Bug 434655

Re-assigned to the right component

But you talk about Rawhide kernel and FC-8? Did you tryed the kernel in
updates-testing ? the kernel-2.6.24.2-7.fc8 has lot of patches related to the
wifi. It might be more "stable" than Rawhide kernel... 

FWIW, the deauthentication messages from your rawhide kernel originate with 
your AP -- "reason=4" means "Disassociated due to inactivity", and 
the "reason=2" means "Previous authentication no longer valid".  These come 
from the AP, and our only option is to comply.  The logs also seem to 
indicated that subsequent authentication and association steps are successful, 
so I don't see a problem in the rawhide logs.

I concur with kwizart that you are likely to have much better results with 
kernel-2.6.24.2-7.fc8 than you had with 2.6.23.15-137.fc8.  Please give that a 
try and report the results here...thanks!

I tried again last night, and generally performance was better across the board
for all kernel configurations, but I was testing in a different location.  I had
hoped to go back to the original location for further experimentation but I
broke something when I updated to the latest rawhide.

Last night I only experienced the deauth messages which were recovered. 
However, prior to these messages, the connection would freeze for some time. 
Pinging the AP would not work.  After a while I would then get the deauth and
re-auth messages.  All the while the network manager icon would report varying
signal strength so it appeared to be tracking the connection.

In fact, I don't know why lack of activity would be the cause.  The
deauth/re-auth cycles occurred several times during downloading the rawhide
updates so there was plenty of activity.  It appears that the download would
progress, then the linux side gets confused and cannot maintain connectivity
(pinging no longer works) and the connection remains hung until reset by the AP
deauth due to inactivity as the linux drivers are "locked up".

Last night, the released F8 *.23 kernel worked best.  I will continue testing.

Keep in mind for rawhide, one of the failure modes is a system crash from which
I have no logs.  Again, I will try to get rawhide back up for further testing.

Going back to the original location (a nice comfy chair 3 feet from phone base
station and 40 feet from the AP) the F8 .24 kernel from updates-testing crashed
almost immediately after connection.

On reboot, system did not crash but connection jammed as described earlier.  NM
icon/iwconfig apparently still see the AP as they show changing signal strength
(25-60%).  iwconfig shows 0kB/s bitrate.  No network traffic appears to be
occurring.  Also from this position, the de-auth reset was not occurring as
before and network remained locked up.  The connection was initiated correctly
as the DHCP transaction occurred.

F8 .23 kernel appears to work from this location.

Wrapping up my testing, the F8 .23 kernel does hang from time to time.  No
messages, but I can reset the connection with NM.  It is the most reliable but
with the worst performance (speed and range).

With 2.6.24 kernels and new system crashes sometimes occur.  They do appear to
have better performance but worse reliability.

Note, M$ WinXP has best of both worlds.  Better range, speeds to 144MB/s and no
reliability problems.  So there is hope.

Can you replicate this issue with current F-8 kernels?

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

Created attachment 297980 [details]
Tarfile containing /var/log/messages and dmesg text

Error messages for the latest F8 kernel

The F8 2.6.24.3-12 kernel worked fine for the first couple days, but today it
locked up during web browsing and even after rebooting I cannot establish a
connection.  Many new error messages have been attached...

Ah, sorry about that.  Some people reporting similar problems have found the 
2.6.24.3-34 kernel to be quite a bit better:

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

Give that a try instead?

Created attachment 298318 [details]
/var/log/messages for system hang with kernel 2.6.24.3-38

Using 2.6.24.3-38 I still get a system hang.  It appears that the system will
hang within after a few seconds the connection is established if at all.  If it
doesn't hang within a few seconds, then it appears that the system hang won't
occur.

Attached is a message log for three attempts.  The first two failed with system
hangs.

Dan, do you see any similarity between this and bug 437903?

kelly: is it a panic, ie the caps-lock light is flashing?  or does the system
just hang?

john: I don't see any apparent errors in the latest log from -38 Kelly posted, I
think notting's bug is different.  We'll need more information about what
process the driver is going through in notting's case, and here driver logs
might also be interesting too just to see what the driver is doing after connect.

The caps- and scroll-lock keys flash.  I only experience system hangs with
2.6.24 or later.  I've never had a system hang with a stock kernel 2.6.23 or
earlier.

When the link stays up, performance seems erratic.  I often have to wait on 
network communication.  I'll have several web pages waiting on their servers,
then all at once they'll all get a large chunk of data and complete.  This is a
separate issue and should probably be addressed elsewhere.  What is the proper
forum for this performance issue?

