1. 17 Jun, 2010 7 commits
    • stephen hemminger's avatar
      bridge: fdb cleanup runs too often · 25442e06
      stephen hemminger authored
      It is common in end-node, non STP bridges to set forwarding
      delay to zero; which causes the forwarding database cleanup
      to run every clock tick. Change to run only as soon as needed
      or at next ageing timer interval which ever is sooner.
      
      Use round_jiffies_up macro rather than attempting round up
      by changing value.
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      25442e06
    • FUJITA Tomonori's avatar
      bnx2: fix dma_get_ops compilation breakage · aabef8b2
      FUJITA Tomonori authored
      This removes dma_get_ops() prefetch optimization in bnx2.
      
      bnx2 uses dma_get_ops() to see if dma_sync_single_for_cpu() is
      noop. bnx2 does prefetch if it's noop.
      
      But dma_get_ops() isn't available on all the architectures (only the
      architectures that uses dma_map_ops struct have it). Using
      dma_get_ops() in drivers leads to compilation breakage on many
      architectures.
      
      This patch removes dma_get_ops() and changes bnx2 to do prefetch on
      all the architectures. This adds useless prefetch on non-coherent
      architectures but this is harmless. It is also unlikely to cause the
      performance drop.
      
      [ Remove now unused local variable 'pdev' -DaveM ]
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Acked-by: default avatarMichael Chan <mchan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aabef8b2
    • Sergey Matyukevich's avatar
      ucc_geth: fix for RX skb buffers recycling · db176edc
      Sergey Matyukevich authored
      This patch implements a proper modification of RX skb buffers before
      recycling. Adjusting only skb->data is not enough because after that
      skb->tail and skb->len become incorrect.
      Signed-off-by: default avatarSergey Matyukevich <geomatsi@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      db176edc
    • Ken Kawasaki's avatar
      pcnet_cs: add new id (TOSHIBA Modem/LAN Card) · 8b1d920f
      Ken Kawasaki authored
      pcnet_cs:
      serial_cs:
          add new id (TOSHIBA Modem/LAN Card)
      Signed-off-by: default avatarKen Kawasaki <ken_kawasaki@spring.nifty.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b1d920f
    • Anton Vorontsov's avatar
      gianfar: Fix oversized packets handling · 63b88b90
      Anton Vorontsov authored
      Issuing the following command on host:
      
      $ ifconfig eth2 mtu 1600 ; ping 10.0.0.27 -s 1485 -c 1
      
      Makes some boards (tested with MPC8315 rev 1.1 and MPC8313 rev 1.0)
      oops like this:
      
        skb_over_panic: text:c0195914 len:1537 put:1537 head:c79e4800 data:c79e4880 tail:0xc79e4e81 end:0xc79e4e80 dev:eth1
        ------------[ cut here ]------------
        kernel BUG at net/core/skbuff.c:127!
        Oops: Exception in kernel mode, sig: 5 [#1]
        MPC831x RDB
        last sysfs file: /sys/kernel/uevent_seqnum
        Modules linked in:
        NIP: c01c1840 LR: c01c1840 CTR: c016d918
        [...]
        NIP [c01c1840] skb_over_panic+0x48/0x5c
        LR [c01c1840] skb_over_panic+0x48/0x5c
        Call Trace:
        [c0339d50] [c01c1840] skb_over_panic+0x48/0x5c (unreliable)
        [c0339d60] [c01c3020] skb_put+0x5c/0x60
        [c0339d70] [c0195914] gfar_clean_rx_ring+0x25c/0x3d0
        [c0339dc0] [c01976e8] gfar_poll+0x170/0x1bc
      
      Dumped buffer descriptors showed that eTSEC's length/truncation
      logic sometimes passes oversized packets, i.e. for the above ICMP
      packet the following two buffer descriptors may become ready:
      
        status=1400 length=1536
        status=1800 length=1541
      
      So, it seems that gianfar actually receives the whole big frame,
      and it tries to place the packet into two BDs. This situation
      confuses the driver, and so the skb_put() sanity check fails.
      
      This patch fixes the issue by adding an appropriate check, i.e.
      the driver should not try to process frames with buffer
      descriptor's length over rx_buffer_size (i.e. maxfrm and mrblr).
      
      Note that sometimes eTSEC works correctly, i.e. in the second
      (last) buffer descriptor bits 'truncated' and 'crcerr' are set,
      and so there's no oops. Though I couldn't find any logic when
      it works correctly and when not.
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@mvista.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      63b88b90
    • Jan-Bernd Themann's avatar
      ehea: Fix kernel deadlock in DLPAR-mem processing · 099473c1
      Jan-Bernd Themann authored
      Port reset operations and memory add/remove operations need to
      be serialized to avoid a kernel deadlock. The deadlock is caused
      by calling the napi_disable() function twice.
      Therefore we have to employ the dlpar_mem_lock in the ehea_reset_port
      function as well
      Signed-off-by: default avatarJan-Bernd Themann <themann@de.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      099473c1
    • Jan-Bernd Themann's avatar
      ehea: fix delayed packet processing · a91fb143
      Jan-Bernd Themann authored
      In the eHEA poll function an rmb() is required. Without that some packets
      on the receive queue are not seen and thus delayed until the next interrupt
      is handled for the same receive queue.
      Signed-off-by: default avatarJan-Bernd Themann <themann@de.ibm.com>
      Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a91fb143
  2. 16 Jun, 2010 9 commits
  3. 15 Jun, 2010 4 commits
  4. 14 Jun, 2010 10 commits
  5. 12 Jun, 2010 1 commit
    • Randy Dunlap's avatar
      enic: fix pci_alloc_consistent argument · d49aba84
      Randy Dunlap authored
      Fix build warning on i386 (32-bit) with 32-bit dma_addr_t:
      
      drivers/net/enic/vnic_dev.c: In function 'vnic_dev_init_prov':
      drivers/net/enic/vnic_dev.c:716: warning: passing argument 3 of 'pci_alloc_consistent' from incompatible pointer type
      include/asm-generic/pci-dma-compat.h:16: note: expected 'dma_addr_t *' but argument is of type 'u64 *'
      
      Now builds without warnings on i386 and on x86_64.
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Cc:	Scott Feldman <scofeldm@cisco.com>
      Cc:	Vasanthy Kolluri <vkolluri@cisco.com>
      Cc:	Roopa Prabhu <roprabhu@cisco.com>
      Acked-by: default avatarScott Feldman <scofeldm@cisco.com>
      d49aba84
  6. 11 Jun, 2010 6 commits
  7. 10 Jun, 2010 2 commits
  8. 09 Jun, 2010 1 commit