regarding to:
0bda:819a RTL8188CUS WLAN doesn't work out of the box in downstream
and upstreamkernel
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1102179
[email protected] wanted me to test in different system the
following commands:
# sudo su
# modprobe -v rtl8192cu
# echo "0bda 819a" > /sys/bus/usb/drivers/rtl8192cu/new_id
(# dmesg (log output))
then X crashes with the echo command and I see the dmesg output
I can't get back to X and I'm not able to reach any tty-shell.
Tested with 64bit-isos Ubuntu 12.04 / 12.10 / Fedora 17 / Fedora
18beta and upstream kernel linux-image-3.8.0-030800rc4-generic
On 02/05/2013 04:37 PM, Xose Vazquez Perez wrote:
> On 02/05/2013 10:54 PM, Larry Finger wrote:
>
>> Yes, but not a bug for the devices that it is supposed to support! No one ever says that their driver will support *future* devices! As I said earlier, there are newer versions of the RTL8188C chip
>> that requires different programming, which may be the cause of the problem. On the other hand, the chip change did not cause a crash in rtl8192ce. I just didn't work very well. As I have no such
>> device, I cannot test any changes; therefore, I will not make them. If you want to write patches that let that device work with the kernel driver, I will be happy to review them.
>
> Then, remove the "new_id" facility of the driver.
>
> *Or* fix the driver. rt2x00 handles correctly any
> kind of unknown device.
The attached patch will fix the oops when a foreign new_id is inserted. I will
be submitting it soon.
Larry
Larry Finger wrote:
> You are likely crashing more than X.
>
> That is very good evidence that rtl8192cu is *NOT* the correct driver for that
> device. As I recall Xose found that USB ID in a Windows driver, but who knows
> what changes are inside that driver?
>
> I have what I think is a complete collection of Realtek drivers for Linux, and
> none of them have 0bda:819a as a USB ID.
He's using the RTL8188C_8192C_USB_linux driver.
Therefore, there are only two possibilities:
- it's a 8192_du device, or
- it's a 8192_cu device, and there is a bug in rtlwifi.
Thomas, could you put "dmesg" output after loading 8192cu.ko (realtek driver) ?
and "lsusb -v -d 0bda:819a" output.
On 02/05/2013 10:54 PM, Larry Finger wrote:
> Yes, but not a bug for the devices that it is supposed to support! No one ever says that their driver will support *future* devices! As I said earlier, there are newer versions of the RTL8188C chip
> that requires different programming, which may be the cause of the problem. On the other hand, the chip change did not cause a crash in rtl8192ce. I just didn't work very well. As I have no such
> device, I cannot test any changes; therefore, I will not make them. If you want to write patches that let that device work with the kernel driver, I will be happy to review them.
Then, remove the "new_id" facility of the driver.
*Or* fix the driver. rt2x00 handles correctly any
kind of unknown device.
usb 2-1.5: new high-speed USB device number 5 using ehci_hcd
usb 2-1.5: New USB device found, idVendor=0bda, idProduct=8176
usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.5: Product: 802.11n WLAN Adapter
usb 2-1.5: Manufacturer: *Realtek*
usb 2-1.5: SerialNumber: 00e04c000001
# echo "0bda 8176" > /sys/bus/usb/drivers/rt2800usb/new_id
phy2 -> rt2800_init_eeprom: Error - Invalid RT chipset 0x0000 detected.
phy2 -> rt2x00lib_probe_dev: Error - Failed to allocate device.
and it doesn't panic. The system works flawlessly after that, see:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/net/wireless/rt2x00/rt2800lib.c;h=197b4466a5d2a44378f998fdefa2c221ae6124c6;hb=HEAD#l4798
rtlwifi also can do the same, -ENODEV in rtl8192cu/mac.c
rtl92c_read_chip_version() at switch(rtlhal->version) default:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/net/wireless/rtlwifi/rtl8192cu/mac.c;h=32ff959a0251bdf36cb69122b55a6fc438e3bdd0;hb=HEAD#l127
In Windows it calls "Realtek RTL8188CUS WLAN USB Slim Solo"
2013/2/5 Larry Finger <[email protected]>:
> On 02/05/2013 01:55 PM, Xose Vazquez Perez wrote:
>>
>> On 02/05/2013 12:00 AM, Thomas Rosenkranz wrote:
>>
>> Larry, are you able to identify the chip of that device
>> with the 8192cu output ?
>>
>> what should he do ? open the device to see the chip ??
>
>
> What difference does it make what chip it has? It is obviously some flavor
> of RTL8188CU/RTL8192CU that is different enough that it does not work with
> the kernel version of rtl8192cu. A few months ago, I ran across a new B-CUT
> RTL8188CE that took new programming for rtl8192ce, and I suspect this device
> also has the B-CUT chip.
>
> The crash on unloading is a known fault of the vendor driver. It happens
> with devices that work OK with the standard rtl8192cu. I have no desire to
> find out what causes the crash.
>
> If someone wants to supply me with a sample of this 0bda:819a device, I'll
> make it work in the kernel. I have no desire to try to purchase one on my
> own.
>
> Larry
>
>
>
On 02/06/2013 12:45 AM, Larry Finger wrote:
>> Then, remove the "new_id" facility of the driver.
>>
>> *Or* fix the driver. rt2x00 handles correctly any
>> kind of unknown device.
>
> The attached patch will fix the oops when a foreign new_id is inserted. I will be submitting it soon.
> Index: wireless-testing-new/drivers/net/wireless/rtlwifi/usb.c
> ===================================================================
> --- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/usb.c
> +++ wireless-testing-new/drivers/net/wireless/rtlwifi/usb.c
> @@ -977,6 +977,9 @@ int rtl_usb_probe(struct usb_interface *
> rtl_dbgp_flag_init(hw);
> /* Init IO handler */
> _rtl_usb_io_handler_init(&udev->dev, hw);
> + if (!rtlpriv->cfg || !rtlpriv->cfg->ops ||
> + !rtlpriv->cfg->ops->read_chip_version)
> + return -ENODEV;
> rtlpriv->cfg->ops->read_chip_version(hw);
> /*like read eeprom and so on */
> rtlpriv->cfg->ops->read_eeprom_info(hw);
>
How about pci devices(rtlwifi/pci.c) ?
thank you.
On 02/04/2013 11:50 AM, Thomas Rosenkranz wrote:
> regarding to:
> 0bda:819a RTL8188CUS WLAN doesn't work out of the box in downstream
> and upstreamkernel
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1102179
>
> [email protected] wanted me to test in different system the
> following commands:
>
> # sudo su
> # modprobe -v rtl8192cu
> # echo "0bda 819a" > /sys/bus/usb/drivers/rtl8192cu/new_id
> (# dmesg (log output))
>
> then X crashes with the echo command and I see the dmesg output
> I can't get back to X and I'm not able to reach any tty-shell.
>
> Tested with 64bit-isos Ubuntu 12.04 / 12.10 / Fedora 17 / Fedora
> 18beta and upstream kernel linux-image-3.8.0-030800rc4-generic
You are likely crashing more than X.
That is very good evidence that rtl8192cu is *NOT* the correct driver for that
device. As I recall Xose found that USB ID in a Windows driver, but who knows
what changes are inside that driver?
I have what I think is a complete collection of Realtek drivers for Linux, and
none of them have 0bda:819a as a USB ID.
Larry
Larry