Skip to content
This repository

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

Closed
marsman2020 opened this Issue May 31, 2012 · 62 comments
Andrew Bingham

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

  1. 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

  2. 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

  3. On the Pi (do this while the download is running in the ssh window!) - Exited htop. Ran "Startx"

  4. 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)

  5. On the Pi - Exited X/LXDE ("Logout")

  6. On the other machine - Observed that the download returned to its original ~3MB/s speed as soon as the system returned to the console.

  7. 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

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

Andrew Bingham

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

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

  • raspberrypi/firmware#9
  • Test the voltage between TP1 and TP2 before and after. If you have a scope , see if it oscillates or oscillated differently.
  • Try a different powered hub, or try plugging things in a different order, into different ports (sometimes seems to work)
  • Try a different power supply
  • Try a different (simpler) keyboard and mouse
Andrew Bingham

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

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

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.

Andrew Bingham

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?

Andrew Bingham

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
NickBT commented June 08, 2012

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
jstsch commented June 10, 2012

Similar issues here. Also without running X. Setup:

  • Pi with the RS Electronics Micro USB Euro power supply
  • Belkin 7-Port USB hub
  • Logitech Pilot Mouse and Logitech K120 keyboard
  • TP-Link TL WN821N USB Wireless N Dongle

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
jstsch commented June 10, 2012

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

Andrew Bingham

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
NickBT commented June 11, 2012

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.

Grigori Goronzy grigorig referenced this issue from a commit in grigorig/rpi-linux January 04, 2012
usb: usb-storage doesn't support dynamic id currently, the patch disa…
…bles the feature to fix an oops

commit 1a3a026 upstream.

Echo vendor and product number of a non usb-storage device to
usb-storage driver's new_id, then plug in the device to host and you
will find following oops msg, the root cause is usb_stor_probe1()
refers invalid id entry if giving a dynamic id, so just disable the
feature.

[ 3105.018012] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 3105.018062] CPU 0
[ 3105.018075] Modules linked in: usb_storage usb_libusual bluetooth
dm_crypt binfmt_misc snd_hda_codec_analog snd_hda_intel snd_hda_codec
snd_hwdep hp_wmi ppdev sparse_keymap snd_pcm snd_seq_midi snd_rawmidi
snd_seq_midi_event snd_seq snd_timer snd_seq_device psmouse snd
serio_raw tpm_infineon soundcore i915 snd_page_alloc tpm_tis
parport_pc tpm tpm_bios drm_kms_helper drm i2c_algo_bit video lp
parport usbhid hid sg sr_mod sd_mod ehci_hcd uhci_hcd usbcore e1000e
usb_common floppy
[ 3105.018408]
[ 3105.018419] Pid: 189, comm: khubd Tainted: G          I  3.2.0-rc7+
#29 Hewlett-Packard HP Compaq dc7800p Convertible Minitower/0AACh
[ 3105.018481] RIP: 0010:[<ffffffffa045830d>]  [<ffffffffa045830d>]
usb_stor_probe1+0x2fd/0xc20 [usb_storage]
[ 3105.018536] RSP: 0018:ffff880056a3d830  EFLAGS: 00010286
[ 3105.018562] RAX: ffff880065f4e648 RBX: ffff88006bb28000 RCX: 0000000000000000
[ 3105.018597] RDX: ffff88006f23c7b0 RSI: 0000000000000001 RDI: 0000000000000206
[ 3105.018632] RBP: ffff880056a3d900 R08: 0000000000000000 R09: ffff880067365000
[ 3105.018665] R10: 00000000000002ac R11: 0000000000000010 R12: ffff6000b41a7340
[ 3105.018698] R13: ffff880065f4ef60 R14: ffff88006bb28b88 R15: ffff88006f23d270
[ 3105.018733] FS:  0000000000000000(0000) GS:ffff88007a200000(0000)
knlGS:0000000000000000
[ 3105.018773] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 3105.018801] CR2: 00007fc99c8c4650 CR3: 0000000001e05000 CR4: 00000000000006f0
[ 3105.018835] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 3105.018870] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 3105.018906] Process khubd (pid: 189, threadinfo ffff880056a3c000,
task ffff88005677a400)
[ 3105.018945] Stack:
[ 3105.018959]  0000000000000000 0000000000000000 ffff880056a3d8d0
0000000000000002
[ 3105.019011]  0000000000000000 ffff880056a3d918 ffff880000000000
0000000000000002
[ 3105.019058]  ffff880056a3d8d0 0000000000000012 ffff880056a3d8d0
0000000000000006
[ 3105.019105] Call Trace:
[ 3105.019128]  [<ffffffffa0458cd4>] storage_probe+0xa4/0xe0 [usb_storage]
[ 3105.019173]  [<ffffffffa0097822>] usb_probe_interface+0x172/0x330 [usbcore]
[ 3105.019211]  [<ffffffff815fda67>] driver_probe_device+0x257/0x3b0
[ 3105.019243]  [<ffffffff815fdd43>] __device_attach+0x73/0x90
[ 3105.019272]  [<ffffffff815fdcd0>] ? __driver_attach+0x110/0x110
[ 3105.019303]  [<ffffffff815fb93c>] bus_for_each_drv+0x9c/0xf0
[ 3105.019334]  [<ffffffff815fd6c7>] device_attach+0xf7/0x120
[ 3105.019364]  [<ffffffff815fc905>] bus_probe_device+0x45/0x80
[ 3105.019396]  [<ffffffff815f98a6>] device_add+0x876/0x990
[ 3105.019434]  [<ffffffffa0094e42>] usb_set_configuration+0x822/0x9e0 [usbcore]
[ 3105.019479]  [<ffffffffa00a3492>] generic_probe+0x62/0xf0 [usbcore]
[ 3105.019518]  [<ffffffffa0097a46>] usb_probe_device+0x66/0xb0 [usbcore]
[ 3105.019555]  [<ffffffff815fda67>] driver_probe_device+0x257/0x3b0
[ 3105.019589]  [<ffffffff815fdd43>] __device_attach+0x73/0x90
[ 3105.019617]  [<ffffffff815fdcd0>] ? __driver_attach+0x110/0x110
[ 3105.019648]  [<ffffffff815fb93c>] bus_for_each_drv+0x9c/0xf0
[ 3105.019680]  [<ffffffff815fd6c7>] device_attach+0xf7/0x120
[ 3105.019709]  [<ffffffff815fc905>] bus_probe_device+0x45/0x80
[ 3105.021040] usb usb6: usb auto-resume
[ 3105.021045] usb usb6: wakeup_rh
[ 3105.024849]  [<ffffffff815f98a6>] device_add+0x876/0x990
[ 3105.025086]  [<ffffffffa0088987>] usb_new_device+0x1e7/0x2b0 [usbcore]
[ 3105.025086]  [<ffffffffa008a4d7>] hub_thread+0xb27/0x1ec0 [usbcore]
[ 3105.025086]  [<ffffffff810d5200>] ? wake_up_bit+0x50/0x50
[ 3105.025086]  [<ffffffffa00899b0>] ? usb_remote_wakeup+0xa0/0xa0 [usbcore]
[ 3105.025086]  [<ffffffff810d49b8>] kthread+0xd8/0xf0
[ 3105.025086]  [<ffffffff81939884>] kernel_thread_helper+0x4/0x10
[ 3105.025086]  [<ffffffff8192a8c0>] ? _raw_spin_unlock_irq+0x50/0x80
[ 3105.025086]  [<ffffffff8192b1b4>] ? retint_restore_args+0x13/0x13
[ 3105.025086]  [<ffffffff810d48e0>] ? __init_kthread_worker+0x80/0x80
[ 3105.025086]  [<ffffffff81939880>] ? gs_change+0x13/0x13
[ 3105.025086] Code: 00 48 83 05 cd ad 00 00 01 48 83 05 cd ad 00 00
01 4c 8b ab 30 0c 00 00 48 8b 50 08 48 83 c0 30 48 89 45 a0 4c 89 a3
40 0c 00 00 <41> 0f b6 44 24 10 48 89 55 a8 3c ff 0f 84 b8 04 00 00 48
83 05
[ 3105.025086] RIP  [<ffffffffa045830d>] usb_stor_probe1+0x2fd/0xc20
[usb_storage]
[ 3105.025086]  RSP <ffff880056a3d830>
[ 3105.060037] hub 6-0:1.0: hub_resume
[ 3105.062616] usb usb5: usb auto-resume
[ 3105.064317] ehci_hcd 0000:00:1d.7: resume root hub
[ 3105.094809] ---[ end trace a7919e7f17c0a727 ]---
[ 3105.130069] hub 5-0:1.0: hub_resume
[ 3105.132131] usb usb4: usb auto-resume
[ 3105.132136] usb usb4: wakeup_rh
[ 3105.180059] hub 4-0:1.0: hub_resume
[ 3106.290052] usb usb6: suspend_rh (auto-stop)
[ 3106.290077] usb usb4: suspend_rh (auto-stop)

Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ab88872
guisacouto

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

