From neuffer@neuffer.info Sun Feb  1 02:03:51 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Feb 2004 02:04:05 -0800 (PST)
Received: from mail-in-03.arcor-online.net (mail-in-03.arcor-online.net [151.189.21.43])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i11A3o7J024637
	for <netdev@oss.sgi.com>; Sun, 1 Feb 2004 02:03:51 -0800
Received: from server.dr1.neuffer.info (dialin-145-254-223-067.arcor-ip.net [145.254.223.67])
	by mail-in-03.arcor-online.net (Postfix) with ESMTP
	id 2900A72D1FC; Sun,  1 Feb 2004 11:03:49 +0100 (CET)
Received: from charion.dr1.neuffer.info (root@charion.dr1.neuffer.info [192.168.1.19])
	by server.dr1.neuffer.info (8.12.11/8.12.11/Debian-1) with ESMTP id i11A3mLD003022
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 1 Feb 2004 11:03:48 +0100
Received: from charion.dr1.neuffer.info (neuffer@localhost [127.0.0.1])
	by charion.dr1.neuffer.info (8.12.11/8.12.11.Beta0/Debian-2) with ESMTP id i11A3lr5013243
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 1 Feb 2004 11:03:47 +0100
Received: (from neuffer@localhost)
	by charion.dr1.neuffer.info (8.12.11/8.12.11.Beta0/Debian-2) id i11A3eEt013242;
	Sun, 1 Feb 2004 11:03:40 +0100
From: Michael Neuffer <neuffer@neuffer.info>
Date: Sun, 1 Feb 2004 11:03:40 +0100
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shuchen@realtek.com.tw
Subject: Re: 2.6.2-rc2-mm2
Message-ID: <20040201100340.GA12436@neuffer.info>
References: <20040130014108.09c964fd.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040130014108.09c964fd.akpm@osdl.org>
User-Agent: Mutt/1.5.5.1+cvs20040105i
X-archive-position: 2923
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: neuffer@neuffer.info
Precedence: bulk
X-list: netdev


Quoting Andrew Morton (akpm@osdl.org):
> [...] 
> +bk-netdev.patch
> 
>  Latest experimental netdev tree

The patch to r8169.c from the netdev patch clearly increases stability

The 2.6.2-rc2 kernel hangs within minutes even on very light load, whereas
2.6.2-rc2-mm2-1 holds up under heavy network traffic repeatably for
over half an hour before it hangs and somewhat longer under light traffic.

It is definitely the RTL-8169 interface since I can not get the kernel
to hang using a different (RTL-8139C) controller connected to the same 
Gigabit switch.

