Kernel-Panic with 3.0.0.12-generic on asus eee pcs and msi wind (both using rt2800 wifi chipset)

[Michael Basse]

The latest Kernel

michael@eeebuntu:/var/log$ uname -a
Linux eeebuntu 3.0.0-12-generic #19-Ubuntu SMP Fri Sep 23 21:18:13 UTC 2011 i686 i686 i386 GNU/Linux

has about 10 Kernelpanics here. All happened on a eeepc 901 from Asus.

Because i have not found anything in /var/log/* i only have a picture from that panic.

Panics are happening with and without power-adapter plugged in

Please let me know if you need more infos

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: linux-image-3.0.0-12-generic 3.0.0-12.19
ProcVersionSignature: Ubuntu 3.0.0-12.19-generic 3.0.4
Uname: Linux 3.0.0-12-generic i686
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
AplayDevices:
 **** List of PLAYBACK Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC269 Analog [ALC269 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
ApportVersion: 1.23-0ubuntu2
Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC269 Analog [ALC269 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: michael 1430 F.... pulseaudio
CRDA: Error: [Errno 2] Datei oder Verzeichnis nicht gefunden
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xf7eb8000 irq 44'
   Mixer name : 'Realtek ALC269'
   Components : 'HDA:10ec0269,1043831a,00100004'
   Controls : 12
   Simple ctrls : 7
Date: Thu Oct 6 22:45:44 2011
EcryptfsInUse: Yes
HibernationDevice: RESUME=UUID=3147250b-39a6-47ab-92dd-3ae71a43c9a8
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release i386 (20110426)
MachineType: ASUSTeK Computer INC. 901
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-12-generic root=UUID=797c12e0-f5e5-4b81-9464-0d8de0ce0a16 ro acpi_osi=Linux acpi_backlight=vendor quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.0.0-12-generic N/A
 linux-backports-modules-3.0.0-12-generic N/A
 linux-firmware 1.60
SourcePackage: linux
UpgradeStatus: Upgraded to oneiric on 2011-09-16 (20 days ago)
dmi.bios.date: 06/11/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 2103
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.:bvr2103:bd06/11/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.

[Gareth (gareth-redhat-bugs-1)]

I also see this or similar behaviour with both 2.6.40 kernel updates, but not 2.6.38.

Often the system doesn't drop to text mode, or the screen is scrambled with panic text overlaid. I also get a panic if I login in text-mode, but it usually takes longer.

The most common panic is "BUG: unable to handle kernel NULL pointer dereference", although sometimes it's "Not syncing".

/var/log/messages contains over 300 MiB of such text:
"BUG: scheduling while atomic: swapper"
"bad: scheduling from the idle thread!"

My system: Fedora 15 x86-64, Intel Core i7 940, Asus P6T Deluxe motherboard, NVIDIA 9800 GT graphics with default up-to-date nouveau driver, untainted kernel.

(Screen-shots and log extracts available on request.)

Gareth

[Josip-g (josip-g)]

Probably related to bug 732008 which has a crash screen picture (that bug occurs immediately on boot, within one second)

[Dave (dave-redhat-bugs)]

> (Screen-shots and log extracts available on request.)

We really need only the first one from each session.
A lot of the time an oops or similar warning will occur, and then the kernel state is so messed up that 'follow-up' oopses happen afterwards that aren't really useful.

[Gareth (gareth-redhat-bugs-1)]

Created attachment 519736
Extract from /var/log/messages

Extract from /var/log/messages, starting just before the first kernel oops (as far as I can tell). This and similar errors then repeat for 350 MiB.

[Gareth (gareth-redhat-bugs-1)]

Created attachment 519737
Kernel message as on-screen

This is the sort of thing I see on the screen when the error happens - if I'm lucky enough to see anything on-screen at all: often it just freezes.

[Roland (roland-redhat-bugs)]

Had the same troubles. My temporary solution:
Install "Kernel 2.6.40.3-0.fc15.x86-64.debug" e.g. by using yumextender.
It worked. No idea why though ...

[Dave (dave-redhat-bugs)]

there's a lot going on here, but my gut is telling me this is related to the wireless driver (if only because it's the only prominent thing in the stack traces).

Maybe John has some clues..

Dirk, does this look like the same thing you're seeing ?

[Gareth (gareth-redhat-bugs-1)]

That sounds reasonable. I've noticed a single panic with 2.6.38 which seemed to be rt2500-related.

I'll attach my lspci -vvxxx output in case it helps.

If there's a general feeling that this is related to the rt2500 driver I can ask on the FedoraForums to see if anyone else is having similar problems.

Gareth

[Gareth (gareth-redhat-bugs-1)]

Created attachment 521064
lspci -vvxxx output

The rt2500 hardware is near the end of the file.

[John (john-redhat-bugs)]

Looks like it could relate to power saving mode. You might try this:

   iw dev wlan0 set power_save off

Does that change the issue?

[Gareth (gareth-redhat-bugs-1)]

I added "iw ..." to my /etc/rc.local (I didn't want to bet on having time to type it manually).

So far, so good - 25 mins uptime, which is *considerably* more than I've ever managed with 2.6.40 before.

It's pub time for me now, but I'll report back when I've got some serious usage out of it tomorrow.

Gareth

[Gareth (gareth-redhat-bugs-1)]

Okay, just to confirm, the suggested iw work-around makes 2.6.40 usable for me.

[Dirk (dirk-redhat-bugs)]

(In reply to comment #7)
> there's a lot going on here, but my gut is telling me this is related to the
> wireless driver (if only because it's the only prominent thing in the stack
> traces).
>
> Maybe John has some clues..
>
> Dirk, does this look like the same thing you're seeing ?

I've made some photos of the kernel panic message since the system freezes and doesn't allow for screen shots.

[Dirk (dirk-redhat-bugs)]

Created attachment 521389
Photos of kernel panic message after system freeze

[Gareth (gareth-redhat-bugs-1)]

Dirk and Roland, are you using the rt2500 wireless driver (or similar)? If so, does John's command stop the kernel panics?

Also take a look at your /var/log/messages, as what appears on screen is probably the end result of the problem, not necessarily the start.

That'd be the easiest way to see if you're affected by the same bug as me, whether it's more complicated, or even multiple different bugs.

Gareth

[Dirk (dirk-redhat-bugs)]

(In reply to comment #15)
> Dirk and Roland, are you using the rt2500 wireless driver (or similar)? If so,
> does John's command stop the kernel panics?
>
> Also take a look at your /var/log/messages, as what appears on screen is
> probably the end result of the problem, not necessarily the start.
>
> That'd be the easiest way to see if you're affected by the same bug as me,
> whether it's more complicated, or even multiple different bugs.
>
> Gareth

Using rt2500pci rt2x00lib

John's command seems to stop the kernel panic. System is up one hour now. Without

iw dev wlan0 set power_save off

panic occurred after a couple of minutes.

Regarding /var/log/messages not sure which part might be of any interest now.

[Gareth (gareth-redhat-bugs-1)]

Okay, ditto, I think that's enough to be sure we're seeing the same bug.

[Roland (roland-redhat-bugs)]

(In reply to comment #15)
> Dirk and Roland, are you using the rt2500 wireless driver (or similar)? If so,
> does John's command stop the kernel panics?
>
> Also take a look at your /var/log/messages, as what appears on screen is
> probably the end result of the problem, not necessarily the start.
>
> That'd be the easiest way to see if you're affected by the same bug as me,
> whether it's more complicated, or even multiple different bugs.
>
> Gareth

Gareth,
That PC has no wireless. Therefore, I suppose it has no wireselss drivers installed. Or could it?

Furher, I cannot read the screen so fast. If you need exact info about what happens, please tell me which file to read. And also how to access it, because ... since a while Fedora has changed so that I can no longer operate root in graphical mode. As a dillettant, I find it very difficult to keep this operating system in the air now. Would you have an advice about this?

Roland

[Michael Basse (michael-alpha-unix)]

also the kernel-panic never happened with 3.0.0-11 just with 3.0.0-12

[Ian Corne (icorne)]

This happens to me too on Asus eee 1000H

Never on my desktop/other laptops.

[Michael Basse (michael-alpha-unix)]

Happened again on eeepc 901 with 3.0.0-12-generic.

I was doing nothing for 5-10 Minutes on the netbook, then the panic happened. Maybe some standby-rules triggered it?

Picture of the panic is attached

[Joseph Salisbury (jsalisbury)]

@Michael

Would it be possible for you to roll back to the 3.0.0-11 kernel? That would confirm that there is a possible regression. It will also confirm there are no new hardware issues since upgrading to the new kernel.

[Michael Basse (michael-alpha-unix)]

Hi Joseph,
of course it is possible. I will run this system on 3.0.0-11-generic.

But i think i cant give you a feedback this week because at the weekend this system is not used very often.

[Joseph Salisbury (jsalisbury)]

@Ian

Would it be possible for you to test your system on 3.0.0-11-generic. That would confirm this as a regression.

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help, we really do appreciate it.

[Michael Basse (michael-alpha-unix)]

@Joseph,
i was running 3.0.0-11-generic for 3 days without a kernel-panic. Dont know if that is enough time to say that 3.0.0-11-generic is not affected. However, i am now using 3.0.0.12.20-generic as Brad suggested.

I will put some info here (and change the bug-status) after some days of testing

[Michael Basse (michael-alpha-unix)]

Happening also with 3.0.0.12.20-generic

[Michael Basse (michael-alpha-unix)]

are there any task i can do to give a better report about this issue?

[Joseph Salisbury (jsalisbury)]

@Michael,

Thanks for confirming the issue does not happen with 3.0.0-11-generic. Posting a screen shot of the panic you had while running 3.0.0.12.20-generic would help.

Also, would it be possible for you to test the latest upstream kernel? It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

[Ian Corne (icorne)]

I am sorry i'm being so passive in this case, I don't use my eee all that much and as such, won't be much use.

[Michael Basse (michael-alpha-unix)]

Joseph, thank your for the feedback and your time.

First of all there was another kernel-panic on 3.0.0-12.20-generic which i will append here. The last screenshot was also from 3.0.0-12.20-generic

At the moment i am using this kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.1-rc9-oneiric/

michael@eeebuntu:/var/log# uname -a
Linux eeebuntu 3.1.0-0301rc9-generic #201110050905 SMP Wed Oct 5 11:20:31 UTC 2011 i686 i686 i386 GNU/Linux

I will test this kernel if the panic still comes up.

FYI: at booting i get but that should be a problem for my tests

./boot.log:Cache read/write disabled: /sys/kernel/security/apparmor/features interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.)

[Yann Benigot (yann-benigot)]

Another kernel panic

[Joseph Salisbury (jsalisbury)]

@Michael

Were you able to test the v3.1-rc9-oneiric kernel?

[Yann Benigot (yann-benigot)]

I have tried other kernels and experienced kernel panics with all of them. Tested kernels : 3.0.0-11, 3.0.0-12, 3.0.6-030006, 3.1.0-0301rc9. Perhaps my problem is different since the panic screen differs from the other shown.

[Michael Basse (michael-alpha-unix)]

Joseph, after 3 Days of testing (20 hours uptime each day) there wa no kernel-panic with 3.1.0-0301rc9-generic

Is there something i can help with for the next steps?

[Michael Basse (michael-alpha-unix)]

@Yann
hm strange, with 3.0.0-11 and 3.1.0-0301rc9-generic i dont get kernel-panics on the eeepc 901. All Versions from 3.0.0-12 produced a panic here.

Maybe 3 Days are not enough time for testing here but with the 3.0.0-12 kernels there is more then one panic a day (20hours uptime) and with the other kernels not

[Yann Benigot (yann-benigot)]

I just experienced another panic. The panic message changes each time so it may be the same problem after all. I get about one panic per hour and they seem more frequent when the system is idle : I leave the room for a few minutes and when I come back I see the black screen... I also had kernel panics with arch linux, but only on shutdown. (the last one corrupted the root partition, so I switched back to ubuntu)

[Michael Basse (michael-alpha-unix)]

i also think that my panic happenes more often in idle.

It never happens when playing a video with vlc (and have vlc opened after the endig of the video) but very often in idle mode (terminator opened, libreoffice opened)

i always was connected to a wifi when the panic occures, never happened when not connected with wifi (but wifi enabled) (sometimes i saw the wifi-module in the panic-message (see my pictures))

i never get a panic on shutdown.

I hope this informations are usefull for someone

[Yann Benigot (yann-benigot)]

Happened three times in a row while ssh-ing to another computer. I then started the netbook from the SD Card with a live ubuntu system and no crash in four hours while doing a "while true; do sleep 1 && cat some-random-file; done" through ssh.
Knowing that, we may suppose that the SSD may have something to do with these crashes. I have the 16GB SSD version.
I also ran memtest86 ; it did not find any problem.

[Michael Basse (michael-alpha-unix)]

still no kernel-panic with 3.1rc9

[Joseph Salisbury (jsalisbury)]

@Yann

Would it be possible for you to try teh 3.1rc9 kernel as well?

[Andrea Esuli (andrea-esuli)]

I have found that when I run only on battery I have kernel panics in few minutes (2-10) from start. I have I unplugged the battery and now I run only on the AC adapter, and I haven't got any panic till now (about three hours). @Yann @Michael can you try if this hypothesis is right?

[Michael Basse (michael-alpha-unix)]

Hi Andrea,
i also have kernel-panics when the ac adapter is plugged it. I am not sure but i think i have more panics when using battery only but definitly i also have panics when ac-adapter is plugged in.

btw, still no kernel-panics with 3.1.0-0301rc9-generic. Just with all tested version from 3.0.0-12-x-generic

[Andrea Esuli (andrea-esuli)]

I forgor to mention that I have removed battery while the ac is plugged. Can you check this setup?

[Tomáš (tom-redhat-bugs-1)]

Hello,

I'm seeing the rt2500pci powersave-related panic reproducibly (the kernel panics a few seconds after enabling powersave). I've got a core via kdump on 2.6.40.6 (can provide the whole 2 GiB file if anyone's interested). I'm attaching the panic log, but the most important part is:

[ 853.871216] [<ffffffff810620a6>] msleep+0x1b/0x22
[ 853.871230] [<ffffffffa0314423>] rt2500pci_set_device_state+0x840/0x8a0 [rt2500pci]
[ 853.871241] [<ffffffffa0314ac7>] rt2500pci_config+0x297/0x2bd [rt2500pci]
[ 853.871257] [<ffffffffa02c319e>] rt2x00lib_config+0x144/0x22a [rt2x00lib]
[ 853.871269] [<ffffffffa02c1355>] rt2x00lib_rxdone+0x2a9/0x37b [rt2x00lib]
[ 853.871280] [<ffffffffa02d455e>] rt2x00pci_rxdone+0x76/0x8b [rt2x00pci]
[ 853.871290] [<ffffffffa03144b3>] rt2500pci_rxdone_tasklet+0x14/0x59 [rt2500pci]

Apparently, rt2500pci_set_device_state check whether the requested state change has succeeded in a loop and doesn't care that it could be called from rt2500pci_rxdone_tasklet (after receiving a beacon the tasklet orders to return to powersaving mode if there's no traffic queued):

rt2500pci.c:1212

        /*
         * Device is not guaranteed to be in the requested state yet.
         * We must wait until the register indicates that the
         * device has entered the correct state.
         */
        for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
                rt2x00pci_register_read(rt2x00dev, PWRCSR1, &reg2);
                bbp_state = rt2x00_get_field32(reg2, PWRCSR1_BBP_CURR_STATE);
                rf_state = rt2x00_get_field32(reg2, PWRCSR1_RF_CURR_STATE);
                if (bbp_state == state && rf_state == state)
                        return 0;
                rt2x00pci_register_write(rt2x00dev, PWRCSR1, reg);
                msleep(10);
        }

So powersave works only for people with devices fast enough to switch state instantly (before the CPU gets to the inner if check). Everyone else steps on the msleep and explodes in softirq context.

"Quick fix": Either drop the msleep() and let it spin a bit or check whether in interrupt and completely skip the loop in that case.

Tip: Since rc.local is sooo pre-systemd era (and putting powersave off there is not reliable, too, since the wifi could come up and panic before rc.local is executed), the best is to do add a simple rule to /etc/udev/rules.d to have powersaving off from the very start:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="rt2500pci", KERNEL=="wlan*", RUN="/sbin/iw $name set power_save off"

[Tomáš (tom-redhat-bugs-1)]

Created attachment 528933
Panic log including subsequent fallout

[Michael Basse (michael-alpha-unix)]

the interesting part would be if you have kernel-panics when using ac-adapter and have the battery plugged in. I can not test your suggested setup before the weekend.

[John (john-redhat-bugs)]

Ivo, any thoughts on comment 19?

[James (james-redhat-bugs)]

I think I'm encountering this in F16 on a laptop, running off the Live USB with kernel 3.1.0-0.rc6.git0.3.fc16.i686. Connect to a wireless network, enter the password, and it panics. Disabling power management via iw seems to do the trick... I'll attach the machine's particulars (backtraces look similar) if anyone thinks they'll be of use.

