Turning wifi "off" using Fn+F2 on Eee PC with Ralink rt2860 results in kernel panic (rfkill)

[Martijn vdS]

SRU Justification:

Impact: Trying to turn of wireless via the Fn+F2 hotkey combination results in a kernel panic when the hardware vanishes from under the driver.

Fix: Test for NULL pointer (patch from 2.6.31.5)

---

When I disable the wifi using Fn+F2, the system hangs with a kernel panic instead of disabling wifi.

I'll try to catch the panic message properly and attach it here (but the machine doesn't have a serial port, so it might take some hacking).

[Martijn vdS (martijn)]

Architecture: i386
DistroRelease: Ubuntu 9.10
MachineType: ASUSTeK Computer INC. 901
Package: linux (not installed)
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-4-generic root=UUID=80129cee-04c5-4196-9f54-a16dee9ddce1 ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 LANG=nl_NL.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-4.21-generic
RelatedPackageVersions: linux-backports-modules-2.6.31-4-generic N/A
Uname: Linux 2.6.31-4-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
dmi.bios.date: 03/17/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1903
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: 901
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: x.xx
dmi.chassis.asset.tag: 0x00000000
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTek Computer INC.
dmi.chassis.version: x.x
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1903:bd03/17/2009:svnASUSTeKComputerINC.:pn901:pvrx.x:rvnASUSTeKComputerINC.:rn901:rvrx.xx:cvnASUSTekComputerINC.:ct10:cvrx.x:
dmi.product.name: 901
dmi.product.version: x.x
dmi.sys.vendor: ASUSTeK Computer INC.

[Martijn vdS (martijn)]

Toggling wifi on (when booted with wifi off) works as expected.

[Martijn vdS (martijn)]

Trying with a mainline kernel next.

[Martijn vdS (martijn)]

Same thing happens with 2.6.31-rc4 mainline build from http://kernel.ubuntu.com/~kernel-ppa/mainline/

[Ritz (jonas-ritz)]

Same thing happens on my EEE1001H running 9.10 / 2.6.31-rc4 with RaLink RT2860 wifi Card.
The WIFI radio does toggle off, I have to turn it on after boot, but system hangs..
With Intel 2945ABG wifi Card it only connects to AP the first time. After update of packets wifi do not work.

[Ritz (jonas-ritz)]

Same thing with 2.6.31-rc5.

[David Iwanowitsch (dav.id)]

I can confirm this on my EeePc 901 too.
But if i disable wireless in NetworkManager at first, rfkill produces no kernel panic

[David Iwanowitsch (dav.id)]

