usbnet: prolific fails reset

usbnet: prolific fails reset

[Kurt Garloff]

[-- Attachment #1.1: Type: text/plain, Size: 873 bytes --]

Hi David,

got a USB network cable and was happy to see that it's supported by usbnet.
Good job, thanks!
usb0: register usbnet 001/004, Prolific PL-2301/PL-2302

However:
Upon ifconfig,
usb-uhci.c: interrupt, status 3, frame# 922
usb0: open reset fail (-32) usbnet 001/004, Prolific PL-2301/PL-2302

The ifconfig fails to up the interface, consequently.

Attached patch prevents the driver from returning the reset failure.
Guess what: The networking worked just fine then.
Probably the real solution is different ...

Patch is against 2.4.16.

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
Physics: Plasma simulations  <K.Garloff@Phys.TUE.NL>  [TU Eindhoven, NL]
Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)

[-- Attachment #1.2: usbnet-ignore-failed-reset-2416.diff --]
[-- Type: text/plain, Size: 295 bytes --]

--- linux/drivers/usb/usbnet.c~	Tue Dec 18 12:45:53 2001
+++ linux/drivers/usb/usbnet.c	Thu Apr 11 20:02:51 2002
@@ -1487,7 +1487,7 @@
 			retval,
 			dev->udev->bus->busnum, dev->udev->devnum,
 			info->description);
-		goto done;
+		//goto done;
 	}
 
 	// insist peer be connected

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: usbnet: prolific fails reset

[David Brownell]

Hi Kurt --

Thanks for the patch, I'll check it out.  "-32" should be a protocol
stall (Intel <asm/errno.h> I assume) that could be retried ... it'd
be better done in device-specific code (pl_reset) than in the
generic layer though.  I'll look at providing a "real" fix, and may
ask you to check out a different patch.

Those Prolific chips are perhaps not as finely crafted as I'd like
to see, there are a bunch of "gotchas" ... this could be a good
way to work around one of them, but I suspect you'll still find that
under load testing, you'll be glad the TX watchdog is so good
at barking (sometimes every few seconds)!

- Dave



----- Original Message ----- 
From: "Kurt Garloff" <kurt@garloff.de>
To: "David Brownell" <dbrownell@users.sourceforge.net>
Cc: "Linux kernel list" <linux-kernel@vger.kernel.org>
Sent: Friday, April 12, 2002 1:48 PM
Subject: usbnet: prolific fails reset


Hi David,

got a USB network cable and was happy to see that it's supported by usbnet.
Good job, thanks!
usb0: register usbnet 001/004, Prolific PL-2301/PL-2302

However:
Upon ifconfig,
usb-uhci.c: interrupt, status 3, frame# 922
usb0: open reset fail (-32) usbnet 001/004, Prolific PL-2301/PL-2302

The ifconfig fails to up the interface, consequently.

Attached patch prevents the driver from returning the reset failure.
Guess what: The networking worked just fine then.
Probably the real solution is different ...

Patch is against 2.4.16.

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
Physics: Plasma simulations  <K.Garloff@Phys.TUE.NL>  [TU Eindhoven, NL]
Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)

[BUG] oops with USB mass storage and DiskOnKey

[Tommi Kyntola]

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		kynde@ts.ray.fi
      "A man alone in the forest talking to himself and
       no women around to hear him. Is he still wrong?"

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		kynde@ts.ray.fi
      "A man alone in the forest talking to himself and
       no women around to hear him. Is he still wrong?"