Summary: | [SNB libva]when play a MPEG2 file and resize it, it will cause GPU hang occasionally | ||||||
---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Hai <hai.lan> | ||||
Component: | Driver/intel | Assignee: | haihao <haihao.xiang> | ||||
Status: | VERIFIED FIXED | QA Contact: | Hai <hai.lan> | ||||
Severity: | major | ||||||
Priority: | medium | ||||||
Version: | unspecified | ||||||
Hardware: | x86 (IA32) | ||||||
OS: | Linux (All) | ||||||
Whiteboard: | |||||||
i915 platform: | i915 features: | ||||||
Attachments: |
|
Description
Hai
2010-12-27 21:18:06 UTC
For Ironlake, this issue won't happen. So it's a regression. For an mpeg2 SD file, resizing it also may cause GPU to hang The previous stack is printed by mplayer automatically. Following is using cat /proc/2816/stack to get the stack(2816 is the pid of mplayer) [<f8406f20>] i915_do_wait_request+0x20d/0x335 [i915] [<f840707d>] i915_gem_object_wait_rendering+0x35/0x3d [i915] [<f840ac56>] i915_gem_do_execbuffer+0x861/0xb58 [i915] [<f840b03f>] i915_gem_execbuffer2+0xf2/0x175 [i915] [<f814b20c>] drm_ioctl+0x268/0x322 [drm] [<c02c691e>] do_vfs_ioctl+0x4fa/0x53f [<c02c69a4>] sys_ioctl+0x41/0x61 [<c020280c>] sysenter_do_call+0x12/0x22 [<ffffffff>] 0xffffffff Even if this issue exists, I don't think it is a regression. Yes, it's not a regression. Sorry about it. It works fine on my destop and zhenyu's mobile machines . What is your stepping? My stepping is 6 Hai: Haihao was asking for graphics revision (see lspci), not cpu stepping. The graphics revision is 08. Could you try the latest master branch? I have tried it with the latest master branch.This issue still happens. But when I use another sandybridge test machine(graphics revision is 09), this issue won't happen. So I think maybe it is a hardware issue. *** Bug 32593 has been marked as a duplicate of this bug. *** How about the result after exchanging the disks? I have used this harddisk with Sugarbay. This issue won't happen. So it can be proved as a hardware issue. or a bios issue. VAAPI works fine with Zhenyu's disk on this machine. So something should be wrong on your disk. We have reinstalled a new OS and tested it on Huron River. The issue still happens occasionally. So I reopen it and the improtance can be medium. I don't think it is related to OS. it is better to build all components on this machine, not just copy from your build machine. I can't reproduce this issue on HuronRiver (the revision is also 8). Could you detail how to reproduce this issue? BTW, please attach your xorg.0.log. Created attachment 41867 [details]
Xorg.0.log
Reproduce steps: ------------------------- mplayer -vo vaapi -va vaapi -fps 25 TS1080i25_h264cab_10mbs_sally-0xe0.264 then press "f" to switch to full screen frequently. (In reply to comment #20) > Reproduce steps: > ------------------------- > mplayer -vo vaapi -va vaapi -fps 25 TS1080i25_h264cab_10mbs_sally-0xe0.264 Are you sure this is a MPEG2 issue? both of TS1080i25_h264cab_10mbs_sally-0xe0.264 and HD.Club-Alisan.Trailer-80Mbps.mpg have the same issue. Can you reproduce this issue now ? This issue won't happen with fillowing commit Libdrm: (master)2.4.24-6-g3b04c73650b5e9bbcb602fdb8cea0b16ad82d0c0 Mesa: (7.10)d525a1b4686cf81eeab79c2fda78e756394d8e47 Xserver: (master)xorg-server-1.10.0 Xf86_video_intel: (master)2.14.901-4-gee740778f5d5355c04f6fc4564f598993b106d62 Cairo: (master)90156f6ab7b94e9e576e34f6a2d8cb809242f8d0 Libva: (master)b7ff2141aeb2adbf5743fed7910a62d971c15013 Kernel: (drm-intel-fixes) 467cffba85791cdfce38c124d75bd578f4bb8625 It also won't hallpen with unstable commit Libdrm: (master)2.4.24-6-g3b04c73650b5e9bbcb602fdb8cea0b16ad82d0c0 Mesa: (master)9b13c988acbf56018c52724e902a15c92ad89db3 Xserver: (master)xorg-server-1.10.0-120-gefcb7275ce5de651f91ba4ff8bb227dfb68bb154 Xf86_video_intel: (master)2.14.901-15-g6bd635b6c46cfa704892f640ac40db133f6fc164 Cairo: (master)90156f6ab7b94e9e576e34f6a2d8cb809242f8d0 Libva: (master)b7ff2141aeb2adbf5743fed7910a62d971c15013 Kernel: (drm-intel-next) 47ae63e0c2e5fdb582d471dc906eb29be94c732f So may close it. marked as fixed. Thanks |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.