Kernel panic on usb disconnect?

[Bernd Walter]

On Tue, Aug 07, 2007 at 05:27:29PM +0200, Olivier Houchard wrote:
> On Tue, Aug 07, 2007 at 04:52:41PM +0200, Bernd Walter wrote:
> > On Tue, Aug 07, 2007 at 04:18:33PM +0300, Krassimir Slavchev wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > Bernd Walter wrote:
> > > > On Tue, Aug 07, 2007 at 03:02:41PM +0300, Krassimir Slavchev wrote:
> > > >> -----BEGIN PGP SIGNED MESSAGE-----
> > > >> Hash: SHA1
> > > >>
> > > >> This is on at91rm9200 with latest -current
> > > >>
> > > >> On connect:
> > > >>
> > > >> umass0: <Corsair Flash Voyager, class 0/0, rev 2.00/11.00, addr 2> on uhub0
> > > >> umass0: SCSI over Bulk-Only; quirks = 0x0000
> > > >> umass0:0:0:-1: Attached to scbus0
> > > >> Expensive timeout(9) function: 0xc00357f0(0xc07e6c00) 0.002746582 s
> > > >>
> > > >> On disconnect:
> > > >>
> > > >> umass0: BBB reset failed, IOERROR
> > > >> umass0: at uhub0 port 1 (addr 2) disconnected
> > > > 
> > > > This problem is not arm specific.
> > > > You have to unmount umass devices befor you can disconnect them.
> > > > 
> > > 
> > > Yes, I know, the device is not mounted. Unfortunately I can't reproduce
> > > this on i386.
> > 
> > My fault - I saw the XPT and assumed it was still mounted.
> > But is it Ok that badaddr_read panics?
> > I though it is there to tamper with possible dangerous addresses.
> > 
> 
> Actually the backtrace is not accurate, because the symbol table isn't loaded.
> You can still use gdb to know what badaddr_read+0x1f4 really is. Also, you'll
> note the badaddr_read call happens after the trap occurs (data_abort_handler).

Ups - that's the second time I'd read the panic wrong.
I should continue working after the first ETOSLEEPY...

-- 
B.Walter                http://www.bwct.de      http://www.fizon.de
bernd at bwct.de           info at bwct.de            support at fizon.de