search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11.01k stars 4.95k forks source link

Running X/LXDE causes packet loss/dmesg errors on networking #29

Closed marsman2020 closed 11 years ago

marsman2020 commented 12 years ago

I am seeing extreme packet loss/networking issues when launching X/LXDE, but not at the console. In an attempt to rule out an issue with my power supply setup, I have gone through the troubleshooting steps below.

Hardware configuration: -Pi Power Supply -> HP Touchpad 5.3V/2A supply, 24AWG USB A to Micro B cable -Pi Storage -> SandDisk Extreme HD Video 4GB 20MB/s Class 6 SDHC Card -Ethernet connected directly to router -USB Hub -> Belkin F5U307 w/PS0538 5V 3.5A power supply --USB Mouse (connected to hub) -> Logitech Wireless, 100mA receiver --Keyboard Adapter (connected to hub) -> Belkin F5U119vE PS/2 to USB Adapter --PS/2 Keyboard (connected to keyboard adapter) -> IBM KPD8923 -Pi Monitor - Lenovo L220x connected via HDMI->DVI Cable

Software Configurations: I used the latest Debian Squeeze image, with the latest kernel (PREEMPT #89) installed via rpi-update and the Debian system fully updated using apt-get upgrade.

I did the following:

  1. On another machine on the network - Used "python -m http.server" in Python 3.2.2 to create an http server. Picked a random ~90MB file on the machine as a test download over http
  2. On the Pi - Installed the 'stress' utility using apt-get. Used "stress -c 15" to load the Pis CPU to 100%. Started htop at the console
  3. On the other machine on the network - SSHed into the Pi and ran wget in the ssh terminal to download the 90MB test.zip onto the Pi using http over the local network. Download speeds ~2.9-3.0 MB/s. ssh window responsiveness is stable. Repeated over a period of 10 minutes to allow the Pis CPU to reach a steady state temperature/power draw at 100% CPU load. Started a final instance of the download
  4. On the Pi (do this while the download is running in the ssh window!) - Exited htop. Ran "Startx"
  5. On the other machine - Observed that the download running in the ssh window on the Pi slowed from ~3MB/s to ~44KB/s as soon as X/LXDE loaded . (The 'stress' command is still running in the background, loading the CPU to the same constant 100% as with the console download tests in Step 3)
  6. On the Pi - Exited X/LXDE ("Logout")
  7. On the other machine - Observed that the download returned to its original ~3MB/s speed as soon as the system returned to the console.
  8. On the Pi - Observed that there are error messages in the dmesg log releated to the eth0 driver - see http://paste.debian.net/172123

I do not believe this is solely a power related issue, as others on this forum have repeatedly stated when users have asked about it. I can peg my Pis CPU at 100% for > 10 minutes at the console and Ethernet works just find until I start X/LXDE (with the same stress programs still running). Only then does the Ethernet drop out. No change in hardware configuration between the two cases (100% CPU at console, 100% CPU with X/LXDE running).

Other reports of similar issues on the Raspberry Pi forums: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=6928 http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=6042 http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=6827#p87855 http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=6677 http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=7075 http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=7445 http://forum.stmlabs.com/showthread.php?tid=441&pid=3258#pid3258

XECDesign commented 12 years ago

Does this happen if you go to console and start gpm?

marsman2020 commented 12 years ago

XECDesign: Yes! I did some more testing last night. Same hardware configuration.

-100% CPU load with "stress" applied for all cases -At console, mouse+keyboard->powered hub->pi w/ 5.3V 2A power supply => Network OK -LXDE, mouse+keyboard->powered hub->pi w/ 5.3V 2A power supply => Network DROPS -LXDE, powered hub->pi w/ 5.3V 2A power supply => Network OK (no mouse/keyboard attached) -LXDE, keyboard only ->powered hub->pi w/ 5.3V 2A power supply => Network OK -LXDE, mouse only->powered hub->pi w/ 5.3V 2A power supply => Network OK -LXDE, keyboard only ->powered hub->pi w/ 5.3V 2A power supply; mouse->pi usb port => Network DROPS -LXDE, mouse+keyboard->pi USB ports w/ 5.3V 2A power supply => Network OK (mouse eventually became unreliable, probably a genuine power issue in this single case)

-At console -Without GPM, mouse+keyboard->powered hub->pi w/ 5.3V 2A power supply => Network OK -GPM, mouse+keyboard->powered hub->pi w/ 5.3V 2A power supply => Network DROPS -Without GPM, mouse+keyboard->pi w/ 5.3V 2A power supply => Network OK -GPM, mouse+keyboard->pi w/ 5.3V 2A power supply => Network DROPS

In LXDE, it seems like having 1 low speed device on a hub and 1 low speed device elsewhere or 2 on the hub causes the problem.

With GPM, it seems like just reading the mouse period is enough to cause the problem.

(Note that my PS/2 -> USB adapter I am using for the keyboard is a dual adapter - there is a mouse port I'm not using - so it shows up as 2 USB devices)

I've got plain jane wired USB keyboard/mouse on the way from Monoprice so I can test with less power-hungry devices....

Edit - another user has done some testing here - http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=7075#p89311

XECDesign commented 12 years ago

I have the same issues, I haven't narrowed it down yet, but some things which you might want to check:

marsman2020 commented 12 years ago

I do not believe this is a power supply issue.

I can load the Pi's CPU to 100% for 10+ minutes with no impact on networking util LXDE is started.

Conversely, starting GPM does not cause a major CPU load on the system, and yet it kills networking as well.

I think there is a software bug in the USB code that has to do with devices that require real-time updates like mice. I don't have the linux kernel skills to chase it down myself.

As I said, I have another mouse/keyboard set en route.

XECDesign commented 12 years ago

Power does not equate directly to CPU load. But if activating your mouse draws another 100mA on top of that, that can make all the difference.

I have found that I can two of either the keyboard, mouse or internet, but not all three, regardless of CPU load. And I have found that there IS a voltage drop when all three are connected.

Either way, it's worth checking if only to rule it out.

XECDesign commented 12 years ago

Also, from http://elinux.org/R-Pi_Troubleshooting#Ethernet_connection_is_lost_when_a_USB_device_is_plugged_in : Ethernet connection is lost when a USB device is plugged in This is caused by inadequate power. Use a good power supply and a good power cable. Some cheap cables that work with a cell phone, cannot fully power the R-Pi. Some USB devices require a lot of power (>100 mA), so they must be used with a powered USB hub. Some cheap USB hubs suck power from the Raspberry Pi even if a USB power supply is connected.

marsman2020 commented 12 years ago

So, I got a hold of an oscilloscope, since I don't own one, and I can verify by checking across TP1-TP2 that this is not a power issue.

I have also re-run some more tests. Hardware configuration as follows: -Pi Power Supply -> HP Touchpad 5.3V/2A supply, 24AWG USB A to Micro B cable -Pi Storage -> SandDisk Extreme HD Video 4GB 20MB/s Class 6 SDHC Card -Ethernet connected directly to router -Powered USB Hub -> Belkin F5U307 w/PS0538 5V 3.5A power supply --USB Mouse (connected to hub) -> Logitech Wireless, 100mA receiver --Keyboard Adapter (connected to hub) -> Belkin F5U119vE PS/2 to USB Adapter --PS/2 Keyboard (connected to keyboard adapter) -> IBM KPD8923 -Pi Monitor - Lenovo L220x connected via HDMI->DVI Cable -Techtronix TDS1012 measuring across TP1 TP2, with cursors at 4.75V and 5.25V and set to trigger on falling edges at 4.75V. Measuring average, min, and max voltage.

-At console, with no extra CPU load -Without GPM, mouse+keyboard->powered hub->pi w/ 5.3V 2A power supply => 4.86V min 4.88V mean 4.93V max, Network OK -GPM, mouse+keyboard->powered hub->pi w/ 5.3V 2A power supply => 4.93V min 4.96V mean 4.98B max, Network DROPS ("eth0: kevent 4 may have been dropped") -Without GPM, mouse+keyboard->pi w/ 5.3V 2A power supply => 4.88V min 4.91V mean 4.94V max, Network OK -GPM, mouse+keyboard->pi w/ 5.3V 2A power supply => 4.88V min 4.91V mean 4.94V max, Network OK

-LXDE started, without GPM, no extra CPU load -mouse+keyboard->pi w/ 5.3V 2A power supply => 4.85V min 4.89V mean 4.95V max, Network OK (I logged out of LXDE to change to the powered hub) -mouse+keyboard->powered hub->pi w/ 5.3V 2A power supply => 4.91V min 4.96V mean 5.00V max, Network DROPS -unplug hub - network returns

The result with the mouse+keyboard directly attached to the Pi is different with GPM from last time, but consistent with the LXDE result.

As a final test of the possibility of any power supply issues in the previous testing I have done: -LXDE running, dual USB->PS2 adapter with keyboard attached (no mouse) & USB Wireless Mouse Receiver attached to Pi USB ports, 100% CPU load via "stress -c 13" => 4.86V min 4.90V mean 4.95V max, Network WORKS

Paste of todays session dmesg log - http://paste.ubuntu.com/1021879/

Conclusions: -The HP Touchpad power supply (5.3V/2A) is an excellent choice for the Pi, when paired with a 6ft 24AWG power wire USB cable. It keeps the TP1-TP2 voltage within spec even with multiple USB devices attached and using power, X running, and 100% CPU load -There is a software issue related to (some? all? unclear as I only have Belkin hubs to test) powered hubs, that interferes with operation of the USB-attached Ethernet power on the Pi. The same issue may possibly manifest with USB-attached wireless adapters (I do not have one to test). Based on GPM triggering the issue, it would appear to be related to the mouse.

So, maybe we can get on with solving this issue?

marsman2020 commented 12 years ago

I'm continuing to monitor the forums for apparent cases of this issue and am updating the first post of this issue with links to the threads as they appear.

NickBT commented 12 years ago

In support of this issue and to raise its profile, I would like to point out that I have similar errors which are related to a wireless dongle failing to connect after LXDE is started. I believe they may have a common cause, so I've cut and pasted some input from me in a couple of threads on the RPi forum.

I've managed to get my pi connected wirelessly with a Belkin FD7050 and the ralink drivers when at the command line. I can ping the BBC website and also ssh into the pi from my PC. I'm powering a Logik keyboard and a mouse from a Logik powered hub. Once I start LXDE with 'startx', I have no network connectivity from the pi and a ping from my PC shows it as unreachable (as is the router itself). When I quit LXDE, I still have no connectivity. LXDE works fine if I connect via the Ethernet cable.

The dmesg output after LXDE is started shows a lot of failed to read/write errors such as

smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114 smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118

I can fix it with a kludge of a workaround

A Google search for 'smsc95xx' brings up a few hits, many of them describing behaviour in the Rpi. It's a kernel module and it doesn't seem to like a mixture of high and low speed USB devices on the same hub.

The (fix): I've got a Belkin wifi dongle, a keyboard, mouse and the recommended Logik powered (2.0A) hub. I've also got a crappy Asda unpowered 4 port hub which I wasn't using until now. Originally I had mouse, kbd, wifi all plugged into the powered hub and the wifi worked until I started LXDE. I then got identical errors to you. The wifi won't run off the Rpi port as there's not enough current capacity by the way.

So mindful of the hint not to mix devices on the same hub I got it going with the following sequence:

1) Wifi in powered hub in one Rpi USB, Asda hub (NO DEVICES CONECTED) in the other RPi USB, turn on power 2) Wait till login prompt, plug kbd into Asda hub, log in 3) Type 'startx', wait for GUI, plug mouse into Asda hub

