Thomas Rosenkranz wrote:
> 0bda:819a RTL8188CUS WLAN doesn't work out of the box in downstream
> and upstreamkernel
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1102179
This should go to <[email protected]>
Try:
# modprobe rtl8192cu
# echo "0bda 819a" > /sys/bus/usb/drivers/rtl8192cu/new_id
# dmesg (see output)
On 02/06/2013 08:05 PM, Larry Finger wrote:
> Please install the attached patch, and retry the above method. I fixed the probe function to get rid of the oops. If the device is really foreign, the process that writes new_id will not finish until
> the device is unplugged; however, the rest of the system is chugging along.
I tried the patch. And now, rtl8192cu doesn't break the kernel.
But it should go out when an unknown chip/rf is detected,
instead of trying to configure the unknown_device.
rtlwifi: reg 0xf0, usbctrl_vendorreq TimeOut! status:0xffffffe0 value=0x0
rtl8192cu: Chip version 0x10 <<<<<------WTF???
rtlwifi: reg 0xa, usbctrl_vendorreq TimeOut! status:0xffffffe0 value=0x0
rtlwifi: reg 0xfe66, usbctrl_vendorreq TimeOut! status:0xffffffe0 value=0x0
rtlwifi: reg 0xfe67, usbctrl_vendorreq TimeOut! status:0xffffffe0 value=0x0
rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1
Tested-by: Xose Vazquez Perez <[email protected]>
On 01/26/2013 04:07 PM, Xose Vazquez Perez wrote:
> Thomas Rosenkranz wrote:
>
>> 0bda:819a RTL8188CUS WLAN doesn't work out of the box in downstream
>> and upstreamkernel
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1102179
>
> This should go to <[email protected]>
>
> Try:
> # modprobe rtl8192cu
> # echo "0bda 819a" > /sys/bus/usb/drivers/rtl8192cu/new_id
> # dmesg (see output)
Please install the attached patch, and retry the above method. I fixed the probe
function to get rid of the oops. If the device is really foreign, the process
that writes new_id will not finish until the device is unplugged; however, the
rest of the system is chugging along.
If 0bda:819a works with rtl8192cu, let me know, and I'll update the USB device
table.
Larry
On 02/06/2013 02:03 PM, Thomas Rosenkranz wrote:
> Sorry for aksing back.
> 1. You mean I should get the kernel clean of the realtek driver first
> to prevent a crash during patching? Cause unplugging is no option for
> a onboard device.
> 2. I have no idea what to do with the patching file and couldn't find
> any good instructions with google. "man patch" doesn't make me smarter
> at all
Put the patch in the directory where the arch, block, crypto, drivers, and so
forth directories are located. Then run the command
patch -p1 < 0001-......patch
After that, run "make" followed by "sudo make modules_install install". If your
distro is reasonable, that will give you a new entry in your boot menu.
Larry
Sorry for aksing back.
1. You mean I should get the kernel clean of the realtek driver first
to prevent a crash during patching? Cause unplugging is no option for
a onboard device.
2. I have no idea what to do with the patching file and couldn't find
any good instructions with google. "man patch" doesn't make me smarter
at all
2013/2/6 Larry Finger <[email protected]>:
> On 01/26/2013 04:07 PM, Xose Vazquez Perez wrote:
>>
>> Thomas Rosenkranz wrote:
>>
>>> 0bda:819a RTL8188CUS WLAN doesn't work out of the box in downstream
>>> and upstreamkernel
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1102179
>>
>>
>> This should go to <[email protected]>
>>
>> Try:
>> # modprobe rtl8192cu
>> # echo "0bda 819a" > /sys/bus/usb/drivers/rtl8192cu/new_id
>> # dmesg (see output)
>
>
> Please install the attached patch, and retry the above method. I fixed the
> probe function to get rid of the oops. If the device is really foreign, the
> process that writes new_id will not finish until the device is unplugged;
> however, the rest of the system is chugging along.
>
> If 0bda:819a works with rtl8192cu, let me know, and I'll update the USB
> device table.
>
> Larry
>
On 02/06/2013 05:03 PM, Xose Vazquez Perez wrote:
> On 02/06/2013 08:05 PM, Larry Finger wrote:
>
>> Please install the attached patch, and retry the above method. I fixed the probe function to get rid of the oops. If the device is really foreign, the process that writes new_id will not finish until
>> the device is unplugged; however, the rest of the system is chugging along.
>
> I tried the patch. And now, rtl8192cu doesn't break the kernel.
>
> But it should go out when an unknown chip/rf is detected,
> instead of trying to configure the unknown_device.
No fooling; however, the only way it can tell if the device is known is by
seeing those USB timeouts. It took a very long time before the probe routine
gets control again. I don't know any way to fix that.
Larry