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

Bug #404626 reported by Martijn vdS on 2009-07-25
250
This bug affects 42 people
Affects Status Importance Assigned to Milestone
Linux
Invalid
Medium
Release Notes for Ubuntu
Undecided
Unassigned
linux (Ubuntu)
High
Unassigned
Karmic
High
Stefan Bader

Bug Description

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) wrote :

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) wrote :
Martijn vdS (martijn) wrote :
Martijn vdS (martijn) wrote :
Martijn vdS (martijn) wrote :
Martijn vdS (martijn) wrote :
Martijn vdS (martijn) wrote :
Martijn vdS (martijn) wrote :
Martijn vdS (martijn) wrote :
Martijn vdS (martijn) wrote :
tags: added: apport-collected

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

Martijn vdS (martijn) wrote :

Trying with a mainline kernel next.

Martijn vdS (martijn) wrote :

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

Martijn vdS (martijn) on 2009-07-26
summary: - Toggling rfkill to "off" using Fn+F2 on Eee PC 901 results in kernel
- panic
+ Turning wifi "off" using Fn+F2 on Eee PC 901 results in kernel panic
+ (rfkill)
Changed in linux (Ubuntu):
importance: Undecided → High
status: New → Triaged

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) wrote :

Same thing with 2.6.31-rc5.

David Iwanowitsch (dav.id) wrote :

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

tags: added: kernel-oops
David Iwanowitsch (dav.id) wrote :

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

Walter_Wittel (wittelw) wrote :

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.

tags: added: karmic
David Iwanowitsch (dav.id) wrote :

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

summary: - Turning wifi "off" using Fn+F2 on Eee PC 901 results in kernel panic
- (rfkill)
+ Turning wifi "off" using Fn+F2 on Eee PC with Ralink rt2860 results in
+ kernel panic (rfkill)
Ritz (jonas-ritz) wrote :

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

Changed in linux:
status: Unknown → Confirmed
buull (wapmobil) wrote :

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) wrote :

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) wrote :

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!

Bug still exists in kernel .14-generic

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

MasterX (trashmaster-disposal) wrote :
Changed in linux (Ubuntu):
status: Triaged → Fix Committed
Ilja Sekler (ilja-sekler-) wrote :

The fix is *not* committed yet.

Changed in linux (Ubuntu):
status: Fix Committed → New

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

Changed in linux (Ubuntu):
status: New → Confirmed
Ruslan (b7-10110111) wrote :

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

Forest (foresto) on 2009-10-23
tags: added: karmic-blocker

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) wrote :

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

MrAuer (mr-auer) wrote :

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) wrote :

Addition - I have the ralink wireless.

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>

Changed in linux (Ubuntu):
status: Confirmed → Triaged
Forest (foresto) wrote :

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?

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>

Steve Langasek (vorlon) on 2009-10-28
Changed in ubuntu-release-notes:
status: New → Fix Released
Changed in linux (Ubuntu):
milestone: none → karmic-updates
Stefan Bader (smb) on 2009-11-12
Changed in linux (Ubuntu Karmic):
importance: Undecided → Medium
status: New → Fix Committed
assignee: nobody → Stefan Bader (stefan-bader-canonical)
milestone: none → karmic-updates
Changed in linux (Ubuntu):
milestone: karmic-updates → none
Changed in linux (Ubuntu Karmic):
importance: Medium → High
Stefan Bader (smb) on 2009-11-12
description: updated
Changed in linux (Ubuntu Karmic):
status: Fix Committed → Confirmed
Steve Langasek (vorlon) on 2009-11-13
Changed in linux (Ubuntu Karmic):
status: Confirmed → Fix Committed
39 comments hidden view all 119 comments
lanzen (lanzen) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

Is this the whole message?

ahamdan (ahamdan) wrote :

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

arne anka (debian-ginguppin) wrote :
Download full text (8.3 KiB)

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

Read more...

Changed in linux (Ubuntu Karmic):
status: Fix Committed → Fix Released
status: Fix Released → Fix Committed
Sergio Callegari (callegar) wrote :

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

Ilja Sekler (ilja-sekler-) wrote :

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

Stefan Bader (smb) wrote :

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-) 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?

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

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) wrote :

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) 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 installed the tool eee-control in karmic UNR.

Thanks

Jochen

sanmiguel9 (againsttcpa84) wrote :

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) wrote :

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) wrote :

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.

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) wrote :

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.

Kyle Weaver (kweaver87) on 2009-11-30
Changed in linux (Ubuntu Karmic):
status: Fix Committed → Fix Released
status: Fix Released → Fix Committed
Mark Hiscock (markhiscock) wrote :

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) wrote :

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) wrote :

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-) wrote :

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) wrote :

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) wrote :

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

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!

tags: added: verification-needed

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) wrote :

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) wrote :

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

Bausparfuchs (bausparfuchs) wrote :

Regular Kernel fix made it. Great!

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

Martin Pitt (pitti) on 2009-12-14
tags: added: verification-done
removed: verification-needed

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) wrote :
Download full text (11.9 KiB)

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

Changed in linux (Ubuntu Karmic):
status: Fix Committed → Fix Released
Jeremy Foshee (jeremyfoshee) wrote :

Setting Fix Released for the linux package.

Changed in linux (Ubuntu):
status: Triaged → Fix Released
MrAuer (mr-auer) wrote :

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) wrote :

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

MrAuer (mr-auer) wrote :

No difference, still hangs the machine.

Steve Langasek (vorlon) wrote :

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) wrote :

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.

Changed in linux:
importance: Unknown → Medium
Changed in linux:
status: Confirmed → Invalid
Shawn Pringle (shawn.pringle) wrote :

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.

Displaying first 40 and last 40 comments. View all 119 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.