interesting log.

* selinux denials.  If you've booted at all with selinux=0 at some point, you'll want to run touch /.autorelabel and reboot.  It'll take a while, but you should then get all the correct file contexts.  If you still see the selinux denial messages, please file bugs on them, as they shouldn't be there.

* lots of packet loss. guess that's the nature of whatever your ppp link connects to

* finally a warning from the wireless stack.

I don't see an immediate correlation between the wireless & the ppp session, so it could be coincidence, but I'll leave it to John for deeper analysis.

Hmm.. I had/and still have SELinux set on permissive mode, so should this still be a problem?

Also, I think we should rule out the chance of it being coincidence, as I use my laptop a lot, and the panics only happen at my evil school where we use PPTP :(

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

What driver is in use here?  Can we have the output from lsmod and/or lspci?

For me it's iwl3945.

$ lspci -v
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
	Subsystem: Intel Corporation Device 1020
	Flags: bus master, fast devsel, latency 0, IRQ 17
	Memory at fe8ff000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: iwl3945
	Kernel modules: iwl3945

iwl3945 here too..

$ sudo lspci -v
05:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
	Subsystem: Intel Corporation PRO/Wireless 3945ABG Network Connection
	Flags: fast devsel, IRQ 18
	Memory at f0200000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [c8] Power Management version 2
	Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable-
	Capabilities: [e0] Express Legacy Endpoint, MSI 00
	Capabilities: [100] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSVoil-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSVoil-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		AERCap:	First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn-
	Capabilities: [140] Device Serial Number 50-6f-43-ff-ff-bf-1c-00
	Kernel driver in use: iwl3945
	Kernel modules: iwl3945


$ lsmod (when not using pptp, and thus the mppe module is not shown)
Module                  Size  Used by
nls_utf8               10240  1 
fuse                   60992  2 
bridge                 56224  0 
stp                    10756  1 bridge
bnep                   22016  2 
sco                    19204  2 
l2cap                  28544  3 bnep
bluetooth              60068  5 bnep,sco,l2cap
sunrpc                191208  3 
ipv6                  287272  36 
cpufreq_ondemand       15504  1 
acpi_cpufreq           17552  2 
freq_table             12928  2 cpufreq_ondemand,acpi_cpufreq
dm_multipath           23704  0 
uinput                 16128  0 
arc4                   10240  2 
i2c_i801               17820  0 
ecb                    11264  2 
crypto_blkcipher       24196  1 ecb
wmi                    14912  0 
snd_hda_intel         476576  3 
i2c_core               29216  1 i2c_i801
iwl3945               151780  0 
video                  28316  0 
lirc_ite8709           15364  0 
r8169                  40964  0 
serio_raw              14084  0 
lirc_dev               20408  1 lirc_ite8709
mii                    13056  1 r8169
iTCO_wdt               20176  0 
iTCO_vendor_support    11652  1 iTCO_wdt
joydev                 19328  0 
snd_seq_dummy          11396  0 
snd_pcsp               18940  1 
snd_seq_oss            39104  0 
snd_seq_midi_event     14848  1 snd_seq_oss
snd_seq                61968  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
output                 11264  1 video
snd_seq_device         15380  3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss            52224  0 
snd_mixer_oss          23168  1 snd_pcm_oss
snd_pcm                85512  3 snd_hda_intel,snd_pcsp,snd_pcm_oss
battery                21000  0 
ac                     13320  0 
snd_timer              30352  2 snd_seq,snd_pcm
snd_page_alloc         16656  2 snd_hda_intel,snd_pcm
snd_hwdep              16392  1 snd_hda_intel
rfkill                 17316  2 iwl3945
snd                    68984  19 snd_hda_intel,snd_seq_dummy,snd_pcsp,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_hwdep
mac80211              213872  1 iwl3945
soundcore              14992  1 snd
cfg80211               32400  2 iwl3945,mac80211

I'm seeing the same WARNING on iwl4965 hardware with Fedora 10 kernel-2.6.27.5-117.fc10.x86_64.  See:

http://kerneloops.org/raw.php?rawid=103470&msgid=

and this for the complete list:

http://kerneloops.org/guilty.php?guilty=rs_get_rate&version=2.6.27-release&start=1802240&end=1835007&class=warn

Interestingly, I am *not* seeing this problem with Fedora 9 kernel-2.6.27.5-37.fc9.x86_64 on the same hardware.

More of the same warnings:

http://fpaste.org/paste/578


Also, I've taken out parts of my /var/log/messages that is logged just before the panics happen. Dunno if they're useful:

http://fpaste.org/paste/579

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

Other than the annoying message, is there a functional problem?  That is, are you still able to get to Google or whatnot?

Yes, there is a functional problem.  It seems to disconnect from the wireless network when the kernel prints this message.  I've noticed WPA2 Enterprise disconnections with this kernel vs. no problems with the F9 one on the same hardware.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Issue remains in -132 and -134 F10 kernels.

Issue happened again in 2.6.27.9-152.rc2.fc10.x86_64.  I had been running older firmware, and I've now updated to:

iwl4965-firmware-228.57.2.23-2.noarch

as suggested in bug #457154

and

kernel-2.6.27.9-157.fc10.x86_64

which has this fix mentioned:

* Mon Dec 15 2008 John W. Linville <linville> 2.6.27.9-157
- iwlagn: fix RX skb alignment

Hopefully between these two updates, we'll have some improvement.

iwl4965-firmware-228.57.2.23-2.noarch
kernel-2.6.27.9-157.fc10.x86_64

No improvement with the above packages.  I still see WARNING: at include/../net/mac80211/rate.h:152 rs_get_rate+0x254/0x28x [iwlagn]() (Not tainted), along with loss of wireless connectivity.

I'm also seeing this on a Thinkpad X61s w/iwl3945, though I'm not using PPTP, and i686 not x86_64. I installed F10 before Christmas, and the warnings seem more frequent since getting a large batch of updates this week.

kernel-2.6.27.9-159.fc10.i686
iwl3945-firmware-15.28.2.8-2.noarch

The warning is accompanied by loss of network, and happens frequently though not at consistent intervals - sometimes after 2-3 minutes, sometimes it'll go ok for 20 minutes or so.

Some examples sent by kerneloops:
http://www.kerneloops.org/submitresult.php?number=169101
http://www.kerneloops.org/submitresult.php?number=170421
etc.

I note that all of the versions reported at kerneloops seem to be for .fc10 or .fc9:
http://kerneloops.org/search.php?filter=2.6.27.9&search=rs_get_rate
(though do other distros ship/enable kerneloops?)

Having just returned to my laptop after a few minutes I found it locked hard (flashing Caps Lock). Could be a co-incidence, but it's usually very stable.

Nothing obviously useful in /var/log/messages, the last entries were:
Jan  7 18:13:09 mopp NetworkManager: <info>  (wlan0): supplicant connection state:  completed -> associating
Jan  7 18:13:09 mopp NetworkManager: <info>  (wlan0): supplicant connection state:  associating -> associated
Jan  7 18:13:09 mopp NetworkManager: <info>  (wlan0): supplicant connection state:  associated -> complete

(and before that a log full of kernel oops, obviously, but nothing immediately before the lockup)

I've tried running with kernel-2.6.27.5-117.fc10.i686 and still experience problems, so I guess this is an F10 problem, not just limited to the latest kernels. I can't see an earlier iwl3945-firmware to revert to.

I hesitate to mention this as it's rather circumstantial evidence, but it seems that the problem occurs more when the network is "busy". e.g. this afternoon in the meeting room in an office with many laptops on wireless, looking back at /var/log/messages over a single hour I count 9 oopses.

This evening, in my room, very likely much lower density of wireless users, and I've been connected for 2 hours without issue.

Now this isn't a "native" network for me, and while it's part of the same system (same SSID etc.) I don't know that the AP hardware is the same. (But if it's not, perhaps the problem is only exhibited with some AP?)

