前言：如下内容已经是在hang完大概半个多月后了，当时想写，一直没过来写，写blog果然也是已经花费时间的事情。
最近一直在休假，电脑的使用频率也不多。后来还是为了生活，不情愿的去开始上班了，上班的第一件事是什么呢？ 当然是配置网路，配好了网路之后，我就开始滚系统（就全系统更新至最新包的意思，因为我们archer的特性之一就是滚动更新，恩，更新都是用滚的。），好久没有正经用了，当然要进入最好最新的状态才能稍微愉快的开始工作了，随便也为新同事们秀一秀我的系统。
就酱，上了两天。就发现不对劲。用着用着X就挂了。不用说，首先就是怀疑滚，系统滚进了什么不稳定的包。
查所有滚动包的列表，它们在这里：
[tong@TStation ~]$ vim /var/log/pacman.log
查看系统日志，两招：1， journalctl。2. dmesg
[tong@TStation ~]$ dmesg
实在抱歉的是，我当时（就是半个月前）没有把log留存下来，log里边的主要内容就是，
GPU HANG，请到 ”https://bugs.freedesktop.org/ “ 去报BUG
综合以上信息，我首先判断是intel的驱动出了问题。查看滚包列表里也确实，发现了内核包（linux）的更新。（intel的驱动在linux内核包里）。然后我就downgrade了linux内核包。
downgrade的方法： 因为arch是滚动更新的，且所有包都由上游提供，所以不提供官方的downgrade方法。换句话说就是arch只负责让你滚上去，而不负责帮你滚下来。
基于以上，一般的做法是，保留旧几个版本的更新包，当出现问题时，可以手动讲单包回退至指定版本。
旧包都保留在这个地方 /var/cache/pacman/pkg/ 系统会基于规则删除最旧的，路径和规则都是可配置的，怎么配就不写了，有兴趣的自行查询手册。
然后找到我需要降回去的linux版本的包，使用pacman降回去，并重启：
[tong@TStation ~]$ pacman -U /var/cache/pacman/pkg/linux-4.7.--x86_64.pkg.tar.xz
以上，是确认了确实是某包故障时的常规解决方法。
然而，可想而知，我的问题，并没有那么简单。降级了kernel，问题依然存在。
于是又陷入了毫无头绪的状态下，遂，求google帮忙。同样没有找到有用的信息。
这期间我也是一直在搜寻着导致这个问题的蛛丝马迹，我当时依然在看dpdk的文档，同时开着win虚拟机和一些其他项目的同事通过QQ沟通，是的，大家依赖着QQ。这样，工作不久，内存就会达到某个临界值，chrome和qemu都在吃内存。于是我开始怀疑chrome出了什么问题。关了chrome的硬件加速，换firefox，都未能顺利解决问题。
变得束手无策了，我开始怀疑KDE（倒霉的KDE，没次又被怀疑），想换到FVWM，这个时候又提到了FVWM，尽早重新配置起来。于是在重新配置FVWM之前，我绝望般的打算去报BUG了，因为这个问题，很难提供有用的信息给开发者，从报bug到解决，定然是个漫长的过程。
报bug之前，自然是要找一找有没有报过的bug。然后我就发现了这个：
https://bugs.freedesktop.org/show_bug.cgi?id=89360
其中提到：
Short version
---
adding 'intel_iommu=igfx_off' helped
是的，还记得，为了调试DPDK，我打开了vt-d功能么？就是为了让PCI设备直接在用户态使用。参加http://www.cnblogs.com/hugetong/p/5904024.html
如此回想起来，每次出问题都是在开启了qemu之后。
总结：
1. 去掉内核选项 intel_iommu=on
2. 升级内核至最新。
3. 重启
问题解决 : )
解决归解决，还是有两个引申出来的问题
1. FVWM，需要重新配置起来，处于可用状态，随时待命。
2. 听闻了 zfs，brtfs两个文件系统？可以文件系统级别快照，回滚？？