1. 28 6月, 2007 1 次提交
  2. 24 6月, 2007 2 次提交
  3. 21 6月, 2007 16 次提交
    • D
      cxgb3 - MAC watchdog update · 2090dee4
      Divy Le Ray 提交于
      Fix variables initialization and usage in the MAC watchdog.
      Signed-off-by: NDivy Le Ray <divy@chelsio.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      2090dee4
    • D
      cxgb3 - Stop mac RX when changing MTU · 7b581a0f
      Divy Le Ray 提交于
      Rx traffic needs to be halted when the MTU is changed
      to avoid a potential chip hang.
      Reset/restore MAC filters around a MTU change.
      Also fix the pause frames high materwark setting.
      Signed-off-by: NDivy Le Ray <divy@chelsio.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      7b581a0f
    • D
      cxgb3 - Fix direct XAUI support · c706bfb5
      Divy Le Ray 提交于
      Check all lanes for link status on direct XAUI cards.
      Don't assume that direct XAUI always uses XGMAC 1.
      Signed-off-by: NDivy Le Ray <divy@chelsio.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      c706bfb5
    • D
      cxgb3 - fix netpoll hanlder · 890de332
      Divy Le Ray 提交于
      Fix netpoll handler to work with line interrupt, msi and msi-x.
      Signed-off-by: NDivy Le Ray <divy@chelsio.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      890de332
    • D
      cxgb3 - fix skb->dev dereference · e360b562
      Divy Le Ray 提交于
      eth_type_trans() now sets skb->dev.
      References to skb->dev should happen after it is called.
      Signed-off-by: NDivy Le Ray <divy@chelsio.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      e360b562
    • G
      natsemi irq flags · d41f2d17
      Gregory Haskins 提交于
      The spinlock irq flags should be a unsigned long to properly support 64 bit
      Signed-off-by: NGregory Haskins <ghaskins@novell.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      d41f2d17
    • T
      forcedeth: use unicast receive mode for WoL · 2cc49a5c
      Tim Mann 提交于
      I happened to notice that a system with an NVidia NIC using the
      forcedeth driver won't wake-on-LAN if the interface was in promiscuous
      mode when you power off.  By experiment, it looks like
      the hardware needs to have NvRegPacketFilterFlags set to
      NVREG_PFF_ALWAYS|NVREG_PFF_MYADDR (i.e., receive unicast packets to my
      address) in order for WoL to work.
      
      Jeff Garzik writes: "NVIDIA says the patch looks OK."  I didn't venture
      to insert a signed-off-by line with his name on it, though.
      Signed-off-by: NTim Mann <mann@vmware.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      2cc49a5c
    • J
      bonding: Fix 802.3ad no carrier on "no partner found" instance · 031ae4de
      Jay Vosburgh 提交于
      	Modify carrier state determination for 802.3ad mode to comply
      with section 43.3.9 of IEEE 802.3, which requires that "Links that are
      not successful candidates for aggregation (e.g., links that are attached
      to other devices that cannot perform aggregation or links that have been
      manually configured to be non-aggregatable) are enabled to operate as
      individual IEEE 802.3 links."
      
      	Bug reported by Laurent Chavey <chavey@google.com>.  This patch
      is an updated version of his patch that changes the wording of
      commentary and adds an update to the driver version.
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NLaurent Chavey <chavey@google.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      031ae4de
    • J
      bonding: Fix use after free in unregister path · 3201e656
      Jay Vosburgh 提交于
      	The following patch (based on a patch from Stephen Hemminger
      <shemminger@linux-foundation.org>) removes use after free conditions in
      the unregister path for the bonding master.  Without this patch, an
      operation of the form "echo -bond0 > /sys/class/net/bonding_masters"
      would trigger a NULL pointer dereference in sysfs.  I was not able to
      induce the failure with the non-sysfs code path, but for consistency I
      updated that code as well.
      
      	I also did some testing of the bonding /proc file being open
      while the bond is being deleted, and didn't see any problems there.
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      3201e656
    • S
      spidernet: checksum and ethtool · 3a2c892d
      Stephen Hemminger 提交于
      It doesn't look like spidernet hardware can really checksum all protocols,
      the code looks like it does IPV4 only.  If so, it should use NETIF_F_IP_CSUM
      instead of NETIF_F_HW_CSUM.
      
      The driver doesn't need it's own get/set for ethtool tx csum, and it
      should use the standard ethtool_op_get_link.
      Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
      Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      3a2c892d
    • L
      spidernet: turn off descriptor chain end interrupt. · 128c6e2e
      Linas Vepstas 提交于
      At some point, the transmit descriptor chain end interrupt (TXDCEINT)
      was turned on. This is a mistake; and it damages small packet
      transmit performance, as it results in a huge storm of interrupts.
      Turn it off.
      Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      128c6e2e
    • L
      spidernet: silence the ramfull messages · c3d1182a
      Linas Vepstas 提交于
      Although the previous patch resolved issues with hangs when the
      RX ram full interrupt is encountered, there are still situations
      where lots of RX ramfull interrupts arrive, resulting in a noisy
      log in syslog. There is no need for this.
      Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      c3d1182a
    • L
      spidernet: Don't terminate the RX ring · 2bf27a0d
      Linas Vepstas 提交于
      The terminated RX ring will cause trouble during the RX ram full
      conditions, leading to a hung driver, as the hardware can't find
      the next descr.  There is no real reason to terminate the RX ring;
      it doesn't make the operation any smooother, and it does
      require an extra sync. So don't do it.
      Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      2bf27a0d
    • L
      spidernet: Cure RX ram full bug · 4c4bd5a9
      Linas Vepstas 提交于
      This patch fixes a rare deadlock that can occur when the kernel
      is not able to empty out the RX ring quickly enough. Below follows
      a detailed description of the bug and the fix.
      
      As long as the OS can empty out the RX buffers at a rate faster than
      the hardware can fill them, there is no problem. If, for some reason,
      the OS fails to empty the RX ring fast enough, the hardware GDACTDPA
      pointer will catch up to the head, notice the not-empty condition,
      ad stop. However, RX packets may still continue arriving on the wire.
      The spidernet chip can save some limited number of these in local RAM.
      When this local ram fills up, the spider chip will issue an interrupt
      indicating this (GHIINT0STS will show ERRINT, and the GRMFLLINT bit
      will be set in GHIINT1STS).  When te RX ram full condition occurs,
      a certain bug/feature is triggered that has to be specially handled.
      This section describes the special handling for this condition.
      
      When the OS finally has a chance to run, it will empty out the RX ring.
      In particular, it will clear the descriptor on which the hardware had
      stopped. However, once the hardware has decided that a certain
      descriptor is invalid, it will not restart at that descriptor; instead
      it will restart at the next descr. This potentially will lead to a
      deadlock condition, as the tail pointer will be pointing at this descr,
      which, from the OS point of view, is empty; the OS will be waiting for
      this descr to be filled. However, the hardware has skipped this descr,
      and is filling the next descrs. Since the OS doesn't see this, there
      is a potential deadlock, with the OS waiting for one descr to fill,
      while the hardware is waiting for a differen set of descrs to become
      empty.
      
      A call to show_rx_chain() at this point indicates the nature of the
      problem. A typical print when the network is hung shows the following:
      
      net eth1: Spider RX RAM full, incoming packets might be discarded!
      net eth1: Total number of descrs=256
      net eth1: Chain tail located at descr=255
      net eth1: Chain head is at 255
      net eth1: HW curr desc (GDACTDPA) is at 0
      net eth1: Have 1 descrs with stat=xa0800000
      net eth1: HW next desc (GDACNEXTDA) is at 1
      net eth1: Have 127 descrs with stat=x40800101
      net eth1: Have 1 descrs with stat=x40800001
      net eth1: Have 126 descrs with stat=x40800101
      net eth1: Last 1 descrs with stat=xa0800000
      
      Both the tail and head pointers are pointing at descr 255, which is
      marked xa... which is "empty". Thus, from the OS point of view, there
      is nothing to be done. In particular, there is the implicit assumption
      that everything in front of the "empty" descr must surely also be empty,
      as explained in the last section. The OS is waiting for descr 255 to
      become non-empty, which, in this case, will never happen.
      
      The HW pointer is at descr 0. This descr is marked 0x4.. or "full".
      Since its already full, the hardware can do nothing more, and thus has
      halted processing. Notice that descrs 0 through 254 are all marked
      "full", while descr 254 and 255 are empty. (The "Last 1 descrs" is
      descr 254, since tail was at 255.) Thus, the system is deadlocked,
      and there can be no forward progress; the OS thinks there's nothing
      to do, and the hardware has nowhere to put incoming data.
      
      This bug/feature is worked around with the spider_net_resync_head_ptr()
      routine. When the driver receives RX interrupts, but an examination
      of the RX chain seems to show it is empty, then it is probable that
      the hardware has skipped a descr or two (sometimes dozens under heavy
      network conditions). The spider_net_resync_head_ptr() subroutine will
      search the ring for the next full descr, and the driver will resume
      operations there.  Since this will leave "holes" in the ring, there
      is also a spider_net_resync_tail_ptr() that will skip over such holes.
      Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      4c4bd5a9
    • L
      spidernet: null out skb pointer after its been used. · 83d35145
      Linas Vepstas 提交于
      Avoid kernel crash in mm/slab.c due to double-free of pointer.
      
      If the ethernet interface is brought down while there is still
      RX traffic in flight, the device shutdown routine can end up
      trying to double-free an skb, leading to a crash in mm/slab.c
      Avoid the double-free by nulling out the skb pointer.
      Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      83d35145
    • R
      [MIPS] Don't drag a platform specific header into generic arch code. · 3b1d4ed5
      Ralf Baechle 提交于
      For some platforms it's definitions may conflict.  So that's the one-liner.
      The rest is 10 square kilometers of collateral damage fixup this include
      used to paper over.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      3b1d4ed5
  4. 18 6月, 2007 2 次提交
    • R
      IB/mlx4: Handle FW command interface rev 3 · 5ae2a7a8
      Roland Dreier 提交于
      Upcoming firmware introduces command interface revision 3, which
      changes the way port capabilities are queried and set.  Update the
      driver to handle both the new and old command interfaces by adding a
      new MLX4_FLAG_OLD_PORT_CMDS that it is set after querying the firmware
      interface revision and then using the correct interface based on the
      setting of the flag.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      5ae2a7a8
    • R
      IB/mlx4: Handle new FW requirement for send request prefetching · 0e6e7416
      Roland Dreier 提交于
      New ConnectX firmware introduces FW command interface revision 2,
      which requires that for each QP, a chunk of send queue entries (the
      "headroom") is kept marked as invalid, so that the HCA doesn't get
      confused if it prefetches entries that haven't been posted yet.  Add
      code to the driver to do this, and also update the user ABI so that
      userspace can request that the prefetcher be turned off for userspace
      QPs (we just leave the prefetcher on for all kernel QPs).
      
      Unfortunately, marking send queue entries this way is confuses older
      firmware, so we change the driver to allow only FW command interface
      revisions 2.  This means that users will have to update their firmware
      to work with the new driver, but the firmware is changing quickly and
      the old firmware has lots of other bugs anyway, so this shouldn't be too
      big a deal.
      
      Based on a patch from Jack Morgenstein <jackm@dev.mellanox.co.il>.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      0e6e7416
  5. 13 6月, 2007 10 次提交
  6. 12 6月, 2007 9 次提交