From owner-freebsd-current Wed Jan 16 6: 9:20 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.acns.ab.ca (h24-64-56-135.cg.shawcable.net [24.64.56.135]) by hub.freebsd.org (Postfix) with ESMTP id EA7A737B400 for ; Wed, 16 Jan 2002 06:09:14 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0GE9EI80391 for ; Wed, 16 Jan 2002 07:09:14 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0GE99d00858 for current@freebsd.org; Wed, 16 Jan 2002 07:09:09 -0700 (MST) (envelope-from davidc) Date: Wed, 16 Jan 2002 07:09:08 -0700 From: Chad David To: current@freebsd.org Subject: socket shutdown delay? Message-ID: <20020116070908.A803@colnta.acns.ab.ca> Mail-Followup-To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Has anyone noticed (or fixed) a bug in -current where socket connections on the local machine do not shutdown properly? During stress testing I'm seeing thousands (2316 right now) of these: tcp4 0 0 192.168.1.2.8080 192.168.1.2.2215 FIN_WAIT_2 tcp4 0 0 192.168.1.2.2215 192.168.1.2.8080 LAST_ACK tcp4 0 0 192.168.1.2.8080 192.168.1.2.2214 FIN_WAIT_2 tcp4 0 0 192.168.1.2.2214 192.168.1.2.8080 LAST_ACK tcp4 0 0 192.168.1.2.8080 192.168.1.2.2213 FIN_WAIT_2 tcp4 0 0 192.168.1.2.2213 192.168.1.2.8080 LAST_ACK tcp4 0 0 192.168.1.2.8080 192.168.1.2.2212 FIN_WAIT_2 tcp4 0 0 192.168.1.2.2212 192.168.1.2.8080 LAST_ACK tcp4 0 0 192.168.1.2.8080 192.168.1.2.2211 FIN_WAIT_2 tcp4 0 0 192.168.1.2.2211 192.168.1.2.8080 LAST_ACK tcp4 0 0 192.168.1.2.8080 192.168.1.2.2210 FIN_WAIT_2 tcp4 0 0 192.168.1.2.2210 192.168.1.2.8080 LAST_ACK Both the client and the server are dead, but the connections stay in this state. I tested with the server on -current and the client on another box, and all of the server sockets end up in TIME_WAIT. Is there something delaying the last ack on local connections? Thanks. FreeBSD colnta 5.0-CURRENT FreeBSD 5.0-CURRENT #17: Sun Jan 13 03:51:32 MST 2002 Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #17: Sun Jan 13 03:51:32 MST 2002 davidc@colnta:/mnt1/obj/usr/src/sys/COLNTA Preloaded elf kernel "/boot/kernel/kernel" at 0xc0521000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05210a8. Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (1004.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383fbff real memory = 1073725440 (1048560K bytes) avail memory = 1039327232 (1014968K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 3, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec00000 Pentium Pro MTRR support enabled Using $PIR table, 7 entries at 0xc00f12d0 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 IOAPIC #0 intpin 18 -> irq 2 IOAPIC #0 intpin 16 -> irq 5 IOAPIC #0 intpin 19 -> irq 10 pci0: on acpi_pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xb800-0xb80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xb400-0xb41f irq 2 at device 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb000-0xb01f irq 2 at device 4.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 12.0 (no driver attached) dc0: port 0xa800-0xa8ff mem 0xeb800000-0xeb8003ff irq 10 at device 13.0 on pci0 dc0: Ethernet address: 00:04:5a:61:f5:6a miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: PRINTER PJL,MLC,PCL,PCLXL,POSTSCRIPT plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it orm0: