Pete Zaitcev wrote:
[...]
>> >>EIP; e0d24da0 <[sr_mod]sr_registered+22deec/22e1ac>   <=====
> 
> 
>>Trace; e0a3b9cf <[usb-uhci]process_interrupt+21f/260>
>>Trace; e0a3bde4 <[usb-uhci]process_urb+254/260>
>>Trace; e0207ee9 <_end+1fe721a5/2064e31c>
>>Trace; e0a3be87 <[usb-uhci]uhci_interrupt+97/170>
>>Trace; c010a848 <handle_IRQ_event+48/80>
>>Trace; c010aa33 <do_IRQ+83/f0>
>>Trace; c0107150 <default_idle+0/40>
>>Trace; c01071f4 <cpu_idle+34/40>
> 
> 
> Hmm. This looks fishy, because sr_registered is not a function.

Yeah it's not reliable :/  How about [snd-seq-midi].data.end
(the finding if don't I don't unload any modules. After every
module unload the finding changes.)

> Does the same happen after "echo /bin/true > /proc/sys/kernel/hotplug"?

Doesn't change anything:
Do the "echo /bin/true > /proc/sys/kernel/hotplug", plug the
disk, manually do "/sbin/modprobe usb-storage", watch the same
scene about interrupts etc, unplug the disk (this time no
hotplug magic is in effect), "/sbin/modprobe -r usb-storage"
and panic. I guess the device is never released from the scsi
layer??? The attached file has the panic info (unreliable as
before; and yes it's nvidia-tainted, but nvidia is irrelevant
it happens reliably all the time).

 > Maybe your hotplug setup yanks a module. I heard some crazy distro
 > did that on unplug.

This is Redhat-9, using hotplug-2004_04_01-4 from rawhide.
I remember the very same failures when I was using Mandrake9.0,
so the distro change doesn't seem to make a difference (yet).

I still strongly beleive that we need a blacklisting mechanism
for crazy cases like this.

Regards,
Ozkan Sezer