Re: null pointer dereference while loading i915
* On 10.08.2012 07:44 PM, Mihai Moldovan wrote: > 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 Just to be safe, I also tested git HEAD (3.6.0-rc1-00209-gf62bf17), no dice either. Best regards, Mihai smime.p7s Description: S/MIME Cryptographic Signature
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 wrote: >> * On 10.08.2012 12:10 PM, Daniel Vetter wrote: >>> On Wed, Aug 8, 2012 at 6:50 AM, Mihai Moldovan 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: 0x0010 >> IPEIR: 0x >> IPEHR: 0x0200 >> INSTDONE: 0x >> INSTPS: 0x8001e025 >> INSTDONE1: 0xbfbb >> ACTHD: 0x00a4203c >> page table error >> PGTBL_ER: 0x0010 >> [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, 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
Re: null pointer dereference while loading i915
On Fri, Aug 10, 2012 at 6:05 PM, Mihai Moldovan wrote: > * On 10.08.2012 12:10 PM, Daniel Vetter wrote: >> On Wed, Aug 8, 2012 at 6:50 AM, Mihai Moldovan 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: 0x0010 > IPEIR: 0x > IPEHR: 0x0200 > INSTDONE: 0x > INSTPS: 0x8001e025 > INSTDONE1: 0xbfbb > ACTHD: 0x00a4203c > page table error > PGTBL_ER: 0x0010 > [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, 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. 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. Thanks, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: null pointer dereference while loading i915
* On 10.08.2012 12:10 PM, Daniel Vetter wrote: > On Wed, Aug 8, 2012 at 6:50 AM, Mihai Moldovan 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: 0x0010 IPEIR: 0x IPEHR: 0x0200 INSTDONE: 0x INSTPS: 0x8001e025 INSTDONE1: 0xbfbb ACTHD: 0x00a4203c page table error PGTBL_ER: 0x0010 [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, 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. Best regards, Mihai smime.p7s Description: S/MIME Cryptographic Signature
Re: null pointer dereference while loading i915
On Wed, Aug 8, 2012 at 6:50 AM, Mihai Moldovan 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? Yours, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: null pointer dereference while loading i915
On Wed, Aug 8, 2012 at 6:50 AM, Mihai Moldovan io...@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? Yours, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: null pointer dereference while loading i915
* On 10.08.2012 12:10 PM, Daniel Vetter wrote: On Wed, Aug 8, 2012 at 6:50 AM, Mihai Moldovan io...@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: 0x0010 IPEIR: 0x IPEHR: 0x0200 INSTDONE: 0x INSTPS: 0x8001e025 INSTDONE1: 0xbfbb ACTHD: 0x00a4203c page table error PGTBL_ER: 0x0010 [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, 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. Best regards, Mihai smime.p7s Description: S/MIME Cryptographic Signature
Re: null pointer dereference while loading i915
On Fri, Aug 10, 2012 at 6:05 PM, Mihai Moldovan io...@ionic.de wrote: * On 10.08.2012 12:10 PM, Daniel Vetter wrote: On Wed, Aug 8, 2012 at 6:50 AM, Mihai Moldovan io...@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: 0x0010 IPEIR: 0x IPEHR: 0x0200 INSTDONE: 0x INSTPS: 0x8001e025 INSTDONE1: 0xbfbb ACTHD: 0x00a4203c page table error PGTBL_ER: 0x0010 [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, 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. 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. Thanks, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 io...@ionic.de wrote: * On 10.08.2012 12:10 PM, Daniel Vetter wrote: On Wed, Aug 8, 2012 at 6:50 AM, Mihai Moldovan io...@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: 0x0010 IPEIR: 0x IPEHR: 0x0200 INSTDONE: 0x INSTPS: 0x8001e025 INSTDONE1: 0xbfbb ACTHD: 0x00a4203c page table error PGTBL_ER: 0x0010 [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, 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 #
Re: null pointer dereference while loading i915
* On 10.08.2012 07:44 PM, Mihai Moldovan wrote: 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 Just to be safe, I also tested git HEAD (3.6.0-rc1-00209-gf62bf17), no dice either. Best regards, Mihai smime.p7s Description: S/MIME Cryptographic Signature
null pointer dereference while loading i915
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". PCI-IDs: 00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e12] (rev 03) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation Device [8086:1003] 00:02.1 Display controller [0380]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e13] (rev 03) Subsystem: Intel Corporation Device [8086:1003] Messages are attached. Any help is appreciated, thanks. :) Best regards, Mihai i915_kernel_BUG_gmbus_nullptrderef.txt.bz2 Description: BZip2 compressed data i915_3.0.2_warning_messages.txt.bz2 Description: BZip2 compressed data smime.p7s Description: S/MIME Cryptographic Signature
null pointer dereference while loading i915
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. PCI-IDs: 00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e12] (rev 03) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation Device [8086:1003] 00:02.1 Display controller [0380]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e13] (rev 03) Subsystem: Intel Corporation Device [8086:1003] Messages are attached. Any help is appreciated, thanks. :) Best regards, Mihai i915_kernel_BUG_gmbus_nullptrderef.txt.bz2 Description: BZip2 compressed data i915_3.0.2_warning_messages.txt.bz2 Description: BZip2 compressed data smime.p7s Description: S/MIME Cryptographic Signature