After many tests I was finally able to capture an Oops:
Oops: 0000 [#1]
PREEMPT
CPU:    0
EIP:    0060:[<c02f6a7a>]   Not tainted VLI
EFLAGS: 00010216
EIP is at rtl8169_rx_interrupt+0x7a/0x280
eax: 0000000f7  ebx: 3281c0f7   ecx: efcec200   edx: 00000000
esi: eecc2070   edi: 00000007   ebp: 000000f3   esp: e99a9fc2
ds: 007b   es: 007b   ss: 0068
Process setiathome (pid: 1817, threadinfo=e99a8000 task=e9a92240)
Stack: ed7d5600 efcec000 efcec000 e99a9f68 eecc2070 00000000 00000001 f3851000
       00000014 e99a8000 c02f6d62 efcec000 efcec200 f3851000 00000001 efcec200
       ef00ef00 04000001 00000000 e99a9fc4 c010e06a 00000013 efcec000 e99a9fc4
Call Trace:
 [<c02f6d62>] rtl8169_interrupt+0xe2/0xf0
 [<c010e06a>] handle_IRQ_event+0x3a/0x70
 [<c010e401>] do_IRQ+0x91/0x130
 [<c0491cdc>] common_interrupt+0x18/0x20

Code: 24 14 89 d8 25 ff 1f 00 00 8d 68 fc 3b 2d 38 12 58 c0 0f 8c 3f 01 00 00 8b
 4c 24 30 c7 84 b9 90 00 00 00 00 00 00 00 8b 54 24 14 <8b> 42 68 85 c0 0f 85 14
 01 00 00 8b 82 a0 00 00 00 01 6a 64 01
 <0>Kernel panic: Fatal exception in interrupt
In interrupt handler not syncing


From dartnell@dim.uchile.cl Sun Feb  1 08:52:24 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Feb 2004 08:52:32 -0800 (PST)
Received: from naboo.manquehue.net (naboo.manquehue.net [200.74.160.92])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i11GqI7J016251
	for <netdev@oss.sgi.com>; Sun, 1 Feb 2004 08:52:19 -0800
Received: from alderaan.manquehue.net (200.74.160.98) by naboo.manquehue.net (6.0.037)
        id 401AC3F30003A13C; Sun, 1 Feb 2004 13:16:50 -0300
Received: from dim.uchile.cl (64.117.144.198) by alderaan.manquehue.net (6.0.037) (authenticated as dartnell@manquehue.net)
        id 401AC42D000470CD; Sun, 1 Feb 2004 13:17:08 -0300
Message-ID: <401D2F80.20007@dim.uchile.cl>
Date: Sun, 01 Feb 2004 13:55:28 -0300
From: "Pablo R. Dartnell" <dartnell@dim.uchile.cl>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en, es-cl, fr-fr
MIME-Version: 1.0
To: netdev@oss.sgi.com
CC: Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net>
Subject: forcedeth: Compilation fails for kernel 2.4.24
Content-Type: multipart/mixed;
 boundary="------------090406050307090209030003"
X-archive-position: 2924
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: dartnell@dim.uchile.cl
Precedence: bulk
X-list: netdev

This is a multi-part message in MIME format.
--------------090406050307090209030003
Content-Type: multipart/alternative;
 boundary="------------070605040306070602030603"


--------------070605040306070602030603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: Quoted-Printable

Hi,

Let me tell you first that I am not a programmer, so I am afraid all I=20
can tell you here is plainly what happened, but not why or what could=20
fix it. I found these addresses at the web page:
http://www.hailfinger.org/carldani/linux/patches/forcedeth/,
and I thought I should let you know what happened when trying to compile=20
the 2.4.24 kernel with the "forcedeth_2_4_patch_v22.txt" patch applied.

Here are the last few lines of output when running "make modules_install"=
:

make -C net modules
make[2]: Entering directory `/usr/src/linux-2.4.24/drivers/net'
gcc32 -D__KERNEL__ -I/usr/src/linux-2.4.24/include -Wall=20
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common=20
-fomit-frame-pointer -pipe -mpreferred-stack-boundary=3D2 -march=3Dathlon=
=20
-DMODULE -DMODVERSIONS -include=20
/usr/src/linux-2.4.24/include/linux/modversions.h  -nostdinc=20
-iwithprefix include -DKBUILD_BASENAME=3Dplip  -c -o plip.o plip.c
gcc32 -D__KERNEL__ -I/usr/src/linux-2.4.24/include -Wall=20
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common=20
-fomit-frame-pointer -pipe -mpreferred-stack-boundary=3D2 -march=3Dathlon=
=20
-DMODULE -DMODVERSIONS -include=20
/usr/src/linux-2.4.24/include/linux/modversions.h  -nostdinc=20
-iwithprefix include -DKBUILD_BASENAME=3Dforcedeth  -c -o forcedeth.o=20
forcedeth.c
forcedeth.c: In function `probe_nic':
forcedeth.c:1321: warning: implicit declaration of function `SET_NETDEV_D=
EV'
forcedeth.c:1321: structure has no member named `dev'
make[2]: *** [forcedeth.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.4.24/drivers/net'
make[1]: *** [_modsubdir_net] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.24/drivers'
make: *** [_mod_drivers] Error 2

I am running Fedora Core 1, may Mainboard is a MSI K7N2, the CPU is an At=
hlon XP 2600+. I am attaching the ".config" file in case it is of any use=
. If you need any other info, please let me know (and since I am not such=
 an expert in these things, if you want me to gather some info, please in=
clude very detailed, fool proof, instructions...)

By the way, the v20 version of the fercedeth driver compiled fine (and I =
am using it right now) with the 2.4.24 kernel.

I hope this is od some help to the great job you are doing...

Best regards,

Pablo


--=20
Pablo R. Dartnell (dartnell@dim.uchile.cl)
Departamento de Ingenier=EDa Matem=E1tica
Universidad de Chile


--------------070605040306070602030603
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7Bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
Let me tell you first that I am not a programmer, so I am afraid all I
can tell you here is plainly what happened, but not why or what could
fix it. I found these addresses at the web page:<br>
<a class="moz-txt-link-freetext" href="http://www.hailfinger.org/carldani/linux/patches/forcedeth/">http://www.hailfinger.org/carldani/linux/patches/forcedeth/</a>,<br>
and I thought I should let you know what happened when trying to
compile the 2.4.24 kernel with the "forcedeth_2_4_patch_v22.txt" patch
applied.<br>
<br>
Here are the last few lines of output when running "make
modules_install":<br>
<br>
<font color="#3333ff"><small>make -C net modules<br>
make[2]: Entering directory `/usr/src/linux-2.4.24/drivers/net'<br>
gcc32 -D__KERNEL__ -I/usr/src/linux-2.4.24/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=athlon
-DMODULE -DMODVERSIONS -include
/usr/src/linux-2.4.24/include/linux/modversions.h&nbsp; -nostdinc
-iwithprefix include -DKBUILD_BASENAME=plip&nbsp; -c -o plip.o plip.c<br>
gcc32 -D__KERNEL__ -I/usr/src/linux-2.4.24/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=athlon
-DMODULE -DMODVERSIONS -include
/usr/src/linux-2.4.24/include/linux/modversions.h&nbsp; -nostdinc
-iwithprefix include -DKBUILD_BASENAME=forcedeth&nbsp; -c -o forcedeth.o
forcedeth.c<br>
forcedeth.c: In function `probe_nic':<br>
forcedeth.c:1321: warning: implicit declaration of function
`SET_NETDEV_DEV'<br>
forcedeth.c:1321: structure has no member named `dev'<br>
make[2]: *** [forcedeth.o] Error 1<br>
make[2]: Leaving directory `/usr/src/linux-2.4.24/drivers/net'<br>
make[1]: *** [_modsubdir_net] Error 2<br>
make[1]: Leaving directory `/usr/src/linux-2.4.24/drivers'<br>
make: *** [_mod_drivers] Error 2</small></font><br>
<br>
<pre class="moz-signature" cols="72"><big>I am running Fedora Core 1, may Mainboard is a MSI K7N2, the CPU is an Athlon XP 2600+. I am attaching the ".config" file in case it is of any use. If you need any other info, please let me know (and since I am not such an expert in these things, if you want me to gather some info, please include very detailed, fool proof, instructions...)

By the way, the v20 version of the fercedeth driver compiled fine (and I am using it right now) with the 2.4.24 kernel.

I hope this is od some help to the great job you are doing...

Best regards,

Pablo

</big>
-- 
Pablo R. Dartnell (<a class="moz-txt-link-abbreviated" href="mailto:dartnell@dim.uchile.cl">dartnell@dim.uchile.cl</a>)
Departamento de Ingenier&iacute;a Matem&aacute;tica
Universidad de Chile
</pre>
</body>
</html>

--------------070605040306070602030603--

--------------090406050307090209030003
Content-Type: text/plain;
 name=".config"
Content-Disposition: inline;
 filename=".config"
Content-Transfer-Encoding: 7Bit

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_HAS_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_F00F_WORKS_OK=y
CONFIG_X86_MCE=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_EDD=m
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
CONFIG_HIGHIO=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_TSC_DISABLE is not set
CONFIG_X86_TSC=y

#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_ISA=y
CONFIG_PCI_NAMES=y
CONFIG_EISA=y
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
# CONFIG_PCMCIA is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
# CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set
# CONFIG_HOTPLUG_PCI_IBM is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PM=y
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
CONFIG_APM_RTC_IS_GMT=y
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# ACPI Support
#
# CONFIG_ACPI is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_SERIAL=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_SUNBPP is not set
# CONFIG_PARPORT_OTHER is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play configuration
#
CONFIG_PNP=y
CONFIG_ISAPNP=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
CONFIG_PARIDE=m
CONFIG_PARIDE_PARPORT=m

#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m

#
# Parallel IDE protocol modules
#
CONFIG_PARIDE_ATEN=m
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_BPCK6=m
CONFIG_PARIDE_COMM=m
CONFIG_PARIDE_DSTR=m
CONFIG_PARIDE_FIT2=m
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
CONFIG_PARIDE_EPATC8=y
CONFIG_PARIDE_EPIA=m
CONFIG_PARIDE_FRIQ=m
CONFIG_PARIDE_FRPW=m
CONFIG_PARIDE_KBIC=m
CONFIG_PARIDE_KTTI=m
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_CISS_SCSI_TAPE is not set
# CONFIG_CISS_MONITOR_THREAD is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_BLK_STATS=y

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_MULTIPATH is not set
CONFIG_BLK_DEV_LVM=m

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_NAT=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_TOS=y
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y

#
#   IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_UNCLEAN=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_MIRROR=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_NAT_AMANDA=m
CONFIG_IP_NF_NAT_LOCAL=y
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
CONFIG_IP_NF_COMPAT_IPCHAINS=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_COMPAT_IPFWADM=m
CONFIG_IP_NF_NAT_NEEDED=y

#
#   IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
CONFIG_IPV6=m

#
#   IPv6: Netfilter Configuration
#
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AHESP=m
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
# CONFIG_KHTTPD is not set

#
#    SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=m
# CONFIG_IP_SCTP is not set
CONFIG_ATM=y
CONFIG_ATM_CLIP=y
# CONFIG_ATM_CLIP_NO_ICMP is not set
CONFIG_ATM_LANE=m
CONFIG_ATM_MPOA=m
CONFIG_ATM_BR2684=m
CONFIG_ATM_BR2684_IPFILTER=y
CONFIG_VLAN_8021Q=m

#
#  
#
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m

#
# Appletalk devices
#
# CONFIG_DEV_APPLETALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set
# CONFIG_PHONE_IXJ_PCMCIA is not set

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_IDEDISK_STROKE is not set
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_BLK_DEV_ADMA100 is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_WDC_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
# CONFIG_AMD74XX_OVERRIDE is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_HPT34X_AUTODMA is not set
# CONFIG_BLK_DEV_HPT366 is not set
CONFIG_BLK_DEV_PIIX=m
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_PDC202XX_BURST is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_RZ1000 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=m
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_IDE_MODES=y
# CONFIG_BLK_DEV_ATARAID is not set
# CONFIG_BLK_DEV_ATARAID_PDC is not set
# CONFIG_BLK_DEV_ATARAID_HPT is not set
# CONFIG_BLK_DEV_ATARAID_SII is not set

#
# SCSI support
#
CONFIG_SCSI=m

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_SD_EXTRA_DEVS=40
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_SR_EXTRA_DEVS=4
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_DEBUG_QUEUES is not set
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_MEGARAID2 is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_DMA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_NCR53C8XX is not set
# CONFIG_SCSI_SYM53C8XX is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SIM710 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
CONFIG_SCSI_DEBUG=m

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_BOOT is not set
# CONFIG_FUSION_ISENSE is not set
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LAN is not set

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
CONFIG_IEEE1394=m

#
# Device Drivers
#
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=m

#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_SBP2_PHYS_DMA=y
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
CONFIG_IEEE1394_CMP=m
CONFIG_IEEE1394_AMDTP=m
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
# CONFIG_IEEE1394_OUI_DB is not set

#
# I2O device support
#
CONFIG_I2O=m
CONFIG_I2O_PCI=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_LAN=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
# CONFIG_ETHERTAP is not set
# CONFIG_NET_SB1000 is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_SUNLANCE is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_CS89x0 is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_DGRS is not set
# CONFIG_DM9102 is not set
# CONFIG_EEPRO100 is not set
# CONFIG_EEPRO100_PIO is not set
# CONFIG_E100 is not set
# CONFIG_LNE390 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
CONFIG_FORCEDETH=m
# CONFIG_NE3210 is not set
# CONFIG_ES3210 is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_SUNDANCE_MMIO is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_RHINE_MMIO is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_MYRI_SBUS is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
# CONFIG_PPP_BSDCOMP is not set
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
# CONFIG_STRIP is not set
# CONFIG_WAVELAN is not set
# CONFIG_ARLAN is not set
# CONFIG_AIRONET4500 is not set
# CONFIG_AIRONET4500_NONCS is not set
# CONFIG_AIRONET4500_PROC is not set
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_PLX_HERMES is not set
# CONFIG_TMD_HERMES is not set
# CONFIG_PCI_HERMES is not set
CONFIG_NET_WIRELESS=y

#
# Token Ring devices
#
# CONFIG_TR is not set
CONFIG_NET_FC=y
# CONFIG_IPHASE5526 is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
CONFIG_WAN=y
# CONFIG_HOSTESS_SV11 is not set
# CONFIG_COSA is not set
# CONFIG_COMX is not set
# CONFIG_DSCC4 is not set
# CONFIG_LANMEDIA is not set
# CONFIG_ATI_XX20 is not set
# CONFIG_SEALEVEL_4021 is not set
# CONFIG_SYNCLINK_SYNCPPP is not set
# CONFIG_HDLC is not set
# CONFIG_DLCI is not set
# CONFIG_LAPBETHER is not set
# CONFIG_X25_ASY is not set
# CONFIG_SBNI is not set

#
# ATM drivers
#
# CONFIG_ATM_TCP is not set
# CONFIG_ATM_LANAI is not set
# CONFIG_ATM_ENI is not set
# CONFIG_ATM_FIRESTREAM is not set
# CONFIG_ATM_ZATM is not set
# CONFIG_ATM_NICSTAR is not set
# CONFIG_ATM_IDT77252 is not set
# CONFIG_ATM_AMBASSADOR is not set
# CONFIG_ATM_HORIZON is not set
# CONFIG_ATM_IA is not set
# CONFIG_ATM_FORE200E_MAYBE is not set
# CONFIG_ATM_HE is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
CONFIG_IRDA=m

#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
CONFIG_IRDA_ULTRA=y

#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
# CONFIG_IRDA_DEBUG is not set

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m
CONFIG_IRPORT_SIR=m

#
# Dongle support
#
CONFIG_DONGLE=y
CONFIG_ESI_DONGLE=m
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
CONFIG_GIRBIL_DONGLE=m
CONFIG_LITELINK_DONGLE=m
CONFIG_MCP2120_DONGLE=m
CONFIG_OLD_BELKIN_DONGLE=m
CONFIG_ACT200L_DONGLE=m
CONFIG_MA600_DONGLE=m

#
# FIR device drivers
#
CONFIG_USB_IRDA=m
CONFIG_NSC_FIR=m
CONFIG_WINBOND_FIR=m
CONFIG_TOSHIBA_OLD=m
CONFIG_TOSHIBA_FIR=m
CONFIG_SMC_IRCC_FIR=m
CONFIG_ALI_FIR=m
CONFIG_VLSI_FIR=m

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Input core support
#
CONFIG_INPUT=m
CONFIG_INPUT_KEYBDEV=m
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_EVDEV=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_SERIAL_EXTENDED=y
CONFIG_SERIAL_MANY_PORTS=y
CONFIG_SERIAL_SHARE_IRQ=y
# CONFIG_SERIAL_DETECT_IRQ is not set
# CONFIG_SERIAL_MULTIPORT is not set
# CONFIG_HUB6 is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=2048
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
CONFIG_TIPAR=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_PHILIPSPAR=m
CONFIG_I2C_ELV=m
CONFIG_I2C_VELLEMAN=m
# CONFIG_SCx200_I2C is not set
# CONFIG_SCx200_ACB is not set
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ELEKTOR=m
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_PROC=m

#
# Mice
#
CONFIG_BUSMOUSE=m
CONFIG_ATIXL_BUSMOUSE=m
CONFIG_LOGIBUSMOUSE=m
CONFIG_MS_BUSMOUSE=m
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
CONFIG_82C710_MOUSE=m
CONFIG_PC110_PAD=m
CONFIG_MK712_MOUSE=m

#
# Joysticks
#
CONFIG_INPUT_GAMEPORT=m
CONFIG_INPUT_NS558=m
CONFIG_INPUT_LIGHTNING=m
CONFIG_INPUT_PCIGAME=m
CONFIG_INPUT_CS461X=m
CONFIG_INPUT_EMU10K1=m
CONFIG_INPUT_SERIO=m
CONFIG_INPUT_SERPORT=m

#
# Joysticks
#
CONFIG_INPUT_ANALOG=m
CONFIG_INPUT_A3D=m
CONFIG_INPUT_ADI=m
CONFIG_INPUT_COBRA=m
CONFIG_INPUT_GF2K=m
CONFIG_INPUT_GRIP=m
CONFIG_INPUT_INTERACT=m
CONFIG_INPUT_TMDC=m
CONFIG_INPUT_SIDEWINDER=m
CONFIG_INPUT_IFORCE_USB=m
CONFIG_INPUT_IFORCE_232=m
CONFIG_INPUT_WARRIOR=m
CONFIG_INPUT_MAGELLAN=m
CONFIG_INPUT_SPACEORB=m
CONFIG_INPUT_SPACEBALL=m
CONFIG_INPUT_STINGER=m
CONFIG_INPUT_DB9=m
CONFIG_INPUT_GAMECON=m
CONFIG_INPUT_TURBOGRAFX=m
# CONFIG_QIC02_TAPE is not set
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_KCS=m
CONFIG_IPMI_WATCHDOG=m

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
# CONFIG_SC520_WDT is not set
# CONFIG_PCWATCHDOG is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_WAFER_WDT is not set
CONFIG_I810_TCO=m
# CONFIG_MIXCOMWD is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_SCx200_WDT is not set
CONFIG_SOFT_WATCHDOG=m
# CONFIG_W83877F_WDT is not set
# CONFIG_WDT is not set
# CONFIG_WDTPCI is not set
# CONFIG_MACHZ_WDT is not set
CONFIG_AMD7XX_TCO=m
# CONFIG_SCx200_GPIO is not set
CONFIG_AMD_RNG=m
CONFIG_INTEL_RNG=m
CONFIG_HW_RANDOM=m
CONFIG_AMD_PM768=m
CONFIG_NVRAM=m
CONFIG_RTC=y
CONFIG_DTLK=m
CONFIG_R3964=m
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
CONFIG_FTAPE=m
CONFIG_ZFTAPE=m
CONFIG_ZFT_DFLT_BLK_SZ=10240

#
#   The compressor will be built as a module only!
#
CONFIG_ZFT_COMPRESSOR=m
CONFIG_FT_NR_BUFFERS=3
# CONFIG_FT_PROC_FS is not set
CONFIG_FT_NORMAL_DEBUG=y
# CONFIG_FT_FULL_DEBUG is not set
# CONFIG_FT_NO_TRACE is not set
# CONFIG_FT_NO_TRACE_AT_ALL is not set

#
# Hardware configuration
#
CONFIG_FT_STD_FDC=y
# CONFIG_FT_MACH2 is not set
# CONFIG_FT_PROBE_FC10 is not set
# CONFIG_FT_ALT_FDC is not set
CONFIG_FT_FDC_THR=8
CONFIG_FT_FDC_MAX_RATE=2000
CONFIG_FT_ALPHA_CLOCK=0
CONFIG_AGP=m
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_I810 is not set
CONFIG_AGP_VIA=y
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD_K8 is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_SWORKS is not set
CONFIG_AGP_NVIDIA=y
# CONFIG_AGP_ATI is not set

#
# Direct Rendering Manager (XFree86 DRI support)
#
CONFIG_DRM=y
# CONFIG_DRM_OLD is not set

#
# DRM 4.1 drivers
#
CONFIG_DRM_NEW=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_GAMMA is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
CONFIG_DRM_I810=m
# CONFIG_DRM_I810_XFREE_41 is not set
CONFIG_DRM_I830=m
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_MWAVE is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#
CONFIG_VIDEO_PROC_FS=y
CONFIG_I2C_PARPORT=m

#
# Video Adapters
#
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_PMS=m
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
CONFIG_VIDEO_CPIA_USB=m
CONFIG_VIDEO_SAA5249=m
CONFIG_TUNER_3036=m
CONFIG_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=m
CONFIG_VIDEO_ZORAN_LML33=m
CONFIG_VIDEO_ZR36120=m
# CONFIG_VIDEO_MEYE is not set

#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_MIROPCM20 is not set
# CONFIG_RADIO_MIROPCM20_RDS is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set

#
# File systems
#
CONFIG_QUOTA=y
CONFIG_QFMT_V2=m
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
CONFIG_HFS_FS=m
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BEFS_DEBUG is not set
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_UMSDOS_FS=m
CONFIG_VFAT_FS=m
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
# CONFIG_JFS_FS is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
CONFIG_MINIX_FS=m
# CONFIG_VXFS_FS is not set
CONFIG_NTFS_FS=m
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
CONFIG_ROMFS_FS=m
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
CONFIG_UDF_FS=m
CONFIG_UDF_RW=y
# CONFIG_UFS_FS is not set
# CONFIG_UFS_FS_WRITE is not set

#
# Network File Systems
#
CONFIG_CODA_FS=m
CONFIG_INTERMEZZO_FS=m
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_TCP is not set
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_ZISOFS_FS=y

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
CONFIG_MINIX_SUBPARTITION=y
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
CONFIG_SMB_NLS=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m

#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_MDA_CONSOLE=m

#
# Frame-buffer support
#
CONFIG_FB=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FB_RIVA=m
# CONFIG_FB_CLGEN is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CYBER2000 is not set
CONFIG_FB_VESA=y
CONFIG_FB_VGA16=m
# CONFIG_FB_HGA is not set
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_MATROX is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
CONFIG_FB_INTEL=m
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FBCON_ADVANCED is not set
CONFIG_FBCON_CFB8=y
CONFIG_FBCON_CFB16=y
CONFIG_FBCON_CFB24=y
CONFIG_FBCON_CFB32=y
CONFIG_FBCON_VGA_PLANES=m
# CONFIG_FBCON_FONTWIDTH8_ONLY is not set
# CONFIG_FBCON_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Sound
#
CONFIG_SOUND=m
# CONFIG_SOUND_ALI5455 is not set
# CONFIG_SOUND_BT878 is not set
# CONFIG_SOUND_CMPCI is not set
# CONFIG_SOUND_EMU10K1 is not set
# CONFIG_MIDI_EMU10K1 is not set
# CONFIG_SOUND_FUSION is not set
# CONFIG_SOUND_CS4281 is not set
# CONFIG_SOUND_ES1370 is not set
# CONFIG_SOUND_ES1371 is not set
# CONFIG_SOUND_ESSSOLO1 is not set
# CONFIG_SOUND_MAESTRO is not set
# CONFIG_SOUND_MAESTRO3 is not set
# CONFIG_SOUND_FORTE is not set
CONFIG_SOUND_ICH=m
# CONFIG_SOUND_RME96XX is not set
# CONFIG_SOUND_SONICVIBES is not set
# CONFIG_SOUND_TRIDENT is not set
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
# CONFIG_SOUND_VIA82CXXX is not set
# CONFIG_MIDI_VIA82CXXX is not set
CONFIG_SOUND_OSS=m
# CONFIG_SOUND_TRACEINIT is not set
CONFIG_SOUND_DMAP=y
# CONFIG_SOUND_AD1816 is not set
# CONFIG_SOUND_AD1889 is not set
# CONFIG_SOUND_SGALAXY is not set
# CONFIG_SOUND_ADLIB is not set
# CONFIG_SOUND_ACI_MIXER is not set
# CONFIG_SOUND_CS4232 is not set
# CONFIG_SOUND_SSCAPE is not set
# CONFIG_SOUND_GUS is not set
CONFIG_SOUND_VMIDI=m
# CONFIG_SOUND_TRIX is not set
# CONFIG_SOUND_MSS is not set
CONFIG_SOUND_MPU401=m
# CONFIG_SOUND_NM256 is not set
# CONFIG_SOUND_MAD16 is not set
# CONFIG_SOUND_PAS is not set
# CONFIG_PAS_JOYSTICK is not set
# CONFIG_SOUND_PSS is not set
# CONFIG_SOUND_SB is not set
# CONFIG_SOUND_AWE32_SYNTH is not set
# CONFIG_SOUND_KAHLUA is not set
# CONFIG_SOUND_WAVEFRONT is not set
# CONFIG_SOUND_MAUI is not set
CONFIG_SOUND_YM3812=m
# CONFIG_SOUND_OPL3SA1 is not set
# CONFIG_SOUND_OPL3SA2 is not set
# CONFIG_SOUND_YMFPCI is not set
# CONFIG_SOUND_YMFPCI_LEGACY is not set
CONFIG_SOUND_UART6850=m
# CONFIG_SOUND_AEDSP16 is not set
# CONFIG_SOUND_TVMIXER is not set
# CONFIG_SOUND_AD1980 is not set
# CONFIG_SOUND_WM97XX is not set

#
# USB support
#
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_UHCI=m
CONFIG_USB_UHCI_ALT=m
CONFIG_USB_OHCI=m
CONFIG_USB_SL811HS_ALT=m
# CONFIG_USB_SL811HS is not set

#
# USB Device Class drivers
#
CONFIG_USB_AUDIO=m
# CONFIG_USB_EMI26 is not set

#
#   USB Bluetooth can only be used with disabled Bluetooth subsystem
#
CONFIG_USB_MIDI=m
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_HP8200e=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
CONFIG_USB_HIDDEV=y
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
CONFIG_USB_AIPTEK=m
CONFIG_USB_WACOM=m
CONFIG_USB_KBTAB=m
CONFIG_USB_POWERMATE=m

#
# USB Imaging devices
#
CONFIG_USB_DC2XX=m
CONFIG_USB_MDC800=m
CONFIG_USB_SCANNER=m
CONFIG_USB_MICROTEK=m
CONFIG_USB_HPUSBSCSI=m

#
# USB Multimedia devices
#
CONFIG_USB_IBMCAM=m
CONFIG_USB_KONICAWC=m
CONFIG_USB_OV511=m
CONFIG_USB_PWC=m
CONFIG_USB_SE401=m
CONFIG_USB_STV680=m
CONFIG_USB_W9968CF=m
CONFIG_USB_VICAM=m
CONFIG_USB_DSBR=m
CONFIG_USB_DABUSB=m

#
# USB Network adaptors
#
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_KAWETH=m
CONFIG_USB_CATC=m
CONFIG_USB_AX8817X=m
CONFIG_USB_CDCETHER=m
CONFIG_USB_USBNET=m

#
# USB port drivers
#
CONFIG_USB_USS720=m

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
# CONFIG_USB_SERIAL_DEBUG is not set
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
# CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
# CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
CONFIG_USB_SERIAL_KEYSPAN_MPR=y
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OMNINET=m

#
# USB Miscellaneous drivers
#
CONFIG_USB_RIO500=m
CONFIG_USB_AUERSWALD=m
CONFIG_USB_TIGL=m
CONFIG_USB_BRLVGER=m
CONFIG_USB_LCD=m
CONFIG_USB_SPEEDTOUCH=m

#
# Support for USB gadgets
#
# CONFIG_USB_GADGET is not set

#
# Bluetooth support
#
CONFIG_BLUEZ=m
CONFIG_BLUEZ_L2CAP=m
CONFIG_BLUEZ_SCO=m
CONFIG_BLUEZ_RFCOMM=m
CONFIG_BLUEZ_RFCOMM_TTY=y
CONFIG_BLUEZ_BNEP=m
CONFIG_BLUEZ_BNEP_MC_FILTER=y
CONFIG_BLUEZ_BNEP_PROTO_FILTER=y

#
# Bluetooth device drivers
#
CONFIG_BLUEZ_HCIUSB=m
CONFIG_BLUEZ_USB_SCO=y
CONFIG_BLUEZ_HCIUART=m
CONFIG_BLUEZ_HCIUART_H4=y
CONFIG_BLUEZ_HCIUART_BCSP=y
CONFIG_BLUEZ_HCIUART_BCSP_TXCRC=y
CONFIG_BLUEZ_HCIBFUSB=m
# CONFIG_BLUEZ_HCIDTL1 is not set
# CONFIG_BLUEZ_HCIBT3C is not set
# CONFIG_BLUEZ_HCIBLUECARD is not set
# CONFIG_BLUEZ_HCIBTUART is not set
CONFIG_BLUEZ_HCIVHCI=m

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_LOG_BUF_SHIFT=0

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_TEST=m

#
# Library routines
#
CONFIG_CRC32=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_FW_LOADER=m

--------------090406050307090209030003--


From niv@us.ibm.com Sun Feb  1 10:32:29 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Feb 2004 10:32:32 -0800 (PST)
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i11IWM7J018829
	for <netdev@oss.sgi.com>; Sun, 1 Feb 2004 10:32:29 -0800
Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33])
	by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i11IWGlv630116
	for <netdev@oss.sgi.com>; Sun, 1 Feb 2004 13:32:16 -0500
Received: from us.ibm.com (d03av01.boulder.ibm.com [9.17.193.81])
	by westrelay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i11IWF6U063060
	for <netdev@oss.sgi.com>; Sun, 1 Feb 2004 11:32:16 -0700
Message-ID: <401D45AD.8010105@us.ibm.com>
Date: Sun, 01 Feb 2004 10:30:05 -0800
From: Nivedita Singhvi <niv@us.ibm.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: netdev <netdev@oss.sgi.com>
Subject: [Fwd: [Bug 1994] New: pinging endpoint through IPSec tunnel crashes
 target]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-archive-position: 2925
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: niv@us.ibm.com
Precedence: bulk
X-list: netdev

Anyone?

thanks,
Nivedita

-------- Original Message --------
Subject: [Bug 1994] New: pinging endpoint through IPSec tunnel crashes target
Date: Sun, 1 Feb 2004 09:59:04 -0800
From: bugme-daemon@osdl.org
To: niv@us.ibm.com

http://bugme.osdl.org/show_bug.cgi?id=1994

            Summary: pinging endpoint through IPSec tunnel crashes target
     Kernel Version: 2.6.1
             Status: NEW
           Severity: blocking
              Owner: niv@us.ibm.com
          Submitter: casteyde.christian@free.fr


Distribution:
Slackware 9.1 + vanilla 2.6.1 kernel compiled from source + pppd 2.4.2

Hardware Environment:
K7 2GHz + ne2k Ethernet cards + ppp + pppoe + netfilter + ipv4 ipsec

Software Environment:
kame tools for ipsec, pppd 2.4.2 + pppoe plugin for Internet connection

Problem Description:
I tried to build an experimental IPSec tunnel with manual keying,
to forward traffic from dummy network of computer A to dummy network
of computer B, which are interconnected by a real network.

I therefore mount dummy0 on both computers (192.168.20.1 and 192.168.20.2),
activated IP forwarding on both, relax firewall rules, and set up
IPv4 IPSec tunnel between both computer to relay packets from 192.168.20.x
through my Internet connection.
My ipsec.conf file defines IPSec policy as shown :

spdadd 192.168.20.1 192.168.20.2 any -P out ipsec
         esp/tunnel/xx.yy.zzz.tt-uu.170.31.3/require
         ah/tunnel/xx.yy.zzz.tt-uu.170.31.3/require;

spdadd 192.168.20.2 192.168.20.1 any -P in ipsec
         esp/tunnel/xx.yy.zzz.tt-uu.170.31.3/require
         ah/tunnel/xx.yy.zzz.tt-uu.170.31.3/require;

(real IP adresses masked).

Then ping 192.168.20.1 crashes the pinged machine.
Oops not available (system freeze under X11).

Steps to reproduce:
Build an IPSec tunnel and ping the remote machine
as described upper.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



From c-d.hailfinger.kernel.2004@gmx.net Sun Feb  1 10:34:33 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Feb 2004 10:34:38 -0800 (PST)
Received: from mail.gmx.net (imap.gmx.net [213.165.64.20])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i11IYW7J019244
	for <netdev@oss.sgi.com>; Sun, 1 Feb 2004 10:34:32 -0800
Received: (qmail 23324 invoked by uid 65534); 1 Feb 2004 18:34:26 -0000
Received: from stud213178.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.213.178)
  by mail.gmx.net (mp005) with SMTP; 01 Feb 2004 19:34:26 +0100
X-Authenticated: #21910825
Message-ID: <401D46AD.2040009@gmx.net>
Date: Sun, 01 Feb 2004 19:34:21 +0100
From: Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821
X-Accept-Language: de, en
MIME-Version: 1.0
To: "Pablo R. Dartnell" <dartnell@dim.uchile.cl>
CC: netdev@oss.sgi.com
Subject: Re: forcedeth: Compilation fails for kernel 2.4.24
References: <401D2F80.20007@dim.uchile.cl>
In-Reply-To: <401D2F80.20007@dim.uchile.cl>
X-Enigmail-Version: 0.76.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-archive-position: 2926
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: c-d.hailfinger.kernel.2004@gmx.net
Precedence: bulk
X-list: netdev

Hi Pablo,

Pablo R. Dartnell wrote:
> Hi,
> 
> Let me tell you first that I am not a programmer, so I am afraid all I
> can tell you here is plainly what happened, but not why or what could
> fix it. I found these addresses at the web page:
> http://www.hailfinger.org/carldani/linux/patches/forcedeth/,
> and I thought I should let you know what happened when trying to compile
> the 2.4.24 kernel with the "forcedeth_2_4_patch_v22.txt" patch applied.

Your report gives all necessary details.

> Here are the last few lines of output when running "make modules_install":
> [...]
> forcedeth.c: In function `probe_nic':
> forcedeth.c:1321: warning: implicit declaration of function
> `SET_NETDEV_DEV'
> forcedeth.c:1321: structure has no member named `dev'

The problem is known and there are two possible solutions:
1. Apply patch-2.4.25-pre8.gz from
ftp://ftp.kernel.org/pub/linux/kernel/v2.4/testing/
2. Send me some mail requesting the necessary compatibility headers

Basically, forcedeth 0.22 and later versions need either a 2.6 series
kernel or 2.4.25-pre7 or later. That allowed me to remove much of the
compatibility cruft.


HTH,
Carl-Daniel
-- 
http://www.hailfinger.org/


From davem@redhat.com Sun Feb  1 11:49:39 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Feb 2004 11:49:42 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i11Jnc7J021362;
	Sun, 1 Feb 2004 11:49:38 -0800
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i11Jnbb27575;
	Sun, 1 Feb 2004 14:49:37 -0500
Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i11Jnba03911;
	Sun, 1 Feb 2004 14:49:37 -0500
Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1])
	by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i11Jn8kC001856;
	Sun, 1 Feb 2004 14:49:09 -0500
Date: Sun, 1 Feb 2004 11:49:36 -0800
From: "David S. Miller" <davem@redhat.com>
To: netdev@oss.sgi.com
Cc: linux-net@oss.sgi.com
Subject: TCP westwood 2.4.x and 2.6.x net BK trees
Message-Id: <20040201114936.08f42cad.davem@redhat.com>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu)
X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 2927
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: davem@redhat.com
Precedence: bulk
X-list: netdev


For the BK inclined, I've put up a publicly accessible BK tree of
the 2.4.x TCP Westwood stuff at:

	bk://kernel.bkbits.net/davem/tcpwestwood-2.4

so people can play with it if they want.  Remember you need to enable
the /proc/sys/net/ipv4/tcp_westwood sysctl for the new code to even be
used :-)

I've also put my current 2.6.3-pre1 pending networking tree up at:

	bk://kernel.bkbits.net/davem/net-2.5

It has Stephen's westwood port in it.

Enjoy.

ChangeSet@1.1301.1.1, 2004-01-30 13:05:20-08:00, buffer@antifork.org
  [TCP]: Add Westwood+ support, off by default.

 include/linux/sysctl.h     |    1 
 include/net/sock.h         |   15 ++
 include/net/tcp.h          |  121 ++++++++++++++++++
 net/ipv4/sysctl_net_ipv4.c |    6 
 net/ipv4/tcp_input.c       |  290 ++++++++++++++++++++++++++++++++++++++++++++-
 5 files changed, 429 insertions(+), 4 deletions(-)


ChangeSet@1.1301.1.2, 2004-01-30 14:57:14-08:00, davem@nuts.davemloft.net
  [TCP]: Put tcp_ prefix on global westwood symbols.

 include/net/tcp.h    |   46 +++++++++++++++++++++++-----------------------
 net/ipv4/tcp_input.c |   22 +++++++++++-----------
 2 files changed, 34 insertions(+), 34 deletions(-)


ChangeSet@1.1301.1.3, 2004-01-30 15:19:14-08:00, davem@nuts.davemloft.net
  [TCP]: Coding style fixes to westwood code.

 include/net/tcp.h    |   76 ++++++++++++++++-------------------
 net/ipv4/tcp_input.c |  110 +++++++++++++++++++++++----------------------------
 2 files changed, 87 insertions(+), 99 deletions(-)


ChangeSet@1.1301.1.4, 2004-01-30 15:23:52-08:00, davem@nuts.davemloft.net
  [TCP]: Kill westwood specific lock, unneeded.

 include/net/sock.h   |    1 -
 include/net/tcp.h    |    1 -
 net/ipv4/tcp_input.c |   15 +--------------
 3 files changed, 1 insertion(+), 16 deletions(-)


ChangeSet@1.1301.1.5, 2004-02-01 11:06:29-08:00, davem@nuts.davemloft.net
  [TCP]: Kill bogus reference to CONFIG_TCP_WESTWOOD.

 net/ipv4/tcp_input.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)


ChangeSet@1.1307, 2004-02-01 11:43:53-08:00, davem@kernel.bkbits.net
  Merge davem@nuts.davemloft.net:/disk1/davem/BK/tcp-2.4
  into kernel.bkbits.net:/home/davem/tcpwestwood-2.4

 include/linux/sysctl.h |    1 +
 1 files changed, 1 insertion(+)



From gozdal@gozdal.eu.org Sun Feb  1 13:58:39 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Feb 2004 13:58:42 -0800 (PST)
Received: from mail.gozdal.eu.org (115-mo3-8.acn.waw.pl [62.121.111.115])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i11Lwb7J027702
	for <netdev@oss.sgi.com>; Sun, 1 Feb 2004 13:58:38 -0800
Received: by mail.gozdal.eu.org (Postfix, from userid 1000)
	id 524382A1; Sun,  1 Feb 2004 22:58:36 +0100 (CET)
Date: Sun, 1 Feb 2004 22:58:36 +0100
To: netdev@oss.sgi.com
Subject: Handling a few hundred thousand TCP flows
Message-ID: <20040201215836.GC16978@gozdal.eu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.5.1+cvs20040112i
From: gozdal@gozdal.eu.org (Marcin Gozdalik)
X-archive-position: 2928
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: gozdal@gozdal.eu.org
Precedence: bulk
X-list: netdev

Hello

I've been successfully using Linux 2.4 for handling many thousands TCP
flows (300k non-stop). I've been wondering which options I should use to
minimize CPU and memory consumption.
I've followed the thread from December about handling 90k TCP streams
and suggestions contained there. I thought however of some more radical
solutions: disabling rt_cache altogether. The routing table contains
whole 2 entries (for eth0 subnet and default gateway) so I'd assume that
walking linearily such short list would be a win cache-wise compared to
huge rt_cache? Or is it a completely stupid idea not worth implementing?
Additionally, I've disabled ECN and SACKs. Does it make any sense? Or
are performance/memory gains negligible?

Cheers,
Marcin

From davem@redhat.com Sun Feb  1 15:24:40 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Feb 2004 15:24:51 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i11NOd7J030718
	for <netdev@oss.sgi.com>; Sun, 1 Feb 2004 15:24:40 -0800
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i11NObb19091;
	Sun, 1 Feb 2004 18:24:37 -0500
Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i11NOba29729;
	Sun, 1 Feb 2004 18:24:37 -0500
Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1])
	by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i11NO8kC013180;
	Sun, 1 Feb 2004 18:24:08 -0500
Date: Sun, 1 Feb 2004 15:24:35 -0800
From: "David S. Miller" <davem@redhat.com>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: schwidefsky@de.ibm.com, zaitcev@redhat.com, utz.bacher@de.ibm.com,
        pavlic@de.ibm.com, netdev@oss.sgi.com
Subject: Re: netdevice->generate_eui64
Message-Id: <20040201152435.34f4231e.davem@redhat.com>
In-Reply-To: <20040130170316.789e8939.zaitcev@redhat.com>
References: <20040130170316.789e8939.zaitcev@redhat.com>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu)
X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 2929
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: davem@redhat.com
Precedence: bulk
X-list: netdev

On Fri, 30 Jan 2004 17:03:16 -0800
Pete Zaitcev <zaitcev@redhat.com> wrote:

> Does anyone know where I can find a patch to add dev->generate_eui64?
> The qeth in 2.6 tree requires it to be built (with IPv6). I am talking
> about a descendant of this patch:
>  http://www.ussg.iu.edu/hypermail/linux/net/0303.0/0037.html

I don't want to see this btw, as I mentioned ipv6 specific things do not
belong in the generic device struct.  There surely are better ways and I'm
totally open to suggestions.


From alextreme@xs4all.nl Sun Feb  1 16:47:10 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Feb 2004 16:47:14 -0800 (PST)
Received: from am.xs4all.nl (mail@am.xs4all.nl [213.84.116.104])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i120l77J004022
	for <netdev@oss.sgi.com>; Sun, 1 Feb 2004 16:47:09 -0800
Received: from www-data by am.xs4all.nl with local (Exim 3.36 #1 (Debian))
	id 1AnSEw-0006X5-00; Mon, 02 Feb 2004 01:47:02 +0100
Received: from omega (omega [127.0.0.1]) 
	by am.xs4all.nl (IMP) with HTTP 
	for <alex@localhost>; Mon,  2 Feb 2004 01:47:02 +0100
Message-ID: <1075682822.401d9e06885a0@am.xs4all.nl>
Date: Mon,  2 Feb 2004 01:47:02 +0100
From: Alex de Landgraaf <alextreme@xs4all.nl>
To: netdev@oss.sgi.com
Cc: Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net>
Subject: [forcedeth] SET_NETDEV_DEV define
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.2
X-archive-position: 2930
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: alextreme@xs4all.nl
Precedence: bulk
X-list: netdev

Hey guys,

Nice work on the forcedeth patches! I've been waiting for a nvnet alternative
for some time, and this seems to be it.

Anyway, in the forcedeth 2.4 v22 patch, it seems that forcedeth.c is missing the
#define SET_NETDEV_DEV from v20. Adding it is relativly simple, just wanted to
let you guys know that it doesn't compile on 2.4.23+ kernels (if you hadn't
heard this earlier).

from v20:
#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,5,70))
#define SET_NETDEV_DEV(x,y)   do { } while(0)
#endif

Could make a patch for it, but honestly I can't be bothered :)

It could also be that I got it completly wrong, in which case you can smack me
with the cluebat

Cheers and keep up with the good work,

/------------------------------------------------------------------\
| Alex de Landgraaf            | The cure for boredom is curiosity |
| Student AI & CS, VU, A'dam   |  There is no cure for curiosity   |
| Phone: 06-16844084           |                                   |
| GPG: http://am.xs4all.nl/key_alex.asc         /'-'\              |
| www.alextreme.org & www.morphix.org          ( o o )             |
\------------------------------------------oOO0--(_)--0OOo---------/




From c-d.hailfinger.kernel.2004@gmx.net Sun Feb  1 17:18:36 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Feb 2004 17:18:39 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i121IZ7J005328
	for <netdev@oss.sgi.com>; Sun, 1 Feb 2004 17:18:36 -0800
Received: (qmail 26450 invoked by uid 65534); 2 Feb 2004 01:18:29 -0000
Received: from stud212086.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.212.86)
  by mail.gmx.net (mp009) with SMTP; 02 Feb 2004 02:18:29 +0100
X-Authenticated: #21910825
Message-ID: <401DA565.4050303@gmx.net>
Date: Mon, 02 Feb 2004 02:18:29 +0100
From: Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821
X-Accept-Language: de, en
MIME-Version: 1.0
To: Alex de Landgraaf <alextreme@xs4all.nl>
CC: netdev@oss.sgi.com
Subject: Re: [forcedeth] SET_NETDEV_DEV define
References: <1075682822.401d9e06885a0@am.xs4all.nl>
In-Reply-To: <1075682822.401d9e06885a0@am.xs4all.nl>
X-Enigmail-Version: 0.76.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-archive-position: 2931
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: c-d.hailfinger.kernel.2004@gmx.net
Precedence: bulk
X-list: netdev

Hi Alex,

Alex de Landgraaf wrote:
> Hey guys,
> 
> Nice work on the forcedeth patches! I've been waiting for a nvnet alternative
> for some time, and this seems to be it.
> 
> Anyway, in the forcedeth 2.4 v22 patch, it seems that forcedeth.c is missing the
> #define SET_NETDEV_DEV from v20. Adding it is relativly simple, just wanted to
> let you guys know that it doesn't compile on 2.4.23+ kernels (if you hadn't
> heard this earlier).

SET_NETDEV_DEV is in since 2.4.24-pre1 (but not in 2.4.24 due to
branching), so I decided to drop the macro. However it seems many people
use older kernels, so I will probably provide a patch that will also
compile for kernels older than current prepatches.

Since this has bitten a few users in the past week, I added a note to the
documents at http://www.hailfinger.org/carldani/linux/patches/forcedeth/

Basically, I wanted to reduce compatibility cruft to zero before
submitting the driver to Marcelo.


Thanks for the heads up,
Carl-Daniel


From weixl@caltech.edu Sun Feb  1 22:01:43 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Feb 2004 22:01:48 -0800 (PST)
Received: from steelemr-loadb-nat-49.caltech.edu (SteeleMR-loadb-NAT-49.caltech.edu [131.215.49.69])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1261h7J018208
	for <netdev@oss.sgi.com>; Sun, 1 Feb 2004 22:01:43 -0800
Received: from water-dog (water-dog [192.168.1.26])
	by water-ox-postvirus (Postfix) with ESMTP
	id 4ADA726ADE2; Sun,  1 Feb 2004 22:01:38 -0800 (PST)
Received: from water-ox ([192.168.1.10])
	by water-dog (MailMonitor for SMTP v1.2.2 ) ;
	Sun, 1 Feb 2004 22:01:37 -0800 (PST)
Received: from weixl (DHCP-45-225.cs.caltech.edu [131.215.45.225])
	by water-ox.its.caltech.edu (Postfix) with ESMTP
	id 4CF4D26ADE6; Sun,  1 Feb 2004 22:01:37 -0800 (PST)
Message-ID: <005401c3e952$04c279f0$f5f2010a@weixl>
From: "Xiaoliang (David) Wei" <weixl@caltech.edu>
To: <netdev@oss.sgi.com>, "Marcin Gozdalik" <gozdal@gozdal.eu.org>
References: <20040201215836.GC16978@gozdal.eu.org>
Subject: Re: Handling a few hundred thousand TCP flows
Date: Sun, 1 Feb 2004 22:01:37 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-archive-position: 2932
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: weixl@caltech.edu
Precedence: bulk
X-list: netdev

Hi,
> I've been successfully using Linux 2.4 for handling many thousands TCP
> flows (300k non-stop). I've been wondering which options I should use to
> minimize CPU and memory consumption.
> I've followed the thread from December about handling 90k TCP streams
> and suggestions contained there. I thought however of some more radical
> solutions: disabling rt_cache altogether. The routing table contains
> whole 2 entries (for eth0 subnet and default gateway) so I'd assume that
> walking linearily such short list would be a win cache-wise compared to
> huge rt_cache? Or is it a completely stupid idea not worth implementing?
> Additionally, I've disabled ECN and SACKs. Does it make any sense? Or
> are performance/memory gains negligible?
    I think SACK will have some overhead since it goes through the
retransmission queue for each SACK option. But this only happens when the
ack packet contains SACK.
    For memory, Linux allocate a block of memory for each connection
(usually 64KB). This is the buffer for the sliding-window algorithm. You can
change this memory buffer size to be w. The principle is that: w*N cannot be
too large in comparison to the memory in you machine (where N is # of
connections). The effect of a small buffer size w is that the window for
each TCP conneciton cannot be high -- hence the throughput of each flow is
low if the RTT is not negligible.
    Web100 project (http://www.web100.org) provide a patch to dynamically
allocate memory for different flows and maintains a static size of aggregate
buffer for all the connections.


-David



From steve@navaho.co.uk Mon Feb  2 00:56:59 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 00:57:04 -0800 (PST)
Received: from pinus.navaho (fairchild-196.adsl.newnet.co.uk [213.131.187.196])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i128uu7J027083
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 00:56:57 -0800
Received: from 10.0.0.42 (steve@navaho.co.uk)
	by pinus.navaho with SMTP (Navaho Galium v3.8.1 [Linux/i686])
	id: 1075711409; Mon, 02 Feb 2004 08:56:45 GMT
X-Sender-Local: 10.0.0.42
Received: from sorbus2.navaho (localhost.localdomain [127.0.0.1])
	by sorbus2.navaho (8.12.10/8.12.10) with ESMTP id i128uj5G004118
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 08:56:45 GMT
Received: from localhost (steve@localhost)
	by sorbus2.navaho (8.12.10/8.12.10/Submit) with ESMTP id i128uj6m004114
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 08:56:45 GMT
X-Authentication-Warning: sorbus2.navaho: steve owned process doing -bs
Date: Mon, 2 Feb 2004 08:56:45 +0000 (GMT)
From: Steve Hill <steve@navaho.co.uk>
X-X-Sender: steve@sorbus2.navaho
To: netdev@oss.sgi.com
Subject: Conntrack leak (2.6.2rc2)
Message-ID: <Pine.LNX.4.58.0402020854160.4039@sorbus2.navaho>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Navaho-ID: 401e0db1
X-Domain-Forwarded-By: pinus.navaho
X-Navaho-Spam-Rating: 0.000000
X-Spam-Override: Local user [steve@navaho.co.uk]
X-Navaho-Spam: No
X-archive-position: 2934
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: steve@navaho.co.uk
Precedence: bulk
X-list: netdev
Content-Length: 1243
Lines: 29


I've already posted this to the netfilter-devel list and had no response 
so I'm hoping that some of you might have some insight into the problem:

I'm using the 2.6.2rc2 kernel and have a strange connection tracking 
problem - when using unfragmented packets every thing is fine - a new 
connection is made and init_conntrack() is called, and as the session is 
timed out by conntrack, destroy_conntrack() is called.  Absolutely fine.

However, if I start a connection with a fragmented packet (i.e. my MTU 
is 1500 bytes, so "ping -c 1 -s 2500 172.16.0.1" sends a packet consisting 
of 2 fragments), init_conntrack() is called as usual, but when the session 
is timed out destroy_conntrack() never gets called.  This means that the 
memory for the connection is never freed and ip_conntrack_count is never 
decremented.  However, the connection is still removed from the hash 
table.  This means that it leaks memory, and eventually reaches 
ip_conntrack_max and starts dropping new connections.

-- 

- Steve Hill
Senior Software Developer                        Email: steve@navaho.co.uk
Navaho Technologies Ltd.                           Tel: +44-870-7034015

        ... Alcohol and calculus don't mix - Don't drink and derive! ...





From steve@navaho.co.uk Mon Feb  2 01:46:30 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 01:46:35 -0800 (PST)
Received: from pinus.navaho (fairchild-196.adsl.newnet.co.uk [213.131.187.196])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i129kT7J028545
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 01:46:29 -0800
Received: from 10.0.0.42 (steve@navaho.co.uk)
	by pinus.navaho with SMTP (Navaho Galium v3.8.1 [Linux/i686])
	id: 1075711488; Mon, 02 Feb 2004 09:46:19 GMT
X-Sender-Local: 10.0.0.42
Received: from sorbus2.navaho (localhost.localdomain [127.0.0.1])
	by sorbus2.navaho (8.12.10/8.12.10) with ESMTP id i129kJ5G004331;
	Mon, 2 Feb 2004 09:46:19 GMT
Received: from localhost (steve@localhost)
	by sorbus2.navaho (8.12.10/8.12.10/Submit) with ESMTP id i129kJZZ004327;
	Mon, 2 Feb 2004 09:46:19 GMT
X-Authentication-Warning: sorbus2.navaho: steve owned process doing -bs
Date: Mon, 2 Feb 2004 09:46:19 +0000 (GMT)
From: Steve Hill <steve@navaho.co.uk>
X-X-Sender: steve@sorbus2.navaho
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
cc: netdev@oss.sgi.com
Subject: Re: Conntrack leak (2.6.2rc2)
In-Reply-To: <Pine.LNX.4.33.0402021016450.6508-100000@blackhole.kfki.hu>
Message-ID: <Pine.LNX.4.58.0402020937030.4127@sorbus2.navaho>
References: <Pine.LNX.4.33.0402021016450.6508-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Navaho-ID: 401e0df9
X-Domain-Forwarded-By: pinus.navaho
X-Navaho-Spam-Rating: 0.000000
X-Spam-Override: Local user [steve@navaho.co.uk]
X-Navaho-Spam: No
X-archive-position: 2935
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: steve@navaho.co.uk
Precedence: bulk
X-list: netdev
Content-Length: 1401
Lines: 29

On Mon, 2 Feb 2004, Jozsef Kadlecsik wrote:

> init_conntrack is called only when we have full, non-fragmented
> packets: ip_conntrack_in explicitly calls the proper function to gather
> the fragments before calling init_conntrack. There is no memory leak
> there.

From my observations, init_conntrack() is being called for each packet 
(not fragment, packet), which seems right.  destroy_conntrack() is, 
however, _not_ being called for any packets that are fragmented (i.e. it 
is not being called for the complete packet).  This is leading to the 
memory never being freed, and the conntrack count never being decremented 
even though the connection has been removed from the hash table.

There _is_ a memory leak here - it is observable and completely 
reproducable.  If I make a number of > MTU sized pings from a machine 
connected to one NIC to a machine connected another NIC (i.e. the packets 
will be fragmented), ip_conntrack_count grows until it reaches 
ip_conntrack_max, at which point it starts dropping new connections.  the 
ip_conntrack memory listed in /proc/slabinfo also grows.  Neither the 
memory or the connection count ever shrink again.

- Steve Hill
Senior Software Developer                        Email: steve@navaho.co.uk
Navaho Technologies Ltd.                           Tel: +44-870-7034015

        ... Alcohol and calculus don't mix - Don't drink and derive! ...



From kadlec@blackhole.kfki.hu Mon Feb  2 02:02:24 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 02:02:28 -0800 (PST)
Received: from blackhole.kfki.hu (blackhole.kfki.hu [148.6.0.114])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12A2D7J029750
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 02:02:13 -0800
Received: by blackhole.kfki.hu (Postfix, from userid 311)
	id DA2EE87B1; Mon,  2 Feb 2004 10:22:17 +0100 (CET)
Date: Mon, 2 Feb 2004 10:22:17 +0100 (CET)
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
To: Steve Hill <steve@navaho.co.uk>
Cc: <netdev@oss.sgi.com>
Subject: Re: Conntrack leak (2.6.2rc2)
In-Reply-To: <Pine.LNX.4.58.0402020854160.4039@sorbus2.navaho>
Message-ID: <Pine.LNX.4.33.0402021016450.6508-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 2936
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: kadlec@blackhole.kfki.hu
Precedence: bulk
X-list: netdev
Content-Length: 1088
Lines: 26

Hi Steve,

On Mon, 2 Feb 2004, Steve Hill wrote:

> However, if I start a connection with a fragmented packet (i.e. my MTU
> is 1500 bytes, so "ping -c 1 -s 2500 172.16.0.1" sends a packet consisting
> of 2 fragments), init_conntrack() is called as usual, but when the session
> is timed out destroy_conntrack() never gets called.  This means that the
> memory for the connection is never freed and ip_conntrack_count is never
> decremented.  However, the connection is still removed from the hash
> table.  This means that it leaks memory, and eventually reaches
> ip_conntrack_max and starts dropping new connections.

init_conntrack is called only when we have full, non-fragmented
packets: ip_conntrack_in explicitly calls the proper function to gather
the fragments before calling init_conntrack. There is no memory leak
there.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary


From steve@navaho.co.uk Mon Feb  2 02:48:20 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 02:48:23 -0800 (PST)
Received: from pinus.navaho (fairchild-196.adsl.newnet.co.uk [213.131.187.196])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12AmJ7J000501
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 02:48:19 -0800
Received: from 10.0.0.42 (steve@navaho.co.uk)
	by pinus.navaho with SMTP (Navaho Galium v3.8.1 [Linux/i686])
	id: 1075711579; Mon, 02 Feb 2004 10:48:08 GMT
X-Sender-Local: 10.0.0.42
Received: from sorbus2.navaho (localhost.localdomain [127.0.0.1])
	by sorbus2.navaho (8.12.10/8.12.10) with ESMTP id i12Am85G006201;
	Mon, 2 Feb 2004 10:48:08 GMT
Received: from localhost (steve@localhost)
	by sorbus2.navaho (8.12.10/8.12.10/Submit) with ESMTP id i12Am8Bh006197;
	Mon, 2 Feb 2004 10:48:08 GMT
X-Authentication-Warning: sorbus2.navaho: steve owned process doing -bs
Date: Mon, 2 Feb 2004 10:48:08 +0000 (GMT)
From: Steve Hill <steve@navaho.co.uk>
X-X-Sender: steve@sorbus2.navaho
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
cc: netdev@oss.sgi.com
Subject: Re: Conntrack leak (2.6.2rc2)
In-Reply-To: <Pine.LNX.4.33.0402021121540.6508-100000@blackhole.kfki.hu>
Message-ID: <Pine.LNX.4.58.0402021039540.5347@sorbus2.navaho>
References: <Pine.LNX.4.33.0402021121540.6508-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Navaho-ID: 401e0e40
X-Domain-Forwarded-By: pinus.navaho
X-Navaho-Spam-Rating: 0.000000
X-Spam-Override: Local user [steve@navaho.co.uk]
X-Navaho-Spam: No
X-archive-position: 2937
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: steve@navaho.co.uk
Precedence: bulk
X-list: netdev
Content-Length: 1986
Lines: 56

On Mon, 2 Feb 2004, Jozsef Kadlecsik wrote:

> > >From my observations, init_conntrack() is being called for each packet
> > (not fragment, packet), which seems right.
> 
> No, that's not true (and would be bad). Please check the code.

I have added to the top of init_conntrack():
    printk("Init conntrack\n");

Doing:
    ping -n 172.16.0.1 -c 1 -s 2500
through the machine now causes the kernel to output "Init conntrack", 
proving the function is being called.

> Yes, because fragmented packets does not lead to conntrack entries -
> there is nothing to be freed.

If fragmented packets do not lead to conntrack entries, how are their 
connections tracked?  I was under the impression that fragmented packets 
were received by one NIC, defragged, pushed through all the netfilter code 
and then transmitted by another NIC (after being fragmented again if they 
are > MTU size)?

> I could not reproduce it: test machine with 2.6.1 + patch-2.6.2-rc2,
> ip_conntrack_max lowered to 10. From another machine, in a loop, 400
> times:
> 
> ping -c 1 -s 2500 test-machine
> 
> No "ip_conntrack: table full, dropping packet" message on test-machine.
> No problem shown up in /proc/slabinfo either.

Just to confirm, you have your network set up like:

    [ Machine 1 ]----[ Machine 2 ]----[Machine 3]

Machines 1 and 3 are running the 2.4 kernel for me, but that shouldn't be 
important.
Machine 2 is running 2.6.2rc2.
I am making > MTU sized pings from machine 1 to machine 3 and machine 2 is 
showing the leak.

Pinging machine 2 from machine 1 does not show any such problems, I have 
not tried pinging from machine 2 itself.

I'm not sure if makes any difference, the NICs are eepro100's but I 
have also reproduced the problem on eepro1000's.

- Steve Hill
Senior Software Developer                        Email: steve@navaho.co.uk
Navaho Technologies Ltd.                           Tel: +44-870-7034015

        ... Alcohol and calculus don't mix - Don't drink and derive! ...



From kadlec@blackhole.kfki.hu Mon Feb  2 03:09:04 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 03:09:14 -0800 (PST)
Received: from blackhole.kfki.hu (blackhole.kfki.hu [148.6.0.114])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12B8q7J001704
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 03:08:53 -0800
Received: by blackhole.kfki.hu (Postfix, from userid 311)
	id 5C21387B1; Mon,  2 Feb 2004 11:34:22 +0100 (CET)
Date: Mon, 2 Feb 2004 11:34:22 +0100 (CET)
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
To: Steve Hill <steve@navaho.co.uk>
Cc: <netdev@oss.sgi.com>
Subject: Re: Conntrack leak (2.6.2rc2)
In-Reply-To: <Pine.LNX.4.58.0402020937030.4127@sorbus2.navaho>
Message-ID: <Pine.LNX.4.33.0402021121540.6508-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 2939
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: kadlec@blackhole.kfki.hu
Precedence: bulk
X-list: netdev
Content-Length: 1677
Lines: 43

On Mon, 2 Feb 2004, Steve Hill wrote:

> > init_conntrack is called only when we have full, non-fragmented
> > packets: ip_conntrack_in explicitly calls the proper function to gather
> > the fragments before calling init_conntrack. There is no memory leak
> > there.
>
> >From my observations, init_conntrack() is being called for each packet
> (not fragment, packet), which seems right.

No, that's not true (and would be bad). Please check the code.

> destroy_conntrack() is, however, _not_ being called for any packets
> that are fragmented

Yes, because fragmented packets does not lead to conntrack entries -
there is nothing to be freed.

> There _is_ a memory leak here - it is observable and completely
> reproducable.  If I make a number of > MTU sized pings from a machine
> connected to one NIC to a machine connected another NIC (i.e. the packets
> will be fragmented), ip_conntrack_count grows until it reaches
> ip_conntrack_max, at which point it starts dropping new connections.  the
> ip_conntrack memory listed in /proc/slabinfo also grows.  Neither the
> memory or the connection count ever shrink again.

I could not reproduce it: test machine with 2.6.1 + patch-2.6.2-rc2,
ip_conntrack_max lowered to 10. From another machine, in a loop, 400
times:

ping -c 1 -s 2500 test-machine

No "ip_conntrack: table full, dropping packet" message on test-machine.
No problem shown up in /proc/slabinfo either.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary


From kadlec@blackhole.kfki.hu Mon Feb  2 03:45:06 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 03:45:20 -0800 (PST)
Received: from blackhole.kfki.hu (blackhole.kfki.hu [148.6.0.114])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12Bj57J003004
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 03:45:05 -0800
Received: by blackhole.kfki.hu (Postfix, from userid 311)
	id 23CF087B1; Mon,  2 Feb 2004 12:45:04 +0100 (CET)
Date: Mon, 2 Feb 2004 12:45:04 +0100 (CET)
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
To: Steve Hill <steve@navaho.co.uk>
Cc: <netdev@oss.sgi.com>
Subject: Re: Conntrack leak (2.6.2rc2)
In-Reply-To: <Pine.LNX.4.58.0402021039540.5347@sorbus2.navaho>
Message-ID: <Pine.LNX.4.33.0402021154410.6508-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 2940
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: kadlec@blackhole.kfki.hu
Precedence: bulk
X-list: netdev
Content-Length: 2593
Lines: 75

On Mon, 2 Feb 2004, Steve Hill wrote:

> > > >From my observations, init_conntrack() is being called for each packet
> > > (not fragment, packet), which seems right.
> >
> > No, that's not true (and would be bad). Please check the code.
>
> I have added to the top of init_conntrack():
>     printk("Init conntrack\n");
>
> Doing:
>     ping -n 172.16.0.1 -c 1 -s 2500
> through the machine now causes the kernel to output "Init conntrack",
> proving the function is being called.

Yes, once, on the whole packet. Or do you see the message two times, when
issuing the ping command above once?

> > Yes, because fragmented packets does not lead to conntrack entries -
> > there is nothing to be freed.
>
> If fragmented packets do not lead to conntrack entries, how are their
> connections tracked?  I was under the impression that fragmented packets
> were received by one NIC, defragged, pushed through all the netfilter code
> and then transmitted by another NIC (after being fragmented again if they
> are > MTU size)?

You described exactly what happens: fragmented packets received, defragged
by the stack, and as we get the complete packet, then it handled by
conntrack.

> > I could not reproduce it: test machine with 2.6.1 + patch-2.6.2-rc2,
> > ip_conntrack_max lowered to 10. From another machine, in a loop, 400
> > times:
> >
> > ping -c 1 -s 2500 test-machine
> >
> > No "ip_conntrack: table full, dropping packet" message on test-machine.
> > No problem shown up in /proc/slabinfo either.
>
> Just to confirm, you have your network set up like:
>
>     [ Machine 1 ]----[ Machine 2 ]----[Machine 3]
>
>
> Machines 1 and 3 are running the 2.4 kernel for me, but that shouldn't be
> important.
> Machine 2 is running 2.6.2rc2.

I have only Machine 1 and Machine 2, but that should make no difference.

> I am making > MTU sized pings from machine 1 to machine 3 and machine 2 is
> showing the leak.
>
> Pinging machine 2 from machine 1 does not show any such problems.

That's really, really strange! Both for local and forwarded packets
ip_conntrack_in is called, which first checks the fragments and calls
defragging, when required. If there were a leak when pinging
machine 3, then there should be a leak when pinging machine 2 as well.

I'll setup an UML-net to test the forwarded case, but I expect negative
results.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary





From steve@navaho.co.uk Mon Feb  2 03:58:26 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 03:58:33 -0800 (PST)
Received: from pinus.navaho (fairchild-196.adsl.newnet.co.uk [213.131.187.196])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12BwN7J005523
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 03:58:25 -0800
Received: from 10.0.0.42 (steve@navaho.co.uk)
	by pinus.navaho with SMTP (Navaho Galium v3.8.1 [Linux/i686])
	id: 1075711715; Mon, 02 Feb 2004 11:58:14 GMT
X-Sender-Local: 10.0.0.42
Received: from sorbus2.navaho (localhost.localdomain [127.0.0.1])
	by sorbus2.navaho (8.12.10/8.12.10) with ESMTP id i12BwD5G006731;
	Mon, 2 Feb 2004 11:58:13 GMT
Received: from localhost (steve@localhost)
	by sorbus2.navaho (8.12.10/8.12.10/Submit) with ESMTP id i12BwDf2006727;
	Mon, 2 Feb 2004 11:58:13 GMT
X-Authentication-Warning: sorbus2.navaho: steve owned process doing -bs
Date: Mon, 2 Feb 2004 11:58:13 +0000 (GMT)
From: Steve Hill <steve@navaho.co.uk>
X-X-Sender: steve@sorbus2.navaho
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
cc: netdev@oss.sgi.com
Subject: Re: Conntrack leak (2.6.2rc2)
In-Reply-To: <Pine.LNX.4.33.0402021154410.6508-100000@blackhole.kfki.hu>
Message-ID: <Pine.LNX.4.58.0402021146370.5347@sorbus2.navaho>
References: <Pine.LNX.4.33.0402021154410.6508-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Navaho-ID: 401e0eb3
X-Domain-Forwarded-By: pinus.navaho
X-Navaho-Spam-Rating: 0.000000
X-Spam-Override: Local user [steve@navaho.co.uk]
X-Navaho-Spam: No
X-archive-position: 2942
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: steve@navaho.co.uk
Precedence: bulk
X-list: netdev
Content-Length: 2254
Lines: 53

On Mon, 2 Feb 2004, Jozsef Kadlecsik wrote:

> Yes, once, on the whole packet. Or do you see the message two times, when
> issuing the ping command above once?

No, only once for the whole packet (sorry, I think I didn't do a good job 
of describing the problem).
init_conntrack() always gets called once for the whole packet (this seems 
right to me).  However, destroy never gets called for the whole packet if 
the packet was fragmented, which seems to be  the source of the leak - 
init_conntrack was called and allocated for the whole packet but that 
memory is never freed again if the packet was fragmented.

I've added some debugging code into nf_conntrack_put() and it seems that 
if it's called on a packet that was fragmented, the usage count is > 1 so 
it never gets freed.  I'm not sure if anything is actually using the 
packet at that point though or if something has just forgotten to 
decrement the usage count though - in any case, it never gets called with 
a usage count <= 1.

> >     [ Machine 1 ]----[ Machine 2 ]----[Machine 3]
> >
> >
> > Machines 1 and 3 are running the 2.4 kernel for me, but that shouldn't be
> > important.
> > Machine 2 is running 2.6.2rc2.
> 
> I have only Machine 1 and Machine 2, but that should make no difference.

Pinging from machine 1 to machine 2 didn't cause any problem for me.  

I have just tried pinging from machine 2 to machine 1 (or 3) and this also 
isn't causing a problem.  The leak is only showing itself if the machine 
is routing packets from one network segment to another, not if the machine 
itself is the source or destination.

> I'll setup an UML-net to test the forwarded case, but I expect negative
> results.

Thanks - I'm doing my best to debug the problem, but I'm not at all 
familiar with the networking code so I'm having to start at the ground and 
work my way up (which is good since I don't have any preconceptions about 
that way it _should_ work, but bad in the fact I'm having to learn it all 
from scratch which takes time).


- Steve Hill
Senior Software Developer                        Email: steve@navaho.co.uk
Navaho Technologies Ltd.                           Tel: +44-870-7034015

        ... Alcohol and calculus don't mix - Don't drink and derive! ...



From kadlec@blackhole.kfki.hu Mon Feb  2 05:22:23 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 05:22:28 -0800 (PST)
Received: from blackhole.kfki.hu (blackhole.kfki.hu [148.6.0.114])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12DMC7J011640
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 05:22:13 -0800
Received: by blackhole.kfki.hu (Postfix, from userid 311)
	id F0F5087B1; Mon,  2 Feb 2004 13:47:56 +0100 (CET)
Date: Mon, 2 Feb 2004 13:47:56 +0100 (CET)
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
To: Steve Hill <steve@navaho.co.uk>
Cc: <netdev@oss.sgi.com>
Subject: Re: Conntrack leak (2.6.2rc2)
In-Reply-To: <Pine.LNX.4.58.0402021146370.5347@sorbus2.navaho>
Message-ID: <Pine.LNX.4.33.0402021316110.6508-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 2943
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: kadlec@blackhole.kfki.hu
Precedence: bulk
X-list: netdev
Content-Length: 1588
Lines: 39

On Mon, 2 Feb 2004, Steve Hill wrote:

> On Mon, 2 Feb 2004, Jozsef Kadlecsik wrote:
>
> > Yes, once, on the whole packet. Or do you see the message two times, when
> > issuing the ping command above once?
>
> No, only once for the whole packet (sorry, I think I didn't do a good job
> of describing the problem).
> init_conntrack() always gets called once for the whole packet (this seems
> right to me).  However, destroy never gets called for the whole packet if
> the packet was fragmented, which seems to be  the source of the leak -
> init_conntrack was called and allocated for the whole packet but that
> memory is never freed again if the packet was fragmented.

To be precise, the destroy function is not called whenever a packet leaves
the system: it gets called, when conntrack thinks the connection is
completed. It can happen when whe explicitly know from the packet that it
finishes the connection (ICMP reply for ICMP non-error messages, and a
special case for TCP RST), or when the timer of the conntrack entry goes
off.

So the destroy function is called when the system sees the ICMP reply
packet from machine 3 (and there were so many request as reply packets so
far) - otherwise it'll simply time out the connection.

Machine 3 answers the ping requests, doesn't it? You ping the same IP
address all the time?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary




From steve@navaho.co.uk Mon Feb  2 05:49:47 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 05:49:52 -0800 (PST)
Received: from pinus.navaho (fairchild-196.adsl.newnet.co.uk [213.131.187.196])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12Dnh7J012669
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 05:49:44 -0800
Received: from 10.0.0.42 (steve@navaho.co.uk)
	by pinus.navaho with SMTP (Navaho Galium v3.8.1 [Linux/i686])
	id: 1075711871; Mon, 02 Feb 2004 13:36:07 GMT
X-Sender-Local: 10.0.0.42
Received: from sorbus2.navaho (localhost.localdomain [127.0.0.1])
	by sorbus2.navaho (8.12.10/8.12.10) with ESMTP id i12Da75G006773;
	Mon, 2 Feb 2004 13:36:07 GMT
Received: from localhost (steve@localhost)
	by sorbus2.navaho (8.12.10/8.12.10/Submit) with ESMTP id i12Da7KB006769;
	Mon, 2 Feb 2004 13:36:07 GMT
X-Authentication-Warning: sorbus2.navaho: steve owned process doing -bs
Date: Mon, 2 Feb 2004 13:36:07 +0000 (GMT)
From: Steve Hill <steve@navaho.co.uk>
X-X-Sender: steve@sorbus2.navaho
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
cc: netdev@oss.sgi.com
Subject: Re: Conntrack leak (2.6.2rc2)
In-Reply-To: <Pine.LNX.4.33.0402021316110.6508-100000@blackhole.kfki.hu>
Message-ID: <Pine.LNX.4.58.0402021319440.5347@sorbus2.navaho>
References: <Pine.LNX.4.33.0402021316110.6508-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Navaho-ID: 401e0f36
X-Domain-Forwarded-By: pinus.navaho
X-Navaho-Spam-Rating: 0.000000
X-Spam-Override: Local user [steve@navaho.co.uk]
X-Navaho-Spam: No
X-archive-position: 2944
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: steve@navaho.co.uk
Precedence: bulk
X-list: netdev
Content-Length: 3206
Lines: 90

On Mon, 2 Feb 2004, Jozsef Kadlecsik wrote:

> To be precise, the destroy function is not called whenever a packet leaves
> the system: it gets called, when conntrack thinks the connection is
> completed. It can happen when whe explicitly know from the packet that it
> finishes the connection (ICMP reply for ICMP non-error messages, and a
> special case for TCP RST), or when the timer of the conntrack entry goes
> off.
> 
> So the destroy function is called when the system sees the ICMP reply
> packet from machine 3 (and there were so many request as reply packets so
> far) - otherwise it'll simply time out the connection.

Yes, this makes sense.  The fact that the connection is removed from the 
hash table indicates that conntrack thinks the connection has gone, but 
the destroy function was never called.  (The connection nolonger appears 
in /proc/net/ip_conntrack).

I turned on the debugging code and got:

----
ip_conntrack_in: new packet for ce8fae40
Altering reply tuple of ce8fae40 to tuple c0357de4: 1 172.16.0.1:5438 -> 
172.17.0.1:0
Altering reply tuple of ce8fae40 to tuple c0357cdc: 1 172.16.0.1:5438 -> 
172.17.0.1:0
Confirming conntrack ce8fae40
conntrack_put ce8faebc 4
conntrack_put ce8faebc 3
clean_from_lists(ce8fae40)
remove_expectations(ce8fae40)
conntrack_put ce8faeb4 3
conntrack_put ce8faec0 4
conntrack_put ce8faec0 3
----

(the conntrack_put debugging was added by me to the nf_conntrack_put() 
function - it shows the pointer to nfct and the usage count).

If it send a small packet through, which won't be fragmented I get:

----
ip_conntrack_in: new packet for ce8fa080
Altering reply tuple of ce8fa080 to tuple c0357de4: 1 172.16.0.1:39486 -> 
172.17.0.1:0
Altering reply tuple of ce8fa080 to tuple c0357d20: 1 172.16.0.1:39486 -> 
172.17.0.1:0
Confirming conntrack ce8fa080
conntrack_put ce8fa0fc 2
clean_from_lists(ce8fa080)
remove_expectations(ce8fa080)
conntrack_put ce8fa0f4 2
conntrack_put ce8fa100 1
destroy_conntrack(ce8fa080)
destroy_conntrack: returning ct=ce8fa080 to slab
----

As you can see, in both cases everything happens in a similar way, except 
when dealing with fragmented packets the usage count is > 1 when 
conntrack_put is called.  Nomatter how long it is left idle, conntrack_put 
is never called again for the packet, so the memory never gets freed.  
However, in both cases the connection is removed from the hash table.

> Machine 3 answers the ping requests, doesn't it? You ping the same IP
> address all the time?

Yes, the machine always responds to the pings and I'm always using the 
same addresses.  My setup is as follows:

[ Machine 1 ]
     | 172.17.0.1/24
     |
     | 172.17.0.254/24
[ Machine 2 ]
     | 172.16.0.254/24
     |
     | 172.16.0.1/24
[ Machine 3 ]

I am consistently testing by making pings from machine 1 to machine 3 - 
machine 3 always responds and there is no other routing in place, so both 
the echo request and the echo reply are being routed through machine 2..

- Steve Hill
Senior Software Developer                        Email: steve@navaho.co.uk
Navaho Technologies Ltd.                           Tel: +44-870-7034015

        ... Alcohol and calculus don't mix - Don't drink and derive! ...



From steve@navaho.co.uk Mon Feb  2 06:03:54 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 06:03:57 -0800 (PST)
Received: from pinus.navaho (fairchild-196.adsl.newnet.co.uk [213.131.187.196])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12E3p7J013375
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 06:03:52 -0800
Received: from 10.0.0.42 (steve@navaho.co.uk)
	by pinus.navaho with SMTP (Navaho Galium v3.8.1 [Linux/i686])
	id: 1075711917; Mon, 02 Feb 2004 14:03:40 GMT
X-Sender-Local: 10.0.0.42
Received: from sorbus2.navaho (localhost.localdomain [127.0.0.1])
	by sorbus2.navaho (8.12.10/8.12.10) with ESMTP id i12E3e5G006876;
	Mon, 2 Feb 2004 14:03:40 GMT
Received: from localhost (steve@localhost)
	by sorbus2.navaho (8.12.10/8.12.10/Submit) with ESMTP id i12E3eeg006872;
	Mon, 2 Feb 2004 14:03:40 GMT
X-Authentication-Warning: sorbus2.navaho: steve owned process doing -bs
Date: Mon, 2 Feb 2004 14:03:40 +0000 (GMT)
From: Steve Hill <steve@navaho.co.uk>
X-X-Sender: steve@sorbus2.navaho
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
cc: netdev@oss.sgi.com
Subject: Re: Conntrack leak (2.6.2rc2)
In-Reply-To: <Pine.LNX.4.33.0402021443570.6508-100000@blackhole.kfki.hu>
Message-ID: <Pine.LNX.4.58.0402021400210.5347@sorbus2.navaho>
References: <Pine.LNX.4.33.0402021443570.6508-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Navaho-ID: 401e0f60
X-Domain-Forwarded-By: pinus.navaho
X-Navaho-Spam-Rating: 0.000000
X-Spam-Override: Local user [steve@navaho.co.uk]
X-Navaho-Spam: No
X-archive-position: 2945
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: steve@navaho.co.uk
Precedence: bulk
X-list: netdev
Content-Length: 479
Lines: 16

On Mon, 2 Feb 2004, Jozsef Kadlecsik wrote:

> You convinced me: something is really fishy. I fire up debugging and
> checking.

:)
I'm just investigating the usage count ATM to see if I can work out what 
is (claiming to be) using the data.

- Steve Hill
Senior Software Developer                        Email: steve@navaho.co.uk
Navaho Technologies Ltd.                           Tel: +44-870-7034015

        ... Alcohol and calculus don't mix - Don't drink and derive! ...



From kadlec@blackhole.kfki.hu Mon Feb  2 06:29:03 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 06:29:07 -0800 (PST)
Received: from blackhole.kfki.hu (blackhole.kfki.hu [148.6.0.114])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12ESq7J014462
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 06:28:53 -0800
Received: by blackhole.kfki.hu (Postfix, from userid 311)
	id 62B8487B1; Mon,  2 Feb 2004 14:46:24 +0100 (CET)
Date: Mon, 2 Feb 2004 14:46:24 +0100 (CET)
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
To: Steve Hill <steve@navaho.co.uk>
Cc: <netdev@oss.sgi.com>
Subject: Re: Conntrack leak (2.6.2rc2)
In-Reply-To: <Pine.LNX.4.58.0402021319440.5347@sorbus2.navaho>
Message-ID: <Pine.LNX.4.33.0402021443570.6508-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 2946
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: kadlec@blackhole.kfki.hu
Precedence: bulk
X-list: netdev
Content-Length: 1590
Lines: 52

On Mon, 2 Feb 2004, Steve Hill wrote:

> I turned on the debugging code and got:
>
> ----
> ip_conntrack_in: new packet for ce8fae40
> Altering reply tuple of ce8fae40 to tuple c0357de4: 1 172.16.0.1:5438 ->
> 172.17.0.1:0
> Altering reply tuple of ce8fae40 to tuple c0357cdc: 1 172.16.0.1:5438 ->
> 172.17.0.1:0
> Confirming conntrack ce8fae40
> conntrack_put ce8faebc 4
> conntrack_put ce8faebc 3
> clean_from_lists(ce8fae40)
> remove_expectations(ce8fae40)
> conntrack_put ce8faeb4 3
> conntrack_put ce8faec0 4
> conntrack_put ce8faec0 3
> ----
>
> (the conntrack_put debugging was added by me to the nf_conntrack_put()
> function - it shows the pointer to nfct and the usage count).
>
> If it send a small packet through, which won't be fragmented I get:
>
> ----
> ip_conntrack_in: new packet for ce8fa080
> Altering reply tuple of ce8fa080 to tuple c0357de4: 1 172.16.0.1:39486 ->
> 172.17.0.1:0
> Altering reply tuple of ce8fa080 to tuple c0357d20: 1 172.16.0.1:39486 ->
> 172.17.0.1:0
> Confirming conntrack ce8fa080
> conntrack_put ce8fa0fc 2
> clean_from_lists(ce8fa080)
> remove_expectations(ce8fa080)
> conntrack_put ce8fa0f4 2
> conntrack_put ce8fa100 1
> destroy_conntrack(ce8fa080)
> destroy_conntrack: returning ct=ce8fa080 to slab
> ----

You convinced me: something is really fishy. I fire up debugging and
checking.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary


From yoshfuji@wide.ad.jp Mon Feb  2 09:06:55 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 09:07:01 -0800 (PST)
Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12H6s7J022376
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 09:06:55 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 010F933CA5; Tue,  3 Feb 2004 02:07:41 +0900 (JST)
Date: Tue, 03 Feb 2004 02:07:41 +0900 (JST)
Message-Id: <20040203.020741.105137354.yoshfuji@wide.ad.jp>
To: davem@redhat.com
Cc: netdev@oss.sgi.com, yoshfuji@wide.ad.jp
Subject: [PATCH] IPV6: fix checking for reserved subnet anycast
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@wide.ad.jp>
Organization: USAGI Project
X-URL: http://www.yoshifuji.org/%7Ehideaki/
X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc
X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU]
 $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEa<!5P`&C$@oP>ZBLP
