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.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000_ethtool.c	2004-02-02 12:05:31.000000000 -0800
@@ -43,6 +43,7 @@ extern int e1000_setup_rx_resources(stru
 extern int e1000_setup_tx_resources(struct e1000_adapter *adapter);
 extern void e1000_free_rx_resources(struct e1000_adapter *adapter);
 extern void e1000_free_tx_resources(struct e1000_adapter *adapter);
+extern void e1000_update_stats(struct e1000_adapter *adapter);
 
 struct e1000_stats {
 	char stat_string[ETH_GSTRING_LEN];
@@ -1604,6 +1605,7 @@ err_geeprom_ioctl:
 		} stats = { {ETHTOOL_GSTATS, E1000_STATS_LEN} };
 		int i;
 
+		e1000_update_stats(adapter);
 		for(i = 0; i < E1000_STATS_LEN; i++)
 			stats.data[i] = (e1000_gstrings_stats[i].sizeof_stat ==
 					sizeof(uint64_t)) ?
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:05:14.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000.h	2004-02-02 12:05:38.000000000 -0800
@@ -206,6 +206,9 @@ struct e1000_adapter {
 	uint32_t tx_int_delay;
 	uint32_t tx_abs_int_delay;
 	uint32_t gotcl;
+	uint64_t gotcl_old;
+	uint64_t tpt_old;
+	uint64_t colc_old;
 	uint32_t tx_fifo_head;
 	uint32_t tx_head_addr;
 	uint32_t tx_fifo_size;
@@ -220,6 +223,7 @@ struct e1000_adapter {
 	uint32_t rx_abs_int_delay;
 	boolean_t rx_csum;
 	uint32_t gorcl;
+	uint64_t gorcl_old;
 
 	/* Interrupt Throttle Rate */
 	uint32_t itr;
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:05:14.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000_main.c	2004-02-02 12:06:46.000000000 -0800
@@ -119,6 +119,7 @@ int e1000_setup_tx_resources(struct e100
 int e1000_setup_rx_resources(struct e1000_adapter *adapter);
 void e1000_free_tx_resources(struct e1000_adapter *adapter);
 void e1000_free_rx_resources(struct e1000_adapter *adapter);
+void e1000_update_stats(struct e1000_adapter *adapter);
 
 /* Local Function Prototypes */
 
@@ -142,7 +143,6 @@ static int e1000_xmit_frame(struct sk_bu
 static struct net_device_stats * e1000_get_stats(struct net_device *netdev);
 static int e1000_change_mtu(struct net_device *netdev, int new_mtu);
 static int e1000_set_mac(struct net_device *netdev, void *p);
-static void e1000_update_stats(struct e1000_adapter *adapter);
 static inline void e1000_irq_disable(struct e1000_adapter *adapter);
 static inline void e1000_irq_enable(struct e1000_adapter *adapter);
 static irqreturn_t e1000_intr(int irq, void *data, struct pt_regs *regs);
@@ -1392,6 +1392,17 @@ e1000_watchdog(unsigned long data)
 	}
 
 	e1000_update_stats(adapter);
+
+	adapter->hw.tx_packet_delta = adapter->stats.tpt - adapter->tpt_old;
+	adapter->tpt_old = adapter->stats.tpt;
+	adapter->hw.collision_delta = adapter->stats.colc - adapter->colc_old;
+	adapter->colc_old = adapter->stats.colc;
+	
+	adapter->gorcl = adapter->stats.gorcl - adapter->gorcl_old;
+	adapter->gorcl_old = adapter->stats.gorcl;
+	adapter->gotcl = adapter->stats.gotcl - adapter->gotcl_old;
+	adapter->gotcl_old = adapter->stats.gotcl;
+
 	e1000_update_adaptive(&adapter->hw);
 
 	if(!netif_carrier_ok(netdev)) {
@@ -1838,6 +1849,7 @@ e1000_get_stats(struct net_device *netde
 {
 	struct e1000_adapter *adapter = netdev->priv;
 
+	e1000_update_stats(adapter);
 	return &adapter->net_stats;
 }
 
@@ -1896,7 +1908,7 @@ e1000_change_mtu(struct net_device *netd
  * @adapter: board private structure
  **/
 
-static void
+void
 e1000_update_stats(struct e1000_adapter *adapter)
 {
 	struct e1000_hw *hw = &adapter->hw;
@@ -1914,8 +1926,7 @@ e1000_update_stats(struct e1000_adapter 
 
 	adapter->stats.crcerrs += E1000_READ_REG(hw, CRCERRS);
 	adapter->stats.gprc += E1000_READ_REG(hw, GPRC);
-	adapter->gorcl = E1000_READ_REG(hw, GORCL);
-	adapter->stats.gorcl += adapter->gorcl;
+	adapter->stats.gorcl += E1000_READ_REG(hw, GORCL);
 	adapter->stats.gorch += E1000_READ_REG(hw, GORCH);
 	adapter->stats.bprc += E1000_READ_REG(hw, BPRC);
 	adapter->stats.mprc += E1000_READ_REG(hw, MPRC);
@@ -1927,8 +1938,6 @@ e1000_update_stats(struct e1000_adapter 
 	adapter->stats.prc1023 += E1000_READ_REG(hw, PRC1023);
 	adapter->stats.prc1522 += E1000_READ_REG(hw, PRC1522);
 
-	spin_unlock_irqrestore(&adapter->stats_lock, flags);
-
 	/* the rest of the counters are only modified here */
 
 	adapter->stats.symerrs += E1000_READ_REG(hw, SYMERRS);
@@ -1946,8 +1955,7 @@ e1000_update_stats(struct e1000_adapter 
 	adapter->stats.xofftxc += E1000_READ_REG(hw, XOFFTXC);
 	adapter->stats.fcruc += E1000_READ_REG(hw, FCRUC);
 	adapter->stats.gptc += E1000_READ_REG(hw, GPTC);
-	adapter->gotcl = E1000_READ_REG(hw, GOTCL);
-	adapter->stats.gotcl += adapter->gotcl;
+	adapter->stats.gotcl += E1000_READ_REG(hw, GOTCL);
 	adapter->stats.gotch += E1000_READ_REG(hw, GOTCH);
 	adapter->stats.rnbc += E1000_READ_REG(hw, RNBC);
 	adapter->stats.ruc += E1000_READ_REG(hw, RUC);
@@ -2029,6 +2037,8 @@ e1000_update_stats(struct e1000_adapter 
 		   !e1000_read_phy_reg(hw, M88E1000_RX_ERR_CNTR, &phy_tmp))
 			adapter->phy_stats.receive_errors += phy_tmp;
 	}
+
+	spin_unlock_irqrestore(&adapter->stats_lock, flags);
 }
 
 /**



From scott.feldman@intel.com Mon Feb  2 13:26:22 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 13:26:29 -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 i12LQL7J007521
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 13:26:21 -0800
Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39])
	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 i12LRrq5026712;
	Mon, 2 Feb 2004 21:27:53 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129])
	by talaria.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 i12LPMHu024855;
	Mon, 2 Feb 2004 21:25:58 GMT
Received: from [134.134.3.50] ([134.134.3.50])
 by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020213261414860
 ; Mon, 02 Feb 2004 13:26:14 -0800
Date: Mon, 2 Feb 2004 14:02:15 -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 6/6] Misc - copyright, changelog spelling
Message-ID: <Pine.LNX.4.44.0402021359300.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: 2959
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: 6712
Lines: 143


* Misc - copyright update, changelog, spelling fixes.

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

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:11:27.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000_ethtool.c	2004-02-02 12:11:52.000000000 -0800
@@ -1,7 +1,7 @@
 /*******************************************************************************
 
   
-  Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved.
+  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved.
   
   This program is free software; you can redistribute it and/or modify it 
   under the terms of the GNU General Public License as published by the Free 
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:11:27.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000.h	2004-02-02 12:11:56.000000000 -0800
@@ -1,7 +1,7 @@
 /*******************************************************************************
 
   
-  Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved.
+  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved.
   
   This program is free software; you can redistribute it and/or modify it 
   under the terms of the GNU General Public License as published by the Free 
diff -Naurp netdev-2.6/drivers/net/e1000/e1000_hw.c netdev-2.6/drivers/net/e1000.mod/e1000_hw.c
--- netdev-2.6/drivers/net/e1000/e1000_hw.c	2004-02-02 12:11:27.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000_hw.c	2004-02-02 12:11:59.000000000 -0800
@@ -1,7 +1,7 @@
 /*******************************************************************************
 
   
-  Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved.
+  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved.
   
   This program is free software; you can redistribute it and/or modify it 
   under the terms of the GNU General Public License as published by the Free 
diff -Naurp netdev-2.6/drivers/net/e1000/e1000_hw.h netdev-2.6/drivers/net/e1000.mod/e1000_hw.h
--- netdev-2.6/drivers/net/e1000/e1000_hw.h	2004-02-02 12:11:27.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000_hw.h	2004-02-02 12:12:03.000000000 -0800
@@ -1,7 +1,7 @@
 /*******************************************************************************
 
   
-  Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved.
+  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved.
   
   This program is free software; you can redistribute it and/or modify it 
   under the terms of the GNU General Public License as published by the Free 
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:11:27.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000_main.c	2004-02-02 12:14:08.000000000 -0800
@@ -1,7 +1,7 @@
 /*******************************************************************************
 
   
-  Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved.
+  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved.
   
   This program is free software; you can redistribute it and/or modify it 
   under the terms of the GNU General Public License as published by the Free 
@@ -30,7 +30,12 @@
 
 /* Change Log
  *
- * 5.2.27	12/14/03
+ * 5.2.30.1	1/29/03
+ *   o Set VLAN filtering to IEEE 802.1Q after reset so we don't break
+ *     SoL connections that use VLANs.
+ *   o Allow 1000/Full setting for AutoNeg param for Fiber connections
+ *     Jon D Mason [jonmason@us.ibm.com].
+ *   o Race between Tx queue and Tx clean fixed with a spin lock.
  *   o Added netpoll support.
  *   o Fixed endianess bug causing ethtool loopback diags to fail on ppc.
  *   o Use pdev->irq rather than netdev->irq in preparation for MSI support.
@@ -63,8 +68,8 @@
 
 char e1000_driver_name[] = "e1000";
 char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver";
-char e1000_driver_version[] = "5.2.27-k1";
-char e1000_copyright[] = "Copyright (c) 1999-2003 Intel Corporation.";
+char e1000_driver_version[] = "5.2.30.1-k1";
+char e1000_copyright[] = "Copyright (c) 1999-2004 Intel Corporation.";
 
 /* e1000_pci_tbl - PCI Device ID Table
  *
diff -Naurp netdev-2.6/drivers/net/e1000/e1000_osdep.h netdev-2.6/drivers/net/e1000.mod/e1000_osdep.h
--- netdev-2.6/drivers/net/e1000/e1000_osdep.h	2004-02-02 12:11:27.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000_osdep.h	2004-02-02 12:14:13.000000000 -0800
@@ -1,7 +1,7 @@
 /*******************************************************************************
 
   
-  Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved.
+  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved.
   
   This program is free software; you can redistribute it and/or modify it 
   under the terms of the GNU General Public License as published by the Free 
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:11:27.000000000 -0800
+++ netdev-2.6/drivers/net/e1000.mod/e1000_param.c	2004-02-02 12:14:52.000000000 -0800
@@ -1,7 +1,7 @@
 /*******************************************************************************
 
   
-  Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved.
+  Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved.
   
   This program is free software; you can redistribute it and/or modify it 
   under the terms of the GNU General Public License as published by the Free 
@@ -63,7 +63,7 @@ MODULE_PARM_DESC(X, S);
 /* Transmit Descriptor Count
  *
  * Valid Range: 80-256 for 82542 and 82543 gigabit ethernet controllers
- * Valid Range: 80-4096 for 82544
+ * Valid Range: 80-4096 for 82544 and newer
  *
  * Default Value: 256
  */
@@ -73,7 +73,7 @@ E1000_PARAM(TxDescriptors, "Number of tr
 /* Receive Descriptor Count
  *
  * Valid Range: 80-256 for 82542 and 82543 gigabit ethernet controllers
- * Valid Range: 80-4096 for 82544
+ * Valid Range: 80-4096 for 82544 and newer
  *
  * Default Value: 256
  */
@@ -289,7 +289,7 @@ static void e1000_check_copper_options(s
  * e1000_check_options - Range Checking for Command Line Parameters
  * @adapter: board private structure
  *
- * This routine checks all command line paramters for valid user
+ * This routine checks all command line parameters for valid user
  * input.  If an invalid value is given, or if no user specified
  * value exists, a default value is used.  The final value is stored
  * in a variable in the adapter structure.



From dlstevens@us.ibm.com Mon Feb  2 15:42:25 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 15:42:28 -0800 (PST)
Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12NgO7J015927
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 15:42:24 -0800
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i12NfGpZ620196;
	Mon, 2 Feb 2004 18:41:16 -0500
Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i12Nf9l7106114;
	Mon, 2 Feb 2004 16:41:14 -0700
Importance: Normal
Sensitivity: 
Subject: Re: Deadlock problem with dev->refcnt somewhere in netlink/multicast... [PATCH]
To: Willy Tarreau <willy@w.ods.org>, "David S. Miller" <davem@redhat.com>
Cc: netdev@oss.sgi.com, jgarzik@pobox.com, Alexandre.Cassen@wanadoo.fr
X-Mailer: Lotus Notes Release 5.0.4a  July 24, 2000
Message-ID: <OFDBAB37F5.227951E9-ON88256E2E.0080F5BF@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Mon, 2 Feb 2004 16:41:11 -0700
X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November
 14, 2003) at 02/02/2004 16:41:14
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=07BBE4BDDF13732F8f9e8a93df938690918c07BBE4BDDF13732F"
X-archive-position: 2960
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: dlstevens@us.ibm.com
Precedence: bulk
X-list: netdev
Content-Length: 7066
Lines: 189

--0__=07BBE4BDDF13732F8f9e8a93df938690918c07BBE4BDDF13732F
Content-type: multipart/alternative; 
	Boundary="1__=07BBE4BDDF13732F8f9e8a93df938690918c07BBE4BDDF13732F"

--1__=07BBE4BDDF13732F8f9e8a93df938690918c07BBE4BDDF13732F
Content-type: text/plain; charset=US-ASCII





Below is a patch for the reference count problem you ran into.

The problem is that the IGMP code was using "IFF_UP" to determine
if a report should be sent or a timer should be started. But it is not
necessarily cleared during a destroy_dev.

The IPv4 code was also missing an ip_mc_down() call added in the
IPv6 code for a similar case by Jan Oravec.

The patch is for 2.4.x but also applies to 2.6.x. In-line for
whitespace-mangled
viewing and attached for applying.

Thanks for reporting the problem, Willy, and let me know if you have any
problems with the patch.
                              +-DLS

diff -ruN linux-2.4.25-pre8/net/ipv4/igmp.c linux-2.4.25-pre8F2/net/ipv4/igmp.c
--- linux-2.4.25-pre8/net/ipv4/igmp.c     2004-01-29 16:21:28.000000000 -0800
+++ linux-2.4.25-pre8F2/net/ipv4/igmp.c   2004-02-02 14:43:40.000000000 -0800
@@ -1051,7 +1051,7 @@
      reporter = im->reporter;
      igmp_stop_timer(im);

-     if (in_dev->dev->flags & IFF_UP) {
+     if (!in_dev->dead) {
            if (IGMP_V1_SEEN(in_dev))
                  goto done;
            if (IGMP_V2_SEEN(in_dev)) {
@@ -1082,6 +1082,8 @@
      if (im->multiaddr == IGMP_ALL_HOSTS)
            return;

+     if (in_dev->dead)
+           return;
      if (IGMP_V1_SEEN(in_dev) || IGMP_V2_SEEN(in_dev)) {
            spin_lock_bh(&im->lock);
            igmp_start_timer(im, IGMP_Initial_Report_Delay);
@@ -1155,7 +1157,7 @@
      igmpv3_del_delrec(in_dev, im->multiaddr);
 #endif
      igmp_group_added(im);
-     if (in_dev->dev->flags & IFF_UP)
+     if (!in_dev->dead)
            ip_rt_multicast_event(in_dev);
 out:
      return;
@@ -1179,7 +1181,7 @@
                        write_unlock_bh(&in_dev->lock);
                        igmp_group_dropped(i);

-                       if (in_dev->dev->flags & IFF_UP)
+                       if (!in_dev->dead)
                              ip_rt_multicast_event(in_dev);

                        ip_ma_put(i);
@@ -1255,6 +1257,9 @@

      ASSERT_RTNL();

+     /* Deactivate timers */
+     ip_mc_down(in_dev);
+
      write_lock_bh(&in_dev->lock);
      while ((i = in_dev->mc_list) != NULL) {
            in_dev->mc_list = i->next;

(See attached file: 2.4igmpref.patch)
--1__=07BBE4BDDF13732F8f9e8a93df938690918c07BBE4BDDF13732F
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline

<html><body>
<p>Below is a patch for the reference count problem you ran into.<br>
<br>
The problem is that the IGMP code was using &quot;IFF_UP&quot; to determine<br>
if a report should be sent or a timer should be started. But it is not<br>
necessarily cleared during a destroy_dev.<br>
<br>
The IPv4 code was also missing an ip_mc_down() call added in the<br>
IPv6 code for a similar case by Jan Oravec.<br>
<br>
The patch is for 2.4.x but also applies to 2.6.x. In-line for whitespace-mangled<br>
viewing and attached for applying.<br>
<br>
Thanks for reporting the problem, Willy, and let me know if you have any<br>
problems with the patch.<br>
					+-DLS<br>
<br>
diff -ruN linux-2.4.25-pre8/net/ipv4/igmp.c linux-2.4.25-pre8F2/net/ipv4/igmp.c<br>
--- linux-2.4.25-pre8/net/ipv4/igmp.c	2004-01-29 16:21:28.000000000 -0800<br>
+++ linux-2.4.25-pre8F2/net/ipv4/igmp.c	2004-02-02 14:43:40.000000000 -0800<br>
@@ -1051,7 +1051,7 @@<br>
 	reporter = im-&gt;reporter;<br>
 	igmp_stop_timer(im);<br>
 <br>
-	if (in_dev-&gt;dev-&gt;flags &amp; IFF_UP) {<br>
+	if (!in_dev-&gt;dead) {<br>
 		if (IGMP_V1_SEEN(in_dev))<br>
 			goto done;<br>
 		if (IGMP_V2_SEEN(in_dev)) {<br>
@@ -1082,6 +1082,8 @@<br>
 	if (im-&gt;multiaddr == IGMP_ALL_HOSTS)<br>
 		return;<br>
 <br>
+	if (in_dev-&gt;dead)<br>
+		return;<br>
 	if (IGMP_V1_SEEN(in_dev) || IGMP_V2_SEEN(in_dev)) {<br>
 		spin_lock_bh(&amp;im-&gt;lock);<br>
 		igmp_start_timer(im, IGMP_Initial_Report_Delay);<br>
@@ -1155,7 +1157,7 @@<br>
 	igmpv3_del_delrec(in_dev, im-&gt;multiaddr);<br>
 #endif<br>
 	igmp_group_added(im);<br>
-	if (in_dev-&gt;dev-&gt;flags &amp; IFF_UP)<br>
+	if (!in_dev-&gt;dead)<br>
 		ip_rt_multicast_event(in_dev);<br>
 out:<br>
 	return;<br>
@@ -1179,7 +1181,7 @@<br>
 				write_unlock_bh(&amp;in_dev-&gt;lock);<br>
 				igmp_group_dropped(i);<br>
 <br>
-				if (in_dev-&gt;dev-&gt;flags &amp; IFF_UP)<br>
+				if (!in_dev-&gt;dead)<br>
 					ip_rt_multicast_event(in_dev);<br>
 <br>
 				ip_ma_put(i);<br>
@@ -1255,6 +1257,9 @@<br>
 <br>
 	ASSERT_RTNL();<br>
 <br>
+	/* Deactivate timers */<br>
+	ip_mc_down(in_dev);<br>
+<br>
 	write_lock_bh(&amp;in_dev-&gt;lock);<br>
 	while ((i = in_dev-&gt;mc_list) != NULL) {<br>
 		in_dev-&gt;mc_list = i-&gt;next;<br>
<br>
<i>(See attached file: 2.4igmpref.patch)</i><br>
</body></html>

--1__=07BBE4BDDF13732F8f9e8a93df938690918c07BBE4BDDF13732F--


--0__=07BBE4BDDF13732F8f9e8a93df938690918c07BBE4BDDF13732F
Content-type: application/octet-stream; 
	name="2.4igmpref.patch"
Content-Disposition: attachment; filename="2.4igmpref.patch"
Content-ID: <10__=07BBE4BDDF13732F8f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64

ZGlmZiAtcnVOIGxpbnV4LTIuNC4yNS1wcmU4L25ldC9pcHY0L2lnbXAuYyBsaW51eC0yLjQuMjUt
cHJlOEYyL25ldC9pcHY0L2lnbXAuYwotLS0gbGludXgtMi40LjI1LXByZTgvbmV0L2lwdjQvaWdt
cC5jCTIwMDQtMDEtMjkgMTY6MjE6MjguMDAwMDAwMDAwIC0wODAwCisrKyBsaW51eC0yLjQuMjUt
cHJlOEYyL25ldC9pcHY0L2lnbXAuYwkyMDA0LTAyLTAyIDE0OjQzOjQwLjAwMDAwMDAwMCAtMDgw
MApAQCAtMTA1MSw3ICsxMDUxLDcgQEAKIAlyZXBvcnRlciA9IGltLT5yZXBvcnRlcjsKIAlpZ21w
X3N0b3BfdGltZXIoaW0pOwogCi0JaWYgKGluX2Rldi0+ZGV2LT5mbGFncyAmIElGRl9VUCkgewor
CWlmICghaW5fZGV2LT5kZWFkKSB7CiAJCWlmIChJR01QX1YxX1NFRU4oaW5fZGV2KSkKIAkJCWdv
dG8gZG9uZTsKIAkJaWYgKElHTVBfVjJfU0VFTihpbl9kZXYpKSB7CkBAIC0xMDgyLDYgKzEwODIs
OCBAQAogCWlmIChpbS0+bXVsdGlhZGRyID09IElHTVBfQUxMX0hPU1RTKQogCQlyZXR1cm47CiAK
KwlpZiAoaW5fZGV2LT5kZWFkKQorCQlyZXR1cm47CiAJaWYgKElHTVBfVjFfU0VFTihpbl9kZXYp
IHx8IElHTVBfVjJfU0VFTihpbl9kZXYpKSB7CiAJCXNwaW5fbG9ja19iaCgmaW0tPmxvY2spOwog
CQlpZ21wX3N0YXJ0X3RpbWVyKGltLCBJR01QX0luaXRpYWxfUmVwb3J0X0RlbGF5KTsKQEAgLTEx
NTUsNyArMTE1Nyw3IEBACiAJaWdtcHYzX2RlbF9kZWxyZWMoaW5fZGV2LCBpbS0+bXVsdGlhZGRy
KTsKICNlbmRpZgogCWlnbXBfZ3JvdXBfYWRkZWQoaW0pOwotCWlmIChpbl9kZXYtPmRldi0+Zmxh
Z3MgJiBJRkZfVVApCisJaWYgKCFpbl9kZXYtPmRlYWQpCiAJCWlwX3J0X211bHRpY2FzdF9ldmVu
dChpbl9kZXYpOwogb3V0OgogCXJldHVybjsKQEAgLTExNzksNyArMTE4MSw3IEBACiAJCQkJd3Jp
dGVfdW5sb2NrX2JoKCZpbl9kZXYtPmxvY2spOwogCQkJCWlnbXBfZ3JvdXBfZHJvcHBlZChpKTsK
IAotCQkJCWlmIChpbl9kZXYtPmRldi0+ZmxhZ3MgJiBJRkZfVVApCisJCQkJaWYgKCFpbl9kZXYt
PmRlYWQpCiAJCQkJCWlwX3J0X211bHRpY2FzdF9ldmVudChpbl9kZXYpOwogCiAJCQkJaXBfbWFf
cHV0KGkpOwpAQCAtMTI1NSw2ICsxMjU3LDkgQEAKIAogCUFTU0VSVF9SVE5MKCk7CiAKKwkvKiBE
ZWFjdGl2YXRlIHRpbWVycyAqLworCWlwX21jX2Rvd24oaW5fZGV2KTsKKwogCXdyaXRlX2xvY2tf
YmgoJmluX2Rldi0+bG9jayk7CiAJd2hpbGUgKChpID0gaW5fZGV2LT5tY19saXN0KSAhPSBOVUxM
KSB7CiAJCWluX2Rldi0+bWNfbGlzdCA9IGktPm5leHQ7Cg==

--0__=07BBE4BDDF13732F8f9e8a93df938690918c07BBE4BDDF13732F--


From davem@redhat.com Mon Feb  2 15:48:38 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 15:48:43 -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 i12NmZ7J016397
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 15:48: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 i12Nlub10518;
	Mon, 2 Feb 2004 18:47:56 -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 i12Nlua00851;
	Mon, 2 Feb 2004 18:47:56 -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 i12NlQkC008023;
	Mon, 2 Feb 2004 18:47:27 -0500
Date: Mon, 2 Feb 2004 15:47:55 -0800
From: "David S. Miller" <davem@redhat.com>
To: David Stevens <dlstevens@us.ibm.com>
Cc: willy@w.ods.org, netdev@oss.sgi.com, jgarzik@pobox.com,
        Alexandre.Cassen@wanadoo.fr
Subject: Re: Deadlock problem with dev->refcnt somewhere in
 netlink/multicast... [PATCH]
Message-Id: <20040202154755.311745d1.davem@redhat.com>
In-Reply-To: <OFDBAB37F5.227951E9-ON88256E2E.0080F5BF@us.ibm.com>
References: <OFDBAB37F5.227951E9-ON88256E2E.0080F5BF@us.ibm.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: 2961
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: 496
Lines: 13

On Mon, 2 Feb 2004 16:41:11 -0700
David Stevens <dlstevens@us.ibm.com> wrote:

> Below is a patch for the reference count problem you ran into.
> 
> The problem is that the IGMP code was using "IFF_UP" to determine
> if a report should be sent or a timer should be started. But it is not
> necessarily cleared during a destroy_dev.
> 
> The IPv4 code was also missing an ip_mc_down() call added in the
> IPv6 code for a similar case by Jan Oravec.

Applied to both 2.4.x and 2.6.x, thanks David.

From zaitcev@redhat.com Mon Feb  2 20:12:08 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 20:12:16 -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 i134C77J030887
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 20:12:08 -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 i134C5b10473;
	Mon, 2 Feb 2004 23:12:05 -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 i134C5a15862;
	Mon, 2 Feb 2004 23:12:05 -0500
Received: from niphredil.zaitcev.lan (vpn50-74.rdu.redhat.com [172.16.50.74])
	by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i134BZkC006898;
	Mon, 2 Feb 2004 23:11:36 -0500
Date: Mon, 2 Feb 2004 20:12:03 -0800
From: Pete Zaitcev <zaitcev@redhat.com>
To: schwidefsky@de.ibm.com
Cc: netdev@oss.sgi.com
Subject: Patchlet 2.6 iucv
Message-Id: <20040202201203.4c8b2053.zaitcev@redhat.com>
Organization: Red Hat, Inc.
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 2963
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: zaitcev@redhat.com
Precedence: bulk
X-list: netdev
Content-Length: 642
Lines: 19

Hi, Martin,

it seems that someone misused container_of. Spotted by Al Viro.
Please pass to whoever is responsible for IUCV.

-- Pete

--- linux-2.6.1/drivers/s390/net/netiucv.c	2003-10-01 15:17:54.000000000 -0700
+++ linux-2.6.1-s390/drivers/s390/net/netiucv.c	2004-02-02 19:59:11.000000000 -0800
@@ -1258,8 +1258,7 @@
 buffer_write (struct device *dev, const char *buf, size_t count)
 {
 	struct netiucv_priv *priv = dev->driver_data;
-	struct net_device *ndev =
-		container_of((void *)priv, struct net_device, priv);
+	struct net_device *ndev = priv->conn->netdev;
 	char         *e;
 	int          bs1;
 	char         tmp[CTRL_BUFSIZE];

From willy@w.ods.org Mon Feb  2 22:01:28 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 22:01:39 -0800 (PST)
Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1361QKO005386
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 22:01:27 -0800
Date: Tue, 3 Feb 2004 07:00:48 +0100
From: Willy Tarreau <willy@w.ods.org>
To: David Stevens <dlstevens@us.ibm.com>
Cc: "David S. Miller" <davem@redhat.com>, netdev@oss.sgi.com,
        jgarzik@pobox.com, Alexandre.Cassen@wanadoo.fr
Subject: Re: Deadlock problem with dev->refcnt somewhere in netlink/multicast... [PATCH]
Message-ID: <20040203060048.GA3531@alpha.home.local>
References: <OFDBAB37F5.227951E9-ON88256E2E.0080F5BF@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OFDBAB37F5.227951E9-ON88256E2E.0080F5BF@us.ibm.com>
User-Agent: Mutt/1.4i
X-archive-position: 2964
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: willy@w.ods.org
Precedence: bulk
X-list: netdev
Content-Length: 799
Lines: 26

Hi David,

On Mon, Feb 02, 2004 at 04:41:11PM -0700, David Stevens wrote:
> Below is a patch for the reference count problem you ran into.
> 
> The problem is that the IGMP code was using "IFF_UP" to determine
> if a report should be sent or a timer should be started. But it is not
> necessarily cleared during a destroy_dev.
> 
> The IPv4 code was also missing an ip_mc_down() call added in the
> IPv6 code for a similar case by Jan Oravec.

I would never have found this myself !

> The patch is for 2.4.x but also applies to 2.6.x. In-line for
> whitespace-mangled
> viewing and attached for applying.
> 
> Thanks for reporting the problem, Willy, and let me know if you have any
> problems with the patch.

Thanks a lot, I will try ASAP and will report if I still can break it.

Cheers,
Willy


From yoshfuji@linux-ipv6.org Mon Feb  2 23:27:06 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Feb 2004 23:27:09 -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 i137R5KO013033
	for <netdev@oss.sgi.com>; Mon, 2 Feb 2004 23:27:06 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 7B73233CA5; Tue,  3 Feb 2004 16:27:54 +0900 (JST)
Date: Tue, 03 Feb 2004 16:27:54 +0900 (JST)
Message-Id: <20040203.162754.96958174.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: [PATCH] IPV6: fix a possible dst leakage in ndisc_send_redirect()
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
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: 2965
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: yoshfuji@linux-ipv6.org
Precedence: bulk
X-list: netdev
Content-Length: 509
Lines: 21

Hello.

D: fix a dst leakage in error path in ndisc_send_redirect().

Thanks.

===== net/ipv6/ndisc.c 1.64 vs edited =====
--- 1.64/net/ipv6/ndisc.c	Thu Jan 22 15:38:40 2004
+++ edited/net/ipv6/ndisc.c	Tue Feb  3 16:18:36 2004
@@ -1365,6 +1365,7 @@
 				   1, &err);
 	if (buff == NULL) {
 		ND_PRINTK1("ndisc_send_redirect: alloc_skb failed\n");
+		dst_release(dst);
 		return;
 	}
 

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

From ak@suse.de Tue Feb  3 00:14:24 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 00:14:30 -0800 (PST)
Received: from Cantor.suse.de (ns.suse.de [195.135.220.2])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i138ELKO017115
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 00:14:24 -0800
Received: from Hermes.suse.de (Hermes.suse.de [195.135.221.8])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by Cantor.suse.de (Postfix) with ESMTP
	id 8994211F690; Tue,  3 Feb 2004 09:14:15 +0100 (CET)
Date: Tue, 3 Feb 2004 09:14:11 +0100
From: Andi Kleen <ak@suse.de>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: steve@navaho.co.uk, netdev@oss.sgi.com
Subject: Re: Conntrack leak (2.6.2rc2)
Message-Id: <20040203091411.19d3a676.ak@suse.de>
In-Reply-To: <Pine.LNX.4.33.0402021443570.6508-100000@blackhole.kfki.hu>
References: <Pine.LNX.4.58.0402021319440.5347@sorbus2.navaho>
	<Pine.LNX.4.33.0402021443570.6508-100000@blackhole.kfki.hu>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 2966
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: ak@suse.de
Precedence: bulk
X-list: netdev
Content-Length: 461
Lines: 15

On Mon, 2 Feb 2004 14:46:24 +0100 (CET)
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:

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

I also have some problems with conntrack since updating to 2.6.2rc3
from 2.6.1 on x86-64. Some TCP connections for the masqueraded machines 
seem to go extremly slow. I haven't investigated more closely yet.

/proc/slabinfo doesn't show leaks for the conntrack slab though.

-Andi


From yoshfuji@linux-ipv6.org Tue Feb  3 00:23:31 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 00:23:41 -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 i138NUKO020657
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 00:23:31 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 7DEB733CC2; Tue,  3 Feb 2004 17:24:19 +0900 (JST)
Date: Tue, 03 Feb 2004 17:24:19 +0900 (JST)
Message-Id: <20040203.172419.43878373.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: vnuorval@tcs.hut.fi, pekkas@netcore.fi, usagi-core@linux-ipv6.org,
        netdev@oss.sgi.com
Subject: Re: (usagi-core 17336) Re: [PATCH|RFC] IPv6: have a proxy discard
 link-local traffic
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
In-Reply-To: <20040203.171952.105535895.yoshfuji@linux-ipv6.org>
References: <Pine.LNX.4.58.0401272259160.28384@rhea.tcs.hut.fi>
	<20040128115910.0a83e906.davem@redhat.com>
	<20040203.171952.105535895.yoshfuji@linux-ipv6.org>
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=iso-2022-jp
Content-Transfer-Encoding: 7bit
X-archive-position: 2967
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: yoshfuji@linux-ipv6.org
Precedence: bulk
X-list: netdev
Content-Length: 1030
Lines: 23

In article <20040203.171952.105535895.yoshfuji@linux-ipv6.org> (at Tue, 03 Feb 2004 17:19:52 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> says:

> In article <20040128115910.0a83e906.davem@redhat.com> (at Wed, 28 Jan 2004 11:59:10 -0800), "David S. Miller" <davem@redhat.com> says:
> 
> > On Tue, 27 Jan 2004 23:11:20 +0200 (EET)
> > Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:
> > 
> > > Dave, since even Pekka is now convinced this patch doesn't break anything,
> > > would you consider applying it? :)
> > 
> > Yoshfuji asked for some time, so let us give it to him so he
> > may analyze your change without rushing.
> 
> David, I'm (or we're) ok with this patch. Please apply. Thanks.
> (But I still do not eat the proxy ND patch.)

Oops, I need to say something.
I however think this should be postponed after linux-2.6.2 is up
since this patch is not so "critical" fix.

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

From yoshfuji@linux-ipv6.org Tue Feb  3 01:00:06 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 01:00:09 -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 i138xtKO022117
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 00:59:56 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 1F99C33CA5; Tue,  3 Feb 2004 17:19:53 +0900 (JST)
Date: Tue, 03 Feb 2004 17:19:52 +0900 (JST)
Message-Id: <20040203.171952.105535895.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: vnuorval@tcs.hut.fi, pekkas@netcore.fi, usagi-core@linux-ipv6.org,
        netdev@oss.sgi.com
Subject: Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
In-Reply-To: <20040128115910.0a83e906.davem@redhat.com>
References: <Pine.LNX.4.44.0401170906160.9907-100000@netcore.fi>
	<Pine.LNX.4.58.0401272259160.28384@rhea.tcs.hut.fi>
	<20040128115910.0a83e906.davem@redhat.com>
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: 2968
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: yoshfuji@linux-ipv6.org
Precedence: bulk
X-list: netdev
Content-Length: 689
Lines: 17

In article <20040128115910.0a83e906.davem@redhat.com> (at Wed, 28 Jan 2004 11:59:10 -0800), "David S. Miller" <davem@redhat.com> says:

> On Tue, 27 Jan 2004 23:11:20 +0200 (EET)
> Ville Nuorvala <vnuorval@tcs.hut.fi> wrote:
> 
> > Dave, since even Pekka is now convinced this patch doesn't break anything,
> > would you consider applying it? :)
> 
> Yoshfuji asked for some time, so let us give it to him so he
> may analyze your change without rushing.

David, I'm (or we're) ok with this patch. Please apply. Thanks.
(But I still do not eat the proxy ND patch.)

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

From kadlec@blackhole.kfki.hu Tue Feb  3 01:22:24 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 01:22:35 -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 i139MDKO025984
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 01:22:14 -0800
Received: by blackhole.kfki.hu (Postfix, from userid 311)
	id 5DCF387B1; Tue,  3 Feb 2004 09:48:55 +0100 (CET)
Date: Tue, 3 Feb 2004 09:48:55 +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.0402030941100.11027-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 2969
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: 892
Lines: 26

On Mon, 2 Feb 2004, Steve Hill wrote:

> 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 created exactly the same setup (machine 1 and 3 are UMLs) and could not
reproduce the problem. tcpdump shows that machine 1 sends fragmented ICMP
echo requests and machine 3 sends ICMP echo reply back. On machine 2,
ip_conntrack_max is lowered to 10, still there is no problem after
hundreds of pings.

Do you have any extra patch applied on the top of 2.6.2rc2?

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 Tue Feb  3 06:36:00 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 06:36:03 -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 i13EZxKO020055
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 06:35:59 -0800
Received: from 10.0.0.42 (steve@navaho.co.uk)
	by pinus.navaho with SMTP (Navaho Galium v3.8.1 [Linux/i686])
	id: 1075805886; Tue, 03 Feb 2004 14:35: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 i13EZj5G010990;
	Tue, 3 Feb 2004 14:35:45 GMT
Received: from localhost (steve@localhost)
	by sorbus2.navaho (8.12.10/8.12.10/Submit) with ESMTP id i13EZjAv010986;
	Tue, 3 Feb 2004 14:35:45 GMT
X-Authentication-Warning: sorbus2.navaho: steve owned process doing -bs
Date: Tue, 3 Feb 2004 14:35:45 +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.0402030941100.11027-100000@blackhole.kfki.hu>
Message-ID: <Pine.LNX.4.58.0402031415390.10797@sorbus2.navaho>
References: <Pine.LNX.4.33.0402030941100.11027-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Navaho-ID: 401f7ea2
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: 2970
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: 1067
Lines: 25

On Tue, 3 Feb 2004, Jozsef Kadlecsik wrote:

> I created exactly the same setup (machine 1 and 3 are UMLs) and could not
> reproduce the problem. tcpdump shows that machine 1 sends fragmented ICMP
> echo requests and machine 3 sends ICMP echo reply back. On machine 2,
> ip_conntrack_max is lowered to 10, still there is no problem after
> hundreds of pings.
> 
> Do you have any extra patch applied on the top of 2.6.2rc2?

No extra patches, it's the vanilla 2.6.2rc2 kernel.  I'm running a 
nonmodular kernel and have spent this morning recompiling it with 
different options - the problem is only showing up when CONFIG_IP_NF_NAT 
is turned on, so I'm guessing that you are using a modular kernel and 
since you haven't set up any rules in the nat table, the module isn't 
loaded - try modprobing it and seeing if that helps.


- 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 Tue Feb  3 08:02:24 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 08: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 i13G2CKO025418
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 08:02:13 -0800
Received: by blackhole.kfki.hu (Postfix, from userid 311)
	id 9925C87B1; Tue,  3 Feb 2004 16:32:42 +0100 (CET)
Date: Tue, 3 Feb 2004 16:32:42 +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.0402031415390.10797@sorbus2.navaho>
Message-ID: <Pine.LNX.4.33.0402031629150.11737-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 2971
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: 884
Lines: 21

On Tue, 3 Feb 2004, Steve Hill wrote:

> No extra patches, it's the vanilla 2.6.2rc2 kernel.  I'm running a
> nonmodular kernel and have spent this morning recompiling it with
> different options - the problem is only showing up when CONFIG_IP_NF_NAT
> is turned on, so I'm guessing that you are using a modular kernel and
> since you haven't set up any rules in the nat table, the module isn't
> loaded - try modprobing it and seeing if that helps.

I can confirm that with the NAT module loaded in, the leak you described
appears. As if the reference counts created as refragging the packet
would not be cleaned up properly...

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 davem@redhat.com Tue Feb  3 09:17:01 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 09:17:04 -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 i13HH0KO001562
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 09:17:01 -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 i13HFrb20822;
	Tue, 3 Feb 2004 12:15:53 -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 i13HFra32741;
	Tue, 3 Feb 2004 12:15:53 -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 i13HFNkC013057;
	Tue, 3 Feb 2004 12:15:23 -0500
Date: Tue, 3 Feb 2004 09:15:48 -0800
From: "David S. Miller" <davem@redhat.com>
To: yoshfuji@linux-ipv6.org
Cc: vnuorval@tcs.hut.fi, pekkas@netcore.fi, usagi-core@linux-ipv6.org,
        netdev@oss.sgi.com
Subject: Re: (usagi-core 17336) Re: [PATCH|RFC] IPv6: have a proxy discard
 link-local traffic
Message-Id: <20040203091548.61051d82.davem@redhat.com>
In-Reply-To: <20040203.172419.43878373.yoshfuji@linux-ipv6.org>
References: <Pine.LNX.4.58.0401272259160.28384@rhea.tcs.hut.fi>
	<20040128115910.0a83e906.davem@redhat.com>
	<20040203.171952.105535895.yoshfuji@linux-ipv6.org>
	<20040203.172419.43878373.yoshfuji@linux-ipv6.org>
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 i13HH0KO001562
X-archive-position: 2972
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: 274
Lines: 8

On Tue, 03 Feb 2004 17:24:19 +0900 (JST)
YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> wrote:

> I however think this should be postponed after linux-2.6.2 is up
> since this patch is not so "critical" fix.

I agree, Ville please resubmit once 2.6.2 is out.


From davem@redhat.com Tue Feb  3 09:18:45 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 09:18: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 i13HIiKO001823
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 09:18:45 -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 i13HIgb22541;
	Tue, 3 Feb 2004 12:18: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 i13HIga01432;
	Tue, 3 Feb 2004 12:18:42 -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 i13HIDkC015104;
	Tue, 3 Feb 2004 12:18:13 -0500
Date: Tue, 3 Feb 2004 09:18:41 -0800
From: "David S. Miller" <davem@redhat.com>
To: yoshfuji@linux-ipv6.org
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH] IPV6: fix a possible dst leakage in
 ndisc_send_redirect()
Message-Id: <20040203091841.2804a29c.davem@redhat.com>
In-Reply-To: <20040203.162754.96958174.yoshfuji@linux-ipv6.org>
References: <20040203.162754.96958174.yoshfuji@linux-ipv6.org>
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 i13HIiKO001823
X-archive-position: 2973
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: 410
Lines: 16

On Tue, 03 Feb 2004 16:27:54 +0900 (JST)
YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> wrote:

> D: fix a dst leakage in error path in ndisc_send_redirect().

Applied.  An eventual cleanup of this function would be to consolidate
all of these paths into a single:

dst_out:
	dst_release(dst);
	return;

near the end of the function that all these spots can jump to.

But it's not so important.


From davem@redhat.com Tue Feb  3 09:48:19 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 09:48:21 -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 i13HmIKO003931
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 09:48:18 -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 i13Hm9b09278;
	Tue, 3 Feb 2004 12:48:09 -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 i13Hm9a13072;
	Tue, 3 Feb 2004 12:48:09 -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 i13HldkC030093;
	Tue, 3 Feb 2004 12:47:40 -0500
Date: Tue, 3 Feb 2004 09:48:08 -0800
From: "David S. Miller" <davem@redhat.com>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: steve@navaho.co.uk, netdev@oss.sgi.com,
        netfilter-devel@lists.netfilter.org
Subject: Re: [PATCH] fix netfilter refcounting [was Re: Conntrack leak
 (2.6.2rc2)]
Message-Id: <20040203094808.2bb3640a.davem@redhat.com>
In-Reply-To: <Pine.LNX.4.33.0402031825170.11950-100000@blackhole.kfki.hu>
References: <Pine.LNX.4.33.0402031629150.11737-100000@blackhole.kfki.hu>
	<Pine.LNX.4.33.0402031825170.11950-100000@blackhole.kfki.hu>
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: 2974
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: 507
Lines: 15

On Tue, 3 Feb 2004 18:43:38 +0100 (CET)
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:

> Steve Hill reported a conntrack leakage in 2.6.2-rc2 when nat is enabled
> and the system forwards fragmented packets. It turned out that an
> nf_conntrack_put was missing from ip_copy_metadata:

Yeah, but... look at what you patched.

>  	/* Connection association is same as pre-frag packet */
> +	nf_conntrack_put(to->nfct);
>  	to->nfct = from->nfct;
>  	nf_conntrack_get(to->nfct);

What about that comment?

From kadlec@blackhole.kfki.hu Tue Feb  3 10:15:44 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 10:15:48 -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 i13IFXKO004757
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 10:15:34 -0800
Received: by blackhole.kfki.hu (Postfix, from userid 311)
	id B7B9A87B1; Tue,  3 Feb 2004 18:43:38 +0100 (CET)
Date: Tue, 3 Feb 2004 18:43:38 +0100 (CET)
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
To: David Miller <davem@redhat.com>, Steve Hill <steve@navaho.co.uk>
Cc: <netdev@oss.sgi.com>, <netfilter-devel@lists.netfilter.org>
Subject: [PATCH] fix netfilter refcounting [was Re: Conntrack leak (2.6.2rc2)]
In-Reply-To: <Pine.LNX.4.33.0402031629150.11737-100000@blackhole.kfki.hu>
Message-ID: <Pine.LNX.4.33.0402031825170.11950-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 2975
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: 863
Lines: 27

Hi Dave,

Steve Hill reported a conntrack leakage in 2.6.2-rc2 when nat is enabled
and the system forwards fragmented packets. It turned out that an
nf_conntrack_put was missing from ip_copy_metadata:

--- a/net/ipv4/ip_output.c	2004-01-09 08:00:12.000000000 +0100
+++ t/net/ipv4/ip_output.c	2004-02-03 18:15:07.000000000 +0100
@@ -414,6 +414,7 @@
 	to->nfmark = from->nfmark;
 	to->nfcache = from->nfcache;
 	/* Connection association is same as pre-frag packet */
+	nf_conntrack_put(to->nfct);
 	to->nfct = from->nfct;
 	nf_conntrack_get(to->nfct);
 #ifdef CONFIG_BRIDGE_NETFILTER

Please apply the patch.

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 sri@us.ibm.com Tue Feb  3 10:17:00 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 10:17:04 -0800 (PST)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i13IGxKO004966
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 10:17:00 -0800
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i13IDuvM531658;
	Tue, 3 Feb 2004 13:13:56 -0500
Received: from w-sridhar.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i13IDtl2058012;
	Tue, 3 Feb 2004 13:13:55 -0500
Date: Tue, 3 Feb 2004 10:13:54 -0800 (PST)
From: Sridhar Samudrala <sri@us.ibm.com>
X-X-Sender: sridhar@localhost.localdomain
To: "David S. Miller" <davem@redhat.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.
In-Reply-To: <20040202112150.3c8d5218.davem@redhat.com>
Message-ID: <Pine.LNX.4.58.0402031008120.2060@localhost.localdomain>
References: <1075747382.786.366.camel@hades.cambridge.redhat.com>
 <Pine.LNX.4.58.0402021056290.2352@localhost.localdomain>
 <20040202112150.3c8d5218.davem@redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 2976
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: 521
Lines: 17

On Mon, 2 Feb 2004, David S. Miller wrote:

>
> 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 :-)

I contacted the team that started the 2.4 backport and we will try to fix
this in the next few weeks so that 2.4 lksctp is in sync 2.6. Hopefully
this will happen by 2.4.26.

Thanks
Sridhar

From davem@redhat.com Tue Feb  3 10:19:47 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 10:19: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 i13IJlKO005532
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 10:19:47 -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 i13IJhb28985;
	Tue, 3 Feb 2004 13:19:43 -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 i13IJha25624;
	Tue, 3 Feb 2004 13:19:43 -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 i13IJDkC014512;
	Tue, 3 Feb 2004 13:19:13 -0500
Date: Tue, 3 Feb 2004 10:19:42 -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: <20040203101942.4568a962.davem@redhat.com>
In-Reply-To: <Pine.LNX.4.58.0402031008120.2060@localhost.localdomain>
References: <1075747382.786.366.camel@hades.cambridge.redhat.com>
	<Pine.LNX.4.58.0402021056290.2352@localhost.localdomain>
	<20040202112150.3c8d5218.davem@redhat.com>
	<Pine.LNX.4.58.0402031008120.2060@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: 2977
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: 319
Lines: 8

On Tue, 3 Feb 2004 10:13:54 -0800 (PST)
Sridhar Samudrala <sri@us.ibm.com> wrote:

> I contacted the team that started the 2.4 backport and we will try to fix
> this in the next few weeks so that 2.4 lksctp is in sync 2.6. Hopefully
> this will happen by 2.4.26.

That's great news, thanks a lot for the status report.

From davem@redhat.com Tue Feb  3 10:27:17 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 10:27:20 -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 i13IRHKO005964
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 10:27:17 -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 i13IRDb01334;
	Tue, 3 Feb 2004 13:27:13 -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 i13IRDa28780;
	Tue, 3 Feb 2004 13:27:13 -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 i13IQhkC018467;
	Tue, 3 Feb 2004 13:26:43 -0500
Date: Tue, 3 Feb 2004 10:27:12 -0800
From: "David S. Miller" <davem@redhat.com>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: steve@navaho.co.uk, netdev@oss.sgi.com,
        netfilter-devel@lists.netfilter.org
Subject: Re: [PATCH] fix netfilter refcounting [was Re: Conntrack leak
 (2.6.2rc2)]
Message-Id: <20040203102712.02626ed5.davem@redhat.com>
In-Reply-To: <Pine.LNX.4.33.0402031825170.11950-100000@blackhole.kfki.hu>
References: <Pine.LNX.4.33.0402031629150.11737-100000@blackhole.kfki.hu>
	<Pine.LNX.4.33.0402031825170.11950-100000@blackhole.kfki.hu>
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: 2978
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: 546
Lines: 12

On Tue, 3 Feb 2004 18:43:38 +0100 (CET)
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:

> Steve Hill reported a conntrack leakage in 2.6.2-rc2 when nat is enabled
> and the system forwards fragmented packets. It turned out that an
> nf_conntrack_put was missing from ip_copy_metadata:

Nevermind my previous email, it was a total thinko... you're patch
is obviously correct and we had this same damn exact problem with
the bridging skbuff nf objects as well. (see changeset 1.1474.41.3)

I'll apply your patch and push to Linus now.  Thanks.

From pekkas@netcore.fi Tue Feb  3 13:55:45 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 13:55:50 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i13LtiKO023020
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 13:55:45 -0800
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i13Ltb209356
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 23:55:38 +0200
Date: Tue, 3 Feb 2004 23:55:37 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: netdev@oss.sgi.com
Subject: Re: Disabling IPv6 accept_ra on just some interface (fwd)
Message-ID: <Pine.LNX.4.44.0402032352570.9234-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
X-archive-position: 2979
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: pekkas@netcore.fi
Precedence: bulk
X-list: netdev

Now that 2.6.x series in in a swing, being able to control, from the 
userspace, when to send RA's and when to shut them off would be very 
beneficial (2.4 too :).

In particular, consider a distribution which wants to allow disabling 
autoconfig on one interface.  When it's possible to do so, it's 
already too late..

---------- Forwarded message ----------
Date: Mon, 27 Oct 2003 15:05:42 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: "YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明"
    <yoshfuji@linux-ipv6.org>
Cc: netdev@oss.sgi.com, sekiya@wide.ad.jp
Subject: Re: Disabling IPv6 accept_ra on just some interface

On Mon, 27 Oct 2003, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote:
> In article <Pine.LNX.4.44.0310231457110.3347-100000@netcore.fi> (at Thu, 23 Oct 2003 15:22:47 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> says:
> > So, my thought (comments welcome) is:
> > 
> >  1) when accept_ra changes from 0 -> 1, initiate the route 
> >     solicitation process, likewise as one would when the interface is 
> >     brought up.
> > 
> >     Makes sense?
> > 
> >  2) (probably not a good idea, but some food for thought..) when accept_ra 
> >     changes from 1 -> 0, delete any autoconfigured routes or
> >     prefixes.  (could be ugly / dangerous..)
> 
> Well, we'd propose to have another config "send_rs" or something like that
> because accept_ra is also effective against unsolicited RAs.
> It, "send_rs," tells kernel to start sending RS 
> when the variable is changed 0 to 1 and/or 
> when interface is going up.

I don't have any major objections to this model, I'm just worried that it
might make the configuration more complex (we already have accept_ra and
"autoconf" toggles which are confusing enough without documentation :-)
with little gain.

That is, is there any case when you'd want to accept an RA but *not* send 
RS?  I fail to see clear applicability for this, hence my proposal to 
overload accept_ra :-)

> Assume the node has eth0 and eth1.
> Operation will be something like the following.
> 
> If you want to listen RA and to send RS on some interfaces,
>  sysctl -w net.ipv6.conf.default.accept_ra=0
>  sysctl -w net.ipv6.conf.default.send_rs=0
>  ifup -a
>  sysctl -w net.ipv6.conf.eth0.accept_ra=1
>  sysctl -w net.ipv6.conf.eth0.send_rs=1
> 
> If you want to listen RA on all interfaces, but do not want to send RS on 
> some of them, 
>  sysctl -w net.ipv6.conf.default.accept_ra=1
>  sysctl -w net.ipv6.conf.default.send_rs=0
>  ifup -a
>  sysctl -w net.ipv6.cont.eth0.send_rs=1
> 
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From rddunlap@osdl.org Tue Feb  3 15:43:43 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 15:43:54 -0800 (PST)
Received: from mail.osdl.org (fw.osdl.org [65.172.181.6])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i13NhgKO028538
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 15:43:42 -0800
Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27])
	by mail.osdl.org (8.11.6/8.11.6) with SMTP id i13NhaB30211;
	Tue, 3 Feb 2004 15:43:36 -0800
Date: Tue, 3 Feb 2004 15:37:25 -0800
From: "Randy.Dunlap" <rddunlap@osdl.org>
To: netdev@oss.sgi.com
Cc: jgarzik@pobox.com
Subject: [PATCH] yellowfin: correct printk of dma_addr_t
Message-Id: <20040203153725.1454e69f.rddunlap@osdl.org>
Organization: OSDL
X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu)
X-Face: +5V?h'hZQPB9<D&+Y;ig/:L-F$8p'$7h4BBmK}zo}[{h,eqHI1X}]1UhhR{49GL33z6Oo!`
 !Ys@HV,^(Xp,BToM.;N_W%gT|&/I#H@Z:ISaK9NqH%&|AO|9i/nB@vD:Km&=R2_?O<_V^7?St>kW
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 2982
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: rddunlap@osdl.org
Precedence: bulk
X-list: netdev


description:	fix dma_addr_t type error with CONFIG_HIGHMEM64G=y;
product_versions: linux-262-rc3

diffstat:=
 drivers/net/yellowfin.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff -Naurp ./drivers/net/yellowfin.c~yel_dma ./drivers/net/yellowfin.c
--- ./drivers/net/yellowfin.c~yel_dma	2004-01-08 22:59:26.000000000 -0800
+++ ./drivers/net/yellowfin.c	2004-02-03 15:02:22.000000000 -0800
@@ -1286,7 +1286,8 @@ static int yellowfin_close(struct net_de
 
 #if defined(__i386__)
 	if (yellowfin_debug > 2) {
-		printk("\n"KERN_DEBUG"  Tx ring at %8.8x:\n", yp->tx_ring_dma);
+		printk("\n"KERN_DEBUG"  Tx ring at %8.8llx:\n",
+				(unsigned long long)yp->tx_ring_dma);
 		for (i = 0; i < TX_RING_SIZE*2; i++)
 			printk(" %c #%d desc. %8.8x %8.8x %8.8x %8.8x.\n",
 				   inl(ioaddr + TxPtr) == (long)&yp->tx_ring[i] ? '>' : ' ',
@@ -1298,7 +1299,8 @@ static int yellowfin_close(struct net_de
 				   i, yp->tx_status[i].tx_cnt, yp->tx_status[i].tx_errs,
 				   yp->tx_status[i].total_tx_cnt, yp->tx_status[i].paused);
 
-		printk("\n"KERN_DEBUG "  Rx ring %8.8x:\n", yp->rx_ring_dma);
+		printk("\n"KERN_DEBUG "  Rx ring %8.8llx:\n",
+				(unsigned long long)yp->rx_ring_dma);
 		for (i = 0; i < RX_RING_SIZE; i++) {
 			printk(KERN_DEBUG " %c #%d desc. %8.8x %8.8x %8.8x\n",
 				   inl(ioaddr + RxPtr) == (long)&yp->rx_ring[i] ? '>' : ' ',


--
~Randy

From rddunlap@osdl.org Tue Feb  3 15:43:51 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 15:43:54 -0800 (PST)
Received: from mail.osdl.org (fw.osdl.org [65.172.181.6])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i13NhoKO028550
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 15:43:51 -0800
Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27])
	by mail.osdl.org (8.11.6/8.11.6) with SMTP id i13NhYB30191;
	Tue, 3 Feb 2004 15:43:34 -0800
Date: Tue, 3 Feb 2004 15:34:48 -0800
From: "Randy.Dunlap" <rddunlap@osdl.org>
To: chas@cmf.nrl.navy.mil
Cc: netdev@oss.sgi.com
Subject: [PATCH] atm/idt77252: correct printk of dma_addr_t
Message-Id: <20040203153448.5c81e49d.rddunlap@osdl.org>
Organization: OSDL
X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu)
X-Face: +5V?h'hZQPB9<D&+Y;ig/:L-F$8p'$7h4BBmK}zo}[{h,eqHI1X}]1UhhR{49GL33z6Oo!`
 !Ys@HV,^(Xp,BToM.;N_W%gT|&/I#H@Z:ISaK9NqH%&|AO|9i/nB@vD:Km&=R2_?O<_V^7?St>kW
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 2981
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: rddunlap@osdl.org
Precedence: bulk
X-list: netdev


description:	fix dma_addr_t type error with CONFIG_HIGHMEM64G=y;
product_versions: linux-262-rc3

diffstat:=
 drivers/atm/idt77252.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff -Naurp ./drivers/atm/idt77252.c~idt_dma ./drivers/atm/idt77252.c
--- ./drivers/atm/idt77252.c~idt_dma	2004-01-08 22:59:33.000000000 -0800
+++ ./drivers/atm/idt77252.c	2004-02-03 14:14:08.000000000 -0800
@@ -664,8 +664,8 @@ alloc_scq(struct idt77252_dev *card, int
 	skb_queue_head_init(&scq->transmit);
 	skb_queue_head_init(&scq->pending);
 
-	TXPRINTK("idt77252: SCQ: base 0x%p, next 0x%p, last 0x%p, paddr %08x\n",
-		 scq->base, scq->next, scq->last, scq->paddr);
+	TXPRINTK("idt77252: SCQ: base 0x%p, next 0x%p, last 0x%p, paddr %08llx\n",
+		 scq->base, scq->next, scq->last, (unsigned long long)scq->paddr);
 
 	return scq;
 }


--
~Randy

From rddunlap@osdl.org Tue Feb  3 15:43:43 2004
Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 Feb 2004 15:43:48 -0800 (PST)
Received: from mail.osdl.org (fw.osdl.org [65.172.181.6])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i13NhgKO028537
	for <netdev@oss.sgi.com>; Tue, 3 Feb 2004 15:43:42 -0800
Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27])
	by mail.osdl.org (8.11.6/8.11.6) with SMTP id i13NhaB30202;
	Tue, 3 Feb 2004 15:43:36 -0800
Date: Tue, 3 Feb 2004 15:36:54 -0800
From: "Randy.Dunlap" <rddunlap@osdl.org>
To: netdev@oss.sgi.com
Cc: jgarzik@pobox.com
Subject: [PATCH] sundance: correct printk of dma_addr_t
Message-Id: <20040203153654.7bc74d19.rddunlap@osdl.org>
Organization: OSDL
X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu)
X-Face: +5V?h'hZQPB9<D&+Y;ig/:L-F$8p'$7h4BBmK}zo}[{h,eqHI1X}]1UhhR{49GL33z6Oo!`
 !Ys@HV,^(Xp,BToM.;N_W%gT|&/I#H@Z:ISaK9NqH%&|AO|9i/nB@vD:Km&=R2_?O<_V^7?St>kW
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 2980
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: rddunlap@osdl.org
Precedence: bulk
X-list: netdev


description:	fix dma_addr_t type error with CONFIG_HIGHMEM64G=y;
product_versions: linux-262-rc3

diffstat:=
 drivers/net/sundance.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff -Naurp ./drivers/net/sundance.c~sundan_dma ./drivers/net/sundance.c
--- ./drivers/net/sundance.c~sundan_dma	2004-02-03 14:53:24.000000000 -0800
+++ ./drivers/net/sundance.c	2004-02-03 14:54:28.000000000 -0800
@@ -986,8 +986,8 @@ static void tx_timeout(struct net_device
 	{
 		int i;
 		for (i=0; i<TX_RING_SIZE; i++) {
-			printk(KERN_DEBUG "%02x %08Zx %08x %08x(%02x) %08x %08x\n", i,
-				np->tx_ring_dma + i*sizeof(*np->tx_ring),
+			printk(KERN_DEBUG "%02x %08llx %08x %08x(%02x) %08x %08x\n", i,
+				(unsigned long long)np->tx_ring_dma + i*sizeof(*np->tx_ring),
 				le32_to_cpu(np->tx_ring[i].next_desc),
 				le32_to_cpu(np->tx_ring[i].status),
 				(le32_to_cpu(np->tx_ring[i].status) >> 2) & 0xff,
@@ -1672,8 +1672,8 @@ static int netdev_ioctl(struct net_devic
 	switch (cmd) {
 		case SIOCDEVPRIVATE:
 		for (i=0; i<TX_RING_SIZE; i++) {
-			printk(KERN_DEBUG "%02x %08Zx %08x %08x(%02x) %08x %08x\n", i,
-				np->tx_ring_dma + i*sizeof(*np->tx_ring),	
+			printk(KERN_DEBUG "%02x %08llx %08x %08x(%02x) %08x %08x\n", i,
+				(unsigned long long)np->tx_ring_dma + i*sizeof(*np->tx_ring),	
 				le32_to_cpu(np->tx_ring[i].next_desc),
 				le32_to_cpu(np->tx_ring[i].status),
 				(le32_to_cpu(np->tx_ring[i].status) >> 2) 


--
~Randy

From steve@navaho.co.uk Wed Feb  4 02:20:05 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 02:20:19 -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 i14AK2KO032106
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 02:20:05 -0800
Received: from 10.0.0.42 (steve@navaho.co.uk)
	by pinus.navaho with SMTP (Navaho Galium v3.8.2 [Linux/i686])
	id: 1075887426; Wed, 04 Feb 2004 10:19:50 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 i14AJo5G015637;
	Wed, 4 Feb 2004 10:19:50 GMT
Received: from localhost (steve@localhost)
	by sorbus2.navaho (8.12.10/8.12.10/Submit) with ESMTP id i14AJjJL015630;
	Wed, 4 Feb 2004 10:19:47 GMT
X-Authentication-Warning: sorbus2.navaho: steve owned process doing -bs
Date: Wed, 4 Feb 2004 10:19:45 +0000 (GMT)
From: Steve Hill <steve@navaho.co.uk>
X-X-Sender: steve@sorbus2.navaho
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
cc: David Miller <davem@redhat.com>, netdev@oss.sgi.com,
        netfilter-devel@lists.netfilter.org
Subject: Re: [PATCH] fix netfilter refcounting [was Re: Conntrack leak
 (2.6.2rc2)]
In-Reply-To: <Pine.LNX.4.33.0402031825170.11950-100000@blackhole.kfki.hu>
Message-ID: <Pine.LNX.4.58.0402041018120.15629@sorbus2.navaho>
References: <Pine.LNX.4.33.0402031825170.11950-100000@blackhole.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Navaho-ID: 4020bd3e
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: 2983
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

On Tue, 3 Feb 2004, Jozsef Kadlecsik wrote:

> Steve Hill reported a conntrack leakage in 2.6.2-rc2 when nat is enabled
> and the system forwards fragmented packets. It turned out that an
> nf_conntrack_put was missing from ip_copy_metadata:

I noticed this fix made it into the 2.6.2 release last night, so I have 
tested with a vanilla 2.6.2 kernel this morning and can confirm it's fixed 
the problem.  Thank you.

- 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 yoshfuji@linux-ipv6.org Wed Feb  4 04:13:24 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 04:13:43 -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 i14CDEKO009906
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 04:13:14 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 487A233CA5; Wed,  4 Feb 2004 20:37:39 +0900 (JST)
Date: Wed, 04 Feb 2004 20:37:39 +0900 (JST)
Message-Id: <20040204.203739.16838230.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com
Subject: [PATCH] IPV6: note on shared socket options
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
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: 2984
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: yoshfuji@linux-ipv6.org
Precedence: bulk
X-list: netdev

Hello.

There're several socket options for multicast
shared between IPv4 and IPv6.
Add a note that some range is already used for them.

(Alternatevely, we could define other names like this:
 #define IPV6_MCAST_JOIN_GROUP   MCAST_JOIN_GROUP
 #define IPV6_MCAST_BLOCK_SOURCE MCAST_BLOCK_SOURCE
 /* bla, bla ... */
)

===== include/linux/in6.h 1.5 vs edited =====
--- 1.5/include/linux/in6.h	Fri Mar 21 14:23:30 2003
+++ edited/include/linux/in6.h	Wed Feb  4 20:30:47 2004
@@ -183,5 +183,17 @@
 #define IPV6_IPSEC_POLICY	34
 #define IPV6_XFRM_POLICY	35
 
+/*
+ * Multicast:
+ * Following socket options are shared between IPv4 and IPv6.
+ *
+ * MCAST_JOIN_GROUP		42
+ * MCAST_BLOCK_SOURCE		43
+ * MCAST_UNBLOCK_SOURCE		44
+ * MCAST_LEAVE_GROUP		45
+ * MCAST_JOIN_SOURCE_GROUP	46
+ * MCAST_LEAVE_SOURCE_GROUP	47
+ * MCAST_MSFILTER		48
+ */
 
 #endif

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

From uucp@coruscant.gnumonks.org Wed Feb  4 04:27:35 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 04:27:50 -0800 (PST)
Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14CRXKO013801
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 04:27:34 -0800
Received: from uucp by coruscant.gnumonks.org with local-bsmtp (Exim 4.20)
	id 1AoM7w-0004sB-3l
	for netdev@oss.sgi.com; Wed, 04 Feb 2004 13:27:32 +0100
Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1)
	id 1AoJD3-0007Sk-00; Wed, 04 Feb 2004 10:20:37 +0100
Date: Wed, 4 Feb 2004 10:20:37 +0100
From: Harald Welte <laforge@gnumonks.org>
To: Steve Hill <steve@navaho.co.uk>
Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>, netdev@oss.sgi.com
Subject: Re: Conntrack leak (2.6.2rc2)
Message-ID: <20040204092037.GW25175@obroa-skai.de.gnumonks.org>
References: <Pine.LNX.4.33.0402021121540.6508-100000@blackhole.kfki.hu> <Pine.LNX.4.58.0402021039540.5347@sorbus2.navaho>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="NgG1H2o5aFKkgPy/"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58.0402021039540.5347@sorbus2.navaho>
X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.6.1-rc1-ben1
X-Date: Today is Prickle-Prickle, the 34th day of Chaos in the YOLD 3170
User-Agent: Mutt/1.5.4i
X-archive-position: 2986
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: laforge@gnumonks.org
Precedence: bulk
X-list: netdev


--NgG1H2o5aFKkgPy/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 02, 2004 at 10:48:08AM +0000, Steve Hill wrote:

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

Yes, this is indeed the case.  Whihc is not a contradiction to what
Jozsef said.  They are defragmented before getting passed to conntrack,
and thus look exactly the same like unfragmented packets throughout the
network stack (until NF_IP_POST_ROUTING).

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

Are you running any netfilter / networking related patches?  Anything
else special about the setup?

> - Steve Hill
> Senior Software Developer                        Email: steve@navaho.co.uk

--=20
- Harald Welte <laforge@gnumonks.org>               http://www.gnumonks.org/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Programming is like sex: One mistake and you have to support it your lifeti=
me

--NgG1H2o5aFKkgPy/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAILllXaXGVTD0i/8RAn6DAJ48WL3Ieh9oU/HEtUppQT8SmDA0iQCgli9R
NRjxIGqWbQ4icAqaOqCtR7c=
=Pbe+
-----END PGP SIGNATURE-----

--NgG1H2o5aFKkgPy/--

From uucp@coruscant.gnumonks.org Wed Feb  4 04:27:35 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 04:27:49 -0800 (PST)
Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14CRYKO013802
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 04:27:34 -0800
Received: from uucp by coruscant.gnumonks.org with local-bsmtp (Exim 4.20)
	id 1AoM7x-0004sT-0l
	for netdev@oss.sgi.com; Wed, 04 Feb 2004 13:27:33 +0100
Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1)
	id 1AoJFC-0007T4-00; Wed, 04 Feb 2004 10:22:50 +0100
Date: Wed, 4 Feb 2004 10:22:50 +0100
From: Harald Welte <laforge@gnumonks.org>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: Steve Hill <steve@navaho.co.uk>, netdev@oss.sgi.com
Subject: Re: Conntrack leak (2.6.2rc2)
Message-ID: <20040204092250.GX25175@obroa-skai.de.gnumonks.org>
References: <Pine.LNX.4.58.0402020937030.4127@sorbus2.navaho> <Pine.LNX.4.33.0402021121540.6508-100000@blackhole.kfki.hu>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="9a9Vq1BJdYBEXpLG"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.33.0402021121540.6508-100000@blackhole.kfki.hu>
X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.6.1-rc1-ben1
X-Date: Today is Prickle-Prickle, the 34th day of Chaos in the YOLD 3170
User-Agent: Mutt/1.5.4i
X-archive-position: 2985
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: laforge@gnumonks.org
Precedence: bulk
X-list: netdev


--9a9Vq1BJdYBEXpLG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 02, 2004 at 11:34:22AM +0100, Jozsef Kadlecsik wrote:
> On Mon, 2 Feb 2004, Steve Hill wrote:
>=20
> > > init_conntrack is called only when we have full, non-fragmented
> > > packets: ip_conntrack_in explicitly calls the proper function to gath=
er
> > > 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.
>=20
> No, that's not true (and would be bad). Please check the code.

To be more precise:

It is called for every NEW packet, after defragmentation happens (i.e.
if ip_conntrack_find_get() returns NULL, meaning there is no entry in
the hash table.).

--=20
- Harald Welte <laforge@gnumonks.org>               http://www.gnumonks.org/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Programming is like sex: One mistake and you have to support it your lifeti=
me

--9a9Vq1BJdYBEXpLG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAILnqXaXGVTD0i/8RAgCeAJ4zIlZw8RfbIvpl1Y5KmeNeWh7KRACeNIuI
PxR5xYI/t4THVqUnFztjmCs=
=SCr9
-----END PGP SIGNATURE-----

--9a9Vq1BJdYBEXpLG--

From kevin.curtis@farsite.co.uk Wed Feb  4 08:06:27 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 08:06:32 -0800 (PST)
Received: from relay5.ftech.net (relay5.ftech.net [195.200.0.100])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14G6OKO005983
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 08:06:25 -0800
Received: from pc1.faradsl.ftech.co.uk ([212.32.46.162] helo=GENERAL.hq.farsitecommunications.com)
	by relay5.ftech.net with esmtp (Exim 3.36-ftechp12 #2)
	id 1AoPXf-0003xq-00; Wed, 04 Feb 2004 16:06:19 +0000
Received: by general.hq.farsitecommunications.com with Internet Mail Service (5.5.2653.19)
	id <XRNNXDN5>; Wed, 4 Feb 2004 16:06:19 -0000
Message-ID: <7C078C66B7752B438B88E11E5E20E72E25CBB5@general.hq.farsitecommunications.com>
From: Kevin Curtis <kevin.curtis@farsite.co.uk>
To: "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>
Cc: "'davem@redhat.com'" <davem@redhat.com>,
        "'jgarzik@redhat.com'"
	 <jgarzik@redhat.com>
Subject: Update FarSync WAN driver in 2.4.25
Date: Wed, 4 Feb 2004 16:06:16 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C3EB38.D1A7D900"
X-archive-position: 2987
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: kevin.curtis@farsite.co.uk
Precedence: bulk
X-list: netdev

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C3EB38.D1A7D900
Content-Type: text/plain

Hi,
	please find attached a patch to update the FarSync WAN driver in the
2.4 Kernel.  The driver has been updated in the following ways:

1) Provides support for new FarSync cards T1U, T2U, T4U and TE1
2) Provides support for an E1 interface
3) Provides support for a variant of X.21 that allows transmit and receive
clocks
4) Provide a raw socket interface directly to the data from the line.
5) Improves performance with less time in interrupts and more in BH's

In the main the only files affected are the farsync.c and farsync.h files,
although there have been some additions to the if.h file.

Please try to include it in the 2.4.25 release.

Never having submitted such a large patch before, let me know if there is
anything I should have done that I haven't.  But I think I remember a mail a
little while back asking for patches to be submitted through you?


Kind Regards

Kevin Curtis
Linux Development
FarSite Communications Ltd
http://www.farsite.co.uk
tel:  +44 1256 330461
fax:  +44 1256 854931


------_=_NextPart_000_01C3EB38.D1A7D900
Content-Type: application/octet-stream;
	name="farsync.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="farsync.patch"

diff -urN linux-2.4.25-orig/drivers/net/wan/farsync.c =
linux/drivers/net/wan/farsync.c=0A=
--- linux-2.4.25-orig/drivers/net/wan/farsync.c	2004-02-04 =
12:08:41.000000000 +0000=0A=
+++ linux/drivers/net/wan/farsync.c	2004-02-04 13:15:45.000000000 =
+0000=0A=
@@ -1,9 +1,9 @@=0A=
 /*=0A=
- *      FarSync X21 driver for Linux (generic HDLC version)=0A=
+ *      FarSync X21 driver for Linux (2.4.x kernel version)=0A=
  *=0A=
  *      Actually sync driver for X.21, V.35 and V.24 on FarSync =
T-series cards=0A=
  *=0A=
- *      Copyright (C) 2001 FarSite Communications Ltd.=0A=
+ *      Copyright (C) 2001-2002 FarSite Communications Ltd.=0A=
  *      www.farsite.co.uk=0A=
  *=0A=
  *      This program is free software; you can redistribute it =
and/or=0A=
@@ -11,17 +11,20 @@=0A=
  *      as published by the Free Software Foundation; either =
version=0A=
  *      2 of the License, or (at your option) any later version.=0A=
  *=0A=
- *      Author: R.J.Dunlop      <bob.dunlop@farsite.co.uk>=0A=
+ *      Author:      R.J.Dunlop    <bob.dunlop@farsite.co.uk>=0A=
+ *      Maintainer:  Kevin Curtis  <kevin.curtis@farsite.co.uk>=0A=
  */=0A=
 =0A=
 #include <linux/module.h>=0A=
 #include <linux/kernel.h>=0A=
+#include <linux/version.h>=0A=
 #include <linux/pci.h>=0A=
 #include <linux/ioport.h>=0A=
 #include <linux/init.h>=0A=
 #include <asm/uaccess.h>=0A=
 #include <linux/if.h>=0A=
 #include <linux/hdlc.h>=0A=
+#include <asm/delay.h>=0A=
 =0A=
 #include "farsync.h"=0A=
 =0A=
@@ -31,6 +34,11 @@=0A=
  */=0A=
 MODULE_AUTHOR("R.J.Dunlop <bob.dunlop@farsite.co.uk>");=0A=
 MODULE_DESCRIPTION("FarSync T-Series X21 driver. FarSite =
Communications Ltd.");=0A=
+MODULE_PARM (fst_txq_low, "i");=0A=
+MODULE_PARM (fst_txq_high, "i");=0A=
+MODULE_PARM (fst_max_reads, "i");=0A=
+MODULE_PARM (fst_excluded_cards, "i");=0A=
+MODULE_PARM (fst_excluded_list, "0-32i");=0A=
 MODULE_LICENSE("GPL");=0A=
 =0A=
 EXPORT_NO_SYMBOLS;=0A=
@@ -40,16 +48,21 @@=0A=
  *      =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
  */=0A=
 =0A=
-/*      Number of ports (per card) supported=0A=
+/*      Number of ports (per card) and cards supported=0A=
  */=0A=
 #define FST_MAX_PORTS           4=0A=
-=0A=
+#define FST_MAX_CARDS           32=0A=
 =0A=
 /*      PCI vendor and device IDs=0A=
  */=0A=
 #define FSC_PCI_VENDOR_ID       0x1619  /* FarSite Communications Ltd =
*/=0A=
 #define T2P_PCI_DEVICE_ID       0x0400  /* T2P X21 2 port card */=0A=
 #define T4P_PCI_DEVICE_ID       0x0440  /* T4P X21 4 port card */=0A=
+#define T1U_PCI_DEVICE_ID       0x0610  /* T1U X21 1 port card */=0A=
+#define T2U_PCI_DEVICE_ID       0x0620  /* T2U X21 2 port card */=0A=
+#define T4U_PCI_DEVICE_ID       0x0640  /* T4U X21 4 port card */=0A=
+#define TE1_PCI_DEVICE_ID       0x1610  /* TE1 X21 1 port card */=0A=
+#define TE1C_PCI_DEVICE_ID      0x1612  /* TE1 X21 1 port channelised =
*/=0A=
 =0A=
 =0A=
 /*      Default parameters for the link=0A=
@@ -59,6 +72,15 @@=0A=
                                          * this down assuming a slower =
line I=0A=
                                          * guess.=0A=
                                          */=0A=
+#define FST_TXQ_DEPTH           16      /* This one is for the =
buffering=0A=
+                                         * of frames on the way down =
to the card=0A=
+                                         * so that we can keep the =
card busy=0A=
+                                         * and maximise throughput=0A=
+					 */=0A=
+#define FST_HIGH_WATER_MARK     12      /* Point at which we flow =
control=0A=
+					 * network layer */=0A=
+#define FST_LOW_WATER_MARK      8       /* Point at which we remove =
flow=0A=
+					 * control from network layer */=0A=
 #define FST_MAX_MTU             8000    /* Huge but possible */=0A=
 #define FST_DEF_MTU             1500    /* Common sane value */=0A=
 =0A=
@@ -72,6 +94,15 @@=0A=
 #endif=0A=
 =0A=
 =0A=
+/*=0A=
+ * Modules parameters and associated varaibles=0A=
+ */=0A=
+int   fst_txq_low=3DFST_LOW_WATER_MARK;=0A=
+int   fst_txq_high=3DFST_HIGH_WATER_MARK;=0A=
+int   fst_max_reads=3D7;=0A=
+int   fst_excluded_cards=3D0;=0A=
+int   fst_excluded_list[FST_MAX_CARDS];=0A=
+=0A=
 /*      Card shared memory layout=0A=
  *      =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=0A=
  */=0A=
@@ -87,7 +118,7 @@=0A=
  *      be used to check that we have not got out of step with the =
firmware=0A=
  *      contained in the .CDE files.=0A=
  */=0A=
-#define SMC_VERSION 11=0A=
+#define SMC_VERSION 24=0A=
 =0A=
 #define FST_MEMSIZE 0x100000    /* Size of card memory (1Mb) */=0A=
 =0A=
@@ -161,7 +192,7 @@=0A=
 #define RX_ENP          0x01            /* Rx: end of packet */=0A=
 =0A=
 =0A=
-/* Interrupts from the card are caused by various events and these are =
presented=0A=
+/* Interrupts from the card are caused by various events which are =
presented=0A=
  * in a circular buffer as several events may be processed on one =
physical int=0A=
  */=0A=
 #define MAX_CIRBUFF     32=0A=
@@ -193,15 +224,59 @@=0A=
 #define TXC_UNDF        0x2A=0A=
 #define TXD_UNDF        0x2B=0A=
 =0A=
+#define F56_INT         0x2C=0A=
+#define M32_INT         0x2D=0A=
+=0A=
+#define TE1_ALMA        0x30=0A=
+=0A=
 =0A=
 /* Port physical configuration. See farsync.h for field values */=0A=
 struct port_cfg {=0A=
         u16  lineInterface;     /* Physical interface type */=0A=
         u8   x25op;             /* Unused at present */=0A=
         u8   internalClock;     /* 1 =3D> internal clock, 0 =3D> =
external */=0A=
+        u8   transparentMode;   /* 1 =3D> on, 0 =3D> off */=0A=
+        u8   invertClock;       /* 0 =3D> normal, 1 =3D> inverted =
*/=0A=
+        u8   padBytes[6];       /* Padding */=0A=
         u32  lineSpeed;         /* Speed in bps */=0A=
 };=0A=
 =0A=
+/* TE1 port physical configuration */=0A=
+struct su_config {=0A=
+        u32  dataRate;=0A=
+        u8   clocking;=0A=
+        u8   framing;=0A=
+        u8   structure;=0A=
+        u8   interface;=0A=
+        u8   coding;=0A=
+        u8   lineBuildOut;=0A=
+        u8   equalizer;=0A=
+        u8   transparentMode;=0A=
+        u8   loopMode;=0A=
+        u8   range;=0A=
+        u8   txBufferMode;=0A=
+        u8   rxBufferMode;=0A=
+        u8   startingSlot;=0A=
+        u8   losThreshold;=0A=
+        u8   enableIdleCode;=0A=
+        u8   idleCode;=0A=
+        u8   spare[44];=0A=
+};=0A=
+=0A=
+/* TE1 Status */=0A=
+struct su_status {=0A=
+        u32  receiveBufferDelay;=0A=
+        u32  framingErrorCount;=0A=
+        u32  codeViolationCount;=0A=
+        u32  crcErrorCount;=0A=
+        u32  lineAttenuation;=0A=
+        u8   portStarted;=0A=
+        u8   lossOfSignal;=0A=
+        u8   receiveRemoteAlarm;=0A=
+        u8   alarmIndicationSignal;=0A=
+        u8   spare[40];=0A=
+};=0A=
+=0A=
 /* Finally sling all the above together into the shared memory =
structure.=0A=
  * Sorry it's a hodge podge of arrays, structures and unused bits, =
it's been=0A=
  * evolving under NT for some time so I guess we're stuck with it.=0A=
@@ -259,14 +334,14 @@=0A=
         u16 portMailbox[FST_MAX_PORTS][2];      /* command, modifier =
*/=0A=
         u16 cardMailbox[4];                     /* Not used */=0A=
 =0A=
-                                /* Number of times that card thinks =
the host has=0A=
+                                /* Number of times the card thinks the =
host has=0A=
                                  * missed an interrupt by not =
acknowledging=0A=
                                  * within 2mS (I guess NT has =
problems)=0A=
                                  */=0A=
         u32 interruptRetryCount;=0A=
 =0A=
                                 /* Driver private data used as an ID. =
We'll not=0A=
-                                 * use this on Linux I'd rather keep =
such things=0A=
+                                 * use this as I'd rather keep such =
things=0A=
                                  * in main memory rather than on the =
PCI bus=0A=
                                  */=0A=
         u32 portHandle[FST_MAX_PORTS];=0A=
@@ -293,9 +368,12 @@=0A=
 =0A=
         u16 portScheduleOffset;=0A=
 =0A=
+        struct su_config suConfig;     /* TE1 Bits */=0A=
+        struct su_status suStatus;=0A=
+=0A=
         u32 endOfSmcSignature;  /* endOfSmcSignature MUST be the last =
member of=0A=
-                                 * the structure and marks the end of =
the shared=0A=
-                                 * memory. Adapter code initializes =
its value as=0A=
+                                 * the structure and marks the end of =
shared=0A=
+                                 * memory. Adapter code initializes it =
as=0A=
                                  * END_SIG.=0A=
                                  */=0A=
 };=0A=
@@ -312,6 +390,42 @@=0A=
 #define ABORTTX         5       /* Abort the transmitter for a port =
*/=0A=
 #define SETV24O         6       /* Set V24 outputs */=0A=
 =0A=
+/* PLX Chip Register Offsets */=0A=
+#define CNTRL_9052      0x50    /* Control Register */=0A=
+#define CNTRL_9054      0x6c    /* Control Register */=0A=
+=0A=
+#define PCIILR          0x3c    /* Interrupt Line Register */=0A=
+#define PCICR           0x04    /* Interrupt Control Register */=0A=
+#define INTCSR_9052     0x4c    /* Interrupt control/status register =
*/=0A=
+#define INTCSR_9054     0x68    /* Interrupt control/status register =
*/=0A=
+=0A=
+/* 9054 DMA Registers */=0A=
+/*=0A=
+ * Note that we will be using DMA Channel 0 for copying rx data=0A=
+ * and Channel 1 for copying tx data=0A=
+ */=0A=
+#define DMAMODE0        0x80=0A=
+#define DMAPADR0        0x84=0A=
+#define DMALADR0        0x88=0A=
+#define DMASIZ0         0x8c=0A=
+#define DMADPR0         0x90=0A=
+#define DMAMODE1        0x94=0A=
+#define DMAPADR1        0x98=0A=
+#define DMALADR1        0x9c=0A=
+#define DMASIZ1         0xa0=0A=
+#define DMADPR1         0xa4=0A=
+#define DMACSR0         0xa8=0A=
+#define DMACSR1         0xa9=0A=
+#define DMAARB          0xac=0A=
+#define DMATHR          0xb0=0A=
+#define DMADAC0         0xb4=0A=
+#define DMADAC1         0xb8=0A=
+#define DMAMARBR        0xac=0A=
+=0A=
+#define FST_MIN_DMA_LEN 64=0A=
+#define FST_RX_DMA_INT  0x01=0A=
+#define FST_TX_DMA_INT  0x02=0A=
+#define FST_CARD_INT    0x04=0A=
 =0A=
 /* Larger buffers are positioned in memory at offset BFM_BASE */=0A=
 struct buf_window {=0A=
@@ -336,10 +450,18 @@=0A=
         int                     index;  /* Port index on the card =
*/=0A=
         int                     hwif;   /* Line hardware =
(lineInterface copy) */=0A=
         int                     run;    /* Port is running */=0A=
+        int                     mode;    /* Normal or FarSync raw =
*/=0A=
         int                     rxpos;  /* Next Rx buffer to use */=0A=
         int                     txpos;  /* Next Tx buffer to use */=0A=
         int                     txipos; /* Next Tx buffer to check for =
free */=0A=
-        int                     txcnt;  /* Count of Tx buffers in use =
*/=0A=
+        int                     start;  /* Indication of start/stop to =
network */=0A=
+  /*=0A=
+   * A sixteen entry transmit queue=0A=
+   */=0A=
+        int                     txqs;  /* index to get next buffer to =
tx */=0A=
+        int                     txqe;  /* index to queue next packet =
*/=0A=
+        struct sk_buff         *txq[FST_TXQ_DEPTH]; /* The queue */=0A=
+        int                     rxqdepth;=0A=
 };=0A=
 =0A=
 /*      Per card information=0A=
@@ -357,6 +479,24 @@=0A=
         unsigned short pci_conf;        /* PCI card config in I/O =
space */=0A=
                                         /* Per port info */=0A=
         struct fst_port_info ports[ FST_MAX_PORTS ];=0A=
+        struct pci_dev *device;         /* Information about the pci =
device */=0A=
+        int            card_no;         /* Inst of the card on the =
system */=0A=
+        int            family;          /* TxP or TxU */=0A=
+        int            dmarx_in_progress;=0A=
+        int            dmatx_in_progress;=0A=
+        unsigned long  int_count;=0A=
+        unsigned long  int_time_ave;=0A=
+	void          *rx_dma_handle_host;=0A=
+	dma_addr_t     rx_dma_handle_card;  =0A=
+	void          *tx_dma_handle_host;=0A=
+	dma_addr_t     tx_dma_handle_card;  =0A=
+        struct sk_buff *dma_skb_rx;=0A=
+        struct fst_port_info *dma_port_rx;=0A=
+        struct fst_port_info *dma_port_tx;=0A=
+        int            dma_len_rx;=0A=
+        int            dma_len_tx;=0A=
+        int            dma_txpos;=0A=
+        int            dma_rxpos;=0A=
 };=0A=
 =0A=
 /* Convert an HDLC device pointer into a port info pointer and similar =
*/=0A=
@@ -403,7 +543,7 @@=0A=
                                 printk ( KERN_DEBUG FST_NAME ": " fmt, =
## A )=0A=
 =0A=
 #else=0A=
-# define dbg(X...)      /* NOP */=0A=
+#define dbg(X...)      /* NOP */=0A=
 #endif=0A=
 =0A=
 =0A=
@@ -422,12 +562,131 @@=0A=
                                         FST_TYPE_T2P },=0A=
         { FSC_PCI_VENDOR_ID, T4P_PCI_DEVICE_ID, PCI_ANY_ID, =
PCI_ANY_ID, 0, 0,=0A=
                                         FST_TYPE_T4P },=0A=
+        { FSC_PCI_VENDOR_ID, T1U_PCI_DEVICE_ID, PCI_ANY_ID, =
PCI_ANY_ID, 0, 0,=0A=
+                                        FST_TYPE_T1U },=0A=
+        { FSC_PCI_VENDOR_ID, T2U_PCI_DEVICE_ID, PCI_ANY_ID, =
PCI_ANY_ID, 0, 0,=0A=
+                                        FST_TYPE_T2U },=0A=
+        { FSC_PCI_VENDOR_ID, T4U_PCI_DEVICE_ID, PCI_ANY_ID, =
PCI_ANY_ID, 0, 0,=0A=
+                                        FST_TYPE_T4U },=0A=
+        { FSC_PCI_VENDOR_ID, TE1_PCI_DEVICE_ID, PCI_ANY_ID, =
PCI_ANY_ID, 0, 0,=0A=
+                                        FST_TYPE_TE1 },=0A=
+        { FSC_PCI_VENDOR_ID, TE1C_PCI_DEVICE_ID, PCI_ANY_ID, =
PCI_ANY_ID, 0, 0,=0A=
+                                        FST_TYPE_TE1 },=0A=
         { 0, }                          /* End */=0A=
 };=0A=
 =0A=
 MODULE_DEVICE_TABLE ( pci, fst_pci_dev_id );=0A=
 =0A=
 =0A=
+/*=0A=
+ *      Device Driver Work Queues=0A=
+ *=0A=
+ *      So that we don't spend too much time processing events in the =
=0A=
+ *      Interrupt Service routine, we will declare a work queue per =
Card =0A=
+ *      and make the ISR schedule a task in the queue for later =
execution.=0A=
+ */=0A=
+=0A=
+static void do_bottom_half_tx (struct fst_card_info *card);=0A=
+static void do_bottom_half_rx (struct fst_card_info *card);=0A=
+=0A=
+struct tq_struct      fst_int_task;=0A=
+struct tq_struct      fst_tx_task;=0A=
+struct fst_card_info *fst_card_array[FST_MAX_CARDS];=0A=
+spinlock_t            fst_work_q_lock;=0A=
+u64                   fst_work_txq;=0A=
+u64                   fst_work_intq;=0A=
+=0A=
+static void=0A=
+fst_q_work_item (u64 *queue, int card_index)=0A=
+{=0A=
+  unsigned long  flags;=0A=
+  u64            mask;=0A=
+=0A=
+  /*=0A=
+   * Grab the queue exclusively=0A=
+   */=0A=
+  spin_lock_irqsave(&fst_work_q_lock, flags);=0A=
+=0A=
+  /*=0A=
+   * Making an entry in the queue is simply a matter of setting=0A=
+   * a bit for the card indicating that there is work to do in the=0A=
+   * bottom half for the card.  Note the limitation of 64 cards.=0A=
+   * That ought to be enough=0A=
+   */=0A=
+  mask =3D 1 << card_index;=0A=
+  *queue |=3D mask; =0A=
+  spin_unlock_irqrestore(&fst_work_q_lock, flags);=0A=
+}=0A=
+=0A=
+=0A=
+static void=0A=
+fst_process_tx_work_q ( void *work_q)=0A=
+{=0A=
+  unsigned long  flags;=0A=
+  u64            work_txq;=0A=
+  int            i;=0A=
+=0A=
+  /*=0A=
+   * Grab the queue exclusively=0A=
+   */=0A=
+  dbg(DBG_TX, "fst_process_tx_work_q\n");=0A=
+  spin_lock_irqsave(&fst_work_q_lock, flags);=0A=
+  work_txq =3D fst_work_txq;=0A=
+  fst_work_txq =3D 0;=0A=
+  spin_unlock_irqrestore(&fst_work_q_lock, flags);=0A=
+=0A=
+  /*=0A=
+   * Call the bottom half for each card with work waiting=0A=
+   */=0A=
+  for (i=3D0; i<FST_MAX_CARDS; i++)=0A=
+    {=0A=
+      if (work_txq & 0x01)=0A=
+        {=0A=
+          if (fst_card_array[i] !=3D NULL)=0A=
+            {=0A=
+              dbg(DBG_TX, "Calling tx bh for card %d\n", i);=0A=
+              do_bottom_half_tx(fst_card_array[i]);=0A=
+            }=0A=
+        }=0A=
+      work_txq =3D work_txq>>1;=0A=
+    }=0A=
+}=0A=
+=0A=
+static void=0A=
+fst_process_int_work_q ( void *work_q)=0A=
+{=0A=
+  unsigned long  flags;=0A=
+  u64            work_intq;=0A=
+  int            i;=0A=
+=0A=
+  /*=0A=
+   * Grab the queue exclusively=0A=
+   */=0A=
+  dbg(DBG_INTR, "fst_process_int_work_q\n");=0A=
+  spin_lock_irqsave(&fst_work_q_lock, flags);=0A=
+  work_intq =3D fst_work_intq;=0A=
+  fst_work_intq =3D 0;=0A=
+  spin_unlock_irqrestore(&fst_work_q_lock, flags);=0A=
+=0A=
+  /*=0A=
+   * Call the bottom half for each card with work waiting=0A=
+   */=0A=
+  for (i=3D0; i<FST_MAX_CARDS; i++)=0A=
+    {=0A=
+      if (work_intq & 0x01)=0A=
+        {=0A=
+          if (fst_card_array[i] !=3D NULL)=0A=
+            {=0A=
+              dbg(DBG_INTR,"Calling rx & tx bh for card %d\n", i);=0A=
+              do_bottom_half_rx(fst_card_array[i]);=0A=
+              do_bottom_half_tx(fst_card_array[i]);=0A=
+            }=0A=
+        }=0A=
+      work_intq =3D work_intq>>1;=0A=
+    }=0A=
+}=0A=
+=0A=
+=0A=
 /*      Card control functions=0A=
  *      =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
  */=0A=
@@ -436,17 +695,55 @@=0A=
  * Used to be a simple write to card control space but a glitch in the =
latest=0A=
  * AMD Am186CH processor means that we now have to do it by asserting =
and de-=0A=
  * asserting the PLX chip PCI Adapter Software Reset. Bit 30 in CNTRL =
register=0A=
- * at offset 0x50.=0A=
+ * at offset 9052_CNTRL.  Note the updates for the TXU.=0A=
  */=0A=
 static inline void=0A=
 fst_cpureset ( struct fst_card_info *card )=0A=
 {=0A=
+        unsigned char interrupt_line_register;=0A=
+	unsigned long j =3D jiffies + 1;=0A=
         unsigned int regval;=0A=
 =0A=
-        regval =3D inl ( card->pci_conf + 0x50 );=0A=
-=0A=
-        outl ( regval |  0x40000000, card->pci_conf + 0x50 );=0A=
-        outl ( regval & ~0x40000000, card->pci_conf + 0x50 );=0A=
+ 	if (card->family =3D=3D FST_FAMILY_TXU)=0A=
+	  {=0A=
+	    if (pci_read_config_byte(card->device, PCIILR, =
&interrupt_line_register))=0A=
+	      {=0A=
+		dbg (DBG_ASS, "Error in reading interrupt line register\n");=0A=
+	      }=0A=
+	    /*=0A=
+	     * Assert PLX software reset and Am186 hardware reset=0A=
+	     * and then deassert the PLX software reset but 186 still in =
reset=0A=
+	     */=0A=
+	    outw ( 0x440f, card->pci_conf + CNTRL_9054 + 2 );=0A=
+	    outw ( 0x040f, card->pci_conf + CNTRL_9054 + 2 );=0A=
+	    /*=0A=
+	     * We are delaying here to allow the 9054 to reset itself=0A=
+	     */=0A=
+	    j =3D jiffies + 1;=0A=
+	    while (jiffies < j)=0A=
+	      /* Do nothing */;=0A=
+	    outw ( 0x240f, card->pci_conf + CNTRL_9054 + 2 );=0A=
+	    /*=0A=
+	     * We are delaying here to allow the 9054 to reload its eeprom=0A=
+	     */=0A=
+	    j =3D jiffies + 1;=0A=
+	    while (jiffies < j)=0A=
+	      /* Do nothing */;=0A=
+	    outw ( 0x040f, card->pci_conf + CNTRL_9054 + 2 );=0A=
+	    =0A=
+	    if (pci_write_config_byte(card->device, PCIILR, =
interrupt_line_register))=0A=
+	      {=0A=
+		dbg (DBG_ASS, "Error in writing interrupt line register\n");=0A=
+	      }=0A=
+	    =0A=
+	  }=0A=
+	else=0A=
+	  {=0A=
+	    regval =3D inl ( card->pci_conf + CNTRL_9052 );=0A=
+=0A=
+	    outl ( regval |  0x40000000, card->pci_conf + CNTRL_9052 );=0A=
+	    outl ( regval & ~0x40000000, card->pci_conf + CNTRL_9052 );=0A=
+	  }=0A=
 }=0A=
 =0A=
 /*      Release the processor from reset=0A=
@@ -454,7 +751,24 @@=0A=
 static inline void=0A=
 fst_cpurelease ( struct fst_card_info *card )=0A=
 {=0A=
-        (void) readb ( card->ctlmem );=0A=
+	if (card->family =3D=3D FST_FAMILY_TXU)=0A=
+	  {=0A=
+	    /*=0A=
+	     * Force posted writes to complete=0A=
+	     */=0A=
+	    (void) readb (card->mem);=0A=
+=0A=
+	    /*=0A=
+	     * Release LRESET DO =3D 1=0A=
+	     * Then release Local Hold, DO =3D 1=0A=
+	     */=0A=
+	    outw ( 0x040e, card->pci_conf + CNTRL_9054 + 2 );=0A=
+	    outw ( 0x040f, card->pci_conf + CNTRL_9054 + 2 );=0A=
+	  }=0A=
+	else=0A=
+	  {=0A=
+	    (void) readb ( card->ctlmem );=0A=
+	  }=0A=
 }=0A=
 =0A=
 /*      Clear the cards interrupt flag=0A=
@@ -462,9 +776,31 @@=0A=
 static inline void=0A=
 fst_clear_intr ( struct fst_card_info *card )=0A=
 {=0A=
-        /* Poke the appropriate PLX chip register (same as enabling =
interrupts)=0A=
-         */=0A=
-        outw ( 0x0543, card->pci_conf + 0x4C );=0A=
+	if (card->family =3D=3D FST_FAMILY_TXU)=0A=
+	  {=0A=
+	    (void) readb ( card->ctlmem );=0A=
+	  }=0A=
+	else=0A=
+	  {=0A=
+	    /* Poke the appropriate PLX chip register (same as enabling =
interrupts)=0A=
+	     */=0A=
+	    outw ( 0x0543, card->pci_conf + INTCSR_9052 );=0A=
+	  }=0A=
+}=0A=
+=0A=
+/*      Enable card interrupts=0A=
+ */=0A=
+static inline void=0A=
+fst_enable_intr ( struct fst_card_info *card )=0A=
+{=0A=
+	if (card->family =3D=3D FST_FAMILY_TXU)=0A=
+	  {=0A=
+	    outl ( 0x0f0c0900, card->pci_conf + INTCSR_9054 );=0A=
+	  }=0A=
+	else=0A=
+	  {=0A=
+	    outw ( 0x0543, card->pci_conf + INTCSR_9052 );=0A=
+	  }=0A=
 }=0A=
 =0A=
 /*      Disable card interrupts=0A=
@@ -472,7 +808,196 @@=0A=
 static inline void=0A=
 fst_disable_intr ( struct fst_card_info *card )=0A=
 {=0A=
-        outw ( 0x0000, card->pci_conf + 0x4C );=0A=
+	if (card->family =3D=3D FST_FAMILY_TXU)=0A=
+	  {=0A=
+	    outl ( 0x00000000, card->pci_conf + INTCSR_9054 );=0A=
+	  }=0A=
+	else=0A=
+	  {=0A=
+	    outw ( 0x0000, card->pci_conf + INTCSR_9052 );=0A=
+	  }=0A=
+}=0A=
+=0A=
+/*      Process the result of trying to pass a recieved frame up the =
stack=0A=
+ */=0A=
+static void fst_process_rx_status ( int rx_status , char *name)=0A=
+{=0A=
+  switch (rx_status)=0A=
+    {=0A=
+    case NET_RX_SUCCESS:=0A=
+      {=0A=
+	/*=0A=
+	 * Nothing to do here=0A=
+	 */=0A=
+	break;=0A=
+      }=0A=
+=0A=
+    case NET_RX_CN_LOW:=0A=
+      {=0A=
+	printk_warn("%s: Receive Low Congestion\n", name);=0A=
+	break;=0A=
+      }=0A=
+=0A=
+    case NET_RX_CN_MOD:=0A=
+      {=0A=
+	printk_warn("%s: Receive Moderate Congestion\n", name);=0A=
+	break;=0A=
+      }=0A=
+=0A=
+    case NET_RX_CN_HIGH:=0A=
+      {=0A=
+	printk_warn("%s: Receive High Congestion\n", name);=0A=
+	break;=0A=
+      }=0A=
+=0A=
+    case NET_RX_DROP:=0A=
+      {=0A=
+	printk_err("%s: Received packet dropped\n", name);=0A=
+	break;=0A=
+      }=0A=
+    }=0A=
+}=0A=
+=0A=
+=0A=
+/*      Initilaise DMA for PLX 9054=0A=
+ */=0A=
+static inline void=0A=
+fst_init_dma ( struct fst_card_info *card )=0A=
+{=0A=
+  unsigned short pci_cr;=0A=
+=0A=
+  /*=0A=
+   * This is only required for the PLX 9054=0A=
+   */=0A=
+  if (card->family =3D=3D FST_FAMILY_TXU)=0A=
+    {=0A=
+      pci_read_config_word (card->device, PCICR, &pci_cr);=0A=
+      pci_cr |=3D 0x0004;=0A=
+      pci_write_config_word (card->device, PCICR, pci_cr);  /* Enable =
DMA Bus mastering */=0A=
+      outl ( 0x00020441, card->pci_conf + DMAMODE0 );=0A=
+      outl ( 0x00020441, card->pci_conf + DMAMODE1 );=0A=
+      outl ( 0x0, card->pci_conf + DMATHR );=0A=
+    }=0A=
+}=0A=
+=0A=
+=0A=
+/*      Tx dma complete interrupt=0A=
+ */=0A=
+static void=0A=
+fst_tx_dma_complete ( struct fst_card_info *card, struct fst_port_info =
*port, =0A=
+		      int len, int txpos)=0A=
+{=0A=
+	/*=0A=
+	 * Everything is now set, just tell the card to go=0A=
+	 */=0A=
+        dbg(DBG_TX, "fst_tx_dma_complete\n");=0A=
+	FST_WRB ( card, txDescrRing[port->index][txpos].bits, =0A=
+		  DMA_OWN | TX_STP | TX_ENP );=0A=
+	port->hdlc.stats.tx_packets++;=0A=
+	port->hdlc.stats.tx_bytes +=3D len;=0A=
+	port_to_dev(port)->trans_start =3D jiffies;=0A=
+}=0A=
+=0A=
+/*      Rx dma complete interrupt=0A=
+ */=0A=
+static void=0A=
+fst_rx_dma_complete ( struct fst_card_info *card, struct fst_port_info =
*port,=0A=
+		      int len, struct sk_buff *skb, int rxp)=0A=
+{=0A=
+    =0A=
+        int pi;=0A=
+	int rx_status;=0A=
+=0A=
+        dbg(DBG_TX, "fst_rx_dma_complete\n");=0A=
+	pi =3D port->index;=0A=
+	memcpy(skb_put(skb, len), card->rx_dma_handle_host, len);=0A=
+=0A=
+	/* Reset buffer descriptor */=0A=
+        FST_WRB ( card, rxDescrRing[pi][rxp].bits, DMA_OWN );=0A=
+=0A=
+        /* Update stats */=0A=
+        port->hdlc.stats.rx_packets++;=0A=
+        port->hdlc.stats.rx_bytes +=3D len;=0A=
+=0A=
+        /* Push upstream */=0A=
+        dbg(DBG_RX, "Pushing the frame up the stack\n");=0A=
+        skb->mac.raw =3D skb->data;=0A=
+        skb->dev =3D hdlc_to_dev(&port->hdlc);=0A=
+        if (port->mode =3D=3D FST_RAW)=0A=
+          {=0A=
+            /*=0A=
+             * Mark it for our own raw sockets interface=0A=
+             */=0A=
+            skb->protocol =3D htons (ETH_P_CUST);=0A=
+            skb->pkt_type =3D PACKET_HOST;=0A=
+          }=0A=
+        else=0A=
+          {=0A=
+            skb->protocol =3D hdlc_type_trans (skb, skb->dev);=0A=
+          }=0A=
+        rx_status =3D netif_rx ( skb );=0A=
+        fst_process_rx_status(rx_status, port_to_dev(port)->name);=0A=
+        if (rx_status =3D=3D NET_RX_DROP)=0A=
+          port->hdlc.stats.rx_dropped++;=0A=
+	port_to_dev(port)->last_rx =3D jiffies;=0A=
+}=0A=
+=0A=
+/*=0A=
+ *      Receive a frame through the DMA=0A=
+ */=0A=
+static inline void=0A=
+fst_rx_dma (struct fst_card_info *card, unsigned char *skb, =0A=
+	    unsigned char *mem, int len)=0A=
+{=0A=
+  /*=0A=
+   * This routine will setup the DMA and start it=0A=
+   */=0A=
+=0A=
+  dbg(DBG_RX, "In fst_rx_dma %p %p %d\n", skb, mem, len);=0A=
+  if (card->dmarx_in_progress)=0A=
+    {=0A=
+      dbg(DBG_ASS, "In fst_rx_dma while dma in progress\n");=0A=
+    }=0A=
+=0A=
+  outl ( (unsigned long)skb, card->pci_conf + DMAPADR0 );   /* Copy to =
here */=0A=
+  outl ( (unsigned long)mem, card->pci_conf + DMALADR0 );   /* from =
here */=0A=
+  outl ( len, card->pci_conf + DMASIZ0 );       /* for this length =
*/=0A=
+  outl ( 0x00000000c, card->pci_conf + DMADPR0); /* In this direction =
*/=0A=
+=0A=
+  /*=0A=
+   * We use the dmarx_in_progress flag to flag the channel as busy=0A=
+   */=0A=
+  card->dmarx_in_progress =3D 1;=0A=
+  outb ( 0x03, card->pci_conf + DMACSR0 );     /* Start the transfer =
*/=0A=
+}=0A=
+=0A=
+/*=0A=
+ *      Send a frame through the DMA=0A=
+ */=0A=
+static inline void=0A=
+fst_tx_dma (struct fst_card_info *card, unsigned char *skb, =0A=
+	    unsigned char *mem, int len)=0A=
+{=0A=
+  /*=0A=
+   * This routine will setup the DMA and start it.=0A=
+   */=0A=
+=0A=
+  dbg(DBG_TX, "In fst_tx_dma %p %p %d\n", skb, mem, len);=0A=
+  if (card->dmatx_in_progress)=0A=
+    {=0A=
+      dbg(DBG_ASS, "In fst_tx_dma while dma in progress\n");=0A=
+    }=0A=
+=0A=
+  outl ( (unsigned long)skb, card->pci_conf + DMAPADR1 );  /* Copy =
from here */=0A=
+  outl ( (unsigned long)mem, card->pci_conf + DMALADR1 );  /* to here =
*/=0A=
+  outl ( len, card->pci_conf + DMASIZ1 );       /* for this length =
*/=0A=
+  outl ( 0x000000004, card->pci_conf + DMADPR1); /* In this direction =
*/=0A=
+=0A=
+  /*=0A=
+   * We use the dmatx_in_progress to flag the channel as busy=0A=
+   */=0A=
+  card->dmatx_in_progress =3D 1;=0A=
+  outb ( 0x03, card->pci_conf + DMACSR1 );     /* Start the transfer =
*/=0A=
 }=0A=
 =0A=
 =0A=
@@ -496,11 +1021,11 @@=0A=
         /* Wait for any previous command to complete */=0A=
         while ( mbval > NAK )=0A=
         {=0A=
-                spin_unlock_irqrestore ( &card->card_lock, flags );=0A=
+	        spin_unlock_irqrestore ( &card->card_lock, flags );=0A=
                 schedule_timeout ( 1 );=0A=
                 spin_lock_irqsave ( &card->card_lock, flags );=0A=
 =0A=
-                if ( ++safety > 1000 )=0A=
+                if ( ++safety > 2000 )=0A=
                 {=0A=
                         printk_err ("Mailbox safety timeout\n");=0A=
                         break;=0A=
@@ -523,7 +1048,7 @@=0A=
         {=0A=
                 port->txpos  =3D 0;=0A=
                 port->txipos =3D 0;=0A=
-                port->txcnt  =3D 0;=0A=
+                port->start  =3D 0;=0A=
         }=0A=
 =0A=
         spin_unlock_irqrestore ( &card->card_lock, flags );=0A=
@@ -576,7 +1101,7 @@=0A=
                 FST_WRB ( card, rxDescrRing[pi][i].hadr, (u8)( offset =
>> 16 ));=0A=
                 FST_WRW ( card, rxDescrRing[pi][i].bcnt,=0A=
                                         cnv_bcnt ( LEN_RX_BUFFER =
));=0A=
-                FST_WRW ( card, rxDescrRing[pi][i].mcnt, 0 );=0A=
+                FST_WRW ( card, rxDescrRing[pi][i].mcnt, LEN_RX_BUFFER =
);=0A=
                 FST_WRB ( card, rxDescrRing[pi][i].bits, DMA_OWN );=0A=
         }=0A=
         port->rxpos  =3D 0;=0A=
@@ -610,11 +1135,63 @@=0A=
         }=0A=
         port->txpos  =3D 0;=0A=
         port->txipos =3D 0;=0A=
-        port->txcnt  =3D 0;=0A=
+        port->start  =3D 0;=0A=
         spin_unlock_irqrestore ( &card->card_lock, flags );=0A=
 }=0A=
 =0A=
 =0A=
+/*      TE1 Alarm change interrupt event=0A=
+ */=0A=
+static void=0A=
+fst_intr_te1_alarm ( struct fst_card_info *card, struct fst_port_info =
*port )=0A=
+{=0A=
+  u8 los;=0A=
+  u8 rra;=0A=
+  u8 ais;=0A=
+=0A=
+  los =3D FST_RDB ( card, suStatus.lossOfSignal );=0A=
+  rra =3D FST_RDB ( card, suStatus.receiveRemoteAlarm );=0A=
+  ais =3D FST_RDB ( card, suStatus.alarmIndicationSignal );=0A=
+=0A=
+  if ( los )=0A=
+    {=0A=
+      /*=0A=
+       * Lost the link=0A=
+       */=0A=
+      if (netif_carrier_ok(port_to_dev(port)))=0A=
+        {=0A=
+          dbg ( DBG_INTR,"Net carrier off\n");=0A=
+          netif_carrier_off(port_to_dev(port));=0A=
+        }    =0A=
+    }=0A=
+  else=0A=
+    {=0A=
+      /*=0A=
+       * Link available=0A=
+       */=0A=
+      if ( ! netif_carrier_ok(port_to_dev(port)))=0A=
+        {=0A=
+          dbg ( DBG_INTR,"Net carrier on\n");  =0A=
+          netif_carrier_on(port_to_dev(port));=0A=
+        }=0A=
+    }=0A=
+=0A=
+  if (los)=0A=
+    dbg (DBG_INTR, "Assert LOS Alarm\n");=0A=
+  else=0A=
+    dbg (DBG_INTR, "De-assert LOS Alarm\n");=0A=
+  if (rra)=0A=
+    dbg (DBG_INTR, "Assert RRA Alarm\n");=0A=
+  else=0A=
+    dbg (DBG_INTR, "De-assert RRA Alarm\n");=0A=
+=0A=
+  if (ais)=0A=
+    dbg (DBG_INTR, "Assert AIS Alarm\n");=0A=
+  else=0A=
+    dbg (DBG_INTR, "De-assert AIS Alarm\n");=0A=
+}=0A=
+=0A=
+=0A=
 /*      Control signal change interrupt event=0A=
  */=0A=
 static void=0A=
@@ -624,7 +1201,8 @@=0A=
 =0A=
         signals =3D FST_RDL ( card, v24DebouncedSts[port->index]);=0A=
 =0A=
-        if ( signals & (( port->hwif =3D=3D X21 ) ? IPSTS_INDICATE : =
IPSTS_DCD ))=0A=
+        if ( signals & (((port->hwif =3D=3D X21) || (port->hwif =3D=3D =
X21D)) =0A=
+			? IPSTS_INDICATE : IPSTS_DCD ))=0A=
         {=0A=
                 if ( ! netif_carrier_ok ( port_to_dev ( port )))=0A=
                 {=0A=
@@ -642,6 +1220,86 @@=0A=
         }=0A=
 }=0A=
 =0A=
+/*      Log Rx Errors=0A=
+ */=0A=
+static void=0A=
+fst_log_rx_error ( struct fst_card_info *card, struct fst_port_info =
*port,=0A=
+		   unsigned char dmabits, int rxp, unsigned short len)=0A=
+{=0A=
+        /* =0A=
+	 * Increment the appropriate error counter=0A=
+	 */=0A=
+         port->hdlc.stats.rx_errors++;=0A=
+         if ( dmabits & RX_OFLO )=0A=
+           {=0A=
+             port->hdlc.stats.rx_fifo_errors++;=0A=
+	     dbg(DBG_ASS, "Rx fifo error on card %d port %d buffer %d\n", =0A=
+		 card->card_no, port->index, rxp);=0A=
+            }=0A=
+          if ( dmabits & RX_CRC )=0A=
+            {=0A=
+              port->hdlc.stats.rx_crc_errors++;=0A=
+	      dbg(DBG_ASS, "Rx crc error on card %d port %d\n",=0A=
+		  card->card_no, port->index);=0A=
+            }=0A=
+          if ( dmabits & RX_FRAM )=0A=
+            {=0A=
+              port->hdlc.stats.rx_frame_errors++;=0A=
+	      dbg(DBG_ASS, "Rx frame error on card %d port %d\n",=0A=
+		  card->card_no, port->index);=0A=
+            }=0A=
+          if ( dmabits =3D=3D ( RX_STP | RX_ENP ))=0A=
+            {=0A=
+              port->hdlc.stats.rx_length_errors++;=0A=
+	      dbg(DBG_ASS, "Rx length error (%d) on card %d port %d\n", =0A=
+	          len,card->card_no, port->index);=0A=
+            }=0A=
+}=0A=
+=0A=
+/*      Rx Error Recovery=0A=
+ */=0A=
+static void=0A=
+fst_recover_rx_error ( struct fst_card_info *card, struct =
fst_port_info *port,=0A=
+		   unsigned char dmabits, int rxp, unsigned short len)=0A=
+{=0A=
+        int i;=0A=
+	int pi;=0A=
+=0A=
+        pi  =3D port->index;=0A=
+	/* =0A=
+	 * Discard buffer descriptors until we see the start of the=0A=
+	 * next frame.  Note that for long frames this could be in=0A=
+	 * a subsequent interrupt. =0A=
+	 */=0A=
+	i =3D 0;=0A=
+	while (( dmabits & ( DMA_OWN | RX_STP )) =3D=3D 0 )=0A=
+	  {=0A=
+	    FST_WRB ( card, rxDescrRing[pi][rxp].bits, DMA_OWN );=0A=
+	    if ( ++rxp >=3D NUM_RX_BUFFER )=0A=
+	      rxp =3D 0;=0A=
+	    if ( ++i > NUM_RX_BUFFER )=0A=
+	      {=0A=
+		dbg ( DBG_ASS,"intr_rx: Discarding more bufs"=0A=
+		      " than we have\n");=0A=
+		break;=0A=
+	      }=0A=
+	    dmabits =3D FST_RDB ( card, rxDescrRing[pi][rxp].bits );=0A=
+	    dbg(DBG_ASS, "DMA Bits of next buffer was %x\n", dmabits);=0A=
+	  }=0A=
+	dbg(DBG_ASS, "There were %d subsequent buffers in error\n", i);=0A=
+	=0A=
+	/* Discard the terminal buffer */=0A=
+	if ( ! ( dmabits & DMA_OWN ))=0A=
+	  {=0A=
+	    FST_WRB ( card, rxDescrRing[pi][rxp].bits, DMA_OWN );=0A=
+	    if ( ++rxp >=3D NUM_RX_BUFFER )=0A=
+	      rxp =3D 0;=0A=
+	  }=0A=
+	port->rxpos =3D rxp;=0A=
+	return;=0A=
+	=0A=
+}=0A=
+=0A=
 =0A=
 /*      Rx complete interrupt=0A=
  */=0A=
@@ -651,10 +1309,9 @@=0A=
         unsigned char dmabits;=0A=
         int pi;=0A=
         int rxp;=0A=
+	int rx_status;=0A=
         unsigned short len;=0A=
         struct sk_buff *skb;=0A=
-        int i;=0A=
-=0A=
 =0A=
         /* Check we have a buffer to process */=0A=
         pi  =3D port->index;=0A=
@@ -666,11 +1323,32 @@=0A=
                                         pi, rxp );=0A=
                 return;=0A=
         }=0A=
+	if (card->dmarx_in_progress)=0A=
+	{=0A=
+	        return;=0A=
+	}=0A=
 =0A=
         /* Get buffer length */=0A=
         len =3D FST_RDW ( card, rxDescrRing[pi][rxp].mcnt );=0A=
         /* Discard the CRC */=0A=
         len -=3D 2;=0A=
+	if (len =3D=3D 0)=0A=
+	  {=0A=
+	    /*=0A=
+	     * This seems to happen on the TE1 interface sometimes=0A=
+	     * so throw the frame away and log the event.=0A=
+	     */=0A=
+	    printk_err("Frame received with 0 length. Card %d Port %d\n",=0A=
+		        card->card_no, port->index);=0A=
+	    /* Return descriptor to card */=0A=
+	    FST_WRB ( card, rxDescrRing[pi][rxp].bits, DMA_OWN );=0A=
+	    =0A=
+	    if ( ++rxp >=3D NUM_RX_BUFFER )=0A=
+	      port->rxpos =3D 0;=0A=
+	    else=0A=
+	      port->rxpos =3D rxp;=0A=
+	    return;=0A=
+	  }=0A=
 =0A=
         /* Check buffer length and for other errors. We insist on one =
packet=0A=
          * in one buffer. This simplifies things greatly and since =
we've=0A=
@@ -680,53 +1358,9 @@=0A=
                                         len );=0A=
         if ( dmabits !=3D ( RX_STP | RX_ENP ) || len > LEN_RX_BUFFER - =
2 )=0A=
         {=0A=
-                port->hdlc.stats.rx_errors++;=0A=
-=0A=
-                /* Update error stats and discard buffer */=0A=
-                if ( dmabits & RX_OFLO )=0A=
-                {=0A=
-                        port->hdlc.stats.rx_fifo_errors++;=0A=
-                }=0A=
-                if ( dmabits & RX_CRC )=0A=
-                {=0A=
-                        port->hdlc.stats.rx_crc_errors++;=0A=
-                }=0A=
-                if ( dmabits & RX_FRAM )=0A=
-                {=0A=
-                        port->hdlc.stats.rx_frame_errors++;=0A=
-                }=0A=
-                if ( dmabits =3D=3D ( RX_STP | RX_ENP ))=0A=
-                {=0A=
-                        port->hdlc.stats.rx_length_errors++;=0A=
-                }=0A=
-=0A=
-                /* Discard buffer descriptors until we see the end of =
packet=0A=
-                 * marker=0A=
-                 */=0A=
-                i =3D 0;=0A=
-                while (( dmabits & ( DMA_OWN | RX_ENP )) =3D=3D 0 )=0A=
-                {=0A=
-                        FST_WRB ( card, rxDescrRing[pi][rxp].bits, =
DMA_OWN );=0A=
-                        if ( ++rxp >=3D NUM_RX_BUFFER )=0A=
-                                rxp =3D 0;=0A=
-                        if ( ++i > NUM_RX_BUFFER )=0A=
-                        {=0A=
-                                dbg ( DBG_ASS,"intr_rx: Discarding =
more bufs"=0A=
-                                                " than we have\n");=0A=
-                                break;=0A=
-                        }=0A=
-                        dmabits =3D FST_RDB ( card, =
rxDescrRing[pi][rxp].bits );=0A=
-                }=0A=
-=0A=
-                /* Discard the terminal buffer */=0A=
-                if ( ! ( dmabits & DMA_OWN ))=0A=
-                {=0A=
-                        FST_WRB ( card, rxDescrRing[pi][rxp].bits, =
DMA_OWN );=0A=
-                        if ( ++rxp >=3D NUM_RX_BUFFER )=0A=
-                                rxp =3D 0;=0A=
-                }=0A=
-                port->rxpos =3D rxp;=0A=
-                return;=0A=
+	     fst_log_rx_error(card, port, dmabits, rxp, len);=0A=
+	     fst_recover_rx_error(card, port, dmabits, rxp, len);=0A=
+	     return;=0A=
         }=0A=
 =0A=
         /* Allocate SKB */=0A=
@@ -746,28 +1380,210 @@=0A=
                 return;=0A=
         }=0A=
 =0A=
-        memcpy_fromio ( skb_put ( skb, len ),=0A=
-                                card->mem + BUF_OFFSET ( =
rxBuffer[pi][rxp][0]),=0A=
-                                len );=0A=
+	/*=0A=
+	 * We know the length we need to receive, len.=0A=
+	 * It's not worth using the DMA for reads of less than=0A=
+	 * FST_MIN_DMA_LEN=0A=
+	 */=0A=
+=0A=
+	if ((len < FST_MIN_DMA_LEN) || (card->family =3D=3D =
FST_FAMILY_TXP))=0A=
+	  {=0A=
+		memcpy_fromio ( skb_put ( skb, len ),=0A=
+				card->mem + BUF_OFFSET ( rxBuffer[pi][rxp][0]),=0A=
+				len );=0A=
+=0A=
+		/* Reset buffer descriptor */=0A=
+		FST_WRB ( card, rxDescrRing[pi][rxp].bits, DMA_OWN );=0A=
+=0A=
+		/* Update stats */=0A=
+		port->hdlc.stats.rx_packets++;=0A=
+		port->hdlc.stats.rx_bytes +=3D len;=0A=
+		=0A=
+		/* Push upstream */=0A=
+                dbg(DBG_RX, "Pushing frame up the stack\n");=0A=
+		skb->mac.raw =3D skb->data;=0A=
+		skb->dev =3D hdlc_to_dev (&port->hdlc);=0A=
+                if (port->mode =3D=3D FST_RAW)=0A=
+                  {=0A=
+                    /*=0A=
+                     * Mark it for our own raw sockets interface=0A=
+                     */=0A=
+                    skb->protocol =3D htons (ETH_P_CUST);=0A=
+                    skb->pkt_type =3D PACKET_HOST;=0A=
+                  }=0A=
+                else=0A=
+                  {=0A=
+                    skb->protocol =3D hdlc_type_trans (skb, =
skb->dev);=0A=
+                  }=0A=
+		rx_status =3D netif_rx ( skb );=0A=
+                fst_process_rx_status( rx_status, =
port_to_dev(port)->name );=0A=
+                if (rx_status =3D=3D NET_RX_DROP)=0A=
+                  {=0A=
+                    port->hdlc.stats.rx_dropped++;=0A=
+                  }=0A=
+		port_to_dev (port)->last_rx =3D jiffies;=0A=
+	  }=0A=
+	else=0A=
+	  {=0A=
+	    card->dma_skb_rx =3D skb;=0A=
+	    card->dma_port_rx =3D port;=0A=
+	    card->dma_len_rx =3D len;=0A=
+	    card->dma_rxpos =3D rxp;=0A=
+	    fst_rx_dma(card, (char*)card->rx_dma_handle_card, =0A=
+		       (char*)BUF_OFFSET(rxBuffer[pi][rxp][0]), =0A=
+		       len);=0A=
+	  }=0A=
+	if (rxp !=3D port->rxpos)=0A=
+	  {=0A=
+	    dbg(DBG_ASS, "About to increment rxpos by more than 1\n");=0A=
+	    dbg(DBG_ASS, "rxp =3D %d rxpos =3D %d\n", rxp, port->rxpos);=0A=
+	  }=0A=
+	if ( ++rxp >=3D NUM_RX_BUFFER )=0A=
+	  port->rxpos =3D 0;=0A=
+	else=0A=
+	  port->rxpos =3D rxp;=0A=
+}=0A=
 =0A=
-        /* Reset buffer descriptor */=0A=
-        FST_WRB ( card, rxDescrRing[pi][rxp].bits, DMA_OWN );=0A=
-        if ( ++rxp >=3D NUM_RX_BUFFER )=0A=
-                port->rxpos =3D 0;=0A=
-        else=0A=
-                port->rxpos =3D rxp;=0A=
 =0A=
-        /* Update stats */=0A=
-        port->hdlc.stats.rx_packets++;=0A=
-        port->hdlc.stats.rx_bytes +=3D len;=0A=
+/*=0A=
+ *      The bottom halfs to the ISR=0A=
+ *=0A=
+ */=0A=
 =0A=
-        /* Push upstream */=0A=
-        skb->mac.raw =3D skb->data;=0A=
-        skb->dev =3D hdlc_to_dev ( &port->hdlc );=0A=
-        skb->protocol =3D hdlc_type_trans(skb, skb->dev);=0A=
-        netif_rx ( skb );=0A=
+static void do_bottom_half_tx (struct fst_card_info *card)=0A=
+{=0A=
+  struct fst_port_info *port;=0A=
+  int pi;=0A=
+  int txq_length;=0A=
+  struct sk_buff *skb;=0A=
+  unsigned long flags;=0A=
+=0A=
+  /*=0A=
+   *  Find a free buffer for the transmit=0A=
+   *  Step through each port on this card=0A=
+   */=0A=
+=0A=
+  dbg(DBG_TX, "do_bottom_half_tx\n");=0A=
+  for ( pi =3D 0, port =3D card->ports ; pi < card->nports ; pi++, =
port++ )=0A=
+    {=0A=
+      if ( ! port->run )=0A=
+	continue;=0A=
+=0A=
+      while (!(FST_RDB ( card, txDescrRing[pi][port->txpos].bits ) & =
DMA_OWN)=0A=
+	     && !(card->dmatx_in_progress))=0A=
+	{=0A=
+	  /*=0A=
+	   * There doesn't seem to be a txdone event per-se=0A=
+	   * We seem to have to deduce it, by checking the DMA_OWN=0A=
+	   * bit on the next buffer we think we can use=0A=
+	   */=0A=
+	  spin_lock_irqsave ( &card->card_lock, flags );=0A=
+	  if ((txq_length =3D port->txqe - port->txqs) < 0)=0A=
+	    {=0A=
+	      /*=0A=
+	       * This is the case where one has wrapped and the=0A=
+	       * maths gives us a negative number=0A=
+	       */=0A=
+	      txq_length =3D txq_length + FST_TXQ_DEPTH ;=0A=
+	    }=0A=
+	  spin_unlock_irqrestore ( &card->card_lock, flags );=0A=
+	  if (txq_length > 0)=0A=
+	    {=0A=
+	      /*=0A=
+	       * There is something to send=0A=
+	       */=0A=
+	      spin_lock_irqsave ( &card->card_lock, flags );=0A=
+	      skb =3D port->txq[port->txqs];=0A=
+	      port->txqs++;=0A=
+	      if (port->txqs =3D=3D FST_TXQ_DEPTH)=0A=
+		{=0A=
+		  port->txqs =3D 0;=0A=
+		}=0A=
+	      spin_unlock_irqrestore ( &card->card_lock, flags );=0A=
+	      /*=0A=
+	       * copy the data and set the required indicators on the=0A=
+	       * card.=0A=
+	       */=0A=
+	      FST_WRW ( card, txDescrRing[pi][port->txpos].bcnt, cnv_bcnt ( =
skb->len ));=0A=
+	      if ((skb->len < FST_MIN_DMA_LEN) || (card->family =3D=3D =
FST_FAMILY_TXP))=0A=
+		{=0A=
+	          /* Enqueue the packet with normal io*/=0A=
+	          memcpy_toio ( card->mem + BUF_OFFSET ( =
txBuffer[pi][port->txpos][0]),=0A=
+		                skb->data, skb->len );=0A=
+		  FST_WRB ( card, txDescrRing[pi][port->txpos].bits, DMA_OWN | =
TX_STP | TX_ENP );=0A=
+		  port->hdlc.stats.tx_packets++;=0A=
+		  port->hdlc.stats.tx_bytes +=3D skb->len;=0A=
+		  port_to_dev(port)->trans_start =3D jiffies;=0A=
+		}=0A=
+	      else=0A=
+		{=0A=
+	          /* Or do it through dma */=0A=
+	          memcpy(card->tx_dma_handle_host, skb->data, skb->len);=0A=
+		  card->dma_port_tx =3D port;=0A=
+		  card->dma_len_tx =3D skb->len;=0A=
+		  card->dma_txpos =3D port->txpos;=0A=
+	          fst_tx_dma(card, (char*)card->tx_dma_handle_card, =0A=
+		             (char*)BUF_OFFSET(txBuffer[pi][port->txpos][0]), =0A=
+		             skb->len);=0A=
+	        }=0A=
+	      if ( ++port->txpos >=3D NUM_TX_BUFFER )=0A=
+		port->txpos =3D 0;=0A=
+	      /*=0A=
+	       * If we have flow control on, can we now release it?=0A=
+	       */=0A=
+	      if (port->start)=0A=
+		{=0A=
+		  if (txq_length < fst_txq_low)=0A=
+		    {=0A=
+		      netif_wake_queue ( port_to_dev(port) );=0A=
+		      port->start =3D 0;=0A=
+		    }=0A=
+		}=0A=
+	      dev_kfree_skb ( skb );=0A=
+	    }=0A=
+	  else=0A=
+	    {=0A=
+	      /*=0A=
+	       * Nothing to send so break out of the while loop=0A=
+	       */=0A=
+	      break;=0A=
+	    }=0A=
+	}=0A=
+    }=0A=
+}=0A=
 =0A=
-        port_to_dev ( port )->last_rx =3D jiffies;=0A=
+static void do_bottom_half_rx (struct fst_card_info *card)=0A=
+{=0A=
+  struct fst_port_info *port;=0A=
+  int pi;=0A=
+  int rx_count=3D0;=0A=
+=0A=
+  /* Check for rx completions on all ports on this card */=0A=
+  dbg(DBG_RX, "do_bottom_half_rx\n");=0A=
+  for ( pi =3D 0, port =3D card->ports ; pi < card->nports ; pi++, =
port++ )=0A=
+    {=0A=
+      //rx_count =3D 0;=0A=
+      if ( ! port->run )=0A=
+	continue;=0A=
+      while (!( FST_RDB ( card, rxDescrRing[pi][port->rxpos].bits )=0A=
+		& DMA_OWN ) && !(card->dmarx_in_progress))=0A=
+	{=0A=
+	  if (rx_count > fst_max_reads)=0A=
+	    {=0A=
+	      /*=0A=
+	       * Don't spend forever in receive processing=0A=
+	       * Schedule another event=0A=
+	       */=0A=
+              fst_q_work_item(&fst_work_intq, card->card_no);=0A=
+	      queue_task(&fst_int_task, &tq_immediate); =0A=
+	      mark_bh(IMMEDIATE_BH); /* Note that this call must follow =
queue_task */=0A=
+	      //pi =3D card->nports;=0A=
+	      break;  /* Leave the loop */=0A=
+	    }=0A=
+	  fst_intr_rx ( card, port );=0A=
+	  rx_count++;=0A=
+	}=0A=
+    }=0A=
 }=0A=
 =0A=
 =0A=
@@ -783,7 +1599,9 @@=0A=
         int rdidx;                      /* Event buffer indices */=0A=
         int wridx;=0A=
         int event;                      /* Actual event for processing =
*/=0A=
-        int pi;=0A=
+	unsigned int dma_intcsr=3D0;=0A=
+	unsigned int do_card_interrupt;=0A=
+	unsigned int int_retry_count;=0A=
 =0A=
         if (( card =3D dev_id ) =3D=3D NULL )=0A=
         {=0A=
@@ -791,100 +1609,160 @@=0A=
                 return;=0A=
         }=0A=
 =0A=
+	/*=0A=
+	 * Check to see if the interrupt was for this card=0A=
+	 * return if not=0A=
+	 * Note that the call to clear the interrupt is important=0A=
+	 */=0A=
         dbg ( DBG_INTR,"intr: %d %p\n", irq, card );=0A=
-=0A=
-        spin_lock ( &card->card_lock );=0A=
+	if (card->state !=3D FST_RUNNING)=0A=
+	  {=0A=
+	    printk_err("Interrupt received for card %d in a non running state =
(%d)\n", card->card_no, card->state);=0A=
+=0A=
+	    /* =0A=
+	     * It is possible to really be running, i.e. we have re-loaded=0A=
+	     * a running card=0A=
+	     * Clear and reprime the interrupt source =0A=
+	     */=0A=
+	    fst_clear_intr ( card );=0A=
+	    return;=0A=
+	  }=0A=
 =0A=
         /* Clear and reprime the interrupt source */=0A=
         fst_clear_intr ( card );=0A=
 =0A=
-        /* Set the software acknowledge */=0A=
-        FST_WRB ( card, interruptHandshake, 0xEE );=0A=
-=0A=
+	/*=0A=
+	 * Is the interrupt for this card (handshake =3D=3D 1)=0A=
+	 */=0A=
+	do_card_interrupt =3D 0;=0A=
+	if (FST_RDB( card, interruptHandshake) =3D=3D 1)=0A=
+	  {=0A=
+	    do_card_interrupt +=3D FST_CARD_INT;=0A=
+	    /* Set the software acknowledge */=0A=
+	    FST_WRB ( card, interruptHandshake, 0xEE );=0A=
+	  }=0A=
+	if (card->family =3D=3D FST_FAMILY_TXU)=0A=
+	  {=0A=
+	    /*=0A=
+	     * Is it a DMA Interrupt=0A=
+	     */=0A=
+	    dma_intcsr =3D inl (card->pci_conf + INTCSR_9054);=0A=
+	    if (dma_intcsr & 0x00200000)=0A=
+	      {=0A=
+		/*=0A=
+		 * DMA Channel 0 (Rx transfer complete)=0A=
+		 */=0A=
+		dbg(DBG_RX, "DMA Rx xfer complete\n");=0A=
+		outb( 0x8, card->pci_conf + DMACSR0);=0A=
+		fst_rx_dma_complete (card, card->dma_port_rx, card->dma_len_rx,=0A=
+				     card->dma_skb_rx, card->dma_rxpos);=0A=
+		card->dmarx_in_progress =3D 0;=0A=
+		do_card_interrupt +=3D FST_RX_DMA_INT;=0A=
+	      }=0A=
+	    if (dma_intcsr & 0x00400000)=0A=
+	      {=0A=
+		/*=0A=
+		 * DMA Channel 1 (Tx transfer complete)=0A=
+		 */=0A=
+		dbg(DBG_TX, "DMA Tx xfer complete\n");=0A=
+		outb( 0x8, card->pci_conf + DMACSR1);=0A=
+		fst_tx_dma_complete (card, card->dma_port_tx, card->dma_len_tx,=0A=
+				     card->dma_txpos);=0A=
+                card->dmatx_in_progress =3D 0;=0A=
+		do_card_interrupt +=3D FST_TX_DMA_INT;=0A=
+	      }=0A=
+	  }=0A=
+	=0A=
+	/*=0A=
+	 * Have we been missing Interrupts=0A=
+	 */=0A=
+	int_retry_count =3D FST_RDL( card, interruptRetryCount);=0A=
+	if (int_retry_count)=0A=
+	  {=0A=
+	    dbg(DBG_ASS, "Card %d int_retry_count is  %d\n", =0A=
+                card->card_no, int_retry_count);=0A=
+	    FST_WRL( card, interruptRetryCount, 0);=0A=
+	  }=0A=
+=0A=
+	if (!do_card_interrupt)=0A=
+	  {=0A=
+	    return;=0A=
+	  }=0A=
+=0A=
+	/* Scehdule the bottom half of the ISR */=0A=
+        fst_q_work_item(&fst_work_intq, card->card_no);=0A=
+	queue_task(&fst_int_task, &tq_immediate); =0A=
+	mark_bh(IMMEDIATE_BH); /* Note that this call must follow =0A=
+				  queue_task */=0A=
+	=0A=
         /* Drain the event queue */=0A=
-        rdidx =3D FST_RDB ( card, interruptEvent.rdindex );=0A=
-        wridx =3D FST_RDB ( card, interruptEvent.wrindex );=0A=
+        rdidx =3D FST_RDB ( card, interruptEvent.rdindex ) & 0x1f;=0A=
+        wridx =3D FST_RDB ( card, interruptEvent.wrindex ) & 0x1f;=0A=
         while ( rdidx !=3D wridx )=0A=
-        {=0A=
-                event =3D FST_RDB ( card, =
interruptEvent.evntbuff[rdidx]);=0A=
-=0A=
-                port =3D &card->ports[event & 0x03];=0A=
-=0A=
-                dbg ( DBG_INTR,"intr: %x\n", event );=0A=
-=0A=
+	  {=0A=
+	    event =3D FST_RDB ( card, interruptEvent.evntbuff[rdidx]);=0A=
+	    port =3D &card->ports[event & 0x03];=0A=
+	    =0A=
+                dbg ( DBG_INTR,"Processing Interrupt event: %x\n", =
event );=0A=
+		=0A=
                 switch ( event )=0A=
-                {=0A=
-                case CTLA_CHG:=0A=
-                case CTLB_CHG:=0A=
-                case CTLC_CHG:=0A=
-                case CTLD_CHG:=0A=
-                        if ( port->run )=0A=
-                                fst_intr_ctlchg ( card, port );=0A=
-                        break;=0A=
-=0A=
-                case ABTA_SENT:=0A=
-                case ABTB_SENT:=0A=
-                case ABTC_SENT:=0A=
-                case ABTD_SENT:=0A=
-                        dbg ( DBG_TX,"Abort complete port %d\n", event =
& 0x03 );=0A=
-                        break;=0A=
-=0A=
-                case TXA_UNDF:=0A=
-                case TXB_UNDF:=0A=
-                case TXC_UNDF:=0A=
-                case TXD_UNDF:=0A=
-                        /* Difficult to see how we'd get this given =
that we=0A=
-                         * always load up the entire packet for =
DMA.=0A=
-                         */=0A=
-                        dbg ( DBG_TX,"Tx underflow port %d\n", event & =
0x03 );=0A=
-                        port->hdlc.stats.tx_errors++;=0A=
-                        port->hdlc.stats.tx_fifo_errors++;=0A=
-                        break;=0A=
-=0A=
-                case INIT_CPLT:=0A=
-                        dbg ( DBG_INIT,"Card init OK intr\n");=0A=
-                        break;=0A=
-=0A=
-                case INIT_FAIL:=0A=
-                        dbg ( DBG_INIT,"Card init FAILED intr\n");=0A=
-                        card->state =3D FST_IFAILED;=0A=
-                        break;=0A=
-=0A=
-                default:=0A=
-                        printk_err ("intr: unknown card event code. =
ignored\n");=0A=
-                        break;=0A=
+		  {=0A=
+		  case TE1_ALMA:=0A=
+		    dbg ( DBG_INTR,"TE1 Alarm intr\n");=0A=
+                    if ( port->run )=0A=
+                      fst_intr_te1_alarm (card, port);=0A=
+                    break;=0A=
+		    		    =0A=
+		  case CTLA_CHG:=0A=
+		  case CTLB_CHG:=0A=
+		  case CTLC_CHG:=0A=
+		  case CTLD_CHG:=0A=
+		    if ( port->run )=0A=
+		      fst_intr_ctlchg ( card, port );=0A=
+		    break;=0A=
+		    =0A=
+		  case ABTA_SENT:=0A=
+		  case ABTB_SENT:=0A=
+		  case ABTC_SENT:=0A=
+		  case ABTD_SENT:=0A=
+		    dbg (DBG_TX,"Abort complete port %d\n", port->index );=0A=
+		    break;=0A=
+		    =0A=
+		  case TXA_UNDF:=0A=
+		  case TXB_UNDF:=0A=
+		  case TXC_UNDF:=0A=
+		  case TXD_UNDF:=0A=
+		    /* Difficult to see how we'd get this given that we=0A=
+		     * always load up the entire packet for DMA.=0A=
+		     */=0A=
+		    dbg (DBG_TX,"Tx underflow port %d\n", port->index );=0A=
+		    =0A=
+		    port->hdlc.stats.tx_errors++;=0A=
+		    port->hdlc.stats.tx_fifo_errors++;=0A=
+		    dbg(DBG_ASS, "Tx underflow on card %d port %d\n",=0A=
+			card->card_no, port->index);=0A=
+		    break;=0A=
+=0A=
+		  case INIT_CPLT:=0A=
+		    dbg ( DBG_INIT,"Card init OK intr\n");=0A=
+		    break;=0A=
+		    =0A=
+		  case INIT_FAIL:=0A=
+		    dbg ( DBG_INIT,"Card init FAILED intr\n");=0A=
+		    card->state =3D FST_IFAILED;=0A=
+		    break;=0A=
+		    =0A=
+		  default:=0A=
+		    printk_err ("intr: unknown card event %d. ignored\n",=0A=
+                                event);=0A=
+		    break;=0A=
                 }=0A=
-=0A=
+		=0A=
                 /* Bump and wrap the index */=0A=
                 if ( ++rdidx >=3D MAX_CIRBUFF )=0A=
-                        rdidx =3D 0;=0A=
-        }=0A=
+		  rdidx =3D 0;=0A=
+	  }=0A=
         FST_WRB ( card, interruptEvent.rdindex, rdidx );=0A=
-=0A=
-        for ( pi =3D 0, port =3D card->ports ; pi < card->nports ; =
pi++, port++ )=0A=
-        {=0A=
-                if ( ! port->run )=0A=
-                        continue;=0A=
-=0A=
-                /* Check for rx completions */=0A=
-                while ( ! ( FST_RDB ( card, =
rxDescrRing[pi][port->rxpos].bits )=0A=
-                                                                & =
DMA_OWN ))=0A=
-                {=0A=
-                        fst_intr_rx ( card, port );=0A=
-                }=0A=
-=0A=
-                /* Check for Tx completions */=0A=
-                while ( port->txcnt > 0 && ! ( FST_RDB ( card,=0A=
-                        txDescrRing[pi][port->txipos].bits ) & DMA_OWN =
))=0A=
-                {=0A=
-                        --port->txcnt;=0A=
-                        if ( ++port->txipos >=3D NUM_TX_BUFFER )=0A=
-                                port->txipos =3D 0;=0A=
-                        netif_wake_queue ( port_to_dev ( port ));=0A=
-                }=0A=
-        }=0A=
-=0A=
-        spin_unlock ( &card->card_lock );=0A=
 }=0A=
 =0A=
 =0A=
@@ -934,9 +1812,9 @@=0A=
          */=0A=
         if ( FST_RDL ( card, numberOfPorts ) !=3D card->nports )=0A=
         {=0A=
-                printk_warn ("Port count mismatch."=0A=
-                                " Firmware thinks %d we say %d\n",=0A=
-                                FST_RDL ( card, numberOfPorts ), =
card->nports );=0A=
+                printk_warn ("Port count mismatch on card %d."=0A=
+                             " Firmware thinks %d we say %d\n", =
card->card_no,=0A=
+                              FST_RDL ( card, numberOfPorts ), =
card->nports );=0A=
         }=0A=
 }=0A=
 =0A=
@@ -946,24 +1824,89 @@=0A=
                 struct fstioc_info *info )=0A=
 {=0A=
         int err;=0A=
+	unsigned char my_framing;=0A=
 =0A=
-        /* Set things according to the user set valid flags.=0A=
-         * Several of the old options have been invalidated/replaced =
by the=0A=
-         * generic HDLC package.=0A=
-         */=0A=
+        /* Set things according to the user set valid flags =0A=
+	 * Several of the old options have been invalidated/replaced by the =
=0A=
+	 * generic hdlc package.=0A=
+	 */=0A=
         err =3D 0;=0A=
         if ( info->valid & FSTVAL_PROTO )=0A=
-                err =3D -EINVAL;=0A=
+          {=0A=
+            if (info->proto =3D=3D FST_RAW)=0A=
+              port->mode =3D FST_RAW;=0A=
+            else=0A=
+              port->mode =3D FST_GEN_HDLC;=0A=
+          }=0A=
+=0A=
         if ( info->valid & FSTVAL_CABLE )=0A=
-                err =3D -EINVAL;=0A=
+	        err =3D -EINVAL;=0A=
+=0A=
         if ( info->valid & FSTVAL_SPEED )=0A=
-                err =3D -EINVAL;=0A=
+	        err =3D -EINVAL;=0A=
 =0A=
+        if ( info->valid & FSTVAL_PHASE )=0A=
+                FST_WRB ( card, =
portConfig[port->index].invertClock,=0A=
+                                        info->invertClock );=0A=
         if ( info->valid & FSTVAL_MODE )=0A=
                 FST_WRW ( card, cardMode, info->cardMode );=0A=
+        if ( info->valid & FSTVAL_TE1 )=0A=
+        {=0A=
+                FST_WRL ( card, suConfig.dataRate, info->lineSpeed =
);=0A=
+                FST_WRB ( card, suConfig.clocking, info->clockSource =
);=0A=
+		my_framing =3D FRAMING_E1;=0A=
+		if (info->framing =3D=3D E1)=0A=
+		  my_framing =3D FRAMING_E1;=0A=
+		if (info->framing =3D=3D T1)=0A=
+		  my_framing =3D FRAMING_T1;=0A=
+		if (info->framing =3D=3D J1)=0A=
+		  my_framing =3D FRAMING_J1;=0A=
+		FST_WRB ( card, suConfig.framing,  my_framing );=0A=
+                FST_WRB ( card, suConfig.structure, info->structure =
);=0A=
+                FST_WRB ( card, suConfig.interface, info->interface =
);=0A=
+                FST_WRB ( card, suConfig.coding, info->coding );=0A=
+                FST_WRB ( card, suConfig.lineBuildOut, =
info->lineBuildOut );=0A=
+                FST_WRB ( card, suConfig.equalizer, info->equalizer =
);=0A=
+                FST_WRB ( card, suConfig.transparentMode, =
info->transparentMode );=0A=
+                FST_WRB ( card, suConfig.loopMode, info->loopMode =
);=0A=
+                FST_WRB ( card, suConfig.range, info->range );=0A=
+                FST_WRB ( card, suConfig.txBufferMode, =
info->txBufferMode );=0A=
+                FST_WRB ( card, suConfig.rxBufferMode, =
info->rxBufferMode );=0A=
+                FST_WRB ( card, suConfig.startingSlot, =
info->startingSlot );=0A=
+                FST_WRB ( card, suConfig.losThreshold, =
info->losThreshold );=0A=
+		if (info->idleCode)=0A=
+		  FST_WRB ( card, suConfig.enableIdleCode, 1 );=0A=
+		else=0A=
+		  FST_WRB ( card, suConfig.enableIdleCode, 0 );=0A=
+		FST_WRB ( card, suConfig.idleCode, info->idleCode );=0A=
+#if FST_DEBUG=0A=
+                if ( info->valid & FSTVAL_TE1 )=0A=
+                  {=0A=
+                    printk("Setting TE1 data\n");=0A=
+                    printk("Line Speed =3D %d\n", info->lineSpeed);=0A=
+                    printk("Start slot =3D %d\n", =
info->startingSlot);=0A=
+                    printk("Clock source =3D %d\n", =
info->clockSource);=0A=
+                    printk("Framing =3D %d\n", my_framing);=0A=
+                    printk("Structure =3D %d\n", info->structure);=0A=
+                    printk("interface =3D %d\n", info->interface);=0A=
+                    printk("Coding =3D %d\n", info->coding);=0A=
+                    printk("Line build out =3D %d\n", =
info->lineBuildOut);=0A=
+                    printk("Equaliser =3D %d\n", info->equalizer);=0A=
+                    printk("Transparent mode =3D %d\n", =
info->transparentMode);=0A=
+                    printk("Loop mode =3D %d\n", info->loopMode);=0A=
+                    printk("Range =3D %d\n", info->range);=0A=
+                    printk("Tx Buffer mode =3D %d\n", =
info->txBufferMode);=0A=
+                    printk("Rx Buffer mode =3D %d\n", =
info->rxBufferMode);=0A=
+                    printk("LOS Threshold =3D %d\n", =
info->losThreshold);=0A=
+		    printk("Idle Code =3D %d\n", info->idleCode);=0A=
+                  }=0A=
+#endif=0A=
+        }=0A=
 #if FST_DEBUG=0A=
         if ( info->valid & FSTVAL_DEBUG )=0A=
+        {=0A=
                 fst_debug_mask =3D info->debug;=0A=
+        }=0A=
 #endif=0A=
 =0A=
         return err;=0A=
@@ -978,6 +1921,7 @@=0A=
         memset ( info, 0, sizeof ( struct fstioc_info ));=0A=
 =0A=
         i =3D port->index;=0A=
+        info->kernelVersion =3D LINUX_VERSION_CODE;=0A=
         info->nports =3D card->nports;=0A=
         info->type   =3D card->type;=0A=
         info->state  =3D card->state;=0A=
@@ -1000,12 +1944,69 @@=0A=
         info->lineInterface =3D FST_RDW ( card, =
portConfig[i].lineInterface );=0A=
         info->internalClock =3D FST_RDB ( card, =
portConfig[i].internalClock );=0A=
         info->lineSpeed     =3D FST_RDL ( card, =
portConfig[i].lineSpeed );=0A=
+	info->invertClock   =3D FST_RDB ( card, portConfig[i].invertClock =
);=0A=
         info->v24IpSts      =3D FST_RDL ( card, v24IpSts[i] );=0A=
         info->v24OpSts      =3D FST_RDL ( card, v24OpSts[i] );=0A=
         info->clockStatus   =3D FST_RDW ( card, clockStatus[i] );=0A=
         info->cableStatus   =3D FST_RDW ( card, cableStatus );=0A=
         info->cardMode      =3D FST_RDW ( card, cardMode );=0A=
         info->smcFirmwareVersion  =3D FST_RDL ( card, =
smcFirmwareVersion );=0A=
+=0A=
+	/*=0A=
+	 * The T2U can report cable presence for both A or B=0A=
+	 * in bits 0 and 1 of cableStatus.  See which port we are and =0A=
+	 * do the mapping.=0A=
+	 */=0A=
+ 	if (card->family =3D=3D FST_FAMILY_TXU)=0A=
+	  {=0A=
+	    if (port->index =3D=3D 0)=0A=
+	      {=0A=
+		/*=0A=
+		 * Port A=0A=
+		 */=0A=
+		info->cableStatus =3D info->cableStatus & 1;=0A=
+	      }=0A=
+	    else=0A=
+	      {=0A=
+		/*=0A=
+		 * Port B=0A=
+		 */=0A=
+		info->cableStatus =3D info->cableStatus >> 1;=0A=
+		info->cableStatus =3D info->cableStatus & 1;=0A=
+	      }=0A=
+          }=0A=
+        /*=0A=
+         * Some additional bits if we are TE1=0A=
+         */=0A=
+        if (card->type =3D=3D FST_TYPE_TE1)=0A=
+          {=0A=
+            info->lineSpeed =3D FST_RDL ( card, suConfig.dataRate =
);=0A=
+            info->clockSource =3D FST_RDB ( card, suConfig.clocking =
);=0A=
+            info->framing =3D FST_RDB ( card, suConfig.framing );=0A=
+            info->structure =3D FST_RDB ( card, suConfig.structure =
);=0A=
+            info->interface =3D FST_RDB ( card, suConfig.interface =
);=0A=
+            info->coding =3D FST_RDB ( card, suConfig.coding );=0A=
+            info->lineBuildOut =3D FST_RDB ( card, =
suConfig.lineBuildOut );=0A=
+            info->equalizer =3D FST_RDB ( card, suConfig.equalizer =
);=0A=
+            info->loopMode =3D FST_RDB ( card, suConfig.loopMode ); =
=0A=
+            info->range =3D FST_RDB ( card, suConfig.range ); =0A=
+            info->txBufferMode =3D FST_RDB ( card, =
suConfig.txBufferMode ); =0A=
+            info->rxBufferMode =3D FST_RDB ( card, =
suConfig.rxBufferMode ); =0A=
+            info->startingSlot =3D FST_RDB ( card, =
suConfig.startingSlot ); =0A=
+            info->losThreshold =3D FST_RDB ( card, =
suConfig.losThreshold );=0A=
+	    if (FST_RDB (card, suConfig.enableIdleCode ))=0A=
+	      info->idleCode =3D  FST_RDB ( card, suConfig.idleCode );=0A=
+	    else=0A=
+	      info->idleCode =3D 0 ; =0A=
+            info->receiveBufferDelay =3D FST_RDL ( card, =
suStatus.receiveBufferDelay );=0A=
+            info->framingErrorCount =3D FST_RDL ( card, =
suStatus.framingErrorCount ); =0A=
+            info->codeViolationCount =3D FST_RDL ( card, =
suStatus.codeViolationCount ); =0A=
+            info->crcErrorCount =3D FST_RDL ( card, =
suStatus.crcErrorCount );=0A=
+            info->lineAttenuation =3D FST_RDL ( card, =
suStatus.lineAttenuation );=0A=
+            info->lossOfSignal =3D FST_RDB ( card, =
suStatus.lossOfSignal );=0A=
+            info->receiveRemoteAlarm =3D FST_RDB ( card, =
suStatus.receiveRemoteAlarm );=0A=
+            info->alarmIndicationSignal =3D FST_RDB ( card, =
suStatus.alarmIndicationSignal );=0A=
+          }=0A=
 }=0A=
 =0A=
 =0A=
@@ -1016,16 +2017,22 @@=0A=
         sync_serial_settings sync;=0A=
         int i;=0A=
 =0A=
-        if (copy_from_user (&sync, ifr->ifr_settings.ifs_ifsu.sync,=0A=
-			    sizeof (sync)))=0A=
+        if ( ifr->ifr_settings.size !=3D sizeof ( sync ))=0A=
+        {=0A=
+                return -ENOMEM;=0A=
+        }=0A=
+=0A=
+        if ( copy_from_user ( &sync, ifr->ifr_settings.ifs_ifsu.sync, =
sizeof ( sync )))=0A=
+        {=0A=
                 return -EFAULT;=0A=
+        }=0A=
 =0A=
         if ( sync.loopback )=0A=
                 return -EINVAL;=0A=
 =0A=
         i =3D port->index;=0A=
 =0A=
-        switch (ifr->ifr_settings.type)=0A=
+        switch ( ifr->ifr_settings.type )=0A=
         {=0A=
         case IF_IFACE_V35:=0A=
                 FST_WRW ( card, portConfig[i].lineInterface, V35 );=0A=
@@ -1042,6 +2049,21 @@=0A=
                 port->hwif =3D X21;=0A=
                 break;=0A=
 =0A=
+        case IF_IFACE_X21D:=0A=
+                FST_WRW ( card, portConfig[i].lineInterface, X21D =
);=0A=
+                port->hwif =3D X21D;=0A=
+                break;=0A=
+=0A=
+        case IF_IFACE_T1:=0A=
+                FST_WRW ( card, portConfig[i].lineInterface, T1 );=0A=
+                port->hwif =3D T1;=0A=
+                break;=0A=
+=0A=
+        case IF_IFACE_E1:=0A=
+                FST_WRW ( card, portConfig[i].lineInterface, E1 );=0A=
+                port->hwif =3D E1;=0A=
+                break;=0A=
+=0A=
         case IF_IFACE_SYNC_SERIAL:=0A=
                 break;=0A=
 =0A=
@@ -1079,33 +2101,48 @@=0A=
          */=0A=
         switch ( port->hwif )=0A=
         {=0A=
+        case E1:=0A=
+                ifr->ifr_settings.type =3D IF_IFACE_E1;=0A=
+                break;=0A=
+        case T1:=0A=
+                ifr->ifr_settings.type =3D IF_IFACE_T1;=0A=
+                break;=0A=
         case V35:=0A=
                 ifr->ifr_settings.type =3D IF_IFACE_V35;=0A=
                 break;=0A=
         case V24:=0A=
                 ifr->ifr_settings.type =3D IF_IFACE_V24;=0A=
                 break;=0A=
+        case X21D:=0A=
+                ifr->ifr_settings.type =3D IF_IFACE_X21D;=0A=
+                break;=0A=
         case X21:=0A=
         default:=0A=
                 ifr->ifr_settings.type =3D IF_IFACE_X21;=0A=
                 break;=0A=
         }=0A=
-=0A=
-	if (ifr->ifr_settings.size < sizeof(sync)) {=0A=
-		ifr->ifr_settings.size =3D sizeof(sync); /* data size wanted */=0A=
-		return -ENOBUFS;=0A=
-	}=0A=
+        if ( ifr->ifr_settings.size =3D=3D 0 )=0A=
+        {=0A=
+                return 0;       /* only type requested */=0A=
+        }=0A=
+        if ( ifr->ifr_settings.size < sizeof ( sync ))=0A=
+        {=0A=
+                return -ENOMEM;=0A=
+        }=0A=
 =0A=
         i =3D port->index;=0A=
         sync.clock_rate =3D FST_RDL ( card, portConfig[i].lineSpeed =
);=0A=
         /* Lucky card and linux use same encoding here */=0A=
-        sync.clock_type =3D FST_RDB ( card, =
portConfig[i].internalClock );=0A=
+        sync.clock_type =3D FST_RDB ( card, =
portConfig[i].internalClock ) =3D=3D=0A=
+                                    INTCLK ? CLOCK_INT : CLOCK_EXT;=0A=
         sync.loopback =3D 0;=0A=
 =0A=
-        if (copy_to_user (ifr->ifr_settings.ifs_ifsu.sync, &sync,=0A=
-			  sizeof(sync)))=0A=
+        if ( copy_to_user ( ifr->ifr_settings.ifs_ifsu.sync, &sync, =
sizeof ( sync )))=0A=
+        {=0A=
                 return -EFAULT;=0A=
+        }=0A=
 =0A=
+        ifr->ifr_settings.size =3D sizeof ( sync );=0A=
         return 0;=0A=
 }=0A=
 =0A=
@@ -1196,7 +2233,7 @@=0A=
                         if ( card->state =3D=3D FST_RUNNING )=0A=
                         {=0A=
                                 spin_lock_irqsave ( &card->card_lock, =
flags );=0A=
-                                fst_clear_intr ( card );=0A=
+                                fst_enable_intr ( card );=0A=
                                 FST_WRB ( card, interruptHandshake, =
0xEE );=0A=
                                 spin_unlock_irqrestore ( =
&card->card_lock,=0A=
                                                                 flags =
);=0A=
@@ -1218,9 +2255,16 @@=0A=
 =0A=
         case FSTSETCONF:=0A=
 =0A=
-                /* Most of the setting have been moved to the generic =
ioctls=0A=
-                 * this just covers debug and board ident mode now=0A=
-                 */=0A=
+		/*=0A=
+		 * Most of the settings have been moved to the generic ioctls=0A=
+		 * this just covers debug and board ident now=0A=
+		 */=0A=
+=0A=
+                if(card->state !=3D FST_RUNNING)=0A=
+	        {=0A=
+		  printk_err("Attempt to configure card %d in non-running state =
(%d)\n", card->card_no, card->state);=0A=
+	                return -EIO;=0A=
+	        }=0A=
                 if ( copy_from_user ( &info,  ifr->ifr_data, sizeof ( =
info )))=0A=
                 {=0A=
                         return -EFAULT;=0A=
@@ -1229,7 +2273,7 @@=0A=
                 return set_conf_from_info ( card, port, &info );=0A=
 =0A=
         case SIOCWANDEV:=0A=
-                switch (ifr->ifr_settings.type)=0A=
+	        switch ( ifr->ifr_settings.type )=0A=
                 {=0A=
                 case IF_GET_IFACE:=0A=
                         return fst_get_iface ( card, port, ifr );=0A=
@@ -1238,10 +2282,28 @@=0A=
                 case IF_IFACE_V35:=0A=
                 case IF_IFACE_V24:=0A=
                 case IF_IFACE_X21:=0A=
+		case IF_IFACE_X21D:=0A=
+                case IF_IFACE_T1:=0A=
+                case IF_IFACE_E1:=0A=
                         return fst_set_iface ( card, port, ifr );=0A=
 =0A=
+                case IF_PROTO_RAW:=0A=
+                  port->mode =3D FST_RAW;=0A=
+                  return 0;=0A=
+=0A=
+                case IF_GET_PROTO:=0A=
+                  if (port->mode =3D=3D FST_RAW)=0A=
+                    {=0A=
+                      ifr->ifr_settings.type =3D IF_PROTO_RAW;=0A=
+                      return 0;=0A=
+                    }=0A=
+                  return hdlc_ioctl ( dev, ifr, cmd );=0A=
+=0A=
                 default:=0A=
-                        return hdlc_ioctl ( dev, ifr, cmd );=0A=
+                  port->mode =3D FST_GEN_HDLC;=0A=
+                  dbg(DBG_IOCTL, "Passing this type to hdlc %x\n",=0A=
+                      ifr->ifr_settings.type);=0A=
+                  return hdlc_ioctl ( dev, ifr, cmd );=0A=
                 }=0A=
 =0A=
         default:=0A=
@@ -1255,6 +2317,7 @@=0A=
 fst_openport ( struct fst_port_info *port )=0A=
 {=0A=
         int signals;=0A=
+	int txq_length;=0A=
 =0A=
         /* Only init things if card is actually running. This allows =
open to=0A=
          * succeed for downloads etc.=0A=
@@ -1277,12 +2340,17 @@=0A=
                 port->run =3D 1;=0A=
 =0A=
                 signals =3D FST_RDL ( port->card, =
v24DebouncedSts[port->index]);=0A=
-                if ( signals & (( port->hwif =3D=3D X21 ) ? =
IPSTS_INDICATE=0A=
-                                                      : IPSTS_DCD =
))=0A=
-                        netif_carrier_on ( port_to_dev ( port ));=0A=
+                if ( signals & (((port->hwif =3D=3D X21) || =
(port->hwif =3D=3D X21D))=0A=
+				? IPSTS_INDICATE : IPSTS_DCD ))=0A=
+                        netif_carrier_on ( port_to_dev(port) );=0A=
                 else=0A=
-                        netif_carrier_off ( port_to_dev ( port ));=0A=
+                        netif_carrier_off ( port_to_dev(port) );=0A=
+=0A=
+		txq_length =3D port->txqe - port->txqs;=0A=
+		port->txqe =3D 0;=0A=
+		port->txqs =3D 0;=0A=
         }=0A=
+=0A=
 }=0A=
 =0A=
 static void=0A=
@@ -1309,14 +2377,18 @@=0A=
 fst_open ( struct net_device *dev )=0A=
 {=0A=
         int err;=0A=
+        struct fst_port_info *port;=0A=
 =0A=
-        err =3D hdlc_open ( dev_to_hdlc ( dev ));=0A=
-        if ( err )=0A=
-                return err;=0A=
-=0A=
+        port =3D dev_to_port(dev);=0A=
         MOD_INC_USE_COUNT;=0A=
+        if (port->mode !=3D FST_RAW)=0A=
+          {=0A=
+            err =3D hdlc_open ( dev_to_hdlc ( dev ));=0A=
+            if ( err )=0A=
+              return err;=0A=
+          }=0A=
 =0A=
-        fst_openport ( dev_to_port ( dev ));=0A=
+        fst_openport ( port );=0A=
         netif_wake_queue ( dev );=0A=
         return 0;=0A=
 }=0A=
@@ -1324,40 +2396,59 @@=0A=
 static int=0A=
 fst_close ( struct net_device *dev )=0A=
 {=0A=
-        netif_stop_queue ( dev );=0A=
-        fst_closeport ( dev_to_port ( dev ));=0A=
-        hdlc_close ( dev_to_hdlc  ( dev ));=0A=
+        struct fst_port_info *port;=0A=
+        struct fst_card_info *card;=0A=
+	unsigned char tx_dma_done;=0A=
+	unsigned char rx_dma_done;=0A=
+=0A=
+        port =3D dev_to_port(dev);=0A=
+	card =3D port->card;=0A=
+=0A=
+	tx_dma_done =3D inb ( card->pci_conf + DMACSR1 );=0A=
+	rx_dma_done =3D inb ( card->pci_conf + DMACSR0 );=0A=
+	dbg(DBG_OPEN, "Port Close: tx_dma_in_progress =3D %d (%x) =
rx_dma_in_progress =3D %d (%x)\n",=0A=
+	       card->dmatx_in_progress, tx_dma_done, =0A=
+	       card->dmarx_in_progress, rx_dma_done);=0A=
+=0A=
+	netif_stop_queue ( dev );=0A=
+	fst_closeport ( dev_to_port (dev) );=0A=
+        if (port->mode !=3D FST_RAW)=0A=
+          {=0A=
+            hdlc_close ( dev_to_hdlc ( dev ));=0A=
+          }=0A=
         MOD_DEC_USE_COUNT;=0A=
         return 0;=0A=
 }=0A=
 =0A=
 static int=0A=
-fst_attach ( hdlc_device *hdlc, unsigned short encoding, unsigned =
short parity )=0A=
+fst_attach ( hdlc_device *hdlc, unsigned short encoding, unsigned =
short parity)=0A=
 {=0A=
-        /* Setting currently fixed in FarSync card so we check and =
forget */=0A=
-        if ( encoding !=3D ENCODING_NRZ || parity !=3D =
PARITY_CRC16_PR1_CCITT )=0A=
-                return -EINVAL;=0A=
-        return 0;=0A=
+	/*=0A=
+	 * Setting currently fixed in FarSync card so we check and forget=0A=
+	 */=0A=
+	if ( encoding !=3D ENCODING_NRZ || parity !=3D PARITY_CRC16_PR1_CCITT =
)=0A=
+		return -EINVAL;=0A=
+	return 0;=0A=
 }=0A=
 =0A=
-=0A=
 static void=0A=
 fst_tx_timeout ( struct net_device *dev )=0A=
 {=0A=
         struct fst_port_info *port;=0A=
+        struct fst_card_info *card;=0A=
 =0A=
-        dbg ( DBG_INTR | DBG_TX,"tx_timeout\n");=0A=
-=0A=
-        port =3D dev_to_port ( dev );=0A=
+        port =3D dev_to_port (dev);=0A=
+        card =3D port->card;=0A=
 =0A=
         port->hdlc.stats.tx_errors++;=0A=
         port->hdlc.stats.tx_aborted_errors++;=0A=
-=0A=
-        if ( port->txcnt > 0 )=0A=
-                fst_issue_cmd ( port, ABORTTX );=0A=
+	dbg(DBG_ASS, "Tx timeout card %d port %d\n", =0A=
+	    card->card_no, port->index);=0A=
+        fst_issue_cmd ( port, ABORTTX );=0A=
 =0A=
         dev->trans_start =3D jiffies;=0A=
         netif_wake_queue ( dev );=0A=
+	port->start =3D 0;=0A=
 }=0A=
 =0A=
 =0A=
@@ -1366,13 +2457,12 @@=0A=
 {=0A=
         struct fst_card_info *card;=0A=
         struct fst_port_info *port;=0A=
-        unsigned char dmabits;=0A=
         unsigned long flags;=0A=
-        int pi;=0A=
-        int txp;=0A=
+	int txq_length;=0A=
 =0A=
         port =3D dev_to_port ( dev );=0A=
         card =3D port->card;=0A=
+	dbg(DBG_TX,"fst_start_xmit: length =3D %d\n", skb->len);=0A=
 =0A=
         /* Drop packet with error if we don't have carrier */=0A=
         if ( ! netif_carrier_ok ( dev ))=0A=
@@ -1380,56 +2470,74 @@=0A=
                 dev_kfree_skb ( skb );=0A=
                 port->hdlc.stats.tx_errors++;=0A=
                 port->hdlc.stats.tx_carrier_errors++;=0A=
+		dbg(DBG_ASS, "Tried to transmit but no carrier on card %d port =
%d\n",=0A=
+		    card->card_no, port->index);=0A=
                 return 0;=0A=
         }=0A=
 =0A=
         /* Drop it if it's too big! MTU failure ? */=0A=
         if ( skb->len > LEN_TX_BUFFER )=0A=
         {=0A=
-                dbg ( DBG_TX,"Packet too large %d vs %d\n", =
skb->len,=0A=
+                dbg ( DBG_ASS,"Packet too large %d vs %d\n", =
skb->len,=0A=
                                                 LEN_TX_BUFFER );=0A=
                 dev_kfree_skb ( skb );=0A=
                 port->hdlc.stats.tx_errors++;=0A=
                 return 0;=0A=
         }=0A=
 =0A=
-        /* Check we have a buffer */=0A=
-        pi =3D port->index;=0A=
+	/*=0A=
+	 * We are always going to queue the packet=0A=
+	 * so that the bottom half is the only place we tx from=0A=
+	 * Check there is room in the port txq=0A=
+	 */=0A=
         spin_lock_irqsave ( &card->card_lock, flags );=0A=
-        txp =3D port->txpos;=0A=
-        dmabits =3D FST_RDB ( card, txDescrRing[pi][txp].bits );=0A=
-        if ( dmabits & DMA_OWN )=0A=
-        {=0A=
-                spin_unlock_irqrestore ( &card->card_lock, flags );=0A=
-                dbg ( DBG_TX,"Out of Tx buffers\n");=0A=
-                dev_kfree_skb ( skb );=0A=
-                port->hdlc.stats.tx_errors++;=0A=
-                return 0;=0A=
-        }=0A=
-        if ( ++port->txpos >=3D NUM_TX_BUFFER )=0A=
-                port->txpos =3D 0;=0A=
-=0A=
-        if ( ++port->txcnt >=3D NUM_TX_BUFFER )=0A=
-                netif_stop_queue ( dev );=0A=
-=0A=
-        /* Release the card lock before we copy the data as we now =
have=0A=
-         * exclusive access to the buffer.=0A=
-         */=0A=
-        spin_unlock_irqrestore ( &card->card_lock, flags );=0A=
-=0A=
-        /* Enqueue the packet */=0A=
-        memcpy_toio ( card->mem + BUF_OFFSET ( =
txBuffer[pi][txp][0]),=0A=
-                                                skb->data, skb->len =
);=0A=
-        FST_WRW ( card, txDescrRing[pi][txp].bcnt, cnv_bcnt ( skb->len =
));=0A=
-        FST_WRB ( card, txDescrRing[pi][txp].bits, DMA_OWN | TX_STP | =
TX_ENP );=0A=
-=0A=
-        port->hdlc.stats.tx_packets++;=0A=
-        port->hdlc.stats.tx_bytes +=3D skb->len;=0A=
-=0A=
-        dev_kfree_skb ( skb );=0A=
+	if ((txq_length =3D port->txqe - port->txqs) < 0)=0A=
+	  {=0A=
+	    /*=0A=
+	     * This is the case where the next free has wrapped but the=0A=
+	     * last used hasn't=0A=
+	     */=0A=
+	    txq_length =3D txq_length + FST_TXQ_DEPTH;=0A=
+	  }=0A=
+	spin_unlock_irqrestore ( &card->card_lock, flags );=0A=
+	if (txq_length > fst_txq_high)=0A=
+	  {=0A=
+	    /*=0A=
+	     * We have got enough buffers in the pipeline.  Ask the =
network=0A=
+	     * layer to stop sending frames down=0A=
+	     */=0A=
+	    netif_stop_queue ( dev );=0A=
+	    port->start =3D 1;   /* I'm using this to signal stop sent up =
*/=0A=
+	  }=0A=
+=0A=
+	if (txq_length =3D=3D FST_TXQ_DEPTH - 1)=0A=
+	  {=0A=
+	    /*=0A=
+	     * This shouldn't have happened but such is life=0A=
+	     */=0A=
+	    dev_kfree_skb ( skb );=0A=
+	    port->hdlc.stats.tx_errors++;=0A=
+	    dbg(DBG_ASS, "Tx queue overflow card %d port %d\n",=0A=
+		card->card_no, port->index);=0A=
+	    return 0;=0A=
+	  }=0A=
+=0A=
+	/*=0A=
+	 * queue the buffer=0A=
+	 */=0A=
+        spin_lock_irqsave ( &card->card_lock, flags );=0A=
+	port->txq[port->txqe] =3D skb;=0A=
+	port->txqe++;=0A=
+	if (port->txqe =3D=3D FST_TXQ_DEPTH)=0A=
+	  port->txqe =3D 0;=0A=
+	spin_unlock_irqrestore ( &card->card_lock, flags );=0A=
+	=0A=
+	/* Scehdule the bottom half which now does transmit processing */=0A=
+        fst_q_work_item(&fst_work_txq, card->card_no);=0A=
+	queue_task(&fst_tx_task, &tq_immediate); =0A=
+	mark_bh(IMMEDIATE_BH); /* Note that this call must follow queue_task =
*/=0A=
 =0A=
-        dev->trans_start =3D jiffies;=0A=
-        return 0;=0A=
+	return 0;=0A=
 }=0A=
 =0A=
 =0A=
@@ -1443,7 +2551,11 @@=0A=
 static char *type_strings[] __devinitdata =3D {=0A=
         "no hardware",                  /* Should never be seen */=0A=
         "FarSync T2P",=0A=
-        "FarSync T4P"=0A=
+        "FarSync T4P",=0A=
+	"FarSync T1U",=0A=
+	"FarSync T2U",=0A=
+	"FarSync T4U",=0A=
+        "FarSync TE1"=0A=
 };=0A=
 =0A=
 static void __devinit=0A=
@@ -1462,22 +2574,19 @@=0A=
                 card->ports[i].card   =3D card;=0A=
                 card->ports[i].index  =3D i;=0A=
                 card->ports[i].run    =3D 0;=0A=
+                card->ports[i].mode   =3D FST_GEN_HDLC;=0A=
 =0A=
                 dev =3D hdlc_to_dev ( &card->ports[i].hdlc );=0A=
 =0A=
-                /* Fill in the net device info */=0A=
-                                /* Since this is a PCI setup this is =
purely=0A=
-                                 * informational. Give them the buffer =
addresses=0A=
-                                 * and basic card I/O.=0A=
-                                 */=0A=
+                /* Fill in the net device info =0A=
+                 * Since this is a PCI setup this is purely=0A=
+                 * informational. Give them the buffer addresses=0A=
+                 * and basic card I/O.=0A=
+                 */=0A=
                 dev->mem_start   =3D card->phys_mem=0A=
                                  + BUF_OFFSET ( txBuffer[i][0][0]);=0A=
                 dev->mem_end     =3D card->phys_mem=0A=
                                  + BUF_OFFSET ( =
txBuffer[i][NUM_TX_BUFFER][0]);=0A=
-                dev->rmem_start  =3D card->phys_mem=0A=
-                                 + BUF_OFFSET ( rxBuffer[i][0][0]);=0A=
-                dev->rmem_end    =3D card->phys_mem=0A=
-                                 + BUF_OFFSET ( =
rxBuffer[i][NUM_RX_BUFFER][0]);=0A=
                 dev->base_addr   =3D card->pci_conf;=0A=
                 dev->irq         =3D card->irq;=0A=
 =0A=
@@ -1505,6 +2614,29 @@=0A=
                         hdlc_to_dev(&card->ports[0].hdlc)->name,=0A=
                         =
hdlc_to_dev(&card->ports[card->nports-1].hdlc)->name,=0A=
                         type_strings[card->type], card->irq, =
card->nports );=0A=
+=0A=
+	if (card->family =3D=3D FST_FAMILY_TXU)=0A=
+	  {=0A=
+	    /*=0A=
+	     * Allocate a dma buffer for transmit and receives=0A=
+	     */=0A=
+	    card->rx_dma_handle_host =3D =0A=
+	      pci_alloc_consistent(card->device, FST_MAX_MTU, =0A=
+				   &card->rx_dma_handle_card);=0A=
+	    if (card->rx_dma_handle_host =3D=3D NULL)=0A=
+	      {=0A=
+		printk_err("Could not allocate rx dma buffer\n");=0A=
+		return;=0A=
+	      }=0A=
+	    card->tx_dma_handle_host =3D =0A=
+	      pci_alloc_consistent(card->device, FST_MAX_MTU,=0A=
+				   &card->tx_dma_handle_card);=0A=
+	    if (card->tx_dma_handle_host =3D=3D NULL)=0A=
+	      {=0A=
+		printk_err("Could not allocate tx dma buffer\n");=0A=
+		return;=0A=
+	      }=0A=
+	  }=0A=
 }=0A=
 =0A=
 =0A=
@@ -1516,16 +2648,39 @@=0A=
 fst_add_one ( struct pci_dev *pdev, const struct pci_device_id *ent =
)=0A=
 {=0A=
         static int firsttime_done =3D 0;=0A=
+	static int no_of_cards_added =3D 0;=0A=
         struct fst_card_info *card;=0A=
         int err =3D 0;=0A=
+	int i;=0A=
 =0A=
         if ( ! firsttime_done )=0A=
         {=0A=
                 printk ( KERN_INFO "FarSync X21 driver " =
FST_USER_VERSION=0A=
-                                " (c) 2001 FarSite Communications =
Ltd.\n");=0A=
+                         " (c) 2001-2003 FarSite Communications =
Ltd.\n");=0A=
                 firsttime_done =3D 1;=0A=
+		dbg(DBG_ASS, "The value of debug mask is %x\n", fst_debug_mask);=0A=
         }=0A=
 =0A=
+	/*=0A=
+	 * We are going to be clever and allow certain cards not to be=0A=
+	 * configured.  An exclude list can be provided in =
/etc/modules.conf=0A=
+	 */=0A=
+	if (fst_excluded_cards !=3D 0)=0A=
+	  {=0A=
+	    /*=0A=
+	     * There are cards to exclude=0A=
+	     *=0A=
+	     */=0A=
+	    for (i=3D0; i< fst_excluded_cards; i++)=0A=
+	      {=0A=
+		if ((pdev->devfn)>>3 =3D=3D fst_excluded_list[i])=0A=
+		  {=0A=
+		    printk("FarSync PCI device %d not assigned\n", =
(pdev->devfn)>>3);=0A=
+		    return -EBUSY;=0A=
+		  }=0A=
+	      }=0A=
+	  }=0A=
+=0A=
         /* Allocate driver private data */=0A=
         card =3D kmalloc ( sizeof ( struct fst_card_info ),  =
GFP_KERNEL);=0A=
         if (card =3D=3D NULL)=0A=
@@ -1536,6 +2691,13 @@=0A=
         }=0A=
         memset ( card, 0, sizeof ( struct fst_card_info ));=0A=
 =0A=
+        /* Try to enable the device */=0A=
+        if (( err =3D pci_enable_device ( pdev )) !=3D 0 )=0A=
+        {=0A=
+                printk_err ("Failed to enable card. Err %d\n", -err =
);=0A=
+                goto error_free_card;=0A=
+        }=0A=
+=0A=
         /* Record info we need*/=0A=
         card->irq         =3D pdev->irq;=0A=
         card->pci_conf    =3D pci_resource_start ( pdev, 1 );=0A=
@@ -1543,9 +2705,18 @@=0A=
         card->phys_ctlmem =3D pci_resource_start ( pdev, 3 );=0A=
 =0A=
         card->type        =3D ent->driver_data;=0A=
-        card->nports      =3D ( ent->driver_data =3D=3D FST_TYPE_T2P ) =
? 2 : 4;=0A=
+	card->family       =3D (( ent->driver_data =3D=3D FST_TYPE_T2P ) =
||=0A=
+                             ( ent->driver_data =3D=3D FST_TYPE_T4P ) =
) =0A=
+	                     ? FST_FAMILY_TXP : FST_FAMILY_TXU;=0A=
+	if ( ( ent->driver_data =3D=3D FST_TYPE_T1U ) ||=0A=
+             (ent->driver_data =3D=3D FST_TYPE_TE1) )=0A=
+	  card->nports =3D 1;=0A=
+	else=0A=
+	  card->nports      =3D (( ent->driver_data =3D=3D FST_TYPE_T2P ) || =
=0A=
+			       ( ent->driver_data =3D=3D FST_TYPE_T2U) ) ? 2 : 4;=0A=
 =0A=
         card->state       =3D FST_UNINIT;=0A=
+	card->device      =3D pdev;=0A=
 =0A=
         dbg ( DBG_PCI,"type %d nports %d irq %d\n", card->type,=0A=
                         card->nports, card->irq );=0A=
@@ -1553,13 +2724,26 @@=0A=
                         card->pci_conf, card->phys_mem, =
card->phys_ctlmem );=0A=
 =0A=
         /* Check we can get access to the memory and I/O regions */=0A=
-        if ( ! request_region ( card->pci_conf, 0x80,"PLX config =
regs"))=0A=
-        {=0A=
+	if (card->family =3D=3D FST_FAMILY_TXU)=0A=
+	  {=0A=
+	    if ( ! request_region ( card->pci_conf, 0x100,"PLX 9054 config =
regs"))=0A=
+	      {=0A=
+                printk_err ("Unable to get config I/O @ 0x%04X\n",=0A=
+			    card->pci_conf );=0A=
+                err =3D -ENODEV;=0A=
+                goto error_free_card;=0A=
+	      }=0A=
+	  }=0A=
+	else=0A=
+	  {=0A=
+            if ( ! request_region ( card->pci_conf, 0x80,"PLX 9050/2 =
config regs"))=0A=
+              {=0A=
                 printk_err ("Unable to get config I/O @ 0x%04X\n",=0A=
                                                 card->pci_conf );=0A=
                 err =3D -ENODEV;=0A=
                 goto error_free_card;=0A=
-        }=0A=
+             }=0A=
+          }=0A=
         if ( ! request_mem_region ( card->phys_mem, =
FST_MEMSIZE,"Shared RAM"))=0A=
         {=0A=
                 printk_err ("Unable to get main memory @ 0x%08X\n",=0A=
@@ -1575,12 +2759,6 @@=0A=
                 goto error_release_mem;=0A=
         }=0A=
 =0A=
-        /* Try to enable the device */=0A=
-        if (( err =3D pci_enable_device ( pdev )) !=3D 0 )=0A=
-        {=0A=
-                printk_err ("Failed to enable card. Err %d\n", -err =
);=0A=
-                goto error_release_ctlmem;=0A=
-        }=0A=
 =0A=
         /* Get virtual addresses of memory regions */=0A=
         if (( card->mem =3D ioremap ( card->phys_mem, FST_MEMSIZE )) =
=3D=3D NULL )=0A=
@@ -1601,6 +2779,9 @@=0A=
         fst_cpureset ( card );=0A=
         card->state =3D FST_RESET;=0A=
 =0A=
+	/* Initialise DMA (if required) */=0A=
+	fst_init_dma ( card );=0A=
+=0A=
         /* Register the interrupt handler */=0A=
         if ( request_irq ( card->irq, fst_intr, SA_SHIRQ, =
FST_DEV_NAME, card ))=0A=
         {=0A=
@@ -1612,8 +2793,14 @@=0A=
 =0A=
         /* Record driver data for later use */=0A=
         pci_set_drvdata(pdev, card);=0A=
+	if (!pci_dma_supported(pdev, 0xffffffff))=0A=
+	  {=0A=
+	    printk("Can't do DMA on this device\n");=0A=
+	  }=0A=
 =0A=
         /* Remainder of card setup */=0A=
+        fst_card_array[no_of_cards_added] =3D card;=0A=
+	card->card_no =3D no_of_cards_added++;  /* Record instance and bump =
it */=0A=
         fst_init_card ( card );=0A=
 =0A=
         return 0;                       /* Success */=0A=
@@ -1665,9 +2852,28 @@=0A=
 =0A=
         release_mem_region ( card->phys_ctlmem, 0x10 );=0A=
         release_mem_region ( card->phys_mem, FST_MEMSIZE );=0A=
-        release_region ( card->pci_conf, 0x80 );=0A=
-=0A=
-        kfree ( card );=0A=
+	if (card->family =3D=3D FST_FAMILY_TXU)=0A=
+	  {=0A=
+	    release_region ( card->pci_conf, 0x100 );=0A=
+	  }=0A=
+	else=0A=
+	  {=0A=
+	    release_region ( card->pci_conf, 0x80 );=0A=
+	  }=0A=
+=0A=
+	if ( card->family =3D=3D FST_FAMILY_TXU)=0A=
+	  {=0A=
+	    /*=0A=
+	     * Free dma buffers=0A=
+	     */=0A=
+	    pci_free_consistent(card->device, FST_MAX_MTU, =0A=
+                                card->rx_dma_handle_host, =0A=
+				card->rx_dma_handle_card);=0A=
+	    pci_free_consistent(card->device, FST_MAX_MTU, =0A=
+                                card->tx_dma_handle_host, =0A=
+				card->tx_dma_handle_card);=0A=
+	  }=0A=
+        fst_card_array[card->card_no] =3D NULL;=0A=
 }=0A=
 =0A=
 static struct pci_driver fst_driver =3D {=0A=
@@ -1682,15 +2888,31 @@=0A=
 static int __init=0A=
 fst_init(void)=0A=
 {=0A=
+        int i;=0A=
+=0A=
+        for (i=3D0; i<FST_MAX_CARDS; i++)=0A=
+          fst_card_array[i] =3D NULL;=0A=
+        //INIT_WORK(&fst_int_task, fst_process_int_work_q, 0); =0A=
+        //INIT_WORK(&fst_tx_task, fst_process_tx_work_q, 0);=0A=
+        /*=0A=
+         * There must be a macro for this ????=0A=
+         */=0A=
+	memset (&fst_tx_task, 0, sizeof(struct tq_struct));=0A=
+	memset (&fst_int_task, 0, sizeof(struct tq_struct));=0A=
+	fst_int_task.data =3D 0; =0A=
+	fst_tx_task.data =3D 0;=0A=
+        fst_int_task.routine =3D fst_process_int_work_q; =0A=
+        fst_tx_task.routine =3D fst_process_tx_work_q;=0A=
+        spin_lock_init ( &fst_work_q_lock );=0A=
         return pci_module_init ( &fst_driver );=0A=
 }=0A=
 =0A=
 static void __exit=0A=
 fst_cleanup_module(void)=0A=
 {=0A=
+        printk_info ( "FarSync X21 driver unloading\n");=0A=
         pci_unregister_driver ( &fst_driver );=0A=
 }=0A=
 =0A=
 module_init ( fst_init );=0A=
 module_exit ( fst_cleanup_module );=0A=
-=0A=
diff -urN linux-2.4.25-orig/drivers/net/wan/farsync.h =
linux/drivers/net/wan/farsync.h=0A=
--- linux-2.4.25-orig/drivers/net/wan/farsync.h	2004-02-04 =
12:08:41.000000000 +0000=0A=
+++ linux/drivers/net/wan/farsync.h	2004-02-04 12:19:38.000000000 =
+0000=0A=
@@ -32,8 +32,13 @@=0A=
  *      A short common prefix is useful for routines within the driver =
to avoid=0A=
  *      conflict with other similar drivers and I chosen to use "fst_" =
for this=0A=
  *      purpose (FarSite T-series).=0A=
+ *=0A=
+ *      Finally the device driver needs a short network interface =
name. Since=0A=
+ *      "hdlc" is already in use I've chosen the even less informative =
"sync"=0A=
+ *      for the present.=0A=
  */=0A=
 #define FST_NAME                "fst"           /* In debug/info etc =
*/=0A=
+#define FST_NDEV_NAME           "sync"          /* For net interface =
*/=0A=
 #define FST_DEV_NAME            "farsync"       /* For misc interfaces =
*/=0A=
 =0A=
 =0A=
@@ -45,7 +50,7 @@=0A=
  *      have individual versions (or IDs) that move much faster than =
the=0A=
  *      the release version as individual updates are tracked.=0A=
  */=0A=
-#define FST_USER_VERSION        "0.09"=0A=
+#define FST_USER_VERSION        "1.04"=0A=
 =0A=
 =0A=
 /*      Ioctl call command values=0A=
@@ -100,6 +105,7 @@=0A=
         unsigned int   state;           /* State of card */=0A=
         unsigned int   index;           /* Index of port ioctl was =
issued on */=0A=
         unsigned int   smcFirmwareVersion;=0A=
+        unsigned long  kernelVersion;   /* What Kernel version we are =
working with */=0A=
         unsigned short lineInterface;   /* Physical interface type =
*/=0A=
         unsigned char  proto;           /* Line protocol */=0A=
         unsigned char  internalClock;   /* 1 =3D> internal clock, 0 =
=3D> external */=0A=
@@ -110,6 +116,31 @@=0A=
         unsigned short cableStatus;     /* lsb: 0=3D> present, 1=3D> =
absent */=0A=
         unsigned short cardMode;        /* lsb: LED id mode */=0A=
         unsigned short debug;           /* Debug flags */=0A=
+        unsigned char  transparentMode; /* Not used always 0 */=0A=
+        unsigned char  invertClock;     /* Invert clock feature for =
syncing */=0A=
+        unsigned char  startingSlot;    /* Time slot to use for start =
of tx */=0A=
+        unsigned char  clockSource;     /* External or internal */=0A=
+        unsigned char  framing;         /* E1, T1 or J1 */=0A=
+        unsigned char  structure;       /* unframed, double, crc4, f4, =
f12, */=0A=
+                                        /* f24 f72 */=0A=
+        unsigned char  interface;       /* rj48c or bnc */=0A=
+        unsigned char  coding;          /* hdb3 b8zs */=0A=
+        unsigned char  lineBuildOut;    /* 0, -7.5, -15, -22 */=0A=
+        unsigned char  equalizer;       /* short or lon haul settings =
*/=0A=
+        unsigned char  loopMode;        /* various loopbacks */=0A=
+        unsigned char  range;           /* cable lengths */=0A=
+        unsigned char  txBufferMode;    /* tx elastic buffer depth =
*/=0A=
+        unsigned char  rxBufferMode;    /* rx elastic buffer depth =
*/=0A=
+        unsigned char  losThreshold;    /* Attenuation on LOS signal =
*/=0A=
+        unsigned char  idleCode;        /* Value to send as idle =
timeslot */=0A=
+        unsigned int   receiveBufferDelay; /* delay thro rx buffer =
timeslots */=0A=
+        unsigned int   framingErrorCount; /* framing errors */=0A=
+        unsigned int   codeViolationCount; /* code violations */=0A=
+        unsigned int   crcErrorCount;   /* CRC errors */=0A=
+        int            lineAttenuation; /* in dB*/=0A=
+        unsigned short lossOfSignal;=0A=
+        unsigned short receiveRemoteAlarm;=0A=
+        unsigned short alarmIndicationSignal;=0A=
 };=0A=
 =0A=
 /* "valid" bitmask */=0A=
@@ -131,13 +162,23 @@=0A=
                                          */=0A=
 #define FSTVAL_PROTO    0x00000200      /* proto */=0A=
 #define FSTVAL_MODE     0x00000400      /* cardMode */=0A=
+#define FSTVAL_PHASE    0x00000800      /* Clock phase */=0A=
+#define FSTVAL_TE1      0x00001000      /* T1E1 Configuration */=0A=
 #define FSTVAL_DEBUG    0x80000000      /* debug */=0A=
-#define FSTVAL_ALL      0x000007FF      /* Note: does not include =
DEBUG flag */=0A=
+#define FSTVAL_ALL      0x00001FFF      /* Note: does not include =
DEBUG flag */=0A=
 =0A=
 /* "type" */=0A=
 #define FST_TYPE_NONE   0               /* Probably should never =
happen */=0A=
 #define FST_TYPE_T2P    1               /* T2P X21 2 port card */=0A=
 #define FST_TYPE_T4P    2               /* T4P X21 4 port card */=0A=
+#define FST_TYPE_T1U    3               /* T1U X21 1 port card */=0A=
+#define FST_TYPE_T2U    4               /* T2U X21 2 port card */=0A=
+#define FST_TYPE_T4U    5               /* T4U X21 4 port card */=0A=
+#define FST_TYPE_TE1    6               /* T1E1 X21 1 port card */=0A=
+=0A=
+/* "family" */=0A=
+#define FST_FAMILY_TXP  0               /* T2P or T4P */=0A=
+#define FST_FAMILY_TXU  1               /* T1U or T2U or T4U */=0A=
 =0A=
 /* "state" */=0A=
 #define FST_UNINIT      0               /* Raw uninitialised state =
following=0A=
@@ -155,6 +196,10 @@=0A=
 #define V24             1=0A=
 #define X21             2=0A=
 #define V35             3=0A=
+#define X21D            4=0A=
+#define T1              5=0A=
+#define E1              6=0A=
+#define J1              7=0A=
 =0A=
 /* "proto" */=0A=
 #define FST_HDLC        1               /* Cisco compatible HDLC */=0A=
@@ -187,6 +232,97 @@=0A=
 /* "cardMode" bitmask */=0A=
 #define CARD_MODE_IDENTIFY      0x0001=0A=
 =0A=
+/* =0A=
+ * Constants for T1/E1 configuration=0A=
+ */=0A=
+=0A=
+/*=0A=
+ * Clock source=0A=
+ */=0A=
+#define CLOCKING_SLAVE       0=0A=
+#define CLOCKING_MASTER      1=0A=
+=0A=
+/*=0A=
+ * Framing=0A=
+ */=0A=
+#define FRAMING_E1           0=0A=
+#define FRAMING_J1           1=0A=
+#define FRAMING_T1           2=0A=
+=0A=
+/*=0A=
+ * Structure=0A=
+ */=0A=
+#define STRUCTURE_UNFRAMED   0=0A=
+#define STRUCTURE_E1_DOUBLE  1=0A=
+#define STRUCTURE_E1_CRC4    2=0A=
+#define STRUCTURE_E1_CRC4M   3=0A=
+#define STRUCTURE_T1_4       4=0A=
+#define STRUCTURE_T1_12      5=0A=
+#define STRUCTURE_T1_24      6=0A=
+#define STRUCTURE_T1_72      7=0A=
+=0A=
+/*=0A=
+ * Interface=0A=
+ */=0A=
+#define INTERFACE_RJ48C      0=0A=
+#define INTERFACE_BNC        1=0A=
+=0A=
+/*=0A=
+ * Coding=0A=
+ */=0A=
+=0A=
+#define CODING_HDB3          0=0A=
+#define CODING_NRZ           1=0A=
+#define CODING_CMI           2=0A=
+#define CODING_CMI_HDB3      3=0A=
+#define CODING_CMI_B8ZS      4=0A=
+#define CODING_AMI           5=0A=
+#define CODING_AMI_ZCS       6=0A=
+#define CODING_B8ZS          7=0A=
+=0A=
+/*=0A=
+ * Line Build Out=0A=
+ */=0A=
+#define LBO_0dB              0=0A=
+#define LBO_7dB5             1=0A=
+#define LBO_15dB             2=0A=
+#define LBO_22dB5            3=0A=
+=0A=
+/*=0A=
+ * Range for long haul t1 > 655ft=0A=
+ */=0A=
+#define RANGE_0_133_FT       0=0A=
+#define RANGE_0_40_M         RANGE_0_133_FT=0A=
+#define RANGE_133_266_FT     1=0A=
+#define RANGE_40_81_M        RANGE_133_266_FT=0A=
+#define RANGE_266_399_FT     2=0A=
+#define RANGE_81_122_M       RANGE_266_399_FT=0A=
+#define RANGE_399_533_FT     3=0A=
+#define RANGE_122_162_M       RANGE_399_533_FT=0A=
+#define RANGE_533_655_FT     4=0A=
+#define RANGE_162_200_M      RANGE_533_655_FT=0A=
+/*=0A=
+ * Receive Equaliser=0A=
+ */=0A=
+#define EQUALIZER_SHORT      0=0A=
+#define EQUALIZER_LONG       1=0A=
+=0A=
+/*=0A=
+ * Loop modes=0A=
+ */=0A=
+#define LOOP_NONE            0=0A=
+#define LOOP_LOCAL           1=0A=
+#define LOOP_PAYLOAD_EXC_TS0 2=0A=
+#define LOOP_PAYLOAD_INC_TS0 3=0A=
+#define LOOP_REMOTE          4=0A=
+=0A=
+/*=0A=
+ * Buffer modes=0A=
+ */=0A=
+#define BUFFER_2_FRAME       0=0A=
+#define BUFFER_1_FRAME       1=0A=
+#define BUFFER_96_BIT        2=0A=
+#define BUFFER_NONE          3=0A=
 =0A=
 /*      Debug support=0A=
  *=0A=
diff -urN linux-2.4.25-orig/include/linux/if.h =
linux/include/linux/if.h=0A=
--- linux-2.4.25-orig/include/linux/if.h	2004-02-04 12:08:25.000000000 =
+0000=0A=
+++ linux/include/linux/if.h	2004-02-04 12:26:14.000000000 +0000=0A=
@@ -62,6 +62,7 @@=0A=
 #define IF_IFACE_T1	0x1003		/* T1 telco serial interface	*/=0A=
 #define IF_IFACE_E1	0x1004		/* E1 telco serial interface	*/=0A=
 #define IF_IFACE_SYNC_SERIAL 0x1005	/* can't be set by software	*/=0A=
+#define IF_IFACE_X21D   0x1006          /* X.21 Dual Clocking =
(FarSite) */=0A=
 =0A=
 /* For definitions see hdlc.h */=0A=
 #define IF_PROTO_HDLC	0x2000		/* raw HDLC protocol		*/=0A=
@@ -76,6 +77,7 @@=0A=
 #define IF_PROTO_FR_DEL_ETH_PVC 0x2009	/*  Delete FR Ethernet-bridged =
PVC */=0A=
 #define IF_PROTO_FR_PVC	0x200A		/* for reading PVC status	*/=0A=
 #define IF_PROTO_FR_ETH_PVC 0x200B=0A=
+#define IF_PROTO_RAW    0x200C          /* RAW Socket                  =
 */=0A=
 =0A=
 =0A=
 /*=0A=

------_=_NextPart_000_01C3EB38.D1A7D900--

From chas@cmf.nrl.navy.mil Wed Feb  4 11:05:09 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 11:05:18 -0800 (PST)
Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14J58KO018752
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 11:05:09 -0800
Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180])
	by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id i14J4xRr017789;
	Wed, 4 Feb 2004 14:04:59 -0500 (EST)
Message-Id: <200402041904.i14J4xRr017789@ginger.cmf.nrl.navy.mil>
To: davem@redhat.com, "Randy.Dunlap" <rddunlap@osdl.org>
cc: netdev@oss.sgi.com
Subject: Re: [PATCH] atm/idt77252: correct printk of dma_addr_t 
In-Reply-To: Message from "Randy.Dunlap" <rddunlap@osdl.org> 
   of "Tue, 03 Feb 2004 15:34:48 PST." <20040203153448.5c81e49d.rddunlap@osdl.org> 
Date: Wed, 04 Feb 2004 14:05:00 -0500
From: chas williams (contractor) <chas@cmf.nrl.navy.mil>
X-Spam-Score: () hits=-0.3
X-Virus-Scanned: NAI Completed
X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
X-archive-position: 2989
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: chas@cmf.nrl.navy.mil
Precedence: bulk
X-list: netdev

dave, please apply the following to the 2.6 and 2.4 trees.

thanks!


# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1549  -> 1.1550 
#	drivers/atm/idt77252.c	1.21    -> 1.22   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 04/02/04	chas@relax.cmf.nrl.navy.mil	1.1550
# [ATM]: [idt77252] fix dma_addr_t type error with CONFIG_HIGHMEM64G=y (by "Randy.Dunlap" <rddunlap@osdl.org>)
# --------------------------------------------
#
diff -Nru a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c
--- a/drivers/atm/idt77252.c	Wed Feb  4 13:24:55 2004
+++ b/drivers/atm/idt77252.c	Wed Feb  4 13:24:55 2004
@@ -664,8 +664,8 @@
 	skb_queue_head_init(&scq->transmit);
 	skb_queue_head_init(&scq->pending);
 
-	TXPRINTK("idt77252: SCQ: base 0x%p, next 0x%p, last 0x%p, paddr %08x\n",
-		 scq->base, scq->next, scq->last, scq->paddr);
+	TXPRINTK("idt77252: SCQ: base 0x%p, next 0x%p, last 0x%p, paddr %08llx\n",
+		 scq->base, scq->next, scq->last, (unsigned long long)scq->paddr);
 
 	return scq;
 }

From chas@cmf.nrl.navy.mil Wed Feb  4 11:04:29 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 11:04:34 -0800 (PST)
Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14J4OKO018631
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 11:04:24 -0800
Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180])
	by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id i14J4GRr017777;
	Wed, 4 Feb 2004 14:04:16 -0500 (EST)
Message-Id: <200402041904.i14J4GRr017777@ginger.cmf.nrl.navy.mil>
To: davem@redhat.com, "Randy.Dunlap" <rddunlap@osdl.org>
Cc: netdev@oss.sgi.com
Subject: Re: Fw: [Kernel-janitors] net/atm/clip.c: check kmem_cache_create() #1 
In-Reply-To: Message from "Randy.Dunlap" <rddunlap@osdl.org> 
   of "Wed, 28 Jan 2004 09:18:03 PST." <20040128091803.1da4cf1c.rddunlap@osdl.org> 
Date: Wed, 04 Feb 2004 14:04:17 -0500
From: chas williams (contractor) <chas@cmf.nrl.navy.mil>
X-Spam-Score: () hits=-8.8
X-Virus-Scanned: NAI Completed
X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
X-archive-position: 2988
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: chas@cmf.nrl.navy.mil
Precedence: bulk
X-list: netdev

randy, i think it should probably return -ENOMEM instead of -1.

dave, please apply the following to both the 2.6 and 2.4 trees.

thanks!

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1548  -> 1.1549 
#	      net/atm/clip.c	1.29    -> 1.30   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 04/02/04	chas@relax.cmf.nrl.navy.mil	1.1549
# [ATM]: [clip] check return code from kmem_cache_create (by "Randy.Dunlap" <rddunlap@osdl.org>)
# --------------------------------------------
#
diff -Nru a/net/atm/clip.c b/net/atm/clip.c
--- a/net/atm/clip.c	Wed Feb  4 13:24:23 2004
+++ b/net/atm/clip.c	Wed Feb  4 13:24:23 2004
@@ -1021,6 +1021,9 @@
 	clip_tbl.kmem_cachep = kmem_cache_create(clip_tbl.id,
 	    clip_tbl.entry_size, 0, SLAB_HWCACHE_ALIGN, NULL, NULL);
 
+	if (!clip_tbl.kmem_cachep)
+		return -ENOMEM;
+
 	/* so neigh_ifdown() doesn't complain */
 	clip_tbl.proxy_timer.data = 0;
 	clip_tbl.proxy_timer.function = 0;



In message <20040128091803.1da4cf1c.rddunlap@osdl.org>,"Randy.Dunlap" writes:
>
>Hi Chas-
>
>What do you think of this patch?
>
>ISTM that the result of kmem_cache_create() should be checked,
>and this patch looks OK to me for a loadable module (it will
>fail loading).  But when this code is in the kernel image,
>will the rest of the code that depends on this kmem_cache_create()
>be OK, or will it try to use the kmem_cachep even though it
>is NULL?
>
>Thanks,
>~Randy
>~~~~~~~~~~~~~~~~~~~~~~~
>
>
>Begin forwarded message:
>
>Date: Sun, 25 Jan 2004 15:07:41 +0100
>From: <WHarms@bfs.de>(Walter Harms)
>To: <kernel-janitors@lists.osdl.org>
>Subject: [Kernel-janitors] net/atm/clip.c: check kmem_cache_create() #1
>
>
>
>
>--- net/atm/clip.c.org  2004-01-24 12:22:02.691771888 +0100
>+++ net/atm/clip.c      2004-01-24 12:27:57.074897464 +0100
>@@ -1026,6 +1026,9 @@
>        clip_tbl.kmem_cachep = kmem_cache_create(clip_tbl.id,
>            clip_tbl.entry_size, 0, SLAB_HWCACHE_ALIGN, NULL, NULL);
> 
>+       if (!clip_tbl.kmem_cachep)
>+               return -1;
>+
>        /* so neigh_ifdown() doesn't complain */
>        clip_tbl.proxy_timer.data = 0;
>        clip_tbl.proxy_timer.function = 0;
>_______________________________________________
>Kernel-janitors mailing list
>Kernel-janitors@lists.osdl.org
>http://lists.osdl.org/mailman/listinfo/kernel-janitors
>
>
>--
>~Randy
>kernel-janitors project:  http://janitor.kernelnewbies.org/
>

From errai110@kornet.net Wed Feb  4 11:12:04 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 11:12:08 -0800 (PST)
Received: from relay1.kornet.net (relay1.kornet.net [211.48.62.161])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14JC3KO019652
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 11:12:04 -0800
Received: from [211.197.3.93] (errai110@kornet.net) by 
          relay1.kornet.net (Terrace MailWatcher) 
          with ESMTP id 2004020504:11:57:554893.18361.26
          for <netdev@oss.sgi.com>; 
          Thu, 05 Feb 2004 04:11:57 +0900 (KST) 
Message-ID: <004101c3eb52$c3412d20$5d03c5d3@errai>
From: "Lee, Kuk-hyun" <errai110@kornet.net>
To: <netdev@oss.sgi.com>
Subject: [question] netif_rx() - why don't call raise_softirq()?
Date: Thu, 5 Feb 2004 04:11:58 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
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: 2990
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: errai110@kornet.net
Precedence: bulk
X-list: netdev

Hi,
I am newbie in the latest kernel development. Nowadays I am starting to work in
linux kernel. BTW, I find kernel code that I can't understand.
in bellow.

netif_rx() in 2.4.19
1238                         dev_hold(skb->dev);
1239                         __skb_queue_tail(&queue->input_pkt_queue,skb);
1240                         /* Runs from irqs or BH's, no need to wake BH */
1241                         cpu_raise_softirq(this_cpu, NET_RX_SOFTIRQ);
1242                         local_irq_restore(flags);

netif_rx() in 2.4.20
1254                         dev_hold(skb->dev);
1255                         __skb_queue_tail(&queue->input_pkt_queue,skb);
1256                         local_irq_restore(flags);

why 2.4.20's netif_rx() don't call raise_softirq()?  Is there never call net_rx_action()? 
maybe, IMHO, because NAPI. but I want to know exactly. I don't know reason why should 
you that. I could not find reason in google or netdev mailling list.

sorry for my stupid question. Any help is highly appriciated.
Thanks,
Lee



From leonid.grossman@s2io.com Wed Feb  4 12:52:25 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 12:52:29 -0800 (PST)
Received: from ns1.s2io.com (ns1.s2io.com [216.209.86.101])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14KqOKO025900
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 12:52:25 -0800
Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98])
	by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i14KjmjF011851;
	Wed, 4 Feb 2004 15:45:48 -0500 (EST)
Received: from lgt40 ([10.16.16.115])
	by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i14Kj7KK025663;
	Wed, 4 Feb 2004 15:45:08 -0500 (EST)
From: "Leonid Grossman" <leonid.grossman@s2io.com>
To: "'Andi Kleen'" <ak@suse.de>
Cc: <netdev@oss.sgi.com>, "'Ragu Vatsavayi'" <raghava.vatsavayi@s2io.com>,
        "'Grant Grundler'" <iod00d@hp.com>
Subject: RE: FW: Submission for S2io 10GbE driver
Date: Wed, 4 Feb 2004 12:44:21 -0800
Message-ID: <004201c3eb5f$ac4e9f00$740efea9@S2IOtech.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <20040123232209.2739e6aa.ak@suse.de>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Score: -101
X-Spam-Outlook-Score: ()
X-Spam-Features: IN_REP_TO,QUOTED_EMAIL_TEXT,USER_IN_WHITELIST
X-Scanned-By: MIMEDefang 2.34
X-archive-position: 2991
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: leonid.grossman@s2io.com
Precedence: bulk
X-list: netdev



> All the ARCH_PPC64 ifdefs shouldn't be needed. Can you remove 
> that? If there are problems in ppc64 code they should be 
> fixed there, not worked around. Same with the ifdefs for 
> kernel 2.6 features. An driver integrated into the kernel 
> should not contain such ifdefs.


Hi Andi,
You are right some of the ifdefs are not needed and we are removing
these; it is not clear if we can get rid of all of them for the
following reasons:

1) We did't find quad word memory operations(writeq and readq) on PCI
bus for PPC64 architecture.

2) We did't had a chance to test the driver on other big endian systems
apart from PPC64. In PPC64 architecture though,
I write/read a value to/from ioremaped address it swaps the value and
behaves like a little endian m/c:  

For ex: if I  do writel(0x12345678, addr) then in it writes 
addr: 78, (addr+1):56, (addr+2):34, (addr+3):12

On a little endian m/c like IA32 also writel writes same values in a
similar manner as shown above. 
So the question is -
Do all big endian machines with linux OS swap the values and write in
little endian format?? 

3)In PPC64 architecture dma_addr_t is u32, unlike remaining 64 bit
architectures where it is defined as u64. Because
of this we have to deal separately for PP64. 
So any suggestions will be useful, .i.e. generally how PPC64 developers
deal with this?

Say if we have some structure corresponding to memory region of our 
hardware device which should be of 16 bytes.

struct hw {
dma_addr_t  phys;
char            *virt;
#ifdef ARCH32 
u64 dummy;
#endif
}

Then above definition will not work for PPC64, we need to modify it like
this:
struct hw {
dma_addr_t  phys;
char            *virt;
#ifdef  ARCH32 
u64 dummy;
#endif
#ifdef ARCH_PPC64
u32 dummy;
#endif
}

 



 

 


From akpm@osdl.org Wed Feb  4 12:55:03 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 12:55:10 -0800 (PST)
Received: from mail.osdl.org (fw.osdl.org [65.172.181.6])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14Kt1KO026286
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 12:55:02 -0800
Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2])
	by mail.osdl.org (8.11.6/8.11.6) with SMTP id i14KstB09220
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 12:54:56 -0800
Date: Wed, 4 Feb 2004 12:56:25 -0800
From: Andrew Morton <akpm@osdl.org>
To: netdev@oss.sgi.com
Subject: Fw: [Bugme-new] [Bug 2017] New: 2.6.2 kernel panic when using IPSEC
Message-Id: <20040204125625.7cda3f0c.akpm@osdl.org>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 2992
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: akpm@osdl.org
Precedence: bulk
X-list: netdev



Begin forwarded message:

Date: Wed, 4 Feb 2004 12:48:26 -0800
From: bugme-daemon@osdl.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 2017] New: 2.6.2 kernel panic when using IPSEC


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

           Summary: 2.6.2 kernel panic when using IPSEC
    Kernel Version: 2.6.2
            Status: NEW
          Severity: high
             Owner: niv@us.ibm.com
         Submitter: linux.bugzilla@padilla.net


Distribution: Debian Stable
Hardware Environment: P-II 350, IDE
Software Environment:
Problem Description:


I upgraded to 2.6.2 today (from 2.6.1) and got a kernel panic as soon sa
I started using IPSEC (same config as I have been using with 2.6.1).
Following is the console output:


Unable to handle kernel NULL pointer dereference at virtual address
00000000
*pde = 00000000
Oops: 0002 [#1]
CPU:    0
EIP:    0060:[<c0117231>]    Not tainted
EFLAGS: 00010082
EIP is at schedule+0x139/0x4f4
eax: 00000001   ebx: 00000000   ecx: c0311d80   edx: c0311d60
esi: c0311d60   edi: c0311f28   ebp: c0389d70   esp: c0389d30
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c0388000 task=c0311d60)
Stack: c0388000 c0389db0 c0389dc4 c81a8cc0 c81a8cc0 cf1f62e0 00000002
cf1f62e0
       c0389e00 c0389dfc 00000246 0926bf51 9530848e 000006f2 c0311d60
c0311f28
       c0389dd4 c02a294d c0389df4 c81a8cc0 c81a8cc0 00000002 00029d00
00000003
Call Trace:
 [<c02a294d>] xfrm_lookup+0x1ed/0x45c
 [<c0117630>] default_wake_function+0x0/0x1c
 [<c0117630>] default_wake_function+0x0/0x1c
 [<c02a2be6>] _decode_session+0x2a/0x40
 [<c02a3283>] __xfrm_route_forward+0x2f/0x48
 [<c0273be7>] ip_forward+0x97/0x234
 [<c0272dc9>] ip_rcv_finish+0x1fd/0x244
 [<c0267cc8>] nf_hook_slow+0xcc/0x124
 [<c02729da>] ip_rcv+0x3ee/0x430
 [<c0272bcc>] ip_rcv_finish+0x0/0x244
 [<c025e8c4>] netif_receive_skb+0x150/0x1a8
 [<c025e98d>] process_backlog+0x71/0x104
 [<c025ea92>] net_rx_action+0x72/0x11c
 [<c011e0fe>] do_softirq+0x4e/0xa0
 [<c010afd1>] do_IRQ+0x115/0x130
 [<c0106f14>] default_idle+0x0/0x34
 [<c0105000>] _stext+0x0/0x5c
 [<c01097fc>] common_interrupt+0x18/0x20
 [<c0106f14>] default_idle+0x0/0x34
 [<c0105000>] _stext+0x0/0x5c
 [<c0106f3a>] default_idle+0x26/0x34
 [<c0106fc5>] cpu_idle+0x31/0x40
 [<c0105055>] _stext+0x55/0x5c
 [<c038a6aa>] start_kernel+0x176/0x17c


Code: ff 0b 8b 51 04 8b 46 20 89 50 04 89 02 c7 46 20 00 01 10 00
 <0>Kernel panic: Fatal exception in interrupt
In interrupt handler - not syncing

attached is the racoon.conf I'm using (aaa.bbb.ccc.ddd, eee.fff.ggg.hhh
and iii.jjj.kkk.lll are ip addresses):


path include "/usr/local/etc/racoon" ;
path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;

#log debug;

listen
{
        isakmp  aaa.bbb.ccc.ddd[500];
}

remote eee.fff.ggg.hhh {
        exchange_mode main;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group modp1024;
        }
}

sainfo address 172.31.0.0/24 any address iii.jjj.kkk.lll/27 any {
        pfs_group modp1024;
        encryption_algorithm 3des;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y

#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_CLEAN_COMPILE=y
CONFIG_STANDALONE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# 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_MPENTIUMII=y
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# 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_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HPET_TIMER is not set
# CONFIG_HPET_EMULATE_RTC is not set
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y

#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_ACPI_RELAXED_AML is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
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_PCI_USE_VECTOR is not set
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
# CONFIG_PCMCIA is not set
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m

#
# Device Drivers
#

#
# Generic Driver Options
#
# CONFIG_FW_LOADER 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 is not set
# CONFIG_PARPORT_OTHER is not set
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_LBD=y

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
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_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_IDEDISK_STROKE is not set
CONFIG_BLK_DEV_IDECD=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_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX 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_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW 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 is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_DMA_NONPCI is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=m
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m

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

#
# 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=m
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_MEGARAID 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_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_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_PAS16 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_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 is not set

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

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=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_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=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_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
# CONFIG_IP_NF_NAT_LOCAL is not set
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_NAT_AMANDA=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_CLASSIFY=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 is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
# CONFIG_VLAN_8021Q is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_CSZ=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NETDEVICES=y

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

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_MII is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL3 is not set
# CONFIG_3C515 is not set
CONFIG_VORTEX=m
# CONFIG_TYPHOON is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
CONFIG_NET_ISA=y
# CONFIG_E2100 is not set
# CONFIG_EWRK3 is not set
# CONFIG_EEXPRESS is not set
# CONFIG_EEXPRESS_PRO is not set
# CONFIG_HPLAN_PLUS is not set
# CONFIG_HPLAN is not set
# CONFIG_LP486E is not set
# CONFIG_ETH16I is not set
CONFIG_NE2000=m
# CONFIG_NET_PCI 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_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_FDDI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# Bluetooth support
#
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y

#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_USB_SCO=y
CONFIG_BT_USB_ZERO_PACKET=y
# CONFIG_BT_HCIUART is not set
# CONFIG_BT_HCIVHCI is not set

#
# ISDN subsystem
#
CONFIG_ISDN_BOOL=y

#
# Old ISDN4Linux
#
CONFIG_ISDN=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_MPP=y
CONFIG_ISDN_PPP_BSDCOMP=m
CONFIG_ISDN_AUDIO=y
CONFIG_ISDN_TTY_FAX=y

#
# ISDN feature submodules
#
CONFIG_ISDN_DRV_LOOP=m

#
# CAPI subsystem
#
# CONFIG_ISDN_CAPI is not set

#
# ISDN4Linux hardware drivers
#

#
# Passive cards
#
CONFIG_ISDN_DRV_HISAX=m

#
# D-channel protocol features
#
CONFIG_HISAX_EURO=y
# CONFIG_DE_AOC is not set
# CONFIG_HISAX_NO_SENDCOMPLETE is not set
# CONFIG_HISAX_NO_LLC is not set
# CONFIG_HISAX_NO_KEYPAD is not set
# CONFIG_HISAX_1TR6 is not set
# CONFIG_HISAX_NI1 is not set
CONFIG_HISAX_MAX_CARDS=8

#
# HiSax supported cards
#
# CONFIG_HISAX_16_0 is not set
CONFIG_HISAX_16_3=y
# CONFIG_HISAX_TELESPCI is not set
# CONFIG_HISAX_S0BOX is not set
# CONFIG_HISAX_AVM_A1 is not set
# CONFIG_HISAX_FRITZPCI is not set
# CONFIG_HISAX_AVM_A1_PCMCIA is not set
# CONFIG_HISAX_ELSA is not set
# CONFIG_HISAX_IX1MICROR2 is not set
# CONFIG_HISAX_DIEHLDIVA is not set
# CONFIG_HISAX_ASUSCOM is not set
# CONFIG_HISAX_TELEINT is not set
# CONFIG_HISAX_HFCS is not set
# CONFIG_HISAX_SEDLBAUER is not set
# CONFIG_HISAX_SPORTSTER is not set
# CONFIG_HISAX_MIC is not set
# CONFIG_HISAX_NETJET is not set
# CONFIG_HISAX_NETJET_U is not set
# CONFIG_HISAX_NICCY is not set
# CONFIG_HISAX_ISURF is not set
# CONFIG_HISAX_HSTSAPHIR is not set
# CONFIG_HISAX_BKM_A4T is not set
# CONFIG_HISAX_SCT_QUADRO is not set
# CONFIG_HISAX_GAZEL is not set
# CONFIG_HISAX_HFC_PCI is not set
# CONFIG_HISAX_W6692 is not set
# CONFIG_HISAX_HFC_SX is not set
# CONFIG_HISAX_ENTERNOW_PCI is not set
CONFIG_HISAX_DEBUG=y

#
# Active cards
#
# CONFIG_ISDN_DRV_ICN is not set
# CONFIG_ISDN_DRV_PCBIT is not set
# CONFIG_ISDN_DRV_SC is not set
# CONFIG_ISDN_DRV_ACT2000 is not set
# CONFIG_HYSDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
# CONFIG_I2C_ALGOBIT is not set
# CONFIG_I2C_ALGOPCF is not set

#
# I2C Hardware Bus support
#
# CONFIG_SCx200_ACB is not set

#
# I2C Hardware Sensors Chip support
#
# CONFIG_I2C_SENSOR is not set

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_QIC02_TAPE is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=m
CONFIG_RTC=m
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
CONFIG_DRM=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 is not set
# CONFIG_DRM_I830 is not set
CONFIG_DRM_MGA=y
# CONFIG_DRM_SIS is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#

#
# Video Adapters
#
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI 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_SF16FMI 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

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
# CONFIG_VIDEO_BTCX is not set

#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
# CONFIG_SND is not set

#
# Open Sound System
#
CONFIG_SOUND_PRIME=m
# CONFIG_SOUND_BT878 is not set
# CONFIG_SOUND_CMPCI is not set
# CONFIG_SOUND_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_ICH 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_SOUND_OSS=m
# CONFIG_SOUND_TRACEINIT is not set
# CONFIG_SOUND_DMAP 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 is not set
# CONFIG_SOUND_TRIX is not set
# CONFIG_SOUND_MSS is not set
# CONFIG_SOUND_MPU401 is not set
# CONFIG_SOUND_NM256 is not set
# CONFIG_SOUND_MAD16 is not set
# CONFIG_SOUND_PAS is not set
# CONFIG_SOUND_PSS is not set
CONFIG_SOUND_SB=m
# CONFIG_SOUND_AWE32_SYNTH is not set
# CONFIG_SOUND_WAVEFRONT is not set
# CONFIG_SOUND_MAUI is not set
# CONFIG_SOUND_YM3812 is not set
# CONFIG_SOUND_OPL3SA1 is not set
# CONFIG_SOUND_OPL3SA2 is not set
# CONFIG_SOUND_YMFPCI is not set
# CONFIG_SOUND_UART6850 is not set
# CONFIG_SOUND_AEDSP16 is not set
# CONFIG_SOUND_TVMIXER is not set
# CONFIG_SOUND_KAHLUA is not set
# CONFIG_SOUND_ALI5455 is not set
# CONFIG_SOUND_FORTE is not set
# CONFIG_SOUND_RME96XX is not set
# CONFIG_SOUND_AD1980 is not set

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

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y

#
# USB Host Controller Drivers
#
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set

#
# USB Bluetooth TTY can only be used with disabled Bluetooth subsystem
#
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=m
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_USB_HIDDEV is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_XPAD is not set

#
# USB Imaging devices
#
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_MICROTEK is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
CONFIG_USB_OV511=m
# CONFIG_USB_PWC is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_STV680 is not set
# CONFIG_USB_W9968CF is not set

#
# USB Network adaptors
#
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_USBNET is not set

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_TIGL is not set
# CONFIG_USB_LCD is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_QUOTA=y
CONFIG_QFMT_V1=m
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_DEVPTS_FS=y
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_SUNRPC=m
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
CONFIG_CIFS=m
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

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

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_FRAME_POINTER=y
CONFIG_X86_EXTRA_IRQS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
# CONFIG_SECURITY is not set

#
# 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_CAST6=m
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_TEST is not set

#
# Library routines
#
CONFIG_CRC32=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y


Steps to reproduce:

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

From jgarzik@pobox.com Wed Feb  4 13:18:19 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 13:18:27 -0800 (PST)
Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14LIIKO028051
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 13:18:19 -0800
Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:36796 helo=pobox.com)
	by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256)
	(Exim 4.22)
	id 1AoUPY-0003PJ-6g; Wed, 04 Feb 2004 21:18:16 +0000
Message-ID: <4021618B.7070605@pobox.com>
Date: Wed, 04 Feb 2004 16:18:03 -0500
From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kevin Curtis <kevin.curtis@farsite.co.uk>
CC: "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>,
        "'davem@redhat.com'" <davem@redhat.com>
Subject: Re: Update FarSync WAN driver in 2.4.25
References: <7C078C66B7752B438B88E11E5E20E72E25CBB5@general.hq.farsitecommunications.com>
In-Reply-To: <7C078C66B7752B438B88E11E5E20E72E25CBB5@general.hq.farsitecommunications.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-archive-position: 2993
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: jgarzik@pobox.com
Precedence: bulk
X-list: netdev

Comments:

* please use standard indentation (one tab)

* please use constants per the include/linux/pci_ids.h standard, rather 
than defining your own.

* please use standard include/linux/pci.h constants, rather than 
defining your own (PCIILR, etc.)

* further, obtain interrupt from struct pci_dev::irq after calling 
pci_enable_device(); do not obtain directly via pci_read_config_xxx()

* fst_process_rx_status() could result in flooding the log

* use pci_set_master() to enable bus-mastering

* bottom halves are deprecated.  do not add new code using mark_bh() and 
friends.  Use tasklets or schedule_task().

* use pci_set_dma_mask() rather than pci_dma_supported()

* use pci_request_regions() rather than request_region()




From romieu@fr.zoreil.com Wed Feb  4 13:36:13 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 13:36:17 -0800 (PST)
Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14LaBKO028903
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 13:36:12 -0800
Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1])
	by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i14LWwgf019736;
	Wed, 4 Feb 2004 22:32:58 +0100
Received: (from romieu@localhost)
	by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i14LWwAm019735;
	Wed, 4 Feb 2004 22:32:58 +0100
Date: Wed, 4 Feb 2004 22:32:58 +0100
From: Francois Romieu <romieu@fr.zoreil.com>
To: Kevin Curtis <kevin.curtis@farsite.co.uk>
Cc: "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>,
        "'davem@redhat.com'" <davem@redhat.com>,
        "'jgarzik@redhat.com'" <jgarzik@redhat.com>
Subject: Re: Update FarSync WAN driver in 2.4.25
Message-ID: <20040204223258.A19321@electric-eye.fr.zoreil.com>
References: <7C078C66B7752B438B88E11E5E20E72E25CBB5@general.hq.farsitecommunications.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <7C078C66B7752B438B88E11E5E20E72E25CBB5@general.hq.farsitecommunications.com>; from kevin.curtis@farsite.co.uk on Wed, Feb 04, 2004 at 04:06:16PM -0000
X-Organisation: Land of Sunshine Inc.
X-archive-position: 2994
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: romieu@fr.zoreil.com
Precedence: bulk
X-list: netdev

Kevin Curtis <kevin.curtis@farsite.co.uk> :
[...]
diff -urN linux-2.4.25-orig/drivers/net/wan/farsync.c linux/drivers/net/wan/farsync.c
--- linux-2.4.25-orig/drivers/net/wan/farsync.c	2004-02-04 12:08:41.000000000 +0000
+++ linux/drivers/net/wan/farsync.c	2004-02-04 13:15:45.000000000 +0000
[...]
+fst_recover_rx_error ( struct fst_card_info *card, struct fst_port_info *port,
+		   unsigned char dmabits, int rxp, unsigned short len)
+{
[...]
+	    if ( ++rxp >= NUM_RX_BUFFER )
+	      rxp = 0;

-> rxp = (rxp + 1) % NUM_RX_BUFFER; ?

   There are a few of those.

[...]
+	if (card->family == FST_FAMILY_TXU)
+	  {
+	    /*
+	     * Allocate a dma buffer for transmit and receives
+	     */
+	    card->rx_dma_handle_host = 
+	      pci_alloc_consistent(card->device, FST_MAX_MTU, 
+				   &card->rx_dma_handle_card);
+	    if (card->rx_dma_handle_host == NULL)
+	      {
+		printk_err("Could not allocate rx dma buffer\n");
+		return;
+	      }
+	    card->tx_dma_handle_host = 
+	      pci_alloc_consistent(card->device, FST_MAX_MTU,
+				   &card->tx_dma_handle_card);
+	    if (card->tx_dma_handle_host == NULL)
+	      {
+		printk_err("Could not allocate tx dma buffer\n");
+		return;
+	      }
+	  }

-> The error logic is broken. An error code should be returned to the caller
   if the allocation fails. Otherwise, the kernel will crash on module removal
   or if the device is further used.


@@ -1516,16 +2648,39 @@
[...]
+	    for (i=0; i< fst_excluded_cards; i++)
+	      {
+		if ((pdev->devfn)>>3 == fst_excluded_list[i])
+		  {
+		    printk("FarSync PCI device %d not assigned\n", (pdev->devfn)>>3);

-> printk(KERN_xxx/printk_xxx

--
Ueimor

From romieu@fr.zoreil.com Wed Feb  4 13:48:24 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 13:48:27 -0800 (PST)
Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14LmNKO029880
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 13:48:24 -0800
Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1])
	by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i14Llegf020044;
	Wed, 4 Feb 2004 22:47:40 +0100
Received: (from romieu@localhost)
	by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i14LleOo020043;
	Wed, 4 Feb 2004 22:47:40 +0100
Date: Wed, 4 Feb 2004 22:47:40 +0100
From: Francois Romieu <romieu@fr.zoreil.com>
To: chas williams <chas@cmf.nrl.navy.mil>
Cc: davem@redhat.com, "Randy.Dunlap" <rddunlap@osdl.org>, netdev@oss.sgi.com
Subject: Re: Fw: [Kernel-janitors] net/atm/clip.c: check kmem_cache_create() #1
Message-ID: <20040204224740.B19321@electric-eye.fr.zoreil.com>
References: <rddunlap@osdl.org> <200402041904.i14J4GRr017777@ginger.cmf.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200402041904.i14J4GRr017777@ginger.cmf.nrl.navy.mil>; from chas@cmf.nrl.navy.mil on Wed, Feb 04, 2004 at 02:04:17PM -0500
X-Organisation: Land of Sunshine Inc.
X-archive-position: 2995
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: romieu@fr.zoreil.com
Precedence: bulk
X-list: netdev

chas williams <chas@cmf.nrl.navy.mil> :
> randy, i think it should probably return -ENOMEM instead of -1.

One should probably apply the following patch on top of it btw.



Unbalanced call to create_proc_entry() on error path.


 net/atm/clip.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletion(-)

diff -puN net/atm/clip.c~clip-procfs-leak net/atm/clip.c
--- linux-2.6.2-rc3/net/atm/clip.c~clip-procfs-leak	2004-02-04 22:41:42.000000000 +0100
+++ linux-2.6.2-rc3-fr/net/atm/clip.c	2004-02-04 22:43:33.000000000 +0100
@@ -1021,8 +1021,10 @@ static int __init atm_clip_init(void)
 	clip_tbl.kmem_cachep = kmem_cache_create(clip_tbl.id,
 	    clip_tbl.entry_size, 0, SLAB_HWCACHE_ALIGN, NULL, NULL);
 
-	if (!clip_tbl.kmem_cachep)
+	if (!clip_tbl.kmem_cachep) {
+		remove_proc_entry("arp", atm_proc_root);
 		return -ENOMEM;
+	}
 
 	/* so neigh_ifdown() doesn't complain */
 	clip_tbl.proxy_timer.data = 0;

_


From dlstevens@us.ibm.com Wed Feb  4 13:50:11 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 13:50:15 -0800 (PST)
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14LoBKO030275
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 13:50:11 -0800
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i14Lnvo6475452;
	Wed, 4 Feb 2004 16:49:57 -0500
Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i14LnqOA063990;
	Wed, 4 Feb 2004 14:49:57 -0700
In-Reply-To: <20040204.203739.16838230.yoshfuji@linux-ipv6.org>
Importance: Normal
Sensitivity: 
Subject: Re: [PATCH] IPV6: note on shared socket options
To: YOSHIFUJI Hideaki /  =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
Cc: davem@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF2F9C078B.064A8A19-ON87256E30.0077B005-88256E30.0077AF76@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Wed, 4 Feb 2004 13:49:51 -0800
X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November
 14, 2003) at 02/04/2004 14:49:56
MIME-Version: 1.0
Content-type: multipart/alternative; 
	Boundary="0__=08BBE4A3DFE436958f9e8a93df938690918c08BBE4A3DFE43695"
Content-Disposition: inline
X-archive-position: 2996
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: dlstevens@us.ibm.com
Precedence: bulk
X-list: netdev

--0__=08BBE4A3DFE436958f9e8a93df938690918c08BBE4A3DFE43695
Content-type: text/plain; charset=ISO-2022-JP





Yoshifuji-san,
      These are defined by draft-ietf-magma-msf-api-03.txt to be in
netinet/in.h (no place else). What's the advantage of adding another
copy in in6.h (which currently isn't used by anything)? Portable user apps
must include netinet/in.h for them, and in-kernel code already does.

                        +-DLS


YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>@oss.sgi.com on
02/04/2004 03:37:39 AM

Sent by:    netdev-bounce@oss.sgi.com


To:    davem@redhat.com
cc:    yoshfuji@linux-ipv6.org, netdev@oss.sgi.com
Subject:    [PATCH] IPV6: note on shared socket options



Hello.

There're several socket options for multicast
shared between IPv4 and IPv6.
Add a note that some range is already used for them.

(Alternatevely, we could define other names like this:
 #define IPV6_MCAST_JOIN_GROUP   MCAST_JOIN_GROUP
 #define IPV6_MCAST_BLOCK_SOURCE MCAST_BLOCK_SOURCE
 /* bla, bla ... */
)

===== include/linux/in6.h 1.5 vs edited =====
--- 1.5/include/linux/in6.h   Fri Mar 21 14:23:30 2003
+++ edited/include/linux/in6.h      Wed Feb  4 20:30:47 2004
@@ -183,5 +183,17 @@
 #define IPV6_IPSEC_POLICY    34
 #define IPV6_XFRM_POLICY     35

+/*
+ * Multicast:
+ * Following socket options are shared between IPv4 and IPv6.
+ *
+ * MCAST_JOIN_GROUP          42
+ * MCAST_BLOCK_SOURCE        43
+ * MCAST_UNBLOCK_SOURCE            44
+ * MCAST_LEAVE_GROUP         45
+ * MCAST_JOIN_SOURCE_GROUP   46
+ * MCAST_LEAVE_SOURCE_GROUP  47
+ * MCAST_MSFILTER            48
+ */

 #endif

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

--0__=08BBE4A3DFE436958f9e8a93df938690918c08BBE4A3DFE43695
Content-type: text/html; charset=ISO-2022-JP
Content-Disposition: inline

<html><body>
<p>Yoshifuji-san,<br>
	These are defined by draft-ietf-magma-msf-api-03.txt to be in<br>
netinet/in.h (no place else). What's the advantage of adding another<br>
copy in in6.h (which currently isn't used by anything)? Portable user apps<br>
must include netinet/in.h for them, and in-kernel code already does.<br>
<br>
				+-DLS<br>
<br>

<p><font size="2" color="#800080">Sent by:	netdev-bounce@oss.sgi.com</font>
<p><font size="2" color="#800080">To:	</font><font size="2">davem@redhat.com</font><br>
<font size="2" color="#800080">cc:	</font><font size="2">yoshfuji@linux-ipv6.org, netdev@oss.sgi.com</font><font size="2" color="#800080"> </font><br>
<font size="2" color="#800080">Subject:	</font><font size="2">[PATCH] IPV6: note on shared socket options</font><br>
<br>
<br>
<br>
<tt>Hello.<br>
</tt><br>
<tt>There're several socket options for multicast<br>
shared between IPv4 and IPv6.<br>
Add a note that some range is already used for them.<br>
</tt><br>
<tt>(Alternatevely, we could define other names like this:<br>
#define IPV6_MCAST_JOIN_GROUP &nbsp; MCAST_JOIN_GROUP<br>
#define IPV6_MCAST_BLOCK_SOURCE MCAST_BLOCK_SOURCE<br>
/* bla, bla ... */</tt><br>
<tt>)<br>
</tt><br>
<tt>===== include/linux/in6.h 1.5 vs edited =====<br>
--- 1.5/include/linux/in6.h	Fri Mar 21 14:23:30 2003<br>
+++ edited/include/linux/in6.h	Wed Feb &nbsp;4 20:30:47 2004<br>
@@ -183,5 +183,17 @@</tt><br>
<tt>#define IPV6_IPSEC_POLICY	34<br>
#define IPV6_XFRM_POLICY	35</tt><br>
<br>
<tt>+/*<br>
+ * Multicast:<br>
+ * Following socket options are shared between IPv4 and IPv6.<br>
+ *<br>
+ * MCAST_JOIN_GROUP		42<br>
+ * MCAST_BLOCK_SOURCE		43<br>
+ * MCAST_UNBLOCK_SOURCE		44<br>
+ * MCAST_LEAVE_GROUP		45<br>
+ * MCAST_JOIN_SOURCE_GROUP	46<br>
+ * MCAST_LEAVE_SOURCE_GROUP	47<br>
+ * MCAST_MSFILTER		48<br>
+ */<br>
</tt><br>
<tt>#endif<br>
</tt><br>
<tt>--<br>
Hideaki YOSHIFUJI @ USAGI Project &lt;yoshfuji@linux-ipv6.org&gt;<br>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF &nbsp;80D8 4807 F894 E062 0EEA</tt><br>
<br>
</body></html>
--0__=08BBE4A3DFE436958f9e8a93df938690918c08BBE4A3DFE43695--


From x-y-z@laposte.net Wed Feb  4 14:13:09 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 14:14:16 -0800 (PST)
Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14MD7KO031625
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 14:13:09 -0800
Received: from laposte.net ([213.103.219.189]) by fep01-svc.swip.net
          with ESMTP
          id <20040204221301.EMKN3464.fep01-svc.swip.net@laposte.net>;
          Wed, 4 Feb 2004 23:13:01 +0100
Message-ID: <40216E6E.1000405@laposte.net>
Date: Wed, 04 Feb 2004 23:13:02 +0100
From: cityhunter <x-y-z@laposte.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040121
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: netdev@oss.sgi.com, c-d.hailfinger.kernel.2004@gmx.net
Subject: throughput measurements.
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-archive-position: 2997
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: x-y-z@laposte.net
Precedence: bulk
X-list: netdev

"We received success reports for nForce, nForce2 and nForce3 systems.
We'd appreciate throughput measurements."

ok 

jlm@Sorcerer:~$ uname -a
Linux Sorcerer 2.6.2 #1 Wed Feb 4 16:38:35 CET 2004 i686 unknown unknown GNU/Linux

doing a ftp transaction from my linux to windo$ filesize 650Mo mesured average 11202.6ko/s and most of the time stable :) 
this is better than nvidia!
nforce2 ABIT
this is a great job!

thanks! 



From c-d.hailfinger.kernel.2004@gmx.net Wed Feb  4 14:27:32 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 14:27:35 -0800 (PST)
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14MRVKO032325
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 14:27:31 -0800
Received: (qmail 15854 invoked by uid 65534); 4 Feb 2004 22:27:25 -0000
Received: from stud212019.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.212.19)
  by mail.gmx.net (mp021) with SMTP; 04 Feb 2004 23:27:25 +0100
X-Authenticated: #21910825
Message-ID: <402171C8.5060700@gmx.net>
Date: Wed, 04 Feb 2004 23:27:20 +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: cityhunter <x-y-z@laposte.net>
CC: netdev@oss.sgi.com
Subject: Re: throughput measurements.
References: <40216E6E.1000405@laposte.net>
In-Reply-To: <40216E6E.1000405@laposte.net>
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: 2998
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

cityhunter wrote:
> "We received success reports for nForce, nForce2 and nForce3 systems.
> We'd appreciate throughput measurements."
> 
> ok
> jlm@Sorcerer:~$ uname -a
> Linux Sorcerer 2.6.2 #1 Wed Feb 4 16:38:35 CET 2004 i686 unknown unknown
> GNU/Linux
> 
> doing a ftp transaction from my linux to windo$ filesize 650Mo mesured
> average 11202.6ko/s and most of the time stable :) this is better than
> nvidia!
> nforce2 ABIT

Thank you very much for the results. I have mentioned them at
http://www.hailfinger.org/carldani/linux/patches/forcedeth/


Regards,
Carl-Daniel


From c-d.hailfinger.kernel.2004@gmx.net Wed Feb  4 16:39:21 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 16:39:25 -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 i150dJKO013624
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 16:39:20 -0800
Received: (qmail 25764 invoked by uid 65534); 5 Feb 2004 00:39:14 -0000
Received: from stud212019.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.212.19)
  by mail.gmx.net (mp021) with SMTP; 05 Feb 2004 01:39:14 +0100
X-Authenticated: #21910825
Message-ID: <402190AC.2040307@gmx.net>
Date: Thu, 05 Feb 2004 01:39:08 +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: Jeff Garzik <jgarzik@pobox.com>
CC: Netdev <netdev@oss.sgi.com>, Manfred Spraul <manfred@colorfullife.com>
Subject: [PATCH] [2.6] Update forcedeth to 0.23
X-Enigmail-Version: 0.76.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/mixed;
 boundary="------------070401010800060103040508"
X-archive-position: 2999
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

This is a multi-part message in MIME format.
--------------070401010800060103040508
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jeff,

this patch updates forcedeth from current Linus tree to 0.23.

The main changes are:
- Support ethtool
- Make the generic function names more descriptive for backtraces
- other cleanups and bugfixes

This release addresses most of the points raised during past reviews. We
will continue to improve the driver, but right now 0.23 is far better than
its predecessors.

Please merge it into your netdrivers tree and feed it upstream.


Regards,
Carl-Daniel

--------------070401010800060103040508
Content-Type: text/plain;
 name="forcedeth_2_6_patch_v23.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="forcedeth_2_6_patch_v23.txt"

===== drivers/net/forcedeth.c 1.5 vs edited =====
--- 1.5/drivers/net/forcedeth.c	Fri Jan 16 01:47:29 2004
+++ edited/drivers/net/forcedeth.c	Thu Feb  5 01:15:27 2004
@@ -60,15 +60,24 @@
  * 			   addresses, really stop rx if already running
  * 			   in start_rx, clean up a bit.
  * 				(C) Carl-Daniel Hailfinger
- * 	0.20: 07 Dev 2003: alloc fixes
+ * 	0.20: 07 Dec 2003: alloc fixes
+ * 	0.21: 12 Jan 2004: additional alloc fix, nic polling fix.
+ *	0.22: 19 Jan 2004: reprogram timer to a sane rate, avoid lockup
+ * 			   on close.
+ * 				(C) Carl-Daniel Hailfinger, Manfred Spraul
+ *	0.23: 26 Jan 2004: various small cleanups
  *
  * Known bugs:
- * The irq handling is wrong - no tx done interrupts are generated.
- * This means recovery from netif_stop_queue only happens in the hw timer
- * interrupt (1/2 second on nForce2, 1/100 second on nForce3), or if an
- * rx packet arrives by chance.
+ * We suspect that on some hardware no TX done interrupts are generated.
+ * This means recovery from netif_stop_queue only happens if the hw timer
+ * interrupt fires (100 times/second, configurable with NVREG_POLL_DEFAULT)
+ * and the timer is active in the IRQMask, or if a rx packet arrives by chance.
+ * If your hardware reliably generates tx done interrupts, then you can remove
+ * DEV_NEED_TIMERIRQ from the driver_data flags.
+ * DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few
+ * superfluous timer interrupts from the nic.
  */
-#define FORCEDETH_VERSION		"0.19"
+#define FORCEDETH_VERSION		"0.23"
 
 #include <linux/module.h>
 #include <linux/types.h>
@@ -104,6 +113,7 @@
 #define DEV_NEED_LASTPACKET1	0x0001
 #define DEV_IRQMASK_1		0x0002
 #define DEV_IRQMASK_2		0x0004
+#define DEV_NEED_TIMERIRQ	0x0008
 
 enum {
 	NvRegIrqStatus = 0x000,
@@ -124,7 +134,12 @@
 	NvRegUnknownSetupReg6 = 0x008,
 #define NVREG_UNKSETUP6_VAL		3
 
+/*
+ * NVREG_POLL_DEFAULT is the interval length of the timer source on the nic
+ * NVREG_POLL_DEFAULT=97 would result in an interval length of 1 ms
+ */
 	NvRegPollingInterval = 0x00c,
+#define NVREG_POLL_DEFAULT	970
 	NvRegMisc1 = 0x080,
 #define NVREG_MISC1_HD		0x02
 #define NVREG_MISC1_FORCE	0x3b0f3c
@@ -286,7 +301,7 @@
 #define NV_WAKEUPMASKENTRIES	4
 
 /* General driver defaults */
-#define NV_WATCHDOG_TIMEO	(2*HZ)
+#define NV_WATCHDOG_TIMEO	(5*HZ)
 #define DEFAULT_MTU		1500	/* also maximum supported, at least for now */
 
 #define RX_RING		128
@@ -520,12 +535,12 @@
 }
 
 /*
- * get_stats: dev->get_stats function
+ * nv_get_stats: dev->get_stats function
  * Get latest stats value from the nic.
  * Called with read_lock(&dev_base_lock) held for read -
  * only synchronized against unregister_netdevice.
  */
-static struct net_device_stats *get_stats(struct net_device *dev)
+static struct net_device_stats *nv_get_stats(struct net_device *dev)
 {
 	struct fe_priv *np = get_nvpriv(dev);
 
@@ -536,14 +551,55 @@
 	return &np->stats;
 }
 
+static int nv_ethtool_ioctl (struct net_device *dev, void *useraddr)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+	u32 ethcmd;
+
+	if (copy_from_user(&ethcmd, useraddr, sizeof (ethcmd)))
+		return -EFAULT;
+
+	switch (ethcmd) {
+	case ETHTOOL_GDRVINFO:
+	{
+		struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO };
+		strcpy(info.driver, "forcedeth");
+		strcpy(info.version, FORCEDETH_VERSION);
+		strcpy(info.bus_info, pci_name(np->pci_dev));
+		if (copy_to_user(useraddr, &info, sizeof (info)))
+			return -EFAULT;
+		return 0;
+	}
+	case ETHTOOL_GLINK:
+	{
+		struct ethtool_value edata = { ETHTOOL_GLINK };
+
+		edata.data = !!netif_carrier_ok(dev);
+
+		if (copy_to_user(useraddr, &edata, sizeof(edata)))
+			return -EFAULT;
+		return 0;
+	}
 
+	default:
+		break;
+	}
+
+	return -EOPNOTSUPP;
+}
 /*
- * nic_ioctl: dev->do_ioctl function
+ * nv_ioctl: dev->do_ioctl function
  * Called with rtnl_lock held.
  */
-static int nic_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
+static int nv_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 {
-	return -EOPNOTSUPP;
+	switch(cmd) {
+	case SIOCETHTOOL:
+		return nv_ethtool_ioctl(dev, (void *) rq->ifr_data);
+
+	default:
+		return -EOPNOTSUPP;
+	}
 }
 
 /*
@@ -661,10 +717,10 @@
 }
 
 /*
- * start_xmit: dev->hard_start_xmit function
+ * nv_start_xmit: dev->hard_start_xmit function
  * Called with dev->xmit_lock held.
  */
-static int start_xmit(struct sk_buff *skb, struct net_device *dev)
+static int nv_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct fe_priv *np = get_nvpriv(dev);
 	int nr = np->next_tx % TX_RING;
@@ -679,7 +735,7 @@
 	spin_lock_irq(&np->lock);
 	wmb();
 	np->tx_ring[nr].Flags = np->tx_flags;
-	dprintk(KERN_DEBUG "%s: start_xmit: packet packet %d queued for transmission.\n",
+	dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission.\n",
 				dev->name, np->next_tx);
 	{
 		int j;
@@ -698,6 +754,7 @@
 		netif_stop_queue(dev);
 	spin_unlock_irq(&np->lock);
 	writel(NVREG_TXRXCTL_KICK, get_hwbase(dev) + NvRegTxRxControl);
+	pci_push(get_hwbase(dev));
 	return 0;
 }
 
@@ -743,10 +800,10 @@
 }
 
 /*
- * tx_timeout: dev->tx_timeout function
+ * nv_tx_timeout: dev->tx_timeout function
  * Called with dev->xmit_lock held.
  */
-static void tx_timeout(struct net_device *dev)
+static void nv_tx_timeout(struct net_device *dev)
 {
 	struct fe_priv *np = get_nvpriv(dev);
 	u8 *base = get_hwbase(dev);
@@ -797,13 +854,13 @@
 			break;	/* still owned by hardware, */
 
 		/*
-		 * the packet is for us - immediately tear down the pci mapping, and
-		 * prefetch the first cacheline of the packet.
+		 * the packet is for us - immediately tear down the pci mapping.
+		 * TODO: check if a prefetch of the first cacheline improves
+		 * the performance.
 		 */
 		pci_unmap_single(np->pci_dev, np->rx_dma[i],
 				np->rx_skbuff[i]->len,
 				PCI_DMA_FROMDEVICE);
-		prefetch(np->rx_skbuff[i]->data);
 
 		{
 			int j;
@@ -870,10 +927,10 @@
 }
 
 /*
- * change_mtu: dev->change_mtu function
+ * nv_change_mtu: dev->change_mtu function
  * Called with dev_base_lock held for read.
  */
-static int change_mtu(struct net_device *dev, int new_mtu)
+static int nv_change_mtu(struct net_device *dev, int new_mtu)
 {
 	if (new_mtu > DEFAULT_MTU)
 		return -EINVAL;
@@ -882,10 +939,10 @@
 }
 
 /*
- * change_mtu: dev->change_mtu function
+ * nv_set_multicast: dev->set_multicast function
  * Called with dev->xmit_lock held.
  */
-static void set_multicast(struct net_device *dev)
+static void nv_set_multicast(struct net_device *dev)
 {
 	struct fe_priv *np = get_nvpriv(dev);
 	u8 *base = get_hwbase(dev);
@@ -1098,13 +1155,13 @@
 	enable_irq(dev->irq);
 }
 
-static int open(struct net_device *dev)
+static int nv_open(struct net_device *dev)
 {
 	struct fe_priv *np = get_nvpriv(dev);
 	u8 *base = get_hwbase(dev);
 	int ret, oom, i;
 
-	dprintk(KERN_DEBUG "forcedeth: open\n");
+	dprintk(KERN_DEBUG "nv_open: begin\n");
 
 	/* 1) erase previous misconfiguration */
 	/* 4.1-1: stop adapter: ignored, 4.3 seems to be overkill */
@@ -1152,17 +1209,23 @@
 	for (i = 1; i < 32; i++) {
 		int id1, id2;
 
+		spin_lock_irq(&np->lock);
 		id1 = mii_rw(dev, i, MII_PHYSID1, MII_READ);
-		if (id1 < 0)
+		spin_unlock_irq(&np->lock);
+		if (id1 < 0 || id1 == 0xffff)
 			continue;
+		spin_lock_irq(&np->lock);
 		id2 = mii_rw(dev, i, MII_PHYSID2, MII_READ);
-		if (id2 < 0)
+		spin_unlock_irq(&np->lock);
+		if (id2 < 0 || id2 == 0xffff)
 			continue;
 		dprintk(KERN_DEBUG "%s: open: Found PHY %04x:%04x at address %d.\n",
 				dev->name, id1, id2, i);
 		np->phyaddr = i;
 
+		spin_lock_irq(&np->lock);
 		update_linkspeed(dev);
+		spin_unlock_irq(&np->lock);
 
 		break;
 	}
@@ -1185,6 +1248,7 @@
 	writel(NVREG_RNDSEED_FORCE | (i&NVREG_RNDSEED_MASK), base + NvRegRandomSeed);
 	writel(NVREG_UNKSETUP1_VAL, base + NvRegUnknownSetupReg1);
 	writel(NVREG_UNKSETUP2_VAL, base + NvRegUnknownSetupReg2);
+	writel(NVREG_POLL_DEFAULT, base + NvRegPollingInterval);
 	writel(NVREG_UNKSETUP6_VAL, base + NvRegUnknownSetupReg6);
 	writel((np->phyaddr << NVREG_ADAPTCTL_PHYSHIFT)|NVREG_ADAPTCTL_PHYVALID,
 			base + NvRegAdapterControl);
@@ -1198,9 +1262,9 @@
 			base + NvRegRingSizes);
 
 	i = readl(base + NvRegPowerState);
-	if ( (i & NVREG_POWERSTATE_POWEREDUP) == 0) {
+	if ( (i & NVREG_POWERSTATE_POWEREDUP) == 0)
 		writel(NVREG_POWERSTATE_POWEREDUP|i, base + NvRegPowerState);
-	}
+
 	pci_push(base);
 	udelay(10);
 	writel(readl(base + NvRegPowerState) | NVREG_POWERSTATE_VALID, base + NvRegPowerState);
@@ -1232,7 +1296,9 @@
 	netif_start_queue(dev);
 	if (oom)
 		mod_timer(&np->oom_kick, jiffies + OOM_REFILL);
-	if (!(mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ) & BMSR_ANEGCOMPLETE)) {
+	if (mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ) & BMSR_ANEGCOMPLETE) {
+		netif_carrier_on(dev);
+	} else {
 		printk("%s: no link during initialization.\n", dev->name);
 		netif_carrier_off(dev);
 	}
@@ -1245,9 +1311,10 @@
 	return ret;
 }
 
-static int close(struct net_device *dev)
+static int nv_close(struct net_device *dev)
 {
 	struct fe_priv *np = get_nvpriv(dev);
+	u8 *base;
 
 	spin_lock_irq(&np->lock);
 	np->in_shutdown = 1;
@@ -1261,6 +1328,13 @@
 	spin_lock_irq(&np->lock);
 	stop_tx(dev);
 	stop_rx(dev);
+	base = get_hwbase(dev);
+
+	/* disable interrupts on the nic or we will lock up */
+	writel(0, base + NvRegIrqMask);
+	pci_push(base);
+	dprintk(KERN_INFO "%s: Irqmask is zero again\n", dev->name);
+
 	spin_unlock_irq(&np->lock);
 
 	free_irq(dev->irq, dev);
@@ -1272,7 +1346,7 @@
 	return 0;
 }
 
-static int __devinit probe_nic(struct pci_dev *pci_dev, const struct pci_device_id *id)
+static int __devinit nv_probe(struct pci_dev *pci_dev, const struct pci_device_id *id)
 {
 	struct net_device *dev;
 	struct fe_priv *np;
@@ -1281,11 +1355,11 @@
 	int err, i;
 
 	dev = alloc_etherdev(sizeof(struct fe_priv));
-	np = get_nvpriv(dev);
 	err = -ENOMEM;
 	if (!dev)
 		goto out;
 
+	np = get_nvpriv(dev);
 	np->pci_dev = pci_dev;
 	spin_lock_init(&np->lock);
 	SET_MODULE_OWNER(dev);
@@ -1333,7 +1407,7 @@
 	err = -ENOMEM;
 	dev->base_addr = (unsigned long) ioremap(addr, NV_PCI_REGSZ);
 	if (!dev->base_addr)
-		goto out_disable;
+		goto out_relreg;
 	dev->irq = pci_dev->irq;
 	np->rx_ring = pci_alloc_consistent(pci_dev, sizeof(struct ring_desc) * (RX_RING + TX_RING),
 						&np->ring_addr);
@@ -1341,19 +1415,18 @@
 		goto out_unmap;
 	np->tx_ring = &np->rx_ring[RX_RING];
 
-	dev->open = open;
-	dev->stop = close;
-	dev->hard_start_xmit = start_xmit;
-	dev->get_stats = get_stats;
-	dev->change_mtu = change_mtu;
-	dev->set_multicast_list = set_multicast;
-	dev->do_ioctl = nic_ioctl;
-	dev->tx_timeout = tx_timeout;
+	dev->open = nv_open;
+	dev->stop = nv_close;
+	dev->hard_start_xmit = nv_start_xmit;
+	dev->get_stats = nv_get_stats;
+	dev->change_mtu = nv_change_mtu;
+	dev->set_multicast_list = nv_set_multicast;
+	dev->do_ioctl = nv_ioctl;
+	dev->tx_timeout = nv_tx_timeout;
 	dev->watchdog_timeo = NV_WATCHDOG_TIMEO;
 
 	pci_set_drvdata(pci_dev, dev);
 
-
 	/* read the mac address */
 	base = get_hwbase(dev);
 	np->orig_mac[0] = readl(base + NvRegMacAddrA);
@@ -1393,6 +1466,8 @@
 		np->irqmask = NVREG_IRQMASK_WANTED_1;
 	if (id->driver_data & DEV_IRQMASK_2)
 		np->irqmask = NVREG_IRQMASK_WANTED_2;
+	if (id->driver_data & DEV_NEED_TIMERIRQ)
+		np->irqmask |= NVREG_IRQ_TIMER;
 
 	err = register_netdev(dev);
 	if (err) {
@@ -1408,6 +1483,7 @@
 out_freering:
 	pci_free_consistent(np->pci_dev, sizeof(struct ring_desc) * (RX_RING + TX_RING),
 				np->rx_ring, np->ring_addr);
+	pci_set_drvdata(pci_dev, NULL);
 out_unmap:
 	iounmap(get_hwbase(dev));
 out_relreg:
@@ -1416,12 +1492,11 @@
 	pci_disable_device(pci_dev);
 out_free:
 	free_netdev(dev);
-	pci_set_drvdata(pci_dev, NULL);
 out:
 	return err;
 }
 
-static void __devexit remove_nic(struct pci_dev *pci_dev)
+static void __devexit nv_remove(struct pci_dev *pci_dev)
 {
 	struct net_device *dev = pci_get_drvdata(pci_dev);
 	struct fe_priv *np = get_nvpriv(dev);
@@ -1430,7 +1505,7 @@
 	unregister_netdev(dev);
 
 	/* special op: write back the misordered MAC address - otherwise
-	 * the next probe_nic would see a wrong address.
+	 * the next nv_probe would see a wrong address.
 	 */
 	writel(np->orig_mac[0], base + NvRegMacAddrA);
 	writel(np->orig_mac[1], base + NvRegMacAddrB);
@@ -1450,21 +1525,21 @@
 		.device = 0x1C3,
 		.subvendor = PCI_ANY_ID,
 		.subdevice = PCI_ANY_ID,
-		.driver_data = DEV_IRQMASK_1,
+		.driver_data = DEV_IRQMASK_1|DEV_NEED_TIMERIRQ,
 	},
 	{	/* nForce2 Ethernet Controller */
 		.vendor = PCI_VENDOR_ID_NVIDIA,
 		.device = 0x0066,
 		.subvendor = PCI_ANY_ID,
 		.subdevice = PCI_ANY_ID,
-		.driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2,
+		.driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ,
 	},
 	{	/* nForce3 Ethernet Controller */
 		.vendor = PCI_VENDOR_ID_NVIDIA,
 		.device = 0x00D6,
 		.subvendor = PCI_ANY_ID,
 		.subdevice = PCI_ANY_ID,
-		.driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2,
+		.driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ,
 	},
 	{0,},
 };
@@ -1472,8 +1547,8 @@
 static struct pci_driver driver = {
 	.name = "forcedeth",
 	.id_table = pci_tbl,
-	.probe = probe_nic,
-	.remove = __devexit_p(remove_nic),
+	.probe = nv_probe,
+	.remove = __devexit_p(nv_remove),
 };
 
 

--------------070401010800060103040508--


From grundler@cup.hp.com Wed Feb  4 16:48:34 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 16:48:39 -0800 (PST)
Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i150mPKO014166
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 16:48:34 -0800
Received: from hpuxmail.cup.hp.com (hpuxmail.cup.hp.com [15.13.189.207])
	by palrel10.hp.com (Postfix) with ESMTP
	id E35171C01042; Wed,  4 Feb 2004 16:48:24 -0800 (PST)
Received: from debian.cup.hp.com (postfix@[15.244.57.47])
	by hpuxmail.cup.hp.com (8.11.1/8.8.6) with ESMTP id i150mFo22268;
	Wed, 4 Feb 2004 16:48:15 -0800 (PST)
Received: by debian.cup.hp.com (Postfix, from userid 1001)
	id ABAA32F7CC; Wed,  4 Feb 2004 16:49:52 -0800 (PST)
Date: Wed, 4 Feb 2004 16:49:52 -0800
From: Grant Grundler <iod00d@hp.com>
To: Leonid Grossman <leonid.grossman@s2io.com>
Cc: "'Andi Kleen'" <ak@suse.de>, netdev@oss.sgi.com,
        "'Ragu Vatsavayi'" <raghava.vatsavayi@s2io.com>,
        "'Grant Grundler'" <iod00d@hp.com>
Subject: Re: FW: Submission for S2io 10GbE driver
Message-ID: <20040205004952.GA27510@cup.hp.com>
References: <20040123232209.2739e6aa.ak@suse.de> <004201c3eb5f$ac4e9f00$740efea9@S2IOtech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <004201c3eb5f$ac4e9f00$740efea9@S2IOtech.com>
User-Agent: Mutt/1.5.5.1+cvs20040105i
X-archive-position: 3000
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: iod00d@hp.com
Precedence: bulk
X-list: netdev

On Wed, Feb 04, 2004 at 12:44:21PM -0800, Leonid Grossman wrote:
> 1) We did't find quad word memory operations(writeq and readq) on PCI
> bus for PPC64 architecture.

I would consider that a bug in the PPC64 port. You can submit
a patch to add a readq/writeq implementation using 32-bit ops
if the PCI Host controller doesn't support 64-bit transactions.
This doesn't always work since two 32-bit writes to a 64-bit register
is not the same as one 64-bit write. Your HW needs to be aware
of that if you want to support that platform.


> 2) We did't had a chance to test the driver on other big endian systems
> apart from PPC64. In PPC64 architecture though,
> I write/read a value to/from ioremaped address it swaps the value and
> behaves like a little endian m/c:  
> 
> For ex: if I  do writel(0x12345678, addr) then in it writes 
> addr: 78, (addr+1):56, (addr+2):34, (addr+3):12
...
> On a little endian m/c like IA32 also writel writes same values in a
> similar manner as shown above. 
> So the question is -
> Do all big endian machines with linux OS swap the values and write in
> little endian format?? 

Yes - I believe so.
There are ways to avoid the byte swap but I'm really not keen
on advocating this path. byte swapping is so much cheaper than
the PIO Reads, it just doesn't make sense to obfuscate the
code most of the time.

> 3)In PPC64 architecture dma_addr_t is u32, unlike remaining 64 bit
> architectures where it is defined as u64. Because of this we have
> to deal separately for PP64. 

You shouldn't be using dma_addr_t for layout of data structures
shared with the card. Several architectures *only* use 32-bit
DMA addresses (IOMMU for all DMA). It makes sense on those
architectures to define dma_addr_t as u32.
Try "fgrep dma_addr_t include/asm*/* | fgrep typedef" on linux-2.6 tree.


> So any suggestions will be useful, .i.e. generally how PPC64 developers
> deal with this?

Only use dma_addr_t to map data and not to define data structures
consumed by the card.

Some history from my perspective:
Fri, 9 Feb 2001, I started a discussion on linux-mm@kvack.org mailing
list on exactly this issue for linux-2.4. At the time Dave Miller
"owned" DMA interface and insisted dma_addr_t be u32.
He offered dma64_addr_t would be introduced in linux-2.5.
So far so good.

The only problem was IA64 was already defining dma_addr_t as u64
and mips was using "unsigned long".

Issue came up again on linux-kernel/linux-ia64 Feb 6, 2002.
(Subject: Proper fix for sym53c8xx_2 driver and dma64_addr_t)
It was pretty clear pci_dac_XXX() was the "preferred" interface
to use. But it made it impossible for a driver to support multiple
chips that supported both.

Somewhere along the line, I think with more thrashing about on
pci_set_dma_mask(), it was decided it was ok for dma_addr_t to
be u64 on architectures that supported it.

Last step into this mess was "64 Bits DMA Addresses for Alloc Consistent
Interfaces" thread started by SGI. Altix box needed it in order to
support PCI-X devices in PCI-X mode. (15 May 2003)
This resulted in "pci_set_consistent_dma_mask()" interface
in order to change the dma_mask for pci_alloc_consistent() calls.
AlexW just submitted support for this a week or two ago to 2.6 kernel.

> Say if we have some structure corresponding to memory region of our 
> hardware device which should be of 16 bytes.
...
> Then above definition will not work for PPC64, we need to modify it like
> this:
> struct hw {
> dma_addr_t  phys;
> char            *virt;
> #ifdef  ARCH32 
> u64 dummy;
> #endif
> #ifdef ARCH_PPC64
> u32 dummy;
> #endif
> }

Use "u64 phys" and it will always be correct.

And "char * virt" has the same problem. "char *" will vary
in size depending arch (ILP32 vs LP64 data model) as well.
You did claim this code worked on i386, ia64 and PPC64, right?

hth,
grant

From c-d.hailfinger.kernel.2004@gmx.net Wed Feb  4 16:52:22 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 16:52:28 -0800 (PST)
Received: from mail.gmx.net (pop.gmx.de [213.165.64.20])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i150qKKO014561
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 16:52:21 -0800
Received: (qmail 20005 invoked by uid 65534); 5 Feb 2004 00:52:14 -0000
Received: from stud212019.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.212.19)
  by mail.gmx.net (mp008) with SMTP; 05 Feb 2004 01:52:14 +0100
X-Authenticated: #21910825
Message-ID: <402193B9.3000000@gmx.net>
Date: Thu, 05 Feb 2004 01:52:09 +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: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
CC: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Netdev <netdev@oss.sgi.com>, Jeff Garzik <jgarzik@pobox.com>,
        Manfred Spraul <manfred@colorfullife.com>
Subject: [PATCH] [2.4] forcedeth network driver
X-Enigmail-Version: 0.76.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/mixed;
 boundary="------------080200080605050005000104"
X-archive-position: 3001
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

This is a multi-part message in MIME format.
--------------080200080605050005000104
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Marcelo,

attached is the current version (0.23) of forcedeth, a network driver for
nForce{,2,3} chipsets which are fairly common today.
So far, the only support for nForce chipsets has been a binary-only driver
from NVidia.

The previous patch I sent generated some criticism from Jeff Garzik et al.
which has been addressed in the current version.
The current version has been posted for review twice and nobody has
complained about it for more than a week.

This driver has received testing by over 200 people on nForce1, nForce2
and nForce3 chipsets and has already been integrated into 2.6. Before
that, it has been in -mm for a few weeks. We currently don't have any
unresolved bug reports.

Credits for the driver go to:
Andrew de Quincey: Writing a spec for the chipset
Carl-Daniel Hailfinger: Co-author of the spec, driver fixes
Manfred Spraul: Writing the driver

The patch is against your current bk tree.
Please apply.

Carl-Daniel

--------------080200080605050005000104
Content-Type: text/plain;
 name="forcedeth_2_4_patch_v23.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="forcedeth_2_4_patch_v23.txt"

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1321  -> 1.1323 
#	drivers/net/Makefile	1.40.1.1 -> 1.42   
#	drivers/net/Config.in	1.72.1.1 -> 1.75   
#	Documentation/Configure.help	1.206.1.21 -> 1.210  
#	               (new)	        -> 1.11    drivers/net/forcedeth.c
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 04/02/04	compiler@4100xcdt.local	1.1322
# Merge 4100xcdt.local:/sources/linux-2.4
# into 4100xcdt.local:/sources/linux-2.4-forcedeth
# --------------------------------------------
# 04/02/05	compiler@4100xcdt.local	1.1323
# update forcedeth from 0.22 to 0.23: cleanups, remove all compat macros
# --------------------------------------------
#
diff -Nru a/Documentation/Configure.help b/Documentation/Configure.help
--- a/Documentation/Configure.help	Thu Feb  5 01:11:12 2004
+++ b/Documentation/Configure.help	Thu Feb  5 01:11:13 2004
@@ -12358,6 +12358,16 @@
   <file:Documentation/networking/net-modules.txt>.  The module will be
   called b44.
 
+nForce Ethernet support (EXPERIMENTAL)
+CONFIG_FORCEDETH
+  If you have a network (Ethernet) controller of this type, say Y and
+  read the Ethernet-HOWTO, available from
+  <http://www.tldp.org/docs.html#howto>.
+
+  To compile this driver as a module, choose M here and read
+  <file:Documentation/networking/net-modules.txt>.  The module will be
+  called forcedeth.o.
+
 CS89x0 support (Daynaport CS and LC cards)
 CONFIG_CS89x0
   Support for CS89x0 chipset based Ethernet cards. If you have a
diff -Nru a/drivers/net/Config.in b/drivers/net/Config.in
--- a/drivers/net/Config.in	Thu Feb  5 01:11:12 2004
+++ b/drivers/net/Config.in	Thu Feb  5 01:11:12 2004
@@ -198,6 +198,7 @@
       dep_tristate '    Myson MTD-8xx PCI Ethernet support' CONFIG_FEALNX $CONFIG_PCI
       dep_tristate '    National Semiconductor DP8381x series PCI Ethernet support' CONFIG_NATSEMI $CONFIG_PCI
       dep_tristate '    PCI NE2000 and clones support (see help)' CONFIG_NE2K_PCI $CONFIG_PCI
+      dep_tristate '    nForce Ethernet support (EXPERIMENTAL)' CONFIG_FORCEDETH $CONFIG_PCI $CONFIG_EXPERIMENTAL
       dep_tristate '    Novell/Eagle/Microdyne NE3210 EISA support (EXPERIMENTAL)' CONFIG_NE3210 $CONFIG_EISA $CONFIG_EXPERIMENTAL
       dep_tristate '    Racal-Interlan EISA ES3210 support (EXPERIMENTAL)' CONFIG_ES3210 $CONFIG_EISA $CONFIG_EXPERIMENTAL
       dep_tristate '    RealTek RTL-8139 C+ PCI Fast Ethernet Adapter support (EXPERIMENTAL)' CONFIG_8139CP $CONFIG_PCI $CONFIG_EXPERIMENTAL
diff -Nru a/drivers/net/Makefile b/drivers/net/Makefile
--- a/drivers/net/Makefile	Thu Feb  5 01:11:12 2004
+++ b/drivers/net/Makefile	Thu Feb  5 01:11:12 2004
@@ -154,6 +154,7 @@
 obj-$(CONFIG_NE3210) += ne3210.o 8390.o
 obj-$(CONFIG_NET_SB1250_MAC) += sb1250-mac.o
 obj-$(CONFIG_B44) += b44.o
+obj-$(CONFIG_FORCEDETH) += forcedeth.o
 
 obj-$(CONFIG_PPP) += ppp_generic.o slhc.o
 obj-$(CONFIG_PPP_ASYNC) += ppp_async.o
diff -Nru a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ b/drivers/net/forcedeth.c	Thu Feb  5 01:11:13 2004
@@ -0,0 +1,1576 @@
+/*
+ * forcedeth: Ethernet driver for NVIDIA nForce media access controllers.
+ *
+ * Note: This driver is a cleanroom reimplementation based on reverse
+ *      engineered documentation written by Carl-Daniel Hailfinger
+ *      and Andrew de Quincey. It's neither supported nor endorsed
+ *      by NVIDIA Corp. Use at your own risk.
+ *
+ * NVIDIA, nForce and other NVIDIA marks are trademarks or registered
+ * trademarks of NVIDIA Corporation in the United States and other
+ * countries.
+ *
+ * Copyright (C) 2003 Manfred Spraul
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * Changelog:
+ * 	0.01: 05 Oct 2003: First release that compiles without warnings.
+ * 	0.02: 05 Oct 2003: Fix bug for drain_tx: do not try to free NULL skbs.
+ * 			   Check all PCI BARs for the register window.
+ * 			   udelay added to mii_rw.
+ * 	0.03: 06 Oct 2003: Initialize dev->irq.
+ * 	0.04: 07 Oct 2003: Initialize np->lock, reduce handled irqs, add printks.
+ * 	0.05: 09 Oct 2003: printk removed again, irq status print tx_timeout.
+ * 	0.06: 10 Oct 2003: MAC Address read updated, pff flag generation updated,
+ * 			   irq mask updated
+ * 	0.07: 14 Oct 2003: Further irq mask updates.
+ * 	0.08: 20 Oct 2003: rx_desc.Length initialization added, alloc_rx refill
+ * 			   added into irq handler, NULL check for drain_ring.
+ * 	0.09: 20 Oct 2003: Basic link speed irq implementation. Only handle the
+ * 			   requested interrupt sources.
+ * 	0.10: 20 Oct 2003: First cleanup for release.
+ * 	0.11: 21 Oct 2003: hexdump for tx added, rx buffer sizes increased.
+ * 			   MAC Address init fix, set_multicast cleanup.
+ * 	0.12: 23 Oct 2003: Cleanups for release.
+ * 	0.13: 25 Oct 2003: Limit for concurrent tx packets increased to 10.
+ * 			   Set link speed correctly. start rx before starting
+ * 			   tx (start_rx sets the link speed).
+ * 	0.14: 25 Oct 2003: Nic dependant irq mask.
+ * 	0.15: 08 Nov 2003: fix smp deadlock with set_multicast_list during
+ * 			   open.
+ * 	0.16: 15 Nov 2003: include file cleanup for ppc64, rx buffer size
+ * 			   increased to 1628 bytes.
+ * 	0.17: 16 Nov 2003: undo rx buffer size increase. Substract 1 from
+ * 			   the tx length.
+ * 	0.18: 17 Nov 2003: fix oops due to late initialization of dev_stats
+ * 	0.19: 29 Nov 2003: Handle RxNoBuf, detect & handle invalid mac
+ * 			   addresses, really stop rx if already running
+ * 			   in start_rx, clean up a bit.
+ * 				(C) Carl-Daniel Hailfinger
+ * 	0.20: 07 Dec 2003: alloc fixes
+ * 	0.21: 12 Jan 2004: additional alloc fix, nic polling fix.
+ *	0.22: 19 Jan 2004: reprogram timer to a sane rate, avoid lockup
+ * 			   on close.
+ * 				(C) Carl-Daniel Hailfinger, Manfred Spraul
+ *	0.23: 26 Jan 2004: various small cleanups
+ *
+ * Known bugs:
+ * We suspect that on some hardware no TX done interrupts are generated.
+ * This means recovery from netif_stop_queue only happens if the hw timer
+ * interrupt fires (100 times/second, configurable with NVREG_POLL_DEFAULT)
+ * and the timer is active in the IRQMask, or if a rx packet arrives by chance.
+ * If your hardware reliably generates tx done interrupts, then you can remove
+ * DEV_NEED_TIMERIRQ from the driver_data flags.
+ * DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few
+ * superfluous timer interrupts from the nic.
+ */
+#define FORCEDETH_VERSION		"0.23"
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/pci.h>
+#include <linux/interrupt.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/delay.h>
+#include <linux/spinlock.h>
+#include <linux/ethtool.h>
+#include <linux/timer.h>
+#include <linux/skbuff.h>
+#include <linux/mii.h>
+#include <linux/random.h>
+#include <linux/init.h>
+
+#include <asm/irq.h>
+#include <asm/io.h>
+#include <asm/uaccess.h>
+#include <asm/system.h>
+
+#if 0
+#define dprintk			printk
+#else
+#define dprintk(x...)		do { } while (0)
+#endif
+
+
+/*
+ * Hardware access:
+ */
+
+#define DEV_NEED_LASTPACKET1	0x0001
+#define DEV_IRQMASK_1		0x0002
+#define DEV_IRQMASK_2		0x0004
+#define DEV_NEED_TIMERIRQ	0x0008
+
+enum {
+	NvRegIrqStatus = 0x000,
+#define NVREG_IRQSTAT_MIIEVENT	0x040
+#define NVREG_IRQSTAT_MASK		0x1ff
+	NvRegIrqMask = 0x004,
+#define NVREG_IRQ_RX			0x0002
+#define NVREG_IRQ_RX_NOBUF		0x0004
+#define NVREG_IRQ_TX_ERR		0x0008
+#define NVREG_IRQ_TX2			0x0010
+#define NVREG_IRQ_TIMER			0x0020
+#define NVREG_IRQ_LINK			0x0040
+#define NVREG_IRQ_TX1			0x0100
+#define NVREG_IRQMASK_WANTED_1		0x005f
+#define NVREG_IRQMASK_WANTED_2		0x0147
+#define NVREG_IRQ_UNKNOWN		(~(NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR|NVREG_IRQ_TX2|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX1))
+
+	NvRegUnknownSetupReg6 = 0x008,
+#define NVREG_UNKSETUP6_VAL		3
+
+/*
+ * NVREG_POLL_DEFAULT is the interval length of the timer source on the nic
+ * NVREG_POLL_DEFAULT=97 would result in an interval length of 1 ms
+ */
+	NvRegPollingInterval = 0x00c,
+#define NVREG_POLL_DEFAULT	970
+	NvRegMisc1 = 0x080,
+#define NVREG_MISC1_HD		0x02
+#define NVREG_MISC1_FORCE	0x3b0f3c
+
+	NvRegTransmitterControl = 0x084,
+#define NVREG_XMITCTL_START	0x01
+	NvRegTransmitterStatus = 0x088,
+#define NVREG_XMITSTAT_BUSY	0x01
+
+	NvRegPacketFilterFlags = 0x8c,
+#define NVREG_PFF_ALWAYS	0x7F0008
+#define NVREG_PFF_PROMISC	0x80
+#define NVREG_PFF_MYADDR	0x20
+
+	NvRegOffloadConfig = 0x90,
+#define NVREG_OFFLOAD_HOMEPHY	0x601
+#define NVREG_OFFLOAD_NORMAL	0x5ee
+	NvRegReceiverControl = 0x094,
+#define NVREG_RCVCTL_START	0x01
+	NvRegReceiverStatus = 0x98,
+#define NVREG_RCVSTAT_BUSY	0x01
+
+	NvRegRandomSeed = 0x9c,
+#define NVREG_RNDSEED_MASK	0x00ff
+#define NVREG_RNDSEED_FORCE	0x7f00
+
+	NvRegUnknownSetupReg1 = 0xA0,
+#define NVREG_UNKSETUP1_VAL	0x16070f
+	NvRegUnknownSetupReg2 = 0xA4,
+#define NVREG_UNKSETUP2_VAL	0x16
+	NvRegMacAddrA = 0xA8,
+	NvRegMacAddrB = 0xAC,
+	NvRegMulticastAddrA = 0xB0,
+#define NVREG_MCASTADDRA_FORCE	0x01
+	NvRegMulticastAddrB = 0xB4,
+	NvRegMulticastMaskA = 0xB8,
+	NvRegMulticastMaskB = 0xBC,
+
+	NvRegTxRingPhysAddr = 0x100,
+	NvRegRxRingPhysAddr = 0x104,
+	NvRegRingSizes = 0x108,
+#define NVREG_RINGSZ_TXSHIFT 0
+#define NVREG_RINGSZ_RXSHIFT 16
+	NvRegUnknownTransmitterReg = 0x10c,
+	NvRegLinkSpeed = 0x110,
+#define NVREG_LINKSPEED_FORCE 0x10000
+#define NVREG_LINKSPEED_10	10
+#define NVREG_LINKSPEED_100	100
+#define NVREG_LINKSPEED_1000	1000
+	NvRegUnknownSetupReg5 = 0x130,
+#define NVREG_UNKSETUP5_BIT31	(1<<31)
+	NvRegUnknownSetupReg3 = 0x134,
+#define NVREG_UNKSETUP3_VAL1	0x200010
+	NvRegTxRxControl = 0x144,
+#define NVREG_TXRXCTL_KICK	0x0001
+#define NVREG_TXRXCTL_BIT1	0x0002
+#define NVREG_TXRXCTL_BIT2	0x0004
+#define NVREG_TXRXCTL_IDLE	0x0008
+#define NVREG_TXRXCTL_RESET	0x0010
+	NvRegMIIStatus = 0x180,
+#define NVREG_MIISTAT_ERROR		0x0001
+#define NVREG_MIISTAT_LINKCHANGE	0x0008
+#define NVREG_MIISTAT_MASK		0x000f
+#define NVREG_MIISTAT_MASK2		0x000f
+	NvRegUnknownSetupReg4 = 0x184,
+#define NVREG_UNKSETUP4_VAL	8
+
+	NvRegAdapterControl = 0x188,
+#define NVREG_ADAPTCTL_START	0x02
+#define NVREG_ADAPTCTL_LINKUP	0x04
+#define NVREG_ADAPTCTL_PHYVALID	0x4000
+#define NVREG_ADAPTCTL_RUNNING	0x100000
+#define NVREG_ADAPTCTL_PHYSHIFT	24
+	NvRegMIISpeed = 0x18c,
+#define NVREG_MIISPEED_BIT8	(1<<8)
+#define NVREG_MIIDELAY	5
+	NvRegMIIControl = 0x190,
+#define NVREG_MIICTL_INUSE	0x10000
+#define NVREG_MIICTL_WRITE	0x08000
+#define NVREG_MIICTL_ADDRSHIFT	5
+	NvRegMIIData = 0x194,
+	NvRegWakeUpFlags = 0x200,
+#define NVREG_WAKEUPFLAGS_VAL		0x7770
+#define NVREG_WAKEUPFLAGS_BUSYSHIFT	24
+#define NVREG_WAKEUPFLAGS_ENABLESHIFT	16
+#define NVREG_WAKEUPFLAGS_D3SHIFT	12
+#define NVREG_WAKEUPFLAGS_D2SHIFT	8
+#define NVREG_WAKEUPFLAGS_D1SHIFT	4
+#define NVREG_WAKEUPFLAGS_D0SHIFT	0
+#define NVREG_WAKEUPFLAGS_ACCEPT_MAGPAT		0x01
+#define NVREG_WAKEUPFLAGS_ACCEPT_WAKEUPPAT	0x02
+#define NVREG_WAKEUPFLAGS_ACCEPT_LINKCHANGE	0x04
+
+	NvRegPatternCRC = 0x204,
+	NvRegPatternMask = 0x208,
+	NvRegPowerCap = 0x268,
+#define NVREG_POWERCAP_D3SUPP	(1<<30)
+#define NVREG_POWERCAP_D2SUPP	(1<<26)
+#define NVREG_POWERCAP_D1SUPP	(1<<25)
+	NvRegPowerState = 0x26c,
+#define NVREG_POWERSTATE_POWEREDUP	0x8000
+#define NVREG_POWERSTATE_VALID		0x0100
+#define NVREG_POWERSTATE_MASK		0x0003
+#define NVREG_POWERSTATE_D0		0x0000
+#define NVREG_POWERSTATE_D1		0x0001
+#define NVREG_POWERSTATE_D2		0x0002
+#define NVREG_POWERSTATE_D3		0x0003
+};
+
+struct ring_desc {
+	u32 PacketBuffer;
+	u16 Length;
+	u16 Flags;
+};
+
+#define NV_TX_LASTPACKET	(1<<0)
+#define NV_TX_RETRYERROR	(1<<3)
+#define NV_TX_LASTPACKET1	(1<<8)
+#define NV_TX_DEFERRED		(1<<10)
+#define NV_TX_CARRIERLOST	(1<<11)
+#define NV_TX_LATECOLLISION	(1<<12)
+#define NV_TX_UNDERFLOW		(1<<13)
+#define NV_TX_ERROR		(1<<14)
+#define NV_TX_VALID		(1<<15)
+
+#define NV_RX_DESCRIPTORVALID	(1<<0)
+#define NV_RX_MISSEDFRAME	(1<<1)
+#define NV_RX_SUBSTRACT1	(1<<3)
+#define NV_RX_ERROR1		(1<<7)
+#define NV_RX_ERROR2		(1<<8)
+#define NV_RX_ERROR3		(1<<9)
+#define NV_RX_ERROR4		(1<<10)
+#define NV_RX_CRCERR		(1<<11)
+#define NV_RX_OVERFLOW		(1<<12)
+#define NV_RX_FRAMINGERR	(1<<13)
+#define NV_RX_ERROR		(1<<14)
+#define NV_RX_AVAIL		(1<<15)
+
+/* Miscelaneous hardware related defines: */
+#define NV_PCI_REGSZ		0x270
+
+/* various timeout delays: all in usec */
+#define NV_TXRX_RESET_DELAY	4
+#define NV_TXSTOP_DELAY1	10
+#define NV_TXSTOP_DELAY1MAX	500000
+#define NV_TXSTOP_DELAY2	100
+#define NV_RXSTOP_DELAY1	10
+#define NV_RXSTOP_DELAY1MAX	500000
+#define NV_RXSTOP_DELAY2	100
+#define NV_SETUP5_DELAY		5
+#define NV_SETUP5_DELAYMAX	50000
+#define NV_POWERUP_DELAY	5
+#define NV_POWERUP_DELAYMAX	5000
+#define NV_MIIBUSY_DELAY	50
+#define NV_MIIPHY_DELAY	10
+#define NV_MIIPHY_DELAYMAX	10000
+
+#define NV_WAKEUPPATTERNS	5
+#define NV_WAKEUPMASKENTRIES	4
+
+/* General driver defaults */
+#define NV_WATCHDOG_TIMEO	(5*HZ)
+#define DEFAULT_MTU		1500	/* also maximum supported, at least for now */
+
+#define RX_RING		128
+#define TX_RING		16
+/* limited to 1 packet until we understand NV_TX_LASTPACKET */
+#define TX_LIMIT_STOP	10
+#define TX_LIMIT_START	5
+
+/* rx/tx mac addr + type + vlan + align + slack*/
+#define RX_NIC_BUFSIZE		(DEFAULT_MTU + 64)
+/* even more slack */
+#define RX_ALLOC_BUFSIZE	(DEFAULT_MTU + 128)
+
+#define OOM_REFILL	(1+HZ/20)
+#define POLL_WAIT	(1+HZ/100)
+
+/*
+ * SMP locking:
+ * All hardware access under dev->priv->lock, except the performance
+ * critical parts:
+ * - rx is (pseudo-) lockless: it relies on the single-threading provided
+ * 	by the arch code for interrupts.
+ * - tx setup is lockless: it relies on dev->xmit_lock. Actual submission
+ *	needs dev->priv->lock :-(
+ * - set_multicast_list: preparation lockless, relies on dev->xmit_lock.
+ */
+
+/* in dev: base, irq */
+struct fe_priv {
+	spinlock_t lock;
+
+	/* General data:
+	 * Locking: spin_lock(&np->lock); */
+	struct net_device_stats stats;
+	int in_shutdown;
+	u32 linkspeed;
+	int duplex;
+	int phyaddr;
+
+	/* General data: RO fields */
+	dma_addr_t ring_addr;
+	struct pci_dev *pci_dev;
+	u32 orig_mac[2];
+	u32 irqmask;
+
+	/* rx specific fields.
+	 * Locking: Within irq hander or disable_irq+spin_lock(&np->lock);
+	 */
+	struct ring_desc *rx_ring;
+	unsigned int cur_rx, refill_rx;
+	struct sk_buff *rx_skbuff[RX_RING];
+	dma_addr_t rx_dma[RX_RING];
+	unsigned int rx_buf_sz;
+	struct timer_list oom_kick;
+	struct timer_list nic_poll;
+
+	/*
+	 * tx specific fields.
+	 */
+	struct ring_desc *tx_ring;
+	unsigned int next_tx, nic_tx;
+	struct sk_buff *tx_skbuff[TX_RING];
+	dma_addr_t tx_dma[TX_RING];
+	u16 tx_flags;
+};
+
+/*
+ * Maximum number of loops until we assume that a bit in the irq mask
+ * is stuck. Overridable with module param.
+ */
+static int max_interrupt_work = 5;
+
+static inline struct fe_priv *get_nvpriv(struct net_device *dev)
+{
+	return (struct fe_priv *) dev->priv;
+}
+
+static inline u8 *get_hwbase(struct net_device *dev)
+{
+	return (u8 *) dev->base_addr;
+}
+
+static inline void pci_push(u8 * base)
+{
+	/* force out pending posted writes */
+	readl(base);
+}
+
+static int reg_delay(struct net_device *dev, int offset, u32 mask, u32 target,
+				int delay, int delaymax, const char *msg)
+{
+	u8 *base = get_hwbase(dev);
+
+	pci_push(base);
+	do {
+		udelay(delay);
+		delaymax -= delay;
+		if (delaymax < 0) {
+			if (msg)
+				printk(msg);
+			return 1;
+		}
+	} while ((readl(base + offset) & mask) != target);
+	return 0;
+}
+
+#define MII_READ	(-1)
+/* mii_rw: read/write a register on the PHY.
+ *
+ * Caller must guarantee serialization
+ */
+static int mii_rw(struct net_device *dev, int addr, int miireg, int value)
+{
+	u8 *base = get_hwbase(dev);
+	int was_running;
+	u32 reg;
+	int retval;
+
+	writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus);
+	was_running = 0;
+	reg = readl(base + NvRegAdapterControl);
+	if (reg & NVREG_ADAPTCTL_RUNNING) {
+		was_running = 1;
+		writel(reg & ~NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl);
+	}
+	reg = readl(base + NvRegMIIControl);
+	if (reg & NVREG_MIICTL_INUSE) {
+		writel(NVREG_MIICTL_INUSE, base + NvRegMIIControl);
+		udelay(NV_MIIBUSY_DELAY);
+	}
+
+	reg = NVREG_MIICTL_INUSE | (addr << NVREG_MIICTL_ADDRSHIFT) | miireg;
+	if (value != MII_READ) {
+		writel(value, base + NvRegMIIData);
+		reg |= NVREG_MIICTL_WRITE;
+	}
+	writel(reg, base + NvRegMIIControl);
+
+	if (reg_delay(dev, NvRegMIIControl, NVREG_MIICTL_INUSE, 0,
+			NV_MIIPHY_DELAY, NV_MIIPHY_DELAYMAX, NULL)) {
+		dprintk(KERN_DEBUG "%s: mii_rw of reg %d at PHY %d timed out.\n",
+				dev->name, miireg, addr);
+		retval = -1;
+	} else if (value != MII_READ) {
+		/* it was a write operation - fewer failures are detectable */
+		dprintk(KERN_DEBUG "%s: mii_rw wrote 0x%x to reg %d at PHY %d\n",
+				dev->name, value, miireg, addr);
+		retval = 0;
+	} else if (readl(base + NvRegMIIStatus) & NVREG_MIISTAT_ERROR) {
+		dprintk(KERN_DEBUG "%s: mii_rw of reg %d at PHY %d failed.\n",
+				dev->name, miireg, addr);
+		retval = -1;
+	} else {
+		/* FIXME: why is that required? */
+		udelay(50);
+		retval = readl(base + NvRegMIIData);
+		dprintk(KERN_DEBUG "%s: mii_rw read from reg %d at PHY %d: 0x%x.\n",
+				dev->name, miireg, addr, retval);
+	}
+	if (was_running) {
+		reg = readl(base + NvRegAdapterControl);
+		writel(reg | NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl);
+	}
+	return retval;
+}
+
+static void start_rx(struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+	u8 *base = get_hwbase(dev);
+
+	dprintk(KERN_DEBUG "%s: start_rx\n", dev->name);
+	/* Already running? Stop it. */
+	if (readl(base + NvRegReceiverControl) & NVREG_RCVCTL_START) {
+		writel(0, base + NvRegReceiverControl);
+		pci_push(base);
+	}
+	writel(np->linkspeed, base + NvRegLinkSpeed);
+	pci_push(base);
+	writel(NVREG_RCVCTL_START, base + NvRegReceiverControl);
+	pci_push(base);
+}
+
+static void stop_rx(struct net_device *dev)
+{
+	u8 *base = get_hwbase(dev);
+
+	dprintk(KERN_DEBUG "%s: stop_rx\n", dev->name);
+	writel(0, base + NvRegReceiverControl);
+	reg_delay(dev, NvRegReceiverStatus, NVREG_RCVSTAT_BUSY, 0,
+		       NV_RXSTOP_DELAY1, NV_RXSTOP_DELAY1MAX,
+		       KERN_INFO "stop_rx: ReceiverStatus remained busy");
+
+	udelay(NV_RXSTOP_DELAY2);
+	writel(0, base + NvRegLinkSpeed);
+}
+
+static void start_tx(struct net_device *dev)
+{
+	u8 *base = get_hwbase(dev);
+
+	dprintk(KERN_DEBUG "%s: start_tx\n", dev->name);
+	writel(NVREG_XMITCTL_START, base + NvRegTransmitterControl);
+	pci_push(base);
+}
+
+static void stop_tx(struct net_device *dev)
+{
+	u8 *base = get_hwbase(dev);
+
+	dprintk(KERN_DEBUG "%s: stop_tx\n", dev->name);
+	writel(0, base + NvRegTransmitterControl);
+	reg_delay(dev, NvRegTransmitterStatus, NVREG_XMITSTAT_BUSY, 0,
+		       NV_TXSTOP_DELAY1, NV_TXSTOP_DELAY1MAX,
+		       KERN_INFO "stop_tx: TransmitterStatus remained busy");
+
+	udelay(NV_TXSTOP_DELAY2);
+	writel(0, base + NvRegUnknownTransmitterReg);
+}
+
+static void txrx_reset(struct net_device *dev)
+{
+	u8 *base = get_hwbase(dev);
+
+	dprintk(KERN_DEBUG "%s: txrx_reset\n", dev->name);
+	writel(NVREG_TXRXCTL_BIT2 | NVREG_TXRXCTL_RESET, base + NvRegTxRxControl);
+	pci_push(base);
+	udelay(NV_TXRX_RESET_DELAY);
+	writel(NVREG_TXRXCTL_BIT2, base + NvRegTxRxControl);
+	pci_push(base);
+}
+
+/*
+ * nv_get_stats: dev->get_stats function
+ * Get latest stats value from the nic.
+ * Called with read_lock(&dev_base_lock) held for read -
+ * only synchronized against unregister_netdevice.
+ */
+static struct net_device_stats *nv_get_stats(struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+
+	/* It seems that the nic always generates interrupts and doesn't
+	 * accumulate errors internally. Thus the current values in np->stats
+	 * are already up to date.
+	 */
+	return &np->stats;
+}
+
+static int nv_ethtool_ioctl (struct net_device *dev, void *useraddr)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+	u32 ethcmd;
+
+	if (copy_from_user(&ethcmd, useraddr, sizeof (ethcmd)))
+		return -EFAULT;
+
+	switch (ethcmd) {
+	case ETHTOOL_GDRVINFO:
+	{
+		struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO };
+		strcpy(info.driver, "forcedeth");
+		strcpy(info.version, FORCEDETH_VERSION);
+		strcpy(info.bus_info, pci_name(np->pci_dev));
+		if (copy_to_user(useraddr, &info, sizeof (info)))
+			return -EFAULT;
+		return 0;
+	}
+	case ETHTOOL_GLINK:
+	{
+		struct ethtool_value edata = { ETHTOOL_GLINK };
+
+		edata.data = !!netif_carrier_ok(dev);
+
+		if (copy_to_user(useraddr, &edata, sizeof(edata)))
+			return -EFAULT;
+		return 0;
+	}
+
+	default:
+		break;
+	}
+
+	return -EOPNOTSUPP;
+}
+/*
+ * nv_ioctl: dev->do_ioctl function
+ * Called with rtnl_lock held.
+ */
+static int nv_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
+{
+	switch(cmd) {
+	case SIOCETHTOOL:
+		return nv_ethtool_ioctl(dev, (void *) rq->ifr_data);
+
+	default:
+		return -EOPNOTSUPP;
+	}
+}
+
+/*
+ * alloc_rx: fill rx ring entries.
+ * Return 1 if the allocations for the skbs failed and the
+ * rx engine is without Available descriptors
+ */
+static int alloc_rx(struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+	unsigned int refill_rx = np->refill_rx;
+
+	while (np->cur_rx != refill_rx) {
+		int nr = refill_rx % RX_RING;
+		struct sk_buff *skb;
+
+		if (np->rx_skbuff[nr] == NULL) {
+
+			skb = dev_alloc_skb(RX_ALLOC_BUFSIZE);
+			if (!skb)
+				break;
+
+			skb->dev = dev;
+			np->rx_skbuff[nr] = skb;
+		} else {
+			skb = np->rx_skbuff[nr];
+		}
+		np->rx_dma[nr] = pci_map_single(np->pci_dev, skb->data, skb->len,
+						PCI_DMA_FROMDEVICE);
+		np->rx_ring[nr].PacketBuffer = cpu_to_le32(np->rx_dma[nr]);
+		np->rx_ring[nr].Length = cpu_to_le16(RX_NIC_BUFSIZE);
+		wmb();
+		np->rx_ring[nr].Flags = cpu_to_le16(NV_RX_AVAIL);
+		dprintk(KERN_DEBUG "%s: alloc_rx: Packet  %d marked as Available\n",
+					dev->name, refill_rx);
+		refill_rx++;
+	}
+	np->refill_rx = refill_rx;
+	if (np->cur_rx - refill_rx == RX_RING)
+		return 1;
+	return 0;
+}
+
+static void do_rx_refill(unsigned long data)
+{
+	struct net_device *dev = (struct net_device *) data;
+	struct fe_priv *np = get_nvpriv(dev);
+
+	disable_irq(dev->irq);
+	if (alloc_rx(dev)) {
+		spin_lock(&np->lock);
+		if (!np->in_shutdown)
+			mod_timer(&np->oom_kick, jiffies + OOM_REFILL);
+		spin_unlock(&np->lock);
+	}
+	enable_irq(dev->irq);
+}
+
+static int init_ring(struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+	int i;
+
+	np->next_tx = np->nic_tx = 0;
+	for (i = 0; i < TX_RING; i++) {
+		np->tx_ring[i].Flags = 0;
+	}
+
+	np->cur_rx = RX_RING;
+	np->refill_rx = 0;
+	for (i = 0; i < RX_RING; i++) {
+		np->rx_ring[i].Flags = 0;
+	}
+	return alloc_rx(dev);
+}
+
+static void drain_tx(struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+	int i;
+	for (i = 0; i < TX_RING; i++) {
+		np->tx_ring[i].Flags = 0;
+		if (np->tx_skbuff[i]) {
+			pci_unmap_single(np->pci_dev, np->tx_dma[i],
+						np->tx_skbuff[i]->len,
+						PCI_DMA_TODEVICE);
+			dev_kfree_skb(np->tx_skbuff[i]);
+			np->tx_skbuff[i] = NULL;
+			np->stats.tx_dropped++;
+		}
+	}
+}
+
+static void drain_rx(struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+	int i;
+	for (i = 0; i < RX_RING; i++) {
+		np->rx_ring[i].Flags = 0;
+		wmb();
+		if (np->rx_skbuff[i]) {
+			pci_unmap_single(np->pci_dev, np->rx_dma[i],
+						np->rx_skbuff[i]->len,
+						PCI_DMA_FROMDEVICE);
+			dev_kfree_skb(np->rx_skbuff[i]);
+			np->rx_skbuff[i] = NULL;
+		}
+	}
+}
+
+static void drain_ring(struct net_device *dev)
+{
+	drain_tx(dev);
+	drain_rx(dev);
+}
+
+/*
+ * nv_start_xmit: dev->hard_start_xmit function
+ * Called with dev->xmit_lock held.
+ */
+static int nv_start_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+	int nr = np->next_tx % TX_RING;
+
+	np->tx_skbuff[nr] = skb;
+	np->tx_dma[nr] = pci_map_single(np->pci_dev, skb->data,skb->len,
+					PCI_DMA_TODEVICE);
+
+	np->tx_ring[nr].PacketBuffer = cpu_to_le32(np->tx_dma[nr]);
+	np->tx_ring[nr].Length = cpu_to_le16(skb->len-1);
+
+	spin_lock_irq(&np->lock);
+	wmb();
+	np->tx_ring[nr].Flags = np->tx_flags;
+	dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission.\n",
+				dev->name, np->next_tx);
+	{
+		int j;
+		for (j=0; j<64; j++) {
+			if ((j%16) == 0)
+				dprintk("\n%03x:", j);
+			dprintk(" %02x", ((unsigned char*)skb->data)[j]);
+		}
+		dprintk("\n");
+	}
+
+	np->next_tx++;
+
+	dev->trans_start = jiffies;
+	if (np->next_tx - np->nic_tx >= TX_LIMIT_STOP)
+		netif_stop_queue(dev);
+	spin_unlock_irq(&np->lock);
+	writel(NVREG_TXRXCTL_KICK, get_hwbase(dev) + NvRegTxRxControl);
+	pci_push(get_hwbase(dev));
+	return 0;
+}
+
+/*
+ * tx_done: check for completed packets, release the skbs.
+ *
+ * Caller must own np->lock.
+ */
+static void tx_done(struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+
+	while (np->nic_tx < np->next_tx) {
+		struct ring_desc *prd;
+		int i = np->nic_tx % TX_RING;
+
+		prd = &np->tx_ring[i];
+
+		dprintk(KERN_DEBUG "%s: tx_done: looking at packet %d, Flags 0x%x.\n",
+					dev->name, np->nic_tx, prd->Flags);
+		if (prd->Flags & cpu_to_le16(NV_TX_VALID))
+			break;
+		if (prd->Flags & cpu_to_le16(NV_TX_RETRYERROR|NV_TX_CARRIERLOST|NV_TX_LATECOLLISION|
+						NV_TX_UNDERFLOW|NV_TX_ERROR)) {
+			if (prd->Flags & cpu_to_le16(NV_TX_UNDERFLOW))
+				np->stats.tx_fifo_errors++;
+			if (prd->Flags & cpu_to_le16(NV_TX_CARRIERLOST))
+				np->stats.tx_carrier_errors++;
+			np->stats.tx_errors++;
+		} else {
+			np->stats.tx_packets++;
+			np->stats.tx_bytes += np->tx_skbuff[i]->len;
+		}
+		pci_unmap_single(np->pci_dev, np->tx_dma[i],
+					np->tx_skbuff[i]->len,
+					PCI_DMA_TODEVICE);
+		dev_kfree_skb_irq(np->tx_skbuff[i]);
+		np->tx_skbuff[i] = NULL;
+		np->nic_tx++;
+	}
+	if (np->next_tx - np->nic_tx < TX_LIMIT_START)
+		netif_wake_queue(dev);
+}
+
+/*
+ * nv_tx_timeout: dev->tx_timeout function
+ * Called with dev->xmit_lock held.
+ */
+static void nv_tx_timeout(struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+	u8 *base = get_hwbase(dev);
+
+	dprintk(KERN_DEBUG "%s: Got tx_timeout. irq: %08x\n", dev->name,
+			readl(base + NvRegIrqStatus) & NVREG_IRQSTAT_MASK);
+
+	spin_lock_irq(&np->lock);
+
+	/* 1) stop tx engine */
+	stop_tx(dev);
+
+	/* 2) check that the packets were not sent already: */
+	tx_done(dev);
+
+	/* 3) if there are dead entries: clear everything */
+	if (np->next_tx != np->nic_tx) {
+		printk(KERN_DEBUG "%s: tx_timeout: dead entries!\n", dev->name);
+		drain_tx(dev);
+		np->next_tx = np->nic_tx = 0;
+		writel((u32) (np->ring_addr + RX_RING*sizeof(struct ring_desc)), base + NvRegTxRingPhysAddr);
+		netif_wake_queue(dev);
+	}
+
+	/* 4) restart tx engine */
+	start_tx(dev);
+	spin_unlock_irq(&np->lock);
+}
+
+static void rx_process(struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+
+	for (;;) {
+		struct ring_desc *prd;
+		struct sk_buff *skb;
+		int len;
+		int i;
+		if (np->cur_rx - np->refill_rx >= RX_RING)
+			break;	/* we scanned the whole ring - do not continue */
+
+		i = np->cur_rx % RX_RING;
+		prd = &np->rx_ring[i];
+		dprintk(KERN_DEBUG "%s: rx_process: looking at packet %d, Flags 0x%x.\n",
+					dev->name, np->cur_rx, prd->Flags);
+
+		if (prd->Flags & cpu_to_le16(NV_RX_AVAIL))
+			break;	/* still owned by hardware, */
+
+		/*
+		 * the packet is for us - immediately tear down the pci mapping.
+		 * TODO: check if a prefetch of the first cacheline improves
+		 * the performance.
+		 */
+		pci_unmap_single(np->pci_dev, np->rx_dma[i],
+				np->rx_skbuff[i]->len,
+				PCI_DMA_FROMDEVICE);
+
+		{
+			int j;
+			dprintk(KERN_DEBUG "Dumping packet (flags 0x%x).",prd->Flags);
+			for (j=0; j<64; j++) {
+				if ((j%16) == 0)
+					dprintk("\n%03x:", j);
+				dprintk(" %02x", ((unsigned char*)np->rx_skbuff[i]->data)[j]);
+			}
+			dprintk("\n");
+		}
+		/* look at what we actually got: */
+		if (!(prd->Flags & cpu_to_le16(NV_RX_DESCRIPTORVALID)))
+			goto next_pkt;
+
+
+		len = le16_to_cpu(prd->Length);
+
+		if (prd->Flags & cpu_to_le16(NV_RX_MISSEDFRAME)) {
+			np->stats.rx_missed_errors++;
+			np->stats.rx_errors++;
+			goto next_pkt;
+		}
+		if (prd->Flags & cpu_to_le16(NV_RX_ERROR1|NV_RX_ERROR2|NV_RX_ERROR3|NV_RX_ERROR4)) {
+			np->stats.rx_errors++;
+			goto next_pkt;
+		}
+		if (prd->Flags & cpu_to_le16(NV_RX_CRCERR)) {
+			np->stats.rx_crc_errors++;
+			np->stats.rx_errors++;
+			goto next_pkt;
+		}
+		if (prd->Flags & cpu_to_le16(NV_RX_OVERFLOW)) {
+			np->stats.rx_over_errors++;
+			np->stats.rx_errors++;
+			goto next_pkt;
+		}
+		if (prd->Flags & cpu_to_le16(NV_RX_ERROR)) {
+			/* framing errors are soft errors, the rest is fatal. */
+			if (prd->Flags & cpu_to_le16(NV_RX_FRAMINGERR)) {
+				if (prd->Flags & cpu_to_le16(NV_RX_SUBSTRACT1)) {
+					len--;
+				}
+			} else {
+				np->stats.rx_errors++;
+				goto next_pkt;
+			}
+		}
+		/* got a valid packet - forward it to the network core */
+		skb = np->rx_skbuff[i];
+		np->rx_skbuff[i] = NULL;
+
+		skb_put(skb, len);
+		skb->protocol = eth_type_trans(skb, dev);
+		dprintk(KERN_DEBUG "%s: rx_process: packet %d with %d bytes, proto %d accepted.\n",
+					dev->name, np->cur_rx, len, skb->protocol);
+		netif_rx(skb);
+		dev->last_rx = jiffies;
+		np->stats.rx_packets++;
+		np->stats.rx_bytes += len;
+next_pkt:
+		np->cur_rx++;
+	}
+}
+
+/*
+ * nv_change_mtu: dev->change_mtu function
+ * Called with dev_base_lock held for read.
+ */
+static int nv_change_mtu(struct net_device *dev, int new_mtu)
+{
+	if (new_mtu > DEFAULT_MTU)
+		return -EINVAL;
+	dev->mtu = new_mtu;
+	return 0;
+}
+
+/*
+ * nv_set_multicast: dev->set_multicast function
+ * Called with dev->xmit_lock held.
+ */
+static void nv_set_multicast(struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+	u8 *base = get_hwbase(dev);
+	u32 addr[2];
+	u32 mask[2];
+	u32 pff;
+
+	memset(addr, 0, sizeof(addr));
+	memset(mask, 0, sizeof(mask));
+
+	if (dev->flags & IFF_PROMISC) {
+		printk(KERN_NOTICE "%s: Promiscuous mode enabled.\n", dev->name);
+		pff = NVREG_PFF_PROMISC;
+	} else {
+		pff = NVREG_PFF_MYADDR;
+
+		if (dev->flags & IFF_ALLMULTI || dev->mc_list) {
+			u32 alwaysOff[2];
+			u32 alwaysOn[2];
+
+			alwaysOn[0] = alwaysOn[1] = alwaysOff[0] = alwaysOff[1] = 0xffffffff;
+			if (dev->flags & IFF_ALLMULTI) {
+				alwaysOn[0] = alwaysOn[1] = alwaysOff[0] = alwaysOff[1] = 0;
+			} else {
+				struct dev_mc_list *walk;
+
+				walk = dev->mc_list;
+				while (walk != NULL) {
+					u32 a, b;
+					a = le32_to_cpu(*(u32 *) walk->dmi_addr);
+					b = le16_to_cpu(*(u16 *) (&walk->dmi_addr[4]));
+					alwaysOn[0] &= a;
+					alwaysOff[0] &= ~a;
+					alwaysOn[1] &= b;
+					alwaysOff[1] &= ~b;
+					walk = walk->next;
+				}
+			}
+			addr[0] = alwaysOn[0];
+			addr[1] = alwaysOn[1];
+			mask[0] = alwaysOn[0] | alwaysOff[0];
+			mask[1] = alwaysOn[1] | alwaysOff[1];
+		}
+	}
+	addr[0] |= NVREG_MCASTADDRA_FORCE;
+	pff |= NVREG_PFF_ALWAYS;
+	spin_lock_irq(&np->lock);
+	stop_rx(dev);
+	writel(addr[0], base + NvRegMulticastAddrA);
+	writel(addr[1], base + NvRegMulticastAddrB);
+	writel(mask[0], base + NvRegMulticastMaskA);
+	writel(mask[1], base + NvRegMulticastMaskB);
+	writel(pff, base + NvRegPacketFilterFlags);
+	start_rx(dev);
+	spin_unlock_irq(&np->lock);
+}
+
+static int update_linkspeed(struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+	int adv, lpa, newls, newdup;
+
+	adv = mii_rw(dev, np->phyaddr, MII_ADVERTISE, MII_READ);
+	lpa = mii_rw(dev, np->phyaddr, MII_LPA, MII_READ);
+	dprintk(KERN_DEBUG "%s: update_linkspeed: PHY advertises 0x%04x, lpa 0x%04x.\n",
+				dev->name, adv, lpa);
+
+	/* FIXME: handle parallel detection properly, handle gigabit ethernet */
+	lpa = lpa & adv;
+	if (lpa  & LPA_100FULL) {
+		newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_100;
+		newdup = 1;
+	} else if (lpa & LPA_100HALF) {
+		newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_100;
+		newdup = 0;
+	} else if (lpa & LPA_10FULL) {
+		newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10;
+		newdup = 1;
+	} else if (lpa & LPA_10HALF) {
+		newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10;
+		newdup = 0;
+	} else {
+		dprintk(KERN_DEBUG "%s: bad ability %04x - falling back to 10HD.\n", dev->name, lpa);
+		newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10;
+		newdup = 0;
+	}
+	if (np->duplex != newdup || np->linkspeed != newls) {
+		np->duplex = newdup;
+		np->linkspeed = newls;
+		return 1;
+	}
+	return 0;
+}
+
+static void link_irq(struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+	u8 *base = get_hwbase(dev);
+	u32 miistat;
+	int miival;
+
+	miistat = readl(base + NvRegMIIStatus);
+	writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus);
+	printk(KERN_DEBUG "%s: link change notification, status 0x%x.\n", dev->name, miistat);
+
+	miival = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ);
+	if (miival & BMSR_ANEGCOMPLETE) {
+		update_linkspeed(dev);
+
+		if (netif_carrier_ok(dev)) {
+			stop_rx(dev);
+		} else {
+			netif_carrier_on(dev);
+			printk(KERN_INFO "%s: link up.\n", dev->name);
+		}
+		writel(NVREG_MISC1_FORCE | ( np->duplex ? 0 : NVREG_MISC1_HD),
+					base + NvRegMisc1);
+		start_rx(dev);
+	} else {
+		if (netif_carrier_ok(dev)) {
+			netif_carrier_off(dev);
+			printk(KERN_INFO "%s: link down.\n", dev->name);
+			stop_rx(dev);
+		}
+		writel(np->linkspeed, base + NvRegLinkSpeed);
+		pci_push(base);
+	}
+}
+
+static irqreturn_t nic_irq(int foo, void *data, struct pt_regs *regs)
+{
+	struct net_device *dev = (struct net_device *) data;
+	struct fe_priv *np = get_nvpriv(dev);
+	u8 *base = get_hwbase(dev);
+	u32 events;
+	int i;
+
+	dprintk(KERN_DEBUG "%s: nic_irq\n", dev->name);
+
+	for (i=0; ; i++) {
+		events = readl(base + NvRegIrqStatus) & NVREG_IRQSTAT_MASK;
+		writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus);
+		pci_push(base);
+		dprintk(KERN_DEBUG "%s: irq: %08x\n", dev->name, events);
+		if (!(events & np->irqmask))
+			break;
+
+		if (events & (NVREG_IRQ_TX1|NVREG_IRQ_TX2|NVREG_IRQ_TX_ERR)) {
+			spin_lock(&np->lock);
+			tx_done(dev);
+			spin_unlock(&np->lock);
+		}
+
+		if (events & (NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF)) {
+			rx_process(dev);
+			if (alloc_rx(dev)) {
+				spin_lock(&np->lock);
+				if (!np->in_shutdown)
+					mod_timer(&np->oom_kick, jiffies + OOM_REFILL);
+				spin_unlock(&np->lock);
+			}
+		}
+
+		if (events & NVREG_IRQ_LINK) {
+			spin_lock(&np->lock);
+			link_irq(dev);
+			spin_unlock(&np->lock);
+		}
+		if (events & (NVREG_IRQ_TX_ERR)) {
+			dprintk(KERN_DEBUG "%s: received irq with events 0x%x. Probably TX fail.\n",
+						dev->name, events);
+		}
+		if (events & (NVREG_IRQ_UNKNOWN)) {
+			printk(KERN_DEBUG "%s: received irq with unknown events 0x%x. Please report\n",
+						dev->name, events);
+ 		}
+		if (i > max_interrupt_work) {
+			spin_lock(&np->lock);
+			/* disable interrupts on the nic */
+			writel(0, base + NvRegIrqMask);
+			pci_push(base);
+
+			if (!np->in_shutdown)
+				mod_timer(&np->nic_poll, jiffies + POLL_WAIT);
+			printk(KERN_DEBUG "%s: too many iterations (%d) in nic_irq.\n", dev->name, i);
+			spin_unlock(&np->lock);
+			break;
+		}
+
+	}
+	dprintk(KERN_DEBUG "%s: nic_irq completed\n", dev->name);
+
+	return IRQ_RETVAL(i);
+}
+
+static void do_nic_poll(unsigned long data)
+{
+	struct net_device *dev = (struct net_device *) data;
+	struct fe_priv *np = get_nvpriv(dev);
+	u8 *base = get_hwbase(dev);
+
+	disable_irq(dev->irq);
+	/*
+	 * reenable interrupts on the nic, we have to do this before calling
+	 * nic_irq because that may decide to do otherwise
+	 */
+	writel(np->irqmask, base + NvRegIrqMask);
+	pci_push(base);
+	nic_irq((int) 0, (void *) data, (struct pt_regs *) NULL);
+	enable_irq(dev->irq);
+}
+
+static int nv_open(struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+	u8 *base = get_hwbase(dev);
+	int ret, oom, i;
+
+	dprintk(KERN_DEBUG "nv_open: begin\n");
+
+	/* 1) erase previous misconfiguration */
+	/* 4.1-1: stop adapter: ignored, 4.3 seems to be overkill */
+	writel(NVREG_MCASTADDRA_FORCE, base + NvRegMulticastAddrA);
+	writel(0, base + NvRegMulticastAddrB);
+	writel(0, base + NvRegMulticastMaskA);
+	writel(0, base + NvRegMulticastMaskB);
+	writel(0, base + NvRegPacketFilterFlags);
+	writel(0, base + NvRegAdapterControl);
+	writel(0, base + NvRegLinkSpeed);
+	writel(0, base + NvRegUnknownTransmitterReg);
+	txrx_reset(dev);
+	writel(0, base + NvRegUnknownSetupReg6);
+
+	/* 2) initialize descriptor rings */
+	np->in_shutdown = 0;
+	oom = init_ring(dev);
+
+	/* 3) set mac address */
+	{
+		u32 mac[2];
+
+		mac[0] = (dev->dev_addr[0] <<  0) + (dev->dev_addr[1] <<  8) +
+				(dev->dev_addr[2] << 16) + (dev->dev_addr[3] << 24);
+		mac[1] = (dev->dev_addr[4] << 0) + (dev->dev_addr[5] << 8);
+
+		writel(mac[0], base + NvRegMacAddrA);
+		writel(mac[1], base + NvRegMacAddrB);
+	}
+
+	/* 4) continue setup */
+	np->linkspeed = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10;
+	np->duplex = 0;
+	writel(NVREG_UNKSETUP3_VAL1, base + NvRegUnknownSetupReg3);
+	writel(0, base + NvRegTxRxControl);
+	pci_push(base);
+	writel(NVREG_TXRXCTL_BIT1, base + NvRegTxRxControl);
+	reg_delay(dev, NvRegUnknownSetupReg5, NVREG_UNKSETUP5_BIT31, NVREG_UNKSETUP5_BIT31,
+			NV_SETUP5_DELAY, NV_SETUP5_DELAYMAX,
+			KERN_INFO "open: SetupReg5, Bit 31 remained off\n");
+	writel(0, base + NvRegUnknownSetupReg4);
+
+	/* 5) Find a suitable PHY */
+	writel(NVREG_MIISPEED_BIT8|NVREG_MIIDELAY, base + NvRegMIISpeed);
+	for (i = 1; i < 32; i++) {
+		int id1, id2;
+
+		spin_lock_irq(&np->lock);
+		id1 = mii_rw(dev, i, MII_PHYSID1, MII_READ);
+		spin_unlock_irq(&np->lock);
+		if (id1 < 0 || id1 == 0xffff)
+			continue;
+		spin_lock_irq(&np->lock);
+		id2 = mii_rw(dev, i, MII_PHYSID2, MII_READ);
+		spin_unlock_irq(&np->lock);
+		if (id2 < 0 || id2 == 0xffff)
+			continue;
+		dprintk(KERN_DEBUG "%s: open: Found PHY %04x:%04x at address %d.\n",
+				dev->name, id1, id2, i);
+		np->phyaddr = i;
+
+		spin_lock_irq(&np->lock);
+		update_linkspeed(dev);
+		spin_unlock_irq(&np->lock);
+
+		break;
+	}
+	if (i == 32) {
+		printk(KERN_INFO "%s: open: failing due to lack of suitable PHY.\n",
+				dev->name);
+		ret = -EINVAL;
+		goto out_drain;
+	}
+
+	/* 6) continue setup */
+	writel(NVREG_MISC1_FORCE | ( np->duplex ? 0 : NVREG_MISC1_HD),
+				base + NvRegMisc1);
+	writel(readl(base + NvRegTransmitterStatus), base + NvRegTransmitterStatus);
+	writel(NVREG_PFF_ALWAYS, base + NvRegPacketFilterFlags);
+	writel(NVREG_OFFLOAD_NORMAL, base + NvRegOffloadConfig);
+
+	writel(readl(base + NvRegReceiverStatus), base + NvRegReceiverStatus);
+	get_random_bytes(&i, sizeof(i));
+	writel(NVREG_RNDSEED_FORCE | (i&NVREG_RNDSEED_MASK), base + NvRegRandomSeed);
+	writel(NVREG_UNKSETUP1_VAL, base + NvRegUnknownSetupReg1);
+	writel(NVREG_UNKSETUP2_VAL, base + NvRegUnknownSetupReg2);
+	writel(NVREG_POLL_DEFAULT, base + NvRegPollingInterval);
+	writel(NVREG_UNKSETUP6_VAL, base + NvRegUnknownSetupReg6);
+	writel((np->phyaddr << NVREG_ADAPTCTL_PHYSHIFT)|NVREG_ADAPTCTL_PHYVALID,
+			base + NvRegAdapterControl);
+	writel(NVREG_UNKSETUP4_VAL, base + NvRegUnknownSetupReg4);
+	writel(NVREG_WAKEUPFLAGS_VAL, base + NvRegWakeUpFlags);
+
+	/* 7) start packet processing */
+	writel((u32) np->ring_addr, base + NvRegRxRingPhysAddr);
+	writel((u32) (np->ring_addr + RX_RING*sizeof(struct ring_desc)), base + NvRegTxRingPhysAddr);
+	writel( ((RX_RING-1) << NVREG_RINGSZ_RXSHIFT) + ((TX_RING-1) << NVREG_RINGSZ_TXSHIFT),
+			base + NvRegRingSizes);
+
+	i = readl(base + NvRegPowerState);
+	if ( (i & NVREG_POWERSTATE_POWEREDUP) == 0)
+		writel(NVREG_POWERSTATE_POWEREDUP|i, base + NvRegPowerState);
+
+	pci_push(base);
+	udelay(10);
+	writel(readl(base + NvRegPowerState) | NVREG_POWERSTATE_VALID, base + NvRegPowerState);
+	writel(NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl);
+
+
+	writel(0, base + NvRegIrqMask);
+	pci_push(base);
+	writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus);
+	pci_push(base);
+	writel(NVREG_MIISTAT_MASK2, base + NvRegMIIStatus);
+	writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus);
+	pci_push(base);
+
+	ret = request_irq(dev->irq, &nic_irq, SA_SHIRQ, dev->name, dev);
+	if (ret)
+		goto out_drain;
+
+	writel(np->irqmask, base + NvRegIrqMask);
+
+	spin_lock_irq(&np->lock);
+	writel(NVREG_MCASTADDRA_FORCE, base + NvRegMulticastAddrA);
+	writel(0, base + NvRegMulticastAddrB);
+	writel(0, base + NvRegMulticastMaskA);
+	writel(0, base + NvRegMulticastMaskB);
+	writel(NVREG_PFF_ALWAYS|NVREG_PFF_MYADDR, base + NvRegPacketFilterFlags);
+	start_rx(dev);
+	start_tx(dev);
+	netif_start_queue(dev);
+	if (oom)
+		mod_timer(&np->oom_kick, jiffies + OOM_REFILL);
+	if (mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ) & BMSR_ANEGCOMPLETE) {
+		netif_carrier_on(dev);
+	} else {
+		printk("%s: no link during initialization.\n", dev->name);
+		netif_carrier_off(dev);
+	}
+
+	spin_unlock_irq(&np->lock);
+
+	return 0;
+out_drain:
+	drain_ring(dev);
+	return ret;
+}
+
+static int nv_close(struct net_device *dev)
+{
+	struct fe_priv *np = get_nvpriv(dev);
+	u8 *base;
+
+	spin_lock_irq(&np->lock);
+	np->in_shutdown = 1;
+	spin_unlock_irq(&np->lock);
+	synchronize_irq();
+
+	del_timer_sync(&np->oom_kick);
+	del_timer_sync(&np->nic_poll);
+
+	netif_stop_queue(dev);
+	spin_lock_irq(&np->lock);
+	stop_tx(dev);
+	stop_rx(dev);
+	base = get_hwbase(dev);
+
+	/* disable interrupts on the nic or we will lock up */
+	writel(0, base + NvRegIrqMask);
+	pci_push(base);
+	dprintk(KERN_INFO "%s: Irqmask is zero again\n", dev->name);
+
+	spin_unlock_irq(&np->lock);
+
+	free_irq(dev->irq, dev);
+
+	drain_ring(dev);
+
+	/* FIXME: power down nic */
+
+	return 0;
+}
+
+static int __devinit nv_probe(struct pci_dev *pci_dev, const struct pci_device_id *id)
+{
+	struct net_device *dev;
+	struct fe_priv *np;
+	unsigned long addr;
+	u8 *base;
+	int err, i;
+
+	dev = alloc_etherdev(sizeof(struct fe_priv));
+	err = -ENOMEM;
+	if (!dev)
+		goto out;
+
+	np = get_nvpriv(dev);
+	np->pci_dev = pci_dev;
+	spin_lock_init(&np->lock);
+	SET_MODULE_OWNER(dev);
+	SET_NETDEV_DEV(dev, &pci_dev->dev);
+
+	init_timer(&np->oom_kick);
+	np->oom_kick.data = (unsigned long) dev;
+	np->oom_kick.function = &do_rx_refill;	/* timer handler */
+	init_timer(&np->nic_poll);
+	np->nic_poll.data = (unsigned long) dev;
+	np->nic_poll.function = &do_nic_poll;	/* timer handler */
+
+	err = pci_enable_device(pci_dev);
+	if (err) {
+		printk(KERN_INFO "forcedeth: pci_enable_dev failed (%d) for device %s\n",
+				err, pci_name(pci_dev));
+		goto out_free;
+	}
+
+	pci_set_master(pci_dev);
+
+	err = pci_request_regions(pci_dev, dev->name);
+	if (err < 0)
+		goto out_disable;
+
+	err = -EINVAL;
+	addr = 0;
+	for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+		dprintk(KERN_DEBUG "%s: resource %d start %p len %ld flags 0x%08lx.\n",
+				pci_name(pci_dev), i, (void*)pci_resource_start(pci_dev, i),
+				pci_resource_len(pci_dev, i),
+				pci_resource_flags(pci_dev, i));
+		if (pci_resource_flags(pci_dev, i) & IORESOURCE_MEM &&
+				pci_resource_len(pci_dev, i) >= NV_PCI_REGSZ) {
+			addr = pci_resource_start(pci_dev, i);
+			break;
+		}
+	}
+	if (i == DEVICE_COUNT_RESOURCE) {
+		printk(KERN_INFO "forcedeth: Couldn't find register window for device %s.\n",
+					pci_name(pci_dev));
+		goto out_relreg;
+	}
+
+	err = -ENOMEM;
+	dev->base_addr = (unsigned long) ioremap(addr, NV_PCI_REGSZ);
+	if (!dev->base_addr)
+		goto out_relreg;
+	dev->irq = pci_dev->irq;
+	np->rx_ring = pci_alloc_consistent(pci_dev, sizeof(struct ring_desc) * (RX_RING + TX_RING),
+						&np->ring_addr);
+	if (!np->rx_ring)
+		goto out_unmap;
+	np->tx_ring = &np->rx_ring[RX_RING];
+
+	dev->open = nv_open;
+	dev->stop = nv_close;
+	dev->hard_start_xmit = nv_start_xmit;
+	dev->get_stats = nv_get_stats;
+	dev->change_mtu = nv_change_mtu;
+	dev->set_multicast_list = nv_set_multicast;
+	dev->do_ioctl = nv_ioctl;
+	dev->tx_timeout = nv_tx_timeout;
+	dev->watchdog_timeo = NV_WATCHDOG_TIMEO;
+
+	pci_set_drvdata(pci_dev, dev);
+
+	/* read the mac address */
+	base = get_hwbase(dev);
+	np->orig_mac[0] = readl(base + NvRegMacAddrA);
+	np->orig_mac[1] = readl(base + NvRegMacAddrB);
+
+	dev->dev_addr[0] = (np->orig_mac[1] >>  8) & 0xff;
+	dev->dev_addr[1] = (np->orig_mac[1] >>  0) & 0xff;
+	dev->dev_addr[2] = (np->orig_mac[0] >> 24) & 0xff;
+	dev->dev_addr[3] = (np->orig_mac[0] >> 16) & 0xff;
+	dev->dev_addr[4] = (np->orig_mac[0] >>  8) & 0xff;
+	dev->dev_addr[5] = (np->orig_mac[0] >>  0) & 0xff;
+
+	if (!is_valid_ether_addr(dev->dev_addr)) {
+		/*
+		 * Bad mac address. At least one bios sets the mac address
+		 * to 01:23:45:67:89:ab
+		 */
+		printk(KERN_ERR "%s: Invalid Mac address detected: %02x:%02x:%02x:%02x:%02x:%02x\n",
+			pci_name(pci_dev),
+			dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2],
+			dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]);
+		printk(KERN_ERR "Please complain to your hardware vendor. Switching to a random MAC.\n");
+		dev->dev_addr[0] = 0x00;
+		dev->dev_addr[1] = 0x00;
+		dev->dev_addr[2] = 0x6c;
+		get_random_bytes(&dev->dev_addr[3], 3);
+	}
+
+	dprintk(KERN_DEBUG "%s: MAC Address %02x:%02x:%02x:%02x:%02x:%02x\n", pci_name(pci_dev),
+			dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2],
+			dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]);
+
+	np->tx_flags = cpu_to_le16(NV_TX_LASTPACKET|NV_TX_LASTPACKET1|NV_TX_VALID);
+	if (id->driver_data & DEV_NEED_LASTPACKET1)
+		np->tx_flags |= cpu_to_le16(NV_TX_LASTPACKET1);
+	if (id->driver_data & DEV_IRQMASK_1)
+		np->irqmask = NVREG_IRQMASK_WANTED_1;
+	if (id->driver_data & DEV_IRQMASK_2)
+		np->irqmask = NVREG_IRQMASK_WANTED_2;
+	if (id->driver_data & DEV_NEED_TIMERIRQ)
+		np->irqmask |= NVREG_IRQ_TIMER;
+
+	err = register_netdev(dev);
+	if (err) {
+		printk(KERN_INFO "forcedeth: unable to register netdev: %d\n", err);
+		goto out_freering;
+	}
+	printk(KERN_INFO "%s: forcedeth.c: subsystem: %05x:%04x bound to %s\n",
+			dev->name, pci_dev->subsystem_vendor, pci_dev->subsystem_device,
+			pci_name(pci_dev));
+
+	return 0;
+
+out_freering:
+	pci_free_consistent(np->pci_dev, sizeof(struct ring_desc) * (RX_RING + TX_RING),
+				np->rx_ring, np->ring_addr);
+	pci_set_drvdata(pci_dev, NULL);
+out_unmap:
+	iounmap(get_hwbase(dev));
+out_relreg:
+	pci_release_regions(pci_dev);
+out_disable:
+	pci_disable_device(pci_dev);
+out_free:
+	free_netdev(dev);
+out:
+	return err;
+}
+
+static void __devexit nv_remove(struct pci_dev *pci_dev)
+{
+	struct net_device *dev = pci_get_drvdata(pci_dev);
+	struct fe_priv *np = get_nvpriv(dev);
+	u8 *base = get_hwbase(dev);
+
+	unregister_netdev(dev);
+
+	/* special op: write back the misordered MAC address - otherwise
+	 * the next nv_probe would see a wrong address.
+	 */
+	writel(np->orig_mac[0], base + NvRegMacAddrA);
+	writel(np->orig_mac[1], base + NvRegMacAddrB);
+
+	/* free all structures */
+	pci_free_consistent(np->pci_dev, sizeof(struct ring_desc) * (RX_RING + TX_RING), np->rx_ring, np->ring_addr);
+	iounmap(get_hwbase(dev));
+	pci_release_regions(pci_dev);
+	pci_disable_device(pci_dev);
+	free_netdev(dev);
+	pci_set_drvdata(pci_dev, NULL);
+}
+
+static struct pci_device_id pci_tbl[] = {
+	{	/* nForce Ethernet Controller */
+		.vendor = PCI_VENDOR_ID_NVIDIA,
+		.device = 0x1C3,
+		.subvendor = PCI_ANY_ID,
+		.subdevice = PCI_ANY_ID,
+		.driver_data = DEV_IRQMASK_1|DEV_NEED_TIMERIRQ,
+	},
+	{	/* nForce2 Ethernet Controller */
+		.vendor = PCI_VENDOR_ID_NVIDIA,
+		.device = 0x0066,
+		.subvendor = PCI_ANY_ID,
+		.subdevice = PCI_ANY_ID,
+		.driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ,
+	},
+	{	/* nForce3 Ethernet Controller */
+		.vendor = PCI_VENDOR_ID_NVIDIA,
+		.device = 0x00D6,
+		.subvendor = PCI_ANY_ID,
+		.subdevice = PCI_ANY_ID,
+		.driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ,
+	},
+	{0,},
+};
+
+static struct pci_driver driver = {
+	.name = "forcedeth",
+	.id_table = pci_tbl,
+	.probe = nv_probe,
+	.remove = __devexit_p(nv_remove),
+};
+
+
+static int __init init_nic(void)
+{
+	printk(KERN_INFO "forcedeth.c: Reverse Engineered nForce ethernet driver. Version %s.\n", FORCEDETH_VERSION);
+	return pci_module_init(&driver);
+}
+
+static void __exit exit_nic(void)
+{
+	pci_unregister_driver(&driver);
+}
+
+MODULE_PARM(max_interrupt_work, "i");
+MODULE_PARM_DESC(max_interrupt_work, "forcedeth maximum events handled per interrupt");
+ 
+MODULE_AUTHOR("Manfred Spraul <manfred@colorfullife.com>");
+MODULE_DESCRIPTION("Reverse Engineered nForce ethernet driver");
+MODULE_LICENSE("GPL");
+
+MODULE_DEVICE_TABLE(pci, pci_tbl);
+
+module_init(init_nic);
+module_exit(exit_nic);

--------------080200080605050005000104--


From leonid.grossman@s2io.com Wed Feb  4 17:21:43 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 17:21:47 -0800 (PST)
Received: from ns1.s2io.com (ns1.s2io.com [216.209.86.101])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i151LgKO017788
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 17:21:42 -0800
Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98])
	by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i151FOjF013425;
	Wed, 4 Feb 2004 20:15:24 -0500 (EST)
Received: from lgt40 ([10.16.16.115])
	by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i151FLKK026173;
	Wed, 4 Feb 2004 20:15:22 -0500 (EST)
From: "Leonid Grossman" <leonid.grossman@s2io.com>
To: "'Grant Grundler'" <iod00d@hp.com>
Cc: "'Andi Kleen'" <ak@suse.de>, <netdev@oss.sgi.com>,
        "'Ragu Vatsavayi'" <raghava.vatsavayi@s2io.com>
Subject: RE: FW: Submission for S2io 10GbE driver
Date: Wed, 4 Feb 2004 17:14:36 -0800
Message-ID: <002a01c3eb85$6c96dd70$7310100a@S2IOtech.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <20040205004952.GA27510@cup.hp.com>
X-Spam-Score: -101
X-Spam-Outlook-Score: ()
X-Spam-Features: IN_REP_TO,QUOTED_EMAIL_TEXT,USER_IN_WHITELIST
X-Scanned-By: MIMEDefang 2.34
X-archive-position: 3002
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: leonid.grossman@s2io.com
Precedence: bulk
X-list: netdev

> Use "u64 phys" and it will always be correct.
> 
> And "char * virt" has the same problem. "char *" will vary
> in size depending arch (ILP32 vs LP64 data model) as well.
> You did claim this code worked on i386, ia64 and PPC64, right?

Yes (Opteron platforms too).
Thanks for the input!
Leonid

> 
> hth,
> grant
> 


From ak@suse.de Wed Feb  4 17:35:10 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 17:35:14 -0800 (PST)
Received: from Cantor.suse.de (ns.suse.de [195.135.220.2])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i151Z9KO018831
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 17:35:09 -0800
Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by Cantor.suse.de (Postfix) with ESMTP
	id 6AB8513B452; Thu,  5 Feb 2004 02:32:11 +0100 (CET)
Date: Thu, 5 Feb 2004 02:32:09 +0100
From: Andi Kleen <ak@suse.de>
To: "Leonid Grossman" <leonid.grossman@s2io.com>
Cc: netdev@oss.sgi.com, raghava.vatsavayi@s2io.com, iod00d@hp.com,
        anton@samba.org
Subject: Re: FW: Submission for S2io 10GbE driver
Message-Id: <20040205023209.4abf2342.ak@suse.de>
In-Reply-To: <004201c3eb5f$ac4e9f00$740efea9@S2IOtech.com>
References: <20040123232209.2739e6aa.ak@suse.de>
	<004201c3eb5f$ac4e9f00$740efea9@S2IOtech.com>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 3003
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: ak@suse.de
Precedence: bulk
X-list: netdev

On Wed, 4 Feb 2004 12:44:21 -0800
"Leonid Grossman" <leonid.grossman@s2io.com> wrote:

> 
> 
> > All the ARCH_PPC64 ifdefs shouldn't be needed. Can you remove 
> > that? If there are problems in ppc64 code they should be 
> > fixed there, not worked around. Same with the ifdefs for 
> > kernel 2.6 features. An driver integrated into the kernel 
> > should not contain such ifdefs.
> 
> 
> Hi Andi,
> You are right some of the ifdefs are not needed and we are removing
> these; it is not clear if we can get rid of all of them for the
> following reasons:
> 
> 1) We did't find quad word memory operations(writeq and readq) on PCI
> bus for PPC64 architecture.

That's a bug in ppc64 then. Can you complain to them?

I would go ahead and just use them in the driver unconditionally and wait for 
the ppc64 to fix it. Or just add them there, it's probably simple.

> 2) We did't had a chance to test the driver on other big endian systems
> apart from PPC64. In PPC64 architecture though,
> I write/read a value to/from ioremaped address it swaps the value and
> behaves like a little endian m/c:  
> 
> For ex: if I  do writel(0x12345678, addr) then in it writes 
> addr: 78, (addr+1):56, (addr+2):34, (addr+3):12

Hmm, weird. Don't know, ask the ppc64 people.

> On a little endian m/c like IA32 also writel writes same values in a
> similar manner as shown above. 
> So the question is -
> Do all big endian machines with linux OS swap the values and write in
> little endian format?? 

I hope not.

> 3)In PPC64 architecture dma_addr_t is u32, unlike remaining 64 bit
> architectures where it is defined as u64. Because
> of this we have to deal separately for PP64. 
> So any suggestions will be useful, .i.e. generally how PPC64 developers
> deal with this?

You could just use u64 in your structure definitions for now.

-Andi

From krkumar@us.ibm.com Wed Feb  4 17:44:56 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 17:44:59 -0800 (PST)
Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i151iuKO019368
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 17:44:56 -0800
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i151inpZ554246;
	Wed, 4 Feb 2004 20:44:49 -0500
Received: from DYN318430BLD.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i151imOB086738;
	Wed, 4 Feb 2004 18:44:48 -0700
Date: Wed, 4 Feb 2004 17:41:48 -0800 (PST)
From: Krishna Kumar <krkumar@us.ibm.com>
X-X-Sender: krkumar@DYN318430BLD.beaverton.ibm.com
To: "David S. Miller" <davem@redhat.com>
cc: netdev@oss.sgi.com
Subject: [PATCH] bug in xfrm_lookup [bugzilla 2017]
In-Reply-To: <20040119211156.4bff1640.davem@redhat.com>
Message-ID: <Pine.LNX.4.44.0402041735320.6034-100000@DYN318430BLD.beaverton.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 3004
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: krkumar@us.ibm.com
Precedence: bulk
X-list: netdev

Hi Dave,

One of my earlier patches had a bug in xfrm_lookup() causin schedule()
to get called though MSG_DONTWAIT was specified. I am going to send
the following patch to the bugzilla user who created this bug report
and ask them to test it. I thought I will let you know of this problem
and I will send you a confirmation once I get a response that the problem
is solved.

Thanks,

- KK

diff -ruN linux-2.6.2/net/xfrm/xfrm_policy.c linux-2.6.2.new/net/xfrm/xfrm_policy.c
--- linux-2.6.2/net/xfrm/xfrm_policy.c	2004-02-04 17:33:51.000000000 -0800
+++ linux-2.6.2.new/net/xfrm/xfrm_policy.c	2004-02-04 17:34:37.000000000 -0800
@@ -775,7 +775,7 @@

 		if (unlikely(nx<0)) {
 			err = nx;
-			if (err == -EAGAIN && !flags) {
+			if (err == -EAGAIN && flags) {
 				DECLARE_WAITQUEUE(wait, current);

 				add_wait_queue(&km_waitq, &wait);


From anton@samba.org Wed Feb  4 17:56:57 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 17:57:00 -0800 (PST)
Received: from lists.samba.org (dp.samba.org [66.70.73.150])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i151uuKO019970
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 17:56:57 -0800
Received: by lists.samba.org (Postfix, from userid 504)
	id 16D002C08B; Thu,  5 Feb 2004 01:57:10 +0000 (GMT)
Date: Thu, 5 Feb 2004 12:51:49 +1100
From: Anton Blanchard <anton@samba.org>
To: Andi Kleen <ak@suse.de>
Cc: Leonid Grossman <leonid.grossman@s2io.com>, netdev@oss.sgi.com,
        raghava.vatsavayi@s2io.com, iod00d@hp.com
Subject: Re: FW: Submission for S2io 10GbE driver
Message-ID: <20040205015149.GN19011@krispykreme>
References: <20040123232209.2739e6aa.ak@suse.de> <004201c3eb5f$ac4e9f00$740efea9@S2IOtech.com> <20040205023209.4abf2342.ak@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040205023209.4abf2342.ak@suse.de>
User-Agent: Mutt/1.5.5.1+cvs20040105i
X-archive-position: 3005
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: anton@samba.org
Precedence: bulk
X-list: netdev


> > 1) We did't find quad word memory operations(writeq and readq) on PCI
> > bus for PPC64 architecture.
> 
> That's a bug in ppc64 then. Can you complain to them?  I would go
> ahead and just use them in the driver unconditionally and wait for the
> ppc64 to fix it. Or just add them there, it's probably simple.

Yep ppc64 should define them. If you are submitting a driver for
inclusion in 2.6 leave these bits out, its my fault they arent defined
and I'll get them added in.

Turns out lots of architectures are missing these, I'll fire an email
off to linux-arch about it.

> > On a little endian m/c like IA32 also writel writes same values in a
> > similar manner as shown above. 
> > So the question is -
> > Do all big endian machines with linux OS swap the values and write in
> > little endian format?? 
> 
> I hope not.

Thats how all big endian platforms work. in* and out*, read* and write*
byteswap. 

> > 3)In PPC64 architecture dma_addr_t is u32, unlike remaining 64 bit
> > architectures where it is defined as u64. Because
> > of this we have to deal separately for PP64. 
> > So any suggestions will be useful, .i.e. generally how PPC64 developers
> > deal with this?
> 
> You could just use u64 in your structure definitions for now.

Its up to the architecture as to what a dma_addr_t looks like. On our
current machines we only support operating through the IOMMU, so all
PCI bus address are in fact 32bit. Most drivers dont care how big a
dma_addr_t is, is there something you are doing that does?

Anton

From yoshfuji@linux-ipv6.org Wed Feb  4 18:09:06 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 18:09:14 -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 i15295KO020663
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 18:09:06 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 045DF33CA5; Thu,  5 Feb 2004 11:09:56 +0900 (JST)
Date: Thu, 05 Feb 2004 11:09:55 +0900 (JST)
Message-Id: <20040205.110955.10680487.yoshfuji@linux-ipv6.org>
To: dlstevens@us.ibm.com
Cc: davem@redhat.com, netdev@oss.sgi.com
Subject: Re: [PATCH] IPV6: note on shared socket options
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
In-Reply-To: <OF2F9C078B.064A8A19-ON87256E30.0077B005-88256E30.0077AF76@us.ibm.com>
References: <20040204.203739.16838230.yoshfuji@linux-ipv6.org>
	<OF2F9C078B.064A8A19-ON87256E30.0077B005-88256E30.0077AF76@us.ibm.com>
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: 3006
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: yoshfuji@linux-ipv6.org
Precedence: bulk
X-list: netdev

In article <OF2F9C078B.064A8A19-ON87256E30.0077B005-88256E30.0077AF76@us.ibm.com> (at Wed, 4 Feb 2004 13:49:51 -0800), David Stevens <dlstevens@us.ibm.com> says:

>       These are defined by draft-ietf-magma-msf-api-03.txt to be in
> netinet/in.h (no place else). What's the advantage of adding another
> copy in in6.h (which currently isn't used by anything)? Portable user apps
> must include netinet/in.h for them, and in-kernel code already does.

(I assume you're talking about the "alternatives.")

Kernel do not use netinet/*.h.

My main point is, do not let people (or myself) forget reserved 
(or used) range.  So, it is enough for me to add a comment on that.


Well, I really do not think that the name of MCAST_xxx is good.
Numeric assignment of "MCAST_xxx" functionalities 
is only required to be unique in that level in theory
since we put MCAST_xxx at network level (IPPROTO_{IP,IPV6} for now).
However, they are share just because of the name.


Anyway, what I want to add is some small note on shared range.
Thanks.

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

From leonid.grossman@s2io.com Wed Feb  4 18:48:53 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 18:48:56 -0800 (PST)
Received: from ns1.s2io.com (ns1.s2io.com [216.209.86.101])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i152moKO022445
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 18:48:53 -0800
Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98])
	by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i152lmjF013864;
	Wed, 4 Feb 2004 21:47:48 -0500 (EST)
Received: from lgt40 ([192.168.0.4])
	by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i152liKK013285;
	Wed, 4 Feb 2004 21:47:45 -0500 (EST)
From: "Leonid Grossman" <leonid.grossman@s2io.com>
To: "'Anton Blanchard'" <anton@samba.org>, "'Andi Kleen'" <ak@suse.de>
Cc: <netdev@oss.sgi.com>, <raghava.vatsavayi@s2io.com>, <iod00d@hp.com>
Subject: RE: FW: Submission for S2io 10GbE driver
Date: Wed, 4 Feb 2004 18:46:59 -0800
Message-ID: <005701c3eb92$55dc7650$7310100a@S2IOtech.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <20040205015149.GN19011@krispykreme>
X-Spam-Score: -101
X-Spam-Outlook-Score: ()
X-Spam-Features: IN_REP_TO,QUOTED_EMAIL_TEXT,USER_IN_WHITELIST
X-Scanned-By: MIMEDefang 2.34
X-archive-position: 3007
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: leonid.grossman@s2io.com
Precedence: bulk
X-list: netdev


> > > 1) We did't find quad word memory operations(writeq and readq) on 
> > > PCI bus for PPC64 architecture.
> > 
> > That's a bug in ppc64 then. Can you complain to them?  I would go 
> > ahead and just use them in the driver unconditionally and 
> wait for the 
> > ppc64 to fix it. Or just add them there, it's probably simple.
> 
> Yep ppc64 should define them. If you are submitting a driver 
> for inclusion in 2.6 leave these bits out, its my fault they 
> arent defined and I'll get them added in.

Hi Anton,
We are submitting for inclusion in 2.6 kernel but we'd like to have same
code for 
2.4 kernels as well, most our customers will stay with 2.4 for a
while... If you add the bits to 2.6, we would still need a solution for
2.4 kernel.

> > > On a little endian m/c like IA32 also writel writes same 
> values in a 
> > > similar manner as shown above. So the question is -
> > > Do all big endian machines with linux OS swap the values 
> and write in
> > > little endian format?? 
> > 
> > I hope not.
> 
> Thats how all big endian platforms work. in* and out*, read* 
> and write* byteswap. 

So, we should make the code big endian specific rather than PPC64
specific, right?

Thanks, Leonid


From errai110@kornet.net Wed Feb  4 19:39:34 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 19:39:37 -0800 (PST)
Received: from relay1.kornet.net (relay1.kornet.net [211.48.62.161])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i153dXKO024488
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 19:39:34 -0800
Received: from [211.192.194.172] (errai110@kornet.net) by 
          relay1.kornet.net (Terrace MailWatcher) 
          with ESMTP id 2004020512:39:28:010046.18361.1662
          for <netdev@oss.sgi.com>; 
          Thu, 05 Feb 2004 12:39:27 +0900 (KST) 
Message-ID: <000701c3eb99$98baabc0$3737030a@darkstar>
From: "Lee, Kuk Hyun" <errai110@kornet.net>
To: <netdev@oss.sgi.com>
References: <107592194524598240.1.ppp13@ppp13>
Subject: Re: [question] netif_rx() - why don't call raise_softirq()?
Date: Thu, 5 Feb 2004 12:39:02 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
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: 3008
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: errai110@kornet.net
Precedence: bulk
X-list: netdev

I solved it. sorry dummy posting :)



From dlstevens@us.ibm.com Wed Feb  4 20:02:39 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 20:02:43 -0800 (PST)
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1542XKO025247
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 20:02:39 -0800
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i1542Hk2657896;
	Wed, 4 Feb 2004 23:02:17 -0500
Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82])
	by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1542GOA096258;
	Wed, 4 Feb 2004 21:02:16 -0700
In-Reply-To: <20040205.110955.10680487.yoshfuji@linux-ipv6.org>
Importance: Normal
Sensitivity: 
Subject: Re: [PATCH] IPV6: note on shared socket options
To: YOSHIFUJI Hideaki /  =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
Cc: davem@redhat.com, netdev@oss.sgi.com
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFABB4DC54.4883B0FD-ON87256E31.0015A354-88256E31.0015F150@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Wed, 4 Feb 2004 21:02:15 -0700
X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November
 14, 2003) at 02/04/2004 21:02:17
MIME-Version: 1.0
Content-type: multipart/alternative; 
	Boundary="0__=08BBE4A2DF8625C48f9e8a93df938690918c08BBE4A2DF8625C4"
Content-Disposition: inline
X-archive-position: 3009
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: dlstevens@us.ibm.com
Precedence: bulk
X-list: netdev

--0__=08BBE4A2DF8625C48f9e8a93df938690918c08BBE4A2DF8625C4
Content-type: text/plain; charset=US-ASCII





I see what you mean now; I agree. I'm not sure all of the other
socket options for each of v4 and v6 appear in a single file,
either; they definitely aren't all grouped so you can tell they come
from the same numeric namespace. So, picking new numbers
requires some detective work, but every little bit helps. :-)

                        +-DLS
--0__=08BBE4A2DF8625C48f9e8a93df938690918c08BBE4A2DF8625C4
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline

<html><body>
<p>I see what you mean now; I agree. I'm not sure all of the other<br>
socket options for each of v4 and v6 appear in a single file,<br>
either; they definitely aren't all grouped so you can tell they come<br>
from the same numeric namespace. So, picking new numbers<br>
requires some detective work, but every little bit helps. :-)<br>
<br>
				+-DLS<br>
</body></html>
--0__=08BBE4A2DF8625C48f9e8a93df938690918c08BBE4A2DF8625C4--


From anton@samba.org Wed Feb  4 20:12:34 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 20:12:46 -0800 (PST)
Received: from lists.samba.org (dp.samba.org [66.70.73.150])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i154CNKO025790
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 20:12:24 -0800
Received: by lists.samba.org (Postfix, from userid 504)
	id 95C062C22C; Thu,  5 Feb 2004 03:28:01 +0000 (GMT)
Date: Thu, 5 Feb 2004 14:25:20 +1100
From: Anton Blanchard <anton@samba.org>
To: Leonid Grossman <leonid.grossman@s2io.com>
Cc: "'Andi Kleen'" <ak@suse.de>, netdev@oss.sgi.com,
        raghava.vatsavayi@s2io.com, iod00d@hp.com
Subject: Re: FW: Submission for S2io 10GbE driver
Message-ID: <20040205032519.GR19011@krispykreme>
References: <20040205015149.GN19011@krispykreme> <005701c3eb92$55dc7650$7310100a@S2IOtech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <005701c3eb92$55dc7650$7310100a@S2IOtech.com>
User-Agent: Mutt/1.5.5.1+cvs20040105i
X-archive-position: 3010
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: anton@samba.org
Precedence: bulk
X-list: netdev

 
> We are submitting for inclusion in 2.6 kernel but we'd like to have same
> code for 
> 2.4 kernels as well, most our customers will stay with 2.4 for a
> while... If you add the bits to 2.6, we would still need a solution for
> 2.4 kernel.

OK, It should be easy to get the readq/writeq macros put into 2.4 as well.

> > Thats how all big endian platforms work. in* and out*, read* 
> > and write* byteswap. 
> 
> So, we should make the code big endian specific rather than PPC64
> specific, right?

Well there are non byteswapping versions on some architectures
(__raw_read*/__raw_write*). However at least on ppc32 they dont contain
memory barriers so you could into trouble using them.

What does your code look like? You could key off __BIG_ENDIAN if you
really need to. Is it performance critical?

Anton

From pekkas@netcore.fi Wed Feb  4 22:25:52 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 22:26:12 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i156PoKO000837
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 22:25:51 -0800
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i156PTf11141;
	Thu, 5 Feb 2004 08:25:30 +0200
Date: Thu, 5 Feb 2004 08:25:29 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: David Stevens <dlstevens@us.ibm.com>
cc: YOSHIFUJI Hideaki /  =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>,
        <davem@redhat.com>, <netdev@oss.sgi.com>
Subject: Re: [PATCH] IPV6: note on shared socket options
In-Reply-To: <OF2F9C078B.064A8A19-ON87256E30.0077B005-88256E30.0077AF76@us.ibm.com>
Message-ID: <Pine.LNX.4.44.0402050824170.10943-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
X-archive-position: 3011
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: pekkas@netcore.fi
Precedence: bulk
X-list: netdev

On Wed, 4 Feb 2004, David Stevens wrote:
> Yoshifuji-san,
>       These are defined by draft-ietf-magma-msf-api-03.txt to be in
> netinet/in.h (no place else). What's the advantage of adding another
> copy in in6.h (which currently isn't used by anything)? Portable user apps
> must include netinet/in.h for them, and in-kernel code already does.

FWIW, this is already RFC 3678, so it might make sense to check 
whether there have been changes since the draft version implemented.

> YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>@oss.sgi.com on
> 02/04/2004 03:37:39 AM
> 
> Sent by:    netdev-bounce@oss.sgi.com
> 
> 
> To:    davem@redhat.com
> cc:    yoshfuji@linux-ipv6.org, netdev@oss.sgi.com
> Subject:    [PATCH] IPV6: note on shared socket options
> 
> 
> 
> Hello.
> 
> There're several socket options for multicast
> shared between IPv4 and IPv6.
> Add a note that some range is already used for them.
> 
> (Alternatevely, we could define other names like this:
>  #define IPV6_MCAST_JOIN_GROUP   MCAST_JOIN_GROUP
>  #define IPV6_MCAST_BLOCK_SOURCE MCAST_BLOCK_SOURCE
>  /* bla, bla ... */
> )
> 
> ===== include/linux/in6.h 1.5 vs edited =====
> --- 1.5/include/linux/in6.h   Fri Mar 21 14:23:30 2003
> +++ edited/include/linux/in6.h      Wed Feb  4 20:30:47 2004
> @@ -183,5 +183,17 @@
>  #define IPV6_IPSEC_POLICY    34
>  #define IPV6_XFRM_POLICY     35
> 
> +/*
> + * Multicast:
> + * Following socket options are shared between IPv4 and IPv6.
> + *
> + * MCAST_JOIN_GROUP          42
> + * MCAST_BLOCK_SOURCE        43
> + * MCAST_UNBLOCK_SOURCE            44
> + * MCAST_LEAVE_GROUP         45
> + * MCAST_JOIN_SOURCE_GROUP   46
> + * MCAST_LEAVE_SOURCE_GROUP  47
> + * MCAST_MSFILTER            48
> + */
> 
>  #endif
> 
> --
> Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
> GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


From davem@redhat.com Wed Feb  4 23:13:02 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 23:13:20 -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 i157D1KO011019
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 23:13:02 -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 i157D0b16710;
	Thu, 5 Feb 2004 02:13:00 -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 i157D0a16633;
	Thu, 5 Feb 2004 02:13:00 -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 i157CUkC010625;
	Thu, 5 Feb 2004 02:12:30 -0500
Date: Wed, 4 Feb 2004 23:12:59 -0800
From: "David S. Miller" <davem@redhat.com>
To: Krishna Kumar <krkumar@us.ibm.com>
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH] bug in xfrm_lookup [bugzilla 2017]
Message-Id: <20040204231259.0a2888f9.davem@redhat.com>
In-Reply-To: <Pine.LNX.4.44.0402041735320.6034-100000@DYN318430BLD.beaverton.ibm.com>
References: <20040119211156.4bff1640.davem@redhat.com>
	<Pine.LNX.4.44.0402041735320.6034-100000@DYN318430BLD.beaverton.ibm.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: 3012
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 Wed, 4 Feb 2004 17:41:48 -0800 (PST)
Krishna Kumar <krkumar@us.ibm.com> wrote:

> One of my earlier patches had a bug in xfrm_lookup() causin schedule()
> to get called though MSG_DONTWAIT was specified. I am going to send
> the following patch to the bugzilla user who created this bug report
> and ask them to test it. I thought I will let you know of this problem
> and I will send you a confirmation once I get a response that the problem
> is solved.

You patch looks correct so I'll apply it for now, if something is
wrong with it send me a fix relative to this patch.

Thanks.

From davem@redhat.com Wed Feb  4 23:21:14 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 23:21:26 -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 i157LDKO011679
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 23:21:13 -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 i157LAb20070;
	Thu, 5 Feb 2004 02:21:10 -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 i157LAa18344;
	Thu, 5 Feb 2004 02:21:10 -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 i157KdkC028145;
	Thu, 5 Feb 2004 02:20:40 -0500
Date: Wed, 4 Feb 2004 23:21:09 -0800
From: "David S. Miller" <davem@redhat.com>
To: yoshfuji@linux-ipv6.org
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH] IPV6: note on shared socket options
Message-Id: <20040204232109.0ad8d5b9.davem@redhat.com>
In-Reply-To: <20040204.203739.16838230.yoshfuji@linux-ipv6.org>
References: <20040204.203739.16838230.yoshfuji@linux-ipv6.org>
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 i157LDKO011679
X-archive-position: 3013
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 Wed, 04 Feb 2004 20:37:39 +0900 (JST)
YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> wrote:

> There're several socket options for multicast
> shared between IPv4 and IPv6.
> Add a note that some range is already used for them.

Applied, thanks Yoshfuji.

As others noted, this in kernel internal headers, our own namespace,
and it's documentation so it's fine.


From davem@redhat.com Wed Feb  4 23:23:04 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 23:23:11 -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 i157N3KO012121
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 23:23:04 -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 i157Mvb20934;
	Thu, 5 Feb 2004 02:22:57 -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 i157Mva18859;
	Thu, 5 Feb 2004 02:22:57 -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 i157MQkC008432;
	Thu, 5 Feb 2004 02:22:26 -0500
Date: Wed, 4 Feb 2004 23:22:56 -0800
From: "David S. Miller" <davem@redhat.com>
To: chas williams (contractor) <chas@cmf.nrl.navy.mil>
Cc: rddunlap@osdl.org, netdev@oss.sgi.com
Subject: Re: [PATCH] atm/idt77252: correct printk of dma_addr_t
Message-Id: <20040204232256.0857bc5c.davem@redhat.com>
In-Reply-To: <200402041904.i14J4xRr017789@ginger.cmf.nrl.navy.mil>
References: <20040203153448.5c81e49d.rddunlap@osdl.org>
	<200402041904.i14J4xRr017789@ginger.cmf.nrl.navy.mil>
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: 3014
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 Wed, 04 Feb 2004 14:05:00 -0500
chas williams (contractor) <chas@cmf.nrl.navy.mil> wrote:

> dave, please apply the following to the 2.6 and 2.4 trees.

Done, thanks Randy/Chas.

From davem@redhat.com Wed Feb  4 23:24:21 2004
Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 Feb 2004 23:24:31 -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 i157OKKO012517
	for <netdev@oss.sgi.com>; Wed, 4 Feb 2004 23:24:20 -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 i157OFb21488;
	Thu, 5 Feb 2004 02:24:15 -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 i157OEa19273;
	Thu, 5 Feb 2004 02:24:14 -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 i157NikC008471;
	Thu, 5 Feb 2004 02:23:44 -0500
Date: Wed, 4 Feb 2004 23:24:14 -0800
From: "David S. Miller" <davem@redhat.com>
To: chas williams (contractor) <chas@cmf.nrl.navy.mil>
Cc: rddunlap@osdl.org, netdev@oss.sgi.com
Subject: Re: Fw: [Kernel-janitors] net/atm/clip.c: check kmem_cache_create()
 #1
Message-Id: <20040204232414.05dc8702.davem@redhat.com>
In-Reply-To: <200402041904.i14J4GRr017777@ginger.cmf.nrl.navy.mil>
References: <20040128091803.1da4cf1c.rddunlap@osdl.org>
	<200402041904.i14J4GRr017777@ginger.cmf.nrl.navy.mil>
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: 3015
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 Wed, 04 Feb 2004 14:04:17 -0500
chas williams (contractor) <chas@cmf.nrl.navy.mil> wrote:

> randy, i think it should probably return -ENOMEM instead of -1.
> 
> dave, please apply the following to both the 2.6 and 2.4 trees.

Applied, thanks guys.

From jgarzik@pobox.com Thu Feb  5 01:27:42 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 01:27:56 -0800 (PST)
Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i159ReKO023989
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 01:27:41 -0800
Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:37013 helo=pobox.com)
	by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256)
	(Exim 4.22)
	id 1AofnN-0008Rh-IN; Thu, 05 Feb 2004 09:27:37 +0000
Message-ID: <40220C7D.2060503@pobox.com>
Date: Thu, 05 Feb 2004 04:27:25 -0500
From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Anton Blanchard <anton@samba.org>
CC: Leonid Grossman <leonid.grossman@s2io.com>, "'Andi Kleen'" <ak@suse.de>,
        netdev@oss.sgi.com, raghava.vatsavayi@s2io.com, iod00d@hp.com
Subject: Re: FW: Submission for S2io 10GbE driver
References: <20040205015149.GN19011@krispykreme> <005701c3eb92$55dc7650$7310100a@S2IOtech.com> <20040205032519.GR19011@krispykreme>
In-Reply-To: <20040205032519.GR19011@krispykreme>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-archive-position: 3016
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: jgarzik@pobox.com
Precedence: bulk
X-list: netdev

Anton Blanchard wrote:
> Well there are non byteswapping versions on some architectures
> (__raw_read*/__raw_write*). However at least on ppc32 they dont contain
> memory barriers so you could into trouble using them.


FWIW the __raw_xxx are not supposed to contain memory barriers.  That's 
for when the driver writer decides he is smart enough to do the byte 
swapping and barriers himself, for possibly increased speed :)

	Jeff




From jgarzik@pobox.com Thu Feb  5 01:30:11 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 01:30:25 -0800 (PST)
Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i159UAKO024346
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 01:30:10 -0800
Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:37014 helo=pobox.com)
	by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256)
	(Exim 4.22)
	id 1Aofpo-00009i-UT; Thu, 05 Feb 2004 09:30:09 +0000
Message-ID: <40220D15.60603@pobox.com>
Date: Thu, 05 Feb 2004 04:29:57 -0500
From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Leonid Grossman <leonid.grossman@s2io.com>
CC: "'Anton Blanchard'" <anton@samba.org>, "'Andi Kleen'" <ak@suse.de>,
        netdev@oss.sgi.com, raghava.vatsavayi@s2io.com, iod00d@hp.com
Subject: Re: FW: Submission for S2io 10GbE driver
References: <005701c3eb92$55dc7650$7310100a@S2IOtech.com>
In-Reply-To: <005701c3eb92$55dc7650$7310100a@S2IOtech.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-archive-position: 3017
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: jgarzik@pobox.com
Precedence: bulk
X-list: netdev

Leonid Grossman wrote:
>>Thats how all big endian platforms work. in* and out*, read* 
>>and write* byteswap. 
> 
> 
> So, we should make the code big endian specific rather than PPC64
> specific, right?


{read,write}[bwlq] should work the same regardless of whether its big 
endian or little endian.  The rule is "PCI is defined to be little 
endian".  On little endian platforms, no byte swapping occurs.  On big 
endian platforms, the platform will byteswap.  Thus, the driver should 
not have big-endian-specific or PPC64-specific code...

(you still have to do your own byteswapping for DMA)

	Jeff




From jgarzik@pobox.com Thu Feb  5 01:46:09 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 01:46:22 -0800 (PST)
Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i159k8KO025161
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 01:46:09 -0800
Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:37022 helo=pobox.com)
	by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256)
	(Exim 4.22)
	id 1Aog5G-0000qp-Kw; Thu, 05 Feb 2004 09:46:06 +0000
Message-ID: <402210D2.1030906@pobox.com>
Date: Thu, 05 Feb 2004 04:45:54 -0500
From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net>
CC: Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Netdev <netdev@oss.sgi.com>, Manfred Spraul <manfred@colorfullife.com>
Subject: Re: [PATCH] [2.4] forcedeth network driver
References: <402193B9.3000000@gmx.net>
In-Reply-To: <402193B9.3000000@gmx.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-archive-position: 3018
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: jgarzik@pobox.com
Precedence: bulk
X-list: netdev

Applied.

I'll send to Marcelo...  but it's up to him whether he will include it 
in 2.4.25-pre ot 2.4.26-pre.  He said he's planning on releasing 
2.4.25-rc soon...

	Jeff





From jgarzik@pobox.com Thu Feb  5 01:48:58 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 01:49:10 -0800 (PST)
Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i159mvKO025588
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 01:48:57 -0800
Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:37027 helo=pobox.com)
	by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256)
	(Exim 4.22)
	id 1Aog80-0000tg-92; Thu, 05 Feb 2004 09:48:56 +0000
Message-ID: <4022117C.60400@pobox.com>
Date: Thu, 05 Feb 2004 04:48:44 -0500
From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net>
CC: Netdev <netdev@oss.sgi.com>, Manfred Spraul <manfred@colorfullife.com>
Subject: Re: [PATCH] [2.6] Update forcedeth to 0.23
References: <402190AC.2040307@gmx.net>
In-Reply-To: <402190AC.2040307@gmx.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-archive-position: 3019
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: jgarzik@pobox.com
Precedence: bulk
X-list: netdev

applied



From jgarzik@pobox.com Thu Feb  5 02:16:49 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 02:18:09 -0800 (PST)
Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15AGmKO026676
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 02:16:49 -0800
Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:37045 helo=pobox.com)
	by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256)
	(Exim 4.22)
	id 1AogYw-0001cx-F6; Thu, 05 Feb 2004 10:16:46 +0000
Message-ID: <40221803.7070208@pobox.com>
Date: Thu, 05 Feb 2004 05:16:35 -0500
From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Dillow <dave@thedillows.org>
CC: Netdev <netdev@oss.sgi.com>
Subject: Re: [BK] Updated 2.6 typhoon driver for 3CR990 & 3CR990B cards
References: <1075260716.3637.4.camel@ori.thedillows.org>
In-Reply-To: <1075260716.3637.4.camel@ori.thedillows.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-archive-position: 3020
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: jgarzik@pobox.com
Precedence: bulk
X-list: netdev

applied to 2.4 and 2.6



From chas@cmf.nrl.navy.mil Thu Feb  5 04:22:48 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 04:22:54 -0800 (PST)
Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15CMlKO004558
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 04:22:48 -0800
Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180])
	by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id i15CMcRr029937;
	Thu, 5 Feb 2004 07:22:39 -0500 (EST)
Message-Id: <200402051222.i15CMcRr029937@ginger.cmf.nrl.navy.mil>
To: Francois Romieu <romieu@fr.zoreil.com>
cc: davem@redhat.com, "Randy.Dunlap" <rddunlap@osdl.org>, netdev@oss.sgi.com
Subject: Re: Fw: [Kernel-janitors] net/atm/clip.c: check kmem_cache_create() #1 
In-Reply-To: Message from Francois Romieu <romieu@fr.zoreil.com> 
   of "Wed, 04 Feb 2004 22:47:40 +0100." <20040204224740.B19321@electric-eye.fr.zoreil.com> 
Date: Thu, 05 Feb 2004 07:22:40 -0500
From: chas williams (contractor) <chas@cmf.nrl.navy.mil>
X-Spam-Score: () hits=-0.3
X-Virus-Scanned: NAI Completed
X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
X-archive-position: 3021
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: chas@cmf.nrl.navy.mil
Precedence: bulk
X-list: netdev

In message <20040204224740.B19321@electric-eye.fr.zoreil.com>,Francois Romieu w
rites:
>One should probably apply the following patch on top of it btw.
>Unbalanced call to create_proc_entry() on error path.

how about the following instead?  we probably shouldnt register the
proc entry until clip_tbl is going to be ready for use anyway (the
arp table iterators should probably also use clip_tbl instead of
clip_tbl_hook).

===== net/atm/clip.c 1.30 vs edited =====
--- 1.30/net/atm/clip.c	Wed Feb  4 13:07:57 2004
+++ edited/net/atm/clip.c	Thu Feb  5 07:18:03 2004
@@ -1008,14 +1008,6 @@
 
 static int __init atm_clip_init(void)
 {
-#ifdef CONFIG_PROC_FS
-	struct proc_dir_entry *p;
-
-	p = create_proc_entry("arp", S_IRUGO, atm_proc_root);
-	if (p)
-		p->proc_fops = &arp_seq_fops;
-#endif
-
 	/* we should use neigh_table_init() */
 	clip_tbl.lock = RW_LOCK_UNLOCKED;
 	clip_tbl.kmem_cachep = kmem_cache_create(clip_tbl.id,
@@ -1032,6 +1024,16 @@
 
 	clip_tbl_hook = &clip_tbl;
 	register_atm_ioctl(&clip_ioctl_ops);
+
+#ifdef CONFIG_PROC_FS
+{
+	struct proc_dir_entry *p;
+
+	p = create_proc_entry("arp", S_IRUGO, atm_proc_root);
+	if (p)
+		p->proc_fops = &arp_seq_fops;
+}
+#endif
 
 	return 0;
 }

From shmulik.hen@intel.com Thu Feb  5 05:59:21 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 05:59:32 -0800 (PST)
Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15DxLKO009192
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 05:59:21 -0800
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129])
	by petasus.ch.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i15DxEmG017641;
	Thu, 5 Feb 2004 13:59:14 GMT
Received: from jrslxjul4.npdj.intel.com ([10.12.220.54])
 by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020505591110770
 ; Thu, 05 Feb 2004 05:59:13 -0800
From: Shmuel Hen <shmulik.hen@intel.com>
Organization: Intel Corporation
To: "David S. Miller" <davem@redhat.com>
Subject: [PATCH] [NET] split arp_send into arp_create and arp_xmit (resend)
Date: Thu, 5 Feb 2004 15:58:56 +0200
User-Agent: KMail/1.5.3
Cc: <netdev@oss.sgi.com>, "Jeff Garzik" <jgarzik@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200402051559.10075.shmulik.hen@intel.com>
X-archive-position: 3023
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: shmulik.hen@intel.com
Precedence: bulk
X-list: netdev
Content-Length: 4176
Lines: 154

Enable intermediate network drivers like bonding to create an ARP 
packet and modify it to their needs before sending it, while avoiding 
code duplication. It does not affect any other place in the kernel 
that uses arp_send.

Tested for patch application and compilation against linux-2.6.2.

-- 
| Shmulik Hen   Advanced Network Services  |
| Israel Design Center, Jerusalem          |
| LAN Access Division, Platform Networking |
| Intel Communications Group, Intel corp.  |


diff -Nuarp a/include/net/arp.h b/include/net/arp.h
--- a/include/net/arp.h	Wed Jan 21 16:56:05 2004
+++ b/include/net/arp.h	Wed Jan 21 16:56:07 2004
@@ -5,6 +5,8 @@
 #include <linux/if_arp.h>
 #include <net/neighbour.h>
 
+#define HAVE_ARP_CREATE
+
 extern struct neigh_table arp_tbl;
 
 extern void	arp_init(void);
@@ -19,6 +21,12 @@ extern int	arp_bind_neighbour(struct dst
 extern int	arp_mc_map(u32 addr, u8 *haddr, struct net_device *dev, int dir);
 extern void	arp_ifdown(struct net_device *dev);
 
+extern struct sk_buff *arp_create(int type, int ptype, u32 dest_ip,
+				  struct net_device *dev, u32 src_ip,
+				  unsigned char *dest_hw, unsigned char *src_hw,
+				  unsigned char *target_hw);
+extern void arp_xmit(struct sk_buff *skb);
+
 extern struct neigh_ops arp_broken_ops;
 
 #endif	/* _ARP_H */
diff -Nuarp a/net/ipv4/arp.c b/net/ipv4/arp.c
--- a/net/ipv4/arp.c	Wed Jan 21 16:56:05 2004
+++ b/net/ipv4/arp.c	Wed Jan 21 16:56:07 2004
@@ -67,6 +67,10 @@
  *					now it is in net/core/neighbour.c.
  *		Krzysztof Halasa:	Added Frame Relay ARP support.
  *		Arnaldo C. Melo :	convert /proc/net/arp to seq_file
+ *		Shmulik Hen:		Split arp_send to arp_create and
+ *					arp_xmit so intermediate drivers like
+ *					bonding can change the skb before
+ *					sending (e.g. insert 8021q tag).
  */
 
 #include <linux/module.h>
@@ -487,34 +491,26 @@ static inline int arp_fwd_proxy(struct i
  */
 
 /*
- *	Create and send an arp packet. If (dest_hw == NULL), we create a broadcast
+ *	Create an arp packet. If (dest_hw == NULL), we create a broadcast
  *	message.
  */
-
-void arp_send(int type, int ptype, u32 dest_ip, 
-	      struct net_device *dev, u32 src_ip, 
-	      unsigned char *dest_hw, unsigned char *src_hw,
-	      unsigned char *target_hw)
+struct sk_buff *arp_create(int type, int ptype, u32 dest_ip,
+			   struct net_device *dev, u32 src_ip,
+			   unsigned char *dest_hw, unsigned char *src_hw,
+			   unsigned char *target_hw)
 {
 	struct sk_buff *skb;
 	struct arphdr *arp;
 	unsigned char *arp_ptr;
 
 	/*
-	 *	No arp on this interface.
-	 */
-	
-	if (dev->flags&IFF_NOARP)
-		return;
-
-	/*
 	 *	Allocate a buffer
 	 */
 	
 	skb = alloc_skb(sizeof(struct arphdr)+ 2*(dev->addr_len+4)
 				+ LL_RESERVED_SPACE(dev), GFP_ATOMIC);
 	if (skb == NULL)
-		return;
+		return NULL;
 
 	skb_reserve(skb, LL_RESERVED_SPACE(dev));
 	skb->nh.raw = skb->data;
@@ -594,12 +590,46 @@ void arp_send(int type, int ptype, u32 d
 	arp_ptr+=dev->addr_len;
 	memcpy(arp_ptr, &dest_ip, 4);
 
-	/* Send it off, maybe filter it using firewalling first.  */
-	NF_HOOK(NF_ARP, NF_ARP_OUT, skb, NULL, dev, dev_queue_xmit);
-	return;
+	return skb;
 
 out:
 	kfree_skb(skb);
+	return NULL;
+}
+
+/*
+ *	Send an arp packet.
+ */
+void arp_xmit(struct sk_buff *skb)
+{
+	/* Send it off, maybe filter it using firewalling first.  */
+	NF_HOOK(NF_ARP, NF_ARP_OUT, skb, NULL, skb->dev, dev_queue_xmit);
+}
+
+/*
+ *	Create and send an arp packet.
+ */
+void arp_send(int type, int ptype, u32 dest_ip, 
+	      struct net_device *dev, u32 src_ip, 
+	      unsigned char *dest_hw, unsigned char *src_hw,
+	      unsigned char *target_hw)
+{
+	struct sk_buff *skb;
+
+	/*
+	 *	No arp on this interface.
+	 */
+	
+	if (dev->flags&IFF_NOARP)
+		return;
+
+	skb = arp_create(type, ptype, dest_ip, dev, src_ip,
+			 dest_hw, src_hw, target_hw);
+	if (skb == NULL) {
+		return;
+	}
+
+	arp_xmit(skb);
 }
 
 static void parp_redo(struct sk_buff *skb)
@@ -1437,6 +1467,8 @@ static int __init arp_proc_init(void)
 EXPORT_SYMBOL(arp_broken_ops);
 EXPORT_SYMBOL(arp_find);
 EXPORT_SYMBOL(arp_rcv);
+EXPORT_SYMBOL(arp_create);
+EXPORT_SYMBOL(arp_xmit);
 EXPORT_SYMBOL(arp_send);
 EXPORT_SYMBOL(arp_tbl);
 


From shmulik.hen@intel.com Thu Feb  5 05:59:54 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 06:00:00 -0800 (PST)
Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15DxsKO009267
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 05:59:54 -0800
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129])
	by petasus.ch.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i15DxBmU017640;
	Thu, 5 Feb 2004 13:59:48 GMT
Received: from jrslxjul4.npdj.intel.com ([10.12.220.54])
 by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020505594510854
 ; Thu, 05 Feb 2004 05:59:47 -0800
From: Shmuel Hen <shmulik.hen@intel.com>
Organization: Intel Corporation
To: "David S. Miller" <davem@redhat.com>
Subject: [PATCH] [8021q] Use VLAN tag set functionality in 8021q module (resend)
Date: Thu, 5 Feb 2004 15:59:43 +0200
User-Agent: KMail/1.5.3
Cc: <netdev@oss.sgi.com>, "Jeff Garzik" <jgarzik@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200402051559.45159.shmulik.hen@intel.com>
X-archive-position: 3024
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: shmulik.hen@intel.com
Precedence: bulk
X-list: netdev
Content-Length: 3735
Lines: 121

Make the regular/HW accelerated xmit functions in the 8021q module 
use the new set VLAN tag functionality to reduce code duplication. 

Tested for patch application and compilation against linux-2.6.2.

 
-- 
| Shmulik Hen   Advanced Network Services  |
| Israel Design Center, Jerusalem          |
| LAN Access Division, Platform Networking |
| Intel Communications Group, Intel corp.  |


diff -Nuarp a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
--- a/net/8021q/vlan_dev.c	Wed Jan 21 16:56:13 2004
+++ b/net/8021q/vlan_dev.c	Wed Jan 21 16:56:15 2004
@@ -445,6 +445,7 @@ int vlan_dev_hard_start_xmit(struct sk_b
 	 */
 
 	if (veth->h_vlan_proto != __constant_htons(ETH_P_8021Q)) {
+		int orig_headroom = skb_headroom(skb);
 		unsigned short veth_TCI;
 
 		/* This is not a VLAN frame...but we can fix that! */
@@ -454,33 +455,7 @@ int vlan_dev_hard_start_xmit(struct sk_b
 		printk(VLAN_DBG "%s: proto to encap: 0x%hx (hbo)\n",
 			__FUNCTION__, htons(veth->h_vlan_proto));
 #endif
-
-		if (skb_headroom(skb) < VLAN_HLEN) {
-			struct sk_buff *sk_tmp = skb;
-			skb = skb_realloc_headroom(sk_tmp, VLAN_HLEN);
-			kfree_skb(sk_tmp);
-			if (skb == NULL) {
-				stats->tx_dropped++;
-				return 0;
-			}
-			VLAN_DEV_INFO(dev)->cnt_inc_headroom_on_tx++;
-		} else {
-			if (!(skb = skb_unshare(skb, GFP_ATOMIC))) {
-				printk(KERN_ERR "vlan: failed to unshare skbuff\n");
-				stats->tx_dropped++;
-				return 0;
-			}
-		}
-		veth = (struct vlan_ethhdr *)skb_push(skb, VLAN_HLEN);
-
-		/* Move the mac addresses to the beginning of the new header. */
-		memmove(skb->data, skb->data + VLAN_HLEN, 12);
-
-		/* first, the ethernet type */
-		/* put_unaligned(__constant_htons(ETH_P_8021Q), &veth->h_vlan_proto); */
-		veth->h_vlan_proto = __constant_htons(ETH_P_8021Q);
-
-		/* Now, construct the second two bytes. This field looks something
+		/* Construct the second two bytes. This field looks something
 		 * like:
 		 * usr_priority: 3 bits	 (high bits)
 		 * CFI		 1 bit
@@ -489,10 +464,16 @@ int vlan_dev_hard_start_xmit(struct sk_b
 		veth_TCI = VLAN_DEV_INFO(dev)->vlan_id;
 		veth_TCI |= vlan_dev_get_egress_qos_mask(dev, skb);
 
-		veth->h_vlan_TCI = htons(veth_TCI);
-	}
+		skb = __vlan_put_tag(skb, veth_TCI);
+		if (!skb) {
+			stats->tx_dropped++;
+			return 0;
+		}
 
-	skb->dev = VLAN_DEV_INFO(dev)->real_dev;
+		if (orig_headroom < VLAN_HLEN) {
+			VLAN_DEV_INFO(dev)->cnt_inc_headroom_on_tx++;
+		}
+	}
 
 #ifdef VLAN_DEBUG
 	printk(VLAN_DBG "%s: about to send skb: %p to dev: %s\n",
@@ -506,10 +487,7 @@ int vlan_dev_hard_start_xmit(struct sk_b
 	stats->tx_packets++; /* for statics only */
 	stats->tx_bytes += skb->len;
 
-	skb->protocol = __constant_htons(ETH_P_8021Q);
-	skb->mac.raw -= VLAN_HLEN;
-	skb->nh.raw -= VLAN_HLEN;
-
+	skb->dev = VLAN_DEV_INFO(dev)->real_dev;
 	dev_queue_xmit(skb);
 
 	return 0;
@@ -518,17 +496,22 @@ int vlan_dev_hard_start_xmit(struct sk_b
 int vlan_dev_hwaccel_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct net_device_stats *stats = vlan_dev_get_stats(dev);
-	struct vlan_skb_tx_cookie *cookie;
+	unsigned short veth_TCI;
+
+	/* Construct the second two bytes. This field looks something
+	 * like:
+	 * usr_priority: 3 bits	 (high bits)
+	 * CFI		 1 bit
+	 * VLAN ID	 12 bits (low bits)
+	 */
+	veth_TCI = VLAN_DEV_INFO(dev)->vlan_id;
+	veth_TCI |= vlan_dev_get_egress_qos_mask(dev, skb);
+	skb = __vlan_hwaccel_put_tag(skb, veth_TCI);
 
 	stats->tx_packets++;
 	stats->tx_bytes += skb->len;
 
 	skb->dev = VLAN_DEV_INFO(dev)->real_dev;
-	cookie = VLAN_TX_SKB_CB(skb);
-	cookie->magic = VLAN_TX_COOKIE_MAGIC;
-	cookie->vlan_tag = (VLAN_DEV_INFO(dev)->vlan_id |
-			    vlan_dev_get_egress_qos_mask(dev, skb));
-
 	dev_queue_xmit(skb);
 
 	return 0;


From willy@w.ods.org Thu Feb  5 10:22:16 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 10:22:24 -0800 (PST)
Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15IMCKO023325
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 10:22:15 -0800
Date: Thu, 5 Feb 2004 19:21:46 +0100
From: Willy Tarreau <willy@w.ods.org>
To: David Stevens <dlstevens@us.ibm.com>
Cc: "David S. Miller" <davem@redhat.com>, netdev@oss.sgi.com,
        jgarzik@pobox.com, Alexandre.Cassen@wanadoo.fr
Subject: Re: Deadlock problem with dev->refcnt somewhere in netlink/multicast... [PATCH]
Message-ID: <20040205182146.GA12703@alpha.home.local>
References: <OFDBAB37F5.227951E9-ON88256E2E.0080F5BF@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OFDBAB37F5.227951E9-ON88256E2E.0080F5BF@us.ibm.com>
User-Agent: Mutt/1.4i
X-archive-position: 3025
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: willy@w.ods.org
Precedence: bulk
X-list: netdev
Content-Length: 315
Lines: 11

Hi David,

On Mon, Feb 02, 2004 at 04:41:11PM -0700, David Stevens wrote:
> Below is a patch for the reference count problem you ran into.

I have just tested 2.4.25-rc1 (which includes your patch) right now, and I
cannot reproduce the problem anymore. So to me, the problem is closed.

Thanks for the fix !
Willy


From romieu@fr.zoreil.com Thu Feb  5 10:40:22 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 10:40:32 -0800 (PST)
Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15IeKKO024120
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 10:40:21 -0800
Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1])
	by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i15IcEgf004706;
	Thu, 5 Feb 2004 19:38:14 +0100
Received: (from romieu@localhost)
	by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i15IcDa5004705;
	Thu, 5 Feb 2004 19:38:13 +0100
Date: Thu, 5 Feb 2004 19:38:13 +0100
From: Francois Romieu <romieu@fr.zoreil.com>
To: chas williams <chas@cmf.nrl.navy.mil>
Cc: "Randy.Dunlap" <rddunlap@osdl.org>, netdev@oss.sgi.com
Subject: Re: Fw: [Kernel-janitors] net/atm/clip.c: check kmem_cache_create() #1
Message-ID: <20040205193813.A4230@electric-eye.fr.zoreil.com>
References: <romieu@fr.zoreil.com> <200402051222.i15CMcRr029937@ginger.cmf.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200402051222.i15CMcRr029937@ginger.cmf.nrl.navy.mil>; from chas@cmf.nrl.navy.mil on Thu, Feb 05, 2004 at 07:22:40AM -0500
X-Organisation: Land of Sunshine Inc.
X-archive-position: 3026
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: romieu@fr.zoreil.com
Precedence: bulk
X-list: netdev
Content-Length: 495
Lines: 15

chas williams <chas@cmf.nrl.navy.mil> :
[...]
> how about the following instead?  we probably shouldnt register the

As long as the ugly-ifdef patrol does not bite, it's fine with me. :o)

> proc entry until clip_tbl is going to be ready for use anyway (the
> arp table iterators should probably also use clip_tbl instead of
> clip_tbl_hook).

It would not hurt. Do you have a specific race in mind before I send
an update on top your patch for the clip_tbl_hook -> clip_tbl change ?

--
Ueimor

From chas@cmf.nrl.navy.mil Thu Feb  5 10:49:01 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 10:49:03 -0800 (PST)
Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15In0KO024636
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 10:49:00 -0800
Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180])
	by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id i15ImrRr005748;
	Thu, 5 Feb 2004 13:48:53 -0500 (EST)
Message-Id: <200402051848.i15ImrRr005748@ginger.cmf.nrl.navy.mil>
To: Francois Romieu <romieu@fr.zoreil.com>
cc: netdev@oss.sgi.com
Subject: Re: Fw: [Kernel-janitors] net/atm/clip.c: check kmem_cache_create() #1 
In-Reply-To: Message from Francois Romieu <romieu@fr.zoreil.com> 
   of "Thu, 05 Feb 2004 19:38:13 +0100." <20040205193813.A4230@electric-eye.fr.zoreil.com> 
Date: Thu, 05 Feb 2004 13:48:55 -0500
From: chas williams (contractor) <chas@cmf.nrl.navy.mil>
X-Spam-Score: (*) hits=1.7
X-Virus-Scanned: NAI Completed
X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
X-archive-position: 3027
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: chas@cmf.nrl.navy.mil
Precedence: bulk
X-list: netdev
Content-Length: 574
Lines: 13

In message <20040205193813.A4230@electric-eye.fr.zoreil.com>,Francois Romieu wr
ites:
>As long as the ugly-ifdef patrol does not bite, it's fine with me. :o)

it would less ugly if people could accept a possibly unused stack
variable for the !CONFIG_PROC_FS case.

>It would not hurt. Do you have a specific race in mind before I send
>an update on top your patch for the clip_tbl_hook -> clip_tbl change ?

no particular race.  just that the arp /proc entry should not be available
until clip gets initialized.  clip_tbl_hook should only be used by 
net/ipv4/arp.c really.

From rask@sygehus.dk Thu Feb  5 11:45:14 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 11:45:17 -0800 (PST)
Received: from 0x50a41c51.albnxx15.adsl-dhcp.tele.dk (0x50a41c51.albnxx15.adsl-dhcp.tele.dk [80.164.28.81])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15JjDKO026413
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 11:45:14 -0800
Received: by 0x535857c9.albnxx15.adsl-dhcp.tele.dk (Postfix, from userid 500)
	id 06E7910B45; Thu,  5 Feb 2004 20:45:11 +0100 (CET)
Date: Thu, 5 Feb 2004 20:45:11 +0100
From: Rask Ingemann Lambertsen <rask@sygehus.dk>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: linux-net@vger.kernel.org, Netdev <netdev@oss.sgi.com>
Subject: Re: Seventh release of i82586 drivers: Novell NE3200, Microdyne EXOS 205T/215T and Intel EtherExpress 16
Message-ID: <20040205204511.C7335@sygehus.dk>
References: <20031031155341.B1773@sygehus.dk> <3FA2854C.9080801@pobox.com> <20031031180525.A1984@sygehus.dk> <20031107192543.A1921@sygehus.dk> <4013175C.6090607@pobox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <4013175C.6090607@pobox.com>; from jgarzik@pobox.com on Sat, Jan 24, 2004 at 08:09:48PM -0500
X-archive-position: 3028
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: rask@sygehus.dk
Precedence: bulk
X-list: netdev
Content-Length: 651
Lines: 18

On Sat, Jan 24, 2004 at 08:09:48PM -0500, Jeff Garzik wrote:
> Rask Ingemann Lambertsen wrote:
> > I now have patches against linux 2.4.22-bk45. Due to the size I won't post
> > them to the list. They can be downloaded instead:
> > 
> > <URL:http://users.cybercity.dk/~ccc94453/linux/i82586/i82586-2.4.22bk45.patch1.bz2>
> > (bzip2 compressed, 41140 bytes)
> > <URL:http://users.cybercity.dk/~ccc94453/linux/i82586/i82586-2.4.22bk45.patch1.txt>
> > (uncompressed, 175346 bytes)
> 
> I've been slow getting to these... any chance you could re-diff against 
> 2.4.25-pre7?

Will do, but probably not until Monday.

-- 
Regards,
Rask Ingemann Lambertsen

From jgarzik@pobox.com Thu Feb  5 12:09:53 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 12:09:56 -0800 (PST)
Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15K9qKO027380
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 12:09:53 -0800
Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:37223 helo=pobox.com)
	by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256)
	(Exim 4.22)
	id 1Aopot-0002eS-Hl
	for netdev@oss.sgi.com; Thu, 05 Feb 2004 20:09:51 +0000
Message-ID: <4022A2F5.7050107@pobox.com>
Date: Thu, 05 Feb 2004 15:09:25 -0500
From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Netdev <netdev@oss.sgi.com>
Subject: New NAPI work applied...
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-archive-position: 3029
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: jgarzik@pobox.com
Precedence: bulk
X-list: netdev
Content-Length: 128
Lines: 10


FYI to all (particularly Robert O and Hirofumi-san),

8139too and tulip NAPI support is now in upstream 2.6.x tree.

	Jeff





From shmulik.hen@intel.com Thu Feb  5 13:14:38 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 13:14:46 -0800 (PST)
Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15LEbKO032052
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 13:14:37 -0800
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129])
	by petasus.ch.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i15DxBmM017640;
	Thu, 5 Feb 2004 13:59:30 GMT
Received: from jrslxjul4.npdj.intel.com ([10.12.220.54])
 by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020505592810807
 ; Thu, 05 Feb 2004 05:59:29 -0800
From: Shmuel Hen <shmulik.hen@intel.com>
Organization: Intel Corporation
To: "David S. Miller" <davem@redhat.com>
Subject: [PATCH] [8021q] Export VLAN tag get/set functionality (resend)
Date: Thu, 5 Feb 2004 15:59:22 +0200
User-Agent: KMail/1.5.3
Cc: <netdev@oss.sgi.com>, "Jeff Garzik" <jgarzik@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200402051559.27597.shmulik.hen@intel.com>
X-archive-position: 3030
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: shmulik.hen@intel.com
Precedence: bulk
X-list: netdev
Content-Length: 4495
Lines: 170

Enable intermediate network drivers like bonding to get or set a 
VLAN tag in an skb without a need to know about how tagging is done 
according to a network adapter's capabilities. 

Tested for patch application and compilation against linux-2.6.2.

-- 
| Shmulik Hen   Advanced Network Services  |
| Israel Design Center, Jerusalem          |
| LAN Access Division, Platform Networking |
| Intel Communications Group, Intel corp.  |


diff -Nuarp a/include/linux/if_vlan.h b/include/linux/if_vlan.h
--- a/include/linux/if_vlan.h	Wed Jan 21 16:56:09 2004
+++ b/include/linux/if_vlan.h	Wed Jan 21 16:56:11 2004
@@ -200,6 +200,152 @@ static inline int vlan_hwaccel_receive_s
 {
 	return __vlan_hwaccel_rx(skb, grp, vlan_tag, 1);
 }
+
+/**
+ * __vlan_put_tag - regular VLAN tag inserting
+ * @skb: skbuff to tag
+ * @tag: VLAN tag to insert
+ *
+ * Inserts the VLAN tag into @skb as part of the payload
+ * Returns a VLAN tagged skb. If a new skb is created, @skb is freed.
+ * 
+ * Following the skb_unshare() example, in case of error, the calling function
+ * doesn't have to worry about freeing the original skb.
+ */
+static inline struct sk_buff *__vlan_put_tag(struct sk_buff *skb, unsigned short tag)
+{
+	struct vlan_ethhdr *veth;
+
+	if (skb_headroom(skb) < VLAN_HLEN) {
+		struct sk_buff *sk_tmp = skb;
+		skb = skb_realloc_headroom(sk_tmp, VLAN_HLEN);
+		kfree_skb(sk_tmp);
+		if (!skb) {
+			printk(KERN_ERR "vlan: failed to realloc headroom\n");
+			return NULL;
+		}
+	} else {
+		skb = skb_unshare(skb, GFP_ATOMIC);
+		if (!skb) {
+			printk(KERN_ERR "vlan: failed to unshare skbuff\n");
+			return NULL;
+		}
+	}
+
+	veth = (struct vlan_ethhdr *)skb_push(skb, VLAN_HLEN);
+
+	/* Move the mac addresses to the beginning of the new header. */
+	memmove(skb->data, skb->data + VLAN_HLEN, 2 * VLAN_ETH_ALEN);
+
+	/* first, the ethernet type */
+	veth->h_vlan_proto = __constant_htons(ETH_P_8021Q);
+
+	/* now, the tag */
+	veth->h_vlan_TCI = htons(tag);
+
+	skb->protocol = __constant_htons(ETH_P_8021Q);
+	skb->mac.raw -= VLAN_HLEN;
+	skb->nh.raw -= VLAN_HLEN;
+
+	return skb;
+}
+
+/**
+ * __vlan_hwaccel_put_tag - hardware accelerated VLAN inserting
+ * @skb: skbuff to tag
+ * @tag: VLAN tag to insert
+ *
+ * Puts the VLAN tag in @skb->cb[] and lets the device do the rest
+ */
+static inline struct sk_buff *__vlan_hwaccel_put_tag(struct sk_buff *skb, unsigned short tag)
+{
+	struct vlan_skb_tx_cookie *cookie;
+
+	cookie = VLAN_TX_SKB_CB(skb);
+	cookie->magic = VLAN_TX_COOKIE_MAGIC;
+	cookie->vlan_tag = tag;
+
+	return skb;
+}
+
+#define HAVE_VLAN_PUT_TAG
+
+/**
+ * vlan_put_tag - inserts VLAN tag according to device features
+ * @skb: skbuff to tag
+ * @tag: VLAN tag to insert
+ *
+ * Assumes skb->dev is the target that will xmit this frame.
+ * Returns a VLAN tagged skb.
+ */
+static inline struct sk_buff *vlan_put_tag(struct sk_buff *skb, unsigned short tag)
+{
+	if (skb->dev->features & NETIF_F_HW_VLAN_TX) {
+		return __vlan_hwaccel_put_tag(skb, tag);
+	} else {
+		return __vlan_put_tag(skb, tag);
+	}
+}
+
+/**
+ * __vlan_get_tag - get the VLAN ID that is part of the payload
+ * @skb: skbuff to query
+ * @tag: buffer to store vlaue
+ * 
+ * Returns error if the skb is not of VLAN type
+ */
+static inline int __vlan_get_tag(struct sk_buff *skb, unsigned short *tag)
+{
+	struct vlan_ethhdr *veth = (struct vlan_ethhdr *)skb->data;
+
+	if (veth->h_vlan_proto != __constant_htons(ETH_P_8021Q)) {
+		return -EINVAL;
+	}
+
+	*tag = ntohs(veth->h_vlan_TCI);
+
+	return 0;
+}
+
+/**
+ * __vlan_hwaccel_get_tag - get the VLAN ID that is in @skb->cb[]
+ * @skb: skbuff to query
+ * @tag: buffer to store vlaue
+ * 
+ * Returns error if @skb->cb[] is not set correctly
+ */
+static inline int __vlan_hwaccel_get_tag(struct sk_buff *skb, unsigned short *tag)
+{
+	struct vlan_skb_tx_cookie *cookie;
+
+	cookie = VLAN_TX_SKB_CB(skb);
+	if (cookie->magic == VLAN_TX_COOKIE_MAGIC) {
+		*tag = cookie->vlan_tag;
+		return 0;
+	} else {
+		*tag = 0;
+		return -EINVAL;
+	}
+}
+
+#define HAVE_VLAN_GET_TAG
+
+/**
+ * vlan_get_tag - get the VLAN ID from the skb
+ * @skb: skbuff to query
+ * @tag: buffer to store vlaue
+ * 
+ * Returns error if the skb is not VLAN tagged
+ */
+static inline int vlan_get_tag(struct sk_buff *skb, unsigned short *tag)
+{
+	if (skb->dev->features & NETIF_F_HW_VLAN_TX) {
+		return __vlan_hwaccel_get_tag(skb, tag);
+	} else {
+		return __vlan_get_tag(skb, tag);
+	}
+}
+
 #endif /* __KERNEL__ */
 
 /* VLAN IOCTLs are found in sockios.h */


From leonid.grossman@s2io.com Thu Feb  5 14:10:15 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 14:10:18 -0800 (PST)
Received: from ns1.s2io.com (ns1.s2io.com [216.209.86.101])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15MAEKO001271
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 14:10:14 -0800
Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98])
	by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i15MA4jF019238;
	Thu, 5 Feb 2004 17:10:04 -0500 (EST)
Received: from lgt40 ([10.16.16.115])
	by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i15M9uKK021740;
	Thu, 5 Feb 2004 17:09:57 -0500 (EST)
From: "Leonid Grossman" <leonid.grossman@s2io.com>
To: "'Jeff Garzik'" <jgarzik@pobox.com>
Cc: "'Anton Blanchard'" <anton@samba.org>, "'Andi Kleen'" <ak@suse.de>,
        <netdev@oss.sgi.com>, <raghava.vatsavayi@s2io.com>, <iod00d@hp.com>
Subject: RE: FW: Submission for S2io 10GbE driver
Date: Thu, 5 Feb 2004 14:09:09 -0800
Message-ID: <000001c3ec34$af53b8e0$5d50ff11@S2IOtech.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <40220D15.60603@pobox.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Score: -101
X-Spam-Outlook-Score: ()
X-Spam-Features: IN_REP_TO,QUOTED_EMAIL_TEXT,USER_IN_WHITELIST
X-Scanned-By: MIMEDefang 2.34
X-archive-position: 3031
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: leonid.grossman@s2io.com
Precedence: bulk
X-list: netdev
Content-Length: 1779
Lines: 44


> {read,write}[bwlq] should work the same regardless of whether its big 
> endian or little endian.  The rule is "PCI is defined to be little 
> endian".  On little endian platforms, no byte swapping 
> occurs.  On big endian platforms, the platform will byteswap.  Thus,
the 
> driver should  not have big-endian-specific or PPC64-specific code...
> (you still have to do your own byteswapping for DMA)
> 	Jeff

Hi Jeff, 

It looks like for the swapper issue we can get rid of PPC64-specific
code, but not necessarily of big-endian-specific code.
The behavior you describe is generic for Linux but not for the platform
- on the same box, another OS will not byteswap, for example on the same
pSeries box AIX will not byteswap while Linux will.

So, our ASIC is designed in a way that for a big endian machine the
swapper control need not be touched, and for little endian box both
register and DMA accesses have to be configured to swap - it would be
nice to have the same configuration working on all systems, but this did
not seem possible.

So, for Linux we configure the ASIC to byteswap register access for both
big and little endian boxes.
For DMA (as you pointed out) we need to configure the ASIC to do our own
byteswap, so this init code (or rather just a config parameter) will be
different on big and little endian machine.
Another small difference will be that the ASIC has actually slightly
different statistic counters for  big and little endian.
We can move these (very few) big/little definition into a header file so
the source itself is clean, but I don't see a way to completely get rid
of these... 

Also, looks like we can get rid of all PPC64-specific stuff.
Thanks to everybody who pointed toward a solution (and/or promised to
fix PPC :-)).

Leonid





From Robert.Olsson@data.slu.se Thu Feb  5 14:31:13 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 14:31:16 -0800 (PST)
Received: from mail1.slu.se (mail1.slu.se [130.238.96.11])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15MVBKO002547
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 14:31:12 -0800
Received: from robur.slu.se (robur.slu.se [130.238.98.12])
	by mail1.slu.se (8.12