Panic when removing a SCSI device entry

[Kostik Belousov]

On Wed, May 18, 2011 at 08:04:29AM +0200, Joerg Wunsch wrote:
> As Joerg Wunsch wrote:
> 
> > > Please provide the full printout from the panic. Also, it would
> > > be useful to get the dump and do "p *dev" from the frame of
> > > destroy_devl(). I might need further information after the requested
> > > data is provided.
> > 
> > Unfortunately, I somehow cannot get the system to provide a coredump.
> 
> OK, it happened again last night, and I've got a DDB trace now.  The
> panic is at a slightly different location (in notify_destroy()), but
> still a null pointer (apparently, dev->si_name is NULL now).
> 
> [thread pid 33502 tid 100246 ]
> Stopped at      strlen+0x8:     cmpb    $0,0(%edx)
> db> bt
> Tracing pid 33502 tid 100246 td 0xc8be92e0
> strlen(0,c6dfc804,cc0b0e80,cc6e6800,e98804b8,...) at strlen+0x8
> notify(ce0dc900,0,0,cc6e6800,c05ac3fb,...) at notify+0x3f
> destroy_devl(e98804f4,c0470a2b,ce0dc900,c07e9284,1,...) at destroy_devl+0x17b
> destroy_dev(ce0dc900,c07e9284,1,0,e988051c,...) at destroy_dev+0x10
The ddb arguments printed might be wrong, or might point to the issue
causing the panic.

Please do "p *(struct cdev_priv *)0xe98804f4" and
"p *(struct cdev_priv *)0xce0dc900" from kgdb.

> sacleanup(cc0b0e80,c07f161b,12,0,e9880570,...) at sacleanup+0x8b
> camperiphfree(50,e9880994,c044b4de,e98809ac,c6e83c80,...) at camperiphfree+0x8f
> cam_periph_release_locked(cc0b0e80,0,cc0b0e80,e98809bc,c044b762,...) at cam_periph_release_locked+0x55
> cam_periph_release(cc0b0e80,14c,cc814200,e98809fc,e98809e8,...) at cam_periph_release+0x60
> saopen(cc814200,1,2000,c8be92e0,c07cc465,...) at saopen+0x263
> giant_open(cc814200,1,2000,c8be92e0,e9880b08,...) at giant_open+0x93
> devfs_open(e9880b08,e9880b30,c061c4fa,c0840e60,e9880b08,...) at devfs_open+0x102
> VOP_OPEN_APV(c0840e60,e9880b08,c075ad1a,cacbe788,0,...) at VOP_OPEN_APV+0x42
> vn_open_cred(e9880b78,e9880c2c,0,0,c7fba280,...) at vn_open_cred+0x4ba
> vn_open(e9880b78,e9880c2c,0,c7f49150,3,...) at vn_open+0x3b
> kern_openat(c8be92e0,ffffff9c,804a0bb,0,1,...) at kern_openat+0x12c
> kern_open(c8be92e0,804a0bb,0,0,6,...) at kern_open+0x35
> open(c8be92e0,e9880cec,0,c,28176088,...) at open+0x30
> syscallenter(c8be92e0,e9880ce4,e9880d1c,c07ad276,c8be92e0,...) at syscallenter+0x329
> syscall(e9880d28) at syscall+0x34
> Xint0x80_syscall() at Xint0x80_syscall+0x21
> syscall (5, FreeBSD ELF32, open), eip = 0x2817608f, esp = 0xbfbfec7c, ebp = 0xbfbfee18 ---
> db> show reg
> cs                0x20
> ds                0x28
> es                0x28
> fs                 0x8
> ss                0x28
> eax                  0
> ecx                0x8
> edx                  0
> ebx                0x2
> esp         0xe9880468
> ebp         0xe9880468
> esi         0xce0dc900
> edi         0xcc6e6800
> eip         0xc0620568  strlen+0x8
> efl            0x10202
> strlen+0x8:     cmpb    $0,0(%edx)
...

> As you can see, I've got a coredump this time, so I can run kgdb
> on that.
> 
> Currently, I'm compiling an INVARIANTS kernel, and will boot that one
> soon - though I wonder whether it really makes sense here, as the
> picture is different from last time (due to Kostik's suggested
> patch?).
I am pretty much sure that INVARIANTS kernel would hit the assert
about SI_NAMED flag being clear on destroy_devl() invocation.
We would have catched the issue earlier, with less interesting data
destroyed.

Anyway, please show the data I requested from the dump, and do
install INVARIANTS kernel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-scsi/attachments/20110518/bc803217/attachment.pgp