Re: if_rum dies on transmit...

On Tuesday 29 September 2009 21:30:26 Lawrence Stewart wrote:
> Poul-Henning Kamp wrote:
> > Has anybody else seen if_rum die when you try to transmit a file over
> > a TCP connection ?
> >
> > If I try to print across the network, upload a file with ftp or anything
> > else of that general tenor, if_rum seems to hang the output queue and
> > stops transmitting packets.
>
> Yes I see the same thing with my D-LINK DWA-110 USB stick which shows up
> as a rum device. According to Sam who had a quick look at the issue for
> me when I first noticed it, the rum driver is in pretty bad shape and
> should be expected to be flaky.
>
> I don't think the issue is specific to TCP connections though. I think
> it's related to timing of inbound/outbound packets. I would frequently
> trigger it when fetch ran as part of a port update, but it happened at
> other seemingly random times as well. I suspect that TCP incoming data
> and the outgoing ACKs might tickle the (locking? state machine?) bug
> more effectively than other traffic mixes.
>
> > Restarting wpa_supplicant mostly resolves the issue, but it does not
> > on its own discover the problem.
> >
> > According to tcpdump(8), packets are still received.
> >
> > Any ideas ?
>
> I've never done any driver work so I have no idea how to resolve the
> issue, and just live with it randomly crapping out on me. I found
> restarting wpa_supplicant to be a hit and miss way to fix it. The
> easiest way to avoid panics or re occurrences was to pull the dongle,
> wait 5 secs, reinsert and then recreate the wlan dev and start
> wpa_supplicant.

During testing I've seen similar issues. The rum hardware is not always 
reliable, but the kernel shouldn't panic ...

--HPS