Browser works and if you quit to the cli, wifi is still up. If you plug the kbd in when you power up, or the mouse before LXDE starts, then you get errors or the wifi connectivity doesn't work. I reckon that two powered hubs, or a low power wifi dongle connected to the Rpi would probably work OK from power up with all device connected

I can confirm that this error is present even after an rpi-update. It also happens with the other lightweight desktop XFCE. The 5V rail holds up at over 4.85 volts under all conditions tested.

jstsch commented 12 years ago

Similar issues here. Also without running X. Setup:

Using just the keyboard and mouse, with or without the hub gives no issues. When the wireless dongle is plugged in I get errors such as:

smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114 Jun 9 15:05:23 raspberrypi kernel: DEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACK Jun 9 15:05:23 raspberrypi kernel: hub 1-1.2:1.0: hub_port_status failed (err = -71) Jun 9 15:05:23 raspberrypi kernel: hub 1-1.2:1.0: Cannot enable port 4. Maybe the USB cable is bad? Jan 1 01:07:55 raspberrypi kernel: INFO:: periodic_channel_available: Total channels: 8, Periodic: 4, Non-periodic: 4 Jan 1 01:07:55 raspberrypi kernel: INFO:: schedule_periodic: No host channel available for periodic transfer. Jan 1 01:07:55 raspberrypi kernel: ERROR::dwc_otg_hcd_urb_enqueue:487: DWC OTG HCD URB Enqueue failed adding QTD. Error status -4008 Jan 1 01:07:55 raspberrypi kernel: usb 1-1.3.3: reset low speed USB device number 5 using dwc_otg

