grantonstar
Posts: 30
Joined: Sat Nov 24, 2012 1:08 pm

Re: USB redux

Tue Nov 27, 2012 7:00 pm

Thanks for your help MaxK1.

I unplugged all HD's except the previously mentioned device and kept the hub in-place. Have played a 100 minute 1080p file via SMB in addition to downloading files via http and bittorrent via another laptop and saving to the HD using NFS concurrently. Worked flawlessly, and no errors in syslog.

I did notice and probably should have mentioned before that dmesg reports this with the drive when mounting during boot:
[ 13.343317] usb 1-1.3.4.3: new high-speed USB device number 6 using dwc_otg
[ 13.484817] usb 1-1.3.4.3: New USB device found, idVendor=1058, idProduct=1021
[ 13.513113] usb 1-1.3.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 13.541576] usb 1-1.3.4.3: Product: Ext HDD 1021
[ 13.564596] usb 1-1.3.4.3: Manufacturer: Western Digital
[ 13.591586] usb 1-1.3.4.3: SerialNumber: 574341565933383137303634
[ 13.646972] scsi0 : usb-storage 1-1.3.4.3:1.0
[ 14.664780] scsi 0:0:0:0: Direct-Access WD Ext HDD 1021 2002 PQ: 0 ANSI: 4
[ 14.697003] sd 0:0:0:0: [sda] 3907024896 512-byte logical blocks: (2.00 TB/1.81 TiB)
[ 14.743922] sd 0:0:0:0: [sda] Test WP failed, assume Write Enabled
[ 14.784292] sd 0:0:0:0: [sda] Asking for cache data failed
[ 14.820419] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 14.858402] sd 0:0:0:0: [sda] Test WP failed, assume Write Enabled
[ 14.891808] sd 0:0:0:0: [sda] Asking for cache data failed
[ 14.919739] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 14.960987] sda: sda1
[ 14.989295] sd 0:0:0:0: [sda] Test WP failed, assume Write Enabled
[ 15.031330] sd 0:0:0:0: [sda] Asking for cache data failed
[ 15.067302] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 15.107495] sd 0:0:0:0: [sda] Attached SCSI disk
[ 101.026186] EXT4-fs (sda1): warning: maximal mount count reached, running e2fsck is recommended
[ 101.230698] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
Has this test narrowed it down at all? I would have had my money on the hub being at fault initially...

grantonstar
Posts: 30
Joined: Sat Nov 24, 2012 1:08 pm

Re: USB redux

Tue Nov 27, 2012 7:05 pm

Have also tested copying between the different HD's connected to the hub and am now also seeing the same error reported on another HD:
Nov 27 19:01:41 raspberrypi kernel: [ 907.421799] usb 1-1.3.4.1: reset high-speed USB device number 6 using dwc_otg
This log line occurs repeatedly (every 15 - 45 seconds) for both drives (source and destination) when copying files via NFS and also locally on the pi itself. So it seems to be a lot of disk/ethernet activity produces this. Given it's more than one drive, does that rule the disks out? is it the hub or I am overloading the USB/ethernet subsystem?

M33P
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm

Re: USB redux

Tue Nov 27, 2012 8:47 pm

To save reposting issues elsewhere, I will add to this:

Sidewinder X4 keyboard is almost unusable with r-Pi.

Steps to reproduce:

1) buy a Sidewinder X4 keyboard
2) buy a r-Pi
3) write the very latest raspbian image to a sdcard, rpi-update after the first boot.
4) plug in the X4 - but the behaviour depends where

If plugged into the model B's USB ports directly, the keyboard will miss a "few" keypresses every now and then. This is a known defect with split transactions/timing/latency/whatever.

However when plugged into a downstream hub, even with no other devices connected, the keyboard is constantly reset and dmesg fills up with "reset full-speed USB device number xx using dwc_otg".

This also has the effect of making the keyboard's backlit keys cycle on-off. The ASIC inside the keyboard turns off the LEDs if the device has not been enumerated or has been reset. From the pattern of flashes this happens pretty much at random several times a second.

