Re: panic in drm or vt or deadlock on mutex or ...

On Thu, Feb 04, 2021 at 10:50:29AM +0100, Emmanuel Vadot wrote:
> On Wed, 3 Feb 2021 08:03:24 -0800
> Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote:
> 
> > On Wed, Feb 03, 2021 at 10:42:21AM +0200, Andriy Gapon wrote:
> > > On 03/02/2021 07:08, Steve Kargl wrote:
> > > > Fatal trap 12: page fault while in kernel mode
> > > > cpuid = 0; apic id = 00
> > > > fault virtual address	= 0xccccc374
> > > > fault code		= supervisor read data, page not present
> > > > instruction pointer	= 0x20:0xef411f
> > > > stack pointer	        = 0x28:0x4074e97c
> > > > frame pointer	        = 0x28:0x4074e988
> > > > code segment		= base 0x0, limit 0xfffff, type 0x1b
> > > > 			= DPL 0, pres 1, def32 1, gran 1
> > > > processor eflags	= interrupt enabled, resume, IOPL = 0
> > > > current process		= 91696 (chrome)
> > > > trap number		= 12
> > > ...
> > > > panic: page fault
> > > > cpuid = 0
> > > > time = 1612328062
> > > > KDB: stack backtrace:
> > > > db_trace_self_wrapper(2,4074e93c,c,0,4074e800,...) at db_trace_self_wrapper+0x28/frame 0x4074e7d4
> > > > vpanic(f9d603,4074e80c,4074e80c,4074e834,f6e2b7,...) at vpanic+0x11a/frame 0x4074e7ec
> > > > panic(f9d603,fe16b8,0,fffff,ccccc39b,...) at panic+0x14/frame 0x4074e800
> > > > trap_fatal(1327100,0,c95893,78f03f4,4074e860,...) at trap_fatal+0x347/frame 0x4074e834
> > > > trap_pfault(ccccc374,0,0) at trap_pfault+0x30/frame 0x4074e864
> > > > trap(4074e93c,8,28,28,0,...) at trap+0x381/frame 0x4074e930
> > > > calltrap() at 0xffc0319f/frame 0x4074e930
> > > > --- trap 0xc, eip = 0xef411f, esp = 0x4074e97c, ebp = 0x4074e988 ---
> > > > vm_radix_lookup(28c7b884,2,0) at vm_radix_lookup+0x7f/frame 0x4074e988
> > > > vm_page_lookup(28c7b854,2,0) at vm_page_lookup+0x15/frame 0x4074e99c
> > > > vm_fault(24ed8d58,3488b000,2,0,4074eab0) at vm_fault+0x839/frame 0x4074ea48
> > > > vm_fault_quick_hold_pages(24ed8d58,34889f00,8000,2,4074eaa8,12) at vm_fault_quick_hold_pages+0x122/frame 0x4074ea88
> > > > vn_io_fault1(247f4380) at vn_io_fault1+0x214/frame 0x4074eb44
> > > > vn_io_fault(2f5a58e8,4074ebc8,262c1e00,0,247f4380) at vn_io_fault+0x1c4/frame 0x4074eb7c
> > > > dofileread(2f5a58e8,4074ebc8,ffffffff,ffffffff,0) at dofileread+0x6d/frame 0x4074ebac
> > > > sys_read(247f4380,247f4618,343fb000,247f4380,40516068,...) at sys_read+0x67/frame 0x4074ec00
> > > > syscall(4074ece8,3b,3b,3b,2d130d1c,...) at syscall+0x17d/frame 0x4074ecdc
> > > > Xint0x80_syscall() at 0xffc033f9/frame 0x4074ecdc
> > > > --- syscall (881410048), eip = 0x2d086faf, esp = 0xfa1e339c, ebp = 0xfa1e33c8 ---
> > > > KDB: enter: panic
> > > 
> > > This is the crash.
> > > The DRM mutex noise is just noise (but it would be good to get rid of it).
> > 
> > OK.  It only happens with drm.
> > 
> > What other info is needed to help track this down?
> > I have kernel.debug, vmcore.0, and core.txt.0, so 
> > can use kgdb if someone would like more information.
> 
>  Only happens with drm when you do what ?
> 

Well, for this panic, I tried to start chrome.
The system has also panicked with simply doing
'kldload i915kms.ko'.

-- 
Steve