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 / $B5HF#1QL@(B <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 / $B5HF#1QL@(B <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 / $B5HF#1QL@(B <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 / $B5HF#1QL@(B <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] $B5HF#1QL@(B"
    <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] $B5HF#1QL@(B 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 / $B5HF#1QL@(B <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 / $B5HF#1QL@(B <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 / $B5HF#1QL@(B <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.10/8.12.10) with ESMTP id i15MVALq022687;
	Thu, 5 Feb 2004 23:31:10 +0100
Received: by robur.slu.se (Postfix, from userid 1000)
	id B8919EC061; Thu,  5 Feb 2004 23:31:10 +0100 (CET)
From: Robert Olsson <Robert.Olsson@data.slu.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16418.50222.708197.388268@robur.slu.se>
Date: Thu, 5 Feb 2004 23:31:10 +0100
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Netdev <netdev@oss.sgi.com>
Subject: New NAPI work applied...
In-Reply-To: <4022A2F5.7050107@pobox.com>
References: <4022A2F5.7050107@pobox.com>
X-Mailer: VM 7.17 under Emacs 21.3.1
X-archive-position: 3032
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: Robert.Olsson@data.slu.se
Precedence: bulk
X-list: netdev
Content-Length: 1061
Lines: 35


Jeff Garzik writes:
 > 
 > FYI to all (particularly Robert O and Hirofumi-san),
 > 
 > 8139too and tulip NAPI support is now in upstream 2.6.x tree.
 > 
 
Thanks Jeff!

The original tulip patch was done by Alexey and came w. the NAPI kernel patch.
And the interrupt mitigation part was stolen and simplified from Jamal. :-)


BTW. I'm hacking with a userland app to get interface stats. It's fork of a
Alexey program too. ifstat. In my take it's ifstat2 and looks like:

 
ifstat2 eth*
             RX --------------------------   TX -------------------------
eth0          704.9 M bit/s       59 k pps      3.2 M bit/s        5 k pps 
eth1             16   bit/s        0   pps    215.8 k bit/s      431   pps 
eth2          220.8 k bit/s      441   pps        0   bit/s        0   pps 
eth3              0   bit/s        0   pps    219.5 k bit/s      438   pps

It's fits between ip -s link and ethtool -S 

ftp://robur.slu.se/pub/Linux/net-development/ifstat2/

A diet linked version for ix86:
http://robur.slu.se/diet/bin-i386/ifstat2


Cheers.
						--ro

From grundler@cup.hp.com Thu Feb  5 14:32:46 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 14:32:51 -0800 (PST)
Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15MWeKO002863
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 14:32:46 -0800
Received: from hpuxmail.cup.hp.com (hpuxmail.cup.hp.com [15.13.189.207])
	by palrel11.hp.com (Postfix) with ESMTP
	id AAF611C02214; Thu,  5 Feb 2004 14:32:39 -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 i15MWZo10158;
	Thu, 5 Feb 2004 14:32:35 -0800 (PST)
Received: by debian.cup.hp.com (Postfix, from userid 1001)
	id 0E15A2F807; Thu,  5 Feb 2004 14:34:14 -0800 (PST)
Date: Thu, 5 Feb 2004 14:34:13 -0800
From: Grant Grundler <iod00d@hp.com>
To: Leonid Grossman <leonid.grossman@s2io.com>
Cc: "'Jeff Garzik'" <jgarzik@pobox.com>, "'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
Message-ID: <20040205223413.GB2508@cup.hp.com>
References: <40220D15.60603@pobox.com> <000001c3ec34$af53b8e0$5d50ff11@S2IOtech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000001c3ec34$af53b8e0$5d50ff11@S2IOtech.com>
User-Agent: Mutt/1.5.5.1+cvs20040105i
X-archive-position: 3033
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
Content-Length: 1384
Lines: 34

On Thu, Feb 05, 2004 at 02:09:09PM -0800, Leonid Grossman wrote:
> It looks like for the swapper issue we can get rid of PPC64-specific
> code, but not necessarily of big-endian-specific code.

right

> 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.

While I understand the desire to share the same driver across OSs,
providing "glue" code like sym53c8xx_2 drivers does can be very ugly.
You might look at that driver a bit and try to compare 2.4 vs 2.6.

> 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.

It's probably not. It sounds like the Tigon2 driver (acenic) which has
similar HW support. You see how endianess is handled there.

...
> 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... 

that's ok I think.

cheers,
grant

From jes@trained-monkey.org Thu Feb  5 15:25:37 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 15:25:40 -0800 (PST)
Received: from jaguar.mkp.net (jaguar.mkp.net [192.139.46.146])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15NPaKO005675
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 15:25:37 -0800
Received: from jes by jaguar.mkp.net with local (Exim 3.35 #1)
	id 1Aosqd-0004NV-00; Thu, 05 Feb 2004 18:23:51 -0500
To: Grant Grundler <iod00d@hp.com>
Cc: Leonid Grossman <leonid.grossman@s2io.com>,
        "'Jeff Garzik'" <jgarzik@pobox.com>,
        "'Anton Blanchard'" <anton@samba.org>, "'Andi Kleen'" <ak@suse.de>,
        netdev@oss.sgi.com, raghava.vatsavayi@s2io.com
Subject: Re: FW: Submission for S2io 10GbE driver
References: <40220D15.60603@pobox.com>
	<000001c3ec34$af53b8e0$5d50ff11@S2IOtech.com>
	<20040205223413.GB2508@cup.hp.com>
From: Jes Sorensen <jes@wildopensource.com>
Date: 05 Feb 2004 18:23:50 -0500
In-Reply-To: <20040205223413.GB2508@cup.hp.com>
Message-ID: <yq03c9pkt4p.fsf@wildopensource.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-archive-position: 3034
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: jes@wildopensource.com
Precedence: bulk
X-list: netdev
Content-Length: 839
Lines: 24

>>>>> "Grant" == Grant Grundler <iod00d@hp.com> writes:

Grant> On Thu, Feb 05, 2004 at 02:09:09PM -0800, Leonid Grossman
Grant> wrote:
>> 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.

Grant> It's probably not. It sounds like the Tigon2 driver (acenic)
Grant> which has similar HW support. You see how endianess is handled
Grant> there.

Grant,

I have a feeling Leonid is fairly familiar with the acenic design ;-)

But yes it's very similar, I made the same mistake originally in the
acenic driver trying to set different swap modes for little vs big
endian.

Cheers,
Jes

From ak@suse.de Thu Feb  5 20:00:51 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 20:00:55 -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 i1640oKO017880
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 20:00:51 -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 7D6FB151769; Fri,  6 Feb 2004 05:00:44 +0100 (CET)
Date: Fri, 6 Feb 2004 05:00:42 +0100
From: Andi Kleen <ak@suse.de>
To: marcel@holtmann.org, bluez-devel@lists.sourceforge.net, netdev@oss.sgi.com,
        viro@zenII.linux.org.uk
Subject: some bluetooth fixes
Message-Id: <20040206050042.20a2b3b0.ak@suse.de>
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: 3035
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: 5620
Lines: 208


While reading bluetooth code I noticed some bugs and potential overflows.

Also I commented one ref-counting bug.

Patch against 2.6.2.

-Andi

diff -u linux-2.6.2-work32/net/bluetooth/rfcomm/tty.c-o linux-2.6.2-work32/net/bluetooth/rfcomm/tty.c
--- linux-2.6.2-work32/net/bluetooth/rfcomm/tty.c-o	2003-09-28 10:53:25.000000000 +0200
+++ linux-2.6.2-work32/net/bluetooth/rfcomm/tty.c	2004-02-06 04:58:28.000000000 +0100
@@ -349,7 +349,7 @@
 	struct rfcomm_dev_list_req *dl;
 	struct rfcomm_dev_info *di;
 	struct list_head *p;
-	int n = 0, size;
+	int n = 0, size, err;
 	u16 dev_num;
 
 	BT_DBG("");
@@ -362,8 +362,8 @@
 
 	size = sizeof(*dl) + dev_num * sizeof(*di);
 
-	if (verify_area(VERIFY_WRITE, (void *)arg, size))
-		return -EFAULT;
+	if (size > (4*PAGE_SIZE)/sizeof(*di))
+		return -EINVAL;
 
 	if (!(dl = kmalloc(size, GFP_KERNEL)))
 		return -ENOMEM;
@@ -389,9 +389,9 @@
 	dl->dev_num = n;
 	size = sizeof(*dl) + n * sizeof(*di);
 
-	copy_to_user((void *) arg, dl, size);
+	err = copy_to_user((void *) arg, dl, size) ? -EFAULT : 0;
 	kfree(dl);
-	return 0;
+	return err;
 }
 
 static int rfcomm_get_dev_info(unsigned long arg)
@@ -549,8 +549,10 @@
 
 	BT_DBG("dev %p dst %s channel %d opened %d", dev, batostr(&dev->dst), dev->channel, dev->opened);
 
-	if (dev->opened++ != 0)
+	if (dev->opened++ != 0) {
+		rfcomm_dev_put(dev);
 		return 0;
+	}
 
 	dlc = dev->dlc;
 
@@ -563,8 +565,10 @@
 	set_bit(RFCOMM_TTY_ATTACHED, &dev->flags);
 
 	err = rfcomm_dlc_open(dlc, &dev->src, &dev->dst, dev->channel);
-	if (err < 0)
+	if (err < 0) { 
+		rfcomm_dev_put(dev);
 		return err;
+	}
 
 	/* Wait for DLC to connect */
 	add_wait_queue(&dev->wait, &wait);
diff -u linux-2.6.2-work32/net/bluetooth/cmtp/sock.c-o linux-2.6.2-work32/net/bluetooth/cmtp/sock.c
--- linux-2.6.2-work32/net/bluetooth/cmtp/sock.c-o	2004-02-05 08:09:54.000000000 +0100
+++ linux-2.6.2-work32/net/bluetooth/cmtp/sock.c	2004-02-05 14:57:57.000000000 +0100
@@ -87,8 +87,10 @@
 		if (!nsock)
 			return err;
 
-		if (nsock->sk->sk_state != BT_CONNECTED)
+		if (nsock->sk->sk_state != BT_CONNECTED) { 
+			fput(nsock->file);
 			return -EBADFD;
+		}
 
 		err = cmtp_add_connection(&ca, nsock);
 		if (!err) {
diff -u linux-2.6.2-work32/net/bluetooth/hci_sock.c-o linux-2.6.2-work32/net/bluetooth/hci_sock.c
--- linux-2.6.2-work32/net/bluetooth/hci_sock.c-o	2004-02-05 08:09:54.000000000 +0100
+++ linux-2.6.2-work32/net/bluetooth/hci_sock.c	2004-02-05 14:57:59.000000000 +0100
@@ -392,6 +392,8 @@
 
 	skb->pkt_type = *((unsigned char *) skb->data);
 	skb_pull(skb, 1);
+	/* AK: looks broken. Who guarantees that hdev doesn't go away while
+	   the skb is queued ? */
 	skb->dev = (void *) hdev;
 
 	if (skb->pkt_type == HCI_COMMAND_PKT) {
diff -u linux-2.6.2-work32/net/bluetooth/hci_conn.c-o linux-2.6.2-work32/net/bluetooth/hci_conn.c
--- linux-2.6.2-work32/net/bluetooth/hci_conn.c-o	2004-02-05 08:09:54.000000000 +0100
+++ linux-2.6.2-work32/net/bluetooth/hci_conn.c	2004-02-05 15:06:10.000000000 +0100
@@ -353,21 +353,24 @@
 	struct hci_conn_info *ci;
 	struct hci_dev *hdev;
 	struct list_head *p;
-	int n = 0, size;
+	int n = 0, size, err;
 
 	if (copy_from_user(&req, (void *) arg, sizeof(req)))
 		return -EFAULT;
 
-	if (!(hdev = hci_dev_get(req.dev_id)))
-		return -ENODEV;
+	if (req.conn_num >= (2*PAGE_SIZE)/sizeof(struct hci_conn_info))
+		return -EINVAL; 
 
 	size = req.conn_num * sizeof(struct hci_conn_info) + sizeof(req);
 
-	if (verify_area(VERIFY_WRITE, (void *)arg, size))
-		return -EFAULT;
-
 	if (!(cl = (void *) kmalloc(size, GFP_KERNEL)))
 		return -ENOMEM;
+
+	if (!(hdev = hci_dev_get(req.dev_id))) { 
+		kfree(cl);
+		return -ENODEV;
+	}
+
 	ci = cl->conn_info;
 
 	hci_dev_lock_bh(hdev);
@@ -375,6 +378,9 @@
 		register struct hci_conn *c;
 		c = list_entry(p, struct hci_conn, list);
 
+		if (n >= req.conn_num) 
+			break;
+
 		bacpy(&(ci + n)->bdaddr, &c->dst);
 		(ci + n)->handle = c->handle;
 		(ci + n)->type  = c->type;
@@ -391,10 +397,10 @@
 
 	hci_dev_put(hdev);
 
-	copy_to_user((void *) arg, cl, size);
+	err = copy_to_user((void *) arg, cl, size) ? -EFAULT : 0; 
 	kfree(cl);
 
-	return 0;
+	return err;
 }
 
 int hci_get_conn_info(struct hci_dev *hdev, unsigned long arg)
@@ -407,9 +413,6 @@
 	if (copy_from_user(&req, (void *) arg, sizeof(req)))
 		return -EFAULT;
 
-	if (verify_area(VERIFY_WRITE, ptr, sizeof(ci)))
-		return -EFAULT;
-
 	hci_dev_lock_bh(hdev);
 	conn = hci_conn_hash_lookup_ba(hdev, req.type, &req.bdaddr);
 	if (conn) {
@@ -425,6 +428,5 @@
 	if (!conn)
 		return -ENOENT;
 
-	copy_to_user(ptr, &ci, sizeof(ci));
-	return 0;
+	return copy_to_user(ptr, &ci, sizeof(ci)) ? -EFAULT : 0;
 }
diff -u linux-2.6.2-work32/net/bluetooth/hci_core.c-o linux-2.6.2-work32/net/bluetooth/hci_core.c
--- linux-2.6.2-work32/net/bluetooth/hci_core.c-o	2004-02-05 08:09:54.000000000 +0100
+++ linux-2.6.2-work32/net/bluetooth/hci_core.c	2004-02-05 15:01:46.000000000 +0100
@@ -715,18 +715,16 @@
 	struct list_head *p;
 	int n = 0, size;
 	__u16 dev_num;
-
+	int err;
+	
 	if (get_user(dev_num, (__u16 *) arg))
 		return -EFAULT;
 
-	if (!dev_num)
+	if (!dev_num || dev_num >= (4*PAGE_SIZE)/sizeof(*dr))
 		return -EINVAL;
 	
 	size = dev_num * sizeof(*dr) + sizeof(*dl);
 
-	if (verify_area(VERIFY_WRITE, (void *) arg, size))
-		return -EFAULT;
-
 	if (!(dl = kmalloc(size, GFP_KERNEL)))
 		return -ENOMEM;
 	dr = dl->dev_req;
@@ -745,10 +743,10 @@
 	dl->dev_num = n;
 	size = n * sizeof(*dr) + sizeof(*dl);
 
-	copy_to_user((void *) arg, dl, size);
+	err = copy_to_user((void *) arg, dl, size);
 	kfree(dl);
 
-	return 0;
+	return err ? -EFAULT : 0;
 }
 
 int hci_get_dev_info(unsigned long arg)

From akpm@osdl.org Thu Feb  5 21:32:39 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 21:32:42 -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 i165WaKO022798
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 21:32:39 -0800
Received: from mnm (build.pdx.osdl.net [172.20.1.2])
	by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i165WON00763;
	Thu, 5 Feb 2004 21:32:25 -0800
Date: Thu, 5 Feb 2004 21:34:22 -0800
From: Andrew Morton <akpm@osdl.org>
To: "David S. Miller" <davem@redhat.com>
Cc: netdev@oss.sgi.com
Subject: more gcc-2.5 patches
Message-Id: <20040205213422.4fefcd27.akpm@osdl.org>
X-Mailer: Sylpheed version 0.9.4 (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: 3036
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
Content-Length: 36
Lines: 2


I managed to miss a few last time.

From akpm@osdl.org Thu Feb  5 21:36:13 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 21:36:17 -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 i165aCKO023189
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 21:36:13 -0800
Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2])
	by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i165a0N01679;
	Thu, 5 Feb 2004 21:36:00 -0800
Date: Thu, 5 Feb 2004 21:36:00 -0800
Message-Id: <200402060536.i165a0N01679@mail.osdl.org>
Subject: [patch 2/3] gcc-3.5: af_packet
To: davem@redhat.com
Cc: netdev@oss.sgi.com
From: akpm@osdl.org
X-archive-position: 3038
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
Content-Length: 644
Lines: 25



Fix illegal lvalue with gcc-3.5



---

 net/packet/af_packet.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN net/packet/af_packet.c~gcc-35-packet net/packet/af_packet.c
--- 25/net/packet/af_packet.c~gcc-35-packet	2004-01-25 13:18:18.000000000 -0800
+++ 25-akpm/net/packet/af_packet.c	2004-01-25 13:18:40.000000000 -0800
@@ -961,7 +961,7 @@ static int packet_create(struct socket *
 	sock_init_data(sock,sk);
 	sk_set_owner(sk, THIS_MODULE);
 
-	po = pkt_sk(sk) = kmalloc(sizeof(*po), GFP_KERNEL);
+	po = sk->sk_protinfo = kmalloc(sizeof(*po), GFP_KERNEL);
 	if (!po)
 		goto out_free;
 	memset(po, 0, sizeof(*po));

_

From akpm@osdl.org Thu Feb  5 21:36:06 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 21:36:13 -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 i165a6KO023183
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 21:36:06 -0800
Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2])
	by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i165ZsN01650;
	Thu, 5 Feb 2004 21:35:54 -0800
Date: Thu, 5 Feb 2004 21:35:54 -0800
Message-Id: <200402060535.i165ZsN01650@mail.osdl.org>
Subject: [patch 1/3] gcc-3.5: netlink
To: davem@redhat.com
Cc: netdev@oss.sgi.com
From: akpm@osdl.org
X-archive-position: 3037
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
Content-Length: 650
Lines: 25



Fix illegal lvalue with gcc-3.5



---

 net/netlink/af_netlink.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN net/netlink/af_netlink.c~gcc-35-netlink net/netlink/af_netlink.c
--- 25/net/netlink/af_netlink.c~gcc-35-netlink	2004-01-25 13:16:12.000000000 -0800
+++ 25-akpm/net/netlink/af_netlink.c	2004-01-25 13:18:09.000000000 -0800
@@ -230,7 +230,7 @@ static int netlink_create(struct socket 
 	sock_init_data(sock,sk);
 	sk_set_owner(sk, THIS_MODULE);
 
-	nlk = nlk_sk(sk) = kmalloc(sizeof(*nlk), GFP_KERNEL);
+	nlk = sk->sk_protinfo = kmalloc(sizeof(*nlk), GFP_KERNEL);
 	if (!nlk) {
 		sk_free(sk);
 		return -ENOMEM;

_

From akpm@osdl.org Thu Feb  5 21:36:20 2004
Received: with ECARTIS (v1.0.0; list netdev); Thu, 05 Feb 2004 21:36:24 -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 i165aJKO023208
	for <netdev@oss.sgi.com>; Thu, 5 Feb 2004 21:36:20 -0800
Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2])
	by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i165a6N01687;
	Thu, 5 Feb 2004 21:36:06 -0800
Date: Thu, 5 Feb 2004 21:36:06 -0800
Message-Id: <200402060536.i165a6N01687@mail.osdl.org>
Subject: [patch 3/3] gcc-3.5: pppoe
To: davem@redhat.com
Cc: netdev@oss.sgi.com
From: akpm@osdl.org
X-archive-position: 3039
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
Content-Length: 737
Lines: 25



drivers/net/pppoe.c: In function `pppoe_create':
drivers/net/pppoe.c:519: error: invalid lvalue in assignment                    


---

 drivers/net/pppoe.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN drivers/net/pppoe.c~gcc-35-pppoe drivers/net/pppoe.c
--- 25/drivers/net/pppoe.c~gcc-35-pppoe	2004-01-28 23:12:52.000000000 -0800
+++ 25-akpm/drivers/net/pppoe.c	2004-01-28 23:12:52.000000000 -0800
@@ -516,7 +516,7 @@ static int pppoe_create(struct socket *s
 	sk->sk_protocol	   = PX_PROTO_OE;
 	sk->sk_destruct	   = pppoe_sk_free;
 
-	po = pppox_sk(sk) = kmalloc(sizeof(*po), GFP_KERNEL);
+	po = sk->sk_protinfo = kmalloc(sizeof(*po), GFP_KERNEL);
 	if (!po)
 		goto frees;
 	memset(po, 0, sizeof(*po));

_

From yoshfuji@linux-ipv6.org Fri Feb  6 01:09:16 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 01:09:27 -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 i1699FKO007673
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 01:09:15 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 1274033CA5; Fri,  6 Feb 2004 18:10:07 +0900 (JST)
Date: Fri, 06 Feb 2004 18:10:06 +0900 (JST)
Message-Id: <20040206.181006.79694138.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com
Subject: [PATCH 2/3] IPV6: unify 3 similar code path in ndisc_recv_ns()
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: 3041
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: 5671
Lines: 220

Hello.

[PATCH 2/3] IPV6: unify 3 similar code path in ndisc_recv_ns()

D: Unify 3 similar code path in ndisc_recv_ns().
D: This patch also fixes:
D:  - flags sent with NA in reply to this NS
D:  - missing random delay after receipt of NS against anycast

Thanks.

--- linux26-dad/net/ipv6/ndisc.c	Fri Feb  6 15:12:33 2004
+++ linux26-recv_ns/net/ipv6/ndisc.c	Fri Feb  6 16:38:16 2004
@@ -707,8 +707,10 @@ static void ndisc_recv_ns(struct sk_buff
 	struct ndisc_options ndopts;
 	struct net_device *dev = skb->dev;
 	struct inet6_ifaddr *ifp;
+	struct inet6_dev *idev = NULL;
 	struct neighbour *neigh;
 	int addr_type = ipv6_addr_type(saddr);
+	int inc;
 
 	if (ipv6_addr_is_multicast(&msg->target)) {
 		if (net_ratelimit())
@@ -757,6 +759,8 @@ static void ndisc_recv_ns(struct sk_buff
 		}
 	}
 
+	inc = ipv6_addr_is_multicast(daddr);
+
 	if ((ifp = ipv6_get_ifaddr(&msg->target, dev, 1)) != NULL) {
 		if (ifp->flags & IFA_F_TENTATIVE) {
 			/* Address is tentative. If the source
@@ -784,127 +788,72 @@ static void ndisc_recv_ns(struct sk_buff
 			addrconf_dad_failure(ifp); 
 			return;
 		}
-	
-		if (addr_type == IPV6_ADDR_ANY) {
-			struct in6_addr maddr;
 
-			ipv6_addr_all_nodes(&maddr);
-			ndisc_send_na(dev, NULL, &maddr, &ifp->addr, 
-				      ifp->idev->cnf.forwarding, 0, 
-				      1, 1);
-			in6_ifa_put(ifp);
+		idev = ifp->idev;
+	} else {
+		idev = in6_dev_get(dev);
+		if (!idev) {
+			/* XXX: count this drop? */
 			return;
 		}
 
-		if (addr_type & IPV6_ADDR_UNICAST) {
-			if (ipv6_addr_is_multicast(daddr))
-				nd_tbl.stats.rcv_probes_mcast++;
-			else
-				nd_tbl.stats.rcv_probes_ucast++;
-
-			/* 
-			 *	update / create cache entry
-			 *	for the source address
-			 */
+		if (ipv6_chk_acast_addr(dev, &msg->target) ||
+		    (idev->cnf.forwarding && 
+		     pneigh_lookup(&nd_tbl, &msg->target, dev, 0))) {
+			if (skb->stamp.tv_sec != 0 &&
+			    skb->pkt_type != PACKET_HOST &&
+			    inc != 0 &&
+			    idev->nd_parms->proxy_delay != 0) {
+				/*
+				 * for anycast or proxy,
+				 * sender should delay its response 
+				 * by a random time between 0 and 
+				 * MAX_ANYCAST_DELAY_TIME seconds.
+				 * (RFC2461) -- yoshfuji
+				 */
+				struct sk_buff *n = skb_clone(skb, GFP_ATOMIC);
+				if (n)
+					pneigh_enqueue(&nd_tbl, idev->nd_parms, n);
+				goto out;
+			}
+		} else
+			goto out;
+	}
 
-			neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, dev);
+	if (addr_type == IPV6_ADDR_ANY) {
+		struct in6_addr maddr;
 
-			if (neigh || !dev->hard_header) {
-				ndisc_send_na(dev, neigh, saddr, &ifp->addr, 
-					      ifp->idev->cnf.forwarding, 1, 
-					      1, 1);
-				if (neigh)
-					neigh_release(neigh);
-			}
-		}
-		in6_ifa_put(ifp);
-	} else if (ipv6_chk_acast_addr(dev, &msg->target)) {
-		struct inet6_dev *idev = in6_dev_get(dev);
-	
-		/* anycast */
-	
-		if (!idev) {
-			/* XXX: count this drop? */
-			return;
-		}
-	
-		if (addr_type == IPV6_ADDR_ANY) {
-			struct in6_addr maddr;
-	
-			ipv6_addr_all_nodes(&maddr);
-			ndisc_send_na(dev, NULL, &maddr, &msg->target,
-				      idev->cnf.forwarding, 0, 0, 1);
-			in6_dev_put(idev);
-			return;
-		}
+		ipv6_addr_all_nodes(&maddr);
+		ndisc_send_na(dev, NULL, &maddr, &msg->target,
+			      idev->cnf.forwarding, 0, (ifp != NULL), 1);
+		goto out;
+	}
 
-		if (addr_type & IPV6_ADDR_UNICAST) {
-			int inc = ipv6_addr_is_multicast(daddr);
-			if (inc)  
-				nd_tbl.stats.rcv_probes_mcast++;
-			else
-				nd_tbl.stats.rcv_probes_ucast++;
-	
-			/*
-			 *   update / create cache entry
-			 *   for the source address
-			 */
+	if (inc)
+		nd_tbl.stats.rcv_probes_mcast++;
+	else
+		nd_tbl.stats.rcv_probes_ucast++;
+
+	/* 
+	 *	update / create cache entry
+	 *	for the source address
+	 */
+	neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, dev);
 
-			neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, skb->dev);
+	if (neigh || !dev->hard_header) {
+		ndisc_send_na(dev, neigh, saddr, &msg->target,
+			      idev->cnf.forwarding, 
+			      1, (ifp != NULL && inc), inc);
+		if (neigh)
+			neigh_release(neigh);
+	}
 
-			if (neigh || !dev->hard_header) {
-				ndisc_send_na(dev, neigh, saddr,
-					      &msg->target, 
-					      idev->cnf.forwarding, 1, 0, inc);
-				if (neigh)
-					neigh_release(neigh);
-			}
-		}
+out:
+	if (ifp)
+		in6_ifa_put(ifp);
+	else
 		in6_dev_put(idev);
-	} else {
-		struct inet6_dev *in6_dev = in6_dev_get(dev);
 
-		if (in6_dev && in6_dev->cnf.forwarding &&
-		    (addr_type & IPV6_ADDR_UNICAST ||
-		     addr_type == IPV6_ADDR_ANY) &&
-		    pneigh_lookup(&nd_tbl, &msg->target, dev, 0)) {
-			int inc = ipv6_addr_is_multicast(daddr);
-
-			if (skb->stamp.tv_sec == 0 ||
-			    skb->pkt_type == PACKET_HOST ||
-			    inc == 0 ||
-			    in6_dev->nd_parms->proxy_delay == 0) {
-				if (inc)
-					nd_tbl.stats.rcv_probes_mcast++;
-				else
-					nd_tbl.stats.rcv_probes_ucast++;
-					
-				if (addr_type & IPV6_ADDR_UNICAST) {
-					neigh = neigh_event_ns(&nd_tbl, lladdr, saddr, dev);
-
-					if (neigh) {
-						ndisc_send_na(dev, neigh, saddr, &msg->target,
-							      0, 1, 0, 1);
-						neigh_release(neigh);
-					}
-				} else {
-					/* proxy should also protect against DAD */
-					struct in6_addr maddr;
-					ipv6_addr_all_nodes(&maddr);
-					ndisc_send_na(dev, NULL, &maddr, &msg->target, 
-						      0, 0, 0, 1);
-				}
-			} else {
-				struct sk_buff *n = skb_clone(skb, GFP_ATOMIC);
-				if (n)
-					pneigh_enqueue(&nd_tbl, in6_dev->nd_parms, n);
-				in6_dev_put(in6_dev);
-				return;
-			}
-		}
-		if (in6_dev)
-			in6_dev_put(in6_dev);
-	}
 	return;
 }
 

-- 
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 Fri Feb  6 01:09:14 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 01:09:27 -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 i1699CKO007665
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 01:09:13 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 0106833CA5; Fri,  6 Feb 2004 18:10:03 +0900 (JST)
Date: Fri, 06 Feb 2004 18:10:03 +0900 (JST)
Message-Id: <20040206.181003.68972716.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com
Subject: [PATCH 1/3] IPV6: clean-up DAD vs tentative address
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: 3040
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: 1563
Lines: 56

Hello.

[PATCH 1/3] IPV6: clean-up DAD vs tentative address

D: clean-up NS (including DAD) vs tentative address

Thanks.

===== net/ipv6/ndisc.c 1.67 vs edited =====
--- 1.67/net/ipv6/ndisc.c	Wed Feb  4 02:13:51 2004
+++ edited/net/ipv6/ndisc.c	Fri Feb  6 15:10:20 2004
@@ -764,23 +764,24 @@
 			   does DAD, otherwise we ignore solicitations
 			   until DAD timer expires.
 			 */
-			if (addr_type == IPV6_ADDR_ANY) {
-				if (dev->type == ARPHRD_IEEE802_TR) { 
-					unsigned char *sadr = skb->mac.raw ;
-					if (((sadr[8] &0x7f) != (dev->dev_addr[0] & 0x7f)) ||
-					(sadr[9] != dev->dev_addr[1]) ||
-					(sadr[10] != dev->dev_addr[2]) ||
-					(sadr[11] != dev->dev_addr[3]) ||
-					(sadr[12] != dev->dev_addr[4]) ||
-					(sadr[13] != dev->dev_addr[5])) 
-					{
-						addrconf_dad_failure(ifp) ; 
-					}
-				} else {
-					addrconf_dad_failure(ifp);
-				}
-			} else
+			if (addr_type != IPV6_ADDR_ANY) {
 				in6_ifa_put(ifp);
+				return;
+			}
+			if (dev->type == ARPHRD_IEEE802_TR) {
+				unsigned char *sadr = skb->mac.raw;
+				if (((sadr[8] ^ dev->dev_addr[0]) & 0x7f) == 0 &&
+				    sadr[9] == dev->dev_addr[1] &&
+				    sadr[10] == dev->dev_addr[2] &&
+				    sadr[11] == dev->dev_addr[3] &&
+				    sadr[12] == dev->dev_addr[4] &&
+				    sadr[13] == dev->dev_addr[5]) {
+					/* looped-back to us */
+					in6_ifa_put(ifp);
+					return;
+				}
+			}
+			addrconf_dad_failure(ifp); 
 			return;
 		}
 	

-- 
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 Fri Feb  6 01:09:23 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 01:09:36 -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 i1699MKO007679
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 01:09:23 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id DE06833CA5; Fri,  6 Feb 2004 18:10:14 +0900 (JST)
Date: Fri, 06 Feb 2004 18:10:14 +0900 (JST)
Message-Id: <20040206.181014.40584753.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com
Subject: [PATCH 3/3] IPV6: use cheaper ipv6_addr_any() where appropriate
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: 3042
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: 2211
Lines: 74

Hello.

[PATCH 3/3] IPV6: use cheaper ipv6_addr_any() where appropriate

D: Use cheaper ipv6_addr_any() where appropriate.

Thanks.

--- linux26-recv_ns/net/ipv6/ndisc.c	Fri Feb  6 16:38:44 2004
+++ linux26-ipv6_addr_any/net/ipv6/ndisc.c	Fri Feb  6 16:58:37 2004
@@ -709,7 +709,7 @@ static void ndisc_recv_ns(struct sk_buff
 	struct inet6_ifaddr *ifp;
 	struct inet6_dev *idev = NULL;
 	struct neighbour *neigh;
-	int addr_type = ipv6_addr_type(saddr);
+	int dad = ipv6_addr_any(saddr);
 	int inc;
 
 	if (ipv6_addr_is_multicast(&msg->target)) {
@@ -722,7 +722,7 @@ static void ndisc_recv_ns(struct sk_buff
 	 * RFC2461 7.1.1:
 	 * DAD has to be destined for solicited node multicast address.
 	 */
-	if (addr_type == IPV6_ADDR_ANY &&
+	if (dad &&
 	    !(daddr->s6_addr32[0] == htonl(0xff020000) &&
 	      daddr->s6_addr32[1] == htonl(0x00000000) &&
 	      daddr->s6_addr32[2] == htonl(0x00000001) &&
@@ -752,7 +752,7 @@ static void ndisc_recv_ns(struct sk_buff
 		 *	there MUST NOT be source link-layer address option 
 		 *	in the message.
 		 */
-		if (addr_type == IPV6_ADDR_ANY) {
+		if (dad) {
 			if (net_ratelimit())
 				printk(KERN_WARNING "ICMP6 NS: bad DAD packet (link-layer address option)\n");
 			return;
@@ -768,10 +768,8 @@ static void ndisc_recv_ns(struct sk_buff
 			   does DAD, otherwise we ignore solicitations
 			   until DAD timer expires.
 			 */
-			if (addr_type != IPV6_ADDR_ANY) {
-				in6_ifa_put(ifp);
-				return;
-			}
+			if (!dad)
+				goto out;
 			if (dev->type == ARPHRD_IEEE802_TR) {
 				unsigned char *sadr = skb->mac.raw;
 				if (((sadr[8] ^ dev->dev_addr[0]) & 0x7f) == 0 &&
@@ -781,8 +779,7 @@ static void ndisc_recv_ns(struct sk_buff
 				    sadr[12] == dev->dev_addr[4] &&
 				    sadr[13] == dev->dev_addr[5]) {
 					/* looped-back to us */
-					in6_ifa_put(ifp);
-					return;
+					goto out;
 				}
 			}
 			addrconf_dad_failure(ifp); 
@@ -820,7 +817,7 @@ static void ndisc_recv_ns(struct sk_buff
 			goto out;
 	}
 
-	if (addr_type == IPV6_ADDR_ANY) {
+	if (dad) {
 		struct in6_addr maddr;
 
 		ipv6_addr_all_nodes(&maddr);


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

From jeffrin_jose@rajagiritech.ac.in Fri Feb  6 02:29:55 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 02:30:03 -0800 (PST)
Received: from mail.rajagiritech.ac.in ([203.197.151.50])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i16ATpKO016318
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 02:29:53 -0800
Received: from rajagiritech.ac.in (www-data@localhost [127.0.0.1])
	by mail.rajagiritech.ac.in (8.12.3/8.12.3/Debian -4) with SMTP id i16A7Ghr015108
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 15:37:18 +0530
Received: from 202.88.226.19
        (RasetMail authenticated user jeffrin_jose)
        by mail.rajagiritech.ac.in with HTTP;
        Fri, 6 Feb 2004 15:37:18 +0530 (IST)
Message-ID: <1050.202.88.226.19.1076062038.mailer@mail.rajagiritech.ac.in>
Date: Fri, 6 Feb 2004 15:37:18 +0530 (IST)
Subject: Project related
From: "Jeffrin" <jeffrin_jose@rajagiritech.ac.in>
To: <netdev@oss.sgi.com>
X-Priority: 3
Importance: Normal
X-Mailer: RasetMail (version 1.2.8)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-archive-position: 3044
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: jeffrin_jose@rajagiritech.ac.in
Precedence: bulk
X-list: netdev
Content-Length: 844
Lines: 28




      I am planning to do a project which does a full
      packet analyse stuff and other operations related
      to it.I am not that well versed in programming
      but i need to learn and i want you to be my guide
      in this project.If you guide me a teach me
       and make me a good programmer then i will be a good
       asset to FSF.I am working for atleast GNU support for
       Rajagiri School of Engineering and Technology.

Here is my  beginning related TODO's ...

 * Bring the NIC to promiscous mode.
* Caputure the packets from the buffer.
* Find source and destination
* Find the type of the packet [TCP or any other protocols]

Please give me intructions and  i will follow it.


-----------------------------------------
Rajagiri School of Engineering and Technology
Kakkanad, Ernakulam
http://rajagiritech.ac.in/



From marcel@holtmann.org Fri Feb  6 06:59:06 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 06:59:09 -0800 (PST)
Received: from mail.holtmann.net (root@linux-bt.org [217.160.111.169])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i16Ex4KO026322
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 06:59:05 -0800
Received: from pegasus (pD9E117F5.dip.t-dialin.net [217.225.23.245])
	by mail.holtmann.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i16ExSV4001411;
	Fri, 6 Feb 2004 15:59:28 +0100
Subject: Re: some bluetooth fixes
From: Marcel Holtmann <marcel@holtmann.org>
To: Andi Kleen <ak@suse.de>
Cc: bluez-devel@lists.sourceforge.net, netdev@oss.sgi.com,
        viro@zenII.linux.org.uk
In-Reply-To: <20040206050042.20a2b3b0.ak@suse.de>
References: <20040206050042.20a2b3b0.ak@suse.de>
Content-Type: text/plain
Message-Id: <1076079512.2806.40.camel@pegasus>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Fri, 06 Feb 2004 15:58:32 +0100
Content-Transfer-Encoding: 7bit
X-archive-position: 3045
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: marcel@holtmann.org
Precedence: bulk
X-list: netdev
Content-Length: 2515
Lines: 85

Hi Andi,

> While reading bluetooth code I noticed some bugs and potential overflows.
> 
> Also I commented one ref-counting bug.
> 
> Patch against 2.6.2.

thanks for looking at it. Same applies to 2.4, right?

> diff -u linux-2.6.2-work32/net/bluetooth/cmtp/sock.c-o linux-2.6.2-work32/net/bluetooth/cmtp/sock.c
> --- linux-2.6.2-work32/net/bluetooth/cmtp/sock.c-o	2004-02-05 08:09:54.000000000 +0100
> +++ linux-2.6.2-work32/net/bluetooth/cmtp/sock.c	2004-02-05 14:57:57.000000000 +0100
> @@ -87,8 +87,10 @@
>  		if (!nsock)
>  			return err;
>  
> -		if (nsock->sk->sk_state != BT_CONNECTED)
> +		if (nsock->sk->sk_state != BT_CONNECTED) { 
> +			fput(nsock->file);
>  			return -EBADFD;
> +		}
>  
>  		err = cmtp_add_connection(&ca, nsock);
>  		if (!err) {

The same should apply to net/bluetooth/bnep/sock.c

> diff -u linux-2.6.2-work32/net/bluetooth/hci_sock.c-o linux-2.6.2-work32/net/bluetooth/hci_sock.c
> --- linux-2.6.2-work32/net/bluetooth/hci_sock.c-o	2004-02-05 08:09:54.000000000 +0100
> +++ linux-2.6.2-work32/net/bluetooth/hci_sock.c	2004-02-05 14:57:59.000000000 +0100
> @@ -392,6 +392,8 @@
>  
>  	skb->pkt_type = *((unsigned char *) skb->data);
>  	skb_pull(skb, 1);
> +	/* AK: looks broken. Who guarantees that hdev doesn't go away while
> +	   the skb is queued ? */
>  	skb->dev = (void *) hdev;
>  
>  	if (skb->pkt_type == HCI_COMMAND_PKT) {

Why should hdev go away?

> diff -u linux-2.6.2-work32/net/bluetooth/hci_conn.c-o linux-2.6.2-work32/net/bluetooth/hci_conn.c
> --- linux-2.6.2-work32/net/bluetooth/hci_conn.c-o	2004-02-05 08:09:54.000000000 +0100
> +++ linux-2.6.2-work32/net/bluetooth/hci_conn.c	2004-02-05 15:06:10.000000000 +0100
> @@ -353,21 +353,24 @@
>  	struct hci_conn_info *ci;
>  	struct hci_dev *hdev;
>  	struct list_head *p;
> -	int n = 0, size;
> +	int n = 0, size, err;
>  
>  	if (copy_from_user(&req, (void *) arg, sizeof(req)))
>  		return -EFAULT;
>  
> -	if (!(hdev = hci_dev_get(req.dev_id)))
> -		return -ENODEV;
> +	if (req.conn_num >= (2*PAGE_SIZE)/sizeof(struct hci_conn_info))
> +		return -EINVAL; 
>  
>  	size = req.conn_num * sizeof(struct hci_conn_info) + sizeof(req);
>  
> -	if (verify_area(VERIFY_WRITE, (void *)arg, size))
> -		return -EFAULT;
> -
>  	if (!(cl = (void *) kmalloc(size, GFP_KERNEL)))
>  		return -ENOMEM;
> +
> +	if (!(hdev = hci_dev_get(req.dev_id))) { 
> +		kfree(cl);
> +		return -ENODEV;
> +	}
> +
>  	ci = cl->conn_info;
>  
>  	hci_dev_lock_bh(hdev);

Why 2*PAGE_SIZE in this case? What is different?

Regards

Marcel



From shmulik.hen@intel.com Fri Feb  6 08:38:15 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 08:38:26 -0800 (PST)
Received: from hermes.py.intel.com (hermes.py.intel.com [146.152.216.3])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i16GcEKO002089
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 08:38:15 -0800
Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4])
	by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.5 2003/11/26 00:10:29 root Exp $) with ESMTP id i15EOm09017736;
	Thu, 5 Feb 2004 14:24:48 GMT
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206])
	by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i15EPhOp009928;
	Thu, 5 Feb 2004 14:25:43 GMT
Received: from jrslxjul4.npdj.intel.com ([10.12.220.54])
 by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020506244311225
 ; Thu, 05 Feb 2004 06:24:45 -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 16:24:40 +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: <200402051624.42303.shmulik.hen@intel.com>
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-archive-position: 3046
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

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 kazunori@miyazawa.org Fri Feb  6 09:32:45 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 09:32:52 -0800 (PST)
Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i16HWiKO003985
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 09:32:45 -0800
Received: from 2001:200:1b0:2031:20c:29ff:febb:6598 ([2001:200:1b0:2031:20c:29ff:febb:6598])
  (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,128bits,RC4-MD5)
  by miyazawa.org with esmtp; Sat, 07 Feb 2004 02:31:06 +0900
From: Kazunori Miyazawa <kazunori@miyazawa.org>
To: davem@redhat.com
Subject: [PATCH][IPV6][NDISC] unify ipv6 output routine
Date: Sat, 7 Feb 2004 02:32:33 +0900
User-Agent: KMail/1.5.4
Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200402070232.33771.kazunori@miyazawa.org>
X-archive-position: 3047
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: kazunori@miyazawa.org
Precedence: bulk
X-list: netdev

Hello, 

Yoshifuji-san and I send the patch which unifies IPv6 output routine and remove
RTF_NDISC again. It resolves an issue of IPv6 IPsec with neighbor discovery
without a flag.

This patch is against linux-2.6.2.

Best regards,

--Kazunori Miyazawa

===== include/linux/ipv6_route.h 1.4 vs edited =====
--- 1.4/include/linux/ipv6_route.h	Sun Aug 31 13:26:12 2003
+++ edited/include/linux/ipv6_route.h	Mon Jan 26 15:09:34 2004
@@ -24,7 +24,6 @@
 #define RTF_CACHE	0x01000000	/* cache entry			*/
 #define RTF_FLOW	0x02000000	/* flow significant route	*/
 #define RTF_POLICY	0x04000000	/* policy route			*/
-#define RTF_NDISC	0x08000000	/* ndisc route			*/
 
 #define RTF_LOCAL	0x80000000
 
===== include/net/ipv6.h 1.28 vs edited =====
--- 1.28/include/net/ipv6.h	Wed Jan 14 09:36:24 2004
+++ edited/include/net/ipv6.h	Mon Jan 26 15:10:50 2004
@@ -355,6 +355,7 @@
  */
 
 extern int			ip6_output(struct sk_buff *skb);
+extern int			ip6_output2(struct sk_buff *skb);
 extern int			ip6_forward(struct sk_buff *skb);
 extern int			ip6_input(struct sk_buff *skb);
 extern int			ip6_mc_input(struct sk_buff *skb);
===== 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	Mon Jan 26 15:10:16 2004
@@ -390,20 +390,6 @@
  *	Send a Neighbour Advertisement
  */
 
-static int ndisc_output(struct sk_buff *skb)
-{
-	if (skb) {
-		struct neighbour *neigh = (skb->dst ? skb->dst->neighbour : NULL);
-		if (ndisc_build_ll_hdr(skb, skb->dev, &skb->nh.ipv6h->daddr, neigh, skb->len) == 0) {
-			kfree_skb(skb);
-			return -EINVAL;
-		}
-		dev_queue_xmit(skb);
-		return 0;
-	}
-	return -EINVAL;
-}
-
 static inline void ndisc_flow_init(struct flowi *fl, u8 type,
 			    struct in6_addr *saddr, struct in6_addr *daddr)
 {
@@ -446,7 +432,7 @@
 
 	ndisc_flow_init(&fl, NDISC_NEIGHBOUR_ADVERTISEMENT, src_addr, daddr);
 
-	dst = ndisc_dst_alloc(dev, neigh, ndisc_output);
+	dst = ndisc_dst_alloc(dev, neigh, ip6_output2);
 	if (!dst)
 		return;
 
@@ -533,7 +519,7 @@
 
 	ndisc_flow_init(&fl, NDISC_NEIGHBOUR_SOLICITATION, saddr, daddr);
 
-	dst = ndisc_dst_alloc(dev, neigh, ndisc_output);
+	dst = ndisc_dst_alloc(dev, neigh, ip6_output2);
 	if (!dst)
 		return;
 
@@ -605,7 +591,7 @@
 
 	ndisc_flow_init(&fl, NDISC_ROUTER_SOLICITATION, saddr, daddr);
 
-	dst = ndisc_dst_alloc(dev, NULL, ndisc_output);
+	dst = ndisc_dst_alloc(dev, NULL, ip6_output2);
 	if (!dst)
 		return;
 
===== net/ipv6/route.c 1.63 vs edited =====
--- 1.63/net/ipv6/route.c	Sun Jan 25 03:09:52 2004
+++ edited/net/ipv6/route.c	Mon Jan 26 15:11:39 2004
@@ -578,7 +578,7 @@
 	rt->rt6i_dev	  = dev;
 	rt->rt6i_nexthop  = neigh;
 	rt->rt6i_expires  = 0;
-	rt->rt6i_flags    = RTF_LOCAL | RTF_NDISC;
+	rt->rt6i_flags    = RTF_LOCAL;
 	rt->rt6i_metric   = 0;
 	atomic_set(&rt->u.dst.__refcnt, 1);
 	rt->u.dst.metrics[RTAX_HOPLIMIT-1] = 255;
@@ -832,7 +832,7 @@
 		}
 	}
 
-	rt->rt6i_flags = rtmsg->rtmsg_flags & ~RTF_NDISC;
+	rt->rt6i_flags = rtmsg->rtmsg_flags;
 
 install_route:
 	if (rta && rta[RTA_METRICS-1]) {
@@ -1124,8 +1124,6 @@
 static struct rt6_info * ip6_rt_copy(struct rt6_info *ort)
 {
 	struct rt6_info *rt = ip6_dst_alloc();
-
-	BUG_ON(ort->rt6i_flags & RTF_NDISC);
 
 	if (rt) {
 		rt->u.dst.input = ort->u.dst.input;
===== net/ipv6/xfrm6_policy.c 1.14 vs edited =====
--- 1.14/net/ipv6/xfrm6_policy.c	Fri Oct 24 21:39:33 2003
+++ edited/net/ipv6/xfrm6_policy.c	Mon Jan 26 15:12:35 2004
@@ -55,13 +55,6 @@
 __xfrm6_find_bundle(struct flowi *fl, struct rtable *rt, struct xfrm_policy *policy)
 {
 	struct dst_entry *dst;
-	u32 ndisc_bit = 0;
-
-	if (fl->proto == IPPROTO_ICMPV6 &&
-	    (fl->fl_icmp_type == NDISC_NEIGHBOUR_ADVERTISEMENT ||
-	     fl->fl_icmp_type == NDISC_NEIGHBOUR_SOLICITATION  ||
-	     fl->fl_icmp_type == NDISC_ROUTER_SOLICITATION))
-		ndisc_bit = RTF_NDISC;
 
 	/* Still not clear if we should set fl->fl6_{src,dst}... */
 	read_lock_bh(&policy->lock);
@@ -69,9 +62,6 @@
 		struct xfrm_dst *xdst = (struct xfrm_dst*)dst;
 		struct in6_addr fl_dst_prefix, fl_src_prefix;
 
-		if ((xdst->u.rt6.rt6i_flags & RTF_NDISC) != ndisc_bit)
-			continue;
-
 		ipv6_addr_prefix(&fl_dst_prefix,
 				 &fl->fl6_dst,
 				 xdst->u.rt6.rt6i_dst.plen);
@@ -169,7 +159,7 @@
 		dst_prev->output	= dst_prev->xfrm->type->output;
 		/* Sheit... I remember I did this right. Apparently,
 		 * it was magically lost, so this code needs audit */
-		x->u.rt6.rt6i_flags    = rt0->rt6i_flags&(RTCF_BROADCAST|RTCF_MULTICAST|RTCF_LOCAL|RTF_NDISC);
+		x->u.rt6.rt6i_flags    = rt0->rt6i_flags&(RTCF_BROADCAST|RTCF_MULTICAST|RTCF_LOCAL);
 		x->u.rt6.rt6i_metric   = rt0->rt6i_metric;
 		x->u.rt6.rt6i_node     = rt0->rt6i_node;
 		x->u.rt6.rt6i_gateway  = rt0->rt6i_gateway;


From mika.penttila@kolumbus.fi Fri Feb  6 09:59:06 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 09:59:11 -0800 (PST)
Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i16Hx3KO005554
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 09:59:05 -0800
Received: from kolumbus.fi ([193.166.244.70])
          by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8)
          with ESMTP id 2004020620011151:6166 ;
          Fri, 6 Feb 2004 20:01:11 +0200 
Message-ID: <4023D6FB.9010909@kolumbus.fi>
Date: Fri, 06 Feb 2004 20:03:39 +0200
From: =?ISO-8859-1?Q?Mika_Penttil=E4?= <mika.penttila@kolumbus.fi>
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
MIME-Version: 1.0
To: Kazunori Miyazawa <kazunori@miyazawa.org>
CC: davem@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com,
        usagi-core@linux-ipv6.org
Subject: Re: [PATCH][IPV6][NDISC] unify ipv6 output routine
References: <200402070232.33771.kazunori@miyazawa.org>
In-Reply-To: <200402070232.33771.kazunori@miyazawa.org>
X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June
 18, 2001) at 06.02.2004 20:01:11,
	Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March
 22, 2002) at 06.02.2004 20:00:25,
	Serialize complete at 06.02.2004 20:00:26,
	Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March
 22, 2002) at 06.02.2004 20:00:26
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-archive-position: 3048
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: mika.penttila@kolumbus.fi
Precedence: bulk
X-list: netdev



Kazunori Miyazawa wrote:

>Hello, 
>
>Yoshifuji-san and I send the patch which unifies IPv6 output routine and remove
>RTF_NDISC again. It resolves an issue of IPv6 IPsec with neighbor discovery
>without a flag.
>  
>

You break multicast replies, see what ndisc_build_ll_hdr() does...

--Mika


>This patch is against linux-2.6.2.
>
>Best regards,
>
>--Kazunori Miyazawa
>
>===== include/linux/ipv6_route.h 1.4 vs edited =====
>--- 1.4/include/linux/ipv6_route.h	Sun Aug 31 13:26:12 2003
>+++ edited/include/linux/ipv6_route.h	Mon Jan 26 15:09:34 2004
>@@ -24,7 +24,6 @@
> #define RTF_CACHE	0x01000000	/* cache entry			*/
> #define RTF_FLOW	0x02000000	/* flow significant route	*/
> #define RTF_POLICY	0x04000000	/* policy route			*/
>-#define RTF_NDISC	0x08000000	/* ndisc route			*/
> 
> #define RTF_LOCAL	0x80000000
> 
>===== include/net/ipv6.h 1.28 vs edited =====
>--- 1.28/include/net/ipv6.h	Wed Jan 14 09:36:24 2004
>+++ edited/include/net/ipv6.h	Mon Jan 26 15:10:50 2004
>@@ -355,6 +355,7 @@
>  */
> 
> extern int			ip6_output(struct sk_buff *skb);
>+extern int			ip6_output2(struct sk_buff *skb);
> extern int			ip6_forward(struct sk_buff *skb);
> extern int			ip6_input(struct sk_buff *skb);
> extern int			ip6_mc_input(struct sk_buff *skb);
>===== 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	Mon Jan 26 15:10:16 2004
>@@ -390,20 +390,6 @@
>  *	Send a Neighbour Advertisement
>  */
> 
>-static int ndisc_output(struct sk_buff *skb)
>-{
>-	if (skb) {
>-		struct neighbour *neigh = (skb->dst ? skb->dst->neighbour : NULL);
>-		if (ndisc_build_ll_hdr(skb, skb->dev, &skb->nh.ipv6h->daddr, neigh, skb->len) == 0) {
>-			kfree_skb(skb);
>-			return -EINVAL;
>-		}
>-		dev_queue_xmit(skb);
>-		return 0;
>-	}
>-	return -EINVAL;
>-}
>-
> static inline void ndisc_flow_init(struct flowi *fl, u8 type,
> 			    struct in6_addr *saddr, struct in6_addr *daddr)
> {
>@@ -446,7 +432,7 @@
> 
> 	ndisc_flow_init(&fl, NDISC_NEIGHBOUR_ADVERTISEMENT, src_addr, daddr);
> 
>-	dst = ndisc_dst_alloc(dev, neigh, ndisc_output);
>+	dst = ndisc_dst_alloc(dev, neigh, ip6_output2);
> 	if (!dst)
> 		return;
> 
>@@ -533,7 +519,7 @@
> 
> 	ndisc_flow_init(&fl, NDISC_NEIGHBOUR_SOLICITATION, saddr, daddr);
> 
>-	dst = ndisc_dst_alloc(dev, neigh, ndisc_output);
>+	dst = ndisc_dst_alloc(dev, neigh, ip6_output2);
> 	if (!dst)
> 		return;
> 
>@@ -605,7 +591,7 @@
> 
> 	ndisc_flow_init(&fl, NDISC_ROUTER_SOLICITATION, saddr, daddr);
> 
>-	dst = ndisc_dst_alloc(dev, NULL, ndisc_output);
>+	dst = ndisc_dst_alloc(dev, NULL, ip6_output2);
> 	if (!dst)
> 		return;
> 
>===== net/ipv6/route.c 1.63 vs edited =====
>--- 1.63/net/ipv6/route.c	Sun Jan 25 03:09:52 2004
>+++ edited/net/ipv6/route.c	Mon Jan 26 15:11:39 2004
>@@ -578,7 +578,7 @@
> 	rt->rt6i_dev	  = dev;
> 	rt->rt6i_nexthop  = neigh;
> 	rt->rt6i_expires  = 0;
>-	rt->rt6i_flags    = RTF_LOCAL | RTF_NDISC;
>+	rt->rt6i_flags    = RTF_LOCAL;
> 	rt->rt6i_metric   = 0;
> 	atomic_set(&rt->u.dst.__refcnt, 1);
> 	rt->u.dst.metrics[RTAX_HOPLIMIT-1] = 255;
>@@ -832,7 +832,7 @@
> 		}
> 	}
> 
>-	rt->rt6i_flags = rtmsg->rtmsg_flags & ~RTF_NDISC;
>+	rt->rt6i_flags = rtmsg->rtmsg_flags;
> 
> install_route:
> 	if (rta && rta[RTA_METRICS-1]) {
>@@ -1124,8 +1124,6 @@
> static struct rt6_info * ip6_rt_copy(struct rt6_info *ort)
> {
> 	struct rt6_info *rt = ip6_dst_alloc();
>-
>-	BUG_ON(ort->rt6i_flags & RTF_NDISC);
> 
> 	if (rt) {
> 		rt->u.dst.input = ort->u.dst.input;
>===== net/ipv6/xfrm6_policy.c 1.14 vs edited =====
>--- 1.14/net/ipv6/xfrm6_policy.c	Fri Oct 24 21:39:33 2003
>+++ edited/net/ipv6/xfrm6_policy.c	Mon Jan 26 15:12:35 2004
>@@ -55,13 +55,6 @@
> __xfrm6_find_bundle(struct flowi *fl, struct rtable *rt, struct xfrm_policy *policy)
> {
> 	struct dst_entry *dst;
>-	u32 ndisc_bit = 0;
>-
>-	if (fl->proto == IPPROTO_ICMPV6 &&
>-	    (fl->fl_icmp_type == NDISC_NEIGHBOUR_ADVERTISEMENT ||
>-	     fl->fl_icmp_type == NDISC_NEIGHBOUR_SOLICITATION  ||
>-	     fl->fl_icmp_type == NDISC_ROUTER_SOLICITATION))
>-		ndisc_bit = RTF_NDISC;
> 
> 	/* Still not clear if we should set fl->fl6_{src,dst}... */
> 	read_lock_bh(&policy->lock);
>@@ -69,9 +62,6 @@
> 		struct xfrm_dst *xdst = (struct xfrm_dst*)dst;
> 		struct in6_addr fl_dst_prefix, fl_src_prefix;
> 
>-		if ((xdst->u.rt6.rt6i_flags & RTF_NDISC) != ndisc_bit)
>-			continue;
>-
> 		ipv6_addr_prefix(&fl_dst_prefix,
> 				 &fl->fl6_dst,
> 				 xdst->u.rt6.rt6i_dst.plen);
>@@ -169,7 +159,7 @@
> 		dst_prev->output	= dst_prev->xfrm->type->output;
> 		/* Sheit... I remember I did this right. Apparently,
> 		 * it was magically lost, so this code needs audit */
>-		x->u.rt6.rt6i_flags    = rt0->rt6i_flags&(RTCF_BROADCAST|RTCF_MULTICAST|RTCF_LOCAL|RTF_NDISC);
>+		x->u.rt6.rt6i_flags    = rt0->rt6i_flags&(RTCF_BROADCAST|RTCF_MULTICAST|RTCF_LOCAL);
> 		x->u.rt6.rt6i_metric   = rt0->rt6i_metric;
> 		x->u.rt6.rt6i_node     = rt0->rt6i_node;
> 		x->u.rt6.rt6i_gateway  = rt0->rt6i_gateway;
>
>
>
>  
>


From shemminger@osdl.org Fri Feb  6 10:13:56 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 10:14:01 -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 i16IDuKO006387
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 10:13:56 -0800
Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60])
	by mail.osdl.org (8.11.6/8.11.6) with SMTP id i16IDiN29541;
	Fri, 6 Feb 2004 10:13:44 -0800
Date: Fri, 6 Feb 2004 10:05:01 -0800
From: Stephen Hemminger <shemminger@osdl.org>
To: "David S. Miller" <davem@redhat.com>
Cc: netdev@oss.sgi.com
Subject: [PATCH] (3/4) Support lots of netdev's -- hash ifindex
Message-Id: <20040206100501.6ffcfa8a.shemminger@osdl.org>
Organization: Open Source Development Lab
X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-linux-gnu)
X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$
 /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 3049
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: shemminger@osdl.org
Precedence: bulk
X-list: netdev

Hash network device index entries, to allow fast lookup by routing
protocols.

diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h
--- a/include/linux/netdevice.h	Thu Feb  5 15:17:30 2004
+++ b/include/linux/netdevice.h	Thu Feb  5 15:17:30 2004
@@ -377,6 +377,8 @@
 	struct list_head	todo_list;
 	/* device name hash chain */
 	struct hlist_node	name_hlist;
+	/* device index hash chain */
+	struct hlist_node	index_hlist;
 
 	/* register/unregister state machine */
 	enum { NETREG_UNINITIALIZED=0,
diff -Nru a/net/core/dev.c b/net/core/dev.c
--- a/net/core/dev.c	Thu Feb  5 15:17:30 2004
+++ b/net/core/dev.c	Thu Feb  5 15:17:30 2004
@@ -188,6 +188,7 @@
 
 #define NETDEV_HASHBITS	8
 static struct hlist_head dev_name_head[1<<NETDEV_HASHBITS];
+static struct hlist_head dev_index_head[1<<NETDEV_HASHBITS];
 
 static inline struct hlist_head *dev_name_hash(const char *name)
 {
@@ -195,6 +196,11 @@
 	return &dev_name_head[hash & ((1<<NETDEV_HASHBITS)-1)];
 }
 
+static inline struct hlist_head *dev_index_hash(int ifindex)
+{
+	return &dev_index_head[ifindex & ((1<<NETDEV_HASHBITS)-1)];
+}
+
 /*
  *	Our notifier list
  */
@@ -554,12 +560,15 @@
 
 struct net_device *__dev_get_by_index(int ifindex)
 {
-	struct net_device *dev;
+	struct hlist_node *p;
 
-	for (dev = dev_base; dev; dev = dev->next)
+	hlist_for_each(p, dev_index_hash(ifindex)) {
+		struct net_device *dev
+			= hlist_entry(p, struct net_device, index_hlist);
 		if (dev->ifindex == ifindex)
-			break;
-	return dev;
+			return dev;
+	}
+	return NULL;
 }
 
 
@@ -2842,6 +2851,7 @@
 	*dev_tail = dev;
 	dev_tail = &dev->next;
 	hlist_add_head(&dev->name_hlist, head);
+	hlist_add_head(&dev->index_hlist, dev_index_hash(dev->ifindex));
 	dev_hold(dev);
 	dev->reg_state = NETREG_REGISTERING;
 	write_unlock_bh(&dev_base_lock);
@@ -3064,6 +3074,7 @@
 		if (d == dev) {
 			write_lock_bh(&dev_base_lock);
 			hlist_del(&dev->name_hlist);
+			hlist_del(&dev->index_hlist);
 			if (dev_tail == &dev->next)
 				dev_tail = dp;
 			*dp = d->next;
@@ -3144,6 +3155,9 @@
 
 	for (i = 0; i < ARRAY_SIZE(dev_name_head); i++)
 		INIT_HLIST_HEAD(&dev_name_head[i]);
+
+	for (i = 0; i < ARRAY_SIZE(dev_index_head); i++)
+		INIT_HLIST_HEAD(&dev_index_head[i]);
 
 	/*
 	 *	Initialise the packet receive queues.

From shemminger@osdl.org Fri Feb  6 10:13:56 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 10:14:01 -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 i16IDtKO006386
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 10:13:56 -0800
Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60])
	by mail.osdl.org (8.11.6/8.11.6) with SMTP id i16IDhN29532;
	Fri, 6 Feb 2004 10:13:43 -0800
Date: Fri, 6 Feb 2004 10:03:10 -0800
From: Stephen Hemminger <shemminger@osdl.org>
To: "David S. Miller" <davem@redhat.com>
Cc: netdev@oss.sgi.com
Subject: [PATCH] (1/4) Support for lots of netdev's -- dev_base move
Message-Id: <20040206100310.21ebd1da.shemminger@osdl.org>
Organization: Open Source Development Lab
X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-linux-gnu)
X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$
 /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 3051
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: shemminger@osdl.org
Precedence: bulk
X-list: netdev

The first patch moves the device list and locks from drivers/net/Space.c
to net/core/dev.c. The list used to be in Space.c because we initialized it
in 2.4, but now it makes more sense to put it over with the management
routines.

Resend of the patchset to support a large number of network
devices efficiently with feedback applied, and rediff'd against 2.6.2

diff -Nru a/drivers/net/Space.c b/drivers/net/Space.c
--- a/drivers/net/Space.c	Thu Feb  5 15:16:58 2004
+++ b/drivers/net/Space.c	Thu Feb  5 15:16:58 2004
@@ -430,28 +430,3 @@
 }
 
 device_initcall(net_olddevs_init);
-
-/*
- * The @dev_base list is protected by @dev_base_lock and the rtln
- * semaphore.
- *
- * Pure readers hold dev_base_lock for reading.
- *
- * Writers must hold the rtnl semaphore while they loop through the
- * dev_base list, and hold dev_base_lock for writing when they do the
- * actual updates.  This allows pure readers to access the list even
- * while a writer is preparing to update it.
- *
- * To put it another way, dev_base_lock is held for writing only to
- * protect against pure readers; the rtnl semaphore provides the
- * protection against other writers.
- *
- * See, for example usages, register_netdevice() and
- * unregister_netdevice(), which must be called with the rtnl
- * semaphore held.
- */
-struct net_device *dev_base;
-rwlock_t dev_base_lock = RW_LOCK_UNLOCKED;
-
-EXPORT_SYMBOL(dev_base);
-EXPORT_SYMBOL(dev_base_lock);
diff -Nru a/net/core/dev.c b/net/core/dev.c
--- a/net/core/dev.c	Thu Feb  5 15:16:58 2004
+++ b/net/core/dev.c	Thu Feb  5 15:16:58 2004
@@ -161,6 +161,31 @@
 #endif
 
 /*
+ * The @dev_base list is protected by @dev_base_lock and the rtln
+ * semaphore.
+ *
+ * Pure readers hold dev_base_lock for reading.
+ *
+ * Writers must hold the rtnl semaphore while they loop through the
+ * dev_base list, and hold dev_base_lock for writing when they do the
+ * actual updates.  This allows pure readers to access the list even
+ * while a writer is preparing to update it.
+ *
+ * To put it another way, dev_base_lock is held for writing only to
+ * protect against pure readers; the rtnl semaphore provides the
+ * protection against other writers.
+ *
+ * See, for example usages, register_netdevice() and
+ * unregister_netdevice(), which must be called with the rtnl
+ * semaphore held.
+ */
+struct net_device *dev_base;
+rwlock_t dev_base_lock = RW_LOCK_UNLOCKED;
+
+EXPORT_SYMBOL(dev_base);
+EXPORT_SYMBOL(dev_base_lock);
+
+/*
  *	Our notifier list
  */
 

From shemminger@osdl.org Fri Feb  6 10:13:56 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 10:14:01 -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 i16IDuKO006388
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 10:13:56 -0800
Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60])
	by mail.osdl.org (8.11.6/8.11.6) with SMTP id i16IDiN29545;
	Fri, 6 Feb 2004 10:13:44 -0800
Date: Fri, 6 Feb 2004 10:12:32 -0800
From: Stephen Hemminger <shemminger@osdl.org>
To: "David S. Miller" <davem@redhat.com>
Cc: netdev@oss.sgi.com
Subject: [PATCH] (4/4) Support for lots of netdev's -- faster dev_alloc_name
Message-Id: <20040206101232.46bc30b1.shemminger@osdl.org>
Organization: Open Source Development Lab
X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-linux-gnu)
X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$
 /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 3050
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: shemminger@osdl.org
Precedence: bulk
X-list: netdev

Convert dev_alloc_name from O(n^2) lookup to O(n) by using a page as
bitmap to figure out how many devices of that pattern have been allocated.
This works for up to 32k devices (PAGE_SIZE*8) on i386, more on other
platforms.  Correctly handles the boundary cases where number of devices
won't fit because name length is limited.

Adds strnchr to the string libraries since we need to find the % format
character, but only care if it is in the first 15 bytes.

diff -Nru a/include/linux/string.h b/include/linux/string.h
--- a/include/linux/string.h	Thu Feb  5 15:17:53 2004
+++ b/include/linux/string.h	Thu Feb  5 15:17:53 2004
@@ -52,6 +52,9 @@
 #ifndef __HAVE_ARCH_STRCHR
 extern char * strchr(const char *,int);
 #endif
+#ifndef __HAVE_ARCH_STRNCHR
+extern char * strnchr(const char *, size_t, int);
+#endif
 #ifndef __HAVE_ARCH_STRRCHR
 extern char * strrchr(const char *,int);
 #endif
diff -Nru a/lib/string.c b/lib/string.c
--- a/lib/string.c	Thu Feb  5 15:17:53 2004
+++ b/lib/string.c	Thu Feb  5 15:17:53 2004
@@ -273,6 +273,22 @@
 }
 #endif
 
+#ifndef __HAVE_ARCH_STRNCHR
+/**
+ * strnchr - Find a character in a length limited string
+ * @s: The string to be searched
+ * @count: The number of characters to be searched
+ * @c: The character to search for
+ */
+char *strnchr(const char *s, size_t count, int c)
+{
+	for (; count-- && *s != '\0'; ++s)
+		if (*s == (char) c)
+			return (char *) s;
+	return NULL;
+}
+#endif
+
 #ifndef __HAVE_ARCH_STRLEN
 /**
  * strlen - Find the length of a string
diff -Nru a/net/core/dev.c b/net/core/dev.c
--- a/net/core/dev.c	Thu Feb  5 15:17:53 2004
+++ b/net/core/dev.c	Thu Feb  5 15:17:53 2004
@@ -720,30 +720,55 @@
 
 int dev_alloc_name(struct net_device *dev, const char *name)
 {
-	int i;
-	char buf[32];
-	char *p;
-
-	/*
-	 * Verify the string as this thing may have come from
-	 * the user.  There must be either one "%d" and no other "%"
-	 * characters, or no "%" characters at all.
-	 */
-	p = strchr(name, '%');
-	if (p && (p[1] != 'd' || strchr(p + 2, '%')))
-		return -EINVAL;
+	int i = 0;
+	char buf[IFNAMSIZ];
+	const char *p;
+	const int max_netdevices = 8*PAGE_SIZE;
+	long *inuse;
+	struct net_device *d;
 
-	/*
-	 * If you need over 100 please also fix the algorithm...
-	 */
-	for (i = 0; i < 100; i++) {
-		snprintf(buf, sizeof(buf), name, i);
-		if (!__dev_get_by_name(buf)) {
-			strcpy(dev->name, buf);
-			return i;
+	p = strnchr(name, IFNAMSIZ-1, '%');
+	if (p) {
+		/*
+		 * Verify the string as this thing may have come from
+		 * the user.  There must be either one "%d" and no other "%"
+		 * characters.
+		 */
+		if (p[1] != 'd' || strchr(p + 2, '%'))
+			return -EINVAL;
+
+		/* Use one page as a bit array of possible slots */
+		inuse = (long *) get_zeroed_page(GFP_ATOMIC);
+		if (!inuse)
+			return -ENOMEM;
+
+		for (d = dev_base; d; d = d->next) {
+			if (!sscanf(d->name, name, &i))
+				continue;
+			if (i < 0 || i >= max_netdevices)
+				continue;
+
+			/*  avoid cases where sscanf is not exact inverse of printf */
+			snprintf(buf, sizeof(buf), name, i);
+			if (!strncmp(buf, d->name, IFNAMSIZ))
+				set_bit(i, inuse);
 		}
+
+		i = find_first_zero_bit(inuse, max_netdevices);
+		free_page((unsigned long) inuse);
+	}
+
+	snprintf(buf, sizeof(buf), name, i);
+	if (!__dev_get_by_name(buf)) {
+		strlcpy(dev->name, buf, IFNAMSIZ);
+		return i;
 	}
-	return -ENFILE;	/* Over 100 of the things .. bail out! */
+
+	/* It is possible to run out of possible slots
+	 * when the name is long and there isn't enough space left
+	 * for the digits, or if all bits are used.
+	 */
+	return -ENFILE;
 }
 
 

From shemminger@osdl.org Fri Feb  6 10:20:59 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 10:21:02 -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 i16IKwKO007748
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 10:20:59 -0800
Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60])
	by mail.osdl.org (8.11.6/8.11.6) with SMTP id i16IKkN31853;
	Fri, 6 Feb 2004 10:20:47 -0800
Date: Fri, 6 Feb 2004 10:20:46 -0800
From: Stephen Hemminger <shemminger@osdl.org>
To: "David S. Miller" <davem@redhat.com>
Cc: netdev@oss.sgi.com
Subject: [PATCH] (2/4) Support for lots of netdev's -- hash name
Message-Id: <20040206102046.7b14a89c.shemminger@osdl.org>
Organization: Open Source Development Lab
X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-linux-gnu)
X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$
 /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 3052
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: shemminger@osdl.org
Precedence: bulk
X-list: netdev

Hash the network device names for faster lookup when there are 1000's
of network devices.  Need to keep track of tail of dev_base linked list,
for fast insertion, since no longer need to walk whole list.

Resend of the patchset to support a large number of network
devices efficiently with feedback applied, and rediff'd against 2.6.2


diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h
--- a/include/linux/netdevice.h	Thu Feb  5 15:17:15 2004
+++ b/include/linux/netdevice.h	Thu Feb  5 15:17:15 2004
@@ -375,6 +375,8 @@
 	atomic_t		refcnt;
 	/* delayed register/unregister */
 	struct list_head	todo_list;
+	/* device name hash chain */
+	struct hlist_node	name_hlist;
 
 	/* register/unregister state machine */
 	enum { NETREG_UNINITIALIZED=0,
diff -Nru a/net/core/dev.c b/net/core/dev.c
--- a/net/core/dev.c	Thu Feb  5 15:17:15 2004
+++ b/net/core/dev.c	Thu Feb  5 15:17:15 2004
@@ -180,11 +180,21 @@
  * semaphore held.
  */
 struct net_device *dev_base;
+struct net_device **dev_tail = &dev_base;
 rwlock_t dev_base_lock = RW_LOCK_UNLOCKED;
 
 EXPORT_SYMBOL(dev_base);
 EXPORT_SYMBOL(dev_base_lock);
 
+#define NETDEV_HASHBITS	8
+static struct hlist_head dev_name_head[1<<NETDEV_HASHBITS];
+
+static inline struct hlist_head *dev_name_hash(const char *name)
+{
+	unsigned hash = full_name_hash(name, strnlen(name, IFNAMSIZ));
+	return &dev_name_head[hash & ((1<<NETDEV_HASHBITS)-1)];
+}
+
 /*
  *	Our notifier list
  */
@@ -468,12 +478,15 @@
 
 struct net_device *__dev_get_by_name(const char *name)
 {
-	struct net_device *dev;
+	struct hlist_node *p;
 
-	for (dev = dev_base; dev; dev = dev->next)
+	hlist_for_each(p, dev_name_hash(name)) {
+		struct net_device *dev
+			= hlist_entry(p, struct net_device, name_hlist);
 		if (!strncmp(dev->name, name, IFNAMSIZ))
-			break;
-	return dev;
+			return dev;
+	}
+	return NULL;
 }
 
 /**
@@ -754,6 +767,9 @@
 	else
 		strlcpy(dev->name, newname, IFNAMSIZ);
 
+	hlist_del(&dev->name_hlist);
+	hlist_add_head(&dev->name_hlist, dev_name_hash(dev->name));
+
 	class_device_rename(&dev->class_dev, dev->name);
 	notifier_call_chain(&netdev_chain, NETDEV_CHANGENAME, dev);
 	return 0;
@@ -2742,7 +2758,8 @@
 
 int register_netdevice(struct net_device *dev)
 {
-	struct net_device *d, **dp;
+	struct hlist_head *head;
+	struct hlist_node *p;
 	int ret;
 
 	BUG_ON(dev_boot_phase);
@@ -2783,13 +2800,17 @@
 	if (dev->iflink == -1)
 		dev->iflink = dev->ifindex;
 
-	/* Check for existence, and append to tail of chain */
-	ret = -EEXIST;
-	for (dp = &dev_base; (d = *dp) != NULL; dp = &d->next) {
-		if (d == dev || !strcmp(d->name, dev->name))
-			goto out_err;
-	}
-	
+	/* Check for existence of name */
+	head = dev_name_hash(dev->name);
+	hlist_for_each(p, head) {
+		struct net_device *d
+			= hlist_entry(p, struct net_device, name_hlist);
+		if (!strncmp(d->name, dev->name, IFNAMSIZ)) {
+			ret = -EEXIST;
+ 			goto out_err;
+		}
+ 	}
+
 	/* Fix illegal SG+CSUM combinations. */
 	if ((dev->features & NETIF_F_SG) &&
 	    !(dev->features & (NETIF_F_IP_CSUM |
@@ -2818,7 +2839,9 @@
 	dev->next = NULL;
 	dev_init_scheduler(dev);
 	write_lock_bh(&dev_base_lock);
-	*dp = dev;
+	*dev_tail = dev;
+	dev_tail = &dev->next;
+	hlist_add_head(&dev->name_hlist, head);
 	dev_hold(dev);
 	dev->reg_state = NETREG_REGISTERING;
 	write_unlock_bh(&dev_base_lock);
@@ -3040,6 +3063,9 @@
 	for (dp = &dev_base; (d = *dp) != NULL; dp = &d->next) {
 		if (d == dev) {
 			write_lock_bh(&dev_base_lock);
+			hlist_del(&dev->name_hlist);
+			if (dev_tail == &dev->next)
+				dev_tail = dp;
 			*dp = d->next;
 			write_unlock_bh(&dev_base_lock);
 			break;
@@ -3115,6 +3141,9 @@
 	INIT_LIST_HEAD(&ptype_all);
 	for (i = 0; i < 16; i++) 
 		INIT_LIST_HEAD(&ptype_base[i]);
+
+	for (i = 0; i < ARRAY_SIZE(dev_name_head); i++)
+		INIT_HLIST_HEAD(&dev_name_head[i]);
 
 	/*
 	 *	Initialise the packet receive queues.

From davem@redhat.com Fri Feb  6 13:39:31 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 13:39:34 -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 i16LdUKO015636
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 13:39:30 -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 i16LdRb16134;
	Fri, 6 Feb 2004 16:39:27 -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 i16LdRa02524;
	Fri, 6 Feb 2004 16:39:27 -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 i16LctkC012919;
	Fri, 6 Feb 2004 16:38:56 -0500
Date: Fri, 6 Feb 2004 13:39:26 -0800
From: "David S. Miller" <davem@redhat.com>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH] (1/4) Support for lots of netdev's -- dev_base move
Message-Id: <20040206133926.29344238.davem@redhat.com>
In-Reply-To: <20040206100310.21ebd1da.shemminger@osdl.org>
References: <20040206100310.21ebd1da.shemminger@osdl.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=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 3053
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, 6 Feb 2004 10:03:10 -0800
Stephen Hemminger <shemminger@osdl.org> wrote:

> The first patch moves the device list and locks from drivers/net/Space.c
> to net/core/dev.c. The list used to be in Space.c because we initialized it
> in 2.4, but now it makes more sense to put it over with the management
> routines.

Applied.

I hope we can eventually mark these two things static somehow.  I know
there's a lot needed to do that, so not now just eventually.

Thanks Stephen.

From davem@redhat.com Fri Feb  6 13:44:55 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 13:44: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 i16LitKO016102
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 13:44: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 i16LiQb18857;
	Fri, 6 Feb 2004 16:44:26 -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 i16LiPa04737;
	Fri, 6 Feb 2004 16:44:25 -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 i16LhskC016293;
	Fri, 6 Feb 2004 16:43:54 -0500
Date: Fri, 6 Feb 2004 13:44:25 -0800
From: "David S. Miller" <davem@redhat.com>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH] (3/4) Support lots of netdev's -- hash ifindex
Message-Id: <20040206134425.50577b1d.davem@redhat.com>
In-Reply-To: <20040206100501.6ffcfa8a.shemminger@osdl.org>
References: <20040206100501.6ffcfa8a.shemminger@osdl.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=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 3054
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, 6 Feb 2004 10:05:01 -0800
Stephen Hemminger <shemminger@osdl.org> wrote:

> Hash network device index entries, to allow fast lookup by routing
> protocols.

Ok, I am applying this and the hash netdev by name patch.

I was going to allocate the tables at run time, not put them
into the image but since these go into the BSS it's not such
a big deal after all.

Thanks Stephen.

From davem@redhat.com Fri Feb  6 14:38:04 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 14:38:08 -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 i16Mc4KO017495
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 14:38: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 i16Mbwb11483;
	Fri, 6 Feb 2004 17:37:58 -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 i16Mbwa24601;
	Fri, 6 Feb 2004 17:37:58 -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 i16MbRkC021233;
	Fri, 6 Feb 2004 17:37:27 -0500
Date: Fri, 6 Feb 2004 14:37:57 -0800
From: "David S. Miller" <davem@redhat.com>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH] (4/4) Support for lots of netdev's -- faster
 dev_alloc_name
Message-Id: <20040206143757.53cd8adb.davem@redhat.com>
In-Reply-To: <20040206101232.46bc30b1.shemminger@osdl.org>
References: <20040206101232.46bc30b1.shemminger@osdl.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=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 3055
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, 6 Feb 2004 10:12:32 -0800
Stephen Hemminger <shemminger@osdl.org> wrote:

> Convert dev_alloc_name from O(n^2) lookup to O(n) by using a page as
> bitmap to figure out how many devices of that pattern have been allocated.
> This works for up to 32k devices (PAGE_SIZE*8) on i386, more on other
> platforms.  Correctly handles the boundary cases where number of devices
> won't fit because name length is limited.
> 
> Adds strnchr to the string libraries since we need to find the % format
> character, but only care if it is in the first 15 bytes.

Ok, applied, thanks Stephen.

From romieu@fr.zoreil.com Fri Feb  6 15:20:18 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 15:20: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 i16NKGKO018691
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 15:20:17 -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 i16NHwgf031725;
	Sat, 7 Feb 2004 00:17:58 +0100
Received: (from romieu@localhost)
	by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i16NHuMu031724;
	Sat, 7 Feb 2004 00:17:56 +0100
Date: Sat, 7 Feb 2004 00:17:56 +0100
From: Francois Romieu <romieu@fr.zoreil.com>
To: Michael Neuffer <neuffer@neuffer.info>
Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, shuchen@realtek.com.tw
Subject: Re: of 2.6.2-rc2-mm2 and r8169
Message-ID: <20040207001756.A26645@electric-eye.fr.zoreil.com>
References: <20040130014108.09c964fd.akpm@osdl.org> <20040201100340.GA12436@neuffer.info>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20040201100340.GA12436@neuffer.info>; from neuffer@neuffer.info on Sun, Feb 01, 2004 at 11:03:40AM +0100
X-Organisation: Land of Sunshine Inc.
X-archive-position: 3056
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

Michael Neuffer <neuffer@neuffer.info> :
[...]
> After many tests I was finally able to capture an Oops:
> Oops: 0000 [#1]
> PREEMPT

If you need to see it work better, I would suggest to disable PREEMPT/SMP.

Could you send me the faulty r8169.o module off-list as well as an lsmod, an
output of the /proc/interrupts and a dmesg from boot ?

--
Ueimor

From marcel@holtmann.org Fri Feb  6 15:30:39 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 15:30:42 -0800 (PST)
Received: from mail.holtmann.net (root@linux-bt.org [217.160.111.169])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i16NUbKO019316
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 15:30:38 -0800
Received: from pegasus (pD95257EB.dip.t-dialin.net [217.82.87.235])
	by mail.holtmann.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i16NV4V4006485;
	Sat, 7 Feb 2004 00:31:04 +0100
Subject: Re: some bluetooth fixes
From: Marcel Holtmann <marcel@holtmann.org>
To: Andi Kleen <ak@suse.de>
Cc: bluez-devel@lists.sourceforge.net, netdev@oss.sgi.com,
        viro@zenII.linux.org.uk
In-Reply-To: <20040206050042.20a2b3b0.ak@suse.de>
References: <20040206050042.20a2b3b0.ak@suse.de>
Content-Type: text/plain
Message-Id: <1076110207.14418.53.camel@pegasus>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Sat, 07 Feb 2004 00:30:08 +0100
Content-Transfer-Encoding: 7bit
X-archive-position: 3058
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: marcel@holtmann.org
Precedence: bulk
X-list: netdev

Hi Andi,

> diff -u linux-2.6.2-work32/net/bluetooth/rfcomm/tty.c-o linux-2.6.2-work32/net/bluetooth/rfcomm/tty.c
> --- linux-2.6.2-work32/net/bluetooth/rfcomm/tty.c-o	2003-09-28 10:53:25.000000000 +0200
> +++ linux-2.6.2-work32/net/bluetooth/rfcomm/tty.c	2004-02-06 04:58:28.000000000 +0100
> @@ -549,8 +549,10 @@
>  
>  	BT_DBG("dev %p dst %s channel %d opened %d", dev, batostr(&dev->dst), dev->channel, dev->opened);
>  
> -	if (dev->opened++ != 0)
> +	if (dev->opened++ != 0) {
> +		rfcomm_dev_put(dev);
>  		return 0;
> +	}
>  
>  	dlc = dev->dlc;

this part is wrong, because it is not an error case. It is success and
the refcount must stay increased.

Regards

Marcel



From davem@redhat.com Fri Feb  6 15:30:20 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 15:30:33 -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 i16NUJKO019290
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 15:30: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 i16NUFb01635;
	Fri, 6 Feb 2004 18:30: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 i16NUFa09914;
	Fri, 6 Feb 2004 18:30:15 -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 i16NTikC008240;
	Fri, 6 Feb 2004 18:29:44 -0500
Date: Fri, 6 Feb 2004 15:30:14 -0800
From: "David S. Miller" <davem@redhat.com>
To: yoshfuji@linux-ipv6.org
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH 1/3] IPV6: clean-up DAD vs tentative address
Message-Id: <20040206153014.61b5286d.davem@redhat.com>
In-Reply-To: <20040206.181003.68972716.yoshfuji@linux-ipv6.org>
References: <20040206.181003.68972716.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 i16NUJKO019290
X-archive-position: 3057
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, 06 Feb 2004 18:10:03 +0900 (JST)
YOSHIFUJI Hideaki / $B5HF#1QL@(B <yoshfuji@linux-ipv6.org> wrote:

> [PATCH 1/3] IPV6: clean-up DAD vs tentative address
> 
> D: clean-up NS (including DAD) vs tentative address

Applied, thanks Yoshfuji.


From davem@redhat.com Fri Feb  6 15:32:08 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 15:32: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 i16NW7KO020028
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 15:32:07 -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 i16NW2b02702;
	Fri, 6 Feb 2004 18:32:02 -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 i16NW2a10895;
	Fri, 6 Feb 2004 18:32:02 -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 i16NVUkC009328;
	Fri, 6 Feb 2004 18:31:31 -0500
Date: Fri, 6 Feb 2004 15:32:01 -0800
From: "David S. Miller" <davem@redhat.com>
To: yoshfuji@linux-ipv6.org
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH 2/3] IPV6: unify 3 similar code path in ndisc_recv_ns()
Message-Id: <20040206153201.126c88b8.davem@redhat.com>
In-Reply-To: <20040206.181006.79694138.yoshfuji@linux-ipv6.org>
References: <20040206.181006.79694138.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 i16NW7KO020028
X-archive-position: 3059
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, 06 Feb 2004 18:10:06 +0900 (JST)
YOSHIFUJI Hideaki / $B5HF#1QL@(B <yoshfuji@linux-ipv6.org> wrote:

> [PATCH 2/3] IPV6: unify 3 similar code path in ndisc_recv_ns()
> 
> D: Unify 3 similar code path in ndisc_recv_ns().
> D: This patch also fixes:
> D:  - flags sent with NA in reply to this NS
> D:  - missing random delay after receipt of NS against anycast

Very nice consolidation of code.

Applied, thanks Yoshfuji.


From davem@redhat.com Fri Feb  6 15:33:25 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 15:33:28 -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 i16NXOKO020416
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 15:33:24 -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 i16NXMb03292;
	Fri, 6 Feb 2004 18:33:22 -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 i16NXMa11328;
	Fri, 6 Feb 2004 18:33:22 -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 i16NWokC009633;
	Fri, 6 Feb 2004 18:32:51 -0500
Date: Fri, 6 Feb 2004 15:33:21 -0800
From: "David S. Miller" <davem@redhat.com>
To: yoshfuji@linux-ipv6.org
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH 3/3] IPV6: use cheaper ipv6_addr_any() where appropriate
Message-Id: <20040206153321.07ca91b0.davem@redhat.com>
In-Reply-To: <20040206.181014.40584753.yoshfuji@linux-ipv6.org>
References: <20040206.181014.40584753.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 i16NXOKO020416
X-archive-position: 3060
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, 06 Feb 2004 18:10:14 +0900 (JST)
YOSHIFUJI Hideaki / $B5HF#1QL@(B <yoshfuji@linux-ipv6.org> wrote:

> [PATCH 3/3] IPV6: use cheaper ipv6_addr_any() where appropriate
> 
> D: Use cheaper ipv6_addr_any() where appropriate.

Also applied.  Guess you didn't get all of these cases the other
week when you were making similar changes. :-)

Thanks.


From davem@redhat.com Fri Feb  6 15:34:09 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 15:34:12 -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 i16NY8KO020720
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 15:34: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 i16NY3b03586;
	Fri, 6 Feb 2004 18:34:03 -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 i16NY3a11579;
	Fri, 6 Feb 2004 18:34:03 -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 i16NXVkC009921;
	Fri, 6 Feb 2004 18:33:31 -0500
Date: Fri, 6 Feb 2004 15:34:01 -0800
From: "David S. Miller" <davem@redhat.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: ak@suse.de, bluez-devel@lists.sourceforge.net, netdev@oss.sgi.com,
        viro@zenII.linux.org.uk
Subject: Re: some bluetooth fixes
Message-Id: <20040206153401.49238aa2.davem@redhat.com>
In-Reply-To: <1076110207.14418.53.camel@pegasus>
References: <20040206050042.20a2b3b0.ak@suse.de>
	<1076110207.14418.53.camel@pegasus>
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: 3061
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


Marcelo/Andi, I assume you guys will work things out and send
me a final patch?

Thanks.

From marcel@holtmann.org Fri Feb  6 15:46:43 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 15:46:46 -0800 (PST)
Received: from mail.holtmann.net (root@linux-bt.org [217.160.111.169])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i16NkeKO022788
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 15:46:43 -0800
Received: from pegasus (pD95257EB.dip.t-dialin.net [217.82.87.235])
	by mail.holtmann.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i16Nl2V4006634;
	Sat, 7 Feb 2004 00:47:07 +0100
Subject: Re: some bluetooth fixes
From: Marcel Holtmann <marcel@holtmann.org>
To: "David S. Miller" <davem@redhat.com>
Cc: ak@suse.de, BlueZ Mailing List <bluez-devel@lists.sourceforge.net>,
        netdev@oss.sgi.com, viro@zenII.linux.org.uk
In-Reply-To: <20040206153401.49238aa2.davem@redhat.com>
References: <20040206050042.20a2b3b0.ak@suse.de>
	 <1076110207.14418.53.camel@pegasus>
	 <20040206153401.49238aa2.davem@redhat.com>
Content-Type: text/plain
Message-Id: <1076111165.14418.62.camel@pegasus>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Sat, 07 Feb 2004 00:46:05 +0100
Content-Transfer-Encoding: 7bit
X-archive-position: 3062
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: marcel@holtmann.org
Precedence: bulk
X-list: netdev

Hi Dave,

> Marcelo/Andi, I assume you guys will work things out and send
> me a final patch?

I already splitted Andi's patch into smaller parts and I wait for the
answers to my questions. I also have some other fixes in the queue, so
you will get a number of patches ;)

Regards

Marcel



From davem@redhat.com Fri Feb  6 16:04:36 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 16:04:39 -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 i1704ZKO023293
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 16:04:36 -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 i1704Nb15313;
	Fri, 6 Feb 2004 19:04:23 -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 i1704Na20205;
	Fri, 6 Feb 2004 19:04:23 -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 i1703pkC021190;
	Fri, 6 Feb 2004 19:03:52 -0500
Date: Fri, 6 Feb 2004 16:04:22 -0800
From: "David S. Miller" <davem@redhat.com>
To: Shmuel Hen <shmulik.hen@intel.com>
Cc: netdev@oss.sgi.com, jgarzik@pobox.com
Subject: Re: [PATCH] [NET] split arp_send into arp_create and arp_xmit
 (resend)
Message-Id: <20040206160422.018955f3.davem@redhat.com>
In-Reply-To: <200402051559.10075.shmulik.hen@intel.com>
References: <200402051559.10075.shmulik.hen@intel.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: 3063
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 Thu, 5 Feb 2004 15:58:56 +0200
Shmuel Hen <shmulik.hen@intel.com> wrote:

> 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.

Applied, thanks Shmuel.

From davem@redhat.com Fri Feb  6 16:25:40 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 16:25: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 i170PeKO026813
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 16:25: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 i170Pcb22827;
	Fri, 6 Feb 2004 19:25:38 -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 i170Pca25137;
	Fri, 6 Feb 2004 19:25:38 -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 i170P6kC026243;
	Fri, 6 Feb 2004 19:25:07 -0500
Date: Fri, 6 Feb 2004 16:25:37 -0800
From: "David S. Miller" <davem@redhat.com>
To: Shmuel Hen <shmulik.hen@intel.com>
Cc: netdev@oss.sgi.com, jgarzik@pobox.com
Subject: Re: [PATCH] [8021q] Use VLAN tag set functionality in 8021q module
 (resend)
Message-Id: <20040206162537.7f314569.davem@redhat.com>
In-Reply-To: <200402051559.45159.shmulik.hen@intel.com>
References: <200402051559.45159.shmulik.hen@intel.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: 3065
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 Thu, 5 Feb 2004 15:59:43 +0200
Shmuel Hen <shmulik.hen@intel.com> wrote:

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

Also applied, thanks.

From davem@redhat.com Fri Feb  6 16:25:23 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 16:25: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 i170PMKO026760
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 16:25:23 -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 i170PLb22709;
	Fri, 6 Feb 2004 19:25:21 -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 i170PLa25038;
	Fri, 6 Feb 2004 19:25:21 -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 i170OnkC026072;
	Fri, 6 Feb 2004 19:24:49 -0500
Date: Fri, 6 Feb 2004 16:25:20 -0800
From: "David S. Miller" <davem@redhat.com>
To: Shmuel Hen <shmulik.hen@intel.com>
Cc: netdev@oss.sgi.com, jgarzik@pobox.com
Subject: Re: [PATCH] [8021q] Export VLAN tag get/set functionality (resend)
Message-Id: <20040206162520.308c523d.davem@redhat.com>
In-Reply-To: <200402051559.27597.shmulik.hen@intel.com>
References: <200402051559.27597.shmulik.hen@intel.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: 3064
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 Thu, 5 Feb 2004 15:59:22 +0200
Shmuel Hen <shmulik.hen@intel.com> wrote:

> 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.

Applied.

From dlstevens@us.ibm.com Fri Feb  6 17:01:54 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 17:01:58 -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 i1711lKO030159
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 17:01:54 -0800
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i1711etv490312;
	Fri, 6 Feb 2004 20:01:40 -0500
Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1711dbP108504;
	Fri, 6 Feb 2004 18:01:39 -0700
In-Reply-To: <20040115221841.7e7cc78d%hibi665@oki.com>
Subject: Re: Source Specific Query of MLDv2 [PATCH]
To: Takashi Hibi <hibi665@oki.com>
Cc: netdev@oss.sgi.com, davem@redhat.com
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFABEBA675.68903615-ON88256E33.000504D4-88256E33.0005673C@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Fri, 6 Feb 2004 18:01:37 -0700
X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November
 14, 2003) at 02/06/2004 18:01:39
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=07BBE4A0DF9682448f9e8a93df938690918c07BBE4A0DF968244"
X-archive-position: 3066
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__=07BBE4A0DF9682448f9e8a93df938690918c07BBE4A0DF968244
Content-type: multipart/alternative; 
	Boundary="1__=07BBE4A0DF9682448f9e8a93df938690918c07BBE4A0DF968244"

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





Takashi,
      Below is a patch that allows MLD ICMP types without
applying the interface filters to them.

                              +-DLS
[in-line & attached]

diff -ruN linux-2.6.2/include/net/addrconf.h linux-2.6.2F1/include/net/addrconf.h
--- linux-2.6.2/include/net/addrconf.h    2004-02-03 19:44:17.000000000 -0800
+++ linux-2.6.2F1/include/net/addrconf.h  2004-02-06 16:03:34.000000000 -0800
@@ -98,6 +98,7 @@

 extern int ipv6_chk_mcast_addr(struct net_device *dev, struct in6_addr *group,
            struct in6_addr *src_addr);
+extern int is_mld(struct sk_buff *skb);

 extern void addrconf_prefix_rcv(struct net_device *dev, u8 *opt, int len);

diff -ruN linux-2.6.2/net/ipv6/ip6_input.c linux-2.6.2F1/net/ipv6/ip6_input.c
--- linux-2.6.2/net/ipv6/ip6_input.c      2004-02-03 19:44:14.000000000 -0800
+++ linux-2.6.2F1/net/ipv6/ip6_input.c    2004-02-06 16:04:00.000000000 -0800
@@ -168,11 +168,19 @@

            smp_read_barrier_depends();
            if (ipprot->flags & INET6_PROTO_FINAL) {
+                 struct ipv6hdr *hdr;
+
                  if (!cksum_sub && skb->ip_summed == CHECKSUM_HW) {
                        skb->csum = csum_sub(skb->csum,
                                         csum_partial(skb->nh.raw, skb->h.raw-skb->nh.raw, 0));
                        cksum_sub++;
                  }
+                 hdr = skb->nh.ipv6h;
+                 if (ipv6_addr_is_multicast(&hdr->daddr) &&
+                     !ipv6_chk_mcast_addr(skb->dev, &hdr->daddr,
+                     &hdr->saddr) &&
+                     !is_mld(skb))
+                       goto discard;
            }
            if (!(ipprot->flags & INET6_PROTO_NOPOLICY) &&
                !xfrm6_policy_check(NULL, XFRM_POLICY_IN, skb))
@@ -211,16 +219,11 @@

 int ip6_mc_input(struct sk_buff *skb)
 {
-     struct ipv6hdr *hdr;
-     int deliver = 0;
+     int deliver = 1;
      int discard = 1;

      IP6_INC_STATS_BH(Ip6InMcastPkts);

-     hdr = skb->nh.ipv6h;
-     if (ipv6_chk_mcast_addr(skb->dev, &hdr->daddr, &hdr->saddr))
-           deliver = 1;
-
      /*
       *    IPv6 multicast router mode isnt currently supported.
       */
diff -ruN linux-2.6.2/net/ipv6/mcast.c linux-2.6.2F1/net/ipv6/mcast.c
--- linux-2.6.2/net/ipv6/mcast.c    2004-02-03 19:44:28.000000000 -0800
+++ linux-2.6.2F1/net/ipv6/mcast.c  2004-02-06 16:04:25.000000000 -0800
@@ -901,6 +901,25 @@
 }

 /*
+ * identify MLD packets for MLD filter exceptions
+ */
+int is_mld(struct sk_buff *skb)
+{
+     struct icmp6hdr *pic = (struct icmp6hdr *)skb->h.raw;
+
+     switch (pic->icmp6_type) {
+     case ICMPV6_MGM_QUERY:
+     case ICMPV6_MGM_REPORT:
+     case ICMPV6_MGM_REDUCTION:
+     case ICMPV6_MLD2_REPORT:
+           return 1;
+     default:
+           break;
+     }
+     return 0;
+}
+
+/*
  *   check if the interface/address pair is valid
  */
 int ipv6_chk_mcast_addr(struct net_device *dev, struct in6_addr *group,

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

<html><body>
<p>Takashi,<br>
	Below is a patch that allows MLD ICMP types without<br>
applying the interface filters to them. <br>
<br>
					+-DLS<br>
[in-line &amp; attached]<br>
<br>
diff -ruN linux-2.6.2/include/net/addrconf.h linux-2.6.2F1/include/net/addrconf.h<br>
--- linux-2.6.2/include/net/addrconf.h	2004-02-03 19:44:17.000000000 -0800<br>
+++ linux-2.6.2F1/include/net/addrconf.h	2004-02-06 16:03:34.000000000 -0800<br>
@@ -98,6 +98,7 @@<br>
 <br>
 extern int ipv6_chk_mcast_addr(struct net_device *dev, struct in6_addr *group,<br>
 		struct in6_addr *src_addr);<br>
+extern int is_mld(struct sk_buff *skb);<br>
 <br>
 extern void addrconf_prefix_rcv(struct net_device *dev, u8 *opt, int len);<br>
 <br>
diff -ruN linux-2.6.2/net/ipv6/ip6_input.c linux-2.6.2F1/net/ipv6/ip6_input.c<br>
--- linux-2.6.2/net/ipv6/ip6_input.c	2004-02-03 19:44:14.000000000 -0800<br>
+++ linux-2.6.2F1/net/ipv6/ip6_input.c	2004-02-06 16:04:00.000000000 -0800<br>
@@ -168,11 +168,19 @@<br>
 		<br>
 		smp_read_barrier_depends();<br>
 		if (ipprot-&gt;flags &amp; INET6_PROTO_FINAL) {<br>
+			struct ipv6hdr *hdr;	<br>
+<br>
 			if (!cksum_sub &amp;&amp; skb-&gt;ip_summed == CHECKSUM_HW) {<br>
 				skb-&gt;csum = csum_sub(skb-&gt;csum,<br>
 						     csum_partial(skb-&gt;nh.raw, skb-&gt;h.raw-skb-&gt;nh.raw, 0));<br>
 				cksum_sub++;<br>
 			}<br>
+			hdr = skb-&gt;nh.ipv6h;<br>
+			if (ipv6_addr_is_multicast(&amp;hdr-&gt;daddr) &amp;&amp;<br>
+			    !ipv6_chk_mcast_addr(skb-&gt;dev, &amp;hdr-&gt;daddr,<br>
+			    &amp;hdr-&gt;saddr) &amp;&amp;<br>
+			    !is_mld(skb))<br>
+				goto discard;<br>
 		}<br>
 		if (!(ipprot-&gt;flags &amp; INET6_PROTO_NOPOLICY) &amp;&amp;<br>
 		    !xfrm6_policy_check(NULL, XFRM_POLICY_IN, skb)) <br>
@@ -211,16 +219,11 @@<br>
 <br>
 int ip6_mc_input(struct sk_buff *skb)<br>
 {<br>
-	struct ipv6hdr *hdr;	<br>
-	int deliver = 0;<br>
+	int deliver = 1;<br>
 	int discard = 1;<br>
 <br>
 	IP6_INC_STATS_BH(Ip6InMcastPkts);<br>
 <br>
-	hdr = skb-&gt;nh.ipv6h;<br>
-	if (ipv6_chk_mcast_addr(skb-&gt;dev, &amp;hdr-&gt;daddr, &amp;hdr-&gt;saddr))<br>
-		deliver = 1;<br>
-<br>
 	/*<br>
 	 *	IPv6 multicast router mode isnt currently supported.<br>
 	 */<br>
diff -ruN linux-2.6.2/net/ipv6/mcast.c linux-2.6.2F1/net/ipv6/mcast.c<br>
--- linux-2.6.2/net/ipv6/mcast.c	2004-02-03 19:44:28.000000000 -0800<br>
+++ linux-2.6.2F1/net/ipv6/mcast.c	2004-02-06 16:04:25.000000000 -0800<br>
@@ -901,6 +901,25 @@<br>
 }<br>
 <br>
 /*<br>
+ * identify MLD packets for MLD filter exceptions<br>
+ */<br>
+int is_mld(struct sk_buff *skb)<br>
+{<br>
+	struct icmp6hdr *pic = (struct icmp6hdr *)skb-&gt;h.raw;<br>
+<br>
+	switch (pic-&gt;icmp6_type) {<br>
+	case ICMPV6_MGM_QUERY:<br>
+	case ICMPV6_MGM_REPORT:<br>
+	case ICMPV6_MGM_REDUCTION:<br>
+	case ICMPV6_MLD2_REPORT:<br>
+		return 1;<br>
+	default:<br>
+		break;<br>
+	}<br>
+	return 0;<br>
+}<br>
+<br>
+/*<br>
  *	check if the interface/address pair is valid<br>
  */<br>
 int ipv6_chk_mcast_addr(struct net_device *dev, struct in6_addr *group,<br>
<br>
<i>(See attached file: mldx.patch)</i><br>
</body></html>

--1__=07BBE4A0DF9682448f9e8a93df938690918c07BBE4A0DF968244--


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

ZGlmZiAtcnVOIGxpbnV4LTIuNi4yL2luY2x1ZGUvbmV0L2FkZHJjb25mLmggbGludXgtMi42LjJG
MS9pbmNsdWRlL25ldC9hZGRyY29uZi5oCi0tLSBsaW51eC0yLjYuMi9pbmNsdWRlL25ldC9hZGRy
Y29uZi5oCTIwMDQtMDItMDMgMTk6NDQ6MTcuMDAwMDAwMDAwIC0wODAwCisrKyBsaW51eC0yLjYu
MkYxL2luY2x1ZGUvbmV0L2FkZHJjb25mLmgJMjAwNC0wMi0wNiAxNjowMzozNC4wMDAwMDAwMDAg
LTA4MDAKQEAgLTk4LDYgKzk4LDcgQEAKIAogZXh0ZXJuIGludCBpcHY2X2Noa19tY2FzdF9hZGRy
KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIHN0cnVjdCBpbjZfYWRkciAqZ3JvdXAsCiAJCXN0cnVj
dCBpbjZfYWRkciAqc3JjX2FkZHIpOworZXh0ZXJuIGludCBpc19tbGQoc3RydWN0IHNrX2J1ZmYg
KnNrYik7CiAKIGV4dGVybiB2b2lkIGFkZHJjb25mX3ByZWZpeF9yY3Yoc3RydWN0IG5ldF9kZXZp
Y2UgKmRldiwgdTggKm9wdCwgaW50IGxlbik7CiAKZGlmZiAtcnVOIGxpbnV4LTIuNi4yL25ldC9p
cHY2L2lwNl9pbnB1dC5jIGxpbnV4LTIuNi4yRjEvbmV0L2lwdjYvaXA2X2lucHV0LmMKLS0tIGxp
bnV4LTIuNi4yL25ldC9pcHY2L2lwNl9pbnB1dC5jCTIwMDQtMDItMDMgMTk6NDQ6MTQuMDAwMDAw
MDAwIC0wODAwCisrKyBsaW51eC0yLjYuMkYxL25ldC9pcHY2L2lwNl9pbnB1dC5jCTIwMDQtMDIt
MDYgMTY6MDQ6MDAuMDAwMDAwMDAwIC0wODAwCkBAIC0xNjgsMTEgKzE2OCwxOSBAQAogCQkKIAkJ
c21wX3JlYWRfYmFycmllcl9kZXBlbmRzKCk7CiAJCWlmIChpcHByb3QtPmZsYWdzICYgSU5FVDZf
UFJPVE9fRklOQUwpIHsKKwkJCXN0cnVjdCBpcHY2aGRyICpoZHI7CQorCiAJCQlpZiAoIWNrc3Vt
X3N1YiAmJiBza2ItPmlwX3N1bW1lZCA9PSBDSEVDS1NVTV9IVykgewogCQkJCXNrYi0+Y3N1bSA9
IGNzdW1fc3ViKHNrYi0+Y3N1bSwKIAkJCQkJCSAgICAgY3N1bV9wYXJ0aWFsKHNrYi0+bmgucmF3
LCBza2ItPmgucmF3LXNrYi0+bmgucmF3LCAwKSk7CiAJCQkJY2tzdW1fc3ViKys7CiAJCQl9CisJ
CQloZHIgPSBza2ItPm5oLmlwdjZoOworCQkJaWYgKGlwdjZfYWRkcl9pc19tdWx0aWNhc3QoJmhk
ci0+ZGFkZHIpICYmCisJCQkgICAgIWlwdjZfY2hrX21jYXN0X2FkZHIoc2tiLT5kZXYsICZoZHIt
PmRhZGRyLAorCQkJICAgICZoZHItPnNhZGRyKSAmJgorCQkJICAgICFpc19tbGQoc2tiKSkKKwkJ
CQlnb3RvIGRpc2NhcmQ7CiAJCX0KIAkJaWYgKCEoaXBwcm90LT5mbGFncyAmIElORVQ2X1BST1RP
X05PUE9MSUNZKSAmJgogCQkgICAgIXhmcm02X3BvbGljeV9jaGVjayhOVUxMLCBYRlJNX1BPTElD
WV9JTiwgc2tiKSkgCkBAIC0yMTEsMTYgKzIxOSwxMSBAQAogCiBpbnQgaXA2X21jX2lucHV0KHN0
cnVjdCBza19idWZmICpza2IpCiB7Ci0Jc3RydWN0IGlwdjZoZHIgKmhkcjsJCi0JaW50IGRlbGl2
ZXIgPSAwOworCWludCBkZWxpdmVyID0gMTsKIAlpbnQgZGlzY2FyZCA9IDE7CiAKIAlJUDZfSU5D
X1NUQVRTX0JIKElwNkluTWNhc3RQa3RzKTsKIAotCWhkciA9IHNrYi0+bmguaXB2Nmg7Ci0JaWYg
KGlwdjZfY2hrX21jYXN0X2FkZHIoc2tiLT5kZXYsICZoZHItPmRhZGRyLCAmaGRyLT5zYWRkcikp
Ci0JCWRlbGl2ZXIgPSAxOwotCiAJLyoKIAkgKglJUHY2IG11bHRpY2FzdCByb3V0ZXIgbW9kZSBp
c250IGN1cnJlbnRseSBzdXBwb3J0ZWQuCiAJICovCmRpZmYgLXJ1TiBsaW51eC0yLjYuMi9uZXQv
aXB2Ni9tY2FzdC5jIGxpbnV4LTIuNi4yRjEvbmV0L2lwdjYvbWNhc3QuYwotLS0gbGludXgtMi42
LjIvbmV0L2lwdjYvbWNhc3QuYwkyMDA0LTAyLTAzIDE5OjQ0OjI4LjAwMDAwMDAwMCAtMDgwMAor
KysgbGludXgtMi42LjJGMS9uZXQvaXB2Ni9tY2FzdC5jCTIwMDQtMDItMDYgMTY6MDQ6MjUuMDAw
MDAwMDAwIC0wODAwCkBAIC05MDEsNiArOTAxLDI1IEBACiB9CiAKIC8qCisgKiBpZGVudGlmeSBN
TEQgcGFja2V0cyBmb3IgTUxEIGZpbHRlciBleGNlcHRpb25zCisgKi8KK2ludCBpc19tbGQoc3Ry
dWN0IHNrX2J1ZmYgKnNrYikKK3sKKwlzdHJ1Y3QgaWNtcDZoZHIgKnBpYyA9IChzdHJ1Y3QgaWNt
cDZoZHIgKilza2ItPmgucmF3OworCisJc3dpdGNoIChwaWMtPmljbXA2X3R5cGUpIHsKKwljYXNl
IElDTVBWNl9NR01fUVVFUlk6CisJY2FzZSBJQ01QVjZfTUdNX1JFUE9SVDoKKwljYXNlIElDTVBW
Nl9NR01fUkVEVUNUSU9OOgorCWNhc2UgSUNNUFY2X01MRDJfUkVQT1JUOgorCQlyZXR1cm4gMTsK
KwlkZWZhdWx0OgorCQlicmVhazsKKwl9CisJcmV0dXJuIDA7Cit9CisKKy8qCiAgKgljaGVjayBp
ZiB0aGUgaW50ZXJmYWNlL2FkZHJlc3MgcGFpciBpcyB2YWxpZAogICovCiBpbnQgaXB2Nl9jaGtf
bWNhc3RfYWRkcihzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgaW42X2FkZHIgKmdyb3Vw
LAo=

--0__=07BBE4A0DF9682448f9e8a93df938690918c07BBE4A0DF968244--


From sri@us.ibm.com Fri Feb  6 17:24:46 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 17:24:49 -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 i171OdKO032321
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 17:24:46 -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 i171OYtv453074;
	Fri, 6 Feb 2004 20:24:34 -0500
Received: from w-sridhar.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 i171OWcb134428;
	Fri, 6 Feb 2004 18:24:33 -0700
Date: Fri, 6 Feb 2004 17:24:32 -0800 (PST)
From: Sridhar Samudrala <sri@us.ibm.com>
X-X-Sender: sridhar@localhost.localdomain
To: davem@redhat.com
cc: netdev@oss.sgi.com
Subject: [BK PATCH] 2.6.2 SCTP updates
Message-ID: <Pine.LNX.4.58.0402061649001.10831@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 3067
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

Hi Dave,

Please do a
	bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work
to get the following udpates to SCTP on top of linux 2.6.2

These csets include fixes for a couple of issues that were reported by
SCTP users.
- Removed deprecated ADLER32 checksum support as it is unexpectedly
  getting selected in certain configurations (ex: allyesconfig) and we
  no longer need to support it.
- Updated the default max socket receive buffer to 64K from 32K and also
  added sysctl variables to change sctp socket send/receive buffers.

# This patch includes the following deltas:
#	           ChangeSet	1.1548  -> 1.1550
#	net/sctp/associola.c	1.64    -> 1.65
#	net/sctp/endpointola.c	1.29    -> 1.30
#	    net/sctp/Kconfig	1.7     -> 1.8
#	include/net/sctp/constants.h	1.17    -> 1.18
#	   net/sctp/sysctl.c	1.15    -> 1.16
#	include/linux/sysctl.h	1.57    -> 1.58
#	 net/sctp/protocol.c	1.59    -> 1.61
#	  net/sctp/adler32.c	1.8     ->         (deleted)
#	 net/sctp/ulpqueue.c	1.26    -> 1.27
#	include/net/sctp/structs.h	1.78    -> 1.79
#	   net/sctp/Makefile	1.9     -> 1.10
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
ChangeSet@1.1550, 2004-02-05 13:58:37-08:00, sri@us.ibm.com
  [SCTP] Removed the deprecated ADLER32 checksum support.

ChangeSet@1.1474.108.5, 2004-01-23 14:58:38-08:00, sri@us.ibm.com
  [SCTP] Add sysctl parameters to update socket send/receive buffers.

ChangeSet@1.1474.108.4, 2004-01-19 11:12:44-08:00, sri@us.ibm.com
  [SCTP] provide valid tos and oif values for ip_route_output_key. (ja@ssi.bg)

Thanks
Sridhar

From ak@suse.de Fri Feb  6 18:26:22 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 18:26:25 -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 i172QLKO000948
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 18:26:21 -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 46F021639B2; Sat,  7 Feb 2004 03:24:30 +0100 (CET)
Date: Sat, 7 Feb 2004 03:24:28 +0100
From: Andi Kleen <ak@suse.de>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: bluez-devel@lists.sourceforge.net, netdev@oss.sgi.com,
        viro@zenII.linux.org.uk
Subject: Re: some bluetooth fixes
Message-Id: <20040207032428.56ffbebc.ak@suse.de>
In-Reply-To: <1076079512.2806.40.camel@pegasus>
References: <20040206050042.20a2b3b0.ak@suse.de>
	<1076079512.2806.40.camel@pegasus>
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: 3068
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 Fri, 06 Feb 2004 15:58:32 +0100
Marcel Holtmann <marcel@holtmann.org> wrote:

> Hi Andi,
> 
> > While reading bluetooth code I noticed some bugs and potential overflows.
> > 
> > Also I commented one ref-counting bug.
> > 
> > Patch against 2.6.2.
> 
> thanks for looking at it. Same applies to 2.4, right?

Probably. I haven't looked at 2.4.

> > diff -u linux-2.6.2-work32/net/bluetooth/hci_sock.c-o linux-2.6.2-work32/net/bluetooth/hci_sock.c
> > --- linux-2.6.2-work32/net/bluetooth/hci_sock.c-o	2004-02-05 08:09:54.000000000 +0100
> > +++ linux-2.6.2-work32/net/bluetooth/hci_sock.c	2004-02-05 14:57:59.000000000 +0100
> > @@ -392,6 +392,8 @@
> >  
> >  	skb->pkt_type = *((unsigned char *) skb->data);
> >  	skb_pull(skb, 1);
> > +	/* AK: looks broken. Who guarantees that hdev doesn't go away while
> > +	   the skb is queued ? */
> >  	skb->dev = (void *) hdev;
> >  
> >  	if (skb->pkt_type == HCI_COMMAND_PKT) {
> 
> Why should hdev go away?


Because the skbuff is queued, but there is no reference count to keep the device around.
I wasn't 100% sure on that, so I just commented it. Feel free to remove if you think
it's correct.

> > diff -u linux-2.6.2-work32/net/bluetooth/hci_conn.c-o linux-2.6.2-work32/net/bluetooth/hci_conn.c
> > --- linux-2.6.2-work32/net/bluetooth/hci_conn.c-o	2004-02-05 08:09:54.000000000 +0100
> > +++ linux-2.6.2-work32/net/bluetooth/hci_conn.c	2004-02-05 15:06:10.000000000 +0100
> > @@ -353,21 +353,24 @@
> >  	struct hci_conn_info *ci;
> >  	struct hci_dev *hdev;
> >  	struct list_head *p;
> > -	int n = 0, size;
> > +	int n = 0, size, err;
> >  
> >  	if (copy_from_user(&req, (void *) arg, sizeof(req)))
> >  		return -EFAULT;
> >  
> > -	if (!(hdev = hci_dev_get(req.dev_id)))
> > -		return -ENODEV;
> > +	if (req.conn_num >= (2*PAGE_SIZE)/sizeof(struct hci_conn_info))
> > +		return -EINVAL; 
> >  
> >  	size = req.conn_num * sizeof(struct hci_conn_info) + sizeof(req);
> >  
> > -	if (verify_area(VERIFY_WRITE, (void *)arg, size))
> > -		return -EFAULT;
> > -
> >  	if (!(cl = (void *) kmalloc(size, GFP_KERNEL)))
> >  		return -ENOMEM;
> > +
> > +	if (!(hdev = hci_dev_get(req.dev_id))) { 
> > +		kfree(cl);
> > +		return -ENODEV;
> > +	}
> > +
> >  	ci = cl->conn_info;
> >  
> >  	hci_dev_lock_bh(hdev);
> 
> Why 2*PAGE_SIZE in this case? What is different?

It's just an arbitary number. Mainly to stop overflow attacks on 
user controlled values. e.g. user can pass UINT_MAX for conn_num.
The kmalloc would overflow and succeed. But a later loop running
through the values could do wrong things on the too small buffer.
The code seems to not be vunerable to this, but only by luck.

Also in general it's good practice to stop user controlled kmalloc
at a reasonable size.

-Andi

From davem@redhat.com Fri Feb  6 19:45:21 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 19:45:30 -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 i173jKKO002123
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 19:45:21 -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 i173jJb31531;
	Fri, 6 Feb 2004 22:45:19 -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 i173jJa10298;
	Fri, 6 Feb 2004 22:45:19 -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 i173ilkC015516;
	Fri, 6 Feb 2004 22:44:48 -0500
Date: Fri, 6 Feb 2004 19:45:18 -0800
From: "David S. Miller" <davem@redhat.com>
To: Sridhar Samudrala <sri@us.ibm.com>
Cc: netdev@oss.sgi.com
Subject: Re: [BK PATCH] 2.6.2 SCTP updates
Message-Id: <20040206194518.56787717.davem@redhat.com>
In-Reply-To: <Pine.LNX.4.58.0402061649001.10831@localhost.localdomain>
References: <Pine.LNX.4.58.0402061649001.10831@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: 3069
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, 6 Feb 2004 17:24:32 -0800 (PST)
Sridhar Samudrala <sri@us.ibm.com> wrote:

> Please do a
> 	bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work
> to get the following udpates to SCTP on top of linux 2.6.2

Pulled, but.

> - Updated the default max socket receive buffer to 64K from 32K and also
>   added sysctl variables to change sctp socket send/receive buffers.

Why do you use specialized SCTP rmem/wmem values and not the globally
sysctl's ones we have for sockets already?

From davem@redhat.com Fri Feb  6 19:48:53 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 19:48: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 i173mrKO002495
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 19:48: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 i173mjb32676;
	Fri, 6 Feb 2004 22:48:45 -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 i173mja10923;
	Fri, 6 Feb 2004 22:48:45 -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 i173mDkC016171;
	Fri, 6 Feb 2004 22:48:14 -0500
Date: Fri, 6 Feb 2004 19:48:44 -0800
From: "David S. Miller" <davem@redhat.com>
To: Mika =?ISO-8859-1?Q?Penttil=E4?= <mika.penttila@kolumbus.fi>
Cc: kazunori@miyazawa.org, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com,
        usagi-core@linux-ipv6.org
Subject: Re: [PATCH][IPV6][NDISC] unify ipv6 output routine
Message-Id: <20040206194844.42bebb59.davem@redhat.com>
In-Reply-To: <4023D6FB.9010909@kolumbus.fi>
References: <200402070232.33771.kazunori@miyazawa.org>
	<4023D6FB.9010909@kolumbus.fi>
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 i173mrKO002495
X-archive-position: 3070
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, 06 Feb 2004 20:03:39 +0200
Mika Penttilä <mika.penttila@kolumbus.fi> wrote:

> >Yoshifuji-san and I send the patch which unifies IPv6 output routine and remove
> >RTF_NDISC again. It resolves an issue of IPv6 IPsec with neighbor discovery
> >without a flag.
> 
> You break multicast replies, see what ndisc_build_ll_hdr() does...

That's right, and compiler should have warned about ndisc_build_ll_hdr()
(a static function in ndisc.c) since it was no longer referenced after
applying the patch, which would be a clue that something was wrong :-)


From davem@redhat.com Fri Feb  6 19:53:45 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 19:53:48 -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 i173riKO002885
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 19:53:44 -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 i173rfb01997;
	Fri, 6 Feb 2004 22:53:41 -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 i173rfa12034;
	Fri, 6 Feb 2004 22:53: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 i173qtkC017214;
	Fri, 6 Feb 2004 22:53:09 -0500
Date: Fri, 6 Feb 2004 19:53:25 -0800
From: "David S. Miller" <davem@redhat.com>
To: David Stevens <dlstevens@us.ibm.com>
Cc: hibi665@oki.com, netdev@oss.sgi.com
Subject: Re: Source Specific Query of MLDv2 [PATCH]
Message-Id: <20040206195325.207aa1c7.davem@redhat.com>
In-Reply-To: <OFABEBA675.68903615-ON88256E33.000504D4-88256E33.0005673C@us.ibm.com>
References: <20040115221841.7e7cc78d%hibi665@oki.com>
	<OFABEBA675.68903615-ON88256E33.000504D4-88256E33.0005673C@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: 3071
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, 6 Feb 2004 18:01:37 -0700
David Stevens <dlstevens@us.ibm.com> wrote:

> +extern int is_mld(struct sk_buff *skb);

David, please don't pollute global name space so badly :-)
ipv6_is_mld() would be fine.

From dlstevens@us.ibm.com Fri Feb  6 20:13:18 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 20:13:21 -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 i174D8KQ003460
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 20:13:18 -0800
Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32])
	by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i174D3wX283496;
	Fri, 6 Feb 2004 23:13:03 -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 i174D1ca050068;
	Fri, 6 Feb 2004 21:13:02 -0700
In-Reply-To: <20040206195325.207aa1c7.davem@redhat.com>
Subject: Re: Source Specific Query of MLDv2 [PATCH]
To: "David S. Miller" <davem@redhat.com>
Cc: hibi665@oki.com, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF293C5854.C480643B-ON88256E33.0016BE45-88256E33.0016EBE0@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Fri, 6 Feb 2004 21:12:59 -0700
X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November
 14, 2003) at 02/06/2004 21:13:02
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=07BBE4A0DF8538D58f9e8a93df938690918c07BBE4A0DF8538D5"
X-archive-position: 3072
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__=07BBE4A0DF8538D58f9e8a93df938690918c07BBE4A0DF8538D5
Content-type: multipart/alternative; 
	Boundary="1__=07BBE4A0DF8538D58f9e8a93df938690918c07BBE4A0DF8538D5"

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






> David, please don't pollute global name space so badly :-)
> ipv6_is_mld() would be fine.

Of course, sorry about that. :-)

                  +-DLS

diff -ruN linux-2.6.2/include/net/addrconf.h linux-2.6.2F1/include/net/addrconf.h
--- linux-2.6.2/include/net/addrconf.h    2004-02-03 19:44:17.000000000 -0800
+++ linux-2.6.2F1/include/net/addrconf.h  2004-02-06 16:03:34.000000000 -0800
@@ -98,6 +98,7 @@

 extern int ipv6_chk_mcast_addr(struct net_device *dev, struct in6_addr *group,
            struct in6_addr *src_addr);
+extern int ipv6_is_mld(struct sk_buff *skb);

 extern void addrconf_prefix_rcv(struct net_device *dev, u8 *opt, int len);

diff -ruN linux-2.6.2/net/ipv6/ip6_input.c linux-2.6.2F1/net/ipv6/ip6_input.c
--- linux-2.6.2/net/ipv6/ip6_input.c      2004-02-03 19:44:14.000000000 -0800
+++ linux-2.6.2F1/net/ipv6/ip6_input.c    2004-02-06 16:04:00.000000000 -0800
@@ -168,11 +168,19 @@

            smp_read_barrier_depends();
            if (ipprot->flags & INET6_PROTO_FINAL) {
+                 struct ipv6hdr *hdr;
+
                  if (!cksum_sub && skb->ip_summed == CHECKSUM_HW) {
                        skb->csum = csum_sub(skb->csum,
                                         csum_partial(skb->nh.raw, skb->h.raw-skb->nh.raw, 0));
                        cksum_sub++;
                  }
+                 hdr = skb->nh.ipv6h;
+                 if (ipv6_addr_is_multicast(&hdr->daddr) &&
+                     !ipv6_chk_mcast_addr(skb->dev, &hdr->daddr,
+                     &hdr->saddr) &&
+                     !ipv6_is_mld(skb))
+                       goto discard;
            }
            if (!(ipprot->flags & INET6_PROTO_NOPOLICY) &&
                !xfrm6_policy_check(NULL, XFRM_POLICY_IN, skb))
@@ -211,16 +219,11 @@

 int ip6_mc_input(struct sk_buff *skb)
 {
-     struct ipv6hdr *hdr;
-     int deliver = 0;
+     int deliver = 1;
      int discard = 1;

      IP6_INC_STATS_BH(Ip6InMcastPkts);

-     hdr = skb->nh.ipv6h;
-     if (ipv6_chk_mcast_addr(skb->dev, &hdr->daddr, &hdr->saddr))
-           deliver = 1;
-
      /*
       *    IPv6 multicast router mode isnt currently supported.
       */
diff -ruN linux-2.6.2/net/ipv6/mcast.c linux-2.6.2F1/net/ipv6/mcast.c
--- linux-2.6.2/net/ipv6/mcast.c    2004-02-03 19:44:28.000000000 -0800
+++ linux-2.6.2F1/net/ipv6/mcast.c  2004-02-06 16:04:25.000000000 -0800
@@ -901,6 +901,25 @@
 }

 /*
+ * identify MLD packets for MLD filter exceptions
+ */
+int ipv6_is_mld(struct sk_buff *skb)
+{
+     struct icmp6hdr *pic = (struct icmp6hdr *)skb->h.raw;
+
+     switch (pic->icmp6_type) {
+     case ICMPV6_MGM_QUERY:
+     case ICMPV6_MGM_REPORT:
+     case ICMPV6_MGM_REDUCTION:
+     case ICMPV6_MLD2_REPORT:
+           return 1;
+     default:
+           break;
+     }
+     return 0;
+}
+
+/*
  *   check if the interface/address pair is valid
  */
 int ipv6_chk_mcast_addr(struct net_device *dev, struct in6_addr *group,

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

<html><body>
<p><tt>&gt; David, please don't pollute global name space so badly :-)<br>
&gt; ipv6_is_mld() would be fine.</tt><br>
<br>
<tt>Of course, sorry about that. :-)</tt><br>
<br>
<tt>			+-DLS</tt><br>
<br>
<tt>diff -ruN linux-2.6.2/include/net/addrconf.h linux-2.6.2F1/include/net/addrconf.h<br>
--- linux-2.6.2/include/net/addrconf.h	2004-02-03 19:44:17.000000000 -0800<br>
+++ linux-2.6.2F1/include/net/addrconf.h	2004-02-06 16:03:34.000000000 -0800<br>
@@ -98,6 +98,7 @@<br>
 <br>
 extern int ipv6_chk_mcast_addr(struct net_device *dev, struct in6_addr *group,<br>
 		struct in6_addr *src_addr);<br>
+extern int ipv6_is_mld(struct sk_buff *skb);<br>
 <br>
 extern void addrconf_prefix_rcv(struct net_device *dev, u8 *opt, int len);<br>
 <br>
diff -ruN linux-2.6.2/net/ipv6/ip6_input.c linux-2.6.2F1/net/ipv6/ip6_input.c<br>
--- linux-2.6.2/net/ipv6/ip6_input.c	2004-02-03 19:44:14.000000000 -0800<br>
+++ linux-2.6.2F1/net/ipv6/ip6_input.c	2004-02-06 16:04:00.000000000 -0800<br>
@@ -168,11 +168,19 @@<br>
 		<br>
 		smp_read_barrier_depends();<br>
 		if (ipprot-&gt;flags &amp; INET6_PROTO_FINAL) {<br>
+			struct ipv6hdr *hdr;	<br>
+<br>
 			if (!cksum_sub &amp;&amp; skb-&gt;ip_summed == CHECKSUM_HW) {<br>
 				skb-&gt;csum = csum_sub(skb-&gt;csum,<br>
 						 &nbsp; &nbsp; csum_partial(skb-&gt;nh.raw, skb-&gt;h.raw-skb-&gt;nh.raw, 0));<br>
 				cksum_sub++;<br>
 			}</tt><br>
<tt>+			hdr = skb-&gt;nh.ipv6h;<br>
+			if (ipv6_addr_is_multicast(&amp;hdr-&gt;daddr) &amp;&amp;<br>
+			 &nbsp; &nbsp;!ipv6_chk_mcast_addr(skb-&gt;dev, &amp;hdr-&gt;daddr,<br>
+			 &nbsp; &nbsp;&amp;hdr-&gt;saddr) &amp;&amp;<br>
+			 &nbsp; &nbsp;!ipv6_is_mld(skb))<br>
+				goto discard;<br>
 		}<br>
 		if (!(ipprot-&gt;flags &amp; INET6_PROTO_NOPOLICY) &amp;&amp;<br>
 		 &nbsp; &nbsp;!xfrm6_policy_check(NULL, XFRM_POLICY_IN, skb)) <br>
@@ -211,16 +219,11 @@<br>
 <br>
 int ip6_mc_input(struct sk_buff *skb)<br>
 {<br>
-	struct ipv6hdr *hdr;	<br>
-	int deliver = 0;<br>
+	int deliver = 1;<br>
 	int discard = 1;<br>
 <br>
 	IP6_INC_STATS_BH(Ip6InMcastPkts);<br>
 <br>
-	hdr = skb-&gt;nh.ipv6h;<br>
-	if (ipv6_chk_mcast_addr(skb-&gt;dev, &amp;hdr-&gt;daddr, &amp;hdr-&gt;saddr))<br>
-		deliver = 1;<br>
-<br>
 	/*<br>
 	 *	IPv6 multicast router mode isnt currently supported.<br>
 	 */<br>
diff -ruN linux-2.6.2/net/ipv6/mcast.c linux-2.6.2F1/net/ipv6/mcast.c<br>
--- linux-2.6.2/net/ipv6/mcast.c	2004-02-03 19:44:28.000000000 -0800<br>
+++ linux-2.6.2F1/net/ipv6/mcast.c	2004-02-06 16:04:25.000000000 -0800<br>
@@ -901,6 +901,25 @@<br>
 }<br>
 <br>
 /*<br>
+ * identify MLD packets for MLD filter exceptions<br>
+ */<br>
+int ipv6_is_mld(struct sk_buff *skb)<br>
+{<br>
+	struct icmp6hdr *pic = (struct icmp6hdr *)skb-&gt;h.raw;</tt><br>
<tt>+<br>
+	switch (pic-&gt;icmp6_type) {<br>
+	case ICMPV6_MGM_QUERY:<br>
+	case ICMPV6_MGM_REPORT:<br>
+	case ICMPV6_MGM_REDUCTION:<br>
+	case ICMPV6_MLD2_REPORT:<br>
+		return 1;<br>
+	default:<br>
+		break;<br>
+	}<br>
+	return 0;<br>
+}<br>
+<br>
+/*<br>
 &nbsp;*	check if the interface/address pair is valid<br>
 &nbsp;*/<br>
 int ipv6_chk_mcast_addr(struct net_device *dev, struct in6_addr *group,</tt><br>
<br>
<i>(See attached file: mldx2.patch)</i><br>
</body></html>

--1__=07BBE4A0DF8538D58f9e8a93df938690918c07BBE4A0DF8538D5--


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

ZGlmZiAtcnVOIGxpbnV4LTIuNi4yL2luY2x1ZGUvbmV0L2FkZHJjb25mLmggbGludXgtMi42LjJG
MS9pbmNsdWRlL25ldC9hZGRyY29uZi5oCi0tLSBsaW51eC0yLjYuMi9pbmNsdWRlL25ldC9hZGRy
Y29uZi5oCTIwMDQtMDItMDMgMTk6NDQ6MTcuMDAwMDAwMDAwIC0wODAwCisrKyBsaW51eC0yLjYu
MkYxL2luY2x1ZGUvbmV0L2FkZHJjb25mLmgJMjAwNC0wMi0wNiAxNjowMzozNC4wMDAwMDAwMDAg
LTA4MDAKQEAgLTk4LDYgKzk4LDcgQEAKIAogZXh0ZXJuIGludCBpcHY2X2Noa19tY2FzdF9hZGRy
KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIHN0cnVjdCBpbjZfYWRkciAqZ3JvdXAsCiAJCXN0cnVj
dCBpbjZfYWRkciAqc3JjX2FkZHIpOworZXh0ZXJuIGludCBpcHY2X2lzX21sZChzdHJ1Y3Qgc2tf
YnVmZiAqc2tiKTsKIAogZXh0ZXJuIHZvaWQgYWRkcmNvbmZfcHJlZml4X3JjdihzdHJ1Y3QgbmV0
X2RldmljZSAqZGV2LCB1OCAqb3B0LCBpbnQgbGVuKTsKIApkaWZmIC1ydU4gbGludXgtMi42LjIv
bmV0L2lwdjYvaXA2X2lucHV0LmMgbGludXgtMi42LjJGMS9uZXQvaXB2Ni9pcDZfaW5wdXQuYwot
LS0gbGludXgtMi42LjIvbmV0L2lwdjYvaXA2X2lucHV0LmMJMjAwNC0wMi0wMyAxOTo0NDoxNC4w
MDAwMDAwMDAgLTA4MDAKKysrIGxpbnV4LTIuNi4yRjEvbmV0L2lwdjYvaXA2X2lucHV0LmMJMjAw
NC0wMi0wNiAxNjowNDowMC4wMDAwMDAwMDAgLTA4MDAKQEAgLTE2OCwxMSArMTY4LDE5IEBACiAJ
CQogCQlzbXBfcmVhZF9iYXJyaWVyX2RlcGVuZHMoKTsKIAkJaWYgKGlwcHJvdC0+ZmxhZ3MgJiBJ
TkVUNl9QUk9UT19GSU5BTCkgeworCQkJc3RydWN0IGlwdjZoZHIgKmhkcjsJCisKIAkJCWlmICgh
Y2tzdW1fc3ViICYmIHNrYi0+aXBfc3VtbWVkID09IENIRUNLU1VNX0hXKSB7CiAJCQkJc2tiLT5j
c3VtID0gY3N1bV9zdWIoc2tiLT5jc3VtLAogCQkJCQkJICAgICBjc3VtX3BhcnRpYWwoc2tiLT5u
aC5yYXcsIHNrYi0+aC5yYXctc2tiLT5uaC5yYXcsIDApKTsKIAkJCQlja3N1bV9zdWIrKzsKIAkJ
CX0KKwkJCWhkciA9IHNrYi0+bmguaXB2Nmg7CisJCQlpZiAoaXB2Nl9hZGRyX2lzX211bHRpY2Fz
dCgmaGRyLT5kYWRkcikgJiYKKwkJCSAgICAhaXB2Nl9jaGtfbWNhc3RfYWRkcihza2ItPmRldiwg
Jmhkci0+ZGFkZHIsCisJCQkgICAgJmhkci0+c2FkZHIpICYmCisJCQkgICAgIWlwdjZfaXNfbWxk
KHNrYikpCisJCQkJZ290byBkaXNjYXJkOwogCQl9CiAJCWlmICghKGlwcHJvdC0+ZmxhZ3MgJiBJ
TkVUNl9QUk9UT19OT1BPTElDWSkgJiYKIAkJICAgICF4ZnJtNl9wb2xpY3lfY2hlY2soTlVMTCwg
WEZSTV9QT0xJQ1lfSU4sIHNrYikpIApAQCAtMjExLDE2ICsyMTksMTEgQEAKIAogaW50IGlwNl9t
Y19pbnB1dChzdHJ1Y3Qgc2tfYnVmZiAqc2tiKQogewotCXN0cnVjdCBpcHY2aGRyICpoZHI7CQot
CWludCBkZWxpdmVyID0gMDsKKwlpbnQgZGVsaXZlciA9IDE7CiAJaW50IGRpc2NhcmQgPSAxOwog
CiAJSVA2X0lOQ19TVEFUU19CSChJcDZJbk1jYXN0UGt0cyk7CiAKLQloZHIgPSBza2ItPm5oLmlw
djZoOwotCWlmIChpcHY2X2Noa19tY2FzdF9hZGRyKHNrYi0+ZGV2LCAmaGRyLT5kYWRkciwgJmhk
ci0+c2FkZHIpKQotCQlkZWxpdmVyID0gMTsKLQogCS8qCiAJICoJSVB2NiBtdWx0aWNhc3Qgcm91
dGVyIG1vZGUgaXNudCBjdXJyZW50bHkgc3VwcG9ydGVkLgogCSAqLwpkaWZmIC1ydU4gbGludXgt
Mi42LjIvbmV0L2lwdjYvbWNhc3QuYyBsaW51eC0yLjYuMkYxL25ldC9pcHY2L21jYXN0LmMKLS0t
IGxpbnV4LTIuNi4yL25ldC9pcHY2L21jYXN0LmMJMjAwNC0wMi0wMyAxOTo0NDoyOC4wMDAwMDAw
MDAgLTA4MDAKKysrIGxpbnV4LTIuNi4yRjEvbmV0L2lwdjYvbWNhc3QuYwkyMDA0LTAyLTA2IDE2
OjA0OjI1LjAwMDAwMDAwMCAtMDgwMApAQCAtOTAxLDYgKzkwMSwyNSBAQAogfQogCiAvKgorICog
aWRlbnRpZnkgTUxEIHBhY2tldHMgZm9yIE1MRCBmaWx0ZXIgZXhjZXB0aW9ucworICovCitpbnQg
aXB2Nl9pc19tbGQoc3RydWN0IHNrX2J1ZmYgKnNrYikKK3sKKwlzdHJ1Y3QgaWNtcDZoZHIgKnBp
YyA9IChzdHJ1Y3QgaWNtcDZoZHIgKilza2ItPmgucmF3OworCisJc3dpdGNoIChwaWMtPmljbXA2
X3R5cGUpIHsKKwljYXNlIElDTVBWNl9NR01fUVVFUlk6CisJY2FzZSBJQ01QVjZfTUdNX1JFUE9S
VDoKKwljYXNlIElDTVBWNl9NR01fUkVEVUNUSU9OOgorCWNhc2UgSUNNUFY2X01MRDJfUkVQT1JU
OgorCQlyZXR1cm4gMTsKKwlkZWZhdWx0OgorCQlicmVhazsKKwl9CisJcmV0dXJuIDA7Cit9CisK
Ky8qCiAgKgljaGVjayBpZiB0aGUgaW50ZXJmYWNlL2FkZHJlc3MgcGFpciBpcyB2YWxpZAogICov
CiBpbnQgaXB2Nl9jaGtfbWNhc3RfYWRkcihzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1Y3Qg
aW42X2FkZHIgKmdyb3VwLAo=

--0__=07BBE4A0DF8538D58f9e8a93df938690918c07BBE4A0DF8538D5--


From yoshfuji@linux-ipv6.org Fri Feb  6 20:14:04 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 20:14:07 -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 i174E3KO003646
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 20:14:04 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 21B2933CA5; Sat,  7 Feb 2004 13:14:56 +0900 (JST)
Date: Sat, 07 Feb 2004 13:14:55 +0900 (JST)
Message-Id: <20040207.131455.27570445.yoshfuji@linux-ipv6.org>
To: mika.penttila@kolumbus.fi
Cc: kazunori@miyazawa.org, davem@redhat.com, netdev@oss.sgi.com,
        usagi-core@linux-ipv6.org
Subject: Re: [PATCH][IPV6][NDISC] unify ipv6 output routine
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
In-Reply-To: <4023D6FB.9010909@kolumbus.fi>
References: <200402070232.33771.kazunori@miyazawa.org>
	<4023D6FB.9010909@kolumbus.fi>
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-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i174E3KO003646
X-archive-position: 3073
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 <4023D6FB.9010909@kolumbus.fi> (at Fri, 06 Feb 2004 20:03:39 +0200), Mika Penttilä <mika.penttila@kolumbus.fi> says:

> Kazunori Miyazawa wrote:
:
> >Yoshifuji-san and I send the patch which unifies IPv6 output routine and remove
> >RTF_NDISC again. It resolves an issue of IPv6 IPsec with neighbor discovery
> >without a flag.
:
> You break multicast replies, see what ndisc_build_ll_hdr() does...

It doesn't "break." 
The ip6_output2() resolves and inserts link-layer address appropriately.
If it did, we would have noticed (by conformance test or even by
usual operation). ;-)

BTW, Miyazawa-san, we do not need ndisc_build_ll_hdr() anymore.
Compiler warns it. Please remove it. Thanks.


Here's the description:

dst->neighbour owns the neighbour entry for the destination. 

For multicast, we know its link-layer address 
(filled in ndisc_constructor()).
For unicast, the link-layer address may be unknown.

ip6_output2() will call ip6_output_finish() and
it tries inserting the link-layer header.

The destination link-layer address is used if it is known (*).
(Note: you remember that we know link-layer address for multicast.)

If the link-layer address is not known or invalid, 
we queue the packet and resolve the link-layer address for the destination.
Here, since the neighbour entry is "invalid," *multicast* NS is sent. 
The NS packet passes similar path. 
We know the destination for the NS is multicast and 
what the link-layer address is, and the packet is sent via (*).
We will send the queued packet when we got NA from that node.

Real story:
A node may send NS without source link-layer address option 
while we do not know the link-layer address for the source of the NS.
We need to send NA in reply to this NS.
Original code cannot handle this case.  The new code path can.

-- 
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 Fri Feb  6 20:21:42 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 20:21:50 -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 i174LfKO007110
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 20:21:41 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 39B7F33CA5; Sat,  7 Feb 2004 13:22:34 +0900 (JST)
Date: Sat, 07 Feb 2004 13:22:33 +0900 (JST)
Message-Id: <20040207.132233.21960944.yoshfuji@linux-ipv6.org>
To: dlstevens@us.ibm.com
Cc: davem@redhat.com, hibi665@oki.com, netdev@oss.sgi.com,
        yoshfuji@linux-ipv6.org
Subject: Re: Source Specific Query of MLDv2 [PATCH]
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
In-Reply-To: <OF293C5854.C480643B-ON88256E33.0016BE45-88256E33.0016EBE0@us.ibm.com>
References: <20040206195325.207aa1c7.davem@redhat.com>
	<OF293C5854.C480643B-ON88256E33.0016BE45-88256E33.0016EBE0@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: 3074
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 <OF293C5854.C480643B-ON88256E33.0016BE45-88256E33.0016EBE0@us.ibm.com> (at Fri, 6 Feb 2004 21:12:59 -0700), David Stevens <dlstevens@us.ibm.com> says:

> > David, please don't pollute global name space so badly :-)
> > ipv6_is_mld() would be fine.
> 
> Of course, sorry about that. :-)

Why not in icmpv6_rcv()?
we need to do pskb_pull() before touching type/code.

>  int ip6_mc_input(struct sk_buff *skb)
>  {
> -     struct ipv6hdr *hdr;
> -     int deliver = 0;
> +     int deliver = 1;
>       int discard = 1;
> 
>       IP6_INC_STATS_BH(Ip6InMcastPkts);
> 
> -     hdr = skb->nh.ipv6h;
> -     if (ipv6_chk_mcast_addr(skb->dev, &hdr->daddr, &hdr->saddr))
> -           deliver = 1;
> -

Please do not remove this.
We need to check destination (but not source)
because the driver may be in "promisc." mode.

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

From davem@redhat.com Fri Feb  6 20:24:43 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 20:24:52 -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 i174OgKO007548;
	Fri, 6 Feb 2004 20:24:43 -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 i174Odb12872;
	Fri, 6 Feb 2004 23:24:39 -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 i174Oda19090;
	Fri, 6 Feb 2004 23:24:39 -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 i174O7kC024803;
	Fri, 6 Feb 2004 23:24:08 -0500
Date: Fri, 6 Feb 2004 20:24:38 -0800
From: "David S. Miller" <davem@redhat.com>
To: David Stevens <dlstevens@us.ibm.com>
Cc: hibi665@oki.com, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com
Subject: Re: Source Specific Query of MLDv2 [PATCH]
Message-Id: <20040206202438.13163677.davem@redhat.com>
In-Reply-To: <OF293C5854.C480643B-ON88256E33.0016BE45-88256E33.0016EBE0@us.ibm.com>
References: <20040206195325.207aa1c7.davem@redhat.com>
	<OF293C5854.C480643B-ON88256E33.0016BE45-88256E33.0016EBE0@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: 3075
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, 6 Feb 2004 21:12:59 -0700
David Stevens <dlstevens@us.ibm.com> wrote:

> @@ -211,16 +219,11 @@
> 
>  int ip6_mc_input(struct sk_buff *skb)
>  {
> -     struct ipv6hdr *hdr;
> -     int deliver = 0;
> +     int deliver = 1;
>       int discard = 1;

'deliver' is always true now, please kill it and all the code
trying to test it :)

From yoshfuji@linux-ipv6.org Fri Feb  6 20:28:45 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 20:28:48 -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 i174SiKO007985
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 20:28:44 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 43B8233CA5; Sat,  7 Feb 2004 13:29:37 +0900 (JST)
Date: Sat, 07 Feb 2004 13:29:37 +0900 (JST)
Message-Id: <20040207.132937.126838355.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: dlstevens@us.ibm.com, hibi665@oki.com, netdev@oss.sgi.com,
        yoshfuji@linux-ipv6.org
Subject: Re: Source Specific Query of MLDv2 [PATCH]
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
In-Reply-To: <20040206202438.13163677.davem@redhat.com>
References: <20040206195325.207aa1c7.davem@redhat.com>
	<OF293C5854.C480643B-ON88256E33.0016BE45-88256E33.0016EBE0@us.ibm.com>
	<20040206202438.13163677.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: 3076
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 <20040206202438.13163677.davem@redhat.com> (at Fri, 6 Feb 2004 20:24:38 -0800), "David S. Miller" <davem@redhat.com> says:

> On Fri, 6 Feb 2004 21:12:59 -0700
> David Stevens <dlstevens@us.ibm.com> wrote:
> 
> > @@ -211,16 +219,11 @@
> > 
> >  int ip6_mc_input(struct sk_buff *skb)
> >  {
> > -     struct ipv6hdr *hdr;
> > -     int deliver = 0;
> > +     int deliver = 1;
> >       int discard = 1;
> 
> 'deliver' is always true now, please kill it and all the code
> trying to test it :)

We should test the destination address here.

--yoshfuji

From davem@redhat.com Fri Feb  6 20:33:36 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 20:33:40 -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 i174XaKO008407
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 20:33:36 -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 i174XVb15866;
	Fri, 6 Feb 2004 23:33:31 -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 i174XVa20967;
	Fri, 6 Feb 2004 23:33:31 -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 i174WxkC026950;
	Fri, 6 Feb 2004 23:33:00 -0500
Date: Fri, 6 Feb 2004 20:33:30 -0800
From: "David S. Miller" <davem@redhat.com>
To: yoshfuji@linux-ipv6.org
Cc: dlstevens@us.ibm.com, hibi665@oki.com, netdev@oss.sgi.com
Subject: Re: Source Specific Query of MLDv2 [PATCH]
Message-Id: <20040206203330.60e63ba7.davem@redhat.com>
In-Reply-To: <20040207.132937.126838355.yoshfuji@linux-ipv6.org>
References: <20040206195325.207aa1c7.davem@redhat.com>
	<OF293C5854.C480643B-ON88256E33.0016BE45-88256E33.0016EBE0@us.ibm.com>
	<20040206202438.13163677.davem@redhat.com>
	<20040207.132937.126838355.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 i174XaKO008407
X-archive-position: 3077
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 Sat, 07 Feb 2004 13:29:37 +0900 (JST)
YOSHIFUJI Hideaki / $B5HF#1QL@(B <yoshfuji@linux-ipv6.org> wrote:

> In article <20040206202438.13163677.davem@redhat.com> (at Fri, 6 Feb 2004 20:24:38 -0800), "David S. Miller" <davem@redhat.com> says:
> 
> > On Fri, 6 Feb 2004 21:12:59 -0700
> > David Stevens <dlstevens@us.ibm.com> wrote:
> > 
> > > @@ -211,16 +219,11 @@
> > > 
> > >  int ip6_mc_input(struct sk_buff *skb)
> 
> We should test the destination address here.

Ok, you and David work things out and let me know when the final
patch is ready.



From dlstevens@us.ibm.com Fri Feb  6 20:40:23 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 20:40:26 -0800 (PST)
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i174eMKO008815
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 20:40:22 -0800
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i174doOH403784;
	Fri, 6 Feb 2004 23:39:50 -0500
Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i174dnbP120016;
	Fri, 6 Feb 2004 21:39:50 -0700
In-Reply-To: <20040207.132233.21960944.yoshfuji@linux-ipv6.org>
Subject: Re: Source Specific Query of MLDv2 [PATCH]
To: YOSHIFUJI Hideaki /  =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
Cc: davem@redhat.com, hibi665@oki.com, netdev@oss.sgi.com,
        "Hideaki YOSHIFUJI" <yoshfuji@cerberus.hongo.wide.ad.jp>,
        yoshfuji@linux-ipv6.org
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF9F84892D.B2226F9C-ON88256E33.00185F62-88256E33.00196063@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Fri, 6 Feb 2004 20:39:47 -0800
X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November
 14, 2003) at 02/06/2004 21:39:50
MIME-Version: 1.0
Content-type: multipart/alternative; 
	Boundary="0__=07BBE4A0DF8BD9F28f9e8a93df938690918c07BBE4A0DF8BD9F2"
Content-Disposition: inline
X-archive-position: 3078
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__=07BBE4A0DF8BD9F28f9e8a93df938690918c07BBE4A0DF8BD9F2
Content-type: text/plain; charset=US-ASCII







"Hideaki YOSHIFUJI" <yoshfuji@cerberus.hongo.wide.ad.jp> wrote on
02/06/2004 08:22:33 PM:

> Why not in icmpv6_rcv()?

      I don't understand this question. It's needed every place
*except* icmpv6_rcv().

> we need to do pskb_pull() before touching type/code.

      Yes, you're right; I'll add that.

> >
> > -     hdr = skb->nh.ipv6h;
> > -     if (ipv6_chk_mcast_addr(skb->dev, &hdr->daddr, &hdr->saddr))
> > -           deliver = 1;
> > -

> Please do not remove this.
> We need to check destination (but not source)
> because the driver may be in "promisc." mode.

      I'm not removing it, I'm moving it. The original code
is:

      ip6_mc_input()
            <filter check> (not much else, since no mc router code)
      ip6_input
            <parse extension headers>
            <deliver to ULP>

new is:
      ip6_mc_input()
            <inc stats, "#if 0" for mc router code>
      ip6_input
            <parse extension headers>
            <filter check>
            <deliver to ULP>

In promiscuous mode, it will parse the extension headers
for non-local multicasts before dropping them. But what
you suggested will do two multicast address look-ups for
every multicast packet (including the valid ones). One
for the destination and another for the destination/source
filter.
      The point where it's filtered is just after the
checksum is validated, and no ICMP errors can be reported
for multicast destinations, so the trade-off is 1) a
performance hit for every multicast packet or 2) parsing
potential extension headers (expected case won't have any
and it doesn't cost anything) for multicast packets that
we may drop.
      This patch implements option #2.

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

<html><body>
<p><tt>&quot;Hideaki YOSHIFUJI&quot; &lt;yoshfuji@cerberus.hongo.wide.ad.jp&gt; wrote on 02/06/2004 08:22:33 PM:<br>
</tt><br>
<tt>&gt; Why not in icmpv6_rcv()?</tt><br>
<br>
<tt>	I don't understand this question. It's needed every place</tt><br>
<tt>*except* icmpv6_rcv().</tt><br>
<tt><br>
&gt; we need to do pskb_pull() before touching type/code.</tt><br>
<br>
<tt>	Yes, you're right; I'll add that.<br>
<br>
&gt; &gt;<br>
&gt; &gt; - &nbsp; &nbsp; hdr = skb-&gt;nh.ipv6h;<br>
&gt; &gt; - &nbsp; &nbsp; if (ipv6_chk_mcast_addr(skb-&gt;dev, &amp;hdr-&gt;daddr, &amp;hdr-&gt;saddr))<br>
&gt; &gt; - &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; deliver = 1;<br>
&gt; &gt; -<br>
</tt><br>
<tt>&gt; Please do not remove this.<br>
&gt; We need to check destination (but not source)<br>
&gt; because the driver may be in &quot;promisc.&quot; mode.</tt><br>
<br>
<tt>	I'm not removing it, I'm moving it. The original code</tt><br>
<tt>is:</tt><br>
<br>
<tt>	ip6_mc_input()</tt><br>
<tt>		&lt;filter check&gt; (not much else, since no mc router code)</tt><br>
<tt>	ip6_input</tt><br>
<tt>		&lt;parse extension headers&gt;</tt><br>
<tt>		&lt;deliver to ULP&gt;</tt><br>
<br>
<tt>new is:</tt><br>
<tt>	ip6_mc_input()</tt><br>
<tt>		&lt;inc stats, &quot;#if 0&quot; for mc router code&gt;</tt><br>
<tt>	ip6_input</tt><br>
<tt>		&lt;parse extension headers&gt;</tt><br>
<tt>		&lt;filter check&gt;</tt><br>
<tt>		&lt;deliver to ULP&gt;</tt><br>
<br>
<tt>In promiscuous mode, it will parse the extension headers</tt><br>
<tt>for non-local multicasts before dropping them. But what</tt><br>
<tt>you suggested will do two multicast address look-ups for</tt><br>
<tt>every multicast packet (including the valid ones). One</tt><br>
<tt>for the destination and another for the destination/source</tt><br>
<tt>filter.</tt><br>
<tt>	The point where it's filtered is just after the</tt><br>
<tt>checksum is validated, and no ICMP errors can be reported</tt><br>
<tt>for multicast destinations, so the trade-off is 1) a</tt><br>
<tt>performance hit for every multicast packet or 2) parsing</tt><br>
<tt>potential extension headers (expected case won't have any</tt><br>
<tt>and it doesn't cost anything) for multicast packets that</tt><br>
<tt>we may drop.</tt><br>
<tt>	This patch implements option #2.</tt><br>
<br>
<tt>				+-DLS</tt><br>
</body></html>
--0__=07BBE4A0DF8BD9F28f9e8a93df938690918c07BBE4A0DF8BD9F2--


From kazunori@miyazawa.org Fri Feb  6 20:49:13 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 20:49:20 -0800 (PST)
Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i174nCKO009222
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 20:49:12 -0800
Received: from 2001:200:1b0:2031:20c:29ff:febb:6598 ([2001:200:1b0:2031:20c:29ff:febb:6598])
  (AUTH: LOGIN kazunori, SSL: TLSv1/SSLv3,128bits,RC4-MD5)
  by miyazawa.org with esmtp; Sat, 07 Feb 2004 13:47:32 +0900
From: Kazunori Miyazawa <kazunori@miyazawa.org>
To: "YOSHIFUJI Hideaki / =?iso-2022-jp?q?=1B$B5HF#1QL=40=1B=28B?=" <yoshfuji@linux-ipv6.org>,
        mika.penttila@kolumbus.fi
Subject: Re: [PATCH][IPV6][NDISC] unify ipv6 output routine
Date: Sat, 7 Feb 2004 13:33:51 +0900
User-Agent: KMail/1.5.4
Cc: davem@redhat.com, netdev@oss.sgi.com, usagi-core@linux-ipv6.org
References: <200402070232.33771.kazunori@miyazawa.org> <4023D6FB.9010909@kolumbus.fi> <20040207.131455.27570445.yoshfuji@linux-ipv6.org>
In-Reply-To: <20040207.131455.27570445.yoshfuji@linux-ipv6.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200402071333.51909.kazunori@miyazawa.org>
X-archive-position: 3079
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: kazunori@miyazawa.org
Precedence: bulk
X-list: netdev

Yoshifuji-san, thank you for following up.
I recreate the pactch. It cares multicast.

> > >Yoshifuji-san and I send the patch
> > > which unifies IPv6 output routine
> > > and remove RTF_NDISC again. It
> > > resolves an issue of IPv6 IPsec
> > > with neighbor discovery without a
> > > flag.
> >
> > You break multicast replies, see
> > what ndisc_build_ll_hdr() does...
>
> It doesn't "break."
> The ip6_output2() resolves and
> inserts link-layer address
> appropriately. If it did, we would
> have noticed (by conformance test or
> even by usual operation). ;-)
>
> BTW, Miyazawa-san, we do not need
> ndisc_build_ll_hdr() anymore.
> Compiler warns it. Please remove it.
> Thanks.
>
>
> Here's the description:
>
> dst->neighbour owns the neighbour
> entry for the destination.
>
> For multicast, we know its link-layer
> address (filled in
> ndisc_constructor()). For unicast,
> the link-layer address may be
> unknown.
>
> ip6_output2() will call
> ip6_output_finish() and it tries
> inserting the link-layer header.
>
> The destination link-layer address is
> used if it is known (*). (Note: you
> remember that we know link-layer
> address for multicast.)
>
--Kazunori Miyazawa

===== include/linux/ipv6_route.h 1.4 vs edited =====
--- 1.4/include/linux/ipv6_route.h	Sun Aug 31 13:26:12 2003
+++ edited/include/linux/ipv6_route.h	Mon Jan 26 15:09:34 2004
@@ -24,7 +24,6 @@
 #define RTF_CACHE	0x01000000	/* cache entry			*/
 #define RTF_FLOW	0x02000000	/* flow significant route	*/
 #define RTF_POLICY	0x04000000	/* policy route			*/
-#define RTF_NDISC	0x08000000	/* ndisc route			*/
 
 #define RTF_LOCAL	0x80000000
 
===== include/net/ip6_route.h 1.11 vs edited =====
--- 1.11/include/net/ip6_route.h	Sat Jul 19 15:42:53 2003
+++ edited/include/net/ip6_route.h	Sat Feb  7 04:11:39 2004
@@ -64,6 +64,7 @@
 
 extern struct dst_entry *ndisc_dst_alloc(struct net_device *dev,
 					 struct neighbour *neigh,
+					 struct in6_addr *addr,
 					 int (*output)(struct sk_buff *));
 extern int ndisc_dst_gc(int *more);
 extern void fib6_force_start_gc(void);
===== include/net/ipv6.h 1.28 vs edited =====
--- 1.28/include/net/ipv6.h	Wed Jan 14 09:36:24 2004
+++ edited/include/net/ipv6.h	Mon Jan 26 15:10:50 2004
@@ -355,6 +355,7 @@
  */
 
 extern int			ip6_output(struct sk_buff *skb);
+extern int			ip6_output2(struct sk_buff *skb);
 extern int			ip6_forward(struct sk_buff *skb);
 extern int			ip6_input(struct sk_buff *skb);
 extern int			ip6_mc_input(struct sk_buff *skb);
===== 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	Sat Feb  7 13:06:24 2004
@@ -345,65 +345,10 @@
 	ipv6_dev_mc_dec(dev, &maddr);
 }
 
-
-
-static int
-ndisc_build_ll_hdr(struct sk_buff *skb, struct net_device *dev,
-		   struct in6_addr *daddr, struct neighbour *neigh, int len)
-{
-	unsigned char ha[MAX_ADDR_LEN];
-	unsigned char *h_dest = NULL;
-
-	if (dev->hard_header) {
-		if (ipv6_addr_type(daddr) & IPV6_ADDR_MULTICAST) {
-			ndisc_mc_map(daddr, ha, dev, 1);
-			h_dest = ha;
-		} else if (neigh) {
-			read_lock_bh(&neigh->lock);
-			if (neigh->nud_state&NUD_VALID) {
-				memcpy(ha, neigh->ha, dev->addr_len);
-				h_dest = ha;
-			}
-			read_unlock_bh(&neigh->lock);
-		} else {
-			neigh = neigh_lookup(&nd_tbl, daddr, dev);
-			if (neigh) {
-				read_lock_bh(&neigh->lock);
-				if (neigh->nud_state&NUD_VALID) {
-					memcpy(ha, neigh->ha, dev->addr_len);
-					h_dest = ha;
-				}
-				read_unlock_bh(&neigh->lock);
-				neigh_release(neigh);
-			}
-		}
-
-		if (dev->hard_header(skb, dev, ETH_P_IPV6, h_dest, NULL, len) < 0)
-			return 0;
-	}
-
-	return 1;
-}
-
-
 /*
  *	Send a Neighbour Advertisement
  */
 
-static int ndisc_output(struct sk_buff *skb)
-{
-	if (skb) {
-		struct neighbour *neigh = (skb->dst ? skb->dst->neighbour : NULL);
-		if (ndisc_build_ll_hdr(skb, skb->dev, &skb->nh.ipv6h->daddr, neigh, skb->len) == 0) {
-			kfree_skb(skb);
-			return -EINVAL;
-		}
-		dev_queue_xmit(skb);
-		return 0;
-	}
-	return -EINVAL;
-}
-
 static inline void ndisc_flow_init(struct flowi *fl, u8 type,
 			    struct in6_addr *saddr, struct in6_addr *daddr)
 {
@@ -446,7 +391,7 @@
 
 	ndisc_flow_init(&fl, NDISC_NEIGHBOUR_ADVERTISEMENT, src_addr, daddr);
 
-	dst = ndisc_dst_alloc(dev, neigh, ndisc_output);
+	dst = ndisc_dst_alloc(dev, neigh, daddr, ip6_output2);
 	if (!dst)
 		return;
 
@@ -533,7 +478,7 @@
 
 	ndisc_flow_init(&fl, NDISC_NEIGHBOUR_SOLICITATION, saddr, daddr);
 
-	dst = ndisc_dst_alloc(dev, neigh, ndisc_output);
+	dst = ndisc_dst_alloc(dev, neigh, daddr, ip6_output2);
 	if (!dst)
 		return;
 
@@ -605,7 +550,7 @@
 
 	ndisc_flow_init(&fl, NDISC_ROUTER_SOLICITATION, saddr, daddr);
 
-	dst = ndisc_dst_alloc(dev, NULL, ndisc_output);
+	dst = ndisc_dst_alloc(dev, NULL, daddr, ip6_output2);
 	if (!dst)
 		return;
 
===== net/ipv6/route.c 1.63 vs edited =====
--- 1.63/net/ipv6/route.c	Sun Jan 25 03:09:52 2004
+++ edited/net/ipv6/route.c	Sat Feb  7 03:57:17 2004
@@ -563,6 +563,7 @@
 
 struct dst_entry *ndisc_dst_alloc(struct net_device *dev, 
 				  struct neighbour *neigh,
+				  struct in6_addr *addr,
 				  int (*output)(struct sk_buff *))
 {
 	struct rt6_info *rt = ip6_dst_alloc();
@@ -574,11 +575,13 @@
 		dev_hold(dev);
 	if (neigh)
 		neigh_hold(neigh);
+	else
+		neigh = ndisc_get_neigh(dev, addr);
 
 	rt->rt6i_dev	  = dev;
 	rt->rt6i_nexthop  = neigh;
 	rt->rt6i_expires  = 0;
-	rt->rt6i_flags    = RTF_LOCAL | RTF_NDISC;
+	rt->rt6i_flags    = RTF_LOCAL;
 	rt->rt6i_metric   = 0;
 	atomic_set(&rt->u.dst.__refcnt, 1);
 	rt->u.dst.metrics[RTAX_HOPLIMIT-1] = 255;
@@ -832,7 +835,7 @@
 		}
 	}
 
-	rt->rt6i_flags = rtmsg->rtmsg_flags & ~RTF_NDISC;
+	rt->rt6i_flags = rtmsg->rtmsg_flags;
 
 install_route:
 	if (rta && rta[RTA_METRICS-1]) {
@@ -1124,8 +1127,6 @@
 static struct rt6_info * ip6_rt_copy(struct rt6_info *ort)
 {
 	struct rt6_info *rt = ip6_dst_alloc();
-
-	BUG_ON(ort->rt6i_flags & RTF_NDISC);
 
 	if (rt) {
 		rt->u.dst.input = ort->u.dst.input;
===== net/ipv6/xfrm6_policy.c 1.14 vs edited =====
--- 1.14/net/ipv6/xfrm6_policy.c	Fri Oct 24 21:39:33 2003
+++ edited/net/ipv6/xfrm6_policy.c	Mon Jan 26 15:12:35 2004
@@ -55,13 +55,6 @@
 __xfrm6_find_bundle(struct flowi *fl, struct rtable *rt, struct xfrm_policy *policy)
 {
 	struct dst_entry *dst;
-	u32 ndisc_bit = 0;
-
-	if (fl->proto == IPPROTO_ICMPV6 &&
-	    (fl->fl_icmp_type == NDISC_NEIGHBOUR_ADVERTISEMENT ||
-	     fl->fl_icmp_type == NDISC_NEIGHBOUR_SOLICITATION  ||
-	     fl->fl_icmp_type == NDISC_ROUTER_SOLICITATION))
-		ndisc_bit = RTF_NDISC;
 
 	/* Still not clear if we should set fl->fl6_{src,dst}... */
 	read_lock_bh(&policy->lock);
@@ -69,9 +62,6 @@
 		struct xfrm_dst *xdst = (struct xfrm_dst*)dst;
 		struct in6_addr fl_dst_prefix, fl_src_prefix;
 
-		if ((xdst->u.rt6.rt6i_flags & RTF_NDISC) != ndisc_bit)
-			continue;
-
 		ipv6_addr_prefix(&fl_dst_prefix,
 				 &fl->fl6_dst,
 				 xdst->u.rt6.rt6i_dst.plen);
@@ -169,7 +159,7 @@
 		dst_prev->output	= dst_prev->xfrm->type->output;
 		/* Sheit... I remember I did this right. Apparently,
 		 * it was magically lost, so this code needs audit */
-		x->u.rt6.rt6i_flags    = rt0->rt6i_flags&(RTCF_BROADCAST|RTCF_MULTICAST|RTCF_LOCAL|RTF_NDISC);
+		x->u.rt6.rt6i_flags    = rt0->rt6i_flags&(RTCF_BROADCAST|RTCF_MULTICAST|RTCF_LOCAL);
 		x->u.rt6.rt6i_metric   = rt0->rt6i_metric;
 		x->u.rt6.rt6i_node     = rt0->rt6i_node;
 		x->u.rt6.rt6i_gateway  = rt0->rt6i_gateway;


From acme@conectiva.com.br Fri Feb  6 21:00:57 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 21:01:10 -0800 (PST)
Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1750tKO009728
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 21:00:56 -0800
Received: from [200.163.195.99] (helo=oops.kerneljanitors.org)
	by orion.netbank.com.br with asmtp (Exim 3.33 #1)
	id 1ApKeh-0000tV-00; Sat, 07 Feb 2004 03:05:23 -0200
Received: by oops.kerneljanitors.org (Postfix, from userid 500)
	id DA841E731; Sat,  7 Feb 2004 03:17:53 -0200 (BRDT)
Date: Sat, 7 Feb 2004 03:17:53 -0200
From: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
To: "David S. Miller" <davem@redhat.com>
Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com
Subject: Re: [PATCH 2/3] IPV6: unify 3 similar code path in ndisc_recv_ns()
Message-ID: <20040207051753.GC25484@conectiva.com.br>
References: <20040206.181006.79694138.yoshfuji@linux-ipv6.org> <20040206153201.126c88b8.davem@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040206153201.126c88b8.davem@redhat.com>
X-Url: http://advogato.org/person/acme
Organization: Conectiva S.A.
User-Agent: Mutt/1.5.5.1i
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i1750tKO009728
X-archive-position: 3080
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: acme@conectiva.com.br
Precedence: bulk
X-list: netdev

Em Fri, Feb 06, 2004 at 03:32:01PM -0800, David S. Miller escreveu:
> On Fri, 06 Feb 2004 18:10:06 +0900 (JST)
> YOSHIFUJI Hideaki / $B5HF#1QL@(B <yoshfuji@linux-ipv6.org> wrote:
> 
> > [PATCH 2/3] IPV6: unify 3 similar code path in ndisc_recv_ns()
> > 
> > D: Unify 3 similar code path in ndisc_recv_ns().
> > D: This patch also fixes:
> > D:  - flags sent with NA in reply to this NS
> > D:  - missing random delay after receipt of NS against anycast
> 
> Very nice consolidation of code.

Indeed, I'm out of the game for a while, swamped in distro work, but don't
worry... I'll be back! :-P

- Arnaldo


From yoshfuji@linux-ipv6.org Fri Feb  6 21:24:29 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 21:24:37 -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 i175ORKO010542
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 21:24:27 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 0434733CA5; Sat,  7 Feb 2004 14:25:20 +0900 (JST)
Date: Sat, 07 Feb 2004 14:25:19 +0900 (JST)
Message-Id: <20040207.142519.117436499.yoshfuji@linux-ipv6.org>
To: dlstevens@us.ibm.com
Cc: davem@redhat.com, hibi665@oki.com, netdev@oss.sgi.com,
        yoshfuji@linux-ipv6.org
Subject: Re: Source Specific Query of MLDv2 [PATCH]
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
In-Reply-To: <OF9F84892D.B2226F9C-ON88256E33.00185F62-88256E33.00196063@us.ibm.com>
References: <20040207.132233.21960944.yoshfuji@linux-ipv6.org>
	<OF9F84892D.B2226F9C-ON88256E33.00185F62-88256E33.00196063@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: 3081
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 <OF9F84892D.B2226F9C-ON88256E33.00185F62-88256E33.00196063@us.ibm.com> (at Fri, 6 Feb 2004 20:39:47 -0800), David Stevens <dlstevens@us.ibm.com> says:

> > Why not in icmpv6_rcv()?
> 
>       I don't understand this question. It's needed every place
> *except* icmpv6_rcv().

Sorry for any confusion.


> > > -     hdr = skb->nh.ipv6h;
> > > -     if (ipv6_chk_mcast_addr(skb->dev, &hdr->daddr, &hdr->saddr))
> > > -           deliver = 1;
> > > -
> 
> > Please do not remove this.
> > We need to check destination (but not source)
> > because the driver may be in "promisc." mode.
> 
>       I'm not removing it, I'm moving it. The original code
> is:
:
> 
> In promiscuous mode, it will parse the extension headers
> for non-local multicasts before dropping them. But what
> you suggested will do two multicast address look-ups for
> every multicast packet (including the valid ones). One
> for the destination and another for the destination/source
> filter.

Yes, but it changes the original and traditional behavior.

Well...

It is okay not to check destination here with good hardware / driver.
We however should check the destination before the process of 
extension headers for bad hardware / driver.
ipv6_chk_mcast_addr() in ip6_mc_input() has been helper for them
We should keep it in ip6_mc_input().

So... hmm... Let's check dev->flags ^ (IFF_PROMISC|IFF_ALLMULTI) like this.
I don't think it is so costy for usual operation.
If you think it is, please introduce hash table for mc_list in idev;
it should have been "heavy." :-)
(You can do it later, of course.)

===== net/ipv6/ip6_input.c 1.14 vs edited =====
--- 1.14/net/ipv6/ip6_input.c	Tue Jun 17 00:11:36 2003
+++ edited/net/ipv6/ip6_input.c	Sat Feb  7 14:14:30 2004
@@ -218,7 +218,8 @@
 	IP6_INC_STATS_BH(Ip6InMcastPkts);
 
 	hdr = skb->nh.ipv6h;
-	if (ipv6_chk_mcast_addr(skb->dev, &hdr->daddr, &hdr->saddr))
+	if ((skb->dev->flags ^ (IFF_PROMISC|IFF_ALLMULTI)) == 0 ||
+	    ipv6_chk_mcast_addr(skb->dev, &hdr->daddr, NULL))
 		deliver = 1;
 
 	/*
===== net/ipv6/mcast.c 1.50 vs edited =====
--- 1.50/net/ipv6/mcast.c	Thu Jan 29 09:06:25 2004
+++ edited/net/ipv6/mcast.c	Sat Feb  7 13:58:58 2004
@@ -918,7 +918,7 @@
 				break;
 		}
 		if (mc) {
-			if (!ipv6_addr_any(src_addr)) {
+			if (src_addr && !ipv6_addr_any(src_addr)) {
 				struct ip6_sf_list *psf;
 
 				spin_lock_bh(&mc->mca_lock);

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

From dlstevens@us.ibm.com Fri Feb  6 22:41:35 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 22:41:38 -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 i176fSKO012402
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 22:41:34 -0800
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i176ekwX055496;
	Sat, 7 Feb 2004 01:40:46 -0500
Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i176ejbP078750;
	Fri, 6 Feb 2004 23:40:46 -0700
In-Reply-To: <20040207.142519.117436499.yoshfuji@linux-ipv6.org>
Subject: Re: Source Specific Query of MLDv2 [PATCH]
To: YOSHIFUJI Hideaki /  =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
Cc: davem@redhat.com, hibi665@oki.com, netdev@oss.sgi.com,
        "Hideaki YOSHIFUJI" <yoshfuji@cerberus.hongo.wide.ad.jp>,
        yoshfuji@linux-ipv6.org
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF92ABDC1A.4056C324-ON88256E33.002267FA-88256E33.00247258@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Fri, 6 Feb 2004 22:40:42 -0800
X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November
 14, 2003) at 02/06/2004 23:40:46
MIME-Version: 1.0
Content-type: multipart/alternative; 
	Boundary="0__=07BBE4A0DFB1E16A8f9e8a93df938690918c07BBE4A0DFB1E16A"
Content-Disposition: inline
X-archive-position: 3083
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: 2188
Lines: 54

--0__=07BBE4A0DFB1E16A8f9e8a93df938690918c07BBE4A0DFB1E16A
Content-type: text/plain; charset=US-ASCII





Good idea; I'll incorporate all the comments, retest and repost.

> So... hmm... Let's check dev->flags ^ (IFF_PROMISC|IFF_ALLMULTI) like
this.

      I think you mean (dev->flags & (IFF_PROMISC|IFF_ALLMULTI)) here,
right?

> I don't think it is so costy for usual operation.
> If you think it is, please introduce hash table for mc_list in idev;
> it should have been "heavy." :-)
> (You can do it later, of course.)

This certainly could be done and I had this in mind for the future when
I designed the interface filter data structures (made sure everything
for the intersection and union is directly available given only the
ifmcaddr). I should do some testing to see how many MCA's or source
filters are needed to make a hash worthwhile, and maybe how many before
it falls over. :-)
                        thanks!
                              +-DLS
--0__=07BBE4A0DFB1E16A8f9e8a93df938690918c07BBE4A0DFB1E16A
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline

<html><body>
<p>Good idea; I'll incorporate all the comments, retest and repost.<br>
<br>
<tt>&gt; So... hmm... Let's check dev-&gt;flags ^ (IFF_PROMISC|IFF_ALLMULTI) like this.</tt><br>
<br>
<tt>	I think you mean (dev-&gt;flags &amp; (IFF_PROMISC|IFF_ALLMULTI)) here, right?</tt><br>
<tt><br>
&gt; I don't think it is so costy for usual operation.<br>
&gt; If you think it is, please introduce hash table for mc_list in idev;<br>
&gt; it should have been &quot;heavy.&quot; :-)<br>
&gt; (You can do it later, of course.)<br>
</tt><br>
<tt>This certainly could be done and I had this in mind for the future when<br>
I designed the interface filter data structures (made sure everything</tt><br>
<tt>for the intersection and union is directly available given only the</tt><br>
<tt>ifmcaddr). I should do some testing to see how many MCA's or source</tt><br>
<tt>filters are needed to make a hash worthwhile, and maybe how many before</tt><br>
<tt>it falls over. :-)</tt><br>
<tt>				thanks!</tt><br>
<tt>					+-DLS</tt></body></html>
--0__=07BBE4A0DFB1E16A8f9e8a93df938690918c07BBE4A0DFB1E16A--


From yoshfuji@linux-ipv6.org Fri Feb  6 22:45:11 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 22:45: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 i176jAKO012783
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 22:45:11 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 85A0633CA5; Sat,  7 Feb 2004 15:46:03 +0900 (JST)
Date: Sat, 07 Feb 2004 15:46:03 +0900 (JST)
Message-Id: <20040207.154603.51160771.yoshfuji@linux-ipv6.org>
To: dlstevens@us.ibm.com
Cc: davem@redhat.com, hibi665@oki.com, netdev@oss.sgi.com,
        yoshfuji@linux-ipv6.org
Subject: Re: Source Specific Query of MLDv2 [PATCH]
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
In-Reply-To: <OF92ABDC1A.4056C324-ON88256E33.002267FA-88256E33.00247258@us.ibm.com>
References: <20040207.142519.117436499.yoshfuji@linux-ipv6.org>
	<OF92ABDC1A.4056C324-ON88256E33.002267FA-88256E33.00247258@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: 3084
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: 596
Lines: 16

In article <OF92ABDC1A.4056C324-ON88256E33.002267FA-88256E33.00247258@us.ibm.com> (at Fri, 6 Feb 2004 22:40:42 -0800), David Stevens <dlstevens@us.ibm.com> says:

> Good idea; I'll incorporate all the comments, retest and repost.
> 
> > So... hmm... Let's check dev->flags ^ (IFF_PROMISC|IFF_ALLMULTI) like
> this.
> 
>       I think you mean (dev->flags & (IFF_PROMISC|IFF_ALLMULTI)) here,
> right?

Oops! Sorry, you're right...
And, it'd be good to use unlikely() here.

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

From hirofumi@mail.parknet.co.jp Fri Feb  6 23:03:57 2004
Received: with ECARTIS (v1.0.0; list netdev); Fri, 06 Feb 2004 23:04:00 -0800 (PST)
Received: from mail.parknet.co.jp (mail.parknet.co.jp [210.171.160.6])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1773uKO013433
	for <netdev@oss.sgi.com>; Fri, 6 Feb 2004 23:03:57 -0800
Received: from ibmpc.myhome.or.jp [210.171.164.65] by mail.parknet.co.jp with ESMTP
  (SMTPD32-4.10) id ACF16EFB0138; Sat, 07 Feb 2004 16:04:01 +0900
Received: from devron.myhome.or.jp (root@devron.myhome.or.jp [192.168.0.3])
	by ibmpc.myhome.or.jp (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1773qBl016768
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sat, 7 Feb 2004 16:03:54 +0900
Received: from devron.myhome.or.jp (hirofumi@localhost [127.0.0.1])
	by devron.myhome.or.jp (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i1773qLO005908
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sat, 7 Feb 2004 16:03:52 +0900
Received: (from hirofumi@localhost)
	by devron.myhome.or.jp (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i1773maU005905;
	Sat, 7 Feb 2004 16:03:48 +0900
To: "David S. Miller" <davem@redhat.com>
Cc: netdev@oss.sgi.com
Subject: [PATCH] af_unix: Fix path of /proc/net/unix
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date: Sat, 07 Feb 2004 16:03:48 +0900
Message-ID: <878yjf2wx7.fsf@devron.myhome.or.jp>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-archive-position: 3085
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: hirofumi@mail.parknet.co.jp
Precedence: bulk
X-list: netdev
Content-Length: 1481
Lines: 54

Hi,

/proc/net/unix on 2.4,
  c14e0580: 0000000C 00000000 00000000 0002 01   742 /dev/log
  c06bfa80: 00000002 00000000 00000000 0002 01 1019617 @0123 ...

/proc/net/unix on 2.6,
  c7c85d1c: 0000000C 00000000 00000000 0002 01  1021 /dev/log^@
  c551bd5c: 00000002 00000000 00000000 0002 01  5692 ^@0123 ... @

We should overwrite the first "nul" by "@" in the case of abstract
path, otherwise currently "netstat -x" can't print, at least.  And
normal one, odd "nul" was added.

This patch does behavior of 2.4. Please apply.


---

 net/unix/af_unix.c |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)

diff -puN net/unix/af_unix.c~af_unix-abstruct-fix net/unix/af_unix.c
--- linux-2.6.2/net/unix/af_unix.c~af_unix-abstruct-fix	2004-02-07 01:47:05.000000000 +0900
+++ linux-2.6.2-hirofumi/net/unix/af_unix.c	2004-02-07 03:39:06.000000000 +0900
@@ -1863,14 +1863,19 @@ static int unix_seq_show(struct seq_file
 			sock_i_ino(s));
 
 		if (u->addr) {
-			int i;
+			int i, len;
 			seq_putc(seq, ' ');
-			
-			for (i = 0; i < u->addr->len-sizeof(short); i++)
-				seq_putc(seq, u->addr->name->sun_path[i]);
 
-			if (UNIX_ABSTRACT(s))
+			i = 0;
+			len = u->addr->len - sizeof(short);
+			if (!UNIX_ABSTRACT(s))
+				len--;
+			else {
 				seq_putc(seq, '@');
+				i++;
+			}
+			for ( ; i < len; i++)
+				seq_putc(seq, u->addr->name->sun_path[i]);
 		}
 		unix_state_runlock(s);
 		seq_putc(seq, '\n');

_
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

From mika.penttila@kolumbus.fi Sat Feb  7 00:36:04 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 00:36:13 -0800 (PST)
Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i178a3KO017888
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 00:36:04 -0800
Received: from kolumbus.fi ([193.166.244.70])
          by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8)
          with ESMTP id 2004020710381238:6540 ;
          Sat, 7 Feb 2004 10:38:12 +0200 
Message-ID: <4024A488.60203@kolumbus.fi>
Date: Sat, 07 Feb 2004 10:40:40 +0200
From: =?ISO-8859-1?Q?Mika_Penttil=E4?= <mika.penttila@kolumbus.fi>
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
MIME-Version: 1.0
To: =?ISO-8859-1?Q?YOSHIFUJI_Hideaki_/_=3F=3F=3F=3F?=
 <yoshfuji@linux-ipv6.org>
CC: kazunori@miyazawa.org, davem@redhat.com, netdev@oss.sgi.com,
        usagi-core@linux-ipv6.org
Subject: Re: [PATCH][IPV6][NDISC] unify ipv6 output routine
References: <200402070232.33771.kazunori@miyazawa.org>	<4023D6FB.9010909@kolumbus.fi> <20040207.131455.27570445.yoshfuji@linux-ipv6.org>
In-Reply-To: <20040207.131455.27570445.yoshfuji@linux-ipv6.org>
X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June
 18, 2001) at 07.02.2004 10:38:12,
	Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March
 22, 2002) at 07.02.2004 10:37:25,
	Serialize complete at 07.02.2004 10:37:25
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i178a3KO017888
X-archive-position: 3086
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: mika.penttila@kolumbus.fi
Precedence: bulk
X-list: netdev
Content-Length: 2228
Lines: 82



YOSHIFUJI Hideaki / ???? wrote:

>In article <4023D6FB.9010909@kolumbus.fi> (at Fri, 06 Feb 2004 20:03:39 +0200), Mika Penttilä <mika.penttila@kolumbus.fi> says:
>
>  
>
>>Kazunori Miyazawa wrote:
>>    
>>
>:
>  
>
>>>Yoshifuji-san and I send the patch which unifies IPv6 output routine and remove
>>>RTF_NDISC again. It resolves an issue of IPv6 IPsec with neighbor discovery
>>>without a flag.
>>>      
>>>
>:
>  
>
>>You break multicast replies, see what ndisc_build_ll_hdr() does...
>>    
>>
>
>It doesn't "break." 
>The ip6_output2() resolves and inserts link-layer address appropriately.
>If it did, we would have noticed (by conformance test or even by
>usual operation). ;-)
>  
>
ip6_output2() doesn't resolve link-layer addresses. We don't even have a 
neighbour, in

ndisc_dst_alloc(dev, NULL, ip6_output2); case.


>BTW, Miyazawa-san, we do not need ndisc_build_ll_hdr() anymore.
>Compiler warns it. Please remove it. Thanks.
>
>
>Here's the description:
>
>dst->neighbour owns the neighbour entry for the destination. 
>
>For multicast, we know its link-layer address 
>(filled in ndisc_constructor()).
>For unicast, the link-layer address may be unknown.
>
>ip6_output2() will call ip6_output_finish() and
>it tries inserting the link-layer header.
>
>The destination link-layer address is used if it is known (*).
>(Note: you remember that we know link-layer address for multicast.)
>
>If the link-layer address is not known or invalid, 
>we queue the packet and resolve the link-layer address for the destination.
>Here, since the neighbour entry is "invalid," *multicast* NS is sent. 
>The NS packet passes similar path. 
>We know the destination for the NS is multicast and 
>what the link-layer address is, and the packet is sent via (*).
>We will send the queued packet when we got NA from that node.
>
>Real story:
>A node may send NS without source link-layer address option 
>while we do not know the link-layer address for the source of the NS.
>We need to send NA in reply to this NS.
>Original code cannot handle this case.  The new code path can.
>  
>

You just described how the normal link layer address resolving goes. It 
doesn't apply here. Again, there is no dst->neighbour.



--Mika





From yoshfuji@linux-ipv6.org Sat Feb  7 02:27:14 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 02:27:22 -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 i17ARBKO019916
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 02:27:14 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 88D8333CA5; Sat,  7 Feb 2004 19:28:04 +0900 (JST)
Date: Sat, 07 Feb 2004 19:28:04 +0900 (JST)
Message-Id: <20040207.192804.29120956.yoshfuji@linux-ipv6.org>
To: mika.penttila@kolumbus.fi
Cc: kazunori@miyazawa.org, davem@redhat.com, netdev@oss.sgi.com,
        usagi-core@linux-ipv6.org
Subject: Re: [PATCH][IPV6][NDISC] unify ipv6 output routine
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
In-Reply-To: <4024A488.60203@kolumbus.fi>
References: <4023D6FB.9010909@kolumbus.fi>
	<20040207.131455.27570445.yoshfuji@linux-ipv6.org>
	<4024A488.60203@kolumbus.fi>
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-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i17ARBKO019916
X-archive-position: 3087
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: 1345
Lines: 34

In article <4024A488.60203@kolumbus.fi> (at Sat, 07 Feb 2004 10:40:40 +0200), Mika Penttilä <mika.penttila@kolumbus.fi> says:

> >The ip6_output2() resolves and inserts link-layer address appropriately.
> >If it did, we would have noticed (by conformance test or even by
> >usual operation). ;-)
> >  
> >
> ip6_output2() doesn't resolve link-layer addresses. We don't even have a 
> neighbour, in
> ndisc_dst_alloc(dev, NULL, ip6_output2); case.

ip6_output2() calls ip6_output_flinish().
ip6_output_finish() calls dst->hh->hh_output() if hh is already built.
Otherwise, dst->neighbour->output() is called and it resolves 
link-layer address of neighbor.

I think you missed our ndsic_dst_alloc() change.
ndisc_dst_alloc() takes 4 argument:
   struct dst_entry *ndisc_dst_alloc(struct net_device *dev, 
                                     struct neighbour *neigh,
                                     struct in6_addr *addr,
                                     int (*output)(struct sk_buff *));
If neigh is NULL, we do ndisc_get_neigh(dev, addr) to get one.


> You just described how the normal link layer address resolving goes. It 
> doesn't apply here. Again, there is no dst->neighbour.

There IS with our patch.

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


From marcel@holtmann.org Sat Feb  7 03:14:06 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 03:14:14 -0800 (PST)
Received: from mail.holtmann.net (root@linux-bt.org [217.160.111.169])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i17BE4KO022629
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 03:14:05 -0800
Received: from pegasus (p5082BACF.dip.t-dialin.net [80.130.186.207])
	by mail.holtmann.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i17BETV4011048;
	Sat, 7 Feb 2004 12:14:29 +0100
Subject: Re: some bluetooth fixes
From: Marcel Holtmann <marcel@holtmann.org>
To: Andi Kleen <ak@suse.de>
Cc: bluez-devel@lists.sourceforge.net, netdev@oss.sgi.com,
        viro@zenII.linux.org.uk
In-Reply-To: <20040207032428.56ffbebc.ak@suse.de>
References: <20040206050042.20a2b3b0.ak@suse.de>
	 <1076079512.2806.40.camel@pegasus>  <20040207032428.56ffbebc.ak@suse.de>
Content-Type: text/plain
Message-Id: <1076152411.14418.73.camel@pegasus>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Sat, 07 Feb 2004 12:13:31 +0100
Content-Transfer-Encoding: 7bit
X-archive-position: 3088
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: marcel@holtmann.org
Precedence: bulk
X-list: netdev
Content-Length: 2829
Lines: 79

Hi Andi,

> > > diff -u linux-2.6.2-work32/net/bluetooth/hci_sock.c-o linux-2.6.2-work32/net/bluetooth/hci_sock.c
> > > --- linux-2.6.2-work32/net/bluetooth/hci_sock.c-o	2004-02-05 08:09:54.000000000 +0100
> > > +++ linux-2.6.2-work32/net/bluetooth/hci_sock.c	2004-02-05 14:57:59.000000000 +0100
> > > @@ -392,6 +392,8 @@
> > >  
> > >  	skb->pkt_type = *((unsigned char *) skb->data);
> > >  	skb_pull(skb, 1);
> > > +	/* AK: looks broken. Who guarantees that hdev doesn't go away while
> > > +	   the skb is queued ? */
> > >  	skb->dev = (void *) hdev;
> > >  
> > >  	if (skb->pkt_type == HCI_COMMAND_PKT) {
> > 
> > Why should hdev go away?
> 
> Because the skbuff is queued, but there is no reference count to keep the device around.
> I wasn't 100% sure on that, so I just commented it. Feel free to remove if you think
> it's correct.

The queue itself is part of the hdev structure and the only call that
let hdev go away is hci_unregister_dev and this clears the queue. So I
don't see a problem here.

> > > diff -u linux-2.6.2-work32/net/bluetooth/hci_conn.c-o linux-2.6.2-work32/net/bluetooth/hci_conn.c
> > > --- linux-2.6.2-work32/net/bluetooth/hci_conn.c-o	2004-02-05 08:09:54.000000000 +0100
> > > +++ linux-2.6.2-work32/net/bluetooth/hci_conn.c	2004-02-05 15:06:10.000000000 +0100
> > > @@ -353,21 +353,24 @@
> > >  	struct hci_conn_info *ci;
> > >  	struct hci_dev *hdev;
> > >  	struct list_head *p;
> > > -	int n = 0, size;
> > > +	int n = 0, size, err;
> > >  
> > >  	if (copy_from_user(&req, (void *) arg, sizeof(req)))
> > >  		return -EFAULT;
> > >  
> > > -	if (!(hdev = hci_dev_get(req.dev_id)))
> > > -		return -ENODEV;
> > > +	if (req.conn_num >= (2*PAGE_SIZE)/sizeof(struct hci_conn_info))
> > > +		return -EINVAL; 
> > >  
> > >  	size = req.conn_num * sizeof(struct hci_conn_info) + sizeof(req);
> > >  
> > > -	if (verify_area(VERIFY_WRITE, (void *)arg, size))
> > > -		return -EFAULT;
> > > -
> > >  	if (!(cl = (void *) kmalloc(size, GFP_KERNEL)))
> > >  		return -ENOMEM;
> > > +
> > > +	if (!(hdev = hci_dev_get(req.dev_id))) { 
> > > +		kfree(cl);
> > > +		return -ENODEV;
> > > +	}
> > > +
> > >  	ci = cl->conn_info;
> > >  
> > >  	hci_dev_lock_bh(hdev);
> > 
> > Why 2*PAGE_SIZE in this case? What is different?
> 
> It's just an arbitary number. Mainly to stop overflow attacks on 
> user controlled values. e.g. user can pass UINT_MAX for conn_num.
> The kmalloc would overflow and succeed. But a later loop running
> through the values could do wrong things on the too small buffer.
> The code seems to not be vunerable to this, but only by luck.
> 
> Also in general it's good practice to stop user controlled kmalloc
> at a reasonable size.

I check this. Maybe we have more of them. What do you propose as max
size value for kmalloc? 2*PAGE_SIZE or 4*PAGE_SIZE?

Regards

Marcel



From mika.penttila@kolumbus.fi Sat Feb  7 03:26:05 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 03:26:09 -0800 (PST)
Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i17BQ3KO023172
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 03:26:04 -0800
Received: from kolumbus.fi ([193.166.244.70])
          by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8)
          with ESMTP id 2004020712431353:6612 ;
          Sat, 7 Feb 2004 12:43:13 +0200 
Message-ID: <4024C1D5.5030906@kolumbus.fi>
Date: Sat, 07 Feb 2004 12:45:41 +0200
From: =?ISO-8859-1?Q?Mika_Penttil=E4?= <mika.penttila@kolumbus.fi>
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
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Mika_Penttil=E4?= <mika.penttila@kolumbus.fi>
CC: YOSHIFUJI Hideaki / ???? <yoshfuji@linux-ipv6.org>, kazunori@miyazawa.org,
        davem@redhat.com, netdev@oss.sgi.com, usagi-core@linux-ipv6.org
Subject: Re: [PATCH][IPV6][NDISC] unify ipv6 output routine
References: <4023D6FB.9010909@kolumbus.fi>	<20040207.131455.27570445.yoshfuji@linux-ipv6.org>	<4024A488.60203@kolumbus.fi> <20040207.192804.29120956.yoshfuji@linux-ipv6.org> <4024C0EA.1010904@kolumbus.fi>
In-Reply-To: <4024C0EA.1010904@kolumbus.fi>
X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June
 18, 2001) at 07.02.2004 12:43:13,
	Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March
 22, 2002) at 07.02.2004 13:27:25,
	Serialize complete at 07.02.2004 13:27:25
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i17BQ3KO023172
X-archive-position: 3089
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: mika.penttila@kolumbus.fi
Precedence: bulk
X-list: netdev
Content-Length: 1648
Lines: 60



Mika Penttilä wrote:

>
>
> YOSHIFUJI Hideaki / ???? wrote:
>
>> In article <4024A488.60203@kolumbus.fi> (at Sat, 07 Feb 2004 10:40:40 
>> +0200), Mika Penttilä <mika.penttila@kolumbus.fi> says:
>>
>>  
>>
>>>> The ip6_output2() resolves and inserts link-layer address 
>>>> appropriately.
>>>> If it did, we would have noticed (by conformance test or even by
>>>> usual operation). ;-)
>>>>
>>>>
>>>>     
>>>
>>> ip6_output2() doesn't resolve link-layer addresses. We don't even 
>>> have a neighbour, in
>>> ndisc_dst_alloc(dev, NULL, ip6_output2); case.
>>>   
>>
>>
>> ip6_output2() calls ip6_output_flinish().
>> ip6_output_finish() calls dst->hh->hh_output() if hh is already built.
>> Otherwise, dst->neighbour->output() is called and it resolves 
>> link-layer address of neighbor.
>>
>> I think you missed our ndsic_dst_alloc() change.
>> ndisc_dst_alloc() takes 4 argument:
>>   struct dst_entry *ndisc_dst_alloc(struct net_device *dev, 
>>                                     struct neighbour *neigh,
>>                                     struct in6_addr *addr,
>>                                     int (*output)(struct sk_buff *));
>> If neigh is NULL, we do ndisc_get_neigh(dev, addr) to get one.
>>
>>  
>>
> hmm. where is this ndisc_dst_alloc() change? In the patch it's called 
> with three params, only the output routine is changed :
>
> - dst = ndisc_dst_alloc(dev, NULL, ndisc_output);
> + dst = ndisc_dst_alloc(dev, NULL, ip6_output2);
>
>
> --Mika
>
I see, it was in a follow-up patch. Ok, I was just looking at the 
original patch, which didn't work. But with this ndisc_dst_alloc() 
change it's ok.

Thanks,
--Mika




From yoshfuji@linux-ipv6.org Sat Feb  7 03:29:04 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 03:29:07 -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 i17BT3KO023622
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 03:29:03 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 79DDA33CA5; Sat,  7 Feb 2004 20:29:56 +0900 (JST)
Date: Sat, 07 Feb 2004 20:29:56 +0900 (JST)
Message-Id: <20040207.202956.74336171.yoshfuji@linux-ipv6.org>
To: mika.penttila@kolumbus.fi
Cc: kazunori@miyazawa.org, davem@redhat.com, netdev@oss.sgi.com,
        usagi-core@linux-ipv6.org
Subject: Re: (usagi-core 17380) Re: [PATCH][IPV6][NDISC] unify ipv6 output
 routine
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
In-Reply-To: <4024C1D5.5030906@kolumbus.fi>
References: <20040207.192804.29120956.yoshfuji@linux-ipv6.org>
	<4024C0EA.1010904@kolumbus.fi>
	<4024C1D5.5030906@kolumbus.fi>
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-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i17BT3KO023622
X-archive-position: 3090
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: 1270
Lines: 33

In article <4024C1D5.5030906@kolumbus.fi> (at Sat, 07 Feb 2004 12:45:41 +0200), Mika Penttilä <mika.penttila@kolumbus.fi> says:

> >> I think you missed our ndsic_dst_alloc() change.
> >> ndisc_dst_alloc() takes 4 argument:
> >>   struct dst_entry *ndisc_dst_alloc(struct net_device *dev, 
> >>                                     struct neighbour *neigh,
> >>                                     struct in6_addr *addr,
> >>                                     int (*output)(struct sk_buff *));
> >> If neigh is NULL, we do ndisc_get_neigh(dev, addr) to get one.
> >>
> >>  
> >>
> > hmm. where is this ndisc_dst_alloc() change? In the patch it's called 
> > with three params, only the output routine is changed :
> >
> > - dst = ndisc_dst_alloc(dev, NULL, ndisc_output);
> > + dst = ndisc_dst_alloc(dev, NULL, ip6_output2);
:
> I see, it was in a follow-up patch. Ok, I was just looking at the 
> original patch, which didn't work. But with this ndisc_dst_alloc() 
> change it's ok.

Oh my god!!

Miyazawa-san failed to export our "correct" code in original patch.
I didn't noticed that.

We're sorry about it. Thank you for spotting the bug.

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


From ak@suse.de Sat Feb  7 03:57:35 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 03:57:41 -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 i17BvYKO024321
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 03:57:35 -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 B6C5016D176; Sat,  7 Feb 2004 12:57:28 +0100 (CET)
Date: Sat, 7 Feb 2004 12:57:23 +0100
From: Andi Kleen <ak@suse.de>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: bluez-devel@lists.sourceforge.net, netdev@oss.sgi.com,
        viro@zenII.linux.org.uk
Subject: Re: some bluetooth fixes
Message-Id: <20040207125723.391a1fcd.ak@suse.de>
In-Reply-To: <1076152411.14418.73.camel@pegasus>
References: <20040206050042.20a2b3b0.ak@suse.de>
	<1076079512.2806.40.camel@pegasus>
	<20040207032428.56ffbebc.ak@suse.de>
	<1076152411.14418.73.camel@pegasus>
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: 3091
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: 409
Lines: 12

On Sat, 07 Feb 2004 12:13:31 +0100
Marcel Holtmann <marcel@holtmann.org> wrote:

> I check this. Maybe we have more of them. What do you propose as max
> size value for kmalloc? 2*PAGE_SIZE or 4*PAGE_SIZE?

What better fits the intended use case. I don't know how many objects are expected
here. Smaller is better probably.

If you want to handle more objects this way you should use seq_file instead.

-Andi

From schwab@suse.de Sat Feb  7 06:18:50 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 06:18:54 -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 i17EIdKO029846
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 06:18:40 -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 C4B8916D39C; Sat,  7 Feb 2004 14:35:45 +0100 (CET)
Received: by sykes.suse.de (Postfix, from userid 597)
	id 3A70D14C9F452; Sat,  7 Feb 2004 14:35:45 +0100 (CET)
To: cramerj@intel.com
Cc: netdev@oss.sgi.com
Subject: Bad UDP checksum with 82540EM
From: Andreas Schwab <schwab@suse.de>
X-Yow: If Robert Di Niro assassinates Walter Slezak, will
 Jodie Foster marry Bonzo??
Date: Sat, 07 Feb 2004 14:35:45 +0100
Message-ID: <je65ejvwpa.fsf@sykes.suse.de>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-archive-position: 3092
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: schwab@suse.de
Precedence: bulk
X-list: netdev
Content-Length: 1028
Lines: 26

I'm getting bad UPD checksums in outgoing packets with the e1000 driver
(version 5.2.16) in 2.6.1 when using HW checksumming on a HP branded
82540EM on ia64 (TCP works fine).  The same driver works fine with an
Intel branded chip.  The two devices are identified as follows:

  Model: "Hewlett-Packard Company 82540EM Gigabit Ethernet Controller"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x100e "82540EM Gigabit Ethernet Controller"
  SubVendor: pci 0x103c "Hewlett-Packard Company"
  SubDevice: pci 0x1274 

  Model: "Intel 82540EM Gigabit Ethernet Controller"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x100e "82540EM Gigabit Ethernet Controller"
  SubVendor: pci 0x8086 "Intel Corporation"
  SubDevice: pci 0x3402 

After disabling tx-checksumming UDP is working again.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

From hch@lst.de Sat Feb  7 06:44:10 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 06:44:13 -0800 (PST)
Received: from mail.lst.de (verein.lst.de [212.34.189.10])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i17Ei8KO030628
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 06:44:09 -0800
Received: from verein.lst.de (localhost [127.0.0.1])
	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i17Ei5Qc019467
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 15:44:06 +0100
Received: (from hch@localhost)
	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i17Ei5Ts019465
	for netdev@oss.sgi.com; Sat, 7 Feb 2004 15:44:05 +0100
Date: Sat, 7 Feb 2004 15:44:05 +0100
From: Christoph Hellwig <hch@lst.de>
To: netdev@oss.sgi.com
Subject: [PATCH][RFC] use completions instead of sleep_on for rpciod
Message-ID: <20040207144405.GA19416@lst.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-Spam-Score: -4.901 () BAYES_00
X-Scanned-By: MIMEDefang 2.39
X-archive-position: 3093
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: hch@lst.de
Precedence: bulk
X-list: netdev
Content-Length: 2527
Lines: 95

[let's hope some sunrpc folks are on this list, too, the nfs list
 mentioned in MAINTAINERS refuses postings from non-subsribers..]

The rpciod shutdown code gives ugly sleep_on without BKL warnings in
-mm.  And it looks indeed somewhat racy.

The easy fix would be to simply use a completion as in the patch below,
but that removes all the signal fuzzing semantics the current code has.
I don't really understand why we want to cancel the operation by
signals, but I think it'd be better to leave that to people familar with
the code anyway..


--- 1.27/net/sunrpc/sched.c	Fri Jun 20 22:16:26 2003
+++ edited/net/sunrpc/sched.c	Wed Feb  4 06:29:02 2004
@@ -71,7 +71,7 @@
  * rpciod-related stuff
  */
 static DECLARE_WAIT_QUEUE_HEAD(rpciod_idle);
-static DECLARE_WAIT_QUEUE_HEAD(rpciod_killer);
+static DECLARE_COMPLETION(rpciod_killer);
 static DECLARE_MUTEX(rpciod_sema);
 static unsigned int		rpciod_users;
 static pid_t			rpciod_pid;
@@ -950,7 +950,6 @@
 static int
 rpciod(void *ptr)
 {
-	wait_queue_head_t *assassin = (wait_queue_head_t*) ptr;
 	int		rounds = 0;
 
 	lock_kernel();
@@ -992,11 +991,11 @@
 		rpciod_killall();
 	}
 
-	rpciod_pid = 0;
-	wake_up(assassin);
-
 	dprintk("RPC: rpciod exiting\n");
 	unlock_kernel();
+
+	rpciod_pid = 0;
+	complete_and_exit(&rpciod_killer, 0);
 	return 0;
 }
 
@@ -1041,7 +1040,7 @@
 	/*
 	 * Create the rpciod thread and wait for it to start.
 	 */
-	error = kernel_thread(rpciod, &rpciod_killer, 0);
+	error = kernel_thread(rpciod, NULL, 0);
 	if (error < 0) {
 		printk(KERN_WARNING "rpciod_up: create thread failed, error=%d\n", error);
 		rpciod_users--;
@@ -1057,8 +1056,6 @@
 void
 rpciod_down(void)
 {
-	unsigned long flags;
-
 	down(&rpciod_sema);
 	dprintk("rpciod_down pid %d sema %d\n", rpciod_pid, rpciod_users);
 	if (rpciod_users) {
@@ -1073,27 +1070,8 @@
 	}
 
 	kill_proc(rpciod_pid, SIGKILL, 1);
-	/*
-	 * Usually rpciod will exit very quickly, so we
-	 * wait briefly before checking the process id.
-	 */
-	clear_thread_flag(TIF_SIGPENDING);
-	yield();
-	/*
-	 * Display a message if we're going to wait longer.
-	 */
-	while (rpciod_pid) {
-		dprintk("rpciod_down: waiting for pid %d to exit\n", rpciod_pid);
-		if (signalled()) {
-			dprintk("rpciod_down: caught signal\n");
-			break;
-		}
-		interruptible_sleep_on(&rpciod_killer);
-	}
-	spin_lock_irqsave(&current->sighand->siglock, flags);
-	recalc_sigpending();
-	spin_unlock_irqrestore(&current->sighand->siglock, flags);
-out:
+	wait_for_completion(&rpciod_killer);
+ out:
 	up(&rpciod_sema);
 }
 

From marcel@holtmann.org Sat Feb  7 08:58:21 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 08:58:24 -0800 (PST)
Received: from mail.holtmann.net (root@linux-bt.org [217.160.111.169])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i17GwJKO003303
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 08:58:20 -0800
Received: from pegasus (p5082B974.dip.t-dialin.net [80.130.185.116])
	by mail.holtmann.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i17GwjV4013528;
	Sat, 7 Feb 2004 17:58:46 +0100
Subject: Re: some bluetooth fixes
From: Marcel Holtmann <marcel@holtmann.org>
To: Andi Kleen <ak@suse.de>
Cc: bluez-devel@lists.sourceforge.net, netdev@oss.sgi.com,
        viro@zenII.linux.org.uk
In-Reply-To: <20040207125723.391a1fcd.ak@suse.de>
References: <20040206050042.20a2b3b0.ak@suse.de>
	 <1076079512.2806.40.camel@pegasus> <20040207032428.56ffbebc.ak@suse.de>
	 <1076152411.14418.73.camel@pegasus>  <20040207125723.391a1fcd.ak@suse.de>
Content-Type: multipart/mixed; boundary="=-khpDIt7H5QVmzre/GLkY"
Message-Id: <1076173068.2670.4.camel@pegasus>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Sat, 07 Feb 2004 17:57:48 +0100
X-archive-position: 3094
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: marcel@holtmann.org
Precedence: bulk
X-list: netdev
Content-Length: 5239
Lines: 219


--=-khpDIt7H5QVmzre/GLkY
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi Andi,

> > I check this. Maybe we have more of them. What do you propose as max
> > size value for kmalloc? 2*PAGE_SIZE or 4*PAGE_SIZE?
> 
> What better fits the intended use case. I don't know how many objects are expected
> here. Smaller is better probably.

I now looked carefully through your patch and changed and added some
parts to better fit into. I also fixed another RFCOMM refcount bug.
Please review it, before I send it to Dave.

> If you want to handle more objects this way you should use seq_file instead.

The general plan is to move over to sysfs.

Regards

Marcel


--=-khpDIt7H5QVmzre/GLkY
Content-Disposition: attachment; filename=patch
Content-Type: text/x-patch; name=patch; charset=iso-8859-15
Content-Transfer-Encoding: 7bit

diff -Nru a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
--- a/net/bluetooth/hci_conn.c	Sat Feb  7 17:52:09 2004
+++ b/net/bluetooth/hci_conn.c	Sat Feb  7 17:52:09 2004
@@ -353,21 +353,24 @@
 	struct hci_conn_info *ci;
 	struct hci_dev *hdev;
 	struct list_head *p;
-	int n = 0, size;
+	int n = 0, size, err;
 
 	if (copy_from_user(&req, (void *) arg, sizeof(req)))
 		return -EFAULT;
 
-	if (!(hdev = hci_dev_get(req.dev_id)))
-		return -ENODEV;
-
-	size = req.conn_num * sizeof(struct hci_conn_info) + sizeof(req);
+	size = sizeof(req) + req.conn_num * sizeof(*ci);
 
-	if (verify_area(VERIFY_WRITE, (void *)arg, size))
-		return -EFAULT;
+	if (size > PAGE_SIZE * 2)
+		return -EINVAL;
 
 	if (!(cl = (void *) kmalloc(size, GFP_KERNEL)))
 		return -ENOMEM;
+
+	if (!(hdev = hci_dev_get(req.dev_id))) {
+		kfree(cl);
+		return -ENODEV;
+	}
+
 	ci = cl->conn_info;
 
 	hci_dev_lock_bh(hdev);
@@ -381,20 +384,21 @@
 		(ci + n)->out   = c->out;
 		(ci + n)->state = c->state;
 		(ci + n)->link_mode = c->link_mode;
-		n++;
+		if (++n >= req.conn_num)
+			break;
 	}
 	hci_dev_unlock_bh(hdev);
 
 	cl->dev_id = hdev->id;
 	cl->conn_num = n;
-	size = n * sizeof(struct hci_conn_info) + sizeof(req);
+	size = sizeof(req) + n * sizeof(*ci);
 
 	hci_dev_put(hdev);
 
-	copy_to_user((void *) arg, cl, size);
+	err = copy_to_user((void *) arg, cl, size);
 	kfree(cl);
 
-	return 0;
+	return err ? -EFAULT : 0;
 }
 
 int hci_get_conn_info(struct hci_dev *hdev, unsigned long arg)
@@ -407,9 +411,6 @@
 	if (copy_from_user(&req, (void *) arg, sizeof(req)))
 		return -EFAULT;
 
-	if (verify_area(VERIFY_WRITE, ptr, sizeof(ci)))
-		return -EFAULT;
-
 	hci_dev_lock_bh(hdev);
 	conn = hci_conn_hash_lookup_ba(hdev, req.type, &req.bdaddr);
 	if (conn) {
@@ -425,6 +426,5 @@
 	if (!conn)
 		return -ENOENT;
 
-	copy_to_user(ptr, &ci, sizeof(ci));
-	return 0;
+	return copy_to_user(ptr, &ci, sizeof(ci)) ? -EFAULT : 0;
 }
diff -Nru a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
--- a/net/bluetooth/hci_core.c	Sat Feb  7 17:52:09 2004
+++ b/net/bluetooth/hci_core.c	Sat Feb  7 17:52:09 2004
@@ -716,7 +716,7 @@
 	struct hci_dev_list_req *dl;
 	struct hci_dev_req *dr;
 	struct list_head *p;
-	int n = 0, size;
+	int n = 0, size, err;
 	__u16 dev_num;
 
 	if (get_user(dev_num, (__u16 *) arg))
@@ -724,14 +724,15 @@
 
 	if (!dev_num)
 		return -EINVAL;
-	
-	size = dev_num * sizeof(*dr) + sizeof(*dl);
 
-	if (verify_area(VERIFY_WRITE, (void *) arg, size))
-		return -EFAULT;
+	size = sizeof(*dl) + dev_num * sizeof(*dr);
+
+	if (size > PAGE_SIZE * 2)
+		return -EINVAL;
 
 	if (!(dl = kmalloc(size, GFP_KERNEL)))
 		return -ENOMEM;
+
 	dr = dl->dev_req;
 
 	read_lock_bh(&hci_dev_list_lock);
@@ -746,12 +747,12 @@
 	read_unlock_bh(&hci_dev_list_lock);
 
 	dl->dev_num = n;
-	size = n * sizeof(*dr) + sizeof(*dl);
+	size = sizeof(*dl) + n * sizeof(*dr);
 
-	copy_to_user((void *) arg, dl, size);
+	err = copy_to_user((void *) arg, dl, size);
 	kfree(dl);
 
-	return 0;
+	return err ? -EFAULT : 0;
 }
 
 int hci_get_dev_info(unsigned long arg)
diff -Nru a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
--- a/net/bluetooth/rfcomm/tty.c	Sat Feb  7 17:52:09 2004
+++ b/net/bluetooth/rfcomm/tty.c	Sat Feb  7 17:52:09 2004
@@ -349,7 +349,7 @@
 	struct rfcomm_dev_list_req *dl;
 	struct rfcomm_dev_info *di;
 	struct list_head *p;
-	int n = 0, size;
+	int n = 0, size, err;
 	u16 dev_num;
 
 	BT_DBG("");
@@ -362,8 +362,8 @@
 
 	size = sizeof(*dl) + dev_num * sizeof(*di);
 
-	if (verify_area(VERIFY_WRITE, (void *)arg, size))
-		return -EFAULT;
+	if (size > PAGE_SIZE * 4)
+		return -EINVAL;
 
 	if (!(dl = kmalloc(size, GFP_KERNEL)))
 		return -ENOMEM;
@@ -389,9 +389,10 @@
 	dl->dev_num = n;
 	size = sizeof(*dl) + n * sizeof(*di);
 
-	copy_to_user((void *) arg, dl, size);
+	err = copy_to_user((void *) arg, dl, size);
 	kfree(dl);
-	return 0;
+
+	return err ? -EFAULT : 0;
 }
 
 static int rfcomm_get_dev_info(unsigned long arg)
@@ -563,8 +564,10 @@
 	set_bit(RFCOMM_TTY_ATTACHED, &dev->flags);
 
 	err = rfcomm_dlc_open(dlc, &dev->src, &dev->dst, dev->channel);
-	if (err < 0)
+	if (err < 0) {
+		rfcomm_dev_put(dev);
 		return err;
+	}
 
 	/* Wait for DLC to connect */
 	add_wait_queue(&dev->wait, &wait);
@@ -588,6 +591,9 @@
 	}
 	set_current_state(TASK_RUNNING);
 	remove_wait_queue(&dev->wait, &wait);
+
+	if (err < 0)
+		rfcomm_dev_put(dev);
 
 	return err;
 }

--=-khpDIt7H5QVmzre/GLkY--


From gandalf@digital.net Sat Feb  7 09:36:22 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 09:36:25 -0800 (PST)
Received: from lakemtao06.cox.net (lakemtao06.cox.net [68.1.17.115])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i17HaLKO004094
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 09:36:21 -0800
Received: from [192.168.1.94] ([68.0.106.3]) by lakemtao06.cox.net
          (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
          id <20040207173616.HUNQ24575.lakemtao06.cox.net@[192.168.1.94]>
          for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 12:36:16 -0500
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Sat, 07 Feb 2004 11:36:14 -0600
Subject: Fragmentation Attack
From: Gandalf The White <gandalf@digital.net>
To: Linux IPStack <netdev@oss.sgi.com>
Message-ID: <BC4A7E2E.E256%gandalf@digital.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-archive-position: 3095
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: gandalf@digital.net
Precedence: bulk
X-list: netdev
Content-Length: 3804
Lines: 81

Greetings and Salutations:

I have been directed to this mailing list for discussion of something I
worked on.  I am hoping that given the specifics that the Linux OS can be
fine tuned to fix this issue.

I recently received my GCFW (GIAC Certified Firewall Analyst) certification
from SANS.  Part of the certification requires completing a "practical", a
security paper.  In the certification we are required to "attack" another
practical that has been previously passed.  While working on this portion of
the paper I came up with (I believe) a unique DoS (Denial Of Service) attack
that affects the operation of most operating systems, but in this case we
are discussing Linux.

The "Rose" attack (as I call it) is described at:
http://digital.net/~gandalf/Rose.rtf

A summary of the attack:
1) The first (very small, 30 bytes) fragment of a ICMP packet is sent.  This
is offset 0 with the complete and correct ICMP header
2) The last fragment (again, very small) of a 64k sized fragment is sent.
3) This process is repeated with a UDP packet and a TCP packet

The end result is that on my 450 MHz Linux box the CPU utilization went to
100% utilization.  I had a fragmented ping from another computer running at
the same time, most fragmented pings were replied to, a few were missed.
The Linux box I was "attacking" returned to normal when I stopped the
attack.

The other interesting feature of this attack that I have seen is that the
source IP address and the source and destination port do not matter.  On any
device.  Since the packet is never fully assembled the upper levels of the
IP stack never validate that the destination port is valid.

I also noticed that different machines handled the ICMP reassembly Time
Required error packet differently, thus this could be used for OS
fingerprinting.

I have cleaned up (revisited) the attack since I wrote the paper.  As
written the original will work the same as my cleaned up version (but below
is the "technically correct" version).  I fixed my input into the nemesis
program (as written in the above paper) as follows.
See http://www.packetfactory.net/projects/nemesis/ for the software:
nemesis icmp -S 10.3.64.121 -D 172.16.1.100 -d1 -i 8 -I 7242 -P
Picmpdata.txt -FM0
nemesis ip -S 10.3.64.121 -D 172.16.1.100 -d1 -I 7242 -p 1 -P Picmpdata.txt
-F8100
nemesis tcp -S 10.196.212.207 -D 172.16.1.100 -d1 -I 2153 -s 2494456820 -x
36961 -y 63398 -P Ptcpdata.txt -FM0
nemesis ip -S 10.196.212.207 -D 172.16.1.100 -d1 -I 2153 -p 6 -P
Ptcpdata.txt -F8100
nemesis udp -S 10.195.74.172 -D 172.16.1.100 -d1 -I 6316 -x 13253 -y 20460
-P Pudpdata.txt -FM0
nemesis ip -S 10.195.74.172 -D 172.16.1.100 -d1 -I 6316 -p 17 -P
Pudpdata.txt -F8100

For testing I generated a Excel spreadsheet to put random values for many of
the fields above (source IP, Sport, Dport) and thousands of packets to test
against the Linux box. I ran the test using nemesis (which is, of course,
too slow to affect the Linux box) and captured the packets using netwox54 :
See http://www.laurentconstantin.com/en/netw/netwox/ for netwox.

After that had finished running for about 9 hours or so I was able to dump
the captured packets back out all at one time using netwox54 again.  This is
where the DoS took place, throwing all those packets at the box at once.

If you want step by step instructions I can provide them.

This is FYI, I am hoping that protection against this attack can be found.

Ken

---------------------------------------------------------------
Do not meddle in the affairs of wizards for they are subtle and
quick to anger.
Ken Hollis - Gandalf The White - gandalf@digital.net - O- TINLC
WWW Page - http://digital.net/~gandalf/
Trace E-Mail forgery - http://digital.net/~gandalf/spamfaq.html
Trolls crossposts - http://digital.net/~gandalf/trollfaq.html



From davem@redhat.com Sat Feb  7 09:45:26 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 09:45:30 -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 i17HjQKO004556
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 09:45:26 -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 i17HjPb17527;
	Sat, 7 Feb 2004 12:45:25 -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 i17HjPa08216;
	Sat, 7 Feb 2004 12:45:25 -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 i17HiqkC002681;
	Sat, 7 Feb 2004 12:44:53 -0500
Date: Sat, 7 Feb 2004 09:45:24 -0800
From: "David S. Miller" <davem@redhat.com>
To: Gandalf The White <gandalf@digital.net>
Cc: netdev@oss.sgi.com
Subject: Re: Fragmentation Attack
Message-Id: <20040207094524.495e883d.davem@redhat.com>
In-Reply-To: <BC4A7E2E.E256%gandalf@digital.net>
References: <BC4A7E2E.E256%gandalf@digital.net>
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: 3096
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: 579
Lines: 16

On Sat, 07 Feb 2004 11:36:14 -0600
Gandalf The White <gandalf@digital.net> wrote:

> If you want step by step instructions I can provide them.

What makes your DoS interesting is whether the attacker needs
a lot of bandwidth or not.  Ie. if he has to be sitting on your
gigabit subnet then the attack isn't interesting.  Whereas if he
can eat all of the remote systems cpu cycles just being behind a
cable modem, that's interesting.

Which is it?

Also have you done your cpu utilization tests on something a little
less ancient than a 450mhz system?  How fast was the network?


From gandalf@digital.net Sat Feb  7 10:00:57 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 10:01:04 -0800 (PST)
Received: from lakemtao05.cox.net (lakemtao05.cox.net [68.1.17.116])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i17I0uKO005099
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 10:00:57 -0800
Received: from [192.168.1.94] ([68.0.106.3]) by lakemtao05.cox.net
          (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
          id <20040207180047.MGQU29834.lakemtao05.cox.net@[192.168.1.94]>;
          Sat, 7 Feb 2004 13:00:47 -0500
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Sat, 07 Feb 2004 12:00:42 -0600
Subject: Re: Fragmentation Attack
From: Gandalf The White <gandalf@digital.net>
To: "David S. Miller" <davem@redhat.com>
CC: Linux IPStack <netdev@oss.sgi.com>
Message-ID: <BC4A83EB.E263%gandalf@digital.net>
In-Reply-To: <20040207094524.495e883d.davem@redhat.com>
Mime-version: 1.0
Content-type: multipart/mixed; boundary="B_3159000045_290789"
X-archive-position: 3097
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: gandalf@digital.net
Precedence: bulk
X-list: netdev
Content-Length: 94321
Lines: 1549

> 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.

--B_3159000045_290789
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

Greetings and Salutations:

On 2/7/04 11:45 AM, "David S. Miller" <davem@redhat.com> wrote:
> What makes your DoS interesting is whether the attacker needs
> a lot of bandwidth or not.  Ie. if he has to be sitting on your
> gigabit subnet then the attack isn't interesting.  Whereas if he
> can eat all of the remote systems cpu cycles just being behind a
> cable modem, that's interesting.
> Which is it?

The network that I was working on was a 100Mb network.  This is (of course)
lots of packets at one time.  Attached is the excerpt from paper, I was
sending somewhere around 780 packets Per Second (I didn't know if
attachments were allowed to the list at first, but I saw a attachment in one
of the e-mails).

The requirements of the attack (from the perspective of the paper I wrote)
was that you had taken over 20 cable modem computers.  From this viewpoint
this could (of course) produce the required number of packets IMHO.

Of course you could also clog up the bandwidth of just about any destination
network with this requirement, but that is a different DoS.

> Also have you done your cpu utilization tests on something a little
> less ancient than a 450mhz system?  How fast was the network?

Well, that was my problem.  I didn't have much equipment to work with which
is why I sent it out to a list like this.  I was hoping that someone else
would be able to do a test on the equipment that they had and verify my
results on different equipment.

I noticed on the ICMP reassembly required timeout that the packets returned
were from IP addresses that were in different parts of the attacks (it
helped that I put random source IP addresses in the file).  It was almost as
if some of the packets I had sent to the Linux box were dropped during the
attack.  But again this could easily be a function of the slow CPU of the
box.

Ken

---------------------------------------------------------------
Do not meddle in the affairs of wizards for they are subtle and
quick to anger.
Ken Hollis - Gandalf The White - gandalf@digital.net - O- TINLC
WWW Page - http://digital.net/~gandalf/
Trace E-Mail forgery - http://digital.net/~gandalf/spamfaq.html
Trolls crossposts - http://digital.net/~gandalf/trollfaq.html



--B_3159000045_290789
Content-type: application/msword; name="Rose.rtf";
 x-mac-creator="4D535744";
 x-mac-type="52544620"
Content-disposition: attachment
Content-transfer-encoding: x-uuencode


begin 644 Rose.rtf
M>UQR=&8Q7&UA8UQA;G-I8W!G,3`P,#!<=6,Q(%QD969F,%QD969L86YG,3`S
M,UQD969L86YG9F4Q,#,S>UQU<')[7&9O;G1T8FQ[7&8P7&9N:6Q<9F-H87)S
M970R-39<9G!R<3)[7"I<<&%N;W-E(#`P,#(P,C`V,#,P-3`T,#4P,C`S?51I
M;65S($YE=R!2;VUA;CM]>UQF,5QF;FEL7&9C:&%R<V5T,C4V7&9P<G$R>UPJ
M7'!A;F]S92`P,#`R,&(P-C`T,#(P,C`R,#(P,GU!<FEA;#M]#7M<9C)<9FYI
M;%QF8VAA<G-E=#(U-EQF<')Q,GM<*EQP86YO<V4@,#`P,C`W,#,P.3`R,#(P
M-3`R,#1]0V]U<FEE<B!.97<[?7M<9C-<9FYI;%QF8VAA<G-E=#)<9G!R<3)[
M7"I<<&%N;W-E(#`P,#(P,#`U,#`P,#`P,#`P,#`P?5-Y;6)O;#M]>UQF-EQF
M;FEL7&9C:&%R<V5T,C4V7&9P<G$R>UPJ7'!A;F]S92`P,#`R,#`P-3`P,#`P
M,#`P,#`P,'U#;W5R:65R.WT->UQF,31<9FYI;%QF8VAA<G-E=#)<9G!R<3)[
M7"I<<&%N;W-E(#`P,#4P,C`Q,#(P,3`X,#0P.#`W?5=I;F=D:6YG<SM]>UQF
M,3A<9FYI;%QF8VAA<G-E=#(U-EQF<')Q,GM<*EQP86YO<V4@,#`P,C!B,#8P
M-#`S,#4P-#`T,#)]5&%H;VUA.WU[7&8Q.5QF<W=I<W-<9F-H87)S970Q,CA<
M9G!R<3)[7"I<<&%N;W-E(#`R,&(P-C`T,#(P,C`R,#(P,C`T?4%R:6%L(%5N
M:6-O9&4@35-[7"I<9F%L="!4:6UE<WT[?0U[7&8R.#1<9G-W:7-S7&9C:&%R
M<V5T,%QF<')Q,B!!<FEA;"!5;FEC;V1E($U3>UPJ7&9A;'0@5&EM97-].WU[
M7&8R.#)<9G-W:7-S7&9C:&%R<V5T,C,X7&9P<G$R($%R:6%L(%5N:6-O9&4@
M35,@0T5[7"I<9F%L="!4:6UE<WT[?7M<9C(X,UQF<W=I<W-<9F-H87)S970R
M,#1<9G!R<3(@07)I86P@56YI8V]D92!-4R!#>7)[7"I<9F%L="!4:6UE<WT[
M?0U[7&8R.#5<9G-W:7-S7&9C:&%R<V5T,38Q7&9P<G$R($%R:6%L(%5N:6-O
M9&4@35,@1W)E96M[7"I<9F%L="!4:6UE<WT[?7M<9C(X-EQF<W=I<W-<9F-H
M87)S970Q-C)<9G!R<3(@07)I86P@56YI8V]D92!-4R!4=7)[7"I<9F%L="!4
M:6UE<WT[?7M<9C(X-UQF<W=I<W-<9F-H87)S970Q.#9<9G!R<3(@07)I86P@
M56YI8V]D92!-4R!"86QT:6-[7"I<9F%L="!4:6UE<WT[?0U]>UPJ7'5D>UQF
M;VYT=&)L>UQF,%QF;FEL7&9C:&%R<V5T,C4V7&9P<G$R>UPJ7'!A;F]S92`P
M,#`R,#(P-C`S,#4P-#`U,#(P,WU4:6UE<R!.97<@4F]M86X[?7M<9C%<9FYI
M;%QF8VAA<G-E=#(U-EQF<')Q,GM<*EQP86YO<V4@,#`P,C!B,#8P-#`R,#(P
M,C`R,#)]07)I86P[?7M<9C)<9FYI;%QF8VAA<G-E=#(U-EQF<')Q,GM<*EQP
M86YO<V4@,#`P,C`W,#,P.3`R,#(P-3`R,#1]0V]U<FEE<B!.97<[?0U[7&8S
M7&9N:6Q<9F-H87)S970R7&9P<G$R>UPJ7'!A;F]S92`P,#`R,#`P-3`P,#`P
M,#`P,#`P,'U3>6UB;VP[?7M<9C9<9FYI;%QF8VAA<G-E=#(U-EQF<')Q,GM<
M*EQP86YO<V4@,#`P,C`P,#4P,#`P,#`P,#`P,#!]0V]U<FEE<CM]>UQF,31<
M9FYI;%QF8VAA<G-E=#)<9G!R<3)[7"I<<&%N;W-E(#`P,#4P,C`Q,#(P,3`X
M,#0P.#`W?5=I;F=D:6YG<SM]#7M<9C$X7&9N:6Q<9F-H87)S970R-39<9G!R
M<3)[7"I<<&%N;W-E(#`P,#(P8C`V,#0P,S`U,#0P-#`R?51A:&]M83M]>UQF
M,3E<9G-W:7-S7&9C:&%R<V5T,3(X7&9P<G$R>UPJ7'!A;F]S92`P,C!B,#8P
M-#`R,#(P,C`R,#(P-'U!<FEA;"!5;FEC;V1E($U3>UPJ7&9A;'0@5&EM97-]
M.WU[7&8R.#1<9G-W:7-S7&9C:&%R<V5T,%QF<')Q,B!!<FEA;"!5;FEC;V1E
M($U3>UPJ7&9A;'0@5&EM97-].WT->UQF,C@R7&9S=VES<UQF8VAA<G-E=#(S
M.%QF<')Q,B!!<FEA;"!5;FEC;V1E($U3($-%>UPJ7&9A;'0@5&EM97-].WU[
M7&8R.#-<9G-W:7-S7&9C:&%R<V5T,C`T7&9P<G$R($%R:6%L(%5N:6-O9&4@
M35,@0WER>UPJ7&9A;'0@5&EM97-].WU[7&8R.#5<9G-W:7-S7&9C:&%R<V5T
M,38Q7&9P<G$R($%R:6%L(%5N:6-O9&4@35,@1W)E96M[7"I<9F%L="!4:6UE
M<WT[?0U[7&8R.#9<9G-W:7-S7&9C:&%R<V5T,38R7&9P<G$R($%R:6%L(%5N
M:6-O9&4@35,@5'5R>UPJ7&9A;'0@5&EM97-].WU[7&8R.#=<9G-W:7-S7&9C
M:&%R<V5T,3@V7&9P<G$R($%R:6%L(%5N:6-O9&4@35,@0F%L=&EC>UPJ7&9A
M;'0@5&EM97-].WU]?7U[7&-O;&]R=&)L.UQR960P7&=R965N,%QB;'5E,#M<
M<F5D,%QG<F5E;C!<8FQU93(U-3M<<F5D,%QG<F5E;C(U-5QB;'5E,C4U.UQR
M960P7&=R965N,C4U7&)L=64P.PU<<F5D,C4U7&=R965N,%QB;'5E,C4U.UQR
M960R-35<9W)E96XP7&)L=64P.UQR960R-35<9W)E96XR-35<8FQU93`[7')E
M9#(U-5QG<F5E;C(U-5QB;'5E,C4U.UQR960P7&=R965N,%QB;'5E,3(X.UQR
M960P7&=R965N,3(X7&)L=64Q,C@[7')E9#!<9W)E96XQ,CA<8FQU93`[7')E
M9#$R.%QG<F5E;C!<8FQU93$R.#M<<F5D,3(X7&=R965N,%QB;'5E,#M<<F5D
M,3(X7&=R965N,3(X7&)L=64P.UQR960Q,CA<9W)E96XQ,CA<8FQU93$R.#L-
M7')E9#$Y,EQG<F5E;C$Y,EQB;'5E,3DR.WU[7'-T>6QE<VAE971[7'=I9&-T
M;'!A<EQA<W!A;'!H85QA<W!N=6U<9F%A=71O7&%D:G5S=')I9VAT7')I;C!<
M;&EN,%QI=&%P,"!<9C%<;&%N9S$P,S-<8V=R:60@7'-N97AT,"!.;W)M86P[
M?7M<<S%<<V(R-#!<<V$V,%QK965P;EQW:61C=&QP87)<87-P86QP:&%<87-P
M;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR:6XP7&QI;C!<:71A<#`@7&)<9C%<
M9G,S,EQL86YG,3`S,UQK97)N:6YG,S)<8V=R:60@#5QS8F%S961O;C`@7'-N
M97AT,"!H96%D:6YG(#$[?7M<<S)<<V(R-#!<<V$V,%QK965P;EQW:61C=&QP
M87)<87-P86QP:&%<87-P;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR:6XP7&QI
M;C!<:71A<#`@7&)<:5QF,5QF<S(X7&QA;F<Q,#,S7&-G<FED(%QS8F%S961O
M;C`@7'-N97AT,"!H96%D:6YG(#([?7M<<S-<<V(R-#!<<V$V,%QK965P;EQW
M:61C=&QP87)<87-P86QP:&%<87-P;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR
M:6XP7&QI;C!<:71A<#`@#5QB7&8Q7&9S,C9<;&%N9S$P,S-<8V=R:60@7'-B
M87-E9&]N,"!<<VYE>'0P(&AE861I;F<@,SM]>UQS-%QS8C(T,%QS838P7&ME
M97!N7'=I9&-T;'!A<EQA<W!A;'!H85QA<W!N=6U<9F%A=71O7&%D:G5S=')I
M9VAT7')I;C!<;&EN,%QI=&%P,"!<8EQF,5QF<S(X7&QA;F<Q,#,S7&-G<FED
M(%QS8F%S961O;C`@7'-N97AT,"!H96%D:6YG(#0[?7L-7',U7'-B,C0P7'-A
M-C!<=VED8W1L<&%R7&%S<&%L<&AA7&%S<&YU;5QF86%U=&]<861J=7-T<FEG
M:'1<<FEN,%QL:6XP7&ET87`P(%QB7&E<9C%<9G,R-EQL86YG,3`S,UQC9W)I
M9"!<<V)A<V5D;VXP(%QS;F5X=#`@:&5A9&EN9R`U.WU[7',V7'-B,C0P7'-A
M-C!<=VED8W1L<&%R7&%S<&%L<&AA7&%S<&YU;5QF86%U=&]<861J=7-T<FEG
M:'1<<FEN,%QL:6XP7&ET87`P(%QB7&9S,C)<;&%N9S$P,S-<8V=R:60@7'-B
M87-E9&]N,"!<<VYE>'0P(`UH96%D:6YG(#8[?7M<<S=<<6-<:V5E<&Y<=VED
M8W1L<&%R7&%S<&%L<&AA7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<<FEN
M,%QL:6XP7&ET87`P(%QB7&8Q7&QA;F<Q,#,S7&-G<FED(%QS8F%S961O;C`@
M7'-N97AT,"!H96%D:6YG(#<[?7M<<SA<<6-<:V5E<&Y<=VED8W1L<&%R7&%S
M<&%L<&AA7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<<FEN,%QL:6XP7&ET
M87`P(%QB7&8Q7&9S,CA<;&%N9S$P,S-<8V=R:60@#5QS8F%S961O;C`@7'-N
M97AT,"!H96%D:6YG(#@[?7M<<SE<:V5E<&Y<=VED8W1L<&%R7&%S<&%L<&AA
M7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<<FEN,%QL:6XP7&ET87`P(%QB
M7&E<9C%<;&%N9S$P,S-<8V=R:60@7'-B87-E9&]N,"!<<VYE>'0P(&AE861I
M;F<@.3M]>UPJ7&-S,3`@7&%D9&ET:79E($1E9F%U;'0@4&%R86=R87!H($9O
M;G0[?7M<*EQC<S$U(%QA9&1I=&EV92!<=6Q<8V8R(%QS8F%S961O;C$P($AY
M<&5R;&EN:SM]>PU<<S$V7'=I9&-T;'!A<EQA<W!A;'!H85QA<W!N=6U<9F%A
M=71O7&%D:G5S=')I9VAT7')I;C!<;&EN,%QI=&%P,"!<8V)P870Y(%QF,3A<
M;&%N9S$P,S-<8V=R:60@7'-B87-E9&]N,"!<<VYE>'0Q-B!$;V-U;65N="!-
M87`[?7M<<S$W7'=I9&-T;'!A<EQA<W!A;'!H85QA<W!N=6U<9F%A=71O7&%D
M:G5S=')I9VAT7')I;C!<;&EN,%QI=&%P,"!<9C%<;&%N9S$P,S-<8V=R:60@
M7'-B87-E9&]N,"!<<VYE>'0P(%QS875T;W5P9"!T;V,@,3M]>PU<<S$X7&QI
M,C0P7'=I9&-T;'!A<EQA<W!A;'!H85QA<W!N=6U<9F%A=71O7&%D:G5S=')I
M9VAT7')I;C!<;&EN,C0P7&ET87`P(%QF,5QL86YG,3`S,UQC9W)I9"!<<V)A
M<V5D;VXP(%QS;F5X=#`@7'-A=71O=7!D('1O8R`R.WU[7',Q.5QL:30X,%QW
M:61C=&QP87)<87-P86QP:&%<87-P;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR
M:6XP7&QI;C0X,%QI=&%P,"!<9C%<;&%N9S$P,S-<8V=R:60@7'-B87-E9&]N
M,"!<<VYE>'0P(%QS875T;W5P9"`-=&]C(#,[?7M<<S(P7&QI-S(P7'=I9&-T
M;'!A<EQA<W!A;'!H85QA<W!N=6U<9F%A=71O7&%D:G5S=')I9VAT7')I;C!<
M;&EN-S(P7&ET87`P(%QF,5QL86YG,3`S,UQC9W)I9"!<<V)A<V5D;VXP(%QS
M;F5X=#`@7'-A=71O=7!D('1O8R`T.WU[7',R,5QL:3DV,%QW:61C=&QP87)<
M87-P86QP:&%<87-P;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR:6XP7&QI;CDV
M,%QI=&%P,"!<9C%<;&%N9S$P,S-<8V=R:60@#5QS8F%S961O;C`@7'-N97AT
M,"!<<V%U=&]U<&0@=&]C(#4[?7M<<S(R7&QI,3(P,%QW:61C=&QP87)<87-P
M86QP:&%<87-P;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR:6XP7&QI;C$R,#!<
M:71A<#`@7&8Q7&QA;F<Q,#,S7&-G<FED(%QS8F%S961O;C`@7'-N97AT,"!<
M<V%U=&]U<&0@=&]C(#8[?7M<<S(S7&QI,30T,%QW:61C=&QP87)<87-P86QP
M:&%<87-P;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR:6XP7&QI;C$T-#!<:71A
M<#`@#5QF,5QL86YG,3`S,UQC9W)I9"!<<V)A<V5D;VXP(%QS;F5X=#`@7'-A
M=71O=7!D('1O8R`W.WU[7',R-%QL:3$V.#!<=VED8W1L<&%R7&%S<&%L<&AA
M7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<<FEN,%QL:6XQ-C@P7&ET87`P
M(%QF,5QL86YG,3`S,UQC9W)I9"!<<V)A<V5D;VXP(%QS;F5X=#`@7'-A=71O
M=7!D('1O8R`X.WU[#5QS,C5<;&DQ.3(P7'=I9&-T;'!A<EQA<W!A;'!H85QA
M<W!N=6U<9F%A=71O7&%D:G5S=')I9VAT7')I;C!<;&EN,3DR,%QI=&%P,"!<
M9C%<;&%N9S$P,S-<8V=R:60@7'-B87-E9&]N,"!<<VYE>'0P(%QS875T;W5P
M9"!T;V,@.3M]>UQS,C9<=VED8W1L<&%R7'1Q8UQT>#0S,C!<='%R7'1X.#8T
M,%QA<W!A;'!H85QA<W!N=6U<9F%A=71O7&%D:G5S=')I9VAT7')I;C!<;&EN
M,%QI=&%P,"!<9C%<;&%N9S$P,S-<8V=R:60@#5QS8F%S961O;C`@7'-N97AT
M,C8@:&5A9&5R.WU[7',R-UQW:61C=&QP87)<='%C7'1X-#,R,%QT<7)<='@X
M-C0P7&%S<&%L<&AA7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<<FEN,%QL
M:6XP7&ET87`P(%QF,5QL86YG,3`S,UQC9W)I9"!<<V)A<V5D;VXP(%QS;F5X
M=#(W(&9O;W1E<CM]>UQS,CA<=VED8W1L<&%R7&%S<&%L<&AA7&%S<&YU;5QF
M86%U=&]<;W5T;&EN96QE=F5L,%QA9&IU<W1R:6=H=%QR:6XP7&QI;C!<:71A
M<#`@#5QB7&E<9C%<9G,S-EQU;%QL86YG,3`S,UQC9W)I9"!<<V)A<V5D;VXP
M(%QS;F5X=#(X($)O9'D@5&5X=#M]>UQS,CE<=VED8W1L<&%R7&%S<&%L<&AA
M7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<<FEN,%QL:6XP7&ET87`P(%QB
M7&E<9C%<9G,T,%QU;%QL86YG,3`S,UQC9W)I9"!<<V)A<V5D;VXP(%QS;F5X
M=#(Y($)O9'D@5&5X="`R.WU[7"I<8W,S,"!<861D:71I=F4@7&(@7'-B87-E
M9&]N,3`@4W1R;VYG.WU[7"I<8W,S,2!<861D:71I=F4@#5QU;%QC9C$R(%QS
M8F%S961O;C$P($9O;&QO=V5D2'EP97)L:6YK.WU[7"I<8W,S,B!<861D:71I
M=F4@7&)<9G,R,EQC9C%<;&]C:%QA9C9<:&EC:%QA9C9<9&)C:%QF,3D@7'-B
M87-E9&]N,3`@2%1-3"!#;V1E.WU[7"I<8W,S,R!<861D:71I=F4@7&9S,C!<
M;&]C:%QA9C$Y7&AI8VA<868Q.5QD8F-H7&8Q.2!<<V)A<V5D;VXQ,"!(5$U,
M(%1Y<&5W<FET97([?7L-7',S-%QW:61C=&QP87)<87-P86QP:&%<87-P;G5M
M7&9A875T;UQA9&IU<W1R:6=H=%QR:6XP7&QI;C!<:71A<#`@7&8Q7&9S,C!<
M;&%N9S$P,S-<8V=R:60@7'-B87-E9&]N,"!<<VYE>'0S-"!E;F1N;W1E('1E
M>'0[?7M<*EQC<S,U(%QA9&1I=&EV92!<<W5P97(@7'-B87-E9&]N,3`@96YD
M;F]T92!R969E<F5N8V4[?7M<*EQC<S,V(%QA9&1I=&EV92!<8EQS=')I:V5<
M9C%<9G,R-%QU;&YO;F5<8V8Q7&%N:6UT97AT,%QS=')I:V5D,"`-7'-B87-E
M9&]N,3`@8V]N=&5N=#$[?7M<*EQC<S,W(%QA9&1I=&EV92!<8EQF,5QF<S(T
M7'5L(%QS8F%S961O;C$P(&-O;G1E;G1L:6YK,3M]>UQS,SA<<6-<;&DQ,C8P
M7')I-S(P7'=I9&-T;'!A<EQA<W!A;'!H85QA<W!N=6U<9F%A=71O7&%D:G5S
M=')I9VAT7')I;C<R,%QL:6XQ,C8P7&ET87`P(%QF,5QL86YG,3`S,UQC9W)I
M9"!<<V)A<V5D;VXP(%QS;F5X=#,X($)L;V-K(%1E>'0[?7L-7',S.5QW:61C
M=&QP87)<87-P86QP:&%<87-P;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR:6XP
M7&QI;C!<:71A<#`@7&8R7&9S,C!<;&%N9S$P,S-<8V=R:60@7'-B87-E9&]N
M,"!<<VYE>'0S.2!";V1Y(%1E>'0@,SM]>UQS-#!<=VED8W1L<&%R7&%S<&%L
M<&AA7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<<FEN,%QL:6XP7&ET87`P
M(%QF,5QF<S(P7&QA;F<Q,#,S7&-G<FED(%QS8F%S961O;C`@7'-N97AT-#`@
M9F]O=&YO=&4@=&5X=#M]>UPJ#5QC<S0Q(%QA9&1I=&EV92!<<W5P97(@7'-B
M87-E9&]N,3`@9F]O=&YO=&4@<F5F97)E;F-E.WU[7',T,EQW:61C=&QP87)<
M='@Y,39<='@Q.#,R7'1X,C<T.%QT>#,V-C1<='@T-3@P7'1X-30Y-EQT>#8T
M,3)<='@W,S(X7'1X.#(T-%QT>#DQ-C!<='@Q,#`W-EQT>#$P.3DR7'1X,3$Y
M,#A<='@Q,C@R-%QT>#$S-S0P7'1X,30V-39<87-P86QP:&%<87-P;G5M7&9A
M875T;UQA9&IU<W1R:6=H=%QR:6XP7&QI;C!<:71A<#`@#5QF<S(P7&QA;F<Q
M,#,S7&QO8VA<868Q.5QH:6-H7&%F,3E<9&)C:%QF,3E<8V=R:60@7'-B87-E
M9&]N,"!<<VYE>'0T,B!(5$U,(%!R969O<FUA='1E9#M]>UPJ7&-S-#,@7&%D
M9&ET:79E(%QB7&8Q7&9S,S`@7'-B87-E9&]N,3`@:&0Q.WU]>UPJ7&QI<W1T
M86)L97M<;&ES=%QL:7-T=&5M<&QA=&5I9"TS,3DS.3DT,#)<;&ES=&AY8G)I
M9'M<;&ES=&QE=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N,C-<;&5V96QJ8S!<
M;&5V96QJ8VXP#5QL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P
M86-E,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I
M9#8V-38Y7"<P,5QU+3,Y,3,@7SM]>UQL979E;&YU;6)E<G,[?5QF,UQC:&)R
M9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A
M=#%<9F)I87,P(%QL;V-H7&%F,UQD8F-H7&%F,%QH:6-H7&8S(%QF:2TS-C!<
M;&DW,C!<:F-L:7-T=&%B7'1X-S(P('U[7&QI<W1L979E;`U<;&5V96QN9F,R
M,UQL979E;&YF8VXR,UQL979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL;W<P
M7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C93,V,%QL979E;&EN9&5N=#![7&QE
M=F5L=&5X=%QL979E;'1E;7!L871E:60Q.3<V-#%<)S`Q;SM]>UQL979E;&YU
M;6)E<G,[?5QF,EQC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<
M8VAC9G!A=#%<8VAC8G!A=#%<9F)I87,P(%QF:2TS-C!<;&DQ-#0P7&IC;&ES
M='1A8EQT>#$T-#`@?0U[7&QI<W1L979E;%QL979E;&YF8S(S7&QE=F5L;F9C
M;C(S7&QE=F5L:F,P7&QE=F5L:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R
M=&%T,5QL979E;'-P86-E,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE
M=F5L=&5M<&QA=&5I9#,R.#<Q,UPG,#%<=2TS.3(Y(%\[?7M<;&5V96QN=6UB
M97)S.WU<9C$T7&-H8G)D<EQB<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC
M:&-F<&%T,5QC:&-B<&%T,5QF8FEA<S`@7&9I+3,V,%QL:3(Q-C`-7&IC;&ES
M='1A8EQT>#(Q-C`@?7M<;&ES=&QE=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N
M,C-<;&5V96QJ8S!<;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T
M870Q7&QE=F5L<W!A8V4S-C!<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V
M96QT96UP;&%T96ED-C8U-CE<)S`Q7'4M,SDQ,R!?.WU[7&QE=F5L;G5M8F5R
M<SM]7&8S7&-H8G)D<EQB<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F
M<&%T,5QC:&-B<&%T,5QF8FEA<S`@#5QL;V-H7&%F,UQD8F-H7&%F,%QH:6-H
M7&8S(%QF:2TS-C!<;&DR.#@P7&IC;&ES='1A8EQT>#(X.#`@?7M<;&ES=&QE
M=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N,C-<;&5V96QJ8S!<;&5V96QJ8VXP
M7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4S-C!<;&5V
M96QI;F1E;G0P>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED,3DW-C0Q7"<P
M,6\[?7M<;&5V96QN=6UB97)S.WU<9C)<8VAB<F1R7&)R9')N;VYE7&)R9')C
M9C$@#5QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,5QF8FEA<S`@7&9I+3,V
M,%QL:3,V,#!<:F-L:7-T=&%B7'1X,S8P,"!]>UQL:7-T;&5V96Q<;&5V96QN
M9F,R,UQL979E;&YF8VXR,UQL979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL
M;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C93,V,%QL979E;&EN9&5N=#![
M7&QE=F5L=&5X=%QL979E;'1E;7!L871E:60S,C@W,3-<)S`Q7'4M,SDR.2!?
M.WU[7&QE=F5L;G5M8F5R<SM]7&8Q-%QC:&)R9'(-7&)R9')N;VYE7&)R9')C
M9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<9FDM,S8P
M7&QI-#,R,%QJ8VQI<W1T86)<='@T,S(P('U[7&QI<W1L979E;%QL979E;&YF
M8S(S7&QE=F5L;F9C;C(S7&QE=F5L:F,P7&QE=F5L:F-N,%QL979E;&9O;&QO
M=S!<;&5V96QS=&%R=&%T,5QL979E;'-P86-E,S8P7&QE=F5L:6YD96YT,'M<
M;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#8V-38Y7"<P,5QU+3,Y,3,@7SM]
M>UQL979E;&YU;6)E<G,-.WU<9C-<8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@
M7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<;&]C:%QA9C-<
M9&)C:%QA9C!<:&EC:%QF,R!<9FDM,S8P7&QI-3`T,%QJ8VQI<W1T86)<='@U
M,#0P('U[7&QI<W1L979E;%QL979E;&YF8S(S7&QE=F5L;F9C;C(S7&QE=F5L
M:F,P7&QE=F5L:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E
M;'-P86-E,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT#5QL979E;'1E;7!L
M871E:60Q.3<V-#%<)S`Q;SM]>UQL979E;&YU;6)E<G,[?5QF,EQC:&)R9')<
M8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A=#%<
M9F)I87,P(%QF:2TS-C!<;&DU-S8P7&IC;&ES='1A8EQT>#4W-C`@?7M<;&ES
M=&QE=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N,C-<;&5V96QJ8S!<;&5V96QJ
M8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4S-C!<
M;&5V96QI;F1E;G0P#7M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#,R.#<Q
M,UPG,#%<=2TS.3(Y(%\[?7M<;&5V96QN=6UB97)S.WU<9C$T7&-H8G)D<EQB
M<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,5QF
M8FEA<S`@7&9I+3,V,%QL:38T.#!<:F-L:7-T=&%B7'1X-C0X,"!]>UQL:7-T
M;F%M92`[?5QL:7-T:60R,C(R,#$R.7U[7&QI<W1<;&ES='1E;7!L871E:60M
M-S8U,#4P-C@V7&QI<W1H>6)R:61[7&QI<W1L979E;%QL979E;&YF8S(S#5QL
M979E;&YF8VXR,UQL979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL;W<P7&QE
M=F5L<W1A<G1A=#%<;&5V96QS<&%C93,V,%QL979E;&EN9&5N=#![7&QE=F5L
M=&5X=%QL979E;'1E;7!L871E:60V-C4V.5PG,#%<=2TS.3$S(%\[?7M<;&5V
M96QN=6UB97)S.WU<9C-<8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD
M;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<;&]C:%QA9C-<9&)C:%QA
M9C!<:&EC:%QF,R!<9FDM,S8P7&QI-S(P#5QJ8VQI<W1T86)<='@W,C`@?7M<
M;&ES=&QE=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N,C-<;&5V96QJ8S!<;&5V
M96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4S
M-C!<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED,3DW
M-C0Q7"<P,6\[?7M<;&5V96QN=6UB97)S.WU<9C)<8VAB<F1R7&)R9')N;VYE
M7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"`-
M7&9I+3,V,%QL:3$T-#!<:F-L:7-T=&%B7'1X,30T,"!]>UQL:7-T;&5V96Q<
M;&5V96QN9F,R,UQL979E;&YF8VXR,UQL979E;&IC,%QL979E;&IC;C!<;&5V
M96QF;VQL;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C93,V,%QL979E;&EN
M9&5N=#![7&QE=F5L=&5X=%QL979E;'1E;7!L871E:60S,C@W,3-<)S`Q7'4M
M,SDR.2!?.WU[7&QE=F5L;G5M8F5R<SM]7&8Q-%QC:&)R9')<8G)D<FYO;F5<
M8G)D<F-F,2`-7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<
M9FDM,S8P7&QI,C$V,%QJ8VQI<W1T86)<='@R,38P('U[7&QI<W1L979E;%QL
M979E;&YF8S(S7&QE=F5L;F9C;C(S7&QE=F5L:F,P7&QE=F5L:F-N,%QL979E
M;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P86-E,S8P7&QE=F5L:6YD
M96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#8V-38Y7"<P,5QU+3,Y
M,3,@7SM]>UQL979E;&YU;6)E<G,[?5QF,UQC:&)R9'(-7&)R9')N;VYE7&)R
M9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<;&]C
M:%QA9C-<9&)C:%QA9C!<:&EC:%QF,R!<9FDM,S8P7&QI,C@X,%QJ8VQI<W1T
M86)<='@R.#@P('U[7&QI<W1L979E;%QL979E;&YF8S(S7&QE=F5L;F9C;C(S
M7&QE=F5L:F,P7&QE=F5L:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T
M,5QL979E;'-P86-E,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE=F5L
M=&5M<&QA=&5I9#$Y-S8T,0U<)S`Q;SM]>UQL979E;&YU;6)E<G,[?5QF,EQC
M:&)R9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC
M8G!A=#%<9F)I87,P(%QF:2TS-C!<;&DS-C`P7&IC;&ES='1A8EQT>#,V,#`@
M?7M<;&ES=&QE=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N,C-<;&5V96QJ8S!<
M;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A
M8V4S-C!<;&5V96QI;F1E;G0P>UQL979E;'1E>'0-7&QE=F5L=&5M<&QA=&5I
M9#,R.#<Q,UPG,#%<=2TS.3(Y(%\[?7M<;&5V96QN=6UB97)S.WU<9C$T7&-H
M8G)D<EQB<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B
M<&%T,5QF8FEA<S`@7&9I+3,V,%QL:30S,C!<:F-L:7-T=&%B7'1X-#,R,"!]
M>UQL:7-T;&5V96Q<;&5V96QN9F,R,UQL979E;&YF8VXR,UQL979E;&IC,%QL
M979E;&IC;C!<;&5V96QF;VQL;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C
M93,V,`U<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED
M-C8U-CE<)S`Q7'4M,SDQ,R!?.WU[7&QE=F5L;G5M8F5R<SM]7&8S7&-H8G)D
M<EQB<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T
M,5QF8FEA<S`@7&QO8VA<868S7&1B8VA<868P7&AI8VA<9C,@7&9I+3,V,%QL
M:34P-#!<:F-L:7-T=&%B7'1X-3`T,"!]>UQL:7-T;&5V96Q<;&5V96QN9F,R
M,UQL979E;&YF8VXR,UQL979E;&IC,%QL979E;&IC;C`-7&QE=F5L9F]L;&]W
M,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4S-C!<;&5V96QI;F1E;G0P>UQL
M979E;'1E>'1<;&5V96QT96UP;&%T96ED,3DW-C0Q7"<P,6\[?7M<;&5V96QN
M=6UB97)S.WU<9C)<8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P
M7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<9FDM,S8P7&QI-3<V,%QJ8VQI
M<W1T86)<='@U-S8P('U[7&QI<W1L979E;%QL979E;&YF8S(S7&QE=F5L;F9C
M;C(S7&QE=F5L:F,P#5QL979E;&IC;C!<;&5V96QF;VQL;W<P7&QE=F5L<W1A
M<G1A=#%<;&5V96QS<&%C93,V,%QL979E;&EN9&5N=#![7&QE=F5L=&5X=%QL
M979E;'1E;7!L871E:60S,C@W,3-<)S`Q7'4M,SDR.2!?.WU[7&QE=F5L;G5M
M8F5R<SM]7&8Q-%QC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<
M8VAC9G!A=#%<8VAC8G!A=#%<9F)I87,P(%QF:2TS-C!<;&DV-#@P7&IC;&ES
M='1A8EQT>#8T.#`@?7M<;&ES=&YA;64@.WU<;&ES=&ED.#`T,3DQ-3-]#7M<
M;&ES=%QL:7-T=&5M<&QA=&5I9"TQ,S4T-#<U-3@R7&QI<W1H>6)R:61[7&QI
M<W1L979E;%QL979E;&YF8S(S7&QE=F5L;F9C;C(S7&QE=F5L:F,P7&QE=F5L
M:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P86-E,S8P
M7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#8V-38Y
M7"<P,5QU+3,Y,3,@7SM]>UQL979E;&YU;6)E<G,[?5QF,UQC:&)R9')<8G)D
M<FYO;F5<8G)D<F-F,2`-7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B
M:6%S,"!<;&]C:%QA9C-<9&)C:%QA9C!<:&EC:%QF,R!<9FDM,S8P7&QI-S(P
M7&IC;&ES='1A8EQT>#<R,"!]>UQL:7-T;&5V96Q<;&5V96QN9F,R,UQL979E
M;&YF8VXR,UQL979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL;W<P7&QE=F5L
M<W1A<G1A=#%<;&5V96QS<&%C93,V,%QL979E;&EN9&5N=#![7&QE=F5L=&5X
M=%QL979E;'1E;7!L871E:60Q.3<V-#%<)S`Q;SM]>UQL979E;&YU;6)E<G,-
M.WU<9C)<8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P
M870Q7&-H8V)P870Q7&9B:6%S,"!<9FDM,S8P7&QI,30T,%QJ8VQI<W1T86)<
M='@Q-#0P('U[7&QI<W1L979E;%QL979E;&YF8S(S7&QE=F5L;F9C;C(S7&QE
M=F5L:F,P7&QE=F5L:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL
M979E;'-P86-E,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE=F5L=&5M
M<&QA=&5I9#,R.#<Q,PU<)S`Q7'4M,SDR.2!?.WU[7&QE=F5L;G5M8F5R<SM]
M7&8Q-%QC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A
M=#%<8VAC8G!A=#%<9F)I87,P(%QF:2TS-C!<;&DR,38P7&IC;&ES='1A8EQT
M>#(Q-C`@?7M<;&ES=&QE=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N,C-<;&5V
M96QJ8S!<;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE
M=F5L<W!A8V4S-C!<;&5V96QI;F1E;G0P>UQL979E;'1E>'0-7&QE=F5L=&5M
M<&QA=&5I9#8V-38Y7"<P,5QU+3,Y,3,@7SM]>UQL979E;&YU;6)E<G,[?5QF
M,UQC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<
M8VAC8G!A=#%<9F)I87,P(%QL;V-H7&%F,UQD8F-H7&%F,%QH:6-H7&8S(%QF
M:2TS-C!<;&DR.#@P7&IC;&ES='1A8EQT>#(X.#`@?7M<;&ES=&QE=F5L7&QE
M=F5L;F9C,C-<;&5V96QN9F-N,C-<;&5V96QJ8S!<;&5V96QJ8VXP7&QE=F5L
M9F]L;&]W,%QL979E;'-T87)T870Q#5QL979E;'-P86-E,S8P7&QE=F5L:6YD
M96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#$Y-S8T,5PG,#%O.WU[
M7&QE=F5L;G5M8F5R<SM]7&8R7&-H8G)D<EQB<F1R;F]N95QB<F1R8V8Q(%QC
M:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,5QF8FEA<S`@7&9I+3,V,%QL:3,V
M,#!<:F-L:7-T=&%B7'1X,S8P,"!]>UQL:7-T;&5V96Q<;&5V96QN9F,R,UQL
M979E;&YF8VXR,UQL979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL;W<P#5QL
M979E;'-T87)T870Q7&QE=F5L<W!A8V4S-C!<;&5V96QI;F1E;G0P>UQL979E
M;'1E>'1<;&5V96QT96UP;&%T96ED,S(X-S$S7"<P,5QU+3,Y,CD@7SM]>UQL
M979E;&YU;6)E<G,[?5QF,31<8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@7&-H
M<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<9FDM,S8P7&QI-#,R
M,%QJ8VQI<W1T86)<='@T,S(P('U[7&QI<W1L979E;%QL979E;&YF8S(S7&QE
M=F5L;F9C;C(S7&QE=F5L:F,P7&QE=F5L:F-N,`U<;&5V96QF;VQL;W<P7&QE
M=F5L<W1A<G1A=#%<;&5V96QS<&%C93,V,%QL979E;&EN9&5N=#![7&QE=F5L
M=&5X=%QL979E;'1E;7!L871E:60V-C4V.5PG,#%<=2TS.3$S(%\[?7M<;&5V
M96QN=6UB97)S.WU<9C-<8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD
M;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<;&]C:%QA9C-<9&)C:%QA
M9C!<:&EC:%QF,R!<9FDM,S8P7&QI-3`T,%QJ8VQI<W1T86)<='@U,#0P('U[
M7&QI<W1L979E;`U<;&5V96QN9F,R,UQL979E;&YF8VXR,UQL979E;&IC,%QL
M979E;&IC;C!<;&5V96QF;VQL;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C
M93,V,%QL979E;&EN9&5N=#![7&QE=F5L=&5X=%QL979E;'1E;7!L871E:60Q
M.3<V-#%<)S`Q;SM]>UQL979E;&YU;6)E<G,[?5QF,EQC:&)R9')<8G)D<FYO
M;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A=#%<9F)I87,P
M(%QF:2TS-C!<;&DU-S8P7&IC;&ES='1A8EQT>#4W-C`@?0U[7&QI<W1L979E
M;%QL979E;&YF8S(S7&QE=F5L;F9C;C(S7&QE=F5L:F,P7&QE=F5L:F-N,%QL
M979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P86-E,S8P7&QE=F5L
M:6YD96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#,R.#<Q,UPG,#%<
M=2TS.3(Y(%\[?7M<;&5V96QN=6UB97)S.WU<9C$T7&-H8G)D<EQB<F1R;F]N
M95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,5QF8FEA<S`@
M7&9I+3,V,%QL:38T.#`-7&IC;&ES='1A8EQT>#8T.#`@?7M<;&ES=&YA;64@
M.WU<;&ES=&ED-S`R,CDR.#DV?7M<;&ES=%QL:7-T=&5M<&QA=&5I9"TY.3`V
M,C8U.31<;&ES=&AY8G)I9'M<;&ES=&QE=F5L7&QE=F5L;F9C,%QL979E;&YF
M8VXP7&QE=F5L:F,P7&QE=F5L:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R
M=&%T,5QL979E;'-P86-E,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE
M=F5L=&5M<&QA=&5I9#$Q,34Q-#5<)S`R7"<P,"D[?7M<;&5V96QN=6UB97)S
M#5PG,#$[?5QC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC
M9G!A=#%<8VAC8G!A=#$@7&9I+3,V,%QL:3<R,%QJ8VQI<W1T86)<='@W,C`@
M?7M<;&ES=&QE=F5L7&QE=F5L;F9C-%QL979E;&YF8VXT7&QE=F5L:F,P7&QE
M=F5L:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P86-E
M,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#$V
M,SDT,S-<)S`R7"<P,2X[?7M<;&5V96QN=6UB97)S#5PG,#$[?5QC:&)R9')<
M8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A=#$@
M7&9I+3,V,%QL:3$T-#!<:F-L:7-T=&%B7'1X,30T,"!]>UQL:7-T;&5V96Q<
M;&5V96QN9F,R7&QE=F5L;F9C;C)<;&5V96QJ8S)<;&5V96QJ8VXR7&QE=F5L
M9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4S-C!<;&5V96QI;F1E
M;G0P>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED,3<W,#4P-0U<)S`R7"<P
M,BX[?7M<;&5V96QN=6UB97)S7"<P,3M]7&-H8G)D<EQB<F1R;F]N95QB<F1R
M8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,2!<9FDM,3@P7&QI,C$V
M,%QJ8VQI<W1T86)<='@R,38P('U[7&QI<W1L979E;%QL979E;&YF8S!<;&5V
M96QN9F-N,%QL979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL;W<P7&QE=F5L
M<W1A<G1A=#%<;&5V96QS<&%C93,V,%QL979E;&EN9&5N=#![7&QE=F5L=&5X
M=%QL979E;'1E;7!L871E:60Y.#0P-S,-7"<P,EPG,#,N.WU[7&QE=F5L;G5M
M8F5R<UPG,#$[?5QC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<
M8VAC9G!A=#%<8VAC8G!A=#$@7&9I+3,V,%QL:3(X.#!<:F-L:7-T=&%B7'1X
M,C@X,"!]>UQL:7-T;&5V96Q<;&5V96QN9F,T7&QE=F5L;F9C;C1<;&5V96QJ
M8S!<;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L
M<W!A8V4S-C!<;&5V96QI;F1E;G0P>UQL979E;'1E>'0-7&QE=F5L=&5M<&QA
M=&5I9#$V,SDT,S-<)S`R7"<P-"X[?7M<;&5V96QN=6UB97)S7"<P,3M]7&-H
M8G)D<EQB<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B
M<&%T,2!<9FDM,S8P7&QI,S8P,%QJ8VQI<W1T86)<='@S-C`P('U[7&QI<W1L
M979E;%QL979E;&YF8S)<;&5V96QN9F-N,EQL979E;&IC,EQL979E;&IC;C)<
M;&5V96QF;VQL;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C93,V,%QL979E
M;&EN9&5N=#`->UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED,3<W,#4P-5PG
M,#)<)S`U+CM]>UQL979E;&YU;6)E<G-<)S`Q.WU<8VAB<F1R7&)R9')N;VYE
M7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q(%QF:2TQ.#!<
M;&DT,S(P7&IC;&ES='1A8EQT>#0S,C`@?7M<;&ES=&QE=F5L7&QE=F5L;F9C
M,%QL979E;&YF8VXP7&QE=F5L:F,P7&QE=F5L:F-N,%QL979E;&9O;&QO=S!<
M;&5V96QS=&%R=&%T,5QL979E;'-P86-E,S8P#5QL979E;&EN9&5N=#![7&QE
M=F5L=&5X=%QL979E;'1E;7!L871E:60Y.#0P-S-<)S`R7"<P-BX[?7M<;&5V
M96QN=6UB97)S7"<P,3M]7&-H8G)D<EQB<F1R;F]N95QB<F1R8V8Q(%QC:'-H
M9&YG,%QC:&-F<&%T,5QC:&-B<&%T,2!<9FDM,S8P7&QI-3`T,%QJ8VQI<W1T
M86)<='@U,#0P('U[7&QI<W1L979E;%QL979E;&YF8S1<;&5V96QN9F-N-%QL
M979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL;W<P7&QE=F5L<W1A<G1A=#%<
M;&5V96QS<&%C93,V,`U<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V96QT
M96UP;&%T96ED,38S.30S,UPG,#)<)S`W+CM]>UQL979E;&YU;6)E<G-<)S`Q
M.WU<8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q
M7&-H8V)P870Q(%QF:2TS-C!<;&DU-S8P7&IC;&ES='1A8EQT>#4W-C`@?7M<
M;&ES=&QE=F5L7&QE=F5L;F9C,EQL979E;&YF8VXR7&QE=F5L:F,R7&QE=F5L
M:F-N,EQL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,0U<;&5V96QS<&%C93,V
M,%QL979E;&EN9&5N=#![7&QE=F5L=&5X=%QL979E;'1E;7!L871E:60Q-S<P
M-3`U7"<P,EPG,#@N.WU[7&QE=F5L;G5M8F5R<UPG,#$[?5QC:&)R9')<8G)D
M<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A=#$@7&9I
M+3$X,%QL:38T.#!<:F-L:7-T=&%B7'1X-C0X,"!]>UQL:7-T;F%M92`[?5QL
M:7-T:60W,3`V.3$P,#-]>UQL:7-T7&QI<W1T96UP;&%T96ED+3$S.38R-C,S
M,S)<;&ES=&AY8G)I9`U[7&QI<W1L979E;%QL979E;&YF8S!<;&5V96QN9F-N
M,%QL979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL;W<P7&QE=F5L<W1A<G1A
M=#%<;&5V96QS<&%C93!<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V96QT
M96UP;&%T96ED,3$Q-3$T-5PG,#)<)S`P*3M]>UQL979E;&YU;6)E<G-<)S`Q
M.WU<8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q
M7&-H8V)P870Q7&9B:6%S,"!<9FDM,S8P7&QI-S(P#5QJ8VQI<W1T86)<='@W
M,C`@?7M<;&ES=&QE=F5L7&QE=F5L;F9C-%QL979E;&YF8VXT7&QE=F5L:F,P
M7&QE=F5L:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P
M86-E,%QL979E;&EN9&5N=#![7&QE=F5L=&5X=%QL979E;'1E;7!L871E:60Q
M-C,Y-#,S7"<P,EPG,#$N.WU[7&QE=F5L;G5M8F5R<UPG,#$[?5QC:&)R9')<
M8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A=#$@
M7&9I+3,V,%QL:3$T-#`-7&IC;&ES='1A8EQT>#$T-#`@?7M<;&ES=&QE=F5L
M7&QE=F5L;F9C,EQL979E;&YF8VXR7&QE=F5L:F,R7&QE=F5L:F-N,EQL979E
M;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P86-E,%QL979E;&EN9&5N
M=#![7&QE=F5L=&5X=%QL979E;'1E;7!L871E:60Q-S<P-3`U7"<P,EPG,#(N
M.WU[7&QE=F5L;G5M8F5R<UPG,#$[?5QC:&)R9')<8G)D<FYO;F5<8G)D<F-F
M,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A=#$@7&9I+3$X,%QL:3(Q-C`-
M7&IC;&ES='1A8EQT>#(Q-C`@?7M<;&ES=&QE=F5L7&QE=F5L;F9C,%QL979E
M;&YF8VXP7&QE=F5L:F,P7&QE=F5L:F-N,%QL979E;&9O;&QO=S!<;&5V96QS
M=&%R=&%T,5QL979E;'-P86-E,%QL979E;&EN9&5N=#![7&QE=F5L=&5X=%QL
M979E;'1E;7!L871E:60Y.#0P-S-<)S`R7"<P,RX[?7M<;&5V96QN=6UB97)S
M7"<P,3M]7&-H8G)D<EQB<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F
M<&%T,5QC:&-B<&%T,2!<9FDM,S8P7&QI,C@X,`U<:F-L:7-T=&%B7'1X,C@X
M,"!]>UQL:7-T;&5V96Q<;&5V96QN9F,T7&QE=F5L;F9C;C1<;&5V96QJ8S!<
M;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A
M8V4P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#$V
M,SDT,S-<)S`R7"<P-"X[?7M<;&5V96QN=6UB97)S7"<P,3M]7&-H8G)D<EQB
M<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,2!<
M9FDM,S8P7&QI,S8P,`U<:F-L:7-T=&%B7'1X,S8P,"!]>UQL:7-T;&5V96Q<
M;&5V96QN9F,R7&QE=F5L;F9C;C)<;&5V96QJ8S)<;&5V96QJ8VXR7&QE=F5L
M9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4P7&QE=F5L:6YD96YT
M,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#$W-S`U,#5<)S`R7"<P-2X[
M?7M<;&5V96QN=6UB97)S7"<P,3M]7&-H8G)D<EQB<F1R;F]N95QB<F1R8V8Q
M(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,2!<9FDM,3@P7&QI-#,R,`U<
M:F-L:7-T=&%B7'1X-#,R,"!]>UQL:7-T;&5V96Q<;&5V96QN9F,P7&QE=F5L
M;F9C;C!<;&5V96QJ8S!<;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T
M87)T870Q7&QE=F5L<W!A8V4P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE
M=F5L=&5M<&QA=&5I9#DX-#`W,UPG,#)<)S`V+CM]>UQL979E;&YU;6)E<G-<
M)S`Q.WU<8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P
M870Q7&-H8V)P870Q(%QF:2TS-C!<;&DU,#0P#5QJ8VQI<W1T86)<='@U,#0P
M('U[7&QI<W1L979E;%QL979E;&YF8S1<;&5V96QN9F-N-%QL979E;&IC,%QL
M979E;&IC;C!<;&5V96QF;VQL;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C
M93!<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED,38S
M.30S,UPG,#)<)S`W+CM]>UQL979E;&YU;6)E<G-<)S`Q.WU<8VAB<F1R7&)R
M9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q(%QF
M:2TS-C!<;&DU-S8P#5QJ8VQI<W1T86)<='@U-S8P('U[7&QI<W1L979E;%QL
M979E;&YF8S)<;&5V96QN9F-N,EQL979E;&IC,EQL979E;&IC;C)<;&5V96QF
M;VQL;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C93!<;&5V96QI;F1E;G0P
M>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED,3<W,#4P-5PG,#)<)S`X+CM]
M>UQL979E;&YU;6)E<G-<)S`Q.WU<8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@
M7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q(%QF:2TQ.#!<;&DV-#@P#5QJ
M8VQI<W1T86)<='@V-#@P('U[7&QI<W1N86UE(#M]7&QI<W1I9#$P-3@Y,SDU
M,S)]>UQL:7-T7&QI<W1T96UP;&%T96ED+3$Y-C4P,C(Q,C!<;&ES=&AY8G)I
M9'M<;&ES=&QE=F5L7&QE=F5L;F9C,%QL979E;&YF8VXP7&QE=F5L:F,P7&QE
M=F5L:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P86-E
M,%QL979E;&EN9&5N=#![7&QE=F5L=&5X=%QL979E;'1E;7!L871E:60Q,3$U
M,30U7"<P,EPG,#`I.WU[7&QE=F5L;G5M8F5R<PU<)S`Q.WU<8VAB<F1R7&)R
M9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B
M:6%S,"!<9FDM,S8P7&QI-S(P7&IC;&ES='1A8EQT>#<R,"!]>UQL:7-T;&5V
M96Q<;&5V96QN9F,T7&QE=F5L;F9C;C1<;&5V96QJ8S!<;&5V96QJ8VXP7&QE
M=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4P7&QE=F5L:6YD
M96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#$V,SDT,S,-7"<P,EPG
M,#$N.WU[7&QE=F5L;G5M8F5R<UPG,#$[?5QC:&)R9')<8G)D<FYO;F5<8G)D
M<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A=#$@7&9I+3,V,%QL:3$T
M-#!<:F-L:7-T=&%B7'1X,30T,"!]>UQL:7-T;&5V96Q<;&5V96QN9F,R7&QE
M=F5L;F9C;C)<;&5V96QJ8S)<;&5V96QJ8VXR7&QE=F5L9F]L;&]W,%QL979E
M;'-T87)T870Q7&QE=F5L<W!A8V4P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT
M7&QE=F5L=&5M<&QA=&5I9#$W-S`U,#4-7"<P,EPG,#(N.WU[7&QE=F5L;G5M
M8F5R<UPG,#$[?5QC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<
M8VAC9G!A=#%<8VAC8G!A=#$@7&9I+3$X,%QL:3(Q-C!<:F-L:7-T=&%B7'1X
M,C$V,"!]>UQL:7-T;&5V96Q<;&5V96QN9F,P7&QE=F5L;F9C;C!<;&5V96QJ
M8S!<;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L
M<W!A8V4P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I
M9#DX-#`W,PU<)S`R7"<P,RX[?7M<;&5V96QN=6UB97)S7"<P,3M]7&-H8G)D
M<EQB<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T
M,2!<9FDM,S8P7&QI,C@X,%QJ8VQI<W1T86)<='@R.#@P('U[7&QI<W1L979E
M;%QL979E;&YF8S1<;&5V96QN9F-N-%QL979E;&IC,%QL979E;&IC;C!<;&5V
M96QF;VQL;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C93!<;&5V96QI;F1E
M;G0P>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED,38S.30S,PU<)S`R7"<P
M-"X[?7M<;&5V96QN=6UB97)S7"<P,3M]7&-H8G)D<EQB<F1R;F]N95QB<F1R
M8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,2!<9FDM,S8P7&QI,S8P
M,%QJ8VQI<W1T86)<='@S-C`P('U[7&QI<W1L979E;%QL979E;&YF8S)<;&5V
M96QN9F-N,EQL979E;&IC,EQL979E;&IC;C)<;&5V96QF;VQL;W<P7&QE=F5L
M<W1A<G1A=#%<;&5V96QS<&%C93!<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<
M;&5V96QT96UP;&%T96ED,3<W,#4P-0U<)S`R7"<P-2X[?7M<;&5V96QN=6UB
M97)S7"<P,3M]7&-H8G)D<EQB<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC
M:&-F<&%T,5QC:&-B<&%T,2!<9FDM,3@P7&QI-#,R,%QJ8VQI<W1T86)<='@T
M,S(P('U[7&QI<W1L979E;%QL979E;&YF8S!<;&5V96QN9F-N,%QL979E;&IC
M,%QL979E;&IC;C!<;&5V96QF;VQL;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS
M<&%C93!<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED
M.3@T,#<S#5PG,#)<)S`V+CM]>UQL979E;&YU;6)E<G-<)S`Q.WU<8VAB<F1R
M7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q
M(%QF:2TS-C!<;&DU,#0P7&IC;&ES='1A8EQT>#4P-#`@?7M<;&ES=&QE=F5L
M7&QE=F5L;F9C-%QL979E;&YF8VXT7&QE=F5L:F,P7&QE=F5L:F-N,%QL979E
M;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P86-E,%QL979E;&EN9&5N
M=#![7&QE=F5L=&5X=%QL979E;'1E;7!L871E:60Q-C,Y-#,S#5PG,#)<)S`W
M+CM]>UQL979E;&YU;6)E<G-<)S`Q.WU<8VAB<F1R7&)R9')N;VYE7&)R9')C
M9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q(%QF:2TS-C!<;&DU-S8P
M7&IC;&ES='1A8EQT>#4W-C`@?7M<;&ES=&QE=F5L7&QE=F5L;F9C,EQL979E
M;&YF8VXR7&QE=F5L:F,R7&QE=F5L:F-N,EQL979E;&9O;&QO=S!<;&5V96QS
M=&%R=&%T,5QL979E;'-P86-E,%QL979E;&EN9&5N=#![7&QE=F5L=&5X=%QL
M979E;'1E;7!L871E:60Q-S<P-3`U#5PG,#)<)S`X+CM]>UQL979E;&YU;6)E
M<G-<)S`Q.WU<8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H
M8V9P870Q7&-H8V)P870Q(%QF:2TQ.#!<;&DV-#@P7&IC;&ES='1A8EQT>#8T
M.#`@?7M<;&ES=&YA;64@.WU<;&ES=&ED,3`Y-3,Y-#0X-'U[7&QI<W1<;&ES
M='1E;7!L871E:60M,3<Y,SDU-3DX-EQL:7-T:'EB<FED>UQL:7-T;&5V96Q<
M;&5V96QN9F,R,UQL979E;&YF8VXR,UQL979E;&IC,%QL979E;&IC;C`-7&QE
M=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4S-C!<;&5V96QI
M;F1E;G0P>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED-C8U-CE<)S`Q7'4M
M,SDQ,R!?.WU[7&QE=F5L;G5M8F5R<SM]7&8S7&-H8G)D<EQB<F1R;F]N95QB
M<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,5QF8FEA<S`@7&QO
M8VA<868S7&1B8VA<868P7&AI8VA<9C,@7&9I+3,V,%QL:3<R,%QJ8VQI<W1T
M86)<='@W,C`@?7M<;&ES=&QE=F5L#5QL979E;&YF8S(S7&QE=F5L;F9C;C(S
M7&QE=F5L:F,P7&QE=F5L:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T
M,5QL979E;'-P86-E,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE=F5L
M=&5M<&QA=&5I9#$Y-S8T,5PG,#%O.WU[7&QE=F5L;G5M8F5R<SM]7&8R7&-H
M8G)D<EQB<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B
M<&%T,5QF8FEA<S`@7&9I+3,V,%QL:3$T-#!<:F-L:7-T=&%B7'1X,30T,"!]
M#7M<;&ES=&QE=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N,C-<;&5V96QJ8S!<
M;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A
M8V4S-C!<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED
M,S(X-S$S7"<P,5QU+3,Y,CD@7SM]>UQL979E;&YU;6)E<G,[?5QF,31<8VAB
M<F1R7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P
M870Q7&9B:6%S,"!<9FDM,S8P7&QI,C$V,`U<:F-L:7-T=&%B7'1X,C$V,"!]
M>UQL:7-T;&5V96Q<;&5V96QN9F,R,UQL979E;&YF8VXR,UQL979E;&IC,%QL
M979E;&IC;C!<;&5V96QF;VQL;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C
M93,V,%QL979E;&EN9&5N=#![7&QE=F5L=&5X=%QL979E;'1E;7!L871E:60V
M-C4V.5PG,#%<=2TS.3$S(%\[?7M<;&5V96QN=6UB97)S.WU<9C-<8VAB<F1R
M7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q
M7&9B:6%S,"`-7&QO8VA<868S7&1B8VA<868P7&AI8VA<9C,@7&9I+3,V,%QL
M:3(X.#!<:F-L:7-T=&%B7'1X,C@X,"!]>UQL:7-T;&5V96Q<;&5V96QN9F,R
M,UQL979E;&YF8VXR,UQL979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL;W<P
M7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C93,V,%QL979E;&EN9&5N=#![7&QE
M=F5L=&5X=%QL979E;'1E;7!L871E:60Q.3<V-#%<)S`Q;SM]>UQL979E;&YU
M;6)E<G,[?5QF,EQC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2`-7&-H<VAD;F<P
M7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<9FDM,S8P7&QI,S8P,%QJ8VQI
M<W1T86)<='@S-C`P('U[7&QI<W1L979E;%QL979E;&YF8S(S7&QE=F5L;F9C
M;C(S7&QE=F5L:F,P7&QE=F5L:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R
M=&%T,5QL979E;'-P86-E,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE
M=F5L=&5M<&QA=&5I9#,R.#<Q,UPG,#%<=2TS.3(Y(%\[?7M<;&5V96QN=6UB
M97)S.WU<9C$T7&-H8G)D<@U<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<
M8VAC9G!A=#%<8VAC8G!A=#%<9F)I87,P(%QF:2TS-C!<;&DT,S(P7&IC;&ES
M='1A8EQT>#0S,C`@?7M<;&ES=&QE=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N
M,C-<;&5V96QJ8S!<;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T
M870Q7&QE=F5L<W!A8V4S-C!<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V
M96QT96UP;&%T96ED-C8U-CE<)S`Q7'4M,SDQ,R!?.WU[7&QE=F5L;G5M8F5R
M<PT[?5QF,UQC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC
M9G!A=#%<8VAC8G!A=#%<9F)I87,P(%QL;V-H7&%F,UQD8F-H7&%F,%QH:6-H
M7&8S(%QF:2TS-C!<;&DU,#0P7&IC;&ES='1A8EQT>#4P-#`@?7M<;&ES=&QE
M=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N,C-<;&5V96QJ8S!<;&5V96QJ8VXP
M7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4S-C!<;&5V
M96QI;F1E;G0P>UQL979E;'1E>'0-7&QE=F5L=&5M<&QA=&5I9#$Y-S8T,5PG
M,#%O.WU[7&QE=F5L;G5M8F5R<SM]7&8R7&-H8G)D<EQB<F1R;F]N95QB<F1R
M8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,5QF8FEA<S`@7&9I+3,V
M,%QL:34W-C!<:F-L:7-T=&%B7'1X-3<V,"!]>UQL:7-T;&5V96Q<;&5V96QN
M9F,R,UQL979E;&YF8VXR,UQL979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL
M;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C93,V,%QL979E;&EN9&5N=#`-
M>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED,S(X-S$S7"<P,5QU+3,Y,CD@
M7SM]>UQL979E;&YU;6)E<G,[?5QF,31<8VAB<F1R7&)R9')N;VYE7&)R9')C
M9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<9FDM,S8P
M7&QI-C0X,%QJ8VQI<W1T86)<='@V-#@P('U[7&QI<W1N86UE(#M]7&QI<W1I
M9#$Q,C<R,S@U.35]>UQL:7-T7&QI<W1T96UP;&%T96ED,3(Q,#`X-34S,%QL
M:7-T:'EB<FED>UQL:7-T;&5V96P-7&QE=F5L;F9C,C-<;&5V96QN9F-N,C-<
M;&5V96QJ8S!<;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q
M7&QE=F5L<W!A8V4S-C!<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V96QT
M96UP;&%T96ED-C8U-CE<)S`Q7'4M,SDQ,R!?.WU[7&QE=F5L;G5M8F5R<SM]
M7&8S7&-H8G)D<EQB<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T
M,5QC:&-B<&%T,5QF8FEA<S`@7&QO8VA<868S7&1B8VA<868P7&AI8VA<9C,@
M#5QF:2TS-C!<;&DW,C!<:F-L:7-T=&%B7'1X-S(P('U[7&QI<W1L979E;%QL
M979E;&YF8S(S7&QE=F5L;F9C;C(S7&QE=F5L:F,P7&QE=F5L:F-N,%QL979E
M;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P86-E,S8P7&QE=F5L:6YD
M96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#$Y-S8T,5PG,#%O.WU[
M7&QE=F5L;G5M8F5R<SM]7&8R7&-H8G)D<EQB<F1R;F]N95QB<F1R8V8Q(`U<
M8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A=#%<9F)I87,P(%QF:2TS-C!<;&DQ
M-#0P7&IC;&ES='1A8EQT>#$T-#`@?7M<;&ES=&QE=F5L7&QE=F5L;F9C,C-<
M;&5V96QN9F-N,C-<;&5V96QJ8S!<;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL
M979E;'-T87)T870Q7&QE=F5L<W!A8V4S-C!<;&5V96QI;F1E;G0P>UQL979E
M;'1E>'1<;&5V96QT96UP;&%T96ED,S(X-S$S7"<P,5QU+3,Y,CD@7SM]>UQL
M979E;&YU;6)E<G,[?5QF,31<8VAB<F1R#5QB<F1R;F]N95QB<F1R8V8Q(%QC
M:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,5QF8FEA<S`@7&9I+3,V,%QL:3(Q
M-C!<:F-L:7-T=&%B7'1X,C$V,"!]>UQL:7-T;&5V96Q<;&5V96QN9F,R,UQL
M979E;&YF8VXR,UQL979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL;W<P7&QE
M=F5L<W1A<G1A=#%<;&5V96QS<&%C93,V,%QL979E;&EN9&5N=#![7&QE=F5L
M=&5X=%QL979E;'1E;7!L871E:60V-C4V.5PG,#%<=2TS.3$S(%\[?7M<;&5V
M96QN=6UB97)S#3M]7&8S7&-H8G)D<EQB<F1R;F]N95QB<F1R8V8Q(%QC:'-H
M9&YG,%QC:&-F<&%T,5QC:&-B<&%T,5QF8FEA<S`@7&QO8VA<868S7&1B8VA<
M868P7&AI8VA<9C,@7&9I+3,V,%QL:3(X.#!<:F-L:7-T=&%B7'1X,C@X,"!]
M>UQL:7-T;&5V96Q<;&5V96QN9F,R,UQL979E;&YF8VXR,UQL979E;&IC,%QL
M979E;&IC;C!<;&5V96QF;VQL;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C
M93,V,%QL979E;&EN9&5N=#![7&QE=F5L=&5X=`U<;&5V96QT96UP;&%T96ED
M,3DW-C0Q7"<P,6\[?7M<;&5V96QN=6UB97)S.WU<9C)<8VAB<F1R7&)R9')N
M;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S
M,"!<9FDM,S8P7&QI,S8P,%QJ8VQI<W1T86)<='@S-C`P('U[7&QI<W1L979E
M;%QL979E;&YF8S(S7&QE=F5L;F9C;C(S7&QE=F5L:F,P7&QE=F5L:F-N,%QL
M979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P86-E,S8P7&QE=F5L
M:6YD96YT,`U[7&QE=F5L=&5X=%QL979E;'1E;7!L871E:60S,C@W,3-<)S`Q
M7'4M,SDR.2!?.WU[7&QE=F5L;G5M8F5R<SM]7&8Q-%QC:&)R9')<8G)D<FYO
M;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A=#%<9F)I87,P
M(%QF:2TS-C!<;&DT,S(P7&IC;&ES='1A8EQT>#0S,C`@?7M<;&ES=&QE=F5L
M7&QE=F5L;F9C,C-<;&5V96QN9F-N,C-<;&5V96QJ8S!<;&5V96QJ8VXP7&QE
M=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4S-C`-7&QE=F5L
M:6YD96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#8V-38Y7"<P,5QU
M+3,Y,3,@7SM]>UQL979E;&YU;6)E<G,[?5QF,UQC:&)R9')<8G)D<FYO;F5<
M8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A=#%<9F)I87,P(%QL
M;V-H7&%F,UQD8F-H7&%F,%QH:6-H7&8S(%QF:2TS-C!<;&DU,#0P7&IC;&ES
M='1A8EQT>#4P-#`@?7M<;&ES=&QE=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N
M,C-<;&5V96QJ8S!<;&5V96QJ8VXP#5QL979E;&9O;&QO=S!<;&5V96QS=&%R
M=&%T,5QL979E;'-P86-E,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE
M=F5L=&5M<&QA=&5I9#$Y-S8T,5PG,#%O.WU[7&QE=F5L;G5M8F5R<SM]7&8R
M7&-H8G)D<EQB<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC
M:&-B<&%T,5QF8FEA<S`@7&9I+3,V,%QL:34W-C!<:F-L:7-T=&%B7'1X-3<V
M,"!]>UQL:7-T;&5V96Q<;&5V96QN9F,R,UQL979E;&YF8VXR,UQL979E;&IC
M,`U<;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L
M<W!A8V4S-C!<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V96QT96UP;&%T
M96ED,S(X-S$S7"<P,5QU+3,Y,CD@7SM]>UQL979E;&YU;6)E<G,[?5QF,31<
M8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H
M8V)P870Q7&9B:6%S,"!<9FDM,S8P7&QI-C0X,%QJ8VQI<W1T86)<='@V-#@P
M('U[7&QI<W1N86UE(#M]7&QI<W1I9#$R.3,U-30S.#D-?7M<;&ES=%QL:7-T
M=&5M<&QA=&5I9#$Q-#$P,3DW,C)<;&ES=&AY8G)I9'M<;&ES=&QE=F5L7&QE
M=F5L;F9C,C-<;&5V96QN9F-N,C-<;&5V96QJ8S!<;&5V96QJ8VXP7&QE=F5L
M9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4S-C!<;&5V96QI;F1E
M;G0P>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED-C8U-CE<)S`Q7'4M,SDQ
M,R!?.WU[7&QE=F5L;G5M8F5R<SM]7&8S7&-H8G)D<EQB<F1R;F]N95QB<F1R
M8V8Q(`U<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A=#%<9F)I87,P(%QL;V-H
M7&%F,UQD8F-H7&%F,%QH:6-H7&8S(%QF:2TS-C!<;&DW,C!<:F-L:7-T=&%B
M7'1X-S(P('U[7&QI<W1L979E;%QL979E;&YF8S(S7&QE=F5L;F9C;C(S7&QE
M=F5L:F,P7&QE=F5L:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL
M979E;'-P86-E,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE=F5L=&5M
M<&QA=&5I9#$Y-S8T,5PG,#%O.WU[7&QE=F5L;G5M8F5R<PT[?5QF,EQC:&)R
M9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A
M=#%<9F)I87,P(%QF:2TS-C!<;&DQ-#0P7&IC;&ES='1A8EQT>#$T-#`@?7M<
M;&ES=&QE=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N,C-<;&5V96QJ8S!<;&5V
M96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4S
M-C!<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED,S(X
M-S$S#5PG,#%<=2TS.3(Y(%\[?7M<;&5V96QN=6UB97)S.WU<9C$T7&-H8G)D
M<EQB<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T
M,5QF8FEA<S`@7&9I+3,V,%QL:3(Q-C!<:F-L:7-T=&%B7'1X,C$V,"!]>UQL
M:7-T;&5V96Q<;&5V96QN9F,R,UQL979E;&YF8VXR,UQL979E;&IC,%QL979E
M;&IC;C!<;&5V96QF;VQL;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C93,V
M,%QL979E;&EN9&5N=#![7&QE=F5L=&5X=`U<;&5V96QT96UP;&%T96ED-C8U
M-CE<)S`Q7'4M,SDQ,R!?.WU[7&QE=F5L;G5M8F5R<SM]7&8S7&-H8G)D<EQB
M<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,5QF
M8FEA<S`@7&QO8VA<868S7&1B8VA<868P7&AI8VA<9C,@7&9I+3,V,%QL:3(X
M.#!<:F-L:7-T=&%B7'1X,C@X,"!]>UQL:7-T;&5V96Q<;&5V96QN9F,R,UQL
M979E;&YF8VXR,UQL979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL;W<P7&QE
M=F5L<W1A<G1A=#$-7&QE=F5L<W!A8V4S-C!<;&5V96QI;F1E;G0P>UQL979E
M;'1E>'1<;&5V96QT96UP;&%T96ED,3DW-C0Q7"<P,6\[?7M<;&5V96QN=6UB
M97)S.WU<9C)<8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H
M8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<9FDM,S8P7&QI,S8P,%QJ8VQI<W1T
M86)<='@S-C`P('U[7&QI<W1L979E;%QL979E;&YF8S(S7&QE=F5L;F9C;C(S
M7&QE=F5L:F,P7&QE=F5L:F-N,%QL979E;&9O;&QO=S`-7&QE=F5L<W1A<G1A
M=#%<;&5V96QS<&%C93,V,%QL979E;&EN9&5N=#![7&QE=F5L=&5X=%QL979E
M;'1E;7!L871E:60S,C@W,3-<)S`Q7'4M,SDR.2!?.WU[7&QE=F5L;G5M8F5R
M<SM]7&8Q-%QC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC
M9G!A=#%<8VAC8G!A=#%<9F)I87,P(%QF:2TS-C!<;&DT,S(P7&IC;&ES='1A
M8EQT>#0S,C`@?7M<;&ES=&QE=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N,C-<
M;&5V96QJ8S!<;&5V96QJ8VXP#5QL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T
M,5QL979E;'-P86-E,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE=F5L
M=&5M<&QA=&5I9#8V-38Y7"<P,5QU+3,Y,3,@7SM]>UQL979E;&YU;6)E<G,[
M?5QF,UQC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A
M=#%<8VAC8G!A=#%<9F)I87,P(%QL;V-H7&%F,UQD8F-H7&%F,%QH:6-H7&8S
M(%QF:2TS-C!<;&DU,#0P7&IC;&ES='1A8EQT>#4P-#`@?7M<;&ES=&QE=F5L
M#5QL979E;&YF8S(S7&QE=F5L;F9C;C(S7&QE=F5L:F,P7&QE=F5L:F-N,%QL
M979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P86-E,S8P7&QE=F5L
M:6YD96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#$Y-S8T,5PG,#%O
M.WU[7&QE=F5L;G5M8F5R<SM]7&8R7&-H8G)D<EQB<F1R;F]N95QB<F1R8V8Q
M(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,5QF8FEA<S`@7&9I+3,V,%QL
M:34W-C!<:F-L:7-T=&%B7'1X-3<V,"!]#7M<;&ES=&QE=F5L7&QE=F5L;F9C
M,C-<;&5V96QN9F-N,C-<;&5V96QJ8S!<;&5V96QJ8VXP7&QE=F5L9F]L;&]W
M,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4S-C!<;&5V96QI;F1E;G0P>UQL
M979E;'1E>'1<;&5V96QT96UP;&%T96ED,S(X-S$S7"<P,5QU+3,Y,CD@7SM]
M>UQL979E;&YU;6)E<G,[?5QF,31<8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@
M7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<9FDM,S8P7&QI
M-C0X,`U<:F-L:7-T=&%B7'1X-C0X,"!]>UQL:7-T;F%M92`[?5QL:7-T:60Q
M-#DS,S8Y.3@V?7M<;&ES=%QL:7-T=&5M<&QA=&5I9#0W-3$Y.#DW-EQL:7-T
M:'EB<FED>UQL:7-T;&5V96Q<;&5V96QN9F,P7&QE=F5L;F9C;C!<;&5V96QJ
M8S!<;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L
M<W!A8V4S-C!<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V96QT96UP;&%T
M96ED.3@T,#<S7"<P,EPG,#`N.WU[7&QE=F5L;G5M8F5R<PU<)S`Q.WU<8VAB
M<F1R7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P
M870Q(%QF:2TS-C!<;&DW,C!<:F-L:7-T=&%B7'1X-S(P('U[7&QI<W1L979E
M;%QL979E;&YF8S1<;&5V96QN9F-N-%QL979E;&IC,%QL979E;&IC;C!<;&5V
M96QF;VQL;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C93,V,%QL979E;&EN
M9&5N=#![7&QE=F5L=&5X=%QL979E;'1E;7!L871E:60Q-C,Y-#,S7"<P,EPG
M,#$N.WU[7&QE=F5L;G5M8F5R<PU<)S`Q.WU<8VAB<F1R7&)R9')N;VYE7&)R
M9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q(%QF:2TS-C!<;&DQ
M-#0P7&IC;&ES='1A8EQT>#$T-#`@?7M<;&ES=&QE=F5L7&QE=F5L;F9C,EQL
M979E;&YF8VXR7&QE=F5L:F,R7&QE=F5L:F-N,EQL979E;&9O;&QO=S!<;&5V
M96QS=&%R=&%T,5QL979E;'-P86-E,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT
M97AT7&QE=F5L=&5M<&QA=&5I9#$W-S`U,#4-7"<P,EPG,#(N.WU[7&QE=F5L
M;G5M8F5R<UPG,#$[?5QC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N
M9S!<8VAC9G!A=#%<8VAC8G!A=#$@7&9I+3$X,%QL:3(Q-C!<:F-L:7-T=&%B
M7'1X,C$V,"!]>UQL:7-T;&5V96Q<;&5V96QN9F,P7&QE=F5L;F9C;C!<;&5V
M96QJ8S!<;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE
M=F5L<W!A8V4S-C!<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V96QT96UP
M;&%T96ED.3@T,#<S#5PG,#)<)S`S+CM]>UQL979E;&YU;6)E<G-<)S`Q.WU<
M8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H
M8V)P870Q(%QF:2TS-C!<;&DR.#@P7&IC;&ES='1A8EQT>#(X.#`@?7M<;&ES
M=&QE=F5L7&QE=F5L;F9C-%QL979E;&YF8VXT7&QE=F5L:F,P7&QE=F5L:F-N
M,%QL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P86-E,S8P7&QE
M=F5L:6YD96YT,'M<;&5V96QT97AT#5QL979E;'1E;7!L871E:60Q-C,Y-#,S
M7"<P,EPG,#0N.WU[7&QE=F5L;G5M8F5R<UPG,#$[?5QC:&)R9')<8G)D<FYO
M;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A=#$@7&9I+3,V
M,%QL:3,V,#!<:F-L:7-T=&%B7'1X,S8P,"!]>UQL:7-T;&5V96Q<;&5V96QN
M9F,R7&QE=F5L;F9C;C)<;&5V96QJ8S)<;&5V96QJ8VXR7&QE=F5L9F]L;&]W
M,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4S-C!<;&5V96QI;F1E;G0P#7M<
M;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#$W-S`U,#5<)S`R7"<P-2X[?7M<
M;&5V96QN=6UB97)S7"<P,3M]7&-H8G)D<EQB<F1R;F]N95QB<F1R8V8Q(%QC
M:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,2!<9FDM,3@P7&QI-#,R,%QJ8VQI
M<W1T86)<='@T,S(P('U[7&QI<W1L979E;%QL979E;&YF8S!<;&5V96QN9F-N
M,%QL979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL;W<P7&QE=F5L<W1A<G1A
M=#%<;&5V96QS<&%C93,V,`U<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V
M96QT96UP;&%T96ED.3@T,#<S7"<P,EPG,#8N.WU[7&QE=F5L;G5M8F5R<UPG
M,#$[?5QC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A
M=#%<8VAC8G!A=#$@7&9I+3,V,%QL:34P-#!<:F-L:7-T=&%B7'1X-3`T,"!]
M>UQL:7-T;&5V96Q<;&5V96QN9F,T7&QE=F5L;F9C;C1<;&5V96QJ8S!<;&5V
M96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4S
M-C`-7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#$V
M,SDT,S-<)S`R7"<P-RX[?7M<;&5V96QN=6UB97)S7"<P,3M]7&-H8G)D<EQB
M<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,2!<
M9FDM,S8P7&QI-3<V,%QJ8VQI<W1T86)<='@U-S8P('U[7&QI<W1L979E;%QL
M979E;&YF8S)<;&5V96QN9F-N,EQL979E;&IC,EQL979E;&IC;C)<;&5V96QF
M;VQL;W<P7&QE=F5L<W1A<G1A=#$-7&QE=F5L<W!A8V4S-C!<;&5V96QI;F1E
M;G0P>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED,3<W,#4P-5PG,#)<)S`X
M+CM]>UQL979E;&YU;6)E<G-<)S`Q.WU<8VAB<F1R7&)R9')N;VYE7&)R9')C
M9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q(%QF:2TQ.#!<;&DV-#@P
M7&IC;&ES='1A8EQT>#8T.#`@?7M<;&ES=&YA;64@.WU<;&ES=&ED,38Q-3`Y
M,C(X-7U[7&QI<W1<;&ES='1E;7!L871E:60R-#DW,#<R,#1<;&ES=&AY8G)I
M9`U[7&QI<W1L979E;%QL979E;&YF8S(S7&QE=F5L;F9C;C(S7&QE=F5L:F,P
M7&QE=F5L:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P
M86-E,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I
M9#8V-38Y7"<P,5QU+3,Y,3,@7SM]>UQL979E;&YU;6)E<G,[?5QF,UQC:&)R
M9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A
M=#%<9F)I87,P(`U<;&]C:%QA9C-<9&)C:%QA9C!<:&EC:%QF,R!<9FDM,S8P
M7&QI-S(P7&IC;&ES='1A8EQT>#<R,"!]>UQL:7-T;&5V96Q<;&5V96QN9F,R
M,UQL979E;&YF8VXR,UQL979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL;W<P
M7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C93,V,%QL979E;&EN9&5N=#![7&QE
M=F5L=&5X=%QL979E;'1E;7!L871E:60Q.3<V-#%<)S`Q;SM]>UQL979E;&YU
M;6)E<G,[?5QF,EQC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2`-7&-H<VAD;F<P
M7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<9FDM,S8P7&QI,30T,%QJ8VQI
M<W1T86)<='@Q-#0P('U[7&QI<W1L979E;%QL979E;&YF8S(S7&QE=F5L;F9C
M;C(S7&QE=F5L:F,P7&QE=F5L:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R
M=&%T,5QL979E;'-P86-E,S8P7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE
M=F5L=&5M<&QA=&5I9#,R.#<Q,UPG,#%<=2TS.3(Y(%\[?7M<;&5V96QN=6UB
M97)S.WU<9C$T7&-H8G)D<@U<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<
M8VAC9G!A=#%<8VAC8G!A=#%<9F)I87,P(%QF:2TS-C!<;&DR,38P7&IC;&ES
M='1A8EQT>#(Q-C`@?7M<;&ES=&QE=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N
M,C-<;&5V96QJ8S!<;&5V96QJ8VXP7&QE=F5L9F]L;&]W,%QL979E;'-T87)T
M870Q7&QE=F5L<W!A8V4S-C!<;&5V96QI;F1E;G0P>UQL979E;'1E>'1<;&5V
M96QT96UP;&%T96ED-C8U-CE<)S`Q7'4M,SDQ,R!?.WU[7&QE=F5L;G5M8F5R
M<PT[?5QF,UQC:&)R9')<8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC
M9G!A=#%<8VAC8G!A=#%<9F)I87,P(%QL;V-H7&%F,UQD8F-H7&%F,%QH:6-H
M7&8S(%QF:2TS-C!<;&DR.#@P7&IC;&ES='1A8EQT>#(X.#`@?7M<;&ES=&QE
M=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N,C-<;&5V96QJ8S!<;&5V96QJ8VXP
M7&QE=F5L9F]L;&]W,%QL979E;'-T87)T870Q7&QE=F5L<W!A8V4S-C!<;&5V
M96QI;F1E;G0P>UQL979E;'1E>'0-7&QE=F5L=&5M<&QA=&5I9#$Y-S8T,5PG
M,#%O.WU[7&QE=F5L;G5M8F5R<SM]7&8R7&-H8G)D<EQB<F1R;F]N95QB<F1R
M8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,5QF8FEA<S`@7&9I+3,V
M,%QL:3,V,#!<:F-L:7-T=&%B7'1X,S8P,"!]>UQL:7-T;&5V96Q<;&5V96QN
M9F,R,UQL979E;&YF8VXR,UQL979E;&IC,%QL979E;&IC;C!<;&5V96QF;VQL
M;W<P7&QE=F5L<W1A<G1A=#%<;&5V96QS<&%C93,V,%QL979E;&EN9&5N=#`-
M>UQL979E;'1E>'1<;&5V96QT96UP;&%T96ED,S(X-S$S7"<P,5QU+3,Y,CD@
M7SM]>UQL979E;&YU;6)E<G,[?5QF,31<8VAB<F1R7&)R9')N;VYE7&)R9')C
M9C$@7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<9FDM,S8P
M7&QI-#,R,%QJ8VQI<W1T86)<='@T,S(P('U[7&QI<W1L979E;%QL979E;&YF
M8S(S7&QE=F5L;F9C;C(S7&QE=F5L:F,P7&QE=F5L:F-N,%QL979E;&9O;&QO
M=S!<;&5V96QS=&%R=&%T,5QL979E;'-P86-E,S8P#5QL979E;&EN9&5N=#![
M7&QE=F5L=&5X=%QL979E;'1E;7!L871E:60V-C4V.5PG,#%<=2TS.3$S(%\[
M?7M<;&5V96QN=6UB97)S.WU<9C-<8VAB<F1R7&)R9')N;VYE7&)R9')C9C$@
M7&-H<VAD;F<P7&-H8V9P870Q7&-H8V)P870Q7&9B:6%S,"!<;&]C:%QA9C-<
M9&)C:%QA9C!<:&EC:%QF,R!<9FDM,S8P7&QI-3`T,%QJ8VQI<W1T86)<='@U
M,#0P('U[7&QI<W1L979E;%QL979E;&YF8S(S7&QE=F5L;F9C;C(S7&QE=F5L
M:F,P7&QE=F5L:F-N,`U<;&5V96QF;VQL;W<P7&QE=F5L<W1A<G1A=#%<;&5V
M96QS<&%C93,V,%QL979E;&EN9&5N=#![7&QE=F5L=&5X=%QL979E;'1E;7!L
M871E:60Q.3<V-#%<)S`Q;SM]>UQL979E;&YU;6)E<G,[?5QF,EQC:&)R9')<
M8G)D<FYO;F5<8G)D<F-F,2!<8VAS:&1N9S!<8VAC9G!A=#%<8VAC8G!A=#%<
M9F)I87,P(%QF:2TS-C!<;&DU-S8P7&IC;&ES='1A8EQT>#4W-C`@?7M<;&ES
M=&QE=F5L7&QE=F5L;F9C,C-<;&5V96QN9F-N,C-<;&5V96QJ8S`-7&QE=F5L
M:F-N,%QL979E;&9O;&QO=S!<;&5V96QS=&%R=&%T,5QL979E;'-P86-E,S8P
M7&QE=F5L:6YD96YT,'M<;&5V96QT97AT7&QE=F5L=&5M<&QA=&5I9#,R.#<Q
M,UPG,#%<=2TS.3(Y(%\[?7M<;&5V96QN=6UB97)S.WU<9C$T7&-H8G)D<EQB
M<F1R;F]N95QB<F1R8V8Q(%QC:'-H9&YG,%QC:&-F<&%T,5QC:&-B<&%T,5QF
M8FEA<S`@7&9I+3,V,%QL:38T.#!<:F-L:7-T=&%B7'1X-C0X,"!]>UQL:7-T
M;F%M92`[?5QL:7-T:60Q-S$Y-#<U,S8Q#7U]>UPJ7&QI<W1O=F5R<FED971A
M8FQE>UQL:7-T;W9E<G)I9&5<;&ES=&ED.#`T,3DQ-3-<;&ES=&]V97)R:61E
M8V]U;G0P7&QS,7U[7&QI<W1O=F5R<FED95QL:7-T:60Q,CDS-34T,S@Y7&QI
M<W1O=F5R<FED96-O=6YT,%QL<S)]>UQL:7-T;W9E<G)I9&5<;&ES=&ED,3<Q
M.30W-3,V,5QL:7-T;W9E<G)I9&5C;W5N=#!<;',S?7M<;&ES=&]V97)R:61E
M7&QI<W1I9#<P,C(Y,C@Y-EQL:7-T;W9E<G)I9&5C;W5N=#!<;',T?0U[7&QI
M<W1O=F5R<FED95QL:7-T:60R,C(R,#$R.5QL:7-T;W9E<G)I9&5C;W5N=#!<
M;',U?7M<;&ES=&]V97)R:61E7&QI<W1I9#$Q,C<R,S@U.35<;&ES=&]V97)R
M:61E8V]U;G0P7&QS-GU[7&QI<W1O=F5R<FED95QL:7-T:60Q-#DS,S8Y.3@V
M7&QI<W1O=F5R<FED96-O=6YT,%QL<S=]>UQL:7-T;W9E<G)I9&5<;&ES=&ED
M,3`U.#DS.34S,EQL:7-T;W9E<G)I9&5C;W5N=#!<;',X?7M<;&ES=&]V97)R
M:61E7&QI<W1I9#<Q,#8Y,3`P,PU<;&ES=&]V97)R:61E8V]U;G0P7&QS.7U[
M7&QI<W1O=F5R<FED95QL:7-T:60Q,#DU,SDT-#@T7&QI<W1O=F5R<FED96-O
M=6YT,%QL<S$P?7M<;&ES=&]V97)R:61E7&QI<W1I9#$V,34P.3(R.#5<;&ES
M=&]V97)R:61E8V]U;G0P7&QS,3%]?7M<:6YF;WM<=&ET;&4@1TE!0R!.971W
M;W)K(%-E8W5R:71Y($=#1E<@5C(N,"`H36%Y(#(V+"`R,#`S*7U[7'-U8FIE
M8W0@1TE!0R!.971W;W)K(%-E8W5R:71Y($=#1E<@5C(N,"`H36%Y(#(V+"`R
M,#`S*7T->UQA=71H;W(@5VEL;&EA;2!++B!(;VQL:7-]>UQK97EW;W)D<R!'
M24%#($YE='=O<FL@4V5C=7)I='E]>UQD;V-C;VUM($1A=&4@4W5B;6ET=&5D
M.B`R,#`T+S`Q+S`W?7M<;W!E<F%T;W(@1V%N9&%L9B!4:&4@5VAI=&5]>UQC
M<F5A=&EM7'ER,C`P-%QM;S%<9'DS,5QH<C$S7&UI;C$V?7M<<F5V=&EM7'ER
M,C`P-%QM;S%<9'DS,5QH<C$S7&UI;C$V?7M<<')I;G1I;5QY<C(P,#1<;6\Q
M7&1Y-EQH<C$R7&UI;C0S?7M<=F5R<VEO;C)]#7M<961M:6YS,'U[7&YO9G!A
M9V5S,WU[7&YO9G=O<F1S,CDW-#)]>UQN;V9C:&%R<S$V.34S,GU[7"I<8V]M
M<&%N>2!.;VYE?7M<;F]F8VAA<G-W<S(P.#$Y-WU[7'9E<FXQ-C4R,7U]7&UA
M<F=L,30T,%QM87)G<C$T-#`@7'=I9&]W8W1R;%QF=&YB:EQA96YD9&]C7&YO
M>&QA='1O>65N7&5X<'-H<G1N7&YO=6QT<FQS<&-<9&YT8FQN<V)D8EQN;W-P
M86-E9F]R=6Q<9F]R;7-H861E7&AO<GID;V-<9&=M87)G:6Y<9&=H<W!A8V4Q
M.#`-7&1G=G-P86-E,3@P7&1G:&]R:6=I;C$T-#!<9&=V;W)I9VEN,30T,%QD
M9VAS:&]W,5QD9W9S:&]W,5QJ97AP86YD7'9I97=K:6YD,5QV:65W<V-A;&4Q
M,#!<<&=B<F1R:&5A9%QP9V)R9')F;V]T7'-P;'ET=VYI;F5<9G1N;'ET=VYI
M;F5<:'1M875T<W!<;F]L;FAT861J=&)L7'5S96QT8F%L;EQA;&YT8FQI;F1<
M;'ET8V%L8W1B;'=D7&QY='1B;')T9W)<;&YB<FMR=6QE(%QF970P7'-E8W1D
M(`U<<'-Z,5QL:6YE>#!<96YD;FAE<F5<<V5C=&QI;F5G<FED,S8P7'-E8W1D
M969A=6QT8VP@>UQH96%D97(@7'!A<F1<<&QA:6X@7',R-EQW:61C=&QP87)<
M='%C7'1X-#,R,%QT<7)<='@X-C0P7&%S<&%L<&AA7&%S<&YU;5QF86%U=&]<
M861J=7-T<FEG:'1<<FEN,%QL:6XP7&ET87`P(%QF,5QL86YG,3`S,UQC9W)I
M9"![7&9S,C`@4&%G92!]>UQF:65L9'M<*EQF;&1I;G-T('M<9G,R,"`@4$%'
M12!]?7M<9FQD<G-L="![7&9S,C!<;&%N9S$P,C0@,WT-?7U[7&9S,C`@(&]F
M('U[7&9I96QD>UPJ7&9L9&EN<W0@>UQF<S(P("!.54U004=%4R!]?7M<9FQD
M<G-L="![7&9S,C!<;&%N9S$P,C0@,WU]?7M<9G,R,"!<=&%B(%QT86(@?7M<
M9FEE;&1[7"I<9FQD:6YS="![7&9S,C`@(%1)344@7%Q`(")-+V0O>7EY>2!H
M.FUM.G-S(&%M+W!M(B!]?7M<9FQD<G-L="![7&9S,C!<;&%N9S$P,C0@,2\S
M,2\R,#`T(#$Z,3,Z-#@@4$U]?7U[7&9S,C`@#5QP87(@?7U[7&9O;W1E<B!<
M<&%R9%QP;&%I;B!<<S(W7'=I9&-T;'!A<EQT<6-<='@T,S(P7'1Q<EQT>#@V
M-#!<87-P86QP:&%<87-P;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR:6XP7&QI
M;C!<:71A<#`@7&8Q7&QA;F<Q,#,S7&-G<FED('M<9G,R,"`-7'!A<B`-7'!A
M<B!]?7M<*EQP;G-E8VQV;#%<<&YU8W)M7'!N<W1A<G0Q7'!N:6YD96YT-S(P
M7'!N:&%N9WM<<&YT>'1A("Y]?7M<*EQP;G-E8VQV;#)<<&YU8VQT<EQP;G-T
M87)T,5QP;FEN9&5N=#<R,%QP;FAA;F=[7'!N='AT82`N?7U[7"I<<&YS96-L
M=FPS7'!N9&5C7'!N<W1A<G0Q7'!N:6YD96YT-S(P7'!N:&%N9WM<<&YT>'1A
M("Y]?7M<*EQP;G-E8VQV;#1<<&YL8VQT<EQP;G-T87)T,5QP;FEN9&5N=#<R
M,%QP;FAA;F=[7'!N='AT82`I?7T->UPJ7'!N<V5C;'9L-5QP;F1E8UQP;G-T
M87)T,5QP;FEN9&5N=#<R,%QP;FAA;F=[7'!N='AT8B`H?7M<<&YT>'1A("E]
M?7M<*EQP;G-E8VQV;#9<<&YL8VQT<EQP;G-T87)T,5QP;FEN9&5N=#<R,%QP
M;FAA;F=[7'!N='AT8B`H?7M<<&YT>'1A("E]?7M<*EQP;G-E8VQV;#=<<&YL
M8W)M7'!N<W1A<G0Q7'!N:6YD96YT-S(P7'!N:&%N9WM<<&YT>'1B("A]>UQP
M;G1X=&$@*7U]>UPJ7'!N<V5C;'9L.`U<<&YL8VQT<EQP;G-T87)T,5QP;FEN
M9&5N=#<R,%QP;FAA;F=[7'!N='AT8B`H?7M<<&YT>'1A("E]?7M<*EQP;G-E
M8VQV;#E<<&YL8W)M7'!N<W1A<G0Q7'!N:6YD96YT-S(P7'!N:&%N9WM<<&YT
M>'1B("A]>UQP;G1X=&$@*7U]7'!A<F1<<&QA:6X@7'=I9&-T;'!A<EQA<W!A
M;'!H85QA<W!N=6U<9F%A=71O7&%D:G5S=')I9VAT7')I;C!<;&EN,%QI=&%P
M,"!<9C%<;&%N9S$P,S-<8V=R:60@>PU<<&%R($$@<V5C;VYD(&UE=&AO9"!T
M;R!P97)F;W)M(&$@1$]3(&%T=&%C:R!I<R!A(&%T=&%C:R!A9V%I;G-T('1H
M92!796(@<V5R=F5R(&%N9"!T:&4@4TU44"!S97)V97(@*&]R(&%N>2!O=&AE
M<B!S97)V97(@>6]U(&UI9VAT(&9I;F0I+B`@270@:7,@86X@871T86-K($D@
M9&5V:7-E9"`H86YD($%&04E+(&ES(&%N(&]R:6=I;F%L(&%T=&%C:RD@22!C
M86QL(")4:&4@4F]S92!A='1A8VLB+B`@5&AI<R!A='1A8VL@:7,@82!C;VUB
M:6YA=&EO;B!O9B!T:`UE(%-93B!A='1A8VL@86YD('1H92`B56YK;F]W;B(@
M24--4"!A='1A8VL@:6X@=&AE($=#1E<@8V]U<G-E=V]R:RX@(%1H92!A='1A
M8VL@9&5P96YD<R!O;B!T:&4@(DUO<F4@1G)A9VUE;G1S(B!F;&%G(&%N9"!T
M:&4@9F%C="!T:&%T('1I;65O=71S(&]N('1I;64@97AC965D961?9G)A9VUE
M;G0@<F5A<W-E;6)L>2!F;W(@;6%N>2!M86-H:6YE<R!A<F4@870@;W(@86)O
M=F4@=&AE(#(@;6EN=71E(')A;F=E+B`@36EC<F]S;V9T(%=I;F1O=W,@,C`-
M,`TP(&ES(#(@;6EN=71E<RP@4W5N(%-O;&%R:7,@87!P96%R<R!T;R!B92!F
M;W5R(&UI;G5T97,@86YD($UA;F1R86ME($QI;G5X(&ES(#,P('-E8V]N9',N
M("!4:&4@9FER<W0@9G)A9VUE;G0@86YD('1H92!L87-T(&9R86=M96YT(&]F
M(")A('9E<GD@;&%R9V4@<&%C:V5T(B`H-C1K*2!I<R!S96YT+"!B=70@;F]T
M('1H92!M:61D;&4@9G)A9VUE;G1S+B`@5&AA="!F<F%G;65N="!B=69F97(@
M:6X@=&AE($E0('-T86-K(&ES(&AE;&0@;W!E;B!U;G0-:0UL('1H92!T:6UE
M<B!E>'!I<F5S+B`@26X@861D:71I;VX@:68@=&AE($E0('-T86-K(&ES(&YO
M="!P<F]G<F%M;65D(&-O<G)E8W1L>2!T:&ES(&UI9VAT(&%L<V\@<F5S=6QT
M(&EN(&$@8G5F9F5R(&]V97)F;&]W(&)E8V%U<V4@;V8@=&AE(&QA<F=E(&YU
M;6)E<B!O9B`B;&%R9V4B('!A8VME=',N("!7:&5N('1H92!N=6UB97(@;V8@
M9G)A9VUE;G0@8G5F9F5R<R!I<R!F:6QL960@;F\@;6]R92!F<F%G;65N=&5D
M('!A8VME=',@87)E(&%C8V5P=&4-9"X@(%=I=&@@5$-0(&%N9"!51%`@82!P
M;W)T(&1O97,@;F]T(&5V96X@:&%V92!T;R!B92!A(")O<&5N(B!P;W)T(&9O
M<B!T:&ES(&%T=&%C:R!T;R!S=6-C965D+@U<<&%R(`U<<&%R(%!E<B!T:&4@
M9&]C=6UE;G1A=&EO;B!A="!3=6X@<VET92!D;V-S+G-U;BYC;VTZ(%-O;&%R
M:7,@5'5N86)L92!087)A;65T97)S(%)E9F5R96YC92!-86YU86PL(#(P,#,N
M("!54DPZ('U[7&9I96QD>UPJ7&9L9&EN<W0@>R!(65!%4DQ)3DL@(FAT='`Z
M+R]D;V-S+G-U;BYC;VTO9&(O9&]C+S@Q-BTP-C`W+S9M-S,U<C5F;C]A/79I
M97<B('U[>UPJ7&1A=&%F:65L9"`-,#!D,&,Y96$W.68Y8F%C93$Q.&,X,C`P
M86$P,#1B83DP8C`R,#`P,#`P,3<P,#`P,#`S-3`P,#`P,#8X,#`W-#`P-S0P
M,#<P,#`S83`P,F8P,#)F,#`V-#`P-F8P,#8S,#`W,S`P,F4P,#<S,#`W-3`P
M-F4P,#)E,#`V,S`P-F8P,#9D,#`R9C`P-C0P,#8R,#`R9C`P-C0P,#9F,#`V
M,S`P,F8P,#,X,#`S,3`P,S8P,#)D,#`S,#`P,S8P,#,P,#`S-S`P,F8P,#,V
M,#`V9#`P,S<P,#,S,#`S-3`P-S(P,#,U,#`V-C`P-F4P,#-F,#`V,3`P,V0P
M,#<V,#`--CDP,#8U,#`W-S`P,#`P,&4P8SEE83<Y9CEB86-E,3$X8S@R,#!A
M83`P-&)A.3!B-F$P,#`P,#`V.#`P-S0P,#<T,#`W,#`P,V$P,#)F,#`R9C`P
M-C0P,#9F,#`V,S`P-S,P,#)E,#`W,S`P-S4P,#9E,#`R93`P-C,P,#9F,#`V
M9#`P,F8P,#8T,#`V,C`P,F8P,#8T,#`V9C`P-C,P,#)F,#`S.#`P,S$P,#,V
M,#`R9#`P,S`P,#,V,#`S,#`P,S<P,#)F,#`S-C`P-F0P,#,W,#`S,S`P,S4P
M,#<R,#`S-3`P-C8P,#9E,#`S9C`P-C$P,#-D,#`W-C`P-CD-,#`V-3`P-S<P
M,#`P,#!]?7U[7&9L9')S;'0@>UQC<S$U7'5L7&-F,B!H='1P.B\O9&]C<RYS
M=6XN8V]M+V1B+V1O8R\X,38M,#8P-R\V;3<S-7(U9FX_83UV:65W?7U]>PT@
M*$%C8V5S<V5D($1E8V5M8F5R(#(L(#(P,#,I+"!T:&4@5$-0($9R86=M96YT
M871I;VX@=&EM97(@=&-P7W1I;65?=V%I=%]I;G1E<G9A;"!I<R`T(&UI;G5T
M97,@86YD('1H92!N=6UB97(@;V8@8V]N;F5C=&EO;G,@<&5N9&EN9R!I<R!T
M8W!?8V]N;E]R97%?;6%X7W$@;V8@,3(X+B!F;W(@5410+"!S964@4V]L87)I
M<R!4=6YA8FQE(%!A<F%M971E<G,@4F5F97)E;F-E($UA;G5A;"P@,C`P,RX@
M(%523#H@?7M<9FEE;&1[7"I<9FQD:6YS="![#2!(65!%4DQ)3DL@(FAT='`Z
M+R]D;V-S+G-U;BYC;VTO9&(O9&]C+S@Q-BTP-C`W+S9M-S,U<C5F;S]A/79I
M97<B('U[>UPJ7&1A=&%F:65L9"`-,#!D,&,Y96$W.68Y8F%C93$Q.&,X,C`P
M86$P,#1B83DP8C`R,#`P,#`P,3<P,#`P,#`S-3`P,#`P,#8X,#`W-#`P-S0P
M,#<P,#`S83`P,F8P,#)F,#`V-#`P-F8P,#8S,#`W,S`P,F4P,#<S,#`W-3`P
M-F4P,#)E,#`V,S`P-F8P,#9D,#`R9C`P-C0P,#8R,#`R9C`P-C0P,#9F,#`V
M,S`P,F8P,#,X,#`S,3`P,S8P,#)D,#`S,#`P,S8P,#,P,#`S-S`P,F8P,#,V
M,#`V9#`P,S<P,#,S,#`S-3`P-S(P,#,U,#`V-C`P-F8P,#-F,#`V,3`P,V0P
M,#<V,#`--CDP,#8U,#`W-S`P,#`P,&4P8SEE83<Y9CEB86-E,3$X8S@R,#!A
M83`P-&)A.3!B-F$P,#`P,#`V.#`P-S0P,#<T,#`W,#`P,V$P,#)F,#`R9C`P
M-C0P,#9F,#`V,S`P-S,P,#)E,#`W,S`P-S4P,#9E,#`R93`P-C,P,#9F,#`V
M9#`P,F8P,#8T,#`V,C`P,F8P,#8T,#`V9C`P-C,P,#)F,#`S.#`P,S$P,#,V
M,#`R9#`P,S`P,#,V,#`S,#`P,S<P,#)F,#`S-C`P-F0P,#,W,#`S,S`P,S4P
M,#<R,#`S-3`P-C8P,#9F,#`S9C`P-C$P,#-D,#`W-C`P-CD-,#`V-3`P-S<P
M,#`P,#!]?7U[7&9L9')S;'0@>UQC<S$U7'5L7&-F,B!H='1P.B\O9&]C<RYS
M=6XN8V]M+V1B+V1O8R\X,38M,#8P-R\V;3<S-7(U9F\_83UV:65W?7U]>R`H
M06-C97-S960@1&5C96UB97(@,BP@,C`P,RDN("!7:&EL92!T:&ES(&EN9F]R
M;6%T:6]N(&ES(&YO="!O;B!T:&4@5410+"!I="!I<R!A<W-U;65D('1H870@
M=&AE(&YU;6)E<G,@87)E('1H92!S86UE(&%S('1H92!40U`@<&%R86UE=&5R
M<RX-7'!A<B`-7'!A<B!/;B!A(%=I;F1O=W,@,C`P,"!M86-H:6YE('=I=&@@
M82!R96QA=&EV96QY('-M86QL(&YU;6)E<B`H86)O=70@,34P*2!P86-K971S
M+"!T:&4@86)I;&ET>2!F;W(@=&AE($E0('-T86-K('1O(&%C8V5P="!F<F%G
M;65N=&5D('!A8VME=',@=V%S(&1I<V%B;&5D(&9O<B`R(&UI;G5T97,N("!7
M:71H(&$@3&EN=7@@8F]X(&%T(#<X,"!P86-K971S('!E<B!S96-O;F0-("AU
M<VEN9R!T:&4@8F5L;W<@=&5S="D@;6EX960@<F5S=6QT<R!W97)E(&]B=&%I
M;F5D('=I=&@@<V]M92!F<F%G;65N=&5D('!I;F<@<&%C:V5T<R!F86EL:6YG
M(&%N9"!S;VUE(')E='5R;F5D(&%N9"!H:6=H($-052!U=&EL:7IA=&EO;BP@
M8G5T('1H92!,:6YU>"!B;W@@<F5T=7)N960@=&\@;F]R;6%L(&%S('-O;VX@
M87,@=&AE(&9L;V]D('-T;W!P960N("!4:&4@<V%M92!T97-T("@W.#`@4%!3
M*2!P<F]V960@=&\@:&%V92!M:7AE9"!R97-U#6P-=',@=VET:"!A($-I<V-O
M(#(V,C%832!R;W5T97(L('=I=&@@-3`@=&\@.3`E($-052!U=&EL:7IA=&EO
M;B!A;F0@=&AE('!I;F=S(')E='5R;F5D('1O(&YO<FUA;"!A<R!S;V]N(&%S
M('1H92!P:6YG(&9L;V]D('-T;W!P960N("!!(%-O;&%R:7,@.2!M86-H:6YE
M('=A<R!U;F%V86EL86)L92!F;W(@=&5S=&EN9R!S;R!T:&4@8F5L;W<@871T
M86-K(&-O=6QD(&YO="!B92!T97-T960@;VX@=&AA="!O<&5R871I;F<@<WES
M=&5M+B`@07,@82!S:61E#2!N;W1E('1H:7,@871T86-K(&-O=6QD(&%L<V\@
M8F4@=7-E9"!F;W(@3U,@9FEN9V5R<')I;G1I;F<N("!7:6YD;W=S('-E;F1S
M(&)A8VL@(D9R86=M96YT871I;VX@=&EM92!E>&-E961E9"(@9F]R(&%L;"!P
M86-K971S+B`@3&EN=7@@<V5N9',@8F%C:R`B1G)A9VUE;G1A=&EO;B!T:6UE
M(&5X8V5E9&5D(B!F;W(@:G5S="!T:&4@24--4"!P86-K971S(&%N9"!#:7-C
M;R!R;W5T97(@;F]N92!A="!A;&PN#5QP87(@#5QP87(@1FER<W0@86X@97AC
M96P@<W!R96%D<VAE970@:7,@8W)E871E9"!F;W(@<F%N9&]M(&%D9')E<W-E
M<RP@<&]R=',L('-E<75E;F-E(&YU;6)E<G,L(&5T8RX@($EF+"!F;W(@97AA
M;7!L92P@<&]R="`X,"`H2%144"D@;VX@82!S<&5C:69I8R!M86-H:6YE(&ES
M(&%T=&%C:V5D('1H96X@65D@*'-E92!B96QO=RD@=V]U;&0@8F4@82!S=&%T
M:6,@96YT<GD@;V8@.#`N("!4:&4@9F]R;6%T(&]F(&5A8V@@<&%C:V5T(&QO
M;VMS(&QI:V4Z#5QP87(@24--4"!F:7)S="!F<F%G;65N="!A;F0@3&%S="!&
M<F%G;65N=#H-7'!A<B!]>UQF,EQF<S(P(&YE;65S:7,@:6-M<"`M4R!75RY6
M5BY65BY65B`M1"`Q.3<N,"XP+C$R("UD,2`M:2`X("U)($E)("U0(%!I8VUP
M9&%T82YT>'0@+49-,`U<<&%R(&YE;65S:7,@:6-M<"`M4R!75RY65BY65BY6
M5B`M1"`Q.3<N,"XP+C$R("UD,2`M:2`X("U)($E)("U0(%!I8VUP9&%T82YT
M>'0@+48X,3`P#5QP87(@?7M40U`@9FER<W0@9G)A9VUE;G0@86YD(&QA<W0@
M9G)A9VUE;G0Z#5QP87(@?7M<9C)<9G,R,"!N96UE<VES('1C<"`M4R!75RY6
M5BY65BY65B`M1"`Q.3<N,"XP+C$R("UD,2`M22!)22`M<R!34R`M82!!02![
M7"I<8FMM:W-T87)T($],15],24Y+,GTM>"!86"`M>2!967M<*EQB:VUK96YD
M($],15],24Y+,GT@+5`@4'1C<&1A=&$N='AT("U&33`-7'!A<B!N96UE<VES
M('1C<"`M4R!75RY65BY65BY65B`M1"`Q.3<N,"XP+C$R("UD,2`M22!)22`M
M<R!34R`M82!!02`M>"!86"`M>2!962`M4"!0=&-P9&%T82YT>'0@7&5N9&%S
M:"!&33@Q,#`-7'!A<B!]>U5$4"!F:7)S="!F<F%G;65N="!A;F0@;&%S="!F
M<F%G;65N=#H-7'!A<B!]>UQF,EQF<S(P(&YE;65S:7,@=61P("U3(%=7+E96
M+E96+E96("U$(#$Y-RXP+C`N,3(@+60Q("U)($E)("UX(%A8("UY(%E9("U0
M(%!U9'!D871A+G1X="`M1DTP#5QP87(@;F5M97-I<R!U9'`@+5,@5U<N5E8N
M5E8N5E8@+40@,3DW+C`N,"XQ,B`M9#$@+4D@24D@+7@@6%@@+7D@65D@+5`@
M4'5D<&1A=&$N='AT("U&33`-7'!A<B!]7'!A<F1<<&QA:6X@7',Q-UQW:61C
M=&QP87)<87-P86QP:&%<87-P;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR:6XP
M7&QI;C!<:71A<#`@7&8Q7&QA;F<Q,#,S7&-G<FED('L-7'!A<B!]7'!A<F1<
M<&QA:6X@7'=I9&-T;'!A<EQA<W!A;'!H85QA<W!N=6U<9F%A=71O7&%D:G5S
M=')I9VAT7')I;C!<;&EN,%QI=&%P,"!<9C%<;&%N9S$P,S-<8V=R:60@>U=H
M97)E.@U<<&%R('U<=')O=V0@7'1R9V%P:#$P.%QT<FQE9G0M,3`X7'1R8G)D
M<G1<8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R;%QB<F1R:&%I<EQB<F1R=S$P
M(%QT<F)R9')B7&)R9')H86ER7&)R9')W,3`@7'1R8G)D<G)<8G)D<FAA:7)<
M8G)D<G<Q,"!<=')B<F1R:%QB<F1R:&%I<EQB<F1R=S$P(%QT<F)R9')V7&)R
M9')H86ER7&)R9')W,3`@#5QT<F9T<U=I9'1H,UQT<G=7:61T:#DT-CA<=')F
M='-7:61T:$(S7'1R9G1S5VED=&A!,UQT<G!A9&1L,3`X7'1R<&%D9'(Q,#A<
M=')P861D9FPS7'1R<&%D9&9R,R!<8VQV97)T86QT7&-L8G)D<G1<8G)D<FAA
M:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B
M7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"!<
M8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW5VED=&@Q-30X(%QC96QL>#$T-#`-
M7&-L=F5R=&%L=%QC;&)R9')T7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<FQ<
M8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC
M;&)R9')R7&)R9')H86ER7&)R9')W,3`@7&-L='AL<G1B7&-L9G1S5VED=&@S
M7&-L=U=I9'1H,3@P,"!<8V5L;'@S,C0P7&-L=F5R=&%L=%QC;&)R9')T7&)R
M9')H86ER7&)R9')W,3`@7&-L8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB
M<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')R#5QB<F1R:&%I<EQB<F1R
M=S$P(%QC;'1X;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#(W,#`@7&-E;&QX
M-3DT,%QC;'9E<G1A;'1<8VQB<F1R=%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R
M9')L7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<F)<8G)D<FAA:7)<8G)D<G<Q
M,"!<8VQB<F1R<EQB<F1R:&%I<EQB<F1R=S$P(%QC;'1X;')T8EQC;&9T<U=I
M9'1H,UQC;'=7:61T:#$P.#`@7&-E;&QX-S`R,%QC;'9E<G1A;'1<8VQB<F1R
M=`U<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P
M(%QC;&)R9')B7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<
M8G)D<G<Q,"!<8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW5VED=&@R,S0P(%QC
M96QL>#DS-C!<<&%R9"!<=VED8W1L<&%R7&EN=&)L7&%S<&%L<&AA7&%S<&YU
M;5QF86%U=&]<861J=7-T<FEG:'1<<FEN,%QL:6XP('M<9C)<9G,R,"!687)<
M8V5L;"!286YG95QC96QL($9O<FUU;&%<8V5L;"`-2&5A9&5R7&-E;&P@1&5S
M8W)I<'1I;VY<8V5L;"!]7'!A<F0@7'=I9&-T;'!A<EQI;G1B;%QA<W!A;'!H
M85QA<W!N=6U<9F%A=71O7&%D:G5S=')I9VAT7')I;C!<;&EN,"![7&8R7&9S
M,C`@7'1R;W=D(%QT<F=A<&@Q,#A<=')L969T+3$P.%QT<F)R9')T7&)R9')H
M86ER7&)R9')W,3`@7'1R8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R
M8EQB<F1R:&%I<EQB<F1R=S$P(%QT<F)R9')R7&)R9')H86ER7&)R9')W,3`@
M7'1R8G)D<F@-7&)R9')H86ER7&)R9')W,3`@7'1R8G)D<G9<8G)D<FAA:7)<
M8G)D<G<Q,"!<=')F='-7:61T:#-<=')W5VED=&@Y-#8X7'1R9G1S5VED=&A"
M,UQT<F9T<U=I9'1H03-<=')P861D;#$P.%QT<G!A9&1R,3`X7'1R<&%D9&9L
M,UQT<G!A9&1F<C,@7&-L=F5R=&%L=%QC;&)R9')T7&)R9')H86ER7&)R9')W
M,3`@7&-L8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I
M<EQB<F1R=S$P(%QC;&)R9')R7&)R9')H86ER7&)R9')W,3`@#5QC;'1X;')T
M8EQC;&9T<U=I9'1H,UQC;'=7:61T:#$U-#@@7&-E;&QX,30T,%QC;'9E<G1A
M;'1<8VQB<F1R=%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')L7&)R9')H86ER
M7&)R9')W,3`@7&-L8G)D<F)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R<EQB
M<F1R:&%I<EQB<F1R=S$P(%QC;'1X;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T
M:#$X,#`@7&-E;&QX,S(T,%QC;'9E<G1A;'1<8VQB<F1R=%QB<F1R:&%I<EQB
M<F1R=S$P(%QC;&)R9')L#5QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B7&)R
M9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQT
M>&QR=&)<8VQF='-7:61T:#-<8VQW5VED=&@R-S`P(%QC96QL>#4Y-#!<8VQV
M97)T86QT7&-L8G)D<G1<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R
M:&%I<EQB<F1R=S$P(%QC;&)R9')B7&)R9')H86ER7&)R9')W,3`@7&-L8G)D
M<G)<8G)D<FAA:7)<8G)D<G<Q,"`-7&-L='AL<G1B7&-L9G1S5VED=&@S7&-L
M=U=I9'1H,3`X,"!<8V5L;'@W,#(P7&-L=F5R=&%L=%QC;&)R9')T7&)R9')H
M86ER7&)R9')W,3`@7&-L8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R
M8EQB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')R7&)R9')H86ER7&)R9')W,3`@
M7&-L='AL<G1B7&-L9G1S5VED=&@S7&-L=U=I9'1H,C,T,"!<8V5L;'@Y,S8P
M7')O=R!]7'1R;W=D(%QT<F=A<&@Q,#A<=')L969T+3$P.%QT<F)R9')T#5QB
M<F1R:&%I<EQB<F1R=S$P(%QT<F)R9')L7&)R9')H86ER7&)R9')W,3`@7'1R
M8G)D<F)<8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R<EQB<F1R:&%I<EQB<F1R
M=S$P(%QT<F)R9')H7&)R9')H86ER7&)R9')W,3`@7'1R8G)D<G9<8G)D<FAA
M:7)<8G)D<G<Q,"!<=')F='-7:61T:#-<=')W5VED=&@Y-#8X7'1R9G1S5VED
M=&A",UQT<F9T<U=I9'1H03-<=')P861D;#$P.%QT<G!A9&1R,3`X7'1R<&%D
M9&9L,UQT<G!A9&1F<C,@7&-L=F5R=&%L=`U<8VQB<F1R=%QB<F1R:&%I<EQB
M<F1R=S$P(%QC;&)R9')L7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<F)<8G)D
M<FAA:7)<8G)D<G<Q,"!<8VQB<F1R<EQB<F1R:&%I<EQB<F1R=S$P(%QC;'1X
M;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#$U-#@@7&-E;&QX,30T,%QC;'9E
M<G1A;'1<8VQB<F1R=%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')L7&)R9')H
M86ER7&)R9')W,3`@7&-L8G)D<F)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R
M<@U<8G)D<FAA:7)<8G)D<G<Q,"!<8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW
M5VED=&@Q.#`P(%QC96QL>#,R-#!<8VQV97)T86QT7&-L8G)D<G1<8G)D<FAA
M:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B
M7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"!<
M8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW5VED=&@R-S`P(%QC96QL>#4Y-#!<
M8VQV97)T86QT7&-L8G)D<G0-7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<FQ<
M8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC
M;&)R9')R7&)R9')H86ER7&)R9')W,3`@7&-L='AL<G1B7&-L9G1S5VED=&@S
M7&-L=U=I9'1H,3`X,"!<8V5L;'@W,#(P7&-L=F5R=&%L=%QC;&)R9')T7&)R
M9')H86ER7&)R9')W,3`@7&-L8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB
M<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')R7&)R9')H86ER7&)R9')W
M,3`@#5QC;'1X;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#(S-#`@7&-E;&QX
M.3,V,%QP87)D(%QW:61C=&QP87)<:6YT8FQ<87-P86QP:&%<87-P;G5M7&9A
M875T;UQA9&IU<W1R:6=H=%QR:6XP7&QI;C`@>UQF,EQF<S(P(%=77&-E;&P@
M,3$@7&5N9&%S:"`@,3<Q7&-E;&P@/4E.5"A204Y$*"DJ,38R*2LQ,5QC96QL
M($E07&-E;&P@5&AE(&9I<G-T(&]C=&5T(&]F('1H92`B<F%N9&]M(B!)4"!A
M9&1R97-S7&-E;&P@?5QP87)D(`U<=VED8W1L<&%R7&EN=&)L7&%S<&%L<&AA
M7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<<FEN,%QL:6XP('M<9C)<9G,R
M,"!<=')O=V0@7'1R9V%P:#$P.%QT<FQE9G0M,3`X7'1R8G)D<G1<8G)D<FAA
M:7)<8G)D<G<Q,"!<=')B<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QT<F)R9')B
M7&)R9')H86ER7&)R9')W,3`@7'1R8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"!<
M=')B<F1R:%QB<F1R:&%I<EQB<F1R=S$P(%QT<F)R9')V#5QB<F1R:&%I<EQB
M<F1R=S$P(%QT<F9T<U=I9'1H,UQT<G=7:61T:#DT-CA<=')F='-7:61T:$(S
M7'1R9G1S5VED=&A!,UQT<G!A9&1L,3`X7'1R<&%D9'(Q,#A<=')P861D9FPS
M7'1R<&%D9&9R,R!<8VQV97)T86QT7&-L8G)D<G1<8G)D<FAA:7)<8G)D<G<Q
M,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B7&)R9')H86ER
M7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"`-7&-L='AL<G1B
M7&-L9G1S5VED=&@S7&-L=U=I9'1H,34T."!<8V5L;'@Q-#0P7&-L=F5R=&%L
M=%QC;&)R9')T7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<FQ<8G)D<FAA:7)<
M8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')R7&)R
M9')H86ER7&)R9')W,3`@7&-L='AL<G1B7&-L9G1S5VED=&@S7&-L=U=I9'1H
M,3@P,"!<8V5L;'@S,C0P7&-L=F5R=&%L=%QC;&)R9')T7&)R9')H86ER7&)R
M9')W,3`@7&-L8G)D<FP-7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<F)<8G)D
M<FAA:7)<8G)D<G<Q,"!<8VQB<F1R<EQB<F1R:&%I<EQB<F1R=S$P(%QC;'1X
M;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#(W,#`@7&-E;&QX-3DT,%QC;'9E
M<G1A;'1<8VQB<F1R=%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')L7&)R9')H
M86ER7&)R9')W,3`@7&-L8G)D<F)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R
M<EQB<F1R:&%I<EQB<F1R=S$P(`U<8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW
M5VED=&@Q,#@P(%QC96QL>#<P,C!<8VQV97)T86QT7&-L8G)D<G1<8G)D<FAA
M:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B
M7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"!<
M8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW5VED=&@R,S0P(%QC96QL>#DS-C!<
M<F]W('U<<&%R9"`-7'=I9&-T;'!A<EQI;G1B;%QA<W!A;'!H85QA<W!N=6U<
M9F%A=71O7&%D:G5S=')I9VAT7')I;C!<;&EN,"![7&8R7&9S,C`@5E9<8V5L
M;"`Q(%QE;F1A<V@@(#(U-%QC96QL(#U)3E0H4D%.1"@I*C(U-"DK,5QC96QL
M($E07&-E;&P@5&AE('-E8V]N9"P@=&AI<F0@86YD(&9O=7)T:"!O8W1E="!O
M9B!T:&4@(G)A;F1O;2(@25`@861D<F5S<UQC96QL('U<<&%R9"`-7'=I9&-T
M;'!A<EQI;G1B;%QA<W!A;'!H85QA<W!N=6U<9F%A=71O7&%D:G5S=')I9VAT
M7')I;C!<;&EN,"![7&8R7&9S,C`@7'1R;W=D(%QT<F=A<&@Q,#A<=')L969T
M+3$P.%QT<F)R9')T7&)R9')H86ER7&)R9')W,3`@7'1R8G)D<FQ<8G)D<FAA
M:7)<8G)D<G<Q,"!<=')B<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QT<F)R9')R
M7&)R9')H86ER7&)R9')W,3`@7'1R8G)D<FA<8G)D<FAA:7)<8G)D<G<Q,"!<
M=')B<F1R=@U<8G)D<FAA:7)<8G)D<G<Q,"!<=')F='-7:61T:#-<=')W5VED
M=&@Y-#8X7'1R9G1S5VED=&A",UQT<F9T<U=I9'1H03-<=')P861D;#$P.%QT
M<G!A9&1R,3`X7'1R<&%D9&9L,UQT<G!A9&1F<C,@7&-L=F5R=&%L=%QC;&)R
M9')T7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q
M,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')R7&)R9')H86ER
M7&)R9')W,3`@#5QC;'1X;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#$U-#@@
M7&-E;&QX,30T,%QC;'9E<G1A;'1<8VQB<F1R=%QB<F1R:&%I<EQB<F1R=S$P
M(%QC;&)R9')L7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<F)<8G)D<FAA:7)<
M8G)D<G<Q,"!<8VQB<F1R<EQB<F1R:&%I<EQB<F1R=S$P(%QC;'1X;')T8EQC
M;&9T<U=I9'1H,UQC;'=7:61T:#$X,#`@7&-E;&QX,S(T,%QC;'9E<G1A;'1<
M8VQB<F1R=%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')L#5QB<F1R:&%I<EQB
M<F1R=S$P(%QC;&)R9')B7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D
M<FAA:7)<8G)D<G<Q,"!<8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW5VED=&@R
M-S`P(%QC96QL>#4Y-#!<8VQV97)T86QT7&-L8G)D<G1<8G)D<FAA:7)<8G)D
M<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B7&)R9')H
M86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"`-7&-L='AL
M<G1B7&-L9G1S5VED=&@S7&-L=U=I9'1H,3`X,"!<8V5L;'@W,#(P7&-L=F5R
M=&%L=%QC;&)R9')T7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<FQ<8G)D<FAA
M:7)<8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')R
M7&)R9')H86ER7&)R9')W,3`@7&-L='AL<G1B7&-L9G1S5VED=&@S7&-L=U=I
M9'1H,C,T,"!<8V5L;'@Y,S8P7')O=R!]7'!A<F0@#5QW:61C=&QP87)<:6YT
M8FQ<87-P86QP:&%<87-P;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR:6XP7&QI
M;C`@>UQF,EQF<S(P($E)7&-E;&P@,2TV-6M<8V5L;"`]24Y4*%)!3D0H*2HV
M-34S,"DK,5QC96QL($E07&-E;&P@25`@261E;G1I9FEC871I;VX@3G5M8F5R
M7&-E;&P@?5QP87)D(%QW:61C=&QP87)<:6YT8FQ<87-P86QP:&%<87-P;G5M
M7&9A875T;UQA9&IU<W1R:6=H=%QR:6XP7&QI;C`@>UQF,EQF<S(P(%QT<F]W
M9"`-7'1R9V%P:#$P.%QT<FQE9G0M,3`X7'1R8G)D<G1<8G)D<FAA:7)<8G)D
M<G<Q,"!<=')B<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QT<F)R9')B7&)R9')H
M86ER7&)R9')W,3`@7'1R8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R
M:%QB<F1R:&%I<EQB<F1R=S$P(%QT<F)R9')V7&)R9')H86ER7&)R9')W,3`@
M#5QT<F9T<U=I9'1H,UQT<G=7:61T:#DT-CA<=')F='-7:61T:$(S7'1R9G1S
M5VED=&A!,UQT<G!A9&1L,3`X7'1R<&%D9'(Q,#A<=')P861D9FPS7'1R<&%D
M9&9R,R!<8VQV97)T86QT7&-L8G)D<G1<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB
M<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B7&)R9')H86ER7&)R9')W
M,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQT>&QR=&)<8VQF='-7
M:61T:#-<8VQW5VED=&@Q-30X(%QC96QL>#$T-#`-7&-L=F5R=&%L=%QC;&)R
M9')T7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q
M,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')R7&)R9')H86ER
M7&)R9')W,3`@7&-L='AL<G1B7&-L9G1S5VED=&@S7&-L=U=I9'1H,3@P,"!<
M8V5L;'@S,C0P7&-L=F5R=&%L=%QC;&)R9')T7&)R9')H86ER7&)R9')W,3`@
M7&-L8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB
M<F1R=S$P(%QC;&)R9')R#5QB<F1R:&%I<EQB<F1R=S$P(%QC;'1X;')T8EQC
M;&9T<U=I9'1H,UQC;'=7:61T:#(W,#`@7&-E;&QX-3DT,%QC;'9E<G1A;'1<
M8VQB<F1R=%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')L7&)R9')H86ER7&)R
M9')W,3`@7&-L8G)D<F)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R<EQB<F1R
M:&%I<EQB<F1R=S$P(%QC;'1X;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#$P
M.#`@7&-E;&QX-S`R,%QC;'9E<G1A;'1<8VQB<F1R=`U<8G)D<FAA:7)<8G)D
M<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B7&)R9')H
M86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQT>&QR
M=&)<8VQF='-7:61T:#-<8VQW5VED=&@R,S0P(%QC96QL>#DS-C!<<F]W('U<
M<&%R9"!<=VED8W1L<&%R7&EN=&)L7&%S<&%L<&AA7&%S<&YU;5QF86%U=&]<
M861J=7-T<FEG:'1<<FEN,%QL:6XP('M<9C)<9G,R,"`Q.3<N,"XP+C$R7&-E
M;&P@4W1A=&EC7&-E;&P@#5-T871I8UQC96QL($E07&-E;&P@1&5S=&EN871I
M;VX@25`@861D<F5S<UQC96QL('U<<&%R9"!<=VED8W1L<&%R7&EN=&)L7&%S
M<&%L<&AA7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<<FEN,%QL:6XP('M<
M9C)<9G,R,"!<=')O=V0@7'1R9V%P:#$P.%QT<FQE9G0M,3`X7'1R8G)D<G1<
M8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QT
M<F)R9')B7&)R9')H86ER7&)R9')W,3`@7'1R8G)D<G(-7&)R9')H86ER7&)R
M9')W,3`@7'1R8G)D<FA<8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R=EQB<F1R
M:&%I<EQB<F1R=S$P(%QT<F9T<U=I9'1H,UQT<G=7:61T:#DT-CA<=')F='-7
M:61T:$(S7'1R9G1S5VED=&A!,UQT<G!A9&1L,3`X7'1R<&%D9'(Q,#A<=')P
M861D9FPS7'1R<&%D9&9R,R!<8VQV97)T86QT7&-L8G)D<G1<8G)D<FAA:7)<
M8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B7&)R
M9')H86ER7&)R9')W,3`@#5QC;&)R9')R7&)R9')H86ER7&)R9')W,3`@7&-L
M='AL<G1B7&-L9G1S5VED=&@S7&-L=U=I9'1H,34T."!<8V5L;'@Q-#0P7&-L
M=F5R=&%L=%QC;&)R9')T7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<FQ<8G)D
M<FAA:7)<8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC;&)R
M9')R7&)R9')H86ER7&)R9')W,3`@7&-L='AL<G1B7&-L9G1S5VED=&@S7&-L
M=U=I9'1H,3@P,"!<8V5L;'@S,C0P7&-L=F5R=&%L=%QC;&)R9')T#5QB<F1R
M:&%I<EQB<F1R=S$P(%QC;&)R9')L7&)R9')H86ER7&)R9')W,3`@7&-L8G)D
M<F)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R<EQB<F1R:&%I<EQB<F1R=S$P
M(%QC;'1X;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#(W,#`@7&-E;&QX-3DT
M,%QC;'9E<G1A;'1<8VQB<F1R=%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')L
M7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<F)<8G)D<FAA:7)<8G)D<G<Q,"!<
M8VQB<F1R<EQB<F1R:&%I<EQB<F1R=S$P(`U<8VQT>&QR=&)<8VQF='-7:61T
M:#-<8VQW5VED=&@Q,#@P(%QC96QL>#<P,C!<8VQV97)T86QT7&-L8G)D<G1<
M8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC
M;&)R9')B7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D
M<G<Q,"!<8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW5VED=&@R,S0P(%QC96QL
M>#DS-C!<<F]W('U<<&%R9"`-7'=I9&-T;'!A<EQI;G1B;%QA<W!A;'!H85QA
M<W!N=6U<9F%A=71O7&%D:G5S=')I9VAT7')I;C!<;&EN,"![7&8R7&9S,C`@
M+60Q7&-E;&P@7&-E;&P@7&-E;&P@7&-E;&P@4V5N9"!P86-K970@;W5T($5T
M:&5R;F5T(#$@8V%R9%QC96QL('U<<&%R9"!<=VED8W1L<&%R7&EN=&)L7&%S
M<&%L<&AA7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<<FEN,%QL:6XP('M<
M9C)<9G,R,"!<=')O=V0@7'1R9V%P:#$P.%QT<FQE9G0M,3`X7'1R8G)D<G0-
M7&)R9')H86ER7&)R9')W,3`@7'1R8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<
M=')B<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QT<F)R9')R7&)R9')H86ER7&)R
M9')W,3`@7'1R8G)D<FA<8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R=EQB<F1R
M:&%I<EQB<F1R=S$P(%QT<F9T<U=I9'1H,UQT<G=7:61T:#DT-CA<=')F='-7
M:61T:$(S7'1R9G1S5VED=&A!,UQT<G!A9&1L,3`X7'1R<&%D9'(Q,#A<=')P
M861D9FPS7'1R<&%D9&9R,R!<8VQV97)T86QT#5QC;&)R9')T7&)R9')H86ER
M7&)R9')W,3`@7&-L8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R8EQB
M<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')R7&)R9')H86ER7&)R9')W,3`@7&-L
M='AL<G1B7&-L9G1S5VED=&@S7&-L=U=I9'1H,34T."!<8V5L;'@Q-#0P7&-L
M=F5R=&%L=%QC;&)R9')T7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<FQ<8G)D
M<FAA:7)<8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC;&)R
M9')R#5QB<F1R:&%I<EQB<F1R=S$P(%QC;'1X;')T8EQC;&9T<U=I9'1H,UQC
M;'=7:61T:#$X,#`@7&-E;&QX,S(T,%QC;'9E<G1A;'1<8VQB<F1R=%QB<F1R
M:&%I<EQB<F1R=S$P(%QC;&)R9')L7&)R9')H86ER7&)R9')W,3`@7&-L8G)D
M<F)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R<EQB<F1R:&%I<EQB<F1R=S$P
M(%QC;'1X;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#(W,#`@7&-E;&QX-3DT
M,%QC;'9E<G1A;'1<8VQB<F1R=`U<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R
M;%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B7&)R9')H86ER7&)R9')W,3`@
M7&-L8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQT>&QR=&)<8VQF='-7:61T
M:#-<8VQW5VED=&@Q,#@P(%QC96QL>#<P,C!<8VQV97)T86QT7&-L8G)D<G1<
M8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC
M;&)R9')B7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D
M<G<Q,"`-7&-L='AL<G1B7&-L9G1S5VED=&@S7&-L=U=I9'1H,C,T,"!<8V5L
M;'@Y,S8P7')O=R!]7'!A<F0@7'=I9&-T;'!A<EQI;G1B;%QA<W!A;'!H85QA
M<W!N=6U<9F%A=71O7&%D:G5S=')I9VAT7')I;C!<;&EN,"![7&8R7&9S,C`@
M4U-<8V5L;"`Q+2`T,CDT.38W,CDU7&-E;&P@/4E.5"A204Y$*"DJ-#(Y-#DV
M-S(Y-2DK,5QC96QL(%1#4%QC96QL(%-E<75E;F-E($YU;6)E<EQC96QL('U<
M<&%R9"`-7'=I9&-T;'!A<EQI;G1B;%QA<W!A;'!H85QA<W!N=6U<9F%A=71O
M7&%D:G5S=')I9VAT7')I;C!<;&EN,"![7&8R7&9S,C`@7'1R;W=D(%QT<F=A
M<&@Q,#A<=')L969T+3$P.%QT<F)R9')T7&)R9')H86ER7&)R9')W,3`@7'1R
M8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R8EQB<F1R:&%I<EQB<F1R
M=S$P(%QT<F)R9')R7&)R9')H86ER7&)R9')W,3`@7'1R8G)D<FA<8G)D<FAA
M:7)<8G)D<G<Q,"!<=')B<F1R=@U<8G)D<FAA:7)<8G)D<G<Q,"!<=')F='-7
M:61T:#-<=')W5VED=&@Y-#8X7'1R9G1S5VED=&A",UQT<F9T<U=I9'1H03-<
M=')P861D;#$P.%QT<G!A9&1R,3`X7'1R<&%D9&9L,UQT<G!A9&1F<C,@7&-L
M=F5R=&%L=%QC;&)R9')T7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<FQ<8G)D
M<FAA:7)<8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC;&)R
M9')R7&)R9')H86ER7&)R9')W,3`@#5QC;'1X;')T8EQC;&9T<U=I9'1H,UQC
M;'=7:61T:#$U-#@@7&-E;&QX,30T,%QC;'9E<G1A;'1<8VQB<F1R=%QB<F1R
M:&%I<EQB<F1R=S$P(%QC;&)R9')L7&)R9')H86ER7&)R9')W,3`@7&-L8G)D
M<F)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R<EQB<F1R:&%I<EQB<F1R=S$P
M(%QC;'1X;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#$X,#`@7&-E;&QX,S(T
M,%QC;'9E<G1A;'1<8VQB<F1R=%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')L
M#5QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B7&)R9')H86ER7&)R9')W,3`@
M7&-L8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQT>&QR=&)<8VQF='-7:61T
M:#-<8VQW5VED=&@R-S`P(%QC96QL>#4Y-#!<8VQV97)T86QT7&-L8G)D<G1<
M8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC
M;&)R9')B7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D
M<G<Q,"`-7&-L='AL<G1B7&-L9G1S5VED=&@S7&-L=U=I9'1H,3`X,"!<8V5L
M;'@W,#(P7&-L=F5R=&%L=%QC;&)R9')T7&)R9')H86ER7&)R9')W,3`@7&-L
M8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R
M=S$P(%QC;&)R9')R7&)R9')H86ER7&)R9')W,3`@7&-L='AL<G1B7&-L9G1S
M5VED=&@S7&-L=U=I9'1H,C,T,"!<8V5L;'@Y,S8P7')O=R!]7'!A<F0@#5QW
M:61C=&QP87)<:6YT8FQ<87-P86QP:&%<87-P;G5M7&9A875T;UQA9&IU<W1R
M:6=H=%QR:6XP7&QI;C`@>UQF,EQF<S(P($%!7&-E;&P@,2T@-#(Y-#DV-S(Y
M-5QC96QL(#U)3E0H4D%.1"@I*C0R.30Y-C<R.34I*S%<8V5L;"!40U!<8V5L
M;"!!8VMN;W=L961G96UE;G0@3G5M8F5R7&-E;&P@?5QP87)D(%QW:61C=&QP
M87)<:6YT8FQ<87-P86QP:&%<87-P;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR
M:6XP7&QI;C`@>UQF,EQF<S(P(%QT<F]W9"`-7'1R9V%P:#$P.%QT<FQE9G0M
M,3`X7'1R8G)D<G1<8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R;%QB<F1R:&%I
M<EQB<F1R=S$P(%QT<F)R9')B7&)R9')H86ER7&)R9')W,3`@7'1R8G)D<G)<
M8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R:%QB<F1R:&%I<EQB<F1R=S$P(%QT
M<F)R9')V7&)R9')H86ER7&)R9')W,3`@#5QT<F9T<U=I9'1H,UQT<G=7:61T
M:#DT-CA<=')F='-7:61T:$(S7'1R9G1S5VED=&A!,UQT<G!A9&1L,3`X7'1R
M<&%D9'(Q,#A<=')P861D9FPS7'1R<&%D9&9R,R!<8VQV97)T86QT7&-L8G)D
M<G1<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P
M(%QC;&)R9')B7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<
M8G)D<G<Q,"!<8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW5VED=&@Q-30X(%QC
M96QL>#$T-#`-7&-L=F5R=&%L=%QC;&)R9')T7&)R9')H86ER7&)R9')W,3`@
M7&-L8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB
M<F1R=S$P(%QC;&)R9')R7&)R9')H86ER7&)R9')W,3`@7&-L='AL<G1B7&-L
M9G1S5VED=&@S7&-L=U=I9'1H,3@P,"!<8V5L;'@S,C0P7&-L=F5R=&%L=%QC
M;&)R9')T7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<FQ<8G)D<FAA:7)<8G)D
M<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')R#5QB<F1R
M:&%I<EQB<F1R=S$P(%QC;'1X;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#(W
M,#`@7&-E;&QX-3DT,%QC;'9E<G1A;'1<8VQB<F1R=%QB<F1R:&%I<EQB<F1R
M=S$P(%QC;&)R9')L7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<F)<8G)D<FAA
M:7)<8G)D<G<Q,"!<8VQB<F1R<EQB<F1R:&%I<EQB<F1R=S$P(%QC;'1X;')T
M8EQC;&9T<U=I9'1H,UQC;'=7:61T:#$P.#`@7&-E;&QX-S`R,%QC;'9E<G1A
M;'1<8VQB<F1R=`U<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I
M<EQB<F1R=S$P(%QC;&)R9')B7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<
M8G)D<FAA:7)<8G)D<G<Q,"!<8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW5VED
M=&@R,S0P(%QC96QL>#DS-C!<<F]W('U<<&%R9"!<=VED8W1L<&%R7&EN=&)L
M7&%S<&%L<&AA7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<<FEN,%QL:6XP
M('M<9C)<9G,R,"!86%QC96QL(#$P,C4M(#8U-3,V7&-E;&P@#3U)3E0H4D%.
M1"@I*C8U-3,U*2LQ,#(U7&-E;&P@5$-0(%5$4%QC96QL(%-O=7)C92!0;W)T
M($YU;6)E<EQC96QL('U<<&%R9"!<=VED8W1L<&%R7&EN=&)L7&%S<&%L<&AA
M7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<<FEN,%QL:6XP('M<9C)<9G,R
M,"!<=')O=V0@7'1R9V%P:#$P.%QT<FQE9G0M,3`X7'1R8G)D<G1<8G)D<FAA
M:7)<8G)D<G<Q,"!<=')B<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QT<F)R9')B
M7&)R9')H86ER7&)R9')W,3`@#5QT<F)R9')R7&)R9')H86ER7&)R9')W,3`@
M7'1R8G)D<FA<8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R=EQB<F1R:&%I<EQB
M<F1R=S$P(%QT<F9T<U=I9'1H,UQT<G=7:61T:#DT-CA<=')F='-7:61T:$(S
M7'1R9G1S5VED=&A!,UQT<G!A9&1L,3`X7'1R<&%D9'(Q,#A<=')P861D9FPS
M7'1R<&%D9&9R,R!<8VQV97)T86QT7&-L8G)D<G1<8G)D<FAA:7)<8G)D<G<Q
M,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B#5QB<F1R:&%I
M<EQB<F1R=S$P(%QC;&)R9')R7&)R9')H86ER7&)R9')W,3`@7&-L='AL<G1B
M7&-L9G1S5VED=&@S7&-L=U=I9'1H,34T."!<8V5L;'@Q-#0P7&-L=F5R=&%L
M=%QC;&)R9')T7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<FQ<8G)D<FAA:7)<
M8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')R7&)R
M9')H86ER7&)R9')W,3`@7&-L='AL<G1B7&-L9G1S5VED=&@S7&-L=U=I9'1H
M,3@P,"!<8V5L;'@S,C0P#5QC;'9E<G1A;'1<8VQB<F1R=%QB<F1R:&%I<EQB
M<F1R=S$P(%QC;&)R9')L7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<F)<8G)D
M<FAA:7)<8G)D<G<Q,"!<8VQB<F1R<EQB<F1R:&%I<EQB<F1R=S$P(%QC;'1X
M;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#(W,#`@7&-E;&QX-3DT,%QC;'9E
M<G1A;'1<8VQB<F1R=%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')L7&)R9')H
M86ER7&)R9')W,3`@7&-L8G)D<F)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R
M<@U<8G)D<FAA:7)<8G)D<G<Q,"!<8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW
M5VED=&@Q,#@P(%QC96QL>#<P,C!<8VQV97)T86QT7&-L8G)D<G1<8G)D<FAA
M:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B
M7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"!<
M8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW5VED=&@R,S0P(%QC96QL>#DS-C!<
M<F]W('U<<&%R9"`-7'=I9&-T;'!A<EQI;G1B;%QA<W!A;'!H85QA<W!N=6U<
M9F%A=71O7&%D:G5S=')I9VAT7')I;C!<;&EN,"![7&8R7&9S,C`@65E<8V5L
M;"`Q+2`V-34S-B!O<B!S=&%T:6,@;V8@<&]R="`X,"`H:'1T<"D@;W(@<&]R
M="`R-2`H<VUT<"E<8V5L;"`]24Y4*%)!3D0H*2HV-34S-2DK,2!O<@U<<&%R
M(#@P#5QP87(@;W(-7'!A<B`R-5QC96QL(%1#4"!51%!<8V5L;"!$97-T:6YA
M=&EO;B!0;W)T($YU;6)E<BX@($EF(&$@<&%R=&EC=6QA<B!S97)V:6-E(&ES
M(&%T=&%C:V5D('5S92!T:&%T('!O<G0@;G5M8F5R+EQC96QL('U<<&%R9"!<
M=VED8W1L<&%R7&EN=&)L7&%S<&%L<&AA7&%S<&YU;5QF86%U=&]<861J=7-T
M<FEG:'1<<FEN,%QL:6XP('M<9C)<9G,R,"!<=')O=V0@7'1R9V%P:#$P.%QT
M<FQE9G0M,3`X7'1R8G)D<G1<8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R;`U<
M8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QT
M<F)R9')R7&)R9')H86ER7&)R9')W,3`@7'1R8G)D<FA<8G)D<FAA:7)<8G)D
M<G<Q,"!<=')B<F1R=EQB<F1R:&%I<EQB<F1R=S$P(%QT<F9T<U=I9'1H,UQT
M<G=7:61T:#DT-CA<=')F='-7:61T:$(S7'1R9G1S5VED=&A!,UQT<G!A9&1L
M,3`X7'1R<&%D9'(Q,#A<=')P861D9FPS7'1R<&%D9&9R,R!<8VQV97)T86QT
M7&-L8G)D<G1<8G)D<FAA:7)<8G)D<G<Q,"`-7&-L8G)D<FQ<8G)D<FAA:7)<
M8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')R7&)R
M9')H86ER7&)R9')W,3`@7&-L='AL<G1B7&-L9G1S5VED=&@S7&-L=U=I9'1H
M,34T."!<8V5L;'@Q-#0P7&-L=F5R=&%L=%QC;&)R9')T7&)R9')H86ER7&)R
M9')W,3`@7&-L8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R8EQB<F1R
M:&%I<EQB<F1R=S$P(%QC;&)R9')R7&)R9')H86ER7&)R9')W,3`@#5QC;'1X
M;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#$X,#`@7&-E;&QX,S(T,%QC;'9E
M<G1A;'1<8VQB<F1R=%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')L7&)R9')H
M86ER7&)R9')W,3`@7&-L8G)D<F)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R
M<EQB<F1R:&%I<EQB<F1R=S$P(%QC;'1X;')T8EQC;&9T<U=I9'1H,UQC;'=7
M:61T:#(W,#`@7&-E;&QX-3DT,%QC;'9E<G1A;'1<8VQB<F1R=%QB<F1R:&%I
M<EQB<F1R=S$P(%QC;&)R9')L#5QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B
M7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"!<
M8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW5VED=&@Q,#@P(%QC96QL>#<P,C!<
M8VQV97)T86QT7&-L8G)D<G1<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R;%QB
M<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B7&)R9')H86ER7&)R9')W,3`@7&-L
M8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"`-7&-L='AL<G1B7&-L9G1S5VED=&@S
M7&-L=U=I9'1H,C,T,"!<8V5L;'@Y,S8P7')O=R!]7'!A<F0@7'=I9&-T;'!A
M<EQI;G1B;%QA<W!A;'!H85QA<W!N=6U<9F%A=71O7&%D:G5S=')I9VAT7')I
M;C!<;&EN,"![7&8R7&9S,C`@+5`@4'1C<&1A=&$N='AT7&-E;&P@4W1A=&EC
M7&-E;&P@4W1A=&EC7&-E;&P@25!<8V5L;"!$871A(&EN('!A8VME="!F<F]M
M(&9I;&4@4'1C<&1A=&$N='AT7&-E;&P@?5QP87)D(`U<=VED8W1L<&%R7&EN
M=&)L7&%S<&%L<&AA7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<<FEN,%QL
M:6XP('M<9C)<9G,R,"!<=')O=V0@7'1R9V%P:#$P.%QT<FQE9G0M,3`X7'1R
M8G)D<G1<8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R;%QB<F1R:&%I<EQB<F1R
M=S$P(%QT<F)R9')B7&)R9')H86ER7&)R9')W,3`@7'1R8G)D<G)<8G)D<FAA
M:7)<8G)D<G<Q,"!<=')B<F1R:%QB<F1R:&%I<EQB<F1R=S$P(%QT<F)R9')V
M#5QB<F1R:&%I<EQB<F1R=S$P(%QT<F9T<U=I9'1H,UQT<G=7:61T:#DT-CA<
M=')F='-7:61T:$(S7'1R9G1S5VED=&A!,UQT<G!A9&1L,3`X7'1R<&%D9'(Q
M,#A<=')P861D9FPS7'1R<&%D9&9R,R!<8VQV97)T86QT7&-L8G)D<G1<8G)D
M<FAA:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R
M9')B7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D<G<Q
M,"`-7&-L='AL<G1B7&-L9G1S5VED=&@S7&-L=U=I9'1H,34T."!<8V5L;'@Q
M-#0P7&-L=F5R=&%L=%QC;&)R9')T7&)R9')H86ER7&)R9')W,3`@7&-L8G)D
M<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R=S$P
M(%QC;&)R9')R7&)R9')H86ER7&)R9')W,3`@7&-L='AL<G1B7&-L9G1S5VED
M=&@S7&-L=U=I9'1H,3@P,"!<8V5L;'@S,C0P7&-L=F5R=&%L=%QC;&)R9')T
M7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<FP-7&)R9')H86ER7&)R9')W,3`@
M7&-L8G)D<F)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R<EQB<F1R:&%I<EQB
M<F1R=S$P(%QC;'1X;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#(W,#`@7&-E
M;&QX-3DT,%QC;'9E<G1A;'1<8VQB<F1R=%QB<F1R:&%I<EQB<F1R=S$P(%QC
M;&)R9')L7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<F)<8G)D<FAA:7)<8G)D
M<G<Q,"!<8VQB<F1R<EQB<F1R:&%I<EQB<F1R=S$P(`U<8VQT>&QR=&)<8VQF
M='-7:61T:#-<8VQW5VED=&@Q,#@P(%QC96QL>#<P,C!<8VQV97)T86QT7&-L
M8G)D<G1<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R
M=S$P(%QC;&)R9')B7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA
M:7)<8G)D<G<Q,"!<8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW5VED=&@R,S0P
M(%QC96QL>#DS-C!<<F]W('U<=')O=V0@7'1R9V%P:#$P.%QT<FQE9G0M,3`X
M7'1R8G)D<G0-7&)R9')H86ER7&)R9')W,3`@7'1R8G)D<FQ<8G)D<FAA:7)<
M8G)D<G<Q,"!<=')B<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QT<F)R9')R7&)R
M9')H86ER7&)R9')W,3`@7'1R8G)D<FA<8G)D<FAA:7)<8G)D<G<Q,"!<=')B
M<F1R=EQB<F1R:&%I<EQB<F1R=S$P(%QT<F9T<U=I9'1H,UQT<G=7:61T:#DT
M-CA<=')F='-7:61T:$(S7'1R9G1S5VED=&A!,UQT<G!A9&1L,3`X7'1R<&%D
M9'(Q,#A<=')P861D9FPS7'1R<&%D9&9R,R!<8VQV97)T86QT#5QC;&)R9')T
M7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<
M8VQB<F1R8EQB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')R7&)R9')H86ER7&)R
M9')W,3`@7&-L='AL<G1B7&-L9G1S5VED=&@S7&-L=U=I9'1H,34T."!<8V5L
M;'@Q-#0P7&-L=F5R=&%L=%QC;&)R9')T7&)R9')H86ER7&)R9')W,3`@7&-L
M8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB<F1R
M=S$P(%QC;&)R9')R#5QB<F1R:&%I<EQB<F1R=S$P(%QC;'1X;')T8EQC;&9T
M<U=I9'1H,UQC;'=7:61T:#$X,#`@7&-E;&QX,S(T,%QC;'9E<G1A;'1<8VQB
M<F1R=%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')L7&)R9')H86ER7&)R9')W
M,3`@7&-L8G)D<F)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R<EQB<F1R:&%I
M<EQB<F1R=S$P(%QC;'1X;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#(W,#`@
M7&-E;&QX-3DT,%QC;'9E<G1A;'1<8VQB<F1R=`U<8G)D<FAA:7)<8G)D<G<Q
M,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P(%QC;&)R9')B7&)R9')H86ER
M7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQT>&QR=&)<
M8VQF='-7:61T:#-<8VQW5VED=&@Q,#@P(%QC96QL>#<P,C!<8VQV97)T86QT
M7&-L8G)D<G1<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB
M<F1R=S$P(%QC;&)R9')B7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D
M<FAA:7)<8G)D<G<Q,"`-7&-L='AL<G1B7&-L9G1S5VED=&@S7&-L=U=I9'1H
M,C,T,"!<8V5L;'@Y,S8P7'!A<F0@7'=I9&-T;'!A<EQI;G1B;%QA<W!A;'!H
M85QA<W!N=6U<9F%A=71O7&%D:G5S=')I9VAT7')I;C!<;&EN,"![7&8R7&9S
M,C`@1DTP(&]R($9-.#$P,%QC96QL(%-T871I8UQC96QL(%-T871I8UQC96QL
M($E07&-E;&P@1G)A9VUE;G0@3V9F<V5T7&-E;&P@?5QP87)D(`U<=VED8W1L
M<&%R7&EN=&)L7&%S<&%L<&AA7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<
M<FEN,%QL:6XP('M<9C)<9G,R,"!<=')O=V0@7'1R9V%P:#$P.%QT<FQE9G0M
M,3`X7'1R8G)D<G1<8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R;%QB<F1R:&%I
M<EQB<F1R=S$P(%QT<F)R9')B7&)R9')H86ER7&)R9')W,3`@7'1R8G)D<G)<
M8G)D<FAA:7)<8G)D<G<Q,"!<=')B<F1R:%QB<F1R:&%I<EQB<F1R=S$P(%QT
M<F)R9')V#5QB<F1R:&%I<EQB<F1R=S$P(%QT<F9T<U=I9'1H,UQT<G=7:61T
M:#DT-CA<=')F='-7:61T:$(S7'1R9G1S5VED=&A!,UQT<G!A9&1L,3`X7'1R
M<&%D9'(Q,#A<=')P861D9FPS7'1R<&%D9&9R,R!<8VQV97)T86QT7&-L8G)D
M<G1<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I<EQB<F1R=S$P
M(%QC;&)R9')B7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<8G)D<FAA:7)<
M8G)D<G<Q,"`-7&-L='AL<G1B7&-L9G1S5VED=&@S7&-L=U=I9'1H,34T."!<
M8V5L;'@Q-#0P7&-L=F5R=&%L=%QC;&)R9')T7&)R9')H86ER7&)R9')W,3`@
M7&-L8G)D<FQ<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R8EQB<F1R:&%I<EQB
M<F1R=S$P(%QC;&)R9')R7&)R9')H86ER7&)R9')W,3`@7&-L='AL<G1B7&-L
M9G1S5VED=&@S7&-L=U=I9'1H,3@P,"!<8V5L;'@S,C0P7&-L=F5R=&%L=%QC
M;&)R9')T7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<FP-7&)R9')H86ER7&)R
M9')W,3`@7&-L8G)D<F)<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R<EQB<F1R
M:&%I<EQB<F1R=S$P(%QC;'1X;')T8EQC;&9T<U=I9'1H,UQC;'=7:61T:#(W
M,#`@7&-E;&QX-3DT,%QC;'9E<G1A;'1<8VQB<F1R=%QB<F1R:&%I<EQB<F1R
M=S$P(%QC;&)R9')L7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<F)<8G)D<FAA
M:7)<8G)D<G<Q,"!<8VQB<F1R<EQB<F1R:&%I<EQB<F1R=S$P(`U<8VQT>&QR
M=&)<8VQF='-7:61T:#-<8VQW5VED=&@Q,#@P(%QC96QL>#<P,C!<8VQV97)T
M86QT7&-L8G)D<G1<8G)D<FAA:7)<8G)D<G<Q,"!<8VQB<F1R;%QB<F1R:&%I
M<EQB<F1R=S$P(%QC;&)R9')B7&)R9')H86ER7&)R9')W,3`@7&-L8G)D<G)<
M8G)D<FAA:7)<8G)D<G<Q,"!<8VQT>&QR=&)<8VQF='-7:61T:#-<8VQW5VED
M=&@R,S0P(%QC96QL>#DS-C!<<F]W('U<<&%R9%QP;&%I;B`-7',Q-UQW:61C
M=&QP87)<87-P86QP:&%<87-P;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR:6XP
M7&QI;C!<:71A<#`@7&8Q7&QA;F<Q,#,S7&-G<FED('L-7'!A<B!]7'!A<F1<
M<&QA:6X@7'=I9&-T;'!A<EQA<W!A;'!H85QA<W!N=6U<9F%A=71O7&%D:G5S
M=')I9VAT7')I;C!<;&EN,%QI=&%P,"!<9C%<;&%N9S$P,S-<8V=R:60@>U-E
M="!U<"!T:&4@<&%Y;&]A9"!D871A('-O('1H870@=V4@:&%V92!A(")L96=A
M;"(@<VEZ960@9G)A9VUE;G0Z#5QP87(@4&EC;7!D871A+G1X="`](")!3F5M
M97-I<TE#35!$871A0DYE;65S:7-)0TU01&%T82(-7'!A<B!0=&-P9&%T82YT
M>'0@/2`B04YE;65S:7-40U!$871A0DYE;65S:7-40U!$82(-7'!A<B!0=61P
M9&%T82YT>'0@/2`B04YE;65S:7-51%!$871A04).96UE<VES54101&%T84(B
M#5QP87(@#5QP87(@3F5X="!N96UE<VES(&%N9"!7:6Y08V%P+3,N,"!W;W5L
M9"!B92!I;G-T86QL960@;VX@96%C:"!O9B!T:&4@86)O=F4@8V]M<')O;6ES
M960@;6%C:&EN97,N("!.96UE<VES(&-A;B!B92!F;W5N9"!A="!3;W5R8V5F
M;W)G93H@2F5F9B!.871H86XL(&YE;65S:7,N<V]U<F-E9F]R9V4N;F5T("T@
M4&%C:V5T(&EN:F5C=&EO;B!T;V]L('-U:71E+"`R,#`S+B`@55),.B!]>UQF
M:65L9'M<*EQF;&1I;G-T('L-($A94$523$E.2R`B:'1T<#HO+VYE;65S:7,N
M<V]U<F-E9F]R9V4N;F5T+R(@?7M[7"I<9&%T869I96QD(`TP,&0P8SEE83<Y
M9CEB86-E,3$X8S@R,#!A83`P-&)A.3!B,#(P,#`P,#`Q-S`P,#`P,#(P,#`P
M,#`P-C@P,#<T,#`W-#`P-S`P,#-A,#`R9C`P,F8P,#9E,#`V-3`P-F0P,#8U
M,#`W,S`P-CDP,#<S,#`R93`P-S,P,#9F,#`W-3`P-S(P,#8S,#`V-3`P-C8P
M,#9F,#`W,C`P-C<P,#8U,#`R93`P-F4P,#8U,#`W-#`P,F8P,#`P,#!E,&,Y
M96$W.68Y8F%C93$Q.&,X,C`P86$P,#1B83DP8C0P,#`P,#`P-C@P,#<T,#`W
M-#`P-S`P,#-A,#`R9C`P,F8P,`TV93`P-C4P,#9D,#`V-3`P-S,P,#8Y,#`W
M,S`P,F4P,#<S,#`V9C`P-S4P,#<R,#`V,S`P-C4P,#8V,#`V9C`P-S(P,#8W
M,#`V-3`P,F4P,#9E,#`V-3`P-S0P,#)F,#`P,#`P?7U]>UQF;&1R<VQT('M<
M8W,Q-5QU;%QC9C(@:'1T<#HO+VYE;65S:7,N<V]U<F-E9F]R9V4N;F5T+WU]
M?7L@*$%C8V5S<V5D($1E8V5M8F5R(#0L(#(P,#,I+B`@5VEN4&-A<"TS+C`@
M8V%N(&)E(&9O=6YD(&%T.B!,;PUR:7,@1&5G:6]A;FYI("AA;F0@;W1H97)S
M*2P@5VEN9&]W<R!086-K970@0V%P='5R92!,:6)R87)Y+"`R,#`S+B`@55),
M.B`@?7M<9FEE;&1[7"I<9FQD:6YS="![($A94$523$E.2R`B:'1T<#HO+W=I
M;G!C87`N<&]L:71O+FET+VEN<W1A;&PO(B!]>WM<*EQD871A9FEE;&0@#3`P
M9#!C.65A-SEF.6)A8V4Q,3AC.#(P,&%A,#`T8F$Y,&(P,C`P,#`P,#$W,#`P
M,#`P,C(P,#`P,#`V.#`P-S0P,#<T,#`W,#`P,V$P,#)F,#`R9C`P-S<P,#8Y
M,#`V93`P-S`P,#8S,#`V,3`P-S`P,#)E,#`W,#`P-F8P,#9C,#`V.3`P-S0P
M,#9F,#`R93`P-CDP,#<T,#`R9C`P-CDP,#9E,#`W,S`P-S0P,#8Q,#`V8S`P
M-F,P,#)F,#`P,#`P93!C.65A-SEF.6)A8V4Q,3AC.#(P,&%A,#`T8F$Y,&(T
M-#`P,#`P,#8X,#`W-#`P-S0P,#<P,#`S83`P#3)F,#`R9C`P-S<P,#8Y,#`V
M93`P-S`P,#8S,#`V,3`P-S`P,#)E,#`W,#`P-F8P,#9C,#`V.3`P-S0P,#9F
M,#`R93`P-CDP,#<T,#`R9C`P-CDP,#9E,#`W,S`P-S0P,#8Q,#`V8S`P-F,P
M,#)F,#`P,#`P?7U]>UQF;&1R<VQT('M<8W,Q-5QU;%QC9C(@:'1T<#HO+W=I
M;G!C87`N<&]L:71O+FET+VEN<W1A;&PO?7U]>R`H06-C97-S960@1&5C96UB
M97(@-"P@,C`P,RDN("!4:&4@97AC96P@;W5T<'5T('=I=&@@82!N86UE(&]F
M(")]>UQB(`UA='1A8VMP+F)A='U[(B!A;F0@(GU[7&(@871T86-K8FEG+F)A
M='U[(B!W;W5L9"!B92!P;&%C960@;VX@=&AE(&-O;7!R;VUI<V5D(&UA8VAI
M;F5S+B`@06X@97AA;7!L92!O9B!J=7-T('-I>"!P86-K971S("AO9B!M86YY
M('1H;W5S86YD<RD@9G)O;2!T:&4@9FEL92!]>UQB(&%T=&%C:W`N8F%T?7L@
M871T86-K:6YG('1H92!(5%10('!O<G0@;VX@,3DW+C`N,"XQ,B!W;W5L9"!L
M;V]K(&QI:V4Z#5QP87(@?5QP87)D7'!L86EN(%QS,SE<=VED8W1L<&%R7&%S
M<&%L<&AA7&%S<&YU;5QF86%U=&]<861J=7-T<FEG:'1<<FEN,%QL:6XP7&ET
M87`P(%QF,EQF<S(P7&QA;F<Q,#,S7&-G<FED('MN96UE<VES(&EC;7`@+5,@
M,38Q+C(Q-2XR,S`N,C(R("U$(#$Y-RXP+C`N,3(@+60Q("UI(#@@+4D@,C8Q
M-C@@+5`@:6-M<&1A=&$N='AT("U&33`-7'!A<B!]7'!A<F1<<&QA:6X@7'=I
M9&-T;'!A<EQA<W!A;'!H85QA<W!N=6U<9F%A=71O7&%D:G5S=')I9VAT7')I
M;C!<;&EN,%QI=&%P,"!<9C%<;&%N9S$P,S-<8V=R:60@>UQF,EQF<S(P(&YE
M;65S:7,@:6-M<"`M4R`Q-C$N,C$U+C(S,"XR,C(@+40@,3DW+C`N,"XQ,B`M
M9#$@+6D@."`M22`R-C$V."`M4"!I8VUP9&%T82YT>'0@+48X,3`P#5QP87(@
M;F5M97-I<R!T8W`@+5,@,3(N,C(V+C$T-"XW,R`M1"`Q.3<N,"XP+C$R("UD
M,2`M22`Q-#$Y,R`M<R`S.3@T-#8X.34U("UA(#,X-C0Y-3(Y,SD@+7@@,C4T
M,C,@+7D@.#`@+5`@4'1C<&1A=&$N='AT("U&33`-7'!A<B!N96UE<VES('1C
M<"`M4R`Q,BXR,C8N,30T+C<S("U$(#$Y-RXP+C`N,3(@+60Q("U)(#$T,3DS
M("US(#,Y.#0T-C@Y-34@+6$@,S@V-#DU,CDS.2`M>"`R-30R,R`M>2`X,"`M
M4"!0=&-P9&%T82YT>'0@+48X,3`P#5QP87(@;F5M97-I<R!U9'`@+5,@,3`Q
M+C0Q+C$Q-RXR,30@+40@,3DW+C`N,"XQ,B`M9#$@+4D@-3@W.#D@+7@@,C0S
M,#`@+7D@.#`@+5`@4'5D<&1A=&$N='AT("U&33`-7'!A<B!N96UE<VES('5D
M<"`M4R`Q,#$N-#$N,3$W+C(Q-"`M1"`Q.3<N,"XP+C$R("UD,2`M22`U.#<X
M.2`M>"`R-#,P,"`M>2`X,"`M4"!0=61P9&%T82YT>'0@+48X,3`P#5QP87(@
M?5QP87)D7'!L86EN(%QS,3=<=VED8W1L<&%R7&%S<&%L<&AA7&%S<&YU;5QF
M86%U=&]<861J=7-T<FEG:'1<<FEN,%QL:6XP7&ET87`P(%QF,5QL86YG,3`S
M,UQC9W)I9"![#5QP87(@?5QP87)D7'!L86EN(%QW:61C=&QP87)<87-P86QP
M:&%<87-P;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR:6XP7&QI;C!<:71A<#`@
M7&8Q7&QA;F<Q,#,S7&-G<FED('M!='1A8VMB:6<N8F%T('=O=6QD(&QO;VL@
M;&EK93H-7'!A<B!]7'!A<F1<<&QA:6X@7',Q-UQW:61C=&QP87)<87-P86QP
M:&%<87-P;G5M7&9A875T;UQA9&IU<W1R:6=H=%QR:6XP7&QI;C!<:71A<#`@
M7&8Q7&QA;F<Q,#,S7&-G<FED('M<9C)<9G,R,"`Z;&]O<`U<<&%R('U<<&%R
M9%QP;&%I;B!<=VED8W1L<&%R7&%S<&%L<&AA7&%S<&YU;5QF86%U=&]<861J
M=7-T<FEG:'1<<FEN,%QL:6XP7&ET87`P(%QF,5QL86YG,3`S,UQC9W)I9"![
M7&8R7&9S,C`@0V%L;"!A='1A8VMP+F)A=`U<<&%R(%)E;2!786ET('1W;R!S
M96-O;F1S(&)E9F]R92!S96YD:6YG(&]U="!T:&4@;F5X="!B871C:"!O9B!D
M871A#5QP87(@<&EN9R`M;B`R(#$R-RXP+C`N,0U<<&%R(&=O=&\@;&]O<`U<
M<&%R('U[#5QP87(@06QL(&]F('1H92!C;VUP<F]M:7-E9"!M86-H:6YE<R!W
M;W5L9"!T:&5N('-T87)T('-E;F1I;F<@=&AE('!A8VME=',@?7M<8B!W:71H
M('1H92!C;VUM86YD(&%S(&9O;&QO=W-]>SH-7'!A<B!]7'!A<F1<<&QA:6X@
M7',Q-UQW:61C=&QP87)<87-P86QP:&%<87-P;G5M7&9A875T;UQA9&IU<W1R
M:6=H=%QR:6XP7&QI;C!<:71A<#`@7&8Q7&QA;F<Q,#,S7&-G<FED('M<9C(@
M0SI<7#YA='1A8VMB:6<N8F%T#5QP87(@?7L-7'!A<B!]7'!A<F1<<&QA:6X@
M7'=I9&-T;'!A<EQA<W!A;'!H85QA<W!N=6U<9F%A=71O7&%D:G5S=')I9VAT
M7')I;C!<;&EN,%QI=&%P,"!<9C%<;&%N9S$P,S-<8V=R:60@>UQB(%1H92!A
M='1A8VL@=V]U;&0@8F4@<W5C8V5S<V9U;'U[#2!I;B!T:&%T(&ET('=O=6QD
M(&YO="!O;FQY('1R>2!T;R!O=F5R=VAE;&T@=&AE(&-O;FYE8W1I;VX@=&\@
M1TE!0R!W:71H('=H870@(FQO;VLB(&QI:V4@<F5A;"!C;VYN96-T:6]N(&%T
M=&5M<'1S+"!I="!I<R!A;'-O(&1E<VEG;F5D('1O(&YO="!A;&QO=R!T:&4@
M=&%R9V5T(&UA8VAI;F4@=&\@8V]M;75N:6-A=&4@=VET:"!O=&AE<B!M86-H
M:6YE<R!T:&%T#2!R97%U:7)E(&9R86=M96YT871I;VX@;V8@;&%R9V4@9&%T
M82!P86-K971S("AW:&5T:&5R('1H97D@8F4@:6YT97)N86P@;W(@97AT97)N
M86P@;6%C:&EN97,I+@U<<&%R(`U<<&%R(%1H92!]>UQB(&-O=6YT97)M96%S
M=7)E<R!T;R!M:71I9V%T92!T:&ES(&%T=&%C:WU[('=O=6QD(&EN=F]L=F4@
M=&AE($E34"!A;F0@<F5C;VYF:6=U<FEN9R!T:&4@:6YT97)N86P@;6%C:&EN
M97,N("!4:&4@25-0('=O=6QD(&AA=F4@=&\@=')A8VL@9&]W;B!E86-H(&]F
M('1H92!C;VUP<F]M:0US960@;6%C:&EN97,N("!3:6YC92!T:&4@<V]U<F-E
M($E0(&%D9')E<W,@:7,@<F%N9&]M('1H92!O;FQY('=A>2!T;R!T<F%C:R!D
M;W=N('1H92!M86-H:6YE(&ES('1O('1R86-E(')O=71E<B!B>2!R;W5T97(L
M(&AO<"!B>2!H;W`L('=H:6-H(&UA8VAI;F5S(&%R92!S96YD:6YG(&]U="!T
M:&4@86YO;6%L;W5S('!A8VME=',N("!);G1E<FYA;"!M86-H:6YE<R!T:&%T
M(&-O;FYE8W0@=&\@=&AE(&UA8VAI;F4@=&AA="!I<R!A='1A8VME9"!W;W4-
M;&0@:&%V92!T;R!B92!R96-O;F9I9W5R960@;F]T('1O('-E;F0@9G)A9VUE
;;G1E9"!P86-K971S+@U<<&%R(`U<<&%R('U]
`
end
--B_3159000045_290789--



From ak@suse.de Sat Feb  7 10:10:21 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 10:10:24 -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 i17IAAKO005616
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 10:10:11 -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 910161553F0; Sat,  7 Feb 2004 18:24:36 +0100 (CET)
Received: by wotan.suse.de (Postfix, from userid 14000)
	id 5D20A196B9; Sat,  7 Feb 2004 18:24:36 +0100 (CET)
Date: Sat, 7 Feb 2004 18:24:36 +0100
From: Andi Kleen <ak@suse.de>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Andi Kleen <ak@suse.de>, bluez-devel@lists.sourceforge.net,
        netdev@oss.sgi.com, viro@zenII.linux.org.uk
Subject: Re: some bluetooth fixes
Message-ID: <20040207172436.GB449@wotan.suse.de>
References: <20040206050042.20a2b3b0.ak@suse.de> <1076079512.2806.40.camel@pegasus> <20040207032428.56ffbebc.ak@suse.de> <1076152411.14418.73.camel@pegasus> <20040207125723.391a1fcd.ak@suse.de> <1076173068.2670.4.camel@pegasus>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1076173068.2670.4.camel@pegasus>
X-archive-position: 3098
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: 394
Lines: 9

On Sat, Feb 07, 2004 at 05:57:48PM +0100, Marcel Holtmann wrote:
> I now looked carefully through your patch and changed and added some
> parts to better fit into. I also fixed another RFCOMM refcount bug.
> Please review it, before I send it to Dave.

Doing size checks after the multiply is too late - they could
have already overflowed. You have to check the raw value from the user.

-Andi

From jonmason@us.ibm.com Sat Feb  7 13:37:32 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 13:37:36 -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 i17LbOKQ011595
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 13:37:31 -0800
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
	by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i17LbIM3659614;
	Sat, 7 Feb 2004 16:37:18 -0500
Received: from d03nm130.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i17LbH07114104;
	Sat, 7 Feb 2004 14:37:18 -0700
In-Reply-To: <je65ejvwpa.fsf@sykes.suse.de>
To: Andreas Schwab <schwab@suse.de>
Cc: cramerj@intel.com, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com
MIME-Version: 1.0
Subject: Re: Bad UDP checksum with 82540EM
X-Mailer: Lotus Notes Build V651_12042003 December 04, 2003
Message-ID: <OFE5352D34.67E10D98-ON87256E33.00725857-86256E33.0076C481@us.ibm.com>
From: Jon D Mason <jonmason@us.ibm.com>
Date: Sat, 7 Feb 2004 15:37:16 -0600
X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at
 02/07/2004 14:37:17,
	Serialize complete at 02/07/2004 14:37:17
Content-Type: text/plain; charset="US-ASCII"
X-archive-position: 3099
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: jonmason@us.ibm.com
Precedence: bulk
X-list: netdev
Content-Length: 429
Lines: 10

This probably isn't helpful, but it sounds like a hardware error.  Is the 
error occurring on multiple/all HP adapters, or only one? 

Also, your driver code is old, the latest is 5.2.30.1 (goto 
http://sourceforge.net/projects/e1000/).  I don't think that has anything 
to do with it though.

Jon Mason                jonmason@us.ibm.com
Software Engineer        Phone:(512)838.4162
Linux eServer I/O        Fax:  (512)838.3509

From mika.penttila@kolumbus.fi Sat Feb  7 13:41:30 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 13:41:33 -0800 (PST)
Received: from notes.hallinto.turkuamk.fi (notes.hallinto.turkuamk.fi [195.148.215.149])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i17LfSKO012492
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 13:41:29 -0800
Received: from kolumbus.fi ([193.166.244.70])
          by marconi.hallinto.turkuamk.fi (Lotus Domino Release 5.0.8)
          with ESMTP id 2004020712391810:6610 ;
          Sat, 7 Feb 2004 12:39:18 +0200 
Message-ID: <4024C0EA.1010904@kolumbus.fi>
Date: Sat, 07 Feb 2004 12:41:46 +0200
From: =?ISO-8859-1?Q?Mika_Penttil=E4?= <mika.penttila@kolumbus.fi>
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
MIME-Version: 1.0
To: =?ISO-8859-1?Q?YOSHIFUJI_Hideaki_/_=3F=3F=3F=3F?=
 <yoshfuji@linux-ipv6.org>
CC: kazunori@miyazawa.org, davem@redhat.com, netdev@oss.sgi.com,
        usagi-core@linux-ipv6.org
Subject: Re: [PATCH][IPV6][NDISC] unify ipv6 output routine
References: <4023D6FB.9010909@kolumbus.fi>	<20040207.131455.27570445.yoshfuji@linux-ipv6.org>	<4024A488.60203@kolumbus.fi> <20040207.192804.29120956.yoshfuji@linux-ipv6.org>
In-Reply-To: <20040207.192804.29120956.yoshfuji@linux-ipv6.org>
X-MIMETrack: Itemize by SMTP Server on marconi.hallinto.turkuamk.fi/TAMK(Release 5.0.8 |June
 18, 2001) at 07.02.2004 12:39:18,
	Serialize by Router on notes.hallinto.turkuamk.fi/TAMK(Release 5.0.10 |March
 22, 2002) at 07.02.2004 23:42:50,
	Serialize complete at 07.02.2004 23:42:50
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i17LfSKO012492
X-archive-position: 3100
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: mika.penttila@kolumbus.fi
Precedence: bulk
X-list: netdev
Content-Length: 1386
Lines: 47



YOSHIFUJI Hideaki / ???? wrote:

>In article <4024A488.60203@kolumbus.fi> (at Sat, 07 Feb 2004 10:40:40 +0200), Mika Penttilä <mika.penttila@kolumbus.fi> says:
>
>  
>
>>>The ip6_output2() resolves and inserts link-layer address appropriately.
>>>If it did, we would have noticed (by conformance test or even by
>>>usual operation). ;-)
>>> 
>>>
>>>      
>>>
>>ip6_output2() doesn't resolve link-layer addresses. We don't even have a 
>>neighbour, in
>>ndisc_dst_alloc(dev, NULL, ip6_output2); case.
>>    
>>
>
>ip6_output2() calls ip6_output_flinish().
>ip6_output_finish() calls dst->hh->hh_output() if hh is already built.
>Otherwise, dst->neighbour->output() is called and it resolves 
>link-layer address of neighbor.
>
>I think you missed our ndsic_dst_alloc() change.
>ndisc_dst_alloc() takes 4 argument:
>   struct dst_entry *ndisc_dst_alloc(struct net_device *dev, 
>                                     struct neighbour *neigh,
>                                     struct in6_addr *addr,
>                                     int (*output)(struct sk_buff *));
>If neigh is NULL, we do ndisc_get_neigh(dev, addr) to get one.
>
>  
>
hmm. where is this ndisc_dst_alloc() change? In the patch it's called 
with three params, only the output routine is changed :

- dst = ndisc_dst_alloc(dev, NULL, ndisc_output);
+ dst = ndisc_dst_alloc(dev, NULL, ip6_output2);


--Mika




From schwab@suse.de Sat Feb  7 15:26:40 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 15:26:50 -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 i17NQSKO017324;
	Sat, 7 Feb 2004 15:26:29 -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 94C2E17372A; Sat,  7 Feb 2004 23:42:22 +0100 (CET)
Received: by sykes.suse.de (Postfix, from userid 597)
	id D4F8F14C9F596; Sat,  7 Feb 2004 23:42:21 +0100 (CET)
To: Jon D Mason <jonmason@us.ibm.com>
Cc: cramerj@intel.com, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com
Subject: Re: Bad UDP checksum with 82540EM
References: <OFE5352D34.67E10D98-ON87256E33.00725857-86256E33.0076C481@us.ibm.com>
From: Andreas Schwab <schwab@suse.de>
X-Yow: Our father who art in heaven..  I sincerely pray that SOMEBODY
 at this table will PAY for my SHREDDED WHAT and ENGLISH MUFFIN..
 and also leave a GENEROUS TIP...
Date: Sat, 07 Feb 2004 23:42:21 +0100
In-Reply-To: <OFE5352D34.67E10D98-ON87256E33.00725857-86256E33.0076C481@us.ibm.com> (Jon
 D. Mason's message of "Sat, 7 Feb 2004 15:37:16 -0600")
Message-ID: <je3c9mv7ea.fsf@sykes.suse.de>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-archive-position: 3101
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: schwab@suse.de
Precedence: bulk
X-list: netdev
Content-Length: 595
Lines: 16

Jon D Mason <jonmason@us.ibm.com> writes:

> This probably isn't helpful, but it sounds like a hardware error.  Is the 
> error occurring on multiple/all HP adapters, or only one? 

I've also seen it with a HP branded BCM5701 on IA64, but also with a
Broadcom BCM5702 on AMD64 (both using the tg3 driver).  It seems like
broken UDP checksumming is rather common. :-(

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

From ak@suse.de Sat Feb  7 19:52:45 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 19:52:55 -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 i183qYKO031014;
	Sat, 7 Feb 2004 19:52:34 -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 70CF8175588; Sun,  8 Feb 2004 04:07:02 +0100 (CET)
Date: Sun, 8 Feb 2004 07:46:43 +0100
From: Andi Kleen <ak@suse.de>
To: Andreas Schwab <schwab@suse.de>
Cc: jonmason@us.ibm.com, cramerj@intel.com, netdev@oss.sgi.com,
        netdev-bounce@oss.sgi.com
Subject: Re: Bad UDP checksum with 82540EM
Message-Id: <20040208074643.482ab4c7.ak@suse.de>
In-Reply-To: <je3c9mv7ea.fsf@sykes.suse.de>
References: <OFE5352D34.67E10D98-ON87256E33.00725857-86256E33.0076C481@us.ibm.com>
	<je3c9mv7ea.fsf@sykes.suse.de>
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: 3102
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: 742
Lines: 19

On Sat, 07 Feb 2004 23:42:21 +0100
Andreas Schwab <schwab@suse.de> wrote:

> Jon D Mason <jonmason@us.ibm.com> writes:
> 
> > This probably isn't helpful, but it sounds like a hardware error.  Is the 
> > error occurring on multiple/all HP adapters, or only one? 
> 
> I've also seen it with a HP branded BCM5701 on IA64, but also with a
> Broadcom BCM5702 on AMD64 (both using the tg3 driver).  It seems like
> broken UDP checksumming is rather common. :-(

It could be still a software bug.  When hardware checksumming is available
the UDP packets use a slightly different path through the stack.

Could you perhaps test if the problem occurs in a 32bit box with the 
same NIC ? Maybe it is some 64bit problem somewhere in software.

-Andi

From yoshfuji@linux-ipv6.org Sat Feb  7 21:10:25 2004
Received: with ECARTIS (v1.0.0; list netdev); Sat, 07 Feb 2004 21:10:28 -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 i185AOKO004292
	for <netdev@oss.sgi.com>; Sat, 7 Feb 2004 21:10:24 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 1F01E33CA5; Sun,  8 Feb 2004 14:11:18 +0900 (JST)
Date: Sun, 08 Feb 2004 14:11:17 +0900 (JST)
Message-Id: <20040208.141117.116936870.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: [RFC,PATCH] remove IPV6_AUTHHDR socket option / ancillary data
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: 3103
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: 4583
Lines: 171

Hello.

AH is now handled by the XFRM engine.
IPV6_AUTHHDR socket option / ancillary data are deprecated.

For sender side, it is very difficult (or even almost impossible) to
create "correct" AH in userspace.
For receiver side, none set opt->auth and user space application
never get authentication data.

IPV6_AUTHHDR is very Linux-specific and applications which use
these feature are not portable at all.

Let's remove almost dead code.

===== include/linux/ipv6.h 1.17 vs edited =====
--- 1.17/include/linux/ipv6.h	Fri Jan 16 07:15:33 2004
+++ edited/include/linux/ipv6.h	Sun Feb  8 13:17:28 2004
@@ -185,7 +185,6 @@
 	int			iif;
 	__u16			ra;
 	__u16			hop;
-	__u16			auth;
 	__u16			dst0;
 	__u16			srcrt;
 	__u16			dst1;
@@ -211,7 +210,6 @@
 				rxhlim:1,
 				hopopts:1,
 				dstopts:1,
-                                authhdr:1,
                                 rxflow:1;
 		} bits;
 		__u8		all;
===== net/ipv6/datagram.c 1.14 vs edited =====
--- 1.14/net/ipv6/datagram.c	Thu Jan 22 15:38:40 2004
+++ edited/net/ipv6/datagram.c	Sun Feb  8 13:20:49 2004
@@ -242,10 +242,6 @@
 		struct ipv6_rt_hdr *rthdr = (struct ipv6_rt_hdr *)(skb->nh.raw + opt->srcrt);
 		put_cmsg(msg, SOL_IPV6, IPV6_RTHDR, (rthdr->hdrlen+1) << 3, rthdr);
 	}
-	if (np->rxopt.bits.authhdr && opt->auth) {
-		u8 *ptr = skb->nh.raw + opt->auth;
-		put_cmsg(msg, SOL_IPV6, IPV6_AUTHHDR, (ptr[1]+1)<<2, ptr);
-	}
 	if (np->rxopt.bits.dstopts && opt->dst1) {
 		u8 *ptr = skb->nh.raw + opt->dst1;
 		put_cmsg(msg, SOL_IPV6, IPV6_DSTOPTS, (ptr[1]+1)<<3, ptr);
@@ -376,26 +372,6 @@
 			}
 			opt->opt_flen += len;
 			opt->dst1opt = hdr;
-			break;
-
-		case IPV6_AUTHHDR:
-                        if (cmsg->cmsg_len < CMSG_LEN(sizeof(struct ipv6_opt_hdr))) {
-				err = -EINVAL;
-				goto exit_f;
-			}
-
-			hdr = (struct ipv6_opt_hdr *)CMSG_DATA(cmsg);
-			len = ((hdr->hdrlen + 2) << 2);
-			if (cmsg->cmsg_len < CMSG_LEN(len)) {
-				err = -EINVAL;
-				goto exit_f;
-			}
-			if (len & ~7) {
-				err = -EINVAL;
-				goto exit_f;
-			}
-			opt->opt_flen += len;
-			opt->auth = hdr;
 			break;
 
 		case IPV6_RTHDR:
===== net/ipv6/exthdrs.c 1.15 vs edited =====
--- 1.15/net/ipv6/exthdrs.c	Thu Jan 29 09:06:25 2004
+++ edited/net/ipv6/exthdrs.c	Sun Feb  8 13:14:43 2004
@@ -518,17 +518,6 @@
 	return &h->nexthdr;
 }
 
-static u8 *ipv6_build_authhdr(struct sk_buff *skb, u8 *prev_hdr, struct ipv6_opt_hdr *opt)
-{
-	struct ipv6_opt_hdr *h = (struct ipv6_opt_hdr *)skb_put(skb, (opt->hdrlen+2)<<2);
-
-	memcpy(h, opt, (opt->hdrlen+2)<<2);
-	h->nexthdr = *prev_hdr;
-	*prev_hdr = NEXTHDR_AUTH;
-	return &h->nexthdr;
-}
-
-
 u8 *ipv6_build_nfrag_opts(struct sk_buff *skb, u8 *prev_hdr, struct ipv6_txoptions *opt,
 			  struct in6_addr *daddr, u32 jumbolen)
 {
@@ -567,8 +556,6 @@
 
 u8 *ipv6_build_frag_opts(struct sk_buff *skb, u8 *prev_hdr, struct ipv6_txoptions *opt)
 {
-	if (opt->auth)
-		prev_hdr = ipv6_build_authhdr(skb, prev_hdr, opt->auth);
 	if (opt->dst1opt)
 		prev_hdr = ipv6_build_exthdr(skb, prev_hdr, NEXTHDR_DEST, opt->dst1opt);
 	return prev_hdr;
@@ -608,15 +595,6 @@
 	*proto = type;
 }
 
-static void ipv6_push_authhdr(struct sk_buff *skb, u8 *proto, struct ipv6_opt_hdr *opt)
-{
-	struct ipv6_opt_hdr *h = (struct ipv6_opt_hdr *)skb_push(skb, (opt->hdrlen+2)<<2);
-
-	memcpy(h, opt, (opt->hdrlen+2)<<2);
-	h->nexthdr = *proto;
-	*proto = NEXTHDR_AUTH;
-}
-
 void ipv6_push_nfrag_opts(struct sk_buff *skb, struct ipv6_txoptions *opt,
 			  u8 *proto,
 			  struct in6_addr **daddr)
@@ -633,8 +611,6 @@
 {
 	if (opt->dst1opt)
 		ipv6_push_exthdr(skb, proto, NEXTHDR_DEST, opt->dst1opt);
-	if (opt->auth)
-		ipv6_push_authhdr(skb, proto, opt->auth);
 }
 
 struct ipv6_txoptions *
@@ -652,8 +628,6 @@
 			*((char**)&opt2->dst0opt) += dif;
 		if (opt2->dst1opt)
 			*((char**)&opt2->dst1opt) += dif;
-		if (opt2->auth)
-			*((char**)&opt2->auth) += dif;
 		if (opt2->srcrt)
 			*((char**)&opt2->srcrt) += dif;
 	}
===== net/ipv6/ipv6_sockglue.c 1.23 vs edited =====
--- 1.23/net/ipv6/ipv6_sockglue.c	Wed Jan 14 09:36:24 2004
+++ edited/net/ipv6/ipv6_sockglue.c	Sun Feb  8 13:14:15 2004
@@ -230,11 +230,6 @@
 		retv = 0;
 		break;
 
-	case IPV6_AUTHHDR:
-		np->rxopt.bits.authhdr = valbool;
-		retv = 0;
-		break;
-
 	case IPV6_DSTOPTS:
 		np->rxopt.bits.dstopts = valbool;
 		retv = 0;
@@ -621,10 +616,6 @@
 
 	case IPV6_HOPOPTS:
 		val = np->rxopt.bits.hopopts;
-		break;
-
-	case IPV6_AUTHHDR:
-		val = np->rxopt.bits.authhdr;
 		break;
 
 	case IPV6_DSTOPTS:



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

From ja@ssi.bg Sun Feb  8 01:56:49 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 01:56:53 -0800 (PST)
Received: from u.domain.uli (ja.mac.ssi.bg [217.79.71.194])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i189uiKO020691
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 01:56:47 -0800
Received: from localhost (localhost [127.0.0.1])
	by u.domain.uli (8.12.10/8.12.10) with ESMTP id i189xZxC007301;
	Sun, 8 Feb 2004 11:59:35 +0200
Date: Sun, 8 Feb 2004 11:59:35 +0200 (EET)
From: Julian Anastasov <ja@ssi.bg>
X-X-Sender: ja@u.domain.uli
To: netdev@oss.sgi.com
cc: linux-net@vger.kernel.org
Subject: Restrict local IP announcements in ARP requests
Message-ID: <Pine.LNX.4.58.0402081149001.6268@u.domain.uli>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 3104
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: ja@ssi.bg
Precedence: bulk
X-list: netdev


	Hello,

	I'm opening again the discussion about src IP selection
in ARP requests. We know that there are tools and framework for
ARP filtering and mangling. The question is whether we need a
simple interface flag to restrict the local src IP address for cases
where the target hosts require sender to be from same known logical
subnet due to [wrong] policy or topology reasons.

	I'm proposing simple flag that controls the src selection
in our ARP requests. I named it arp_announce - mode used to define
different restriction levels for announcing the local source address
from IP packets in ARP requests:

0 - the current behavior: use any local address if possible

	as it appears it is not the most safe mode in some cases

1 - restrict saddr to the target's subnet

	this behavior is useful in setups where the target hosts
	have [sometimes default] policy to drop incoming requests by
	checking the src IP. The result is that we can announce
	only addresses from same logical subnet as the target.

2 - always use the best source address for this target

	This is the most restrictive mode that expects answer
	from the target host. In this case we can announce only
	preferred/primary IP address. Useful for setups where we
	do not want to announce secondary IPs, for example, if
	they are shared from many hosts.

Draft version can be found here:

http://www.ssi.bg/~ja/#arp_announce

and it is also appended here. Comments?

Regards

--
Julian Anastasov <ja@ssi.bg>

diff -ur v2.6.2/linux/Documentation/networking/ip-sysctl.txt linux/Documentation/networking/ip-sysctl.txt
--- v2.6.2/linux/Documentation/networking/ip-sysctl.txt	2004-02-05 00:23:10.000000000 +0200
+++ linux/Documentation/networking/ip-sysctl.txt	2004-02-08 11:35:04.617310560 +0200
@@ -486,6 +486,21 @@
 	conf/{all,interface}/arp_filter is set to TRUE,
 	it will be disabled otherwise
 
+arp_announce - INTEGER
+	Define different restriction levels for announcing the local
+	source IP address from IP packets in ARP requests sent on
+	interface:
+	0 - (default) Use any local address, configured on any interface
+	1 - Try to avoid local addresses that are not in the target's
+	subnet for this interface
+	2 - Always use the best source address for this target
+
+	The max value from conf/{all,interface}/arp_announce is used.
+
+	Increasing the restriction level gives more chance for
+	receiving answer from the resolved target while decreasing
+	the level announces more valid sender's information.
+
 tag - INTEGER
 	Allows you to write a number, which can be used as required.
 	Default value is 0.
diff -ur v2.6.2/linux/include/linux/inetdevice.h linux/include/linux/inetdevice.h
--- v2.6.2/linux/include/linux/inetdevice.h	2003-08-23 19:42:33.000000000 +0300
+++ linux/include/linux/inetdevice.h	2004-02-07 17:57:38.000000000 +0200
@@ -18,6 +18,7 @@
 	int	mc_forwarding;
 	int	tag;
 	int     arp_filter;
+	int	arp_announce;
 	int	medium_id;
 	int	no_xfrm;
 	int	no_policy;
@@ -70,6 +71,7 @@
 	  (ipv4_devconf.accept_redirects || (in_dev)->cnf.accept_redirects)))
 
 #define IN_DEV_ARPFILTER(in_dev)	(ipv4_devconf.arp_filter || (in_dev)->cnf.arp_filter)
+#define IN_DEV_ARP_ANNOUNCE(in_dev)	(max(ipv4_devconf.arp_announce, (in_dev)->cnf.arp_announce))
 
 struct in_ifaddr
 {
diff -ur v2.6.2/linux/include/linux/sysctl.h linux/include/linux/sysctl.h
--- v2.6.2/linux/include/linux/sysctl.h	2004-02-05 00:23:17.000000000 +0200
+++ linux/include/linux/sysctl.h	2004-02-07 18:01:58.000000000 +0200
@@ -360,6 +360,7 @@
 	NET_IPV4_CONF_MEDIUM_ID=14,
 	NET_IPV4_CONF_NOXFRM=15,
 	NET_IPV4_CONF_NOPOLICY=16,
+	NET_IPV4_CONF_ARP_ANNOUNCE=17,
 };
 
 /* /proc/sys/net/ipv4/netfilter */
diff -ur v2.6.2/linux/net/ipv4/arp.c linux/net/ipv4/arp.c
--- v2.6.2/linux/net/ipv4/arp.c	2004-02-05 00:23:18.000000000 +0200
+++ linux/net/ipv4/arp.c	2004-02-08 11:37:24.551037400 +0200
@@ -321,15 +321,57 @@
 
 static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb)
 {
-	u32 saddr;
+	u32 saddr = 0;
 	u8  *dst_ha = NULL;
 	struct net_device *dev = neigh->dev;
 	u32 target = *(u32*)neigh->primary_key;
 	int probes = atomic_read(&neigh->probes);
+	struct rtable *rt;
+	struct in_device *in_dev = in_dev_get(dev);
 
-	if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL)
+	if (!in_dev)
+		return;
+
+	switch (IN_DEV_ARP_ANNOUNCE(in_dev)) {
+	default:
+	case 0:		/* By default announce any local IP */
+		if (skb && inet_addr_type(skb->nh.iph->saddr) == RTN_LOCAL)
+			saddr = skb->nh.iph->saddr;
+		break;
+	case 1:		/* Restrict announcements of saddr in same subnet */
+		if (!skb || !(rt = (struct rtable *) skb->dst) || rt->fl.iif)
+			break;
 		saddr = skb->nh.iph->saddr;
-	else
+		/* rt_src is always a local address */
+		if (saddr == rt->rt_src || inet_addr_type(saddr) == RTN_LOCAL) {
+			/* saddr should be known to target */
+			if (inet_addr_onlink(in_dev, target, saddr))
+				break;
+		}
+		saddr = 0;
+		break;
+	case 2:		/* Avoid secondary IPs, get a primary/preferred one */
+#if 0
+		{
+			struct flowi fl = {
+				.nl_u = { .ip4_u = { .daddr = target } },
+				.oif = dev->ifindex };
+
+			in_dev_put(in_dev);
+			in_dev = NULL;
+			if (ip_route_output_key(&rt, &fl) < 0)
+				return;
+			saddr = rt->rt_src;
+			ip_rt_put(rt);
+		}
+#endif
+
+		break;
+	}
+
+	if (in_dev)
+		in_dev_put(in_dev);
+	if (!saddr)
 		saddr = inet_select_addr(dev, target, RT_SCOPE_LINK);
 
 	if ((probes -= neigh->parms->ucast_probes) < 0) {
diff -ur v2.6.2/linux/net/ipv4/devinet.c linux/net/ipv4/devinet.c
--- v2.6.2/linux/net/ipv4/devinet.c	2004-02-05 00:23:18.000000000 +0200
+++ linux/net/ipv4/devinet.c	2004-02-07 18:03:04.000000000 +0200
@@ -1132,7 +1132,7 @@
 
 static struct devinet_sysctl_table {
 	struct ctl_table_header *sysctl_header;
-	ctl_table		devinet_vars[17];
+	ctl_table		devinet_vars[18];
 	ctl_table		devinet_dev[2];
 	ctl_table		devinet_conf_dir[2];
 	ctl_table		devinet_proto_dir[2];
@@ -1252,6 +1252,14 @@
 			.proc_handler	= &proc_dointvec,
 		},
 		{
+			.ctl_name	= NET_IPV4_CONF_ARP_ANNOUNCE,
+			.procname	= "arp_announce",
+			.data		= &ipv4_devconf.arp_announce,
+			.maxlen		= sizeof(int),
+			.mode		= 0644,
+			.proc_handler	= &proc_dointvec,
+		},
+		{
 			.ctl_name	= NET_IPV4_CONF_NOXFRM,
 			.procname	= "disable_xfrm",
 			.data		= &ipv4_devconf.no_xfrm,

From yoshfuji@linux-ipv6.org Sun Feb  8 04:20:01 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 04:20:05 -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 i18CJoKO029564
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 04:19:51 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 981AF33CA5; Sun,  8 Feb 2004 20:39:30 +0900 (JST)
Date: Sun, 08 Feb 2004 20:39:30 +0900 (JST)
Message-Id: <20040208.203930.36073978.yoshfuji@linux-ipv6.org>
To: davem@redhat.com, kuznet@ms2.inr.ac.ru
Cc: netdev@oss.sgi.com
Subject: [Q] LL_RESERVED_SPACE(dev) vs HH_DATA_ALIGN(dev->hard_header_len)
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: 3105
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 many places like:
  (dev->hard_header_len + 15) & ~15
or
  dev->hard_header_len + 15.

I guess the second one trying to express maximum number of the 
first one and it seems that
  HH_DATA_ALIGN(dev->hard_header_len)
  LL_SPACE_RESERVED(dev)
(defined in include/linux/netdevice.h) will do for us respectively.

Question: 
  How do you think about the following patch?
  Or, is it okay to simply use LL_RESERVED_SPACE(dev) in both places?

Thanks in advance.

===== net/econet/af_econet.c 1.30 vs edited =====
--- 1.30/net/econet/af_econet.c	Mon Jan 26 04:05:06 2004
+++ edited/net/econet/af_econet.c	Sun Feb  8 17:18:51 2004
@@ -318,12 +318,12 @@
 #ifdef CONFIG_ECONET_NATIVE
 		dev_hold(dev);
 		
-		skb = sock_alloc_send_skb(sk, len+dev->hard_header_len+15, 
+		skb = sock_alloc_send_skb(sk, len + LL_RESERVED_SPACE(dev),
 					  msg->msg_flags & MSG_DONTWAIT, &err);
 		if (skb==NULL)
 			goto out_unlock;
 		
-		skb_reserve(skb, (dev->hard_header_len+15)&~15);
+		skb_reserve(skb, HH_DATA_ALIGN(dev->hard_header_len));
 		skb->nh.raw = skb->data;
 		
 		eb = (struct ec_cb *)&skb->cb;

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

From schwab@suse.de Sun Feb  8 05:11:18 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 05:11:29 -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 i18DBHKO003454;
	Sun, 8 Feb 2004 05:11:17 -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 D80F9179E2F; Sun,  8 Feb 2004 14:09:39 +0100 (CET)
Received: by sykes.suse.de (Postfix, from userid 597)
	id D6DC814CA417D; Sun,  8 Feb 2004 14:09:36 +0100 (CET)
To: Andi Kleen <ak@suse.de>
Cc: jonmason@us.ibm.com, cramerj@intel.com, netdev@oss.sgi.com,
        netdev-bounce@oss.sgi.com
Subject: Re: Bad UDP checksum with 82540EM
References: <OFE5352D34.67E10D98-ON87256E33.00725857-86256E33.0076C481@us.ibm.com>
	<je3c9mv7ea.fsf@sykes.suse.de> <20040208074643.482ab4c7.ak@suse.de>
From: Andreas Schwab <schwab@suse.de>
X-Yow: This PIZZA symbolizes my COMPLETE EMOTIONAL RECOVERY!!
Date: Sun, 08 Feb 2004 14:09:36 +0100
In-Reply-To: <20040208074643.482ab4c7.ak@suse.de> (Andi Kleen's message of
 "Sun, 8 Feb 2004 07:46:43 +0100")
Message-ID: <jeznbtg1kf.fsf@sykes.suse.de>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-archive-position: 3106
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: schwab@suse.de
Precedence: bulk
X-list: netdev

Andi Kleen <ak@suse.de> writes:

> On Sat, 07 Feb 2004 23:42:21 +0100
> Andreas Schwab <schwab@suse.de> wrote:
>
>> Jon D Mason <jonmason@us.ibm.com> writes:
>> 
>> > This probably isn't helpful, but it sounds like a hardware error.  Is the 
>> > error occurring on multiple/all HP adapters, or only one? 
>> 
>> I've also seen it with a HP branded BCM5701 on IA64, but also with a
>> Broadcom BCM5702 on AMD64 (both using the tg3 driver).  It seems like
>> broken UDP checksumming is rather common. :-(
>
> It could be still a software bug.  When hardware checksumming is available
> the UDP packets use a slightly different path through the stack.
>
> Could you perhaps test if the problem occurs in a 32bit box with the 
> same NIC ? Maybe it is some 64bit problem somewhere in software.

Just tested with a "3Com 3C996B-T 1000Base-T" (BCM5701 based, with tg3
driver) on an Athlon.  It shows the same bug, and disabling HW
checksumming on tx fixes it.  So it doesn't look like a 64bit issue.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

From shmulik.hen@intel.com Sun Feb  8 08:11:25 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 08:11:38 -0800 (PST)
Received: from hermes.py.intel.com (hermes.py.intel.com [146.152.216.3])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i18GBOKO008866
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 08:11:25 -0800
Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4])
	by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.5 2003/11/26 00:10:29 root Exp $) with ESMTP id i18GBGrr004100;
	Sun, 8 Feb 2004 16:11:16 GMT
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206])
	by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i18GC5tl000589;
	Sun, 8 Feb 2004 16:12:15 GMT
Received: from jrslxjul4.npdj.intel.com ([10.12.220.54])
 by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020808111315955
 ; Sun, 08 Feb 2004 08:11:14 -0800
From: Shmuel Hen <shmulik.hen@intel.com>
Organization: Intel Corporation
To: "Jeff Garzik" <jgarzik@pobox.com>
Subject: [PATCH 1/3][bonding][2.6] Add support for HW accel. slaves
Date: Sun, 8 Feb 2004 18:11:10 +0200
User-Agent: KMail/1.5.3
Cc: "linux-netdev" <netdev@oss.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200402081811.12359.shmulik.hen@intel.com>
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-archive-position: 3109
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: 31350
Lines: 1072

Jeff,
Now that David Miller accepted the first half of this set into 2.6,
I'm resending the last half to you for inclusion in netdev-2.6.

Tested against latest netdev-2.6. Summary:

Change the bond interface to publish full VLAN hardware acceleration 
offloading capabilities, and add capability in all xmit functions to 
take special care for VLAN HW accel. tagged skb's that are going out 
through a slave that is not offloading capable. 

Add a mechanism to collect and save the VLAN Id's that have been 
added on top of a bond interface, and propagate the register/add/kill 
operations to the slaves. 

Add blocking mechanism to prevent adding VLAN interfaces on top of a 
bond that contains VLAN challenged slaves and to prevent adding VLAN 
challenged slaves to a bond that already has VLAN interfaces on top 
of it. 

Add a section about VLAN to Documentation/networking/bonding.txt and
also correct some minor spelling/grammer errors.
 
-- 
| Shmulik Hen   Advanced Network Services  |
| Israel Design Center, Jerusalem          |
| LAN Access Division, Platform Networking |
| Intel Communications Group, Intel corp.  |


diff -Nuarp a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
--- a/Documentation/networking/bonding.txt	Wed Jan 21 16:56:18 2004
+++ b/Documentation/networking/bonding.txt	Wed Jan 21 16:56:19 2004
@@ -31,6 +31,7 @@ Verifying Bond Configuration
 Frequently Asked Questions
 High Availability
 Promiscuous Sniffing notes
+8021q VLAN support
 Limitations
 Resources and Links
 
@@ -140,10 +141,6 @@ probeall bond0 eth0 eth1 bonding
 Be careful not to reference bond0 itself at the end of the line, or modprobe
 will die in an endless recursive loop.
 
-To have device characteristics (such as MTU size) propagate to slave devices,
-set the bond characteristics before enslaving the device.  The characteristics
-are propagated during the enslave process.
-
 If running SNMP agents, the bonding driver should be loaded before any network
 drivers participating in a bond. This requirement is due to the the interface
 index (ipAdEntIfIndex) being associated to the first interface found with a
@@ -601,7 +598,7 @@ Frequently Asked Questions
 	For ethernet cards not supporting MII status, the arp_interval and
         arp_ip_target parameters must be specified for bonding to work
         correctly. If packets have not been sent or received during the
-        specified arp_interval durration, an ARP request is sent to the
+        specified arp_interval duration, an ARP request is sent to the
         targets to generate send and receive traffic. If after this
         interval, either the successful send and/or receive count has not
         incremented, the next slave in the sequence will become the active
@@ -669,16 +666,8 @@ Frequently Asked Questions
 	that will be added.
 
 	To restore your slaves' MAC addresses, you need to detach them
-	from the bond (`ifenslave -d bond0 eth0'), set them down
-	(`ifconfig eth0 down'), unload the drivers (`rmmod 3c59x', for
-	example) and reload them to get the MAC addresses from their
-	eeproms. If the driver is shared by several devices, you need
-	to turn them all down. Another solution is to look for the MAC
-	address at boot time (dmesg or tail /var/log/messages) and to
-	reset it by hand with ifconfig :
-
-	  # ifconfig eth0 down
-	  # ifconfig eth0 hw ether 00:20:40:60:80:A0
+	from the bond (`ifenslave -d bond0 eth0'). The bonding driver will then
+	restore the MAC addresses that the slaves had before they were enslaved.
 
 9.  Which transmit polices can be used?
 
@@ -843,7 +832,7 @@ point of failure" solution.
 
 In this configuration, there is an ISL - Inter Switch Link (could be a trunk),
 several servers (host1, host2 ...) attached to both switches each, and one or
-more ports to the outside world (port3...). One an only one slave on each host
+more ports to the outside world (port3...). One and only one slave on each host
 is active at a time, while all links are still monitored (the system can
 detect a failure of active and backup links).
 
@@ -933,6 +922,41 @@ capacity aggregating; but it works fine 
 just ignore all the warnings it emits.
 
 
+8021q VLAN support
+==================
+
+It is possible to configure VLAN devices over a bond interface using the 8021q
+driver. However, only packets coming from the 8021q driver and passing through
+bonding will be tagged by default. Self generated packets, like bonding's
+learning packets or ARP packets generated by either ALB mode or the ARP
+monitor mechanism, are tagged internally by bonding itself. As a result,
+bonding has to "learn" what VLAN IDs are configured on top of it, and it uses
+those IDs to tag self generated packets.
+
+For simplicity reasons, and to support the use of adapters that can do VLAN
+hardware acceleration offloding, the bonding interface declares itself as
+fully hardware offloaing capable, it gets the add_vid/kill_vid notifications
+to gather the necessary information, and it propagates those actions to the
+slaves.
+In case of mixed adapter types, hardware accelerated tagged packets that should
+go through an adapter that is not offloading capable are "un-accelerated" by the
+bonding driver so the VLAN tag sits in the regular location.
+
+VLAN interfaces *must* be added on top of a bonding interface only after
+enslaving at least one slave. This is because until the first slave is added the
+bonding interface has a HW address of 00:00:00:00:00:00, which will be copied by
+the VLAN interface when it is created.
+
+Notice that a problem would occur if all slaves are released from a bond that
+still has VLAN interfaces on top of it. When later coming to add new slaves, the
+bonding interface would get a HW address from the first slave, which might not
+match that of the VLAN interfaces. It is recommended that either all VLANs are
+removed and then re-added, or to manually set the bonding interface's HW
+address so it matches the VLAN's. (Note: changing a VLAN interface's HW address
+would set the underlying device -- i.e. the bonding interface -- to promiscouos
+mode, which might not be what you want).
+
+
 Limitations
 ===========
 The main limitations are :
diff -Nuarp a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
--- a/drivers/net/bonding/bond_3ad.c	Wed Jan 21 16:56:18 2004
+++ b/drivers/net/bonding/bond_3ad.c	Wed Jan 21 16:56:19 2004
@@ -2362,6 +2362,7 @@ int bond_3ad_xmit_xor(struct sk_buff *sk
 	int agg_id;
 	int i;
 	struct ad_info ad_info;
+	int res = 1;
 
 	/* make sure that the slaves list will
 	 * not change during tx
@@ -2369,12 +2370,12 @@ int bond_3ad_xmit_xor(struct sk_buff *sk
 	read_lock(&bond->lock);
 
 	if (!BOND_IS_OK(bond)) {
-		goto free_out;
+		goto out;
 	}
 
 	if (bond_3ad_get_active_agg_info(bond, &ad_info)) {
 		printk(KERN_DEBUG "ERROR: bond_3ad_get_active_agg_info failed\n");
-		goto free_out;
+		goto out;
 	}
 
 	slaves_in_agg = ad_info.ports;
@@ -2383,7 +2384,7 @@ int bond_3ad_xmit_xor(struct sk_buff *sk
 	if (slaves_in_agg == 0) {
 		/*the aggregator is empty*/
 		printk(KERN_DEBUG "ERROR: active aggregator is empty\n");
-		goto free_out;
+		goto out;
 	}
 
 	slave_agg_no = (data->h_dest[5]^bond->dev->dev_addr[5]) % slaves_in_agg;
@@ -2401,7 +2402,7 @@ int bond_3ad_xmit_xor(struct sk_buff *sk
 
 	if (slave_agg_no >= 0) {
 		printk(KERN_ERR DRV_NAME ": Error: Couldn't find a slave to tx on for aggregator ID %d\n", agg_id);
-		goto free_out;
+		goto out;
 	}
 
 	start_at = slave;
@@ -2414,24 +2415,19 @@ int bond_3ad_xmit_xor(struct sk_buff *sk
 			slave_agg_id = agg->aggregator_identifier;
 		}
 
-		if (SLAVE_IS_OK(slave) && 
-		    agg && (slave_agg_id == agg_id)) {
-			skb->dev = slave->dev;			
-			skb->priority = 1;
-			dev_queue_xmit(skb);
-
-			goto out;
+		if (SLAVE_IS_OK(slave) && agg && (slave_agg_id == agg_id)) {
+			res = bond_dev_queue_xmit(bond, skb, slave->dev);
+			break;
 		}
 	}
 
 out:
+	if (res) {
+		/* no suitable interface, frame not sent */
+		dev_kfree_skb(skb);
+	}
 	read_unlock(&bond->lock);
 	return 0;
-
-free_out:
-	/* no suitable interface, frame not sent */
-	dev_kfree_skb(skb);
-	goto out;
 }
 
 int bond_3ad_lacpdu_recv(struct sk_buff *skb, struct net_device *dev, struct packet_type* ptype)
diff -Nuarp a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
--- a/drivers/net/bonding/bond_alb.c	Wed Jan 21 16:56:18 2004
+++ b/drivers/net/bonding/bond_alb.c	Wed Jan 21 16:56:19 2004
@@ -1193,6 +1193,7 @@ int bond_alb_xmit(struct sk_buff *skb, s
 	int do_tx_balance = 1;
 	u32 hash_index = 0;
 	u8 *hash_start = NULL;
+	int res = 1;
 
 	/* make sure that the curr_active_slave and the slaves list do
 	 * not change during tx
@@ -1201,7 +1202,7 @@ int bond_alb_xmit(struct sk_buff *skb, s
 	read_lock(&bond->curr_slave_lock);
 
 	if (!BOND_IS_OK(bond)) {
-		goto free_out;
+		goto out;
 	}
 
 	switch (ntohs(skb->protocol)) {
@@ -1266,29 +1267,27 @@ int bond_alb_xmit(struct sk_buff *skb, s
 	}
 
 	if (tx_slave && SLAVE_IS_OK(tx_slave)) {
-		skb->dev = tx_slave->dev;
 		if (tx_slave != bond->curr_active_slave) {
 			memcpy(eth_data->h_source,
 			       tx_slave->dev->dev_addr,
 			       ETH_ALEN);
 		}
-		dev_queue_xmit(skb);
+
+		res = bond_dev_queue_xmit(bond, skb, tx_slave->dev);
 	} else {
-		/* no suitable interface, frame not sent */
 		if (tx_slave) {
 			tlb_clear_slave(bond, tx_slave, 0);
 		}
-		goto free_out;
 	}
 
 out:
+	if (res) {
+		/* no suitable interface, frame not sent */
+		dev_kfree_skb(skb);
+	}
 	read_unlock(&bond->curr_slave_lock);
 	read_unlock(&bond->lock);
 	return 0;
-
-free_out:
-	dev_kfree_skb(skb);
-	goto out;
 }
 
 void bond_alb_monitor(struct bonding *bond)
diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
--- a/drivers/net/bonding/bond_main.c	Wed Jan 21 16:56:18 2004
+++ b/drivers/net/bonding/bond_main.c	Wed Jan 21 16:56:19 2004
@@ -502,6 +502,7 @@
 #include <net/arp.h>
 #include <linux/mii.h>
 #include <linux/ethtool.h>
+#include <linux/if_vlan.h>
 #include <linux/if_bonding.h>
 #include "bonding.h"
 #include "bond_3ad.h"
@@ -620,6 +621,330 @@ static const char *bond_mode_name(int mo
 	}
 }
 
+/*---------------------------------- VLAN -----------------------------------*/
+
+/**
+ * bond_add_vlan - add a new vlan id on bond
+ * @bond: bond that got the notification
+ * @vlan_id: the vlan id to add
+ *
+ * Returns -ENOMEM if allocation failed.
+ */
+static int bond_add_vlan(struct bonding *bond, unsigned short vlan_id)
+{
+	struct vlan_entry *vlan;
+
+	dprintk("bond: %s, vlan id %d\n",
+		(bond ? bond->dev->name: "None"), vlan_id);
+
+	vlan = kmalloc(sizeof(struct vlan_entry), GFP_KERNEL);
+	if (!vlan) {
+		return -ENOMEM;
+	}
+
+	INIT_LIST_HEAD(&vlan->vlan_list);
+	vlan->vlan_id = vlan_id;
+
+	write_lock_bh(&bond->lock);
+
+	list_add_tail(&vlan->vlan_list, &bond->vlan_list);
+
+	write_unlock_bh(&bond->lock);
+
+	dprintk("added VLAN ID %d on bond %s\n", vlan_id, bond->dev->name);
+
+	return 0;
+}
+
+/**
+ * bond_del_vlan - delete a vlan id from bond
+ * @bond: bond that got the notification
+ * @vlan_id: the vlan id to delete
+ *
+ * returns -ENODEV if @vlan_id was not found in @bond.
+ */
+static int bond_del_vlan(struct bonding *bond, unsigned short vlan_id)
+{
+	struct vlan_entry *vlan, *next;
+	int res = -ENODEV;
+
+	dprintk("bond: %s, vlan id %d\n", bond->dev->name, vlan_id);
+
+	write_lock_bh(&bond->lock);
+
+	list_for_each_entry_safe(vlan, next, &bond->vlan_list, vlan_list) {
+		if (vlan->vlan_id == vlan_id) {
+			list_del(&vlan->vlan_list);
+
+			dprintk("removed VLAN ID %d from bond %s\n", vlan_id,
+				bond->dev->name);
+
+			kfree(vlan);
+
+			if (list_empty(&bond->vlan_list) &&
+			    (bond->slave_cnt == 0)) {
+				/* Last VLAN removed and no slaves, so
+				 * restore block on adding VLANs. This will
+				 * be removed once new slaves that are not
+				 * VLAN challenged will be added.
+				 */
+				bond->dev->features |= NETIF_F_VLAN_CHALLENGED;
+			}
+
+			res = 0;
+			goto out;
+		}
+	}
+
+	dprintk("couldn't find VLAN ID %d in bond %s\n", vlan_id,
+		bond->dev->name);
+
+out:
+	write_unlock_bh(&bond->lock);
+	return res;
+}
+
+/**
+ * bond_has_challenged_slaves
+ * @bond: the bond we're working on
+ *
+ * Searches the slave list. Returns 1 if a vlan challenged slave
+ * was found, 0 otherwise.
+ *
+ * Assumes bond->lock is held.
+ */
+static int bond_has_challenged_slaves(struct bonding *bond)
+{
+	struct slave *slave;
+	int i;
+
+	bond_for_each_slave(bond, slave, i) {
+		if (slave->dev->features & NETIF_F_VLAN_CHALLENGED) {
+			dprintk("found VLAN challenged slave - %s\n",
+				slave->dev->name);
+			return 1;
+		}
+	}
+
+	dprintk("no VLAN challenged slaves found\n");
+	return 0;
+}
+
+/**
+ * bond_dev_queue_xmit - Prepare skb for xmit.
+ * 
+ * @bond: bond device that got this skb for tx.
+ * @skb: hw accel VLAN tagged skb to transmit
+ * @slave_dev: slave that is supposed to xmit this skbuff
+ * 
+ * When the bond gets an skb to tarnsmit that is
+ * already hardware accelerated VLAN tagged, and it
+ * needs to relay this skb to a slave that is not
+ * hw accel capable, the skb needs to be "unaccelerated",
+ * i.e. strip the hwaccel tag and re-insert it as part
+ * of the payload.
+ * 
+ * Assumption - once a VLAN device is created over the bond device, all
+ * packets are going to be hardware accelerated VLAN tagged since the IP
+ * binding is done over the VLAN device
+ */
+int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev)
+{
+	unsigned short vlan_id;
+	int res;
+
+	if (!list_empty(&bond->vlan_list) &&
+	    !(slave_dev->features & NETIF_F_HW_VLAN_TX)) {
+		res = vlan_get_tag(skb, &vlan_id);
+		if (res) {
+			return -EINVAL;
+		}
+
+		skb->dev = slave_dev;
+		skb = vlan_put_tag(skb, vlan_id);
+		if (!skb) {
+			/* vlan_put_tag() frees the skb in case of error,
+			 * so return success here so the calling functions
+			 * won't attempt to free is again.
+			 */
+			return 0;
+		}
+	} else {
+		skb->dev = slave_dev;
+	}
+
+	skb->priority = 1;
+	dev_queue_xmit(skb);
+
+	return 0;
+}
+
+/*
+ * In the following 3 functions, bond_vlan_rx_register(), bond_vlan_rx_add_vid
+ * and bond_vlan_rx_kill_vid, We don't protect the slave list iteration with a
+ * lock because:
+ * a. This operation is performed in IOCTL context,
+ * b. The operation is protected by the RTNL semaphore in the 8021q code,
+ * c. Holding a lock with BH disabled while directly calling a base driver
+ *    entry point is generally a BAD idea.
+ * 
+ * The design of synchronization/protection for this operation in the 8021q
+ * module is good for one or more VLAN devices over a single physical device
+ * and cannot be extended for a teaming solution like bonding, so there is a
+ * potential race condition here where a net device from the vlan group might
+ * be referenced (either by a base driver or the 8021q code) while it is being
+ * removed from the system. However, it turns out we're not making matters
+ * worse, and if it works for regular VLAN usage it will work here too.
+*/
+
+/**
+ * bond_vlan_rx_register - Propagates registration to slaves
+ * @bond_dev: bonding net device that got called
+ * @grp: vlan group being registered
+ */
+static void bond_vlan_rx_register(struct net_device *bond_dev, struct vlan_group *grp)
+{
+	struct bonding *bond = bond_dev->priv;
+	struct slave *slave;
+	int i;
+
+	bond->vlgrp = grp;
+
+	bond_for_each_slave(bond, slave, i) {
+		struct net_device *slave_dev = slave->dev;
+
+		if ((slave_dev->features & NETIF_F_HW_VLAN_RX) &&
+		    slave_dev->vlan_rx_register) {
+			slave_dev->vlan_rx_register(slave_dev, grp);
+		}
+	}
+}
+
+/**
+ * bond_vlan_rx_add_vid - Propagates adding an id to slaves
+ * @bond_dev: bonding net device that got called
+ * @vid: vlan id being added
+ */
+static void bond_vlan_rx_add_vid(struct net_device *bond_dev, uint16_t vid)
+{
+	struct bonding *bond = bond_dev->priv;
+	struct slave *slave;
+	int i, res;
+
+	bond_for_each_slave(bond, slave, i) {
+		struct net_device *slave_dev = slave->dev;
+
+		if ((slave_dev->features & NETIF_F_HW_VLAN_FILTER) &&
+		    slave_dev->vlan_rx_add_vid) {
+			slave_dev->vlan_rx_add_vid(slave_dev, vid);
+		}
+	}
+
+	res = bond_add_vlan(bond, vid);
+	if (res) {
+		printk(KERN_ERR DRV_NAME
+		       ": %s: Failed to add vlan id %d\n",
+		       bond_dev->name, vid);
+	}
+}
+
+/**
+ * bond_vlan_rx_kill_vid - Propagates deleting an id to slaves
+ * @bond_dev: bonding net device that got called
+ * @vid: vlan id being removed
+ */
+static void bond_vlan_rx_kill_vid(struct net_device *bond_dev, uint16_t vid)
+{
+	struct bonding *bond = bond_dev->priv;
+	struct slave *slave;
+	struct net_device *vlan_dev;
+	int i, res;
+
+	bond_for_each_slave(bond, slave, i) {
+		struct net_device *slave_dev = slave->dev;
+
+		if ((slave_dev->features & NETIF_F_HW_VLAN_FILTER) &&
+		    slave_dev->vlan_rx_kill_vid) {
+			/* Save and then restore vlan_dev in the grp array,
+			 * since the slave's driver might clear it.
+			 */
+			vlan_dev = bond->vlgrp->vlan_devices[vid];
+			slave_dev->vlan_rx_kill_vid(slave_dev, vid);
+			bond->vlgrp->vlan_devices[vid] = vlan_dev;
+		}
+	}
+
+	res = bond_del_vlan(bond, vid);
+	if (res) {
+		printk(KERN_ERR DRV_NAME
+		       ": %s: Failed to remove vlan id %d\n",
+		       bond_dev->name, vid);
+	}
+}
+
+static void bond_add_vlans_on_slave(struct bonding *bond, struct net_device *slave_dev)
+{
+	struct vlan_entry *vlan;
+
+	write_lock_bh(&bond->lock);
+
+	if (list_empty(&bond->vlan_list)) {
+		goto out;
+	}
+
+	if ((slave_dev->features & NETIF_F_HW_VLAN_RX) &&
+	    slave_dev->vlan_rx_register) {
+		slave_dev->vlan_rx_register(slave_dev, bond->vlgrp);
+	}
+
+	if (!(slave_dev->features & NETIF_F_HW_VLAN_FILTER) ||
+	    !(slave_dev->vlan_rx_add_vid)) {
+		goto out;
+	}
+
+	list_for_each_entry(vlan, &bond->vlan_list, vlan_list) {
+		slave_dev->vlan_rx_add_vid(slave_dev, vlan->vlan_id);
+	}
+
+out:
+	write_unlock_bh(&bond->lock);
+}
+
+static void bond_del_vlans_from_slave(struct bonding *bond, struct net_device *slave_dev)
+{
+	struct vlan_entry *vlan;
+	struct net_device *vlan_dev;
+
+	write_lock_bh(&bond->lock);
+
+	if (list_empty(&bond->vlan_list)) {
+		goto out;
+	}
+
+	if (!(slave_dev->features & NETIF_F_HW_VLAN_FILTER) ||
+	    !(slave_dev->vlan_rx_kill_vid)) {
+		goto unreg;
+	}
+
+	list_for_each_entry(vlan, &bond->vlan_list, vlan_list) {
+		/* Save and then restore vlan_dev in the grp array,
+		 * since the slave's driver might clear it.
+		 */
+		vlan_dev = bond->vlgrp->vlan_devices[vlan->vlan_id];
+		slave_dev->vlan_rx_kill_vid(slave_dev, vlan->vlan_id);
+		bond->vlgrp->vlan_devices[vlan->vlan_id] = vlan_dev;
+	}
+
+unreg:
+	if ((slave_dev->features & NETIF_F_HW_VLAN_RX) &&
+	    slave_dev->vlan_rx_register) {
+		slave_dev->vlan_rx_register(slave_dev, NULL);
+	}
+
+out:
+	write_unlock_bh(&bond->lock);
+}
+
 /*------------------------------- Link status -------------------------------*/
 
 /*
@@ -1214,6 +1539,7 @@ static int bond_enslave(struct net_devic
 	struct dev_mc_list *dmi;
 	struct sockaddr addr;
 	int link_reporting;
+	int old_features = bond_dev->features;
 	int res = 0;
 
 	if (slave_dev->do_ioctl == NULL) {
@@ -1234,6 +1560,36 @@ static int bond_enslave(struct net_devic
 		return -EBUSY;
 	}
 
+	/* vlan challenged mutual exclusion */
+	/* no need to lock since we're protected by rtnl_lock */
+	if (slave_dev->features & NETIF_F_VLAN_CHALLENGED) {
+		dprintk("%s: NETIF_F_VLAN_CHALLENGED\n", slave_dev->name);
+		if (!list_empty(&bond->vlan_list)) {
+			printk(KERN_ERR DRV_NAME
+			       ": Error: cannot enslave VLAN "
+			       "challenged slave %s on VLAN enabled "
+			       "bond %s\n", slave_dev->name,
+			       bond_dev->name);
+			return -EPERM;
+		} else {
+			printk(KERN_WARNING DRV_NAME
+			       ": Warning: enslaved VLAN challenged "
+			       "slave %s. Adding VLANs will be blocked as "
+			       "long as %s is part of bond %s\n",
+			       slave_dev->name, slave_dev->name,
+			       bond_dev->name);
+			bond_dev->features |= NETIF_F_VLAN_CHALLENGED;
+		}
+	} else {
+		dprintk("%s: ! NETIF_F_VLAN_CHALLENGED\n", slave_dev->name);
+		if (bond->slave_cnt == 0) {
+			/* First slave, and it is not VLAN challenged,
+			 * so remove the block of adding VLANs over the bond.
+			 */
+			bond_dev->features &= ~NETIF_F_VLAN_CHALLENGED;
+		}
+	}
+
 	if (app_abi_ver >= 1) {
 		/* The application is using an ABI, which requires the
 		 * slave interface to be closed.
@@ -1242,7 +1598,8 @@ static int bond_enslave(struct net_devic
 			printk(KERN_ERR DRV_NAME
 			       ": Error: %s is up\n",
 			       slave_dev->name);
-			return -EPERM;
+			res = -EPERM;
+			goto err_undo_flags;
 		}
 
 		if (slave_dev->set_mac_address == NULL) {
@@ -1253,7 +1610,8 @@ static int bond_enslave(struct net_devic
 			       "Your kernel likely does not support slave "
 			       "devices.\n");
 
-			return -EOPNOTSUPP;
+			res = -EOPNOTSUPP;
+			goto err_undo_flags;
 		}
 	} else {
 		/* The application is not using an ABI, which requires the
@@ -1263,7 +1621,8 @@ static int bond_enslave(struct net_devic
 			printk(KERN_ERR DRV_NAME
 			       ": Error: %s is not running\n",
 			       slave_dev->name);
-			return -EINVAL;
+			res = -EINVAL;
+			goto err_undo_flags;
 		}
 
 		if ((bond->params.mode == BOND_MODE_8023AD) ||
@@ -1273,13 +1632,15 @@ static int bond_enslave(struct net_devic
 			       ": Error: to use %s mode, you must upgrade "
 			       "ifenslave.\n",
 			       bond_mode_name(bond->params.mode));
-			return -EOPNOTSUPP;
+			res = -EOPNOTSUPP;
+			goto err_undo_flags;
 		}
 	}
 
 	new_slave = kmalloc(sizeof(struct slave), GFP_KERNEL);
 	if (!new_slave) {
-		return -ENOMEM;
+		res = -ENOMEM;
+		goto err_undo_flags;
 	}
 
 	memset(new_slave, 0, sizeof(struct slave));
@@ -1368,6 +1729,8 @@ static int bond_enslave(struct net_devic
 		dev_mc_add(slave_dev, lacpdu_multicast, ETH_ALEN, 0);
 	}
 
+	bond_add_vlans_on_slave(bond, slave_dev);
+
 	write_lock_bh(&bond->lock);
 
 	bond_attach_slave(bond, new_slave);
@@ -1576,6 +1939,10 @@ err_restore_mac:
 
 err_free:
 	kfree(new_slave);
+
+err_undo_flags:
+	bond_dev->features = old_features;
+
 	return res;
 }
 
@@ -1689,8 +2056,37 @@ static int bond_release(struct net_devic
 		}
 	}
 
+	if (bond->slave_cnt == 0) {
+		/* if the last slave was removed, zero the mac address
+		 * of the master so it will be set by the application
+		 * to the mac address of the first slave
+		 */
+		memset(bond_dev->dev_addr, 0, bond_dev->addr_len);
+
+		if (list_empty(&bond->vlan_list)) {
+			bond_dev->features |= NETIF_F_VLAN_CHALLENGED;
+		} else {
+			printk(KERN_WARNING DRV_NAME
+			       ": Warning: clearing HW address of %s while it "
+			       "still has VLANs.\n",
+			       bond_dev->name);
+			printk(KERN_WARNING DRV_NAME
+			       ": When re-adding slaves, make sure the bond's "
+			       "HW address matches its VLANs'.\n");
+		}
+	} else if ((bond_dev->features & NETIF_F_VLAN_CHALLENGED) &&
+		   !bond_has_challenged_slaves(bond)) {
+		printk(KERN_INFO DRV_NAME
+		       ": last VLAN challenged slave %s "
+		       "left bond %s. VLAN blocking is removed\n",
+		       slave_dev->name, bond_dev->name);
+		bond_dev->features &= ~NETIF_F_VLAN_CHALLENGED;
+	}
+
 	write_unlock_bh(&bond->lock);
 
+	bond_del_vlans_from_slave(bond, slave_dev);
+
 	/* If the mode USES_PRIMARY, then we should only remove its
 	 * promisc and mc settings if it was the curr_active_slave, but that was
 	 * already taken care of above when we detached the slave
@@ -1732,14 +2128,6 @@ static int bond_release(struct net_devic
 
 	kfree(slave);
 
-	/* if the last slave was removed, zero the mac address
-	 * of the master so it will be set by the application
-	 * to the mac address of the first slave
-	 */
-	if (bond->slave_cnt == 0) {
-		memset(bond_dev->dev_addr, 0, bond_dev->addr_len);
-	}
-
 	return 0;  /* deletion OK */
 }
 
@@ -1788,6 +2176,8 @@ static int bond_release_all(struct net_d
 		 */
 		write_unlock_bh(&bond->lock);
 
+		bond_del_vlans_from_slave(bond, slave_dev);
+
 		/* If the mode USES_PRIMARY, then we should only remove its
 		 * promisc and mc settings if it was the curr_active_slave, but that was
 		 * already taken care of above when we detached the slave
@@ -1838,6 +2228,18 @@ static int bond_release_all(struct net_d
 	 */
 	memset(bond_dev->dev_addr, 0, bond_dev->addr_len);
 
+	if (list_empty(&bond->vlan_list)) {
+		bond_dev->features |= NETIF_F_VLAN_CHALLENGED;
+	} else {
+		printk(KERN_WARNING DRV_NAME
+		       ": Warning: clearing HW address of %s while it "
+		       "still has VLANs.\n",
+		       bond_dev->name);
+		printk(KERN_WARNING DRV_NAME
+		       ": When re-adding slaves, make sure the bond's "
+		       "HW address matches its VLANs'.\n");
+	}
+
 	printk(KERN_INFO DRV_NAME
 	       ": %s: released all slaves\n",
 	       bond_dev->name);
@@ -3569,11 +3971,12 @@ static int bond_xmit_roundrobin(struct s
 	struct bonding *bond = bond_dev->priv;
 	struct slave *slave, *start_at;
 	int i;
+	int res = 1;
 
 	read_lock(&bond->lock);
 
 	if (!BOND_IS_OK(bond)) {
-		goto free_out;
+		goto out;
 	}
 
 	read_lock(&bond->curr_slave_lock);
@@ -3581,33 +3984,31 @@ static int bond_xmit_roundrobin(struct s
 	read_unlock(&bond->curr_slave_lock);
 
 	if (!slave) {
-		goto free_out;
+		goto out;
 	}
 
 	bond_for_each_slave_from(bond, slave, i, start_at) {
 		if (IS_UP(slave->dev) &&
 		    (slave->link == BOND_LINK_UP) &&
 		    (slave->state == BOND_STATE_ACTIVE)) {
-			skb->dev = slave->dev;
-			skb->priority = 1;
-			dev_queue_xmit(skb);
+			res = bond_dev_queue_xmit(bond, skb, slave->dev);
 
 			write_lock(&bond->curr_slave_lock);
 			bond->curr_active_slave = slave->next;
 			write_unlock(&bond->curr_slave_lock);
 
-			goto out;
+			break;
 		}
 	}
 
+
 out:
+	if (res) {
+		/* no suitable interface, frame not sent */
+		dev_kfree_skb(skb);
+	}
 	read_unlock(&bond->lock);
 	return 0;
-
-free_out:
-	/* no suitable interface, frame not sent */
-	dev_kfree_skb(skb);
-	goto out;
 }
 
 /*
@@ -3617,6 +4018,7 @@ free_out:
 static int bond_xmit_activebackup(struct sk_buff *skb, struct net_device *bond_dev)
 {
 	struct bonding *bond = bond_dev->priv;
+	int res = 1;
 
 	/* if we are sending arp packets, try to at least
 	   identify our own ip address */
@@ -3633,26 +4035,21 @@ static int bond_xmit_activebackup(struct
 	read_lock(&bond->curr_slave_lock);
 
 	if (!BOND_IS_OK(bond)) {
-		goto free_out;
+		goto out;
 	}
 
 	if (bond->curr_active_slave) { /* one usable interface */
-		skb->dev = bond->curr_active_slave->dev;
-		skb->priority = 1;
-		dev_queue_xmit(skb);
-		goto out;
-	} else {
-		goto free_out;
+		res = bond_dev_queue_xmit(bond, skb, bond->curr_active_slave->dev);
 	}
+
 out:
+	if (res) {
+		/* no suitable interface, frame not sent */
+		dev_kfree_skb(skb);
+	}
 	read_unlock(&bond->curr_slave_lock);
 	read_unlock(&bond->lock);
 	return 0;
-
-free_out:
-	/* no suitable interface, frame not sent */
-	dev_kfree_skb(skb);
-	goto out;
 }
 
 /*
@@ -3667,11 +4064,12 @@ static int bond_xmit_xor(struct sk_buff 
 	struct slave *slave, *start_at;
 	int slave_no;
 	int i;
+	int res = 1;
 
 	read_lock(&bond->lock);
 
 	if (!BOND_IS_OK(bond)) {
-		goto free_out;
+		goto out;
 	}
 
 	slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % bond->slave_cnt;
@@ -3689,22 +4087,18 @@ static int bond_xmit_xor(struct sk_buff 
 		if (IS_UP(slave->dev) &&
 		    (slave->link == BOND_LINK_UP) &&
 		    (slave->state == BOND_STATE_ACTIVE)) {
-			skb->dev = slave->dev;
-			skb->priority = 1;
-			dev_queue_xmit(skb);
-
-			goto out;
+			res = bond_dev_queue_xmit(bond, skb, slave->dev);
+			break;
 		}
 	}
 
 out:
+	if (res) {
+		/* no suitable interface, frame not sent */
+		dev_kfree_skb(skb);
+	}
 	read_unlock(&bond->lock);
 	return 0;
-
-free_out:
-	/* no suitable interface, frame not sent */
-	dev_kfree_skb(skb);
-	goto out;
 }
 
 /*
@@ -3716,11 +4110,12 @@ static int bond_xmit_broadcast(struct sk
 	struct slave *slave, *start_at;
 	struct net_device *tx_dev = NULL;
 	int i;
+	int res = 1;
 
 	read_lock(&bond->lock);
 
 	if (!BOND_IS_OK(bond)) {
-		goto free_out;
+		goto out;
 	}
 
 	read_lock(&bond->curr_slave_lock);
@@ -3728,7 +4123,7 @@ static int bond_xmit_broadcast(struct sk
 	read_unlock(&bond->curr_slave_lock);
 
 	if (!start_at) {
-		goto free_out;
+		goto out;
 	}
 
 	bond_for_each_slave_from(bond, slave, i, start_at) {
@@ -3744,31 +4139,28 @@ static int bond_xmit_broadcast(struct sk
 					continue;
 				}
 
-				skb2->dev = tx_dev;
-				skb2->priority = 1;
-				dev_queue_xmit(skb2);
+				res = bond_dev_queue_xmit(bond, skb2, tx_dev);
+				if (res) {
+					dev_kfree_skb(skb2);
+					continue;
+				}
 			}
 			tx_dev = slave->dev;
 		}
 	}
 
 	if (tx_dev) {
-		skb->dev = tx_dev;
-		skb->priority = 1;
-		dev_queue_xmit(skb);
-	} else {
-		goto free_out;
+		res = bond_dev_queue_xmit(bond, skb, tx_dev);
 	}
 
 out:
+	if (res) {
+		/* no suitable interface, frame not sent */
+		dev_kfree_skb(skb);
+	}
 	/* frame sent to all suitable interfaces */
 	read_unlock(&bond->lock);
 	return 0;
-
-free_out:
-	/* no suitable interface, frame not sent */
-	dev_kfree_skb(skb);
-	goto out;
 }
 
 #ifdef CONFIG_NET_FASTROUTE
@@ -3837,6 +4229,7 @@ static int __init bond_init(struct net_d
 	bond->current_arp_slave = NULL;
 	bond->primary_slave = NULL;
 	bond->dev = bond_dev;
+	INIT_LIST_HEAD(&bond->vlan_list);
 
 	/* Initialize the device entry points */
 	bond_dev->open = bond_open;
@@ -3858,6 +4251,25 @@ static int __init bond_init(struct net_d
 	bond_dev->tx_queue_len = 0;
 	bond_dev->flags |= IFF_MASTER|IFF_MULTICAST;
 
+	/* At first, we block adding VLANs. That's the only way to
+	 * prevent problems that occur when adding VLANs over an
+	 * empty bond. The block will be removed once non-challenged
+	 * slaves are enslaved.
+	 */
+	bond_dev->features |= NETIF_F_VLAN_CHALLENGED;
+
+	/* By default, we declare the bond to be fully
+	 * VLAN hardware accelerated capable. Special
+	 * care is taken in the various xmit functions
+	 * when there are slaves that are not hw accel
+	 * capable
+	 */
+	bond_dev->vlan_rx_register = bond_vlan_rx_register;
+	bond_dev->vlan_rx_add_vid  = bond_vlan_rx_add_vid;
+	bond_dev->vlan_rx_kill_vid = bond_vlan_rx_kill_vid;
+	bond_dev->features |= (NETIF_F_HW_VLAN_TX |
+			       NETIF_F_HW_VLAN_RX |
+			       NETIF_F_HW_VLAN_FILTER);
 
 #ifdef CONFIG_PROC_FS
 	bond_create_proc_entry(bond);
diff -Nuarp a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
--- a/drivers/net/bonding/bonding.h	Wed Jan 21 16:56:18 2004
+++ b/drivers/net/bonding/bonding.h	Wed Jan 21 16:56:19 2004
@@ -147,6 +147,11 @@ struct bond_params {
 	u32 arp_targets[BOND_MAX_ARP_TARGETS];
 };
 
+struct vlan_entry {
+	struct list_head vlan_list;
+	unsigned short vlan_id;
+};
+
 struct slave {
 	struct net_device *dev; /* first - usefull for panic debug */
 	struct slave *next;
@@ -196,6 +201,8 @@ struct bonding {
 	struct   ad_bond_info ad_info;
 	struct   alb_bond_info alb_info;
 	struct   bond_params params;
+	struct   list_head vlan_list;
+	struct   vlan_group *vlgrp;
 };
 
 /**
@@ -238,5 +245,7 @@ extern inline void bond_set_slave_active
 	slave->dev->flags &= ~IFF_NOARP;
 }
 
+int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev);
+
 #endif /* _LINUX_BONDING_H */
 


From shmulik.hen@intel.com Sun Feb  8 08:11:30 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 08:11:38 -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 i18GBTKO008870
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 08:11:29 -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 i18GD6Eu016634;
	Sun, 8 Feb 2004 16:13:06 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124])
	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 i18GBEZ8009652;
	Sun, 8 Feb 2004 16:11:14 GMT
Received: from jrslxjul4.npdj.intel.com ([10.12.220.54])
 by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020808112224083
 ; Sun, 08 Feb 2004 08:11:23 -0800
From: Shmuel Hen <shmulik.hen@intel.com>
Organization: Intel Corporation
To: "Jeff Garzik" <jgarzik@pobox.com>
Subject: [PATCH 2/3][bonding][2.6] Add VLAN support in TLB mode
Date: Sun, 8 Feb 2004 18:11:19 +0200
User-Agent: KMail/1.5.3
Cc: "linux-netdev" <netdev@oss.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200402081811.21053.shmulik.hen@intel.com>
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-archive-position: 3108
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: 5503
Lines: 179

Add capability to tag self generated learning packets that are 
required to speed up port selection in the switch after a fail 
over in bonding since some switches will only update their MAC 
tables from tagged packets when VLAN support is turned on. All 
VLAN Id's that have been configured on top of the bond interface 
will be used in cyclic order. 

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


diff -Nuarp a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
--- a/drivers/net/bonding/bond_alb.c	Wed Jan 21 16:56:22 2004
+++ b/drivers/net/bonding/bond_alb.c	Wed Jan 21 16:56:24 2004
@@ -50,6 +50,7 @@
 #include <linux/if_arp.h>
 #include <linux/if_ether.h>
 #include <linux/if_bonding.h>
+#include <linux/if_vlan.h>
 #include <net/ipx.h>
 #include <net/arp.h>
 #include <asm/byteorder.h>
@@ -79,7 +80,7 @@
 
 
 #define TLB_NULL_INDEX		0xffffffff
-#define MAX_LP_RETRY		3
+#define MAX_LP_BURST		3
 
 /* rlb defs */
 #define RLB_HASH_TABLE_SIZE	256
@@ -816,6 +817,7 @@ static void rlb_deinitialize(struct bond
 
 static void alb_send_learning_packets(struct slave *slave, u8 mac_addr[])
 {
+	struct bonding *bond = bond_get_bond_by_slave(slave);
 	struct learning_pkt pkt;
 	int size = sizeof(struct learning_pkt);
 	int i;
@@ -825,7 +827,7 @@ static void alb_send_learning_packets(st
 	memcpy(pkt.mac_src, mac_addr, ETH_ALEN);
 	pkt.type = __constant_htons(ETH_P_LOOP);
 
-	for (i = 0; i < MAX_LP_RETRY; i++) {
+	for (i = 0; i < MAX_LP_BURST; i++) {
 		struct sk_buff *skb;
 		char *data;
 
@@ -843,6 +845,26 @@ static void alb_send_learning_packets(st
 		skb->priority = TC_PRIO_CONTROL;
 		skb->dev = slave->dev;
 
+		if (!list_empty(&bond->vlan_list)) {
+			struct vlan_entry *vlan;
+
+			vlan = bond_next_vlan(bond,
+					      bond->alb_info.current_alb_vlan);
+
+			bond->alb_info.current_alb_vlan = vlan;
+			if (!vlan) {
+				kfree_skb(skb);
+				continue;
+			}
+
+			skb = vlan_put_tag(skb, vlan->vlan_id);
+			if (!skb) {
+				printk(KERN_ERR DRV_NAME
+				       ": Error: failed to insert VLAN tag\n");
+				continue;
+			}
+		}
+
 		dev_queue_xmit(skb);
 	}
 }
@@ -1588,3 +1610,11 @@ int bond_alb_set_mac_address(struct net_
 	return 0;
 }
 
+void bond_alb_clear_vlan(struct bonding *bond, unsigned short vlan_id)
+{
+	if (bond->alb_info.current_alb_vlan &&
+	    (bond->alb_info.current_alb_vlan->vlan_id == vlan_id)) {
+		bond->alb_info.current_alb_vlan = NULL;
+	}
+}
+
diff -Nuarp a/drivers/net/bonding/bond_alb.h b/drivers/net/bonding/bond_alb.h
--- a/drivers/net/bonding/bond_alb.h	Wed Jan 21 16:56:22 2004
+++ b/drivers/net/bonding/bond_alb.h	Wed Jan 21 16:56:24 2004
@@ -122,6 +122,7 @@ struct alb_bond_info {
 						 * rx traffic should be
 						 * rebalanced
 						 */
+	struct vlan_entry	*current_alb_vlan;
 };
 
 int bond_alb_initialize(struct bonding *bond, int rlb_enabled);
@@ -133,6 +134,6 @@ void bond_alb_handle_active_change(struc
 int bond_alb_xmit(struct sk_buff *skb, struct net_device *bond_dev);
 void bond_alb_monitor(struct bonding *bond);
 int bond_alb_set_mac_address(struct net_device *bond_dev, void *addr);
-
+void bond_alb_clear_vlan(struct bonding *bond, unsigned short vlan_id);
 #endif /* __BOND_ALB_H__ */
 
diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
--- a/drivers/net/bonding/bond_main.c	Wed Jan 21 16:56:22 2004
+++ b/drivers/net/bonding/bond_main.c	Wed Jan 21 16:56:24 2004
@@ -676,6 +676,11 @@ static int bond_del_vlan(struct bonding 
 		if (vlan->vlan_id == vlan_id) {
 			list_del(&vlan->vlan_list);
 
+			if ((bond->params.mode == BOND_MODE_TLB) ||
+			    (bond->params.mode == BOND_MODE_ALB)) {
+				bond_alb_clear_vlan(bond, vlan_id);
+			}
+
 			dprintk("removed VLAN ID %d from bond %s\n", vlan_id,
 				bond->dev->name);
 
@@ -731,6 +736,42 @@ static int bond_has_challenged_slaves(st
 }
 
 /**
+ * bond_next_vlan - safely skip to the next item in the vlans list.
+ * @bond: the bond we're working on
+ * @curr: item we're advancing from
+ *
+ * Returns %NULL if list is empty, bond->next_vlan if @curr is %NULL,
+ * or @curr->next otherwise (even if it is @curr itself again).
+ * 
+ * Caller must hold bond->lock
+ */
+struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr)
+{
+	struct vlan_entry *next, *last;
+
+	if (list_empty(&bond->vlan_list)) {
+		return NULL;
+	}
+
+	if (!curr) {
+		next = list_entry(bond->vlan_list.next,
+				  struct vlan_entry, vlan_list);
+	} else {
+		last = list_entry(bond->vlan_list.prev,
+				  struct vlan_entry, vlan_list);
+		if (last == curr) {
+			next = list_entry(bond->vlan_list.next,
+					  struct vlan_entry, vlan_list);
+		} else {
+			next = list_entry(curr->vlan_list.next,
+					  struct vlan_entry, vlan_list);
+		}
+	}
+
+	return next;
+}
+
+/**
  * bond_dev_queue_xmit - Prepare skb for xmit.
  * 
  * @bond: bond device that got this skb for tx.
diff -Nuarp a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
--- a/drivers/net/bonding/bonding.h	Wed Jan 21 16:56:22 2004
+++ b/drivers/net/bonding/bonding.h	Wed Jan 21 16:56:24 2004
@@ -245,6 +245,7 @@ extern inline void bond_set_slave_active
 	slave->dev->flags &= ~IFF_NOARP;
 }
 
+struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr);
 int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev);
 
 #endif /* _LINUX_BONDING_H */


From sri@us.ibm.com Sun Feb  8 09:08:02 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 09:08:08 -0800 (PST)
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i18H7tKO013835
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 09:08:02 -0800
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i18H7ntB613146;
	Sun, 8 Feb 2004 12:07:49 -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 i18H7mt1133928;
	Sun, 8 Feb 2004 12:07:49 -0500
Date: Sun, 8 Feb 2004 09:07:48 -0800 (PST)
From: Sridhar Samudrala <sri@us.ibm.com>
X-X-Sender: sridhar@localhost.localdomain
To: "David S. Miller" <davem@redhat.com>
cc: netdev@oss.sgi.com
Subject: Re: [BK PATCH] 2.6.2 SCTP updates
In-Reply-To: <20040206194518.56787717.davem@redhat.com>
Message-ID: <Pine.LNX.4.58.0402080900450.25152@localhost.localdomain>
References: <Pine.LNX.4.58.0402061649001.10831@localhost.localdomain>
 <20040206194518.56787717.davem@redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 3110
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: 929
Lines: 29

On Fri, 6 Feb 2004, David S. Miller wrote:

> On Fri, 6 Feb 2004 17:24:32 -0800 (PST)
> Sridhar Samudrala <sri@us.ibm.com> wrote:
>
> > Please do a
> > 	bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work
> > to get the following udpates to SCTP on top of linux 2.6.2
>
> Pulled, but.
>
> > - Updated the default max socket receive buffer to 64K from 32K and also
> >   added sysctl variables to change sctp socket send/receive buffers.
>
> Why do you use specialized SCTP rmem/wmem values and not the globally
> sysctl's ones we have for sockets already?

Dave,

I guess i was influenced by the TCP specific tcp_rmem/tcp_wmem. But TCP
seems to be using them as a vector of 3 values and tuning the buffer sizes
dynamically based on these values.
As of now, SCTP doesn't do any tuning dynamically so i could have used the
core rmem_default/wmem_default.

Do you want me to remove the specialized SCTP sysctl's?

Thanks
Sridhar

From davem@redhat.com Sun Feb  8 10:39:39 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 10:39: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 i18IdcKO016200
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 10:39: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 i18Idbb02319;
	Sun, 8 Feb 2004 13:39: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 i18Idaa21707;
	Sun, 8 Feb 2004 13:39:36 -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 i18IcokC002134;
	Sun, 8 Feb 2004 13:39:04 -0500
Date: Sun, 8 Feb 2004 10:39:21 -0800
From: "David S. Miller" <davem@redhat.com>
To: Sridhar Samudrala <sri@us.ibm.com>
Cc: netdev@oss.sgi.com
Subject: Re: [BK PATCH] 2.6.2 SCTP updates
Message-Id: <20040208103921.68614451.davem@redhat.com>
In-Reply-To: <Pine.LNX.4.58.0402080900450.25152@localhost.localdomain>
References: <Pine.LNX.4.58.0402061649001.10831@localhost.localdomain>
	<20040206194518.56787717.davem@redhat.com>
	<Pine.LNX.4.58.0402080900450.25152@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: 3111
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: 530
Lines: 13

On Sun, 8 Feb 2004 09:07:48 -0800 (PST)
Sridhar Samudrala <sri@us.ibm.com> wrote:

> I guess i was influenced by the TCP specific tcp_rmem/tcp_wmem. But TCP
> seems to be using them as a vector of 3 values and tuning the buffer sizes
> dynamically based on these values.
> As of now, SCTP doesn't do any tuning dynamically so i could have used the
> core rmem_default/wmem_default.
> 
> Do you want me to remove the specialized SCTP sysctl's?

It seems as duplication if there is no specific need to have seperate
controls right?

From ja@ssi.bg Sun Feb  8 12:41:32 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 12:41:38 -0800 (PST)
Received: from u.domain.uli (ja.mac.ssi.bg [217.79.71.194])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i18KfSKO026566
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 12:41:30 -0800
Received: from localhost (localhost [127.0.0.1])
	by u.domain.uli (8.12.10/8.12.10) with ESMTP id i18Ki5xC025767;
	Sun, 8 Feb 2004 22:44:05 +0200
Date: Sun, 8 Feb 2004 22:44:05 +0200 (EET)
From: Julian Anastasov <ja@ssi.bg>
X-X-Sender: ja@u.domain.uli
To: netdev@oss.sgi.com
cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Subject: Change proxy_arp to respond only for valid neighbours
Message-ID: <Pine.LNX.4.58.0402082234110.6268@u.domain.uli>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 3113
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: ja@ssi.bg
Precedence: bulk
X-list: netdev
Content-Length: 2790
Lines: 98


	Hello,

	Appended is a patch that modifies proxy_arp to check
the target's neighbour state before reporting any information
to requestors. The benefit is that the availability of the target
host is properly reported to the requestor, we prefer not to send
replies when target is unreachable. The changes:

- now pneigh_lookup has more priority compared to arp_fwd_proxy

- neigh_event_ns is called only once per request, not twice

- the 'skb->pkt_type == PACKET_HOST' check has no semantic anymore,
the requestor should have same information no matter the packet
type. In all cases we add response delay for all requests, broadcast
or unicast, to help other authoritative hosts to reply before us.

- the RTCF_DNAT case is not delayed anymore (may be it is not used
anymore, IIRC)

Remaining questions:

- do we need to delay the pneigh_lookup case? Now it is still delayed
as before.

Comments?

Regards

--
Julian Anastasov <ja@ssi.bg>

diff -ur v2.6.2/linux/net/ipv4/arp.c linux/net/ipv4/arp.c
--- v2.6.2/linux/net/ipv4/arp.c	2004-02-05 00:23:18.000000000 +0200
+++ linux/net/ipv4/arp.c	2004-02-08 21:06:49.843123528 +0200
@@ -758,24 +758,36 @@
 			}
 			goto out;
 		} else if (IN_DEV_FORWARD(in_dev)) {
+			int fwd_proxy = 0, delay = 0;
+
 			if ((rt->rt_flags&RTCF_DNAT) ||
 			    (addr_type == RTN_UNICAST  && rt->u.dst.dev != dev &&
-			     (arp_fwd_proxy(in_dev, rt) || pneigh_lookup(&arp_tbl, &tip, dev, 0)))) {
-				n = neigh_event_ns(&arp_tbl, sha, &sip, dev);
-				if (n)
-					neigh_release(n);
-
-				if (skb->stamp.tv_sec == 0 ||
-				    skb->pkt_type == PACKET_HOST ||
-				    in_dev->arp_parms->proxy_delay == 0) {
-					arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev->dev_addr,sha);
-				} else {
-					pneigh_enqueue(&arp_tbl, in_dev->arp_parms, skb);
-					in_dev_put(in_dev);
-					return 0;
-				}
+			     ((delay = in_dev->arp_parms->proxy_delay,
+			       pneigh_lookup(&arp_tbl, &tip, dev, 0)) ||
+			      (fwd_proxy = arp_fwd_proxy(in_dev, rt))))) {
+
+				if (skb->stamp.tv_sec) {
+					n = neigh_event_ns(&arp_tbl, sha, &sip, dev);
+					if (n)
+						neigh_release(n);
+					if ((fwd_proxy &&
+					    (n = rt->u.dst.neighbour) &&
+					    /* We need the actual state ASAP */
+					    neigh_event_send(n, NULL)) || delay) {
+						if (delay) {
+							pneigh_enqueue(&arp_tbl, in_dev->arp_parms, skb);
+							skb = NULL;
+						}
+						goto out;
+					}
+				} else if (fwd_proxy && (n = rt->u.dst.neighbour) &&
+					   !neigh_is_valid(n))
+					goto out;
+
+				arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev->dev_addr,sha);
+				goto out;
+			} else if (!skb->stamp.tv_sec)
 				goto out;
-			}
 		}
 	}
 
@@ -819,7 +831,8 @@
 out:
 	if (in_dev)
 		in_dev_put(in_dev);
-	kfree_skb(skb);
+	if (skb)
+		kfree_skb(skb);
 	return 0;
 }
 

From davem@redhat.com Sun Feb  8 12:43:30 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 12:43:36 -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 i18KhUKO027176
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 12:43:30 -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 i18KhRb11890;
	Sun, 8 Feb 2004 15:43:27 -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 i18KhRa19373;
	Sun, 8 Feb 2004 15:43:27 -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 i18KgskC006460;
	Sun, 8 Feb 2004 15:42:54 -0500
Date: Sun, 8 Feb 2004 12:43:26 -0800
From: "David S. Miller" <davem@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH][RFC] use completions instead of sleep_on for rpciod
Message-Id: <20040208124326.2381b974.davem@redhat.com>
In-Reply-To: <20040207144405.GA19416@lst.de>
References: <20040207144405.GA19416@lst.de>
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: 3114
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: 664
Lines: 16

On Sat, 7 Feb 2004 15:44:05 +0100
Christoph Hellwig <hch@lst.de> wrote:

> The rpciod shutdown code gives ugly sleep_on without BKL warnings in
> -mm.  And it looks indeed somewhat racy.
> 
> The easy fix would be to simply use a completion as in the patch below,
> but that removes all the signal fuzzing semantics the current code has.
> I don't really understand why we want to cancel the operation by
> signals, but I think it'd be better to leave that to people familar with
> the code anyway..

I think your patch is fine, and there are no signal issues (such code looks
merely to be some abberation rather than anything else).

So I've added it to my tree.

From davem@redhat.com Sun Feb  8 12:45:33 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 12:45:37 -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 i18KjVKO027554
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 12:45:33 -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 i18KjTb12729;
	Sun, 8 Feb 2004 15:45:29 -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 i18KjTa19922;
	Sun, 8 Feb 2004 15:45:29 -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 i18KiukC007087;
	Sun, 8 Feb 2004 15:44:57 -0500
Date: Sun, 8 Feb 2004 12:45:28 -0800
From: "David S. Miller" <davem@redhat.com>
To: Gandalf The White <gandalf@digital.net>
Cc: netdev@oss.sgi.com
Subject: Re: Fragmentation Attack
Message-Id: <20040208124528.2c667378.davem@redhat.com>
In-Reply-To: <BC4A83EB.E263%gandalf@digital.net>
References: <20040207094524.495e883d.davem@redhat.com>
	<BC4A83EB.E263%gandalf@digital.net>
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: 3115
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: 814
Lines: 17

On Sat, 07 Feb 2004 12:00:42 -0600
Gandalf The White <gandalf@digital.net> wrote:

> The requirements of the attack (from the perspective of the paper I wrote)
> was that you had taken over 20 cable modem computers.  From this viewpoint
> this could (of course) produce the required number of packets IMHO.
>
> Of course you could also clog up the bandwidth of just about any destination
> network with this requirement, but that is a different DoS.

Yes, but this very fact makes the "DoS" much much less interesting.
If I can clog your link anyways with arbitrary traffic, who cares
what it does as a second order effect, the machine is made unreachable
and unusable either way.

Also, these half-complete ICMP packets are really super easy to create
firewall rules for to block them at ingress of a major site.

From davem@redhat.com Sun Feb  8 12:58:25 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 12:58:28 -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 i18KwOKO028020
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 12:58:25 -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 i18KwJb17234;
	Sun, 8 Feb 2004 15:58:19 -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 i18KwJa23200;
	Sun, 8 Feb 2004 15:58:19 -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 i18KvkkC011106;
	Sun, 8 Feb 2004 15:57:47 -0500
Date: Sun, 8 Feb 2004 12:58:18 -0800
From: "David S. Miller" <davem@redhat.com>
To: yoshfuji@linux-ipv6.org
Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com
Subject: Re: [RFC,PATCH] remove IPV6_AUTHHDR socket option / ancillary data
Message-Id: <20040208125818.02eba2f5.davem@redhat.com>
In-Reply-To: <20040208.141117.116936870.yoshfuji@linux-ipv6.org>
References: <20040208.141117.116936870.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 i18KwOKO028020
X-archive-position: 3116
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: 664
Lines: 21

On Sun, 08 Feb 2004 14:11:17 +0900 (JST)
YOSHIFUJI Hideaki / $B5HF#1QL@(B <yoshfuji@linux-ipv6.org> wrote:

> AH is now handled by the XFRM engine.
> IPV6_AUTHHDR socket option / ancillary data are deprecated.
> 
> For sender side, it is very difficult (or even almost impossible) to
> create "correct" AH in userspace.
> For receiver side, none set opt->auth and user space application
> never get authentication data.
> 
> IPV6_AUTHHDR is very Linux-specific and applications which use
> these feature are not portable at all.

I totally agree, I didn't even know this broken thing existed
to be honest.

Let's kill this now.

Patch applied, thanks Yoshfuji.


From davem@redhat.com Sun Feb  8 13:03:10 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 13:03:14 -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 i18L39KO028439
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 13:03:10 -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 i18L36b18946;
	Sun, 8 Feb 2004 16:03:06 -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 i18L35a24383;
	Sun, 8 Feb 2004 16:03:06 -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 i18L2XkC012727;
	Sun, 8 Feb 2004 16:02:33 -0500
Date: Sun, 8 Feb 2004 13:03:04 -0800
From: "David S. Miller" <davem@redhat.com>
To: yoshfuji@linux-ipv6.org
Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com
Subject: Re: [Q] LL_RESERVED_SPACE(dev) vs
 HH_DATA_ALIGN(dev->hard_header_len)
Message-Id: <20040208130304.5df8e2c3.davem@redhat.com>
In-Reply-To: <20040208.203930.36073978.yoshfuji@linux-ipv6.org>
References: <20040208.203930.36073978.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 i18L39KO028439
X-archive-position: 3117
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: 1356
Lines: 40

On Sun, 08 Feb 2004 20:39:30 +0900 (JST)
YOSHIFUJI Hideaki / $B5HF#1QL@(B <yoshfuji@linux-ipv6.org> wrote:

> Question: 
>   How do you think about the following patch?
>   Or, is it okay to simply use LL_RESERVED_SPACE(dev) in both places?

LL_RESERVED_SPACE() is what should be used in both spots.

I checked in the following patch, thanks for noticing this.

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/02/08 12:58:29-08:00 davem@nuts.davemloft.net 
#   [ECONET]: Use LL_RESERVED_SPACE() where applicable.  Noticed by yoshfuji.
# 
# net/econet/af_econet.c
#   2004/02/08 12:58:13-08:00 davem@nuts.davemloft.net +2 -2
#   [ECONET]: Use LL_RESERVED_SPACE() where applicable.  Noticed by yoshfuji.
# 
diff -Nru a/net/econet/af_econet.c b/net/econet/af_econet.c
--- a/net/econet/af_econet.c	Sun Feb  8 12:59:08 2004
+++ b/net/econet/af_econet.c	Sun Feb  8 12:59:08 2004
@@ -318,12 +318,12 @@
 #ifdef CONFIG_ECONET_NATIVE
 		dev_hold(dev);
 		
-		skb = sock_alloc_send_skb(sk, len+dev->hard_header_len+15, 
+		skb = sock_alloc_send_skb(sk, len+LL_RESERVED_SPACE(dev), 
 					  msg->msg_flags & MSG_DONTWAIT, &err);
 		if (skb==NULL)
 			goto out_unlock;
 		
-		skb_reserve(skb, (dev->hard_header_len+15)&~15);
+		skb_reserve(skb, LL_RESERVED_SPACE(dev));
 		skb->nh.raw = skb->data;
 		
 		eb = (struct ec_cb *)&skb->cb;


From davem@redhat.com Sun Feb  8 13:07:04 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 13:07:08 -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 i18L74KO028855
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 13:07: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 i18L71b20293;
	Sun, 8 Feb 2004 16:07:01 -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 i18L71a25328;
	Sun, 8 Feb 2004 16:07:01 -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 i18L6SkC013825;
	Sun, 8 Feb 2004 16:06:29 -0500
Date: Sun, 8 Feb 2004 13:07:00 -0800
From: "David S. Miller" <davem@redhat.com>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH] af_unix: Fix path of /proc/net/unix
Message-Id: <20040208130700.4e225134.davem@redhat.com>
In-Reply-To: <878yjf2wx7.fsf@devron.myhome.or.jp>
References: <878yjf2wx7.fsf@devron.myhome.or.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=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 3118
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: 331
Lines: 10

On Sat, 07 Feb 2004 16:03:48 +0900
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote:

> We should overwrite the first "nul" by "@" in the case of abstract
> path, otherwise currently "netstat -x" can't print, at least.  And
> normal one, odd "nul" was added.
> 
> This patch does behavior of 2.4. Please apply.

Applied, thanks.

From davem@redhat.com Sun Feb  8 13:08:19 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 13:08:23 -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 i18L8JKO029218
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 13:08:19 -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 i18L8Cb20586;
	Sun, 8 Feb 2004 16:08:12 -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 i18L8Ca25552;
	Sun, 8 Feb 2004 16:08:12 -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 i18L7dkC014217;
	Sun, 8 Feb 2004 16:07:40 -0500
Date: Sun, 8 Feb 2004 13:08:11 -0800
From: "David S. Miller" <davem@redhat.com>
To: Kazunori Miyazawa <kazunori@miyazawa.org>
Cc: yoshfuji@linux-ipv6.org, mika.penttila@kolumbus.fi, netdev@oss.sgi.com,
        usagi-core@linux-ipv6.org
Subject: Re: [PATCH][IPV6][NDISC] unify ipv6 output routine
Message-Id: <20040208130811.328225e7.davem@redhat.com>
In-Reply-To: <200402071333.51909.kazunori@miyazawa.org>
References: <200402070232.33771.kazunori@miyazawa.org>
	<4023D6FB.9010909@kolumbus.fi>
	<20040207.131455.27570445.yoshfuji@linux-ipv6.org>
	<200402071333.51909.kazunori@miyazawa.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=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 3119
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: 71
Lines: 3


Is a fixed version of this output path unification patch
coming soon?

From gandalf@digital.net Sun Feb  8 13:12:42 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 13:12:48 -0800 (PST)
Received: from lakemtao07.cox.net (lakemtao07.cox.net [68.1.17.114])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i18LCfKO029628
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 13:12:42 -0800
Received: from [192.168.1.94] ([68.13.240.115]) by lakemtao07.cox.net
          (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
          id <20040208211236.KJMJ2432.lakemtao07.cox.net@[192.168.1.94]>;
          Sun, 8 Feb 2004 16:12:36 -0500
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Sun, 08 Feb 2004 15:12:36 -0600
Subject: Re: Fragmentation Attack
From: Gandalf The White <gandalf@digital.net>
To: "David S. Miller" <davem@redhat.com>
CC: Linux IPStack <netdev@oss.sgi.com>
Message-ID: <BC4C0264.E3F3%gandalf@digital.net>
In-Reply-To: <20040208124528.2c667378.davem@redhat.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-archive-position: 3120
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: gandalf@digital.net
Precedence: bulk
X-list: netdev
Content-Length: 2166
Lines: 45

Greetings and Salutations:

On 2/8/04 2:45 PM, "David S. Miller" <davem@redhat.com> wrote:
> On Sat, 07 Feb 2004 12:00:42 -0600
> Gandalf The White <gandalf@digital.net> wrote:
>> The requirements of the attack (from the perspective of the paper I wrote)
>> was that you had taken over 20 cable modem computers.  From this viewpoint
>> this could (of course) produce the required number of packets IMHO.
>> 
>> Of course you could also clog up the bandwidth of just about any destination
>> network with this requirement, but that is a different DoS.
> Yes, but this very fact makes the "DoS" much much less interesting.
> If I can clog your link anyways with arbitrary traffic, who cares
> what it does as a second order effect, the machine is made unreachable
> and unusable either way.

Exactly.  So I was discounting the "clog your connection" attack.  What I
was looking at is if someone has a fast machine that they can send a
regulated amount of packets to and test out the fragment attack that would
be good.  I suspect that this attack would still spike the CPU on a machine
at a relatively low (a few hundred) packets per second rate.  On a web
server or other Internet Facing machine that has a decent load this could be
enough CPU overhead to create a DoS.

> Also, these half-complete ICMP packets are really super easy to create
> firewall rules for to block them at ingress of a major site.

The attack has ICMP, UDP and TCP.  If you were seeing a specific signature
over and over again then I agree that it might be easy to block (depending
on the firewall) ... But ... If someone were sending fragments destined for
port 80 to your web server I don't see how you could differentiate between
"real" fragments going to the web server and faked fragmentation requests.


Ken

---------------------------------------------------------------
Do not meddle in the affairs of wizards for they are subtle and
quick to anger.
Ken Hollis - Gandalf The White - gandalf@digital.net - O- TINLC
WWW Page - http://digital.net/~gandalf/
Trace E-Mail forgery - http://digital.net/~gandalf/spamfaq.html
Trolls crossposts - http://digital.net/~gandalf/trollfaq.html



From davem@redhat.com Sun Feb  8 13:14:25 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 13:14:29 -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 i18LEPKO030079
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 13:14:25 -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 i18LEIb22290;
	Sun, 8 Feb 2004 16:14:18 -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 i18LEIa26540;
	Sun, 8 Feb 2004 16:14:18 -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 i18LDjkC015752;
	Sun, 8 Feb 2004 16:13:45 -0500
Date: Sun, 8 Feb 2004 13:14:17 -0800
From: "David S. Miller" <davem@redhat.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru
Subject: Re: Change proxy_arp to respond only for valid neighbours
Message-Id: <20040208131417.4f8693de.davem@redhat.com>
In-Reply-To: <Pine.LNX.4.58.0402082234110.6268@u.domain.uli>
References: <Pine.LNX.4.58.0402082234110.6268@u.domain.uli>
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: 3121
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: 391
Lines: 13

On Sun, 8 Feb 2004 22:44:05 +0200 (EET)
Julian Anastasov <ja@ssi.bg> wrote:

> Comments?

This is a dicey situation in that when the entry does become
valid this does not trigger a proxy arp by us, does it?

I guess the original requestor will redo the request, so I'm
just mentioning this in passing.  This is an area where admittedly
I'm not well versed.

So proxy ARP experts speak up :)

From davem@redhat.com Sun Feb  8 13:18:28 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 13:18:32 -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 i18LIRKO030743
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 13:18:28 -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 i18LIRb23539;
	Sun, 8 Feb 2004 16:18:27 -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 i18LIRa27374;
	Sun, 8 Feb 2004 16:18:27 -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 i18LHskC017051;
	Sun, 8 Feb 2004 16:17:54 -0500
Date: Sun, 8 Feb 2004 13:18:26 -0800
From: "David S. Miller" <davem@redhat.com>
To: Gandalf The White <gandalf@digital.net>
Cc: netdev@oss.sgi.com
Subject: Re: Fragmentation Attack
Message-Id: <20040208131826.104eaef4.davem@redhat.com>
In-Reply-To: <BC4C0264.E3F3%gandalf@digital.net>
References: <20040208124528.2c667378.davem@redhat.com>
	<BC4C0264.E3F3%gandalf@digital.net>
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: 3122
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: 1216
Lines: 24

On Sun, 08 Feb 2004 15:12:36 -0600
Gandalf The White <gandalf@digital.net> wrote:

> The attack has ICMP, UDP and TCP.  If you were seeing a specific signature
> over and over again then I agree that it might be easy to block (depending
> on the firewall) ... But ... If someone were sending fragments destined for
> port 80 to your web server I don't see how you could differentiate between
> "real" fragments going to the web server and faked fragmentation requests.

In this day and age, and with all the headaches fragmentation causes
(either directly or indirectly via these resource consumption DoS's)
we may soon be reaching the point where only talking to sites doing
path-MTU discovery (yes, even for UDP) is a valid decision for a big
site.

This would solve the problem in a hurry.

For TCP I think people can do this today.  For UDP, what do you need fragmented
UDP for, DNS queries?  I think not for those types of usage, and even streaming
voice or whatever UDP uses chop up the datastream themselves spitting out a
non-fragmented time transmitted line of packets looking sort of ATM'ish.

Fragmented ICMP should just be blocked at firewall for people concerned about
this, I see no valid use of this.

From yoshfuji@linux-ipv6.org Sun Feb  8 13:25:16 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 13:25:22 -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 i18LPGKO031232
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 13:25:16 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 9A7AC33CA5; Mon,  9 Feb 2004 06:26:10 +0900 (JST)
Date: Mon, 09 Feb 2004 06:26:09 +0900 (JST)
Message-Id: <20040209.062609.55856700.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: kazunori@miyazawa.org, mika.penttila@kolumbus.fi, netdev@oss.sgi.com,
        usagi-core@linux-ipv6.org
Subject: Re: [PATCH][IPV6][NDISC] unify ipv6 output routine
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= <yoshfuji@linux-ipv6.org>
In-Reply-To: <20040208130811.328225e7.davem@redhat.com>
References: <20040207.131455.27570445.yoshfuji@linux-ipv6.org>
	<200402071333.51909.kazunori@miyazawa.org>
	<20040208130811.328225e7.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: 3123
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: 385
Lines: 11

In article <20040208130811.328225e7.davem@redhat.com> (at Sun, 8 Feb 2004 13:08:11 -0800), "David S. Miller" <davem@redhat.com> says:

> 
> Is a fixed version of this output path unification patch
> coming soon?

No. The second patch from Miyazawa-san is fine.

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

From ja@ssi.bg Sun Feb  8 13:35:34 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 13:35:37 -0800 (PST)
Received: from u.domain.uli (ja.mac.ssi.bg [217.79.71.194])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i18LZSKO031676
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 13:35:32 -0800
Received: from localhost (localhost [127.0.0.1])
	by u.domain.uli (8.12.10/8.12.10) with ESMTP id i18LcCxC025921;
	Sun, 8 Feb 2004 23:38:14 +0200
Date: Sun, 8 Feb 2004 23:38:12 +0200 (EET)
From: Julian Anastasov <ja@ssi.bg>
X-X-Sender: ja@u.domain.uli
To: "David S. Miller" <davem@redhat.com>
cc: netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru
Subject: Re: Change proxy_arp to respond only for valid neighbours
In-Reply-To: <20040208131417.4f8693de.davem@redhat.com>
Message-ID: <Pine.LNX.4.58.0402082322140.6268@u.domain.uli>
References: <Pine.LNX.4.58.0402082234110.6268@u.domain.uli>
 <20040208131417.4f8693de.davem@redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 3124
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: ja@ssi.bg
Precedence: bulk
X-list: netdev
Content-Length: 972
Lines: 32


	Hello,

On Sun, 8 Feb 2004, David S. Miller wrote:

> This is a dicey situation in that when the entry does become
> valid this does not trigger a proxy arp by us, does it?

	Yes, currently it works in this way, when target
replies we do not propagate this answer to the proxy_queue.
But this is not fatal becuase we apply delay in the answer
which means we have time to resolve the target. If we do not
have answer in that time we simply drop the skb from proxy_queue.
The requestor can send next requests and we reply each that
request only if the target is in valid state.

> I guess the original requestor will redo the request, so I'm

	Yes, the skbs from proxy_queue are removed in time, they
do not stay there until we have answer for them.

> just mentioning this in passing.  This is an area where admittedly
> I'm not well versed.
>
> So proxy ARP experts speak up :)

	Yep, lets see what Alexey and other gurus think

Regards

--
Julian Anastasov <ja@ssi.bg>

From ja@ssi.bg Sun Feb  8 14:41:52 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 14:41:55 -0800 (PST)
Received: from u.domain.uli (ja.mac.ssi.bg [217.79.71.194])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i18MfjKO002966
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 14:41:49 -0800
Received: from localhost (localhost [127.0.0.1])
	by u.domain.uli (8.12.10/8.12.10) with ESMTP id i18MiQxC026197;
	Mon, 9 Feb 2004 00:44:29 +0200
Date: Mon, 9 Feb 2004 00:44:26 +0200 (EET)
From: Julian Anastasov <ja@ssi.bg>
X-X-Sender: ja@u.domain.uli
To: "David S. Miller" <davem@redhat.com>
cc: netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru
Subject: Re: Change proxy_arp to respond only for valid neighbours
In-Reply-To: <20040208131417.4f8693de.davem@redhat.com>
Message-ID: <Pine.LNX.4.58.0402090036330.6268@u.domain.uli>
References: <Pine.LNX.4.58.0402082234110.6268@u.domain.uli>
 <20040208131417.4f8693de.davem@redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 3125
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: ja@ssi.bg
Precedence: bulk
X-list: netdev
Content-Length: 321
Lines: 18


	Hello,

On Sun, 8 Feb 2004, David S. Miller wrote:

> So proxy ARP experts speak up :)

	I found that it is better not to delay answers to unicast
probes. In case I change other things, I'll keep latest version of this 
patch here:

http://www.ssi.bg/~ja/tmp/
arp_proxy-*.diff

Regards

--
Julian Anastasov <ja@ssi.bg>

From schwab@suse.de Sun Feb  8 17:34:40 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 17:34:49 -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 i191YSKO013794
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 17:34:29 -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 9D1B9181006; Mon,  9 Feb 2004 01:50:53 +0100 (CET)
Received: by sykes.suse.de (Postfix, from userid 597)
	id 0CA0B15B2D5C6; Mon,  9 Feb 2004 01:50:50 +0100 (CET)
To: "cramerj" <cramerj@intel.com>
Cc: "Andi Kleen" <ak@suse.de>, <jonmason@us.ibm.com>, <netdev@oss.sgi.com>
Subject: Re: Bad UDP checksum with 82540EM
References: <101E0EB68A545748974019DC227C554007CBDD@orsmsx406.jf.intel.com>
From: Andreas Schwab <schwab@suse.de>
X-Yow: Psychoanalysis??  I thought this was a nude rap session!!!
Date: Mon, 09 Feb 2004 01:50:48 +0100
In-Reply-To: <101E0EB68A545748974019DC227C554007CBDD@orsmsx406.jf.intel.com> (cramerj@intel.com's
 message of "Sun, 8 Feb 2004 15:22:29 -0800")
Message-ID: <jey8rdcbyv.fsf@sykes.suse.de>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-archive-position: 3126
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: schwab@suse.de
Precedence: bulk
X-list: netdev
Content-Length: 871
Lines: 26

"cramerj" <cramerj@intel.com> writes:

> Just for clarification...how are you determining a bad checksum?  Are
> you using tcpdump/ethereal on those test machines (that you're
> transmitting from), or are you capturing packets on the wire (from some
> other system receiving the packets).

Actually both.  I have first noticed the issue because my DHCP clients
didn't accept the answers from the server.

> If the former, then please see the following thread.
>
> http://marc.theaimsgroup.com/?t=107422099800006&r=1&w=2
>
> Is this perhaps the issue you're seeing?

I just double checked, the packets are really going out with a bad
checksum.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

From yoshfuji@linux-ipv6.org Sun Feb  8 20:42:41 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 20:42:56 -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 i194geKO021299
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 20:42:41 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id AA70833CA5; Mon,  9 Feb 2004 13:43:35 +0900 (JST)
Date: Mon, 09 Feb 2004 13:43:35 +0900 (JST)
Message-Id: <20040209.134335.71212303.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: [PATCH] [WANROUTER] LL_RESERVED_SPACE
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: 3127
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: 783
Lines: 26

D: [WANROUTER] Use LL_RESERVED_SPACE() where appricable.

===== net/wanrouter/af_wanpipe.c 1.31 vs edited =====
--- 1.31/net/wanrouter/af_wanpipe.c	Sun Oct  5 15:51:01 2003
+++ edited/net/wanrouter/af_wanpipe.c	Mon Feb  9 12:39:45 2004
@@ -591,14 +591,14 @@
   		return -EMSGSIZE;
 	}
 
-	skb = sock_alloc_send_skb(sk, len+dev->hard_header_len+15, 
+	skb = sock_alloc_send_skb(sk, len + LL_RESERVED_SPACE(dev),
 				msg->msg_flags & MSG_DONTWAIT, &err);
 
 	if (skb==NULL){
 		goto out_unlock;
 	}
 		
-	skb_reserve(skb, (dev->hard_header_len+15)&~15);
+	skb_reserve(skb, LL_RESERVED_SPACE(dev));
 	skb->nh.raw = skb->data;
 
 	/* Returns -EFAULT on error */

-- 
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 Sun Feb  8 20:42:46 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 20:42:59 -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 i194gkKO021312
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 20:42:46 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 7A7A433CA5; Mon,  9 Feb 2004 13:43:41 +0900 (JST)
Date: Mon, 09 Feb 2004 13:43:41 +0900 (JST)
Message-Id: <20040209.134341.43254113.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: [PATCH] [PACKET] LL_RESERVED_SPACE
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: 3128
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: 1386
Lines: 42

D: [PACKET] Use LL_RESERVED_SPACE() where appricable.

===== net/packet/af_packet.c 1.40 vs edited =====
--- 1.40/net/packet/af_packet.c	Sat Feb  7 06:30:12 2004
+++ edited/net/packet/af_packet.c	Mon Feb  9 12:41:20 2004
@@ -327,7 +327,7 @@
 		goto out_unlock;
 
 	err = -ENOBUFS;
-	skb = sock_wmalloc(sk, len+dev->hard_header_len+15, 0, GFP_KERNEL);
+	skb = sock_wmalloc(sk, len + LL_RESERVED_SPACE(dev), 0, GFP_KERNEL);
 
 	/*
 	 *	If the write buffer is full, then tough. At this level the user gets to
@@ -346,7 +346,7 @@
 	 * hard header at transmission time by themselves. PPP is the
 	 * notable one here. This should really be fixed at the driver level.
 	 */
-	skb_reserve(skb,(dev->hard_header_len+15)&~15);
+	skb_reserve(skb, LL_RESERVED_SPACE(dev));
 	skb->nh.raw = skb->data;
 
 	/* Try to align data part correctly */
@@ -700,12 +700,12 @@
 	if (len > dev->mtu+reserve)
 		goto out_unlock;
 
-	skb = sock_alloc_send_skb(sk, len+dev->hard_header_len+15, 
+	skb = sock_alloc_send_skb(sk, len + LL_RESERVED_SPACE(dev),
 				msg->msg_flags & MSG_DONTWAIT, &err);
 	if (skb==NULL)
 		goto out_unlock;
 
-	skb_reserve(skb, (dev->hard_header_len+15)&~15);
+	skb_reserve(skb, LL_RESERVED_SPACE(dev));
 	skb->nh.raw = skb->data;
 
 	if (dev->hard_header) {

-- 
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 Sun Feb  8 20:43:24 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 20:43:37 -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 i194hNKO021443
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 20:43:24 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 1E63833CA5; Mon,  9 Feb 2004 13:44:19 +0900 (JST)
Date: Mon, 09 Feb 2004 13:44:18 +0900 (JST)
Message-Id: <20040209.134418.72875541.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: [PATCH] [NETFILTER] LL_RESERVED_SPACE
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: 3130
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: 987
Lines: 30

D: [NETFILTER] Use LL_RESERVED_SPACE() where appricable.

===== net/ipv4/netfilter/ipt_REJECT.c 1.26 vs edited =====
--- 1.26/net/ipv4/netfilter/ipt_REJECT.c	Fri Jan 30 10:00:13 2004
+++ edited/net/ipv4/netfilter/ipt_REJECT.c	Mon Feb  9 12:47:03 2004
@@ -117,7 +117,7 @@
 	if ((rt = route_reverse(oldskb, hook)) == NULL)
 		return;
 
-	hh_len = (rt->u.dst.dev->hard_header_len + 15)&~15;
+	hh_len = LL_RESERVED_SPACE(rt->u.dst.dev);
 
 	/* We need a linear, writeable skb.  We also need to expand
 	   headroom in case hh_len of incoming interface < hh_len of
@@ -305,9 +305,9 @@
 	if (length > 576)
 		length = 576;
 
-	hh_len = (rt->u.dst.dev->hard_header_len + 15)&~15;
+	hh_len = LL_RESERVED_SPACE(rt->u.dst.dev);
 
-	nskb = alloc_skb(hh_len+15+length, GFP_ATOMIC);
+	nskb = alloc_skb(hh_len + length, GFP_ATOMIC);
 	if (!nskb) {
 		ip_rt_put(rt);
 		return;

-- 
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 Sun Feb  8 20:43:19 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 20:43:32 -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 i194hIKO021422
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 20:43:18 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id C558D33CA5; Mon,  9 Feb 2004 13:44:13 +0900 (JST)
Date: Mon, 09 Feb 2004 13:44:13 +0900 (JST)
Message-Id: <20040209.134413.98076915.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: [PATCH] [IPV4] LL_RESERVED_SPACE
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: 3129
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: 793
Lines: 27

D: [IPV4] Use LL_RESERVED_SPACE() where appricable

===== net/ipv4/igmp.c 1.47 vs edited =====
--- 1.47/net/ipv4/igmp.c	Tue Feb  3 08:43:31 2004
+++ edited/net/ipv4/igmp.c	Mon Feb  9 12:44:46 2004
@@ -276,7 +276,7 @@
 	struct iphdr *pip;
 	struct igmpv3_report *pig;
 
-	skb = alloc_skb(size + dev->hard_header_len + 15, GFP_ATOMIC);
+	skb = alloc_skb(size + LL_RESERVED_SPACE(dev), GFP_ATOMIC);
 	if (skb == NULL)
 		return 0;
 
@@ -298,7 +298,7 @@
 	skb->dst = &rt->u.dst;
 	skb->dev = dev;
 
-	skb_reserve(skb, (dev->hard_header_len+15)&~15);
+	skb_reserve(skb, LL_RESERVED_SPACE(dev));
 
 	skb->nh.iph = pip =(struct iphdr *)skb_put(skb, sizeof(struct iphdr)+4);
 

-- 
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 Sun Feb  8 20:44:28 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 20:44: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 i194iRKO022161
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 20:44:28 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 5030E33CA5; Mon,  9 Feb 2004 13:45:23 +0900 (JST)
Date: Mon, 09 Feb 2004 13:45:23 +0900 (JST)
Message-Id: <20040209.134523.27564970.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: [PATCH] [IPV6] LL_RESERVED_SPACE
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: 3131
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: 4972
Lines: 154

D: [IPV6] Use LL_RESERVED_SPACE() where appricable.

===== net/ipv6/ip6_output.c 1.49 vs edited =====
--- 1.49/net/ipv6/ip6_output.c	Thu Jan 22 15:18:21 2004
+++ edited/net/ipv6/ip6_output.c	Mon Feb  9 13:25:45 2004
@@ -218,7 +218,7 @@
 		 */
 		head_room = opt->opt_nflen + opt->opt_flen;
 		seg_len += head_room;
-		head_room += sizeof(struct ipv6hdr) + ((dst->dev->hard_header_len + 15)&~15);
+		head_room += sizeof(struct ipv6hdr) + LL_RESERVED_SPACE(dst->dev);
 
 		if (skb_headroom(skb) < head_room) {
 			struct sk_buff *skb2 = skb_realloc_headroom(skb, head_room);
@@ -844,7 +844,7 @@
 		mtu = inet->cork.fragsize;
 	}
 
-	hh_len = (rt->u.dst.dev->hard_header_len&~15) + 16;
+	hh_len = LL_RESERVED_SPACE(rt->u.dst.dev);
 
 	fragheaderlen = sizeof(struct ipv6hdr) + (opt ? opt->opt_nflen : 0);
 	maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen - sizeof(struct frag_hdr);
@@ -881,14 +881,14 @@
 			alloclen += sizeof(struct frag_hdr);
 			if (transhdrlen) {
 				skb = sock_alloc_send_skb(sk,
-						alloclen + hh_len + 15,
+						alloclen + hh_len,
 						(flags & MSG_DONTWAIT), &err);
 			} else {
 				skb = NULL;
 				if (atomic_read(&sk->sk_wmem_alloc) <=
 				    2 * sk->sk_sndbuf)
 					skb = sock_wmalloc(sk,
-							   alloclen + hh_len + 15, 1,
+							   alloclen + hh_len, 1,
 							   sk->sk_allocation);
 				if (unlikely(skb == NULL))
 					err = -ENOBUFS;
===== net/ipv6/mcast.c 1.50 vs edited =====
--- 1.50/net/ipv6/mcast.c	Thu Jan 29 09:06:25 2004
+++ edited/net/ipv6/mcast.c	Mon Feb  9 13:35:19 2004
@@ -1233,12 +1233,13 @@
 		     IPV6_TLV_ROUTERALERT, 2, 0, 0,
 		     IPV6_TLV_PADN, 0 };
 
-	skb = sock_alloc_send_skb(sk, size + dev->hard_header_len+15, 1, &err);
+	/* we assume size > sizeof(ra) here */
+	skb = sock_alloc_send_skb(sk, size + LL_RESERVED_SPACE(dev), 1, &err);
 
 	if (skb == 0)
 		return 0;
 
-	skb_reserve(skb, (dev->hard_header_len + 15) & ~15);
+	skb_reserve(skb, LL_RESERVED_SPACE(dev));
 	if (dev->hard_header) {
 		unsigned char ha[MAX_ADDR_LEN];
 
@@ -1580,12 +1581,12 @@
 	payload_len = len + sizeof(ra);
 	full_len = sizeof(struct ipv6hdr) + payload_len;
 
-	skb = sock_alloc_send_skb(sk, dev->hard_header_len + full_len + 15, 1, &err);
+	skb = sock_alloc_send_skb(sk, LL_RESERVED_SPACE(dev) + full_len, 1, &err);
 
 	if (skb == NULL)
 		return;
 
-	skb_reserve(skb, (dev->hard_header_len + 15) & ~15);
+	skb_reserve(skb, LL_RESERVED_SPACE(dev));
 	if (dev->hard_header) {
 		unsigned char ha[MAX_ADDR_LEN];
 		ndisc_mc_map(snd_addr, ha, dev, 1);
===== net/ipv6/ndisc.c 1.70 vs edited =====
--- 1.70/net/ipv6/ndisc.c	Sat Feb  7 08:28:55 2004
+++ edited/net/ipv6/ndisc.c	Mon Feb  9 13:25:45 2004
@@ -459,7 +459,7 @@
 			inc_opt = 0;
 	}
 
-	skb = sock_alloc_send_skb(sk, MAX_HEADER + len + dev->hard_header_len + 15,
+	skb = sock_alloc_send_skb(sk, MAX_HEADER + len + LL_RESERVED_SPACE(dev),
 				  1, &err);
 
 	if (skb == NULL) {
@@ -468,7 +468,7 @@
 		return;
 	}
 
-	skb_reserve(skb, (dev->hard_header_len + 15) & ~15);
+	skb_reserve(skb, LL_RESERVED_SPACE(dev));
 	ip6_nd_hdr(sk, skb, dev, src_addr, daddr, IPPROTO_ICMPV6, len);
 
 	msg = (struct nd_msg *)skb_put(skb, len);
@@ -545,7 +545,7 @@
 	if (send_llinfo)
 		len += NDISC_OPT_SPACE(dev->addr_len);
 
-	skb = sock_alloc_send_skb(sk, MAX_HEADER + len + dev->hard_header_len + 15,
+	skb = sock_alloc_send_skb(sk, MAX_HEADER + len + LL_RESERVED_SPACE(dev),
 				  1, &err);
 	if (skb == NULL) {
 		ND_PRINTK1("send_ns: alloc skb failed\n");
@@ -553,7 +553,7 @@
 		return;
 	}
 
-	skb_reserve(skb, (dev->hard_header_len + 15) & ~15);
+	skb_reserve(skb, LL_RESERVED_SPACE(dev));
 	ip6_nd_hdr(sk, skb, dev, saddr, daddr, IPPROTO_ICMPV6, len);
 
 	msg = (struct nd_msg *)skb_put(skb, len);
@@ -617,7 +617,7 @@
 	if (dev->addr_len)
 		len += NDISC_OPT_SPACE(dev->addr_len);
 
-        skb = sock_alloc_send_skb(sk, MAX_HEADER + len + dev->hard_header_len + 15,
+        skb = sock_alloc_send_skb(sk, MAX_HEADER + len + LL_RESERVED_SPACE(dev),
 				  1, &err);
 	if (skb == NULL) {
 		ND_PRINTK1("send_ns: alloc skb failed\n");
@@ -625,7 +625,7 @@
 		return;
 	}
 
-	skb_reserve(skb, (dev->hard_header_len + 15) & ~15);
+	skb_reserve(skb, LL_RESERVED_SPACE(dev));
 	ip6_nd_hdr(sk, skb, dev, saddr, daddr, IPPROTO_ICMPV6, len);
 
         hdr = (struct icmp6hdr *)skb_put(skb, len);
@@ -1305,7 +1305,7 @@
 	rd_len &= ~0x7;
 	len += rd_len;
 
-	buff = sock_alloc_send_skb(sk, MAX_HEADER + len + dev->hard_header_len + 15,
+	buff = sock_alloc_send_skb(sk, MAX_HEADER + len + LL_RESERVED_SPACE(dev),
 				   1, &err);
 	if (buff == NULL) {
 		ND_PRINTK1("ndisc_send_redirect: alloc_skb failed\n");
@@ -1315,7 +1315,7 @@
 
 	hlen = 0;
 
-	skb_reserve(buff, (dev->hard_header_len + 15) & ~15);
+	skb_reserve(buff, LL_RESERVED_SPACE(dev));
 	ip6_nd_hdr(sk, buff, dev, &saddr_buf, &skb->nh.ipv6h->saddr,
 		   IPPROTO_ICMPV6, len);
 


-- 
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 Sun Feb  8 20:44:34 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 20:44:46 -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 i194iXKO022168
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 20:44:34 -0800
Received: from localhost (localhost [127.0.0.1])
	by yue.hongo.wide.ad.jp (Postfix) with ESMTP
	id 1A2E833CA5; Mon,  9 Feb 2004 13:45:29 +0900 (JST)
Date: Mon, 09 Feb 2004 13:45:28 +0900 (JST)
Message-Id: <20040209.134528.28683257.yoshfuji@linux-ipv6.org>
To: davem@redhat.com
Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: [PATCH,RFC] [NET] ALIGN
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: 3132
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: 699
Lines: 23

D: Use ALIGN() where appricable.

BTW, 
 1. do we really need this ALIGN?
 2. should 16 be BYTES_PER_WORD (in mm/slab.c)?

===== net/core/neighbour.c 1.24 vs edited =====
--- 1.24/net/core/neighbour.c	Tue Jan 20 14:31:23 2004
+++ edited/net/core/neighbour.c	Mon Feb  9 13:13:37 2004
@@ -1164,8 +1164,7 @@
 
 	if (!tbl->kmem_cachep)
 		tbl->kmem_cachep = kmem_cache_create(tbl->id,
-						     (tbl->entry_size +
-						      15) & ~15,
+						     ALIGN(tbl->entry_size, 16),
 						     0, SLAB_HWCACHE_ALIGN,
 						     NULL, NULL);
 	tbl->lock	       = RW_LOCK_UNLOCKED;

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

From pekkas@netcore.fi Sun Feb  8 22:08:46 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 22:08:59 -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 i1968jKO025110
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 22:08:46 -0800
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id i1968UY12576;
	Mon, 9 Feb 2004 08:08:31 +0200
Date: Mon, 9 Feb 2004 08:08:30 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: Julian Anastasov <ja@ssi.bg>
cc: netdev@oss.sgi.com, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Subject: Re: Change proxy_arp to respond only for valid neighbours
In-Reply-To: <Pine.LNX.4.58.0402082234110.6268@u.domain.uli>
Message-ID: <Pine.LNX.4.44.0402090806040.11837-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 3133
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
Content-Length: 929
Lines: 23

On Sun, 8 Feb 2004, Julian Anastasov wrote:
> 	Appended is a patch that modifies proxy_arp to check
> the target's neighbour state before reporting any information
> to requestors. The benefit is that the availability of the target
> host is properly reported to the requestor, we prefer not to send
> replies when target is unreachable. 

As this seems to make the proxy_arp more intelligent, maybe you should 
take a look at:

http://www.ietf.org/internet-drafts/draft-thaler-ipv6-ndproxy-01.txt

(which, at the moment, specifies proxy arp/ND for both IPv4 and IPv6)

and see how close our implementation is wrt. to that spec, whether the 
above spec is better or worse, or whether there may be room for 
improvement otherwise as well?

-- 
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 k_jambunathan@yahoo.co.uk Sun Feb  8 23:56:50 2004
Received: with ECARTIS (v1.0.0; list netdev); Sun, 08 Feb 2004 23:57:04 -0800 (PST)
Received: from web25110.mail.ukl.yahoo.com (web25110.mail.ukl.yahoo.com [217.12.10.58])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i197unKO027416
	for <netdev@oss.sgi.com>; Sun, 8 Feb 2004 23:56:50 -0800
Message-ID: <20040209075644.11922.qmail@web25110.mail.ukl.yahoo.com>
Received: from [202.144.86.147] by web25110.mail.ukl.yahoo.com via HTTP; Mon, 09 Feb 2004 07:56:44 GMT
Date: Mon, 9 Feb 2004 07:56:44 +0000 (GMT)
From: =?iso-8859-1?q?Jambunathan=20Kalyanasundaram?= <k_jambunathan@yahoo.co.uk>
Subject: TProxy, 2.4 Kernel and NetFilter
To: netfilter-devel@lists.netfilter.org
Cc: netdev@oss.sgi.com
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-archive-position: 3135
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: k_jambunathan@yahoo.co.uk
Precedence: bulk
X-list: netdev
Content-Length: 1117
Lines: 36

( Sorry for posting in two mailing lists at the same
time )

I would like to implement Transparent HTTP Proxy  and
I have scoured through your archives for the related
threads. Can someone confirm that my following
understanding is still valid as of date considering
the latest Linux kernel and Netfilter source tree.

1) For packet interception from browser side, the
standard way is to use REDIRECT target of Netfilter.

2) But if I am not really interested in the overheads
imposed by the NetFilter, the only option is to patch
the Linux kernel with Balazs Scheidler's patch. 

If I don't like something as heavyweight as Netfilter
and something that is as  "non standard" as patching
the kernel, are there any ways out ? 

Also are there any existing NetFilter modules that
work on a standard, unpatched kerenel that allow proxy
to talk to the web server as though it's the web
browser ( source address spoofing ) ?

Regards,
Jambunathan K.




	
	
		
___________________________________________________________
BT Yahoo! Broadband - Free modem offer, sign up online today and save £80 http://btyahoo.yahoo.co.uk

From shmulik.hen@intel.com Mon Feb  9 02:53:18 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 02:53:37 -0800 (PST)
Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i19ArIKO005068
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 02:53:18 -0800
Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39])
	by hermes-pilot.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 i18G9VfT021980;
	Sun, 8 Feb 2004 16:09:32 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124])
	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 i18GBLZA009717;
	Sun, 8 Feb 2004 16:11:22 GMT
Received: from jrslxjul4.npdj.intel.com ([10.12.220.54])
 by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020808113024093
 ; Sun, 08 Feb 2004 08:11:31 -0800
From: Shmuel Hen <shmulik.hen@intel.com>
Organization: Intel Corporation
To: "Jeff Garzik" <jgarzik@pobox.com>
Subject: [PATCH 3/3][bonding][2.6] Add VLAN support in ALB mode
Date: Sun, 8 Feb 2004 18:11:28 +0200
User-Agent: KMail/1.5.3
Cc: "linux-netdev" <netdev@oss.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200402081811.29698.shmulik.hen@intel.com>
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-archive-position: 3136
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: 7045
Lines: 217

Add capability to tag self generated ARP packets that are required 
for receive load balancing in bonding. VLAN Id's are saved and used 
each time a new IP connection is established since 8021q currently 
supports IP binding. 

Update module version and comment blocks.

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


diff -Nuarp a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
--- a/drivers/net/bonding/bond_alb.c	Wed Jan 21 16:56:26 2004
+++ b/drivers/net/bonding/bond_alb.c	Wed Jan 21 16:56:28 2004
@@ -34,6 +34,9 @@
  *
  * 2003/12/30 - Amir Noam <amir.noam at intel dot com>
  *	- Fixed: Cannot remove and re-enslave the original active slave.
+ *
+ * 2004/01/14 - Shmulik Hen <shmulik.hen at intel dot com>
+ *	- Add capability to tag self generated packets in ALB/TLB modes.
  */
 
 //#define BONDING_DEBUG 1
@@ -499,13 +502,33 @@ static void rlb_update_client(struct rlb
 	}
 
 	for (i = 0; i < RLB_ARP_BURST_SIZE; i++) {
-		arp_send(ARPOP_REPLY, ETH_P_ARP,
-			 client_info->ip_dst,
-			 client_info->slave->dev,
-			 client_info->ip_src,
-			 client_info->mac_dst,
-			 client_info->slave->dev->dev_addr,
-			 client_info->mac_dst);
+		struct sk_buff *skb;
+
+		skb = arp_create(ARPOP_REPLY, ETH_P_ARP,
+				 client_info->ip_dst,
+				 client_info->slave->dev,
+				 client_info->ip_src,
+				 client_info->mac_dst,
+				 client_info->slave->dev->dev_addr,
+				 client_info->mac_dst);
+		if (!skb) {
+			printk(KERN_ERR DRV_NAME
+			       ": Error: failed to create an ARP packet\n");
+			continue;
+		}
+
+		skb->dev = client_info->slave->dev;
+
+		if (client_info->tag) {
+			skb = vlan_put_tag(skb, client_info->vlan_id);
+			if (!skb) {
+				printk(KERN_ERR DRV_NAME
+				       ": Error: failed to insert VLAN tag\n");
+				continue;
+			}
+		}
+
+		arp_xmit(skb);
 	}
 }
 
@@ -604,9 +627,10 @@ static void rlb_req_update_subnet_client
 }
 
 /* Caller must hold both bond and ptr locks for read */
-struct slave *rlb_choose_channel(struct bonding *bond, struct arp_pkt *arp)
+struct slave *rlb_choose_channel(struct sk_buff *skb, struct bonding *bond)
 {
 	struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
+	struct arp_pkt *arp = (struct arp_pkt *)skb->nh.raw;
 	struct slave *assigned_slave;
 	struct rlb_client_info *client_info;
 	u32 hash_index = 0;
@@ -662,6 +686,15 @@ struct slave *rlb_choose_channel(struct 
 			client_info->ntt = 0;
 		}
 
+		if (!list_empty(&bond->vlan_list)) {
+			unsigned short vlan_id;
+			int res = vlan_get_tag(skb, &vlan_id);
+			if (!res) {
+				client_info->tag = 1;
+				client_info->vlan_id = vlan_id;
+			}
+		}
+
 		if (!client_info->assigned) {
 			u32 prev_tbl_head = bond_info->rx_hashtbl_head;
 			bond_info->rx_hashtbl_head = hash_index;
@@ -692,7 +725,7 @@ static struct slave *rlb_arp_xmit(struct
 		/* the arp must be sent on the selected
 		* rx channel
 		*/
-		tx_slave = rlb_choose_channel(bond, arp);
+		tx_slave = rlb_choose_channel(skb, bond);
 		if (tx_slave) {
 			memcpy(arp->mac_src,tx_slave->dev->dev_addr, ETH_ALEN);
 		}
@@ -703,7 +736,7 @@ static struct slave *rlb_arp_xmit(struct
 		 * When the arp reply is received the entry will be updated
 		 * with the correct unicast address of the client.
 		 */
-		rlb_choose_channel(bond, arp);
+		rlb_choose_channel(skb, bond);
 
 		/* The ARP relpy packets must be delayed so that
 		 * they can cancel out the influence of the ARP request.
@@ -809,6 +842,40 @@ static void rlb_deinitialize(struct bond
 
 	kfree(bond_info->rx_hashtbl);
 	bond_info->rx_hashtbl = NULL;
+	bond_info->rx_hashtbl_head = RLB_NULL_INDEX;
+
+	_unlock_rx_hashtbl(bond);
+}
+
+static void rlb_clear_vlan(struct bonding *bond, unsigned short vlan_id)
+{
+	struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
+	u32 curr_index;
+
+	_lock_rx_hashtbl(bond);
+
+	curr_index = bond_info->rx_hashtbl_head;
+	while (curr_index != RLB_NULL_INDEX) {
+		struct rlb_client_info *curr = &(bond_info->rx_hashtbl[curr_index]);
+		u32 next_index = bond_info->rx_hashtbl[curr_index].next;
+		u32 prev_index = bond_info->rx_hashtbl[curr_index].prev;
+
+		if (curr->tag && (curr->vlan_id == vlan_id)) {
+			if (curr_index == bond_info->rx_hashtbl_head) {
+				bond_info->rx_hashtbl_head = next_index;
+			}
+			if (prev_index != RLB_NULL_INDEX) {
+				bond_info->rx_hashtbl[prev_index].next = next_index;
+			}
+			if (next_index != RLB_NULL_INDEX) {
+				bond_info->rx_hashtbl[next_index].prev = prev_index;
+			}
+
+			rlb_init_table_entry(curr);
+		}
+
+		curr_index = next_index;
+	}
 
 	_unlock_rx_hashtbl(bond);
 }
@@ -1616,5 +1683,9 @@ void bond_alb_clear_vlan(struct bonding 
 	    (bond->alb_info.current_alb_vlan->vlan_id == vlan_id)) {
 		bond->alb_info.current_alb_vlan = NULL;
 	}
+
+	if (bond->alb_info.rlb_enabled) {
+		rlb_clear_vlan(bond, vlan_id);
+	}
 }
 
diff -Nuarp a/drivers/net/bonding/bond_alb.h b/drivers/net/bonding/bond_alb.h
--- a/drivers/net/bonding/bond_alb.h	Wed Jan 21 16:56:26 2004
+++ b/drivers/net/bonding/bond_alb.h	Wed Jan 21 16:56:28 2004
@@ -77,6 +77,8 @@ struct rlb_client_info {
 	u8  assigned;		/* checking whether this entry is assigned */
 	u8  ntt;		/* flag - need to transmit client info */
 	struct slave *slave;	/* the slave assigned to this client */
+	u8 tag;			/* flag - need to tag skb */
+	unsigned short vlan_id;	/* VLAN tag associated with IP address */
 };
 
 struct tlb_slave_info {
diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
--- a/drivers/net/bonding/bond_main.c	Wed Jan 21 16:56:26 2004
+++ b/drivers/net/bonding/bond_main.c	Wed Jan 21 16:56:28 2004
@@ -455,12 +455,20 @@
  *
  * 2003/12/30 - Amir Noam <amir.noam at intel dot com>
  *	- Fixed: Cannot remove and re-enslave the original active slave.
- *	- Fixed: Releasing the original active slave causes mac address duplication.
+ *	- Fixed: Releasing the original active slave causes mac address
+ *		 duplication.
  *	- Add support for slaves that use ethtool_ops.
  *	  Set version to 2.5.3.
  *
  * 2004/01/05 - Amir Noam <amir.noam at intel dot com>
  *	- Save bonding parameters per bond instead of using the global values.
+ *	  Set version to 2.5.4.
+ *
+ * 2004/01/14 - Shmulik Hen <shmulik.hen at intel dot com>
+ *	- Enhance VLAN support:
+ *	  * Add support for VLAN hardware acceleration capable slaves.
+ *	  * Add capability to tag self generated packets in ALB/TLB modes.
+ *	  Set version to 2.6.0.
  */
 
 //#define BONDING_DEBUG 1
diff -Nuarp a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
--- a/drivers/net/bonding/bonding.h	Wed Jan 21 16:56:26 2004
+++ b/drivers/net/bonding/bonding.h	Wed Jan 21 16:56:28 2004
@@ -36,8 +36,8 @@
 #include "bond_3ad.h"
 #include "bond_alb.h"
 
-#define DRV_VERSION	"2.5.4"
-#define DRV_RELDATE	"December 30, 2003"
+#define DRV_VERSION	"2.6.0"
+#define DRV_RELDATE	"January 14, 2004"
 #define DRV_NAME	"bonding"
 #define DRV_DESCRIPTION	"Ethernet Channel Bonding Driver"
 


From okir@suse.de Mon Feb  9 03:11:36 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 03:11:50 -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 i19BBPKO006647
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 03:11:26 -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 079CF186C71; Mon,  9 Feb 2004 11:28:02 +0100 (CET)
Received: by wotan.suse.de (Postfix, from userid 10572)
	id D8854196B5; Mon,  9 Feb 2004 11:28:01 +0100 (CET)
Date: Mon, 9 Feb 2004 11:28:01 +0100
From: Olaf Kirch <okir@suse.de>
To: Christoph Hellwig <hch@lst.de>
Cc: netdev@oss.sgi.com, nfs@lists.sourceforge.net
Subject: Re: [NFS] [PATCH][RFC] use completions instead of sleep_on for rpciod
Message-ID: <20040209102801.GC21364@suse.de>
References: <20040207144405.GA19416@lst.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <20040207144405.GA19416@lst.de>
User-Agent: Mutt/1.4i
X-archive-position: 3137
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: okir@suse.de
Precedence: bulk
X-list: netdev
Content-Length: 615
Lines: 17

On Sat, Feb 07, 2004 at 03:44:05PM +0100, Christoph Hellwig wrote:
> The rpciod shutdown code gives ugly sleep_on without BKL warnings in
> -mm.  And it looks indeed somewhat racy.

Yes, this code is indeed one of the areas that breaks when you use
the sunrpc code without the BKL. Another one was the missing spinlock
in xprt_alloc_xid. The code in fs/nfs/unlink.c is probably also racy
without BKL.

So if you remove the sunrpc BKL be prepared for lots and lots
of bug reports :)

Olaf
-- 
Olaf Kirch     |  Stop wasting entropy - start using predictable
okir@suse.de   |  tempfile names today!
---------------+ 

From ja@ssi.bg Mon Feb  9 03:30:53 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 03:31:06 -0800 (PST)
Received: from l.himel.bg (IDENT:root@unamed.infotel.bg [212.39.68.18] (may be forged))
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i19BUhKO007387
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 03:30:50 -0800
Received: from linux.himel.bg (IDENT:ja@linux.himel.bg [127.0.0.1])
	by l.himel.bg (8.11.6/8.9.3) with ESMTP id i19BUuV03261;
	Mon, 9 Feb 2004 13:30:56 +0200
Date: Mon, 9 Feb 2004 13:30:56 +0200 (EET)
From: Julian Anastasov <ja@ssi.bg>
X-X-Sender: ja@l
To: Pekka Savola <pekkas@netcore.fi>
cc: netdev@oss.sgi.com, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Subject: Re: Change proxy_arp to respond only for valid neighbours
In-Reply-To: <Pine.LNX.4.44.0402090806040.11837-100000@netcore.fi>
Message-ID: <Pine.LNX.4.44.0402091329140.3176-100000@l>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 3138
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: ja@ssi.bg
Precedence: bulk
X-list: netdev
Content-Length: 543
Lines: 23


	Hello,

On Mon, 9 Feb 2004, Pekka Savola wrote:

> As this seems to make the proxy_arp more intelligent, maybe you should
> take a look at:
>
> http://www.ietf.org/internet-drafts/draft-thaler-ipv6-ndproxy-01.txt
>
> (which, at the moment, specifies proxy arp/ND for both IPv4 and IPv6)
>
> and see how close our implementation is wrt. to that spec, whether the
> above spec is better or worse, or whether there may be room for
> improvement otherwise as well?

	Thanks, I'll check it later today.

Regards

--
Julian Anastasov <ja@ssi.bg>


From vandrove@vc.cvut.cz Mon Feb  9 05:01:39 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 05:01:52 -0800 (PST)
Received: from vana.vc.cvut.cz (root@vana.vc.cvut.cz [147.32.240.58])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i19D1bKO017915
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 05:01:38 -0800
Received: from vana.vc.cvut.cz (smmsp@localhost [127.0.0.1])
	by vana.vc.cvut.cz (8.12.11/8.12.11/Debian-1) with ESMTP id i19D1ZRL016156;
	Mon, 9 Feb 2004 14:01:36 +0100
Received: (from root@localhost)
	by vana.vc.cvut.cz (8.12.11/8.12.11/Debian-1) id i19D1Y1I016150;
	Mon, 9 Feb 2004 14:01:34 +0100
Date: Mon, 9 Feb 2004 14:01:34 +0100
From: Petr Vandrovec <vandrove@vc.cvut.cz>
To: netdev@oss.sgi.com
Cc: linux-kernel@vger.kernel.org
Subject: 2.6.2 crash after network link failure
Message-ID: <20040209130134.GA14136@vana.vc.cvut.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.5.1+cvs20040105i
X-archive-position: 3140
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: vandrove@vc.cvut.cz
Precedence: bulk
X-list: netdev
Content-Length: 1395
Lines: 38

Hi,
  on Saturday our network switch lost power due to scheduled
Power outage, and unfortunately one of systems connected to the switch
(mine :-( ) did not survive it. When I came to the system's console today, 
I found (written by hand, made a bit shorter...) on screen:

e100: eth0 NIC Link is Up 100Mbps Full Duplex
kernel/sched.c:1802: spin_is_locked on uninitialized spinlock d6e74e18
Unable to handle NULL kernel pointer dereference at virtual address 00000000
...
EIP: C0120AF1  <__wake_up_common + 0x17/0x57>
...
EAX: D6E74E30   EBX: D6E74E18    ECX: 00000001    EDX: 00000000
ESI: 00000001   EDI: 00000001    EBP: C9F3DEDC    ESP: C9F3DEC0
...
Call Trace:
   __wake_up + 0x7B/0x139
   sock_def_write_space + 0x8C/0x94
   sock_wfree + 0x4B/0x4D
   __kfree_skb + 0x5C/0xD9
   net_tx_action + 0x3E/0x210
   do_softirq + 0x92/0x94
   do_IRQ + 0x207/0x360
   common_interrupt + 0x18/0x20


It looks to me like that we've got skb on completion_queue which was connected
to a bit unhappy socket - one which had sk->sk_sleep uninitialized. Only problem 
is that only af_unix sets skb->destructor to sock_wfree, so I somehow miss how 
this could be triggered by e100 link change.

Kernel is approx 2.6.2-bk2, UP, APIC, IOAPIC, no-preempt, all DEBUG options except
CONFIG_FRAME_POINTER enabled.

System is 1.6GHz P4/512MB RAM.
						Best regards,
							Petr Vandrovec
							vandrove@vc.cvut.cz

From hadi@cyberus.ca Mon Feb  9 07:01:29 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 07:01:38 -0800 (PST)
Received: from tiger.cybersurf.com (tiger.cybersurf.com [209.197.145.194])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i19F1SKO026261
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 07:01:29 -0800
Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21])
	by tiger.cybersurf.com (8.12.8/8.12.8) with ESMTP id i19F1JJB008461
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 08:01:19 -0700
Received: from [216.209.86.2] (helo=[10.0.0.21])
	by mail.cyberus.ca with esmtp (Exim 4.20)
	id 1AqCuS-0002Tl-CS; Mon, 09 Feb 2004 10:01:16 -0500
Subject: Re: Change proxy_arp to respond only for valid neighbours
From: jamal <hadi@cyberus.ca>
Reply-To: hadi@cyberus.ca
To: Julian Anastasov <ja@ssi.bg>
Cc: netdev@oss.sgi.com, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
In-Reply-To: <Pine.LNX.4.58.0402082234110.6268@u.domain.uli>
References: <Pine.LNX.4.58.0402082234110.6268@u.domain.uli>
Content-Type: text/plain
Organization: jamalopolis
Message-Id: <1076338874.1026.36.camel@jzny.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 09 Feb 2004 10:01:15 -0500
Content-Transfer-Encoding: 7bit
X-archive-position: 3141
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: hadi@cyberus.ca
Precedence: bulk
X-list: netdev
Content-Length: 1716
Lines: 53


On Sun, 2004-02-08 at 15:44, Julian Anastasov wrote:
> 	Hello,
> 
> 	Appended is a patch that modifies proxy_arp to check
> the target's neighbour state before reporting any information
> to requestors. The benefit is that the availability of the target
> host is properly reported to the requestor, we prefer not to send
> replies when target is unreachable. 

It should probably be a sysctl example proxy_arp_validate_neigh.
I am happy with the way it is right now in the situation i use it in.

> The changes:
> 
> - now pneigh_lookup has more priority compared to arp_fwd_proxy
>
> - neigh_event_ns is called only once per request, not twice

Could the neighbor be removed while we have the packet in the proxy
queue?
It doesnt seem like theres any harm done in redoing the neigh_event_ns
twice.

> - the 'skb->pkt_type == PACKET_HOST' check has no semantic anymore,
> the requestor should have same information no matter the packet
> type. In all cases we add response delay for all requests, broadcast
> or unicast, to help other authoritative hosts to reply before us.
> 

So far we havent been delaying responses to unicast because their
state is typically sane. I should say we are taking for granted
the sender's state machine is sane and would send a valid unicast
probe. Are you protecting against insane implementations?
Other than Linux what other OS actually sends unicast probes?

> - the RTCF_DNAT case is not delayed anymore (may be it is not used
> anymore, IIRC)
> 

Looking at 2.6.1 CONFIG_IP_ROUTE_NAT RTCF_NAT is still in use. Recommend
leaving it.

> Remaining questions:
> 
> - do we need to delay the pneigh_lookup case? Now it is still delayed
> as before.

Didnt follow.

cheers,
jamal


From davem@redhat.com Mon Feb  9 11:18:18 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 11:18:29 -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 i19JIIKO005538
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 11:18: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 i19JIFb32443;
	Mon, 9 Feb 2004 14:18: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 i19JIFa28219;
	Mon, 9 Feb 2004 14:18:15 -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 i19JHfkC027061;
	Mon, 9 Feb 2004 14:17:42 -0500
Date: Mon, 9 Feb 2004 11:18:14 -0800
From: "David S. Miller" <davem@redhat.com>
To: yoshfuji@linux-ipv6.org
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH] [IPV6] LL_RESERVED_SPACE
Message-Id: <20040209111814.3967d222.davem@redhat.com>
In-Reply-To: <20040209.134523.27564970.yoshfuji@linux-ipv6.org>
References: <20040209.134523.27564970.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=US-ASCII
Content-Transfer-Encoding: 7bit
X-archive-position: 3142
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: 81
Lines: 3


I applied all of your LL_RESERVED_SPACE() patches, thanks for
doing this audit.

From davem@redhat.com Mon Feb  9 11:20:10 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 11:20: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 i19JKAKO005761
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 11:20:10 -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 i19JK8b00809;
	Mon, 9 Feb 2004 14:20:08 -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 i19JK8a28697;
	Mon, 9 Feb 2004 14:20:08 -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 i19JJZkC027584;
	Mon, 9 Feb 2004 14:19:35 -0500
Date: Mon, 9 Feb 2004 11:20:07 -0800
From: "David S. Miller" <davem@redhat.com>
To: yoshfuji@linux-ipv6.org
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH,RFC] [NET] ALIGN
Message-Id: <20040209112007.08023ba6.davem@redhat.com>
In-Reply-To: <20040209.134528.28683257.yoshfuji@linux-ipv6.org>
References: <20040209.134528.28683257.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 i19JKAKO005761
X-archive-position: 3143
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: 658
Lines: 23

On Mon, 09 Feb 2004 13:45:28 +0900 (JST)
YOSHIFUJI Hideaki / $B5HF#1QL@(B <yoshfuji@linux-ipv6.org> wrote:

> D: Use ALIGN() where appricable.
> 
> BTW, 
>  1. do we really need this ALIGN?
>  2. should 16 be BYTES_PER_WORD (in mm/slab.c)?

Let's hold on this patch.

Why does it want to align the table entry size to 16 bytes
anyways?

I think this is complete nonsense, and that the alignment is not
necessary.  I can't even come up with a performance reason as SLAB
is going to align things to hw cache line size anyways.

Can anybody come up with some theory ? :-)

Else let's just remove this bogus 16 byte alignment in the
kmem_cache_create() call.


From sri@us.ibm.com Mon Feb  9 12:01:35 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 12:01:45 -0800 (PST)
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i19K1SKO007062
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 12:01:34 -0800
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150])
	by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i19K1LtB626788;
	Mon, 9 Feb 2004 15:01:21 -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 i19K1Kmh131968;
	Mon, 9 Feb 2004 15:01:21 -0500
Date: Mon, 9 Feb 2004 12:01:20 -0800 (PST)
From: Sridhar Samudrala <sri@us.ibm.com>
X-X-Sender: sridhar@localhost.localdomain
To: "David S. Miller" <davem@redhat.com>
cc: netdev@oss.sgi.com
Subject: Re: [BK PATCH] 2.6.2 SCTP updates
In-Reply-To: <20040206194518.56787717.davem@redhat.com>
Message-ID: <Pine.LNX.4.58.0402091155070.10043@localhost.localdomain>
References: <Pine.LNX.4.58.0402061649001.10831@localhost.localdomain>
 <20040206194518.56787717.davem@redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 3144
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: 962
Lines: 26

On Sun, 8 Feb 2004, David S. Miller wrote:

> On Sun, 8 Feb 2004 09:07:48 -0800 (PST)
> Sridhar Samudrala <sri@us.ibm.com> wrote:
>
> > I guess i was influenced by the TCP specific tcp_rmem/tcp_wmem. But TCP
> > seems to be using them as a vector of 3 values and tuning the buffer sizes
> > dynamically based on these values.
> > As of now, SCTP doesn't do any tuning dynamically so i could have used the
> > core rmem_default/wmem_default.
> >
> > Do you want me to remove the specialized SCTP sysctl's?
>
> It seems as duplication if there is no specific need to have seperate
> controls right?

OK. I removed the SCTP specific rmem/wmem. Please do a pull again from
	http://linux-lksctp.bkbits.net/lksctp-2.5.work
to get the following cset.

ChangeSet@1.1551, 2004-02-09 11:14:24-08:00, sri@us.ibm.com
  [SCTP] Removed SCTP specific rmem/wmem sysctl's and use the global
         rmem_default/wmem_default values for SCTP socket buffer sizes.

Thanks
Sridhar

From davem@redhat.com Mon Feb  9 12:27:09 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 12:27:24 -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 i19KR9KO010743
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 12:27:09 -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 i19KQmb13426;
	Mon, 9 Feb 2004 15:26:48 -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 i19KQmi30560;
	Mon, 9 Feb 2004 15:26:48 -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 i19KQFkC016549;
	Mon, 9 Feb 2004 15:26:15 -0500
Date: Mon, 9 Feb 2004 12:26:47 -0800
From: "David S. Miller" <davem@redhat.com>
To: Sridhar Samudrala <sri@us.ibm.com>
Cc: netdev@oss.sgi.com
Subject: Re: [BK PATCH] 2.6.2 SCTP updates
Message-Id: <20040209122647.1e8df80a.davem@redhat.com>
In-Reply-To: <Pine.LNX.4.58.0402091155070.10043@localhost.localdomain>
References: <Pine.LNX.4.58.0402061649001.10831@localhost.localdomain>
	<20040206194518.56787717.davem@redhat.com>
	<Pine.LNX.4.58.0402091155070.10043@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: 3145
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: 556
Lines: 14

On Mon, 9 Feb 2004 12:01:20 -0800 (PST)
Sridhar Samudrala <sri@us.ibm.com> wrote:

> OK. I removed the SCTP specific rmem/wmem. Please do a pull again from
> 	http://linux-lksctp.bkbits.net/lksctp-2.5.work
> to get the following cset.
> 
> ChangeSet@1.1551, 2004-02-09 11:14:24-08:00, sri@us.ibm.com
>   [SCTP] Removed SCTP specific rmem/wmem sysctl's and use the global
>          rmem_default/wmem_default values for SCTP socket buffer sizes.

Pulled, thanks for following up on this Sridhar.

What is the status of synchronizing the 2.4.x SCTP sources?

From sri@us.ibm.com Mon Feb  9 12:34:16 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 12:34:27 -0800 (PST)
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i19KYDKO011150
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 12:34:16 -0800
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i19KY8Pc020690;
	Mon, 9 Feb 2004 15:34:08 -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 i19KY8C2055850;
	Mon, 9 Feb 2004 15:34:09 -0500
Date: Mon, 9 Feb 2004 12:34:06 -0800 (PST)
From: Sridhar Samudrala <sri@us.ibm.com>
X-X-Sender: sridhar@localhost.localdomain
To: "David S. Miller" <davem@redhat.com>
cc: netdev@oss.sgi.com
Subject: Re: [BK PATCH] 2.6.2 SCTP updates
In-Reply-To: <20040209122647.1e8df80a.davem@redhat.com>
Message-ID: <Pine.LNX.4.58.0402091228320.10748@localhost.localdomain>
References: <Pine.LNX.4.58.0402061649001.10831@localhost.localdomain>
 <20040206194518.56787717.davem@redhat.com> <Pine.LNX.4.58.0402091155070.10043@localhost.localdomain>
 <20040209122647.1e8df80a.davem@redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 3146
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: 272
Lines: 9

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

>
> What is the status of synchronizing the 2.4.x SCTP sources?

It is going on well. I hope to get it done by the end of this week. Do you
want me to wait for 2.4.25 release? Or can i submit it even in the -rc phase?

-Sridhar

From niv@us.ibm.com Mon Feb  9 12:36:48 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 12:37:01 -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 i19KajKO011532
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 12:36:48 -0800
Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10])
	by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i19KadM3301594;
	Mon, 9 Feb 2004 15:36:39 -0500
Received: from us.ibm.com (d03av03.boulder.ibm.com [9.17.193.83])
	by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i19KacqG107662;
	Mon, 9 Feb 2004 13:36:39 -0700
Message-ID: <4027EECA.9000705@us.ibm.com>
Date: Mon, 09 Feb 2004 12:34:18 -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: Sridhar Samudrala <sri@us.ibm.com>
CC: "David S. Miller" <davem@redhat.com>, netdev@oss.sgi.com
Subject: Re: [BK PATCH] 2.6.2 SCTP updates
References: <Pine.LNX.4.58.0402061649001.10831@localhost.localdomain> <20040206194518.56787717.davem@redhat.com> <Pine.LNX.4.58.0402091155070.10043@localhost.localdomain>
In-Reply-To: <Pine.LNX.4.58.0402091155070.10043@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-archive-position: 3147
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
Content-Length: 566
Lines: 20

Sridhar Samudrala wrote:

> ChangeSet@1.1551, 2004-02-09 11:14:24-08:00, sri@us.ibm.com
>   [SCTP] Removed SCTP specific rmem/wmem sysctl's and use the global
>          rmem_default/wmem_default values for SCTP socket buffer sizes.

Sorry to pitch in on this so late - and I'm not suggesting
this was not the right thing to do here, but I feel that
having the per-protocol globals (as we do for TCP) is a
good thing, as then you don't affect all (raw, udp..)
traffic on the system just because someone is tuning
for SCTP, etc.

Just my 0.2c :)

thanks,
Nivedita




From davem@redhat.com Mon Feb  9 12:38:41 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 12:38:52 -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 i19KcfKO011942
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 12:38:41 -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 i19KcZb20525;
	Mon, 9 Feb 2004 15:38:35 -0500
Received: from devserv.devel.redhat.com ([172.16.58.1])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i19KJTa27476;
	Mon, 9 Feb 2004 15:19:29 -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 i19KIskC010304;
	Mon, 9 Feb 2004 15:18:56 -0500
Date: Mon, 9 Feb 2004 12:19:26 -0800
From: "David S. Miller" <davem@redhat.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru
Subject: Re: Change proxy_arp to respond only for valid neighbours
Message-Id: <20040209121926.6f016ebf.davem@redhat.com>
In-Reply-To: <Pine.LNX.4.58.0402082234110.6268@u.domain.uli>
References: <Pine.LNX.4.58.0402082234110.6268@u.domain.uli>
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: 3148
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: 979
Lines: 20

On Sun, 8 Feb 2004 22:44:05 +0200 (EET)
Julian Anastasov <ja@ssi.bg> wrote:

> - the 'skb->pkt_type == PACKET_HOST' check has no semantic anymore,
> the requestor should have same information no matter the packet
> type. In all cases we add response delay for all requests, broadcast
> or unicast, to help other authoritative hosts to reply before us.

Do we really want to reply to all the garbage tcpdump causes us
to capture?

That is what the pkt_type is dealing with.  If we're in promiscuous
mode, we'll hear ARP requests meant not for any of our devices, we
should not proxy for them right?

RTCF_*NAT is dead wood, the existing route nating stuff is totally broken
an unusable in 2.6.x, the eventual plan was to code up XFRM engine version
of that feature but this is of course not done.  Since nobody is complaining
about lack of routing NAT in 2.6.x, I think we should just kill off all references
and if someone gets inspired they can code up the XFRM engine version.

From davem@redhat.com Mon Feb  9 12:40:10 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 12:40:22 -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 i19Ke8KO012357
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 12:40:10 -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 i19Kdcb21215;
	Mon, 9 Feb 2004 15:39:38 -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 i19Kdci03748;
	Mon, 9 Feb 2004 15:39:38 -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 i19Kd5kC025462;
	Mon, 9 Feb 2004 15:39:05 -0500
Date: Mon, 9 Feb 2004 12:39:37 -0800
From: "David S. Miller" <davem@redhat.com>
To: Sridhar Samudrala <sri@us.ibm.com>
Cc: netdev@oss.sgi.com
Subject: Re: [BK PATCH] 2.6.2 SCTP updates
Message-Id: <20040209123937.7c2a3e3d.davem@redhat.com>
In-Reply-To: <Pine.LNX.4.58.0402091228320.10748@localhost.localdomain>
References: <Pine.LNX.4.58.0402061649001.10831@localhost.localdomain>
	<20040206194518.56787717.davem@redhat.com>
	<Pine.LNX.4.58.0402091155070.10043@localhost.localdomain>
	<20040209122647.1e8df80a.davem@redhat.com>
	<Pine.LNX.4.58.0402091228320.10748@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: 3149
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: 485
Lines: 10

On Mon, 9 Feb 2004 12:34:06 -0800 (PST)
Sridhar Samudrala <sri@us.ibm.com> wrote:

> It is going on well. I hope to get it done by the end of this week. Do you
> want me to wait for 2.4.25 release? Or can i submit it even in the -rc phase?

I would like to have it as soon as possible.  Not necessarily so that
it gets merged into 2.4.25 (I don't think I'll try to do that) but moreso
because I'd like to do review it now such that when 2.4.26-preX starts up
I can just push it along.

From davem@redhat.com Mon Feb  9 12:42:16 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 12:42:28 -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 i19KgFKO012727
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 12:42:15 -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 i19Kfkb22528;
	Mon, 9 Feb 2004 15:41:47 -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 i19Kfki04896;
	Mon, 9 Feb 2004 15:41:46 -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 i19KfDkC028970;
	Mon, 9 Feb 2004 15:41:13 -0500
Date: Mon, 9 Feb 2004 12:41:45 -0800
From: "David S. Miller" <davem@redhat.com>
To: Nivedita Singhvi <niv@us.ibm.com>
Cc: sri@us.ibm.com, netdev@oss.sgi.com
Subject: Re: [BK PATCH] 2.6.2 SCTP updates
Message-Id: <20040209124145.48de8d55.davem@redhat.com>
In-Reply-To: <4027EECA.9000705@us.ibm.com>
References: <Pine.LNX.4.58.0402061649001.10831@localhost.localdomain>
	<20040206194518.56787717.davem@redhat.com>
	<Pine.LNX.4.58.0402091155070.10043@localhost.localdomain>
	<4027EECA.9000705@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: 3150
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: 741
Lines: 20

On Mon, 09 Feb 2004 12:34:18 -0800
Nivedita Singhvi <niv@us.ibm.com> wrote:

> Sorry to pitch in on this so late - and I'm not suggesting
> this was not the right thing to do here, but I feel that
> having the per-protocol globals (as we do for TCP) is a
> good thing, as then you don't affect all (raw, udp..)
> traffic on the system just because someone is tuning
> for SCTP, etc.

I understand.

But there was no known reason to tweak things for SCTP.
If one wanted to adjust things system wide there was no
way for it to apply to SCTP too.

Also, the TCP controls are not as they would seem.  They don't
directly effect things like the sysctl*{rmem,wmem} stuff does,
rather it influences the dynamic socket buffer sizing which
TCP does.

From trondmy@ulrik.uio.no Mon Feb  9 12:49:11 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 12:49:22 -0800 (PST)
Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i19Kn7KO013542
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 12:49:10 -0800
Received: from mail-mx2.uio.no ([129.240.10.30])
	by pat.uio.no with esmtp (Exim 4.20)
	id 1AqIL1-00068Q-3j; Mon, 09 Feb 2004 21:49:03 +0100
Received: from mail-web2.uio.no ([129.240.10.46] helo=webmail.uio.no)
	by mail-mx2.uio.no with smtp (Exim 4.14)
	id 1AqIKx-00065T-Tk; Mon, 09 Feb 2004 21:48:59 +0100
Received: from ti221110a080-0832.bb.online.no ([80.213.3.64])
        (SquirrelMail authenticated user trondmy)
        by webmail.uio.no with HTTP;
        Mon, 9 Feb 2004 21:48:59 +0100 (CET)
Message-ID: <35059.80.213.3.64.1076359739.squirrel@webmail.uio.no>
Date: Mon, 9 Feb 2004 21:48:59 +0100 (CET)
Subject: Re: [NFS] [PATCH][RFC] use completions instead of sleep_on 
     forrpciod
From: trond.myklebust@fys.uio.no
To: "Olaf Kirch" <okir@suse.de>, "Christoph Hellwig" <hch@lst.de>
Cc: netdev@oss.sgi.com, nfs@lists.sourceforge.net
User-Agent: SquirrelMail/1.4.2
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3
Importance: Normal
References: <20040207144405.GA19416@lst.de> 
    <20040209102801.GC21364@suse.de>
In-Reply-To: <20040209102801.GC21364@suse.de>
X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning
X-UiO-MailScanner: No virus found
X-UiO-Spam-info: not spam, SpamAssassin (score=1.116, required 12,
	NO_REAL_NAME 0.28, PRIORITY_NO_NAME 0.83)
X-UiO-Spam-score: s
X-archive-position: 3152
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: trond.myklebust@fys.uio.no
Precedence: bulk
X-list: netdev
Content-Length: 954
Lines: 29

På må , 09/02/2004 klokka 11:28, skreiv Olaf Kirch:
> On Sat, Feb 07, 2004 at 03:44:05PM +0100, Christoph Hellwig wrote:
> > The rpciod shutdown code gives ugly sleep_on without BKL warnings in
-mm.  And it looks indeed somewhat racy.
>
> Yes, this code is indeed one of the areas that breaks when you use the
sunrpc code without the BKL. Another one was the missing spinlock in
xprt_alloc_xid. The code in fs/nfs/unlink.c is probably also racy
without BKL.
>
> So if you remove the sunrpc BKL be prepared for lots and lots
> of bug reports :)

Ahem....

xprt_alloc_xid is quite safe. It's always called under xprt->xprt_lock.

The code in unlink.c is only called from dentry_iput() or from
sillyrename(). In either case, there is no possibility for SMP races.

I'll admit that the rpciod killer code is racy, but I'm not sure that
completions are the best answer, as they have at least one nasty feature:
they are not interruptible.

Cheers,
  Trond




From niv@us.ibm.com Mon Feb  9 12:52:47 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 12:52:57 -0800 (PST)
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i19KqkKO013962
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 12:52:47 -0800
Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33])
	by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i19KqeOH400416;
	Mon, 9 Feb 2004 15:52:41 -0500
Received: from us.ibm.com (d03av03.boulder.ibm.com [9.17.193.83])
	by westrelay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i19Kqdkb076564;
	Mon, 9 Feb 2004 13:52:40 -0700
Message-ID: <4027F28A.40704@us.ibm.com>
Date: Mon, 09 Feb 2004 12:50:18 -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: "David S. Miller" <davem@redhat.com>
CC: sri@us.ibm.com, netdev@oss.sgi.com
Subject: Re: [BK PATCH] 2.6.2 SCTP updates
References: <Pine.LNX.4.58.0402061649001.10831@localhost.localdomain>	<20040206194518.56787717.davem@redhat.com>	<Pine.LNX.4.58.0402091155070.10043@localhost.localdomain>	<4027EECA.9000705@us.ibm.com> <20040209124145.48de8d55.davem@redhat.com>
In-Reply-To: <20040209124145.48de8d55.davem@redhat.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-archive-position: 3153
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
Content-Length: 526
Lines: 19

David S. Miller wrote:

> I understand.
> 
> But there was no known reason to tweak things for SCTP.

Yeah, I agree it doesn't matter right now for SCTP.
I don't know of anyone running SCTP *and* heavy NFS/raw
apps simultaneously. But they open up those socket
buffers for some real decent SCTP performance and
watch that unconstrained raw or udp traffic bludgeon
any congestion controlled streams like TCP and SCTP
out of the network. But this is a rather intrinsic
problem with other solutions, really..

thanks,
Nivedita



From davem@redhat.com Mon Feb  9 13:00:45 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 13:00:55 -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 i19L0jKO014852
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 13:00: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 i19L0bb00679;
	Mon, 9 Feb 2004 16:00: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 i19L0bi14344;
	Mon, 9 Feb 2004 16:00: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 i19L04kC012365;
	Mon, 9 Feb 2004 16:00:04 -0500
Date: Mon, 9 Feb 2004 13:00:36 -0800
From: "David S. Miller" <davem@redhat.com>
To: trond.myklebust@fys.uio.no
Cc: okir@suse.de, hch@lst.de, netdev@oss.sgi.com, nfs@lists.sourceforge.net
Subject: Re: [NFS] [PATCH][RFC] use completions instead of sleep_on 
 forrpciod
Message-Id: <20040209130036.613a9bdd.davem@redhat.com>
In-Reply-To: <35059.80.213.3.64.1076359739.squirrel@webmail.uio.no>
References: <20040207144405.GA19416@lst.de>
	<20040209102801.GC21364@suse.de>
	<35059.80.213.3.64.1076359739.squirrel@webmail.uio.no>
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: 3154
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: 335
Lines: 9

On Mon, 9 Feb 2004 21:48:59 +0100 (CET)
trond.myklebust@fys.uio.no wrote:

> I'll admit that the rpciod killer code is racy, but I'm not sure that
> completions are the best answer, as they have at least one nasty feature:
> they are not interruptible.

Would you like to back out the change then?  I put it into
Linus's tree already.

From jmorris@redhat.com Mon Feb  9 13:26:56 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 13:27:08 -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 i19LQuKO015673
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 13:26:56 -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 i19LQnb13413;
	Mon, 9 Feb 2004 16:26:49 -0500
Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i19LQli23506;
	Mon, 9 Feb 2004 16:26:47 -0500
Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238])
	by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i19LQk03012810;
	Mon, 9 Feb 2004 16:26:46 -0500
Date: Mon, 9 Feb 2004 16:26:46 -0500 (EST)
From: James Morris <jmorris@redhat.com>
X-X-Sender: jmorris@thoron.boston.redhat.com
To: "David S. Miller" <davem@redhat.com>
cc: Julian Anastasov <ja@ssi.bg>, <netdev@oss.sgi.com>, <kuznet@ms2.inr.ac.ru>
Subject: Re: Change proxy_arp to respond only for valid neighbours
In-Reply-To: <20040209121926.6f016ebf.davem@redhat.com>
Message-ID: <Xine.LNX.4.44.0402091626260.3557-100000@thoron.boston.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 3155
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: jmorris@redhat.com
Precedence: bulk
X-list: netdev
Content-Length: 505
Lines: 17

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

> RTCF_*NAT is dead wood, the existing route nating stuff is totally broken
> an unusable in 2.6.x, the eventual plan was to code up XFRM engine version
> of that feature but this is of course not done.  Since nobody is complaining
> about lack of routing NAT in 2.6.x, I think we should just kill off all references
> and if someone gets inspired they can code up the XFRM engine version.

Sounds like a plan.


- James
-- 
James Morris
<jmorris@redhat.com>



From greearb@candelatech.com Mon Feb  9 13:40:07 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 13:40:17 -0800 (PST)
Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i19Le7KO016174
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 13:40:07 -0800
Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74])
	(authenticated bits=0)
	by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i19Ldp9v032575;
	Mon, 9 Feb 2004 13:39:51 -0800
Message-ID: <4027FE27.9020102@candelatech.com>
Date: Mon, 09 Feb 2004 13:39:51 -0800
From: Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "David S. Miller" <davem@redhat.com>
CC: Julian Anastasov <ja@ssi.bg>, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru
Subject: Re: Change proxy_arp to respond only for valid neighbours
References: <Pine.LNX.4.58.0402082234110.6268@u.domain.uli> <20040209121926.6f016ebf.davem@redhat.com>
In-Reply-To: <20040209121926.6f016ebf.davem@redhat.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-archive-position: 3156
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: greearb@candelatech.com
Precedence: bulk
X-list: netdev
Content-Length: 816
Lines: 26

David S. Miller wrote:
> On Sun, 8 Feb 2004 22:44:05 +0200 (EET)
> Julian Anastasov <ja@ssi.bg> wrote:
> 
> 
>>- the 'skb->pkt_type == PACKET_HOST' check has no semantic anymore,
>>the requestor should have same information no matter the packet
>>type. In all cases we add response delay for all requests, broadcast
>>or unicast, to help other authoritative hosts to reply before us.
> 
> 
> Do we really want to reply to all the garbage tcpdump causes us
> to capture?
> 
> That is what the pkt_type is dealing with.  If we're in promiscuous
> mode, we'll hear ARP requests meant not for any of our devices, we
> should not proxy for them right?

Arp requests are always broadcasts, so promisc changes nothing,
right?


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From davem@redhat.com Mon Feb  9 13:46:04 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 13:46:13 -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 i19Lk3KO016580
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 13:46: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 i19Ljrb22495;
	Mon, 9 Feb 2004 16:45: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 i19Ljqi29621;
	Mon, 9 Feb 2004 16:45: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 i19LjJkC003146;
	Mon, 9 Feb 2004 16:45:19 -0500
Date: Mon, 9 Feb 2004 13:45:51 -0800
From: "David S. Miller" <davem@redhat.com>
To: Ben Greear <greearb@candelatech.com>
Cc: ja@ssi.bg, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru
Subject: Re: Change proxy_arp to respond only for valid neighbours
Message-Id: <20040209134551.3bd533a2.davem@redhat.com>
In-Reply-To: <4027FE27.9020102@candelatech.com>
References: <Pine.LNX.4.58.0402082234110.6268@u.domain.uli>
	<20040209121926.6f016ebf.davem@redhat.com>
	<4027FE27.9020102@candelatech.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: 3157
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: 728
Lines: 18

On Mon, 09 Feb 2004 13:39:51 -0800
Ben Greear <greearb@candelatech.com> wrote:

> Arp requests are always broadcasts, so promisc changes nothing,
> right?

Unicast probes are possible.

If it is broadcast/multicast then pkt_type will be PACKET_{BROAD,MULTI}CAST.

The existing ipv4 proxy-arp code is saying (as I read it) to not delay the
response if this is a unicast probe.  This is one of the behaviors that
Julian is modifying slightly.

For everyone's edification, when looking at changes Julian is suggesting, realize
that his interests lie in IPVS like applications, so consider the corner case
situations that such setups might be interested in and you'll see clearly the
impetus for all of his ARP change proposals :-)

From kenneth.krekula@kiruna.se Mon Feb  9 13:50:50 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 13:51:02 -0800 (PST)
Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73])
	by oss.sgi.com (8.12.10/8.12.9) with SMTP id i19LoiKO016991
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 13:50:45 -0800
Received: from [192.168.0.126] ([213.114.123.43] [213.114.123.43])
          by mxfep02.bredband.com with ESMTP
          id <20040209215028.FNGB16874.mxfep02.bredband.com@[192.168.0.126]>;
          Mon, 9 Feb 2004 22:50:28 +0100
From: Kenneth Krekula <kenneth.krekula@kiruna.se>
To: netdev@oss.sgi.com
Subject: A small forcedeth driver issue
Date: Mon, 9 Feb 2004 22:52:22 +0100
User-Agent: KMail/1.6.1
Cc: c-d.hailfinger.kernel.2004@gmx.net
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <200402092252.22540.kenneth.krekula@kiruna.se>
X-archive-position: 3158
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: kenneth.krekula@kiruna.se
Precedence: bulk
X-list: netdev
Content-Length: 535
Lines: 17

Hi.

I have a NForce1 motherboard and have tested the forcedeth driver with the 
Mandrake 10 betas. The driver works very well (thanks for the great work!!) 
and I only have a small issue:

If I have been using the driver in Mandrake 10 beta 2, and reboot into Win XP 
or Mandrake Linux 9.2 (with the NVIdia NForce drivers) the network just 
fails. 

However, if I shut off the power switch and wait for some seconds, I can power 
on and boot into Win XP, Mandrake 9.2.

I don't know if this is a known issue or not.

Regards,
Kenneth

From davem@redhat.com Mon Feb  9 13:58:51 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 13:59:01 -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 i19LwoKO017488
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 13:58:50 -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 i19Lwib28907;
	Mon, 9 Feb 2004 16:58:44 -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 i19Lwii01800;
	Mon, 9 Feb 2004 16:58:44 -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 i19LwAkC010660;
	Mon, 9 Feb 2004 16:58:11 -0500
Date: Mon, 9 Feb 2004 13:58:43 -0800
From: "David S. Miller" <davem@redhat.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru
Subject: Re: Change proxy_arp to respond only for valid neighbours
Message-Id: <20040209135843.42b5b67e.davem@redhat.com>
In-Reply-To: <Pine.LNX.4.58.0402082234110.6268@u.domain.uli>
References: <Pine.LNX.4.58.0402082234110.6268@u.domain.uli>
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: 3159
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: 1220
Lines: 32

On Sun, 8 Feb 2004 22:44:05 +0200 (EET)
Julian Anastasov <ja@ssi.bg> wrote:

> +				if (skb->stamp.tv_sec) {

Julian, do you understand what this check is for?

If it is zero, this means we are being reinvoked via the delayed proxy queue.
It means that some previously delayed response has been kicked so that we
should respond to it right now, with no delay, no matter what.

Otherwise you could loop delaying the thing forever.  If there is a case
where some pneigh ARP request should be evaluated multiple times, such
a change belongs in the pneigh_*() code not here in ipv4 arp processing.

The exact path is:

1) All input packets get skb->stamp.tv_sec assigned to in net/core/dev.c at
   the waaaay beginning of input packet processing...

2) Therefore the first time skb goes through arp_rcv() skb->tv_sec will be
   non-zero.

3) If it is pneigh_enqueue()'d, then skb->stamp.tv_sec will be set to zero
   therefore upon reprocessing by arp_rcv() it will be seen as zero and this
   is how such a state is detected.

Yes, I hate all of these overloaded meanings of skb->stamp.tv_* as much as
anyone else.

This is my contribution wrt. this suggested patch today, it's your turn to
make some commentary Julian :-)

From davem@redhat.com Mon Feb  9 14:09:05 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 14:09:17 -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 i19M95KO017960
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 14:09:05 -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 i19M8tb01421;
	Mon, 9 Feb 2004 17:08:55 -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 i19M8ti06009;
	Mon, 9 Feb 2004 17:08:55 -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 i19M8LkC015866;
	Mon, 9 Feb 2004 17:08:22 -0500
Date: Mon, 9 Feb 2004 14:08:53 -0800
From: "David S. Miller" <davem@redhat.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org
Subject: Re: Restrict local IP announcements in ARP requests
Message-Id: <20040209140853.69ab8bea.davem@redhat.com>
In-Reply-To: <Pine.LNX.4.58.0402081149001.6268@u.domain.uli>
References: <Pine.LNX.4.58.0402081149001.6268@u.domain.uli>
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: 3160
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: 797
Lines: 21

On Sun, 8 Feb 2004 11:59:35 +0200 (EET)
Julian Anastasov <ja@ssi.bg> wrote:

> 	I'm proposing simple flag that controls the src selection
> in our ARP requests. I named it arp_announce - mode used to define
> different restriction levels for announcing the local source address
> from IP packets in ARP requests:

I'm fine with this patch, although it appears incomplete because:

> 2 - always use the best source address for this target

The code handling this case is "#if 0/#endif" commented out in your
patch.

Finish this thing up, and as a birthday present to everyone I'll also
add an IN_DEV_ARP_IGNORE flag for inet devices to so people can control
complete ARP ignoring via a global/per-device sysctl.

Hopefully, combined, this will get all the virtual server maniacs off
of my back :-)

From davem@redhat.com Mon Feb  9 14:20:24 2004
Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 14:20:32 -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 i19MKNKO018623
	for <netdev@oss.sgi.com>; Mon, 9 Feb 2004 14:20:23 -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 i19MKFb07172;
	Mon, 9 Feb 2004 17:20: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 i19MKFi10494;
	Mon, 9 Feb 2004 17:20:15 -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 i19MJgkC022285;
	Mon, 9 Feb 2004 17:19:42 -0500
Date: Mon, 9 Feb 2004 14:20:14 -0800
From: "David S. Miller" <davem@redhat.com>
To: "David S. Miller" <davem@redhat.com>
Cc: ja@ssi.bg, netdev@oss.sgi.com, linux-net@vger.kernel.org
Subject: Re: Restrict local IP announcements in ARP requests
Message-Id: <20040209142014.413209d7.davem@redhat.com>
In-Reply-To: <20040209140853.69ab8bea.davem@redhat.com>
References: <Pine.LNX.4.58.0402081149001.6268@u.domain.uli>
	<20040209140853.69ab8bea.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: 3161
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: 3534
Lines: 103

On Mon, 9 Feb 2004 14:08:53 -0800
"David S. Miller" <davem@redhat.com> wrote:

> as a birthday present to everyone I'll also add an IN_DEV_ARP_IGNORE
> flag for inet devices to so people can control
> complete ARP ignoring via a global/per-device sysctl.

Ok, does this do what everyone wants?  Speak now or forever hold your peace
on this issue :-)

I'll add this to 2.6.x and 2.4.x if folks are OK with it.  Write this date
down on your calendars, I doubt I'll capitulate like this ever again 8-)

===== Documentation/networking/ip-sysctl.txt 1.20 vs edited =====
--- 1.20/Documentation/networking/ip-sysctl.txt	Mon Feb  2 10:20:58 2004
+++ edited/Documentation/networking/ip-sysctl.txt	Mon Feb  9 14:08:57 2004
@@ -499,6 +499,15 @@
 	conf/{all,interface}/arp_filter is set to TRUE,
 	it will be disabled otherwise
 
+arp_ignore - BOOLEAN
+	0 - (default) Process ARP requests.
+	1 - Ignore ARP requests.
+
+	ARP requests received on a given interface will be ignored if
+	at least one of conf/{all,interface}/arp_ignore is set to TRUE.
+	ARP requests will be processed otherwise (barring any other
+	restrictive controls such as 'arp_filter' documented above).
+
 tag - INTEGER
 	Allows you to write a number, which can be used as required.
 	Default value is 0.
===