With the boot option dwc_otg.speed=1 the problem disappears, but this breaks pretty much everything else (ethernet = 1Mbit, external storage = 705KB/s, webcams unusable)

MaxK1
Posts: 1043
Joined: Sun Aug 26, 2012 11:34 pm

Re: USB redux

Tue Nov 27, 2012 10:30 pm

grantonstar wrote:Have also tested copying between the different HD's connected to the hub and am now also seeing the same error reported on another HD:
Nov 27 19:01:41 raspberrypi kernel: [ 907.421799] usb 1-1.3.4.1: reset high-speed USB device number 6 using dwc_otg
This log line occurs repeatedly (every 15 - 45 seconds) for both drives (source and destination) when copying files via NFS and also locally on the pi itself. So it seems to be a lot of disk/ethernet activity produces this. Given it's more than one drive, does that rule the disks out? is it the hub or I am overloading the USB/ethernet subsystem?
I'd say that since you are showing errors on different drives, it isn't them. I just copied a 4G file from en external HDD (through a hub) to an external HDD connected directly to the Pi while flood pinging the wired network (1400 byte packets) and a regular ping via wifi (hub connected) . No USB resets, no data loss and no lost packets. Not an exact copy of your test, though. I would look at begging/borrowing/stealing a different hub if possible...
You are in a maze of twisty little passages, all alike.
When General Failure and Major Disaster get together, Private Parts usually suffers.

grantonstar
Posts: 30
Joined: Sat Nov 24, 2012 1:08 pm

Re: USB redux

Wed Nov 28, 2012 8:26 am

Thankss MaxK1. Have ordered a D-Link DUB-H4 which according to this forum and the hardware compatibility page should work. I'll let you know how I get on once it arrives.

User avatar
with ice cream
Posts: 164
Joined: Mon Jul 30, 2012 7:25 am

Re: USB redux

Thu Nov 29, 2012 1:43 pm

USB related problems also drive me crazy. I thought they would no longer occur but it seems as soon as there is more 'stress' on the bus devices crash. This is not a power issues (powered hubs are in use), it occurs on 256 and on 512 models and under regular official (#250) and also under the latest development firmware (#307).

In my particular case it is an LCD digital picture frame. The behavior is rather strange. With data trickling down the bus it operates normally yet when a screensize png should be loaded it crashes. The problem is reproducible.

In flash mode the device identifies itself as this

Code: Select all

usb 1-1.3.3: new full-speed USB device number 9 using dwc_otg
usb 1-1.3.3: New USB device found, idVendor=1908, idProduct=3318
usb 1-1.3.3: New USB device strings: Mfr=2, Product=1, SerialNumber=3
usb 1-1.3.3: Product: BL206v1.0.0
usb 1-1.3.3: Manufacturer: BUILDWIN
usb 1-1.3.3: SerialNumber: 000001
generic-usb 0003:1908:3318.0001: timeout initializing reports
generic-usb 0003:1908:3318.0001: hiddev0: USB HID v2.01 Device [BUILDWIN BL206v1.0.0] on usb-bcm2708_usb-1.3.3/input0
In regular mode (with flashed firmware):

Code: Select all

usb 1-1.3.3: new full-speed USB device number 11 using dwc_otg
usb 1-1.3.3: New USB device found, idVendor=1908, idProduct=0102
usb 1-1.3.3: New USB device strings: Mfr=2, Product=3, SerialNumber=1
usb 1-1.3.3: Product: USB-Display
usb 1-1.3.3: Manufacturer: hackfin
usb 1-1.3.3: SerialNumber: 001
Adding dwc_otg.speed=1 to the cmdline.txt helps but, as mentioned above, everything else becomes too slow.

I hope that this can be resolved.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1440
Joined: Sat Sep 10, 2011 11:43 am

Re: USB redux

Thu Nov 29, 2012 2:27 pm

with ice cream wrote:In my particular case it is an LCD digital picture frame. The behavior is rather strange. With data trickling down the bus it operates normally yet when a screensize png should be loaded it crashes. The problem is reproducible.
Have you got a crashlog?

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

User avatar
with ice cream
Posts: 164
Joined: Mon Jul 30, 2012 7:25 am

Re: USB redux

Thu Nov 29, 2012 2:38 pm

I'm not sure how to get more details. Where would a crashlog be, dmesg alone doesn't tell much.

anath3ma
Posts: 16
Joined: Fri Nov 09, 2012 4:38 pm

USB Problem?

Thu Nov 29, 2012 9:14 pm

Another person and myself are getting similar issues from two different usb wifi interfaces.

Could this be a usb issue?
http://www.raspberrypi.org/phpBB3/viewt ... 54#p218254

If it conforms to the types of problems USB has, please tell me what debugging info is needed.

Thanks.

M33P
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm

Re: USB redux

Thu Nov 29, 2012 10:36 pm

M33P wrote:To save reposting issues elsewhere, I will add to this:

Sidewinder X4 keyboard is almost unusable with r-Pi.

Steps to reproduce:

1) buy a Sidewinder X4 keyboard
2) buy a r-Pi
3) write the very latest raspbian image to a sdcard, rpi-update after the first boot.
4) plug in the X4 - but the behaviour depends where

