Bug 485165

Blinking caps-lock is a kernel panic; can you paste in the output of "/sbin/lspci" so we can find out what wireless hardware you have?  Are there any messages in /var/log/messages after reboot that look like a kernel panic log?

As Dan says, those messages would be good to see.  Another possibility might be to try to recreate the problem from a text console by stopping NetworkManager and using ifconfig/iwconfig/dhcp.

There are no message in /var/log/messages that indicate a panic or really anything other than boot up. I'll attempt again tomorrow and post any results.


http://www.smolts.org/show?uuid=pub_9ab9fe28-a123-4299-91c7-12c51241f644

/sbin/lspci

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
01:00.0 VGA compatible controller: nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1)
03:01.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 21)
03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02)
09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express (rev 02)
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

Created attachment 331782 [details]
dmidecode output

I can confirm a similar^Widentical problem. It does depend on where I am trying to connect. For example, at home I have WPA2-PSK, and the only networks in my neighbourhood are either WEP or WPA{,2}-PSK (or open). I never experience any problems there.

At the office, we have two WPA2-Enterprise networks and a WPA2-PSK network. Even if I connect to the WPA2-PSK network, my wireless led blinks with a higher frequency then normal and after a few minutes I have a hard hang (caps/num blinking).

http://www.smolts.org/client/show/?uuid=pub_330e1ad8-96d8-4543-a58d-585a4fd3842e

Is it possible that NM (or perhaps more likely, the iwl3945 driver) gets some traffic from one of the other networks that it doesn't like?

The only other thing that's different in the set-up between home and office is that we have multiple base-stations for each SSID in the office environment. Could that be a factor?

I usually have nothing in my syslog, but this morning I found:

Mar  3 09:17:44 cluestix NetworkManager: <info>  (wlan0): supplicant connection state:  completed -> associating
Mar  3 09:17:45 cluestix kernel: BUG: sleeping function called from invalid context at kernel/mutex.c:88
Mar  3 09:17:45 cluestix kernel: in_atomic():1, irqs_disabled():0
Mar  3 09:17:45 cluestix kernel: Pid: 0, comm: swapper Tainted: P          2.6.27.15-170.2.24.fc10.i686 #1
Mar  3 09:17:45 cluestix kernel: [<c0427e7d>] __might_sleep+0xc6/0xcb
Mar  3 09:17:45 cluestix kernel: [<c06a9a05>] mutex_lock+0x18/0x2d
Mar  3 09:17:45 cluestix kernel: [<f892bd9a>] iwl3945_mac_conf_tx+0x19e/0x20c [iwl3945]
Mar  3 09:17:45 cluestix kernel: [<f8900615>] ieee80211_sta_wmm_params+0x175/0x1a4 [mac80211]
Mar  3 09:17:45 cluestix kernel: [<f89024fe>] ieee80211_rx_mgmt_beacon+0xe8/0x1de [mac80211]
Mar  3 09:17:45 cluestix kernel: [<c062def6>] ? __kfree_skb+0x63/0x66
Mar  3 09:17:45 cluestix kernel: [<f8902653>] ieee80211_sta_rx_scan+0x5f/0x78 [mac80211]
Mar  3 09:17:45 cluestix kernel: [<f8909087>] ieee80211_invoke_rx_handlers+0x4d/0x1475 [mac80211]
Mar  3 09:17:45 cluestix kernel: [<c0424296>] ? enqueue_entity+0x203/0x20b
Mar  3 09:17:45 cluestix kernel: [<c06aa9bb>] ? _spin_unlock_irqrestore+0x22/0x38
Mar  3 09:17:45 cluestix kernel: [<c0431f00>] ? __tasklet_schedule+0x66/0x7d
Mar  3 09:17:45 cluestix kernel: [<f8908b02>] ? ieee80211_rx_irqsafe+0x4d/0x52 [mac80211]
Mar  3 09:17:45 cluestix kernel: [<f8934201>] ? iwl3945_pass_packet_to_mac80211+0x272/0x284 [iwl3945]
Mar  3 09:17:45 cluestix kernel: [<f8934a25>] ? iwl3945_rx_reply_rx+0x812/0x81a [iwl3945]
Mar  3 09:17:45 cluestix kernel: [<f890a96b>] __ieee80211_rx_handle_packet+0x4bc/0x4ce [mac80211]
Mar  3 09:17:45 cluestix kernel: [<f890afdc>] __ieee80211_rx+0x464/0x4b4 [mac80211]
Mar  3 09:17:45 cluestix kernel: [<f88fcc88>] ieee80211_tasklet_handler+0x62/0xda [mac80211]
Mar  3 09:17:45 cluestix kernel: [<c04320d9>] tasklet_action+0x7f/0xea
Mar  3 09:17:45 cluestix kernel: [<c0432707>] __do_softirq+0x84/0x109
Mar  3 09:17:45 cluestix kernel: [<c0432683>] ? __do_softirq+0x0/0x109
Mar  3 09:17:45 cluestix kernel: [<c0406f1c>] do_softirq+0x77/0xdb
Mar  3 09:17:45 cluestix kernel: [<c04661af>] ? handle_fasteoi_irq+0x0/0xc0
Mar  3 09:17:45 cluestix kernel: [<c043236e>] irq_exit+0x44/0x83
Mar  3 09:17:45 cluestix kernel: [<c0406e8e>] do_IRQ+0xe7/0xfe
Mar  3 09:17:45 cluestix kernel: [<c0405668>] common_interrupt+0x28/0x30
Mar  3 09:17:45 cluestix kernel: [<c0567972>] ? acpi_idle_enter_bm+0x27d/0x2cc
Mar  3 09:17:45 cluestix kernel: [<c0617526>] cpuidle_idle_call+0x60/0x92
Mar  3 09:17:45 cluestix kernel: [<c0403c61>] cpu_idle+0x101/0x134
Mar  3 09:17:45 cluestix kernel: [<c06a65cb>] start_secondary+0x197/0x19f
Mar  3 09:17:45 cluestix kernel: =======================
Mar  3 09:17:45 cluestix kernel: BUG: scheduling while atomic: swapper/0/0x00000100
Mar  3 09:17:45 cluestix kernel: Modules linked in: aes_i586 aes_generic ipt_MASQUERADE iptable_nat nf_nat bridge stp sunrpc ip6t_REJECT nf_conn
track_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq fuse vfat fat dm_multipath kvm_intel kvm uinput snd_hda_intel snd_seq_d
ummy snd_seq_oss snd_seq_midi_event snd_seq snd_usb_audio snd_pcm_oss snd_mixer_oss snd_usb_lib snd_pcm b44 snd_rawmidi snd_timer snd_page_alloc
 arc4 snd_seq_device snd_hwdep ecb crypto_blkcipher firewire_ohci ricoh_mmc snd sdhci_pci soundcore firewire_core crc_itu_t ssb mii nvidia(P) iw
l3945 rfkill mac80211 iTCO_wdt iTCO_vendor_support sdhci mmc_core btusb bluetooth video uvcvideo compat_ioctl32 videodev v4l1_compat cfg80211 i2
c_i801 i2c_core output joydev dcdbas wmi ata_generic pata_acpi [last unloaded: microcode]

Not sure if this is relevant though.

(And yes, I have a tainted nvidia module :-(, but even with the "nv" and "nouveau" drivers, I still experience these hard hangs.)

My output from /sbin/lspci:

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
01:00.0 VGA compatible controller: nVidia Corporation G72M [GeForce Go 7400] (rev a1)
03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
03:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19)
03:01.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a)
03:01.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05)
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

I just saw bug #453298 (from Fedora 9, dated 2008-06-29, status still NEW), which mentions similar symptoms, only for a Broadcom chip. Could this point to something in the ieee80211 stack?

