Messages in this thread | | | Date | Mon, 11 Oct 1999 10:47:16 -0700 (PDT) | From | Linux Lists <> | Subject | Re: Stalls on sync PPP transmission (new card) |
| |
On Sat, 9 Oct 1999, Alan Cox wrote:
> > 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/
| |