X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-archive-position: 2947
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: yoshfuji@wide.ad.jp
Precedence: bulk
X-list: netdev
Content-Length: 926
Lines: 23

Reserved subnet anycast is as follows:
   11111101 11....11 1xxxxxxx
The code checking for reserved subnet anycast in 
__ipv6_regen_rndid() was incorrect.

D: fix checking for reserved subnet anycast in __ipv6_regen_rndid().

===== net/ipv6/addrconf.c 1.90 vs edited =====
--- 1.90/net/ipv6/addrconf.c	Sun Jan 25 03:09:52 2004
+++ edited/net/ipv6/addrconf.c	Tue Feb  3 01:39:19 2004
@@ -1147,7 +1147,7 @@
 	 *  - XXX: already assigned to an address on the device
 	 */
 	if (idev->rndid[0] == 0xfd && 
-	    (idev->rndid[1]&idev->rndid[2]&idev->rndid[3]&idev->rndid[4]&idev->rndid[5]&idev->rndid[6]) &&
+	    (idev->rndid[1]&idev->rndid[2]&idev->rndid[3]&idev->rndid[4]&idev->rndid[5]&idev->rndid[6]) == 0xff &&
 	    (idev->rndid[7]&0x80))
 		goto regen;
 	if ((idev->rndid[0]|idev->rndid[1]) == 0) {

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

From davem@redhat.com Mon Feb  2 10:36:54 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 10:36:57 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12Iar7J028587
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 10:36:53 -0800
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i12Iaob29498;
	Mon, 2 Feb 2004 13:36:50 -0500
Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i12Iaoa10214;
	Mon, 2 Feb 2004 13:36:50 -0500
Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1])
	by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i12IaLkC002313;
	Mon, 2 Feb 2004 13:36:21 -0500