[Michael Basse (michael-alpha-unix)]

Kernelpanic with 3.1.0-0301rc9-generic while watching a video on youtube on eeepc 901.

Picture from the panic is added

[Michael Basse (michael-alpha-unix)]

so i guess its useless to make any further tests if it is happening with 3.0.0-12 and 3.1-rc9. I guess we should discuss about a usefull debugging from the testers here to give usefull input.

I cant find anything in syslog or kern.log

are there some ways to run the kernel in a higher verbose-mode? so that there are maybe some usefull infos in the logs?

[Ian Corne (icorne)]

I've just had it happen on 3.0.0-9 (after finding 3.0.0-12 unusable)

Will upload picture asap

[Joseph Salisbury (jsalisbury)]

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report at bugzilla.kernel.org? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report.

[Michael Basse (michael-alpha-unix)]

There is no bugzilla.kernel.org anymore. Some kernel-hackers told me to use the "linux kernel mailinglist" so i will go that way. When finished i will post the reference here

[JosephWheatley (skinnyjim)]

Keeps getting me too on my ASUS Eee PC 1000h

Had it three times this morning already - worse than previously.

uname -a

Linux james-1000H 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:50:42 UTC 2011 i686 i686 i386 GNU/Linux

[JosephWheatley (skinnyjim)]