With Karmic and mainline kernel 2.6.31-rc7 its still not working :(

[Walter_Wittel (wittelw)]

Toggling both on and off was working for a few days on my eeepc 901 (but blue tooth was disabled as I had left it in BIOS since I don't use it). I notice now that the blue tooth is enabled (at least in the notification area and I was able to my Motorola V3 phone so it works).

When this feature was working the blue radio LED would turn off as well as Wi-Fi. Now Wi-Fi is disabled on reboot but the blue radio LED is on (different from disabling Wi-Fi in BIOS where the LED stays off) so the panic must happen part of the way through the process.

BTW, on my system I do not get the kernel dump to the screen as the attachment at the start of this bug -- just a blinking hyphen in the upper left and a frozen mouse cursor on a black screen. I turned on KMS per https://wiki.ubuntu.com/X/KernelModeSetting so perhaps that is the difference.

[David Iwanowitsch (dav.id)]

The problem is not fixed in 2.6.31 release, but there is a workaround in the upstream bug.

[Ritz (jonas-ritz)]

with no card installed you can toggle the blue led on and off with Fn+F2

[sitronen (peter-ullinger-deactivatedaccount)]

Bug duplicated?:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/420363

[buull (wapmobil)]

I think it is a bug in new wifi diver ralink-rt2860 v 2.x.xx , because in version 1.8.xx it bug was absent.
My Bug #448992 may be duplicate, but it is only when WiFi with active connection. When I disconnect wifi network, wifi turn off successful.

[Brezhonneg (fricompte)]

FYI, I have not tested it but a fix was released yesterday (upstream) and was confirmed to work by at least one person:

http://bugzilla.kernel.org/show_bug.cgi?id=13390#c21

[MasterX (trashmaster-disposal)]

I just experienced this crash, too. ASUS eeePC 1000H. Toggling WLAN off while connected causes a crash (black screen, frozen cursor).

Hope the patched driver will soon be (back-)ported to Ubuntu!

[sitronen (peter-ullinger-deactivatedaccount)]

Bug still exists in kernel .14-generic

[sitronen (peter-ullinger-deactivatedaccount)]

Like said- disconnect the wificonnection before toggling the hardware off avoids the crash.

[MasterX (trashmaster-disposal)]

for fix see this comment: http://bugzilla.kernel.org/show_bug.cgi?id=13390#c23

[MasterX (trashmaster-disposal)]

or alternatively http://bugzilla.kernel.org/show_bug.cgi?id=13390#c21

[Ilja Sekler (ilja-sekler-)]

The fix is *not* committed yet.

[GiuseppeVerde (launchpad-digitasaru)]

Moving to confirmed, 'cause it is (and was so marked). Perhaps "triaged" is better? So sad that my mjg quote is not in this thread, though. :(

[Ruslan (b7-10110111)]

Kernel 2.6.32-rc5 has this bug fixed, at least changelog says this.

[Ilja Sekler (ilja-sekler-)]

Yes, the patch has been checked in upstream: <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0af49167b1e5ba154e90d2c454bf4624ee47df80>.

[GiuseppeVerde (launchpad-digitasaru)]

Just got bitten by this again, thanks to my infant son poking around on my keyboard with his hands.

Please fix soon!

[Matthew East (mdke)]

It's not needed to subscribe Ubuntu Drivers to bugs, I've removed the subscription.

[MrAuer (mr-auer)]

Confirm on Eee pc 901 with Karmic Release Candidate. (Its been that way since Jaunty unless one installed some scripts to fix it, like Fewts addons for the Eee from Statux)

See here for Statux's Fewts (angry) comments on this issue (he stopped maintaining the Eee pc addons due to this issue among others) -
http://www.fewt.com/2009/10/i-give-up.html

"Every time something in the OS changes, Eee PC Utils gets the blame for "breaking" people's computers even though whatever I release typically doesn't even alter the code being reported. Even though I've published work-around after work-around on the Wiki for Linux bugs like the famous bluetooth bug in 2.6.28, the WIFI hotplug bug (pciehp force), or linking to the fix for the Intel video driver bugs, its still considered my fault in the eyes of the users when the screen won't turn off and on (xrandr reports a protocol error that it didn't a few weeks ago) or their WIFI won't come on after they turn it off (because the kernel pciehp module is broken).

Now that Karmic is coming Eee users are looking forward to having 2 Radio Kill devices for Bluetooth, and 2 for WIFI. Yes, this is in a production released kernel, yes, the interfaces are provided by different modules (eeepc-laptop exposes them as do the driver modules), yes their naming and function is of course not named using a reasonably grep-able syntax, and yes they do actually work differently somehow." (theres more but see the link, he complains a bit in addition to discussing the issue ;) )

Please, please fix this urgently!
This is a real showstopper and it should not be too hard to fix.
Most other things seemed to work ok on Karmic RC as of yesterday, but as long as there are bugs that cause my laptop to totally hang, I cannot upgrade to it. As is known, Jaunty also has its share of bugs on Eee pcs, so I would very much like to get an usable Ubuntu on it - I for one have been hopefully waiting for Karmic to finally work flawlessly on my Eees.

I for one need to be able to switch off the wlan, since I also use a 3g modem where wlan is not available. It is not very cool to have your machine hang, reboot and only then be able to use 3g without wlan drawing extra power.

[MrAuer (mr-auer)]

Addition - I have the ralink wireless.

[Leann Ogasawara (leannogasawara)]

The patch mentioned in commend #33 to resolve this bug is now in the upstream 2.6.31.5 stable kernel. The Karmic kernel is currently frozen for release at the moment, but we will rebase to 2.6.31.5 as a Stable Release Update for Karmic. As an interim solution, feel free to run the 2.6.31.5 mainline kernel build:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31.5/

I'm pasting the commit information below just for reference:

ogasawara@yoji:~/linux-2.6.31.y$ git show b5a56fc94bcc0910870391da8778ba1c6d41bd3d
commit b5a56fc94bcc0910870391da8778ba1c6d41bd3d
Author: Darren Salt <email address hidden>
Date: Wed Oct 14 02:19:22 2009 +0100

    Staging: rt2860sta: prevent a panic when disabling when associated

    commit 0af49167b1e5ba154e90d2c454bf4624ee47df80 upstream.

    This fixes a panic which is triggered when the hardware "disappears" from
    beneath the driver, i.e. when wireless is toggled off via Fn-F2 on various
    EeePC models.

    Ref. bug report http://bugzilla.kernel.org/show_bug.cgi?id=13390
              panic http://bugzilla.kernel.org/attachment.cgi?id=21928

    Signed-off-by: Darren Salt <email address hidden>
    Signed-off-by: Greg Kroah-Hartman <email address hidden>

[Forest (foresto)]

Can someone estimate how long after the Karmic release date the kernel rebase will take place? This is a pretty awful bug to stick netbook users with, especially those who have been waiting six months for a release that works with WPA encryption (bug 339891).

I think this patch might warrant a kernel freeze exception. Why advertise a netbook distribution whose net connectivity is broken for two major releases in a row?

[Steve Langasek (vorlon)]

On Tue, Oct 27, 2009 at 05:35:53AM -0000, Forest wrote:
> I think this patch might warrant a kernel freeze exception.

No, it doesn't work that way. An "exception" here would set back the
release by a whole week, due to the time involved in integrating kernel
changes and validating the resulting images. We aren't going to do that for
a single piece of hardware that's supported on a best effort basis - this is
entirely suitable for fixing in a post-release update.

> Why advertise a netbook distribution whose net connectivity is broken for
> two major releases in a row?

There are many netbooks that aren't affected by this problem. Some of them
are sold with Ubuntu pre-installed.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Andrew Wyatt (awyatt)]

>An "exception" here would set back the release by a whole week, due to the time involved in integrating kernel

So what, the focus should be on quality, not meeting a release date.

>We aren't going to do that for a single piece of hardware that's supported on a best effort basis

What you are saying here is that you would rather impact users than miss your release date. Complete and utter disregard for quality is why Ubuntu will unfortunately never be accepted in the mainstream.

Set the release back a week, and focus on quality for a change rather than continuing to build garbage salads.

[MrAuer (mr-auer)]

My Eee 901 also periodically hangs when suspending, or resuming from suspend. Is this perhaps related? I took a picture of the screen the one time I was able to get into a terminal before it went completely unresponsive. Sadly the picture is out of focus so its hard to make out what it says. Last few lines are something about devkit-power and libgobject. Ill include the pic anyway. Other times the machine simply hangs, a few times Ive clicked Suspend, after which nothing at all happens and I cant open the shutdown menu anymore. Killing X at this point leads to hanging and only powerdown from powerbutton works. Other times again, wlan goes off, machine suspends, comes back from suspend fine and even wlan comes back up.

I would really rather have the release set back and these issues fixed. I had serious issues with Jaunty as well, and after latest updates to Jaunty, my wlan stopped working completely in that as well - I can switch it on and off but network manager never registers it - which is why I bit the bullet and installed Karmic RC anyway. Which did not much improve the situation, sadly. At least suspend worked on Jaunty...

Also, does the "feel free to run the 2.6.31.5 mainline kernel build: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31.5/" fix the suspend issue? Should I make another bug report of the suspend issue, or is there already one open? Is that going to be fixed? I will try that kernel anyway, cant hurt. Will report my experience back.

Also, I agree with what Andrew Wyatt said above. I was waiting for Karmic to fix the Intel video driver bugs and the periodic hard locks I had with Jaunty, but instead now it is worse with Karmic - and Jaunty updates stopped wlan working as well. That it might work on some other netbooks is hardly comforting. I have been using Ubuntu since Warty, and have installed it for several other people. The bugs that are present in final releases has been the biggest complaint for several people - and personally, I feel that making Ubuntu more stable and bug free should be more important than keeping some release date. One person of these actually went and bought a Mac after some frustrating stability issues across 2 releases (Hardy and Intrepid).

So please consider fixing these issues before release rather than after.

[Ruslan (b7-10110111)]

Can't the patch just be backported to currently used kernel rather then rebase ubuntu to new version?

[Steve Langasek (vorlon)]

Documented at <https://wiki.ubuntu.com/KarmicKoala/ReleaseNotes#Disabling%20Ralink%20rt2860%20wifi%20on%20EeePC%20with%20Fn+F2%20hotkey%20causes%20a%20kernel%20crash>:

Using the Fn+F2 hotkey to disable the wireless antenna on an EeePC that uses a Ralink rt2860 chip (EeePC 900 and 1000 series) results in a kernel panic that will hang the system. A fix for this issue is expected to be provided in a post-release update immediately after the Ubuntu 9.10 release. (404626)

[Andrew Wyatt (awyatt)]

15 2009-10-28 13:23:01 13139 vorlon errata for bug #404626 view

Awesome, thank you.

[MrAuer (mr-auer)]

With the mainline 2.6.31-15 kernel someone provided above, switching wlan on and off no longer crashes the machine, BUT network manager does not see the wlan after turning it on again. I think this might be the same issue that in Jaunty needed the kernel boot option "options pciehp pciehp_force=1 pciehp_poll_mode=1" ? Could that be fixed as well, or do others get their network back up after re-enabling wlan radio? For me, network manager only reconnects after resume from suspend, but not after re-enabling wifi radio.

Now if I only could get my Huawei modem to work as well .... ;)