If plugged into the model B's USB ports directly, the keyboard will miss a "few" keypresses every now and then. This is a known defect with split transactions/timing/latency/whatever.

However when plugged into a downstream hub, even with no other devices connected, the keyboard is constantly reset and dmesg fills up with "reset full-speed USB device number xx using dwc_otg".

This also has the effect of making the keyboard's backlit keys cycle on-off. The ASIC inside the keyboard turns off the LEDs if the device has not been enumerated or has been reset. From the pattern of flashes this happens pretty much at random several times a second.

With the boot option dwc_otg.speed=1 the problem disappears, but this breaks pretty much everything else (ethernet = 1Mbit, external storage = 705KB/s, webcams unusable)
Update:

This behaviour is specific to the current kernel branch used by R-Pi's official distributions (3.2.27+). It does not appear in 3.6.7+, presumably due to the changes done to the Linux kernel's HID subsystem.

User avatar
with ice cream
Posts: 164
Joined: Mon Jul 30, 2012 7:25 am

Re: USB redux

Fri Nov 30, 2012 3:06 pm

M33P wrote:This behaviour is specific to the current kernel branch used by R-Pi's official distributions (3.2.27+). It does not appear in 3.6.7+, presumably due to the changes done to the Linux kernel's HID subsystem.
Pray tell where would one get such a distribution. Do I need to roll my own?

User avatar
piotr-e
Posts: 71
Joined: Tue Aug 28, 2012 10:51 am
Location: Poland

Re: USB redux

Fri Nov 30, 2012 8:24 pm

@gsh can you compare USB problems between model B and model A :?:

Maybe for model A USB problem isn't exist.
Raspberry Pi, model B, revision 2, 256MB RAM; Raspbian; Huawei E3131 modem (it works :-) ); EasyCap 4CH USB DVR (it works, but very slow)

I'm sorry for my English.

the_summer
Posts: 16
Joined: Mon Mar 19, 2012 9:49 am

Re: USB Problem?

Fri Nov 30, 2012 10:06 pm

anath3ma wrote:Another person and myself are getting similar issues from two different usb wifi interfaces.

Could this be a usb issue?
http://www.raspberrypi.org/phpBB3/viewt ... 54#p218254

If it conforms to the types of problems USB has, please tell me what debugging info is needed.

Thanks.
I think I have the same problem. I use a TP-Link TL-WN821N v3 with hostapd. When I try to copy a large file (500MB) from the pi to my computer. It get stuck after a few minutes. This is the log I get:

Code: Select all

