Eric Biggers
2015-Aug-09 17:06 UTC
[Nouveau] [REGRESSION] nouveau: Crash in gk104_fifo_intr_runlist()
Hi, I am testing Linux v4.2-rc5 and I am sporadically getting crashes shortly after startup in gk104_fifo_intr_runlist(). What I've found is that the 'mask' value read from offset 0x2a00 comes back as '0xbad0da00'. This causes the 'engn' variable to be assigned the value 9, which is invalid; then wake_up() is called on an uninitialized waitqueue which causes the crash. Reverting commit 1addc12648521d ("drm/nouveau/fifo/gk104: kick channels when deactivating them") seemed to make the problem go away, although I can't be 100% sure because the problem is sporadic. Attached an example of the kernel log up to the crash. Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg.gz Type: application/gzip Size: 17948 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20150809/db77b95f/attachment-0001.bin>
Ilia Mirkin
2015-Aug-09 17:28 UTC
[Nouveau] [REGRESSION] nouveau: Crash in gk104_fifo_intr_runlist()
Alexandre, could you take a look? 0xbad* generally comes from bad mmio reads. On Aug 9, 2015 1:08 PM, "Eric Biggers" <ebiggers3 at gmail.com> wrote:> Hi, > > I am testing Linux v4.2-rc5 and I am sporadically getting crashes shortly > after > startup in gk104_fifo_intr_runlist(). What I've found is that the 'mask' > value > read from offset 0x2a00 comes back as '0xbad0da00'. This causes the 'engn' > variable to be assigned the value 9, which is invalid; then wake_up() is > called > on an uninitialized waitqueue which causes the crash. > > Reverting commit 1addc12648521d ("drm/nouveau/fifo/gk104: kick channels > when > deactivating them") seemed to make the problem go away, although I can't > be 100% > sure because the problem is sporadic. > > Attached an example of the kernel log up to the crash. > > Eric > > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20150809/f5ead3e1/attachment.html>
Alexandre Courbot
2015-Aug-11 04:28 UTC
[Nouveau] [REGRESSION] nouveau: Crash in gk104_fifo_intr_runlist()
Indeed, and I am actually surprised to see one here. I will double-check that patch. Eric, would you be able to give an estimate of the repro rate for this issue? More testing with and without the patch would be welcome, it'd be good to know whether it is actually the culprit or not. On Mon, Aug 10, 2015 at 2:28 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:> Alexandre, could you take a look? 0xbad* generally comes from bad mmio > reads. > > On Aug 9, 2015 1:08 PM, "Eric Biggers" <ebiggers3 at gmail.com> wrote: >> >> Hi, >> >> I am testing Linux v4.2-rc5 and I am sporadically getting crashes shortly >> after >> startup in gk104_fifo_intr_runlist(). What I've found is that the 'mask' >> value >> read from offset 0x2a00 comes back as '0xbad0da00'. This causes the >> 'engn' >> variable to be assigned the value 9, which is invalid; then wake_up() is >> called >> on an uninitialized waitqueue which causes the crash. >> >> Reverting commit 1addc12648521d ("drm/nouveau/fifo/gk104: kick channels >> when >> deactivating them") seemed to make the problem go away, although I can't >> be 100% >> sure because the problem is sporadic. >> >> Attached an example of the kernel log up to the crash. >> >> Eric >> >> _______________________________________________ >> Nouveau mailing list >> Nouveau at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/nouveau >> >
Possibly Parallel Threads
- [REGRESSION] nouveau: Crash in gk104_fifo_intr_runlist()
- [REGRESSION] nouveau: Crash in gk104_fifo_intr_runlist()
- [PATCH] Revert "drm/nouveau/fifo/gk104: kick channels when deactivating them"
- [PATCH 0/5] Improve Robust Channel (RC) recovery for Turing
- [RFC PATCH v2 0/5] More explicit pushbuf error handling