Re: [PATCH] rt2x00: rt2800: fix zeroing skb structure

[Justin Piszcz]

On Wed, 3 Aug 2011, Stanislaw Gruszka wrote:

> On Wed, Aug 03, 2011 at 01:44:10PM -0400, Justin Piszcz wrote:
> > Tested that patch:
> > 
> > 1. The driver no longer automatically loads, I had to manually modprobe it.
> This must be some other problem not related with patch.
>
> > 2. After loading, I get this (keep getting these)
> > 
> > [  384.054538] phy0 -> rt2800_txdone: Error - Data pending
> > [  384.072773] phy0 -> rt2800_txdone: Error - Data pending
> > [  384.096545] phy0 -> rt2800_txdone: Error - Data pending
> > [  384.117301] phy0 -> rt2800_txdone: Error - Data pending
> > [  384.537586] phy0 -> rt2800_txdone: Error - Data pending
> > [  384.555716] phy0 -> rt2800_txdone: Error - Data pending
> > [  384.573903] phy0 -> rt2800_txdone: Error - Data pending
> > [  384.599465] phy0 -> rt2800_txdone: Error - Data pending
> > [  384.618523] phy0 -> rt2800_txdone: Error - Data pending
> You can remove line
>
> ERROR(rt2x00dev, "Data pending\n");
>
> from rt2800_txdone to stop seeing this. It's kinda interesting
> how frequent this happens.
>
> > No crash yet, but bad ping again too (always with the rt2800usb) driver:
> > 
> > 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=1 ttl=64 time=53.1 ms
> > 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=2 ttl=64 time=285 ms
> > 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=3 ttl=64 time=89.6 ms
> > 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=4 ttl=64 time=120 ms
> > 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=5 ttl=64 time=42.2 ms
> > 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=6 ttl=64 time=156 ms
> > 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=7 ttl=64 time=77.2 ms
>
> I think patch could have site effect to not run tx queue while we have pending
> data on it. Do you have such ping times always (i.e. after a 5 minutes, 10
> minutes, 20  ... ) or just randomly?
>
> Stanislaw

Hi,

So the patch is good but did not solve the problem, after several hours, the
main USB wireless stick went off-line:

Aug  3 22:02:16 atom kernel: [23424.597037] phy0 -> rt2800_txdone: Error - Data pending
Aug  3 22:02:16 atom kernel: [23424.597168] phy0 -> rt2800_txdone: Error - Data pending
Aug  3 22:02:16 atom kernel: [23424.598047] phy0 -> rt2800_txdone: Error - Data pending
Aug  3 22:02:16 atom kernel: [23424.598411] phy0 -> rt2800_txdone: Error - Data pending
Aug  3 22:02:16 atom kernel: [23424.599414] phy0 -> rt2800_txdone: Error - Data pending
Aug  3 22:02:16 atom kernel: [23424.599549] phy0 -> rt2800_txdone: Error - Data pending
Aug  3 22:02:16 atom kernel: [23424.599664] phy0 -> rt2800_txdone: Error - Data pending
Aug  3 22:47:12 atom kernel: [26120.279774] wlan0: deauthenticated from hidden (Reason: 2)
Aug  3 22:47:13 atom kernel: [26121.728581] wlan0: authenticate with hidden (try 1)
Aug  3 22:47:13 atom kernel: [26121.730109] wlan0: authenticated
Aug  3 22:47:13 atom kernel: [26121.745088] wlan0: associate with hidden (try 1)
Aug  3 22:47:13 atom kernel: [26121.750738] wlan0: RX ReassocResp from hidden (capab=0x431 status=0 aid=2)
Aug  3 22:47:13 atom kernel: [26121.750746] wlan0: associated
Aug  3 22:47:14 atom kernel: [26121.845641] wlan0: Wrong control channel in association response: configured center-freq: 2417 hti-cfreq: 2437  hti->control_chan: 6 band: 0.  Disabling HT.


( at this point wlan0 is offline )

$ ssh atomw
ssh: connect to host atomw port 22: No route to host

BUT: It did not crash the kernel; however, interestingly (I have two of these
sticks), now phy1 starts showing the same symptoms wlan0 had (phy0).

Aug  3 22:49:46 atom kernel: [26274.088150] phy1 -> rt2800_txdone: Error - Data pending
Aug  3 22:49:46 atom kernel: [26274.147869] phy1 -> rt2800_txdone: Error - Data pending
Aug  3 22:49:46 atom kernel: [26274.152743] phy1 -> rt2800_txdone: Error - Data pending

Are these sticks just incomptabile with the rt2800usb driver?

Justin.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/