sky2: receive dma mapping error handling
in [Kernel]
|
From: Jarek Poplawski on 1 Feb 2010 17:50 On Mon, Feb 01, 2010 at 02:29:42PM -0800, Stephen Hemminger wrote: > On Mon, 1 Feb 2010 22:27:41 +0100 > Jarek Poplawski <jarkao2(a)gmail.com> wrote: > > > @@ -1038,13 +1035,14 @@ static void tx_init(struct sky2_port *sky2) > > { > > struct sky2_tx_le *le; > > > > - sky2->tx_prod = sky2->tx_cons = 0; > > + sky2->tx_prod = 0; > > sky2->tx_tcpsum = 0; > > sky2->tx_last_mss = 0; > > > > le = get_tx_le(sky2, &sky2->tx_prod); > > le->addr = 0; > > le->opcode = OP_ADDR64 | HW_OWNER; > > + sky2->tx_cons = sky2->tx_prod; > > sky2->tx_last_upper = 0; > > } > > Your change causes the initial element to be skipped. I want > it to goto the hardware. It makes sure the upper bits of the > first request are set (0). I thought "Send high bits if needed" part in sky2_xmit_frame() was enough. If it's otherwise than my patch was wrong. > > I don't see what was wrong with my fix. > It's OK. Please, submit it instead of mine. Thanks, Jarek P. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stephen Hemminger on 1 Feb 2010 18:00 On Mon, 1 Feb 2010 23:46:39 +0100 Jarek Poplawski <jarkao2(a)gmail.com> wrote: > On Mon, Feb 01, 2010 at 02:29:42PM -0800, Stephen Hemminger wrote: > > On Mon, 1 Feb 2010 22:27:41 +0100 > > Jarek Poplawski <jarkao2(a)gmail.com> wrote: > > > > > @@ -1038,13 +1035,14 @@ static void tx_init(struct sky2_port *sky2) > > > { > > > struct sky2_tx_le *le; > > > > > > - sky2->tx_prod = sky2->tx_cons = 0; > > > + sky2->tx_prod = 0; > > > sky2->tx_tcpsum = 0; > > > sky2->tx_last_mss = 0; > > > > > > le = get_tx_le(sky2, &sky2->tx_prod); > > > le->addr = 0; > > > le->opcode = OP_ADDR64 | HW_OWNER; > > > + sky2->tx_cons = sky2->tx_prod; > > > sky2->tx_last_upper = 0; > > > } > > > > Your change causes the initial element to be skipped. I want > > it to goto the hardware. It makes sure the upper bits of the > > first request are set (0). > > I thought "Send high bits if needed" part in sky2_xmit_frame() was > enough. If it's otherwise than my patch was wrong. > The definition is "high bits are different than the last value". The code init sets the last value to zero, and initializes the hardware engine as well. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 2 Feb 2010 17:50 Stephen Hemminger <shemminger(a)linux-foundation.org> writes: > - for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) > - re->frag_addr[i] = pci_map_page(pdev, > + > +map_page_error: > + while (--i >= 0) { > + pci_unmap_page(pdev, re->frag_addr[i], > + skb_shinfo(skb)->frags[i].size, > + PCI_DMA_FROMDEVICE); > + } > + > + pci_unmap_single(pdev, re->data_addr, pci_unmap_len(re, data_size), > + PCI_DMA_FROMDEVICE); Better add a helper somewhere to do this, doesn't make sense to duplicate this in all drivers (lots of drivers have similar problems) I remember looking at this some time ago but for some reason the patches never made it out. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael Breuer on 2 Feb 2010 23:10 On 2/1/2010 1:20 PM, Stephen Hemminger wrote: > This fixes the fact that re->flags is always zero without causing > other confusion. > > --- a/drivers/net/sky2.c 2010-02-01 10:07:42.676296236 -0800 > +++ b/drivers/net/sky2.c 2010-02-01 10:18:12.575044064 -0800 > @@ -1025,11 +1025,8 @@ static void sky2_prefetch_init(struct sk > static inline struct sky2_tx_le *get_tx_le(struct sky2_port *sky2, u16 *slot) > { > struct sky2_tx_le *le = sky2->tx_le + *slot; > - struct tx_ring_info *re = sky2->tx_ring + *slot; > > *slot = RING_NEXT(*slot, sky2->tx_ring_size); > - re->flags = 0; > - re->skb = NULL; > le->ctrl = 0; > return le; > } > @@ -1622,8 +1619,7 @@ static unsigned tx_le_req(const struct s > return count; > } > > -static void sky2_tx_unmap(struct pci_dev *pdev, > - const struct tx_ring_info *re) > +static void sky2_tx_unmap(struct pci_dev *pdev, struct tx_ring_info *re) > { > if (re->flags& TX_MAP_SINGLE) > pci_unmap_single(pdev, pci_unmap_addr(re, mapaddr), > @@ -1633,6 +1629,7 @@ static void sky2_tx_unmap(struct pci_dev > pci_unmap_page(pdev, pci_unmap_addr(re, mapaddr), > pci_unmap_len(re, maplen), > PCI_DMA_TODEVICE); > + re->flags = 0; > } > > /* > @@ -1839,6 +1836,7 @@ static void sky2_tx_complete(struct sky2 > dev->stats.tx_packets++; > dev->stats.tx_bytes += skb->len; > > + re->skb = NULL; > dev_kfree_skb_any(skb); > > sky2->tx_next = RING_NEXT(idx, sky2->tx_ring_size); > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > Just a brief update - this has been up and stable for about 32 hours - I've been periodically generating load on the system. No kernel errors of any sort so far. Actually, in retrospect, I believe the dma issue was triggering other bad things - including an rcu lockup (patched in tip - sched.c). Just as an FYI - (and this should probably be in a new thread) I am seeing an large number (>9,000,000) of dropped rx packets, however at this time I see no errors resulting from that (on this or client machines). As the # of dropped packets hasn't incremented at any time I was observing things, I can't say what this is about. Probably nothing, but I'll see if I can track down what is going on. I did see some of this earlier on while troubleshooting the sky2 issues that now seem resolved. Quick crosschecking of other machines do not show high error or retransmission rates. I'm also not seeing any evidence of other errors (no errors reported by ifconfig, or ethtool, or printk (debug is enabled). I'm wondering whether these dropped packets are due mostly to hitting GMR_FS_RX_OK in sky2_receive. I'm also guessing that the high numbers of this that I'm seeing is an artifact of being able to pump more traffic through with the above patch. Given the description of the status code in sky2.h (receive ok) I'm wondering whether a) this should be reported as dropped, b) whether resubmit is necessary, c) whether it's possible that eth1 events coinciding with eth0 events are the cause and d) whether or not there's another issue entirely. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael Breuer on 3 Feb 2010 11:50
On 02/02/2010 11:07 PM, Michael Breuer wrote: > Just a brief update - this has been up and stable for about 32 hours - > I've been periodically generating load on the system. No kernel errors > of any sort so far. Actually, in retrospect, I believe the dma issue > was triggering other bad things - including an rcu lockup (patched in > tip - sched.c). > > Just as an FYI - (and this should probably be in a new thread) I am > seeing an large number (>9,000,000) of dropped rx packets, however at > this time I see no errors resulting from that (on this or client > machines). As the # of dropped packets hasn't incremented at any time > I was observing things, I can't say what this is about. Probably > nothing, but I'll see if I can track down what is going on. I did see > some of this earlier on while troubleshooting the sky2 issues that now > seem resolved. Quick crosschecking of other machines do not show high > error or retransmission rates. I'm also not seeing any evidence of > other errors (no errors reported by ifconfig, or ethtool, or printk > (debug is enabled). > > I'm wondering whether these dropped packets are due mostly to hitting > GMR_FS_RX_OK in sky2_receive. I'm also guessing that the high numbers > of this that I'm seeing is an artifact of being able to pump more > traffic through with the above patch. Given the description of the > status code in sky2.h (receive ok) I'm wondering whether a) this > should be reported as dropped, b) whether resubmit is necessary, c) > whether it's possible that eth1 events coinciding with eth0 events are > the cause and d) whether or not there's another issue entirely. > Tracked this down. The status being returned is 0x3c0080 - good flow control packets. Nothing is actually being dropped (confirmed by packet trace on switch compared with packet trace on server). I whipped up a trivial patch to not count these as dropped packets and will post to netdev. I'm not really sure what the driver should be doing in this case, but resubmit seems to work. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |