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 <[email protected]> [Eindhoven, NL]
Physics: Plasma simulations <[email protected]> [TU Eindhoven, NL]
Linux: SCSI, Security <[email protected]> [SuSE Nuernberg, DE]
(See mail header or public key servers for PGP2 and GPG public keys.)
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" <[email protected]>
To: "David Brownell" <[email protected]>
Cc: "Linux kernel list" <[email protected]>
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 <[email protected]> [Eindhoven, NL]
Physics: Plasma simulations <[email protected]> [TU Eindhoven, NL]
Linux: SCSI, Security <[email protected]> [SuSE Nuernberg, DE]
(See mail header or public key servers for PGP2 and GPG public keys.)
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 [email protected]
"A man alone in the forest talking to himself and
no women around to hear him. Is he still wrong?"
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 [email protected]
"A man alone in the forest talking to himself and
no women around to hear him. Is he still wrong?"