Last night everything was working. Had everything plugged into the hub. Browsing using Midori over the wireless connection. This morning the Pi had crashed (nothing on the screen). Booting with everything plugged in gave me a kernel panic just now after a stream of similar error messages.

Hopefully some useful information in here!

jstsch commented 12 years ago

Some more:

Jun 9 23:16:39 raspberrypi kernel: mmc0: missed completion of cmd 17 DMA (512/512 [1]/[1]) - ignoring it Jun 9 23:16:39 raspberrypi kernel: mmc0: DMA IRQ 6 ignored - results were reset Jun 9 23:16:39 raspberrypi kernel: mmc0: missed completion of cmd 17 DMA (512/512 [1]/[1]) - ignoring it Jun 9 23:16:39 raspberrypi kernel: mmc0: DMA IRQ 6 ignored - results were reset

Upon pluggin in the wireless dongle:

Jun 10 00:43:00 raspberrypi kernel: usb 1-1.3.6: new high speed USB device number 9 using dwc_otg Jun 10 00:43:01 raspberrypi kernel: usb 1-1.3.6: New USB device found, idVendor=0cf3, idProduct=7015 Jun 10 00:43:01 raspberrypi kernel: usb 1-1.3.6: New USB device strings: Mfr=16, Product=32, SerialNumber=48 Jun 10 00:43:01 raspberrypi kernel: usb 1-1.3.6: Product: USB WLAN Jun 10 00:43:01 raspberrypi kernel: usb 1-1.3.6: Manufacturer: ATHEROS Jun 10 00:43:01 raspberrypi kernel: usb 1-1.3.6: SerialNumber: 12345 Jun 10 00:43:01 raspberrypi kernel: usb 1-1.3.6: ath9k_htc: Transferred FW: htc_7010.fw, size: 72992 Jun 10 00:43:02 raspberrypi kernel: usb 1-1.3.6: Service connection timeout for: 256 Jun 10 00:43:02 raspberrypi kernel: ath9k_htc 1-1.3.6:1.0: ath9k_htc: Unable to initialize HTC services Jun 10 00:43:02 raspberrypi kernel: Failed to initialize the device Jun 10 00:43:02 raspberrypi kernel: ath9k_htc: probe of 1-1.3.6:1.0 failed with error -22

marsman2020 commented 12 years ago

I also was able to observe the issue in Arch Linux with their custom kernel.

However, changing mice seems to have semi-resolved my immediate issue. I went from a Logitech Wireless to a "Monoprice special" wired optical mouse.

That Logitech mouse has worked fine on multiple computers with several Linux distributions, Windows XP, and Windows 7 for the last ~4 years. It should work fine with a powered hub on the Pi. Based on the many, many other threads on issues with USB devices on this forum, I think it comes down to the USB driver provided by the company that made the USB IP core that Broadcom bought for the Pi's SoC just sucking, and until someone rewrites a complete new USB driver we will continue to have these types of issues.

It's unfortunate because with these kinds of issues, the Pi doesn't really meet the as-advertised "plug in whatever USB keyboard/mouse/hub you have in the house and start coding" that has been put forth by the Foundation for the last 6 months.

I will by trying to add an Arduino Uno and Open Bench Logic Sniffer to the same powered USB hub soon, to test out using the Pi as a low-cost host computer for open source hardware tools. I'll report back on what happens when those devices are added...

NickBT commented 12 years ago

I've done some investigation into what fails when I startx and one of the peripherals plugged into the powered hub fails. I did a fairly rough and ready hack to find out where the first error that I can locate is. I altered dwc_otg_hcd_queue.c's function

static int periodic_channel_available(dwc_otg_hcd_t * hcd) { / * Currently assuming that there is a dedicated host channnel for each * periodic transaction plus at least one host channel for * non-periodic transactions. / int status; int num_channels;

num_channels = hcd->core_if->core_params->host_channels;
if ((hcd->periodic_channels + hcd->non_periodic_channels < num_channels) &&
    (hcd->periodic_channels < num_channels - 1)) {
    status = 0;
} else {
    //DWC_INFO("%s: Total channels: %d, Periodic: %d, Non-periodic: %d\n",
    //  __func__, num_channels, hcd->periodic_channels, hcd->non_periodic_channels);    //NOTICE
    DWC_ERROR("%s: NBT Total channels: %d, Periodic: %d, Non-periodic: %d\n",
        __func__, num_channels, hcd->periodic_channels, hcd->non_periodic_channels);    //NOTICE
    status = -DWC_E_NO_SPACE;
}

return status;

}

(The 'NBT' is my marker for grepping)

When it fails it gives error in dmesg:

smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114 ERROR::periodic_channel_available:342: periodic_channel_available: NBT Total channels: 8, Periodic: 5, Non-periodic: 3

Leaving aside that I may have given func as an incorrect argument to DWC_ERROR, we can see that the first condition will fail,as 5 + 3 is not less than 8.

I hope this sheds some light on the matter.

P.S. the dmesg output is crammed full of such messages after the failure P.P.S - sorry if this doesn't format right.

marsman2020 commented 12 years ago

Another potential case of this issue - http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=8391 And another - http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=8352

marsman2020 commented 12 years ago

Another potential case - http://www.raspberrypi.org/phpBB3/viewtopic.php?f=50&t=8453

guisacouto commented 12 years ago

I wouldn't be surprise if this had something to do with issue 9. My guess is that when you startx you start opening and reading a lot of files into memory, and there is where the problem is. Very I/O causes issues, and not the 100% CPU for itself.

If you combine high CPU usage with some sort of high usb usage (rather it is the ethernet using the usb bus, wifi, or usb storage) that generates a lot of I/0 opening, writing, and reading files that is what causes all this issues I think

XECDesign commented 12 years ago

@guisacouto