And again while I was trying to upload the previous comment,

This output mentions the kernel and some hardware.

I don't know if this is helpful but am posting it just to show the problem is real.

[Ivo (ivo-redhat-bugs)]

(In reply to comment #21)
> Ivo, any thoughts on comment 19?

Sounds like a very valid point, I guess it was introduced when we were moving the interrupts from process to IRQ context back and forth.. :(

[Stanislaw (stanislaw-redhat-bugs)]

Helmut works (or plan to work) on that:
http://marc.info/?l=linux-wireless&m=131702522217100&w=2

[Gertjan (gertjan-redhat-bugs)]

Created attachment 531046
Proposed patch

Please check if the attached patch fixes the issue for you.

[Dirk (dirk-redhat-bugs)]

(In reply to comment #25)
> Created attachment 531046 [details]
> Proposed patch
>
> Please check if the attached patch fixes the issue for you.

How would I do that?

[Stanislaw (stanislaw-redhat-bugs)]

I'll prepare kernel build with the patch.

[Stanislaw (stanislaw-redhat-bugs)]

Here is kernel build with patch from comment 25, please test when it finish to compile:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3478051

[Ian (ian-redhat-bugs)]

Thanks for that, ran out of space when trying to do my own kernel build (9GB not enough!)

kernel-2.6.40.6-0.fc15.x86_64
(Current stable I think) has this crash for me when not using set power_save off.

kernel-2.6.40.8-3.bz731672.fc15.x86_64
Hasn't crashed yet at ~ 1/2hour uptime.

[Tomáš (tom-redhat-bugs-1)]

(In reply to comment #25)
> Created attachment 531046 [details]
> Proposed patch
>
> Please check if the attached patch fixes the issue for you.

Indeed it does, thanks.
kernel-2.6.40.8-2.fc15.x86_64 - crashes within a few seconds after enabling powersave

kernel-2.6.40.8-2.rhbz731672.fc15.x86_64 - can't reproduce the crash, power management works as expected now (judging from the "STA will sleep" flag being set in transmitted frames)

[John (john-redhat-bugs)]

So, when will we see this patch upstream? :-)

[Gertjan (gertjan-redhat-bugs)]

As soon as I have returned from my travels I will submit the patch upstream (sorry travels came in between that) ;-)

[Gareth (gareth-redhat-bugs-1)]

I'm currently updating to F16, but I'll give the patch a test when I get a chance (if it isn't already included by then!).

[Ian (ian-redhat-bugs)]

I'm not sure this will require a new bug, but while I no longer see this crash I do get disconnected or very slow connection to the AP. NetworkManager keeps asking me for a password, using the iw $name set power_save off seems to prevent it. Could be a separate bug which has been uncovered by fixing the power management?

[Tomáš (tom-redhat-bugs-1)]

(In reply to comment #34)
> I'm not sure this will require a new bug, but while I no longer see this crash
> I do get disconnected or very slow connection to the AP. NetworkManager keeps
> asking me for a password, using the iw $name set power_save off seems to
> prevent it. Could be a separate bug which has been uncovered by fixing the
> power management?

Yes, there probably is some powersave-related bug in there somewhere (I've hit it twice over the last two weeks with PS enabled) - basically the device locks up and requires resetting via modprobe -r rt2500pci; modprobe rt2500pci.

Anyways, that's nowhere near as severe as this panic so I'll recommend opening a separate bug for that (otherwise I'll do that as soon as the patch for this one is applied to Fedora kernel or upstream so that the bug dependencies don't get too confusing).

[Ian (ian-redhat-bugs)]

Thanks, just wanted to make sure it wasn't likely to be directly related. https://bugzilla.redhat.com/show_bug.cgi?id=753648

[Tomáš (tom-redhat-bugs-1)]

Confirming this is fixed on F15 by kernel-2.6.41.4-1.fc15.x86_64 (now in testing).
Fixed upstream by commit ed66ba472a742cd8df37d7072804b2111cdb1014 (starting with 3.1.3).

[bob (bob-redhat-bugs-1)]

*** Bug 728186 has been marked as a duplicate of this bug. ***

[bob (bob-redhat-bugs-1)]

Confirming fixed in 2.6.41.4-1.fc15.i686.PAE also for bug 728186 (so it really was a duplicate even though symptoms were somewhat different).

[Gareth (gareth-redhat-bugs-1)]

Confirming that this is fixed in F16 by the equivalent kernel update, but I'm also seeing the disconnecting behaviour described by Ian above.