[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50254887.6030209@ionic.de>
Date: Fri, 10 Aug 2012 19:44:39 +0200
From: Mihai Moldovan <ionic@...ic.de>
To: Daniel Vetter <daniel.vetter@...ll.ch>
CC: LKML <linux-kernel@...r.kernel.org>
Subject: Re: null pointer dereference while loading i915
* On 10.08.2012 06:39 PM, Daniel Vetter wrote:
> On Fri, Aug 10, 2012 at 6:05 PM, Mihai Moldovan <ionic@...ic.de> wrote:
>> * On 10.08.2012 12:10 PM, Daniel Vetter wrote:
>>> On Wed, Aug 8, 2012 at 6:50 AM, Mihai Moldovan <ionic@...ic.de> wrote:
>>>> Hi Daniel, hi list
>>>>
>>>> ever since version 3.2.0 (maybe even earlier, but 3.0.2 is still working fine),
>>>> my box is crashing when loading the i915 driver (mode-setting enabled.)
>>>>
>>>> The current version I'm testing with is 3.5.0.
>>>>
>>>> I was able to get the BUG output (please forgive any errors/flips in the output,
>>>> I have had to transcribe the messages from the screen/images), however, I'm not
>>>> able to find out what's wrong.
>>>>
>>>> If I see it correctly, there's a null pointer dereference in a printk called
>>>> from inside gmbus_xfer. The only printk calls I can see in
>>>> drivers/gpu/drm/i915/intel_i2c.c gmbus_xfer() however are issued by the
>>>> DRM_DEBUG_KMS() and DRM_INFO() macros.
>>>> Neither call looks wrong to me, I even tried to swap adapter->name with
>>>> bus->adapter.name and make *sure* i < num is true, but haven't had any success.
>>>>
>>>> I'd really like to see this bug fixed, as it's preventing me from updating the
>>>> kernel for over a year now.
>>>>
>>>> Also, while 3.0.2 works, it *does* spew error/warning messages related to gmbus
>>>> and I've had corrupted VTs in the past (albeit after a long uptime with multiple
>>>> X restarting and DVI cable unplugging/reattaching events), so maybe there's a
>>>> lot more broken than "expected".
>>> Hm, this is rather strange. gmbus should not be enable on 3.2 nor 3.0,
>>> since exactly this issue might happen. We've re-enabled gmbus again on
>>> 3.5 after having fixed this bug. Are you sure that this is plain 3.2
>>> you're running?
>> Sorry, I messed up the version numbers. Started bisecting yesterday and noticed,
>> that 3.0 up to 3.2 still work "fine" (see below), instead I've had another
>> problem with 3.2 (completely lockup after the kernel is running for a few
>> minutes, but I have no idea where this issue is coming from. Seems to be
>> happening with 3.2.0 only, so... *shrug*)
>>
>> 3.0.2 => working, gmbus warnings as posted.
>> 3.1-09933/07170 => working, NO gmbus warnings, but render errors (see below)
>> 3.2-rc2 to rc4 => working, NO gmbus warnings, but render errors (see below)
>> --- (stopped bisecting 3.0 to 3.2 as this was pointless) ---
>> --- (restarted bisecting with 3.2 to 3.5) ---
>> 3.3.0-06109 => working, gmbus warnings just like with 3.0, render errors
>> (see below)
>> 3.4.0-07487 => working, gmbus warnings, hang errors (see below)
>> ...
>>
>> I've done more steps, but have not yet finished bisecting, so stay tuned.
>> All those render errors look like that:
>>
>> [drm] capturing error event; look for more information in
>> /debug/dri/0/i915_error_state
>> render error detected, EIR: 0x00000010
>> IPEIR: 0x00000000
>> IPEHR: 0x02000000
>> INSTDONE: 0xffffffff
>> INSTPS: 0x8001e025
>> INSTDONE1: 0xbfbbffff
>> ACTHD: 0x00a4203c
>> page table error
>> PGTBL_ER: 0x00100000
>> [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
>>
>> I'll finish bisecting (and hope, that my guess was right, concerning the
>> varaiant I wasn't able to build) and will post the bisect log when done.
>>
>> Meanwhile: at least for 3.0.2 and even older versions, gmbus must have been
>> enabled as I'm pretty sure I always saw those errors when booting (just
>> confirmed via logs for 3.0.0, 26.38.6, 2.6.39). Doesn't come up with 2.6.34,
>> 2.6.36.1, 3.1-..., 3.2-... though.
> Yeah, we've enabled gmbus a few times and then disabled it again due
> to bugs. Also, the usual debug messsage says gmbus even when gmbus
> isn't on ... yeah, slightly confusing, but that should be fixed, too.
Hm, OK.
Well, I'm done now.
bisect log:
git bisect start
# good: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
git bisect good 805a6af8dba5dfdd35ec35dc52ec0122400b2610
# bad: [28a33cbc24e4256c143dce96c7d93bf423229f92] Linux 3.5
git bisect bad 28a33cbc24e4256c143dce96c7d93bf423229f92
# good: [49d99a2f9c4d033cc3965958a1397b1fad573dd3] Merge branch 'for-linus' of
git://oss.sgi.com/xfs/xfs
git bisect good 49d99a2f9c4d033cc3965958a1397b1fad573dd3
# good: [813a95e5b4fa936bbde10ef89188932745dcd7f4] Merge tag 'pinctrl' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good 813a95e5b4fa936bbde10ef89188932745dcd7f4
# bad: [9978306e31a8f89bd81fbc4c49fd9aefb1d30d10] Merge branch 'for-linus' of
git://oss.sgi.com/xfs/xfs
git bisect bad 9978306e31a8f89bd81fbc4c49fd9aefb1d30d10
# good: [927ad551031798d4cba49766549600bbb33872d7] Merge tag
'ktest-v3.5-spelling' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest
git bisect good 927ad551031798d4cba49766549600bbb33872d7
# good: [2c01e7bc46f10e9190818437e564f7e0db875ae9] Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
git bisect good 2c01e7bc46f10e9190818437e564f7e0db875ae9
# bad: [5f54d29ee9dace1e2ef4e8c9873ad4dd7a06d11a] drm/nva3/pm: make pll->pll
mode work
git bisect bad 5f54d29ee9dace1e2ef4e8c9873ad4dd7a06d11a
# bad: [8b2e326dc7c5aa6952c88656d04d0d81fd85a6f8] drm/i915: Unconditionally
initialise the interrupt workers
git bisect bad 8b2e326dc7c5aa6952c88656d04d0d81fd85a6f8
# bad: [f637fde434c9e3687798730c7ddd367e93666013] drm/i915: inline
enable/disable_irq into ring->get/put_irq
git bisect bad f637fde434c9e3687798730c7ddd367e93666013
# bad: [23e3f9b37e7368ee8530ba99907508363feebc14] drm/i915: check for disabled
interrupts on ValleyView
git bisect bad 23e3f9b37e7368ee8530ba99907508363feebc14
# good: [8489731c9bd22c27ab17a2190cd7444604abf95f] drm/i915: move clflushing
into shmem_pread
git bisect good 8489731c9bd22c27ab17a2190cd7444604abf95f
# good: [3bd7d90938f1fe77de5991dc4b727843c4980b2a] drm/i915/intel_i2c: refactor
using intel_gmbus_get_adapter
git bisect good 3bd7d90938f1fe77de5991dc4b727843c4980b2a
# bad: [57f350b6722f9569f407872f6ead56e2d221d98a] drm/i915: add DPIO support
git bisect bad 57f350b6722f9569f407872f6ead56e2d221d98a
# bad: [93e537a10f2c8c0f2e74409b6cb473fc221758fa] drm/i915: split LVDS update
code out of i9xx_crtc_mode_set
git bisect bad 93e537a10f2c8c0f2e74409b6cb473fc221758fa
# bad: [f2c9677be3158c31ba19f527e2be0f7a519e19d1] drm/i915/intel_i2c: allocate
gmbus array as part of drm_i915_private
git bisect bad f2c9677be3158c31ba19f527e2be0f7a519e19d1
# bad: [2ed06c93a1fce057808894d73167aae03c76deaf] drm/i915/intel_i2c: gmbus
disabled and reserved ports are invalid
git bisect bad 2ed06c93a1fce057808894d73167aae03c76deaf
bisect result:
2ed06c93a1fce057808894d73167aae03c76deaf is the first bad commit
commit 2ed06c93a1fce057808894d73167aae03c76deaf
Author: Daniel Kurtz <djkurtz@...omium.org>
Date: Wed Mar 28 02:36:15 2012 +0800
drm/i915/intel_i2c: gmbus disabled and reserved ports are invalid
There is no GMBUS "disabled" port 0, nor "reserved" port 7.
For the other 6 ports there is a fixed 1:1 mapping between pin pairs and
gmbus ports, which means every real gmbus port has a gpio pin.
Given these realizations, clean up gmbus initialization.
Tested on Sandybridge (gen 6, PCH == CougarPoint) hardware.
Signed-off-by: Daniel Kurtz <djkurtz@...omium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@...ll.ch>
:040000 040000 cae5a0edaff96fc7f03eafaf8b2f1909032b0694
9244756995c6fe8b4e1e2ef5c916be1fe7ca4cbd M drivers
I guess just reverting the commit on top of v3.5.0 won't work though.
> For the gpu hang, please ensure that you're running the latest stable
> release of everything (to avoid hunting down already known issues and
> also because recent kernels dump more useful stuff), grab the entire
> i915_error_state from debugfs and file a bug report with the usual
> details at bugs.freedesktop.org against dri -> drm/intel.
I should have a decently current userland (i.e., Intel Xorg module version 2.20.2).
Will do this once the kernel is working again. :)
Best regards,
Mihai
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4506 bytes)
Powered by blists - more mailing lists