[Ilja Sekler (ilja-sekler-)]

> do others get their network back up after re-enabling wlan radio?

No problems reconnecting to a wireless network, either open or WPA2 encrypted, on Asus Eee PC 1000H with the vanilla 2.6.31.5 kernel after re-enabling wireless. In addition to it, boot options "pciehp.pciehp_force=1 pciehp.pciehp_poll_mode=1" are not needed on this hardware anymore.

But this is clearly OT in this bug.

[Helen_Colledge (helen-fellpainter)]

I would just like to add from my own experience that this problem also affects the eeepc 701SD.

[MrAuer (mr-auer)]

Addition, even thou perhaps OT - I have now tried both 2.6.31-5 and 2.6.32-rc5 kernels -
I can turn the wifi led on and off, BUT Network manager never sees any wireless connection. None.
I can turn it on and off as many times as I wish, but NM never registers the connection - not even when I boot again with the wlan on. Anyone know why that happens? Does anyone else have this problem?
I dont know how I could troubleshoot this - what logs to look to, as nothing crashes...NM doesnt even show any wireless networks, not even greyed out "Wireless" - just "Wired network" and "3G"...

At least with these two kernels the Huawei modem works so I can get online, albeit at a slower speed.

[Ritz (jonas-ritz)]

If I guess right, your system does not see your wifi card. You can
varify that with lspci in a terminal window.

On Sun, 2009-11-01 at 09:16 +0000, MrAuer wrote:
> Addition, even thou perhaps OT - I have now tried both 2.6.31-5 and 2.6.32-rc5 kernels -
> I can turn the wifi led on and off, BUT Network manager never sees any wireless connection. None.
> I can turn it on and off as many times as I wish, but NM never registers the connection - not even when I boot again with the wlan on. Anyone know why that happens? Does anyone else have this problem?
> I dont know how I could troubleshoot this - what logs to look to, as nothing crashes...NM doesnt even show any wireless networks, not even greyed out "Wireless" - just "Wired network" and "3G"...
>
> At least with these two kernels the Huawei modem works so I can get
> online, albeit at a slower speed.
>

[Jonathan Hudson (jh+lpd)]

This is probably because the ppa mainline kernels do not, alas, include the "staging" drivers (e.g. the rt2860).

