Bug 441000

Please try 2.6.25-0.195.rc8.git1.fc9 or later just to make sure we haven't 
already addressed the issue. :-)

Also, do you have a line like this in /etc/modprobe.conf?

   options iwl3945 disable_hw_scan=1

Could you try with (or without) it?  That sometimes seems to change that 
driver's behavior...

Created attachment 301580 [details]
output of dmesg

Chmm, this is
Linux viklef 2.6.25-0.200.rc8.git3.fc9.i686 #1 SMP Sat Apr 5 00:00:10 EDT 2008
i686 i686 i386 GNU/Linux

and two times of out of two attempts it worked flawlessly. Except when testing
now I found some backtraces in output of dmesg. See attached. Will try hw_scan.

a) disable_hw_scan didn't help, it might even make things a little bit worse for
what I know,

b) using 

Linux viklef 2.6.25-0.234.rc9.git1.fc9.i686 #1 SMP Tue Apr 15 18:37:15 EDT 2008
i686 i686 i386 GNU/Linux

wireless is still quite unrealiable. Most of the time it gets on pretty well
(and even fast, it almost looks like computer has never been disconnected).
However, when it breaks, it's pretty bad. service NetworkManager restart doesn't
help, iwlist wlan0 scan doesn't help, and apparently I cannot even reliably
modprobe -v -r iwl3945 (modules just stay there). I tried even plain
rmmod -f iwl3945 but the module just stays there and it is apparently not in
good shape. Sometimes, I make it work again with just plain iwlist when rubbing
it for some time with rmmod, but sometimes it just doesn't work and I have to
reboot.

I am founding in dmesg really strange things when rmmod doesn't work:

name_count maxed, losing inode data: dev=00:05, inode=950710<7>name_count maxed,
losing inode data: dev=00:05, inode=950710<7>name_count maxed, losing inode
data: dev=00:05, inode=950710<7>name_count maxed, losing inode data: dev=00:05,
inode=950710<7>name_count maxed, losing inode data: dev=00:05,
inode=950710<7>name_count maxed, losing inode data: dev=00:05,
inode=950710<7>name_count maxed, losing inode data: dev=00:05,
inode=950710<7>name_count maxed, losing inode data: dev=00:05,
inode=950710<7>name_count maxed, losing inode data: dev=00:05,
inode=950710<7>name_count maxed, losing inode data: dev=00:05,
inode=950710<7>name_count maxed, losing inode data: dev=00:05,
inode=950710<7>name_count maxed, losing inode data: dev=00:05,
inode=950710<7>name_count maxed, losing inode data: dev=00:05,
inode=950710<7>name_count maxed, losing inode data: dev=00:05,
inode=950710<7>name_count maxed, losing inode data: dev=00:05,
inode=950710<7>name_count maxed, losing inode data: dev=00:05,
inode=950710<7>name_count maxed, losing inode data: dev=00:05,
inode=950710<6>ADDRCONF(NETDEV_UP): eth0: link is not ready

Attaching /var/log/messages (bzipped -- they are 11MB otherwise) and dmesg output.

Created attachment 302843 [details]
output of dmesg

Created attachment 302844 [details]
/var/log/messages

I'm experiencing this problem also, I cannot connect to my router. I tried both
with the system-config-network and NetworkManager, both fail. My dmesg shows
similar patterns with the line "wlan0: RX disassociation from 00:0f:3d:99:85:32
(reason=7)" appearing several times along it. This is with the kernel bundled
with the preview release: 

kernel-2.6.25-0.234.rc9.git1.fc9.x86_64

At present F8 kernels actually are more up-to-date w.r.t. wireless...could you 
try these kernels?

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