@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

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
jstsch commented June 21, 2012

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

Andrew Bingham

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

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
g4eml commented June 22, 2012

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...

Ing. Jan Kaláb
Pitel commented June 25, 2012

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.

Neil McPhail

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
Owner

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.

Andrew Bingham

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
Owner

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
NickBT commented July 10, 2012

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

popcornmix popcornmix referenced this issue July 11, 2012
Closed

Usb problem #51

Andrew Bingham

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
mchr3k commented July 16, 2012

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
davr commented July 25, 2012

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).

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. :)

rotmoset

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

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

Connected to Hama 4-way USB 2.0 Hub:

  • Tenda W311U Mini 11N
  • Cherry Keyboard
  • Saitek Mouse

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

Bernhard M. Wiedemann bmwiedemann referenced this issue from a commit in bmwiedemann/raspberrypi-linux January 04, 2012
usb: usb-storage doesn't support dynamic id currently, the patch disa…
…bles the feature to fix an oops

Echo vendor and product number of a non usb-storage device to
usb-storage driver's new_id, then plug in the device to host and you
will find following oops msg, the root cause is usb_stor_probe1()
refers invalid id entry if giving a dynamic id, so just disable the
feature.

[ 3105.018012] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 3105.018062] CPU 0
[ 3105.018075] Modules linked in: usb_storage usb_libusual bluetooth
dm_crypt binfmt_misc snd_hda_codec_analog snd_hda_intel snd_hda_codec
snd_hwdep hp_wmi ppdev sparse_keymap snd_pcm snd_seq_midi snd_rawmidi
snd_seq_midi_event snd_seq snd_timer snd_seq_device psmouse snd
serio_raw tpm_infineon soundcore i915 snd_page_alloc tpm_tis
parport_pc tpm tpm_bios drm_kms_helper drm i2c_algo_bit video lp
parport usbhid hid sg sr_mod sd_mod ehci_hcd uhci_hcd usbcore e1000e
usb_common floppy
[ 3105.018408]
[ 3105.018419] Pid: 189, comm: khubd Tainted: G          I  3.2.0-rc7+
#29 Hewlett-Packard HP Compaq dc7800p Convertible Minitower/0AACh
[ 3105.018481] RIP: 0010:[<ffffffffa045830d>]  [<ffffffffa045830d>]
usb_stor_probe1+0x2fd/0xc20 [usb_storage]
[ 3105.018536] RSP: 0018:ffff880056a3d830  EFLAGS: 00010286
[ 3105.018562] RAX: ffff880065f4e648 RBX: ffff88006bb28000 RCX: 0000000000000000
[ 3105.018597] RDX: ffff88006f23c7b0 RSI: 0000000000000001 RDI: 0000000000000206
[ 3105.018632] RBP: ffff880056a3d900 R08: 0000000000000000 R09: ffff880067365000
[ 3105.018665] R10: 00000000000002ac R11: 0000000000000010 R12: ffff6000b41a7340
[ 3105.018698] R13: ffff880065f4ef60 R14: ffff88006bb28b88 R15: ffff88006f23d270
[ 3105.018733] FS:  0000000000000000(0000) GS:ffff88007a200000(0000)
knlGS:0000000000000000
[ 3105.018773] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 3105.018801] CR2: 00007fc99c8c4650 CR3: 0000000001e05000 CR4: 00000000000006f0
[ 3105.018835] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 3105.018870] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 3105.018906] Process khubd (pid: 189, threadinfo ffff880056a3c000,
task ffff88005677a400)
[ 3105.018945] Stack:
[ 3105.018959]  0000000000000000 0000000000000000 ffff880056a3d8d0
0000000000000002
[ 3105.019011]  0000000000000000 ffff880056a3d918 ffff880000000000
0000000000000002
[ 3105.019058]  ffff880056a3d8d0 0000000000000012 ffff880056a3d8d0
0000000000000006
[ 3105.019105] Call Trace:
[ 3105.019128]  [<ffffffffa0458cd4>] storage_probe+0xa4/0xe0 [usb_storage]
[ 3105.019173]  [<ffffffffa0097822>] usb_probe_interface+0x172/0x330 [usbcore]
[ 3105.019211]  [<ffffffff815fda67>] driver_probe_device+0x257/0x3b0
[ 3105.019243]  [<ffffffff815fdd43>] __device_attach+0x73/0x90
[ 3105.019272]  [<ffffffff815fdcd0>] ? __driver_attach+0x110/0x110
[ 3105.019303]  [<ffffffff815fb93c>] bus_for_each_drv+0x9c/0xf0
[ 3105.019334]  [<ffffffff815fd6c7>] device_attach+0xf7/0x120
[ 3105.019364]  [<ffffffff815fc905>] bus_probe_device+0x45/0x80
[ 3105.019396]  [<ffffffff815f98a6>] device_add+0x876/0x990
[ 3105.019434]  [<ffffffffa0094e42>] usb_set_configuration+0x822/0x9e0 [usbcore]
[ 3105.019479]  [<ffffffffa00a3492>] generic_probe+0x62/0xf0 [usbcore]
[ 3105.019518]  [<ffffffffa0097a46>] usb_probe_device+0x66/0xb0 [usbcore]
[ 3105.019555]  [<ffffffff815fda67>] driver_probe_device+0x257/0x3b0
[ 3105.019589]  [<ffffffff815fdd43>] __device_attach+0x73/0x90
[ 3105.019617]  [<ffffffff815fdcd0>] ? __driver_attach+0x110/0x110
[ 3105.019648]  [<ffffffff815fb93c>] bus_for_each_drv+0x9c/0xf0
[ 3105.019680]  [<ffffffff815fd6c7>] device_attach+0xf7/0x120
[ 3105.019709]  [<ffffffff815fc905>] bus_probe_device+0x45/0x80
[ 3105.021040] usb usb6: usb auto-resume
[ 3105.021045] usb usb6: wakeup_rh
[ 3105.024849]  [<ffffffff815f98a6>] device_add+0x876/0x990
[ 3105.025086]  [<ffffffffa0088987>] usb_new_device+0x1e7/0x2b0 [usbcore]
[ 3105.025086]  [<ffffffffa008a4d7>] hub_thread+0xb27/0x1ec0 [usbcore]
[ 3105.025086]  [<ffffffff810d5200>] ? wake_up_bit+0x50/0x50
[ 3105.025086]  [<ffffffffa00899b0>] ? usb_remote_wakeup+0xa0/0xa0 [usbcore]
[ 3105.025086]  [<ffffffff810d49b8>] kthread+0xd8/0xf0
[ 3105.025086]  [<ffffffff81939884>] kernel_thread_helper+0x4/0x10
[ 3105.025086]  [<ffffffff8192a8c0>] ? _raw_spin_unlock_irq+0x50/0x80
[ 3105.025086]  [<ffffffff8192b1b4>] ? retint_restore_args+0x13/0x13
[ 3105.025086]  [<ffffffff810d48e0>] ? __init_kthread_worker+0x80/0x80
[ 3105.025086]  [<ffffffff81939880>] ? gs_change+0x13/0x13
[ 3105.025086] Code: 00 48 83 05 cd ad 00 00 01 48 83 05 cd ad 00 00
01 4c 8b ab 30 0c 00 00 48 8b 50 08 48 83 c0 30 48 89 45 a0 4c 89 a3
40 0c 00 00 <41> 0f b6 44 24 10 48 89 55 a8 3c ff 0f 84 b8 04 00 00 48
83 05
[ 3105.025086] RIP  [<ffffffffa045830d>] usb_stor_probe1+0x2fd/0xc20
[usb_storage]
[ 3105.025086]  RSP <ffff880056a3d830>
[ 3105.060037] hub 6-0:1.0: hub_resume
[ 3105.062616] usb usb5: usb auto-resume
[ 3105.064317] ehci_hcd 0000:00:1d.7: resume root hub
[ 3105.094809] ---[ end trace a7919e7f17c0a727 ]---
[ 3105.130069] hub 5-0:1.0: hub_resume
[ 3105.132131] usb usb4: usb auto-resume
[ 3105.132136] usb usb4: wakeup_rh
[ 3105.180059] hub 4-0:1.0: hub_resume
[ 3106.290052] usb usb6: suspend_rh (auto-stop)
[ 3106.290077] usb usb4: suspend_rh (auto-stop)

Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
1a3a026
sulge

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

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
Owner

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

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

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

