Date: Sun, 8 May 2011 12:45:43 +0200 From: Joerg Wunsch <freebsd-scsi@uriah.heep.sax.de> To: freebsd-scsi@freebsd.org Subject: Re: Panic when removing a SCSI device entry Message-ID: <20110508104543.GB5364@uriah.heep.sax.de> In-Reply-To: <20110508094509.GT48734@deviant.kiev.zoral.com.ua> References: <20110508085314.GA5364@uriah.heep.sax.de> <20110508094509.GT48734@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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).
> 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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110508104543.GB5364>