Date: Sun, 12 Sep 2021 21:49:25 +0300 From: Vladimir Kondratyev <wulf@FreeBSD.org> To: pete@nomadlogic.org, x11@freebsd.org Subject: Re: Panic on drm-devel v5.5.19.g20210909 Message-ID: <ca3a9dce-96e2-9667-fcde-88ce50df82b5@FreeBSD.org> In-Reply-To: <aaee7785-5c2c-2c9f-0e18-8f1f43cddfbc@nomadlogic.org> References: <f38c9e97-1d82-1842-f2c2-13f29f0f666a@nomadlogic.org> <e7bed6f0-d705-c880-5233-58f8339d33a5@FreeBSD.org> <ba76ba08-53ac-49b7-23da-cc885b5126d1@nomadlogic.org> <aaee7785-5c2c-2c9f-0e18-8f1f43cddfbc@nomadlogic.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12.09.2021 03:47, Pete Wright via x11 wrote: > > > On 9/11/21 9:53 AM, Pete Wright via freebsd-x11 wrote: >> >> >> On 9/11/21 8:17 AM, Vladimir Kondratyev wrote: >>> On 11.09.2021 02:53, Pete Wright via freebsd-x11 wrote: >>>> hello, >>>> i got the following panic after upgrading my current laptop to >>>> drm-devel-v5.5.19.g20210909 (3df6598adf625a18a7c762b2d48b4c3dd7925838): >>>> >>>> panic: acquiring blockable sleep lock with spinlock or critical section >>>> held (sleep mutex) linux_wq_exec @ >>>> /usr/home/pete/git/freebsd/sys/compat/linuxkpi/common/src/linux_work.c:105 >>>> >>>> cpuid = 5 >>>> time = 1631315668 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>>> 0xfffffe011d086060 >>>> vpanic() at vpanic+0x187/frame 0xfffffe011d0860c0 >>>> panic() at panic+0x43/frame 0xfffffe011d086120 >>>> witness_checkorder() at witness_checkorder+0xe78/frame >>>> 0xfffffe011d0862f0 >>>> __mtx_lock_flags() at __mtx_lock_flags+0x94/frame 0xfffffe011d086340 >>>> linux_queue_work_on() at linux_queue_work_on+0x9a/frame >>>> 0xfffffe011d086380 >>>> dma_fence_signal() at dma_fence_signal+0xc0/frame 0xfffffe011d0863d0 >>>> dma_resv_add_shared_fence() at dma_resv_add_shared_fence+0x96/frame >>>> 0xfffffe011d086420 >>>> i915_vma_move_to_active() at i915_vma_move_to_active+0x7e/frame >>>> 0xfffffe011d086460 >>>> i915_gem_do_execbuffer() at i915_gem_do_execbuffer+0x13d7/frame >>>> 0xfffffe011d086670 >>>> i915_gem_execbuffer2_ioctl() at i915_gem_execbuffer2_ioctl+0x195/frame >>>> 0xfffffe011d0866e0 >>>> drm_ioctl_kernel() at drm_ioctl_kernel+0x72/frame 0xfffffe011d086730 >>>> drm_ioctl() at drm_ioctl+0x2bf/frame 0xfffffe011d086820 >>>> linux_file_ioctl() at linux_file_ioctl+0x297/frame 0xfffffe011d086880 >>>> kern_ioctl() at kern_ioctl+0x202/frame 0xfffffe011d0868f0 >>>> sys_ioctl() at sys_ioctl+0x124/frame 0xfffffe011d0869c0 >>>> amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe011d086af0 >>>> fast_syscall_common() at fast_syscall_common+0xf8/frame >>>> 0xfffffe011d086af0 >>>> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80f1ae3ca, rsp = >>>> 0x7fffffffc8d8, rbp = 0x7fffffffc970 --- >>>> KDB: enter: panic >>>> >>>> >>>> I have a core and and additional info if that'll help debug this issue. >>>> it happened three times while doing normal web+shell work. i've >>>> reverted to the commit previous this one and it looks like the >>>> system no >>>> longer panic's. >>>> >>>> -pete >>>> >>> Try to revert this commit: >>> https://github.com/freebsd/drm-kmod/commit/787ffa8c48ecd02310ce2ec27c4b84d1898201e5 >>> >>> >> Thanks for the heads up on that. Just reverted on my system and it >> seems better on my end now. Let me know if there is any additional >> debugging i can do to fix the original sleep lock issue. >> > > hrm - spoke too soon, just had the same panic with that commit > reverted. made it most of the day with several suspend/resume's as well > as web browsing and watching videos. > > -pete > Could you make backtrace with kgdb? One from your mail is useless as kdb skipped all functions declared as static. just type # kgdb /boot/kernel/kernel /var/crash/vmcore.last (kgdb) bt -- WBR Vladimir Kondratyev
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ca3a9dce-96e2-9667-fcde-88ce50df82b5>