Alex Bradbury
Owner
asb commented August 21, 2012

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

virtualguy

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

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

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
Owner

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

virtualguy
popcornmix
Owner

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

virtualguy

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

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

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.

...
[ 191.485350] smsc95xx 1-1.1:1.0: eth0: kevent 4 may have been dropped
[ 191.493347] smsc95xx 1-1.1:1.0: eth0: kevent 4 may have been dropped
[ 191.497462] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
...

In my case the issue was apparently caused by a cheap powered 7 port USB hub.

Switching from a Samsung cellphone charger (output: 5V, 0.7A) to an HTC cellphone charger (output: 5V, 2A) allowed me to get rid of the powered hub which then made things work. Just putting tape on the +5V pin of the hub's upstream cable (as suggested at http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=7445&p=105118) did not solve the issue, neither did using the hub after only changing the power supply or powering the Pi from the hub

used devices: just a cheap basic Hama keyboard and a Logitech Mouseman Dual Optical:

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 014: ID 046d:c012 Logitech, Inc. Mouseman Dual Optical
Bus 001 Device 005: ID 04d9:1603 Holtek Semiconductor, Inc. Keyboard

With no free USB ports left this "solution" obviously won't work for everyone but at least it's a quick fix to get the Pi working at all.

peatmanb

I got my Raspberry Pi today and had this issue. ping times were great until I started X and then they were terrible and soon i would just lose network.