Please can we have staging in the mainline ppa?

[Ruslan (b7-10110111)]

Yes, it seems the driver isn't enabled. Type
lsmod|grep rt2860sta
 to see if the driver is loaded. And, to see if the driver exists in your configuration, try
modinfo rt2860sta
. If these commands don't output anything or give errors, then there is no such module and it's just what jh says.

[MrAuer (mr-auer)]

Yup, no such module exists.
Any suggestions on how to proceed to get wlan working, preferably so also Huawei modem works?
Can I somehow add that driver module only?

[MrAuer (mr-auer)]

Or perhaps its best to wait a while for this to (maybe) be fixed via regular updates...

[Ritz (jonas-ritz)]

will the wifi card be visible with lspci, if the driver is not present?

[Andrew Wyatt (awyatt)]

If it's on an Eee PC, when rfkill is set to 0 the device is removed from
the PCI listing as it is off in the BIOS (and the USB port is powered
off).

When turned back on with rfkill=1 then the port is turned back on, but
since the pciehp hotplug bug exists you still won't see it in the pci
listing unless you have the grub option set to force pciehp.

On Sun, 2009-11-01 at 13:26 +0000, Ritz wrote:
> will the wifi card be visible with lspci, if the driver is not present?
>

[Ruslan (b7-10110111)]

>since the pciehp hotplug bug exists you still won't see it in the pci
>listing unless you have the grub option set to force pciehp.

Hasn't this bug been fixed already?

> will the wifi card be visible with lspci, if the driver is not present?
>

Anyway, even if the bug is not fixed, the card should be visible after reboot with wifi enabled.

>Any suggestions on how to proceed to get wlan working, preferably so also

You could compile the kernel yourself and enable staging drivers there.

[bornagainpenguin (bornagainpenguin)]

So are you guys planning on fixing this bug that should have never been allowed to slip through to a final release, even at the risk of your oh so precious schedule or are we all doomed to wait until upstream gets it fixed? Seriously, what kind of quality control is this that allows you to get a final release that crashes the system just because you tried to turn off the WiFi? This and other silliness by the Canonical developers is really making me question their commitment to releasing a distro that is "humanity towards others" because if this is your idea of humane, God help us all!

--bornagainpenguin

[MilchFlasche (robertus0617)]

Whoa... take it easy Buddy upstairs... I too am a bit annoyed by this bug, but I still want to say thanks to all you guys in the Open Community, and also you guys working for Canonical. I don't know how many people Canonical has got now, but I guess it still takes quite a lot of time (and also cost) to get so many bugs fixed --- there might be so many of them marked as "critical" or "high" already! And I think since every bug in Open Source world takes the good will of some kind guys to look after it, either paid or unpaid, so it might be positive as well to use compliment rather than a harsh whip here.

I can understand when people get stuck with some major bugs which is not feasible to happen in the first place. I too were annoyed with some bugs Ubuntu 8.04 has got with Eee PC, so that was why I switched to Mandriva during the past year. But with 9.10, I have seen hope and progress again in Ubuntu, and I won't doubt the commitment and decision of Canonical to make a more comfortable distro because some bugs persist for such long time. Just hope some guys can eventually get this bug fixed when time, resources and cost permit.

[bornagainpenguin (bornagainpenguin)]

>>Just hope some guys can eventually get this bug fixed when time, resources and cost permit.

You mean when the Debian developers fix it, right?

[Dave Roberts (drob-blueyonder)]

I have a EeePC 1000H and I have installed Karmic UNR
I have also installed the excellent eeepc-utilities by Andrew Fewt

 http://www.statux.org/content?page=repo for repo and instuctions

This is an excellent solution for EeePC ACPI management.

RESULT wifi toggle now works completely, connection the whole business.
I know it might not be within the spirit of "bug fixing", but with the eeepc-utilities installed I have an EeePC with FULL functionaity.

Thanks very much to Andrew for his now discontinued work on these scripts for Ubuntu.
A big thank you also to the Ubuntu Karmic developers I have had Hardy, Intrepid, and Jaunty installed previously, but Karmic install and functionality is the best by a mile.

[David Headrick (sparkix)]

The EEEPC ACPI scripts don't help the problem with my 901. I still get a black screen when I toggle WIFI off.

[Jonathan Hudson (jh+lpd)]

Alas, still present in the karmic-proposed 2.6.31-15-generic #49-Ubuntu SMP update

[Stanislav German-Evtushenko (giner)]

This bug affects me too.

[Stanislav German-Evtushenko (giner)]

Ubuntu karmic with lastest updates. Eee PC 901.

[MrAuer (mr-auer)]

Yup, this still happens with 2.6.31-15-generic I installed from Karmic-proposed - disabling wlan still crashes kernel.. I guess the "fix" reported earlier was only because there was no ralink module / no driver present in the kernel for testing the Huawei fix.

Any hope of getting the fix in the same kernel update as the Huawei fix when it is properly released (not just in Proposed)?

[Joe Aztec (aztecjoe)]

I am running 2.6.31-14-generic and can happily crash the OS using Fn-F2 while wireless connection is active. By disconnecting from the wireless connection I can happily toggle the WLAN on-off. Its a small price to pay while waiting for a bug fix. All the Fn keys appear to work without installing eee-controls which I used with 9.04.

[Stefan Bader (smb)]

This is supposed to be fix in upstream stable by: Staging: rt2860sta: prevent a panic when disabling when associated

