1. 25 Nov, 2008 1 commit
    • Johannes Berg's avatar
      iwlagn: fix DMA sync · e91af0af
      Johannes Berg authored
      For the RX DMA fix for iwlwifi ("iwlagn: fix RX skb alignment") Luis
      pointed out:
      
      > aligned_dma_addr can obviously be > real_dma_addr at this point, what
      > guarantees we can use it on our own whim?
      
      I asked around, and he's right, there may be platforms that do not allow
      passing such such an address to the DMA API functions. This patch
      changes it by using the proper dma_sync_single_range_for_cpu API
      invented for this purpose.
      
      Cc: Luis R. Rodriguez <mcgrof@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e91af0af
  2. 22 Nov, 2008 4 commits
    • Catalin Marinas's avatar
      net: Fix memory leak in the proto_register function · 7e56b5d6
      Catalin Marinas authored
      If the slub allocator is used, kmem_cache_create() may merge two or more
      kmem_cache's into one but the cache name pointer is not updated and
      kmem_cache_name() is no longer guaranteed to return the pointer passed
      to the former function. This patch stores the kmalloc'ed pointers in the
      corresponding request_sock_ops and timewait_sock_ops structures.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Reviewed-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7e56b5d6
    • Petr Tesarik's avatar
      tcp: Do not use TSO/GSO when there is urgent data · 33cf71ce
      Petr Tesarik authored
      This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=12014
      
      Since most (if not all) implementations of TSO and even the in-kernel
      software GSO do not update the urgent pointer when splitting a large
      segment, it is necessary to turn off TSO/GSO for all outgoing traffic
      with the URG pointer set.
      
      Looking at tcp_current_mss (and the preceding comment) I even think
      this was the original intention. However, this approach is insufficient,
      because TSO/GSO is turned off only for newly created frames, not for
      frames which were already pending at the arrival of a message with
      MSG_OOB set. These frames were created when TSO/GSO was enabled,
      so they may be large, and they will have the urgent pointer set
      in tcp_transmit_skb().
      
      With this patch, such large packets will be fragmented again before
      going to the transmit routine.
      
      As a side note, at least the following NICs are known to screw up
      the urgent pointer in the TCP header when doing TSO:
      
      	Intel 82566MM (PCI ID 8086:1049)
      	Intel 82566DC (PCI ID 8086:104b)
      	Intel 82541GI (PCI ID 8086:1076)
      	Broadcom NetXtreme II BCM5708 (PCI ID 14e4:164c)
      Signed-off-by: default avatarPetr Tesarik <ptesarik@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      33cf71ce
    • Randy Dunlap's avatar
      net/hp-plus: fix link errors · 38ae07e4
      Randy Dunlap authored
      Fix hp-plus driver link errors.
      Builds as loadable module and kernel image driver.
      All drivers that use 8390.o or 8390p.o that will build on
      i386 with MCA/PCI/EISA/ISA were built successfully both
      =m and =y.
      
      drivers/built-in.o: In function `hpp_open':
      hp-plus.c:(.text+0xac06c): undefined reference to `eip_interrupt'
      hp-plus.c:(.text+0xac0d7): undefined reference to `eip_open'
      drivers/built-in.o: In function `hpp_close':
      hp-plus.c:(.text+0xac1bb): undefined reference to `eip_close'
      drivers/built-in.o: In function `hpp_probe1':
      hp-plus.c:(.init.text+0xa98a): undefined reference to `NS8390p_init'
      drivers/built-in.o: In function `hp_plus_probe':
      (.init.text+0xa9fe): undefined reference to `__alloc_eip_netdev'
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      38ae07e4
    • Cord Walter's avatar
      axnet_cs / pcnet_cs: moving PCMCIA_DEVICE_PROD_ID for Netgear FA411 · 208fbec5
      Cord Walter authored
      Hi,
      
      after noticing that my Netgear FA411 (PCMCIA-NIC) [1] stopped working with
      the release of the 2.6.25 kernel (sidux-version), I checked the
      respective driver sources and noticed that the pcnet_cs driver bailed
      out with "use axnet_cs instead" for the Netgear FA411, but axnet_cs
      doesn't claim this ID.
      
      I compiled a kernel with the PCMCIA-ID for the netgear card moved to
      axnet_cs from pcnet_cs which worked. I then contacted sidux-kernel
      maintainer Stefan Lippers-Hollmann who turned the info into this patch
      and integrated it into the kernel:
      
      <http://svn.berlios.de/svnroot/repos/fullstory/linux-sidux-2.6/trunk/debian/patches/features/2.6.27.4_PCMCIA_move-PCMCIA-ID-for-Netgear-FA411-from-pcnet_cs-to-axnet_cs.patch>
      
      This works for me and AFAIK there were no reports of any breakage for
      other devices on sidux-support.
      
      This looks like a trivial patch, but since I have very limited
      experience with kernel modifications  I might be woefully wrong there.
      But if there are no side effects of this patch, is it possible to get it
      into the official kernel?
      
      I can provide more detailed information on the affected hardware if
      necessary.
      
      -cord
      
      [1]
      Socket 1 Device 0:      [axnet_cs]              (bus ID: 1.0)
              Configuration:  state: on
              Product Name:   NETGEAR FA411 Fast Ethernet
              Identification: manf_id: 0x0149 card_id: 0x0411
                              function: 6 (network)
                              prod_id(1): "NETGEAR" (0x9aa79dc3)
                              prod_id(2): "FA411" (0x40fad875)
                              prod_id(3): "Fast Ethernet" (0xb4be14e3)
                              prod_id(4): --- (---)
      
      From: Stefan Lippers-Hollmann <s.l-h@gmx.de>
      Date: Sat, 1 Nov 2008 23:53:04 +0000
      Subject: PCMCIA: move PCMCIA ID for Netgear FA411 from pcnet_cs to axnet_cs:
      
      Since kernel 2.6.25, commit 61da96be
      (pcnet_cs: if AX88190-based card, printk "use axnet_cs instead" message.),
      pcnet_cs bails out with "use axnet_cs instead" for the Netgear FA411, but
      axnet_cs doesn't claim this ID.
      
      Socket 1 Device 0:      [axnet_cs]              (bus ID: 1.0)
              Configuration:  state: on
              Product Name:   NETGEAR FA411 Fast Ethernet
              Identification: manf_id: 0x0149 card_id: 0x0411
                              function: 6 (network)
                              prod_id(1): "NETGEAR" (0x9aa79dc3)
                              prod_id(2): "FA411" (0x40fad875)
                              prod_id(3): "Fast Ethernet" (0xb4be14e3)
                              prod_id(4): --- (---)
      
      Cc: stable <stable@kernel.org> [2.6.25, 2.6.26, 2.6.27]
      Signed-off-by: default avatarStefan Lippers-Hollmann <s.l-h@gmx.de>
      Signed-off-by: default avatarCord Walter <qord@cwalter.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      208fbec5
  3. 21 Nov, 2008 2 commits
  4. 20 Nov, 2008 33 commits