Really odd wifi behaviour! LXDE kills it...

[piglet]

I've spent most of the evening on irc with a very nice chap helping me setup wifi on my pi. I'm most grateful.

Dongle Model: D-Link DWA-140

I currently have it plugged into a (very cheap) external usb hub powered by a good 3A supply. At boot it connects perfectly to the router. All the signs are good.

I can ssh into the pi through the wlan0 ip address and all is well.

As soon as I fire up lxde the pi starts to run far slower than it does on wired connection, and it pretty much dies. No connectivity to internet; ip addr hangs; iwconfig hangs. Everything pretty much borked even after a logout of lxde and will lock up if I try and do iwconfig.

The end of dmesg output looked like this when I was in lxde:

Code: Select all

smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
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
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
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

and this after logging off from lxde (or at least after I took the bit above and before I ran dmesg again from the main shell):

Code: Select all

phy0 -> rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x1208 with error -110.
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
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
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
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
phy0 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x1208 with error -110.
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
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
smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
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
bcm2708_fb_check_var info(cb888000) 1824x984 (1824x984), 3620864, 16
bcm2708_fb_check_var var(cb9d5cfc) 1824x984 (1824x984), 16, 1810432
bcm2708_fb_set_par info(cb888000) 1824x984 (1824x984), 3620864, 16
BCM2708FB: start = cd000000,4d6fa000 width=1824, height=984, bpp=16, pitch=3648 size=3620864 success=0
phy0 -> rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x1208 with error -110.

Any ideas?

[piglet]

Code for one message is here:

http://webcache.googleusercontent.com/s ... =firefox-a

On the main set, it seems very similar to problems reported here: http://www.raspberrypi.org/phpBB3/viewt ... 65&p=80648

A rather better hub is in the post. I'll try that when it comes.

It just seems odd that this only happens when lxde is started. That will cause higher pi power usage, but the hub is +5v isolated from the pi as I completely removed pin 1 from the cable from hub to pi so that seems odd.

[jbeale]

if the Pi is suffering a "brownout" due to software activity causing increased power draw and lowering its onboard voltage, removing a USB power pin won't necessarily improve matters. Have you checked that the voltage between TP1 and TP2 on the board is healthy (4.75 - 5.25 V) ? See also: http://elinux.org/R-Pi_Troubleshooting# ... r_problems

[piglet]

Ok - everything moved to powered hub: Mouse, keyboard, dongle. Hub not connected with +5V on lead to pi. Same issue on starting lxde:

TP1 to TP2 is 4.82V while this is happening. ssh session got disconnected the moment i startx'd. The CPU usage monitor is bumping along the bottom - little or no activity. "top" shows 4.3% cpu being used Xorg - next highest user of cpu is "top" itself.

Same setup, but with wifi dongle not plugged into powered hub:

TP1 to TP2 is 4.82V before lxde
TP1 to TP2 is 4.80V with lan cable plugged in
TP1 to TP2 is 4.80V with lan cable plugged in with lxde running. 4.79V with cpu at 100% starting up Chromium.


I don't think it's a brown-out....

[jbeale]

Thanks for measuring this and posting the details. I agree with you, it doesn't seem likely that the 5V power is the problem here. It looks to be some sort of software issue linked to something started up by LXDE, as you have suggested. Unfortunately I can't offer any further assistance in that direction, but hopefully someone else can!

[NickT]

I have much the same problem with my Belkin F5D7050. I have the same 'vendor request' errors. I did post a question here http://www.raspberrypi.org/phpBB3/viewt ... 6c92c349c2 which describes it in more detail. I can confirm that my voltage didn't drop. It seems almost as though LXDE uses a different network wireless config when it starts up and never reinstates the old one when it exits. When I run startx it outputs something to the screen so briefly I can't catch it all. It's something along the lines of 'unknown command .....'. I don't have any reference to wpa_supplicant in the interfaces file or a wpa_supplicant.conf file anywhere. I just used the 'how to set up your Belkin' advice from the wiki.

[piglet]

Thanks. Interesting thought.

A google search threw up this link: http://ubuntu-lxde.wikidot.com/wifi-control

LXDE does have it's own Network Manger called LXNM

I had a quick try of wicd before seeing this link and it didn't seem to do anything.

Another how-to here: http://wiki.debian.org/WiFi/HowToUse#Wicd

That says not to put connection details in /etc/network/interfaces - which is where I've set up (working) network details for cli.

I also tried network-manager, but shortly afterwards removed it to focus on getting wifi working outside lxde. network-manager is mentioned here: http://forum.lxde.org/viewtopic.php?t=1655&f=6

[NickT]