There is currently a kernel compiling in my PPA at https://launchpad.net/~stefan-bader-canonical/+archive/karmic
(2.6.31-16.51~pre2). If that finishes, could someone test whether this is true? Thanks.

[Jonathan Hudson (jh+lpd)]

Boot, Fn-F2 toggles wi-fi and does NOT cause a kernel crash. Not much else tested.

-jh

[Jonathan Hudson (jh+lpd)]

sorry, forgot to say "Thanks" for building this.

-jh

[Stefan Bader (smb)]

Thanks for testing

[Giovanni Pardini (gio.pardini)]

I can confirm that, with the kernel proposed in #68, the bug does not happen anymore.
Now Fn+F2 works correctly with eeepc 901.
Thanks!

[Sebastian (slovdahl)]

I can also confirm that it works correctly on my Eee PC 901 with Bader's 2.6.31-16.51~pre2.

Thanks a lot!

[Ruslan (b7-10110111)]

It's great that this does work. But will this be available as a usual update, or i will have to add ppa etc.?

[MilchFlasche (robertus0617)]

With current official 2.6.31-15 kernel update, boom! Still kernel panic when pressing Fn+F2 to toggle wireless off.

With 2.6.31-16 from PPA by Stefan, it's working like a charm! Allellujah! :D Thanks a million to you, Angel, since it's possible to toggle wireless off to save battery without fear.

And reply to upstairs Ruslan: i believe that in normal Ubuntu update workflow, this patch and update will eventually hit the main repository. And if it's urgent for you, you can just use "sudo add-apt-repository ppa:stefan-bader-canonical/karmic", and get an updated package list, and then update the linux-image-* packages and use this pre-release happily. It's quite simple :)

[Stefan Bader (smb)]

Ruslan wrote:
> It's great that this does work. But will this be available as a usual
> update, or i will have to add ppa etc.?
>
Eventually it will work its way to proposed and then to updates. The PPA is
a staging area to make things available as early as possible.

[Tars (tars-ac)]

I just tested this fix on a fresh 9.10 installation (with new updates applied as of today, but no other changes from the stock iso) and Stefan Bader's ppa on my Eee PC 1000. There is no more kernel panic, and it disconnects from the wireless network, but the LED light stays on. Checking lspci reveals that the wireless card is no longer there. Does that mean that the wifi is no longer draining the battery when it is off? Why is the LED not turning off?

When I turn the wifi off in the BIOS, the LED turns off correctly.

[lanzen (lanzen)]

Tars, do you have bluetooth on your eeepc? I have and the blue led stays on unless bluetooth is disabled.

And, thank you Stefan! 2.6.31-16 worked for me, too.

[Ruslan (b7-10110111)]

The blue LED is turned on if either of WiFi or Bluetooth are on.
Try this to disable bluetooth:
sudo su -c "echo 0 > /sys/devices/platform/eeepc/rfkill/rfkill1/state"

[lanzen (lanzen)]

Ruslan wrote:

> The blue LED is turned on if either of WiFi or Bluetooth are on.
> Try this to disable bluetooth:
> sudo su -c "echo 0 > /sys/devices/platform/eeepc/rfkill/rfkill1/state"
>

Right! And if it's a standard Ununtu he may also click on the BT applet
on the upper panel. ;)

[Tars (tars-ac)]

Thank you! I hadn't realized that the bluetooth behaved in this way because I only recently began using it - before that it was off all the time. You are correct, as soon as I turned off bluetooth the light turned off as well.

[ahamdan (ahamdan)]

When I updated ubuntu 9.10 the system failed to startup. showing panic kernel failure. I don't want to start from scratches by uninstalling the current and reinstalling again. I might have the problem again after new installation. Is there a fix?

[ahamdan (ahamdan)]

Ubuntu 9.10 startup failure. Message:
[ Linux - bzlmage, setup=0x3400, size=0x3b26e0]
[ 1.197053] kernal panic - not syncing: VFS: unable to mount root fs on unknown -block (8,1)

What should I do. plz help!

[Ruslan (b7-10110111)]

Is this the whole message?

[ahamdan (ahamdan)]

Yes Sir. The system stops booting at this "only" message.

[arne anka (debian-ginguppin)]

still problematic with stefan bader's ppa's 2.6.31-16.51~pre2.
while the wifi disconnects and the led goes dark, kernel log still displays a stack trace.
watching this on a console (tty1-7) produced a stacktrace for every keypress and eventually locked up.
being in X did not look up, but i decided to reboot almost immediately nevertheless.

