On Thu, 15 Mar 2007, Michael Schmitz wrote:
> > > and the transmit timeout handling, but the driver has been largely > > > rewritten. I'll have to look at it some more to see what might be > > > used. > > > > I think that the bug that bit Wouter's 950 was a race between the tx > > code and the interrupt handler (though it was a while ago that I > > looked at this). If so, the 2.6 version could need a complete > > back-port, since both algorithms changed significantly to get > > zero-copy in the present version (and to adopt the DMA API, which > > isn't in 2.2). There is probably a quicker fix. > > If you could remember what the nature of the race was, I could perhaps > find a way to prevent it. Note that the transmit function now only stops > the queue if the ring is full; that may be important. When I look at the 2.2 code now, I'm immediately suspicious of the interaction between sonic_send_packet() and sonic_interrupt(), with respect to lp->tx_full, lp->cur_tx, lp->dirty_tx and lp->tx_laddr[]. Reason being, there is no mutual exclusion to prevent interrupt handler from interfering with the other routine. Still, it isn't clear to me how this leads to "Warning: kfree_skb passed an skb still on a list (from 000e4416)." I don't know how these lists work. Does the address 000e4416 tell you anything? -f -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
