Bug 15123 (Driver) - The new Kernel has a big problem with driver rtl8187.
Summary: The new Kernel has a big problem with driver rtl8187.
Status: RESOLVED DUPLICATE of bug 14168
Alias: Driver
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-24 18:52 UTC by alessandrodv
Modified: 2010-03-01 19:09 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.30 and up
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description alessandrodv 2010-01-24 18:52:15 UTC
Hi there,

The driver rtl8187 has a problem with the new version of kernel. Actually i dont really know what the real matter is, but i tried to fix it and to workaround the problem,basically the only solution to use my WifiCard is to edit the file /etc/modprobe.conf and insert new algoritm line;

options mac80211 ieee80211_default_rc_algo=pid 

after that the wireless card works, but not at the maximum power.The strength of signal is low in comparison to driver made for Windows XP. Im sure that there must be a solution if the producer of the driver works on it. 


Regards

Alessandro
Comment 1 Hin-Tak Leung 2010-01-25 15:15:21 UTC
(In reply to comment #0)
> The driver rtl8187 has a problem with the new version of kernel...

You will have to be more specific than this - e.g. what version of the kernel are you using, and whether you are using wireless-testing/compat-wireless. In general, if you are not using the latest release kernel or a recent wireless-testing/compat-wireless, I'd suggest you go and give that a try first. If you are using a distro-distributed kernel, you should contact your distro's bugzilla first.

The signal/power field of the rtl8187 driver has not meaning compared to windows XP's - it is just a number relative to itself, higher number means better connectivity to itself. Comparison of that number to other platform/hardware/driver has no meaning.

You should give compat-wireless a try first, before filing such vague reports.
(http://linuxwireless.org/en/users/Download )
Comment 2 alessandrodv 2010-01-25 19:08:14 UTC
Kernel version : 2.6.30 and up, sorry,but that means 2.6.30, 2.6.31 and the latest stable version 2.6.32.5 , i have tried with all of them.

Im sure about that, becouse i have tested the latest linux-wireless-driver, and the best performances to take advantage of my WirelessCard is by using kernel <= 2.6.29. 

Now im using 2.6.31.5, it works fine but it doesnt compare to the kernel 2.6.29 and the older ones. 

I want to specify that i have tested the latest version of the kernel compiled by me in Slackware, with all the drivers included in that kernel, and the problem is still there. 

Tell me what further information i need to tell you to make a good report.

Ciao
Comment 3 Hin-Tak Leung 2010-01-25 19:39:45 UTC
(In reply to comment #2)
> Kernel version : 2.6.30 and up, sorry,but that means 2.6.30, 2.6.31 and the
> latest stable version 2.6.32.5 , i have tried with all of them.

> I want to specify that i have tested the latest version of the kernel
> compiled
> by me in Slackware, with all the drivers included in that kernel, and the
> problem is still there. 

Wireless-testing/compat-wireless is *ahead* of the release kernel. Since your problem appears to be rate-determining algorithm related and related to pid and minstrel, you probably could also try iwconfig rate <somefixrate> (or the iw equivalent); there are a few minstrel-related fixes/changes in compat-wireless/wireless-testing which is not in the release kernel - you should give compat-wireless/wireless-testing a try and see if that works well, and if it does, we can try pushing the minstrel-related change to Linus.
Comment 4 Errico Prota 2010-01-25 23:09:08 UTC
Hi, I think that it's a duplicate of bug http://bugzilla.kernel.org/show_bug.cgi?id=14168.

It's a minstrel algorithm problem with weak signals < 65-70 dBm

Any news about ?
Comment 5 John W. Linville 2010-03-01 19:09:12 UTC

*** This bug has been marked as a duplicate of bug 14168 ***

Note You need to log in before you can comment on or make changes to this bug.