Nov 16 11:14:17 eeepc1000h kernel: [ 80.793162] pciehp 0000:00:1c.3:pcie04: Card not present on Slot(0-2)
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793296] ------------[ cut here ]------------
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793322] WARNING: at /build/buildd/linux-2.6.31/fs/sysfs/group.c:138 sysfs_remove_group+0xbe/0xc0()
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793334] Hardware name: 1000H
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793343] sysfs group c076b720 not found for kobject '0000:01:00.0'
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793352] Modules linked in: binfmt_misc snd_hda_codec_realtek snd_hda_intel snd_hda_codec i2c_dev i2c_i801 snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event joydev snd_seq snd_timer snd_seq_device iptable_filter snd uvcvideo ppdev ip_tables soundcore videodev psmouse lp snd_page_alloc x_tables rt2860sta(C) v4l1_compat eeepc_laptop serio_raw parport fbcon tileblit font bitblit softcursor atl1e i915 drm i2c_algo_bit intel_agp agpgart video output
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793474] Pid: 41, comm: pciehpd Tainted: G C 2.6.31-16-generic #51~pre2-Ubuntu
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793480] Call Trace:
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793493] [<c01450fd>] warn_slowpath_common+0x6d/0xa0
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793501] [<c023c4be>] ? sysfs_remove_group+0xbe/0xc0
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793508] [<c023c4be>] ? sysfs_remove_group+0xbe/0xc0
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793517] [<c0145176>] warn_slowpath_fmt+0x26/0x30
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793524] [<c023c4be>] sysfs_remove_group+0xbe/0xc0
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793534] [<c03a6220>] dpm_sysfs_remove+0x10/0x20
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793543] [<c03a0691>] device_del+0x31/0x150
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793551] [<c03a07bb>] device_unregister+0xb/0x20
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793559] [<c032445e>] pci_stop_bus_device+0x4e/0x60
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793567] [<c0324574>] pci_remove_bus_device+0x14/0x50
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793577] [<c03342cf>] pciehp_unconfigure_device+0x8f/0x1c0
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793586] [<c0332d99>] remove_board+0x19/0xf0
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793594] [<c0333676>] pciehp_disable_slot+0x56/0x190
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793603] [<c0333b08>] pciehp_power_thread+0x88/0x100
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793610] [<c0138007>] ? finish_task_switch+0x57/0xe0
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793619] [<c056ee6c>] ? schedule+0x40c/0x730
Nov 16 11:14:17 eeepc1000h kernel: [ 80.793628] [<c01579ce>] run_workqueue+0x6...

[Sergio Callegari (callegar)]

Is this fixed with the latest 2.6.31-15 that was delivered today?

[Ilja Sekler (ilja-sekler-)]

> Is this fixed with the latest 2.6.31-15 that was delivered today?

No. It would be nice to know what was the reason not to apply the ready-to-use patch to 2.6.31-15, even if it was intended to rebase to 2.6.31.5 or 2.6.31.6 later.

[pinzia (pinzia)]

@sergio.callegari
see comment 68 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/404626/comments/68

[Stefan Bader (smb)]

No, the patch was delayed because -15 was already uploaded to proposed for verification. There might be delays too by hiigh priority patches, too. One of the next ones. Though somehow comment 86 indicates this is not a fix in all cases.

[Ilja Sekler (ilja-sekler-)]

> the patch was delayed because -15 was already uploaded to proposed
> for verification.

There is something strange in the changelog <https://launchpad.net/ubuntu/karmic/+source/linux/+changelog> claiming two identical entries for 2.6.31-15.49: the first dated 2009-10-28 and the second 2009-11-10. The patch was checked in upstream on 2009-10-22: <http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.31.y.git;a=commitdiff;h=b5a56fc94bcc0910870391da8778ba1c6d41bd3d>. Does it mean, the first -15 was uploaded to proposed 5 days before the official timestamp in the changelog? And what about the second one?

> Though somehow comment 86 indicates this is not a fix in all cases.

I have the same hardware (Asus Eee PC 1000H) and can't reproduce the issue stated in comment #86 with 2.6.31-16.51~pre2 (no other issues turning wireless on/off with this kernel as well).

[Stefan Bader (smb)]

Ilja Sekler wrote:
>> the patch was delayed because -15 was already uploaded to proposed
>> for verification.
>
> There is something strange in the changelog
> <https://launchpad.net/ubuntu/karmic/+source/linux/+changelog> claiming
> two identical entries for 2.6.31-15.49: the first dated 2009-10-28 and
> the second 2009-11-10. The patch was checked in upstream on 2009-10-22:
> <http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.31.y.git;a=commitdiff;h=b5a56fc94bcc0910870391da8778ba1c6d41bd3d>.
> Does it mean, the first -15 was uploaded to proposed 5 days before the
> official timestamp in the changelog? And what about the second one?

Seems a weird issue with the way that log is generated. I have to check on
that. The real changelog in the repo has -15.49 which is dated 10-22.
The 10-28 date belongs to -15.50 which is missing the release date in
that case.

>> Though somehow comment 86 indicates this is not a fix in all cases.
>
> I have the same hardware (Asus Eee PC 1000H) and can't reproduce the
> issue stated in comment #86 with 2.6.31-16.51~pre2 (no other issues
> turning wireless on/off with this kernel as well).

Ok, thanks. So I guess if there still is a problem there, it best
should go into a new bug as it likely is a new/different problem.

[Wilford Argandoña (wilford)]

I have a netbook with the Realtek's 8187SE wireless card, and I have the same issue turning off the wireless with Fn+F2 keys. I tried with the Stefan's 2.6.31-16.51~pre2 kernel but the issue still happening. Do you think this patch should also fix the problem on my netbook's card? Thanks in advance.

[Bausparfuchs (bausparfuchs)]

Any ideas when that really annoying bug will be fixed by the regular updates without using a ppa or proposed update? For a workaround I installed the tool eee-control in karmic UNR.

Thanks

Jochen

[sanmiguel9 (againsttcpa84)]

I installed the 2.6.31-16.51~pre2 kernel from comment #68 on my Asus EeePC 1000H and it fixes the problem. I can now use the "Fn+F2" combo to toggle the state of my wlan card without any annoying system freezes. Great!!

[Stefan Bader (smb)]