I read this thread and did :

sudo apt-get upgrade

I got rpi-update and updated my kernel to:

pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.2.27+ #114 PREEMPT Tue Sep 4 00:15:33 BST 2012 armv6l GNU/Linux

and I added :
dwc_otg.microframe_schedule=1

to the front of
/boot/cmdline.txt

Now everything is great. Thanks!
I had a Mac Keyboard so I had to use a USB powered hub. I guess thats part of the problem from reading this. Mine is USB 2.0 from IOGear.

licaon-kter

adding smsc95xx.turbo_mode=N to /boot/cmdline.txt alleviates the issue?

9er

Same issues here, but without using X. I've got a powered USB Hub with 3 usb-rs232 adapters connected to it. Works perfectly for about about 1-2 hours, then ethernet fails.

Sep 25 01:47:42 raspberrypi kernel: [22656.813350] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Sep 25 01:47:47 raspberrypi kernel: [22661.813241] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114
Sep 25 01:47:52 raspberrypi kernel: [22666.813084] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Sep 25 01:47:57 raspberrypi kernel: [22671.812965] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118

I'm using raspbian with the latest firmware.
Linux raspberrypi 3.2.27+ #168 PREEMPT Sat Sep 22 19:26:13 BST 2012 armv6l GNU/Linux

I've already tried:

  • smsc95xx.turbo_mode=N
  • dwc_otg.fiq_fix_enable=1
  • vm.min_free_kbytes = 32768
  • dwc_otg.microframe_schedule=1
  • dwc_otg.speed=1

and different combinations of these settings. (but not all)
I also tried different power supplies, as well as powering the RPi from the Hub, but there was no difference. The hub can also be used without power supply, but again, that doesn't change anything.
As I'm writing this, ethernet failed again.
Is there any chance this gets fixed?

licaon-kter

BTW, dwc_otg.fiq_fix_enable & dwc_otg.microframe_schedule are already included and activated, you can only disable them

ghollingworth
9er

Updated firmware to
Linux raspberrypi 3.2.27+ #171 PREEMPT Tue Sep 25 00:08:57 BST 2012 armv6l
and set dwc_otg.speed=1.
So now it fails the moment, I plug in the USB hub (or on boot if its already plugged in). But I've just noticed something interesting, that (at least I think) wasn't happening before: When I unplug the Hub with all the attatched stuff, ethernet starts working again (smcs95xx gets registered on usb). I think this is because of the limited number of channels?
I tried unplugging the UPS and it's working for now. The weird thing is, with firmware #160 and #168 it's been working with all the connected devices, even the UPS. At least for about an hour...

ghollingworth
9er

Yep, latest kernel on raspbian.
Basicly I'm just plugging in the hub (which I think is actually two hubs internally) and then everything (three RS232 adapters and my UPS) into the hub.

Here are some pastes:

by the way I removed set dwc_otg.speed=1 to try this.

ghollingworth

OK there is a huge amount of interrupts per second in that system, basically you're looking at something like 60K interrupts per second just with the serial connections...

You could try increasing the ignore time for the NAK interrupting in the dwc_otg driver (this is the last change I made) currently when a bulk endpoint is NAK'd I don't bother retransmitting for a whole frame (8 uframes) this reduces the interrupt over head but it's still something like 17K interrupts per second for a single serial device.

Gordon

popcornmix popcornmix referenced this issue from a commit February 22, 2012
x86: Remove some noise from boot log when starting cpus
Printing the "start_ip" for every secondary cpu is very noisy on a large
system - and doesn't add any value. Drop this message.

Console log before:
Booting Node   0, Processors  #1
smpboot cpu 1: start_ip = 96000
 #2
smpboot cpu 2: start_ip = 96000
 #3
smpboot cpu 3: start_ip = 96000
 #4
smpboot cpu 4: start_ip = 96000
       ...
 #31
smpboot cpu 31: start_ip = 96000
Brought up 32 CPUs

Console log after:
Booting Node   0, Processors  #1 #2 #3 #4 #5 #6 #7 Ok.
Booting Node   1, Processors  #8 #9 #10 #11 #12 #13 #14 #15 Ok.
Booting Node   0, Processors  #16 #17 #18 #19 #20 #21 #22 #23 Ok.
Booting Node   1, Processors  #24 #25 #26 #27 #28 #29 #30 #31
Brought up 32 CPUs

Acked-by: Borislav Petkov <bp@amd64.org>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Link: http://lkml.kernel.org/r/4f452eb42507460426@agluck-desktop.sc.intel.com
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
140f190
feitingen

I'm seeing similar behavior when displaying X windows from a remote machine with a lot of updates.
It works fine for a while, but after an hour or so, the connection drops, and I'm unable to shell in, I'm getting error "Wrong password" for 10-15 seconds, and then it resumes operation as usual.
Any chance this will be fixed?

Stephen Warren swarren referenced this issue from a commit in swarren/linux-rpi January 31, 2013
Lars-Peter Clausen staging:iio:adxrs450: Reflow overlong lines
Reflow two lines to meet the 80 characters per line limit.

Fixes the following checkpatch warnings:
	WARNING: line over 80 characters
	#29: FILE: staging/iio/gyro/adxrs450_core.c:29:
	+ * @reg_address: the address of the lower of the two registers,which should be an even address,

	WARNING: line over 80 characters
	#81: FILE: staging/iio/gyro/adxrs450_core.c:81:
	+ * @reg_address: the address of the lower of the two registers,which should be an even address,

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
1439b6e
Gregory Haskins ghaskins referenced this issue from a commit in ghaskins/raspberrypi-rt July 11, 2012
Subject: perf: Make swevent hrtimer run in irq instead of softirq
Otherwise we get a deadlock like below:

[ 1044.042749] BUG: scheduling while atomic: ksoftirqd/21/141/0x00010003
[ 1044.042752] INFO: lockdep is turned off.
[ 1044.042754] Modules linked in:
[ 1044.042757] Pid: 141, comm: ksoftirqd/21 Tainted: G        W    3.4.0-rc2-rt3-23676-ga723175-dirty #29
[ 1044.042759] Call Trace:
[ 1044.042761]  <IRQ>  [<ffffffff8107d8e5>] __schedule_bug+0x65/0x80
[ 1044.042770]  [<ffffffff8168978c>] __schedule+0x83c/0xa70
[ 1044.042775]  [<ffffffff8106bdd2>] ? prepare_to_wait+0x32/0xb0
[ 1044.042779]  [<ffffffff81689a5e>] schedule+0x2e/0xa0
[ 1044.042782]  [<ffffffff81071ebd>] hrtimer_wait_for_timer+0x6d/0xb0
[ 1044.042786]  [<ffffffff8106bb30>] ? wake_up_bit+0x40/0x40
[ 1044.042790]  [<ffffffff81071f20>] hrtimer_cancel+0x20/0x40
[ 1044.042794]  [<ffffffff8111da0c>] perf_swevent_cancel_hrtimer+0x3c/0x50
[ 1044.042798]  [<ffffffff8111da31>] task_clock_event_stop+0x11/0x40
[ 1044.042802]  [<ffffffff8111da6e>] task_clock_event_del+0xe/0x10
[ 1044.042805]  [<ffffffff8111c568>] event_sched_out+0x118/0x1d0
[ 1044.042809]  [<ffffffff8111c649>] group_sched_out+0x29/0x90
[ 1044.042813]  [<ffffffff8111ed7e>] __perf_event_disable+0x18e/0x200
[ 1044.042817]  [<ffffffff8111c343>] remote_function+0x63/0x70
[ 1044.042821]  [<ffffffff810b0aae>] generic_smp_call_function_single_interrupt+0xce/0x120
[ 1044.042826]  [<ffffffff81022bc7>] smp_call_function_single_interrupt+0x27/0x40
[ 1044.042831]  [<ffffffff8168d50c>] call_function_single_interrupt+0x6c/0x80
[ 1044.042833]  <EOI>  [<ffffffff811275b0>] ? perf_event_overflow+0x20/0x20
[ 1044.042840]  [<ffffffff8168b970>] ? _raw_spin_unlock_irq+0x30/0x70
[ 1044.042844]  [<ffffffff8168b976>] ? _raw_spin_unlock_irq+0x36/0x70
[ 1044.042848]  [<ffffffff810702e2>] run_hrtimer_softirq+0xc2/0x200
[ 1044.042853]  [<ffffffff811275b0>] ? perf_event_overflow+0x20/0x20
[ 1044.042857]  [<ffffffff81045265>] __do_softirq_common+0xf5/0x3a0
[ 1044.042862]  [<ffffffff81045c3d>] __thread_do_softirq+0x15d/0x200
[ 1044.042865]  [<ffffffff81045dda>] run_ksoftirqd+0xfa/0x210
[ 1044.042869]  [<ffffffff81045ce0>] ? __thread_do_softirq+0x200/0x200
[ 1044.042873]  [<ffffffff81045ce0>] ? __thread_do_softirq+0x200/0x200
[ 1044.042877]  [<ffffffff8106b596>] kthread+0xb6/0xc0
[ 1044.042881]  [<ffffffff8168b97b>] ? _raw_spin_unlock_irq+0x3b/0x70
[ 1044.042886]  [<ffffffff8168d994>] kernel_thread_helper+0x4/0x10
[ 1044.042889]  [<ffffffff8107d98c>] ? finish_task_switch+0x8c/0x110
[ 1044.042894]  [<ffffffff8168b97b>] ? _raw_spin_unlock_irq+0x3b/0x70
[ 1044.042897]  [<ffffffff8168bd5d>] ? retint_restore_args+0xe/0xe
[ 1044.042900]  [<ffffffff8106b4e0>] ? kthreadd+0x1e0/0x1e0
[ 1044.042902]  [<ffffffff8168d990>] ? gs_change+0xb/0xb

Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1341476476-5666-1-git-send-email-yong.zhang0@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
1e15b4b
Stephen Warren swarren referenced this issue from a commit in swarren/linux-rpi February 16, 2013
jmberg iwlwifi: mvm: fix time event command handling race
Occasionally, we would run into this warning:

  iwlwifi 0000:02:00.0: U iwl_mvm_protect_session extend 0x2601: only 200 ms left
  iwlwifi 0000:02:00.0: U iwl_mvm_remove_time_event Removing TE 0x2601
  iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0925, 60 bytes at 37[5]:9
  iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command TIME_EVENT_CMD
  iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command TIME_EVENT_CMD
  iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0926, 60 bytes at 38[6]:9
  iwlwifi 0000:02:00.0: U iwl_mvm_time_event_response TIME_EVENT_CMD response - UID = 0x2601
  iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command TIME_EVENT_CMD
  iwlwifi 0000:02:00.0: U iwl_mvm_rx_time_event_notif Time event notification - UID = 0x2701 action 1
  wlan0: associate with 00:0a:b8:55:a8:30 (try 2/3)
  ------------[ cut here ]------------
  WARNING: at drivers/net/wireless/iwlwifi/mvm/time-event.c:269 iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]()
  Modules linked in: [...]
  Call Trace:
   [<c1046e42>] warn_slowpath_common+0x72/0xa0
   [<c1046e92>] warn_slowpath_null+0x22/0x30
   [<f8cad913>] iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]
   [<f8cadead>] iwl_mvm_protect_session+0xcd/0x1c0 [iwlmvm]
   [<f8ca2087>] iwl_mvm_mac_mgd_prepare_tx+0x67/0xa0 [iwlmvm]
   [<f882a130>] ieee80211_sta_work+0x8f0/0x1070 [mac80211]

The reason is a problem with asynchronous vs. synchronous
commands, what happens here is the following:
 * TE 0x2601 is removed, the TIME_EVENT_CMD for that is async
 * a new TE (will be 0x2701) is created, the TIME_EVENT_CMD
   for that is sync and also uses a notification wait for the
   response (to avoid another race condition)
 * the response for the TE 0x2601 removal comes from the
   firmware, and is handled by the notification wait handler
   that's really waiting for the second response, but can't
   tell the difference, we therefore see the message
   "TIME_EVENT_CMD response - UID = 0x2601" instead of
   "TIME_EVENT_CMD response - UID = 0x2701".