Date: Mon, 2 Feb 2004 10:36:49 -0800
From: "David S. Miller" <davem@redhat.com>
To: yoshfuji@wide.ad.jp
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH] IPV6: fix checking for reserved subnet anycast
Message-Id: <20040202103649.32e4a9b2.davem@redhat.com>
In-Reply-To: <20040203.020741.105137354.yoshfuji@wide.ad.jp>
References: <20040203.020741.105137354.yoshfuji@wide.ad.jp>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu)
X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i12Iar7J028587
X-archive-position: 2948
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: davem@redhat.com
Precedence: bulk
X-list: netdev
Content-Length: 362
Lines: 12

On Tue, 03 Feb 2004 02:07:41 +0900 (JST)
YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@wide.ad.jp> wrote:

> Reserved subnet anycast is as follows:
>    11111101 11....11 1xxxxxxx
> The code checking for reserved subnet anycast in 
> __ipv6_regen_rndid() was incorrect.
> 
> D: fix checking for reserved subnet anycast in __ipv6_regen_rndid().

Applied, thanks.


From dwmw2@infradead.org Mon Feb  2 10:43:06 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 10:43:09 -0800 (PST)
Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.86.99.235])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12Ih57J029392
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 10:43:06 -0800
Received: from [213.86.99.237] (helo=[172.16.18.64])
	by pentafluge.infradead.org with asmtp (Exim 4.30 #5 (Red Hat Linux))
	id 1Anj2G-0001nF-3Z; Mon, 02 Feb 2004 18:43:04 +0000
Subject: SCTP sockopt discrepancy between 2.4 and 2.6.
From: David Woodhouse <dwmw2@infradead.org>
To: netdev@oss.sgi.com, marcelo.tosatti@cyclades.com
Cc: lksctp-developers@lists.sourceforge.net
Content-Type: text/plain
Message-Id: <1075747382.786.366.camel@hades.cambridge.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-8.dwmw2.2) 
Date: Mon, 02 Feb 2004 18:43:03 +0000
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-archive-position: 2949
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: dwmw2@infradead.org
Precedence: bulk
X-list: netdev
Content-Length: 545
Lines: 15

