Kernel panic on usb disconnect?

[Olivier Houchard]

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).

Regards,

Olivier