Fix this issue by making the TE removal synchronous as well,
this means that we wait for the response to that command
first, before there's any chance of sending a new one.

Also, to detect such issues more easily in the future, add
a warning to the notification handler that detects them.

Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
e372282
Stephen Warren swarren referenced this issue from a commit in swarren/linux-rpi April 04, 2013
Lai Jiangshan workqueue: avoid false negative WARN_ON() in destroy_workqueue()
destroy_workqueue() performs several sanity checks before proceeding
with destruction of a workqueue.  One of the checks verifies that
refcnt of each pwq (pool_workqueue) is over 1 as at that point there
should be no in-flight work items and the only holder of pwq refs is
the workqueue itself.

This worked fine as a workqueue used to hold only one reference to its
pwqs; however, since 4c16bd3 ("workqueue: implement NUMA affinity
for unbound workqueues"), a workqueue may hold multiple references to
its default pwq triggering this sanity check spuriously.

Fix it by not triggering the pwq->refcnt assertion on default pwqs.

An example spurious WARN trigger follows.

 WARNING: at kernel/workqueue.c:4201 destroy_workqueue+0x6a/0x13e()
 Hardware name: 4286C12
 Modules linked in: sdhci_pci sdhci mmc_core usb_storage i915 drm_kms_helper drm i2c_algo_bit i2c_core video
 Pid: 361, comm: umount Not tainted 3.9.0-rc5+ #29
 Call Trace:
  [<c04314a7>] warn_slowpath_common+0x7c/0x93
  [<c04314e0>] warn_slowpath_null+0x22/0x24
  [<c044796a>] destroy_workqueue+0x6a/0x13e
  [<c056dc01>] ext4_put_super+0x43/0x2c4
  [<c04fb7b8>] generic_shutdown_super+0x4b/0xb9
  [<c04fb848>] kill_block_super+0x22/0x60
  [<c04fb960>] deactivate_locked_super+0x2f/0x56
  [<c04fc41b>] deactivate_super+0x2e/0x31
  [<c050f1e6>] mntput_no_expire+0x103/0x108
  [<c050fdce>] sys_umount+0x2a2/0x2c4
  [<c050fe0e>] sys_oldumount+0x1e/0x20
  [<c085ba4d>] sysenter_do_call+0x12/0x38

tj: Rewrote description.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
5c52959
ghollingworth
Owner

Many USB issues fixed... Please reopen if still a problem

ghollingworth ghollingworth closed this August 22, 2013
Stephen Warren swarren referenced this issue from a commit in swarren/linux-rpi September 27, 2013
x86: Improve the printout of the SMP bootup CPU table
As the new x86 CPU bootup printout format code maintainer, I am
taking immediate action to improve and clean (and thus indulge
my OCD) the reporting of the cores when coming up online.

Fix padding to a right-hand alignment, cleanup code and bind
reporting width to the max number of supported CPUs on the
system, like this:

 [    0.074509] smpboot: Booting Node   0, Processors:      #1  #2  #3  #4  #5  #6  #7 OK
 [    0.644008] smpboot: Booting Node   1, Processors:  #8  #9 #10 #11 #12 #13 #14 #15 OK
 [    1.245006] smpboot: Booting Node   2, Processors: #16 #17 #18 #19 #20 #21 #22 #23 OK
 [    1.864005] smpboot: Booting Node   3, Processors: #24 #25 #26 #27 #28 #29 #30 #31 OK
 [    2.489005] smpboot: Booting Node   4, Processors: #32 #33 #34 #35 #36 #37 #38 #39 OK
 [    3.093005] smpboot: Booting Node   5, Processors: #40 #41 #42 #43 #44 #45 #46 #47 OK
 [    3.698005] smpboot: Booting Node   6, Processors: #48 #49 #50 #51 #52 #53 #54 #55 OK
 [    4.304005] smpboot: Booting Node   7, Processors: #56 #57 #58 #59 #60 #61 #62 #63 OK
 [    4.961413] Brought up 64 CPUs

and this:

 [    0.072367] smpboot: Booting Node   0, Processors:    #1 #2 #3 #4 #5 #6 #7 OK
 [    0.686329] Brought up 8 CPUs

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Libin <huawei.libin@huawei.com>
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Link: http://lkml.kernel.org/r/20130927143554.GF4422@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
646e29a
Stephen Warren swarren referenced this issue from a commit in swarren/linux-rpi September 30, 2013
x86/boot: Further compress CPUs bootup message
Turn it into (for example):

[    0.073380] x86: Booting SMP configuration:
[    0.074005] .... node   #0, CPUs:          #1   #2   #3   #4   #5   #6   #7
[    0.603005] .... node   #1, CPUs:     #8   #9  #10  #11  #12  #13  #14  #15
[    1.200005] .... node   #2, CPUs:    #16  #17  #18  #19  #20  #21  #22  #23
[    1.796005] .... node   #3, CPUs:    #24  #25  #26  #27  #28  #29  #30  #31
[    2.393005] .... node   #4, CPUs:    #32  #33  #34  #35  #36  #37  #38  #39
[    2.996005] .... node   #5, CPUs:    #40  #41  #42  #43  #44  #45  #46  #47
[    3.600005] .... node   #6, CPUs:    #48  #49  #50  #51  #52  #53  #54  #55
[    4.202005] .... node   #7, CPUs:    #56  #57  #58  #59  #60  #61  #62  #63
[    4.811005] .... node   #8, CPUs:    #64  #65  #66  #67  #68  #69  #70  #71
[    5.421006] .... node   #9, CPUs:    #72  #73  #74  #75  #76  #77  #78  #79
[    6.032005] .... node  #10, CPUs:    #80  #81  #82  #83  #84  #85  #86  #87
[    6.648006] .... node  #11, CPUs:    #88  #89  #90  #91  #92  #93  #94  #95
[    7.262005] .... node  #12, CPUs:    #96  #97  #98  #99 #100 #101 #102 #103
[    7.865005] .... node  #13, CPUs:   #104 #105 #106 #107 #108 #109 #110 #111
[    8.466005] .... node  #14, CPUs:   #112 #113 #114 #115 #116 #117 #118 #119
[    9.073006] .... node  #15, CPUs:   #120 #121 #122 #123 #124 #125 #126 #127
[    9.679901] x86: Booted up 16 nodes, 128 CPUs

and drop useless elements.

Change num_digits() to hpa's division-avoiding, cell-phone-typed
version which he went at great lengths and pains to submit on a
Saturday evening.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: huawei.libin@huawei.com
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
a17bce4
Stephen Warren swarren referenced this issue from a commit in swarren/linux-rpi January 20, 2014
stmmac: Fix kernel crashes for jumbo frames
These changes correct the following issues with jumbo frames on the
stmmac driver:

1) The Synopsys EMAC can be configured to support different FIFO
sizes at core configuration time. There's no way to query the
controller and know the FIFO size, so the driver needs to get this
information from the device tree in order to know how to correctly
handle MTU changes and setting up dma buffers. The default
max-frame-size is as currently used, which is the size of a jumbo
frame.