starting x is not a requirement to replicate this. starting gpm (which wouldn't affect IO much) also.

usb interrupts is something that might be worth looking into.

guisacouto commented 12 years ago

That skipped me. Then yes.. I guess it's all about usb interrupts. What bothers me is that there is a lot of people reporting this kind of problems, but I don't see updates on the repos to try solve this.. it always ends with a 'it must be a power supply issue' or something. I hope this gets more attention soon

jstsch commented 12 years ago

Dito. Right now I am recommending people to wait getting a R-Pi until these issues are resolved. I wrote a short review the other day: http://jstsch.com/post/24_hours_with_the_raspberry_pi

marsman2020 commented 12 years ago

Another case - http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=9077&p=106318#p106318

User bought a hub listed in the "verified peripherals" section of the Wiki...

fbutler commented 12 years ago

I'm seeing the same type of issue with a Logitech Di Novo Edge keyboard without running startx. I get variations of the same type of errors whether the device is plugged in at boot time or plugged in after booting has completed.

My Setup is:

Wheezy beta distro fully updated A logilink 10 port powered hub A USB Y cable powering the Pi from the Logilink hub Voltage across TP1 and TP2 is 4.91V Additional USB cable between the hub and the Pi with the red wire snipped to prevent back powering to the Pi Logitech wireless adapter (Part Number 832243-0000) plugged into hub Keyboard Part Number YRAY-81 No other USB devices plugged in

Here is a portion of the dmesg output from the point when the device is detected:

[ 940.096845] usb 1-1.2: new full speed USB device number 12 using dwc_otg [ 940.200190] usb 1-1.2: New USB device found, idVendor=046d, idProduct=0b04 [ 940.200237] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 940.200259] usb 1-1.2: Product: Logitech BT Mini-Receiver [ 940.200275] usb 1-1.2: Manufacturer: Logitech [ 940.207521] hub 1-1.2:1.0: USB hub found [ 940.207888] hub 1-1.2:1.0: 3 ports detected [ 940.486952] usb 1-1.2.2: new full speed USB device number 13 using dwc_otg [ 940.595807] usb 1-1.2.2: New USB device found, idVendor=046d, idProduct=c713 [ 940.595864] usb 1-1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 940.595889] usb 1-1.2.2: Product: Logitech BT Mini-Receiver [ 940.595907] usb 1-1.2.2: Manufacturer: Logitech [ 940.595924] usb 1-1.2.2: SerialNumber: 001F2039B887 [ 940.615500] input: Logitech Logitech BT Mini-Receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/input/input4 [ 940.618982] generic-usb 0003:046D:C713.0005: input: USB HID v1.11 Keyboard [Logitech Logitech BT Mini-Receiver] on usb-bcm2708_usb-1.2.2/input0 [ 940.707062] usb 1-1.2.3: new full speed USB device number 14 using dwc_otg [ 940.815761] usb 1-1.2.3: New USB device found, idVendor=046d, idProduct=c714 [ 940.815799] usb 1-1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 940.815821] usb 1-1.2.3: Product: Logitech BT Mini-Receiver [ 940.815852] usb 1-1.2.3: Manufacturer: Logitech [ 940.815870] usb 1-1.2.3: SerialNumber: 001F2039B887 [ 940.849750] input: Logitech Logitech BT Mini-Receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2.3/1-1.2.3:1.0/input/input5 [ 940.854898] logitech 0003:046D:C714.0006: input,hiddev0: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-bcm2708_usb-1.2.3/input0 [ 945.923909] hub 1-1.2:1.0: hub_port_status failed (err = -110) [ 946.256616] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 946.256665] smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read [ 951.248243] usb 1-1.2.2: USB disconnect, device number 13 [ 951.255861] usb 1-1.2.3: USB disconnect, device number 14 [ 951.346828] usb 1-1.2: reset full speed USB device number 12 using dwc_otg [ 951.746821] usb 1-1.2.2: new full speed USB device number 15 using dwc_otg [ 951.855081] usb 1-1.2.2: New USB device found, idVendor=046d, idProduct=c713 [ 951.855133] usb 1-1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 951.855155] usb 1-1.2.2: Product: Logitech BT Mini-Receiver [ 951.855174] usb 1-1.2.2: Manufacturer: Logitech [ 951.855190] usb 1-1.2.2: SerialNumber: 001F2039B887 [ 951.875358] input: Logitech Logitech BT Mini-Receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/input/input6 [ 951.879026] generic-usb 0003:046D:C713.0007: input: USB HID v1.11 Keyboard [Logitech Logitech BT Mini-Receiver] on usb-bcm2708_usb-1.2.2/input0 [ 951.966973] usb 1-1.2.3: new full speed USB device number 16 using dwc_otg [ 952.075734] usb 1-1.2.3: New USB device found, idVendor=046d, idProduct=c714 [ 952.075783] usb 1-1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 952.075806] usb 1-1.2.3: Product: Logitech BT Mini-Receiver [ 952.075823] usb 1-1.2.3: Manufacturer: Logitech [ 952.075840] usb 1-1.2.3: SerialNumber: 001F2039B887 [ 952.103900] input: Logitech Logitech BT Mini-Receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2.3/1-1.2.3:1.0/input/input7 [ 952.111451] logitech 0003:046D:C714.0008: input,hiddev0: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-bcm2708_usb-1.2.3/input0 [ 957.106472] hub 1-1:1.0: hub_port_status failed (err = -110) [ 957.246478] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 962.676429] hub 1-1.2:1.0: hub_port_status failed (err = -110) [ 966.206348] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 967.676337] hub 1-1.2:1.0: hub_port_status failed (err = -110) [ 971.206295] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118 [ 972.676267] hub 1-1.2:1.0: hub_port_status failed (err = -110) [ 977.306200] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 977.676223] hub 1-1.2:1.0: hub_port_status failed (err = -110) [ 982.306165] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114 [ 982.676153] hub 1-1.2:1.0: hub_port_status failed (err = -110) [ 991.286029] hub 1-1.2:1.0: hub_port_status failed (err = -110) [ 991.286066] hub 1-1.2:1.0: connect-debounce failed, port 1 disabled [ 996.245957] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114 [ 996.285980] hub 1-1.2:1.0: hub_port_status failed (err = -110) [ 1001.245917] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 1006.245838] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118 [ 1011.245784] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 1020.475652] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 1020.475703] smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read [ 1025.475568] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 1025.475618] smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read [ 1029.401439] usb 1-1.2.2: USB disconnect, device number 15 [ 1029.414868] usb 1-1.2.3: USB disconnect, device number 16 [ 1029.515768] usb 1-1.2: reset full speed USB device number 12 using dwc_otg [ 1029.915780] usb 1-1.2.1: new full speed USB device number 17 using dwc_otg [ 1030.021981] usb 1-1.2.1: New USB device found, idVendor=046d, idProduct=c709 [ 1030.022018] usb 1-1.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1030.022040] usb 1-1.2.1: Product: Logitech BT Mini-Receiver [ 1030.022057] usb 1-1.2.1: Manufacturer: Logitech [ 1030.022085] usb 1-1.2.1: SerialNumber: 001F2039B887 [ 1030.136063] usb 1-1.2.2: new full speed USB device number 18 using dwc_otg [ 1030.247815] usb 1-1.2.2: New USB device found, idVendor=046d, idProduct=c713 [ 1030.247878] usb 1-1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1030.247923] usb 1-1.2.2: Product: Logitech BT Mini-Receiver [ 1030.247968] usb 1-1.2.2: Manufacturer: Logitech [ 1030.248008] usb 1-1.2.2: SerialNumber: 001F2039B887 [ 1030.286157] input: Logitech Logitech BT Mini-Receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/input/input8 [ 1030.286316] INFO:: periodic_channel_available: Total channels: 8, Periodic: 6, Non-periodic: 2 [ 1030.286330] [ 1030.286346] INFO:: schedule_periodic: No host channel available for periodic transfer. [ 1030.286358] [ 1030.286378] ERROR::dwc_otg_hcd_urb_enqueue:487: DWC OTG HCD URB Enqueue failed adding QTD. Error status -4008 [ 1030.286391] [ 1030.287573] generic-usb 0003:046D:C713.0009: input: USB HID v1.11 Keyboard [Logitech Logitech BT Mini-Receiver] on usb-bcm2708_usb-1.2.2/input0 [ 1030.305539] INFO:: periodic_channel_available: Total channels: 8, Periodic: 6, Non-periodic: 2 [ 1030.305557] [ 1030.305581] INFO:: schedule_periodic: No host channel available for periodic transfer. [ 1030.305594] [ 1030.305616] ERROR::dwc_otg_hcd_urb_enqueue:487: DWC OTG HCD URB Enqueue failed adding QTD. Error status -4008 [ 1030.305629] [ 1030.335596] INFO:: periodic_channel_available: Total channels: 8, Periodic: 6, Non-periodic: 2 [ 1030.335614] [ 1030.335638] INFO:: schedule_periodic: No host channel available for periodic transfer. [ 1030.335650] [ 1030.335671] ERROR::dwc_otg_hcd_urb_enqueue:487: DWC OTG HCD URB Enqueue failed adding QTD. Error status -4008 [ 1030.335684] [ 1030.366111] usb 1-1.2.3: new full speed USB device number 19 using dwc_otg [ 1030.395543] INFO:: periodic_channel_available: Total channels: 8, Periodic: 6, Non-periodic: 2 [ 1030.395561] [ 1030.395584] INFO:: schedule_periodic: No host channel available for periodic transfer.

