[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
Sun Oct 21 08:04:12 AEDT 2012

Here is my update on this:
I cannot boot with the patched kernel - I get a kernel panic at about 9
secs during boot.

I have 2 more computers that connect to my routers frequently and without
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), but that one is running
ubuntu 12.04, which has an older kernel so I wouldn't see the bug anyway.

I have applied the patch using "patch -Np1 -l -i ap.patch". All 3 "hunks"
were successfully applied. I had to use "-l" swith or they would fail. I
blame gmail for messing up the indentations.

Where do I go from here?


On 20 October 2012 07:34, Andreas Hartmann <andihartmann at 01019freenet.de>wrote:

> Francisco Pina Martins wrote:
> [...]
> > The AP is a  Belkin F5D8233-4-v1(01A) using the latest available
> http://wikidevi.com/wiki/Belkin_F5D8233-4_v1
> -> this device uses a rt2860 chip - probably the same or similar one
> which I'm using for my AP.
> -> Could it possibly show the same "handling behavior" here and
> if it is handled the same way (-> let the other do the job), it most
> probably will slow down or even break the connection :-(.
> This could explain, why my 2860 device works fine as STA with or
> w/o Stanislaws patch: because WAP610N (AP) does the job. The WAP610N
> uses a MtW8171 chip according
> http://www.wikidevi.com/wiki/Linksys_WAP610N which most probably
> doesn't show this problem.
> I'm writing this, because Helmut already mentioned that this workaround
> would not work with intel STA (which most probably has the same
> problem - don't know, if all intel STA are affected or just some and I
> don't know, if it is limited to the linux client or not).
> If Stanislaw or any other person can't find a better solution as the
> workaround we have now, I would try to shrink the workaround to AP mode
> and / or probably to 2860 chip (I can't estimate the latter).
> Is there a way to check if the 2860 device behaves the same in STA
> mode as in AP mode? Most probably it would need an air trace I
> think :-(.
> Kind regards,
> Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/attachments/20121020/2c2d9f71/attachment-0002.html>

More information about the users mailing list