Further to my earlier post, I don't believe it's a wireless config issue that lies at the root of the problem. I have a (very clunky) fix, described after the next paragraph.

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'm fairly convinced that this is a kernel issue which will affect all distros. I wish they would fix it!

[jbeale]

FYI there was a kernel patch a month ago specifically about supporting high and low speed devices on a hub (there's a special mechanism called "TT" or Transaction Translator that's involved with the mixed speed.) So either that patch hasn't made it to the released builds yet, or it didn't work. See also:
http://www.raspberrypi.org/phpBB3/viewt ... =40#p72218

[piglet]

Aha! Very interesting. Thank you.

I have another hub I can try later. Mouse and keyboard in one, Wifi dongle in the other... OK. I'll report back if I get a similar result to you!

[piglet]

Hurrah! That worked.

Passive hub with keyboard only
Powered hub with USB WiFi Dongle only
Power on, log in, go to lxde
Plug in mouse to passive hub and internet connection by WiFi is not lost.

This post is from the pi set up like that!

@jbeale- do you know more about the kernel patch you mentioned? Is there a thread on it?


This is something for the Wiki. I've never Wiki'd...

[NickT]

I'm glad that it worked. It's not a very convenient power up procedure though. I'm also glad that it it's not unique to my setup and therefore stands a better chance of being corrected. I can't believe that more people haven't reported it though on the forum. I imagine that a lot of the supposed power supply issues may actually being caused by this same issue.

I'm expecting another cheap e-bay SD card through the post soon. I think I'll burn ArchLinux on it and see if I can reproduce the fault on that distro. That would definitely nail it down as a kernel problem.

[piglet]

Wiki updated with wifi dongle information. Noted this thread in the "not working in lxde" area.

[marsman2020]

Your issue seems very similar to the issue described in this thread - http://www.raspberrypi.org/phpBB3/viewt ... =28&t=6042

[jbeale]

@jbeale- do you know more about the kernel patch you mentioned? Is there a thread on it?

Below is all I know about the USB driver "Transaction Translator" (high speed/low speed on USB hub) patch: the actual source from github. It would be great if someone in the know explained what it actually does!

"added support for TT in the USB driver. Thanks Naren"
Dom Cobley authored a month ago

https://github.com/raspberrypi/linux/co ... 1fa0678556

[marsman2020]

I did some investigation on this tonight.

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 FPD8923

I used the latest Debian Squeeze image, with the latest kernel (PREEMPT #89) installed via rpi-update.

I did the following:
-On another machine on the network
--Used "python -m http.server" in Python 3.2.2 to create an http server
--Used a random ~90MB file on the machine as a test download over http

-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

-On the other machine on the network
--SSHed into the Pi and ran wget to download the 90MB test.zip 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

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

-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

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

-On the other machine
--Observed that the download returned to its original speed as soon as the system returned to the console.

-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 (see also http://www.raspberrypi.org/phpBB3/viewt ... =28&t=6042). I can peg my Pis CPU for > 10 minutes at the console and Ethernet works just find until I start X/LXDE (with the same stress programs still running, yielding a much higher CPU load then just starting X/LXDE normally). Only then does the Ethernet drop out.

Further testing to be done tomorrow - remove the USB hub and attached devices and see if the effect is still present and could be related to USB drivers. Run X/LXDE over tightvnc instead of using the HDMI connector to see if the issue could be related to the framebuffer drivers.

[bredman]

I confirm that I have the same issue. My RT2070 WiFi device fails if it is plugged into the same hub as a keyboard.

[NickT]

FYI there was a kernel patch a month ago specifically about supporting high and low speed devices on a hub (there's a special mechanism called "TT" or Transaction Translator that's involved with the mixed speed.) So either that patch hasn't made it to the released builds yet, or it didn't work. See also:
http://www.raspberrypi.org/phpBB3/viewt ... =40#p72218

As a further update: I updated my Debian firmware an hour ago using rpi-update. It has made no difference. I don't know whether that patch got included in the update

[piglet]

Me too. Same result.

It's a shame we have to use two hubs just to separate low and high speed usb devices.

Is there an official/semi-official bug-tracker yet?

[dom]

The TT patch was to allow low speed devices to work with the model A board when directly connected (nothing to do with external hubs).
On model B, everything goes through the LAN/hub chip which looks like a high speed device.

Please create a github/linux issue with as much information as you can about this problem.

It is any mixture of low and high speed devices though an external hub fails (I don't believe so as I've use keyboard/mouse/USB disk all though external hub).
Does it only affect wifi modules? Is it hub specific?
Does the same hub, with the same collection of attached devices work correctly on another linux machine?

[NickT]

The TT patch was to allow low speed devices to work with the model A board when directly connected (nothing to do with external hubs).
On model B, everything goes through the LAN/hub chip which looks like a high speed device.

Please create a github/linux issue with as much information as you can about this problem.

It is any mixture of low and high speed devices though an external hub fails (I don't believe so as I've use keyboard/mouse/USB disk all though external hub).
Does it only affect wifi modules? Is it hub specific?
Does the same hub, with the same collection of attached devices work correctly on another linux machine?

I'm not familiar with Github and I only have a limited range of kit to try out. With Piglet's description of his kit then perhaps you could collate the information and raise the issue?

I get exactly the same

Code: Select all

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

errors

My kit is nearly all from the 'known working' items in the Wiki.

Wifi dongle: Belkin Components F5D7050 with the Ralink drivers as per the instructions
Powered hub : Logik LP4HUB10 4-Port USB Hub
Keyboard : Logik Ultra slim keyboard LKBWSL11
Mouse: PC world optical mouse

The hub is powering the RPi via the micro USB. The voltage holds up to 4.85V at all times. I've tried having the wlan0 setup in both the interfaces file and a wpa-conf - it makes no difference. As soon as LXDE starts the wlan is gone. I don't know at what time all the driver error messages ' failed to find index.. etc' appear but I expect it's when the LXDE starts. I'd quite like to try it with a wifi dongle that draws less than 140mA but I'm skeptical as to whether such a creature exists.

[marsman2020]

I will file a bug on github, but it will be for the built-in Ethernet case only. I do not have access to a wifi dongle to test if wifi is impacted as well. Since the internal Ethernet is a USB device hanging off the internal USB hub, my personal opinion is that the same issue is impacting both devices.

Edit: Issue filed. See https://github.com/raspberrypi/linux/issues/29

I encourage anyone who is having problems along this line to sign up for a github account (it's free and super fast) and add your observations to this issue.

[piglet]

Does the same hub, with the same collection of attached devices work correctly on another linux machine?

Hi dom,

Retest on pi

I've tested this on another mouse and keyboard in my pi, no passive hub:
Started off with powered hub with dongle. Keyboard to pi
Checked pi connected to wifi
startx - all well with lxde
plugged mouse in place of keyboard in pi - all well - fired up browser to check connectivity. All good
plugged keyboard back in place of mouse to pi. tried another site. All good
plugged mouse into powered hub: Instant wifi drop.

Test on another non-pi linux machine

I've tested this on my main PC running Ubuntu. No problems whatsoever using the same keyboard, mouse, hub and dongle.

I started off with a different mouse and keyboard in passive hub, dongle in powered hub.
Checked wireless working correctly.
Removed mouse from passive and put in the mouse from pi to powered hub. All working correctly
Removed keyboard from passive and put in the keyboard from pi to powered hub. All working correctly

Code: Select all

$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 05e3:0760 Genesys Logic, Inc. USB 2.0 Card Reader/Writer
Bus 002 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 002 Device 010: ID 413c:2005 Dell Computer Corp. RT7D50 Keyboard
Bus 002 Device 009: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse
Bus 002 Device 006: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 002 Device 007: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 002 Device 008: ID 07d1:3c09 D-Link System DWA-140 RangeBooster N Adapter(rev.B1) [Ralink RT2870]

[piglet]

This post is from a second pi

Test as before:

Booted up with powered hub and dongle, keyboard in pi
wifi working
startx->lxde, swapping between mouse and keyboard in pi - wifi working
plugged mouse to hub. Wifi stopped, mouse working
removed mouse and dongle, plugged dongle back in to hub, nowifi
restarted network: sudo /etc/init.d/networking restart
wifi now working.

[tangential]

I was experiencing this issue, but managed to resolve it by disabling the eth0 interface. While not a fix, this workaround is feasible if you do not require both wlan* and eth0 functionality at the same time.

In order to disable the eth0 interface, run the following:

Code: Select all

echo -n '1-1.1:1.0' > /sys/bus/usb/drivers/smsc95xx/unbind

And to re-enable, run the following:

Code: Select all

echo -n '1-1.1:1.0' > /sys/bus/usb/drivers/smsc95xx/bind

These commands effectively disconnect (and reconnect) the ethernet device portion of the smsc95xx chipset from its USB bus. In my experience, the low/high speed USB issue (resulting in a loss of wireless connectivity) only occurs while the eth0 device is connected/bound.
The unbind'ing and re'bind'ing of the eth0 device can be added into the /etc/network/interfaces configuration as part of the appropriate 'pre-up' and 'post-down' directives. You may also want to add similar directives to the eth0 interface configuration to ensure that online state of eth0 and wlan* are mutually exclusive (I have been too lazy to do this yet, so I don't have a tested excerpt to share).