Description of problem: i can't connect to wireless ap with a pcmcia card using rt2500pci. however, i can connect if i replace the rt2500pci with ndiswrapper+rt2500 windows driver. see https://bugzilla.redhat.com/show_bug.cgi?id=472183#add_comment for details Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Please try the latest fedora 10 kernl from updates-testing: yum --enablerepo=updates-testing update kernel
uname -r 2.6.29.1-30.fc10.i686 the driver is no longer loaded with this kernel.
Were you blacklisting it to load ndiswrapper? Did you un-blacklist it when testing 2.6.29.1-30.fc10.i686? I don't recall removing any IDs from that driver. Please post the output of 'lspci -nv'...thanks!
$ cat /etc/modprobe.d/blacklist # # Listing a module here prevents the hotplug scripts from loading it. # Usually that'd be so that some other driver will bind it instead, # no matter which driver happens to get probed first. Sometimes user # mode tools can also control driver binding. # # Syntax: driver name alone (without any spaces) on a line. Other # lines are ignored. # # watchdog drivers blacklist i8xx_tco # framebuffer drivers blacklist aty128fb blacklist atyfb blacklist radeonfb blacklist i810fb blacklist cirrusfb blacklist intelfb blacklist kyrofb blacklist i2c-matroxfb blacklist hgafb blacklist nvidiafb blacklist rivafb blacklist savagefb blacklist sstfb blacklist neofb blacklist tridentfb blacklist tdfxfb blacklist virgefb blacklist vga16fb # ISDN - see bugs 154799, 159068 blacklist hisax blacklist hisax_fcpcipnp # sound drivers blacklist snd-pcsp # wireless #blacklist rt2500pci of course, the info on this post is sent using the previous, stable, f10 kernel. lspci -nv output, in attachment.
Created attachment 341184 [details] lspci -nv output
what took me by surprise, is that even if the module was unlisted, the ndiswrapper module has priority. i remember very clear that i've blacklisted rt2500pci because it had priority over ndiswrapper.
03:00.0 0280: 1814:0201 (rev 01) Subsystem: 1458:e831 Flags: bus master, slow devsel, latency 64, IRQ 16 Memory at d4000000 (32-bit, non-prefetchable) [size=8K] Capabilities: <access denied> Kernel driver in use: ndiswrapper Kernel modules: rt2500pci Looks like the kernel still recognizes that device for rt2500pci, but ndiswrapper is getting loaded instead...
that was while i was connected to wireless network, with ndiswrapper. that;s how it looks when i use the new kernel: 03:00.0 0280: 1814:0201 (rev 01) Subsystem: 1458:e831 Flags: slow devsel, IRQ 16 Memory at d4000000 (32-bit, non-prefetchable) [disabled] [size=8K] Capabilities: <access denied> Kernel modules: rt2500pci otoh, if i modprobe rt2500pci, i get the usual network manager screen requiring again and again same credentials (useless).
It still looks pretty clear that the rt2500pci module has the proper ID. Are you saying it isn't getting loaded automatically? If not, then it almost certainly is a configuration issue.
the driver is not loaded automatically on the above named kernel. (2.6.29.1-30.fc10.i686) . however, sometimes it is loaded instead of ndiswrapper on older kernels. i have no idea why sometimes it is loaded and sometimes ndiswrapper is loaded. config is the same on both cases, the kernel is from "updates", ndiswrapper is enabled, and the blacklist entry is commented out. anyway, with the new kernel and the driver modprobed, the problem is still present.
I tried Fedora 11 Snap1 Live CD with kernel 2.6.29.1-54.fc11.i586 on a ThinkPad 600E and I have the same problem. I have WL-107g card. I can see the name of my network in NetworkManager but connection always fails. WL-107g works with Fedora 7. If I unplug the WL-107g card and try with XyZEL AG-220 then I can connect to the network. The network does not have any encryption. I have not tried with ndiswrapper. I have had similar problems with a rt2500 PCI card on a desktop machine as well. I think this is an old bug?
Is this duplicate of bug #457441?
it looks like it is.
*** This bug has been marked as a duplicate of bug 457441 ***