Re: [regression from v4.19] Re: 4.20.0-rc6-next-20181210, v4.20-rc1: list_del corruption on thinkpad x220, graphics related?
Hi! > > > So if you could please try drm-tip reproducing AND open a bug in Bugzilla. > > > If you are unwilling to do that, it is very difficult to help you > > > more. > > > > Website says I have to read and agree to two different pieces of > > legalesee, and I'd need to keep track of yet another password... so > > you can "communicate" with me. > > > > But you can already communicate with me, over email. > > I've listed all the reasons why our bug handling process is what it is. > > If registering to the Bugzilla is too much of an effort for you, then I > won't be able to help you further on this. Actually I did register at the bugzilla. Only useful help there was that CONFIG_DRM_I915_DEBUG_GEM might be useful. Unfortunately that one seems to make it panic() and impossible to get anything useful. https://bugs.freedesktop.org/show_bug.cgi?id=109175 Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [regression from v4.19] Re: 4.20.0-rc6-next-20181210, v4.20-rc1: list_del corruption on thinkpad x220, graphics related?
Quoting Pavel Machek (2018-12-27 10:34:39) > Hi! > > > > > > If you think it is useful, I can try to update my machine to > > > > > linux-next. > > > > > > > > linux-next is closer to drm-tip, so it's better. Do you have some > > > > specific reason for not wanting to run drm-tip (but linux-next is still > > > > ok)? > > > > > > I already have build/update scripts for -next, and I trust -next not > > > to store screenshots of my desktop in my master boot record :-). > > > > > > Anyway, it does happen with -next. This time, chromiums were running, > > > and crash happened minute? after I exited flightgear. It can be seen > > > in the logs. > > > > > > Oh and I might want to mention -- machine was rather deep in swap this > > > time, as in "mouse jumping when starting fgfs" and "could feel the > > > chromium being swapped back in". I might have had this situation > > > before, and just powercycled the machine "because it is so deep in > > > swap that it will not recover". > > > > > > top says: > > > > > > top - 19:18:24 up 2 days, 8:03, 2 users, load average: 3.02, 3.45, > > > 3.21 > > > Tasks: 141 total, 1 running, 86 sleeping, 0 stopped, 2 zombie > > > %Cpu(s): 18.8 us, 7.6 sy, 3.0 ni, 68.4 id, 1.3 wa, 0.0 hi, 0.9 > > > si, 0.0 st > > > KiB Mem: 5967968 total, 663244 used, 5304724 free,48876 > > > buffers > > > KiB Swap: 1681428 total, 170904 used, 1510524 free. 446280 > > > cached Mem > > > > > > but of course that memory is free once everything died. > > > > > > Any ideas? Should I go back to v4.19 to see if it happens there, too? > > > > linux-next includes very much the same code as drm-tip. There's nobody > > magically reviewing the code more than it is reviewed for inclusion into > > drm-tip, when it is fed into linux-next. So thinking linux-next would be > > some way safer is an illusion. > > > > It sounds like having memory pressure expedites the corruption, which > > should make it easier to reproduce and thus fix. > > > > So if you could please try drm-tip reproducing AND open a bug in Bugzilla. > > If you are unwilling to do that, it is very difficult to help you > > more. > > Website says I have to read and agree to two different pieces of > legalesee, and I'd need to keep track of yet another password... so > you can "communicate" with me. > > But you can already communicate with me, over email. I've listed all the reasons why our bug handling process is what it is. If registering to the Bugzilla is too much of an effort for you, then I won't be able to help you further on this. Regards, Joonas > I verified v4.19 is stable -- it worked ok for way more than two days > it usually takes to crash. > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[regression from v4.19] Re: 4.20.0-rc6-next-20181210, v4.20-rc1: list_del corruption on thinkpad x220, graphics related?
Hi! > > > > If you think it is useful, I can try to update my machine to > > > > linux-next. > > > > > > linux-next is closer to drm-tip, so it's better. Do you have some > > > specific reason for not wanting to run drm-tip (but linux-next is still > > > ok)? > > > > I already have build/update scripts for -next, and I trust -next not > > to store screenshots of my desktop in my master boot record :-). > > > > Anyway, it does happen with -next. This time, chromiums were running, > > and crash happened minute? after I exited flightgear. It can be seen > > in the logs. > > > > Oh and I might want to mention -- machine was rather deep in swap this > > time, as in "mouse jumping when starting fgfs" and "could feel the > > chromium being swapped back in". I might have had this situation > > before, and just powercycled the machine "because it is so deep in > > swap that it will not recover". > > > > top says: > > > > top - 19:18:24 up 2 days, 8:03, 2 users, load average: 3.02, 3.45, > > 3.21 > > Tasks: 141 total, 1 running, 86 sleeping, 0 stopped, 2 zombie > > %Cpu(s): 18.8 us, 7.6 sy, 3.0 ni, 68.4 id, 1.3 wa, 0.0 hi, 0.9 > > si, 0.0 st > > KiB Mem: 5967968 total, 663244 used, 5304724 free,48876 > > buffers > > KiB Swap: 1681428 total, 170904 used, 1510524 free. 446280 > > cached Mem > > > > but of course that memory is free once everything died. > > > > Any ideas? Should I go back to v4.19 to see if it happens there, too? > > linux-next includes very much the same code as drm-tip. There's nobody > magically reviewing the code more than it is reviewed for inclusion into > drm-tip, when it is fed into linux-next. So thinking linux-next would be > some way safer is an illusion. > > It sounds like having memory pressure expedites the corruption, which > should make it easier to reproduce and thus fix. > > So if you could please try drm-tip reproducing AND open a bug in Bugzilla. > If you are unwilling to do that, it is very difficult to help you > more. Website says I have to read and agree to two different pieces of legalesee, and I'd need to keep track of yet another password... so you can "communicate" with me. But you can already communicate with me, over email. I verified v4.19 is stable -- it worked ok for way more than two days it usually takes to crash. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: 4.20.0-rc6-next-20181210, v4.20-rc1: list_del corruption on thinkpad x220, graphics related?
Quoting Pavel Machek (2018-12-12 20:29:02) > Hi! > > > > > > > > > There's one similar for nouveau in Bugzilla, but it seems like > > > > > > > > a genuine > > > > > > > > memory corruption (1 bit flipped): > > > > > > > > > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880 > > > > > > > > > > > > > > > > Any extra information would be of use :) > > > > > > > > > > > > > > > > Regards, Joonas > > > > > > > > > > > > > > > > PS. Could you open a bug to Bugzilla, it'll help to collect the > > > > > > > > information in one consolidated place: > > > > > > > > > > > > > > > > https://01.org/linuxgraphics/documentation/how-report-bugs > > > > > > > > > > > > > > I prefer email... certainly for bugs that can't be reproduced. > > > > > > > > > > > > By adding it to the Bugzilla it may be recognized by somebody else > > > > > > who is experiencing a similar issue. Internet points are not > > > > > > deducted > > > > > > for submitting bugs in good faith, even if they get closed as > > > > > > NOTABUG. > > > > > > > > Well, your documentation suggests you'll deduce my internet points: > > > > > > > > Before filing the bug, please try to reproduce your issue with the > > > > latest kernel. Use the latest drm-tip branch from > > > > http://cgit.freedesktop.org/drm-tip and build as instructed on our > > > > Build Guide. > > > > > > > > :-) > > > > > > I'd prefer not to run drm-tip. I'll update to 2.6.20-rc5+ and see if > > > it re-appears (but it takes long time to reproduce :-(). > > > > If we can or can not reproduce the issue with drm-tip, is a very useful > > datapoint for us. If we can not reproduce, it'll be possible to bisect > > which commit fixed it, and backport that. On the other hand, if it's > > still reproducible, we know we're not spending time on something we > > already fixed, and the priority gets a bump. > > bisect ... is not practical on something that takes 2 days to reproduce. > > > > If you think it is useful, I can try to update my machine to > > > linux-next. > > > > linux-next is closer to drm-tip, so it's better. Do you have some > > specific reason for not wanting to run drm-tip (but linux-next is still > > ok)? > > I already have build/update scripts for -next, and I trust -next not > to store screenshots of my desktop in my master boot record :-). > > Anyway, it does happen with -next. This time, chromiums were running, > and crash happened minute? after I exited flightgear. It can be seen > in the logs. > > Oh and I might want to mention -- machine was rather deep in swap this > time, as in "mouse jumping when starting fgfs" and "could feel the > chromium being swapped back in". I might have had this situation > before, and just powercycled the machine "because it is so deep in > swap that it will not recover". > > top says: > > top - 19:18:24 up 2 days, 8:03, 2 users, load average: 3.02, 3.45, > 3.21 > Tasks: 141 total, 1 running, 86 sleeping, 0 stopped, 2 zombie > %Cpu(s): 18.8 us, 7.6 sy, 3.0 ni, 68.4 id, 1.3 wa, 0.0 hi, 0.9 > si, 0.0 st > KiB Mem: 5967968 total, 663244 used, 5304724 free,48876 > buffers > KiB Swap: 1681428 total, 170904 used, 1510524 free. 446280 > cached Mem > > but of course that memory is free once everything died. > > Any ideas? Should I go back to v4.19 to see if it happens there, too? linux-next includes very much the same code as drm-tip. There's nobody magically reviewing the code more than it is reviewed for inclusion into drm-tip, when it is fed into linux-next. So thinking linux-next would be some way safer is an illusion. It sounds like having memory pressure expedites the corruption, which should make it easier to reproduce and thus fix. So if you could please try drm-tip reproducing AND open a bug in Bugzilla. If you are unwilling to do that, it is very difficult to help you more. Regards, Joonas > > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
4.20.0-rc6-next-20181210, v4.20-rc1: list_del corruption on thinkpad x220, graphics related?
Hi! > > > > > > > There's one similar for nouveau in Bugzilla, but it seems like a > > > > > > > genuine > > > > > > > memory corruption (1 bit flipped): > > > > > > > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880 > > > > > > > > > > > > > > Any extra information would be of use :) > > > > > > > > > > > > > > Regards, Joonas > > > > > > > > > > > > > > PS. Could you open a bug to Bugzilla, it'll help to collect the > > > > > > > information in one consolidated place: > > > > > > > > > > > > > > https://01.org/linuxgraphics/documentation/how-report-bugs > > > > > > > > > > > > I prefer email... certainly for bugs that can't be reproduced. > > > > > > > > > > By adding it to the Bugzilla it may be recognized by somebody else > > > > > who is experiencing a similar issue. Internet points are not deducted > > > > > for submitting bugs in good faith, even if they get closed as > > > > > NOTABUG. > > > > > > Well, your documentation suggests you'll deduce my internet points: > > > > > > Before filing the bug, please try to reproduce your issue with the > > > latest kernel. Use the latest drm-tip branch from > > > http://cgit.freedesktop.org/drm-tip and build as instructed on our > > > Build Guide. > > > > > > :-) > > > > I'd prefer not to run drm-tip. I'll update to 2.6.20-rc5+ and see if > > it re-appears (but it takes long time to reproduce :-(). > > If we can or can not reproduce the issue with drm-tip, is a very useful > datapoint for us. If we can not reproduce, it'll be possible to bisect > which commit fixed it, and backport that. On the other hand, if it's > still reproducible, we know we're not spending time on something we > already fixed, and the priority gets a bump. bisect ... is not practical on something that takes 2 days to reproduce. > > If you think it is useful, I can try to update my machine to > > linux-next. > > linux-next is closer to drm-tip, so it's better. Do you have some > specific reason for not wanting to run drm-tip (but linux-next is still > ok)? I already have build/update scripts for -next, and I trust -next not to store screenshots of my desktop in my master boot record :-). Anyway, it does happen with -next. This time, chromiums were running, and crash happened minute? after I exited flightgear. It can be seen in the logs. Oh and I might want to mention -- machine was rather deep in swap this time, as in "mouse jumping when starting fgfs" and "could feel the chromium being swapped back in". I might have had this situation before, and just powercycled the machine "because it is so deep in swap that it will not recover". top says: top - 19:18:24 up 2 days, 8:03, 2 users, load average: 3.02, 3.45, 3.21 Tasks: 141 total, 1 running, 86 sleeping, 0 stopped, 2 zombie %Cpu(s): 18.8 us, 7.6 sy, 3.0 ni, 68.4 id, 1.3 wa, 0.0 hi, 0.9 si, 0.0 st KiB Mem: 5967968 total, 663244 used, 5304724 free,48876 buffers KiB Swap: 1681428 total, 170904 used, 1510524 free. 446280 cached Mem but of course that memory is free once everything died. Any ideas? Should I go back to v4.19 to see if it happens there, too? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html delme.gz Description: application/gzip signature.asc Description: Digital signature
Re: v4.20-rc1: list_del corruption on thinkpad x220, graphics related?
On Sat, 2018-12-08 at 12:24 +0100, Pavel Machek wrote: > On Sat 2018-12-08 12:13:46, Pavel Machek wrote: > > Hi! > > > > > > > > There's one similar for nouveau in Bugzilla, but it seems like a > > > > > > genuine > > > > > > memory corruption (1 bit flipped): > > > > > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880 > > > > > > > > > > > > Any extra information would be of use :) > > > > > > > > > > > > Regards, Joonas > > > > > > > > > > > > PS. Could you open a bug to Bugzilla, it'll help to collect the > > > > > > information in one consolidated place: > > > > > > > > > > > > https://01.org/linuxgraphics/documentation/how-report-bugs > > > > > > > > > > I prefer email... certainly for bugs that can't be reproduced. > > > > > > > > By adding it to the Bugzilla it may be recognized by somebody else > > > > who is experiencing a similar issue. Internet points are not deducted > > > > for submitting bugs in good faith, even if they get closed as > > > > NOTABUG. > > > > Well, your documentation suggests you'll deduce my internet points: > > > > Before filing the bug, please try to reproduce your issue with the > > latest kernel. Use the latest drm-tip branch from > > http://cgit.freedesktop.org/drm-tip and build as instructed on our > > Build Guide. > > > > :-) > > I'd prefer not to run drm-tip. I'll update to 2.6.20-rc5+ and see if > it re-appears (but it takes long time to reproduce :-(). If we can or can not reproduce the issue with drm-tip, is a very useful datapoint for us. If we can not reproduce, it'll be possible to bisect which commit fixed it, and backport that. On the other hand, if it's still reproducible, we know we're not spending time on something we already fixed, and the priority gets a bump. > If you think it is useful, I can try to update my machine to > linux-next. linux-next is closer to drm-tip, so it's better. Do you have some specific reason for not wanting to run drm-tip (but linux-next is still ok)? Regards, Joonas > > Best regards, > Pavel > -- Joonas Lahtinen Open Source Graphics Center Intel Corporation
Re: v4.20-rc1: list_del corruption on thinkpad x220, graphics related?
On Sat 2018-12-08 12:13:46, Pavel Machek wrote: > Hi! > > > > > > There's one similar for nouveau in Bugzilla, but it seems like a > > > > > genuine > > > > > memory corruption (1 bit flipped): > > > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880 > > > > > > > > > > Any extra information would be of use :) > > > > > > > > > > Regards, Joonas > > > > > > > > > > PS. Could you open a bug to Bugzilla, it'll help to collect the > > > > > information in one consolidated place: > > > > > > > > > > https://01.org/linuxgraphics/documentation/how-report-bugs > > > > > > > > I prefer email... certainly for bugs that can't be reproduced. > > > > > > By adding it to the Bugzilla it may be recognized by somebody else > > > who is experiencing a similar issue. Internet points are not deducted > > > for submitting bugs in good faith, even if they get closed as > > > NOTABUG. > > Well, your documentation suggests you'll deduce my internet points: > > Before filing the bug, please try to reproduce your issue with the > latest kernel. Use the latest drm-tip branch from > http://cgit.freedesktop.org/drm-tip and build as instructed on our > Build Guide. > > :-) I'd prefer not to run drm-tip. I'll update to 2.6.20-rc5+ and see if it re-appears (but it takes long time to reproduce :-(). If you think it is useful, I can try to update my machine to linux-next. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: v4.20-rc1: list_del corruption on thinkpad x220, graphics related?
Hi! > > > > There's one similar for nouveau in Bugzilla, but it seems like a genuine > > > > memory corruption (1 bit flipped): > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880 > > > > > > > > Any extra information would be of use :) > > > > > > > > Regards, Joonas > > > > > > > > PS. Could you open a bug to Bugzilla, it'll help to collect the > > > > information in one consolidated place: > > > > > > > > https://01.org/linuxgraphics/documentation/how-report-bugs > > > > > > I prefer email... certainly for bugs that can't be reproduced. > > > > By adding it to the Bugzilla it may be recognized by somebody else > > who is experiencing a similar issue. Internet points are not deducted > > for submitting bugs in good faith, even if they get closed as > > NOTABUG. Well, your documentation suggests you'll deduce my internet points: Before filing the bug, please try to reproduce your issue with the latest kernel. Use the latest drm-tip branch from http://cgit.freedesktop.org/drm-tip and build as instructed on our Build Guide. :-) > Feel free to copy from email to bugzilla :-). Hmm, so it seems it happened again today: Dec 8 11:45:01 duo CRON[29325]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Dec 8 11:46:42 duo org.mate.panel.applet.MateWeatherAppletFactory[3983]: (mateweather-applet-2:4242): GLib-CRITICAL **: Source ID 14603 was not found when attempting to remove it Dec 8 11:54:59 duo kernel: list_del corruption. prev->next should be 88019283ea28, but was 8801411a1c68 Dec 8 11:54:59 duo kernel: [ cut here ] Dec 8 11:54:59 duo kernel: kernel BUG at /data/fast/l/k/lib/list_debug.c:53! Dec 8 11:54:59 duo kernel: invalid opcode: [#1] SMP PTI Dec 8 11:54:59 duo kernel: CPU: 1 PID: 3428 Comm: Xorg Not tainted 4.20.0-rc1+ #4 Dec 8 11:54:59 duo kernel: Hardware name: LENOVO 42872WU/42872WU, BIOS 8DET74WW (1.44 ) 03/13/2018 Dec 8 11:54:59 duo kernel: RIP: 0010:__list_del_entry_valid+0x8e/0x90 Dec 8 11:54:59 duo kernel: Code: 16 88 d1 ff 0f 0b 48 89 fe 31 c0 48 c7 c7 08 75 5e 85 e8 03 88 d1 ff 0f 0b 48 89 fe 31 c0 48 c7 c7 40 75 5e 85 e8 f0 87 d1 ff <0f> 0b 55 48 89 d0 48 8b 52 08 48 89 e5 48 39 f2 75 19 48 8b 32 48 Dec 8 11:54:59 duo kernel: RSP: :c9223ac0 EFLAGS: 00213282 Dec 8 11:54:59 duo kernel: RAX: 0054 RBX: 880115a07c40 RCX: Dec 8 11:54:59 duo kernel: RDX: RSI: 88019e2653d8 RDI: 88019e2653d8 Dec 8 11:54:59 duo kernel: RBP: c9223ac0 R08: 880193a2ad10 R09: Dec 8 11:54:59 duo kernel: R10: 008e9088 R11: 2e6e6f6974707501 R12: 8801960cb240 Dec 8 11:54:59 duo kernel: R13: 88019283e900 R14: 880115a07ec0 R15: 88019283ea28 Dec 8 11:54:59 duo kernel: FS: () GS:88019e24(0063) knlGS:f79c4880 Dec 8 11:54:59 duo kernel: CS: 0010 DS: 002b ES: 002b CR0: 80050033 Dec 8 11:54:59 duo kernel: CR2: 086b0df8 CR3: 0001939f6004 CR4: 000606a0 Dec 8 11:54:59 duo kernel: Call Trace: Dec 8 11:54:59 duo kernel: i915_vma_move_to_active+0x1c3/0x510 Dec 8 11:54:59 duo kernel: ? i915_request_await_object+0xf4/0x280 Dec 8 11:54:59 duo kernel: i915_gem_do_execbuffer+0xe2f/0x10a0 Dec 8 11:54:59 duo kernel: ? find_held_lock+0x39/0xb0 Dec 8 11:54:59 duo kernel: ? kvmalloc_node+0x26/0x70 Dec 8 11:54:59 duo kernel: i915_gem_execbuffer2_ioctl+0x1b4/0x360 Dec 8 11:54:59 duo kernel: ? i915_gem_execbuffer_ioctl+0x290/0x290 Dec 8 11:54:59 duo kernel: drm_ioctl_kernel+0xaa/0xf0 Dec 8 11:54:59 duo kernel: drm_ioctl+0x323/0x3d0 Dec 8 11:54:59 duo kernel: ? i915_gem_execbuffer_ioctl+0x290/0x290 Dec 8 11:54:59 duo kernel: ? posix_ktime_get_ts+0xc/0x10 Dec 8 11:54:59 duo kernel: i915_compat_ioctl+0x37/0x40 Dec 8 11:54:59 duo kernel: __ia32_compat_sys_ioctl+0x429/0xe90 Dec 8 11:54:59 duo kernel: ? put_old_timespec32+0x9/0x10 Dec 8 11:54:59 duo kernel: ? __ia32_compat_sys_clock_gettime+0x67/0x90 Dec 8 11:54:59 duo kernel: do_int80_syscall_32+0x50/0x100 Dec 8 11:54:59 duo kernel: entry_INT80_compat+0x7d/0x82 Dec 8 11:54:59 duo kernel: RIP: 0023:0xf7fd5c42 Dec 8 11:54:59 duo kernel: Code: 65 8b 15 04 00 00 00 8b 0e 8b 0c ca 83 f9 ff 75 0c 89 04 24 89 f0 e8 b3 fe ff ff eb 05 8b 46 04 01 c8 83 c4 14 5b 5e c3 cd 80 8d b6 00 00 00 00 8d bc 27 00 00 00 00 8b 1c 24 c3 8d b6 00 00 Dec 8 11:54:59 duo kernel: RSP: 002b:fff1a014 EFLAGS: 00203292 ORIG_RAX: 0036 Dec 8 11:54:59 duo kernel: RAX: ffda RBX: 000a RCX: 40406469 Dec 8 11:54:59 duo kernel: RDX: fff1a0bc RSI: RDI: 40406469 Dec 8 11:54:59 duo kernel: RBP: 000a R08: R09: Dec 8 11:54:59 duo kernel: R10: R11:
