[rt2x00-users] [bugzilla-daemon at bugzilla.kernel.org: [Bug 42828] rt2800pci unstable - chokes after too much I/O]
Francisco Pina Martins
f.pinamartins at gmail.com
Mon Oct 22 02:12:46 AEDT 2012
On Sun, 2012-10-21 at 11:02 +0200, Andreas Hartmann wrote:
> Francisco Pina Martins wrote:
> > Here is my update on this:
> > I cannot boot with the patched kernel - I get a kernel panic at about 9
> > secs during boot.
> Stanislaws patch hangs the machine for me, too. See my other post.
Guess it's a no-go then.
> > I have 2 more computers that connect to my routers frequently and without
> > issue:
> > One has an intel 4950 wireless card (currently using kernel 3.6.2, and
> > never had any issues);
> > The other one also has a ralink wireless card (not sure about the model
> > though - i can check later if it is relevant),
> It is relevant. Which kernel version? Which driver?
Wireless card (it's USB in fact, must be on an internal port): Realtek
Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network Adapter
Kernel driver: rtl8187
Kernel version: Linux Nucha-Laptop 3.2.0-31-generic #50-Ubuntu SMP Fri
Sep 7 16:16:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Turns out it's not ralink after all, but rather a realtek (I always
confuse them)... Sorry about the confusion. Nothing like checking it out
> > but that one is running
> > ubuntu 12.04, which has an older kernel so I wouldn't see the bug anyway.
> Please don't think all users would use Ubuntu :-). Please add
> the complete kernel version!
By no means! =-) I just wasn't sure what the kernel version in there was
so I just wrote what I knew of the top of my head.
> One more thing:
> The problem usually only comes up if the connection is bad (e.g. high
> distance or in common bad receiving conditions).
> You wrote, that the other devices wouldn't show the behaviour you
> described for your 2872 chipset with your AP. This doesn't prove anything.
> Are they located at the same place or maybe at a place where the
> receiving conditions are even worse?
> Could you please test it with several bad receiving conditions using
> netperf (about 30 minutes - see below) to get resilient behaviour.
All of my wireless equipped machines are laptops, that get used in
various different places around the house with varying signal quality.
None of them exhibits this behaviour except my netbook (which uses
rt2800pci). This occurs both under poor and good (1,5 - 2m of distance
from the AP with no obstacles inbetween them) receiving conditions.
I will attempt to test using netpref later today.
> > I have applied the patch using "patch -Np1 -l -i ap.patch".
> Where did you apply the patch? Do you use compat-wireless?
Just the same way I applied the previous patches posted to the kernel
bugzilla. I am using vanilla kernel, and no compat wireless (I did some
tests with it when I first became aware of the problem, but it didn't
work so I abandoned it - there is nothing left of it in my system).
> BTW: Testing is much easier and more reliably using netperf. This tool
> is very good to test the quality / throughput / behaviour of a connection!
> Running netperf is easy. You have to install it on two machines. These
> are the machines between the stream should be tested. In your case: the
> machine before the AP and the machine behind the AP.
> You start "netserver" on the machine behind the AP and the following
> script on the machine before the AP:
> dest="[the name or ip of the machine behind the AP]"
> while true ; do
> netperf -t TCP_MAERTS -H $dest
> netperf -t TCP_STREAM -H $dest
> netperf -t TCP_SENDFILE -H $dest
> You can stop this script with CTRL-C
> At the same time you may run xosview +n to get an actual view of the
> network throughput. This enables you to see even short breaks e.g. The
> Throughput as shown by xosview +n should be stable and the throughput
> shown by netperf should be constantly at least 8MB/s (until 16 MB/s in
> one direction) in both directions (MAERTS vs. STREM/SENDFILE) with
> 2.4GHz / 40MHz according netperf (not xosview - value of xosview will be
> (much) higher).
This sounds quite simple. I will get back to you when I have these
results to show.
> kind regards,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users