Re: [BUG] oops with USB mass storage and DiskOnKey

[Tommi Kyntola]

Just a minor additional note, by rmmod'ing usb-storage module before 
plugging it back in this mount/umount hangs go away. 

Worth noting may also be that where 2.4.19-pre6 oopses with 2nd mount
the 2.4.18 (and for example RedHat flavor 2.4.9-31) behaves slightly 
differently, the mount (after being plugged out) succeeds, but the
umount after that will hang instead.

If there are any "Could you do/try this-and-that ?", I'll be glad to help.

> Reproducible mount/sync hang which results in oops with DiskOnKey.
> 
> After unplugging a DiskOnKey USB mass storage device (after being plugged 
> in and mounted/umounted atleast once) and then plugging it back in, any 
> mount for that device will hang (and after that all calls to sync 
> will/would hang, too) And after 20ish seconds it oopses...
> 
> Here's the oops with 2.4.19-pre6, what was done was :
> mount /dev/sda1 /mnt/diskonkey
> umout /mnt/diskonkey
> *** unplugged the DoK and plugged it right back in ***
> mount /dev/sda1 /mnt/diskonkey
> 
> straced : 
> mount("/dev/sda1","/mnt/diskonkey","ext2",MS_NOSUID|MS_NODEV|0xc0ed0000,0x805b140 
> -------------------------------------------------------------------------
> 
> Unable to handle kernel paging request at virtual address 6c2d7479
> *pde = 00000000
> Oops: 0000
> CPU:    0
> EIP:    0010:[<d0851269>]    Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010202
> eax: 6c2d7461   ebx: cf658c00   ecx: cd837e5c   edx: cf2228c0
> esi: 00000190   edi: cd837e58   ebp: cd836000   esp: cd837e4c
> ds: 0018   es: 0018   ss: 0018
> Process scsi_eh_0 (pid: 1372, stackpage=cd837000)
> Stack: d0851352 cf2228c0 cd837e68 00000000 cd837e70 cd837e70 00000000 00000000
>        cd836000 cd837e5c cd837e5c cf658c00 80000000 ce47ee40 00000000 d08514b9
>        cf2228c0 00000190 cd837e98 00000246 00000000 ce47ee40 00000190 cf658c00
> Call Trace: [<d0851352>] [<d08514b9>] [<d0851554>] [<d085f484>] [<d0852371>]   
>   [<d0855016>] [<c011543b>] [<d0962359>] [<d0917c0d>] [<d0918313>] [<d091882a>]
>   [<c010879e>] [<c0110018>] [<c0107036>] [<d0918730>]
> Code: 8b 40 18 85 c0 74 06 52 ff 50 0c 5a c3 b8 ed ff ff ff c3 8d
> 
> >>EIP; d0851269 <[usbcore]usb_submit_urb+19/30>   <=====
> Trace; d0851352 <[usbcore]usb_start_wait_urb+82/190>
> Trace; d08514b9 <[usbcore]usb_internal_control_msg+59/70>
> Trace; d0851554 <[usbcore]usb_control_msg+84/a0>
> Trace; d085f484 <[usbcore]usb_address0_sem+0/14>
> Trace; d0852371 <[usbcore]usb_set_address+31/40>
> Trace; d0855016 <[usbcore]usb_reset_device+c6/2f7>
> Trace; c011543b <call_console_drivers+eb/100>
> Trace; d0962359 <[usb-storage]bus_reset+89/1e0>
> Trace; d0917c0d <[scsi_mod]scsi_try_bus_reset+3d/90>
> Trace; d0918313 <[scsi_mod]scsi_unjam_host+383/7a0>
> Trace; d091882a <[scsi_mod]scsi_error_handler+fa/160>
> Trace; c010879e <ret_from_fork+6/20>
> Trace; c0110018 <pcibios_lookup_irq+138/2a0>
> Trace; c0107036 <kernel_thread+26/30>
> Trace; d0918730 <[scsi_mod]scsi_error_handler+0/160>
> Code;  d0851269 <[usbcore]usb_submit_urb+19/30>   <=====
>    0:   8b 40 18                  mov    0x18(%eax),%eax   <=====
> Code;  d085126c <[usbcore]usb_submit_urb+1c/30>
>    3:   85 c0                     test   %eax,%eax
> 
> ...
> 
> I'm not sure wether this is a known issue or just induced by 
> possible bugs in DiskOnKey. I've tested this thing with uhci (bx 
> chipset) and ohci (Ali chipset) boxen with same results.
> 
> I've had this same issue with kernel versions 2.4.X (vanilla aswell 
> as -ac tree) from atleast 2.4.9 up to 2.4.19-pre6 aswell as 2.5.0 up to 
> IIRC 2.5.7 (possibly just up to 2.5.6).
> 
> I can post the .config and post the full ksymoops and look into it more 
> if this indeed is a new issue and not just some personal fsck-up due to 
> ignorance. 
> 
> 

-- 
Tommi Kynde Kyntola		[e-mail]
      "A man alone in the forest talking to himself and
       no women around to hear him. Is he still wrong?"