Bugzilla – Bug 13535
wlan kernel oops (was sometimes baby UI is painfully slow)
Last modified: 2010-05-27 14:46:11 UTC
I see this maybe once per day, and so far haven't been able to make a connection to anything. Sometimes the UI takes more than a few seconds to respond to scrolling. Rebooting always fixes this. Checking top from serial shows nothing out of the ordinary, jive using ~40% memory and 1-3% CPU.
I have experienced this at times as well, but could not reproduce it reliably.
It doesn't serve this bug well to have it in my court. Unassigning and tagging with bug_meeting.
I've talked to Richard about this and he said it would be good if you could get a log when this happens and then talk to him.
Give Richard a chat on IM when you see this happening, make sure you have serial cable attached.
Created attachment 5676 [details] Rico's log
Rico saw lagginess (see attached log). He is running a private network with no connection to SN. The lagginess appear after a cold reboot. He said: "10:46:09 is when it recovers", which in the log is when the idle disconnects to the SCs occurs.
tail -f /var/log/messages ? or some other logging?
Created attachment 5678 [details] 2nd log Happened again during boot & reconnect to wireless interface. Connected power supply, removed battery, connected serial, no shell prompt, yet there was feedback from plugging in ethernet. Wading through the slow menus I'm able to get it to connect via ethernet, whereupon baby again recovers and the UI is snappy. Looks like udhcpc dies several times and respawns, finally gets a proper lease around 7:40, and everything goes back to normal, except the serial console still won't put up a prompt.
Created attachment 5680 [details] Long log incl. kernel oops & watchdog Once more, this time serial tty was enabled at bootup. I've seen this kernel oops before and not had any ill effects so I'm not sure it's related. However line 811 shows watchdog finally kicking in before I had a chance to switch to wired networking. For some reason baby cannot get a dhcp lease but wants to resume playback..? Unfortunately as before top was not helpful here, maybe a wireshark capture would be handy if it happens again.
Created attachment 5692 [details] console output With the D-link WBR-1310 I'm able to reproduce this consistently from a factory reset state using WPA2, Cipher type Auto (TKIP / AES), PSK 8~63 ASCII.
Created attachment 5693 [details] packet capture Packet capture while reproducing this bug, see packets 512 through ~524.
Felix do you need anything else from QA? If you would like this router shipped to you just say the word. :-) Thank you Rico!
Rico: Thanks, not yet. Richard: Some of the logs show the kernel oops you are looking into with Atheros.
r7360 reproduces this consistently while trying to connect via wireless to linksys WRT610N WPA2.
r7406 reproduces this consistently with D-link DIR655. Tempting to upgrade the severity of this bug, in some ways it is blocking (or at least painfully slowing) router testing for baby.
I was just talking to Ross about how slow this makes router testing, and I'm raising the severity. I know that Richard and Felix have plenty of work, and it's all high priority, but this is my vote that this bug is definitely making QA's life much more difficult. Please schedule your work with our pain in mind. :)
== Auto-comment from SVN commit #7416 to the jive repo by richard == == https://svn.slimdevices.com/jive?view=revision&revision=7416 == Bug #13535 Fix atheros driver for RT Linux.
Richard made some amazing progress on this, I can no longer reproduce. He mentioned wanting to track this down further so we'll leave this bug open. Thanks Richard, this helps me a lot.
Sorry for the late feedback, but I had a hard time yesterday to reproduce with r7406. For some strange reason I couldn't make it happen. But this morning, when I re-tried with r7406, the issue occurred twice out of 20 attempts. After updating to r7418 it did not happen once in 20 attempts. Looks good I think.
Further investigation appears to suggest the additional error I was seeing is caused by using LOCKDEP kernel debugging with loadable modules. I don't think this is a problem when the debugging is disabled. Based on the comments from Ross and Felix this is now confirmed fixed.
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
These bugs have all been marked resolved and belong to a component which is being removed. Therefore they have been moved to the most applicable of the new components.