> > Furthermore, I noticed that the first thing that is called after a "hang"
> > is cpc_queue_xmit (i.e., the TX function to which the hard_start_xmit
> > pointer in the device structure points to). My question is: what could
> > cause this function not to be called immediately by the network subsystem
> > as soon as TX data is available from the application? Since I could see
>
> If the driver previously did a dev->tbusy = 0 without a mark_bh(NET_BH) it
> may not wake the networking bh to feed data out. If the delays are
> precisely one second see if they occur in 2.2.13pre14/5 as Alexey fixed
> a traffic scheduling bug
I've tried 2.2.13pre15, and ... it does NOT solve it. :(
Ok, let's see if this e-mail provides more useful info. This is the
skeleton of cpc_queue_xmit:
static int cpc_queue_xmit(struct sk_buff *skb, struct device *dev)
{
if (dev->tbusy) {
if (time_before(jiffies, dev->trans_start + PC300_TX_TIMEOUT))
return 1;
stats->tx_dropped++;
dev->tbusy=0;
}
if (test_and_set_bit(0, (void*)&dev->tbusy) != 0) {
return 1;
}
/* Write buffer to on-board DMA buffers */
CPC_LOCK(card, flags);
if(dma_buf_write(card, chan, (ucchar *)skb->data, skb->len) != 0) {
CPC_UNLOCK(card, flags);
stats->tx_dropped++;
dev_kfree_skb(skb);
return 1;
}
CPC_UNLOCK(card, flags);
stats->tx_bytes += skb->len;
dev_kfree_skb(skb);
stats->tx_packets++;
dev->trans_start = jiffies;
dev->tbusy = 0;
mark_bh(NET_BH);
/* Start transmission */
tx_dma_start(card, chan);
return 0;
}
Note that mark_bh is called just after dev->tbusy is set to 0 (before you
ask, there are no dropped packets, so I know that the other places where
tbusy could be set to 0 are not reached).
Furthermore, the only other places where the tbusy value is changed are
the open (tbusy = 0) and close (tbusy = 1) functions.
Do you know of anything else that might cause this?? Do you have any
suggestion on where to look (or what to use to debug it) in order to find
the culprit??
Thanks for your help.
Regards,
Ivan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/