From: Mihai Moldovan <ionic@ionic.de>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: null pointer dereference while loading i915
Date: Fri, 10 Aug 2012 19:44:39 +0200 [thread overview]
Message-ID: <50254887.6030209@ionic.de> (raw)
In-Reply-To: <CAKMK7uFsZyhC4b6YWiskm6dk8HPuy_-qaaxvOO2fhYu3krOEaQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8250 bytes --]
* On 10.08.2012 06:39 PM, Daniel Vetter wrote:
> On Fri, Aug 10, 2012 at 6:05 PM, Mihai Moldovan <ionic@ionic.de> wrote:
>> * On 10.08.2012 12:10 PM, Daniel Vetter wrote:
>>> On Wed, Aug 8, 2012 at 6:50 AM, Mihai Moldovan <ionic@ionic.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@chromium.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@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.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
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4506 bytes --]
next prev parent reply other threads:[~2012-08-10 17:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-08 4:50 null pointer dereference while loading i915 Mihai Moldovan
2012-08-10 10:10 ` Daniel Vetter
2012-08-10 16:05 ` Mihai Moldovan
2012-08-10 16:39 ` Daniel Vetter
2012-08-10 17:44 ` Mihai Moldovan [this message]
2012-08-10 23:09 ` Mihai Moldovan
2012-08-13 14:33 ` [PATCH 0/1] hopefully fix null pointer dereference on i915 load Jani Nikula
2012-08-13 14:33 ` Jani Nikula
2012-08-13 14:33 ` [PATCH 1/1] drm/i915: ensure i2c adapter is all set before adding it Jani Nikula
2012-08-13 17:05 ` Daniel Vetter
2012-08-13 15:03 ` [PATCH 0/1] hopefully fix null pointer dereference on i915 load Mihai Moldovan
2012-08-13 15:09 ` Daniel Vetter
2012-08-13 15:27 ` Mihai Moldovan
2012-08-13 16:15 ` Mihai Moldovan
2012-08-14 6:17 ` Jani Nikula
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50254887.6030209@ionic.de \
--to=ionic@ionic.de \
--cc=daniel.vetter@ffwll.ch \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.