Wilford Argandoña wrote:
> Stefan's 2.6.31-16.51~pre2 kernel but the issue still happening. Do you
> think this patch should also fix the problem on my netbook's card?

No, completely different driver. Please open a new/different bug for
that. Thanks.

[Stefan Bader (smb)]

Jochen Bauer wrote:
> Any ideas when that really annoying bug will be fixed by the regular
> updates without using a ppa or proposed update? For a workaround I

Hard to say. First, there will be some security updates which take
priority. Then the kernel including this patch gets uploaded into
proposed. Then it needs to get verified against the open bugs and
tested whether it might cause regressions. And then it goes into
updates.

[MilchFlasche (robertus0617)]

So I guess this would be painful to imagine how long would it take for us to
have a working new kernel update, were there not your pre-build package and
the testing PPA. Thanks again.

2009/11/30 Stefan Bader <email address hidden>

> Jochen Bauer wrote:
> > Any ideas when that really annoying bug will be fixed by the regular
> > updates without using a ppa or proposed update? For a workaround I
>
> Hard to say. First, there will be some security updates which take
> priority. Then the kernel including this patch gets uploaded into
> proposed. Then it needs to get verified against the open bugs and
> tested whether it might cause regressions. And then it goes into
> updates.
>

[Sergio Callegari (callegar)]

Would it be possible to devise a different process to deal with issues like these (namely bugs in drivers that are kernel modules) in the future?

Due to the need of guaranteeing the stability of the kernel even fixes for relatively simple bugs involving drivers like this one take months, with the result that people skip some distribution releases altogether.

Wouldn't it be possible and maybe easier in the future to deal with problems like this one by shipping out special packages containing only the source code of the fixed driver and using dkms to compile themselves and overriding the bugged modules?

In this way, only the people affected by the bug would install the fixing package, which could then be distributed with much less paranoia than a full kernel.

[Mark Hiscock (markhiscock)]

Hi All,

I find that if I have bluetooth enabled on my Eee PC 901 using 2.6.31-14-386 kernel then the crash does not happen. However, if bluetooth is disabled, the crash does happen.

Not sure if this is significant but it's some kind of workaround for people.

Mark

[Klaus Vormweg (klaus-vormweg-deactivatedaccount)]

This problem seems to resolved with todays kernel update to 2.6.31-16.52. At least on my Eee PC 1000H switching wi-fi on and off works with Fn+F" without problems.

[Sergey Dushkin (serg-157)]

Eee PC 901: I can confirm that after kernel update to 2.6.31-16.52 switching wi-fi on and off with Fn+F2 keys works without any problems

[Ilja Sekler (ilja-sekler-)]

The patch that fixes the crash is definitely not included in 2.6.31-16.52. This s*cks.

I can explain comments #101 and #102 only in the way that people, who claim the update to 2.6.31-16.52 has solved the bug, in fact run a different kernel like one from <https://launchpad.net/~stefan-bader-canonical/+archive/karmic>.

[Jim Connor (jim-canada)]

I agree with #103.

The 2.6.31-16-generic (stock kernel) on my 1000HE still kernel panics on alt-F2.

It's disappointing.

[John Stevenson (jr0cket)]

I still get a black screen on my eee1000 after the kernel update yesterday
in Karmic.

If there is a wireless connection, even if it is not the one in use (I plug
into a wired network), and I do Fn-F2 then I get a black screen.

If I disconnect from the wireless network, then I can switch off the
wireless card with Fn+F2 without issue.

I am able to switch on/off bluetooth using the bluetooth applet in the
panel.

Thanks
John

[Martin Pitt (pitti)]

Accepted linux into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[MasterX (trashmaster-disposal)]

The new kernel fixes this bug. Kernel doesn't crash anymore, when I shut down an active wifi connection with Fn+F2.
ASUS eeePC 1000H
Kernel: 2.6.31-17-generic

-> Fixed!

Thanks!

[Walter_Wittel (wittelw)]

Likewise Kernel 2.6.31-17-generic no longer hangs my Asus eeePC 901 when toggling an active wifi connection with Fn+F2. I also tried this with bluetooth both enabled and disabled and it worked both ways. Also ran system testing per Martin's link. Hope this is where I'm supposed to post the results. Thanks to all responsible for the fix!

[Tars (tars-ac)]

What is the recommended procedure to get back to the regular kernels once I'm on the PPA?

[Bausparfuchs (bausparfuchs)]

Regular Kernel fix made it. Great!

@tars what about removing the ppa, boot an older kernel and take the regular one?

[Stefan Bader (smb)]