Just want to comment that I am also seeing a system hang with this driver.  iwl
4965 card, Kernel 2.6.24.3-50.fc8 x86_64.

For me the problem is:
Connect to a WPA/WPA2 802.11n network -> hang (sometimes a blinking capslock)

But if I connect first to a neighbour's unsecured 802.11b network, and THEN
connect to my WPA/WPA2 802.11n network, things usually work.  Every time I
suspend or resume I have to do the same thing.  It's workable for now but I hate
to think what I'd do if my neighbour shut off or secured his wifi :)

Unrelated to the hang: I am seeing the same performance issue as Kelly Stephens
mentioned, not to mention that I only connect to my N accesspoint at 60Mbps.

Well I hate to keep playing the "try the latest kernel game", but...

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

Several have had success using iwl3945 with that kernel.  Does it help you?

Created attachment 301807 [details]
/var/log/messages for F8 and F9

I maintain a separate partition for both F8 and F9.  Both have halted in the
past day.  Attached are the logs.  F9 ran for 10 minutes before crashing, but
the suspicious iwl4965 message occurred just before the crash.	In F8, the
connection was established, my mail headers downloaded, and then the system
crashed.  Again just after the iwl4965 message.

Are you in charge of your wireless access point?  If so, can you disable 
802.11n on it?  If so, could you try that and see if that prevents the crash?

Thanks!

When I disable 802.11n I no longer see the crash but my range is reduced.  From
the location where I usually experience the crashes the network comes up
initially and is able to transfer some data, but a few seconds later the network
goes down.  Subsequent attempts to reconnect all fail.  Closer to the AP, the
network appears reliable.

There is a patch called "iwlwifi: fix n-band association problem" in the 
kernels here:

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

Give those a try?

I haven't had a system hang for some time with these kernels for fc8 or fc9. 
But the connection has continued to be unreliable.  This now appears to be fixed
in fc8 as of 2.6.24.6-90.  Please port to fc9 as I am hooked on the updated
features of NetworkManager.

Thanks so much...

Spoke too soon.  Still no system hangs, but the connection remains unreliable in
fc8.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I just experienced a system hang with the latest fc9 kernel: 2.6.25.3-18.

I also have a D630 with 4965AGN, without problems on either F8 (only the latest
few kernels released) or F9. However I don't have a 802.11n-accesspoint
available, only using 802.11g.

Can you recreate this issue with the test kernels here?

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

With 2.6.25.4-30 I am experiencing a different kind of system hang.  Rather than
an immediate hang with blinking caps and scroll lights, the system slowly dies.
 After logging in, everything works fine, but if I come back later and try to
start Mozilla not connection is made.  If I then try to start a terminal, it
will also fail.  Things deteriorate quickly with the window manager misbehaving
then the mouse eventually freezing.  The only option is to power down.

Hmmm...well that doesn't necessarily sound likea wireless problem.  Do you get 
different behavior if you do not use the network?

I've been keeping up with the kernel releases.  I'm now at 2.6.25.4-42.  It
appeared to be pretty stable until I went on vacation.  When I try to connect to
an AP with WEP security the notebook crashes again with the blinking lights.  If
I change the security on the AP to WPA2, I do not crash but successfully
negotiating the connection is iffy.

(In reply to comment #28)
> I've been keeping up with the kernel releases.  I'm now at 2.6.25.4-42.  It
> appeared to be pretty stable until I went on vacation.  When I try to connect 
to
> an AP with WEP security the notebook crashes again with the blinking lights.  
If
> I change the security on the AP to WPA2, I do not crash but successfully
> negotiating the connection is iffy.

I got a kernel version which is working pretty well with AGN4965, do u want to 
give it a try if I upload for you kernel + kmod-nvidia ? (2.6.25-
0.121.rc5.git4.fc8 + patch from intellinuxwireless)

(btw my computer hangs sometimes too when I'm trying to connect to a WEP 
network)

Another thing is that if I run "ifdown wlan0", i got no output and the command 
seems to hang indefinitely (until I press Ctrl-C), perhaps something I could 
try to get you some debug infos ?

NB: I tried the last kernel that John W. Linville gave me in another thread for 
4965AGN, it was even worse ... => (I never succeeded in making a WEP connection 
without hanging the whole system)

Is this still occuring with kernel-2.6.25.9-76.fc9?

worksforme with 4965 and -76.fc9; confirmed broken with -55.fc9 of course