UNR Freeze & Flashing Caps Lock Indicator when D/Ling Files/Binaries on Acer Aspire One AOA150

This bug has been moved to Ubuntu distribution

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it without more information.

Is this something that has happened only once, or is it reproducible?
Also, please run the following command on your system, this will gather logs and attach them to the bug:
apport-collect -p linux-image-`uname -r` <bug#>

For your reference, the full description of procedures for kernel-related bug reports is available at https://wiki.ubuntu.com/KernelTeamBugPolicies Thanks in advance!

Architecture: i386
DistroRelease: Ubuntu 9.04
HibernationDevice: RESUME=UUID=01f0dbcd-5135-4f5f-badd-5e352ca0eb92
MachineType: Acer AOA150
Package: linux-image-2.6.28-11-generic 2.6.28-11.42
PackageArchitecture: i386
ProcCmdLine: root=UUID=280f495a-38d7-49d3-8d72-89f85b016aed ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.28-11.42-generic
Tags: ubuntu-unr
Uname: Linux 2.6.28-11-generic i686
UserGroups: adm admin audio cdrom dialout dip fax floppy fuse lpadmin netdev plugdev sambashare tape video

> apport-collect -p linux-image-`uname -r` <bug#>

Completed the above task. Hope I did it right.

> Is this something that has happened only once, or is it reproducible?

Frequency: This freeze-up issue has happen about a half dozen times in the past 24-hours (just got the netbook/installed UNR yesterday).

Reproducibility: Still working on trying to predictably reproduce this bug.

Update: This issue has also happened when using Firefox to simultaneously download three mp3 files (podcasts; 17.5MB/file).

Hi Jason, thanks for getting that. It would help greatly if we could capture the kernel output when it happens. Having a reliable way to reproduce it would be helpful also of course. If you are able, could you try this please:
1. Try rebooting to a known working kernel right after reproducing the problem and see if any backtrace was logged to /var/log/kern.log.0. Please attach this file if anything was captured.
2. When no clues found in /var/log/kern.log.0, supply a digital photo of the screen to capture the crash.
For this, you would need to be in text mode when it happens. If at some point, you have a way to reproduce it, just ctrl-alt-f1 to get to the text console, and reproduce the bug.
3. When all fails, try to see if https://wiki.ubuntu.com/KernelTeam/Netconsole can help out.

Try #1 first since it's the easiest, and hopefully that will capture the stack trace, if not then move on to #2 or #3.

All this, as well as some other information can be found at https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies if you want to take a look.

Hi Paul, Still working on being able to reproduce the bug reliably. Will try #1-3 when able.

The most recent occurrence of this bug came just *after* a download of an .mp3 file finished (d/ling with Firefox). This was a surprise, as previously the lock-up has occurred while downloads (both of Usenet binaries and thru Firefox) were in progress. This time the freeze-up happened just as the download finished and Firefox displayed the "All downloads completed" (or some such message) notification.

The one consistent aspect has been the flashing Caps Lock indicator light along with the freeze up.

Attempts to simulate the known conditions under which this issue has occurred have not been able to reproduce the bug. :(

Thanks again for the help.

I should have mentioned this before, but the flashing caps lock is an indicator that you've had what's called a kernel panic - a serious error that causes the system to crash. In text mode, you would have seen some output to the screen that developers can use to help pinpoint the source of the problem. Unfortunately, in graphical mode this is not possible, which is why the steps I mentioned above are needed in order to gather this information. I appreciate your diligence in trying to reproduce the problem and gather the debug data.

It now seems that I have a somewhat reliable way of reproducing this issue, using the CLI-based Usenet binary downloader, HellaNZB. Methodology:

1. Using standard Gnome interface, load several NZB files into the HellaNZB queue folder [NZBs contain references to Usenet binaries for easy downloading]

2. Drop to text console using ctrl-alt-F1

3. Start HellaNZB, which begins to download the Usenet binaries, and wait for kernel panic to occur

Using this method, I am able to provide the following updated info:

> 1. Try rebooting to a known working kernel right after reproducing the problem and see if any backtrace was logged to /var/log/kern.log.0. Please attach this file if anything was captured.

Based on timestamps, no info was collected in /var/log/kern.log.0 related to the most recent reproduction of this issue.

> 2. When no clues found in /var/log/kern.log.0, supply a digital photo of the screen to capture the crash.
For this, you would need to be in text mode when it happens. If at some point, you have a way to reproduce it, just ctrl-alt-f1 to get to the text console, and reproduce the bug.

See attached file, 'Bug 381336 - Kernel Panic Screenshot.jpg'.

Thanks for your efforts in reproducing this and getting a picture of the stack trace. Since you have a way to reproduce it reliably, and have most of the stack trace legibly captured in the photo, I'm marking this confirmed. Please continue to watch in case there are requests for additional information.

I experienced this problem under high network load on an Ubuntu 9.04 on a Acer Aspire One. I found a solution in my case which may help. This problem did not occur with the default ath5k wireless driver, but I had tried to use the madwifi driver ath_pci, which didn't work, and then the ndiswrapper driver, which did. The problem only occurred when both the ath_pci and ndiswrapper drivers were loaded (ndiswrapper being used); I conclude that this is a driver conflict issue. blacklisting the ath_pci driver solved this problem for me.

I posted specific details on a Ubuntu forum; http://ubuntuforums.org/showthread.php?p=7693525#post7693525. I hope this helps and is related to the above bug.

Have had some success in working around this issue. As in danjlawson's comment, it involves using different wifi drivers for the Atheros hardware, although it does not involve blacklisting & I am actually using a version of Madwifi ath_pci.

In short, using directions from here:

http://madwifi-project.org/wiki/UserDocs/FirstTimeHowTo

I downloaded & compiled Madwifi drivers from the source code available here:

http://snapshots.madwifi-project.org/

Have tried & had success with both madwifi-hal-0.10.5.6 & madwifi-hal-testing (currently using the testing version).

Kernel panics with high network load are now virtually gone. (Still get KP from time to time, but rare now and might be due to other issues.) Additionally, wifi data transfer rates / speeds are now no longer significantly slower than they should be. Also fixed issue with not being able to connect to WPA2 networks, and the random disappearance / unloading (?) of the wifi driver.

The only downside to this solution is that the drivers need recompiled with every kernel update. I keep a copy of the .tar.gz source code and the instructions locally, b/c no Internet access after kernel update. A minor inconvenience.

If anyone has an Acer Aspire One (w/Atheros wireless hardware) and is experiencing these kind of serious wifi issues, I suggest you check out this solution.

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.