[KJ][PATCH]sb1250-mac.c-kzalloc

2007-04-16 Thread vignesh.babu

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

2007-04-16 Thread Olof Johansson
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

2007-04-16 Thread Olof Johansson
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

2007-04-16 Thread Michael Chan
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

2007-04-16 Thread Andi Kleen
 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

2007-04-16 Thread Michael Ellerman
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

2007-04-16 Thread Olof Johansson
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

2007-04-16 Thread Olof Johansson
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

2007-04-16 Thread Olof Johansson
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

2007-04-16 Thread Michael Chan
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

2007-04-16 Thread Olof Johansson
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

2007-04-16 Thread Patrick McHardy
[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

2007-04-16 Thread Patrick McHardy
[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

2007-04-16 Thread Patrick McHardy
[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

2007-04-16 Thread Patrick McHardy
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[]

2007-04-16 Thread Thomas Graf
* 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[]

2007-04-16 Thread Willy Tarreau
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

2007-04-16 Thread Jerome Borsboom
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

2007-04-16 Thread Patrick McHardy
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.

2007-04-16 Thread Aubrey Li

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

2007-04-16 Thread Patrick McHardy
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)

2007-04-16 Thread Ilpo Järvinen
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

2007-04-16 Thread Ilpo Järvinen
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, ...)

2007-04-16 Thread Ilpo Järvinen
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

2007-04-16 Thread Patrick McHardy
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, ...)

2007-04-16 Thread Christoph Hellwig
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, ...)

2007-04-16 Thread Ilpo Järvinen
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, ...)

2007-04-16 Thread Patrick McHardy
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

2007-04-16 Thread David Acker

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, ...)

2007-04-16 Thread Ilpo Järvinen
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, ...)

2007-04-16 Thread Patrick McHardy
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, ...)

2007-04-16 Thread Ilpo Järvinen
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, ...)

2007-04-16 Thread Ilpo Järvinen
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.

2007-04-16 Thread Tantilov, Emil S
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

2007-04-16 Thread Stephen Hemminger
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.

2007-04-16 Thread John Heffner

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

2007-04-16 Thread Matt Mackall
[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

2007-04-16 Thread Michael Chan
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.

2007-04-16 Thread Robert Iakobashvili

 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.

2007-04-16 Thread John Heffner

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.

2007-04-16 Thread David Miller
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.

2007-04-16 Thread David Miller
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.

2007-04-16 Thread Jesse Brandeburg

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

2007-04-16 Thread Peter Missel
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

2007-04-16 Thread Andrew Morton
 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

2007-04-16 Thread Francois Romieu
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?

2007-04-16 Thread Sebastian Kuzminsky
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?

2007-04-16 Thread Stephen Hemminger
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?

2007-04-16 Thread Sebastian Kuzminsky
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

2007-04-16 Thread CaT
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?

2007-04-16 Thread Stephen Hemminger
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

2007-04-16 Thread David Miller
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

2007-04-16 Thread David Miller
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

2007-04-16 Thread David Miller
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

2007-04-16 Thread David Miller
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

2007-04-16 Thread David Miller
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

2007-04-16 Thread David Miller
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

2007-04-16 Thread Brandeburg, Jesse
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, ...)

2007-04-16 Thread David Miller
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

2007-04-16 Thread Dave Jones
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

2007-04-16 Thread Jeff Garzik

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

2007-04-16 Thread Michael Ellerman
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?

2007-04-16 Thread Sebastian Kuzminsky
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?

2007-04-16 Thread John Heffner

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?

2007-04-16 Thread Sebastian Kuzminsky
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?

2007-04-16 Thread Philip Craig
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?

2007-04-16 Thread Sebastian Kuzminsky
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