The 2.4 and 2.6 SCTP code have _different_ values for the SCTP_*
sockopts. The 2.4 version claims to implement
draft-ietf-tsvwg-sctpsocket-04.txt while the 2.6 version implements
draft-ietf-tsvwg-sctpsocket-07.txt.

This means that tools compiled with the current libraries and header
files cannot work on the 2.4 kernel.

Am I missing something -- like perhaps the existence of a patch to
update the 2.4 kernel -- or is the SCTP implementation in 2.4 no longer
being maintained, and no longer compatible with 2.6 and its userspace?

-- 
dwmw2


From davem@redhat.com Mon Feb  2 11:03:46 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 11:03:50 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12J3k7J030302
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 11:03:46 -0800
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i12J3gb13652;
	Mon, 2 Feb 2004 14:03:42 -0500
Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i12J3fa21266;
	Mon, 2 Feb 2004 14:03:41 -0500
Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1])
	by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i12J3CkC017713;
	Mon, 2 Feb 2004 14:03:12 -0500
Date: Mon, 2 Feb 2004 11:03:40 -0800
From: "David S. Miller" <davem@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: netdev@oss.sgi.com, marcelo.tosatti@cyclades.com,
        lksctp-developers@lists.sourceforge.net
Subject: Re: SCTP sockopt discrepancy between 2.4 and 2.6.
Message-Id: <20040202110340.3f4cdabd.davem@redhat.com>
In-Reply-To: <1075747382.786.366.camel@hades.cambridge.redhat.com>
References: <1075747382.786.366.camel@hades.cambridge.redhat.com>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu)
X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 2950
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: davem@redhat.com
Precedence: bulk
X-list: netdev
Content-Length: 525
Lines: 12

On Mon, 02 Feb 2004 18:43:03 +0000
David Woodhouse <dwmw2@infradead.org> wrote:

> Am I missing something -- like perhaps the existence of a patch to
> update the 2.4 kernel -- or is the SCTP implementation in 2.4 no longer
> being maintained, and no longer compatible with 2.6 and its userspace?

Good catch David, this does need to be synchronized and fixed.

I believe the 2.4.x SCTP code was a port of some older 2.6.x incantation
and then the 2.6.x line kept being updated yet such updates never were
merged 2.4.x'ward.

From sri@us.ibm.com Mon Feb  2 11:11:59 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 11:12:03 -0800 (PST)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12JBw7J030865
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 11:11:59 -0800
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i12J9O2a378768;
	Mon, 2 Feb 2004 14:09:24 -0500
Received: from w-sridhar.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i12J9MYQ110434;
	Mon, 2 Feb 2004 14:09:23 -0500
Date: Mon, 2 Feb 2004 11:09:21 -0800 (PST)
From: Sridhar Samudrala <sri@us.ibm.com>
X-X-Sender: sridhar@localhost.localdomain
To: David Woodhouse <dwmw2@infradead.org>
cc: netdev@oss.sgi.com, marcelo.tosatti@cyclades.com,
        lksctp-developers@lists.sourceforge.net
Subject: Re: SCTP sockopt discrepancy between 2.4 and 2.6.
In-Reply-To: <1075747382.786.366.camel@hades.cambridge.redhat.com>
Message-ID: <Pine.LNX.4.58.0402021056290.2352@localhost.localdomain>
References: <1075747382.786.366.camel@hades.cambridge.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 2951
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: sri@us.ibm.com
Precedence: bulk
X-list: netdev
Content-Length: 1221
Lines: 31

On Mon, 2 Feb 2004, David Woodhouse wrote:

> The 2.4 and 2.6 SCTP code have _different_ values for the SCTP_*
> sockopts. The 2.4 version claims to implement
> draft-ietf-tsvwg-sctpsocket-04.txt while the 2.6 version implements
> draft-ietf-tsvwg-sctpsocket-07.txt.

I think 2.4 lksctp is compatible with draft-iets-tsvwg-sctpsocket-06.txt.

>
> This means that tools compiled with the current libraries and header
> files cannot work on the 2.4 kernel.

Right. The latest lksctp-tools(lksctp-tools-2.6.0-test7-0.7.4) will not work
with 2.4. An earlier version(lksctp-tools-2_5_67-0_6_9) may work with 2.4.

>
> Am I missing something -- like perhaps the existence of a patch to
> update the 2.4 kernel -- or is the SCTP implementation in 2.4 no longer
> being maintained, and no longer compatible with 2.6 and its userspace?

2.4 lksctp implementation is a backport from 2.6(the backport originally was
done from 2.5.69). The backport process should have continued and kept up with
the 2.6 changes. But due to resource problems, it is not happening.
2.6 lksctp is under active development and is compatible with the latest
SCTP sockets api draft(ver 07).

Are you interested in a 2.4 version of lksctp?

Thanks
Sridhar

From davem@redhat.com Mon Feb  2 11:21:56 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 11:21:58 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12JLt7J031587
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 11:21:55 -0800
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i12JLqb24766;
	Mon, 2 Feb 2004 14:21:52 -0500
Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i12JLqa29048;
	Mon, 2 Feb 2004 14:21:52 -0500
Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1])
	by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i12JLMkC026813;
	Mon, 2 Feb 2004 14:21:23 -0500
Date: Mon, 2 Feb 2004 11:21:50 -0800
From: "David S. Miller" <davem@redhat.com>
To: Sridhar Samudrala <sri@us.ibm.com>
Cc: dwmw2@infradead.org, netdev@oss.sgi.com, marcelo.tosatti@cyclades.com,
        lksctp-developers@lists.sourceforge.net
Subject: Re: SCTP sockopt discrepancy between 2.4 and 2.6.
Message-Id: <20040202112150.3c8d5218.davem@redhat.com>
In-Reply-To: <Pine.LNX.4.58.0402021056290.2352@localhost.localdomain>
References: <1075747382.786.366.camel@hades.cambridge.redhat.com>
	<Pine.LNX.4.58.0402021056290.2352@localhost.localdomain>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu)
X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 2952
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: davem@redhat.com
Precedence: bulk
X-list: netdev
Content-Length: 273
Lines: 8


I appreciate your status report Sridhar, thank you.

But the fact of the matter is that 2.4.x and 2.6.x cannot export two
totally incompatible user visible APIs for the SCTP socket layer.

This is something which must be fixed, not something we would like to
be fixed :-)

From scott.feldman@intel.com Mon Feb  2 13:25:46 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 13:25:49 -0800 (PST)
Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12LPj7J007186
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 13:25:45 -0800
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37])
	by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i12LRIq5026326;
	Mon, 2 Feb 2004 21:27:18 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124])
	by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i12LRPJw009606;
	Mon, 2 Feb 2004 21:27:25 GMT
Received: from [134.134.3.50] ([134.134.3.50])
 by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020213253918423
 ; Mon, 02 Feb 2004 13:25:39 -0800