g4eml commented 12 years ago

I too can confirm that I am seeing similar issues with low speed devices. I initially suspected power problems but have monitored the power with a scope and I am now totally confident that power is not the cause.

If I have two low speed devices plugged into an external hub I almost immediately start getting USB hub and Ethernet failure messages reported with dmesg. The hub cycles on and off repeatedly. Anything attached to the hub works for a few seconds then stops for a few seconds.

I initially saw this with just my keyboard and mouse plugged into the hub. Connecting either the keyboard or the mouse directly to the second port on the Pi and leaving the other device connected to the hub immediately stops the error messages .

Connecting two mice to the hub produces the same errors.

Connecting high speed devices doesn't seem to cause the same problems.

In conclusion it appears that having two low speed devices on an external hub is causing some sort of conflict in the software.

I am pretty sure this has been seen by many people but incorrectly attributed to power problems.

Colin...

Pitel commented 12 years ago

I can somehow confirm the previous findings.

I bought Pyramid 7 Port USB 2.0 Hub (powered). I have my wifi dongle connected to it, which is low-speed device. If I also try connecting my mouse, whch is also low-speed, bad things starts to happen.

marsman2020 commented 12 years ago

Another case here - http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=9470&p=111192#p111192 and here - http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=8473

mcphail commented 12 years ago

I'm having almost identical problems but don't need to startx to drop eth0. Simply plugging a Huawei e173 modem causes a flood of similar error messages in the logs with frequent disconnection and reconnection of the USB modem. I have a Logitech K260 wireless keyboard and mouse combo. I've tried every combination of power supply and powered or passive USB hubs I can get my hands on. I'm running debian 6 and the latest firmware.

popcornmix commented 12 years ago

Just an update. We have been looking into various USB issues, and some of the simpler ones have been fixed. I think the comments in this thread, as usual has a mixture of issues, but one significant one is running out of periodic channels. E.g. INFO:: schedule_periodic: No host channel available for periodic transfer.

Now, the hardware we have is limited to 8 host channels. Now that sounds like lots, but it turns out the ethernet takes one. The ethernet hub takes one. An external hub takes one. One is reserved for non-periodic transfers. Some devices have multiple endpoints. E.g. we've seen an Air-Mouse with 4 endpoints.

Currently the driver just has a fixed allocation of host channels, so a mostly idle keyboard permanently consumes a channel.

Take a look at drivers/usb/host/dwc_otg/dwc_otg_hcd_queue.c#periodic_channel_available

https://github.com/raspberrypi/linux/blob/rpi-patches/drivers/usb/host/dwc_otg/dwc_otg_hcd_queue.c#L323

it requires there is one dedicated host channel for each 'periodic' (interrupt or isochronous I think) transaction. This was actually fixed in the denx tree some time ago:

http://git.denx.de/?p=linux-denx.git;a=commit;h=9796e39e7a513d8a4acde759ec5d0023645143d8

This patch has been incorporated in to the dwc_otg patchset that APM have been trying to get upstream:

http://lkml.indiana.edu/hypermail/linux/kernel/1205.0/01170.html

So, we can see a flaw in the USB driver. And there is a potential solution. Naren has ported it and we have just started testing. Fingers crossed it helps.

marsman2020 commented 12 years ago

I'm willing to help, is there a place where I can get Naren's version of the patch and apply it to a custom compiled kernel, or a testing kernel image that includes the patch already?

Unfortunately my old patebins have expired, but it's likely I have been seeing the out of channels error just before all of the many repeated kevent 4 errors and failed to read register errors.

popcornmix commented 12 years ago

Well, I wouldn't recommend this to people who want a more stable system, as it has had very limited testing. But if you want to help with testing, then try this: https://dl.dropbox.com/u/3669512/temp/0001-added-microframe-schedule-from-the-linux-denx-tree.dc4.patch

It will probably only help if you were getting this error: "schedule_periodic: No host channel available for periodic transfer"

