Bug Description

This card works intermittently and follows a set sequence.

1. On 1st boot the card comes up as disabled.
2. On second boot the card comes up as enabled but will not connect to the wireless network, although it can see the network.
3. On third boot the card works O.K.

Peter, you've reported this as a bug on 'Launchpad', which is the bug tracking software, rather than on 'Ubuntu' which I presume is what you intended. I've made a new task on Ubuntu for you, and and closing the 'Launchpad' task (because Launchpad is a website, not part of Ubuntu).

On 27/01/11 19:54, Robert Collins wrote:
> Peter, you've reported this as a bug on 'Launchpad', which is the bug
> tracking software, rather than on 'Ubuntu' which I presume is what you
> intended. I've made a new task on Ubuntu for you, and and closing the
> 'Launchpad' task (because Launchpad is a website, not part of Ubuntu).
>
> ** Also affects: ubuntu
> Importance: Undecided
> Status: New
>
> ** Project changed: launchpad => null
>
> ** Changed in: null
> Status: New => Invalid
>

Latest updates seem to have solved the 'device not ready' problem on first boot (although this still happens on resume from suspend). However I am still getting problems with not connecting properly, see attached file.

I get intermittent network with my Samsung N150. The wireless mostly connects (not always), but then will go very slow or stop transmitting or receiving traffic, then sometimes comes back and then stops and so on.

Another problem is that the driver doesn't see channels 12 or 13, though I'm in the UK and it should see them. There are several APs around here all sending "GB " in their beacon frames. Dmesg includes these messages:

The problem is still here. The only way to stop the log files being flooded with:
"rtl819xE:No more TX desc@6, ring->idx = 0,idx = 0,52"
is to use NDISwrapper and install the Window XP driver in NDISwrapper.

I have Lubuntu 11.10 32-bit installed on my Samsung NB30 and I had a "kernel panic" after install because of the buggy Realtek rtl819xE WLAN driver!

Rather than rebooting, I can get the wireless working by removing and reinserting the driver until it can connect. Run the following as root:

modprobe -r r8192e_pci; modprobe r8192e_pci

If it doesn't connect, check the network status in the bar at the top of the screen. If it says "device not connected", re-run the commands. Repeat until it connects. It seems to take 2-3 times on average for me.

Would it be possible for you to test the latest upstream kernel? It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the release candidate kernel versus the daily build. Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the others). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Tested this bug on 3.0.0-12-generic and on upstream 2011-10-24-oneiric. No great
difference between the two. Both seem to have lost the pattern of 2 fails followed
by successful connection.

My tests simply involved booting the machine, checking
wireless status, logging, shutting down. By success, I mean booted with wireless working
and fail, booted with device not ready and no wireless connection.

With 3.0.0-12-generic I had 2 fails followed by multiple successes.

With upstream release I had 3 fails, then single success, four fails, five successes
and 14th boot failed.

I have attached archive of log files from dmesg for all cases.

Note, I am, with both configurations, getting kernel panics causing the machine to
hang. This mostly occurs when the machine is shutting down. I'm not sure how to capture
the logs of these panics. If they are of interest you can let me know and perhaps suggest
method of capture and I'll happily follow up.

I've attached a patch which changes some of the time-outs for enabling the CPU and uploading firmware to the wireless adapter. This seems to make things better on my N150, but doesn't 100% resolve the problem.

I've added more debug to the driver as well. Maybe that will help track down the issue.

It looks like the driver queues up a bunch of packets to send the firmware to a CPU on the wireless adapter. And then it polls the adapter to see if it's ready. I set the firmware-loading time-out to 10 seconds at one point, but it still seemed to fail. It seems like there is a race between firmware set-up and something else in the driver.

The 3.2 kernel from comment #28 seems to be working a lot better. My wireless connects on log-in without any issues, and seems stable for 8+ hours. I've rebooted a few times over the past 2 days, and the wireless works without issues.

I downloaded the 3.2 kernerl from the link in comment #28, and installed it like this:

Peter Cooper, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command in the development release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. As well, please comment on which kernel version specifically you tested.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream', and comment as to why specifically you were unable to test it.