Can you replicate this problem on a 2.6.29-based kernel?

   http://koji.fedoraproject.org/koji/buildinfo?buildID=92572

Thanks, I just installed the 2.6.29-0.53.rc7.fc10.i686 kernel. Boots OK (although nouveau is now *really* broken, but that's another story). I'm at home right now, and my laptoop associates fine (so no regression there). I'll test at the office in the morning.

Ok, I've been in the office for over four hours and so far, no crash. I do seem to have issues connecting to the WPA-PSK network here, but the WPA-Enterprise network does work, so I'm guessing it's a local issue.

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

This happened to me probably five times in the course of an hour and a half today on my laptop.  I think it was either the wireless connection, or a faulty power connection that was causing it (the power was coming on and off from the source).  Same symptom of the caps lock light blinking.

kernel-2.6.27.19-170.2.35.fc10.i686

00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03)                                                            
00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port (rev 03)                                                             
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)                                                            
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)                                                            
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)                                                           
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)                                                                 
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)                                                                    
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)                                                                    
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03)                                                                    
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)                                                                    
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)                                                            
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)                                                            
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)                                                            
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)                                                           
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)       
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)                                                                  
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation GeForce 8400M G (rev a1)
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12)
03:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCIController (rev 02)
04:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
07:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05)
07:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22)
07:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 12)
07:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter(rev ff)

It is difficult to debug a hard lock-up like that.  Sometimes a clue can be found by using netconsole to get a trace.  You will need a wired connection to another linux box, preferrably with a private network between the boxes over that link.

Edit /etc/sysconfig/netconsole and add an appropriate SYSLOGADDR= line for the other end of the link.  On the other box, run "nc -lu 514".  Make sure that iptables is not blocking that port (e.g. "service iptables stop").

On the crashing box, execute "service netconsole start".  Now do whatever it takes to trigger the crash.  Once it happens, take the output from the "nc" command on the other box and attach it here...thanks!

I've been hitting this problem on a Lenovo N3000: caps-lock led blinking. Kernel is kernel-2.6.27.21-170.2.56.fc10.i686 (though I have been seeing it with earlier 2.6.27 kernels as well); wireless is iwl3945.

I get hangs within an hour or two on my home network: two access points, one offering only WPA2-PSK; the other offering both WPA2-PSK (AES) and WPA-PSK (TKIP).

Crashes during successive software update sessions caused yum-complete-transaction to get very confused and blow away a number of necessary packages, so after re-installation I will try setting up a private wired nework and see if I can capture the information John is requesting.

Created attachment 340613 [details]
Kernel crash log

I've added a kernel crash log obtained from the 'nc' network console set up on a separate private hard-wired network.  The crash seemed to happen when the client was attempting to switch APs (I had just powered-on a closer AP to the client) while significant network traffic was happening (a large iso download)

I have just got an identical stack trace (iwl3945_rx_reply_rx leading to a call to ieee80211_rx_irqsafe ending in "BUG: sleeping function called from invalid context at kernel/mutex.c:88".  This time I was not playing games with AP enabling/disabling, os it is not clear if an AP switch was involved in this case.

Please let me know of any other information you need to analyse this crash.

I can also reproduce this failure on the original fc10 release kernel ( 2.6.27.5-117.fc10.i686 ).

I have not yet been able to reproduce it on the latest 2.6.29 development kernel ( kernel-2.6.29.1-42.fc10.i686 ); will continue testing with this, but it looks as if it is fixed in 2.6.29 as others have reported.

this bug present in 2.6.29.4-167.fc11.x86_64 :(

I can confirm that this bug is not related to a specific wireless chipset. My computer experiences exactly the same symptoms as described above (machine hangs hard with CapsLock and ScrollLock lights blinking), with both the internal wireless card and an external USB card (Linksys - Compact Wireless G-USB adapter). Before testing with the USB card I switched off the internal wireless card in the appropriate BIOS menu so that it wouldn't be visible to the operating system.

My PC crashes when using both NetworkManager and manual network interface configuration.

My PC is a DELL D630 and its internal wireless card is the following:

0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

I am using the following kernel version:

2.6.27.24-170.2.68.fc10.i686

The bug was also present in the previous F10 kernel:

2.6.27.21-170.2.56.fc10.i686

Apparently, the PC crashes more often when using the Cisco VPN Client.

The tests were performed using 128 bit WEP encryption with a Belkin router (F5D7230-4) in a bridged configuration with another router of the same model.

This is the output of the lspci command:

/sbin/lspci 
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02)
00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02)
03:01.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 21)
03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02)
09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5755M Gigabit Ethernet PCI Express (rev 02)
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

