From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 00:26:46 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ABEE16A420 for ; Sun, 12 Aug 2007 00:26:46 +0000 (UTC) (envelope-from brucec@muon.bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id 30D6B13C458 for ; Sun, 12 Aug 2007 00:26:45 +0000 (UTC) (envelope-from brucec@muon.bluestop.org) Received: by muon.bluestop.org (Postfix, from userid 1000) id 3BAB530123; Sun, 12 Aug 2007 01:22:52 +0100 (BST) Date: Sun, 12 Aug 2007 01:22:51 +0100 From: bruce@cran.org.uk To: Don Lewis Message-ID: <20070812002251.GA19278@muon.bluestop.org> References: <46BC1418.9070008@cran.org.uk> <200708101505.l7AF53jG043973@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708101505.l7AF53jG043973@gw.catspoiler.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@FreeBSD.org Subject: Re: RE: Reboot on "shutdown -r" hangs after final "uptime ..." string X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 00:26:46 -0000 On Fri, Aug 10, 2007 at 08:05:03AM -0700, Don Lewis wrote: > I'm seeing this problem on an Athlon 64 desktop machine with the NVIDIA > GeForce 7050PV / nForce 630a chipset. The hang is occuring at this > point in boot() in kern_shutdown.c: > > /* Now that we're going to really halt the system... */ > EVENTHANDLER_INVOKE(shutdown_final, howto); > > The culprit is an infinite loop in ehci_pci_givecontroller(), which is > called from ehci_shutdown(). The infinite loop is triggered by reading > the incorrect value from one of the EHCI controller registers because > the register is being read before a reset of the controller has > completed. > > Try this patch: > > Index: sys/dev/usb/ehci.c > + usb_delay_ms(&sc->sc_bus, 1); > + EOWRITE4(sc, EHCI_USBCMD, EHCI_CMD_HCRESET); > + for (i = 0; i < 100; i++) { > + usb_delay_ms(&sc->sc_bus, 1); > + hcr = EOREAD4(sc, EHCI_USBCMD) & EHCI_CMD_HCRESET; > + if (!hcr) > + return (USBD_NORMAL_COMPLETION); > + } > + printf("%s: reset timeout\n", device_get_nameunit(sc->sc_bus.bdev)); > + return (USBD_IOERROR); > +} The patch doesn't fix the issue on my laptop, which identifies the USB controller as: uhub0: on usb0 By putting more printfs I see that it gets to the line "eec = pci_read_config" in ehci_pci_givecontroller and then appears to stop - I've got a printf at the end of ehci_pci_givecontroller that never gets displayed, and the printf at the top of the for loop only gets displayed once. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 00:44:57 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E94D16A417 for ; Sun, 12 Aug 2007 00:44:57 +0000 (UTC) (envelope-from brucec@muon.bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id 6ADCA13C45B for ; Sun, 12 Aug 2007 00:44:57 +0000 (UTC) (envelope-from brucec@muon.bluestop.org) Received: by muon.bluestop.org (Postfix, from userid 1000) id 1293B30169; Sun, 12 Aug 2007 01:41:03 +0100 (BST) Date: Sun, 12 Aug 2007 01:41:03 +0100 From: bruce@cran.org.uk To: current@freebsd.org Message-ID: <20070812004103.GA20935@muon.bluestop.org> References: <46BC1418.9070008@cran.org.uk> <200708101505.l7AF53jG043973@gw.catspoiler.org> <20070812002251.GA19278@muon.bluestop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070812002251.GA19278@muon.bluestop.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: RE: Reboot on "shutdown -r" hangs after final "uptime ..." string X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 00:44:57 -0000 On Sun, Aug 12, 2007 at 01:22:51AM +0100, bruce@cran.org.uk wrote: > By putting more printfs I see that it gets to the line "eec = > pci_read_config" in ehci_pci_givecontroller and then appears to stop - > I've got a printf at the end of ehci_pci_givecontroller that never gets > displayed, and the printf at the top of the for loop only gets displayed > once. > After adding one more printf I see that it actually stops at the pci_write_config line, not the pci_read_config. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 01:27:46 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2367016A417 for ; Sun, 12 Aug 2007 01:27:46 +0000 (UTC) (envelope-from hintonda@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.freebsd.org (Postfix) with ESMTP id B93B413C46A for ; Sun, 12 Aug 2007 01:27:45 +0000 (UTC) (envelope-from hintonda@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so792478wxd for ; Sat, 11 Aug 2007 18:27:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:mime-version:content-type:content-transfer-encoding:message-id:date:to:subject:x-mailer; b=bfd/MdlNtErvxPZjOEtB81AHw5nziOMwTdF/KiSxa4OgT0hZ6F4HgTeb08Mlv0SAkXDp9sOg76M7L7FA/1i165QYBx/fwNT/qL0SuUG81lyDnJgg4T5DxE5BUW3rOfs2CVq6C5gI+m+3HXwOdslRGK/hxw1AMKmyvXVX6n/i1C0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:mime-version:content-type:content-transfer-encoding:message-id:date:to:subject:x-mailer; b=BOnlmTQwNDRyQmFmvMPOV4iotn6UolpINxUA+0J6mjyQbtDh8/SRe7OkPSPZQ3dgeWat1BUdJNVXcmVQ3zZf4yjnG4lYpi+f/G5K4Ohas21dZPy9mQIOyzIkNbhW+Gt4LJbq9eC3yQo4Quxfbnpr0Z5L5cVpQJQJFCge2NDWhF0= Received: by 10.70.125.11 with SMTP id x11mr7851973wxc.1186880496875; Sat, 11 Aug 2007 18:01:36 -0700 (PDT) Received: from localhost.my.domain ( [69.245.3.33]) by mx.google.com with ESMTPS id i18sm4829799wxd.2007.08.11.18.01.35 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Aug 2007 18:01:35 -0700 (PDT) From: Don Hinton MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18110.23498.250364.673461@localhost.my.domain> Date: Sun, 12 Aug 2007 01:00:58 +0000 To: current@freebsd.org X-Mailer: VM 7.19 under Emacs 22.1.1 Cc: Subject: Consoles go blank after loading X with GM965 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 01:27:46 -0000 Hi: I have an Intel GM965 SVGA adapter, and when I load snd_hda in /boot/loader.conf, I loose the ability to ctrl-alt-fn to any of my consoles after starting xfce--I have keyboard, but the console screens goes blank. This happens on both 7.0-current and 6.2-stable, and with a plain startx, kde, and xfce. However, if I wait to load snd_hda until after apci gets loaded (which seems to be the only thing that matters), I don't have the problem, i.e., I can ctrl-alt-fn to other consoles. The only other odd thing is that I compiled vesa into the kernel, and see VESA: set_mode(): 24(18) -> 24(18) written to the console everytime I switch from X. I don't have any idea what's going on, but figured passing this along might help someone more knowledgable. thanks... don $ uname -a FreeBSD localhost 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Aug 8 22:06:24 UTC 2007 root@:/usr/obj/usr/src/sys/HP_SMP i386 $ cat /boot/loader.conf debug.acpi.disabled="sysresource" $ dmesg Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #0: Wed Aug 8 22:06:24 UTC 2007 root@:/usr/obj/usr/src/sys/HP_SMP WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.77-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fa Stepping = 10 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2137849856 (2038 MB) avail memory = 2082467840 (1985 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem 0xf8000000-0xf80fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7676k stolen memory agp0: aperture size is 256M vgapci1: mem 0xf8100000-0xf81fffff at device 2.1 on pci0 uhci0: port 0x1820-0x183f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xf8704800-0xf8704bff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered pci0: at device 27.0 (no driver attached) pcib1: irq 17 at device 28.0 on pci0 pci2: on pcib1 pci2: at device 0.0 (no driver attached) pcib2: irq 16 at device 28.1 on pci0 pci4: on pcib2 pcib3: irq 16 at device 28.5 on pci0 pci6: on pcib3 re0: port 0x3000-0x30ff mem 0xf8300000-0xf8300fff irq 17 at device 0.0 on pci6 re0: Using 2 MSI messages miibus0: on re0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: Ethernet address: 00:1b:24:6d:22:97 re0: [FILTER] re0: [FILTER] uhci2: port 0x1860-0x187f irq 23 at device 29.0 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0x1880-0x189f irq 19 at device 29.1 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x18a0-0x18bf irq 18 at device 29.2 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xf8704c00-0xf8704fff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered ugen0: on uhub6 pcib4: at device 30.0 on pci0 pci7: on pcib4 fwohci0: <1394 Open Host Controller Interface> mem 0xf8400000-0xf84007ff irq 20 at device 9.0 on pci7 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:24:1b:00:f0:02:38:00 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:24:1b:02:38:00 fwe0: Ethernet address: 02:24:1b:02:38:00 fwip0: on firewire0 fwip0: Firewire address: 00:24:1b:00:f0:02:38:00 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x7d060000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode pci7: at device 9.1 (no driver attached) pci7: at device 9.2 (no driver attached) pci7: at device 9.3 (no driver attached) pci7: at device 9.4 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x1c00-0x1c07,0x18d4-0x18d7,0x18d8-0x18df,0x18d0-0x18d3,0x18e0-0x18ff mem 0xf8704000-0xf87047ff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 3 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz0: _CRT value is absurd, ignored (-72.6C) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xcf000-0xcffff,0xe0000-0xe17ff pnpid ORM0000 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acd0: DVDR at ata0-master PIO4 ad4: 95396MB at ata2-master SATA150 ad8: 95396MB at ata4-master SATA150 GEOM_LABEL: Label for provider ad4s1 is ntfs/OS. GEOM_LABEL: Label for provider ad4s2 is ntfs/HP_RECOVERY. SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad4s3a pcm0: mem 0xf8700000-0xf8703fff irq 22 at device 27.0 on pci0 pcm0: [ITHREAD] pcm0: pcm0: VESA: set_mode(): 24(18) -> 24(18) $ cat /root/kernels/HP_SMP |sed -E -n -f /usr/src/sys/conf/makeLINT.sed cpu I686_CPU ident HP_SMP makeoptions DEBUG=-g options SCHED_4BSD options PREEMPTION options INET options INET6 options SCTP options FFS options SOFTUPDATES options UFS_ACL options UFS_DIRHASH options UFS_GJOURNAL options MD_ROOT options NFSCLIENT options NFSSERVER options NFS_ROOT options MSDOSFS options CD9660 options PROCFS options PSEUDOFS options GEOM_PART_GPT options GEOM_LABEL options COMPAT_43TTY options COMPAT_FREEBSD4 options COMPAT_FREEBSD5 options COMPAT_FREEBSD6 options SCSI_DELAY=5000 options KTRACE options SYSVSHM options SYSVMSG options SYSVSEM options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV options ADAPTIVE_GIANT options STOP_NMI options AUDIT options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN options SMP device apic device cpufreq device eisa device pci device fdc device ata device atadisk device ataraid device atapicd device atapifd device atapist options ATA_STATIC_ID device ahb device ahc options AHC_REG_PRETTY_PRINT device ahd options AHD_REG_PRETTY_PRINT device amd device hptiop device isp device mpt device sym device trm device adv device adw device aha device aic device bt device ncv device nsp device stg device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device asr device ciss device dpt device hptmv device rr232x device iir device ips device mly device twa device aac device aacp device ida device mfi device mlx device pst device twe device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device agp options VESA options VESA_DEBUG options VGA_DEBUG device drm device pmtimer device cbb device pccard device cardbus device sio device uart device ppc device ppbus device lpt device plip device ppi device de device em device ixgb device le device txp device vx device miibus device bce device bfe device bge device dc device fxp device lge device msk device nfe device nge device pcn device re device rl device sf device sis device sk device ste device stge device ti device tl device tx device vge device vr device wb device xl device cs device ed device ex device ep device fe device ie device sn device xe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device wlan_scan_ap device wlan_scan_sta device an device ath device ath_hal device ath_rate_sample device awi device ral device wi device loop device random device ether device sl device ppp device tun device pty device md device gif device faith device firmware device bpf device uhci device ohci device ehci device usb device ugen device uhid device ukbd device ulpt device umass device ums device ural device rum device urio device uscanner device aue device axe device cdce device cue device kue device rue device firewire device sbp device fwe device fwip device dcons device dcons_crom From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 01:33:35 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D68F716A41A for ; Sun, 12 Aug 2007 01:33:35 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id B8CCF13C465 for ; Sun, 12 Aug 2007 01:33:35 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id l7C1XL54060302; Sat, 11 Aug 2007 18:33:25 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200708120133.l7C1XL54060302@gw.catspoiler.org> Date: Sat, 11 Aug 2007 18:33:21 -0700 (PDT) From: Don Lewis To: bruce@cran.org.uk In-Reply-To: <20070812004103.GA20935@muon.bluestop.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: current@FreeBSD.org Subject: Re: RE: Reboot on "shutdown -r" hangs after final "uptime ..." string X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 01:33:35 -0000 On 12 Aug, bruce@cran.org.uk wrote: > On Sun, Aug 12, 2007 at 01:22:51AM +0100, bruce@cran.org.uk wrote: >> By putting more printfs I see that it gets to the line "eec = >> pci_read_config" in ehci_pci_givecontroller and then appears to stop - >> I've got a printf at the end of ehci_pci_givecontroller that never gets >> displayed, and the printf at the top of the for loop only gets displayed >> once. >> > > After adding one more printf I see that it actually stops at the > pci_write_config line, not the pci_read_config. I wonder if the register write is triggering an SMI, which is sending the CPU off into the weeds. Take a look at sections 2.1.7 and 2.1.8 of the EHCI spec . You might want to print the values of eec and pci_read_config(self, eecp+4, 4) immediately before the call to pci_write_config(). Bit 13 of the latter will be the most interesting. Something that you might want to also print is the value of EOREAD4(sc, EHCI_USBSTS) immediately before the EOWRITE4(sc, EHCI_USBCMD, EHCI_CMD_HCRESET); call in ehci_hcreset(). Bit 12 of this register (EHCI_STS_HCH) should be a zero before the write to do the reset is performed. Maybe ehci_hcreset() needs to wait for that to happen (as is done in ehci_init()), rather than just waiting a fixed amount of time. I don't know much about SMI, but if the CPU is getting stuck in the SMI handler, then that might indicate that the problem is a BIOS bug. From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 01:57:43 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FE4916A417 for ; Sun, 12 Aug 2007 01:57:43 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 0CE3313C428 for ; Sun, 12 Aug 2007 01:57:42 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id l7C1vWcI060342; Sat, 11 Aug 2007 18:57:36 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200708120157.l7C1vWcI060342@gw.catspoiler.org> Date: Sat, 11 Aug 2007 18:57:32 -0700 (PDT) From: Don Lewis To: bruce@cran.org.uk In-Reply-To: <200708120133.l7C1XL54060302@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: current@FreeBSD.org Subject: Re: RE: Reboot on "shutdown -r" hangs after final "uptime ..." string X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 01:57:43 -0000 On 11 Aug, To: bruce@cran.org.uk wrote: > On 12 Aug, bruce@cran.org.uk wrote: > Something that you might want to also print is the value of > EOREAD4(sc, EHCI_USBSTS) > immediately before the > EOWRITE4(sc, EHCI_USBCMD, EHCI_CMD_HCRESET); > call in ehci_hcreset(). Bit 12 of this register (EHCI_STS_HCH) should > be a zero before the write to do the reset is performed. Correction, this bit should be a one before doing the reset. > Maybe > ehci_hcreset() needs to wait for that to happen (as is done in > ehci_init()), rather than just waiting a fixed amount of time. I misread the code in ehci_init(), which is waiting for a transition in the opposite direction. I don't know why, because the EHCI spec says that the 1->0 transition is immediate. From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 02:40:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C1C316A419 for ; Sun, 12 Aug 2007 02:40:31 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 491EB13C45E for ; Sun, 12 Aug 2007 02:40:31 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.101]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IK3NW-0008JK-KE for freebsd-current@freebsd.org; Sun, 12 Aug 2007 02:40:30 +0000 Message-ID: <46BE7310.8020802@psg.com> Date: Sat, 11 Aug 2007 16:40:16 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: change in less for ti@:te@ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 02:40:31 -0000 as reported by deischen at freebsd.org, ti@:te@ in termcap for xterms is no longer working for less. this is a real pain to us really old farts here. in message , he does suggest a fix. anyone bribable to review and check this in? randy From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 03:30:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D606816A417 for ; Sun, 12 Aug 2007 03:30:23 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 930C213C45D for ; Sun, 12 Aug 2007 03:30:23 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id C494EEB475B; Sun, 12 Aug 2007 11:30:22 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id CJqwM1TpU9IA; Sun, 12 Aug 2007 11:30:20 +0800 (CST) Received: from charlie.delphij.net (unknown [221.219.159.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id A8D2FEB43B0; Sun, 12 Aug 2007 11:30:20 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=adBQ00Xn5/heZ77w2Tac2DSL1C2fiQP35gUEXOd1AaihvS4KMyqIhVaRq84DVijbO ygmSEBP9AnDbVXOEeYRRA== Message-ID: <46BE7ECB.6020104@delphij.net> Date: Sun, 12 Aug 2007 11:30:19 +0800 From: Xin LI User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: Randy Bush References: <46BE7310.8020802@psg.com> In-Reply-To: <46BE7310.8020802@psg.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: change in less for ti@:te@ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 03:30:24 -0000 Randy Bush wrote: > as reported by deischen at freebsd.org, ti@:te@ in termcap for xterms is > no longer working for less. this is a real pain to us really old farts > here. in message > , > he does suggest a fix. anyone bribable to review and check this in? Sorry for the delay. I have just sent a commit request to re@ and is waiting for their approval. Cheers, From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 03:31:35 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07F9316A417 for ; Sun, 12 Aug 2007 03:31:35 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id E71AC13C465 for ; Sun, 12 Aug 2007 03:31:34 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.101]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IK4Av-000Nqe-Ck; Sun, 12 Aug 2007 03:31:33 +0000 Message-ID: <46BE7F06.6000705@psg.com> Date: Sat, 11 Aug 2007 17:31:18 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Xin LI References: <46BE7310.8020802@psg.com> <46BE7ECB.6020104@delphij.net> In-Reply-To: <46BE7ECB.6020104@delphij.net> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: change in less for ti@:te@ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 03:31:35 -0000 > Sorry for the delay. i demand a full refund! :) > I have just sent a commit request to re@ and is waiting for their > approval. thank you! randy From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 04:26:40 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6178916A41A for ; Sun, 12 Aug 2007 04:26:40 +0000 (UTC) (envelope-from freebsd.ruomad@free.fr) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id 118A013C483 for ; Sun, 12 Aug 2007 04:26:39 +0000 (UTC) (envelope-from freebsd.ruomad@free.fr) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by postfix2-g20.free.fr (Postfix) with ESMTP id 8C3E2191BB0C for ; Sun, 12 Aug 2007 04:55:53 +0200 (CEST) Received: from smtp2-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp2-g19.free.fr (Postfix) with ESMTP id C1C7598E30 for ; Sun, 12 Aug 2007 05:55:02 +0200 (CEST) Received: from vil1.ruomad.net (vln78-1-82-238-160-33.fbx.proxad.net [82.238.160.33]) by smtp2-g19.free.fr (Postfix) with ESMTP id A409098DE3 for ; Sun, 12 Aug 2007 05:55:02 +0200 (CEST) Message-ID: <46BE8495.2000308@free.fr> Date: Sun, 12 Aug 2007 05:55:01 +0200 From: Bruno Damour User-Agent: Thunderbird 2.0.0.6 (X11/20070804) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: TCP errors ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 04:26:40 -0000 Hello, I'm getting a lot of messages like this, what is that supposed to come from ? No harm done AFAIK but my dmesg gets bloated ? TCP: [192.168.0.100]:389 to [192.168.0.100]:53612 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received data after socket was closed, sending RST and removing tcpcb Thanks in advance. Bruno From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 04:43:07 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E282816A417 for ; Sun, 12 Aug 2007 04:43:07 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id A952113C45B for ; Sun, 12 Aug 2007 04:43:07 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id l7C4gtMP060591; Sat, 11 Aug 2007 21:42:59 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200708120442.l7C4gtMP060591@gw.catspoiler.org> Date: Sat, 11 Aug 2007 21:42:55 -0700 (PDT) From: Don Lewis To: bruce@cran.org.uk In-Reply-To: <200708120157.l7C1vWcI060342@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: current@FreeBSD.org Subject: Re: RE: Reboot on "shutdown -r" hangs after final "uptime ..." string X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 04:43:08 -0000 On 11 Aug, Don Lewis wrote: > On 11 Aug, To: bruce@cran.org.uk wrote: >> On 12 Aug, bruce@cran.org.uk wrote: > >> Something that you might want to also print is the value of >> EOREAD4(sc, EHCI_USBSTS) >> immediately before the >> EOWRITE4(sc, EHCI_USBCMD, EHCI_CMD_HCRESET); >> call in ehci_hcreset(). Bit 12 of this register (EHCI_STS_HCH) should >> be a zero before the write to do the reset is performed. > > Correction, this bit should be a one before doing the reset. > >> Maybe >> ehci_hcreset() needs to wait for that to happen (as is done in >> ehci_init()), rather than just waiting a fixed amount of time. > > I misread the code in ehci_init(), which is waiting for a transition in > the opposite direction. I don't know why, because the EHCI spec says > that the 1->0 transition is immediate. A revised version of the patch is below. The only change is the addition of a second wait loop in ehci_hcreset(), which would be necessary according the the EHCI spec if the controller could ever require more than 1ms to stop. This patch might fix the problem on your machine if you are observing a zero for bit 12 (EHCI_STS_HCH) of the EHCI_USBSTS register in ehci_hcreset(). Index: sys/dev/usb/ehci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/usb/ehci.c,v retrieving revision 1.55 diff -u -r1.55 ehci.c --- sys/dev/usb/ehci.c 20 Jun 2007 05:10:52 -0000 1.55 +++ sys/dev/usb/ehci.c 12 Aug 2007 03:55:54 -0000 @@ -311,6 +311,39 @@ ehci_device_isoc_done, }; +static usbd_status +ehci_hcreset(ehci_softc_t *sc) +{ + u_int32_t hcr; + u_int i; + + EOWRITE4(sc, EHCI_USBCMD, 0); /* Halt controller */ + for (i = 0; i < 100; i++) { + usb_delay_ms(&sc->sc_bus, 1); + hcr = EOREAD4(sc, EHCI_USBSTS) & EHCI_STS_HCH; + if (hcr) + break; + } + if (!hcr) + /* + * Fall through and try reset anyway even though + * Table 2-9 in the EHCI spec says this will result + * in undefined behavior. + */ + printf("%s: stop timeout\n", + device_get_nameunit(sc->sc_bus.bdev)); + + EOWRITE4(sc, EHCI_USBCMD, EHCI_CMD_HCRESET); + for (i = 0; i < 100; i++) { + usb_delay_ms(&sc->sc_bus, 1); + hcr = EOREAD4(sc, EHCI_USBCMD) & EHCI_CMD_HCRESET; + if (!hcr) + return (USBD_NORMAL_COMPLETION); + } + printf("%s: reset timeout\n", device_get_nameunit(sc->sc_bus.bdev)); + return (USBD_IOERROR); +} + usbd_status ehci_init(ehci_softc_t *sc) { @@ -365,20 +398,9 @@ /* Reset the controller */ DPRINTF(("%s: resetting\n", device_get_nameunit(sc->sc_bus.bdev))); - EOWRITE4(sc, EHCI_USBCMD, 0); /* Halt controller */ - usb_delay_ms(&sc->sc_bus, 1); - EOWRITE4(sc, EHCI_USBCMD, EHCI_CMD_HCRESET); - for (i = 0; i < 100; i++) { - usb_delay_ms(&sc->sc_bus, 1); - hcr = EOREAD4(sc, EHCI_USBCMD) & EHCI_CMD_HCRESET; - if (!hcr) - break; - } - if (hcr) { - printf("%s: reset timeout\n", - device_get_nameunit(sc->sc_bus.bdev)); - return (USBD_IOERROR); - } + err = ehci_hcreset(sc); + if (err != USBD_NORMAL_COMPLETION) + return (err); /* frame list size at default, read back what we got and use that */ switch (EHCI_CMD_FLS(EOREAD4(sc, EHCI_USBCMD))) { @@ -927,8 +949,7 @@ sc->sc_dying = 1; EOWRITE4(sc, EHCI_USBINTR, sc->sc_eintrs); - EOWRITE4(sc, EHCI_USBCMD, 0); - EOWRITE4(sc, EHCI_USBCMD, EHCI_CMD_HCRESET); + (void) ehci_hcreset(sc); callout_stop(&sc->sc_tmo_intrlist); callout_stop(&sc->sc_tmo_pcd); @@ -1090,8 +1111,7 @@ ehci_softc_t *sc = v; DPRINTF(("ehci_shutdown: stopping the HC\n")); - EOWRITE4(sc, EHCI_USBCMD, 0); /* Halt controller */ - EOWRITE4(sc, EHCI_USBCMD, EHCI_CMD_HCRESET); + (void) ehci_hcreset(sc); } usbd_status If this doesn't help, you could test the SMI hypothesis by disabling the SMI on OS Ownership Enable bit before clearing the EHCI_LEGSUP_OSOWNED bit. Something like the following should disable the SMI enable bit, but I don't know what side effects it might have. It could even melt your computer ;-) In any case, it's not a proper fix. static void ehci_pci_givecontroller(device_t self) { ehci_softc_t *sc = device_get_softc(self); u_int32_t cparams, eec, legsup; int eecp; cparams = EREAD4(sc, EHCI_HCCPARAMS); for (eecp = EHCI_HCC_EECP(cparams); eecp != 0; eecp = EHCI_EECP_NEXT(eec)) { eec = pci_read_config(self, eecp, 4); if (EHCI_EECP_ID(eec) != EHCI_EC_LEGSUP) continue; /* NEW */ legsup = pci_read_config(self,eecp+EHCI_LEGSUP_USBLEGCTLSTS,4); /* NEW */ legsup = legsup & ~0x200; /* NEW */ pci_write_config(self, eecp+EHCI_LEGSUP_USBLEGCTLSTS, legsup,4); legsup = eec; pci_write_config(self, eecp, legsup & ~EHCI_LEGSUP_OSOWNED, 4); } } From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 04:54:41 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2FEE16A417 for ; Sun, 12 Aug 2007 04:54:41 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.freebsd.org (Postfix) with ESMTP id A51D613C442 for ; Sun, 12 Aug 2007 04:54:41 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by py-out-1112.google.com with SMTP id a73so2040747pye for ; Sat, 11 Aug 2007 21:54:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ett84TVEDmdnSFhCcjlMsW2413fUcRTzu+BUqDeGIg4v0ONkXrreVCKYlN8k3zuxCSsXrtK/9urv7vkMZhpo3ewzi+iYi74YqeVUEQrPMvtUWdtFKKVWR8l97a50vNc/IWR1YwVkEYjNfmtP8VHNb1ciMvXVw0l3rVNkKx4VNLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=g/mI7YQR/J+UENeUrIBQbQs5Y8asns+3QbvMAblw5L9e3t1R9SuJVzh/LkruVaWHbhsPC6filkXMzkNVtHxqGaseS0kVMrR4LYZ8sgmTJcD1o+OfKowkY8EwNZRnHB8upzQeXFiSF/kfnze8ujeol+Ta+dn/HeAzr1rJcS4xI60= Received: by 10.65.135.19 with SMTP id m19mr7257923qbn.1186894480761; Sat, 11 Aug 2007 21:54:40 -0700 (PDT) Received: by 10.64.193.5 with HTTP; Sat, 11 Aug 2007 21:54:40 -0700 (PDT) Message-ID: <6eb82e0708112154y55ae49dfo503416306ed5f5bf@mail.gmail.com> Date: Sun, 12 Aug 2007 12:54:40 +0800 From: "Rong-en Fan" To: "Kris Kennaway" In-Reply-To: <20070811191835.GA28716@rot26.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6eb82e0708111122g7e36b725h19ede889e4bbc9d6@mail.gmail.com> <20070811191835.GA28716@rot26.obsecurity.org> Cc: current@freebsd.org Subject: Re: panic: sleeping thread owns a non-sleepable lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 04:54:42 -0000 On 8/12/07, Kris Kennaway wrote: > On Sun, Aug 12, 2007 at 02:22:35AM +0800, Rong-en Fan wrote: > > I'm running 7.0-CURRENT as of yesterday, and it's very easy > > to make it panic: > > > > Sleeping thread (tid 100065, pid 1066) owns a non-sleepable lock > > sched_switch(c50a1600,0,1,1c7a7e4,4217e5,...) at sched_switch+0x190 > > mi_switch(1,0) at mi_switch+0x13f > > sleepq_switch(c50a1600,0,c078a4e2,21b,c07e3820,...) at sleepq_switch+0x87 > > sleepq_wait(c07e3820,0,c0770b7e,3,0,...) at sleepq_wait+0x36 > > _sx_xlock_hard(c07e3820,c50a1600,0,0,0,...) at _sx_xlock_hard+0x21d > > fr_checknatout(f9c7a8d0,f9c7a8cc,64,c57ad900,c4de7400,...) at > > fr_checknatout+0x29d > > fr_check(c8cc4644,14,c4de7400,1,f9c7a9b4,...) at fr_check+0x9b1 > > fr_check_wrapper(0,f9c7a9b4,c4de7400,2,c54dab28,...) at fr_check_wrapper+0x3f > > pfil_run_hooks(c08057c0,f9c7aa4c,c4de7400,2,c54dab28,...) at pfil_run_hooks+0x74 > > ip_output(c8cc4600,0,f9c7aa10,0,0,...) at ip_output+0x913 > > tcp_output(cae322d0,cb277200,0,0,0,...) at tcp_output+0x1106 > > tcp_usr_send(c51e7318,0,cb277200,0,0,...) at tcp_usr_send+0x240 > > kern_sendfile(c50a1600,f9c7acfc,0,0,0,...) at kern_sendfile+0x1037 > > sendfile(c50a1600,f9c7acfc,20,16,f9c7ad2c,...) at sendfile+0xa8 > > syscall(f9c7ad38) at syscall+0x315 > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > --- syscall (393, FreeBSD ELF32, sendfile), eip = 0x28290bff, esp = > > 0xbfbfc6ac, ebp = 0xbfbfe718 --- > > What is the lock it holds, and where is it acquired? Hope this if enough, if not please tell me what commands I need to issue in ddb ;-) Sleeping thread (tid 100025, pid 26) owns a non-sleepable lock sched_switch(c4d00e00,0,1,1ede764,23150ee,...) at sched_switch+0x190 mi_switch(1,0) at mi_switch+0x13f sleepq_switch(c4d00e00,0,c078a4e2,21b,c07e3820,...) at sleepq_switch+0x87 sleepq_wait(c07e3820,0,c0770b7e,3,0,...) at sleepq_wait+0x36 _sx_xlock_hard(c07e3820,c4d00e00,0,0,0,...) at _sx_xlock_hard+0x21d fr_checknatout(f5ede850,f5ede84c,64,c400,0,...) at fr_checknatout+0x29d fr_check(c5733344,14,c4de7400,1,f5ede934,...) at fr_check+0x9b1 fr_check_wrapper(0,f5ede934,c4de7400,2,c584e498,...) at fr_check_wrapper+0x3f pfil_run_hooks(c08057c0,f5ede9cc,c4de7400,2,c584e498,...) at pfil_run_hooks+0x74 ip_output(c5733300,0,f5ede990,0,0,...) at ip_output+0x913 tcp_output(c55bb000,b9ba2480,b9ba2a28,f5edead4,c065f1ef,...) at tcp_output+0x1106 tcp_do_segment(c55bb000,34,5a8,4b1e708c,b0ee,...) at tcp_do_segment+0x1ba7 tcp_input(c8597200,14,c4de7400,1,0,...) at tcp_input+0x935 ip_input(c8597200,c8597200,800,c4de7400,800,...) at ip_input+0x6cf netisr_dispatch(2,c8597200,10,3,0,...) at netisr_dispatch+0x57 ether_demux(c4de7400,c8597200,3,0,3,...) at ether_demux+0x1a3 ether_input(c4de7400,c8597200,c4d00e00,0,1,...) at ether_input+0x313 em_handle_rxtx(c4da2800,1,c4dd8880,c4dd889c,c07811ce,...) at em_handle_rxtx+0x41c taskqueue_run(c4dd8880,c4dd889c,c07811ce,0,f5edecf4,...) at taskqueue_run+0x174 taskqueue_thread_loop(c4da2aec,f5eded38,0,0,0,...) at taskqueue_thread_loop+0xb5 fork_exit(c05c3e06,c4da2aec,f5eded38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf5eded70, ebp = 0 --- panic: sleeping thread cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper(c0789bc6,f9d5baa0,c05973a0,c07a12bc,1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07a12bc,1,c078a9b5,f9d5baac,1,...) at kdb_backtrace+0x29 panic(c078a9b5,ffffffff,1a,cb,c51fea00,...) at panic+0x10f propagate_priority(c51fea00,c5091050,c078a956,2d8,f9d5baec,...) at propagate_priority+0x114 turnstile_wait(c5091050,c4d00e00,0,c584e498,c5531c60,...) at turnstile_wait+0x2e9 _mtx_lock_sleep(c584e528,c51fea00,0,0,0,...) at _mtx_lock_sleep+0xde tcp_usr_rcvd(c5531c60,0,f9d5bc60,0,0,...) at tcp_usr_rcvd+0x53 soreceive_generic(c5531c60,0,f9d5bc60,0,0,...) at soreceive_generic+0xef4 soreceive(c5531c60,0,f9d5bc60,0,0,...) at soreceive+0x38 soo_read(cd936828,f9d5bc60,cdce6500,0,c51fea00,...) at soo_read+0x3b dofileread(f9d5bc60,ffffffff,ffffffff,0,cd936828,...) at dofileread+0x90 kern_readv(c51fea00,3,f9d5bc60,2822affc,0,...) at kern_readv+0x52 read(c51fea00,f9d5bcfc,c,0,ffffffff,...) at read+0x4f syscall(f9d5bd38) at syscall+0x315 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x2818c64f, esp = 0xbfbfb20c, ebp = 0xbfbfb358 --- KDB: enter: panic [thread pid 18996 tid 100158 ] Stopped at kdb_enter+0x332: leave db> show allchain chain 1: thread 100158 (pid 18996, rsync) blocked on lock 0xc584e528 (sleep mutex) "inp" thread 100025 (pid 26, em0 taskq) inhibited db > show sleepchain thread 100158 (pid 18996, rsync) inhibited db> show lock 0xc584e528 class: sleep mutex name: inp type: tcpinp flags: {DEF, RECURSE, DUPOK} state: {OWNED, CONTESTED} owner: 0xc4d00e00 (tid 100025, pid 26, "em0 taskq") db> The rsync thread is in another jail which has public ip. Regards, Rong-En Fan > kris > From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 11:54:21 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 656E616A417 for ; Sun, 12 Aug 2007 11:54:21 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id E3C3F13C4B0 for ; Sun, 12 Aug 2007 11:54:20 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l7CBhMRC016019 for ; Sun, 12 Aug 2007 21:13:22 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Sun, 12 Aug 2007 21:24:11 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Aug 2007 21:11:15 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.1/8.14.1) with ESMTP id l7CBeML0093262 for ; Sun, 12 Aug 2007 19:40:22 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.1/8.14.1/Submit) id l7CBeHvL093261 for freebsd-current@freebsd.org; Sun, 12 Aug 2007 19:40:17 +0800 (WST) (envelope-from wilkinsa) Date: Sun, 12 Aug 2007 19:40:17 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20070812114017.GA93036@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 12 Aug 2007 11:41:15.0557 (UTC) FILETIME=[B0CABD50:01C7DCD5] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.0.1021-15354.001 X-TM-AS-Result: No-6.243900-0.000000-31 Content-Transfer-Encoding: 7bit Subject: Larger NGROUPS_MAX in CURRENT ? Ready for 7.0-R ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 11:54:21 -0000 Hi all, According to the following post: [http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-05/1086.html] Robert Watson has said there was work in the pipeline to increase NGROUPS_MAX to hundreds and even thousands of groups. Does anyone know if this work got done ? Will be included in 7.0-R ? Robert ? Lots of us are hitting the maximum group limit of 16 and this is a painful experience when authenticating FreeBSD against AD when users are in 30-60 groups :( -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 12:52:36 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7745616A41A; Sun, 12 Aug 2007 12:52:36 +0000 (UTC) (envelope-from brucec@muon.bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id 138CB13C457; Sun, 12 Aug 2007 12:52:35 +0000 (UTC) (envelope-from brucec@muon.bluestop.org) Received: by muon.bluestop.org (Postfix, from userid 1000) id 5FD9130123; Sun, 12 Aug 2007 13:48:41 +0100 (BST) Date: Sun, 12 Aug 2007 13:48:41 +0100 From: bruce@cran.org.uk To: Don Lewis Message-ID: <20070812124840.GA5465@muon.bluestop.org> References: <200708120157.l7C1vWcI060342@gw.catspoiler.org> <200708120442.l7C4gtMP060591@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708120442.l7C4gtMP060591@gw.catspoiler.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@FreeBSD.org Subject: Re: RE: Reboot on "shutdown -r" hangs after final "uptime ..." string X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 12:52:36 -0000 On Sat, Aug 11, 2007 at 09:42:55PM -0700, Don Lewis wrote: > On 11 Aug, Don Lewis wrote: > > On 11 Aug, To: bruce@cran.org.uk wrote: > >> On 12 Aug, bruce@cran.org.uk wrote: > > > >> Something that you might want to also print is the value of > >> EOREAD4(sc, EHCI_USBSTS) > >> immediately before the > >> EOWRITE4(sc, EHCI_USBCMD, EHCI_CMD_HCRESET); > >> call in ehci_hcreset(). Bit 12 of this register (EHCI_STS_HCH) should > >> be a zero before the write to do the reset is performed. > > > > Correction, this bit should be a one before doing the reset. > > > >> Maybe > >> ehci_hcreset() needs to wait for that to happen (as is done in > >> ehci_init()), rather than just waiting a fixed amount of time. > > > > I misread the code in ehci_init(), which is waiting for a transition in > > the opposite direction. I don't know why, because the EHCI spec says > > that the 1->0 transition is immediate. > > A revised version of the patch is below. The only change is the > addition of a second wait loop in ehci_hcreset(), which would be > necessary according the the EHCI spec if the controller could ever > require more than 1ms to stop. > > This patch might fix the problem on your machine if you are observing a > zero for bit 12 (EHCI_STS_HCH) of the EHCI_USBSTS register in > ehci_hcreset(). > > Index: sys/dev/usb/ehci.c > > > If this doesn't help, you could test the SMI hypothesis by disabling the > SMI on OS Ownership Enable bit before clearing the EHCI_LEGSUP_OSOWNED > bit. Something like the following should disable the SMI enable bit, > but I don't know what side effects it might have. It could even melt > your computer ;-) In any case, it's not a proper fix. > > static void > ehci_pci_givecontroller(device_t self) > { > ehci_softc_t *sc = device_get_softc(self); > u_int32_t cparams, eec, legsup; > int eecp; > > cparams = EREAD4(sc, EHCI_HCCPARAMS); > for (eecp = EHCI_HCC_EECP(cparams); eecp != 0; > eecp = EHCI_EECP_NEXT(eec)) { > eec = pci_read_config(self, eecp, 4); > if (EHCI_EECP_ID(eec) != EHCI_EC_LEGSUP) > continue; > /* NEW */ legsup = pci_read_config(self,eecp+EHCI_LEGSUP_USBLEGCTLSTS,4); > /* NEW */ legsup = legsup & ~0x200; > /* NEW */ pci_write_config(self, eecp+EHCI_LEGSUP_USBLEGCTLSTS, legsup,4); > legsup = eec; > pci_write_config(self, eecp, legsup & ~EHCI_LEGSUP_OSOWNED, 4); > } > } > > Thanks for your help. The revised patch doesn't change the behaviour; in ehci_pci_givecontroller, eec has the value 0x1000001 and the pci_read_config returns 0xC0002000. Disabling the SMI bit doesn't help either, but something I have noticed it that (both with and without the SMI disabling code) I get an 'f' printed on the console occasionally, which is probably from the printf I put in, "finished in ehci_pci_givecontroller": // code to disable SMI bit... DPRINTF(("pci_write_config in ehci_pci_givecontroller\n")); pci_write_config(...) // end for loop DPRINT(("finished in ehci_pci_givecontroller\n")); // end of ehci_pci_givecontroller function which suggests that something is causing the system to hang after the pci_write_config has finished. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 16:47:09 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F6EF16A418 for ; Sun, 12 Aug 2007 16:47:09 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by mx1.freebsd.org (Postfix) with ESMTP id A4DD413C45E for ; Sun, 12 Aug 2007 16:47:08 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.19] (helo=mx9.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.68-dev) (envelope-from ) id 1IKGap-0007Hg-3B; Sun, 12 Aug 2007 18:47:07 +0200 Received: from rac74.r.pppool.de ([89.54.172.116]:51990 helo=peedub.jennejohn.org) by mx9.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.68-dev #12) id 1IKGap-0006nU-17; Sun, 12 Aug 2007 18:47:07 +0200 Date: Sun, 12 Aug 2007 18:47:01 +0200 From: Gary Jennejohn To: Bruce Cran Message-Id: <20070812184701.8e71b41d.gary.jennejohn@freenet.de> In-Reply-To: <46BE1D6C.6040903@cran.org.uk> References: <3979a4b0707291120v4927a20cm357b845f6d1f3567@mail.gmail.com> <46BE1D6C.6040903@cran.org.uk> Organization: DENX Softwre Engineering GmbH X-Mailer: Sylpheed 2.4.4 (GTK+ 2.10.13; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: console hangs after setting hostname X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 16:47:09 -0000 On Sat, 11 Aug 2007 21:34:52 +0100 Bruce Cran wrote: > KOT MATPOCKuH wrote: > > I got a problem. After messages on console: > > ... > > Mounting local files systems:. > > Setting hostname: green. > > fxp: link state changed to UP > > nfe0: link state changed to DOWN > > > > console hangs. > > No any new messages, I can't input anything from keyboard, changing virtual > > consoles is not working. After X is started, console is not switched to xdm > > display. > > But system is works - I can login to system via ssh, ... > > > > dmesg.boot is attached. > > > > Where is a problem and what I need to do? :) > > > > I'm also seeing the console hang, but in a different situation. If I > attach and remove my iPod the console hangs - the only key press that's > accepted is ctrl-alt-esc to break into the debugger. > > umass0: on uhub5 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 19073MB (39063024 512 byte sectors: 255H 63S/T 2431C) > (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 2 54 d ef 0 0 1 0 > (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (da0:umass-sim0:0:0:0): SCSI Status: Check Condition > (da0:umass-sim0:0:0:0): ILLEGAL REQUEST asc:21,0 > (da0:umass-sim0:0:0:0): Logical block address out of range > (da0:umass-sim0:0:0:0): Unretryable error > (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 2 54 d ef 0 0 1 0 > (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (da0:umass-sim0:0:0:0): SCSI Status: Check Condition > (da0:umass-sim0:0:0:0): ILLEGAL REQUEST asc:21,0 > (da0:umass-sim0:0:0:0): Logical block address out of range > (da0:umass-sim0:0:0:0): Unretryable error > GEOM_LABEL: Label for provider da0s2 is msdosfs/IPOD. > > When I remove the iPod I get the following messages: > > umass0: at uhub5 port 1 (addr 2) disconnected > da0:umass-sim0:0:0G:0EO :M _LlAoBst L d ev aibceel <-- garbled > )m(sd ao0s:fs m/aIsPsO-Ds irme0m:o0v:ed :.0 <-- output > : removing device entry > umass0: detached > I reported this problem at least a month ago. The garbled ouput to the console somehow completely screws things up so that only output from the kernel appears thereafter. I have no idea why this happens, but the pattern is very clear. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 17:38:56 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD8A916A420 for ; Sun, 12 Aug 2007 17:38:56 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.bluestop.org (muon.bluestop.org [80.68.94.188]) by mx1.freebsd.org (Postfix) with ESMTP id 8498D13C461 for ; Sun, 12 Aug 2007 17:38:56 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.draftnet (dyn-62-56-68-171.dslaccess.co.uk [62.56.68.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTP id ED9BE30123; Sun, 12 Aug 2007 18:11:55 +0100 (BST) Message-ID: <46BF4017.6090900@cran.org.uk> Date: Sun, 12 Aug 2007 18:15:03 +0100 From: Bruce Cran User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: Bruno Damour References: <46BE8495.2000308@free.fr> In-Reply-To: <46BE8495.2000308@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: TCP errors ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 17:38:56 -0000 Bruno Damour wrote: > Hello, > > I'm getting a lot of messages like this, what is that supposed to come > from ? > No harm done AFAIK but my dmesg gets bloated ? > > TCP: [192.168.0.100]:389 to [192.168.0.100]:53612 tcpflags > 0x18; tcp_do_segment: FIN_WAIT_2: Received data after > socket was closed, sending RST and removing tcpcb They're expected as part of some new debugging code in the TCP stack - see http://lists.freebsd.org/pipermail/freebsd-current/2007-August/075984.html for details. To stop them being displayed, set sys.net.inet.tcp.log_debug. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 17:51:29 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3FB816A41B for ; Sun, 12 Aug 2007 17:51:29 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id C529713C45A for ; Sun, 12 Aug 2007 17:51:29 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id l7CHpHIg063518; Sun, 12 Aug 2007 10:51:21 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200708121751.l7CHpHIg063518@gw.catspoiler.org> Date: Sun, 12 Aug 2007 10:51:17 -0700 (PDT) From: Don Lewis To: bruce@cran.org.uk In-Reply-To: <20070812124840.GA5465@muon.bluestop.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: current@FreeBSD.org Subject: Re: RE: Reboot on "shutdown -r" hangs after final "uptime ..." string X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 17:51:30 -0000 On 12 Aug, bruce@cran.org.uk wrote: > On Sat, Aug 11, 2007 at 09:42:55PM -0700, Don Lewis wrote: > Thanks for your help. The revised patch doesn't change the behaviour; It was a shot in the dark ... > in > ehci_pci_givecontroller, eec has the value 0x1000001 and the > pci_read_config returns 0xC0002000. Disabling the > SMI bit doesn't help either, Whoops, bit 13 is set in this register. In my test code, I told you to use the mask ~0x200, but the mask should have been ~0x2000. > but something I have noticed it that > (both with and without the SMI disabling code) I get an 'f' printed on > the console occasionally, which is probably from the printf I put in, > "finished in ehci_pci_givecontroller": > > // code to disable SMI bit... > DPRINTF(("pci_write_config in ehci_pci_givecontroller\n")); > pci_write_config(...) > // end for loop > DPRINT(("finished in ehci_pci_givecontroller\n")); > // end of ehci_pci_givecontroller function > > which suggests that something is > causing the system to hang after the pci_write_config has finished. The logical thing would be the SMI triggered by the pci_write_config(). There might be some uncertainty about the timing of the interrupt, which would account for the uncertainty in the appearance of the 'f'. From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 20:31:57 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38BFC16A417 for ; Sun, 12 Aug 2007 20:31:57 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (adsl-75-1-14-242.dsl.scrm01.sbcglobal.net [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 17AA413C461 for ; Sun, 12 Aug 2007 20:31:57 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id l7CKVo3b063733 for ; Sun, 12 Aug 2007 13:31:54 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200708122031.l7CKVo3b063733@gw.catspoiler.org> Date: Sun, 12 Aug 2007 13:31:50 -0700 (PDT) From: Don Lewis To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: Subject: CFR/CFT: IPv6 patch for quota (PR 42004) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 20:31:57 -0000 PR 42004, which has been open for nearly five years, includes the patch below to add IPv6 support to /usr/bin/quota. This patch applies cleanly and compiles without error, but I'm unable to test it because I use neither IPv6 nor disk quotas over NFS. If someone who uses IPv6 and quotas over NFS can test this patch, then we could commit this change and close the PR. --- usr.bin/quota/quota.c.1.18 Fri Aug 9 06:36:48 2002 +++ usr.bin/quota/quota.c Sun Aug 25 17:43:36 2002 @@ -665,26 +665,20 @@ callaurpc(char *host, int prognum, int versnum, int procnum, xdrproc_t inproc, char *in, xdrproc_t outproc, char *out) { - struct sockaddr_in server_addr; enum clnt_stat clnt_stat; - struct hostent *hp; struct timeval timeout, tottimeout; - CLIENT *client = NULL; - int sock = RPC_ANYSOCK; + CLIENT *client; - if ((hp = gethostbyname(host)) == NULL) - return ((int) RPC_UNKNOWNHOST); + /* XXX - If clnt_call fails, we should try other addresses and AF_ */ + client = clnt_create(host, prognum, versnum, "udp"); + if (client == NULL) + return ((int) rpc_createerr.cf_stat); + timeout.tv_usec = 0; timeout.tv_sec = 6; - bcopy(hp->h_addr, &server_addr.sin_addr, - MIN(hp->h_length,(int)sizeof(server_addr.sin_addr))); - server_addr.sin_family = AF_INET; - server_addr.sin_port = 0; - - if ((client = clntudp_create(&server_addr, prognum, - versnum, timeout, &sock)) == NULL) - return ((int) rpc_createerr.cf_stat); + (void) CLNT_CONTROL(client, + CLSET_RETRY_TIMEOUT, (char *)(void *)&timeout); client->cl_auth = authunix_create_default(); tottimeout.tv_sec = 25; From owner-freebsd-current@FreeBSD.ORG Sun Aug 12 21:04:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 504E816A417 for ; Sun, 12 Aug 2007 21:04:11 +0000 (UTC) (envelope-from stuartb@4gh.net) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id C071A13C46C for ; Sun, 12 Aug 2007 21:04:10 +0000 (UTC) (envelope-from stuartb@4gh.net) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 12 Aug 2007 16:35:14 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.8.3-GA) with ESMTP id NQS24820; Sun, 12 Aug 2007 16:35:13 -0400 (EDT) Received: from 216-15-55-106.c3-0.slvr-ubr2.lnh-slvr.md.cable.rcn.com (HELO freeman.4gh.net) ([216.15.55.106]) by smtp01.lnh.mail.rcn.net with ESMTP; 12 Aug 2007 16:35:13 -0400 Received: by freeman.4gh.net (Postfix, from userid 1001) id 96EFA117F1; Sun, 12 Aug 2007 16:35:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by freeman.4gh.net (Postfix) with ESMTP id 7A7A4117EF for ; Sun, 12 Aug 2007 16:35:13 -0400 (EDT) Date: Sun, 12 Aug 2007 16:35:13 -0400 (EDT) From: Stuart Barkley cc: FreeBSD Current In-Reply-To: <46BE7310.8020802@psg.com> Message-ID: <20070812163147.U64666@freeman.4gh.net> References: <46BE7310.8020802@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Junkmail-Status: score=10/50, host=mr02.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090209.46BF6F01.00B4,ss=1,fgs=0, ip=207.172.4.11, so=2006-12-09 10:45:40, dmn=5.3.14/2007-05-31 X-Mailman-Approved-At: Sun, 12 Aug 2007 22:07:03 +0000 Subject: Re: change in less for ti@:te@ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2007 21:04:11 -0000 Having recently begun using Linux again for $DAYJOB, I've been reminded that I like adding the following to my .Xresources file: XTerm*tiXtraScroll: true XTerm*titeInhibit: true Stuart -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 05:03:35 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42AAE16A417 for ; Mon, 13 Aug 2007 05:03:35 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from smtp02.dentaku.gol.com (smtp02.dentaku.gol.com [203.216.5.72]) by mx1.freebsd.org (Postfix) with ESMTP id 1754F13C469 for ; Mon, 13 Aug 2007 05:03:34 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[127.0.0.1]) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1IKS5V-0000Gu-K1 for ; Mon, 13 Aug 2007 14:03:33 +0900 Message-ID: <46BFE620.8070906@fusiongol.com> Date: Mon, 13 Aug 2007 14:03:28 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL X-Abuse-Complaints: abuse@gol.com Subject: Promise SATA 300 TX4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 05:03:35 -0000 >I tried to roll back to right before the above mentioned change >Karsten (well, I assume it was him :-) ) noted on IRC that it might >be the cause of the problems since I have a similar controller, though >not exactly the same one, but it didn't fix the timeouts for me. >For this server I have 3 disks in a graid3 (so no ZFS but the errors >are similar to what I have seen / heard about wrt. ZFS + ata use) and >I get timeouts several times a day which causes FreeBSD to loose >contact with one or more disks where I have to reboot before things >recover (usually FreeBSD panic's enough so the system reboots by >itself). I'm certain that the issue with this card isn't limited to ZFS. It's been seen before in the 6.x series too. I really would like to find out which code changes ruined the card's correct operation... if that could help the ata maintainer in some way. Unfortunately my csup-fu isn't that strong, otherwise I would send my source tree back to June 15th and analyse daily buildworlds from that date until I could pin-point the exact date and file changes that caused the problem all of us are seeing. Could someone teach me how to do csup rollbacks to a specific date in the source tree? If it's not obvious already, I'd really like to squash this bug. From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 05:55:19 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDB3016A468 for ; Mon, 13 Aug 2007 05:55:19 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id E241213C442 for ; Mon, 13 Aug 2007 05:55:18 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l7D5iOh7010726 for ; Mon, 13 Aug 2007 15:14:24 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Mon, 13 Aug 2007 15:25:11 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 15:25:11 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.1/8.14.1) with ESMTP id l7D5sGof098196 for ; Mon, 13 Aug 2007 13:54:16 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.1/8.14.1/Submit) id l7D5sG1t098195 for freebsd-current@freebsd.org; Mon, 13 Aug 2007 13:54:16 +0800 (WST) (envelope-from wilkinsa) Date: Mon, 13 Aug 2007 13:54:16 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20070813055415.GM93381@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 13 Aug 2007 05:55:12.0059 (UTC) FILETIME=[833220B0:01C7DD6E] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.0.1021-15354.001 X-TM-AS-Result: No--6.933700-0.000000-31 Content-Transfer-Encoding: 7bit Subject: ZVOL/ZFS hosting UFS filesystems ... ERROR! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 05:55:20 -0000 Hi all, I need to use UFS within a ZVOL so that I can use POSIX ACLs. i.e. since ZFS on FreeBSD doesn't (yet) support POSIX ACLs. The problem -~-~-~-~-~- /boot/kernel/zfs.ko seems to be loaded after /etc/fstab is read. And I need zfs.ko to be loaded before /etc/fstab is read i.e because to mount a ZVOL automatically defined in fstab(5) zfs.ko needs to be loaded. Currently when boostrapping I get the following error: "Can't stat /dev/zvol/data_dg/export/ufs Unknown error; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)!" And I drop into single user mode. The line causing this in fstab(5) is: /dev/zvol/data_dg/export/ufs /export/mod ufs rw,acls 1 1 Can anyone recommend how I can get around this ? Thanks -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 06:50:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18AD216A419 for ; Mon, 13 Aug 2007 06:50:34 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by mx1.freebsd.org (Postfix) with ESMTP id 9D90E13C442 for ; Mon, 13 Aug 2007 06:50:33 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1567359mue for ; Sun, 12 Aug 2007 23:50:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pmzNFPpE9uOXgWB4Gyenlq08fDpL+ANFJkPfiOB/oWkEMUwGIOKjEIFeeQVxUCeDhM97q5RbWigOG59BSOU3QGdVjeUGT/ak1B+Dki+WihVx7YPMAjCx6su7dBMt39d3rO5Ce+sUer5dJKUZr9ZCmkmhg0d5QviyUGETAsXvsXk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AfbuAuLnPeOIowWFHKtCh11j+3ZuhomVopKIK+NqxQhNiYnilDnw8jgV6MYQU5HlenXbYEH6/NRWq5RCcfSOizoJwrGCpYvwgU7H0zUzm3RygwnRD/jJ5miKh/sQ+17syU8fCrejm8lAv27kpmu1Yaby4B4NSX6c+J1p0v9/RtI= Received: by 10.86.51.2 with SMTP id y2mr4464139fgy.1186987832333; Sun, 12 Aug 2007 23:50:32 -0700 (PDT) Received: by 10.86.59.6 with HTTP; Sun, 12 Aug 2007 23:50:32 -0700 (PDT) Message-ID: <790a9fff0708122350w729761d1v72e6aaff414d3756@mail.gmail.com> Date: Mon, 13 Aug 2007 01:50:32 -0500 From: "Scot Hetzel" To: freebsd-current@freebsd.org In-Reply-To: <20070813055415.GM93381@obelix.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070813055415.GM93381@obelix.dsto.defence.gov.au> Subject: Re: ZVOL/ZFS hosting UFS filesystems ... ERROR! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 06:50:34 -0000 On 8/13/07, Wilkinson, Alex wrote: > Currently when boostrapping I get the following error: > > "Can't stat /dev/zvol/data_dg/export/ufs > Unknown error; help! > ERROR: ABORTING BOOT (sending SIGTERM to parent)!" > > And I drop into single user mode. > > The line causing this in fstab(5) is: > > /dev/zvol/data_dg/export/ufs /export/mod ufs rw,acls 1 1 > > Can anyone recommend how I can get around this ? > Try using: /dev/zvol/data_dg/export/ufs /export/mod ufs rw,acls,late 1 1 I had a similar problem, except I was mounting UFS filesystems (/dev/ad0s2d) on to a mount point that was in a ZFS filesystem. When I added the 'late' option, I nolonger saw messages that the mount point didn't exist. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 07:06:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DDC316A419 for ; Mon, 13 Aug 2007 07:06:34 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7DFCD13C48D for ; Mon, 13 Aug 2007 07:06:33 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l7D6tcUk028367 for ; Mon, 13 Aug 2007 16:25:38 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Mon, 13 Aug 2007 16:36:27 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 16:36:26 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.1/8.14.1) with ESMTP id l7D75USI098695 for ; Mon, 13 Aug 2007 15:05:30 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.1/8.14.1/Submit) id l7D75U5q098694 for freebsd-current@freebsd.org; Mon, 13 Aug 2007 15:05:30 +0800 (WST) (envelope-from wilkinsa) Date: Mon, 13 Aug 2007 15:05:30 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20070813070530.GT93381@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20070813055415.GM93381@obelix.dsto.defence.gov.au> <790a9fff0708122350w729761d1v72e6aaff414d3756@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <790a9fff0708122350w729761d1v72e6aaff414d3756@mail.gmail.com> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 13 Aug 2007 07:06:26.0876 (UTC) FILETIME=[772F6FC0:01C7DD78] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.0.1021-15354.001 X-TM-AS-Result: No--4.542900-0.000000-2 Content-Transfer-Encoding: 7bit Subject: Re: ZVOL/ZFS hosting UFS filesystems ... ERROR! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 07:06:34 -0000 0n Mon, Aug 13, 2007 at 01:50:32AM -0500, Scot Hetzel wrote: >On 8/13/07, Wilkinson, Alex wrote: >> Currently when boostrapping I get the following error: >> >> "Can't stat /dev/zvol/data_dg/export/ufs >> Unknown error; help! >> ERROR: ABORTING BOOT (sending SIGTERM to parent)!" >> >> And I drop into single user mode. >> >> The line causing this in fstab(5) is: >> >> /dev/zvol/data_dg/export/ufs /export/mod ufs rw,acls 1 1 >> >> Can anyone recommend how I can get around this ? >> >Try using: > > /dev/zvol/data_dg/export/ufs /export/mod ufs rw,acls,late 1 1 > >I had a similar problem, except I was mounting UFS filesystems >(/dev/ad0s2d) on to a mount point that was in a ZFS filesystem. When >I added the 'late' option, I nolonger saw messages that the mount >point didn't exist. Unfortuneately the 'late' option does not help. Exact same problem as I have described above with 'late' included in fstab(5). :-( I am dropped into single user mode, then I have to: #/etc/rc.d/hostid start #/etc/rc.d/zfs start #mount /export/mod #^D And THEN all is good. OR set "noauto" in fstab(5) for /export/mod :-( -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 08:03:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26A1416A41B for ; Mon, 13 Aug 2007 08:03:39 +0000 (UTC) (envelope-from ks@dlx.dk) Received: from exch.hoffice.dk (exch.hoffice.dk [87.61.124.141]) by mx1.freebsd.org (Postfix) with ESMTP id C4CE413C45E for ; Mon, 13 Aug 2007 08:03:38 +0000 (UTC) (envelope-from ks@dlx.dk) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Aug 2007 10:04:24 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: In-Reply-To: <46BFE620.8070906@fusiongol.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Promise SATA 300 TX4 Thread-Index: AcfdZ6hDxOjsbHpCQLCTUI5Ux1D7zAAGHZzQ References: <46BFE620.8070906@fusiongol.com> From: "Karsten W. Schmidt / DLX ApS" To: Subject: RE: Promise SATA 300 TX4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 08:03:39 -0000 >Could someone teach me how to do csup rollbacks to a specific date in >the source tree? If it's not obvious already, I'd really like to squash >this bug. Put a line like this in your supfile *date=3D2007.06.16.00.00.00 The format is taken from csup(1) date=3D[cc]yy.mm.dd.hh.mm.ss --=20 Karsten From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 08:23:01 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CF3916A41A for ; Mon, 13 Aug 2007 08:23:01 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from nxm.secservers.com (nxm.secservers.com [89.185.226.22]) by mx1.freebsd.org (Postfix) with ESMTP id B2D1213C46C for ; Mon, 13 Aug 2007 08:23:00 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from [127.0.0.1] (nxm.secservers.com. [89.185.226.22]) by nxm.secservers.com (8.13.4/8.13.8) with ESMTP id l7D8AKCh035694; Mon, 13 Aug 2007 10:10:20 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Trigve Siver In-Reply-To: <179073.30151.qm@web52707.mail.re2.yahoo.com> References: <179073.30151.qm@web52707.mail.re2.yahoo.com> Content-Type: text/plain Date: Mon, 13 Aug 2007 10:10:12 +0200 Message-Id: <1186992612.1207.9.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Error while 'make buildworld' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 08:23:01 -0000 Trigve Siver wrote: > Hi all, > > I'm trying to compile freebsd current (to test PMC) from cvs... But when I try to 'make buildworld' it throw me this error: > //-------------- > ... > /usr/local/libexec/ccache/world-cc -O1 -pipe -O2 -pipe -s -O2 -pipe -s -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c > In file included from ./tm.h:4, > from /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c:24: > ./options.h:375: error: redeclaration of enumerator `OPT_d' > ./options.h:373: error: previous definition of 'OPT_d' was here > ./options.h:898: error: redeclaration of enumerator `OPT_w' > ./options.h:896: error: previous definition of 'OPT_w' was here > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/cc/cc_tools. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > //----------------- > > uname: > > FreeBSD pentium4.domain 6.2-STABLE FreeBSD 6.2-STABLE #0: Sat Aug 11 > 12:16:01 UTC 2007 > dodes@pentium4.domain:/usr/obj/usr/src/sys/CUSTOM i386 > > I've tried to search the net but haven't found anything. I encounter the problem too and I am quite certain it is cause by the locale settings (at least in my case). As src/UPDATING suggests, you should build with "sanitized" environment (e.g. precede your build sesssion by 'env -i' or unset LC_* or LANG or similar. HTH Michal From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 08:23:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEBFE16A480 for ; Mon, 13 Aug 2007 08:23:27 +0000 (UTC) (envelope-from takeharu1219@ybb.ne.jp) Received: from ybbsmtp12.mail.ogk.yahoo.co.jp (ybbsmtp12.mail.ogk.yahoo.co.jp [124.83.153.132]) by mx1.freebsd.org (Postfix) with SMTP id 66E6713C478 for ; Mon, 13 Aug 2007 08:23:27 +0000 (UTC) (envelope-from takeharu1219@ybb.ne.jp) Received: (qmail 17133 invoked by alias); 13 Aug 2007 07:56:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ybb20050223; d=ybb.ne.jp; b=dPrYEDzn3lXQcZ9kGSvRlzqWNwnW+AdjTgT921JQcMvhFfo1fzbonB3xJ92v8S641IVXNRPcr8sMPq5j+HjmBsujnIdNsl+apzo/CWVDWC4MsisZKI0sccYnxjZxueAS ; Received: from unknown (HELO ?127.0.0.1?) (takeharu1219@219.35.170.86 with plain) by ybbsmtp12.mail.ogk.yahoo.co.jp with SMTP; 13 Aug 2007 07:56:44 -0000 X-Apparently-From: Message-ID: <46C00EB4.1030707@ybb.ne.jp> Date: Mon, 13 Aug 2007 16:56:36 +0900 From: Takeharu KATO User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Mike Tancsa References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> <86tzuxni1b.fsf@dwp.des.no> <200707061723.l66HNYSe037055@lava.sentex.ca> <86ir86hqhc.fsf@ds4.des.no> <200707262035.l6QKZtnd067391@lava.sentex.ca> <86abtihk6h.fsf@ds4.des.no> <200707262338.l6QNcL1T068284@lava.sentex.ca> <86hcnq900e.fsf@ds4.des.no> <200707270038.l6R0cLNV068524@lava.sentex.ca> <8664462p1b.fsf@ds4.des.no> <200707271037.l6RAbc2Q071412@lava.sentex.ca> <86fy2v2x9e.fsf@ds4.des.no> <200708071529.l77FTpsO040934@lava.sentex.ca> In-Reply-To: <200708071529.l77FTpsO040934@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 08:23:27 -0000 Hi, Would you these patches with verbose mode? As far as I know, ichwd patches does not show error messages when the system make the watch-dog disabled with TCO register as default. The driver may output some error messages if you use it with verbose mode. P.S. Thank you for your work, Mr. DES. I'm testing your patch now. > Original posted patch and your patch reboot this box running RELENG_6 > > ichwd0: at port 0x430-0x437,0x460-0x469 on isa0 > ichwd0: Intel ICH7 watchdog timer (TCO version 2) > ppc0: parallel port not found. > > ichwd module loaded > ichwd0: on isa0 > ichwd0: Intel ICH7 watchdog timer (ICH7 or equivalent) > ppc0: parallel port not found. > > >> I've tested the driver under -CURRENT on a couple more machines, with >> the same result everywhere: it probes and attaches and seems to work >> fine, but the box does not reboot. > > kldload ichwd, watchdogd -t 20;killall -9 watchdogd > and nada ? > I can boot one of my working RELENG_6 boxes on current and test if you > think it is some version issue. > > ---Mike > > >> I haven't tried RELENG_6 on the same hardware, though. >> >> I have no idea where to go on from here... > From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 08:35:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2D4C16A420 for ; Mon, 13 Aug 2007 08:35:14 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id AC74C13C467 for ; Mon, 13 Aug 2007 08:35:14 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 8B14820B2; Mon, 13 Aug 2007 10:35:07 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 7DCB320B1; Mon, 13 Aug 2007 10:35:07 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 682268444F; Mon, 13 Aug 2007 10:35:07 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Takeharu KATO References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> <86tzuxni1b.fsf@dwp.des.no> <200707061723.l66HNYSe037055@lava.sentex.ca> <86ir86hqhc.fsf@ds4.des.no> <200707262035.l6QKZtnd067391@lava.sentex.ca> <86abtihk6h.fsf@ds4.des.no> <200707262338.l6QNcL1T068284@lava.sentex.ca> <86hcnq900e.fsf@ds4.des.no> <200707270038.l6R0cLNV068524@lava.sentex.ca> <8664462p1b.fsf@ds4.des.no> <200707271037.l6RAbc2Q071412@lava.sentex.ca> <86fy2v2x9e.fsf@ds4.des.no> <200708071529.l77FTpsO040934@lava.sentex.ca> <46C00EB4.1030707@ybb.ne.jp> Date: Mon, 13 Aug 2007 10:35:07 +0200 In-Reply-To: <46C00EB4.1030707@ybb.ne.jp> (Takeharu KATO's message of "Mon\, 13 Aug 2007 16\:56\:36 +0900") Message-ID: <86y7gf6ddw.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Mike Tancsa Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 08:35:15 -0000 Takeharu KATO writes: > Would you these patches with verbose mode? > As far as I know, ichwd patches does not show error messages when > the system make the watch-dog disabled with TCO register as default. if (rc) device_printf(sc->device, "ICH WDT present but disabled in BIOS or hardware\n"); DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 09:19:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB91C16A418 for ; Mon, 13 Aug 2007 09:19:13 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from merke.itea.ntnu.no (merke.itea.ntnu.no [129.241.7.61]) by mx1.freebsd.org (Postfix) with ESMTP id 98F1913C428 for ; Mon, 13 Aug 2007 09:19:13 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by merke.itea.ntnu.no (Postfix) with ESMTP id 98A641423C2; Mon, 13 Aug 2007 11:19:12 +0200 (CEST) Received: from caracal.stud.ntnu.no (caracal.stud.ntnu.no [129.241.56.185]) by merke.itea.ntnu.no (Postfix) with ESMTP; Mon, 13 Aug 2007 11:18:21 +0200 (CEST) Received: by caracal.stud.ntnu.no (Postfix, from userid 2312) id DEF736240E2; Mon, 13 Aug 2007 11:18:02 +0200 (CEST) Date: Mon, 13 Aug 2007 11:18:02 +0200 From: Ulf Lilleengen To: Nathan Butcher Message-ID: <20070813091802.GB3078@stud.ntnu.no> References: <46BFE620.8070906@fusiongol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46BFE620.8070906@fusiongol.com> User-Agent: Mutt/1.5.9i X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: freebsd-current@freebsd.org Subject: Re: Promise SATA 300 TX4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 09:19:13 -0000 On Mon, Aug 13, 2007 at 02:03:28PM +0900, Nathan Butcher wrote: > >I tried to roll back to right before the above mentioned change > >Karsten (well, I assume it was him :-) ) noted on IRC that it might > >be the cause of the problems since I have a similar controller, though > >not exactly the same one, but it didn't fix the timeouts for me. > > >For this server I have 3 disks in a graid3 (so no ZFS but the errors > >are similar to what I have seen / heard about wrt. ZFS + ata use) and > >I get timeouts several times a day which causes FreeBSD to loose > >contact with one or more disks where I have to reboot before things > >recover (usually FreeBSD panic's enough so the system reboots by > >itself). > > I'm certain that the issue with this card isn't limited to ZFS. It's > been seen before in the 6.x series too. > > I really would like to find out which code changes ruined the card's > correct operation... if that could help the ata maintainer in some way. > Unfortunately my csup-fu isn't that strong, otherwise I would send my > source tree back to June 15th and analyse daily buildworlds from that > date until I could pin-point the exact date and file changes that caused > the problem all of us are seeing. I have problems with this card in -CURRENT too. Details can be found here: http://lists.freebsd.org/pipermail/freebsd-current/2007-July/074960.html I never bothered trying with earlier versions of -CURRENT, but it works good in 6.2. -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 10:05:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3907D16A417 for ; Mon, 13 Aug 2007 10:05:11 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238]) by mx1.freebsd.org (Postfix) with ESMTP id E991313C46B for ; Mon, 13 Aug 2007 10:05:10 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1009576wxd for ; Mon, 13 Aug 2007 03:05:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fbRhDg/OX0IPDnUP0aI/agJkJFrHTehElbu6FiqekzNelqzexlJ5pCbaJiBo9SGzp7H9gCJKpBODZAHMELxOcfaKCokwIjqdTQ5qk0uFBvIKOoN9bxXaHrDGxxBMHwIZ0CtOfRU15AoZpPFM3o8Vix/rrWkGwTxYg7f7xMDT7j0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SjAg+QuWrOuranQNxngqxazy5XFWS5JhSSFQvVOX+mAxsJWStw7VqnN/TkMZ0QUuDIsYUvRuPKZMncXV6na/XU2NntJZ3wxQ32rV+xkZsw1aG6jdTrysyHe6A86Of+iBfvcxRyKqb1D88YGDeNpMDr0IC8OMiaCzgMizkgn26mY= Received: by 10.70.109.12 with SMTP id h12mr10012542wxc.1186999510138; Mon, 13 Aug 2007 03:05:10 -0700 (PDT) Received: by 10.70.109.20 with HTTP; Mon, 13 Aug 2007 03:05:10 -0700 (PDT) Message-ID: Date: Mon, 13 Aug 2007 12:05:10 +0200 From: "Claus Guttesen" To: freebsd-current@freebsd.org In-Reply-To: <20070813070530.GT93381@obelix.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070813055415.GM93381@obelix.dsto.defence.gov.au> <790a9fff0708122350w729761d1v72e6aaff414d3756@mail.gmail.com> <20070813070530.GT93381@obelix.dsto.defence.gov.au> Subject: Re: ZVOL/ZFS hosting UFS filesystems ... ERROR! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 10:05:11 -0000 > >> "Can't stat /dev/zvol/data_dg/export/ufs > >> Unknown error; help! > >> ERROR: ABORTING BOOT (sending SIGTERM to parent)!" > >> > >> And I drop into single user mode. > >> > >> The line causing this in fstab(5) is: > >> > >> /dev/zvol/data_dg/export/ufs /export/mod ufs rw,acls 1 1 > >> > >> Can anyone recommend how I can get around this ? > >> I added an entry like this to root's crontab, not the best place to put it, but I put a comment in fstab. @reboot /sbin/mount /dev/zvol/disk1/home/ufs /home/ufs -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 10:33:41 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CBC816A420 for ; Mon, 13 Aug 2007 10:33:41 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by mx1.freebsd.org (Postfix) with ESMTP id B8B9013C45D for ; Mon, 13 Aug 2007 10:33:40 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.20] (helo=mx10.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.68-dev) (envelope-from ) id 1IKXEt-0006Qk-2B; Mon, 13 Aug 2007 12:33:35 +0200 Received: from ra196.r.pppool.de ([89.54.161.150]:63522 helo=peedub.jennejohn.org) by mx10.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.68-dev #12) id 1IKXEs-0003Ah-HC; Mon, 13 Aug 2007 12:33:34 +0200 Date: Mon, 13 Aug 2007 12:33:32 +0200 From: Gary Jennejohn To: "Wilkinson, Alex" Message-Id: <20070813123332.bd6dba7b.gary.jennejohn@freenet.de> In-Reply-To: <20070813070530.GT93381@obelix.dsto.defence.gov.au> References: <20070813055415.GM93381@obelix.dsto.defence.gov.au> <790a9fff0708122350w729761d1v72e6aaff414d3756@mail.gmail.com> <20070813070530.GT93381@obelix.dsto.defence.gov.au> Organization: DENX Softwre Engineering GmbH X-Mailer: Sylpheed 2.4.4 (GTK+ 2.10.13; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ZVOL/ZFS hosting UFS filesystems ... ERROR! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 10:33:41 -0000 On Mon, 13 Aug 2007 15:05:30 +0800 "Wilkinson, Alex" wrote: > 0n Mon, Aug 13, 2007 at 01:50:32AM -0500, Scot Hetzel wrote: > > >On 8/13/07, Wilkinson, Alex wrote: > >> Currently when boostrapping I get the following error: > >> > >> "Can't stat /dev/zvol/data_dg/export/ufs > >> Unknown error; help! > >> ERROR: ABORTING BOOT (sending SIGTERM to parent)!" > >> > >> And I drop into single user mode. > >> > >> The line causing this in fstab(5) is: > >> > >> /dev/zvol/data_dg/export/ufs /export/mod ufs rw,acls 1 1 > >> > >> Can anyone recommend how I can get around this ? > >> > >Try using: > > > > /dev/zvol/data_dg/export/ufs /export/mod ufs rw,acls,late 1 1 > > > >I had a similar problem, except I was mounting UFS filesystems > >(/dev/ad0s2d) on to a mount point that was in a ZFS filesystem. When > >I added the 'late' option, I nolonger saw messages that the mount > >point didn't exist. > > Unfortuneately the 'late' option does not help. Exact same problem as I have > described above with 'late' included in fstab(5). :-( > > I am dropped into single user mode, then I have to: > > #/etc/rc.d/hostid start > #/etc/rc.d/zfs start > #mount /export/mod > #^D > > And THEN all is good. OR set "noauto" in fstab(5) for /export/mod > > :-( > Add this line to /boot/loader.conf (if it's already there then I can't help you): zfs_load="YES" --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 07:15:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B86A016A418 for ; Mon, 13 Aug 2007 07:15:40 +0000 (UTC) (envelope-from lists@billsf.net) Received: from curacao.billsf.net (billsf.net [213.130.164.21]) by mx1.freebsd.org (Postfix) with ESMTP id 7CF3713C46E for ; Mon, 13 Aug 2007 07:15:39 +0000 (UTC) (envelope-from lists@billsf.net) Received: by curacao.billsf.net (Postfix, from userid 1004) id 7620829027A; Mon, 13 Aug 2007 09:15:38 +0200 (CEST) Date: Mon, 13 Aug 2007 09:15:38 +0200 From: FreeBSD Mailing Lists To: Nathan Butcher Message-ID: <20070813071538.GA2058@curacao.billsf.net> References: <46BFE620.8070906@fusiongol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46BFE620.8070906@fusiongol.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Mailman-Approved-At: Mon, 13 Aug 2007 11:21:52 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Promise SATA 300 TX4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 07:15:40 -0000 On Mon, Aug 13, 2007 at 02:03:28PM +0900, Nathan Butcher wrote: > >I tried to roll back to right before the above mentioned change > >Karsten (well, I assume it was him :-) ) noted on IRC that it might > >be the cause of the problems since I have a similar controller, though > >not exactly the same one, but it didn't fix the timeouts for me. > > >For this server I have 3 disks in a graid3 (so no ZFS but the errors > >are similar to what I have seen / heard about wrt. ZFS + ata use) and > >I get timeouts several times a day which causes FreeBSD to loose > >contact with one or more disks where I have to reboot before things > >recover (usually FreeBSD panic's enough so the system reboots by > >itself). > > I'm certain that the issue with this card isn't limited to ZFS. It's > been seen before in the 6.x series too. > > I really would like to find out which code changes ruined the card's > correct operation... if that could help the ata maintainer in some way. > Unfortunately my csup-fu isn't that strong, otherwise I would send my > source tree back to June 15th and analyse daily buildworlds from that > date until I could pin-point the exact date and file changes that caused > the problem all of us are seeing. > > Could someone teach me how to do csup rollbacks to a specific date in > the source tree? If it's not obvious already, I'd really like to squash > this bug. Nathan, This problem has gone away for me, for the most part. At one point, out of desparation, I changed a few lines in the kernel to prevent crashes. I don't have this problem with zfs, but that is on a production server using a SCSI RAID system. (v6.2-stable about a year old) According to csup(1) just add 'date=[cc]yy.mm.dd.hh.mm.ss' to your cmdline arguments. Presumably it also works in 'supfile'. Note that you must supply the full year past 2000. I'd either reserve another space or back-up your current source tree. I've only needed to backtrack once before and that was using cvsup(1). Corrupted or improperly tagged material just stays. Actually this is a feature, but offtopic. The machine I'm referring too uses an on-board nVidia N570 SATA-300 system, though the Promise cards are 100% compatible. (and preferred because the connectors are hard to reach and as a result are easy to break) Bill From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 12:31:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4FD116A418 for ; Mon, 13 Aug 2007 12:31:27 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 664C813C461 for ; Mon, 13 Aug 2007 12:31:27 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.55.99] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1IKZ4i2gS8-0002Rr; Mon, 13 Aug 2007 14:31:23 +0200 From: Max Laier Organization: FreeBSD To: Pawel Jakub Dawidek Date: Mon, 13 Aug 2007 14:31:06 +0200 User-Agent: KMail/1.9.7 References: <6eb82e0708111122g7e36b725h19ede889e4bbc9d6@mail.gmail.com> <200708112129.29751.max@love2party.net> <20070811205437.GA24731@garage.freebsd.pl> In-Reply-To: <20070811205437.GA24731@garage.freebsd.pl> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1983264.hrjkTlodga"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708131431.13088.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19hM5AdOsPV8pL5n1XbagCiXjHDKj9dUSKIKFP YNHgll18/sedRPEzz1lbLi/QGs7vypIs7Qa7gks7g4yO+OM4X9 b60EO/bqGLK78IjmSKQVqWh8QygWY9YPbvkWWFMjK4= Cc: freebsd-current@freebsd.org, Rong-en Fan , Kris Kennaway Subject: Re: panic: sleeping thread owns a non-sleepable lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 12:31:27 -0000 --nextPart1983264.hrjkTlodga Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 11 August 2007, Pawel Jakub Dawidek wrote: > On Sat, Aug 11, 2007 at 09:29:23PM +0200, Max Laier wrote: > > On Saturday 11 August 2007, Kris Kennaway wrote: > > > On Sun, Aug 12, 2007 at 02:22:35AM +0800, Rong-en Fan wrote: > > > > I'm running 7.0-CURRENT as of yesterday, and it's very easy > > > > to make it panic: > > > > > > > > Sleeping thread (tid 100065, pid 1066) owns a non-sleepable lock > > > > sched_switch(c50a1600,0,1,1c7a7e4,4217e5,...) at > > > > sched_switch+0x190 mi_switch(1,0) at mi_switch+0x13f > > > > sleepq_switch(c50a1600,0,c078a4e2,21b,c07e3820,...) at > > > > sleepq_switch+0x87 sleepq_wait(c07e3820,0,c0770b7e,3,0,...) at > > > > sleepq_wait+0x36 _sx_xlock_hard(c07e3820,c50a1600,0,0,0,...) at > > > > _sx_xlock_hard+0x21d > > > > fr_checknatout(f9c7a8d0,f9c7a8cc,64,c57ad900,c4de7400,...) at > > > > fr_checknatout+0x29d > > > > fr_check(c8cc4644,14,c4de7400,1,f9c7a9b4,...) at fr_check+0x9b1 > > > > fr_check_wrapper(0,f9c7a9b4,c4de7400,2,c54dab28,...) at > > > > fr_check_wrapper+0x3f > > > > pfil_run_hooks(c08057c0,f9c7aa4c,c4de7400,2,c54dab28,...) at > > > > pfil_run_hooks+0x74 ip_output(c8cc4600,0,f9c7aa10,0,0,...) at > > > > ip_output+0x913 > > > > tcp_output(cae322d0,cb277200,0,0,0,...) at tcp_output+0x1106 > > > > tcp_usr_send(c51e7318,0,cb277200,0,0,...) at tcp_usr_send+0x240 > > > > kern_sendfile(c50a1600,f9c7acfc,0,0,0,...) at > > > > kern_sendfile+0x1037 > > > > sendfile(c50a1600,f9c7acfc,20,16,f9c7ad2c,...) at sendfile+0xa8 > > > > syscall(f9c7ad38) at syscall+0x315 > > > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > > > --- syscall (393, FreeBSD ELF32, sendfile), eip =3D 0x28290bff, esp > > > > =3D 0xbfbfc6ac, ebp =3D 0xbfbfe718 --- > > > > > > What is the lock it holds, and where is it acquired? > > > > My bet is on the pfil rwlock - accquired in pfil_run_hooks and > > tcbinfo / inp mtxs from tcp_output. Nothing in the transmission path > > must use sx locks. I keep on telling that. > > It looks like a whole lot of complex code can be run with pfil rwlock > held. More complex code - harder to avoid sleeping. Is it not possible > to call ->pfil_func() without holding pfil rwlock? For example by > acquiring the lock, taking a hook, increasing its reference count so it > won't go away, dropping the lock and calling ->pfil_func() ? Won't help a bit. There are other locks on the way that would need=20 similar changes. I believe that things that hook into pfil(9) must be=20 aware that they are running in the hot transmission path. Actions that=20 can not be performed with a mutex held must be deferred to another=20 context. Note that traditional pfil(9) consumers used to run at splnet,=20 where sleeping is a bad idea as well. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1983264.hrjkTlodga Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGwE8RXyyEoT62BG0RAjEEAJ9cYzhsSPGPtxo6lWYWzi6BgK3R4QCfeMzy xF3FUNd1f8yPxqqXWAQGdKU= =W9Ca -----END PGP SIGNATURE----- --nextPart1983264.hrjkTlodga-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 13:32:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D86B816A419 for ; Mon, 13 Aug 2007 13:32:06 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 973F713C465 for ; Mon, 13 Aug 2007 13:32:06 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 2998520B1; Mon, 13 Aug 2007 15:31:58 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 95E5D208A; Mon, 13 Aug 2007 15:31:57 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 7DC0784436; Mon, 13 Aug 2007 15:31:57 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: gary.jennejohn@freenet.de References: <20070813055415.GM93381@obelix.dsto.defence.gov.au> <790a9fff0708122350w729761d1v72e6aaff414d3756@mail.gmail.com> <20070813070530.GT93381@obelix.dsto.defence.gov.au> <20070813123332.bd6dba7b.gary.jennejohn@freenet.de> Date: Mon, 13 Aug 2007 15:31:57 +0200 In-Reply-To: <20070813123332.bd6dba7b.gary.jennejohn@freenet.de> (Gary Jennejohn's message of "Mon\, 13 Aug 2007 12\:33\:32 +0200") Message-ID: <861we75zn6.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, "Wilkinson, Alex" Subject: Re: ZVOL/ZFS hosting UFS filesystems ... ERROR! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 13:32:06 -0000 Gary Jennejohn writes: > "Wilkinson, Alex" writes: > > Unfortuneately the 'late' option does not help. Exact same problem as I= have > > described above with 'late' included in fstab(5). :-( > Add this line to /boot/loader.conf (if it's already there then I can't he= lp you): > > zfs_load=3D"YES" That won't make any difference. All he needs is zfs_enable=3D"YES" in /etc/rc.conf, and to mark the affected filesystems "late". Alex, make sure you're up to date with mergemaster etc. Try running 'rcorder /etc/rc.d/*' and check that zfs (which should be between mountcritlocal and FILESYSTEMS) comes before mountlate (which should be somewhere between DAEMON and LOGIN). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 13:35:00 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D305D16A417 for ; Mon, 13 Aug 2007 13:35:00 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id 5A61B13C45D for ; Mon, 13 Aug 2007 13:34:59 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so514418nfb for ; Mon, 13 Aug 2007 06:34:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HhQOJ1NmFT5ptb8YZsU3VtCbv2l2V+HeVaB9atBm9fwqLlsADMYuprCBrtXtdJ27vDkm0js7VS6rSsB8oW1hc01A9EiyEAWX5KJ82IpvyVxJ1uVMNyxD+ZFwYpeWyTZxSxjHPqEcEhZmzpxBRUpUDtm2ssyTEox4YVaaYlXni98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jAkNio7ootg26T3iYB/R1NAMUjVghgOH6AzGMUW2FnIHVN2xO/0auoX0x+P0FWsLozo8Ldpzfy+6PXmkrwEE/WKl/aYU8cYUsfJnUQcmsHokWbd6c24ENSsD6EJqbaMvSCtdpM6Xp5fMFh62NUhd6w0UnVous0zPwJZO9NgLJh4= Received: by 10.86.51.2 with SMTP id y2mr4745088fgy.1187012098473; Mon, 13 Aug 2007 06:34:58 -0700 (PDT) Received: by 10.86.59.6 with HTTP; Mon, 13 Aug 2007 06:34:58 -0700 (PDT) Message-ID: <790a9fff0708130634k18411f00ld6aa47b6bfb2a54b@mail.gmail.com> Date: Mon, 13 Aug 2007 08:34:58 -0500 From: "Scot Hetzel" To: gary.jennejohn@freenet.de In-Reply-To: <20070813123332.bd6dba7b.gary.jennejohn@freenet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070813055415.GM93381@obelix.dsto.defence.gov.au> <790a9fff0708122350w729761d1v72e6aaff414d3756@mail.gmail.com> <20070813070530.GT93381@obelix.dsto.defence.gov.au> <20070813123332.bd6dba7b.gary.jennejohn@freenet.de> Cc: freebsd-current@freebsd.org, "Wilkinson, Alex" Subject: Re: ZVOL/ZFS hosting UFS filesystems ... ERROR! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 13:35:00 -0000 On 8/13/07, Gary Jennejohn wrote: > On Mon, 13 Aug 2007 15:05:30 +0800 > "Wilkinson, Alex" wrote: > > > 0n Mon, Aug 13, 2007 at 01:50:32AM -0500, Scot Hetzel wrote: > > > > >On 8/13/07, Wilkinson, Alex > wrote: > > >> Currently when boostrapping I get the following error: > > >> > > >> "Can't stat /dev/zvol/data_dg/export/ufs > > >> Unknown error; help! > > >> ERROR: ABORTING BOOT (sending SIGTERM to parent)!" > > >> > > >> And I drop into single user mode. > > >> > > >> The line causing this in fstab(5) is: > > >> > > >> /dev/zvol/data_dg/export/ufs /export/mod ufs rw,acls 1 1 > > >> > > >> Can anyone recommend how I can get around this ? > > >> > > >Try using: > > > > > > /dev/zvol/data_dg/export/ufs /export/mod ufs rw,acls,late 1 1 > > > > > >I had a similar problem, except I was mounting UFS filesystems > > >(/dev/ad0s2d) on to a mount point that was in a ZFS filesystem. When > > >I added the 'late' option, I nolonger saw messages that the mount > > >point didn't exist. > > > > Unfortuneately the 'late' option does not help. Exact same problem as I > have > > described above with 'late' included in fstab(5). :-( > > > > I am dropped into single user mode, then I have to: > > > > #/etc/rc.d/hostid start > > #/etc/rc.d/zfs start > > #mount /export/mod > > #^D > > > > And THEN all is good. OR set "noauto" in fstab(5) for /export/mod > > > > :-( > > > > Add this line to /boot/loader.conf (if it's already there then I can't help > you): > > zfs_load="YES" > If this doesn't work add the following to /etc/rc.d/zfs start_main so that it will mount the zfs volumes after the module has been loaded: # Mount ZVOLs with property org.freebsd:late=on. zfs list -H -o org.freebsd:late,name -t volume | \ while read state name; do case "${state}" in [oO][nN]) mount /dev/zvol/${name} ;; esac done Edit /etc/fstab to add noauto to each ZVOLs, and then add the "org.freebsd:late" attribute to each ZVOLs: zfs set org.freebsd:late=on data_dg/export/ufs Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 13:45:44 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFC6916A420 for ; Mon, 13 Aug 2007 13:45:44 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1C6D613C4A7 for ; Mon, 13 Aug 2007 13:45:43 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l7DDYmMf005751 for ; Mon, 13 Aug 2007 23:04:48 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Mon, 13 Aug 2007 23:15:36 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 23:15:36 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.1/8.14.1) with ESMTP id l7DDidhb000216 for ; Mon, 13 Aug 2007 21:44:39 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.1/8.14.1/Submit) id l7DDidOK000215 for freebsd-current@freebsd.org; Mon, 13 Aug 2007 21:44:39 +0800 (WST) (envelope-from wilkinsa) Date: Mon, 13 Aug 2007 21:44:39 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20070813134439.GX93381@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20070813055415.GM93381@obelix.dsto.defence.gov.au> <790a9fff0708122350w729761d1v72e6aaff414d3756@mail.gmail.com> <20070813070530.GT93381@obelix.dsto.defence.gov.au> <20070813123332.bd6dba7b.gary.jennejohn@freenet.de> <861we75zn6.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <861we75zn6.fsf@ds4.des.no> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 13 Aug 2007 13:45:36.0552 (UTC) FILETIME=[3A4DFA80:01C7DDB0] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.0.1021-15354.001 X-TM-AS-Result: No--3.308900-0.000000-2 Content-Transfer-Encoding: 7bit Subject: Re: ZVOL/ZFS hosting UFS filesystems ... ERROR! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 13:45:44 -0000 0n Mon, Aug 13, 2007 at 03:31:57PM +0200, Dag-Erling Smrgrav wrote: >Gary Jennejohn writes: >> "Wilkinson, Alex" writes: >> > Unfortuneately the 'late' option does not help. Exact same problem as I have >> > described above with 'late' included in fstab(5). :-( >> Add this line to /boot/loader.conf (if it's already there then I can't help you): >> >> zfs_load="YES" > >That won't make any difference. All he needs is zfs_enable="YES" in >/etc/rc.conf, and to mark the affected filesystems "late". > >Alex, make sure you're up to date with mergemaster etc. Try running >'rcorder /etc/rc.d/*' and check that zfs (which should be between >mountcritlocal and FILESYSTEMS) comes before mountlate (which should be >somewhere between DAEMON and LOGIN). mmm ... zfs is in the correct place, however, mountlate is sitting between: /etc/rc.d/motd /etc/rc.d/mountlate /etc/rc.d/ntpd However, having said that, /etc/rc.d/zfs is before /etc/rc.d/mountlate. Suggestions ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 13:51:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 129C116A4AC for ; Mon, 13 Aug 2007 13:51:23 +0000 (UTC) (envelope-from takeharu1219@ybb.ne.jp) Received: from ybbsmtp07.mail.ogk.yahoo.co.jp (ybbsmtp07.mail.ogk.yahoo.co.jp [124.83.153.127]) by mx1.freebsd.org (Postfix) with SMTP id F0F0613C458 for ; Mon, 13 Aug 2007 13:51:20 +0000 (UTC) (envelope-from takeharu1219@ybb.ne.jp) Received: (qmail 14564 invoked by alias); 13 Aug 2007 13:51:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ybb20050223; d=ybb.ne.jp; b=afJJXqB881cvIYj8C/71LURwdWX6RHO8n5MwhzQ2AaO5bqjoYPXgBUwwoL998V3mFRsVsVSUmK25zAgvXPF662KZv/UY2Zfw5b1iC7Lfc0T3AbW53Yr+S6fOLbYwGNxR ; Received: from unknown (HELO ?127.0.0.1?) (takeharu1219@219.35.170.86 with plain) by ybbsmtp07.mail.ogk.yahoo.co.jp with SMTP; 13 Aug 2007 13:51:19 -0000 X-Apparently-From: Message-ID: <46C061CC.2040300@ybb.ne.jp> Date: Mon, 13 Aug 2007 22:51:08 +0900 From: Takeharu KATO User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> <86tzuxni1b.fsf@dwp.des.no> <200707061723.l66HNYSe037055@lava.sentex.ca> <86ir86hqhc.fsf@ds4.des.no> <200707262035.l6QKZtnd067391@lava.sentex.ca> <86abtihk6h.fsf@ds4.des.no> <200707262338.l6QNcL1T068284@lava.sentex.ca> <86hcnq900e.fsf@ds4.des.no> <200707270038.l6R0cLNV068524@lava.sentex.ca> <8664462p1b.fsf@ds4.des.no> <200707271037.l6RAbc2Q071412@lava.sentex.ca> <86fy2v2x9e.fsf@ds4.des.no> <200708071529.l77FTpsO040934@lava.sentex.ca> <46C00EB4.1030707@ybb.ne.jp> <86y7gf6ddw.fsf@ds4.des.no> In-Reply-To: <86y7gf6ddw.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Mike Tancsa Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 13:51:23 -0000 Hi, > if (rc) > device_printf(sc->device, > "ICH WDT present but disabled in BIOS or hardware\n"); > > DES Certainly, your patch show this result, sorry. But I want to know operation of reset bit operation. BTW, why do you use ich version number to switch WDT operation (In particular, NOREBOOT operation)? As far as I think, it is more preferable to use TCO version instead of ich version number to this purpose. Because 6300ESB is a kind of ICH5 with TCO version 2, isn't it? Regards, From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 13:54:47 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0A2316A41A for ; Mon, 13 Aug 2007 13:54:47 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 9C2CB13C4A8 for ; Mon, 13 Aug 2007 13:54:47 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost.egr.msu.edu [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 061E22EB966 for ; Mon, 13 Aug 2007 09:36:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeOxkv6Sq6cW for ; Mon, 13 Aug 2007 09:36:53 -0400 (EDT) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id A13092EB95E for ; Mon, 13 Aug 2007 09:36:53 -0400 (EDT) Received: by localhost (Postfix, from userid 21281) id 8C9B533C22; Mon, 13 Aug 2007 09:36:53 -0400 (EDT) Date: Mon, 13 Aug 2007 09:36:53 -0400 From: Adam McDougall To: freebsd-current@freebsd.org Message-ID: <20070813133653.GC1188@egr.msu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Subject: GEOM Journal vanished, module is loaded, might be my fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 13:54:47 -0000 Recently I did a new install of -current on my workstation. I added a 190782MB that was formatted in a 6.x computer, created a journaled UFS partition on it following the first example in the manpage, mounted it and copied data in. At the time I had manually compiled and installed the geom_journal kernel module. Last night I decided to csup to -current and upgrade my system. I did so and found that fsck had failed due to a missing /dev/ad2s1.journal. I discovered I had forgotten to compile, install, and load the geom_journal automatically, but after fixing make.conf, loader.conf, and installing and loading geom_journal, no journal devices were detected still. I know it used to exist, according to logs, my memory, and fstab: /dev/ad2s1.journal /data4 ufs rw,noauto,async 2 2 Aug 6 15:41:13 daemon kernel: GEOM_JOURNAL: Journal 2704801608: ad2s1 contains data. Aug 6 15:41:13 daemon kernel: GEOM_JOURNAL: Journal 2704801608: ad2s1 contains journal. Aug 6 15:41:13 daemon kernel: GEOM_JOURNAL: Journal ad2s1 clean. Aug 6 16:07:53 daemon kernel: /data4: optimization changed from TIME to SPACE and I've done this before successfully. I had not otherwise rebooted since creating this journal. I tried booting the old kernel, still did not detect, I tried booting with kern.geom.journal.debug=1 and geom_journal_load="YES" ( 9 1 0xc0f91000 14a54 geom_journal.ko) and the kernel made no reference to ad2 in the bootup of the most recent kernel other than detecting the drive itself. All I see in /dev from /dev/ad2* is: crw-r----- 1 root operator 0, 85 Aug 13 08:41 /dev/ad2 If I recall correctly, I had some difficulty when creating it, something must have been strange with the partitioning because it was angry and while debugging/fixing kept flipping between ad2s1 and ad2s1c as I attempted to get the journal to detect and function properly on the right device (using gjournal stop,etc): Aug 6 15:35:10 daemon kernel: GEOM_JOURNAL: Journal 4249488822: ad2s1 contains data. Aug 6 15:35:10 daemon kernel: GEOM_JOURNAL: Journal 4249488822: ad2s1 contains journal. Aug 6 15:35:10 daemon kernel: GEOM_JOURNAL: Journal ad2s1 clean. Aug 6 15:35:10 daemon kernel: WARNING: Expected rawoffset 0, found 63 Aug 6 15:38:25 daemon kernel: WARNING: Expected rawoffset 0, found 63 Aug 6 15:38:47 daemon kernel: WARNING: Expected rawoffset 0, found 63 Aug 6 15:38:59 daemon kernel: GEOM_JOURNAL: Journal 4249488822: ad2s1c contains data. Aug 6 15:38:59 daemon kernel: GEOM_JOURNAL: Journal 4249488822: ad2s1c contains journal. Aug 6 15:38:59 daemon kernel: GEOM_JOURNAL: Journal ad2s1c clean. Aug 6 15:38:59 daemon kernel: WARNING: Expected rawoffset 0, found 63 Aug 6 15:39:36 daemon kernel: GEOM_JOURNAL: Journal 4249488822: ad2s1 contains data. Aug 6 15:39:36 daemon kernel: GEOM_JOURNAL: Journal 4249488822: ad2s1 contains journal. Aug 6 15:39:36 daemon kernel: GEOM_JOURNAL: Journal ad2s1 clean. Aug 6 15:39:36 daemon kernel: WARNING: Expected rawoffset 0, found 63 Aug 6 15:39:48 daemon kernel: GEOM_JOURNAL: Journal 4249488822: ad2s1c contains data. Aug 6 15:39:48 daemon kernel: GEOM_JOURNAL: Journal 4249488822: ad2s1c contains journal. Aug 6 15:39:48 daemon kernel: GEOM_JOURNAL: Journal ad2s1c clean. Aug 6 15:39:48 daemon kernel: WARNING: Expected rawoffset 0, found 63 Aug 6 15:40:30 daemon kernel: GEOM_JOURNAL: Journal 4249488822: ad2s1 contains data. Aug 6 15:40:30 daemon kernel: GEOM_JOURNAL: Journal 4249488822: ad2s1 contains journal. Aug 6 15:40:30 daemon kernel: GEOM_JOURNAL: Journal ad2s1 clean. I gave up on that situation on Aug 6 and I believe I used dd to zero out the first meg of the disk, partitioned, and got a stable working journal setup without unusual fuss. I'm pretty sure I have a backup of the data still, and it is of low importance, but how can I figure out what happened and/or how to fix it? I'm not going to poke around with it pending advice. Maybe I managed to label and use a partition that the kernel previously detected, but wasn't actually created on disk? Thanks for any help. % fdisk ad2 ******* Working on device /dev/ad2 ******* parameters extracted from in-core disklabel are: cylinders=387621 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=387621 heads=16 sectors/track=63 (1008 blks/cyl) fdisk: invalid fdisk partition table found Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 390721905 (190782 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 548/ head 15/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 14:44:17 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97D4B16A419 for ; Mon, 13 Aug 2007 14:44:17 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 512FD13C4D1 for ; Mon, 13 Aug 2007 14:44:17 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 8510C20B4; Mon, 13 Aug 2007 16:44:02 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 7534E20B3; Mon, 13 Aug 2007 16:44:02 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 5C91A8444F; Mon, 13 Aug 2007 16:44:02 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Takeharu KATO References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> <4633932A.8080602@ybb.ne.jp> <86tzuxni1b.fsf@dwp.des.no> <200707061723.l66HNYSe037055@lava.sentex.ca> <86ir86hqhc.fsf@ds4.des.no> <200707262035.l6QKZtnd067391@lava.sentex.ca> <86abtihk6h.fsf@ds4.des.no> <200707262338.l6QNcL1T068284@lava.sentex.ca> <86hcnq900e.fsf@ds4.des.no> <200707270038.l6R0cLNV068524@lava.sentex.ca> <8664462p1b.fsf@ds4.des.no> <200707271037.l6RAbc2Q071412@lava.sentex.ca> <86fy2v2x9e.fsf@ds4.des.no> <200708071529.l77FTpsO040934@lava.sentex.ca> <46C00EB4.1030707@ybb.ne.jp> <86y7gf6ddw.fsf@ds4.des.no> <46C061CC.2040300@ybb.ne.jp> Date: Mon, 13 Aug 2007 16:44:02 +0200 In-Reply-To: <46C061CC.2040300@ybb.ne.jp> (Takeharu KATO's message of "Mon\, 13 Aug 2007 22\:51\:08 +0900") Message-ID: <86r6m74hql.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Mike Tancsa Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 14:44:17 -0000 Takeharu KATO writes: > BTW, why do you use ich version number to switch WDT operation > (In particular, NOREBOOT operation)? > As far as I think, it is more preferable to use TCO version instead of > ich version number to this purpose. There was nothing in the documentation about a "TCO version", and I didn't want to use arbitrary numbers (1 and 2). It would probably have been better to simply use an enum. > Because 6300ESB is a kind of ICH5 with TCO version 2, isn't it? It's an ICH5-equivalent chipset for mobile and embedded systems, and it has what you would call "TCO version 1" (8-bit TCO_TMR at TCOBASE+01H): http://www.intel.com/design/intarch/datashts/30064103.pdf DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 15:04:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 834E716A421 for ; Mon, 13 Aug 2007 15:04:29 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3FE6413C4A8 for ; Mon, 13 Aug 2007 15:04:29 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 61F5B20B0 for ; Mon, 13 Aug 2007 17:04:19 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 4A4BE208A for ; Mon, 13 Aug 2007 17:04:19 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 2DEF78444F; Mon, 13 Aug 2007 17:04:19 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: freebsd-current@freebsd.org References: <20070813055415.GM93381@obelix.dsto.defence.gov.au> <790a9fff0708122350w729761d1v72e6aaff414d3756@mail.gmail.com> <20070813070530.GT93381@obelix.dsto.defence.gov.au> <20070813123332.bd6dba7b.gary.jennejohn@freenet.de> <861we75zn6.fsf@ds4.des.no> <20070813134439.GX93381@obelix.dsto.defence.gov.au> Date: Mon, 13 Aug 2007 17:04:19 +0200 In-Reply-To: <20070813134439.GX93381@obelix.dsto.defence.gov.au> (Alex Wilkinson's message of "Mon\, 13 Aug 2007 21\:44\:39 +0800") Message-ID: <86hcn34gss.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: ZVOL/ZFS hosting UFS filesystems ... ERROR! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 15:04:29 -0000 "Wilkinson, Alex" writes: > Dag-Erling Smrgrav writes: > > Alex, make sure you're up to date with mergemaster etc. Try running > > 'rcorder /etc/rc.d/*' and check that zfs (which should be between > > mountcritlocal and FILESYSTEMS) comes before mountlate (which should be > > somewhere between DAEMON and LOGIN). > > mmm ... zfs is in the correct place, however, mountlate is sitting betwee= n: > > /etc/rc.d/motd > /etc/rc.d/mountlate > /etc/rc.d/ntpd Yes. DAEMON comes before that, and LOGIN comes after, so mountlate is "somewhere between DAEMON and LOGIN" as I wrote. > However, having said that, /etc/rc.d/zfs is before /etc/rc.d/mountlate. so everything is fine? > Suggestions ? If it still doesn't work, I'll need to see the full console output from the point where init(8) starts until the point where getty(8) starts. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 15:06:03 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89AF016A478 for ; Mon, 13 Aug 2007 15:06:03 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 443FC13C4A7 for ; Mon, 13 Aug 2007 15:06:03 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 51B8820B0; Mon, 13 Aug 2007 17:05:59 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 43017208A; Mon, 13 Aug 2007 17:05:59 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 29A8A8444F; Mon, 13 Aug 2007 17:05:59 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Scot Hetzel" References: <20070813055415.GM93381@obelix.dsto.defence.gov.au> <790a9fff0708122350w729761d1v72e6aaff414d3756@mail.gmail.com> <20070813070530.GT93381@obelix.dsto.defence.gov.au> <20070813123332.bd6dba7b.gary.jennejohn@freenet.de> <790a9fff0708130634k18411f00ld6aa47b6bfb2a54b@mail.gmail.com> Date: Mon, 13 Aug 2007 17:05:59 +0200 In-Reply-To: <790a9fff0708130634k18411f00ld6aa47b6bfb2a54b@mail.gmail.com> (Scot Hetzel's message of "Mon\, 13 Aug 2007 08\:34\:58 -0500") Message-ID: <86d4xr4gq0.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, "Wilkinson, Alex" Subject: Re: ZVOL/ZFS hosting UFS filesystems ... ERROR! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 15:06:03 -0000 "Scot Hetzel" writes: > If this doesn't work add the following to /etc/rc.d/zfs start_main so > that it will mount the zfs volumes after the module has been loaded: This is a completely wrong solution. Not only will he have to maintain those changes through uncounted mergemaster iterations, but we'll never find out what's actually wrong with his system. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 17:23:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE5A416A419 for ; Mon, 13 Aug 2007 17:23:40 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 4E1CE13C46E for ; Mon, 13 Aug 2007 17:23:40 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4462D487F4; Mon, 13 Aug 2007 19:23:39 +0200 (CEST) Received: from localhost (public-gprs36066.centertel.pl [91.94.12.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id B1A2945B26; Mon, 13 Aug 2007 19:23:25 +0200 (CEST) Date: Mon, 13 Aug 2007 19:22:25 +0200 From: Pawel Jakub Dawidek To: Max Laier Message-ID: <20070813172225.GB8819@garage.freebsd.pl> References: <6eb82e0708111122g7e36b725h19ede889e4bbc9d6@mail.gmail.com> <200708112129.29751.max@love2party.net> <20070811205437.GA24731@garage.freebsd.pl> <200708131431.13088.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zx4FCpZtqtKETZ7O" Content-Disposition: inline In-Reply-To: <200708131431.13088.max@love2party.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: freebsd-current@freebsd.org, Rong-en Fan , Kris Kennaway Subject: Re: panic: sleeping thread owns a non-sleepable lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 17:23:40 -0000 --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 13, 2007 at 02:31:06PM +0200, Max Laier wrote: > > It looks like a whole lot of complex code can be run with pfil rwlock > > held. More complex code - harder to avoid sleeping. Is it not possible > > to call ->pfil_func() without holding pfil rwlock? For example by > > acquiring the lock, taking a hook, increasing its reference count so it > > won't go away, dropping the lock and calling ->pfil_func() ? >=20 > Won't help a bit. There are other locks on the way that would need=20 > similar changes. I believe that things that hook into pfil(9) must be=20 > aware that they are running in the hot transmission path. Actions that= =20 > can not be performed with a mutex held must be deferred to another=20 > context. Note that traditional pfil(9) consumers used to run at splnet,= =20 > where sleeping is a bad idea as well. After I send that e-mail, I realized that sleeping with read lock should be ok. When we acquire read lock and sleep, other readers can also acquire it and when we need write lock, we don't operate in fast path (I assume we need write lock when we register/deregister hook mostly). In other words we could change pfil lock from rwlock(9) to sx(9). In this very case posted in the begining of the thread I see nothing wrong in thread sleeping in sendfile(2), because it won't affect other processes. BUT if as you said there are other locks in the way, my idea doesn't apply. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --zx4FCpZtqtKETZ7O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGwJNRForvXbEpPzQRAvAbAKCV48ah9iTZg54dfe5mHJ7rGKRmUACg24u+ R1vxtog9kxSohYvGbI0dhLc= =R8LI -----END PGP SIGNATURE----- --zx4FCpZtqtKETZ7O-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 17:28:16 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C187B16A417 for ; Mon, 13 Aug 2007 17:28:16 +0000 (UTC) (envelope-from wildes@itecgyn.com.br) Received: from correio.itecgyn.com.br (201.22.164.121.static.gvt.net.br [201.22.164.121]) by mx1.freebsd.org (Postfix) with ESMTP id 964E913C465 for ; Mon, 13 Aug 2007 17:28:14 +0000 (UTC) (envelope-from wildes@itecgyn.com.br) Received: from localhost (localhost.itecgyn.com.br [127.0.0.1]) by correio.itecgyn.com.br (Postfix) with ESMTP id C215D115C6 for ; Mon, 13 Aug 2007 14:15:36 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 13 Aug 2007 14:15:36 +0000 From: Wildes Miranda de Oliveira To: freebsd-current@freebsd.org Organization: Itecgyn Informatica ME In-Reply-To: <903f4bc2118c595b4baf82815ea99ca6@localhost> References: <903f4bc2118c595b4baf82815ea99ca6@localhost> Message-ID: <044112fd226062ed9e5d4ac73ecd1337@localhost> X-Sender: wildes@itecgyn.com.br User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: Cant load Marvell Yukon network interface with acpi enabled andAtherosAR5005 with acpi disabled. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gowmo@itecgyn.com.br List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 17:28:16 -0000 can anyone help me ? thanks. On Mon, 6 Aug 2007 22:03:46 +0000, Wildes Miranda de Oliveira wrote: >> hi list, >> >> excuse-me my poorly english. >> >> recently i bought one notebook acer aspire 3680, and i have had problems >> for load network interfaces on them. >> the problem is that the interface ethernet Marvell Yukon don't load with >> acpi enabled, and the interface >> wireless Atheros AR5005 don't load with acpi disabled, with this it´s >> never load on same bootstrap. >> i'm annexing informations about dmesg with acpi enabled/disabled , >> acpidump and pciconf -lv. >> >> i wish ask you about tunning of acpi described in man page. could this >> solve my problem ? >> >> LOADER TUNABLES >> Tunables can be set at the loader(8) prompt before booting the > kernel >> or >> stored in /boot/loader.conf. Many of these tunables also have a >> matching >> >> hw.acpi.serialize_methods >> >> Allow override of whether methods execute in parallel or > not. >> Enable this for serial behavior, which fixes >> "AE_ALREADY_EXISTS" >> errors for AML that really cannot handle parallel method >> execu- >> tion. It is off by default since this breaks recursive >> methods >> and some IBMs use such code. >> >> hw.pci.link.%s.%d.irq >> >> Override the interrupt to use for this link and index. > This >> capability should be used carefully, and only if a device > is >> not >> working with acpi enabled. "%s" is the name of the link >> (e.g., >> LNKA). "%d" is the resource index when the link supports >> multi- >> ple IRQs. Most PCI links only have one IRQ resource, so > the >> below form should be used. >> >> hw.pci.link.%s.irq >> >> Override the interrupt to use. This capability should be >> used >> carefully, and only if a device is not working with acpi >> enabled. >> "%s" is the name of the link (e.g., LNKA). >> >> #================= ACPI DISABLED > ==================================== >> >> Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. >> FreeBSD 7.0-CURRENT-200706 #0: Sun Jun 3 18:41:02 UTC 2007 >> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >> WARNING: WITNESS option enabled, expect reduced performance. >> MPTable: >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Celeron(R) M CPU 430 @ 1.73GHz (1733.41-MHz >> 686-class CPU) >> Origin = "GenuineIntel" Id = 0x6e8 Stepping = 8 >> >> > Features=0xafe9fbff >> Features2=0xc109 >> AMD Features=0x100000 >> real memory = 526974976 (502 MB) >> avail memory = 501780480 (478 MB) >> ioapic0: Assuming intbase of 0 >> ioapic0 irqs 0-23 on motherboard >> kbd1 at kbdmux0 >> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413) >> cpu0 on motherboard >> pcib0: pcibus 0 on motherboard >> pci0: on pcib0 >> vgapci0: port 0x1800-0x1807 mem >> 0xd0200000-0xd027ffff,0xc0000000-0xcfffffff,0xd0300000-0xd033ffff irq 16 > at >> device 2.0 on pci0 >> agp0: on vgapci0 >> agp0: detected 7932k stolen memory >> agp0: aperture size is 256M >> vgapci1: mem 0xd0280000-0xd02fffff at device > 2.1 >> on pci0 >> pci0: at device 27.0 (no driver attached) >> pcib1: irq 16 at device 28.0 on pci0 >> pci2: on pcib1 >> mskc0: port 0x2000-0x20ff mem >> 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 >> msk0: on mskc0 >> msk0: Ethernet address: 00:16:36:d1:56:ce >> miibus0: on msk0 >> e1000phy0: PHY 0 on miibus0 >> e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> ukphy0: PHY 3 on miibus0 >> ukphy0: no media present >> ukphy1: PHY 6 on miibus0 >> ukphy1: no media present >> mskc0: [FILTER] >> pcib2: irq 17 at device 28.1 on pci0 >> pci3: on pcib2 >> pcib3: irq 18 at device 28.2 on pci0 >> pci4: on pcib3 >> pcib4: irq 19 at device 28.3 on pci0 >> pci5: on pcib4 >> uhci0: port 0x1820-0x183f irq 23 at > device >> 29.0 on pci0 >> uhci0: [GIANT-LOCKED] >> uhci0: [ITHREAD] >> usb0: on uhci0 >> usb0: USB revision 1.0 >> uhub0: on usb0 >> uhub0: 2 ports with 2 removable, self powered >> uhci1: port 0x1840-0x185f irq 19 at > device >> 29.1 on pci0 >> uhci1: [GIANT-LOCKED] >> uhci1: [ITHREAD] >> usb1: on uhci1 >> usb1: USB revision 1.0 >> uhub1: on usb1 >> uhub1: 2 ports with 2 removable, self powered >> uhci2: port 0x1860-0x187f irq 18 at > device >> 29.2 on pci0 >> uhci2: [GIANT-LOCKED] >> uhci2: [ITHREAD] >> usb2: on uhci2 >> usb2: USB revision 1.0 >> uhub2: on usb2 >> uhub2: 2 ports with 2 removable, self powered >> uhci3: port 0x1880-0x189f irq 16 at > device >> 29.3 on pci0 >> uhci3: [GIANT-LOCKED] >> uhci3: [ITHREAD] >> usb3: on uhci3 >> usb3: USB revision 1.0 >> uhub3: on usb3 >> uhub3: 2 ports with 2 removable, self powered >> ehci0: mem >> 0xd0544000-0xd05443ff irq 23 at device 29.7 on pci0 >> ehci0: [GIANT-LOCKED] >> ehci0: [ITHREAD] >> usb4: EHCI version 1.0 >> usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 >> usb4: on ehci0 >> usb4: USB revision 2.0 >> uhub4: on usb4 >> uhub4: 8 ports with 8 removable, self powered >> pcib5: at device 30.0 on pci0 >> pci10: on pcib5 >> ath0: mem 0xd0000000-0xd000ffff at device 3.0 on pci10 >> pcib5: unable to route slot 3 INTA >> ath0: could not map interrupt >> device_attach: ath0 attach returned 6 >> cbb0: mem 0xd0014000-0xd0014fff irq 20 at device > 9.0 >> on pci10 >> cardbus0: on cbb0 >> pccard0: <16-bit PCCard bus> on cbb0 >> cbb0: [ITHREAD] >> pci10: at device 9.2 (no driver attached) >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18b0-0x18bf at device 31.2 on pci0 >> ata0: on atapci0 >> ata0: [ITHREAD] >> ata1: on atapci0 >> ata1: [ITHREAD] >> pci0: at device 31.3 (no driver attached) >> pmtimer0 on isa0 >> orm0: at iomem 0xcf000-0xcffff,0xdf800-0xdffff pnpid >> ORM0000 on isa0 >> atkbdc0: at port 0x60,0x64 on isa0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> psm0: irq 12 on atkbdc0 >> psm0: [GIANT-LOCKED] >> psm0: [ITHREAD] >> psm0: model Generic PS/2 mouse, device ID 0 >> ppc0: parallel port not found. >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> sio0: configured irq 4 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> sio0: configured irq 4 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 >> sio0: type 8250 or not responding >> sio0: [FILTER] >> sio1: configured irq 3 not in bitmap of probed irqs 0 >> sio1: port may not be enabled >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 >> unknown: can't assign resources (memory) >> unknown: can't assign resources (port) >> unknown: can't assign resources (memory) >> unknown: can't assign resources (memory) >> unknown: can't assign resources (memory) >> unknown: can't assign resources (memory) >> unknown: can't assign resources (memory) >> unknown: can't assign resources (irq) >> Timecounter "TSC" frequency 1733412980 Hz quality 800 >> Timecounters tick every 1.000 msec >> ad0: 76319MB at ata0-master SATA150 >> acd0: CDRW at ata1-master UDMA33 >> GEOM_LABEL: Label for provider ad0s3 is msdosfs/DADOS. >> Trying to mount root from ufs:/dev/ad0s1a >> msk0: link state changed to UP >> >> #====================== ACPI ENABLED > ==================================== >> >> Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. >> FreeBSD 7.0-CURRENT-200706 #0: Sun Jun 3 18:41:02 UTC 2007 >> root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >> WARNING: WITNESS option enabled, expect reduced performance. >> ACPI APIC Table: >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Celeron(R) M CPU 430 @ 1.73GHz (1733.41-MHz >> 686-class CPU) >> Origin = "GenuineIntel" Id = 0x6e8 Stepping = 8 >> >> > Features=0xafe9fbff >> Features2=0xc109 >> AMD Features=0x100000 >> real memory = 526974976 (502 MB) >> avail memory = 501760000 (478 MB) >> ioapic0 irqs 0-23 on motherboard >> kbd1 at kbdmux0 >> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413) >> acpi0: on motherboard >> acpi0: [ITHREAD] >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on >> acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 2000 >> acpi0: Power Button (fixed) >> unknown: I/O range not supported >> acpi0: reservation of fed00000, 400 (3) failed >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 >> acpi_ec0: port 0x62,0x66 on acpi0 >> cpu0: on acpi0 >> acpi_throttle0: on cpu0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> vgapci0: port 0x1800-0x1807 mem >> 0xd0200000-0xd027ffff,0xc0000000-0xcfffffff,0xd0300000-0xd033ffff irq 16 > at >> device 2.0 on pci0 >> agp0: on vgapci0 >> agp0: detected 7932k stolen memory >> agp0: aperture size is 256M >> vgapci1: mem 0xd0280000-0xd02fffff at device > 2.1 >> on pci0 >> pci0: at device 27.0 (no driver attached) >> pcib1: irq 16 at device 28.0 on pci0 >> pci2: on pcib1 >> mskc0: irq 16 at device 0.0 on >> pci2 >> mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). >> mskc0: unknown device: id=0x00, rev=0x00 >> device_attach: mskc0 attach returned 6 >> pcib2: irq 17 at device 28.1 on pci0 >> pci3: on pcib2 >> pcib3: irq 18 at device 28.2 on pci0 >> pci4: on pcib3 >> uhci0: port 0x1820-0x183f irq 23 at > device >> 29.0 on pci0 >> uhci0: [GIANT-LOCKED] >> uhci0: [ITHREAD] >> usb0: on uhci0 >> usb0: USB revision 1.0 >> uhub0: on usb0 >> uhub0: 2 ports with 2 removable, self powered >> uhci1: port 0x1840-0x185f irq 19 at > device >> 29.1 on pci0 >> uhci1: [GIANT-LOCKED] >> uhci1: [ITHREAD] >> usb1: on uhci1 >> usb1: USB revision 1.0 >> uhub1: on usb1 >> uhub1: 2 ports with 2 removable, self powered >> uhci2: port 0x1860-0x187f irq 18 at > device >> 29.2 on pci0 >> uhci2: [GIANT-LOCKED] >> uhci2: [ITHREAD] >> usb2: on uhci2 >> usb2: USB revision 1.0 >> uhub2: on usb2 >> uhub2: 2 ports with 2 removable, self powered >> uhci3: port 0x1880-0x189f irq 16 at > device >> 29.3 on pci0 >> uhci3: [GIANT-LOCKED] >> uhci3: [ITHREAD] >> usb3: on uhci3 >> usb3: USB revision 1.0 >> uhub3: on usb3 >> uhub3: 2 ports with 2 removable, self powered >> ehci0: mem >> 0xd0544000-0xd05443ff irq 23 at device 29.7 on pci0 >> ehci0: [GIANT-LOCKED] >> ehci0: [ITHREAD] >> usb4: EHCI version 1.0 >> usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 >> usb4: on ehci0 >> usb4: USB revision 2.0 >> uhub4: on usb4 >> uhub4: 8 ports with 8 removable, self powered >> pcib4: at device 30.0 on pci0 >> pci10: on pcib4 >> ath0: mem 0xd0000000-0xd000ffff at device 3.0 on pci10 >> ath0: [ITHREAD] >> ath0: using obsoleted if_watchdog interface >> ath0: Ethernet address: 00:19:7d:47:ed:84 >> ath0: mac 7.8 phy 4.5 radio 5.6 >> cbb0: mem 0xd0014000-0xd0014fff irq 20 at device > 9.0 >> on pci10 >> cardbus0: on cbb0 >> pccard0: <16-bit PCCard bus> on cbb0 >> cbb0: [ITHREAD] >> pci10: at device 9.2 (no driver attached) >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18b0-0x18bf at device 31.2 on pci0 >> ata0: on atapci0 >> ata0: [ITHREAD] >> ata1: on atapci0 >> ata1: [ITHREAD] >> pci0: at device 31.3 (no driver attached) >> acpi_acad0: on acpi0 >> battery0: on acpi0 >> acpi_lid0: on acpi0 >> acpi_button0: on acpi0 >> acpi_button1: on acpi0 >> acpi_tz0: on acpi0 >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> psm0: irq 12 on atkbdc0 >> psm0: [GIANT-LOCKED] >> psm0: [ITHREAD] >> psm0: model Generic PS/2 mouse, device ID 0 >> pmtimer0 on isa0 >> orm0: at iomem 0xcf000-0xcffff,0xdf800-0xdffff pnpid >> ORM0000 on isa0 >> ppc0: parallel port not found. >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> sio0: configured irq 4 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> sio0: configured irq 4 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 >> sio0: type 8250 or not responding >> sio0: [FILTER] >> sio1: configured irq 3 not in bitmap of probed irqs 0 >> sio1: port may not be enabled >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 >> Timecounter "TSC" frequency 1733409431 Hz quality 800 >> Timecounters tick every 1.000 msec >> ad0: 76319MB at ata0-master SATA150 >> acd0: CDRW at ata1-master UDMA33 >> GEOM_LABEL: Label for provider ad0s3 is msdosfs/DADOS. >> Trying to mount root from ufs:/dev/ad0s1a >> >> #======================== PCICONF -LV > ==================================== >> >> hostb0@pci0:0:0: class=0x060000 card=0x01101025 chip=0x27a08086 rev=0x03 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '955XM/945GM/PM/GMS/940GML Express Processor to DRAM >> Controller' >> class = bridge >> subclass = HOST-PCI >> vgapci0@pci0:2:0: class=0x030000 card=0x01101025 chip=0x27a28086 > rev=0x03 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Mobile Integrated Graphics Controller' >> class = display >> subclass = VGA >> vgapci1@pci0:2:1: class=0x038000 card=0x01101025 chip=0x27a68086 > rev=0x03 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Mobile Integrated Graphics Controller' >> class = display >> none0@pci0:27:0: class=0x040300 card=0x01101025 chip=0x27d88086 rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) High Definition Audio' >> class = multimedia >> pcib1@pci0:28:0: class=0x060400 card=0x01101025 chip=0x27d08086 rev=0x02 >> hdr=0x01 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) PCI Express Root Port' >> class = bridge >> subclass = PCI-PCI >> pcib2@pci0:28:1: class=0x060400 card=0x01101025 chip=0x27d28086 rev=0x02 >> hdr=0x01 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) PCI Express Root Port' >> class = bridge >> subclass = PCI-PCI >> pcib3@pci0:28:2: class=0x060400 card=0x01101025 chip=0x27d48086 rev=0x02 >> hdr=0x01 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) PCI Express Root Port' >> class = bridge >> subclass = PCI-PCI >> uhci0@pci0:29:0: class=0x0c0300 card=0x01101025 chip=0x27c88086 rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) USB Universal Host Controller' >> class = serial bus >> subclass = USB >> uhci1@pci0:29:1: class=0x0c0300 card=0x01101025 chip=0x27c98086 rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) USB Universal Host Controller' >> class = serial bus >> subclass = USB >> uhci2@pci0:29:2: class=0x0c0300 card=0x01101025 chip=0x27ca8086 rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) USB Universal Host Controller' >> class = serial bus >> subclass = USB >> uhci3@pci0:29:3: class=0x0c0300 card=0x01101025 chip=0x27cb8086 rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) USB Universal Host Controller' >> class = serial bus >> subclass = USB >> ehci0@pci0:29:7: class=0x0c0320 card=0x01101025 chip=0x27cc8086 rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' >> class = serial bus >> subclass = USB >> pcib4@pci0:30:0: class=0x060401 card=0x01101025 chip=0x24488086 rev=0xe2 >> hdr=0x01 >> vendor = 'Intel Corporation' >> device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI >> Bridge' >> class = bridge >> subclass = PCI-PCI >> isab0@pci0:31:0: class=0x060100 card=0x01101025 chip=0x27b98086 rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801GBM (ICH7-M) LPC Interface Controller' >> class = bridge >> subclass = PCI-ISA >> atapci0@pci0:31:2: class=0x010180 card=0x01101025 chip=0x27c48086 > rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage >> Controller' >> class = mass storage >> subclass = ATA >> none1@pci0:31:3: class=0x0c0500 card=0x01101025 chip=0x27da8086 rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82801G (ICH7 Family) SMBus Controller' >> class = serial bus >> subclass = SMBus >> mskc0@pci2:0:0: class=0x020000 card=0x01101025 chip=0x435211ab rev=0x14 >> hdr=0x00 >> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >> device = 'Yukon 88E8038 PCI-E Fast Ethernet Controller' >> class = network >> subclass = ethernet >> ath0@pci10:3:0: class=0x020000 card=0x04181468 chip=0x001a168c rev=0x01 >> hdr=0x00 >> vendor = 'Atheros Communications Inc.' >> device = 'Atheros AR5005G Atheros AR5005G 802.11abg NIC Chipset' >> class = network >> subclass = ethernet >> cbb0@pci10:9:0: class=0x060700 card=0x01101025 chip=0x8039104c rev=0x00 >> hdr=0x02 >> vendor = 'Texas Instruments (TI)' >> device = 'PCIxx12 Cardbus Controller' >> class = bridge >> subclass = PCI-CardBus >> none2@pci10:9:2: class=0x018000 card=0x01101025 chip=0x803b104c rev=0x00 >> hdr=0x00 >> vendor = 'Texas Instruments (TI)' >> device = 'PCIxx12 Integrated Flash Media Controller' >> class = mass storage From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 19:41:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8734E16A417 for ; Mon, 13 Aug 2007 19:41:50 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0C07E13C46A for ; Mon, 13 Aug 2007 19:41:49 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from [192.168.1.67] (e181027114.adsl.alicedsl.de [85.181.27.114]) (authenticated bits=0) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l7DJflvY085899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Aug 2007 21:41:48 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) X-Authentication-Warning: smtp.dmz.omnisec.de: Host e181027114.adsl.alicedsl.de [85.181.27.114] claimed to be [192.168.1.67] From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Mon, 13 Aug 2007 21:41:41 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708132141.43165.h.schmalzbauer@omnisec.de> Subject: powerd and it's "wakeup" behaviour X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 19:41:50 -0000 Hello, I'm using cpufreq (acpi_perf (800/9800 500/5900) with acpi_throttle and I have limited debug.cpufreq.lowest=250, so dev.cpu.0.freq_levels reads: 800/9800 700/8575 600/7350 500/5900 437/5162 375/4425 312/3687 250/2950 I haven't tested the saving which acpi_throttling provides, but I think I can gain some minutes over plain 800/500MHz(Vcore)switch. Now the problem is that "waking up" from 250 MHz to full speed needs too much time to be effective for short term task like displaying a PDF. Reading the file doesn't stress the CPU so powerd increases "clock" (paranthesized because clock has only two states, but throttling adds 6 steps) in 7 steps to 800MHz. I'd love to have a option which tells powerd to slowly step down, but jump to full throttle if threshold of cpu usage is reached, regardless the current clock setting. So a CPU usage peak would give full performance first, then slowly stepping down again according to the CPU usage. Even my old 800MHz P3-m is fast enough to complete "cpu hungry" tasks in a quiet short time, so slowly stepping clock up is not optimal form me because it's not that fast that comleting the task with quarter speed doesn't feel sluggish. Any thoughts? Anyone who could and want to implement such a feature? (my programming skills are far beyond...) Thanks, -Harry From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 20:40:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E254E16A41A; Mon, 13 Aug 2007 20:40:39 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from signal.itea.ntnu.no (signal.itea.ntnu.no [129.241.190.231]) by mx1.freebsd.org (Postfix) with ESMTP id 9A1B013C461; Mon, 13 Aug 2007 20:40:39 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by signal.itea.ntnu.no (Postfix) with ESMTP id A49AD34A20; Mon, 13 Aug 2007 22:40:37 +0200 (CEST) Received: from gaupe.stud.ntnu.no (gaupe.stud.ntnu.no [129.241.56.184]) by signal.itea.ntnu.no (Postfix) with ESMTP; Mon, 13 Aug 2007 22:40:35 +0200 (CEST) Received: by gaupe.stud.ntnu.no (Postfix, from userid 2312) id DB455D0046; Mon, 13 Aug 2007 22:40:35 +0200 (CEST) Date: Mon, 13 Aug 2007 22:40:35 +0200 From: Ulf Lilleengen To: freebsd-current@freebsd.org, freebsd-geom@freebsd.org, freebsd-arch@freebsd.org Message-ID: <20070813204035.GA5338@stud.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: le@FreeBSD.org Subject: Testers wanted: Gvinum patches of SoC 2007 work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 20:40:40 -0000 Hi, It's here! The new and hopefully better gvinum patch. This is perhaps my final patch of the work I've done during GSoC 2007 (the patch will be updated when I fix a bug). This doesn't mean I'll stop work on gvinum, but rather that I'm not adding more features until this gets into the tree. But, for this to get into the tree, I need people to test it. _ALL_ reports on how it works is good. So, what should you test? * Plain normal use. * Mirror synchronization, rebuild if raid-5 arrays, growing of raid-5 arrays etc. These should work, and probably is the most tested, but some weird combinations that I have not forseen might show itself. * Try weird combinations to check if it crashes. * Test mirror, concat, stripe and raid5 commands. * If there are any issues with the usability aspect. E.g. if the information gvinum gives you is good enough for you to understand what it's doing, if one way to do things seems unnatural to you etc. I'd like to hear all of this, no matter how bikshedish it might sound, it might be something that have been overlooked. These things are hard to test for the people that have been developing it, since we know how it "should" be used. Before you head on, beware that the new gvinum does not give messages back to the userland gvinum (so you won't get them into your terminal). This is because it's not very simple to do with the new event system. !! This means you'll have to look after messages in /var/log/messages !! And thanks to people for comments and help that I've been getting during the summer. -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Mon Aug 13 20:47:19 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0CEF16A417; Mon, 13 Aug 2007 20:47:19 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from fri.itea.ntnu.no (fri.itea.ntnu.no [129.241.7.60]) by mx1.freebsd.org (Postfix) with ESMTP id 8865713C494; Mon, 13 Aug 2007 20:47:19 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by fri.itea.ntnu.no (Postfix) with ESMTP id 10CA6868F; Mon, 13 Aug 2007 22:46:55 +0200 (CEST) Received: from gaupe.stud.ntnu.no (gaupe.stud.ntnu.no [129.241.56.184]) by fri.itea.ntnu.no (Postfix) with ESMTP; Mon, 13 Aug 2007 22:46:51 +0200 (CEST) Received: by gaupe.stud.ntnu.no (Postfix, from userid 2312) id DACCFD0046; Mon, 13 Aug 2007 22:46:51 +0200 (CEST) Date: Mon, 13 Aug 2007 22:46:51 +0200 From: Ulf Lilleengen To: freebsd-current@freebsd.org, freebsd-geom@freebsd.org, freebsd-arch@freebsd.org Message-ID: <20070813204651.GB5338@stud.ntnu.no> References: <20070813204035.GA5338@stud.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070813204035.GA5338@stud.ntnu.no> User-Agent: Mutt/1.5.9i X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: le@FreeBSD.org Subject: Re: Testers wanted: Gvinum patches of SoC 2007 work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2007 20:47:20 -0000 On man, aug 13, 2007 at 10:40:35 +0200, Ulf Lilleengen wrote: > Hi, > > It's here! The new and hopefully better gvinum patch. This is perhaps my final > patch of the work I've done during GSoC 2007 (the patch will be updated when I > fix a bug). This doesn't mean I'll stop work on gvinum, but rather that I'm not > adding more features until this gets into the tree. But, for this to get into > the tree, I need people to test it. _ALL_ reports on how it works is good. > *SNIP* > Ehm, And ofcourse, the patches can be found here: http://folk.ntnu.no/lulf/patches/freebsd/gvinum One for releng_6* and one for current. The patch is applied like this: # cd /usr/src && patch < /path/to/patch Remember to not have the old gvinum module running. Then install the module: # cd /usr/src/sys/modules/geom/geom_vinum && make && make install clean Then install userland gvinum # cd /usr/src/sbin/gvinum && make && make install clean And you should be ready to go. The updated manpage in /usr/src/sbin/gvinum/gvinum.8 describes how growing is done. Just gzip it and put it in /usr/share/man/man8 to use it. -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 10:47:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 714E816A41B for ; Tue, 14 Aug 2007 10:47:37 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from merke.itea.ntnu.no (merke.itea.ntnu.no [129.241.7.61]) by mx1.freebsd.org (Postfix) with ESMTP id C8DCB13C465 for ; Tue, 14 Aug 2007 10:47:36 +0000 (UTC) (envelope-from lulf@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by merke.itea.ntnu.no (Postfix) with ESMTP id 3B9E713D03C; Tue, 14 Aug 2007 12:47:34 +0200 (CEST) Received: from caracal.stud.ntnu.no (caracal.stud.ntnu.no [129.241.56.185]) by merke.itea.ntnu.no (Postfix) with ESMTP; Tue, 14 Aug 2007 12:47:25 +0200 (CEST) Received: by caracal.stud.ntnu.no (Postfix, from userid 2312) id 10BFE6240E2; Tue, 14 Aug 2007 12:47:25 +0200 (CEST) Date: Tue, 14 Aug 2007 12:47:25 +0200 From: Ulf Lilleengen To: freebsd-current@freebsd.org Message-ID: <20070814104724.GA13068@stud.ntnu.no> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: kib@FreeBSD.org Subject: [PATCH] Make fdescfs MPSAFE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 10:47:37 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, To be able to better understand VFS and locking in general, I started making fdescfs MPSAFE. I'm not experienced with any of these things, so there might be some errors, although I've looked through much VFS code and code for other FS like nullfs. I've tested it by running two pthreads on the same fd, and that seamt to work, but there might be other cases where it will fail. Patch is attached. -- Ulf Lilleengen --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fdescfs_locking.diff" Index: sys/fs/fdescfs/fdesc.h =================================================================== RCS file: /home/ncvs/src/sys/fs/fdescfs/fdesc.h,v retrieving revision 1.20 diff -u -r1.20 fdesc.h --- sys/fs/fdescfs/fdesc.h 10 Feb 2005 12:09:15 -0000 1.20 +++ sys/fs/fdescfs/fdesc.h 13 Aug 2007 23:29:21 -0000 @@ -31,7 +31,7 @@ * * @(#)fdesc.h 8.5 (Berkeley) 1/21/94 * - * $FreeBSD: src/sys/fs/fdescfs/fdesc.h,v 1.20 2005/02/10 12:09:15 phk Exp $ + * $FreeBSD$ */ #ifdef _KERNEL @@ -59,6 +59,7 @@ #define VTOFDESC(vp) ((struct fdescnode *)(vp)->v_data) extern vfs_init_t fdesc_init; +extern vfs_uninit_t fdesc_uninit; extern int fdesc_allocvp(fdntype, int, struct mount *, struct vnode **, struct thread *); #endif /* _KERNEL */ Index: sys/fs/fdescfs/fdesc_vfsops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/fdescfs/fdesc_vfsops.c,v retrieving revision 1.56 diff -u -r1.56 fdesc_vfsops.c --- sys/fs/fdescfs/fdesc_vfsops.c 4 Apr 2007 09:11:32 -0000 1.56 +++ sys/fs/fdescfs/fdesc_vfsops.c 13 Aug 2007 23:29:21 -0000 @@ -31,7 +31,7 @@ * * @(#)fdesc_vfsops.c 8.4 (Berkeley) 1/21/94 * - * $FreeBSD: src/sys/fs/fdescfs/fdesc_vfsops.c,v 1.56 2007/04/04 09:11:32 rwatson Exp $ + * $FreeBSD$ */ /* @@ -85,17 +85,22 @@ if (mp->mnt_flag & (MNT_UPDATE | MNT_ROOTFS)) return (EOPNOTSUPP); - error = fdesc_allocvp(Froot, FD_ROOT, mp, &rvp, td); - if (error) - return (error); - MALLOC(fmp, struct fdescmount *, sizeof(struct fdescmount), M_FDESCMNT, M_WAITOK); /* XXX */ + error = fdesc_allocvp(Froot, FD_ROOT, mp, &rvp, td); + if (error) { + free(fmp, M_FDESCMNT); + return (error); + } rvp->v_type = VDIR; rvp->v_vflag |= VV_ROOT; fmp->f_root = rvp; + VOP_UNLOCK(rvp, 0, td); /* XXX -- don't mark as local to work around fts() problems */ /*mp->mnt_flag |= MNT_LOCAL;*/ + MNT_ILOCK(mp); + mp->mnt_kern_flag |= MNTK_MPSAFE; + MNT_IUNLOCK(mp); mp->mnt_data = (qaddr_t) fmp; vfs_getnewfsid(mp); @@ -148,8 +153,8 @@ * Return locked reference to root. */ vp = VFSTOFDESC(mp)->f_root; - VREF(vp); vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td); + VREF(vp); *vpp = vp; return (0); } @@ -209,6 +214,7 @@ .vfs_root = fdesc_root, .vfs_statfs = fdesc_statfs, .vfs_unmount = fdesc_unmount, + .vfs_uninit = fdesc_uninit, }; VFS_SET(fdesc_vfsops, fdescfs, VFCF_SYNTHETIC); Index: sys/fs/fdescfs/fdesc_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/fdescfs/fdesc_vnops.c,v retrieving revision 1.104 diff -u -r1.104 fdesc_vnops.c --- sys/fs/fdescfs/fdesc_vnops.c 4 Apr 2007 09:11:32 -0000 1.104 +++ sys/fs/fdescfs/fdesc_vnops.c 13 Aug 2007 23:29:21 -0000 @@ -31,7 +31,7 @@ * * @(#)fdesc_vnops.c 8.9 (Berkeley) 1/21/94 * - * $FreeBSD: src/sys/fs/fdescfs/fdesc_vnops.c,v 1.104 2007/04/04 09:11:32 rwatson Exp $ + * $FreeBSD$ */ /* @@ -58,7 +58,7 @@ #define FDL_WANT 0x01 #define FDL_LOCKED 0x02 -static int fdcache_lock; +static struct mtx fdesc_hashmtx; #define NFDCACHE 4 #define FD_NHASH(ix) \ @@ -97,9 +97,32 @@ { fdhashtbl = hashinit(NFDCACHE, M_CACHE, &fdhash); + mtx_init(&fdesc_hashmtx, "fdeschs", NULL, MTX_DEF); return (0); } +/* Cleanup. */ +int +fdesc_uninit(vfsp) + struct vfsconf *vfsp; +{ + + mtx_destroy(&fdesc_hashmtx); + return (0); +} + +static void +fdesc_insmntque_dtr(struct vnode *vp, void *arg) +{ + struct fdescnode *fd; + + fd = (struct fdescnode *)arg; + free(fd, M_TEMP); + vp->v_data = NULL; + vgone(vp); + vput(vp); +} + int fdesc_allocvp(ftype, ix, mp, vpp, td) fdntype ftype; @@ -114,25 +137,20 @@ fc = FD_NHASH(ix); loop: + mtx_lock(&fdesc_hashmtx); LIST_FOREACH(fd, fc, fd_hash) { if (fd->fd_ix == ix && fd->fd_vnode->v_mount == mp) { - if (vget(fd->fd_vnode, 0, td)) + VI_LOCK(fd->fd_vnode); + mtx_unlock(&fdesc_hashmtx); + if (vget(fd->fd_vnode, LK_EXCLUSIVE | LK_INTERLOCK, td)) { + VI_UNLOCK(fd->fd_vnode); goto loop; + } *vpp = fd->fd_vnode; return (error); } } - - /* - * otherwise lock the array while we call getnewvnode - * since that can block. - */ - if (fdcache_lock & FDL_LOCKED) { - fdcache_lock |= FDL_WANT; - (void) tsleep( &fdcache_lock, PINOD, "fdalvp", 0); - goto loop; - } - fdcache_lock |= FDL_LOCKED; + mtx_unlock(&fdesc_hashmtx); /* * Do the MALLOC before the getnewvnode since doing so afterward @@ -151,23 +169,14 @@ fd->fd_type = ftype; fd->fd_fd = -1; fd->fd_ix = ix; - /* XXX: vnode should be locked here */ - error = insmntque(*vpp, mp); /* XXX: Too early for mpsafe fs */ - if (error != 0) { - free(fd, M_TEMP); - *vpp = NULLVP; + vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY, td); + error = insmntque1(*vpp, mp, fdesc_insmntque_dtr, fd); + if (error != 0) goto out; - } + mtx_lock(&fdesc_hashmtx); LIST_INSERT_HEAD(fc, fd, fd_hash); - + mtx_unlock(&fdesc_hashmtx); out: - fdcache_lock &= ~FDL_LOCKED; - - if (fdcache_lock & FDL_WANT) { - fdcache_lock &= ~FDL_WANT; - wakeup( &fdcache_lock); - } - return (error); } @@ -233,8 +242,7 @@ if (error) goto bad; VTOFDESC(fvp)->fd_fd = fd; - if (fvp != dvp) - vn_lock(fvp, LK_EXCLUSIVE | LK_RETRY, td); + *vpp = fvp; return (0); @@ -528,7 +536,10 @@ struct vnode *vp = ap->a_vp; struct fdescnode *fd = VTOFDESC(vp); + mtx_lock(&fdesc_hashmtx); LIST_REMOVE(fd, fd_hash); + mtx_unlock(&fdesc_hashmtx); + FREE(vp->v_data, M_TEMP); vp->v_data = 0; --fUYQa+Pmc3FrFX/N-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 11:20:13 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F2A116A420 for ; Tue, 14 Aug 2007 11:20:13 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 05E8213C4A8 for ; Tue, 14 Aug 2007 11:20:12 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id B6D2C1B10EA4; Tue, 14 Aug 2007 13:00:48 +0200 (CEST) Received: from hater.cmotd.com (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id B3A131B10C26; Tue, 14 Aug 2007 13:00:48 +0200 (CEST) Message-ID: <46C18B60.8050400@moneybookers.com> Date: Tue, 14 Aug 2007 14:00:48 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.4pre (X11/20070711) MIME-Version: 1.0 To: Eygene Ryabinkin References: <20070806224112.GA21876@muon.bluestop.org> <20070807073920.GV50228@void.codelabs.ru> In-Reply-To: <20070807073920.GV50228@void.codelabs.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: current@freebsd.org Subject: Re: "tcpflags 0x18; tcp_do_segment" kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 11:20:13 -0000 Hi, Eygene Ryabinkin wrote: > Bruce, good day. > > Mon, Aug 06, 2007 at 11:41:12PM +0100, bruce@cran.org.uk wrote: > >> I cvsupped my -CURRENT laptop last night and have been building ports >> today. When I checked the dmesg there were lots of messages similar to: >> >> TCP: [204.152.184.73]:21 to [10.0.10.13]:65159] tcpflags 0x18; >> tcp_do_segment: FIN_WAIT_2: Received data after socket was closed, >> sending RST and removing tcpcb >> > > This was introduced in the /sys/netinet/tcp_input.c, 1.365. > The origin and need for the change was discuissed in > http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014804.html > (See http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014808.html > for the explanation of what's going on). > > If you were running -CURRENT on the same machine prior to CVSupping, > then you probably saw the 'Spurious RST' messages. They were > provoked by the same situation. The messages themselves are harmless, > This is not harmless here :( I'm running current from today 14.Aug. I use an network applications that hangs every time when I see such a message. Any ideas how can I debug, or help to someone who is familiar with the code ? My colleagues report and problems with ssh and apache on this server. > they just telling us that some data was came in, but the listener > had already closed his socket, so he is not interested in the data > anymore. > > Use sys.net.inet.tcp.log_debug to disable TCP stack debug output > and get rid of those. > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 12:09:57 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78F6216A417 for ; Tue, 14 Aug 2007 12:09:57 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2001:1b20:1:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id D251613C457 for ; Tue, 14 Aug 2007 12:09:56 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (vmzsxe@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l7EC9nlg082369; Tue, 14 Aug 2007 14:09:54 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l7EC9nrb082368; Tue, 14 Aug 2007 14:09:49 +0200 (CEST) (envelope-from olli) Date: Tue, 14 Aug 2007 14:09:49 +0200 (CEST) Message-Id: <200708141209.l7EC9nrb082368@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, h.schmalzbauer@omnisec.de In-Reply-To: <200708132141.43165.h.schmalzbauer@omnisec.de> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 14 Aug 2007 14:09:54 +0200 (CEST) X-Mailman-Approved-At: Tue, 14 Aug 2007 12:15:39 +0000 Cc: Subject: Re: powerd and it's "wakeup" behaviour X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 12:09:57 -0000 Harald Schmalzbauer wrote: > I'm using cpufreq (acpi_perf (800/9800 500/5900) with acpi_throttle and I have > limited debug.cpufreq.lowest=250, so dev.cpu.0.freq_levels reads: > 800/9800 700/8575 600/7350 500/5900 437/5162 375/4425 312/3687 250/2950 > > I haven't tested the saving which acpi_throttling provides, but I think I can > gain some minutes over plain 800/500MHz(Vcore)switch. > > Now the problem is that "waking up" from 250 MHz to full speed needs too much > time to be effective for short term task like displaying a PDF. > Reading the file doesn't stress the CPU so powerd increases "clock" > (paranthesized because clock has only two states, but throttling adds 6 > steps) in 7 steps to 800MHz. > > I'd love to have a option which tells powerd to slowly step down, but jump to > full throttle if threshold of cpu usage is reached, regardless the current > clock setting. So a CPU usage peak would give full performance first, then > slowly stepping down again according to the CPU usage. > > Even my old 800MHz P3-m is fast enough to complete "cpu hungry" tasks in a > quiet short time, so slowly stepping clock up is not optimal form me because > it's not that fast that comleting the task with quarter speed doesn't feel > sluggish. > > Any thoughts? > Anyone who could and want to implement such a feature? (my programming skills > are far beyond...) I've needed a similar feature for some time and I have a patch, so I cleaned it up a bit and submitted it along with an update to the manpage. It's PR bin/115513: http://www.freebsd.org/cgi/query-pr.cgi?pr=115513 Apply the diff relative to src/usr/sbin/powerd, then "make clean && make && make install", and restart powerd with option -u 100. That should have the effect that you described above. The patch is relative to RELENG_6 (it can be applied manually to -current without problems). If you have difficulty extracting it from the PR, the patch is also available from this URL: http://www.secnetix.de/~olli/tmp/powerd.diff Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 14:48:56 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F41916A418 for ; Tue, 14 Aug 2007 14:48:56 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp814.mail.ird.yahoo.com (smtp814.mail.ird.yahoo.com [217.146.188.74]) by mx1.freebsd.org (Postfix) with SMTP id 5D7C413C480 for ; Tue, 14 Aug 2007 14:48:54 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 96250 invoked from network); 14 Aug 2007 14:48:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:From:To:Subject:Date:User-Agent:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=stneCBaiWvWbySyudw3a8m/W0FqQG0MN3owBBiK3+LSSu/XAEAUgy5C4exj2UgmNXOlVcSqK6OiWBp6Kq3JoJ1BKd/jqb+tXNhK4LaUghhqimKlRMagJb+RKI7zO+ZoPsJ5wJBmS//mw+Ue4u8/5I4NRl0qDgoprVJV8PWxI8Gg= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (thomas.sparrevohn@btinternet.com@86.148.49.224 with login) by smtp814.mail.ird.yahoo.com with SMTP; 14 Aug 2007 14:48:52 -0000 X-YMail-OSG: mQ9OrToVM1mfQUIXXSHOYOjusxlU4_oXx5qtFhe1VLmVAOYLDBc0r3U3Et50dhU0Di4v1O0W3A-- From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Tue, 14 Aug 2007 15:48:45 +0100 User-Agent: KMail/1.9.7 References: <200708120157.l7C1vWcI060342@gw.catspoiler.org> <200708120442.l7C4gtMP060591@gw.catspoiler.org> <20070812124840.GA5465@muon.bluestop.org> In-Reply-To: <20070812124840.GA5465@muon.bluestop.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708141548.46049.Thomas.Sparrevohn@btinternet.com> Subject: Re: Reboot on "shutdown -r" hangs after final "uptime ..." string X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 14:48:56 -0000 Thanks to everybody that worked on this - My machine now powers down correctly - Thanks a million From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 14:58:09 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BC8516A41B for ; Tue, 14 Aug 2007 14:58:09 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 2498B13C4B4 for ; Tue, 14 Aug 2007 14:58:09 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=h9MDRpLp39pnRYEdSpxEDleMl9sNTFiR+8bRl1QOcXQNLGhPGeJee0MujIQbwn2/vIwi5vxve7ly54JcOLtdG2TnVQP+TnO6v90NeARJX/42NVd5vF+Nlu91OwVKRQf9Kd8Pq0RZIqH1Y/AcX7UUUOFjaUbRcwWMuWtqH9hbgwc=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1IKxqN-00012q-OO; Tue, 14 Aug 2007 18:58:03 +0400 Date: Tue, 14 Aug 2007 18:57:59 +0400 From: Eygene Ryabinkin To: Stefan Lambrev Message-ID: <20070814145759.GB25169@void.codelabs.ru> References: <20070806224112.GA21876@muon.bluestop.org> <20070807073920.GV50228@void.codelabs.ru> <46C18B60.8050400@moneybookers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <46C18B60.8050400@moneybookers.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: current@freebsd.org Subject: Re: "tcpflags 0x18; tcp_do_segment" kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 14:58:09 -0000 Stefan, good day. Tue, Aug 14, 2007 at 02:00:48PM +0300, Stefan Lambrev wrote: > >If you were running -CURRENT on the same machine prior to CVSupping, > >then you probably saw the 'Spurious RST' messages. They were > >provoked by the same situation. The messages themselves are harmless, > > > This is not harmless here :( Yep, sorry. What I meant is that 'I had no problems with them' ;)) > I'm running current from today 14.Aug. > I use an network applications that hangs every time when I see such a message. > > Any ideas how can I debug, or help to someone who is familiar with the code ? You can provide the tcpdump's raw dump of the session (sniffed with the -s 1500 or whatever MTU you have). This may sched some light. > My colleagues report and problems with ssh and apache on this server. Haven't seen any with SSH, but Apache tends to close keep-alived connections on the -CURRENT. Try disabling them and see if this will help. More verbose description of problems your colleagues are seeing may also help. Thank you! -- Eygene From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 17:39:32 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD15116A41B for ; Tue, 14 Aug 2007 17:39:32 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 6BBAE13C45D for ; Tue, 14 Aug 2007 17:39:32 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (1w158508u7ou3ix9@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l7EHdVb3023446; Tue, 14 Aug 2007 10:39:31 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l7EHdVGP023445; Tue, 14 Aug 2007 10:39:31 -0700 (PDT) (envelope-from jmg) Date: Tue, 14 Aug 2007 10:39:30 -0700 From: John-Mark Gurney To: Peter Jeremy Message-ID: <20070814173930.GC99491@funkthat.com> Mail-Followup-To: Peter Jeremy , Jona Joachim , freebsd-current@freebsd.org References: <46B14894.8060408@tpnet.co.nz> <20070802235154.3d518c3d@localhost> <20070802234658.GB2842@soaustin.net> <20070803150030.01f4d545@spaceman.my.domain> <20070804004107.GJ1262@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070804004107.GJ1262@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-current@freebsd.org, Jona Joachim Subject: Re: Atheros Open Hal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 17:39:32 -0000 Peter Jeremy wrote this message on Sat, Aug 04, 2007 at 10:41 +1000: > On 2007-Aug-03 15:00:30 +0200, Jona Joachim wrote: > >On Thu, 2 Aug 2007 18:46:58 -0500 > >linimon@lonesome.com (Mark Linimon) wrote: > > > >> On Thu, Aug 02, 2007 at 11:51:54PM +0200, Jona Joachim wrote: > >> > Quoting from > >> > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/people.html: > >> > "In order to develop FreeBSD, committers must have the ability to > >> > openly discuss matters that will be resolved before they are > >> > publicly announced. Frank discussions of work in progress are not > >> > suitable for open publication and may harm FreeBSD." > ... > >I reread the sentence twice to make sure I don't change its meaning > >by putting it out of context. > > However you didn't mention the final paragraph regarding the > -developers list which makes it clear that -developers is _not_ > intended to hide general discussions from the general FreeBSD > community. There's a lot that wasn't quoted: Examples are Core voting, announcements, etc. This list is not intended as a place for code reviews or a replacement for the FreeBSD architecture and design mailing list or the FreeBSD source code audit mailing list. In fact using it as such hurts the FreeBSD Project as it gives a sense of a closed list where general decisions affecting all of the FreeBSD using community are made without being "open". And that last one clearly states that what was accussed should not happen... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 18:24:09 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10B9916A418 for ; Tue, 14 Aug 2007 18:24:09 +0000 (UTC) (envelope-from freebsd@ruomad.net) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id C9DC513C45B for ; Tue, 14 Aug 2007 18:24:08 +0000 (UTC) (envelope-from freebsd@ruomad.net) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by postfix2-g20.free.fr (Postfix) with ESMTP id 94B9A1932774 for ; Tue, 14 Aug 2007 18:57:40 +0200 (CEST) Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id 6320D1CDAC; Tue, 14 Aug 2007 19:56:49 +0200 (CEST) Received: from [127.0.0.1] (unknown [82.64.157.224]) by smtp8-g19.free.fr (Postfix) with ESMTP id DCACA545F; Tue, 14 Aug 2007 19:56:48 +0200 (CEST) Message-ID: <46C1EDAC.6040306@ruomad.net> Date: Tue, 14 Aug 2007 20:00:12 +0200 From: Bruno Damour User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Bruce Cran References: <46BE8495.2000308@free.fr> <46BF4017.6090900@cran.org.uk> In-Reply-To: <46BF4017.6090900@cran.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 14 Aug 2007 19:14:57 +0000 Cc: freebsd-current@FreeBSD.org, Bruno Damour Subject: Re: TCP errors ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 18:24:09 -0000 Bruce Cran a écrit : > Bruno Damour wrote: >> Hello, >> >> I'm getting a lot of messages like this, what is that supposed to >> come from ? >> No harm done AFAIK but my dmesg gets bloated ? >> >> TCP: [192.168.0.100]:389 to [192.168.0.100]:53612 tcpflags >> 0x18; tcp_do_segment: FIN_WAIT_2: Received data after >> socket was closed, sending RST and removing tcpcb > > They're expected as part of some new debugging code in the TCP stack - > see > http://lists.freebsd.org/pipermail/freebsd-current/2007-August/075984.html > for details. > To stop them being displayed, set sys.net.inet.tcp.log_debug. > > -- > Bruce Cran > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" Ok thanks Good luck with the debugging ;-) bruno From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 18:10:46 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0F1016A520 for ; Tue, 14 Aug 2007 18:10:46 +0000 (UTC) (envelope-from mi@bonkers.video-collage.com) Received: from bonkers.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by mx1.freebsd.org (Postfix) with ESMTP id B885413C478 for ; Tue, 14 Aug 2007 18:10:45 +0000 (UTC) (envelope-from mi@bonkers.video-collage.com) Received: from bonkers.video-collage.com (localhost [127.0.0.1]) by bonkers.video-collage.com (8.14.1/8.14.1) with ESMTP id l7EHVH21025564 for ; Tue, 14 Aug 2007 13:31:17 -0400 (EDT) (envelope-from mi@bonkers.video-collage.com) Received: (from mi@localhost) by bonkers.video-collage.com (8.14.1/8.14.1/Submit) id l7EHVGI0025563 for current@freebsd.org; Tue, 14 Aug 2007 13:31:16 -0400 (EDT) (envelope-from mi) From: Mikhail Teterin To: current@freebsd.org Date: Tue, 14 Aug 2007 13:06:04 -0400 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708141306.05102.mteterin@meowmeow> X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: X-UID: 1087717 X-Keywords: Sender: mi@bonkers.video-collage.com X-Virus-Scanned: ClamAV 0.88.7/3957/Tue Aug 14 01:48:58 2007 on bonkers.video-collage.com X-Virus-Status: Clean X-Mailman-Approved-At: Tue, 14 Aug 2007 19:15:14 +0000 Cc: Subject: atexit vs. dlclose X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 18:10:46 -0000 Hello! The current implementation of atexit and dlclose allow programs to be shot in the tail by dlclose-ing a shared library, which may contain an atexit-scheduled function. In this case the program will seg-fault upon otherwise clean exit. Although usually benign, this may prevent other atexit-registered functions from ever being called -- potentially causing far more disruption than a random core-dump file here and there. Our current attitude is "atexit should not be called from shared libraries. Ha-ha." Although this is, likely, true, we could do better -- the atexit-scheduled function can be looked up in the list of the dlopen-ed libraries (by scanning the linked list and checking, whether the passed pointer is between mapbase and mapbase+textsize of any of the Obj_Entries). Here are the approaches I can think of: 1. atexit to bump up the shared object's ref-count. A re-implementation of atexit() (under libexec/rtld-elf someplace) will scan through the dlopen-ed objects. If the atexit's argument is found to belong to an object, that object's dl_refcount will be increased. This will cause the object to survive the explicit dlclose(), although it may still not survive, if the application calls dlclose an extra time. 2. dlclose to refuse unloading the object This way it will be the dlclose, that will perform the check -- for each symbol registered through atexit, it will check, whether the shared object being closed owns the symbol and fail with a descriptive error dlerror (and warnx?), if it does. I personally favour the second approach more, because it provides for more descriptive diagnostics and requires less invasive implementation (no atexit re-implementation). It will also survive multiple calls to dlclose, thus being more helpful to erroneous programmers. I can see, however, how the first approach can be argued to be "more elegant", though... What do you think? -mi From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 19:31:51 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7752616A421 for ; Tue, 14 Aug 2007 19:31:51 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 69DB213C45E for ; Tue, 14 Aug 2007 19:31:51 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 8C9831A4D7C; Tue, 14 Aug 2007 12:30:27 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id A542FC134; Tue, 14 Aug 2007 15:31:50 -0400 (EDT) Date: Tue, 14 Aug 2007 15:31:50 -0400 From: Kris Kennaway To: Eygene Ryabinkin Message-ID: <20070814193150.GA21553@rot26.obsecurity.org> References: <20070806224112.GA21876@muon.bluestop.org> <20070807073920.GV50228@void.codelabs.ru> <46C18B60.8050400@moneybookers.com> <20070814145759.GB25169@void.codelabs.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070814145759.GB25169@void.codelabs.ru> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, Stefan Lambrev Subject: Re: "tcpflags 0x18; tcp_do_segment" kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 19:31:51 -0000 On Tue, Aug 14, 2007 at 06:57:59PM +0400, Eygene Ryabinkin wrote: > Stefan, good day. > > Tue, Aug 14, 2007 at 02:00:48PM +0300, Stefan Lambrev wrote: > > >If you were running -CURRENT on the same machine prior to CVSupping, > > >then you probably saw the 'Spurious RST' messages. They were > > >provoked by the same situation. The messages themselves are harmless, > > > > > This is not harmless here :( > > Yep, sorry. What I meant is that 'I had no problems with them' ;)) > > > I'm running current from today 14.Aug. > > I use an network applications that hangs every time when I see such a message. > > > > Any ideas how can I debug, or help to someone who is familiar with the code ? > > You can provide the tcpdump's raw dump of the session (sniffed with > the -s 1500 or whatever MTU you have). This may sched some light. tcpdump will probably be essential. Kris From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 22:01:13 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3957916A419 for ; Tue, 14 Aug 2007 22:01:13 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.freebsd.org (Postfix) with ESMTP id 1622A13C48E for ; Tue, 14 Aug 2007 22:01:13 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 14 Aug 2007 15:01:12 -0700 X-IronPort-AV: i="4.19,261,1183359600"; d="scan'208"; a="171001624:sNHT40098618" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7EM1COF004812 for ; Tue, 14 Aug 2007 15:01:12 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7EM1CFA016421 for ; Tue, 14 Aug 2007 22:01:12 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 15:01:11 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 15:01:11 -0700 Message-ID: <46C2263F.4080607@cisco.com> Date: Tue, 14 Aug 2007 18:01:35 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2007 22:01:11.0896 (UTC) FILETIME=[A05D2580:01C7DEBE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=242; t=1187128872; x=1187992872; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20IP=20over=20HTTP? |Sender:=20; bh=6BrJECaPu+i0dMMjsO3UU+DTI/gk/16IuqwlUDdnfTM=; b=rKOnI+vNGLeguwHlQ/Yr50wr+HdG/BZgD4eGxCaP4nmtqzxnmsfYysd+wpnDc9pcRSdfGHFp /w1L0SAFvqN++BJvBC6cwe2VikOsqpUyxd7rO/DVQqJCD6wl+QEO/FtM; Authentication-Results: sj-dkim-3; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); Cc: Subject: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 22:01:13 -0000 Hi all: Just curious.. as anyone did this on BSD? If so, pointers would be nice.. if not... I may (but I won't go into the rant as why ;-D) R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 23:05:54 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18DB816A418 for ; Tue, 14 Aug 2007 23:05:54 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id A3A2D13C4B5 for ; Tue, 14 Aug 2007 23:05:53 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so820379nfb for ; Tue, 14 Aug 2007 16:05:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K4xJuWYMJq5nXo93gb8bAlDPoVUky6RX9tkj2ObirVEMpORiPG4kacfIFr9TrOVlqaXiVb2X92rgnDxs8wftifKQJ6uexj1q/5hTa7WqFk9XT+zZfrUuH9KVcOANtnpZdRevxIrmt/NlBwIwoJA2tfPwXw2PtdlmSSJTcbiE5oo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gwTzVfKtzjKKsvswOBx0Iu7JiTk+SvWGZR5NT0TpEwQ8JwXd4eBpg8kKuDIpBcFU+sXABZN5lCe2iV6/TBUdojrf+pdsgMNrtiYUZ6LUon22GEGeopQ63y8W3QrM8W7LPBSVrF48xzcjUCqXuuamlkiMzJr9JDbqI6yk8MB80Jc= Received: by 10.78.166.7 with SMTP id o7mr3062517hue.1187132751817; Tue, 14 Aug 2007 16:05:51 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Tue, 14 Aug 2007 16:05:51 -0700 (PDT) Message-ID: Date: Tue, 14 Aug 2007 16:05:51 -0700 From: "Kip Macy" To: "Randall Stewart" In-Reply-To: <46C2263F.4080607@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46C2263F.4080607@cisco.com> Cc: current@freebsd.org Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 23:05:54 -0000 On 8/14/07, Randall Stewart wrote: > Hi all: > > Just curious.. as anyone did this on BSD? > > If so, pointers would be nice.. if not... I may (but > I won't go into the rant as why ;-D) I can guess. I believe there is an IPoDNS netgraph module floating around that *might* make a good reference. -Kip From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 23:22:36 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B3B216A420 for ; Tue, 14 Aug 2007 23:22:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outY.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id EA38E13C457 for ; Tue, 14 Aug 2007 23:22:35 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 14 Aug 2007 16:22:35 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 1AC7E125F65; Tue, 14 Aug 2007 16:22:35 -0700 (PDT) Message-ID: <46C2393B.8080508@elischer.org> Date: Tue, 14 Aug 2007 16:22:35 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Randall Stewart References: <46C2263F.4080607@cisco.com> In-Reply-To: <46C2263F.4080607@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 23:22:36 -0000 Randall Stewart wrote: > Hi all: > > Just curious.. as anyone did this on BSD? > > If so, pointers would be nice.. if not... I may (but > I won't go into the rant as why ;-D) > > R hmm Are you considering a network tunnelling interface? :-) ifconfig http0 create ifconfig http0 remote www.freebsd.org:6667 ifconfig http0 tunnelend myend route add default tunnelend Hmmm actually you could probably do this with netgraph or even tunnel (/dev/tun) devices right? From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 23:24:07 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC74216A41A for ; Tue, 14 Aug 2007 23:24:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id B3CCB13C442 for ; Tue, 14 Aug 2007 23:24:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 14 Aug 2007 16:24:07 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id B531C125F55; Tue, 14 Aug 2007 16:24:06 -0700 (PDT) Message-ID: <46C2399A.2050401@elischer.org> Date: Tue, 14 Aug 2007 16:24:10 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Kip Macy References: <46C2263F.4080607@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randall Stewart , current@freebsd.org Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 23:24:07 -0000 Kip Macy wrote: > On 8/14/07, Randall Stewart wrote: >> Hi all: >> >> Just curious.. as anyone did this on BSD? >> >> If so, pointers would be nice.. if not... I may (but >> I won't go into the rant as why ;-D) > > I can guess. I believe there is an IPoDNS netgraph module floating > around that *might* make a good reference. > > -Kip > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" OH Come on.. if you have a reference, cough up :-) It should be committed! (how many times have I wanted that?) From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 23:36:15 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB8EA16A41B for ; Tue, 14 Aug 2007 23:36:15 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outR.internet-mail-service.net (outR.internet-mail-service.net [216.240.47.241]) by mx1.freebsd.org (Postfix) with ESMTP id BC92813C468 for ; Tue, 14 Aug 2007 23:36:15 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 14 Aug 2007 16:36:13 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 11725125F78; Tue, 14 Aug 2007 16:36:09 -0700 (PDT) Message-ID: <46C23C6C.5020202@elischer.org> Date: Tue, 14 Aug 2007 16:36:12 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Kip Macy References: <46C2263F.4080607@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randall Stewart , current@freebsd.org Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 23:36:15 -0000 Kip Macy wrote: > On 8/14/07, Randall Stewart wrote: >> Hi all: >> >> Just curious.. as anyone did this on BSD? >> >> If so, pointers would be nice.. if not... I may (but >> I won't go into the rant as why ;-D) > > I can guess. I believe there is an IPoDNS netgraph module floating > around that *might* make a good reference. hmm OMG /usr/ports/net/iodine !! > > -Kip > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 23:50:52 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68D5216A418 for ; Tue, 14 Aug 2007 23:50:52 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.freebsd.org (Postfix) with ESMTP id 430D813C46C for ; Tue, 14 Aug 2007 23:50:52 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 14 Aug 2007 16:50:52 -0700 X-IronPort-AV: i="4.19,261,1183359600"; d="scan'208"; a="200118705:sNHT45487449" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7ENoptv025186; Tue, 14 Aug 2007 16:50:52 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7ENoOFO013126; Tue, 14 Aug 2007 23:50:51 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 16:50:48 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 16:50:47 -0700 Message-ID: <46C23FEF.5060407@cisco.com> Date: Tue, 14 Aug 2007 19:51:11 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <46C2263F.4080607@cisco.com> <46C23C6C.5020202@elischer.org> In-Reply-To: <46C23C6C.5020202@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2007 23:50:47.0937 (UTC) FILETIME=[EFFD5F10:01C7DECD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1364; t=1187135452; x=1187999452; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20IP=20over=20HTTP? |Sender:=20; bh=vxp/qu7x0f4QNh3rrI2zkzH/40v+1ezN7GBHC/Kjj2U=; b=OAKBsT4VBjtjK3enzpFeIYMoxim5SlSSfy1/Sn8m8BQKt5pIF0zeeA+TYns+yp9d9OhR7ghV AoJ7EToYu/gQuQzuCdozw5pxbbLYEXljjTIwuusTF1J3YA+VYjQ9ARRkFOcMLH/1Y8Qf0kobJz RiBx2bK/tO+U+5SjlEL94tIsk=; Authentication-Results: sj-dkim-1; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); Cc: Kip Macy , current@freebsd.org Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 23:50:52 -0000 Julian Elischer wrote: > Kip Macy wrote: > >> On 8/14/07, Randall Stewart wrote: >> >>> Hi all: >>> >>> Just curious.. as anyone did this on BSD? >>> >>> If so, pointers would be nice.. if not... I may (but >>> I won't go into the rant as why ;-D) >> >> >> I can guess. I believe there is an IPoDNS netgraph module floating >> around that *might* make a good reference. > > > hmm OMG > /usr/ports/net/iodine !! > >> >> -Kip >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > > Perfect... With some hacking I can use this as a starting point to make it run over web.. There are several places I have gone (rest areas in SD for example.. :-o) that block all but port 80. I am thinking I will add with this some sort of authentication too.. and reserve one of my IP addresses at home to use for this .. no more ^&&^*%$# they block everything but port 80 .. and for that matter xchat.. which is blocked (especially inside a firewall of a large router company's that Julian may run across :-D) would then work :-) R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Tue Aug 14 23:56:57 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DD4016A41A for ; Tue, 14 Aug 2007 23:56:57 +0000 (UTC) (envelope-from flz@xbsd.org) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id D0BF913C46B for ; Tue, 14 Aug 2007 23:56:56 +0000 (UTC) (envelope-from flz@xbsd.org) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix1-g20.free.fr (Postfix) with ESMTP id A8052189AF5A for ; Wed, 15 Aug 2007 01:28:42 +0200 (CEST) Received: from smtp6-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp6-g19.free.fr (Postfix) with ESMTP id 56098B7AE8; Wed, 15 Aug 2007 01:28:41 +0200 (CEST) Received: from smtp.xbsd.org (xbsd.org [82.233.2.192]) by smtp6-g19.free.fr (Postfix) with ESMTP id 50E2A955F; Wed, 15 Aug 2007 01:28:40 +0200 (CEST) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 9185112022; Wed, 15 Aug 2007 01:28:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at xbsd.org Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkGkIDw-tCYP; Wed, 15 Aug 2007 01:28:34 +0200 (CEST) Received: from [193.120.13.132] (innercity.xbsd.org [193.120.13.132]) by smtp.xbsd.org (Postfix) with ESMTP id 8E82912020; Wed, 15 Aug 2007 01:28:33 +0200 (CEST) In-Reply-To: <46C2399A.2050401@elischer.org> References: <46C2263F.4080607@cisco.com> <46C2399A.2050401@elischer.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <36C33C6D-8EDE-4000-9B3D-164CD580BE7F@xbsd.org> Content-Transfer-Encoding: 7bit From: Florent Thoumie Date: Wed, 15 Aug 2007 00:28:26 +0100 To: Julian Elischer X-Mailer: Apple Mail (2.752.2) Cc: Kip Macy , Randall Stewart , current@freebsd.org Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2007 23:56:57 -0000 On 15 Aug 2007, at 00:24, Julian Elischer wrote: > Kip Macy wrote: >> On 8/14/07, Randall Stewart wrote: >>> Hi all: >>> >>> Just curious.. as anyone did this on BSD? >>> >>> If so, pointers would be nice.. if not... I may (but >>> I won't go into the rant as why ;-D) >> I can guess. I believe there is an IPoDNS netgraph module floating >> around that *might* make a good reference. >> -Kip >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current- >> unsubscribe@freebsd.org" > > > > OH Come on.. if you have a reference, cough up :-) > It should be committed! (how many times have I wanted that?) I second that, if only for the coolness factor :-) -- Florent Thoumie flz@FreeBSD.org FreeBSD Committer From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 00:47:47 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5293016A418 for ; Wed, 15 Aug 2007 00:47:47 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outZ.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8E713C468 for ; Wed, 15 Aug 2007 00:47:47 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 14 Aug 2007 17:47:46 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id B1FEC125F81; Tue, 14 Aug 2007 17:47:45 -0700 (PDT) Message-ID: <46C24D35.7010301@elischer.org> Date: Tue, 14 Aug 2007 17:47:49 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Antony Mawer References: <46C2263F.4080607@cisco.com> <46C2393B.8080508@elischer.org> <46C24761.9080608@mawer.org> In-Reply-To: <46C24761.9080608@mawer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randall Stewart , current@freebsd.org Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 00:47:47 -0000 Antony Mawer wrote: > On 15/08/2007 9:22 AM, Julian Elischer wrote: >> Randall Stewart wrote: >>> Just curious.. as anyone did this on BSD? >>> >>> If so, pointers would be nice.. if not... I may (but >>> I won't go into the rant as why ;-D) >> >> hmm Are you considering a network tunnelling interface? :-) >> >> ifconfig http0 create >> ifconfig http0 remote www.freebsd.org:6667 ifconfig http0 tunnelend myend >> route add default tunnelend >> >> Hmmm actually you could probably do this with netgraph or even tunnel >> (/dev/tun) devices right? > > Isn't this the purpose of the "super tunnelling" daemon currently being > developed as a Google SoC project? > > http://wiki.freebsd.org/SuperTunnelDaemon I'm getting too old to remember everything going on in the entire world apparently.. good pointer. > > --Antony From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 00:53:54 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBC5F16A417 for ; Wed, 15 Aug 2007 00:53:54 +0000 (UTC) (envelope-from fbsd-current@mawer.org) Received: from webmail.icp-qv1-irony2.iinet.net.au (webmail.icp-qv1-irony2.iinet.net.au [203.59.1.107]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD2613C45A for ; Wed, 15 Aug 2007 00:53:53 +0000 (UTC) (envelope-from fbsd-current@mawer.org) Received: from unknown (HELO [10.24.1.1]) ([203.206.173.235]) by outbound.icp-qv1-irony-out2.iinet.net.au with ESMTP; 15 Aug 2007 08:23:54 +0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAHzkwUbLzq3r/2dsb2JhbAAN X-IronPort-AV: i="4.19,262,1183305600"; d="scan'208"; a="182845216:sNHT23670822" Message-ID: <46C24761.9080608@mawer.org> Date: Wed, 15 Aug 2007 10:22:57 +1000 From: Antony Mawer User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julian Elischer References: <46C2263F.4080607@cisco.com> <46C2393B.8080508@elischer.org> In-Reply-To: <46C2393B.8080508@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randall Stewart , current@freebsd.org Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 00:53:54 -0000 On 15/08/2007 9:22 AM, Julian Elischer wrote: > Randall Stewart wrote: >> Just curious.. as anyone did this on BSD? >> >> If so, pointers would be nice.. if not... I may (but >> I won't go into the rant as why ;-D) > > hmm Are you considering a network tunnelling interface? :-) > > ifconfig http0 create > ifconfig http0 remote www.freebsd.org:6667 ifconfig http0 tunnelend myend > route add default tunnelend > > Hmmm actually you could probably do this with netgraph or even tunnel > (/dev/tun) devices right? Isn't this the purpose of the "super tunnelling" daemon currently being developed as a Google SoC project? http://wiki.freebsd.org/SuperTunnelDaemon --Antony From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 01:28:00 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 400C816A41B for ; Wed, 15 Aug 2007 01:28:00 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 182A913C45D for ; Wed, 15 Aug 2007 01:27:59 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 60F8C12088; Tue, 14 Aug 2007 21:27:59 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 14 Aug 2007 21:27:59 -0400 X-Sasl-enc: 5Oksb1Wa40vcHFkElzBjOiLSJddYPFfVYQMLPxMH/cJo 1187141279 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id A2EBD3615; Tue, 14 Aug 2007 21:27:58 -0400 (EDT) Message-ID: <46C25696.3020306@incunabulum.net> Date: Wed, 15 Aug 2007 02:27:50 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Antony Mawer References: <46C2263F.4080607@cisco.com> <46C2393B.8080508@elischer.org> <46C24761.9080608@mawer.org> In-Reply-To: <46C24761.9080608@mawer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randall Stewart , Julian Elischer , current@freebsd.org Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 01:28:00 -0000 Antony Mawer wrote: > > Isn't this the purpose of the "super tunnelling" daemon currently > being developed as a Google SoC project? > > http://wiki.freebsd.org/SuperTunnelDaemon I guess so, but it will really need source-address selection (and IPv4 address scope) to work properly in all situations. regards, BMS From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 01:33:43 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B1C216A418 for ; Wed, 15 Aug 2007 01:33:43 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 26CF413C457 for ; Wed, 15 Aug 2007 01:33:43 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 380FF1A4D7C; Tue, 14 Aug 2007 18:32:18 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id 6D4DAC1DE; Tue, 14 Aug 2007 21:33:42 -0400 (EDT) Date: Tue, 14 Aug 2007 21:33:42 -0400 From: Kris Kennaway To: Randall Stewart Message-ID: <20070815013342.GA25882@rot26.obsecurity.org> References: <46C2263F.4080607@cisco.com> <46C23C6C.5020202@elischer.org> <46C23FEF.5060407@cisco.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <46C23FEF.5060407@cisco.com> User-Agent: Mutt/1.4.2.3i Cc: Kip Macy , Julian Elischer , current@freebsd.org Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 01:33:43 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 14, 2007 at 07:51:11PM -0400, Randall Stewart wrote: > Julian Elischer wrote: > >Kip Macy wrote: > > > >>On 8/14/07, Randall Stewart wrote: > >> > >>>Hi all: > >>> > >>>Just curious.. as anyone did this on BSD? > >>> > >>>If so, pointers would be nice.. if not... I may (but > >>>I won't go into the rant as why ;-D) > >> > >> > >>I can guess. I believe there is an IPoDNS netgraph module floating > >>around that *might* make a good reference. > > > > > >hmm OMG > >/usr/ports/net/iodine !! > > > >> > >> -Kip > >>_______________________________________________ > >>freebsd-current@freebsd.org mailing list > >>http://lists.freebsd.org/mailman/listinfo/freebsd-current > >>To unsubscribe, send any mail to=20 > >>"freebsd-current-unsubscribe@freebsd.org" > > > > > Perfect... >=20 > With some hacking I can use this as a starting point to make > it run over web.. You mean like www/httptunnel? :) Basically all you need is a method of bidirectionally passing data over whatever lower layer you want, then you can run ppp(8) over it. Kris --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGwlf2Wry0BWjoQKURAgJAAKDrV5uRavtoR2jn/kTNimYQpoOVbwCgt9fL 6/vSHc1B68hU9k4TEE9RlQY= =KWWw -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 01:36:12 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2E4216A420 for ; Wed, 15 Aug 2007 01:36:12 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 6340613C461 for ; Wed, 15 Aug 2007 01:36:12 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id F0B001CC59; Wed, 15 Aug 2007 03:36:09 +0200 (CEST) Date: Wed, 15 Aug 2007 03:36:09 +0200 From: Ed Schouten To: current@freebsd.org Message-ID: <20070815013609.GB58414@hoeg.nl> References: <46C2263F.4080607@cisco.com> <46C23C6C.5020202@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v9Ux+11Zm5mwPlX6" Content-Disposition: inline In-Reply-To: <46C23C6C.5020202@elischer.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 01:36:12 -0000 --v9Ux+11Zm5mwPlX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Julian Elischer wrote: > hmm OMG=20 > /usr/ports/net/iodine !! I know, little bit unrelated, but the Ports tree also has an IP-over-ICMP package: net/ptunnel Yours, --=20 Ed Schouten WWW: http://g-rave.nl/ --v9Ux+11Zm5mwPlX6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGwliJ52SDGA2eCwURAtuoAJ4nPAy8jv49ZRni9BilzcRZeBblswCaA9aR yZGXNsk8hMmJO/YxkKYkWCE= =NTNP -----END PGP SIGNATURE----- --v9Ux+11Zm5mwPlX6-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 02:22:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C37416A41A for ; Wed, 15 Aug 2007 02:22:08 +0000 (UTC) (envelope-from yb@bashibuzuk.net) Received: from a.6f2.net (a.6f2.net [213.189.5.89]) by mx1.freebsd.org (Postfix) with ESMTP id 181C213C45D for ; Wed, 15 Aug 2007 02:22:08 +0000 (UTC) (envelope-from yb@bashibuzuk.net) Received: by a.6f2.net (Postfix, from userid 66) id 1AD3EBF9598; Wed, 15 Aug 2007 04:22:07 +0200 (CEST) Received: by fandango.byzant.net (Postfix, from userid 1001) id 616E95A87; Tue, 14 Aug 2007 22:21:17 -0400 (EDT) Date: Tue, 14 Aug 2007 22:21:17 -0400 From: Yann Berthier To: freebsd-current@freebsd.org Message-ID: <20070815022117.GL37961@bashibuzuk.net> References: <46C2263F.4080607@cisco.com> <46C23C6C.5020202@elischer.org> <46C23FEF.5060407@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46C23FEF.5060407@cisco.com> X-Operating-System: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 02:22:08 -0000 On Tue, 14 Aug 2007, at 19:51, Randall Stewart wrote: > There are several places I have gone (rest areas in SD for > example.. :-o) that block all but port 80. it was mentioned recently in another thread, but in case you missed it: ssltunnel (in ports), creates a ppp over ssl tunnel, and even sports ntlm auth (not supposing that that router company you are part of uses isa, but may be handy on some customers' sites). Auth between client and tunnel endpoint is cert based From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 06:38:41 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D406F16A417; Wed, 15 Aug 2007 06:38:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8DC1413C468; Wed, 15 Aug 2007 06:38:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1ILCWd-0002bp-OZ; Wed, 15 Aug 2007 09:38:39 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: am-utils@fsl.cs.sunysb.edu In-reply-to: Your message of Mon, 06 Aug 2007 13:40:59 +0300 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Aug 2007 09:38:39 +0300 From: Danny Braniss Message-ID: Cc: freebsd-current@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: amd crashes when memory is low X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 06:38:42 -0000 > > Hi, > > This is not new, but now that freebsd current is almost out, I'm > > trying it out again. amd (am-utils version 6.1.5) on an amd64 will crash when > > vm memory is low. In the past it was suggested to add 'plock=no' to > > /etc/amd.conf, but I have to check if it's read since I still see: > > Couldn't lock process pages in memory using mlockall(): \ > > Resource temporarily unavailable > > > > I'll try it out under i386 and report later. > > ok, it works under i386, because mlockall() does not fail, and hence > amd is locked in core, while it failes under amd64. this does not explain > why it crashes when swapped out, but that is another problem? > to the am-utils maintainers: changing the call to mlockall, from mlockall(MCL_FUTURE|MCL_CURRENT) to mlockall(MCL_FUTURE) solves the problem. danny From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 07:00:53 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E4D316A418 for ; Wed, 15 Aug 2007 07:00:53 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.227]) by mx1.freebsd.org (Postfix) with ESMTP id 9C8DE13C4DD for ; Wed, 15 Aug 2007 07:00:52 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1429210wxd for ; Wed, 15 Aug 2007 00:00:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=sHxyid/jNjcxp4dXTzrUAFdAFtOEK+m/UpwcJAbtN9MK6JBsfTK//ZEkeAwM8UaJ3Vuk9gf7asnl/mPFtWZOvuqzRty5+PyltSKeQVFMhy2y1R2XTFgGqenxbd3OnaXObMNCXoiMuppXTJRMjR9drg0p41MHhh6H8mJtGs9Ob84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LRz4Uedv5J+T4PKp6LxQPahPd8TgP3HnBWeyzc1Fyf4nVWA6VxmGsP6hbIoiw6o9v4atfj300hST8OV9QYPm66TPE61DIxfjg46jbl8JZ9tk8wawjytB8YTZUb6HCzky+fkud+8ffkz0MFgCRBoyH+/dVol3fpflp1p7wR4S6BY= Received: by 10.70.72.11 with SMTP id u11mr426207wxa.1187161251568; Wed, 15 Aug 2007 00:00:51 -0700 (PDT) Received: by 10.100.144.1 with HTTP; Wed, 15 Aug 2007 00:00:51 -0700 (PDT) Message-ID: <11167f520708150000v614f78f5wcd5c4d3aca04211b@mail.gmail.com> Date: Wed, 15 Aug 2007 02:00:51 -0500 From: "Sam Fourman Jr." To: "Don Lewis" In-Reply-To: <200708110952.l7B9qp8C058494@gw.catspoiler.org> MIME-Version: 1.0 References: <20070811092626.GB22569@cdnetworks.co.kr> <200708110952.l7B9qp8C058494@gw.catspoiler.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, current@freebsd.org Subject: Re: bizarre nfe(4) problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 07:00:53 -0000 I am having weird nfe problems too, I tried to run -current today and I loaded a snapshot and upon dhclient nfe0 my computer reboots below is a dmesg(kinda it is actually a /var/log/messages file) from -current keep in mind that I am running PCBSD 1.4 BETA (based on 6.2 with nfe compiled in) and nfe is working like a champ. I would love to have any help or pointers Aug 14 19:56:52 newsyslog[836]: logfile first created Aug 14 19:56:52 syslogd: kernel boot file is /boot/kernel/kernel Aug 14 19:56:52 kernel: Copyright (c) 1992-2007 The FreeBSD Project. Aug 14 19:56:52 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Aug 14 19:56:52 kernel: The Regents of the University of California. All rights reserved. Aug 14 19:56:52 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Aug 14 19:56:52 kernel: FreeBSD 7.0-20070814-SNAP #0: Tue Aug 14 10:20:29 UTC 2007 Aug 14 19:56:52 kernel: root@builder.snapshots.us.freebsd.org :/usr/obj/usr/src/sys/GENERIC Aug 14 19:56:52 kernel: WARNING: WITNESS option enabled, expect reduced performance. Aug 14 19:56:52 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Aug 14 19:56:52 kernel: CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (2138.25-MHz 686-class CPU) Aug 14 19:56:52 kernel: Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Aug 14 19:56:52 kernel: Features=0xbfebfbff Aug 14 19:56:52 kernel: Features2=0xe3bd Aug 14 19:56:52 kernel: AMD Features=0x20100000 Aug 14 19:56:52 kernel: AMD Features2=0x1 Aug 14 19:56:52 kernel: Cores per package: 2 Aug 14 19:56:52 kernel: real memory = 2146369536 (2046 MB) Aug 14 19:56:52 kernel: avail memory = 2090835968 (1993 MB) Aug 14 19:56:52 kernel: ACPI APIC Table: Aug 14 19:56:52 kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Aug 14 19:56:52 kernel: cpu0 (BSP): APIC ID: 0 Aug 14 19:56:52 kernel: cpu1 (AP): APIC ID: 1 Aug 14 19:56:52 kernel: ioapic0: Changing APIC ID to 4 Aug 14 19:56:52 kernel: ioapic0 irqs 0-23 on motherboard Aug 14 19:56:52 kernel: kbd1 at kbdmux0 Aug 14 19:56:52 kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) Aug 14 19:56:52 kernel: acpi0: on motherboard Aug 14 19:56:52 kernel: acpi0: [ITHREAD] Aug 14 19:56:52 kernel: acpi_hpet0: iomem 0xfeff0000-0xfeff03ff on acpi0 Aug 14 19:56:52 kernel: Timecounter "HPET" frequency 25000000 Hz quality 900 Aug 14 19:56:52 kernel: acpi0: Power Button (fixed) Aug 14 19:56:52 kernel: acpi0: reservation of feff0000, 400 (3) failed Aug 14 19:56:52 kernel: acpi0: reservation of 0, a0000 (3) failed Aug 14 19:56:52 kernel: acpi0: reservation of 100000, 7fdf0000 (3) failed Aug 14 19:56:52 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Aug 14 19:56:52 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 Aug 14 19:56:52 kernel: cpu0: on acpi0 Aug 14 19:56:52 kernel: est0: on cpu0 Aug 14 19:56:52 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Aug 14 19:56:52 kernel: est: cpu_vendor GenuineIntel, msr 828082806000828 Aug 14 19:56:52 kernel: device_attach: est0 attach returned 6 Aug 14 19:56:52 kernel: p4tcc0: on cpu0 Aug 14 19:56:52 kernel: cpu1: on acpi0 Aug 14 19:56:52 kernel: est1: on cpu1 Aug 14 19:56:52 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Aug 14 19:56:52 kernel: est: cpu_vendor GenuineIntel, msr 828082806000828 Aug 14 19:56:52 kernel: device_attach: est1 attach returned 6 Aug 14 19:56:52 kernel: p4tcc1: on cpu1 Aug 14 19:56:52 kernel: acpi_button0: on acpi0 Aug 14 19:56:52 kernel: pcib0: port 0xcf8-0xcff on acpi0 Aug 14 19:56:52 kernel: pci0: on pcib0 Aug 14 19:56:52 kernel: pci0: at device 0.1 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 0.2 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 0.3 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 0.4 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 0.5 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 0.6 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 0.7 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 1.0 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 1.1 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 1.2 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 1.3 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 1.4 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 1.5 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 1.6 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 2.0 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 2.1 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 2.2 (no driver attached) Aug 14 19:56:52 kernel: pcib1: at device 3.0 on pci0 Aug 14 19:56:52 kernel: pci1: on pcib1 Aug 14 19:56:52 kernel: vgapci0: port 0xdf00-0xdf7f mem 0xec000000-0xecffffff,0xd0000000-0xdfffffff,0xea000000-0xebffffff irq 16 at device 0.0 on pci1 Aug 14 19:56:52 kernel: pci0: at device 9.0 (no driver attached) Aug 14 19:56:52 kernel: isab0: at device 10.0 on pci0 Aug 14 19:56:52 kernel: isa0: on isab0 Aug 14 19:56:52 kernel: pci0: at device 10.1 (no driver attached) Aug 14 19:56:52 kernel: pci0: at device 10.2 (no driver attached) Aug 14 19:56:52 kernel: ohci0: mem 0xeffff000-0xefffffff irq 21 at device 11.0 on pci0 Aug 14 19:56:52 kernel: ohci0: [GIANT-LOCKED] Aug 14 19:56:52 kernel: ohci0: [ITHREAD] Aug 14 19:56:52 kernel: usb0: OHCI version 1.0, legacy support Aug 14 19:56:52 kernel: usb0: SMM does not respond, resetting Aug 14 19:56:52 kernel: usb0: on ohci0 Aug 14 19:56:52 kernel: usb0: USB revision 1.0 Aug 14 19:56:52 kernel: uhub0: on usb0 Aug 14 19:56:52 kernel: uhub0: 10 ports with 10 removable, self powered Aug 14 19:56:52 kernel: ehci0: mem 0xefffe000-0xefffe0ff irq 22 at device 11.1 on pci0 Aug 14 19:56:52 kernel: ehci0: [GIANT-LOCKED] Aug 14 19:56:52 kernel: ehci0: [ITHREAD] Aug 14 19:56:52 kernel: usb1: EHCI version 1.0 Aug 14 19:56:52 kernel: usb1: companion controller, 10 ports each: usb0 Aug 14 19:56:52 kernel: usb1: on ehci0 Aug 14 19:56:52 kernel: usb1: USB revision 2.0 Aug 14 19:56:52 kernel: uhub1: on usb1 Aug 14 19:56:52 kernel: uhub1: 10 ports with 10 removable, self powered Aug 14 19:56:52 kernel: umass0: on uhub1 Aug 14 19:56:52 kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 13.0 on pci0 Aug 14 19:56:52 kernel: ata0: on atapci0 Aug 14 19:56:52 kernel: ata0: [ITHREAD] Aug 14 19:56:52 kernel: ata1: on atapci0 Aug 14 19:56:52 kernel: ata1: [ITHREAD] Aug 14 19:56:52 kernel: atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf700-0xf70f mem 0xefffd000-0xefffdfff irq 23 at device 14.0 on pci0 Aug 14 19:56:52 kernel: atapci1: [ITHREAD] Aug 14 19:56:52 kernel: ata2: on atapci1 Aug 14 19:56:52 kernel: ata2: [ITHREAD] Aug 14 19:56:52 kernel: ata3: on atapci1 Aug 14 19:56:52 kernel: ata3: [ITHREAD] Aug 14 19:56:52 kernel: atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf200-0xf20f mem 0xefffc000-0xefffcfff irq 20 at device 14.1 on pci0 Aug 14 19:56:52 kernel: atapci2: [ITHREAD] Aug 14 19:56:52 kernel: ata4: on atapci2 Aug 14 19:56:52 kernel: ata4: [ITHREAD] Aug 14 19:56:52 kernel: ata5: on atapci2 Aug 14 19:56:52 kernel: ata5: [ITHREAD] Aug 14 19:56:52 kernel: atapci3: port 0xf100-0xf107,0xf000-0xf003,0xef00-0xef07,0xee00-0xee03,0xed00-0xed0f mem 0xefffb000-0xefffbfff irq 21 at device 14.2 on pci0 Aug 14 19:56:52 kernel: atapci3: [ITHREAD] Aug 14 19:56:52 kernel: ata6: on atapci3 Aug 14 19:56:52 kernel: ata6: [ITHREAD] Aug 14 19:56:52 kernel: ata7: on atapci3 Aug 14 19:56:52 kernel: ata7: [ITHREAD] Aug 14 19:56:52 kernel: pcib2: at device 15.0 on pci0 Aug 14 19:56:52 kernel: pci2: on pcib2 Aug 14 19:56:52 kernel: fwohci0: port 0xcf00-0xcf7f mem 0xefdff000-0xefdff7ff irq 19 at device 11.0 on pci2 Aug 14 19:56:52 kernel: fwohci0: [FILTER] Aug 14 19:56:52 kernel: fwohci0: OHCI version 1.10 (ROM=1) Aug 14 19:56:52 kernel: fwohci0: No. of Isochronous channels is 4. Aug 14 19:56:52 kernel: fwohci0: EUI64 00:11:d8:00:01:1e:3d:ab Aug 14 19:56:52 kernel: fwohci0: Phy 1394a available S400, 2 ports. Aug 14 19:56:52 kernel: fwohci0: Link S400, max_rec 2048 bytes. Aug 14 19:56:52 kernel: firewire0: on fwohci0 Aug 14 19:56:52 kernel: fwe0: on firewire0 Aug 14 19:56:52 kernel: if_fwe0: Fake Ethernet address: 02:11:d8:1e:3d:ab Aug 14 19:56:52 kernel: fwe0: Ethernet address: 02:11:d8:1e:3d:ab Aug 14 19:56:52 kernel: fwip0: on firewire0 Aug 14 19:56:52 kernel: fwip0: Firewire address: 00:11:d8:00:01:1e:3d:ab @ 0xfffe00000000, S400, maxrec 2048 Aug 14 19:56:52 kernel: sbp0: on firewire0 Aug 14 19:56:52 kernel: dcons_crom0: on firewire0 Aug 14 19:56:52 kernel: dcons_crom0: bus_addr 0x7d864000 Aug 14 19:56:52 kernel: fwohci0: Initiate bus reset Aug 14 19:56:52 kernel: fwohci0: BUS reset Aug 14 19:56:52 kernel: fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode Aug 14 19:56:52 kernel: pci0: at device 15.1 (no driver attached) Aug 14 19:56:52 kernel: nfe0: port 0xec00-0xec07 mem 0xefffa000-0xefffafff,0xefff9000-0xefff90ff,0xefff8000-0xefff800f irq 23 at device 17.0 on pci0 Aug 14 19:56:52 kernel: miibus0: on nfe0 Aug 14 19:56:52 kernel: e1000phy0: PHY 19 on miibus0 Aug 14 19:56:52 kernel: e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto Aug 14 19:56:52 kernel: nfe0: Ethernet address: 00:1a:92:46:e0:44 Aug 14 19:56:52 kernel: nfe0: [FILTER] Aug 14 19:56:52 last message repeated 7 times Aug 14 19:56:52 kernel: nfe1: port 0xeb00-0xeb07 mem 0xefff7000-0xefff7fff,0xefff6000-0xefff60ff,0xefff5000-0xefff500f irq 20 at device 18.0 on pci0 Aug 14 19:56:52 kernel: miibus1: on nfe1 Aug 14 19:56:52 kernel: e1000phy1: PHY 1 on miibus1 Aug 14 19:56:52 kernel: e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto Aug 14 19:56:52 kernel: nfe1: Ethernet address: 00:1a:92:46:ed:f7 Aug 14 19:56:52 kernel: nfe1: [FILTER] Aug 14 19:56:52 last message repeated 7 times Aug 14 19:56:52 kernel: pcib3: at device 19.0 on pci0 Aug 14 19:56:52 kernel: pci3: on pcib3 Aug 14 19:56:52 kernel: pcib4: at device 20.0 on pci0 Aug 14 19:56:52 kernel: pci4: on pcib4 Aug 14 19:56:52 kernel: pcib5: at device 21.0 on pci0 Aug 14 19:56:52 kernel: pci5: on pcib5 Aug 14 19:56:52 kernel: pcib6: at device 22.0 on pci0 Aug 14 19:56:52 kernel: pci6: on pcib6 Aug 14 19:56:52 kernel: atapci4: port 0x8f00-0x8f7f mem 0xef6ff000-0xef6ff07f,0xef6f8000-0xef6fbfff irq 16 at device 0.0 on pci6 Aug 14 19:56:52 kernel: atapci4: [ITHREAD] Aug 14 19:56:52 kernel: ata8: on atapci4 Aug 14 19:56:52 kernel: ata8: [ITHREAD] Aug 14 19:56:52 kernel: ata9: on atapci4 Aug 14 19:56:52 kernel: ata9: [ITHREAD] Aug 14 19:56:52 kernel: pcib7: at device 23.0 on pci0 Aug 14 19:56:52 kernel: pci7: on pcib7 Aug 14 19:56:52 kernel: pcib8: at device 24.0 on pci0 Aug 14 19:56:52 kernel: pci8: on pcib8 Aug 14 19:56:52 kernel: acpi_tz0: on acpi0 Aug 14 19:56:52 kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Aug 14 19:56:52 kernel: fdc0: [FILTER] Aug 14 19:56:52 kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Aug 14 19:56:52 kernel: pmtimer0 on isa0 Aug 14 19:56:52 kernel: orm0: at iomem 0xd0000-0xd3fff pnpid ORM0000 on isa0 Aug 14 19:56:52 kernel: atkbdc0: at port 0x60,0x64 on isa0 Aug 14 19:56:52 kernel: atkbd0: irq 1 on atkbdc0 Aug 14 19:56:52 kernel: kbd0 at atkbd0 Aug 14 19:56:52 kernel: atkbd0: [GIANT-LOCKED] Aug 14 19:56:52 kernel: atkbd0: [ITHREAD] Aug 14 19:56:52 kernel: ppc0: parallel port not found. Aug 14 19:56:52 kernel: sc0: at flags 0x100 on isa0 Aug 14 19:56:52 kernel: sc0: VGA <16 virtual consoles, flags=0x300> Aug 14 19:56:52 kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Aug 14 19:56:52 kernel: sio0: port may not be enabled Aug 14 19:56:52 kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Aug 14 19:56:52 kernel: sio0: port may not be enabled Aug 14 19:56:52 kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Aug 14 19:56:52 kernel: sio0: type 8250 or not responding Aug 14 19:56:52 kernel: sio0: [FILTER] Aug 14 19:56:52 kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Aug 14 19:56:52 kernel: sio1: port may not be enabled Aug 14 19:56:52 kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Aug 14 19:56:52 kernel: uhub2: on uhub0 Aug 14 19:56:52 kernel: uhub2: 4 ports with 2 removable, bus powered Aug 14 19:56:52 kernel: ukbd0: on uhub2 Aug 14 19:56:52 kernel: kbd2 at ukbd0 Aug 14 19:56:52 kernel: uhid0: on uhub2 Aug 14 19:56:52 kernel: uhid1: on uhub2 Aug 14 19:56:52 kernel: ums0: on uhub0 Aug 14 19:56:52 kernel: ums0: 8 buttons and Z dir. Aug 14 19:56:52 kernel: Timecounters tick every 1.000 msec Aug 14 19:56:52 kernel: firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) Aug 14 19:56:52 kernel: firewire0: bus manager 0 (me) Aug 14 19:56:52 kernel: acd0: DVDR at ata0-master UDMA66 Aug 14 19:56:52 kernel: acd1: CDRW at ata0-slave UDMA33 Aug 14 19:56:52 kernel: ad4: 152627MB at ata2-master SATA300 Aug 14 19:56:52 kernel: ad6: 152627MB at ata3-master SATA300 Aug 14 19:56:52 kernel: ad8: 152627MB at ata4-master SATA300 Aug 14 19:56:52 kernel: SMP: AP CPU #1 Launched! Aug 14 19:56:52 kernel: WARNING: WITNESS option enabled, expect reduced performance. Aug 14 19:56:52 kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Aug 14 19:56:52 kernel: da0: Removable Direct Access SCSI-0 device Aug 14 19:56:52 kernel: da0: 40.000MB/s transfers Aug 14 19:56:52 kernel: da0: Attempt to query device size failed: NOT READY, Medium not present Aug 14 19:56:52 kernel: da1 at umass-sim0 bus 0 target 0 lun 1 Aug 14 19:56:52 kernel: da1: Removable Direct Access SCSI-0 device Aug 14 19:56:52 kernel: da1: 40.000MB/s transfers Aug 14 19:56:52 kernel: da1: Attempt to query device size failed: NOT READY, Medium not present Aug 14 19:56:52 kernel: da2 at umass-sim0 bus 0 target 0 lun 2 Aug 14 19:56:52 kernel: da2: Removable Direct Access SCSI-0 device Aug 14 19:56:52 kernel: da2: 40.000MB/s transfers Aug 14 19:56:52 kernel: da2: Attempt to query device size failed: NOT READY, Medium not present Aug 14 19:56:52 kernel: da3 at umass-sim0 bus 0 target 0 lun 3 Aug 14 19:56:52 kernel: da3: Removable Direct Access SCSI-0 device Aug 14 19:56:52 kernel: da3: 40.000MB/s transfers Aug 14 19:56:52 kernel: da3: Attempt to query device size failed: NOT READY, Medium not present Aug 14 19:56:52 kernel: Trying to mount root from ufs:/dev/ad8s1a Aug 14 19:56:53 savecore: no dumps found Aug 14 19:57:05 login: ROOT LOGIN (root) ON ttyv0 Aug 14 19:57:21 kernel: nfe0: link state changed to DOWN Aug 14 19:59:58 syslogd: kernel boot file is /boot/kernel/kernel Aug 14 19:59:58 kernel: Copyright (c) 1992-2007 The FreeBSD Project. Aug 14 19:59:58 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Aug 14 19:59:58 kernel: The Regents of the University of California. All rights reserved. Aug 14 19:59:58 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Aug 14 19:59:58 kernel: FreeBSD 7.0-20070814-SNAP #0: Tue Aug 14 10:20:29 UTC 2007 Aug 14 19:59:58 kernel: root@builder.snapshots.us.freebsd.org :/usr/obj/usr/src/sys/GENERIC Aug 14 19:59:58 kernel: WARNING: WITNESS option enabled, expect reduced performance. Aug 14 19:59:58 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Aug 14 19:59:58 kernel: CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (2138.26-MHz 686-class CPU) Aug 14 19:59:58 kernel: Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Aug 14 19:59:58 kernel: Features=0xbfebfbff Aug 14 19:59:58 kernel: Features2=0xe3bd Aug 14 19:59:58 kernel: AMD Features=0x20100000 Aug 14 19:59:58 kernel: AMD Features2=0x1 Aug 14 19:59:58 kernel: Cores per package: 2 Aug 14 19:59:58 kernel: real memory = 2146369536 (2046 MB) Aug 14 19:59:58 kernel: avail memory = 2090835968 (1993 MB) Aug 14 19:59:58 kernel: ACPI APIC Table: Aug 14 19:59:58 kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Aug 14 19:59:58 kernel: cpu0 (BSP): APIC ID: 0 Aug 14 19:59:58 kernel: cpu1 (AP): APIC ID: 1 Aug 14 19:59:58 kernel: ioapic0: Changing APIC ID to 4 Aug 14 19:59:58 kernel: ioapic0 irqs 0-23 on motherboard Aug 14 19:59:58 kernel: kbd1 at kbdmux0 Aug 14 19:59:58 kernel: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) Aug 14 19:59:58 kernel: acpi0: on motherboard Aug 14 19:59:58 kernel: acpi0: [ITHREAD] Aug 14 19:59:58 kernel: acpi_hpet0: iomem 0xfeff0000-0xfeff03ff on acpi0 Aug 14 19:59:58 kernel: Timecounter "HPET" frequency 25000000 Hz quality 900 Aug 14 19:59:58 kernel: acpi0: Power Button (fixed) Aug 14 19:59:58 kernel: acpi0: reservation of feff0000, 400 (3) failed Aug 14 19:59:58 kernel: acpi0: reservation of 0, a0000 (3) failed Aug 14 19:59:58 kernel: acpi0: reservation of 100000, 7fdf0000 (3) failed Aug 14 19:59:58 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Aug 14 19:59:58 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 Aug 14 19:59:58 kernel: cpu0: on acpi0 Aug 14 19:59:58 kernel: est0: on cpu0 Aug 14 19:59:58 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Aug 14 19:59:58 kernel: est: cpu_vendor GenuineIntel, msr 828082806000828 Aug 14 19:59:58 kernel: device_attach: est0 attach returned 6 Aug 14 19:59:58 kernel: p4tcc0: on cpu0 Aug 14 19:59:58 kernel: cpu1: on acpi0 Aug 14 19:59:58 kernel: est1: on cpu1 Aug 14 19:59:58 kernel: est: CPU supports Enhanced Speedstep, but is not recognized. Aug 14 19:59:58 kernel: est: cpu_vendor GenuineIntel, msr 828082806000828 Aug 14 19:59:58 kernel: device_attach: est1 attach returned 6 Aug 14 19:59:58 kernel: p4tcc1: on cpu1 Aug 14 19:59:58 kernel: acpi_button0: on acpi0 Aug 14 19:59:58 kernel: pcib0: port 0xcf8-0xcff on acpi0 Aug 14 19:59:58 kernel: pci0: on pcib0 Aug 14 19:59:58 kernel: pci0: at device 0.1 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 0.2 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 0.3 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 0.4 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 0.5 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 0.6 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 0.7 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 1.0 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 1.1 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 1.2 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 1.3 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 1.4 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 1.5 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 1.6 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 2.0 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 2.1 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 2.2 (no driver attached) Aug 14 19:59:58 kernel: pcib1: at device 3.0 on pci0 Aug 14 19:59:58 kernel: pci1: on pcib1 Aug 14 19:59:58 kernel: vgapci0: port 0xdf00-0xdf7f mem 0xec000000-0xecffffff,0xd0000000-0xdfffffff,0xea000000-0xebffffff irq 16 at device 0.0 on pci1 Aug 14 19:59:58 kernel: pci0: at device 9.0 (no driver attached) Aug 14 19:59:58 kernel: isab0: at device 10.0 on pci0 Aug 14 19:59:58 kernel: isa0: on isab0 Aug 14 19:59:58 kernel: pci0: at device 10.1 (no driver attached) Aug 14 19:59:58 kernel: pci0: at device 10.2 (no driver attached) Aug 14 19:59:58 kernel: ohci0: mem 0xeffff000-0xefffffff irq 21 at device 11.0 on pci0 Aug 14 19:59:58 kernel: ohci0: [GIANT-LOCKED] Aug 14 19:59:58 kernel: ohci0: [ITHREAD] Aug 14 19:59:58 kernel: usb0: OHCI version 1.0, legacy support Aug 14 19:59:58 kernel: usb0: SMM does not respond, resetting Aug 14 19:59:58 kernel: usb0: on ohci0 Aug 14 19:59:58 kernel: usb0: USB revision 1.0 Aug 14 19:59:58 kernel: uhub0: on usb0 Aug 14 19:59:58 kernel: uhub0: 10 ports with 10 removable, self powered Aug 14 19:59:58 kernel: ehci0: mem 0xefffe000-0xefffe0ff irq 22 at device 11.1 on pci0 Aug 14 19:59:58 kernel: ehci0: [GIANT-LOCKED] Aug 14 19:59:58 kernel: ehci0: [ITHREAD] Aug 14 19:59:58 kernel: usb1: EHCI version 1.0 Aug 14 19:59:58 kernel: usb1: companion controller, 10 ports each: usb0 Aug 14 19:59:58 kernel: usb1: on ehci0 Aug 14 19:59:58 kernel: usb1: USB revision 2.0 Aug 14 19:59:58 kernel: uhub1: on usb1 Aug 14 19:59:58 kernel: uhub1: 10 ports with 10 removable, self powered Aug 14 19:59:58 kernel: umass0: on uhub1 Aug 14 19:59:58 kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 13.0 on pci0 Aug 14 19:59:58 kernel: ata0: on atapci0 Aug 14 19:59:58 kernel: ata0: [ITHREAD] Aug 14 19:59:58 kernel: ata1: on atapci0 Aug 14 19:59:58 kernel: ata1: [ITHREAD] Aug 14 19:59:58 kernel: atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf700-0xf70f mem 0xefffd000-0xefffdfff irq 23 at device 14.0 on pci0 Aug 14 19:59:58 kernel: atapci1: [ITHREAD] Aug 14 19:59:58 kernel: ata2: on atapci1 Aug 14 19:59:58 kernel: ata2: [ITHREAD] Aug 14 19:59:58 kernel: ata3: on atapci1 Aug 14 19:59:58 kernel: ata3: [ITHREAD] Aug 14 19:59:58 kernel: atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf200-0xf20f mem 0xefffc000-0xefffcfff irq 20 at device 14.1 on pci0 Aug 14 19:59:58 kernel: atapci2: [ITHREAD] Aug 14 19:59:58 kernel: ata4: on atapci2 Aug 14 19:59:58 kernel: ata4: [ITHREAD] Aug 14 19:59:58 kernel: ata5: on atapci2 Aug 14 19:59:58 kernel: ata5: [ITHREAD] Aug 14 19:59:58 kernel: atapci3: port 0xf100-0xf107,0xf000-0xf003,0xef00-0xef07,0xee00-0xee03,0xed00-0xed0f mem 0xefffb000-0xefffbfff irq 21 at device 14.2 on pci0 Aug 14 19:59:58 kernel: atapci3: [ITHREAD] Aug 14 19:59:58 kernel: ata6: on atapci3 Aug 14 19:59:58 kernel: ata6: [ITHREAD] Aug 14 19:59:58 kernel: ata7: on atapci3 Aug 14 19:59:58 kernel: ata7: [ITHREAD] Aug 14 19:59:58 kernel: pcib2: at device 15.0 on pci0 Aug 14 19:59:58 kernel: pci2: on pcib2 Aug 14 19:59:58 kernel: fwohci0: port 0xcf00-0xcf7f mem 0xefdff000-0xefdff7ff irq 19 at device 11.0 on pci2 Aug 14 19:59:58 kernel: fwohci0: [FILTER] Aug 14 19:59:58 kernel: fwohci0: OHCI version 1.10 (ROM=1) Aug 14 19:59:58 kernel: fwohci0: No. of Isochronous channels is 4. Aug 14 19:59:58 kernel: fwohci0: EUI64 00:11:d8:00:01:1e:3d:ab Aug 14 19:59:58 kernel: fwohci0: Phy 1394a available S400, 2 ports. Aug 14 19:59:58 kernel: fwohci0: Link S400, max_rec 2048 bytes. Aug 14 19:59:58 kernel: firewire0: on fwohci0 Aug 14 19:59:58 kernel: fwe0: on firewire0 Aug 14 19:59:58 kernel: if_fwe0: Fake Ethernet address: 02:11:d8:1e:3d:ab Aug 14 19:59:58 kernel: fwe0: Ethernet address: 02:11:d8:1e:3d:ab Aug 14 19:59:58 kernel: fwip0: on firewire0 Aug 14 19:59:58 kernel: fwip0: Firewire address: 00:11:d8:00:01:1e:3d:ab @ 0xfffe00000000, S400, maxrec 2048 Aug 14 19:59:58 kernel: sbp0: on firewire0 Aug 14 19:59:58 kernel: dcons_crom0: on firewire0 Aug 14 19:59:58 kernel: dcons_crom0: bus_addr 0x7d864000 Aug 14 19:59:58 kernel: fwohci0: Initiate bus reset Aug 14 19:59:58 kernel: fwohci0: BUS reset Aug 14 19:59:58 kernel: fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode Aug 14 19:59:58 kernel: pci0: at device 15.1 (no driver attached) Aug 14 19:59:58 kernel: nfe0: port 0xec00-0xec07 mem 0xefffa000-0xefffafff,0xefff9000-0xefff90ff,0xefff8000-0xefff800f irq 23 at device 17.0 on pci0 Aug 14 19:59:58 kernel: miibus0: on nfe0 Aug 14 19:59:58 kernel: e1000phy0: PHY 19 on miibus0 Aug 14 19:59:58 kernel: e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto Aug 14 19:59:58 kernel: nfe0: Ethernet address: 00:1a:92:46:e0:44 Aug 14 19:59:58 kernel: nfe0: [FILTER] Aug 14 19:59:58 last message repeated 7 times Aug 14 19:59:58 kernel: nfe1: port 0xeb00-0xeb07 mem 0xefff7000-0xefff7fff,0xefff6000-0xefff60ff,0xefff5000-0xefff500f irq 20 at device 18.0 on pci0 Aug 14 19:59:58 kernel: miibus1: on nfe1 Aug 14 19:59:58 kernel: e1000phy1: PHY 1 on miibus1 Aug 14 19:59:58 kernel: e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto Aug 14 19:59:58 kernel: nfe1: Ethernet address: 00:1a:92:46:ed:f7 Aug 14 19:59:58 kernel: nfe1: [FILTER] Aug 14 19:59:58 last message repeated 7 times Aug 14 19:59:58 kernel: pcib3: at device 19.0 on pci0 Aug 14 19:59:58 kernel: pci3: on pcib3 Aug 14 19:59:58 kernel: pcib4: at device 20.0 on pci0 Aug 14 19:59:58 kernel: pci4: on pcib4 Aug 14 19:59:58 kernel: pcib5: at device 21.0 on pci0 Aug 14 19:59:58 kernel: pci5: on pcib5 Aug 14 19:59:58 kernel: pcib6: at device 22.0 on pci0 Aug 14 19:59:58 kernel: pci6: on pcib6 Aug 14 19:59:58 kernel: atapci4: port 0x8f00-0x8f7f mem 0xef6ff000-0xef6ff07f,0xef6f8000-0xef6fbfff irq 16 at device 0.0 on pci6 Aug 14 19:59:58 kernel: atapci4: [ITHREAD] Aug 14 19:59:58 kernel: ata8: on atapci4 Aug 14 19:59:58 kernel: ata8: [ITHREAD] Aug 14 19:59:58 kernel: ata9: on atapci4 Aug 14 19:59:58 kernel: ata9: [ITHREAD] Aug 14 19:59:58 kernel: pcib7: at device 23.0 on pci0 Aug 14 19:59:58 kernel: pci7: on pcib7 Aug 14 19:59:58 kernel: pcib8: at device 24.0 on pci0 Aug 14 19:59:58 kernel: pci8: on pcib8 Aug 14 19:59:58 kernel: acpi_tz0: on acpi0 Aug 14 19:59:58 kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Aug 14 19:59:58 kernel: fdc0: [FILTER] Aug 14 19:59:58 kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Aug 14 19:59:58 kernel: pmtimer0 on isa0 Aug 14 19:59:58 kernel: orm0: at iomem 0xd0000-0xd3fff pnpid ORM0000 on isa0 Aug 14 19:59:58 kernel: atkbdc0: at port 0x60,0x64 on isa0 Aug 14 19:59:58 kernel: atkbd0: irq 1 on atkbdc0 Aug 14 19:59:58 kernel: kbd0 at atkbd0 Aug 14 19:59:58 kernel: atkbd0: [GIANT-LOCKED] Aug 14 19:59:58 kernel: atkbd0: [ITHREAD] Aug 14 19:59:58 kernel: ppc0: parallel port not found. Aug 14 19:59:58 kernel: sc0: at flags 0x100 on isa0 Aug 14 19:59:58 kernel: sc0: VGA <16 virtual consoles, flags=0x300> Aug 14 19:59:58 kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Aug 14 19:59:58 kernel: sio0: port may not be enabled Aug 14 19:59:58 kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Aug 14 19:59:58 kernel: sio0: port may not be enabled Aug 14 19:59:58 kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Aug 14 19:59:58 kernel: sio0: type 8250 or not responding Aug 14 19:59:58 kernel: sio0: [FILTER] Aug 14 19:59:58 kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Aug 14 19:59:58 kernel: sio1: port may not be enabled Aug 14 19:59:58 kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Aug 14 19:59:58 kernel: uhub2: on uhub0 Aug 14 19:59:58 kernel: uhub2: 4 ports with 2 removable, bus powered Aug 14 19:59:58 kernel: ukbd0: on uhub2 Aug 14 19:59:58 kernel: kbd2 at ukbd0 Aug 14 19:59:58 kernel: uhid0: on uhub2 Aug 14 19:59:58 kernel: uhid1: on uhub2 Aug 14 19:59:58 kernel: ums0: on uhub0 Aug 14 19:59:58 kernel: ums0: 8 buttons and Z dir. Aug 14 19:59:58 kernel: Timecounters tick every 1.000 msec Aug 14 19:59:58 kernel: firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) Aug 14 19:59:58 kernel: firewire0: bus manager 0 (me) Aug 14 19:59:58 kernel: acd0: DVDR at ata0-master UDMA66 Aug 14 19:59:58 kernel: acd1: CDRW at ata0-slave UDMA33 Aug 14 19:59:58 kernel: ad4: 152627MB at ata2-master SATA300 Aug 14 19:59:58 kernel: ad6: 152627MB at ata3-master SATA300 Aug 14 19:59:58 kernel: ad8: 152627MB at ata4-master SATA300 Aug 14 19:59:58 kernel: SMP: AP CPU #1 Launched! Aug 14 19:59:58 kernel: WARNING: WITNESS option enabled, expect reduced performance. Aug 14 19:59:58 kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Aug 14 19:59:58 kernel: da0: Removable Direct Access SCSI-0 device Aug 14 19:59:58 kernel: da0: 40.000MB/s transfers Aug 14 19:59:58 kernel: da0: Attempt to query device size failed: NOT READY, Medium not present Aug 14 19:59:58 kernel: da1 at umass-sim0 bus 0 target 0 lun 1 Aug 14 19:59:58 kernel: da1: Removable Direct Access SCSI-0 device Aug 14 19:59:58 kernel: da1: 40.000MB/s transfers Aug 14 19:59:58 kernel: da1: Attempt to query device size failed: NOT READY, Medium not present Aug 14 19:59:58 kernel: da2 at umass-sim0 bus 0 target 0 lun 2 Aug 14 19:59:58 kernel: da2: Removable Direct Access SCSI-0 device Aug 14 19:59:58 kernel: da2: 40.000MB/s transfers Aug 14 19:59:58 kernel: da2: Attempt to query device size failed: NOT READY, Medium not present Aug 14 19:59:58 kernel: da3 at umass-sim0 bus 0 target 0 lun 3 Aug 14 19:59:58 kernel: da3: Removable Direct Access SCSI-0 device Aug 14 19:59:58 kernel: da3: 40.000MB/s transfers Aug 14 19:59:58 kernel: da3: Attempt to query device size failed: NOT READY, Medium not present Aug 14 19:59:58 kernel: Trying to mount root from ufs:/dev/ad8s1a Aug 14 19:59:58 kernel: WARNING: / was not properly dismounted Aug 14 19:59:58 kernel: WARNING: /tmp was not properly dismounted Aug 14 19:59:58 kernel: /tmp: mount pending error: blocks 0 files 1 Aug 14 19:59:58 kernel: WARNING: /usr was not properly dismounted Aug 14 19:59:58 kernel: WARNING: /var was not properly dismounted Aug 14 19:59:58 kernel: /var: mount pending error: blocks 0 files 1 Aug 14 19:59:58 savecore: no dumps found Aug 14 20:00:22 login: ROOT LOGIN (root) ON ttyv0 Aug 14 20:01:00 fsck: /dev/ad8s1d: LINK COUNT DIR I=2 OWNER=root MODE=41777 Aug 14 20:01:00 fsck: /dev/ad8s1d: SIZE=512 MTIME=Aug 14 19:59 2007 COUNT 11 SHOULD BE 7 (ADJUSTED) Aug 14 20:01:00 fsck: /dev/ad8s1d: Reclaimed: 5 directories, 0 files, 4 fragments Aug 14 20:01:00 fsck: /dev/ad8s1d: 7 files, 6 used, 1522493 free (77 frags, 190302 blocks, 0.0% fragmentation) Aug 14 20:03:48 fsck: /dev/ad8s1f: 15237 files, 119648 used, 58298354 free (9682 frags, 7286084 blocks, 0.0% fragmentation) Aug 14 20:03:53 fsck: /dev/ad8s1e: INCORRECT BLOCK COUNT I=259074 (8 should be 4) (CORRECTED) Aug 14 20:03:53 fsck: /dev/ad8s1e: Reclaimed: 1 directories, 16 files, 17 fragments Aug 14 20:03:53 fsck: /dev/ad8s1e: 97 files, 123 used, 1522363 free (107 frags, 190282 blocks, 0.0% fragmentation) Aug 14 20:12:58 kernel: nfe0: link state changed to DOWN Sam Fourman Jr. On 8/11/07, Don Lewis wrote: > > On 11 Aug, Pyun YongHyeon wrote: > > On Sat, Aug 11, 2007 at 06:22:22PM +0900, To Don Lewis wrote: > > > On Fri, Aug 10, 2007 at 10:42:19PM -0700, Don Lewis wrote: > > > > I've a rather strange nfe(4) problem that appears to be > repeatable. I > > > > recently started running -CURRENT on a older socket 754 > motherboard with > > > > the nForce3 chipset. Initially, I was running an SMP kernel, but > I had > > > > problems with sporadic "nfe0: watchdog timeout (missed Tx > interrupts) -- > > > > recovering" problems that would intermittently cause the system to > lose > > > > network connectivity which it would recover from. The kernel was > very > > > > similar to GENERIC, with just the addition of "options > DEBUG_VFS_LOCKS" > > > > and the replacement of atapicd with atapicam. > > > > > > > > The nfe0 problem totally went away when I removed "options SMP" > and > > > > "device apic" from the kernel configuration, except under the > following > > > > very specific circumstances: > > > > > > > > A vncserver session using the GNOME desktop was started on > the > > > > system. > > > > > > > > There was no keyboard or mouse activity on the console for > an > > > > extended period of time, allowing the GNOME screen saver > to kick > > > > in and lock the screen. > > > > > > > > The system would run fine in this state for many hours, and would > accept > > > > incoming SMTP connections, etc. > > > > > > > > A remote vncclient makes a connection to the vncserver > session > > > > and the password was entired on the client. > > > > > > > > At this point the nfe0 interface would appear to go deaf. This > might > > > > happen before or slightly after the password dialog box appeared > for the > > > > vnc session. For a short while, the system would be able to > transmit > > > > TCP packets, ntp queries, etc., but it would not respond to any > incoming > > > > packets (ping, TCP connection requests, etc.). Eventually, the ARP > cache > > > > would time out and the only packets being transmitted would be ARP > > > > requests and the occasional UDP broadcast from the samba server > running > > > > on the machine. > > > > > > > > Pressing any key on the (PS/2) keyboard would instantly bring the > > > > network interface back to life. Examination of /var/log/messages > showed > > > > lots of "nfe0: watchdog timeout" messages for the entire time that > nfe0 > > > > was not listening to the network. > > > > > > > > I've had this problem happen twice. Both times were after an > extended > > > > period of console inactivity. An incoming vnc connection is not > > > > sufficient to trigger the problem if the console was recently > active, > > > > and even waiting for the GNOME screensaver to put the monitor in > DPMS > > > > power save mode before initiating the vnc connection does not > appear to > > > > be sufficient to trigger the problem. > > > > > > > > I believe that nfe0 was sharing an interrupt with one of the USB > ports > > > > when the kernel was compiled with "device apic", but it is not > sharing > > > > an interrupt without "device apic". > > > > > > > > Any thoughts on how to debug this problem? > > > > > > > > > > > > # vmstat -i > > > > interrupt total rate > > > > irq0: clk 41903449 1000 > > > > irq1: atkbd0 39034 0 > > > > irq3: ohci0 5 0 > > > > irq7: ppc0 2 0 > > > > irq8: rtc 5362802 127 > > > > irq9: ohci1 ahc0+ 1963559 46 > > > > irq10: nfe0+ 225593 5 > > > ^^ > > > You have nfe0+ which indicates vmstat had run out of room to > > > display somthing. I'm not sure but it's still sharing interrupt > > > with other device? > > > > It seems the interrupt is shared with atapci1. > > Which is unused ... > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 07:06:25 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09E3816A476 for ; Wed, 15 Aug 2007 07:06:25 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id BC08713C4DD for ; Wed, 15 Aug 2007 07:06:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2607701waf for ; Wed, 15 Aug 2007 00:06:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=GJQho4Urf8RaNON30juH+spPOwGz08ChLM0FR3pG6x44oyJJ/MKt6b/ypy0o1kXpjnZGk07Ix4Pb1e0fw6v7P3ef5L4cX/GVExTUs8ytS54d2ZV0rgO3uAcVXiCZBZrrRjbYsBzsGvOOL7ZeyEdUm2emW2mTkGaQA18SWA79YQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=DaS2CbpmdKN8pIMGZ2l1+TgokFxgP5NM2+5hs0hGo0/Njsm+Kk1ms7MvkvW3S6LnB3620+saDTk1Eg1ll3LbeVxf2IsIQtjQJOvFvyN0Hv5j/BacEWwKQWjD6aZrJw6wQurPwxMB7iBMKAJlGqYH7Oy2gDXXvceF8uXtx7GP2II= Received: by 10.114.80.4 with SMTP id d4mr228498wab.1187161584286; Wed, 15 Aug 2007 00:06:24 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id m40sm11670021wag.2007.08.15.00.06.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Aug 2007 00:06:13 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l7F762tc037647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2007 16:06:02 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l7F762up037646; Wed, 15 Aug 2007 16:06:02 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 15 Aug 2007 16:06:02 +0900 From: Pyun YongHyeon To: "Sam Fourman Jr." Message-ID: <20070815070602.GC36539@cdnetworks.co.kr> References: <20070811092626.GB22569@cdnetworks.co.kr> <200708110952.l7B9qp8C058494@gw.catspoiler.org> <11167f520708150000v614f78f5wcd5c4d3aca04211b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11167f520708150000v614f78f5wcd5c4d3aca04211b@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: Don Lewis , current@freebsd.org Subject: Re: bizarre nfe(4) problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 07:06:25 -0000 On Wed, Aug 15, 2007 at 02:00:51AM -0500, Sam Fourman Jr. wrote: > I am having weird nfe problems too, I tried to run -current today and I > loaded a snapshot and upon dhclient nfe0 my computer reboots > Show me the back trace info of the panic. > below is a dmesg(kinda it is actually a /var/log/messages file) from > -current keep in mind that I am running PCBSD 1.4 BETA (based on 6.2 with > nfe compiled in) and nfe is working like a champ. > > I would love to have any help or pointers > -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 08:34:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6CF816A417 for ; Wed, 15 Aug 2007 08:34:39 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4AE2013C442 for ; Wed, 15 Aug 2007 08:34:38 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l7F8NejN007627 for ; Wed, 15 Aug 2007 17:53:40 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Wed, 15 Aug 2007 18:04:32 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 18:04:31 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.1/8.14.1) with ESMTP id l7F8XULe011935 for ; Wed, 15 Aug 2007 16:33:30 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.1/8.14.1/Submit) id l7F8XUUu011934 for freebsd-current@freebsd.org; Wed, 15 Aug 2007 16:33:30 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 15 Aug 2007 16:33:30 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20070815083329.GB11649@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <46C2263F.4080607@cisco.com> <46C23C6C.5020202@elischer.org> <46C23FEF.5060407@cisco.com> <20070815022117.GL37961@bashibuzuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20070815022117.GL37961@bashibuzuk.net> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 15 Aug 2007 08:34:31.0967 (UTC) FILETIME=[1A2BD2F0:01C7DF17] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.0.1021-15362.002 X-TM-AS-Result: No-2.631300-0.000000-31 Content-Transfer-Encoding: 7bit Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 08:34:39 -0000 0n Tue, Aug 14, 2007 at 10:21:17PM -0400, Yann Berthier wrote: >On Tue, 14 Aug 2007, at 19:51, Randall Stewart wrote: > >> There are several places I have gone (rest areas in SD for >> example.. :-o) that block all but port 80. > > it was mentioned recently in another thread, but in case you missed > it: ssltunnel (in ports), creates a ppp over ssl tunnel, and even > sports ntlm auth (not supposing that that router company you are part > of uses isa, but may be handy on some customers' sites). Auth between > client and tunnel endpoint is cert based While we are at it, one can also use net/corkscrew/ to tunnel SSH over 80 and 443 :-) -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 10:50:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B72DB16A417 for ; Wed, 15 Aug 2007 10:50:38 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 210A813C458 for ; Wed, 15 Aug 2007 10:50:37 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l7FAdecM004079 for ; Wed, 15 Aug 2007 20:09:40 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Wed, 15 Aug 2007 20:20:31 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 20:20:31 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.1/8.14.1) with ESMTP id l7FAnT6R012587 for ; Wed, 15 Aug 2007 18:49:29 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.1/8.14.1/Submit) id l7FAnTck012586 for freebsd-current@freebsd.org; Wed, 15 Aug 2007 18:49:29 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 15 Aug 2007 18:49:29 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20070815104929.GJ11649@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20070812114017.GA93036@obelix.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20070812114017.GA93036@obelix.dsto.defence.gov.au> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 15 Aug 2007 10:50:31.0811 (UTC) FILETIME=[19D13530:01C7DF2A] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.0.1021-15362.002 X-TM-AS-Result: No-5.930100-0.000000-31 Content-Transfer-Encoding: 7bit Subject: Re: SEC:ULarger NGROUPS_MAX in CURRENT ? Ready for 7.0-R ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 10:50:38 -0000 Anyone ? rwatson@ ? 0n Sun, Aug 12, 2007 at 07:40:17PM +0800, Wilkinson, Alex wrote: >Hi all, > >According to the following post: >[http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-05/1086.html] > >Robert Watson has said there was work in the pipeline to increase NGROUPS_MAX to >hundreds and even thousands of groups. > >Does anyone know if this work got done ? Will be included in 7.0-R ? > >Robert ? > >Lots of us are hitting the maximum group limit of 16 and this is a painful >experience when authenticating FreeBSD against AD when users are in 30-60 groups >:( > > -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 10:28:01 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E78316A419 for ; Wed, 15 Aug 2007 10:28:01 +0000 (UTC) (envelope-from ivi@dhs.net.ru) Received: from atlant.asiamusic.ru (AsiaTrade-Orient.orient.net.ru [195.161.236.162]) by mx1.freebsd.org (Postfix) with ESMTP id 28B3513C45D for ; Wed, 15 Aug 2007 10:28:01 +0000 (UTC) (envelope-from ivi@dhs.net.ru) Received: from atlant.asiamusic.ru (localhost [127.0.0.1]) by atlant.asiamusic.ru (Postfix) with ESMTP id 828F61CC48 for ; Wed, 15 Aug 2007 18:57:34 +0900 (IRKST) Received: from topaz.dhs.net.ru (webmaster.asiamusic.lan [192.168.125.10]) by atlant.asiamusic.ru (Postfix) with ESMTP id 4B2D51CC44 for ; Wed, 15 Aug 2007 18:57:34 +0900 (IRKST) Message-ID: <46C2CE09.1060106@dhs.net.ru> Date: Wed, 15 Aug 2007 18:57:29 +0900 From: "Vyacheslav I. Ivanchenko" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.6) Gecko/20070810 SeaMonkey/1.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: 20070808170412.GA31196@eos.sc1.parodius.com Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Wed, 15 Aug 2007 11:17:46 +0000 Subject: Apache on Current Error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 10:28:01 -0000 http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/apache13/files/patch-ae From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 11:25:01 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D64CB16A419 for ; Wed, 15 Aug 2007 11:25:01 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by mx1.freebsd.org (Postfix) with ESMTP id 7068013C46A for ; Wed, 15 Aug 2007 11:25:01 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (dpm.xs4all.nl [213.84.11.61]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id l7FB8R5Y027511 for ; Wed, 15 Aug 2007 13:08:28 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 15 Aug 2007 13:08:32 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB19BC3D@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: delete-old Thread-Index: Acfaa+PgrjfiURSeThOT4mP+IVnbDQEv70ug From: "Johan Hendriks" To: X-Virus-Scanned: by XS4ALL Virus Scanner Subject: delete-old X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 11:25:01 -0000 When i do a make delete-old I get the following output. >>> Removing old files (only deletes safe to delete libs) >>> Old files = removed >>> Removing old directories = /usr/include/netgraph/bluetooth/include /usr/include/netgraph/bluetooth >>> Old directories removed To remove old libraries run '/usr/obj/usr/src/make.i386/make = delete-old-libs'. Nothing wrong but after a second buildworld and a make delete-old I get = the same output, so the directory's are recreated. My src.conf: WITHOUT_BLUETOOTH=3D yes WITHOUT_LPR=3D yes WITHOUT_I4B=3D yes WITHOUT_IPFILTER=3D yes WITHOUT_GAMES=3D yes WITHOUT_PROFILE=3D yes WITHOUT_SENDMAIL=3D yes WITHOUT_IPX=3D yes Regards, Johan No virus found in this outgoing message. Checked by AVG Free Edition.=20 Version: 7.5.476 / Virus Database: 269.11.19/953 - Release Date: = 14-8-2007 17:19 =20 From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 11:35:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B413516A419 for ; Wed, 15 Aug 2007 11:35:25 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from mail.itu.dk (pluto.itu.dk [130.226.142.18]) by mx1.freebsd.org (Postfix) with ESMTP id 25D7413C428 for ; Wed, 15 Aug 2007 11:35:22 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from localhost (unknown [10.0.0.3]) by mail.itu.dk (Postfix) with ESMTP id 2140832D219 for ; Wed, 15 Aug 2007 11:04:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at itu.dk Received: from superman.itu.dk ([130.226.142.5]) by localhost (daredevil.itu.dk [130.226.142.26]) (amavisd-new, port 10024) with ESMTP id ia7lLEYSIh8p for ; Wed, 15 Aug 2007 11:04:34 +0200 (CEST) Received: from wimac.littlebit.dk (unknown [85.233.238.191]) by superman.itu.dk (Postfix) with ESMTP id F01C39E17E for ; Wed, 15 Aug 2007 11:04:33 +0200 (CEST) Message-ID: <46C2C19D.9090700@cederstrand.dk> Date: Wed, 15 Aug 2007 11:04:29 +0200 From: Erik Cederstrand User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Feedback for performance tracker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 11:35:25 -0000 Hi! This autumn, we have decided to grab the Performance Tracker entry[1] from the project ideas page and give it a spin as a subject for our thesis at the IT University of Copenhagen. The tracker intends to fill a hole in the range of tinderboxes and automatic stress/regression tests that FreeBSD already has. The initial idea is to have a small collection of servers constantly performing benchmarks and publishing the results to a server with a web interface. Before we start coding, we'd like to ask a couple of questions: 1) Which benchmarks would you like to see being run? 2) Which tests do you perform regularly, which the tracker could automate? 3) Which features in the web interface would you find most helpful? Also, we'd greatly appreciate pointers to previous work in the area. We welcome all comments and suggestions, but please bear in mind that we only have around 3 months full-time to develop the tracker. Thanks for your time, Anthony Liberto and Erik Cederstrand [1] http://www.freebsd.org/projects/ideas/#p-performancetracking From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 12:03:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67ACB16A47B for ; Wed, 15 Aug 2007 12:03:50 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 3B90113C4B6 for ; Wed, 15 Aug 2007 12:03:50 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from proton.local (209-163-168-124.static.twtelecom.net [209.163.168.124]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l7FC3kBA025959; Wed, 15 Aug 2007 07:03:47 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46C2EBA4.8070808@freebsd.org> Date: Wed, 15 Aug 2007 07:03:48 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Erik Cederstrand References: <46C2C19D.9090700@cederstrand.dk> In-Reply-To: <46C2C19D.9090700@cederstrand.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: freebsd-current@freebsd.org Subject: Re: Feedback for performance tracker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 12:03:50 -0000 Erik Cederstrand wrote: > Hi! > > This autumn, we have decided to grab the Performance Tracker entry[1] > from the project ideas page and give it a spin as a subject for our > thesis at the IT University of Copenhagen. The tracker intends to fill a > hole in the range of tinderboxes and automatic stress/regression tests > that FreeBSD already has. > > The initial idea is to have a small collection of servers constantly > performing benchmarks and publishing the results to a server with a web > interface. > > Before we start coding, we'd like to ask a couple of questions: > > 1) Which benchmarks would you like to see being run? - A database benchmark (multithreaded) - File system benchmarks (IOzone, postmark, bonnie++) - Network performance benchmark (someone else can mention which ones) - Some kind of compiling test (buildworld for a specific release maybe?) - NFS server/client for a specific workset - USB throughput - Firewire throughput - 802.11 throughput (eek! Hey, it's a wishlist, right? :D ) > 2) Which tests do you perform regularly, which the tracker could automate? - database benchmarks - File system benchmarks (iozone and postmark) - NFS (see file system benchmarks) > 3) Which features in the web interface would you find most helpful? It would be great to be able to see the various recorded numbers based on release, and also based on time. So you can see the difference (a graph would be the best) between say March 1st and August 1st, and compare. It would also be nice if this setup was portable enough for developers to run part or all of this suite in their labs, so they can watch the performance numbers change (or not) depending on what they do, *before* they commit it. > Also, we'd greatly appreciate pointers to previous work in the area. > > We welcome all comments and suggestions, but please bear in mind that we > only have around 3 months full-time to develop the tracker. Sounds like a great project - good luck! Eric From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 13:13:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E073C16A417 for ; Wed, 15 Aug 2007 13:13:59 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 67F8B13C474 for ; Wed, 15 Aug 2007 13:13:59 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-34-175.lns10.adl2.internode.on.net [121.45.34.175]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id l7FDDt7B065282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2007 22:43:55 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 15 Aug 2007 22:43:52 +0930 User-Agent: KMail/1.9.7 References: <46C2263F.4080607@cisco.com> <20070815022117.GL37961@bashibuzuk.net> <20070815083329.GB11649@obelix.dsto.defence.gov.au> In-Reply-To: <20070815083329.GB11649@obelix.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1856427.7zuVrNNHtf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708152243.53372.doconnor@gsoft.com.au> X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 203.31.81.10 Cc: "Wilkinson, Alex" Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 13:14:00 -0000 --nextPart1856427.7zuVrNNHtf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 15 Aug 2007, Wilkinson, Alex wrote: > 0n Tue, Aug 14, 2007 at 10:21:17PM -0400, Yann Berthier wrote: > >On Tue, 14 Aug 2007, at 19:51, Randall Stewart wrote: > >> There are several places I have gone (rest areas in SD for > >> example.. :-o) that block all but port 80. > > > > it was mentioned recently in another thread, but in case you > > missed it: ssltunnel (in ports), creates a ppp over ssl tunnel, > > and even sports ntlm auth (not supposing that that router > > company you are part of uses isa, but may be handy on some > > customers' sites). Auth between client and tunnel endpoint is > > cert based > > While we are at it, one can also use net/corkscrew/ to tunnel SSH > over 80 and 443 :-) I haven't seen security/openvpn mentioned either. (It does tunnels over HTTPS and can use proxies) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1856427.7zuVrNNHtf Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGwvwR5ZPcIHs/zowRAu3DAKCb1arHWEu1Xwydzxp6YaDGTU4i7gCeKUpI JVyty8TyZQjtoKPHlvbQbd0= =d+uK -----END PGP SIGNATURE----- --nextPart1856427.7zuVrNNHtf-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 13:50:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84D3016A41A for ; Wed, 15 Aug 2007 13:50:54 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 39D6813C428 for ; Wed, 15 Aug 2007 13:50:54 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A573CA.dip.t-dialin.net [84.165.115.202]) by redbull.bpaserver.net (Postfix) with ESMTP id 9F7442E26B; Wed, 15 Aug 2007 15:50:48 +0200 (CEST) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 903C45B4926; Wed, 15 Aug 2007 15:50:45 +0200 (CEST) Date: Wed, 15 Aug 2007 15:50:48 +0200 From: Alexander Leidinger To: "Johan Hendriks" Message-ID: <20070815155048.101b31a7@deskjail> In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB19BC3D@w2003s01.double-l.local> References: <57200BF94E69E54880C9BB1AF714BBCB19BC3D@w2003s01.double-l.local> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: delete-old X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 13:50:54 -0000 Quoting "Johan Hendriks" (Wed, 15 Aug 2007 13:08:32 +0200): > When i do a make delete-old I get the following output. > > >>> Removing old files (only deletes safe to delete libs) >>> Old files removed >>> Removing old directories /usr/include/netgraph/bluetooth/include > /usr/include/netgraph/bluetooth > >>> Old directories removed > To remove old libraries run '/usr/obj/usr/src/make.i386/make delete-old-libs'. > > Nothing wrong but after a second buildworld and a make delete-old I get the same output, so the directory's are recreated. > > My src.conf: > > WITHOUT_BLUETOOTH= yes This means either the bluetooth entries in tools/build/mk/OptionalObsoleteFiles.inc are not right (bug in this file), or that those bluetooth directories should not be created when WITHOUT_BLUETOOTH is set (bug in the corresponding Makefile). Bye, Alexander. -- To criticize the incompetent is easy; it is more difficult to criticize the competent. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 13:56:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5699916A419 for ; Wed, 15 Aug 2007 13:56:46 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 042E413C46C for ; Wed, 15 Aug 2007 13:56:45 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A573CA.dip.t-dialin.net [84.165.115.202]) by redbull.bpaserver.net (Postfix) with ESMTP id 7D7932E26B; Wed, 15 Aug 2007 15:56:37 +0200 (CEST) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 7013F5B4926; Wed, 15 Aug 2007 15:56:34 +0200 (CEST) Date: Wed, 15 Aug 2007 15:56:36 +0200 From: Alexander Leidinger To: Erik Cederstrand Message-ID: <20070815155636.711dac62@deskjail> In-Reply-To: <46C2C19D.9090700@cederstrand.dk> References: <46C2C19D.9090700@cederstrand.dk> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.9, required 8, BAYES_00 -15.00, DKIM_POLICY_SIGNSOME 0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-current@freebsd.org, brooks@FreeBSD.org Subject: Re: Feedback for performance tracker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 13:56:46 -0000 Quoting Erik Cederstrand (Wed, 15 Aug 2007 11:04:29 +0200): > Hi! > > This autumn, we have decided to grab the Performance Tracker entry[1] > from the project ideas page and give it a spin as a subject for our > thesis at the IT University of Copenhagen. The tracker intends to fill a > hole in the range of tinderboxes and automatic stress/regression tests > that FreeBSD already has. If you are serious about it (as in 'we are about it'), tell me if you want to be added as a contact for this project on the ideas page. Additionally we can arrange access to the FreeBSD wiki (http://wiki.freebsd.org/) to have some official page about the development, if you want. Before _I_ help you out with those 2 things, _I_ request you to ask yourself if you care enough about it to inform us if you abandon the project (for whatever reasons... I don't care about the reason, I just want to make sure we don't have stale information regarding the project on the ideas list). You should also coordinate with Brooks (CCed), as he is listed as the technical contact for this entry. Bye, Alexander. -- Beauty and harmony are as necessary to you as the very breath of life. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 14:27:35 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1838C16A468 for ; Wed, 15 Aug 2007 14:27:35 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (unknown [IPv6:2001:5c0:8fff:fffe::214d]) by mx1.freebsd.org (Postfix) with ESMTP id CAA3A13C478 for ; Wed, 15 Aug 2007 14:27:34 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1ILJjd-0002E9-Uj; Wed, 15 Aug 2007 10:20:33 -0400 Date: Wed, 15 Aug 2007 10:20:33 -0400 From: Gary Palmer To: Alexander Leidinger Message-ID: <20070815142033.GA970@in-addr.com> Mail-Followup-To: Alexander Leidinger , Johan Hendriks , freebsd-current@freebsd.org References: <57200BF94E69E54880C9BB1AF714BBCB19BC3D@w2003s01.double-l.local> <20070815155048.101b31a7@deskjail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070815155048.101b31a7@deskjail> Cc: Johan Hendriks , freebsd-current@freebsd.org Subject: Re: delete-old X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 14:27:35 -0000 On Wed, Aug 15, 2007 at 03:50:48PM +0200, Alexander Leidinger wrote: > Quoting "Johan Hendriks" (Wed, 15 Aug 2007 13:08:32 +0200): > > > When i do a make delete-old I get the following output. > > > > >>> Removing old files (only deletes safe to delete libs) >>> Old files removed >>> Removing old directories /usr/include/netgraph/bluetooth/include > > /usr/include/netgraph/bluetooth > > >>> Old directories removed > > To remove old libraries run '/usr/obj/usr/src/make.i386/make delete-old-libs'. > > > > Nothing wrong but after a second buildworld and a make delete-old I get the same output, so the directory's are recreated. > > > > My src.conf: > > > > WITHOUT_BLUETOOTH= yes > > This means either the bluetooth entries in > tools/build/mk/OptionalObsoleteFiles.inc are not right (bug in this > file), or that those bluetooth directories should not be created when > WITHOUT_BLUETOOTH is set (bug in the corresponding Makefile). The directories are made by mtree (check src/etc/mtree/BSD.include.dist) mtree doesn't know about the WITHOUT_ flags... From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 14:37:28 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E1DA16A419 for ; Wed, 15 Aug 2007 14:37:28 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 9D7C313C4A5 for ; Wed, 15 Aug 2007 14:37:27 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id 933E71B10EE7; Wed, 15 Aug 2007 16:37:26 +0200 (CEST) Received: from hater.cmotd.com (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 8DDF81B10EE0; Wed, 15 Aug 2007 16:37:26 +0200 (CEST) Message-ID: <46C30FA6.7060108@moneybookers.com> Date: Wed, 15 Aug 2007 17:37:26 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.4pre (X11/20070711) MIME-Version: 1.0 To: Kris Kennaway References: <20070806224112.GA21876@muon.bluestop.org> <20070807073920.GV50228@void.codelabs.ru> <46C18B60.8050400@moneybookers.com> <20070814145759.GB25169@void.codelabs.ru> <20070814193150.GA21553@rot26.obsecurity.org> In-Reply-To: <20070814193150.GA21553@rot26.obsecurity.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: current@freebsd.org Subject: Re: "tcpflags 0x18; tcp_do_segment" kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 14:37:28 -0000 Hello, Kris Kennaway wrote: > On Tue, Aug 14, 2007 at 06:57:59PM +0400, Eygene Ryabinkin wrote: > >> Stefan, good day. >> >> Tue, Aug 14, 2007 at 02:00:48PM +0300, Stefan Lambrev wrote: >> >>>> If you were running -CURRENT on the same machine prior to CVSupping, >>>> then you probably saw the 'Spurious RST' messages. They were >>>> provoked by the same situation. The messages themselves are harmless, >>>> >>>> >>> This is not harmless here :( >>> >> Yep, sorry. What I meant is that 'I had no problems with them' ;)) >> >> >>> I'm running current from today 14.Aug. >>> I use an network applications that hangs every time when I see such a message. >>> >>> Any ideas how can I debug, or help to someone who is familiar with the code ? >>> >> You can provide the tcpdump's raw dump of the session (sniffed with >> the -s 1500 or whatever MTU you have). This may sched some light. >> > > Now I have a tcpdump.out file and all packets are logged while this problem happened. Here is part of the file (I hope this is enough because the file itself is +150MB) : 16:09:30.747276 IP 192.168.13.7.50603 > 192.168.13.4.25: S 1951617849:1951617849(0) win 65535 16:09:30.747473 IP 192.168.13.4.25 > 192.168.13.7.50603: S 1766623039:1766623039(0) ack 1951617850 win 65535 16:09:30.747502 IP 192.168.13.7.50603 > 192.168.13.4.25: . ack 1 win 260 16:09:30.748936 IP 192.168.13.4.25 > 192.168.13.7.50603: P 1:48(47) ack 1 win 33304 16:09:30.749023 IP 192.168.13.7.50603 > 192.168.13.4.25: P 1:29(28) ack 48 win 260 16:09:30.749377 IP 192.168.13.4.25 > 192.168.13.7.50603: P 48:181(133) ack 29 win 33304 16:09:30.749490 IP 192.168.13.7.50603 > 192.168.13.4.25: P 29:70(41) ack 181 win 260 16:09:30.749817 IP 192.168.13.4.25 > 192.168.13.7.50603: P 181:195(14) ack 70 win 33304 16:09:30.749878 IP 192.168.13.7.50603 > 192.168.13.4.25: P 70:95(25) ack 195 win 260 16:09:30.751282 IP 192.168.13.4.25 > 192.168.13.7.50603: P 195:209(14) ack 95 win 33304 16:09:30.751377 IP 192.168.13.7.50603 > 192.168.13.4.25: P 95:101(6) ack 209 win 260 16:09:30.752015 IP 192.168.13.4.25 > 192.168.13.7.50603: P 209:246(37) ack 101 win 33304 16:09:30.752567 IP 192.168.13.7.50603 > 192.168.13.4.25: P 101:125(24) ack 246 win 260 16:09:30.753304 IP 192.168.13.7.50603 > 192.168.13.4.25: . 125:1573(1448) ack 246 win 260 16:09:30.753629 IP 192.168.13.4.25 > 192.168.13.7.50603: . ack 1573 win 32580 16:09:30.753647 IP 192.168.13.7.50603 > 192.168.13.4.25: P 1573:2590(1017) ack 246 win 260 16:09:30.754749 IP 192.168.13.7.50603 > 192.168.13.4.25: . 2590:4038(1448) ack 246 win 260 16:09:30.754946 IP 192.168.13.4.25 > 192.168.13.7.50603: . ack 4038 win 32580 16:09:30.754960 IP 192.168.13.7.50603 > 192.168.13.4.25: P 4038:4563(525) ack 246 win 260 16:09:30.755509 IP 192.168.13.7.50603 > 192.168.13.4.25: . 4563:6011(1448) ack 246 win 260 16:09:30.755681 IP 192.168.13.4.25 > 192.168.13.7.50603: . ack 6011 win 32580 16:09:30.755695 IP 192.168.13.7.50603 > 192.168.13.4.25: P 6011:6483(472) ack 246 win 260 16:09:30.756247 IP 192.168.13.7.50603 > 192.168.13.4.25: . 6483:7931(1448) ack 246 win 260 16:09:30.756418 IP 192.168.13.4.25 > 192.168.13.7.50603: . ack 7931 win 32580 16:09:30.756431 IP 192.168.13.7.50603 > 192.168.13.4.25: P 7931:8403(472) ack 246 win 260 16:09:30.757007 IP 192.168.13.7.50603 > 192.168.13.4.25: . 8403:9851(1448) ack 246 win 260 16:09:30.757151 IP 192.168.13.4.25 > 192.168.13.7.50603: . ack 9851 win 32580 16:09:30.757164 IP 192.168.13.7.50603 > 192.168.13.4.25: P 9851:10151(300) ack 246 win 260 16:09:30.757673 IP 192.168.13.7.50603 > 192.168.13.4.25: . 10151:11599(1448) ack 246 win 260 16:09:30.757886 IP 192.168.13.4.25 > 192.168.13.7.50603: . ack 11599 win 32580 16:09:30.757898 IP 192.168.13.7.50603 > 192.168.13.4.25: P 11599:12199(600) ack 246 win 260 16:09:30.758373 IP 192.168.13.7.50603 > 192.168.13.4.25: . 12199:13647(1448) ack 246 win 260 16:09:30.758620 IP 192.168.13.4.25 > 192.168.13.7.50603: . ack 13647 win 32580 16:09:30.758633 IP 192.168.13.7.50603 > 192.168.13.4.25: P 13647:14444(797) ack 246 win 260 16:09:30.758984 IP 192.168.13.7.50603 > 192.168.13.4.25: . 14444:15892(1448) ack 246 win 260 16:09:30.759208 IP 192.168.13.4.25 > 192.168.13.7.50603: . ack 15892 win 32580 16:09:30.759219 IP 192.168.13.7.50603 > 192.168.13.4.25: P 15892:16716(824) ack 246 win 260 16:09:30.759722 IP 192.168.13.7.50603 > 192.168.13.4.25: . 16716:18164(1448) ack 246 win 260 16:09:30.759941 IP 192.168.13.4.25 > 192.168.13.7.50603: . ack 18164 win 32580 16:09:30.759954 IP 192.168.13.7.50603 > 192.168.13.4.25: P 18164:18734(570) ack 246 win 260 16:09:30.760348 IP 192.168.13.7.50603 > 192.168.13.4.25: . 18734:20182(1448) ack 246 win 260 16:09:30.760530 IP 192.168.13.4.25 > 192.168.13.7.50603: . ack 20182 win 32580 16:09:30.760543 IP 192.168.13.7.50603 > 192.168.13.4.25: P 20182:20631(449) ack 246 win 260 16:09:30.761072 IP 192.168.13.7.50603 > 192.168.13.4.25: . 20631:22079(1448) ack 246 win 260 16:09:30.761259 IP 192.168.13.4.25 > 192.168.13.7.50603: . ack 22079 win 32580 16:09:30.761272 IP 192.168.13.7.50603 > 192.168.13.4.25: P 22079:22560(481) ack 246 win 260 16:09:30.761972 IP 192.168.13.7.50603 > 192.168.13.4.25: . 22560:24008(1448) ack 246 win 260 16:09:30.762139 IP 192.168.13.4.25 > 192.168.13.7.50603: . ack 24008 win 32580 16:09:30.762153 IP 192.168.13.7.50603 > 192.168.13.4.25: P 24008:24658(650) ack 246 win 260 16:09:30.862086 IP 192.168.13.4.25 > 192.168.13.7.50603: . ack 24658 win 33304 16:09:30.862098 IP 192.168.13.7.50603 > 192.168.13.4.25: P 24658:24847(189) ack 246 win 260 16:09:30.888262 IP 192.168.13.4.25 > 192.168.13.7.50603: P 246:283(37) ack 24847 win 33304 16:09:30.888512 IP 192.168.13.7.50603 > 192.168.13.4.25: P 24847:24853(6) ack 283 win 260 16:09:30.888995 IP 192.168.13.4.25 > 192.168.13.7.50603: P 283:298(15) ack 24853 win 33304 16:09:30.889055 IP 192.168.13.7.50603 > 192.168.13.4.25: F 24853:24853(0) ack 298 win 260 16:09:30.889151 IP 192.168.13.4.25 > 192.168.13.7.50603: F 298:298(0) ack 24853 win 33304 16:09:30.889290 IP 192.168.13.4.25 > 192.168.13.7.50603: F 298:298(0) ack 24854 win 33304 16:09:30.889309 IP 192.168.13.7.50603 > 192.168.13.4.25: . ack 299 win 260 connection closed and opened again ? 16:09:30.940328 IP 192.168.13.7.59206 > 192.168.13.4.25: S 823245446:823245446(0) win 65535 16:09:30.940624 IP 192.168.13.4.25 > 192.168.13.7.59206: S 823705952:823705952(0) ack 823245447 win 65535 16:09:30.940667 IP 192.168.13.7.59206 > 192.168.13.4.25: . ack 1 win 260 16:09:30.942087 IP 192.168.13.4.25 > 192.168.13.7.59206: P 1:48(47) ack 1 win 33304 16:09:30.942180 IP 192.168.13.7.59206 > 192.168.13.4.25: P 1:29(28) ack 48 win 260 16:09:30.942528 IP 192.168.13.4.25 > 192.168.13.7.59206: P 48:181(133) ack 29 win 33304 16:09:30.942646 IP 192.168.13.7.59206 > 192.168.13.4.25: P 29:70(41) ack 181 win 260 16:09:30.942822 IP 192.168.13.4.25 > 192.168.13.7.59206: P 181:195(14) ack 70 win 33304 16:09:30.942887 IP 192.168.13.7.59206 > 192.168.13.4.25: P 70:98(28) ack 195 win 260 16:09:30.944287 IP 192.168.13.4.25 > 192.168.13.7.59206: P 195:209(14) ack 98 win 33304 16:09:30.944377 IP 192.168.13.7.59206 > 192.168.13.4.25: P 98:104(6) ack 209 win 260 16:09:30.944729 IP 192.168.13.4.25 > 192.168.13.7.59206: P 209:246(37) ack 104 win 33304 16:09:30.945266 IP 192.168.13.7.59206 > 192.168.13.4.25: P 104:128(24) ack 246 win 260 16:09:30.946009 IP 192.168.13.7.59206 > 192.168.13.4.25: . 128:1576(1448) ack 246 win 260 16:09:30.946197 IP 192.168.13.4.25 > 192.168.13.7.59206: . ack 1576 win 32580 16:09:30.946214 IP 192.168.13.7.59206 > 192.168.13.4.25: P 1576:2077(501) ack 246 win 260 16:09:30.947241 IP 192.168.13.7.59206 > 192.168.13.4.25: . 2077:3525(1448) ack 246 win 260 16:09:30.947366 IP 192.168.13.4.25 > 192.168.13.7.59206: . ack 3525 win 32580 16:09:30.947379 IP 192.168.13.7.59206 > 192.168.13.4.25: P 3525:3857(332) ack 246 win 260 16:09:30.947932 IP 192.168.13.7.59206 > 192.168.13.4.25: . 3857:5305(1448) ack 246 win 260 16:09:30.948250 IP 192.168.13.4.25 > 192.168.13.7.59206: . ack 5305 win 32580 16:09:30.948265 IP 192.168.13.7.59206 > 192.168.13.4.25: P 5305:6197(892) ack 246 win 260 16:09:30.948824 IP 192.168.13.7.59206 > 192.168.13.4.25: . 6197:7645(1448) ack 246 win 260 16:09:30.948995 IP 192.168.13.4.25 > 192.168.13.7.59206: . ack 7645 win 32580 16:09:30.949008 IP 192.168.13.7.59206 > 192.168.13.4.25: P 7645:8117(472) ack 246 win 260 16:09:30.949655 IP 192.168.13.7.59206 > 192.168.13.4.25: . 8117:9565(1448) ack 246 win 260 16:09:30.949973 IP 192.168.13.4.25 > 192.168.13.7.59206: . ack 9565 win 32580 16:09:30.949985 IP 192.168.13.7.59206 > 192.168.13.4.25: P 9565:10448(883) ack 246 win 260 16:09:30.950469 IP 192.168.13.7.59206 > 192.168.13.4.25: . 10448:11896(1448) ack 246 win 260 16:09:30.950708 IP 192.168.13.4.25 > 192.168.13.7.59206: . ack 11896 win 32580 16:09:30.950721 IP 192.168.13.7.59206 > 192.168.13.4.25: P 11896:12522(626) ack 246 win 260 16:09:30.951144 IP 192.168.13.7.59206 > 192.168.13.4.25: . 12522:13970(1448) ack 246 win 260 16:09:30.951442 IP 192.168.13.4.25 > 192.168.13.7.59206: . ack 13970 win 32580 16:09:30.951455 IP 192.168.13.7.59206 > 192.168.13.4.25: P 13970:14837(867) ack 246 win 260 16:09:30.951753 IP 192.168.13.7.59206 > 192.168.13.4.25: . 14837:16285(1448) ack 246 win 260 16:09:30.951882 IP 192.168.13.4.25 > 192.168.13.7.59206: . ack 16285 win 32580 16:09:30.951893 IP 192.168.13.7.59206 > 192.168.13.4.25: P 16285:16672(387) ack 246 win 260 16:09:30.952396 IP 192.168.13.7.59206 > 192.168.13.4.25: . 16672:18120(1448) ack 246 win 260 16:09:30.952616 IP 192.168.13.4.25 > 192.168.13.7.59206: . ack 18120 win 32580 16:09:30.952641 IP 192.168.13.7.59206 > 192.168.13.4.25: P 18120:18690(570) ack 246 win 260 16:09:30.953033 IP 192.168.13.7.59206 > 192.168.13.4.25: . 18690:20138(1448) ack 246 win 260 16:09:30.953350 IP 192.168.13.4.25 > 192.168.13.7.59206: . ack 20138 win 32580 16:09:30.953364 IP 192.168.13.7.59206 > 192.168.13.4.25: P 20138:21062(924) ack 246 win 260 16:09:30.953865 IP 192.168.13.7.59206 > 192.168.13.4.25: . 21062:22510(1448) ack 246 win 260 16:09:30.954084 IP 192.168.13.4.25 > 192.168.13.7.59206: . ack 22510 win 32580 16:09:30.954099 IP 192.168.13.7.59206 > 192.168.13.4.25: P 22510:22779(269) ack 246 win 260 16:09:30.954703 IP 192.168.13.7.59206 > 192.168.13.4.25: . 22779:24227(1448) ack 246 win 260 16:09:30.954964 IP 192.168.13.4.25 > 192.168.13.7.59206: . ack 24227 win 32580 16:09:30.954976 IP 192.168.13.7.59206 > 192.168.13.4.25: P 24227:24855(628) ack 246 win 260 16:09:31.055138 IP 192.168.13.4.25 > 192.168.13.7.59206: . ack 24855 win 33304 16:09:31.055148 IP 192.168.13.7.59206 > 192.168.13.4.25: P 24855:24862(7) ack 246 win 260 16:09:31.080437 IP 192.168.13.4.25 > 192.168.13.7.59206: P 246:283(37) ack 24862 win 33304 16:09:31.080685 IP 192.168.13.7.59206 > 192.168.13.4.25: P 24862:24868(6) ack 283 win 260 16:09:31.081025 IP 192.168.13.4.25 > 192.168.13.7.59206: P 283:298(15) ack 24868 win 33304 16:09:31.081085 IP 192.168.13.7.59206 > 192.168.13.4.25: F 24868:24868(0) ack 298 win 260 16:09:31.081180 IP 192.168.13.4.25 > 192.168.13.7.59206: F 298:298(0) ack 24868 win 33304 16:09:31.081320 IP 192.168.13.4.25 > 192.168.13.7.59206: F 298:298(0) ack 24869 win 33304 16:09:31.081335 IP 192.168.13.7.59206 > 192.168.13.4.25: . ack 299 win 260 connection closed and opened again ? 16:10:13.206555 IP 192.168.13.7.60906 > 192.168.13.4.25: S 219272317:219272317(0) win 65535 16:10:13.206789 IP 192.168.13.4.25 > 192.168.13.7.60906: S 1948405606:1948405606(0) ack 219272318 win 65535 16:10:13.206824 IP 192.168.13.7.60906 > 192.168.13.4.25: . ack 1 win 260 16:10:13.208261 IP 192.168.13.4.25 > 192.168.13.7.60906: P 1:48(47) ack 1 win 33304 16:10:13.208347 IP 192.168.13.7.60906 > 192.168.13.4.25: P 1:21(20) ack 48 win 260 16:10:13.208690 IP 192.168.13.4.25 > 192.168.13.7.60906: P 48:74(26) ack 21 win 33304 16:10:13.208715 IP 192.168.13.7.60906 > 192.168.13.4.25: P 21:27(6) ack 74 win 260 16:10:13.208729 IP 192.168.13.7.60906 > 192.168.13.4.25: F 27:27(0) ack 74 win 260 Why the flag is 'F' here ? doesn't seems normal for me :) 16:10:13.208835 IP 192.168.13.4.25 > 192.168.13.7.60906: . ack 28 win 33301 16:10:13.208986 IP 192.168.13.4.25 > 192.168.13.7.60906: P 74:89(15) ack 28 win 33304 16:10:13.209069 IP 192.168.13.7.60906 > 192.168.13.4.25: R 219272345:219272345(0) win 0 16:10:13.209074 IP 192.168.13.4.25 > 192.168.13.7.60906: F 89:89(0) ack 28 win 33304 16:10:13.209079 IP 192.168.13.7.60906 > 192.168.13.4.25: R 219272345:219272345(0) win 0 application hangs at this point, no more packets captured. This is from /var/log/messages: Aug 15 16:10:13 mb7 kernel: TCP: [192.168.13.4]:25 to [192.168.13.7]:60906 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received data after socket was closed, sending RST and removing tcpcb -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 14:51:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C55716A41A for ; Wed, 15 Aug 2007 14:51:15 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from qsrv01ps.mx.bigpond.com (qsrv01ps.mx.bigpond.com [144.140.82.181]) by mx1.freebsd.org (Postfix) with ESMTP id 8353913C4EE for ; Wed, 15 Aug 2007 14:51:13 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from oaamta01ps.mx.bigpond.com ([124.188.162.95]) by omta05ps.mx.bigpond.com with ESMTP id <20070815122753.DMYU154.omta05ps.mx.bigpond.com@oaamta01ps.mx.bigpond.com> for ; Wed, 15 Aug 2007 12:27:53 +0000 Received: from areilly.bpa.nu ([124.188.162.95]) by oaamta01ps.mx.bigpond.com with ESMTP id <20070815122748.YKLG21704.oaamta01ps.mx.bigpond.com@areilly.bpa.nu> for ; Wed, 15 Aug 2007 12:27:48 +0000 Received: (qmail 63023 invoked by uid 501); 15 Aug 2007 12:27:47 -0000 Date: Wed, 15 Aug 2007 22:27:47 +1000 From: Andrew Reilly To: freebsd-current@freebsd.org Message-ID: <20070815122747.GA62123@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Does 7-CURRENT (aka cvsup tag=.) build under 6-STABLE? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 14:51:15 -0000 I ask because when I tried this on the weekend, on my ia32 crash-box-come-sound server, it died while trying to build csh. I didn't investigate deeply. Seemed that the include directories and what-not were pointing into the src directory, as expected. Src was nfs mounted, if that makes any difference (can't imagine so). Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 14:56:49 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC1F016A417 for ; Wed, 15 Aug 2007 14:56:49 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 880FC13C48A for ; Wed, 15 Aug 2007 14:56:49 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=Yt2XS9FL45ibNDiXA9QfG1neYR1gg8swSm8V+DfWjMZS+jJhnWU29kUuQSaftAhcJiAVOBCk34lJ/15eJiYr4jOkJLsgIfXp/TWWp/xiPuxiGUUyNSMsgtKso5DunR9pehsZwtgZAUTeUxonvimTWkWponrqpXBml/QUcKfvcpw=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1ILKIf-0009gZ-Dc; Wed, 15 Aug 2007 18:56:45 +0400 Date: Wed, 15 Aug 2007 18:56:40 +0400 From: Eygene Ryabinkin To: Stefan Lambrev Message-ID: <20070815145640.GQ988@void.codelabs.ru> References: <20070806224112.GA21876@muon.bluestop.org> <20070807073920.GV50228@void.codelabs.ru> <46C18B60.8050400@moneybookers.com> <20070814145759.GB25169@void.codelabs.ru> <20070814193150.GA21553@rot26.obsecurity.org> <46C30FA6.7060108@moneybookers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <46C30FA6.7060108@moneybookers.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.9 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_40 Cc: current@freebsd.org, Kris Kennaway Subject: Re: "tcpflags 0x18; tcp_do_segment" kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 14:56:49 -0000 Stefan, good day. Wed, Aug 15, 2007 at 05:37:26PM +0300, Stefan Lambrev wrote: > Now I have a tcpdump.out file and all packets are logged while this problem > happened. > Here is part of the file (I hope this is enough because the file itself is > +150MB) : > <... two connections that were closed are deleted ...> > 16:10:13.206555 IP 192.168.13.7.60906 > 192.168.13.4.25: S > 219272317:219272317(0) win 65535 108147619 0> > 16:10:13.206789 IP 192.168.13.4.25 > 192.168.13.7.60906: S > 1948405606:1948405606(0) ack 219272318 win 65535 1,nop,nop,timestamp 3042169350 108147619,sackOK,eol> > 16:10:13.206824 IP 192.168.13.7.60906 > 192.168.13.4.25: . ack 1 win 260 > > 16:10:13.208261 IP 192.168.13.4.25 > 192.168.13.7.60906: P 1:48(47) ack 1 win > 33304 > 16:10:13.208347 IP 192.168.13.7.60906 > 192.168.13.4.25: P 1:21(20) ack 48 win > 260 > 16:10:13.208690 IP 192.168.13.4.25 > 192.168.13.7.60906: P 48:74(26) ack 21 win > 33304 > 16:10:13.208715 IP 192.168.13.7.60906 > 192.168.13.4.25: P 21:27(6) ack 74 win > 260 > 16:10:13.208729 IP 192.168.13.7.60906 > 192.168.13.4.25: F 27:27(0) ack 74 win > 260 > > Why the flag is 'F' here ? doesn't seems normal for me :) > > 16:10:13.208835 IP 192.168.13.4.25 > 192.168.13.7.60906: . ack 28 win 33301 > > 16:10:13.208986 IP 192.168.13.4.25 > 192.168.13.7.60906: P 74:89(15) ack 28 win > 33304 > 16:10:13.209069 IP 192.168.13.7.60906 > 192.168.13.4.25: R > 219272345:219272345(0) win 0 > 16:10:13.209074 IP 192.168.13.4.25 > 192.168.13.7.60906: F 89:89(0) ack 28 win > 33304 > 16:10:13.209079 IP 192.168.13.7.60906 > 192.168.13.4.25: R > 219272345:219272345(0) win 0 It will be good to see SMTP protocol trace. If you have no sensitive data, then add '-s 1500 -X' to the tcpdump's options and show us the output. If you can upload the result or raw trace for the abovementioned three connections, it will be good. You can extract the sessions using something like (for the last session) 'tcpdump -s 1500 -r dump.out -w session.out host 192.168.13.7 and port 60906' Thank you. -- Eygene From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 15:12:56 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C5E316A469 for ; Wed, 15 Aug 2007 15:12:56 +0000 (UTC) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (gerbercreations.com [71.39.140.16]) by mx1.freebsd.org (Postfix) with ESMTP id BACE913C4D5 for ; Wed, 15 Aug 2007 15:12:55 +0000 (UTC) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.13.1/8.13.3) with ESMTP id l7FEm5cv005220; Wed, 15 Aug 2007 07:48:05 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.13.1/8.13.3/Submit) id l7FEm4Hp005219; Wed, 15 Aug 2007 07:48:04 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Wed, 15 Aug 2007 07:48:04 -0700 From: Greg Lewis To: Tobias Grosser Message-ID: <20070815144804.GC5151@misty.eyesbeyond.com> References: <1186303666.36623.23.camel@tobias.wg.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1186303666.36623.23.camel@tobias.wg.> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org, freebsd-java@freebsd.org Subject: Re: Gcc bugs break java/jdk15 build? [Workaround] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 15:12:56 -0000 On Sun, Aug 05, 2007 at 10:47:46AM +0200, Tobias Grosser wrote: > since the last gcc import (Update to 4.2) I had problems to compile > java/jdk15 (using linux-sun-jdk14/15 and diablo-jdk15), because often > the linux-sun-jdk crashed or I got the following errors: > > ../../../../../src/share/classes/sun/security/util/SignatureFileVerifier.java:22: cannot find symbol > symbol : class timestamp > location: package sun.security > import sun.security.timestamp.TimestampToken; > ^ Can you, and people with similar errors, try again after updating to a -CURRENT after the GCC 4.2.1 import. This should fix these errors but it would be great to get some confirmation. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 15:21:03 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87ED616A417 for ; Wed, 15 Aug 2007 15:21:03 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id C27BB13C45B for ; Wed, 15 Aug 2007 15:21:02 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id D19811B10ED2; Wed, 15 Aug 2007 17:21:01 +0200 (CEST) Received: from hater.cmotd.com (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id CC6A41B10EA4; Wed, 15 Aug 2007 17:21:01 +0200 (CEST) Message-ID: <46C319DD.3010806@moneybookers.com> Date: Wed, 15 Aug 2007 18:21:01 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.4pre (X11/20070711) MIME-Version: 1.0 To: Eygene Ryabinkin References: <20070806224112.GA21876@muon.bluestop.org> <20070807073920.GV50228@void.codelabs.ru> <46C18B60.8050400@moneybookers.com> <20070814145759.GB25169@void.codelabs.ru> <20070814193150.GA21553@rot26.obsecurity.org> <46C30FA6.7060108@moneybookers.com> <20070815145640.GQ988@void.codelabs.ru> In-Reply-To: <20070815145640.GQ988@void.codelabs.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: current@freebsd.org, Kris Kennaway Subject: Re: "tcpflags 0x18; tcp_do_segment" kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 15:21:03 -0000 Hello, Eygene Ryabinkin wrote: > Stefan, good day. > > Wed, Aug 15, 2007 at 05:37:26PM +0300, Stefan Lambrev wrote: > >> Now I have a tcpdump.out file and all packets are logged while this problem >> happened. >> Here is part of the file (I hope this is enough because the file itself is >> +150MB) : >> >> -cut- > It will be good to see SMTP protocol trace. If you have no sensitive > data, then add '-s 1500 -X' to the tcpdump's options and show us > the output. If you can upload the result or raw trace for the > abovementioned three connections, it will be good. You can extract > the sessions using something like (for the last session) > 'tcpdump -s 1500 -r dump.out -w session.out host 192.168.13.7 and port 60906' > > Thank you. > Here is the part that does not have anything sensible: 16:10:13.206555 IP mb7.intra.net.60906 > mb4.intra.net.smtp: S 219272317:219272317(0) win 65535 0x0000: 4500 003c 2747 4000 4006 0000 c0a8 0d07 E..<'G@.@....... 0x0010: c0a8 0d04 edea 0019 0d11 d47d 0000 0000 ...........}.... 0x0020: a002 ffff 9b8a 0000 0204 05b4 0103 0308 ................ 0x0030: 0402 080a 0672 33a3 0000 0000 .....r3..... 16:10:13.206789 IP mb4.intra.net.smtp > mb7.intra.net.60906: S 1948405606:1948405606(0) ack 219272318 win 65535 0x0000: 4500 0040 b86e 4000 4006 e6ed c0a8 0d04 E..@.n@.@....... 0x0010: c0a8 0d07 0019 edea 7422 4f66 0d11 d47e ........t"Of...~ 0x0020: b012 ffff 4709 0000 0204 05b4 0103 0301 ....G........... 0x0030: 0101 080a b553 d206 0672 33a3 0402 0000 .....S...r3..... 16:10:13.206824 IP mb7.intra.net.60906 > mb4.intra.net.smtp: . ack 1 win 260 0x0000: 4500 0034 2748 4000 4006 0000 c0a8 0d07 E..4'H@.@....... 0x0010: c0a8 0d04 edea 0019 0d11 d47e 7422 4f67 ...........~t"Og 0x0020: 8010 0104 9b82 0000 0101 080a 0672 33a4 .............r3. 0x0030: b553 d206 .S.. 16:10:13.208261 IP mb4.intra.net.smtp > mb7.intra.net.60906: P 1:48(47) ack 1 win 33304 0x0000: 4500 0063 b873 4000 4006 e6c5 c0a8 0d04 E..c.s@.@....... 0x0010: c0a8 0d07 0019 edea 7422 4f67 0d11 d47e ........t"Og...~ 0x0020: 8018 8218 fca6 0000 0101 080a b553 d207 .............S.. 0x0030: 0672 33a4 3232 3020 6d62 342e 6d6f 6e65 .r3.220.mb4.mone 0x0040: 7962 6f6f 6b65 7273 2e63 6f6d 2045 534d ybookers.com.ESM 0x0050: 5450 206d 6169 6c2d 6578 6368 616e 6765 TP.mail-exchange 0x0060: 720d 0a r.. 16:10:13.208347 IP mb7.intra.net.60906 > mb4.intra.net.smtp: P 1:21(20) ack 48 win 260 0x0000: 4500 0048 2749 4000 4006 0000 c0a8 0d07 E..H'I@.@....... 0x0010: c0a8 0d04 edea 0019 0d11 d47e 7422 4f96 ...........~t"O. 0x0020: 8018 0104 9b96 0000 0101 080a 0672 33a5 .............r3. 0x0030: b553 d207 4845 4c4f 206d 6237 2e69 6e74 .S..HELO.mb7.int 0x0040: 7261 2e6e 6574 0d0a ra.net.. 16:10:13.208690 IP mb4.intra.net.smtp > mb7.intra.net.60906: P 48:74(26) ack 21 win 33304 0x0000: 4500 004e b877 4000 4006 e6d6 c0a8 0d04 E..N.w@.@....... 0x0010: c0a8 0d07 0019 edea 7422 4f96 0d11 d492 ........t"O..... 0x0020: 8018 8218 b312 0000 0101 080a b553 d208 .............S.. 0x0030: 0672 33a5 3235 3020 6d62 342e 6d6f 6e65 .r3.250.mb4.mone 0x0040: 7962 6f6f 6b65 7273 2e63 6f6d 0d0a ybookers.com.. 16:10:13.208715 IP mb7.intra.net.60906 > mb4.intra.net.smtp: P 21:27(6) ack 74 win 260 0x0000: 4500 003a 274a 4000 4006 0000 c0a8 0d07 E..:'J@.@....... 0x0010: c0a8 0d04 edea 0019 0d11 d492 7422 4fb0 ............t"O. 0x0020: 8018 0104 9b88 0000 0101 080a 0672 33a5 .............r3. 0x0030: b553 d208 5155 4954 0d0a .S..QUIT.. I'm not sure why this QUIT is here. But I noticed that the app normaly use "quit" (small letters) May be the problem is in the application itself ? Anyway here are the rest of the packets (and one of them trigger the error msg) : 16:10:13.208729 IP mb7.intra.net.60906 > mb4.intra.net.smtp: F 27:27(0) ack 74 win 260 0x0000: 4500 0034 274b 4000 4006 0000 c0a8 0d07 E..4'K@.@....... 0x0010: c0a8 0d04 edea 0019 0d11 d498 7422 4fb0 ............t"O. 0x0020: 8011 0104 9b82 0000 0101 080a 0672 33a5 .............r3. 0x0030: b553 d208 .S.. 16:10:13.208835 IP mb4.intra.net.smtp > mb7.intra.net.60906: . ack 28 win 33301 0x0000: 4500 0034 b878 4000 4006 e6ef c0a8 0d04 E..4.x@.@....... 0x0010: c0a8 0d07 0019 edea 7422 4fb0 0d11 d499 ........t"O..... 0x0020: 8010 8215 0457 0000 0101 080a b553 d208 .....W.......S.. 0x0030: 0672 33a5 .r3. 16:10:13.208986 IP mb4.intra.net.smtp > mb7.intra.net.60906: P 74:89(15) ack 28 win 33304 0x0000: 4500 0043 b879 4000 4006 e6df c0a8 0d04 E..C.y@.@....... 0x0010: c0a8 0d07 0019 edea 7422 4fb0 0d11 d499 ........t"O..... 0x0020: 8018 8218 5ce7 0000 0101 080a b553 d208 ....\........S.. 0x0030: 0672 33a5 3232 3120 322e 302e 3020 4279 .r3.221.2.0.0.By 0x0040: 650d 0a e.. 16:10:13.209069 IP mb7.intra.net.60906 > mb4.intra.net.smtp: R 219272345:219272345(0) win 0 0x0000: 4500 0028 274c 4000 4006 0000 c0a8 0d07 E..('L@.@....... 0x0010: c0a8 0d04 edea 0019 0d11 d499 0000 0000 ................ 0x0020: 5004 0000 9b76 0000 0000 0000 0000 P....v........ 16:10:13.209074 IP mb4.intra.net.smtp > mb7.intra.net.60906: F 89:89(0) ack 28 win 33304 0x0000: 4500 0034 b87a 4000 4006 e6ed c0a8 0d04 E..4.z@.@....... 0x0010: c0a8 0d07 0019 edea 7422 4fbf 0d11 d499 ........t"O..... 0x0020: 8011 8218 0444 0000 0101 080a b553 d208 .....D.......S.. 0x0030: 0672 33a5 .r3. 16:10:13.209079 IP mb7.intra.net.60906 > mb4.intra.net.smtp: R 219272345:219272345(0) win 0 0x0000: 4500 0028 274d 4000 4006 0000 c0a8 0d07 E..('M@.@....... 0x0010: c0a8 0d04 edea 0019 0d11 d499 0000 0000 ................ 0x0020: 5004 0000 9b76 0000 0000 0000 0000 P....v........ And here is the normal end of the task (same socket used ~9 min earlier) : 16:01:20.298645 IP mb4.intra.net.smtp > mb7.intra.net.60906: P 246:283(37) ack 24881 win 33304 0x0000: 4500 0059 f4bc 4000 4006 aa86 c0a8 0d04 E..Y..@.@....... 0x0010: c0a8 0d07 0019 edea a76e cce8 ebc6 8f74 .........n.....t 0x0020: 8018 8218 3e15 0000 0101 080a b54b afe1 ....>........K.. 0x0030: 066a 1166 3235 3020 322e 302e 3020 4f6b .j.f250.2.0.0.Ok 0x0040: 3a20 7175 6575 6564 2061 7320 3546 4541 :.queued.as.5FEA 0x0050: 4532 3044 3539 430d 0a E20D59C.. 16:01:20.298900 IP mb7.intra.net.60906 > mb4.intra.net.smtp: P 24881:24887(6) ack 283 win 260 0x0000: 4500 003a d953 4000 4006 0000 c0a8 0d07 E..:.S@.@....... 0x0010: c0a8 0d04 edea 0019 ebc6 8f74 a76e cd0d ...........t.n.. 0x0020: 8018 0104 9b88 0000 0101 080a 066a 1180 .............j.. 0x0030: b54b afe1 7175 6974 0d0a .K..quit.. 16:01:20.299675 IP mb4.intra.net.smtp > mb7.intra.net.60906: P 283:298(15) ack 24887 win 33304 0x0000: 4500 0043 f4c2 4000 4006 aa96 c0a8 0d04 E..C..@.@....... 0x0010: c0a8 0d07 0019 edea a76e cd0d ebc6 8f7a .........n.....z 0x0020: 8018 8218 5702 0000 0101 080a b54b afe2 ....W........K.. 0x0030: 066a 1180 3232 3120 322e 302e 3020 4279 .j..221.2.0.0.By 0x0040: 650d 0a e.. 16:01:20.299688 IP mb4.intra.net.smtp > mb7.intra.net.60906: F 298:298(0) ack 24887 win 33304 0x0000: 4500 0034 f4c3 4000 4006 aaa4 c0a8 0d04 E..4..@.@....... 0x0010: c0a8 0d07 0019 edea a76e cd1c ebc6 8f7a .........n.....z 0x0020: 8011 8218 fe5e 0000 0101 080a b54b afe2 .....^.......K.. 0x0030: 066a 1180 .j.. 16:01:20.299700 IP mb7.intra.net.60906 > mb4.intra.net.smtp: . ack 299 win 260 0x0000: 4500 0034 d954 4000 4006 0000 c0a8 0d07 E..4.T@.@....... 0x0010: c0a8 0d04 edea 0019 ebc6 8f7a a76e cd1d ...........z.n.. 0x0020: 8010 0104 9b82 0000 0101 080a 066a 1181 .............j.. 0x0030: b54b afe2 .K.. 16:01:20.299746 IP mb7.intra.net.60906 > mb4.intra.net.smtp: F 24887:24887(0) ack 299 win 260 0x0000: 4500 0034 d955 4000 4006 0000 c0a8 0d07 E..4.U@.@....... 0x0010: c0a8 0d04 edea 0019 ebc6 8f7a a76e cd1d ...........z.n.. 0x0020: 8011 0104 9b82 0000 0101 080a 066a 1181 .............j.. 0x0030: b54b afe2 .K.. 16:01:20.299972 IP mb4.intra.net.smtp > mb7.intra.net.60906: . ack 24888 win 33303 0x0000: 4500 0034 f4c4 4000 4006 aaa3 c0a8 0d04 E..4..@.@....... 0x0010: c0a8 0d07 0019 edea a76e cd1d ebc6 8f7b .........n.....{ 0x0020: 8010 8217 fe5d 0000 0101 080a b54b afe2 .....].......K.. 0x0030: 066a 1181 .j.. -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 15:28:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D31B416A417 for ; Wed, 15 Aug 2007 15:28:13 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (vlk.vlakno.cz [62.168.28.247]) by mx1.freebsd.org (Postfix) with ESMTP id 8971713C4E3 for ; Wed, 15 Aug 2007 15:28:13 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 7115B8C0FE6; Wed, 15 Aug 2007 17:28:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (vlk.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aYEnj-tAdtB; Wed, 15 Aug 2007 17:28:08 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 1BD158C0FDE; Wed, 15 Aug 2007 17:28:08 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.13.8/8.13.8/Submit) id l7FFS7ss070111; Wed, 15 Aug 2007 17:28:07 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 15 Aug 2007 17:28:07 +0200 From: Roman Divacky To: Erik Cederstrand Message-ID: <20070815152807.GA69991@freebsd.org> References: <46C2C19D.9090700@cederstrand.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46C2C19D.9090700@cederstrand.dk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Feedback for performance tracker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 15:28:13 -0000 On Wed, Aug 15, 2007 at 11:04:29AM +0200, Erik Cederstrand wrote: > Hi! > > This autumn, we have decided to grab the Performance Tracker entry[1] > from the project ideas page and give it a spin as a subject for our > thesis at the IT University of Copenhagen. The tracker intends to fill a > hole in the range of tinderboxes and automatic stress/regression tests > that FreeBSD already has. > > The initial idea is to have a small collection of servers constantly > performing benchmarks and publishing the results to a server with a web > interface. great! > Before we start coding, we'd like to ask a couple of questions: > > 1) Which benchmarks would you like to see being run? what eric anderson pointed out + some microbenchmark like /usr/ports/benchmarks/libmicro > 3) Which features in the web interface would you find most helpful? I think something like this (the graphs) is excellent: http://people.redhat.com/dnovillo/spec2000.em64t/gcc/global-run-ratio.html From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 16:00:22 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B8C016A418; Wed, 15 Aug 2007 16:00:22 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id 0F56C13C45D; Wed, 15 Aug 2007 16:00:21 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP id l7FFxnKh028508 (8.13.4/1.4); Wed, 15 Aug 2007 17:59:49 +0200 (MEST) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP id l7FFxnLP028505 (8.13.4/2.02); Wed, 15 Aug 2007 17:59:49 +0200 (MEST) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Wed, 15 Aug 2007 17:59:49 +0200 (MEST) From: Michiel Boland To: Greg Lewis In-Reply-To: <20070815144804.GC5151@misty.eyesbeyond.com> Message-ID: References: <1186303666.36623.23.camel@tobias.wg.> <20070815144804.GC5151@misty.eyesbeyond.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-java@freebsd.org, Tobias Grosser , freebsd-current@freebsd.org Subject: Re: Gcc bugs break java/jdk15 build? [Workaround] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 16:00:22 -0000 Alas, java/jdk15 build breaks for me on i386 -CURRENT with gcc 4.2.1 (bootstrapped with diablo-jdk 1.5) The good news is perhaps that jdk15 builds ok on amd64 -CURRENT with diablo-jdk. But there the gcc version does not matter. That is, on amd64 I was already able to build jdk15, even with the 'old' gcc. Last fragment of the i386 build typescript follows. I trimmed some very long line down somewhat. Cheers Michiel gmake[5]: Leaving directory `/usr/ports/java/jdk15/work/j2se/make/sun/javac/javac' <<>>Recursively making recompile all @ Wed Aug 15 17:32:46 CEST 2007 ... gmake[5]: Entering directory `/usr/ports/java/jdk15/work/j2se/make/sun/javac/recompile' >>>Recursively making library all @ Wed Aug 15 17:32:46 CEST 2007 ... gmake[6]: Entering directory `/usr/ports/java/jdk15/work/j2se/make/sun/javac/recompile/library' gmake classes copy-classes VARIANT=OPT gmake[7]: Entering directory `/usr/ports/java/jdk15/work/j2se/make/sun/javac/recompile/library' /bin/mkdir -p /usr/ports/java/jdk15/work/control/build/bsd-i586/tmp/java/java.lang/obj /bin/mkdir -p /usr/ports/java/jdk15/work/control/build/bsd-i586/tmp/java/java.lang/library/newclasses rm -f /usr/ports/java/jdk15/work/control/build/bsd-i586/tmp/java/java.lang/.classes.list if [ -s /usr/ports/java/jdk15/work/control/build/bsd-i586/tmp/java/java.lang/.classes.list ] ; \ then /usr/ports/java/jdk15/work/control/build/bsd-i586/bin/javac -J-XX:ThreadStackSize=768 -J-Xms64m -J-Xmx256m -classpath "/usr/ports/java/jdk15/work/control/build/bsd-i586/tmp/java/java.lang/libra ../../../../../src/share/classes/java/lang/Object.java ../../../../../src/share/classes/java/lang/Class.java ../../../../../src/share/classes/java/lang/Thread.java ../../../../../src/share/classe fi ../../../../../src/share/classes/java/nio/Bits.java:19: duplicate class: Bits class Bits { // package-private ^ ../../../../../src/solaris/classes/sun/net/www/protocol/file/Handler.java:26: duplicate class: Handler public class Handler extends URLStreamHandler { ^ ../../../../../src/share/classes/java/lang/Class.java:10: cannot access java.lang.reflect.Array bad class file: ../../../../../src/share/classes/java/lang/reflect/Array.java file does not contain class java.lang.reflect.Array Please remove or make sure it appears in the correct subdirectory of the classpath. import java.lang.reflect.Array; ^ 3 errors gmake[7]: *** [.compile.classlist] Error 1 gmake[7]: Leaving directory `/usr/ports/java/jdk15/work/j2se/make/sun/javac/recompile/library' gmake[6]: *** [optimized] Error 2 gmake[6]: Leaving directory `/usr/ports/java/jdk15/work/j2se/make/sun/javac/recompile/library' gmake[5]: *** [all] Error 1 gmake[5]: Leaving directory `/usr/ports/java/jdk15/work/j2se/make/sun/javac/recompile' gmake[4]: *** [all] Error 1 gmake[4]: Leaving directory `/usr/ports/java/jdk15/work/j2se/make/sun/javac' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/usr/ports/java/jdk15/work/j2se/make/java/javac' gmake[2]: *** [all] Error 1 gmake[2]: Leaving directory `/usr/ports/java/jdk15/work/j2se/make/java' gmake[1]: *** [all] Error 1 gmake[1]: Leaving directory `/usr/ports/java/jdk15/work/j2se/make' gmake: *** [j2se-build] Error 2 *** Error code 2 Stop in /usr/ports/java/jdk15. *** Error code 1 Stop in /usr/ports/java/jdk15. From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 16:21:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 067C816A417 for ; Wed, 15 Aug 2007 16:21:26 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 93E0B13C483 for ; Wed, 15 Aug 2007 16:21:25 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so274466pyb for ; Wed, 15 Aug 2007 09:21:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IKLqEuZbN1MCUXboLKp+XyIrt0uXi8TR+X3V58TFrkPuhbIipCKnUSdSyYXsA9qPSG5q3c/aSB+eF/kg4HZt86sPPIOEADGqMVYqOYyEK4frhT+oKkCGdnj+5yotwfv0tiH0jyxR3+VKakTq9i22zVYCfXUNhF4J0pThE1vJMvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HgXVd7HyoApGDqgdX23Ne2v0KlNkwz7Q2EuYfCMM9p9eAMILkVsdEb2BdVl/pWE8mbcys1j50nmlI/Iqr7cX9h4YwTq8w/Tkww2YkZuQKAwVnuih/O7NASfaxOPWY6debaWh4P3TMrhMvw+FWoNvouO6LI3nwO5DbRge0omqs20= Received: by 10.65.214.2 with SMTP id r2mr1173573qbq.1187193146881; Wed, 15 Aug 2007 08:52:26 -0700 (PDT) Received: by 10.64.185.10 with HTTP; Wed, 15 Aug 2007 08:52:26 -0700 (PDT) Message-ID: <6eb82e0708150852t354e0a55h674d168ccee1f750@mail.gmail.com> Date: Wed, 15 Aug 2007 23:52:26 +0800 From: "Rong-en Fan" To: "Max Laier" In-Reply-To: <200708112129.29751.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6eb82e0708111122g7e36b725h19ede889e4bbc9d6@mail.gmail.com> <20070811191835.GA28716@rot26.obsecurity.org> <200708112129.29751.max@love2party.net> Cc: freebsd-current@freebsd.org, Kris Kennaway Subject: Re: panic: sleeping thread owns a non-sleepable lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 16:21:26 -0000 On 8/12/07, Max Laier wrote: > On Saturday 11 August 2007, Kris Kennaway wrote: > > On Sun, Aug 12, 2007 at 02:22:35AM +0800, Rong-en Fan wrote: > > > I'm running 7.0-CURRENT as of yesterday, and it's very easy > > > to make it panic: > > > > > > Sleeping thread (tid 100065, pid 1066) owns a non-sleepable lock > > > sched_switch(c50a1600,0,1,1c7a7e4,4217e5,...) at sched_switch+0x190 > > > mi_switch(1,0) at mi_switch+0x13f > > > sleepq_switch(c50a1600,0,c078a4e2,21b,c07e3820,...) at > > > sleepq_switch+0x87 sleepq_wait(c07e3820,0,c0770b7e,3,0,...) at > > > sleepq_wait+0x36 _sx_xlock_hard(c07e3820,c50a1600,0,0,0,...) at > > > _sx_xlock_hard+0x21d > > > fr_checknatout(f9c7a8d0,f9c7a8cc,64,c57ad900,c4de7400,...) at > > > fr_checknatout+0x29d > > > fr_check(c8cc4644,14,c4de7400,1,f9c7a9b4,...) at fr_check+0x9b1 > > > fr_check_wrapper(0,f9c7a9b4,c4de7400,2,c54dab28,...) at > > > fr_check_wrapper+0x3f > > > pfil_run_hooks(c08057c0,f9c7aa4c,c4de7400,2,c54dab28,...) at > > > pfil_run_hooks+0x74 ip_output(c8cc4600,0,f9c7aa10,0,0,...) at > > > ip_output+0x913 > > > tcp_output(cae322d0,cb277200,0,0,0,...) at tcp_output+0x1106 > > > tcp_usr_send(c51e7318,0,cb277200,0,0,...) at tcp_usr_send+0x240 > > > kern_sendfile(c50a1600,f9c7acfc,0,0,0,...) at kern_sendfile+0x1037 > > > sendfile(c50a1600,f9c7acfc,20,16,f9c7ad2c,...) at sendfile+0xa8 > > > syscall(f9c7ad38) at syscall+0x315 > > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > > --- syscall (393, FreeBSD ELF32, sendfile), eip = 0x28290bff, esp = > > > 0xbfbfc6ac, ebp = 0xbfbfe718 --- > > > > What is the lock it holds, and where is it acquired? > > My bet is on the pfil rwlock - accquired in pfil_run_hooks and tcbinfo / > inp mtxs from tcp_output. Nothing in the transmission path must use sx > locks. I keep on telling that. I compiled kernel with WITNESS and INVARIANTS as in GENERIC. After boot, without doing anything (I even set ipnat_enable="NO", i.e. only ipfw is running, but ipf/ipnat is compiled in). I got panic. I don't have serial console attached, but the console screen is at http://www.rafan.org/tmp/pfil_panic.jpg You can find 'show locks', 'show allpcpu', and 'show lock' for each lock. Also two trace for thread that are found in 'show allpcpu'. If necessary, I can setup serial console, but it will take few days. Hope this helps, Rong-En Fan > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 16:29:21 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37EB316A417 for ; Wed, 15 Aug 2007 16:29:21 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1E1FD13C459 for ; Wed, 15 Aug 2007 16:29:21 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 807E41A4D7C; Wed, 15 Aug 2007 09:27:53 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id 70BABC3EC; Wed, 15 Aug 2007 12:29:20 -0400 (EDT) Date: Wed, 15 Aug 2007 12:29:20 -0400 From: Kris Kennaway To: "Vyacheslav I. Ivanchenko" Message-ID: <20070815162920.GA70786@rot26.obsecurity.org> References: <46C2CE09.1060106@dhs.net.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <46C2CE09.1060106@dhs.net.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Apache on Current Error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 16:29:21 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Aug 15, 2007 at 06:57:29PM +0900, Vyacheslav I. Ivanchenko wrote: > http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/apache13/files/patch-ae What do you mean? Kris --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGwyngWry0BWjoQKURAuvBAJ9/1yVaZK/TEPVqwyySTIhmjZ/AKgCgiffO 3RAoyIYvTqCgIrzSaZEOFkU= =s3KF -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 16:58:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB1CB16A417 for ; Wed, 15 Aug 2007 16:58:12 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.freebsd.org (Postfix) with ESMTP id 62B0013C461 for ; Wed, 15 Aug 2007 16:58:12 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so499737wra for ; Wed, 15 Aug 2007 09:58:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=NPXHYqpqJPwEAXA2QqI1pNMuga+H24KU5vuPUGqO8AH0Ct8dplQjx5jy61jMVjaLAXNc7VeKQJYxzRu56rPXCyTFDN0MFwgZYjsjiE9fHm/ELfIpfisYIhHq7H0hHME9Z6kVPucoWDADmMTYWW86HzdxNEpKylBHdt45qcM8gh4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=B0/SCvXNXddq+39IfS0bQxAOo5G4vZW1I4FG/kGXlaGSdq0wN8u8MTyGgENRD8jD4C+iTQXzNuQZe7xSWEDKSRkMg4wioU+0eopWoJguB8sRrwjdS8HOuACOYSmYyOfrj08McmACvv3xZ+2rYfWcrSWDIzgV/M4ux+NJJ5/tWqg= Received: by 10.90.98.3 with SMTP id v3mr1003153agb.1187197091370; Wed, 15 Aug 2007 09:58:11 -0700 (PDT) Received: by 10.100.9.14 with HTTP; Wed, 15 Aug 2007 09:58:11 -0700 (PDT) Message-ID: <499c70c0708150958g7a4c336fuc5bfffb2181950be@mail.gmail.com> Date: Wed, 15 Aug 2007 19:58:11 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: MySQL 5.0.45 isn't shutting down at all in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 16:58:12 -0000 FreeBSD 7.0-CURRENT #0: Tue Aug 14 22:32:18 GMT 2007 arabian@services.wearab.net:/usr/obj/usr/src/sys/SERVICES amd64 ---> Backing up the old version ---> Uninstalling the old version ---> Deinstalling 'mysql-server-5.0.45' Stopping mysql. Waiting for PIDS: 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 578 mysql 9 20 0 110M 93524K sigwai 1 571:15 0.00% mysqld I tried kill -9 578 and killall -SIGTERM mysqld with no way to stop it. Any work around, or I have to restart the server? -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 17:12:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 061CA16A421 for ; Wed, 15 Aug 2007 17:12:12 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id AB2F013C45A for ; Wed, 15 Aug 2007 17:12:11 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ILMPf-0006vs-51 for freebsd-current@freebsd.org; Wed, 15 Aug 2007 19:12:07 +0200 Received: from 89-172-37-6.adsl.net.t-com.hr ([89.172.37.6]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Aug 2007 19:12:07 +0200 Received: from ivoras by 89-172-37-6.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Aug 2007 19:12:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 15 Aug 2007 19:11:52 +0200 Lines: 29 Message-ID: References: <20070812114017.GA93036@obelix.dsto.defence.gov.au> <20070815104929.GJ11649@obelix.dsto.defence.gov.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF10894EE94709D437F350143" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-37-6.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <20070815104929.GJ11649@obelix.dsto.defence.gov.au> X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: SEC:ULarger NGROUPS_MAX in CURRENT ? Ready for 7.0-R ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 17:12:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF10894EE94709D437F350143 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Wilkinson, Alex wrote: > Anyone ? rwatson@ ? AFAIK the only problem with this is that NFS will fail with larger number of groups, so (for those not using NFS) why not make the number of groups an item in kernel configurations and make a compile-time and module-load-time checks for this in the NFS code? --------------enigF10894EE94709D437F350143 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwzPeldnAQVacBcgRAhKIAJ9DK19uKdL+5r95HF9oHezacEew0gCZARrm nZt3se2Mvwhj3PeQpIuIJds= =X33u -----END PGP SIGNATURE----- --------------enigF10894EE94709D437F350143-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 17:19:01 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF78F16A419 for ; Wed, 15 Aug 2007 17:19:01 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 2365213C459 for ; Wed, 15 Aug 2007 17:19:00 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l7FHIwJ3002122; Wed, 15 Aug 2007 19:18:58 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l7FHIrOh005694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2007 19:18:53 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l7FHIqEC080780; Wed, 15 Aug 2007 19:18:52 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l7FHIqop080779; Wed, 15 Aug 2007 19:18:52 +0200 (CEST) (envelope-from ticso) Date: Wed, 15 Aug 2007 19:18:52 +0200 From: Bernd Walter To: Abdullah Ibn Hamad Al-Marri Message-ID: <20070815171851.GA72415@cicely12.cicely.de> References: <499c70c0708150958g7a4c336fuc5bfffb2181950be@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <499c70c0708150958g7a4c336fuc5bfffb2181950be@mail.gmail.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: FreeBSD Current Subject: Re: MySQL 5.0.45 isn't shutting down at all in 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 17:19:02 -0000 On Wed, Aug 15, 2007 at 07:58:11PM +0300, Abdullah Ibn Hamad Al-Marri wrote: > FreeBSD 7.0-CURRENT #0: Tue Aug 14 22:32:18 GMT 2007 > arabian@services.wearab.net:/usr/obj/usr/src/sys/SERVICES amd64 > > > ---> Backing up the old version > ---> Uninstalling the old version > ---> Deinstalling 'mysql-server-5.0.45' > Stopping mysql. > Waiting for PIDS: 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, > 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, > 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, > 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, > 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, > 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, > 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, > 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, > 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, > 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, 578, > 578, 578, > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 578 mysql 9 20 0 110M 93524K sigwai 1 571:15 0.00% mysqld > > I tried kill -9 578 and killall -SIGTERM mysqld with no way to stop it. > > Any work around, or I have to restart the server? I had excactly the same situation with MySQL two weeks ago. System is -current from 28th june on amd64. The MySQL was running inside a jail, which has it's whole data on ZFS. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 17:27:38 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F229216A41B for ; Wed, 15 Aug 2007 17:27:38 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 79F6A13C457 for ; Wed, 15 Aug 2007 17:27:38 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=M2TNmOtsHRYPkf2kXT//EOB7f71niQvLFhMSWb8KTdqdMlAQGdGWpetHHO9WDdBFoKfNZCoF0PVSqbaAHJDnyBn0kBBl4cbauNA9L8i61663CYY3i89n3+aSy76CrMN6o/Bve09i10tsAyTPSXROzIvSOtadHanTESfD702GPjM=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1ILMed-000AjW-TQ; Wed, 15 Aug 2007 21:27:36 +0400 Date: Wed, 15 Aug 2007 21:27:31 +0400 From: Eygene Ryabinkin To: Stefan Lambrev Message-ID: <20070815172731.GR988@void.codelabs.ru> References: <20070806224112.GA21876@muon.bluestop.org> <20070807073920.GV50228@void.codelabs.ru> <46C18B60.8050400@moneybookers.com> <20070814145759.GB25169@void.codelabs.ru> <20070814193150.GA21553@rot26.obsecurity.org> <46C30FA6.7060108@moneybookers.com> <20070815145640.GQ988@void.codelabs.ru> <46C319DD.3010806@moneybookers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <46C319DD.3010806@moneybookers.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: current@freebsd.org, Kris Kennaway Subject: Re: "tcpflags 0x18; tcp_do_segment" kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 17:27:39 -0000 Stefan, Wed, Aug 15, 2007 at 06:21:01PM +0300, Stefan Lambrev wrote: > Here is the part that does not have anything sensible: > > 16:10:13.206555 IP mb7.intra.net.60906 > mb4.intra.net.smtp: S > 219272317:219272317(0) win 65535 108147619 0> > 0x0000: 4500 003c 2747 4000 4006 0000 c0a8 0d07 E..<'G@.@....... > 0x0010: c0a8 0d04 edea 0019 0d11 d47d 0000 0000 ...........}.... > 0x0020: a002 ffff 9b8a 0000 0204 05b4 0103 0308 ................ > 0x0030: 0402 080a 0672 33a3 0000 0000 .....r3..... > 16:10:13.206789 IP mb4.intra.net.smtp > mb7.intra.net.60906: S > 1948405606:1948405606(0) ack 219272318 win 65535 1,nop,nop,timestamp 3042169350 108147619,sackOK,eol> > 0x0000: 4500 0040 b86e 4000 4006 e6ed c0a8 0d04 E..@.n@.@....... > 0x0010: c0a8 0d07 0019 edea 7422 4f66 0d11 d47e ........t"Of...~ > 0x0020: b012 ffff 4709 0000 0204 05b4 0103 0301 ....G........... > 0x0030: 0101 080a b553 d206 0672 33a3 0402 0000 .....S...r3..... > 16:10:13.206824 IP mb7.intra.net.60906 > mb4.intra.net.smtp: . ack 1 win 260 > > 0x0000: 4500 0034 2748 4000 4006 0000 c0a8 0d07 E..4'H@.@....... > 0x0010: c0a8 0d04 edea 0019 0d11 d47e 7422 4f67 ...........~t"Og > 0x0020: 8010 0104 9b82 0000 0101 080a 0672 33a4 .............r3. > 0x0030: b553 d206 .S.. Three-way handshake. > 16:10:13.208261 IP mb4.intra.net.smtp > mb7.intra.net.60906: P 1:48(47) ack 1 > win 33304 > 0x0000: 4500 0063 b873 4000 4006 e6c5 c0a8 0d04 E..c.s@.@....... > 0x0010: c0a8 0d07 0019 edea 7422 4f67 0d11 d47e ........t"Og...~ > 0x0020: 8018 8218 fca6 0000 0101 080a b553 d207 .............S.. > 0x0030: 0672 33a4 3232 3020 6d62 342e 6d6f 6e65 .r3.220.mb4.mone > 0x0040: 7962 6f6f 6b65 7273 2e63 6f6d 2045 534d ybookers.com.ESM > 0x0050: 5450 206d 6169 6c2d 6578 6368 616e 6765 TP.mail-exchange > 0x0060: 720d 0a r.. SMTP banner and greeting. > 16:10:13.208347 IP mb7.intra.net.60906 > mb4.intra.net.smtp: P 1:21(20) ack 48 > win 260 > 0x0000: 4500 0048 2749 4000 4006 0000 c0a8 0d07 E..H'I@.@....... > 0x0010: c0a8 0d04 edea 0019 0d11 d47e 7422 4f96 ...........~t"O. > 0x0020: 8018 0104 9b96 0000 0101 080a 0672 33a5 .............r3. > 0x0030: b553 d207 4845 4c4f 206d 6237 2e69 6e74 .S..HELO.mb7.int > 0x0040: 7261 2e6e 6574 0d0a ra.net.. Client sent his HELO. > 16:10:13.208690 IP mb4.intra.net.smtp > mb7.intra.net.60906: P 48:74(26) ack 21 > win 33304 > 0x0000: 4500 004e b877 4000 4006 e6d6 c0a8 0d04 E..N.w@.@....... > 0x0010: c0a8 0d07 0019 edea 7422 4f96 0d11 d492 ........t"O..... > 0x0020: 8018 8218 b312 0000 0101 080a b553 d208 .............S.. > 0x0030: 0672 33a5 3235 3020 6d62 342e 6d6f 6e65 .r3.250.mb4.mone > 0x0040: 7962 6f6f 6b65 7273 2e63 6f6d 0d0a ybookers.com.. Server sent 250, 'pleased to meet you' message. > 16:10:13.208715 IP mb7.intra.net.60906 > mb4.intra.net.smtp: P 21:27(6) ack 74 > win 260 > 0x0000: 4500 003a 274a 4000 4006 0000 c0a8 0d07 E..:'J@.@....... > 0x0010: c0a8 0d04 edea 0019 0d11 d492 7422 4fb0 ............t"O. > 0x0020: 8018 0104 9b88 0000 0101 080a 0672 33a5 .............r3. > 0x0030: b553 d208 5155 4954 0d0a .S..QUIT.. For some odd reason client issued QUIT. > I'm not sure why this QUIT is here. But I noticed that the app normaly use > "quit" (small letters) > May be the problem is in the application itself ? I don't know for sure, but what I am seeing with Apache, -CURRENT and keep-alived connections is that Apache sometimes drop them without any reason. Your SMTP symptoms are strange, as the Apache ones. May be FreeBSD TCP stack does something that provokes applications to behave weirdly. Can you tell what client and server software you're running: if client has sources, maybe we can see if it issues uppercase QUIT in some curcumstances, and the lowercase quit in other cases. I have Apache debugging in my TODO list, but currently I have no spare time for it. But your case can give some clues, so I will try to debug Apache soon. And the facts about your SMTP client will also help. > Anyway here are the rest of the packets (and one of them trigger > the error msg): And I can tell you, which one ;)) > 16:10:13.208729 IP mb7.intra.net.60906 > mb4.intra.net.smtp: F 27:27(0) ack 74 > win 260 > 0x0000: 4500 0034 274b 4000 4006 0000 c0a8 0d07 E..4'K@.@....... > 0x0010: c0a8 0d04 edea 0019 0d11 d498 7422 4fb0 ............t"O. > 0x0020: 8011 0104 9b82 0000 0101 080a 0672 33a5 .............r3. > 0x0030: b553 d208 .S.. > 16:10:13.208835 IP mb4.intra.net.smtp > mb7.intra.net.60906: . ack 28 win 33301 > > 0x0000: 4500 0034 b878 4000 4006 e6ef c0a8 0d04 E..4.x@.@....... > 0x0010: c0a8 0d07 0019 edea 7422 4fb0 0d11 d499 ........t"O..... > 0x0020: 8010 8215 0457 0000 0101 080a b553 d208 .....W.......S.. > 0x0030: 0672 33a5 .r3. > 16:10:13.208986 IP mb4.intra.net.smtp > mb7.intra.net.60906: P 74:89(15) ack 28 > win 33304 > 0x0000: 4500 0043 b879 4000 4006 e6df c0a8 0d04 E..C.y@.@....... > 0x0010: c0a8 0d07 0019 edea 7422 4fb0 0d11 d499 ........t"O..... > 0x0020: 8018 8218 5ce7 0000 0101 080a b553 d208 ....\........S.. > 0x0030: 0672 33a5 3232 3120 322e 302e 3020 4279 .r3.221.2.0.0.By > 0x0040: 650d 0a e.. The previous one: client mb7.intra.net had thrown his 'QUIT' and closed the socket, thus he is not interested in the server's response. Judging by the normal end of the task that you're citing below, the normal client workflow is to wait for the server's response to the 'quit' message and to close the socket only after it. So something unusual happening to the client and it is really interesting to look at the client's sources to see what's up. To clarify a bit: are all two servers running -CURRENT, or just the client one? Thank you! > 16:10:13.209069 IP mb7.intra.net.60906 > mb4.intra.net.smtp: R > 219272345:219272345(0) win 0 > 0x0000: 4500 0028 274c 4000 4006 0000 c0a8 0d07 E..('L@.@....... > 0x0010: c0a8 0d04 edea 0019 0d11 d499 0000 0000 ................ > 0x0020: 5004 0000 9b76 0000 0000 0000 0000 P....v........ > 16:10:13.209074 IP mb4.intra.net.smtp > mb7.intra.net.60906: F 89:89(0) ack 28 > win 33304 > 0x0000: 4500 0034 b87a 4000 4006 e6ed c0a8 0d04 E..4.z@.@....... > 0x0010: c0a8 0d07 0019 edea 7422 4fbf 0d11 d499 ........t"O..... > 0x0020: 8011 8218 0444 0000 0101 080a b553 d208 .....D.......S.. > 0x0030: 0672 33a5 .r3. > 16:10:13.209079 IP mb7.intra.net.60906 > mb4.intra.net.smtp: R > 219272345:219272345(0) win 0 > 0x0000: 4500 0028 274d 4000 4006 0000 c0a8 0d07 E..('M@.@....... > 0x0010: c0a8 0d04 edea 0019 0d11 d499 0000 0000 ................ > 0x0020: 5004 0000 9b76 0000 0000 0000 0000 P....v........ > > And here is the normal end of the task (same socket used ~9 min earlier) : > > 16:01:20.298645 IP mb4.intra.net.smtp > mb7.intra.net.60906: P 246:283(37) ack > 24881 win 33304 > 0x0000: 4500 0059 f4bc 4000 4006 aa86 c0a8 0d04 E..Y..@.@....... > 0x0010: c0a8 0d07 0019 edea a76e cce8 ebc6 8f74 .........n.....t > 0x0020: 8018 8218 3e15 0000 0101 080a b54b afe1 ....>........K.. > 0x0030: 066a 1166 3235 3020 322e 302e 3020 4f6b .j.f250.2.0.0.Ok > 0x0040: 3a20 7175 6575 6564 2061 7320 3546 4541 :.queued.as.5FEA > 0x0050: 4532 3044 3539 430d 0a E20D59C.. > 16:01:20.298900 IP mb7.intra.net.60906 > mb4.intra.net.smtp: P 24881:24887(6) > ack 283 win 260 > 0x0000: 4500 003a d953 4000 4006 0000 c0a8 0d07 E..:.S@.@....... > 0x0010: c0a8 0d04 edea 0019 ebc6 8f74 a76e cd0d ...........t.n.. > 0x0020: 8018 0104 9b88 0000 0101 080a 066a 1180 .............j.. > 0x0030: b54b afe1 7175 6974 0d0a .K..quit.. > 16:01:20.299675 IP mb4.intra.net.smtp > mb7.intra.net.60906: P 283:298(15) ack > 24887 win 33304 > 0x0000: 4500 0043 f4c2 4000 4006 aa96 c0a8 0d04 E..C..@.@....... > 0x0010: c0a8 0d07 0019 edea a76e cd0d ebc6 8f7a .........n.....z > 0x0020: 8018 8218 5702 0000 0101 080a b54b afe2 ....W........K.. > 0x0030: 066a 1180 3232 3120 322e 302e 3020 4279 .j..221.2.0.0.By > 0x0040: 650d 0a e.. > 16:01:20.299688 IP mb4.intra.net.smtp > mb7.intra.net.60906: F 298:298(0) ack > 24887 win 33304 > 0x0000: 4500 0034 f4c3 4000 4006 aaa4 c0a8 0d04 E..4..@.@....... > 0x0010: c0a8 0d07 0019 edea a76e cd1c ebc6 8f7a .........n.....z > 0x0020: 8011 8218 fe5e 0000 0101 080a b54b afe2 .....^.......K.. > 0x0030: 066a 1180 .j.. > 16:01:20.299700 IP mb7.intra.net.60906 > mb4.intra.net.smtp: . ack 299 win 260 > > 0x0000: 4500 0034 d954 4000 4006 0000 c0a8 0d07 E..4.T@.@....... > 0x0010: c0a8 0d04 edea 0019 ebc6 8f7a a76e cd1d ...........z.n.. > 0x0020: 8010 0104 9b82 0000 0101 080a 066a 1181 .............j.. > 0x0030: b54b afe2 .K.. > 16:01:20.299746 IP mb7.intra.net.60906 > mb4.intra.net.smtp: F 24887:24887(0) > ack 299 win 260 > 0x0000: 4500 0034 d955 4000 4006 0000 c0a8 0d07 E..4.U@.@....... > 0x0010: c0a8 0d04 edea 0019 ebc6 8f7a a76e cd1d ...........z.n.. > 0x0020: 8011 0104 9b82 0000 0101 080a 066a 1181 .............j.. > 0x0030: b54b afe2 .K.. > 16:01:20.299972 IP mb4.intra.net.smtp > mb7.intra.net.60906: . ack 24888 win > 33303 > 0x0000: 4500 0034 f4c4 4000 4006 aaa3 c0a8 0d04 E..4..@.@....... > 0x0010: c0a8 0d07 0019 edea a76e cd1d ebc6 8f7b .........n.....{ > 0x0020: 8010 8217 fe5d 0000 0101 080a b54b afe2 .....].......K.. > 0x0030: 066a 1181 .j.. -- Eygene From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 17:40:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF84F16A417 for ; Wed, 15 Aug 2007 17:40:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with SMTP id 4B54C13C467 for ; Wed, 15 Aug 2007 17:40:09 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 20487 invoked by uid 399); 15 Aug 2007 17:40:09 -0000 Received: from localhost (HELO slave.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 15 Aug 2007 17:40:09 -0000 X-Originating-IP: 127.0.0.1 Date: Wed, 15 Aug 2007 10:40:07 -0700 (PDT) From: Doug Barton To: Ivan Voras In-Reply-To: Message-ID: References: <20070812114017.GA93036@obelix.dsto.defence.gov.au> <20070815104929.GJ11649@obelix.dsto.defence.gov.au> X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: SEC:ULarger NGROUPS_MAX in CURRENT ? Ready for 7.0-R ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 17:40:09 -0000 On Wed, 15 Aug 2007, Ivan Voras wrote: > Wilkinson, Alex wrote: >> Anyone ? rwatson@ ? > > AFAIK the only problem with this is that NFS will fail with larger > number of groups, so (for those not using NFS) why not make the number > of groups an item in kernel configurations and make a compile-time and > module-load-time checks for this in the NFS code? Sure, we look forward to reviewing your patches. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 18:07:01 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14FA216A419 for ; Wed, 15 Aug 2007 18:07:01 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id BA24113C428 for ; Wed, 15 Aug 2007 18:07:00 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ILNGf-0005Ce-RU for freebsd-current@freebsd.org; Wed, 15 Aug 2007 20:06:53 +0200 Received: from 89-172-37-6.adsl.net.t-com.hr ([89.172.37.6]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Aug 2007 20:06:53 +0200 Received: from ivoras by 89-172-37-6.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Aug 2007 20:06:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 15 Aug 2007 20:06:40 +0200 Lines: 39 Message-ID: References: <20070812114017.GA93036@obelix.dsto.defence.gov.au> <20070815104929.GJ11649@obelix.dsto.defence.gov.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE90AE4910C89F6F45982AB2E" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-37-6.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: SEC:ULarger NGROUPS_MAX in CURRENT ? Ready for 7.0-R ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 18:07:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE90AE4910C89F6F45982AB2E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Doug Barton wrote: > On Wed, 15 Aug 2007, Ivan Voras wrote: >=20 >> Wilkinson, Alex wrote: >>> Anyone ? rwatson@ ? >> >> AFAIK the only problem with this is that NFS will fail with larger >> number of groups, so (for those not using NFS) why not make the number= >> of groups an item in kernel configurations and make a compile-time and= >> module-load-time checks for this in the NFS code? >=20 > Sure, we look forward to reviewing your patches. So all this time it was just a matter of someone doing it? No other architectural problems? --------------enigE90AE4910C89F6F45982AB2E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGw0CwldnAQVacBcgRAmf9AJ45LPBryZ/0wB8W79upp1syWi37zwCgi9ZF 9LgQ9/nVnC4ijRfNbTLi6wA= =1uqi -----END PGP SIGNATURE----- --------------enigE90AE4910C89F6F45982AB2E-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 18:23:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F18B16A417 for ; Wed, 15 Aug 2007 18:23:37 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by mx1.freebsd.org (Postfix) with ESMTP id 1DF5513C459 for ; Wed, 15 Aug 2007 18:23:37 +0000 (UTC) (envelope-from rodrigc@crodrigues.org) Received: from dibbler.crodrigues.org (c-66-31-32-42.hsd1.ma.comcast.net[66.31.32.42]) by comcast.net (rwcrmhc13) with SMTP id <20070815181229m13003lcope>; Wed, 15 Aug 2007 18:12:30 +0000 Received: by dibbler.crodrigues.org (sSMTP sendmail emulation); Wed, 15 Aug 2007 14:38:52 -0400 From: "Craig Rodrigues" Date: Wed, 15 Aug 2007 14:38:52 -0400 To: Karol Kwiatkowski Message-ID: <20070815183852.GA2463@crodrigues.org> References: <46BAF87E.8020406@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46BAF87E.8020406@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: Scot Hetzel , freebsd-current@freebsd.org Subject: Re: Can't remove 'noatime' on mounted filesystem on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 18:23:37 -0000 On Thu, Aug 09, 2007 at 01:20:30PM +0200, Karol Kwiatkowski wrote: > It seems to be impossible to remove 'noatime' property on mounted > filesystem (via -u option): Hi, Can you update your sources so that you get this patch: http://lists.freebsd.org/pipermail/cvs-src/2007-August/081243.html This should address your issue. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 18:52:07 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE22716A419 for ; Wed, 15 Aug 2007 18:52:07 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 6CB9D13C478 for ; Wed, 15 Aug 2007 18:52:07 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.185.41] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1ILNyO0Cnz-0000ly; Wed, 15 Aug 2007 20:52:04 +0200 From: Max Laier Organization: FreeBSD To: "Rong-en Fan" Date: Wed, 15 Aug 2007 20:51:50 +0200 User-Agent: KMail/1.9.7 References: <6eb82e0708111122g7e36b725h19ede889e4bbc9d6@mail.gmail.com> <200708112129.29751.max@love2party.net> <6eb82e0708150852t354e0a55h674d168ccee1f750@mail.gmail.com> In-Reply-To: <6eb82e0708150852t354e0a55h674d168ccee1f750@mail.gmail.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2244228.rqKCzGaHZH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708152052.01275.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+UyA++sQSCM8mMK2wzfUTIDgxbEDY+Z5GoVDq fULc9btjR/h2NMDfyGcWdrN4e5Iwfanv9VMxtv1TXBH8wvN8iI 2CUzYPeDJxqx5tXvsfzBCF6n4Fe3W1MTt0h7FVO2ak= Cc: freebsd-current@freebsd.org, Kris Kennaway Subject: Re: panic: sleeping thread owns a non-sleepable lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 18:52:08 -0000 --nextPart2244228.rqKCzGaHZH Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 15 August 2007, Rong-en Fan wrote: > On 8/12/07, Max Laier wrote: > > On Saturday 11 August 2007, Kris Kennaway wrote: > > > On Sun, Aug 12, 2007 at 02:22:35AM +0800, Rong-en Fan wrote: > > > > I'm running 7.0-CURRENT as of yesterday, and it's very easy > > > > to make it panic: > > > > > > > > Sleeping thread (tid 100065, pid 1066) owns a non-sleepable lock > > > > sched_switch(c50a1600,0,1,1c7a7e4,4217e5,...) at > > > > sched_switch+0x190 mi_switch(1,0) at mi_switch+0x13f > > > > sleepq_switch(c50a1600,0,c078a4e2,21b,c07e3820,...) at > > > > sleepq_switch+0x87 sleepq_wait(c07e3820,0,c0770b7e,3,0,...) at > > > > sleepq_wait+0x36 _sx_xlock_hard(c07e3820,c50a1600,0,0,0,...) at > > > > _sx_xlock_hard+0x21d > > > > fr_checknatout(f9c7a8d0,f9c7a8cc,64,c57ad900,c4de7400,...) at > > > > fr_checknatout+0x29d > > > > fr_check(c8cc4644,14,c4de7400,1,f9c7a9b4,...) at fr_check+0x9b1 > > > > fr_check_wrapper(0,f9c7a9b4,c4de7400,2,c54dab28,...) at > > > > fr_check_wrapper+0x3f > > > > pfil_run_hooks(c08057c0,f9c7aa4c,c4de7400,2,c54dab28,...) at > > > > pfil_run_hooks+0x74 ip_output(c8cc4600,0,f9c7aa10,0,0,...) at > > > > ip_output+0x913 > > > > tcp_output(cae322d0,cb277200,0,0,0,...) at tcp_output+0x1106 > > > > tcp_usr_send(c51e7318,0,cb277200,0,0,...) at tcp_usr_send+0x240 > > > > kern_sendfile(c50a1600,f9c7acfc,0,0,0,...) at > > > > kern_sendfile+0x1037 > > > > sendfile(c50a1600,f9c7acfc,20,16,f9c7ad2c,...) at sendfile+0xa8 > > > > syscall(f9c7ad38) at syscall+0x315 > > > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > > > --- syscall (393, FreeBSD ELF32, sendfile), eip =3D 0x28290bff, esp > > > > =3D 0xbfbfc6ac, ebp =3D 0xbfbfe718 --- > > > > > > What is the lock it holds, and where is it acquired? > > > > My bet is on the pfil rwlock - accquired in pfil_run_hooks and > > tcbinfo / inp mtxs from tcp_output. Nothing in the transmission path > > must use sx locks. I keep on telling that. > > I compiled kernel with WITNESS and INVARIANTS as in GENERIC. > After boot, without doing anything (I even set ipnat_enable=3D"NO", i.e. > only ipfw is running, but ipf/ipnat is compiled in). I got panic. > I don't have serial console attached, but the console screen is at > > http://www.rafan.org/tmp/pfil_panic.jpg > > You can find 'show locks', 'show allpcpu', and 'show lock' for each > lock. Also two trace for thread that are found in 'show allpcpu'. > > If necessary, I can setup serial console, but it will take few days. The problem is understood and has been reported to the ipfilter=20 maintainer. One sollution might be to use rwlocks instead, but if there=20 is a path that sleeps with the lock held another sollution might be=20 required. Most likely the ioctl path (on copyin/copyout) exercises that=20 problem. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2244228.rqKCzGaHZH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGw0tRXyyEoT62BG0RAoeQAJ97nN4aCD5DdRmZtXx2wNqSKGRtTQCfb3r4 +sqG438eBEW+BDdE0hbYzbg= =wTwY -----END PGP SIGNATURE----- --nextPart2244228.rqKCzGaHZH-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 18:59:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 272CB16A41B for ; Wed, 15 Aug 2007 18:59:59 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 8E45D13C469 for ; Wed, 15 Aug 2007 18:59:58 +0000 (UTC) (envelope-from h.schmalzbauer@omnisec.de) Received: from [192.168.1.67] (e181041192.adsl.alicedsl.de [85.181.41.192]) (authenticated bits=0) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id l7FIxuTL018310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2007 20:59:57 +0200 (CEST) (envelope-from h.schmalzbauer@omnisec.de) X-Authentication-Warning: smtp.dmz.omnisec.de: Host e181041192.adsl.alicedsl.de [85.181.41.192] claimed to be [192.168.1.67] From: Harald Schmalzbauer Organization: OmniSEC To: freebsd-current@freebsd.org Date: Wed, 15 Aug 2007 20:59:51 +0200 User-Agent: KMail/1.9.7 References: <200708141209.l7EC9nrb082368@lurza.secnetix.de> In-Reply-To: <200708141209.l7EC9nrb082368@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708152059.52469.h.schmalzbauer@omnisec.de> Cc: Oliver Fromme Subject: Re: powerd and it's "wakeup" behaviour X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 18:59:59 -0000 Am Dienstag, 14. August 2007 14:09:49 schrieb Oliver Fromme: > Harald Schmalzbauer wrote: [...] > I've needed a similar feature for some time and I have a > patch, so I cleaned it up a bit and submitted it along > with an update to the manpage. It's PR bin/115513: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=115513 > > Apply the diff relative to src/usr/sbin/powerd, then > "make clean && make && make install", and restart > powerd with option -u 100. That should have the effect > that you described above. Wonderful, hopefully it will make it's way into powerd. But I haven't testet because measuring the throttling of my P3-m showed that it saves exactly nothing (primary measured, 14.00W@500MHz, 14.00W@"62"MHz). So since it's old SpeedStep wich only proviedes two frequencies/voltages "wakeup" is 100% with throttling disabled. It's the most sutable way for me now but I'll love to have the -u feature when I'll have an EST machine. Thanks, -Harry From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 19:18:52 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF0EB16A468 for ; Wed, 15 Aug 2007 19:18:51 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C5F0E13C457 for ; Wed, 15 Aug 2007 19:18:51 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 91ABD1A4D7C; Wed, 15 Aug 2007 12:17:23 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id 8D556C3EC; Wed, 15 Aug 2007 15:18:50 -0400 (EDT) Date: Wed, 15 Aug 2007 15:18:50 -0400 From: Kris Kennaway To: Erik Cederstrand Message-ID: <20070815191850.GA74746@rot26.obsecurity.org> References: <46C2C19D.9090700@cederstrand.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <46C2C19D.9090700@cederstrand.dk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Feedback for performance tracker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 19:18:52 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 15, 2007 at 11:04:29AM +0200, Erik Cederstrand wrote: > Hi! >=20 > This autumn, we have decided to grab the Performance Tracker entry[1] > from the project ideas page and give it a spin as a subject for our > thesis at the IT University of Copenhagen. The tracker intends to fill a > hole in the range of tinderboxes and automatic stress/regression tests > that FreeBSD already has. >=20 > The initial idea is to have a small collection of servers constantly > performing benchmarks and publishing the results to a server with a web > interface. >=20 > Before we start coding, we'd like to ask a couple of questions: >=20 > 1) Which benchmarks would you like to see being run? > 2) Which tests do you perform regularly, which the tracker could automate? > 3) Which features in the web interface would you find most helpful? >=20 > Also, we'd greatly appreciate pointers to previous work in the area. >=20 > We welcome all comments and suggestions, but please bear in mind that we > only have around 3 months full-time to develop the tracker. Hi, Thanks for your interest in the project. I have some recommendations for how to approach it: * Don't focus on the individual benchmarks, instead on the framework for accumulating and analysing the data. There are lots of benchmarks we may want to plug into this over time, so developing a flexible and extensible system for doing this is more important than any given benchmark. * I imagine a system where data from benchmark systems (which will be geographically remote) is fed into a database that tracks multiple data sets over time. A front end would provide an interface into this database and allow for various analyses and visualizations of the data * The system should allow for annotation of data, for example to provide explanations for sudden jumps in performance when they are understood. * Data sets may be multi-dimensional (e.g. tracking a performance metric like network throughput as various parameters like packet size, number of concurrent streams, etc, are changed). In most cases we are also interested in changes over time. * There may be parametric and non-parametric variables. An example of a parametric variable would be "size of a network packet" (i.e. a numerical parameter which takes values over some range). A non-parametric variable might be "kernel built with option X, or option Y, or option Z". It makes sense to visualize parametrized data as a continuous function, e.g. by plotting it as a continuous function on a graph, or fitting the data to a function. It makes less sense to treat non-parametric data as a continuous function. * Data sets are typically noisy. They need to be analysed by statistical techniques to extract a signal (if any), which will usually be tiny over small times but may accumulate over larger times. A background in statistics will be most useful here. * An ideal front-end would be able to apply appropriate statistical and data visualization techniques to cross-sections of the data to answer questions like "have there been any statistically significant changes to this data set (or subset) over time, and if so, when did they occur?". * There is likely to be significant prior art in all of this, but I don't know what any of it is. The HDF data format http://hdf.ncsa.uiuc.edu/ and related tools might be interesting to investigate; but I don't really know anything about it so it might be too heavy-weight. Perhaps some of our scientific computing users can make some suggestions. * Start small. You should keep an eye on the bigger picture such as what I suggest, but don't try and bite it all off at once. For example, you could start by limiting to recording and analysing data sets that contain only a single data point changing over time (while hopefully not limiting future expansion), because even that will be a useful beginning. Kris --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGw1GaWry0BWjoQKURAvZIAKCEyR9SB5tDenW3IBeAL5bkAtAyfQCgyI6w Vpy5c3M0b/d8GPu82akJfmg= =Ou/p -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 18:51:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF2BF16A41A for ; Wed, 15 Aug 2007 18:51:09 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id C5FB313C46C for ; Wed, 15 Aug 2007 18:51:09 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 4D948100D; Wed, 15 Aug 2007 13:51:06 -0500 (CDT) Date: Wed, 15 Aug 2007 13:51:06 -0500 To: Erik Cederstrand Message-ID: <20070815185106.GA5001@soaustin.net> References: <46C2C19D.9090700@cederstrand.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46C2C19D.9090700@cederstrand.dk> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Wed, 15 Aug 2007 20:22:32 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Feedback for performance tracker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 18:51:10 -0000 On Wed, Aug 15, 2007 at 11:04:29AM +0200, Erik Cederstrand wrote: > 1) Which benchmarks would you like to see being run? > 2) Which tests do you perform regularly, which the tracker could automate? > 3) Which features in the web interface would you find most helpful? Here's what Robert Watson last posted on this subject (on freebsd-arch@). I hope that he doesn't mind the re-post. Date: Wed, 4 Jul 2007 12:58:44 +0100 (BST) From: Robert Watson In-Reply-To: <20070704105525.GU45894@elvis.mu.org> Message-ID: <20070704124833.W37059@fledge.watson.org> References: <20070702230728.E552@10.0.0.1> <20070703181242.T552@10.0.0.1> <20070704105525.GU45894@elvis.mu.org> Cc: arch@freebsd.org I also worry about the narrowness of the benchmarking we're doing -- however, it's hardly new. We do best at optimizing where we have clearly defined targets and measures of performance. The four-times increase in MySQL select performance is a direct result of Kris taking on scalability measurement and helping developers with optimization ideas try them out, profile them, etc. A point I've made at a number of devsummits and elsewhere is that what we really need now is more people to "take ownership" of the performance of workloads they care about. They don't need to be the people to do the optimizations, but if they could help manage outstanding patchsets, measure the change in performance over time, get involved in profiling, etc, then that will have a big effect on performance for the workload, as has happened with MySQL. Here are some workloads I'd really like to see people take responsibility for: - Flat file Apache performance, perhaps with Apachebench or another HTTP throughput measurement tool. - Dynamic Apache performance, perhaps using some combination of Apache/php/MySQL. - BIND query performance with a few realistic-looking workloads. - PostgreSQL performance along the same lines as current MySQL performance. Kris has waved his hands a bit in this direction already and much of the MySQL measurement work can be reused. - Some sort of compiler/build/etc test -- buildworld of HEAD tends to be highly variable over time as components change, compilers change, etc, but optimizing build performance still has a big benefit for developers. Perhaps how long it takes to do the post-buildtools bit of buildworld for a fixed FreeBSD version. - Network micro-benchmarks, including loopback TCP and UDP, multi-machine TCP and UDP, both single stream and multi-stream. - UI interactivity testing -- how long it takes to go from a simultaned keypress from the keyboard device to an input program running in an xterm and other related latency tests that will be affected by scheduling, IPC, and so on. There seem to be two parts of owning a benchmark: - Establishing baselines over time -- how doe FreeBSD 4.8, 5.5, 6.0, 6.1, 6.2, 6-STABLE weekly, 7-CURRENT weekly, and maybe a Linux or NetBSD version perform for the workload using otherwise identical configuration. - Measurement and feedback -- identifying bottlenecks, working with developers to measure the results of specific optimizations, etc, across the life cycle of the patch. If Kris can motivate such a dramatic improvement in MySQL performance, it seems likely that people doing similar things with other workloads could have similar effects. And, as you say, breadth is really important -- tuning the system for MySQL is very important, but has it generally hurt or helped other workloads? In most cases, I'd expect work to date to have helped, because it involved lowering overhead, etc. However, when we get into schedulers, space/time trade-offs, and so on, then that balance will become harder to strike. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 20:28:27 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BDB316A417 for ; Wed, 15 Aug 2007 20:28:27 +0000 (UTC) (envelope-from fbsdlists@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239]) by mx1.freebsd.org (Postfix) with ESMTP id 0725413C461 for ; Wed, 15 Aug 2007 20:28:26 +0000 (UTC) (envelope-from fbsdlists@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so26459nzf for ; Wed, 15 Aug 2007 13:28:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=asZIWUZNhwz4Xxazvx4PQVO4+YC8ZDjLZ3kBdFS84/uYck+XTHudN+G9gN+2XFzeTWnmaYOeekcLrBgqro4z7luEEme1/zUF9FH5GrHgTjJ38aUuGRajFIOdGkUJKthPl4dX2kJOJpD7yNDp60YI5O8m6YKML1JpUCv1O3SEZ9Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gAKNIhVeC4vX6vZajDbTyLx4KvN5/6aa6J1ZtA9137qs6GcsU4PKaz1RDYwHmbHqHXAgteOeATtC35PGGtBAOOPVbbYeVJJcrW0mYbdcDXAIUKM98yUll6i8+kdEUZFmysKUEK/rrKnm/nYsv7aIuJqexqygjt4ch/tnqWsLiIc= Received: by 10.142.52.9 with SMTP id z9mr50273wfz.1187208120294; Wed, 15 Aug 2007 13:02:00 -0700 (PDT) Received: by 10.142.80.8 with HTTP; Wed, 15 Aug 2007 13:02:00 -0700 (PDT) Message-ID: <54db43990708151302u62515d9fldeb836fa778d9f16@mail.gmail.com> Date: Wed, 15 Aug 2007 16:02:00 -0400 From: "Bob Johnson" To: current@freebsd.org In-Reply-To: <36C33C6D-8EDE-4000-9B3D-164CD580BE7F@xbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46C2263F.4080607@cisco.com> <46C2399A.2050401@elischer.org> <36C33C6D-8EDE-4000-9B3D-164CD580BE7F@xbsd.org> Cc: Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 20:28:27 -0000 On 8/14/07, Florent Thoumie wrote: > On 15 Aug 2007, at 00:24, Julian Elischer wrote: > > > Kip Macy wrote: > >> On 8/14/07, Randall Stewart wrote: > >>> Hi all: > >>> > >>> Just curious.. as anyone did this on BSD? > >>> > >>> If so, pointers would be nice.. if not... I may (but > >>> I won't go into the rant as why ;-D) > >> I can guess. I believe there is an IPoDNS netgraph module floating > >> around that *might* make a good reference. > >> -Kip > > > > OH Come on.. if you have a reference, cough up :-) > > It should be committed! (how many times have I wanted that?) > > I second that, if only for the coolness factor :-) For coolness factor, it's hard to beat the TCP-over-email proof-of-concept I ran across about ten or twelve years ago. Mostly useless, but very entertaining. It was probably the one done by Marcus Ranum http://www.ranum.com/, but I don't really remember. And then there is RFC 1149: http://tools.ietf.org/html/rfc1149, which according to Wikipedia, has actually been implemented by a Linux group who apparently were having a slow weekend. - Bob From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 21:35:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8642316A41A for ; Wed, 15 Aug 2007 21:35:59 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3C99313C48D for ; Wed, 15 Aug 2007 21:35:59 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1ILQWz-0007MX-K2 for freebsd-current@freebsd.org; Wed, 15 Aug 2007 23:35:57 +0200 Received: from 89-172-37-6.adsl.net.t-com.hr ([89.172.37.6]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Aug 2007 23:35:57 +0200 Received: from ivoras by 89-172-37-6.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Aug 2007 23:35:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 15 Aug 2007 23:35:31 +0200 Lines: 35 Message-ID: References: <46C2C19D.9090700@cederstrand.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0BD0534724CDC6F06697F6F1" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-37-6.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <46C2C19D.9090700@cederstrand.dk> X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: Feedback for performance tracker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 21:35:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0BD0534724CDC6F06697F6F1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Erik Cederstrand wrote: > The initial idea is to have a small collection of servers constantly > performing benchmarks and publishing the results to a server with a web= > interface. In addition to "processed" data please make the raw data also available, so people who need it can make their own calculations and conclusions. Make the data available in some standard format, either text, xml or SQLite (a nice benefit of SQLite is that, if you do your entire project with it, you can simply offer your database file(s) for dowload, no need for database dumps/conversion). --------------enig0BD0534724CDC6F06697F6F1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGw3GtldnAQVacBcgRApOiAKDN3137Qcna4ZKMbQnOQrkfvGmg+QCggnAP YsQ6+5JIWohKV83PJlHvB0Y= =dnsj -----END PGP SIGNATURE----- --------------enig0BD0534724CDC6F06697F6F1-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 22:14:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEB8916A419 for ; Wed, 15 Aug 2007 22:14:26 +0000 (UTC) (envelope-from bkelly@vadev.org) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id B28C413C48E for ; Wed, 15 Aug 2007 22:14:26 +0000 (UTC) (envelope-from bkelly@vadev.org) Received: (qmail 2008 invoked from network); 15 Aug 2007 21:47:45 -0000 Received: from vadev.org (HELO [192.168.1.84]) (Desdicardo@[66.92.166.151]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 15 Aug 2007 21:47:45 -0000 Message-ID: <46C37480.5010408@vadev.org> Date: Wed, 15 Aug 2007 17:47:44 -0400 From: Ben Kelly User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: Erik Cederstrand References: <46C2C19D.9090700@cederstrand.dk> In-Reply-To: <46C2C19D.9090700@cederstrand.dk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Feedback for performance tracker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2007 22:14:26 -0000 Erik Cederstrand wrote: > 1) Which benchmarks would you like to see being run? > 2) Which tests do you perform regularly, which the tracker could automate? > 3) Which features in the web interface would you find most helpful? It might be helpful to capture and make available the configuration of the machine(s) under test. For example, kernel configuration, make.conf, dmesg output, etc. It might make sense to use each configuration to define each data series. A change in the configuration would be the start of a new series. Just a thought. - Ben From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 00:31:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96A6216A420 for ; Thu, 16 Aug 2007 00:31:04 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id 519AB13C457 for ; Thu, 16 Aug 2007 00:31:03 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so155408pyb for ; Wed, 15 Aug 2007 17:31:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=R+jkmPgDffeCukQm+LPjUqZAjAE4pnrKBZUIUFaZ2djNAHsTbxIP9QjTV+TQjqAkUDAakBA5pG4I5pfafNlsb4hLOxWzcDo8oX5b0FZSbOpLEbQkRAvKsecJaMrHpmtJ/Qo8erSFUqYsJS73g4cKCT5kWRwxzhtE4zCBDGvHFxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Xfj2waaRPG+wWlXpF+bLrWxdVinJnH7QXcWSID4xln6+EoUJOGSBZyrYWVAqMNacgLc0Y2xcbK6jeDNBawEFHs2bPn3hkAk3LBnwEbjQ8O7vsRXSsPFgzFpTVIfoqjntVRuQWP1e1bJrzW1+ZNq74IgdGXLMftac7NrmEWB8jIQ= Received: by 10.65.242.11 with SMTP id u11mr2031291qbr.1187224262291; Wed, 15 Aug 2007 17:31:02 -0700 (PDT) Received: by 10.64.185.10 with HTTP; Wed, 15 Aug 2007 17:31:02 -0700 (PDT) Message-ID: <6eb82e0708151731q103c2a11i65628425014fb39d@mail.gmail.com> Date: Thu, 16 Aug 2007 08:31:02 +0800 From: "Rong-en Fan" To: "Max Laier" In-Reply-To: <200708152052.01275.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6eb82e0708111122g7e36b725h19ede889e4bbc9d6@mail.gmail.com> <200708112129.29751.max@love2party.net> <6eb82e0708150852t354e0a55h674d168ccee1f750@mail.gmail.com> <200708152052.01275.max@love2party.net> Cc: freebsd-current@freebsd.org, Kris Kennaway Subject: Re: panic: sleeping thread owns a non-sleepable lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 00:31:04 -0000 On 8/16/07, Max Laier wrote: > On Wednesday 15 August 2007, Rong-en Fan wrote: > > On 8/12/07, Max Laier wrote: > > > On Saturday 11 August 2007, Kris Kennaway wrote: > > > > On Sun, Aug 12, 2007 at 02:22:35AM +0800, Rong-en Fan wrote: > > > > > I'm running 7.0-CURRENT as of yesterday, and it's very easy > > > > > to make it panic: > > > > > > > > > > Sleeping thread (tid 100065, pid 1066) owns a non-sleepable lock > > > > > sched_switch(c50a1600,0,1,1c7a7e4,4217e5,...) at > > > > > sched_switch+0x190 mi_switch(1,0) at mi_switch+0x13f > > > > > sleepq_switch(c50a1600,0,c078a4e2,21b,c07e3820,...) at > > > > > sleepq_switch+0x87 sleepq_wait(c07e3820,0,c0770b7e,3,0,...) at > > > > > sleepq_wait+0x36 _sx_xlock_hard(c07e3820,c50a1600,0,0,0,...) at > > > > > _sx_xlock_hard+0x21d > > > > > fr_checknatout(f9c7a8d0,f9c7a8cc,64,c57ad900,c4de7400,...) at > > > > > fr_checknatout+0x29d > > > > > fr_check(c8cc4644,14,c4de7400,1,f9c7a9b4,...) at fr_check+0x9b1 > > > > > fr_check_wrapper(0,f9c7a9b4,c4de7400,2,c54dab28,...) at > > > > > fr_check_wrapper+0x3f > > > > > pfil_run_hooks(c08057c0,f9c7aa4c,c4de7400,2,c54dab28,...) at > > > > > pfil_run_hooks+0x74 ip_output(c8cc4600,0,f9c7aa10,0,0,...) at > > > > > ip_output+0x913 > > > > > tcp_output(cae322d0,cb277200,0,0,0,...) at tcp_output+0x1106 > > > > > tcp_usr_send(c51e7318,0,cb277200,0,0,...) at tcp_usr_send+0x240 > > > > > kern_sendfile(c50a1600,f9c7acfc,0,0,0,...) at > > > > > kern_sendfile+0x1037 > > > > > sendfile(c50a1600,f9c7acfc,20,16,f9c7ad2c,...) at sendfile+0xa8 > > > > > syscall(f9c7ad38) at syscall+0x315 > > > > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > > > > --- syscall (393, FreeBSD ELF32, sendfile), eip = 0x28290bff, esp > > > > > = 0xbfbfc6ac, ebp = 0xbfbfe718 --- > > > > > > > > What is the lock it holds, and where is it acquired? > > > > > > My bet is on the pfil rwlock - accquired in pfil_run_hooks and > > > tcbinfo / inp mtxs from tcp_output. Nothing in the transmission path > > > must use sx locks. I keep on telling that. > > > > I compiled kernel with WITNESS and INVARIANTS as in GENERIC. > > After boot, without doing anything (I even set ipnat_enable="NO", i.e. > > only ipfw is running, but ipf/ipnat is compiled in). I got panic. > > I don't have serial console attached, but the console screen is at > > > > http://www.rafan.org/tmp/pfil_panic.jpg > > > > You can find 'show locks', 'show allpcpu', and 'show lock' for each > > lock. Also two trace for thread that are found in 'show allpcpu'. > > > > If necessary, I can setup serial console, but it will take few days. > > The problem is understood and has been reported to the ipfilter > maintainer. One sollution might be to use rwlocks instead, but if there > is a path that sleeps with the lock held another sollution might be > required. Most likely the ioctl path (on copyin/copyout) exercises that > problem. I see. So, only ipfilter has this problem, but not pf and ipfw, right? Thanks. Regards, Rong-En Fan > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 00:47:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3082416A418 for ; Thu, 16 Aug 2007 00:47:58 +0000 (UTC) (envelope-from ivi@dhs.net.ru) Received: from atlant.asiamusic.ru (AsiaTrade-Orient.orient.net.ru [195.161.236.162]) by mx1.freebsd.org (Postfix) with ESMTP id C323413C457 for ; Thu, 16 Aug 2007 00:47:56 +0000 (UTC) (envelope-from ivi@dhs.net.ru) Received: from atlant.asiamusic.ru (localhost [127.0.0.1]) by atlant.asiamusic.ru (Postfix) with ESMTP id 80CB31CC48 for ; Thu, 16 Aug 2007 09:47:51 +0900 (IRKST) Received: from topaz.dhs.net.ru (webmaster.asiamusic.lan [192.168.125.10]) by atlant.asiamusic.ru (Postfix) with ESMTP id 3A0181CC44 for ; Thu, 16 Aug 2007 09:47:51 +0900 (IRKST) Message-ID: <46C39EB5.6050701@dhs.net.ru> Date: Thu, 16 Aug 2007 09:47:49 +0900 From: "Vyacheslav I. Ivanchenko" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.6) Gecko/20070810 SeaMonkey/1.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: 46C2CE09.1060106@dhs.net.ru Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Thu, 16 Aug 2007 00:50:04 +0000 Subject: Apache on Current Error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 00:47:58 -0000 I use 7.0-CURRENT from August, 14 2007. I had problems with ports www/apache13-modssl, russian/apache13, russian/apache13-modssl, after applying this patch the problem was solved. From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 03:06:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7F9116A417 for ; Thu, 16 Aug 2007 03:06:54 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6F27313C469 for ; Thu, 16 Aug 2007 03:06:54 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l7G2ttZS019144 for ; Thu, 16 Aug 2007 12:25:55 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Thu, 16 Aug 2007 12:36:45 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 12:36:45 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.1/8.14.1) with ESMTP id l7G35fU7016497 for ; Thu, 16 Aug 2007 11:05:41 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.1/8.14.1/Submit) id l7G35fe4016496 for freebsd-current@freebsd.org; Thu, 16 Aug 2007 11:05:41 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 16 Aug 2007 11:05:41 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20070816030540.GO11649@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20070812114017.GA93036@obelix.dsto.defence.gov.au> <20070815104929.GJ11649@obelix.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 16 Aug 2007 03:06:45.0647 (UTC) FILETIME=[7A8B49F0:01C7DFB2] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.0.1021-15364.000 X-TM-AS-Result: No--1.107800-0.000000-31 Content-Transfer-Encoding: 7bit Subject: Re: SEC:ULarger NGROUPS_MAX in CURRENT ? Ready for 7.0-R ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 03:06:55 -0000 0n Wed, Aug 15, 2007 at 10:40:07AM -0700, Doug Barton wrote: >> AFAIK the only problem with this is that NFS will fail with larger >> number of groups, so (for those not using NFS) why not make the number >> of groups an item in kernel configurations and make a compile-time and >> module-load-time checks for this in the NFS code? > >Sure, we look forward to reviewing your patches. Linux has done some interesting work with respect to this. They have implemented "Dynamic Allocation of Groups Array When Required" [http://lwn.net/Articles/50916/]. And can allocate up to: #cat /proc/sys/kernel/ngroups_max 65536 I thought NFSv4 no longer has the 16 group limitation ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 07:37:34 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4416616A417 for ; Thu, 16 Aug 2007 07:37:34 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id F2B2513C4A7 for ; Thu, 16 Aug 2007 07:37:33 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id 95E461B10EE8; Thu, 16 Aug 2007 09:37:32 +0200 (CEST) Received: from hater.cmotd.com (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 935DB1B10EA4; Thu, 16 Aug 2007 09:37:32 +0200 (CEST) Message-ID: <46C3FEBC.80409@moneybookers.com> Date: Thu, 16 Aug 2007 10:37:32 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.4pre (X11/20070711) MIME-Version: 1.0 To: Eygene Ryabinkin References: <20070806224112.GA21876@muon.bluestop.org> <20070807073920.GV50228@void.codelabs.ru> <46C18B60.8050400@moneybookers.com> <20070814145759.GB25169@void.codelabs.ru> <20070814193150.GA21553@rot26.obsecurity.org> <46C30FA6.7060108@moneybookers.com> <20070815145640.GQ988@void.codelabs.ru> <46C319DD.3010806@moneybookers.com> <20070815172731.GR988@void.codelabs.ru> In-Reply-To: <20070815172731.GR988@void.codelabs.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: current@freebsd.org Subject: Re: "tcpflags 0x18; tcp_do_segment" kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 07:37:34 -0000 Hello, Eygene Ryabinkin wrote: > The previous one: client mb7.intra.net had thrown his 'QUIT' and > closed the socket, thus he is not interested in the server's response. > Judging by the normal end of the task that you're citing below, the > normal client workflow is to wait for the server's response to the > 'quit' message and to close the socket only after it. So something > unusual happening to the client and it is really interesting to > look at the client's sources to see what's up. > > To clarify a bit: are all two servers running -CURRENT, or just the > client one? > > Thank you! > Only mb7 is -current (i386), mb4 is 6.2 (i386). The server is postfix, but the client is binary and we do not have the sources. I'll see what the creators can tell about this. -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 08:05:27 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C12116A417 for ; Thu, 16 Aug 2007 08:05:27 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4FB6713C467 for ; Thu, 16 Aug 2007 08:05:27 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=kxvPVsn6fvZunjg15UKQI3CGZLA/4/IScTaaNB4kZhqApRhAjqvZP0AgJQDhMrX5Vn3N+yOfDcWVzkTBEP5FpxHtZ8/BHmSzcvi1DQ3sAfZOyxyjw2SkqUuvtKF8kq1EwG1nNOq9owml2r7d2rQC3BbxSBF7+RAs2/kLipKAyeY=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1ILaM5-000G9T-K9; Thu, 16 Aug 2007 12:05:22 +0400 Date: Thu, 16 Aug 2007 12:05:17 +0400 From: Eygene Ryabinkin To: Stefan Lambrev Message-ID: <20070816080516.GW988@void.codelabs.ru> References: <20070806224112.GA21876@muon.bluestop.org> <20070807073920.GV50228@void.codelabs.ru> <46C18B60.8050400@moneybookers.com> <20070814145759.GB25169@void.codelabs.ru> <20070814193150.GA21553@rot26.obsecurity.org> <46C30FA6.7060108@moneybookers.com> <20070815145640.GQ988@void.codelabs.ru> <46C319DD.3010806@moneybookers.com> <20070815172731.GR988@void.codelabs.ru> <46C3FEBC.80409@moneybookers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <46C3FEBC.80409@moneybookers.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: current@freebsd.org Subject: Re: "tcpflags 0x18; tcp_do_segment" kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 08:05:27 -0000 Stefan, good day. Thu, Aug 16, 2007 at 10:37:32AM +0300, Stefan Lambrev wrote: > >To clarify a bit: are all two servers running -CURRENT, or just the > >client one? > > > Only mb7 is -current (i386), mb4 is 6.2 (i386). OK, fine. > The server is postfix, but the client is binary and we do not have the sources. But 'strings | grep -i quit' gives us both 'quit' and 'QUIT'? Just to be sure that it is the client who has these two SMTP answers inside. > I'll see what the creators can tell about this. OK, will wait for the information. Thank you! -- Eygene From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 08:27:11 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E75B116A419 for ; Thu, 16 Aug 2007 08:27:11 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by mx1.freebsd.org (Postfix) with ESMTP id A797013C481 for ; Thu, 16 Aug 2007 08:27:11 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so154426wxd for ; Thu, 16 Aug 2007 01:27:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=GLME3IPxQ2c6V2v6r5VObNWbx3/x09KNWigvNzdwDxiOxZMiPRWgaU7RUadDg+eh9HFX6APrnuQiuCJp32oFKNKAaCGb8JN8VS8Q9tjPXZHo6X9B3aukTw7ffH5vJ+U26c4S1LbTOoSPxqwitbbyYk494E9QXJJAMsFCCOLAhIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=UKpx0N7N5EwJ1B2gmezAh88ZNV97fZkLjRXrCbmXmhCqL9ch/A7I6vfFNk9EqNWvMGRSqjmsEk9QWi9TFRzZnNZr7uhPP58l8kCyp2mg8O1zem4e1OUDZfUYxUm4hZOkgtRNwG/A4GJ/6FBobMmJoct8VxbaE2zktsohaf6K0WE= Received: by 10.90.95.11 with SMTP id s11mr2035028agb.1187252830754; Thu, 16 Aug 2007 01:27:10 -0700 (PDT) Received: by 10.100.144.1 with HTTP; Thu, 16 Aug 2007 01:27:10 -0700 (PDT) Message-ID: <11167f520708160127l3478805at9c8375a70487c3a3@mail.gmail.com> Date: Thu, 16 Aug 2007 03:27:10 -0500 From: "Sam Fourman Jr." To: "Don Lewis" In-Reply-To: <200708110952.l7B9qp8C058494@gw.catspoiler.org> MIME-Version: 1.0 References: <20070811092626.GB22569@cdnetworks.co.kr> <200708110952.l7B9qp8C058494@gw.catspoiler.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, current@freebsd.org Subject: Re: bizarre nfe(4) problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 08:27:12 -0000 After some time fooling around with -CURRENT, it would appear that my ASUS Striker Extreme MotherBoard had a older Bios version 0701 dated 12/20/2006 after updating the Bios to 1301 dated 7/26/07 Everything worked again. Thank you for all of your Help Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 08:56:41 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57EE516A41B for ; Thu, 16 Aug 2007 08:56:41 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id A385913C469 for ; Thu, 16 Aug 2007 08:56:40 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILb9g-000M1d-Or; Thu, 16 Aug 2007 16:56:36 +0800 Message-ID: <46C41144.20809@micom.mng.net> Date: Thu, 16 Aug 2007 16:56:36 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.6 (X11/20070809) MIME-Version: 1.0 To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imp@bsdimp.com Subject: PR: usb/76653, usb/93389 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 08:56:41 -0000 Hi, The initial patch I sent to these PR (Pentax Optio S60 camera support) was working. However I didn't test the modified patch of Alex Demin (support at spectrum.ru). Probably it works too. Unfortunately I can not test my Pentax Optio S60 camera, because it is not working anymore through USB connection. Even in Windows it is not working. Maybe camera USB is broken because of static electricity. So I don't know how these PR should be handled, I guess the patch on these PR should be tested and then committed if needed. Or maybe recent CURRENT already supports this camera. Maybe I'm wrong here. Warner, can you check these PR if you have time? thanks a lot, Ganbold -- Skill without imagination is craftsmanship and gives us many useful objects such as wickerwork picnic baskets. Imagination without skill gives us modern art. -- Tom Stoppard From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 11:22:59 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2DF316A417 for ; Thu, 16 Aug 2007 11:22:59 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2001:1b20:1:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA3C13C47E for ; Thu, 16 Aug 2007 11:22:58 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (ofybur@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l7GBMeoQ097704; Thu, 16 Aug 2007 13:22:45 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l7GBMd2f097695; Thu, 16 Aug 2007 13:22:39 +0200 (CEST) (envelope-from olli) Date: Thu, 16 Aug 2007 13:22:39 +0200 (CEST) Message-Id: <200708161122.l7GBMd2f097695@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, Kris Kennaway , Randall Stewart , Kip Macy , Julian Elischer In-Reply-To: <20070815013342.GA25882@rot26.obsecurity.org> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 16 Aug 2007 13:22:46 +0200 (CEST) X-Mailman-Approved-At: Thu, 16 Aug 2007 11:27:48 +0000 Cc: Subject: Re: IP over HTTP? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 11:22:59 -0000 Kris Kennaway wrote: > Randall Stewart wrote: > > Julian Elischer wrote: > > > Kip Macy wrote: > > > > Randall Stewart wrote: > > > > > [IP over HTTP] > > > > > Just curious.. as anyone did this on BSD? > > > > > > > > I can guess. I believe there is an IPoDNS netgraph module floating > > > > around that *might* make a good reference. > > > > > > hmm OMG > > > /usr/ports/net/iodine !! > > > > Perfect... > > > > With some hacking I can use this as a starting point to make > > it run over web.. > > You mean like www/httptunnel? :) > > Basically all you need is a method of bidirectionally passing data > over whatever lower layer you want, then you can run ppp(8) over it. Or use ssh(1)'s -w option on top of www/httptunnel to forward a tun(4) interface through the http connection. It's dead easy. You can even set up a http tunnel with tools from the base system only, without needing anything from the ports collection. Just add this line to your ssh config: ProxyCommand /usr/bin/nc -X connect -x $PN:$PP %h %p where $PN is the proxy name and $PP is the proxy port. The use this command to establish an IP tunnel to $REMOTE_HOST (port 22): ssh -w any:any $REMOTE_HOST Or, if a different port $SSH_PORT is used: ssh -w any:any -p $SSH_PORT $REMOTE_HOST It will allocate one tun(4) device locally and one remote, which you then can configure with ifconfig(8). Requires root priviledges, of course. Note, however, that some HTTP proxies are configured to disallow connections to arbitrary ports, for security reasons. If that's the case for you, run you sshd server on port 443 wich should always be allowed by proxies (only possible if you don't already run a HTTPS server on port 443, of course). Note that you can have multiple "port" commands in your sshd_config, i.e. you can run your sshd server on both the standard port 22 and port 443. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python tricks" is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure . -- Tim Peters From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 12:45:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5957016A41B; Thu, 16 Aug 2007 12:45:29 +0000 (UTC) (envelope-from lists_freebsd_org@07.antispam.web-wahnsinn.de) Received: from webmailfront01.ispgateway.de (webmailfront01.ispgateway.de [80.67.16.111]) by mx1.freebsd.org (Postfix) with ESMTP id CE42B13C469; Thu, 16 Aug 2007 12:45:28 +0000 (UTC) (envelope-from lists_freebsd_org@07.antispam.web-wahnsinn.de) Received: from webmailfront01.ispgateway.de (localhost [127.0.0.1]) by webmailfront01.ispgateway.de (8.14.0/8.14.0) with ESMTP id l7GCj1UI020024; Thu, 16 Aug 2007 14:45:01 +0200 Received: (from nobody@localhost) by webmailfront01.ispgateway.de (8.14.0/8.14.0/Submit) id l7GCiwTo020022; Thu, 16 Aug 2007 14:44:58 +0200 Received: from p57A32BA1.dip0.t-ipconnect.de (p57A32BA1.dip0.t-ipconnect.de [87.163.43.161]) by webmail.df.eu (Horde MIME library) with HTTP; Thu, 16 Aug 2007 14:44:58 +0200 Message-ID: <20070816144458.kv2datmjkk4kcok8@webmail.df.eu> Date: Thu, 16 Aug 2007 14:44:58 +0200 From: Tobias Grosser To: Greg Lewis References: <1186303666.36623.23.camel@tobias.wg.> <20070815144804.GC5151@misty.eyesbeyond.com> In-Reply-To: <20070815144804.GC5151@misty.eyesbeyond.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: domainFACTORY X-Originating-IP: 87.163.43.161 Cc: freebsd-current@freebsd.org, freebsd-java@freebsd.org Subject: Re: Gcc bugs break java/jdk15 build? [Workaround] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 12:45:29 -0000 Zitat von Greg Lewis : > On Sun, Aug 05, 2007 at 10:47:46AM +0200, Tobias Grosser wrote: >> since the last gcc import (Update to 4.2) I had problems to compile >> java/jdk15 (using linux-sun-jdk14/15 and diablo-jdk15), because often >> the linux-sun-jdk crashed or I got the following errors: >> >> ../../../../../src/share/classes/sun/security/util/SignatureFileVerifier.= java:22: cannot find =20 >> symbol >> symbol : class timestamp >> location: package sun.security >> import sun.security.timestamp.TimestampToken; >> ^ > > Can you, and people with similar errors, try again after updating to a > -CURRENT after the GCC 4.2.1 import. This should fix these errors but > it would be great to get some confirmation. I tried already with the gcc 4.2.1 patch from =20 (http://people.freebsd.org/~kan/contrib-gcc421.tar.gz), but the build also breaks with optimization. (I am not sure, if it was =20 the same error) Without optimization it was working. When I am back from holiday at Tuesday, I will try again after gcc =20 import, and post the error log or report success. ;-) From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 13:52:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D1E016A41A; Thu, 16 Aug 2007 13:52:09 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.freebsd.org (Postfix) with ESMTP id 9CA7A13C469; Thu, 16 Aug 2007 13:52:08 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net by neerbosch.nijmegen.internl.net via neerbosch.nijmegen.internl.net [217.149.193.38] with ESMTP id l7GDp5UD023699 (8.13.4/1.4); Thu, 16 Aug 2007 15:51:05 +0200 (MEST) Received: from localhost by neerbosch.nijmegen.internl.net via mboland@localhost with ESMTP id l7GDp5Mk023677 (8.13.4/2.02); Thu, 16 Aug 2007 15:51:05 +0200 (MEST) X-Authentication-Warning: neerbosch.nijmegen.internl.net: mboland owned process doing -bs Date: Thu, 16 Aug 2007 15:51:05 +0200 (MEST) From: Michiel Boland To: Tobias Grosser In-Reply-To: <20070816144458.kv2datmjkk4kcok8@webmail.df.eu> Message-ID: References: <1186303666.36623.23.camel@tobias.wg.> <20070815144804.GC5151@misty.eyesbeyond.com> <20070816144458.kv2datmjkk4kcok8@webmail.df.eu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Greg Lewis , freebsd-current@freebsd.org, freebsd-java@freebsd.org Subject: Re: Gcc bugs break java/jdk15 build? [Workaround] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 13:52:09 -0000 > I tried already with the gcc 4.2.1 patch from > (http://people.freebsd.org/~kan/contrib-gcc421.tar.gz), > but the build also breaks with optimization. (I am not sure, if it was the > same error) Without optimization it was working. FWIW the builds succeeds for me if I add -fno-tree-vrp to OPT_CFLAGS: diff -ur o/jdk15.patches n/jdk15.patches --- o/jdk15.patches 2007-07-26 18:00:23.000000000 +0200 +++ n/jdk15.patches 2007-08-16 14:12:04.000000000 +0200 @@ -16460,7 +16460,7 @@ +CFLAGS += $(GCC_SAVE_TEMPS) + +# The flags to use for an Optimized g++ build -+OPT_CFLAGS += -O3 ++OPT_CFLAGS += -O3 -fno-tree-vrp +# Hotspot uses very unstrict aliasing turn this optimization off +OPT_CFLAGS += -fno-strict-aliasing + From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 15:40:52 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BBD116A418 for ; Thu, 16 Aug 2007 15:40:52 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp106.rog.mail.re2.yahoo.com (smtp106.rog.mail.re2.yahoo.com [68.142.225.204]) by mx1.freebsd.org (Postfix) with SMTP id B882513C47E for ; Thu, 16 Aug 2007 15:40:51 +0000 (UTC) (envelope-from mikej@rogers.com) Received: (qmail 1501 invoked from network); 16 Aug 2007 15:14:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Received:Message-ID:Date:Subject:From:To:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:Importance; b=pe37+4XNr4bsYBGs/9S4eZ5Sz+r+KqkyXKYI//MqnmSD7T4FvVVhPdYXkSJdzTIsjEnmUSs9f+OQBXKN8za9eZBysiGxtYpVxL0azPWb91wjI87EHZtRG4L7IRxtICuDcoS7/vM3If9iZlY16AC6W0V+pZ3ZFv2JF2PdDNw5Wog= ; Received: from unknown (HELO wettoast.dyndns.org) (mikej@rogers.com@99.244.15.156 with login) by smtp106.rog.mail.re2.yahoo.com with SMTP; 16 Aug 2007 15:14:11 -0000 X-YMail-OSG: 9qqwkfEVM1nS14NiJSmP9R2YNmAaGDESvKwRujwMvDMxgTMIsN4m.DQ1MDWTK9labQ-- Received: from 209.47.38.69 (SquirrelMail authenticated user mikej) by wettoast.dyndns.org with HTTP; Thu, 16 Aug 2007 11:14:08 -0400 (EDT) Message-ID: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> Date: Thu, 16 Aug 2007 11:14:08 -0400 (EDT) From: "Mike Jakubik" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: TCP info spamming the logs and dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 15:40:52 -0000 Hi Guys, I recently did an update on my -CURRENT system, and i am now seeing a lot of TCP messages from the kernel which are spamming my dmesg and /var/log/messages. --- TCP: [217.81.3.76]:2978 to [99.244.15.156]:80; syncache_timer: Response timeout, retransmitting (1) SYN|ACK TCP: [58.254.32.40]:6926 to [99.244.15.156]:21; syncache_timer: Retransmits exhausted, giving up and removing syncache entry TCP: [58.254.32.40]:4342 to [99.244.15.156]:21; syncache_timer: Response timeout, retransmitting (3) SYN|ACK TCP: [209.47.38.69]:17523 to [99.244.15.156]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored --- Is there any way to disable these, or have them log to a separate log? Thanks. From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 16:34:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BC9616A417 for ; Thu, 16 Aug 2007 16:34:12 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1213013C461 for ; Thu, 16 Aug 2007 16:34:12 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=cAMvKfHcRnU8e2XKu9HdblVc8//a6jUU8TNGoD8cYk4NJVF+FmJn8rNQTqfcUG6ib/nVeC7Dd27nP42/kp/Q2X/C/mSYf8UU0r15x2NCTovEO5jTO8Ez4yFeEjHe5wJeLRrMQBdjszJtV2OnXKFxJn+/RvdLV774WOmpbkCfVkA=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1ILiIU-000J2P-B6; Thu, 16 Aug 2007 20:34:10 +0400 Date: Thu, 16 Aug 2007 20:34:05 +0400 From: Eygene Ryabinkin To: Mike Jakubik Message-ID: <20070816163405.GG988@void.codelabs.ru> References: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.2 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_20 Cc: freebsd-current@freebsd.org Subject: Re: TCP info spamming the logs and dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 16:34:12 -0000 Mike, good day. Thu, Aug 16, 2007 at 11:14:08AM -0400, Mike Jakubik wrote: > I recently did an update on my -CURRENT system, and i am now seeing a lot > of TCP messages from the kernel which are spamming my dmesg and > /var/log/messages. > > --- > TCP: [217.81.3.76]:2978 to [99.244.15.156]:80; syncache_timer: Response > timeout, retransmitting (1) SYN|ACK > TCP: [58.254.32.40]:6926 to [99.244.15.156]:21; syncache_timer: > Retransmits exhausted, giving up and removing syncache entry > TCP: [58.254.32.40]:4342 to [99.244.15.156]:21; syncache_timer: Response > timeout, retransmitting (3) SYN|ACK > TCP: [209.47.38.69]:17523 to [99.244.15.156]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored > --- > > Is there any way to disable these, or have them log to a separate log? sysctl net.inet.tcp.log_debug=0 will disable them. -- Eygene From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 16:41:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAE8816A419; Thu, 16 Aug 2007 16:41:39 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 9D61C13C442; Thu, 16 Aug 2007 16:41:39 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=XjOE1qsZrJPJmzmsA1bTqdgt9hQJqWmtWqRPY2Z3tWCQpxYNYvxWVxGHIJ9Yy7myMLWG3Kp60tYq2jC9CQl3N3iUq2Iks8GIykkgcXi3J7W+5Rejfmwb0TTCP07GJ+5WV8lfe4acUtYLUsPLX2+GrcPMrNLxHNS1/Bd76rjekH4=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1ILiPh-000J5G-KP; Thu, 16 Aug 2007 20:41:37 +0400 Date: Thu, 16 Aug 2007 20:41:33 +0400 From: Eygene Ryabinkin To: andre@freebsd.org Message-ID: <20070816164133.GH988@void.codelabs.ru> References: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> <20070816163405.GG988@void.codelabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070816163405.GG988@void.codelabs.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-current@freebsd.org Subject: Re: TCP info spamming the logs and dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 16:41:40 -0000 Andre, good day. Thu, Aug 16, 2007 at 08:34:05PM +0400, Eygene Ryabinkin wrote: > Thu, Aug 16, 2007 at 11:14:08AM -0400, Mike Jakubik wrote: > > I recently did an update on my -CURRENT system, and i am now seeing a lot > > of TCP messages from the kernel which are spamming my dmesg and > > /var/log/messages. > > > > --- > > TCP: [217.81.3.76]:2978 to [99.244.15.156]:80; syncache_timer: Response > > timeout, retransmitting (1) SYN|ACK > > TCP: [58.254.32.40]:6926 to [99.244.15.156]:21; syncache_timer: > > Retransmits exhausted, giving up and removing syncache entry > > TCP: [58.254.32.40]:4342 to [99.244.15.156]:21; syncache_timer: Response > > timeout, retransmitting (3) SYN|ACK > > TCP: [209.47.38.69]:17523 to [99.244.15.156]:80 tcpflags 0x4; > > syncache_chkrst: Spurious RST without matching syncache entry (possibly > > syncookie only), segment ignored > > --- > > > > Is there any way to disable these, or have them log to a separate log? I had seen about four such questions for the last two weeks, so maybe it is time to patch tcp(4) manpage? The following is the very rough patch for it: --- tcp.4.orig 2007-08-16 20:35:06.000000000 +0400 +++ tcp.4 2007-08-16 20:37:33.000000000 +0400 @@ -259,6 +259,11 @@ Maximum .Tn TCP receive window. +.It Va log_debug +Enable (1) or disable (0) +.Tn TCP +stack debugging messages. +Default is 1, i.e., the logging is enabled. .It Va log_in_vain Log any connection attempts to ports where there is not a socket accepting connections. -- Eygene From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 16:49:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04F3216A419 for ; Thu, 16 Aug 2007 16:49:24 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from vps1.solepartners.com (vps1.solepartners.com [85.233.167.66]) by mx1.freebsd.org (Postfix) with ESMTP id 5E0C413C45A for ; Thu, 16 Aug 2007 16:49:23 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: (qmail 16269 invoked from network); 16 Aug 2007 16:22:42 -0000 Received: from 150.117-84-212.staticip.namesco.net (HELO prawn.unsane.co.uk) (212.84.117.150) by vps1.solepartners.com with SMTP; 16 Aug 2007 16:22:42 -0000 Message-ID: <46C479D1.7060400@unsane.co.uk> Date: Thu, 16 Aug 2007 17:22:41 +0100 From: Vince User-Agent: Thunderbird 2.0.0.6 (X11/20070808) MIME-Version: 1.0 To: Mike Jakubik References: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> In-Reply-To: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: TCP info spamming the logs and dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 16:49:24 -0000 Mike Jakubik wrote: > Hi Guys, > > I recently did an update on my -CURRENT system, and i am now seeing a lot > of TCP messages from the kernel which are spamming my dmesg and > /var/log/messages. > > --- > TCP: [217.81.3.76]:2978 to [99.244.15.156]:80; syncache_timer: Response > timeout, retransmitting (1) SYN|ACK > TCP: [58.254.32.40]:6926 to [99.244.15.156]:21; syncache_timer: > Retransmits exhausted, giving up and removing syncache entry > TCP: [58.254.32.40]:4342 to [99.244.15.156]:21; syncache_timer: Response > timeout, retransmitting (3) SYN|ACK > TCP: [209.47.38.69]:17523 to [99.244.15.156]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored > --- > > Is there any way to disable these, or have them log to a separate log? > I bbelieve you want to set net.inet.tcp.log_debug=0 Vince > Thanks. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 19:04:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61FFE16A419 for ; Thu, 16 Aug 2007 19:04:38 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.kuban.ru (mail.kuban.ru [62.183.66.246]) by mx1.freebsd.org (Postfix) with ESMTP id A9EA913C45B for ; Thu, 16 Aug 2007 19:04:37 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bsam.ru ([85.172.12.160]) by mail.kuban.ru (8.9.1/8.9.1) with ESMTP id l7GIiFUR080281; Thu, 16 Aug 2007 22:44:26 +0400 (MSD) Received: (from bsam@localhost) by bsam.ru (8.14.1/8.14.1/Submit) id l7GIiZrQ001220; Thu, 16 Aug 2007 22:44:35 +0400 (MSD) (envelope-from bsam@ipt.ru) X-Authentication-Warning: bsam.ru: bsam set sender to bsam@ipt.ru using -f To: "Vyacheslav I. Ivanchenko" References: <46C39EB5.6050701@dhs.net.ru> From: Boris Samorodov Date: Thu, 16 Aug 2007 22:44:35 +0400 In-Reply-To: <46C39EB5.6050701@dhs.net.ru> (Vyacheslav I. Ivanchenko's message of "Thu\, 16 Aug 2007 09\:47\:49 +0900") Message-ID: <86679404@bsam.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: Apache on Current Error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 19:04:38 -0000 On Thu, 16 Aug 2007 09:47:49 +0900 Vyacheslav I. Ivanchenko wrote: > I use 7.0-CURRENT from August, 14 2007. > I had problems with ports www/apache13-modssl, russian/apache13, > russian/apache13-modssl, after applying this patch the problem was > solved. There is no patch at your email. WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 19:52:17 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3602C16A41A for ; Thu, 16 Aug 2007 19:52:17 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id EFDAF13C442 for ; Thu, 16 Aug 2007 19:52:16 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.14.0/8.14.0) with ESMTP id l7GJqGux001815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Aug 2007 15:52:16 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l7GJpmsM001920; Thu, 16 Aug 2007 15:51:48 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18116.43755.107638.103132@grasshopper.cs.duke.edu> Date: Thu, 16 Aug 2007 15:51:48 -0400 (EDT) To: freebsd-current@freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Subject: IPSEC disables TSO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 19:52:17 -0000 When tracking down an mxge 10GbE performance issue, I noticed that simply compiling IPSEC into the kernel totally destroys 10GbE transmit performance because it will silently disable TSO. The problem seems to be at least that the test on line 463 of tcp_output.c (tp->t_inpcb->inp_sp == NULL) will always be false. If I comment that line out, TSO works as normal (though I have no idea what would happen on an IPSEC connection). Is there some way to make this not happen? I believe that the mxge user simply wanted to run some handful of applications through ipsec tunnels (perhaps even on a different NIC entirely). Thanks, Drew From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 19:53:49 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EDD916A418 for ; Thu, 16 Aug 2007 19:53:49 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id D3BE913C46B for ; Thu, 16 Aug 2007 19:53:48 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so213259nfb for ; Thu, 16 Aug 2007 12:53:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WveTYqfhjYVcPyKyXCIrh4dxewfVpywEfbnqAnJXW+MJfpzad/OWnvha+miJD54i+ENmiEElcIftYHIL/32lekMdr2qGmjt/7BPLGfo4OuIk2uxmjtsuLb0y19dlzVsEir6pFMr/T+Awp/gEVQzKg41aVlf/sdcj2TYq7+gRSOE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IWHHd5OEIxrDZNRsNqt3dczrEOLzvBJApD8buTZ9YRIpAvkKW6aS87hhU+KxPoA/Wqx+57FhHs5fUVhqjKZnjomRMmWRhAi9YHQCciTjM2EhcgO0fqQ2eberhbmOQWVBNDIFgyi9j34TTZnGMvdrnZf8CGMJdstD/fpVhRK78B4= Received: by 10.78.200.3 with SMTP id x3mr787369huf.1187294026886; Thu, 16 Aug 2007 12:53:46 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Thu, 16 Aug 2007 12:53:46 -0700 (PDT) Message-ID: Date: Thu, 16 Aug 2007 12:53:46 -0700 From: "Kip Macy" To: "Andrew Gallatin" In-Reply-To: <18116.43755.107638.103132@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <18116.43755.107638.103132@grasshopper.cs.duke.edu> Cc: freebsd-current@freebsd.org Subject: Re: IPSEC disables TSO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 19:53:49 -0000 On 8/16/07, Andrew Gallatin wrote: > > When tracking down an mxge 10GbE performance issue, I noticed that > simply compiling IPSEC into the kernel totally destroys 10GbE transmit > performance because it will silently disable TSO. > > The problem seems to be at least that the test on line 463 of > tcp_output.c (tp->t_inpcb->inp_sp == NULL) will always be > false. If I comment that line out, TSO works as normal > (though I have no idea what would happen on an IPSEC connection). > > Is there some way to make this not happen? I believe that the mxge > user simply wanted to run some handful of applications through ipsec > tunnels (perhaps even on a different NIC entirely). IPSEC encrypts the TCP header - how is the card going to do TSO? -Kip From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 19:56:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0B4516A420 for ; Thu, 16 Aug 2007 19:56:24 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 7060B13C459 for ; Thu, 16 Aug 2007 19:56:24 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so213723nfb for ; Thu, 16 Aug 2007 12:56:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uYiClh/Wv3jSR+OhmAFfSiDNzvIhbO5nWAGUoiquPgT7iqijLeJiQnxinCXj7fn6kajsFzE+ab8vtqExpgYQq+S86Cdj2T2785Nswn8OtehsrhH+YP+IEpluJQ4lcN+Ejh/XWSMYRELZF3WxYxP3e5babygcMHGE46JTMKm5N68= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=T5H23bfQ9xXHVUv4ieEYyAcU9aS3BDmwz64aJct3r6uEsCjqaACel9ujlza4N479N2YDcBN6zAPvwHk0wX5Cwq5ZSIkt2yjyEO07NHeR45f0LwR84y60YCVrNaUjBov5DHkCV+ZElPjupWldkB768A3bcw0ZMNko1AEYrNhnMqo= Received: by 10.78.160.4 with SMTP id i4mr783371hue.1187294182649; Thu, 16 Aug 2007 12:56:22 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Thu, 16 Aug 2007 12:56:22 -0700 (PDT) Message-ID: Date: Thu, 16 Aug 2007 12:56:22 -0700 From: "Kip Macy" To: "Andrew Gallatin" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <18116.43755.107638.103132@grasshopper.cs.duke.edu> Cc: freebsd-current@freebsd.org Subject: Re: IPSEC disables TSO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 19:56:25 -0000 On 8/16/07, Kip Macy wrote: > On 8/16/07, Andrew Gallatin wrote: > > > > When tracking down an mxge 10GbE performance issue, I noticed that > > simply compiling IPSEC into the kernel totally destroys 10GbE transmit > > performance because it will silently disable TSO. > > > > The problem seems to be at least that the test on line 463 of > > tcp_output.c (tp->t_inpcb->inp_sp == NULL) will always be > > false. If I comment that line out, TSO works as normal > > (though I have no idea what would happen on an IPSEC connection). > > > > Is there some way to make this not happen? I believe that the mxge > > user simply wanted to run some handful of applications through ipsec > > tunnels (perhaps even on a different NIC entirely). > > IPSEC encrypts the TCP header - how is the card going to do TSO? I thought about this after sending and realized that the appropriate response is that IPSEC needs to be careful to disable TSO when its in use for a connection. What you're seeing was most likely done as an expedient. -Kip From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 20:06:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1424A16A421 for ; Thu, 16 Aug 2007 20:06:46 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id C5D6813C467 for ; Thu, 16 Aug 2007 20:06:45 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.14.0/8.14.0) with ESMTP id l7GK6jUE003843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 16:06:45 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l7GK6H4Y001942; Thu, 16 Aug 2007 16:06:17 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18116.44624.144286.621286@grasshopper.cs.duke.edu> Date: Thu, 16 Aug 2007 16:06:17 -0400 (EDT) To: "Kip Macy" In-Reply-To: References: <18116.43755.107638.103132@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-current@freebsd.org Subject: Re: IPSEC disables TSO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 20:06:46 -0000 Kip Macy writes: > On 8/16/07, Kip Macy wrote: > > On 8/16/07, Andrew Gallatin wrote: > > > > > > When tracking down an mxge 10GbE performance issue, I noticed that > > > simply compiling IPSEC into the kernel totally destroys 10GbE transmit > > > performance because it will silently disable TSO. > > > > > > The problem seems to be at least that the test on line 463 of > > > tcp_output.c (tp->t_inpcb->inp_sp == NULL) will always be > > > false. If I comment that line out, TSO works as normal > > > (though I have no idea what would happen on an IPSEC connection). > > > > > > Is there some way to make this not happen? I believe that the mxge > > > user simply wanted to run some handful of applications through ipsec > > > tunnels (perhaps even on a different NIC entirely). > > > > IPSEC encrypts the TCP header - how is the card going to do TSO? > > > I thought about this after sending and realized that the appropriate > response is that IPSEC needs to be careful to disable TSO when its in > use for a connection. What you're seeing was most likely done as an > expedient. Yes, exactly, there needs to be a smarter test that can distingiush if IPSEC is actually in use on a connection or not; I should have been more clear about this. The problem is that I have zero knowledge about IPSEC, so I have no idea how to do this. I'm worried that people will compile IPSEC into the kernel to run an encrypted tunnel (or the TCP MD5 signature stuff for BGP), and then be rather surprised that their their "normal" TCP performance stinks. Drew From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 20:10:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0092316A419 for ; Thu, 16 Aug 2007 20:10:12 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 72B9213C459 for ; Thu, 16 Aug 2007 20:10:11 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so216388nfb for ; Thu, 16 Aug 2007 13:10:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=J9fjfrrFXw9uGoGV/Pf6bU4q9i1eljcCzeZBRquxpaiHnrAYfKhXzroar8G6NZtObaVhSFS9uxKmgKDtRKoLHAV4XOxQ0rA6IP4z9YfOYWX+4dhJbL9KLmzYPk5NAmylPHgYEM+zc7oisQHTxzPpQuvGYL2zLjaLLm5MPseBSDM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Scgr2oQ6RKhFieBFoK9hlUj/UoUrtS6XDTYFkHZb1sJlqSIPdRgfS63FbkLmEyp26gqTJnRcexTHBZ3HWYzz63rZ4apPLTWHOA0zZjGonpnMRgRH+PPOhACZ7wPFj3EMy5gn+Sop604I5pWSlET6rJ5XW66Dk5FDEu744HnX1xA= Received: by 10.78.200.20 with SMTP id x20mr791845huf.1187295009640; Thu, 16 Aug 2007 13:10:09 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Thu, 16 Aug 2007 13:10:09 -0700 (PDT) Message-ID: Date: Thu, 16 Aug 2007 13:10:09 -0700 From: "Kip Macy" To: "Andrew Gallatin" In-Reply-To: <18116.44624.144286.621286@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <18116.43755.107638.103132@grasshopper.cs.duke.edu> <18116.44624.144286.621286@grasshopper.cs.duke.edu> Cc: freebsd-current@freebsd.org Subject: Re: IPSEC disables TSO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 20:10:12 -0000 > > Yes, exactly, there needs to be a smarter test that can distingiush if > IPSEC is actually in use on a connection or not; I should have been > more clear about this. The problem is that I have zero knowledge > about IPSEC, so I have no idea how to do this. > > I'm worried that people will compile IPSEC into the kernel to run an > encrypted tunnel (or the TCP MD5 signature stuff for BGP), and > then be rather surprised that their their "normal" TCP performance > stinks. Maybe file it as a PR? -Kip From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 20:44:01 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0E9C16A41B for ; Thu, 16 Aug 2007 20:44:01 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7163713C4B3 for ; Thu, 16 Aug 2007 20:44:01 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.14.0/8.14.0) with ESMTP id l7GKi0qX008593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 16:44:00 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l7GKhWS7002007; Thu, 16 Aug 2007 16:43:32 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18116.46859.409749.756304@grasshopper.cs.duke.edu> Date: Thu, 16 Aug 2007 16:43:32 -0400 (EDT) To: "Kip Macy" In-Reply-To: References: <18116.43755.107638.103132@grasshopper.cs.duke.edu> <18116.44624.144286.621286@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-current@freebsd.org Subject: Re: IPSEC disables TSO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 20:44:01 -0000 Kip Macy writes: > > > > Yes, exactly, there needs to be a smarter test that can distingiush if > > IPSEC is actually in use on a connection or not; I should have been > > more clear about this. The problem is that I have zero knowledge > > about IPSEC, so I have no idea how to do this. > > > > I'm worried that people will compile IPSEC into the kernel to run an > > encrypted tunnel (or the TCP MD5 signature stuff for BGP), and > > then be rather surprised that their their "normal" TCP performance > > stinks. > > Maybe file it as a PR? Good idea. http://www.freebsd.org/cgi/query-pr.cgi?pr=115586 Drew From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 21:01:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 019B316A419 for ; Thu, 16 Aug 2007 21:01:43 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp100.rog.mail.re2.yahoo.com (smtp100.rog.mail.re2.yahoo.com [206.190.36.78]) by mx1.freebsd.org (Postfix) with SMTP id 8B9CE13C47E for ; Thu, 16 Aug 2007 21:01:42 +0000 (UTC) (envelope-from mikej@rogers.com) Received: (qmail 5997 invoked from network); 16 Aug 2007 21:01:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=H+qAp0Rf8K1Jymxwp9kjkILfGAuuaVses26KeJ9aX0VShDoRODIah5FxeD8nZYT9AvJRFIpJKwzf0PkKeRo8Cj9uiPRQMtWmfRpCI7DZrJSHyWeX94MRp0DZ5E4AuYXnXfqy9M8M88FZxDKsSc59s/81N0cTyX6ivDXm2dR6GR4= ; Received: from unknown (HELO ?172.16.0.165?) (mikej@rogers.com@99.244.15.156 with plain) by smtp100.rog.mail.re2.yahoo.com with SMTP; 16 Aug 2007 21:01:34 -0000 X-YMail-OSG: 2yg7HV0VM1nocE9Vfb2MTaDPjKRYfQ0FaZs3E7m6b49e7npEZgk.6FxeBmc2Yws6KQ-- Message-ID: <46C4BB28.8030000@rogers.com> Date: Thu, 16 Aug 2007 17:01:28 -0400 From: Mike Jakubik User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eygene Ryabinkin References: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> <20070816163405.GG988@void.codelabs.ru> In-Reply-To: <20070816163405.GG988@void.codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: TCP info spamming the logs and dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 21:01:43 -0000 Eygene Ryabinkin wrote: > Mike, good day. > > Thu, Aug 16, 2007 at 11:14:08AM -0400, Mike Jakubik wrote: > >> Is there any way to disable these, or have them log to a separate log? >> > > sysctl net.inet.tcp.log_debug=0 will disable them. > Thanks, that does the job. From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 21:04:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5141016A512 for ; Thu, 16 Aug 2007 21:04:46 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp104.rog.mail.re2.yahoo.com (smtp104.rog.mail.re2.yahoo.com [206.190.36.82]) by mx1.freebsd.org (Postfix) with SMTP id DCD1613C468 for ; Thu, 16 Aug 2007 21:04:45 +0000 (UTC) (envelope-from mikej@rogers.com) Received: (qmail 10337 invoked from network); 16 Aug 2007 21:04:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Uh0RwHmXsonugqT35Px6IErhHi09CgYBn55bTjZLbu1S+4209CopZ8iq5pS90TvMhRS37V+NX5rwo2dHqxpvLg81C+nVRBt6rNSjlWRr31xB5fPXtTrY2vdtOiNjtgmsj9QMDDEVjPR1oOsRngWuKt0hJ8SV3Wtzl08Ro38Ktio= ; Received: from unknown (HELO ?172.16.0.165?) (mikej@rogers.com@99.244.15.156 with plain) by smtp104.rog.mail.re2.yahoo.com with SMTP; 16 Aug 2007 21:04:45 -0000 X-YMail-OSG: k.QCPGgVM1n46dAZaMjPKqJSu2lwbjtyxsYsZEJB0E.k8vPtczK7quYSWQMnrwlwFA-- Message-ID: <46C4BBE7.5000908@rogers.com> Date: Thu, 16 Aug 2007 17:04:39 -0400 From: Mike Jakubik User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eygene Ryabinkin References: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> <20070816163405.GG988@void.codelabs.ru> <20070816164133.GH988@void.codelabs.ru> In-Reply-To: <20070816164133.GH988@void.codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, andre@freebsd.org Subject: Re: TCP info spamming the logs and dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 21:04:46 -0000 Eygene Ryabinkin wrote: > Andre, good day. > > Thu, Aug 16, 2007 at 08:34:05PM +0400, Eygene Ryabinkin wrote: > >> Thu, Aug 16, 2007 at 11:14:08AM -0400, Mike Jakubik wrote: >> >>> Is there any way to disable these, or have them log to a separate log? >>> > > I had seen about four such questions for the last two weeks, so maybe > it is time to patch tcp(4) manpage? The following is the very rough > patch for it: > --- tcp.4.orig 2007-08-16 20:35:06.000000000 +0400 > +++ tcp.4 2007-08-16 20:37:33.000000000 +0400 > @@ -259,6 +259,11 @@ > Maximum > .Tn TCP > receive window. > +.It Va log_debug > +Enable (1) or disable (0) > +.Tn TCP > +stack debugging messages. > +Default is 1, i.e., the logging is enabled. > .It Va log_in_vain > Log any connection attempts to ports where there is not a socket > accepting connections. > That sounds like a good idea, perhaps it would also be a good idea to set the default to 0? From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 21:49:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F45616A420; Thu, 16 Aug 2007 21:49:51 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id C0F8113C46A; Thu, 16 Aug 2007 21:49:50 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=F0fuIvfLL35QQo+lZYt0DpMCkjs6c2YTsXzLGRygpl2afflxbEwyoTYKMKlZhp1hcqS1oX0QYwPlkQFWbHG8+TpG81KdkvAhyY0njxIntmWzMC53iOusarDQP5F5A/PywOjhicQR/kdDT2r6j2eXXhNOxkDlPuaCOBgKfJeTK2o=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1ILnDu-000KsR-C9; Fri, 17 Aug 2007 01:49:46 +0400 Date: Fri, 17 Aug 2007 01:49:41 +0400 From: Eygene Ryabinkin To: Mike Jakubik Message-ID: <20070816214941.GI988@void.codelabs.ru> References: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> <20070816163405.GG988@void.codelabs.ru> <20070816164133.GH988@void.codelabs.ru> <46C4BBE7.5000908@rogers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <46C4BBE7.5000908@rogers.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-current@freebsd.org, andre@freebsd.org Subject: Re: TCP info spamming the logs and dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 21:49:51 -0000 Thu, Aug 16, 2007 at 05:04:39PM -0400, Mike Jakubik wrote: > That sounds like a good idea, perhaps it would also be a good idea to set the > default to 0? See http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c#rev1.365 After reading the commit log I had sligtly modified the patch for the tcp(4) to reflect the coupling to log_in_vain: --- tcp.4.orig 2007-08-16 20:35:06.000000000 +0400 +++ tcp.4 2007-08-17 01:45:42.000000000 +0400 @@ -259,6 +259,14 @@ Maximum .Tn TCP receive window. +.It Va log_debug +Enable (1) or disable (0) +.Tn TCP +stack debugging messages. +Default is 1, i.e., the logging is enabled. +Note that enabling this variable will also enable +.Tn log_in_vain +option. .It Va log_in_vain Log any connection attempts to ports where there is not a socket accepting connections. -- Eygene From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 22:04:09 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 796E416A419; Thu, 16 Aug 2007 22:04:09 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 278D313C428; Thu, 16 Aug 2007 22:04:09 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 33BD120B0; Fri, 17 Aug 2007 00:04:00 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 23688208A; Fri, 17 Aug 2007 00:04:00 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 0DAA78444F; Fri, 17 Aug 2007 00:04:00 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: current@freebsd.org References: <1187099341.17556.44.camel@opus.cse.buffalo.edu> <20070814165423.ebuvjb6dwswkgc8g@webmail.leidinger.net> <20070814153519.GA18648@rot26.obsecurity.org> <86643h3isp.fsf@ds4.des.no> <20070814213515.GA23492@rot26.obsecurity.org> <86d4xp21i3.fsf@ds4.des.no> <86lkccorig.fsf@ds4.des.no> <86tzqz5ia2.fsf@ds4.des.no> <86k5rv5eeg.fsf_-_@ds4.des.no> Date: Fri, 17 Aug 2007 00:03:59 +0200 In-Reply-To: <86k5rv5eeg.fsf_-_@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm?= =?utf-8?Q?=C3=B8rgrav=22's?= message of "Thu\, 16 Aug 2007 23\:59\:51 +0200") Message-ID: <86fy2j5e7k.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: pjd@freebsd.org, mohans@freebsd.org Subject: Re: NFS hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 22:04:09 -0000 Dag-Erling Sm=C3=B8rgrav writes: > Fresh 7.0-CURRENT-200706-i386 install; no rc.conf, no configuration > other than listing the root fs in /etc/fstab and symlinking /boot/kernel > to /boot/GENERIC; PXE / NFS unattended boot to multiuser hangs while > writing /var/run/dmesg.boot. The file remains empty on the NFS server. > Complete tcpdump (from power-on to reset) attached. 10.0.0.4 is the > server ("ds4"), 10.0.0.10 is the client ("xps"). I just realized mailman will diligently block the attachment. You can get it from (~6 MB). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 22:22:01 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18BCB16A41A for ; Thu, 16 Aug 2007 22:22:01 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from mail.itu.dk (pluto.itu.dk [130.226.142.18]) by mx1.freebsd.org (Postfix) with ESMTP id C778413C46B for ; Thu, 16 Aug 2007 22:22:00 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from localhost (unknown [10.0.0.3]) by mail.itu.dk (Postfix) with ESMTP id 6F51732CFD1 for ; Fri, 17 Aug 2007 00:21:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at itu.dk Received: from superman.itu.dk ([130.226.142.5]) by localhost (daredevil.itu.dk [130.226.142.26]) (amavisd-new, port 10024) with ESMTP id FJ4+A2Pp9o0L for ; Fri, 17 Aug 2007 00:21:50 +0200 (CEST) Received: from wimac.littlebit.dk (unknown [85.233.238.191]) by superman.itu.dk (Postfix) with ESMTP id D2BA89E233 for ; Fri, 17 Aug 2007 00:21:50 +0200 (CEST) Message-ID: <46C4CDF9.6040200@cederstrand.dk> Date: Fri, 17 Aug 2007 00:21:45 +0200 From: Erik Cederstrand User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <46C2C19D.9090700@cederstrand.dk> In-Reply-To: <46C2C19D.9090700@cederstrand.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Feedback for performance tracker X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 22:22:01 -0000 Erik Cederstrand wrote: > Hi! > > This autumn, we have decided to grab the Performance Tracker entry[1] > from the project ideas page and give it a spin as a subject for our > thesis at the IT University of Copenhagen. The tracker intends to fill a > hole in the range of tinderboxes and automatic stress/regression tests > that FreeBSD already has. [...] We'd like to thank everyone for their valuable comments and ideas. I can say with certainty that we'll only complete a small subset of the ideas posted, but we'll do our best to get a useful tool going and keep you updated on the progress. It's interesting to see that apparently only one person actually runs benchmarks regularly :-) Erik From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 22:23:07 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0D0316A419 for ; Thu, 16 Aug 2007 22:23:07 +0000 (UTC) (envelope-from cb@severious.net) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 9842513C467 for ; Thu, 16 Aug 2007 22:23:07 +0000 (UTC) (envelope-from cb@severious.net) Received: by ion.gank.org (Postfix, from userid 1001) id 7714E10FAB; Thu, 16 Aug 2007 17:04:37 -0500 (CDT) Date: Thu, 16 Aug 2007 17:04:36 -0500 From: Craig Boston To: Kip Macy Message-ID: <20070816220427.GA6457@nowhere> Mail-Followup-To: Craig Boston , Kip Macy , Andrew Gallatin , freebsd-current@freebsd.org References: <18116.43755.107638.103132@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Andrew Gallatin Subject: Re: IPSEC disables TSO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 22:23:07 -0000 On Thu, Aug 16, 2007 at 12:53:46PM -0700, Kip Macy wrote: > IPSEC encrypts the TCP header - how is the card going to do TSO? Maybe I'm missing something, but I don't understand why IPSEC should have to disable TSO at all. Of course encrypted packets won't be able to take advantage of TSO, but by the time they reach the NIC, they're not TCP anymore. They're IP protocol 50 (ESP). Shouldn't TSO simply be ignoring protocols other than TCP? Craig From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 22:53:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A29CB16A41A for ; Thu, 16 Aug 2007 22:53:33 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp108.rog.mail.re2.yahoo.com (smtp108.rog.mail.re2.yahoo.com [68.142.225.206]) by mx1.freebsd.org (Postfix) with SMTP id 361FA13C45D for ; Thu, 16 Aug 2007 22:53:32 +0000 (UTC) (envelope-from mikej@rogers.com) Received: (qmail 6479 invoked from network); 16 Aug 2007 22:53:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=khrArHsz4+QwdR6p1S3OWLXG8C1ly8zxbvAB5BQGEe1ZljxWgjSeKHFDn2ISIx5ZAdyesbCFxK2IcBKyxnLhjBv4Q5h5Xc+oI9e3TnOUU32LuiMSmrFVr7lu8c7aAf4kOpgu7Xk09PB7C/+W+b22bPBhXUvr7XRCwcHc8D0HpCM= ; Received: from unknown (HELO ?172.16.0.165?) (mikej@rogers.com@99.244.15.156 with plain) by smtp108.rog.mail.re2.yahoo.com with SMTP; 16 Aug 2007 22:53:32 -0000 X-YMail-OSG: yjt_DRQVM1k3ns9p.In9cLS3048cIKJAwgkpgTwcE6yxcrf_tedJ_NU92ycJWKY.tA-- Message-ID: <46C4D566.1060505@rogers.com> Date: Thu, 16 Aug 2007 18:53:26 -0400 From: Mike Jakubik User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eygene Ryabinkin References: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> <20070816163405.GG988@void.codelabs.ru> <20070816164133.GH988@void.codelabs.ru> <46C4BBE7.5000908@rogers.com> <20070816214941.GI988@void.codelabs.ru> In-Reply-To: <20070816214941.GI988@void.codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, andre@freebsd.org Subject: Re: TCP info spamming the logs and dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2007 22:53:33 -0000 Eygene Ryabinkin wrote: > Thu, Aug 16, 2007 at 05:04:39PM -0400, Mike Jakubik wrote: > >> That sounds like a good idea, perhaps it would also be a good idea to set the >> default to 0? >> > > See http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c#rev1.365 > > After reading the commit log I had sligtly modified the patch for > the tcp(4) to reflect the coupling to log_in_vain: > Ahh, i see. I also see that that you plan on setting it to 0 for the release, good stuff :) From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 01:43:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6F4116A468 for ; Fri, 17 Aug 2007 01:43:36 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from smtp02.dentaku.gol.com (smtp02.dentaku.gol.com [203.216.5.72]) by mx1.freebsd.org (Postfix) with ESMTP id AFE6D13C46A for ; Fri, 17 Aug 2007 01:43:36 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[127.0.0.1]) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1ILqsA-0007hY-UX for ; Fri, 17 Aug 2007 10:43:35 +0900 Message-ID: <46C4FD44.1060105@fusiongol.com> Date: Fri, 17 Aug 2007 10:43:32 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV GOL X-Abuse-Complaints: abuse@gol.com Subject: Promise SATA 300 TX4 cause X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 01:43:37 -0000 After some poking around, I can confirm Karsten's report that it is indeed the following edit that causes problems with the Promise card: http://lists.freebsd.org/pipermail/cvs-src/2007-June/079930.html a csup with date=2007.06.16.03.00.00 is ok, but a csup with date=2007.06.16.06.00.00 introduces the vm updates and breaks the operation of the card (resulting in many checksum errors in my ZFS pool, and an eventual system lockup after a good amount of time) From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 02:12:05 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 826DF16A417; Fri, 17 Aug 2007 02:12:05 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from ns.trinitel.com (186.161.36.72.static.reverse.ltdomains.com [72.36.161.186]) by mx1.freebsd.org (Postfix) with ESMTP id 5525413C442; Fri, 17 Aug 2007 02:12:05 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from neutrino.vnode.org (r74-193-81-203.pfvlcmta01.grtntx.tl.dh.suddenlink.net [74.193.81.203]) (authenticated bits=0) by ns.trinitel.com (8.14.1/8.14.1) with ESMTP id l7H2C1SE007281 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2007 21:12:02 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46C503EC.1090309@freebsd.org> Date: Thu, 16 Aug 2007 21:11:56 -0500 From: Eric Anderson User-Agent: Thunderbird 2.0.0.6 (X11/20070816) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <1187099341.17556.44.camel@opus.cse.buffalo.edu> <20070814165423.ebuvjb6dwswkgc8g@webmail.leidinger.net> <20070814153519.GA18648@rot26.obsecurity.org> <86643h3isp.fsf@ds4.des.no> <20070814213515.GA23492@rot26.obsecurity.org> <86d4xp21i3.fsf@ds4.des.no> <86lkccorig.fsf@ds4.des.no> <86tzqz5ia2.fsf@ds4.des.no> <86k5rv5eeg.fsf_-_@ds4.des.no> <86fy2j5e7k.fsf@ds4.des.no> In-Reply-To: <86fy2j5e7k.fsf@ds4.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on ns.trinitel.com Cc: pjd@freebsd.org, current@freebsd.org, mohans@freebsd.org Subject: Re: NFS hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 02:12:05 -0000 On 08/16/07 17:03, Dag-Erling Smørgrav wrote: > Dag-Erling Smørgrav writes: >> Fresh 7.0-CURRENT-200706-i386 install; no rc.conf, no configuration >> other than listing the root fs in /etc/fstab and symlinking /boot/kernel >> to /boot/GENERIC; PXE / NFS unattended boot to multiuser hangs while >> writing /var/run/dmesg.boot. The file remains empty on the NFS server. >> Complete tcpdump (from power-on to reset) attached. 10.0.0.4 is the >> server ("ds4"), 10.0.0.10 is the client ("xps"). > > I just realized mailman will diligently block the attachment. You can > get it from (~6 MB). > > DES Looks like it's not getting a response from the NFS server when trying to write to a log file (dmesg.boot) - no response from the NFSv2 UDP write packets. You don't happen to have a trace from the server, do you? Eric From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 02:56:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A5FC16A417 for ; Fri, 17 Aug 2007 02:56:45 +0000 (UTC) (envelope-from qumqats@outel.org) Received: from outel.org (outel.org [69.12.226.165]) by mx1.freebsd.org (Postfix) with ESMTP id E4B3313C442 for ; Fri, 17 Aug 2007 02:56:44 +0000 (UTC) (envelope-from qumqats@outel.org) Received: from winxp ([192.168.1.20]) by outel.org with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ILrl0-0006sd-7w for freebsd-current@freebsd.org; Thu, 16 Aug 2007 19:40:14 -0700 Date: Thu, 16 Aug 2007 19:40:10 -0700 From: "Joel M. Baldwin" cc: freebsd-current@freebsd.org Message-ID: In-Reply-To: <46C4BB28.8030000@rogers.com> References: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> <20070816163405.GG988@void.codelabs.ru> <46C4BB28.8030000@rogers.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: TCP info spamming the logs and dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 02:56:45 -0000 --On Thursday, August 16, 2007 5:01 PM -0400 Mike Jakubik wrote: > Eygene Ryabinkin wrote: >> Mike, good day. >> >> Thu, Aug 16, 2007 at 11:14:08AM -0400, Mike Jakubik wrote: >> >>> Is there any way to disable these, or have them log to a separate log? >>> >> >> sysctl net.inet.tcp.log_debug=0 will disable them. >> > > Thanks, that does the job. Well it doesn't fix it for me! # sysctl net.inet.tcp.log_debug=0 sysctl: unknown oid 'net.inet.tcp.log_debug' Is there some dependency in the kernel for this to work to stop the logging? From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 03:30:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E54516A418 for ; Fri, 17 Aug 2007 03:30:45 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id 4831D13C45E for ; Fri, 17 Aug 2007 03:30:45 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so324924rvb for ; Thu, 16 Aug 2007 20:30:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AOiuZclHSC5y//N8guVLc1U3zQJUvxpW2s2v2vwkeoHtdFL0HiXJbOuQwvTkhATdo8kYHlKGyqHNXnPnBA63On5gWEzj1ZGykep3mEFiAAzmibsdcuGmkHh5TVzejGkNUw3vqXkfDlQ56ip7jjDvo7PQWsNIJIOFt9YRcEukeFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p2LCRKmhmt+TvoQcvZ8zo1ZwxRrCtt6tctDpdfkOmhzwztMuf04SKIkkq715r+ayH6at06oB0WOhpxUDG0jvZhIDN0tqouWP5M7cELdkoXOm3DiwrSJGGKz9ljV1zcNhwSQQGJXZtIvTVTQeSk3vSQs5MC8+eHr+5472zMiLFZ8= Received: by 10.114.210.2 with SMTP id i2mr1857759wag.1187319900954; Thu, 16 Aug 2007 20:05:00 -0700 (PDT) Received: by 10.114.76.7 with HTTP; Thu, 16 Aug 2007 20:05:00 -0700 (PDT) Message-ID: Date: Thu, 16 Aug 2007 23:05:00 -0400 From: "Scott Ullrich" To: "Joel M. Baldwin" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> <20070816163405.GG988@void.codelabs.ru> <46C4BB28.8030000@rogers.com> Cc: freebsd-current@freebsd.org Subject: Re: TCP info spamming the logs and dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 03:30:45 -0000 On 8/16/07, Joel M. Baldwin wrote: > Well it doesn't fix it for me! > > # sysctl net.inet.tcp.log_debug=0 > sysctl: unknown oid 'net.inet.tcp.log_debug' > > Is there some dependency in the kernel for this to work to stop the logging? This was commited on July 28 at 12:20;40 UTC. By chance is your kernel younger than this commit? http://lists.freebsd.org/pipermail/cvs-src/2007-July/080961.html Scott From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 01:21:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6637516A417 for ; Fri, 17 Aug 2007 01:21:29 +0000 (UTC) (envelope-from ivi@asiamusic.ru) Received: from atlant.asiamusic.ru (AsiaTrade-Orient.orient.net.ru [195.161.236.162]) by mx1.freebsd.org (Postfix) with ESMTP id F39D013C442 for ; Fri, 17 Aug 2007 01:21:28 +0000 (UTC) (envelope-from ivi@asiamusic.ru) Received: from atlant.asiamusic.ru (localhost [127.0.0.1]) by atlant.asiamusic.ru (Postfix) with ESMTP id BE3BF1CC48; Fri, 17 Aug 2007 09:51:32 +0900 (IRKST) Received: from topaz.dhs.net.ru (webmaster.asiamusic.lan [192.168.125.10]) by atlant.asiamusic.ru (Postfix) with ESMTP id 96DB51CC44; Fri, 17 Aug 2007 09:51:32 +0900 (IRKST) Message-ID: <46C4F111.20903@asiamusic.ru> Date: Fri, 17 Aug 2007 09:51:29 +0900 From: "Vyacheslav I. Ivanchenko" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.6) Gecko/20070810 SeaMonkey/1.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org, bsam@ipt.ru References: 46C39EB5.6050701@dhs.net.ru Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Fri, 17 Aug 2007 03:32:51 +0000 Cc: Subject: Apache on Current Error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 01:21:29 -0000 http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/apache13/files/patch-ae # uname -mrs FreeBSD 7.0-CURRENT i386 # cd /usr/ports/www/apache13-modssl && make install clean && rehash # /usr/local/etc/rc.d/apache.sh start Starting apache. Syntax error on line 205 of /usr/local/etc/apache/httpd.conf: Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: /usr/local/libexec/apache/mod_mmap_static.so: Undefined symbol "ap_null_cleanup" # pkg_delete apache+mod_ssl-1.3.37+2.8.28 # cp -Rp /usr/ports/www/apache13/files/patch-ae /usr/ports/www/apache13-modssl/files/patch-az # cd /usr/ports/www/apache13-modssl && make install clean && rehash # /usr/local/etc/rc.d/apache.sh start Starting apache. # ps -ax | grep httpd 18791 ?? Ss 0:00,05 /usr/local/sbin/httpd -DSSL 18792 ?? S 0:00,00 /usr/local/sbin/httpd -DSSL 18793 ?? S 0:00,00 /usr/local/sbin/httpd -DSSL 18794 ?? S 0:00,00 /usr/local/sbin/httpd -DSSL 18795 ?? S 0:00,00 /usr/local/sbin/httpd -DSSL 18796 ?? S 0:00,00 /usr/local/sbin/httpd -DSSL 18797 ?? S 0:00,00 /usr/local/sbin/httpd -DSSL The patch solves also a problem in russian/apache13 and russian/apache13-modssl. From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 04:02:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F42B16A417 for ; Fri, 17 Aug 2007 04:02:42 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 1FDA813C49D for ; Fri, 17 Aug 2007 04:02:41 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 2B659EB0F43; Fri, 17 Aug 2007 12:02:40 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id KM6cjrPUEO36; Fri, 17 Aug 2007 12:02:34 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id AB254EB0F44; Fri, 17 Aug 2007 12:02:34 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type; b=VWTGBhmO88eutM/9X4O/VrfR4RU59hFyTmU2J5NksXAmIvzJTk/XUKV0O7s/Pzlne EtNP+hrMLeb17YcmlZfxg== Message-ID: <46C51DB3.6080709@delphij.net> Date: Fri, 17 Aug 2007 12:01:55 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.95.3 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig21979A9D62B8774A390A91AC" Subject: Why we don't use bzip2 in sysinstall/rescue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 04:02:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig21979A9D62B8774A390A91AC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Is there a reason behind this? (i.e. do we have some interest of related work?) Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig21979A9D62B8774A390A91AC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGxR20OfuToMruuMARCoJQAJ4oLIAZ9Gqf2QeqasHrYOW3p59OYwCfQEKj 3QoirQ+bj3XjWfrf3Pry/sg= =s1sP -----END PGP SIGNATURE----- --------------enig21979A9D62B8774A390A91AC-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 05:15:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8856016A417 for ; Fri, 17 Aug 2007 05:15:24 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by mx1.freebsd.org (Postfix) with ESMTP id 6A63B13C461 for ; Fri, 17 Aug 2007 05:15:24 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l7H5FIrX019951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Aug 2007 22:15:18 -0700 X-Auth-Received: from [192.168.10.45] (c-24-10-12-194.hsd1.ca.comcast.net [24.10.12.194]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l7H5FH0C002785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Aug 2007 22:15:18 -0700 Message-ID: <46C52EE1.50409@u.washington.edu> Date: Thu, 16 Aug 2007 22:15:13 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: d@delphij.net References: <46C51DB3.6080709@delphij.net> In-Reply-To: <46C51DB3.6080709@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.16.214525 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: FreeBSD Current Subject: Re: Why we don't use bzip2 in sysinstall/rescue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 05:15:24 -0000 LI Xin wrote: > Hi, > > Is there a reason behind this? (i.e. do we have some interest of > related work?) > > Cheers, > My guess is that: 1. It's dynamically linked (IIRC only statically linked apps were allowed in rescue). 2. It's dynamically linked to a lib that exists in /usr (and /usr is on a commonly located on a separate partition, whereas /rescue isn't). [root@optimus-vm-7 ~]# ldd `which bzip2` /usr/bin/bzip2: libbz2.so.2 => /usr/lib/libbz2.so.2 (0x800639000) libc.so.7 => /lib/libc.so.7 (0x800748000) -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 05:30:14 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A00E716A46E for ; Fri, 17 Aug 2007 05:30:14 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 5715F13C469 for ; Fri, 17 Aug 2007 05:30:14 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 7EE40EB0F6B; Fri, 17 Aug 2007 13:30:13 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id ILrroLHc4U11; Fri, 17 Aug 2007 13:30:10 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id CBC77EB0F68; Fri, 17 Aug 2007 13:30:09 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=aJMEZGlj23SoNHH7fM7ANzhfcU7bZSdsAuM4m041zmHX5ldaOWZqYQj5lCUapdY6t HzXuemqTtCXuvVdo6mabA== Message-ID: <46C5323B.6040404@delphij.net> Date: Fri, 17 Aug 2007 13:29:31 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Garrett Cooper References: <46C51DB3.6080709@delphij.net> <46C52EE1.50409@u.washington.edu> In-Reply-To: <46C52EE1.50409@u.washington.edu> X-Enigmail-Version: 0.95.3 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig375D49FA0531BE674DE1846A" Cc: FreeBSD Current , d@delphij.net Subject: Re: Why we don't use bzip2 in sysinstall/rescue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 05:30:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig375D49FA0531BE674DE1846A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Garrett Cooper wrote: > LI Xin wrote: >> Hi, >> >> Is there a reason behind this? (i.e. do we have some interest of >> related work?) >> >> Cheers, >> =20 > My guess is that: >=20 > 1. It's dynamically linked (IIRC only statically linked apps were > allowed in rescue). > 2. It's dynamically linked to a lib that exists in /usr (and /usr is on= > a commonly located on a separate partition, whereas /rescue isn't). >=20 > [root@optimus-vm-7 ~]# ldd `which bzip2` > /usr/bin/bzip2: > libbz2.so.2 =3D> /usr/lib/libbz2.so.2 (0x800639000) > libc.so.7 =3D> /lib/libc.so.7 (0x800748000) My fault, bzip2 is included in rescue... As a side note. For networked installation, using bzip2 would reduce traffic by ~11%. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig375D49FA0531BE674DE1846A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGxTI7OfuToMruuMARCn/FAJ9AHrfr3XnkRJZTVvdzhWTMP+7KeQCeL9I7 EhbCVbQprN573IdJ46m3eHo= =jTuB -----END PGP SIGNATURE----- --------------enig375D49FA0531BE674DE1846A-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 07:33:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0AE316A418 for ; Fri, 17 Aug 2007 07:33:24 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 4D16F13C47E for ; Fri, 17 Aug 2007 07:33:23 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l7H7XMmx006431 for ; Fri, 17 Aug 2007 17:33:22 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l7H7XLaW006430 for freebsd-current@freebsd.org; Fri, 17 Aug 2007 17:33:21 +1000 (EST) (envelope-from peter) Date: Fri, 17 Aug 2007 17:33:21 +1000 From: Peter Jeremy To: freebsd-current@freebsd.org Message-ID: <20070817073321.GA6321@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Subject: panic unmounting filesystems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 07:33:25 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable After upgrading to current as of about 24 hours ago, I now consistently get panics when I try to unmount filesystems with pending I/O. If I just mount and unmount a filesystem, it works but if I try to unmount a filesystem that has been active, I get: handle_workitem_remove: vget: got error 16 while accessing filesystem softdep_waitidle: Failed to flush worklist for 0xc2c6429c panic: vfs_allocate_syncvnode: insmntque failed I have a crashdump and the backtrace looks like: #8 0xc055c545 in panic (fmt=3D0xc07309f1 "vfs_allocate_syncvnode: insmntqu= e failed") at /usr/src/sys/kern/kern_shutdown.c:547 #9 0xc05d6b9a in vfs_allocate_syncvnode (mp=3D0xc2c6429c) at /usr/src/sys/= kern/vfs_subr.c:3111 #10 0xc05d1222 in dounmount (mp=3D0xc2c6429c, flags=3D0x8000000, td=3D0xc2d= 9c600) at /usr/src/sys/kern/vfs_mount.c:1289 #11 0xc05d16ff in unmount (td=3D0xc2d9c600, uap=3D0xd6218cfc) at /usr/src/s= ys/kern/vfs_mount.c:1170 #12 0xc06de9ea in syscall (frame=3D0xd6218d38) at /usr/src/sys/i386/i386/tr= ap.c:1008 #13 0xc06cc5c0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s= :196 According to kgdb, insmntque() returned both EXDEV and EBUSY. The former is impossible so I suspect kgdb is confused and the latter is correct. The mountpoint shows as in the process of being unmounted and has mnt_nvnodelistsize =3D=3D 0 so insmntque() makes sense at the micro level. Having a system panic as a result does not make sense. The softdep_waitidle() error looks suspicious - at a quick glance, it appears to only wait for 10 ticks (10msec) for the dependency chain to empty. This seems unreasonably short for an operation that probably includes physical I/O. Is my reasoning correct? Does anyone have any suggestions on where to look next? --=20 Peter Jeremy --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGxU9B/opHv/APuIcRAs3GAKCejOuCLQYUPtGpXdtJHXDx0dK/EACgg+3I W676I9/UQQxOjH0nmikY+O4= =qZWL -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 08:04:23 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A5CC16A41A for ; Fri, 17 Aug 2007 08:04:23 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id D203E13C4E3 for ; Fri, 17 Aug 2007 08:04:22 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id E736E1B10EE2; Fri, 17 Aug 2007 10:04:20 +0200 (CEST) Received: from hater.cmotd.com (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id E47461B10EE0; Fri, 17 Aug 2007 10:04:20 +0200 (CEST) Message-ID: <46C55684.4050402@moneybookers.com> Date: Fri, 17 Aug 2007 11:04:20 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.4pre (X11/20070711) MIME-Version: 1.0 To: Eygene Ryabinkin References: <20070806224112.GA21876@muon.bluestop.org> <20070807073920.GV50228@void.codelabs.ru> <46C18B60.8050400@moneybookers.com> <20070814145759.GB25169@void.codelabs.ru> <20070814193150.GA21553@rot26.obsecurity.org> <46C30FA6.7060108@moneybookers.com> <20070815145640.GQ988@void.codelabs.ru> <46C319DD.3010806@moneybookers.com> <20070815172731.GR988@void.codelabs.ru> <46C3FEBC.80409@moneybookers.com> <20070816080516.GW988@void.codelabs.ru> In-Reply-To: <20070816080516.GW988@void.codelabs.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: current@freebsd.org Subject: Re: "tcpflags 0x18; tcp_do_segment" kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 08:04:23 -0000 Hello, Eygene Ryabinkin wrote: > Stefan, good day. > > Thu, Aug 16, 2007 at 10:37:32AM +0300, Stefan Lambrev wrote: > >>> To clarify a bit: are all two servers running -CURRENT, or just the >>> client one? >>> >>> >> Only mb7 is -current (i386), mb4 is 6.2 (i386). >> > > OK, fine. > > >> The server is postfix, but the client is binary and we do not have the sources. >> > > But 'strings | grep -i quit' gives us both 'quit' > and 'QUIT'? Just to be sure that it is the client who has these > two SMTP answers inside. > > >> I'll see what the creators can tell about this. >> > > OK, will wait for the information. > > Thank you! > Their response is that the mail server timeout. Now the question is why the program things that the server timeouts when it does not :) -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 08:14:32 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02BD116A418 for ; Fri, 17 Aug 2007 08:14:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C72F713C48A for ; Fri, 17 Aug 2007 08:14:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 6C9D44C601; Fri, 17 Aug 2007 04:14:31 -0400 (EDT) Date: Fri, 17 Aug 2007 09:14:31 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrew Gallatin In-Reply-To: <18116.44624.144286.621286@grasshopper.cs.duke.edu> Message-ID: <20070817084418.N43264@fledge.watson.org> References: <18116.43755.107638.103132@grasshopper.cs.duke.edu> <18116.44624.144286.621286@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kip Macy , freebsd-current@freebsd.org Subject: Re: IPSEC disables TSO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 08:14:32 -0000 On Thu, 16 Aug 2007, Andrew Gallatin wrote: > > I thought about this after sending and realized that the appropriate > > response is that IPSEC needs to be careful to disable TSO when its in use > > for a connection. What you're seeing was most likely done as an expedient. > > Yes, exactly, there needs to be a smarter test that can distingiush if IPSEC > is actually in use on a connection or not; I should have been more clear > about this. The problem is that I have zero knowledge about IPSEC, so I > have no idea how to do this. > > I'm worried that people will compile IPSEC into the kernel to run an > encrypted tunnel (or the TCP MD5 signature stuff for BGP), and then be > rather surprised that their their "normal" TCP performance stinks. There are a few things going on here, and a few different approaches that could be taken. I'm pretty sure we have problems with the handling of various TCP TSO edge cases. Right now we handle one "disabling" edge case, and the way it's handled may be instructive in thinking about the problem: if a route changes, or TSO is disabled on the interface, EMSGSIZE will be returned from the IP output function, causing TCP to reevaluate the segmentation strategy it's using, and turn off TSO as required. This case may not properly handle IPSEC as it runs today, because it's reevaluation of whether to use TSO and what MTU size to use likely doesn't take IPSEC into account. However, you could imagine that it might in the future, in which case the right way to handle this case might be for IPSEC to simply encrypt the datagram and let the EMSGSIZE from its send propagate back up to IP and then TCP. Another way to deal with this whole scenario is to treat TSO the same way we treat offloaded checksums: provide a just-in-time segmentation routine to run at the last moment when we discover that TSO is not the right strategy. This isn't, probably, generally the right solution (i.e., don't always use TSO at the TCP layer), as we'd like TCP to make the segmentation decisions with more information in the general case (so you don't end up with awkwardly sized segments, etc). However, there may be other places where it does make sense. We also currently have no way to enable/re-enable TSO in the event that we start routing to an interface that has TSO enabled, or where TSO is turned on administratively, so once a connection has started, it can only ever downgrade from TSO operation to normal operation, never reverse the change. For some protocols, this is undesirable -- for example, for long-running NFS TCP connections, it would be nice if TSO would turn itself back on again. However, we should get basic TSO working properly before turning to issues like this :-). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 08:31:48 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 204F316A418; Fri, 17 Aug 2007 08:31:45 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id C48C813C465; Fri, 17 Aug 2007 08:31:44 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=M0U9m9m3ZP695L7FveoPuZRiWgI8RF2pKVCQtcHnfQt1HxdonoSk99Ub6MfcUM8V+KAwZoxmH+b2E+1JIIDT6TFiT8SAFsbtmo34kfMAxz5z2hq86ShXbk4oquKOrJvXD6TyEwarQT5OJB+QUf2RMLzjswlMaHTbD4Mea/DFgKw=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1ILxF6-000Omq-FU; Fri, 17 Aug 2007 12:31:40 +0400 Date: Fri, 17 Aug 2007 12:31:35 +0400 From: Eygene Ryabinkin To: Stefan Lambrev Message-ID: <20070817083135.GM988@void.codelabs.ru> References: <46C18B60.8050400@moneybookers.com> <20070814145759.GB25169@void.codelabs.ru> <20070814193150.GA21553@rot26.obsecurity.org> <46C30FA6.7060108@moneybookers.com> <20070815145640.GQ988@void.codelabs.ru> <46C319DD.3010806@moneybookers.com> <20070815172731.GR988@void.codelabs.ru> <46C3FEBC.80409@moneybookers.com> <20070816080516.GW988@void.codelabs.ru> <46C55684.4050402@moneybookers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <46C55684.4050402@moneybookers.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.2 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: silby@silby.com, rwatson@freebsd.org, current@freebsd.org Subject: Re: "tcpflags 0x18; tcp_do_segment" kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 08:31:49 -0000 Stefan, good day. Fri, Aug 17, 2007 at 11:04:20AM +0300, Stefan Lambrev wrote: > Their response is that the mail server timeout. And how they are detecting the timeout? They are using alarm(), just polling for the time with non-blocking read calls, setting the socket timeout or something else? > Now the question is why the program things that the server timeouts when it > does not :) May be this is connected to the socket timeout stuff: chances are good that the PHP program uses apr_socket_timeout_set(), so there can be issues with SO_SNDTIMEO/SO_RCVTIMEO socket options in the -CURRENT. At least Apache (that I have problems with) sets keep-alived sockets with apr_socket_timeout_set(). I will try to have a look if this can be true. Thanks for your information! Mike, Robert, there are chances that some timeout code behaves weirdly. And maybe the magic number 3 (every 3rd keep-alived connection seems to be dropped due to the timeout, Stefan sees it too) should be searched in the timeout code. Maybe you can give some hints or point to the exact place where the error can occur? Thank you. -- Eygene From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 09:07:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6553A16A417 for ; Fri, 17 Aug 2007 09:07:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id A15CB13C491 for ; Fri, 17 Aug 2007 09:07:32 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 69458 invoked from network); 17 Aug 2007 08:58:39 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Aug 2007 08:58:39 -0000 Message-ID: <46C56558.1090901@freebsd.org> Date: Fri, 17 Aug 2007 11:07:36 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Mike Jakubik References: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> <20070816163405.GG988@void.codelabs.ru> <20070816164133.GH988@void.codelabs.ru> <46C4BBE7.5000908@rogers.com> In-Reply-To: <46C4BBE7.5000908@rogers.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: TCP info spamming the logs and dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 09:07:34 -0000 Mike Jakubik wrote: > Eygene Ryabinkin wrote: >> Andre, good day. >> >> Thu, Aug 16, 2007 at 08:34:05PM +0400, Eygene Ryabinkin wrote: >> >>> Thu, Aug 16, 2007 at 11:14:08AM -0400, Mike Jakubik wrote: >>> >>>> Is there any way to disable these, or have them log to a separate log? >>>> >> >> I had seen about four such questions for the last two weeks, so maybe >> it is time to patch tcp(4) manpage? The following is the very rough >> patch for it: >> --- tcp.4.orig 2007-08-16 20:35:06.000000000 +0400 >> +++ tcp.4 2007-08-16 20:37:33.000000000 +0400 >> @@ -259,6 +259,11 @@ >> Maximum >> .Tn TCP >> receive window. >> +.It Va log_debug >> +Enable (1) or disable (0) >> +.Tn TCP >> +stack debugging messages. >> +Default is 1, i.e., the logging is enabled. >> .It Va log_in_vain >> Log any connection attempts to ports where there is not a socket >> accepting connections. >> > > > That sounds like a good idea, perhaps it would also be a good idea to > set the default to 0? Yes, that is planned for the release together with all the other performance affecting debugging features in the kernel (WITNESS, INVARIANTS, etc). I have updates to the tcp.4 and syncache.4 manpage in the wings to document all changes and new sysctls. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 09:08:41 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9F7A16A419 for ; Fri, 17 Aug 2007 09:08:41 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1F9A513C48E for ; Fri, 17 Aug 2007 09:08:40 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 69477 invoked from network); 17 Aug 2007 08:59:48 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Aug 2007 08:59:48 -0000 Message-ID: <46C5659C.3020906@freebsd.org> Date: Fri, 17 Aug 2007 11:08:44 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eygene Ryabinkin References: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> <20070816163405.GG988@void.codelabs.ru> <20070816164133.GH988@void.codelabs.ru> <46C4BBE7.5000908@rogers.com> <20070816214941.GI988@void.codelabs.ru> In-Reply-To: <20070816214941.GI988@void.codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Jakubik , freebsd-current@freebsd.org Subject: Re: TCP info spamming the logs and dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 09:08:41 -0000 Eygene Ryabinkin wrote: > Thu, Aug 16, 2007 at 05:04:39PM -0400, Mike Jakubik wrote: >> That sounds like a good idea, perhaps it would also be a good idea to set the >> default to 0? > > See http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c#rev1.365 > > After reading the commit log I had sligtly modified the patch for > the tcp(4) to reflect the coupling to log_in_vain: > > --- tcp.4.orig 2007-08-16 20:35:06.000000000 +0400 > +++ tcp.4 2007-08-17 01:45:42.000000000 +0400 > @@ -259,6 +259,14 @@ > Maximum > .Tn TCP > receive window. > +.It Va log_debug > +Enable (1) or disable (0) > +.Tn TCP > +stack debugging messages. > +Default is 1, i.e., the logging is enabled. > +Note that enabling this variable will also enable > +.Tn log_in_vain > +option. > .It Va log_in_vain > Log any connection attempts to ports where there is not a socket > accepting connections. It's the other way around. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 09:25:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E9E916A417 for ; Fri, 17 Aug 2007 09:25:27 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3F86A13C45E for ; Fri, 17 Aug 2007 09:25:27 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id C7CE520B0; Fri, 17 Aug 2007 11:25:20 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id BBA07208A; Fri, 17 Aug 2007 11:25:20 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id A166784437; Fri, 17 Aug 2007 11:25:20 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Nathan Butcher References: <46C4FD44.1060105@fusiongol.com> Date: Fri, 17 Aug 2007 11:25:20 +0200 In-Reply-To: <46C4FD44.1060105@fusiongol.com> (Nathan Butcher's message of "Fri\, 17 Aug 2007 10\:43\:32 +0900") Message-ID: <86odh6ikcf.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Promise SATA 300 TX4 cause X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 09:25:27 -0000 Nathan Butcher writes: > After some poking around, I can confirm Karsten's report that it is > indeed the following edit that causes problems with the Promise card: > > http://lists.freebsd.org/pipermail/cvs-src/2007-June/079930.html Once again, *no*. This commit may have exacerbated the problem, but people were having trouble with Promise controllers already in April. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 10:00:40 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2047B16A4A9; Fri, 17 Aug 2007 10:00:40 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 96EF613C4E3; Fri, 17 Aug 2007 10:00:32 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id AE90A20B0; Fri, 17 Aug 2007 12:00:22 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 2B398208A; Fri, 17 Aug 2007 12:00:22 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 0681A84468; Fri, 17 Aug 2007 12:00:22 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: current@freebsd.org References: <1187099341.17556.44.camel@opus.cse.buffalo.edu> <20070814165423.ebuvjb6dwswkgc8g@webmail.leidinger.net> <20070814153519.GA18648@rot26.obsecurity.org> <86643h3isp.fsf@ds4.des.no> <20070814213515.GA23492@rot26.obsecurity.org> <86d4xp21i3.fsf@ds4.des.no> <86lkccorig.fsf@ds4.des.no> <86tzqz5ia2.fsf@ds4.des.no> <86k5rv5eeg.fsf_-_@ds4.des.no> <86fy2j5e7k.fsf@ds4.des.no> Date: Fri, 17 Aug 2007 12:00:21 +0200 In-Reply-To: <86fy2j5e7k.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Fri\, 17 Aug 2007 00\:03\:59 +0200") Message-ID: <86k5ruiiq2.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: pjd@freebsd.org, mohans@freebsd.org Subject: Re: NFS hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 10:00:40 -0000 Dag-Erling Sm=C3=B8rgrav writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Fresh 7.0-CURRENT-200706-i386 install; no rc.conf, no configuration > > other than listing the root fs in /etc/fstab and symlinking /boot/kernel > > to /boot/GENERIC; PXE / NFS unattended boot to multiuser hangs while > > writing /var/run/dmesg.boot. The file remains empty on the NFS server. > > Complete tcpdump (from power-on to reset) attached. 10.0.0.4 is the > > server ("ds4"), 10.0.0.10 is the client ("xps"). > I just realized mailman will diligently block the attachment. You can > get it from (~6 MB). The rest of the message, which was blocked by mailman, was: This really surprises me, as my web server is running fine with a 2007-07-03 kernel (but fails with a 2007-07-29 kernel) as an NFS client against the same server. Starting to think it might be a server issue after all. The server runs CURRENT from 2007-08-03. All exported file systems are ZFS; should I try to disable the ZIL? That's the one part of ZFS I can think of that would interact with NFS in a way other file systems don't. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 10:38:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D004B16A41A; Fri, 17 Aug 2007 10:38:08 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 802A213C48D; Fri, 17 Aug 2007 10:38:08 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=WbSJmRgR/1yaulmmBq4zhL4GblrcRtNJNkMOTIpD9ed0668NXCbLG/qk9zjJXe56dvupr2lNX9Vu+mHFUD4imxG8zCF9NXhTH8altwv2X+funLw7FLDdqpazOGGoNDKWpJRrNyRSl8W5YgNz4r6frkiXdvCDsgI0mwrStvf2l1k=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1ILzDR-000Pae-VF; Fri, 17 Aug 2007 14:38:06 +0400 Date: Fri, 17 Aug 2007 14:38:00 +0400 From: Eygene Ryabinkin To: Andre Oppermann Message-ID: <20070817103800.GN988@void.codelabs.ru> References: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> <20070816163405.GG988@void.codelabs.ru> <20070816164133.GH988@void.codelabs.ru> <46C4BBE7.5000908@rogers.com> <20070816214941.GI988@void.codelabs.ru> <46C5659C.3020906@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <46C5659C.3020906@freebsd.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_40 Cc: Mike Jakubik , freebsd-current@freebsd.org Subject: Re: TCP info spamming the logs and dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 10:38:08 -0000 Fri, Aug 17, 2007 at 11:08:44AM +0200, Andre Oppermann wrote: > >+Note that enabling this variable will also enable > >+.Tn log_in_vain > >+option. > > .It Va log_in_vain > It's the other way around. Yep, you're right. -- Eygene From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 10:57:04 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF41916A417; Fri, 17 Aug 2007 10:57:04 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 653F313C469; Fri, 17 Aug 2007 10:57:04 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4810845B26; Fri, 17 Aug 2007 12:57:02 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id EBCEB45684; Fri, 17 Aug 2007 12:56:56 +0200 (CEST) Date: Fri, 17 Aug 2007 12:56:04 +0200 From: Pawel Jakub Dawidek To: Dag-Erling Sm??rgrav Message-ID: <20070817105604.GA9640@garage.freebsd.pl> References: <1187099341.17556.44.camel@opus.cse.buffalo.edu> <20070814165423.ebuvjb6dwswkgc8g@webmail.leidinger.net> <20070814153519.GA18648@rot26.obsecurity.org> <86643h3isp.fsf@ds4.des.no> <20070814213515.GA23492@rot26.obsecurity.org> <86d4xp21i3.fsf@ds4.des.no> <86lkccorig.fsf@ds4.des.no> <86tzqz5ia2.fsf@ds4.des.no> <86k5rv5eeg.fsf_-_@ds4.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <86k5rv5eeg.fsf_-_@ds4.des.no> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: current@freebsd.org, mohans@freebsd.org Subject: Re: NFS hangs (was: Re: FBSD-7.0 status...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 10:57:05 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 16, 2007 at 11:59:51PM +0200, Dag-Erling Sm??rgrav wrote: > [continuing a thread from another list about client-side NFS issues with > recent kernels] >=20 > Fresh 7.0-CURRENT-200706-i386 install; no rc.conf, no configuration > other than listing the root fs in /etc/fstab and symlinking /boot/kernel > to /boot/GENERIC; PXE / NFS unattended boot to multiuser hangs while > writing /var/run/dmesg.boot. The file remains empty on the NFS server. > Complete tcpdump (from power-on to reset) attached. 10.0.0.4 is the > server ("ds4"), 10.0.0.10 is the client ("xps"). >=20 > This really surprises me, as my web server is running fine with a > 2007-07-03 kernel (but fails with a 2007-07-29 kernel) as an NFS client > against the same server. >=20 > Starting to think it might be a server issue after all. The server runs > CURRENT from 2007-08-03. All exported file systems are ZFS; should I > try to disable the ZIL? That's the one part of ZFS I can think of that > would interact with NFS in a way other file systems don't. I can't see how ZIL can make any difference visible for NFS clients, except when your NFS server crashes. Although I'd keep ZFS on suspects list, as exporting ZFS file systems over NFS wasn't really heavily tested. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGxX7EForvXbEpPzQRAiRvAKCrEHT0WRtmxCQcALOynlSZa+oebgCfXFmO xGTjBY3YDTWPWMG8dBYtQCw= =gKEz -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 11:09:08 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 052B916A41A; Fri, 17 Aug 2007 11:09:08 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 71A7C13C461; Fri, 17 Aug 2007 11:09:07 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 2C08420B2; Fri, 17 Aug 2007 13:09:04 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 1AF6F20B1; Fri, 17 Aug 2007 13:09:04 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 051BB8444F; Fri, 17 Aug 2007 13:09:04 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Jakub Dawidek References: <1187099341.17556.44.camel@opus.cse.buffalo.edu> <20070814165423.ebuvjb6dwswkgc8g@webmail.leidinger.net> <20070814153519.GA18648@rot26.obsecurity.org> <86643h3isp.fsf@ds4.des.no> <20070814213515.GA23492@rot26.obsecurity.org> <86d4xp21i3.fsf@ds4.des.no> <86lkccorig.fsf@ds4.des.no> <86tzqz5ia2.fsf@ds4.des.no> <86k5rv5eeg.fsf_-_@ds4.des.no> <20070817105604.GA9640@garage.freebsd.pl> Date: Fri, 17 Aug 2007 13:09:03 +0200 In-Reply-To: <20070817105604.GA9640@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Fri\, 17 Aug 2007 12\:56\:04 +0200") Message-ID: <86bqd6ifjk.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, mohans@freebsd.org Subject: Re: NFS hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 11:09:08 -0000 Pawel Jakub Dawidek writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Starting to think it might be a server issue after all. The server runs > > CURRENT from 2007-08-03. All exported file systems are ZFS; should I > > try to disable the ZIL? That's the one part of ZFS I can think of that > > would interact with NFS in a way other file systems don't. > I can't see how ZIL can make any difference visible for NFS clients, > except when your NFS server crashes. Although I'd keep ZFS on suspects > list, as exporting ZFS file systems over NFS wasn't really heavily > tested. As I understand it, write operations pass through the ZIL to maintain consistency? Anyway, disabling the ZIL had no effect. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 09:40:18 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A8D716A474 for ; Fri, 17 Aug 2007 09:40:18 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2001:1b20:1:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id 58D1213C46C for ; Fri, 17 Aug 2007 09:40:08 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (ixstoj@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l7H9di1A054470; Fri, 17 Aug 2007 11:39:55 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l7H9diEk054469; Fri, 17 Aug 2007 11:39:44 +0200 (CEST) (envelope-from olli) Date: Fri, 17 Aug 2007 11:39:44 +0200 (CEST) Message-Id: <200708170939.l7H9diEk054469@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, d@delphij.net In-Reply-To: <46C5323B.6040404@delphij.net> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 17 Aug 2007 11:39:59 +0200 (CEST) X-Mailman-Approved-At: Fri, 17 Aug 2007 11:18:57 +0000 Cc: Subject: Re: Why we don't use bzip2 in sysinstall/rescue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 09:40:18 -0000 LI Xin wrote: > As a side note. For networked installation, using bzip2 would reduce > traffic by ~11%. And increase local installation time by 900% (except maybe on high-end machines). I just tested extracting a 10 MB .bz2 file to /dev/null on our 800 MHz server: It took 57 seconds. Recompressing the result to .gz, extracting that took only 5 seconds. The installation data is roughly 30 times that much. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "... there are two ways of constructing a software design: One way is to make it so simple that there are _obviously_ no deficiencies and the other way is to make it so complicated that there are no _obvious_ deficiencies." -- C.A.R. Hoare, ACM Turing Award Lecture, 1980 From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 11:19:12 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00B6316A420; Fri, 17 Aug 2007 11:19:12 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 8DBEA13C480; Fri, 17 Aug 2007 11:19:11 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5F3B845B26; Fri, 17 Aug 2007 13:19:10 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 7ECC245681; Fri, 17 Aug 2007 13:19:05 +0200 (CEST) Date: Fri, 17 Aug 2007 13:18:12 +0200 From: Pawel Jakub Dawidek To: Dag-Erling Sm??rgrav Message-ID: <20070817111812.GB9640@garage.freebsd.pl> References: <20070814165423.ebuvjb6dwswkgc8g@webmail.leidinger.net> <20070814153519.GA18648@rot26.obsecurity.org> <86643h3isp.fsf@ds4.des.no> <20070814213515.GA23492@rot26.obsecurity.org> <86d4xp21i3.fsf@ds4.des.no> <86lkccorig.fsf@ds4.des.no> <86tzqz5ia2.fsf@ds4.des.no> <86k5rv5eeg.fsf_-_@ds4.des.no> <20070817105604.GA9640@garage.freebsd.pl> <86bqd6ifjk.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline In-Reply-To: <86bqd6ifjk.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: current@freebsd.org, mohans@freebsd.org Subject: Re: NFS hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 11:19:12 -0000 --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 17, 2007 at 01:09:03PM +0200, Dag-Erling Sm??rgrav wrote: > Pawel Jakub Dawidek writes: > > Dag-Erling Sm??rgrav writes: > > > Starting to think it might be a server issue after all. The server r= uns > > > CURRENT from 2007-08-03. All exported file systems are ZFS; should I > > > try to disable the ZIL? That's the one part of ZFS I can think of th= at > > > would interact with NFS in a way other file systems don't. > > I can't see how ZIL can make any difference visible for NFS clients, > > except when your NFS server crashes. Although I'd keep ZFS on suspects > > list, as exporting ZFS file systems over NFS wasn't really heavily > > tested. >=20 > As I understand it, write operations pass through the ZIL to maintain > consistency? No consistency - ZFS is always consistent on disk, but without ZIL, for example fsync(2) is a no-op, which may confuse NFS clients in an event of NFS server crash. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGxYP0ForvXbEpPzQRAkN1AJ9Tpf84Yhkt/0jISCIjV6ZvthJQpACgxFau sq+hpVmHQP7vlQ7vODjddIg= =9RQO -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 12:52:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D5E616A420 for ; Fri, 17 Aug 2007 12:52:23 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3166C13C46A for ; Fri, 17 Aug 2007 12:52:23 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 17 Aug 2007 08:22:33 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.8.3-GA) with ESMTP id IZX94304; Fri, 17 Aug 2007 08:22:33 -0400 (EDT) Received: from 65-78-26-179.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([65.78.26.179]) by smtp01.lnh.mail.rcn.net with ESMTP; 17 Aug 2007 08:22:24 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18117.37649.6266.369458@jerusalem.litteratus.org> Date: Fri, 17 Aug 2007 08:22:41 -0400 To: freebsd-current@freebsd.org In-Reply-To: <20070815122747.GA62123@duncan.reilly.home> References: <20070815122747.GA62123@duncan.reilly.home> X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr08.lnh.mail.rcn.net) Subject: Does 7-CURRENT (aka cvsup tag=.) build under 6-STABLE? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 12:52:23 -0000 Andrew Reilly writes: > I ask because when I tried this on the weekend, on my ia32 > crash-box-come-sound server, it died while trying to build csh. One of the attributes of CURRENT _by definition_ is Sometimes Things Break. If you're lucky, they break during compilation. Inhale, Exhale, Try again in 24 hours. Robert Huff From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 13:10:01 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0B5F16A41B for ; Fri, 17 Aug 2007 13:10:01 +0000 (UTC) (envelope-from ks@dlx.dk) Received: from exch.hoffice.dk (exch.hoffice.dk [87.61.124.141]) by mx1.freebsd.org (Postfix) with ESMTP id 8649113C458 for ; Fri, 17 Aug 2007 13:10:01 +0000 (UTC) (envelope-from ks@dlx.dk) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 17 Aug 2007 14:58:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <86odh6ikcf.fsf@ds4.des.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Promise SATA 300 TX4 cause Thread-Index: AcfgsR4NaaliBp6/QkiGn7oxQWHPXgAG9K5Q References: <46C4FD44.1060105@fusiongol.com> <86odh6ikcf.fsf@ds4.des.no> From: "Karsten W. Schmidt / DLX ApS" To: Cc: Subject: Re: Promise SATA 300 TX4 cause X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 13:10:02 -0000 Pj4gQWZ0ZXIgc29tZSBwb2tpbmcgYXJvdW5kLCBJIGNhbiBjb25maXJtIEthcnN0ZW4ncyByZXBv cnQgdGhhdCBpdCBpcw0KPj4gaW5kZWVkIHRoZSBmb2xsb3dpbmcgZWRpdCB0aGF0IGNhdXNlcyBw cm9ibGVtcyB3aXRoIHRoZSBQcm9taXNlIGNhcmQ6DQo+Pg0KPj4gaHR0cDovL2xpc3RzLmZyZWVi c2Qub3JnL3BpcGVybWFpbC9jdnMtc3JjLzIwMDctSnVuZS8wNzk5MzAuaHRtbA0KPg0KPiBPbmNl IGFnYWluLCAqbm8qLiAgVGhpcyBjb21taXQgbWF5IGhhdmUgZXhhY2VyYmF0ZWQgdGhlIHByb2Js ZW0sIGJ1dA0KPiBwZW9wbGUgd2VyZSBoYXZpbmcgdHJvdWJsZSB3aXRoIFByb21pc2UgY29udHJv bGxlcnMgYWxyZWFkeSBpbiBBcHJpbC4NCg0KTWF5YmUgaXTigJlzIHRoZSBzYW1lIHByb2JsZW0s IGJ1dCBiZWZvcmUgdGhpcyBjaGFuZ2UgSSBuZXZlciBoYWQgYW55IGRhdGEgY29ycnVwdGlvbi4N ClRoZSBvbmx5IHByb2JsZW1zIEkgaGF2ZSB3aXRoIGEga2VybmVsIG9sZGVyIHRoYW4gdGhpcyBj aGFuZ2UgaXMgdGhlc2UuDQoNCmFkMjA6IFdBUk5JTkcgLSBTRVRGRUFUVVJFUyBTRVQgVFJBTlNG RVIgTU9ERSB0YXNrcXVldWUgdGltZW91dCAtIGNvbXBsZXRpbmcgcmVxdWVzdCBkaXJlY3RseQ0K YWQyMDogV0FSTklORyAtIFNFVEZFQVRVUkVTIFNFVCBUUkFOU0ZFUiBNT0RFIHRhc2txdWV1ZSB0 aW1lb3V0IC0gY29tcGxldGluZyByZXF1ZXN0IGRpcmVjdGx5DQphZDIwOiBXQVJOSU5HIC0gU0VU RkVBVFVSRVMgRU5BQkxFIFJDQUNIRSB0YXNrcXVldWUgdGltZW91dCAtIGNvbXBsZXRpbmcgcmVx dWVzdCBkaXJlY3RseQ0KYWQyMDogV0FSTklORyAtIFNFVEZFQVRVUkVTIEVOQUJMRSBXQ0FDSEUg dGFza3F1ZXVlIHRpbWVvdXQgLSBjb21wbGV0aW5nIHJlcXVlc3QgZGlyZWN0bHkNCmFkMjA6IFdB Uk5JTkcgLSBTRVRfTVVMVEkgdGFza3F1ZXVlIHRpbWVvdXQgLSBjb21wbGV0aW5nIHJlcXVlc3Qg ZGlyZWN0bHkNCmFkMjA6IFRJTUVPVVQgLSBSRUFEX0RNQSByZXRyeWluZyAoMSByZXRyeSBsZWZ0 KSBMQkE9Mjc2NDU5DQoNCi0tIA0KS2Fyc3Rlbg0K From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 13:45:26 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F119616A417 for ; Fri, 17 Aug 2007 13:45:26 +0000 (UTC) (envelope-from kan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E248913C46A for ; Fri, 17 Aug 2007 13:45:26 +0000 (UTC) (envelope-from kan@FreeBSD.org) Received: from freefall.freebsd.org (kan@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7HDjQFb029851 for ; Fri, 17 Aug 2007 13:45:26 GMT (envelope-from kan@freefall.freebsd.org) Received: (from kan@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7HDjQJA029850 for current@freebsd.org; Fri, 17 Aug 2007 13:45:26 GMT (envelope-from kan) Date: Fri, 17 Aug 2007 13:45:26 +0000 From: Alexander Kabaev To: current@freebsd.org Message-ID: <20070817134526.GA27365@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Double mutex destruction X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 13:45:27 -0000 Hi, I left development box running 7.0 sitting idle at work overnight and was greeted with the following panic this morning: panic: mtx_lock() of destroyed mutex @ ../../../net/route.c:1303 cpuid = 1 KDB: enter: panic [thread pid 4088 tid 100128 ] Stopped at kdb_enter+0x32: leave db> bt Tracing pid 4088 tid 100128 td 0xc5539cc0 kdb_enter(c07c56bd,1,c07c4619,f199f9bc,1,...) at kdb_enter+0x32 panic(c07c4619,c07d2ce5,517,507,c5386a7c,...) at panic+0x124 _mtx_lock_flags(c5aeb510,0,c07d2ce5,517,f199fa28,...) at _mtx_lock_flags+0x65 rt_check(f199fa20,f199fa3c,c541ec30,c080a6c4,c07d2cee,...) at rt_check+0x111 arpresolve(c51e4000,c5584bb8,c5587d00,c541ec30,f199fa56,...) at arpresolve+0xb0 ether_output(c51e4000,c5587d00,c541ec30,c5584bb8,c5539cc0,...) at ether_output+0x7e ip_output(c5587d00,0,f199fac4,0,0,...) at ip_output+0x9f5 udp_send(c5a72000,0,c5587d00,c5a17970,0,...) at udp_send+0x597 sosend_dgram(c5a72000,c5a17970,f199fbe8,c5587d00,0,...) at sosend_dgram+0x351 sosend(c5a72000,c5a17970,f199fbe8,0,0,...) at sosend+0x54 kern_sendit(c5539cc0,4,f199fc64,0,0,...) at kern_sendit+0x104 sendit(0,28228a34,0,c5a17970,10,...) at sendit+0x182 sendto(c5539cc0,f199fcfc,18,c07c1d9e,c0804e18,...) at sendto+0x4f syscall(f199fd38) at syscall+0x29a Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (133, FreeBSD ELF32, sendto), eip = 0x28152f23, esp = 0xbfbfe2cc, ebp = 0xbfbfe3e8 --- Is this one known? Unfortunately, vmcore from this panic got garbled somehow. -- Alexander Kabaev From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 15:49:18 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E603316A41A for ; Fri, 17 Aug 2007 15:49:18 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by mx1.freebsd.org (Postfix) with ESMTP id A8CA613C468 for ; Fri, 17 Aug 2007 15:49:18 +0000 (UTC) (envelope-from datahead4@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so403215wra for ; Fri, 17 Aug 2007 08:49:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=J1onAzbARKMXfJM+IxOW3/zoIzHXc6lCUZWLAiKPnADAsHMrSPTiPJJPj/cAhK09xVrbhnYDU6CUlNvNfZpgaXyCiuKGl96EI19F9+a2yHyAqY/ALkNwPC3RSTGU9QnZ2HHcum6cfSMZk2POgjXYd30ta9sI4D6VXOeGM2PxCzM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ORQ2KBB75KEQA1mQjIp1LuCfWMpFYHTuolEZEDaoK752NZairH9dfRsT+MNxOyHbNC2++26aAGHKD0APSc3PaE0JAgjMpA2VaFMCu/jGw5ax/aCGAN3sot4O8VfEJUK6+Gkgh2httojsXun6shfJpdI/m/7EZ9EE+gg1gpmLit0= Received: by 10.90.119.15 with SMTP id r15mr4728183agc.1187365755794; Fri, 17 Aug 2007 08:49:15 -0700 (PDT) Received: by 10.90.55.10 with HTTP; Fri, 17 Aug 2007 08:49:15 -0700 (PDT) Message-ID: Date: Fri, 17 Aug 2007 10:49:15 -0500 From: Matt To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: rc error with this morning's -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 15:49:19 -0000 I noticed an error thrown after booting into a -current build from this morning (cvsup'd and built at around 9:30 AM). I am unsure which rc script threw the error, but the relative position in /var/log/messages is shown below: Aug 17 10:18:48 matt-bsd savecore: no dumps found Aug 17 10:18:48 matt-bsd root: /etc/rc: ERROR: USAGE: load_rc_config name Aug 17 10:18:48 matt-bsd root: /etc/rc: ERROR: USAGE: load_rc_config name Aug 17 10:18:50 matt-bsd kernel: eth0: link state changed to UP Aug 17 10:18:50 matt-bsd kernel: eth1: link state changed to UP uname -a output is: FreeBSD matt-bsd.aei-msn.aeieng.com 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Fri Aug 17 09:48:30 CDT 2007 root@matt-bsd.aei-msn.aeieng.com:/usr/obj/usr/src/sys/SMP-CUSTOM i386 There are no apparent ill effects for the system and all services seem to have come up fine. Any suggestions for how I should track this down and fix it? Thanks, Matt From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 15:53:31 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 890EF16A419 for ; Fri, 17 Aug 2007 15:53:31 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 45DD913C465 for ; Fri, 17 Aug 2007 15:53:31 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id DE3F61B10EA4; Fri, 17 Aug 2007 17:53:29 +0200 (CEST) Received: from hater.cmotd.com (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id DB18A1B10E0D; Fri, 17 Aug 2007 17:53:29 +0200 (CEST) Message-ID: <46C5C479.1010307@moneybookers.com> Date: Fri, 17 Aug 2007 18:53:29 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.4pre (X11/20070711) MIME-Version: 1.0 To: Matt References: In-Reply-To: Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: current@freebsd.org Subject: Re: rc error with this morning's -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 15:53:31 -0000 Hello, Matt wrote: > I noticed an error thrown after booting into a -current build from > this morning (cvsup'd and built at around 9:30 AM). I am unsure which > rc script threw the error, but the relative position in > /var/log/messages is shown below: > > Aug 17 10:18:48 matt-bsd savecore: no dumps found > Aug 17 10:18:48 matt-bsd root: /etc/rc: ERROR: USAGE: load_rc_config name > Aug 17 10:18:48 matt-bsd root: /etc/rc: ERROR: USAGE: load_rc_config name > Aug 17 10:18:50 matt-bsd kernel: eth0: link state changed to UP > Aug 17 10:18:50 matt-bsd kernel: eth1: link state changed to UP > I can confirm this. But next after /etc/rc: ERROR: USAGE: load_rc_config name I have: Starting local daemons. > uname -a output is: > FreeBSD matt-bsd.aei-msn.aeieng.com 7.0-CURRENT FreeBSD 7.0-CURRENT > #0: Fri Aug 17 09:48:30 CDT 2007 > root@matt-bsd.aei-msn.aeieng.com:/usr/obj/usr/src/sys/SMP-CUSTOM i386 > > There are no apparent ill effects for the system and all services seem > to have come up fine. Any suggestions for how I should track this > down and fix it? > > Thanks, > Matt > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 16:19:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DD9616A41B for ; Fri, 17 Aug 2007 16:19:26 +0000 (UTC) (envelope-from qumqats@outel.org) Received: from outel.org (outel.org [69.12.226.165]) by mx1.freebsd.org (Postfix) with ESMTP id 1EA2E13C45A for ; Fri, 17 Aug 2007 16:19:26 +0000 (UTC) (envelope-from qumqats@outel.org) Received: from winxp ([192.168.1.20]) by outel.org with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IM4Xl-000KRe-6m; Fri, 17 Aug 2007 09:19:25 -0700 Date: Fri, 17 Aug 2007 09:19:22 -0700 From: "Joel M. Baldwin" To: Scott Ullrich Message-ID: In-Reply-To: References: <19693.209.47.38.69.1187277248.squirrel@wettoast.dyndns.org> <20070816163405.GG988@void.codelabs.ru> <46C4BB28.8030000@rogers.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-current@freebsd.org Subject: Re: TCP info spamming the logs and dmesg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 16:19:26 -0000 --On Thursday, August 16, 2007 11:05 PM -0400 Scott Ullrich wrote: > On 8/16/07, Joel M. Baldwin wrote: >> Well it doesn't fix it for me! >> >> # sysctl net.inet.tcp.log_debug=0 >> sysctl: unknown oid 'net.inet.tcp.log_debug' >> >> Is there some dependency in the kernel for this to work to stop the >> logging? > > This was commited on July 28 at 12:20;40 UTC. By chance is your > kernel younger than this commit? > > http://lists.freebsd.org/pipermail/cvs-src/2007-July/080961.html > > Scott Yes it is. I'll cvsup/make/install. Thanks for the prompt and correct answer! From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 16:54:33 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E55716A419 for ; Fri, 17 Aug 2007 16:54:33 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 4D4FB13C45D for ; Fri, 17 Aug 2007 16:54:33 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.14.1) id l7HGsWjS082088; Fri, 17 Aug 2007 11:54:32 -0500 (CDT) (envelope-from dan) Date: Fri, 17 Aug 2007 11:54:32 -0500 From: Dan Nelson To: Alexander Kabaev Message-ID: <20070817165431.GA49455@dan.emsphone.com> References: <20070817134526.GA27365@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070817134526.GA27365@freefall.freebsd.org> X-OS: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: current@freebsd.org Subject: Re: Double mutex destruction X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 16:54:33 -0000 In the last episode (Aug 17), Alexander Kabaev said: > I left development box running 7.0 sitting idle at work overnight and > was greeted with the following panic this morning: > > panic: mtx_lock() of destroyed mutex @ ../../../net/route.c:1303 > cpuid = 1 > KDB: enter: panic > [thread pid 4088 tid 100128 ] > Stopped at kdb_enter+0x32: leave > db> bt > Tracing pid 4088 tid 100128 td 0xc5539cc0 > kdb_enter(c07c56bd,1,c07c4619,f199f9bc,1,...) at kdb_enter+0x32 > panic(c07c4619,c07d2ce5,517,507,c5386a7c,...) at panic+0x124 > _mtx_lock_flags(c5aeb510,0,c07d2ce5,517,f199fa28,...) at _mtx_lock_flags+0x65 > rt_check(f199fa20,f199fa3c,c541ec30,c080a6c4,c07d2cee,...) at rt_check+0x111 > arpresolve(c51e4000,c5584bb8,c5587d00,c541ec30,f199fa56,...) at arpresolve+0xb0 [...] I get this about once a week or so, and Andre Guibert de Bruet has also reported it. Occasionally instead of an assertion panic, I get a trap 12: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 03 fault virtual address = 0x188 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05dc855 stack pointer = 0x28:0xe74b0920 frame pointer = 0x28:0xe74b0938 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 2623 (epic-EPIC4-2.6) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c082afcc,e74b07fc,c05e9541,c08435d9,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08435d9,0,c080f97f,e74b0808,0,...) at kdb_backtrace+0x29 panic(c080f97f,c084484e,c83e377c,1,1,...) at panic+0x111 trap_fatal(c0844750,c,c082707b,efa498f6,c83e3558,...) at trap_fatal+0x383 trap(e74b08e0) at trap+0x11b calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc05dc855, esp = 0xe74b0920, ebp = 0xe74b0938 --- _mtx_lock_sleep(c62d3d80,c83e6000,0,0,0,...) at _mtx_lock_sleep+0x85 rt_check(e74b0980,e74b099c,c5a64e10,0,0,...) at rt_check+0x120 arpresolve(c3bd0c00,c62d4d20,c3fff400,c5a64e10,e74b09b6,...) at arpresolve+0xb4 ether_output(c3bd0c00,c3fff400,c5a64e10,c62d4d20,c807d7e0,...) at ether_output+0x8e ip_output(c3fff400,0,e74b0a28,0,0,...) at ip_output+0xb45 tcp_output(c744a000,c437a100,e74b0c60,1,0,...) at tcp_output+0x11de tcp_usr_send(c7fc3630,0,c437a100,0,0,...) at tcp_usr_send+0x262 sosend_generic(c7fc3630,0,e74b0c60,c437a100,0,...) at sosend_generic+0x6a5 sosend(c7fc3630,0,e74b0c60,0,0,...) at sosend+0x3f soo_write(c9869948,e74b0c60,c9871000,0,c83e6000,...) at soo_write+0x4b dofilewrite(e74b0c60,ffffffff,ffffffff,0,c9869948,...) at dofilewrite+0x97 kern_writev(c83e6000,3,e74b0c60,bfbf8d02,0,...) at kern_writev+0x58 write(c83e6000,e74b0cfc,c,16,e74b0d2c,...) at write+0x4f syscall(e74b0d38) at syscall+0x365 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (4, FreeBSD ELF32, write), eip = 0x28448577, esp = 0xbfbf8c8c, ebp = 0xbfbf8cb8 --- Uptime: 6h40m30s Physical memory: 1015 MB Dumping 246 MB: 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) (kgdb) #0 doadump () at pcpu.h:195 #1 0xc05e9287 in boot (howto=260) at ../../../kern/kern_shutdown.c:409 #2 0xc05e9570 in panic (fmt=Variable "fmt" is not available.) at ../../../kern/kern_shutdown.c:563 #3 0xc07cabd3 in trap_fatal (frame=0xe74b08e0, eva=392) at ../../../i386/i386/trap.c:872 #4 0xc07cb5cb in trap (frame=0xe74b08e0) at ../../../i386/i386/trap.c:277 #5 0xc07b070b in calltrap () at ../../../i386/i386/exception.s:139 #6 0xc05dc855 in _mtx_lock_sleep (m=0xc62d3d80, tid=3359531008, opts=0, file=0x0, line=0) at ../../../kern/kern_mutex.c:360 #7 0xc0695a60 in rt_check (lrt=0xe74b0980, lrt0=0xe74b099c, dst=0xc5a64e10) at ../../../net/route.c:1303 #8 0xc069f644 in arpresolve (ifp=0xc3bd0c00, rt0=0xc62d4d20, m=0xc3fff400, dst=0xc5a64e10, desten=0xe74b09b6 " ├D⌠ ├") at ../../../netinet/if_ether.c:373 #9 0xc068964e in ether_output (ifp=0xc3bd0c00, m=0xc3fff400, dst=0xc5a64e10, rt0=0xc62d4d20) at ../../../net/if_ethersubr.c:175 #10 0xc06ba9a5 in ip_output (m=0xc3fff400, opt=0x0, ro=0xe74b0a28, flags=Variable "flags" is not available.) at ../../../netinet/ip_output.c:547 #11 0xc06c2c7e in tcp_output (tp=0xc744a000) at ../../../netinet/tcp_output.c:1125 #12 0xc06cba12 in tcp_usr_send (so=0xc7fc3630, flags=Variable "flags" is not available.) at ../../../netinet/tcp_usrreq.c:839 #13 0xc06406a5 in sosend_generic (so=0xc7fc3630, addr=0x0, uio=0xe74b0c60, top=0xc437a100, control=0x0, flags=0, td=0xc83e6000) at ../../../kern/uipc_socket.c:1241 #14 0xc063c34f in sosend (so=0xc7fc3630, addr=0x0, uio=0xe74b0c60, top=0x0, control=0x0, flags=0, td=0xc83e6000) at ../../../kern/uipc_socket.c:1287 #15 0xc0624a3b in soo_write (fp=0xc9869948, uio=0xe74b0c60, active_cred=0xc9871000, flags=0, td=0xc83e6000) at ../../../kern/sys_socket.c:104 #16 0xc061e0c7 in dofilewrite (td=0xc83e6000, fd=3, fp=0xc9869948, auio=0xe74b0c60, offset=-1, flags=0) at file.h:254 #17 0xc061e3b8 in kern_writev (td=0xc83e6000, fd=3, auio=0xe74b0c60) at ../../../kern/sys_generic.c:404 #18 0xc061e42f in write (td=0xc83e6000, uap=0xe74b0cfc) at ../../../kern/sys_generic.c:320 #19 0xc07cb1e5 in syscall (frame=0xe74b0d38) at ../../../i386/i386/trap.c:1008 #20 0xc07b0770 in Xint0x80_syscall () at ../../../i386/i386/exception.s:196 #21 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 17:21:13 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E512716A417; Fri, 17 Aug 2007 17:21:13 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D1E6A13C46A; Fri, 17 Aug 2007 17:21:13 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 640AD1A3C1A; Fri, 17 Aug 2007 10:19:37 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id E2F00C0EF; Fri, 17 Aug 2007 13:21:12 -0400 (EDT) Date: Fri, 17 Aug 2007 13:21:11 -0400 From: Kris Kennaway To: Alexander Kabaev Message-ID: <20070817172110.GA29023@rot26.obsecurity.org> References: <20070817134526.GA27365@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <20070817134526.GA27365@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: Double mutex destruction (from loss of gateway route?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 17:21:14 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 17, 2007 at 01:45:26PM +0000, Alexander Kabaev wrote: > Hi, >=20 > I left development box running 7.0 sitting idle at work overnight and > was greeted with the following panic this morning: >=20 > panic: mtx_lock() of destroyed mutex @ ../../../net/route.c:1303 > cpuid =3D 1 > KDB: enter: panic > [thread pid 4088 tid 100128 ] > Stopped at kdb_enter+0x32: leave > db> bt > Tracing pid 4088 tid 100128 td 0xc5539cc0 > kdb_enter(c07c56bd,1,c07c4619,f199f9bc,1,...) at kdb_enter+0x32 > panic(c07c4619,c07d2ce5,517,507,c5386a7c,...) at panic+0x124 > _mtx_lock_flags(c5aeb510,0,c07d2ce5,517,f199fa28,...) at _mtx_lock_flags+= 0x65 > rt_check(f199fa20,f199fa3c,c541ec30,c080a6c4,c07d2cee,...) at rt_check+0x= 111 > arpresolve(c51e4000,c5584bb8,c5587d00,c541ec30,f199fa56,...) at arpresolv= e+0xb0 > ether_output(c51e4000,c5587d00,c541ec30,c5584bb8,c5539cc0,...) at ether_o= utput+0x7e > ip_output(c5587d00,0,f199fac4,0,0,...) at ip_output+0x9f5 > udp_send(c5a72000,0,c5587d00,c5a17970,0,...) at udp_send+0x597 > sosend_dgram(c5a72000,c5a17970,f199fbe8,c5587d00,0,...) at sosend_dgram+0= x351 > sosend(c5a72000,c5a17970,f199fbe8,0,0,...) at sosend+0x54 > kern_sendit(c5539cc0,4,f199fc64,0,0,...) at kern_sendit+0x104 > sendit(0,28228a34,0,c5a17970,10,...) at sendit+0x182 > sendto(c5539cc0,f199fcfc,18,c07c1d9e,c0804e18,...) at sendto+0x4f > syscall(f199fd38) at syscall+0x29a > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (133, FreeBSD ELF32, sendto), eip =3D 0x28152f23, esp =3D 0xb= fbfe2cc, ebp =3D 0xbfbfe3e8 --- >=20 >=20 > Is this one known? Unfortunately, vmcore from this panic got garbled some= how. It looks like a panic I was having when the gateway route disappeared from a sparc64 system. The switch seemed to be dodgy and would randomly drop the link, and the system would panic. Kris --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGxdkFWry0BWjoQKURAlodAKCdWW606JtH3YmCSKxkdE8fplJ9wwCeIsYZ tIwPgOxysa0EOOiThBK5RGo= =gJuH -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 17:53:11 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E974116A420; Fri, 17 Aug 2007 17:53:11 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D916013C481; Fri, 17 Aug 2007 17:53:11 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from rot26.obsecurity.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 5427A1A4D7C; Fri, 17 Aug 2007 10:51:35 -0700 (PDT) Received: by rot26.obsecurity.org (Postfix, from userid 1001) id 40CD8C0EF; Fri, 17 Aug 2007 13:53:11 -0400 (EDT) Date: Fri, 17 Aug 2007 13:53:11 -0400 From: Kris Kennaway To: sparc64@FreeBSD.org, current@FreeBSD.org Message-ID: <20070817175311.GB29597@rot26.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: sparc64 gcc problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 17:53:12 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline It looks like there are a few ports that have problems with our gcc compiler on sparc64. 1) Some of them complaing about missing libstdc++ symbols: /libexec/ld-elf.so.1: budgie/budgie: Undefined symbol "_ZN9__gnu_cxx18__exchange_and_addEPVii" /usr/local/lib/libAtlasObjects-0.6.so: undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)' /usr/local/lib/libvarconf-1.0.so: undefined reference to `_ZN9__gnu_cxx18__exchange_and_addEPVii@GLIBCXX_3.4' This seems to be a MD libstdc++ symbol that we may not be adding properly on sparc. 2) A couple of ports are failing like this: log.c:21894: warning: incompatible implicit declaration of built-in function 'strchr' {standard input}: Assembler messages: {standard input}:23537: Error: Illegal operands {standard input}:23597: Error: Illegal operands which makes me suspect that gcc is emitting opcodes that binutils cannot assemble. 3) there are a number of ports that are failing at runtime due to segfaults. Is anyone interested in investigating? Kris --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGxeCHWry0BWjoQKURAslHAJ4y5lYkFJykDV8AkBH/G3CNSikxvQCgv7xR cytPsiahHjBIlco5kR6CUQQ= =Uvqd -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 18:28:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9176816A418 for ; Fri, 17 Aug 2007 18:28:08 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 079C613C48D for ; Fri, 17 Aug 2007 18:28:07 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 75133 invoked from network); 17 Aug 2007 18:19:10 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Aug 2007 18:19:10 -0000 Message-ID: <46C5E8B6.7070807@freebsd.org> Date: Fri, 17 Aug 2007 20:28:06 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Andrew Gallatin References: <18116.43755.107638.103132@grasshopper.cs.duke.edu> In-Reply-To: <18116.43755.107638.103132@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: IPSEC disables TSO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 18:28:08 -0000 Andrew Gallatin wrote: > When tracking down an mxge 10GbE performance issue, I noticed that > simply compiling IPSEC into the kernel totally destroys 10GbE transmit > performance because it will silently disable TSO. > > The problem seems to be at least that the test on line 463 of > tcp_output.c (tp->t_inpcb->inp_sp == NULL) will always be > false. If I comment that line out, TSO works as normal > (though I have no idea what would happen on an IPSEC connection). > > Is there some way to make this not happen? I believe that the mxge > user simply wanted to run some handful of applications through ipsec > tunnels (perhaps even on a different NIC entirely). The idea was that ip->t_inpcb->inp_sp is NULL when no SP is active. This may no longer be the case after the FAST_IPSEC -> IPSEC switch and this test may have to be reevaluated. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 18:39:26 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2083116A418 for ; Fri, 17 Aug 2007 18:39:26 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 6BDED13C4A5 for ; Fri, 17 Aug 2007 18:39:25 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anb.matik.com.br (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l7HHbkag042288; Fri, 17 Aug 2007 14:37:46 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: Matt Date: Fri, 17 Aug 2007 14:37:42 -0300 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708171437.43201.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: current@freebsd.org Subject: Re: rc error with this morning's -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 18:39:26 -0000 On Friday 17 August 2007 12:49:15 Matt wrote: > I noticed an error thrown after booting into a -current build from > this morning (cvsup'd and built at around 9:30 AM). I am unsure which > rc script threw the error, but the relative position in > /var/log/messages is shown below: > > Aug 17 10:18:48 matt-bsd savecore: no dumps found > Aug 17 10:18:48 matt-bsd root: /etc/rc: ERROR: USAGE: load_rc_config name > Aug 17 10:18:48 matt-bsd root: /etc/rc: ERROR: USAGE: load_rc_config name > Aug 17 10:18:50 matt-bsd kernel: eth0: link state changed to UP > Aug 17 10:18:50 matt-bsd kernel: eth1: link state changed to UP > > uname -a output is: > FreeBSD matt-bsd.aei-msn.aeieng.com 7.0-CURRENT FreeBSD 7.0-CURRENT > #0: Fri Aug 17 09:48:30 CDT 2007 > root@matt-bsd.aei-msn.aeieng.com:/usr/obj/usr/src/sys/SMP-CUSTOM i386 > > There are no apparent ill effects for the system and all services seem > to have come up fine. Any suggestions for how I should track this > down and fix it? > with rcorder /etc/rc.d/* you can find out the order of execution and you check which of them you use= =20 next afert dumpon =20 =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Fri Aug 17 22:46:29 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C95D16A418; Fri, 17 Aug 2007 22:46:29 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 51E4C13C4A5; Fri, 17 Aug 2007 22:46:29 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (xrrxqkmk0d96xhuo@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l7HMkTAH094417; Fri, 17 Aug 2007 15:46:29 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l7HMkSfu094416; Fri, 17 Aug 2007 15:46:28 -0700 (PDT) (envelope-from jmg) Date: Fri, 17 Aug 2007 15:46:28 -0700 From: John-Mark Gurney To: stable@FreeBSD.org Message-ID: <20070817224628.GI99491@funkthat.com> Mail-Followup-To: stable@FreeBSD.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="4SFOXa2GPu3tIq4H" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-Mailman-Approved-At: Fri, 17 Aug 2007 22:54:19 +0000 Cc: Subject: 2TB+ on ahd broken? (6.2-R) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2007 22:46:29 -0000 --4SFOXa2GPu3tIq4H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I was just attempting to add a RAID shelf to a system w/ an Adaptec 29320 card, and when I export a 7TB disk to the card, and kept getting timeout related issues. The dump is very similar to PR 76178 which appears to be reporting the same issue... I have attached a dmesg w/ the failure... I tried various sizes and 1000000MB, 500MB and 2000000MB disks work... When I tried the full 7TB or 2.3TB disk, ahd failed w/ the messages at the end of the dmesg. Is anyone even working on this? As 2TB disks are coming soon, I'd imagine that ahd will need to get fixed before long, or are there just not many people use large disks w/ ahd? If ahd isn't getting fixed, can someone recommend a low profile PCI-X Ultra320 card? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --4SFOXa2GPu3tIq4H Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.splicer" Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Thu Jul 26 14:40:30 PDT 2007 root@splicer:/usr/src/sys/i386/compile/splicer Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x441d> Logical CPUs per core: 2 real memory = 1073676288 (1023 MB) avail memory = 1041502208 (993 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 3.0 on pci0 pci1: on pcib1 em0: port 0xac00-0xac1f mem 0xfc2e0000-0xfc2fffff irq 18 at device 1.0 on pci1 em0: Ethernet address: 00:04:23:be:9c:f4 pcib2: at device 28.0 on pci0 pci2: on pcib2 pcib3: at device 3.0 on pci2 pci3: on pcib3 arcmsr0: mem 0xfc3ff000-0xfc3fffff irq 27 at device 14.0 on pci3 ARECA RAID ADAPTER0: Driver Version 1.20.00.13 2006-8-18 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.36 2005-5-18 ahd0: port 0xb800-0xb8ff,0xb400-0xb4ff mem 0xfc5fe000-0xfc5fffff irq 26 at device 4.0 on pci2 ahd0: [GIANT-LOCKED] aic7901: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 50-66Mhz, 512 SCBs uhci0: port 0xe800-0xe81f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xec00-0xec1f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 29.4 (no driver attached) pci0: at device 29.5 (no driver attached) ehci0: mem 0xfe7ffc00-0xfe7fffff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered pcib4: at device 30.0 on pci0 pci4: on pcib4 pci4: at device 0.0 (no driver attached) fxp0: port 0xcc00-0xcc3f mem 0xfe6fe000-0xfe6fefff,0xfe6a0000-0xfe6bffff irq 17 at device 1.0 on pci4 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:04:23:be:9c:f5 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc07,0xd800-0xd803,0xd400-0xd40f irq 18 at device 31.2 on pci0 ata2: on atapci1 ata3: on atapci1 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xca7ff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: DMA limited to UDMA33, controller found non-ATA66 cable acd0: DVDR at ata0-master UDMA33 ad4: 715404MB at ata2-master SATA150 ad6: 476940MB at ata3-master SATA150 Waiting 5 seconds for SCSI devices to settle Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x0 0x0 0x0 0x0 0x0 pass1 at arcmsr0 bus 0 target 16 lun 0 pass1: Fixed Processor SCSI-0 device da0 at arcmsr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 166.666MB/s transfers (83.333MHz, offset 32, 16bit), Tagged Queueing Enabled da0: 953674MB (1953124352 512 byte sectors: 255H 63S/T 121576C) da1 at ahd0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da1: 1000000MB (2048000000 512 byte sectors: 255H 63S/T 127482C) da2 at ahd0 bus 0 target 0 lun 1 da2: Fixed Direct Access SCSI-3 device da2: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da2: 500MB (1024000 512 byte sectors: 64H 32S/T 500C) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/da0s1a WARNING: / was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted WARNING: /v/arch3 was not properly dismounted WARNING: /v/arch was not properly dismounted em0: link state changed to UP Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x3f 0xe 0x0 0x0 0x0 0x0 (da1:ahd0:0:0:0): lost device (da1:ahd0:0:0:0): removing device entry (ahd0:A:0:1): refuses tagged commands. Performing non-tagged I/O (da2:ahd0:0:0:1): lost device (da2:ahd0:0:0:1): removing device entry da1 at ahd0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da1: 500MB (1024000 512 byte sectors: 64H 32S/T 500C) Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x3f 0xe 0x0 0x0 0x0 0x0 Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x3f 0xe 0x0 0x0 0x0 0x0 da2 at ahd0 bus 0 target 0 lun 1 da2: Fixed Direct Access SCSI-3 device da2: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da2: 2000000MB (4096000000 512 byte sectors: 255H 63S/T 254964C) Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x3f 0xe 0x0 0x0 0x0 0x0 (da1:ahd0:0:0:0): lost device (da1:ahd0:0:0:0): removing device entry (da1:ahd0:0:0:0): No or incomplete CDB sent to device. (da1:ahd0:0:0:0): Protocol violation in Message-in phase. Attempting to abort. (da1:ahd0:0:0:0): Abort Tag Message Sent (da1:ahd0:0:0:0): SCB 15 - Abort Completed. found == 0x1 ahd0:A:0: no active SCB for reconnecting target - issuing BUS DEVICE RESET SAVED_SCSIID == 0x7, SAVED_LUN == 0x1, REG0 == 0x1 ACCUM = 0x0 SEQ_FLAGS == 0x0, SCBPTR == 0x1, BTT == 0xffff, SINDEX == 0x1ba SELID == 0x0, SCB_SCSIID == 0xe7, SCB_LUN == 0x0, SCB_CONTROL == 0x40 SCSIBUS[0] == 0x81, SCSISIGI == 0xe6 SXFRCTL0 == 0x88 SEQCTL0 == 0x0 >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd0: Dumping Card State at program address 0x15f Mode 0x33 Card was paused INTSTAT[0x0] SELOID[0x0] SELID[0x0] HS_MAILBOX[0x0] INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE) SCSISIGI[0xe6]:(P_MESGIN|REQI|BSYI) SCSIPHASE[0x8]:(MSG_IN_PHASE) SCSIBUS[0x81] LASTPHASE[0xe0]:(P_MESGIN) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x0] SEQINTCTL[0x0] SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x7] KERNEL_QFREEZE_COUNT[0x7] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] SSTAT0[0x2]:(SPIORDY) SSTAT1[0x11]:(REQINIT|PHASEMIS) SSTAT2[0xc0]:(BUSFREE_DFF1) SSTAT3[0x0] PERRDIAG[0xc0]:(HIPERR|HIZERO) SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 16 CMDS_PENDING = 1 LASTSCB 0xffff CURRSCB 0xf NEXTSCB 0xff80 qinstart = 197 qinfifonext = 198 QINFIFO: 0xf WAITING_TID_QUEUES: Pending list: 15 FIFO_USE[0x0] SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x7] 14 FIFO_USE[0x0] SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x7] Total 2 Kernel Free SCB list: 1 13 12 11 10 9 8 7 6 5 4 3 2 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: Sequencer On QFreeze and Complete list: ahd0: FIFO0 Free, LONGJMP == 0x8253, SCB 0xf SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) ahd0: FIFO1 Free, LONGJMP == 0x8063, SCB 0xf SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x4]:(DIRECTION) DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) LQIN: 0x8 0x0 0x0 0xf 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd0: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x52 ahd0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 ahd0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x4]:(CCSCBDIR) ahd0: REG0 == 0x1, SINDEX = 0x1ba, DINDEX = 0x1ba ahd0: SCBPTR == 0x1, SCB_NEXT == 0xff00, SCB_NEXT2 == 0xe CDB 12 0 0 0 24 0 STACK: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> ahd0: Someone reset channel A (da1:ahd0:0:0:0): No or incomplete CDB sent to device. (da1:ahd0:0:0:0): Protocol violation in Message-in phase. Attempting to abort. (da1:ahd0:0:0:0): Abort Tag Message Sent (da1:ahd0:0:0:0): SCB 14 - Abort Completed. found == 0x1 (da1:ahd0:0:0:0): No or incomplete CDB sent to device. (da1:ahd0:0:0:0): Protocol violation in Message-in phase. Attempting to abort. (da1:ahd0:0:0:0): Abort Tag Message Sent (da1:ahd0:0:0:0): SCB 14 - Abort Completed. found == 0x1 (da1:ahd0:0:0:0): No or incomplete CDB sent to device. (da1:ahd0:0:0:0): Protocol violation in Message-in phase. Attempting to abort. (da1:ahd0:0:0:0): Abort Tag Message Sent (da1:ahd0:0:0:0): SCB 14 - Abort Completed. found == 0x1 (da1:ahd0:0:0:0): No or incomplete CDB sent to device. (da1:ahd0:0:0:0): Protocol violation in Message-in phase. Attempting to abort. (da1:ahd0:0:0:0): Abort Tag Message Sent (da1:ahd0:0:0:0): SCB 14 - Abort Completed. found == 0x1 (da1:ahd0:0:0:0): got CAM status 0x54 (da1:ahd0:0:0:0): fatal error, failed to attach to device (da1:ahd0:0:0:0): lost device (da1:ahd0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:ahd0:0:0:0): CAM Status: SCSI Status Error (da1:ahd0:0:0:0): SCSI Status: Check Condition (da1:ahd0:0:0:0): UNIT ATTENTION asc:29,0 (da1:ahd0:0:0:0): Power on, reset, or bus device reset occurred (da1:ahd0:0:0:0): Retrying Command (per Sense Data) (da1:ahd0:0:0:0): No or incomplete CDB sent to device. (da1:ahd0:0:0:0): Protocol violation in Message-in phase. Attempting to abort. (da1:ahd0:0:0:0): Abort Tag Message Sent (da1:ahd0:0:0:0): SCB 14 - Abort Completed. found == 0x1 (da1:ahd0:0:0:0): No or incomplete CDB sent to device. (da1:ahd0:0:0:0): Protocol violation in Message-in phase. Attempting to abort. (da1:ahd0:0:0:0): Abort Tag Message Sent (da1:ahd0:0:0:0): SCB 14 - Abort Completed. found == 0x1 (da1:ahd0:0:0:0): No or incomplete CDB sent to device. (da1:ahd0:0:0:0): Protocol violation in Message-in phase. Attempting to abort. (da1:ahd0:0:0:0): Abort Tag Message Sent (da1:ahd0:0:0:0): SCB 14 - Abort Completed. found == 0x1 (da1:ahd0:0:0:0): No or incomplete CDB sent to device. (da1:ahd0:0:0:0): Protocol violation in Message-in phase. Attempting to abort. (da1:ahd0:0:0:0): Abort Tag Message Sent (da1:ahd0:0:0:0): SCB 14 - Abort Completed. found == 0x1 (da1:ahd0:0:0:0): No or incomplete CDB sent to device. (da1:ahd0:0:0:0): Protocol violation in Message-in phase. Attempting to abort. (da1:ahd0:0:0:0): Abort Tag Message Sent (da1:ahd0:0:0:0): SCB 14 - Abort Completed. found == 0x1 (da1:ahd0:0:0:0): removing device entry Opened disk da1 -> 5 --4SFOXa2GPu3tIq4H-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 18 01:55:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E32516A418 for ; Sat, 18 Aug 2007 01:55:31 +0000 (UTC) (envelope-from william88@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 2321F13C45D for ; Sat, 18 Aug 2007 01:55:31 +0000 (UTC) (envelope-from william88@gmail.com) Received: by wa-out-1112.google.com with SMTP id m33so37565wag for ; Fri, 17 Aug 2007 18:55:30 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=GcVIkomon1KqTzvwsJHM8EI0Hy9UPF+Cprtdd9otEhWvn2Uo1ref1co5A9YeYLbmmKTLtCUvfqFFSjyzw87DDvGEOmkUqtUcF1bw1viMynecV84ifNuVF473tlVLM40npy6KhdqE91dluKNnT0Y/GpfFbHG4rOY25y+yZX0uCcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=pPz6mrL/rzzxbxKMq0W2khB41OcMxcj/sojK3lFu4Lc0ts1ogBqrFWSh/1Os+L4Qiae4oVrRPJE5wEMUYP0lsCYqkXY5qucdK3UaIWvEwOxqLOgxqb7phooDPV5o8ytSdp8hRtEz2gRwJy68HVFUOdG6g04y0gAGcuLiQvbrepA= Received: by 10.114.132.5 with SMTP id f5mr2084306wad.1187402130781; Fri, 17 Aug 2007 18:55:30 -0700 (PDT) Received: by 10.114.111.4 with HTTP; Fri, 17 Aug 2007 18:55:30 -0700 (PDT) Message-ID: <632825b40708171855u155d0195udb6994999de12d15@mail.gmail.com> Date: Fri, 17 Aug 2007 22:55:30 -0300 From: "William Grzybowski" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Atheros AR5006 abg minipci X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 01:55:31 -0000 Hi, I got wireless minipci atheros ar5006 with -CURRENT. Cant use it even with if_ndis and i didnt tried on stable/release yet. dmesg: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xd0000000-0xd000ffff irq 16 at device 0.0 on pci3 ath0: [ITHREAD] ath0: unable to attach hardware; HAL status 13 device_attach: ath0 attach returned 6 I tried to search about it on the history without success, does it means this card isn't supported yey? could i do anything providing info to help? Should I forward this message to another list? Thanks. -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Msn: william.grz at hotmail dot com Curitiba/PR From owner-freebsd-current@FreeBSD.ORG Sat Aug 18 03:17:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22A2E16A417 for ; Sat, 18 Aug 2007 03:17:40 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id EF92713C45A for ; Sat, 18 Aug 2007 03:17:39 +0000 (UTC) (envelope-from sam@errno.com) Received: from sam-lefflers-powerbook-g4-15.local (sam@[10.0.0.178]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l7I3Hbxk080335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 20:17:37 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46C664D0.3060906@errno.com> Date: Fri, 17 Aug 2007 20:17:36 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: William Grzybowski References: <632825b40708171855u155d0195udb6994999de12d15@mail.gmail.com> In-Reply-To: <632825b40708171855u155d0195udb6994999de12d15@mail.gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Atheros AR5006 abg minipci X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 03:17:40 -0000 William Grzybowski wrote: > Hi, > > I got wireless minipci atheros ar5006 with -CURRENT. > Cant use it even with if_ndis and i didnt tried on stable/release yet. > dmesg: > > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath0: mem 0xd0000000-0xd000ffff irq 16 at device 0.0 on > pci3 > ath0: [ITHREAD] > ath0: unable to attach hardware; HAL status 13 > device_attach: ath0 attach returned 6 > > I tried to search about it on the history without success, does it means > this card isn't supported yey? could i do anything providing info to help? > Should I forward this message to another list? You can try the test hal in http://www.freebsd.org/~sam. Beware it is not a release (has not undergone full testing and has known issues). If the 0.9.30.3 hal doesn't work then your part is probably a 2425. Support for that part has been blocked waiting on Atheros for >1 month. No idea when it might show up. Sam From owner-freebsd-current@FreeBSD.ORG Sat Aug 18 06:54:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 663F516A41B for ; Sat, 18 Aug 2007 06:54:33 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2-b.corp.dcn.yahoo.com (mrout2-b.corp.dcn.yahoo.com [216.109.112.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1600513C474 for ; Sat, 18 Aug 2007 06:54:32 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l7I6iHFI028920; Fri, 17 Aug 2007 23:44:18 -0700 (PDT) Date: Sat, 18 Aug 2007 15:44:07 +0900 Message-ID: From: gnn@freebsd.org To: Andre Oppermann In-Reply-To: <46C5E8B6.7070807@freebsd.org> References: <18116.43755.107638.103132@grasshopper.cs.duke.edu> <46C5E8B6.7070807@freebsd.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current@freebsd.org, Andrew Gallatin Subject: Re: IPSEC disables TSO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 06:54:33 -0000 OK, I've got the PR, thanks, I'll try to think more about this. Best, George From owner-freebsd-current@FreeBSD.ORG Sat Aug 18 07:43:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4ABE16A418 for ; Sat, 18 Aug 2007 07:43:50 +0000 (UTC) (envelope-from jacob.hart@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id 8B94513C457 for ; Sat, 18 Aug 2007 07:43:50 +0000 (UTC) (envelope-from jacob.hart@gmail.com) Received: by wa-out-1112.google.com with SMTP id m33so123927wag for ; Sat, 18 Aug 2007 00:43:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=iGc1gBFXxQEt+st9IIN86J+WM+4KY4JZRyH8yrhCBGbllZ0la+PNBM4EAJIlRZzRizmjXGjykgtqahcDvmC4HkczTPOpNycBSKIEkcsc8iWiJwJfIQVews+5p77uJnwQbxlVlheS46HIMZVNA730kU7Vee9G9JnzwYuNI3eqHUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=eR9pCpyTEf/LlRbg11dK4ZKklq3WrJesvvNP59+YWaCZUhCHHte6A14Q2T1C76rb4g4sAyV1pqftQqs9Kp28KeXz2XAZAlK6BM2pEmP9941cJZbaKw1w5EP2Ibg4r7n+UO3J8BtLTlTOvERU4X4Nl7VwbotyPIs5VvEY9BnDtaU= Received: by 10.115.106.7 with SMTP id i7mr1476374wam.1187421577386; Sat, 18 Aug 2007 00:19:37 -0700 (PDT) Received: by 10.114.150.11 with HTTP; Sat, 18 Aug 2007 00:19:37 -0700 (PDT) Message-ID: <139a3a1b0708180019n183eeda6j493b0ca8eec2c4b4@mail.gmail.com> Date: Sat, 18 Aug 2007 17:19:37 +1000 From: "Jacob Hart" Sender: jacob.hart@gmail.com To: "Sam Leffler" , freebsd-current@freebsd.org In-Reply-To: <46C664D0.3060906@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <632825b40708171855u155d0195udb6994999de12d15@mail.gmail.com> <46C664D0.3060906@errno.com> X-Google-Sender-Auth: 981091b45aab147c Cc: Subject: Re: Atheros AR5006 abg minipci X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 07:43:50 -0000 Sam, I'm using the 0.9.30.3 hal on a recently built -CURRENT, and my wireless is detected as shown: ath0: mem 0x90100000-0x9010ffff irq 17 at device 0.0 on pci2 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:17:f2:e9:64:19 ath0: mac 12.10 phy 8.1 radio 12.0 In my quest for a quieter notebook I've been experimenting with powerd. The wireless connection works reliably if debug.cpufreq.lowest sysctl is set to restrict the CPU frequency to 1.16GHz or greater (it is a 2GHz core2 duo using the est driver), but anything under that it begins to show some instability. At 1GHz and 875MHz the wireless connection will intermittently freeze. I can usually resurrect the connection by forcing wpa_supplicant to reassociate with the AP (from wpa_cli) or, if not, by restarting the ath0 interface via /etc/rc.d/netif restart. At 750MHz I experience the same problem as above, but occasionally the if_ath module must be unloaded and re-loaded, then the ath0 interface brought back up before the driver will be able to associate with an AP. At 500MHz i must always unload and reload the if_ath module. Scanning usually works, but association with an AP is not guaranteed at this speed; i'd estimate it works about 25% of the time. At speeds below 500Mhz, it is not possible to scan or associate with an AP. Is this a known known issue with the driver or is it specific to my system? Further, is there anything I can do to help track down the problem? -j On 8/18/07, Sam Leffler wrote: > William Grzybowski wrote: > > Hi, > > > > I got wireless minipci atheros ar5006 with -CURRENT. > > Cant use it even with if_ndis and i didnt tried on stable/release yet. > > dmesg: > > > > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > > ath0: mem 0xd0000000-0xd000ffff irq 16 at device 0.0 on > > pci3 > > ath0: [ITHREAD] > > ath0: unable to attach hardware; HAL status 13 > > device_attach: ath0 attach returned 6 > > > > I tried to search about it on the history without success, does it means > > this card isn't supported yey? could i do anything providing info to help? > > Should I forward this message to another list? > > You can try the test hal in http://www.freebsd.org/~sam. Beware it is > not a release (has not undergone full testing and has known issues). If > the 0.9.30.3 hal doesn't work then your part is probably a 2425. > Support for that part has been blocked waiting on Atheros for >1 month. > No idea when it might show up. > > Sam > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Aug 18 08:27:58 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EF8B16A421 for ; Sat, 18 Aug 2007 08:27:58 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by mx1.freebsd.org (Postfix) with ESMTP id 63B2C13C458 for ; Sat, 18 Aug 2007 08:27:58 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from prometheus.scode.org (85.229.22.84) by proxy1.bredband.net (7.3.127) id 46C5A96A0002D93D for current@freebsd.org; Sat, 18 Aug 2007 10:27:57 +0200 Received: from localhost (localhost [127.0.0.1]) by prometheus.scode.org (Postfix) with ESMTP id 86A8F1CC7B for ; Sat, 18 Aug 2007 10:28:14 +0200 (CEST) From: Peter Schuller To: current@freebsd.org Date: Sat, 18 Aug 2007 10:28:13 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708181028.13882.peter.schuller@infidyne.com> Cc: Subject: ZFS: Listable but un-stat():able snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 08:27:58 -0000 Hello, first off, this is on a machine running CURRENT from ~ 2007-05-08, so perhaps this is no longer an issue. But I don't remember reading about it anywhere. zfs list contains among other things (full path obscured, but otherwise exactly as-is): XXX@rsync 0 - 146G - XXX@200708181011 0 - 146G - XXX@rsync2 126K - 146G - I took the first two snapshots rapidly in succession after each other - I believe without any I/O to the fs in between. After I could not "cd" into the rsync snapshot, I took another one (rsync2) for testing. ls XXX/.zfs/snapshot: 200708122313 200708180037 200708181011 rsync rsync2 ls -l XXX/.zfs/snapshot (username obscured): ls: rsync: No such file or directory drwx------ 12 YYY YYY 43 Aug 12 22:31 200708122313 drwx------ 12 YYY YYY 43 Aug 18 00:30 200708180037 drwx------ 12 YYY YYY 43 Aug 18 09:30 200708181011 drwx------ 12 YYY YYY 43 Aug 18 09:30 rsync2 cd XXX/.zfs/snapshot/rsync: cd: no such file or directory: XXX/.zfs/snapshot/rsync Excerpt of kdump after ktrace ls -l: 55508 ls CALL getdirentries(0x5,0x28214000,0x1000,0x28213054) 55508 ls RET getdirentries 128/0x80 55508 ls CALL lstat(0x28216168,0x28216108) 55508 ls NAMI "200708181011" 55508 ls RET lstat 0 55508 ls CALL lstat(0x28216228,0x282161c8) 55508 ls NAMI "200708180037" 55508 ls RET lstat 0 55508 ls CALL lstat(0x282162e8,0x28216288) 55508 ls NAMI "200708122313" 55508 ls RET lstat 0 55508 ls CALL lstat(0x28211268,0x28211208) 55508 ls NAMI "rsync2" 55508 ls RET lstat 0 55508 ls CALL lstat(0x28211318,0x282112b8) 55508 ls NAMI "rsync" 55508 ls RET lstat -1 errno 2 No such file or directory I still have the snapshot on the machine and such if anybody wants me to run some diagnostic commands. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org From owner-freebsd-current@FreeBSD.ORG Sat Aug 18 10:44:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6885816A418 for ; Sat, 18 Aug 2007 10:44:24 +0000 (UTC) (envelope-from ted@omval.tednet.nl) Received: from omval.tednet.nl (omval.tednet.nl [IPv6:2001:7b8:206:1:200:39ff:fe59:b187]) by mx1.freebsd.org (Postfix) with ESMTP id 03CD413C48E for ; Sat, 18 Aug 2007 10:44:23 +0000 (UTC) (envelope-from ted@omval.tednet.nl) Received: from omval.tednet.nl (localhost [127.0.0.1]) by omval.tednet.nl (8.14.1/8.14.1) with ESMTP id l7IAiJfu001529 for ; Sat, 18 Aug 2007 12:44:19 +0200 (CEST) (envelope-from ted@omval.tednet.nl) Received: (from ted@localhost) by omval.tednet.nl (8.14.1/8.14.1/Submit) id l7IAiJ6q001528 for freebsd-current@freebsd.org; Sat, 18 Aug 2007 12:44:19 +0200 (CEST) (envelope-from ted) Message-Id: <200708181044.l7IAiJ6q001528@omval.tednet.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Sat, 18 Aug 2007 12:44:18 +0200 X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: freebsd-current@freebsd.org X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on omval.tednet.nl X-Mailman-Approved-At: Sat, 18 Aug 2007 11:29:32 +0000 Subject: /etc/rc: ERROR: USAGE: load_rc_config name X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 10:44:24 -0000 After my daily update I see: Aug 18 11:42:37 omval root: /etc/rc: ERROR: USAGE: load_rc_config name Aug 18 11:42:37 omval kernel: /etc/rc: ERROR: USAGE: load_rc_config name Aug 18 11:42:37 omval root: /etc/rc: ERROR: USAGE: load_rc_config name Aug 18 11:42:37 omval kernel: /etc/rc: ERROR: USAGE: load_rc_config name The problem is in /etc/rc.d/lockd en /etc/rc.d/statd, which call load_rc_config $name without setting "name". regards, -- ted From owner-freebsd-current@FreeBSD.ORG Sat Aug 18 13:17:18 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 687F316A481 for ; Sat, 18 Aug 2007 13:17:18 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from ns.tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB7013C45D for ; Sat, 18 Aug 2007 13:17:10 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by ns.tydfam.jp (8.14.1/8.14.1) with ESMTP id l7ICUfBE011165; Sat, 18 Aug 2007 21:31:13 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Sat, 18 Aug 2007 21:32:08 +0900 (JST) Message-Id: <20070818.213208.74754361.ken@tydfam.jp> To: glewis@eyesbeyond.com From: Ken Yamada In-Reply-To: <20070815144804.GC5151@misty.eyesbeyond.com> References: <1186303666.36623.23.camel@tobias.wg.> <20070815144804.GC5151@misty.eyesbeyond.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91/3982/Sat Aug 18 16:45:32 2007 on ns.tydfam.jp X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on ns.tydfam.jp Cc: freebsd-java@freebsd.org, lists_freebsd_org@07.antispam.web-wahnsinn.de, freebsd-current@freebsd.org Subject: Re: Gcc bugs break java/jdk15 build? [Workaround] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 13:17:18 -0000 FYI. GCC 4.2.1 alone did not solve the compilation problem on -current, but with -fno-tree-vrp compilation went without any problem. I added -fno-tree-vrp to CFLAGS in /etc/make.conf, and jdk15/jdk16 compilationwent successfull. From owner-freebsd-current@FreeBSD.ORG Sat Aug 18 13:50:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3A8D16A417 for ; Sat, 18 Aug 2007 13:50:26 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp804.mail.ird.yahoo.com (smtp804.mail.ird.yahoo.com [217.146.188.64]) by mx1.freebsd.org (Postfix) with SMTP id 3540013C483 for ; Sat, 18 Aug 2007 13:50:25 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 39067 invoked from network); 18 Aug 2007 13:23:43 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.140.28.215 with plain) by smtp804.mail.ird.yahoo.com with SMTP; 18 Aug 2007 13:23:43 -0000 X-YMail-OSG: 9Nr19mIVM1kpofDDaTtZ2LMNmBzBGpfzt5ZneBqgM19k4anO Message-ID: <46C7019B.7090003@tomjudge.com> Date: Sat, 18 Aug 2007 15:26:35 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Ted Lindgreen References: <200708181044.l7IAiJ6q001528@omval.tednet.nl> In-Reply-To: <200708181044.l7IAiJ6q001528@omval.tednet.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: /etc/rc: ERROR: USAGE: load_rc_config name X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 13:50:26 -0000 Ted Lindgreen wrote: > After my daily update I see: > > Aug 18 11:42:37 omval root: /etc/rc: ERROR: USAGE: load_rc_config name > Aug 18 11:42:37 omval kernel: /etc/rc: ERROR: USAGE: load_rc_config name > Aug 18 11:42:37 omval root: /etc/rc: ERROR: USAGE: load_rc_config name > Aug 18 11:42:37 omval kernel: /etc/rc: ERROR: USAGE: load_rc_config name > > The problem is in /etc/rc.d/lockd en /etc/rc.d/statd, which call > > load_rc_config $name > > without setting "name". > > regards, > -- ted This was fixed in the commit at the following time: mtm 2007-08-18 04:08:53 UTC Tom From owner-freebsd-current@FreeBSD.ORG Sat Aug 18 14:10:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FE3916A417 for ; Sat, 18 Aug 2007 14:10:34 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3937C13C442 for ; Sat, 18 Aug 2007 14:10:33 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-34-175.lns10.adl2.internode.on.net [121.45.34.175]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id l7IEAH6U032694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Aug 2007 23:40:26 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sat, 18 Aug 2007 23:39:59 +0930 User-Agent: KMail/1.9.7 References: <200708100010.46487.h.schmalzbauer@omnisec.de> <200708100052.39861.h.schmalzbauer@omnisec.de> <626eb4530708091703j18bd2cd7w99f9b96a3f3c402c@mail.gmail.com> In-Reply-To: <626eb4530708091703j18bd2cd7w99f9b96a3f3c402c@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200708182340.00680.doconnor@gsoft.com.au> X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 203.31.81.10 Cc: Hidetoshi Shimokawa , Harald Schmalzbauer Subject: Re: firewire problem (root node is not cycle master capable) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 14:10:34 -0000 On Fri, 10 Aug 2007, Hidetoshi Shimokawa wrote: > On 8/10/07, Harald Schmalzbauer wrote: > > Am Freitag, 10. August 2007 00:23:41 schrieb Hidetoshi Shimokawa: > > > Basically, you don't need the cycle master for sbp devices. > > > Try the following. > > > > > > 1. fwcontrol -r > > > 2. fwcontrol -f 0 -r > > > > Hm, I think that's a typo, the man page doesn't show "-f" nor does > > my fwcontrol understand it. > > Oops, it was an uncommited option in my repository which sends > force_root packets. Any chance you can post a diff? I see this on a remote machine and would like to try it. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-current@FreeBSD.ORG Sat Aug 18 15:24:25 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3A7616A419 for ; Sat, 18 Aug 2007 15:24:25 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 89E7A13C442 for ; Sat, 18 Aug 2007 15:24:25 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IMQA4-0000hD-7y; Sat, 18 Aug 2007 15:24:24 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IMQA2-000AhE-BS; Sat, 18 Aug 2007 05:24:22 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18119.3872.547510.973785@roam.psg.com> Date: Sat, 18 Aug 2007 05:24:16 -1000 To: Robert Huff References: <20070815122747.GA62123@duncan.reilly.home> <18117.37649.6266.369458@jerusalem.litteratus.org> Cc: freebsd-current@freebsd.org Subject: Re: Does 7-CURRENT (aka cvsup tag=.) build under 6-STABLE? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 15:24:25 -0000 i just upgraded two RELENG_6 boxes to 7-CURRENT last eve. no prob. i was silly and broke the union rules by following the instructions at the bottom of /usr/src/UPDATING. it is extremely rare that i have had problems on this path, 4 to 5, 5 to 6, 6 to 7. have not tried 7 to 8 yet. randy From owner-freebsd-current@FreeBSD.ORG Sat Aug 18 16:29:08 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0B7D16A46B for ; Sat, 18 Aug 2007 16:29:08 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id 87B3313C4D3 for ; Sat, 18 Aug 2007 16:29:08 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from bruce-a-mahs-computer.local (hornet.kitchenlab.org [64.142.31.105]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l7IGT2nj003243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Aug 2007 09:29:08 -0700 Message-ID: <46C71E46.9040305@freebsd.org> Date: Sat, 18 Aug 2007 09:28:54 -0700 From: "Bruce A. Mah" User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Peter Schuller References: <200708181028.13882.peter.schuller@infidyne.com> In-Reply-To: <200708181028.13882.peter.schuller@infidyne.com> X-Enigmail-Version: 0.95.3 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4A33ECA5A8AD9170DCBECD79" Cc: current@freebsd.org Subject: Re: ZFS: Listable but un-stat():able snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 16:29:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4A33ECA5A8AD9170DCBECD79 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Peter Schuller wrote: > Hello, >=20 > first off, this is on a machine running CURRENT from ~ 2007-05-08, so p= erhaps=20 > this is no longer an issue. But I don't remember reading about it anywh= ere. >=20 > zfs list contains among other things (full path obscured, but otherwise= =20 > exactly as-is): >=20 > XXX@rsync 0 - 146G - > XXX@200708181011 0 - 146G - > XXX@rsync2 126K - 146G - >=20 > I took the first two snapshots rapidly in succession after each other -= I=20 > believe without any I/O to the fs in between. After I could not "cd" in= to the=20 > rsync snapshot, I took another one (rsync2) for testing. >=20 > ls XXX/.zfs/snapshot: >=20 > 200708122313 200708180037 200708181011 rsync rsync2 >=20 > ls -l XXX/.zfs/snapshot (username obscured): >=20 > ls: rsync: No such file or directory > drwx------ 12 YYY YYY 43 Aug 12 22:31 200708122313 > drwx------ 12 YYY YYY 43 Aug 18 00:30 200708180037 > drwx------ 12 YYY YYY 43 Aug 18 09:30 200708181011 > drwx------ 12 YYY YYY 43 Aug 18 09:30 rsync2 >=20 > cd XXX/.zfs/snapshot/rsync: >=20 > cd: no such file or directory: XXX/.zfs/snapshot/rsync I've seen something similar to this (several months ago?). But I wasn't able to do much more investigation, nor was I able to reproduce the problem reliably. pjd@ and I talked about it briefly and while we agreed there was a problem, it wasn't obvious what it was. I think I made the problem go away with a reboot. Bruce. > Excerpt of kdump after ktrace ls -l: >=20 > 55508 ls CALL getdirentries(0x5,0x28214000,0x1000,0x28213054) > 55508 ls RET getdirentries 128/0x80 > 55508 ls CALL lstat(0x28216168,0x28216108) > 55508 ls NAMI "200708181011" > 55508 ls RET lstat 0 > 55508 ls CALL lstat(0x28216228,0x282161c8) > 55508 ls NAMI "200708180037" > 55508 ls RET lstat 0 > 55508 ls CALL lstat(0x282162e8,0x28216288) > 55508 ls NAMI "200708122313" > 55508 ls RET lstat 0 > 55508 ls CALL lstat(0x28211268,0x28211208) > 55508 ls NAMI "rsync2" > 55508 ls RET lstat 0 > 55508 ls CALL lstat(0x28211318,0x282112b8) > 55508 ls NAMI "rsync" > 55508 ls RET lstat -1 errno 2 No such file or directory >=20 > I still have the snapshot on the machine and such if anybody wants me t= o run=20 > some diagnostic commands. >=20 --------------enig4A33ECA5A8AD9170DCBECD79 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGxx5L2MoxcVugUsMRAu2eAKDQmUT60antdtXRSUyGKUM7HpLNvACglOKR O0QQCl3C0yW5g8o3Bgx9QHg= =KHVd -----END PGP SIGNATURE----- --------------enig4A33ECA5A8AD9170DCBECD79-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 18 17:53:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B4C016A41A for ; Sat, 18 Aug 2007 17:53:04 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: from abbe.salford.ac.uk (abbe.salford.ac.uk [146.87.0.10]) by mx1.freebsd.org (Postfix) with SMTP id B13E113C481 for ; Sat, 18 Aug 2007 17:53:02 +0000 (UTC) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 76982 invoked by uid 98); 18 Aug 2007 18:26:20 +0100 Received: from 146.87.255.121 by abbe.salford.ac.uk (envelope-from , uid 401) with qmail-scanner-2.01 (clamdscan: 0.90/3838. spamassassin: 3.1.8. Clear:RC:1(146.87.255.121):. Processed in 0.328644 secs); 18 Aug 2007 17:26:20 -0000 Received: from rust.salford.ac.uk (HELO rust.salford.ac.uk) (146.87.255.121) by abbe.salford.ac.uk (qpsmtpd/0.3x.614) with SMTP; Sat, 18 Aug 2007 18:26:20 +0100 Received: (qmail 78106 invoked by uid 1002); 18 Aug 2007 17:26:18 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Aug 2007 17:26:18 -0000 Date: Sat, 18 Aug 2007 18:26:18 +0100 (BST) From: "Mark Powell" To: freebsd-current@freebsd.org Message-ID: <20070818163810.I75076@rust.salford.ac.uk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1376663942-1187457978=:75076" X-Mailman-Approved-At: Sat, 18 Aug 2007 18:15:54 +0000 Subject: 7.0-CURRENT MCP55 PATA to SATA convertor problems on Asus M2N32 WS Pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 17:53:04 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1376663942-1187457978=:75076 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi, Been experimenting with the June snapshot of i386 7.0-CURRENT for some weeks now, on an Athlon XP. I had a 3 drive ZFS fs on PATA drives. Tried to move my installation to an Asus M2N32 WS Pro motherboard based system (Nforce 590 SLI). It supports 8 possible drives on the chipset 2xPATA + 6xSATA, which are reported by 6.2 as these controllers: atapci0: nVidia nForce MCP55 UDMA133 Controller atapci1: nVidia nForce MCP55 SATA300 Controller atapci2: nVidia nForce MCP55 SATA300 Controller atapci3: nVidia nForce MCP55 SATA300 Controller I put the drives onto some PATA-SATA convertors that I had. They have always worked before with 6.2. Even though they are connected to SATA ports, the 6.2 kernel displays the drive as UDMA100 or such rather than SATA150 i.e. it is aware they are PATA drives. When 7.0 tries to probe the SATA converted drives connected to the SATA controllers it gives the following error, for each drive (after suitable timeout): unknown: timeout waiting to issue command unknown: error issuing ATA_IDENTIFY command After this failed probing, a later hard reset of the PC causes the BIOS then to fail to detect any SATA drives. The system needs power cycling before the BIOS is happy detecting all drives again. The failed probing of 7.0 seems to mess the controller up somehow, that even a hard reset doesn't fix (which strikes me as unusual). 7.0 has no problems detecting and identifying the drives when they are directly connected to the UDMA133 controller. 7.0 also has no problems probing a real SATA drive. It seems to be only converted drives. See boot -v attached. This is with both amd64 and i386 7.0-CURRENT June snapshot. I've also updated to and rebuilt CURRENT i386 as of today and removed all usb modules (just in case), with no improvement in this problem. However, 6.2 seems to have no problems with this hardware i.e. it probes the converted PATA drives on SATA ports without issue. If you need any more info, I'd be glad to provide it. Many thanks. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key --0-1376663942-1187457978=:75076 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=bootv7 Content-Transfer-Encoding: BASE64 Content-ID: <20070818182618.X75076@rust.salford.ac.uk> Content-Description: Content-Disposition: attachment; filename=bootv7 VGFibGUgJ1RDUEEnIGF0IDB4M2ZlZWNlODANClRhYmxlICdTU0RUJyBhdCAw eDNmZWVjZjAwDQpUYWJsZSAnSFBFVCcgYXQgMHgzZmVlZDIwMA0KVGFibGUg J01DRkcnIGF0IDB4M2ZlZWQyODANClRhYmxlICdBUElDJyBhdCAweDNmZWVj ZGMwDQpNQURUOiBGb3VuZCB0YWJsZSBhdCAweDNmZWVjZGMwDQpBUElDOiBV c2luZyB0aGUgTUFEVCBlbnVtZXJhdG9yLg0KTUFEVDogRm91bmQgQ1BVIEFQ SUMgSUQgMCBBQ1BJIElEIDA6IGVuYWJsZWQNClNNUDogQWRkZWQgQ1BVIDAg KEFQKQ0KTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMSBBQ1BJIElEIDE6IGVu YWJsZWQNClNNUDogQWRkZWQgQ1BVIDEgKEFQKQ0KQUNQSSBBUElDIFRhYmxl OiA8TnZpZGlhIEFTVVNBQ1BJPg0KQ2FsaWJyYXRpbmcgY2xvY2socykgLi4u IGk4MjU0IGNsb2NrOiAxMTkzMjE4IEh6DQpDTEtfVVNFX0k4MjU0X0NBTElC UkFUSU9OIG5vdCBzcGVjaWZpZWQgLSB1c2luZyBkZWZhdWx0IGZyZXF1ZW5j eQ0KVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBx dWFsaXR5IDANCkNhbGlicmF0aW5nIFRTQyBjbG9jayAuLi4gVFNDIGNsb2Nr OiAyNjEyMDU4NjM4IEh6DQpDUFU6IEFNRCBBdGhsb24odG0pIDY0IFgyIER1 YWwgQ29yZSBQcm9jZXNzb3IgNTIwMCsgKDI2MTIuMDYtTUh6IDY4Ni1jbGFz cyBDUFUpDQogIE9yaWdpbiA9ICJBdXRoZW50aWNBTUQiICBJZCA9IDB4NDBm MzMgIFN0ZXBwaW5nID0gMw0KICBGZWF0dXJlcz0weDE3OGJmYmZmPEZQVSxW TUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQ R0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsTU1YLEZYU1IsU1NFLFNT RTIsSFRUPg0KICBGZWF0dXJlczI9MHgyMDAxPFNTRTMsQ1gxNj4NCiAgQU1E IEZlYXR1cmVzPTB4ZWE1MDA4MDA8U1lTQ0FMTCxOWCxNTVgrLEZGWFNSLFJE VFNDUCxMTSwzRE5vdyErLDNETm93IT4NCiAgQU1EIEZlYXR1cmVzMj0weDFm PExBSEYsQ01QLFNWTSxFeHRBUElDLENSOD4NCiAgQ29yZXMgcGVyIHBhY2th Z2U6IDINCkRhdGEgVExCOiAzMiBlbnRyaWVzLCBmdWxseSBhc3NvY2lhdGl2 ZQ0KSW5zdHJ1Y3Rpb24gVExCOiAzMiBlbnRyaWVzLCBmdWxseSBhc3NvY2lh dGl2ZQ0KTDEgZGF0YSBjYWNoZTogNjQga2J5dGVzLCA2NCBieXRlcy9saW5l LCAxIGxpbmVzL3RhZywgMi13YXkgYXNzb2NpYXRpdmUNCkwxIGluc3RydWN0 aW9uIGNhY2hlOiA2NCBrYnl0ZXMsIDY0IGJ5dGVzL2xpbmUsIDEgbGluZXMv dGFnLCAyLXdheSBhc3NvY2lhdGl2ZQ0KTDIgaW50ZXJuYWwgY2FjaGU6IDEw MjQga2J5dGVzLCA2NCBieXRlcy9saW5lLCAxIGxpbmVzL3RhZywgOC13YXkg YXNzb2NpYXRpdmUNCnJlYWwgbWVtb3J5ICA9IDEwNzIzNjU1NjggKDEwMjIg TUIpDQpQaHlzaWNhbCBtZW1vcnkgY2h1bmsocyk6DQoweDAwMDAwMDAwMDAw MDEwMDAgLSAweDAwMDAwMDAwMDAwOWJmZmYsIDYzNDg4MCBieXRlcyAoMTU1 IHBhZ2VzKQ0KMHgwMDAwMDAwMDAwMTAwMDAwIC0gMHgwMDAwMDAwMDAwM2Zm ZmZmLCAzMTQ1NzI4IGJ5dGVzICg3NjggcGFnZXMpDQoweDAwMDAwMDAwMDE0 MjgwMDAgLSAweDAwMDAwMDAwM2VjNmRmZmYsIDEwMzIwODU1MDQgYnl0ZXMg KDI1MTk3NCBwYWdlcykNCmF2YWlsIG1lbW9yeSA9IDEwMzE1NDA3MzYgKDk4 MyBNQikNCklOVFI6IEFkZGluZyBsb2NhbCBBUElDIDEgYXMgYSB0YXJnZXQN CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6 IDIgQ1BVcw0KIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwDQogY3B1MSAoQVAp OiBBUElDIElEOiAgMQ0KYmlvczMyOiBGb3VuZCBCSU9TMzIgU2VydmljZSBE aXJlY3RvcnkgaGVhZGVyIGF0IDB4YzAwZmJhNjANCmJpb3MzMjogRW50cnkg PSAweGYyMGMwIChjMDBmMjBjMCkgIFJldiA9IDAgIExlbiA9IDENCnBjaWJp b3M6IFBDSSBCSU9TIGVudHJ5IGF0IDB4ZjAwMDArMHgyMGYwDQpwbnBiaW9z OiBGb3VuZCBQblAgQklPUyBkYXRhIGF0IDB4YzAwZmM1YzANCnBucGJpb3M6 IEVudHJ5ID0gZjAwMDA6YzVmMCAgUmV2ID0gMS4wDQpPdGhlciBCSU9TIHNp Z25hdHVyZXMgZm91bmQ6DQpBUElDOiBDUFUgMCBoYXMgQUNQSSBJRCAwDQpB UElDOiBDUFUgMSBoYXMgQUNQSSBJRCAxDQpBQ1BJOiBSU0RQIEAgMHgweGY3 ZTQwLzB4MDAyNCAodiAgMiBOdmlkaWEpDQpBQ1BJOiBYU0RUIEAgMHgweDNm ZWUzMTAwLzB4MDA1NCAodiAgMSBOdmlkaWEgQVNVU0FDUEkgMHg0MjMwMkUz MSBBV1JEIDB4MDAwMDAwMDApDQpBQ1BJOiBGQUNQIEAgMHgweDNmZWVjYzgw LzB4MDBGNCAodiAgMyBOdmlkaWEgQVNVU0FDUEkgMHg0MjMwMkUzMSBBV1JE IDB4MDAwMDAwMDApDQpBQ1BJOiBEU0RUIEAgMHgweDNmZWUzMjgwLzB4OTlB RiAodiAgMSBOVklESUEgQVdSREFDUEkgMHgwMDAwMTAwMCBNU0ZUIDB4MDMw MDAwMDApDQpBQ1BJOiBGQUNTIEAgMHgweDNmZWIwMDAwLzB4MDA0MA0KQUNQ STogVENQQSBAIDB4MHgzZmVlY2U4MC8weDAwMzIgKHYgIDEgICAgSFRDICBI VENBQ1BJIDB4NDIzMDJFMzEgQVdSRCAweDAwMDAwMDAwKQ0KQUNQSTogU1NE VCBAIDB4MHgzZmVlY2YwMC8weDAyOEEgKHYgIDEgUFRMVEQgIFBPV0VSTk9X IDB4MDAwMDAwMDEgIExUUCAweDAwMDAwMDAxKQ0KQUNQSTogSFBFVCBAIDB4 MHgzZmVlZDIwMC8weDAwMzggKHYgIDEgTnZpZGlhIEFTVVNBQ1BJIDB4NDIz MDJFMzEgQVdSRCAweDAwMDAwMDk4KQ0KQUNQSTogTUNGRyBAIDB4MHgzZmVl ZDI4MC8weDAwM0MgKHYgIDEgTnZpZGlhIEFTVVNBQ1BJIDB4NDIzMDJFMzEg QVdSRCAweDAwMDAwMDAwKQ0KQUNQSTogQVBJQyBAIDB4MHgzZmVlY2RjMC8w eDAwN0MgKHYgIDEgTnZpZGlhIEFTVVNBQ1BJIDB4NDIzMDJFMzEgQVdSRCAw eDAwMDAwMDAwKQ0KTUFEVDogRm91bmQgSU8gQVBJQyBJRCAyLCBJbnRlcnJ1 cHQgMCBhdCAweGZlYzAwMDAwDQppb2FwaWMwOiBDaGFuZ2luZyBBUElDIElE IHRvIDINCmlvYXBpYzA6IFJvdXRpbmcgZXh0ZXJuYWwgODI1OUEncyAtPiBp bnRwaW4gMA0KTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2UgMCwg aXJxIDINCmlvYXBpYzA6IFJvdXRpbmcgSVJRIDAgLT4gaW50cGluIDINCk1B RFQ6IEludGVycnVwdCBvdmVycmlkZTogc291cmNlIDksIGlycSA5DQppb2Fw aWMwOiBpbnRwaW4gOSB0cmlnZ2VyOiBsZXZlbA0KTUFEVDogSW50ZXJydXB0 IG92ZXJyaWRlOiBzb3VyY2UgMTQsIGlycSAxNA0KTUFEVDogSW50ZXJydXB0 IG92ZXJyaWRlOiBzb3VyY2UgMTUsIGlycSAxNQ0KbGFwaWMwOiBSb3V0aW5n IE5NSSAtPiBMSU5UMQ0KbGFwaWMwOiBMSU5UMSB0cmlnZ2VyOiBlZGdlDQps YXBpYzA6IExJTlQxIHBvbGFyaXR5OiBoaWdoDQpsYXBpYzE6IFJvdXRpbmcg Tk1JIC0+IExJTlQxDQpsYXBpYzE6IExJTlQxIHRyaWdnZXI6IGVkZ2UNCmxh cGljMTogTElOVDEgcG9sYXJpdHk6IGhpZ2gNCmlvYXBpYzAgPFZlcnNpb24g MS4xPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQNCmNwdTAgQlNQOg0KICAg ICBJRDogMHgwMDAwMDAwMCAgIFZFUjogMHg4MDA1MDAxMCBMRFI6IDB4MDAw MDAwMDAgREZSOiAweGZmZmZmZmZmDQogIGxpbnQwOiAweDAwMDEwNzAwIGxp bnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAx ZmYNCiAgdGltZXI6IDB4MDAwMTAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJy OiAweDAwMDEwMDAwIHBjbTogMHgwMDAxMDAwMA0Kc25kX3VuaXRfaW5pdCgp IHU9MHgwMGZmODAwMCBbNTEyXSBkPTB4MDAwMDdjMDAgWzMyXSBjPTB4MDAw MDAzZmYgWzEwMjRdDQpmZWVkZXJfcmVnaXN0ZXI6IHNuZF91bml0PS0xIHNu ZF9tYXhhdXRvdmNoYW5zPTE2IGxhdGVuY3k9NSBmZWVkZXJfYnVmZmVyc2l6 ZT0xNjM4NCBmZWVkZXJfcmF0ZV9taW49MSBmZWVkZXJfcmF0ZV9tYXg9MjAx NjAwMCBmZWVkZXJfcmF0ZV9yb3VuZD0yNQ0KYXRoX3JhdGU6IHZlcnNpb24g MS4yIDxTYW1wbGVSYXRlIGJpdC1yYXRlIHNlbGVjdGlvbiBhbGdvcml0aG0+ DQp3bGFuX2FtcnI6IDxBTVJSIFRyYW5zbWl0IFJhdGUgQ29udHJvbCBBbGdv cml0aG0+DQp3bGFuOiA8ODAyLjExIExpbmsgTGF5ZXI+DQpuZnNsb2NrOiBw c2V1ZG8tZGV2aWNlDQprYmQ6IG5ldyBhcnJheSBzaXplIDQNCmtiZDEgYXQg a2JkbXV4MA0KbWVtOiA8bWVtb3J5Pg0KUGVudGl1bSBQcm8gTVRSUiBzdXBw b3J0IGVuYWJsZWQNCmlvOiA8SS9PPg0KbnVsbDogPG51bGwgZGV2aWNlLCB6 ZXJvIGRldmljZT4NClZFU0E6IGluZm9ybWF0aW9uIGJsb2NrDQo1NiA0NSA1 MyA0MSAwMiAwMSA2ZCAyNyAwMCBjMCAwMCAwMCAwMCAwMCAxNCAwMCANCjAw IDAxIDEwIDAwIDAzIDAxIDA0IDAxIDAwIDAxIDAxIDAxIDA1IDAxIDExIDAx IA0KMTQgMDEgMTAgMDEgMTMgMDEgMDIgMDEgMDYgMDEgMTIgMDEgN2MgMDAg ZmYgZmYgDQowMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCANClZFU0E6IDEzIG1vZGUocykgZm91bmQNClZFU0E6IHYx LjIsIDEwMjRrIG1lbW9yeSwgZmxhZ3M6MHgwLCBtb2RlIHRhYmxlOjB4YzBj ODE2MTQgKDEwMDAwMTQpDQpWRVNBOiBDaXJydXMgTG9naWMgR0QtNTQzNi80 NiBWR0ENCnJhbmRvbTogPGVudHJvcHkgc291cmNlLCBTb2Z0d2FyZSwgWWFy cm93Pg0KYXRoX2hhbDogMC45LjIwLjMgKEFSNTIxMCwgQVI1MjExLCBBUjUy MTIsIFJGNTExMSwgUkY1MTEyLCBSRjI0MTMsIFJGNTQxMykNCnJyMjMyeDog Um9ja2V0UkFJRCAyMzJ4IGNvbnRyb2xsZXIgZHJpdmVyIHYxLjAyIChBdWcg MTggMjAwNyAxNTozMTo1NykNCm5weDA6IElOVCAxNiBpbnRlcmZhY2UNCmFj cGkwOiA8TnZpZGlhIEFTVVNBQ1BJPiBvbiBtb3RoZXJib2FyZA0KaW9hcGlj MDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElSUSA5KSB0byB2ZWN0b3IgNDgN CmFjcGkwOiBbTVBTQUZFXQ0KYWNwaTA6IFtJVEhSRUFEXQ0KYWNwaV9ocGV0 MDogPEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBpb21lbSAweGZlZmZm MDAwLTB4ZmVmZmYzZmYgb24gYWNwaTANCmFjcGlfaHBldDA6IHZlbmQ6IDB4 MTBkZSByZXY6IDB4MSBudW06IDcgaHo6IDI1MDAwMDAwIG9wdHM6IGxlZ19y b3V0ZQ0KVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5jeSAyNTAwMDAwMCBI eiBxdWFsaXR5IDkwMA0KcGNpX29wZW4oMSk6CW1vZGUgMSBhZGRyIHBvcnQg KDB4MGNmOCkgaXMgMHg4MDAwNjAwNA0KcGNpX29wZW4oMWEpOgltb2RlMXJl cz0weDgwMDAwMDAwICgweDgwMDAwMDAwKQ0KcGNpX2NmZ2NoZWNrOglkZXZp Y2UgMCBbY2xhc3M9MDUwMDAwXSBbaGRyPTgwXSBpcyB0aGVyZSAoaWQ9MDJm NDEwZGUpDQpwY2liaW9zOiBCSU9TIHZlcnNpb24gMy4wMA0KQWNwaU9zRGVy aXZlUGNpSWQ6IFxcX1NCXy5QQ0kwLlNNQjAuU01DQSAtPiBidXMgMCBkZXYg OSBmdW5jIDENCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQ0KYWNwaTA6 IHdha2V1cCBjb2RlIHZhIDB4ZDhiZDcwMDAgcGEgMHgxMDAwDQpBY3BpT3NE ZXJpdmVQY2lJZDogXFxfU0JfLlBDSTAuSzgwMS5LMTgxIC0+IGJ1cyAwIGRl diAyNCBmdW5jIDENCkFjcGlPc0Rlcml2ZVBjaUlkOiBcXF9TQl8uUENJMC5M RUcwLlBJTzEgLT4gYnVzIDAgZGV2IDkgZnVuYyAwDQpBY3BpT3NEZXJpdmVQ Y2lJZDogXFxfU0JfLlBDSTAuTEVHMC5QSVJRIC0+IGJ1cyAwIGRldiA5IGZ1 bmMgMA0KYWNwaTA6IHJlc2VydmF0aW9uIG9mIGZlZmZmMDAwLCAxMDAwICgz KSBmYWlsZWQNCmFjcGkwOiByZXNlcnZhdGlvbiBvZiAwLCBhMDAwMCAoMykg ZmFpbGVkDQphY3BpMDogcmVzZXJ2YXRpb24gb2YgMTAwMDAwLCAzZmRiMDAw MCAoMykgZmFpbGVkDQpBQ1BJIHRpbWVyOiAxLzEgMS8xIDEvMSAxLzEgMS8x IDEvMSAxLzEgMS8xIDEvMSAxLzEgLT4gMTANClRpbWVjb3VudGVyICJBQ1BJ LWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMA0KYWNw aV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQg MHgxMDA4LTB4MTAwYiBvbiBhY3BpMA0KcGNpX2xpbmswOiAgICAgICAgSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAg ICAwICAgIDUgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQ0KICBWYWxp ZGF0aW9uICAgICAgICAgIDAgICAgNSAgIE4gICAgIDAgIDUgNyA5IDEwIDEx IDE0IDE1DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAg MCAgNSA3IDkgMTAgMTEgMTQgMTUNCnBjaV9saW5rMTogICAgICAgIEluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUNCiAgVmFsaWRh dGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMCAxMSAx NCAxNQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDUgNyA5IDEwIDExIDE0IDE1DQpwY2lfbGluazI6ICAgICAgICBJbmRleCAg SVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1DQogIFZhbGlkYXRp b24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQg MTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICA1 IDcgOSAxMCAxMSAxNCAxNQ0KcGNpX2xpbmszOiAgICAgICAgSW5kZXggIElS USAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAg MTEgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQ0KICBWYWxpZGF0aW9u ICAgICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1 DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3 IDkgMTAgMTEgMTQgMTUNCnBjaV9saW5rNDogICAgICAgIEluZGV4ICBJUlEg IFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDEw ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUNCiAgVmFsaWRhdGlvbiAg ICAgICAgICAwICAgMTAgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQ0K ICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5 IDEwIDExIDE0IDE1DQpwY2lfbGluazU6ICAgICAgICBJbmRleCAgSVJRICBS dGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1DQogIFZhbGlkYXRpb24gICAg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUNCiAg QWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAx MCAxMSAxNCAxNQ0KcGNpX2xpbms2OiAgICAgICAgSW5kZXggIElSUSAgUnRk ICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBO ICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAg ICAgIDAgICAxMSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1DQogIEFm dGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAg MTEgMTQgMTUNCnBjaV9saW5rNzogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUNCiAgVmFsaWRhdGlvbiAgICAgICAg ICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQ0KICBBZnRl ciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDEx IDE0IDE1DQpwY2lfbGluazg6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJl ZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAg IDAgIDUgNyA5IDEwIDExIDE0IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUNCiAgQWZ0ZXIg RGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMCAxMSAx NCAxNQ0KcGNpX2xpbms5OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYg IElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgIDcgICBOICAgICAw ICA1IDcgOSAxMCAxMSAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAgICAgIDAg ICAgNyAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1DQogIEFmdGVyIERp c2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQg MTUNCnBjaV9saW5rMTA6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJ UlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgICA1ICAgTiAgICAgMCAg NSA3IDkgMTAgMTEgMTQgMTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAg IDUgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQ0KICBBZnRlciBEaXNh YmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1 DQpwY2lfbGluazExOiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJR cw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMCAgIE4gICAgIDAgIDUg NyA5IDEwIDExIDE0IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDEw ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJs ZSAgICAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQ0K cGNpX2xpbmsxMjogICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMN CiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAgICAwICA1IDcg OSAxMCAxMSAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMSAg IE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1DQogIEFmdGVyIERpc2FibGUg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUNCnBj aV9saW5rMTM6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQog IEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkg MTAgMTEgMTQgMTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBO ICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1DQpwY2lf bGluazE0OiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJ bml0aWFsIFByb2JlICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDUgNyA5IDEw IDExIDE0IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDExICAgTiAg ICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAg ICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQ0KcGNpX2xp bmsxNTogICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5p dGlhbCBQcm9iZSAgICAgICAwICAgMTAgICBOICAgICAwICA1IDcgOSAxMCAx MSAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAxMCAgIE4gICAg IDAgIDUgNyA5IDEwIDExIDE0IDE1DQogIEFmdGVyIERpc2FibGUgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUNCnBjaV9saW5r MTY6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRp YWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEg MTQgMTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAw ICA1IDcgOSAxMCAxMSAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1DQpwY2lfbGluazE3 OiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFs IFByb2JlICAgICAgIDAgICAgNSAgIE4gICAgIDAgIDUgNyA5IDEwIDExIDE0 IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgICA1ICAgTiAgICAgMCAg NSA3IDkgMTAgMTEgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAy NTUgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAxNQ0KcGNpX2xpbmsxODog ICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQ cm9iZSAgICAgICAwICAgIDUgICBOICAgICAwICA1IDcgOSAxMCAxMSAxNCAx NQ0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAgNSAgIE4gICAgIDAgIDUg NyA5IDEwIDExIDE0IDE1DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUNCnBjaV9saW5rMTk6ICAg ICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJv YmUgICAgICAgMCAgICA1ICAgTiAgICAgMCAgNSA3IDkgMTAgMTEgMTQgMTUN CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgIDUgICBOICAgICAwICA1IDcg OSAxMCAxMSAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDUgNyA5IDEwIDExIDE0IDE1DQpwY2lfbGluazIwOiAgICAg ICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2Jl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2DQogIFZhbGlkYXRpb24gICAg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYNCiAgQWZ0ZXIgRGlzYWJsZSAg ICAgICAwICAyNTUgICBOICAgICAwICAxNg0KcGNpX2xpbmsyMTogICAgICAg SW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAg ICAgICAwICAyNTUgICBOICAgICAwICAxNw0KICBWYWxpZGF0aW9uICAgICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDE3DQogIEFmdGVyIERpc2FibGUgICAg ICAgMCAgMjU1ICAgTiAgICAgMCAgMTcNCnBjaV9saW5rMjI6ICAgICAgIElu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAg ICAgMCAgMjU1ICAgTiAgICAgMCAgMTgNCiAgVmFsaWRhdGlvbiAgICAgICAg ICAwICAyNTUgICBOICAgICAwICAxOA0KICBBZnRlciBEaXNhYmxlICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDE4DQpwY2lfbGluazIzOiAgICAgICBJbmRl eCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDE5DQogIFZhbGlkYXRpb24gICAgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgMTkNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAw ICAyNTUgICBOICAgICAwICAxOQ0KcGNpX2xpbmsyNDogICAgICAgSW5kZXgg IElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAw ICAyNTUgICBOICAgICAwICAxNg0KICBWYWxpZGF0aW9uICAgICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDE2DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAg MjU1ICAgTiAgICAgMCAgMTYNCnBjaV9saW5rMjU6ICAgICAgIEluZGV4ICBJ UlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAg MjU1ICAgTiAgICAgMCAgMTYNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAy NTUgICBOICAgICAwICAxNg0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDE2DQpwY2lfbGluazI2OiAgICAgICBJbmRleCAgSVJR ICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDE2DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMTYNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUg ICBOICAgICAwICAxNg0KcGNpX2xpbmsyNzogICAgICAgSW5kZXggIElSUSAg UnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUg ICBOICAgICAwICAxNg0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDE2DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMTYNCnBjaV9saW5rMjg6ICAgICAgIEluZGV4ICBJUlEgIFJ0 ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMjAgMjEgMjIgMjMNCiAgVmFsaWRhdGlvbiAgICAgICAgICAw ICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMw0KICBBZnRlciBEaXNhYmxl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIzDQpwY2lfbGlu azI5OiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0 aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIz DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjAg MjEgMjIgMjMNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAg ICAwICAyMCAyMSAyMiAyMw0KcGNpX2xpbmszMDogICAgICAgSW5kZXggIElS USAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAy NTUgICBOICAgICAwICAyMCAyMSAyMiAyMw0KICBWYWxpZGF0aW9uICAgICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIzDQogIEFmdGVyIERp c2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMNCnBj aV9saW5rMzE6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQog IEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEg MjIgMjMNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAw ICAyMCAyMSAyMiAyMw0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDIwIDIxIDIyIDIzDQpwY2lfbGluazMyOiAgICAgICBJbmRl eCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIzDQogIFZhbGlkYXRpb24g ICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMNCiAgQWZ0 ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAy Mw0KcGNpX2xpbmszMzogICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElS UXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAy MCAyMSAyMiAyMw0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDIwIDIxIDIyIDIzDQogIEFmdGVyIERpc2FibGUgICAgICAgMCAg MjU1ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMNCnBjaV9saW5rMzQ6ICAgICAg IEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMNCiAgVmFsaWRh dGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMw0K ICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIx IDIyIDIzDQpwY2lfbGluazM1OiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJl ZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAg IDAgIDIwIDIxIDIyIDIzDQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMNCiAgQWZ0ZXIgRGlzYWJsZSAgICAg ICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMw0KcGNpX2xpbmszNjog ICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQ cm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMw0KICBW YWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIy IDIzDQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAg MjAgMjEgMjIgMjMNCnBjaV9saW5rMzc6ICAgICAgIEluZGV4ICBJUlEgIFJ0 ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMjAgMjEgMjIgMjMNCiAgVmFsaWRhdGlvbiAgICAgICAgICAw ICAyNTUgICBOICAgICAwICAyMCAyMSAyMiAyMw0KICBBZnRlciBEaXNhYmxl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIzDQpwY2lfbGlu azM4OiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJbml0 aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIz DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjAg MjEgMjIgMjMNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAg ICAwICAyMCAyMSAyMiAyMw0KcGNpX2xpbmszOTogICAgICAgSW5kZXggIElS USAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAy NTUgICBOICAgICAwICAyMCAyMSAyMiAyMw0KICBWYWxpZGF0aW9uICAgICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwIDIxIDIyIDIzDQogIEFmdGVyIERp c2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjAgMjEgMjIgMjMNCmNw dTA6IDxBQ1BJIENQVT4gb24gYWNwaTANCmNwdTA6IHN3aXRjaGluZyB0byBn ZW5lcmljIEN4IG1vZGUNCnBvd2Vybm93MDogPFBvd2VyTm93ISBLOD4gb24g Y3B1MA0KY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KcG93ZXJub3cxOiA8 UG93ZXJOb3chIEs4PiBvbiBjcHUxDQphY3BpX2J1dHRvbjA6IDxQb3dlciBC dXR0b24+IG9uIGFjcGkwDQpwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdl PiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwDQpwY2kwOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMA0KcGNpMDogcGh5c2ljYWwgYnVzPTANCmZvdW5kLT4J dmVuZG9yPTB4MTBkZSwgZGV2PTB4MDJmNCwgcmV2aWQ9MHhhMg0KCWJ1cz0w LCBzbG90PTAsIGZ1bmM9MA0KCWNsYXNzPTA1LTAwLTAwLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTENCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDBiMCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwg bWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCmZvdW5k LT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDJmYSwgcmV2aWQ9MHhhMg0KCWJ1 cz0wLCBzbG90PTAsIGZ1bmM9MQ0KCWNsYXNzPTA1LTAwLTAwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTENCgljbWRyZWc9MHgwMTAwLCBzdGF0cmVnPTB4NDAy MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCmZv dW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDJmZSwgcmV2aWQ9MHhhMg0K CWJ1cz0wLCBzbG90PTAsIGZ1bmM9Mg0KCWNsYXNzPTA1LTAwLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTENCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4 MDAyMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykN CmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDJmOCwgcmV2aWQ9MHhh Mg0KCWJ1cz0wLCBzbG90PTAsIGZ1bmM9Mw0KCWNsYXNzPTA1LTAwLTAwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTENCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVn PTB4MDBhMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAw ICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykNCmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDJmOSwgcmV2aWQ9 MHhhMg0KCWJ1cz0wLCBzbG90PTAsIGZ1bmM9NA0KCWNsYXNzPTA1LTAwLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA2LCBzdGF0 cmVnPTB4MDBhMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0w eDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykNCmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDJmZiwgcmV2 aWQ9MHhhMg0KCWJ1cz0wLCBzbG90PTAsIGZ1bmM9NQ0KCWNsYXNzPTA1LTAw LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTENCgljbWRyZWc9MHgwMDA2LCBz dGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykNCmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDI3Ziwg cmV2aWQ9MHhhMg0KCWJ1cz0wLCBzbG90PTAsIGZ1bmM9Ng0KCWNsYXNzPTA1 LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTENCgljbWRyZWc9MHgwMTAy LCBzdGF0cmVnPTB4MDAyMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0 aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykNCmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDI3 ZSwgcmV2aWQ9MHhhMg0KCWJ1cz0wLCBzbG90PTAsIGZ1bmM9Nw0KCWNsYXNz PTA1LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTENCgljbWRyZWc9MHgw MDAwLCBzdGF0cmVnPTB4MDAyMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykNCmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4 MDJmYiwgcmV2aWQ9MHhhMQ0KCWJ1cz0wLCBzbG90PTQsIGZ1bmM9MA0KCWNs YXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTANCgljbWRyZWc9 MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTggKGR3b3JkcykN CglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDQgKDEwMDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykNCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMg RDAgRDMgIGN1cnJlbnQgRDANCglNU0kgc3VwcG9ydHMgMiBtZXNzYWdlcywg NjQgYml0DQpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAzNjksIHJl dmlkPTB4YTENCglidXM9MCwgc2xvdD04LCBmdW5jPTANCgljbGFzcz0wNS0w MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wDQoJY21kcmVnPTB4MDAwNiwg c3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChkd29yZHMpDQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4 MDAgKDAgbnMpDQpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAzNjAs IHJldmlkPTB4YTINCglidXM9MCwgc2xvdD05LCBmdW5jPTANCgljbGFzcz0w Ni0wMS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xDQoJY21kcmVnPTB4MDAw Ziwgc3RhdHJlZz0weDAwYTAsIGNhY2hlbG5zej0wIChkd29yZHMpDQoJbGF0 dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpDQpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAz NjgsIHJldmlkPTB4YTINCglidXM9MCwgc2xvdD05LCBmdW5jPTENCgljbGFz cz0wYy0wNS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xDQoJY21kcmVnPTB4 MDAwMSwgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChkd29yZHMpDQoJ bGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWEsIGlycT0xMQ0KCXBvd2Vyc3Bl YyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KCW1hcFsyMF06IHR5 cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MWMwMCwgc2l6ZSAgNiwg ZW5hYmxlZA0KCW1hcFsyNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBi YXNlIDB4MWM0MCwgc2l6ZSAgNiwgZW5hYmxlZA0KcGNpYjA6IG1hdGNoZWQg ZW50cnkgZm9yIDAuOS5JTlRBIChzcmMgXFxfU0JfLlBDSTAuQVBDUzowKQ0K cGNpX2xpbmszMzogUGlja2VkIElSUSAyMCB3aXRoIHdlaWdodCAwDQpwY2li MDogc2xvdCA5IElOVEEgcm91dGVkIHRvIGlycSAyMCB2aWEgXFxfU0JfLlBD STAuQVBDUw0KZm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMzZhLCBy ZXZpZD0weGEyDQoJYnVzPTAsIHNsb3Q9OSwgZnVuYz0yDQoJY2xhc3M9MDUt MDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQ0KCWNtZHJlZz0weDA0MDAs IHN0YXRyZWc9MHgwMGEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQ0KCWxhdHRp bWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQ0KZm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMzZj LCByZXZpZD0weGExDQoJYnVzPTAsIHNsb3Q9MTAsIGZ1bmM9MA0KCWNsYXNz PTBjLTAzLTEwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgw MDA3LCBzdGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyksIG1h eGxhdD0weDAxICgyNTAgbnMpDQoJaW50cGluPWEsIGlycT03DQoJcG93ZXJz cGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwDQoJbWFw WzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmUwMmYwMDAs IHNpemUgMTIsIGVuYWJsZWQNCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAw LjEwLklOVEEgKHNyYyBcXF9TQl8uUENJMC5BUENGOjApDQpwY2lfbGluazI4 OiBQaWNrZWQgSVJRIDIxIHdpdGggd2VpZ2h0IDANCnBjaWIwOiBzbG90IDEw IElOVEEgcm91dGVkIHRvIGlycSAyMSB2aWEgXFxfU0JfLlBDSTAuQVBDRg0K Zm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMzZlLCByZXZpZD0weGEx DQoJYnVzPTAsIHNsb3Q9MTIsIGZ1bmM9MA0KCWNsYXNzPTAxLTAxLThhLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVn PTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAw ICgwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAxICgy NTAgbnMpDQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50 IEQwDQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2Ug MHhmNDAwLCBzaXplICA0LCBlbmFibGVkDQpmb3VuZC0+CXZlbmRvcj0weDEw ZGUsIGRldj0weDAzN2YsIHJldmlkPTB4YTINCglidXM9MCwgc2xvdD0xMywg ZnVuYz0wDQoJY2xhc3M9MDEtMDEtODUsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MQ0KCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgw MyAoNzUwIG5zKSwgbWF4bGF0PTB4MDEgKDI1MCBucykNCglpbnRwaW49YSwg aXJxPTUNCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQg RDANCglNU0kgc3VwcG9ydHMgNCBtZXNzYWdlcywgNjQgYml0DQoJbWFwWzEw XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg5ZjAsIHNpemUg IDMsIGVuYWJsZWQNCgltYXBbMTRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAz MiwgYmFzZSAweGJmMCwgc2l6ZSAgMiwgZW5hYmxlZA0KCW1hcFsxOF06IHR5 cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4OTcwLCBzaXplICAzLCBl bmFibGVkDQoJbWFwWzFjXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJh c2UgMHhiNzAsIHNpemUgIDIsIGVuYWJsZWQNCgltYXBbMjBdOiB0eXBlIEkv TyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGUwMDAsIHNpemUgIDQsIGVuYWJs ZWQNCgltYXBbMjRdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhm ZTAyZDAwMCwgc2l6ZSAxMiwgZW5hYmxlZA0KcGNpYjA6IG1hdGNoZWQgZW50 cnkgZm9yIDAuMTMuSU5UQSAoc3JjIFxcX1NCXy5QQ0kwLkFQU0k6MCkNCnBj aV9saW5rMzc6IFBpY2tlZCBJUlEgMjIgd2l0aCB3ZWlnaHQgMA0KcGNpYjA6 IHNsb3QgMTMgSU5UQSByb3V0ZWQgdG8gaXJxIDIyIHZpYSBcXF9TQl8uUENJ MC5BUFNJDQpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAzN2YsIHJl dmlkPTB4YTINCglidXM9MCwgc2xvdD0xMywgZnVuYz0xDQoJY2xhc3M9MDEt MDEtODUsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQ0KCWNtZHJlZz0weDAwMDcs IHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQ0KCWxhdHRp bWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMyAoNzUwIG5zKSwgbWF4bGF0 PTB4MDEgKDI1MCBucykNCglpbnRwaW49YiwgaXJxPTUNCglwb3dlcnNwZWMg MiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCglNU0kgc3VwcG9ydHMg NCBtZXNzYWdlcywgNjQgYml0DQoJbWFwWzEwXTogdHlwZSBJL08gUG9ydCwg cmFuZ2UgMzIsIGJhc2UgMHg5ZTAsIHNpemUgIDMsIGVuYWJsZWQNCgltYXBb MTRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGJlMCwgc2l6 ZSAgMiwgZW5hYmxlZA0KCW1hcFsxOF06IHR5cGUgSS9PIFBvcnQsIHJhbmdl IDMyLCBiYXNlIDB4OTYwLCBzaXplICAzLCBlbmFibGVkDQoJbWFwWzFjXTog dHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhiNjAsIHNpemUgIDIs IGVuYWJsZWQNCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwg YmFzZSAweGNjMDAsIHNpemUgIDQsIGVuYWJsZWQNCgltYXBbMjRdOiB0eXBl IE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmZTAyYzAwMCwgc2l6ZSAxMiwg ZW5hYmxlZA0KcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMTMuSU5UQiAo c3JjIFxcX1NCXy5QQ0kwLkFQU0o6MCkNCnBjaV9saW5rMzg6IFBpY2tlZCBJ UlEgMjMgd2l0aCB3ZWlnaHQgMA0KcGNpYjA6IHNsb3QgMTMgSU5UQiByb3V0 ZWQgdG8gaXJxIDIzIHZpYSBcXF9TQl8uUENJMC5BUFNKDQpmb3VuZC0+CXZl bmRvcj0weDEwZGUsIGRldj0weDAzN2YsIHJldmlkPTB4YTINCglidXM9MCwg c2xvdD0xMywgZnVuYz0yDQoJY2xhc3M9MDEtMDEtODUsIGhkcnR5cGU9MHgw MCwgbWZkZXY9MQ0KCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMGIwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBt aW5nbnQ9MHgwMyAoNzUwIG5zKSwgbWF4bGF0PTB4MDEgKDI1MCBucykNCglp bnRwaW49YywgaXJxPTUNCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMg IGN1cnJlbnQgRDANCglNU0kgc3VwcG9ydHMgNCBtZXNzYWdlcywgNjQgYml0 DQoJbWFwWzEwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhj ODAwLCBzaXplICAzLCBlbmFibGVkDQoJbWFwWzE0XTogdHlwZSBJL08gUG9y dCwgcmFuZ2UgMzIsIGJhc2UgMHhjNDAwLCBzaXplICAyLCBlbmFibGVkDQoJ bWFwWzE4XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhjMDAw LCBzaXplICAzLCBlbmFibGVkDQoJbWFwWzFjXTogdHlwZSBJL08gUG9ydCwg cmFuZ2UgMzIsIGJhc2UgMHhiYzAwLCBzaXplICAyLCBlbmFibGVkDQoJbWFw WzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhiODAwLCBz aXplICA0LCBlbmFibGVkDQoJbWFwWzI0XTogdHlwZSBNZW1vcnksIHJhbmdl IDMyLCBiYXNlIDB4ZmUwMmIwMDAsIHNpemUgMTIsIGVuYWJsZWQNCnBjaWIw OiBtYXRjaGVkIGVudHJ5IGZvciAwLjEzLklOVEMgKHNyYyBcXF9TQl8uUENJ MC5BU0EyOjApDQpwY2lfbGluazM5OiBQaWNrZWQgSVJRIDIwIHdpdGggd2Vp Z2h0IDENCnBjaWIwOiBzbG90IDEzIElOVEMgcm91dGVkIHRvIGlycSAyMCB2 aWEgXFxfU0JfLlBDSTAuQVNBMg0KZm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBk ZXY9MHgwMzcwLCByZXZpZD0weGEyDQoJYnVzPTAsIHNsb3Q9MTQsIGZ1bmM9 MA0KCWNsYXNzPTA2LTA0LTAxLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTENCglj bWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3 b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MGMgKDMw MDAgbnMpLCBtYXhsYXQ9MHgwYSAoMjUwMCBucykNCmZvdW5kLT4JdmVuZG9y PTB4MTBkZSwgZGV2PTB4MDM3MSwgcmV2aWQ9MHhhMg0KCWJ1cz0wLCBzbG90 PTE0LCBmdW5jPTENCgljbGFzcz0wNC0wMy0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0xDQoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAwYjAsIGNhY2hl bG5zej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdu dD0weDAyICg1MDAgbnMpLCBtYXhsYXQ9MHgwNSAoMTI1MCBucykNCglpbnRw aW49YiwgaXJxPTExDQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBj dXJyZW50IEQwDQoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0LCB2 ZWN0b3IgbWFza3MNCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIs IGJhc2UgMHhmZTAyMDAwMCwgc2l6ZSAxNCwgZW5hYmxlZA0KcGNpYjA6IG1h dGNoZWQgZW50cnkgZm9yIDAuMTQuSU5UQiAoc3JjIFxcX1NCXy5QQ0kwLkFB WkE6MCkNCnBjaV9saW5rMzI6IFBpY2tlZCBJUlEgMjEgd2l0aCB3ZWlnaHQg MQ0KcGNpYjA6IHNsb3QgMTQgSU5UQiByb3V0ZWQgdG8gaXJxIDIxIHZpYSBc XF9TQl8uUENJMC5BQVpBDQpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0w eDAzNzMsIHJldmlkPTB4YTINCglidXM9MCwgc2xvdD0xNiwgZnVuYz0wDQoJ Y2xhc3M9MDYtODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MA0KCWNtZHJl Zz0weDAwMDcsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRz KQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMSAoMjUwIG5z KSwgbWF4bGF0PTB4MTQgKDUwMDAgbnMpDQoJaW50cGluPWEsIGlycT01DQoJ cG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQw DQoJTVNJIHN1cHBvcnRzIDggbWVzc2FnZXMsIDY0IGJpdCwgdmVjdG9yIG1h c2tzDQoJTVNJLVggc3VwcG9ydHMgOCBtZXNzYWdlcyBpbiBtYXBzIDB4MTgg YW5kIDB4MWMNCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJh c2UgMHhmZTAyYTAwMCwgc2l6ZSAxMiwgZW5hYmxlZA0KCW1hcFsxNF06IHR5 cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4YjQwMCwgc2l6ZSAgMywg ZW5hYmxlZA0KCW1hcFsxOF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFz ZSAweGZlMDI5MDAwLCBzaXplICA4LCBlbmFibGVkDQoJbWFwWzFjXTogdHlw ZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmUwMjgwMDAsIHNpemUgIDQs IGVuYWJsZWQNCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjE2LklOVEEg KHNyYyBcXF9TQl8uUENJMC5BUENIOjApDQpwY2lfbGluazI5OiBQaWNrZWQg SVJRIDIyIHdpdGggd2VpZ2h0IDENCnBjaWIwOiBzbG90IDE2IElOVEEgcm91 dGVkIHRvIGlycSAyMiB2aWEgXFxfU0JfLlBDSTAuQVBDSA0KZm91bmQtPgl2 ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMzczLCByZXZpZD0weGEyDQoJYnVzPTAs IHNsb3Q9MTcsIGZ1bmM9MA0KCWNsYXNzPTA2LTgwLTAwLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDBiMCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwg bWluZ250PTB4MDEgKDI1MCBucyksIG1heGxhdD0weDE0ICg1MDAwIG5zKQ0K CWludHBpbj1hLCBpcnE9MTANCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAg RDEgRDIgRDMgIGN1cnJlbnQgRDANCglNU0kgc3VwcG9ydHMgOCBtZXNzYWdl cywgNjQgYml0LCB2ZWN0b3IgbWFza3MNCglNU0ktWCBzdXBwb3J0cyA4IG1l c3NhZ2VzIGluIG1hcHMgMHgxOCBhbmQgMHgxYw0KCW1hcFsxMF06IHR5cGUg TWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZlMDI3MDAwLCBzaXplIDEyLCBl bmFibGVkDQoJbWFwWzE0XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJh c2UgMHhiMDAwLCBzaXplICAzLCBlbmFibGVkDQoJbWFwWzE4XTogdHlwZSBN ZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmUwMjYwMDAsIHNpemUgIDgsIGVu YWJsZWQNCgltYXBbMWNdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2Ug MHhmZTAyNTAwMCwgc2l6ZSAgNCwgZW5hYmxlZA0KcGNpYjA6IG1hdGNoZWQg ZW50cnkgZm9yIDAuMTcuSU5UQSAoc3JjIFxcX1NCXy5QQ0kwLkFNQzE6MCkN CnBjaV9saW5rMzA6IFBpY2tlZCBJUlEgMjMgd2l0aCB3ZWlnaHQgMQ0KcGNp YjA6IHNsb3QgMTcgSU5UQSByb3V0ZWQgdG8gaXJxIDIzIHZpYSBcXF9TQl8u UENJMC5BTUMxDQpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAzNzYs IHJldmlkPTB4YTINCglidXM9MCwgc2xvdD0xOCwgZnVuYz0wDQoJY2xhc3M9 MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MA0KCWNtZHJlZz0weDAw MDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQ0KCWxh dHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1h eGxhdD0weDAwICgwIG5zKQ0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBE MyAgY3VycmVudCBEMA0KCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCA2NCBi aXQNCmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDM3NCwgcmV2aWQ9 MHhhMg0KCWJ1cz0wLCBzbG90PTIwLCBmdW5jPTANCgljbGFzcz0wNi0wNC0w MCwgaGRydHlwZT0weDAxLCBtZmRldj0wDQoJY21kcmVnPTB4MDAwMCwgc3Rh dHJlZz0weDAwMTAsIGNhY2hlbG5zej04IChkd29yZHMpDQoJbGF0dGltZXI9 MHgwMCAoMCBucyksIG1pbmdudD0weDA0ICgxMDAwIG5zKSwgbWF4bGF0PTB4 MDAgKDAgbnMpDQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJy ZW50IEQwDQoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIDY0IGJpdA0KZm91 bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMzc4LCByZXZpZD0weGEyDQoJ YnVzPTAsIHNsb3Q9MjEsIGZ1bmM9MA0KCWNsYXNzPTA2LTA0LTAwLCBoZHJ0 eXBlPTB4MDEsIG1mZGV2PTANCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4 MDAxMCwgY2FjaGVsbnN6PTggKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykNCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAN CglNU0kgc3VwcG9ydHMgMiBtZXNzYWdlcywgNjQgYml0DQpmb3VuZC0+CXZl bmRvcj0weDEwZGUsIGRldj0weDAzNzUsIHJldmlkPTB4YTINCglidXM9MCwg c2xvdD0yMiwgZnVuYz0wDQoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgw MSwgbWZkZXY9MA0KCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBj YWNoZWxuc3o9OCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBt aW5nbnQ9MHgwNCAoMTAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KCXBv d2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KCU1TSSBz dXBwb3J0cyAyIG1lc3NhZ2VzLCA2NCBiaXQNCmZvdW5kLT4JdmVuZG9yPTB4 MTBkZSwgZGV2PTB4MDM3NywgcmV2aWQ9MHhhMg0KCWJ1cz0wLCBzbG90PTIz LCBmdW5jPTANCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRl dj0wDQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5z ej04IChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0w eDA0ICgxMDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJcG93ZXJzcGVj IDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwDQoJTVNJIHN1cHBvcnRz IDIgbWVzc2FnZXMsIDY0IGJpdA0KZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBk ZXY9MHgxMTAwLCByZXZpZD0weDAwDQoJYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9 MA0KCWNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTENCglj bWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3 b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCmZvdW5kLT4JdmVuZG9yPTB4MTAy MiwgZGV2PTB4MTEwMSwgcmV2aWQ9MHgwMA0KCWJ1cz0wLCBzbG90PTI0LCBm dW5jPTENCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0x DQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0w IChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAw ICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQpmb3VuZC0+CXZlbmRvcj0w eDEwMjIsIGRldj0weDExMDIsIHJldmlkPTB4MDANCglidXM9MCwgc2xvdD0y NCwgZnVuYz0yDQoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MQ0KCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDAwLCBjYWNoZWxu c3o9MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KZm91bmQtPgl2ZW5k b3I9MHgxMDIyLCBkZXY9MHgxMTAzLCByZXZpZD0weDAwDQoJYnVzPTAsIHNs b3Q9MjQsIGZ1bmM9Mw0KCWNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTENCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2Fj aGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCnBjaTA6IDxt ZW1vcnksIFJBTT4gYXQgZGV2aWNlIDAuMCAobm8gZHJpdmVyIGF0dGFjaGVk KQ0KcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2UgMC4xIChubyBkcml2 ZXIgYXR0YWNoZWQpDQpwY2kwOiA8bWVtb3J5LCBSQU0+IGF0IGRldmljZSAw LjIgKG5vIGRyaXZlciBhdHRhY2hlZCkNCnBjaTA6IDxtZW1vcnksIFJBTT4g YXQgZGV2aWNlIDAuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KcGNpMDogPG1l bW9yeSwgUkFNPiBhdCBkZXZpY2UgMC40IChubyBkcml2ZXIgYXR0YWNoZWQp DQpwY2kwOiA8bWVtb3J5LCBSQU0+IGF0IGRldmljZSAwLjUgKG5vIGRyaXZl ciBhdHRhY2hlZCkNCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDAu NiAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KcGNpMDogPG1lbW9yeSwgUkFNPiBh dCBkZXZpY2UgMC43IChubyBkcml2ZXIgYXR0YWNoZWQpDQpwY2liMTogPEFD UEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA0LjAgb24gcGNpMA0KcGNp YjE6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMQ0KcGNpYjE6ICAgc3Vib3JkaW5h dGUgYnVzICAgMQ0KcGNpYjE6ICAgSS9PIGRlY29kZSAgICAgICAgMHgwLTB4 MA0KcGNpYjE6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUNCnBjaWIxOiBjb3Vs ZCBub3QgZ2V0IFBDSSBpbnRlcnJ1cHQgcm91dGluZyB0YWJsZSBmb3IgXFxf U0JfLlBDSTAuWFZSQSAtIEFFX05PVF9GT1VORA0KcGNpMTogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjENCnBjaTE6IHBoeXNpY2FsIGJ1cz0xDQpwY2kwOiA8 bWVtb3J5LCBSQU0+IGF0IGRldmljZSA4LjAgKG5vIGRyaXZlciBhdHRhY2hl ZCkNCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSA5LjAgb24g cGNpMA0KaXNhMDogPElTQSBidXM+IG9uIGlzYWIwDQpwY2kwOiA8c2VyaWFs IGJ1cywgU01CdXM+IGF0IGRldmljZSA5LjEgKG5vIGRyaXZlciBhdHRhY2hl ZCkNCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDkuMiAobm8gZHJp dmVyIGF0dGFjaGVkKQ0KcGNpMDogPHNlcmlhbCBidXMsIFVTQj4gYXQgZGV2 aWNlIDEwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkNCmF0YXBjaTA6IDxuVmlk aWEgbkZvcmNlIE1DUDU1IFVETUExMzMgY29udHJvbGxlcj4gcG9ydCAweDFm MC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweGY0MDAtMHhmNDBm IGF0IGRldmljZSAxMi4wIG9uIHBjaTANCmF0YXBjaTA6IFJlc2VydmVkIDB4 MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGY0MDANCmF0YTA6 IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwDQphdGFwY2kwOiBSZXNlcnZl ZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDFmMA0KYXRh cGNpMDogUmVzZXJ2ZWQgMHgxIGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQg YXQgMHgzZjYNCmF0YTA6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBv c3RhdDE9NTANCmF0YTA6IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNiPTB4MDAg bXNiPTB4MDANCmF0YTA6IHN0YXQxPTB4NTAgZXJyPTB4MDEgbHNiPTB4MDAg bXNiPTB4MDANCmF0YTA6IHJlc2V0IHRwMiBzdGF0MD01MCBzdGF0MT01MCBk ZXZpY2VzPTB4MzxBVEFfU0xBVkUsQVRBX01BU1RFUj4NCmlvYXBpYzA6IHJv dXRpbmcgaW50cGluIDE0IChJU0EgSVJRIDE0KSB0byB2ZWN0b3IgNDkNCmF0 YTA6IFtNUFNBRkVdDQphdGEwOiBbSVRIUkVBRF0NCmF0YTE6IDxBVEEgY2hh bm5lbCAxPiBvbiBhdGFwY2kwDQphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0 ZXMgZm9yIHJpZCAweDE4IHR5cGUgNCBhdCAweDE3MA0KYXRhcGNpMDogUmVz ZXJ2ZWQgMHgxIGJ5dGVzIGZvciByaWQgMHgxYyB0eXBlIDQgYXQgMHgzNzYN CmF0YTE6IHJlc2V0IHRwMSBtYXNrPTAwIG9zdGF0MD1mZiBvc3RhdDE9ZmYN CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE1IChJU0EgSVJRIDE1KSB0byB2 ZWN0b3IgNTANCmF0YTE6IFtNUFNBRkVdDQphdGExOiBbSVRIUkVBRF0NCmF0 YXBjaTE6IDxuVmlkaWEgbkZvcmNlIE1DUDU1IFNBVEEzMDAgY29udHJvbGxl cj4gcG9ydCAweDlmMC0weDlmNywweGJmMC0weGJmMywweDk3MC0weDk3Nyww eGI3MC0weGI3MywweGUwMDAtMHhlMDBmIG1lbSAweGZlMDJkMDAwLTB4ZmUw MmRmZmYgaXJxIDIyIGF0IGRldmljZSAxMy4wIG9uIHBjaTANCmF0YXBjaTE6 IFJlc2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAw eGUwMDANCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIyIChQQ0kgSVJRIDIy KSB0byB2ZWN0b3IgNTENCmF0YXBjaTE6IFtNUFNBRkVdDQphdGFwY2kxOiBb SVRIUkVBRF0NCmF0YXBjaTE6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3Ig cmlkIDB4MjQgdHlwZSAzIGF0IDB4ZmUwMmQwMDANCmF0YTI6IDxBVEEgY2hh bm5lbCAwPiBvbiBhdGFwY2kxDQphdGFwY2kxOiBSZXNlcnZlZCAweDggYnl0 ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDlmMA0KYXRhcGNpMTogUmVz ZXJ2ZWQgMHg0IGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQgYXQgMHhiZjAN CmF0YTI6IFNBVEEgY29ubmVjdCB0aW1lPTBtcw0KYXRhMjogcmVzZXQgdHAx IG1hc2s9MDEgb3N0YXQwPTUwIG9zdGF0MT0wMA0KYXRhMjogc3RhdDA9MHg1 MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMA0KYXRhMjogcmVzZXQgdHAy IHN0YXQwPTUwIHN0YXQxPTAwIGRldmljZXM9MHgxPEFUQV9NQVNURVI+DQph dGEyOiBbTVBTQUZFXQ0KYXRhMjogW0lUSFJFQURdDQphdGEzOiA8QVRBIGNo YW5uZWwgMT4gb24gYXRhcGNpMQ0KYXRhcGNpMTogUmVzZXJ2ZWQgMHg4IGJ5 dGVzIGZvciByaWQgMHgxOCB0eXBlIDQgYXQgMHg5NzANCmF0YXBjaTE6IFJl c2VydmVkIDB4NCBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4Yjcw DQphdGEzOiBTQVRBIGNvbm5lY3QgdGltZT0wbXMNCmF0YTM6IHJlc2V0IHRw MSBtYXNrPTAxIG9zdGF0MD01MCBvc3RhdDE9MDANCmF0YTM6IHN0YXQwPTB4 NTAgZXJyPTB4MDEgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHJlc2V0IHRw MiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MTxBVEFfTUFTVEVSPg0K YXRhMzogW01QU0FGRV0NCmF0YTM6IFtJVEhSRUFEXQ0KYXRhcGNpMjogPG5W aWRpYSBuRm9yY2UgTUNQNTUgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4 OWUwLTB4OWU3LDB4YmUwLTB4YmUzLDB4OTYwLTB4OTY3LDB4YjYwLTB4YjYz LDB4Y2MwMC0weGNjMGYgbWVtIDB4ZmUwMmMwMDAtMHhmZTAyY2ZmZiBpcnEg MjMgYXQgZGV2aWNlIDEzLjEgb24gcGNpMA0KYXRhcGNpMjogUmVzZXJ2ZWQg MHgxMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4Y2MwMA0KaW9h cGljMDogcm91dGluZyBpbnRwaW4gMjMgKFBDSSBJUlEgMjMpIHRvIHZlY3Rv ciA1Mg0KYXRhcGNpMjogW01QU0FGRV0NCmF0YXBjaTI6IFtJVEhSRUFEXQ0K YXRhcGNpMjogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgyNCB0 eXBlIDMgYXQgMHhmZTAyYzAwMA0KYXRhNDogPEFUQSBjaGFubmVsIDA+IG9u IGF0YXBjaTINCmF0YXBjaTI6IFJlc2VydmVkIDB4OCBieXRlcyBmb3Igcmlk IDB4MTAgdHlwZSA0IGF0IDB4OWUwDQphdGFwY2kyOiBSZXNlcnZlZCAweDQg Ynl0ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweGJlMA0KYXRhNDogU0FU QSBjb25uZWN0IHN0YXR1cz0wMDAwMDAwMA0KYXRhNDogW01QU0FGRV0NCmF0 YTQ6IFtJVEhSRUFEXQ0KYXRhNTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBj aTINCmF0YXBjaTI6IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTgg dHlwZSA0IGF0IDB4OTYwDQphdGFwY2kyOiBSZXNlcnZlZCAweDQgYnl0ZXMg Zm9yIHJpZCAweDFjIHR5cGUgNCBhdCAweGI2MA0KYXRhNTogU0FUQSBjb25u ZWN0IHN0YXR1cz0wMDAwMDAwMA0KYXRhNTogW01QU0FGRV0NCmF0YTU6IFtJ VEhSRUFEXQ0KYXRhcGNpMzogPG5WaWRpYSBuRm9yY2UgTUNQNTUgU0FUQTMw MCBjb250cm9sbGVyPiBwb3J0IDB4YzgwMC0weGM4MDcsMHhjNDAwLTB4YzQw MywweGMwMDAtMHhjMDA3LDB4YmMwMC0weGJjMDMsMHhiODAwLTB4YjgwZiBt ZW0gMHhmZTAyYjAwMC0weGZlMDJiZmZmIGlycSAyMCBhdCBkZXZpY2UgMTMu MiBvbiBwY2kwDQphdGFwY2kzOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciBy aWQgMHgyMCB0eXBlIDQgYXQgMHhiODAwDQppb2FwaWMwOiByb3V0aW5nIGlu dHBpbiAyMCAoUENJIElSUSAyMCkgdG8gdmVjdG9yIDUzDQphdGFwY2kzOiBb TVBTQUZFXQ0KYXRhcGNpMzogW0lUSFJFQURdDQphdGFwY2kzOiBSZXNlcnZl ZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAweDI0IHR5cGUgMyBhdCAweGZlMDJi MDAwDQphdGE2OiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMw0KYXRhcGNp MzogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDQgYXQg MHhjODAwDQphdGFwY2kzOiBSZXNlcnZlZCAweDQgYnl0ZXMgZm9yIHJpZCAw eDE0IHR5cGUgNCBhdCAweGM0MDANCmF0YTY6IFNBVEEgY29ubmVjdCBzdGF0 dXM9MDAwMDAwMDANCmF0YTY6IFtNUFNBRkVdDQphdGE2OiBbSVRIUkVBRF0N CmF0YTc6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kzDQphdGFwY2kzOiBS ZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4IHR5cGUgNCBhdCAweGMw MDANCmF0YXBjaTM6IFJlc2VydmVkIDB4NCBieXRlcyBmb3IgcmlkIDB4MWMg dHlwZSA0IGF0IDB4YmMwMA0KYXRhNzogU0FUQSBjb25uZWN0IHN0YXR1cz0w MDAwMDAwMA0KYXRhNzogW01QU0FGRV0NCmF0YTc6IFtJVEhSRUFEXQ0KcGNp YjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTQuMCBvbiBw Y2kwDQpwY2liMjogICBzZWNvbmRhcnkgYnVzICAgICAyDQpwY2liMjogICBz dWJvcmRpbmF0ZSBidXMgICAyDQpwY2liMjogICBJL08gZGVjb2RlICAgICAg ICAweGYwMDAtMHhmZmYNCnBjaWIyOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4 ZmRmMDAwMDAtMHhmZGZmZmZmZg0KcGNpYjI6ICAgcHJlZmV0Y2hlZCBkZWNv ZGUgMHhmYzAwMDAwMC0weGZjZmZmZmZmDQpwY2liMjogICBTdWJ0cmFjdGl2 ZWx5IGRlY29kZWQgYnJpZGdlLg0KcGNpMjogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjINCnBjaTI6IHBoeXNpY2FsIGJ1cz0yDQpmb3VuZC0+CXZlbmRvcj0w eDEwMTMsIGRldj0weDAwYjgsIHJldmlkPTB4MDANCglidXM9Miwgc2xvdD02 LCBmdW5jPTANCgljbGFzcz0wMy0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRl dj0wDQoJY21kcmVnPTB4MDAwMywgc3RhdHJlZz0weDAyMDAsIGNhY2hlbG5z ej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0w eDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWEsIGly cT01DQoJbWFwWzEwXTogdHlwZSBQcmVmZXRjaGFibGUgTWVtb3J5LCByYW5n ZSAzMiwgYmFzZSAweGZjMDAwMDAwLCBzaXplIDI0LCBlbmFibGVkDQpwY2li MjogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGZjMDAwMDAwLTB4ZmNmZmZm ZmY6IGdvb2QNCnBjaWIyOiBtYXRjaGVkIGVudHJ5IGZvciAyLjYuSU5UQSAo c3JjIFxcX1NCXy5QQ0kwLkFQQzE6MCkNCnBjaV9saW5rMjA6IFBpY2tlZCBJ UlEgMTYgd2l0aCB3ZWlnaHQgMA0KcGNpYjI6IHNsb3QgNiBJTlRBIHJvdXRl ZCB0byBpcnEgMTYgdmlhIFxcX1NCXy5QQ0kwLkFQQzENCmZvdW5kLT4JdmVu ZG9yPTB4MTA0YywgZGV2PTB4ODAyMywgcmV2aWQ9MHgwMA0KCWJ1cz0yLCBz bG90PTExLCBmdW5jPTANCgljbGFzcz0wYy0wMC0xMCwgaGRydHlwZT0weDAw LCBtZmRldj0wDQoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAyMTAsIGNh Y2hlbG5zej04IChkd29yZHMpDQoJbGF0dGltZXI9MHgyMCAoOTYwIG5zKSwg bWluZ250PTB4MDIgKDUwMCBucyksIG1heGxhdD0weDA0ICgxMDAwIG5zKQ0K CWludHBpbj1hLCBpcnE9MTENCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAg RDEgRDIgRDMgIGN1cnJlbnQgRDANCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwg cmFuZ2UgMzIsIGJhc2UgMHhmZGZmZjAwMCwgc2l6ZSAxMSwgZW5hYmxlZA0K cGNpYjI6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmZGZmZjAwMC0weGZk ZmZmN2ZmOiBnb29kDQoJbWFwWzE0XTogdHlwZSBNZW1vcnksIHJhbmdlIDMy LCBiYXNlIDB4ZmRmZjgwMDAsIHNpemUgMTQsIGVuYWJsZWQNCnBjaWIyOiBy ZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmRmZjgwMDAtMHhmZGZmYmZmZjog Z29vZA0KcGNpYjI6IG1hdGNoZWQgZW50cnkgZm9yIDIuMTEuSU5UQSAoc3Jj IFxcX1NCXy5QQ0kwLkFQQzQ6MCkNCnBjaV9saW5rMjM6IFBpY2tlZCBJUlEg MTkgd2l0aCB3ZWlnaHQgMA0KcGNpYjI6IHNsb3QgMTEgSU5UQSByb3V0ZWQg dG8gaXJxIDE5IHZpYSBcXF9TQl8uUENJMC5BUEM0DQp2Z2FwY2kwOiA8VkdB LWNvbXBhdGlibGUgZGlzcGxheT4gbWVtIDB4ZmMwMDAwMDAtMHhmY2ZmZmZm ZiBpcnEgMTYgYXQgZGV2aWNlIDYuMCBvbiBwY2kyDQpwY2kyOiA8c2VyaWFs IGJ1cywgRmlyZVdpcmU+IGF0IGRldmljZSAxMS4wIChubyBkcml2ZXIgYXR0 YWNoZWQpDQpwY2kwOiA8bXVsdGltZWRpYT4gYXQgZGV2aWNlIDE0LjEgKG5v IGRyaXZlciBhdHRhY2hlZCkNCm5mZTA6IDxOVklESUEgbkZvcmNlIE1DUDU1 IE5ldHdvcmtpbmcgQWRhcHRlcj4gcG9ydCAweGI0MDAtMHhiNDA3IG1lbSAw eGZlMDJhMDAwLTB4ZmUwMmFmZmYsMHhmZTAyOTAwMC0weGZlMDI5MGZmLDB4 ZmUwMjgwMDAtMHhmZTAyODAwZiBpcnEgMjIgYXQgZGV2aWNlIDE2LjAgb24g cGNpMA0KbmZlMDogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgx MCB0eXBlIDMgYXQgMHhmZTAyYTAwMA0KbmZlMDogUmVzZXJ2ZWQgMHgxMDAg Ynl0ZXMgZm9yIHJpZCAweDE4IHR5cGUgMyBhdCAweGZlMDI5MDAwDQpuZmUw OiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgxYyB0eXBlIDMgYXQg MHhmZTAyODAwMA0KbmZlMDogYXR0ZW1wdGluZyB0byBhbGxvY2F0ZSA4IE1T SS1YIHZlY3RvcnMgKDggc3VwcG9ydGVkKQ0KbXNpOiByb3V0aW5nIE1TSS1Y IElSUSAyNTYgdG8gdmVjdG9yIDU0DQptc2k6IHJvdXRpbmcgTVNJLVggSVJR IDI1NyB0byB2ZWN0b3IgNTUNCm1zaTogcm91dGluZyBNU0ktWCBJUlEgMjU4 IHRvIHZlY3RvciA1Ng0KbXNpOiByb3V0aW5nIE1TSS1YIElSUSAyNTkgdG8g dmVjdG9yIDU3DQptc2k6IHJvdXRpbmcgTVNJLVggSVJRIDI2MCB0byB2ZWN0 b3IgNTgNCm1zaTogcm91dGluZyBNU0ktWCBJUlEgMjYxIHRvIHZlY3RvciA1 OQ0KbXNpOiByb3V0aW5nIE1TSS1YIElSUSAyNjIgdG8gdmVjdG9yIDYwDQpt c2k6IHJvdXRpbmcgTVNJLVggSVJRIDI2MyB0byB2ZWN0b3IgNjENCm5mZTA6 IHVzaW5nIElSUXMgMjU2LTI2MyBmb3IgTVNJLVgNCm5mZTA6IFVzaW5nIDgg TVNJWCBtZXNzYWdlcw0KbWlpYnVzMDogPE1JSSBidXM+IG9uIG5mZTANCmUx MDAwcGh5MDogPE1hcnZlbGwgODhFMTExNiBHaWdhYml0IFBIWT4gUEhZIDEg b24gbWlpYnVzMA0KZTEwMDBwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgs IDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAwMGJhc2VUWC1GRFgsIGF1 dG8NCm5mZTA6IGJwZiBhdHRhY2hlZA0KbmZlMDogRXRoZXJuZXQgYWRkcmVz czogMDA6MTg6ZjM6YWI6NGM6ZjANCm5mZTA6IFtNUFNBRkVdDQpuZmUwOiBb RklMVEVSXQ0KbmZlMDogW01QU0FGRV0NCm5mZTA6IFtGSUxURVJdDQpuZmUw OiBbTVBTQUZFXQ0KbmZlMDogW0ZJTFRFUl0NCm5mZTA6IFtNUFNBRkVdDQpu ZmUwOiBbRklMVEVSXQ0KbmZlMDogW01QU0FGRV0NCm5mZTA6IFtGSUxURVJd DQpuZmUwOiBbTVBTQUZFXQ0KbmZlMDogW0ZJTFRFUl0NCm5mZTA6IFtNUFNB RkVdDQpuZmUwOiBbRklMVEVSXQ0KbmZlMDogW01QU0FGRV0NCm5mZTA6IFtG SUxURVJdDQpuZmUxOiA8TlZJRElBIG5Gb3JjZSBNQ1A1NSBOZXR3b3JraW5n IEFkYXB0ZXI+IHBvcnQgMHhiMDAwLTB4YjAwNyBtZW0gMHhmZTAyNzAwMC0w eGZlMDI3ZmZmLDB4ZmUwMjYwMDAtMHhmZTAyNjBmZiwweGZlMDI1MDAwLTB4 ZmUwMjUwMGYgaXJxIDIzIGF0IGRldmljZSAxNy4wIG9uIHBjaTANCm5mZTE6 IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0 IDB4ZmUwMjcwMDANCm5mZTE6IFJlc2VydmVkIDB4MTAwIGJ5dGVzIGZvciBy aWQgMHgxOCB0eXBlIDMgYXQgMHhmZTAyNjAwMA0KbmZlMTogUmVzZXJ2ZWQg MHgxMCBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSAzIGF0IDB4ZmUwMjUwMDAN Cm5mZTE6IGF0dGVtcHRpbmcgdG8gYWxsb2NhdGUgOCBNU0ktWCB2ZWN0b3Jz ICg4IHN1cHBvcnRlZCkNCm1zaTogcm91dGluZyBNU0ktWCBJUlEgMjY0IHRv IHZlY3RvciA2Mg0KbXNpOiByb3V0aW5nIE1TSS1YIElSUSAyNjUgdG8gdmVj dG9yIDYzDQptc2k6IHJvdXRpbmcgTVNJLVggSVJRIDI2NiB0byB2ZWN0b3Ig NjQNCm1zaTogcm91dGluZyBNU0ktWCBJUlEgMjY3IHRvIHZlY3RvciA2NQ0K bXNpOiByb3V0aW5nIE1TSS1YIElSUSAyNjggdG8gdmVjdG9yIDY2DQptc2k6 IHJvdXRpbmcgTVNJLVggSVJRIDI2OSB0byB2ZWN0b3IgNjcNCm1zaTogcm91 dGluZyBNU0ktWCBJUlEgMjcwIHRvIHZlY3RvciA2OA0KbXNpOiByb3V0aW5n IE1TSS1YIElSUSAyNzEgdG8gdmVjdG9yIDY5DQpuZmUxOiB1c2luZyBJUlFz IDI2NC0yNzEgZm9yIE1TSS1YDQpuZmUxOiBVc2luZyA4IE1TSVggbWVzc2Fn ZXMNCm1paWJ1czE6IDxNSUkgYnVzPiBvbiBuZmUxDQplMTAwMHBoeTE6IDxN YXJ2ZWxsIDg4RTExMTYgR2lnYWJpdCBQSFk+IFBIWSAxIG9uIG1paWJ1czEN CmUxMDAwcGh5MTogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgs IDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlVFgtRkRYLCBhdXRvDQpuZmUxOiBi cGYgYXR0YWNoZWQNCm5mZTE6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjE4OmYz OmFiOjUwOjZmDQpuZmUxOiBbTVBTQUZFXQ0KbmZlMTogW0ZJTFRFUl0NCm5m ZTE6IFtNUFNBRkVdDQpuZmUxOiBbRklMVEVSXQ0KbmZlMTogW01QU0FGRV0N Cm5mZTE6IFtGSUxURVJdDQpuZmUxOiBbTVBTQUZFXQ0KbmZlMTogW0ZJTFRF Ul0NCm5mZTE6IFtNUFNBRkVdDQpuZmUxOiBbRklMVEVSXQ0KbmZlMTogW01Q U0FGRV0NCm5mZTE6IFtGSUxURVJdDQpuZmUxOiBbTVBTQUZFXQ0KbmZlMTog W0ZJTFRFUl0NCm5mZTE6IFtNUFNBRkVdDQpuZmUxOiBbRklMVEVSXQ0KcGNp YjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTguMCBvbiBw Y2kwDQpwY2liMzogICBzZWNvbmRhcnkgYnVzICAgICAzDQpwY2liMzogICBz dWJvcmRpbmF0ZSBidXMgICA1DQpwY2liMzogICBJL08gZGVjb2RlICAgICAg ICAweGEwMDAtMHhhZmZmDQpwY2liMzogICBtZW1vcnkgZGVjb2RlICAgICAw eGZkZDAwMDAwLTB4ZmRlZmZmZmYNCnBjaWIzOiAgIG5vIHByZWZldGNoZWQg ZGVjb2RlDQpwY2liMzogY291bGQgbm90IGdldCBQQ0kgaW50ZXJydXB0IHJv dXRpbmcgdGFibGUgZm9yIFxcX1NCXy5QQ0kwLlhWUjUgLSBBRV9OT1RfRk9V TkQNCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzDQpwY2kzOiBwaHlz aWNhbCBidXM9Mw0KZm91bmQtPgl2ZW5kb3I9MHgxMDMzLCBkZXY9MHgwMTI1 LCByZXZpZD0weDA2DQoJYnVzPTMsIHNsb3Q9MCwgZnVuYz0wDQoJY2xhc3M9 MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MQ0KCWNtZHJlZz0weDAw MDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9OCAoZHdvcmRzKQ0KCWxh dHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1h eGxhdD0weDAwICgwIG5zKQ0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBE MSBEMyAgY3VycmVudCBEMA0KZm91bmQtPgl2ZW5kb3I9MHgxMDMzLCBkZXY9 MHgwMTI1LCByZXZpZD0weDA2DQoJYnVzPTMsIHNsb3Q9MCwgZnVuYz0xDQoJ Y2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MQ0KCWNtZHJl Zz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9OCAoZHdvcmRz KQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQ0KCWludHBpbj1hLCBpcnE9MTENCglw b3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDMgIGN1cnJlbnQgRDANCglN U0kgc3VwcG9ydHMgMSBtZXNzYWdlLCA2NCBiaXQNCgltYXBbMTBdOiB0eXBl IE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmZGVmZjAwMCwgc2l6ZSAgNywg ZW5hYmxlZA0KcGNpYjM6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmZGVm ZjAwMC0weGZkZWZmMDdmOiBnb29kDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBm b3IgMC4xOC5JTlRBIChzcmMgXFxfU0JfLlBDSTAuQVBDNzowKQ0KcGNpX2xp bmsyNjogUGlja2VkIElSUSAxNiB3aXRoIHdlaWdodCAzDQpwY2liMDogc2xv dCAxOCBJTlRBIHJvdXRlZCB0byBpcnEgMTYgdmlhIFxcX1NCXy5QQ0kwLkFQ QzcNCnBjaWIzOiBzbG90IDAgSU5UQSBpcyByb3V0ZWQgdG8gaXJxIDE2DQpw Y2liNDogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMC4wIG9uIHBjaTMN CnBjaWI0OiAgIHNlY29uZGFyeSBidXMgICAgIDQNCnBjaWI0OiAgIHN1Ym9y ZGluYXRlIGJ1cyAgIDQNCnBjaWI0OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4 YTAwMC0weGFmZmYNCnBjaWI0OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZmRk MDAwMDAtMHhmZGRmZmZmZg0KcGNpYjQ6ICAgbm8gcHJlZmV0Y2hlZCBkZWNv ZGUNCnBjaTQ6IDxQQ0kgYnVzPiBvbiBwY2liNA0KcGNpNDogcGh5c2ljYWwg YnVzPTQNCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MTAwOCwgcmV2 aWQ9MHgwMg0KCWJ1cz00LCBzbG90PTIsIGZ1bmM9MA0KCWNsYXNzPTAyLTAw LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA3LCBz dGF0cmVnPTB4MDIzMCwgY2FjaGVsbnN6PTggKGR3b3JkcykNCglsYXR0aW1l cj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHhmZiAoNjM3NTAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykNCglpbnRwaW49YSwgaXJxPTEwDQoJcG93ZXJzcGVj IDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwDQoJTVNJIHN1cHBvcnRz IDEgbWVzc2FnZSwgNjQgYml0DQoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJh bmdlIDY0LCBiYXNlIDB4ZmRkZTAwMDAsIHNpemUgMTcsIGVuYWJsZWQNCnBj aWI0OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmRkZTAwMDAtMHhmZGRm ZmZmZjogZ29vZA0KcGNpYjM6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhm ZGRlMDAwMC0weGZkZGZmZmZmOiBnb29kDQoJbWFwWzE4XTogdHlwZSBNZW1v cnksIHJhbmdlIDY0LCBiYXNlIDB4ZmRkYzAwMDAsIHNpemUgMTcsIGVuYWJs ZWQNCnBjaWI0OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmRkYzAwMDAt MHhmZGRkZmZmZjogZ29vZA0KcGNpYjM6IHJlcXVlc3RlZCBtZW1vcnkgcmFu Z2UgMHhmZGRjMDAwMC0weGZkZGRmZmZmOiBnb29kDQoJbWFwWzIwXTogdHlw ZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhhYzAwLCBzaXplICA1LCBl bmFibGVkDQpwY2liNDogcmVxdWVzdGVkIEkvTyByYW5nZSAweGFjMDAtMHhh YzFmOiBpbiByYW5nZQ0KcGNpYjM6IHJlcXVlc3RlZCBJL08gcmFuZ2UgMHhh YzAwLTB4YWMxZjogaW4gcmFuZ2UNCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZv ciAwLjE4LklOVEMgKHNyYyBcXF9TQl8uUENJMC5BUEM1OjApDQpwY2lfbGlu azI0OiBQaWNrZWQgSVJRIDE2IHdpdGggd2VpZ2h0IDEyDQpwY2liMDogc2xv dCAxOCBJTlRDIHJvdXRlZCB0byBpcnEgMTYgdmlhIFxcX1NCXy5QQ0kwLkFQ QzUNCnBjaWIzOiBzbG90IDAgSU5UQyBpcyByb3V0ZWQgdG8gaXJxIDE2DQpw Y2liNDogc2xvdCAyIElOVEEgaXMgcm91dGVkIHRvIGlycSAxNg0KZW0wOiA8 SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uIFZlcnNpb24g LSA2LjUuMz4gcG9ydCAweGFjMDAtMHhhYzFmIG1lbSAweGZkZGUwMDAwLTB4 ZmRkZmZmZmYsMHhmZGRjMDAwMC0weGZkZGRmZmZmIGlycSAxNiBhdCBkZXZp Y2UgMi4wIG9uIHBjaTQNCmVtMDogUmVzZXJ2ZWQgMHgyMDAwMCBieXRlcyBm b3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmRkZTAwMDANCmVtMDogUmVzZXJ2 ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4YWMwMA0K ZW0wOiBicGYgYXR0YWNoZWQNCmVtMDogRXRoZXJuZXQgYWRkcmVzczogMDA6 MDI6YjM6YmM6YzU6ZjcNCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE2IChQ Q0kgSVJRIDE2KSB0byB2ZWN0b3IgNzANCmVtMDogW0ZJTFRFUl0NCnBjaWI1 OiA8UENJLVBDSSBicmlkZ2U+IG1lbSAweGZkZWZmMDAwLTB4ZmRlZmYwN2Yg aXJxIDE2IGF0IGRldmljZSAwLjEgb24gcGNpMw0KcGNpYjU6ICAgc2Vjb25k YXJ5IGJ1cyAgICAgNQ0KcGNpYjU6ICAgc3Vib3JkaW5hdGUgYnVzICAgNQ0K cGNpYjU6ICAgSS9PIGRlY29kZSAgICAgICAgMHhmMDAwLTB4ZmZmDQpwY2li NTogICBubyBwcmVmZXRjaGVkIGRlY29kZQ0KcGNpNTogPFBDSSBidXM+IG9u IHBjaWI1DQpwY2k1OiBwaHlzaWNhbCBidXM9NQ0KcGNpYjY6IDxBQ1BJIFBD SS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMjAuMCBvbiBwY2kwDQpwY2liNjog ICBzZWNvbmRhcnkgYnVzICAgICA2DQpwY2liNjogICBzdWJvcmRpbmF0ZSBi dXMgICA2DQpwY2liNjogICBJL08gZGVjb2RlICAgICAgICAweDAtMHgwDQpw Y2liNjogICBubyBwcmVmZXRjaGVkIGRlY29kZQ0KcGNpYjY6IGNvdWxkIG5v dCBnZXQgUENJIGludGVycnVwdCByb3V0aW5nIHRhYmxlIGZvciBcXF9TQl8u UENJMC5YVlIzIC0gQUVfTk9UX0ZPVU5EDQpwY2k2OiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liNg0KcGNpNjogcGh5c2ljYWwgYnVzPTYNCnBjaWI3OiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDIxLjAgb24gcGNpMA0KcGNp Yjc6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgNw0KcGNpYjc6ICAgc3Vib3JkaW5h dGUgYnVzICAgNw0KcGNpYjc6ICAgSS9PIGRlY29kZSAgICAgICAgMHgwLTB4 MA0KcGNpYjc6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUNCnBjaWI3OiBjb3Vs ZCBub3QgZ2V0IFBDSSBpbnRlcnJ1cHQgcm91dGluZyB0YWJsZSBmb3IgXFxf U0JfLlBDSTAuWFZSMiAtIEFFX05PVF9GT1VORA0KcGNpNzogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjcNCnBjaTc6IHBoeXNpY2FsIGJ1cz03DQpwY2liODog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyMi4wIG9uIHBjaTAN CnBjaWI4OiAgIHNlY29uZGFyeSBidXMgICAgIDgNCnBjaWI4OiAgIHN1Ym9y ZGluYXRlIGJ1cyAgIDgNCnBjaWI4OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4 OTAwMC0weDlmZmYNCnBjaWI4OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZmRj MDAwMDAtMHhmZGNmZmZmZg0KcGNpYjg6ICAgbm8gcHJlZmV0Y2hlZCBkZWNv ZGUNCnBjaWI4OiBjb3VsZCBub3QgZ2V0IFBDSSBpbnRlcnJ1cHQgcm91dGlu ZyB0YWJsZSBmb3IgXFxfU0JfLlBDSTAuWFZSMSAtIEFFX05PVF9GT1VORA0K cGNpODogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjgNCnBjaTg6IHBoeXNpY2Fs IGJ1cz04DQpmb3VuZC0+CXZlbmRvcj0weDExYWIsIGRldj0weDYxNDEsIHJl dmlkPTB4MDENCglidXM9OCwgc2xvdD0wLCBmdW5jPTANCgljbGFzcz0wMS0w Ni04MSwgaGRydHlwZT0weDAwLCBtZmRldj0wDQoJY21kcmVnPTB4MDAwNywg c3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej04IChkd29yZHMpDQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDA4ICgyMDAwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpDQoJaW50cGluPWEsIGlycT0xMQ0KCXBvd2Vyc3BlYyAy ICBzdXBwb3J0cyBEMCBEMSBEMyAgY3VycmVudCBEMA0KCU1TSSBzdXBwb3J0 cyAxIG1lc3NhZ2UNCgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAz MiwgYmFzZSAweDljMDAsIHNpemUgIDMsIGVuYWJsZWQNCnBjaWI4OiByZXF1 ZXN0ZWQgSS9PIHJhbmdlIDB4OWMwMC0weDljMDc6IGluIHJhbmdlDQoJbWFw WzE0XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg5ODAwLCBz aXplICAyLCBlbmFibGVkDQpwY2liODogcmVxdWVzdGVkIEkvTyByYW5nZSAw eDk4MDAtMHg5ODAzOiBpbiByYW5nZQ0KCW1hcFsxOF06IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4OTQwMCwgc2l6ZSAgNiwgZW5hYmxlZA0K cGNpYjg6IHJlcXVlc3RlZCBJL08gcmFuZ2UgMHg5NDAwLTB4OTQzZjogaW4g cmFuZ2UNCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFz ZSAweDkwMDAsIHNpemUgIDUsIGVuYWJsZWQNCnBjaWI4OiByZXF1ZXN0ZWQg SS9PIHJhbmdlIDB4OTAwMC0weDkwMWY6IGluIHJhbmdlDQoJbWFwWzI0XTog dHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmRjZmYwMDAsIHNpemUg MTAsIGVuYWJsZWQNCnBjaWI4OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4 ZmRjZmYwMDAtMHhmZGNmZjNmZjogZ29vZA0KcGNpYjA6IG1hdGNoZWQgZW50 cnkgZm9yIDAuMjIuSU5UQSAoc3JjIFxcX1NCXy5QQ0kwLkFQQzc6MCkNCnBj aWIwOiBzbG90IDIyIElOVEEgcm91dGVkIHRvIGlycSAxNiB2aWEgXFxfU0Jf LlBDSTAuQVBDNw0KcGNpYjg6IHNsb3QgMCBJTlRBIGlzIHJvdXRlZCB0byBp cnEgMTYNCnBjaTg6IDxtYXNzIHN0b3JhZ2U+IGF0IGRldmljZSAwLjAgKG5v IGRyaXZlciBhdHRhY2hlZCkNCnBjaWI5OiA8QUNQSSBQQ0ktUENJIGJyaWRn ZT4gYXQgZGV2aWNlIDIzLjAgb24gcGNpMA0KcGNpYjk6ICAgc2Vjb25kYXJ5 IGJ1cyAgICAgOQ0KcGNpYjk6ICAgc3Vib3JkaW5hdGUgYnVzICAgOQ0KcGNp Yjk6ICAgSS9PIGRlY29kZSAgICAgICAgMHgwLTB4MA0KcGNpYjk6ICAgbm8g cHJlZmV0Y2hlZCBkZWNvZGUNCnBjaWI5OiBjb3VsZCBub3QgZ2V0IFBDSSBp bnRlcnJ1cHQgcm91dGluZyB0YWJsZSBmb3IgXFxfU0JfLlBDSTAuWFZSMCAt IEFFX05PVF9GT1VORA0KcGNpOTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjkN CnBjaTk6IHBoeXNpY2FsIGJ1cz05DQphY3BpX3R6MDogPFRoZXJtYWwgWm9u ZT4gb24gYWNwaTANCnNpbzA6IGlycSBtYXBzOiAweGNhMSAweGNiMSAweGNh MSAweGNhMQ0Kc2lvMDogaXJxIG1hcHM6IDB4Y2ExIDB4Y2IxIDB4Y2ExIDB4 Y2ExDQpzaW8wOiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQg MHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMA0Kc2lvMDog dHlwZSAxNjU1MEENCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDQgKElTQSBJ UlEgNCkgdG8gdmVjdG9yIDcxDQpzaW8wOiBbRklMVEVSXQ0KYXRrYmRjMDog PEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQg aXJxIDEgb24gYWNwaTANCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBv biBhdGtiZGMwDQphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRyb2xsZXIg Y29tbWFuZCBieXRlIDAwNDcNCmF0a2JkOiBrZXlib2FyZCBJRCAweDQxYWIg KDIpDQprYmQwIGF0IGF0a2JkMA0Ka2JkMDogYXRrYmQwLCBBVCAxMDEvMTAy ICgyKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDANCmlvYXBpYzA6IHJv dXRpbmcgaW50cGluIDEgKElTQSBJUlEgMSkgdG8gdmVjdG9yIDcyDQphdGti ZDA6IFtHSUFOVC1MT0NLRURdDQphdGtiZDA6IFtJVEhSRUFEXQ0KcHNtMDog dW5hYmxlIHRvIGFsbG9jYXRlIElSUQ0KdW5rbm93bjogc3RhdHVzIHJlZyB0 ZXN0IGZhaWxlZCBmZg0KdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxl ZCBmZg0KdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZg0KdW5r bm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZg0KdW5rbm93bjogc3Rh dHVzIHJlZyB0ZXN0IGZhaWxlZCBmZg0KdW5rbm93bjogc3RhdHVzIHJlZyB0 ZXN0IGZhaWxlZCBmZg0KZXhfaXNhX2lkZW50aWZ5KCkNCmFoY19pc2FfcHJv YmUgMDogaW9wb3J0IDB4YzAwIGFsbG9jIGZhaWxlZA0KYWhjX2lzYV9wcm9i ZSAxOiBpb3BvcnQgMHgxYzAwIGFsbG9jIGZhaWxlZA0KYWhjX2lzYV9wcm9i ZSA5OiBpb3BvcnQgMHg5YzAwIGFsbG9jIGZhaWxlZA0KYWhjX2lzYV9wcm9i ZSAxMDogaW9wb3J0IDB4YWMwMCBhbGxvYyBmYWlsZWQNCmFoY19pc2FfcHJv YmUgMTE6IGlvcG9ydCAweGJjMDAgYWxsb2MgZmFpbGVkDQphaGNfaXNhX3By b2JlIDEyOiBpb3BvcnQgMHhjYzAwIGFsbG9jIGZhaWxlZA0KYXRhOiBhdGEw IGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdA0KYXRhOiBhdGExIGFscmVh ZHkgZXhpc3RzOyBza2lwcGluZyBpdA0KYXRrYmRjOiBhdGtiZGMwIGFscmVh ZHkgZXhpc3RzOyBza2lwcGluZyBpdA0Kc2M6IHNjMCBhbHJlYWR5IGV4aXN0 czsgc2tpcHBpbmcgaXQNCnNpbzogc2lvMCBhbHJlYWR5IGV4aXN0czsgc2tp cHBpbmcgaXQNCnZnYTogdmdhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcg aXQNCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyMDMNCnBu cF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyNDMNCnBucF9pZGVu dGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyODMNCnBucF9pZGVudGlmeTog VHJ5aW5nIFJlYWRfUG9ydCBhdCAyYzMNCnBucF9pZGVudGlmeTogVHJ5aW5n IFJlYWRfUG9ydCBhdCAzMDMNCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRf UG9ydCBhdCAzNDMNCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBh dCAzODMNCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzYzMN ClBOUCBJZGVudGlmeSBjb21wbGV0ZQ0KaXNhX3Byb2JlX2NoaWxkcmVuOiBk aXNhYmxpbmcgUG5QIGRldmljZXMNCmlzYV9wcm9iZV9jaGlsZHJlbjogcHJv YmluZyBub24tUG5QIGRldmljZXMNCnBtdGltZXIwIG9uIGlzYTANCm9ybTA6 IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjN2ZmZiww eGM4MDAwLTB4ZDNmZmYgcG5waWQgT1JNMDAwMCBvbiBpc2EwDQpzYzA6IDxT eXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMA0Kc2MwOiBW R0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPg0Kc2MwOiBm YjAsIGtiZDEsIHRlcm1pbmFsIGVtdWxhdG9yOiBzYyAoc3lzY29ucyB0ZXJt aW5hbCkNCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAt MHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTANCmFkdjA6IG5v dCBwcm9iZWQgKGRpc2FibGVkKQ0KYWhhMDogbm90IHByb2JlZCAoZGlzYWJs ZWQpDQphaWMwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNCmJ0MDogbm90IHBy b2JlZCAoZGlzYWJsZWQpDQpjczA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0K ZWQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNCmZkYzAgZmFpbGVkIHRvIHBy b2JlIGF0IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24g aXNhMA0KZmUwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNCmllMDogbm90IHBy b2JlZCAoZGlzYWJsZWQpDQpsZTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0K cHBjMDogcGFyYWxsZWwgcG9ydCBmb3VuZCBhdCAweDM3OA0KcHBjMDogdXNp bmcgZXh0ZW5kZWQgSS9PIHBvcnQgcmFuZ2UNCnBwYzA6IEVDUCBTUFAgRUNQ K0VQUCBTUFANCnBwYzA6IDxQYXJhbGxlbCBwb3J0PiBhdCBwb3J0IDB4Mzc4 LTB4MzdmIGlycSA3IG9uIGlzYTANCnBwYzA6IFNNQy1saWtlIGNoaXBzZXQg KEVDUC9FUFAvUFMyL05JQkJMRSkgaW4gQ09NUEFUSUJMRSBtb2RlDQpwcGMw OiBGSUZPIHdpdGggMTYvMTYvMTYgYnl0ZXMgdGhyZXNob2xkDQpwcGJ1czA6 IDxQYXJhbGxlbCBwb3J0IGJ1cz4gb24gcHBjMA0KcGxpcDA6IDxQTElQIG5l dHdvcmsgaW50ZXJmYWNlPiBvbiBwcGJ1czANCnBsaXAwOiBicGYgYXR0YWNo ZWQNCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czANCmxwdDA6IEludGVycnVw dC1kcml2ZW4gcG9ydA0KcHBpMDogPFBhcmFsbGVsIEkvTz4gb24gcHBidXMw DQppb2FwaWMwOiByb3V0aW5nIGludHBpbiA3IChJU0EgSVJRIDcpIHRvIHZl Y3RvciA3Mw0KcHBjMDogW0dJQU5ULUxPQ0tFRF0NCnBwYzA6IFtJVEhSRUFE XQ0Kc2lvMTogY29uZmlndXJlZCBpcnEgMyBub3QgaW4gYml0bWFwIG9mIHBy b2JlZCBpcnFzIDANCnNpbzE6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkDQpz aW8xOiBpcnEgbWFwczogMHhjYTEgMHhjYTEgMHhjYTEgMHhjYTENCnNpbzE6 IHByb2JlIGZhaWxlZCB0ZXN0KHMpOiAwIDEgMiA0IDYgNyA5DQpzaW8xIGZh aWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGlz YTANCnNpbzI6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0Kc2lvMzogbm90IHBy b2JlZCAoZGlzYWJsZWQpDQpzbjA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0K dnQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNCmlzYV9wcm9iZV9jaGlsZHJl bjogcHJvYmluZyBQblAgZGV2aWNlcw0KRGV2aWNlIGNvbmZpZ3VyYXRpb24g ZmluaXNoZWQuDQpwcm9jZnMgcmVnaXN0ZXJlZA0KV0FSTklORzogWkZTIGlz IGNvbnNpZGVyZWQgdG8gYmUgYW4gZXhwZXJpbWVudGFsIGZlYXR1cmUgaW4g RnJlZUJTRC4NCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1ZW5jeSAxMDA0NjM4 NDkgaHoNClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAyNjEyMDU4NjM4 IEh6IHF1YWxpdHkgLTEwMA0KVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4w MDAgbXNlYw0KTGludXggRUxGIGV4ZWMgaGFuZGxlciBpbnN0YWxsZWQNCmxv MDogYnBmIGF0dGFjaGVkDQpycjIzMng6IG5vIGNvbnRyb2xsZXIgZGV0ZWN0 ZWQuDQpUaGUgR0VPTSBjbGFzcyBMQUJFTCBpcyBhbHJlYWR5IGxvYWRlZC4N ClpGUyBmaWxlc3lzdGVtIHZlcnNpb24gNg0KWkZTIHN0b3JhZ2UgcG9vbCB2 ZXJzaW9uIDYNCmF0YTAtc2xhdmU6IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRt YT1VRE1BMTMzIGNhYmxlPTgwIHdpcmUNCmF0YTAtbWFzdGVyOiBwaW89UElP NCB3ZG1hPVdETUEyIHVkbWE9VURNQTEzMyBjYWJsZT04MCB3aXJlDQphZDA6 IHNldHRpbmcgUElPNCBvbiBuRm9yY2UgTUNQNTUgY2hpcA0KYWQwOiBzZXR0 aW5nIFVETUExMzMgb24gbkZvcmNlIE1DUDU1IGNoaXANCmFkMDogMjM5Mzcy TUIgPE1heHRvciA2WTI1MFAwIFlBUjQxQlcwPiBhdCBhdGEwLW1hc3RlciBV RE1BMTMzDQphZDA6IDQ5MDIzNDc1MiBzZWN0b3JzIFs0ODYzNDRDLzE2SC82 M1NdIDE2IHNlY3RvcnMvaW50ZXJydXB0IDEgZGVwdGggcXVldWUNCkdFT006 IG5ldyBkaXNrIGFkMA0KYWQwOiBuVmlkaWEgY2hlY2sxIGZhaWxlZA0KYWQw OiBBZGFwdGVjIGNoZWNrMSBmYWlsZWQNCmFkMDogTFNJICh2MykgY2hlY2sx IGZhaWxlZA0KYWQwOiBMU0kgKHYyKSBjaGVjazEgZmFpbGVkDQphZDA6IEZy ZWVCU0QgY2hlY2sxIGZhaWxlZA0KYWQxOiBzZXR0aW5nIFBJTzQgb24gbkZv ckdFT01fTUlSUk9SOiBEZXZpY2UgbWlycm9yL2dtMCBsYXVuY2hlZCAoMS8x KS4NCmNlIE1DUDU1IGNoaXANCmFkMTogc2V0dGluZyBVRE1BMTMzIG9uIG5G b3JjZSBNQ1A1NSBjaGlwDQphZDE6IDMyMjUzTUIgPE1heHRvciA2TDIwMFAw IEJBSjQxRzIwPiBhdCBhdGEwLXNsYXZlIFVETUExMzMNCmFkMTogNjYwNTUy NDggc2VjdG9ycyBbNjU1MzFDLzE2SC82M1NdIDE2IHNlY3RvcnMvaW50ZXJy dXB0IDEgZGVwdGggcXVldWUNCmFkMTogblZpZGlhIGNoZWNrMSBmYWlsZWQN CmFkMTogQWRhcHRlYyBjaGVjazEgZmFpbGVkDQphZDE6IExTSSAodjMpIGNo ZWNrMSBmYWlsZWQNCmFkMTogTFNJICh2MikgY2hlY2sxIGZhaWxlZA0KYWQx OiBGcmVlQlNEIGNoZWNrMSBmYWlsZWQNCmF0YTItbWFzdGVyOiBwaW89UElP NCB3ZG1hPVdETUEyIHVkbWE9VURNQTEzMyBjYWJsZT00MCB3aXJlDQphZDQ6 IDQ3Njk0ME1CIDxXREMgV0Q1MDAwQUFLUy0yMlRNQTAgMTIuMDFDMDE+IGF0 IGF0YTItbWFzdGVyIFNBVEEzMDANCmFkNDogOTc2NzczMTY4IHNlY3RvcnMg Wzk2OTAyMUMvMTZILzYzU10gMTYgc2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0 aCBxdWV1ZQ0KR0VPTTogbmV3IGRpc2sgYWQxDQpHRU9NOiBuZXcgZGlzayBh ZDQNCmFkNDogblZpZGlhIGNoZWNrMSBmYWlsZWQNCmFkNDogQWRhcHRlYyBj aGVjazEgZmFpbGVkDQphZDQ6IExTSSAodjMpIGNoZWNrMSBmYWlsZWQNCmFk NDogTFNJICh2MikgY2hlY2sxIGZhaWxlZA0KYWQ0OiBGcmVlQlNEIGNoZWNr MSBmYWlsZWQNCmF0YTM6IHJlaW5pdGluZyBjaGFubmVsIC4uDQphdGEzOiBT QVRBIGNvbm5lY3QgdGltZT0wbXMNCmF0YTM6IHJlc2V0IHRwMSBtYXNrPTAx IG9zdGF0MD01OCBvc3RhdDE9MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDANCmF0YTM6IHJlc2V0IHRwMiBzdGF0MD1k OCBzdGF0MT0wMCBkZXZpY2VzPTB4MA0KYXRhMzogcmVpbml0IGRvbmUgLi4N CnVua25vd246IHRpbWVvdXQgd2FpdGluZyB0byBpc3N1ZSBjb21tYW5kDQp1 bmtub3duOiBlcnJvciBpc3N1aW5nIEFUQV9JREVOVElGWSBjb21tYW5kDQpB VEEgUHNldWRvUkFJRCBsb2FkZWQNClNNUDogQVAgQ1BVICMxIExhdW5jaGVk IQ0KY3B1MSBBUDoNCiAgICAgSUQ6IDB4MDEwMDAwMDAgICBWRVI6IDB4ODAw NTAwMTAgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZg0KICBsaW50 MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4MDAwMDAw MDAgU1ZSOiAweDAwMDAwMWZmDQogIHRpbWVyOiAweDAwMDIwMGVmIHRoZXJt OiAweDAwMDEwMDAwIGVycjogMHgwMDAxMDAwMCBwY206IDB4MDAwMTAwMDAN CmlvYXBpYzA6IEFzc2lnbmluZyBJU0EgSVJRIDEgdG8gbG9jYWwgQVBJQyAw DQppb2FwaWMwOiBBc3NpZ25pbmcgSVNBIElSUSA0IHRvIGxvY2FsIEFQSUMg MQ0KaW9hcGljMDogQXNzaWduaW5nIElTQSBJUlEgNyB0byBsb2NhbCBBUElD IDANCmlvYXBpYzA6IEFzc2lnbmluZyBJU0EgSVJRIDkgdG8gbG9jYWwgQVBJ QyAxDQppb2FwaWMwOiBBc3NpZ25pbmcgSVNBIElSUSAxNCB0byBsb2NhbCBB UElDIDANCmlvYXBpYzA6IEFzc2lnbmluZyBJU0EgSVJRIDE1IHRvIGxvY2Fs IEFQSUMgMQ0KaW9hcGljMDogQXNzaWduaW5nIFBDSSBJUlEgMTYgdG8gbG9j YWwgQVBJQyAwDQppb2FwaWMwOiBBc3NpZ25pbmcgUENJIElSUSAyMCB0byBs b2NhbCBBUElDIDENCmlvYXBpYzA6IEFzc2lnbmluZyBQQ0kgSVJRIDIyIHRv IGxvY2FsIEFQSUMgMA0KaW9hcGljMDogQXNzaWduaW5nIFBDSSBJUlEgMjMg dG8gbG9jYWwgQVBJQyAxDQptc2k6IEFzc2lnbmluZyBNU0ktWCBJUlEgMjU2 IHRvIGxvY2FsIEFQSUMgMA0KbXNpOiBBc3NpZ25pbmcgTVNJLVggSVJRIDI1 NyB0byBsb2NhbCBBUElDIDENCm1zaTogQXNzaWduaW5nIE1TSS1YIElSUSAy NTggdG8gbG9jYWwgQVBJQyAwDQptc2k6IEFzc2lnbmluZyBNU0ktWCBJUlEg MjU5IHRvIGxvY2FsIEFQSUMgMQ0KbXNpOiBBc3NpZ25pbmcgTVNJLVggSVJR IDI2MCB0byBsb2NhbCBBUElDIDANCm1zaTogQXNzaWduaW5nIE1TSS1YIElS USAyNjEgdG8gbG9jYWwgQVBJQyAxDQptc2k6IEFzc2lnbmluZyBNU0ktWCBJ UlEgMjYyIHRvIGxvY2FsIEFQSUMgMA0KbXNpOiBBc3NpZ25pbmcgTVNJLVgg SVJRIDI2MyB0byBsb2NhbCBBUElDIDENCm1zaTogQXNzaWduaW5nIE1TSS1Y IElSUSAyNjQgdG8gbG9jYWwgQVBJQyAwDQptc2k6IEFzc2lnbmluZyBNU0kt WCBJUlEgMjY1IHRvIGxvY2FsIEFQSUMgMQ0KbXNpOiBBc3NpZ25pbmcgTVNJ LVggSVJRIDI2NiB0byBsb2NhbCBBUElDIDANCm1zaTogQXNzaWduaW5nIE1T SS1YIElSUSAyNjcgdG8gbG9jYWwgQVBJQyAxDQptc2k6IEFzc2lnbmluZyBN U0ktWCBJUlEgMjY4IHRvIGxvY2FsIEFQSUMgMA0KbXNpOiBBc3NpZ25pbmcg TVNJLVggSVJRIDI2OSB0byBsb2NhbCBBUElDIDENCm1zaTogQXNzaWduaW5n IE1TSS1YIElSUSAyNzAgdG8gbG9jYWwgQVBJQyAwDQptc2k6IEFzc2lnbmlu ZyBNU0ktWCBJUlEgMjcxIHRvIGxvY2FsIEFQSUMgMQ0KV0FSTklORzogV0lU TkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFu Y2UuDQpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHpmczp0YW5rL3Jvb3QN Cg0KTWFudWFsIHJvb3QgZmlsZXN5c3RlbSBzcGVjaWZpY2F0aW9uOg0KICA8 ZnN0eXBlPjo8ZGV2aWNlPiAgTW91bnQgPGRldmljZT4gdXNpbmcgZmlsZXN5 c3RlbSA8ZnN0eXBlPg0KICAgICAgICAgICAgICAgICAgICAgICBlZy4gdWZz OmRhMHMxYQ0KICA/ICAgICAgICAgICAgICAgICAgTGlzdCB2YWxpZCBkaXNr IGJvb3QgZGV2aWNlcw0KICA8ZW1wdHkgbGluZT4gICAgICAgQWJvcnQgbWFu dWFsIGlucHV0DQoNCm1vdW50cm9vdD4gdWZzIFxeSCBcXkg6bWlycm9yL2dt MGENClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOm1pcnJvci9nbTBh DQpzdGFydF9pbml0OiB0cnlpbmcgL3NiaW4vaW5pdA0Kc3BsYXNoOiBpbWFn ZSBkZWNvZGVyIGZvdW5kOiBsb2dvX3NhdmVyDQpUQ1A6IFs4Ny4xOTQuMC42 OF06MjUgdG8gWzE5Mi4xNjguMS4yXTo2MDkzMCB0Y3BmbGFncyAweDE4PFBV U0gsQUNLPjsgdGNwX2RvX3NlZ21lbnQ6IEZJTl9XQUlUXzE6IFJlY2VpdmVk IGRhdGEgYWZ0ZXIgc29ja2V0IHdhcyBjbG9zZWQsIHNlbmRpbmcgUlNUIGFu ZCByZW1vdmluZyB0Y3BjYg0KDQo= --0-1376663942-1187457978=:75076-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 18 22:17:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 958DD16A419; Sat, 18 Aug 2007 22:17:33 +0000 (UTC) (envelope-from anrays@gmail.com) Received: from mail.matrix.farlep.net (mail.matrix.farlep.net [217.146.241.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4700E13C480; Sat, 18 Aug 2007 22:17:33 +0000 (UTC) (envelope-from anrays@gmail.com) Received: from santinel.home.ua (senser.ppp.matrix.private [10.64.37.183]) by mail.matrix.farlep.net with ESMTP id 1IMVUZ-0004r6-GF; Sun, 19 Aug 2007 00:05:55 +0300 Received: from anray by santinel.home.ua with local (Exim 4.67; FreeBSD) id 1IMVVj-00018K-SW; Sun, 19 Aug 2007 00:07:07 +0300 To: Ken Yamada References: <1186303666.36623.23.camel@tobias.wg.> <20070815144804.GC5151@misty.eyesbeyond.com> <20070818.213208.74754361.ken@tydfam.jp> Organization: Santinel From: Andrey Slusar Date: Sun, 19 Aug 2007 00:07:07 +0300 In-Reply-To: <20070818.213208.74754361.ken@tydfam.jp> (Ken Yamada's message of "Sat, 18 Aug 2007 21:32:08 +0900 (JST)") Message-ID: <864piweemc.fsf@santinel.home.ua> User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.5-b28 (i386--freebsd) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Spam-Report: Content analysis details: (0.0 points, 5.0 required, autolearn: no) pts rule name description ---- ---------------------- -------------------------------------------------- X-Mailman-Approved-At: Sat, 18 Aug 2007 22:24:17 +0000 Cc: glewis@eyesbeyond.com, lists_freebsd_org@07.antispam.web-wahnsinn.de, freebsd-current@freebsd.org, freebsd-java@freebsd.org Subject: Re: Gcc bugs break java/jdk15 build? [Workaround] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2007 22:17:33 -0000 Sat, 18 Aug 2007 21:32:08 +0900 (JST), Ken Yamada wrote: > GCC 4.2.1 alone did not solve the compilation problem on -current, but with -fno-tree-vrp compilation went without any problem. > I added -fno-tree-vrp to CFLAGS in /etc/make.conf, and jdk15/jdk16 compilationwent successfull. Mee too: uname -a FreeBSD santinel.home.ua 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Tue Aug 14 21:41:54 EEST 2007 anray@santinel.home.ua:/usr/obj/usr/src/sys/ANRAY i386 java -version java version "1.5.0_12-p6" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-p6-root_16_aug_2007_20_47) Java HotSpot(TM) Server VM (build 1.5.0_12-p6-root_16_aug_2007_20_47, mixed mode) -- Regards, Andrey.