Nov 30 21:51:49 raspberrypi kernel: [ 1321.186153] ifplugd         D c038072c     0  1463      1 0x00000000
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186230] [<c038072c>] (__schedule+0x2bc/0x568) from [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186303] [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154) from [<c02de5c8>] (dev_ioctl+0x3e0/0x864)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186344] [<c02de5c8>] (dev_ioctl+0x3e0/0x864) from [<c00c855c>] (do_vfs_ioctl+0x7c/0x578)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186374] [<c00c855c>] (do_vfs_ioctl+0x7c/0x578) from [<c00c8a8c>] (sys_ioctl+0x34/0x60)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186410] [<c00c8a8c>] (sys_ioctl+0x34/0x60) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186457] ifplugd         D c038072c     0  1479      1 0x00000000
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186499] [<c038072c>] (__schedule+0x2bc/0x568) from [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186531] [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154) from [<c02de5c8>] (dev_ioctl+0x3e0/0x864)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186562] [<c02de5c8>] (dev_ioctl+0x3e0/0x864) from [<c00c855c>] (do_vfs_ioctl+0x7c/0x578)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186590] [<c00c855c>] (do_vfs_ioctl+0x7c/0x578) from [<c00c8a8c>] (sys_ioctl+0x34/0x60)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186618] [<c00c8a8c>] (sys_ioctl+0x34/0x60) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186701] ifplugd         D c038072c     0  8688      1 0x00000000
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186741] [<c038072c>] (__schedule+0x2bc/0x568) from [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186775] [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154) from [<c02de5c8>] (dev_ioctl+0x3e0/0x864)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186806] [<c02de5c8>] (dev_ioctl+0x3e0/0x864) from [<c00c855c>] (do_vfs_ioctl+0x7c/0x578)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186833] [<c00c855c>] (do_vfs_ioctl+0x7c/0x578) from [<c00c8a8c>] (sys_ioctl+0x34/0x60)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186863] [<c00c8a8c>] (sys_ioctl+0x34/0x60) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186910] ifplugd         D c038072c     0  9317      1 0x00000000
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186950] [<c038072c>] (__schedule+0x2bc/0x568) from [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.186983] [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154) from [<c02de5c8>] (dev_ioctl+0x3e0/0x864)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.187013] [<c02de5c8>] (dev_ioctl+0x3e0/0x864) from [<c00c855c>] (do_vfs_ioctl+0x7c/0x578)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.187040] [<c00c855c>] (do_vfs_ioctl+0x7c/0x578) from [<c00c8a8c>] (sys_ioctl+0x34/0x60)
Nov 30 21:51:49 raspberrypi kernel: [ 1321.187068] [<c00c8a8c>] (sys_ioctl+0x34/0x60) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187276] ifplugd         D c038072c     0  1463      1 0x00000000
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187351] [<c038072c>] (__schedule+0x2bc/0x568) from [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187397] [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154) from [<c02de5c8>] (dev_ioctl+0x3e0/0x864)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187437] [<c02de5c8>] (dev_ioctl+0x3e0/0x864) from [<c00c855c>] (do_vfs_ioctl+0x7c/0x578)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187467] [<c00c855c>] (do_vfs_ioctl+0x7c/0x578) from [<c00c8a8c>] (sys_ioctl+0x34/0x60)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187502] [<c00c8a8c>] (sys_ioctl+0x34/0x60) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187549] ifplugd         D c038072c     0  1479      1 0x00000000
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187589] [<c038072c>] (__schedule+0x2bc/0x568) from [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187623] [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154) from [<c02de5c8>] (dev_ioctl+0x3e0/0x864)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187653] [<c02de5c8>] (dev_ioctl+0x3e0/0x864) from [<c00c855c>] (do_vfs_ioctl+0x7c/0x578)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187681] [<c00c855c>] (do_vfs_ioctl+0x7c/0x578) from [<c00c8a8c>] (sys_ioctl+0x34/0x60)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187709] [<c00c8a8c>] (sys_ioctl+0x34/0x60) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187755] ntpd            D c038072c     0  1988      1 0x00000001
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187794] [<c038072c>] (__schedule+0x2bc/0x568) from [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187827] [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154) from [<c02de6cc>] (dev_ioctl+0x4e4/0x864)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187858] [<c02de6cc>] (dev_ioctl+0x4e4/0x864) from [<c00c855c>] (do_vfs_ioctl+0x7c/0x578)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187886] [<c00c855c>] (do_vfs_ioctl+0x7c/0x578) from [<c00c8a8c>] (sys_ioctl+0x34/0x60)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187913] [<c00c8a8c>] (sys_ioctl+0x34/0x60) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.187993] ifplugd         D c038072c     0  8688      1 0x00000000
Nov 30 21:53:49 raspberrypi kernel: [ 1441.188068] [<c038072c>] (__schedule+0x2bc/0x568) from [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.188102] [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154) from [<c02de5c8>] (dev_ioctl+0x3e0/0x864)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.188134] [<c02de5c8>] (dev_ioctl+0x3e0/0x864) from [<c00c855c>] (do_vfs_ioctl+0x7c/0x578)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.188162] [<c00c855c>] (do_vfs_ioctl+0x7c/0x578) from [<c00c8a8c>] (sys_ioctl+0x34/0x60)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.188192] [<c00c8a8c>] (sys_ioctl+0x34/0x60) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.188240] ifplugd         D c038072c     0  9317      1 0x00000000
Nov 30 21:53:49 raspberrypi kernel: [ 1441.188280] [<c038072c>] (__schedule+0x2bc/0x568) from [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.188313] [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154) from [<c02de5c8>] (dev_ioctl+0x3e0/0x864)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.188344] [<c02de5c8>] (dev_ioctl+0x3e0/0x864) from [<c00c855c>] (do_vfs_ioctl+0x7c/0x578)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.188372] [<c00c855c>] (do_vfs_ioctl+0x7c/0x578) from [<c00c8a8c>] (sys_ioctl+0x34/0x60)
Nov 30 21:53:49 raspberrypi kernel: [ 1441.188401] [<c00c8a8c>] (sys_ioctl+0x34/0x60) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Nov 30 21:55:49 raspberrypi kernel: [ 1561.188391] ifplugd         D c038072c     0  1463      1 0x00000000
Nov 30 21:55:49 raspberrypi kernel: [ 1561.188468] [<c038072c>] (__schedule+0x2bc/0x568) from [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154)
Nov 30 21:55:49 raspberrypi kernel: [ 1561.188514] [<c0381c48>] (__mutex_lock_slowpath+0xb8/0x154) from [<c02de5c8>] (dev_ioctl+0x3e0/0x864)
Nov 30 21:55:49 raspberrypi kernel: [ 1561.188554] [<c02de5c8>] (dev_ioctl+0x3e0/0x864) from [<c00c855c>] (do_vfs_ioctl+0x7c/0x578)
Nov 30 21:55:49 raspberrypi kernel: [ 1561.188583] [<c00c855c>] (do_vfs_ioctl+0x7c/0x578) from [<c00c8a8c>] (sys_ioctl+0x34/0x60)
Nov 30 21:55:49 raspberrypi kernel: [ 1561.188619] [<c00c8a8c>] (sys_ioctl+0x34/0x60) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Nov 30 21:56:29 raspberrypi kernel: [ 1601.246796] usb 1-1.2.2: USB disconnect, device number 9
Nov 30 21:56:30 raspberrypi kernel: [ 1602.649379] usb 1-1.2.2: ath9k_htc: USB layer deinitialized
I don't know if that is an issue with the usb-host controller gordon is working on or a problem of the ath9k-driver of the wifi-dongle.

