Bug 5744 - usbnet connection to sharp zaurus SL-5600 buggy since kernel 2.6.14
Summary: usbnet connection to sharp zaurus SL-5600 buggy since kernel 2.6.14
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: David Brownell
URL:
Keywords:
Depends on:
Blocks: USB
  Show dependency tree
 
Reported: 2005-12-14 09:07 UTC by Bj
Modified: 2006-05-17 09:32 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.14/2.6.15
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
experimental mtu patch (2.05 KB, patch)
2006-05-04 15:09 UTC, David Brownell
Details | Diff
output of lsusb -v (3.05 KB, text/plain)
2006-05-10 13:58 UTC, Paul Worrall
Details

Description Bj 2005-12-14 09:07:31 UTC
Most recent kernel where this bug did not occur: 2.6.14
Distribution: Gentoo (and others)
Hardware Environment: x86

Problem Description:
Since kernel-2.6.14 (vanilla) connections to my Sharp Zaurus SL-5600 are hanging
as soon as there is a little traffic over the interface.
Traffic means that the output of dmesg over ssh is causing the connection to
break. The connection is not useable.
The problem goes away as soon as I boot into a 2.6.13 kernel.
I normally use gentoo-sources, but got the same problem with vanilla-2.6.14 and
vanilla-2.6.15-rc5.
I found another user in #openzaurus on freenode who has the same problem.
This may be specific to this zaurus model, as I don't know anyone who has this
problem with another zaurus.
On the SL-5600 kernel 2.4.18 is running.

I compiled in usb-debug support and this is the output of dmesg that might
interest you:

zaurus 3-3:1.0: usb_probe_interface
zaurus 3-3:1.0: usb_probe_interface - got id
usb0: register 'zaurus' at usb-0000:00:02.1-3, pseudo-MDLM (BLAN) device,
4a:03:bf:a6:90:0a
hub 3-0:1.0: state 5 ports 3 chg 0000 evt 0008
usb0: rxqlen 0 --> 4
usb0: rxqlen 0 --> 4
ohci_hcd 0000:00:02.1: urb ed6b0ae0 path 3 ep1in 83160000 cc 8 --> status -75
ohci_hcd 0000:00:02.1: urb ed6b08e0 path 3 ep1in 83160000 cc 8 --> status -75
ohci_hcd 0000:00:02.1: urb ed6b0a60 path 3 ep1in 82160000 cc 8 --> status -75
ohci_hcd 0000:00:02.1: urb ed6b0ae0 path 3 ep1in 82160000 cc 8 --> status -75
ohci_hcd 0000:00:02.1: urb ed6b08e0 path 3 ep1in 82160000 cc 8 --> status -75
ohci_hcd 0000:00:02.1: urb ed6b0a60 path 3 ep1in 82160000 cc 8 --> status -75
ohci_hcd 0000:00:02.1: urb ed6b0ae0 path 3 ep1in 82160000 cc 8 --> status -75

Steps to reproduce:
- Boot a 2.6.14 kernel
- Connect your sharp zaurus SL-5600 (don't know whether this problems occurs on
other zauruses too) to your PC via USB
- Bring usb0 up and ssh into it
- Get some output, try dmesg or ls /etc/ . See how the console hangs.
Comment 1 Bj 2006-01-22 04:53:06 UTC
Problem is still there in kernel-2.6.15.
From /var/log/messages:

