Panic when removing a SCSI device entry

[Kostik Belousov]

On Sun, May 08, 2011 at 12:45:43PM +0200, Joerg Wunsch wrote:
> As Kostik Belousov wrote:
> 
> 
> > > and it's the indirection of *(dev)->si_siblings.le_prev that hits a
> > > NULL pointer.  Obviously, LIST_REMOVE doesn't anticipate that
> 
> > Is it NULL pointer dereference ? See below.
> 
> Yes, the fault address in the page fault is 0.
> 
> > 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.
> 
> The dmesg printout from the panic is:
> 
> sa0 at sym0 bus 0 scbus1 target 0 lun 0
> sa0: <QUANTUM DLT7000 2560> Removable Sequential Access SCSI-2 device 
> sa0: 20.000MB/s transfers (10.000MHz, offset 15, 16bit)
> (sa0:sym0:0:0:0): removing device entry
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x0
> fault code              = supervisor write, page not present
> instruction pointer     = 0x20:0xc052f346
> stack pointer           = 0x28:0xe98504a0
> frame pointer           = 0x28:0xe98504c4
> 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         = 52518 (mt)
> trap number             = 12
> panic: page fault
> cpuid = 0
> Uptime: 1d4h55m31s
> 
> (This includes the sa0 device arrival/removal messages.)
> 
> The disassembly of the respective part of destroy_devl() is:
> 
> 0xc052f32e <destroy_devl+30>:   test   $0x10,%dl
> 0xc052f331 <destroy_devl+33>:   je     0xc052f34c <destroy_devl+60>
> 0xc052f333 <destroy_devl+35>:   mov    0x4c(%esi),%edx
> 0xc052f336 <destroy_devl+38>:   test   %edx,%edx
> 0xc052f338 <destroy_devl+40>:   je     0xc052f340 <destroy_devl+48>
> 0xc052f33a <destroy_devl+42>:   mov    0x50(%esi),%eax
> 0xc052f33d <destroy_devl+45>:   mov    %eax,0x50(%edx)
> 0xc052f340 <destroy_devl+48>:   mov    0x50(%esi),%edx
> 0xc052f343 <destroy_devl+51>:   mov    0x4c(%esi),%eax
> 0xc052f346 <destroy_devl+54>:   mov    %eax,(%edx)
> 0xc052f348 <destroy_devl+56>:   andl   $0xffffffef,0x4(%esi)
> 
> I could perhaps setup a serial console, so to get at least DDB
> functioning if you'd like to see more details.  A remote GDB might
> also be possible, but will require more work (setting up the
> respective environment on a second machine).
Serial console is fine, I do want to see a backtrace.
There is also "show cdev" command in ddb, that might provide some
useful information.

INVARIANTS may be also useful, since the kernel might catch the corruption
earlier.
> 
> > Thing you may try meantime is the following patch.
> 
> OK, I'll do that tonight, so let's see how the subsequent nightly
> backups proceed.
> 
> -- 
> cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL
> 
> http://www.sax.de/~joerg/                        NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)
-------------- 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/20110508/3bc3344f/attachment.pgp