If someone has suggestions or wants a more detailed log, just tell me. I just don't know atm where to find more valuable informations.

Best regards,

Jan

M33P
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm

Re: USB redux

Fri Nov 30, 2012 11:30 pm

with ice cream wrote:
M33P wrote:This behaviour is specific to the current kernel branch used by R-Pi's official distributions (3.2.27+). It does not appear in 3.6.7+, presumably due to the changes done to the Linux kernel's HID subsystem.
Pray tell where would one get such a distribution. Do I need to roll my own?
The Pi's kernel is on Github at https://github.com/raspberrypi/linux. This is the code repository for the up-to-date kernel which is subsequently compiled and available via rpi-update. You can see that a branch (3.6.y) has been created which is also in active development - this includes pretty much all the patches already done to 3.2.27 but is built on top of the "mainline" 3.6 kernel. The 3.6 branch is not precompiled in general.

To build it yourself, you really need an additional computer running linux. It takes days to compile the kernel on an r-pi.

http://elinux.org/RPi_Kernel_Compilation

User avatar
with ice cream
Posts: 164
Joined: Mon Jul 30, 2012 7:25 am

Re: USB redux

Sat Dec 01, 2012 12:42 pm

M33P wrote:The Pi's kernel is on Github [...] To build it yourself, you really need an additional computer running linux. It takes days to compile the kernel on an r-pi.[...]
Thank you for clarifying this, but I guess this is too much for me.