I apologize for my english level.

I'm seeing this on F-11 with kernel-PAE-2.6.29.5-191.fc11.i686. On modprobe -r iwl3945, the system hangs (not always, but most of the time) and the two lights are blinking.

I believe I finally found what the problem was. The BIOS of my PC (Dell D630) allows the user to hide the two cores of the CPU and make it look like a single processor to the operating system. After doing this, the problem disappeared. Apparently, there seems to be a negative interaction between the Cisco VPN Client and the SMP feature because, as I mentioned above, the problem is not related to a specific wireless chip. Before making this change, the PC always crashed as soon as I tried to connect to a Citrix server over a Cisco VPN Client connection or produced a large volume of traffic over that same VPN connection.

This still happens with F11 on a Thinkpad T41 and my X40 - not on every shutdown but at least every 10 shutdowns. Completely unresponsive, black screen, blinking capslock. The only solution is to hold power till it manually shuts off.

Linux blackbox 2.6.29.5-191.fc11.i586 #1 SMP Tue Jun 16 23:11:39 EDT 2009 i686 i686 i386 GNU/Linux
Fedora 11 latest, including updates-testing (dev machine)

The above dual-core/citrix stuff is not the cause as I have none of those things. This seems like a nasty kernel bug.

Closing on basis of comment 20...

Not sure that was the right course of action. I don't run Cisco VPN, for instance, but had the same problem. Was there a change in the kernel that actually fixed this?

Having opened the bug, I would like to provide some feedback considering it's been closed. Not really sure if it's fixed, but it's closed.

I have been running in the exact scenario described initially. I have the network manager connected to both the wired and wireless networks and all has been well for the last 4 hours. (no hang).

I've added a GSM phone teather network as well and it survived it and the disconnecting of the device and destruction of the network interface.

I haven't had the opportunity to test this as thoroughly as I would like, as I haven't been in the same situations. (roaming from cell to cell on the wireless network).

I will provide feedback if it begins to lock up again.

I have upgraded to FedXI and the 2.6.29.5-191.fc11.i586 kernel.

The last occurance of a lock up was about 3 weeks ago (after upgrading to fed 11), so if something in the kernel, network manager ..etc has changed that fixed this problem, we're good, otherwise it's just going to be re-opened in Fedora 11.

Thanks,

G...

Oh, and also closing this ticket on the basis of comment #20 is minimalistic at best. The fact that there is a "fix" based on bios changes to make a core 2 duo be a core is not a fix, it's a problem with several other implications.

Not only that, I don't use the Cisco VPN any more, I use the Juniper network connect and it still happens with that VPN, it also happens without any VPN connected. This is not a VPN issue, that was merely put out there because of the nature of the corporate network.

If you would like to close this bug because Fedora 11 is out and the bug should be opened there, then fine.. promote this to a fedora 11 bug considering nothing has been done to fix or even think about this issue, it's just closing our eyes and hoping that it works better now or turning 2 cores into 1 core so Cisco works better.. which wasn't the problem in the first place...

stepping down from soap box and taking back exactly .01 cents from the .02 I dropped. (rough economy)