Re: crash from ohci detach

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Thu, 3 Jan 2008 00:32:24 +0100
Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:

> On Wed, Jan 02, 2008 at 06:09:15PM -0500, Steven M. Bellovin wrote:
> > Eyeballing the panic, it says "ohci_intr:... bad address" followed
> > by a uvm_fault.  These are both consistent with a bad PTE...
> 
> Check if the interrupt handler is called after the memory mapped IO
> has been removed.
> 
I finally got a crash dump; however, running 'bt' doesn't work --
invalid PTE entry.

Here is the panic message, as extracted from the dump:

panic: ohci_softintr: addr 0x021e86b0 not found
Begin traceback...
uvm_fault(0xc0b00ac0, 0x21e8000, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c0542771 cs 8 eflags 10246 cr2 21e86b0 ilevel 3
panic: trap
Faulted in mid-traceback; aborting...

At the time of the crash (up-to-date i386-current, T42 laptop), the
network was wedged.  That is, I was no longer able to run IP over ppp
over ucom+umodem+uhub+ohci+xyzzy.  I hit ^C; things started to
terminate, but hung.  I hit ^C again; it said that it tcsetattr was
interrupted.  Then things died...

Prior to the PM branch merge, I had no problems with the card.  In
particular, it didn't wedge and didn't crash the system on detach
(though I sometimes saw crashes from just removing the card, as opposed
to my current practice of using drvctl first to detach it.)  I *think*
that the problems started before the vmlock2 merge, though I'm not 100%
certain.

I wonder if there's a race condition somewhere, causing an interrupt to
be lost and hence wedging the device.  Similar reasoning would apply to
the crash -- the device is in use but the higher-level code doesn't
think it is.  (The connection to the actual PM change may be
coincidental; it may have just changed timing.)


                --Steve Bellovin, http://www.cs.columbia.edu/~smb