This also aligns with my experiences over and after Christmas: at home (quiet network) I didn't see any problems, but on return to work (busy network) lots of oopses. I *know* the AP hardware isn't the same in this case, mind.

If there's anything I can do, any debug I can collect, to help get to the bottom of this, please let me know. Obviously 10 ooopses and hour - loosing network each time - makes F10 borderline unusable on wireless.

Similarly any hints, even if they're "known problem, but won't be fixed any time soon", would be appreciated so I can plan to work around it, somehow.

(FWIW, F8 and F9 ran fine on this hardware without oopsing)

See this upstream bug report with patch that appears to fix the issue:

http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1822

Thanks for the info...FWIW, Intel hasn't pushed that upstream yet.

Created attachment 329127 [details]
iwlwifi-intel-bug-1822.patch

Patch modified for current F10 kernels...

Current = rawhide/devel?

Trying to apply to kernel-2.6.27.9-159.fc10 fails:

$ patch --verbose -F1 -p1 --dry-run < ../../../SOURCES/iwlwifi-intel-bug-1822.patch 
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -up linux-2.6.28.noarch/drivers/net/wireless/iwlwifi/iwl-3945-rs.c.orig linux-2.6.28.noarch/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
|--- linux-2.6.28.noarch/drivers/net/wireless/iwlwifi/iwl-3945-rs.c.orig	2009-01-15 13:30:23.000000000 -0500
|+++ linux-2.6.28.noarch/drivers/net/wireless/iwlwifi/iwl-3945-rs.c	2009-01-15 13:39:16.000000000 -0500
--------------------------
Patching file drivers/net/wireless/iwlwifi/iwl-3945-rs.c using Plan A...
Hunk #1 FAILED at 665.
1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/iwlwifi/iwl-3945-rs.c.rej
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -up linux-2.6.28.noarch/drivers/net/wireless/iwlwifi/iwl-agn-rs.c.orig linux-2.6.28.noarch/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
|--- linux-2.6.28.noarch/drivers/net/wireless/iwlwifi/iwl-agn-rs.c.orig	2009-01-15 13:30:23.000000000 -0500
|+++ linux-2.6.28.noarch/drivers/net/wireless/iwlwifi/iwl-agn-rs.c	2009-01-15 13:37:37.000000000 -0500
--------------------------
Patching file drivers/net/wireless/iwlwifi/iwl-agn-rs.c using Plan A...
Hunk #1 FAILED at 775.
Hunk #2 succeeded at 798 (offset 6 lines).
Hunk #3 FAILED at 817.
Hunk #4 FAILED at 2123.
Hunk #5 FAILED at 2143.
4 out of 5 hunks FAILED -- saving rejects to file drivers/net/wireless/iwlwifi/iwl-agn-rs.c.rej
done