(In reply to comment #9)
> At present F8 kernels actually are more up-to-date w.r.t. wireless...could you 
> try these kernels?
> 
>    http://koji.fedoraproject.org/koji/buildinfo?buildID=46436

Is it possible downgrade from 2.6.25-1.fc9.i686 to 2_6_24_4-84_fc8 without
causing any harm?

I haven't specifically tried, but generally the worst you can do is to have a 
new kernel that doesn't work.  You might have to install the F8 kernel 
with --force and/or --nodeps.  Hth!

I do have fedora 8 installed in the same computer and it seems to work better
with it. Would a test with the fedora 9 environment and the fedora 8 kernel
still make sense? 

Also it seems that the first time after the boot the connection works ok, if I
log out, networkmanager disconnects the network, and log in again the connection
refuses to go up again. 

I've got similar problem with my iwl4965, after logging into system, first thing
what i have to do is restart NetworkManager (or all network). Then usually i
must wait few minutes for NM to find my networks (one DHCP WPA and one static
WEP) - scanning takes ages. Sometimes i just have to restart NM several times
until it'll find my networks. After they're found usually there's no problem
with connection, but sometimes happens, that i'm being asked to provide key. But
after providing proper key, it still can't connect, and then ask me to provide
key again and again. NM restart usually is helpful then. 
I don't know if it's NM or kernel related, but about month ago there was no
problems with scanning networks, i had my networks immediately available. There
was also no problems with connection to WEP network (after support for static
configuration was added), sometimes i had only problems with keys for WPA
network. Now after loosing connection to my network i must restart NM and wait
another few minutes to connect also, nm just won't reconnect by itself.

(In reply to comment #11)
> I haven't specifically tried, but generally the worst you can do is to have a 
> new kernel that doesn't work.  You might have to install the F8 kernel 
> with --force and/or --nodeps.  Hth!

Actually, it won't work for me -- partially by mistake, but I did switch my root
partition to ext4dev, which is not AFAIK supported by F8 kernels at all.

Victor,

I don't think there is any great benefit to trying an F8 kernel on an F9 
userland in your situation.  Which F8 kernel are you using?  Also, how much 
better is "works better"?  Is it greatly improved?  Or just less annoying? :-)

The bug is not fixed in Fedora9 RC1, on x64 version, for WPA2PSK wireless
connections.
kernel-2.6.25-8.fc9.x86_64
NetworkManager-0.7.0-0.9.3.svn3623.fc9.x86_64
NetworkManager-gnome-0.7.0-0.9.3.svn3623.fc9.x86_64
wireless-tools-29-2.fc9.x86_64

Steps to reproduce:
1. Login to F9. Wait until NM connects to the wireless connection.
2. Logout.
3. Login with the same account or a different one -> NM doesn't connect.
Sometimes it works after reentering the wireless network passwd. The rest of the
times, the connection from NM must be deleted and reentered.

Let me know if you need aditional info.

Agreed, I still see it as well with

[matej@viklef ~]$ rpm -q kernel NetworkManager wireless-tools
kernel-2.6.25-1.fc9.i686
kernel-2.6.25-8.fc9.i686
kernel-2.6.25-14.fc9.i686
NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386
wireless-tools-29-2.fc9.i386
[matej@viklef ~]$ uname -a
Linux viklef 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT 2008 i686 i686
i386 GNU/Linux
[matej@viklef ~]$ 

Updated today to the latest F9. I can no longer reproduce the bug, with:
kernel-2.6.25-14.fc9.x86_64
NetworkManager-0.7.0-0.9.3.svn3623.fc9.x86_64
NetworkManager-gnome-0.7.0-0.9.3.svn3623.fc9.x86_64
wireless-tools-29-2.fc9.x86_64

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

problem persist, also, somtimes i get a notification saying that im connected to
"none" and of course i get no connection at all. This seems to be a kernel
failure as i kept trying to connect and when it finally connected i get
kerneloops error message. This problem is not easy to reproduce as it seems to
be very random. I get it sometimes when i reboot the laptop. Also i found out
that i get an error when starting apache when i get this issue with the wirless
connections, saying that it can find an address specified ina VirtualHost, and
as soon as i get things working such error in apache dissapear and things work
fine again

I just updated my bios (i have a Dell Inspiron 1420) and after the update things
are working so much better. I cant really say its fixed, but i really tried to
reproduce the bug and it didnt happened but once and after two tries (way more
less than the usual when bug appears) i got my connection back

Can you recreate this issue with the test kernels here?

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

On first tests, it looks like working flawlessly. THANKS!!!

However, let me test it a littlbe bit more and I will let you know whether I
will meet any problems with it.

Certainly the situation has changed substantially. I would consider this fixed,
and if I found more problems, I would let you know.

THANK YOU

Bug is not fixed completely by the kernel proposed there, neither is done by
kernel 2.6.25.4-30.fc9 from updates-testing repository, even though things got a
lot better than they were, they are still not as good as they where in fedora 8
with kernels 2.6.23 and 2.6.24

I'm afraid you'll have to be more specific than that if you want to keep this
bug open.  Or better yet, open a bug specific to whatever problem you are
currenly seeing.  "Not as good as...kernels 2.6.24 and 2.6.24" is a bit too
subjective.

sorry about that. Thing is, with kernel 2.6.25-30 things are working so much
better, nm connects to the wireless network in less time than before, but still
there are times when it keeps asking for the password again and again and doesnt
connect, although is not as frequent as it was with a previous f9 kernel. 
Please let me know if there is anything else you need to get more understanding
of what's happening.

One of the reasons why it would be better for you (and us) to open a new bug for
new issue, is that it would force to provide complete information about what's
going on. I might overshoot it in the original filing of this bug, but could you
try to provide similar amount of infromation about your problem, please? And
probably in a new bug.

Closing, because as an original reporter, I think this has been fixed for me.