But, try the patch. Report anything that used to work and now doesn't, or anything that didn't work and now does.

NickBT commented 12 years ago

I've just applied this patch to a newly cloned kernel. For the first time ever I can get wifi dongle, keyboard, mouse all working in LXDE. It has wifi network connectivity through the browser. IT WORKS - no fail r/w on index 114 or 118 or failure to enque error messages. That's the good news! The bad news is that pinging bbc.co.uk from a terminal in the GUI gives 35% packet loss. It's a definite improvement from my point of view, well done. Update : bit more bad news, I quit the GUI back to the command line and I can't even ping the router at 192.168.1.1. - host unreachable

marsman2020 commented 12 years ago

I cloned the 3.1.19 raspberry-pi branch and applied this patch. Tested with a Raspbian installation, fully updated with rpi-update and apt-get dist-upgrade.

I have satellite internet. Test on Linux Mint Debian Edition on an x86 latop: -Ping = 8-10% packet loss

Test results with the stock unpatched 7/14 kernel: -With no mouse, at command line - wget test from local LAN ok, ping 8.8.8.8 = 8%-14% packet loss, ping LAN = 0% packet loss. -With mouse, at command line - wget test from local LAN ok, ping 8.8.8.8 = 8%-16% packet loss, ping LAN = % packet loss. -With mouse, in X windows - wget test from local LAN - fails, ping 8.8.8.8 and LAN = extreme packet loss.

Tests results with the patched 7/14 kernel: -With no mouse, at command line - wget test from local LAN ok, ping 8.8.8.8 = 8%-14% packet loss, LAN = 0% packet loss. -With mouse, at command line - wget test from local LAN ok, ping 8.8.8.8 = 12% packet loss, LAN = 0% packet loss. -With mouse, in X windows - wget test from local LAN - fails, ping 8.8.8.8 = 10-20% packet loss, LAN = 0% packet loss.

I'm going to run the patched kernel in IRC overnight and see if it's stable... But I haven't seen the downsides that NickBT did.... The packet loss seems to be due to my internet connection, since even the x86 machine has it.

mchr3k commented 12 years ago

I have also hit this issue: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=10496&p=124750#p124750

I get "schedule_periodic: No host channel available for periodic transfer." when I plug in my webcam while I already have my USB wifi + USB keyboard/mouse plugged in. These are all plugged into a powered USB hub.

davr commented 12 years ago

I have the same problem, when I plug in an arduino, USB-Serial adaptor, and a USB webcam, via a powered USB hub. Whenever I try to access the webcam, I get the following erors:

Jul 25 18:30:59 raspberrypi kernel: [ 1207.331697] INFO:: periodic_channel_available: Total channels: 8, Periodic: 5, Non-periodic: 3 Jul 25 18:30:59 raspberrypi kernel: [ 1207.331716] Jul 25 18:30:59 raspberrypi kernel: [ 1207.331741] INFO:: schedule_periodic: No host channel available for periodic transfer. Jul 25 18:30:59 raspberrypi kernel: [ 1207.331754] Jul 25 18:30:59 raspberrypi kernel: [ 1207.331842] ERROR::dwc_otg_hcd_urb_enqueue:518: DWC OTG HCD URB Enqueue failed adding QTD. Error status -4008 Jul 25 18:30:59 raspberrypi kernel: [ 1207.331856] Jul 25 18:30:59 raspberrypi kernel: [ 1207.331940] uvcvideo: Failed to submit URB 0 (-4008).

SharkyRawr commented 12 years ago

I can confirm that popcornmix's patch, applied on a freshly pulled raspberrypi/linux tree, works. I no longer get the schedule_periodic/periodic_channel_available messages though I have noticed, that enabling the SOF_reduction makes the keyboard/mouse (and potentially others) very unstable [see lines 2-29 of log below].

Syslog: http://pastebin.com/P8tJ5nzZ

Also, every now and then my mouse stopped working for a second or two and then resumed [see lines 30-38, 101-108 of log above]. And I have no idea if that memory allocation error [see line 44] is related to this patch or not, it didn't seem to have any lasting effect as apt-get completed cleanly.

I can't confirm any packet loss, I left a ping running while doing some resource intensive X stuff (opening chromium, browsing around while installing packages, system load was around 7.00 due to swapping) and only 4 out of ~4000 pings were lost; considering this ran via wireless, I don't seem to have the issue NickBT reported. :)

I'm running 3 devices off a powered USB hub connected to the RPi: Mouse, keyboard, Zyxel zd1211rw Wireless Adapter.

If you have any more patches that need testing or need more debugging info, let me know. :)

andreasjhkarlsson commented 12 years ago

I tried popcornmix's patch as well and the initial reaction was that it fixed my problems (My problems are described at the rpi forums: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=12949).

However after more extensive testing (taking snapshots with the webcam and sending it over the network for several hours) the problems reappear although with the following errors:

Aug 4 16:57:04 bengt kernel: uvcvideo: Failed to resubmit video URB (-1). Aug 4 16:59:05 bengt kernel: wlan0: deauthenticated from 4c:e6:76:c4:55:84 (Reason: 2)

I guess the time difference between the fail entries is due to some timeout for the wifi.

I guess that this could be another problem, however my feeling is that the patch doesn't go after the root cause of these problems but rather the symptoms.

sspies commented 12 years ago

I bought hardware from http://elinux.org/RPi_VerifiedPeripherals

Connected to Hama 4-way USB 2.0 Hub:

RPi PSU is 1000mA Hama PSU unknown

After booting up, everything seems to be recognized correctly, but once LXDE is started, wifi connection drops: http://pastebin.com/1aBVBeX3

Voltage constantly 4,9V

sulge commented 12 years ago

Unfortunately, I have the following erros when testing @popcornmix's patch: BUG: scheduling while atomic: testUSB.sh/1155/0x00000002 Modules linked in: ipv6 pl2303 ftdi_sio usbserial Backtrace: Function entered at [] from [] r6:cd860000 r5:ceb75440 r4:00000000 Function entered at [] from [] Function entered at [] from [] r4:c0427be0 Function entered at [] from [] Function entered at [] from [] Function entered at [] from [] Function entered at [] from [] Function entered at [] from [] Function entered at [] from [] r8:000000a1 r7:00000000 r6:00000000 r5:00000007 r4:cea707c0 Function entered at [] from [] Function entered at [] from [] Function entered at [] from [] Function entered at [] from [] r8:ceadf840 r7:cd9cdc00 r6:ceaaa634 r5:ceaaa604 r4:cd860000 Function entered at [] from [] r8:ceadf840 r7:0bc00000 r6:ceadf840 r5:ceaaa600 r4:cd9cdc00 Function entered at [] from [] r6:cd9cdc00 r5:ce9d18e0 r4:ce9d18e4 Function entered at [] from [] Function entered at [] from [] Function entered at [] from [] Function entered at [] from [] r7:00000000 r6:00000000 r5:cd861ed0 r4:ce958798 Function entered at [] from [] Function entered at [] from [] Function entered at [] from [] r8:00000003 r7:ceb16000 r6:000001b6 r5:00020241 r4:00000001 Function entered at [] from [] Function entered at [] from []

