Re: 3.0: rt2800usb(Kernel PANIC) vs. rt2780sta(GOOD/2.6.38)

[Larry Finger]

On 07/27/2011 06:33 PM, Justin Piszcz wrote:
> Hi,
>
> Kernel 3.0 (rt2800usb driver- horrid, and then it panics moments after, see
> picture below)
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=301 ttl=64 time=146 ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=302 ttl=64 time=274 ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=303 ttl=64 time=197 ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=304 ttl=64 time=115 ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=305 ttl=64 time=243 ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=306 ttl=64 time=265 ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=307 ttl=64 time=183 ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=308 ttl=64 time=201 ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=309 ttl=64 time=236 ms
>
> Then it crashes if you use the network:
> http://home.comcast.net/~jpiszcz/20110727/photo.JPG
>
> With the rt2870sta driver, the machine has been solid for months (2.6.38) with
> consistent low pings:
>
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=2 ttl=64 time=1.38 ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=3 ttl=64 time=0.520 ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=4 ttl=64 time=1.11 ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=5 ttl=64 time=0.573 ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=6 ttl=64 time=0.562 ms
>
> Can we please get the rt2870sta back into the kernel?

No. One of the reasons for deleting rt2870sta was that having it around was 
preventing the use of rt2800usb and it was not getting debugged.

This problem does not happen on my device.

Bus 001 Device 004: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless 
Adapter

That device is an unbranded USB stick that I got from Ebay for $2.59. My pings are

PING sonylap (192.168.1.50) 56(84) bytes of data.
64 bytes from sonylap (192.168.1.50): icmp_req=1 ttl=64 time=13.2 ms
64 bytes from sonylap (192.168.1.50): icmp_req=2 ttl=64 time=11.3 ms
64 bytes from sonylap (192.168.1.50): icmp_req=3 ttl=64 time=10.3 ms
64 bytes from sonylap (192.168.1.50): icmp_req=4 ttl=64 time=10.5 ms
64 bytes from sonylap (192.168.1.50): icmp_req=5 ttl=64 time=11.6 ms
64 bytes from sonylap (192.168.1.50): icmp_req=6 ttl=64 time=11.2 ms
64 bytes from sonylap (192.168.1.50): icmp_req=7 ttl=64 time=10.1 ms
64 bytes from sonylap (192.168.1.50): icmp_req=8 ttl=64 time=11.7 ms
64 bytes from sonylap (192.168.1.50): icmp_req=9 ttl=64 time=10.7 ms
64 bytes from sonylap (192.168.1.50): icmp_req=10 ttl=64 time=13.2 ms
64 bytes from sonylap (192.168.1.50): icmp_req=11 ttl=64 time=10.2 ms
64 bytes from sonylap (192.168.1.50): icmp_req=12 ttl=64 time=11.6 ms
64 bytes from sonylap (192.168.1.50): icmp_req=13 ttl=64 time=10.7 ms
64 bytes from sonylap (192.168.1.50): icmp_req=14 ttl=64 time=10.6 ms
64 bytes from sonylap (192.168.1.50): icmp_req=15 ttl=64 time=16.0 ms
64 bytes from sonylap (192.168.1.50): icmp_req=16 ttl=64 time=10.3 ms
^C
--- sonylap ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 15025ms
rtt min/avg/max/mdev = 10.194/11.499/16.075/1.502 ms

Performance is adequate, but not sparkling. Using tcpperf, I get 6 Mbps upload 
speed on an 802.11n network. The output of iwconfig says that I have a speed of 
121.5 Mbps set, but I'm only getting 1/10th of the transmit rate that I would 
expect for that setting.

@Ivo: I don't know if you saw this or not. From the photo, the kernel panics on 
a page fault in interrupt mode. The traceback is to rt2800usb_write_tx_desc+0x4, 
which seems to implicate the inline routine get_skb_frame_desc(). The offending 
statement is

return (struct skb_frame_desc *)&IEEE80211_SKB_CB(skb)->driver_data;

Any thoughts on how either the skb or the driver_data member might not be setup 
correctly?

Thanks,

Larry
--
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/