看视频时，整个画面可能会随机的莫名卡死

[kashu]

问题：看视频时，整个画面可能会随机的莫名卡死（这个画面不是单指的浏览器中的视频画面部分，而是整个屏幕界面都是卡死的状态）
我觉得这个问题不太容易能够被很好地描述出来，因此，我尽量用语言表达清晰一点

我使用Chromium浏览器在线观看需要flash插件的视频时，在观看过程中，整个画面有可能会卡死（此现象随机性较强，而且比较难被重现，有可能看一两个小时也不一定会出现，很怪），但是一旦出现画面卡死时，声音依旧在正常播放着（声音一直是连续的，未出现卡顿或断续），并且鼠标虽然可以移动，但鼠标做任何其它操作都不会有反应，同时在键盘上按键似乎也没有反应，num clock灯卡死不动（不闪烁也切换不动），并在此时，用快捷键尝试切换到CLI界面，此时，进入了一种看似彻底卡死的状态，鼠标也无法移动，键盘上按任何键也没反应（所以前面说“似乎也没反应”），试图再切换回GUI界面也无效，依旧是一种彻底卡死的状态，但是，在这种卡死的状态中，视频中的声音始终是在正常向前播放着，没有卡顿也没有断续。然后，等待漫长的几分钟后，突然所有的一切就又恢复正常了。

恰巧的是，我在terminal中始终运行着这条监控命令：dstat -cdnmpyslt -N eth0 -D total,sda --top-bio-adv
因此，有系统资源使用率的一个健康状态跟踪，输出信息在这：http://paste.ubuntu.com/16237083/
从第9行（17:47:23）一直到第282行（17:51:47），持续了大约4分半的时间，整个屏幕画面一直处于卡死的状态。
从dstat的输出中来看，在整个卡死的全过程中，IO不存在压力，CPU不存在压力，内存不存在压力，系统的整体负载看上去都很正常……
但从第9行开始，system那列的csw突然从11k骤降到8907、6484、5903，并在随后的4分半时间内稳定在大概5000以内的范围内。感觉好像有一种如释重负的样子？

这个问题在过去的一个月时间里，我好像至少碰到了3次，并且每次我在terminal中都有运行着dstat并跟踪到系统的状况，都是发生在系统负载很低的情况（因此我觉得看上去应该不是系统资源压力过高导致的），并且一旦碰到这个问题时，都是在等待完数分钟的全屏幕画面卡死之后，就一切都恢复正常了，很怪。

请问，这种问题该怎么办是好？（不一定给出直接的解决方法，如果您有好的想法或问题的排查方法也行）谢谢！


附：
操作系统： Xubuntu 14.04.4 LTS 64-bit
chromium-browser浏览器： Version: 49.0.2623.108-0ubuntu0.14.04.1.1113
Kernel版本： 3.16.0-67-generic x86_64 x86_64

[rosynirvana]

看看/var/log/syslog里面有没有gpu hang之类的

[kashu]

看看/var/log/syslog里面有没有gpu hang之类的

这是syslog日志部分：http://paste.ubuntu.com/16238212/
没找到有gpu hang之类的

根据问题出现的时间段，syslog中有这么一段看不太懂的信息：

代码： 全选