Nevertheless, I would like to contribute what I can to get this fixed. How Can I provide more log information than dmesg output?

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5331
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: USB redux

Sat Dec 01, 2012 3:46 pm

M33P wrote:which is also in active development - this includes pretty much all the patches already done to 3.2.27 but is built on top of the "mainline" 3.6 kernel. The 3.6 branch is not precompiled in general.

To build it yourself, you really need an additional computer running linux. It takes days to compile the kernel on an r-pi.
No. Prebuilt 3.6 kernel is available in github. See (towards end of)
http://www.raspberrypi.org/phpBB3/viewt ... 29&t=19334
for update information.

chrisw2
Posts: 106
Joined: Sat Apr 07, 2012 11:22 am
Location: Manchester, UK

Re: USB redux

Sat Dec 01, 2012 8:54 pm

M33P wrote:... It takes days to compile the kernel on an r-pi.
That is a bit of an exaggeration. It takes about six hours. - My tip: go away and do something else while it is compiling :)

Sorry for being Off-Topic but I couldn't let that go uncorrected

MaxK1
Posts: 1043
Joined: Sun Aug 26, 2012 11:34 pm

Re: USB redux

Sat Dec 01, 2012 11:52 pm

Just got a rev 2 512M (one of last Made in China I'm guessing from the date code) Swapped out a working Rev 1 and fired it up. Booted, but no USB or ethernet. Tried again. Same thing. Tried a different SD image. Same again. Kernel didn't report any USB or ethernet found. Flipped the board over and gave X1 a healthy thwack with my finger (you can guess which one. No prizes... ;-) ) tried again - booted fine, USB sprang to life, Ethernet lit up like a Christmas tree, been working ever since. My question - If it can be brought to life like that, presumably it can crap out from rough handling or rude hand gestures on a running system. Would the symptoms be a complete hang/crash or just USB/Ethernet go to lunch? If the latter, could that or something similar explain _some_ of the USB weirdness being reported? X1 drops in and/or out at random and anything connected is left in some unknown, but probably non-working state? I have no idea if it was an ill-placed microscopic "blob" of solder, a bad solder joint or just TLC....
You are in a maze of twisty little passages, all alike.
When General Failure and Major Disaster get together, Private Parts usually suffers.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1440
Joined: Sat Sep 10, 2011 11:43 am

Re: USB redux

Sun Dec 02, 2012 4:56 pm

piotr-e wrote:@gsh can you compare USB problems between model B and model A :?:

Maybe for model A USB problem isn't exist.
The only reason problems will go away for Model A would be because you plugged in a USB1.1 device (i.e. a single keyboard or mouse) as soon as you plug in a hub any split transaction problems will re-occur)

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

drgeoff
Posts: 9821
Joined: Wed Jan 25, 2012 6:39 pm

Re: USB redux

Sun Dec 02, 2012 8:15 pm

