mail archive Ubuntu bug tracker changes - HIGH VOLUME
ubuntu-bugs.lists.ubuntu.com
(List home) (Recent threads) (278 other Ubuntu lists)
Subscription Options
- RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
- Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
- Very high traffic list: 100+ messages per day
- This list contains about 2,108,047 messages, beginning Jun 2009
- 2,088 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no
[NEW] Toggling rfkill to off using Fn+F2 on Eee PC 901 results in kernel panic
Ad
Public bug reported:
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).
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Tags: apport-collected
** Attachment added: "Picture of the panic" http://launchpadlibrarian.net/29520055/img_09...
** Attachment added: "CurrentDmesg.txt" http://launchpadlibrarian.net/29520149/Curren...
** Attachment added: "BootDmesg.txt" http://launchpadlibrarian.net/29520148/BootDm...
** Attachment added: "Lspci.txt" http://launchpadlibrarian.net/29520150/Lspci....
** Attachment added: "Lsusb.txt" http://launchpadlibrarian.net/29520151/Lsusb....
** Attachment added: "ProcInterrupts.txt" http://launchpadlibrarian.net/29520153/ProcIn...
** Attachment added: "ProcCpuinfo.txt" http://launchpadlibrarian.net/29520152/ProcCp...
** Attachment added: "UdevDb.txt" http://launchpadlibrarian.net/29520155/UdevDb...
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.
** Attachment added: "ProcModules.txt" http://launchpadlibrarian.net/29520154/ProcMo...
** Attachment added: "UdevLog.txt" http://launchpadlibrarian.net/29520157/UdevLo... ** Tags added: apport-collected
Toggling wifi on (when booted with wifi off) works as expected.
Same thing happens with 2.6.31-rc4 mainline build from http://kernel.ubuntu.com/~kernel-ppa/mainline...
** Changed in: linux (Ubuntu)
Importance: Undecided => High
** Changed in: linux (Ubuntu)
Status: New => Triaged
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
With Karmic and mainline kernel 2.6.31-rc7 its still not working :(
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.
** Bug watch added: Linux Kernel Bug Tracker #13390 http://bugzilla.kernel.org/show_bug.cgi?id=13... ** Also affects: linux via http://bugzilla.kernel.org/show_bug.cgi?id=13... Importance: Unknown Status: Unknown
The problem is not fixed in 2.6.31 release, but there is a workaround in the upstream bug. ** Summary changed: - 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)
with no card installed you can toggle the blue led on and off with Fn+F2
** Changed in: linux
Status: Unknown => Confirmed
Bug duplicated?: https://bugs.launchpad.net/ubuntu/+source/lin...
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.
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=13...
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!
Like said- disconnect the wificonnection before toggling the hardware off avoids the crash.
or alternatively http://bugzilla.kernel.org/show_bug.cgi?id=13...
for fix see this comment: http://bugzilla.kernel.org/show_bug.cgi?id=13... ** Changed in: linux (Ubuntu) Status: Triaged => Fix Committed
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
Kernel 2.6.32-rc5 has this bug fixed, at least changelog says this.
Yes, the patch has been checked in upstream: <http://git.kernel.org/?p=linux/kernel/git/tor...>.
Just got bitten by this again, thanks to my infant son poking around on my keyboard with his hands. Please fix soon!
It's not needed to subscribe Ubuntu Drivers to bugs, I've removed the subscription.
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.
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... 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 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=13... panic http://bugzilla.kernel.org/attachment.cgi?id=... Signed-off-by: Darren Salt Signed-off-by: Greg Kroah-Hartman ** Changed in: linux (Ubuntu) Status: Confirmed => Triaged
** Also affects: ubuntu-release-notes
Importance: Undecided
Status: New
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?
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.On Tue, Oct 27, 2009 at 05:35:53AM -0000, Forest wrote: > I think this patch might warrant a kernel freeze exception.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/> Why advertise a netbook distribution whose net connectivity is broken for > two major releases in a row?
>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.
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..." 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. ** Attachment added: "00002.jpg" http://launchpadlibrarian.net/34453038/00002....
Can't the patch just be backported to currently used kernel rather then rebase ubuntu to new version?
Documented at <https://wiki.ubuntu.com/KarmicKoala/ReleaseNo...>: 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) ** Changed in: ubuntu-release-notes Status: New => Fix Released
15 2009-10-28 13:23:01 13139 vorlon errata for bug #404626 view Awesome, thank you.
** Changed in: linux (Ubuntu)
Milestone: None => karmic-updates
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 .... ;)
> 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.
I would just like to add from my own experience that this problem also affects the eeepc 701SD.
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.
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. >
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?
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.
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?
Or perhaps its best to wait a while for this to (maybe) be fixed via regular updates...
will the wifi card be visible with lspci, if the driver is not present?
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.
Hasn't this bug been fixed already?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.>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.
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
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.
>>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?
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.
The EEEPC ACPI scripts don't help the problem with my 901. I still get a black screen when I toggle WIFI off.
Alas, still present in the karmic-proposed 2.6.31-15-generic #49-Ubuntu SMP update
This bug affects me too.
Ubuntu karmic with lastest updates. Eee PC 901.
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)?
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.
** Also affects: linux (Ubuntu Karmic)
Importance: Undecided
Status: New
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... (2.6.31-16.51~pre2). If that finishes, could someone test whether this is true? Thanks. ** Changed in: linux (Ubuntu Karmic) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Karmic) Status: New => Fix Committed ** Changed in: linux (Ubuntu Karmic) Milestone: None => karmic-updates ** Changed in: linux (Ubuntu Karmic) Assignee: (unassigned) => Stefan Bader (stefan-bader-canonical) ** Changed in: linux (Ubuntu) Milestone: karmic-updates => None ** Changed in: linux (Ubuntu Karmic) Importance: Medium => High
Boot, Fn-F2 toggles wi-fi and does NOT cause a kernel crash. Not much else tested. -jh
sorry, forgot to say "Thanks" for building this. -jh
** Description changed: + 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).
** Changed in: linux (Ubuntu Karmic)
Status: Fix Committed => Confirmed
** Changed in: linux (Ubuntu Karmic)
Status: Confirmed => Fix Committed
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!
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!
It's great that this does work. But will this be available as a usual update, or i will have to add ppa etc.?
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 :)
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.
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.
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"
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.
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?
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!
Yes Sir. The system stops booting at this "only" message.
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+0x6e/0x140 Nov 16 11:14:17 eeepc1000h kernel: [ 80.793636] [<c0333a80>] ? pciehp_power_thread+0x0/0x100 Nov 16 11:14:17 eeepc1000h kernel: [ 80.793644] [<c0157b28>] worker_thread+0x88/0xe0 Nov 16 11:14:17 eeepc1000h kernel: [ 80.793653] [<c015c170>] ? autoremove_wake_function+0x0/0x40 Nov 16 11:14:17 eeepc1000h kernel: [ 80.793661] [<c0157aa0>] ? worker_thread+0x0/0xe0 Nov 16 11:14:17 eeepc1000h kernel: [ 80.793668] [<c015be7c>] kthread+0x7c/0x90 Nov 16 11:14:17 eeepc1000h kernel: [ 80.793675] [<c015be00>] ? kthread+0x0/0x90 Nov 16 11:14:17 eeepc1000h kernel: [ 80.793684] [<c0104007>] kernel_thread_helper+0x7/0x10 Nov 16 11:14:17 eeepc1000h kernel: [ 80.793689] ---[ end trace ff474051a9831bf3 ]--- Nov 16 11:14:17 eeepc1000h kernel: [ 80.793708] BUG: unable to handle kernel NULL pointer dereference at 00000010 Nov 16 11:14:17 eeepc1000h kernel: [ 80.793813] IP: [<c055e768>] klist_put+0x18/0x80 Nov 16 11:14:17 eeepc1000h kernel: [ 80.793878] *pde = 00000000 Nov 16 11:14:17 eeepc1000h kernel: [ 80.793920] Oops: 0000 [#1] SMP Nov 16 11:14:17 eeepc1000h kernel: [ 80.793972] last sysfs file: /sys/devices/platform/eeepc/rfkill/rfkill0/uevent Nov 16 11:14:17 eeepc1000h kernel: [ 80.794053] 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.794837] Nov 16 11:14:17 eeepc1000h kernel: [ 80.794862] Pid: 41, comm: pciehpd Tainted: G WC (2.6.31-16-generic #51~pre2-Ubuntu) 1000H Nov 16 11:14:17 eeepc1000h kernel: [ 80.794960] EIP: 0060:[<c055e768>] EFLAGS: 00010246 CPU: 0 Nov 16 11:14:17 eeepc1000h kernel: [ 80.795025] EIP is at klist_put+0x18/0x80 Nov 16 11:14:17 eeepc1000h kernel: [ 80.795073] EAX: 00000000 EBX: f70d2494 ECX: fffff63d EDX: 00000001 Nov 16 11:14:17 eeepc1000h kernel: [ 80.795144] ESI: 00000000 EDI: f7103058 EBP: f684be30 ESP: f684be20 Nov 16 11:14:17 eeepc1000h kernel: [ 80.795215] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Nov 16 11:14:17 eeepc1000h kernel: [ 80.795278] Process pciehpd (pid: 41, ti=f684a000 task=f68225b0 task.ti=f684a000) Nov 16 11:14:17 eeepc1000h kernel: [ 80.795360] Stack: Nov 16 11:14:17 eeepc1000h kernel: [ 80.795387] f70ce200 f7108058 00000000 f7103058 f684be38 c055e7fd f684be4c c03a06a0 Nov 16 11:14:17 eeepc1000h kernel: [ 80.795517] <0> f7108058 00000000 f7108000 f684be58 c03a07bb f7108000 f684be6c c032445e Nov 16 11:14:17 eeepc1000h kernel: [ 80.795661] <0> f7108000 00000000 f727bd80 f684be7c c0324574 f7108000 00000000 f684bec0 Nov 16 11:14:17 eeepc1000h kernel: [ 80.795810] Call Trace: Nov 16 11:14:17 eeepc1000h kernel: [ 80.795846] [<c055e7fd>] ? klist_del+0xd/0x10 Nov 16 11:14:17 eeepc1000h kernel: [ 80.795901] [<c03a06a0>] ? device_del+0x40/0x150 Nov 16 11:14:17 eeepc1000h kernel: [ 80.795959] [<c03a07bb>] ? device_unregister+0xb/0x20 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796021] [<c032445e>] ? pci_stop_bus_device+0x4e/0x60 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796086] [<c0324574>] ? pci_remove_bus_device+0x14/0x50 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796153] [<c03342cf>] ? pciehp_unconfigure_device+0x8f/0x1c0 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796225] [<c0332d99>] ? remove_board+0x19/0xf0 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796284] [<c0333676>] ? pciehp_disable_slot+0x56/0x190 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796351] [<c0333b08>] ? pciehp_power_thread+0x88/0x100 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796416] [<c0138007>] ? finish_task_switch+0x57/0xe0 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796479] [<c056ee6c>] ? schedule+0x40c/0x730 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796537] [<c01579ce>] ? run_workqueue+0x6e/0x140 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796598] [<c0333a80>] ? pciehp_power_thread+0x0/0x100 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796663] [<c0157b28>] ? worker_thread+0x88/0xe0 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796723] [<c015c170>] ? autoremove_wake_function+0x0/0x40 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796791] [<c0157aa0>] ? worker_thread+0x0/0xe0 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796849] [<c015be7c>] ? kthread+0x7c/0x90 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796903] [<c015be00>] ? kthread+0x0/0x90 Nov 16 11:14:17 eeepc1000h kernel: [ 80.796956] [<c0104007>] ? kernel_thread_helper+0x7/0x10 Nov 16 11:14:17 eeepc1000h kernel: [ 80.797017] Code: 3f 00 00 00 b8 d8 fd 70 c0 e8 e5 69 be ff 5d c3 8d 76 00 55 89 e5 83 ec 10 89 5d f4 89 c3 89 75 f8 89 7d fc 8b 30 83 e6 fe 89 f0 <8b> 7e 10 88 55 f0 e8 2d 26 01 00 0f b6 55 f0 84 d2 74 0b 8b 03 Nov 16 11:14:17 eeepc1000h kernel: [ 80.797251] EIP: [<c055e768>] klist_put+0x18/0x80 SS:ESP 0068:f684be20 Nov 16 11:14:17 eeepc1000h kernel: [ 80.797251] CR2: 0000000000000010 Nov 16 11:14:17 eeepc1000h kernel: [ 80.797795] ---[ end trace ff474051a9831bf4 ]---
** Changed in: linux (Ubuntu Karmic)
Status: Fix Committed => Fix Released
** Changed in: linux (Ubuntu Karmic)
Status: Fix Released => Fix Committed
Is this fixed with the latest 2.6.31-15 that was delivered today?
> 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.
@sergio.callegari see comment 68 https://bugs.launchpad.net/ubuntu/+source/lin...
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.
There is something strange in the changelog <https://launchpad.net/ubuntu/karmic/+source/l...> 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/sta...>. 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).
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.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.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/l...> 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/sta...>. > 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?
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.
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
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 > 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. >
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!!
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.
** Changed in: linux (Ubuntu Karmic)
Status: Fix Committed => Fix Released
** Changed in: linux (Ubuntu Karmic)
Status: Fix Released => Fix Committed
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
** Branch linked: lp:ubuntu/linux-mvl-dove
** Branch linked: lp:ubuntu/linux-fsl-imx51
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.
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
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>.
I agree with #103. The 2.6.31-16-generic (stock kernel) on my 1000HE still kernel panics on alt-F2. It's disappointing.
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/EnablePropose... 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!
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!
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.
Regular Kernel fix made it. Great! @tars what about removing the ppa, boot an older kernel and take the regular one?
** Tags added: verification-done ** Tags removed: verification-needed
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: #461556
* Bluetooth: Add extra device reference counting for connections
- LP: #461556
* Bluetooth: Let HIDP grab the device reference for connections
- LP: #461556
* connector: Keep the skb in cn_callback_data
- LP: #461556
* connector: Provide the sender's credentials to the callback
- LP: #461556
* connector: Removed the destruct_data callback since it is always
kfree_skb()
- LP: #461556
* dm/connector: Only process connector packages from privileged processes
- LP: #461556
* dst/connector: Disallow unpliviged users to configure dst
- LP: #461556
* pohmelfs/connector: Disallow unpliviged users to configure pohmelfs
- LP: #461556
* uvesafb/connector: Disallow unpliviged users to send netlink packets
- LP: #461556
* e1000e: swap max hw supported frame size between 82574 and 82583
- LP: #461556, #445572
* MAINTAINERS: Fix Riku Voipio's address
- LP: #461556
* macintosh: Don't assume i2c device probing always succeeds
- LP: #461556
* i2c: Hide probe errors caused by ACPI resource conflicts
- LP: #461556
* ALSA: Don't assume i2c device probing always succeeds
- LP: #461556
* bsdacct: switch credentials for writing to the accounting file
- LP: #461556
* sysfs: Allow sysfs_notify_dirent to be called from interrupt context.
- LP: #461556
* Staging: rt2860sta: prevent a panic when disabling when associated
- LP: #461556, #404626
* usb-storage: Workaround devices with bogus sense size
- LP: #461556, #446146
* iwlwifi: incorrect method used for finding valid OTP blocks
- LP: #461556
* mac80211: fix vlan and optimise RX
- LP: #461556
* tty: Make flush_to_ldisc() locking more robust
- LP: #461556
* Linux 2.6.31.5
- LP: #461556
* fs: pipe.c null pointer dereference
- LP: #480144
* pci: increase alignment to make more space for hidden code
- LP: #407824, #480144, #474577
* libata: fix internal command failure handling
- LP: #480144
* libata: fix PMP initialization
- LP: #480144
* sata_nv: make sure link is brough up online when skipping hardreset
- LP: #480144
* nfs: Fix nfs_parse_mount_options() kfree() leak
- LP: #480144
* KVM: use proper hrtimer function to retrieve expiration time
- LP: #480144
* KVM: ignore reads from AMDs C1E enabled MSR
- LP: #480144
* futex: Handle spurious wake up
- LP: #480144
* futex: Check for NULL keys in match_futex
- LP: #480144
* futex: Move drop_futex_key_refs out of spinlock'ed region
- LP: #480144
* futex: Fix spurious wakeup for requeue_pi really
- LP: #480144
* ahci: revert "Restore SB600 sata controller 64 bit DMA"
- LP: #480144
* sparc64: Set IRQF_DISABLED on LDC channel IRQs.
- LP: #480144
* watchdog: Fix rio watchdog probe function
- LP: #480144
* Input: synaptics - add another Protege M300 to rate blacklist
- LP: #480144
* dm snapshot: free exception store on init failure
- LP: #480144
* dm snapshot: sort by chunk size to fix race
- LP: #480144
* dm log: userspace fix incorrect luid cast in userspace_ctr
- LP: #480144
* dm: add missing del_gendisk to alloc_dev error path
- LP: #480144
* dm: dec_pending needs locking to save error value
- LP: #480144
* dm exception store: fix failed set_chunk_size error path
- LP: #480144
* dm snapshot: lock snapshot while supplying status
- LP: #480144
* dm snapshot: require non zero chunk size by end of ctr
- LP: #480144
* dm snapshot: use unsigned integer chunk size
- LP: #480144
* ray_cs: Fix copy_from_user handling
- LP: #480144
* mbind(): fix leak of never putback pages
- LP: #480144
* do_mbind(): fix memory leak
- LP: #480144
* 8250_pci: add IBM Saturn serial card
- LP: #480144
* dpt_i2o: Fix up copy*user
- LP: #480144
* dpt_i2o: Fix typo of EINVAL
- LP: #480144
* hfsplus: refuse to mount volumes larger than 2TB
- LP: #480144
* Driver core: fix driver_register() return value
- LP: #480144
* param: fix lots of bugs with writing charp params from sysfs, by
leaking mem.
- LP: #480144
* param: fix NULL comparison on oom
- LP: #480144
* param: fix setting arrays of bool
- LP: #480144
* USB: serial: sierra driver send_setup() autopm fix
- LP: #480144
* USB: option: Patch for Huawei Mobile Broadband E270+ Modem
- LP: #480144
* USB: option: Support for AIRPLUS MCD650 Datacard
- LP: #480144
* USB: option: TLAYTECH TUE800 support
- LP: #456264, #480144
* libertas if_usb: Fix crash on 64-bit machines
- LP: #480144
* cpuidle: always return with interrupts enabled
- LP: #480144
* virtio: order used ring after used index read
- LP: #480144
* CIFS: Fixing to avoid invalid kfree() in cifs_get_tcp_session()
- LP: #480144
* mac80211: fix for incorrect sequence number on hostapd injected frames
- LP: #480144
* mac80211: check interface is down before type change
- LP: #480144
* x86, UV: Fix information in __uv_hub_info structure
- LP: #480144
* x86, UV: Set DELIVERY_MODE=4 for vector=NMI_VECTOR in uv_hub_send_ipi()
- LP: #480144
* NOMMU: Don't pass NULL pointers to fput() in do_mmap_pgoff()
- LP: #480144
* mm: remove incorrect swap_count() from try_to_unuse()
- LP: #480144
* x86-64: Fix register leak in 32-bit syscall audting
- LP: #480144
* nilfs2: fix dirty page accounting leak causing hang at write
- LP: #480144
* drm/i915: Fix FDI M/N setting according with correct color depth
- LP: #480144
* drm/i915: fix to setup display reference clock control on Ironlake
- LP: #480144
* drm/i915: fix panel fitting filter coefficient select for Ironlake
- LP: #480144
* agp/intel: Add B43 chipset support
- LP: #480144
* drm/i915: add B43 chipset support
- LP: #480144
* xen/hvc: make sure console output is always emitted, with explicit
polling
- LP: #480144
* xen: mask extended topology info in cpuid
- LP: #480144
* sgi-gru: decrapfiy options_write() function
- LP: #480144
* KVM: get_tss_base_addr() should return a gpa_t
- LP: #480144
* fuse: prevent fuse_put_request on invalid pointer
- LP: #480144
* fuse: fix kunmap in fuse_ioctl_copy_user
- LP: #480144
* x86/amd-iommu: Workaround for erratum 63
- LP: #480144
* fsnotify: do not set group for a mark before it is on the i_list
- LP: #480144
* mips: fix build of vmlinux.lds
- LP: #480144
* alpha: fix build after vmlinux.lds.S cleanup
- LP: #480144
* ACPI / PCI: Fix NULL pointer dereference in acpi_get_pci_dev() (rev. 2)
- LP: #480144
* KEYS: get_instantiation_keyring() should inc the keyring refcount in
all cases
- LP: #480144
* b43: Fix Bugzilla #14181 and the bug from the previous 'fix'
- LP: #476154, #480144
* pata_sc1200: Fix crash on boot
- LP: #480144
* AF_UNIX: Fix deadlock on connecting to shutdown socket (CVE-2009-3621)
- LP: #480144
* ALSA: ice1724 - Make call to set hw params succeed on ESI Juli@
- LP: #480144
* bonding: fix a race condition in calls to slave MII ioctls
- LP: #480144
* hwmon: (it87) Fix VID reading on IT8718F/IT8720F
- LP: #480144
* netlink: fix typo in initialization (CVE-2009-3612)
- LP: #480144
* nfs: Avoid overrun when copying client IP address string
- LP: #480144
* nfs: Panic when commit fails
- LP: #480144
* NFSv4: Fix a bug when the server returns NFS4ERR_RESOURCE
- LP: #480144
* NFSv4: Fix two unbalanced put_rpccred() issues.
- LP: #459265, #480144
* NFSv4: Kill nfs4_renewd_prepare_shutdown()
- LP: #480144
* NFSv4: The link() operation should return any delegation on the file
- LP: #480144
* powerpc: Remove SMP warning from PowerMac cpufreq
- LP: #480144
* vmscan: limit VM_EXEC protection to file pages
- LP: #480144
* x86: mce: Clean up thermal throttling state tracking code
- LP: #480144
* x86: mce: Fix thermal throttling message storm
- LP: #453444, #480144
* iwlwifi: fix potential rx buffer loss
- LP: #480144
* iwlwifi: reduce noise when skb allocation fails
- LP: #480144
* x86/amd-iommu: Un__init function required on shutdown
- LP: #480144
* KVM: Prevent kvm_init from corrupting debugfs structures
- LP: #480144
* powerpc/pmac: Fix PowerSurge SMP IPI allocation
- LP: #480144
* powerpc/pmac: Fix issues with sleep on some powerbooks
- LP: #480144
* powerpc/pci: Fix regression in powerpc MSI-X
- LP: #480144
* powerpc: Fix some late PowerMac G5 with PCIe ATI graphics
- LP: #480144
* sata_via: Remove redundant device ID for VIA VT8261
- LP: #480144
* pata_via: extend the rev_max for VT6330
- LP: #480144
* PM / yenta: Split resume into early and late parts (rev. 4)
- LP: #480144
* Linux 2.6.31.6
- LP: #480144
-- Stefan Bader Thu, 03 Dec 2009 22:57:36 +0100
** Changed in: linux (Ubuntu Karmic)
Status: Fix Committed => Fix Released
** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2009-3612
** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2009-3621
Setting Fix Released for the linux package.
** Changed in: linux (Ubuntu)
Status: Triaged => Fix Released
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).
Ah, there is a new 2.6.31-20 kernel available in proposed, going to try that.
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.
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
Ad