(applying to the rpmbuild prepared source tree here to get patch output, but previously following http://fedoraproject.org/wiki/Docs/CustomKernel )

It is for 2.6.28-based kernels.  Unfortunately, the build was broken yesterday.  Hopefully this one will succeed:

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

When/if it does, please try to recreate the issue with those kernels?

That one seems to have built -- please test...thanks!

I guess there's something I need to change (mkinitrd? - couldn't see any newer versions?) to get kernel-2.6.28.1-9.rc2.fc10.i686 to boot? I enter my LUKS passphrase, but then booting halts with "error mounting /dev/root on /sysroot as ext3: no such file or directory".

Or if not, and it's a bug with that kernel, let me know and I'll file something.

I'll test the iwlwifi fix when I can boot with the kernel ;)

Hmmm...beats me.  That sounds more like the initrd didn't get recreated properly.  That happens from time to time.  Could I persuade you to try installing that kernel once more?  Sometimes that resolves such issues.

No luck, I'm afraid.

Tried:
mkinitrd -v -f initrd-2.6.28.1-9.rc2.fc10.i686.img 2.6.28.1-9.rc2.fc10.i686

also (via bug #471093, bug #466607):
mkinitrd -v --with=scsi_wait_scan -f initrd-2.6.28.1-9.rc2.fc10.i686.img 2.6.28.1-9.rc2.fc10.i686

and tried scsi_mod.scan=sync in grub.conf, though the above bugs suggest this shouldn't be expected to work (scsi_mod no longer a module?).

I've submitted bug #480761, but if you've any other ideas so I can test this kernel, let me know.

(In reply to comment #23)
> It is for 2.6.28-based kernels.  Unfortunately, the build was broken yesterday.
>  Hopefully this one will succeed:
> 
>    http://koji.fedoraproject.org/koji/buildinfo?buildID=78849
> 
> When/if it does, please try to recreate the issue with those kernels?


This kernel fixes the issue for me completely.  I've seen no oopses or panics since using 2.6.28.1-9.rc2.fc10.x86_64.

I'm going to go ahead and close on the basis of comment 28.  Please reopen if the problem continues with 2.6.28.1-9.rc2.fc10 or later kernels.

Back on one of the previously problematic networks and 2.6.28.1-9.rc2.fc10.i686 fixes the issue for me as well - thanks!

When will this fix be pushed through the update system? I am running a fully updated stock F10 system and am experiencing frequent oopses and occasional hard lockups in the iwl3945 driver.

bugzilla.redhat.com/page.cgi?id=fields.html says that "CLOSED, CURRENTRELEASE" means "the problem described has been fixed and only ever appeared in unsupported or unreleased products" which doesn't seem to be correct.

Thanks for the link -- I'm not sure how accurate it is w.r.t. actual usage, but whatever. :-)

As for when it will come through the update system, you may have to wait a bit -- there is some ongoing issue with 2.6.28 and later kernels on F10.  Hopefully that will get resolved before too long.

Can this fix be applied any sooner than 2.6.28, since it is a crasher for fairly common hardware? I notice that there are still 2.6.27 builds in the update pipeline on Koji.

Also, sorry to be a bug status nerd, but I've since come across http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow. The kind folks in #fedora-bugzappers tell me that means this one should actually be OPEN,MODIFIED (since it's not in the testing repo, yet).

OK, bug status nerds...who is going to make sure this disappears from my sight when the update is actually pushed?

Nevermind, looks like it is already off My Bugzilla Front Page...

The continuing 2.6.27 stream seems to be forked from the normal process.  Maybe we can persuade cebbert or kylem to ask for that patch to be included.

This bug affects 3965 and 4965.  The patch fixes the problem completely for me.

The patched kernel also fixes the problem for me (iwl3945).

This is still the #1 issue on the frontpage at kerneloops.org right now (~1300 reported warnings this week, mostly from latest fc10 kernel), so pushing a timely update is probably a good idea, esp since this appears to be a crasher.

(In reply to comment #17)
> Having just returned to my laptop after a few minutes I found it locked hard
> (flashing Caps Lock). Could be a co-incidence, but it's usually very stable.
> 
> Nothing obviously useful in /var/log/messages, the last entries were:
> Jan  7 18:13:09 mopp NetworkManager: <info>  (wlan0): supplicant connection
> state:  completed -> associating
> Jan  7 18:13:09 mopp NetworkManager: <info>  (wlan0): supplicant connection
> state:  associating -> associated
> Jan  7 18:13:09 mopp NetworkManager: <info>  (wlan0): supplicant connection
> state:  associated -> complete
> 
> (and before that a log full of kernel oops, obviously, but nothing immediately
> before the lockup)

I have the same issue with identical log entries.

On kernel 2.6.27-12-170.2.5.fc10.x86_64 the problem disappears when I disable wireless with the hardware switch which leads me to believe its related to iwl3945.

Created attachment 330229 [details]
/var/log/messages showing disconnects

Possibly should be a new bug; possibly a re-occurrence of bug #235247 ? Or an artefact of this fix?

Since starting to use 2.6.28.1-9.rc2.fc10.i686 I get frequent (after a few minute) disconnects from the network after booting and connecting.

Forcing NM to reconnect doesn't help, however the problem seems to be cured if I use the kill switch to turn wireless off, then turn it back on.

/var/log/messages attached.

I don't believe that the patch mentioned above is the fix for this problem. 

kylem backported that patch to the current 2.6.27 kernel (rpms available at http://koji.fedoraproject.org/koji/taskinfo?taskID=1089515 ), but this does not fix the problem for me.

I also tried out the 2.6.28-3.fc10.i686 kernel, which I verified does *not* contain this patch (rpms at http://koji.fedoraproject.org/koji/buildinfo?buildID=78354 ), and it *does* fix the problem. 

So the success with 2.6.28.1-9 is apparently not due to this fix. 

One solution is just to wait for 2.6.28, but recent traffic on fedora-kernel-devel suggests that this is held up for a while ( http://koji.fedoraproject.org/koji/buildinfo?buildID=78354 ).

I have tried kernel 2.6.28-3, and the oops of iwl3945 resurfaced after several suspension and hibernation (running 10 hours before getting the iwl3945 oops message). And 2.6.28.1-19, though seemingly solved issue (no oops reported so far), still has the "Disabling IRQ#16" message, yet in 2.6.28.1-19 my system seems to be able to live with the issue long enough. The system is able to shutdown in 2.6.28.1-19, but not in 2.6.27.12-170.2.5, with that "Disabling IRQ#16" recurring.

(feel free to delete this comment)
Does Linville's comment #35 ("looks like it is already off My Bugzilla Front Page...") imply that this bug is not being worked on?

#41: The reports at http://kerneloops.org/searchweek.php?search=rs_get_rate agree with your experience: they show that this is still being hit in 2.6.28-1 and 2.6.28-3. 

I'm not too sure how to read these oopses, but there is a difference in the oopses generated by 2.6.27 and .28:

All the 2.6.27 reports show:
include/../net/mac80211/rate.h:152

While all the 2.6.28 reports show:
include/net/mac80211.h:1863 

Is this the calling function? If so, maybe the newer issue was either occluded by (or caused by) the patch. Just some very amateurish debugging--hopefully a useful clue to someone.


[For the record, this is still the number one issue on the front page of www.kerneloops.org (and is only reported by fc10 kernels--is this because it's a Fedora-specific issue, or because only Fedora is filing oops reports at kerneloops.org?)]

Further testing here (around 3 hours) shows that 2.6.27.5-117.fc10.x86_64 with the wireless switch turned off has neither the wpa_supplicant/iwl3945 oops nor the "Disabling IRQ#16" warning, yet 2.6.28-3, 2.6.28.1-19, and 2.6.27.12-170.2.5 do (vide comment #41). Further to be added is that "su -c 'rmmod iwl3945'" will not solve the case for 2.6.27.12-170.2.5, which will eventually freeze everything, no matter whether the wireless switch is on or off, contradicting comment #38.

(In reply to comment #43)
> #41: The reports at http://kerneloops.org/searchweek.php?search=rs_get_rate
> agree with your experience: they show that this is still being hit in 2.6.28-1
> and 2.6.28-3. 

Confirmed: I had an oops yesterday with 2.6.28.1-9.rc2.fc10.i686. This has taken 
~2 weeks to show up, rather than the 20 minutes I was seeing with 2.6.27 (same WLAN), so perhaps the fix has only mitigated whatever *triggers* the underlying oops problem (perhaps just on my hardware and network).

I've also been seeing occasional - but more frequent than F9 - disconnects from the WLAN. This is what I was also seeing in 2.6.27 just before every oops; with 2.6.28 it survived the reconnect without an oops each time until yesterday. This looks to be the error log on each drop:
Feb  5 16:59:00 mopp kernel: iwl3945: Error sending REPLY_SCAN_CMD: time out after 500ms.
Feb  5 16:59:01 mopp kernel: iwl3945: Error sending REPLY_RXON: time out after 500ms.
Feb  5 16:59:01 mopp kernel: iwl3945: Error setting new configuration (-110).
Feb  5 16:59:01 mopp kernel: iwl3945: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms.

I tried the recent vanilla release as follows,

$ uname -r
2.6.28.7

, which runs without neither Xorg nor iwl3945 oopses for almost 2 hours right now, with the following,

$ rpm -qv kerneloops
kerneloops-0.12-1.fc10.x86_64

. So I could reasonably conclude that the upstream already had the issue fixed. And this bug could be closed I guess, albeit still we do not know what the cause is.

Have you tried any of the 2.6.29-based F10 kernels available in Koji?

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

Well, not yet, but thanks for pointing that out, as hopefully I would prefer to keep my machine stable, id est, frozen, for a week. I will probably restore settings and check out 2.6.29 kernels this weekend. The vanilla 2.6.28.7 kernel has already run for almost 24 hours, and nothing bad happens so far. Wireless and Xorg is going well and no more oops messages, particularly about tainted or not-tainted module. I also have to make sure the issue will not resurface as it did in the previous 2.6.28.x kernel releases in koji.

Are there any known good kernels from 2.6.28.x with regard to iwl3945 and the kernel oops?

(In reply to comment #49)
> Are there any known good kernels from 2.6.28.x with regard to iwl3945 and the
> kernel oops?

From koji

The powers that be in Fedora decided to skip 2.6.28 -- the last 2.6.28-based kernel build I see in Koji was based on 2.6.28.1 and is the kernel reference in comment 45 as still showing signs of the problem.

(In reply to comment #47)
> Have you tried any of the 2.6.29-based F10 kernels available in Koji?

kernel-2.6.29-0.43.rc6.fc10.i686 wireless stalls after 30 secs or so, and doesn't seem to put anything useful in /var/log/messages either (i.e. nothing in messages, but my wireless ground to a halt). I'd say this is worse, not better. Incidentally, my bluetooth and UMTS modem haven't been detected either.

I note there's now a newer 2.6.29 kernel in koji. Given the intermittent nature of the problem (seems to only happen on "busy" networks?) it's tricky to track, install, and test the latest kernel - I'm not on a known problem network all the time, and installing a new kernel is tricky without network ;) . If you could point out specific kernels you'd like us to try - perhaps where fixes are known to have been committed - that would be helpful.

(In reply to comment #52)
> I note there's now a newer 2.6.29 kernel in koji.

Apologies, this still seems to be the latest .29 F10 kernel after all. Let me know if there's anything else you'd like me to try with it.

A few of us at EclipseCon here this week have been experiencing this with our x61 ThinkPads.  At least we think this is the same bug :)

The issue seems to go away with kernel-2.6.29-3.fc10.x86_64, its been running for 2 days and I have not got any issue with wireless.

Marking as tentatively fixed. Some more confirmations would be helpful...

I've had no problems with freezing/crashing with 2.6.29-0.43.rc6.fc10.x86_64 for several weeks now.

(In reply to comment #56)
> Marking as tentatively fixed. Some more confirmations would be helpful...  

I've installed kernel-2.6.29-3.fc10.x86_64 and will test next week on the known busy problem network to see it solves the stalls I had in comment #52 with 2.6.29-0.43.rc6

Related to NM: 2.6.29-3.fc10 certainly doesn't detect my wwan card (or bluetooth) as mentioned previously in comment #52. I've reported this against the kernel as bug #492709, but if you think it's more likely to be hal or NM, please say/re-assign.

This is hard to report on bugzilla as it spans multiple components, but F10 has been *terrible* for hardware regressions on this laptop. I've not yet had a set of packages for F10 that gives me more than two out of: working X, working wlan, working wwan/bluetooth. Worse still, testing kernels etc. for any one of the problems has exacerbated the problem for the others. I realise it's just an "unlucky" combination of hardware, but it's a combination many users will have - and that worked with F9. What's the best way to report this?

Random disconnects with 3956ABG on Thinkpad X60 (i386) here too.
Installed 2.6.29-10 from koji today but still random disconnects... Maybe i'll try 2.6.29-3 as mentioned later if it will fix the problem.

re: Comment #59
Then it's hardward-dependent as I am on a Thinkpad T61 with x86_64 and was with 2.6.29-3 and now with 2.6.29-10.

(In reply to comment #60)
> re: Comment #59
> Then it's hardward-dependent as I am on a Thinkpad T61 with x86_64 and was with
> 2.6.29-3 and now with 2.6.29-10.  

I'm using a Thinkpad T61p (Intel 3945ABG, iwl3945) and I haven't had any freezing issues with 2.6.29-0.43.rc6.fc10.x86_64.

Are you using the Intel 3945 wireless card or the newer one that was offered with the T61? (4965?)

re: Comment #60

I'm with the 3945 one.

(In reply to comment #59)
> Random disconnects with 3956ABG on Thinkpad X60 (i386) here too.
> Installed 2.6.29-10 from koji today but still random disconnects... Maybe i'll
> try 2.6.29-3 as mentioned later if it will fix the problem.  

I made a mistake, it's a 3945ABG of course.

Please try kernel-2.6.29.1-30 from the updates-testing repository.

I haven't been experiencing any issues with 2.6.29-3.fc10.x86_64 but I'm also rarely on a high-traffic wifi network like I was at EclipseCon when I experienced this.

kernel-2.6.29.1-30.fc10.i686 and now kernel-2.6.29.1-42.fc10.i686 seem ok to me...

BUT I think we may have had another AP added to the previously problematic network here (due to high-traffic), so I wouldn't want to guarantee I'm on a high-traffic net anymore (if that was indeed the trigger for the bug).

2.6.29.1-42.fc10.i686 and back on the original "problem" (busy) network: I'm getting pretty regular disconnects from the network. It doesn't always seem to fully re-connect to the network without turning wireless off and on again (which I guess modprobes in and out).


I have installed 2.6.29.3-60.fc10 from updates-testing, and will boot into that tomorrow.


Got a couple of oops too, when I used the kill-switch, but I think these are from sierra (which the kill-switch also bounces, and probably triggered):
May 20 17:02:43 mopp kernel: BUG: sleeping function called from invalid context at kernel/mutex.c:88
May 20 17:02:43 mopp kernel: in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper
May 20 17:02:43 mopp kernel: Pid: 0, comm: swapper Not tainted 2.6.29.1-42.fc10.i686 #1
May 20 17:02:43 mopp kernel: Call Trace:
May 20 17:02:43 mopp kernel: [<c042843e>] __might_sleep+0xdf/0xe4
May 20 17:02:43 mopp kernel: [<c06d6957>] mutex_lock+0x18/0x2d
May 20 17:02:43 mopp kernel: [<c06d78a6>] ? _spin_unlock_irqrestore+0x22/0x38
May 20 17:02:43 mopp kernel: [<c058ed9e>] reset_buffer_flags+0x4f/0xd5
May 20 17:02:43 mopp kernel: [<c058ee31>] n_tty_flush_buffer+0xd/0x60
May 20 17:02:43 mopp kernel: [<c058f33a>] n_tty_receive_buf+0x4b6/0xff9
May 20 17:02:43 mopp kernel: [<c0428786>] ? default_wake_function+0xb/0xd
May 20 17:02:43 mopp kernel: [<c0424f25>] ? enqueue_entity+0x295/0x29d
May 20 17:02:43 mopp kernel: [<c041b421>] ? default_spin_lock_flags+0x8/0xb
May 20 17:02:43 mopp kernel: [<c06d78a6>] ? _spin_unlock_irqrestore+0x22/0x38
May 20 17:02:43 mopp kernel: [<c041b421>] ? default_spin_lock_flags+0x8/0xb
May 20 17:02:43 mopp kernel: [<c05918f5>] flush_to_ldisc+0xf1/0x17f
May 20 17:02:43 mopp kernel: [<c05919c4>] tty_flip_buffer_push+0x41/0x51
May 20 17:02:43 mopp kernel: [<f87088b9>] sierra_indat_callback+0x68/0xb0 [sierra]
May 20 17:02:43 mopp kernel: [<c05f129e>] usb_hcd_giveback_urb+0x63/0x97
May 20 17:02:43 mopp kernel: [<c0606f8a>] uhci_giveback_urb+0xe5/0x15f
May 20 17:02:43 mopp kernel: [<c06077bf>] uhci_scan_schedule+0x533/0x776
May 20 17:02:43 mopp kernel: [<c0447987>] ? clockevents_program_event+0xdb/0xea
May 20 17:02:43 mopp kernel: [<c06092fa>] uhci_irq+0x107/0x11c
May 20 17:02:43 mopp kernel: [<c05f0ee5>] usb_hcd_irq+0x40/0xa3
May 20 17:02:43 mopp kernel: [<c0466ee4>] handle_IRQ_event+0x2f/0x64
May 20 17:02:43 mopp kernel: [<c0468061>] handle_fasteoi_irq+0x7b/0xb5
May 20 17:02:43 mopp kernel: [<c0467fe6>] ? handle_fasteoi_irq+0x0/0xb5
May 20 17:02:43 mopp kernel: <IRQ>  [<c04043ac>] ? common_interrupt+0x2c/0x34
May 20 17:02:43 mopp kernel: [<c057e932>] ? acpi_idle_enter_bm+0x259/0x29a
May 20 17:02:43 mopp kernel: [<c0635464>] ? cpuidle_idle_call+0x60/0x94
May 20 17:02:43 mopp kernel: [<c0402dfc>] ? cpu_idle+0x6b/0x8b
May 20 17:02:43 mopp kernel: [<c06d3053>] ? start_secondary+0x1c9/0x1d1
May 20 17:02:44 mopp kerneloops: Submitted 1 kernel oopses to www.kerneloops.org

Upgraded to F11, and still having some disconnect issues on the "problem"/busy network. My feeling is that the problem is less frequent, but this could equally be the number of hosts on the network changing? Once a disconnect has occurred it seems to be much harder to get a stable connection (but again, this could just be a busy day?)

The problems seem to kick off with:
Jul 13 12:36:49 mopp NetworkManager: <info>  (wlan0): supplicant connection state:  completed -> disconnected
Jul 13 12:36:49 mopp NetworkManager: <info>  (wlan0): supplicant connection state:  disconnected -> scanning
Jul 13 12:36:49 mopp NetworkManager: <info>  (wlan0): supplicant connection state:  scanning -> associating
Jul 13 12:36:49 mopp kernel: iwl3945: Microcode SW error detected.  Restarting 0x82000008.
Jul 13 12:36:49 mopp kernel: iwl3945: Error Reply type 0x000002F0 cmd REPLY_TX_PWR_TABLE_CMD (0x97) seq 0x0443 ser 0x00000078
Jul 13 12:36:49 mopp kernel: iwl3945: Can't stop Rx DMA.
Jul 13 12:36:49 mopp kernel: Registered led device: iwl-phy0:radio
Jul 13 12:36:49 mopp kernel: Registered led device: iwl-phy0:assoc
Jul 13 12:36:49 mopp kernel: Registered led device: iwl-phy0:RX
Jul 13 12:36:49 mopp kernel: Registered led device: iwl-phy0:TX
Jul 13 12:36:49 mopp NetworkManager: <info>  (wlan0): supplicant connection state:  associating -> disconnected
Jul 13 12:37:04 mopp NetworkManager: <info>  (wlan0): device state change: 8 -> 3
Jul 13 12:37:04 mopp NetworkManager: <info>  (wlan0): deactivating device (reason: 11).
Jul 13 12:37:04 mopp NetworkManager: <info>  wlan0: canceled DHCP transaction, dhcp client pid 2120


Let me know if you need more/different logs.

On this occasion NM timed out; I could then force a reconnect by manually re-selecting the network.

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

According to comment #68 problem still occurs on F11.

I've not been having this problem on F11 or F12 on my ThinkPad T61/iwl4965.  I'm on a fairly large edu wireless network with lots of traffic.

Kevin, 

your problem on F11 seems to be different issue, could you please open new bug report for it ?

I haven't seen this issue in the last month or so with recent F11 kernels (though obviously it was always pretty intermittent). If it shows up again I'll file a new bug.

Reversion back to F10, issue is not reproducible on F11.

I do not see any chance to fix this bug in F10. Since bug fixed on F11 I'm closing is with NEXTRELAESE.