Jan 22 13:29:28 AMD2800 usb 3-3: new full speed USB device using ohci_hcd and
address 11
Jan 22 13:29:28 AMD2800 ohci_hcd 0000:00:02.1: GetStatus roothub.portstatus [2]
= 0x00100103 PRSC PPS PES CCS
Jan 22 13:29:28 AMD2800 usb 3-3: ep0 maxpacket = 16
Jan 22 13:29:28 AMD2800 usb 3-3: skipped 4 descriptors after interface
Jan 22 13:29:28 AMD2800 usb 3-3: default language 0x0409
Jan 22 13:29:28 AMD2800 usb 3-3: new device strings: Mfr=1, Product=2,
SerialNumber=0
Jan 22 13:29:28 AMD2800 usb 3-3: Product: SL-5600
Jan 22 13:29:28 AMD2800 usb 3-3: Manufacturer: Sharp
Jan 22 13:29:28 AMD2800 usb 3-3: hotplug
Jan 22 13:29:28 AMD2800 usb 3-3: adding 3-3:1.0 (config #1, interface 0)
Jan 22 13:29:28 AMD2800 usb 3-3:1.0: hotplug
Jan 22 13:29:28 AMD2800 zaurus 3-3:1.0: usb_probe_interface
Jan 22 13:29:28 AMD2800 zaurus 3-3:1.0: usb_probe_interface - got id
Jan 22 13:29:28 AMD2800 usb0: register 'zaurus' at usb-0000:00:02.1-3,
pseudo-MDLM (BLAN) device, 22:57:24:8f:89:cb
Jan 22 13:29:28 AMD2800 drivers/usb/core/inode.c: creating file '011'
Jan 22 13:29:28 AMD2800 hub 3-0:1.0: state 5 ports 3 chg 0000 evt 0008
Jan 22 13:29:30 AMD2800 usb0: rxqlen 0 --> 4
Jan 22 13:49:38 AMD2800 usb0: rxqlen 0 --> 4
Jan 22 13:49:52 AMD2800 ohci_hcd 0000:00:02.1: urb db3a42c0 path 3 ep1in
82160000 cc 8 --> status -75
Jan 22 13:49:52 AMD2800 ohci_hcd 0000:00:02.1: urb db3a4540 path 3 ep1in
82160000 cc 8 --> status -75
Jan 22 13:49:53 AMD2800 ohci_hcd 0000:00:02.1: urb db3a4340 path 3 ep1in
82160000 cc 8 --> status -75
Jan 22 13:49:53 AMD2800 ohci_hcd 0000:00:02.1: urb db3a42c0 path 3 ep1in
82160000 cc 8 --> status -75
Jan 22 13:49:54 AMD2800 ohci_hcd 0000:00:02.1: urb db3a45c0 path 3 ep1in
82160000 cc 8 --> status -75
Jan 22 13:49:56 AMD2800 ohci_hcd 0000:00:02.1: urb db3a42c0 path 3 ep1in
82160000 cc 8 --> status -75
Jan 22 13:49:59 AMD2800 ohci_hcd 0000:00:02.1: urb db3a4540 path 3 ep1in
82160000 cc 8 --> status -75
Jan 22 13:50:06 AMD2800 ohci_hcd 0000:00:02.1: urb db3a45c0 path 3 ep1in
82160000 cc 8 --> status -75
Jan 22 13:50:19 AMD2800 ohci_hcd 0000:00:02.1: urb db3a4340 path 3 ep1in
82160000 cc 8 --> status -75
Jan 22 13:50:46 AMD2800 ohci_hcd 0000:00:02.1: urb db3a42c0 path 3 ep1in
82160000 cc 8 --> status -75
Comment 2 Greg Kroah-Hartman 2006-03-06 10:44:13 UTC
David, any ideas?
Comment 3 Henry von Tresckow 2006-04-06 13:45:07 UTC
Changing the MTU size to 576 on either side of the link seems to make the
connection usable again. Tested on Fedora4 with 2.6.16-1 kernel.
Comment 4 Bj 2006-04-21 14:03:46 UTC
Confirmed, that helps.

Additionaly this problem does only exist in one direction.
I can browse the web and download megabytes from the PDA through the interface.
Only sending data to my PC seems to make the problem.
Comment 5 Paul Worrall 2006-05-03 13:30:38 UTC
I noticed that usbd0 on my SL-5500 gets an MTU of 1500 but usb0 on the PC end 
of the link gets 1494.  The symptoms I get are an inability to download files 
on the Zaurus bigger than about 1kB (smaller files work OK).  Setting the MTU 
on usbd0 to 1494 fixes the problem.  I'm using kernel 2.6.16-gentoo-r6 on the 
PC and 2.4.18-rmk7-pxa3-embedix on the PDA.
Comment 6 Paul Worrall 2006-05-03 14:00:23 UTC
I should have mentioned that I am using ethernet bridging on the PC to give 
the PDA access to the network.  If I use NAT, the difference in MTU doesn't 
seem to cause a problem.
Comment 7 David Brownell 2006-05-03 14:04:18 UTC
Sounds like yet another bug in the "embedix" code; if you 
update to a current version of OpenEmbedded/HH.org code 
on your Zaurus, does the problem still appear?  I recall 
confusion there about MTUs, as well as a lot of other 
basic stuff. 
 
Please provide "lsusb -v" output showing your Z, and use 
the "usbutils 0.72" version of that tool. 
Comment 8 David Brownell 2006-05-03 14:05:50 UTC
Oh, also include for BOTH ENDS OF THE LINK the "ifconfig" output. 
Comment 9 David Brownell 2006-05-04 15:09:15 UTC
Created attachment 8027 [details]
experimental mtu patch

Please see if this patch improves anything...
Comment 10 Bj 2006-05-10 00:34:36 UTC
Great, with that patch it works without changing the MTU.
Comment 11 Paul Worrall 2006-05-10 13:58:36 UTC
Created attachment 8087 [details]
output of lsusb -v
Comment 12 Paul Worrall 2006-05-10 14:49:26 UTC
I'm afraid gentoo has only usbutils 0.71, is that good enough?

gentoo # ifconfig usb0
usb0      Link encap:Ethernet  HWaddr 4E:6B:FB:0F:0F:4C
          UP BROADCAST RUNNING MULTICAST  MTU:1494  Metric:1
          RX packets:48 errors:0 dropped:0 overruns:0 frame:0
          TX packets:73 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5507 (5.3 Kb)  TX bytes:8377 (8.1 Kb)

zaurus # ifconfig usbd0
usbd0     Link encap:Ethernet  HWaddr 40:00:01:00:00:01
          inet addr:192.168.2.50  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:63 errors:0 dropped:0 overruns:0 frame:0
          TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:6451 (6.2 KiB)  TX bytes:4520 (4.4 KiB)

The above was taken _after_ applying your patch.

I am using 2.4.18-rmk7-pxa3-embedix on the zaurus which comes with the current 
version of OpenZaurus (3.5.4).  On the desktop I've got 2.6.16-gentoo-r6.
Comment 13 Bj 2006-05-17 04:31:16 UTC
So, what is holding you back from bringing this patch into mainline and marking
this bug as resolved?
Comment 14 David Brownell 2006-05-17 09:32:52 UTC
patch is now in greg's queue, and should be in the next mm patchset 

Note You need to log in before you can comment on or make changes to this bug.