| Summary: | [arrandale] kernel BUG setting external monitor to a higher resolution | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Bryce Harrington <bryce> | ||||||||||||
| Component: | DRM/Intel | Assignee: | Daniel Vetter <daniel> | ||||||||||||
| Status: | CLOSED INVALID | QA Contact: | |||||||||||||
| Severity: | major | ||||||||||||||
| Priority: | high | CC: | ben, chris, daniel, eugeni, jbarnes | ||||||||||||
| Version: | unspecified | Keywords: | regression | ||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||||
| OS: | Linux (All) | ||||||||||||||
| Whiteboard: | |||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Bryce Harrington
2012-01-20 10:03:19 UTC
Created attachment 55842 [details]
BUG trace photo
Created attachment 55843 [details]
BootDmesg.txt
Created attachment 55844 [details]
CurrentDmesg.txt
Created attachment 55845 [details]
XorgLog.txt
OOPS-decoding for fun and profit: A reasonable decode of the code from the OOPS 0x400641 <array+1>: mov 0x16e0(%r12),%rdx 0x400649 <array+9>: lea 0x16e0(%r12),%rcx 0x400651 <array+17>: cmp %rdx,%rcx 0x400654 <array+20>: lea -0xb0(%rdx),%rax 0x40065b <array+27>: je 0x400682 0x40065d <array+29>: nopl 0x0(%rax) 0x400664 <array+36>: mov 0x88(%rax),%rdx 0x40066b <array+43>: add 0x30(%rdx),%ebx <- we die here 0x40066e <array+46>: mov 0xb0(%rax),%rdx 0x400675 <array+53>: cmp %rdx,%rcx 0x400678 <array+56>: lea -0xb0(%rdx),%rax 0x40067f <array+63>: add %ah,0x1000a70(%rip) # 0x14010f5 0x400685: sbb (%rbx),%eax 0x400687: cmp (%rax),%ebp 0x400689: add %al,(%rax) 0x40068b: add %al,(%rax,%rax,1) 0x40068e: add %al,(%rax) 0x400690: rex.WR std 0x400692: (bad) 0x400693: incl 0x0(%rax,%rax,1) Some comparison with asm from my own tree suggest that %rdx == gtt_space 0x30(%rdx) gtt_space->size %rax == obj 0x88(rax) == obj->gtt_space 0xb0(rax) == obj->mm_list.next We die at NULL+0x30. Stuff before&after makes less sense, and I'm misssing the function exit code which should follow. Propably the add %rip does something fancy out-of-line. In other news we have an obj on the pinned list with gtt_space = NULL. Created attachment 55880 [details] [review] use private slab for i915 gem objects Please try to reproduce the issue with patch. Also ensure that you either use the SLAB allocator or if your using SLUB, please boot with slub_debug on the kernel cmdline. You are missing one declaration of dev_priv, around line 205. With that fixed, it does build on the Ubuntu kernel. I'm going to test it with slub_debug. > --- Comment #7 from Martin Pool <mbp@sourcefrog.net> 2012-01-22 22:01:45 PST ---
> You are missing one declaration of dev_priv, around line 205. With that fixed,
> it does build on the Ubuntu kernel. I'm going to test it with slub_debug.
Oops, I've fixed that locally but forgot to amend the patch before attaching it.
Hi Daniel, With this patch applied, and 'slub_debug' on the kernel command line, I get the same problem I was previously: no oops, but the external screen is blank or can't sync. Just to check: the patch _does_ get rid of the oops? For the blank screen issue: Please boot with drm.debug=0x4 added to your kernel cmdline, reproduce the problem and then attach the full dmesg. Ping. It looks like the private slab works around foreign memory corruption and for the remaining issues the reporter has gone awol. Also, I don't quite see the evidence for why this is a regression. Tentatively closing, please reopen if this is still an issue on latest kernel version. Closing resolved+invalid. No activity on >4 years. |
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.