MaxK1 wrote: I have no idea if it was an ill-placed microscopic "blob" of solder, a bad solder joint or just TLC....
I'm not an expert on quartz crystal oscillators but I do know that the crystal does resonate with real (but small) physical vibrations. Googling has brought up www.daewonmc.com/data/tech_doc/se.ppt about "sleeping crystals" which is quite interesting and may be relevant. Note that there is no permanent cure.

User avatar
piotr-e
Posts: 71
Joined: Tue Aug 28, 2012 10:51 am
Location: Poland

Re: USB redux

Sun Dec 02, 2012 8:37 pm

gsh wrote: The only reason problems will go away for Model A would be because you plugged in a USB1.1 device (i.e. a single keyboard or mouse) as soon as you plug in a hub any split transaction problems will re-occur)

Gordon
When I use only one device (easycap) and SSH through RJ-45 and I also have a problem with USB. In my opinion split transaction isn't reason in this case. For easycap(STK1160 driver from github) USB works too slow. Maybe it is second reason of USB problem. Tomorrow I compile newest linux kernel from github, I run easycap and I put full report here.
Last edited by piotr-e on Sun Dec 02, 2012 9:03 pm, edited 1 time in total.
Raspberry Pi, model B, revision 2, 256MB RAM; Raspbian; Huawei E3131 modem (it works :-) ); EasyCap 4CH USB DVR (it works, but very slow)

I'm sorry for my English.

MaxK1
Posts: 1043
Joined: Sun Aug 26, 2012 11:34 pm

Re: USB redux

Sun Dec 02, 2012 8:48 pm

drgeoff wrote:
MaxK1 wrote: I have no idea if it was an ill-placed microscopic "blob" of solder, a bad solder joint or just TLC....
I'm not an expert on quartz crystal oscillators but I do know that the crystal does resonate with real (but small) physical vibrations. Googling has brought up http://www.daewonmc.com/data/tech_doc/se.ppt about "sleeping crystals" which is quite interesting and may be relevant. Note that there is no permanent cure.
I was thinking more along the lines of intermittent contact (Like a bad solder joint), but that reference may be quite relevant as well. Several of the Troubleshooting posts have mentioned freezing the board or re-flowing solder around X1 as well as just probing it with a 'scope to get it started. I'm wondering what the symptoms would be if it was cutting in and out.
You are in a maze of twisty little passages, all alike.
When General Failure and Major Disaster get together, Private Parts usually suffers.

grantonstar
Posts: 30
Joined: Sat Nov 24, 2012 1:08 pm

Re: USB redux

Mon Dec 03, 2012 11:23 am

MaxK1 - Have received and installed the D-Link DUB-H4. Have done quite a bit of testing over the weekend including copying locally and via NFS/Samba. So far, so good. Must have been a dodgy hub.

Thanks again for all your help.

f32mark
Posts: 36
Joined: Wed Sep 05, 2012 4:58 am

Re: USB redux

Mon Dec 03, 2012 1:33 pm

rew wrote:
jamesh wrote:Can you post exact steps to reproduce the problem please (unless you've already done so on github or similar, in which case can you link them).
Try the following. Connect your camera. Then try gphoto2 -L . And then again.
If that works, we need some cooperation from your camera: try gphoto2 --capture-image . Twice. It seems the second one hangs.
(I haven't tried this myself: I'm just on the gphoto mailing list. But this is supposed to be a surefire way to trigger it!).
I had this problem with command line gphoto2, but when using the library and some code of my own, the problem went away. I can now use motion to control a connected camera and the gphoto2 libary with no problems.

a version of the code is here: http://www.raspberrypi.org/phpBB3/viewt ... 57#p214757

I've got a slightly newer example with less lag, but it uses the same library calls. So I wonder if the problem is with gphoto2?

s7mx1
Posts: 78
Joined: Fri Sep 30, 2011 9:28 am

Re: USB redux

Thu Dec 06, 2012 10:35 am

Anyone checked this thread:

http://www.raspberrypi.org/phpBB3/viewt ... 28&t=24669

I have one usb 2.0 speakers has to be used with usb 1.1 mode otherwise I will have distorted sound during playback.

Return to “Troubleshooting”