How can I help you to improve it?

rstolfa commented 12 years ago

Is there any word on this problem? I'm fighting it too, but I need a bit more help on getting the kernel sources and applying the patch from popcornmix ...unless it's out of testing and in the stable distribution?

popcornmix commented 12 years ago

Anyone with issues, can you udpate to latest firmware, and add: dwc_otg.microframe_schedule=1 to cmdline.txt and report if it improves anything. [edit: replaced config.txt with cmdline.txt]

fbutler commented 12 years ago

I can confirm that this has solved the periodic channel error messages for me. No error messages in /var/log/syslog and for the first time I'm successfully able to use a KVM.

An lsusb from the console shows all the devices correctly with no error messages: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. Bus 001 Device 004: ID 0424:2524 Standard Microsystems Corp. USB MultiSwitch Hub Bus 001 Device 005: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Bus 001 Device 006: ID 050d:3201 Belkin Components F1DF102U/F1DG102U Flip KVM Bus 001 Device 007: ID 046d:c062 Logitech, Inc. LS1 Laser Mouse, corded Bus 001 Device 008: ID 046d:0b04 Logitech, Inc. Bus 001 Device 009: ID 0a81:0101 Chesen Electronics Corp. Keyboard Bus 001 Device 010: ID eb1a:2861 eMPIA Technology, Inc. Bus 001 Device 011: ID 20a0:0001 Clay Logic Bus 001 Device 012: ID 045e:0737 Microsoft Corp. Compact Optical Mouse 500 Bus 001 Device 015: ID 046d:c713 Logitech, Inc. Bus 001 Device 016: ID 046d:c714 Logitech, Inc. diNovo Edge Keyboard

I'll test it further tonight with a 10 port hub and some more devices, but so far it's looking good.

Thanks to all for their work on this issue.

virtualguy commented 12 years ago

Loaded rpi-update and added dwc_otg.microframe_schedule=1 to my config.txt and I still get the usb errors. I also get ethernet related faults (which I am sure are caused by usb going down). With 6 usb devices all works fine (2x 4port hub, mouse, keyboard). Enable the other 4 port hub (my 10 port hub allows you to turn some ports off) and plug in a USB GSM modem (which enumerates as a whole lot of devices) and everything falls over again. Interestingly just the USB GSM modem works fine with nothing else on the USB bus (keyboard and mouse via synergy).

Is there anyway to check if the patch/fix is infact applied? Let me know if you need any debug info

asb commented 12 years ago

@virtualguy: I believe Dom meant to say cmdline.txt

virtualguy commented 12 years ago

A little bit of github stalking his other comments lead me to believe the same thing, just tried it now. Got a different errors: pi@raspberrypi ~ $ dmesg | tail -n 30 [ 40.812821] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 54.323238] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114 [ 60.413514] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 65.413727] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114 [ 72.023904] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 77.024113] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114 [ 84.334379] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114 [ 94.774748] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 99.774932] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114 [ 101.715204] usb 1-1.3.1.2: reset low-speed USB device number 7 using dwc_otg [ 109.345481] usb 1-1.3.1.2: reset low-speed USB device number 7 using dwc_otg [ 122.065841] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 127.065946] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114 [ 133.636205] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 138.636442] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114 [ 140.526725] usb 1-1.3.1.2: reset low-speed USB device number 7 using dwc_otg [ 146.266674] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 156.957066] hub 1-1.3.1:1.0: hub_port_status failed (err = -110) [ 156.957102] hub 1-1.3.1:1.0: connect-debounce failed, port 1 disabled [ 165.247428] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 165.247463] smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read [ 170.247585] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 177.357858] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 177.357924] smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read [ 182.358036] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 182.358089] smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read [ 188.458254] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 196.358794] usb 1-1.3.1.2: reset low-speed USB device number 7 using dwc_otg [ 204.043512] usb 1-1.3.2: USB disconnect, device number 6 [ 232.710113] usb 1-1.3.1.2: reset low-speed USB device number 7 using dwc_otg

virtualguy commented 12 years ago

Perhaps a more concrete result of the issue still being persistant. See the periodic transfer failure in dmesg below: dmesg | tail -n 30 [ 130.006004] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118 [ 132.026377] usb 1-1.3.1.2: reset low-speed USB device number 7 using dwc_otg [ 144.016506] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 164.957246] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 169.957467] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114 [ 183.037925] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118 [ 190.358398] usb 1-1.3.1.2: reset low-speed USB device number 7 using dwc_otg [ 208.978910] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 213.979717] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118 [ 224.069474] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114 [ 229.069674] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 [ 262.070875] hub 1-1.3.1:1.0: cannot reset port 1 (err = -110) [ 264.072250] usb 1-1.3.1.1: new high-speed USB device number 8 using dwc_otg [ 273.001295] usb 1-1.3.1.1: unable to read config index 0 descriptor/all [ 273.001359] usb 1-1.3.1.1: can't read configurations, error -110 [ 273.001484] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118 [ 274.211343] usb 1-1.3.1.1: new high-speed USB device number 9 using dwc_otg [ 279.020280] usb 1-1.3.1.1: New USB device found, idVendor=1a40, idProduct=0101 [ 279.020315] usb 1-1.3.1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 279.020335] usb 1-1.3.1.1: Product: USB 2.0 Hub [ 279.050900] hub 1-1.3.1.1:1.0: USB hub found [ 279.051161] hub 1-1.3.1.1:1.0: 4 ports detected [ 279.661520] INFO:: periodic_channel_available: Total channels: 8, Periodic: 7, Non-periodic: 1 [ 279.661537] [ 279.661558] INFO:: schedule_periodic: No host channel available for periodic transfer. [ 279.661569] [ 279.661605] ERROR::dwc_otg_hcd_urb_enqueue:498: DWC OTG HCD URB Enqueue failed adding QTD. Error status -28 [ 279.661618] [ 279.661648] hub 1-1.3.1.1:1.0: activate --> -28 [ 282.076255] usb 1-1.3.1.1.4: new full-speed USB device number 10 using dwc_otg

