Bugzilla – Bug 113385
Netgear 32-bit CardBus WG511 does not work anymore
Last modified: 2005-11-24 12:54:12 UTC
Hardware: Netgear WG511 CardBus WLAN card, worked fine until 9.3. After update to 10.0Beta3 I run the install_intersil_firmware script (luckily I had a network cable to connect, since the location of the firmware on SuSE Linux changed) to install the new firmware on the system. I get the following messages if I insert the card: "Loaded prism54 driver, version 1.2 PCI: Enabling device 0000:02:00.0 (0000 -> 0002)" In the past with SuSE Linux 9.3 I got: Aug 26 09:57:04 rubicon kernel: eth1: uploading firmware... Aug 26 09:57:04 rubicon kernel: eth1: firmware version: 1.0.4.3 Aug 26 09:57:04 rubicon kernel: eth1: firmware upload complete Aug 26 09:57:04 rubicon kernel: eth1: interface reset complete I don't get this anymore, the WLAN card does not work and the MAC is 00:00:00:00:00:00, which looks like the card will not be initialized correct.
Already fixed in stable. The udev rule for the firmware script was wrong. Try STABLE.
Nope, does not work with new udev from stable. If I look at the script and try to understand it, I would think that the prism54 driver does not support /sys correct, at least I cannot find a "loading" directory.
Adding debug code shows, that the firmware script is not run and yes, I verified that the path is correct and I bootet to make sure that the new udev is really used.
After googleing a bit I think I know now what happens: - Insert the pcmcia card - Call "ifconfig eth1 up" (eth1 is the card in my case) - Run "ifup eth1" Voila, now it works. What happens is: The firmware will not be loaded before somebody is accessing the network. But without firmware we don't have the correct MAC address, so a "ifup eth1" has to fail. If "ifup eth1" does not work, we cannot access the network and the firmware will not be loaded :-(
OK, known problem. I will reactivate the old hack we had in network.agent.
reduce number of kukuks blocker ... To be honest, this is just one broken driver of many. This is definitvely not a blocker.
Workaround is now in sysconfig package. Call udevcontrol reload_rules, since it contains new rules. Joe will also fix the driver.
Created attachment 48111 [details] Patch to make prism54 load firmware on initialization Here is a patch for prism54 against the beta3 kernel.
Jiri, please review the patch and submit to HEAD if appropriate.
I think there may be some problems with this patch: - the card will reset and load the firmware twice ... on initialization and on open; My experience is that prism54 cards often hang hang on a reset. - if this driver is ever compiled directly into the kernel (not as a module), it will request the firmware before the root filesystem with the firmware is mounted, and will probably timeout for 30 seconds (??) -- not sure about this. Joachim: have you actually tested it works? We don't have the hardware here. This seems like a workaround, rather than a bugfix that could possibly be sent upstream. This is a known problem of this driver (and many others), and the proper fix would be more complicated (one of the solutions is to load the firmware when the first ioctl call on the device occurs). If we have a workaround in userspace, do we have to have another one in the kernel?
> the card will reset and load the firmware twice ... on initialization and on open This is true. But the driver will load the firmware every time the interface is set up, so I don't see a problem here. > if this driver is ever compiled directly into the kernel (not as a module), it will request the firmware before the root filesystem with the firmware is mounted, and will probably timeout for 30 seconds (??) -- not sure about this. The firmware loading will fail in this case, no doubt. Not only the firmware image is not available at this point, there is also no firmware hotplug handler. But I don't think the kernel will hang. I've tested it of course and it seems to work. But I don't insist on this patch.
Installation: SUSE 10 x86_64 (update from 9.3) Beta: Beta4 HW Info: http://www.cynapses.org/hwinfo.log Description: ------------ Currently the firmware gets uploaded twice and the interface gets renamed to eth(x++). So the number increases with every plug-in. Reproduction: ------------- Re-plugin the card serveral times Logs: ----- I could attach the part of /var/log/messages with udev log_priority=info if wanted.
Christian, that fixed in RC1 iirc, isn't it? Besides the interface renaming problem, does the card work after all?
My card works now fine.
to comment 12: don't update betaN to betaN+M cd /etc/udev/rules.d/; mv 30*rpmnew 30-net.....
closing, see comment #14