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

hugin84 commented 12 years ago

... [ 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 commented 12 years ago

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 commented 12 years ago

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

9er commented 11 years ago

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:

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 commented 11 years ago

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

ghollingworth commented 11 years ago

Are you sure dwc_otg.speed=1 didn't make any difference?

I would think this should stop any problems because everything drops back to USB1.0

Gordon

On 25 September 2012 09:30, licaon-kter notifications@github.com wrote:

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

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

9er commented 11 years ago

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 commented 11 years ago

Can you do a

Sudo lsusb -v Sudo lsusb -t

And send the results with just the hub... I assume you have the latest kernel? This deals with channel scheduling properly so shouldn't be the cause of the issue

What are you actually plugging in, can you draw the hierarchy and try one device at a time getting the lsusb -v information for each device

Gordon

Gordon

On 26/09/2012, 9er notifications@github.com wrote:

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

Reply to this email directly or view it on GitHub: https://github.com/raspberrypi/linux/issues/29#issuecomment-8880844

Sent from my mobile device

9er commented 11 years ago

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 commented 11 years ago

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

audunmg commented 11 years ago

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?

ghollingworth commented 11 years ago

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