From yoshfuji@linux-ipv6.org Sat Nov 1 03:01:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 03:02:02 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA1B1R25009335 for ; Sat, 1 Nov 2003 03:01:28 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-6.6) with ESMTP id hA1B1Wlg018026; Sat, 1 Nov 2003 20:01:33 +0900 Date: Sat, 01 Nov 2003 20:01:32 +0900 (JST) Message-Id: <20031101.200132.55114465.yoshfuji@linux-ipv6.org> To: davem@redhat.com CC: netdev@oss.sgi.com Subject: [PATCH] IPV{4,6}: Fix one more inappropriate use of inet6_sk()->ipv6only From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA 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/MEaZBLP 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: 1166 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. Sorry, I forgot to fix this one... ===== net/ipv4/tcp_ipv4.c 1.75 vs edited ===== --- 1.75/net/ipv4/tcp_ipv4.c Tue Oct 28 20:10:47 2003 +++ edited/net/ipv4/tcp_ipv4.c Sat Nov 1 19:36:45 2003 @@ -187,7 +187,7 @@ sk_for_each_bound(sk2, node, &tb->owners) { if (sk != sk2 && - !ipv6_only_sock(sk2) && + !tcp_v6_ipv6only(sk2) && (!sk->sk_bound_dev_if || !sk2->sk_bound_dev_if || sk->sk_bound_dev_if == sk2->sk_bound_dev_if)) { -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From daniel.blueman@gmx.net Sat Nov 1 10:13:34 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 10:14:08 -0800 (PST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA1IDX25019208 for ; Sat, 1 Nov 2003 10:13:34 -0800 Received: (qmail 13073 invoked by uid 0); 1 Nov 2003 18:13:27 -0000 Received: from 81.107.229.142 by www6.gmx.net with HTTP; Sat, 1 Nov 2003 19:13:27 +0100 (MET) Date: Sat, 1 Nov 2003 19:13:27 +0100 (MET) From: "Daniel Blueman" To: "David S. Miller" Cc: devik@cdi.cz, netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org MIME-Version: 1.0 References: <20031030130859.605f856d.davem@redhat.com> Subject: Re: [2.6.0-test9] QoS HTB crash... X-Priority: 3 (Normal) X-Authenticated: #8973862 Message-ID: <4371.1067710407@www6.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-archive-position: 1167 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: daniel.blueman@gmx.net Precedence: bulk X-list: netdev Having applied this patch, I still get this issue when I kill pppd: Oops: 0002 [#1] CPU: 0 >>EIP; c02ced99 <===== >>ebx; d9c0586c <_end+19797f60/3fb906f4> >>ecx; dc95adf8 <_end+1c4ed4ec/3fb906f4> >>edx; d9c057f8 <_end+19797eec/3fb906f4> >>esi; dc95adf8 <_end+1c4ed4ec/3fb906f4> >>edi; df4eceac <_end+1f07f5a0/3fb906f4> >>ebp; d9c4bdfc <_end+197de4f0/3fb906f4> >>esp; d9c4bde4 <_end+197de4d8/3fb906f4> Trace; c011a647 Trace; c02d3876 Trace; c02d3b1f Trace; c02d3b5e Trace; c011a647 Trace; c02d3cc4 Trace; c02ce073 Trace; c02cdedc Trace; c02ce112 Trace; c02c1ea9 Trace; c02c260a Trace; c01398e8 Trace; c02b59e2 Trace; c02bd6ce Trace; c0235f8c Trace; c023c1ce Trace; c0183836 Trace; c016527c <__fput+7c/cd> Trace; c02363a5 Trace; c01652bb <__fput+bb/cd> Trace; c0163353 Trace; c0163481 Trace; c010a3eb Code; c02ced99 00000000 <_EIP>: Code; c02ced99 <===== 0: 83 ae 58 01 00 00 01 subl $0x1,0x158(%esi) <===== Code; c02ceda0 7: 8b 5d f8 mov 0xfffffff8(%ebp),%ebx Code; c02ceda3 a: 8b 75 fc mov 0xfffffffc(%ebp),%esi Code; c02ceda6 d: 89 ec mov %ebp,%esp Code; c02ceda8 f: 5d pop %ebp Code; c02ceda9 10: c3 ret Code; c02cedaa 11: 83 ab 3c 00 00 00 00 subl $0x0,0x3c(%ebx) <0>Kernel panic: Fatal exception in interrupt --- > On Thu, 30 Oct 2003 20:50:16 +0100 (CET) > devik wrote: > > > thanks for the report. I know that there is an issue regarding > > HTB in 2.6.x. Please send me net/sched/sch_htb.o, > > net/sched/sch_htb.c (just to be sure) and be sure that you > > build the kernel with debugging symbols (see debugging section > > of menuconfig/xconfig). > > I think the problem is the changes that were made > in 2.5.x to htb_next_rb_node(). It used to be: > > static void htb_next_rb_node(rb_node_t **n) > { > rb_node_t *p; > if ((*n)->rb_right) { > /* child at right. use it or its leftmost ancestor */ > *n = (*n)->rb_right; > while ((*n)->rb_left) > *n = (*n)->rb_left; > return; > } > while ((p = (*n)->rb_parent) != NULL) { > /* if we've arrived from left child then we have next node > */ > if (p->rb_left == *n) break; > *n = p; > } > *n = p; > } > > But it was changed into: > > static void htb_next_rb_node(struct rb_node **n) > { > *n = rb_next(*n); > } > > This is wrong, the new code has much different side effects > than the original code. > > This looks like the problem, devik what do you think? > -- Daniel J Blueman NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ From akpm@osdl.org Sat Nov 1 13:34:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 13:34:55 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA1LXu25023712 for ; Sat, 1 Nov 2003 13:34:16 -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 hA1LXhC16609; Sat, 1 Nov 2003 13:33:46 -0800 Date: Sat, 1 Nov 2003 13:36:01 -0800 From: Andrew Morton To: Stian Jordet Cc: netdev@oss.sgi.com Subject: Re: Oops at "NET: Registering protocol family 23" at boot with 2.6.0t9-bk Message-Id: <20031101133601.7cf12497.akpm@osdl.org> In-Reply-To: <1067705386.666.1.camel@chevrolet.hybel> References: <1067705386.666.1.camel@chevrolet.hybel> 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: 1168 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 Stian Jordet wrote: > > Hello, > kernel 2.6.0-test9 works perfect here, but with the latest cset I get > the attached oops at boottime. Hope this helps someone. > Please send your .config. > NET: Registered protocol family 23 > Unable to handle kernel NULL pointer dereference at virtual address 00000004 > printing eip: > c03de40d > *pde = 00000000 > Oops: 0002 [#1] > CPU: 0 > CIP: 0060:[] Not tainted > EFLAGS: 00010202 > EIP is at dev_add_pack+0x4d/0xb0 > eax: 00000038 ebx: c062f2f8 ecx: 00000000 edx: c05799e0 > esi: c05799d0 edi: 00000000 ebp: 00000000 esp: c152ffb4 > ds: 007b es: 007b ss: 0068 > Process swapper (pid: 1, threadinfo=c152e000 task=dff8f900) > Stack: c05e7fc8 00000001 c05defad c05799d0 c04af833 c05c094c 00000000 00000000 > c01359af 00000000 c152e000 c01050f6 00000002 c01050a0 00000000 c01072b9 > 00000000 00000000 00000000 > Call Trace: > [] irda_init+0x3d/0x60 > [] do_initcalls+0x2c/0xa0 > [] init_workqueues+0xf/0x24 > [] init+0x56/0x180 > [] init+0x0/0x180 > [] kernel_thread_helper+0x5/0xc > > Code: 89 51 04 89 90 c0 f2 62 c0 c6 05 40 3c 57 c0 01 b8 00 e0 ff > (0)Kernel panic: Fatal exception in interrupt > In interrupt handler - not syncing > > > From liste@jordet.nu Sat Nov 1 13:54:14 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 13:54:51 -0800 (PST) Received: from dodge.hybel (root@dodge.jordet.nu [217.13.8.142]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA1Lro25024174 for ; Sat, 1 Nov 2003 13:54:11 -0800 Received: from chevrolet.hybel (stianj@chevrolet.hybel [192.168.0.2]) by dodge.hybel (8.12.3/8.12.3/Debian-6.6) with ESMTP id hA1LreuY024928 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 1 Nov 2003 22:53:41 +0100 Subject: Re: Oops at "NET: Registering protocol family 23" at boot with 2.6.0t9-bk From: Stian Jordet To: Andrew Morton Cc: netdev@oss.sgi.com In-Reply-To: <20031101133601.7cf12497.akpm@osdl.org> References: <1067705386.666.1.camel@chevrolet.hybel> <20031101133601.7cf12497.akpm@osdl.org> Content-Type: multipart/mixed; boundary="=-CXZmLYdmid/PKgG6qYdK" Message-Id: <1067723628.643.0.camel@chevrolet.hybel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 01 Nov 2003 22:53:48 +0100 X-archive-position: 1169 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: liste@jordet.nu Precedence: bulk X-list: netdev --=-CXZmLYdmid/PKgG6qYdK Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dodge.hybel id hA1LreuY024928 l=F8r, 01.11.2003 kl. 22.36 skrev Andrew Morton: > Stian Jordet wrote: > > > > Hello, > > kernel 2.6.0-test9 works perfect here, but with the latest cset I get > > the attached oops at boottime. Hope this helps someone. > >=20 >=20 > Please send your .config. Here you are :) Thanks for looking into this :) Best regards, Stian > > NET: Registered protocol family 23 > > Unable to handle kernel NULL pointer dereference at virtual address 0= 0000004 > > printing eip: > > c03de40d > > *pde =3D 00000000 > > Oops: 0002 [#1] > > CPU: 0 > > CIP: 0060:[] Not tainted > > EFLAGS: 00010202 > > EIP is at dev_add_pack+0x4d/0xb0 > > eax: 00000038 ebx: c062f2f8 ecx: 00000000 edx: c05799e0 > > esi: c05799d0 edi: 00000000 ebp: 00000000 esp: c152ffb4 > > ds: 007b es: 007b ss: 0068 > > Process swapper (pid: 1, threadinfo=3Dc152e000 task=3Ddff8f900) > > Stack: c05e7fc8 00000001 c05defad c05799d0 c04af833 c05c094c 00000000= 00000000 > > c01359af 00000000 c152e000 c01050f6 00000002 c01050a0 00000000= c01072b9 > > 00000000 00000000 00000000 > > Call Trace: > > [] irda_init+0x3d/0x60 > > [] do_initcalls+0x2c/0xa0 > > [] init_workqueues+0xf/0x24 > > [] init+0x56/0x180 > > [] init+0x0/0x180 > > [] kernel_thread_helper+0x5/0xc > > =20 > > Code: 89 51 04 89 90 c0 f2 62 c0 c6 05 40 3c 57 c0 01 b8 00 e0 ff > > (0)Kernel panic: Fatal exception in interrupt > > In interrupt handler - not syncing > > =20 > >=20 > >=20 --=-CXZmLYdmid/PKgG6qYdK Content-Disposition: attachment; filename=config-2.6.0-test9 Content-Type: text/plain; name=config-2.6.0-test9; charset=iso-8859-1 Content-Transfer-Encoding: 7bit # # 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=y # CONFIG_CLEAN_COMPILE is not set CONFIG_STANDALONE=y CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # 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 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set 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 is not set CONFIG_MPENTIUMIII=y # 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=y CONFIG_NR_CPUS=2 CONFIG_PREEMPT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # CONFIG_EDD 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_HAVE_DEC_LOCK=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_SOFTWARE_SUSPEND=y # CONFIG_PM_DISK is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_FAN is not set CONFIG_ACPI_PROCESSOR=y # CONFIG_ACPI_THERMAL is not set # 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 # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM 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_LEGACY_PROC is not set CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=y CONFIG_YENTA=y CONFIG_CARDBUS=y # CONFIG_I82092 is not set # CONFIG_TCIC is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_MISC=y # # 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=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_CML1=y # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_PC_PCMCIA is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # # CONFIG_ISAPNP is not set CONFIG_PNPBIOS=y # # Block devices # CONFIG_BLK_DEV_FD=y # 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_UMEM is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_LBD is not set # # 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 is not set # CONFIG_IDEDISK_STROKE is not set CONFIG_BLK_DEV_IDECS=y # CONFIG_BLK_DEV_IDECD is not set # CONFIG_BLK_DEV_IDETAPE is not set CONFIG_BLK_DEV_IDEFLOPPY=y # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set # CONFIG_IDE_TASKFILE_IO 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 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDE_TCQ is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_IDEDMA_PCI_WIP 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_CS5520 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 is not set # 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=y 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=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=y # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_REPORT_LUNS is not set # 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_ACARD is not set # CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=253 CONFIG_AIC7XXX_RESET_DELAY_MS=5000 # CONFIG_AIC7XXX_PROBE_EISA_VL is not set # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D 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_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I 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_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # PCMCIA SCSI adapter support # # CONFIG_PCMCIA_AHA152X is not set # CONFIG_PCMCIA_FDOMAIN is not set # CONFIG_PCMCIA_NINJA_SCSI is not set # CONFIG_PCMCIA_QLOGIC is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK_DEV is not set CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # 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_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 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=y CONFIG_IP_NF_FTP=y CONFIG_IP_NF_IRC=y # CONFIG_IP_NF_TFTP is not set # CONFIG_IP_NF_AMANDA is not set CONFIG_IP_NF_QUEUE=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y # CONFIG_IP_NF_MATCH_IPRANGE is not set CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_PKTTYPE=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_RECENT=y CONFIG_IP_NF_MATCH_ECN=y CONFIG_IP_NF_MATCH_DSCP=y CONFIG_IP_NF_MATCH_AH_ESP=y CONFIG_IP_NF_MATCH_LENGTH=y CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_MATCH_TCPMSS=y CONFIG_IP_NF_MATCH_HELPER=y CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_CONNTRACK=y CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y # CONFIG_IP_NF_TARGET_NETMAP is not set # CONFIG_IP_NF_TARGET_SAME is not set CONFIG_IP_NF_NAT_LOCAL=y CONFIG_IP_NF_NAT_SNMP_BASIC=y CONFIG_IP_NF_NAT_IRC=y CONFIG_IP_NF_NAT_FTP=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y CONFIG_IP_NF_TARGET_ECN=y CONFIG_IP_NF_TARGET_DSCP=y CONFIG_IP_NF_TARGET_MARK=y # CONFIG_IP_NF_TARGET_CLASSIFY is not set CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_ULOG=y CONFIG_IP_NF_TARGET_TCPMSS=y CONFIG_IP_NF_ARPTABLES=y # CONFIG_IP_NF_ARPFILTER is not set CONFIG_IP_NF_ARP_MANGLE=y # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=y # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB 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 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 is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_HP100 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_B44 is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set CONFIG_E100=y # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE 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_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 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_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=y CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=y CONFIG_PPP_SYNC_TTY=y CONFIG_PPP_DEFLATE=y CONFIG_PPP_BSDCOMP=y # CONFIG_PPPOE is not set # 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 # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # PCMCIA network device support # CONFIG_NET_PCMCIA=y # CONFIG_PCMCIA_3C589 is not set # CONFIG_PCMCIA_3C574 is not set # CONFIG_PCMCIA_FMVJ18X is not set CONFIG_PCMCIA_PCNET=y # CONFIG_PCMCIA_NMCLAN is not set # CONFIG_PCMCIA_SMC91C92 is not set # CONFIG_PCMCIA_XIRC2PS is not set # CONFIG_PCMCIA_AXNET is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # CONFIG_IRDA=y # # IrDA protocols # # CONFIG_IRLAN is not set # CONFIG_IRNET is not set CONFIG_IRCOMM=y # CONFIG_IRDA_ULTRA is not set # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y CONFIG_IRDA_DEBUG=y # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=y # # Dongle support # # CONFIG_DONGLE is not set # # Old SIR device drivers # # CONFIG_IRPORT_SIR is not set # # Old Serial dongle support # # # FIR device drivers # # CONFIG_USB_IRDA is not set # CONFIG_TOSHIBA_FIR is not set # CONFIG_VLSI_FIR is not set # # Bluetooth support # CONFIG_BT=y CONFIG_BT_L2CAP=y CONFIG_BT_SCO=y CONFIG_BT_RFCOMM=y CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=y CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m # CONFIG_BT_USB_SCO is not set # CONFIG_BT_USB_ZERO_PACKET is not set # CONFIG_BT_HCIUART is not set # CONFIG_BT_HCIDTL1 is not set # CONFIG_BT_HCIBT3C is not set # CONFIG_BT_HCIBLUECARD is not set # CONFIG_BT_HCIBTUART is not set # CONFIG_BT_HCIVHCI is not set # # ISDN subsystem # # CONFIG_ISDN_BOOL 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=y # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # CONFIG_GAMEPORT=y CONFIG_SOUND_GAMEPORT=y # CONFIG_GAMEPORT_NS558 is not set # CONFIG_GAMEPORT_L4 is not set CONFIG_GAMEPORT_EMU10K1=y # CONFIG_GAMEPORT_VORTEX is not set # CONFIG_GAMEPORT_FM801 is not set # CONFIG_GAMEPORT_CS461x is not set 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_PS2_SYNAPTICS is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=y # CONFIG_INPUT_UINPUT 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 is not set # CONFIG_SERIAL_8250_CS is not set # 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_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # CONFIG_PRINTER is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR is not set # # I2C support # CONFIG_I2C=y # CONFIG_I2C_CHARDEV is not set # # I2C Algorithms # # CONFIG_I2C_ALGOBIT is not set # CONFIG_I2C_ALGOPCF is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set CONFIG_I2C_VIAPRO=y # # I2C Hardware Sensors Chip support # CONFIG_I2C_SENSOR=y # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_VIA686A is not set CONFIG_SENSORS_W83781D=y # # 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=y CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=m # 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 is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set CONFIG_AGP_VIA=m # CONFIG_DRM is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS 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=y # # Video For Linux # # # Video Adapters # # CONFIG_VIDEO_BWQCAM is not set # CONFIG_VIDEO_CQCAM is not set # CONFIG_VIDEO_W9966 is not set # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set # CONFIG_VIDEO_ZR36120 is not set CONFIG_VIDEO_SAA7134=y # 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_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set CONFIG_VIDEO_TUNER=y CONFIG_VIDEO_BUF=y # CONFIG_VIDEO_BTCX is not set # # Graphics support # CONFIG_FB=y # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y # CONFIG_FB_HGA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_MATROX is not set CONFIG_FB_RADEON=y # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # 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_PM3 is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=m CONFIG_PCI_CONSOLE=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Logo configuration # CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_LOGO_LINUX_CLUT224=y # # Sound # CONFIG_SOUND=y # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_SEQUENCER=m # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set CONFIG_SND_MPU401=m # # PCI devices # # CONFIG_SND_ALI5451 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set CONFIG_SND_EMU10K1=m # CONFIG_SND_KORG1212 is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VX222 is not set # # ALSA USB devices # # CONFIG_SND_USB_AUDIO is not set # # PCMCIA devices # # CONFIG_SND_VXPOCKET is not set # CONFIG_SND_VXP440 is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # # USB Host Controller Drivers # # CONFIG_USB_EHCI_HCD is not set # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=y # # 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=y CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # # USB Human Interface Devices (HID) # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # 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_MDC800 is not set CONFIG_USB_SCANNER=y # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_PWC is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_STV680 is not set # # USB Network adaptors # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 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=m # CONFIG_USB_SERIAL_GENERIC is not set # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_EDGEPORT_TI is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_KOBIL_SCT is not set # CONFIG_USB_SERIAL_MCT_U232 is not set CONFIG_USB_SERIAL_PL2303=m # CONFIG_USB_SERIAL_SAFE is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set # CONFIG_USB_SERIAL_OMNINET is not set # # USB Miscellaneous drivers # # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_BRLVGER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_TEST is not set # CONFIG_USB_GADGET is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y CONFIG_XFS_POSIX_ACL=y # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_QUOTA=y # CONFIG_QFMT_V1 is not set # CONFIG_QFMT_V2 is not set CONFIG_QUOTACTL=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_NTFS_FS=y # CONFIG_NTFS_DEBUG is not set # CONFIG_NTFS_RW is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y # CONFIG_DEVFS_FS is not set 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_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # 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=y CONFIG_NFS_V3=y CONFIG_NFS_V4=y # CONFIG_NFS_DIRECTIO is not set # CONFIG_NFSD is not set CONFIG_LOCKD=y CONFIG_LOCKD_V4=y # CONFIG_EXPORTFS is not set CONFIG_SUNRPC=y # CONFIG_SUNRPC_GSS is not set CONFIG_SMB_FS=y # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-15" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=y # 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=y # 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=y # 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=y # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_IOVIRT is not set # CONFIG_MAGIC_SYSRQ is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_FRAME_POINTER is not set 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 is not set # # Library routines # CONFIG_CRC32=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_PC=y --=-CXZmLYdmid/PKgG6qYdK-- From akpm@osdl.org Sat Nov 1 16:01:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 16:02:35 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA201d25026191 for ; Sat, 1 Nov 2003 16:01:59 -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 hA201VC01085; Sat, 1 Nov 2003 16:01:31 -0800 Date: Sat, 1 Nov 2003 16:03:50 -0800 From: Andrew Morton To: Stian Jordet Cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: Oops at "NET: Registering protocol family 23" at boot with 2.6.0t9-bk Message-Id: <20031101160350.2f1fe0af.akpm@osdl.org> In-Reply-To: <1067723628.643.0.camel@chevrolet.hybel> References: <1067705386.666.1.camel@chevrolet.hybel> <20031101133601.7cf12497.akpm@osdl.org> <1067723628.643.0.camel@chevrolet.hybel> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) 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 hA201d25026191 X-archive-position: 1170 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 Stian Jordet wrote: > > lør, 01.11.2003 kl. 22.36 skrev Andrew Morton: > > Stian Jordet wrote: > > > > > > Hello, > > > kernel 2.6.0-test9 works perfect here, but with the latest cset I get > > > the attached oops at boottime. Hope this helps someone. > > > > > > > Please send your .config. > > Here you are :) Thanks for looking into this :) OK, it goes bang because ptype_all has not been initialised yet. This is because net_dev_init() is fs_initcall, and irda_init() is subsys_initcall - irda_init() runs before net_dev_init(). Dave, I'm not sure what's the best thing to do here - I was afraid that the initcall level shuffling was a bit premature. IRDA doesn't look flexible (hugs to JT for commenting this nicely): /* * The IrDA stack must be initialised *before* drivers get initialised, * and *before* higher protocols (IrLAN/IrCOMM/IrNET) get initialised, * otherwise bad things will happen (hashbins will be NULL for example). * Those modules are at module_init()/device_initcall() level. * * On the other hand, it needs to be initialised *after* the basic * networking, the /proc/net filesystem and sysctl module. Those are * currently initialised in .../init/main.c (before initcalls). * Also, IrDA drivers needs to be initialised *after* the random number * generator (main stack and higher layer init don't need it anymore). * * Jean II */ So I dunno. Maybe we need to just revert the PNP patch, think about it some more? diff -puN drivers/pnp/isapnp/core.c~pnp-initcall-revert drivers/pnp/isapnp/core.c --- 25/drivers/pnp/isapnp/core.c~pnp-initcall-revert 2003-11-01 16:02:36.000000000 -0800 +++ 25-akpm/drivers/pnp/isapnp/core.c 2003-11-01 16:02:54.000000000 -0800 @@ -1160,7 +1160,7 @@ int __init isapnp_init(void) return 0; } -fs_initcall(isapnp_init); +device_initcall(isapnp_init); /* format is: noisapnp */ diff -puN net/core/dev.c~pnp-initcall-revert net/core/dev.c --- 25/net/core/dev.c~pnp-initcall-revert 2003-11-01 16:02:36.000000000 -0800 +++ 25-akpm/net/core/dev.c 2003-11-01 16:02:54.000000000 -0800 @@ -3067,7 +3067,7 @@ out: return rc; } -fs_initcall(net_dev_init); +subsys_initcall(net_dev_init); EXPORT_SYMBOL(__dev_get); EXPORT_SYMBOL(__dev_get_by_flags); _ From acme@conectiva.com.br Sat Nov 1 17:15:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 17:16:25 -0800 (PST) Received: from oops.kerneljanitors.org (1-131.ctame700-6.telepar.net.br [200.193.158.131]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA21FJ25030573 for ; Sat, 1 Nov 2003 17:15:39 -0800 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id 093F81966F; Sun, 2 Nov 2003 00:49:23 +0000 (UTC) Date: Sat, 1 Nov 2003 22:49:23 -0200 From: Arnaldo Carvalho de Melo To: "David S. Miller" Cc: Linux Networking Development Mailing List Subject: [PATCH] LLC: fix client side after sockaddr_llc fixup Message-ID: <20031102004923.GB11632@conectiva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.4i X-archive-position: 1171 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 Hi David, After I did the fixup in struct sockaddr_llc, i.e. not to use 3 addresses, but just one the server side was OK, as I said to you in that RFC, but the client side was working by luck, i.e. it was always getting the destination sap and using it as both local and destination sap, this was because llc_ui_autobind was OK for servers and clients in the past with 3 addresses, but now it can't be shared by PF_LLC->bind() and PF_LLC->{sendmsg, connect}, so I made ->bind() have its own specific autobinding code and llc_ui_autobind is now only used by ->connect() and ->sendmsg(). This makes the client able to make multiple connections to the same sap on another machine. I refrained from changing the comments in llc_ui_bind and llc_ui_autobind to make the hunks in this patch look sane, will submit another patch that updates the comments to the (now) correct behaviour. Tested running sshd server with PF_LLC patch on both machines and connecting back and forth several times, everything working fine now. Best Regards, - Arnaldo ===== net/llc/af_llc.c 1.57 vs edited ===== --- 1.57/net/llc/af_llc.c Thu Oct 30 16:35:41 2003 +++ edited/net/llc/af_llc.c Sat Nov 1 21:36:53 2003 @@ -250,41 +250,19 @@ if (!sk->sk_zapped) goto out; - /* bind to a specific sap, optional. */ - if (!addr->sllc_sap) { - rc = -EUSERS; - addr->sllc_sap = llc_ui_autoport(); - if (!addr->sllc_sap) - goto out; - } - sap = llc_sap_find(addr->sllc_sap); - if (!sap) { - sap = llc_sap_open(addr->sllc_sap, NULL); - rc = -EBUSY; /* some other network layer is using the sap */ - if (!sap) - goto out; - } else { - struct llc_addr laddr, daddr; - struct sock *ask; - - memset(&laddr, 0, sizeof(laddr)); - memset(&daddr, 0, sizeof(daddr)); - /* - * FIXME: check if the the address is multicast, - * only SOCK_DGRAM can do this. - */ - memcpy(laddr.mac, addr->sllc_mac, IFHWADDRLEN); - laddr.lsap = addr->sllc_sap; - rc = -EADDRINUSE; /* mac + sap clash. */ - ask = llc_lookup_established(sap, &daddr, &laddr); - if (ask) { - sock_put(ask); - goto out; - } - } - llc->laddr.lsap = addr->sllc_sap; - if (llc->dev) - memcpy(llc->laddr.mac, llc->dev->dev_addr, IFHWADDRLEN); + rc = -ENODEV; + llc->dev = dev_getfirstbyhwtype(addr->sllc_arphrd); + if (!llc->dev) + goto out; + rc = -EUSERS; + llc->laddr.lsap = llc_ui_autoport(); + if (!llc->laddr.lsap) + goto out; + rc = -EBUSY; /* some other network layer is using the sap */ + sap = llc_sap_open(llc->laddr.lsap, NULL); + if (!sap) + goto out; + memcpy(llc->laddr.mac, llc->dev->dev_addr, IFHWADDRLEN); memcpy(&llc->addr, addr, sizeof(llc->addr)); /* assign new connection to its SAP */ llc_sap_add_socket(sap, sk); @@ -315,6 +293,8 @@ { struct sockaddr_llc *addr = (struct sockaddr_llc *)uaddr; struct sock *sk = sock->sk; + struct llc_opt *llc = llc_sk(sk); + struct llc_sap *sap; int rc = -EINVAL; dprintk("%s: binding %02X\n", __FUNCTION__, addr->sllc_sap); @@ -323,8 +303,43 @@ rc = -EAFNOSUPPORT; if (addr->sllc_family != AF_LLC) goto out; - /* use autobind, to avoid code replication. */ - rc = llc_ui_autobind(sock, addr); + if (!addr->sllc_sap) { + rc = -EUSERS; + addr->sllc_sap = llc_ui_autoport(); + if (!addr->sllc_sap) + goto out; + } + sap = llc_sap_find(addr->sllc_sap); + if (!sap) { + sap = llc_sap_open(addr->sllc_sap, NULL); + rc = -EBUSY; /* some other network layer is using the sap */ + if (!sap) + goto out; + } else { + struct llc_addr laddr, daddr; + struct sock *ask; + + memset(&laddr, 0, sizeof(laddr)); + memset(&daddr, 0, sizeof(daddr)); + /* + * FIXME: check if the the address is multicast, + * only SOCK_DGRAM can do this. + */ + memcpy(laddr.mac, addr->sllc_mac, IFHWADDRLEN); + laddr.lsap = addr->sllc_sap; + rc = -EADDRINUSE; /* mac + sap clash. */ + ask = llc_lookup_established(sap, &daddr, &laddr); + if (ask) { + sock_put(ask); + goto out; + } + } + llc->laddr.lsap = addr->sllc_sap; + memcpy(llc->laddr.mac, addr->sllc_mac, IFHWADDRLEN); + memcpy(&llc->addr, addr, sizeof(llc->addr)); + /* assign new connection to its SAP */ + llc_sap_add_socket(sap, sk); + rc = sk->sk_zapped = 0; out: return rc; } @@ -399,15 +414,7 @@ llc->daddr.lsap = addr->sllc_sap; memcpy(llc->daddr.mac, addr->sllc_mac, IFHWADDRLEN); } - if (!llc->dev) { - rc = -ENODEV; - dev = dev_getfirstbyhwtype(addr->sllc_arphrd); - if (!dev) - goto out; - llc->dev = dev; - memcpy(llc->laddr.mac, llc->dev->dev_addr, IFHWADDRLEN); - } else - dev = llc->dev; + dev = llc->dev; if (sk->sk_type != SOCK_STREAM) goto out; rc = -EALREADY; @@ -610,7 +617,7 @@ int rc = -EOPNOTSUPP; dprintk("%s: accepting on %02X\n", __FUNCTION__, - llc_sk(sk)->addr.sllc_sap); + llc_sk(sk)->laddr.lsap); lock_sock(sk); if (sk->sk_type != SOCK_STREAM) goto out; @@ -622,7 +629,7 @@ if (rc) goto out; dprintk("%s: got a new connection on %02X\n", __FUNCTION__, - llc_sk(sk)->addr.sllc_sap); + llc_sk(sk)->laddr.lsap); skb = skb_dequeue(&sk->sk_receive_queue); rc = -EINVAL; if (!skb->sk) @@ -747,13 +754,7 @@ if (rc) goto release; } - if (!llc->dev) { - rc = -ENODEV; - dev = dev_getfirstbyhwtype(addr->sllc_arphrd); - if (!dev) - goto release; - } else - dev = llc->dev; + dev = llc->dev; hdrlen = dev->hard_header_len + llc_ui_header_len(sk, addr); size = hdrlen + len; if (size > dev->mtu) From davem@pizda.ninka.net Sat Nov 1 19:36:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 19:37:26 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA23ah25031937 for ; Sat, 1 Nov 2003 19:36:46 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA17405; Sat, 1 Nov 2003 19:29:26 -0800 Date: Sat, 1 Nov 2003 19:29:26 -0800 From: "David S. Miller" To: Andrew Morton Cc: liste@jordet.nu, netdev@oss.sgi.com Subject: Re: Oops at "NET: Registering protocol family 23" at boot with 2.6.0t9-bk Message-Id: <20031101192926.3c7d516f.davem@redhat.com> In-Reply-To: <20031101160350.2f1fe0af.akpm@osdl.org> References: <1067705386.666.1.camel@chevrolet.hybel> <20031101133601.7cf12497.akpm@osdl.org> <1067723628.643.0.camel@chevrolet.hybel> <20031101160350.2f1fe0af.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1172 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, 1 Nov 2003 16:03:50 -0800 Andrew Morton wrote: > OK, it goes bang because ptype_all has not been initialised yet. > > This is because net_dev_init() is fs_initcall, and irda_init() is > subsys_initcall - irda_init() runs before net_dev_init(). > > Dave, I'm not sure what's the best thing to do here - I was afraid that the > initcall level shuffling was a bit premature. Turns out my suspicions were correct afterall :-) If it's just ptype_all that it needs, why don't we just initialize that one list head at compile time? From akpm@osdl.org Sat Nov 1 19:49:36 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 19:50:10 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA23na25032405 for ; Sat, 1 Nov 2003 19:49:36 -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 hA23nHC27507; Sat, 1 Nov 2003 19:49:17 -0800 Date: Sat, 1 Nov 2003 19:51:37 -0800 From: Andrew Morton To: "David S. Miller" Cc: liste@jordet.nu, netdev@oss.sgi.com Subject: Re: Oops at "NET: Registering protocol family 23" at boot with 2.6.0t9-bk Message-Id: <20031101195137.0b19784a.akpm@osdl.org> In-Reply-To: <20031101192926.3c7d516f.davem@redhat.com> References: <1067705386.666.1.camel@chevrolet.hybel> <20031101133601.7cf12497.akpm@osdl.org> <1067723628.643.0.camel@chevrolet.hybel> <20031101160350.2f1fe0af.akpm@osdl.org> <20031101192926.3c7d516f.davem@redhat.com> 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: 1173 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 "David S. Miller" wrote: > > If it's just ptype_all that it needs, why don't we just initialize > that one list head at compile time? Pessimism, basically. I'm sure we could locally fix IRDA, but what other bugs has that initcall change introduced? From davem@pizda.ninka.net Sat Nov 1 19:52:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 19:52:44 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA23qA25032684 for ; Sat, 1 Nov 2003 19:52:11 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA17446; Sat, 1 Nov 2003 19:44:53 -0800 Date: Sat, 1 Nov 2003 19:44:53 -0800 From: "David S. Miller" To: Andrew Morton Cc: liste@jordet.nu, netdev@oss.sgi.com Subject: Re: Oops at "NET: Registering protocol family 23" at boot with 2.6.0t9-bk Message-Id: <20031101194453.70cb8405.davem@redhat.com> In-Reply-To: <20031101195137.0b19784a.akpm@osdl.org> References: <1067705386.666.1.camel@chevrolet.hybel> <20031101133601.7cf12497.akpm@osdl.org> <1067723628.643.0.camel@chevrolet.hybel> <20031101160350.2f1fe0af.akpm@osdl.org> <20031101192926.3c7d516f.davem@redhat.com> <20031101195137.0b19784a.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1174 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, 1 Nov 2003 19:51:37 -0800 Andrew Morton wrote: > "David S. Miller" wrote: > > > > If it's just ptype_all that it needs, why don't we just initialize > > that one list head at compile time? > > Pessimism, basically. I'm sure we could locally fix IRDA, but what > other bugs has that initcall change introduced? Okie dokie, I'll likely just revert it in my tree after I look this issue over a little more. From rusty@samba.org Sat Nov 1 22:23:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 22:24:20 -0800 (PST) Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA26Nj25004319 for ; Sat, 1 Nov 2003 22:23:46 -0800 Received: by lists.samba.org (Postfix, from userid 590) id 8755A2C003; Sun, 2 Nov 2003 06:23:45 +0000 (GMT) From: Rusty Russell To: anton@samba.org, kuznet@ms2.inr.ac.ru, davem@redhat.com Cc: netdev@oss.sgi.com Subject: Flow cache uses unsigned long for cpu mask. Date: Sun, 02 Nov 2003 16:34:35 +1100 Message-Id: <20031102062345.8755A2C003@lists.samba.org> X-archive-position: 1175 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: netdev net/core/flow.c uses "unsigned long flow_cache_cpu_map": AFAICT this should be a cpumask_t. Just doing an unrelated audit... Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From davem@pizda.ninka.net Sat Nov 1 22:58:09 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 22:58:42 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA26w925004868 for ; Sat, 1 Nov 2003 22:58:09 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id WAA17668; Sat, 1 Nov 2003 22:50:50 -0800 Date: Sat, 1 Nov 2003 22:50:50 -0800 From: "David S. Miller" To: Rusty Russell Cc: anton@samba.org, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: net/core/flow.c cpu handling? Message-Id: <20031101225050.4de96a8b.davem@redhat.com> In-Reply-To: <20031102062345.A472E2C0CD@lists.samba.org> References: <20031102062345.A472E2C0CD@lists.samba.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1176 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 Very likely, the code is how it is in order to make the 2.4.x backport of this code and the 2.6.x version as similar as humanly possible. From rusty@samba.org Sat Nov 1 23:16:05 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 23:16:38 -0800 (PST) Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA27Ft25005365 for ; Sat, 1 Nov 2003 23:15:55 -0800 Received: by lists.samba.org (Postfix, from userid 590) id A472E2C0CD; Sun, 2 Nov 2003 06:23:45 +0000 (GMT) From: Rusty Russell To: anton@samba.org, kuznet@ms2.inr.ac.ru, davem@redhat.com Cc: netdev@oss.sgi.com Subject: net/core/flow.c cpu handling? Date: Sun, 02 Nov 2003 17:22:55 +1100 Message-Id: <20031102062345.A472E2C0CD@lists.samba.org> X-archive-position: 1177 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: netdev Hi again, Is there something I'm missing, or wouldn't the code in net/core/flow.c be much simpler if: 1) flow_cache_cpu_prepare() were done for each possible cpu, not dynamically as they came up. 2) The cpucontrol lock is held in flow_cache_flush to guarantee that cpus don't go up and down. 3) The normal cpu_online_map were used instead of flow_cache_cpu_map. The patch below is untested, but if you can't see anything wrong with the approach, I'll test it. Cheers, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. Name: Simplify CPU Handling in net/core/flow.c Author: Rusty Russell Status: Booted on 2.6.0-test9-bk6 D: The cpu handling in net/core/flow.c is flawed, because it uses an D: unsigned long instead of a cpumask_t. This replaces that code D: with a much simpler version which allocates for every possible CPU, D: (the same amount of work on most machines) and takes the cpucontrol D: semaphore when flushing. --- linux-2.6.0-test9-bk4/net/core/flow.c 2003-10-09 18:03:03.000000000 +1000 +++ working-2.6.0-test9-bk4-hotcpu-with-kthread/net/core/flow.c 2003-11-02 17:10:55.000000000 +1100 @@ -65,23 +65,18 @@ struct flow_flush_info { atomic_t cpuleft; - unsigned long cpumap; struct completion completion; }; static DEFINE_PER_CPU(struct tasklet_struct, flow_flush_tasklets) = { NULL }; #define flow_flush_tasklet(cpu) (&per_cpu(flow_flush_tasklets, cpu)) -static DECLARE_MUTEX(flow_cache_cpu_sem); -static unsigned long flow_cache_cpu_map; -static unsigned int flow_cache_cpu_count; - static void flow_cache_new_hashrnd(unsigned long arg) { int i; for (i = 0; i < NR_CPUS; i++) - if (test_bit(i, &flow_cache_cpu_map)) + if (cpu_possible(i)) flow_hash_rnd_recalc(i) = 1; flow_hash_rnd_timer.expires = jiffies + FLOW_HASH_RND_PERIOD; @@ -178,7 +173,9 @@ cpu = smp_processor_id(); fle = NULL; - if (!test_bit(cpu, &flow_cache_cpu_map)) + /* Packet really early in init? Making flow_cache_init a + * pre-smp initcall would solve this. --RR */ + if (!flow_table(cpu)) goto nocache; if (flow_hash_rnd_recalc(cpu)) @@ -277,9 +274,6 @@ struct tasklet_struct *tasklet; cpu = smp_processor_id(); - if (!test_bit(cpu, &info->cpumap)) - return; - tasklet = flow_flush_tasklet(cpu); tasklet->data = (unsigned long)info; tasklet_schedule(tasklet); @@ -288,29 +282,23 @@ void flow_cache_flush(void) { struct flow_flush_info info; - static DECLARE_MUTEX(flow_flush_sem); - - down(&flow_cache_cpu_sem); - info.cpumap = flow_cache_cpu_map; - atomic_set(&info.cpuleft, flow_cache_cpu_count); - up(&flow_cache_cpu_sem); + /* Don't want cpus going down or up during this, also protects + * against multiple callers. */ + down(&cpucontrol); + atomic_set(&info.cpuleft, num_online_cpus()); init_completion(&info.completion); - down(&flow_flush_sem); - local_bh_disable(); smp_call_function(flow_cache_flush_per_cpu, &info, 1, 0); - if (test_bit(smp_processor_id(), &info.cpumap)) - flow_cache_flush_tasklet((unsigned long)&info); + flow_cache_flush_tasklet((unsigned long)&info); local_bh_enable(); wait_for_completion(&info.completion); - - up(&flow_flush_sem); + up(&cpucontrol); } -static int __devinit flow_cache_cpu_prepare(int cpu) +static void __devinit flow_cache_cpu_prepare(int cpu) { struct tasklet_struct *tasklet; unsigned long order; @@ -323,9 +311,8 @@ flow_table(cpu) = (struct flow_cache_entry **) __get_free_pages(GFP_KERNEL, order); - if (!flow_table(cpu)) - return NOTIFY_BAD; + panic("NET: failed to allocate flow cache order %lu\n", order); memset(flow_table(cpu), 0, PAGE_SIZE << order); @@ -334,39 +321,8 @@ tasklet = flow_flush_tasklet(cpu); tasklet_init(tasklet, flow_cache_flush_tasklet, 0); - - return NOTIFY_OK; -} - -static int __devinit flow_cache_cpu_online(int cpu) -{ - down(&flow_cache_cpu_sem); - set_bit(cpu, &flow_cache_cpu_map); - flow_cache_cpu_count++; - up(&flow_cache_cpu_sem); - - return NOTIFY_OK; -} - -static int __devinit flow_cache_cpu_notify(struct notifier_block *self, - unsigned long action, void *hcpu) -{ - unsigned long cpu = (unsigned long)cpu; - switch (action) { - case CPU_UP_PREPARE: - return flow_cache_cpu_prepare(cpu); - break; - case CPU_ONLINE: - return flow_cache_cpu_online(cpu); - break; - } - return NOTIFY_OK; } -static struct notifier_block __devinitdata flow_cache_cpu_nb = { - .notifier_call = flow_cache_cpu_notify, -}; - static int __init flow_cache_init(void) { int i; @@ -388,15 +344,9 @@ flow_hash_rnd_timer.expires = jiffies + FLOW_HASH_RND_PERIOD; add_timer(&flow_hash_rnd_timer); - register_cpu_notifier(&flow_cache_cpu_nb); - for (i = 0; i < NR_CPUS; i++) { - if (!cpu_online(i)) - continue; - if (flow_cache_cpu_prepare(i) == NOTIFY_OK && - flow_cache_cpu_online(i) == NOTIFY_OK) - continue; - panic("NET: failed to initialise flow cache hash table\n"); - } + for (i = 0; i < NR_CPUS; i++) + if (cpu_possible(i)) + flow_cache_cpu_prepare(i); return 0; } From davem@pizda.ninka.net Sat Nov 1 23:16:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 23:17:18 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA27Gk25005390 for ; Sat, 1 Nov 2003 23:16:46 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA17715; Sat, 1 Nov 2003 23:09:21 -0800 Date: Sat, 1 Nov 2003 23:09:21 -0800 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPV{4,6}: Fix one more inappropriate use of inet6_sk()->ipv6only Message-Id: <20031101230921.285fc538.davem@redhat.com> In-Reply-To: <20031101.200132.55114465.yoshfuji@linux-ipv6.org> References: <20031101.200132.55114465.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1178 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 Applied, thanks Yoshfuji. From davem@pizda.ninka.net Sat Nov 1 23:17:48 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 23:18:18 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA27Hm25005936 for ; Sat, 1 Nov 2003 23:17:48 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA17742; Sat, 1 Nov 2003 23:10:27 -0800 Date: Sat, 1 Nov 2003 23:10:27 -0800 From: "David S. Miller" To: Arnaldo Carvalho de Melo Cc: netdev@oss.sgi.com Subject: Re: [PATCH] LLC: fix procfs reading when there are saps without sockets Message-Id: <20031101231027.13d06c8c.davem@redhat.com> In-Reply-To: <20031101065504.GK3705@conectiva.com.br> References: <20031101065504.GK3705@conectiva.com.br> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1179 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 Applied, thanks Arnaldo. From davem@pizda.ninka.net Sat Nov 1 23:19:01 2003 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Nov 2003 23:19:33 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA27J125006307 for ; Sat, 1 Nov 2003 23:19:01 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA17774; Sat, 1 Nov 2003 23:11:42 -0800 Date: Sat, 1 Nov 2003 23:11:42 -0800 From: "David S. Miller" To: Arnaldo Carvalho de Melo Cc: netdev@oss.sgi.com Subject: Re: [PATCH] LLC: fix client side after sockaddr_llc fixup Message-Id: <20031101231142.2bec7e27.davem@redhat.com> In-Reply-To: <20031102004923.GB11632@conectiva.com.br> References: <20031102004923.GB11632@conectiva.com.br> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1180 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 Applied, thanks Arnaldo. From laforge@gnumonks.org Sun Nov 2 06:48:59 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Nov 2003 06:49:33 -0800 (PST) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA2Emv25021878 for ; Sun, 2 Nov 2003 06:48:58 -0800 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org) by coruscant.gnumonks.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.22) id 1AGJXD-0003Tj-5x; Sun, 02 Nov 2003 15:48:55 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.22) id 1AGDiF-0001NH-5z; Sun, 02 Nov 2003 09:35:55 +0100 Date: Sun, 2 Nov 2003 09:35:55 +0100 From: Harald Welte To: Joseph Conlin Cc: netdev@oss.sgi.com, jrd@cc.usu.edu Subject: Re: Replace the Nagle Algorithm Message-ID: <20031102083555.GG1536@sunbeam.de.gnumonks.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ndw/alBWmZEhfcZ" Content-Disposition: inline In-Reply-To: X-Operating-system: Linux sunbeam 2.6.0-test5-nftest X-Date: Today is Setting Orange, the 13rd day of The Aftermath in the YOLD 3169 User-Agent: Mutt/1.5.4i X-Spam-Score: -6.7 (------) X-archive-position: 1181 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 --4ndw/alBWmZEhfcZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 20, 2003 at 12:58:19PM -0600, Joseph Conlin wrote: > I see in the archives and the code that I have looked at (2.4.22, > 2.6.0-test8) that the Minshall algorithm is being used to reduce the > effects of Nagle/delayed ACK interaction. I haven't seen any mention of > the following solution, proposed as an IETF draft RFC by Joe Doupnik > (jrd@cc.usu.edu). >=20 > http://netlab1.usu.edu/pub/misc/draft-doupnik-tcpimpl-nagle-mode-00.txt Interesting, but do you know why this has not been aprooved as RFC and never became more than a draft of the TCP implementation working group? --=20 - Harald Welte 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 --4ndw/alBWmZEhfcZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/pMHrXaXGVTD0i/8RAvh+AKCSFS3PebGTt/FCcSXclZP8gs0nxACfcbgh XBIxvcDguLxJdDpMKxyCAvc= =H46q -----END PGP SIGNATURE----- --4ndw/alBWmZEhfcZ-- From laforge@gnumonks.org Sun Nov 2 06:52:58 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Nov 2003 06:53:32 -0800 (PST) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA2Eqv25022248 for ; Sun, 2 Nov 2003 06:52:58 -0800 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org) by coruscant.gnumonks.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.22) id 1AGJXB-0003Sf-2B; Sun, 02 Nov 2003 15:48:53 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.22) id 1AGE8u-0001hB-CB; Sun, 02 Nov 2003 10:03:28 +0100 Date: Sun, 2 Nov 2003 10:03:28 +0100 From: Harald Welte To: Christian Cc: netdev@oss.sgi.com Subject: Re: ppc32 lockups with 2.6 (maybe network related) Message-ID: <20031102090328.GI1536@sunbeam.de.gnumonks.org> References: <3FA10C2E.1000205@g-house.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k9xkV0rc9XGsukaG" Content-Disposition: inline In-Reply-To: <3FA10C2E.1000205@g-house.de> X-Operating-system: Linux sunbeam 2.6.0-test5-nftest X-Date: Today is Setting Orange, the 13rd day of The Aftermath in the YOLD 3169 User-Agent: Mutt/1.5.4i X-Spam-Score: -6.7 (------) X-archive-position: 1182 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 --k9xkV0rc9XGsukaG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 30, 2003 at 02:03:42PM +0100, Christian wrote: >=20 > I am not subscribed to netdev@oss.sgi.com, please CC me. > i posted to LKML too, but followed an advise better posting to this list. Please consider mailing this to the linuxppc-dev list, since you have a ppc specific bug. > Thank you, > Christian. --=20 - Harald Welte 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 --k9xkV0rc9XGsukaG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/pMhgXaXGVTD0i/8RAs4NAJ0Q6fOTLM4QqehYkntKyP/ZOOJPxwCfaptc pdUrQwKH6ePphJ3MLBNjvas= =5L+m -----END PGP SIGNATURE----- --k9xkV0rc9XGsukaG-- From laforge@gnumonks.org Sun Nov 2 06:53:20 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Nov 2003 06:53:53 -0800 (PST) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA2ErI25022255 for ; Sun, 2 Nov 2003 06:53:19 -0800 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org) by coruscant.gnumonks.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.22) id 1AGJXC-0003Sf-SY; Sun, 02 Nov 2003 15:48:55 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.22) id 1AGE4B-0001dh-Bm; Sun, 02 Nov 2003 09:58:35 +0100 Date: Sun, 2 Nov 2003 09:58:35 +0100 From: Harald Welte To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] remove historic entries in Documentation/Changes Message-ID: <20031102085835.GH1536@sunbeam.de.gnumonks.org> References: <20031029.012202.105420248.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aF3LVLvitz/VQU3c" Content-Disposition: inline In-Reply-To: <20031029.012202.105420248.yoshfuji@linux-ipv6.org> X-Operating-system: Linux sunbeam 2.6.0-test5-nftest X-Date: Today is Setting Orange, the 13rd day of The Aftermath in the YOLD 3169 User-Agent: Mutt/1.5.4i X-Spam-Score: -6.2 (------) X-archive-position: 1183 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 --aF3LVLvitz/VQU3c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Yoshifuji! Please consider the following update for netfilter/iptables, instead of removing any reference to it. --- linux-old/Documentation/Changes 2003-09-29 21:20:11.000000000 +0200 +++ linux/Documentation/Changes 2003-11-02 09:56:09.000000000 +0100 @@ -237,13 +237,15 @@ General changes --------------- =20 -The IP firewalling and NAT code has been replaced again. The new -netfilter software (including ipfwadm and ipchains backwards- -compatible modules) is currently distributed separately. - If you have advanced network configuration needs, you should probably consider using the network tools from ip-route2. =20 +Packet Filter / NAT +------------------- +The packet filtering and NAT code uses the same tools like the previous 2.= 4.x +kernel series (iptables). It still includes backwards-compatibility modul= es +for 2.2.x-style ipchains and 2.0.x-style ipfwadm. + PPP --- =20 @@ -400,11 +402,9 @@ --------- o =20 -Netfilter ---------- -o -o -o +Iptables +-------- +o =20 Ip-route2 --------- --=20 - Harald Welte 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 --aF3LVLvitz/VQU3c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/pMc7XaXGVTD0i/8RAmDRAJ49qfDwKFF2UtCIjbkj/TietFzzeACePjPS EJbFH95MuNC4KJzCm4cm9ds= =Emx2 -----END PGP SIGNATURE----- --aF3LVLvitz/VQU3c-- From amir.noam@intel.com Sun Nov 2 06:54:06 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Nov 2003 06:54:40 -0800 (PST) Received: from petasus.isw.intel.com (petasus.isw.intel.com [192.55.37.196]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA2Es425022532 for ; Sun, 2 Nov 2003 06:54:05 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by petasus.isw.intel.com (8.11.6-20030918-01/8.11.6/d: solo.mc,v 1.56 2003/05/22 21:18:22 rfjohns1 Exp $) with ESMTP id hA2Erb313358 for ; Sun, 2 Nov 2003 14:53:37 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA2EvAu03030 for ; Sun, 2 Nov 2003 14:57:10 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110216535409775 ; Sun, 02 Nov 2003 16:53:54 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.254.188]) by sun111.npdj.intel.com (8.12.9/8.12.9/MailSET/Hub) with ESMTP id hA2Eq9BN002967; Sun, 2 Nov 2003 16:52:12 +0200 (IST) Content-Type: text/plain; charset="iso-8859-1" From: Amir Noam To: "Jay Vosburgh" Subject: Re: [Bonding-devel] Re: [PATCH 2/10] [bonding 2.6] fix monitoring functions Date: Sun, 2 Nov 2003 16:53:51 +0200 User-Agent: KMail/1.4.3 Cc: "Jeff Garzik" , , , References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200311021653.51194.amir.noam@intel.com> X-archive-position: 1184 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev On Thursday 30 October 2003 07:12 pm, Jay Vosburgh wrote: > >However, the following patch that restores backward > > compatibility with old ifenslave is still needed for 2.6. I > > see that it's already been applied by David Miller to 2.4. > > I thought we were dropping the ancient > (SIOCDEVPRIVATE) backwards compatibility in 2.6. This patch restores compatibility with old ifenslave versions that still use the SIOCBONDSETHWADDR command, not necessarily the SIOCDEVPRIVATE ioctls, so this patch is definitely needed for now. If we really want to remove backward compatibility in 2.6 we should do it for all bonding commands and replace them with the new interface. The problem is, since 2.6 is in effect in code freeze I'm not sure if we can actually replace the bonding<->ifenslave interface at this time (as much as I'd like to do it). Jeff, David, We haven't heard from either one of you on this issue: We want to drop support for SIOCDEVPRIVATE in 2.6. As a side effect this will force users to upgrade their user land tools anyway, so we might as well use this opportunity to insert the new interface to replace the current one. (Obviously, it would be preferable for such a change to take effect before 2.6.0 is made final) What do you think about making changes to the 2.6 bonding that will force users to upgrade their ifenslave application? (this new ifenslave will be, of course, backward compatible with 2.4 bonding). For now, however, this patch that restores backward compatibility is still needed for 2.6. I've noticed I'd sent out the wrong patch before (on 2003/10/30), so here is the corrected patch. Sorry for the mix up. Amir diff -Naurp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Oct 30 10:38:34 2003 +++ b/drivers/net/bonding/bond_main.c Sun Nov 2 15:14:21 2003 @@ -3047,6 +3047,10 @@ static int bond_ioctl(struct net_device case SIOCBONDRELEASE: ret = bond_release(master_dev, slave_dev); break; + case BOND_SETHWADDR_OLD: + case SIOCBONDSETHWADDR: + ret = bond_sethwaddr(master_dev, slave_dev); + break; case BOND_CHANGE_ACTIVE_OLD: case SIOCBONDCHANGEACTIVE: if (USES_PRIMARY(bond_mode)) { From amir.noam@intel.com Sun Nov 2 06:55:26 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Nov 2003 06:55:41 -0800 (PST) Received: from petasus.isw.intel.com (petasus.isw.intel.com [192.55.37.196]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA2EtP25025670 for ; Sun, 2 Nov 2003 06:55:26 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by petasus.isw.intel.com (8.11.6-20030918-01/8.11.6/d: solo.mc,v 1.56 2003/05/22 21:18:22 rfjohns1 Exp $) with ESMTP id hA2Esv313524 for ; Sun, 2 Nov 2003 14:54:58 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA2EwVu03171 for ; Sun, 2 Nov 2003 14:58:31 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110216551532671 ; Sun, 02 Nov 2003 16:55:15 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.254.188]) by sun111.npdj.intel.com (8.12.9/8.12.9/MailSET/Hub) with ESMTP id hA2ErXBN002982; Sun, 2 Nov 2003 16:53:33 +0200 (IST) Content-Type: text/plain; charset="iso-8859-1" From: Amir Noam To: "Jay Vosburgh" , "David S. Miller" Subject: Re: [Bonding-devel] [PATCH] [bonding 2.4] fix creating/destroying the /proc/net/bonding dir Date: Sun, 2 Nov 2003 16:55:15 +0200 User-Agent: KMail/1.4.3 Cc: , , References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200311021655.15498.amir.noam@intel.com> X-archive-position: 1185 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev On Friday 31 October 2003 10:10 pm, Jay Vosburgh wrote: > Jeff, can you apply Amir's patch, as it seems to work > just fine except for this ignorable problem? I'll append the > patch below for your convenience. That patch also applies to 2.6 (after the "restore backward compatibility" patch) with an offset of one line per chunk. I've appended it here again, against 2.6, just in case you want it to apply cleanly with no warnings. Amir diff -Naurp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Sun Nov 2 15:06:08 2003 +++ b/drivers/net/bonding/bond_main.c Sun Nov 2 15:06:18 2003 @@ -3573,6 +3573,62 @@ static void bond_destroy_proc_info(struc bond->bond_proc_file = NULL; } } + +/* Create the bonding directory under /proc/net, if doesn't exist yet. + * Caller must hold rtnl_lock. + */ +static void bond_create_proc_dir(void) +{ + int len = strlen(DRV_NAME); + + for (bond_proc_dir = proc_net->subdir; bond_proc_dir; + bond_proc_dir = bond_proc_dir->next) { + if ((bond_proc_dir->namelen == len) && + !memcmp(bond_proc_dir->name, DRV_NAME, len)) { + break; + } + } + + if (!bond_proc_dir) { + bond_proc_dir = proc_mkdir(DRV_NAME, proc_net); + if (bond_proc_dir) { + bond_proc_dir->owner = THIS_MODULE; + } else { + printk(KERN_WARNING DRV_NAME + ": Warning: cannot create /proc/net/%s\n", + DRV_NAME); + } + } +} + +/* Destroy the bonding directory under /proc/net, if empty. + * Caller must hold rtnl_lock. + */ +static void bond_destroy_proc_dir(void) +{ + struct proc_dir_entry *de; + + if (!bond_proc_dir) { + return; + } + + /* verify that the /proc dir is empty */ + for (de = bond_proc_dir->subdir; de; de = de->next) { + /* ignore . and .. */ + if (*(de->name) != '.') { + break; + } + } + + if (de) { + if (bond_proc_dir->owner == THIS_MODULE) { + bond_proc_dir->owner = NULL; + } + } else { + remove_proc_entry(DRV_NAME, proc_net); + bond_proc_dir = NULL; + } +} #endif /* CONFIG_PROC_FS */ /* @@ -3828,6 +3884,9 @@ static struct notifier_block bond_netdev .notifier_call = bond_netdev_event, }; +/* De-initialize device specific data. + * Caller must hold rtnl_lock. + */ static inline void bond_deinit(struct net_device *dev) { struct bonding *bond = dev->priv; @@ -3839,6 +3898,9 @@ static inline void bond_deinit(struct ne #endif } +/* Unregister and free all bond devices. + * Caller must hold rtnl_lock. + */ static void bond_free_all(void) { struct bonding *bond, *nxt; @@ -3846,16 +3908,13 @@ static void bond_free_all(void) list_for_each_entry_safe(bond, nxt, &bond_dev_list, bond_list) { struct net_device *dev = bond->device; - unregister_netdev(dev); + unregister_netdevice(dev); bond_deinit(dev); free_netdev(dev); } #ifdef CONFIG_PROC_FS - if (bond_proc_dir) { - remove_proc_entry(DRV_NAME, proc_net); - bond_proc_dir = NULL; - } + bond_destroy_proc_dir(); #endif } @@ -4233,18 +4292,12 @@ static int __init bonding_init(void) primary = NULL; } + rtnl_lock(); + #ifdef CONFIG_PROC_FS - bond_proc_dir = proc_mkdir(DRV_NAME, proc_net); - if (bond_proc_dir == NULL) { - printk(KERN_WARNING - "bonding_init(): can not create /proc/net/" DRV_NAME); - } else { - bond_proc_dir->owner = THIS_MODULE; - } + bond_create_proc_dir(); #endif - rtnl_lock(); - err = 0; for (no = 0; no < max_bonds; no++) { struct net_device *dev; @@ -4287,18 +4340,21 @@ static int __init bonding_init(void) return 0; out_err: - rtnl_unlock(); - /* free and unregister all bonds that were successfully added */ bond_free_all(); + rtnl_unlock(); + return err; } static void __exit bonding_exit(void) { unregister_netdevice_notifier(&bond_netdev_notifier); + + rtnl_lock(); bond_free_all(); + rtnl_unlock(); } module_init(bonding_init); From pekkas@netcore.fi Sun Nov 2 23:26:52 2003 Received: with ECARTIS (v1.0.0; list netdev); Sun, 02 Nov 2003 23:27:25 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA37Qo25015900 for ; Sun, 2 Nov 2003 23:26:51 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA37QbT27984; Mon, 3 Nov 2003 09:26:37 +0200 Date: Mon, 3 Nov 2003 09:26:36 +0200 (EET) From: Pekka Savola To: David Woodhouse cc: netdev@oss.sgi.com Subject: Re: IPv6 on-link assumption considered harmful In-Reply-To: <1067615762.3423.264.camel@hades.cambridge.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1186 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 Fri, 31 Oct 2003, David Woodhouse wrote: > On Thu, 2003-10-30 at 21:09 +0200, Pekka Savola wrote: > > Just to give a heads-up before this is finalized, to give people ability > > to prepare or comment prior to this process is formalized in the IETF. > > With corresponding changes to the route advertisement protocol as used > by radvd, so that routes can actually be advertised to autoconfigured > nodes? Or does that already exist and I just missed it when I was > looking? Do you mean: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt This has nothing to do with this subject (AFAICS), but one person just a couple of days ago asked about this and wanted to know whether anyone else is hacking this, and if not, whether he should go ahead. We gave (as radvd maintainers) a thumbs-up. If you're also interested in hacking this, contact me off-list, and I'll ask the other person whether he'd like to get some help.. (Obviously, the preferences will need support in the kernel too.) -- 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 rusty@samba.org Mon Nov 3 02:28:31 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 02:29:04 -0800 (PST) Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3ASU25023258 for ; Mon, 3 Nov 2003 02:28:31 -0800 Received: by lists.samba.org (Postfix, from userid 590) id E1C622C05E; Mon, 3 Nov 2003 10:28:29 +0000 (GMT) From: Rusty Russell To: "David S. Miller" Cc: anton@samba.org, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: net/core/flow.c cpu handling? In-reply-to: Your message of "Sat, 01 Nov 2003 22:50:50 -0800." <20031101225050.4de96a8b.davem@redhat.com> Date: Mon, 03 Nov 2003 21:26:40 +1100 Message-Id: <20031103102829.E1C622C05E@lists.samba.org> X-archive-position: 1187 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: netdev In message <20031101225050.4de96a8b.davem@redhat.com> you write: > > Very likely, the code is how it is in order to make the > 2.4.x backport of this code and the 2.6.x version as > similar as humanly possible. Hmm, AFAICT the patch I sent should be easier, not harder to backport. Anyway, I'm carrying the patch as part of the hotplug CPU patches: we can discuss it once 2.6.0 is out. Thanks, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From wensong@linux-vs.org Mon Nov 3 06:17:33 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 06:18:09 -0800 (PST) Received: from lb1.ctrip.com ([218.244.111.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3EHS25001438 for ; Mon, 3 Nov 2003 06:17:32 -0800 Received: from penguin.linux-vs.org ([211.136.74.13]) by lb1.ctrip.com (8.12.9/8.12.9) with ESMTP id hA3EH0MP024985 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 3 Nov 2003 22:17:11 +0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by penguin.linux-vs.org (8.12.8/8.12.8) with ESMTP id hA3EFl4L005800; Mon, 3 Nov 2003 22:15:48 +0800 Date: Mon, 3 Nov 2003 22:15:47 +0800 (CST) From: Wensong Zhang To: netdev@oss.sgi.com cc: "David S. Miller" , Julian Anastasov Subject: [2.4/2.6 PATCH] Cosmetic IP_VS_INFO fix Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811584-2066790978-1067868947=:5797" X-archive-position: 1188 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: wensong@linux-vs.org Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463811584-2066790978-1067868947=:5797 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Here is minor cosmetic fix to add the trailing '\n'. Please check and apply them. Thanks, Wensong ---1463811584-2066790978-1067868947=:5797 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="linux-2.4-ipvs-tidyup.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-2.4-ipvs-tidyup.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTE3OCAgLT4gMS4xMTc5IA0KIwlu ZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5jCTEuMiAgICAgLT4gMS4zICAgIA0K Iw0KIyBUaGUgZm9sbG93aW5nIGlzIHRoZSBCaXRLZWVwZXIgQ2hhbmdlU2V0 IExvZw0KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KIyAwMy8xMS8wMwl3ZW5zb25nQGxpbnV4LXZzLm9yZwkxLjEx NzkNCiMgW0lQVlNdIENvc21ldGljIElQX1ZTX0lORk8gZml4IHRvIGFkZCB0 aGUgdHJhaWxpbmcgJ1xuJw0KIyANCiMgUGF0Y2ggZnJvbSBIb3JtcyA8aG9y bXNAdmVyZ2VuZXQubmV0Pg0KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KIw0KZGlmZiAtTnJ1IGEvbmV0L2lwdjQv aXB2cy9pcF92c19jdGwuYyBiL25ldC9pcHY0L2lwdnMvaXBfdnNfY3RsLmMN Ci0tLSBhL25ldC9pcHY0L2lwdnMvaXBfdnNfY3RsLmMJTW9uIE5vdiAgMyAy MTo1Nzo0NCAyMDAzDQorKysgYi9uZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5j CU1vbiBOb3YgIDMgMjE6NTc6NDQgMjAwMw0KQEAgLTE3NDAsOSArMTc0MCw5 IEBADQogCSAqIENoZWNrIGZvciB2YWxpZCBwcm90b2NvbDogVENQIG9yIFVE UC4gRXZlbiBmb3IgZndtYXJrIT0wDQogCSAqLw0KIAlpZiAodXJ1bGUtPnBy b3RvY29sIT1JUFBST1RPX1RDUCAmJiB1cnVsZS0+cHJvdG9jb2whPUlQUFJP VE9fVURQKSB7DQotCQlJUF9WU19JTkZPKCJ2c19jdGw6IGludmFsaWQgcHJv dG9jb2w6ICVkICVkLiVkLiVkLiVkOiVkICVzIiwNCi0JCQkgICBudG9ocyh1 cnVsZS0+cHJvdG9jb2wpLCBOSVBRVUFEKHVydWxlLT52YWRkciksDQotCQkJ ICAgbnRvaHModXJ1bGUtPnZwb3J0KSwgdXJ1bGUtPnNjaGVkX25hbWUpOw0K KwkJSVBfVlNfRVJSKCJzZXRfY3RsOiBpbnZhbGlkIHByb3RvY29sICVkICVk LiVkLiVkLiVkOiVkICVzXG4iLA0KKwkJCSAgbnRvaHModXJ1bGUtPnByb3Rv Y29sKSwgTklQUVVBRCh1cnVsZS0+dmFkZHIpLA0KKwkJCSAgbnRvaHModXJ1 bGUtPnZwb3J0KSwgdXJ1bGUtPnNjaGVkX25hbWUpOw0KIAkJcmV0ID0gLUVG QVVMVDsNCiAJCWdvdG8gb3V0X3VubG9jazsNCiAJfQ0K ---1463811584-2066790978-1067868947=:5797 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="linux-2.5-ipvs-tidyup.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-2.5-ipvs-tidyup.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTQwMyAgLT4gMS4xNDA0IA0KIwlu ZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5jCTEuMTEgICAgLT4gMS4xMiAgIA0K Iw0KIyBUaGUgZm9sbG93aW5nIGlzIHRoZSBCaXRLZWVwZXIgQ2hhbmdlU2V0 IExvZw0KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KIyAwMy8xMS8wMwl3ZW5zb25nQGxpbnV4LXZzLm9yZwkxLjE0 MDQNCiMgW0lQVlNdIENvc21ldGljIElQX1ZTX0lORk8gZml4IHRvIGFkZCB0 aGUgdHJhaWxpbmcgJ1xuJw0KIyANCiMgUGF0Y2ggZnJvbSBIb3JtcyA8aG9y bXNAdmVyZ2VuZXQubmV0Pg0KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KIw0KZGlmZiAtTnJ1IGEvbmV0L2lwdjQv aXB2cy9pcF92c19jdGwuYyBiL25ldC9pcHY0L2lwdnMvaXBfdnNfY3RsLmMN Ci0tLSBhL25ldC9pcHY0L2lwdnMvaXBfdnNfY3RsLmMJTW9uIE5vdiAgMyAy MjoxMDozMiAyMDAzDQorKysgYi9uZXQvaXB2NC9pcHZzL2lwX3ZzX2N0bC5j CU1vbiBOb3YgIDMgMjI6MTA6MzIgMjAwMw0KQEAgLTE4MzksOSArMTgzOSw5 IEBADQogDQogCS8qIENoZWNrIGZvciB2YWxpZCBwcm90b2NvbDogVENQIG9y IFVEUCwgZXZlbiBmb3IgZndtYXJrIT0wICovDQogCWlmICh1c3ZjLT5wcm90 b2NvbCE9SVBQUk9UT19UQ1AgJiYgdXN2Yy0+cHJvdG9jb2whPUlQUFJPVE9f VURQKSB7DQotCQlJUF9WU19JTkZPKCJ2c19jdGw6IGludmFsaWQgcHJvdG9j b2w6ICVkICVkLiVkLiVkLiVkOiVkICVzIiwNCi0JCQkgICBudG9ocyh1c3Zj LT5wcm90b2NvbCksIE5JUFFVQUQodXN2Yy0+YWRkciksDQotCQkJICAgbnRv aHModXN2Yy0+cG9ydCksIHVzdmMtPnNjaGVkX25hbWUpOw0KKwkJSVBfVlNf RVJSKCJzZXRfY3RsOiBpbnZhbGlkIHByb3RvY29sICVkICVkLiVkLiVkLiVk OiVkICVzXG4iLA0KKwkJCSAgbnRvaHModXN2Yy0+cHJvdG9jb2wpLCBOSVBR VUFEKHVzdmMtPmFkZHIpLA0KKwkJCSAgbnRvaHModXN2Yy0+cG9ydCksIHVz dmMtPnNjaGVkX25hbWUpOw0KIAkJcmV0ID0gLUVGQVVMVDsNCiAJCWdvdG8g b3V0X3VubG9jazsNCiAJfQ0K ---1463811584-2066790978-1067868947=:5797-- From hch@infradead.org Mon Nov 3 07:12:15 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 07:12:52 -0800 (PST) Received: from phoenix.infradead.org (pub234.cambridge.redhat.com [213.86.99.234] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3FC725003995 for ; Mon, 3 Nov 2003 07:12:12 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.22) id 1AGgMr-0007cx-Ck; Mon, 03 Nov 2003 15:11:45 +0000 Date: Mon, 3 Nov 2003 15:11:45 +0000 From: Christoph Hellwig To: "David S. Miller" Cc: Rusty Russell , anton@samba.org, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: net/core/flow.c cpu handling? Message-ID: <20031103151145.A29287@infradead.org> References: <20031102062345.A472E2C0CD@lists.samba.org> <20031101225050.4de96a8b.davem@redhat.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: <20031101225050.4de96a8b.davem@redhat.com>; from davem@redhat.com on Sat, Nov 01, 2003 at 10:50:50PM -0800 X-archive-position: 1189 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev On Sat, Nov 01, 2003 at 10:50:50PM -0800, David S. Miller wrote: > > Very likely, the code is how it is in order to make the > 2.4.x backport of this code and the 2.6.x version as > similar as humanly possible. Well, the current code is wrong for 2.6 and breaks badly for machines with more than 32/64 cpus. -- Christoph Hellwig - Freelance Hacker Contact me for driver hacking and kernel development consulting From yoshfuji@linux-ipv6.org Mon Nov 3 10:24:21 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 10:24:55 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3IOK25008919 for ; Mon, 3 Nov 2003 10:24:21 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian-6.6) with ESMTP id hA3IO2lg028840; Tue, 4 Nov 2003 03:24:02 +0900 Date: Tue, 04 Nov 2003 03:24:02 +0900 (JST) Message-Id: <20031104.032402.67222659.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: dwmw2@infradead.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: IPv6 on-link assumption considered harmful From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <1067615762.3423.264.camel@hades.cambridge.redhat.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA 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/MEaZBLP 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: 1190 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. In article (at Mon, 3 Nov 2003 09:26:36 +0200 (EET)), Pekka Savola says: > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt > > This has nothing to do with this subject (AFAICS), but one person just a > couple of days ago asked about this and wanted to know whether anyone else > is hacking this, and if not, whether he should go ahead. We gave (as > radvd maintainers) a thumbs-up. Host code is already available in USAGI tree since January, 2003. I'll contribute this to mainline (after 2.6.0). Thanks. --yoshfuji From pp@ee.oulu.fi Mon Nov 3 12:53:44 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 12:54:20 -0800 (PST) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3Krg25015981 for ; Mon, 3 Nov 2003 12:53:43 -0800 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.10/8.12.10) with ESMTP id hA3KrawE026468; Mon, 3 Nov 2003 22:53:36 +0200 (EET) Received: (from pp@localhost) by tk28.oulu.fi (8.12.10/8.12.10/Submit) id hA3KrZfS012571; Mon, 3 Nov 2003 22:53:35 +0200 (EET) Date: Mon, 3 Nov 2003 22:53:35 +0200 From: Pekka Pietikainen To: Charles Bueche Cc: netdev@oss.sgi.com Subject: Re: changing MTU on b44 breaks eth0 Message-ID: <20031103205335.GA7668@ee.oulu.fi> References: <1067888106.3366.20.camel@bluez.bueche.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <1067888106.3366.20.camel@bluez.bueche.ch> User-Agent: Mutt/1.4.1i X-archive-position: 1191 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pp@ee.oulu.fi Precedence: bulk X-list: netdev On Mon, Nov 03, 2003 at 08:35:38PM +0100, Charles Bueche wrote: > Hi, > > I tried to reduce the MTU to 1464 because I'm behind an ADSL router. > Rigth when I do the "ifconfig eth0 192.168.0.4 mtu 1464", it hangs the > port. > The problem can be reproduced. I have attached a few log extracts. I > would be ready to test patches or new versions if needed. Heh Thanks for the report. Looking at the code and previous bugs in it, I can safely say I found the problem and a few similar ones that could be triggered when using ethtool :-) Anyway, here's a (untested) patch that should fix the problem. As a bonus I even snuck in a new feature, power management support! --- /usr/src/linux-2.6.0-0.test9.1.67/drivers/net/b44.c 2003-10-25 21:43:30.000000000 +0300 +++ linux-2.6.0-test9/drivers/net/b44.c 2003-11-03 22:25:15.943854312 +0200 @@ -25,8 +25,8 @@ #define DRV_MODULE_NAME "b44" #define PFX DRV_MODULE_NAME ": " -#define DRV_MODULE_VERSION "0.91" -#define DRV_MODULE_RELDATE "Oct 3, 2003" +#define DRV_MODULE_VERSION "0.92" +#define DRV_MODULE_RELDATE "Nov 3, 2003" #define B44_DEF_MSG_ENABLE \ (NETIF_MSG_DRV | \ @@ -942,6 +942,8 @@ b44_init_hw(bp); spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } @@ -1558,6 +1560,8 @@ netif_wake_queue(bp->dev); spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } case ETHTOOL_GPAUSEPARAM: { @@ -1601,6 +1605,8 @@ } spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } }; @@ -1852,11 +1858,57 @@ } } +#ifdef CONFIG_PM +static int b44_suspend(struct pci_dev *pdev, u32 state) +{ + struct net_device *dev = pci_get_drvdata(pdev); + struct b44 *bp = dev->priv; + + if (!netif_running(dev)) + return 0; + + del_timer_sync(&bp->timer); + + spin_lock_irq(&bp->lock); + + b44_halt(bp); + netif_carrier_off(bp->dev); + netif_device_detach(bp->dev); + b44_free_rings(bp); + + spin_unlock_irq(&bp->lock); + return 0; +} + +static int b44_resume(struct pci_dev *pdev) +{ + struct net_device *dev = pci_get_drvdata(pdev); + struct b44 *bp = dev->priv; + + if (!netif_running(dev)) + return 0; + + spin_lock_irq(&bp->lock); + + b44_init_rings(bp); + b44_init_hw(bp); + netif_device_attach(bp->dev); + spin_unlock_irq(&bp->lock); + + b44_enable_ints(bp); + return 0; +} +#endif /* CONFIG_PM */ + static struct pci_driver b44_driver = { .name = DRV_MODULE_NAME, .id_table = b44_pci_tbl, .probe = b44_init_one, .remove = __devexit_p(b44_remove_one), +#ifdef CONFIG_PM + .suspend = b44_suspend, + .resume = b44_resume, +#endif /* CONFIG_PM */ }; static int __init b44_init(void) From davem@pizda.ninka.net Mon Nov 3 14:50:38 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 14:51:13 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3MoI25019437 for ; Mon, 3 Nov 2003 14:50:38 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id OAA16260; Mon, 3 Nov 2003 14:45:21 -0800 Date: Mon, 3 Nov 2003 14:45:21 -0800 From: "David S. Miller" To: Rusty Russell Cc: anton@samba.org, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: net/core/flow.c cpu handling? Message-Id: <20031103144521.0aec9ea3.davem@redhat.com> In-Reply-To: <20031103102829.E1C622C05E@lists.samba.org> References: <20031101225050.4de96a8b.davem@redhat.com> <20031103102829.E1C622C05E@lists.samba.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1192 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 Mon, 03 Nov 2003 21:26:40 +1100 Rusty Russell wrote: > In message <20031101225050.4de96a8b.davem@redhat.com> you write: > > > > Very likely, the code is how it is in order to make the > > 2.4.x backport of this code and the 2.6.x version as > > similar as humanly possible. > > Hmm, AFAICT the patch I sent should be easier, not harder to backport. > > Anyway, I'm carrying the patch as part of the hotplug CPU patches: we > can discuss it once 2.6.0 is out. I intend to review your patch today, there is no justification for the problems you've pointed out in this code regardless of how difficult or easy fixing it makes a backport. From davem@pizda.ninka.net Mon Nov 3 14:52:11 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 14:52:43 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3MqB25019630 for ; Mon, 3 Nov 2003 14:52:11 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id OAA16267; Mon, 3 Nov 2003 14:47:07 -0800 Date: Mon, 3 Nov 2003 14:47:07 -0800 From: "David S. Miller" To: Wensong Zhang Cc: netdev@oss.sgi.com, ja@ssi.bg Subject: Re: [2.4/2.6 PATCH] Cosmetic IP_VS_INFO fix Message-Id: <20031103144707.30fa18df.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1193 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 Cosmetic fixes can wait for 2.6.1 and 2.4.24 From davem@pizda.ninka.net Mon Nov 3 15:00:46 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 15:01:19 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3N0j25020236 for ; Mon, 3 Nov 2003 15:00:45 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id OAA16281; Mon, 3 Nov 2003 14:55:39 -0800 Date: Mon, 3 Nov 2003 14:55:39 -0800 From: "David S. Miller" To: Christoph Hellwig Cc: rusty@rustcorp.com.au, anton@samba.org, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: net/core/flow.c cpu handling? Message-Id: <20031103145539.17f3ba01.davem@redhat.com> In-Reply-To: <20031103151145.A29287@infradead.org> References: <20031102062345.A472E2C0CD@lists.samba.org> <20031101225050.4de96a8b.davem@redhat.com> <20031103151145.A29287@infradead.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1194 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 Mon, 3 Nov 2003 15:11:45 +0000 Christoph Hellwig wrote: > On Sat, Nov 01, 2003 at 10:50:50PM -0800, David S. Miller wrote: > > > > Very likely, the code is how it is in order to make the > > 2.4.x backport of this code and the 2.6.x version as > > similar as humanly possible. > > Well, the current code is wrong for 2.6 and breaks badly for machines > with more than 32/64 cpus. I totally understand, I am in no way trying to justify what the code is doing. From davem@pizda.ninka.net Mon Nov 3 15:21:16 2003 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Nov 2003 15:21:50 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA3NLG25020760 for ; Mon, 3 Nov 2003 15:21:16 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id PAA16422; Mon, 3 Nov 2003 15:16:18 -0800 Date: Mon, 3 Nov 2003 15:16:18 -0800 From: "David S. Miller" To: Pekka Pietikainen Cc: charles@bueche.ch, netdev@oss.sgi.com Subject: Re: changing MTU on b44 breaks eth0 Message-Id: <20031103151618.79704b30.davem@redhat.com> In-Reply-To: <20031103205335.GA7668@ee.oulu.fi> References: <1067888106.3366.20.camel@bluez.bueche.ch> <20031103205335.GA7668@ee.oulu.fi> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1195 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 Mon, 3 Nov 2003 22:53:35 +0200 Pekka Pietikainen wrote: > Anyway, here's a (untested) patch that should fix the problem. As a bonus I > even snuck in a new feature, power management support! I think Jeff should merge this upstrea, but I really disagree with the CONFIG_PM ifdefs for the power-management support. From pp@ee.oulu.fi Tue Nov 4 03:16:00 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 03:16:38 -0800 (PST) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4BFx25022355 for ; Tue, 4 Nov 2003 03:16:00 -0800 Received: from tk28.oulu.fi (tk28 [130.231.48.68]) by ee.oulu.fi (8.12.10/8.12.10) with ESMTP id hA4BFuwE023940; Tue, 4 Nov 2003 13:15:56 +0200 (EET) Received: (from pp@localhost) by tk28.oulu.fi (8.12.10/8.12.10/Submit) id hA4BFthM027680; Tue, 4 Nov 2003 13:15:55 +0200 (EET) Date: Tue, 4 Nov 2003 13:15:55 +0200 From: Pekka Pietikainen To: "David S. Miller" Cc: charles@bueche.ch, netdev@oss.sgi.com Subject: Re: changing MTU on b44 breaks eth0 Message-ID: <20031104111555.GA26860@ee.oulu.fi> References: <1067888106.3366.20.camel@bluez.bueche.ch> <20031103205335.GA7668@ee.oulu.fi> <20031103151618.79704b30.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20031103151618.79704b30.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 1196 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pp@ee.oulu.fi Precedence: bulk X-list: netdev On Mon, Nov 03, 2003 at 03:16:18PM -0800, David S. Miller wrote: > I think Jeff should merge this upstrea, but I really disagree > with the CONFIG_PM ifdefs for the power-management support. Fine with me (patch with CONFIG_PM removed included) Oh btw., when trying out whether the new code even compiles/loads I got the following in rmmod, does it look like something caused by generic code or should I look for a reason in b44? :-) (This is 2.6.0-test9-bk6). kernel BUG at net/core/dev.c:2882! invalid operand: 0000 [#1] CPU: 0 EIP: 0060:[] Tainted: P EFLAGS: 00010297 EIP is at free_netdev+0x2d/0x40 eax: ddfd6800 ebx: ddfd6800 ecx: 1f2e9da0 edx: 00000003 esi: dff5d000 edi: dff5d054 ebp: de743ec4 esp: de743ec4 ds: 007b es: 007b ss: 0068 Process rmmod (pid: 18966, threadinfo=de742000 task=c797b320) Stack: de743edc e090011d ddfd6800 dff5d000 e0902544 00000000 de743eec c01c8c09 dff5d000 dff5d054 de743f04 c0210dd0 dff5d054 dff5d080 e0902590 e0902590 de743f18 c0210e02 dff5d054 e0902544 c02fb458 de743f2c c0211039 e0902544 Call Trace: [] b44_remove_one+0x3d/0x60 [b44] [] pci_device_remove+0x39/0x40 [] device_release_driver+0x60/0x70 [] driver_detach+0x22/0x40 [] bus_remove_driver+0x39/0x70 [] driver_unregister+0x14/0x26 [] pci_unregister_driver+0x17/0x30 [] b44_cleanup+0x12/0x14 [b44] [] sys_delete_module+0x113/0x190 [] do_munmap+0x14f/0x1b0 [] sys_munmap+0x43/0x60 [] sysenter_past_esp+0x52/0x71 Code: 0f 0b 42 0b ab 48 2e c0 eb de c9 e9 93 6e ef ff 8d 76 00 55 Trying to reproduce on a fresh non-nvidia-tainted -bk8 rmmod initially worked, then I did /sbin/modprobe b44; /sbin/ifup eth0; /sbin/rmmod b44 managed to trigger another race: eth0: no IPv6 routers present Unable to handle kernel paging request at virtual address 706647ef printing eip: c0254415 *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010216 EIP is at rtnetlink_fill_ifinfo+0x2a5/0x480 eax: 706647e3 ebx: df037800 ecx: 00000ee4 edx: c68fa09c esi: 00000000 edi: df037805 ebp: dff8deb4 esp: dff8de88 ds: 007b es: 007b ss: 0068 Process events/0 (pid: 3, threadinfo=dff8c000 task=c151cc80) Stack: c689fd80 00000004 00000004 dff8dea4 00000ee4 00000f60 c68fa000 000005dc c689fd80 ffffffff 00000011 dff8dee4 c02548ac c689fd80 df037800 00000011 00000000 00000000 ffffffff df037800 c0335c00 df037800 00000006 dff8def8 Call Trace: [] rtmsg_ifinfo+0x5c/0xd0 [] rtnetlink_event+0x35/0x62 [] notifier_call_chain+0x2d/0x50 [] netdev_wait_allrefs+0xc0/0x110 [] netdev_run_todo+0x10c/0x1f0 [] __down_failed+0xb/0x14 [] worker_thread+0x1bb/0x2a0 [] linkwatch_event+0x0/0x30 [] default_wake_function+0x0/0x30 [] ret_from_fork+0x6/0x14 [] default_wake_function+0x0/0x30 [] worker_thread+0x0/0x2a0 [] kernel_thread_helper+0x5/0xc Code: 8b 50 0c b9 ff ff ff ff 31 c0 83 c2 08 89 d7 f2 ae f7 d1 49 --- /usr/src/linux-2.6.0-0.test9.1.67/drivers/net/b44.c 2003-10-25 21:43:30.000000000 +0300 +++ linux-2.6.0-test9/drivers/net/b44.c 2003-11-04 12:32:13.403426192 +0200 @@ -25,8 +25,8 @@ #define DRV_MODULE_NAME "b44" #define PFX DRV_MODULE_NAME ": " -#define DRV_MODULE_VERSION "0.91" -#define DRV_MODULE_RELDATE "Oct 3, 2003" +#define DRV_MODULE_VERSION "0.92" +#define DRV_MODULE_RELDATE "Nov 4, 2003" #define B44_DEF_MSG_ENABLE \ (NETIF_MSG_DRV | \ @@ -942,6 +942,8 @@ b44_init_hw(bp); spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } @@ -1558,6 +1560,8 @@ netif_wake_queue(bp->dev); spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } case ETHTOOL_GPAUSEPARAM: { @@ -1601,6 +1605,8 @@ } spin_unlock_irq(&bp->lock); + b44_enable_ints(bp); + return 0; } }; @@ -1852,11 +1858,53 @@ } } +static int b44_suspend(struct pci_dev *pdev, u32 state) +{ + struct net_device *dev = pci_get_drvdata(pdev); + struct b44 *bp = dev->priv; + + if (!netif_running(dev)) + return 0; + + del_timer_sync(&bp->timer); + + spin_lock_irq(&bp->lock); + + b44_halt(bp); + netif_carrier_off(bp->dev); + netif_device_detach(bp->dev); + b44_free_rings(bp); + + spin_unlock_irq(&bp->lock); + return 0; +} + +static int b44_resume(struct pci_dev *pdev) +{ + struct net_device *dev = pci_get_drvdata(pdev); + struct b44 *bp = dev->priv; + + if (!netif_running(dev)) + return 0; + + spin_lock_irq(&bp->lock); + + b44_init_rings(bp); + b44_init_hw(bp); + netif_device_attach(bp->dev); + spin_unlock_irq(&bp->lock); + + b44_enable_ints(bp); + return 0; +} + static struct pci_driver b44_driver = { .name = DRV_MODULE_NAME, .id_table = b44_pci_tbl, .probe = b44_init_one, .remove = __devexit_p(b44_remove_one), + .suspend = b44_suspend, + .resume = b44_resume, }; static int __init b44_init(void) -- Pekka Pietikainen From kuznet@ms2.inr.ac.ru Tue Nov 4 04:34:12 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 04:34:45 -0800 (PST) Received: from yakov.inr.ac.ru (yakov.inr.ac.ru [193.233.7.111]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4CYA25030301 for ; Tue, 4 Nov 2003 04:34:11 -0800 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id PAA15518; Tue, 4 Nov 2003 15:33:03 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200311041233.PAA15518@yakov.inr.ac.ru> Subject: Re: Fw: issues with SO_PRIORITY and IP_TOS To: davem@redhat.com (David S. Miller) Date: Tue, 4 Nov 2003 15:33:03 +0300 (MSK) Cc: jmorris@redhat.com, cfriesen@nortelnetworks.com, hadi@znyx.com, netdev@oss.sgi.com In-Reply-To: <20031030120140.678b721b.davem@redhat.com> from "David S. Miller" at ïËÔ 30, 2003 12:01:40 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1197 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! [cced to Jamal] > I've always been confused about all of the weird things > we do to handle DSCP et al. when masking the TOS bits all > over the place. TOS bits are masked only in one place: when doing routing by TOS, implemented by some existing routing engines sort of OSPF. No bits but TOS bits are used for these things. > Alexey, what is going on here? #1. Setting priority derived from TOS is different thing, it is just to make life more convenient for old and still existing applications: telnet, ftp, ssh, which set TOS bits in some way, which used to be reasonable. Actually, even not four bits but only two bits are used. #2. If the host is inside diffserv environment all these things just have no effects and make no sense. That's why we do not change anything (except for disabling access to ECN bits). > reasons. Firstly, if we're using the old bit fields it should be the > precedence bits that are used for the skb priority rather than the tos > field. Secondly, the whole precedence/tos thing has been obsoleted by > the 6-bit DSCP field, of which the first 3 bits are supposed to be > backwards compatible with the old precedence field. Shouldn't we > properly handle that? See above #1. Precedence bits used to be _non-sense_ in the past and their use outside of context of setup of your routers (in pre-DS world) or outide context of diffserv does not make sense. What's about "backward-compatibility", it sounds funny, DS is made compatible with Cisco use precedence and this has nothing to do with end users (where socket options make sense), precedence bits are rewritten by routers for their own use. > Secondly, for vlan priority tagging there are only 3 bits available. > This means that practically speaking anyone using vlan priorities needs > to limit themselves to priorities 0-7. Thirdly. :-) Technically speaking, direct access of user to such things is prohibited in any case. So, use proper classifiers to do right mappings. > Currently, for me to send a packet with IP precedence bits set to a > nonzero value *and* vlan priority set to the same value, I have to do > the following: > > int opt = PRIORITY << 5; > setsockopt(mysocks[i], SOL_IP, IP_TOS, &opt, sizeof(opt)); > opt = PRIORITY; > setsockopt(mysocks[i], SOL_SOCKET, SO_PRIORITY, &opt, sizeof(opt)); This is right. > This is kind of ugly. Hmm.. This is kinda nice. IP_TOS sets real TOS bits without any funny shifts and masks, but with some reasonable access control, SO_PRIORITY sets priority. TOS and PRIORITY are not related. > I propose adding a new IP socket option, IP_DSCP, > which would let you set the 6-bit DSCP value (which is then shifted by > two bits in the kernel to generate the 8-bit value for the header > field). I do not even think that IP_DSCP makes sense in diffserv environment. Packets are marked according to DS rules, not according to desire of particular user. Anyway, the thing which you suggest is equal to IP_TOS in this part. > The high-order 3 bits would then be automatically used to set > the socket priority to make a vlan egress mapping simple. Not even subject to discuss... In old current world it is just wrong, in new world it is even wronger. If DSCP is used for prioritizing, it is used via proper classifiers, not via some rules hardcoded to kernel. Alexey From an3h0ny@yahoo.fr Tue Nov 4 05:32:41 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 05:33:15 -0800 (PST) Received: from web11105.mail.yahoo.com (web11105.mail.yahoo.com [216.136.131.152]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4DWf25032470 for ; Tue, 4 Nov 2003 05:32:41 -0800 Message-ID: <20031104133240.89887.qmail@web11105.mail.yahoo.com> Received: from [195.68.44.148] by web11105.mail.yahoo.com via HTTP; Tue, 04 Nov 2003 14:32:40 CET Date: Tue, 4 Nov 2003 14:32:40 +0100 (CET) From: =?iso-8859-1?q?an7?= Subject: tcp checksumming To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 1198 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: an3h0ny@yahoo.fr Precedence: bulk X-list: netdev Hello, In tcp_rcv_established(), when you are in fast path, you use checksum and copy (the first function in the chain is tcp_copy_to_iovec) to finally delivering data to the user. I browse datagram.c,checksum.h,skbuff.c,tcp_input.c and only sees (mainly by following function calls in datagram.c) checksum calculation, by a lot of calls to csum_fold() and csum_partial(), and copy to iovec, but i have never seen the checksum _verification_. I learn that skb->csum is (when you have not CHECKSUM UNECESSARY defined in the case of a device computing the checksum by itself) the checksum on running data.But it is used in all functions,and get replaced by a function result. I don't see where it is used as a comparison My question is pretty simple : where in the code, is the tcp checksum verified (compared to the computed one). My first impression was that it was done in the *copy_and_csum* functions, but i only see checksum computation. That is to say, it is like a side effect of keeping data in a buffer with a bad checksum.(maybe it is removed after ? i don't think so) PS : i have posted here many times, never get an answer. Please pay a little attention ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com From an3h0ny@yahoo.fr Tue Nov 4 05:36:28 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 05:37:02 -0800 (PST) Received: from web11102.mail.yahoo.com (web11102.mail.yahoo.com [216.136.131.149]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4DaG25000408 for ; Tue, 4 Nov 2003 05:36:28 -0800 Message-ID: <20031104133615.86082.qmail@web11102.mail.yahoo.com> Received: from [195.68.44.148] by web11102.mail.yahoo.com via HTTP; Tue, 04 Nov 2003 14:36:15 CET Date: Tue, 4 Nov 2003 14:36:15 +0100 (CET) From: =?iso-8859-1?q?an7?= Subject: tcp checksumming To: davem@redhat.com Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 1199 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: an3h0ny@yahoo.fr Precedence: bulk X-list: netdev Hello, In tcp_rcv_established(), when you are in fast path, you use checksum and copy (the first function in the chain is tcp_copy_to_iovec) to finally delivering data to the user. I browse datagram.c,checksum.h,skbuff.c,tcp_input.c and only sees (mainly by following function calls in datagram.c) checksum calculation, by a lot of calls to csum_fold() and csum_partial(), and copy to iovec, but i have never seen the checksum _verification_. I learn that skb->csum is (when you have not CHECKSUM UNECESSARY defined in the case of a device computing the checksum by itself) the checksum on running data.But it is used in all functions,and get replaced by a function result. I don't see where it is used as a comparison My question is pretty simple : where in the code, is the tcp checksum verified (compared to the computed one). My first impression was that it was done in the *copy_and_csum* functions, but i only see checksum computation. That is to say, it is like a side effect of keeping data in a buffer with a bad checksum.(maybe it is removed after ? i don't think so) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com From rmk@arm.linux.org.uk Tue Nov 4 06:28:50 2003 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Nov 2003 06:29:28 -0800 (PST) Received: from caramon.arm.linux.org.uk (caramon.arm.linux.org.uk [212.18.232.186]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA4ESm25001317 for ; Tue, 4 Nov 2003 06:28:49 -0800 Received: from flint.arm.linux.org.uk ([2002:d412:e8ba:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.22) id 1AH2Ai-0003ca-1L; Tue, 04 Nov 2003 14:28:40 +0000 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.22) id 1AH2Ah-0003GZ-9R; Tue, 04 Nov 2003 14:28:39 +0000 Date: Tue, 4 Nov 2003 14:28:39 +0000 From: Russell King To: davem@redhat.com, netdev@oss.sgi.com Subject: Fwd: tcp checksumming Message-ID: <20031104142839.C2207@flint.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i X-Message-Flag: Your copy of Microsoft Outlook is vulnerable to viruses. See www.mutt.org for more details. X-archive-position: 1200 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rmk@arm.linux.org.uk Precedence: bulk X-list: netdev Not my problem. Please ensure that replies are directed at the appropriate address (ie not me.) Thanks. ----- Forwarded message from an7 ----- Date: Tue, 4 Nov 2003 15:17:59 +0100 (CET) From: an7 Subject: tcp checksumming Hello, i am sorry russel, but i asked many times on netdev without having the answer, i tried to understand by myself during two weeks..please help me In tcp_rcv_established