May  5 17:51:45 kashu kernel: [199498.580014] ------------[ cut here ]------------
May  5 17:51:45 kashu kernel: [199498.580074] WARNING: CPU: 0 PID: 1940 at /build/linux-lts-utopic-9LCANk/linux-lts-utopic-3.16.0/drivers/gpu/drm/i915/intel_display.c:3324 intel_crtc_wait_for_pending_flips+0x171/0x180 [i915]()
May  5 17:51:45 kashu kernel: [199498.580079] Modules linked in: xt_conntrack ipt_REJECT ip6_tables ebtable_nat ebtables nvram msr pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables hid_generic usbhid hid snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic rfcomm bnep bluetooth 6lowpan_iphc sparse_keymap snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp binfmt_misc snd_rawmidi nfsd auth_rpcgss arc4 nfs_acl kvm_intel snd_seq kvm nfs lockd sunrpc crct10dif_pclmul crc32_pclmul aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ath9k fscache ath9k_common joydev ath9k_hw serio_raw ath snd_seq_device mac80211 snd_timer cfg80211 i915 lpc_ich drm_kms_helper snd drm shpchp soundcore mei_me i2c_algo_bit mei wmi parport_pc ppdev video mac_hid v4l2loopback_dc(OE) videodev media lp parport tcp_htcp psmouse ahci r8169 libahci mii lz4 lz4_compress
May  5 17:51:45 kashu kernel: [199498.580181] CPU: 0 PID: 1940 Comm: Xorg Tainted: G           OE 3.16.0-67-generic #87~14.04.1-Ubuntu
May  5 17:51:45 kashu kernel: [199498.580183] Hardware name: Hasee To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 04/25/2012
May  5 17:51:45 kashu kernel: [199498.580186]  0000000000000009 ffff88030b847bf0 ffffffff817699e8 0000000000000000
May  5 17:51:45 kashu kernel: [199498.580189]  ffff88030b847c28 ffffffff8106ee9d 0000000000000000 ffff8800da82e000
May  5 17:51:45 kashu kernel: [199498.580192]  ffff88030d318238 ffff88030c29c000 ffff88030c29c000 ffff88030b847c38
May  5 17:51:45 kashu kernel: [199498.580195] Call Trace:
May  5 17:51:45 kashu kernel: [199498.580203]  [<ffffffff817699e8>] dump_stack+0x45/0x56
May  5 17:51:45 kashu kernel: [199498.580208]  [<ffffffff8106ee9d>] warn_slowpath_common+0x7d/0xa0
May  5 17:51:45 kashu kernel: [199498.580212]  [<ffffffff8106ef7a>] warn_slowpath_null+0x1a/0x20
May  5 17:51:45 kashu kernel: [199498.580243]  [<ffffffffc03a59f1>] intel_crtc_wait_for_pending_flips+0x171/0x180 [i915]
May  5 17:51:45 kashu kernel: [199498.580249]  [<ffffffff810b6220>] ? prepare_to_wait_event+0x100/0x100
May  5 17:51:45 kashu kernel: [199498.580272]  [<ffffffffc03a84b3>] intel_crtc_disable_planes+0x33/0x1c0 [i915]
May  5 17:51:45 kashu kernel: [199498.580293]  [<ffffffffc03a8a7d>] ironlake_crtc_disable+0x4d/0x920 [i915]
May  5 17:51:45 kashu kernel: [199498.580316]  [<ffffffffc02f2b83>] ? drm_modeset_lock+0x33/0xe0 [drm]
May  5 17:51:45 kashu kernel: [199498.580321]  [<ffffffff81770552>] ? mutex_lock+0x12/0x2f
May  5 17:51:45 kashu kernel: [199498.580345]  [<ffffffffc03a9db7>] intel_crtc_update_dpms+0x67/0xa0 [i915]
May  5 17:51:45 kashu kernel: [199498.580366]  [<ffffffffc03ae1d9>] intel_connector_dpms+0x59/0x70 [i915]
May  5 17:51:45 kashu kernel: [199498.580387]  [<ffffffffc02e9a6f>] drm_mode_obj_set_property_ioctl+0x39f/0x3b0 [drm]
May  5 17:51:45 kashu kernel: [199498.580404]  [<ffffffffc02e9ab0>] drm_mode_connector_property_set_ioctl+0x30/0x40 [drm]
May  5 17:51:45 kashu kernel: [199498.580419]  [<ffffffffc02d89ec>] drm_ioctl+0x1ec/0x660 [drm]
May  5 17:51:45 kashu kernel: [199498.580428]  [<ffffffff811e89f0>] do_vfs_ioctl+0x2e0/0x4c0
May  5 17:51:45 kashu kernel: [199498.580431]  [<ffffffff811d8061>] ? __sb_end_write+0x31/0x60
May  5 17:51:45 kashu kernel: [199498.580436]  [<ffffffff811d5be2>] ? vfs_write+0x172/0x1f0
May  5 17:51:45 kashu kernel: [199498.580439]  [<ffffffff811e8c51>] SyS_ioctl+0x81/0xa0
May  5 17:51:45 kashu kernel: [199498.580444]  [<ffffffff8177214d>] system_call_fastpath+0x1a/0x1f
May  5 17:51:45 kashu kernel: [199498.580446] ---[ end trace 2016c90d1ee5dfa3 ]---

