RobertCNelson / stable-kernel

MIT License
74 stars 39 forks source link

Usb issues #24

Open aferre opened 11 years ago

aferre commented 11 years ago

On a beagleboard:

uname -a : Linux arm 3.7.1-x4 #1 SMP Fri Jan 25 12:52:47 CET 2013 armv7l armv7l armv7l GNU/Linux

lsb_release -a: Distributor ID: Ubuntu Description: Ubuntu 12.10 Release: 12.10 Codename: quantal

symptoms:

[3098.487487] ftdi_sio ttyUSB5: error from flowcontrol urb
[63109.495178] ftdi_sio ttyUSB5: ftdi_set_termios FAILED to set databits/stopbits/parity
[63110.502929] ftdi_sio ttyUSB5: ftdi_set_termios urb failed to set baudrate
[63120.510437] ftdi_sio ttyUSB5: urb failed to set to rts/cts flow control
[63130.518707] ftdi_sio ttyUSB5: urb failed to set to rts/cts flow control
[63135.526153] ftdi_sio ttyUSB5: urb failed to set to rts/cts flow control
[63140.534149] ftdi_sio ttyUSB5: urb failed to set to rts/cts flow control
[63145.542236] ftdi_sio ttyUSB5: urb failed to set to rts/cts flow control
[63150.549438] ftdi_sio ttyUSB5: urb failed to set to rts/cts flow control
[63455.660095] ftdi_sio ttyUSB5: urb failed to set to rts/cts flow control

Tried to reset the usb bus using ioctl USBDEVFS_RESET, but the device then fails to enumerate.

Apr 12 09:12:00 arm kernel: [64992.774658] ftdi_sio ttyUSB5: FTDI USB Serial Device converter now disconnected from ttyUSB5
Apr 12 09:12:00 arm kernel: [64992.774871] ftdi_sio 1-2.4:1.0: device disconnected
Apr 12 09:12:00 arm kernel: [64992.868011] usb 1-2.4: reset full-speed USB device number 4 using ehci-omap
Apr 12 09:12:15 arm kernel: [65007.954162] usb 1-2.4: device descriptor read/64, error -110
Apr 12 09:12:30 arm kernel: [65023.157165] usb 1-2.4: device descriptor read/64, error -110
Apr 12 09:12:31 arm kernel: [65023.360229] usb 1-2.4: reset full-speed USB device number 4 using ehci-omap
Apr 12 09:12:46 arm kernel: [65038.446289] usb 1-2.4: device descriptor read/64, error -110
Apr 12 09:13:01 arm kernel: [65053.649108] usb 1-2.4: device descriptor read/64, error -110
Apr 12 09:13:01 arm kernel: [65053.852447] usb 1-2.4: reset full-speed USB device number 4 using ehci-omap
Apr 12 09:13:11 arm kernel: [65064.273773] usb 1-2.4: device not accepting address 4, error -110
Apr 12 09:13:12 arm kernel: [65064.368133] usb 1-2.4: reset full-speed USB device number 4 using ehci-omap
Apr 12 09:13:22 arm kernel: [65074.789337] usb 1-2.4: device not accepting address 4, error -110
Apr 12 09:13:22 arm kernel: [65074.802368] usb 1-2.4: USB disconnect, device number 4
Apr 12 09:13:22 arm kernel: [65074.899169] usb 1-2.4: new full-speed USB device number 8 using ehci-omap
Apr 12 09:13:37 arm kernel: [65089.985076] usb 1-2.4: device descriptor read/64, error -110
Apr 12 09:13:52 arm kernel: [65105.187835] usb 1-2.4: device descriptor read/64, error -110
Apr 12 09:13:53 arm kernel: [65105.390991] usb 1-2.4: new full-speed USB device number 9 using ehci-omap
Apr 12 09:14:08 arm kernel: [65120.477081] usb 1-2.4: device descriptor read/64, error -110
Apr 12 09:14:23 arm kernel: [65135.679870] usb 1-2.4: device descriptor read/64, error -110
Apr 12 09:14:23 arm kernel: [65135.883087] usb 1-2.4: new full-speed USB device number 10 using ehci-omap
Apr 12 09:14:33 arm kernel: [65146.304443] usb 1-2.4: device not accepting address 10, error -110
Apr 12 09:14:34 arm kernel: [65146.398834] usb 1-2.4: new full-speed USB device number 11 using ehci-omap
Apr 12 09:14:44 arm kernel: [65156.820281] usb 1-2.4: device not accepting address 11, error -110
Apr 12 09:14:44 arm kernel: [65156.832550] hub 1-2:1.0: unable to enumerate USB device on port 4

When switching the usb port it does work though ( I mean when connecting the usb device to another physical usb port)

RobertCNelson commented 11 years ago

2 questions:

Does the problem still exist with: v3.7.10-x10

To Test: wget http://rcn-ee.net/deb/quantal-armhf/v3.7.10-x10/install-me.sh sudo /bin/bash install-me.sh

and does it occur with: v3.9-rc6:

To Test: wget http://rcn-ee.net/deb/quantal-armhf/v3.9.0-rc6-x0/install-me.sh sudo /bin/bash install-me.sh

Background: I'm thinking of doing the v3.7.10 -> v3.9-rc(7/8) jump with my images by default for everyone...

aferre commented 11 years ago

The problem arises on the long run (no problem for 16 days for instance, and then out of nowhere, usb enumeration and cts/rts drops).

I am not able to test multiple hardwares at a time anymore as we have already shipped most of your boards. I'm still willing to test though, but the results won't show until a few weeks.

Le ven. 12 avril 2013 14:56:32 CEST, Robert Nelson a écrit :

2 questions:

Does the problem still exist with: v3.7.10-x10

To Test: wget http://rcn-ee.net/deb/quantal-armhf/v3.7.10-x10/install-me.sh sudo /bin/bash install-me.sh

and does it occur with: v3.9-rc6:

To Test: wget http://rcn-ee.net/deb/quantal-armhf/v3.9.0-rc6-x0/install-me.sh sudo /bin/bash install-me.sh

Background: I'm thinking of doing the v3.7.10 -> v3.9-rc(7/8) jump with my images by default for everyone...

— Reply to this email directly or view it on GitHub https://github.com/RobertCNelson/stable-kernel/issues/24#issuecomment-16291246.

RobertCNelson commented 11 years ago

Ah no problem, I never know what type of environment (hands of end user/production/testing/etc) these images are being used in. ;)

Yuck, so searching on google, this has come before with the ftdi_sio drivers.. No good hints..

Mainline vs 3.7.1: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/usb/serial/ftdi_sio.c

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/usb/serial/ftdi_sio.c?id=refs/tags/v3.7.1

One or two changes other then vid/pid additions... So you'll probally not see a difference..

aferre commented 11 years ago

Note:

Found a thread related to this kind of issue. The thread states that this should be related to power issues but the guy having the problem was using an external non powered hub, which is not my case (I plug my devices directly on the beagle) but this is still interesting to note.

aferre commented 11 years ago

Other note:

I am using socat to pipe the tty on a socket.

aferre commented 11 years ago

Third note:

The problem now seems to happen every 10-20 hours (on the board in production). FWICT this seems to be degrading (is that even a word? :) ) over time.