| Summary: | [SNB] some simple operations will cause kernel oops | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | zhao jian <jian.j.zhao> | ||||||
| Component: | DRM/Intel | Assignee: | Zou Nan hai <nanhai.zou> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | critical | ||||||||
| Priority: | highest | CC: | chris, jbarnes | ||||||
| Version: | XOrg git | ||||||||
| Hardware: | x86 (IA32) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
|
Description
zhao jian
2010-11-04 23:54:14 UTC
Created attachment 40059 [details]
xorg.0.log
Created attachment 40060 [details]
dmesg of the kernel oops when doing rendercheck
When use mplayer to play a video with xv output, system will stop response(oops will be reported) Reproduce steps: ---------------- 1. xinit 2. mplayer -vo xv mediafile 3. move and resize window Following is the sys log of playing video with xv output. Message from syslogd@x-hnr1 at Nov 6 02:44:44 ... kernel:Oops: 0002 [#1] SMP Message from syslogd@x-hnr1 at Nov 6 02:44:44 ... kernel:last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/energy_full Message from syslogd@x-hnr1 at Nov 6 02:44:44 ... kernel:Process X (pid: 2848, ti=f5a20000 task=f59a2580 task.ti=f5a20000) Message from syslogd@x-hnr1 at Nov 6 02:44:44 ... kernel:Stack: Message from syslogd@x-hnr1 at Nov 6 02:44:44 ... kernel:Call Trace: Message from syslogd@x-hnr1 at Nov 6 02:44:44 ... kernel:Code: 20 8b 53 10 c7 04 02 01 00 80 10 8b 43 20 8d 50 04 89 53 20 8b 53 10 c7 44 02 04 80 00 00 00 8b 43 20 8d 50 04 89 53 20 8b 53 10 <89> 7c 02 04 8b 43 20 8d 50 04 89 53 20 8b 53 10 c7 44 02 04 00 Message from syslogd@x-hnr1 at Nov 6 02:44:44 ... kernel:EIP: [<f8425658>] blt_ring_add_request+0x5d/0xa5 [i915] SS:ESP 0068:f5a21d94 Message from syslogd@x-hnr1 at Nov 6 02:44:44 ... kernel:CR2: 00000000f8b60000 Note that I can't see this on sandybridge desktop with D2 CPU. So this might be hw stepping related. This is a side effect of bug 31370. I've cherry-picked the workaround from -next onto -staging that should prevent this: commit a3d4677623ca677c18f90484157be69c4c5f8312 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Nov 5 08:56:38 2010 +0000 drm/i915/ringbuffer: Use the HEAD auto-reporting mechanism My Sandybridge only reports 0 for the ring buffer registers, causing it to hang as soon as we exhaust the available ring. As a workaround, take advantage of our huge ring buffers and use the auto-reporting mechanism to update the status page with the HEAD location every 64 KiB. Cherry-picked from 6aa56062eaba67adfb247cded244fd877329588d. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (In reply to comment #5) > Note that I can't see this on sandybridge desktop with D2 CPU. So this might be > hw stepping related. What does /sys/kernel/debug/dri/0/i915_*ringbuffer_info report? Can you start drm-intel-next without it barfing? And what revision is SNB D2? (In reply to comment #6) > This is a side effect of bug 31370. I've cherry-picked the workaround from > -next onto -staging that should prevent this: > > commit a3d4677623ca677c18f90484157be69c4c5f8312 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Fri Nov 5 08:56:38 2010 +0000 > > drm/i915/ringbuffer: Use the HEAD auto-reporting mechanism > > My Sandybridge only reports 0 for the ring buffer registers, causing it > to hang as soon as we exhaust the available ring. As a workaround, take > advantage of our huge ring buffers and use the auto-reporting mechanism > to update the status page with the HEAD location every 64 KiB. > > Cherry-picked from 6aa56062eaba67adfb247cded244fd877329588d. > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Chris, what do you mean by "side effect of bug 31370"? The KMS can be enabled well here. Of course I can have a test with this commit and patch it to drm-intel-fixes branch. Bug 31370 is the hw doesn't read the correct values from the ringbuffer registers which is the root cause of the problem here. (In reply to comment #6) > This is a side effect of bug 31370. I've cherry-picked the workaround from > -next onto -staging that should prevent this: > commit a3d4677623ca677c18f90484157be69c4c5f8312 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Fri Nov 5 08:56:38 2010 +0000 > drm/i915/ringbuffer: Use the HEAD auto-reporting mechanism > My Sandybridge only reports 0 for the ring buffer registers, causing it > to hang as soon as we exhaust the available ring. As a workaround, take > advantage of our huge ring buffers and use the auto-reporting mechanism > to update the status page with the HEAD location every 64 KiB. > Cherry-picked from 6aa56062eaba67adfb247cded244fd877329588d. > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> We tested with commit a3d4677623ca677c18f90484157be69c4c5f8312 on -staging branch, both the rendercheck and media work well without kernel oops. So Chris, can you pull it into -fixes branch? Thanks. The commit a3d4677623ca677c18f90484157be69c4c5f8312 was cherry-picked to drm-intel-fixes now, and it works well now with 3f8ff0e72d75fdbe7f2cba2c4015fd9fdd9e13fd on drm-intel-fixes branch. so closed. Verified->Closed. |
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.