2) The driver was enabling Jumbo frames by default, but was not allocating
dma buffers of sufficient size to handle the maximum possible packet
size that could be received. This led to memory corruption since DMAs were
occurring beyond the extent of the allocated receive buffers for certain types
of network traffic.

kernel BUG at net/core/skbuff.c:126!
Internal error: Oops - BUG: 0 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 563 Comm: sockperf Not tainted 3.13.0-rc6-01523-gf7111b9 #31
task: ef35e580 ti: ef252000 task.ti: ef252000
PC is at skb_panic+0x60/0x64
LR is at skb_panic+0x60/0x64
pc : [<c03c7c3c>]    lr : [<c03c7c3c>]    psr: 60000113
sp : ef253c18  ip : 60000113  fp : 00000000
r10: ef3a5400  r9 : 00000ebc  r8 : ef3a546c
r7 : ee59f000  r6 : ee59f084  r5 : ee59ff40  r4 : ee59f140
r3 : 000003e2  r2 : 00000007  r1 : c0b9c420  r0 : 0000007d
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 2e8ac04a  DAC: 00000015
Process sockperf (pid: 563, stack limit = 0xef252248)
Stack: (0xef253c18 to 0xef254000)
3c00:                                                       00000ebc ee59f000
3c20: ee59f084 ee59ff40 ee59f140 c04a9cd8 ee8c50c0 00000ebc ee59ff40 00000000
3c40: ee59f140 c02d0ef0 00000056 ef1eda80 ee8c50c0 00000ebc 22bbef29 c0318f8c
3c60: 00000056 ef3a547c ffe2c716 c02c9c90 c0ba1298 ef3a5838 ef3a5838 ef3a5400
3c80: 000020c0 ee573840 000055cb ef3f2050 c053f0e0 c0319214 22b9b085 22d92813
3ca0: 00001c80 004b8e00 ef3a5400 ee573840 ef3f2064 22d92813 ef3f2064 000055cb
3cc0: ef3f2050 c031a19c ef252000 00000000 00000000 c0561bc0 00000000 ff00ffff
3ce0: c05621c0 ef3a5400 ef3f2064 ee573840 00000020 ef3f2064 000055cb ef3f2050
3d00: c053f0e0 c031cad0 c053e740 00000e60 00000000 00000000 ee573840 ef3a5400
3d20: ef0a6e00 00000000 ef3f2064 c032507c 00010000 00000020 c0561bc0 c0561bc0
3d40: ee599850 c032799c 00000000 ee573840 c055a380 ef3a5400 00000000 ef3f2064
3d60: ef3f2050 c032799c 0101c7c0 2b6755cb c059a280 c030e4d8 000055cb ffffffff
3d80: ee574fc0 c055a380 ee574000 ee573840 00002b67 ee573840 c03fe9c4 c053fa68
3da0: c055a380 00001f6f 00000000 ee573840 c053f0e0 c0304fdc ef0a6e01 ef3f2050
3dc0: ee573858 ef031000 ee573840 c03055d8 c0ba0c40 ef000f40 00100100 c053f0dc
3de0: c053ffdc c053f0f0 00000008 00000000 ef031000 c02da948 00001140 00000000
3e00: c0563c78 ef253e5f 00000020 ee573840 00000020 c053f0f0 ef313400 ee573840
3e20: c053f0e0 00000000 00000000 c05380c0 ef313400 00001000 00000015 c02df280
3e40: ee574000 ef001e00 00000000 00001080 00000042 005cd980 ef031500 ef031500
3e60: 00000000 c02df824 ef031500 c053e390 c0541084 f00b1e00 c05925e8 c02df864
3e80: 00001f5c ef031440 c053e390 c0278524 00000002 00000000 c0b9eb48 c02df280
3ea0: ee8c7180 00000100 c0542ca8 00000015 00000040 ef031500 ef031500 ef031500
3ec0: c027803c ef252000 00000040 000000ec c05380c0 c0b9eb40 c0b9eb48 c02df940
3ee0: ef060780 ffffa4dd c0564a9c c056343c 002e80a8 00000080 ef031500 00000001
3f00: c053808c ef252000 fffec100 00000003 00000004 002e80a8 0000000c c00258f0
3f20: 002e80a8 c005e704 00000005 00000100 c05634d0 c0538080 c05333e0 00000000
3f40: 0000000a c0565580 c05380c0 ffffa4dc c05434f4 00400100 00000004 c0534cd4
3f60: 00000098 00000000 fffec100 002e80a8 00000004 002e80a8 002a20e0 c0025da8
3f80: c0534cd4 c000f020 fffec10c c053ea60 ef253fb0 c0008530 0000ffe2 b6ef67f4
3fa0: 40000010 ffffffff 00000124 c0012f3c 0000ffe2 002e80f0 0000ffe2 00004000
3fc0: becb6338 becb6334 00000004 00000124 002e80a8 00000004 002e80a8 002a20e0
3fe0: becb6300 becb62f4 002773bb b6ef67f4 40000010 ffffffff 00000000 00000000
[<c03c7c3c>] (skb_panic+0x60/0x64) from [<c02d0ef0>] (skb_put+0x4c/0x50)
[<c02d0ef0>] (skb_put+0x4c/0x50) from [<c0318f8c>] (tcp_collapse+0x314/0x3ec)
[<c0318f8c>] (tcp_collapse+0x314/0x3ec) from [<c0319214>]
(tcp_try_rmem_schedule+0x1b0/0x3c4)
[<c0319214>] (tcp_try_rmem_schedule+0x1b0/0x3c4) from [<c031a19c>]
(tcp_data_queue+0x480/0xe6c)
[<c031a19c>] (tcp_data_queue+0x480/0xe6c) from [<c031cad0>]
(tcp_rcv_established+0x180/0x62c)
[<c031cad0>] (tcp_rcv_established+0x180/0x62c) from [<c032507c>]
(tcp_v4_do_rcv+0x13c/0x31c)
[<c032507c>] (tcp_v4_do_rcv+0x13c/0x31c) from [<c032799c>]
(tcp_v4_rcv+0x718/0x73c)
[<c032799c>] (tcp_v4_rcv+0x718/0x73c) from [<c0304fdc>]
(ip_local_deliver+0x98/0x274)
[<c0304fdc>] (ip_local_deliver+0x98/0x274) from [<c03055d8>]
(ip_rcv+0x420/0x758)
[<c03055d8>] (ip_rcv+0x420/0x758) from [<c02da948>]
(__netif_receive_skb_core+0x44c/0x5bc)
[<c02da948>] (__netif_receive_skb_core+0x44c/0x5bc) from [<c02df280>]
(netif_receive_skb+0x48/0xb4)
[<c02df280>] (netif_receive_skb+0x48/0xb4) from [<c02df824>]
(napi_gro_flush+0x70/0x94)
[<c02df824>] (napi_gro_flush+0x70/0x94) from [<c02df864>]
(napi_complete+0x1c/0x34)
[<c02df864>] (napi_complete+0x1c/0x34) from [<c0278524>]
(stmmac_poll+0x4e8/0x5c8)
[<c0278524>] (stmmac_poll+0x4e8/0x5c8) from [<c02df940>]
(net_rx_action+0xc4/0x1e4)
[<c02df940>] (net_rx_action+0xc4/0x1e4) from [<c00258f0>]
(__do_softirq+0x12c/0x2e8)
[<c00258f0>] (__do_softirq+0x12c/0x2e8) from [<c0025da8>] (irq_exit+0x78/0xac)
[<c0025da8>] (irq_exit+0x78/0xac) from [<c000f020>] (handle_IRQ+0x44/0x90)
[<c000f020>] (handle_IRQ+0x44/0x90) from [<c0008530>]
(gic_handle_irq+0x2c/0x5c)
[<c0008530>] (gic_handle_irq+0x2c/0x5c) from [<c0012f3c>]
(__irq_usr+0x3c/0x60)