Date: Mon, 2 Feb 2004 14:01:40 -0800 (PST)
From: "Feldman, Scott" <scott.feldman@intel.com>
X-X-Sender: scott.feldman@localhost.localdomain
Reply-To: "Feldman, Scott" <scott.feldman@intel.com>
To: Jeff Garzik <jgarzik@pobox.com>
cc: netdev@oss.sgi.com, "Feldman, Scott" <scott.feldman@intel.com>
Subject: [e1000 netdev-2.6 3/6] Serial-over-LAN (SoL) fix
Message-ID: <Pine.LNX.4.44.0402021346140.6288-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-archive-position: 2955
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: scott.feldman@intel.com
Precedence: bulk
X-list: netdev
Content-Length: 1113
Lines: 31


* Set VLAN filtering to IEEE 802.1Q after reset so we don't
  break Serial-over-LAN (SoL) connections that use VLANs.

-----------------

diff -Naurp netdev-2.6/drivers/net/e1000/e1000_main.c netdev-2.6/drivers/net/e1000.mod/e1000_main.c
--- netdev-2.6/drivers/net/e1000/e1000_main.c	2004-02-02 12:08:24.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000_main.c	2004-02-02 12:09:00.000000000 -0800
@@ -339,6 +339,10 @@ e1000_reset(struct e1000_adapter *adapte
 	if(adapter->hw.mac_type >= e1000_82544)
 		E1000_WRITE_REG(&adapter->hw, WUC, 0);
 	e1000_init_hw(&adapter->hw);
+
+	/* Enable h/w to recognize an 802.1Q VLAN Ethernet packet */
+	E1000_WRITE_REG(&adapter->hw, VET, ETHERNET_IEEE_VLAN_TYPE);
+
 	e1000_reset_adaptive(&adapter->hw);
 	e1000_phy_get_info(&adapter->hw, &adapter->phy_info);
 }
@@ -2666,8 +2670,6 @@ e1000_vlan_rx_register(struct net_device
 	if(grp) {
 		/* enable VLAN tag insert/strip */
 
-		E1000_WRITE_REG(&adapter->hw, VET, ETHERNET_IEEE_VLAN_TYPE);
-
 		ctrl = E1000_READ_REG(&adapter->hw, CTRL);
 		ctrl |= E1000_CTRL_VME;
 		E1000_WRITE_REG(&adapter->hw, CTRL, ctrl);



From scott.feldman@intel.com Mon Feb  2 13:25:55 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 13:25:59 -0800 (PST)
Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12LPs7J007205
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 13:25:55 -0800
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37])
	by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i12LNKC6025261;
	Mon, 2 Feb 2004 21:23:20 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128])
	by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i12LRXJw009703;
	Mon, 2 Feb 2004 21:27:33 GMT
Received: from [134.134.3.50] ([134.134.3.50])
 by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020213254707513
 ; Mon, 02 Feb 2004 13:25:47 -0800
Date: Mon, 2 Feb 2004 14:01:49 -0800 (PST)
From: "Feldman, Scott" <scott.feldman@intel.com>
X-X-Sender: scott.feldman@localhost.localdomain
Reply-To: "Feldman, Scott" <scott.feldman@intel.com>
To: Jeff Garzik <jgarzik@pobox.com>
cc: netdev@oss.sgi.com, "Feldman, Scott" <scott.feldman@intel.com>
Subject: [e1000 netdev-2.6 4/6] 82547 interrupt assert/de-assert re-ordering
Message-ID: <Pine.LNX.4.44.0402021348160.6288-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-archive-position: 2956
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: scott.feldman@intel.com
Precedence: bulk
X-list: netdev
Content-Length: 1684
Lines: 44


* 82547 needs interrupt disable/enable to keep interrupt assertion
  state synced between 82547 and APIC.  82547 will re-order
  assert and de-assert messages if hub link bus is busy (heavy
  traffic).  Disabling interrupt on device works around re-
  order issue.  Note: this is a re-patch.  We backed out the
  patch because of a report on a system with a 8086:1019 device
  would lock up with this patch.  Turns out that system was a
  pre-production sample.

-----------

diff -Naurp netdev-2.6/drivers/net/e1000/e1000_main.c netdev-2.6/drivers/net/e1000.mod/e1000_main.c
--- netdev-2.6/drivers/net/e1000/e1000_main.c	2004-02-02 12:09:08.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000_main.c	2004-02-02 12:10:43.000000000 -0800
@@ -2119,10 +2119,26 @@ e1000_intr(int irq, void *data, struct p
 		__netif_rx_schedule(netdev);
 	}
 #else
+        /* Writing IMC and IMS is needed for 82547.
+	   Due to Hub Link bus being occupied, an interrupt 
+	   de-assertion message is not able to be sent. 
+	   When an interrupt assertion message is generated later,
+	   two messages are re-ordered and sent out.
+	   That causes APIC to think 82547 is in de-assertion
+	   state, while 82547 is in assertion state, resulting 
+	   in dead lock. Writing IMC forces 82547 into 
+	   de-assertion state.
+        */
+	if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2)
+		e1000_irq_disable(adapter);
+
 	for(i = 0; i < E1000_MAX_INTR; i++)
 		if(!e1000_clean_rx_irq(adapter) &
 		   !e1000_clean_tx_irq(adapter))
 			break;
+
+	if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2)
+		e1000_irq_enable(adapter);
 #endif
 
 	return IRQ_HANDLED;



From scott.feldman@intel.com Mon Feb  2 13:26:13 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 13:26:16 -0800 (PST)
Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12LQA7J007333
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 13:26:12 -0800
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37])
	by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i12LRhq5026586;
	Mon, 2 Feb 2004 21:27:43 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128])
	by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i12LRoJw009885;
	Mon, 2 Feb 2004 21:27:50 GMT
Received: from [134.134.3.50] ([134.134.3.50])
 by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020213260407537
 ; Mon, 02 Feb 2004 13:26:04 -0800
Date: Mon, 2 Feb 2004 14:02:06 -0800 (PST)
From: "Feldman, Scott" <scott.feldman@intel.com>
X-X-Sender: scott.feldman@localhost.localdomain
Reply-To: "Feldman, Scott" <scott.feldman@intel.com>
To: Jeff Garzik <jgarzik@pobox.com>
cc: netdev@oss.sgi.com, "Feldman, Scott" <scott.feldman@intel.com>
Subject: [e1000 netdev-2.6 5/6] Allow 1000/Full setting for Autoneg param
Message-ID: <Pine.LNX.4.44.0402021357230.6288-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-archive-position: 2958
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: scott.feldman@intel.com
Precedence: bulk
X-list: netdev
Content-Length: 877
Lines: 24


* Allow 1000/Full setting for AutoNeg param for Fiber connections.
  Jon D Mason [jonmason@us.ibm.com].

------------

diff -Naurp netdev-2.6/drivers/net/e1000/e1000_param.c netdev-2.6/drivers/net/e1000.mod/e1000_param.c
--- netdev-2.6/drivers/net/e1000/e1000_param.c	2004-02-02 12:10:53.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000_param.c	2004-02-02 12:11:26.000000000 -0800
@@ -489,9 +489,9 @@ e1000_check_fiber_options(struct e1000_a
 		printk(KERN_INFO "Duplex not valid for fiber adapters, "
 		       "parameter ignored\n");
 	}
-	if((AutoNeg[bd] != OPTION_UNSET)) {
-		printk(KERN_INFO "AutoNeg not valid for fiber adapters, "
-		       "parameter ignored\n");
+	if((AutoNeg[bd] != OPTION_UNSET) && (AutoNeg[bd] != 0x20)) {
+		printk(KERN_INFO "AutoNeg other than Full/1000 is "
+		       "not valid for fiber adapters, parameter ignored\n");
 	}
 }
 



From scott.feldman@intel.com Mon Feb  2 13:25:45 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 13:25:49 -0800 (PST)
Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12LPg7J007185
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 13:25:45 -0800
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37])
	by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i12LN5C6025052;
	Mon, 2 Feb 2004 21:23:05 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128])
	by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i12LRGK0009501;
	Mon, 2 Feb 2004 21:27:17 GMT
Received: from [134.134.3.50] ([134.134.3.50])
 by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020213253107482
 ; Mon, 02 Feb 2004 13:25:31 -0800
Date: Mon, 2 Feb 2004 14:01:32 -0800 (PST)
From: "Feldman, Scott" <scott.feldman@intel.com>
X-X-Sender: scott.feldman@localhost.localdomain
Reply-To: "Feldman, Scott" <scott.feldman@intel.com>
To: Jeff Garzik <jgarzik@pobox.com>
cc: netdev@oss.sgi.com, "Feldman, Scott" <scott.feldman@intel.com>
Subject: [e1000 netdev-2.6 2/6] tx_lock
Message-ID: <Pine.LNX.4.44.0402021340570.6288-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-archive-position: 2954
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: scott.feldman@intel.com
Precedence: bulk
X-list: netdev
Content-Length: 2838
Lines: 92


* Fix race in Tx performance path with tx_lock.  Between checking
  if we're out of resources and stopping the queue, we can get
  a hard interrupt which will clean up all Tx work, and wake
  the queue.  Coming out of hard interrupt context, we stop the
  queue even though no work was queued, and all work completed
  has been cleaned up.  Scenario requires ring to be completely
  filled, which is more likely to happen with TSO, since each
  TSO send consumes multiple ring entries.

--------------

diff -Naurp netdev-2.6/drivers/net/e1000/e1000.h netdev-2.6/drivers/net/e1000.mod/e1000.h
--- netdev-2.6/drivers/net/e1000/e1000.h	2004-02-02 12:07:15.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000.h	2004-02-02 12:07:29.000000000 -0800
@@ -202,6 +202,7 @@ struct e1000_adapter {
 
 	/* TX */
 	struct e1000_desc_ring tx_ring;
+	spinlock_t tx_lock;
 	uint32_t txd_cmd;
 	uint32_t tx_int_delay;
 	uint32_t tx_abs_int_delay;
diff -Naurp netdev-2.6/drivers/net/e1000/e1000_main.c netdev-2.6/drivers/net/e1000.mod/e1000_main.c
--- netdev-2.6/drivers/net/e1000/e1000_main.c	2004-02-02 12:07:15.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000_main.c	2004-02-02 12:08:10.000000000 -0800
@@ -674,6 +674,7 @@ e1000_sw_init(struct e1000_adapter *adap
 
 	atomic_set(&adapter->irq_sem, 1);
 	spin_lock_init(&adapter->stats_lock);
+	spin_lock_init(&adapter->tx_lock);
 
 	return 0;
 }
@@ -1772,6 +1773,7 @@ e1000_xmit_frame(struct sk_buff *skb, st
 	struct e1000_adapter *adapter = netdev->priv;
 	unsigned int first;
 	unsigned int tx_flags = 0;
+	unsigned long flags;
 	int count;
 
 	if(skb->len <= 0) {
@@ -1779,10 +1781,13 @@ e1000_xmit_frame(struct sk_buff *skb, st
 		return 0;
 	}
 
+	spin_lock_irqsave(&adapter->tx_lock, flags);
+
 	if(adapter->hw.mac_type == e1000_82547) {
 		if(e1000_82547_fifo_workaround(adapter, skb)) {
 			netif_stop_queue(netdev);
 			mod_timer(&adapter->tx_fifo_stall_timer, jiffies);
+			spin_unlock_irqrestore(&adapter->tx_lock, flags);
 			return 1;
 		}
 	}
@@ -1803,11 +1808,14 @@ e1000_xmit_frame(struct sk_buff *skb, st
 		e1000_tx_queue(adapter, count, tx_flags);
 	else {
 		netif_stop_queue(netdev);
+		spin_unlock_irqrestore(&adapter->tx_lock, flags);
 		return 1;
 	}
 
 	netdev->trans_start = jiffies;
 
+	spin_unlock_irqrestore(&adapter->tx_lock, flags);
+	
 	return 0;
 }
 
@@ -2160,6 +2168,8 @@ e1000_clean_tx_irq(struct e1000_adapter 
 	unsigned int i, eop;
 	boolean_t cleaned = FALSE;
 
+	spin_lock(&adapter->tx_lock);
+
 	i = tx_ring->next_to_clean;
 	eop = tx_ring->buffer_info[i].next_to_watch;
 	eop_desc = E1000_TX_DESC(*tx_ring, eop);
@@ -2204,6 +2214,8 @@ e1000_clean_tx_irq(struct e1000_adapter 
 	if(cleaned && netif_queue_stopped(netdev) && netif_carrier_ok(netdev))
 		netif_wake_queue(netdev);
 
+	spin_unlock(&adapter->tx_lock);
+
 	return cleaned;
 }
 




From scott.feldman@intel.com Mon Feb  2 13:26:01 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 13:26:05 -0800 (PST)
Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12LQ17J007261
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 13:26:01 -0800
Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6])
	by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i12LQxpG024211;
	Mon, 2 Feb 2004 21:26:59 GMT
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206])
	by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i12LQVMF032165;
	Mon, 2 Feb 2004 21:26:32 GMT
Received: from [134.134.3.50] ([134.134.3.50])
 by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020213252524915
 ; Mon, 02 Feb 2004 13:25:25 -0800
Date: Mon, 2 Feb 2004 14:01:26 -0800 (PST)
From: "Feldman, Scott" <scott.feldman@intel.com>
X-X-Sender: scott.feldman@localhost.localdomain
Reply-To: "Feldman, Scott" <scott.feldman@intel.com>
To: Jeff Garzik <jgarzik@pobox.com>
cc: netdev@oss.sgi.com, "Feldman, Scott" <scott.feldman@intel.com>
Subject: [e1000 netdev-2.6 1/6] on-demand stats support
Message-ID: <Pine.LNX.4.44.0402021334560.6288-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-archive-position: 2957
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: scott.feldman@intel.com
Precedence: bulk
X-list: netdev
Content-Length: 5620
Lines: 142


* Provide updated stats when requested via ->get_stats or ethtool.
  Previously, driver would only update stats every 2 seconds,
  which would cause some monitoring apps to show zero change
  from one second to the next.

----------

diff -Naurp netdev-2.6/drivers/net/e1000/e1000_ethtool.c netdev-2.6/drivers/net/e1000.mod/e1000_ethtool.c
--- netdev-2.6/drivers/net/e1000/e1000_ethtool.c	2004-02-02 12:05:14.