然后，我把这一小段信息（intel_crtc_wait_for_pending_flips+0x171/0x180）直接放到Google里搜索
好像是个什么bug？ 还没看完……

[rosynirvana]

应该就是这个
Intel显核的毛病，有时候会hang，除了升级驱动外没什么好办法

[kashu]

感谢回复！

我浏览了一下这个，他们的问题现象和我的极为相似，他们都是围绕着Linux内核来说的……3.16.0好像有点问题，有人是通过升级到新版内核解决这问题
https://bugs.launchpad.net/ubuntu/+sour ... ug/1384342

我也升级内核试试吧。

[cao627]

你的情况我在ubuntu14 .04也时不时偶尔遇到。具体和你描述的一样。

现在我用debian8，内核也是3.16.0。从来没有遇到过此问题。所以我不认为是内核问题。
debian自带的浏览器播放flash，非常安静，cpu开销在13%上下。我在debian上安装了其他浏览器，播放flash，明显观察到cup开销大，20%以上，笔记本风扇随之会响起。

[vickycq]

chrome://flags 和 chromium 设置中关闭所有“硬件加速、硬解”相关的选项试试看。

现在我用debian8，内核也是3.16.0。从来没有遇到过此问题。所以我不认为是内核问题。

应该无法简单地得出这个结论

[cao627]

@vickcq
chrome倒没试
试的是Vivaldi，还有一款名字忘记了，都卸了。
想想iceweasel也挺好，人总是不满足。

[vickycq]

@vickcq
chrome倒没试
试的是Vivaldi，还有一款名字忘记了，都卸了。
想想iceweasel也挺好，人总是不满足。

Iceweasel 总感觉很卡，一直用不住


浏览器看视频硬解出问题应该比较常见
我这 chrome 没问题。chromium 开硬解后会出现以下现象：
- 正常播放；
- 显示器自动休眠；
- 动鼠标唤醒，出现与楼主类似现象。

在 chrome://flags/ 中搜索 'accel' 关闭相关选项 \
关闭设置中 Use hw acc when possible \
后，可以正常播放

不过以上测试用 chromium 中未安装 flash

[kashu]

感谢各位的回复。

目前用的Linux内核我暂时还没来得及去升级，我先试试@vickycq提供的方法并观测一段时间看有没有效果。

@cao627，浏览器我应该是不会换，再怎么换浏览器，我基本还是在Chromium或Chrome中做选择。
我以前观察过，Firefox在观看同等画质的Flash视频时，占用的CPU资源确实比Chrome和Chromium明显会少一些（csw上下文切换差距较明显）。
其它的浏览器，我没安装过也没用过。

[rosynirvana]

自检信息说的清清楚楚的i915，Intel graphic stack的问题
Intel HD系列gpu hang又不是什么稀罕事，也不是linux平台独有的

[rosynirvana]

另外firefox的NPAPI-flash比chrome的PPAPI-flash效率低，如果用过demanding一点的flash应该很清楚这点
现在linux上的chrome flash早不是七八年前的洪水猛兽了，几年前的笔记本一边看斗鱼直播一边玩页游也没什么问题