[KJ][PATCH]sb1250-mac.c-kzalloc
Replacing kmalloc/memset combination with kzalloc. Signed-off-by: vignesh babu [EMAIL PROTECTED] --- diff --git a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c index 103c317..af7649f 100644 --- a/drivers/net/sb1250-mac.c +++ b/drivers/net/sb1250-mac.c @@ -735,8 +735,8 @@ static void sbdma_initctx(sbmacdma_t *d, d-sbdma_maxdescr = maxdescr; - d-sbdma_dscrtable = (sbdmadscr_t *) - kmalloc((d-sbdma_maxdescr+1)*sizeof(sbdmadscr_t), GFP_KERNEL); + d-sbdma_dscrtable = + kzalloc((d-sbdma_maxdescr+1)*sizeof(sbdmadscr_t), GFP_KERNEL); /* * The descriptor table must be aligned to at least 16 bytes or the @@ -745,8 +745,6 @@ static void sbdma_initctx(sbmacdma_t *d, d-sbdma_dscrtable = (sbdmadscr_t *) ALIGN((unsigned long)d-sbdma_dscrtable, sizeof(sbdmadscr_t)); - memset(d-sbdma_dscrtable,0,d-sbdma_maxdescr*sizeof(sbdmadscr_t)); - d-sbdma_dscrtable_end = d-sbdma_dscrtable + d-sbdma_maxdescr; d-sbdma_dscrtable_phys = virt_to_phys(d-sbdma_dscrtable); @@ -755,10 +753,8 @@ static void sbdma_initctx(sbmacdma_t *d, * And context table */ - d-sbdma_ctxtable = (struct sk_buff **) - kmalloc(d-sbdma_maxdescr*sizeof(struct sk_buff *), GFP_KERNEL); - - memset(d-sbdma_ctxtable,0,d-sbdma_maxdescr*sizeof(struct sk_buff *)); + d-sbdma_ctxtable = + kzalloc(d-sbdma_maxdescr*sizeof(struct sk_buff *), GFP_KERNEL); #ifdef CONFIG_SBMAC_COALESCE /* -- Regards, Vignesh Babu BM _ Why is it that every time I'm with you, makes me believe in magic? smime.p7s Description: S/MIME cryptographic signature
[PATCH] [1/4] pasemi_mac: minor bugfixes
Ethernet bugfixes: * Move the was_full/wake_queue logic from tx_intr to clean_tx * Fix polarity in checks in pasemi_mac_close Signed-off-by: Olof Johansson [EMAIL PROTECTED] Index: linux-2.6/drivers/net/pasemi_mac.c === --- linux-2.6.orig/drivers/net/pasemi_mac.c +++ linux-2.6/drivers/net/pasemi_mac.c @@ -451,9 +451,12 @@ static int pasemi_mac_clean_tx(struct pa struct pas_dma_xct_descr *dp; int start, count; int flags; + int was_full; spin_lock_irqsave(mac-tx-lock, flags); + was_full = mac-tx-next_to_clean - mac-tx-next_to_use == TX_RING_SIZE; + start = mac-tx-next_to_clean; count = 0; @@ -478,6 +481,9 @@ static int pasemi_mac_clean_tx(struct pa mac-tx-next_to_clean += count; spin_unlock_irqrestore(mac-tx-lock, flags); + if (was_full) + netif_wake_queue(mac-netdev); + return count; } @@ -512,9 +518,6 @@ static irqreturn_t pasemi_mac_tx_intr(in struct net_device *dev = data; struct pasemi_mac *mac = netdev_priv(dev); unsigned int reg; - int was_full; - - was_full = mac-tx-next_to_clean - mac-tx-next_to_use == TX_RING_SIZE; if (!(*mac-tx_status PAS_STATUS_INT)) return IRQ_NONE; @@ -528,9 +531,6 @@ static irqreturn_t pasemi_mac_tx_intr(in pci_write_config_dword(mac-iob_pdev, PAS_IOB_DMA_TXCH_RESET(mac-dma_txch), reg); - if (was_full) - netif_wake_queue(dev); - return IRQ_HANDLED; } @@ -662,40 +665,37 @@ static int pasemi_mac_close(struct net_d pci_read_config_dword(mac-dma_pdev, PAS_DMA_TXCHAN_TCMDSTA(mac-dma_txch), stat); - if (stat PAS_DMA_TXCHAN_TCMDSTA_ACT) + if (!(stat PAS_DMA_TXCHAN_TCMDSTA_ACT)) break; cond_resched(); } - if (!(stat PAS_DMA_TXCHAN_TCMDSTA_ACT)) { + if (stat PAS_DMA_TXCHAN_TCMDSTA_ACT) dev_err(mac-dma_pdev-dev, Failed to stop tx channel\n); - } for (retries = 0; retries MAX_RETRIES; retries++) { pci_read_config_dword(mac-dma_pdev, PAS_DMA_RXCHAN_CCMDSTA(mac-dma_rxch), stat); - if (stat PAS_DMA_RXCHAN_CCMDSTA_ACT) + if (!(stat PAS_DMA_RXCHAN_CCMDSTA_ACT)) break; cond_resched(); } - if (!(stat PAS_DMA_RXCHAN_CCMDSTA_ACT)) { + if (stat PAS_DMA_RXCHAN_CCMDSTA_ACT) dev_err(mac-dma_pdev-dev, Failed to stop rx channel\n); - } for (retries = 0; retries MAX_RETRIES; retries++) { pci_read_config_dword(mac-dma_pdev, PAS_DMA_RXINT_RCMDSTA(mac-dma_if), stat); - if (stat PAS_DMA_RXINT_RCMDSTA_ACT) + if (!(stat PAS_DMA_RXINT_RCMDSTA_ACT)) break; cond_resched(); } - if (!(stat PAS_DMA_RXINT_RCMDSTA_ACT)) { + if (stat PAS_DMA_RXINT_RCMDSTA_ACT) dev_err(mac-dma_pdev-dev, Failed to stop rx interface\n); - } /* Then, disable the channel. This must be done separately from * stopping, since you can't disable when active. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [0/4] pasemi_mac: fixes and enhancements
Hi, The four following patches contain a number of fixes and improvements of the pasemi_mac driver: 1/4: A couple of minor bugfixes. 2/4: Move the IRQ mapping from the PCI layer under our platform, to the driver. 3/4: A rather large patch with various NAPI/performance-related fixes and enhancements. 4/4: phy support -Olof - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: tg3 spitting out uninitialized memory
Jamie webb wrote: Well, so far so good. I'll let you know if it happens again, but it looks like that's fixed it. Further testing showed that I also had to disable rx checksumming, otherwise I was getting random kernel crashes. Presumably it was not only reading data from random memory locations, but also writing in the wrong place... So, do I understand correctly that this is causing the CPU rather than the NIC to do the checksumming? That's right. See the discussion on a similar problem here: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=10 59644admit=-682735245+1158251313899+28353475 In this other case, the symptoms were very similar to yours. I suspected it was an IOMMU problem, and the problem went away when the user upgraded to the latest kernel at that time. Is this a reasonable permanent solution? I don't think so. We need to get to the bottom of it. Looking at your original email, the corruption also happened in multiples of 16 bytes. If it is a hardware or driver bug, the corruption is usually more random than this. Or MSS- sized chunks should be corrupted. If you have other captured corruption data, please send it to me. Anyway, I'll see if our lab can setup a similar machine to test this out. Thanks. Crashing aside, I'm a little nervous about putting into production a box that might for example randomly decide to serve up its SSL private keys halfway through an email message... Cheers /J - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: tg3 spitting out uninitialized memory
That's right. See the discussion on a similar problem here: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=10 59644admit=-682735245+1158251313899+28353475 That's an AMD machine. In this other case, the symptoms were very similar to yours. I suspected it was an IOMMU problem, and the problem went away when the user upgraded to the latest kernel at that time. tg3s never use the IOMMU on AMD systems with production kernels because they have a suitably large DMA mask. IOMMU is only used there to remap memory that doesn't fit a device's DMA mask. There is a debugging mode to force iommu always, but it is not used unless you configure it specially. -Andi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [2/4] pasemi_mac: irq mapping changes
On Mon, 2007-04-16 at 01:18 -0500, Olof Johansson wrote: Fixes for ethernet IRQ mapping, to move it to the driver instead of in the platform setup code. Signed-off-by: Olof Johansson [EMAIL PROTECTED] Index: powerpc/arch/powerpc/platforms/pasemi/pci.c === --- powerpc.orig/arch/powerpc/platforms/pasemi/pci.c +++ powerpc/arch/powerpc/platforms/pasemi/pci.c @@ -163,19 +163,6 @@ static void __init pas_fixup_phb_resourc } -void __devinit pas_pci_irq_fixup(struct pci_dev *dev) -{ - /* DMA is special, 84 interrupts (128 - 211), all but 128 - * need to be mapped by hand here. - */ - if (dev-vendor == 0x1959 dev-device == 0xa007) { - int i; - for (i = 129; i 212; i++) - irq_create_mapping(NULL, i); - } -} - - void __init pas_pci_init(void) { struct device_node *np, *root; Index: powerpc/arch/powerpc/platforms/pasemi/setup.c === --- powerpc.orig/arch/powerpc/platforms/pasemi/setup.c +++ powerpc/arch/powerpc/platforms/pasemi/setup.c @@ -240,5 +240,4 @@ define_machine(pas) { .check_legacy_ioport= pas_check_legacy_ioport, .progress = pas_progress, .machine_check_exception = pas_machine_check_handler, - .pci_irq_fixup = pas_pci_irq_fixup, }; Index: powerpc/drivers/net/pasemi_mac.c === --- powerpc.orig/drivers/net/pasemi_mac.c +++ powerpc/drivers/net/pasemi_mac.c @@ -537,6 +537,9 @@ static irqreturn_t pasemi_mac_tx_intr(in static int pasemi_mac_open(struct net_device *dev) { struct pasemi_mac *mac = netdev_priv(dev); + struct device_node *dma_dn = pci_device_to_OF_node(mac-dma_pdev); + const unsigned int *prop; + int base_irq; unsigned int flags; int ret; @@ -600,8 +603,24 @@ static int pasemi_mac_open(struct net_de netif_start_queue(dev); netif_poll_enable(dev); - ret = request_irq(mac-dma_pdev-irq + mac-dma_txch, - pasemi_mac_tx_intr, IRQF_DISABLED, + /* Interrupts are a bit different for our DMA controller: While + * it's got one a regular PCI device header, the interrupt there + * is really the base of the range it's using. Each tx and rx + * channel has it's own interrupt source. + * + * The only way to get to the actual hardware interrupt is by + * getting it from the device tree, since the kernel has done + * virtual remapping of the sources by the time we can get them + * from the PCI device. + */ + + prop = of_get_property(dma_dn, interrupts, NULL); + base_irq = *prop; The recently added virq_to_hw() makes it nice 'n easy to reverse map the hw irq from the pci_dev: base_irq = virq_to_hw(pdev-irq); You should also probably check that irq_create_mapping() succeeds, just to be pedantic. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
[PATCH] [3/4] pasemi_mac: cleanups and rx performance improvements
NAPI fixes and cleanups for pasemi_mac: * Timer changes/fixes * Abstract out the rx intr restart to a separate function * Similar function for tx intr to reset to a known clear state even if firmware used the same interface * Add a copy-break and recycle the SKB in the driver for small packets * Other cleanups to rx path Signed-off-by: Olof Johansson [EMAIL PROTECTED] Index: powerpc/drivers/net/pasemi_mac.c === --- powerpc.orig/drivers/net/pasemi_mac.c +++ powerpc/drivers/net/pasemi_mac.c @@ -59,12 +59,6 @@ #define BUF_SIZE 1646 /* 1500 MTU + ETH_HLEN + VLAN_HLEN + 2 64B cachelines */ -/* XXXOJN these should come out of the device tree some day */ -#define PAS_DMA_CAP_BASE 0xe00d0040 -#define PAS_DMA_CAP_SIZE 0x100 -#define PAS_DMA_COM_BASE 0xe00d0100 -#define PAS_DMA_COM_SIZE 0x100 - static struct pasdma_status *dma_status; static int pasemi_get_mac_addr(struct pasemi_mac *mac) @@ -277,8 +271,8 @@ static void pasemi_mac_free_rx_resources for (i = 0; i RX_RING_SIZE; i++) { info = RX_DESC_INFO(mac, i); dp = RX_DESC(mac, i); - if (info-dma) { - if (info-skb) { + if (info-skb) { + if (info-dma) { pci_unmap_single(mac-dma_pdev, info-dma, info-skb-len, @@ -309,84 +303,122 @@ static void pasemi_mac_replenish_rx_ring struct pasemi_mac *mac = netdev_priv(dev); unsigned int i; int start = mac-rx-next_to_fill; - unsigned int count; + unsigned int limit, count; - count = (mac-rx-next_to_clean + RX_RING_SIZE - + limit = (mac-rx-next_to_clean + RX_RING_SIZE - mac-rx-next_to_fill) (RX_RING_SIZE - 1); /* Check to see if we're doing first-time setup */ if (unlikely(mac-rx-next_to_clean == 0 mac-rx-next_to_fill == 0)) - count = RX_RING_SIZE; + limit = RX_RING_SIZE; - if (count = 0) + if (limit = 0) return; - for (i = start; i start + count; i++) { + i = start; + + for (count = limit; count; count--) { struct pasemi_mac_buffer *info = RX_DESC_INFO(mac, i); u64 *buff = RX_BUFF(mac, i); struct sk_buff *skb; dma_addr_t dma; - skb = dev_alloc_skb(BUF_SIZE); + /* skb might still be in there for recycle on short receives */ + if (info-skb) + skb = info-skb; + else + skb = dev_alloc_skb(BUF_SIZE); - if (!skb) { - count = i - start; + if (unlikely(!skb)) break; - } skb-dev = dev; dma = pci_map_single(mac-dma_pdev, skb-data, skb-len, PCI_DMA_FROMDEVICE); - if (dma_mapping_error(dma)) { + if (unlikely(dma_mapping_error(dma))) { dev_kfree_skb_irq(info-skb); - count = i - start; break; } info-skb = skb; info-dma = dma; *buff = XCT_RXB_LEN(BUF_SIZE) | XCT_RXB_ADDR(dma); + i++; } wmb(); pci_write_config_dword(mac-dma_pdev, PAS_DMA_RXCHAN_INCR(mac-dma_rxch), - count); + limit - count); pci_write_config_dword(mac-dma_pdev, PAS_DMA_RXINT_INCR(mac-dma_if), - count); + limit - count); + + mac-rx-next_to_fill += limit - count; +} + +static void pasemi_mac_restart_rx_intr(struct pasemi_mac *mac) +{ + unsigned int reg, stat; + /* Re-enable packet count interrupts: finally +* ack the packet count interrupt we got in rx_intr. +*/ + + pci_read_config_dword(mac-iob_pdev, + PAS_IOB_DMA_RXCH_STAT(mac-dma_rxch), + stat); + + reg = PAS_IOB_DMA_RXCH_RESET_PCNT(stat PAS_IOB_DMA_RXCH_STAT_CNTDEL_M) | + PAS_IOB_DMA_RXCH_RESET_PINTC; + + pci_write_config_dword(mac-iob_pdev, + PAS_IOB_DMA_RXCH_RESET(mac-dma_rxch), + reg); +} + +static void pasemi_mac_restart_tx_intr(struct pasemi_mac *mac) +{ + unsigned int reg, stat; - mac-rx-next_to_fill += count; + /* Re-enable packet count interrupts */ + pci_read_config_dword(mac-iob_pdev, + PAS_IOB_DMA_TXCH_STAT(mac-dma_txch), stat); + + reg = PAS_IOB_DMA_TXCH_RESET_PCNT(stat
[PATCH] [4/4] pasemi_mac: phy support
PHY support for pasemi_mac. Also add msg_enable flags for future disablement of the link messages. Signed-off-by: Olof Johansson [EMAIL PROTECTED] Index: powerpc/drivers/net/pasemi_mac.c === --- powerpc.orig/drivers/net/pasemi_mac.c +++ powerpc/drivers/net/pasemi_mac.c @@ -40,13 +40,11 @@ * * - Get rid of pci_{read,write}_config(), map registers with ioremap * for performance - * - PHY support * - Multicast support * - Large MTU support * - Other performance improvements */ - /* Must be a power of two */ #define RX_RING_SIZE 512 #define TX_RING_SIZE 512 @@ -592,6 +590,110 @@ static irqreturn_t pasemi_mac_tx_intr(in return IRQ_HANDLED; } +static void pasemi_adjust_link(struct net_device *dev) +{ + struct pasemi_mac *mac = netdev_priv(dev); + int msg; + unsigned int flags; + unsigned int new_flags; + + if (!mac-phydev-link) { + /* If no link, MAC speed settings don't matter. Just report +* link down and return. +*/ + if (mac-link netif_msg_link(mac)) + printk(KERN_INFO %s: Link is down.\n, dev-name); + + netif_carrier_off(dev); + mac-link = 0; + + return; + } else + netif_carrier_on(dev); + + pci_read_config_dword(mac-pdev, PAS_MAC_CFG_PCFG, flags); + new_flags = flags ~(PAS_MAC_CFG_PCFG_HD | PAS_MAC_CFG_PCFG_SPD_M); + + if (!mac-phydev-duplex) + new_flags |= PAS_MAC_CFG_PCFG_HD; + + switch (mac-phydev-speed) { + case 1000: + new_flags |= PAS_MAC_CFG_PCFG_SPD_1G; + break; + case 100: + new_flags |= PAS_MAC_CFG_PCFG_SPD_100M; + break; + case 10: + new_flags |= PAS_MAC_CFG_PCFG_SPD_10M; + break; + default: + printk(Unsupported speed %d\n, mac-phydev-speed); + } + + /* Print on link or speed/duplex change */ + msg = mac-link != mac-phydev-link || flags != new_flags; + + mac-duplex = mac-phydev-duplex; + mac-speed = mac-phydev-speed; + mac-link = mac-phydev-link; + + if (new_flags != flags) + pci_write_config_dword(mac-pdev, PAS_MAC_CFG_PCFG, new_flags); + + if (msg netif_msg_link(mac)) + printk(KERN_INFO %s: Link is up at %d Mbps, %s duplex.\n, + dev-name, mac-speed, mac-duplex ? full : half); +} + +static int pasemi_mac_phy_init(struct net_device *dev) +{ + struct pasemi_mac *mac = netdev_priv(dev); + struct device_node *dn, *phy_dn; + struct phy_device *phydev; + unsigned int phy_id; + const phandle *ph; + const unsigned int *prop; + struct resource r; + int ret; + + dn = pci_device_to_OF_node(mac-pdev); + ph = get_property(dn, phy-handle, NULL); + if (!ph) + return -ENODEV; + phy_dn = of_find_node_by_phandle(*ph); + + prop = get_property(phy_dn, reg, NULL); + ret = of_address_to_resource(phy_dn-parent, 0, r); + if (ret) + goto err; + + phy_id = *prop; + snprintf(mac-phy_id, BUS_ID_SIZE, PHY_ID_FMT, (int)r.start, phy_id); + + of_node_put(phy_dn); + + mac-link = 0; + mac-speed = 0; + mac-duplex = -1; + + phydev = phy_connect(dev, mac-phy_id, pasemi_adjust_link, 0, PHY_INTERFACE_MODE_SGMII); + + if (IS_ERR(phydev)) { + printk(KERN_ERR %s: Could not attach to phy\n, dev-name); + return PTR_ERR(phydev); + } + + mac-phydev = phydev; + + return 0; + +err: + of_node_put(phy_dn); + return -ENODEV; +} + + static int pasemi_mac_open(struct net_device *dev) { struct pasemi_mac *mac = netdev_priv(dev); @@ -666,6 +768,13 @@ static int pasemi_mac_open(struct net_de pasemi_mac_replenish_rx_ring(dev); + ret = pasemi_mac_phy_init(dev); + /* Some configs don't have PHYs (XAUI etc), so don't complain about +* failed init due to -ENODEV. +*/ + if (ret ret != -ENODEV) + dev_warn(mac-pdev-dev, phy init failed: %d\n, ret); + netif_start_queue(dev); netif_poll_enable(dev); @@ -699,6 +808,9 @@ static int pasemi_mac_open(struct net_de goto out_rx_int; } + if (mac-phydev) + phy_start(mac-phydev); + return 0; out_rx_int: @@ -722,6 +834,11 @@ static int pasemi_mac_close(struct net_d unsigned int stat; int retries; + if (mac-phydev) { + phy_stop(mac-phydev); + phy_disconnect(mac-phydev); + } + netif_stop_queue(dev); /* Clean out any pending buffers */ @@ -1015,6 +1132,9 @@ pasemi_mac_probe(struct pci_dev *pdev, c mac-rx_status = dma_status-rx_sta[mac-dma_rxch];
[PATCH] [2/4] pasemi_mac: irq mapping changes
Fixes for ethernet IRQ mapping, to move it to the driver instead of in the platform setup code. Signed-off-by: Olof Johansson [EMAIL PROTECTED] Index: powerpc/arch/powerpc/platforms/pasemi/pci.c === --- powerpc.orig/arch/powerpc/platforms/pasemi/pci.c +++ powerpc/arch/powerpc/platforms/pasemi/pci.c @@ -163,19 +163,6 @@ static void __init pas_fixup_phb_resourc } -void __devinit pas_pci_irq_fixup(struct pci_dev *dev) -{ - /* DMA is special, 84 interrupts (128 - 211), all but 128 -* need to be mapped by hand here. -*/ - if (dev-vendor == 0x1959 dev-device == 0xa007) { - int i; - for (i = 129; i 212; i++) - irq_create_mapping(NULL, i); - } -} - - void __init pas_pci_init(void) { struct device_node *np, *root; Index: powerpc/arch/powerpc/platforms/pasemi/setup.c === --- powerpc.orig/arch/powerpc/platforms/pasemi/setup.c +++ powerpc/arch/powerpc/platforms/pasemi/setup.c @@ -240,5 +240,4 @@ define_machine(pas) { .check_legacy_ioport= pas_check_legacy_ioport, .progress = pas_progress, .machine_check_exception = pas_machine_check_handler, - .pci_irq_fixup = pas_pci_irq_fixup, }; Index: powerpc/drivers/net/pasemi_mac.c === --- powerpc.orig/drivers/net/pasemi_mac.c +++ powerpc/drivers/net/pasemi_mac.c @@ -537,6 +537,9 @@ static irqreturn_t pasemi_mac_tx_intr(in static int pasemi_mac_open(struct net_device *dev) { struct pasemi_mac *mac = netdev_priv(dev); + struct device_node *dma_dn = pci_device_to_OF_node(mac-dma_pdev); + const unsigned int *prop; + int base_irq; unsigned int flags; int ret; @@ -600,8 +603,24 @@ static int pasemi_mac_open(struct net_de netif_start_queue(dev); netif_poll_enable(dev); - ret = request_irq(mac-dma_pdev-irq + mac-dma_txch, - pasemi_mac_tx_intr, IRQF_DISABLED, + /* Interrupts are a bit different for our DMA controller: While +* it's got one a regular PCI device header, the interrupt there +* is really the base of the range it's using. Each tx and rx +* channel has it's own interrupt source. +* +* The only way to get to the actual hardware interrupt is by +* getting it from the device tree, since the kernel has done +* virtual remapping of the sources by the time we can get them +* from the PCI device. +*/ + + prop = of_get_property(dma_dn, interrupts, NULL); + base_irq = *prop; + + mac-tx_irq = irq_create_mapping(NULL, base_irq + mac-dma_txch); + mac-rx_irq = irq_create_mapping(NULL, base_irq + 20 + mac-dma_txch); + + ret = request_irq(mac-tx_irq, pasemi_mac_tx_intr, IRQF_DISABLED, mac-tx-irq_name, dev); if (ret) { dev_err(mac-pdev-dev, request_irq of irq %d failed: %d\n, @@ -609,8 +628,7 @@ static int pasemi_mac_open(struct net_de goto out_tx_int; } - ret = request_irq(mac-dma_pdev-irq + 20 + mac-dma_rxch, - pasemi_mac_rx_intr, IRQF_DISABLED, + ret = request_irq(mac-rx_irq, pasemi_mac_rx_intr, IRQF_DISABLED, mac-rx-irq_name, dev); if (ret) { dev_err(mac-pdev-dev, request_irq of irq %d failed: %d\n, @@ -621,7 +639,7 @@ static int pasemi_mac_open(struct net_de return 0; out_rx_int: - free_irq(mac-dma_pdev-irq + mac-dma_txch, dev); + free_irq(mac-tx_irq, dev); out_tx_int: netif_poll_disable(dev); netif_stop_queue(dev); @@ -705,8 +723,8 @@ static int pasemi_mac_close(struct net_d pci_write_config_dword(mac-dma_pdev, PAS_DMA_RXINT_RCMDSTA(mac-dma_if), 0); - free_irq(mac-dma_pdev-irq + mac-dma_txch, dev); - free_irq(mac-dma_pdev-irq + 20 + mac-dma_rxch, dev); + free_irq(mac-tx_irq, dev); + free_irq(mac-rx_irq, dev); /* Free resources */ pasemi_mac_free_rx_resources(dev); Index: powerpc/drivers/net/pasemi_mac.h === --- powerpc.orig/drivers/net/pasemi_mac.h +++ powerpc/drivers/net/pasemi_mac.h @@ -73,6 +73,8 @@ struct pasemi_mac { struct pasemi_mac_txring *tx; struct pasemi_mac_rxring *rx; + unsigned long tx_irq; + unsigned long rx_irq; }; /* Software status descriptor (desc_info) */ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: tg3 spitting out uninitialized memory
Andi Kleen wrote: tg3s never use the IOMMU on AMD systems with production kernels because they have a suitably large DMA mask. IOMMU is only used there to remap memory that doesn't fit a device's DMA mask. There is a debugging mode to force iommu always, but it is not used unless you configure it specially. We actually have one chip that uses a 32-bit mask, and some that use a 40-bit mask. But you're right, I don't know for a fact whether it was IOMMU or not. The corruption happened on 64-bit chunks and seemed to have gone away after upgrading to the latest kernel, according to the user. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [0/4] pasemi_mac: fixes and enhancements
On Mon, Apr 16, 2007 at 01:16:54AM -0500, Olof Johansson wrote: Hi, The four following patches contain a number of fixes and improvements of the pasemi_mac driver: I just realized that these have been based on top of some OF API changes that are in paulus' for-2.6.22 tree, and won't build on something based on current mainline. I'll fix this up when I respin based on first round of comments in the next day or so. It should mostly be a matter of doing rename of_$foo() - $foo(). -Olof - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RTNETLINK 02/04]: Hold rtnl_mutex during netlink dump callbacks
[RTNETLINK]: Hold rtnl_mutex during netlink dump callbacks Hold rtnl_mutex during the entire netlink dump operation. This allows to simplify locking in the dump callbacks, since they can now rely on that no concurrent changes happen. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] --- commit 8d28b6a3d70b6c98bba6d1e60e2ecf8eb9fbbb2b tree e363ea54f7b22a3cbd47e032c5fed1b1edb7d53c parent 8373a426e9d692f74d10867c2dc3ea332e09154c author Patrick McHardy [EMAIL PROTECTED] Mon, 16 Apr 2007 09:05:24 +0200 committer Patrick McHardy [EMAIL PROTECTED] Mon, 16 Apr 2007 09:05:24 +0200 net/core/rtnetlink.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index 648a7b6..62f5c7f 100644 --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -859,6 +859,7 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh) int min_len; int family; int type; + int err; type = nlh-nlmsg_type; if (type RTM_MAX) @@ -887,7 +888,10 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh) if (dumpit == NULL) return -EOPNOTSUPP; - return netlink_dump_start(rtnl, skb, nlh, dumpit, NULL); + __rtnl_unlock(); + err = netlink_dump_start(rtnl, skb, nlh, dumpit, NULL); + rtnl_lock(); + return err; } memset(rta_buf, 0, (rtattr_max * sizeof(struct rtattr *))); @@ -972,7 +976,7 @@ void __init rtnetlink_init(void) panic(rtnetlink_init: cannot allocate rta_buf\n); rtnl = netlink_kernel_create(NETLINK_ROUTE, RTNLGRP_MAX, rtnetlink_rcv, -NULL, THIS_MODULE); +rtnl_mutex, THIS_MODULE); if (rtnl == NULL) panic(rtnetlink_init: cannot initialize rtnetlink\n); netlink_set_nonroot(NETLINK_ROUTE, NL_NONROOT_RECV); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RTNETLINK 03/04]: Remove unnecessary locking in dump callbacks
[RTNETLINK]: Remove unnecessary locking in dump callbacks Since we're now holding the rtnl during the entire dump operation, we can remove additional locking for rtnl protected data. This patch does that for all simple cases (dev_base_lock for dev_base walking, RCU protection for FIB rule dumping). Signed-off-by: Patrick McHardy [EMAIL PROTECTED] --- commit 49310148887f3d7a6b78809b0a771628be4ef0a8 tree 901a913e7b2570765df8aeb5b628c3783ee4934a parent 8d28b6a3d70b6c98bba6d1e60e2ecf8eb9fbbb2b author Patrick McHardy [EMAIL PROTECTED] Mon, 16 Apr 2007 09:05:32 +0200 committer Patrick McHardy [EMAIL PROTECTED] Mon, 16 Apr 2007 09:05:32 +0200 net/bridge/br_netlink.c |2 -- net/core/fib_rules.c|4 +--- net/core/rtnetlink.c|2 -- net/decnet/dn_dev.c |3 --- net/ipv4/devinet.c | 12 ++-- net/ipv6/addrconf.c |2 -- 6 files changed, 3 insertions(+), 22 deletions(-) diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c index 5e84ade..35facc0 100644 --- a/net/bridge/br_netlink.c +++ b/net/bridge/br_netlink.c @@ -109,7 +109,6 @@ static int br_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb) struct net_device *dev; int idx; - read_lock(dev_base_lock); for (dev = dev_base, idx = 0; dev; dev = dev-next) { /* not a bridge port */ if (dev-br_port == NULL || idx cb-args[0]) @@ -122,7 +121,6 @@ static int br_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb) skip: ++idx; } - read_unlock(dev_base_lock); cb-args[0] = idx; diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c index cb2dae1..8c5474e 100644 --- a/net/core/fib_rules.c +++ b/net/core/fib_rules.c @@ -495,8 +495,7 @@ static int dump_rules(struct sk_buff *skb, struct netlink_callback *cb, int idx = 0; struct fib_rule *rule; - rcu_read_lock(); - list_for_each_entry_rcu(rule, ops-rules_list, list) { + list_for_each_entry(rule, ops-rules_list, list) { if (idx cb-args[1]) goto skip; @@ -507,7 +506,6 @@ static int dump_rules(struct sk_buff *skb, struct netlink_callback *cb, skip: idx++; } - rcu_read_unlock(); cb-args[1] = idx; rules_ops_put(ops); diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index 62f5c7f..bc95fab 100644 --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -543,7 +543,6 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb) int s_idx = cb-args[0]; struct net_device *dev; - read_lock(dev_base_lock); for (dev=dev_base, idx=0; dev; dev = dev-next, idx++) { if (idx s_idx) continue; @@ -552,7 +551,6 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb) cb-nlh-nlmsg_seq, 0, NLM_F_MULTI) = 0) break; } - read_unlock(dev_base_lock); cb-args[0] = idx; return skb-len; diff --git a/net/decnet/dn_dev.c b/net/decnet/dn_dev.c index 61be2ca..5c2a995 100644 --- a/net/decnet/dn_dev.c +++ b/net/decnet/dn_dev.c @@ -799,7 +799,6 @@ static int dn_nl_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) skip_ndevs = cb-args[0]; skip_naddr = cb-args[1]; - read_lock(dev_base_lock); for (dev = dev_base, idx = 0; dev; dev = dev-next, idx++) { if (idx skip_ndevs) continue; @@ -824,8 +823,6 @@ static int dn_nl_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) } } done: - read_unlock(dev_base_lock); - cb-args[0] = idx; cb-args[1] = dn_idx; diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c index 9bdc795..08d 100644 --- a/net/ipv4/devinet.c +++ b/net/ipv4/devinet.c @@ -1182,17 +1182,13 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) int s_ip_idx, s_idx = cb-args[0]; s_ip_idx = ip_idx = cb-args[1]; - read_lock(dev_base_lock); for (dev = dev_base, idx = 0; dev; dev = dev-next, idx++) { if (idx s_idx) continue; if (idx s_idx) s_ip_idx = 0; - rcu_read_lock(); - if ((in_dev = __in_dev_get_rcu(dev)) == NULL) { - rcu_read_unlock(); + if ((in_dev = __in_dev_get_rtnl(dev)) == NULL) continue; - } for (ifa = in_dev-ifa_list, ip_idx = 0; ifa; ifa = ifa-ifa_next, ip_idx++) { @@ -1200,16 +1196,12 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) continue; if (inet_fill_ifaddr(skb, ifa, NETLINK_CB(cb-skb).pid,
[NET_SCHED 04/04]: Eliminate qdisc_tree_lock
[NET_SCHED]: Eliminate qdisc_tree_lock Since we're now holding the rtnl during the entire dump operation, we can remove qdisc_tree_lock, whose only purpose is to protect dump callbacks from concurrent changes to the qdisc tree. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] --- commit cc965189583f5a980e1fc6acaf708c47d3661a22 tree faede9cc5c6b86b39517c56c71caa6942e748f20 parent 49310148887f3d7a6b78809b0a771628be4ef0a8 author Patrick McHardy [EMAIL PROTECTED] Mon, 16 Apr 2007 09:05:39 +0200 committer Patrick McHardy [EMAIL PROTECTED] Mon, 16 Apr 2007 09:05:39 +0200 include/net/pkt_sched.h |2 -- net/sched/cls_api.c |2 -- net/sched/sch_api.c | 22 +++--- net/sched/sch_generic.c | 29 +++-- 4 files changed, 10 insertions(+), 45 deletions(-) diff --git a/include/net/pkt_sched.h b/include/net/pkt_sched.h index b2cc9a8..5754d53 100644 --- a/include/net/pkt_sched.h +++ b/include/net/pkt_sched.h @@ -13,8 +13,6 @@ struct qdisc_walker int (*fn)(struct Qdisc *, unsigned long cl, struct qdisc_walker *); }; -extern rwlock_t qdisc_tree_lock; - #define QDISC_ALIGNTO 32 #define QDISC_ALIGN(len) (((len) + QDISC_ALIGNTO-1) ~(QDISC_ALIGNTO-1)) diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c index ca3da50..ebf94ed 100644 --- a/net/sched/cls_api.c +++ b/net/sched/cls_api.c @@ -400,7 +400,6 @@ static int tc_dump_tfilter(struct sk_buff *skb, struct netlink_callback *cb) if ((dev = dev_get_by_index(tcm-tcm_ifindex)) == NULL) return skb-len; - read_lock(qdisc_tree_lock); if (!tcm-tcm_parent) q = dev-qdisc_sleeping; else @@ -457,7 +456,6 @@ errout: if (cl) cops-put(q, cl); out: - read_unlock(qdisc_tree_lock); dev_put(dev); return skb-len; } diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c index 2e863bd..0ce6914 100644 --- a/net/sched/sch_api.c +++ b/net/sched/sch_api.c @@ -191,7 +191,7 @@ int unregister_qdisc(struct Qdisc_ops *qops) (root qdisc, all its children, children of children etc.) */ -static struct Qdisc *__qdisc_lookup(struct net_device *dev, u32 handle) +struct Qdisc *qdisc_lookup(struct net_device *dev, u32 handle) { struct Qdisc *q; @@ -202,16 +202,6 @@ static struct Qdisc *__qdisc_lookup(struct net_device *dev, u32 handle) return NULL; } -struct Qdisc *qdisc_lookup(struct net_device *dev, u32 handle) -{ - struct Qdisc *q; - - read_lock(qdisc_tree_lock); - q = __qdisc_lookup(dev, handle); - read_unlock(qdisc_tree_lock); - return q; -} - static struct Qdisc *qdisc_leaf(struct Qdisc *p, u32 classid) { unsigned long cl; @@ -405,7 +395,7 @@ void qdisc_tree_decrease_qlen(struct Qdisc *sch, unsigned int n) if (n == 0) return; while ((parentid = sch-parent)) { - sch = __qdisc_lookup(sch-dev, TC_H_MAJ(parentid)); + sch = qdisc_lookup(sch-dev, TC_H_MAJ(parentid)); cops = sch-ops-cl_ops; if (cops-qlen_notify) { cl = cops-get(sch, parentid); @@ -905,7 +895,6 @@ static int tc_dump_qdisc(struct sk_buff *skb, struct netlink_callback *cb) continue; if (idx s_idx) s_q_idx = 0; - read_lock(qdisc_tree_lock); q_idx = 0; list_for_each_entry(q, dev-qdisc_list, list) { if (q_idx s_q_idx) { @@ -913,13 +902,10 @@ static int tc_dump_qdisc(struct sk_buff *skb, struct netlink_callback *cb) continue; } if (tc_fill_qdisc(skb, q, q-parent, NETLINK_CB(cb-skb).pid, - cb-nlh-nlmsg_seq, NLM_F_MULTI, RTM_NEWQDISC) = 0) { - read_unlock(qdisc_tree_lock); + cb-nlh-nlmsg_seq, NLM_F_MULTI, RTM_NEWQDISC) = 0) goto done; - } q_idx++; } - read_unlock(qdisc_tree_lock); } done: @@ -1142,7 +1128,6 @@ static int tc_dump_tclass(struct sk_buff *skb, struct netlink_callback *cb) s_t = cb-args[0]; t = 0; - read_lock(qdisc_tree_lock); list_for_each_entry(q, dev-qdisc_list, list) { if (t s_t || !q-ops-cl_ops || (tcm-tcm_parent @@ -1164,7 +1149,6 @@ static int tc_dump_tclass(struct sk_buff *skb, struct netlink_callback *cb) break; t++; } - read_unlock(qdisc_tree_lock); cb-args[0] = t; diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c index 52eb343..1894eb7 100644 --- a/net/sched/sch_generic.c +++ b/net/sched/sch_generic.c @@ -36,34 +36,23 @@ /* Main transmission queue.
[NET_SCHED]: ingress: switch back to using ingress_lock
This patch fixes a few spots for using ingress_lock for the ingress qdisc again and switches ing_filter back to use it. Applies on top of the netlink dump patches. [NET_SCHED]: ingress: switch back to using ingress_lock Switch ingress queueing back to use ingress_lock. qdisc_lock_tree now locks both the ingress and egress qdiscs on the device. All changes to data that might be used on both ingress and egress needs to be protected by using qdisc_lock_tree instead of manually taking dev-queue_lock. Additionally the qdisc stats_lock needs to be initialized to ingress_lock for ingress qdiscs. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] --- commit d053117e309fa2cc5fd9f39890bcadc148e79202 tree 6cad0c900beb67101bf4f84cbf55338d3d302e42 parent cc965189583f5a980e1fc6acaf708c47d3661a22 author Patrick McHardy [EMAIL PROTECTED] Mon, 16 Apr 2007 09:05:48 +0200 committer Patrick McHardy [EMAIL PROTECTED] Mon, 16 Apr 2007 09:05:48 +0200 net/core/dev.c |4 ++-- net/sched/cls_route.c |4 ++-- net/sched/sch_api.c | 26 +++--- net/sched/sch_generic.c |6 +- net/sched/sch_ingress.c |9 ++--- 5 files changed, 26 insertions(+), 23 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index 7f31d0f..c8f5ea9 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -1747,10 +1747,10 @@ static int ing_filter(struct sk_buff *skb) skb-tc_verd = SET_TC_AT(skb-tc_verd,AT_INGRESS); - spin_lock(dev-queue_lock); + spin_lock(dev-ingress_lock); if ((q = dev-qdisc_ingress) != NULL) result = q-enqueue(skb, q); - spin_unlock(dev-queue_lock); + spin_unlock(dev-ingress_lock); } diff --git a/net/sched/cls_route.c b/net/sched/cls_route.c index e92d716..cc941d0 100644 --- a/net/sched/cls_route.c +++ b/net/sched/cls_route.c @@ -89,9 +89,9 @@ static __inline__ int route4_fastmap_hash(u32 id, int iif) static inline void route4_reset_fastmap(struct net_device *dev, struct route4_head *head, u32 id) { - spin_lock_bh(dev-queue_lock); + qdisc_lock_tree(dev); memset(head-fastmap, 0, sizeof(head-fastmap)); - spin_unlock_bh(dev-queue_lock); + qdisc_unlock_tree(dev); } static inline void diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c index 0ce6914..8699e70 100644 --- a/net/sched/sch_api.c +++ b/net/sched/sch_api.c @@ -500,12 +500,16 @@ qdisc_create(struct net_device *dev, u32 handle, struct rtattr **tca, int *errp) if (handle == TC_H_INGRESS) { sch-flags |= TCQ_F_INGRESS; + sch-stats_lock = dev-ingress_lock; handle = TC_H_MAKE(TC_H_INGRESS, 0); - } else if (handle == 0) { - handle = qdisc_alloc_handle(dev); - err = -ENOMEM; - if (handle == 0) - goto err_out3; + } else { + sch-stats_lock = dev-queue_lock; + if (handle == 0) { + handle = qdisc_alloc_handle(dev); + err = -ENOMEM; + if (handle == 0) + goto err_out3; + } } sch-handle = handle; @@ -654,9 +658,9 @@ static int tc_get_qdisc(struct sk_buff *skb, struct nlmsghdr *n, void *arg) return err; if (q) { qdisc_notify(skb, n, clid, q, NULL); - spin_lock_bh(dev-queue_lock); + qdisc_lock_tree(dev); qdisc_destroy(q); - spin_unlock_bh(dev-queue_lock); + qdisc_unlock_tree(dev); } } else { qdisc_notify(skb, n, clid, NULL, q); @@ -789,17 +793,17 @@ graft: err = qdisc_graft(dev, p, clid, q, old_q); if (err) { if (q) { - spin_lock_bh(dev-queue_lock); + qdisc_lock_tree(dev); qdisc_destroy(q); - spin_unlock_bh(dev-queue_lock); + qdisc_unlock_tree(dev); } return err; } qdisc_notify(skb, n, clid, old_q, q); if (old_q) { - spin_lock_bh(dev-queue_lock); + qdisc_lock_tree(dev); qdisc_destroy(old_q); - spin_unlock_bh(dev-queue_lock); + qdisc_unlock_tree(dev); } } return 0; diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c index 1894eb7..3385ee5 100644 --- a/net/sched/sch_generic.c +++ b/net/sched/sch_generic.c @@ -42,16 +42,20 @@ * The idea is the following: * - enqueue, dequeue are serialized via top level device * spinlock
Re: [IPv4] fib: Fix out of bound access of fib_props[]
* Willy Tarreau [EMAIL PROTECTED] 2007-04-14 17:48 Finally, I think I have the correct fix below. Please someone confirm or tell me I'm nuts. Looks good, same is needed for DECnet - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPv4] fib: Fix out of bound access of fib_props[]
On Mon, Apr 16, 2007 at 10:14:17AM +0200, Thomas Graf wrote: * Willy Tarreau [EMAIL PROTECTED] 2007-04-14 17:48 Finally, I think I have the correct fix below. Please someone confirm or tell me I'm nuts. Looks good, same is needed for DECnet Thank you Thomas. The DECnet stuff was already merged, it was (expectedly) the same code. Regards, Willy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] parse ip:port strings correctly in in4_pton
in4_pton converts a textual representation of an ip4 address into an integer representation. However, when the textual representation is of in the form ip:port, c.f. 192.168.1.1:5060, and 'delim' is set to -1, the function bails out when parsing the colon. It makes sense to allow the colon as a delimiting character without explicitly having to set it through the 'delim' variable as there can be no ambiguity in the point where the ip address is completely parsed. Furthermore, this function is indeed called from nf_conntrack_sip.c in this way to parse textual ip:port combinations which fails as stated above. Signed-off-by: Jerome Borsboom [EMAIL PROTECTED] --- linux-2.6.20/net/core/utils.c 2007-02-04 19:44:54.0 +0100 +++ linux-2.6.20/net/core/utils.c 2007-04-15 21:08:55.0 +0200 @@ -137,16 +137,16 @@ while(1) { int c; c = xdigit2bin(srclen 0 ? *s : '\0', delim); - if (!(c (IN6PTON_DIGIT | IN6PTON_DOT | IN6PTON_DELIM))) { + if (!(c (IN6PTON_DIGIT | IN6PTON_DOT | IN6PTON_DELIM | IN6PTON_COLON_MASK))) { goto out; } - if (c (IN6PTON_DOT | IN6PTON_DELIM)) { + if (c (IN6PTON_DOT | IN6PTON_DELIM | IN6PTON_COLON_MASK)) { if (w == 0) goto out; *d++ = w 0xff; w = 0; i++; - if (c IN6PTON_DELIM) { + if (c (IN6PTON_DELIM | IN6PTON_COLON_MASK)) { if (i != 4) goto out; break; - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] parse ip:port strings correctly in in4_pton
Jerome Borsboom wrote: in4_pton converts a textual representation of an ip4 address into an integer representation. However, when the textual representation is of in the form ip:port, c.f. 192.168.1.1:5060, and 'delim' is set to -1, the function bails out when parsing the colon. It makes sense to allow the colon as a delimiting character without explicitly having to set it through the 'delim' variable as there can be no ambiguity in the point where the ip address is completely parsed. Furthermore, this function is indeed called from nf_conntrack_sip.c in this way to parse textual ip:port combinations which fails as stated above. What about IPv6? in6_pton behaves similar and is also used by nf_conntrack_sip. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: udp checksum issue in netpoll mode.
On 4/12/07, Stephen Hemminger [EMAIL PROTECTED] wrote: Aubrey Li wrote: I think we discussed this issue before. The current checksum function doesn't consider the kind of packet which is padded to reach a specific minimum length. I believe that's the problem caused my test case failed. Is this issue fixed? Or is it acceptable if I make a patch not calculating this kind of packet? Thanks, -Aubrey The caller should be trimming the packet and updating the hardware checksum value (like the normal UDP path). OK, the following patch fixed the problem. Signed-off-by: Aubrey.Li [EMAIL PROTECTED] --- net/core/netpoll.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/net/core/netpoll.c b/net/core/netpoll.c index 823215d..522e441 100644 --- a/net/core/netpoll.c +++ b/net/core/netpoll.c @@ -471,6 +471,13 @@ int __netpoll_rx(struct sk_buff *skb) if (skb-len len || len iph-ihl*4) goto out; + /* +* Our transport medium may have padded the buffer out. +* Now We trim to the true length of the frame. +*/ + if (pskb_trim_rcsum(skb, len)) + goto out; + if (iph-protocol != IPPROTO_UDP) goto out; -- 1.5.1 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Don't attach callback to a going-away netlink socket
Pavel Emelianov wrote: From: Denis Lunev [EMAIL PROTECTED] There is a race between netlink_dump_start() and netlink_release() that can lead to the situation when a netlink socket with non-zero callback is freed. Can you describe the race in more detail please? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [TCP]: Fix unused variable warnings (tcp_sock *tp no longer needed)
Manual completion to func(sk, tp, ...) - func(sk, ...) conversion. Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] --- net/ipv4/tcp_input.c |1 - net/ipv4/tcp_output.c |3 --- 2 files changed, 0 insertions(+), 4 deletions(-) diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index cd167a5..877239f 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -3879,7 +3879,6 @@ static void tcp_check_space(struct sock static inline void tcp_data_snd_check(struct sock *sk) { - struct tcp_sock *tp = tcp_sk(sk); tcp_push_pending_frames(sk); tcp_check_space(sk); } diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index 473ec06..d17159a 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -1441,7 +1441,6 @@ static int tcp_write_xmit(struct sock *s void __tcp_push_pending_frames(struct sock *sk, unsigned int cur_mss, int nonagle) { - struct tcp_sock *tp = tcp_sk(sk); struct sk_buff *skb = tcp_send_head(sk); if (skb) { @@ -2039,7 +2038,6 @@ void tcp_send_fin(struct sock *sk) */ void tcp_send_active_reset(struct sock *sk, gfp_t priority) { - struct tcp_sock *tp = tcp_sk(sk); struct sk_buff *skb; /* NOTE: No TCP options attached and we never retransmit this. */ @@ -2369,7 +2367,6 @@ void tcp_send_ack(struct sock *sk) { /* If we have been reset, we may not send again. */ if (sk-sk_state != TCP_CLOSE) { - struct tcp_sock *tp = tcp_sk(sk); struct sk_buff *buff; /* We are not putting this on the write queue, so -- 1.4.2 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [TCP]: Added emptylines after the new tcp_sock *tp initialization
Improves readability a bit here and there (this is likely less than complete change anyway). Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] --- net/ipv4/tcp_input.c | 10 ++ net/ipv4/tcp_output.c |2 ++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 877239f..49af779 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -257,6 +257,7 @@ static void tcp_grow_window(struct sock struct sk_buff *skb) { struct tcp_sock *tp = tcp_sk(sk); + /* Check #1 */ if (tp-rcv_ssthresh tp-window_clamp (int)tp-rcv_ssthresh tcp_space(sk) @@ -1548,6 +1549,7 @@ static inline int tcp_skb_timedout(struc static inline int tcp_head_timedout(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); + return tp-packets_out tcp_skb_timedout(sk, tcp_write_queue_head(sk)); } @@ -1717,6 +1719,7 @@ static void tcp_add_reno_sack(struct soc static void tcp_remove_reno_sacks(struct sock *sk, int acked) { struct tcp_sock *tp = tcp_sk(sk); + if (acked 0) { /* One ACK acked hole. The rest eat duplicate ACKs. */ if (acked-1 = tp-sacked_out) @@ -1782,6 +1785,7 @@ static void tcp_mark_head_lost(struct so static void tcp_update_scoreboard(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); + if (IsFack(tp)) { int lost = tp-fackets_out - tp-reordering; if (lost = 0) @@ -1928,6 +1932,7 @@ static inline int tcp_may_undo(struct tc static int tcp_try_undo_recovery(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); + if (tcp_may_undo(tp)) { /* Happy end! We did not retransmit anything * or our original transmission succeeded. @@ -1955,6 +1960,7 @@ static int tcp_try_undo_recovery(struct static void tcp_try_undo_dsack(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); + if (tp-undo_marker !tp-undo_retrans) { DBGUNDO(sk, D-SACK); tcp_undo_cwr(sk, 1); @@ -1998,6 +2004,7 @@ static int tcp_try_undo_partial(struct s static int tcp_try_undo_loss(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); + if (tcp_may_undo(tp)) { struct sk_buff *skb; tcp_for_write_queue(skb, sk) { @@ -2033,6 +2040,7 @@ static inline void tcp_complete_cwr(stru static void tcp_try_to_open(struct sock *sk, int flag) { struct tcp_sock *tp = tcp_sk(sk); + tp-left_out = tp-sacked_out; if (tp-retrans_out == 0) @@ -2331,6 +2339,7 @@ static void tcp_cong_avoid(struct sock * static void tcp_ack_packets_out(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); + if (!tp-packets_out) { inet_csk_clear_xmit_timer(sk, ICSK_TIME_RETRANS); } else { @@ -3822,6 +3831,7 @@ void tcp_cwnd_application_limited(struct static int tcp_should_expand_sndbuf(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); + /* If the user specified a specific send buffer setting, do * not modify it. */ diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index d17159a..2634aee 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -66,6 +66,7 @@ static void update_send_head(struct sock struct sk_buff *skb) { struct tcp_sock *tp = tcp_sk(sk); + tcp_advance_send_head(sk, skb); tp-snd_nxt = TCP_SKB_CB(skb)-end_seq; tcp_packets_out_inc(sk, skb); @@ -80,6 +81,7 @@ static void update_send_head(struct sock static inline __u32 tcp_acceptable_seq(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); + if (!before(tp-snd_una+tp-snd_wnd, tp-snd_nxt)) return tp-snd_nxt; else -- 1.4.2 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.22 1/3] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)
This is fully automated change using this magic: sed -e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N' -e 's|struct sock \*sk,[\n\t ]*struct tcp_sock \*tp\([^{]*\n{\n\)| struct sock \*sk\1\tstruct tcp_sock *tp = tcp_sk(sk);\n|g' -e 's|struct sock \*sk, struct tcp_sock \*tp| struct sock \*sk|g' -e 's|sk, tp\([^-]\)|sk\1|g' Introduces four warnings that are fixed manually by the following patch. $ gcc --version gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) ... $ codiff -fV built-in.o.old built-in.o.new net/ipv4/route.c: rt_cache_flush | +14 1 function changed, 14 bytes added net/ipv4/tcp.c: tcp_setsockopt | -5 tcp_sendpage | -25 tcp_sendmsg| -16 3 functions changed, 46 bytes removed net/ipv4/tcp_input.c: tcp_try_undo_recovery | +3 tcp_try_undo_dsack| +2 tcp_mark_head_lost| -12 tcp_ack | -15 tcp_event_data_recv | -32 tcp_rcv_state_process | -10 tcp_rcv_established | +1 7 functions changed, 6 bytes added, 69 bytes removed, diff: -63 net/ipv4/tcp_output.c: update_send_head | -9 tcp_transmit_skb | +19 tcp_cwnd_validate | +1 tcp_write_wakeup | -17 __tcp_push_pending_frames | -25 tcp_push_one | -8 tcp_send_fin | -4 7 functions changed, 20 bytes added, 63 bytes removed, diff: -43 built-in.o.new: 18 functions changed, 40 bytes added, 178 bytes removed, diff: -138 Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] --- include/net/tcp.h | 20 --- include/net/tcp_ecn.h |6 +- net/ipv4/tcp.c| 35 +++-- net/ipv4/tcp_input.c | 131 - net/ipv4/tcp_output.c | 48 ++ 5 files changed, 136 insertions(+), 104 deletions(-) diff --git a/include/net/tcp.h b/include/net/tcp.h index 07f724e..19cf5d5 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -420,9 +420,9 @@ extern __u32 cookie_v4_init_sequence(str /* tcp_output.c */ -extern void __tcp_push_pending_frames(struct sock *sk, struct tcp_sock *tp, +extern void __tcp_push_pending_frames(struct sock *sk, unsigned int cur_mss, int nonagle); -extern int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp); +extern int tcp_may_send_now(struct sock *sk); extern int tcp_retransmit_skb(struct sock *, struct sk_buff *); extern void tcp_xmit_retransmit_queue(struct sock *); extern void tcp_simple_retransmit(struct sock *); @@ -479,8 +479,9 @@ static inline void tcp_fast_path_on(stru __tcp_fast_path_on(tp, tp-snd_wnd tp-rx_opt.snd_wscale); } -static inline void tcp_fast_path_check(struct sock *sk, struct tcp_sock *tp) +static inline void tcp_fast_path_check(struct sock *sk) { + struct tcp_sock *tp = tcp_sk(sk); if (skb_queue_empty(tp-out_of_order_queue) tp-rcv_wnd atomic_read(sk-sk_rmem_alloc) sk-sk_rcvbuf @@ -591,10 +592,10 @@ static inline void tcp_dec_pcount_approx } } -static inline void tcp_packets_out_inc(struct sock *sk, - struct tcp_sock *tp, +static inline void tcp_packets_out_inc(struct sock *sk, const struct sk_buff *skb) { + struct tcp_sock *tp = tcp_sk(sk); int orig = tp-packets_out; tp-packets_out += tcp_skb_pcount(skb); @@ -778,18 +779,19 @@ static inline void tcp_minshall_update(s tp-snd_sml = TCP_SKB_CB(skb)-end_seq; } -static inline void tcp_check_probe_timer(struct sock *sk, struct tcp_sock *tp) +static inline void tcp_check_probe_timer(struct sock *sk) { + struct tcp_sock *tp = tcp_sk(sk); const struct inet_connection_sock *icsk = inet_csk(sk); if (!tp-packets_out !icsk-icsk_pending) inet_csk_reset_xmit_timer(sk, ICSK_TIME_PROBE0, icsk-icsk_rto, TCP_RTO_MAX); } -static inline void tcp_push_pending_frames(struct sock *sk, - struct tcp_sock *tp) +static inline void tcp_push_pending_frames(struct sock *sk) { - __tcp_push_pending_frames(sk, tp, tcp_current_mss(sk, 1), tp-nonagle); + struct tcp_sock *tp = tcp_sk(sk); + __tcp_push_pending_frames(sk, tcp_current_mss(sk, 1), tp-nonagle); } static inline void tcp_init_wl(struct tcp_sock *tp, u32 ack, u32 seq) diff --git a/include/net/tcp_ecn.h b/include/net/tcp_ecn.h index b5f7c6a..f3043d2 100644 --- a/include/net/tcp_ecn.h +++ b/include/net/tcp_ecn.h @@ -27,9 +27,10 @@ static inline void TCP_ECN_send_synack(s TCP_SKB_CB(skb)-flags = ~TCPCB_FLAG_ECE; } -static inline void TCP_ECN_send_syn(struct sock *sk, struct tcp_sock *tp, +static inline void TCP_ECN_send_syn(struct sock *sk, struct sk_buff *skb) { + struct tcp_sock *tp = tcp_sk(sk);
Re: [PATCH] Don't attach callback to a going-away netlink socket
Pavel Emelianov wrote: Patrick McHardy wrote: There is a race between netlink_dump_start() and netlink_release() that can lead to the situation when a netlink socket with non-zero callback is freed. Can you describe the race in more detail please? Here it is: [...] The proposal it to make sock_orphan before detaching the callback in netlink_release() and to check for the sock to be SOCK_DEAD in netlink_dump_start() before setting a new callback. Thanks, good catch. Your patch also looks good. Acked-by: Patrick McHardy [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.22 1/3] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)
It would be easier if you sent all bits in a single patch, it's one logical change after all, and a rather small one aswell. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.22 1/3] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)
On Mon, 16 Apr 2007, Christoph Hellwig wrote: It would be easier if you sent all bits in a single patch, it's one logical change after all, and a rather small one aswell. Here it is the way you requested... [PATCH] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...) This is (mostly) automated change using this magic: sed -e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N' -e 's|struct sock \*sk,[\n\t ]*struct tcp_sock \*tp\([^{]*\n{\n\)| struct sock \*sk\1\tstruct tcp_sock *tp = tcp_sk(sk);\n|g' -e 's|struct sock \*sk, struct tcp_sock \*tp| struct sock \*sk|g' -e 's|sk, tp\([^-]\)|sk\1|g' Tweaked newlines manually fixed four warnings that were introduced. $ gcc --version gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) ... $ codiff -f built-in.o.old built-in.o.new net/ipv4/route.c: rt_cache_flush | +14 1 function changed, 14 bytes added net/ipv4/tcp.c: tcp_setsockopt | -5 tcp_sendpage | -25 tcp_sendmsg| -16 3 functions changed, 46 bytes removed net/ipv4/tcp_input.c: tcp_try_undo_recovery | +3 tcp_try_undo_dsack| +2 tcp_mark_head_lost| -12 tcp_ack | -15 tcp_event_data_recv | -32 tcp_rcv_state_process | -10 tcp_rcv_established | +1 7 functions changed, 6 bytes added, 69 bytes removed, diff: -63 net/ipv4/tcp_output.c: update_send_head | -9 tcp_transmit_skb | +19 tcp_cwnd_validate | +1 tcp_write_wakeup | -17 __tcp_push_pending_frames | -25 tcp_push_one | -8 tcp_send_fin | -4 7 functions changed, 20 bytes added, 63 bytes removed, diff: -43 built-in.o.new: 18 functions changed, 40 bytes added, 178 bytes removed, diff: -138 Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] --- include/net/tcp.h | 20 --- include/net/tcp_ecn.h |6 +- net/ipv4/tcp.c| 35 +++- net/ipv4/tcp_input.c | 140 + net/ipv4/tcp_output.c | 51 ++ 5 files changed, 146 insertions(+), 106 deletions(-) diff --git a/include/net/tcp.h b/include/net/tcp.h index 07f724e..19cf5d5 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -420,9 +420,9 @@ extern __u32 cookie_v4_init_sequence(str /* tcp_output.c */ -extern void __tcp_push_pending_frames(struct sock *sk, struct tcp_sock *tp, +extern void __tcp_push_pending_frames(struct sock *sk, unsigned int cur_mss, int nonagle); -extern int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp); +extern int tcp_may_send_now(struct sock *sk); extern int tcp_retransmit_skb(struct sock *, struct sk_buff *); extern void tcp_xmit_retransmit_queue(struct sock *); extern void tcp_simple_retransmit(struct sock *); @@ -479,8 +479,9 @@ static inline void tcp_fast_path_on(stru __tcp_fast_path_on(tp, tp-snd_wnd tp-rx_opt.snd_wscale); } -static inline void tcp_fast_path_check(struct sock *sk, struct tcp_sock *tp) +static inline void tcp_fast_path_check(struct sock *sk) { + struct tcp_sock *tp = tcp_sk(sk); if (skb_queue_empty(tp-out_of_order_queue) tp-rcv_wnd atomic_read(sk-sk_rmem_alloc) sk-sk_rcvbuf @@ -591,10 +592,10 @@ static inline void tcp_dec_pcount_approx } } -static inline void tcp_packets_out_inc(struct sock *sk, - struct tcp_sock *tp, +static inline void tcp_packets_out_inc(struct sock *sk, const struct sk_buff *skb) { + struct tcp_sock *tp = tcp_sk(sk); int orig = tp-packets_out; tp-packets_out += tcp_skb_pcount(skb); @@ -778,18 +779,19 @@ static inline void tcp_minshall_update(s tp-snd_sml = TCP_SKB_CB(skb)-end_seq; } -static inline void tcp_check_probe_timer(struct sock *sk, struct tcp_sock *tp) +static inline void tcp_check_probe_timer(struct sock *sk) { + struct tcp_sock *tp = tcp_sk(sk); const struct inet_connection_sock *icsk = inet_csk(sk); if (!tp-packets_out !icsk-icsk_pending) inet_csk_reset_xmit_timer(sk, ICSK_TIME_PROBE0, icsk-icsk_rto, TCP_RTO_MAX); } -static inline void tcp_push_pending_frames(struct sock *sk, - struct tcp_sock *tp) +static inline void tcp_push_pending_frames(struct sock *sk) { - __tcp_push_pending_frames(sk, tp, tcp_current_mss(sk, 1), tp-nonagle); + struct tcp_sock *tp = tcp_sk(sk); + __tcp_push_pending_frames(sk, tcp_current_mss(sk, 1), tp-nonagle); } static inline void tcp_init_wl(struct tcp_sock *tp, u32 ack, u32 seq) diff --git a/include/net/tcp_ecn.h b/include/net/tcp_ecn.h index b5f7c6a..f3043d2 100644 --- a/include/net/tcp_ecn.h +++ b/include/net/tcp_ecn.h @@ -27,9 +27,10 @@ static inline void TCP_ECN_send_synack(s
Re: [PATCH net-2.6.22 1/3] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)
Ilpo Järvinen wrote: Tweaked newlines manually fixed four warnings that were introduced. Not all of them it seems: -static inline void tcp_fast_path_check(struct sock *sk, struct tcp_sock *tp) +static inline void tcp_fast_path_check(struct sock *sk) { + struct tcp_sock *tp = tcp_sk(sk); ^ missing newline if (skb_queue_empty(tp-out_of_order_queue) tp-rcv_wnd atomic_read(sk-sk_rmem_alloc) sk-sk_rcvbuf @@ -778,18 +779,19 @@ static inline void tcp_minshall_update(s tp-snd_sml = TCP_SKB_CB(skb)-end_seq; } -static inline void tcp_check_probe_timer(struct sock *sk, struct tcp_sock *tp) +static inline void tcp_check_probe_timer(struct sock *sk) { + struct tcp_sock *tp = tcp_sk(sk); ^ same here .. quite a few follow const struct inet_connection_sock *icsk = inet_csk(sk); if (!tp-packets_out !icsk-icsk_pending) inet_csk_reset_xmit_timer(sk, ICSK_TIME_PROBE0, icsk-icsk_rto, TCP_RTO_MAX); } - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] e100 driver on ARM
Lennart Sorensen wrote: Which PCI host controller are you using with the PXA255? We tried using a PXA255 based system with a PCI controller a couple of years ago and have to change to a different cpu in the end due to the PCI controller simply not being valid PCI. The PXA255 wasn't designed for PCI, and I get the impression that non of the PCI companion chips for it do a good enough job to actually add it correctly. Sorry for the delay in responding...my wife and I just had twins! We are using the IT8152G RISC-to-PCI companion chip. -Ack - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.22 1/3] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)
On Mon, 16 Apr 2007, Patrick McHardy wrote: Ilpo Järvinen wrote: Tweaked newlines manually fixed four warnings that were introduced. Not all of them it seems: -static inline void tcp_fast_path_check(struct sock *sk, struct tcp_sock *tp) +static inline void tcp_fast_path_check(struct sock *sk) { + struct tcp_sock *tp = tcp_sk(sk); ^ missing newline ...in the other (original) patch description that is not copied fully here I had a sort of disclaimer for these missing ones but in case they should all be changed so that if the added tcp_sock is the only local variable I can do that of course... It's not clear to me what is really the preferred style considering all the variants... E.g., tcp_check_probe_timer (below) does not have the newline before this patch either?!? :-) ...tried to look from CodingStyle too but it didn't give any light to this thing... if (skb_queue_empty(tp-out_of_order_queue) tp-rcv_wnd atomic_read(sk-sk_rmem_alloc) sk-sk_rcvbuf @@ -778,18 +779,19 @@ static inline void tcp_minshall_update(s tp-snd_sml = TCP_SKB_CB(skb)-end_seq; } -static inline void tcp_check_probe_timer(struct sock *sk, struct tcp_sock *tp) +static inline void tcp_check_probe_timer(struct sock *sk) { + struct tcp_sock *tp = tcp_sk(sk); ^ same here .. quite a few follow const struct inet_connection_sock *icsk = inet_csk(sk); ...No newline should be place here, since it's being followed by another local variable defination. if (!tp-packets_out !icsk-icsk_pending) inet_csk_reset_xmit_timer(sk, ICSK_TIME_PROBE0, icsk-icsk_rto, TCP_RTO_MAX); } -- i.
Re: [PATCH net-2.6.22 1/3] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)
Ilpo Järvinen wrote: On Mon, 16 Apr 2007, Patrick McHardy wrote: [...] ...in the other (original) patch description that is not copied fully here I had a sort of disclaimer for these missing ones but in case they should all be changed so that if the added tcp_sock is the only local variable I can do that of course... It's not clear to me what is really the preferred style considering all the variants... E.g., tcp_check_probe_timer (below) does not have the newline before this patch either?!? :-) ...tried to look from CodingStyle too but it didn't give any light to this thing... The preferred style is a newline after variable declarations. Some (mostly old) code doesn't consistently do that, but in cases where you add the first local variable you should really add them. const struct inet_connection_sock *icsk = inet_csk(sk); ...No newline should be place here, since it's being followed by another local variable defination. Yes, this one was a mistake. In this case I would probably leave it as it was before to avoid bloating the patch, but I guess nobody would mind if you'd add newlines here as well, the patch is not very large or hard to understand anyway. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.22 1/3] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)
On Mon, 16 Apr 2007, Patrick McHardy wrote: Ilpo Järvinen wrote: On Mon, 16 Apr 2007, Patrick McHardy wrote: [...] It's not clear to me what is really the preferred style considering all the variants... [...] The preferred style is a newline after variable declarations. Some (mostly old) code doesn't consistently do that, but in cases where you add the first local variable you should really add them. Just to make sure... And this holds in all cases, e.g., in 2 lines functions too like tcp_push_pending_frames? Maybe I'm just being too picky or something... :-) -- i.
Re: [PATCH net-2.6.22 1/3] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)
On Mon, 16 Apr 2007, Patrick McHardy wrote: The preferred style is a newline after variable declarations. Some (mostly old) code doesn't consistently do that, but in cases where you add the first local variable you should really add them. ...No newline should be place here, since it's being followed by another local variable defination. Yes, this one was a mistake. In this case I would probably leave it as it was before to avoid bloating the patch, but I guess nobody would mind if you'd add newlines here as well, the patch is not very large or hard to understand anyway. I made these changes then: - Added newlines after local variables in the functions that had *tp added (assuming that the first line after the local variables is visible in the context of the diff) - Refitted arguments to 80 chars [PATCH] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...) This is (mostly) automated change using magic: sed -e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N' -e 's|struct sock \*sk,[\n\t ]*struct tcp_sock \*tp\([^{]*\n{\n\)| struct sock \*sk\1\tstruct tcp_sock *tp = tcp_sk(sk);\n|g' -e 's|struct sock \*sk, struct tcp_sock \*tp| struct sock \*sk|g' -e 's|sk, tp\([^-]\)|sk\1|g' Fixed four unused variable (tp) warnings that were introduced. In addition, manually added newlines after local variables and tweaked function arguments positioning. $ gcc --version gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) ... $ codiff -fV built-in.o.old built-in.o.new net/ipv4/route.c: rt_cache_flush | +14 1 function changed, 14 bytes added net/ipv4/tcp.c: tcp_setsockopt | -5 tcp_sendpage | -25 tcp_sendmsg| -16 3 functions changed, 46 bytes removed net/ipv4/tcp_input.c: tcp_try_undo_recovery | +3 tcp_try_undo_dsack| +2 tcp_mark_head_lost| -12 tcp_ack | -15 tcp_event_data_recv | -32 tcp_rcv_state_process | -10 tcp_rcv_established | +1 7 functions changed, 6 bytes added, 69 bytes removed, diff: -63 net/ipv4/tcp_output.c: update_send_head | -9 tcp_transmit_skb | +19 tcp_cwnd_validate | +1 tcp_write_wakeup | -17 __tcp_push_pending_frames | -25 tcp_push_one | -8 tcp_send_fin | -4 7 functions changed, 20 bytes added, 63 bytes removed, diff: -43 built-in.o.new: 18 functions changed, 40 bytes added, 178 bytes removed, diff: -138 Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] --- include/net/tcp.h | 25 +--- include/net/tcp_ecn.h | 11 ++-- net/ipv4/tcp.c| 39 +++-- net/ipv4/tcp_input.c | 145 + net/ipv4/tcp_output.c | 54 ++ 5 files changed, 158 insertions(+), 116 deletions(-) diff --git a/include/net/tcp.h b/include/net/tcp.h index 07f724e..fffd063 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -420,9 +420,9 @@ extern __u32 cookie_v4_init_sequence(str /* tcp_output.c */ -extern void __tcp_push_pending_frames(struct sock *sk, struct tcp_sock *tp, - unsigned int cur_mss, int nonagle); -extern int tcp_may_send_now(struct sock *sk, struct tcp_sock *tp); +extern void __tcp_push_pending_frames(struct sock *sk, unsigned int cur_mss, + int nonagle); +extern int tcp_may_send_now(struct sock *sk); extern int tcp_retransmit_skb(struct sock *, struct sk_buff *); extern void tcp_xmit_retransmit_queue(struct sock *); extern void tcp_simple_retransmit(struct sock *); @@ -479,8 +479,10 @@ static inline void tcp_fast_path_on(stru __tcp_fast_path_on(tp, tp-snd_wnd tp-rx_opt.snd_wscale); } -static inline void tcp_fast_path_check(struct sock *sk, struct tcp_sock *tp) +static inline void tcp_fast_path_check(struct sock *sk) { + struct tcp_sock *tp = tcp_sk(sk); + if (skb_queue_empty(tp-out_of_order_queue) tp-rcv_wnd atomic_read(sk-sk_rmem_alloc) sk-sk_rcvbuf @@ -591,10 +593,10 @@ static inline void tcp_dec_pcount_approx } } -static inline void tcp_packets_out_inc(struct sock *sk, - struct tcp_sock *tp, +static inline void tcp_packets_out_inc(struct sock *sk, const struct sk_buff *skb) { + struct tcp_sock *tp = tcp_sk(sk); int orig = tp-packets_out; tp-packets_out += tcp_skb_pcount(skb); @@ -778,18 +780,21 @@ static inline void tcp_minshall_update(s tp-snd_sml = TCP_SKB_CB(skb)-end_seq; } -static inline void tcp_check_probe_timer(struct sock *sk, struct tcp_sock *tp) +static inline void tcp_check_probe_timer(struct sock *sk) { + struct tcp_sock *tp = tcp_sk(sk); const struct inet_connection_sock *icsk = inet_csk(sk); + if (!tp-packets_out !icsk-icsk_pending)
RE: 2.6.21rc7 e1000 media-detect oddness.
Dave Jones wrote: I booted up 2.6.21rc7 without an ethernet cable plugged in, and noticed this.. e1000: :02:00.0: e1000_probe: The EEPROM Checksum Is Not Valid e1000: probe of :02:00.0 failed with error -5 I plugged a cable in, did rmmod e1000;modprobe e1000, and got this.. e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:d3:3a:62:d3 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO and it works fine.. Why would no cable make it think the EEPROM is invalid ? There was a similar issue reported a while back on T60 and it had to do with power management: http://forums.gentoo.org/viewtopic-t-476305-highlight-e1000.html Some questions: What was the system in your case (lspci -vv)? I repeated this a few times, just to be sure it wasn't a fluke, and it seems to happen 100% reproducably. Can you reproduce this with the latest driver from e1000.sf.net? Thanks, Emil - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] NetXen: Multi PCI support for Quad cards
On Fri, 13 Apr 2007 08:39:31 -0700 Linsys Contractor Mithlesh Thukral [EMAIL PROTECTED] wrote: NetXen: Fix the multi PCI function for cards with more than 2 ports. This patch fixes the working of multi PCI capable driver on cards with more than 2 ports by adding the addresses for their rings and sizes. Signed-off by: Mithlesh Thukral [EMAIL PROTECTED] --- drivers/net/netxen/netxen_nic_hw.c | 119 +++-- drivers/net/netxen/netxen_nic_init.c |4 drivers/net/netxen/netxen_nic_main.c | 61 +- drivers/net/netxen/netxen_nic_phan_reg.h |6 - 4 files changed, 146 insertions(+), 44 deletions(-) diff --git a/drivers/net/netxen/netxen_nic_hw.c b/drivers/net/netxen/netxen_nic_hw.c index a066208..274a261 100644 --- a/drivers/net/netxen/netxen_nic_hw.c +++ b/drivers/net/netxen/netxen_nic_hw.c @@ -140,8 +140,105 @@ struct netxen_recv_crb recv_crb_register NETXEN_NIC_REG(0x180), /* crb_status_ring_size */ NETXEN_NIC_REG(0x184), - }, + /* + * Instance 3, + */ + { + { + { + /* crb_rcv_producer_offset: */ + NETXEN_NIC_REG(0x1d8), + /* crb_rcv_consumer_offset: */ + NETXEN_NIC_REG(0x1dc), + /* crb_gloablrcv_ring: */ + NETXEN_NIC_REG(0x1f0), + /* crb_rcv_ring_size */ + NETXEN_NIC_REG(0x1f4), + }, + /* Jumbo frames */ + { + /* crb_rcv_producer_offset: */ + NETXEN_NIC_REG(0x1f8), + /* crb_rcv_consumer_offset: */ + NETXEN_NIC_REG(0x1fc), + /* crb_gloablrcv_ring: */ + NETXEN_NIC_REG(0x200), + /* crb_rcv_ring_size */ + NETXEN_NIC_REG(0x204), + }, + /* LRO */ + { + /* crb_rcv_producer_offset: */ + NETXEN_NIC_REG(0x208), + /* crb_rcv_consumer_offset: */ + NETXEN_NIC_REG(0x20c), + /* crb_gloablrcv_ring: */ + NETXEN_NIC_REG(0x210), + /* crb_rcv_ring_size */ + NETXEN_NIC_REG(0x214), + } + }, + /* crb_rcvstatus_ring: */ + NETXEN_NIC_REG(0x218), + /* crb_rcv_status_producer: */ + NETXEN_NIC_REG(0x21c), + /* crb_rcv_status_consumer: */ + NETXEN_NIC_REG(0x220), + /* crb_rcvpeg_state: */ + NETXEN_NIC_REG(0x224), + /* crb_status_ring_size */ + NETXEN_NIC_REG(0x228), + }, + /* + * Instance 4, + */ + { + { + { + /* crb_rcv_producer_offset: */ + NETXEN_NIC_REG(0x22c), + /* crb_rcv_consumer_offset: */ + NETXEN_NIC_REG(0x230), + /* crb_gloablrcv_ring: */ + NETXEN_NIC_REG(0x234), + /* crb_rcv_ring_size */ + NETXEN_NIC_REG(0x238), + }, + /* Jumbo frames */ + { + /* crb_rcv_producer_offset: */ + NETXEN_NIC_REG(0x23c), + /* crb_rcv_consumer_offset: */ + NETXEN_NIC_REG(0x240), + /* crb_gloablrcv_ring: */ + NETXEN_NIC_REG(0x244), + /* crb_rcv_ring_size */ + NETXEN_NIC_REG(0x248), + }, + /* LRO */ + { + /* crb_rcv_producer_offset: */ + NETXEN_NIC_REG(0x24c), + /* crb_rcv_consumer_offset: */ + NETXEN_NIC_REG(0x250), + /* crb_gloablrcv_ring: */ + NETXEN_NIC_REG(0x254), + /* crb_rcv_ring_size */ + NETXEN_NIC_REG(0x258), + } + }, + /* crb_rcvstatus_ring: */ + NETXEN_NIC_REG(0x25c), + /* crb_rcv_status_producer: */ + NETXEN_NIC_REG(0x260), + /* crb_rcv_status_consumer: */ + NETXEN_NIC_REG(0x264), + /* crb_rcvpeg_state: */ + NETXEN_NIC_REG(0x268), + /* crb_status_ring_size */ + NETXEN_NIC_REG(0x26c), + }, }; u64 ctx_addr_sig_regs[][3] = { @@ -294,6 +391,7 @@ int netxen_nic_hw_resources(struct netxe u32 card_cmdring = 0; struct netxen_recv_context *recv_ctx; struct netxen_rcv_desc_ctx *rcv_desc; + int func_id = adapter-portnum; DPRINTK(INFO, crb_base: %lx %x, NETXEN_PCI_CRBSPACE, PCI_OFFSET_SECOND_RANGE(adapter, NETXEN_PCI_CRBSPACE)); @@ -341,7 +439,7 @@ int netxen_nic_hw_resources(struct netxe adapter-ctx_desc_pdev); printk(KERN_INFO ctx_desc_phys_addr: 0x%llx\n, -(unsigned long long) adapter-ctx_desc_phys_addr); +(u64) adapter-ctx_desc_phys_addr); This will give a warning on 64 bit platforms because format doesn't match width. You need to cast to (unsigned long long). - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP connection stops after high load.
Robert Iakobashvili wrote: Hi John, On 4/15/07, John Heffner [EMAIL PROTECTED] wrote: Robert Iakobashvili wrote: Vanilla 2.6.18.3 works for me perfectly, whereas 2.6.19.5 and 2.6.20.6 do not. Looking into the tcp /proc entries of 2.6.18.3 versus 2.6.19.5 tcp_rmem and tcp_wmem are the same, whereas tcp_mem are much different: kernel tcp_mem --- 2.6.18.312288 16384 24576 2.6.19.5 30724096 6144 Another patch that went in right around that time: commit 52bf376c63eebe72e862a1a6e713976b038c3f50 Author: John Heffner [EMAIL PROTECTED] Date: Tue Nov 14 20:25:17 2006 -0800 [TCP]: Fix up sysctl_tcp_mem initialization. (This has been changed again for 2.6.21.) In the dmesg, there should be some messages like this: IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) What do yours say? For the 2.6.19.5, where we have this problem: From dmsg: IP route cache hash table entries: 4096 (order: 2, 16384 bytes) TCP established hash table entries: 16384 (order: 5, 131072 bytes) TCP bind hash table entries: 8192 (order: 4, 65536 bytes) #cat /proc/sys/net/ipv4/tcp_mem 307240966144 MemTotal: 484368 kB CONFIG_HIGHMEM4G=y Yes, this difference is caused by the commit above. The old way didn't really make a lot of sense, since it was different based on smp/non-smp and page size, and had large discontinuities at 512MB and every power of two. It was hard to make the limit never larger than the memory pool but never too small either, when based on the hash table size. The current net-2.6 (2.6.21) has a redesigned tcp_mem initialization that should give you more appropriate values, something like 45408 60546 90816. For reference: Commit: 53cdcc04c1e85d4e423b2822b66149b6f2e52c2c Author: John Heffner [EMAIL PROTECTED] Fri, 16 Mar 2007 15:04:03 -0700 [TCP]: Fix tcp_mem[] initialization. Change tcp_mem initialization function. The fraction of total memory is now a continuous function of memory size, and independent of page size. Signed-off-by: John Heffner [EMAIL PROTECTED] Signed-off-by: David S. Miller [EMAIL PROTECTED] Thanks, -John - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] netconsole hangs machine 2.6.20
[cc:ed to netdev] On Sun, Apr 15, 2007 at 10:45:37PM -0700, Mike Mattie wrote: Hello, netconsole is hanging my box during IDE init. I am running 2.6.20.7, config is attached from /proc Without using netconsole the kernel boots fine. I am writing this message from it. When I do enable net-console I get from the linux banner to a couple of lines after sanitize end on the logging client ( Mac OS X 10.4 , simple nc listener ) The boot continues until hde (handled by the HPT366 driver, hdg is the last drive ) and then the kernel just hangs. I don't really have a theory for that. What NIC are you using? Looks like VIA Rhine? Is it sharing an IRQ with your IDE interface? Please post your boot messages with debug on the kernel command line. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intermittant petabyte usage reported with broadcom nic
On Sat, 2007-04-14 at 17:20 -0700, Michael Chan wrote: I also like Andi's idea of using change_page_attr() to isolate the problem. I'll try to send you a debug patch in the next few days to try that out. Thanks. Here's the debug patch for x86 only that will change the statistics memory block to read-only. If the kernel is corrupting it, you should get a page fault that will crash the system. If you continue to see bogus counters, it is definitely a firmware or hardware problem. Please try it and let me know. Thanks. diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c index 0b7aded..b7d491b 100644 --- a/drivers/net/bnx2.c +++ b/drivers/net/bnx2.c @@ -47,6 +47,7 @@ #include linux/prefetch.h #include linux/cache.h #include linux/zlib.h +#include asm/cacheflush.h #include bnx2.h #include bnx2_fw.h @@ -436,6 +437,8 @@ bnx2_free_mem(struct bnx2 *bp) } } if (bp-status_blk) { + change_page_attr(virt_to_page(bp-status_blk), 1, PAGE_KERNEL); + global_flush_tlb(); pci_free_consistent(bp-pdev, bp-status_stats_size, bp-status_blk, bp-status_blk_mapping); bp-status_blk = NULL; @@ -501,6 +504,7 @@ bnx2_alloc_mem(struct bnx2 *bp) bp-status_stats_size = status_blk_size + sizeof(struct statistics_block); + bp-status_stats_size = PAGE_SIZE; bp-status_blk = pci_alloc_consistent(bp-pdev, bp-status_stats_size, bp-status_blk_mapping); if (bp-status_blk == NULL) @@ -508,6 +512,10 @@ bnx2_alloc_mem(struct bnx2 *bp) memset(bp-status_blk, 0, bp-status_stats_size); + /* x86 debug code to see if the kernel is corrupting the statistics */ + change_page_attr(virt_to_page(bp-status_blk), 1, PAGE_KERNEL_RO); + global_flush_tlb(); + bp-stats_blk = (void *) ((unsigned long) bp-status_blk + status_blk_size); @@ -4307,7 +4315,9 @@ bnx2_timer(unsigned long data) msg = (u32) ++bp-fw_drv_pulse_wr_seq; REG_WR_IND(bp, bp-shmem_base + BNX2_DRV_PULSE_MB, msg); +#if 0 bp-stats_blk-stat_FwRxDrop = REG_RD_IND(bp, BNX2_FW_RX_DROP_COUNT); +#endif if (bp-phy_flags PHY_SERDES_FLAG) { if (CHIP_NUM(bp) == CHIP_NUM_5706) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP connection stops after high load.
Robert Iakobashvili wrote: Vanilla 2.6.18.3 works for me perfectly, whereas 2.6.19.5 and 2.6.20.6 do not. Looking into the tcp /proc entries of 2.6.18.3 versus 2.6.19.5 tcp_rmem and tcp_wmem are the same, whereas tcp_mem are much different: kernel tcp_mem --- 2.6.18.312288 16384 24576 2.6.19.5 30724096 6144 Another patch that went in right around that time: commit 52bf376c63eebe72e862a1a6e713976b038c3f50 Author: John Heffner [EMAIL PROTECTED] Date: Tue Nov 14 20:25:17 2006 -0800 [TCP]: Fix up sysctl_tcp_mem initialization. (This has been changed again for 2.6.21.) Yes, this difference is caused by the commit above. The current net-2.6 (2.6.21) has a redesigned tcp_mem initialization that should give you more appropriate values, something like 45408 60546 90816. For reference: Commit: 53cdcc04c1e85d4e423b2822b66149b6f2e52c2c Author: John Heffner [EMAIL PROTECTED] Fri, 16 Mar 2007 15:04:03 -0700 [TCP]: Fix tcp_mem[] initialization. Change tcp_mem initialization function. The fraction of total memory is now a continuous function of memory size, and independent of page size. Kernels 2.6.19 and 2.6.20 series are effectively broken right now. Don't you wish to patch them? -- Sincerely, Robert Iakobashvili, coroberti %x40 gmail %x2e com ... Navigare necesse est, vivere non est necesse ... http://curl-loader.sourceforge.net An open-source HTTP/S, FTP/S traffic generating, and web testing tool. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP connection stops after high load.
Robert Iakobashvili wrote: Kernels 2.6.19 and 2.6.20 series are effectively broken right now. Don't you wish to patch them? I don't know if this qualifies as an unconditional bug. The commit above was actually a bugfix so that the limits were not higher than total memory on some systems, but had the side effect that it made them even smaller on your particular configuration. Also, having initial sysctl values that are conservatively small probably doesn't qualify as a bug (for patching stable trees). You might ask the -stable maintainers if they have a different opinion. For most people, 2.6.19 and 2.6.20 work fine. For those who really care about the tcp_mem values (are using a substantial fraction of physical memory for TCP connections), the best bet is to set the tcp_mem sysctl values in the startup scripts, or use the new initialization function in 2.6.21. Thanks, -John - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP connection stops after high load.
From: Robert Iakobashvili [EMAIL PROTECTED] Date: Mon, 16 Apr 2007 20:51:54 +0200 Commit: 53cdcc04c1e85d4e423b2822b66149b6f2e52c2c Author: John Heffner [EMAIL PROTECTED] Fri, 16 Mar 2007 15:04:03 -0700 [TCP]: Fix tcp_mem[] initialization. Change tcp_mem initialization function. The fraction of total memory is now a continuous function of memory size, and independent of page size. Kernels 2.6.19 and 2.6.20 series are effectively broken right now. Don't you wish to patch them? Can you verify that this patch actually fixes your problem? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP connection stops after high load.
From: John Heffner [EMAIL PROTECTED] Date: Mon, 16 Apr 2007 15:11:07 -0400 I don't know if this qualifies as an unconditional bug. The commit above was actually a bugfix so that the limits were not higher than total memory on some systems, but had the side effect that it made them even smaller on your particular configuration. Also, having initial sysctl values that are conservatively small probably doesn't qualify as a bug (for patching stable trees). You might ask the -stable maintainers if they have a different opinion. For most people, 2.6.19 and 2.6.20 work fine. For those who really care about the tcp_mem values (are using a substantial fraction of physical memory for TCP connections), the best bet is to set the tcp_mem sysctl values in the startup scripts, or use the new initialization function in 2.6.21. What's most important is determining if that tcp_mem[] patch actually fixes his problem, so it is his responsibility to see whether this is the case. If it does fix the problem, I'm happy to submit the backport to -stable. But until such tests are made, it's just speculation whether the patch fixes the problem or not, and therefore there is zero justification to submit it to -stable. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.21rc7 e1000 media-detect oddness.
On 4/15/07, Dave Jones [EMAIL PROTECTED] wrote: I booted up 2.6.21rc7 without an ethernet cable plugged in, and noticed this.. e1000: :02:00.0: e1000_probe: The EEPROM Checksum Is Not Valid e1000: probe of :02:00.0 failed with error -5 I plugged a cable in, did rmmod e1000;modprobe e1000, and got this.. e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:d3:3a:62:d3 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO and it works fine.. Why would no cable make it think the EEPROM is invalid ? I repeated this a few times, just to be sure it wasn't a fluke, and it seems to happen 100% reproducably. This is a known issue, having to do with a power saving mode on the PCIe side of the adapter, that is enabled when link is down. There are several fixes, an eeprom fix, or changing the code to call e1000_validate_eeprom_checksum twice in a row if the first fails. this bug has some text about this and an attachment with the fix script http://sourceforge.net/tracker/index.php?func=detailaid=1474679group_id=42302atid=447449 Jesse - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
r8169 2.2LK: Low link speed after suspend
Greetings! I have a SuSE 10.2 64-bit installation that uses a Realtek PCI GbE chip in D-Link disguise (lspci see below). While this works rather well after a normal boot sequence, I don't get a gigabit link after resume from standby or suspend-to-disk. Entering standby, the link speed goes down to 100 Mb as expected; the link stays up during standby/suspend (for WOL purposes apparently). Now after resume, the link is working OK but doesn't come back up to normal gigabit operation. ifdown, unloading and reloading the r8169 module, and then ifup again fixes it. If there's something more I can do to help debug this, please let me know. Please be sure to copy me, since my list traffic here is still somewhat unreliable. Thanks. regards, Peter 00:0d.0 Ethernet controller: D-Link System Inc DGE-528T Gigabit Ethernet Adapter (rev 10) Subsystem: D-Link System Inc DGE-528T Gigabit Ethernet Adapter Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 (8000ns min, 16000ns max), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 185 Region 0: I/O ports at eb00 [size=256] Region 1: Memory at e812c000 (32-bit, non-prefetchable) [size=256] [virtual] Expansion ROM at 5002 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 86 11 00 43 17 00 b0 02 10 00 00 02 10 20 00 00 10: 01 eb 00 00 00 c0 12 e8 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 11 00 43 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 20 40 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 c2 f7 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8338] New: NAT of TCP connections broken
On Mon, 16 Apr 2007 13:35:47 -0700 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8338 Summary: NAT of TCP connections broken Kernel Version: 2.6.20.7 Status: NEW Severity: high Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did *NOT* occur: 2.6.18 Distribution: Debian Hardware Environment: amd64 4200x2 Software Environment: Problem Description: I'm using my debian box for sharing internet connection. After update to debian's 2.6.20 kernel (and adjusting new kernel configuration for NAT) NAT of TCP connections stoped working, while ICMP and UDP is working (ping, traceroute and DNS). When trying to open web page on a PC from my LAN (tried with linux and winxp), it sends the request but is unable to receive correct response from any site. On the router PC www works ok. I tried both new Independent connection tracking as well as Dependent (obsolete) connection tracking options with no luck. tcp_window_scaling setting seems to have no effect. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 2.2LK: Low link speed after suspend
Peter Missel [EMAIL PROTECTED] : [...] Entering standby, the link speed goes down to 100 Mb as expected; the link stays up during standby/suspend (for WOL purposes apparently). Yes. Now after resume, the link is working OK but doesn't come back up to normal gigabit operation. ifdown, unloading and reloading the r8169 module, and then ifup again fixes it. If there's something more I can do to help debug this, please let me know. Please be sure to copy me, since my list traffic here is still somewhat unreliable. Thanks. Can you try 2.6.21-rc7 + (either): - http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.21-rc7/r8169-20070416 - http://www.fr.zoreil.com/people/francois/misc/20070416-2.6.21-rc7-r8169-test.patch If it does not work better, please fill an entry for it at bugzilla.kernel.org, Cc: it to me and attach the output of a registers dump taken from mii-tool before suspend and after a failed resume. -- Ueimor Anybody got a battery for my Ultra 10 ? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
bug in tcp?
I'm seeing some weird behavior in TCP. The issue is perfectly reproducible using netcat and other programs. This is what I do: 1. Open a TCP connection over the loopback (over IPv4). 2. Send a couple of bytes of data each way. No problems. 3. Wait about 120 hours with no writes on either side of the connection. 4. write() a few bytes to the server's socket. I'd expect the data to go through, but it doesnt. I see the TCP frame from the server to the client, but instead of an ACK, the client sends back a RST. netstat shows the bytes sitting in the server's socket's send-buffer. 5. write a few bytes to the client's socket. The server gets these immediately. 6. On the next server-to-client retransmit, the client gets the bytes from the server. After this, the connection works normally. The libpcap capture file is here (only shows steps 4-6): http://highlab.com/~seb/tcp-idleness-bug The behavior is reproducible on all kernels I've tried: 2.4.32, 2.6.19.1, and 2.6.20.4. I dont think it's iptables-related, though I'm rerunning the tests on a machine without iptables to be sure. I'll have results for you in 120 hours. ;-) -- Sebastian Kuzminsky - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug in tcp?
On Mon, 16 Apr 2007 16:28:22 -0600 Sebastian Kuzminsky [EMAIL PROTECTED] wrote: I'm seeing some weird behavior in TCP. The issue is perfectly reproducible using netcat and other programs. This is what I do: 1. Open a TCP connection over the loopback (over IPv4). 2. Send a couple of bytes of data each way. No problems. 3. Wait about 120 hours with no writes on either side of the connection. 4. write() a few bytes to the server's socket. I'd expect the data to go through, but it doesnt. I see the TCP frame from the server to the client, but instead of an ACK, the client sends back a RST. netstat shows the bytes sitting in the server's socket's send-buffer. 5. write a few bytes to the client's socket. The server gets these immediately. 6. On the next server-to-client retransmit, the client gets the bytes from the server. After this, the connection works normally. The libpcap capture file is here (only shows steps 4-6): http://highlab.com/~seb/tcp-idleness-bug The behavior is reproducible on all kernels I've tried: 2.4.32, 2.6.19.1, and 2.6.20.4. I dont think it's iptables-related, though I'm rerunning the tests on a machine without iptables to be sure. I'll have results for you in 120 hours. ;-) What server? Some servers do application timeouts. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug in tcp?
Stephen Hemminger [EMAIL PROTECTED] wrote: On Mon, 16 Apr 2007 16:28:22 -0600 Sebastian Kuzminsky [EMAIL PROTECTED] wrote: I'm seeing some weird behavior in TCP. The issue is perfectly reproducible using netcat and other programs. This is what I do: 1. Open a TCP connection over the loopback (over IPv4). 2. Send a couple of bytes of data each way. No problems. 3. Wait about 120 hours with no writes on either side of the connection. 4. write() a few bytes to the server's socket. I'd expect the data to go through, but it doesnt. I see the TCP frame from the server to the client, but instead of an ACK, the client sends back a RST. netstat shows the bytes sitting in the server's socket's send-buffer. 5. write a few bytes to the client's socket. The server gets these immediately. 6. On the next server-to-client retransmit, the client gets the bytes from the server. After this, the connection works normally. The libpcap capture file is here (only shows steps 4-6): http://highlab.com/~seb/tcp-idleness-bug The behavior is reproducible on all kernels I've tried: 2.4.32, 2.6.19.1, and 2.6.20.4. I dont think it's iptables-related, though I'm rerunning the tests on a machine without iptables to be sure. I'll have results for you in 120 hours. ;-) What server? Some servers do application timeouts. I've observed the behavior with the server mode of nc, and with a homebrew application which does not do app-level timeouts. But anyway, application timeouts wouldnt explain the described behavior, afaik. -- Sebastian Kuzminsky - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: intermittant petabyte usage reported with broadcom nic
On Mon, Apr 16, 2007 at 12:10:51PM -0700, Michael Chan wrote: On Sat, 2007-04-14 at 17:20 -0700, Michael Chan wrote: I also like Andi's idea of using change_page_attr() to isolate the problem. I'll try to send you a debug patch in the next few days to try that out. Thanks. Here's the debug patch for x86 only that will change the statistics memory block to read-only. If the kernel is corrupting it, you should get a page fault that will crash the system. If you continue to see bogus counters, it is definitely a firmware or hardware problem. Please try it and let me know. Thanks. Ahh. Would truly love to but the moment you said 'crash the system' I had to bail. These boxes are in production and as such a crash would be, shall we say, unwelcome. I might be able to fenagle something but I very-much doubt it. Perhaps Jean-Daniel, who is also experiencing this problem and seemingly more frequently then I, has a box that he could run your patch on. I think we both run pretty-much the same hardware (Dell [12]950s). I've CCed him. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug in tcp?
On Mon, 16 Apr 2007 17:05:42 -0600 Sebastian Kuzminsky [EMAIL PROTECTED] wrote: Stephen Hemminger [EMAIL PROTECTED] wrote: On Mon, 16 Apr 2007 16:28:22 -0600 Sebastian Kuzminsky [EMAIL PROTECTED] wrote: I'm seeing some weird behavior in TCP. The issue is perfectly reproducible using netcat and other programs. This is what I do: 1. Open a TCP connection over the loopback (over IPv4). 2. Send a couple of bytes of data each way. No problems. 3. Wait about 120 hours with no writes on either side of the connection. 4. write() a few bytes to the server's socket. I'd expect the data to go through, but it doesnt. I see the TCP frame from the server to the client, but instead of an ACK, the client sends back a RST. netstat shows the bytes sitting in the server's socket's send-buffer. 5. write a few bytes to the client's socket. The server gets these immediately. 6. On the next server-to-client retransmit, the client gets the bytes from the server. After this, the connection works normally. The libpcap capture file is here (only shows steps 4-6): http://highlab.com/~seb/tcp-idleness-bug The behavior is reproducible on all kernels I've tried: 2.4.32, 2.6.19.1, and 2.6.20.4. I dont think it's iptables-related, though I'm rerunning the tests on a machine without iptables to be sure. I'll have results for you in 120 hours. ;-) What server? Some servers do application timeouts. I've observed the behavior with the server mode of nc, and with a homebrew application which does not do app-level timeouts. But anyway, application timeouts wouldnt explain the described behavior, afaik. A guess: maybe something related to a PAWS wraparound problem. Does turning off sysctl net.ipv4.tcp_timestamps fix it? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NETLINK 01/04]: Switch cb_lock spinlock to mutex and allow to override it
From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 16 Apr 2007 09:51:53 +0200 (MEST) [NETLINK]: Switch cb_lock spinlock to mutex and allow to override it Switch cb_lock to mutex and allow netlink kernel users to override it with a subsystem specific mutex for consistent locking in dump callbacks. All netlink_dump_start users have been audited not to rely on any side-effects of the previously used spinlock. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Applied. The call signature of netlink_kernel_create() is getting huge. It's getting near the time we should pass in a descriotor block in the form of a structure to specify all of these parameters. It would have even made this patch significantly smaller since the default of NULL would have worked out perfectly. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RTNETLINK 02/04]: Hold rtnl_mutex during netlink dump callbacks
From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 16 Apr 2007 09:51:54 +0200 (MEST) [RTNETLINK]: Hold rtnl_mutex during netlink dump callbacks Hold rtnl_mutex during the entire netlink dump operation. This allows to simplify locking in the dump callbacks, since they can now rely on that no concurrent changes happen. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Applied, thanks Patrick. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RTNETLINK 03/04]: Remove unnecessary locking in dump callbacks
From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 16 Apr 2007 09:51:55 +0200 (MEST) [RTNETLINK]: Remove unnecessary locking in dump callbacks Since we're now holding the rtnl during the entire dump operation, we can remove additional locking for rtnl protected data. This patch does that for all simple cases (dev_base_lock for dev_base walking, RCU protection for FIB rule dumping). Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Applied, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET_SCHED 04/04]: Eliminate qdisc_tree_lock
From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 16 Apr 2007 09:51:57 +0200 (MEST) [NET_SCHED]: Eliminate qdisc_tree_lock Since we're now holding the rtnl during the entire dump operation, we can remove qdisc_tree_lock, whose only purpose is to protect dump callbacks from concurrent changes to the qdisc tree. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Also applied, thanks a lot Patrick. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET_SCHED]: ingress: switch back to using ingress_lock
From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 16 Apr 2007 09:53:55 +0200 This patch fixes a few spots for using ingress_lock for the ingress qdisc again and switches ing_filter back to use it. Applies on top of the netlink dump patches. Applied, thanks a lot for following up on this ingress locking issue Patrick. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8320] New: replacing route in kernel doesn't send netlink message
From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 16 Apr 2007 06:59:06 +0200 RTM_DELROUTE + RTM_NEWROUTE seem to be safer, although you're correct that it might cause userspace to perform some action upon receiving the DELROUTE message since the update is non-atomic. So I really don't know, I'm in favour of having notifications for replacements, but I fear we might break something. We can cry foul about a broken application if an application following the API correctly would interpret the new messages correctly. I think it doesn't make sense to do a delete then a newroute for the atomicity issues, and therefore the replace makes the most sense as long as existing correct uses of the API would not explode on this. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [1/2] 2.6.21-rc7: known regressions
Adrian Bunk wrote: Subject: laptops with e1000: lockups References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 Submitter : Dave Jones [EMAIL PROTECTED] Handled-By : Jesse Brandeburg [EMAIL PROTECTED] Status : problem is being debugged this is being actively debugged, here is what we have so far: o v2.6.20: crashes during boot, unless noacpi and nousb bootparams used o v2.6.21-rc6: some userspace issue, crashes just after root mount without init=/bin/bash o v2.6.2X: serial console in docking station spews goo at all speeds with console=ttyS0,n8 . work continues on this, as we don't know if there are kernel panic messages during the hard lock. o fedora 7 test kernel 2948: boots okay, have been using this as only truly working kernel on this machine. one reproduction of the problem was had with scp -l 5000 file remote when linked at 100Mb/Full. Tried probably 20 other times same test with no repro, ugh. Otherwise, slogging through continues. We are actively working on this in case it *is* an e1000 issue. Right now the repro is so unlikely we could hardly tell if we fixed it. Jesse PS .config available on request - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.22 1/3] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...)
From: Ilpo_Järvinen [EMAIL PROTECTED] Date: Mon, 16 Apr 2007 19:19:02 +0300 (EEST) [PATCH] [TCP]: Sed magic converts func(sk, tp, ...) - func(sk, ...) I was trying to spread out the net-2.6.22 tree from the tcp-2.6 one so that we could do the experimental TCP stuff in the tcp-2.6 tree and leave other networking changes for net-2.6.22 Putting in TCP cleanups which touch a lot of code into net-2.6.22 defeats that effort because now there will be all kinds of rejects and merge errors people will have to deal with if they clone a net-2.6.22 tree then pull in tcp-2.6 to do some TCP hacking which is valid. I suppose we can live with that, and just tell people to just pull tcp-2.6 into a fresh linux-2.6 tree straight, but it's going to make rebasing difficult for me as well. net-2.6.22 is already approaching 350 patches, it's a monster and the merge conflicts and rebasing pain are really getting hard to deal with. For example, John Linville probably now has some build failures to deal with in his wireless-2.6 tree due to Patrick McHardy's netlink_kernel_create() function signature change today. Also, the VLAN skb-h.raw bug fix from the other day in mainline vanilla 2.6 tree is going to cause a build failure I'll have to fixup next time I rebase, and people will hit that now if they try to use current linux-2.6.git to pull in the net-2.6.22 tree. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/2] 2.6.21-rc7: known regressions
On Mon, Apr 16, 2007 at 05:14:40PM -0700, Brandeburg, Jesse wrote: Adrian Bunk wrote: Subject: laptops with e1000: lockups References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 Submitter : Dave Jones [EMAIL PROTECTED] Handled-By : Jesse Brandeburg [EMAIL PROTECTED] Status : problem is being debugged this is being actively debugged, here is what we have so far: o v2.6.20: crashes during boot, unless noacpi and nousb bootparams used o v2.6.21-rc6: some userspace issue, crashes just after root mount without init=/bin/bash o v2.6.2X: serial console in docking station spews goo at all speeds with console=ttyS0,n8 . work continues on this, as we don't know if there are kernel panic messages during the hard lock. o fedora 7 test kernel 2948: boots okay, have been using this as only truly working kernel on this machine. one reproduction of the problem was had with scp -l 5000 file remote when linked at 100Mb/Full. Tried probably 20 other times same test with no repro, ugh. Otherwise, slogging through continues. We are actively working on this in case it *is* an e1000 issue. Right now the repro is so unlikely we could hardly tell if we fixed it. FWIW, I can reproduce this pretty much ondemand, on 100M through the ethernet port on a netgear wireless AP. A number of our Fedora7 testers are also able to easily reproduce this. To isolate e1000, for tomorrows test build I've reverted e1000 to the same code that was in 2.6.20. If that works out without causing hangs, I'll try and narrow down further which of the dozen csets is responsible. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/2] 2.6.21-rc7: known regressions
Dave Jones wrote: On Mon, Apr 16, 2007 at 05:14:40PM -0700, Brandeburg, Jesse wrote: Adrian Bunk wrote: Subject: laptops with e1000: lockups References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 Submitter : Dave Jones [EMAIL PROTECTED] Handled-By : Jesse Brandeburg [EMAIL PROTECTED] Status : problem is being debugged this is being actively debugged, here is what we have so far: o v2.6.20: crashes during boot, unless noacpi and nousb bootparams used o v2.6.21-rc6: some userspace issue, crashes just after root mount without init=/bin/bash o v2.6.2X: serial console in docking station spews goo at all speeds with console=ttyS0,n8 . work continues on this, as we don't know if there are kernel panic messages during the hard lock. o fedora 7 test kernel 2948: boots okay, have been using this as only truly working kernel on this machine. one reproduction of the problem was had with scp -l 5000 file remote when linked at 100Mb/Full. Tried probably 20 other times same test with no repro, ugh. Otherwise, slogging through continues. We are actively working on this in case it *is* an e1000 issue. Right now the repro is so unlikely we could hardly tell if we fixed it. FWIW, I can reproduce this pretty much ondemand, on 100M through the ethernet port on a netgear wireless AP. A number of our Fedora7 testers are also able to easily reproduce this. To isolate e1000, for tomorrows test build I've reverted e1000 to the same code that was in 2.6.20. If that works out without causing hangs, I'll try and narrow down further which of the dozen csets is responsible. Also, there are e1000 fixes in -mm. At the time (rc2? rc3?) I felt it was best to get that into -mm for testing, rather than fast-tracking it to 2.6.21. But hey, see if they help. It's the netdev-2.6.git#e1000-fixes branch, if you are git-ified. I was going to push them first thing 2.6.22. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix sparse errors in drivers/net/ibmveth.c
drivers/net/ibmveth.c:96:46: error: marked inline, but without a definition drivers/net/ibmveth.c:96: warning: 'ibmveth_rxq_harvest_buffer' declared inline after being called drivers/net/ibmveth.c:96: warning: previous declaration of 'ibmveth_rxq_harvest_buffer' was here Just let the compiler decide, as it happens gcc 4.~ inlines it anyway. drivers/net/ibmveth.c:957:71: warning: Using plain integer as NULL pointer drivers/net/ibmveth.c:964:85: warning: Using plain integer as NULL pointer Split the long lines as well, ugly, but 80 columns. Signed-off-by: Michael Ellerman [EMAIL PROTECTED] --- drivers/net/ibmveth.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) Index: powerpc/drivers/net/ibmveth.c === --- powerpc.orig/drivers/net/ibmveth.c +++ powerpc/drivers/net/ibmveth.c @@ -93,7 +93,7 @@ static void ibmveth_proc_unregister_driv static void ibmveth_proc_register_adapter(struct ibmveth_adapter *adapter); static void ibmveth_proc_unregister_adapter(struct ibmveth_adapter *adapter); static irqreturn_t ibmveth_interrupt(int irq, void *dev_instance); -static inline void ibmveth_rxq_harvest_buffer(struct ibmveth_adapter *adapter); +static void ibmveth_rxq_harvest_buffer(struct ibmveth_adapter *adapter); static struct kobj_type ktype_veth_pool; #ifdef CONFIG_PROC_FS @@ -389,7 +389,7 @@ static void ibmveth_rxq_recycle_buffer(s } } -static inline void ibmveth_rxq_harvest_buffer(struct ibmveth_adapter *adapter) +static void ibmveth_rxq_harvest_buffer(struct ibmveth_adapter *adapter) { ibmveth_remove_buffer_from_pool(adapter, adapter-rx_queue.queue_addr[adapter-rx_queue.index].correlator); @@ -954,14 +954,16 @@ static int __devinit ibmveth_probe(struc ibmveth_debug_printk_no_adapter(entering ibmveth_probe for UA 0x%x\n, dev-unit_address); - mac_addr_p = (unsigned char *) vio_get_attribute(dev, VETH_MAC_ADDR, 0); + mac_addr_p = (unsigned char *) vio_get_attribute(dev, + VETH_MAC_ADDR, NULL); if(!mac_addr_p) { printk(KERN_ERR (%s:%3.3d) ERROR: Can't find VETH_MAC_ADDR attribute\n, __FILE__, __LINE__); return 0; } - mcastFilterSize_p= (unsigned int *) vio_get_attribute(dev, VETH_MCAST_FILTER_SIZE, 0); + mcastFilterSize_p = (unsigned int *) vio_get_attribute(dev, + VETH_MCAST_FILTER_SIZE, NULL); if(!mcastFilterSize_p) { printk(KERN_ERR (%s:%3.3d) ERROR: Can't find VETH_MCAST_FILTER_SIZE attribute\n, - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug in tcp?
Stephen Hemminger [EMAIL PROTECTED] wrote: A guess: maybe something related to a PAWS wraparound problem. Does turning off sysctl net.ipv4.tcp_timestamps fix it? I just started this test, I'll let you know in 5 days. :-/ Any other things I should try, anyone? I'm doing the new tests under qemu, so it's easy to run lots of tests in parallel. The previous reports of this bug all occurred when running natively. I'm doing the new tests with 2.6.18, but the behavior does not seem sensitive to the kernel version. -- Sebastian Kuzminsky - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug in tcp?
Stephen Hemminger wrote: A guess: maybe something related to a PAWS wraparound problem. Does turning off sysctl net.ipv4.tcp_timestamps fix it? That was my first thought too (aside from netfilter), but a failed PAWS check should not result in a reset.. -John - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug in tcp?
John Heffner [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: A guess: maybe something related to a PAWS wraparound problem. Does turning off sysctl net.ipv4.tcp_timestamps fix it? That was my first thought too (aside from netfilter), but a failed PAWS check should not result in a reset.. All three of the systems where I saw the problems earlier did have some netfilter rules up and running All tests I'm doing now have netfilter compiled in but no rules set (INPUT, FORWARD, and OUTPUT are all empty, and the policies are all ACCEPT). -- Sebastian Kuzminsky - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug in tcp?
Sebastian Kuzminsky wrote: I'm seeing some weird behavior in TCP. The issue is perfectly reproducible using netcat and other programs. This is what I do: 1. Open a TCP connection over the loopback (over IPv4). 2. Send a couple of bytes of data each way. No problems. 3. Wait about 120 hours with no writes on either side of the connection. 4. write() a few bytes to the server's socket. I'd expect the data to go through, but it doesnt. I see the TCP frame from the server to the client, but instead of an ACK, the client sends back a RST. netstat shows the bytes sitting in the server's socket's send-buffer. 5. write a few bytes to the client's socket. The server gets these immediately. 6. On the next server-to-client retransmit, the client gets the bytes from the server. After this, the connection works normally. The libpcap capture file is here (only shows steps 4-6): http://highlab.com/~seb/tcp-idleness-bug The behavior is reproducible on all kernels I've tried: 2.4.32, 2.6.19.1, and 2.6.20.4. I dont think it's iptables-related, though I'm rerunning the tests on a machine without iptables to be sure. I'll have results for you in 120 hours. ;-) It sounds like it could easily be iptables related, if you have iptables rules that only allow new connections in the client to server direction, which is quite normal. The default iptables timeout for TCP connections is 5 days. So after 5 days of idle, any packets from the server will be treated as a new connection and the iptables rules will drop them. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug in tcp?
Philip Craig [EMAIL PROTECTED] wrote: It sounds like it could easily be iptables related, if you have iptables rules that only allow new connections in the client to server direction, which is quite normal. Sure I have those standard rules. iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --syn --dport ssh -j ACCEPT iptables -A INPUT -p tcp --syn --dport http -j ACCEPT ... etc The default iptables timeout for TCP connections is 5 days. So after 5 days of idle, any packets from the server will be treated as a new connection and the iptables rules will drop them. Weird. Why does sending a message from the client make it go again? If that's the case, it seems like a simple fix would be to enable TCP keepalive in my app, that would keep netfilter from timing out, right? That seems better than extending the netfilter timeout. How do people normally handle this? -- Sebastian Kuzminsky - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html