[Maverick] r8192s_usb firmware not found

[Stefan Bader]

Binary package hint: linux-firmware

SRU justification:

Impact: Firmware file not found because the driver is looking for a different path.

FIX: Create a softlink for the directory.

Testcase: Inserting a wireless dongle which uses this driver.

---

The driver is looking for its firmware in RTL8192SU/ which is not present, but RTL8192SE/ contains a firmware file with the name the driver is looking for. And at least with the wireless dongle I was testing with, I could successfully authenticate to my AP after creating a link to the other directory. I assume the difference between the SE and SU drivers is just whether the device is PCI or USB. But apparently the FW is working for the SU as well.

I cannot verify whether this is true or not for Natty, as the HW I can test with is there using the rtl8712 module which has a built in firmware code.

[Martin Pitt (pitti)]

Accepted linux-firmware into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux-firmware - 1.38.5

---------------
linux-firmware (1.38.5) maverick-proposed; urgency=low

  [ Stefan Bader ]

  * Pull firmware for ath9k-htc from Natty
    The ath9k-htc module is contained in the compat-wireless-2.6.37
    backports for Lucid and Maverick. However the firmware for that module
    is missing.
    - LP: #721393

  * Add link for RTL8192SU firmware
    Create a link from RTL8192SU -> RTL8192SE as testing proved the same
    firmware works for both.
    - LP: #721356

linux-firmware (1.38.4) maverick-proposed; urgency=low

  * iwlwifi: Updated iwlwifi-6000g2a-5.ucode and iwlwifi-6000g2b-5.ucode to 17.168.5.2
    17.168.5.2 fixes a showstopper issue that it can't connect to a 5G hidden SSID.
    -LP: #716832
 -- Tim Gardner <email address hidden> Fri, 18 Feb 2011 10:58:40 -0700

[Zeno Izen (zenoizen)]

" * Add link for RTL8192SU firmware
    Create a link from RTL8192SU -> RTL8192SE as testing proved the same
    firmware works for both.
    - LP: #721356"

This change appears to have affected my EDIMAX EW-7811Un adaptor (RTL8188CUS chipset). Seeks, but can't find the network.

Problem is somewhat over my head, but I'm trying to figure it out.

[Stefan Bader (smb)]

It is not completely clear to me in what exact way it did affect that adapter (worked before and now as described or was not working and is sort of half working now). The only thing done really was to provide a link in /lib/firmware that points now to another directory in there. The question if the adapter has been working before would be whether you ever took a firmware and added it to /lib/firmware manually. Or what happens if you rename or delete that link (what are the startup messages in dmesg). Also what is the exact usb id of that adapter.

[Zeno Izen (zenoizen)]

First, thank you for the reply. Second, I've installed the windows driver with ndiswrapper so the adaptor is working now, but I wouldn't mind knowing exactly what went wrong.

Meanwhile, no it doesn't entirely make sense that the new link would have caused the failure, but the only other possibilities (that I can think of) are that something else in that day's update caused the problem, or that I did something in the course of installing/trying to figure out Samba--which was really the only thing I think I did on that machine during that uptime. I'm sure I didn't manually open /lib/firmware at any time.

In any case, I thought it could possibly be helpful to someone else to have the event on record.

As to the exact effect on the adaptor: It was working normally, connecting automatically at log in, until the failure which came at the first reboot after the update. At that point the wireless indicator on the panel would "pulse" as if trying to find the signal, and then eventually give up.

Just for fun I'm going to uninstall ndiswrapper and see what happens when I disable the pointer. If I figure out anything stronger than a hypothesis, I'll post it here.

The usb ID is 7392:7811.

Thanks again for your time. No need to reply on my behalf. From here it's just me learning something new.

-z

[Stefan Bader (smb)]

Just one thought that may be useful. Maybe there always were two driver modules that claimed to handle that adapter (could be ndiswrapper or something else). Before the firmware update the realtek driver would not load because the firmware was missing. This allows the next driver to try. But with the firmware link in place, the realtek driver loads, even if it does not work well...

[Zeno Izen (zenoizen)]

@SB:

Yes, that's more than plausible. More even, I can't reproduce the problem. So I'm a ways from knowing exactly what happened.

Still, this event can probably be ignored. If any other users have the same problem I'd be surprised. I'll still be tinkering with it, though, because I'd like to understand drivers/modules better.