a5a5aa555oo / rtl8xxxu

9 stars 0 forks source link

firmware upload failure #2

Open onre opened 5 days ago

onre commented 5 days ago

Hi,

I had some issues with my cost-effective rtl8xxxu and came across this:

https://bbs.archlinux.org/viewtopic.php?id=297680

I had exactly the same problem as the original poster, applied the patch and it sort-of fixes the problem - I may have to modprobe the module a few times before the firmware sticks, so to say, but at least now it's possible to use the dongle. It does work reliably once I get the firmware into it.

The device ID for my dongle is 0bda:8179 and lsusb calls it a Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter.

Nov 20 15:08:16 tieteislaskin kernel: usb 1-1.2.4: rtl8xxxu_writeN: Failed to write block at addr: 1000 size: 0080 status -71
Nov 20 15:08:16 tieteislaskin kernel: usb 1-1.2.4: rtl8xxxu_writeN: Failed to write block at addr: 1100 size: 0080 status -71
Nov 20 15:08:16 tieteislaskin kernel: usb 1-1.2.4: rtl8xxxu_writeN: Failed to write block at addr: 1680 size: 0080 status -71
Nov 20 15:08:16 tieteislaskin kernel: usb 1-1.2.4: rtl8xxxu_writeN: Failed to write block at addr: 1080 size: 0080 status -71
Nov 20 15:08:16 tieteislaskin kernel: usb 1-1.2.4: rtl8xxxu_writeN: Failed to write block at addr: 1500 size: 0080 status -71

This is how a failed write looks like.

onre commented 5 days ago

Might be a timing issue. Adding 5 millisecond delay here makes it load a bit more consistently on 1st attempt, but still far from reliable. I wrote a small shell script loop to get some evidence, will post results soon.

onre commented 5 days ago

Based on a hunch I changed the code so that I can separately control the delay time before first and every subsequent rtl8xxxu_writeN() call in the loop - as in, before writing first block, wait 5 ms and after that wait 1 ms between all the remaining blocks.

Then I wrote a shell script loop to try out different combinations automatically.

As a summary, adding 5 ms delay before the first call and no delay for subsequent calls made it load the firmware every time.

In case you're interested (or want a good laugh), here are the results, shell scripts and the diff.

https://gist.github.com/onre/99c5656596469e9e2c464ed12f3acac1

dubhater commented 5 days ago

You found a fix, that's great!

I don't know why it needs a delay there. The official drivers don't have one.

What if you put the delay outside the loop? https://github.com/a5a5aa555oo/rtl8xxxu/blob/36bd19cd875350ef4276406fcb0bc05737a701ff/core.c#L2048

And if you change writeN_block_size in 8188e.c to 196, does it work without the added delay?

onre commented 5 days ago

With writeN_block_size == 196 it works without added delay. I unloaded & loaded the module about 10 times in a row and it works every time.