From herbert@gondor.apana.org.au Sun May 1 01:12:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 01:12:13 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j418C77J031945 for ; Sun, 1 May 2005 01:12:09 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DS9YG-00057c-00; Sun, 01 May 2005 18:11:44 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DS9YC-0005Nz-00; Sun, 01 May 2005 18:11:40 +1000 Date: Sun, 1 May 2005 18:11:40 +1000 To: Tommy Christensen Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost Message-ID: <20050501081140.GA20647@gondor.apana.org.au> References: <426FDF8B.1030808@tpack.net> <20050427214224.GA25325@gondor.apana.org.au> <42701FFD.5000505@tpack.net> <20050427234359.GB22238@gondor.apana.org.au> <1114768308.4695.1487.camel@tsc-6.cph.tpack.net> <20050429101836.GA2237@gondor.apana.org.au> <1114777355.4695.1598.camel@tsc-6.cph.tpack.net> <20050429234512.GA22699@gondor.apana.org.au> <427380A8.2070006@tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427380A8.2070006@tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 501 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Hi Tommy: I agree with you now that your patch is the best way to go. On Sat, Apr 30, 2005 at 02:57:12PM +0200, Tommy Christensen wrote: > > Regarding the sort of NICs you mention, I came to the conclusion that > we shouldn't try to fix this in the stack. They indicate that they can > take more packets (by NOT calling netif_stop_queue), so we should obey > this and leave it to the drivers to handle things, e.g. by dropping the > packets if needed. Otherwise we deprive the drivers the option of > maintaining their tx_carrier_errors statistics, for instance. And, > theoretically, a driver could even depend on having its hard_start_xmit > invoked in order to kickstart its TX engine. We should document this so that NIC drivers are told about this. Any NICs that can't process their TX rings while the carrier is off needs to stop their queue just before calling netif_carrier_off. > So, I am reluctant to drop this check for netif_queue_stopped. Doing so > would needlessly impact the drivers that work fine already (or at least > should be handling this situation). I don't see how those drivers are worse off without this check. When the carrier is off it doesn't really matter whether we're sending them packets or not. Besides, you didn't put this check in the link_watch code path which would affect them a lot more than this path. > >The other concern I have is that this code can call dev_activate > >or dev_deactivate twice in a row. As far as I can tell this is > >harmless for the moment but it would be nice if we can avoid it. > > Agreed, this isn't ideal. However, if this is the only downside, it > is something that I'd be happy to live with. I don't see any easy > way to avoid it. > > Ideas, anyone? You mean how we can avoid the double call? Here is one way. Move the setting of IF_RUNNING out of dev_get_flags and into dev_activate. This would guarantee that IF_RUNNING is set iff the device has a qdisc. Assuming that you remove the aformentioned netif_queue_stopped check, the device has a qdisc iff the carrier is on. So this preserves the meaning of IF_RUNNING. Now you can avoid the double call by returning early in dev_activate if IF_RUNNING is set, and in dev_deactivate if IF_RUNNING is not set. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From adobriyan@mail.ru Sun May 1 01:29:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 01:29:31 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j418TQ7J000594 for ; Sun, 1 May 2005 01:29:26 -0700 Received: from [217.10.38.130] (port=48616 helo=mail.ru) by mx2.mail.ru with smtp id 1DS9pF-000G3B-00; Sun, 01 May 2005 12:29:17 +0400 Received: by mail.ru (nbSMTP-0.98) for uid 1000 for ; Sun, 1 May 2005 12:32:43 +0000 (GMT) Date: Sun, 1 May 2005 12:32:42 +0000 From: Alexey Dobriyan To: Jesper Juhl Cc: "David S. Miller" , Jouni Malinen , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] resource release cleanup in net/ Message-ID: <20050501123242.GA8407@mipter.zuzino.mipt.ru> Mail-Followup-To: Jesper Juhl , "David S. Miller" , Jouni Malinen , netdev@oss.sgi.com, linux-kernel@vger.kernel.org References: <20050501025349.GA9243@mipter.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 502 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adobriyan@mail.ru Precedence: bulk X-list: netdev On Sun, May 01, 2005 at 01:13:28AM +0200, Jesper Juhl wrote: > On Sun, 1 May 2005, Alexey Dobriyan wrote: > > > On Sat, Apr 30, 2005 at 10:36:00PM +0200, Jesper Juhl wrote: > > > Since Andrew merged the patch that makes calling crypto_free_tfm() with a > > > NULL pointer safe into 2.6.12-rc3-mm1, I made a patch to remove checks for > > > NULL before calling that function > > > drivers/net/wireless/hostap/hostap_crypt_ccmp.c | 5 - > > > drivers/net/wireless/hostap/hostap_crypt_tkip.c | 10 +- > > > drivers/net/wireless/hostap/hostap_crypt_wep.c | 5 - > > > net/ieee80211/ieee80211_crypt_ccmp.c | 5 - > > > net/ieee80211/ieee80211_crypt_tkip.c | 10 +- > > > net/ieee80211/ieee80211_crypt_wep.c | 5 - > > I think I have a better one for these. > > > > --- linux-2.6.12-rc3-mm1/drivers/net/wireless/hostap/hostap_crypt_ccmp.c 2005-05-01 01:53:50.000000000 +0000 > > +++ linux-2.6.12-rc3-mm1-hostap/drivers/net/wireless/hostap/hostap_crypt_ccmp.c 2005-05-01 02:21:10.000000000 +0000 > > @@ -121,8 +118,7 @@ fail: > > static void hostap_ccmp_deinit(void *priv) > > { > > struct hostap_ccmp_data *_priv = priv; > > - if (_priv && _priv->tfm) > > - crypto_free_tfm(_priv->tfm); > > + crypto_free_tfm(_priv->tfm); > > kfree(priv); > > module_put(THIS_MODULE); > > } > > This will Oops if _priv is NULL. That's why my patch did > > if (_priv) > crypto_free_tfm(_priv->tfm); After hostap_ccmp_init() returns successfully: 1. priv is valid pointer line 95 2. priv->tfm is valid pointer line 102 From akpm@osdl.org Sun May 1 03:29:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 03:29:16 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j41ATC7J004279 for ; Sun, 1 May 2005 03:29:12 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j41ASYs4012605 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 1 May 2005 03:28:39 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j41ASWQe010017; Sun, 1 May 2005 03:28:32 -0700 Date: Sun, 1 May 2005 03:28:09 -0700 From: Andrew Morton To: netfilter-devel@lists.netfilter.org Cc: netdev@oss.sgi.com Subject: CONFIG_NETFILTER_DEBUG spew Message-Id: <20050501032809.3d0b4cda.akpm@osdl.org> X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 503 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 With the below .config, `telnet localhost' spews stuff like this: [ 179.995229] ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN [ 179.995274] skb: pf=2 (unowned) dev=lo len=54 [ 179.995304] PROTO=6 127.0.0.1:23 127.0.0.1:2737 L=54 S=0x10 I=37030 F=0x4000 T=64 2.6.12-rc3 doesn't do this - it's something to do with changes in Linus's tree post-2.6.12-rc3. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc3 # Sun May 1 03:19:50 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="-arakou" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # 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_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # 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 is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODE 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=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=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=y # CONFIG_HPET_EMULATE_RTC is not set # CONFIG_SMP is not set # CONFIG_PREEMPT is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=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=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_REGPARM=y CONFIG_SECCOMP=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION="/dev/hda2" # # 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_VIDEO=m CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # 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_X86_PM_TIMER is not set CONFIG_ACPI_CONTAINER=m # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=m # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m # CONFIG_CPU_FREQ_STAT_DETAILS is not set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set # CONFIG_X86_SPEEDSTEP_ICH is not set # CONFIG_X86_SPEEDSTEP_SMI is not set # CONFIG_X86_P4_CLOCKMOD is not set # CONFIG_X86_CPUFREQ_NFORCE2 is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set # CONFIG_X86_SPEEDSTEP_LIB is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCIEPORTBUS is not set CONFIG_PCI_MSI=y # CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y # CONFIG_PCI_DEBUG is not set CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # # CONFIG_STANDALONE is not set CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_FW_LOADER is not set # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_GSC is not set CONFIG_PARPORT_1284=y # # Plug and Play support # # CONFIG_PNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_LBD is not set CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_ATA_OVER_ETH 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_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set CONFIG_BLK_DEV_IDEFLOPPY=m CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=m # CONFIG_BLK_DEV_CMD640 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_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP 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=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_ARM is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=y # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI Transport Attributes # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX 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_IN2000 is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=y # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set # CONFIG_IEEE1394_OUI_DB is not set # CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set # # Device Drivers # # CONFIG_IEEE1394_PCILYNX is not set # CONFIG_IEEE1394_OHCI1394 is not set # # Protocol Drivers # CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set # CONFIG_IEEE1394_ETH1394 is not set CONFIG_IEEE1394_RAWIO=m # CONFIG_IEEE1394_CMP is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y # CONFIG_IP_ROUTE_MULTIPATH is not set CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m # CONFIG_NET_IPGRE_BROADCAST is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD 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 CONFIG_INET_TUNNEL=m CONFIG_IP_TCPDIAG=y # CONFIG_IP_TCPDIAG_IPV6 is not set # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_INET6_TUNNEL=m # CONFIG_IPV6_TUNNEL is not set CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_BRIDGE_NETFILTER=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m # CONFIG_IP_NF_CT_ACCT is not set CONFIG_IP_NF_CONNTRACK_MARK=y # CONFIG_IP_NF_CT_PROTO_SCTP is not set CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m # CONFIG_IP_NF_AMANDA is not set CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m # CONFIG_IP_NF_MATCH_ECN is not set # CONFIG_IP_NF_MATCH_DSCP is not set # CONFIG_IP_NF_MATCH_AH_ESP is not set CONFIG_IP_NF_MATCH_LENGTH=m # CONFIG_IP_NF_MATCH_TTL is not set # CONFIG_IP_NF_MATCH_TCPMSS is not set CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m # CONFIG_IP_NF_MATCH_PHYSDEV is not set CONFIG_IP_NF_MATCH_ADDRTYPE=m # CONFIG_IP_NF_MATCH_REALM is not set # CONFIG_IP_NF_MATCH_SCTP is not set CONFIG_IP_NF_MATCH_COMMENT=m CONFIG_IP_NF_MATCH_CONNMARK=m CONFIG_IP_NF_MATCH_HASHLIMIT=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m # CONFIG_IP_NF_TARGET_ULOG is not set # CONFIG_IP_NF_TARGET_TCPMSS is not set CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m # CONFIG_IP_NF_TARGET_DSCP is not set CONFIG_IP_NF_TARGET_MARK=m # CONFIG_IP_NF_TARGET_CLASSIFY is not set CONFIG_IP_NF_TARGET_CONNMARK=m # CONFIG_IP_NF_TARGET_CLUSTERIP is not set # CONFIG_IP_NF_RAW is not set # CONFIG_IP_NF_ARPTABLES is not set # # IPv6: Netfilter Configuration (EXPERIMENTAL) # # CONFIG_IP6_NF_QUEUE is not set # CONFIG_IP6_NF_IPTABLES is not set # # Bridge: Netfilter Configuration # CONFIG_BRIDGE_NF_EBTABLES=m # CONFIG_BRIDGE_EBT_BROUTE is not set # CONFIG_BRIDGE_EBT_T_FILTER is not set # CONFIG_BRIDGE_EBT_T_NAT is not set # CONFIG_BRIDGE_EBT_802_3 is not set # CONFIG_BRIDGE_EBT_AMONG is not set # CONFIG_BRIDGE_EBT_ARP is not set # CONFIG_BRIDGE_EBT_IP is not set # CONFIG_BRIDGE_EBT_LIMIT is not set # CONFIG_BRIDGE_EBT_MARK is not set # CONFIG_BRIDGE_EBT_PKTTYPE is not set # CONFIG_BRIDGE_EBT_STP is not set # CONFIG_BRIDGE_EBT_VLAN is not set # CONFIG_BRIDGE_EBT_ARPREPLY is not set # CONFIG_BRIDGE_EBT_DNAT is not set # CONFIG_BRIDGE_EBT_MARK_T is not set # CONFIG_BRIDGE_EBT_REDIRECT is not set # CONFIG_BRIDGE_EBT_SNAT is not set # CONFIG_BRIDGE_EBT_LOG is not set # CONFIG_BRIDGE_EBT_ULOG is not set CONFIG_XFRM=y # CONFIG_XFRM_USER is not set # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set CONFIG_BRIDGE=m # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET 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 # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CLK_JIFFIES=y # CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set # CONFIG_NET_SCH_CLK_CPU is not set CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m # CONFIG_NET_QOS is not set # CONFIG_NET_CLS is not set # CONFIG_NET_CLS_ROUTE is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_EQUALIZER=m CONFIG_TUN=m # # ARCnet devices # # CONFIG_ARCNET is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_CS89x0 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=m CONFIG_8139TOO_PIO=y CONFIG_8139TOO_TUNE_TWISTER=y CONFIG_8139TOO_8129=y CONFIG_8139_OLD_RX_RESET=y # 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 # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set CONFIG_SK98LIN=m # CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_S2IO is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set CONFIG_PLIP=m CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set # CONFIG_PPP_FILTER is not set CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # # ISDN subsystem # # CONFIG_ISDN 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=m # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # # CONFIG_SERIAL_8250 is not set # # Non-8250 serial port support # # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_PRINTER is not set CONFIG_PPDEV=m # CONFIG_TIPAR is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_HW_RANDOM=m CONFIG_NVRAM=m 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=y # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set # CONFIG_AGP_INTEL is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set CONFIG_AGP_VIA=y # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set # CONFIG_HANGCHECK_TIMER is not set # # TPM devices # # CONFIG_TCG_TPM is not set # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set CONFIG_I2C_ELEKTOR=m # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_ISA is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_STUB is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # CONFIG_I2C_VOODOO3 is not set # CONFIG_I2C_PCA_ISA is not set # # Hardware Sensors Chip support # # CONFIG_I2C_SENSOR is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_FSCPOS is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83627HF is not set # # Other I2C Chip support # # CONFIG_SENSORS_DS1337 is not set # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_RTC8564 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # # CONFIG_VIDEO_BT848 is not set # CONFIG_VIDEO_PMS is not set # 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_SAA5246A 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_SAA7134 is not set # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_DPC is not set # CONFIG_VIDEO_HEXIUM_ORION is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # CONFIG_VIDEO_CX88 is not set # CONFIG_VIDEO_OVCAMCHIP is not set # # Radio Adapters # # CONFIG_RADIO_CADET is not set # CONFIG_RADIO_RTRACK is not set # CONFIG_RADIO_RTRACK2 is not set # CONFIG_RADIO_AZTECH is not set # CONFIG_RADIO_GEMTEK is not set # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # CONFIG_RADIO_SF16FMI is not set # CONFIG_RADIO_SF16FMR2 is not set # CONFIG_RADIO_TERRATEC is not set # CONFIG_RADIO_TRUST is not set # CONFIG_RADIO_TYPHOON is not set # CONFIG_RADIO_ZOLTRIX is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # CONFIG_FB=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_SOFT_CURSOR=y # CONFIG_FB_MACMODES is not set CONFIG_FB_MODE_HELPERS=y # CONFIG_FB_TILEBLITTING is not set # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set CONFIG_FB_VGA16=m CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y # CONFIG_FB_HGA is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_I810 is not set # CONFIG_FB_INTEL is not set # CONFIG_FB_MATROX is not set CONFIG_FB_RADEON_OLD=m CONFIG_FB_RADEON=m # CONFIG_FB_RADEON_I2C is not set # CONFIG_FB_RADEON_DEBUG is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_S1D13XXX 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=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 # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m # CONFIG_SND_SEQUENCER_OSS is not set # CONFIG_SND_RTCTIMER is not set # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=m # 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 is not set # # ISA devices # # CONFIG_SND_AD1848 is not set # CONFIG_SND_CS4231 is not set # CONFIG_SND_CS4232 is not set # CONFIG_SND_CS4236 is not set # CONFIG_SND_ES1688 is not set # CONFIG_SND_ES18XX is not set # CONFIG_SND_GUSCLASSIC is not set # CONFIG_SND_GUSEXTREME is not set # CONFIG_SND_GUSMAX is not set # CONFIG_SND_INTERWAVE is not set # CONFIG_SND_INTERWAVE_STB is not set # CONFIG_SND_OPTI92X_AD1848 is not set # CONFIG_SND_OPTI92X_CS4231 is not set # CONFIG_SND_OPTI93X is not set # CONFIG_SND_SB8 is not set # CONFIG_SND_SB16 is not set # CONFIG_SND_SBAWE is not set # CONFIG_SND_WAVEFRONT is not set # CONFIG_SND_CMI8330 is not set # CONFIG_SND_OPL3SA2 is not set # CONFIG_SND_SGALAXY is not set # CONFIG_SND_SSCAPE is not set # # PCI devices # CONFIG_SND_AC97_CODEC=m # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MIXART 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_INTEL8X0M is not set # CONFIG_SND_SONICVIBES is not set CONFIG_SND_VIA82XX=m # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_HDA_INTEL is not set # # USB devices # # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB=m # 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 # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m # CONFIG_USB_EHCI_SPLIT_ISO is not set CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_OHCI_HCD=m # CONFIG_USB_OHCI_BIG_ENDIAN is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m # CONFIG_USB_SL811_HCD is not set # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_MIDI is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # 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_USBAT 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 Input Devices # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_MTOUCH is not set # CONFIG_USB_EGALAX is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK 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_SE401 is not set # CONFIG_USB_SN9C102 is not set # CONFIG_USB_STV680 is not set # CONFIG_USB_PWC is not set # # USB Network Adapters # # 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 CONFIG_USB_MON=m # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGETKIT is not set # CONFIG_USB_PHIDGETSERVO is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_TEST is not set # # USB ATM/DSL drivers # # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # MMC/SD Card support # # CONFIG_MMC is not set # # InfiniBand support # # CONFIG_INFINIBAND is not set # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y # CONFIG_EXT2_FS_SECURITY is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y # CONFIG_EXT3_FS_SECURITY is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y # CONFIG_REISERFS_FS_SECURITY is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y # # XFS support # # CONFIG_XFS_FS is not set CONFIG_MINIX_FS=m CONFIG_ROMFS_FS=m # CONFIG_QUOTA is not set CONFIG_DNOTIFY=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=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVPTS_FS_XATTR is not set CONFIG_TMPFS=y # CONFIG_TMPFS_XATTR is not set # 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_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set CONFIG_CRAMFS=y # 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 is not set # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y # CONFIG_NFSD_V4 is not set CONFIG_NFSD_TCP=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=y CONFIG_SUNRPC=y # CONFIG_RPCSEC_GSS_KRB5 is not set # CONFIG_RPCSEC_GSS_SPKM3 is not set CONFIG_SMB_FS=m CONFIG_SMB_NLS_DEFAULT=y CONFIG_SMB_NLS_REMOTE="cp850" CONFIG_CIFS=m # CONFIG_CIFS_STATS is not set # CONFIG_CIFS_XATTR is not set # CONFIG_CIFS_EXPERIMENTAL is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m # 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=m # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_PRINTK_TIME=y CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y CONFIG_LOG_BUF_SHIFT=14 # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_HIGHMEM is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_FS is not set CONFIG_FRAME_POINTER=y CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_KPROBES is not set # CONFIG_DEBUG_STACK_USAGE is not set # # Page alloc debug is incompatible with Software Suspend on i386 # CONFIG_4KSTACKS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set CONFIG_CRYPTO_WP512=m # CONFIG_CRYPTO_TGR192 is not set CONFIG_CRYPTO_DES=m # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_AES_586 is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_ARC4 is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_ANUBIS is not set CONFIG_CRYPTO_DEFLATE=m # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_TEST is not set # # Hardware crypto devices # # CONFIG_CRYPTO_DEV_PADLOCK is not set # # Library routines # CONFIG_CRC_CCITT=m CONFIG_CRC32=y # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y From herbert@gondor.apana.org.au Sun May 1 04:15:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 04:15:47 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j41BFe7J006904 for ; Sun, 1 May 2005 04:15:41 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSCPo-0005tL-00; Sun, 01 May 2005 21:15:12 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSCPj-0000Za-00; Sun, 01 May 2005 21:15:07 +1000 Date: Sun, 1 May 2005 21:15:07 +1000 To: Patrick McHardy Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, Andrew Morton Subject: Re: CONFIG_NETFILTER_DEBUG spew Message-ID: <20050501111507.GA2133@gondor.apana.org.au> References: <20050501032809.3d0b4cda.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050501032809.3d0b4cda.akpm@osdl.org> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 504 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Sun, May 01, 2005 at 10:28:09AM +0000, Andrew Morton wrote: > > With the below .config, `telnet localhost' spews stuff like this: > > [ 179.995229] ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN > [ 179.995274] skb: pf=2 (unowned) dev=lo len=54 > [ 179.995304] PROTO=6 127.0.0.1:23 127.0.0.1:2737 L=54 S=0x10 I=37030 F=0x4000 T=64 > > 2.6.12-rc3 doesn't do this - it's something to do with changes in Linus's > tree post-2.6.12-rc3. Patrick, looks like we need to fix nf_debug_ip_local_deliver to reflect the newly added nf_reset on the ip_output path. BTW, should we do nf_reset in ip_dev_loopback_xmit as well? -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From bunk@stusta.de Sun May 1 06:56:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 06:56:26 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j41DuJ7J017122 for ; Sun, 1 May 2005 06:56:20 -0700 Received: (qmail 14345 invoked from network); 1 May 2005 13:56:07 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 1 May 2005 13:56:07 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 9AE7CBB5D6; Sun, 1 May 2005 15:56:07 +0200 (CEST) Date: Sun, 1 May 2005 15:56:07 +0200 From: Adrian Bunk To: jkmaline@cc.hut.fi Cc: hostap@shmoo.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [-mm patch] net/ieee80211/: remove pci.h #include's Message-ID: <20050501135607.GD3592@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1593 Lines: 44 I was wondering why editing pci.h triggered the rebuild of three files under net/, and as far as I can see, there's no reason for these three files to #include pci.h . Signed-off-by: Adrian Bunk --- net/ieee80211/ieee80211_module.c | 1 - net/ieee80211/ieee80211_rx.c | 1 - net/ieee80211/ieee80211_tx.c | 1 - 3 files changed, 3 deletions(-) --- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_module.c.old 2005-04-30 23:23:14.000000000 +0200 +++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_module.c 2005-04-30 23:23:18.000000000 +0200 @@ -40,7 +40,6 @@ #include #include #include -#include #include #include #include --- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_tx.c.old 2005-04-30 23:23:25.000000000 +0200 +++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_tx.c 2005-04-30 23:23:32.000000000 +0200 @@ -33,7 +33,6 @@ #include #include #include -#include #include #include #include --- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_rx.c.old 2005-04-30 23:23:42.000000000 +0200 +++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_rx.c 2005-04-30 23:23:46.000000000 +0200 @@ -23,7 +23,6 @@ #include #include #include -#include #include #include #include From kaber@trash.net Sun May 1 08:17:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 08:17:20 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j41FHG7J020898 for ; Sun, 1 May 2005 08:17:17 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DSGBp-0002AQ-HQ; Sun, 01 May 2005 17:17:01 +0200 Message-ID: <4274F2ED.9080404@trash.net> Date: Sun, 01 May 2005 17:17:01 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, Andrew Morton , "David S. Miller" Subject: Re: CONFIG_NETFILTER_DEBUG spew References: <20050501032809.3d0b4cda.akpm@osdl.org> <20050501111507.GA2133@gondor.apana.org.au> In-Reply-To: <20050501111507.GA2133@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------070805040200040001000308" X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 509 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2748 Lines: 79 This is a multi-part message in MIME format. --------------070805040200040001000308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > On Sun, May 01, 2005 at 10:28:09AM +0000, Andrew Morton wrote: > >>With the below .config, `telnet localhost' spews stuff like this: >> >>[ 179.995229] ip_local_deliver: bad loopback skb: PRE_ROUTING LOCAL_IN >>[ 179.995274] skb: pf=2 (unowned) dev=lo len=54 >>[ 179.995304] PROTO=6 127.0.0.1:23 127.0.0.1:2737 L=54 S=0x10 I=37030 F=0x4000 T=64 >> >>2.6.12-rc3 doesn't do this - it's something to do with changes in Linus's >>tree post-2.6.12-rc3. > > Patrick, looks like we need to fix nf_debug_ip_local_deliver to > reflect the newly added nf_reset on the ip_output path. You're right. I'm tempted to remove the entire nf_debug stuff, as far as I know it has never found a real bug. But for now I've only fixed the warning. > BTW, should we do nf_reset in ip_dev_loopback_xmit as well? I think so. I'll send a patch later, I'm a bit in a hurry right now. Regards Patrick --------------070805040200040001000308 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" [NETFILTER]: Fix nf_debug_ip_local_deliver() Signed-off-by: Patrick McHardy --- commit a91b6fa8bc4b1626d413d58c21cfcfecabbb4a61 tree 9544bb88b28c2e3ca4b0a66fedfa2bb540ec06e2 parent e8108c98dd6d65613fa0ec9d2300f89c48d554bf author Patrick McHardy 1114952978 +0200 committer Patrick McHardy 1114952978 +0200 Index: net/core/netfilter.c =================================================================== --- 3608de2fc88b062070a9d197eda9cac1fb9635d3/net/core/netfilter.c (mode:100644 sha1:e51cfa46950cf8f1f4dea42be94e71d76d8c3c5b) +++ 9544bb88b28c2e3ca4b0a66fedfa2bb540ec06e2/net/core/netfilter.c (mode:100644 sha1:92c51824797dd15018e579eb5753cc372e04fd3d) @@ -217,21 +217,10 @@ * NF_IP_RAW_INPUT and NF_IP_PRE_ROUTING. */ if (!skb->dev) { printk("ip_local_deliver: skb->dev is NULL.\n"); - } - else if (strcmp(skb->dev->name, "lo") == 0) { - if (skb->nf_debug != ((1 << NF_IP_LOCAL_OUT) - | (1 << NF_IP_POST_ROUTING) - | (1 << NF_IP_PRE_ROUTING) - | (1 << NF_IP_LOCAL_IN))) { - printk("ip_local_deliver: bad loopback skb: "); - debug_print_hooks_ip(skb->nf_debug); - nf_dump_skb(PF_INET, skb); - } - } - else { + } else { if (skb->nf_debug != ((1<nf_debug); nf_dump_skb(PF_INET, skb); } --------------070805040200040001000308-- From bunk@stusta.de Sun May 1 08:42:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 08:42:15 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j41FgA7J025577 for ; Sun, 1 May 2005 08:42:11 -0700 Received: (qmail 17005 invoked from network); 1 May 2005 15:42:01 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 1 May 2005 15:42:01 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 3B69EAFC8E; Sun, 1 May 2005 17:42:01 +0200 (CEST) Date: Sun, 1 May 2005 17:42:01 +0200 From: Adrian Bunk To: Andrew Morton Cc: linux@syskonnect.de, Jeff Garzik , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [2.6 patch] remove drivers/net/skfp/lnkstat.c Message-ID: <20050501154201.GH3592@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 510 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 5847 Lines: 232 This patch removes a file that seems to be used only on AIX (sic). Signed-off-by: Adrian Bunk --- This patch was already sent on: - 20 Apr 2005 drivers/net/skfp/Makefile | 2 drivers/net/skfp/lnkstat.c | 204 ------------------------------------- 2 files changed, 1 insertion(+), 205 deletions(-) --- linux-2.6.12-rc2-mm3-full/drivers/net/skfp/Makefile.old 2005-04-20 01:39:14.000000000 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/net/skfp/Makefile 2005-04-20 01:39:33.000000000 +0200 @@ -6,7 +6,7 @@ skfp-objs := skfddi.o hwmtm.o fplustm.o smt.o cfm.o \ ecm.o pcmplc.o pmf.o queue.o rmt.o \ - smtdef.o smtinit.o smttimer.o srf.o lnkstat.o \ + smtdef.o smtinit.o smttimer.o srf.o \ hwt.o drvfbi.o ess.o # NOTE: --- linux-2.6.12-rc2-mm3-full/drivers/net/skfp/lnkstat.c 2005-04-20 01:35:22.000000000 +0200 +++ /dev/null 2005-03-19 22:42:59.000000000 +0100 @@ -1,204 +0,0 @@ -/****************************************************************************** - * - * (C)Copyright 1998,1999 SysKonnect, - * a business unit of Schneider & Koch & Co. Datensysteme GmbH. - * - * See the file "skfddi.c" for further information. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * The information in this file is provided "AS IS" without warranty. - * - ******************************************************************************/ - -/* - IBM FDDI read error log function -*/ - -#include "h/types.h" -#include "h/fddi.h" -#include "h/smc.h" -#include "h/lnkstat.h" - -#ifndef lint -static const char ID_sccs[] = "@(#)lnkstat.c 1.8 97/04/11 (C) SK " ; -#endif - -#ifdef sun -#define _far -#endif - -#define EL_IS_OK(x,l) ((((int)&(((struct s_error_log *)0)->x)) + \ - sizeof(er->x)) <= l) - -/* - BEGIN_MANUAL_ENTRY(if,func;others;11) - - u_long smt_get_error_word(smc) - struct s_smc *smc ; - -Function DOWNCALL (SMT, lnkstat.c) - This functions returns the SMT error work for AIX events. - -Return smt_error_word These bits are supported: - - SMT_ERL_ALC == [PS/PA].fddiPORTLerFlag - SMT_ERL_BLC == [PB].fddiPORTLerFlag - SMT_ERL_NCC == fddiMACNotCopiedFlag - SMT_ERL_FEC == fddiMACFrameErrorFlag - - END_MANUAL_ENTRY() - */ -u_long smt_get_error_word(struct s_smc *smc) -{ - u_long st; - - /* - * smt error word low - */ - st = 0 ; - if (smc->s.sas == SMT_SAS) { - if (smc->mib.p[PS].fddiPORTLerFlag) - st |= SMT_ERL_ALC ; - } - else { - if (smc->mib.p[PA].fddiPORTLerFlag) - st |= SMT_ERL_ALC ; - if (smc->mib.p[PB].fddiPORTLerFlag) - st |= SMT_ERL_BLC ; - } - if (smc->mib.m[MAC0].fddiMACNotCopiedFlag) - st |= SMT_ERL_NCC ; /* not copied condition */ - if (smc->mib.m[MAC0].fddiMACFrameErrorFlag) - st |= SMT_ERL_FEC ; /* frame error condition */ - - return st; -} - -/* - BEGIN_MANUAL_ENTRY(if,func;others;11) - - u_long smt_get_event_word(smc) - struct s_smc *smc ; - -Function DOWNCALL (SMT, lnkstat.c) - This functions returns the SMT event work for AIX events. - -Return smt_event_word always 0 - - END_MANUAL_ENTRY() - */ -u_long smt_get_event_word(struct s_smc *smc) -{ - return (u_long) 0; -} - -/* - BEGIN_MANUAL_ENTRY(if,func;others;11) - - u_long smt_get_port_event_word(smc) - struct s_smc *smc ; - -Function DOWNCALL (SMT, lnkstat.c) - This functions returns the SMT port event work for AIX events. - -Return smt_port_event_word always 0 - - END_MANUAL_ENTRY() - */ -u_long smt_get_port_event_word(struct s_smc *smc) -{ - return (u_long) 0; -} - -/* - BEGIN_MANUAL_ENTRY(if,func;others;11) - - u_long smt_read_errorlog(smc,p,len) - struct s_smc *smc ; - char _far *p ; - int len ; - -Function DOWNCALL (SMT, lnkstat.c) - This functions returns the SMT error log field for AIX events. - -Para p pointer to the error log field - len len of the error log field - -Return len used len of the error log field - - END_MANUAL_ENTRY() - */ -int smt_read_errorlog(struct s_smc *smc, char _far *p, int len) -{ - int i ; - int st ; - struct s_error_log _far *er ; - - er = (struct s_error_log _far *) p ; - if (len > sizeof(struct s_error_log)) - len = sizeof(struct s_error_log) ; - for (i = 0 ; i < len ; i++) - *p++ = 0 ; - /* - * set count - */ - if (EL_IS_OK(set_count_high,len)) { - er->set_count_low = (u_short)smc->mib.fddiSMTSetCount.count ; - er->set_count_high = - (u_short)(smc->mib.fddiSMTSetCount.count >> 16L) ; - } - /* - * aci - */ - if (EL_IS_OK(aci_id_code,len)) { - er->aci_id_code = 0 ; - } - /* - * purge counter is missed frames; 16 bits only - */ - if (EL_IS_OK(purge_frame_counter,len)) { - if (smc->mib.m[MAC0].fddiMACCopied_Ct > 0xffff) - er->purge_frame_counter = 0xffff ; - else - er->purge_frame_counter = - (u_short)smc->mib.m[MAC0].fddiMACCopied_Ct ; - } - /* - * CMT and RMT state machines - */ - if (EL_IS_OK(ecm_state,len)) - er->ecm_state = smc->mib.fddiSMTECMState ; - - if (EL_IS_OK(pcm_b_state,len)) { - if (smc->s.sas == SMT_SAS) { - er->pcm_a_state = smc->y[PS].mib->fddiPORTPCMState ; - er->pcm_b_state = 0 ; - } - else { - er->pcm_a_state = smc->y[PA].mib->fddiPORTPCMState ; - er->pcm_b_state = smc->y[PB].mib->fddiPORTPCMState ; - } - } - if (EL_IS_OK(cfm_state,len)) - er->cfm_state = smc->mib.fddiSMTCF_State ; - if (EL_IS_OK(rmt_state,len)) - er->rmt_state = smc->mib.m[MAC0].fddiMACRMTState ; - - /* - * smt error word low (we only need the low order 16 bits.) - */ - - st = smt_get_error_word(smc) & 0xffff ; - - if (EL_IS_OK(smt_error_low,len)) - er->smt_error_low = st ; - - if (EL_IS_OK(ucode_version_level,len)) - er->ucode_version_level = 0x0101 ; - return(len) ; -} - From venza@brownhat.org Sun May 1 09:44:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 09:44:10 -0700 (PDT) Received: from gateway.milesteg.arr (adsl-10-231.38-151.net24.it [151.38.231.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j41Gi27J027527 for ; Sun, 1 May 2005 09:44:06 -0700 Received: (qmail 8822 invoked from network); 1 May 2005 16:43:52 -0000 Received: from unknown (HELO ?192.168.0.205?) (192.168.0.205) by gateway.milesteg.arr with SMTP; 1 May 2005 16:43:52 -0000 In-Reply-To: <20050430115249.GA3654@stusta.de> References: <20050429231653.32d2f091.akpm@osdl.org> <20050430115249.GA3654@stusta.de> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5c6061e021b4bd91a5b6ee47fbb7f575@brownhat.org> Content-Transfer-Encoding: 7bit Cc: Jeff Garzik , Linux Kernel Mailing List , Adrian Bunk , Netdev From: Daniele Venzano Subject: Re: [-mm patch] SIS900 must select MII Date: Sun, 1 May 2005 18:43:46 +0200 To: Andrew Morton X-Mailer: Apple Mail (2.622) X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 511 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: venza@brownhat.org Precedence: bulk X-list: netdev Content-Length: 860 Lines: 31 On 30/apr/05, at 13:52, Adrian Bunk wrote: > This patch fixes the following compile error caused by bk-netdev: > > <-- snip --> > > Signed-off-by: Adrian Bunk Signed-off-by: Daniele Venzano > --- linux-2.6.12-rc3-mm1/drivers/net/Kconfig.old 2005-04-30 > 13:47:25.000000000 +0200 > +++ linux-2.6.12-rc3-mm1/drivers/net/Kconfig 2005-04-30 > 13:47:48.000000000 +0200 > @@ -1543,8 +1543,9 @@ > config SIS900 > tristate "SiS 900/7016 PCI Fast Ethernet Adapter support" > depends on NET_PCI && PCI > select CRC32 > + select MII > ---help--- > This is a driver for the Fast Ethernet PCI network cards based on > the SiS 900 and SiS 7016 chips. The SiS 900 core is also embedded > in > SiS 630 and SiS 540 chipsets. If you have one of those, say Y and > > -- Daniele Venzano http://www.brownhat.org From tgraf@suug.ch Sun May 1 11:47:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 11:47:26 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j41IlJ7J032006 for ; Sun, 1 May 2005 11:47:22 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 16AB81C0EB; Sun, 1 May 2005 20:47:32 +0200 (CEST) Date: Sun, 1 May 2005 20:47:31 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 1/2] [XFRM] Prevent off-by-one access to xfrm_dispatch Message-ID: <20050501184731.GJ577@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 520 Lines: 18 Makes the type > XFRM_MSG_MAX check behave correctly to protect access to xfrm_dispatch. Signed-off-by: Thomas Graf --- linux-2.6.12-rc3.orig/include/linux/xfrm.h 2005-04-30 20:22:19.000000000 +0200 +++ linux-2.6.12-rc3/include/linux/xfrm.h 2005-05-01 11:53:30.000000000 +0200 @@ -140,8 +140,9 @@ XFRM_MSG_FLUSHPOLICY, #define XFRM_MSG_FLUSHPOLICY XFRM_MSG_FLUSHPOLICY - XFRM_MSG_MAX + __XFRM_MSG_MAX }; +#define XFRM_MSG_MAX (__XFRM_MSG_MAX - 1) struct xfrm_user_tmpl { struct xfrm_id id; From tgraf@suug.ch Sun May 1 11:55:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 11:55:38 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j41ItZ7J032616 for ; Sun, 1 May 2005 11:55:36 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 6DD1B1C0EB; Sun, 1 May 2005 20:55:48 +0200 (CEST) Date: Sun, 1 May 2005 20:55:48 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH 2/2] [XFRM] Cleanup xfrm_msg_min and xfrm_dispatch Message-ID: <20050501185548.GK577@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 513 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 4959 Lines: 113 Converts xfrm_msg_min and xfrm_dispatch to use c99 designated initializers to make greping a little bit easier. Also replaces two hardcoded message type with meaningful names. Signed-off-by: Thomas Graf diff -Nru -X dontdiff linux-2.6.12-rc3.orig/include/linux/xfrm.h linux-2.6.12-rc3/include/linux/xfrm.h --- linux-2.6.12-rc3.orig/include/linux/xfrm.h 2005-05-01 13:17:00.000000000 +0200 +++ linux-2.6.12-rc3/include/linux/xfrm.h 2005-05-01 12:21:08.000000000 +0200 @@ -144,6 +144,8 @@ }; #define XFRM_MSG_MAX (__XFRM_MSG_MAX - 1) +#define XFRM_NR_MSGTYPES (XFRM_MSG_MAX + 1 - XFRM_MSG_BASE) + struct xfrm_user_tmpl { struct xfrm_id id; __u16 family; diff -Nru -X dontdiff linux-2.6.12-rc3.orig/net/xfrm/xfrm_user.c linux-2.6.12-rc3/net/xfrm/xfrm_user.c --- linux-2.6.12-rc3.orig/net/xfrm/xfrm_user.c 2005-04-30 20:22:26.000000000 +0200 +++ linux-2.6.12-rc3/net/xfrm/xfrm_user.c 2005-05-01 14:52:48.000000000 +0200 @@ -855,47 +855,44 @@ return 0; } -static const int xfrm_msg_min[(XFRM_MSG_MAX + 1 - XFRM_MSG_BASE)] = { - NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)), /* NEW SA */ - NLMSG_LENGTH(sizeof(struct xfrm_usersa_id)), /* DEL SA */ - NLMSG_LENGTH(sizeof(struct xfrm_usersa_id)), /* GET SA */ - NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_info)),/* NEW POLICY */ - NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_id)), /* DEL POLICY */ - NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_id)), /* GET POLICY */ - NLMSG_LENGTH(sizeof(struct xfrm_userspi_info)), /* ALLOC SPI */ - NLMSG_LENGTH(sizeof(struct xfrm_user_acquire)), /* ACQUIRE */ - NLMSG_LENGTH(sizeof(struct xfrm_user_expire)), /* EXPIRE */ - NLMSG_LENGTH(sizeof(struct xfrm_userpolicy_info)),/* UPD POLICY */ - NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)), /* UPD SA */ - NLMSG_LENGTH(sizeof(struct xfrm_user_polexpire)), /* POLEXPIRE */ - NLMSG_LENGTH(sizeof(struct xfrm_usersa_flush)), /* FLUSH SA */ - NLMSG_LENGTH(0), /* FLUSH POLICY */ +#define XMSGSIZE(type) NLMSG_LENGTH(sizeof(struct type)) + +static const int xfrm_msg_min[XFRM_NR_MSGTYPES] = { + [XFRM_MSG_NEWSA - XFRM_MSG_BASE] = XMSGSIZE(xfrm_usersa_info), + [XFRM_MSG_DELSA - XFRM_MSG_BASE] = XMSGSIZE(xfrm_usersa_id), + [XFRM_MSG_GETSA - XFRM_MSG_BASE] = XMSGSIZE(xfrm_usersa_id), + [XFRM_MSG_NEWPOLICY - XFRM_MSG_BASE] = XMSGSIZE(xfrm_userpolicy_info), + [XFRM_MSG_DELPOLICY - XFRM_MSG_BASE] = XMSGSIZE(xfrm_userpolicy_id), + [XFRM_MSG_GETPOLICY - XFRM_MSG_BASE] = XMSGSIZE(xfrm_userpolicy_id), + [XFRM_MSG_ALLOCSPI - XFRM_MSG_BASE] = XMSGSIZE(xfrm_userspi_info), + [XFRM_MSG_ACQUIRE - XFRM_MSG_BASE] = XMSGSIZE(xfrm_user_acquire), + [XFRM_MSG_EXPIRE - XFRM_MSG_BASE] = XMSGSIZE(xfrm_user_expire), + [XFRM_MSG_UPDPOLICY - XFRM_MSG_BASE] = XMSGSIZE(xfrm_userpolicy_info), + [XFRM_MSG_UPDSA - XFRM_MSG_BASE] = XMSGSIZE(xfrm_usersa_info), + [XFRM_MSG_POLEXPIRE - XFRM_MSG_BASE] = XMSGSIZE(xfrm_user_polexpire), + [XFRM_MSG_FLUSHSA - XFRM_MSG_BASE] = XMSGSIZE(xfrm_usersa_flush), + [XFRM_MSG_FLUSHPOLICY - XFRM_MSG_BASE] = NLMSG_LENGTH(0), }; +#undef XMSGSIZE + static struct xfrm_link { int (*doit)(struct sk_buff *, struct nlmsghdr *, void **); int (*dump)(struct sk_buff *, struct netlink_callback *); -} xfrm_dispatch[] = { - { .doit = xfrm_add_sa, }, - { .doit = xfrm_del_sa, }, - { - .doit = xfrm_get_sa, - .dump = xfrm_dump_sa, - }, - { .doit = xfrm_add_policy }, - { .doit = xfrm_get_policy }, - { - .doit = xfrm_get_policy, - .dump = xfrm_dump_policy, - }, - { .doit = xfrm_alloc_userspi }, - {}, - {}, - { .doit = xfrm_add_policy }, - { .doit = xfrm_add_sa, }, - {}, - { .doit = xfrm_flush_sa }, - { .doit = xfrm_flush_policy }, +} xfrm_dispatch[XFRM_NR_MSGTYPES] = { + [XFRM_MSG_NEWSA - XFRM_MSG_BASE] = { .doit = xfrm_add_sa }, + [XFRM_MSG_DELSA - XFRM_MSG_BASE] = { .doit = xfrm_del_sa }, + [XFRM_MSG_GETSA - XFRM_MSG_BASE] = { .doit = xfrm_get_sa, + .dump = xfrm_dump_sa }, + [XFRM_MSG_NEWPOLICY - XFRM_MSG_BASE] = { .doit = xfrm_add_policy }, + [XFRM_MSG_DELPOLICY - XFRM_MSG_BASE] = { .doit = xfrm_get_policy }, + [XFRM_MSG_GETPOLICY - XFRM_MSG_BASE] = { .doit = xfrm_get_policy, + .dump = xfrm_dump_policy }, + [XFRM_MSG_ALLOCSPI - XFRM_MSG_BASE] = { .doit = xfrm_alloc_userspi }, + [XFRM_MSG_UPDPOLICY - XFRM_MSG_BASE] = { .doit = xfrm_add_policy }, + [XFRM_MSG_UPDSA - XFRM_MSG_BASE] = { .doit = xfrm_add_sa }, + [XFRM_MSG_FLUSHSA - XFRM_MSG_BASE] = { .doit = xfrm_flush_sa }, + [XFRM_MSG_FLUSHPOLICY - XFRM_MSG_BASE] = { .doit = xfrm_flush_policy }, }; static int xfrm_done(struct netlink_callback *cb) @@ -931,7 +928,9 @@ return -1; } - if ((type == 2 || type == 5) && (nlh->nlmsg_flags & NLM_F_DUMP)) { + if ((type == (XFRM_MSG_GETSA - XFRM_MSG_BASE) || + type == (XFRM_MSG_GETPOLICY - XFRM_MSG_BASE)) && + (nlh->nlmsg_flags & NLM_F_DUMP)) { u32 rlen; if (link->dump == NULL) From herbert@gondor.apana.org.au Sun May 1 16:10:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 16:10:51 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j41NAU7J011026 for ; Sun, 1 May 2005 16:10:31 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSNYR-000292-00; Mon, 02 May 2005 09:08:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSNYJ-0004Il-00; Mon, 02 May 2005 09:08:43 +1000 Date: Mon, 2 May 2005 09:08:43 +1000 To: Jesper Juhl Cc: "David S. Miller" , Jouni Malinen , James Morris , Pedro Roque , Alexey Kuznetsov , Kunihiro Ishiguro , Mitsuru KANDA , lksctp-developers@lists.sourceforge.net, Andy Adamson , Bruce Fields , netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] resource release cleanup in net/ Message-ID: <20050501230843.GA16518@gondor.apana.org.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 515 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 776 Lines: 19 On Sat, Apr 30, 2005 at 10:36:00PM +0200, Jesper Juhl wrote: > > Since Andrew merged the patch that makes calling crypto_free_tfm() with a > NULL pointer safe into 2.6.12-rc3-mm1, I made a patch to remove checks for > NULL before calling that function, and while I was at it I removed similar > redundant checks before calls to kfree() and vfree() in the same files. > There are also a few tiny whitespace cleanups in there. Hi Jesper: Could we wait until the crypto_free_tfm patch gets into the main tree? Most people here track that instead of mm. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From juhl-lkml@dif.dk Sun May 1 16:18:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 16:18:39 -0700 (PDT) Received: from saerimmer.dif.dk (mail.dif.dk [193.138.115.101]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j41NIa7J012046 for ; Sun, 1 May 2005 16:18:37 -0700 Received: from localhost (localhost [127.0.0.1]) by saerimmer.dif.dk (Postfix) with ESMTP id 28AF2FF410 for ; Mon, 2 May 2005 01:30:03 +0200 (CEST) Received: from saerimmer.dif.dk ([127.0.0.1]) by localhost (saerimmer [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09349-05 for ; Mon, 2 May 2005 01:29:57 +0200 (CEST) Received: from diftmgw2.backbone.dif.dk (diftmgw2.backbone.dif.dk [10.227.136.246]) by saerimmer.dif.dk (Postfix) with ESMTP id 8063AFFC6E for ; Mon, 2 May 2005 01:29:54 +0200 (CEST) Received: from DIFPST1A.backbone.dif.dk ([10.227.136.220]) by diftmgw2.backbone.dif.dk with InterScan Messaging Security Suite; Mon, 02 May 2005 01:16:52 +0200 Received: from [172.16.2.11] (10.227.136.29 [10.227.136.29]) by DIFPST1A.backbone.dif.dk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JVV1AQ3J; Mon, 2 May 2005 01:18:14 +0200 Date: Mon, 2 May 2005 01:21:50 +0200 (CEST) From: Jesper Juhl To: Herbert Xu Cc: "David S. Miller" , Jouni Malinen , James Morris , Pedro Roque , Alexey Kuznetsov , Kunihiro Ishiguro , Mitsuru KANDA , lksctp-developers@lists.sourceforge.net, Andy Adamson , Bruce Fields , YOSHIFUJI Hideaki , netdev@oss.sgi.com, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] resource release cleanup in net/ In-Reply-To: <20050501230843.GA16518@gondor.apana.org.au> Message-ID: References: <20050501230843.GA16518@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Scanned: amavisd-new at dif.dk X-Virus-Status: Clean X-archive-position: 516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: juhl-lkml@dif.dk Precedence: bulk X-list: netdev Content-Length: 747 Lines: 25 On Mon, 2 May 2005, Herbert Xu wrote: > On Sat, Apr 30, 2005 at 10:36:00PM +0200, Jesper Juhl wrote: > > > > Since Andrew merged the patch that makes calling crypto_free_tfm() with a > > NULL pointer safe into 2.6.12-rc3-mm1, I made a patch to remove checks for > > NULL before calling that function, and while I was at it I removed similar > > redundant checks before calls to kfree() and vfree() in the same files. > > There are also a few tiny whitespace cleanups in there. > > Hi Jesper: > > Could we wait until the crypto_free_tfm patch gets into the main tree? > Most people here track that instead of mm. > Sure. I don't have a problem with that. I'll just hold on to the patches and resend them at a later date. -- Jesper From bunk@stusta.de Sun May 1 18:47:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 18:47:43 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j421la7J020786 for ; Sun, 1 May 2005 18:47:37 -0700 Received: (qmail 31136 invoked from network); 2 May 2005 01:47:27 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 2 May 2005 01:47:27 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 96553BBA1B; Mon, 2 May 2005 03:47:26 +0200 (CEST) Date: Mon, 2 May 2005 03:47:26 +0200 From: Adrian Bunk To: Andrew Morton Cc: Jeff Garzik , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] drivers/net/arcnet/: possible cleanups Message-ID: <20050502014726.GH3592@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 527 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 5052 Lines: 161 This patch contains the following possible cleanups: - make needlessly global code static - arcnet.c: remove the outdated VERSION - arcnet.c: remove the unneeded EXPORT_SYMBOL(arc_proto_null) - arcnet.c: remove the unneeded EXPORT_SYMBOL(arcnet_dump_packet) Signed-off-by: Adrian Bunk --- This patch was already sent on: - 15 Apr 2005 - 24 Mar 2005 drivers/net/arcnet/arc-rawmode.c | 2 +- drivers/net/arcnet/arcnet.c | 19 ++++++++++--------- drivers/net/arcnet/rfc1051.c | 2 +- drivers/net/arcnet/rfc1201.c | 3 +-- include/linux/arcdevice.h | 9 --------- 5 files changed, 13 insertions(+), 22 deletions(-) --- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arc-rawmode.c.old 2005-02-16 15:16:38.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arc-rawmode.c 2005-02-16 15:16:51.000000000 +0100 @@ -42,7 +42,7 @@ static int prepare_tx(struct net_device *dev, struct archdr *pkt, int length, int bufnum); -struct ArcProto rawmode_proto = +static struct ArcProto rawmode_proto = { .suffix = 'r', .mtu = XMTU, --- linux-2.6.11-rc3-mm2-full/include/linux/arcdevice.h.old 2005-02-16 15:17:26.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/include/linux/arcdevice.h 2005-02-16 15:20:57.000000000 +0100 @@ -206,7 +206,6 @@ extern struct ArcProto *arc_proto_map[256], *arc_proto_default, *arc_bcast_proto, *arc_raw_proto; -extern struct ArcProto arc_proto_null; /* @@ -334,17 +333,9 @@ #define arcnet_dump_skb(dev,skb,desc) ; #endif -#if (ARCNET_DEBUG_MAX & D_RX) || (ARCNET_DEBUG_MAX & D_TX) -void arcnet_dump_packet(struct net_device *dev, int bufnum, char *desc, - int take_arcnet_lock); -#else -#define arcnet_dump_packet(dev, bufnum, desc,take_arcnet_lock) ; -#endif - void arcnet_unregister_proto(struct ArcProto *proto); irqreturn_t arcnet_interrupt(int irq, void *dev_id, struct pt_regs *regs); struct net_device *alloc_arcdev(char *name); -void arcnet_rx(struct net_device *dev, int bufnum); #endif /* __KERNEL__ */ #endif /* _LINUX_ARCDEVICE_H */ --- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arcnet.c.old 2005-02-16 15:17:47.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arcnet.c 2005-02-16 15:21:20.000000000 +0100 @@ -41,8 +41,6 @@ * */ -#define VERSION "arcnet: v3.93 BETA 2000/04/29 - by Avery Pennarun et al.\n" - #include #include #include @@ -61,6 +59,7 @@ static int null_prepare_tx(struct net_device *dev, struct archdr *pkt, int length, int bufnum); +static void arcnet_rx(struct net_device *dev, int bufnum); /* * one ArcProto per possible proto ID. None of the elements of @@ -71,7 +70,7 @@ struct ArcProto *arc_proto_map[256], *arc_proto_default, *arc_bcast_proto, *arc_raw_proto; -struct ArcProto arc_proto_null = +static struct ArcProto arc_proto_null = { .suffix = '?', .mtu = XMTU, @@ -90,7 +89,6 @@ EXPORT_SYMBOL(arc_proto_default); EXPORT_SYMBOL(arc_bcast_proto); EXPORT_SYMBOL(arc_raw_proto); -EXPORT_SYMBOL(arc_proto_null); EXPORT_SYMBOL(arcnet_unregister_proto); EXPORT_SYMBOL(arcnet_debug); EXPORT_SYMBOL(alloc_arcdev); @@ -118,8 +116,8 @@ arcnet_debug = debug; - printk(VERSION); + printk("arcnet loaded.\n"); #ifdef ALPHA_WARNING BUGLVL(D_EXTRA) { printk("arcnet: ***\n" @@ -178,8 +174,8 @@ * Dump the contents of an ARCnet buffer */ #if (ARCNET_DEBUG_MAX & (D_RX | D_TX)) -void arcnet_dump_packet(struct net_device *dev, int bufnum, char *desc, - int take_arcnet_lock) +static void arcnet_dump_packet(struct net_device *dev, int bufnum, + char *desc, int take_arcnet_lock) { struct arcnet_local *lp = dev->priv; int i, length; @@ -208,7 +204,10 @@ } -EXPORT_SYMBOL(arcnet_dump_packet); +#else + +#define arcnet_dump_packet(dev, bufnum, desc,take_arcnet_lock) do { } while (0) + #endif @@ -987,7 +986,7 @@ * This is a generic packet receiver that calls arcnet??_rx depending on the * protocol ID found. */ -void arcnet_rx(struct net_device *dev, int bufnum) +static void arcnet_rx(struct net_device *dev, int bufnum) { struct arcnet_local *lp = dev->priv; struct archdr pkt; --- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1051.c.old 2005-02-16 15:22:16.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1051.c 2005-02-16 15:22:23.000000000 +0100 @@ -43,7 +43,7 @@ int bufnum); -struct ArcProto rfc1051_proto = +static struct ArcProto rfc1051_proto = { .suffix = 's', .mtu = XMTU - RFC1051_HDR_SIZE, --- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1201.c.old 2005-02-16 15:22:35.000000000 +0100 +++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1201.c 2005-02-16 15:22:46.000000000 +0100 @@ -43,7 +43,7 @@ int bufnum); static int continue_tx(struct net_device *dev, int bufnum); -struct ArcProto rfc1201_proto = +static struct ArcProto rfc1201_proto = { .suffix = 'a', .mtu = 1500, /* could be more, but some receivers can't handle it... */ From nacc@us.ibm.com Sun May 1 23:15:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 23:15:11 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j426F17J032730 for ; Sun, 1 May 2005 23:15:07 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j426EoeE370080 for ; Mon, 2 May 2005 02:14:50 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j426Eoxj307560 for ; Mon, 2 May 2005 00:14:50 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j426EoQX022528 for ; Mon, 2 May 2005 00:14:50 -0600 Received: from joust (sig-9-49-132-50.mts.ibm.com [9.49.132.50]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j426Enoa022521; Mon, 2 May 2005 00:14:49 -0600 Received: by joust (Postfix, from userid 1000) id B83FF4F9FF; Sun, 1 May 2005 23:14:46 -0700 (PDT) Date: Sun, 1 May 2005 23:14:46 -0700 From: Nishanth Aravamudan To: philb@gnu.org Cc: netdev@oss.sgi.com, Kernel-Janitors Subject: [PATCH] net/3c505: replace schedule_timeout() with msleep() Message-ID: <20050502061446.GB10173@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Linux 2.6.12-rc3-mm2 (i686) User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 528 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1028 Lines: 27 Use msleep() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan --- 2.6.12-rc3/drivers/net/3c505.c 2005-04-29 11:03:04.000000000 -0700 +++ 2.6.12-rc3-dev/drivers/net/3c505.c 2005-05-01 20:52:01.000000000 -0700 @@ -1317,8 +1317,7 @@ static int __init elp_sense(struct net_d if (orig_HSR & DIR) { /* If HCR.DIR is up, we pull it down. HSR.DIR should follow. */ outb(0, dev->base_addr + PORT_CONTROL); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(30*HZ/100); + msleep(300); if (inb_status(addr) & DIR) { if (elp_debug > 0) printk(notfound_msg, 2); @@ -1327,8 +1326,7 @@ static int __init elp_sense(struct net_d } else { /* If HCR.DIR is down, we pull it up. HSR.DIR should follow. */ outb(DIR, dev->base_addr + PORT_CONTROL); - set_current_state(TASK_UNINTERRUPTIBLE); - schedule_timeout(30*HZ/100); + msleep(300); if (!(inb_status(addr) & DIR)) { if (elp_debug > 0) printk(notfound_msg, 3); From nacc@us.ibm.com Sun May 1 23:35:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 May 2005 23:35:25 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j426ZC7J001548 for ; Sun, 1 May 2005 23:35:14 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j426Z14I316888 for ; Mon, 2 May 2005 02:35:02 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j426Z1xj302036 for ; Mon, 2 May 2005 00:35:01 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j426Z1OS008521 for ; Mon, 2 May 2005 00:35:01 -0600 Received: from joust (sig-9-49-132-50.mts.ibm.com [9.49.132.50]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j426Z0Ns008432; Mon, 2 May 2005 00:35:00 -0600 Received: by joust (Postfix, from userid 1000) id E10324F9FF; Sun, 1 May 2005 23:34:57 -0700 (PDT) Date: Sun, 1 May 2005 23:34:57 -0700 From: Nishanth Aravamudan To: loz@holmes.demon.co.uk, waltje@uwalt.nl.mugnet.org.sgi.com Cc: netdev@oss.sgi.com, Kernel-Janitors Subject: [PATCH] net/slip: replace schedule_timeout() with msleep_interruptible() Message-ID: <20050502063457.GG10173@us.ibm.com> References: <20050502061446.GB10173@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050502061446.GB10173@us.ibm.com> X-Operating-System: Linux 2.6.12-rc3-mm2 (i686) User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 529 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nacc@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 572 Lines: 18 Use msleep_interruptible() instead of schedule_timeout() to guarantee the task delays as expected. --- 2.6.12-rc3/drivers/net/slip.c 2005-03-01 23:38:33.000000000 -0800 +++ 2.6.12-rc3-dev/drivers/net/slip.c 2005-05-01 20:53:08.000000000 -0700 @@ -1395,10 +1395,8 @@ static void __exit slip_exit(void) /* First of all: check for active disciplines and hangup them. */ do { - if (busy) { - set_current_state(TASK_INTERRUPTIBLE); - schedule_timeout(HZ / 10); - } + if (busy) + msleep_interruptible(100); busy = 0; for (i = 0; i < slip_maxdev; i++) { From hadi@cyberus.ca Mon May 2 05:10:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 05:11:04 -0700 (PDT) Received: from mx04.cybersurf.com (mx04.cybersurf.com [209.197.145.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42CAv7J025372 for ; Mon, 2 May 2005 05:10:57 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx04.cybersurf.com with esmtp (Exim 4.30) id 1DSZl6-0006Ss-JV for netdev@oss.sgi.com; Mon, 02 May 2005 08:10:44 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DSZl3-0008Oc-7a; Mon, 02 May 2005 08:10:41 -0400 Subject: Re: patch: Action repeat From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Patrick McHardy , netdev , "David S. Miller" In-Reply-To: <20050430235809.GI577@postel.suug.ch> References: <1114879817.8929.117.camel@localhost.localdomain> <4273BB30.1050402@trash.net> <4273BBAA.6060405@trash.net> <1114882045.8929.123.camel@localhost.localdomain> <4273CAB7.6080403@trash.net> <1114890709.8929.147.camel@localhost.localdomain> <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Mon, 02 May 2005 08:10:38 -0400 Message-Id: <1115035838.8929.236.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/861/Sat Apr 30 02:28:52 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1601 Lines: 38 On Sun, 2005-01-05 at 01:58 +0200, Thomas Graf wrote: > * jamal <1114900485.8929.171.camel@localhost.localdomain> 2005-04-30 18:34 [..] > > Perhaps we can reuse classid by flagging somewhere? > > A good place to do it is tc_verdict. There a few bits still left. > > We could set a bit to say the meaning of classid to be global vs local. > > Sounds good to me, I'm not quite sure if I still have a good enough > picture of your action code. Let's assume we have ematches and an > action setting the classid at ingress. The action sets the above flag > to state the global scope. Which means the classid is not reset by exec(). > The packet passes the stack and the > classid gets copied into the new encapsulated packet. On the egress > device we have something like a nop action assigning the classid > to res->classid. How do we make sure that the classid remains > untouched even if the packet passes a dummy device in between having > actions configured? Can we we still have functional actions on > this dummy device? I would say that if dummy changes it because of a policy, then thats a fair deal. i.e filter blah blah \ action add meta classid global :23 I am beginning to think that perhaps classid should stay as a local scope metadata and what Patrick suggested maybe the way out. Although i have to admit I dont like a generic function to have a parameter that only a very small set of users find useful. If we are going to allow a structure to be passed back and forth, perhaps it should also carry other things (in addition to _result). Need to think a little. cheers, jamal From markb@wetlettuce.com Mon May 2 05:58:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 05:58:39 -0700 (PDT) Received: from piglet.wetlettuce.com (piglet.wetlettuce.com [82.68.149.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42Cwa7J028503 for ; Mon, 2 May 2005 05:58:36 -0700 Received: from tigger.wetlettuce.com ([82.68.149.65] helo=tigger ident=Debian-exim) by piglet.wetlettuce.com with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 1DSaTh-0001tr-00; Mon, 02 May 2005 13:56:49 +0100 Received: from localhost ([127.0.0.1] ident=mark) by tigger with esmtp (Exim 4.50) id 1DSaTf-0003Ap-9E; Mon, 02 May 2005 13:56:47 +0100 Message-ID: <4276238E.4060606@wetlettuce.com> Date: Mon, 02 May 2005 13:56:46 +0100 From: Mark Broadbent User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sergey Vlasov CC: "David S. Miller" , Herbert Xu , netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock References: <20050429093521.274adf9a.davem@davemloft.net> <20050429214336.04b40b3f.vsu@altlinux.ru> In-Reply-To: <20050429214336.04b40b3f.vsu@altlinux.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Wetlettuce-MailScanner: Mail is clear of Viree X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: markb@wetlettuce.com Precedence: bulk X-list: netdev Content-Length: 1973 Lines: 56 Sergey Vlasov wrote: > On Fri, 29 Apr 2005 09:35:21 -0700 David S. Miller wrote: > > >>Look at most interrupt handlers in the kernel, they use >>spin_lock_irqsave() rather consistently. If an interrupt >>is registered with SA_SHIRQ, this is a requirement. >>Here is why. >> >>On i386 (or any other platform using the generic IRQ layer), >>for example, unless you specify SA_INTERRUPT at >>request_irq() time, the handler dispatch is: >> >> local_irq_enable(); >> >> for each irq registered { >> x->handler(); >> } >> local_irq_disable(); >> >>(see kernel/irq/handle.c) >> >>At the top level from that handle_IRQ_event() function, the >>IRQ source is ACK'd after those calls. >> >>However, if you have multiple devices on that IRQ line, you >>run into a problem. Let's say TUlip interrupts first and >>we go into the Tulip driver and grab the lock, next the other >>device interrupts and we jump into the Tulip interrupt handler >>again, we will deadlock but what we should have done is use >>IRQ disabling spin locking like Mark's fix does. > > > If what you wrote above is really correct, this means that > Documentation/DocBook/kernel-locking.sgml contains wrong information: See Documentation/spin-locking.txt line 137, this states that spin_[un]lock() should not be used in IRQ handlers. >>>>The irq handler does not to use spin_lock_irq(), because the >>>>softirq cannot run while the irq handler is running: it can use >>>>spin_lock(), which is slightly faster. The only exception would >>>>be if a different hardware irq handler uses the same lock: >>>>spin_lock_irq() will stop that from interrupting us. > > > AFAIK, even if interrupts are enabled, the IRQ line which is currently > handled is disabled in the interrupt controller, therefore the > interrupt handler cannot be reentered (for the same device instance). > Did this really change? As far as I can tell this is the case (disclaimer applies) [see my other reply to Herbert Xu]. Thanks Mark From markb@wetlettuce.com Mon May 2 05:59:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 05:59:09 -0700 (PDT) Received: from piglet.wetlettuce.com (piglet.wetlettuce.com [82.68.149.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42Cx67J028655 for ; Mon, 2 May 2005 05:59:07 -0700 Received: from tigger.wetlettuce.com ([82.68.149.65] helo=tigger ident=Debian-exim) by piglet.wetlettuce.com with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 1DSaUL-0001u0-00; Mon, 02 May 2005 13:57:29 +0100 Received: from localhost ([127.0.0.1] ident=mark) by tigger with esmtp (Exim 4.50) id 1DSaUK-0003BB-TF; Mon, 02 May 2005 13:57:29 +0100 Message-ID: <427623B8.8050107@wetlettuce.com> Date: Mon, 02 May 2005 13:57:28 +0100 From: Mark Broadbent User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock References: <20050429093521.274adf9a.davem@davemloft.net> <20050429224931.GA18616@gondor.apana.org.au> In-Reply-To: <20050429224931.GA18616@gondor.apana.org.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Wetlettuce-MailScanner: Mail is clear of Viree X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: markb@wetlettuce.com Precedence: bulk X-list: netdev Content-Length: 1664 Lines: 48 Herbert Xu wrote: > On Fri, Apr 29, 2005 at 09:35:21AM -0700, David S. Miller wrote: > >>On i386 (or any other platform using the generic IRQ layer), >>for example, unless you specify SA_INTERRUPT at >>request_irq() time, the handler dispatch is: >> >> local_irq_enable(); > > > Yes you're absolutely correct. > > >>However, if you have multiple devices on that IRQ line, you >>run into a problem. Let's say TUlip interrupts first and >>we go into the Tulip driver and grab the lock, next the other >>device interrupts and we jump into the Tulip interrupt handler >>again, we will deadlock but what we should have done is use >>IRQ disabling spin locking like Mark's fix does. > > > However, I don't see how this can happen. __do_IRQ ensures > that the handlers on a single IRQ aren't reentered by desc->lock > and desc->status. Softirqs are also kept out by irq_enter. Am > I missing something? As far as I can see desc->lock is dropped before handle_IRQ_event() is called in __do_IRQ() (kernel/irq/handle.c:170) and desc->status does not prevent the execution of the IRQ handler. Same with softirqs, interrupts are enabled when the handler is called (kernel/softirq.c:89). Thanks Mark >>Therefore I think his patch is perfectly fine and this is an >>excellent area for an audit of the entire tree. I even just >>noticed recently that some of the Sparc drivers/serial/ >>drivers were not taking the interrupt handler lock correctly like >>this (ie. using irqsave). > > > Unless these drivers are registering two different IRQ lines that > can nest within each other, I still think that a plain spin_lock is > safe and desirable. > > Cheers, From jeroens@office.netland.nl Mon May 2 06:22:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 06:22:33 -0700 (PDT) Received: from services-04.netland.nl (mx1.netland.nl [217.170.32.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42DMT7J030384 for ; Mon, 2 May 2005 06:22:29 -0700 Received: from n010095.nbs.netland.nl (fw.office.netland.nl [217.170.32.40]) by services-04.netland.nl (Postfix) with ESMTP id 4A0E45400B for ; Mon, 2 May 2005 15:22:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by n010095.nbs.netland.nl (Postfix) with ESMTP id 0858EA4EC for ; Mon, 2 May 2005 15:22:18 +0200 (CEST) Received: from n010095.nbs.netland.nl ([127.0.0.1]) by localhost (n010095.nbs.netland.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19927-03-4 for ; Mon, 2 May 2005 15:22:17 +0200 (CEST) Received: from jeroens.office.netland.nl (jeroens.office.netland.nl [192.168.170.25]) by n010095.nbs.netland.nl (Postfix) with ESMTP id 1B7F2A4EA for ; Mon, 2 May 2005 15:22:17 +0200 (CEST) Subject: icmp_unreachable uses wrong ip From: "J. Simonetti" To: netdev@oss.sgi.com Content-Type: multipart/mixed; boundary="=-Q2xJWlJ7VlmjEMgXdZYq" Organization: Netland Internet Services Date: Mon, 02 May 2005 15:21:19 +0200 Message-Id: <1115040079.5620.11.camel@jeroens.office.netland.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Scanned: by amavisd-new at n010095.nbs.netland.nl X-Virus-Status: Clean X-archive-position: 534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jeroens@office.netland.nl Precedence: bulk X-list: netdev Content-Length: 1252 Lines: 40 --=-Q2xJWlJ7VlmjEMgXdZYq Content-Type: text/plain Content-Transfer-Encoding: 7bit I've recently come to notice that traceroutes through a linux router use the wrong ip (ip of exitting interface) wich should actually be the ip of the incomming interface. I've found a trivial patch (attached) wich resolves this. Perhaps this is something to include (or have a sysctl to toggle this behaviour). I unfortunately have no knowledge of programming, so the sysctl option would have te be done by a volunteer. Regards, Jeroen Simonetti -- Netland Internet Services http://www.netland.nl I despise the pleasure of pleasing people whom I despise. --=-Q2xJWlJ7VlmjEMgXdZYq Content-Disposition: attachment; filename=icmp_traceroute.patch Content-Type: text/x-patch; name=icmp_traceroute.patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- net/ipv4/icmp.orig 2005-05-02 04:55:53.512447464 +0200 +++ net/ipv4/icmp.c 2005-05-02 04:56:21.370212440 +0200 @@ -512,7 +512,7 @@ saddr = iph->daddr; if (!(rt->rt_flags & RTCF_LOCAL)) - saddr = 0; + saddr = inet_select_addr(skb_in->dev, 0, RT_SCOPE_LINK); tos = icmp_pointers[type].error ? ((iph->tos & IPTOS_TOS_MASK) | IPTOS_PREC_INTERNETCONTROL) : --=-Q2xJWlJ7VlmjEMgXdZYq-- From hasso@estpak.ee Mon May 2 06:59:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 06:59:23 -0700 (PDT) Received: from arena.estpak.ee (test.estpak.ee [194.126.115.47]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42DxK7J032643 for ; Mon, 2 May 2005 06:59:21 -0700 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.50) id 1DSbRy-0001Ad-FQ; Mon, 02 May 2005 16:59:06 +0300 From: Hasso Tepper To: "J. Simonetti" Subject: Re: icmp_unreachable uses wrong ip Date: Mon, 2 May 2005 16:59:05 +0300 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com References: <1115040079.5620.11.camel@jeroens.office.netland.nl> In-Reply-To: <1115040079.5620.11.camel@jeroens.office.netland.nl> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_pIjdCRH/C+iyHjz" Message-Id: <200505021659.05674.hasso@estpak.ee> X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 535 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 3797 Lines: 102 --Boundary-00=_pIjdCRH/C+iyHjz Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline J. Simonetti wrote: > I've recently come to notice that traceroutes through a linux router use > the wrong ip (ip of exitting interface) wich should actually be the ip > of the incomming interface. There is nothing _wrong_ with this behaviour. Linux just behaves this way. > I've found a trivial patch (attached) wich resolves this. Perhaps this > is something to include (or have a sysctl to toggle this behaviour). I > unfortunately have no knowledge of programming, so the sysctl option > would have te be done by a volunteer. Similar patches have been posted to the list repeatedly AFAIK with no any response from developers. Can someone enlighten us why? Is there something wrong with it? This is the feature people administrating routers would like to have. It makes debugging complicated topologies much easier and all routers I have seen behave this way. I'm attaching patch which was posted to the list some time ago. I'm using it for some time already. I can't find the post from the archive though at the moment. -- Hasso Tepper Elion Enterprises Ltd. WAN administrator --Boundary-00=_pIjdCRH/C+iyHjz Content-Type: text/x-diff; charset="iso-8859-6"; name="linux-2.4.26-icmperrors.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.4.26-icmperrors.patch" diff -ru linux-2.4.26/include/linux/sysctl.h linux-2.4.26-icmperrors/include/linux/sysctl.h --- linux-2.4.26/include/linux/sysctl.h 2004-04-14 14:05:40.000000000 +0100 +++ linux-2.4.26-icmperrors/include/linux/sysctl.h 2004-09-23 22:52:16.000000000 +0100 @@ -314,6 +314,7 @@ NET_IPV4_IPFRAG_SECRET_INTERVAL=94, NET_TCP_WESTWOOD=95, NET_IPV4_IGMP_MAX_MSF=96, + NET_IPV4_ICMP_ERRORS_USE_INBOUND_IFADDR=97, }; enum { diff -ru linux-2.4.26/net/ipv4/icmp.c linux-2.4.26-icmperrors/net/ipv4/icmp.c --- linux-2.4.26/net/ipv4/icmp.c 2004-04-14 14:05:41.000000000 +0100 +++ linux-2.4.26-icmperrors/net/ipv4/icmp.c 2004-09-23 22:52:38.000000000 +0100 @@ -162,6 +162,7 @@ int sysctl_icmp_ratelimit = 1*HZ; int sysctl_icmp_ratemask = 0x1818; +int sysctl_icmp_errors_use_inbound_ifaddr = 0; /* * ICMP control array. This specifies what to do with each ICMP. @@ -452,8 +453,12 @@ #endif saddr = iph->daddr; - if (!(rt->rt_flags & RTCF_LOCAL)) - saddr = 0; + if (!(rt->rt_flags & RTCF_LOCAL)) { + if(sysctl_icmp_errors_use_inbound_ifaddr) + saddr = inet_select_addr(skb_in->dev, 0, RT_SCOPE_LINK); + else + saddr = 0; + } tos = icmp_pointers[type].error ? ((iph->tos & IPTOS_TOS_MASK) | IPTOS_PREC_INTERNETCONTROL) : diff -ru linux-2.4.26/net/ipv4/sysctl_net_ipv4.c linux-2.4.26-icmperrors/net/ipv4/sysctl_net_ipv4.c --- linux-2.4.26/net/ipv4/sysctl_net_ipv4.c 2004-04-14 14:05:41.000000000 +0100 +++ linux-2.4.26-icmperrors/net/ipv4/sysctl_net_ipv4.c 2004-09-23 22:53:07.000000000 +0100 @@ -22,6 +22,7 @@ extern int sysctl_icmp_echo_ignore_all; extern int sysctl_icmp_echo_ignore_broadcasts; extern int sysctl_icmp_ignore_bogus_error_responses; +extern int sysctl_icmp_errors_use_inbound_ifaddr; /* From ip_fragment.c */ extern int sysctl_ipfrag_low_thresh; @@ -181,6 +182,9 @@ {NET_IPV4_ICMP_IGNORE_BOGUS_ERROR_RESPONSES, "icmp_ignore_bogus_error_responses", &sysctl_icmp_ignore_bogus_error_responses, sizeof(int), 0644, NULL, &proc_dointvec}, + {NET_IPV4_ICMP_ERRORS_USE_INBOUND_IFADDR, "icmp_errors_use_inbound_ifaddr", + &sysctl_icmp_errors_use_inbound_ifaddr, sizeof(int), 0644, NULL, + &proc_dointvec}, {NET_IPV4_ROUTE, "route", NULL, 0, 0555, ipv4_route_table}, #ifdef CONFIG_IP_MULTICAST {NET_IPV4_IGMP_MAX_MEMBERSHIPS, "igmp_max_memberships", --Boundary-00=_pIjdCRH/C+iyHjz-- From pmarques@grupopie.com Mon May 2 07:16:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 07:16:44 -0700 (PDT) Received: from bipbip.comserver-pie.com ([195.23.16.24]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42EGV7J001668 for ; Mon, 2 May 2005 07:16:37 -0700 Received: from bipbip.comserver-pie.com (localhost [127.0.0.1]) by VAMS.dummy (Postfix) with SMTP id 8460E26B139; Mon, 2 May 2005 15:12:36 +0100 (WEST) Received: from [192.168.0.198] (195-23-20-139.net.novis.pt [195.23.20.139]) by bipbip.comserver-pie.com (Postfix) with ESMTP id 9521F26B139; Mon, 2 May 2005 15:12:33 +0100 (WEST) Message-ID: <4276362B.1010004@grupopie.com> Date: Mon, 02 May 2005 15:16:11 +0100 From: Paulo Marques Organization: Grupo PIE User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Broadbent Cc: linux-kernel@vger.kernel.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 536 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pmarques@grupopie.com Precedence: bulk X-list: netdev Content-Length: 614 Lines: 17 Mark Broadbent wrote: > The interrupt handling code in the tulip network driver appears to use a non > IRQ safe spinlock in an interrupt context. The following patch should correct > this. Huh? Can a network interrupt handler be interrupted by the same interrupt? AFAIK, the spin_lock_irqsave is to disable interruptions so that an interrupt can not happen in the critical section, so that the interrupt handler can not make modifications to shared data. Am I wrong? -- Paulo Marques - www.grupopie.com All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke (1729 - 1797) From kaber@trash.net Mon May 2 07:52:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 07:52:20 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42EqI7J003659 for ; Mon, 2 May 2005 07:52:18 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DScHG-0000wu-EL; Mon, 02 May 2005 16:52:06 +0200 Message-ID: <42763E96.1070209@trash.net> Date: Mon, 02 May 2005 16:52:06 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Hasso Tepper CC: "J. Simonetti" , netdev@oss.sgi.com Subject: Re: icmp_unreachable uses wrong ip References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505021659.05674.hasso@estpak.ee> In-Reply-To: <200505021659.05674.hasso@estpak.ee> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 537 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 452 Lines: 11 Hasso Tepper wrote: > Similar patches have been posted to the list repeatedly AFAIK with no any > response from developers. Can someone enlighten us why? Is there something > wrong with it? This is the feature people administrating routers would like > to have. It makes debugging complicated topologies much easier and all > routers I have seen behave this way. Why can't you simply add the prefered source address to the route? Regards Patrick From tgraf@suug.ch Mon May 2 08:06:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 08:06:27 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42F6L7J004705 for ; Mon, 2 May 2005 08:06:22 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id CE4031C0EB; Mon, 2 May 2005 17:06:32 +0200 (CEST) Date: Mon, 2 May 2005 17:06:32 +0200 From: Thomas Graf To: jamal Cc: Patrick McHardy , netdev , "David S. Miller" Subject: Re: patch: Action repeat Message-ID: <20050502150632.GM577@postel.suug.ch> References: <4273BBAA.6060405@trash.net> <1114882045.8929.123.camel@localhost.localdomain> <4273CAB7.6080403@trash.net> <1114890709.8929.147.camel@localhost.localdomain> <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115035838.8929.236.camel@localhost.localdomain> X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 538 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1162 Lines: 23 * jamal <1115035838.8929.236.camel@localhost.localdomain> 2005-05-02 08:10 > I would say that if dummy changes it because of a policy, then thats a > fair deal. i.e > > filter blah blah \ > action add meta classid global :23 Absolutely, given it is requested by the user. My main concern are dependencies on classid invisble to the user. > I am beginning to think that perhaps classid should stay as a local > scope metadata and what Patrick suggested maybe the way out. Although i > have to admit I dont like a generic function to have a parameter that > only a very small set of users find useful. If we are going to allow a > structure to be passed back and forth, perhaps it should also carry > other things (in addition to _result). Need to think a little. What about if we introduce something like struct tcf_pkt_info as we have it for ematches? I'm using it intensly to share information from the classifier to ematches to extend and customize existing classifier. We could declare tc_classid as being global by definition and hide the current use in the API? I'd really like to be able to transfer classification results from one device to another. From kaber@trash.net Mon May 2 09:13:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 09:13:12 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42GD87J011655 for ; Mon, 2 May 2005 09:13:09 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DSdXL-0007Y5-43; Mon, 02 May 2005 18:12:47 +0200 Message-ID: <4276517F.6030606@trash.net> Date: Mon, 02 May 2005 18:12:47 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, Andrew Morton , "David S. Miller" Subject: Re: CONFIG_NETFILTER_DEBUG spew References: <20050501032809.3d0b4cda.akpm@osdl.org> <20050501111507.GA2133@gondor.apana.org.au> In-Reply-To: <20050501111507.GA2133@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------070605040806010003070303" X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 1989 Lines: 59 This is a multi-part message in MIME format. --------------070605040806010003070303 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Herbert Xu wrote: > BTW, should we do nf_reset in ip_dev_loopback_xmit as well? I think we should, tc actions could do something unexpected with the packet. Regards Patrick --------------070605040806010003070303 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" [NETFILTER]: Drop conntrack reference in ip_dev_loopback_xmit() Signed-off-by: Patrick McHardy --- commit c4644e58c8b52dca9699e8ee0e975f5f13eb4d2c tree 35d8915a3fd6fa39a46d9b2e8e1fd272e82ea3af parent a91b6fa8bc4b1626d413d58c21cfcfecabbb4a61 author Patrick McHardy 1115049922 +0200 committer Patrick McHardy 1115049922 +0200 Index: net/core/netfilter.c =================================================================== --- 9544bb88b28c2e3ca4b0a66fedfa2bb540ec06e2/net/core/netfilter.c (mode:100644 sha1:92c51824797dd15018e579eb5753cc372e04fd3d) +++ 35d8915a3fd6fa39a46d9b2e8e1fd272e82ea3af/net/core/netfilter.c (mode:100644 sha1:22a8f127c4aad9821e5f3294aa518807165ee8b7) @@ -236,8 +236,6 @@ debug_print_hooks_ip(newskb->nf_debug); nf_dump_skb(PF_INET, newskb); } - /* Clear to avoid confusing input check */ - newskb->nf_debug = 0; } void nf_debug_ip_finish_output2(struct sk_buff *skb) Index: net/ipv4/ip_output.c =================================================================== --- 9544bb88b28c2e3ca4b0a66fedfa2bb540ec06e2/net/ipv4/ip_output.c (mode:100644 sha1:38f69532a029e5ff1ddbdbd665afcff46e94abb5) +++ 35d8915a3fd6fa39a46d9b2e8e1fd272e82ea3af/net/ipv4/ip_output.c (mode:100644 sha1:24fe3e00b42b0bb673be5a6d8ceb15defb192974) @@ -111,6 +111,7 @@ #ifdef CONFIG_NETFILTER_DEBUG nf_debug_ip_loopback_xmit(newskb); #endif + nf_reset(newskb); netif_rx(newskb); return 0; } --------------070605040806010003070303-- From Yair@arx.com Mon May 2 09:17:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 09:18:03 -0700 (PDT) Received: from post.arx.com (post.arx.com [212.25.66.95]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42GHv7J012325 for ; Mon, 2 May 2005 09:17:59 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Re-routing packets via netfilter (ip_rt_bug) Date: Mon, 2 May 2005 19:17:16 +0200 Message-ID: <4151C0F9B9C25C47B3328922A6297A3286CFB8@post.arx.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re-routing packets via netfilter (ip_rt_bug) Thread-Index: AcVLKiK78AJdzKpmRxyqorAryLrbSgD3ejng From: "Yair Itzhaki" To: "Patrick McHardy" , "Herbert Xu" Cc: "Jozsef Kadlecsik" , , , X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j42GHv7J012325 X-archive-position: 540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Yair@arx.com Precedence: bulk X-list: netdev Content-Length: 1952 Lines: 53 Can anyone propose a patch that I can start checking? I have come up with the following: --- net/core/netfilter.c.orig 2005-04-18 21:55:30.000000000 +0300 +++ net/core/netfilter.c 2005-05-02 17:35:20.000000000 +0300 @@ -622,9 +622,10 @@ /* some non-standard hacks like ipt_REJECT.c:send_reset() can cause * packets with foreign saddr to appear on the NF_IP_LOCAL_OUT hook. */ - if (inet_addr_type(iph->saddr) == RTN_LOCAL) { + if ((inet_addr_type(iph->saddr) == RTN_LOCAL) || + (inet_addr_type(iph->daddr) == RTN_LOCAL)) { fl.nl_u.ip4_u.daddr = iph->daddr; - fl.nl_u.ip4_u.saddr = iph->saddr; + fl.nl_u.ip4_u.saddr = 0; fl.nl_u.ip4_u.tos = RT_TOS(iph->tos); fl.oif = (*pskb)->sk ? (*pskb)->sk->sk_bound_dev_if : 0; #ifdef CONFIG_IP_ROUTE_FWMARK Please advise, Yair > -----Original Message----- > From: Patrick McHardy [mailto:kaber@trash.net] > Sent: Wednesday, April 27, 2005 14:05 > To: Herbert Xu > Cc: Jozsef Kadlecsik; netdev@oss.sgi.com; > netfilter-devel@lists.netfilter.org; Yair Itzhaki; > linux-kernel@vger.kernel.org > Subject: Re: Re-routing packets via netfilter (ip_rt_bug) > > > Herbert Xu wrote: > > Here is another reason why these packets should go through FORWARD. > > They were generated in response to packets in INPUT/FORWARD/OUTPUT. > > The original packet has not undergone SNAT in any of these cases. > > > > However, if we feed the response packet through LOCAL_OUT it will > > be subject to DNAT. This creates a NAT asymmetry and we may end > > up with the wrong destination address. > > > > By pushing it through FORWARD it will only undergo SNAT which is > > correct since the original packet would have undergone DNAT. > > This is only a problem since the recent NAT changes, but I agree > that we should fix it by moving these packets to FORWARD. > > Regards > Patrick > From hasso@estpak.ee Mon May 2 10:38:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 10:38:39 -0700 (PDT) Received: from arena.estpak.ee (dream.estpak.ee [194.126.115.147]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42Hca7J017603 for ; Mon, 2 May 2005 10:38:36 -0700 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.50) id 1DSesA-0000nG-MB; Mon, 02 May 2005 20:38:22 +0300 From: Hasso Tepper To: Patrick McHardy Subject: Re: icmp_unreachable uses wrong ip Date: Mon, 2 May 2005 20:38:21 +0300 User-Agent: KMail/1.8 Cc: "J. Simonetti" , netdev@oss.sgi.com References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505021659.05674.hasso@estpak.ee> <42763E96.1070209@trash.net> In-Reply-To: <42763E96.1070209@trash.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200505022038.22014.hasso@estpak.ee> X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j42Hca7J017603 X-archive-position: 547 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 910 Lines: 20 Patrick McHardy wrote: > Hasso Tepper wrote: > > Similar patches have been posted to the list repeatedly AFAIK with no > > any response from developers. Can someone enlighten us why? Is there > > something wrong with it? This is the feature people administrating > > routers would like to have. It makes debugging complicated topologies > > much easier and all routers I have seen behave this way. > > Why can't you simply add the prefered source address to the route? Because I don't know what it is. Router A knows what's the best path from router A to router B, but he can't know (at least in cases where there are more than 1 path between them) what's the best path from router B to router A. Therefore you canät say which one is incoming interface in router A for traffic from router B. And even if you know it in some moment, topology might change in next moment (dynamic routing) etc. -- Hasso From mkomu@twilight.cs.hut.fi Mon May 2 11:39:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 11:39:38 -0700 (PDT) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42IdX7J023127 for ; Mon, 2 May 2005 11:39:34 -0700 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 69F5E2E65; Mon, 2 May 2005 21:39:22 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id B77232DE8 for ; Mon, 2 May 2005 21:39:20 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j42IdKv27517; Mon, 2 May 2005 21:39:20 +0300 (EEST) Date: Mon, 2 May 2005 21:39:20 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: netdev@oss.sgi.com Subject: IPsec performance Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 550 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miika@iki.fi Precedence: bulk X-list: netdev Content-Length: 700 Lines: 21 Hi folks, I compared TCP-over-NULL-ESP vs. plain-TCP throughput with "ttcp" tool and obtained the following results: Plain-TCP: 11 megabytes/s NULL-ESP: 2.5 megabytes/s Am I doing something wrong? I did the measurements by transferring a 100 megabyte file using vanilla 2.6.7 kernel and IPv6. Seems like my results are inconsistent at least with measurements published by Linux Journal: http://www.linuxjournal.com/article/7840 The main differences with the Linux Journal measurements are that I used a significantly larger filesize and IPv6. So, I tried to run the same with IPv4 and got similar results... any ideas? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From mkomu@twilight.cs.hut.fi Mon May 2 12:09:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 12:09:29 -0700 (PDT) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42J9H7J024322 for ; Mon, 2 May 2005 12:09:17 -0700 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id EA58A2E68; Mon, 2 May 2005 22:09:03 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 4B3EB2DDA for ; Mon, 2 May 2005 22:09:02 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j42J92929691; Mon, 2 May 2005 22:09:02 +0300 (EEST) Date: Mon, 2 May 2005 22:09:02 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: netdev@oss.sgi.com Subject: Re: IPsec performance In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 551 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miika@iki.fi Precedence: bulk X-list: netdev Content-Length: 910 Lines: 29 On Mon, 2 May 2005, Miika Komu wrote: > Hi folks, > > I compared TCP-over-NULL-ESP vs. plain-TCP throughput with "ttcp" tool and > obtained the following results: > > Plain-TCP: 11 megabytes/s > NULL-ESP: 2.5 megabytes/s > > Am I doing something wrong? I did the measurements by transferring a 100 > megabyte file using vanilla 2.6.7 kernel and IPv6. Seems like my > results are inconsistent at least with measurements published by Linux > Journal: > > http://www.linuxjournal.com/article/7840 > > The main differences with the Linux Journal measurements are that I used a > significantly larger filesize and IPv6. So, I tried to run the same with > IPv4 and got similar results... any ideas? I browsed the archives also and found this one: http://oss.sgi.com/archives/netdev/2004-12/msg00801.html Nothing has been done for this? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From herbert@gondor.apana.org.au Mon May 2 14:29:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 14:29:16 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42LT77J006499 for ; Mon, 2 May 2005 14:29:09 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSiSo-0007xm-00; Tue, 03 May 2005 07:28:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSiSh-0004DD-00; Tue, 03 May 2005 07:28:19 +1000 Date: Tue, 3 May 2005 07:28:19 +1000 To: Mark Broadbent Cc: Sergey Vlasov , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock Message-ID: <20050502212819.GA16177@gondor.apana.org.au> References: <20050429093521.274adf9a.davem@davemloft.net> <20050429214336.04b40b3f.vsu@altlinux.ru> <4276238E.4060606@wetlettuce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4276238E.4060606@wetlettuce.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 562 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 615 Lines: 15 On Mon, May 02, 2005 at 01:56:46PM +0100, Mark Broadbent wrote: > > > If what you wrote above is really correct, this means that > > Documentation/DocBook/kernel-locking.sgml contains wrong information: > > See Documentation/spin-locking.txt line 137, this states that > spin_[un]lock() should not be used in IRQ handlers. Line 137 in my spin-locking.txt is a blank line :) Please quote the exact text. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon May 2 14:31:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 14:31:31 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42LVQ7J006778 for ; Mon, 2 May 2005 14:31:27 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSiVR-0007yH-00; Tue, 03 May 2005 07:31:09 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSiVQ-0004Dl-00; Tue, 03 May 2005 07:31:08 +1000 Date: Tue, 3 May 2005 07:31:08 +1000 To: Mark Broadbent Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock Message-ID: <20050502213108.GB16177@gondor.apana.org.au> References: <20050429093521.274adf9a.davem@davemloft.net> <20050429224931.GA18616@gondor.apana.org.au> <427623B8.8050107@wetlettuce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427623B8.8050107@wetlettuce.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 563 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1032 Lines: 25 On Mon, May 02, 2005 at 01:57:28PM +0100, Mark Broadbent wrote: > > > However, I don't see how this can happen. __do_IRQ ensures > > that the handlers on a single IRQ aren't reentered by desc->lock > > and desc->status. Softirqs are also kept out by irq_enter. Am > > I missing something? > > As far as I can see desc->lock is dropped before handle_IRQ_event() is > called in __do_IRQ() (kernel/irq/handle.c:170) and desc->status does not > prevent the execution of the IRQ handler. Same with softirqs, desc->status is set to IRQ_INPROGRESS (kernel/irq/handle.c:144) which prevents the same IRQ handlers from being invoked again (kernel/irq/handle.c:141). > interrupts are enabled when the handler is called (kernel/softirq.c:89). Soft IRQs do not run when we're in an IRQ handler (kernel/softirq.c:121). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon May 2 14:32:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 14:32:42 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42LWc7J007152 for ; Mon, 2 May 2005 14:32:39 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSiWb-0007yW-00; Tue, 03 May 2005 07:32:21 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSiWa-0004E7-00; Tue, 03 May 2005 07:32:20 +1000 Date: Tue, 3 May 2005 07:32:20 +1000 To: "David S. Miller" Cc: Mark Broadbent , netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock Message-ID: <20050502213220.GC16177@gondor.apana.org.au> References: <20050429093521.274adf9a.davem@davemloft.net> <20050429224931.GA18616@gondor.apana.org.au> <427623B8.8050107@wetlettuce.com> <20050502124358.7186447f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050502124358.7186447f.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 564 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 730 Lines: 18 On Mon, May 02, 2005 at 12:43:58PM -0700, David S. Miller wrote: > > Now, a seperate issue. If we wish to disable IRQs at all for another > reason (say to make the critical section not get interrupted by timers > or some other device's handler) than we must use _irqsave/_irqrestore > instead of _irq because there is no guarentee whether IRQs are disabled > upon entry to an IRQ handler or not. The SA_INTERRUPT behavior is not Agreed. However, AFAIK the tulip driver doesn't care about other interrupts. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon May 2 14:36:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 14:36:56 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42Lap7J008314 for ; Mon, 2 May 2005 14:36:52 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSiaN-00080a-00; Tue, 03 May 2005 07:36:15 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSiaK-0004En-00; Tue, 03 May 2005 07:36:12 +1000 Date: Tue, 3 May 2005 07:36:12 +1000 To: Patrick McHardy Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, Andrew Morton , "David S. Miller" Subject: Re: CONFIG_NETFILTER_DEBUG spew Message-ID: <20050502213612.GD16177@gondor.apana.org.au> References: <20050501032809.3d0b4cda.akpm@osdl.org> <20050501111507.GA2133@gondor.apana.org.au> <4276517F.6030606@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4276517F.6030606@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 565 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 479 Lines: 13 On Mon, May 02, 2005 at 06:12:47PM +0200, Patrick McHardy wrote: > Herbert Xu wrote: > > BTW, should we do nf_reset in ip_dev_loopback_xmit as well? > > I think we should, tc actions could do something unexpected with > the packet. Looks good to me. Thanks Patrick. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Mon May 2 14:43:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 14:43:58 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42Lhu7J009092 for ; Mon, 2 May 2005 14:43:56 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DSiWm-00018L-00; Mon, 02 May 2005 14:32:32 -0700 Date: Mon, 2 May 2005 14:32:32 -0700 From: "David S. Miller" To: Herbert Xu Cc: markb@wetlettuce.com, netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock Message-Id: <20050502143232.1dbec2d6.davem@davemloft.net> In-Reply-To: <20050502213220.GC16177@gondor.apana.org.au> References: <20050429093521.274adf9a.davem@davemloft.net> <20050429224931.GA18616@gondor.apana.org.au> <427623B8.8050107@wetlettuce.com> <20050502124358.7186447f.davem@davemloft.net> <20050502213220.GC16177@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 566 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 298 Lines: 9 On Tue, 3 May 2005 07:32:20 +1000 Herbert Xu wrote: > However, AFAIK the tulip driver doesn't care about other interrupts. Even the netdev watchdog? :-) tulip_tx_timeout takes the tp->lock. Therefore it seems that Mark's patch is correct _and_ needed, after all. From herbert@gondor.apana.org.au Mon May 2 14:46:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 14:46:12 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42Lk77J009572 for ; Mon, 2 May 2005 14:46:08 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSijc-0008GJ-00; Tue, 03 May 2005 07:45:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSijZ-0003VR-00; Tue, 03 May 2005 07:45:45 +1000 Date: Tue, 3 May 2005 07:45:45 +1000 To: "David S. Miller" Cc: markb@wetlettuce.com, netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock Message-ID: <20050502214545.GA13462@gondor.apana.org.au> References: <20050429093521.274adf9a.davem@davemloft.net> <20050429224931.GA18616@gondor.apana.org.au> <427623B8.8050107@wetlettuce.com> <20050502124358.7186447f.davem@davemloft.net> <20050502213220.GC16177@gondor.apana.org.au> <20050502143232.1dbec2d6.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050502143232.1dbec2d6.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/862/Mon May 2 05:24:27 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 567 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 563 Lines: 15 On Mon, May 02, 2005 at 02:32:32PM -0700, David S. Miller wrote: > On Tue, 3 May 2005 07:32:20 +1000 > Herbert Xu wrote: > > > However, AFAIK the tulip driver doesn't care about other interrupts. > > Even the netdev watchdog? :-) The watchdog runs in softirq context which is disabled while the IRQ handler is running. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Mon May 2 15:05:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 15:05:04 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42M507J010811 for ; Mon, 2 May 2005 15:05:00 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DSj20-0006fH-70; Tue, 03 May 2005 00:04:48 +0200 Message-ID: <4276A400.2050306@trash.net> Date: Tue, 03 May 2005 00:04:48 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Hasso Tepper CC: "J. Simonetti" , netdev@oss.sgi.com Subject: Re: icmp_unreachable uses wrong ip References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505021659.05674.hasso@estpak.ee> <42763E96.1070209@trash.net> <200505022038.22014.hasso@estpak.ee> In-Reply-To: <200505022038.22014.hasso@estpak.ee> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.83/863/Mon May 2 09:32:37 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 568 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 860 Lines: 19 Hasso Tepper wrote: > Patrick McHardy wrote: > >>Why can't you simply add the prefered source address to the route? > > Because I don't know what it is. Router A knows what's the best path from > router A to router B, but he can't know (at least in cases where there are > more than 1 path between them) what's the best path from router B to router > A. Therefore you canät say which one is incoming interface in router A for > traffic from router B. And even if you know it in some moment, topology > might change in next moment (dynamic routing) etc. Your patch can't guarantee that the address used is the same that was used as nexthop by the previous hop in the path when multiple addresses are configured on the incoming interface. So I don't think it achieves much of your goal of making debugging complicated topologies easier. Regards Patrick From shemminger@osdl.org Mon May 2 16:24:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 16:24:31 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j42NOK7J019388 for ; Mon, 2 May 2005 16:24:20 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j42NO4s4018814 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 May 2005 16:24:04 -0700 Received: from localhost.localdomain (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j42NO45m027059; Mon, 2 May 2005 16:24:04 -0700 Date: Mon, 2 May 2005 16:24:05 -0700 From: Stephen Hemminger To: "David S. Miller" , Jeff Garzik Cc: netdev@oss.sgi.com Subject: Mystery packet killing tg3 Message-ID: <20050502162405.65dfb4a9@localhost.localdomain> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-Virus-Scanned: ClamAV 0.83/864/Mon May 2 14:10:35 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 572 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 518 Lines: 11 While I was on vacation, OSDL did some networking changes that seems to aggravate some existing bug in the tg3 driver. Could be some VLAN related garbage, not sure. System is 2 CPU AMD64 and the tg3 is on the motherboard. I am seeing messages like: eth0: Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:60:53:08:18 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] tg3: tg3_stop_block timed out, ofs=4000 enable_bit=2 Any clues? From kaber@trash.net Mon May 2 17:55:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 17:55:32 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j430tR7J023626 for ; Mon, 2 May 2005 17:55:30 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DSlgy-0006zD-AD; Tue, 03 May 2005 02:55:16 +0200 Date: Tue, 3 May 2005 02:55:16 +0200 (CEST) From: Patrick McHardy X-X-Sender: kaber@kaber.coreworks.de To: Miika Komu cc: netdev@oss.sgi.com Subject: Re: IPsec performance In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 574 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 524 Lines: 18 On Mon, 2 May 2005, Miika Komu wrote: >> I compared TCP-over-NULL-ESP vs. plain-TCP throughput with "ttcp" tool and >> obtained the following results: >> >> Plain-TCP: 11 megabytes/s >> NULL-ESP: 2.5 megabytes/s >> > I browsed the archives also and found this one: > > http://oss.sgi.com/archives/netdev/2004-12/msg00801.html null encryption uses a block size of 1, which causes inefficent handling of the data. I'm unsure if some hack for this specific case is worth it since its only meant for testing. Regards Patrick From akepner@sgi.com Mon May 2 18:13:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 18:13:11 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j431D67J024487 for ; Mon, 2 May 2005 18:13:06 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j432tFOG007406 for ; Mon, 2 May 2005 19:55:15 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (SGI-8.12.5/8.12.10/SGI_generic_relay-1.2) with ESMTP id j431BtbT64893084 for ; Mon, 2 May 2005 18:11:55 -0700 (PDT) Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-189.corp.sgi.com [134.15.0.189]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j431As5x20790926; Mon, 2 May 2005 18:10:54 -0700 (PDT) Date: Mon, 2 May 2005 18:09:26 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: Leonid Grossman , muhammad.shafiq@neterion.com, ramkrishna.vepa@neterion.com cc: netdev@oss.sgi.com Subject: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() In-Reply-To: <200504051836.j35IanDD005402@guinness.s2io.com> Message-ID: References: <200504051836.j35IanDD005402@guinness.s2io.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 575 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 1170 Lines: 32 The neterion 10gige driver uses a readq() to flush some PIO writes in s2io_xmit(). Using mmiowb() can, in some cases, reduce CPU utilization, and/or allow higher throughput. This is particularly true when TSO is off, and small MTUs are in use. For example, in one test measurement I just did with 2.6.12-rc2 on an Altix, MTUs were set to 1500 bytes and TSO turned off. With this patch, transmit throughput improved by ~20%. Throughput was ultimately bound by the CPU with or without the patch. With large MTUs (9600 bytes) or with TSO turned on, there was no significant change to throughput or CPU utilization. Signed-off-by: Arthur Kepner --- linux.orig/drivers/net/s2io.c 2005-05-02 16:40:17.469733509 -0700 +++ linux/drivers/net/s2io.c 2005-05-02 16:40:25.001043632 -0700 @@ -2759,8 +2759,8 @@ static int s2io_xmit(struct sk_buff *skb #endif writeq(val64, &tx_fifo->List_Control); - /* Perform a PCI read to flush previous writes */ - val64 = readq(&bar0->general_int_status); + /* Perform a mmiowb() to order previous writes */ + mmiowb(); put_off++; put_off %= mac_control->tx_curr_put_info[queue].fifo_len + 1; -- Arthur From anton@ozlabs.org Mon May 2 18:44:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 18:44:41 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j431ic7J027026 for ; Mon, 2 May 2005 18:44:39 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 89280679FD; Tue, 3 May 2005 11:44:26 +1000 (EST) Date: Tue, 3 May 2005 11:40:34 +1000 From: Anton Blanchard To: Arthur Kepner Cc: Leonid Grossman , muhammad.shafiq@neterion.com, ramkrishna.vepa@neterion.com, netdev@oss.sgi.com Subject: Re: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() Message-ID: <20050503014034.GC12682@krispykreme> References: <200504051836.j35IanDD005402@guinness.s2io.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 576 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 1351 Lines: 38 Hi, > The neterion 10gige driver uses a readq() to flush some PIO writes > in s2io_xmit(). Using mmiowb() can, in some cases, reduce CPU > utilization, and/or allow higher throughput. This is particularly > true when TSO is off, and small MTUs are in use. > > For example, in one test measurement I just did with 2.6.12-rc2 > on an Altix, MTUs were set to 1500 bytes and TSO turned off. > With this patch, transmit throughput improved by ~20%. Throughput > was ultimately bound by the CPU with or without the patch. With > large MTUs (9600 bytes) or with TSO turned on, there was no > significant change to throughput or CPU utilization. I didnt know mmiowb is supposed to be a replacement for PCI write posting. Most architectures define mmiowb as nothing and so will be broken with your change. Anton > --- linux.orig/drivers/net/s2io.c 2005-05-02 16:40:17.469733509 -0700 > +++ linux/drivers/net/s2io.c 2005-05-02 16:40:25.001043632 -0700 > @@ -2759,8 +2759,8 @@ static int s2io_xmit(struct sk_buff *skb > #endif > writeq(val64, &tx_fifo->List_Control); > > - /* Perform a PCI read to flush previous writes */ > - val64 = readq(&bar0->general_int_status); > + /* Perform a mmiowb() to order previous writes */ > + mmiowb(); > > put_off++; > put_off %= mac_control->tx_curr_put_info[queue].fifo_len + 1; > > -- > Arthur > From akepner@sgi.com Mon May 2 19:15:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 19:15:37 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j432FX7J028435 for ; Mon, 2 May 2005 19:15:33 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j433vg9G019728 for ; Mon, 2 May 2005 20:57:42 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (SGI-8.12.5/8.12.10/SGI_generic_relay-1.2) with ESMTP id j432ELbT65806622 for ; Mon, 2 May 2005 19:14:21 -0700 (PDT) Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-189.corp.sgi.com [134.15.0.189]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j432DK5x20777765; Mon, 2 May 2005 19:13:21 -0700 (PDT) Date: Mon, 2 May 2005 19:11:53 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: Anton Blanchard cc: Leonid Grossman , muhammad.shafiq@neterion.com, ramkrishna.vepa@neterion.com, netdev@oss.sgi.com Subject: Re: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() In-Reply-To: <20050503014034.GC12682@krispykreme> Message-ID: References: <200504051836.j35IanDD005402@guinness.s2io.com> <20050503014034.GC12682@krispykreme> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 577 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 450 Lines: 16 On Tue, 3 May 2005, Anton Blanchard wrote: > > I didnt know mmiowb is supposed to be a replacement for PCI write > posting. Most architectures define mmiowb as nothing and so will be > broken with your change. > I thought that an arch was supposed to define mmiowb() if it needs it. In this case, the readq() is only being used for the side-effect of ordering the previous writes (the neterion folks can correct me if I'm wrong). -- Arthur From ram.vepa@neterion.com Mon May 2 19:58:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 19:58:58 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j432wu7J029752 for ; Mon, 2 May 2005 19:58:56 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j432whOC000493; Mon, 2 May 2005 22:58:43 -0400 (EDT) Received: from spiderman ([10.16.16.59]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j432wcVG027487; Mon, 2 May 2005 22:58:40 -0400 (EDT) From: "Ramkrishna Vepa" To: "'Arthur Kepner'" , "'Anton Blanchard'" Cc: "'Leonid Grossman'" , , , , "'Ravinandan Arakali'" Subject: RE: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() Date: Mon, 2 May 2005 19:58:38 -0700 Message-ID: <03d401c54f8c$03917fd0$5c10100a@pc.s2io.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Scanned-By: MIMEDefang 2.34 X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 578 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ram.vepa@neterion.com Precedence: bulk X-list: netdev Content-Length: 527 Lines: 16 > > I didnt know mmiowb is supposed to be a replacement for PCI write > > posting. Most architectures define mmiowb as nothing and so will be > > broken with your change. > > > > I thought that an arch was supposed to define mmiowb() if it needs > it. In this case, the readq() is only being used for the side-effect > of ordering the previous writes (the neterion folks can correct me > if I'm wrong). [Ram] Yes, it is to ensure ordering as well as the flush of the io that is required in some platforms. > > -- > Arthur From anton@ozlabs.org Mon May 2 20:05:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 20:05:52 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4335l7J030517 for ; Mon, 2 May 2005 20:05:48 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 4DF2E679FD; Tue, 3 May 2005 13:05:34 +1000 (EST) Date: Tue, 3 May 2005 13:05:15 +1000 From: Anton Blanchard To: Arthur Kepner Cc: Leonid Grossman , muhammad.shafiq@neterion.com, ramkrishna.vepa@neterion.com, netdev@oss.sgi.com Subject: Re: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() Message-ID: <20050503030515.GD12682@krispykreme> References: <200504051836.j35IanDD005402@guinness.s2io.com> <20050503014034.GC12682@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 579 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 1274 Lines: 29 Hi, > I thought that an arch was supposed to define mmiowb() if it needs > it. In this case, the readq() is only being used for the side-effect > of ordering the previous writes (the neterion folks can correct me > if I'm wrong). The documentation suggests mmiowb does not do write posting: In addition to write posting, on some large multiprocessing systems (e.g. SGI Challenge, Origin and Altix machines) posted writes won't be strongly ordered coming from different CPUs. Thus it's important to properly protect parts of your driver that do memory-mapped writes with locks and use the mmiowb to make sure they arrive in the order intended. Issuing a regular readX will also ensure write ordering, but should only be used when the driver has to be sure that the write has actually arrived at the device (not that it's simply ordered with respect to other writes), since a full readX is a relatively expensive operation. So if we require the write to be posted we will need the read. If however we only need to order wrt subsequent IO writes then I agree mmiowb can be used. Anton From anton@ozlabs.org Mon May 2 20:10:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 20:10:51 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j433Am7J031153 for ; Mon, 2 May 2005 20:10:49 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id 4DC8E679FD; Tue, 3 May 2005 13:10:37 +1000 (EST) Date: Tue, 3 May 2005 13:06:20 +1000 From: Anton Blanchard To: Ramkrishna Vepa Cc: "'Arthur Kepner'" , "'Leonid Grossman'" , muhammad.shafiq@neterion.com, ramkrishna.vepa@neterion.com, netdev@oss.sgi.com, "'Ravinandan Arakali'" Subject: Re: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() Message-ID: <20050503030620.GE12682@krispykreme> References: <03d401c54f8c$03917fd0$5c10100a@pc.s2io.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03d401c54f8c$03917fd0$5c10100a@pc.s2io.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 580 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 190 Lines: 7 > [Ram] Yes, it is to ensure ordering as well as the flush of the io that is > required in some platforms. If the flush of the IO is required I cant see how we can remove the read. Anton From davem@davemloft.net Mon May 2 20:13:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 20:13:55 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j433Dq7J031739 for ; Mon, 2 May 2005 20:13:52 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DSngR-0003NL-00; Mon, 02 May 2005 20:02:51 -0700 Date: Mon, 2 May 2005 20:02:51 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-Id: <20050502200251.38271b61.davem@davemloft.net> In-Reply-To: <20050502162405.65dfb4a9@localhost.localdomain> References: <20050502162405.65dfb4a9@localhost.localdomain> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 581 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1396 Lines: 34 On Mon, 2 May 2005 16:24:05 -0700 Stephen Hemminger wrote: > While I was on vacation, OSDL did some networking changes that seems to aggravate some > existing bug in the tg3 driver. Could be some VLAN related garbage, not sure. > > System is 2 CPU AMD64 and the tg3 is on the motherboard. > > I am seeing messages like: > eth0: Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:60:53:08:18 > eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] > tg3: tg3_stop_block timed out, ofs=4000 enable_bit=2 > > Any clues? This usually means that there is some DMA corruption. For example, some bug in the x86_64 IOMMU code or similar causes a bogus DMA address to be fed to the tg3 or even worse a DMA mapping is unmapped before tg3 is actually done with it. Please try to get some more debugging. One thing that might be useful would be a dump of the PCI config and PCI status registers from PCI config space when that tg3_stop_block event triggers. It will tell us if there was a master or slave abort on the PCI bus which would confirm my above theory. Also what PCI controller is in this box? (ie. the north bridge, lspci -v would tell) Since AMD promised me an Opteron system last year, but never made good on that promise, I've never been able to work on fixing this bug myself. :-/ From mkomu@twilight.cs.hut.fi Mon May 2 22:25:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 22:25:33 -0700 (PDT) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j435PT7J007334 for ; Mon, 2 May 2005 22:25:29 -0700 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 7C6E42F33; Tue, 3 May 2005 08:25:17 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 949C72F2C; Tue, 3 May 2005 08:25:15 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j435PFv25258; Tue, 3 May 2005 08:25:15 +0300 (EEST) Date: Tue, 3 May 2005 08:25:15 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Patrick McHardy Cc: netdev@oss.sgi.com Subject: Re: IPsec performance In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 582 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miika@iki.fi Precedence: bulk X-list: netdev Content-Length: 750 Lines: 23 On Tue, 3 May 2005, Patrick McHardy wrote: > On Mon, 2 May 2005, Miika Komu wrote: > >> I compared TCP-over-NULL-ESP vs. plain-TCP throughput with "ttcp" tool and > >> obtained the following results: > >> > >> Plain-TCP: 11 megabytes/s > >> NULL-ESP: 2.5 megabytes/s > >> > > I browsed the archives also and found this one: > > > > http://oss.sgi.com/archives/netdev/2004-12/msg00801.html > > null encryption uses a block size of 1, which causes inefficent handling > of the data. I'm unsure if some hack for this specific case is worth it > since its only meant for testing. Thanks for your response. However, this does explain why I got only 1.9 megabytes/s with 3DES. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From dave@thedillows.org Mon May 2 22:54:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 22:54:28 -0700 (PDT) Received: from smtp.knology.net (smtp.knology.net [24.214.63.101]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j435sQ7J008260 for ; Mon, 2 May 2005 22:54:26 -0700 Received: (qmail 28565 invoked by uid 0); 3 May 2005 05:54:14 -0000 Received: from user-24-96-111-205.knology.net (HELO ori.thedillows.org) (24.96.111.205) by smtp2.knology.net with SMTP; 3 May 2005 05:54:14 -0000 Received: from ori.thedillows.org (localhost [127.0.0.1]) by ori.thedillows.org (8.13.1/8.13.1) with ESMTP id j435sdZK003765; Tue, 3 May 2005 01:54:39 -0400 Received: (from il1@localhost) by ori.thedillows.org (8.13.1/8.13.1/Submit) id j435sdvC003764; Tue, 3 May 2005 01:54:39 -0400 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: Re: IPsec performance From: Dave Dillow To: Miika Komu Cc: Patrick McHardy , Netdev In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 03 May 2005 01:54:38 -0400 Message-Id: <1115099678.2953.3.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 583 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev Content-Length: 331 Lines: 10 On Tue, 2005-05-03 at 08:25 +0300, Miika Komu wrote: > However, this does explain why I got only 1.9 megabytes/s with 3DES. What was your hardware? Without knowing what you're running on, it's impossible to tell if that is good or bad. Linux Journal was getting ~5.5MB/s on a PIV 2.2GHz. I get ~2.1MB/s on a 550MHz Athlon. Dave From mkomu@twilight.cs.hut.fi Mon May 2 23:44:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 23:44:42 -0700 (PDT) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j436ib7J009893 for ; Mon, 2 May 2005 23:44:37 -0700 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id AE78C2F57; Tue, 3 May 2005 09:44:25 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 12B232F4F; Tue, 3 May 2005 09:44:25 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j436iO700370; Tue, 3 May 2005 09:44:24 +0300 (EEST) Date: Tue, 3 May 2005 09:44:24 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Dave Dillow Cc: Patrick McHardy , Netdev Subject: Re: IPsec performance In-Reply-To: <1115099678.2953.3.camel@ori.thedillows.org> Message-ID: References: <1115099678.2953.3.camel@ori.thedillows.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miika@iki.fi Precedence: bulk X-list: netdev Content-Length: 482 Lines: 15 On Tue, 3 May 2005, Dave Dillow wrote: > On Tue, 2005-05-03 at 08:25 +0300, Miika Komu wrote: > > However, this does explain why I got only 1.9 megabytes/s with 3DES. > > What was your hardware? Without knowing what you're running on, it's > impossible to tell if that is good or bad. > > Linux Journal was getting ~5.5MB/s on a PIV 2.2GHz. > I get ~2.1MB/s on a 550MHz Athlon. Intel Pentium III 500 MHz -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From hasso@estpak.ee Mon May 2 23:45:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 May 2005 23:45:11 -0700 (PDT) Received: from arena.estpak.ee (test.estpak.ee [194.126.115.47]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j436j67J009932 for ; Mon, 2 May 2005 23:45:06 -0700 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.50) id 1DSr9F-0000pm-Qz; Tue, 03 May 2005 09:44:49 +0300 From: Hasso Tepper To: Patrick McHardy Subject: Re: icmp_unreachable uses wrong ip Date: Tue, 3 May 2005 09:44:48 +0300 User-Agent: KMail/1.8 Cc: "J. Simonetti" , netdev@oss.sgi.com References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505022038.22014.hasso@estpak.ee> <4276A400.2050306@trash.net> In-Reply-To: <4276A400.2050306@trash.net> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200505030944.49175.hasso@estpak.ee> X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j436j67J009932 X-archive-position: 585 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 1270 Lines: 33 Patrick McHardy wrote: > Hasso Tepper wrote: > > Patrick McHardy wrote: > >>Why can't you simply add the prefered source address to the route? > > > > Because I don't know what it is. Router A knows what's the best path > > from router A to router B, but he can't know (at least in cases where > > there are more than 1 path between them) what's the best path from > > router B to router A. Therefore you canät say which one is incoming > > interface in router A for traffic from router B. And even if you know > > it in some moment, topology might change in next moment (dynamic > > routing) etc. > > Your patch can't guarantee that the address used is the same that was > used as nexthop by the previous hop in the path when multiple addresses > are configured on the incoming interface. So I don't think it achieves > much of your goal of making debugging complicated topologies easier. At first I don't care what was used as nexthop. I want to know which physical link was used. Having multiple addresses in the same link is more corner case in core network anyway. And can you explain what theoretical possibilities router has to obtain info what address was used as nexthop by neighbour? regards, -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From herbert@gondor.apana.org.au Tue May 3 02:08:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 02:08:52 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4398j7J019785 for ; Tue, 3 May 2005 02:08:46 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DStNp-0004Kq-00; Tue, 03 May 2005 19:08:01 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DStNl-0007gO-00; Tue, 03 May 2005 19:07:57 +1000 Date: Tue, 3 May 2005 19:07:57 +1000 To: Mark Broadbent Cc: vsu@altlinux.ru, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock Message-ID: <20050503090757.GA29509@gondor.apana.org.au> References: <20050429093521.274adf9a.davem@davemloft.net> <20050429214336.04b40b3f.vsu@altlinux.ru> <4276238E.4060606@wetlettuce.com> <20050502212819.GA16177@gondor.apana.org.au> <57556.192.102.214.6.1115108726.squirrel@webmail.wetlettuce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57556.192.102.214.6.1115108726.squirrel@webmail.wetlettuce.com> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 587 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1112 Lines: 31 On Tue, May 03, 2005 at 09:25:26AM +0100, Mark Broadbent wrote: > > >> See Documentation/spin-locking.txt line 137, this states that > >> spin_[un]lock() should not be used in IRQ handlers. > > "If you have a case where you have to protect a data structure across > several CPU's and you want to use spinlocks you can potentially use > cheaper versions of the spinlocks. IFF you know that the spinlocks are > never used in interrupt handlers, you can use the non-irq versions: > > spin_lock(&lock); > ... > spin_unlock(&lock); > " Yes this isn't very clear. What it's trying to say that if you're in a softirq/user context and the spin lock may be taken in an IRQ context elsewhere then you must use the IRQ-disabling version. However, if you're in the IRQ context yourself, and yours is the only IRQ context that takes that spin lock, then you may use the straight spin_lock version. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From buytenh@wantstofly.org Tue May 3 02:23:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 02:23:04 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j439N07J020539 for ; Tue, 3 May 2005 02:23:01 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id 8D6D92B0EC; Tue, 3 May 2005 11:22:44 +0200 (MEST) Date: Tue, 3 May 2005 11:22:44 +0200 From: Lennert Buytenhek To: netdev@oss.sgi.com Cc: "J. Simonetti" Subject: Re: icmp_unreachable uses wrong ip Message-ID: <20050503092244.GA8864@xi.wantstofly.org> References: <1115040079.5620.11.camel@jeroens.office.netland.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115040079.5620.11.camel@jeroens.office.netland.nl> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 588 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 814 Lines: 20 On Mon, May 02, 2005 at 03:21:19PM +0200, J. Simonetti wrote: > I've recently come to notice that traceroutes through a linux router use > the wrong ip (ip of exitting interface) wich should actually be the ip > of the incomming interface. > > I've found a trivial patch (attached) wich resolves this. Perhaps this > is something to include (or have a sysctl to toggle this behaviour). I > unfortunately have no knowledge of programming, so the sysctl option > would have te be done by a volunteer. For what it's worth, I would love to see something like this in. In the presence of asymmetric routing, the way linux routers show up on traceroutes has always been slightly confusing to me. (I know, "Every other router vendor out there does it this way." is not a good reason for doing it the same way.) --L From pekkas@netcore.fi Tue May 3 02:42:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 02:42:24 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j439gJ7J021505 for ; Tue, 3 May 2005 02:42:20 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j439g1x03254; Tue, 3 May 2005 12:42:01 +0300 Date: Tue, 3 May 2005 12:42:01 +0300 (EEST) From: Pekka Savola To: Lennert Buytenhek cc: netdev@oss.sgi.com, "J. Simonetti" Subject: Re: icmp_unreachable uses wrong ip In-Reply-To: <20050503092244.GA8864@xi.wantstofly.org> Message-ID: References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <20050503092244.GA8864@xi.wantstofly.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 589 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 680 Lines: 16 On Tue, 3 May 2005, Lennert Buytenhek wrote: > (I know, "Every other router vendor out there does it this way." > is not a good reason for doing it the same way.) There's no specification requiring or recommending either of these approaches, either for v6 or v4 AFAICS so you can't depend on that behaviour.. Do you have specific data to back up "every other router vendor..." ? I doubt it's quite as uniform as that, but if so, it would certainly be a major motivation for a change. -- 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 herbert@gondor.apana.org.au Tue May 3 02:53:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 02:53:44 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j439rd7J022317 for ; Tue, 3 May 2005 02:53:40 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSu5e-0004Y4-00; Tue, 03 May 2005 19:53:18 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSu5Y-0007kn-00; Tue, 03 May 2005 19:53:12 +1000 Date: Tue, 3 May 2005 19:53:12 +1000 To: Evgeniy Polyakov Cc: netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" , Jamal Hadi Salim Subject: Re: [patch/RFC]: Asynchronous IPsec processing. Message-ID: <20050503095312.GA29788@gondor.apana.org.au> References: <20050429144103.A23268@2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050429144103.A23268@2ka.mipt.ru> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 912 Lines: 21 On Fri, Apr 29, 2005 at 02:41:03PM +0400, Evgeniy Polyakov wrote: > > I've created POC code to perform asynchronous IPsec [ESP] > processing. Please comment about bugs in the following patch. > It of course very dirty - but it is only begining, > I just want to know if approach is right. > Patch was tested with several ssh session and some > traffic like find / and tcpdump over them. IMHO we should ensure that the async code path does not adversely impact synchronous crypto performance. Most users will be using synchronous crypto primitives. Synchronous crypto is also the best way to utilise VIA Padlock which is arguably the best hardware crypto solution that's available today. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Tue May 3 03:03:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 03:03:36 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43A3U7J023045 for ; Tue, 3 May 2005 03:03:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSuFA-0004dO-00; Tue, 03 May 2005 20:03:08 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSuF8-0007li-00; Tue, 03 May 2005 20:03:06 +1000 Date: Tue, 3 May 2005 20:03:06 +1000 To: Tommy Christensen Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) Message-ID: <20050503100306.GB29788@gondor.apana.org.au> References: <4276B13F.2040103@tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4276B13F.2040103@tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1820 Lines: 56 Hi Tommy: On Tue, May 03, 2005 at 01:01:19AM +0200, Tommy Christensen wrote: > Some network drivers call netif_stop_queue() when detecting loss of > carrier. This leads to packets being queued up at the qdisc level for > an unbound period of time. In order to prevent this effect, the core > networking stack will now seize to queue packets for any device, that > is operationally down (i.e. the queue is flushed and disabled). This looks great. > @@ -552,15 +560,18 @@ > { > struct Qdisc *qdisc; > > - spin_lock_bh(&dev->queue_lock); > - qdisc = dev->qdisc; > - dev->qdisc = &noop_qdisc; > + if (dev->flags & IFF_RUNNING) { > + spin_lock_bh(&dev->queue_lock); > + qdisc = dev->qdisc; > + dev->qdisc = &noop_qdisc; > > - qdisc_reset(qdisc); > + qdisc_reset(qdisc); > > - spin_unlock_bh(&dev->queue_lock); > + spin_unlock_bh(&dev->queue_lock); > > - dev_watchdog_down(dev); > + dev_watchdog_down(dev); > + } > + dev->flags &= ~IFF_RUNNING; > > while (test_bit(__LINK_STATE_SCHED, &dev->state)) > yield(); Doing the wait when IFF_RUNNING is off isn't necessary though. If IFF_RUNNING isn't set, then either the device has never been activated or we've already carried out those waits the last time we were in dev_deactivate. I understand your preference for defensive programming. However, in cases like this it's better to do the obvious thing because: 1) We don't cover up bugs that may come back to bite us elsewhere. 2) We don't give people misconceptions. If they're unfamiliar with the system they may infer things from this code that aren't necessarily the case. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From johnpol@2ka.mipt.ru Tue May 3 03:11:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 03:11:22 -0700 (PDT) Received: from vocord.com (user-edvans3.msk.internet2.ru [217.25.93.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43ABI7J023727 for ; Tue, 3 May 2005 03:11:19 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j43AAamt022873; Tue, 3 May 2005 14:10:37 +0400 Subject: Re: [patch/RFC]: Asynchronous IPsec processing. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Herbert Xu Cc: netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" , Jamal Hadi Salim In-Reply-To: <20050503095312.GA29788@gondor.apana.org.au> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cJaM2D1YZkDdvae0Sc3H" Organization: MIPT Date: Tue, 03 May 2005 14:18:22 +0400 Message-Id: <1115115502.3414.22.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/852/Mon Apr 25 19:12:46 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Tue, 03 May 2005 14:10:40 +0400 (MSD) X-archive-position: 592 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1717 Lines: 49 --=-cJaM2D1YZkDdvae0Sc3H Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-05-03 at 19:53 +1000, Herbert Xu wrote: > On Fri, Apr 29, 2005 at 02:41:03PM +0400, Evgeniy Polyakov wrote: > >=20 > > I've created POC code to perform asynchronous IPsec [ESP] > > processing. Please comment about bugs in the following patch. > > It of course very dirty - but it is only begining,=20 > > I just want to know if approach is right. > > Patch was tested with several ssh session and some=20 > > traffic like find / and tcpdump over them. >=20 > IMHO we should ensure that the async code path does not adversely > impact synchronous crypto performance. Most users will be using > synchronous crypto primitives. Synchronous crypto is also the best > way to utilise VIA Padlock which is arguably the best hardware crypto > solution that's available today. It can be compile option - those people who wants asynchronous crypto processing and has appropriate hardware will benefit from that even if theirs general purpose CPU is VIA with PadLock ACE. It looks like several CPUs can not be used for synchronous crypto processing in current IPsec implementation. Using asynchronous mode there might be significant performance win. > Cheers, --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-cJaM2D1YZkDdvae0Sc3H Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCd0/uIKTPhE+8wY0RAh7xAJ4nA4frpuNJdlP59SNY7U9nsxXkRwCcDlFJ BZlFh0eFWlwEIevbQHdhnuQ= =MkCS -----END PGP SIGNATURE----- --=-cJaM2D1YZkDdvae0Sc3H-- From herbert@gondor.apana.org.au Tue May 3 03:15:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 03:15:44 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43AFT7J024599 for ; Tue, 3 May 2005 03:15:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSuQV-0004j3-00; Tue, 03 May 2005 20:14:51 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSuQR-0007nh-00; Tue, 03 May 2005 20:14:47 +1000 Date: Tue, 3 May 2005 20:14:47 +1000 To: Evgeniy Polyakov Cc: netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" , Jamal Hadi Salim Subject: Re: [patch/RFC]: Asynchronous IPsec processing. Message-ID: <20050503101447.GA29973@gondor.apana.org.au> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115115502.3414.22.camel@uganda> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 593 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 938 Lines: 24 On Tue, May 03, 2005 at 02:18:22PM +0400, Evgeniy Polyakov wrote: > > It can be compile option - those people who wants asynchronous crypto > processing and has appropriate hardware will benefit from that even > if theirs general purpose CPU is VIA with PadLock ACE. Well if there were no better options then we'll have to do that. However, I believe that with the right crypto API we should be able to have async crypto support without sacrificing synchronous performance. > It looks like several CPUs can not be used for synchronous crypto > processing in current IPsec implementation. Using asynchronous That's just an implementation quirk. I will be addressing that soon as part of the xfrm locking clean-up. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From johnpol@2ka.mipt.ru Tue May 3 03:24:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 03:24:29 -0700 (PDT) Received: from vocord.com (user-edvans3.msk.internet2.ru [217.25.93.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43AOP7J025249 for ; Tue, 3 May 2005 03:24:26 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j43ANnMl023895; Tue, 3 May 2005 14:23:49 +0400 Subject: Re: [patch/RFC]: Asynchronous IPsec processing. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Herbert Xu Cc: netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" , Jamal Hadi Salim In-Reply-To: <20050503101447.GA29973@gondor.apana.org.au> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> <20050503101447.GA29973@gondor.apana.org.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-wUR+YD3lwNiIhhyNElti" Organization: MIPT Date: Tue, 03 May 2005 14:31:35 +0400 Message-Id: <1115116295.3414.30.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/852/Mon Apr 25 19:12:46 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Tue, 03 May 2005 14:23:50 +0400 (MSD) X-archive-position: 594 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 1928 Lines: 58 --=-wUR+YD3lwNiIhhyNElti Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-05-03 at 20:14 +1000, Herbert Xu wrote: > On Tue, May 03, 2005 at 02:18:22PM +0400, Evgeniy Polyakov wrote: > >=20 > > It can be compile option - those people who wants asynchronous crypto > > processing and has appropriate hardware will benefit from that even > > if theirs general purpose CPU is VIA with PadLock ACE. >=20 > Well if there were no better options then we'll have to do that. >=20 > However, I believe that with the right crypto API we should be > able to have async crypto support without sacrificing synchronous > performance. Asynchronous processing will not hurt synchronous pathes in any way. But in some places we can use async api easily - like block devices encryption, but for others - like IPsec, there is no ability to split packet processing and thus even use async api. How carefully asynchronous API would be created current IPsec code just can not use it. > > It looks like several CPUs can not be used for synchronous crypto > > processing in current IPsec implementation. Using asynchronous >=20 > That's just an implementation quirk. I will be addressing that > soon as part of the xfrm locking clean-up. That is not enough, as far as I can see, since only one tfm is used for one transformer state. Locking changes will allow parallel processing of AH and ESP for example, but not two packets from the same flow. > Cheers, --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-wUR+YD3lwNiIhhyNElti Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCd1MHIKTPhE+8wY0RAvHyAJ97hDiRUjMPNB7sg2i2sSWKre7O+gCeK99w TahkxWsV6D4GpBuiZbgGn2o= =sN5I -----END PGP SIGNATURE----- --=-wUR+YD3lwNiIhhyNElti-- From herbert@gondor.apana.org.au Tue May 3 03:29:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 03:29:58 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43ATp7J025856 for ; Tue, 3 May 2005 03:29:52 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSuek-0004mo-00; Tue, 03 May 2005 20:29:34 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSuef-0007pr-00; Tue, 03 May 2005 20:29:29 +1000 Date: Tue, 3 May 2005 20:29:29 +1000 To: Evgeniy Polyakov Cc: netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" , Jamal Hadi Salim Subject: Re: [patch/RFC]: Asynchronous IPsec processing. Message-ID: <20050503102929.GA30097@gondor.apana.org.au> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> <20050503101447.GA29973@gondor.apana.org.au> <1115116295.3414.30.camel@uganda> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115116295.3414.30.camel@uganda> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 595 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 456 Lines: 11 On Tue, May 03, 2005 at 02:31:35PM +0400, Evgeniy Polyakov wrote: > > Asynchronous processing will not hurt synchronous pathes in any way. It will if you force everybody to go through the asynchronous path because you're jacking up the latency. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From buytenh@wantstofly.org Tue May 3 03:38:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 03:38:27 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43AcP7J027137 for ; Tue, 3 May 2005 03:38:25 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id 7D7C02B0EC; Tue, 3 May 2005 12:38:06 +0200 (MEST) Date: Tue, 3 May 2005 12:38:06 +0200 From: Lennert Buytenhek To: Pekka Savola Cc: netdev@oss.sgi.com, "J. Simonetti" Subject: Re: icmp_unreachable uses wrong ip Message-ID: <20050503103806.GB8864@xi.wantstofly.org> References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <20050503092244.GA8864@xi.wantstofly.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 597 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 1302 Lines: 34 On Tue, May 03, 2005 at 12:42:01PM +0300, Pekka Savola wrote: > >(I know, "Every other router vendor out there does it this way." > >is not a good reason for doing it the same way.) > > There's no specification requiring or recommending either of these > approaches, either for v6 or v4 AFAICS so you can't depend on that > behaviour.. > > Do you have specific data to back up "every other router vendor..." ? Sorry, I wasn't claiming that every other router vendor out there does it that way, just merely trying to state that that would not be a good argument. The ones I've worked with in the past do, and I just did some simple tests (doing traceroute from a foreign IP in a different network and looking at the ICMP time-exceededs arriving at that foreign IP) to confirm that: - Juniper M5 and M20 both running JUNOS 7.0R2.7 - Cisco 7206VXR and 12k(unsure which model) running unknown IOS versions - Foundry FastIron 3 (the 15-slot chassis) running BIR06636.bin do all behave opposite of the linux way, i.e. sending ICMPs with (one of) the source address(es) of the interface where the original packet (that we're sending an ICMP for) came in. I did also find one router that behaves the linux way: - Foundry TurboIron/8 running 07.800A Any other vendors that we're interested in? --L From johnpol@2ka.mipt.ru Tue May 3 03:48:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 03:48:36 -0700 (PDT) Received: from vocord.com (user-edvans3.msk.internet2.ru [217.25.93.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43AmQ7J027885 for ; Tue, 3 May 2005 03:48:28 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j43AlgDX025163; Tue, 3 May 2005 14:47:42 +0400 Subject: Re: [patch/RFC]: Asynchronous IPsec processing. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Herbert Xu Cc: netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" , Jamal Hadi Salim In-Reply-To: <20050503102929.GA30097@gondor.apana.org.au> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> <20050503101447.GA29973@gondor.apana.org.au> <1115116295.3414.30.camel@uganda> <20050503102929.GA30097@gondor.apana.org.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-k9PHOwYCs5KMRHWF2+qk" Organization: MIPT Date: Tue, 03 May 2005 14:55:28 +0400 Message-Id: <1115117728.3414.48.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Scanned: ClamAV 0.80/852/Mon Apr 25 19:12:46 2005 clamav-milter version 0.80j on dea.vocord.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Tue, 03 May 2005 14:47:43 +0400 (MSD) X-archive-position: 598 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 2099 Lines: 66 --=-k9PHOwYCs5KMRHWF2+qk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-05-03 at 20:29 +1000, Herbert Xu wrote: > On Tue, May 03, 2005 at 02:31:35PM +0400, Evgeniy Polyakov wrote: > > > > Asynchronous processing will not hurt synchronous pathes in any way. >=20 > It will if you force everybody to go through the asynchronous path > because you're jacking up the latency. But if it will not be selected - IPsec users will not be affected. Using asynchronous crypto processing of course has it's own nitpics, and although it's value was prooven [1] to be unsignificant, it is still=20 there. Current IPsec processing [even if it is UP only] has very strong model which always gets the maximum only from synchronous crypto. If people select asynchronous IPsec processing - they will use=20 _asynchronous_ IPsec processing, and no _synchronous_ pathes will be=20 affected. Using asynchronous IPsec processing is only usefull with asynchronous crypto layers, so no need to turn it on if none could be used with hardware. Btw, current crypto schema by design is SMP unfriendly - there is only low-level TFM entity, which=20 1. must be recreated for several CPUs 2. caller must know about how many CPUs are, which TFM to use and so on. Asynchronous crypto layers allow to hide it using proper API. I doubt there will be any benfit for existing IPsec schema from several CPUs without either some crypto processing rewrite (either by using per-cpu xfrm states or using several tfms per transformer), or without using some asynchronous crypto processing schema... [1] http://www.openbsd.org/papers/ocf.pdf --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-k9PHOwYCs5KMRHWF2+qk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCd1igIKTPhE+8wY0RAreZAJ0UMQ91mhs1Elzjm/pOowLPpTM1KACeMRzi hzOPWkUIC40JQeseFr15c/k= =ArHw -----END PGP SIGNATURE----- --=-k9PHOwYCs5KMRHWF2+qk-- From hasso@estpak.ee Tue May 3 04:01:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 04:01:23 -0700 (PDT) Received: from arena.estpak.ee (test.estpak.ee [194.126.115.47]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43B1K7J028785 for ; Tue, 3 May 2005 04:01:21 -0700 Received: from [127.0.0.1] (helo=arena) by arena.estpak.ee with esmtp (Exim 4.50) id 1DSv9E-0005kS-Uq; Tue, 03 May 2005 14:01:04 +0300 From: Hasso Tepper To: Lennert Buytenhek Subject: Re: icmp_unreachable uses wrong ip Date: Tue, 3 May 2005 14:00:47 +0300 User-Agent: KMail/1.8 Cc: Pekka Savola , netdev@oss.sgi.com, "J. Simonetti" References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <20050503103806.GB8864@xi.wantstofly.org> In-Reply-To: <20050503103806.GB8864@xi.wantstofly.org> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505031400.48287.hasso@estpak.ee> X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 599 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 887 Lines: 24 Lennert Buytenhek wrote: > The ones I've worked with in the past do, and I just did some > simple tests (doing traceroute from a foreign IP in a different > network and looking at the ICMP time-exceededs arriving at that > foreign IP) to confirm that: > - Juniper M5 and M20 both running JUNOS 7.0R2.7 > - Cisco 7206VXR and 12k(unsure which model) running unknown IOS versions I haven't seen JUNOS or IOS versions behave differently. > - Foundry FastIron 3 (the 15-slot chassis) running BIR06636.bin I can add to it (probably all) Extreme Networks line. Tested with both software lines - Summit 24e3 and Inferno (Black Diamond 6808). > do all behave opposite of the linux way, i.e. sending ICMPs with (one > of) the source address(es) of the interface where the original packet > (that we're sending an ICMP for) came in. -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From tgraf@suug.ch Tue May 3 04:18:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 04:18:43 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43BId7J030157 for ; Tue, 3 May 2005 04:18:39 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 1C42D1C0EB; Tue, 3 May 2005 13:18:44 +0200 (CEST) Date: Tue, 3 May 2005 13:18:44 +0200 From: Thomas Graf To: Herbert Xu Cc: Tommy Christensen , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) Message-ID: <20050503111844.GP577@postel.suug.ch> References: <4276B13F.2040103@tpack.net> <20050503100306.GB29788@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503100306.GB29788@gondor.apana.org.au> X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 600 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1736 Lines: 47 * Herbert Xu <20050503100306.GB29788@gondor.apana.org.au> 2005-05-03 20:03 > On Tue, May 03, 2005 at 01:01:19AM +0200, Tommy Christensen wrote: > > Some network drivers call netif_stop_queue() when detecting loss of > > carrier. This leads to packets being queued up at the qdisc level for > > an unbound period of time. In order to prevent this effect, the core > > networking stack will now seize to queue packets for any device, that > > is operationally down (i.e. the queue is flushed and disabled). > > This looks great. > > > @@ -552,15 +560,18 @@ > > { > > struct Qdisc *qdisc; > > > > - spin_lock_bh(&dev->queue_lock); > > - qdisc = dev->qdisc; > > - dev->qdisc = &noop_qdisc; > > + if (dev->flags & IFF_RUNNING) { > > + spin_lock_bh(&dev->queue_lock); > > + qdisc = dev->qdisc; > > + dev->qdisc = &noop_qdisc; > > > > - qdisc_reset(qdisc); > > + qdisc_reset(qdisc); > > > > - spin_unlock_bh(&dev->queue_lock); > > + spin_unlock_bh(&dev->queue_lock); > > > > - dev_watchdog_down(dev); > > + dev_watchdog_down(dev); > > + } > > + dev->flags &= ~IFF_RUNNING; > > > > while (test_bit(__LINK_STATE_SCHED, &dev->state)) > > yield(); > > Doing the wait when IFF_RUNNING is off isn't necessary though. If > IFF_RUNNING isn't set, then either the device has never been activated > or we've already carried out those waits the last time we were in > dev_deactivate. I do like the patch, no question but IFF_RUNNING is still abused by drivers and some subsystems. So I'm not sure how reliable the above code will be without those cases fixed. I submitted a patchset once to fix some of them, not sure about the status. Also, what about those drivers that do not support or do not use netif_carrier_(on|off)? From herbert@gondor.apana.org.au Tue May 3 04:23:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 04:23:44 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43BNd7J001698 for ; Tue, 3 May 2005 04:23:40 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DSvUf-00054W-00; Tue, 03 May 2005 21:23:13 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DSvUc-0007ud-00; Tue, 03 May 2005 21:23:10 +1000 Date: Tue, 3 May 2005 21:23:10 +1000 To: Thomas Graf Cc: Tommy Christensen , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) Message-ID: <20050503112310.GA30356@gondor.apana.org.au> References: <4276B13F.2040103@tpack.net> <20050503100306.GB29788@gondor.apana.org.au> <20050503111844.GP577@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503111844.GP577@postel.suug.ch> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-Virus-Scanned: ClamAV 0.83/865/Mon May 2 16:16:49 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 601 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 982 Lines: 24 On Tue, May 03, 2005 at 01:18:44PM +0200, Thomas Graf wrote: > > I do like the patch, no question but IFF_RUNNING is still abused > by drivers and some subsystems. So I'm not sure how reliable the > above code will be without those cases fixed. I submitted a Ouch, you're right. They either need to be fixed or we'll just have to go back to the simpler version that may call dev_activate/dev_deactivate repeatedly. > patchset once to fix some of them, not sure about the status. Also, > what about those drivers that do not support or do not use > netif_carrier_(on|off)? They simply won't benefit from this patch. This is OK since they're no worse off than where they were before. It might also prove to be an incentive for someone to finally fix them :) Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From hasso@estpak.ee Tue May 3 04:46:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 04:47:00 -0700 (PDT) Received: from arena.estpak.ee (test.estpak.ee [194.126.115.47]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Bkv7J002977 for ; Tue, 3 May 2005 04:46:57 -0700 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.50) id 1DSvrR-0005oX-3z for netdev@oss.sgi.com; Tue, 03 May 2005 14:46:45 +0300 From: Hasso Tepper Subject: Re: icmp_unreachable uses wrong ip Date: Tue, 3 May 2005 14:46:44 +0300 User-Agent: KMail/1.8 Cc: netdev@oss.sgi.com References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505021659.05674.hasso@estpak.ee> In-Reply-To: <200505021659.05674.hasso@estpak.ee> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline To: "Undisclosed.Recipients": ; Message-Id: <200505031446.44551.hasso@estpak.ee> X-archive-position: 602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Content-Length: 360 Lines: 13 Hasso Tepper wrote: > I'm attaching patch which was posted to the list some time ago. I'm using > it for some time already. I can't find the post from the archive though > at the moment. Chris Wilson was probably author of this patch. http://marc.theaimsgroup.com/?l=linux-net&m=109595048606145&w=2 -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From johnpol@2ka.mipt.ru Tue May 3 06:31:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 06:31:55 -0700 (PDT) Received: from vocord.com (user-edvans3.msk.internet2.ru [217.25.93.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43DVl7J007227 for ; Tue, 3 May 2005 06:31:49 -0700 Received: from uganda.factory.vocord.ru (uganda.factory.vocord.ru [192.168.0.48]) by vocord.com (8.13.1/8.13.1) with ESMTP id j43DUfmW000413; Tue, 3 May 2005 17:30:57 +0400 Subject: [patch/RFC]: Asynchronous IPsec processing benchmark. From: Evgeniy Polyakov Reply-To: johnpol@2ka.mipt.ru To: Herbert Xu Cc: netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" , Jamal Hadi Salim In-Reply-To: <1115117728.3414.48.camel@uganda> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> <20050503101447.GA29973@gondor.apana.org.au> <1115116295.3414.30.camel@uganda> <20050503102929.GA30097@gondor.apana.org.au> <1115117728.3414.48.camel@uganda> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-FFK2WSC8sADObNy6J1+q" Organization: MIPT Date: Tue, 03 May 2005 17:38:27 +0400 Message-Id: <1115127507.3414.58.camel@uganda> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (vocord.com [192.168.0.1]); Tue, 03 May 2005 17:31:02 +0400 (MSD) X-archive-position: 603 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev Content-Length: 943 Lines: 40 --=-FFK2WSC8sADObNy6J1+q Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Here are some numbers: ./netperf -l 60 -H gw -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 TCP STREAM TEST to gw : +/-2.5% @ 99% conf. async-ipsec, 10^6bits/sec: 35.42 sync-ipsec, 10^6bits/sec: 37.11 So even with existing timer deferring it is not noticebly slower [about 4%]. And I think that benefits it provides definitely cost that price and=20 compile time option. --=20 Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski --=-FFK2WSC8sADObNy6J1+q Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCd37TIKTPhE+8wY0RAho5AJ9rMXgXW4qUErGFYBfH1nLZWVDxxwCdH3ZZ n1R13gy6YosPvqaXG4XfhhQ= =dmqb -----END PGP SIGNATURE----- --=-FFK2WSC8sADObNy6J1+q-- From dave@thedillows.org Tue May 3 07:17:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 07:17:10 -0700 (PDT) Received: from smtp.knology.net (smtp.knology.net [24.214.63.101]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j43EH77J009580 for ; Tue, 3 May 2005 07:17:07 -0700 Received: (qmail 21339 invoked by uid 0); 3 May 2005 14:16:54 -0000 Received: from user-24-96-111-205.knology.net (HELO ori.thedillows.org) (24.96.111.205) by smtp7.knology.net with SMTP; 3 May 2005 14:16:54 -0000 Received: from ori.thedillows.org (localhost [127.0.0.1]) by ori.thedillows.org (8.13.1/8.13.1) with ESMTP id j43EHJff004440; Tue, 3 May 2005 10:17:19 -0400 Received: (from il1@localhost) by ori.thedillows.org (8.13.1/8.13.1/Submit) id j43EHJin004439; Tue, 3 May 2005 10:17:19 -0400 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: Re: IPsec performance From: Dave Dillow To: Miika Komu Cc: Patrick McHardy , Netdev In-Reply-To: References: <1115099678.2953.3.camel@ori.thedillows.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 03 May 2005 10:17:19 -0400 Message-Id: <1115129839.2953.4.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-archive-position: 605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev Content-Length: 572 Lines: 16 On Tue, 2005-05-03 at 09:44 +0300, Miika Komu wrote: > On Tue, 3 May 2005, Dave Dillow wrote: > > > On Tue, 2005-05-03 at 08:25 +0300, Miika Komu wrote: > > > However, this does explain why I got only 1.9 megabytes/s with 3DES. > > > > What was your hardware? Without knowing what you're running on, it's > > impossible to tell if that is good or bad. > > > > Linux Journal was getting ~5.5MB/s on a PIV 2.2GHz. > > I get ~2.1MB/s on a 550MHz Athlon. > > Intel Pentium III 500 MHz 3DES is processor intensive. I'd say 1.9MB/s is reasonable for the hardware you are on. From akepner@sgi.com Tue May 3 07:53:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 07:53:53 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Erm7J011109 for ; Tue, 3 May 2005 07:53:48 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id j43Ga1RG008145 for ; Tue, 3 May 2005 09:36:01 -0700 Received: from [192.168.2.20] (mtv-vpn-sw-corp-0-189.corp.sgi.com [134.15.0.189]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id j43ErZ5x20946576; Tue, 3 May 2005 07:53:35 -0700 (PDT) Date: Tue, 3 May 2005 07:52:06 -0700 (PDT) From: Arthur Kepner X-X-Sender: akepner@linux.site To: Anton Blanchard cc: Ramkrishna Vepa , "'Leonid Grossman'" , muhammad.shafiq@neterion.com, ramkrishna.vepa@neterion.com, netdev@oss.sgi.com, "'Ravinandan Arakali'" Subject: Re: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() In-Reply-To: <20050503030620.GE12682@krispykreme> Message-ID: References: <03d401c54f8c$03917fd0$5c10100a@pc.s2io.com> <20050503030620.GE12682@krispykreme> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 606 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akepner@sgi.com Precedence: bulk X-list: netdev Content-Length: 358 Lines: 14 On Tue, 3 May 2005, Anton Blanchard wrote: > > > [Ram] Yes, it is to ensure ordering as well as the flush of the io that is > > required in some platforms. > > If the flush of the IO is required I cant see how we can remove the read. > Agreed. Can someone from neterion comment? Is a flush required, or is ordering all that's required here? -- Arthur From breed@zuzulu.com Tue May 3 08:28:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 08:28:29 -0700 (PDT) Received: from optimus.nocdirect.com (optimus.nocdirect.com [69.73.171.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43FSM7J019463 for ; Tue, 3 May 2005 08:28:23 -0700 Received: from wbar3.sjo1-4-11-005-121.sjo1.dsl-verizon.net ([4.11.5.121] helo=[192.168.1.102]) by optimus.nocdirect.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.50) id 1DSzJl-0006jl-FN; Tue, 03 May 2005 10:28:14 -0500 From: Benjamin Reed To: netdev@oss.sgi.com Subject: [PATCH] dynamic wep keys for airo.c Date: Tue, 3 May 2005 08:26:42 -0700 User-Agent: KMail/1.8 Cc: linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200505030826.42564.breed@zuzulu.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - optimus.nocdirect.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zuzulu.com X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 608 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: breed@zuzulu.com Precedence: bulk X-list: netdev I'm resubmitting a patch for the 2.6.11.8 aironet driver (airo.c) that will enable dynamic wep keying without disabling the MAC. It allows us to use xsupplicant with the driver. Aironet provides the ability to set WEP keys permanently or temporarily. There is a special IW_ENCODE_TEMP flag for selecting which type of key you are setting. However, apart from iwconfig, nobody seems to use this flag. When a permanent WEP key is set, the MAC must be disabled. I have added a module parameter to skip disabling the MAC even if a permanent WEP key is set. Using this flag allows xsupplicant to work without modification. ben Signed-off-by: Benjamin Reed --- drivers/net/wireless/airo.c.orig 2005-05-02 10:15:24.000000000 -0700 +++ drivers/net/wireless/airo.c 2005-05-02 11:16:43.000000000 -0700 @@ -224,6 +224,8 @@ static int maxencrypt /* = 0 */; /* The highest rate that the card can encrypt at. 0 means no limit. For old cards this was 4 */ +static int perm_key_support = 1; /* If set, the MAC will be disabled when + permanent wep keys are set. */ static int auto_wep /* = 0 */; /* If set, it tries to figure out the wep mode */ static int aux_bap /* = 0 */; /* Checks to see if the aux ports are needed to read the bap, needed on some older cards and buses. */ @@ -251,6 +253,13 @@ module_param(basic_rate, int, 0); module_param_array(rates, int, NULL, 0); module_param_array(ssids, charp, NULL, 0); module_param(auto_wep, int, 0); +module_param(perm_key_support, int, 1); +MODULE_PARM_DESC(perm_key_support, "The MAC is supposed to be disabled before \ +a permanent WEP key (the default) is set. Applications that want to set the \ +temporary keys, and thus not disable the MAC, are supposed to use the \ +IW_ENCODE_TEMP flag. Unfortunately, life doesn't always work the way it is \ +supposed to. If the IW_ENCODE_TEMP flag is not used and the MAC should not be \ +disabled, set this flag to 0."); MODULE_PARM_DESC(auto_wep, "If non-zero, the driver will keep looping through \ the authentication options until an association is made. The value of \ auto_wep is number of the wep keys to check. A value of 2 will try using \ @@ -1738,9 +1747,12 @@ static int writeWepKeyRid(struct airo_in rc = PC4500_writerid(ai, RID_WEP_TEMP, &wkr, sizeof(wkr), lock); if (rc!=SUCCESS) printk(KERN_ERR "airo: WEP_TEMP set %x\n", rc); if (perm) { + // We make these messages debug. They really should be error, + // but no one seems to use the TEMP flag and writing a PERM key + // with the MAC disable throws this error rc = PC4500_writerid(ai, RID_WEP_PERM, &wkr, sizeof(wkr), lock); if (rc!=SUCCESS) { - printk(KERN_ERR "airo: WEP_PERM set %x\n", rc); + printk(KERN_DEBUG "airo: WEP_PERM set %x\n", rc); } } return rc; @@ -3813,11 +3825,14 @@ static u16 issuecommand(struct airo_info pRsp->rsp1 = IN4500(ai, RESP1); pRsp->rsp2 = IN4500(ai, RESP2); if ((pRsp->status & 0xff00)!=0 && pCmd->cmd != CMD_SOFTRESET) { - printk (KERN_ERR "airo: cmd= %x\n", pCmd->cmd); - printk (KERN_ERR "airo: status= %x\n", pRsp->status); - printk (KERN_ERR "airo: Rsp0= %x\n", pRsp->rsp0); - printk (KERN_ERR "airo: Rsp1= %x\n", pRsp->rsp1); - printk (KERN_ERR "airo: Rsp2= %x\n", pRsp->rsp2); + /* These really should be error, but supplicants don't seem + * to use the TEMP flag when setting the keys, so this + * error is common */ + printk (KERN_DEBUG "airo: cmd= %x\n", pCmd->cmd); + printk (KERN_DEBUG "airo: status= %x\n", pRsp->status); + printk (KERN_DEBUG "airo: Rsp0= %x\n", pRsp->rsp0); + printk (KERN_DEBUG "airo: Rsp1= %x\n", pRsp->rsp1); + printk (KERN_DEBUG "airo: Rsp2= %x\n", pRsp->rsp2); } // clear stuck command busy if necessary @@ -4046,10 +4061,12 @@ static int PC4500_writerid(struct airo_i Cmd cmd; Resp rsp; +#if 0 /* This check is to catch bugs, not needed for WepRid with temp key */ if (test_bit(FLAG_ENABLED, &ai->flags)) printk(KERN_ERR "%s: MAC should be disabled (rid=%04x)\n", __FUNCTION__, rid); +#endif memset(&cmd, 0, sizeof(cmd)); memset(&rsp, 0, sizeof(rsp)); @@ -5094,7 +5111,7 @@ static int set_wep_key(struct airo_info wkr.len = sizeof(wkr); wkr.kindex = 0xffff; wkr.mac[0] = (char)index; - if (perm) printk(KERN_INFO "Setting transmit key to %d\n", index); + if (perm) printk(KERN_DEBUG "Setting transmit key to %d\n", index); if (perm) ai->defindex = (char)index; } else { // We are actually setting the key @@ -5103,12 +5120,11 @@ static int set_wep_key(struct airo_info wkr.klen = keylen; memcpy( wkr.key, key, keylen ); memcpy( wkr.mac, macaddr, ETH_ALEN ); - printk(KERN_INFO "Setting key %d\n", index); } - disable_MAC(ai, lock); + if (perm_key_support && perm) disable_MAC(ai, lock); writeWepKeyRid(ai, &wkr, perm, lock); - enable_MAC(ai, &rsp, lock); + if (perm_key_support && perm) enable_MAC(ai, &rsp, lock); return 0; } @@ -5562,9 +5578,9 @@ static int __init airo_init_module( void } #ifdef CONFIG_PCI - printk( KERN_INFO "airo: Probing for PCI adapters\n" ); + printk( KERN_DEBUG "airo: Probing for PCI adapters\n" ); pci_register_driver(&airo_driver); - printk( KERN_INFO "airo: Finished probing for PCI adapters\n" ); + printk( KERN_DEBUG "airo: Finished probing for PCI adapters\n" ); #endif /* Always exit with success, as we are a library module @@ -5576,7 +5592,7 @@ static int __init airo_init_module( void static void __exit airo_cleanup_module( void ) { while( airo_devices ) { - printk( KERN_INFO "airo: Unregistering %s\n", airo_devices->dev->name ); + printk( KERN_DEBUG "airo: Unregistering %s\n", airo_devices->dev->name ); stop_airo_card( airo_devices->dev, 1 ); } #ifdef CONFIG_PCI @@ -6166,6 +6182,7 @@ static int airo_set_encode(struct net_de { struct airo_info *local = dev->priv; CapabilityRid cap_rid; /* Card capability info */ + u16 oldAuthType; /* Is WEP supported ? */ readCapabilityRid(local, &cap_rid, 1); @@ -6208,7 +6225,8 @@ static int airo_set_encode(struct net_de /* Copy the key in the driver */ memcpy(key.key, extra, dwrq->length); /* Send the key to the card */ - set_wep_key(local, index, key.key, key.len, 1, 1); + set_wep_key(local, index, key.key, key.len, + !(dwrq->flags&IW_ENCODE_TEMP), 1); } /* WE specify that if a valid key is set, encryption * should be enabled (user may turn it off later) @@ -6222,13 +6240,15 @@ static int airo_set_encode(struct net_de /* Do we want to just set the transmit key index ? */ int index = (dwrq->flags & IW_ENCODE_INDEX) - 1; if ((index >= 0) && (index < ((cap_rid.softCap & 0x80)?4:1))) { - set_wep_key(local, index, NULL, 0, 1, 1); + set_wep_key(local, index, NULL, 0, + !(dwrq->flags&IW_ENCODE_TEMP), 1); } else /* Don't complain if only change the mode */ if(!dwrq->flags & IW_ENCODE_MODE) { return -EINVAL; } } + oldAuthType = local->config.authType; /* Read the flags */ if(dwrq->flags & IW_ENCODE_DISABLED) local->config.authType = AUTH_OPEN; // disable encryption @@ -6237,7 +6257,7 @@ static int airo_set_encode(struct net_de if(dwrq->flags & IW_ENCODE_OPEN) local->config.authType = AUTH_ENCRYPT; // Only Wep /* Commit the changes to flags if needed */ - if(dwrq->flags & IW_ENCODE_MODE) + if(oldAuthType != local->config.authType) set_bit (FLAG_COMMIT, &local->flags); return -EINPROGRESS; /* Call commit handler */ } From mkomu@twilight.cs.hut.fi Tue May 3 09:14:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 09:14:25 -0700 (PDT) Received: from twilight.cs.hut.fi (twilight.cs.hut.fi [130.233.40.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43GEK7J023499 for ; Tue, 3 May 2005 09:14:21 -0700 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 0DA3B2FDE; Tue, 3 May 2005 19:14:06 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5BED92FC3; Tue, 3 May 2005 19:14:05 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j43GE5X09755; Tue, 3 May 2005 19:14:05 +0300 (EEST) Date: Tue, 3 May 2005 19:14:05 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Dave Dillow Cc: Patrick McHardy , Netdev Subject: Re: IPsec performance In-Reply-To: <1115129839.2953.4.camel@ori.thedillows.org> Message-ID: References: <1115099678.2953.3.camel@ori.thedillows.org> <1115129839.2953.4.camel@ori.thedillows.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: miika@iki.fi Precedence: bulk X-list: netdev On Tue, 3 May 2005, Dave Dillow wrote: > On Tue, 2005-05-03 at 09:44 +0300, Miika Komu wrote: > > On Tue, 3 May 2005, Dave Dillow wrote: > > > > > On Tue, 2005-05-03 at 08:25 +0300, Miika Komu wrote: > > > > However, this does explain why I got only 1.9 megabytes/s with 3DES. > > > > > > What was your hardware? Without knowing what you're running on, it's > > > impossible to tell if that is good or bad. > > > > > > Linux Journal was getting ~5.5MB/s on a PIV 2.2GHz. > > > I get ~2.1MB/s on a 550MHz Athlon. > > > > Intel Pentium III 500 MHz > > 3DES is processor intensive. I'd say 1.9MB/s is reasonable for the > hardware you are on. Ok. Thanks for your quick responses! -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From ram.vepa@neterion.com Tue May 3 09:23:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 09:23:31 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43GNO7J024249 for ; Tue, 3 May 2005 09:23:24 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j43GNBOC002476; Tue, 3 May 2005 12:23:11 -0400 (EDT) Received: from spiderman ([10.16.16.58]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id j43GN8VG007709; Tue, 3 May 2005 12:23:08 -0400 (EDT) From: "Ramkrishna Vepa" To: "'Arthur Kepner'" , "'Anton Blanchard'" Cc: "'Leonid Grossman'" , , , , "'Ravinandan Arakali'" Subject: RE: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() Date: Tue, 3 May 2005 09:23:07 -0700 Message-ID: <03d701c54ffc$651958c0$5c10100a@pc.s2io.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Scanned-By: MIMEDefang 2.34 X-archive-position: 610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ram.vepa@neterion.com Precedence: bulk X-list: netdev Ordering is all that is required. We can get rid of the flush. Ram > -----Original Message----- > From: Arthur Kepner [mailto:akepner@sgi.com] > Sent: Tuesday, May 03, 2005 7:52 AM > To: Anton Blanchard > Cc: Ramkrishna Vepa; 'Leonid Grossman'; muhammad.shafiq@neterion.com; > ramkrishna.vepa@neterion.com; netdev@oss.sgi.com; 'Ravinandan Arakali' > Subject: Re: [PATCH] s2io: replace readq() with mmiowb() in s2io_xmit() > > On Tue, 3 May 2005, Anton Blanchard wrote: > > > > > > [Ram] Yes, it is to ensure ordering as well as the flush of the io > that is > > > required in some platforms. > > > > If the flush of the IO is required I cant see how we can remove the > read. > > > > Agreed. Can someone from neterion comment? Is a flush required, or is > ordering all that's required here? > > -- > Arthur From kaber@trash.net Tue May 3 11:15:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 11:15:24 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43IFL7J032382 for ; Tue, 3 May 2005 11:15:21 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT1vC-00029o-Eu; Tue, 03 May 2005 20:15:03 +0200 Message-ID: <4277BFA6.8090306@trash.net> Date: Tue, 03 May 2005 20:15:02 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Hasso Tepper CC: "J. Simonetti" , netdev@oss.sgi.com Subject: Re: icmp_unreachable uses wrong ip References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505022038.22014.hasso@estpak.ee> <4276A400.2050306@trash.net> <200505030944.49175.hasso@estpak.ee> In-Reply-To: <200505030944.49175.hasso@estpak.ee> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Hasso Tepper wrote: > Patrick McHardy wrote: >> >>Your patch can't guarantee that the address used is the same that was >>used as nexthop by the previous hop in the path when multiple addresses >>are configured on the incoming interface. So I don't think it achieves >>much of your goal of making debugging complicated topologies easier. > > At first I don't care what was used as nexthop. I want to know which > physical link was used. Having multiple addresses in the same link is more > corner case in core network anyway. But when multiple addresses are used the result can be even more confusing. I don't like inconsistent behaviour, and this patch works sometimes and sometimes it doesn't. > And can you explain what theoretical possibilities router has to obtain info > what address was used as nexthop by neighbour? I can think of none. Regards Patrick From dave@thedillows.org Tue May 3 12:28:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 12:28:13 -0700 (PDT) Received: from iasrv1.idleaire.net (ns1.idleaire.net [65.220.16.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43JS87J007219 for ; Tue, 3 May 2005 12:28:08 -0700 Received: by iasrv1.idleaire.net (Postfix, from userid 300) id AF75C236E55; Tue, 3 May 2005 15:27:44 -0400 (EDT) Received: from corp4.idleaire.com (corp4.idleaire.com [10.1.66.36]) by iasrv1.idleaire.net (Postfix) with ESMTP id 1EC90236E4D; Tue, 3 May 2005 15:27:42 -0400 (EDT) Received: from [10.1.66.124] ([10.1.66.124]) by corp4.idleaire.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 May 2005 15:27:44 -0400 Subject: Re: IPsec performance From: Dave Dillow To: Miika Komu Cc: Patrick McHardy , Netdev In-Reply-To: References: <1115099678.2953.3.camel@ori.thedillows.org> <1115129839.2953.4.camel@ori.thedillows.org> Content-Type: text/plain Date: Tue, 03 May 2005 15:27:41 -0400 Message-Id: <1115148461.31573.9.camel@dillow.idleaire.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2005 19:27:44.0358 (UTC) FILETIME=[2E249860:01C55016] X-archive-position: 612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev On Tue, 2005-05-03 at 19:14 +0300, Miika Komu wrote: > On Tue, 3 May 2005, Dave Dillow wrote: > > 3DES is processor intensive. I'd say 1.9MB/s is reasonable for the > > hardware you are on. > > Ok. Thanks for your quick responses! I should note that I mean reasonable given the current implementation -- you're seeing performance in line with numbers on other machines. I think it's been mentioned that our 3DES implementation has not been tuned for x86, so there's probably some performance being left on the floor. I could be wrong, though. -- Dave Dillow From davem@davemloft.net Tue May 3 12:39:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 12:39:15 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43JdC7J008140 for ; Tue, 3 May 2005 12:39:13 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT33Y-0001hc-00; Tue, 03 May 2005 12:27:44 -0700 Date: Tue, 3 May 2005 12:27:44 -0700 From: "David S. Miller" To: Dave Dillow Cc: miika@iki.fi, kaber@trash.net, netdev@oss.sgi.com Subject: Re: IPsec performance Message-Id: <20050503122744.1e5cafcf.davem@davemloft.net> In-Reply-To: <1115148461.31573.9.camel@dillow.idleaire.com> References: <1115099678.2953.3.camel@ori.thedillows.org> <1115129839.2953.4.camel@ori.thedillows.org> <1115148461.31573.9.camel@dillow.idleaire.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 613 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 03 May 2005 15:27:41 -0400 Dave Dillow wrote: > I think it's been mentioned that our 3DES implementation has not been > tuned for x86, so there's probably some performance being left on the > floor. That's right. We only have an optimized AES implementation in assembler, and that's for i386 and x86_64 platforms only. From shemminger@osdl.org Tue May 3 14:05:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:05:48 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43L5g7J011397 for ; Tue, 3 May 2005 14:05:42 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43L5Rs4019254 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 14:05:27 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43L5Rfc016016; Tue, 3 May 2005 14:05:27 -0700 Date: Tue, 3 May 2005 14:05:28 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> In-Reply-To: <20050502200251.38271b61.davem@davemloft.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 614 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Mon, 2 May 2005 20:02:51 -0700 "David S. Miller" wrote: > On Mon, 2 May 2005 16:24:05 -0700 > Stephen Hemminger wrote: > > > While I was on vacation, OSDL did some networking changes that seems to aggravate some > > existing bug in the tg3 driver. Could be some VLAN related garbage, not sure. > > > > System is 2 CPU AMD64 and the tg3 is on the motherboard. > > > > I am seeing messages like: > > eth0: Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:60:53:08:18 > > eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] > > tg3: tg3_stop_block timed out, ofs=4000 enable_bit=2 > > > > Any clues? > > This usually means that there is some DMA corruption. > For example, some bug in the x86_64 IOMMU code or similar > causes a bogus DMA address to be fed to the tg3 or even > worse a DMA mapping is unmapped before tg3 is actually > done with it. > > Please try to get some more debugging. One thing that might > be useful would be a dump of the PCI config and PCI status > registers from PCI config space when that tg3_stop_block > event triggers. It will tell us if there was a master or > slave abort on the PCI bus which would confirm my above > theory. Added call to tg_dump_state() tg3: tg3_stop_block timed out, ofs=4000 enable_bit=2 DEBUG: PCI status [02b0] TG3PCI state[000010e2] DEBUG: MAC_MODE[00c04c08] MAC_STATUS[00400003] MAC_EVENT[00001000] MAC_LED_CTRL[00000880] DEBUG: MAC_TX_MODE[00000010] MAC_TX_STATUS[00000008] MAC_RX_MODE[00000004] MAC_RX_STATUS[00000000] DEBUG: SNDDATAI_MODE[00000000] SNDDATAI_STATUS[00000000] SNDDATAI_STATSCTRL[00000003] DEBUG: SNDDATAC_MODE[00000000] DEBUG: SNDBDS_MODE[00000004] SNDBDS_STATUS[00000000] DEBUG: SNDBDI_MODE[00000004] SNDBDI_STATUS[00000000] DEBUG: SNDBDC_MODE[00000000] DEBUG: RCVLPC_MODE[00000000] RCVLPC_STATUS[00000000] RCVLPC_STATSCTRL[00000001] DEBUG: RCVDBDI_MODE[00000010] RCVDBDI_STATUS[00000000] DEBUG: RCVDCC_MODE[00000004] DEBUG: RCVBDI_MODE[00000004] RCVBDI_STATUS[00000000] DEBUG: RCVCC_MODE[00000004] RCVCC_STATUS[00000000] DEBUG: RCVLSC_MODE[00000004] RCVLSC_STATUS[00000000] DEBUG: MBFREE_MODE[00000000] MBFREE_STATUS[00000000] DEBUG: HOSTCC_MODE[00000100] HOSTCC_STATUS[00000000] DEBUG: HOSTCC_STATS_BLK_HOST_ADDR[0000000006bb8000] DEBUG: HOSTCC_STATUS_BLK_HOST_ADDR[000000001ce8c000] DEBUG: HOSTCC_STATS_BLK_NIC_ADDR[00000300] DEBUG: HOSTCC_STATUS_BLK_NIC_ADDR[00000b00] DEBUG: MEMARB_MODE[00000002] MEMARB_STATUS[00000000] DEBUG: BUFMGR_MODE[00000004] BUFMGR_STATUS[00000000] DEBUG: BUFMGR_MB_POOL_ADDR[00008000] BUFMGR_MB_POOL_SIZE[00018000] DEBUG: BUFMGR_DMA_DESC_POOL_ADDR[00002000] BUFMGR_DMA_DESC_POOL_SIZE[00002000] DEBUG: RDMAC_MODE[000003fc] RDMAC_STATUS[00000000] DEBUG: WDMAC_MODE[000003fc] WDMAC_STATUS[00000000] DEBUG: DMAC_MODE[00000000] DEBUG: GRC_MODE[04130034] GRC_MISC_CFG[00081082] DEBUG: GRC_LOCAL_CTRL[01000209] DEBUG: RCVDBDI_JUMBO_BD[0000000000000000:00000002:00000000] DEBUG: RCVDBDI_STD_BD[000000002d1c4000:06000000:00006000] DEBUG: RCVDBDI_MINI_BD[0000000000000000:00000002:00000000] > Also what PCI controller is in this box? (ie. the north bridge, > lspci -v would tell) 00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=69 I/O behind bridge: 00002000-00002fff Memory behind bridge: c0100000-c01fffff Capabilities: [c0] HyperTransport: Slave or Primary Interface Capabilities: [f0] HyperTransport: Interrupt Discovery and Configuration 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05) Subsystem: IBM: Unknown device 02b7 Flags: bus master, 66Mhz, medium devsel, latency 0 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03) (prog-if 8a [Master SecP PriP]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 64 I/O ports at 1460 [size=16] 00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02) Subsystem: IBM: Unknown device 02b7 Flags: medium devsel, IRQ 11 I/O ports at 1440 [size=32] 00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05) Subsystem: IBM: Unknown device 02b7 Flags: medium devsel 00:07.5 Multimedia audio controller: Advanced Micro Devices [AMD] AMD-8111 AC97 Audio (rev 03) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 64, IRQ 169 I/O ports at 1000 [size=256] I/O ports at 1400 [size=64] 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 I/O behind bridge: 00003000-00003fff Memory behind bridge: c0200000-c02fffff Capabilities: [a0] PCI-X bridge device. Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration Capabilities: [c0] HyperTransport: Slave or Primary Interface 00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 0 Memory at c0000000 (64-bit, non-prefetchable) [size=4K] 00:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=03, subordinate=03, sec-latency=64 Memory behind bridge: c0300000-c03fffff Capabilities: [a0] PCI-X bridge device. Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration 00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 0 Memory at c0001000 (64-bit, non-prefetchable) [size=4K] 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface Capabilities: [a0] HyperTransport: Host or Secondary Interface Capabilities: [c0] HyperTransport: Host or Secondary Interface 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel 00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface Capabilities: [a0] HyperTransport: Host or Secondary Interface Capabilities: [c0] HyperTransport: Host or Secondary Interface 00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel 00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel 00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel 01:02.0 Unknown mass storage controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01) (prog-if 85) Subsystem: IBM: Unknown device 3512 Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 169 I/O ports at 2020 [size=8] I/O ports at 2014 [size=4] I/O ports at 2018 [size=8] I/O ports at 2010 [size=4] I/O ports at 2000 [size=16] Memory at c0104000 (32-bit, non-prefetchable) [size=512] Capabilities: [60] Power Management version 2 01:03.0 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 64, IRQ 193 Memory at c0102000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 01:03.1 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 64, IRQ 201 Memory at c0103000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 01:03.2 USB Controller: NEC Corporation USB 2.0 (rev 04) (prog-if 20 [EHCI]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 132, IRQ 185 Memory at c0104400 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Power Management version 2 02:01.0 Ethernet controller: Syskonnect (Schneider & Koch) SK-98xx Gigabit Ethernet Server Adapter (rev 13) Subsystem: Syskonnect (Schneider & Koch) SK-9821 Gigabit Ethernet Server Adapter (SK-NET GE-T) Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 10 Memory at c0200000 (32-bit, non-prefetchable) [size=16K] I/O ports at 3000 [size=256] Capabilities: [48] Power Management version 1 Capabilities: [50] Vital Product Data 03:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02) Subsystem: IBM: Unknown device 026f Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 177 Memory at c0300000 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] PCI-X non-bridge device. Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- 08:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-8151 System Controller (rev 13) Subsystem: IBM: Unknown device 02b7 Flags: medium devsel Memory at d0000000 (32-bit, prefetchable) [size=256M] Capabilities: [a0] AGP version 3.0 Capabilities: [c0] HyperTransport: Slave or Primary Interface 08:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8151 AGP Bridge (rev 13) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 99 Bus: primary=08, secondary=09, subordinate=0d, sec-latency=68 I/O behind bridge: 00004000-00004fff Memory behind bridge: c0700000-c07fffff Prefetchable memory behind bridge: e0000000-efffffff 08:03.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=08, secondary=0e, subordinate=12, sec-latency=64 Capabilities: [a0] PCI-X bridge device. Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration Capabilities: [c0] HyperTransport: Slave or Primary Interface 08:03.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 0 Memory at c0600000 (64-bit, non-prefetchable) [size=4K] 08:04.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=08, secondary=13, subordinate=17, sec-latency=64 Capabilities: [a0] PCI-X bridge device. Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration 08:04.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC]) Subsystem: IBM: Unknown device 02b7 Flags: bus master, medium devsel, latency 0 Memory at c0601000 (64-bit, non-prefetchable) [size=4K] 09:00.0 VGA compatible controller: ATI Technologies Inc Radeon R300 NG [FireGL X1] (rev 80) (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 0172 Flags: bus master, stepping, 66Mhz, medium devsel, latency 66, IRQ 5 Memory at e0000000 (32-bit, prefetchable) [size=128M] I/O ports at 4000 [size=256] Memory at c0700000 (32-bit, non-prefetchable) [size=64K] Capabilities: [58] AGP version 3.0 Capabilities: [50] Power Management version 2 09:00.1 Display controller: ATI Technologies Inc Radeon R300 [FireGL X1] (Secondary) (rev 80) Subsystem: ATI Technologies Inc: Unknown device 0173 Flags: bus master, stepping, 66Mhz, medium devsel, latency 66 Memory at e8000000 (32-bit, prefetchable) [size=128M] Memory at c0710000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 -- Stephen Hemminger > Since AMD promised me an Opteron system last year, but never > made good on that promise, I've never been able to work on > fixing this bug myself. :-/ From davem@davemloft.net Tue May 3 14:24:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:24:38 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LOZ7J012441 for ; Tue, 3 May 2005 14:24:35 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4hf-0002RJ-00; Tue, 03 May 2005 14:13:15 -0700 Date: Tue, 3 May 2005 14:13:14 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-Id: <20050503141314.441c9d75.davem@davemloft.net> In-Reply-To: <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 615 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 3 May 2005 14:05:28 -0700 Stephen Hemminger wrote: > 00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC]) Buggy 8131 APIC, does the drivers/pci/quirks.c:quirk_amd_8131_ioapic() message: PCI: MSI quirk detected. pci_msi_quirk set. trigger? MSI support recently got added to the tg3.c driver, but it should only register MSI interrupt handling if pci_enable_msi() returns zero. See what it ends up doing, or if you even have a MSI capable tg3.c in your kernel. From shemminger@osdl.org Tue May 3 14:30:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:30:17 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LUB7J013100 for ; Tue, 3 May 2005 14:30:12 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43LTqs4021479 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 14:29:53 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43LTqh4017444; Tue, 3 May 2005 14:29:52 -0700 Date: Tue, 3 May 2005 14:29:52 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050503142952.527c33c5@dxpl.pdx.osdl.net> In-Reply-To: <20050503141314.441c9d75.davem@davemloft.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 616 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Tue, 3 May 2005 14:13:14 -0700 "David S. Miller" wrote: > On Tue, 3 May 2005 14:05:28 -0700 > Stephen Hemminger wrote: > > > 00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC]) > > Buggy 8131 APIC, does the drivers/pci/quirks.c:quirk_amd_8131_ioapic() > message: > > PCI: MSI quirk detected. pci_msi_quirk set. yes. that is there. > trigger? MSI support recently got added to the tg3.c driver, but it should > only register MSI interrupt handling if pci_enable_msi() returns zero. There is no call to pci_enable_msi in the 2.6.12-rc3 source > See what it ends up doing, or if you even have a MSI capable tg3.c in > your kernel. From davem@davemloft.net Tue May 3 14:35:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:35:46 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LZb7J013713 for ; Tue, 3 May 2005 14:35:37 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4s0-0002TT-00; Tue, 03 May 2005 14:23:56 -0700 Date: Tue, 3 May 2005 14:23:55 -0700 From: "David S. Miller" To: Herbert Xu Cc: yoshfuji@linux-ipv6.org, dlstevens@us.ibm.com, netdev@oss.sgi.com Subject: Re: [IPV6] Fix raw socket checksums with IPsec Message-Id: <20050503142355.7f2c7ba5.davem@davemloft.net> In-Reply-To: <20050430123301.GA25174@gondor.apana.org.au> References: <20050430123301.GA25174@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 30 Apr 2005 22:33:01 +1000 Herbert Xu wrote: > I made a mistake in my last patch to the raw socket checksum code. > I used the value of inet->cork.length as the length of the payload. > While this works with normal packets, it breaks down when IPsec is > present since the cork length includes the extension header length. > > So here is a patch to fix the length calculations. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. From davem@davemloft.net Tue May 3 14:35:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:35:52 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LZn7J013736 for ; Tue, 3 May 2005 14:35:49 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4sY-0002Tj-00; Tue, 03 May 2005 14:24:30 -0700 Date: Tue, 3 May 2005 14:24:30 -0700 From: "David S. Miller" To: Herbert Xu Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [IPV6] Include ipv6.h for ipv6_addr_set Message-Id: <20050503142430.05ea5437.davem@davemloft.net> In-Reply-To: <20050430073845.GA3515@gondor.apana.org.au> References: <20050430073845.GA3515@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 618 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 30 Apr 2005 17:38:45 +1000 Herbert Xu wrote: > This patch includes net/ipv6.h from addrconf.h since it needs > ipv6_addr_set. > > Signed-off-by: Herbert Xu Applied, thanks Herbert. From shemminger@osdl.org Tue May 3 14:36:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:36:24 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LaI7J013890 for ; Tue, 3 May 2005 14:36:18 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43La3s4021881 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 14:36:04 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43La3SO017789; Tue, 3 May 2005 14:36:03 -0700 Date: Tue, 3 May 2005 14:36:03 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Fw: [Bug 4554] New: /proc/net/route missing info for 127.0.0.1/8 Message-ID: <20050503143603.4d77d3dd@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 619 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Begin forwarded message: Date: Wed, 27 Apr 2005 09:05:29 -0700 From: bugme-daemon@osdl.org To: shemminger@osdl.org Subject: [Bug 4554] New: /proc/net/route missing info for 127.0.0.1/8 http://bugme.osdl.org/show_bug.cgi?id=4554 Summary: /proc/net/route missing info for 127.0.0.1/8 Kernel Version: kernel-2.6.9-5.0.3.EL Status: NEW Severity: normal Owner: shemminger@osdl.org Submitter: alex@milivojevic.org Distribution: CentOS 4 (RHEL4) Hardware Environment: i686 Problem Description: cat /proc/net/route is missing information for 127.0.0.1/8 network (lo interface). On 2.4 kernels, this info was present (just checked on an old RH7.3 machine). It seems to be missing on 2.6 kernels. Bug? Feature? Omission? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From davem@davemloft.net Tue May 3 14:36:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:36:38 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LaV7J014092 for ; Tue, 3 May 2005 14:36:31 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4tH-0002Tz-00; Tue, 03 May 2005 14:25:15 -0700 Date: Tue, 3 May 2005 14:25:15 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/2] [XFRM] Prevent off-by-one access to xfrm_dispatch Message-Id: <20050503142515.1c3c5d8e.davem@davemloft.net> In-Reply-To: <20050501184731.GJ577@postel.suug.ch> References: <20050501184731.GJ577@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 620 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sun, 1 May 2005 20:47:31 +0200 Thomas Graf wrote: > Makes the type > XFRM_MSG_MAX check behave correctly to > protect access to xfrm_dispatch. > > Signed-off-by: Thomas Graf Applied, thanks Thomas. From davem@davemloft.net Tue May 3 14:37:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:37:14 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Lb97J014769 for ; Tue, 3 May 2005 14:37:09 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4tw-0002UF-00; Tue, 03 May 2005 14:25:56 -0700 Date: Tue, 3 May 2005 14:25:55 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/2] [XFRM] Cleanup xfrm_msg_min and xfrm_dispatch Message-Id: <20050503142555.5b795eeb.davem@davemloft.net> In-Reply-To: <20050501185548.GK577@postel.suug.ch> References: <20050501185548.GK577@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 621 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sun, 1 May 2005 20:55:48 +0200 Thomas Graf wrote: > Converts xfrm_msg_min and xfrm_dispatch to use c99 designated > initializers to make greping a little bit easier. Also replaces > two hardcoded message type with meaningful names. > > Signed-off-by: Thomas Graf Applied, thanks. From davem@davemloft.net Tue May 3 14:38:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:38:56 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Lcr7J016230 for ; Tue, 3 May 2005 14:38:54 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4vc-0002Uv-00; Tue, 03 May 2005 14:27:40 -0700 Date: Tue, 3 May 2005 14:27:40 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/3] [RTNETLINK] Fix RTM_MAX to represent the maximum valid message type Message-Id: <20050503142740.345925ea.davem@davemloft.net> In-Reply-To: <20050430195058.GC577@postel.suug.ch> References: <20050430195058.GC577@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 622 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 30 Apr 2005 21:50:58 +0200 Thomas Graf wrote: > RTM_MAX is currently set to the maximum reserverd message type plus one > thus being the cause of two bugs for new types being assigned a) given the > new family registers only the NEW command in its reserved block the array > size for per family entries is calculated one entry short and b) given the > new family registers all commands RTM_MAX would point to the first entry > of the block following this one and the rtnetlink receive path would accept > a message type for a nonexisting family. > > This patch changes RTM_MAX to point to the maximum valid message type > by aligning it to the start of the next block and subtracting one. > > Signed-off-by: Thomas Graf Excellent observation. The fact that we encode the "modifies state" in the low bits of the RTM_* numbers has always been a source of obscure bugs and hard to track down errors. Patch applied, thanks. From davem@davemloft.net Tue May 3 14:39:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:39:36 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LdY7J016531 for ; Tue, 3 May 2005 14:39:34 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4wG-0002V8-00; Tue, 03 May 2005 14:28:20 -0700 Date: Tue, 3 May 2005 14:28:20 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/3] [RTNETLINK] Fix & cleanup rtm_min/rtm_max Message-Id: <20050503142820.7a436e58.davem@davemloft.net> In-Reply-To: <20050430195202.GD577@postel.suug.ch> References: <20050430195202.GD577@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 623 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 30 Apr 2005 21:52:02 +0200 Thomas Graf wrote: > Converts rtm_min and rtm_max arrays to use c99 designated > initializers for easier insertion of new message families. > RTM_GETMULTICAST and RTM_GETANYCAST did not have the minimal > message size specified which means that the netlink message > was parsed for routing attributes starting from the header. > Adds the proper minimal message sizes for these messages > (netlink header + common rtnetlink header) to fix this issue. > > Signed-off-by: Thomas Graf Applied, thanks Thomas. From davem@davemloft.net Tue May 3 14:40:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:40:11 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Le87J016865 for ; Tue, 3 May 2005 14:40:08 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4wp-0002VO-00; Tue, 03 May 2005 14:28:55 -0700 Date: Tue, 3 May 2005 14:28:54 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 3/3] [RTNETLINK] Cleanup rtnetlink_link tables Message-Id: <20050503142854.7097daec.davem@davemloft.net> In-Reply-To: <20050430195243.GE577@postel.suug.ch> References: <20050430195243.GE577@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 624 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 30 Apr 2005 21:52:43 +0200 Thomas Graf wrote: > Converts remaining rtnetlink_link tables to use c99 designated > initializers to make greping a little bit easier. > > Signed-off-by: Thomas Graf Applied, thanks a lot. From mchan@broadcom.com Tue May 3 14:40:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:40:24 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LeJ7J016968 for ; Tue, 3 May 2005 14:40:19 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 03 May 2005 14:40:12 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 3 May 2005 14:39:45 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AWG12822; Tue, 3 May 2005 14:39:45 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA20331; Tue, 3 May 2005 14:39:44 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 May 2005 21:39:44 +0000 Received: from rh4 by nt-irva-0741; 03 May 2005 13:41:47 -0700 Subject: Re: Mystery packet killing tg3 From: "Michael Chan" To: "David S. Miller" cc: "Stephen Hemminger" , jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <20050503141314.441c9d75.davem@davemloft.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> Date: Tue, 03 May 2005 13:41:47 -0700 Message-ID: <1115152907.15156.26.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E6930361MW1668191-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 625 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev On Tue, 2005-05-03 at 14:13 -0700, David S. Miller wrote: > On Tue, 3 May 2005 14:05:28 -0700 > Stephen Hemminger wrote: > > > 00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) (prog-if 10 [IO-APIC]) > > Buggy 8131 APIC, does the drivers/pci/quirks.c:quirk_amd_8131_ioapic() > message: > > PCI: MSI quirk detected. pci_msi_quirk set. > > trigger? MSI support recently got added to the tg3.c driver, but it should > only register MSI interrupt handling if pci_enable_msi() returns zero. > > See what it ends up doing, or if you even have a MSI capable tg3.c in > your kernel. > > MSI is buggy on 5703 and tg3 will not enable MSI on that chip. MSI only works on the latest PCI Express chips. From davem@davemloft.net Tue May 3 14:42:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:42:05 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Lg37J018239 for ; Tue, 3 May 2005 14:42:03 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT4yc-0002Vq-00; Tue, 03 May 2005 14:30:46 -0700 Date: Tue, 3 May 2005 14:30:46 -0700 From: "David S. Miller" To: Andrew Grover Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Add more explanation to tcp_prequeue comment Message-Id: <20050503143046.6f514dc9.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 626 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 28 Apr 2005 14:14:13 -0700 Andrew Grover wrote: > Here's a patch to make that prequeue comment a little clearer. Look ok? Looks great, except that it does not apply cleanly. From davem@davemloft.net Tue May 3 14:44:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:44:32 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Li87J018919 for ; Tue, 3 May 2005 14:44:08 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT50U-0002Wn-00; Tue, 03 May 2005 14:32:42 -0700 Date: Tue, 3 May 2005 14:32:42 -0700 From: "David S. Miller" To: Arnaldo Carvalho de Melo Cc: juhl-lkml@dif.dk, netdev@oss.sgi.com, reginak@cyclades.com, pc300@cyclades.com, ncorbic@sangoma.com, eis@baty.hanse.de, linux-net@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] cleanups in drivers/net/wan/ - kfree of NULL pointer is valid Message-Id: <20050503143242.3d06f71f.davem@davemloft.net> In-Reply-To: <20050428222330.GI26945@conectiva.com.br> References: <20050428222330.GI26945@conectiva.com.br> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 627 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 28 Apr 2005 19:23:30 -0300 Arnaldo Carvalho de Melo wrote: > Em Fri, Apr 29, 2005 at 12:22:22AM +0200, Jesper Juhl escreveu: > > kfree(0) is perfectly valid, checking pointers for NULL before calling > > kfree() on them is redundant. The patch below cleans away a few such > > redundant checks (and while I was around some of those bits I couldn't > > stop myself from making a few tiny whitespace changes as well). > > > Acked-by: Arnaldo Carvalho de MElo Applied, thanks everyone. From davem@davemloft.net Tue May 3 14:47:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:47:38 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43LlZ7J019718 for ; Tue, 3 May 2005 14:47:35 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT541-0002ZW-00; Tue, 03 May 2005 14:36:21 -0700 Date: Tue, 3 May 2005 14:36:20 -0700 From: "David S. Miller" To: folkert@vanheusden.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH] optimize check in port-allocation code Message-Id: <20050503143620.43cac50f.davem@davemloft.net> In-Reply-To: <20050428212449.GC8774@vanheusden.com> References: <20050420184419.GM20290@vanheusden.com> <20050424190427.11b4863e.davem@davemloft.net> <20050425061210.GB15167@vanheusden.com> <20050428120824.6cc9b345.davem@davemloft.net> <20050428212449.GC8774@vanheusden.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 628 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Thu, 28 Apr 2005 23:24:53 +0200 folkert@vanheusden.com wrote: > > > I'll resend it as an attachment (see attachment). > > It still has spaces where there should be tabs, even though > > you compressed the patch and used attachment. > > The diff itself must already be corrupt before you attach > > it. > > Please double check that the patch you submit actually apply, > > this will save me a lot of wasted time. > > Ok, I've redone them and tested if they patch cleanly, they now do. > See them attached. Both patches applied, thanks a lot. From davem@davemloft.net Tue May 3 14:48:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:48:46 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Lmf7J020088 for ; Tue, 3 May 2005 14:48:42 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT554-0002aJ-00; Tue, 03 May 2005 14:37:26 -0700 Date: Tue, 3 May 2005 14:37:26 -0700 From: "David S. Miller" To: Jesper Juhl Cc: paulus@samba.org, linux-ppp@vger.kernel.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ppp: remove redundant NULL pointer checks before kfree & vfree Message-Id: <20050503143726.63758ce3.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 629 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 29 Apr 2005 00:54:44 +0200 (CEST) Jesper Juhl wrote: > kfree() and vfree() can both deal with NULL pointers. This patch removes > redundant NULL pointer checks from the ppp code in drivers/net/ > > Signed-off-by: Jesper Juhl Applied, thanks Jesper. From davem@davemloft.net Tue May 3 14:50:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:50:50 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Lol7J020800 for ; Tue, 3 May 2005 14:50:47 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT574-0002bw-00; Tue, 03 May 2005 14:39:30 -0700 Date: Tue, 3 May 2005 14:39:30 -0700 From: "David S. Miller" To: Asim Shankar Cc: netdev@oss.sgi.com Subject: Re: [RESEND] [PATCH 2.6.11.7] sch_htb: Drop packet when direct queue is full Message-Id: <20050503143930.28650cba.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 630 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 29 Apr 2005 17:33:12 +0000 (UTC) Asim Shankar wrote: > htb_enqueue(): Free skb and return NET_XMIT_DROP if a packet is > destined for the direct_queue but the direct_queue is full. (Before > this: erroneously returned NET_XMIT_SUCCESS even though the packet was > not enqueued) > > Signed-off-by: Asim Shankar Applied, thanks Asim. From davem@davemloft.net Tue May 3 14:51:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:51:56 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Lpq7J021208 for ; Tue, 3 May 2005 14:51:52 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT584-0002cr-00; Tue, 03 May 2005 14:40:32 -0700 Date: Tue, 3 May 2005 14:40:32 -0700 From: "David S. Miller" To: Patrick McHardy Cc: tgraf@suug.ch, nicolas.dichtel@6wind.com, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Question about QOS Message-Id: <20050503144032.25ea921d.davem@davemloft.net> In-Reply-To: <427225B2.6010705@trash.net> References: <426E06F1.9000105@6wind.com> <20050426125955.GT577@postel.suug.ch> <426E56DC.7000108@6wind.com> <20050426191454.GU577@postel.suug.ch> <426F42F0.9020609@6wind.com> <20050427114216.GV577@postel.suug.ch> <427225B2.6010705@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 631 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 29 Apr 2005 14:16:50 +0200 Patrick McHardy wrote: > Thomas Graf wrote: > > * Nicolas DICHTEL <426F42F0.9020609@6wind.com> 2005-04-27 09:44 > > > >>>Yes I agree, it doesn't really matter what value we return and `bound' > >>>is most likely to be correct. I think we should also fix the unlikely > >>>but still possible case when tv1.tv_usec is slightly smaller than > >>>tv2.tv_usec. I know it is very unlikely but do_gettimeofday really > >>>is not that reliable and we have users which rely on a positive > >>>delta. Can you extend your patch to return abs(delta) for case 0 > >>>in PSCHED_TDIFF_SAFE? > > Why abs(delta)? It could be above bound, in fact all cases besides > delta_sec > 2 doesn't take care to stay inside [0..bound] at all. Applied, thanks Patrick. From davem@davemloft.net Tue May 3 14:52:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:52:57 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Lqs7J021708 for ; Tue, 3 May 2005 14:52:54 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT58m-0002cv-00; Tue, 03 May 2005 14:41:16 -0700 Date: Tue, 3 May 2005 14:41:15 -0700 From: "David S. Miller" To: Sridhar Samudrala Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.4 6/6][SCTP] Fix SCTP sendbuffer accouting. Message-Id: <20050503144115.0d03ae87.davem@davemloft.net> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 632 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Sridhar, I will apply all of these as soon as Marcelo has his GIT tree setup for the 2.4.x kernel. They all look perfectly fine and thanks for remembering to update the default sysctl setting for socket based accounting. From davem@davemloft.net Tue May 3 14:54:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 14:54:09 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Ls57J022274 for ; Tue, 3 May 2005 14:54:05 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT5AC-0002eQ-00; Tue, 03 May 2005 14:42:44 -0700 Date: Tue, 3 May 2005 14:42:44 -0700 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [NETLINK] cb_lock does not needs ref count on sk Message-Id: <20050503144244.1efdfd0c.davem@davemloft.net> In-Reply-To: <20050401093633.GA32707@gondor.apana.org.au> References: <20050327091524.GA23215@elte.hu> <20050327133811.GA5569@elte.hu> <20050329104906.GA19836@gondor.apana.org.au> <20050329114926.GA14986@elte.hu> <20050330082640.GA8269@gondor.apana.org.au> <20050330170236.2bddf666.davem@davemloft.net> <20050331231922.GA26587@gondor.apana.org.au> <20050331232322.GA26693@gondor.apana.org.au> <20050331203313.57e1c5c3.davem@davemloft.net> <20050401093633.GA32707@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Fri, 1 Apr 2005 19:36:33 +1000 Herbert Xu wrote: > Here is a little optimisation for the cb_lock used by netlink_dump. > While fixing that race earlier, I noticed that the reference count > held by cb_lock is completely useless. The reason is that in order > to obtain the protection of the reference count, you have to take > the cb_lock. But the only way to take the cb_lock is through > dereferencing the socket. > > That is, you must already possess a reference count on the socket > before you can take advantage of the reference count held by cb_lock. > As a corollary, we can remve the reference count held by the cb_lock. > > Signed-off-by: Herbert Xu Looks good, applied. From davem@davemloft.net Tue May 3 15:14:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:14:54 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MEo7J023977 for ; Tue, 3 May 2005 15:14:51 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT5UL-0002rN-00; Tue, 03 May 2005 15:03:33 -0700 Date: Tue, 3 May 2005 15:03:33 -0700 From: "David S. Miller" To: "Michael Chan" Cc: shemminger@osdl.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-Id: <20050503150333.1ac1c159.davem@davemloft.net> In-Reply-To: <1115152907.15156.26.camel@rh4> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> <1115152907.15156.26.camel@rh4> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 634 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 03 May 2005 13:41:47 -0700 "Michael Chan" wrote: > MSI is buggy on 5703 and tg3 will not enable MSI on that chip. MSI only > works on the latest PCI Express chips. Ok, and he has a pre-MSI copy of the tg3 driver anyways. Michael, there were no master/target abort bits set in the PCI status register from his dump. If one of the DMA units locks up on the tg3, will it still be able to update the PCI_STATUS register appropriately when it encounters a DMA transaction error (ie. master or target abort) or would we also need to look at the PCI host bridge PCI config space registers as well? I strongly suspect one of two things in these AMD system cases of tg3 wedging: 1) some DMA problem 2) register write reordering Lack of master/target abort indication in tg3's PCI status register makes me feel that #2 is more likely to be the problem cause. Just for fun, Stephen, can you make tg3_get_invariants() always set the TG3_FLAG_MBOX_WRITE_REORDER bit in tp->tg3_flags and see if that makes the problem go away? Thanks. From tgraf@suug.ch Tue May 3 15:19:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:20:01 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MJu7J024679 for ; Tue, 3 May 2005 15:19:57 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id B2CDB1C0EB; Wed, 4 May 2005 00:20:03 +0200 (CEST) Date: Wed, 4 May 2005 00:20:03 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/3] [RTNETLINK] Fix RTM_MAX to represent the maximum valid message type Message-ID: <20050503222003.GQ577@postel.suug.ch> References: <20050430195058.GC577@postel.suug.ch> <20050503142740.345925ea.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503142740.345925ea.davem@davemloft.net> X-archive-position: 635 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * David S. Miller <20050503142740.345925ea.davem@davemloft.net> 2005-05-03 14:27 > Excellent observation. The fact that we encode the "modifies state" > in the low bits of the RTM_* numbers has always been a source of > obscure bugs and hard to track down errors. > > Patch applied, thanks. Do you want 2.4 backports for all patches or just the xfrm off-by-one fix? From mchan@broadcom.com Tue May 3 15:26:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:26:42 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MQd7J025434 for ; Tue, 3 May 2005 15:26:40 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 03 May 2005 15:26:25 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 3 May 2005 15:26:12 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AWG24966; Tue, 3 May 2005 15:26:08 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA05094; Tue, 3 May 2005 15:26:08 -0700 (PDT) Received: from 10.7.17.55 ([10.7.17.55]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 May 2005 22:26:07 +0000 Received: from rh4 by nt-irva-0741; 03 May 2005 14:28:10 -0700 Subject: Re: Mystery packet killing tg3 From: "Michael Chan" To: "David S. Miller" cc: shemminger@osdl.org, jgarzik@pobox.com, netdev@oss.sgi.com In-Reply-To: <20050503150333.1ac1c159.davem@davemloft.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> <1115152907.15156.26.camel@rh4> <20050503150333.1ac1c159.davem@davemloft.net> Date: Tue, 03 May 2005 14:28:10 -0700 Message-ID: <1115155690.15156.32.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E69251B0UW1602596-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 636 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev On Tue, 2005-05-03 at 15:03 -0700, David S. Miller wrote: > Michael, there were no master/target abort bits set in the PCI status > register from his dump. If one of the DMA units locks up on the tg3, > will it still be able to update the PCI_STATUS register appropriately > when it encounters a DMA transaction error (ie. master or target abort) I believe so. Also, the DMA read and write status registers showed all zeros, meaning there were no DMA related errors: DEBUG: RDMAC_MODE[000003fc] RDMAC_STATUS[00000000] DEBUG: WDMAC_MODE[000003fc] WDMAC_STATUS[00000000] From tommy.christensen@tpack.net Tue May 3 15:31:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:31:19 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j43MVF7J026089 for ; Tue, 3 May 2005 15:31:16 -0700 Received: (qmail 6494 invoked from network); 3 May 2005 22:31:00 -0000 Received: from unknown (HELO ?172.17.159.11?) (192.168.111.6) by 0 with SMTP; 3 May 2005 22:31:00 -0000 Message-ID: <4277FC16.4050307@tpack.net> Date: Wed, 04 May 2005 00:32:54 +0200 From: Tommy Christensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) References: <4276B13F.2040103@tpack.net> <20050503100306.GB29788@gondor.apana.org.au> In-Reply-To: <20050503100306.GB29788@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------060107070809070404040805" X-archive-position: 637 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------060107070809070404040805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > Doing the wait when IFF_RUNNING is off isn't necessary though. If > IFF_RUNNING isn't set, then either the device has never been activated > or we've already carried out those waits the last time we were in > dev_deactivate. Right. But it still depends on what the synchronization is meant to protect us from. It isn't clear to me, whether it's o packets in flight o qdisc references o device references so yes, I tried to play it safe. Anyway, given the comments from Thomas, I've pulled out the IFF_RUNNING stuff. We can add this later, when the other uses have been sorted out. > I understand your preference for defensive programming. However, in > cases like this it's better to do the obvious thing because: > > 1) We don't cover up bugs that may come back to bite us elsewhere. > 2) We don't give people misconceptions. If they're unfamiliar with > the system they may infer things from this code that aren't necessarily > the case. I totally agree with this. -Tommy --------------060107070809070404040805 Content-Type: text/plain; name="carrier-5.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="carrier-5.patch" diff -ru linux-2.6.12-rc3/net/core/link_watch.c linux-2.6.12-work/net/core/link_watch.c --- linux-2.6.12-rc3/net/core/link_watch.c 2005-03-04 09:55:42.000000000 +0100 +++ linux-2.6.12-work/net/core/link_watch.c 2005-05-02 22:40:59.000000000 +0200 @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -74,6 +75,12 @@ clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); if (dev->flags & IFF_UP) { + if (netif_carrier_ok(dev)) { + WARN_ON(dev->qdisc_sleeping == &noop_qdisc); + dev_activate(dev); + } else + dev_deactivate(dev); + netdev_state_change(dev); } diff -ru linux-2.6.12-rc3/net/sched/sch_generic.c linux-2.6.12-work/net/sched/sch_generic.c --- linux-2.6.12-rc3/net/sched/sch_generic.c 2005-03-04 09:55:44.000000000 +0100 +++ linux-2.6.12-work/net/sched/sch_generic.c 2005-05-04 00:24:55.558105856 +0200 @@ -539,6 +539,10 @@ write_unlock_bh(&qdisc_tree_lock); } + if (!netif_carrier_ok(dev)) + /* Delay activation until next carrier-on event */ + return; + spin_lock_bh(&dev->queue_lock); rcu_assign_pointer(dev->qdisc, dev->qdisc_sleeping); if (dev->qdisc != &noqueue_qdisc) { --------------060107070809070404040805-- From davem@davemloft.net Tue May 3 15:38:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:38:27 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43McN7J026725 for ; Tue, 3 May 2005 15:38:24 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT5r6-00036a-00; Tue, 03 May 2005 15:27:04 -0700 Date: Tue, 3 May 2005 15:27:04 -0700 From: "David S. Miller" To: Thomas Graf Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/3] [RTNETLINK] Fix RTM_MAX to represent the maximum valid message type Message-Id: <20050503152704.4c6744d6.davem@davemloft.net> In-Reply-To: <20050503222003.GQ577@postel.suug.ch> References: <20050430195058.GC577@postel.suug.ch> <20050503142740.345925ea.davem@davemloft.net> <20050503222003.GQ577@postel.suug.ch> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 638 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 4 May 2005 00:20:03 +0200 Thomas Graf wrote: > * David S. Miller <20050503142740.345925ea.davem@davemloft.net> 2005-05-03 14:27 > > Excellent observation. The fact that we encode the "modifies state" > > in the low bits of the RTM_* numbers has always been a source of > > obscure bugs and hard to track down errors. > > > > Patch applied, thanks. > > Do you want 2.4 backports for all patches or just the xfrm > off-by-one fix? Congratulations if you can find xfrm in the vanilla 2.4.x tree :-) From kaber@trash.net Tue May 3 15:41:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:41:26 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MfM7J027259 for ; Tue, 3 May 2005 15:41:23 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT64b-0005HH-9q; Wed, 04 May 2005 00:41:01 +0200 Message-ID: <4277FDFD.3040501@trash.net> Date: Wed, 04 May 2005 00:41:01 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: Fw: [Bug 4554] New: /proc/net/route missing info for 127.0.0.1/8 References: <20050503143603.4d77d3dd@dxpl.pdx.osdl.net> In-Reply-To: <20050503143603.4d77d3dd@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 639 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev > Distribution: CentOS 4 (RHEL4) > Hardware Environment: i686 > Problem Description: > cat /proc/net/route is missing information for 127.0.0.1/8 network (lo > interface). On 2.4 kernels, this info was present (just checked on an old RH7.3 > machine). It seems to be missing on 2.6 kernels. Bug? Feature? Omission? 2.4.30 doesn't show it: # route -n Destination Gateway Genmask Flags Metric Ref Use Iface 172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 And I'd be surprised if it did, it doesn't include other routes from the local table. Regards Patrick From shemminger@osdl.org Tue May 3 15:45:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:45:20 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MjG7J027930 for ; Tue, 3 May 2005 15:45:16 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43Mj1s4027705 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 15:45:01 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43Mj03M021716; Tue, 3 May 2005 15:45:00 -0700 Date: Tue, 3 May 2005 15:45:00 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: "Michael Chan" , jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050503154500.0a53160d@dxpl.pdx.osdl.net> In-Reply-To: <20050503150333.1ac1c159.davem@davemloft.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> <1115152907.15156.26.camel@rh4> <20050503150333.1ac1c159.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 640 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Tue, 3 May 2005 15:03:33 -0700 "David S. Miller" wrote: > On Tue, 03 May 2005 13:41:47 -0700 > "Michael Chan" wrote: > > > MSI is buggy on 5703 and tg3 will not enable MSI on that chip. MSI only > > works on the latest PCI Express chips. > > Ok, and he has a pre-MSI copy of the tg3 driver anyways. > > Michael, there were no master/target abort bits set in the PCI status > register from his dump. If one of the DMA units locks up on the tg3, > will it still be able to update the PCI_STATUS register appropriately > when it encounters a DMA transaction error (ie. master or target abort) > or would we also need to look at the PCI host bridge PCI config space > registers as well? > > I strongly suspect one of two things in these AMD system cases of tg3 > wedging: > > 1) some DMA problem > 2) register write reordering > > Lack of master/target abort indication in tg3's PCI status register > makes me feel that #2 is more likely to be the problem cause. > > Just for fun, Stephen, can you make tg3_get_invariants() always set > the TG3_FLAG_MBOX_WRITE_REORDER bit in tp->tg3_flags and see if that > makes the problem go away? No, I forced it to always be true and still dies (when taking network down). From shemminger@osdl.org Tue May 3 15:47:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:47:29 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MlN7J028643 for ; Tue, 3 May 2005 15:47:25 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43Ml9s4027974 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 15:47:09 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43Ml90C021970; Tue, 3 May 2005 15:47:09 -0700 Date: Tue, 3 May 2005 15:47:09 -0700 From: Stephen Hemminger To: Patrick McHardy Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [Bug 4554] New: /proc/net/route missing info for 127.0.0.1/8 Message-ID: <20050503154709.218626c6@dxpl.pdx.osdl.net> In-Reply-To: <4277FDFD.3040501@trash.net> References: <20050503143603.4d77d3dd@dxpl.pdx.osdl.net> <4277FDFD.3040501@trash.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 641 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Wed, 04 May 2005 00:41:01 +0200 Patrick McHardy wrote: > > Distribution: CentOS 4 (RHEL4) > > Hardware Environment: i686 > > Problem Description: > > cat /proc/net/route is missing information for 127.0.0.1/8 network (lo > > interface). On 2.4 kernels, this info was present (just checked on an old RH7.3 > > machine). It seems to be missing on 2.6 kernels. Bug? Feature? Omission? > > 2.4.30 doesn't show it: > > # route -n > Destination Gateway Genmask Flags Metric Ref Use > Iface > 172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 > > And I'd be surprised if it did, it doesn't include other routes > from the local table. > > Regards > Patrick It shows up on our 2.4.18 system, probably it got lost in the fib/seq_printf conversion. $ /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.159.0 172.20.4.11 255.255.255.0 UG 0 0 0 eth2 172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth2 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 172.20.0.1 0.0.0.0 UG 0 0 0 eth2 From davem@davemloft.net Tue May 3 15:51:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:51:29 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MpD7J029227 for ; Tue, 3 May 2005 15:51:25 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT63W-0003DL-00; Tue, 03 May 2005 15:39:54 -0700 Date: Tue, 3 May 2005 15:39:54 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: mchan@broadcom.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-Id: <20050503153954.6be62f8a.davem@davemloft.net> In-Reply-To: <20050503154500.0a53160d@dxpl.pdx.osdl.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> <1115152907.15156.26.camel@rh4> <20050503150333.1ac1c159.davem@davemloft.net> <20050503154500.0a53160d@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 642 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 3 May 2005 15:45:00 -0700 Stephen Hemminger wrote: > No, I forced it to always be true and still dies (when taking network down). You're reproducing this pretty fast. Does the link jam up, or are you just simply downing the interface and the stop block messages are printed out? If it jams up, what kind of traffic are you using to trigger this problem? From arnaldo.melo@gmail.com Tue May 3 15:55:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:55:34 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MtU7J029832 for ; Tue, 3 May 2005 15:55:30 -0700 Received: by zproxy.gmail.com with SMTP id 8so70799nzo for ; Tue, 03 May 2005 15:55:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EssaBc0T4Oa4KTpnaaDKfe94z3pCBm6L+6fbFu/4k+h4D+j5rSCJX2KjQ/WSADrS7ySTCmsMofWgCqUcu6rQpO+Uc0Z67wgB6agiRKCD9/kntyki3zKJzwjQ29YlFJEJ7DKaKRHzJTk0I9+QhpdzG8Oj6Hi/yEuZG0aMKHvt7R8= Received: by 10.36.61.5 with SMTP id j5mr50102nza; Tue, 03 May 2005 15:55:15 -0700 (PDT) Received: by 10.36.56.15 with HTTP; Tue, 3 May 2005 15:55:15 -0700 (PDT) Message-ID: <39e6f6c70505031555691daf80@mail.gmail.com> Date: Tue, 3 May 2005 19:55:15 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@ghostprotocols.net To: Stephen Hemminger Subject: Re: [Bug 4554] New: /proc/net/route missing info for 127.0.0.1/8 Cc: Patrick McHardy , "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050503154709.218626c6@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050503143603.4d77d3dd@dxpl.pdx.osdl.net> <4277FDFD.3040501@trash.net> <20050503154709.218626c6@dxpl.pdx.osdl.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j43MtU7J029832 X-archive-position: 643 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev On 5/3/05, Stephen Hemminger wrote: > On Wed, 04 May 2005 00:41:01 +0200 > Patrick McHardy wrote: > > > > Distribution: CentOS 4 (RHEL4) > > > Hardware Environment: i686 > > > Problem Description: > > > cat /proc/net/route is missing information for 127.0.0.1/8 network (lo > > > interface). On 2.4 kernels, this info was present (just checked on an old RH7.3 > > > machine). It seems to be missing on 2.6 kernels. Bug? Feature? Omission? > > > > 2.4.30 doesn't show it: > > > > # route -n > > Destination Gateway Genmask Flags Metric Ref Use > > Iface > > 172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 > > > > And I'd be surprised if it did, it doesn't include other routes > > from the local table. > > > > Regards > > Patrick > > It shows up on our 2.4.18 system, probably it got lost in the fib/seq_printf > conversion. > > $ /sbin/route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 192.168.159.0 172.20.4.11 255.255.255.0 UG 0 0 0 eth2 > 172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth2 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo > 0.0.0.0 172.20.0.1 0.0.0.0 UG 0 0 0 eth2 [root@toy acme]# route -n Tabela de Roteamento IP do Kernel Destino Roteador MáscaraGen. Opções Métrica Ref Uso Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 0 eth0 [root@toy acme]# uname -r 2.6.11-77124cl [root@toy acme]# [root@toy acme]# ip r s 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.192 172.20.0.0/16 dev tun0 proto kernel scope link src 172.20.0.1 127.0.0.0/8 dev lo scope link default via 192.168.1.2 dev eth0 [root@toy acme]# [root@toy acme]# cat /proc/net/route Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT eth0 0001A8C0 00000000 0001 0 0 0 00FFFFFF 0 0 0 tun0 000014AC 00000000 0001 0 0 0 0000FFFF 0 0 0 lo 0000007F 00000000 0001 0 0 0 000000FF 0 0 0 eth0 00000000 0201A8C0 0003 0 0 0 00000000 0 0 0 [root@toy acme]# No problems here. - Arnaldo From kaber@trash.net Tue May 3 15:58:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:58:49 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Mwj7J030458 for ; Tue, 3 May 2005 15:58:45 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT6LQ-0005jH-9G; Wed, 04 May 2005 00:58:24 +0200 Message-ID: <42780210.2070607@trash.net> Date: Wed, 04 May 2005 00:58:24 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [Bug 4554] New: /proc/net/route missing info for 127.0.0.1/8 References: <20050503143603.4d77d3dd@dxpl.pdx.osdl.net> <4277FDFD.3040501@trash.net> <20050503154709.218626c6@dxpl.pdx.osdl.net> In-Reply-To: <20050503154709.218626c6@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 644 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Stephen Hemminger wrote: > It shows up on our 2.4.18 system, probably it got lost in the fib/seq_printf > conversion. > > $ /sbin/route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 192.168.159.0 172.20.4.11 255.255.255.0 UG 0 0 0 eth2 > 172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth2 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo > 0.0.0.0 172.20.0.1 0.0.0.0 UG 0 0 0 eth2 2.4.18 looks similar to 2.4.30 in fib_get_procinfo(), fib_magic() and other functions involved. I believe its simply a change of how userspace sets up the routes: # route -n 172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 172.16.0.1 0.0.0.0 UG 0 0 0 eth0 # route add -net 127.0.0.0/8 lo # route -n 172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 172.16.0.1 0.0.0.0 UG 0 0 0 eth0 "route" seems to add all routes to the main table. My debian system relies on the kernel setting up loopback correctly, so it doesn't add a route itself. Regards Patrick From shemminger@osdl.org Tue May 3 15:59:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 15:59:32 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43MxR7J030564 for ; Tue, 3 May 2005 15:59:27 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43MxBs4028946 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 15:59:12 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43MxBfU022627; Tue, 3 May 2005 15:59:11 -0700 Date: Tue, 3 May 2005 15:59:11 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: mchan@broadcom.com, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-ID: <20050503155911.766409c3@dxpl.pdx.osdl.net> In-Reply-To: <20050503153954.6be62f8a.davem@davemloft.net> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> <1115152907.15156.26.camel@rh4> <20050503150333.1ac1c159.davem@davemloft.net> <20050503154500.0a53160d@dxpl.pdx.osdl.net> <20050503153954.6be62f8a.davem@davemloft.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 645 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Tue, 3 May 2005 15:39:54 -0700 "David S. Miller" wrote: > On Tue, 3 May 2005 15:45:00 -0700 > Stephen Hemminger wrote: > > > No, I forced it to always be true and still dies (when taking network down). > > You're reproducing this pretty fast. > > Does the link jam up, or are you just simply downing the interface > and the stop block messages are printed out? Initially, it reproduced everytime link came up, we reconfigured the VLAN to have a mirror port into a laptop to try and capture what was happening, but when we did that the bootup problem went away. It was in the tg3_reset_hw during initial dev_open. Today it only triggers when I force it by doing something does a dev_close (like ifconfig or rmmod). Since the message is the same, I assume it is the same or similar problem. > If it jams up, what kind of traffic are you using to trigger this > problem? No traffic is present when the close occurs. But some DMA could be stuck (forever) in flight at that point. From tgraf@suug.ch Tue May 3 16:02:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:02:13 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43N297J031696 for ; Tue, 3 May 2005 16:02:09 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 186A01C0EB; Wed, 4 May 2005 01:02:18 +0200 (CEST) Date: Wed, 4 May 2005 01:02:17 +0200 From: Thomas Graf To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/3] [RTNETLINK] Fix RTM_MAX to represent the maximum valid message type Message-ID: <20050503230217.GR577@postel.suug.ch> References: <20050430195058.GC577@postel.suug.ch> <20050503142740.345925ea.davem@davemloft.net> <20050503222003.GQ577@postel.suug.ch> <20050503152704.4c6744d6.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503152704.4c6744d6.davem@davemloft.net> X-archive-position: 646 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * David S. Miller <20050503152704.4c6744d6.davem@davemloft.net> 2005-05-03 15:27 > On Wed, 4 May 2005 00:20:03 +0200 > Thomas Graf wrote: > > > * David S. Miller <20050503142740.345925ea.davem@davemloft.net> 2005-05-03 14:27 > > > Excellent observation. The fact that we encode the "modifies state" > > > in the low bits of the RTM_* numbers has always been a source of > > > obscure bugs and hard to track down errors. > > > > > > Patch applied, thanks. > > > > Do you want 2.4 backports for all patches or just the xfrm > > off-by-one fix? > > Congratulations if you can find xfrm in the vanilla > 2.4.x tree :-) Heh, ok ok ;-> I think none of the patches need to be backported then, although the type > RTM_MAX has an off-by-one issue the current RTM_MAX is set to one below the start of the next block so the behaviour matches the 2.6 tree. From davem@davemloft.net Tue May 3 16:05:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:05:19 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43N5F7J032273 for ; Tue, 3 May 2005 16:05:15 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6H6-0003Js-00; Tue, 03 May 2005 15:53:56 -0700 Date: Tue, 3 May 2005 15:53:55 -0700 From: "David S. Miller" To: "Michael Chan" Cc: shemminger@osdl.org, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: Mystery packet killing tg3 Message-Id: <20050503155355.6ac3f4a6.davem@davemloft.net> In-Reply-To: <1115155690.15156.32.camel@rh4> References: <20050502162405.65dfb4a9@localhost.localdomain> <20050502200251.38271b61.davem@davemloft.net> <20050503140528.1bd2ac74@dxpl.pdx.osdl.net> <20050503141314.441c9d75.davem@davemloft.net> <1115152907.15156.26.camel@rh4> <20050503150333.1ac1c159.davem@davemloft.net> <1115155690.15156.32.camel@rh4> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 647 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 03 May 2005 14:28:10 -0700 "Michael Chan" wrote: > On Tue, 2005-05-03 at 15:03 -0700, David S. Miller wrote: > > > Michael, there were no master/target abort bits set in the PCI status > > register from his dump. If one of the DMA units locks up on the tg3, > > will it still be able to update the PCI_STATUS register appropriately > > when it encounters a DMA transaction error (ie. master or target abort) > > I believe so. Also, the DMA read and write status registers showed all > zeros, meaning there were no DMA related errors: > > DEBUG: RDMAC_MODE[000003fc] RDMAC_STATUS[00000000] > DEBUG: WDMAC_MODE[000003fc] WDMAC_STATUS[00000000] Right, I noticed that too. Stephen says that trying to force enable the mailbox write reordering workaround doesn't solve the problem either. I wonder exactly how it would show up if the x86_64 port unmapped a DMA address in the IOMMU and tg3 (or a bridge in the middle) tried to fetch that address again. I remember some issue not too long ago where PCI bridges could still prefetch a DMA address even after a device was done with it. Because of this, they added code to the x86_64 IOMMU driver that kept a read-only dummy mapping around all the time so that this would not cause faults. I even added similar code to the PCI IOMMU handling on sparc64. Indeed, if you look in arch/x86_64/kernel/pci-gart.c they use a scratch mapping when the unmap DMA translations. I can't think of what else could be wedging the tg3. Michael, any ideas? There are some 5703 specific programming to consider: 1) Setting of PCIX_CAPS_BURST_MASK in PCI_X_CAPS register. Currently tg3 sets it to "PCIX_CAPS_MAX_BURST_CPIOB" which is 2 (shifted up PCIX_CAPS_BURST_SHIFT of course). 2) On Fibre, we force a write of 0x616000 to MAC_SERDES_CFG for 5703 chips. Because the PCS synced indication is on in his dumps, I am assuming he is on a Fibre link, so this is relevant. 3) When the low 5 bits of TG3PCI_CLOCK_CTRL are 0x6 or 0x7 we set DMA_RWCTL_ONE_DMA in the DMA R/W control register. On all 5703 we also set bit 23 to enable some hw bug workaround. 4) On 5703 (and 5704), we always clear the low 4 bits of DMA R/W control. A quick perusal shows that these same exact things get done in the bcm5700 driver too. From tgraf@suug.ch Tue May 3 16:08:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:08:22 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43N8G7J000429 for ; Tue, 3 May 2005 16:08:19 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 46F211C0EB; Wed, 4 May 2005 01:08:24 +0200 (CEST) Date: Wed, 4 May 2005 01:08:24 +0200 From: Thomas Graf To: acme@ghostprotocols.net Cc: Stephen Hemminger , Patrick McHardy , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [Bug 4554] New: /proc/net/route missing info for 127.0.0.1/8 Message-ID: <20050503230824.GS577@postel.suug.ch> References: <20050503143603.4d77d3dd@dxpl.pdx.osdl.net> <4277FDFD.3040501@trash.net> <20050503154709.218626c6@dxpl.pdx.osdl.net> <39e6f6c70505031555691daf80@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <39e6f6c70505031555691daf80@mail.gmail.com> X-archive-position: 648 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * Arnaldo Carvalho de Melo <39e6f6c70505031555691daf80@mail.gmail.com> 2005-05-03 19:55 > [root@toy acme]# route -n > Tabela de Roteamento IP do Kernel > Destino Roteador MáscaraGen. Opções Métrica Ref Uso Iface > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > 172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun0 > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo > 0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 0 eth0 > [root@toy acme]# uname -r > 2.6.11-77124cl > [root@toy acme]# > > [root@toy acme]# ip r s > 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.192 > 172.20.0.0/16 dev tun0 proto kernel scope link src 172.20.0.1 > 127.0.0.0/8 dev lo scope link > default via 192.168.1.2 dev eth0 Your distribution, scripts, whatever doesn't use the local table for the loopback route. This gets to be a problem once you add fib rules and rely on the fact that local routes should have top priority. > [root@toy acme]# > > [root@toy acme]# cat /proc/net/route > Iface Destination Gateway Flags RefCnt Use Metric > Mask MTU Window IRTT > eth0 0001A8C0 00000000 0001 0 0 0 > 00FFFFFF 0 0 0 > tun0 000014AC 00000000 0001 0 0 0 > 0000FFFF 0 0 0 > lo 0000007F 00000000 0001 0 0 0 > 000000FF 0 0 0 > eth0 00000000 0201A8C0 0003 0 0 0 > 00000000 0 0 0 > [root@toy acme]# Yes, that's the main routing table. This is a userspace issue. From herbert@gondor.apana.org.au Tue May 3 16:10:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:10:58 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NAn7J000853 for ; Tue, 3 May 2005 16:10:50 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DT6X4-0002ow-00; Wed, 04 May 2005 09:10:26 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DT6X1-0004lw-00; Wed, 04 May 2005 09:10:23 +1000 Date: Wed, 4 May 2005 09:10:23 +1000 To: Tommy Christensen Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) Message-ID: <20050503231023.GA18323@gondor.apana.org.au> References: <4276B13F.2040103@tpack.net> <20050503100306.GB29788@gondor.apana.org.au> <4277FC16.4050307@tpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4277FC16.4050307@tpack.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 649 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Wed, May 04, 2005 at 12:32:54AM +0200, Tommy Christensen wrote: > > Anyway, given the comments from Thomas, I've pulled out the IFF_RUNNING > stuff. We can add this later, when the other uses have been sorted out. Thanks Tommy. This version looks good to me. BTW, you probably should add a Signed-off-by line. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From davem@davemloft.net Tue May 3 16:22:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:22:13 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NMA7J005165 for ; Tue, 3 May 2005 16:22:10 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6XC-0003PT-00; Tue, 03 May 2005 16:10:34 -0700 Date: Tue, 3 May 2005 16:10:34 -0700 From: "David S. Miller" To: Herbert Xu Cc: tommy.christensen@tpack.net, netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) Message-Id: <20050503161034.1fc3ec38.davem@davemloft.net> In-Reply-To: <20050503231023.GA18323@gondor.apana.org.au> References: <4276B13F.2040103@tpack.net> <20050503100306.GB29788@gondor.apana.org.au> <4277FC16.4050307@tpack.net> <20050503231023.GA18323@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 650 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 4 May 2005 09:10:23 +1000 Herbert Xu wrote: > On Wed, May 04, 2005 at 12:32:54AM +0200, Tommy Christensen wrote: > > > > Anyway, given the comments from Thomas, I've pulled out the IFF_RUNNING > > stuff. We can add this later, when the other uses have been sorted out. > > Thanks Tommy. This version looks good to me. BTW, you probably > should add a Signed-off-by line. Yes, please provide this and I'll happily apply this patch. Thanks. From tommy.christensen@tpack.net Tue May 3 16:26:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:26:49 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j43NQi7J005769 for ; Tue, 3 May 2005 16:26:44 -0700 Received: (qmail 15375 invoked from network); 3 May 2005 23:26:30 -0000 Received: from unknown (HELO ?172.17.159.11?) (192.168.111.6) by 0 with SMTP; 3 May 2005 23:26:30 -0000 Message-ID: <42780918.10001@tpack.net> Date: Wed, 04 May 2005 01:28:24 +0200 From: Tommy Christensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) References: <4276B13F.2040103@tpack.net> <20050503100306.GB29788@gondor.apana.org.au> <4277FC16.4050307@tpack.net> <20050503231023.GA18323@gondor.apana.org.au> In-Reply-To: <20050503231023.GA18323@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------060507010509040804020203" X-archive-position: 651 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------060507010509040804020203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Herbert Xu wrote: > Thanks Tommy. This version looks good to me. BTW, you probably > should add a Signed-off-by line. Sigh. I remembered on all but the final patch ... Thanks for helping out. Signed-off-by: Tommy S. Christensen --------------060507010509040804020203 Content-Type: text/plain; name="carrier-5.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="carrier-5.patch" diff -ru linux-2.6.12-rc3/net/core/link_watch.c linux-2.6.12-work/net/core/link_watch.c --- linux-2.6.12-rc3/net/core/link_watch.c 2005-03-04 09:55:42.000000000 +0100 +++ linux-2.6.12-work/net/core/link_watch.c 2005-05-02 22:40:59.000000000 +0200 @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -74,6 +75,12 @@ clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state); if (dev->flags & IFF_UP) { + if (netif_carrier_ok(dev)) { + WARN_ON(dev->qdisc_sleeping == &noop_qdisc); + dev_activate(dev); + } else + dev_deactivate(dev); + netdev_state_change(dev); } diff -ru linux-2.6.12-rc3/net/sched/sch_generic.c linux-2.6.12-work/net/sched/sch_generic.c --- linux-2.6.12-rc3/net/sched/sch_generic.c 2005-03-04 09:55:44.000000000 +0100 +++ linux-2.6.12-work/net/sched/sch_generic.c 2005-05-04 00:24:55.558105856 +0200 @@ -539,6 +539,10 @@ write_unlock_bh(&qdisc_tree_lock); } + if (!netif_carrier_ok(dev)) + /* Delay activation until next carrier-on event */ + return; + spin_lock_bh(&dev->queue_lock); rcu_assign_pointer(dev->qdisc, dev->qdisc_sleeping); if (dev->qdisc != &noqueue_qdisc) { --------------060507010509040804020203-- From shemminger@osdl.org Tue May 3 16:27:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:27:43 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NRd7J006133 for ; Tue, 3 May 2005 16:27:40 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43NRLs4031825 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 16:27:21 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43NRL7d024965; Tue, 3 May 2005 16:27:21 -0700 Date: Tue, 3 May 2005 16:25:50 -0700 From: Stephen Hemminger To: "David S. Miller" , Patrick McHardy Cc: netdev@oss.sgi.com, netem@osdl.org Subject: [PATCH] (3/3) netem: adjust parent qlen when duplicating Message-ID: <20050503162550.30acf31a@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 653 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Fix qlen underrun when doing duplication with netem. If netem is used as leaf discipline, then the parent needs to be tweaked when packets are duplicated. Signed-off-by: Stephen Hemminger Index: netem-2.6.12-rc3/net/sched/sch_api.c =================================================================== --- netem-2.6.12-rc3.orig/net/sched/sch_api.c 2005-05-03 11:19:23.000000000 -0700 +++ netem-2.6.12-rc3/net/sched/sch_api.c 2005-05-03 15:20:59.000000000 -0700 @@ -1289,6 +1289,7 @@ subsys_initcall(pktsched_init); +EXPORT_SYMBOL(qdisc_lookup); EXPORT_SYMBOL(qdisc_get_rtab); EXPORT_SYMBOL(qdisc_put_rtab); EXPORT_SYMBOL(register_qdisc); Index: netem-2.6.12-rc3/net/sched/sch_netem.c =================================================================== --- netem-2.6.12-rc3.orig/net/sched/sch_netem.c 2005-05-03 11:20:05.000000000 -0700 +++ netem-2.6.12-rc3/net/sched/sch_netem.c 2005-05-03 15:41:14.000000000 -0700 @@ -206,7 +206,6 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); - struct sk_buff *skb2; int ret; pr_debug("netem_enqueue skb=%p\n", skb); @@ -220,11 +219,21 @@ } /* Random duplication */ - if (q->duplicate && q->duplicate >= get_crandom(&q->dup_cor) - && (skb2 = skb_clone(skb, GFP_ATOMIC)) != NULL) { - pr_debug("netem_enqueue: dup %p\n", skb2); + if (q->duplicate && q->duplicate >= get_crandom(&q->dup_cor)) { + struct sk_buff *skb2; + + skb2 = skb_clone(skb, GFP_ATOMIC); + if (skb2 && netem_delay(sch, skb2) == NET_XMIT_SUCCESS) { + struct Qdisc *qp; + + /* Since one packet can generate two packets in the + * queue, the parent's qlen accounting gets confused, + * so fix it. + */ + qp = qdisc_lookup(sch->dev, TC_H_MAJ(sch->parent)); + if (qp) + qp->q.qlen++; - if (netem_delay(sch, skb2)) { sch->q.qlen++; sch->bstats.bytes += skb2->len; sch->bstats.packets++; @@ -253,6 +262,7 @@ } else sch->qstats.drops++; + pr_debug("netem: enqueue ret %d\n", ret); return ret; } From shemminger@osdl.org Tue May 3 16:27:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:27:37 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NRX7J006047 for ; Tue, 3 May 2005 16:27:33 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43NRIs4031817 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 16:27:18 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43NRIds024931; Tue, 3 May 2005 16:27:18 -0700 Date: Tue, 3 May 2005 16:27:18 -0700 From: Stephen Hemminger To: "David S. Miller" , Patrick McHardy Cc: netdev@oss.sgi.com, netem@osdl.org Subject: [PATCH] (1/3) netetm: trap infinite loop hange on qlen underflow Message-ID: <20050503162718.6a670800@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 652 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Due to bugs in netem (fixed by later patches), it is possible to get qdisc qlen to go negative. If this happens the CPU ends up spinning forever in qdisc_run(). So add a BUG_ON() to trap it. Signed-off-by: Stephen Hemminger Index: netem-2.6.12-rc3/net/sched/sch_generic.c =================================================================== --- netem-2.6.12-rc3.orig/net/sched/sch_generic.c 2005-05-03 10:55:50.000000000 -0700 +++ netem-2.6.12-rc3/net/sched/sch_generic.c 2005-05-03 10:56:01.000000000 -0700 @@ -179,6 +179,7 @@ netif_schedule(dev); return 1; } + BUG_ON((int) q->q.qlen < 0); return q->q.qlen; } From shemminger@osdl.org Tue May 3 16:27:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:27:46 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NRe7J006139 for ; Tue, 3 May 2005 16:27:40 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j43NRLs4031827 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 16:27:21 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j43NRLq1024967; Tue, 3 May 2005 16:27:21 -0700 Date: Tue, 3 May 2005 16:27:09 -0700 From: Stephen Hemminger To: "David S. Miller" , Patrick McHardy Cc: netdev@oss.sgi.com, netem@lists.osdl.org Subject: [PATCH] (2/3) netem: make qdisc friendly to outer disciplines Message-ID: <20050503162709.5c0315ec@dxpl.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 654 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Netem currently dumps packets into the queue when timer expires. This patch makes work by self-clocking (more like TBF). It fixes a bug when 0 delay is requested (only doing loss or duplication). Signed-off-by: Stephen Hemminger cb; psched_tdiff_t td; psched_time_t now; PSCHED_GET_TIME(now); td = tabledist(q->latency, q->jitter, &q->delay_cor, q->delay_dist); - PSCHED_TADD2(now, td, cb->time_to_send); /* Always queue at tail to keep packets in order */ if (likely(q->delayed.qlen < q->limit)) { + struct netem_skb_cb *cb = (struct netem_skb_cb *)skb->cb; + + PSCHED_TADD2(now, td, cb->time_to_send); + + pr_debug("netem_delay: skb=%p now=%llu tosend=%llu\n", skb, + now, cb->time_to_send); + __skb_queue_tail(&q->delayed, skb); - if (!timer_pending(&q->timer)) { - q->timer.expires = jiffies + PSCHED_US2JIFFIE(td); - add_timer(&q->timer); - } return NET_XMIT_SUCCESS; } + pr_debug("netem_delay: queue over limit %d\n", q->limit); + sch->qstats.overlimits++; kfree_skb(skb); return NET_XMIT_DROP; } +/* + * Move a packet that is ready to send from the delay holding + * list to the underlying qdisc. + */ +static int netem_run(struct Qdisc *sch) +{ + struct netem_sched_data *q = qdisc_priv(sch); + struct sk_buff *skb; + psched_time_t now; + + PSCHED_GET_TIME(now); + + skb = skb_peek(&q->delayed); + if (skb) { + const struct netem_skb_cb *cb + = (const struct netem_skb_cb *)skb->cb; + long delay + = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); + pr_debug("netem_run: skb=%p delay=%ld\n", skb, delay); + + /* if more time remaining? */ + if (delay > 0) { + mod_timer(&q->timer, jiffies + delay); + return 1; + } + + __skb_unlink(skb, &q->delayed); + + if (q->qdisc->enqueue(skb, q->qdisc)) { + sch->q.qlen--; + sch->qstats.drops++; + } + } + + return 0; +} + static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); struct sk_buff *skb2; int ret; - pr_debug("netem_enqueue skb=%p @%lu\n", skb, jiffies); + pr_debug("netem_enqueue skb=%p\n", skb); /* Random packet drop 0 => none, ~0 => all */ if (q->loss && q->loss >= get_crandom(&q->loss_cor)) { @@ -184,7 +224,7 @@ && (skb2 = skb_clone(skb, GFP_ATOMIC)) != NULL) { pr_debug("netem_enqueue: dup %p\n", skb2); - if (delay_skb(sch, skb2)) { + if (netem_delay(sch, skb2)) { sch->q.qlen++; sch->bstats.bytes += skb2->len; sch->bstats.packets++; @@ -202,7 +242,8 @@ ret = q->qdisc->enqueue(skb, q->qdisc); } else { q->counter = 0; - ret = delay_skb(sch, skb); + ret = netem_delay(sch, skb); + netem_run(sch); } if (likely(ret == NET_XMIT_SUCCESS)) { @@ -241,56 +282,35 @@ return len; } -/* Dequeue packet. - * Move all packets that are ready to send from the delay holding - * list to the underlying qdisc, then just call dequeue - */ static struct sk_buff *netem_dequeue(struct Qdisc *sch) { struct netem_sched_data *q = qdisc_priv(sch); struct sk_buff *skb; + int pending; + + pending = netem_run(sch); skb = q->qdisc->dequeue(q->qdisc); - if (skb) + if (skb) { + pr_debug("netem_dequeue: return skb=%p\n", skb); sch->q.qlen--; + sch->flags &= ~TCQ_F_THROTTLED; + } + else if (pending) { + pr_debug("netem_dequeue: throttling\n"); + sch->flags |= TCQ_F_THROTTLED; + } + return skb; } static void netem_watchdog(unsigned long arg) { struct Qdisc *sch = (struct Qdisc *)arg; - struct netem_sched_data *q = qdisc_priv(sch); - struct net_device *dev = sch->dev; - struct sk_buff *skb; - psched_time_t now; - pr_debug("netem_watchdog: fired @%lu\n", jiffies); - - spin_lock_bh(&dev->queue_lock); - PSCHED_GET_TIME(now); - - while ((skb = skb_peek(&q->delayed)) != NULL) { - const struct netem_skb_cb *cb - = (const struct netem_skb_cb *)skb->cb; - long delay - = PSCHED_US2JIFFIE(PSCHED_TDIFF(cb->time_to_send, now)); - pr_debug("netem_watchdog: skb %p@%lu %ld\n", - skb, jiffies, delay); - - /* if more time remaining? */ - if (delay > 0) { - mod_timer(&q->timer, jiffies + delay); - break; - } - __skb_unlink(skb, &q->delayed); - - if (q->qdisc->enqueue(skb, q->qdisc)) { - sch->q.qlen--; - sch->qstats.drops++; - } - } - qdisc_run(dev); - spin_unlock_bh(&dev->queue_lock); + pr_debug("netem_watchdog qlen=%d\n", sch->q.qlen); + sch->flags &= ~TCQ_F_THROTTLED; + netif_schedule(sch->dev); } static void netem_reset(struct Qdisc *sch) @@ -301,6 +321,7 @@ skb_queue_purge(&q->delayed); sch->q.qlen = 0; + sch->flags &= ~TCQ_F_THROTTLED; del_timer_sync(&q->timer); } From davem@davemloft.net Tue May 3 16:29:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:29:34 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NTV7J007517 for ; Tue, 3 May 2005 16:29:31 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6eW-0003Vc-00; Tue, 03 May 2005 16:18:08 -0700 Date: Tue, 3 May 2005 16:18:08 -0700 From: "David S. Miller" To: Tommy Christensen Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com Subject: Re: [PATCH] net: Disable queueing when carrier is lost (take 2) Message-Id: <20050503161808.5925f241.davem@davemloft.net> In-Reply-To: <42780918.10001@tpack.net> References: <4276B13F.2040103@tpack.net> <20050503100306.GB29788@gondor.apana.org.au> <4277FC16.4050307@tpack.net> <20050503231023.GA18323@gondor.apana.org.au> <42780918.10001@tpack.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 655 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 04 May 2005 01:28:24 +0200 Tommy Christensen wrote: > Herbert Xu wrote: > > Thanks Tommy. This version looks good to me. BTW, you probably > > should add a Signed-off-by line. > > Sigh. I remembered on all but the final patch ... > Thanks for helping out. > > Signed-off-by: Tommy S. Christensen Applied, thanks Tommy. From davem@davemloft.net Tue May 3 16:35:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:35:31 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NZS7J008557 for ; Tue, 3 May 2005 16:35:29 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6kM-0003XK-00; Tue, 03 May 2005 16:24:10 -0700 Date: Tue, 3 May 2005 16:24:10 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: kaber@trash.net, netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating Message-Id: <20050503162410.6199eabf.davem@davemloft.net> In-Reply-To: <20050503162550.30acf31a@dxpl.pdx.osdl.net> References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 656 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev All 3 patches applied, thanks Stephen. From kaber@trash.net Tue May 3 16:35:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:35:45 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NZg7J008586 for ; Tue, 3 May 2005 16:35:42 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT6vJ-0006VO-BF; Wed, 04 May 2005 01:35:29 +0200 Message-ID: <42780AC1.8040409@trash.net> Date: Wed, 04 May 2005 01:35:29 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Hemminger CC: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> In-Reply-To: <20050503162550.30acf31a@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 657 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Stephen Hemminger wrote: > Fix qlen underrun when doing duplication with netem. If netem is used as > leaf discipline, then the parent needs to be tweaked when packets are duplicated. > + /* Since one packet can generate two packets in the > + * queue, the parent's qlen accounting gets confused, > + * so fix it. > + */ > + qp = qdisc_lookup(sch->dev, TC_H_MAJ(sch->parent)); > + if (qp) > + qp->q.qlen++; This only works in a hierarchy with just one qdisc above netem, there could be up to seven (check_loop_fn prevents more than that). It's also not safe because it violates qdisc locking rules, when this code is executed dev->queue_lock is already taken and qdisc_lookup() grabs qdisc_tree_lock, but they can only be taken in the other order. Regards Patrick From hasso@estpak.ee Tue May 3 16:35:50 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:35:53 -0700 (PDT) Received: from arena.estpak.ee (dream.estpak.ee [194.126.115.147]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NZo7J008604 for ; Tue, 3 May 2005 16:35:50 -0700 Received: from localhost ([127.0.0.1] helo=arena) by arena.estpak.ee with esmtp (Exim 4.50) id 1DT6vO-0001NG-JN; Wed, 04 May 2005 02:35:34 +0300 From: Hasso Tepper To: Patrick McHardy Subject: Re: icmp_unreachable uses wrong ip Date: Wed, 4 May 2005 02:35:33 +0300 User-Agent: KMail/1.8 Cc: "J. Simonetti" , netdev@oss.sgi.com References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505030944.49175.hasso@estpak.ee> <4277BFA6.8090306@trash.net> In-Reply-To: <4277BFA6.8090306@trash.net> Organization: Elion Enterprises Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505040235.33461.hasso@estpak.ee> X-archive-position: 658 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hasso@estpak.ee Precedence: bulk X-list: netdev Patrick McHardy wrote: > But when multiple addresses are used the result can be even more > confusing. I don't like inconsistent behaviour, and this patch works > sometimes and sometimes it doesn't. I see no behaviour you can define as "it doesn't work". Purpose of this patch is to provide info about links (not addresses, you can't have this info) used to forward packets and it does the job. > > And can you explain what theoretical possibilities router has to obtain > > info what address was used as nexthop by neighbour? > > I can think of none. Exactly. regards, -- Hasso Tepper Elion Enterprises Ltd. WAN administrator From kaber@trash.net Tue May 3 16:37:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:37:57 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Nbr7J009941 for ; Tue, 3 May 2005 16:37:54 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT6xQ-0006Vs-BM; Wed, 04 May 2005 01:37:40 +0200 Message-ID: <42780B44.8040803@trash.net> Date: Wed, 04 May 2005 01:37:40 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Hasso Tepper CC: "J. Simonetti" , netdev@oss.sgi.com Subject: Re: icmp_unreachable uses wrong ip References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505030944.49175.hasso@estpak.ee> <4277BFA6.8090306@trash.net> <200505040235.33461.hasso@estpak.ee> In-Reply-To: <200505040235.33461.hasso@estpak.ee> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 659 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Hasso Tepper wrote: > Patrick McHardy wrote: > >>But when multiple addresses are used the result can be even more >>confusing. I don't like inconsistent behaviour, and this patch works >>sometimes and sometimes it doesn't. > > > I see no behaviour you can define as "it doesn't work". Purpose of this > patch is to provide info about links (not addresses, you can't have this > info) used to forward packets and it does the job. Well, arguably it can be called "doesn't work" if addresses not used at all during transmit of the packet show up in traceroute. Regards Patrick From davem@davemloft.net Tue May 3 16:38:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:38:05 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Nc27J010131 for ; Tue, 3 May 2005 16:38:02 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6gS-0003W8-00; Tue, 03 May 2005 16:20:08 -0700 Date: Tue, 3 May 2005 16:20:07 -0700 From: "David S. Miller" To: Patrick McHardy Cc: herbert@gondor.apana.org.au, netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, akpm@osdl.org Subject: Re: CONFIG_NETFILTER_DEBUG spew Message-Id: <20050503162007.70c57f37.davem@davemloft.net> In-Reply-To: <4274F2ED.9080404@trash.net> References: <20050501032809.3d0b4cda.akpm@osdl.org> <20050501111507.GA2133@gondor.apana.org.au> <4274F2ED.9080404@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 660 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Patch applied, thanks. From davem@davemloft.net Tue May 3 16:38:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:38:18 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NcE7J010278 for ; Tue, 3 May 2005 16:38:14 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6gk-0003WC-00; Tue, 03 May 2005 16:20:26 -0700 Date: Tue, 3 May 2005 16:20:26 -0700 From: "David S. Miller" To: Patrick McHardy Cc: herbert@gondor.apana.org.au, netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, akpm@osdl.org Subject: Re: CONFIG_NETFILTER_DEBUG spew Message-Id: <20050503162026.11ec4ada.davem@davemloft.net> In-Reply-To: <4276517F.6030606@trash.net> References: <20050501032809.3d0b4cda.akpm@osdl.org> <20050501111507.GA2133@gondor.apana.org.au> <4276517F.6030606@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 661 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Mon, 02 May 2005 18:12:47 +0200 Patrick McHardy wrote: > Herbert Xu wrote: > > BTW, should we do nf_reset in ip_dev_loopback_xmit as well? > > I think we should, tc actions could do something unexpected with > the packet. Also applied, thanks a lot. From davem@davemloft.net Tue May 3 16:39:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:39:42 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Ndd7J011563 for ; Tue, 3 May 2005 16:39:39 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6mb-0003b6-00; Tue, 03 May 2005 16:26:29 -0700 Date: Tue, 3 May 2005 16:26:28 -0700 From: "David S. Miller" To: Herbert Xu Cc: yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries (was: [PATCH][IPv6][IPsec] stop infinite loop) Message-Id: <20050503162628.7541807d.davem@davemloft.net> In-Reply-To: <20050430114349.GA24573@gondor.apana.org.au> References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 662 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 30 Apr 2005 21:43:49 +1000 Herbert Xu wrote: > The ref counting on loopback_idev wasn't quite right. Here is the > corrected version. Applied, thanks Herbert. From davem@davemloft.net Tue May 3 16:39:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:39:53 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Ndn7J011582 for ; Tue, 3 May 2005 16:39:49 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6ob-0003by-00; Tue, 03 May 2005 16:28:33 -0700 Date: Tue, 3 May 2005 16:28:33 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: patch: Action repeat Message-Id: <20050503162833.4dc1ae80.davem@davemloft.net> In-Reply-To: <1114879817.8929.117.camel@localhost.localdomain> References: <1114879817.8929.117.camel@localhost.localdomain> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 663 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Sat, 30 Apr 2005 12:50:17 -0400 jamal wrote: > Long standing bug. > Policy to repeat an action never worked. > > signed-off-by: J Hadi Salim Applied, thanks Jamal. From davem@davemloft.net Tue May 3 16:41:42 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:41:46 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43Nfg7J012845 for ; Tue, 3 May 2005 16:41:42 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT6qP-0003e4-00; Tue, 03 May 2005 16:30:25 -0700 Date: Tue, 3 May 2005 16:30:25 -0700 From: "David S. Miller" To: Patrick McHardy Cc: shemminger@osdl.org, netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating Message-Id: <20050503163025.38bb9682.davem@davemloft.net> In-Reply-To: <42780AC1.8040409@trash.net> References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> <42780AC1.8040409@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 664 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 04 May 2005 01:35:29 +0200 Patrick McHardy wrote: > Stephen Hemminger wrote: > > Fix qlen underrun when doing duplication with netem. If netem is used as > > leaf discipline, then the parent needs to be tweaked when packets are duplicated. > > > + /* Since one packet can generate two packets in the > > + * queue, the parent's qlen accounting gets confused, > > + * so fix it. > > + */ > > + qp = qdisc_lookup(sch->dev, TC_H_MAJ(sch->parent)); > > + if (qp) > > + qp->q.qlen++; > > This only works in a hierarchy with just one qdisc above netem, there > could be up to seven (check_loop_fn prevents more than that). It's also > not safe because it violates qdisc locking rules, when this code is > executed dev->queue_lock is already taken and qdisc_lookup() grabs > qdisc_tree_lock, but they can only be taken in the other order. I see... I'm leaving Stephen's patch in there for now. Perhaps we can create some kind of "propagate up" function that will handle all of the parents in the qdisc hierarchy above netem? From kaber@trash.net Tue May 3 16:48:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 16:48:19 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j43NmF7J014038 for ; Tue, 3 May 2005 16:48:16 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT77S-0006Y3-TI; Wed, 04 May 2005 01:48:02 +0200 Message-ID: <42780DB2.2090201@trash.net> Date: Wed, 04 May 2005 01:48:02 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> <42780AC1.8040409@trash.net> <20050503163025.38bb9682.davem@davemloft.net> In-Reply-To: <20050503163025.38bb9682.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 665 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev David S. Miller wrote: > On Wed, 04 May 2005 01:35:29 +0200 > Patrick McHardy wrote: > >>This only works in a hierarchy with just one qdisc above netem, there >>could be up to seven (check_loop_fn prevents more than that). It's also >>not safe because it violates qdisc locking rules, when this code is >>executed dev->queue_lock is already taken and qdisc_lookup() grabs >>qdisc_tree_lock, but they can only be taken in the other order. > > I see... I'm leaving Stephen's patch in there for now. > > Perhaps we can create some kind of "propagate up" function > that will handle all of the parents in the qdisc hierarchy > above netem? That's what I already suggested, it should be pretty simple to do so. I'll send a patch once your tree appears on kernel.org. BTW, are you pushing it regulary or just for Linus to merge? Regards Patrick From davem@davemloft.net Tue May 3 17:10:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 17:11:01 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j440Au7J015169 for ; Tue, 3 May 2005 17:10:56 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DT7If-0003rU-00; Tue, 03 May 2005 16:59:37 -0700 Date: Tue, 3 May 2005 16:59:37 -0700 From: "David S. Miller" To: Patrick McHardy Cc: shemminger@osdl.org, netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating Message-Id: <20050503165937.0c6cac6d.davem@davemloft.net> In-Reply-To: <42780DB2.2090201@trash.net> References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> <42780AC1.8040409@trash.net> <20050503163025.38bb9682.davem@davemloft.net> <42780DB2.2090201@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 666 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 04 May 2005 01:48:02 +0200 Patrick McHardy wrote: > That's what I already suggested, it should be pretty simple to do > so. I'll send a patch once your tree appears on kernel.org. Thanks. > BTW, are you pushing it regulary or just for Linus to merge? I tend to process a batch of patches, then push the kernel.org, then to Linus. I just pushed my tree to: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/ and you poke it on the web via: http://www.kernel.org/git/ My net-2.6 tree is in the list there at: http://www.kernel.org/git/gitweb.cgi?p=linux%2Fkernel%2Fgit%2Fdavem%2Fnet-2.6.git;a=log as soon as Marcelo has his GIT tree going for 2.4.x, I'll put Sparc and Net trees up for that as well. From herbert@gondor.apana.org.au Tue May 3 17:46:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 17:46:37 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j440kT7J016706 for ; Tue, 3 May 2005 17:46:30 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DT81b-0000gX-00; Wed, 04 May 2005 10:46:03 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DT81Y-00055Q-00; Wed, 04 May 2005 10:46:00 +1000 Date: Wed, 4 May 2005 10:46:00 +1000 To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries (was: [PATCH][IPv6][IPsec] stop infinite loop) Message-ID: <20050504004600.GA19502@gondor.apana.org.au> References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> <20050503162628.7541807d.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503162628.7541807d.davem@davemloft.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 667 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Tue, May 03, 2005 at 04:26:28PM -0700, David S. Miller wrote: > > Applied, thanks Herbert. Thanks Dave. BTW, I was reviewing the rt6i_idev usage in IPv6 and it seems to me that they need some protection with locking or RCU. As it is they are simply dereferenced in user/softirq context with no locking. For example, the call chain udpv6_sendmsg -> ip6_dst_lookup -> ipv6_get_saddr occurs in user context and simply dereferences rt6i_idev. The race condition is that another CPU could come in and free rt6i_idev. The reference count held by the dst entry doesn't help since the other CPU will drop the reference count for us through dst_ifdown. Yoshifuji-san, does this look like a real problem to you? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From kaber@trash.net Tue May 3 18:07:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:07:44 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4417d7J017669 for ; Tue, 3 May 2005 18:07:39 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT8Ld-0003XC-V5; Wed, 04 May 2005 03:06:45 +0200 Message-ID: <42782025.3010700@trash.net> Date: Wed, 04 May 2005 03:06:45 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: Herbert Xu , yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> <20050503162628.7541807d.davem@davemloft.net> In-Reply-To: <20050503162628.7541807d.davem@davemloft.net> Content-Type: multipart/mixed; boundary="------------010304080206040500020904" X-archive-position: 668 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------010304080206040500020904 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David S. Miller wrote: > On Sat, 30 Apr 2005 21:43:49 +1000 > Herbert Xu wrote: > >>The ref counting on loopback_idev wasn't quite right. Here is the >>corrected version. > > > Applied, thanks Herbert. The patch causes a compile error here: CC net/ipv6/xfrm6_policy.o In file included from net/ipv6/xfrm6_policy.c:18: include/net/addrconf.h:40: error: field `prefix' has incomplete type This patch fixes it. Signed-off-by: Patrick McHardy --------------010304080206040500020904 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" Index: net/ipv6/xfrm6_policy.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/ipv6/xfrm6_policy.c (mode:100644 sha1:4429b1a1fe5fe2528318b7417e539279548d9988) +++ uncommitted/net/ipv6/xfrm6_policy.c (mode:100644) @@ -15,6 +15,7 @@ #include #include #include +#include #include #include #include --------------010304080206040500020904-- From herbert@gondor.apana.org.au Tue May 3 18:12:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:12:40 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j441Ca7J018269 for ; Tue, 3 May 2005 18:12:36 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DT8Qq-0000pJ-00; Wed, 04 May 2005 11:12:08 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DT8Qm-00058a-00; Wed, 04 May 2005 11:12:04 +1000 Date: Wed, 4 May 2005 11:12:04 +1000 To: Patrick McHardy Cc: "David S. Miller" , yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries Message-ID: <20050504011204.GA19740@gondor.apana.org.au> References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> <20050503162628.7541807d.davem@davemloft.net> <42782025.3010700@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42782025.3010700@trash.net> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 669 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Wed, May 04, 2005 at 03:06:45AM +0200, Patrick McHardy wrote: > > The patch causes a compile error here: > > CC net/ipv6/xfrm6_policy.o > In file included from net/ipv6/xfrm6_policy.c:18: > include/net/addrconf.h:40: error: field `prefix' has incomplete type Hmm, I wonder why I didn't see this. Anyway, could you please add the include to addrconf.h instead? Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From glen.turner@aarnet.edu.au Tue May 3 18:16:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:16:10 -0700 (PDT) Received: from clix.aarnet.edu.au (clix.aarnet.edu.au [192.94.63.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j441G57J018860 for ; Tue, 3 May 2005 18:16:06 -0700 Received: from [202.158.193.5] (andromache.adelaide.aarnet.edu.au [202.158.193.5]) (authenticated bits=0) by clix.aarnet.edu.au (8.12.8/8.12.8) with ESMTP id j441Fjob001649 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 4 May 2005 11:15:46 +1000 Message-ID: <42782241.6080909@aarnet.edu.au> Date: Wed, 04 May 2005 10:45:45 +0930 From: Glen Turner Organization: Australian Academic and Research Network User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: netdev@oss.sgi.com Subject: Re: icmp_unreachable uses wrong ip References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <20050503092244.GA8864@xi.wantstofly.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MDSA: Yes X-Scanned-By: MIMEDefang 2.39 X-archive-position: 670 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: glen.turner@aarnet.edu.au Precedence: bulk X-list: netdev Pekka Savola wrote: > > > There's no specification requiring or recommending either of these > approaches, either for v6 or v4 AFAICS so you can't depend on that > behaviour.. In the lack of a specification, doing what works best for network operators would be nice :-) And that behaviour is that addresses in a traceroute should be ping-able. That is, you're tracing the route and there's loss at one point, so you want to determine how much loss. The outgoing interface's address may not be reached down the same path as used by the traceroute, whereis the incoming address obviously is (or if it isn't, then that itself is interesting diagnostic information). Similarly, using the incoming interface gives more information about asymetric routes. In short, since using the incoming address gives more useful output and the specification is silent as to which address is allowable, using the incoming interface's address would be the most useful choice. Cheers, Glen -- Glen Turner Tel: (08) 8303 3936 or +61 8 8303 3936 Australia's Academic & Research Network www.aarnet.edu.au From herbert@gondor.apana.org.au Tue May 3 18:20:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:20:38 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j441KV7J019456 for ; Tue, 3 May 2005 18:20:33 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DT8YP-0000tD-00; Wed, 04 May 2005 11:19:57 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DT8YO-0005Nc-00; Wed, 04 May 2005 11:19:56 +1000 Date: Wed, 4 May 2005 11:19:56 +1000 To: Patrick McHardy Cc: "David S. Miller" , yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries Message-ID: <20050504011956.GA20670@gondor.apana.org.au> References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> <20050503162628.7541807d.davem@davemloft.net> <42782025.3010700@trash.net> <20050504011204.GA19740@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: <20050504011204.GA19740@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040907i From: Herbert Xu X-archive-position: 671 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, May 04, 2005 at 11:12:04AM +1000, herbert wrote: > On Wed, May 04, 2005 at 03:06:45AM +0200, Patrick McHardy wrote: > > > > The patch causes a compile error here: > > > > CC net/ipv6/xfrm6_policy.o > > In file included from net/ipv6/xfrm6_policy.c:18: > > include/net/addrconf.h:40: error: field `prefix' has incomplete type > > Hmm, I wonder why I didn't see this. Anyway, could you please add > the include to addrconf.h instead? Aha, I can see it if I do something like this. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p ===== include/asm-i386/checksum.h 1.14 vs edited ===== --- 1.14/include/asm-i386/checksum.h 2005-01-16 22:58:42 +11:00 +++ edited/include/asm-i386/checksum.h 2005-05-04 11:17:09 +10:00 @@ -1,8 +1,6 @@ #ifndef _I386_CHECKSUM_H #define _I386_CHECKSUM_H -#include - /* * computes the checksum of a memory block at buff, length len, * and adds in "sum" (32-bit) @@ -145,6 +143,7 @@ } #define _HAVE_ARCH_IPV6_CSUM +struct in6_addr; static __inline__ unsigned short int csum_ipv6_magic(struct in6_addr *saddr, struct in6_addr *daddr, __u32 len, --mP3DRpeJDSE+ciuQ-- From kaber@trash.net Tue May 3 18:21:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:21:07 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j441L17J019497 for ; Tue, 3 May 2005 18:21:02 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT8Yd-0006Hb-Nw; Wed, 04 May 2005 03:20:11 +0200 Message-ID: <4278234B.2080605@trash.net> Date: Wed, 04 May 2005 03:20:11 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> <20050503162628.7541807d.davem@davemloft.net> <42782025.3010700@trash.net> <20050504011204.GA19740@gondor.apana.org.au> In-Reply-To: <20050504011204.GA19740@gondor.apana.org.au> Content-Type: multipart/mixed; boundary="------------090201060903000203060606" X-archive-position: 672 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------090201060903000203060606 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Herbert Xu wrote: > Hmm, I wonder why I didn't see this. Anyway, could you please add > the include to addrconf.h instead? Sure, I missed the includes below and thought users of the file were supposed to include it first. Signed-off-by: Patrick McHardy --------------090201060903000203060606 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" Index: include/net/addrconf.h =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/include/net/addrconf.h (mode:100644 sha1:f1e5af4be98e4a9cde314a5c1ceeaf3a61cf87ad) +++ uncommitted/include/net/addrconf.h (mode:100644) @@ -17,6 +17,8 @@ #define IPV6_MAX_ADDRESSES 16 +#include + struct prefix_info { __u8 type; __u8 length; @@ -43,7 +45,6 @@ #ifdef __KERNEL__ -#include #include #include #include --------------090201060903000203060606-- From kaber@trash.net Tue May 3 18:24:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:24:21 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j441OI7J020581 for ; Tue, 3 May 2005 18:24:18 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT8bp-0006I5-CM; Wed, 04 May 2005 03:23:29 +0200 Message-ID: <42782411.2070206@trash.net> Date: Wed, 04 May 2005 03:23:29 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: Herbert Xu CC: "David S. Miller" , yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> <20050503162628.7541807d.davem@davemloft.net> <42782025.3010700@trash.net> <20050504011204.GA19740@gondor.apana.org.au> <20050504011956.GA20670@gondor.apana.org.au> In-Reply-To: <20050504011956.GA20670@gondor.apana.org.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 673 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Herbert Xu wrote: >>Hmm, I wonder why I didn't see this. Anyway, could you please add >>the include to addrconf.h instead? > > Aha, I can see it if I do something like this. > > > ------------------------------------------------------------------------ > > ===== include/asm-i386/checksum.h 1.14 vs edited ===== > --- 1.14/include/asm-i386/checksum.h 2005-01-16 22:58:42 +11:00 > +++ edited/include/asm-i386/checksum.h 2005-05-04 11:17:09 +10:00 > @@ -1,8 +1,6 @@ > #ifndef _I386_CHECKSUM_H > #define _I386_CHECKSUM_H > > -#include > - > /* > * computes the checksum of a memory block at buff, length len, > * and adds in "sum" (32-bit) > @@ -145,6 +143,7 @@ > } > > #define _HAVE_ARCH_IPV6_CSUM > +struct in6_addr; > static __inline__ unsigned short int csum_ipv6_magic(struct in6_addr *saddr, > struct in6_addr *daddr, > __u32 len, I use x86_64, which explains why I saw the error: struct in6_addr; #define _HAVE_ARCH_IPV6_CSUM 1 csum_ipv6_magic(struct in6_addr *saddr, struct in6_addr *daddr, __u32 len, unsigned short proto, unsigned int sum); Regards Patrick From kaber@trash.net Tue May 3 18:57:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:57:18 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j441vE7J022220 for ; Tue, 3 May 2005 18:57:15 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT98I-00046Z-8c; Wed, 04 May 2005 03:57:02 +0200 Message-ID: <42782BEE.2050206@trash.net> Date: Wed, 04 May 2005 03:57:02 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> <42780AC1.8040409@trash.net> <20050503163025.38bb9682.davem@davemloft.net> <42780DB2.2090201@trash.net> <20050503165937.0c6cac6d.davem@davemloft.net> <42782B59.3000500@trash.net> In-Reply-To: <42782B59.3000500@trash.net> Content-Type: multipart/mixed; boundary="------------070808090604040309020309" X-archive-position: 675 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------070808090604040309020309 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Patrick McHardy wrote: > David S. Miller wrote: > >>On Wed, 04 May 2005 01:48:02 +0200 >>Patrick McHardy wrote: >> >> >> >>>That's what I already suggested, it should be pretty simple to do >>>so. I'll send a patch once your tree appears on kernel.org. > > > This one should work. It keeps a pointer to the parent qdisc in struct > Qdisc and adjusts q.qlen of all parent qdiscs in netem. The __parent > pointer also used by CBQ is renamed to parentq and is used for this. To > avoid confusion, the parent classid is also renamed to parentcl. It > should work with all currently included classful qdiscs except HFSC. > Statistics are not correctly updated (and can't be without support from > the qdisc since classes are internal to it), we need to keep this in > mind in case a qdisc like RED which uses qstats.backlog for calculations > is converted to a classful one. Fixing HFSC is very low priority, it > could only use netem in work-conserving mode anyway. > > My favourite solution would be to avoid this hack and let tc actions > handle duplication, as Jamal suggested. My previous point against this > of not necessarily having an identical classification result for the > duplicated packet as the original one is actually a plus since it > provides more flexibility. Steven, what do you think about it? > > Signed-off-by: Patrick McHardy > Oops, I've attached an old patch with a bug. This one is the correct one. --------------070808090604040309020309 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" Index: include/net/sch_generic.h =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/include/net/sch_generic.h (mode:100644 sha1:c57504b3b51819522dc9f868aa9a208d61dd3892) +++ uncommitted/include/net/sch_generic.h (mode:100644) @@ -35,7 +35,7 @@ int padded; struct Qdisc_ops *ops; u32 handle; - u32 parent; + u32 parentcl; atomic_t refcnt; struct sk_buff_head q; struct net_device *dev; @@ -49,10 +49,11 @@ int (*reshape_fail)(struct sk_buff *skb, struct Qdisc *q); - /* This field is deprecated, but it is still used by CBQ + /* This field is deprecated, but it is still used by CBQ and netem * and it will live until better solution will be invented. + * Valid only while qdisc is grafted to its parent. */ - struct Qdisc *__parent; + struct Qdisc *parentq; }; struct Qdisc_class_ops Index: net/sched/sch_api.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_api.c (mode:100644 sha1:07977f8f2679b30cf93808f93fbbcce3c3dbc776) +++ uncommitted/net/sched/sch_api.c (mode:100644) @@ -378,9 +378,11 @@ if (cops) { unsigned long cl = cops->get(parent, classid); if (cl) { + if (new) { + new->parentcl = classid; + new->parentq = parent; + } err = cops->graft(parent, cl, new, old); - if (new) - new->parent = classid; cops->put(parent, cl); } } @@ -855,7 +857,7 @@ q_idx++; continue; } - if (tc_fill_qdisc(skb, q, q->parent, NETLINK_CB(cb->skb).pid, + if (tc_fill_qdisc(skb, q, q->parentcl, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, NLM_F_MULTI, RTM_NEWQDISC) <= 0) { read_unlock_bh(&qdisc_tree_lock); goto done; @@ -1289,7 +1291,6 @@ subsys_initcall(pktsched_init); -EXPORT_SYMBOL(qdisc_lookup); EXPORT_SYMBOL(qdisc_get_rtab); EXPORT_SYMBOL(qdisc_put_rtab); EXPORT_SYMBOL(register_qdisc); Index: net/sched/sch_cbq.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_cbq.c (mode:100644 sha1:d43e3b8cbf6af27a25ab7b9d2aee82a32f8010eb) +++ uncommitted/net/sched/sch_cbq.c (mode:100644) @@ -419,9 +419,6 @@ return ret; } -#ifdef CONFIG_NET_CLS_POLICE - cl->q->__parent = sch; -#endif if ((ret = cl->q->enqueue(skb, cl->q)) == NET_XMIT_SUCCESS) { sch->q.qlen++; sch->bstats.packets++; @@ -456,7 +453,6 @@ #ifdef CONFIG_NET_CLS_POLICE q->rx_class = cl; - cl->q->__parent = sch; #endif if ((ret = cl->q->ops->requeue(skb, cl->q)) == 0) { sch->q.qlen++; @@ -690,7 +686,7 @@ static int cbq_reshape_fail(struct sk_buff *skb, struct Qdisc *child) { int len = skb->len; - struct Qdisc *sch = child->__parent; + struct Qdisc *sch = child->parentq; struct cbq_sched_data *q = qdisc_priv(sch); struct cbq_class *cl = q->rx_class; @@ -701,7 +697,6 @@ cbq_mark_toplevel(q, cl); q->rx_class = cl; - cl->q->__parent = sch; if (cl->q->enqueue(skb, cl->q) == 0) { sch->q.qlen++; Index: net/sched/sch_generic.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_generic.c (mode:100644 sha1:87e48a4e105133ca3d0407b5c2d84f1b0e3a72c4) +++ uncommitted/net/sched/sch_generic.c (mode:100644) @@ -501,7 +501,7 @@ /* unlink inner qdiscs from dev->qdisc_list immediately */ list_for_each_entry(cq, &cql, list) list_for_each_entry_safe(q, n, &qdisc->dev->qdisc_list, list) - if (TC_H_MAJ(q->parent) == TC_H_MAJ(cq->handle)) { + if (TC_H_MAJ(q->parentcl) == TC_H_MAJ(cq->handle)) { if (q->ops->cl_ops == NULL) list_del_init(&q->list); else Index: net/sched/sch_netem.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_netem.c (mode:100644 sha1:e0c9fbe73b15cee32b44f4469e1ac5eeb9849267) +++ uncommitted/net/sched/sch_netem.c (mode:100644) @@ -230,11 +230,9 @@ * queue, the parent's qlen accounting gets confused, * so fix it. */ - qp = qdisc_lookup(sch->dev, TC_H_MAJ(sch->parent)); - if (qp) + for (qp = sch; qp; qp = qp->parentq) qp->q.qlen++; - sch->q.qlen++; sch->bstats.bytes += skb2->len; sch->bstats.packets++; } else --------------070808090604040309020309-- From kaber@trash.net Tue May 3 18:54:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 18:54:52 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j441sk7J021935 for ; Tue, 3 May 2005 18:54:49 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DT95t-000450-4n; Wed, 04 May 2005 03:54:33 +0200 Message-ID: <42782B59.3000500@trash.net> Date: Wed, 04 May 2005 03:54:33 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> <42780AC1.8040409@trash.net> <20050503163025.38bb9682.davem@davemloft.net> <42780DB2.2090201@trash.net> <20050503165937.0c6cac6d.davem@davemloft.net> In-Reply-To: <20050503165937.0c6cac6d.davem@davemloft.net> Content-Type: multipart/mixed; boundary="------------020602040806080405010609" X-archive-position: 674 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------020602040806080405010609 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David S. Miller wrote: > On Wed, 04 May 2005 01:48:02 +0200 > Patrick McHardy wrote: > > >>That's what I already suggested, it should be pretty simple to do >>so. I'll send a patch once your tree appears on kernel.org. This one should work. It keeps a pointer to the parent qdisc in struct Qdisc and adjusts q.qlen of all parent qdiscs in netem. The __parent pointer also used by CBQ is renamed to parentq and is used for this. To avoid confusion, the parent classid is also renamed to parentcl. It should work with all currently included classful qdiscs except HFSC. Statistics are not correctly updated (and can't be without support from the qdisc since classes are internal to it), we need to keep this in mind in case a qdisc like RED which uses qstats.backlog for calculations is converted to a classful one. Fixing HFSC is very low priority, it could only use netem in work-conserving mode anyway. My favourite solution would be to avoid this hack and let tc actions handle duplication, as Jamal suggested. My previous point against this of not necessarily having an identical classification result for the duplicated packet as the original one is actually a plus since it provides more flexibility. Steven, what do you think about it? Signed-off-by: Patrick McHardy --------------020602040806080405010609 Content-Type: text/plain; name="x" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="x" Index: include/net/sch_generic.h =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/include/net/sch_generic.h (mode:100644 sha1:c57504b3b51819522dc9f868aa9a208d61dd3892) +++ uncommitted/include/net/sch_generic.h (mode:100644) @@ -35,7 +35,7 @@ int padded; struct Qdisc_ops *ops; u32 handle; - u32 parent; + u32 parentcl; atomic_t refcnt; struct sk_buff_head q; struct net_device *dev; @@ -49,10 +49,11 @@ int (*reshape_fail)(struct sk_buff *skb, struct Qdisc *q); - /* This field is deprecated, but it is still used by CBQ + /* This field is deprecated, but it is still used by CBQ and netem * and it will live until better solution will be invented. + * Valid only while qdisc is grafted to its parent. */ - struct Qdisc *__parent; + struct Qdisc *parentq; }; struct Qdisc_class_ops Index: net/sched/sch_api.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_api.c (mode:100644 sha1:07977f8f2679b30cf93808f93fbbcce3c3dbc776) +++ uncommitted/net/sched/sch_api.c (mode:100644) @@ -378,9 +378,11 @@ if (cops) { unsigned long cl = cops->get(parent, classid); if (cl) { + if (new) { + new->parentcl = classid; + new->parentq = parent; + } err = cops->graft(parent, cl, new, old); - if (new) - new->parent = classid; cops->put(parent, cl); } } @@ -855,7 +857,7 @@ q_idx++; continue; } - if (tc_fill_qdisc(skb, q, q->parent, NETLINK_CB(cb->skb).pid, + if (tc_fill_qdisc(skb, q, q->parentcl, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, NLM_F_MULTI, RTM_NEWQDISC) <= 0) { read_unlock_bh(&qdisc_tree_lock); goto done; @@ -1289,7 +1291,6 @@ subsys_initcall(pktsched_init); -EXPORT_SYMBOL(qdisc_lookup); EXPORT_SYMBOL(qdisc_get_rtab); EXPORT_SYMBOL(qdisc_put_rtab); EXPORT_SYMBOL(register_qdisc); Index: net/sched/sch_cbq.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_cbq.c (mode:100644 sha1:d43e3b8cbf6af27a25ab7b9d2aee82a32f8010eb) +++ uncommitted/net/sched/sch_cbq.c (mode:100644) @@ -419,9 +419,6 @@ return ret; } -#ifdef CONFIG_NET_CLS_POLICE - cl->q->__parent = sch; -#endif if ((ret = cl->q->enqueue(skb, cl->q)) == NET_XMIT_SUCCESS) { sch->q.qlen++; sch->bstats.packets++; @@ -456,7 +453,6 @@ #ifdef CONFIG_NET_CLS_POLICE q->rx_class = cl; - cl->q->__parent = sch; #endif if ((ret = cl->q->ops->requeue(skb, cl->q)) == 0) { sch->q.qlen++; @@ -690,7 +686,7 @@ static int cbq_reshape_fail(struct sk_buff *skb, struct Qdisc *child) { int len = skb->len; - struct Qdisc *sch = child->__parent; + struct Qdisc *sch = child->parentq; struct cbq_sched_data *q = qdisc_priv(sch); struct cbq_class *cl = q->rx_class; @@ -701,7 +697,6 @@ cbq_mark_toplevel(q, cl); q->rx_class = cl; - cl->q->__parent = sch; if (cl->q->enqueue(skb, cl->q) == 0) { sch->q.qlen++; Index: net/sched/sch_generic.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_generic.c (mode:100644 sha1:87e48a4e105133ca3d0407b5c2d84f1b0e3a72c4) +++ uncommitted/net/sched/sch_generic.c (mode:100644) @@ -501,7 +501,7 @@ /* unlink inner qdiscs from dev->qdisc_list immediately */ list_for_each_entry(cq, &cql, list) list_for_each_entry_safe(q, n, &qdisc->dev->qdisc_list, list) - if (TC_H_MAJ(q->parent) == TC_H_MAJ(cq->handle)) { + if (TC_H_MAJ(q->parentcl) == TC_H_MAJ(cq->handle)) { if (q->ops->cl_ops == NULL) list_del_init(&q->list); else Index: net/sched/sch_netem.c =================================================================== --- 591ce19741741438606ab75a45ac9f973cbb4787/net/sched/sch_netem.c (mode:100644 sha1:e0c9fbe73b15cee32b44f4469e1ac5eeb9849267) +++ uncommitted/net/sched/sch_netem.c (mode:100644) @@ -230,8 +230,7 @@ * queue, the parent's qlen accounting gets confused, * so fix it. */ - qp = qdisc_lookup(sch->dev, TC_H_MAJ(sch->parent)); - if (qp) + for (qp = sch->parentq; qp; qp = qp->parentq) qp->q.qlen++; sch->q.qlen++; --------------020602040806080405010609-- From akpm@osdl.org Tue May 3 21:56:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 21:56:25 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j444uL7J031028 for ; Tue, 3 May 2005 21:56:22 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j444u7U3022506 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 May 2005 21:56:07 -0700 Received: from localhost.localdomain (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j444u6sS004479; Tue, 3 May 2005 21:56:07 -0700 Message-Id: <200505040456.j444u6sS004479@shell0.pdx.osdl.net> Subject: [patch 1/1] addrconf.h build fix To: davem@davemloft.net Cc: netdev@oss.sgi.com, akpm@osdl.org From: akpm@osdl.org Date: Tue, 03 May 2005 21:55:40 -0700 X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 676 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 On ppc64: In file included from net/ipv6/xfrm6_policy.c:18: include/net/addrconf.h:40: error: field `prefix' has incomplete type This surely patch isn't right, and might break userspace inclusion of this header file. Signed-off-by: Andrew Morton --- include/net/addrconf.h | 2 ++ 1 files changed, 2 insertions(+) diff -puN include/net/addrconf.h~addrconf-build-fix include/net/addrconf.h --- 25/include/net/addrconf.h~addrconf-build-fix 2005-05-04 04:47:24.000000000 -0600 +++ 25-akpm/include/net/addrconf.h 2005-05-04 04:47:39.000000000 -0600 @@ -1,6 +1,8 @@ #ifndef _ADDRCONF_H #define _ADDRCONF_H +#include + #define RETRANS_TIMER HZ #define MAX_RTR_SOLICITATIONS 3 _ From shemminger@osdl.org Tue May 3 22:02:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 22:02:18 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4452F7J031525 for ; Tue, 3 May 2005 22:02:15 -0700 Received: from [192.168.0.106] (063-170-215-071.dslnorthwest.net [63.170.215.71]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j4451wU3023030 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 3 May 2005 22:02:00 -0700 Message-ID: <4278573C.3040503@osdl.org> Date: Tue, 03 May 2005 22:01:48 -0700 From: Stephen Hemminger User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Patrick McHardy CC: "David S. Miller" , netdev@oss.sgi.com, netem@osdl.org Subject: Re: [PATCH] (3/3) netem: adjust parent qlen when duplicating References: <20050503162550.30acf31a@dxpl.pdx.osdl.net> <42780AC1.8040409@trash.net> <20050503163025.38bb9682.davem@davemloft.net> <42780DB2.2090201@trash.net> <20050503165937.0c6cac6d.davem@davemloft.net> <42782B59.3000500@trash.net> <42782BEE.2050206@trash.net> In-Reply-To: <42782BEE.2050206@trash.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 677 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev I like Patrick's solution; and eventually I'll remove duplicate from netem and use mirred action. The problem is that it makes setting up a test environment even more complicated (and error prone). The interface to this is just getting so messy (sorry Jamal), with mirred, filters etc.. Unfortunately, tcng doesn't seem to be getting updated regularly. From davem@davemloft.net Tue May 3 22:03:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 22:03:07 -0700 (PDT) Received: from cheetah.davemloft.net ([216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j445317J031621 for ; Tue, 3 May 2005 22:03:01 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTBr8-00060U-00; Tue, 03 May 2005 21:51:30 -0700 Date: Tue, 3 May 2005 21:51:30 -0700 From: "David S. Miller" To: akpm@osdl.org Cc: netdev@oss.sgi.com, akpm@osdl.org Subject: Re: [patch 1/1] addrconf.h build fix Message-Id: <20050503215130.0526178c.davem@davemloft.net> In-Reply-To: <200505040456.j444u6sS004479@shell0.pdx.osdl.net> References: <200505040456.j444u6sS004479@shell0.pdx.osdl.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 678 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Tue, 03 May 2005 21:55:40 -0700 akpm@osdl.org wrote: > On ppc64: > > In file included from net/ipv6/xfrm6_policy.c:18: > include/net/addrconf.h:40: error: field `prefix' has incomplete type > > This surely patch isn't right, and might break userspace inclusion of this > header file. I've got a fix in my queue for this already. In fact, the patch in question was posted to netdev@oss.sgi.com a few hours ago, you may wish to start scanning that list before posting patches :-) From davem@davemloft.net Tue May 3 22:28:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 22:28:33 -0700 (PDT) Received: from cheetah.davemloft.net (dsl027-180-174.sfo1.dsl.speakeasy.net [216.27.180.174]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j445ST7J000807 for ; Tue, 3 May 2005 22:28:29 -0700 Received: from localhost ([127.0.0.1] helo=cheetah.davemloft.net ident=davem) by cheetah.davemloft.net with smtp (Exim 3.36 #1 (Debian)) id 1DTCFa-0006BV-00; Tue, 03 May 2005 22:16:46 -0700 Date: Tue, 3 May 2005 22:16:46 -0700 From: "David S. Miller" To: Patrick McHardy Cc: herbert@gondor.apana.org.au, yoshfuji@linux-ipv6.org, kazunori@miyazawa.org, netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [IPSEC] Store idev entries Message-Id: <20050503221646.4a8de611.davem@davemloft.net> In-Reply-To: <4278234B.2080605@trash.net> References: <4272EC95.20401@miyazawa.org> <20050430.120736.45974367.yoshfuji@linux-ipv6.org> <20050430031159.GA24326@gondor.apana.org.au> <20050430082339.GA20338@gondor.apana.org.au> <20050430114349.GA24573@gondor.apana.org.au> <20050503162628.7541807d.davem@davemloft.net> <42782025.3010700@trash.net> <20050504011204.GA19740@gondor.apana.org.au> <4278234B.2080605@trash.net> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 679 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev On Wed, 04 May 2005 03:20:11 +0200 Patrick McHardy wrote: > Herbert Xu wrote: > > Hmm, I wonder why I didn't see this. Anyway, could you please add > > the include to addrconf.h instead? > > Sure, I missed the includes below and thought users of the file were > supposed to include it first. > > Signed-off-by: Patrick McHardy Applied, thanks guys. From mchan@broadcom.com Tue May 3 23:09:51 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 23:09:54 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j4469p7J002579 for ; Tue, 3 May 2005 23:09:51 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 03 May 2005 23:09:52 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 3 May 2005 23:09:24 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AWH22068; Tue, 3 May 2005 23:09:16 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id XAA06944; Tue, 3 May 2005 23:09:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Mystery packet killing tg3 Date: Tue, 3 May 2005 23:09:15 -0700 Message-ID: Thread-Topic: Mystery packet killing tg3 Thread-Index: AcVQNIybHxh2ztwcRo6XfD92dZE2OQANmgSg From: "Michael Chan" To: "David S. Miller" cc: shemminger@osdl.org, jgarzik@pobox.com, netdev@oss.sgi.com X-WSS-ID: 6E66B8A51MW1780003-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j4469p7J002579 X-archive-position: 680 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev David S. Miller wrote: > I can't think of what else could be wedging the tg3. > Michael, any ideas? There are some 5703 specific programming > to consider: > The 5703 related settings in tg3 seem ok to me too. If Stephen says the stop_block error happens during normal ifdown and traffic was otherwise working fine before ifdown, then I think it may not even be a problem at all. Stopping the various state machines can be tricky and I'm not at all surprised that some state machines can fail to stop in some cases. They are all interconnected and even if you follow the stopping sequence in the programmer's reference manual, you may still end up with a situation where one state machine is waiting for another that has been stopped already. This is not a problem as tg3_stop_block() calls are always followed by a global chip reset that will clean up the whole chip. The purpose of tg3_stop_block() is to quiesce the chip and complete all DMA transactions before abruptly resetting the chip. If the DMA blocks would not stop, then it would be a bigger problem. Other tg3_stop_block() errors that I've seen, such as the ones reported by John Linville, were preceded by netdev watchdog timeouts. These netdev watchdog timeouts were real problems that needed to be solved. From mchan@broadcom.com Tue May 3 23:28:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 03 May 2005 23:28:14 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j446S97J003803 for ; Tue, 3 May 2005 23:28:11 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 03 May 2005 23:27:41 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 3 May 2005 23:27:38 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id AWH25736; Tue, 3 May 2005 23:27:38 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id XAA08694; Tue, 3 May 2005 23:27:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Mystery packet killing tg3 Date: Tue, 3 May 2005 23:27:38 -0700 Message-ID: Thread-Topic: Mystery packet killing tg3 Thread-Index: AcVQM89W4DZXZfpCTo+wPELXO7wCDQAPP+9A From: "Michael Chan" To: "Stephen Hemminger" , "David S. Miller" cc: jgarzik@pobox.com, netdev@oss.sgi.com X-WSS-ID: 6E66B4D70UW1703523-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j446S97J003803 X-archive-position: 681 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Stephen Hemminger wrote: > Initially, it reproduced everytime link came up, we > reconfigured the VLAN to > have a mirror port into a laptop to try and capture what was > happening, but when > we did that the bootup problem went away. It was in the tg3_reset_hw > during initial dev_open. > During initial dev_open, the TG3_FLAG_INIT_COMPLETE flag is not set so tg3_reset_hw() should not call tg3_abort_hw() where the stop_block calls are made. So there should be no stop_block errors. I think stop_block errors can only happen during dev_close, suspend, netdev watchdog, or ethtool "set" calls. From mroos@tartu.cyber.ee Wed May 4 00:04:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 00:04:08 -0700 (PDT) Received: from tartu.cyber.ee (tartu.cyber.ee [193.40.6.68]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j447447J006868 for ; Wed, 4 May 2005 00:04:05 -0700 Received: Message by Barricade tartu.cyber.ee with ESMTP id j446eBg29837 for ; Wed, 4 May 2005 09:40:11 +0300 Received: from rhn.tartu-labor (rhn.tartu-labor [192.168.74.17]) by ondatra.tartu-labor (Postfix) with ESMTP id 7BE0A14C48 for ; Wed, 4 May 2005 10:03:45 +0300 (EEST) Received: from mroos by rhn.tartu-labor with local (Exim 4.50) id 1DTDv7-0003vR-DS for netdev@oss.sgi.com; Wed, 04 May 2005 10:03:45 +0300 From: Meelis Roos To: netdev@oss.sgi.com Subject: Re: icmp_unreachable uses wrong ip In-Reply-To: <4276A400.2050306@trash.net> User-Agent: tin/1.7.8-20050315 ("Scalpay") (UNIX) (Linux/2.6.12-rc2 (i686)) Message-Id: Date: Wed, 04 May 2005 10:03:45 +0300 X-archive-position: 682 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mroos@linux.ee Precedence: bulk X-list: netdev PM> Your patch can't guarantee that the address used is the same that was PM> used as nexthop by the previous hop in the path when multiple addresses PM> are configured on the incoming interface. So I don't think it achieves PM> much of your goal of making debugging complicated topologies easier. Nevertheless this patch seems to be the most logical thing to do and is _much_ better than current state IMHO. Principle of least surprise. -- Meelis Roos From folkert@vanheusden.com Wed May 4 00:15:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 00:15:41 -0700 (PDT) Received: from keetweej.vanheusden.com (keetweej.xs4all.nl [213.84.46.114]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j447Fa7J007664 for ; Wed, 4 May 2005 00:15:37 -0700 Received: from keetweej.intranet.vanheusden.com (keetweej.intranet.vanheusden.com [192.168.64.99]) by keetweej.vanheusden.com (Postfix) with ESMTP id BC89A1CA366; Wed, 4 May 2005 09:15:22 +0200 (CEST) Date: Wed, 4 May 2005 09:15:20 +0200 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] optimize check in port-allocation code Message-ID: <20050504071516.GA1008@vanheusden.com> References: <20050420184419.GM20290@vanheusden.com> <20050424190427.11b4863e.davem@davemloft.net> <20050425061210.GB15167@vanheusden.com> <20050428120824.6cc9b345.davem@davemloft.net> <20050428212449.GC8774@vanheusden.com> <20050503143620.43cac50f.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503143620.43cac50f.davem@davemloft.net> Organization: www.unixexpert.nl X-Chameleon-Return-To: folkert@vanheusden.com X-Xfmail-Return-To: folkert@vanheusden.com X-Phonenumber: +31-6-41278122 X-URL: http://www.vanheusden.com/ X-PGP-KeyID: 1F28D8AE X-GPG-fingerprint: AC89 09CE 41F2 00B4 FCF2 B174 3019 0E8C 1F28 D8AE X-Key: http://pgp.surfnet.nl:11371/pks/lookup?op=get&search=0x1F28D8AE Read-Receipt-To: Reply-By: Wed May 4 21:24:53 CEST 2005 X-MSMail-Priority: High User-Agent: Mutt/1.5.9i From: folkert@vanheusden.com X-archive-position: 683 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: folkert@vanheusden.com Precedence: bulk X-list: netdev > > > > I'll resend it as an attachment (see attachment). > > > It still has spaces where there should be tabs, even though > > > you compressed the patch and used attachment. > > > The diff itself must already be corrupt before you attach > > > it. > > > Please double check that the patch you submit actually apply, > > > this will save me a lot of wasted time. > > Ok, I've redone them and tested if they patch cleanly, they now do. > > See them attached. > Both patches applied, thanks a lot. What about moving that rover++ to the end of the loop? Was my analysis correct? Folkert van Heusden -- Auto te koop, zie: http://www.vanheusden.com/daihatsu.php Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden. -------------------------------------------------------------------- UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) a try, it brings monitoring logfiles to a different level! See http://vanheusden.com/multitail/features.html for a feature-list. -------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE Get your PGP/GPG key signed at www.biglumber.com! From buytenh@wantstofly.org Wed May 4 01:30:11 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 01:30:13 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [212.238.201.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j448UA7J014550 for ; Wed, 4 May 2005 01:30:10 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id F24D82B0EC; Wed, 4 May 2005 10:29:51 +0200 (MEST) Date: Wed, 4 May 2005 10:29:51 +0200 From: Lennert Buytenhek To: Patrick McHardy Cc: Hasso Tepper , "J. Simonetti" , netdev@oss.sgi.com Subject: Re: icmp_unreachable uses wrong ip Message-ID: <20050504082951.GA13761@xi.wantstofly.org> References: <1115040079.5620.11.camel@jeroens.office.netland.nl> <200505030944.49175.hasso@estpak.ee> <4277BFA6.8090306@trash.net> <200505040235.33461.hasso@estpak.ee> <42780B44.8040803@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42780B44.8040803@trash.net> User-Agent: Mutt/1.4.1i X-archive-position: 684 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev On Wed, May 04, 2005 at 01:37:40AM +0200, Patrick McHardy wrote: > >>But when multiple addresses are used the result can be even more > >>confusing. I don't like inconsistent behaviour, and this patch works > >>sometimes and sometimes it doesn't. > > > > I see no behaviour you can define as "it doesn't work". Purpose of this > > patch is to provide info about links (not addresses, you can't have this > > info) used to forward packets and it does the job. > > Well, arguably it can be called "doesn't work" if addresses not used > at all during transmit of the packet show up in traceroute. That argument doesn't hold, since exactly the same situation occurs if we use the outgoing address as we do now. With asymmetric routing, the incoming interface, interface to the destination, and the interface back to the source might all be different, so we can end up with: path from r3 back to a +-------------------+ | | V | a --- r1 --- r2 --- r3 --- r4 --- r5 --- b The address of the 'upper' interface of r3 is likewise "not used at all during transmit of the packet", but it is the address we currently send the ICMP from. --L From hadi@cyberus.ca Wed May 4 03:40:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 03:40:37 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44AeY7J018230 for ; Wed, 4 May 2005 03:40:34 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DTHIl-00047g-6E for netdev@oss.sgi.com; Wed, 04 May 2005 06:40:23 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTHIe-0006v4-S5; Wed, 04 May 2005 06:40:17 -0400 Subject: Re: [patch/RFC]: Asynchronous IPsec processing benchmark. From: jamal Reply-To: hadi@cyberus.ca To: johnpol@2ka.mipt.ru Cc: Herbert Xu , netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" In-Reply-To: <1115127507.3414.58.camel@uganda> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> <20050503101447.GA29973@gondor.apana.org.au> <1115116295.3414.30.camel@uganda> <20050503102929.GA30097@gondor.apana.org.au> <1115117728.3414.48.camel@uganda> <1115127507.3414.58.camel@uganda> Content-Type: text/plain Organization: unknown Date: Wed, 04 May 2005 06:40:14 -0400 Message-Id: <1115203214.7665.58.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 685 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2005-03-05 at 17:38 +0400, Evgeniy Polyakov wrote: > Here are some numbers: > > ./netperf -l 60 -H gw -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 > -S 57344 > > TCP STREAM TEST to gw : +/-2.5% @ 99% conf. > > async-ipsec, 10^6bits/sec: 35.42 > sync-ipsec, 10^6bits/sec: 37.11 > > So even with existing timer deferring it is not noticebly slower [about > 4%]. > by "sync" i hope you mean the original code without your change? The one thing i see in your POC code that may affect numbers a bit is allocation of struct esp_async every time in the path. Perhaps precreate a pool of those and then just grab/return to/fro pool; BTW, you may need to incr ref counter of x pre-callback and decrement when done in callback. > And I think that benefits it provides definitely cost that price and > compile time option. I think Herberts concerns about latency should go away if you really have some proper crypto hardware. cheers, jamal From hadi@cyberus.ca Wed May 4 04:34:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 04:35:03 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44BYt7J023827 for ; Wed, 4 May 2005 04:34:56 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DTI9J-0007tT-26 for netdev@oss.sgi.com; Wed, 04 May 2005 05:34:41 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTI9I-0007FM-Fe; Wed, 04 May 2005 07:34:40 -0400 Subject: Re: IPsec performance From: jamal Reply-To: hadi@cyberus.ca To: Miika Komu Cc: Dave Dillow , Patrick McHardy , Netdev In-Reply-To: References: <1115099678.2953.3.camel@ori.thedillows.org> Content-Type: text/plain Organization: unknown Date: Wed, 04 May 2005 07:34:37 -0400 Message-Id: <1115206478.7665.100.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 686 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2005-03-05 at 09:44 +0300, Miika Komu wrote: > On Tue, 3 May 2005, Dave Dillow wrote: > > > On Tue, 2005-05-03 at 08:25 +0300, Miika Komu wrote: > > > However, this does explain why I got only 1.9 megabytes/s with 3DES. > > > > What was your hardware? Without knowing what you're running on, it's > > impossible to tell if that is good or bad. > > > > Linux Journal was getting ~5.5MB/s on a PIV 2.2GHz. > > I get ~2.1MB/s on a 550MHz Athlon. > > Intel Pentium III 500 MHz I tested on 2.4.x based on Davems code backport and contribution from Herbert > a year ago on a really bad Xeon 2.0Ghz(?), 32 bit bus mboard, e1000 NIC. I used a 2.4.x kernel because i was trying to compare against a broadcom SB1250 board which couldnt run 2.6.x - I also had to do a few tricks to get it to run/compile on MIPS and so may have contributed to perfomance degradation. In any case, the numbers between those two were not very different (even though the sb1250 was at i think 600Mhz). Unfortunately i lost the loaner sb1250 shortly after (it was fun to play with). I have my full results somewhere in another machine which i can lookup, but heres some summary data i had in my laptop: used: A) i) two flows ii) 4 flows iii) 8 flows all seem to reproduce the same aggregate throughput. B) static keying Tests and results ----------------- I: Transport mode: 1) Message Authentication: tested with hmac-md5 Should have done sha-1. Next time. a) 64 byte packets Input 100Mbps (148.8Kpps) output 112 Kpps This is about 75% of wire rate (75Mbps). b) 1400 byte packets 8712 (99% of wire rate) == about 17.4Kpps which is almost wire rate at 200Mbps at that packet size. Note we can never get 100% wire rate since the packet header grows because of the AH insertion. 2) Data encryption mode: 3DES/md5 a) 64 byte packets Peak achievement: 43Kpps == 30Mbps. b) 1400 byte packets Peak achievement: 1.8Kpps == 20Mbps. Now this result is very interesting. It clearly shows that 3DES is compute intensive i.e as the packet grows you get slower - quiet counterintuitive. An encryption chip would go along way to help with large packet sizes. Another observation: In other words given the synchronous nature of the crypto path, there is a threshold value where it may be valuable to use a crypto chip. The effects of this were actually demonstrated by Eugene Surovegin ; long thread of discussion on this on netdev. We need to find the threshold packet size where encryption starts overtaking general packet processing i.e where offloading becomes interesting if we stick with sync scheme. Another thing for s/ware based crypto is to improve the 3DES implementation as in assembler coding. Iam back on/off playing with this, so expect more results Real Soon Now. cheers, jamal From hadi@cyberus.ca Wed May 4 04:46:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 04:46:57 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44Bkr7J024796 for ; Wed, 4 May 2005 04:46:53 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DTIKw-0008Ps-IT for netdev@oss.sgi.com; Wed, 04 May 2005 07:46:42 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTIKq-0000O7-N1; Wed, 04 May 2005 07:46:36 -0400 Subject: Re: patch: Action repeat From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Patrick McHardy , netdev , "David S. Miller" In-Reply-To: <20050502150632.GM577@postel.suug.ch> References: <4273BBAA.6060405@trash.net> <1114882045.8929.123.camel@localhost.localdomain> <4273CAB7.6080403@trash.net> <1114890709.8929.147.camel@localhost.localdomain> <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Wed, 04 May 2005 07:46:34 -0400 Message-Id: <1115207194.7665.109.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 687 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2005-02-05 at 17:06 +0200, Thomas Graf wrote: > * jamal <1115035838.8929.236.camel@localhost.localdomain> 2005-05-02 08:10 [..] > > I am beginning to think that perhaps classid should stay as a local > > scope metadata and what Patrick suggested maybe the way out. Although i > > have to admit I dont like a generic function to have a parameter that > > only a very small set of users find useful. If we are going to allow a > > structure to be passed back and forth, perhaps it should also carry > > other things (in addition to _result). Need to think a little. > > What about if we introduce something like struct tcf_pkt_info as we > have it for ematches? I'm using it intensly to share information > from the classifier to ematches to extend and customize existing > classifier. Basically, something along those lines (eg struct tca_pkt_info) in which the tcf_result is one of the components should do it. I would be satisfied with this being the structure in the ->act() parameters because then it could also be used to pass action-metadata around (no action written so far needs such coordination, but its been one of those things i have been thinking of for some dynamic creations for example where the return code is insufficient to describe things). Patrick, either you or i could do it. It doesnt matter if at the moment the structure only contains tcf_result or elements of tcf_result because i will add more to it later. Then we could kill access to tc_classid in exec() > We could declare tc_classid as being global by definition > and hide the current use in the API? I'd really like to be able to > transfer classification results from one device to another. since tc_classid suddenly becomes available theres no question about the need for it being global - which is selectable at the meta action. Global I believe means you dont reset it when you clone/copy. skb->tc_verd is only cleared when we free the skb at the moment and transfered when we clone or copy. A bit or two could be reserved in the tc_verd to say "clear tc_classid" and have the meta action decide if it is global(dont clear) or not(clear - current behavior) during clone/copy . Does this sound reasonable? cheers, jamal From kaber@trash.net Wed May 4 05:15:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 05:15:49 -0700 (PDT) Received: from kaber.coreworks.de ([62.206.217.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44CFi7J026246 for ; Wed, 4 May 2005 05:15:45 -0700 Received: from localhost ([127.0.0.1]) by kaber.coreworks.de with esmtp (Exim 4.50) id 1DTImi-0005wE-Jx; Wed, 04 May 2005 14:15:24 +0200 Message-ID: <4278BCDC.8010208@trash.net> Date: Wed, 04 May 2005 14:15:24 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 X-Accept-Language: en MIME-Version: 1.0 To: hadi@cyberus.ca CC: Thomas Graf , netdev , "David S. Miller" Subject: Re: patch: Action repeat References: <4273BBAA.6060405@trash.net> <1114882045.8929.123.camel@localhost.localdomain> <4273CAB7.6080403@trash.net> <1114890709.8929.147.camel@localhost.localdomain> <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> In-Reply-To: <1115207194.7665.109.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 688 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev jamal wrote: > Patrick, either you or i could do it. It doesnt matter if at the moment > the structure only contains tcf_result or elements of tcf_result because > i will add more to it later. Then we could kill access to tc_classid in > exec() I'll do it, I have a few patches touching this code lying around anyway Regards Patrick From tgraf@suug.ch Wed May 4 05:32:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 05:32:10 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44CW37J027237 for ; Wed, 4 May 2005 05:32:04 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id D85521C0EB; Wed, 4 May 2005 14:31:57 +0200 (CEST) Date: Wed, 4 May 2005 14:31:57 +0200 From: Thomas Graf To: jamal Cc: Patrick McHardy , netdev , "David S. Miller" Subject: Re: patch: Action repeat Message-ID: <20050504123157.GA18452@postel.suug.ch> References: <4273CAB7.6080403@trash.net> <1114890709.8929.147.camel@localhost.localdomain> <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115207194.7665.109.camel@localhost.localdomain> X-archive-position: 689 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * jamal <1115207194.7665.109.camel@localhost.localdomain> 2005-05-04 07:46 > Basically, something along those lines (eg struct tca_pkt_info) in which > the tcf_result is one of the components should do it. > > I would be satisfied with this being the structure in the ->act() > parameters because then it could also be used to pass action-metadata > around (no action written so far needs such coordination, but its been > one of those things i have been thinking of for some dynamic creations > for example where the return code is insufficient to describe things). > Patrick, either you or i could do it. It doesnt matter if at the moment > the structure only contains tcf_result or elements of tcf_result because > i will add more to it later. Then we could kill access to tc_classid in > exec() Sounds good. > Global I believe means you dont reset it when you clone/copy. > skb->tc_verd is only cleared when we free the skb at the moment and > transfered when we clone or copy. A bit or two could be reserved in the > tc_verd to say "clear tc_classid" and have the meta action decide if it > is global(dont clear) or not(clear - current behavior) during > clone/copy . Does this sound reasonable? I have no objections but fail to see why we want to clear it anyway? From hadi@cyberus.ca Wed May 4 05:59:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 05:59:32 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44CxQ7J028673 for ; Wed, 4 May 2005 05:59:27 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DTJT6-0004SE-6d for netdev@oss.sgi.com; Wed, 04 May 2005 06:59:12 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTJT5-0006Xe-BV; Wed, 04 May 2005 08:59:11 -0400 Subject: Re: patch: Action repeat From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Patrick McHardy , netdev , "David S. Miller" In-Reply-To: <20050504123157.GA18452@postel.suug.ch> References: <4273CAB7.6080403@trash.net> <1114890709.8929.147.camel@localhost.localdomain> <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Wed, 04 May 2005 08:59:08 -0400 Message-Id: <1115211549.7665.140.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 691 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Wed, 2005-04-05 at 14:31 +0200, Thomas Graf wrote: > * jamal <1115207194.7665.109.camel@localhost.localdomain> 2005-05-04 07:46 > > tc_verd to say "clear tc_classid" and have the meta action decide if it > > is global(dont clear) or not(clear - current behavior) during > > clone/copy . Does this sound reasonable? > > I have no objections but fail to see why we want to clear it anyway? > If its scope is local i.e for one device, then not reseting could confuse the next device that sees it and tries to classify on it. cheers, jamal From matti.aarnio@zmailer.org Wed May 4 05:58:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 05:58:29 -0700 (PDT) Received: from mail.zmailer.org (van-1-67.lab.dnainternet.fi [62.78.96.67]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44CwK7J028479 for ; Wed, 4 May 2005 05:58:20 -0700 Received: (mea@mea-ext) by mail.zmailer.org id S1611277AbVEDM5w (ORCPT ); Wed, 4 May 2005 15:57:52 +0300 Date: Wed, 4 May 2005 15:57:52 +0300 From: Matti Aarnio To: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: TCP4/6 socket closure causing system crash.. Message-ID: <20050504125752.GA7399@mea-ext.zmailer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 690 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: matti.aarnio@zmailer.org Precedence: bulk X-list: netdev I have CVS-pserver running under a chroot wrapper. Recently system has become unresponsive the instance somebody refers to the pserver... I have three kernels to choose from: title Fedora Core (2.6.11-1.1282_FC4smp) title Fedora Core (2.6.11-1.1276_FC4smp) title Fedora Core (2.6.11-1.1191_FC4smp) First two crash, third works just fine for this workset. Serial console capture tells following: ----------------- Kernel 2.6.11-1.1282_FC4smp on an i686 mismatch in kmem_cache_free: expected cache f78ee500, got f7972800 f7972800 is TCP. f78ee500 is TCPv6. Badness in cache_free_debugcheck at mm/slab.c:1926 (Not tainted) [] cache_free_debugcheck+0xb3/0x222 [] sk_free+0x7e/0xff [] kmem_cache_free+0x2a/0x69 [] sk_free+0x7e/0xff [] __kfree_skb+0x54/0x146 [] scsi_finish_command+0x7d/0xd1 [scsi_mod] [] net_tx_action+0x4e/0x121 [] scsi_softirq+0x9a/0xbf [scsi_mod] [] __do_softirq+0x72/0xdc [] do_softirq+0x4b/0x4f ======================= [] do_IRQ+0x55/0x86 [] tcp_v4_destroy_sock+0x9/0x16f [] common_interrupt+0x1a/0x20 [] cpuset_zonelist_valid_mems_allowed+0x3/0x3f [] _spin_lock+0x12/0x40 [] __fput+0xbe/0x10e [] _atomic_dec_and_lock+0x27/0x44 [] dput+0xe5/0x1df [] __fput+0xc5/0x10e [] filp_close+0x4f/0x6d [] put_files_struct+0x6e/0xe7 [] do_exit+0xfc/0x36a [] __dequeue_signal+0xe9/0x1aa [] do_group_exit+0x29/0x90 [] get_signal_to_deliver+0x263/0x371 [] do_signal+0x5d/0x111 [] poison_obj+0x20/0x3d [] cache_free_debugcheck+0x138/0x222 [] sys_open+0x4a/0x5b [] do_page_fault+0x0/0x6a7 [] do_notify_resume+0x28/0x39 [] work_notifysig+0x13/0x15 slab error in cache_free_debugcheck(): cache `TCP': double free, or memory outside object was overwritten [] cache_free_debugcheck+0x19e/0x222 [] sk_free+0x7e/0xff [] kmem_cache_free+0x2a/0x69 [] sk_free+0x7e/0xff [] __kfree_skb+0x54/0x146 [] scsi_finish_command+0x7d/0xd1 [scsi_mod] [] net_tx_action+0x4e/0x121 [] scsi_softirq+0x9a/0xbf [scsi_mod] [] __do_softirq+0x72/0xdc [] do_softirq+0x4b/0x4f ======================= [] do_IRQ+0x55/0x86 [] tcp_v4_destroy_sock+0x9/0x16f [] common_interrupt+0x1a/0x20 [] cpuset_zonelist_valid_mems_allowed+0x3/0x3f [] _spin_lock+0x12/0x40 [] __fput+0xbe/0x10e [] _atomic_dec_and_lock+0x27/0x44 [] dput+0xe5/0x1df [] __fput+0xc5/0x10e [] filp_close+0x4f/0x6d [] put_files_struct+0x6e/0xe7 [] do_exit+0xfc/0x36a [] __dequeue_signal+0xe9/0x1aa [] do_group_exit+0x29/0x90 [] get_signal_to_deliver+0x263/0x371 [] do_signal+0x5d/0x111 [] poison_obj+0x20/0x3d [] cache_free_debugcheck+0x138/0x222 [] sys_open+0x4a/0x5b [] do_page_fault+0x0/0x6a7 [] do_notify_resume+0x28/0x39 [] work_notifysig+0x13/0x15 f6456f10: redzone 1: 0x170fc2a5, redzone 2: 0x0. ------------[ cut here ]------------ kernel BUG at mm/slab.c:1946! invalid operand: 0000 [#1] SMP Modules linked in: parport_pc lp parport w83627hf eeprom i2c_sensor i2c_isa ip_conntrack_ftp ipt_conntrack iptable_mangle ipt_state ip_conntrack ipt_REJECT iptable_filter ip_tables ip6table_filter ip6_tables md5 ipv6 dm_mod video button battery ac ohci1394 ieee1394 uhci_hcd ehci_hcd hw_random tpm_nsc tpm i2c_i801 i2c_core snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc e100 mii sk98lin dummy floppy ext3 jbd raid1 qla2300 qla2xxx scsi_transport_fc sata_sil ata_piix libata aic7xxx scsi_transport_spi sd_mod scsi_mod CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010016 (2.6.11-1.1282_FC4smp) EIP is at cache_free_debugcheck+0x215/0x222 eax: f6456dcc ebx: 00012c00 ecx: 00000ca8 edx: 00000144 esi: f7972800 edi: f6456124 ebp: f6456f10 esp: c040bf48 ds: 007b es: 007b ss: 0068 Process cvs (pid: 7668, threadinfo=c040b000 task=d7882020) Stack: c03206d4 f6456f10 170fc2a5 00000000 c0451840 c02a42a7 f6456f14 f7972800 f7d79f18 00000286 c014d20d f6456f14 00000000 c2012480 0000000a c02a42a7 f7ce0fc0 f7ce0ff8 c23b002c f31b8b3c f51dde3c c02a58c1 f7d5b8f4 0000000a Call Trace: [] sk_free+0x7e/0xff [] kmem_cache_free+0x2a/0x69 [] sk_free+0x7e/0xff [] __kfree_skb+0x54/0x146 [] scsi_finish_command+0x7d/0xd1 [scsi_mod] [] net_tx_action+0x4e/0x121 [] scsi_softirq+0x9a/0xbf [scsi_mod] [] __do_softirq+0x72/0xdc [] do_softirq+0x4b/0x4f ======================= [] do_IRQ+0x55/0x86 [] tcp_v4_destroy_sock+0x9/0x16f [] common_interrupt+0x1a/0x20 [] cpuset_zonelist_valid_mems_allowed+0x3/0x3f [] _spin_lock+0x12/0x40 [] __fput+0xbe/0x10e [] _atomic_dec_and_lock+0x27/0x44 [] dput+0xe5/0x1df [] __fput+0xc5/0x10e [] filp_close+0x4f/0x6d [] put_files_struct+0x6e/0xe7 [] do_exit+0xfc/0x36a [] __dequeue_signal+0xe9/0x1aa [] do_group_exit+0x29/0x90 [] get_signal_to_deliver+0x263/0x371 [] do_signal+0x5d/0x111 [] poison_obj+0x20/0x3d [] cache_free_debugcheck+0x138/0x222 [] sys_open+0x4a/0x5b [] do_page_fault+0x0/0x6a7 [] do_notify_resume+0x28/0x39 [] work_notifysig+0x13/0x15 Code: 8b 9e b4 00 00 00 e9 d0 fe ff ff 89 ea 89 f0 e8 fb e3 ff ff 81 38 a5 c2 0f 17 75 87 eb c4 0f 0b 99 07 53 fb 31 c0 e9 d9 fe ff ff <0f> 0b 9a 07 53 fb 31 c0 e9 da fe ff ff 55 57 56 53 83 ec 14 89 <0>Kernel panic - not syncing: Fatal exception in interrupt [] panic+0x45/0x1e8 [] die+0x17b/0x185 [] do_invalid_op+0x0/0xab [] do_invalid_op+0xa2/0xab [] cache_free_debugcheck+0x215/0x222 [] call_console_drivers+0x80/0x14c [] release_console_sem+0x78/0xb5 [] vprintk+0x1f5/0x2a9 [] error_code+0x4f/0x54 [] cache_free_debugcheck+0x215/0x222 [] sk_free+0x7e/0xff [] kmem_cache_free+0x2a/0x69 [] sk_free+0x7e/0xff [] __kfree_skb+0x54/0x146 [] scsi_finish_command+0x7d/0xd1 [scsi_mod] [] net_tx_action+0x4e/0x121 [] scsi_softirq+0x9a/0xbf [scsi_mod] [] __do_softirq+0x72/0xdc [] do_softirq+0x4b/0x4f ======================= [] do_IRQ+0x55/0x86 [] tcp_v4_destroy_sock+0x9/0x16f [] common_interrupt+0x1a/0x20 [] cpuset_zonelist_valid_mems_allowed+0x3/0x3f [] _spin_lock+0x12/0x40 [] __fput+0xbe/0x10e [] _atomic_dec_and_lock+0x27/0x44 [] dput+0xe5/0x1df [] __fput+0xc5/0x10e [] filp_close+0x4f/0x6d [] put_files_struct+0x6e/0xe7 [] do_exit+0xfc/0x36a [] __dequeue_signal+0xe9/0x1aa [] do_group_exit+0x29/0x90 [] get_signal_to_deliver+0x263/0x371 [] do_signal+0x5d/0x111 [] poison_obj+0x20/0x3d [] cache_free_debugcheck+0x138/0x222 [] sys_open+0x4a/0x5b [] do_page_fault+0x0/0x6a7 [] do_notify_resume+0x28/0x39 [] work_notifysig+0x13/0x15 From tgraf@suug.ch Wed May 4 06:28:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 06:28:22 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44DSG7J030259 for ; Wed, 4 May 2005 06:28:16 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id CCF831C0EB; Wed, 4 May 2005 15:28:22 +0200 (CEST) Date: Wed, 4 May 2005 15:28:22 +0200 From: Thomas Graf To: jamal Cc: Patrick McHardy , netdev , "David S. Miller" Subject: Re: patch: Action repeat Message-ID: <20050504132822.GB18452@postel.suug.ch> References: <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115211549.7665.140.camel@localhost.localdomain> X-archive-position: 692 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * jamal <1115211549.7665.140.camel@localhost.localdomain> 2005-05-04 08:59 > On Wed, 2005-04-05 at 14:31 +0200, Thomas Graf wrote: > > * jamal <1115207194.7665.109.camel@localhost.localdomain> 2005-05-04 07:46 > > > > tc_verd to say "clear tc_classid" and have the meta action decide if it > > > is global(dont clear) or not(clear - current behavior) during > > > clone/copy . Does this sound reasonable? > > > > I have no objections but fail to see why we want to clear it anyway? > > > > If its scope is local i.e for one device, then not reseting could > confuse the next device that sees it and tries to classify on it. OK, so we're not talking about a reset in action_exec() but rather in tc_classify() or enqueue()? From tgraf@suug.ch Wed May 4 06:32:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 06:33:06 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44DWw7J031061 for ; Wed, 4 May 2005 06:32:58 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 24D491C0EB; Wed, 4 May 2005 15:33:06 +0200 (CEST) Date: Wed, 4 May 2005 15:33:06 +0200 From: Thomas Graf To: jamal Cc: Patrick McHardy , netdev , "David S. Miller" Subject: Re: patch: Action repeat Message-ID: <20050504133306.GC18452@postel.suug.ch> References: <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050504132822.GB18452@postel.suug.ch> X-archive-position: 693 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * Thomas Graf <20050504132822.GB18452@postel.suug.ch> 2005-05-04 15:28 > * jamal <1115211549.7665.140.camel@localhost.localdomain> 2005-05-04 08:59 > > On Wed, 2005-04-05 at 14:31 +0200, Thomas Graf wrote: > > > * jamal <1115207194.7665.109.camel@localhost.localdomain> 2005-05-04 07:46 > > > > > > tc_verd to say "clear tc_classid" and have the meta action decide if it > > > > is global(dont clear) or not(clear - current behavior) during > > > > clone/copy . Does this sound reasonable? > > > > > > I have no objections but fail to see why we want to clear it anyway? > > > > > > > If its scope is local i.e for one device, then not reseting could > > confuse the next device that sees it and tries to classify on it. > > OK, so we're not talking about a reset in action_exec() but rather > in tc_classify() or enqueue()? Sorry, little bit to vague, what I mean is before the first call to tc_classify() or enqueue() on a new device. From hadi@cyberus.ca Wed May 4 06:33:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 06:33:41 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44DXd7J031132 for ; Wed, 4 May 2005 06:33:39 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DTK0D-0004oY-GJ for netdev@oss.sgi.com; Wed, 04 May 2005 09:33:25 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTK0A-00056n-Vm; Wed, 04 May 2005 09:33:23 -0400 Subject: Re: patch: Action repeat From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Patrick McHardy , netdev , "David S. Miller" In-Reply-To: <20050504132822.GB18452@postel.suug.ch> References: <20050430200848.GF577@postel.suug.ch> <1114894202.8929.165.camel@localhost.localdomain> <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Wed, 04 May 2005 09:33:20 -0400 Message-Id: <1115213600.7665.166.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 694 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Wed, 2005-04-05 at 15:28 +0200, Thomas Graf wrote: > * jamal <1115211549.7665.140.camel@localhost.localdomain> 2005-05-04 08:59 > > On Wed, 2005-04-05 at 14:31 +0200, Thomas Graf wrote: > > > * jamal <1115207194.7665.109.camel@localhost.localdomain> 2005-05-04 07:46 > > > > > > tc_verd to say "clear tc_classid" and have the meta action decide if it > > > > is global(dont clear) or not(clear - current behavior) during > > > > clone/copy . Does this sound reasonable? > > > > > > I have no objections but fail to see why we want to clear it anyway? > > > > > > > If its scope is local i.e for one device, then not reseting could > > confuse the next device that sees it and tries to classify on it. > > OK, so we're not talking about a reset in action_exec() but rather > in tc_classify() or enqueue()? in skb_clone() and friends. Look at CONFIG_NET_CLS_ACT in net/core/skbuff.c cheers, jamal From tgraf@suug.ch Wed May 4 06:48:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 06:48:12 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44Dm77J000302 for ; Wed, 4 May 2005 06:48:10 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 4BE831C0EB; Wed, 4 May 2005 15:48:15 +0200 (CEST) Date: Wed, 4 May 2005 15:48:15 +0200 From: Thomas Graf To: jamal Cc: Patrick McHardy , netdev , "David S. Miller" Subject: Re: patch: Action repeat Message-ID: <20050504134815.GD18452@postel.suug.ch> References: <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> <1115213600.7665.166.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115213600.7665.166.camel@localhost.localdomain> X-archive-position: 695 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * jamal <1115213600.7665.166.camel@localhost.localdomain> 2005-05-04 09:33 > On Wed, 2005-04-05 at 15:28 +0200, Thomas Graf wrote: > > * jamal <1115211549.7665.140.camel@localhost.localdomain> 2005-05-04 08:59 > > > If its scope is local i.e for one device, then not reseting could > > > confuse the next device that sees it and tries to classify on it. > > > > OK, so we're not talking about a reset in action_exec() but rather > > in tc_classify() or enqueue()? > > in skb_clone() and friends. > Look at CONFIG_NET_CLS_ACT in net/core/skbuff.c Yes this solves the case for dummy devices etc but how would this cause a reset on the way from ingress to egress? From hadi@cyberus.ca Wed May 4 06:53:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 06:53:23 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44DrL7J000963 for ; Wed, 4 May 2005 06:53:21 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DTKJI-00048H-E4 for netdev@oss.sgi.com; Wed, 04 May 2005 09:53:08 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTKJF-0000PU-0b; Wed, 04 May 2005 09:53:05 -0400 Subject: Re: patch: Action repeat From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Patrick McHardy , netdev , "David S. Miller" In-Reply-To: <20050504134815.GD18452@postel.suug.ch> References: <20050430215550.GH577@postel.suug.ch> <1114900485.8929.171.camel@localhost.localdomain> <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> <1115213600.7665.166.camel@localhost.localdomain> <20050504134815.GD18452@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Wed, 04 May 2005 09:53:02 -0400 Message-Id: <1115214782.7665.184.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 696 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Wed, 2005-04-05 at 15:48 +0200, Thomas Graf wrote: > * jamal <1115213600.7665.166.camel@localhost.localdomain> 2005-05-04 09:33 > > in skb_clone() and friends. > > Look at CONFIG_NET_CLS_ACT in net/core/skbuff.c > > Yes this solves the case for dummy devices etc but how would > this cause a reset on the way from ingress to egress? If the verdict is not to reset, there should be no clearing of those fields from ingress -> egress until the skb is either freed or someone else along the path resets it. Cloning or copying inherits. Am i missing something? cheers, jamal From tgraf@suug.ch Wed May 4 07:05:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 07:05:39 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44E5X7J001801 for ; Wed, 4 May 2005 07:05:33 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id B36A31C0EB; Wed, 4 May 2005 16:05:40 +0200 (CEST) Date: Wed, 4 May 2005 16:05:40 +0200 From: Thomas Graf To: jamal Cc: Patrick McHardy , netdev , "David S. Miller" Subject: Re: patch: Action repeat Message-ID: <20050504140540.GE18452@postel.suug.ch> References: <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> <1115213600.7665.166.camel@localhost.localdomain> <20050504134815.GD18452@postel.suug.ch> <1115214782.7665.184.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115214782.7665.184.camel@localhost.localdomain> X-archive-position: 697 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * jamal <1115214782.7665.184.camel@localhost.localdomain> 2005-05-04 09:53 > On Wed, 2005-04-05 at 15:48 +0200, Thomas Graf wrote: > > * jamal <1115213600.7665.166.camel@localhost.localdomain> 2005-05-04 09:33 > > > > in skb_clone() and friends. > > > Look at CONFIG_NET_CLS_ACT in net/core/skbuff.c > > > > Yes this solves the case for dummy devices etc but how would > > this cause a reset on the way from ingress to egress? > > If the verdict is not to reset, there should be no clearing of those > fields from ingress -> egress until the skb is either freed or someone > else along the path resets it. Cloning or copying inherits. Am i missing > something? I guess not but we might have a different understanding of when to reset. From my point of view the only reason to reset any meta data is to provide a certain scope a set of new fresh and clean sheets to play around. Assuming we define global as everything and local as per device/(ingress|egress) then we definitely need to invoke a reset on the way over to egress. From hadi@cyberus.ca Wed May 4 07:24:07 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 07:24:18 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44EO57J002959 for ; Wed, 4 May 2005 07:24:07 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1DTKn3-0008Jy-B4 for netdev@oss.sgi.com; Wed, 04 May 2005 10:23:53 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DTKn1-00067q-By; Wed, 04 May 2005 10:23:51 -0400 Subject: Re: patch: Action repeat From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: Patrick McHardy , netdev , "David S. Miller" In-Reply-To: <20050504140540.GE18452@postel.suug.ch> References: <20050430235809.GI577@postel.suug.ch> <1115035838.8929.236.camel@localhost.localdomain> <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> <1115213600.7665.166.camel@localhost.localdomain> <20050504134815.GD18452@postel.suug.ch> <1115214782.7665.184.camel@localhost.localdomain> <20050504140540.GE18452@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Wed, 04 May 2005 10:23:49 -0400 Message-Id: <1115216629.7906.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 698 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Wed, 2005-04-05 at 16:05 +0200, Thomas Graf wrote: > Assuming we define global as everything and local > as per device/(ingress|egress) then we definitely need to invoke > a reset on the way over to egress. Agreed. So shall we stick then to just make it a global-only? cheers, jamal From tgraf@suug.ch Wed May 4 07:53:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 07:53:40 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44ErZ7J004294 for ; Wed, 4 May 2005 07:53:35 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id B11E71C0EB; Wed, 4 May 2005 16:53:41 +0200 (CEST) Date: Wed, 4 May 2005 16:53:41 +0200 From: Thomas Graf To: jamal Cc: Patrick McHardy , netdev , "David S. Miller" Subject: Re: patch: Action repeat Message-ID: <20050504145341.GG18452@postel.suug.ch> References: <20050502150632.GM577@postel.suug.ch> <1115207194.7665.109.camel@localhost.localdomain> <20050504123157.GA18452@postel.suug.ch> <1115211549.7665.140.camel@localhost.localdomain> <20050504132822.GB18452@postel.suug.ch> <1115213600.7665.166.camel@localhost.localdomain> <20050504134815.GD18452@postel.suug.ch> <1115214782.7665.184.camel@localhost.localdomain> <20050504140540.GE18452@postel.suug.ch> <1115216629.7906.4.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115216629.7906.4.camel@localhost.localdomain> X-archive-position: 699 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev * jamal <1115216629.7906.4.camel@localhost.localdomain> 2005-05-04 10:23 > On Wed, 2005-04-05 at 16:05 +0200, Thomas Graf wrote: > > > > Assuming we define global as everything and local > > as per device/(ingress|egress) then we definitely need to invoke > > a reset on the way over to egress. > > Agreed. So shall we stick then to just make it a global-only? As long as we can't find a way to have a well defined local scope which is both easy to implement and easy to understand for the user a global-only scope with the ability for the user to reset the value via the meta action is most reasonable to me. We need to define this well because it will get to be the backend for any advanced classyfing over multiple devices. I will give it some more thinking in the background, in the meantime I suggest to implement it global-only for now. The global classid issue is the next item on my list and I should be able to come up with something this week after posting rtnetlink neighbour tables patches and the new generic textsearch API + skb search bits + textsearch ematch which will provide optimized textsearching facitilies including a simple regular expression for both linear and non-linear skbs. From johnpol@2ka.mipt.ru Wed May 4 09:12:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 09:12:45 -0700 (PDT) Received: from 2ka.mipt.ru (relay.2ka.mipt.ru [194.85.82.65]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44GCd7J011409 for ; Wed, 4 May 2005 09:12:40 -0700 Received: from zanzibar.2ka.mipt.ru (zanzibar.2ka.mipt.ru [194.85.82.77]) by 2ka.mipt.ru (8.12.11/8.12.11) with ESMTP id j44GBg1l020484; Wed, 4 May 2005 20:11:42 +0400 Date: Wed, 4 May 2005 20:11:43 +0400 From: Evgeniy Polyakov To: hadi@cyberus.ca Cc: Herbert Xu , netdev@oss.sgi.com, Patrick McHardy , "David S. Miller" Subject: Re: [patch/RFC]: Asynchronous IPsec processing benchmark. Message-ID: <20050504201143.7f6bdcce@zanzibar.2ka.mipt.ru> In-Reply-To: <1115203214.7665.58.camel@localhost.localdomain> References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au> <1115115502.3414.22.camel@uganda> <20050503101447.GA29973@gondor.apana.org.au> <1115116295.3414.30.camel@uganda> <20050503102929.GA30097@gondor.apana.org.au> <1115117728.3414.48.camel@uganda> <1115127507.3414.58.camel@uganda> <1115203214.7665.58.camel@localhost.localdomain> Reply-To: johnpol@2ka.mipt.ru Organization: MIPT X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.5 (2ka.mipt.ru [194.85.82.65]); Wed, 04 May 2005 20:11:43 +0400 (MSD) X-archive-position: 701 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: johnpol@2ka.mipt.ru Precedence: bulk X-list: netdev On Wed, 04 May 2005 06:40:14 -0400 jamal wrote: > On Tue, 2005-03-05 at 17:38 +0400, Evgeniy Polyakov wrote: > > Here are some numbers: > > > > ./netperf -l 60 -H gw -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 > > -S 57344 > > > > TCP STREAM TEST to gw : +/-2.5% @ 99% conf. > > > > async-ipsec, 10^6bits/sec: 35.42 > > sync-ipsec, 10^6bits/sec: 37.11 > > > > So even with existing timer deferring it is not noticebly slower [about > > 4%]. > > > > by "sync" i hope you mean the original code without your change? Yes, it is vanilla 2.6.12-rc2 kernel with native IPsec. > The one thing i see in your POC code that may affect numbers a bit is > allocation of struct esp_async every time in the path. Perhaps precreate > a pool of those and then just grab/return to/fro pool; That could be skb too - since both skb/kmalloc atomic allocations end up in kmem_cache_alloc(). > BTW, you may need to incr ref counter of x pre-callback and decrement > when done in callback. It looks like dst entry holding is enough since direct dst->output(), i.e. xfrm_state->output(), call itself is not protected by reference counter, but dst entry is being held during that call. > > And I think that benefits it provides definitely cost that price and > > compile time option. > > I think Herberts concerns about latency should go away if you really > have some proper crypto hardware. Unfortunately I do not have hardware crypto accelerator setup currently [board freezes before even monitor and keyboard blink with my HIFN card, it looks like bus arbitrage problem], so I can not provide real numbers with it, but I will set acrypto with several software crypto providers with that patch on SMP [scheiße, I burned second HT Xeon] (1+1HT) up, and will rerun the test soon. > cheers, > jamal > Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt From Robert.Olsson@data.slu.se Wed May 4 09:10:38 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 09:10:47 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44GAb7J011040 for ; Wed, 4 May 2005 09:10:37 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j44GAKfd019974; Wed, 4 May 2005 18:10:20 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 15B51EE1E9; Wed, 4 May 2005 18:10:20 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17016.62444.34282.625407@robur.slu.se> Date: Wed, 4 May 2005 18:10:20 +0200 To: netdev@oss.sgi.com Cc: Robert Olsson , Jens.Laas@data.slu.se Subject: (diet-)FIB alternative fib_hlist.c X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-archive-position: 700 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Hello! fib_hlist is the smallest and simpliest routing algo we could think of it's just a sorted (h)list. routing (FIB lookup) performance. dst hash is not used. fib_hlist fib_hash test routing table size ----------------------------------------------------- 444 kpps 433 kpps Single flow. local=19/main=5 entries 433 kpps 431 kpps rDoS. local=19/main=5 0.2 kpps 198 kpps rDoS local=19/main=123946 As seen fib_hlist is catastrophe for large routing tables as expected but performs surprisingly well for ordinary routing tables so it should be fine for most hosts and servers. The patch has config option to select FIB. Probably we soon want to specify differnt lookup schemes for different tables say for local table fib_hash or fib_hlist. While for large main table fib_hash2/fib_trie would be better option. Cheers. --ro --- net/ipv4/Makefile.orig 2005-04-15 13:42:12.000000000 +0200 +++ net/ipv4/Makefile 2005-05-04 16:24:27.000000000 +0200 @@ -7,8 +7,10 @@ ip_output.o ip_sockglue.o \ tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o tcp_minisocks.o \ datagram.o raw.o udp.o arp.o icmp.o devinet.o af_inet.o igmp.o \ - sysctl_net_ipv4.o fib_frontend.o fib_semantics.o fib_hash.o + sysctl_net_ipv4.o fib_frontend.o fib_semantics.o +obj-$(CONFIG_IP_FIB_HASH) += fib_hash.o +obj-$(CONFIG_IP_FIB_HLIST) += fib_hlist.o obj-$(CONFIG_PROC_FS) += proc.o obj-$(CONFIG_IP_MULTIPLE_TABLES) += fib_rules.o obj-$(CONFIG_IP_MROUTE) += ipmr.o --- net/ipv4/Kconfig.orig 2005-04-15 13:41:52.000000000 +0200 +++ net/ipv4/Kconfig 2005-05-04 16:23:58.000000000 +0200 @@ -1,6 +1,27 @@ # # IP configuration # +choice + prompt "Choose IP: FIB lookup"" + depends on INET + default IP_FIB_HASH + +config IP_FIB_HASH + bool "FIB_HASH" + ---help--- + Current FIB is very proven and good enough for most users. + +config IP_FIB_HLIST + bool "FIB_HLIST" + depends on INET && EXPERIMENTAL + ---help--- + + Use new very simple and minimalistic lookup algorithm. It should + only be used for small routing tables. Performance is equal to + FIB_HASH with small tables but with less memory use. + +endchoice + config IP_MULTICAST bool "IP: multicasting" depends on INET --- /dev/null 2005-04-14 15:05:36.930846264 +0200 +++ net/ipv4/fib_hlist.c 2005-05-03 20:07:24.000000000 +0200 @@ -0,0 +1,719 @@ +/* + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Robert Olsson Uppsala Universitet + * & Swedish University of Agricultural Sciences. + * + * Jens Laas Swedish University of + * Agricultural Sciences. + * + * Hans Liss Uppsala Universitet + * + * Code from fib_hash has been reused which includes the following header: + * + * Authors: Alexey Kuznetsov, + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +/* + * An alternative FIB for applications with small routing table + * The simplest and smallest routing algo eveer all routes is keept + * in a single (h)list sorted by prefix length. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "fib_lookup.h" + +#define VERSION "0.04" + +typedef unsigned int t_key; + +struct fib_hlist_info { + struct hlist_node hlist; + u32 plen; + u32 pfx; + struct list_head falh; +}; + +struct fib_hlist_table { + struct hlist_head list; + rwlock_t lock; +}; + +extern void rtmsg_fib(int event, u32 key, struct fib_alias *fa, int z, int tb_id, + struct nlmsghdr *n, struct netlink_skb_parms *req); + +extern struct fib_alias *fib_find_alias(struct list_head *fah, u8 tos, u32 prio); +extern int fib_detect_death(struct fib_info *fi, int order, + struct fib_info **last_resort, int *last_idx, int *dflt); + +static int debug = 0; +static kmem_cache_t *fn_alias_kmem; +static kmem_cache_t *fn_hlist_kmem; + +static inline void fn_free_node(struct fib_hlist_info * f) +{ + kmem_cache_free(fn_hlist_kmem, f); +} + +/* Candiate for fib_semantics */ + +static void fn_free_alias(struct fib_alias *fa) +{ + fib_release_info(fa->fa_info); + kmem_cache_free(fn_alias_kmem, fa); +} + +static struct fib_hlist_info *fib_find_node(struct hlist_head *head, u32 key, int plen) +{ + struct hlist_node *node; + struct fib_hlist_info *fhi; + + hlist_for_each_entry(fhi, node, head, hlist) { + + if ( fhi->plen == plen && fhi->pfx == key ) + return fhi; + } + return NULL; +} + +static void fib_insert_node(struct hlist_head *head, struct fib_hlist_info *new) +{ + struct fib_hlist_info *fhi=NULL, *last=NULL; + struct hlist_node *node, *tmp; + + if(hlist_empty(head)) + hlist_add_head(&new->hlist, head); + else { + hlist_for_each_entry_safe(fhi, node, tmp, head, hlist) { + + if (new->plen > fhi->plen) + break; + + last = fhi; + } + if(last) + hlist_add_after(&last->hlist, &new->hlist); + else + hlist_add_before(&new->hlist, &fhi->hlist); + } +} + +static int +fn_hlist_insert(struct fib_table *tb, struct rtmsg *r, struct kern_rta *rta, + struct nlmsghdr *nlhdr, struct netlink_skb_parms *req) +{ + struct fib_hlist_table *t = (struct fib_hlist_table *) tb->tb_data; + int plen = r->rtm_dst_len; + int type = r->rtm_type; + u8 tos = r->rtm_tos; + u32 key, mask; + int err = 0; + struct fib_alias *fa=NULL, *new_fa; + struct list_head *fa_head=NULL; + struct fib_info *fi; + struct fib_hlist_info *fhi=NULL, *new_fhi; + + if (plen > 32) + return -EINVAL; + + key = 0; + if (rta->rta_dst) + memcpy(&key, rta->rta_dst, 4); + + key = ntohl(key); + mask = ntohl( inet_make_mask(plen) ); + + if(key & ~mask) + return -EINVAL; + + key = key & mask; + + if(debug) + printk("fn_hlist_insert id=%d %08x/%d\n", tb->tb_id, key, plen); + + if ((fi = fib_create_info(r, rta, nlhdr, &err)) == NULL) + return err; + + fhi = fib_find_node(&t->list, key, plen); + + if (!fhi) + fa = NULL; + else { + fa_head = &fhi->falh; + fa = fib_find_alias(fa_head, tos, fi->fib_priority); + } + + /* Now fa, if non-NULL, points to the first fib alias + * with the same keys [prefix,tos,priority], if such key already + * exists or to the node before which we will insert new one. + * + * If fa is NULL, we will need to allocate a new one and + * insert to the head of f. + * + * If f is NULL, no fib node matched the destination key + * and we need to allocate a new one of those as well. + */ + + if (fa && + fa->fa_info->fib_priority == fi->fib_priority) { + struct fib_alias *fa_orig; + + err = -EEXIST; + if (nlhdr->nlmsg_flags & NLM_F_EXCL) + goto out; + + if (nlhdr->nlmsg_flags & NLM_F_REPLACE) { + struct fib_info *fi_drop; + u8 state; + + write_lock_bh(&t->lock); + fi_drop = fa->fa_info; + fa->fa_info = fi; + fa->fa_type = type; + fa->fa_scope = r->rtm_scope; + state = fa->fa_state; + fa->fa_state &= ~FA_S_ACCESSED; + write_unlock_bh(&t->lock); + + fib_release_info(fi_drop); + if (state & FA_S_ACCESSED) + rt_cache_flush(-1); + return 0; + } + + /* Error if we find a perfect match which + * uses the same scope, type, and nexthop + * information. + */ + fa_orig = fa; + list_for_each_entry(fa, fa_orig->fa_list.prev, fa_list) { + if (fa->fa_tos != tos) + break; + if (fa->fa_info->fib_priority != fi->fib_priority) + break; + if (fa->fa_type == type && + fa->fa_scope == r->rtm_scope && + fa->fa_info == fi) + goto out; + } + if (!(nlhdr->nlmsg_flags & NLM_F_APPEND)) + fa = fa_orig; + } + + err = -ENOENT; + if (!(nlhdr->nlmsg_flags&NLM_F_CREATE)) + goto out; + + err = -ENOBUFS; + new_fa = kmem_cache_alloc(fn_alias_kmem, SLAB_KERNEL); + if (new_fa == NULL) + goto out; + + new_fa->fa_info = fi; + new_fa->fa_tos = tos; + new_fa->fa_type = type; + new_fa->fa_scope = r->rtm_scope; + new_fa->fa_state = 0; + + new_fhi = NULL; + if (!fhi) { + new_fhi = kmem_cache_alloc(fn_hlist_kmem, SLAB_KERNEL); + if(!new_fhi) + goto out_free_new_fa; + + new_fhi->plen = plen; + new_fhi->pfx = key; + + INIT_LIST_HEAD(&new_fhi->falh); + fa_head = &new_fhi->falh; + } + + /* + * Insert new entry to the list. + */ + + write_lock_bh(&t->lock); + if(new_fhi) + fib_insert_node(&t->list, new_fhi); + + list_add_tail(&new_fa->fa_list, + (fa ? &fa->fa_list : fa_head)); + write_unlock_bh(&t->lock); + + rt_cache_flush(-1); + rtmsg_fib(RTM_NEWROUTE, key, new_fa, plen, tb->tb_id, nlhdr, req); + return 0; + +out_free_new_fa: + kmem_cache_free(fn_alias_kmem, new_fa); +out: + fib_release_info(fi); + return err; +} + +static int +fn_hlist_lookup(struct fib_table *tb, const struct flowi *flp, struct fib_result *res) +{ + struct fib_hlist_table *t = (struct fib_hlist_table *) tb->tb_data; + t_key key; + u32 mask; + int ret; + struct fib_hlist_info *fhi = NULL; + struct hlist_node *node; + + key = ntohl( flp->fl4_dst ); + + read_lock(&t->lock); + hlist_for_each_entry(fhi, node, &t->list, hlist) { + + mask = ntohl( inet_make_mask(fhi->plen) ); + + if (fhi->pfx == (key & mask)) { + ret = fib_semantic_match(&fhi->falh, flp, res, fhi->plen); + + if(ret <= 0) + goto found; + } + } + ret = 1; +found: + read_unlock(&t->lock); + return ret; +} + +static int +fn_hlist_delete(struct fib_table *tb, struct rtmsg *r, struct kern_rta *rta, + struct nlmsghdr *nlhdr, struct netlink_skb_parms *req) +{ + struct fib_hlist_table *t = (struct fib_hlist_table *) tb->tb_data; + u32 key, mask; + int plen = r->rtm_dst_len; + u8 tos = r->rtm_tos; + int err = 0; + int kill_fn = 0; + struct fib_alias *fa, *fa_to_delete; + struct list_head *fa_head; + struct hlist_node *node; + struct fib_hlist_info *fhi = NULL; + + if (plen > 32) + return -EINVAL; + + key = 0; + if (rta->rta_dst) + memcpy(&key, rta->rta_dst, 4); + + key = ntohl(key); + mask = ntohl( inet_make_mask(plen) ); + + if(key & ~mask) + return -EINVAL; + + key = key & mask; + + if(debug) + printk("fn_hlist_delete id=%d %08x/%d\n", tb->tb_id, key, plen); + + hlist_for_each_entry(fhi, node, &t->list, hlist) { + if (fhi->plen == plen && fhi->pfx == key ) { + fa = fib_find_alias(&fhi->falh, tos, 0); + if(fa) + goto got_alias; + } + } + return -ESRCH; + +got_alias: + fa_to_delete = NULL; + fa_head = fa->fa_list.prev; + list_for_each_entry(fa, fa_head, fa_list) { + struct fib_info *fi = fa->fa_info; + + if (fa->fa_tos != tos) + break; + + if ((!r->rtm_type || + fa->fa_type == r->rtm_type) && + (r->rtm_scope == RT_SCOPE_NOWHERE || + fa->fa_scope == r->rtm_scope) && + (!r->rtm_protocol || + fi->fib_protocol == r->rtm_protocol) && + fib_nh_match(r, nlhdr, rta, fi) == 0) { + fa_to_delete = fa; + break; + } + } + + if (! fa_to_delete) + return -ESRCH; + + kill_fn = 0; + fa = fa_to_delete; + + rtmsg_fib(RTM_DELROUTE, key, fa, plen, tb->tb_id, nlhdr, req); + + write_lock_bh(&t->lock); + list_del(&fa->fa_list); + + /* Remove fib_hlist_info in case */ + + if(list_empty(fa_head)) { + hlist_del(&fhi->hlist); + kill_fn = 1; + } + write_unlock_bh(&t->lock); + + if (fa->fa_state & FA_S_ACCESSED) + rt_cache_flush(-1); + + fn_free_alias(fa); + + if (kill_fn) + fn_free_node(fhi); + + return err; +} + +static int hlist_flush_list(struct fib_hlist_table *t, struct list_head *fah) +{ + struct list_head *head = fah; + struct fib_alias *fa, *fa_node; + int found = 0; + + list_for_each_entry_safe(fa, fa_node, head, fa_list) { + struct fib_info *fi = fa->fa_info; + + if (fi && (fi->fib_flags&RTNH_F_DEAD)) { + + write_lock_bh(&t->lock); + list_del(&fa->fa_list); + write_unlock_bh(&t->lock); + + fn_free_alias(fa); + found++; + } + } + return found; +} + +static int fn_hlist_flush(struct fib_table *tb) +{ + struct fib_hlist_table *t = (struct fib_hlist_table *) tb->tb_data; + int found = 0; + struct hlist_head *bh; + struct hlist_node *node; + struct hlist_node *tmp; + struct fib_hlist_info *fhi; + int kill_f; + + if(debug) + printk("fn_hlist_flush table=%d\n", tb->tb_id); + + bh = &t->list; + + hlist_for_each_entry_safe(fhi, node, tmp, bh, hlist) { + if(list_empty(&fhi->falh)) + continue; + + found += hlist_flush_list(t, &fhi->falh); + + kill_f = 0; + write_lock_bh(&t->lock); + if(list_empty(&fhi->falh)) { + hlist_del(&fhi->hlist); + kill_f = 1; + } + write_unlock_bh(&t->lock); + + if(kill_f) + fn_free_node(fhi); + } + + if(debug) + printk("fn_hlist_flush flushed=%d\n", found); + + return found; +} + +static int hlist_last_dflt=-1; + +static void +fn_hlist_select_default(struct fib_table *tb, const struct flowi *flp, struct fib_result *res) +{ + struct fib_hlist_table *t = (struct fib_hlist_table *) tb->tb_data; + int order, last_idx; + struct fib_info *fi = NULL; + struct fib_info *last_resort; + struct fib_alias *fa = NULL; + struct fib_hlist_info *fhi; + + if(debug) + printk("fn_hlist_select_default\n"); + + fhi = fib_find_node(&t->list, 0, 0); + + if(!fhi) + return; + + if (list_empty(&fhi->falh)) + return; + + last_idx = -1; + last_resort = NULL; + order = -1; + + list_for_each_entry(fa, &fhi->falh, fa_list) { + struct fib_info *next_fi = fa->fa_info; + + if (fa->fa_scope != res->scope || + fa->fa_type != RTN_UNICAST) + continue; + + if (next_fi->fib_priority > res->fi->fib_priority) + break; + if (!next_fi->fib_nh[0].nh_gw || + next_fi->fib_nh[0].nh_scope != RT_SCOPE_LINK) + continue; + fa->fa_state |= FA_S_ACCESSED; + + if (fi == NULL) { + if (next_fi != res->fi) + break; + } else if (!fib_detect_death(fi, order, &last_resort, + &last_idx, &hlist_last_dflt)) { + if (res->fi) + fib_info_put(res->fi); + res->fi = fi; + atomic_inc(&fi->fib_clntref); + hlist_last_dflt = order; + goto out; + } + fi = next_fi; + order++; + } + + if (order <= 0 || fi == NULL) { + hlist_last_dflt = -1; + goto out; + } + + if (!fib_detect_death(fi, order, &last_resort, &last_idx, &hlist_last_dflt)) { + if (res->fi) + fib_info_put(res->fi); + res->fi = fi; + atomic_inc(&fi->fib_clntref); + hlist_last_dflt = order; + goto out; + } + + if (last_idx >= 0) { + if (res->fi) + fib_info_put(res->fi); + res->fi = last_resort; + if (last_resort) + atomic_inc(&last_resort->fib_clntref); + } + hlist_last_dflt = last_idx; + out:; +} + +static inline int fn_hlist_dump_fa(t_key key, int plen, struct list_head *fah, struct fib_table *tb, + struct sk_buff *skb, struct netlink_callback *cb) +{ + int i, s_i; + struct fib_alias *fa; + u32 xkey=htonl(key); + s_i=cb->args[3]; + i = 0; + + list_for_each_entry(fa, fah, fa_list) { + + if (i < s_i) + goto next; + + if (fa->fa_info->fib_nh == NULL) + goto next; + + if (fa->fa_info == NULL) + goto next; + + if (fib_dump_info(skb, NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, + RTM_NEWROUTE, + tb->tb_id, + fa->fa_type, + fa->fa_scope, + &xkey, + plen, + fa->fa_tos, + fa->fa_info) < 0) { + cb->args[3] = i; + return -1; + } + next: + i++; + } + cb->args[3]=i; + return skb->len; +} + +static inline int fn_hlist_dump_plen(int plen, struct fib_table *tb, + struct sk_buff *skb, struct netlink_callback *cb) +{ + int s_i = cb->args[2]; + int i = 0; + struct hlist_node *node; + struct fib_hlist_info *fhi; + struct fib_hlist_table *t = (struct fib_hlist_table *) tb->tb_data; + struct hlist_head *head; + + head = &t->list; + + hlist_for_each_entry(fhi, node, head, hlist) { + + if (i < s_i) + goto next; + + if (i > s_i) + memset(&cb->args[3], 0, + sizeof(cb->args) - 3*sizeof(cb->args[0])); + + if (fhi->plen == plen) { + + if (fn_hlist_dump_fa(fhi->pfx, fhi->plen, &fhi->falh, tb, skb, cb)<0) { + cb->args[2]=i; + return -1; + } + } + next: + i++; + } + cb->args[2]=i; + return skb->len; +} + +static int fn_hlist_dump(struct fib_table *tb, struct sk_buff *skb, struct netlink_callback *cb) +{ + int m, s_m; + s_m= cb->args[1]; + + for (m=s_m; m<=32; m++) { + + if (m < s_m) continue; + if (m > s_m) + memset(&cb->args[2], 0, + sizeof(cb->args) - 2*sizeof(cb->args[0])); + + if (fn_hlist_dump_plen(32-m, tb, skb, cb)<0) { + cb->args[1] = m; + return -1; + } + } + cb->args[1] = m; + return skb->len; +} + +void create(struct fib_table *tb) +{ + struct fib_hlist_table *t = (struct fib_hlist_table *) tb->tb_data; + + INIT_HLIST_HEAD(&t->list); + + printk(KERN_INFO "IP: FIB_hlist vers %s routing table id=%d\n", + VERSION, tb->tb_id); +} + +#ifdef CONFIG_IP_MULTIPLE_TABLES +struct fib_table * fib_hash_init(int id) +#else +struct fib_table * __init fib_hash_init(int id) +#endif +{ + struct fib_table *tb; + struct fib_hlist_table *t; + + if (fn_alias_kmem == NULL) + fn_alias_kmem = kmem_cache_create("ip_fib_alias", + sizeof(struct fib_alias), + 0, SLAB_HWCACHE_ALIGN, + NULL, NULL); + + if (fn_hlist_kmem == NULL) + fn_hlist_kmem = kmem_cache_create("ip_hlist_info", + sizeof(struct fib_hlist_info), + 0, SLAB_HWCACHE_ALIGN, + NULL, NULL); + + tb = kmalloc(sizeof(struct fib_table) + sizeof(struct fib_hlist_table), + GFP_KERNEL); + + if (tb == NULL) + return NULL; + + tb->tb_id = id; + tb->tb_lookup = fn_hlist_lookup; + tb->tb_insert = fn_hlist_insert; + tb->tb_delete = fn_hlist_delete; + tb->tb_flush = fn_hlist_flush; + tb->tb_select_default = fn_hlist_select_default; + tb->tb_dump = fn_hlist_dump; + memset(tb->tb_data, 0, sizeof(struct fib_hlist_table)); + + t = (struct fib_hlist_table *) tb->tb_data; + + t->lock = RW_LOCK_UNLOCKED; + + create(tb); + return tb; +} + +#ifdef CONFIG_PROC_FS + +int __init fib_proc_init(void) +{ + return 0; +} + +void __init fib_proc_exit(void) +{ + proc_net_remove("route"); +} +#endif /* CONFIG_PROC_FS */ + From arnaldo.melo@gmail.com Wed May 4 09:16:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 09:16:49 -0700 (PDT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44GGV7J012118 for ; Wed, 4 May 2005 09:16:34 -0700 Received: by zproxy.gmail.com with SMTP id 8so265066nzo for ; Wed, 04 May 2005 09:16:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V9AeM40jQNUinWDtmgPwrH3tm3pvqZumf1APxvwGUO2FvUhy5zy62xVf1+wWnw70SzszEptH41E6KvJHCVvpf5uf6eNVUlTMRMyD9T/kYjlzrSI4cgnSR6lZ6+TCGNpEZ+npRAod8vzNX0MA7Pd/6X4/b0q7FEUZUzNIe24GqUs= Received: by 10.36.8.20 with SMTP id 20mr164344nzh; Wed, 04 May 2005 09:16:17 -0700 (PDT) Received: by 10.36.56.15 with HTTP; Wed, 4 May 2005 09:16:17 -0700 (PDT) Message-ID: <39e6f6c705050409161b90858b@mail.gmail.com> Date: Wed, 4 May 2005 13:16:17 -0300 From: Arnaldo Carvalho de Melo Reply-To: acme@ghostprotocols.net To: Matti Aarnio Subject: Re: TCP4/6 socket closure causing system crash.. Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org In-Reply-To: <20050504125752.GA7399@mea-ext.zmailer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050504125752.GA7399@mea-ext.zmailer.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j44GGV7J012118 X-archive-position: 702 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: arnaldo.melo@gmail.com Precedence: bulk X-list: netdev On 5/4/05, Matti Aarnio wrote: > I have CVS-pserver running under a chroot wrapper. > Recently system has become unresponsive the instance somebody > refers to the pserver... > > I have three kernels to choose from: > > title Fedora Core (2.6.11-1.1282_FC4smp) > title Fedora Core (2.6.11-1.1276_FC4smp) > title Fedora Core (2.6.11-1.1191_FC4smp) > > First two crash, third works just fine for this workset. > > Serial console capture tells following: > > ----------------- > > Kernel 2.6.11-1.1282_FC4smp on an i686 > > mismatch in kmem_cache_free: expected cache f78ee500, got f7972800 Look at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155389 Try with the sk_prot_creator patch. - Arnaldo From shemminger@osdl.org Wed May 4 10:10:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 04 May 2005 10:10:24 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j44HAB7J014749 for ; Wed, 4 May 2005 10:10:12 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j44H9rU3013104 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 4 May 2005 10:09:54 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j44H9rRC001