wireless rtl8192X cards kernel 3.10.X not working
 

Something went wrong from 3.9 to 3.10 :(

https://bugzilla.kernel.org/show_bug.cgi?id=60713

here other people reported the same issue and there are some logs:

https://bugs.archlinux.org/task/36292

I run two pcs both with the same wireless card so for now I'll have to hold from using -current or downgrade the kernel.

Does this include the usb version? I have just bought three. I could not get the rtl8192cu to work on 3.10 compiled for x86. It does work on 3.6 compiled for arm though, which is where I tried first. Then I tried downgrading x86 to 3.6, and all intermediate versions. I had it working briefly, but I didn't have time to sort it all out. The problem I have is similar as in the report, it will associate, but frequently disconnect. I have no idea why it works on arm just fine from the same location. Anyone have pointers? I would like to upgrade my machines to 'n' wireless, but put it off because of this problem.

I've never tried that version, both my cards are rtl8192se and have pretty much always worked fine but for a few iccups (I used to lose connectivity every few hours on slackware 14, never figured out why)

It is not Slackware specific. I tried even over openSUSE 12.3 (kernel 3.7.0) and even an customized ... Android 4.0.3 (kernel 3.0.8). Nothing.

Those who have balls are free to load their guns and to walk slowly to Realtek Co. headquarters... ;)

Check the kernel configuration settings thoroughly. Often there is a module that may have been deprecated that may need to be reactivated and rebuilt for, or it might be under the incomplete, staging, and skeleton drivers sections.

So I think I got lucky. It appears that 3.11rc1 has a patch fixing how the transmit power was being set.
https://git.kernel.org/cgit/linux/ke...80524d7787d688
This patch also went into 3.10.2.

Apparently this bug has always been in rtl8192cu there, and was going to be fixed in 3.1rc1, but then it accidentally got reverted. I tested 3.11rc5, and everything is good so far (using the device to write this message).

As for why the ARM device was not affected, somebody slipped the realtek alternate driver into the raspberry pi tree :( This also shows me why it would have been difficult to bisect.

I don't see any movement on problems with rtl8192se, but if you believe this is a regression, you might be able to bisect it.