NickBT commented 12 years ago

The issue of having no wifi connectivity through LXDE is now resolved for me with Linux version 3.2.27+ #24 PREEMPT and dwc_otg.microframe_schedule=1 in cmdline.txt.

I have a 4 port Logik hub powering the Pi, basic USB kbd and mouse and a Belkin USB wifi dongle. wlan0 and eth0 are both up. I had previously seen dmesg output full of the same index 00000114/118 errors that others have been, and in some cases still are, reporting. I see no such errors now in my setup.

I should have added that I'm using Raspbian.

popcornmix commented 12 years ago

@virtualguy Have you added to dwc_otg.microframe_schedule=1 to cmdline.txt? (not config.txt as I originally mistyped)

virtualguy commented 12 years ago

I have indeed. I have updated my firmware do i need to update my kernel too? Currently running what i think is the latest, 3.2.27+ from the default wheezy install. On Aug 21, 2012 10:59 PM, "popcornmix" notifications@github.com wrote:

@virtualguy https://github.com/virtualguy Have you added to dwc_otg.microframe_schedule=1 to cmdline.txt? (not config.txt as I originally mistyped)

— Reply to this email directly or view it on GitHubhttps://github.com/raspberrypi/linux/issues/29#issuecomment-7897692.

popcornmix commented 12 years ago

@virtualguy You will need latest firmware from rpi-update. "uname -a" should be 18th August or later.

virtualguy commented 12 years ago

pi@raspberrypi ~ $ uname -a Linux raspberrypi 3.2.27+ #24 PREEMPT Sun Aug 19 21:28:36 BST 2012 armv6l GNU/Linux

I'll try a fresh install just to rule out any of the packages I have installed but looks to me like its still an issue. I'll also throw the scope on it today just to ensure the power supply is clean. I had have a powered hub providing +5V back upstream earlier but have "fixed" the hub now.

htahola commented 12 years ago

I have been trying to put up a video surveillance with usb-webcam and a USB-3G dongle. Using a 5V 5A PSU powering a USB hub (only as power distribution). Using USB-Y-cables to provide extra power for both camera and the 3G. I have applied the Aug 18 kernel patch, which made the improvement that I got it working in the first place. But it fails after random time. I then tried to put the 3G dongle on a separate 3G-router connected to PI with rj-45. That did not solve the case as I noticed the usb hub inside the Pi is a 3-port one. The rj-45 is just a usb device too. The problem, when it happens, persists over softboot. Only power off/on sorts it out. The problem occurs randomly in 6 hours or almost instantly after start. I Hope this helps in solving the problem. btw. I think half of the open issues (33) are related to this USB one. AND I added dwc_otg.microframe_schedule=1 to cmdline.txt :)

keithsuddick commented 12 years ago

I'd like to add my experience today: I have a D-Link, powered 7 port hub only, connected to my RPi, attached to the hub are a keyboard, mouse and D-Link DWA-140 wi-fi dongle - lsusb gives the following:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. Bus 001 Device 004: ID 2001:f103 D-Link Corp. DUB-H7 7-port USB 2.0 hub Bus 001 Device 005: ID 07d1:3c09 D-Link System DWA-140 RangeBooster N Adapter(rev.B1) [Ralink RT2870] Bus 001 Device 010: ID 0b38:0010 Gear Head 107-Key Keyboard Bus 001 Device 009: ID 413c:3016 Dell Computer Corp. Optical 5-Button Wheel Mouse

This combination has always worked at the command prompt but always failed when starting X - network connectivity fails, and mouse and keyboard work unpredictably even after exiting X.

After updating and adding dwc_otg.microframe_schedule=1 to cmdline.txt I can now start X and everything remains working - I can still SSH into the RPi and I can browse websites within X so this is a huge step forward from my point of view - thank you to those who contributed to this fix.

I am still seeing occasional errors and repeated reset messages for some of the USB devices and some have disconnected/reconnected as differently numbered devices, such as:

Aug 22 14:44:26 raspberrypi kernel: [ 146.284562] usb 1-1.3.5: reset low-speed USB device number 6 using dwc_otg Aug 22 14:53:30 raspberrypi kernel: [ 690.008420] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114 Aug 22 14:58:42 raspberrypi kernel: [ 1002.005468] usb 1-1.3.5: reset low-speed USB device number 6 using dwc_otg Aug 22 14:58:42 raspberrypi kernel: [ 1002.575513] usb 1-1.3.5: reset low-speed USB device number 6 using dwc_otg Aug 22 14:58:45 raspberrypi kernel: [ 1005.295643] usb 1-1.3.5: reset low-speed USB device number 6 using dwc_otg Aug 22 14:58:46 raspberrypi kernel: [ 1005.865597] usb 1-1.3.5: reset low-speed USB device number 6 using dwc_otg Aug 22 14:58:48 raspberrypi kernel: [ 1007.695616] usb 1-1.3.5: reset low-speed USB device number 6 using dwc_otg Aug 22 14:58:48 raspberrypi kernel: [ 1008.378570] usb 1-1.3.5: reset low-speed USB device number 6 using dwc_otg Aug 22 14:58:50 raspberrypi kernel: [ 1010.415711] usb 1-1.3.5: reset low-speed USB device number 6 using dwc_otg Aug 22 14:58:54 raspberrypi kernel: [ 1013.685787] usb 1-1.3.5: reset low-speed USB device number 6 using dwc_otg Aug 22 14:58:54 raspberrypi kernel: [ 1014.375376] usb 1-1.3.5: reset low-speed USB device number 6 using dwc_otg Aug 22 14:58:56 raspberrypi kernel: [ 1015.626104] hub 1-1.3:1.0: port 5 disabled by hub (EMI?), re-enabling... Aug 22 14:58:56 raspberrypi kernel: [ 1015.626332] usb 1-1.3.5: USB disconnect, device number 6 Aug 22 14:58:56 raspberrypi kernel: [ 1015.875795] usb 1-1.3.5: new low-speed USB device number 8 using dwc_otg Aug 22 14:58:56 raspberrypi kernel: [ 1015.980960] usb 1-1.3.5: New USB device found, idVendor=0b38, idProduct=0010 Aug 22 14:58:56 raspberrypi kernel: [ 1015.980994] usb 1-1.3.5: New USB device strings: Mfr=0, Product=0, SerialNumber=0

But this is a definite improvement. Thanks again.