Tars wrote:
> What is the recommended procedure to get back to the regular kernels
> once I'm on the PPA?
>
The regular proposed kernel will replace the PPA version as it has a
higher version number. You can simply de-select the PPA as a source in
software sources and the next proposed kernel will replace your PPA
version (or delete the PPA lines in /etc/apt/sources.list.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 2.6.31-17.54

---------------
linux (2.6.31-17.54) karmic-proposed; urgency=low

  [ John Johansen ]

  * SAUCE: AppArmor: Fix oops after profile removal
    - LP: #475619
  * SAUCE: AppArmor: Fix Oops when in apparmor_bprm_set_creds
    - LP: #437258
  * SAUCE: AppArmor: Fix cap audit_caching preemption disabling
    - LP: #479102
  * SAUCE: AppArmor: Fix refcounting bug causing leak of creds
    - LP: #479115
  * SAUCE: AppArmor: Fix oops there is no tracer and doing unsafe
    transition.
    - LP: #480112

  [ Leann Ogasawara ]

  * Revert "[Upstream] (drop after 2.6.31) usb-storage: Workaround devices
    with bogus sense size"
    - LP: #461556
  * Revert "[Upstream] (drop after 2.6.31) Input: synaptics - add another
    Protege M300 to rate blacklist"
    - LP: #480144

  [ Tim Gardner ]

  * [Config] udeb: Add squashfs to fs-core-modules
    - LP: #352615

  [ Upstream Kernel Changes ]

  * Revert "e1000e: swap max hw supported frame size between 82574 and
    82583"
    - LP: #461556
  * Revert "drm/i915: Fix FDI M/N setting according with correct color
    depth"
    - LP: #480144
  * Revert "agp/intel: Add B43 chipset support"
    - LP: #480144
  * Revert "drm/i915: add B43 chipset support"
    - LP: #480144
  * Revert "ACPI: Attach the ACPI device to the ACPI handle as early as
    possible"
    - LP: #327499, #480144
  * SCSI: Retry ADD_TO_MLQUEUE return value for EH commands
    - LP: #461556
  * SCSI: Fix protection scsi_data_buffer leak
    - LP: #461556
  * SCSI: sg: Free data buffers after calling blk_rq_unmap_user
    - LP: #461556
  * ARM: pxa: workaround errata #37 by not using half turbo switching
    - LP: #461556
  * tracing/filters: Fix memory leak when setting a filter
    - LP: #461556
  * x86/paravirt: Use normal calling sequences for irq enable/disable
    - LP: #461556
  * USB: ftdi_sio: remove tty->low_latency
    - LP: #461556
  * USB: ftdi_sio: remove unused rx_byte counter
    - LP: #461556
  * USB: ftdi_sio: clean up read completion handler
    - LP: #461556
  * USB: ftdi_sio: re-implement read processing
    - LP: #461556
  * USB: pl2303: fix error characters not being reported to ldisc
    - LP: #461556
  * USB: digi_acceleport: Fix broken unthrottle.
    - LP: #461556
  * USB: serial: don't call release without attach
    - LP: #461556
  * USB: option: Toshiba G450 device id
    - LP: #461556
  * USB: ipaq: fix oops when device is plugged in
    - LP: #461556
  * USB: cp210x: Add support for the DW700 UART
    - LP: #461556
  * USB: Fix throttling in generic usbserial driver
    - LP: #461556
  * USB: storage: When a device returns no sense data, call it a Hardware
    Error
    - LP: #400652, #461556
  * arm, cris, mips, sparc, powerpc, um, xtensa: fix build with bash 4.0
    - LP: #461556
  * intel-iommu: Cope with broken HP DC7900 BIOS
    - LP: #461556
  * futex: Detect mismatched requeue targets
    - LP: #461556
  * futex: Fix wakeup race by setting TASK_INTERRUPTIBLE before queue_me()
    - LP: #461556
  * tpm-fixup-pcrs-sysfs-file-update
    - LP: #461556
  * TPM: fix pcrread
    - LP: #461556
  * Bluetooth: Disconnect HIDRAW devices on disconnect
    - LP...

[Jeremy Foshee (jeremyfoshee)]

Setting Fix Released for the linux package.

[MrAuer (mr-auer)]

Kernel 2.6.31-19, Eee PC 701SD with 8GB SSD, toggling wlan with Fn-F2 still causes a kernel panic. Vanilla Karmic. I just tried it now. I don't know if I have time for extensive troubleshooting, since this is not my own laptop, but I was supposed to upgrade it to Karmic and then mail it back ASAP. I did not remember that it had a different wireless card from my own 701 4GB and 901, which both now work fine, wlan toggle and all.

So it is still NOT fixed for the 701SD with the RTL8187SE ,and the crash happens even when its not connected to any network when toggling, as well as when it is. Ill see if I need to mail the machine back today, or if I can keep it for a few more days to get more info (now I have just gotten a black screen whenever I toggle wlan off, have not yet tried to generate a crash report).

[MrAuer (mr-auer)]

Ah, there is a new 2.6.31-20 kernel available in proposed, going to try that.

[MrAuer (mr-auer)]

No difference, still hangs the machine.

[Steve Langasek (vorlon)]

Since the bug log shows that this new kernel did correct the issue for users with other hardware, I suggest you file a separate bug report for your ongoing issue.

[MrAuer (mr-auer)]

Yep, thats true. I will look into it today. My own Eee 701 4GB and 901 both work perfectly now...Its the bloody Realtek chipset on the 701SD ;) I suppose the SD model of the 701 is not so common either, since the 900 series was introduced and the older ones phased out around the time.

[Shawn Pringle (shawn.pringle)]

Here I am in 2017, and it seems to be a regression bug. A bug that has come back, or perhaps it was never fixed and the user who reported it fixed, did so because it went from always crashing to intermittent crashing. A user will learn not to turn off wifi and the symptom goes away. I am using an Exomate and not only does it panic when turning off wifi but on startup it panics intermittently whenever you use a USB device you left plugged into it or plug in a USB device. After many power cycles and with periods of remaining off, the perpetual panics abate but I know not to turn off wifi now.

As a user, I am getting similar symptoms. And I see this is my symptom and it is not so aptly described in the link above. Although the cause may not be same, people are going to come here when they search, as I did.

See also: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1482892
In the above link I post a outputs from lspci, lsmod, and dmesg.