Skip to content

L
linux-davinci
Switch branch/tag
  1. 25 Nov, 2008 3 commits
  3. 24 Nov, 2008 1 commit
  5. 23 Nov, 2008 2 commits
  7. 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
  9. 21 Nov, 2008 2 commits
  11. 20 Nov, 2008 28 commits