3) The driver was setting the dma buffer size after allocating dma buffers,
which caused a system panic when changing the MTU.

BUG: Bad page state in process ifconfig  pfn:2e850
page:c0b72a00 count:0 mapcount:0 mapping:  (null) index:0x0
page flags: 0x200(arch_1)
Modules linked in:
CPU: 0 PID: 566 Comm: ifconfig Not tainted 3.13.0-rc6-01523-gf7111b9 #29
[<c001547c>] (unwind_backtrace+0x0/0xf8) from [<c00122dc>]
(show_stack+0x10/0x14)
[<c00122dc>] (show_stack+0x10/0x14) from [<c03c793c>] (dump_stack+0x70/0x88)
[<c03c793c>] (dump_stack+0x70/0x88) from [<c00b2620>] (bad_page+0xc8/0x118)
[<c00b2620>] (bad_page+0xc8/0x118) from [<c00b302c>]
(get_page_from_freelist+0x744/0x870)
[<c00b302c>] (get_page_from_freelist+0x744/0x870) from [<c00b40f4>]
(__alloc_pages_nodemask+0x118/0x86c)
[<c00b40f4>] (__alloc_pages_nodemask+0x118/0x86c) from [<c00b4858>]
(__get_free_pages+0x10/0x54)
[<c00b4858>] (__get_free_pages+0x10/0x54) from [<c00cba1c>]
(kmalloc_order_trace+0x24/0xa0)
[<c00cba1c>] (kmalloc_order_trace+0x24/0xa0) from [<c02d199c>]
(__kmalloc_reserve.isra.21+0x24/0x70)
[<c02d199c>] (__kmalloc_reserve.isra.21+0x24/0x70) from [<c02d240c>]
(__alloc_skb+0x68/0x13c)
[<c02d240c>] (__alloc_skb+0x68/0x13c) from [<c02d3930>]
(__netdev_alloc_skb+0x3c/0xe8)
[<c02d3930>] (__netdev_alloc_skb+0x3c/0xe8) from [<c0279378>]
(stmmac_open+0x63c/0x1024)
[<c0279378>] (stmmac_open+0x63c/0x1024) from [<c02e18cc>]
(__dev_open+0xa0/0xfc)
[<c02e18cc>] (__dev_open+0xa0/0xfc) from [<c02e1b40>]
(__dev_change_flags+0x94/0x158)
[<c02e1b40>] (__dev_change_flags+0x94/0x158) from [<c02e1c24>]
(dev_change_flags+0x18/0x48)
[<c02e1c24>] (dev_change_flags+0x18/0x48) from [<c0337bc0>]
(devinet_ioctl+0x638/0x700)
[<c0337bc0>] (devinet_ioctl+0x638/0x700) from [<c02c7aec>]
(sock_ioctl+0x64/0x290)
[<c02c7aec>] (sock_ioctl+0x64/0x290) from [<c0100890>]
(do_vfs_ioctl+0x78/0x5b8)
[<c0100890>] (do_vfs_ioctl+0x78/0x5b8) from [<c0100e0c>] (SyS_ioctl+0x3c/0x5c)
[<c0100e0c>] (SyS_ioctl+0x3c/0x5c) from [<c000e760>]

The fixes have been verified using reproducible, automated testing.

Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2618abb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.