From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 01:49:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 656A6106566B for ; Sun, 18 Apr 2010 01:49:37 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id F1F698FC1D for ; Sun, 18 Apr 2010 01:49:36 +0000 (UTC) Received: by wwa36 with SMTP id 36so2337912wwa.13 for ; Sat, 17 Apr 2010 18:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:from:date :x-google-sender-auth:received:message-id:subject:to:content-type; bh=zi6n/rJJSK8E8D0pDqDSphOzDOWja6zlIgPg/jee2Ds=; b=e6InznUFcw71EGHYeO9RjaxwkZ6uBfv0dFBBREkV7fIeViii+pOVsDgTXJZaU2Gmy+ K5sPs8FYy0B5gGd3BMUyDrRUZuqlaWZUZwoHCOShKscv8l17gE8r6haULpnrnHHf8oBP Zyy/y8oFAJXY97f6KupLmiscIHyjKYoaU5ObA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=JCuBdiNIJvzR8oYZ2+xPmQ2TAtnEmr0zRHLGLvRS22AIcXR+BV+WIELSXcYSb6ITBv MQ3ZLeB1V8CYQx90nBSzIMuL9lyQHuqGWEgtjsmquISUvDiFMS3sKdvaAnCzOnW8yGSE 1QVAUuJTNMsrpQD2TckfzOIyS/UlP9k0STQDY= MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.216.230.134 with HTTP; Sat, 17 Apr 2010 18:49:14 -0700 (PDT) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sun, 18 Apr 2010 03:49:14 +0200 X-Google-Sender-Auth: 454e5932af22b922 Received: by 10.216.89.202 with SMTP id c52mr4766926wef.84.1271555374110; Sat, 17 Apr 2010 18:49:34 -0700 (PDT) Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: iwn firmware instability with an up-to-date stable kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 01:49:37 -0000 Hi, I meet instability with an up-to-date stable 8 kernel and iwn drivers: About twice a day, my wireless connection hang and I've this error message in dmesg: firmware error log: error type = "NMI_INTERRUPT_WDG" (0x00000004) program counter = 0x0000046C source line = 0x000000D0 error data = 0x0000000207030000 branch link = 0x000050F2000004C2 interrupt link = 0x000006DE000018B8 time = 2103860338 driver status: tx ring 0: qid=0 cur=19 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=2 queued=0 tx ring 4: qid=4 cur=234 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 rx ring: cur=52 Does anyone meet the same problem ? More information about my kernel and device (Dell Latitude D630): uname -a FreeBSD d630.bsdrp.net 8.0-STABLE FreeBSD 8.0-STABLE #66: Tue Apr 13 02:16:26 CEST 2010 root@d630.bsdrp.net:/usr/obj/usr/src/sys/DellD630 amd64 dmesg iwn0: mem 0xf6cfe000-0xf6cfffff irq 17 at device 0.0 on pci12 iwn0: MIMO 2T3R, MoW2, address 00:1d:e0:72:10:01 iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps pciconf iwn0@pci0:12:0:0: class=0x028000 card=0x11218086 chip=0x42298086 rev=0x61 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Wireless WiFi Link 4965AGN(supporting 802.11a/b/g/Draft-N) (Intel 4965AGN)' class = network Thanks, Olivier From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 08:14:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A224106564A for ; Sun, 18 Apr 2010 08:14:03 +0000 (UTC) (envelope-from bschmidt@mx.techwires.net) Received: from mx.techwires.net (mx.techwires.net [IPv6:2001:4d88:100f:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id C09F38FC0C for ; Sun, 18 Apr 2010 08:14:02 +0000 (UTC) Received: by mx.techwires.net (Postfix, from userid 1001) id 18D6226CE9; Sun, 18 Apr 2010 10:14:01 +0200 (CEST) Date: Sun, 18 Apr 2010 10:14:01 +0200 From: Bernhard Schmidt To: Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= Message-ID: <20100418081400.GA40496@mx.techwires.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: iwn firmware instability with an up-to-date stable kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 08:14:03 -0000 On Sun, Apr 18, 2010 at 03:49:14AM +0200, Olivier Cochard-Labbé wrote: > Hi, > > I meet instability with an up-to-date stable 8 kernel and iwn drivers: > About twice a day, my wireless connection hang and I've this error > message in dmesg: > > firmware error log: > error type = "NMI_INTERRUPT_WDG" (0x00000004) > program counter = 0x0000046C > source line = 0x000000D0 >[..] > > Does anyone meet the same problem ? I've seen this error a few times, even Intel knows about it: http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1965 Issue is that there is no known workaround. Are you able to reproduce this on demand? As in type a few commands and the firmware error occurs? -- Bernhard From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 10:20:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D77CE106566B for ; Sun, 18 Apr 2010 10:20:27 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 674158FC14 for ; Sun, 18 Apr 2010 10:20:26 +0000 (UTC) Received: by wyf28 with SMTP id 28so645235wyf.13 for ; Sun, 18 Apr 2010 03:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=qjihTrkNFXQ6UYftTMbu2XqKSrnAOr4IqMZc4FOqi6A=; b=l/iUHbIeQUk5g43bfTZG7bUaWT93yVHg+pPvfLoCYcxRmZ6iZ3zAFk6GYm0qJuYq9Z uC5UUSiMS72PX11pwL5MpTsRacw+4D3ytHnqcpg17fr7jKPrL6TxG4kpyfQZgjHQ025H hyXU235T+YxocFFe3XoLgxnGkJevPupS1YqAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fU9QFbSbQ5+KwMIKGH8So40P5eyGQQpRnE3+wXXf8XJiSk2orrdjA17dBf1pUuJBeY Ogpe7CCX4PMd2VZHnZ4kTt5yvIyY78LTp7sFOkRkR3JUwgfvugyvVhRbNW7Djx6j0cn/ VB369oQVj4JdsigXBhxJdZmPtUP6fpPh8swrw= MIME-Version: 1.0 Received: by 10.216.49.76 with HTTP; Sun, 18 Apr 2010 03:20:26 -0700 (PDT) In-Reply-To: <20100414103054.GA2460@cemu.ru> References: <20100414103054.GA2460@cemu.ru> Date: Sun, 18 Apr 2010 10:20:26 +0000 Received: by 10.216.86.3 with SMTP id v3mr74828wee.190.1271586026225; Sun, 18 Apr 2010 03:20:26 -0700 (PDT) Message-ID: From: Paul B Mahol To: Lystopad Olexandr Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: ath0: kernel panic when adhoc mode. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 10:20:28 -0000 On 4/14/10, Lystopad Olexandr wrote: > Hi! > > I install 8.0 FreeBSD, upgrade it to yesturday stable. > I need to create wireless link in adhoc mode. > Help me to do this. > > > I put a wireless card into this box: > > ath0@pci0:3:3:0: class=0x020000 card=0xcc2114b9 chip=0x0013168c > rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = '802.11a/b/g Wireless Adapter (AR5212)' > class = network > subclass = ethernet > cap 01[44] = powerspec 2 supports D0 D3 current D0 > > > > when I do: > # ifconfig wlan0 create wlandev ath0 wlanmode adhoc > > server reboot with kernel panic: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0xffff > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0791612 > stack pointer = 0x28:0xd2f42ba4 > frame pointer = 0x28:0xd2f42bac > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (ath0 taskq) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 3m35s > Physical memory: 439 MB > Dumping 80 MB: 65 49 33panic: bufwrite: buffer is not busy??? > cpuid = 1 > 17 1 > > #0 doadump () at pcpu.h:246 > 246 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:246 > #1 0xc06b3497 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xc06b3789 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:579 > #3 0xc08b63bc in trap_fatal (frame=0xd2f42b64, eva=65535) > at /usr/src/sys/i386/i386/trap.c:938 > #4 0xc08b6620 in trap_pfault (frame=0xd2f42b64, usermode=0, eva=65535) > at /usr/src/sys/i386/i386/trap.c:851 > #5 0xc08b6f39 in trap (frame=0xd2f42b64) at > /usr/src/sys/i386/i386/trap.c:533 > #6 0xc0899b3b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > #7 0xc0791612 in ieee80211_getcapinfo (vap=0xc2d5f000, chan=0xffff) > at /usr/src/sys/net80211/ieee80211_output.c:1836 > #8 0xc0793d17 in ieee80211_beacon_construct (m=0xc2edca00, > frm=0xc2f0516e "", bo=0xc2d5f884, ni=0xc2ceb000) > at /usr/src/sys/net80211/ieee80211_output.c:2559 > #9 0xc07946db in ieee80211_beacon_alloc (ni=0xc2ceb000, bo=0xc2d5f884) > at /usr/src/sys/net80211/ieee80211_output.c:2756 > #10 0xc050eaea in ath_newstate (vap=0xc2d5f000, nstate=IEEE80211_S_RUN, > arg=-1) at /usr/src/sys/dev/ath/if_ath.c:2641 > #11 0xc0798db1 in ieee80211_newstate_cb (xvap=0xc2d5f000, npending=3) > at /usr/src/sys/net80211/ieee80211_proto.c:1654 > #12 0xc06ebf92 in taskqueue_run (queue=0xc2a84c80) > at /usr/src/sys/kern/subr_taskqueue.c:239 > #13 0xc06ec19d in taskqueue_thread_loop (arg=0xc2ada074) > at /usr/src/sys/kern/subr_taskqueue.c:360 > #14 0xc068a331 in fork_exit (callout=0xc06ec0e0 , > arg=0xc2ada074, frame=0xd2f42d38) at /usr/src/sys/kern/kern_fork.c:843 > #15 0xc0899bb0 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:270 > (kgdb) > This is bug, please report it ASAP. > > > > dmesg is: > > Copyright (c) 1992-2010 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 8.0-STABLE #0: Wed Apr 14 07:45:45 MSD 2010 > root@serv01:/usr/obj/usr/src/sys/serv01 i386 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2194.76-MHz 686-class > CPU) > Origin = "AuthenticAMD" Id = 0x40fb2 Family = f Model = 4b Stepping = > 2 > > Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x1f > real memory = 536870912 (512 MB) > avail memory = 449187840 (428 MB) > ACPI APIC Table: <050407 APIC1334> > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: <050407 RSDT1334> on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of fee00000, 1000 (3) failed > acpi0: reservation of ffb80000, 80000 (3) failed > acpi0: reservation of fff80000, 80000 (3) failed > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 1bf00000 (3) failed > ACPI HPET table warning: Sequence is non-zero (2) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0xc000-0xc0ff mem > 0xf8000000-0xfbffffff,0xfe7f0000-0xfe7fffff,0xfe600000-0xfe6fffff irq 18 at > device 5.0 on pci1 > pcib2: at device 7.0 on pci0 > pci2: on pcib2 > re0: port 0xd800-0xd8ff > mem 0xfe8ff000-0xfe8fffff irq 19 at device 0.0 on pci2 > re0: Using 1 MSI messages > re0: Chip rev. 0x34000000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > rlphy0: PHY 1 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > re0: Ethernet address: 00:19:db:65:31:df > re0: [FILTER] > atapci0: port > 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem > 0xfe5ff800-0xfe5ffbff irq 22 at device 1 > 8.0 on pci0 > atapci0: [ITHREAD] > atapci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported > ata2: on atapci0 > ata2: port is not ready (timeout 0ms) tfd = 000001d0 > ata2: software reset clear timeout > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > ata4: on atapci0 > ata4: [ITHREAD] > ata5: on atapci0 > ata5: [ITHREAD] > ohci0: mem 0xfe5fe000-0xfe5fefff irq 16 at > device 19.0 on pci0 > ohci0: [ITHREAD] > usbus0: on ohci0 > ohci1: mem 0xfe5fd000-0xfe5fdfff irq 17 at > device 19.1 on pci0 > ohci1: [ITHREAD] > usbus1: on ohci1 > ohci2: mem 0xfe5fc000-0xfe5fcfff irq 18 at > device 19.2 on pci0 > ohci2: [ITHREAD] > usbus2: on ohci2 > ohci3: mem 0xfe5fb000-0xfe5fbfff irq 17 at > device 19.3 on pci0 > ohci3: [ITHREAD] > usbus3: on ohci3 > ohci4: mem 0xfe5fa000-0xfe5fafff irq 18 at > device 19.4 on pci0 > ohci4: [ITHREAD] > usbus4: on ohci4 > ehci0: mem 0xfe5ff000-0xfe5ff0ff irq 19 > at device 19.5 on pci0 > ehci0: [ITHREAD] > ehci0: AMD SB600/700 quirk applied > usbus5: EHCI version 1.0 > usbus5: on ehci0 > pci0: at device 20.0 (no driver attached) > atapci1: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 > ata0: on atapci1 > ata0: [ITHREAD] > pci0: at device 20.2 (no driver attached) > isab0: at device 20.3 on pci0 > isa0: on isab0 > pcib3: at device 20.4 on pci0 > pci3: on pcib3 > fxp0: port 0xe800-0xe81f mem > 0xfdfff000-0xfdffffff,0xfeb00000-0xfebfffff irq 22 at device 2.0 on pci3 > fxp0: Enabling Rx lock-up workaround > miibus1: on fxp0 > inphy0: PHY 1 on miibus1 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: Ethernet address: 00:08:c7:c9:55:38 > fxp0: [ITHREAD] > ath0: mem 0xfe9f0000-0xfe9fffff irq 21 at device 3.0 on pci3 > ath0: [ITHREAD] > ath0: AR5212 mac 5.9 RF5112 phy 4.3 > acpi_button0: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > pmtimer0 on isa0 > orm0: at iomem 0xcd800-0xce7ff,0xce800-0xcefff pnpid > ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > acpi_throttle0: on cpu0 > acpi_throttle0: CLK_VAL field overlaps THT_EN bit > device_attach: acpi_throttle0 attach returned 6 > powernow0: on cpu0 > device_attach: powernow0 attach returned 6 > powernow1: on cpu1 > device_attach: powernow1 attach returned 6 > Timecounters tick every 1.000 msec > ipfw2 initialized, divert loadable, nat enabled, rule-based forwarding > enabled, default to accept, logging disabled > load_dn_sched dn_sched FIFO loaded > load_dn_sched dn_sched PRIO loaded > load_dn_sched dn_sched QFQ loaded > load_dn_sched dn_sched RR loaded > load_dn_sched dn_sched WF2Q+ loaded > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 12Mbps Full Speed USB v1.0 > usbus4: 12Mbps Full Speed USB v1.0 > usbus5: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ugen4.1: at usbus4 > uhub4: on usbus4 > ugen5.1: at usbus5 > uhub5: on usbus5 > acd0: CDRW at ata0-slave UDMA33 > ad4: 76318MB at ata2-master UDMA100 SATA 1.5Gb/s > SMP: AP CPU #1 Launched! > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub3: 2 ports with 2 removable, self powered > uhub4: 2 ports with 2 removable, self powered > Root mount waiting for: usbus5 > Root mount waiting for: usbus5 > uhub5: 10 ports with 10 removable, self powered > Trying to mount root from ufs:/dev/ad4s1a > WARNING: / was not properly dismounted > wlan0: Ethernet address: 00:40:96:a9:97:8f > > > > -- > Olexandr Lystopad > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 10:21:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C53381065670 for ; Sun, 18 Apr 2010 10:21:29 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 722E18FC1C for ; Sun, 18 Apr 2010 10:21:29 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1O3Rd0-0009lF-Mb; Sun, 18 Apr 2010 13:21:26 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-stable@freebsd.org In-reply-to: References: <20100415104711.GA84922@icarus.home.lan> <20100415111102.GA85532@icarus.home.lan> <20100415122343.GD2415@deviant.kiev.zoral.com.ua> Comments: In-reply-to Daniel Braniss message dated "Fri, 16 Apr 2010 11:44:37 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Apr 2010 13:21:26 +0300 From: Daniel Braniss Message-ID: Cc: Kostik Belousov , Jeremy Chadwick Subject: Re: panic: vm_fault_copy_wired: page missing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 10:21:29 -0000 > > > > > > --QA3RSaXxDkY7tjDy > > > Content-Type: text/plain; charset=us-ascii > > > Content-Disposition: inline > > > Content-Transfer-Encoding: quoted-printable > > > > > > On Thu, Apr 15, 2010 at 02:54:19PM +0300, Daniel Braniss wrote: > > > >=20 > > > > > Take NFS out of the picture if you can... > > > > >=20 > > > > I've been thinking along those lines, and Kostic is convinced > > > > that the problem lies there, so I guess I'll give it a try, but > > > > it's no realy a solution. > > > > > > Better solution is to remove mlock()/mlockall(). > > > > without binaries via NFS there is no panic. > > > > I can't remove mlock()/mlockall() since it's not my program, it's apache > > et.all. > > but, while my knowledge of dtrace is almost zero, I did the next best thing > > and put a printf in mlock/mlockall and they are not being called by userland. > > > > so, it seems the problem is nfs related, calling in the heavy-weights, > > hi rick! > > well, Kostic was right after all. It was am-utils that called mlockall(), > I missed the message first time, commented out the call to mlockall, and the > system is not panicking. > > so there is a problem with mlock and nfs, can this be fixed? is there a pr? > > anyways, thank you all! > > danny I placed amd(am-utils) on local disc, and it still panics - slightly differently: KDB: enter: panic [thread pid 1029 tid 100098 ] Stopped at kdb_enter+0x3d: movq $0,0x68f7a0(%rip) db> tr Tracing pid 1029 tid 100098 td 0xffffff0007502000 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b vm_fault_copy_entry() at vm_fault_copy_entry+0x283 vmspace_fork() at vmspace_fork+0x4d0 fork1() at fork1+0x35f fork() at fork+0x1c syscall() at syscall+0x1e7 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (2, FreeBSD ELF64, fork), rip = 0x8009f41ac, rsp = 0x7fffffffe788, rbp = 0 --- so IMHO, the problem is somewhere in the fact that root is diskless. danny From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 11:57:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E538B106564A for ; Sun, 18 Apr 2010 11:57:15 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 796978FC19 for ; Sun, 18 Apr 2010 11:57:15 +0000 (UTC) Received: by wyf28 with SMTP id 28so668389wyf.13 for ; Sun, 18 Apr 2010 04:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:received:message-id :subject:to:cc:content-type; bh=sKIbxe2YTpRp55EgL9bm2Ug4ndlT/oMXQy8CWXWx/lc=; b=VqeotNtNH7L6BKL+dFd8F8UbToA4xDOztY5vdNN+OEdcibdRd+/Ad40Qk2dN/CoSmD fLJctS1fUqW45bf9YgiUXaPvwxOnWu+v+6YJXgRakvfaxWb1XVw/3dg4njYjZVWb0p75 Zilb1lUnje/94WyG9BADoWqO25BxP3EoLLY7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=hGbkJBR1FOnHDSeoCm5S96c0U25pTzby7yAqS66IzvM6AVXXTzvYld/jBEiT6ICYfD X/BL+ayJ6xmCGBRdgG8uwniVLMAqpqsPGoGsq2LA5wFMubT0bK7LuAzREZMslB0xMQEh kAaFQpJ24TVP0NFzHcuTZXXqd4Y2O1uti/GVo= MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.216.230.134 with HTTP; Sun, 18 Apr 2010 04:56:54 -0700 (PDT) In-Reply-To: <20100418081400.GA40496@mx.techwires.net> References: <20100418081400.GA40496@mx.techwires.net> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sun, 18 Apr 2010 13:56:54 +0200 X-Google-Sender-Auth: 16534aaf5a323d2f Received: by 10.216.89.202 with SMTP id c52mr5411232wef.84.1271591834282; Sun, 18 Apr 2010 04:57:14 -0700 (PDT) Message-ID: To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: iwn firmware instability with an up-to-date stable kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 11:57:16 -0000 2010/4/18 Bernhard Schmidt : > Are you able to reproduce this on demand? As in type a few commands and > the firmware error occurs? > No, I'm not able to reproduce on demand this problem. Regards, Olivier From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 12:44:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62F701065672 for ; Sun, 18 Apr 2010 12:44:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id F04E48FC1F for ; Sun, 18 Apr 2010 12:44:58 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o3ICiJKC097008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Apr 2010 15:44:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o3ICiJVT023586; Sun, 18 Apr 2010 15:44:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o3ICiJ07023585; Sun, 18 Apr 2010 15:44:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 18 Apr 2010 15:44:19 +0300 From: Kostik Belousov To: Daniel Braniss Message-ID: <20100418124419.GX2415@deviant.kiev.zoral.com.ua> References: <20100415104711.GA84922@icarus.home.lan> <20100415111102.GA85532@icarus.home.lan> <20100415122343.GD2415@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SpFw69Q4vVW19Q1W" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: panic: vm_fault_copy_wired: page missing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 12:44:59 -0000 --SpFw69Q4vVW19Q1W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 18, 2010 at 01:21:26PM +0300, Daniel Braniss wrote: > > > >=20 > > > > --QA3RSaXxDkY7tjDy > > > > Content-Type: text/plain; charset=3Dus-ascii > > > > Content-Disposition: inline > > > > Content-Transfer-Encoding: quoted-printable > > > >=20 > > > > On Thu, Apr 15, 2010 at 02:54:19PM +0300, Daniel Braniss wrote: > > > > >=3D20 > > > > > > Take NFS out of the picture if you can... > > > > > >=3D20 > > > > > I've been thinking along those lines, and Kostic is convinced > > > > > that the problem lies there, so I guess I'll give it a try, but > > > > > it's no realy a solution. > > > >=20 > > > > Better solution is to remove mlock()/mlockall(). > > >=20 > > > without binaries via NFS there is no panic. > > >=20 > > > I can't remove mlock()/mlockall() since it's not my program, it's apa= che=20 > > > et.all. > > > but, while my knowledge of dtrace is almost zero, I did the next best= thing > > > and put a printf in mlock/mlockall and they are not being called by u= serland. > > >=20 > > > so, it seems the problem is nfs related, calling in the heavy-weights, > > > hi rick! > >=20 > > well, Kostic was right after all. It was am-utils that called mlockall(= ), > > I missed the message first time, commented out the call to mlockall, an= d the > > system is not panicking. > >=20 > > so there is a problem with mlock and nfs, can this be fixed? is there a= pr? > >=20 > > anyways, thank you all! > >=20 > > danny >=20 > I placed amd(am-utils) on local disc, and it still panics - slightly=20 > differently: >=20 > KDB: enter: panic > [thread pid 1029 tid 100098 ] > Stopped at kdb_enter+0x3d: movq $0,0x68f7a0(%rip) > db> tr > Tracing pid 1029 tid 100098 td 0xffffff0007502000 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x17b > vm_fault_copy_entry() at vm_fault_copy_entry+0x283 > vmspace_fork() at vmspace_fork+0x4d0 > fork1() at fork1+0x35f > fork() at fork+0x1c > syscall() at syscall+0x1e7 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (2, FreeBSD ELF64, fork), rip =3D 0x8009f41ac, rsp =3D 0x7fff= ffffe788,=20 > rbp =3D 0 --- >=20 > so IMHO, the problem is somewhere in the fact that root is diskless. Root on nfs means that e.g. libc is still mapped from nfs mount. --SpFw69Q4vVW19Q1W Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvK/poACgkQC3+MBN1Mb4h3YwCgjHPK3+XV5ptgl7nSk84RQVft 9G8AoOzcp/5+EoqadWlKBeJAfSiNT2q/ =vMwx -----END PGP SIGNATURE----- --SpFw69Q4vVW19Q1W-- From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 14:13:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39B14106566B for ; Sun, 18 Apr 2010 14:13:37 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id D94AC8FC0C for ; Sun, 18 Apr 2010 14:13:36 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1O3VFf-000DK3-8D; Sun, 18 Apr 2010 17:13:35 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Kostik Belousov In-reply-to: <20100418124419.GX2415@deviant.kiev.zoral.com.ua> References: <20100415104711.GA84922@icarus.home.lan> <20100415111102.GA85532@icarus.home.lan> <20100415122343.GD2415@deviant.kiev.zoral.com.ua> <20100418124419.GX2415@deviant.kiev.zoral.com.ua> Comments: In-reply-to Kostik Belousov message dated "Sun, 18 Apr 2010 15:44:19 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Apr 2010 17:13:35 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: panic: vm_fault_copy_wired: page missing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 14:13:37 -0000 > > --SpFw69Q4vVW19Q1W > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Sun, Apr 18, 2010 at 01:21:26PM +0300, Daniel Braniss wrote: > > > > >=20 > > > > > --QA3RSaXxDkY7tjDy > > > > > Content-Type: text/plain; charset=3Dus-ascii > > > > > Content-Disposition: inline > > > > > Content-Transfer-Encoding: quoted-printable > > > > >=20 > > > > > On Thu, Apr 15, 2010 at 02:54:19PM +0300, Daniel Braniss wrote: > > > > > >=3D20 > > > > > > > Take NFS out of the picture if you can... > > > > > > >=3D20 > > > > > > I've been thinking along those lines, and Kostic is convinced > > > > > > that the problem lies there, so I guess I'll give it a try, but > > > > > > it's no realy a solution. > > > > >=20 > > > > > Better solution is to remove mlock()/mlockall(). > > > >=20 > > > > without binaries via NFS there is no panic. > > > >=20 > > > > I can't remove mlock()/mlockall() since it's not my program, it's apa= > che=20 > > > > et.all. > > > > but, while my knowledge of dtrace is almost zero, I did the next best= > thing > > > > and put a printf in mlock/mlockall and they are not being called by u= > serland. > > > >=20 > > > > so, it seems the problem is nfs related, calling in the heavy-weights, > > > > hi rick! > > >=20 > > > well, Kostic was right after all. It was am-utils that called mlockall(= > ), > > > I missed the message first time, commented out the call to mlockall, an= > d the > > > system is not panicking. > > >=20 > > > so there is a problem with mlock and nfs, can this be fixed? is there a= > pr? > > >=20 > > > anyways, thank you all! > > >=20 > > > danny > >=20 > > I placed amd(am-utils) on local disc, and it still panics - slightly=20 > > differently: > >=20 > > KDB: enter: panic > > [thread pid 1029 tid 100098 ] > > Stopped at kdb_enter+0x3d: movq $0,0x68f7a0(%rip) > > db> tr > > Tracing pid 1029 tid 100098 td 0xffffff0007502000 > > kdb_enter() at kdb_enter+0x3d > > panic() at panic+0x17b > > vm_fault_copy_entry() at vm_fault_copy_entry+0x283 > > vmspace_fork() at vmspace_fork+0x4d0 > > fork1() at fork1+0x35f > > fork() at fork+0x1c > > syscall() at syscall+0x1e7 > > Xfast_syscall() at Xfast_syscall+0xe1 > > --- syscall (2, FreeBSD ELF64, fork), rip =3D 0x8009f41ac, rsp =3D 0x7fff= > ffffe788,=20 > > rbp =3D 0 --- > >=20 > > so IMHO, the problem is somewhere in the fact that root is diskless. > > Root on nfs means that e.g. libc is still mapped from nfs mount. argh, forgot about shared libs, so I linked amd static, and it's not panicking, yet ... [amd is in the root nfs]. From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 14:20:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CEBF106566C for ; Sun, 18 Apr 2010 14:20:49 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 185458FC24 for ; Sun, 18 Apr 2010 14:20:46 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1O3VMb-000DNl-C6; Sun, 18 Apr 2010 17:20:45 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Kostik Belousov In-reply-to: References: <20100415104711.GA84922@icarus.home.lan> <20100415111102.GA85532@icarus.home.lan> <20100415122343.GD2415@deviant.kiev.zoral.com.ua> <20100418124419.GX2415@deviant.kiev.zoral.com.ua> Comments: In-reply-to Daniel Braniss message dated "Sun, 18 Apr 2010 17:13:35 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Apr 2010 17:20:45 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: panic: vm_fault_copy_wired: page missing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 14:20:49 -0000 ... > > > so IMHO, the problem is somewhere in the fact that root is diskless. > > > > Root on nfs means that e.g. libc is still mapped from nfs mount. > > argh, forgot about shared libs, so I linked amd static, and it's not panicking, > yet ... [amd is in the root nfs]. it just panicked :-( From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 17:03:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 008351065676 for ; Sun, 18 Apr 2010 17:03:17 +0000 (UTC) (envelope-from mailman@mimimail12.com) Received: from mimimail12.com (mimimail12.com [207.210.122.178]) by mx1.freebsd.org (Postfix) with ESMTP id CB7398FC2C for ; Sun, 18 Apr 2010 17:03:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mimi; d=madmimi.com; h=Date:From:To:Message-Id:Subject:Mime-Version:Content-Type:List-Unsubscribe; bh=8AwTJMmWJ2TXOaJaUKOwQXVlpg0=; b=QZk3IyRH4NkpCiWHYjj7nsKZgKhFt8z7zdMeWfymNtNprtK/l6audfw4UM9MvR5EkLdick0K4SfH 6CBPpTtnnaX8cNKsQSrHN77NWaevP1n4bPHsQLg14n8Ho+0Z2dhI+tj+fyOlW6sRx/buVa2yU2R+ QD9Bii/Uv0gZ9UuHXRs= Received: from mimimail12.com (207.210.123.235) by mimimail12.com (PowerMTA(TM) v3.5r15) id hpctl80t3cg6 for ; Sun, 18 Apr 2010 12:35:59 -0400 (envelope-from ) Date: Sun, 18 Apr 2010 12:35:59 -0400 From: YNV Records To: freebsd-stable@freebsd.org Message-Id: <4bcb34ef9ea3c_2a5e4ef893c719c4@worker2.gldl.railsmachina.com.tmail> Mime-Version: 1.0 Mimiaid: 958917923 Precendence: bulk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: Quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Ynv Records Presents X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 17:03:17 -0000 Since 2003, the latino community, along with other races, have been enjoy= ing a different type of music thanks to D.R-FLOW. The Group , which is co= mprised of 2 very talented youths , Ezequiel Rodriguez and Manuel Vasquez= , represent Dominicans, in and out of the Dominican Republic in a big way= . Ever since the very beginnings of the group, these bright and talented yo= ung men have received the love and support of, not only the latino popula= tion, but also other races all over the world . Their music reaches from = the streets of New York, to the hearts of many in South America, Europe, = and beyond!!! They are well-recieved where ever they go because of the di= versity of their music, from hip-hop to r&b, fans get the opportunity to = take away a little bit of every genre of music known today. For More info Regarding Drops, jingle Interviews Or For bookings = 413-363-4388 Moe View this email on the web here: http://mim.io/e9d53?fe=3D1&pact=3D958917923 Unsubscribe: http://go.madmimi.com/opt_out?fe=3D1&pact=3D958917923&amx=3D224345343 You can also forward to a friend: http://go.madmimi.com/forward/958917923?amx=3D224345343 YNV Records | Boston Ma 02128 From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 17:03:17 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7FC11065677 for ; Sun, 18 Apr 2010 17:03:17 +0000 (UTC) (envelope-from mailman@mimimail12.com) Received: from mimimail12.com (mimimail12.com [207.210.122.178]) by mx1.freebsd.org (Postfix) with ESMTP id 7F9BD8FC0C for ; Sun, 18 Apr 2010 17:03:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mimi; d=madmimi.com; h=Date:From:To:Message-Id:Subject:Mime-Version:Content-Type:List-Unsubscribe; bh=ArquvEpxsZqYPCqUEQ14y3Rzspo=; b=OigPBRB1AmTfNWzCqkOUxSNH2EwBQ0bhPPPB7PzlNxpDQTlYXqFsPH+1XR0na2DA23QNRHEAJdVh hEyK0neiR7qpOZSfUb8NE+Vh29op5DlY2H4YvgCi4trASdagrtqFMkUa+4zE4sKMlZqDzhJwPx31 OXixAvvDhc/PDHH8aWk= Received: from mimimail12.com (75.127.77.162) by mimimail12.com (PowerMTA(TM) v3.5r15) id hpctla0t3cg4 for ; Sun, 18 Apr 2010 12:37:38 -0400 (envelope-from ) Date: Sun, 18 Apr 2010 12:37:38 -0400 From: YNV Records To: stable@freebsd.org Message-Id: <4bcb355214634_2e3e6c46930701c2@worker4.gldl.railsmachina.com.tmail> Mime-Version: 1.0 Mimiaid: 958923032 Precendence: bulk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: Quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Ynv Records Presents X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 17:03:17 -0000 Since 2003, the latino community, along with other races, have been enjoy= ing a different type of music thanks to D.R-FLOW. The Group , which is co= mprised of 2 very talented youths , Ezequiel Rodriguez and Manuel Vasquez= , represent Dominicans, in and out of the Dominican Republic in a big way= . Ever since the very beginnings of the group, these bright and talented yo= ung men have received the love and support of, not only the latino popula= tion, but also other races all over the world . Their music reaches from = the streets of New York, to the hearts of many in South America, Europe, = and beyond!!! They are well-recieved where ever they go because of the di= versity of their music, from hip-hop to r&b, fans get the opportunity to = take away a little bit of every genre of music known today. For More info Regarding Drops, jingle Interviews Or For bookings = 413-363-4388 Moe View this email on the web here: http://mim.io/e9d53?fe=3D1&pact=3D958923032 Unsubscribe: http://go.madmimi.com/opt_out?fe=3D1&pact=3D958923032&amx=3D224345464 You can also forward to a friend: http://go.madmimi.com/forward/958923032?amx=3D224345464 YNV Records | Boston Ma 02128 From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 21:37:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 102861065670 for ; Sun, 18 Apr 2010 21:37:30 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id B2BCF8FC08 for ; Sun, 18 Apr 2010 21:37:29 +0000 (UTC) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta08.westchester.pa.mail.comcast.net with comcast id 79ZV1e0050cZkys589dVU8; Sun, 18 Apr 2010 21:37:29 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta10.westchester.pa.mail.comcast.net with comcast id 79dU1e00C3S48mS3W9dVwe; Sun, 18 Apr 2010 21:37:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7FAF19B419; Sun, 18 Apr 2010 14:37:27 -0700 (PDT) Date: Sun, 18 Apr 2010 14:37:27 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100418213727.GA98129@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 21:37:30 -0000 I'd like to discuss the possibility of introduction of a new script into /etc/rc.d base system a script, which when enabled, would provide a way to wait until the IP networking layer (using ping(8)) is up and usable before continuing with daemon startup. I've written a script that's in use on all of our RELENG_8 systems (I have not tested RELENG_7) which works reliably; I'll include that script at the bottom of my mail, and also a link to it[1]. Let's discuss. :-) HISTORY ========= The situation which brought this debacle to my attention: I found that on reboot of some of our systems, ntpdate (used to sync the clock initially before ntpd would be started) wouldn't work. The daemon would report that it couldn't resolve any of the FQDNs within ntp.conf, and would therefore act as a no-op before continuing on. This failure had dire consequences -- Dovecot (at least with older versions; newer seems to behave better[2]) would refuse to start up, citing "time moved backwards". Dovecot not starting had a trick-down effect on Postfix (which was compiled to use Dovecot for SMTP AUTH), where Postfix would start but all inbound mail would fail due to Dovecot's SMTP AUTH mech not listening on a domain socket. Ouch. Since DNS failure was the root issue, I dug around rc.d/named and found that Doug had introduced a feature to rc.d/named called "named_wait" which calls "host $named_wait_host" repetitively (sleeping 1 second between calls), waiting until successful resolution before continuing onwards. This worked (e.g. set named_wait_host to "www.google.com" or something Internet-bound). However, named itself still complains during startup about "host unreachable resolving XXX messages" with regards to the root servers. These errors were visible in logs, etc... and could cause confusion or unnecessary worry (they did in my case). The root cause should be fairly obvious: the physical networking layer hadn't fully come up by the time named had started. In other cases, the physical network was available but layer 2 (ARP) hadn't finished. So I wrote this. USE ===== 1) Install script as /usr/local/etc/rc.d/waitnetwork 2) chmod 755 /usr/local/etc/rc.d/waitnetwork 3) Set the following in rc.conf: waitnetwork_enable="yes" waitnetwork_ip="some_ip_addr_to_ping" Note that this does need to be an IP address and *not* an FQDN. I've discussed this reasoning with some others and they agree. Don't pick something like 127.0.0.1 either (meaning don't be silly). :-) Other parameters you can adjust: waitnetwork_count -- passed as ping(8) -c flag (default 5) waitnetwork_timeout -- passed as ping(8) -t flag (default 60) CAVEATS / POINTS OF INTEREST ============================== 1) This script requires the $waitnetwork_ip box/router/whatever respond to ICMP ECHO requests. Please do not bikeshed on this point; we need something that works, and this requirement shouldn't be that bad to deal with (firewall/ACL-wise). For most folks (co-located in particular), this could be your default gateway, but you can use whatever you want. 2) The needs of some folks may vary depending upon configuration; "we have two NICs, dual-homed, so what exactly do I put in waitnetwork_ip?" Yes, I understand the confusion -- hopefully these folks, given their topologies, can figure out a way to make this work reliably for them. 3) Other stuff I probably haven't thought of. For those considering arguing that "we should just wait for the NIC to come up", that won't work -- what's needed is a way to verify layer 3/4 is usable, not layer 1. I admit there's no universal way to cover every single person's needs, but providing a simple framework to at least wait until something is pingable would be a good starting point; it's better than nothing! NOTES BEFORE COMMITTING ========================= The script also contains some XXX comments which should be reviewed by anyone willing to commit this into the base system. REFERENCES ============ [1]: http://jdc.parodius.com/freebsd/waitnetwork [2]: http://wiki.dovecot.org/TimeMovedBackwards -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | #!/bin/sh # # $FreeBSD: $ # # PROVIDE: waitnetwork # REQUIRE: NETWORKING # BEFORE: mountcritremote # KEYWORD: nojail # XXX - once/if committed to base, it's better to have mountcritremote # XXX - REQUIRE waitnetwork, rather than use the above BEFORE line. . /etc/rc.subr name="waitnetwork" rc_var=`set_rcvar` start_cmd="waitnetwork_start" stop_cmd=":" # XXX - once/if committed to base, the following defaults should # XXX - be placed into src/etc/defaults/rc.conf instead of here waitnetwork_enable="NO" # Wait for network availability before # continuing with NETWORKING rc scripts waitnetwork_ip="" # IP address to ping waitnetwork_count="5" # ping count (see ping(8) -c flag) waitnetwork_timeout="60" # ping timeout (see ping(8) -t flag) waitnetwork_start() { local rc if [ -z "${waitnetwork_ip}" ]; then warn "You must define an IP address in waitnetwork_ip" return fi echo "Waiting for ${waitnetwork_ip} to respond to ICMP..." if [ -z "${waitnetwork_timeout}" ]; then /sbin/ping -c ${waitnetwork_count} ${waitnetwork_ip} >/dev/null 2>&1 rc=$? else info "Using timeout of ${waitnetwork_timeout} seconds" /sbin/ping -t ${waitnetwork_timeout} -c ${waitnetwork_count} ${waitnetwork_ip} >/dev/null 2>&1 rc=$? fi if [ $rc -eq 0 ]; then echo "Host reachable; network considered available." else echo "No response from IP. Continuing, but be aware you may not" echo "have a fully functional networking layer at this point." fi } load_rc_config $name run_rc_command "$1" From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 23:24:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45E021065670 for ; Sun, 18 Apr 2010 23:24:23 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas01p.mx.bigpond.com (nschwmtas01p.mx.bigpond.com [61.9.189.137]) by mx1.freebsd.org (Postfix) with ESMTP id C530A8FC08 for ; Sun, 18 Apr 2010 23:24:22 +0000 (UTC) Received: from nschwotgx02p.mx.bigpond.com ([124.188.161.100]) by nschwmtas01p.mx.bigpond.com (InterMail vM.7.05.02.08 201-2174-114-118-20080528) with ESMTP id <20100418232420.MRYO17427.nschwmtas01p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com>; Sun, 18 Apr 2010 23:24:20 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20100418232420.SWGO2131.nschwotgx02p.mx.bigpond.com@duncan.reilly.home>; Sun, 18 Apr 2010 23:24:20 +0000 Date: Mon, 19 Apr 2010 09:24:20 +1000 From: Andrew Reilly To: Jeremy Chadwick Message-ID: <20100418232420.GA4620@duncan.reilly.home> References: <20100418213727.GA98129@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100418213727.GA98129@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx02p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Sun, 18 Apr 2010 23:24:20 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150205.4BCB94A4.00E6,ss=1,fgs=0 X-SIH-MSG-ID: rBA7GNP4TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rANv1RsM6kxD9EJhiGNGMkaa7kTY3Rs9mK Cc: freebsd-stable@freebsd.org Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 23:24:23 -0000 On Sun, Apr 18, 2010 at 02:37:27PM -0700, Jeremy Chadwick wrote: > I'd like to discuss the possibility of introduction of a new script into > /etc/rc.d base system a script, which when enabled, would provide a way > to wait until the IP networking layer (using ping(8)) is up and usable > before continuing with daemon startup. > > Let's discuss. :-) > > > HISTORY > ========= > The situation which brought this debacle to my attention: > > I found that on reboot of some of our systems, ntpdate (used to sync the > clock initially before ntpd would be started) wouldn't work. The daemon > would report that it couldn't resolve any of the FQDNs within ntp.conf, > and would therefore act as a no-op before continuing on. By way of discussion, I'd just like to re-iterate what I said the first time around: it must be understood that this sort of thing is a (necessary) hacky-workaround that should ultimately be unnecessary. In preference, we should work on the failing daemons or hassle up-stream daemon authors so that the daemons in question either (a) retry until they *do* get the information they're after or (b) fail properly, so that they can be restarted by an external process monitoring framework like sysutils/daemontools or launchd. The reasoning is simple: network outage is something that can happen even after startup, and when network connectivity returns, the routing and addresses that are visible won't necessarily be the same. Consider laptops that suspend, as a particular example. Or mobile devices that switch from wi-fi to cellular networking to no connectivity on a regular basis. The "get it right at boot time" model is important and traditional, but (I think) a fragile and diminishing fraction of use cases. Our rc-ng framework favours solution (a). I'm more a fan of approach (b), myself: I use daemontools for many services, and I like the way that launchd works on my Mac laptops. Cheers, -- Andrew From owner-freebsd-stable@FreeBSD.ORG Sun Apr 18 23:38:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6E421065670 for ; Sun, 18 Apr 2010 23:38:00 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF5F8FC1A for ; Sun, 18 Apr 2010 23:38:00 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so1386449qwi.7 for ; Sun, 18 Apr 2010 16:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CJNqBHvT6PThDnnJnxC9xWMbkNY93IVq95vPvVC5EAY=; b=W86O7H+AM2aPiqA159y+xyyhJp24b1K6gl0yMUJdBlnHfSaOlX8YO1x7OXiAuAHlZh edq/fuu8cqOFF5qWuoSOGCYnlFaaurS7zpY+ZKZMk7VUZCOyNJD5vJcsXFytyT4/3pqb sd/Ah01c/ytKXFLtlfgOBkjM6B6INMyppMy7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uL0tygryadYSIDpH/U/YG1MLmwyOUqSMb+1FDAsLAK2qd1YMQRgZkTdMeLx9egKmRe oMgUEw+FSPcGQg/iFM/8dVOWoVQT8JWy+XNH3AYa900KBXHire786WpYULiNb7UdbQ1U +l4RKYOdxVRED7qwi40b/GPl0Fgs5ryvtrIwE= MIME-Version: 1.0 Received: by 10.229.28.85 with HTTP; Sun, 18 Apr 2010 16:37:59 -0700 (PDT) In-Reply-To: <20100418232420.GA4620@duncan.reilly.home> References: <20100418213727.GA98129@icarus.home.lan> <20100418232420.GA4620@duncan.reilly.home> Date: Sun, 18 Apr 2010 16:37:59 -0700 Received: by 10.229.248.211 with SMTP id mh19mr4827839qcb.104.1271633879660; Sun, 18 Apr 2010 16:37:59 -0700 (PDT) Message-ID: From: Garrett Cooper To: Andrew Reilly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 23:38:01 -0000 On Sun, Apr 18, 2010 at 4:24 PM, Andrew Reilly wro= te: > On Sun, Apr 18, 2010 at 02:37:27PM -0700, Jeremy Chadwick wrote: >> I'd like to discuss the possibility of introduction of a new script into >> /etc/rc.d base system a script, which when enabled, would provide a way >> to wait until the IP networking layer (using ping(8)) is up and usable >> before continuing with daemon startup. >> >> Let's discuss. =A0:-) >> >> >> HISTORY >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> The situation which brought this debacle to my attention: >> >> I found that on reboot of some of our systems, ntpdate (used to sync the >> clock initially before ntpd would be started) wouldn't work. =A0The daem= on >> would report that it couldn't resolve any of the FQDNs within ntp.conf, >> and would therefore act as a no-op before continuing on. > > By way of discussion, I'd just like to re-iterate what I > said the first time around: it must be understood that this > sort of thing is a (necessary) hacky-workaround that should > ultimately be unnecessary. =A0In preference, we should work on > the failing daemons or hassle up-stream daemon authors so > that the daemons in question either (a) retry until they *do* > get the information they're after or (b) fail properly, so > that they can be restarted by an external process monitoring > framework like sysutils/daemontools or launchd. =A0The reasoning > is simple: network outage is something that can happen even > after startup, and when network connectivity returns, the > routing and addresses that are visible won't necessarily be the > same. =A0Consider laptops that suspend, as a particular example. > Or mobile devices that switch from wi-fi to cellular networking > to no connectivity on a regular basis. =A0The "get it right at > boot time" model is important and traditional, but (I think) > a fragile and diminishing fraction of use cases. =A0Our rc-ng > framework favours solution (a). =A0I'm more a fan of approach (b), > myself: I use daemontools for many services, and I like the way > that launchd works on my Mac laptops. I agree with Andrew. This is the model that Mac has been on for a while now with launchd and this is the way that we should be migrating towards (IMO) as it does a better job at detecting asynchronous system events and could improve the overall init / rc model used in FreeBSD. What ever happened to this work: http://wiki.freebsd.org/launchd ? I remember that Apple went in a more OSX centric set of APIs in Leopard+, but it might be worthwhile to start with the older version of launchd, and migrate from there. Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 02:39:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E4B3106566B for ; Mon, 19 Apr 2010 02:39:16 +0000 (UTC) (envelope-from china@thewrittenword.com) Received: from mail1.thewrittenword.com (mail1.thewrittenword.com [69.67.212.77]) by mx1.freebsd.org (Postfix) with ESMTP id 5725A8FC0C for ; Mon, 19 Apr 2010 02:39:16 +0000 (UTC) Received: from mail1.il.thewrittenword.com (emma-internal-gw.il.thewrittenword.com [192.168.13.25]) by mail1.thewrittenword.com (Postfix) with ESMTP id A7EE65CC7 for ; Mon, 19 Apr 2010 02:40:35 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.4.4 mail1.thewrittenword.com A7EE65CC7 Received: from honinbu.il.thewrittenword.com (honinbu.il.thewrittenword.com [10.191.57.58]) by mail1.il.thewrittenword.com (Postfix) with ESMTP id 1EE32892 for ; Mon, 19 Apr 2010 02:19:49 +0000 (UTC) Received: by honinbu.il.thewrittenword.com (Postfix, from userid 1000) id B9298362; Sun, 18 Apr 2010 21:11:07 -0500 (CDT) Date: Sun, 18 Apr 2010 21:11:07 -0500 From: Albert Chin To: freebsd-stable@freebsd.org Message-ID: <20100419021107.GA5835@honinbu.il.thewrittenword.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-08-17) X-Virus-Scanned: clamav-milter 0.96 at maetel.il.thewrittenword.com X-Virus-Status: Clean Subject: cyclades driver in 8.0-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 02:39:16 -0000 Just updated to 8.0-RELEASE and recompiling 8.0-STABLE with the following addition to GENERIC: device cy options CY_PCI_FASTINTR Building the kernel with: make buildkernel KERNCONF=NEWKERNEL gives me: cc -c -O -pipe -march=pentium4 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/opt/freebsd/src/sys -I/opt/freebsd/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /opt/freebsd/src/sys/dev/cy/cy.c /opt/freebsd/src/sys/dev/cy/cy.c:251: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cybreak' /opt/freebsd/src/sys/dev/cy/cy.c:252: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cymodem' /opt/freebsd/src/sys/dev/cy/cy.c:253: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cyopen' /opt/freebsd/src/sys/dev/cy/cy.c:254: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cyclose' cc1: warnings being treated as errors FreeBSD 7 had: typedef void t_break_t(struct tty *, int); in This is no longer present in FreeBSD 8. Oversight? Should I be able to compile the cyclades driver for FreeBSD 8? -- albert chin (china@thewrittenword.com) From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 06:49:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA239106564A for ; Mon, 19 Apr 2010 06:49:26 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 7C96B8FC1B for ; Mon, 19 Apr 2010 06:49:26 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1O3knM-000MaT-3E; Mon, 19 Apr 2010 09:49:24 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Andrew Reilly In-reply-to: <20100418232420.GA4620@duncan.reilly.home> References: <20100418213727.GA98129@icarus.home.lan> <20100418232420.GA4620@duncan.reilly.home> Comments: In-reply-to Andrew Reilly message dated "Mon, 19 Apr 2010 09:24:20 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Apr 2010 09:49:24 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 06:49:26 -0000 > On Sun, Apr 18, 2010 at 02:37:27PM -0700, Jeremy Chadwick wrote: > > I'd like to discuss the possibility of introduction of a new script into > > /etc/rc.d base system a script, which when enabled, would provide a way > > to wait until the IP networking layer (using ping(8)) is up and usable > > before continuing with daemon startup. > > > > Let's discuss. :-) > > > > > > HISTORY > > ========= > > The situation which brought this debacle to my attention: > > > > I found that on reboot of some of our systems, ntpdate (used to sync the > > clock initially before ntpd would be started) wouldn't work. The daemon > > would report that it couldn't resolve any of the FQDNs within ntp.conf, > > and would therefore act as a no-op before continuing on. > > By way of discussion, I'd just like to re-iterate what I > said the first time around: it must be understood that this > sort of thing is a (necessary) hacky-workaround that should > ultimately be unnecessary. In preference, we should work on > the failing daemons or hassle up-stream daemon authors so > that the daemons in question either (a) retry until they *do* > get the information they're after or (b) fail properly, so > that they can be restarted by an external process monitoring > framework like sysutils/daemontools or launchd. The reasoning > is simple: network outage is something that can happen even > after startup, and when network connectivity returns, the > routing and addresses that are visible won't necessarily be the > same. Consider laptops that suspend, as a particular example. > Or mobile devices that switch from wi-fi to cellular networking > to no connectivity on a regular basis. The "get it right at > boot time" model is important and traditional, but (I think) > a fragile and diminishing fraction of use cases. Our rc-ng > framework favours solution (a). I'm more a fan of approach (b), > myself: I use daemontools for many services, and I like the way > that launchd works on my Mac laptops. I think that rc is being overloaded yet again(*), and a launchDaemon kind of solution should be followed, maybe even as a replacement for inetd? /blah (*): in the begining rc would do everything, but life was simple - no internet, then it got complicated, too many daemons, so inetd was invented, things were back in control, for a while. Then sysv invented init.d/init levels, then rc-ng came along, though it solves many problems, 1) the order of things, 2) easy to configure services, it's getting complicated to get 1 'correctly'. blah/ danny From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 06:53:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A10791065670; Mon, 19 Apr 2010 06:53:41 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CCBD98FC15; Mon, 19 Apr 2010 06:53:40 +0000 (UTC) Received: by wyf28 with SMTP id 28so988444wyf.13 for ; Sun, 18 Apr 2010 23:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=jP596AHsfN6CO6RNWXTRvEMmD1zSCM4hDuOhFkPI/Tw=; b=Z5aitRIVrBw11B3jORk4zyknJPoRnX1Hv0LKi8eCm4SgIPDhG22ecVKQrO1rGwTbKg /xxlQf9PrfvDl/H2//Jmh8JlOStYksj8esMnzBUY7Oiaj9ng3VXgOjQ/tUAznvnPULEU HLRl5GrEnOEgZQ4lVrl0FV3KpRICCV9QTgNQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tLVC+Ij4z8MsE/jWLvaRf9IiUN9zNtnF2IQu4RnwZsqN9nWX57k5qa2KnrP+U/c/CX sVY3vvBAsacuQLEaA3r2wzetT8E6pgjlbaFJKn7jdxisuoALMlNzxrEVBQx9gskieGju DKrQtV8RPY8a4glnqzVONKnp/SXGIPbs1UOCA= MIME-Version: 1.0 Received: by 10.216.13.7 with HTTP; Sun, 18 Apr 2010 23:53:38 -0700 (PDT) In-Reply-To: <4B28F841.1070900@skylinetele.com> References: <4B28F841.1070900@skylinetele.com> Date: Mon, 19 Apr 2010 09:53:38 +0300 Received: by 10.216.170.147 with SMTP id p19mr6484897wel.129.1271660019425; Sun, 18 Apr 2010 23:53:39 -0700 (PDT) Message-ID: From: Marin Atanasov To: "Prokofiev S.P." Content-Type: multipart/mixed; boundary=0016e65a1074bba2380484916b22 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, "Li, Qing" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Qing Li Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 06:53:41 -0000 --0016e65a1074bba2380484916b22 Content-Type: text/plain; charset=ISO-8859-1 Hi, I was setting up mpd5 from ports, but this proxy-arp issue still exists in 8.0. > uname -r 8.0-RELEASE-p2 I've attached the output from the mpd5 daemon, where you can still see that the issue is relevant. I've also tried to apply the patch, but it's no longer on that location. Something else to add - I've a dns server running on the same machine that mpd5 was set up. I'm not sure if this is caused by mpd5 daemon or the arp issue, but after a couple of start/stops of mpd5 the name resolving from the gateway machine is not possible, all other systems from the internal network are able to use the dns server on the gateway, but the gateway itself cannot. Restart of named, doesn't help either, so I had to completely reboot the machine, so that arp entries are flushed as well. Could you please have a look at the issue? If you need some additional information, please let me know. Regards, Marin On Wed, Dec 16, 2009 at 6:09 PM, Prokofiev S.P. wrote: > Thank you ! > The problem with proxy-arp has disappeared (FreeBSD 8-STABLE amd64 with > mpd5). > > Please, somebody fix the bug kern/141285... > > > Li, Qing wrote: > >> Hi, >> >> Recently there have been several reports regarding issues with ppp, mpd5 >> and proxy-arp configuration over the ppp links. I read through the >> various postings and the problems seem to be: >> >> 1. Unable to add proxy-arp entries for the remote ppp clients. >> >> 2. Log showing "ifa_add_loopback_route: insertion failed" causing some >> userland applications to fail. >> >> May I ask that you try applying patch >> >> http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff >> >> and report back if the patch fixes your problems. And if not, please >> describe what additional issues you are having. >> >> Thanks, >> >> -- Qing >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> >> >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org --0016e65a1074bba2380484916b22 Content-Type: text/plain; charset=US-ASCII; name="mpd-daemon.txt" Content-Disposition: attachment; filename="mpd-daemon.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g86xilo30 IyAvdXNyL2xvY2FsL3NiaW4vbXBkNQ0KTXVsdGktbGluayBQUFAgZGFlbW9uIGZvciBGcmVlQlNE DQogDQpwcm9jZXNzIDIyOTUgc3RhcnRlZCwgdmVyc2lvbiA1LjUgKHJvb3RAZG9tYWluIDAyOjIx IDE3LUFwci0yMDEwKQ0KVXNhZ2U6IHNldCB1c2VyIHtuYW1lfSB7cGFzc3dvcmR9IFt7cHJpdn1d DQpDT05TT0xFOiBsaXN0ZW5pbmcgb24gMTI3LjAuMC4xIDUwMDUNCndlYjogbGlzdGVuaW5nIG9u IDAuMC4wLjAgNTAwNg0KUFBUUDogd2FpdGluZyBmb3IgY29ubmVjdGlvbiBvbiA8ZXh0ZXJuYWwt aXAtaGVyZT4gMTcyMw0KW0xdIFtMLTFdIEFjY2VwdGluZyBQUFRQIGNvbm5lY3Rpb24NCltMLTFd IExpbms6IE9QRU4gZXZlbnQNCltMLTFdIExDUDogT3BlbiBldmVudA0KW0wtMV0gTENQOiBzdGF0 ZSBjaGFuZ2UgSW5pdGlhbCAtLT4gU3RhcnRpbmcNCltMLTFdIExDUDogTGF5ZXJTdGFydA0KW0wt MV0gUFBUUDogYXR0YWNoaW5nIHRvIHBlZXIncyBvdXRnb2luZyBjYWxsDQpbTC0xXSBMaW5rOiBV UCBldmVudA0KW0wtMV0gTENQOiBVcCBldmVudA0KW0wtMV0gTENQOiBzdGF0ZSBjaGFuZ2UgU3Rh cnRpbmcgLS0+IFJlcS1TZW50DQpbTC0xXSBMQ1A6IFNlbmRDb25maWdSZXEgIzENCltMLTFdICAg QUNGQ09NUA0KW0wtMV0gICBQUk9UT0NPTVANCltMLTFdICAgTVJVIDE1MDANCltMLTFdICAgTUFH SUNOVU0gMTAyYzRkMjINCltMLTFdICAgQVVUSFBST1RPIENIQVAgTVNPRlR2Mg0KW0wtMV0gICBN UCBNUlJVIDIwNDgNCltMLTFdICAgTVAgU0hPUlRTRVENCltMLTFdICAgRU5EUE9JTlRESVNDIFs4 MDIuMV0gMDAgMTAgZGMgMTAgNTUgM2YNCltMLTFdIExDUDogcmVjJ2QgQ29uZmlndXJlIFJlamVj dCAjMSAoUmVxLVNlbnQpDQpbTC0xXSAgIE1QIE1SUlUgMjA0OA0KW0wtMV0gICBNUCBTSE9SVFNF UQ0KW0wtMV0gICBFTkRQT0lOVERJU0MgWzgwMi4xXSAwMCAxMCBkYyAxMCA1NSAzZg0KW0wtMV0g TENQOiBTZW5kQ29uZmlnUmVxICMyDQpbTC0xXSAgIEFDRkNPTVANCltMLTFdICAgUFJPVE9DT01Q DQpbTC0xXSAgIE1SVSAxNTAwDQpbTC0xXSAgIE1BR0lDTlVNIDEwMmM0ZDIyDQpbTC0xXSAgIEFV VEhQUk9UTyBDSEFQIE1TT0ZUdjINCltMLTFdIExDUDogcmVjJ2QgQ29uZmlndXJlIEFjayAjMiAo UmVxLVNlbnQpDQpbTC0xXSAgIEFDRkNPTVANCltMLTFdICAgUFJPVE9DT01QDQpbTC0xXSAgIE1S VSAxNTAwDQpbTC0xXSAgIE1BR0lDTlVNIDEwMmM0ZDIyDQpbTC0xXSAgIEFVVEhQUk9UTyBDSEFQ IE1TT0ZUdjINCltMLTFdIExDUDogc3RhdGUgY2hhbmdlIFJlcS1TZW50IC0tPiBBY2stUmN2ZA0K W0wtMV0gTENQOiByZWMnZCBDb25maWd1cmUgUmVxdWVzdCAjMSAoQWNrLVJjdmQpDQpbTC0xXSAg IE1SVSAxNDAwDQpbTC0xXSAgIE1BR0lDTlVNIDdmZTU3NDRkDQpbTC0xXSAgIFBST1RPQ09NUA0K W0wtMV0gICBBQ0ZDT01QDQpbTC0xXSAgIENBTExCQUNLIDYNCltMLTFdIExDUDogU2VuZENvbmZp Z1JlaiAjMQ0KW0wtMV0gICBDQUxMQkFDSyA2DQpbTC0xXSBMQ1A6IHJlYydkIENvbmZpZ3VyZSBS ZXF1ZXN0ICMyIChBY2stUmN2ZCkNCltMLTFdICAgTVJVIDE0MDANCltMLTFdICAgTUFHSUNOVU0g N2ZlNTc0NGQNCltMLTFdICAgUFJPVE9DT01QDQpbTC0xXSAgIEFDRkNPTVANCltMLTFdIExDUDog U2VuZENvbmZpZ0FjayAjMg0KW0wtMV0gICBNUlUgMTQwMA0KW0wtMV0gICBNQUdJQ05VTSA3ZmU1 NzQ0ZA0KW0wtMV0gICBQUk9UT0NPTVANCltMLTFdICAgQUNGQ09NUA0KW0wtMV0gTENQOiBzdGF0 ZSBjaGFuZ2UgQWNrLVJjdmQgLS0+IE9wZW5lZA0KW0wtMV0gTENQOiBhdXRoOiBwZWVyIHdhbnRz IG5vdGhpbmcsIEkgd2FudCBDSEFQDQpbTC0xXSBDSEFQOiBzZW5kaW5nIENIQUxMRU5HRSAjMSBs ZW46IDIxDQpbTC0xXSBMQ1A6IExheWVyVXANCltMLTFdIExDUDogcmVjJ2QgSWRlbnQgIzMgKE9w ZW5lZCkNCltMLTFdICAgTUVTRzogTVNSQVNWNS4xMA0KW0wtMV0gTENQOiByZWMnZCBJZGVudCAj NCAoT3BlbmVkKQ0KW0wtMV0gICBNRVNHOiBNU1JBUy0wLVRTVU5BTUkNCltMLTFdIENIQVA6IHJl YydkIFJFU1BPTlNFICMxIGxlbjogNjENCltMLTFdICAgTmFtZTogIm1yYXRlc3QiDQpbTC0xXSBB VVRIOiBUcnlpbmcgSU5URVJOQUwNCltMLTFdIEFVVEg6IElOVEVSTkFMIHJldHVybmVkOiB1bmRl ZmluZWQNCltMLTFdIENIQVA6IEF1dGggcmV0dXJuIHN0YXR1czogdW5kZWZpbmVkDQpbTC0xXSBD SEFQOiBSZXNwb25zZSBpcyB2YWxpZA0KW0wtMV0gQ0hBUDogUmVwbHkgbWVzc2FnZTogUz04QkUz MDVGMDhGQkFFQjRFODAxQjYyMDEwMzdCNEI0QUVCNzZBNzNCDQpbTC0xXSBDSEFQOiBzZW5kaW5n IFNVQ0NFU1MgIzEgbGVuOiA0Ng0KW0wtMV0gTENQOiBhdXRob3JpemF0aW9uIHN1Y2Nlc3NmdWwN CltMLTFdIExpbms6IE1hdGNoZWQgYWN0aW9uICdidW5kbGUgIkIiICIiJw0KW0wtMV0gQ3JlYXRp bmcgbmV3IGJ1bmRsZSB1c2luZyB0ZW1wbGF0ZSAiQiIuDQpbQi0xXSBCdW5kbGU6IEludGVyZmFj ZSBuZzAgY3JlYXRlZA0KW0wtMV0gTGluazogSm9pbiBidW5kbGUgIkItMSINCltCLTFdIEJ1bmRs ZTogU3RhdHVzIHVwZGF0ZTogdXAgMSBsaW5rLCB0b3RhbCBiYW5kd2lkdGggNjQwMDAgYnBzDQpb Qi0xXSBJUENQOiBPcGVuIGV2ZW50DQpbQi0xXSBJUENQOiBzdGF0ZSBjaGFuZ2UgSW5pdGlhbCAt LT4gU3RhcnRpbmcNCltCLTFdIElQQ1A6IExheWVyU3RhcnQNCltCLTFdIENDUDogT3BlbiBldmVu dA0KW0ItMV0gQ0NQOiBzdGF0ZSBjaGFuZ2UgSW5pdGlhbCAtLT4gU3RhcnRpbmcNCltCLTFdIEND UDogTGF5ZXJTdGFydA0KW0ItMV0gSVBDUDogVXAgZXZlbnQNCltCLTFdIElQQ1A6IEdvdCBJUCAx MC4xLjE2LjUwIGZyb20gcG9vbCAicG9vbDEiIGZvciBwZWVyDQpbQi0xXSBJUENQOiBzdGF0ZSBj aGFuZ2UgU3RhcnRpbmcgLS0+IFJlcS1TZW50DQpbQi0xXSBJUENQOiBTZW5kQ29uZmlnUmVxICMx DQpbQi0xXSAgIElQQUREUiA8ZXh0ZXJuYWwtaXAtaGVyZT4NCltCLTFdICAgQ09NUFBST1RPIFZK Q09NUCwgMTYgY29tcC4gY2hhbm5lbHMsIG5vIGNvbXAtY2lkDQpbQi0xXSBDQ1A6IFVwIGV2ZW50 DQpbQi0xXSBDQ1A6IHN0YXRlIGNoYW5nZSBTdGFydGluZyAtLT4gUmVxLVNlbnQNCltCLTFdIEND UDogU2VuZENvbmZpZ1JlcSAjMQ0KW0ItMV0gICBNUFBDDQpbQi0xXSAgICAgMHgwMTAwMDA2MDpN UFBFKDQwLCAxMjggYml0cyksIHN0YXRlbGVzcw0KW0ItMV0gQ0NQOiByZWMnZCBDb25maWd1cmUg UmVxdWVzdCAjNSAoUmVxLVNlbnQpDQpbQi0xXSAgIE1QUEMNCltCLTFdICAgICAweDAxMDAwMGUx Ok1QUEMsIE1QUEUoNDAsIDU2LCAxMjggYml0cyksIHN0YXRlbGVzcw0KW0ItMV0gQ0NQOiBTZW5k Q29uZmlnTmFrICM1DQpbQi0xXSAgIE1QUEMNCltCLTFdICAgICAweDAxMDAwMDQwOk1QUEUoMTI4 IGJpdHMpLCBzdGF0ZWxlc3MNCltCLTFdIElQQ1A6IHJlYydkIENvbmZpZ3VyZSBSZXF1ZXN0ICM2 IChSZXEtU2VudCkNCltCLTFdICAgSVBBRERSIDAuMC4wLjANCltCLTFdICAgICBOQUtpbmcgd2l0 aCAxMC4xLjE2LjUwDQpbQi0xXSAgIFBSSUROUyAwLjAuMC4wDQpbQi0xXSAgICAgTkFLaW5nIHdp dGggMTAuMS4xNi4xDQpbQi0xXSAgIFBSSU5CTlMgMC4wLjAuMA0KW0ItMV0gICBTRUNETlMgMC4w LjAuMA0KW0ItMV0gICBTRUNOQk5TIDAuMC4wLjANCltCLTFdIElQQ1A6IFNlbmRDb25maWdSZWog IzYNCltCLTFdICAgUFJJTkJOUyAwLjAuMC4wDQpbQi0xXSAgIFNFQ0ROUyAwLjAuMC4wDQpbQi0x XSAgIFNFQ05CTlMgMC4wLjAuMA0KW0ItMV0gSVBDUDogcmVjJ2QgQ29uZmlndXJlIFJlamVjdCAj MSAoUmVxLVNlbnQpDQpbQi0xXSAgIENPTVBQUk9UTyBWSkNPTVAsIDE2IGNvbXAuIGNoYW5uZWxz LCBubyBjb21wLWNpZA0KW0ItMV0gSVBDUDogU2VuZENvbmZpZ1JlcSAjMg0KW0ItMV0gICBJUEFE RFIgPGV4dGVybmFsLWlwLWhlcmU+DQpbQi0xXSBDQ1A6IHJlYydkIENvbmZpZ3VyZSBOYWsgIzEg KFJlcS1TZW50KQ0KW0ItMV0gICBNUFBDDQpbQi0xXSAgICAgMHgwMTAwMDA0MDpNUFBFKDEyOCBi aXRzKSwgc3RhdGVsZXNzDQpbQi0xXSBDQ1A6IFNlbmRDb25maWdSZXEgIzINCltCLTFdICAgTVBQ Qw0KW0ItMV0gICAgIDB4MDEwMDAwNDA6TVBQRSgxMjggYml0cyksIHN0YXRlbGVzcw0KW0ItMV0g Q0NQOiByZWMnZCBDb25maWd1cmUgUmVxdWVzdCAjNyAoUmVxLVNlbnQpDQpbQi0xXSAgIE1QUEMN CltCLTFdICAgICAweDAxMDAwMDQwOk1QUEUoMTI4IGJpdHMpLCBzdGF0ZWxlc3MNCltCLTFdIEND UDogU2VuZENvbmZpZ0FjayAjNw0KW0ItMV0gICBNUFBDDQpbQi0xXSAgICAgMHgwMTAwMDA0MDpN UFBFKDEyOCBiaXRzKSwgc3RhdGVsZXNzDQpbQi0xXSBDQ1A6IHN0YXRlIGNoYW5nZSBSZXEtU2Vu dCAtLT4gQWNrLVNlbnQNCltCLTFdIElQQ1A6IHJlYydkIENvbmZpZ3VyZSBSZXF1ZXN0ICM4IChS ZXEtU2VudCkNCltCLTFdICAgSVBBRERSIDAuMC4wLjANCltCLTFdICAgICBOQUtpbmcgd2l0aCAx MC4xLjE2LjUwDQpbQi0xXSAgIFBSSUROUyAwLjAuMC4wDQpbQi0xXSAgICAgTkFLaW5nIHdpdGgg MTAuMS4xNi4xDQpbQi0xXSBJUENQOiBTZW5kQ29uZmlnTmFrICM4DQpbQi0xXSAgIElQQUREUiAx MC4xLjE2LjUwDQpbQi0xXSAgIFBSSUROUyAxMC4xLjE2LjENCltCLTFdIElQQ1A6IHJlYydkIENv bmZpZ3VyZSBBY2sgIzIgKFJlcS1TZW50KQ0KW0ItMV0gICBJUEFERFIgPGV4dGVybmFsLWlwLWhl cmU+DQpbQi0xXSBJUENQOiBzdGF0ZSBjaGFuZ2UgUmVxLVNlbnQgLS0+IEFjay1SY3ZkDQpbQi0x XSBDQ1A6IHJlYydkIENvbmZpZ3VyZSBBY2sgIzIgKEFjay1TZW50KQ0KW0ItMV0gICBNUFBDDQpb Qi0xXSAgICAgMHgwMTAwMDA0MDpNUFBFKDEyOCBiaXRzKSwgc3RhdGVsZXNzDQpbQi0xXSBDQ1A6 IHN0YXRlIGNoYW5nZSBBY2stU2VudCAtLT4gT3BlbmVkDQpbQi0xXSBDQ1A6IExheWVyVXANCltC LTFdIENDUDogQ29tcHJlc3MgdXNpbmc6IG1wcGMgKE1QUEUoMTI4IGJpdHMpLCBzdGF0ZWxlc3Mp DQpbQi0xXSBDQ1A6IERlY29tcHJlc3MgdXNpbmc6IG1wcGMgKE1QUEUoMTI4IGJpdHMpLCBzdGF0 ZWxlc3MpDQpbQi0xXSBJUENQOiByZWMnZCBDb25maWd1cmUgUmVxdWVzdCAjOSAoQWNrLVJjdmQp DQpbQi0xXSAgIElQQUREUiAxMC4xLjE2LjUwDQpbQi0xXSAgICAgMTAuMS4xNi41MCBpcyBPSw0K W0ItMV0gICBQUklETlMgMTAuMS4xNi4xDQpbQi0xXSBJUENQOiBTZW5kQ29uZmlnQWNrICM5DQpb Qi0xXSAgIElQQUREUiAxMC4xLjE2LjUwDQpbQi0xXSAgIFBSSUROUyAxMC4xLjE2LjENCltCLTFd IElQQ1A6IHN0YXRlIGNoYW5nZSBBY2stUmN2ZCAtLT4gT3BlbmVkDQpbQi0xXSBJUENQOiBMYXll clVwDQpbQi0xXSAgIDxleHRlcm5hbC1pcC1oZXJlPiAtPiAxMC4xLjE2LjUwDQpbQi0xXSBzeXN0 ZW06IGNvbW1hbmQgIi91c3Ivc2Jpbi9hcnAiIHJldHVybmVkIDI1Ng0KW0ItMV0gSUZBQ0U6IFVw IGV2ZW50DQo= --0016e65a1074bba2380484916b22-- From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 08:21:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0975C1065674 for ; Mon, 19 Apr 2010 08:21:20 +0000 (UTC) (envelope-from spamrefuse@yahoo.com) Received: from web33308.mail.mud.yahoo.com (web33308.mail.mud.yahoo.com [68.142.206.123]) by mx1.freebsd.org (Postfix) with SMTP id A34EE8FC27 for ; Mon, 19 Apr 2010 08:21:19 +0000 (UTC) Received: (qmail 2652 invoked by uid 60001); 19 Apr 2010 07:54:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271663677; bh=G+Ii2n9vjQcjtz7xmHYYuvmTeoyIasm9JaVRtaKgIk4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=ALCUBzgTa/60b7PzyJ0DzaMTBcaB57tyBZMO+IRHF7xlBwH7a507F6LxyFa2NlsVD46wKU0bq1kH3HsIs7VlvnQmnzT1ypSXiNAIHftoqcwAFqpNDNrYLbvcJZey6THYLSbQPF5kZFiJ7JUSVaGWZglNhHWFp8OTfJSi2B1Lx5U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=M5EREd73zaOv6Q7/z6qpMqWLlxqAxBVsIqTcl1q7z/G2pxxax0xeJvPY5dmEhEvr8p8KWxPF6BfQyFHvom6nfS2T9HmKUxE58S7nzdW9HyEjgKgXJUIXev/wbXwkNlAp9Rvy8EkVRS85q9ZUsAUxTsyMjFcx+/Zl+HY1+yMI1oI=; Message-ID: <595984.2470.qm@web33308.mail.mud.yahoo.com> X-YMail-OSG: nh0.PIUVM1moQ1iavrI3VV5IRRLvqzJ_r8ZUnxiJcdveqHY 0ZAwx1BB62WvIuAMb9NS.P..bX5IlTRg6dVRFn5_JecU0ltu8orXDb4gpfIB 1nRhkDx7Wx2k_HGHFNJ1Z6j6uweh4qzRhTSBKmfE1nRBP1Brl3rIRsQpBzc6 mh67su8j5ooOhZlIhE89QzIBhVd2Vl8V8dZrh2HroqqV5yDIE8EgiiDkEynY lQ3qeVikCD6C95v1RINKkTvCgXNVXlKqj.5vdKKX55UQRRn5gchuctzlZckl lESmv8q8T41F.Kkw_HGsIhzRg79da Received: from [202.150.188.32] by web33308.mail.mud.yahoo.com via HTTP; Mon, 19 Apr 2010 00:54:37 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.100.260964 Date: Mon, 19 Apr 2010 00:54:37 -0700 (PDT) From: Rob To: FreeBSD Stable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: "8.6 The Configuration File" out of date? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 08:21:20 -0000 Hi, I wonder if somebody add/remove the kernel options that came & went with FreeBSD 8.0. For example: Those that seemed to have disappeared: machine i386 options GEOM_GPT options COMPAT_43 options ADAPTIVE_GIANT New ones that appeared in GENERIC (at least: they are not discussed in the Handbook, 8.6): options SCTP options UFS_GJOURNAL options GEOM_PART_GPT options GEOM_LABEL options COMPAT_43TTY options COMPAT_FREEBSD6 options COMPAT_FREEBSD7 options STACK options P1003_1B_SEMAPHORES options PRINTF_BUFR_SIZE=128 Regards, R. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 08:58:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20CBD106564A for ; Mon, 19 Apr 2010 08:58:58 +0000 (UTC) (envelope-from laa@cemu.ru) Received: from m.cemu.ru (m.cemu.ru [81.95.136.64]) by mx1.freebsd.org (Postfix) with ESMTP id C41F58FC12 for ; Mon, 19 Apr 2010 08:58:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=laa.zp.ua; s=dkim; h=Sender:In-Reply-To:Content-Type:Mime-Version:References:Message-ID:Subject:To:From:Date; bh=8+LSN2PxXV42rIuejl5hnqqqrFR84jGzoQi1bHX8m2I=; b=Cg823DcISOsBvsHthnGPmX+jRPwmWXd4FXaVD5IlhvW1fFrQtlyTEK7L3Co6Bo0jGVt6N2TdytuLYyyZaR8dANKY/CttAR+l+fTowTmZlsRZUmftOEmYQ1nYJbgw7g6BZ/Qek8/lEUZwPS1RmDDPcY3xpkQ/RJXtRHfanq6Ayps=; Received: from laa by m.cemu.ru with local (Exim) (envelope-from ) id 1O3moi-0006dn-AT for freebsd-stable@freebsd.org; Mon, 19 Apr 2010 12:58:56 +0400 Date: Mon, 19 Apr 2010 12:58:56 +0400 From: Lystopad Olexandr To: freebsd-stable@freebsd.org Message-ID: <20100419085856.GX2460@cemu.ru> References: <20100414103054.GA2460@cemu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: laa Subject: Re: ath0: kernel panic when adhoc mode. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 08:58:58 -0000 Hello, Paul B Mahol! On Sun, Apr 18, 2010 at 10:20:26AM +0000 onemda@gmail.com wrote about "Re: ath0: kernel panic when adhoc mode.": > On 4/14/10, Lystopad Olexandr wrote: > > Hi! > > > > I install 8.0 FreeBSD, upgrade it to yesturday stable. > > I need to create wireless link in adhoc mode. > > Help me to do this. > > > > > > I put a wireless card into this box: > > > > ath0@pci0:3:3:0: class=0x020000 card=0xcc2114b9 chip=0x0013168c > > rev=0x01 hdr=0x00 > > vendor = 'Atheros Communications Inc.' > > device = '802.11a/b/g Wireless Adapter (AR5212)' > > class = network > > subclass = ethernet > > cap 01[44] = powerspec 2 supports D0 D3 current D0 > > > > > > > > when I do: > > # ifconfig wlan0 create wlandev ath0 wlanmode adhoc > > > > server reboot with kernel panic: > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 1; apic id = 01 > > fault virtual address = 0xffff > > fault code = supervisor read, page not present > > instruction pointer = 0x20:0xc0791612 > > stack pointer = 0x28:0xd2f42ba4 > > frame pointer = 0x28:0xd2f42bac > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 0 (ath0 taskq) > > trap number = 12 > > panic: page fault > > cpuid = 1 > > Uptime: 3m35s > > Physical memory: 439 MB > > Dumping 80 MB: 65 49 33panic: bufwrite: buffer is not busy??? > > cpuid = 1 > > 17 1 > > > > #0 doadump () at pcpu.h:246 > > 246 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) #0 doadump () at pcpu.h:246 > > #1 0xc06b3497 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 > > #2 0xc06b3789 in panic (fmt=Variable "fmt" is not available. > > ) at /usr/src/sys/kern/kern_shutdown.c:579 > > #3 0xc08b63bc in trap_fatal (frame=0xd2f42b64, eva=65535) > > at /usr/src/sys/i386/i386/trap.c:938 > > #4 0xc08b6620 in trap_pfault (frame=0xd2f42b64, usermode=0, eva=65535) > > at /usr/src/sys/i386/i386/trap.c:851 > > #5 0xc08b6f39 in trap (frame=0xd2f42b64) at > > /usr/src/sys/i386/i386/trap.c:533 > > #6 0xc0899b3b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > > #7 0xc0791612 in ieee80211_getcapinfo (vap=0xc2d5f000, chan=0xffff) > > at /usr/src/sys/net80211/ieee80211_output.c:1836 > > #8 0xc0793d17 in ieee80211_beacon_construct (m=0xc2edca00, > > frm=0xc2f0516e "", bo=0xc2d5f884, ni=0xc2ceb000) > > at /usr/src/sys/net80211/ieee80211_output.c:2559 > > #9 0xc07946db in ieee80211_beacon_alloc (ni=0xc2ceb000, bo=0xc2d5f884) > > at /usr/src/sys/net80211/ieee80211_output.c:2756 > > #10 0xc050eaea in ath_newstate (vap=0xc2d5f000, nstate=IEEE80211_S_RUN, > > arg=-1) at /usr/src/sys/dev/ath/if_ath.c:2641 > > #11 0xc0798db1 in ieee80211_newstate_cb (xvap=0xc2d5f000, npending=3) > > at /usr/src/sys/net80211/ieee80211_proto.c:1654 > > #12 0xc06ebf92 in taskqueue_run (queue=0xc2a84c80) > > at /usr/src/sys/kern/subr_taskqueue.c:239 > > #13 0xc06ec19d in taskqueue_thread_loop (arg=0xc2ada074) > > at /usr/src/sys/kern/subr_taskqueue.c:360 > > #14 0xc068a331 in fork_exit (callout=0xc06ec0e0 , > > arg=0xc2ada074, frame=0xd2f42d38) at /usr/src/sys/kern/kern_fork.c:843 > > #15 0xc0899bb0 in fork_trampoline () at > > /usr/src/sys/i386/i386/exception.s:270 > > (kgdb) > > > > This is bug, please report it ASAP. Thanks. Done. http://www.freebsd.org/cgi/query-pr.cgi?pr=145826 -- Olexandr Lystopad From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 09:43:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27C141065670 for ; Mon, 19 Apr 2010 09:43:52 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f199.google.com (mail-qy0-f199.google.com [209.85.221.199]) by mx1.freebsd.org (Postfix) with ESMTP id D63658FC1A for ; Mon, 19 Apr 2010 09:43:51 +0000 (UTC) Received: by qyk37 with SMTP id 37so4119995qyk.8 for ; Mon, 19 Apr 2010 02:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4sxbGfl8MV1KWyVJLtQe34YxIBjKy+RcPJ83x76m7e0=; b=xPn13F6+QSPiZY9TaH7iUenHz58JKpwNTpRcPyNwhiReNft7gRyhJY5vLPwpgA0rf8 PEUmpDZUsGtWILg0xDGIV6ECG0HPkKJfl8JHfEXGoJmCUA8yuNKneiVaQHzE2YrzL85c wIEMH8jirzIwNpVnwx+g86vFAGTbNVt6cNaKk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=osg1+sbHC+z1SDwa2gl+RdBA1nqWZNl2BSua6AgCj5/aZFKhHa8wEezuCg/wUmuPB8 IE2o3lFCz5X1PrtCtjxzvmKnfYFkhg7LrNjBtW4QFyMcoL885XM5OsV2jt+tNY/4jbj9 3DR6cdzEPkDT/QfAM5fvlYdBipNFkK6B8kw9U= MIME-Version: 1.0 Received: by 10.229.28.85 with HTTP; Mon, 19 Apr 2010 02:43:51 -0700 (PDT) In-Reply-To: <595984.2470.qm@web33308.mail.mud.yahoo.com> References: <595984.2470.qm@web33308.mail.mud.yahoo.com> Date: Mon, 19 Apr 2010 02:43:51 -0700 Received: by 10.229.211.75 with SMTP id gn11mr3866547qcb.34.1271670231049; Mon, 19 Apr 2010 02:43:51 -0700 (PDT) Message-ID: From: Garrett Cooper To: Rob Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Subject: Re: "8.6 The Configuration File" out of date? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 09:43:52 -0000 On Mon, Apr 19, 2010 at 12:54 AM, Rob wrote: > Hi, > > I wonder if somebody add/remove the kernel options that > came & went with FreeBSD 8.0. > > For example: > > Those that seemed to have disappeared: > > machine =A0 =A0 =A0 =A0i386 What architecture was this for -- amd64, i386, etc? > options =A0 =A0 =A0 =A0 =A0GEOM_GPT Should be GEOM_PART_GPT > options =A0 =A0 =A0 =A0 =A0COMPAT_43 Eh...? This still should be in there according to NOTES. > options =A0 =A0 =A0 =A0 =A0ADAPTIVE_GIANT Yes, this should be removed. > New ones that appeared in GENERIC > (at least: they are not discussed in the Handbook, 8.6): > > options =A0 =A0 =A0 =A0SCTP > options =A0 =A0 =A0 =A0 UFS_GJOURNAL > options =A0 =A0 =A0 =A0 GEOM_PART_GPT > options =A0 =A0 =A0 =A0 GEOM_LABEL > options =A0 =A0 =A0 =A0 COMPAT_43TTY > options =A0 =A0 =A0 =A0 COMPAT_FREEBSD6 > options =A0 =A0 =A0 =A0 COMPAT_FREEBSD7 > options =A0 =A0 =A0 =A0 STACK > options =A0 =A0 =A0 =A0 P1003_1B_SEMAPHORES > options =A0 =A0 =A0 =A0 PRINTF_BUFR_SIZE=3D128 These are all discussed in sys/conf/NOTES though, so they definitely need to be updated in the handbook. I'd file a PR with your findings and assign it to the doc category. Thanks for the keen eyes :)! -Garrett From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 13:13:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 320431065673 for ; Mon, 19 Apr 2010 13:13:47 +0000 (UTC) (envelope-from spamrefuse@yahoo.com) Received: from web33306.mail.mud.yahoo.com (web33306.mail.mud.yahoo.com [68.142.206.121]) by mx1.freebsd.org (Postfix) with SMTP id CFFCE8FC16 for ; Mon, 19 Apr 2010 13:13:46 +0000 (UTC) Received: (qmail 29242 invoked by uid 60001); 19 Apr 2010 13:13:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271682826; bh=+JgZFNcC5a52FyySgsj7tH1ERj3Dm6R59Y4Hp3G/sjs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=bJEJY7qQU3gGinyDutto60aZHJ8rTakKhUIGiNomuOCaN3bOjdaWvNhLCIVls3s3TdQBpyDRrUeGizjfkCDvlIIP/PZ0JPxs7cDsQ8I0ETecd6ypVo80tCk0VTqS0nJWQll8aNfR8Uv2h9wiCuWgmRyoNZMUgQhB3NH+rMtz8o0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=qs0z4IcjuL5Z3g/SQlii3xRmKqxVRC4JoEaEDNVTregEWFryCLRt+Oepw6oh/cjA8W2qmMHq9cWLvCI1huAJooojvN5eXDFvUZ2xWEo/4eG+6xa0r2jukXLAcgkA7kaN1U8tLVcIcm+E8OJWMQ/hrwKViNwEK0oRzukMJlMAUgs=; Message-ID: <176926.27578.qm@web33306.mail.mud.yahoo.com> X-YMail-OSG: 1RgOndQVM1l21FAjBTLRux7N7iwlm1llImpb2PFGPbL_R9f Shfo4iVWUWSj2cug6z3Lkk_YmYPP8WoNhSHB_ioqReSzGN7JdXC6rUhhp4wh NR_R7ZN78F4wp_oqxq9rtV47MgcOoO.Ixv1pdW1A2n8Vo6ZrklfBo6ux3hmq MOkwmMrFykWGnCnkGsLMqbSbjCOuIwOMyiD8r8gwvqzkzwO3i_2l.kkVwjna lSzNphF1reqncm2HVcbAprDhvcHAgEU3Z9U1.SLpd6aE_nI9OnpUj6Xj3e57 h3qav9cr.fwLEAR8SGd_qllVJs8x6 Received: from [202.150.188.32] by web33306.mail.mud.yahoo.com via HTTP; Mon, 19 Apr 2010 06:13:46 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.100.260964 Date: Mon, 19 Apr 2010 06:13:46 -0700 (PDT) From: Rob To: FreeBSD Stable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: "8.6 The Configuration File" out of date? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 13:13:47 -0000 Garrett Cooper wrote: > > > machine i386 > > What architecture was this for -- amd64, i386, etc? But this line is not at all present in the GENERIC configuration of FreeBSD 8.0 release.... > > options COMPAT_43 > > Eh...? This still should be in there according to NOTES. It's not in the GENERIC kernel configuration... There is, however: options COMPAT_43TTY Is that a mistake then? R. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 15:12:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEBAE106567F for ; Mon, 19 Apr 2010 15:12:19 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f199.google.com (mail-qy0-f199.google.com [209.85.221.199]) by mx1.freebsd.org (Postfix) with ESMTP id 63BF28FC3F for ; Mon, 19 Apr 2010 15:12:19 +0000 (UTC) Received: by qyk37 with SMTP id 37so4498162qyk.8 for ; Mon, 19 Apr 2010 08:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bNDK/JCp+jOa5pjeZe/vtXYW/RkoaqB41NNNQPEzv6I=; b=CUp4d5LNNRXV1B0NUwdpBXxy7Sl3SP03uyG97gwDwXvUcZ51vDPQMjow2TpIvvY3qk Aiig7WDs034029VLmwX1EwVXSJmEwUjC3XPjbIr3PCuW+khu5TZ9muwTX6GvuD9XAoCs m9gITVD5z+qHi1oniDbVO5sQKHCB25C9gOQH0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jupHYjQ91Yho3Z16pRU+y6mVNszz+nEpcGZ1xJwNUMsAhZY8kYT6Pi5nrmKg846cGg mAC8wmPWQOBHfD2F7AXF1nWqgYrwryB5lGxOI+q8W5+3FrZttQnPIX2Aij12RVRMljxS RsRBiBRSelONYHDzmJHQWrafbcMXSqXVybFQ4= MIME-Version: 1.0 Received: by 10.229.28.85 with HTTP; Mon, 19 Apr 2010 08:12:18 -0700 (PDT) In-Reply-To: <176926.27578.qm@web33306.mail.mud.yahoo.com> References: <176926.27578.qm@web33306.mail.mud.yahoo.com> Date: Mon, 19 Apr 2010 08:12:18 -0700 Received: by 10.229.233.199 with SMTP id jz7mr3173448qcb.56.1271689938261; Mon, 19 Apr 2010 08:12:18 -0700 (PDT) Message-ID: From: Garrett Cooper To: Rob Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Subject: Re: "8.6 The Configuration File" out of date? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 15:12:19 -0000 On Mon, Apr 19, 2010 at 6:13 AM, Rob wrote: > Garrett Cooper wrote: >> >> > machine =A0 =A0 =A0 =A0i386 >> >> What architecture was this for -- amd64, i386, etc? > > But this line is not at all present in the GENERIC > configuration of FreeBSD 8.0 release.... Probably because there was unnecessary overlap with `cpu ...'. >> > options =A0 =A0 =A0 =A0 =A0COMPAT_43 >> >> Eh...? This still should be in there according to NOTES. > > It's not in the GENERIC kernel configuration... > There is, however: > > options =A0 =A0 =A0 =A0 COMPAT_43TTY > > Is that a mistake then? Not IIRC; they were just preparing to remove the need for COMPAT_43 entirely in 8.1 (I think). Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 15:23:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5C5A10656AB for ; Mon, 19 Apr 2010 15:23:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 97A588FC21 for ; Mon, 19 Apr 2010 15:23:44 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4A79446B51; Mon, 19 Apr 2010 11:23:44 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 8FCE88A026; Mon, 19 Apr 2010 11:23:43 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 19 Apr 2010 09:55:21 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <20100419021107.GA5835@honinbu.il.thewrittenword.com> In-Reply-To: <20100419021107.GA5835@honinbu.il.thewrittenword.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004190955.21163.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 19 Apr 2010 11:23:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Albert Chin Subject: Re: cyclades driver in 8.0-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 15:23:44 -0000 On Sunday 18 April 2010 10:11:07 pm Albert Chin wrote: > Just updated to 8.0-RELEASE and recompiling 8.0-STABLE with the > following addition to GENERIC: > device cy > options CY_PCI_FASTINTR > > Building the kernel with: > make buildkernel KERNCONF=NEWKERNEL > gives me: > cc -c -O -pipe -march=pentium4 -std=c99 -g -Wall -Wredundant-decls - Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith - Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/opt/freebsd/src/sys -I/opt/freebsd/src/sys/contrib/altq -D_KERNEL - DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline- limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow - mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /opt/freebsd/src/sys/dev/cy/cy.c > /opt/freebsd/src/sys/dev/cy/cy.c:251: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cybreak' > /opt/freebsd/src/sys/dev/cy/cy.c:252: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cymodem' > /opt/freebsd/src/sys/dev/cy/cy.c:253: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cyopen' > /opt/freebsd/src/sys/dev/cy/cy.c:254: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cyclose' > cc1: warnings being treated as errors > > FreeBSD 7 had: > typedef void t_break_t(struct tty *, int); > in > > This is no longer present in FreeBSD 8. Oversight? Should I be able to > compile the cyclades driver for FreeBSD 8? No, it is not presently supported on 8. It needs to be ported to the new tty layer. You could perhaps ask ed@FreeBSD.org for some assistance. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 16:16:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5AE61065674 for ; Mon, 19 Apr 2010 16:16:53 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id A98278FC18 for ; Mon, 19 Apr 2010 16:16:53 +0000 (UTC) Received: by iwn42 with SMTP id 42so2486448iwn.14 for ; Mon, 19 Apr 2010 09:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=TtLuPHaoMBvOFszzlozuvRgZZNGbGty/63jxAqlHnv0=; b=xaCCOjnlB76Wi86l7vbHB55cW7/xnmm0xPIBrGDVcK/Ay+DqtssZubcI/wpt9qucAD wL9WBveJhLpCUU1daQkkP3X5QDNu/Jg3hlxCVF3OT6+GL7uICbFBaTMZfxjr++5pXU+g cezia6h796wQ0keVrds2dv1+8QUMLOGDcPBMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=VvIpz5W7rmY4of0BuRHFvQKBt90D14olLsOXOsGXgdamSzI2sNbXIRFyatLeIFFZBC fnAVC7rzJEuZm60f3thvrZvH53SBPCKXfPhx2KrmEMBb12wjWdLUvvSSyT9kD08Rjfof vJdUYBlTf//qSt8eMfvUT7tMahxC/YPLFq0p8= MIME-Version: 1.0 Received: by 10.231.14.76 with HTTP; Mon, 19 Apr 2010 09:16:52 -0700 (PDT) In-Reply-To: References: <176926.27578.qm@web33306.mail.mud.yahoo.com> Date: Mon, 19 Apr 2010 09:16:52 -0700 Received: by 10.231.150.2 with SMTP id w2mr1963003ibv.90.1271693812944; Mon, 19 Apr 2010 09:16:52 -0700 (PDT) Message-ID: From: Freddie Cash To: FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: "8.6 The Configuration File" out of date? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 16:16:54 -0000 On Mon, Apr 19, 2010 at 8:12 AM, Garrett Cooper wrote: > On Mon, Apr 19, 2010 at 6:13 AM, Rob wrote: > > Garrett Cooper wrote: > >> > >> > machine i386 > >> > >> What architecture was this for -- amd64, i386, etc? > > > > But this line is not at all present in the GENERIC > > configuration of FreeBSD 8.0 release.... > > Probably because there was unnecessary overlap with `cpu ...'. > > No, it's been moved to DEFAULTS, along with a handful of other things that should always be present in an i386 kernel (isa, npx, mem, io, etc). Same for amd64. "machine amd64" is in DEFAULTS, not GENERIC. >> > options COMPAT_43 > >> > >> Eh...? This still should be in there according to NOTES. > > > > It's not in the GENERIC kernel configuration... > > There is, however: > > > > options COMPAT_43TTY > > > > Is that a mistake then? > > Not IIRC; they were just preparing to remove the need for COMPAT_43 > entirely in 8.1 (I think). > One does not need COMPAT_43 anymore, as the few remaining bits that are required were moved to COMPAT_43TTY. One can build a kernel without COMPAT_43 (been doing that for awhile now). -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 18:05:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7B761065673 for ; Mon, 19 Apr 2010 18:05:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 722F28FC19 for ; Mon, 19 Apr 2010 18:05:21 +0000 (UTC) Received: (qmail 31445 invoked by uid 399); 19 Apr 2010 18:05:20 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 19 Apr 2010 18:05:20 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BCC9B5D.5020603@FreeBSD.org> Date: Mon, 19 Apr 2010 11:05:17 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Reilly References: <20100418213727.GA98129@icarus.home.lan> <20100418232420.GA4620@duncan.reilly.home> In-Reply-To: <20100418232420.GA4620@duncan.reilly.home> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 18:05:21 -0000 On 4/18/2010 4:24 PM, Andrew Reilly wrote: > By way of discussion, I'd just like to re-iterate what I > said the first time around: it must be understood that this > sort of thing is a (necessary) hacky-workaround that should > ultimately be unnecessary. While I find the discussion about launchd-type facilities interesting, we have a real problem at the moment and now we have a real solution for it. Jeremy, since no one has criticized your idea on a technical basis why don't you run it by the -net and -rc lists to be sure that it's technically sound, then I would be inclined to move forward with it. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 18:12:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D7511065672; Mon, 19 Apr 2010 18:12:35 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f199.google.com (mail-qy0-f199.google.com [209.85.221.199]) by mx1.freebsd.org (Postfix) with ESMTP id 319658FC0C; Mon, 19 Apr 2010 18:12:34 +0000 (UTC) Received: by qyk37 with SMTP id 37so4744091qyk.8 for ; Mon, 19 Apr 2010 11:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=f0nGkZJQbnCEbXBrnYtLwTSxRYT+qxDtsgPpeJsLqvY=; b=XrFYZv5kL6vGhMa3mNz9G7hVFQ8eeQDf9XXuiROZvDSWez54KJtdPvRXX1m2N0xaVU GqCcQa96mIOMMSk1ke2pxAHz8kKk5UnO6Xc4ju9NgivtUsksxYzLxUzAwNm3GwfeDuVR EEUch8YnbwODY8zkEuLhDeeFCf3gTlvQXxeMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LDiurnII5S/g5M0MxoBgLquSMCfJRcGCW1LIHi+08jus2IrASm9RJTNI07S+VGw4TB 9B2YjneIYi5sovEPEhvZGCrPgNKYOP9dQvbZZpuxLc+nUp5dYtijHabnXpVPAHCuLvVK NaywsTKN4NfIfz3WYu1Dl+llvVfWqHqQzF73s= MIME-Version: 1.0 Received: by 10.229.28.85 with HTTP; Mon, 19 Apr 2010 11:12:34 -0700 (PDT) In-Reply-To: <4BCC9B5D.5020603@FreeBSD.org> References: <20100418213727.GA98129@icarus.home.lan> <20100418232420.GA4620@duncan.reilly.home> <4BCC9B5D.5020603@FreeBSD.org> Date: Mon, 19 Apr 2010 11:12:34 -0700 Received: by 10.229.221.78 with SMTP id ib14mr2218537qcb.28.1271700754383; Mon, 19 Apr 2010 11:12:34 -0700 (PDT) Message-ID: From: Garrett Cooper To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 18:12:35 -0000 On Mon, Apr 19, 2010 at 11:05 AM, Doug Barton wrote: > On 4/18/2010 4:24 PM, Andrew Reilly wrote: >> By way of discussion, I'd just like to re-iterate what I >> said the first time around: it must be understood that this >> sort of thing is a (necessary) hacky-workaround that should >> ultimately be unnecessary. > > While I find the discussion about launchd-type facilities interesting, > we have a real problem at the moment and now we have a real solution for it. > > Jeremy, since no one has criticized your idea on a technical basis why > don't you run it by the -net and -rc lists to be sure that it's > technically sound, then I would be inclined to move forward with it. Agreed. Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 18:16:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0739B106566C; Mon, 19 Apr 2010 18:16:26 +0000 (UTC) (envelope-from tomelite82@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 934DC8FC12; Mon, 19 Apr 2010 18:16:25 +0000 (UTC) Received: by vws18 with SMTP id 18so229642vws.13 for ; Mon, 19 Apr 2010 11:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=r5HOjLStbV87e+IF7+R9PFQ573DEr0BfkUkgSo357rI=; b=TtNC/a8aob7V/Hv3Kt21AD0QxjIU3qHSmT4kskr43LGeNp3aBuq6tStOGGWRRaU6zK ErU8lEH7zx4YSdujCzog7bwOS+HKPIcz9lpFY11AxRDbElOdwExgdVteiFboX/kEHgBA WP1z6x3WH20knl5MVIg8Ax7Fjfk0vzP/TQvEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=tVJV4Z41Q/Z65sJyCAqRs9z9MSvizrcFdQb8BxNPCC3s/4jajXb926ru091q3NT3D9 MaoX2eS4hTFictwn1PoV+fFTh1UnMS3JeYpEPLLPozR/MBf2+pxqfMoAls6e1zK+HfIq unrp3t4gkcigGXLBnpgBC4xdvSN/NY9T0rQX8= MIME-Version: 1.0 Sender: tomelite82@gmail.com Received: by 10.220.76.71 with HTTP; Mon, 19 Apr 2010 10:50:07 -0700 (PDT) In-Reply-To: References: <4B28F841.1070900@skylinetele.com> Date: Mon, 19 Apr 2010 10:50:07 -0700 X-Google-Sender-Auth: 554a4fe646b39f4c Received: by 10.220.157.206 with SMTP id c14mr3771040vcx.230.1271699407439; Mon, 19 Apr 2010 10:50:07 -0700 (PDT) Message-ID: From: Qing Li To: Marin Atanasov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, "Li, Qing" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, "Prokofiev S.P." Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 18:16:26 -0000 Have you seen this thread? http://lists.freebsd.org/pipermail/freebsd-net/2010-April/025128.html Quite a few fixes have gone into the -current and RELENG_8 branches. Please try sync-up to the latest code before applying the patch. -- Qing On Sun, Apr 18, 2010 at 11:53 PM, Marin Atanasov wrote: > Hi, > > I was setting up mpd5 from ports, but this proxy-arp issue still exists i= n > 8.0. > >> uname -r > 8.0-RELEASE-p2 > > I've attached the output from the mpd5 daemon, where you can still see th= at > the issue is relevant. > > I've also tried to apply the patch, but it's no longer on that location. > Something else to add - I've a dns server running on the same machine tha= t > mpd5 was set up. I'm not sure if this is caused by mpd5 daemon or the arp > issue, but after a couple of start/stops of mpd5 the name resolving from = the > gateway machine is not possible, all other systems from the internal netw= ork > are able to use the dns server on the gateway, but the gateway itself > cannot. > > Restart of named, doesn't help either, so I had to completely reboot the > machine, so that arp entries are flushed as well. > > Could you please have a look at the issue? If you need some additional > information, please let me know. > > Regards, > Marin > > On Wed, Dec 16, 2009 at 6:09 PM, Prokofiev S.P. > wrote: >> >> Thank you ! >> The problem with proxy-arp has disappeared (FreeBSD 8-STABLE amd64 with >> mpd5). >> >> Please, somebody =A0fix =A0the bug kern/141285... >> >> >> Li, Qing wrote: >>> >>> Hi, >>> >>> Recently there have been several reports regarding issues with ppp, mpd= 5 >>> and proxy-arp configuration over the ppp links. I read through the >>> various postings and the problems seem to be: >>> >>> 1. Unable to add proxy-arp entries for the remote ppp clients. >>> >>> 2. Log showing "ifa_add_loopback_route: insertion failed" causing =A0 = =A0some >>> userland applications to fail. >>> >>> May I ask that you try applying patch >>> >>> =A0http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff >>> >>> and report back if the patch fixes your problems. And if not, please >>> describe what additional issues you are having. >>> >>> Thanks, >>> >>> -- Qing >>> >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >>> >>> >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org= " > > > > -- > Marin Atanasov Nikolov > dnaeon AT gmail DOT com > daemon AT unix-heaven DOT org > From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 18:54:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9FEC1065686 for ; Mon, 19 Apr 2010 18:54:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 7D3768FC2B for ; Mon, 19 Apr 2010 18:54:48 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 7V9i1e00C1eYJf8A1Wuoeg; Mon, 19 Apr 2010 18:54:48 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta19.emeryville.ca.mail.comcast.net with comcast id 7Wuo1e0013S48mS01Wuoaf; Mon, 19 Apr 2010 18:54:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B8BFA9B419; Mon, 19 Apr 2010 11:54:46 -0700 (PDT) Date: Mon, 19 Apr 2010 11:54:46 -0700 From: Jeremy Chadwick To: Doug Barton Message-ID: <20100419185446.GA36397@icarus.home.lan> References: <20100418213727.GA98129@icarus.home.lan> <20100418232420.GA4620@duncan.reilly.home> <4BCC9B5D.5020603@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BCC9B5D.5020603@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 18:54:48 -0000 On Mon, Apr 19, 2010 at 11:05:17AM -0700, Doug Barton wrote: > On 4/18/2010 4:24 PM, Andrew Reilly wrote: > > By way of discussion, I'd just like to re-iterate what I > > said the first time around: it must be understood that this > > sort of thing is a (necessary) hacky-workaround that should > > ultimately be unnecessary. > > While I find the discussion about launchd-type facilities interesting, > we have a real problem at the moment and now we have a real solution for it. > > Jeremy, since no one has criticized your idea on a technical basis why > don't you run it by the -net and -rc lists to be sure that it's > technically sound, then I would be inclined to move forward with it. Doug and Garrett -- thanks. I'll send a shorter mail to said lists referencing the discussion here on -stable and let folks weigh in. Much appreciated! -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 19:32:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D288B1065670 for ; Mon, 19 Apr 2010 19:32:38 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 6CEED8FC15 for ; Mon, 19 Apr 2010 19:32:38 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1O3whE-0003mR-V7 for freebsd-stable@freebsd.org; Mon, 19 Apr 2010 20:31:52 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O3whE-000GSB-UC for freebsd-stable@freebsd.org; Mon, 19 Apr 2010 20:31:52 +0100 Date: Mon, 19 Apr 2010 20:31:52 +0100 Message-Id: To: freebsd-stable@freebsd.org From: Pete French Subject: Problems with gmirror locking up on recent 8.0-STABLE/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 19:32:38 -0000 I have a machine used as a firewall which boots from a pair of drives mirrored using gmirror. This has been in situ for a long time, and was upgraded to 8.0 a while ago. Just before the weekend I upgraded the kernel to the latest STABLE to get the new em code. After doing this I observed that at seemingly random points the disc system would 'lockup' by which I mean that all networking continued fine, but if you tried to do anything which would read or write the disc then that would pause forever. Only fixed by reboot, and on reboot the array was degraded, and always resynced the same drive. "dying drive" I thought to myself - seemed a resonable conclusion. Except today I took another machine (completelt different hardware BTW) and build a new system with different drives, but the same gmirrored configuration - and an hour after I had installed it, it locked up in exactly the same way. Just after I upgraded it to match the version of the kernel running onthe original one in fact. So now I am wondering if there is some unfortunate problem which has crept into gmirror in the last few weeks. Has anyone else seen anything like this ? -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 20:30:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 085871065674 for ; Mon, 19 Apr 2010 20:30:05 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 27ACF8FC1A for ; Mon, 19 Apr 2010 20:30:04 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1O3xbL-00047f-T7; Mon, 19 Apr 2010 21:29:51 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O3xbL-000Gae-SC; Mon, 19 Apr 2010 21:29:51 +0100 Date: Mon, 19 Apr 2010 21:29:51 +0100 Message-Id: To: freebsd-stable@freebsd.org, petefrench@ticketswitch.com In-Reply-To: From: Pete French Cc: Subject: Re: Problems with gmirror locking up on recent 8.0-STABLE/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 20:30:05 -0000 Just following up my own email, but soemthing is definitely up with gmirror, as it has got to 100% complete on the resync, but stays in degraded mode... i.e. $ gmirror status Name Status Components mirror/pair0 DEGRADED da0s1 da1s1 (100%) this, obviously, shouldn't happen should it ? I am thinking maybe I should resync my code and rebuild my kernel. -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Apr 19 23:14:36 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E50CE106566B; Mon, 19 Apr 2010 23:14:36 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from worf.ds9.tecnik93.com (worf.ds9.tecnik93.com [81.196.207.130]) by mx1.freebsd.org (Postfix) with ESMTP id 97CB38FC08; Mon, 19 Apr 2010 23:14:36 +0000 (UTC) Received: from it.buh.tecnik93.com (it.buh.tecnik93.com [81.196.204.98]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by worf.ds9.tecnik93.com (Postfix) with ESMTPSA id 7F6AB22C50C9; Tue, 20 Apr 2010 02:14:35 +0300 (EEST) Date: Tue, 20 Apr 2010 02:14:20 +0300 From: Ion-Mihai Tetcu To: Ion-Mihai Tetcu Message-ID: <20100420021420.22e22136@it.buh.tecnik93.com> In-Reply-To: <20100328163828.1f34e0e7@it.buh.tecnik93.com> References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/mwd84L/W4VAdm.WDKCG8lL."; protocol="application/pgp-signature" Cc: stable@freebsd.org, questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 23:14:37 -0000 --Sig_/mwd84L/W4VAdm.WDKCG8lL. Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable A switch to use newer GMP version has been committed. Unfortunately lang/ghc and dependent ports (and possibly lang/gnat-gcc44) were broken by this. The brokenness wasn't detected in our -exp run because of being masked by other issues. It will take a few days to fix lang/ghc. I'm still investigating lang/gnat-gcc44. As a workaround, keep your old gmp library in /usr/local/lib/compat/pkg; both portmaster and portupdate have an option for this. X11 is still in work, the other are waiting for it. --=20 IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B --Sig_/mwd84L/W4VAdm.WDKCG8lL. Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvM49oACgkQJ7GIuiH/oeW1CwCgpBrP0/W1OL6tUDw0hVTSdSxh YSkAn1s0IRsDr2gs8SERGR5PbVt0AeBV =N7re -----END PGP SIGNATURE----- --Sig_/mwd84L/W4VAdm.WDKCG8lL.-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 00:07:55 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22B7E106566C; Tue, 20 Apr 2010 00:07:55 +0000 (UTC) (envelope-from freebsd-ports@coreland.ath.cx) Received: from birch.site5.com (birch.site5.com [174.132.116.226]) by mx1.freebsd.org (Postfix) with ESMTP id F0EAF8FC1C; Tue, 20 Apr 2010 00:07:54 +0000 (UTC) Received: from dsl78-143-206-24.in-addr.fast.co.uk ([78.143.206.24] helo=viper.internal.network) by birch.site5.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1O40YS-0004Qw-TU; Mon, 19 Apr 2010 18:39:05 -0500 Received: by viper.internal.network (Postfix, from userid 11001) id 9E7314AC0B; Mon, 19 Apr 2010 23:38:58 +0000 (UTC) Date: Mon, 19 Apr 2010 23:38:58 +0000 From: freebsd-ports@coreland.ath.cx To: Ion-Mihai Tetcu Message-ID: <20100419233858.GC43612@logik.internal.network> References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <20100420021420.22e22136@it.buh.tecnik93.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100420021420.22e22136@it.buh.tecnik93.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - birch.site5.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - coreland.ath.cx X-Source: X-Source-Args: X-Source-Dir: Cc: stable@freebsd.org, questions@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 00:07:55 -0000 On 2010-04-20 02:14:20, Ion-Mihai Tetcu wrote: > A switch to use newer GMP version has been committed. > > I'm still investigating lang/gnat-gcc44. As far as I know, the gnat-gcc44 bootstrap binaries will be fine as they're bundled with the libgmp library that was used to build them. Whether gcc builds with the newer libgmp remains to be seen... M From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 00:40:37 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CC36106566C; Tue, 20 Apr 2010 00:40:37 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id EF13B8FC0C; Tue, 20 Apr 2010 00:40:36 +0000 (UTC) Received: by qyk11 with SMTP id 11so5682340qyk.13 for ; Mon, 19 Apr 2010 17:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=UDCdbQL7pxFSgj6BIcuL5QzA7h1+cfM+9+ohqAaX7fg=; b=WWpP5u5gC4QCR9kKXkBsPUn2ELg1gZ1PH6OYkuc01Hetw4THNgiJZFlcb1igw94TYE v6eGvBI+CupJOBRF/raLG330Ry5HcWG5P2oIpuflp7JXxCDF3P2gO0OwJ/VDJu8N0gHv 3XXbyo2r9gQSCiz4AVagzxjyrqA8HEhYiIHhM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Dsb3262bCWmw29AV46Ex5UQijsXtQcmYbHAJC+vsupbanc19RuhBeE9DwWwXhXY0+f WmGDXnbl4+W72ZmWJw67ShJAI3ffcNJ+Y+qBTWAKNt1tm9Hdc9vgHHConSWv7THZMfxe 2OkWPQpyRuy70bGzQDA5rkWhZcQoO37X+91JA= MIME-Version: 1.0 Received: by 10.229.28.85 with HTTP; Mon, 19 Apr 2010 17:40:35 -0700 (PDT) In-Reply-To: <20100419233858.GC43612@logik.internal.network> References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <20100420021420.22e22136@it.buh.tecnik93.com> <20100419233858.GC43612@logik.internal.network> Date: Mon, 19 Apr 2010 17:40:35 -0700 Received: by 10.229.192.10 with SMTP id do10mr2143635qcb.48.1271724036067; Mon, 19 Apr 2010 17:40:36 -0700 (PDT) Message-ID: From: Garrett Cooper To: freebsd-ports@coreland.ath.cx Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, Ion-Mihai Tetcu , questions@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 00:40:37 -0000 On Mon, Apr 19, 2010 at 4:38 PM, wrote: > On 2010-04-20 02:14:20, Ion-Mihai Tetcu wrote: >> A switch to use newer GMP version has been committed. >> >> I'm still investigating lang/gnat-gcc44. > > As far as I know, the gnat-gcc44 bootstrap binaries will be > fine as they're bundled with the libgmp library that was used > to build them. Whether gcc builds with the newer libgmp remains > to be seen... As discussed in the QAT emails, it might be related to ccache use on the build cluster graciously donated by ixSystems, and the fact that the cached data is inconsistently distributed across the cluster. I've provided some tips for itetcu to work around this on IRC (basically disable ccache), but it kind of sucks when you run into periodic issues with toolchain variance like this, s.t. building with NO_CACHE=yes is a necessary evil to work through end-to-end build functional issues. Someone else who knows more about ccache could provide a better explanation of what's going on because my ranting about this would only be me talking out of my rear :). More info about ccache with FreeBSD can be found here: http://forums.freebsd.org/archive/index.php/t-174.html Cheers, -Garrett From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 03:13:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F59F1065672 for ; Tue, 20 Apr 2010 03:13:04 +0000 (UTC) (envelope-from spamrefuse@yahoo.com) Received: from web33306.mail.mud.yahoo.com (web33306.mail.mud.yahoo.com [68.142.206.121]) by mx1.freebsd.org (Postfix) with SMTP id 296918FC0C for ; Tue, 20 Apr 2010 03:13:03 +0000 (UTC) Received: (qmail 33274 invoked by uid 60001); 20 Apr 2010 03:13:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1271733183; bh=r06QI12kPZa6USYMGMJPQszRbV7yHDU1ydM794S0Ggw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=KCyN7tFFfmh0dQ/HoPnsXhgBq8eGG+9pKUIEj4WJ0RfZ1zjSBf+6/dWNxeiivGuBNVlTf7UKuOZE73gZGzqJtu64yNQD4iS/mPSrY7xNEGrRNDYSK8oqaQWXNJ2ncmEQcwcf41YbJrLeCD7cknYOFcAYS+L1y1JObS85WMs5RSY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=Mk0VgCZ0Hlld8DFtcb4UPBFtC0k73sncv07KSbkRd8bdI6qlJQEl4lgC2jKlYMuseZ5ShIctqJxMNg8nhy5xg9izrDC27BJYZF5U7dIt7ODCfM2Z4dIXUHtTl7WdKtZ0xLRGumHY/UVu3Y4HX6RCcOcsbP/Xd2XPPjBmUhD8Eio=; Message-ID: <333144.31435.qm@web33306.mail.mud.yahoo.com> X-YMail-OSG: sKYb_swVM1micijMJIcBR9KODMchtGPoxCh.pCWrSKa1Ere hKl7RherBzbNGIWp8guWu6jkU9JvaJTCxwgRglaeHBFjZ1AVwtcHeQCbjJ53 LUvlEMhO_VUwnRBzXbilHb_56sncum7mt9vjubOLq5QZQBA8k_f6y86S6Nl_ ndAEcKzERnEwGxqZlhHpKeFDBDXg1vX6qGkAnrzrfrsgz1B_nPZSY34kDwIj sXi0YN3czWaMLAFpJepRk3ar.Y0lOG9LIM2QvpApk4tjl0PXOkNRnIIxMLi. UENLTDrIMQ3HHnRZJYolm Received: from [202.150.188.32] by web33306.mail.mud.yahoo.com via HTTP; Mon, 19 Apr 2010 20:13:03 PDT X-Mailer: YahooMailRC/348.5 YahooMailWebService/0.8.100.260964 Date: Mon, 19 Apr 2010 20:13:03 -0700 (PDT) From: Rob To: FreeBSD Stable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: "8.6 The Configuration File" out of date? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 03:13:04 -0000 Freddie Cash wrote: > > No, it's been moved to DEFAULTS, along with a handful of > other things that should always be present in an i386 kernel > (isa, npx, mem, io, etc). Is the DEFAULTS configuration automagically included into a custom kernel configuration file, or does it then require an extra line: include DEFAULTS to have these defaults included? Is this documented somewhere? Thanks. R. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 03:20:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E222106564A for ; Tue, 20 Apr 2010 03:20:24 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gx0-f211.google.com (mail-gx0-f211.google.com [209.85.217.211]) by mx1.freebsd.org (Postfix) with ESMTP id CD9758FC27 for ; Tue, 20 Apr 2010 03:20:23 +0000 (UTC) Received: by gxk3 with SMTP id 3so2385420gxk.13 for ; Mon, 19 Apr 2010 20:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=kDLJjw7NWFFquV43CyC1abVC2KQCIQEYDbQipA6tglQ=; b=A208sLQseFzLjKlrtYY5u1nV1ObyvhcsDp4TmHz/y2JFJcd5uAZgHW7K3XQgcqtSrW ZXJzyFbFs9EkblYfdQrUOiTEgee1cE+87iCcChPn7Yao0pnm+eVa2ySrkah/jV5Gzoou KLUb3npJ/c7ZS+tYo0At64XTN9W/LylVelupc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=rAPddoWU16bnrSna1h4SNmTEcg4loc2j+FKotWW/2OcJ82KqgDdIPNnLBfb7wt1hMp +r1fnufjvzBSE41cuvINAHFZbYBOcl3++51IP2och8R2GF9MtOLHsTUawjDweTafEp8P 1ccx0SZQ3Ux1vUobQqdOK2GKfxBmpQrBMY0/s= MIME-Version: 1.0 Received: by 10.231.14.76 with HTTP; Mon, 19 Apr 2010 20:20:22 -0700 (PDT) In-Reply-To: <333144.31435.qm@web33306.mail.mud.yahoo.com> References: <333144.31435.qm@web33306.mail.mud.yahoo.com> Date: Mon, 19 Apr 2010 20:20:22 -0700 Received: by 10.100.88.10 with SMTP id l10mr14217953anb.184.1271733622270; Mon, 19 Apr 2010 20:20:22 -0700 (PDT) Message-ID: From: Freddie Cash To: FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: "8.6 The Configuration File" out of date? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 03:20:24 -0000 On Mon, Apr 19, 2010 at 8:13 PM, Rob wrote: > Freddie Cash wrote: > > > > No, it's been moved to DEFAULTS, along with a handful of > > other things that should always be present in an i386 kernel > > (isa, npx, mem, io, etc). > > Is the DEFAULTS configuration automagically included into a > custom kernel configuration file, or does it then require an > extra line: > > include DEFAULTS > > to have these defaults included? > > You'd have to double-check the Makefiles and whatnot, but I believe it's pulled in to every kernel build, not matter what. Hence the name. :) > Is this documented somewhere? > In the Makefiles? -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 05:48:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2419C106566C for ; Tue, 20 Apr 2010 05:48:26 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id C2A2A8FC15 for ; Tue, 20 Apr 2010 05:48:25 +0000 (UTC) Received: by qyk11 with SMTP id 11so6040337qyk.13 for ; Mon, 19 Apr 2010 22:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=5RZFZQNceqq2/RRrnNklOxTSuNJXiv2VM8xym6T2zbs=; b=MCAErzsySteCuVExQpTujHfQ8LGB+8RLKErVS2nYMmLxqDVuUEoyNJcRgVn1pTlqMy whIsiZk+BXTbDDLhMTEzx26WISmAbqWlekGtWQ1BfqeK8tGOAyChCTNoPKzFKBIfQplk 4RlqsPzblGRde3534URH8mc8irMdyORX9U3Zg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=dCq0uBB4jTFiNUsw0jxe3+XXsylF/kyHxkn/0lA1DlT37nNvVunrPKECB4PobYc7Lg u/gv43oKL5gAQ7p9BfxcoCso+SXiy4BnEI8ZgbGj2fQhnGMxUxQe5Cdu9ic3TL/mxZK8 BgAy6K7+FmNMZW+qtnviO/zZCxtyAvIEkWn2c= Received: by 10.224.60.5 with SMTP id n5mr2052705qah.288.1271742504762; Mon, 19 Apr 2010 22:48:24 -0700 (PDT) Received: from centel.dataix.local (c-71-205-129-194.hsd1.mi.comcast.net [71.205.129.194]) by mx.google.com with ESMTPS id 23sm4517022qyk.15.2010.04.19.22.48.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 19 Apr 2010 22:48:23 -0700 (PDT) Sender: "J. Hellenthal" Date: Tue, 20 Apr 2010 01:48:11 -0400 From: jhell To: Barry Pederson In-Reply-To: <4BB0BC7C.3000801@barryp.org> Message-ID: References: <20100215090756.GA54764@icarus.home.lan> <20100215105000.101326yj01j0f64g@webmail.leidinger.net> <20100215122744.GA57382@icarus.home.lan> <20100215161105.14071eiflhc9le68@webmail.leidinger.net> <4B79BA9C.3020402@quip.cz> <4B7AD0A3.9080701@barryp.org> <4BB0BC7C.3000801@barryp.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Stable Subject: Re: ZFS Tuning - arc_summary.pl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 05:48:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 29 Mar 2010 10:43, Barry Pederson wrote: In Message-Id: <4BB0BC7C.3000801@barryp.org> > I've been using the arc_summary.pl script from here: > > http://jhell.googlecode.com/svn/base/head/scripts/zfs/arc_summary/arc_summary.pl > > and noticed some odd numbers, with the ARC Current Size being larger than the > Max Size, and the breakdown adding up to less than the current size as shown > below > > -------- > ARC Size: > Current Size: 992.71M (arcsize) > Target Size: (Adaptive) 512.00M (c) > Min Size (Hard Limit): 81.82M (arc_min) > Max Size (Hard Limit): 512.00M (arc_max) > > ARC Size Breakdown: > Recently Used Cache Size: 99.84% 511.18M (p) > Frequently Used Cache Size: 0.16% 0.82M (c-p) > -------- > > > From another thread I saw, it sounds like arc_max isn't really > a "Hard Limit" but rather some kind of high water mark. If that's > the case then I wonder if this might make more sense.... > > > > --------- > --- arc_summary.pl.original 2010-02-25 19:23:13.000000000 -0600 > +++ arc_summary.pl 2010-03-29 09:32:28.000000000 -0500 > @@ -121,20 +121,20 @@ > > my $arc_size = ${Kstat}->{zfs}->{0}->{arcstats}->{size}; > my $arc_size_MiB = ($arc_size / 1048576); > -my $mfu_size = $target_size - $mru_size; > +my $mfu_size = $arc_size - $mru_size; > my $mfu_size_MiB = ($mfu_size / 1048576); > -my $mru_perc = 100*($mru_size / $target_size); > -my $mfu_perc = 100*($mfu_size / $target_size); > +my $mru_perc = 100*($mru_size / $arc_size); > +my $mfu_perc = 100*($mfu_size / $arc_size); > > print "ARC Size:\n"; > printf("\tCurrent Size:\t\t\t\t%0.2fM (arcsize)\n", $arc_size_MiB); > printf("\tTarget Size: (Adaptive)\t\t\t%0.2fM (c)\n", $target_size_MiB); > printf("\tMin Size (Hard Limit):\t\t\t%0.2fM (arc_min)\n", > $arc_min_size_MiB); > -printf("\tMax Size (Hard Limit):\t\t\t%0.2fM (arc_max)\n", > $arc_max_size_MiB); > +printf("\tMax Size :\t\t\t%0.2fM (arc_max)\n", > $arc_max_size_MiB); > > print "\nARC Size Breakdown:\n"; > printf("\tRecently Used Cache Size:\t%0.2f%%\t%0.2fM (p)\n", $mru_perc, > $mru_size_MiB); > -printf("\tFrequently Used Cache Size:\t%0.2f%%\t%0.2fM (c-p)\n", $mfu_perc, > $mfu_size_MiB); > +printf("\tFrequently Used Cache Size:\t%0.2f%%\t%0.2fM (arcsize-p)\n", > $mfu_perc, $mfu_size_MiB); > print "\n"; > > ### ARC Efficency ### > > ----------- > > > Giving something like this... > > -------- > ARC Size: > Current Size: 992.88M (arcsize) > Target Size: (Adaptive) 512.00M (c) > Min Size (Hard Limit): 81.82M (arc_min) > Max Size : 512.00M (arc_max) > > ARC Size Breakdown: > Recently Used Cache Size: 51.48% 511.18M (p) > Frequently Used Cache Size: 48.52% 481.70M (arcsize-p) > -------- > > Barry > Barry, What branch and revision was this run on ? I need the above information because the output above just does not match up quite as it should and I want to investigate when, where & why as I believe something else is going on here that is not on the behalf of arc_summary.pl. Or if you could provide me personally with the full output of the script from the downloads section "just to be sure" in an attachment that would work as well. Thanks. - -- jhell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLzUAhAAoJEJBXh4mJ2FR+kP4H/3FSkazC+Jxv0q5XJhP/YfeP gJ0vWP+84J6HM68GyS4eCOu3QPGUPBAuqZOS8Bb9jXg9xNfxCvw2DQn5mP6v6i6H w8mWyYyCla7iBfItod4L2GjQeP52SIt7sW9icDeWvrS+LphwjTQmBiA4QwGBQT5D YiarUMpzY1Jkq8I6YgGYRIwZqeuNn7X68ZEKIz8/LhTM6WKdktm5dcBb6UM/mC/a I82sv+7mG/9Bn0Orp7DMqvym0rllYmb+Sj7Pj2NEcPt9LYDNf6Vy1Wmly6hNQTYb b8WkfgLeMogDN9JS6Bw+UxNGwHgQgqDIWvkKDt9qrmuTpKLEozD6GnBzo27uZkg= =RoRd -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 06:00:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D67E11065670; Tue, 20 Apr 2010 06:00:59 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id E2D1A8FC08; Tue, 20 Apr 2010 06:00:58 +0000 (UTC) Received: by wwa36 with SMTP id 36so3529884wwa.13 for ; Mon, 19 Apr 2010 23:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=lBOO4L+pUE7DhyJlGUS4A/ek8bm7/hi1IlFxKKVLHE0=; b=SiIVhzp+XRiIl30Mk5ESylRnRvqoeJjXwGZ/N3pEyDCCxe84onWm+IKypWuT7xXn5C awWsy2TcLvfhhQKLg+nDXJVK85VktyxsOSFheofWdPxPVYdmBn5NHAwIZDGMZi8xDOnR 881b0hUcWCjnOsNngQlt2y1ZaVtTfMbm/lzkI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vHjJf4r2lAMMkrHbvNTS8nyWwpE8eAcVHtOH2JYU0/50b/emQCbu+k3LGtvHCy2rzV G6wgoCmPn0mSnmnXU+zj96jvp7pc/Ldm6qQyjvoPGgFDl8gGj3NQEahGUCtn8x4ULePb hCTozUSfb/3GB7rqJXwsv/xAYtagqokvTM2o4= MIME-Version: 1.0 Received: by 10.216.13.7 with HTTP; Mon, 19 Apr 2010 23:00:57 -0700 (PDT) In-Reply-To: References: <4B28F841.1070900@skylinetele.com> Date: Tue, 20 Apr 2010 09:00:57 +0300 Received: by 10.216.86.67 with SMTP id v45mr832972wee.70.1271743257713; Mon, 19 Apr 2010 23:00:57 -0700 (PDT) Message-ID: From: Marin Atanasov To: Qing Li Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, "Li, Qing" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, "Prokofiev S.P." Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 06:00:59 -0000 Hello Qing, Seems I've missed that thread, thank you for pointing it out. I was using csup to track RELEN_8_0 branch. Currently I'm syncing to RELENG_8. If I understood you right, after getting the sources for RELENG_8, I need to apply the patch and then rebuild world? Thanks and regards, Marin On Mon, Apr 19, 2010 at 8:50 PM, Qing Li wrote: > Have you seen this thread? > > http://lists.freebsd.org/pipermail/freebsd-net/2010-April/025128.html > > Quite a few fixes have gone into the -current and RELENG_8 branches. > Please try sync-up to the latest code before applying the patch. > > -- Qing > > > > On Sun, Apr 18, 2010 at 11:53 PM, Marin Atanasov wrote: > > Hi, > > > > I was setting up mpd5 from ports, but this proxy-arp issue still exists > in > > 8.0. > > > >> uname -r > > 8.0-RELEASE-p2 > > > > I've attached the output from the mpd5 daemon, where you can still see > that > > the issue is relevant. > > > > I've also tried to apply the patch, but it's no longer on that location. > > Something else to add - I've a dns server running on the same machine > that > > mpd5 was set up. I'm not sure if this is caused by mpd5 daemon or the arp > > issue, but after a couple of start/stops of mpd5 the name resolving from > the > > gateway machine is not possible, all other systems from the internal > network > > are able to use the dns server on the gateway, but the gateway itself > > cannot. > > > > Restart of named, doesn't help either, so I had to completely reboot the > > machine, so that arp entries are flushed as well. > > > > Could you please have a look at the issue? If you need some additional > > information, please let me know. > > > > Regards, > > Marin > > > > On Wed, Dec 16, 2009 at 6:09 PM, Prokofiev S.P. > > wrote: > >> > >> Thank you ! > >> The problem with proxy-arp has disappeared (FreeBSD 8-STABLE amd64 with > >> mpd5). > >> > >> Please, somebody fix the bug kern/141285... > >> > >> > >> Li, Qing wrote: > >>> > >>> Hi, > >>> > >>> Recently there have been several reports regarding issues with ppp, > mpd5 > >>> and proxy-arp configuration over the ppp links. I read through the > >>> various postings and the problems seem to be: > >>> > >>> 1. Unable to add proxy-arp entries for the remote ppp clients. > >>> > >>> 2. Log showing "ifa_add_loopback_route: insertion failed" causing > some > >>> userland applications to fail. > >>> > >>> May I ask that you try applying patch > >>> > >>> http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff > >>> > >>> and report back if the patch fixes your problems. And if not, please > >>> describe what additional issues you are having. > >>> > >>> Thanks, > >>> > >>> -- Qing > >>> > >>> > >>> _______________________________________________ > >>> freebsd-net@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >>> > >>> > >>> > >> > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to " > freebsd-stable-unsubscribe@freebsd.org" > > > > > > > > -- > > Marin Atanasov Nikolov > > dnaeon AT gmail DOT com > > daemon AT unix-heaven DOT org > > > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 07:23:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69E5C106566C for ; Tue, 20 Apr 2010 07:23:14 +0000 (UTC) (envelope-from nr1c0re@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 936458FC1A for ; Tue, 20 Apr 2010 07:23:09 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so1633204fge.13 for ; Tue, 20 Apr 2010 00:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=vn9ChI9/oAHI9DFzaV7MbzO2WLRq7zMq42Jie+0aLp0=; b=xprhBr+9H2K9gxtnJ0AqiICLdndcXD4RFGK9y6qMfoADihj99yUxDJSTk9sEx8B302 c3Chn1PihOoeGP1GIoPpkJrjPUSC1mzqVL1PWx72Oldumhm5uSmglda5NNWFHOpoGiHz wmkqUMGclScHuwcuPwj8lFtWbBPlvN+gOkiw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=aIqp9JKH6HU1/mYPfSWmX/3kK9r+SIaw6l0dFiv5UhTvfsNslwmcl+mvKVAtjEZ9Qn i+SN4MJLtpnRY4ScLNBv83q1U34MV4SkWzRM2Cme51v1KggxD/Oi7DlqGkO/yjWGgc3J kh2UbxrQixI1XJ4Aat14DIBKKzjFqZT6Vr/mY= MIME-Version: 1.0 Received: by 10.86.84.6 with HTTP; Mon, 19 Apr 2010 23:53:16 -0700 (PDT) Date: Tue, 20 Apr 2010 10:53:16 +0400 Received: by 10.87.42.2 with SMTP id u2mr5258891fgj.79.1271746396275; Mon, 19 Apr 2010 23:53:16 -0700 (PDT) Message-ID: From: c0re To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD 7.3, reboot after panic: double fault X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 07:23:14 -0000 Hello All! I've upgraded freebsd from 7.0 to 7.3 and all was good until I tryed to configure gre interface and use ipfw fwd. I'm actually does not know what was the point of failure in my configuration. I got freebsd 7.0, next i made csup and: make buildworld && make kernel KERNCONF=MYKERNEL reboot to single user mode mergemaster -p make installworld make delete-old make delete-old-libs mergemaster -iF reboot And made some test to check that 7.3 works well. It worked about one week and then I made some configuration changes: added gre interface and 2 aliases: # cat /etc/rc.conf |grep ifconfig_xl0="inet 192.168.0.10 netmask 255.255.255.0" ifconfig_xl0_alias0="192.168.0.11 netmask 255.255.255.255" ifconfig_xl0_alias1="192.168.0.12 netmask 255.255.255.255" cloned_interfaces="gre0" ifconfig_gre0="inet 192.168.250.6 192.168.250.5 tunnel 192.168.0.12 192.168.200.15 netmask 255.255.255.252 link1 up" and # cat /etc/rc.local #!/bin/sh ipfw add fwd 192.168.250.5 icmp from 192.168.0.11 to any out via xl0 ipfw add fwd 192.168.250.5 tcp from 192.168.0.11 443 to any out via xl0 ipfw add allow ip from any to any # ifconfig gre0 gre0: flags=b050 metric 0 mtu 1476 tunnel inet 192.168.0.12 --> 192.168.200.15 inet 192.168.250.6 --> 192.168.250.5 netmask 0xfffffffc I shutted down gre interface to prevent requests via gre to buggy IP. The main idea of such configurations was: fwd all connections to https to 192.168.0.1 via gre interface. And also I made apache configurations to make it listen on 192.168.0.11 too. And make some tests: ping 192.168.0.11 - was fine, goes via gre. Telnet to 192.168.0.11 443 was fine too. Then I tryed to make browser https connection to 192.168.0.11. Apache showed me certificate warning and I accepted, then in browser nothing happened, it was trying to open page. But server got kernel panic at that moment. At first time I thought that it was some power failure, I tryed 2 more times and got same behaviour. So https works without kernel panic via 192.168.0.10 address but kernel panics when I try do https via 192.168.0.11 address that source-forwarded via gre. And some tech info: FreeBSD host.domain.com 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Wed Apr 14 23:41:15 NOVST 2010 root@host.domain.com:/usr/obj/usr/src/sys/MYKERNEL i386 dmesg after failure: host# dmesg Copyright (c) 1992-2010 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.3-RELEASE #0: Wed Apr 14 23:41:15 NOVST 2010 root@host.domain.com:/usr/obj/usr/src/sys/MYKERNEL i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 2.00GHz (2000.03-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 259981312 (247 MB) avail memory = 240336896 (229 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, f6f0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: mem 0xe0000000-0xe7ffffff,0xec100000-0xec17ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 8060k stolen memory agp0: aperture size is 128M uhci0: port 0xd800-0xd81f irq 16 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 0xd000-0xd01f 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 0xd400-0xd41f 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 ehci0: mem 0xec180000-0xec1803ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib1: at device 30.0 on pci0 pci1: on pcib1 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xc000-0xc07f mem 0xec020000-0xec02007f irq 22 at device 6.0 on pci1 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:03:99:88:79:2f xl0: [ITHREAD] fxp0: port 0xc400-0xc43f mem 0xec021000-0xec021fff irq 20 at device 8.0 on pci1 miibus1: on fxp0 inphy0: PHY 1 on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:0a:48:08:7d:0a fxp0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] 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 Explorer, device ID 4 cpu0: on acpi0 p4tcc0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xcc000-0xcc7ff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2000033152 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 initialized, divert enabled, nat loadable, rule-based forwarding enabled, default to deny, logging limited to 1000 packets/entry by default ad0: 76319MB at ata0-master UDMA100 ad2: 76319MB at ata1-master UDMA100 Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted host# tail /var/log/messages Apr 19 20:49:00 host kernel: WARNING: / was not properly dismounted Apr 19 20:49:00 host kernel: WARNING: /tmp was not properly dismounted Apr 19 20:49:00 host kernel: WARNING: /usr was not properly dismounted Apr 19 20:49:00 host kernel: WARNING: /var was not properly dismounted Apr 19 20:49:00 host savecore: reboot after panic: double fault Apr 19 20:49:00 host savecore: writing core to vmcore.2 Apr 19 20:49:31 host su: milyar to root on /dev/ttyp0 Apr 19 20:50:10 host fsck: /dev/ad0s1e: 30 files, 25 used, 1012990 free (70 frags, 126615 blocks, 0.0% fragmentation) Apr 19 20:51:56 host fsck: /dev/ad0s1f: 298037 files, 2009202 used, 3067877 free (103869 frags, 370501 blocks, 2.0% fragmentation) Apr 19 20:52:06 host fsck: /dev/ad0s1d: 22758 files, 749889 used, 263126 free (30022 frags, 29138 blocks, 3.0% fragmentation) _______________________________________________________________________________________ /var/log/messages after failure: Apr 19 20:49:00 host syslogd: kernel boot file is /boot/kernel/kernel Apr 19 20:49:00 host kernel: Copyright (c) 1992-2010 The FreeBSD Project. Apr 19 20:49:00 host kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Apr 19 20:49:00 host kernel: The Regents of the University of California. All rights reserved. Apr 19 20:49:00 host kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Apr 19 20:49:00 host kernel: FreeBSD 7.3-RELEASE #0: Wed Apr 14 23:41:15 NOVST 2010 Apr 19 20:49:00 host kernel: root@host.domain.com:/usr/obj/usr/src/sys/MYKERNEL i386 Apr 19 20:49:00 host kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Apr 19 20:49:00 host kernel: CPU: Intel(R) Celeron(R) CPU 2.00GHz (2000.03-MHz 686-class CPU) Apr 19 20:49:00 host kernel: Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Apr 19 20:49:00 host kernel: Features=0xbfebfbff Apr 19 20:49:00 host kernel: Features2=0x4400 Apr 19 20:49:00 host kernel: real memory = 259981312 (247 MB) Apr 19 20:49:00 host kernel: avail memory = 240336896 (229 MB) Apr 19 20:49:00 host kernel: ACPI APIC Table: Apr 19 20:49:00 host kernel: ioapic0 irqs 0-23 on motherboard Apr 19 20:49:00 host kernel: kbd1 at kbdmux0 Apr 19 20:49:00 host kernel: acpi0: on motherboard Apr 19 20:49:00 host kernel: acpi0: [ITHREAD] Apr 19 20:49:00 host kernel: acpi0: Power Button (fixed) Apr 19 20:49:00 host kernel: acpi0: reservation of 0, a0000 (3) failed Apr 19 20:49:00 host kernel: acpi0: reservation of 100000, f6f0000 (3) failed Apr 19 20:49:00 host kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Apr 19 20:49:00 host kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 Apr 19 20:49:00 host kernel: acpi_button0: on acpi0 Apr 19 20:49:00 host kernel: pcib0: port 0xcf8-0xcff on acpi0 Apr 19 20:49:00 host kernel: pci0: on pcib0 Apr 19 20:49:00 host kernel: vgapci0: mem 0xe0000000-0xe7ffffff,0xec100000-0xec17ffff irq 16 at device 2.0 on pci0 Apr 19 20:49:00 host kernel: agp0: on vgapci0 Apr 19 20:49:00 host kernel: agp0: detected 8060k stolen memory Apr 19 20:49:00 host kernel: agp0: aperture size is 128M Apr 19 20:49:00 host kernel: uhci0: port 0xd800-0xd81f irq 16 at device 29.0 on pci0 Apr 19 20:49:00 host kernel: uhci0: [GIANT-LOCKED] Apr 19 20:49:00 host kernel: uhci0: [ITHREAD] Apr 19 20:49:00 host kernel: usb0: on uhci0 Apr 19 20:49:00 host kernel: usb0: USB revision 1.0 Apr 19 20:49:00 host kernel: uhub0: on usb0 Apr 19 20:49:00 host kernel: uhub0: 2 ports with 2 removable, self powered Apr 19 20:49:00 host kernel: uhci1: port 0xd000-0xd01f irq 19 at device 29.1 on pci0 Apr 19 20:49:00 host kernel: uhci1: [GIANT-LOCKED] Apr 19 20:49:00 host kernel: uhci1: [ITHREAD] Apr 19 20:49:00 host kernel: usb1: on uhci1 Apr 19 20:49:00 host kernel: usb1: USB revision 1.0 Apr 19 20:49:00 host kernel: uhub1: on usb1 Apr 19 20:49:00 host kernel: uhub1: 2 ports with 2 removable, self powered Apr 19 20:49:00 host kernel: uhci2: port 0xd400-0xd41f irq 18 at device 29.2 on pci0 Apr 19 20:49:00 host kernel: uhci2: [GIANT-LOCKED] Apr 19 20:49:00 host kernel: uhci2: [ITHREAD] Apr 19 20:49:00 host kernel: usb2: on uhci2 Apr 19 20:49:00 host kernel: usb2: USB revision 1.0 Apr 19 20:49:00 host kernel: uhub2: on usb2 Apr 19 20:49:00 host kernel: uhub2: 2 ports with 2 removable, self powered Apr 19 20:49:00 host kernel: ehci0: mem 0xec180000-0xec1803ff irq 23 at device 29.7 on pci0 Apr 19 20:49:00 host kernel: ehci0: [GIANT-LOCKED] Apr 19 20:49:00 host kernel: ehci0: [ITHREAD] Apr 19 20:49:00 host kernel: usb3: EHCI version 1.0 Apr 19 20:49:00 host kernel: usb3: companion controllers, 2 ports each: usb0 usb1 usb2 Apr 19 20:49:00 host kernel: usb3: on ehci0 Apr 19 20:49:00 host kernel: usb3: USB revision 2.0 Apr 19 20:49:00 host kernel: uhub3: on usb3 Apr 19 20:49:00 host kernel: uhub3: 6 ports with 6 removable, self powered Apr 19 20:49:00 host kernel: pcib1: at device 30.0 on pci0 Apr 19 20:49:00 host kernel: pci1: on pcib1 Apr 19 20:49:00 host kernel: xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xc000-0xc07f mem 0xec020000-0xec02007f irq 22 at device 6.0 on pci1 Apr 19 20:49:00 host kernel: miibus0: on xl0 Apr 19 20:49:00 host kernel: xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 Apr 19 20:49:00 host kernel: xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Apr 19 20:49:00 host kernel: xl0: Ethernet address: 00:03:99:88:79:2f Apr 19 20:49:00 host kernel: xl0: [ITHREAD] Apr 19 20:49:00 host kernel: fxp0: port 0xc400-0xc43f mem 0xec021000-0xec021fff irq 20 at device 8.0 on pci1 Apr 19 20:49:00 host kernel: miibus1: on fxp0 Apr 19 20:49:00 host kernel: inphy0: PHY 1 on miibus1 Apr 19 20:49:00 host kernel: inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Apr 19 20:49:00 host kernel: fxp0: Ethernet address: 00:0a:48:08:7d:0a Apr 19 20:49:00 host kernel: fxp0: [ITHREAD] Apr 19 20:49:00 host kernel: isab0: at device 31.0 on pci0 Apr 19 20:49:00 host kernel: isa0: on isab0 Apr 19 20:49:00 host kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 31.1 on pci0 Apr 19 20:49:00 host kernel: ata0: on atapci0 Apr 19 20:49:00 host kernel: ata0: [ITHREAD] Apr 19 20:49:00 host kernel: ata1: on atapci0 Apr 19 20:49:00 host kernel: ata1: [ITHREAD] Apr 19 20:49:00 host kernel: pci0: at device 31.3 (no driver attached) Apr 19 20:49:00 host kernel: pci0: at device 31.5 (no driver attached) Apr 19 20:49:00 host kernel: acpi_tz0: on acpi0 Apr 19 20:49:00 host kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Apr 19 20:49:00 host kernel: fdc0: [FILTER] Apr 19 20:49:00 host kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Apr 19 20:49:00 host kernel: sio0: type 16550A Apr 19 20:49:00 host kernel: sio0: [FILTER] Apr 19 20:49:00 host kernel: sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 Apr 19 20:49:00 host kernel: sio1: type 16550A Apr 19 20:49:00 host kernel: sio1: [FILTER] Apr 19 20:49:00 host kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Apr 19 20:49:00 host kernel: atkbd0: irq 1 on atkbdc0 Apr 19 20:49:00 host kernel: kbd0 at atkbd0 Apr 19 20:49:00 host kernel: atkbd0: [GIANT-LOCKED] Apr 19 20:49:00 host kernel: atkbd0: [ITHREAD] Apr 19 20:49:00 host kernel: psm0: irq 12 on atkbdc0 Apr 19 20:49:00 host kernel: psm0: [GIANT-LOCKED] Apr 19 20:49:00 host kernel: psm0: [ITHREAD] Apr 19 20:49:00 host kernel: psm0: model IntelliMouse Explorer, device ID 4 Apr 19 20:49:00 host kernel: cpu0: on acpi0 Apr 19 20:49:00 host kernel: p4tcc0: on cpu0 Apr 19 20:49:00 host kernel: pmtimer0 on isa0 Apr 19 20:49:00 host kernel: orm0: at iomem 0xcc000-0xcc7ff pnpid ORM0000 on isa0 Apr 19 20:49:00 host kernel: ppc0: at port 0x378-0x37f irq 7 on isa0 Apr 19 20:49:00 host kernel: ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode Apr 19 20:49:00 host kernel: ppc0: FIFO with 16/16/9 bytes threshold Apr 19 20:49:00 host kernel: ppbus0: on ppc0 Apr 19 20:49:00 host kernel: ppbus0: [ITHREAD] Apr 19 20:49:00 host kernel: plip0: on ppbus0 Apr 19 20:49:00 host kernel: plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag Apr 19 20:49:00 host kernel: lpt0: on ppbus0 Apr 19 20:49:00 host kernel: lpt0: Interrupt-driven port Apr 19 20:49:00 host kernel: ppi0: on ppbus0 Apr 19 20:49:00 host kernel: ppc0: [GIANT-LOCKED] Apr 19 20:49:00 host kernel: ppc0: [ITHREAD] Apr 19 20:49:00 host kernel: sc0: at flags 0x100 on isa0 Apr 19 20:49:00 host kernel: sc0: VGA <16 virtual consoles, flags=0x300> Apr 19 20:49:00 host kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Apr 19 20:49:00 host kernel: Timecounter "TSC" frequency 2000033152 Hz quality 800 Apr 19 20:49:00 host kernel: Timecounters tick every 1.000 msec Apr 19 20:49:00 host kernel: ipfw2 initialized, divert enabled, nat loadable, rule-based forwarding enabled, default to deny, logging limited to 1000 packets/entry by default Apr 19 20:49:00 host kernel: ad0: 76319MB at ata0-master UDMA100 Apr 19 20:49:00 host kernel: ad2: 76319MB at ata1-master UDMA100 Apr 19 20:49:00 host kernel: Trying to mount root from ufs:/dev/ad0s1a Apr 19 20:49:00 host kernel: WARNING: / was not properly dismounted Apr 19 20:49:00 host kernel: WARNING: /tmp was not properly dismounted Apr 19 20:49:00 host kernel: WARNING: /usr was not properly dismounted Apr 19 20:49:00 host kernel: WARNING: /var was not properly dismounted Apr 19 20:49:00 host savecore: reboot after panic: double fault Apr 19 20:49:00 host savecore: writing core to vmcore.2 _______________________________________________________________________________________ kernel config: # cat /usr/src/sys/i386/conf/MYKERNEL # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.474.2.22.2.1 2010/02/10 00:26:20 kensmith Exp $ #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident MYKERNEL # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking #options INET6 # IPv6 communications protocols #options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing #options KDTRACE_HOOKS # Kernel DTrace hooks options INCLUDE_CONFIG_FILE # Include this file in kernel # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. device amd # AMD 53C974 (Tekram DC-390(T)) device hptiop # Highpoint RocketRaid 3xxx series device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mfi # LSI MegaRAID SAS device mlx # Mylex DAC960 family device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 Gigabit Ethernet Family device igb # Intel PRO/1000 PCIE Server Gigabit Family device ixgb # Intel PRO/10GbE Ethernet Card device le # AMD Am7900 LANCE and Am79C9xx PCnet device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device age # Attansic/Atheros L1 Gigabit Ethernet device alc # Atheros AR8131/AR8132 Ethernet device ale # Atheros AR8121/AR8113/AR8114 Ethernet device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device et # Agere ET1310 10/100/Gigabit Ethernet device fxp # Intel EtherExpress PRO/100B (82557, 82558) device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nfe # nVidia nForce MCP on-board Ethernet device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device wlan_scan_ap # 802.11 AP mode scanning device wlan_scan_sta # 802.11 STA mode scanning device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors device ath_rate_sample # SampleRate tx rate control for ath device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device vlan # 802.1Q VLAN support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Serial devices device ucom # Generic com ttys device uark # Technologies ARK3116 based serial adapters device ubsa # Belkin F5U103 and compatible serial adapters device ubser # BWCT console serial adapters device uftdi # For FTDI usb serial adapters device uipaq # Some WinCE based devices device uplcom # Prolific PL-2303 serial adapters device uslcom # SI Labs CP2101/CP2102 serial adapters device uvisor # Visor and Palm devices device uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet # USB Wireless device rum # Ralink Technology RT2501USB wireless NICs device ural # Ralink Technology RT2500USB wireless NICs # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) device fwip # IP over FireWire (RFC 2734,3146) device dcons # Dumb console driver device dcons_crom # Configuration ROM for dcons # Local additions options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=1000 #limit verbosity options IPFIREWALL_FORWARD #packet destination changes options IPDIVERT #divert sockets options IPSTEALTH #support for stealth forwarding options DUMMYNET device carp _______________________________________________________________________________________ And debugging information: vmcore.2 # cd /usr/obj/usr/src/sys/MYKERNEL # kgdb kernel.debug /var/crash/vmcore.2 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal double fault: eip = 0xc08e3ba3 esp = 0xccf6dfc4 ebp = 0xccf6e274 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 Uptime: 7m14s Physical memory: 235 MB Dumping 35 MB: 20 4 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/if_gre.ko...Reading symbols from /boot/kernel/if_gre.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_gre.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07f2857 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07f2b29 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0a7ea2b in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:983 #4 0xc08e3ba3 in ipfw_chk (args=0xccf6e28c) at /usr/src/sys/netinet/ip_fw2.c:2465 #5 0xc08e6ce1 in ipfw_check_out (arg=0x0, m0=0xccf6e390, ifp=0xc25c5c00, dir=2, inp=0xc28ba708) at /usr/src/sys/netinet/ip_fw_pfil.c:248 #6 0xc08a1968 in pfil_run_hooks (ph=0xc0c55240, mp=0xccf6e420, ifp=0xc25c5c00, dir=2, inp=0xc28ba708) at /usr/src/sys/net/pfil.c:78 #7 0xc08eb6f2 in ip_output (m=0xc2710b00, opt=0x0, ro=0xccf6e3f4, flags=0, imo=0x0, inp=0xc28ba708) at /usr/src/sys/netinet/ip_output.c:443 #8 0xc08f4016 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1134 #9 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #10 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #11 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #12 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #13 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #14 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #15 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #16 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #17 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #18 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #19 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #20 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #21 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #22 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #23 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #24 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #25 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #26 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #27 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #28 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #29 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #30 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #31 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #32 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #33 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #34 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #35 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #36 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #37 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #38 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #39 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #40 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #41 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #42 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #43 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #44 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #45 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #46 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #47 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #48 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #49 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 ---Type to continue, or q to quit--- #50 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #51 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #52 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #53 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 #54 0xc08f4105 in tcp_output (tp=0xc25b2570) at /usr/src/sys/netinet/tcp_output.c:1195 #55 0xc08fdcf8 in tcp_usr_send (so=0xc2ac1820, flags=0, m=0xc270ed00, nam=0x0, control=0x0, td=0xc28e2d80) at tcp_offload.h:269 #56 0xc0850405 in sosend_generic (so=0xc2ac1820, addr=0x0, uio=0xc28766c0, top=0xc270ed00, control=0x0, flags=0, td=0xc28e2d80) at /usr/src/sys/kern/uipc_socket.c:1243 #57 0xc084bf7f in sosend (so=0xc2ac1820, addr=0x0, uio=0xc28766c0, top=0x0, control=0x0, flags=0, td=0xc28e2d80) at /usr/src/sys/kern/uipc_socket.c:1285 #58 0xc0833c5b in soo_write (fp=0xc28e84c0, uio=0xc28766c0, active_cred=0xc28e5900, flags=0, td=0xc28e2d80) at /usr/src/sys/kern/sys_socket.c:103 #59 0xc082d2e7 in dofilewrite (td=0xc28e2d80, fd=24, fp=0xc28e84c0, auio=0xc28766c0, offset=-1, flags=0) at file.h:257 #60 0xc082d5c8 in kern_writev (td=0xc28e2d80, fd=24, auio=0xc28766c0) at /usr/src/sys/kern/sys_generic.c:402 #61 0xc082d816 in writev (td=0xc28e2d80, uap=0xccf6fcfc) at /usr/src/sys/kern/sys_generic.c:388 #62 0xc0a7f2d5 in syscall (frame=0xccf6fd38) at /usr/src/sys/i386/i386/trap.c:1101 #63 0xc0a636a0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262 #64 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) (kgdb) quit _______________________________________________________________________________________ vmcore.1 host# kgdb kernel.debug /var/crash/vmcore.1 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal double fault: eip = 0xc08e3091 esp = 0xc23f2f34 ebp = 0xc23f31e4 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 Uptime: 12m7s Physical memory: 235 MB Dumping 43 MB: 28 12 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/if_gre.ko...Reading symbols from /boot/kernel/if_gre.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_gre.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07f2857 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07f2b29 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0a7ea2b in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:983 #4 0xc08e3091 in ipfw_chk (args=0xc23f31fc) at /usr/src/sys/netinet/ip_fw2.c:2118 #5 0xc08e6ce1 in ipfw_check_out (arg=0x0, m0=0xc23f3300, ifp=0xc25c5c00, dir=2, inp=0xc28e8168) at /usr/src/sys/netinet/ip_fw_pfil.c:248 #6 0xc08a1968 in pfil_run_hooks (ph=0xc0c55240, mp=0xc23f3390, ifp=0xc25c5c00, dir=2, inp=0xc28e8168) at /usr/src/sys/net/pfil.c:78 #7 0xc08eb6f2 in ip_output (m=0xc2710600, opt=0x0, ro=0xc23f3364, flags=0, imo=0x0, inp=0xc28e8168) at /usr/src/sys/netinet/ip_output.c:443 #8 0xc08f4016 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1134 #9 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #10 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #11 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #12 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #13 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #14 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #15 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #16 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #17 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #18 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #19 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #20 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #21 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #22 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #23 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #24 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #25 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #26 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #27 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #28 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #29 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #30 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #31 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #32 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #33 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #34 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #35 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #36 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #37 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #38 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #39 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #40 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #41 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #42 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #43 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #44 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #45 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #46 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #47 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 #48 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #49 0xc08f6d98 in tcp_mtudisc (inp=0xc28e8168, errno=0) at tcp_offload.h:269 ---Type to continue, or q to quit--- #50 0xc08f4105 in tcp_output (tp=0xc28eaae0) at /usr/src/sys/netinet/tcp_output.c:1195 #51 0xc08f14f5 in tcp_do_segment (m=0xc25ece00, th=0xc260b83c, so=0xc27e6820, tp=0xc28eaae0, drop_hdrlen=40, tlen=0) at /usr/src/sys/netinet/tcp_input.c:2359 #52 0xc08f21df in tcp_input (m=0xc25ece00, off0=20) at /usr/src/sys/netinet/tcp_input.c:847 #53 0xc08e9d29 in ip_input (m=0xc25ece00) at /usr/src/sys/netinet/ip_input.c:664 #54 0xc08a0105 in netisr_dispatch (num=2, m=0xc25ece00) at /usr/src/sys/net/netisr.c:185 #55 0xc27b842a in gre_input (m=0xc25ece00, off=20) at /usr/src/sys/modules/if_gre/../../netinet/ip_gre.c:217 #56 0xc08df35a in encap4_input (m=0xc25ece00, off=20) at /usr/src/sys/netinet/ip_encap.c:191 #57 0xc08e9d29 in ip_input (m=0xc25ece00) at /usr/src/sys/netinet/ip_input.c:664 #58 0xc08a0105 in netisr_dispatch (num=2, m=0xc25ece00) at /usr/src/sys/net/netisr.c:185 #59 0xc089426a in ether_demux (ifp=0xc25c5c00, m=0xc25ece00) at /usr/src/sys/net/if_ethersubr.c:834 #60 0xc0894683 in ether_input (ifp=0xc25c5c00, m=0xc25ece00) at /usr/src/sys/net/if_ethersubr.c:692 #61 0xc0952f18 in xl_rxeof (sc=0xc25d9000) at /usr/src/sys/pci/if_xl.c:2022 #62 0xc0955490 in xl_intr (arg=0xc25d9000) at /usr/src/sys/pci/if_xl.c:2257 #63 0xc07cf6db in ithread_loop (arg=0xc25b4900) at /usr/src/sys/kern/kern_intr.c:1181 #64 0xc07cbe79 in fork_exit (callout=0xc07cf530 , arg=0xc25b4900, frame=0xc23f4d38) at /usr/src/sys/kern/kern_fork.c:811 #65 0xc0a636b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:271 (kgdb) (kgdb) quit _______________________________________________________________________________________ vmcore.0 host# kgdb kernel.debug /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal double fault: eip = 0xc08e3ba3 esp = 0xccfd6fc4 ebp = 0xccfd7274 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 Uptime: 4d2h25m8s Physical memory: 235 MB Dumping 81 MB: 66 50 34 18 2 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/if_gre.ko...Reading symbols from /boot/kernel/if_gre.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_gre.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07f2857 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07f2b29 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0a7ea2b in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:983 #4 0xc08e3ba3 in ipfw_chk (args=0xccfd728c) at /usr/src/sys/netinet/ip_fw2.c:2465 #5 0xc08e6ce1 in ipfw_check_out (arg=0x0, m0=0xccfd7390, ifp=0xc25c5c00, dir=2, inp=0xc288dd5c) at /usr/src/sys/netinet/ip_fw_pfil.c:248 #6 0xc08a1968 in pfil_run_hooks (ph=0xc0c55240, mp=0xccfd7420, ifp=0xc25c5c00, dir=2, inp=0xc288dd5c) at /usr/src/sys/net/pfil.c:78 #7 0xc08eb6f2 in ip_output (m=0xc3633400, opt=0x0, ro=0xccfd73f4, flags=0, imo=0x0, inp=0xc288dd5c) at /usr/src/sys/netinet/ip_output.c:443 #8 0xc08f4016 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1134 #9 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #10 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #11 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #12 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #13 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #14 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #15 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #16 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #17 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #18 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #19 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #20 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #21 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #22 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #23 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #24 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #25 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #26 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #27 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #28 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #29 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #30 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #31 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #32 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #33 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #34 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #35 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #36 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #37 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #38 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #39 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #40 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #41 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #42 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #43 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #44 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #45 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #46 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #47 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #48 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #49 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 ---Type to continue, or q to quit--- #50 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #51 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #52 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #53 0xc08f6d98 in tcp_mtudisc (inp=0xc288dd5c, errno=0) at tcp_offload.h:269 #54 0xc08f4105 in tcp_output (tp=0xc32123a0) at /usr/src/sys/netinet/tcp_output.c:1195 #55 0xc08fdcf8 in tcp_usr_send (so=0xc26d4000, flags=0, m=0xc27c3b00, nam=0x0, control=0x0, td=0xc2a57480) at tcp_offload.h:269 #56 0xc0850405 in sosend_generic (so=0xc26d4000, addr=0x0, uio=0xc266ed40, top=0xc27c3b00, control=0x0, flags=0, td=0xc2a57480) at /usr/src/sys/kern/uipc_socket.c:1243 #57 0xc084bf7f in sosend (so=0xc26d4000, addr=0x0, uio=0xc266ed40, top=0x0, control=0x0, flags=0, td=0xc2a57480) at /usr/src/sys/kern/uipc_socket.c:1285 #58 0xc0833c5b in soo_write (fp=0xc2754098, uio=0xc266ed40, active_cred=0xc3404200, flags=0, td=0xc2a57480) at /usr/src/sys/kern/sys_socket.c:103 #59 0xc082d2e7 in dofilewrite (td=0xc2a57480, fd=24, fp=0xc2754098, auio=0xc266ed40, offset=-1, flags=0) at file.h:257 #60 0xc082d5c8 in kern_writev (td=0xc2a57480, fd=24, auio=0xc266ed40) at /usr/src/sys/kern/sys_generic.c:402 #61 0xc082d816 in writev (td=0xc2a57480, uap=0xccfd8cfc) at /usr/src/sys/kern/sys_generic.c:388 #62 0xc0a7f2d5 in syscall (frame=0xccfd8d38) at /usr/src/sys/i386/i386/trap.c:1101 #63 0xc0a636a0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262 #64 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) quit I'm not kernel hacker and C programmer so it's hard for me to understand what's the problem here. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 08:03:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 325581065672; Tue, 20 Apr 2010 08:03:34 +0000 (UTC) (envelope-from tomelite82@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A72F18FC1F; Tue, 20 Apr 2010 08:03:33 +0000 (UTC) Received: by vws18 with SMTP id 18so648226vws.13 for ; Tue, 20 Apr 2010 01:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type; bh=azVqSKKjveSxlU/lmT8rzNuSjgPHeFYjk2IENmfv4PQ=; b=l/DRPQxeM3Cxu4EcfdNDzN91mQy/3TLu2Mott6qKqNFqX6gThP02NtojWZUiVXesVV UDSSu08ILB8pnaeUDFZuEzKL1kEXP8fJNk5MUvKyqYGEE7FZ/0A5VklIVKgw+uRZk0fO jpfFSLBM94I31iLjRT6tP4uQIomWnYSulxQyc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Ff3C7m29erNEmsX/AUwY2qgz1gZF7hDlnqugsG09wsEsamW0/U21q0j3WFy5aGUXie GonQhXoN/npVhiEqKqLBkVkRTXkWtWera9Fd9zCcMH2j8fyvRC0A06vsxlm8IweTR6RM doZnuVcURSAWcuJkdTc8yU7BwHiIYUh2q7/J4= MIME-Version: 1.0 Sender: tomelite82@gmail.com Received: by 10.220.76.71 with HTTP; Tue, 20 Apr 2010 01:03:32 -0700 (PDT) In-Reply-To: References: <4B28F841.1070900@skylinetele.com> Date: Tue, 20 Apr 2010 01:03:32 -0700 X-Google-Sender-Auth: fa6dd5dbd164b230 Received: by 10.220.108.227 with SMTP id g35mr4380355vcp.184.1271750612811; Tue, 20 Apr 2010 01:03:32 -0700 (PDT) Message-ID: From: Qing Li To: Marin Atanasov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, "Li, Qing" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, "Prokofiev S.P." Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 08:03:34 -0000 > > I was using csup to track RELEN_8_0 branch. Currently I'm syncing to > RELENG_8. > > If I understood you right, after getting the sources for RELENG_8, I need to > apply the patch and then rebuild world? > You only need to rebuild the kernel. -- Qing From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 13:41:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94259106564A; Tue, 20 Apr 2010 13:41:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 541B88FC13; Tue, 20 Apr 2010 13:41:49 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DFBCB46B37; Tue, 20 Apr 2010 09:41:48 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id CF53A8A021; Tue, 20 Apr 2010 09:41:47 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 20 Apr 2010 07:48:09 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004200748.09566.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 20 Apr 2010 09:41:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: c0re , net@freebsd.org Subject: Re: FreeBSD 7.3, reboot after panic: double fault X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 13:41:49 -0000 On Tuesday 20 April 2010 2:53:16 am c0re wrote: > Hello All! > I've upgraded freebsd from 7.0 to 7.3 and all was good until I tryed to > configure gre interface and use ipfw fwd. > I'm actually does not know what was the point of failure in my > configuration. > > [ some details snipped ] > > It worked about one week and then I made some configuration changes: > added gre interface and 2 aliases: > > # cat /etc/rc.conf |grep > ifconfig_xl0="inet 192.168.0.10 netmask 255.255.255.0" > ifconfig_xl0_alias0="192.168.0.11 netmask 255.255.255.255" > ifconfig_xl0_alias1="192.168.0.12 netmask 255.255.255.255" > cloned_interfaces="gre0" > ifconfig_gre0="inet 192.168.250.6 192.168.250.5 tunnel 192.168.0.12 > 192.168.200.15 netmask 255.255.255.252 link1 up" > > and > > # cat /etc/rc.local > #!/bin/sh > ipfw add fwd 192.168.250.5 icmp from 192.168.0.11 to any out via xl0 > ipfw add fwd 192.168.250.5 tcp from 192.168.0.11 443 to any out via xl0 > ipfw add allow ip from any to any > > # ifconfig gre0 > gre0: flags=b050 metric 0 mtu > 1476 > tunnel inet 192.168.0.12 --> 192.168.200.15 > inet 192.168.250.6 --> 192.168.250.5 netmask 0xfffffffc > > I shutted down gre interface to prevent requests via gre to buggy IP. > > The main idea of such configurations was: fwd all connections to https to > 192.168.0.1 via gre interface. > And also I made apache configurations to make it listen on 192.168.0.11 too. > > And make some tests: ping 192.168.0.11 - was fine, goes via gre. Telnet to > 192.168.0.11 443 was fine too. Then I tryed to make browser https > connection to 192.168.0.11. Apache showed me certificate warning and I > accepted, then in browser nothing happened, it was trying to open page. But > server got kernel panic at that moment. > > At first time I thought that it was some power failure, I tryed 2 more times > and got same behaviour. > > So https works without kernel panic via 192.168.0.10 address but kernel > panics when I try do https via 192.168.0.11 address that source-forwarded > via gre. Looks like the TCP output path got stuck in an infinite recursion loop until it exhausted the kernel stack: > # cd /usr/obj/usr/src/sys/MYKERNEL > # kgdb kernel.debug /var/crash/vmcore.2 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > Fatal double fault: > eip = 0xc08e3ba3 > esp = 0xccf6dfc4 > ebp = 0xccf6e274 > cpuid = 0; apic id = 00 > panic: double fault > cpuid = 0 > Uptime: 7m14s > Physical memory: 235 MB > Dumping 35 MB: 20 4 > > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > Reading symbols from /boot/kernel/if_gre.ko...Reading symbols from > /boot/kernel/if_gre.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/if_gre.ko > Reading symbols from /boot/kernel/linux.ko...Reading symbols from > /boot/kernel/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linux.ko > #0 doadump () at pcpu.h:196 > 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc07f2857 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc07f2b29 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #3 0xc0a7ea2b in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:983 > #4 0xc08e3ba3 in ipfw_chk (args=0xccf6e28c) at > /usr/src/sys/netinet/ip_fw2.c:2465 > #5 0xc08e6ce1 in ipfw_check_out (arg=0x0, m0=0xccf6e390, ifp=0xc25c5c00, > dir=2, inp=0xc28ba708) at /usr/src/sys/netinet/ip_fw_pfil.c:248 > #6 0xc08a1968 in pfil_run_hooks (ph=0xc0c55240, mp=0xccf6e420, > ifp=0xc25c5c00, dir=2, inp=0xc28ba708) at /usr/src/sys/net/pfil.c:78 > #7 0xc08eb6f2 in ip_output (m=0xc2710b00, opt=0x0, ro=0xccf6e3f4, flags=0, > imo=0x0, inp=0xc28ba708) at /usr/src/sys/netinet/ip_output.c:443 > #8 0xc08f4016 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1134 > #9 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #10 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #11 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #12 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #13 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #14 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #15 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #16 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #17 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #18 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #19 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #20 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #21 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #22 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #23 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #24 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #25 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #26 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #27 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #28 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #29 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #30 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #31 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #32 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #33 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #34 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #35 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #36 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #37 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #38 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #39 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #40 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #41 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #42 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #43 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #44 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #45 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #46 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #47 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #48 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #49 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > ---Type to continue, or q to quit--- > #50 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #51 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #52 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #53 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at tcp_offload.h:269 > #54 0xc08f4105 in tcp_output (tp=0xc25b2570) at > /usr/src/sys/netinet/tcp_output.c:1195 > #55 0xc08fdcf8 in tcp_usr_send (so=0xc2ac1820, flags=0, m=0xc270ed00, > nam=0x0, control=0x0, td=0xc28e2d80) at tcp_offload.h:269 > #56 0xc0850405 in sosend_generic (so=0xc2ac1820, addr=0x0, uio=0xc28766c0, > top=0xc270ed00, control=0x0, flags=0, td=0xc28e2d80) at > /usr/src/sys/kern/uipc_socket.c:1243 > #57 0xc084bf7f in sosend (so=0xc2ac1820, addr=0x0, uio=0xc28766c0, top=0x0, > control=0x0, flags=0, td=0xc28e2d80) at /usr/src/sys/kern/uipc_socket.c:1285 > #58 0xc0833c5b in soo_write (fp=0xc28e84c0, uio=0xc28766c0, > active_cred=0xc28e5900, flags=0, td=0xc28e2d80) at > /usr/src/sys/kern/sys_socket.c:103 > #59 0xc082d2e7 in dofilewrite (td=0xc28e2d80, fd=24, fp=0xc28e84c0, > auio=0xc28766c0, offset=-1, flags=0) at file.h:257 > #60 0xc082d5c8 in kern_writev (td=0xc28e2d80, fd=24, auio=0xc28766c0) at > /usr/src/sys/kern/sys_generic.c:402 > #61 0xc082d816 in writev (td=0xc28e2d80, uap=0xccf6fcfc) at > /usr/src/sys/kern/sys_generic.c:388 > #62 0xc0a7f2d5 in syscall (frame=0xccf6fd38) at > /usr/src/sys/i386/i386/trap.c:1101 > #63 0xc0a636a0 in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:262 > #64 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > (kgdb) quit tcp_output() calls tcp_mtudisc() if ip_output() returns EMSGSIZE: case EMSGSIZE: /* * For some reason the interface we used initially * to send segments changed to another or lowered * its MTU. * * tcp_mtudisc() will find out the new MTU and as * its last action, initiate retransmission, so it * is important to not do so here. * * If TSO was active we either got an interface * without TSO capabilits or TSO was turned off. * Disable it for this connection as too and * immediatly retry with MSS sized segments generated * by this function. */ if (tso) tp->t_flags &= ~TF_TSO; tcp_mtudisc(tp->t_inpcb, 0); return (0); But tcp_mtudisc() calls tcp_output(): tcpstat.tcps_mturesent++; tp->t_rtttime = 0; tp->snd_nxt = tp->snd_una; tcp_free_sackholes(tp); tp->snd_recover = tp->snd_max; if (tp->t_flags & TF_SACK_PERMIT) EXIT_FASTRECOVERY(tp); tcp_output_send(tp); return (inp); I'm not sure why it's not able to figure out the MTU, perhaps folks on net@ can help. However, it would seem that for the tcp_output() case, tcp_mtudisc() should probably not call tcp_output_send(), but instead tcp_output() should just loop back up to the top after calling tcp_mtudisc() and retry. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 13:51:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C80F3106564A; Tue, 20 Apr 2010 13:51:52 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 00A878FC22; Tue, 20 Apr 2010 13:51:51 +0000 (UTC) Received: by bwz8 with SMTP id 8so5567813bwz.3 for ; Tue, 20 Apr 2010 06:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AnP+huBkOJHK0m9w+ovY662TEpMWEBmCZ+hrgxqnnHM=; b=eAB6TcoY8ommvWy6Y3wwNKyMSimT1vknnlIx09wvoEEB/zWiStVh6fA5BAIeik13fO 46eLRazGA99nQwggAKyZrDQxhguVk37cZRcktnoN4Wd0SgXPuuMOOzwniCnfRXfNjef1 /IW+6xTorKG+xNHT/5JEZ4oNWCQmNPs2OHqb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=feoiSU5SajZbv0kzYYNji6I38RdDGthwtvFzeGYK6fAby41BDUztoghPRtC9jsH5nz c9T90p9W5wP48oaBK4zyUoZOoNIXxwOQdw0ZjtdwEMUfDDGi2H/In6IKx31/8jNjfD4P 36Skgb85gdI9vTTZO6MDv4SEI/SUO+XYjj1+s= MIME-Version: 1.0 Received: by 10.204.47.232 with HTTP; Tue, 20 Apr 2010 06:51:49 -0700 (PDT) In-Reply-To: <201004200748.09566.jhb@freebsd.org> References: <201004200748.09566.jhb@freebsd.org> Date: Tue, 20 Apr 2010 17:51:49 +0400 Received: by 10.204.21.18 with SMTP id h18mr2490059bkb.177.1271771510528; Tue, 20 Apr 2010 06:51:50 -0700 (PDT) Message-ID: From: pluknet To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, c0re , net@freebsd.org Subject: Re: FreeBSD 7.3, reboot after panic: double fault X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 13:51:52 -0000 On 20 April 2010 15:48, John Baldwin wrote: > On Tuesday 20 April 2010 2:53:16 am c0re wrote: >> Hello All! >> I've upgraded freebsd from 7.0 to 7.3 and all was good until I tryed to >> configure gre interface and use ipfw fwd. >> I'm actually does not know what was the point of failure in my >> configuration. >> >> [ some details snipped ] >> >> It worked about one week and then I made some configuration changes: >> added gre interface and 2 aliases: >> >> # cat /etc/rc.conf |grep >> ifconfig_xl0=3D"inet 192.168.0.10 =A0netmask 255.255.255.0" >> ifconfig_xl0_alias0=3D"192.168.0.11 netmask 255.255.255.255" >> ifconfig_xl0_alias1=3D"192.168.0.12 netmask 255.255.255.255" >> cloned_interfaces=3D"gre0" >> ifconfig_gre0=3D"inet 192.168.250.6 192.168.250.5 tunnel 192.168.0.12 >> 192.168.200.15 netmask 255.255.255.252 link1 up" >> >> and >> >> # cat /etc/rc.local >> #!/bin/sh >> ipfw add fwd 192.168.250.5 icmp from 192.168.0.11 to any out via xl0 >> ipfw add fwd 192.168.250.5 tcp from 192.168.0.11 443 to any out via xl0 >> ipfw add allow ip from any to any >> >> # ifconfig gre0 >> gre0: flags=3Db050 metric 0 m= tu >> 1476 >> =A0 =A0 =A0 =A0 tunnel inet 192.168.0.12 --> 192.168.200.15 >> =A0 =A0 =A0 =A0 inet 192.168.250.6 --> 192.168.250.5 netmask 0xfffffffc >> >> I shutted down gre interface to prevent requests via gre to buggy IP. >> >> The main idea of such configurations was: fwd all connections to https t= o >> 192.168.0.1 via gre interface. >> And also I made apache configurations to make it listen on 192.168.0.11 = too. >> >> And make some tests: ping 192.168.0.11 - was fine, goes via gre. Telnet = to >> 192.168.0.11 =A0443 was fine too. Then I tryed to make browser https >> connection to 192.168.0.11. Apache showed me certificate warning and I >> accepted, then in browser nothing happened, it was trying to open page. = But >> server got kernel panic at that moment. >> >> At first time I thought that it was some power failure, I tryed 2 more t= imes >> and got same behaviour. >> >> So https works without kernel panic via 192.168.0.10 address but kernel >> panics when I try do https via 192.168.0.11 address that source-forwarde= d >> via gre. > > Looks like the TCP output path got stuck in an infinite recursion loop un= til > it exhausted the kernel stack: > >> # cd /usr/obj/usr/src/sys/MYKERNEL >> # kgdb kernel.debug /var/crash/vmcore.2 >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you= are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. =A0Type "show warranty" for det= ails. >> This GDB was configured as "i386-marcel-freebsd"... >> >> Unread portion of the kernel message buffer: >> >> Fatal double fault: >> eip =3D 0xc08e3ba3 >> esp =3D 0xccf6dfc4 >> ebp =3D 0xccf6e274 >> cpuid =3D 0; apic id =3D 00 >> panic: double fault >> cpuid =3D 0 >> Uptime: 7m14s >> Physical memory: 235 MB >> Dumping 35 MB: 20 4 >> >> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >> /boot/kernel/acpi.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/acpi.ko >> Reading symbols from /boot/kernel/if_gre.ko...Reading symbols from >> /boot/kernel/if_gre.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/if_gre.ko >> Reading symbols from /boot/kernel/linux.ko...Reading symbols from >> /boot/kernel/linux.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/linux.ko >> #0 =A0doadump () at pcpu.h:196 >> 196 =A0 =A0 =A0 =A0 =A0 =A0 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (= td)); >> (kgdb) bt >> #0 =A0doadump () at pcpu.h:196 >> #1 =A00xc07f2857 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdow= n.c:418 >> #2 =A00xc07f2b29 in panic (fmt=3DVariable "fmt" is not available. >> ) at /usr/src/sys/kern/kern_shutdown.c:574 >> #3 =A00xc0a7ea2b in dblfault_handler () at /usr/src/sys/i386/i386/trap.c= :983 >> #4 =A00xc08e3ba3 in ipfw_chk (args=3D0xccf6e28c) at >> /usr/src/sys/netinet/ip_fw2.c:2465 >> #5 =A00xc08e6ce1 in ipfw_check_out (arg=3D0x0, m0=3D0xccf6e390, ifp=3D0x= c25c5c00, >> dir=3D2, inp=3D0xc28ba708) at /usr/src/sys/netinet/ip_fw_pfil.c:248 >> #6 =A00xc08a1968 in pfil_run_hooks (ph=3D0xc0c55240, mp=3D0xccf6e420, >> ifp=3D0xc25c5c00, dir=3D2, inp=3D0xc28ba708) at /usr/src/sys/net/pfil.c:= 78 >> #7 =A00xc08eb6f2 in ip_output (m=3D0xc2710b00, opt=3D0x0, ro=3D0xccf6e3f= 4, flags=3D0, >> imo=3D0x0, inp=3D0xc28ba708) at /usr/src/sys/netinet/ip_output.c:443 >> #8 =A00xc08f4016 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1134 >> #9 =A00xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_off= load.h:269 >> #10 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #11 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #12 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #13 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #14 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #15 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #16 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #17 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #18 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #19 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #20 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #21 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #22 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #23 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #24 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #25 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #26 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #27 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #28 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #29 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #30 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #31 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #32 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #33 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #34 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #35 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #36 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #37 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #38 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #39 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #40 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #41 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #42 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #43 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #44 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #45 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #46 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #47 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #48 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #49 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> ---Type to continue, or q to quit--- >> #50 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #51 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #52 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #53 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offlo= ad.h:269 >> #54 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >> /usr/src/sys/netinet/tcp_output.c:1195 >> #55 0xc08fdcf8 in tcp_usr_send (so=3D0xc2ac1820, flags=3D0, m=3D0xc270ed= 00, >> nam=3D0x0, control=3D0x0, td=3D0xc28e2d80) at tcp_offload.h:269 >> #56 0xc0850405 in sosend_generic (so=3D0xc2ac1820, addr=3D0x0, uio=3D0xc= 28766c0, >> top=3D0xc270ed00, control=3D0x0, flags=3D0, td=3D0xc28e2d80) at >> /usr/src/sys/kern/uipc_socket.c:1243 >> #57 0xc084bf7f in sosend (so=3D0xc2ac1820, addr=3D0x0, uio=3D0xc28766c0,= top=3D0x0, >> control=3D0x0, flags=3D0, td=3D0xc28e2d80) at /usr/src/sys/kern/uipc_soc= ket.c:1285 >> #58 0xc0833c5b in soo_write (fp=3D0xc28e84c0, uio=3D0xc28766c0, >> active_cred=3D0xc28e5900, flags=3D0, td=3D0xc28e2d80) at >> /usr/src/sys/kern/sys_socket.c:103 >> #59 0xc082d2e7 in dofilewrite (td=3D0xc28e2d80, fd=3D24, fp=3D0xc28e84c0= , >> auio=3D0xc28766c0, offset=3D-1, flags=3D0) at file.h:257 >> #60 0xc082d5c8 in kern_writev (td=3D0xc28e2d80, fd=3D24, auio=3D0xc28766= c0) at >> /usr/src/sys/kern/sys_generic.c:402 >> #61 0xc082d816 in writev (td=3D0xc28e2d80, uap=3D0xccf6fcfc) at >> /usr/src/sys/kern/sys_generic.c:388 >> #62 0xc0a7f2d5 in syscall (frame=3D0xccf6fd38) at >> /usr/src/sys/i386/i386/trap.c:1101 >> #63 0xc0a636a0 in Xint0x80_syscall () at >> /usr/src/sys/i386/i386/exception.s:262 >> #64 0x00000033 in ?? () >> Previous frame inner to this frame (corrupt stack?) >> (kgdb) >> (kgdb) quit > > tcp_output() calls tcp_mtudisc() if ip_output() returns EMSGSIZE: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0case EMSGSIZE: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * For some reason the int= erface we used initially > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * to send segments change= d to another or lowered > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * its MTU. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * tcp_mtudisc() will find= out the new MTU and as > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * its last action, initia= te retransmission, so it > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * is important to not do = so here. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * If TSO was active we ei= ther got an interface > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * without TSO capabilits = or TSO was turned off. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Disable it for this con= nection as too and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * immediatly retry with M= SS sized segments generated > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * by this function. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (tso) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tp->t_flag= s &=3D ~TF_TSO; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tcp_mtudisc(tp->t_inpcb, 0= ); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); > > But tcp_mtudisc() calls tcp_output(): > > =A0 =A0 =A0 =A0tcpstat.tcps_mturesent++; > =A0 =A0 =A0 =A0tp->t_rtttime =3D 0; > =A0 =A0 =A0 =A0tp->snd_nxt =3D tp->snd_una; > =A0 =A0 =A0 =A0tcp_free_sackholes(tp); > =A0 =A0 =A0 =A0tp->snd_recover =3D tp->snd_max; > =A0 =A0 =A0 =A0if (tp->t_flags & TF_SACK_PERMIT) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0EXIT_FASTRECOVERY(tp); > =A0 =A0 =A0 =A0tcp_output_send(tp); > =A0 =A0 =A0 =A0return (inp); > > I'm not sure why it's not able to figure out the MTU, perhaps folks on ne= t@ > can help. =A0However, it would seem that for the tcp_output() case, > tcp_mtudisc() should probably not call tcp_output_send(), but instead > tcp_output() should just loop back up to the top after calling tcp_mtudis= c() > and retry. > I'm afraid to be wrong but it looks similar to another report for 8.0-STABL= E (may it be a cross-major version regression somewhere around tcp_mtudisc()?= ): http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056063.html --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 16:14:32 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58A82106566B; Tue, 20 Apr 2010 16:14:32 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from worf.ds9.tecnik93.com (worf.ds9.tecnik93.com [81.196.207.130]) by mx1.freebsd.org (Postfix) with ESMTP id AF7448FC27; Tue, 20 Apr 2010 16:14:31 +0000 (UTC) Received: from it.buh.tecnik93.com (it.buh.tecnik93.com [81.196.204.98]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by worf.ds9.tecnik93.com (Postfix) with ESMTPSA id 224A722C50CD; Tue, 20 Apr 2010 19:14:30 +0300 (EEST) Date: Tue, 20 Apr 2010 19:14:28 +0300 From: Ion-Mihai Tetcu To: Garrett Cooper Message-ID: <20100420191428.1447931e@it.buh.tecnik93.com> In-Reply-To: References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <20100420021420.22e22136@it.buh.tecnik93.com> <20100419233858.GC43612@logik.internal.network> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/2Uvyna7zchllsg7Vrw07iiU"; protocol="application/pgp-signature" Cc: stable@freebsd.org, freebsd-ports@coreland.ath.cx, questions@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 16:14:32 -0000 --Sig_/2Uvyna7zchllsg7Vrw07iiU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 19 Apr 2010 17:40:35 -0700 Garrett Cooper wrote: > On Mon, Apr 19, 2010 at 4:38 PM, > wrote: > > On 2010-04-20 02:14:20, Ion-Mihai Tetcu wrote: > >> A switch to use newer GMP version has been committed. > >> > >> I'm still investigating lang/gnat-gcc44. > > > > As far as I know, the gnat-gcc44 bootstrap binaries will be > > fine as they're bundled with the libgmp library that was used > > to build them. Whether gcc builds with the newer libgmp remains > > to be seen... >=20 > As discussed in the QAT emails, it might be related to ccache use > on the build cluster graciously donated by ixSystems, and the fact > that the cached data is inconsistently distributed across the cluster. ATM no, the new cluster is in works, not yet used, QAT is running on a single machine, with ccache. > I've provided some tips for itetcu to work around this on IRC > (basically disable ccache), but it kind of sucks when you run into > periodic issues with toolchain variance like this, s.t. building with > NO_CACHE=3Dyes is a necessary evil to work through end-to-end build > functional issues.=20 Problem is I need an automated solution. I'm testing it now on QAT with ccache disabled. > Someone else who knows more about ccache could provide a better > explanation of what's going on because my ranting about this would > only be me talking out of my rear :). Yes, please. > More info about ccache with FreeBSD can be found here: > http://forums.freebsd.org/archive/index.php/t-174.html Thanks. --=20 IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B --Sig_/2Uvyna7zchllsg7Vrw07iiU Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvN0uUACgkQJ7GIuiH/oeVkywCeLWcmV54/Q8vniBAMow8R+12C dwEAn3JW+U3xVWFXYPQfL67EVDz2t2eD =xHjw -----END PGP SIGNATURE----- --Sig_/2Uvyna7zchllsg7Vrw07iiU-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 16:19:09 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE14A1065670; Tue, 20 Apr 2010 16:19:09 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from worf.ds9.tecnik93.com (worf.ds9.tecnik93.com [81.196.207.130]) by mx1.freebsd.org (Postfix) with ESMTP id 232628FC1F; Tue, 20 Apr 2010 16:19:08 +0000 (UTC) Received: from it.buh.tecnik93.com (it.buh.tecnik93.com [81.196.204.98]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by worf.ds9.tecnik93.com (Postfix) with ESMTPSA id EE35722C50EB; Tue, 20 Apr 2010 19:19:07 +0300 (EEST) Date: Tue, 20 Apr 2010 19:19:06 +0300 From: Ion-Mihai Tetcu To: Ion-Mihai Tetcu Message-ID: <20100420191906.2c752ea2@it.buh.tecnik93.com> In-Reply-To: <20100420191428.1447931e@it.buh.tecnik93.com> References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <20100420021420.22e22136@it.buh.tecnik93.com> <20100419233858.GC43612@logik.internal.network> <20100420191428.1447931e@it.buh.tecnik93.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/rMT=xxqFgDMdo5n1XXIrhRU"; protocol="application/pgp-signature" Cc: Garrett Cooper , stable@freebsd.org, freebsd-ports@coreland.ath.cx, questions@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 16:19:09 -0000 --Sig_/rMT=xxqFgDMdo5n1XXIrhRU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 20 Apr 2010 19:14:28 +0300 Ion-Mihai Tetcu wrote: > > I've provided some tips for itetcu to work around this on IRC > > (basically disable ccache), but it kind of sucks when you run into > > periodic issues with toolchain variance like this, s.t. building > > with NO_CACHE=3Dyes is a necessary evil to work through end-to-end > > build functional issues. =20 >=20 > Problem is I need an automated solution. > I'm testing it now on QAT with ccache disabled. Same error. --=20 IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B --Sig_/rMT=xxqFgDMdo5n1XXIrhRU Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvN0/sACgkQJ7GIuiH/oeX/ywCcCWzIVrGc/wIA1ILi2baRNXOv HYsAoIqLMyavwUPvd9dzCsivzFSuphT+ =/TPw -----END PGP SIGNATURE----- --Sig_/rMT=xxqFgDMdo5n1XXIrhRU-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 19:35:53 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45CF4106566B; Tue, 20 Apr 2010 19:35:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 148A58FC15; Tue, 20 Apr 2010 19:35:52 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3KJZqN6047498; Tue, 20 Apr 2010 15:35:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3KJZqB8047494; Tue, 20 Apr 2010 19:35:52 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 20 Apr 2010 19:35:52 GMT Message-Id: <201004201935.o3KJZqB8047494@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 19:35:53 -0000 TB --- 2010-04-20 17:53:40 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-20 17:53:40 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2010-04-20 17:53:40 - cleaning the object tree TB --- 2010-04-20 17:54:06 - cvsupping the source tree TB --- 2010-04-20 17:54:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2010-04-20 17:54:32 - building world TB --- 2010-04-20 17:54:32 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-20 17:54:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-20 17:54:32 - TARGET=amd64 TB --- 2010-04-20 17:54:32 - TARGET_ARCH=amd64 TB --- 2010-04-20 17:54:32 - TZ=UTC TB --- 2010-04-20 17:54:32 - __MAKE_CONF=/dev/null TB --- 2010-04-20 17:54:32 - cd /src TB --- 2010-04-20 17:54:32 - /usr/bin/make -B buildworld >>> World build started on Tue Apr 20 17:54:33 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Apr 20 19:20:04 UTC 2010 TB --- 2010-04-20 19:20:04 - generating LINT kernel config TB --- 2010-04-20 19:20:04 - cd /src/sys/amd64/conf TB --- 2010-04-20 19:20:04 - /usr/bin/make -B LINT TB --- 2010-04-20 19:20:04 - building LINT kernel TB --- 2010-04-20 19:20:04 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-20 19:20:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-20 19:20:04 - TARGET=amd64 TB --- 2010-04-20 19:20:04 - TARGET_ARCH=amd64 TB --- 2010-04-20 19:20:04 - TZ=UTC TB --- 2010-04-20 19:20:04 - __MAKE_CONF=/dev/null TB --- 2010-04-20 19:20:04 - cd /src TB --- 2010-04-20 19:20:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Apr 20 19:20:04 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ===> geom/geom_sched (all) ===> geom/geom_sched/gs_sched (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c cc1: warnings being treated as errors /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c: In function 'g_sched_issuer_pid': /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: implicit declaration of function 'g_sched_issuer' /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: nested extern declaration of 'g_sched_issuer' /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: initialization makes pointer from integer without a cast *** Error code 1 Stop in /src/sys/modules/geom/geom_sched/gs_sched. *** Error code 1 Stop in /src/sys/modules/geom/geom_sched. *** Error code 1 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-20 19:35:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-20 19:35:52 - ERROR: failed to build lint kernel TB --- 2010-04-20 19:35:52 - 4617.32 user 883.91 system 6131.74 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 20:03:59 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB6981065670; Tue, 20 Apr 2010 20:03:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6602E8FC25; Tue, 20 Apr 2010 20:03:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3KK3rk3061974; Tue, 20 Apr 2010 16:03:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3KK3rK7061963; Tue, 20 Apr 2010 20:03:53 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 20 Apr 2010 20:03:53 GMT Message-Id: <201004202003.o3KK3rK7061963@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 20:03:59 -0000 TB --- 2010-04-20 18:45:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-20 18:45:19 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2010-04-20 18:45:19 - cleaning the object tree TB --- 2010-04-20 18:45:40 - cvsupping the source tree TB --- 2010-04-20 18:45:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2010-04-20 18:47:09 - building world TB --- 2010-04-20 18:47:09 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-20 18:47:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-20 18:47:09 - TARGET=i386 TB --- 2010-04-20 18:47:09 - TARGET_ARCH=i386 TB --- 2010-04-20 18:47:09 - TZ=UTC TB --- 2010-04-20 18:47:09 - __MAKE_CONF=/dev/null TB --- 2010-04-20 18:47:09 - cd /src TB --- 2010-04-20 18:47:09 - /usr/bin/make -B buildworld >>> World build started on Tue Apr 20 18:47:10 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Apr 20 19:46:08 UTC 2010 TB --- 2010-04-20 19:46:08 - generating LINT kernel config TB --- 2010-04-20 19:46:08 - cd /src/sys/i386/conf TB --- 2010-04-20 19:46:08 - /usr/bin/make -B LINT TB --- 2010-04-20 19:46:08 - building LINT kernel TB --- 2010-04-20 19:46:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-20 19:46:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-20 19:46:08 - TARGET=i386 TB --- 2010-04-20 19:46:08 - TARGET_ARCH=i386 TB --- 2010-04-20 19:46:08 - TZ=UTC TB --- 2010-04-20 19:46:08 - __MAKE_CONF=/dev/null TB --- 2010-04-20 19:46:08 - cd /src TB --- 2010-04-20 19:46:08 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Apr 20 19:46:09 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ===> geom/geom_sched (all) ===> geom/geom_sched/gs_sched (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c cc1: warnings being treated as errors /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c: In function 'g_sched_issuer_pid': /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: implicit declaration of function 'g_sched_issuer' /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: nested extern declaration of 'g_sched_issuer' /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: initialization makes pointer from integer without a cast *** Error code 1 Stop in /src/sys/modules/geom/geom_sched/gs_sched. *** Error code 1 Stop in /src/sys/modules/geom/geom_sched. *** Error code 1 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-20 20:03:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-20 20:03:53 - ERROR: failed to build lint kernel TB --- 2010-04-20 20:03:53 - 3526.67 user 640.05 system 4713.82 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 20:24:06 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AD25106566B; Tue, 20 Apr 2010 20:24:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0FB6C8FC1E; Tue, 20 Apr 2010 20:24:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3KKO5cC001668; Tue, 20 Apr 2010 16:24:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3KKO5nZ001664; Tue, 20 Apr 2010 20:24:05 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 20 Apr 2010 20:24:05 GMT Message-Id: <201004202024.o3KKO5nZ001664@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 20:24:06 -0000 TB --- 2010-04-20 19:09:50 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-20 19:09:50 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2010-04-20 19:09:50 - cleaning the object tree TB --- 2010-04-20 19:10:13 - cvsupping the source tree TB --- 2010-04-20 19:10:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2010-04-20 19:11:06 - building world TB --- 2010-04-20 19:11:06 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-20 19:11:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-20 19:11:06 - TARGET=pc98 TB --- 2010-04-20 19:11:06 - TARGET_ARCH=i386 TB --- 2010-04-20 19:11:06 - TZ=UTC TB --- 2010-04-20 19:11:06 - __MAKE_CONF=/dev/null TB --- 2010-04-20 19:11:06 - cd /src TB --- 2010-04-20 19:11:06 - /usr/bin/make -B buildworld >>> World build started on Tue Apr 20 19:11:06 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Apr 20 20:08:51 UTC 2010 TB --- 2010-04-20 20:08:51 - generating LINT kernel config TB --- 2010-04-20 20:08:51 - cd /src/sys/pc98/conf TB --- 2010-04-20 20:08:51 - /usr/bin/make -B LINT TB --- 2010-04-20 20:08:51 - building LINT kernel TB --- 2010-04-20 20:08:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-20 20:08:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-20 20:08:51 - TARGET=pc98 TB --- 2010-04-20 20:08:51 - TARGET_ARCH=i386 TB --- 2010-04-20 20:08:51 - TZ=UTC TB --- 2010-04-20 20:08:51 - __MAKE_CONF=/dev/null TB --- 2010-04-20 20:08:51 - cd /src TB --- 2010-04-20 20:08:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Apr 20 20:08:52 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ===> geom/geom_sched (all) ===> geom/geom_sched/gs_sched (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c cc1: warnings being treated as errors /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c: In function 'g_sched_issuer_pid': /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: implicit declaration of function 'g_sched_issuer' /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: nested extern declaration of 'g_sched_issuer' /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: initialization makes pointer from integer without a cast *** Error code 1 Stop in /src/sys/modules/geom/geom_sched/gs_sched. *** Error code 1 Stop in /src/sys/modules/geom/geom_sched. *** Error code 1 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-20 20:24:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-20 20:24:05 - ERROR: failed to build lint kernel TB --- 2010-04-20 20:24:05 - 3362.93 user 643.21 system 4454.59 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 20:44:24 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D21671065670; Tue, 20 Apr 2010 20:44:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A327C8FC0A; Tue, 20 Apr 2010 20:44:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3KKiNtI023833; Tue, 20 Apr 2010 16:44:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3KKiNGL023832; Tue, 20 Apr 2010 20:44:23 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 20 Apr 2010 20:44:23 GMT Message-Id: <201004202044.o3KKiNGL023832@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 20:44:25 -0000 TB --- 2010-04-20 19:10:18 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-20 19:10:18 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2010-04-20 19:10:18 - cleaning the object tree TB --- 2010-04-20 19:10:37 - cvsupping the source tree TB --- 2010-04-20 19:10:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile TB --- 2010-04-20 19:11:06 - building world TB --- 2010-04-20 19:11:06 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-20 19:11:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-20 19:11:06 - TARGET=ia64 TB --- 2010-04-20 19:11:06 - TARGET_ARCH=ia64 TB --- 2010-04-20 19:11:06 - TZ=UTC TB --- 2010-04-20 19:11:06 - __MAKE_CONF=/dev/null TB --- 2010-04-20 19:11:06 - cd /src TB --- 2010-04-20 19:11:06 - /usr/bin/make -B buildworld >>> World build started on Tue Apr 20 19:11:06 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Apr 20 20:26:05 UTC 2010 TB --- 2010-04-20 20:26:05 - generating LINT kernel config TB --- 2010-04-20 20:26:05 - cd /src/sys/ia64/conf TB --- 2010-04-20 20:26:05 - /usr/bin/make -B LINT TB --- 2010-04-20 20:26:05 - building LINT kernel TB --- 2010-04-20 20:26:05 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-20 20:26:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-20 20:26:05 - TARGET=ia64 TB --- 2010-04-20 20:26:05 - TARGET_ARCH=ia64 TB --- 2010-04-20 20:26:05 - TZ=UTC TB --- 2010-04-20 20:26:05 - __MAKE_CONF=/dev/null TB --- 2010-04-20 20:26:05 - cd /src TB --- 2010-04-20 20:26:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Apr 20 20:26:05 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ===> geom/geom_sched (all) ===> geom/geom_sched/gs_sched (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/ia64/src/sys/LINT -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c cc1: warnings being treated as errors /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c: In function 'g_sched_issuer_pid': /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: implicit declaration of function 'g_sched_issuer' /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: nested extern declaration of 'g_sched_issuer' /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: initialization makes pointer from integer without a cast *** Error code 1 Stop in /src/sys/modules/geom/geom_sched/gs_sched. *** Error code 1 Stop in /src/sys/modules/geom/geom_sched. *** Error code 1 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-20 20:44:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-20 20:44:23 - ERROR: failed to build lint kernel TB --- 2010-04-20 20:44:23 - 4654.55 user 634.84 system 5645.73 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 21:15:26 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FCF8106566B; Tue, 20 Apr 2010 21:15:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4FF0F8FC1F; Tue, 20 Apr 2010 21:15:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3KLFPxw038601; Tue, 20 Apr 2010 17:15:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3KLFPwR038600; Tue, 20 Apr 2010 21:15:25 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 20 Apr 2010 21:15:25 GMT Message-Id: <201004202115.o3KLFPwR038600@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 21:15:26 -0000 TB --- 2010-04-20 20:03:53 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-20 20:03:53 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2010-04-20 20:03:53 - cleaning the object tree TB --- 2010-04-20 20:04:09 - cvsupping the source tree TB --- 2010-04-20 20:04:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2010-04-20 20:07:01 - building world TB --- 2010-04-20 20:07:01 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-20 20:07:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-20 20:07:01 - TARGET=powerpc TB --- 2010-04-20 20:07:01 - TARGET_ARCH=powerpc TB --- 2010-04-20 20:07:01 - TZ=UTC TB --- 2010-04-20 20:07:01 - __MAKE_CONF=/dev/null TB --- 2010-04-20 20:07:01 - cd /src TB --- 2010-04-20 20:07:01 - /usr/bin/make -B buildworld >>> World build started on Tue Apr 20 20:07:01 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Apr 20 21:03:05 UTC 2010 TB --- 2010-04-20 21:03:05 - generating LINT kernel config TB --- 2010-04-20 21:03:05 - cd /src/sys/powerpc/conf TB --- 2010-04-20 21:03:05 - /usr/bin/make -B LINT TB --- 2010-04-20 21:03:05 - building LINT kernel TB --- 2010-04-20 21:03:05 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-20 21:03:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-20 21:03:05 - TARGET=powerpc TB --- 2010-04-20 21:03:05 - TARGET_ARCH=powerpc TB --- 2010-04-20 21:03:05 - TZ=UTC TB --- 2010-04-20 21:03:05 - __MAKE_CONF=/dev/null TB --- 2010-04-20 21:03:05 - cd /src TB --- 2010-04-20 21:03:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Apr 20 21:03:05 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ===> geom/geom_sched (all) ===> geom/geom_sched/gs_sched (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mlongcall -fno-omit-frame-pointer -I/obj/powerpc/src/sys/LINT -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c cc1: warnings being treated as errors /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c: In function 'g_sched_issuer_pid': /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: implicit declaration of function 'g_sched_issuer' /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: nested extern declaration of 'g_sched_issuer' /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: initialization makes pointer from integer without a cast *** Error code 1 Stop in /src/sys/modules/geom/geom_sched/gs_sched. *** Error code 1 Stop in /src/sys/modules/geom/geom_sched. *** Error code 1 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-20 21:15:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-20 21:15:25 - ERROR: failed to build lint kernel TB --- 2010-04-20 21:15:25 - 3386.05 user 568.74 system 4291.59 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Tue Apr 20 21:30:33 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE091106568E; Tue, 20 Apr 2010 21:30:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A6F508FC1B; Tue, 20 Apr 2010 21:30:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3KLUWU1062416; Tue, 20 Apr 2010 17:30:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3KLUVnL062415; Tue, 20 Apr 2010 21:30:31 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 20 Apr 2010 21:30:31 GMT Message-Id: <201004202130.o3KLUVnL062415@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 21:30:33 -0000 TB --- 2010-04-20 20:23:53 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-20 20:23:53 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2010-04-20 20:23:53 - cleaning the object tree TB --- 2010-04-20 20:24:08 - cvsupping the source tree TB --- 2010-04-20 20:24:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2010-04-20 20:26:05 - building world TB --- 2010-04-20 20:26:05 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-20 20:26:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-20 20:26:05 - TARGET=sparc64 TB --- 2010-04-20 20:26:05 - TARGET_ARCH=sparc64 TB --- 2010-04-20 20:26:05 - TZ=UTC TB --- 2010-04-20 20:26:05 - __MAKE_CONF=/dev/null TB --- 2010-04-20 20:26:05 - cd /src TB --- 2010-04-20 20:26:05 - /usr/bin/make -B buildworld >>> World build started on Tue Apr 20 20:26:05 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Apr 20 21:16:59 UTC 2010 TB --- 2010-04-20 21:16:59 - generating LINT kernel config TB --- 2010-04-20 21:16:59 - cd /src/sys/sparc64/conf TB --- 2010-04-20 21:16:59 - /usr/bin/make -B LINT TB --- 2010-04-20 21:16:59 - building LINT kernel TB --- 2010-04-20 21:16:59 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-20 21:16:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-20 21:16:59 - TARGET=sparc64 TB --- 2010-04-20 21:16:59 - TARGET_ARCH=sparc64 TB --- 2010-04-20 21:16:59 - TZ=UTC TB --- 2010-04-20 21:16:59 - __MAKE_CONF=/dev/null TB --- 2010-04-20 21:16:59 - cd /src TB --- 2010-04-20 21:16:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Apr 20 21:16:59 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ===> geom/geom_sched (all) ===> geom/geom_sched/gs_sched (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c cc1: warnings being treated as errors /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c: In function 'g_sched_issuer_pid': /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: implicit declaration of function 'g_sched_issuer' /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: nested extern declaration of 'g_sched_issuer' /src/sys/modules/geom/geom_sched/gs_sched/../../../../geom/sched/g_sched.c:760: warning: initialization makes pointer from integer without a cast *** Error code 1 Stop in /src/sys/modules/geom/geom_sched/gs_sched. *** Error code 1 Stop in /src/sys/modules/geom/geom_sched. *** Error code 1 Stop in /src/sys/modules/geom. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-20 21:30:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-20 21:30:31 - ERROR: failed to build lint kernel TB --- 2010-04-20 21:30:31 - 3272.77 user 560.33 system 3998.65 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Wed Apr 21 00:55:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B860B106564A for ; Wed, 21 Apr 2010 00:55:48 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 795298FC26 for ; Wed, 21 Apr 2010 00:55:48 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 5516019E027 for ; Wed, 21 Apr 2010 02:55:46 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 0C76719E023 for ; Wed, 21 Apr 2010 02:55:44 +0200 (CEST) Message-ID: <4BCE4D0F.2020807@quip.cz> Date: Wed, 21 Apr 2010 02:55:43 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: /libexec/ld-elf.so.1: Cannot execute objects on / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 00:55:48 -0000 I have large storage partition (/vol0) mounted as noexec and nosuid. Then one directory from this partition is mounted by nullfs as "exec and suid" so anything on it can be executed. The directory contains full installation of jail. Jail is running fine, but some ports (PHP for example) cannot be compiled inside the jail with message: /libexec/ld-elf.so.1: Cannot execute objects on / The same apply to executing of apxs root@rainnew ~/# /usr/local/sbin/apxs -q MPM_NAME /libexec/ld-elf.so.1: Cannot execute objects on / apxs:Error: Sorry, no shared object support for Apache. apxs:Error: available under your platform. Make sure. apxs:Error: the Apache module mod_so is compiled into. apxs:Error: your server binary '/usr/local/sbin/httpd'.. (it should return "prefork") So I think there is some bug in checking the mountpoint options, where the check is made on "parent" of the nullfs instead of the nullfs target mountpoint. It is on 6.4-RELEASE i386 GENERIC. I did not test it on another release. This is list of related mount points: /dev/mirror/gm0s2d on /vol0 (ufs, local, noexec, nosuid, soft-updates) /vol0/jail/.nullfs/rain on /vol0/jail/rain_new (nullfs, local) /usr/ports on /vol0/jail/rain_new/usr/ports (nullfs, local) devfs on /vol0/jail/rain_new/dev (devfs, local) If I changed /vol0 options to (ufs, local, soft-updates) the above error is gone and apxs / compilation works fine. Can somebody look at this problem? Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed Apr 21 01:46:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E506106566C for ; Wed, 21 Apr 2010 01:46:41 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 030B88FC13 for ; Wed, 21 Apr 2010 01:46:40 +0000 (UTC) Received: by qyk11 with SMTP id 11so7421200qyk.13 for ; Tue, 20 Apr 2010 18:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=K5sGCAJETxjNcQPxWGsp4iwt1lDUaxzw9JX2ASgCfIM=; b=MQB3jb0zb0PM2xljeSw652RZT8HIX4Wv86mkzyhmq6hzclcsiXwsA1Ltse7DWAMe1N PgTwkeVznb5EPr2YuJFmrvReAcH0y6r3N1SNpXClGInVJ0hH10yIwZOYNddfkaFUsdx+ O3ckQBp+dNLjkHmrkNRpSl0KGb+tKqSZ+0Jyk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dIhojOyhz6TUphuUDkSBiH/dwGmnTl9SHdX2d/RvNwg62xp3J+R6oq09XAG8y8Zzai OROhYgNtnJSGFBQRjfnLmYONKD2qy1avpj3VVXbjMd76J3iArHd3M8AIYVVH7GOJsYJw c/4ouoyUQQJeRLcG+o/lGrQ8gTtwSQr6ueQ8E= MIME-Version: 1.0 Received: by 10.229.28.85 with HTTP; Tue, 20 Apr 2010 18:46:40 -0700 (PDT) In-Reply-To: <4BCE4D0F.2020807@quip.cz> References: <4BCE4D0F.2020807@quip.cz> Date: Tue, 20 Apr 2010 18:46:40 -0700 Received: by 10.229.225.7 with SMTP id iq7mr3209432qcb.26.1271814400288; Tue, 20 Apr 2010 18:46:40 -0700 (PDT) Message-ID: From: Garrett Cooper To: Miroslav Lachman <000.fbsd@quip.cz> Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: /libexec/ld-elf.so.1: Cannot execute objects on / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 01:46:42 -0000 2010/4/20 Miroslav Lachman <000.fbsd@quip.cz>: > I have large storage partition (/vol0) mounted as noexec and nosuid. Then > one directory from this partition is mounted by nullfs as "exec and suid" so > anything on it can be executed. > > The directory contains full installation of jail. Jail is running fine, but > some ports (PHP for example) cannot be compiled inside the jail with > message: > > /libexec/ld-elf.so.1: Cannot execute objects on / > > The same apply to executing of apxs > > root@rainnew ~/# /usr/local/sbin/apxs -q MPM_NAME > /libexec/ld-elf.so.1: Cannot execute objects on / > > apxs:Error: Sorry, no shared object support for Apache. > apxs:Error: available under your platform. Make sure. > apxs:Error: the Apache module mod_so is compiled into. > apxs:Error: your server binary '/usr/local/sbin/httpd'.. > > (it should return "prefork") > > So I think there is some bug in checking the mountpoint options, where the > check is made on "parent" of the nullfs instead of the nullfs target > mountpoint. > > It is on 6.4-RELEASE i386 GENERIC. I did not test it on another release. > > This is list of related mount points: > > /dev/mirror/gm0s2d on /vol0 (ufs, local, noexec, nosuid, soft-updates) > /vol0/jail/.nullfs/rain on /vol0/jail/rain_new (nullfs, local) > /usr/ports on /vol0/jail/rain_new/usr/ports (nullfs, local) > devfs on /vol0/jail/rain_new/dev (devfs, local) > > If I changed /vol0 options to (ufs, local, soft-updates) the above error is > gone and apxs / compilation works fine. > > Can somebody look at this problem? Can you please provide output from ktrace / truss for the issue? Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Wed Apr 21 02:42:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64579106566C for ; Wed, 21 Apr 2010 02:42:38 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 235148FC16 for ; Wed, 21 Apr 2010 02:42:37 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 59D2919E027; Wed, 21 Apr 2010 04:42:35 +0200 (CEST) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id EFDEB19E023; Wed, 21 Apr 2010 04:42:31 +0200 (CEST) Message-ID: <4BCE6615.9010707@quip.cz> Date: Wed, 21 Apr 2010 04:42:29 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4 MIME-Version: 1.0 To: Garrett Cooper References: <4BCE4D0F.2020807@quip.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: /libexec/ld-elf.so.1: Cannot execute objects on / X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 02:42:38 -0000 Garrett Cooper wrote: > 2010/4/20 Miroslav Lachman<000.fbsd@quip.cz>: >> I have large storage partition (/vol0) mounted as noexec and nosuid. Then >> one directory from this partition is mounted by nullfs as "exec and suid" so >> anything on it can be executed. >> >> The directory contains full installation of jail. Jail is running fine, but >> some ports (PHP for example) cannot be compiled inside the jail with >> message: >> >> /libexec/ld-elf.so.1: Cannot execute objects on / >> >> The same apply to executing of apxs >> >> root@rainnew ~/# /usr/local/sbin/apxs -q MPM_NAME >> /libexec/ld-elf.so.1: Cannot execute objects on / >> >> apxs:Error: Sorry, no shared object support for Apache. >> apxs:Error: available under your platform. Make sure. >> apxs:Error: the Apache module mod_so is compiled into. >> apxs:Error: your server binary '/usr/local/sbin/httpd'.. >> >> (it should return "prefork") >> >> So I think there is some bug in checking the mountpoint options, where the >> check is made on "parent" of the nullfs instead of the nullfs target >> mountpoint. >> >> It is on 6.4-RELEASE i386 GENERIC. I did not test it on another release. >> >> This is list of related mount points: >> >> /dev/mirror/gm0s2d on /vol0 (ufs, local, noexec, nosuid, soft-updates) >> /vol0/jail/.nullfs/rain on /vol0/jail/rain_new (nullfs, local) >> /usr/ports on /vol0/jail/rain_new/usr/ports (nullfs, local) >> devfs on /vol0/jail/rain_new/dev (devfs, local) >> >> If I changed /vol0 options to (ufs, local, soft-updates) the above error is >> gone and apxs / compilation works fine. >> >> Can somebody look at this problem? > > Can you please provide output from ktrace / truss for the issue? I did # ktrace /usr/local/sbin/apxs -q MPM_NAME The output is here http://freebsd.quip.cz/ld-elf/ktrace.out Let me know if you need something else. Thank you for your interest! Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed Apr 21 07:55:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4873106564A; Wed, 21 Apr 2010 07:55:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 10B938FC13; Wed, 21 Apr 2010 07:55:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 1C97541C707; Wed, 21 Apr 2010 09:55:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 4fK10W4iQAFT; Wed, 21 Apr 2010 09:55:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id EBADE41C6DB; Wed, 21 Apr 2010 09:55:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 9F81E4448EC; Wed, 21 Apr 2010 07:54:46 +0000 (UTC) Date: Wed, 21 Apr 2010 07:54:46 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: pluknet In-Reply-To: Message-ID: <20100421074959.J40281@maildrop.int.zabbadoz.net> References: <201004200748.09566.jhb@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-945982823-1271836486=:40281" Cc: freebsd-stable@freebsd.org, c0re , John Baldwin , net@freebsd.org Subject: Re: FreeBSD 7.3, reboot after panic: double fault X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 07:55:09 -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-945982823-1271836486=:40281 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 20 Apr 2010, pluknet wrote: > On 20 April 2010 15:48, John Baldwin wrote: >> On Tuesday 20 April 2010 2:53:16 am c0re wrote: >>> Hello All! >>> I've upgraded freebsd from 7.0 to 7.3 and all was good until I tryed to >>> configure gre interface and use ipfw fwd. >>> I'm actually does not know what was the point of failure in my >>> configuration. >>> >>> [ some details snipped ] >>> >>> It worked about one week and then I made some configuration changes: >>> added gre interface and 2 aliases: >>> >>> # cat /etc/rc.conf |grep >>> ifconfig_xl0=3D"inet 192.168.0.10 =A0netmask 255.255.255.0" >>> ifconfig_xl0_alias0=3D"192.168.0.11 netmask 255.255.255.255" >>> ifconfig_xl0_alias1=3D"192.168.0.12 netmask 255.255.255.255" >>> cloned_interfaces=3D"gre0" >>> ifconfig_gre0=3D"inet 192.168.250.6 192.168.250.5 tunnel 192.168.0.12 >>> 192.168.200.15 netmask 255.255.255.252 link1 up" >>> >>> and >>> >>> # cat /etc/rc.local >>> #!/bin/sh >>> ipfw add fwd 192.168.250.5 icmp from 192.168.0.11 to any out via xl0 >>> ipfw add fwd 192.168.250.5 tcp from 192.168.0.11 443 to any out via xl0 >>> ipfw add allow ip from any to any >>> >>> # ifconfig gre0 >>> gre0: flags=3Db050 metric 0 = mtu >>> 1476 >>> =A0 =A0 =A0 =A0 tunnel inet 192.168.0.12 --> 192.168.200.15 >>> =A0 =A0 =A0 =A0 inet 192.168.250.6 --> 192.168.250.5 netmask 0xfffffffc >>> >>> I shutted down gre interface to prevent requests via gre to buggy IP. >>> >>> The main idea of such configurations was: fwd all connections to https = to >>> 192.168.0.1 via gre interface. >>> And also I made apache configurations to make it listen on 192.168.0.11= too. >>> >>> And make some tests: ping 192.168.0.11 - was fine, goes via gre. Telnet= to >>> 192.168.0.11 =A0443 was fine too. Then I tryed to make browser https >>> connection to 192.168.0.11. Apache showed me certificate warning and I >>> accepted, then in browser nothing happened, it was trying to open page.= But >>> server got kernel panic at that moment. >>> >>> At first time I thought that it was some power failure, I tryed 2 more = times >>> and got same behaviour. >>> >>> So https works without kernel panic via 192.168.0.10 address but kernel >>> panics when I try do https via 192.168.0.11 address that source-forward= ed >>> via gre. >> >> Looks like the TCP output path got stuck in an infinite recursion loop u= ntil >> it exhausted the kernel stack: >> >>> # cd /usr/obj/usr/src/sys/MYKERNEL >>> # kgdb kernel.debug /var/crash/vmcore.2 >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and yo= u are >>> welcome to change it and/or distribute copies of it under certain >>> conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. =A0Type "show warranty" for de= tails. >>> This GDB was configured as "i386-marcel-freebsd"... >>> >>> Unread portion of the kernel message buffer: >>> >>> Fatal double fault: >>> eip =3D 0xc08e3ba3 >>> esp =3D 0xccf6dfc4 >>> ebp =3D 0xccf6e274 >>> cpuid =3D 0; apic id =3D 00 >>> panic: double fault >>> cpuid =3D 0 >>> Uptime: 7m14s >>> Physical memory: 235 MB >>> Dumping 35 MB: 20 4 >>> >>> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >>> /boot/kernel/acpi.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/acpi.ko >>> Reading symbols from /boot/kernel/if_gre.ko...Reading symbols from >>> /boot/kernel/if_gre.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/if_gre.ko >>> Reading symbols from /boot/kernel/linux.ko...Reading symbols from >>> /boot/kernel/linux.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/linux.ko >>> #0 =A0doadump () at pcpu.h:196 >>> 196 =A0 =A0 =A0 =A0 =A0 =A0 __asm __volatile("movl %%fs:0,%0" : "=3Dr" = (td)); >>> (kgdb) bt >>> #0 =A0doadump () at pcpu.h:196 >>> #1 =A00xc07f2857 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdo= wn.c:418 >>> #2 =A00xc07f2b29 in panic (fmt=3DVariable "fmt" is not available. >>> ) at /usr/src/sys/kern/kern_shutdown.c:574 >>> #3 =A00xc0a7ea2b in dblfault_handler () at /usr/src/sys/i386/i386/trap.= c:983 >>> #4 =A00xc08e3ba3 in ipfw_chk (args=3D0xccf6e28c) at >>> /usr/src/sys/netinet/ip_fw2.c:2465 >>> #5 =A00xc08e6ce1 in ipfw_check_out (arg=3D0x0, m0=3D0xccf6e390, ifp=3D0= xc25c5c00, >>> dir=3D2, inp=3D0xc28ba708) at /usr/src/sys/netinet/ip_fw_pfil.c:248 >>> #6 =A00xc08a1968 in pfil_run_hooks (ph=3D0xc0c55240, mp=3D0xccf6e420, >>> ifp=3D0xc25c5c00, dir=3D2, inp=3D0xc28ba708) at /usr/src/sys/net/pfil.c= :78 >>> #7 =A00xc08eb6f2 in ip_output (m=3D0xc2710b00, opt=3D0x0, ro=3D0xccf6e3= f4, flags=3D0, >>> imo=3D0x0, inp=3D0xc28ba708) at /usr/src/sys/netinet/ip_output.c:443 >>> #8 =A00xc08f4016 in tcp_output (tp=3D0xc25b2570) at >>> /usr/src/sys/netinet/tcp_output.c:1134 [twiddle] >>> #47 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offl= oad.h:269 >>> #48 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >>> /usr/src/sys/netinet/tcp_output.c:1195 >>> #49 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offl= oad.h:269 >>> ---Type to continue, or q to quit--- >>> #50 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >>> /usr/src/sys/netinet/tcp_output.c:1195 >>> #51 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offl= oad.h:269 >>> #52 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >>> /usr/src/sys/netinet/tcp_output.c:1195 >>> #53 0xc08f6d98 in tcp_mtudisc (inp=3D0xc28ba708, errno=3D0) at tcp_offl= oad.h:269 >>> #54 0xc08f4105 in tcp_output (tp=3D0xc25b2570) at >>> /usr/src/sys/netinet/tcp_output.c:1195 >>> #55 0xc08fdcf8 in tcp_usr_send (so=3D0xc2ac1820, flags=3D0, m=3D0xc270e= d00, >>> nam=3D0x0, control=3D0x0, td=3D0xc28e2d80) at tcp_offload.h:269 >>> #56 0xc0850405 in sosend_generic (so=3D0xc2ac1820, addr=3D0x0, uio=3D0x= c28766c0, >>> top=3D0xc270ed00, control=3D0x0, flags=3D0, td=3D0xc28e2d80) at >>> /usr/src/sys/kern/uipc_socket.c:1243 >>> #57 0xc084bf7f in sosend (so=3D0xc2ac1820, addr=3D0x0, uio=3D0xc28766c0= , top=3D0x0, >>> control=3D0x0, flags=3D0, td=3D0xc28e2d80) at /usr/src/sys/kern/uipc_so= cket.c:1285 >>> #58 0xc0833c5b in soo_write (fp=3D0xc28e84c0, uio=3D0xc28766c0, >>> active_cred=3D0xc28e5900, flags=3D0, td=3D0xc28e2d80) at >>> /usr/src/sys/kern/sys_socket.c:103 >>> #59 0xc082d2e7 in dofilewrite (td=3D0xc28e2d80, fd=3D24, fp=3D0xc28e84c= 0, >>> auio=3D0xc28766c0, offset=3D-1, flags=3D0) at file.h:257 >>> #60 0xc082d5c8 in kern_writev (td=3D0xc28e2d80, fd=3D24, auio=3D0xc2876= 6c0) at >>> /usr/src/sys/kern/sys_generic.c:402 >>> #61 0xc082d816 in writev (td=3D0xc28e2d80, uap=3D0xccf6fcfc) at >>> /usr/src/sys/kern/sys_generic.c:388 >>> #62 0xc0a7f2d5 in syscall (frame=3D0xccf6fd38) at >>> /usr/src/sys/i386/i386/trap.c:1101 >>> #63 0xc0a636a0 in Xint0x80_syscall () at >>> /usr/src/sys/i386/i386/exception.s:262 >>> #64 0x00000033 in ?? () >>> Previous frame inner to this frame (corrupt stack?) >>> (kgdb) >>> (kgdb) quit >> >> tcp_output() calls tcp_mtudisc() if ip_output() returns EMSGSIZE: >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0case EMSGSIZE: >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * For some reason the in= terface we used initially >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * to send segments chang= ed to another or lowered >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * its MTU. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * tcp_mtudisc() will fin= d out the new MTU and as >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * its last action, initi= ate retransmission, so it >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * is important to not do= so here. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * If TSO was active we e= ither got an interface >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * without TSO capabilits= or TSO was turned off. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Disable it for this co= nnection as too and >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * immediatly retry with = MSS sized segments generated >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * by this function. >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (tso) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tp->t_fla= gs &=3D ~TF_TSO; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tcp_mtudisc(tp->t_inpcb, = 0); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); >> >> But tcp_mtudisc() calls tcp_output(): >> >> =A0 =A0 =A0 =A0tcpstat.tcps_mturesent++; >> =A0 =A0 =A0 =A0tp->t_rtttime =3D 0; >> =A0 =A0 =A0 =A0tp->snd_nxt =3D tp->snd_una; >> =A0 =A0 =A0 =A0tcp_free_sackholes(tp); >> =A0 =A0 =A0 =A0tp->snd_recover =3D tp->snd_max; >> =A0 =A0 =A0 =A0if (tp->t_flags & TF_SACK_PERMIT) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0EXIT_FASTRECOVERY(tp); >> =A0 =A0 =A0 =A0tcp_output_send(tp); >> =A0 =A0 =A0 =A0return (inp); >> >> I'm not sure why it's not able to figure out the MTU, perhaps folks on n= et@ >> can help. =A0However, it would seem that for the tcp_output() case, >> tcp_mtudisc() should probably not call tcp_output_send(), but instead >> tcp_output() should just loop back up to the top after calling tcp_mtudi= sc() >> and retry. >> > > I'm afraid to be wrong but it looks similar to another report for 8.0-STA= BLE > (may it be a cross-major version regression somewhere around tcp_mtudisc(= )?): > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056063.html The backtrace indeed looks very similar. The reporter at that point had been cvs updated in the middle between two commits. Updating again seemed to have fixed it for him. None of those changes are in 7.3-RELEASE though and the endless loop indeed should no happen. Is the kernel and the core file still avail for further analyses? /bz --=20 Bjoern A. Zeeb It will not break if you know what you are doing. --0-945982823-1271836486=:40281-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 21 08:01:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9B59106566B for ; Wed, 21 Apr 2010 08:01:21 +0000 (UTC) (envelope-from ukrzilla@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6232C8FC13 for ; Wed, 21 Apr 2010 08:01:21 +0000 (UTC) Received: by wwa36 with SMTP id 36so4371839wwa.13 for ; Wed, 21 Apr 2010 01:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=65d7hTHy4b2dWioqLn0RqVKJLODIVouenEoJpArUOU8=; b=sBdEjSdKzaN0BdmOZ4q6UPiHtGvjSsNG5a6DCqPLcVJfRRFSak1P14LxVJNIWIixx0 dA4yPTjG6iUyNI993v9XiucOqJWP/IAtL6kfMmO7hKpacGmRWGlnhOIlp1zenC0ZZyPT QrAtOe5EnF27OsX45SCM6+PZPobfZnAFNjXxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LfwxXz7cLSqampmiQzNFuTJeZ85jXCFHNzzx4JuZJwCZTnb3ewgdA5epKs7pySaMmX 81pycCNpLT8RteYc5JD38136PhmiceiRWPDcL9qRCiQ5gdk8n+9fBHQkcaTXoSWEMJfL iulv+IMDNX826E2Uo+Nb/BLH9jFo4+IpcqHkM= MIME-Version: 1.0 Received: by 10.216.24.149 with HTTP; Wed, 21 Apr 2010 00:34:32 -0700 (PDT) Date: Wed, 21 Apr 2010 10:34:32 +0300 Received: by 10.216.89.195 with SMTP id c45mr1274310wef.98.1271835272928; Wed, 21 Apr 2010 00:34:32 -0700 (PDT) Message-ID: From: Denis Lamanov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: kernel: arpresolve: can't allocate llinfo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:01:21 -0000 Hi! I am ukranian and bad speak english :( I have VPN servers with mpd5.5 and FreeBSD 8.0 upgrade it to 8.0-STABLE #1 r206493 all servers have real static IP address in mpd enabled proxy-arp and mpd provide real static IP address into pptp/l2tp tunnels. Periodic in console and /var/log/debug.log writes: kernel: arpresolve: can't allocate llinfo for 155.xx.xx.1 kernel: arpresolve: can't allocate llinfo for 155.xx.xx.123 kernel: arpresolve: can't allocate llinfo for 155.xx.xx.456 and after server kernel panic/trap 12 with current proccess: ng_queue From owner-freebsd-stable@FreeBSD.ORG Wed Apr 21 08:58:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C54381065673 for ; Wed, 21 Apr 2010 08:58:58 +0000 (UTC) (envelope-from askjuise@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 7C0258FC1E for ; Wed, 21 Apr 2010 08:58:58 +0000 (UTC) Received: by qyk11 with SMTP id 11so7855483qyk.13 for ; Wed, 21 Apr 2010 01:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=U+KttqBlqrF7wpQlk39471e3iFJ58NJPXPMOzTPmKX0=; b=H6Jewk8aK07xGQjJcs6/M+d1/x47KCfVj8sAVJKhLFnz3Ml2+W7YJTwX2KsEw/QBKR +7MGYY8jbYbnAeurIpPDY+dtSqmOh7M+xiUzeSFkyr6IWBE1qSf9nkdFywULT0bVafYo hIpFfaVM9jcKilbl6jyKZ9it+LqytyrKLmFeA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=XqLYJZ9TP+wCWheKQb3WolxnWydQg0D2tq9MnCpI+jTLzK4nAG7cdSnK46WCx2JWRY MNyTBAIdrV0HxpX22kjbkYsT/chU+h0mOKHGlEx9+SCDrbaj16hySxYxaelLWhoKoSSu 3hWkWROQrdbvZiWYUEehxqbnofkOKMs8eChf4= MIME-Version: 1.0 Received: by 10.229.46.85 with HTTP; Wed, 21 Apr 2010 01:58:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Apr 2010 17:58:57 +0900 Received: by 10.229.219.203 with SMTP id hv11mr59314qcb.46.1271840337267; Wed, 21 Apr 2010 01:58:57 -0700 (PDT) Message-ID: From: Alexander Petrovsky To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: kernel: arpresolve: can't allocate llinfo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:58:58 -0000 Hello! I have some problem. Every day! # cat /var/log/debug.log Apr 21 05:58:26 troll kernel: arpresolve: can't allocate llinfo for 84.*.23.36 Apr 21 05:58:56 troll kernel: arpresolve: can't allocate llinfo for 84.*.23.36 Apr 21 06:10:31 troll kernel: arpresolve: can't allocate llinfo for 84.*.23.36 Apr 21 16:28:13 troll kernel: arpresolve: can't allocate llinfo for 84.*.23.36 ... etc. # ifconfig em0: flags=3D8843 metric 0 mtu 1500 options=3D1db ether 00:0a:e4:0a:78:f5 inet 84.*.23.36 netmask 0xffffffc0 broadcast 84.*.23.63 media: Ethernet autoselect (100baseTX ) status: active rl0: flags=3D8843 metric 0 mtu 1500 options=3D48 ether 00:14:d1:14:62:63 inet 84.*.22.3 netmask 0xffffff80 broadcast 84.*.22.127 ... inet 84.*.22.16 netmask 0xffffff80 broadcast 84.*.22.127 media: Ethernet autoselect (100baseTX ) status: active rl1: flags=3D8843 metric 0 mtu 1500 options=3D48 ether 00:40:f4:cc:d2:98 inet 192.168.47.3 netmask 0xffffff00 broadcast 192.168.47.255 ... inet 192.168.47.16 netmask 0xffffff00 broadcast 192.168.47.255 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=3D8049 metric 0 mtu 16384 # uname -a FreeBSD * 8.0-STABLE FreeBSD 8.0-STABLE #0 r199880: Thu Dec 3 13:35:21 IRK= T 2009 alexander@*:/usr/obj/usr/src/sys/WEBKERNEL i386 what could be the problem? 2010/4/21 Denis Lamanov Hi! I am ukranian and bad speak english :( > I have VPN servers with mpd5.5 and FreeBSD 8.0 > upgrade it to 8.0-STABLE #1 r206493 > all servers have real static IP address > in mpd enabled proxy-arp and mpd provide real static IP address into > pptp/l2tp tunnels. > Periodic in console and /var/log/debug.log writes: > kernel: arpresolve: can't allocate llinfo for 155.xx.xx.1 > kernel: arpresolve: can't allocate llinfo for 155.xx.xx.123 > kernel: arpresolve: can't allocate llinfo for 155.xx.xx.456 > > and after server kernel panic/trap 12 with current proccess: ng_queue > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > --=20 =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2=D1=81=D0=BA=D0=B8=D0=B9 =D0=90=D0=BB= =D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 / Alexander Petrovsky, ICQ: 350342118 Jabber: juise@jabber.ru Phone: +7 914 8 820 815 From owner-freebsd-stable@FreeBSD.ORG Wed Apr 21 09:02:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01F751065670 for ; Wed, 21 Apr 2010 09:02:39 +0000 (UTC) (envelope-from ukrzilla@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 83F4C8FC08 for ; Wed, 21 Apr 2010 09:02:38 +0000 (UTC) Received: by wye20 with SMTP id 20so763450wye.13 for ; Wed, 21 Apr 2010 02:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=6L7WR/7ChTgP0PWespqVCOuOZ7TDpKwaolrZBTI4JRA=; b=hM2lqk7uzAAJvFYmxMZN4ZZok/ASctLdTnGv3uMQNGWKYwR9RrzdMxFzxPcdD1PK3s 09sJ20Qb8msRBcxnJS5LC3+kbQsRAFgtb+YjBFZ0t/Qi8U79lVArWWKdrLfN2z7twcNG n5iG/RQlCRpXbL+xvPtEPfJcUQb9hnZOZBOaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Hcga42CDidZkNJ7rZqNaIaObSggdsIOmu4LTzzK+D35jNWd+v9YEyyAlYCDThbOoWL oviFEvwZoUtqBml9MKerbBpuZ01iOZU11noXgvdl7GWZn/53JxMFZpAvj2RjgJ13HhG0 gyLbXkiHFLwghS3mqX9JFEKELjS5bbRCdocD0= MIME-Version: 1.0 Received: by 10.216.24.149 with HTTP; Wed, 21 Apr 2010 02:02:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Apr 2010 12:02:37 +0300 Received: by 10.216.176.212 with SMTP id b62mr1882317wem.179.1271840557095; Wed, 21 Apr 2010 02:02:37 -0700 (PDT) Message-ID: From: Denis Lamanov To: Alexander Petrovsky , freebsd-stable@freebsd.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: kernel: arpresolve: can't allocate llinfo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:02:39 -0000 vmstat -m | grep lltable every 3 minutes increases :( lltable 16938 2149K - 17779 128,256 2010/4/21 Alexander Petrovsky > Hello! > > I have some problem. Every day/ > > # cat /var/log/debug.log > Apr 21 05:58:26 troll kernel: arpresolve: can't allocate llinfo for > 84.*.23.36 > Apr 21 05:58:56 troll kernel: arpresolve: can't allocate llinfo for > 84.*.23.36 > Apr 21 06:10:31 troll kernel: arpresolve: can't allocate llinfo for > 84.*.23.36 > Apr 21 16:28:13 troll kernel: arpresolve: can't allocate llinfo for > 84.*.23.36 > ... etc. > > # ifconfig > em0: flags=3D8843 metric 0 mtu 15= 00 > > options=3D1db > ether 00:0a:e4:0a:78:f5 > inet 84.*.23.36 netmask 0xffffffc0 broadcast 84.*.23.63 > media: Ethernet autoselect (100baseTX ) > status: active > rl0: flags=3D8843 metric 0 mtu 15= 00 > options=3D48 > ether 00:14:d1:14:62:63 > inet 84.*.22.3 netmask 0xffffff80 broadcast 84.*.22.127 > ... > inet 84.*.22.16 netmask 0xffffff80 broadcast 84.*.22.127 > media: Ethernet autoselect (100baseTX ) > status: active > rl1: flags=3D8843 metric 0 mtu 15= 00 > options=3D48 > ether 00:40:f4:cc:d2:98 > inet 192.168.47.3 netmask 0xffffff00 broadcast 192.168.47.255 > ... > inet 192.168.47.16 netmask 0xffffff00 broadcast 192.168.47.255 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=3D8049 metric 0 mtu 16384 > > # uname -a > FreeBSD * 8.0-STABLE FreeBSD 8.0-STABLE #0 r199880: Thu Dec 3 13:35:21 > IRKT 2009 alexander@*:/usr/obj/usr/src/sys/WEBKERNEL i386 > > what could be the problem? > > 2010/4/21 Denis Lamanov > >> Hi! I am ukranian and bad speak english :( >> I have VPN servers with mpd5.5 and FreeBSD 8.0 >> upgrade it to 8.0-STABLE #1 r206493 >> all servers have real static IP address >> in mpd enabled proxy-arp and mpd provide real static IP address into >> pptp/l2tp tunnels. >> Periodic in console and /var/log/debug.log writes: >> kernel: arpresolve: can't allocate llinfo for 155.xx.xx.1 >> kernel: arpresolve: can't allocate llinfo for 155.xx.xx.123 >> kernel: arpresolve: can't allocate llinfo for 155.xx.xx.456 >> >> and after server kernel panic/trap 12 with current proccess: ng_queue >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org= " >> > > > > -- > =F0=C5=D4=D2=CF=D7=D3=CB=C9=CA =E1=CC=C5=CB=D3=C1=CE=C4=D2 / Alexander Pe= trovsky, > > ICQ: 350342118 > Jabber: juise@jabber.ru > Phone: +7 914 8 820 815 > From owner-freebsd-stable@FreeBSD.ORG Wed Apr 21 15:02:21 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFA851065675; Wed, 21 Apr 2010 15:02:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9E08B8FC17; Wed, 21 Apr 2010 15:02:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3LF2KxT057289; Wed, 21 Apr 2010 11:02:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3LF2KwG057285; Wed, 21 Apr 2010 15:02:20 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 21 Apr 2010 15:02:20 GMT Message-Id: <201004211502.o3LF2KwG057285@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 15:02:22 -0000 TB --- 2010-04-21 14:56:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-21 14:56:29 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2010-04-21 14:56:29 - cleaning the object tree TB --- 2010-04-21 14:56:58 - cvsupping the source tree TB --- 2010-04-21 14:56:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2010-04-21 15:02:20 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-04-21 15:02:20 - ERROR: unable to cvsup the source tree TB --- 2010-04-21 15:02:20 - 2.18 user 12.84 system 350.77 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Wed Apr 21 17:45:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 776DB106564A for ; Wed, 21 Apr 2010 17:45:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 0B3338FC18 for ; Wed, 21 Apr 2010 17:45:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 0F8AE41C64C; Wed, 21 Apr 2010 19:45:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id mSXqS2S7ONkk; Wed, 21 Apr 2010 19:45:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 78C6541C64A; Wed, 21 Apr 2010 19:45:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 63C8D4448EC; Wed, 21 Apr 2010 17:44:06 +0000 (UTC) Date: Wed, 21 Apr 2010 17:44:06 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Denis Lamanov In-Reply-To: Message-ID: <20100421174142.N40281@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Petrovsky , freebsd-stable@freebsd.org Subject: Re: kernel: arpresolve: can't allocate llinfo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 17:45:07 -0000 On Wed, 21 Apr 2010, Denis Lamanov wrote: Hi, > vmstat -m | grep lltable > every 3 minutes increases :( > lltable 16938 2149K - 17779 128,256 I'll MFC the patches to fix that the next couple of days, maybe tommorow morning. In case you want to try them, you'd need SVN r206469,206470,206481 applied to 8-STABLE. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 21 19:55:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 303ED1065677 for ; Wed, 21 Apr 2010 19:55:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id DCDF68FC16 for ; Wed, 21 Apr 2010 19:55:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 4239A41C752; Wed, 21 Apr 2010 21:55:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id tMNPoVZGflSV; Wed, 21 Apr 2010 21:55:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 7EB7341C751; Wed, 21 Apr 2010 21:55:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id AC0DD4448EC; Wed, 21 Apr 2010 19:53:08 +0000 (UTC) Date: Wed, 21 Apr 2010 19:53:08 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Denis Lamanov In-Reply-To: <20100421174142.N40281@maildrop.int.zabbadoz.net> Message-ID: <20100421195127.Y40281@maildrop.int.zabbadoz.net> References: <20100421174142.N40281@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Petrovsky , freebsd-stable@freebsd.org Subject: Re: kernel: arpresolve: can't allocate llinfo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 19:55:07 -0000 On Wed, 21 Apr 2010, Bjoern A. Zeeb wrote: > On Wed, 21 Apr 2010, Denis Lamanov wrote: > > Hi, > >> vmstat -m | grep lltable >> every 3 minutes increases :( >> lltable 16938 2149K - 17779 128,256 > > I'll MFC the patches to fix that the next couple of days, maybe > tommorow morning. In case you want to try them, you'd need > SVN r206469,206470,206481 applied to 8-STABLE. Actually I just merged them. If you wait an hour or two for the changes to show up on your local mirror 8-STABLE should be fine. Please note that if you are using option FLOWTABLE you will still see the leak. I haven't gotten around to update my patches for that. I'll try to remember to post them once done. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 21 20:07:48 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54EAD106566C; Wed, 21 Apr 2010 20:07:48 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from worf.ds9.tecnik93.com (worf.ds9.tecnik93.com [81.196.207.130]) by mx1.freebsd.org (Postfix) with ESMTP id AEEC58FC27; Wed, 21 Apr 2010 20:07:47 +0000 (UTC) Received: from it.buh.tecnik93.com (it.buh.tecnik93.com [81.196.204.98]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by worf.ds9.tecnik93.com (Postfix) with ESMTPSA id AF9A422C50DE; Wed, 21 Apr 2010 23:07:46 +0300 (EEST) Date: Wed, 21 Apr 2010 23:07:46 +0300 From: Ion-Mihai Tetcu To: Ion-Mihai Tetcu Message-ID: <20100421230746.71454b7d@it.buh.tecnik93.com> In-Reply-To: <20100420021420.22e22136@it.buh.tecnik93.com> References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <20100420021420.22e22136@it.buh.tecnik93.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ICxWFpLZ79rTTHCoY=FhSf."; protocol="application/pgp-signature" Cc: stable@freebsd.org, questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 20:07:48 -0000 --Sig_/ICxWFpLZ79rTTHCoY=FhSf. Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 20 Apr 2010 02:14:20 +0300 Ion-Mihai Tetcu wrote: > A switch to use newer GMP version has been committed. >=20 > Unfortunately lang/ghc and dependent ports (and possibly > lang/gnat-gcc44) were broken by this. The brokenness wasn't detected > in our -exp run because of being masked by other issues. A fix has been committed :) --=20 IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B --Sig_/ICxWFpLZ79rTTHCoY=FhSf. Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvPWxIACgkQJ7GIuiH/oeXf5wCggYy4rcXZzCK/D8kJpM7fA7yd vykAnR8/0sa9N79hMKMiCgwqmhyaHM9W =2Dcp -----END PGP SIGNATURE----- --Sig_/ICxWFpLZ79rTTHCoY=FhSf.-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 21 22:15:19 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E53B81065676; Wed, 21 Apr 2010 22:15:19 +0000 (UTC) (envelope-from sterling@camdensoftware.com) Received: from wh2.interactivevillages.com (wh2.interactivevillages.com [75.125.250.34]) by mx1.freebsd.org (Postfix) with ESMTP id 876D78FC19; Wed, 21 Apr 2010 22:15:19 +0000 (UTC) Received: from 174-21-99-21.tukw.qwest.net ([174.21.99.21] helo=_HOSTNAME_) by wh2.interactivevillages.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1O4gqY-0004Ik-Fx; Wed, 21 Apr 2010 13:48:35 -0700 Received: by _HOSTNAME_ (sSMTP sendmail emulation); Wed, 21 Apr 2010 13:52:26 -0700 Date: Wed, 21 Apr 2010 13:52:26 -0700 From: Chip Camden Message-ID: <20100421205226.GA20692@libertas.local.camdensoftware.com> References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <20100420021420.22e22136@it.buh.tecnik93.com> <20100421230746.71454b7d@it.buh.tecnik93.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100421230746.71454b7d@it.buh.tecnik93.com> User-Agent: Mutt/1.4.2.3i X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wh2.interactivevillages.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - camdensoftware.com Cc: stable@freebsd.org, questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 22:15:20 -0000 On Wed, Apr 21, 2010 at 11:07:46PM +0300, Ion-Mihai Tetcu wrote: > On Tue, 20 Apr 2010 02:14:20 +0300 > Ion-Mihai Tetcu wrote: > > > A switch to use newer GMP version has been committed. > > > > Unfortunately lang/ghc and dependent ports (and possibly > > lang/gnat-gcc44) were broken by this. The brokenness wasn't detected > > in our -exp run because of being masked by other issues. > > A fix has been committed :) > > -- > IOnut - Un^d^dregistered ;) FreeBSD "user" > "Intellectual Property" is nowhere near as valuable as "Intellect" > FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B lang/ghc is still marked IGNORE, unless I'm missing something. -- Sterling (Chip) Camden | camdensoftware.com | chipstips.com | chipsquips.com From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 03:37:08 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B1F9106566B for ; Thu, 22 Apr 2010 03:37:08 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7A7C8FC0A for ; Thu, 22 Apr 2010 03:37:07 +0000 (UTC) Received: by gyh20 with SMTP id 20so4248187gyh.13 for ; Wed, 21 Apr 2010 20:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6qVhsaCRWDXOPYg6TBb8XPNpspeYPXKcimAolyQ7UNg=; b=L4d0P6tTjDCOKAgx3j6ui+LVMI6ZC5/LqByhcFnJO+Dp5t52rMt8GuTEVbKUqkDWo+ YR6wnbfkayaJ84BGNyVZtzn0eQ1sKDt+CivbL0Zh5aA31WoLZxwiKjZacKd7rLMARyNd uOZv3s8mGCXTkzjl/MjC7DZlpWTGIWN3ItYoQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=c8hpgt85pnCflAB2iU2f+x6mf2BlO+6CW+83M9hlUIDYp+tMQWIq1nVLIKBiSJHutn vZ1mT3/XKlvRkwrJQypd2+4BkNGLKIdnG88osmYlMyrE2d2Kv1K4x8uhwu+EtFe/zolD bWq1cDLAvLD9ZJYCcZrBG+Rl/nHWw1EMCMZJY= MIME-Version: 1.0 Received: by 10.231.113.36 with HTTP; Wed, 21 Apr 2010 20:07:21 -0700 (PDT) In-Reply-To: References: <20100413151933.GA20976@icarus.home.lan> Date: Wed, 21 Apr 2010 22:07:21 -0500 Received: by 10.101.149.40 with SMTP id b40mr22335083ano.99.1271905642002; Wed, 21 Apr 2010 20:07:22 -0700 (PDT) Message-ID: From: Brandon Gooch To: Lin Jui-Nan Eric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, stable@freebsd.org, Jeremy Chadwick Subject: Re: pf stalls connection when using route-to X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 03:37:08 -0000 On Tue, Apr 13, 2010 at 10:53 AM, Lin Jui-Nan Eric wro= te: > On Tue, Apr 13, 2010 at 11:19 PM, Jeremy Chadwick > wrote: >> >> What FreeBSD version? =A0uname -a output please. >> > I have tried 7.2-R and 8.0-R. Both version stalls, too. > > 8.0-RELEASE: > # uname -a > FreeBSD bsd8 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #3: Wed Mar 3 > 17:15:52 CST 2010 root@bsd8:/usr/obj/usr/src/sys/KERNEL amd64 [SNIP] Jack Vogel recently committed an updated, overhauled em(4) driver to 9-CURRENT, which was MFC'd to 8-STABLE: http://svn.freebsd.org/viewvc/base/stable/8/sys/dev/e1000/ Would it be possible for you to try your configuration on one of these newer versions? -Brandon From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 04:30:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05F35106564A for ; Thu, 22 Apr 2010 04:30:01 +0000 (UTC) (envelope-from ukrzilla@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3EC078FC1B for ; Thu, 22 Apr 2010 04:30:00 +0000 (UTC) Received: by wwa36 with SMTP id 36so5083197wwa.13 for ; Wed, 21 Apr 2010 21:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=TkPDzQlCkou/2rfldQdnOLRQT6IYqhQIvCnFILeaJhU=; b=llMZZsiIrrMomMzD9m76FtjB8eZxK61+Xt6D+6DaWmgfa0dzpmGIKirwE1i3+wHuyX l6ukXS0O2ZnFJGCVxazPBAja8PU1nNyhiL7I/KrzUZUZNJizZLXgGMr+el2l9LmB9Ai2 PochWtjTFkKdayqfVABS86DVM8iyfPJp+ZfH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dLxiFaLNDDtTFC2SHX5WbF7Lj2NGyhzx2cfPZBlnDNYfnEWLUhuqbmPdcgRDP0J2Qc nD/OKOeYlZ+s8kA14M1X1yw8cFRvT/epHBnFgIa6diE2Xw3OQnQVRI9ilmx0PmpGMifX emxBTcbAzKDSJ9c3Nf3D6ND0KshVD4lOvw2TI= MIME-Version: 1.0 Received: by 10.216.24.149 with HTTP; Wed, 21 Apr 2010 21:29:59 -0700 (PDT) In-Reply-To: <20100421195127.Y40281@maildrop.int.zabbadoz.net> References: <20100421174142.N40281@maildrop.int.zabbadoz.net> <20100421195127.Y40281@maildrop.int.zabbadoz.net> Date: Thu, 22 Apr 2010 07:29:59 +0300 Received: by 10.216.162.202 with SMTP id y52mr3327333wek.76.1271910599963; Wed, 21 Apr 2010 21:29:59 -0700 (PDT) Message-ID: From: Denis Lamanov To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Petrovsky , freebsd-stable@freebsd.org Subject: Re: kernel: arpresolve: can't allocate llinfo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 04:30:02 -0000 I am not using option FLOWTABLE and disable in kernel with compile after install FreeBSD8. If i upgrades today to STABLE patches will apply? 2010/4/21 Bjoern A. Zeeb > On Wed, 21 Apr 2010, Bjoern A. Zeeb wrote: > > On Wed, 21 Apr 2010, Denis Lamanov wrote: >> >> Hi, >> >> vmstat -m | grep lltable >>> every 3 minutes increases :( >>> lltable 16938 2149K - 17779 128,256 >>> >> >> I'll MFC the patches to fix that the next couple of days, maybe >> tommorow morning. In case you want to try them, you'd need >> SVN r206469,206470,206481 applied to 8-STABLE. >> > > > Actually I just merged them. If you wait an hour or two for the > changes to show up on your local mirror 8-STABLE should be fine. > > Please note that if you are using option FLOWTABLE you will still see > the leak. I haven't gotten around to update my patches for that. > I'll try to remember to post them once done. > > > /bz > > -- > Bjoern A. Zeeb It will not break if you know what you are doing. > From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 07:19:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46B601065670 for ; Thu, 22 Apr 2010 07:19:37 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp02.srv.cat (smtp02.cdmon.com [212.36.74.55]) by mx1.freebsd.org (Postfix) with ESMTP id 080BE8FC18 for ; Thu, 22 Apr 2010 07:19:35 +0000 (UTC) Received: from jespasac.cdmon.com (155.Red-88-2-251.staticIP.rima-tde.net [88.2.251.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jespasac@noverificar) by smtp02.srv.cat (Postfix) with ESMTP id 01B7246378 for ; Thu, 22 Apr 2010 09:19:33 +0200 (CEST) Message-ID: <4BCFF881.9000809@minibofh.org> Date: Thu, 22 Apr 2010 09:19:29 +0200 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: gmirror(8) rebuild speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 07:19:37 -0000 Hi, I wonder if is possible to configure the gmirror rebuild speed. Neither I've found any related info in the net nor the man pages. -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 08:35:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 488D91065678 for ; Thu, 22 Apr 2010 08:35:12 +0000 (UTC) (envelope-from nr1c0re@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id B1DDF8FC1D for ; Thu, 22 Apr 2010 08:35:11 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so248143fga.13 for ; Thu, 22 Apr 2010 01:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=Y8aTezJESh4uqdtX9d5QW3ki9p+cFCWi8ebtxxDG++w=; b=phuO9p2/egfkfT/sYjDcjyOfZ+8TUdknIE/787sHBEo1xhOPlx0i55/lDCDuYi8hG9 7/R7dzeZovpAkNf2Gy1s3ApIU9znBjGmfY5SDwJ2zGBNBx7s9LMNtuZJNF00I8buG3lg wlKHSRApQmskpbKf/lMQpGahVi9JaT24+cJxc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=E+VmfpdSGvfw0xpXOzw6qeH03biGltiMQCj1fv+nOmUPZDq2WYvUTMHVaHdFHUIp9M qrDzA3hDI14P3Q4u+/h5IhS7w32mHKqbaYFAhj67TDvlMhgebcuB20oLsRABjZn0QwAg tGRnsyfrahV5o7EFKOgctQjsmyPQ5cRHDQU+Q= MIME-Version: 1.0 Received: by 10.86.84.6 with HTTP; Thu, 22 Apr 2010 01:35:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Apr 2010 12:35:10 +0400 Received: by 10.87.66.15 with SMTP id t15mr285533fgk.37.1271925310285; Thu, 22 Apr 2010 01:35:10 -0700 (PDT) Message-ID: From: c0re To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: FreeBSD 7.3, reboot after panic: double fault X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 08:35:12 -0000 Bjoern A. Zeeb, I send you e-mail with link to download kernel and dump. And I remade kernel panic situation on virtual machines. You need 2 freebsd machines for gre tunnel. First need just to make gre tunnel like: ifconfig em0 inet 10.0.0.1 netmask 255.255.255.0 ifconfig gre0 create ifconfig gre0 inet 192.168.0.1 192.168.0.2 tunnel 10.10.0.1 10.10.0.2 netmask 255.255.255.252 link1 up route add 10.10.0.3/32 10.10.0.2 Also this machine will be as a client to connect to remote. So we need to install some browser like lynx. Second machine: Default installation of freebsd 7.3 with "src" checked in distributions. After install - recompile kernel for IPFIREWALL_FORWARD support (mainly): # Local additions options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=1000 #limit verbosity options IPFIREWALL_FORWARD #packet destination changes options IPDIVERT #divert sockets options IPSTEALTH #support for stealth forwarding options DUMMYNET device carp And make kernel KERNCONF=MYKERNEL reboot and configure network and firewall: ifconfig em0 inet 10.10.0.2 netmask 255.255.255.0 ifconfig em0 alias inet 10.0.0.3 netmask 255.255.255.255 ifconfig gre0 create ifconfig gre0 inet 192.168.0.2 192.168.0.1 tunnel 10.0.0.2 10.0.0.1 netmask 255.255.255.252 link1 up ipfw add 00100 fwd 192.168.0.1 icmp from 10.0.0.3 to any out via em0 ipfw add 00200 fwd 192.168.0.1 tcp from 10.0.0.3 80 to any out via em0 ipfw add 00300 fwd 192.168.0.1 tcp from 10.0.0.3 443 to any out via em0 ipfw add 00400 allow ip from any to any At that moment you can check icmp ping from 10.0.0.1 10.0.0.3 and ipfw show to view that ipfw fwd counters are working. Next we need to have some tcp service. I used apache2. So in port /usr/ports/www/apache20 make install clean. apache20_enable="YES" in rc.conf In /usr/local/etc/apache2/httpd.conf: edit "Listen 80" to "Listen 10.0.0.3:80 " and add virtual host with 10kb index.html NameVirtualHost 10.0.0.3:80 > DocumentRoot /usr/local/www/test mkdir /usr/local/www/test dd if=/dev/random of=/usr/local/www/test/index.html bc=10k count=1 /usr/local/etc/rc.d/apache2 start At that moment everything ready to panic :) >From first machine i'm trying lynx http://10.0.0.3/ On second machine I see kernel panic. When I was testing - I got no panic at first time. So I generated apache ssl certs and adited ssl.conf. But next time I made same configuration - not only 443, but 80 port connection made kernel panic too. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 08:59:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 397EA106564A for ; Thu, 22 Apr 2010 08:59:57 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas04p.mx.bigpond.com (nschwmtas04p.mx.bigpond.com [61.9.189.146]) by mx1.freebsd.org (Postfix) with ESMTP id BA97F8FC12 for ; Thu, 22 Apr 2010 08:59:56 +0000 (UTC) Received: from nschwotgx01p.mx.bigpond.com ([124.188.161.100]) by nschwmtas04p.mx.bigpond.com (InterMail vM.7.05.02.08 201-2174-114-118-20080528) with ESMTP id <20100422085954.DIWG9850.nschwmtas04p.mx.bigpond.com@nschwotgx01p.mx.bigpond.com>; Thu, 22 Apr 2010 08:59:54 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx01p.mx.bigpond.com with ESMTP id <20100422085954.NNOH3673.nschwotgx01p.mx.bigpond.com@duncan.reilly.home>; Thu, 22 Apr 2010 08:59:54 +0000 Date: Thu, 22 Apr 2010 18:59:54 +1000 From: Andrew Reilly To: Jordi Espasa Clofent Message-ID: <20100422085954.GA10035@duncan.reilly.home> References: <4BCFF881.9000809@minibofh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BCFF881.9000809@minibofh.org> User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx01p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Thu, 22 Apr 2010 08:59:54 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150204.4BD0100A.015D,ss=1,fgs=0 X-SIH-MSG-ID: ox0yENf3TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rHK+ZRsM6kxDxOJhqNNGQpaangTY3Rs9mK Cc: freebsd-stable@freebsd.org Subject: Re: gmirror(8) rebuild speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 08:59:57 -0000 On Thu, Apr 22, 2010 at 09:19:29AM +0200, Jordi Espasa Clofent wrote: > I wonder if is possible to configure the gmirror rebuild speed. > Neither I've found any related info in the net nor the man pages. To make it slower, I assume? When is that a good idea? Cheers, -- Andrew From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 09:04:43 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6041106564A; Thu, 22 Apr 2010 09:04:43 +0000 (UTC) (envelope-from pali.gabor@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 886FC8FC0A; Thu, 22 Apr 2010 09:04:39 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so260929fga.13 for ; Thu, 22 Apr 2010 02:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type; bh=H0ojKkdAfmogcM8DPQ4s74sUTd4nfnznAa4hR8WsGHI=; b=WSbsw6pacPyQK9NYixnJiFiirTavZDhA2GNxn5rstgfSjoEbqZ9Ry22hKgan3BLe1T dakuMthTCfS1ZkGHH83GpmOxC1DzDLX/RrkgBzEXDFe8jPvbE3fDH/CR1tKQZOG9km3+ cZdx+yXUk8lecD9zC2qDhCsQfihW20bBdovuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ENEExs9zSebLjV5CB2MjnYN0b0tcAeOqIULLACL7bi2T8/BOhIT4sp9oE9qWsv0IQe UrMVhRPb168ET08qLUT3bg8rUvfFXhcqPzhCEnzdHD5r40qe6BPjjNak2HCtvMUARvIc Dw70iOs7KPCdBQf5oigx/qJr9jybqCv+Cz+gY= MIME-Version: 1.0 Sender: pali.gabor@googlemail.com Received: by 10.223.110.75 with HTTP; Thu, 22 Apr 2010 01:24:35 -0700 (PDT) In-Reply-To: <20100421205226.GA20692@libertas.local.camdensoftware.com> References: <20100328163828.1f34e0e7@it.buh.tecnik93.com> <20100420021420.22e22136@it.buh.tecnik93.com> <20100421230746.71454b7d@it.buh.tecnik93.com> <20100421205226.GA20692@libertas.local.camdensoftware.com> Date: Thu, 22 Apr 2010 10:24:35 +0200 X-Google-Sender-Auth: 9ed02ade5659d098 Received: by 10.223.92.153 with SMTP id r25mr460044fam.76.1271924675070; Thu, 22 Apr 2010 01:24:35 -0700 (PDT) Message-ID: From: Gabor PALI To: Chip Camden Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, questions@freebsd.org, freebsd-ports@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 09:04:43 -0000 On Wed, Apr 21, 2010 at 10:52 PM, Chip Camden wrote: > lang/ghc is still marked IGNORE, unless I'm missing something. Yes, if your system is older than 6.0 on i386 and older then 7.0 on amd64, it is still ignored, since we do not support those platforms. Otherwise it must be okay. Cheers, g. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 09:07:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CD131065674 for ; Thu, 22 Apr 2010 09:07:50 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id EEF5A8FC1B for ; Thu, 22 Apr 2010 09:07:49 +0000 (UTC) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by gate1.intern.punkt.de with ESMTP id o3M97hEX006393; Thu, 22 Apr 2010 11:07:43 +0200 (CEST) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id o3M97hUh073377; Thu, 22 Apr 2010 11:07:43 +0200 (CEST) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.14.2/8.14.2/Submit) id o3M97hkY073376; Thu, 22 Apr 2010 11:07:43 +0200 (CEST) (envelope-from ry93) Date: Thu, 22 Apr 2010 11:07:43 +0200 From: "Patrick M. Hausen" To: Andrew Reilly Message-ID: <20100422090743.GH67328@hugo10.ka.punkt.de> References: <4BCFF881.9000809@minibofh.org> <20100422085954.GA10035@duncan.reilly.home> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100422085954.GA10035@duncan.reilly.home> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Jordi Espasa Clofent , freebsd-stable@freebsd.org Subject: Re: gmirror(8) rebuild speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 09:07:50 -0000 Hello, On Thu, Apr 22, 2010 at 06:59:54PM +1000, Andrew Reilly wrote: > To make it slower, I assume? When is that a good idea? When the rebuild is bringing your production system to a crawl and you are willing to face the tradeoff - hopefully because you have an additional backup for the worst case. Best regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 09:13:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBA90106566B for ; Thu, 22 Apr 2010 09:13:52 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp02.srv.cat (smtp02.srv.cat [212.36.74.55]) by mx1.freebsd.org (Postfix) with ESMTP id AA2FC8FC0A for ; Thu, 22 Apr 2010 09:13:52 +0000 (UTC) Received: from jespasac.cdmon.com (155.Red-88-2-251.staticIP.rima-tde.net [88.2.251.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jespasac@noverificar) by smtp02.srv.cat (Postfix) with ESMTP id 308BA465AD for ; Thu, 22 Apr 2010 11:13:51 +0200 (CEST) Message-ID: <4BD0134D.1060305@minibofh.org> Date: Thu, 22 Apr 2010 11:13:49 +0200 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 CC: freebsd-stable@freebsd.org References: <4BCFF881.9000809@minibofh.org> <20100422085954.GA10035@duncan.reilly.home> In-Reply-To: <20100422085954.GA10035@duncan.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: gmirror(8) rebuild speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 09:13:53 -0000 > To make it slower, I assume? When is that a good idea? It depends on what status your server are. For example: - if I've a fsck in background so the I/O is high, maybe I want to make it slower - If the box is completey unloaded maybe I want to make it quicker -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 09:25:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FF20106566C for ; Thu, 22 Apr 2010 09:25:09 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas05p.mx.bigpond.com (nschwmtas05p.mx.bigpond.com [61.9.189.149]) by mx1.freebsd.org (Postfix) with ESMTP id 09F338FC12 for ; Thu, 22 Apr 2010 09:25:08 +0000 (UTC) Received: from nschwotgx03p.mx.bigpond.com ([124.188.161.100]) by nschwmtas05p.mx.bigpond.com (InterMail vM.7.05.02.08 201-2174-114-118-20080528) with ESMTP id <20100422092506.RMEQ6690.nschwmtas05p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com>; Thu, 22 Apr 2010 09:25:06 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20100422092506.WESO2192.nschwotgx03p.mx.bigpond.com@duncan.reilly.home>; Thu, 22 Apr 2010 09:25:06 +0000 Date: Thu, 22 Apr 2010 19:25:05 +1000 From: Andrew Reilly To: "Patrick M. Hausen" Message-ID: <20100422192505.4540de45@duncan.reilly.home> In-Reply-To: <20100422090743.GH67328@hugo10.ka.punkt.de> References: <4BCFF881.9000809@minibofh.org> <20100422085954.GA10035@duncan.reilly.home> <20100422090743.GH67328@hugo10.ka.punkt.de> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx03p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Thu, 22 Apr 2010 09:25:06 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.4BD015F2.0110,ss=1,fgs=0 X-SIH-MSG-ID: rB02Edb6TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rHK+ZRsM6kxDxOJhqMNGMlaaziTY3Rs9mK Cc: Jordi Espasa Clofent , freebsd-stable@freebsd.org Subject: Re: gmirror(8) rebuild speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 09:25:09 -0000 On Thu, 22 Apr 2010 11:07:43 +0200 "Patrick M. Hausen" wrote: > When the rebuild is bringing your production system to > a crawl and you are willing to face the tradeoff - hopefully > because you have an additional backup for the worst case. Fair enough. I've noticed some slowdowns with re-builds, but I generally thought it best to get it over-with as quickly as possible. It's possible to turn off auto-synch, so that you can start the re-build at the beginning of a quiet-time, if there is one. I guess if the system is in demand 24/7 you'll need something else though. Cheers, -- Andrew From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 09:58:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D015106566C; Thu, 22 Apr 2010 09:58:30 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id 96A848FC16; Thu, 22 Apr 2010 09:58:29 +0000 (UTC) Received: by bwz28 with SMTP id 28so9368439bwz.14 for ; Thu, 22 Apr 2010 02:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2bcMUWg71eHftdDft7idQtrqrK+1jtjvpKVG+i//Fg8=; b=KLnDETLTFsCl30ZQyiwrgtF+bllig3Mt0Q9m5c+HyNNcKvURIib1KgFhjaKdb0WBTq /zDsUGziBB3GHivwNPbpaNURFP0y3jk+sXDArQ/YnfLYUc0Lgdpv+mMnoXamp+NxR4zS RbUDyeg2Y7coqQ9zlGm+VfzIpjnLj0q2zXrL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=C0hvIxlI3TANyMVJvzy6P8t8na2qATjgfJmh+TJqMncC/caYRijneXKyNsbxGXSknA TjjEeJl6fOO790lnqWVr51STMkbcN/6jYBBWmSmM1/FA3eKTNaBfCxIttzJu86HRkEFg H4Xy12yB2vFxZfWz/Knec2nebkJbVOOsq2iIc= MIME-Version: 1.0 Received: by 10.204.79.3 with HTTP; Thu, 22 Apr 2010 02:58:24 -0700 (PDT) In-Reply-To: References: <4BC82B80.3070108@omnilan.de> <20100416092803.GA17526@icarus.home.lan> <4BC82FF7.1030700@omnilan.de> <201004160822.09359.jhb@freebsd.org> <4BC8A76A.6000107@omnilan.de> <4BC8CB9E.8060802@omnilan.de> Date: Thu, 22 Apr 2010 13:58:24 +0400 Received: by 10.204.161.197 with SMTP id s5mr8158195bkx.90.1271930304668; Thu, 22 Apr 2010 02:58:24 -0700 (PDT) Message-ID: From: pluknet To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Brandon Gooch , Harald Schmalzbauer , freebsd-stable@freebsd.org, John Baldwin , Jeremy Chadwick Subject: Re: em JumboFrame improovement and PCIe addon-card regression [Was: Re: em regression, UDP LOR followed by ssh stall] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 09:58:30 -0000 On 17 April 2010 00:53, Jack Vogel wrote: > Why are you using ZERO_COPY_SOCKETS? =A0And is this LOR happening on STAB= LE or > CURRENT? > I got exactly this and another similar LORs with GENERIC on head. The second: login: lock order reversal: 1st 0xffffff0002539a18 em0:rx(0) (em0:rx(0)) @ /home/svn/freebsd/head/sys/dev/e1000/if_em.c:1452 2nd 0xffffffff80e3a280 in_multi_mtx (in_multi_mtx) @ /home/svn/freebsd/head/sys/netinet/igmp.c:823 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 igmp_input() at igmp_input+0x4ce ip_input() at ip_input+0xbc netisr_dispatch_src() at netisr_dispatch_src+0xb8 ether_demux() at ether_demux+0x17d ether_input() at ether_input+0x175 em_rxeof() at em_rxeof+0x165 em_handle_que() at em_handle_que+0x68 taskqueue_run() at taskqueue_run+0x91 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff80000bed30, rbp =3D 0 --- --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 10:35:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 905A71065678 for ; Thu, 22 Apr 2010 10:35:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 787428FC0A for ; Thu, 22 Apr 2010 10:35:05 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 8aMT1e0060vp7WLA1ab5um; Thu, 22 Apr 2010 10:35:05 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta05.emeryville.ca.mail.comcast.net with comcast id 8ab41e0033S48mS8Rab56G; Thu, 22 Apr 2010 10:35:05 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0769A9B419; Thu, 22 Apr 2010 03:17:12 -0700 (PDT) Date: Thu, 22 Apr 2010 03:17:12 -0700 From: Jeremy Chadwick To: Jordi Espasa Clofent Message-ID: <20100422101711.GA54482@icarus.home.lan> References: <4BCFF881.9000809@minibofh.org> <20100422085954.GA10035@duncan.reilly.home> <4BD0134D.1060305@minibofh.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD0134D.1060305@minibofh.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: gmirror(8) rebuild speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 10:35:05 -0000 On Thu, Apr 22, 2010 at 11:13:49AM +0200, Jordi Espasa Clofent wrote: > >To make it slower, I assume? When is that a good idea? > > It depends on what status your server are. > For example: > > - if I've a fsck in background so the I/O is high, maybe I want to > make it slower > - If the box is completey unloaded maybe I want to make it quicker RELENG_8 just had the GEOM scheduler code committed to it, which might be able to provide what the OP is wanting. Commits: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/sched/ README itself: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/sched/README?rev=1.1.2.2;content-type=text%2Fplain -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 11:07:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4F1D106566B for ; Thu, 22 Apr 2010 11:07:47 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 778CE8FC0A for ; Thu, 22 Apr 2010 11:07:45 +0000 (UTC) Received: (qmail 72965 invoked from network); 22 Apr 2010 11:07:44 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@96.224.221.101) by acm.poly.edu with AES256-SHA encrypted SMTP; 22 Apr 2010 11:07:44 -0000 Message-ID: <4BD02DF5.2030402@acm.poly.edu> Date: Thu, 22 Apr 2010 07:07:33 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.24 (X11/20100330) MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List References: <4BCFF881.9000809@minibofh.org> In-Reply-To: <4BCFF881.9000809@minibofh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: gmirror(8) rebuild speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 11:07:47 -0000 Jordi Espasa Clofent wrote: > Hi, > > I wonder if is possible to configure the gmirror rebuild speed. > Neither I've found any related info in the net nor the man pages. > This doesn't do exactly what you want, but might address your problem, anyway: try "renice +20 [gmirror PID]", where "[gmirror PID]" is the PID of the system process handling your mirror (ps auxw | grep g_mirror). I know that back when ZFS code ran in separate processes back in RELENG_7, renicing the zpa_zio* and spa_scrub_thread processes made the system a lot more responsive during a scrub. -Boris From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 14:44:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 968CF106564A for ; Thu, 22 Apr 2010 14:44:59 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 80FC58FC12 for ; Thu, 22 Apr 2010 14:44:59 +0000 (UTC) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta04.emeryville.ca.mail.comcast.net with comcast id 8bq81e0041wfjNsA4ekzK1; Thu, 22 Apr 2010 14:44:59 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta23.emeryville.ca.mail.comcast.net with comcast id 8ekz1e00A3S48mS8jekzUP; Thu, 22 Apr 2010 14:44:59 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5A5C79B423; Thu, 22 Apr 2010 07:35:42 -0700 (PDT) Date: Thu, 22 Apr 2010 07:35:42 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100422143542.GA2208@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: jkim@freebsd.org Subject: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 14:44:59 -0000 Looks like some form of regression in RELENG_8, between the dates of 2010/03/30 and 2010/04/22. My 2010/03/30 kernel (built from RELENG_8 source dated 2010/03/30 @ 10:30 PDT) doesn't have this problem. Symptom: shutdown -p no longer powers off either of my systems; instead, the box reboots (e.g. shutdown -p behaves like shutdown -r). Systems are a Supermicro X7SBL-LN2 board, and a Supermicro X7SBA board. These are server-class boards. I have not tried using the physical power switch yet. Looks like others have reported the same on a different board, though I haven't booted verbose to see if the behaviour is identical: http://lists.freebsd.org/pipermail/freebsd-acpi/2010-March/006345.html http://lists.freebsd.org/pipermail/freebsd-acpi/2010-April/006462.html I went digging through HEAD commits between the above dates and wasn't able to find much other than this, which appears to be the HEAD commit that was MFC'd to RELENG_8: http://freshbsd.org/2010/04/02/23/04/31 So I'm not sure where/what fixed this in HEAD, but it should probably be MFC'd sooner than the 4 week window. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 15:47:32 2010 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9889A106564A; Thu, 22 Apr 2010 15:47:32 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6BEE78FC16; Thu, 22 Apr 2010 15:47:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3MFlWoj051355; Thu, 22 Apr 2010 15:47:32 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3MFlWTI051354; Thu, 22 Apr 2010 15:47:32 GMT (envelope-from danger) Date: Thu, 22 Apr 2010 15:47:32 +0000 From: Daniel Gerzo To: questions@FreeBSD.org, current@FreeBSD.org, hackers@FreeBSD.org, stable@FreeBSD.org Message-ID: <20100422154732.GA51340@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: Subject: FreeBSD Status Report January-March, 2010 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 15:47:32 -0000 FreeBSD Quarterly Status Report Introduction This report covers FreeBSD related projects between January and March 2010. Being the first of the four reports planned for 2010 with 46 entries, it shows a good progress of the FreeBSD Project and proves that our committers are keeping up with the latest trends in the OS development. During this period, a new minor version of FreeBSD, 7.3-RELEASE, has been released, while the release process for 8.1-RELEASE is soon to begin and is planned to be released later this summer. Thanks to all the reporters for their excellent work! We hope you enjoy the reading. Please note that the deadline for submissions covering the period between April and June 2010 is July 15th, 2010. __________________________________________________________________ Google Summer of Code * Google Summer of Code 2010 Projects * Chromium web browser * Clang replacing GCC in the base system * EFI support for FreeBSD/i386 * mfsBSD * Modular Congestion Control * NAND Flash framework for embedded FreeBSD * Out of Tree Toolchain * PC-BSD PC-SysInstall Backend * The tbemd branch * webcamd FreeBSD Team Reports * FreeBSD Bugbusting Team * Release Engineering Team * The FreeBSD Foundation Network Infrastructure * (Virtual) Network Stack resource cleanup * 802.11n support * Atheros AR9285 support * Enhancing the FreeBSD TCP Implementation * Experimental NFS subsystem (NFSv4) * ipfw and dummynet enhancements * net80211 rate control framework * TCP/UDP connection groups Kernel * CAM-based ATA implementation * Dynamic Ticks in FreeBSD * geom_sched * IPv6 without legacy IP kernel * Multichannel playback in HDA sound driver (snd_hda) * Rewrite of FreeBSD read/write path using vnode page * SUJ: Journaled Softupdates * ZFS Documentation * The FreeBSD German Documentation Project * The FreeBSD Hungarian Documentation Project Userland Programs * FreeBSD port for libunwind * LDAP support in base system Architectures * FreeBSD/arm port for TI DaVinci * FreeBSD/ia64 * FreeBSD/mips on D-Link DIR-320 * FreeBSD/powerpc * FreeBSD/powerpc64 port * FreeBSD/sparc64 Ports * Portmaster * Ports Collection * QAT Miscellaneous * BSDCan 2010 -- The BSD Conference * meetBSD 2010 -- The BSD Conference __________________________________________________________________ (Virtual) Network Stack resource cleanup Contact: Bjoern A. Zeeb In February work was done to address resource leaks in the (virtual) network stack, especially on teardown. During that time also multiple general run-time problems and leaks were identified and fixed including leaked ipfw tables on module unload, routing entries leaked, in case of interfaces going away, as well as leaked link-layer entries in interaction with flowtable and timers. For virtual network stacks resources are are no longer allocated multiple times or freed upon teardown for eventhandlers, IP and upper level layers, like TCP syncache and host cache, flowtable, and especially radix/routing table memory. In addition epair(4) was enhanced and debugging was improved. This work was sponsored by ISPsystem. Open tasks: 1. Merge the remaining patches. 2. Work on a better teardown model and get to the point where we can free UMA zones without keeping pages for type stability and timers around. __________________________________________________________________ 802.11n support Contact: Rui Paulo 802.11n support in the Atheros driver is being worked on. Right now it can do AMPDU RX in software and we are working on TX AMPDU. The code lives in a private Perforce branch, but some bits of it are already committed to HEAD. This work is being sponsored by iXsystems, inc. __________________________________________________________________ Atheros AR9285 support Contact: Rui Paulo Atheros AR9285 support was added to FreeBSD HEAD and 8-STABLE. There are still some issues but in general it works fine. __________________________________________________________________ BSDCan 2010 -- The BSD Conference URL: http://www.BSDCan.org/2010/ URL: http://www.BSDCan.org/2010/schedule/ Contact: BSDCan Information BSDCan, a BSD conference held in Ottawa, Canada, has quickly established itself as the technical conference for people working on and with 4.4BSD based operating systems and related projects. The organizers have found a fantastic formula that appeals to a wide range of people from extreme novices to advanced developers. BSDCan 2010 will be held on 13-14 May 2010 at the University of Ottawa, and will be preceded by two days of Tutorials on 11-12 May 2010. There will be related events (of a social nature, for the most part) on the day before and after the conference. Please check the conference web site for more information. __________________________________________________________________ CAM-based ATA implementation Contact: Alexander Motin Work on CAM-based ATA implementation continues. Since last report handling of heavy errors and timeouts was improved, Hot-plug now works for both Host and Port Multiplier ports. Series of changes were made to CAM to fix some old issues and honor some new ATA demands. New drivers ahci(4) and siis(4) got some fixes and are quite stable now. "options ATA_CAM" kernel option shows good results in supporting other controllers using existing ata(4) drivers, so it is possible to start deprecating old ata(4) APIs now. Started work on new Marvell SATA driver for both PCI-X/PCIe cards and ARM System-on-Chip SATA controllers. It is expected to support NCQ, Port Multipliers with FIS-based switching and other new features. Most of the code is present in 8-STABLE. Open tasks: 1. Port ataraid(4) functionality to GEOM module. 2. Write SAS-specific transport and drivers for SAS HBAs (specs wanted). SAS controllers can support SATA devices and multipliers, so it should fit nicely into new infrastructure. __________________________________________________________________ Chromium web browser URL: http://chromium.jaggeri.com URL: http://wiki.FreeBSD.org/Chromium Contact: sprewell Chromium is a Webkit-based web browser that is mostly BSD licensed. It works very well on FreeBSD and even supports new features like HTML 5 video. I have started offering subscriptions to fund the porting effort to FreeBSD, funding which has already paid to fix Chromium on BSD-i386. I am using a new funding model where subscriptions pay for development that is kept closed for at most 1 year, after which all patches used in a build are released to subscribers under the same BSD license as Chromium. Also, parts of the closed patches are continually pushed upstream, the BSD i386 fix has already been committed upstream. The goal is to fund Chromium development on BSD while continually pushing patches back to the BSD-licensed Chromium project. I will spin off a Chromium port for ports soon, for those who do not mind using an older, stable build that does not have all the paid features in the subscriber builds. You can read about the issues that a subscription would pay for, such as replacing the ALSA audio backend with OSS, and find out more about subscribing. __________________________________________________________________ Clang replacing GCC in the base system URL: http://wiki.FreeBSD.org/BuildingFreeBSDWithClang URL: http://lists.FreeBSD.org/pipermail/FreeBSD-current/2010-April/016648.ht ml Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach Since the last status report we got to the state where we are able to build all of FreeBSD (the C and C++ bits) on i386/amd64 with clang. The only exception is the bootloader which does not fit within the given size constraint. This is where the current efforts are going on. The C++ part got a big boost now being able to compile all C++ code in FreeBSD and itself. We saw some movment on Mips and PowerPC. Mips got its driver definitions from Oleksander Tymoshenko and Nathan Whitehorn did the same for PowerPC and tested the kernel. Currently, the PPC kernel seems to boot but due to lack of va_arg implementation for PowerPC nothing is printed out. Nathan is working on that. Overall ClangBSD is selfhosting on i386/amd64 and some progress has been made on PowerPC/PPC. We also saw some contribution to the Sparc64 but this seems to have stalled. We need people to try out ClangBSD (see the wiki) and runtime test it. We also would appreciate help with other archs - namely ARM. Open tasks: 1. Runtime test ClangBSD on amd64/i386. 2. Help with ARM/Mips/Sparc64. 3. More testing of clang on 3rd party apps (ports). 4. Discussion on integrating LLVM/clang into FreeBSD. __________________________________________________________________ Dynamic Ticks in FreeBSD URL: http://github.com/oza/FreeBSD-8.0-dyntick URL: http://tsuyoshiozawa.blogspot.com/2010/03/started-to-implement-dynticks -in.html Contact: Tsuyoshi Ozawa I wrote experimental code (please see my project page) and threw patch ( http://gist.github.com/350230 ) to freebsd-hackers. A lot of FreeBSD hackers gave me precious advice, so I am going to reflect it as a next step. Open tasks: 1. Run hard/stat/prof-clocks irregularly (in progress). 2. Some timers which are added after the kernel's scheduling next timer interrupt may be ignored (BUG). 3. Make callout queue have the tick when the next timer event rise up. __________________________________________________________________ EFI support for FreeBSD/i386 Contact: Rui Paulo Work on supporting EFI booting on FreeBSD/i386 resumed. The boot loader can now read an ELF file from the EFI FAT partition. We are now working on trying to boot a kernel. __________________________________________________________________ Enhancing the FreeBSD TCP Implementation URL: http://caia.swin.edu.au/freebsd/etcp09/ URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://www.FreeBSDFoundation.org/projects.shtml URL: http://people.FreeBSD.org/~lstewart/patches/tcp_ffcaia2008/ Contact: Lawrence Stewart The ALQ(9) implementation and KPI has been rototilled and modified (one more patch needs to be committed) to support variable length messages. In addition, it can now be compiled and loaded as a kernel module. With the ALQ changes in head, SIFTR can finally be imported. Reassembly queue autotuning is in the project branch and needs to be extracted as a patch people can easily test. Open tasks: 1. Solicit external testing for and commit SIFTR. 2. Solicit external testing for and commit reassembly queue autotuning patch. __________________________________________________________________ Experimental NFS subsystem (NFSv4) Contact: Rick Macklem Although the bare bones of the NFS Version 4 support was released in FreeBSD 8.0, the integration has been progressing slowly and support should be functional for FreeBSD 8.1 for RFC3530 (NFS Version 4.0). Post FreeBSD 8.1, I believe the focus will be on code cleanup and, under a projects area of svn, some experimental work on aggressive whole file caching to client disk. Open tasks: 1. Handling of delegations on the server w.r.t. local processes running on the server. 2. Integration of recent changes to the regular NFS client, such as Dtrace support. __________________________________________________________________ FreeBSD Bugbusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://people.FreeBSD.org/~linimon/studies/prs/ URL: http://people.FreeBSD.org/~linimon/studies/prs/recommended_prs.html URL: http://people.FreeBSD.org/~linimon/recommended_subscribers.txt URL: http://people.FreeBSD.org/~linimon/studies/prs/easy_prs.html URL: http://people.FreeBSD.org/~linimon/studies/prs/prs_for_all_groups.html URL: http://wiki.FreeBSD.org/AssigningPRs Contact: Gavin Atkinson Contact: Mark Linimon Contact: Remko Lodder Contact: Volker Werth Bruce Cran (brucec) has graduated from GNATS-only access to having a src commit bit. He has been making commits to help us catch up with the PR backlog. Thanks! We continue to classify PRs as they arrive, adding 'tags' to the subject lines corresponding to the kernel subsystem involved, or man page references for userland PRs. These tags, in turn, produce lists of PRs sorted both by tag and by manpage. The most recent use of these tags is the creating of a new report, Summary Chart of PRs With Tags, which sorts tagged PRs into logical groups such as filesystem, network drivers, libraries, and so forth. The slice labels are clickable. The chart is updated once a day. You can consider it as a prototype for browsing "sub-categories" of kernel PRs. The "recommended list" has been split up into "non-trivial PRs which need committer evaluation" and the "easy list" of trivial PRs, to try to focus some attention on the latter. New reports were added for "PRs which are from FreeBSD vendors or OEMs", "PRs containing code for new device drivers", and "PRs referencing other BSDs". These will primarily be of interest to committers. Some other bitrot on the "experimental PR reports" pages has been fixed. It is now possible for interested parties to be emailed a weekly, customized, report along the lines of the above. If you are interested in setting one up, contact linimon@FreeBSD.org. The overall PR count has recently jumped to around 6400. This may be due to increasing uptake of FreeBSD 8. Our clearance rate of PRs, especially in kern and bin, seems to be improving. Mark Linimon polled various committers about their interest in specific PRs. As a result, the AssigningPRs page on the wiki and the src/MAINTAINERS file were updated based on feedback. As always, anybody interested in helping out with the PR queue is welcome to join us in #freebsd-bugbusters on EFnet. We are always looking for additional help, whether your interests lie in triaging incoming PRs, generating patches to resolve existing problems, or simply helping with the database housekeeping (identifying duplicate PRs, ones that have already been resolved, etc). This is a great way of getting more involved with FreeBSD! Open tasks: 1. We will be having a bugbusting session at BSDCan. If you are developer who will be attending the conference, please stop by. 2. try to find ways to get more committers helping us with closing PRs that the team has already analyzed. __________________________________________________________________ FreeBSD port for libunwind URL: http://www.nongnu.org/libunwind/ Contact: Konstantin Belousov The alpha version of libunwind library port for FreeBSD x86 and x86_64 is completed and imported into the official libunwind git repository. Libunwind is the library to perform dynamic unwinding of stacks, using dwarf call frame information. The library features remote unwinding using ptrace(2), very fast setjmp(3) implementation and more interesting features. __________________________________________________________________ FreeBSD/arm port for TI DaVinci URL: http://focus.ti.com/dsp/docs/dspplatformscontenttp.tsp?sectionId=2&fami lyId=1300&tabId=1854 URL: http://p4web.FreeBSD.org/@md=d&cd=//depot/user/jceel/davinci/ Contact: Jakub Klama DaVinci (TMS320DM644x) is an ARM9-based system-on-chip family from Texas Instruments with built-in DSP core and powerful multimedia/video features. This work is bringing support for FreeBSD on these systems - it works in multiuser mode, using root filesystem mounted either via NFS or from SD/MMC card. The code is available in P4 at //depot/user/jceel/davinci/. Current DaVinci support includes: * Booting from U-Boot bootloader * Serial console * Interrupt controller * Integrated timers * Power and sleep controller * 10/100 Ethernet controller * SD/MMC controller Open tasks: 1. Remaining built-in peripherals drivers (USB, ATA, NAND flash, I2C, DMA engine, sound, video input/output). 2. Framework for communicating with DSP core. __________________________________________________________________ FreeBSD/ia64 Contact: Mark Linimon The stability of the machines under package build has been improved by a number of recent commits. Some rework is underway to run with WITNESS. However, we are still limited in the number of simultaneous packages that can be built. Based on this, we have completed the first full ia64-8 package build. 17187 were built (as compared to 19885 on a recent i386-8.) Mark Linimon has gone through the results to denote which packages do not build. A few fixes have already been committed based on this. We currently have 3 available machines that are stable enough for package builds. Support for the SGI Altix 350 has made its start. Porting is done on 2 SGI Altix 350 machines connected with NUMAFlex, giving a total of 4 CPUs and 24GB of DDR. The kernel boots with code on the projects/altix branch but since ACPI does not enumerate PCI busses, no hardware devices are found. SMP has been disabled because waking up the APs result in a machine check. Open tasks: 1. Continue to try to understand why multiple simultaneous package builds bring the machines down. 2. Upgrade the firmware on the two machines at Yahoo! to see if that helps the problem. 3. Figure out why the fourth machine is not stable. 4. Configure a fifth machine that has been made available to us. 5. Figure out the problems with the latest gcc port. 6. We need documentation about the SGI SAL implementation to speed up porting to the SGI Altix 350. 7. The loader and kernel need to change to allow the kernel to be loaded at a runtime-determined physical address as well as add support for NUMA. __________________________________________________________________ FreeBSD/mips on D-Link DIR-320 URL: http://wiki.ddteam.net/wiki.cgi?page=DIR-320+FreeBSD Contact: Alexandr Rybalko FreeBSD/mips has been ported to D-Link DIR-320, wireless router based on BCM5354 SoC. Project aims to providing several working images tailored for different purposes (profiles). So far racoon based router-ipsec image is available. Open tasks: 1. bfeswitch configuration utility. 2. Add router profile. 3. Add wifi-router profile. 4. Add openvpn-router profile. __________________________________________________________________ FreeBSD/mips on Octeon URL: http://svn.FreeBSD.org/base/user/jmallett/octeon/ Contact: Juli Mallett Significant progress has been made in terms of stabilizing the uniprocessor Octeon port and adding support for MIPS ABIs other than o32 in the toolchain, rtld, libc and the kernel. Kernels built to the n32 ABI are currently supported with changes that will not be merged because they make invasive changes throughout the system with regard to db_expr_t and register_t, which are larger than a pointer in the n32 ABI. Once support for n64 kernels is completed (including the ability to run n32 worlds) and the n32 hacks are removed, the branch will be suitable for merging. Many nearby cleanups have occurred, particularly in the area of TLB and pmap code. Open tasks: 1. An import of select pieces of the Cavium simple executive as vendor code is planned to make it possible to remove locally-maintained copies of Cavium headers and shim functions, many of which are vastly outdated. 2. The Linux opencrypto port contains an opencrypto driver for the cryptographic coprocessor which look relatively easy to port. 3. Support for SMP is a high-priority item that will be addressed after the 64-bit changes are stabilized. 4. PCI and USB bus and device support is planned to follow the import of the simple executive functions and headers. 5. The rgmx ethernet driver currently copies packets in and out of mbufs rather than putting pointers to mbuf storage into hardware, which results in bad network performance. __________________________________________________________________ FreeBSD/powerpc Contact: Nathan Whitehorn An Apple XServe G5 has been donated by Peter Grehan for package building. Based on the last two months' worth of testing, a large number of commits have been made to increase stability. We have completed the first full powerpc-8 package build. Only 10918 were built (as compared to 19885 on a recent i386-8), primarily due to a few high-impact packages failing (such as lang/python25). Mark Linimon has gone through the results to denote which packages do not build. A few fixes have already been committed based on this; we have patches that are being tested in the next run. Mark Linimon is working on getting us more XServes. Open tasks: 1. Start the hard work of fixing individual packages. __________________________________________________________________ FreeBSD/powerpc64 port Contact: Nathan Whitehorn A full 64-bit PowerPC port of FreeBSD is now complete, and should shortly be merged to HEAD, likely first appearing in FreeBSD 9.0. This port supports SLB-based 64-bit server CPUs, such as the IBM POWER4-7, PowerPC 970 (G5), and Cell Broadband Engine. Current machine support is limited to Apple single and dual processor G5 systems, with future support planned for IBM Power Systems servers and the Sony PlayStation 3. __________________________________________________________________ FreeBSD/sparc64 Contact: Marius Strobl * Yet another bug causing unaligned accesses in NFS server operation has been found and fixed in FreeBSD 7 and 8. Unlike as announced in the last Status Report, no Erratum Notices regarding these problems have been issued as it quickly became obvious that dealing with so many of them is impractical, especially since the fixes unveiled secondary bugs. * Alexander Motin has fixed several bugs in netgraph(4) nodes in 9.0-CURRENT which also caused unaligned accesses, so these should work now on sparc64. * Peter Jeremy has contributed several fixes for the sparc64 FPU emulation code, which now passes a test suite built around TestFloat. These fixes were incorporated into FreeBSD 6, 7 and 8 but unfortunately did not quite make it into 7.3-RELEASE but will be present in 8.1-RELEASE and 7.4-RELEASE. * Support for UltraSPARC-IV and -IV+ CPUs has been added and will be present in 8.1-RELEASE and 7.4-RELEASE. Thus Sun Fire V890 is now supported and stable, though due to the lack of properly working test hardware, not with configurations consisting of a mix of US-IV and -IV+ CPUs. However, performance is not yet where it should be, i.e. a buildworld on a 4x1.5GHz US-IV+ Sun Fire V890 takes nearly 3 hours while on a Sun Fire V440 with (theoretically) less powerful 4x1.5GHz US-IIIi CPUs it takes just over 1 hour. So far it is unclear what is causing this, it might have to with what appears to be a silicon bug of US-IV+ CPUs encountered and worked around while adding support for these. * Work on getting Sun Fire V1280 supported has been continued. A third firmware bug has been worked around and a driver for the BootBus controller, which provides console and time-of-day services in these machines, has been written. It is now possible to netboot Sun Fire V1280 into multi-user mode. Unfortunately, they do not run stable as processes may hang when transitioning to another CPU, likely due to what the OpenSolaris code refers to as Cheetah+ erratum 25, but which unfortunately is not part of the publicly available US-III+/++ errata document. Efforts on understanding this problem are still ongoing. * Mark Linimon is trying to find volunteers interested in helping to fix packages on sparc64. __________________________________________________________________ geom_sched URL: http://info.iet.unipi.it/~luigi/geom_sched/ Contact: Luigi Rizzo Contact: Fabio Checconi geom_sched is a GEOM module that supports pluggable schedulers for disk I/O requests. The main algorithm supported at the moment is an anticipatory Round Robin scheduler, which is especially effective in presence of workloads with highly random disk accesses. Other schedulers are available on the geom_sched page. Developed in early 2009 and refined as a GSOC2009 project, geom_sched has been recently introduced in HEAD and is going to be soon merged to stable/8. A version for stable/7 also exists, with some restrictions. To use the module, say on disk ad4, all you need to do is: kldload geom_sched geom sched insert ad4 A number of sysctl variables under kern.geom.sched allow you to tune the parameters of the algorithm, or bypass the scheduler entirely so you can tell the difference of behaviour with and without the scheduler. __________________________________________________________________ Google Summer of Code 2010 URL: http://socghop.appspot.com/org/home/google/gsoc2010/freebsd URL: http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/t imeline Contact: Brooks Davis Contact: Robert Watson We are once again participating in the Google Summer of Code. This is our 6th year of participation and we hope to once again see great results from our students. Currently applications have all been submitted and we are in the process of reviewing them. Accepted students will be announced April 26th and coding officially begins May 24th. __________________________________________________________________ ipfw and dummynet enhancements URL: http://info.iet.unipi.it/~luigi/dummynet/ URL: http://www.youtube.com/watch?v=r8vBmybeKlE URL: http://info.iet.unipi.it/~luigi/qfq/ Contact: Luigi Rizzo We have recently completed a massive revision of ipfw and dummynet, and the result has been committed to HEAD and stable/8. The main features introduced with this work are: * ipfw now has much faster skipto instructions, including table-based ones. The complexity for rule lookups is now O(1) or O(log N) as opposed to the O(N) that we had before. People using "skipto tablearg" or "pipe tablearg" with large numbers of rules or pipes should see a significant performance improvement; * Expensive operations in response to userland reconfigurations now do not interfere with kernel filtering for more than the time required to swap a pointer; * You can now use ports and the "tos" field as lookup argument for tables. This might allow some simplifications in rulesets which in turn result in faster execution time; * ipfw can now send packets matching rules with a 'log' attribute to the "ipfw0" pseudo interface, where you can run tcpdump to implement additional filtering, logging etc.; * dummynet now supports many different scheduler types, to adapt to different needs people may have in terms of performance and service guarantees. Existing schedulers now include FIFO, WF2Q+, Deficit Round Robin, Priority, and QFQ. More schedulers can be implemented as loadable kernel modules.; * The kernel side has a backward-compatible interface so you can use a RELENG_7 or RELENG_8 version of /sbin/ipfw to configure the firewall and dummynet. Open tasks: 1. There is ongoing work on optimizing the deletion of idle entries in dummynet. This should be completed shortly. 2. A longer term goal is to parallelize operation in presence of ipfw dynamic rules, which currently require exclusive lock on a hash table containing dynamic rules. __________________________________________________________________ IPv6 without legacy IP kernel URL: http://p4web.FreeBSD.org/@md=d&cd=//&c=MNx@//depot/user/bz/noinet/src/s ys/?ac=83 Contact: Bjoern A. Zeeb During 2009 work was done that allowed us to build a FreeBSD kernel without INET and without INET6 (again). This work was the foundation for a prototype to get a kernel to compile and boot with only INET6 but no INET compiled in earlier this year. The current focus is to identify general architectural problems and dependencies we do have between these two address families as well as with the upper layer protocols. This will at some point allow us to discuss the issues and seek solutions, preparing for a future where we can remove either INET or INET6 from the system. Once we will have a stable, in-tree way to compile out either address family, optimizations wrt. size, as well as user space will need to be worked on. In addition to this, the work is believed to help should we further head in the direction of network stack modularization. __________________________________________________________________ LDAP support in base system Contact: Xin ZHAO Contact: Xin LI FreeBSD is currently lacking support of LDAP based authentication and user identity. We have integrated a stripped down OpenLDAP library (renamed to avoid conflict with ports OpenLDAP libraries), as well as some changes to OpenSSH as well as plugins for PAM, NSS and can support. We have used several existing works and updated them to use new OpenLDAP API, fixed several bugs and integrated them together. All these works are under BSD or similar license and our new work would be under 2-clause BSD license. Currently, we support storing user identity, password and SSH public keys in LDAP tree. Open tasks: 1. Further code review. 2. Make the changes less intrusive. 3. Fix issues found in production deployment. __________________________________________________________________ meetBSD 2010 -- The BSD Conference URL: http://www.meetbsd.org Contact: meetBSD Information meetBSD is an annual event gathering users and developers of the BSD operating systems family, mostly FreeBSD, NetBSD and OpenBSD. Afer the special California edition, meetBSD Wintercamp in Livigno, this year we are back to Krakow, Poland. meetBSD 2010 will be held on 2-3 July at Jagiellonian University. See the conference main web site for more details. __________________________________________________________________ mfsBSD URL: http://mfsbsd.vx.sk Contact: Martin Matuska mfsBSD is a set of scripts that generate a bootable image (e.g. an ISO file) that creates a working minimal installation of FreeBSD that is completely loaded into memory (mfs). The project has now reached a stable and well tested state. Images can be created from 8.0-RELEASE or 7.3-RELEASE ISO image files or from a custom makeworld. A new feature is a script called "zfsinstall" that automates a ZFS-only install of FreeBSD from a mfsbsd ISO (script works with 8-STABLE and 9-CURRENT, sample ISO images can be downloaded from the project web site). Open tasks: 1. Bundle distribution installation files (target: 8.1-RELEASE). 2. Make zfsinstall 7.3 compatible (mostly gpart syntax). 3. Enable zfsinstall combination with sysinstall (zfsinstall prepares drives, sysinstall installs distribution). 4. Integrate toolset into FreeBSD source (tools?). __________________________________________________________________ Modular Congestion Control URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://svn.FreeBSD.org/viewvc/base/projects/tcp_cc_head/ Contact: Lawrence Stewart I have just completed the last disruptive change to the KPI, which laid the groundwork to allow different congestion aware transports to share congestion control algorithms. The import into the head branch is a big job and my time is limited, so progress will be slow and I will not have it done and ready to MFC by 8.1 as I had hoped. I will aim to have it in 8.2 though. Open tasks: 1. Solicit external testing. 2. Commit to head. __________________________________________________________________ Multichannel playback in HDA sound driver (snd_hda) Contact: Alexander Motin snd_hda(4) audio driver got real multichannel playback support. It now supports 4.0 (quadro), 5.1 and 7.1 analog speaker setups. Digital multichannel AC3/DTS passthrough was already implemented earlier. Digital multichannel LPCM output via HDMI could also be possible now, but is not tested. To use multichannel playback you should have fresh 8-STABLE kernel, instruct sound(4) vchans subsystem (if you are using it) about your speaker setup using dev.pcm.X.play.vchanformat sysctls and use your audio/video player application to play multichannel audio content without down-mixing it to stereo. Open tasks: 1. HDMI/DisplayPort often require some audio support from X11 video drivers. This area still should be investigated and tested, especially relayed to multichannel LPCM playback. __________________________________________________________________ NAND Flash framework for embedded FreeBSD URL: http://wiki.FreeBSD.org/NAND#head-9a32aaa85046b2f9f9219e36ba34947ca47a4 153 URL: http://p4db.FreeBSD.org/changeList.cgi?FSPC=//depot/projects/nand2/... Contact: Grzegorz Bernacki Contact: Rafal Jaworowski The purpose of this project is to provide embedded FreeBSD with a generic and flexible scheme to support NAND Flash devices. The framework provides a set of KOBJ interfaces inside the kernel, which allow for uniform and flexible management of the NAND devices: * NAND Flash Controller (NFC) layer, into which back-end drivers for individual controllers plug in (implementing low-level routines specific to a given NAND controller) * Generic (common) NAND layer which provides means to perform operations on the flash devices in an abstract way (read, program, erase, get status etc.) * NAND character device, which exports chip device as a standard character device and allows to read/write directly to a device, as well as perform other specific operations by using ioctl. * GEOM NAND class for basic access through GEOM. Part of the infrastructure is a full system simulator of ONFI-compliant devices (NANDsim), with a userland control application. This allows for exercising of the framework on platforms without real NAND chips. Current state highlights: * The framework is considered functionally complete (including NANDsim). * Framework compliant back-end drivers are available for the following NAND Flash controller (NFC) chips: * Freescale MPC8572 (PowerPC) * Marvell MV-78100 (ARM) * Samsung S3C24X0 (ARM) Open tasks: 1. Extend interface with features / options suggested by early adopters of the code. 2. Complete, clean up, merge with HEAD. __________________________________________________________________ net80211 rate control framework URL: http://people.FreeBSD.org/~rpaulo/ratectl.diff Contact: Rui Paulo The net80211 (wireless) stack will support a modular rate control framework soon. The idea is to reduce some code in the drivers and add more rate control algorithms in the tree. All drivers that do rate control in software will automatically benefit from this project. On this stage, we are working on changing all the necessary drivers to cope with the new framework and making sure it all works as expected. Later this year we will bring the necessary changes to change the rate control algorithm with ifconfig(1). If you are doing rate control algorithm or research on rate control algorithms for wireless networks, FreeBSD is now an ideal candidate for testing your project! __________________________________________________________________ Out of Tree Toolchain Contact: Warner Losh Work is underway to allow the FreeBSD build system to use out of tree compilers and binary utililies (loaders, linkers, etc), especially in a cross compilation environment. While it is possible to swap out the compiler with a compatible compiler relatively easily, swapping out the toolchain is more involved. In addition, when using an external compiler to build the system, certain parts of buildworld can be omitted. Open tasks: 1. Create ports for latest binutils. This work is nearly complete, and is waiting for integration of two branches that are collapsing soon (the 'tbemd' branch from Warner and the mips collapse from Juli Mallet). 2. Create ports for gcc. This work has been started. Native builds are straight forward, but cross builds have a buildworld dependency at the moment. These dependencies are being worked out, as well as some gcc library dependencies. 3. Documentation needs to be written for how to use all of this. __________________________________________________________________ PC-BSD PC-SysInstall Backend URL: http://www.pcbsd.org URL: http://trac.pcbsd.org/browser/pcbsd/trunk/pc-sysinstall Contact: Kris Moore We are currently doing a lot of code cleanup in the new System Installer backend for PC-BSD, pc-sysinstall, which can be used to install regular FreeBSD as well. Some new features have already been implemented, such as: * Improved ZFS support, raidz, mirroring, multiple mount-points per-pool, etc. * Support for GPT/EFI on "Full" installations, allowing us to go beyond the 2TB barrier. * MBR Slice/Partition manager. * geli passphrase support. Open tasks: 1. We are mostly finished migrating to only using gpart instead of fdisk, which gives us some new functionality for dealing with GPT/EFI partitioning schemes. __________________________________________________________________ Portmaster URL: http://dougbarton.us/portmaster-proposal.html Contact: Doug Barton Portmaster version 2.22 is now in the ports tree and has full support for the following new features: * Using the INDEX file to show that an installed port needs updating. * Support for installation of packages in 'try packages first,' --packages-only, --packages-if-newer, and --packages-build modes. * A new --delete-build-only option to delete ports/packages that are not needed at run time. * Updating of the terminal title bar to show what is being worked on, and how much more is left to do. * Support for custom definitions of the packages repository and INDEX files. * The ability to operate without any local ports tree at all with the --index-only and --packages-only options. * A new dialog to confirm the list of ports to be installed. I am very excited about these new features, and owe a debt of gratitude to the companies and especially the individuals who stepped forward to support this work. I literally could not have done it without them. Open tasks: 1. There are still some interesting and oft-requested features listed on the proposal web site that I would really like to implement, including (but not limited to) downloading of all packages before beginning the installation, and writing out a script that can be re-run either on that machine, or on a set of identical machines. __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://tinderbox.marcuscom.com/ Contact: Thomas Abthorpe Contact: Port Management Team Most of quarter one was spent dealing with the 7.3-RELEASE process. With apparent success enforcing Feature Safe ports commits during the 8.0-RELEASE, it was continued for the recent src/ freeze. The ports count now exceeds 21,500 ports, and counting. The open PR count currently is over 1000. With the release of FreeBSD 7.3, it is hoped this count will drop drastically. Since the last report, we added four new committers, and had an old committer rejoin us. With the donation of an Apple Xserve, powerpc builds have resumed. Renewed interest in ia64 has brought about new ports builds. A new sparc64 machine hosted by skreuser will help us with this build. The Ports Management team have been running -exp runs on an ongoing basis, verifying how src code updates may affect the ports tree, as well as providing QA runs for major ports updates. Of note -exp runs were done for; gabor's BSD licensed bc/dc in src/, mva's OpenAL and SDL upgrades; brooks' removal of NGROUPS; ed's removal of libcompat and regexp.h; dinoex's jpeg update; a test run for m4 update; jilles' update for sh(1); johans' update for bison; and roam's curl update. Open tasks: 1. Looking for help fixing ports broken on CURRENT. 2. Looking for help with Tier-2 architectures. 3. Most ports PRs are assigned, we now need to focus on testing, committing and closing. 4. Major commits expected soon include the latest Xorg, KDE4, and Gnome updates. __________________________________________________________________ QAT Contact: Ion-Mihai Tetcu Contact: Josh Paetzel QAT has been running on a single server for about two years now and has proven very effective at catching problems with ports commits. Many of the problems it cannot catch are architecture or branch related. By moving QAT to a VMware box capable of running arbitrary versions of FreeBSD on both amd64 and i386 this limitation will be removed. Open tasks: 1. Bring VMware server online and provision VMs. 2. Refactor QAT code to handle concurrent builds. 3. Migrate the existing QAT to the new setup. __________________________________________________________________ Release Engineering Team URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team announced FreeBSD-7.3 on March 23rd, 2010. The schedule has been set for FreeBSD-8.1 with the release date planned for mid July 2010. __________________________________________________________________ Rewrite of FreeBSD read/write path using vnode page URL: http://svn.freebsd.org/viewvc/base/user/kib/vm6/ URL: http://wiki.FreeBSD.org/VM6 Contact: Konstantin Belousov Contact: Peter Holm Based on the idea of Jeff Roberton, we reimplemented the path for read(2)/write(2) syscalls using page cache (in wide sense) to eliminate the issues with recursive vnode and buffer lock acquisitions. The usual reads and writes are no longer calls into VOP_READ/VOP_WRITE; the operation is done by copying user buffers to or from the pages of the vnode. This fixes known deadlocks when reads or writes are done over file-mmaped buffers. The patch changes the performance characteristics of I/O, and we observed both better and worse behaviour. If filesystem implements VOP_GETPAGES and VOP_PUTPAGES without referencing buffer cache, buffers are completely eliminated from the i/o path (not true for UFS or NFS). Open tasks: 1. We need wider testing and reviews. __________________________________________________________________ SUJ: Journaled Softupdates URL: http://jeffr_tech.livejournal.com/ Contact: Jeff Roberson The soft-updates journaling project is nearing completion and will be available in head by the time this status report is released. Backports to other releases are maintained in SVN. SUJ is fully backwards compatible with non-journaled softupdates. Existing systems will not be affected. Journaling may be enabled and disabled by tunefs on unmounted filesystems. Journaling provides near-instant filesystem recovery after crash at the expense of some runtime performance and extra disk I/O. __________________________________________________________________ TCP/UDP connection groups Contact: Robert Watson Contact: FreeBSD network mailing list This on-going project is to reduce tcbinfo/udbinfo lock and cache line contention; this global lock protects access to connection lists, and while it is a read-write lock, it is acquired for every in-bound packet (briefly) to look up the connection. This project adds a new connection group table, which assigns connections to groups, each of which has CPU affinity and aligns with RSS-selected queues in high-end 1gbps and most 10gbps implementations. The following tasks have been completed: * Teach libkvm to handle dynamic per-cpu storage (DPCPU) to improve crashdump analysis of per-CPU data. * Teach netstat to monitor netisr DPCPU queues for live kernels and crashdumps. * Create a new inpcbgroup abstraction, used for UDP and TCP. * Distribute UDP and TCP connections (inpcbs) over groups based on 4-tuple bindings. * Replicate membership across all groups for wildcard socket bindings. * Write new TCP/UDP connection and binding regression tests. The following tasks remain: * Migrate from naive work assignment algorithm to RSS assignment. * Modify device driver KPI to allow consistent initialization and configuration between stack and hardware. * Complete migration to dynamic, per-CPU network statistics in TCP, UDP, and IP. * Add socket options to query effective CPU affinity of connections from userspace. * On supporting hardware, allow affinity for a specific connection to be explicitly migrated using a socket option. * Detailed performance evaluation and optimization. This work is being performed in the FreeBSD Perforce repository, and is sponsored by Juniper Networks. Connection groups and related features are slated for inclusion in FreeBSD 9.0 (with possible backports to 8-STABLE of some features). __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org Contact: Deb Goodkin We were proud to be a sponsor for AsiaBSDCon in March. We also committed to sponsoring BSDCan 2010 and NYCBSDCon 2010. We provided travel grants for AsiaBSDCon. We funded a project by Murray Stokely to provide Closed Captioning of FreeBSD Technical Videos in the BSD Conferences YouTube Channel. We were very pleased that the foundation funded HAST project completed. We solicited project proposals and were very pleased with the number of proposals we received. With our project spending budget increase, we will be able to fund more projects this year. We grew our board of directors by adding Erwin Lansing. This will expand our representation in Europe. Erwin brings ports knowledge and expertise to the board. We continued our work on infrastructure projects to beef up hardware for package-building, network-testing, etc. Follow us on Twitter now! We are fund-raising for 2010 now! Find out more at http://www.FreeBSDFoundation.org/donate/. __________________________________________________________________ The FreeBSD German Documentation Project URL: http://doc.bsdgroup.de Contact: Johann Kois Contact: Benedict Reuschling Our last status report listed a number of documents that needed help. Thanks to the external contributions of Frank Boerner we were able to update a substantial amount of documents. This has resulted in a great reduction of our backlog. Subsequently, Benedict has agreed to take Frank under mentorship for the German doc project. We are looking forward to his future contributions and thank him for his past efforts. Johann was busy keeping the German website in sync with updates to FreeBSD.org. However, there are still parts of the website that remain untranslated. We are looking for more support in maintaining the German website. FreeBSD users with German language skills are always welcome to join our efforts in translating the documentation and/or fixing bugs. Open tasks: 1. Translate more parts of the documentation and the German website. 2. Keep the current documentation up to date. 3. Report bugs to de-bsd-translators@de.FreeBSD.org. __________________________________________________________________ The FreeBSD Hungarian Documentation Project URL: http://www.FreeBSD.org/hu/ URL: http://www.FreeBSD.org/doc/hu/ URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.FreeBSD.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: Gábor Kövesdán Contact: Gábor Páli We restlessly keep the existing documentation and web page translations up to date. However, this will not last forever, and help is always welcome, so if you feel yourself Hungarian with some interests in translation, please contact our Documentation Project via the email addresses noted above. Open tasks: 1. Translate release notes. 2. Translate articles. 3. Translate web pages. 4. Read translations, send feedback. __________________________________________________________________ The tbemd branch Contact: Warner Losh 'tbemd' stands for Target Big Endian Must Die. The current build systems requires that one define TARGET_BIG_ENDIAN for either big endian MIPS or big endian ARM processors. There are many problems with this approach. The resulting system will not create the proper binaries without TARGET_BIG_ENDIAN defined. There is no easy way to know what the endian is of the system you are running. There are many issues with ports, since they do not use bsd make, so do not pick up the extra flags that are added if TARGET_BIG_ENDIAN is defined. The tbemd branch seeks to fix this. We will move from MACHINE_ARCH=mips for all mips platforms to MACHINE_ARCH=mipsel, mipseb, mips64eb and mips64el to match NetBSD's conventions. These represent 32-bit mips little endian, 32-bit mips big endian, 64-bit mips big endian and 64-bit mips little endian respectively. ARM will move to arm (little endian) and armeb (big endian), again following the standards set elsewhere. To facilitate a number of different MACHINE_ARCHs all built from the same source, a new MACHINE_CPUARCH is introduced and represents the sources needed to build CPU support for a given MACHINE_ARCH. In addition, MACHINE_ARCH is overused in the build system today. Many of its uses are gratuitous and can be simplified. Many of its uses do not scale well and need to be refactored into a system that will scale well. A per MACHINE/MACHINE_ARCH/MACHINE_CPUARCH selection mechanism for makefile snippets will be introduced to move much of the current if spaghetti into more controlled lists. The branch can build everything we currently support with the new names. Open tasks: 1. Finish migrating to bsd.arch.inc.mk. 2. Reduce diffs between the branch and the mainline before the collapse. 3. Documentation needs to be written for how to use all of this. __________________________________________________________________ webcamd URL: http://www.selasky.org/hans_petter/video4bsd/ Contact: Hans Petter Selasky Webcamd is a userland daemon that enables use of hundreds of different USB based Linux device drivers under the FreeBSD-8/9 operating system. Current focus has been on USB webcam and USB DVB-T/S/C devices. It is also possible to use the webcamd framework to make other Linux kernel USB devices work under the FreeBSD-8/9 operating system, without violating the GPL license. The daemon currently depends on libc, pthreads, libusb and libcuse4bsd. Cuse4BSD is a new character device from userland implementation that fully supports open, read, write, ioctl, mmap and close file operations. If you like this project or want me to spend more time on it, you can support it by transferring money to hselasky@c2i.net via paypal. Open tasks: 1. Testing and bugfixes. 2. Add support for more device drivers. __________________________________________________________________ ZFS URL: http://perforce.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/ zfs URL: http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome Contact: Pawel Jakub Dawidek Contact: Martin Matuska Contact: Xin LI The ZFS file system has been updated to version 14 on both -HEAD and 8-STABLE. Ongoing work is undergoing to bring bug fixes and performance improvements from upstream svn -HEAD to approximately ZFS v15 in the near future, and a full upgrade of ZFS to version 24 including the de-duplication functionality, etc. The de-duplication functionality is currently partly supported, which is demonstrated below: # uname -sr FreeBSD 9.0-CURRENT # zpool create tank ad{4,6,8,10} # zpool get version tank NAME PROPERTY VALUE SOURCE tank version 24 default # zfs set dedup=on tank # dd if=/dev/random of=/tank/rand0 bs=1m count=1024 # zpool get allocated,dedupratio tank NAME PROPERTY VALUE SOURCE tank allocated 1.00G - tank dedupratio 1.00x - # dd if=/tank/rand0 of=/tank/rand1 bs=1m # dd if=/tank/rand0 of=/tank/rand2 bs=1m # dd if=/tank/rand0 of=/tank/rand3 bs=1m # zpool get allocated,dedupratio tank NAME PROPERTY VALUE SOURCE tank allocated 1.01G - tank dedupratio 4.00x - Open tasks: 1. Bring ZFS v15 changes to svn -HEAD and MFC. 2. Further polish the code in perforce and test for functionality, etc. __________________________________________________________________ (c) 2010 The FreeBSD Project. All rights reserved. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 18:44:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22FB61065675; Thu, 22 Apr 2010 18:44:00 +0000 (UTC) (envelope-from dnaeon@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 319B78FC19; Thu, 22 Apr 2010 18:43:58 +0000 (UTC) Received: by wye20 with SMTP id 20so2057491wye.13 for ; Thu, 22 Apr 2010 11:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=U3GI3nd9oezAIzWVnwhAvY2mfjiZ5C+8+naD1NhFLtw=; b=uhFOLRi6647EDHveCz4+AjIwisS+5Wi+4V0gN5Ve5W9K9fof4MFd6uqsatvT+UxaXG f87I/O7BvsOIjYHJRUJCcbE4GqJyywbwSlXxV0EC86c4uiZVXmzgIpsN4/SHbaDyLWwS fZlPvUvElRIp0flns4FoseKadOSVfr86t9iu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PJRjM9cMpHKgGOlf0wys1GiWuhldzvJMfKmfrqL46qow+eCj9m6uuR3ypADu5uZHwS RJ64EhXS/qR8CJ5YN6xpCcc3fitGnOngYB6jRPFYF+gmgn5bY9D1HsxKpFR6oLtM+LDm kogfrV40B7RryiWRQztmMg40++j35OHCTt7Bw= MIME-Version: 1.0 Received: by 10.216.13.7 with HTTP; Thu, 22 Apr 2010 11:43:57 -0700 (PDT) In-Reply-To: References: <4B28F841.1070900@skylinetele.com> Date: Thu, 22 Apr 2010 21:43:57 +0300 Received: by 10.216.91.6 with SMTP id g6mr690090wef.37.1271961837824; Thu, 22 Apr 2010 11:43:57 -0700 (PDT) Message-ID: From: Marin Atanasov To: Qing Li Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, "Li, Qing" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, "Prokofiev S.P." Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 18:44:00 -0000 Hello, Thanks a lot for the patch, Qing! It works fine. However I've noticed one thing, after I start mpd5 and connect to my home network: kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize() Not very sure if this is something to worry about or not? Regards, Marin On Tue, Apr 20, 2010 at 11:03 AM, Qing Li wrote: > > > > I was using csup to track RELEN_8_0 branch. Currently I'm syncing to > > RELENG_8. > > > > If I understood you right, after getting the sources for RELENG_8, I need > to > > apply the patch and then rebuild world? > > > > You only need to rebuild the kernel. > > -- Qing > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 19:33:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D84E106564A for ; Thu, 22 Apr 2010 19:33:45 +0000 (UTC) (envelope-from mloftis@wgops.com) Received: from juggler.wgops.com (juggler.wgops.com [204.11.247.41]) by mx1.freebsd.org (Postfix) with ESMTP id 597AB8FC1B for ; Thu, 22 Apr 2010 19:33:45 +0000 (UTC) Received: by juggler.wgops.com (Postfix, from userid 65534) id 8A933A8119; Thu, 22 Apr 2010 13:33:44 -0600 (MDT) X-Spam-ASN: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on juggler.wgops.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 Received: from [192.168.1.100] (host-72-174-42-38.msl-mt.client.bresnan.net [72.174.42.38]) by juggler.wgops.com (Postfix) with ESMTPSA id 51373A8092 for ; Thu, 22 Apr 2010 13:33:42 -0600 (MDT) Date: Thu, 22 Apr 2010 13:33:48 -0600 From: Michael Loftis To: freebsd-stable@freebsd.org Message-ID: <1935DF0278C55632AE1FC907@[192.168.1.100]> In-Reply-To: <20100422085954.GA10035@duncan.reilly.home> References: <4BCFF881.9000809@minibofh.org> <20100422085954.GA10035@duncan.reilly.home> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: clamav-milter 0.95.3 at juggler X-Virus-Status: Clean Subject: Re: gmirror(8) rebuild speed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:33:45 -0000 --On Thursday, April 22, 2010 6:59 PM +1000 Andrew Reilly wrote: > On Thu, Apr 22, 2010 at 09:19:29AM +0200, Jordi Espasa Clofent wrote: >> I wonder if is possible to configure the gmirror rebuild speed. >> Neither I've found any related info in the net nor the man pages. > > To make it slower, I assume? When is that a good idea? The last thing you need is for a RAID rebuild to make the machine unusable. It's probably going to impact perfomance somewhat. Being able to decide if it's more important to rebuild, or serve data, is a better way to go. From owner-freebsd-stable@FreeBSD.ORG Thu Apr 22 22:12:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B356106564A; Thu, 22 Apr 2010 22:12:16 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6A9968FC13; Thu, 22 Apr 2010 22:12:15 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA16362; Fri, 23 Apr 2010 01:12:10 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1O54d0-0008cs-JL; Fri, 23 Apr 2010 01:12:10 +0300 Message-ID: <4BD0C9BA.2000405@icyb.net.ua> Date: Fri, 23 Apr 2010 01:12:10 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Jeremy Chadwick References: <20100422143542.GA2208@icarus.home.lan> In-Reply-To: <20100422143542.GA2208@icarus.home.lan> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, jkim@freebsd.org Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 22:12:16 -0000 on 22/04/2010 17:35 Jeremy Chadwick said the following: > I went digging through HEAD commits between the above dates and wasn't > able to find much other than this, which appears to be the HEAD commit > that was MFC'd to RELENG_8: > > http://freshbsd.org/2010/04/02/23/04/31 I don't think this has been MFC-ed to 8. Most likely a red herring. AFAIK, there were no ACPI-related changes in 8 for the last couple of months, so the issue must be elsewhere. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 02:22:16 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C3651065673; Fri, 23 Apr 2010 02:22:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 68D098FC0C; Fri, 23 Apr 2010 02:22:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3N2MFUV007562; Thu, 22 Apr 2010 22:22:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3N2MFaV007561; Fri, 23 Apr 2010 02:22:15 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 23 Apr 2010 02:22:15 GMT Message-Id: <201004230222.o3N2MFaV007561@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 02:22:16 -0000 TB --- 2010-04-23 01:21:05 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-23 01:21:05 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2010-04-23 01:21:05 - cleaning the object tree TB --- 2010-04-23 01:21:24 - cvsupping the source tree TB --- 2010-04-23 01:21:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2010-04-23 01:21:48 - building world TB --- 2010-04-23 01:21:48 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-23 01:21:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-23 01:21:48 - TARGET=sparc64 TB --- 2010-04-23 01:21:48 - TARGET_ARCH=sparc64 TB --- 2010-04-23 01:21:48 - TZ=UTC TB --- 2010-04-23 01:21:48 - __MAKE_CONF=/dev/null TB --- 2010-04-23 01:21:48 - cd /src TB --- 2010-04-23 01:21:48 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 23 01:21:48 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Apr 23 02:15:56 UTC 2010 TB --- 2010-04-23 02:15:56 - generating LINT kernel config TB --- 2010-04-23 02:15:56 - cd /src/sys/sparc64/conf TB --- 2010-04-23 02:15:56 - /usr/bin/make -B LINT TB --- 2010-04-23 02:15:56 - building LINT kernel TB --- 2010-04-23 02:15:56 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-23 02:15:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-23 02:15:56 - TARGET=sparc64 TB --- 2010-04-23 02:15:56 - TARGET_ARCH=sparc64 TB --- 2010-04-23 02:15:56 - TZ=UTC TB --- 2010-04-23 02:15:56 - __MAKE_CONF=/dev/null TB --- 2010-04-23 02:15:56 - cd /src TB --- 2010-04-23 02:15:56 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 23 02:15:56 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/fs/nfs/nfs_commonacl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clcomsubs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clsubs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clstate.c /src/sys/fs/nfsclient/nfs_clstate.c: In function 'nfscl_open': /src/sys/fs/nfsclient/nfs_clstate.c:280: error: 'NFSCLOPEN_SETCRED' undeclared (first use in this function) /src/sys/fs/nfsclient/nfs_clstate.c:280: error: (Each undeclared identifier is reported only once /src/sys/fs/nfsclient/nfs_clstate.c:280: error: for each function it appears in.) *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-23 02:22:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-23 02:22:15 - ERROR: failed to build lint kernel TB --- 2010-04-23 02:22:15 - 2889.47 user 554.27 system 3669.41 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 02:23:21 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12CE91065676; Fri, 23 Apr 2010 02:23:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 863CD8FC28; Fri, 23 Apr 2010 02:23:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o3N2NIJN008118; Thu, 22 Apr 2010 22:23:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o3N2NInB008117; Fri, 23 Apr 2010 02:23:18 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 23 Apr 2010 02:23:18 GMT Message-Id: <201004230223.o3N2NInB008117@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 02:23:21 -0000 TB --- 2010-04-23 01:19:27 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-04-23 01:19:27 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2010-04-23 01:19:27 - cleaning the object tree TB --- 2010-04-23 01:19:43 - cvsupping the source tree TB --- 2010-04-23 01:19:43 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2010-04-23 01:20:12 - building world TB --- 2010-04-23 01:20:12 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-23 01:20:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-23 01:20:12 - TARGET=powerpc TB --- 2010-04-23 01:20:12 - TARGET_ARCH=powerpc TB --- 2010-04-23 01:20:12 - TZ=UTC TB --- 2010-04-23 01:20:12 - __MAKE_CONF=/dev/null TB --- 2010-04-23 01:20:12 - cd /src TB --- 2010-04-23 01:20:12 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 23 01:20:13 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Apr 23 02:17:12 UTC 2010 TB --- 2010-04-23 02:17:12 - generating LINT kernel config TB --- 2010-04-23 02:17:12 - cd /src/sys/powerpc/conf TB --- 2010-04-23 02:17:12 - /usr/bin/make -B LINT TB --- 2010-04-23 02:17:12 - building LINT kernel TB --- 2010-04-23 02:17:12 - MAKEOBJDIRPREFIX=/obj TB --- 2010-04-23 02:17:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-04-23 02:17:12 - TARGET=powerpc TB --- 2010-04-23 02:17:12 - TARGET_ARCH=powerpc TB --- 2010-04-23 02:17:12 - TZ=UTC TB --- 2010-04-23 02:17:12 - __MAKE_CONF=/dev/null TB --- 2010-04-23 02:17:12 - cd /src TB --- 2010-04-23 02:17:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 23 02:17:12 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/fs/nfs/nfs_commonacl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clcomsubs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clsubs.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/fs/nfsclient/nfs_clstate.c /src/sys/fs/nfsclient/nfs_clstate.c: In function 'nfscl_open': /src/sys/fs/nfsclient/nfs_clstate.c:280: error: 'NFSCLOPEN_SETCRED' undeclared (first use in this function) /src/sys/fs/nfsclient/nfs_clstate.c:280: error: (Each undeclared identifier is reported only once /src/sys/fs/nfsclient/nfs_clstate.c:280: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-04-23 02:23:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-04-23 02:23:18 - ERROR: failed to build lint kernel TB --- 2010-04-23 02:23:18 - 3042.94 user 560.86 system 3830.98 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 06:39:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2625106564A; Fri, 23 Apr 2010 06:39:56 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from mail.vnode.se (mail.vnode.se [62.119.52.80]) by mx1.freebsd.org (Postfix) with ESMTP id 1C8568FC1C; Fri, 23 Apr 2010 06:39:56 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 122ECE3F086; Fri, 23 Apr 2010 08:22:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cP5yDxZQxiK; Fri, 23 Apr 2010 08:22:08 +0200 (CEST) Received: from bubba.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id D28CFE3F077; Fri, 23 Apr 2010 08:22:07 +0200 (CEST) Date: Fri, 23 Apr 2010 08:22:05 +0200 From: Joel Dahl To: Jeremy Chadwick Message-ID: <20100423062205.GB84889@bubba.vnode.local> References: <20100422143542.GA2208@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100422143542.GA2208@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, jkim@freebsd.org Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 06:39:56 -0000 On 22-04-2010 7:35, Jeremy Chadwick wrote: > Looks like some form of regression in RELENG_8, between the dates of > 2010/03/30 and 2010/04/22. My 2010/03/30 kernel (built from RELENG_8 > source dated 2010/03/30 @ 10:30 PDT) doesn't have this problem. > > Symptom: shutdown -p no longer powers off either of my systems; instead, > the box reboots (e.g. shutdown -p behaves like shutdown -r). Systems > are a Supermicro X7SBL-LN2 board, and a Supermicro X7SBA board. These > are server-class boards. I have not tried using the physical power > switch yet. For the record: I have the same problem on at least two boxes, both running 9-CURRENT. -- Joel From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 07:27:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F6411065672; Fri, 23 Apr 2010 07:27:13 +0000 (UTC) (envelope-from makc@issp.ac.ru) Received: from mail.issp.ac.ru (mail.issp.ac.ru [77.236.34.3]) by mx1.freebsd.org (Postfix) with ESMTP id 04F958FC1B; Fri, 23 Apr 2010 07:27:12 +0000 (UTC) Received: from lqc.issp.ac.ru [77.236.34.156:23244] (HELO/EHLO lqc.issp.ac.ru, authenticated with PLAIN) by mail.issp.ac.ru with ESMTP/inet id o3N6mA82000535 (using TLSv1/SSLv3, with cipher DHE-RSA-AES256-SHA (256 bits), verified NO) Fri, 23 Apr 2010 10:48:10 +0400 (MSD) From: Max Brazhnikov Organization: ISSP RAS To: freebsd-stable@freebsd.org Date: Fri, 23 Apr 2010 10:48:54 +0400 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.5; i386; ; ) References: <20100422143542.GA2208@icarus.home.lan> In-Reply-To: <20100422143542.GA2208@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201004231048.54664.makc@issp.ac.ru> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (mail.issp.ac.ru [77.236.34.3]); Fri, 23 Apr 2010 10:48:10 +0400 (MSD) Cc: jkim@freebsd.org, Jeremy Chadwick , Andriy Gapon Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 07:27:13 -0000 On Thu, 22 Apr 2010 07:35:42 -0700, Jeremy Chadwick wrote: > Looks like some form of regression in RELENG_8, between the dates of > 2010/03/30 and 2010/04/22. My 2010/03/30 kernel (built from RELENG_8 > source dated 2010/03/30 @ 10:30 PDT) doesn't have this problem. Does not work for me either since I updated my system on April 4. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 07:55:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50DD8106566B for ; Fri, 23 Apr 2010 07:55:37 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id DD9098FC22 for ; Fri, 23 Apr 2010 07:55:36 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 799091B97; Fri, 23 Apr 2010 09:55:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mail; t=1272009330; x= 1273823730; bh=PQSXSdiuYoi0P2hc8c94zYZZg8Tc19Zvpoqwvo9aUXA=; b=t 2BUSuRzkg2vFtPNt+zoToUVBST045+Ire9LUOFoEWROQ1cHPF5+49wuC9WmcAG26 5h9q/EuvQ4JcRZMROYPlGqE5VHaHvff1DAVN9prpNMO0B9jjMl+2xaln4N3uRP1F rlacv4gftQsfNpBNdXuHenUNGwXHcAHGqU9/L+4vI4= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PhEUrvAVOGuo; Fri, 23 Apr 2010 09:55:30 +0200 (CEST) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 53D1C1B90; Fri, 23 Apr 2010 09:55:30 +0200 (CEST) Date: Fri, 23 Apr 2010 09:55:30 +0200 From: Guido Falsi To: Jeremy Chadwick Message-ID: <20100423075530.GA2306@megatron.madpilot.net> References: <20100422143542.GA2208@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100422143542.GA2208@icarus.home.lan> X-Operating-System: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, jkim@freebsd.org Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 07:55:37 -0000 On Thu, Apr 22, 2010 at 07:35:42AM -0700, Jeremy Chadwick wrote: > Looks like some form of regression in RELENG_8, between the dates of > 2010/03/30 and 2010/04/22. My 2010/03/30 kernel (built from RELENG_8 > source dated 2010/03/30 @ 10:30 PDT) doesn't have this problem. > > Symptom: shutdown -p no longer powers off either of my systems; instead, > the box reboots (e.g. shutdown -p behaves like shutdown -r). Systems > are a Supermicro X7SBL-LN2 board, and a Supermicro X7SBA board. These > are server-class boards. I have not tried using the physical power > switch yet. > > Looks like others have reported the same on a different board, though I > haven't booted verbose to see if the behaviour is identical: I'm having the same problem on an HP DC7800 Desktop since updating the system yesterday. I'm using 8-STABLE. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 08:36:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2FB41065670 for ; Fri, 23 Apr 2010 08:36:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id A25858FC0C for ; Fri, 23 Apr 2010 08:36:22 +0000 (UTC) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta14.westchester.pa.mail.comcast.net with comcast id 8wcN1e00F0vyq2s5EwcN0e; Fri, 23 Apr 2010 08:36:22 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta05.westchester.pa.mail.comcast.net with comcast id 8wcM1e0053S48mS3RwcNYl; Fri, 23 Apr 2010 08:36:22 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 523599B423; Thu, 22 Apr 2010 12:50:00 -0700 (PDT) Date: Thu, 22 Apr 2010 12:50:00 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100422195000.GA10082@icarus.home.lan> References: <20100422143542.GA2208@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100422143542.GA2208@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: jkim@freebsd.org Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 08:36:23 -0000 On Thu, Apr 22, 2010 at 07:35:42AM -0700, Jeremy Chadwick wrote: > Symptom: shutdown -p no longer powers off either of my systems; instead, > the box reboots (e.g. shutdown -p behaves like shutdown -r). Systems > are a Supermicro X7SBL-LN2 board, and a Supermicro X7SBA board. These > are server-class boards. I have not tried using the physical power > switch yet. Manual power switch behaves the same way (and given what I understand of ATX and ACPI, this is normal). The only way I found to shut the machine off is to press the power button shortly after POST. > I went digging through HEAD commits between the above dates ... I realised I'll need to find when the ACPICA code was originally committed to HEAD (probably much earlier than RELENG_8!), then work forwards to present day to try and find the committed fix. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 08:36:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 444461065675 for ; Fri, 23 Apr 2010 08:36:23 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id E6B288FC15 for ; Fri, 23 Apr 2010 08:36:22 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id 8wYC1e0041vXlb851wcPda; Fri, 23 Apr 2010 08:36:23 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.westchester.pa.mail.comcast.net with comcast id 8wcM1e00B3S48mS3dwcNS1; Fri, 23 Apr 2010 08:36:23 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4F2029B42B; Thu, 22 Apr 2010 21:25:10 -0700 (PDT) Date: Thu, 22 Apr 2010 21:25:10 -0700 From: Jeremy Chadwick To: Andriy Gapon Message-ID: <20100423042510.GA21479@icarus.home.lan> References: <20100422143542.GA2208@icarus.home.lan> <4BD0C9BA.2000405@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD0C9BA.2000405@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, jfvogel@gmail.com Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 08:36:23 -0000 On Fri, Apr 23, 2010 at 01:12:10AM +0300, Andriy Gapon wrote: > on 22/04/2010 17:35 Jeremy Chadwick said the following: > > I went digging through HEAD commits between the above dates and wasn't > > able to find much other than this, which appears to be the HEAD commit > > that was MFC'd to RELENG_8: > > > > http://freshbsd.org/2010/04/02/23/04/31 > > I don't think this has been MFC-ed to 8. > Most likely a red herring. > AFAIK, there were no ACPI-related changes in 8 for the last couple of months, so > the issue must be elsewhere. You're right -- sorry about that. I was looking at cvsweb initially, and missed the fact that CVS tags was HEAD (I thought it was RELENG_8). Removing jkim@ from CC list. I'm not sure how I'm going to figure out what the cause of this is, due to how the problem manifests itself. The only other idea I have pertains to WOL (Wake-on-LAN), as both machines use em(4), and I see ifconfig reports the following on their NICs: options=399b WOL_UCAST, WOL_MCAST, and WOL_MAGIC are new -- presumably respecting a WOL packet sent via unicast and multicast, but what's WOL_MAGIC? The "magic packet" part of WOL is mandatory, AFAIK (has to contain 6 0xFFs followed by 16 repetitions of the MAC address, and the packet can be of any type. Why I care: When I visually inspected the machine during "shutdown -p", I noticed it had shut off (fans powered down), but the instant the LAN LED blinked the machine powered back on. This could indicate that the new e1000 code isn't doing the Right Thing(tm) when it comes to WOL, and is instead interpreting *any* packet coming in to the NIC as WOL, thus powering up. I have no idea how I'd go about debugging this either. Jack, any ideas? The NICs which have link/exist on the same LAN together: Supermicro X7SBA: em0: port 0x2000-0x201f mem 0xdc200000-0xdc21ffff irq 16 at device 0.0 on pci13 em0@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (82573E)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) Supermicro X7SBL-LN2: em0: port 0x2000-0x201f mem 0xdc100000-0xdc11ffff irq 16 at device 0.0 on pci13 em0@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (82573E)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 08:46:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44D3E106567B; Fri, 23 Apr 2010 08:46:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B07188FC18; Fri, 23 Apr 2010 08:46:11 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o3N8k7eK005045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Apr 2010 11:46:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o3N8k6at059862; Fri, 23 Apr 2010 11:46:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o3N8k6vG059861; Fri, 23 Apr 2010 11:46:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 23 Apr 2010 11:46:06 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20100423084606.GV2422@deviant.kiev.zoral.com.ua> References: <20100422143542.GA2208@icarus.home.lan> <4BD0C9BA.2000405@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DzFMwNuU1QL7hgxO" Content-Disposition: inline In-Reply-To: <4BD0C9BA.2000405@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org, jkim@freebsd.org, Jeremy Chadwick Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 08:46:12 -0000 --DzFMwNuU1QL7hgxO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 23, 2010 at 01:12:10AM +0300, Andriy Gapon wrote: > on 22/04/2010 17:35 Jeremy Chadwick said the following: > > I went digging through HEAD commits between the above dates and wasn't > > able to find much other than this, which appears to be the HEAD commit > > that was MFC'd to RELENG_8: > >=20 > > http://freshbsd.org/2010/04/02/23/04/31 >=20 > I don't think this has been MFC-ed to 8. > Most likely a red herring. >=20 > AFAIK, there were no ACPI-related changes in 8 for the last couple of mon= ths, so > the issue must be elsewhere. I have the 5046A-XB SuperWorkstation, and I can confirm that it restarts shortly after power halt. On the other hand, I thought that this is a hardware bug. --DzFMwNuU1QL7hgxO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvRXk4ACgkQC3+MBN1Mb4hqPACg7bCy5aVFEYnSJ2FAU4MXI4Ys 19cAoJotzRHkD7wf1l4YPyNi+z9unxTj =fzbp -----END PGP SIGNATURE----- --DzFMwNuU1QL7hgxO-- From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 08:59:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1B481065670 for ; Fri, 23 Apr 2010 08:59:21 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by mx1.freebsd.org (Postfix) with ESMTP id 9E61C8FC0C for ; Fri, 23 Apr 2010 08:59:21 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta15.westchester.pa.mail.comcast.net with comcast id 8wzM1e0061vXlb85FwzMNH; Fri, 23 Apr 2010 08:59:21 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.westchester.pa.mail.comcast.net with comcast id 8wzL1e0043S48mS3dwzM4f; Fri, 23 Apr 2010 08:59:21 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5FBDE9B423; Fri, 23 Apr 2010 01:54:01 -0700 (PDT) Date: Fri, 23 Apr 2010 01:54:01 -0700 From: Jeremy Chadwick To: Kostik Belousov Message-ID: <20100423085401.GA28720@icarus.home.lan> References: <20100422143542.GA2208@icarus.home.lan> <4BD0C9BA.2000405@icyb.net.ua> <20100423084606.GV2422@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100423084606.GV2422@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Andriy Gapon , jkim@freebsd.org Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 08:59:22 -0000 On Fri, Apr 23, 2010 at 11:46:06AM +0300, Kostik Belousov wrote: > On Fri, Apr 23, 2010 at 01:12:10AM +0300, Andriy Gapon wrote: > > on 22/04/2010 17:35 Jeremy Chadwick said the following: > > > I went digging through HEAD commits between the above dates and wasn't > > > able to find much other than this, which appears to be the HEAD commit > > > that was MFC'd to RELENG_8: > > > > > > http://freshbsd.org/2010/04/02/23/04/31 > > > > I don't think this has been MFC-ed to 8. > > Most likely a red herring. > > > > AFAIK, there were no ACPI-related changes in 8 for the last couple of months, so > > the issue must be elsewhere. > > I have the 5046A-XB SuperWorkstation, and I can confirm that it restarts > shortly after power halt. On the other hand, I thought that this is a > hardware bug. In my case, it's not a hardware nor BIOS (ACPI) bug. Both of my systems have worked just fine with "shutdown -p now" until recent commits to RELENG_8. Something broke this functionality between March 30th and April 22nd. I'll try to spend some time this weekend tracking it down... -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 11:33:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3500B1065674; Fri, 23 Apr 2010 11:33:24 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4588FC15; Fri, 23 Apr 2010 11:33:23 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 99FDA1C83; Fri, 23 Apr 2010 13:33:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mail; t=1272022399; x= 1273836799; bh=lv+owNTJbnUBCJurqiZggXXI7X6yjWM4GXH09V1MUVM=; b=o lJNnXZiZgx00pdDmFOtAfqvj7jTcLxCQB9T7txEdGcaihWqHEDqCEK6uQBRDnrcN ynsiO/N1vc0m3FnYtqBaCt3eAhs+kJDmZSGv3OOgX2ODvi+6zQAVm3jEUQYV8yPz Uvtuozs25bCNaNdzfmxDUfqWV5fz++9TuzItHxLLlU= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nW1J3DPE2xx6; Fri, 23 Apr 2010 13:33:19 +0200 (CEST) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 9F2E91C7C; Fri, 23 Apr 2010 13:33:19 +0200 (CEST) Date: Fri, 23 Apr 2010 13:33:19 +0200 From: Guido Falsi To: Jeremy Chadwick Message-ID: <20100423113319.GA4925@megatron.madpilot.net> References: <20100422143542.GA2208@icarus.home.lan> <4BD0C9BA.2000405@icyb.net.ua> <20100423084606.GV2422@deviant.kiev.zoral.com.ua> <20100423085401.GA28720@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100423085401.GA28720@icarus.home.lan> X-Operating-System: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , freebsd-stable@freebsd.org, Andriy Gapon , jkim@freebsd.org Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 11:33:24 -0000 On Fri, Apr 23, 2010 at 01:54:01AM -0700, Jeremy Chadwick wrote: > On Fri, Apr 23, 2010 at 11:46:06AM +0300, Kostik Belousov wrote: > > On Fri, Apr 23, 2010 at 01:12:10AM +0300, Andriy Gapon wrote: > > > on 22/04/2010 17:35 Jeremy Chadwick said the following: > > > > I went digging through HEAD commits between the above dates and wasn't > > > > able to find much other than this, which appears to be the HEAD commit > > > > that was MFC'd to RELENG_8: > > > > > > > > http://freshbsd.org/2010/04/02/23/04/31 > > > > > > I don't think this has been MFC-ed to 8. > > > Most likely a red herring. > > > > > > AFAIK, there were no ACPI-related changes in 8 for the last couple of months, so > > > the issue must be elsewhere. > > > > I have the 5046A-XB SuperWorkstation, and I can confirm that it restarts > > shortly after power halt. On the other hand, I thought that this is a > > hardware bug. > > In my case, it's not a hardware nor BIOS (ACPI) bug. Both of my systems > have worked just fine with "shutdown -p now" until recent commits to > RELENG_8. Something broke this functionality between March 30th and > April 22nd. > > I'll try to spend some time this weekend tracking it down... Since I find this quite annoying I tried some experiments. First I tried an "ifconfig em0 -wol" and after that the PC was able to power down and stay powered down (left it there for 2 minutes...It powers back up in no more than a second otherwise). Disabling WOL from the BIOS on this machine seems not to change anything. the functionality is enabled anyway by the driver. As a temporary workaround I commented out this piece of code in if_em.c (lines 2710-2714): /* Enable All WOL methods by default */ /* if (adapter->wol) { ifp->if_capabilities |= IFCAP_WOL; ifp->if_capenable |= IFCAP_WOL; } */ I had a look at if_em.c and diffs from previous versions and noticed that the last update adds this snippet of code to unconditionally enable WOL on em cards. Is this correct policy? I checked with another machine with an older world and WOL used to be off by default. Anyway there is also a problem because even with WOL on the machine should not turn on on ANY packet. I tried to make something out, but I have no idea where to look at. I suspect something is incorrect in the programming of the PHY to enable WOL. It definitely is an em WOL problem though. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 12:20:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84058106566B for ; Fri, 23 Apr 2010 12:20:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFF68FC17 for ; Fri, 23 Apr 2010 12:20:02 +0000 (UTC) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta07.westchester.pa.mail.comcast.net with comcast id 8ySU1e0010cZkys570L3Aa; Fri, 23 Apr 2010 12:20:03 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta10.westchester.pa.mail.comcast.net with comcast id 90L11e0083S48mS3W0L10q; Fri, 23 Apr 2010 12:20:03 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 288F49B425; Fri, 23 Apr 2010 05:20:00 -0700 (PDT) Date: Fri, 23 Apr 2010 05:20:00 -0700 From: Jeremy Chadwick To: Guido Falsi Message-ID: <20100423122000.GA41857@icarus.home.lan> References: <20100422143542.GA2208@icarus.home.lan> <4BD0C9BA.2000405@icyb.net.ua> <20100423084606.GV2422@deviant.kiev.zoral.com.ua> <20100423085401.GA28720@icarus.home.lan> <20100423113319.GA4925@megatron.madpilot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100423113319.GA4925@megatron.madpilot.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , freebsd-stable@freebsd.org, Andriy Gapon , jfvogel@gmail.com Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 12:20:03 -0000 On Fri, Apr 23, 2010 at 01:33:19PM +0200, Guido Falsi wrote: > On Fri, Apr 23, 2010 at 01:54:01AM -0700, Jeremy Chadwick wrote: > > On Fri, Apr 23, 2010 at 11:46:06AM +0300, Kostik Belousov wrote: > > > On Fri, Apr 23, 2010 at 01:12:10AM +0300, Andriy Gapon wrote: > > > > on 22/04/2010 17:35 Jeremy Chadwick said the following: > > > > > I went digging through HEAD commits between the above dates and wasn't > > > > > able to find much other than this, which appears to be the HEAD commit > > > > > that was MFC'd to RELENG_8: > > > > > > > > > > http://freshbsd.org/2010/04/02/23/04/31 > > > > > > > > I don't think this has been MFC-ed to 8. > > > > Most likely a red herring. > > > > > > > > AFAIK, there were no ACPI-related changes in 8 for the last couple of months, so > > > > the issue must be elsewhere. > > > > > > I have the 5046A-XB SuperWorkstation, and I can confirm that it restarts > > > shortly after power halt. On the other hand, I thought that this is a > > > hardware bug. > > > > In my case, it's not a hardware nor BIOS (ACPI) bug. Both of my systems > > have worked just fine with "shutdown -p now" until recent commits to > > RELENG_8. Something broke this functionality between March 30th and > > April 22nd. > > > > I'll try to spend some time this weekend tracking it down... > > Since I find this quite annoying I tried some experiments. > > First I tried an "ifconfig em0 -wol" and after that the PC was able to > power down and stay powered down (left it there for 2 minutes...It > powers back up in no more than a second otherwise). > > Disabling WOL from the BIOS on this machine seems not to change > anything. the functionality is enabled anyway by the driver. > > As a temporary workaround I commented out this piece of code in if_em.c > (lines 2710-2714): > > /* Enable All WOL methods by default */ > /* if (adapter->wol) { > ifp->if_capabilities |= IFCAP_WOL; > ifp->if_capenable |= IFCAP_WOL; > } */ > > > I had a look at if_em.c and diffs from previous versions and noticed > that the last update adds this snippet of code to unconditionally > enable WOL on em cards. Is this correct policy? I checked with > another machine with an older world and WOL used to be off by > default. > > Anyway there is also a problem because even with WOL on the machine > should not turn on on ANY packet. I tried to make something out, > but I have no idea where to look at. I suspect something is incorrect > in the programming of the PHY to enable WOL. > > It definitely is an em WOL problem though. CC'ing Jack Vogel on this one too. Guido, Thanks for the investigative efforts. I can validate your statements: doing "ifconfig emX -wol" does in fact address the problem. The ifconfig(8) man page had this to say: There are three types of packets that may wake a system: ucast (directed solely to the machine's mac address), mcast (directed to a broadcast or multicast address), or magic (unicast or multicast frames with a ``magic contents''). I read the ucast definition to mean **any** packet directed to the machine's MAC, which would almost guarantee the machine be woken up; think ARP packets. The same goes for mcast -- **any** packet directed to the broadcast of the network (e.g. 192.168.1.255) or a multicast address (e.g. addresses within RFC3171 range) would wake the machine up. How is this behaviour at all desirable? I can see the above features working *in addition* to the WOL_MAGIC (magic packet) requirement, but that's not what the man page implies, nor is it what's being seen in driver 7.0.5. It's as if nearly any kind of packet arriving on the NIC powers the machine up. I'll spend some time later today messing around with combinations of ifconfig em0 -wol_ucast and -wol_mcast to see if I can narrow down the condition. I'll report back with those findings. I've already noticed that "ifconfig em0 -wol_mcast -wol_ucast" results in the WOL_MCAST being removed but WOL_UCAST + WOL_MAGIC being left enabled. I have a feeling this is by design (e.g. you can't just have WOL_MAGIC set and that's it), but I'm not sure. One thing I do want to note: Prior to driver 7.0.5, ifconfig did not show any WOL capabilities. However, magic packets directed to the broadcast address on the local network (e.g. 192.168.1.255) *did* induce the machine to power up. How do I know this? Because the X7SBA system would use ports/net/wol, calling wol --host=192.168.1.255 $mac (where $mac = MAC address of X7SBL-LN2 machine), to wake the X7SBL-LN2 box up (to perform automated backups). Using --host=255.255.255.255 didn't work, nor did using --host=what-the-machines-IP-address-last-was. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 14:21:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 204A91065672 for ; Fri, 23 Apr 2010 14:21:49 +0000 (UTC) (envelope-from nr1c0re@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF708FC08 for ; Fri, 23 Apr 2010 14:21:47 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so691119fga.13 for ; Fri, 23 Apr 2010 07:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=G76LVv3hON+tqgxSitw8Tk0fMCvnCznVAYDoxSr4LyU=; b=j6iDPla9xVhTVg2zfeFxOZcLK9mWdul0raIcccEo2YjPJy6xMQUUgX3S4wddIWMTmG 1FaGwWg/wEj/aXh/L8rMXQFauaRQ7xOFCLsappPpe1YovhrEZmPyFUqZot2fHGQixox5 Etn6opTPuFDduEQNmadhkDIQhv2sD1/UhU5wQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W7Dckn/recNO3N+0a4/1qSo3TNrsHL9hviodwqLpfWAX3Tga6QztLxjpBXzBsA51mV UXzi/ONhpMgICXYLMt1D6iBIAjb9PLIvGjJKEDbw/hBJgKoEtomr8jycv5t1w8/Cb+oE lodDZMcVjQRaYhStrGgtzjlUqDsbRBcVAp9Fk= MIME-Version: 1.0 Received: by 10.87.62.28 with SMTP id p28mr525583fgk.16.1272032499666; Fri, 23 Apr 2010 07:21:39 -0700 (PDT) Received: by 10.86.84.6 with HTTP; Fri, 23 Apr 2010 07:21:39 -0700 (PDT) In-Reply-To: <20100421074959.J40281@maildrop.int.zabbadoz.net> References: <201004200748.09566.jhb@freebsd.org> <20100421074959.J40281@maildrop.int.zabbadoz.net> Date: Fri, 23 Apr 2010 18:21:39 +0400 Message-ID: From: c0re To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, net@freebsd.org Subject: Re: FreeBSD 7.3, reboot after panic: double fault X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 14:21:49 -0000 I tryed RELENG_7_3, RELENG_7, RELENG_8_0, RELENG_8 - results are same - kernel panic. This is backtrace of RELENG_8 host# kgdb kernel.debug /var/crash/vmcore.7 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal double fault: eip = 0xc0933a38 esp = 0xe460bfd8 ebp = 0xe460c068 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 Uptime: 4m42s Physical memory: 1011 MB Dumping 68 MB: 53 37 21 5 Reading symbols from /boot/kernel/if_gre.ko...Reading symbols from /boot/kernel/if_gre.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_gre.ko #0 doadump () at pcpu.h:246 246 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc0891997 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc0891c89 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xc0b4525b in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:971 #4 0xc0933a38 in flowtable_lookup (ft=0xc4478000, ssa=0xe460c108, dsa=0xe460c088, fibnum=0, flags=2050) at /usr/src/sys/net/flowtable.c:1115 #5 0xc093428c in flowtable_lookup_mbuf (ft=0xc4478000, m=0xc4470e00, af=2) at /usr/src/sys/net/flowtable.c:607 #6 0xc09b141f in ip_output (m=0xc4470e00, opt=0x0, ro=0x0, flags=0, imo=0x0, inp=0xc4c5d44c) at /usr/src/sys/netinet/ip_output.c:164 #7 0xc09baba6 in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1187 #8 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #9 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #10 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #11 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #12 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #13 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #14 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #15 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #16 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #17 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #18 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #19 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #20 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #21 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #22 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #23 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #24 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #25 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #26 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #27 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #28 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #29 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #30 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #31 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #32 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #33 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #34 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #35 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #36 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #37 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #38 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #39 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #40 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #41 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #42 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #43 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #44 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #45 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #46 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #47 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #48 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #49 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 ---Type to continue, or q to quit--- #50 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #51 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #52 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #53 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #54 0xc09bd5a8 in tcp_mtudisc (inp=0xc4c5d44c, errno=0) at tcp_offload.h:282 #55 0xc09bac9b in tcp_output (tp=0xc4c5f768) at /usr/src/sys/netinet/tcp_output.c:1248 #56 0xc09b78e5 in tcp_do_segment (m=0xc4a83800, th=0xc4aa4024, so=0xc4a2480c, tp=0xc4c5f768, drop_hdrlen=52, tlen=0, iptos=0 '\0', ti_locked=3) at /usr/src/sys/netinet/tcp_input.c:2684 #57 0xc09b8b7d in tcp_input (m=0xc4a83800, off0=20) at /usr/src/sys/netinet/tcp_input.c:1020 #58 0xc09af671 in ip_input (m=0xc4a83800) at /usr/src/sys/netinet/ip_input.c:804 #59 0xc0946a09 in netisr_dispatch_src (proto=1, source=0, m=0xc4a83800) at /usr/src/sys/net/netisr.c:917 #60 0xc0946ca0 in netisr_dispatch (proto=1, m=0xc4a83800) at /usr/src/sys/net/netisr.c:1004 #61 0xc093d2aa in ether_demux (ifp=0xc42d7000, m=0xc4a83800) at /usr/src/sys/net/if_ethersubr.c:901 #62 0xc093d82f in ether_input (ifp=0xc42d7000, m=0xc4a83800) at /usr/src/sys/net/if_ethersubr.c:760 #63 0xc0623c4a in lem_handle_rxtx (context=0xc42ea000, pending=1) at /usr/src/sys/dev/e1000/if_lem.c:3616 #64 0xc08cb282 in taskqueue_run (queue=0xc42c9c80) at /usr/src/sys/kern/subr_taskqueue.c:239 #65 0xc08cb48d in taskqueue_thread_loop (arg=0xc42ee5a8) at /usr/src/sys/kern/subr_taskqueue.c:360 #66 0xc0868831 in fork_exit (callout=0xc08cb3d0 , arg=0xc42ee5a8, frame=0xe460dd38) at /usr/src/sys/kern/kern_fork.c:843 #67 0xc0b28c10 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) 2010/4/21 Bjoern A. Zeeb > On Tue, 20 Apr 2010, pluknet wrote: > > On 20 April 2010 15:48, John Baldwin wrote: >> >>> On Tuesday 20 April 2010 2:53:16 am c0re wrote: >>> >>>> Hello All! >>>> I've upgraded freebsd from 7.0 to 7.3 and all was good until I tryed to >>>> configure gre interface and use ipfw fwd. >>>> I'm actually does not know what was the point of failure in my >>>> configuration. >>>> >>>> [ some details snipped ] >>>> >>>> It worked about one week and then I made some configuration changes: >>>> added gre interface and 2 aliases: >>>> >>>> # cat /etc/rc.conf |grep >>>> ifconfig_xl0="inet 192.168.0.10 netmask 255.255.255.0" >>>> ifconfig_xl0_alias0="192.168.0.11 netmask 255.255.255.255" >>>> ifconfig_xl0_alias1="192.168.0.12 netmask 255.255.255.255" >>>> cloned_interfaces="gre0" >>>> ifconfig_gre0="inet 192.168.250.6 192.168.250.5 tunnel 192.168.0.12 >>>> 192.168.200.15 netmask 255.255.255.252 link1 up" >>>> >>>> and >>>> >>>> # cat /etc/rc.local >>>> #!/bin/sh >>>> ipfw add fwd 192.168.250.5 icmp from 192.168.0.11 to any out via xl0 >>>> ipfw add fwd 192.168.250.5 tcp from 192.168.0.11 443 to any out via xl0 >>>> ipfw add allow ip from any to any >>>> >>>> # ifconfig gre0 >>>> gre0: flags=b050 metric 0 mtu >>>> 1476 >>>> tunnel inet 192.168.0.12 --> 192.168.200.15 >>>> inet 192.168.250.6 --> 192.168.250.5 netmask 0xfffffffc >>>> >>>> I shutted down gre interface to prevent requests via gre to buggy IP. >>>> >>>> The main idea of such configurations was: fwd all connections to https >>>> to >>>> 192.168.0.1 via gre interface. >>>> And also I made apache configurations to make it listen on 192.168.0.11 >>>> too. >>>> >>>> And make some tests: ping 192.168.0.11 - was fine, goes via gre. Telnet >>>> to >>>> 192.168.0.11 443 was fine too. Then I tryed to make browser https >>>> connection to 192.168.0.11. Apache showed me certificate warning and I >>>> accepted, then in browser nothing happened, it was trying to open page. >>>> But >>>> server got kernel panic at that moment. >>>> >>>> At first time I thought that it was some power failure, I tryed 2 more >>>> times >>>> and got same behaviour. >>>> >>>> So https works without kernel panic via 192.168.0.10 address but kernel >>>> panics when I try do https via 192.168.0.11 address that >>>> source-forwarded >>>> via gre. >>>> >>> >>> Looks like the TCP output path got stuck in an infinite recursion loop >>> until >>> it exhausted the kernel stack: >>> >>> # cd /usr/obj/usr/src/sys/MYKERNEL >>>> # kgdb kernel.debug /var/crash/vmcore.2 >>>> GNU gdb 6.1.1 [FreeBSD] >>>> Copyright 2004 Free Software Foundation, Inc. >>>> GDB is free software, covered by the GNU General Public License, and you >>>> are >>>> welcome to change it and/or distribute copies of it under certain >>>> conditions. >>>> Type "show copying" to see the conditions. >>>> There is absolutely no warranty for GDB. Type "show warranty" for >>>> details. >>>> This GDB was configured as "i386-marcel-freebsd"... >>>> >>>> Unread portion of the kernel message buffer: >>>> >>>> Fatal double fault: >>>> eip = 0xc08e3ba3 >>>> esp = 0xccf6dfc4 >>>> ebp = 0xccf6e274 >>>> cpuid = 0; apic id = 00 >>>> panic: double fault >>>> cpuid = 0 >>>> Uptime: 7m14s >>>> Physical memory: 235 MB >>>> Dumping 35 MB: 20 4 >>>> >>>> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >>>> /boot/kernel/acpi.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/acpi.ko >>>> Reading symbols from /boot/kernel/if_gre.ko...Reading symbols from >>>> /boot/kernel/if_gre.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/if_gre.ko >>>> Reading symbols from /boot/kernel/linux.ko...Reading symbols from >>>> /boot/kernel/linux.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/linux.ko >>>> #0 doadump () at pcpu.h:196 >>>> 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); >>>> (kgdb) bt >>>> #0 doadump () at pcpu.h:196 >>>> #1 0xc07f2857 in boot (howto=260) at >>>> /usr/src/sys/kern/kern_shutdown.c:418 >>>> #2 0xc07f2b29 in panic (fmt=Variable "fmt" is not available. >>>> ) at /usr/src/sys/kern/kern_shutdown.c:574 >>>> #3 0xc0a7ea2b in dblfault_handler () at >>>> /usr/src/sys/i386/i386/trap.c:983 >>>> #4 0xc08e3ba3 in ipfw_chk (args=0xccf6e28c) at >>>> /usr/src/sys/netinet/ip_fw2.c:2465 >>>> #5 0xc08e6ce1 in ipfw_check_out (arg=0x0, m0=0xccf6e390, >>>> ifp=0xc25c5c00, >>>> dir=2, inp=0xc28ba708) at /usr/src/sys/netinet/ip_fw_pfil.c:248 >>>> #6 0xc08a1968 in pfil_run_hooks (ph=0xc0c55240, mp=0xccf6e420, >>>> ifp=0xc25c5c00, dir=2, inp=0xc28ba708) at /usr/src/sys/net/pfil.c:78 >>>> #7 0xc08eb6f2 in ip_output (m=0xc2710b00, opt=0x0, ro=0xccf6e3f4, >>>> flags=0, >>>> imo=0x0, inp=0xc28ba708) at /usr/src/sys/netinet/ip_output.c:443 >>>> #8 0xc08f4016 in tcp_output (tp=0xc25b2570) at >>>> /usr/src/sys/netinet/tcp_output.c:1134 >>>> >>> > [twiddle] > > > #47 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at >>>> tcp_offload.h:269 >>>> #48 0xc08f4105 in tcp_output (tp=0xc25b2570) at >>>> /usr/src/sys/netinet/tcp_output.c:1195 >>>> #49 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at >>>> tcp_offload.h:269 >>>> ---Type to continue, or q to quit--- >>>> #50 0xc08f4105 in tcp_output (tp=0xc25b2570) at >>>> /usr/src/sys/netinet/tcp_output.c:1195 >>>> #51 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at >>>> tcp_offload.h:269 >>>> #52 0xc08f4105 in tcp_output (tp=0xc25b2570) at >>>> /usr/src/sys/netinet/tcp_output.c:1195 >>>> #53 0xc08f6d98 in tcp_mtudisc (inp=0xc28ba708, errno=0) at >>>> tcp_offload.h:269 >>>> #54 0xc08f4105 in tcp_output (tp=0xc25b2570) at >>>> /usr/src/sys/netinet/tcp_output.c:1195 >>>> #55 0xc08fdcf8 in tcp_usr_send (so=0xc2ac1820, flags=0, m=0xc270ed00, >>>> nam=0x0, control=0x0, td=0xc28e2d80) at tcp_offload.h:269 >>>> #56 0xc0850405 in sosend_generic (so=0xc2ac1820, addr=0x0, >>>> uio=0xc28766c0, >>>> top=0xc270ed00, control=0x0, flags=0, td=0xc28e2d80) at >>>> /usr/src/sys/kern/uipc_socket.c:1243 >>>> #57 0xc084bf7f in sosend (so=0xc2ac1820, addr=0x0, uio=0xc28766c0, >>>> top=0x0, >>>> control=0x0, flags=0, td=0xc28e2d80) at >>>> /usr/src/sys/kern/uipc_socket.c:1285 >>>> #58 0xc0833c5b in soo_write (fp=0xc28e84c0, uio=0xc28766c0, >>>> active_cred=0xc28e5900, flags=0, td=0xc28e2d80) at >>>> /usr/src/sys/kern/sys_socket.c:103 >>>> #59 0xc082d2e7 in dofilewrite (td=0xc28e2d80, fd=24, fp=0xc28e84c0, >>>> auio=0xc28766c0, offset=-1, flags=0) at file.h:257 >>>> #60 0xc082d5c8 in kern_writev (td=0xc28e2d80, fd=24, auio=0xc28766c0) at >>>> /usr/src/sys/kern/sys_generic.c:402 >>>> #61 0xc082d816 in writev (td=0xc28e2d80, uap=0xccf6fcfc) at >>>> /usr/src/sys/kern/sys_generic.c:388 >>>> #62 0xc0a7f2d5 in syscall (frame=0xccf6fd38) at >>>> /usr/src/sys/i386/i386/trap.c:1101 >>>> #63 0xc0a636a0 in Xint0x80_syscall () at >>>> /usr/src/sys/i386/i386/exception.s:262 >>>> #64 0x00000033 in ?? () >>>> Previous frame inner to this frame (corrupt stack?) >>>> (kgdb) >>>> (kgdb) quit >>>> >>> >>> tcp_output() calls tcp_mtudisc() if ip_output() returns EMSGSIZE: >>> >>> case EMSGSIZE: >>> /* >>> * For some reason the interface we used initially >>> * to send segments changed to another or lowered >>> * its MTU. >>> * >>> * tcp_mtudisc() will find out the new MTU and as >>> * its last action, initiate retransmission, so it >>> * is important to not do so here. >>> * >>> * If TSO was active we either got an interface >>> * without TSO capabilits or TSO was turned off. >>> * Disable it for this connection as too and >>> * immediatly retry with MSS sized segments >>> generated >>> * by this function. >>> */ >>> if (tso) >>> tp->t_flags &= ~TF_TSO; >>> tcp_mtudisc(tp->t_inpcb, 0); >>> return (0); >>> >>> But tcp_mtudisc() calls tcp_output(): >>> >>> tcpstat.tcps_mturesent++; >>> tp->t_rtttime = 0; >>> tp->snd_nxt = tp->snd_una; >>> tcp_free_sackholes(tp); >>> tp->snd_recover = tp->snd_max; >>> if (tp->t_flags & TF_SACK_PERMIT) >>> EXIT_FASTRECOVERY(tp); >>> tcp_output_send(tp); >>> return (inp); >>> >>> I'm not sure why it's not able to figure out the MTU, perhaps folks on >>> net@ >>> can help. However, it would seem that for the tcp_output() case, >>> tcp_mtudisc() should probably not call tcp_output_send(), but instead >>> tcp_output() should just loop back up to the top after calling >>> tcp_mtudisc() >>> and retry. >>> >>> >> I'm afraid to be wrong but it looks similar to another report for >> 8.0-STABLE >> (may it be a cross-major version regression somewhere around >> tcp_mtudisc()?): >> >> http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056063.html >> > > The backtrace indeed looks very similar. The reporter at that point > had been cvs updated in the middle between two commits. Updating > again seemed to have fixed it for him. > > None of those changes are in 7.3-RELEASE though and the endless loop > indeed should no happen. > > > Is the kernel and the core file still avail for further analyses? > > > /bz > > -- > Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 15:49:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 664B2106574A for ; Fri, 23 Apr 2010 15:49:22 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E54E18FC12 for ; Fri, 23 Apr 2010 15:49:21 +0000 (UTC) Received: by wye20 with SMTP id 20so2729803wye.13 for ; Fri, 23 Apr 2010 08:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=fgMSjo4PE3Z3z5W15Uo55C7eqQw/gRvLa2k1IP1Yy54=; b=oso7fYkfsLXrbALUpLsoTQll4Qqpp1yOkabeJw6ttp3XkI/q8MicXhY9Uo571uJUDF fv4sZQLSYSwyOg4NwCMxb9E0Gg6Rma0qpIbertWESR/AFCJoZqXnBM1+gABsEi7CFlWO rcJpC/FJNIGCxtc7PoSbGiWgTSr7zXlYwcIfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KwWORwYRDVUZAtlaOUeU4Q6pBkI98ERb6jNxIWQBzCbUa2AqMucln9kz8dzmuyxA9E 9gjCl+sHobNZm2RzJS3aL/Dl69vc49cctj9x0B+PqHGCY9uCWCjkRkPf0OzSZiNMnhqt uklvgnyhNchOzcpQUusHMLo1hfBzkjm4b24w8= MIME-Version: 1.0 Received: by 10.216.182.78 with SMTP id n56mr305180wem.148.1272037760725; Fri, 23 Apr 2010 08:49:20 -0700 (PDT) Received: by 10.216.11.8 with HTTP; Fri, 23 Apr 2010 08:49:20 -0700 (PDT) In-Reply-To: <20100423122000.GA41857@icarus.home.lan> References: <20100422143542.GA2208@icarus.home.lan> <4BD0C9BA.2000405@icyb.net.ua> <20100423084606.GV2422@deviant.kiev.zoral.com.ua> <20100423085401.GA28720@icarus.home.lan> <20100423113319.GA4925@megatron.madpilot.net> <20100423122000.GA41857@icarus.home.lan> Date: Fri, 23 Apr 2010 08:49:20 -0700 Message-ID: From: Jack Vogel To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Kostik Belousov , freebsd-stable@freebsd.org, Guido Falsi , Andriy Gapon Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 15:49:22 -0000 Sorry guys, somehow I've not noticed this thread for a while. It was just pointed out to me that I undid a change in the latest driver code, because due to one user's problems after I put in WOL support, I had taken out the broadcast option and left in ONLY MAGIC, but now as you've seen I inadvertently reintroduced it in the newest code. I've agreed to go back to MAGIC only in the current code, but am in the middle of some new development and havent yet got to it but will shortly. Jack On Fri, Apr 23, 2010 at 5:20 AM, Jeremy Chadwick wrote: > On Fri, Apr 23, 2010 at 01:33:19PM +0200, Guido Falsi wrote: > > On Fri, Apr 23, 2010 at 01:54:01AM -0700, Jeremy Chadwick wrote: > > > On Fri, Apr 23, 2010 at 11:46:06AM +0300, Kostik Belousov wrote: > > > > On Fri, Apr 23, 2010 at 01:12:10AM +0300, Andriy Gapon wrote: > > > > > on 22/04/2010 17:35 Jeremy Chadwick said the following: > > > > > > I went digging through HEAD commits between the above dates and > wasn't > > > > > > able to find much other than this, which appears to be the HEAD > commit > > > > > > that was MFC'd to RELENG_8: > > > > > > > > > > > > http://freshbsd.org/2010/04/02/23/04/31 > > > > > > > > > > I don't think this has been MFC-ed to 8. > > > > > Most likely a red herring. > > > > > > > > > > AFAIK, there were no ACPI-related changes in 8 for the last couple > of months, so > > > > > the issue must be elsewhere. > > > > > > > > I have the 5046A-XB SuperWorkstation, and I can confirm that it > restarts > > > > shortly after power halt. On the other hand, I thought that this is a > > > > hardware bug. > > > > > > In my case, it's not a hardware nor BIOS (ACPI) bug. Both of my > systems > > > have worked just fine with "shutdown -p now" until recent commits to > > > RELENG_8. Something broke this functionality between March 30th and > > > April 22nd. > > > > > > I'll try to spend some time this weekend tracking it down... > > > > Since I find this quite annoying I tried some experiments. > > > > First I tried an "ifconfig em0 -wol" and after that the PC was able to > > power down and stay powered down (left it there for 2 minutes...It > > powers back up in no more than a second otherwise). > > > > Disabling WOL from the BIOS on this machine seems not to change > > anything. the functionality is enabled anyway by the driver. > > > > As a temporary workaround I commented out this piece of code in if_em.c > > (lines 2710-2714): > > > > /* Enable All WOL methods by default */ > > /* if (adapter->wol) { > > ifp->if_capabilities |= IFCAP_WOL; > > ifp->if_capenable |= IFCAP_WOL; > > } */ > > > > > > I had a look at if_em.c and diffs from previous versions and noticed > > that the last update adds this snippet of code to unconditionally > > enable WOL on em cards. Is this correct policy? I checked with > > another machine with an older world and WOL used to be off by > > default. > > > > Anyway there is also a problem because even with WOL on the machine > > should not turn on on ANY packet. I tried to make something out, > > but I have no idea where to look at. I suspect something is incorrect > > in the programming of the PHY to enable WOL. > > > > It definitely is an em WOL problem though. > > CC'ing Jack Vogel on this one too. > > Guido, > > Thanks for the investigative efforts. I can validate your statements: > doing "ifconfig emX -wol" does in fact address the problem. > > The ifconfig(8) man page had this to say: > > There are three types of packets that may wake a system: > ucast (directed solely to the machine's mac address), mcast > (directed to a broadcast or multicast address), or magic > (unicast or multicast frames with a ``magic contents''). > > I read the ucast definition to mean **any** packet directed to the > machine's MAC, which would almost guarantee the machine be woken up; > think ARP packets. The same goes for mcast -- **any** packet directed > to the broadcast of the network (e.g. 192.168.1.255) or a multicast > address (e.g. addresses within RFC3171 range) would wake the machine up. > > How is this behaviour at all desirable? > > I can see the above features working *in addition* to the WOL_MAGIC > (magic packet) requirement, but that's not what the man page implies, > nor is it what's being seen in driver 7.0.5. It's as if nearly any kind > of packet arriving on the NIC powers the machine up. > > I'll spend some time later today messing around with combinations of > ifconfig em0 -wol_ucast and -wol_mcast to see if I can narrow down the > condition. I'll report back with those findings. > > I've already noticed that "ifconfig em0 -wol_mcast -wol_ucast" results > in the WOL_MCAST being removed but WOL_UCAST + WOL_MAGIC being left > enabled. I have a feeling this is by design (e.g. you can't just have > WOL_MAGIC set and that's it), but I'm not sure. > > One thing I do want to note: > > Prior to driver 7.0.5, ifconfig did not show any WOL capabilities. > However, magic packets directed to the broadcast address on the local > network (e.g. 192.168.1.255) *did* induce the machine to power up. How > do I know this? Because the X7SBA system would use ports/net/wol, > calling wol --host=192.168.1.255 $mac (where $mac = MAC address of > X7SBL-LN2 machine), to wake the X7SBL-LN2 box up (to perform automated > backups). Using --host=255.255.255.255 didn't work, nor did using > --host=what-the-machines-IP-address-last-was. > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 15:54:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C3C7106566C for ; Fri, 23 Apr 2010 15:54:32 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 6F30B8FC14 for ; Fri, 23 Apr 2010 15:54:32 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 90aP1e0080b6N64A23uYcJ; Fri, 23 Apr 2010 15:54:32 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta03.emeryville.ca.mail.comcast.net with comcast id 93uX1e00E3S48mS8P3uXKN; Fri, 23 Apr 2010 15:54:32 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 021DE9B425; Fri, 23 Apr 2010 08:54:30 -0700 (PDT) Date: Fri, 23 Apr 2010 08:54:29 -0700 From: Jeremy Chadwick To: Guido Falsi Message-ID: <20100423155429.GA47524@icarus.home.lan> References: <20100422143542.GA2208@icarus.home.lan> <4BD0C9BA.2000405@icyb.net.ua> <20100423084606.GV2422@deviant.kiev.zoral.com.ua> <20100423085401.GA28720@icarus.home.lan> <20100423113319.GA4925@megatron.madpilot.net> <20100423122000.GA41857@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100423122000.GA41857@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , freebsd-stable@freebsd.org, Andriy Gapon , jfvogel@gmail.com Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 15:54:32 -0000 On Fri, Apr 23, 2010 at 05:20:00AM -0700, Jeremy Chadwick wrote: > I'll spend some time later today messing around with combinations of > ifconfig em0 -wol_ucast and -wol_mcast to see if I can narrow down the > condition. I'll report back with those findings. Here are those results. First, minor details of the setup: box1 = 192.168.1.51, Supermicro X7SBA, connected to switch via em0 box2 = 192.168.1.52, Supermicro X7SBL-LN2, connected to switch via em0 Netmask is 255.255.255.0; absolutely nothing fancy about the setup. My ifconfig "tests", which show some strange behaviour: box2# ifconfig em0 | head -2 em0: flags=8843 metric 0 mtu 1500 options=399b box2# ifconfig em0 -wol_ucast box2# ifconfig em0 | head -2 em0: flags=8843 metric 0 mtu 1500 options=399b box2# ifconfig em0 -wol_mcast box2# ifconfig em0 | head -2 em0: flags=8843 metric 0 mtu 1500 options=299b box2# ifconfig em0 wol box2# ifconfig em0 | head -2 em0: flags=8843 metric 0 mtu 1500 options=399b box2# ifconfig em0 -wol_magic em0: flags=8843 metric 0 mtu 1500 options=199b box2# ifconfig em0 -wol box2# ifconfig em0 | head -2 em0: flags=8843 metric 0 mtu 1500 options=99b box2# ifconfig em0 -wol_ucast box2# ifconfig em0 | head -2 em0: flags=8843 metric 0 mtu 1500 options=99b box2# ifconfig em0 wol_mcast -wol_ucast box2# ifconfig em0 | head -2 em0: flags=8843 metric 0 mtu 1500 options=199b box2# ifconfig em0 wol box2# ifconfig em0 -wol_mcast box2# ifconfig em0 | head -2 em0: flags=8843 metric 0 mtu 1500 options=299b At this point on box2, I executed the following: box2# shutdown -p now Then I did the following tests from box1. To rule out any chance of ARP expiring, I added a static ARP entry for box2's MAC --> 192.168.1.52. 1. ping 192.168.1.255 -- box2 did not power on 2. ping 192.168.1.52 -- box2 did not power on 3. ping 255.255.255.255 -- box2 did not power on 4. sent magic packet to 255.255.255.255 UDP port 40000 -- box2 did not power on 5. sent magic packet to 192.168.1.255 UDP port 40000 -- box2 powered on 6. sent magic packet to 192.168.1.52 UDP port 40000 -- box2 powered on Between test #5 and #6, I executed "ifconfig em0 -wol_mcast" on box2 prior to doing the shutdown. Based on all this, we can more or less reliably tell that: 1) ifconfig's behaviour is unintuitive in this case; this could be a driver (7.0.5) bug, or it could be some odd capabilities bug. I don't know. If this is intentional behaviour, it's unintuitive, and there's no mention of it (or WOL!) in the em(4) man page. Likewise, ifconfig(8)'s descriptions of what the WOL_xxx flags do is also a bit unintuitive. 2) When WOL_MCAST capability disabled on the interface, the system behaviour is identical to that of the older (pre-7.0.5) driver. 3) WOL_MCAST may be buggy in some way, or not implemented correctly inside of the em (7.0.5) driver. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 16:00:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8473106564A for ; Fri, 23 Apr 2010 16:00:44 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id AA3F88FC0C for ; Fri, 23 Apr 2010 16:00:44 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta10.emeryville.ca.mail.comcast.net with comcast id 90C51e0050vp7WLAA40lcV; Fri, 23 Apr 2010 16:00:45 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta05.emeryville.ca.mail.comcast.net with comcast id 940k1e0053S48mS8R40kxP; Fri, 23 Apr 2010 16:00:44 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 05D759B425; Fri, 23 Apr 2010 09:00:43 -0700 (PDT) Date: Fri, 23 Apr 2010 09:00:42 -0700 From: Jeremy Chadwick To: Jack Vogel Message-ID: <20100423160042.GA47940@icarus.home.lan> References: <20100422143542.GA2208@icarus.home.lan> <4BD0C9BA.2000405@icyb.net.ua> <20100423084606.GV2422@deviant.kiev.zoral.com.ua> <20100423085401.GA28720@icarus.home.lan> <20100423113319.GA4925@megatron.madpilot.net> <20100423122000.GA41857@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , freebsd-stable@freebsd.org, Guido Falsi , Andriy Gapon Subject: Re: RELENG_8 -- shutdown -p no longer powers off boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 16:00:44 -0000 On Fri, Apr 23, 2010 at 08:49:20AM -0700, Jack Vogel wrote: > Sorry guys, somehow I've not noticed this thread for a while. It was just > pointed out to > me that I undid a change in the latest driver code, because due to one > user's problems > after I put in WOL support, I had taken out the broadcast option and left in > ONLY MAGIC, > but now as you've seen I inadvertently reintroduced it in the newest code. > > I've agreed to go back to MAGIC only in the current code, but am in the > middle of some > new development and havent yet got to it but will shortly. And I sent the results of my tests 5 minutes after your mail, doh! :-) I guess a quick-fix for the driver would be to force WOL_MCAST off (internally) and remove it from the device capabilities list. I can probably submit a tested patch that would do exactly that; lemme know. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Apr 23 21:42:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEB26106566B for ; Fri, 23 Apr 2010 21:42:59 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (unknown [IPv6:2001:16d8:cc1e:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5976C8FC0C for ; Fri, 23 Apr 2010 21:42:40 +0000 (UTC) Received: from localhost (system.jails.se [87.237.210.209]) by system.jails.se (Postfix) with SMTP id BAF15BB5DF for ; Fri, 23 Apr 2010 23:42:33 +0200 (CEST) Received: from [172.25.1.40] (c-ae06e155.166-7-64736c14.cust.bredbandsbolaget.se [85.225.6.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by system.jails.se (Postfix) with ESMTPSA id 2764DBB5D9 for ; Fri, 23 Apr 2010 23:42:33 +0200 (CEST) From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Apr 2010 23:42:37 +0200 Message-Id: <5FE5B136-ADE3-4E44-BF62-3ACD03178CB3@pean.org> To: freebsd-stable Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Apr 23 23:42:33 2010 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 4bd2144916291467915965 X-DSPAM-Factors: 27, keymap, 0.40000, keymap, 0.40000, but, 0.40000, but, 0.40000, Received*cipher+AES128, 0.40000, Mime-Version*Message, 0.40000, Date*Apr, 0.40000, What+keymap, 0.40000, org, 0.40000, of, 0.40000, Message-Id*3ACD03178CB3, 0.40000, a+macbook, 0.40000, Received*client+certificate, 0.40000, works+out, 0.40000, Date*Fri, 0.40000, use, 0.40000, macbook+working, 0.40000, Subject*FreeBSD, 0.40000, pean, 0.40000, fine, 0.40000, Message-Id*3ACD03178CB3+pean.org>, 0.40000, keymap+should, 0.40000, Received*7+64736c14.cust.bredbandsbolaget.se, 0.40000, Received*TLSv1+with, 0.40000, Received*from+[172.25.1.40], 0.40000, Date*2010+23, 0.40000, Message-Id*BF62, 0.40000 Subject: FreeBSD on MacBook Pro. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 21:43:00 -0000 Im trying to install FreeBSD on a macbook with dualboot. Everyting works = out fine but the keymap doesnt work at all.=20 I've tried alot of keymaps but everyting it produces is "mumbojumbo". = What keymap should I use to get the macbook=20 working in console? -- Peter Ankerst=E5l peter@pean.org http://www.pean.org/ From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 02:29:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E5941065672 for ; Sat, 24 Apr 2010 02:29:32 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id E76DB8FC13 for ; Sat, 24 Apr 2010 02:29:31 +0000 (UTC) Received: by qyk11 with SMTP id 11so12326829qyk.13 for ; Fri, 23 Apr 2010 19:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5NRGH5Iup/K0uqM75QaiAp0FQXwN01hFsqsOQA/XAog=; b=SRg/IKJK0hlz2zGrP5OPnjHAxJJy7/kC5MMnOgD3jPO+askHVyCbYQfHFqEAviwh62 bcGBReIrsJyMkBA5aKWHGuM6KnndUe+jzliCuMwL3y8Cp00yTjokusuHZVCG0pHzLQ1t wrcSjZwkKY/oGQ2EywmCTuUK29aMZdaGGLCnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ek5xz+GQQRADBU+usRu8FBIqVJOm60+Wj6ILOwsFNyBto1E+frdWRJPgMgiEEtTpRb D6WsBKUFic6gfZFVsHOWwmEeI/voW+v0R6roLDcnfTsg3nmmIBD3lwF2OHwDL/nJTzQ0 OPC3GlLHjN/NTbaXEZtafXAWF99BOTqxwWcTA= MIME-Version: 1.0 Received: by 10.229.212.213 with SMTP id gt21mr1141742qcb.2.1272076171150; Fri, 23 Apr 2010 19:29:31 -0700 (PDT) Received: by 10.229.233.11 with HTTP; Fri, 23 Apr 2010 19:29:31 -0700 (PDT) In-Reply-To: References: <20100418081400.GA40496@mx.techwires.net> Date: Fri, 23 Apr 2010 19:29:31 -0700 Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bernhard Schmidt , freebsd-stable@freebsd.org Subject: Re: iwn firmware instability with an up-to-date stable kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 02:29:32 -0000 2010/4/18 Olivier Cochard-Labb=E9 : > 2010/4/18 Bernhard Schmidt : >> Are you able to reproduce this on demand? As in type a few commands and >> the firmware error occurs? >> > > No, I'm not able to reproduce on demand this problem. I'm seeing similar issues on occasion with my Lenovo as well: Apr 23 19:25:24 garrcoop-fbsd kernel: firmware error log: Apr 23 19:25:24 garrcoop-fbsd kernel: error type =3D "NMI_INTERRUPT_WDG" (0x00000004) Apr 23 19:25:24 garrcoop-fbsd kernel: program counter =3D 0x0000046C Apr 23 19:25:24 garrcoop-fbsd kernel: source line =3D 0x000000D0 Apr 23 19:25:24 garrcoop-fbsd kernel: error data =3D 0x000000020703000= 0 Apr 23 19:25:24 garrcoop-fbsd kernel: branch link =3D 0x00008370000004C= 2 Apr 23 19:25:24 garrcoop-fbsd kernel: interrupt link =3D 0x000006DA000018B= 8 Apr 23 19:25:24 garrcoop-fbsd kernel: time =3D 4287402440 Apr 23 19:25:24 garrcoop-fbsd kernel: driver status: Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 0: qid=3D0 cur=3D1 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 1: qid=3D1 cur=3D0 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 2: qid=3D2 cur=3D0 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 3: qid=3D3 cur=3D36 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 4: qid=3D4 cur=3D123 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 5: qid=3D5 cur=3D0 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 6: qid=3D6 cur=3D0 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 7: qid=3D7 cur=3D0 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 8: qid=3D8 cur=3D0 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 9: qid=3D9 cur=3D0 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 10: qid=3D10 cur=3D0 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 11: qid=3D11 cur=3D0 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 12: qid=3D12 cur=3D0 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 13: qid=3D13 cur=3D0 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 14: qid=3D14 cur=3D0 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 15: qid=3D15 cur=3D0 queued= =3D0 Apr 23 19:25:24 garrcoop-fbsd kernel: rx ring: cur=3D8 This may be because the system was under load (I was installing a port shortly before the connection dropped). I'll try poking at this further because it's going to be an annoying productivity loss :/. Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 02:32:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28E501065676 for ; Sat, 24 Apr 2010 02:32:32 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id C50C58FC16 for ; Sat, 24 Apr 2010 02:32:31 +0000 (UTC) Received: by qyk11 with SMTP id 11so12329414qyk.13 for ; Fri, 23 Apr 2010 19:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oZm3LHllB/b570G/5/JuMSueNiXayFLZ6mihDjO3kGU=; b=guCZmlYByCjH+ce3n9iEYJOtyjr3Cn/RGi5QB/qruGZhNLxTFCdIj/r3Ze54PHpWOt epw8iETSinBMr/UZrOiysuKGaP09vbIFdP0hJGTNU+kTz/Tyg7hIqlzbWQKQyHdZGzXb X5d98lXHbA0+GS5LAa+R7npi5Hj7XG0kCtEug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qMvCJXRCGaa1wDw8cmxHkt1uJmJxOUyCfJTbZtQFftSVjUYSHuhQqEFCBQr4/yTiMP Mn4MVZXhuzGTKCYq+F9TI2fJqLGi/nvJ6K57ymHjmjR0OuUqMKtHp6HpMXXJ5Txwcn0u 3y9yKh1KDlo6rQSaCASIIgvuXs1if2jq4nMbM= MIME-Version: 1.0 Received: by 10.229.99.143 with SMTP id u15mr1055781qcn.105.1272076351042; Fri, 23 Apr 2010 19:32:31 -0700 (PDT) Received: by 10.229.233.11 with HTTP; Fri, 23 Apr 2010 19:32:30 -0700 (PDT) In-Reply-To: References: <20100418081400.GA40496@mx.techwires.net> Date: Fri, 23 Apr 2010 19:32:30 -0700 Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bernhard Schmidt , freebsd-stable@freebsd.org Subject: Re: iwn firmware instability with an up-to-date stable kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 02:32:32 -0000 2010/4/23 Garrett Cooper : > 2010/4/18 Olivier Cochard-Labb=E9 : >> 2010/4/18 Bernhard Schmidt : >>> Are you able to reproduce this on demand? As in type a few commands and >>> the firmware error occurs? >>> >> >> No, I'm not able to reproduce on demand this problem. > > I'm seeing similar issues on occasion with my Lenovo as well: > > Apr 23 19:25:24 garrcoop-fbsd kernel: firmware error log: > Apr 23 19:25:24 garrcoop-fbsd kernel: error type =A0 =A0 =A0=3D > "NMI_INTERRUPT_WDG" (0x00000004) > Apr 23 19:25:24 garrcoop-fbsd kernel: program counter =3D 0x0000046C > Apr 23 19:25:24 garrcoop-fbsd kernel: source line =A0 =A0 =3D 0x000000D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: error data =A0 =A0 =A0=3D 0x0000000= 207030000 > Apr 23 19:25:24 garrcoop-fbsd kernel: branch link =A0 =A0 =3D 0x000083700= 00004C2 > Apr 23 19:25:24 garrcoop-fbsd kernel: interrupt link =A0=3D 0x000006DA000= 018B8 > Apr 23 19:25:24 garrcoop-fbsd kernel: time =A0 =A0 =A0 =A0 =A0 =A0=3D 428= 7402440 > Apr 23 19:25:24 garrcoop-fbsd kernel: driver status: > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A00: qid=3D0 =A0cur=3D1 = =A0 queued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A01: qid=3D1 =A0cur=3D0 = =A0 queued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A02: qid=3D2 =A0cur=3D0 = =A0 queued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A03: qid=3D3 =A0cur=3D36 = =A0queued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A04: qid=3D4 =A0cur=3D123 = queued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A05: qid=3D5 =A0cur=3D0 = =A0 queued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A06: qid=3D6 =A0cur=3D0 = =A0 queued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A07: qid=3D7 =A0cur=3D0 = =A0 queued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A08: qid=3D8 =A0cur=3D0 = =A0 queued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A09: qid=3D9 =A0cur=3D0 = =A0 queued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 10: qid=3D10 cur=3D0 =A0 qu= eued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 11: qid=3D11 cur=3D0 =A0 qu= eued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 12: qid=3D12 cur=3D0 =A0 qu= eued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 13: qid=3D13 cur=3D0 =A0 qu= eued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 14: qid=3D14 cur=3D0 =A0 qu= eued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 15: qid=3D15 cur=3D0 =A0 qu= eued=3D0 > Apr 23 19:25:24 garrcoop-fbsd kernel: rx ring: cur=3D8 > > This may be because the system was under load (I was installing a port > shortly before the connection dropped). I'll try poking at this > further because it's going to be an annoying productivity loss :/. Sorry... should have included more helpful details. Thanks, -Garrett dmesg: iwn0: mem 0xdf2fe000-0xdf2fffff irq 17 at device 0.0 on pci3 iwn0: MIMO 2T3R, MoW1, address 00:1d:e0:7d:9f:c7 iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps pciconf -lv snippet: iwn0@pci0:3:0:0: class=3D0x028000 card=3D0x11108086 chip=3D0x42308086 rev=3D0x61 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Intel Wireless WiFi Link 4965AGN (Intel 4965AGN)' class =3D network cbb0@pci0:21:0:0: class=3D0x060700 card=3D0x20c617aa chip=3D0x04761180 rev=3D0xba hdr=3D0x02 uname -a: $ uname -a FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #0 r207006: Wed Apr 21 13:18:44 PDT 2010 root@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86 i386 From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 03:05:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1E57106564A for ; Sat, 24 Apr 2010 03:05:33 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-yw0-f193.google.com (mail-yw0-f193.google.com [209.85.211.193]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7D68FC0A for ; Sat, 24 Apr 2010 03:05:33 +0000 (UTC) Received: by ywh31 with SMTP id 31so5140107ywh.3 for ; Fri, 23 Apr 2010 20:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=lL4HXmlhG5xugGp3hkGF0oECmzJGxiEqqK+g3v+8+5k=; b=UeF5PZj22FEXDGdrrNNyfcHJb8Wcdvl6IjZYwixj5gmcBv46w/svDsmoy5mReU3BdM pXqLKCOFFvozjPFjUVpgkuWBrsYHhvM+Q+wPPKcBDWWQEpthzOmbs8EGQ9LaAQS/Bddn 0shkQyxM9IF/rWTXp7gLX7PRFf9TPvccKTGjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IrHeMTr+QHnMb9zhqEYa+cPAyFhSasimDdjfirShM0QoLP3mkXuJPutT62d8OKdBkQ UxSbIvCCcd/iZbW6aufY3eDLIPWtJ0XYhAcOLzQGiob9yGReIDrUL9Sk6T8nbaDVjANe b0hFoTaR3JP6AnwxKrNIBwQ7WLuDPjAspwOAg= MIME-Version: 1.0 Received: by 10.91.112.13 with SMTP id p13mr478232agm.29.1272078332544; Fri, 23 Apr 2010 20:05:32 -0700 (PDT) Received: by 10.231.113.36 with HTTP; Fri, 23 Apr 2010 20:05:32 -0700 (PDT) In-Reply-To: References: <20100418081400.GA40496@mx.techwires.net> Date: Fri, 23 Apr 2010 22:05:32 -0500 Message-ID: From: Brandon Gooch To: Garrett Cooper Content-Type: multipart/mixed; boundary=0016e64652882349f90484f2d1ef Cc: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= , Bernhard Schmidt , freebsd-stable@freebsd.org Subject: Re: iwn firmware instability with an up-to-date stable kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 03:05:34 -0000 --0016e64652882349f90484f2d1ef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2010/4/23 Garrett Cooper : > 2010/4/23 Garrett Cooper : >> 2010/4/18 Olivier Cochard-Labb=E9 : >>> 2010/4/18 Bernhard Schmidt : >>>> Are you able to reproduce this on demand? As in type a few commands an= d >>>> the firmware error occurs? >>>> >>> >>> No, I'm not able to reproduce on demand this problem. >> >> I'm seeing similar issues on occasion with my Lenovo as well: >> >> Apr 23 19:25:24 garrcoop-fbsd kernel: firmware error log: >> Apr 23 19:25:24 garrcoop-fbsd kernel: error type =A0 =A0 =A0=3D >> "NMI_INTERRUPT_WDG" (0x00000004) >> Apr 23 19:25:24 garrcoop-fbsd kernel: program counter =3D 0x0000046C >> Apr 23 19:25:24 garrcoop-fbsd kernel: source line =A0 =A0 =3D 0x000000D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: error data =A0 =A0 =A0=3D 0x000000= 0207030000 >> Apr 23 19:25:24 garrcoop-fbsd kernel: branch link =A0 =A0 =3D 0x00008370= 000004C2 >> Apr 23 19:25:24 garrcoop-fbsd kernel: interrupt link =A0=3D 0x000006DA00= 0018B8 >> Apr 23 19:25:24 garrcoop-fbsd kernel: time =A0 =A0 =A0 =A0 =A0 =A0=3D 42= 87402440 >> Apr 23 19:25:24 garrcoop-fbsd kernel: driver status: >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A00: qid=3D0 =A0cur=3D1 = =A0 queued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A01: qid=3D1 =A0cur=3D0 = =A0 queued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A02: qid=3D2 =A0cur=3D0 = =A0 queued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A03: qid=3D3 =A0cur=3D36 = =A0queued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A04: qid=3D4 =A0cur=3D123= queued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A05: qid=3D5 =A0cur=3D0 = =A0 queued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A06: qid=3D6 =A0cur=3D0 = =A0 queued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A07: qid=3D7 =A0cur=3D0 = =A0 queued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A08: qid=3D8 =A0cur=3D0 = =A0 queued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A09: qid=3D9 =A0cur=3D0 = =A0 queued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 10: qid=3D10 cur=3D0 =A0 q= ueued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 11: qid=3D11 cur=3D0 =A0 q= ueued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 12: qid=3D12 cur=3D0 =A0 q= ueued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 13: qid=3D13 cur=3D0 =A0 q= ueued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 14: qid=3D14 cur=3D0 =A0 q= ueued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 15: qid=3D15 cur=3D0 =A0 q= ueued=3D0 >> Apr 23 19:25:24 garrcoop-fbsd kernel: rx ring: cur=3D8 >> >> This may be because the system was under load (I was installing a port >> shortly before the connection dropped). I'll try poking at this >> further because it's going to be an annoying productivity loss :/. > > =A0 =A0Sorry... should have included more helpful details. > Thanks, > -Garrett > > dmesg: > > iwn0: mem 0xdf2fe000-0xdf2fffff irq 17 > at device 0.0 on pci3 > iwn0: MIMO 2T3R, MoW1, address 00:1d:e0:7d:9f:c7 > iwn0: [ITHREAD] > iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps > 24Mbps 36Mbps 48Mbps 54Mbps > > pciconf -lv snippet: > > iwn0@pci0:3:0:0: =A0 =A0 =A0 =A0class=3D0x028000 card=3D0x11108086 chip= =3D0x42308086 > rev=3D0x61 hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' > =A0 =A0device =A0 =A0 =3D 'Intel Wireless WiFi Link 4965AGN (Intel 4965AG= N)' > =A0 =A0class =A0 =A0 =A0=3D network > cbb0@pci0:21:0:0: =A0 =A0 =A0 class=3D0x060700 card=3D0x20c617aa chip=3D0= x04761180 > rev=3D0xba hdr=3D0x02 > > uname -a: > > $ uname -a > FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #0 > r207006: Wed Apr 21 13:18:44 PDT 2010 > root@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86 =A0i386 I'm actually looking at this right now. For me, it's actually happening when my machine stays on overnight (or for long periods of time, idle). Also, it seems to be causing the kernel to panic, although I'm now wondering if the Machine Check Architecture is somehow catching this device error and causing an exception (hw.mca.enabled=3D1)(?) -- not possible, right ??? Whatever the case, I can't seem to get the firmware error to occur with iwn(4) debugging or wlandebug options enabled, so who knows exactly what leads to this. I know Bernhard has worked hard on this driver, it's a shame that this freaky bug has bit us all now, without leaving many clues :( I've attached a textdump for posterity if nothing else :) -Brandon --0016e64652882349f90484f2d1ef Content-Type: application/octet-stream; name="iwn_nmi_interrupt_wdg_textdump.tar.2" Content-Disposition: attachment; filename="iwn_nmi_interrupt_wdg_textdump.tar.2" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g8dulxlt0 ZGRiLnR4dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADA2MDAAAAAAMAAAAAAA AAAwAAAAAAAAADE0MDAwMAAAAAAAADExMzY0MjQ2NDIzACAgNzA3NwAgAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAAAHJvb3QAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd2hlZWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABk Yj4gc2hvdyBhbGxwY3B1CgpDdXJyZW50IENQVTogMAoKY3B1aWQgICAgICAgID0gMApkeW5hbWlj IHBjcHUgICAgPSAweDY5MmQwMApjdXJ0aHJlYWQgICAgPSAweGZmZmZmZjAwMDE1MDczOTA6IHBp ZCAxMSAiaWRsZTogY3B1MCIKY3VycGNiICAgICAgID0gMHhmZmZmZmY4MDAwMDM5ZDQwCmZwY3Vy dGhyZWFkICA9IG5vbmUKaWRsZXRocmVhZCAgID0gMHhmZmZmZmYwMDAxNTA3MzkwOiBwaWQgMTEg ImlkbGU6IGNwdTAiCmN1cnBtYXAgICAgICAgICA9IDAKdHNzcCAgICAgICAgICAgID0gMHhmZmZm ZmZmZjgwODQwNTgwCmNvbW1vbnRzc3AgICAgICA9IDB4ZmZmZmZmZmY4MDg0MDU4MApyc3AwICAg ICAgICAgICAgPSAweGZmZmZmZjgwMDAwMzlkNDAKZ3MzMnAgICAgICAgICAgID0gMHhmZmZmZmZm ZjgwODNmM2I4CmxkdCAgICAgICAgICAgICA9IDB4ZmZmZmZmZmY4MDgzZjNmOAp0c3MgICAgICAg ICAgICAgPSAweGZmZmZmZmZmODA4M2YzZTgKCmNwdWlkICAgICAgICA9IDEKZHluYW1pYyBwY3B1 ICAgID0gMHhmZmZmZmY4MDdmODVlZDAwCmN1cnRocmVhZCAgICA9IDB4ZmZmZmZmMDAwMTUwNzcy MDogcGlkIDExICJpZGxlOiBjcHUxIgpjdXJwY2IgICAgICAgPSAweGZmZmZmZjgwMDAwMzRkNDAK ZnBjdXJ0aHJlYWQgID0gbm9uZQppZGxldGhyZWFkICAgPSAweGZmZmZmZjAwMDE1MDc3MjA6IHBp ZCAxMSAiaWRsZTogY3B1MSIKY3VycG1hcCAgICAgICAgID0gMAp0c3NwICAgICAgICAgICAgPSAw eGZmZmZmZmZmODA4NDA1ZTgKY29tbW9udHNzcCAgICAgID0gMHhmZmZmZmZmZjgwODQwNWU4CnJz cDAgICAgICAgICAgICA9IDB4ZmZmZmZmODAwMDAzNGQ0MApnczMycCAgICAgICAgICAgPSAweGZm ZmZmZmZmODA4M2Y0MjAKbGR0ICAgICAgICAgICAgID0gMHhmZmZmZmZmZjgwODNmNDYwCnRzcyAg ICAgICAgICAgICA9IDB4ZmZmZmZmZmY4MDgzZjQ1MAoKZGI+IGJ0CgpUcmFjaW5nIHBpZCAxMSB0 aWQgMTAwMDA0IHRkIDB4ZmZmZmZmMDAwMTUwNzM5MApybWFuX2dldF9idXNoYW5kbGUoKSBhdCBy bWFuX2dldF9idXNoYW5kbGUrMHgxCnNjaGVkX2lkbGV0ZCgpIGF0IHNjaGVkX2lkbGV0ZCsweDEy Mwpmb3JrX2V4aXQoKSBhdCBmb3JrX2V4aXQrMHgxMTgKZm9ya190cmFtcG9saW5lKCkgYXQgZm9y a190cmFtcG9saW5lKzB4ZQotLS0gdHJhcCAwLCByaXAgPSAwLCByc3AgPSAweGZmZmZmZjgwMDAw MzlkMzAsIHJicCA9IDAgLS0tCmRiPiBwcwoKICBwaWQgIHBwaWQgIHBncnAgICB1aWQgICBzdGF0 ZSAgIHdtZXNnICAgICAgICAgd2NoYW4gICAgICAgIGNtZAo1MTAyNiA1MTAyNCA1MTAyNiAgMTAw MSAgU3MrICAgICB0dHlpbiAgICAweGZmZmZmZjAwMDE2N2EwYTggdGNzaAo1MTAyNCAgMTU1OCAg MTU1OCAgMTAwMSAgUyAgICAgICBzZWxlY3QgICAweGZmZmZmZjAwNjQ3MjljNDAgeHRlcm0KNDUx NDAgICAgIDEgNDUxMzkgIDEwMDEgIFMgICAgICAgKHRocmVhZGVkKSAgICAgICAgICAgICAgICAg IFZCb3hTVkMKMTAwMjk3ICAgICAgICAgICAgICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhmZmZm ZmYwMDA0ODI1NTgwIFZCb3hTVkMKMTAwMjk2ICAgICAgICAgICAgICAgICAgIFMgICAgICAgdWNv bmQgICAgMHhmZmZmZmYwMGE4ZmJiMTAwIFZCb3hTVkMKMTAwMjk1ICAgICAgICAgICAgICAgICAg IFMgICAgICAgdWNvbmQgICAgMHhmZmZmZmYwMTIwYTU3NjgwIFZCb3hTVkMKMTAwMjk0ICAgICAg ICAgICAgICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhmZmZmZmYwMTIwYTViNjAwIFZCb3hTVkMK MTAwMjkzICAgICAgICAgICAgICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhmZmZmZmYwMDA0Yjc0 NjgwIFZCb3hTVkMKMTAwMjkyICAgICAgICAgICAgICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhm ZmZmZmYwMGE4ZjIwMTAwIFZCb3hTVkMKMTAwMjkxICAgICAgICAgICAgICAgICAgIFMgICAgICAg c2VsZWN0ICAgMHhmZmZmZmYwMTI2MGJiOGMwIFZCb3hTVkMKMTAwMjU3ICAgICAgICAgICAgICAg ICAgIFMgICAgICAgdWNvbmQgICAgMHhmZmZmZmYwMGE4ZmJiMjAwIGluaXRpYWwgdGhyZWFkCjQ1 MTM3IDQ1MDc5ICAxNTU4ICAxMDAxICBTICAgICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDBhODIxYzY0 MCBpbml0aWFsIHRocmVhZAo0NTA3OSAgMTU1OCAgMTU1OCAgMTAwMSAgUyAgICAgICAodGhyZWFk ZWQpICAgICAgICAgICAgICAgICAgVmlydHVhbEJveAoxMDAyODkgICAgICAgICAgICAgICAgICAg UyAgICAgICB1Y29uZCAgICAweGZmZmZmZjAxMjBhNWI1MDAgVmlydHVhbEJveAoxMDAyMjggICAg ICAgICAgICAgICAgICAgUyAgICAgICBzZWxlY3QgICAweGZmZmZmZjAxMjYxZjExYzAgVmlydHVh bEJveAoxMDAyMjMgICAgICAgICAgICAgICAgICAgUyAgICAgICB3YWl0ICAgICAweGZmZmZmZjAx MjA1ODY0NjAgVmlydHVhbEJveAoxMDAyMzAgICAgICAgICAgICAgICAgICAgUyAgICAgICBzZWxl Y3QgICAweGZmZmZmZjAwMGVjNzA1NDAgaW5pdGlhbCB0aHJlYWQKNDQ3MzAgICAgIDAgICAgIDAg ICAgIDAgIERMICAgICAgSVBSVCBFdmUgMHhmZmZmZmYwMDM2OThhMjUwIFtUSU1FUl0KNDE4MzIg NDE4MjggNDE4MzIgIDEwMDEgIFNzKyAgICAgdHR5aW4gICAgMHhmZmZmZmYwMDA0NWM3OGE4IHRj c2gKNDE4MjggIDE1NTggIDE1NTggIDEwMDEgIFMgICAgICAgc2VsZWN0ICAgMHhmZmZmZmYwMDY0 MmQxN2MwIHh0ZXJtCjkwNzk1IDkwNzc3ICAxNTU4ICAxMDAxICBTICAgICAgIHNlbGVjdCAgIDB4 ZmZmZmZmMDAwZWZmZTNjMCBucHZpZXdlci5iaW4KOTA3NzcgOTA3NzMgIDE1NTggIDEwMDEgIFMg ICAgICAgKHRocmVhZGVkKSAgICAgICAgICAgICAgICAgIGZpcmVmb3gtYmluCjEwMDI1OSAgICAg ICAgICAgICAgICAgICBTICAgICAgIHVjb25kICAgIDB4ZmZmZmZmMDEyMDM4YTAwMCBmaXJlZm94 LWJpbgoxMDAyOTAgICAgICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAweGZmZmZmZjAw MDRjMzQ4ODAgZmlyZWZveC1iaW4KMTAwMjQxICAgICAgICAgICAgICAgICAgIFMgICAgICAgdWNv bmQgICAgMHhmZmZmZmYwMTIwYWY5MDAwIGZpcmVmb3gtYmluCjEwMDIyNiAgICAgICAgICAgICAg ICAgICBTICAgICAgIHVjb25kICAgIDB4ZmZmZmZmMDEyMGFlMGM4MCBmaXJlZm94LWJpbgoxMDAy MjQgICAgICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAweGZmZmZmZjAwMDRkN2E2MDAg ZmlyZWZveC1iaW4KMTAwMjIxICAgICAgICAgICAgICAgICAgIFMgICAgICAgdWNvbmQgICAgMHhm ZmZmZmYwMDVjZTA3YjAwIGZpcmVmb3gtYmluCjEwMDIyMCAgICAgICAgICAgICAgICAgICBTICAg ICAgIHVjb25kICAgIDB4ZmZmZmZmMDA1Y2IzZGE4MCBmaXJlZm94LWJpbgoxMDAyMTkgICAgICAg ICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAweGZmZmZmZjAwMDRlMDQ0ODAgZmlyZWZveC1i aW4KMTAwMjE4ICAgICAgICAgICAgICAgICAgIFMgICAgICAgc2VsZWN0ICAgMHhmZmZmZmYwMDY0 NzE4ZGMwIGZpcmVmb3gtYmluCjEwMDIyNyAgICAgICAgICAgICAgICAgICBTICAgICAgIHNlbGVj dCAgIDB4ZmZmZmZmMDA5MzVmOTJjMCBpbml0aWFsIHRocmVhZAo5MDc3MyA5MDc2MSAgMTU1OCAg MTAwMSAgU1cgICAgICB3YWl0ICAgICAweGZmZmZmZjAwMDRjMTcwMDAgc2gKOTA3NjEgIDE1NTgg IDE1NTggIDEwMDEgIFNXICAgICAgd2FpdCAgICAgMHhmZmZmZmYwMGE4ZTlmMDAwIHNoCjkwNzE5 IDU0NTQ2IDkwNzE5ICAxMDAxICBTcysgICAgIHR0eWluICAgIDB4ZmZmZmZmMDAwNDRjMmNhOCB0 Y3NoCjU5Nzk3IDU0NTQ2IDU5Nzk3ICAxMDAxICBTcysgICAgIHR0eWluICAgIDB4ZmZmZmZmMDAw NDQ5MWNhOCB0Y3NoCjU5Nzk2IDU5NzYyIDU5Nzk2ICAxMDAxICBTVysgICAgIGtxcmVhZCAgIDB4 ZmZmZmZmMDA2NjE1NzcwMCBpbml0aWFsIHRocmVhZAo1OTc2MiA1OTc2MCA1OTc2MiAgMTAwMSAg U1dzKyAgICBwYXVzZSAgICAweGZmZmZmZjAxMjBhYmUwYTAgdGNzaAo1OTc2MCAgMTU1OCAgMTU1 OCAgMTAwMSAgUyAgICAgICBzZWxlY3QgICAweGZmZmZmZjAwNWY0NGJkNDAgeHRlcm0KNTk2NDgg NTk2NDMgNTY5MjMgIDEwMDEgIFMrICAgICAgdHR5aW4gICAgMHhmZmZmZmYwMDAyODQyMGE4IG1v cmUKNTk2NDMgNTY5MjMgNTY5MjMgIDEwMDEgIFNXKyAgICAgd2FpdCAgICAgMHhmZmZmZmYwMTIw YWJjOGMwIHNoCjU4MDI3IDU3Nzk2IDU4MDI3ICAxMDAxICBTKyAgICAgIHR0eWluICAgIDB4ZmZm ZmZmMDAwMTY1NmNhOCBzeXN0YXQKNTc3OTYgNTc3OTQgNTc3OTYgIDEwMDEgIFNXcysgICAgcGF1 c2UgICAgMHhmZmZmZmYwMTIwYWJhMGEwIHRjc2gKNTc3OTQgIDE1NTggIDE1NTggIDEwMDEgIFMg ICAgICAgc2VsZWN0ICAgMHhmZmZmZmYwMTIwMGFmNmMwIHh0ZXJtCjU2OTIzIDU0NTQ3IDU2OTIz ICAxMDAxICBTVysgICAgIHdhaXQgICAgIDB4ZmZmZmZmMDEyMDU4MjAwMCBtYW4KNTQ1NDcgNTQ1 NDYgNTQ1NDcgIDEwMDEgIFNXcysgICAgcGF1c2UgICAgMHhmZmZmZmYwMTIwNTgyOTYwIHRjc2gK NTQ1NDYgICAgIDEgNTQ1NDYgIDEwMDEgIFNzICAgICAga3FyZWFkICAgMHhmZmZmZmYwMDY2ODRi OTAwIHRtdXgKNDQxNjYgNDQxNjMgNDQxNjYgIDEwMDEgIFNzKyAgICAgdHR5aW4gICAgMHhmZmZm ZmYwMDA0OGRmY2E4IHRjc2gKNDQxNjMgIDE1NTggIDE1NTggIDEwMDEgIFMgICAgICAgc2VsZWN0 ICAgMHhmZmZmZmYwMDY0MjhkNjQwIHh0ZXJtCiAxODY1ICAgICAxICAxODY1ICAgIDY1ICBTcyAg ICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDBhOGMwMTdjMCBkaGNsaWVudAogMTgyMSAgICAgMSAgMTgy MSAgICAgMCAgU3MgICAgICBzZWxlY3QgICAweGZmZmZmZjAxMjAxY2M0NDAgZGhjbGllbnQKIDE3 NDAgIDE1MTIgIDE1MDggICAgIDAgIFNXICAgICAga3FyZWFkICAgMHhmZmZmZmYwMDA0YzFhNzAw IGluaXRpYWwgdGhyZWFkCiAxNzIyICAgICAxICAxNzIyICAgICAwICBTcyAgICAgIHNlbGVjdCAg IDB4ZmZmZmZmMDBhOGU4OTc0MCBtb3VzZWQKIDE1ODMgICAgIDEgIDE1ODMgIDEwMDEgIFNzICAg ICAgc2VsZWN0ICAgMHhmZmZmZmYwMDA0YzUwMWMwIGRidXMtZGFlbW9uCiAxNTgyICAgICAxICAx NTU4ICAxMDAxICBTICAgICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDBhOGMwMTI0MCBkYnVzLWxhdW5j aAogMTU3NiAgICAgMSAgMTU1OCAgMTAwMSAgRCAgICAgICBhY3Bpc2xwICAweGZmZmZmZmZmODA3 ZDJiMjQgY29ua3kKIDE1NzMgICAgIDEgIDE1NzMgIDEwMDEgIFNzICAgICAgbmFuc2xwICAgMHhm ZmZmZmZmZjgwN2QyZTQ4IHN5bmRhZW1vbgogMTU1OCAgMTU0OSAgMTU1OCAgMTAwMSAgU3MgICAg ICBzZWxlY3QgICAweGZmZmZmZjAwMDRjNGY5YzAgb3BlbmJveAogMTU0OSAgMTUwMSAgMTU0OSAg ICAgMCAgU1dzICAgICB3YWl0ICAgICAweGZmZmZmZjAwMDRhY2QwMDAgeGRtCiAxNTE3ICAxNTEy ICAxNTA4ICAgICAwICBTVyAgICAgIGtxcmVhZCAgIDB4ZmZmZmZmMDBhODJkMzUwMCBpbml0aWFs IHRocmVhZAogMTUxMiAgMTUwOCAgMTUwOCAgICAgMCAgUyAgICAgICBzZWxlY3QgICAweGZmZmZm ZjAwYTgyOWY3YzAgaW5pdGlhbCB0aHJlYWQKIDE1MTEgICAgIDEgIDE1MTEgICAgIDAgIFNzICAg ICAgKHRocmVhZGVkKSAgICAgICAgICAgICAgICAgIGNvbnNvbGUta2l0LWRhZW1vbgoxMDAxODkg ICAgICAgICAgICAgICAgICAgUyAgICAgICB3YWl0dnQgICAweGZmZmZmZmZmODA3Y2U2YTAgY29u c29sZS1raXQtZGFlbW9uCjEwMDIwMyAgICAgICAgICAgICAgICAgICBTICAgICAgIHdhaXR2dCAg IDB4ZmZmZmZmZmY4MDdjZTZkOCBjb25zb2xlLWtpdC1kYWVtb24KMTAwMjAyICAgICAgICAgICAg ICAgICAgIFMgICAgICAgd2FpdHZ0ICAgMHhmZmZmZmZmZjgwN2NlNmQwIGNvbnNvbGUta2l0LWRh ZW1vbgoxMDAyMDEgICAgICAgICAgICAgICAgICAgUyAgICAgICB3YWl0dnQgICAweGZmZmZmZmZm ODA3Y2U2YzggY29uc29sZS1raXQtZGFlbW9uCjEwMDIwMCAgICAgICAgICAgICAgICAgICBTICAg ICAgIHdhaXR2dCAgIDB4ZmZmZmZmZmY4MDdjZTZjMCBjb25zb2xlLWtpdC1kYWVtb24KMTAwMTk5 ICAgICAgICAgICAgICAgICAgIFMgICAgICAgd2FpdHZ0ICAgMHhmZmZmZmZmZjgwN2NlNmI4IGNv bnNvbGUta2l0LWRhZW1vbgoxMDAxOTggICAgICAgICAgICAgICAgICAgUyAgICAgICB3YWl0dnQg ICAweGZmZmZmZmZmODA3Y2U2YjAgY29uc29sZS1raXQtZGFlbW9uCjEwMDE5NyAgICAgICAgICAg ICAgICAgICBTICAgICAgIHdhaXR2dCAgIDB4ZmZmZmZmZmY4MDdjZTZhOCBjb25zb2xlLWtpdC1k YWVtb24KMTAwMTk2ICAgICAgICAgICAgICAgICAgIFMgICAgICAgd2FpdHZ0ICAgMHhmZmZmZmZm ZjgwN2NlNjk4IGNvbnNvbGUta2l0LWRhZW1vbgoxMDAxOTUgICAgICAgICAgICAgICAgICAgUyAg ICAgICB3YWl0dnQgICAweGZmZmZmZmZmODA3Y2U2OTAgY29uc29sZS1raXQtZGFlbW9uCjEwMDE5 NCAgICAgICAgICAgICAgICAgICBTICAgICAgIHdhaXR2dCAgIDB4ZmZmZmZmZmY4MDdjZTY4OCBj b25zb2xlLWtpdC1kYWVtb24KMTAwMTkzICAgICAgICAgICAgICAgICAgIFMgICAgICAgd2FpdHZ0 ICAgMHhmZmZmZmZmZjgwN2NlNjgwIGNvbnNvbGUta2l0LWRhZW1vbgoxMDAxOTIgICAgICAgICAg ICAgICAgICAgUyAgICAgICB3YWl0dnQgICAweGZmZmZmZmZmODA3Y2U2NzggY29uc29sZS1raXQt ZGFlbW9uCjEwMDE5MSAgICAgICAgICAgICAgICAgICBTICAgICAgIHdhaXR2dCAgIDB4ZmZmZmZm ZmY4MDdjZTY3MCBjb25zb2xlLWtpdC1kYWVtb24KMTAwMTkwICAgICAgICAgICAgICAgICAgIFMg ICAgICAgd2FpdHZ0ICAgMHhmZmZmZmZmZjgwN2NlNjY4IGNvbnNvbGUta2l0LWRhZW1vbgoxMDAx ODggICAgICAgICAgICAgICAgICAgUyAgICAgICB1Y29uZCAgICAweGZmZmZmZjAwMDRiNWE1MDAg Y29uc29sZS1raXQtZGFlbW9uCjEwMDE2OCAgICAgICAgICAgICAgICAgICBTICAgICAgIHNlbGVj dCAgIDB4ZmZmZmZmMDBhODI5ZTA0MCBjb25zb2xlLWtpdC1kYWVtb24KIDE1MDggICAgIDEgIDE1 MDggICA1NjAgIFNzICAgICAgc2VsZWN0ICAgMHhmZmZmZmYwMGE4MjcwMjQwIGhhbGQKIDE1MDMg IDE1MDEgIDE1MDMgICAgIDAgIFNzICAgICAgc2VsZWN0ICAgMHhmZmZmZmYwMGE4Y2M2ODQwIGlu aXRpYWwgdGhyZWFkCiAxNTAxICAgICAxICAgICAxICAgICAwICBTVyAgICAgIHBhdXNlICAgIDB4 ZmZmZmZmMDAwNGYwNzk2MCB4ZG0KIDE1MDAgICAgIDEgIDE1MDAgICAgIDAgIFNzKyAgICAgdHR5 aW4gICAgMHhmZmZmZmYwMDA0NGIwOGE4IGdldHR5CiAxNDk5ICAgICAxICAxNDk5ICAgICAwICBT cysgICAgIHR0eWluICAgIDB4ZmZmZmZmMDAwNDRiMThhOCBnZXR0eQogMTQ5OCAgICAgMSAgMTQ5 OCAgICAgMCAgU3MrICAgICB0dHlpbiAgICAweGZmZmZmZjAwMDQ0YjE0YTggZ2V0dHkKIDE0OTcg ICAgIDEgIDE0OTcgICAgIDAgIFNzKyAgICAgdHR5aW4gICAgMHhmZmZmZmYwMDA0NGFlMGE4IGdl dHR5CiAxNDk2ICAgICAxICAxNDk2ICAgICAwICBTcysgICAgIHR0eWluICAgIDB4ZmZmZmZmMDAw NDRhZGNhOCBnZXR0eQogMTQ5NSAgICAgMSAgMTQ5NSAgICAgMCAgU3MrICAgICB0dHlpbiAgICAw eGZmZmZmZjAwMDQ0YWVjYTggZ2V0dHkKIDE0OTQgICAgIDEgIDE0OTQgICAgIDAgIFNzKyAgICAg dHR5aW4gICAgMHhmZmZmZmYwMDA0NGFlOGE4IGdldHR5CiAxNDkzICAgICAxICAxNDkzICAgICAw ICBTcysgICAgIHR0eWluICAgIDB4ZmZmZmZmMDAwNDRhZDhhOCBnZXR0eQogMTQyOSAgICAgMSAg MTQyOSAgICAgMCAgU3MgICAgICBuYW5zbHAgICAweGZmZmZmZmZmODA3ZDJlNDggY3JvbgogMTQy MiAgICAgMSAgMTQyMiAgICAyNSAgU3MgICAgICBwYXVzZSAgICAweGZmZmZmZjAwMDRjMTc1MDAg c2VuZG1haWwKIDE0MTggICAgIDEgIDE0MTggICAgIDAgIFNzICAgICAgc2VsZWN0ICAgMHhmZmZm ZmYwMDA0ZjI4ZGMwIHNlbmRtYWlsCiAxNDEwICAgICAxICAxNDEwICAgICAwICBTcyAgICAgIHNl bGVjdCAgIDB4ZmZmZmZmMDAwNGYyODJjMCBzc2hkCiAxMzcxICAgICAxICAxMzcxICAgICAwICBT cyAgICAgIHNlbGVjdCAgIDB4ZmZmZmZmMDAwNGYyOGQ0MCBwb3dlcmQKIDEyNTYgICAgIDEgIDEy NTYgICA1NTYgIFNzICAgICAgc2VsZWN0ICAgMHhmZmZmZmYwMDA0ZWNmMTQwIGRidXMtZGFlbW9u CiAxMjE3ICAxMjE2ICAxMjE2ICAgICAwICBTICAgICAgICh0aHJlYWRlZCkgICAgICAgICAgICAg ICAgICBuZnNkCjEwMDE3NSAgICAgICAgICAgICAgICAgICBTICAgICAgIHJwY3N2YyAgIDB4ZmZm ZmZmMDAwNGJjNzQyMCBuZnNkOiBzZXJ2aWNlCjEwMDE3NCAgICAgICAgICAgICAgICAgICBTICAg ICAgIHJwY3N2YyAgIDB4ZmZmZmZmMDAwNGU5MDMyMCBuZnNkOiBzZXJ2aWNlCjEwMDE3MyAgICAg ICAgICAgICAgICAgICBTICAgICAgIHJwY3N2YyAgIDB4ZmZmZmZmMDAwNGUwODkyMCBuZnNkOiBz ZXJ2aWNlCjEwMDE2MSAgICAgICAgICAgICAgICAgICBTICAgICAgIHJwY3N2YyAgIDB4ZmZmZmZm MDAwNGU5MDNhMCBuZnNkOiBtYXN0ZXIKIDEyMTYgICAgIDEgIDEyMTYgICAgIDAgIFNzICAgICAg c2VsZWN0ICAgMHhmZmZmZmYwMDA0ZThmOWMwIG5mc2QKIDExMzUgICAgIDEgIDExMzUgICAgIDAg IFNzICAgICAgc2VsZWN0ICAgMHhmZmZmZmYwMDA0ZThmN2MwIGFtZAogMTEwOCAgICAgMSAgMTEw OCAgICAgMCAgU3MgICAgICBzZWxlY3QgICAweGZmZmZmZjAwMDRlNDRjYzAgcnBjYmluZAogMTA4 MyAgICAgMSAgMTA4MyAgICAgMCAgU3MgICAgICBzZWxlY3QgICAweGZmZmZmZjAwMDRlNDRlNDAg c3lzbG9nZAogIDg2MyAgICAgMSAgIDg2MyAgICAgMCAgU3MgICAgICBzZWxlY3QgICAweGZmZmZm ZjAwMDRjNGY3NDAgZGV2ZAogIDQ3MSAgICAgMSAgIDQ3MSAgICAgMCAgU3MgICAgICBzZWxlY3Qg ICAweGZmZmZmZjAwMDRjMzBjNDAgd3BhX3N1cHBsaWNhbnQKICAgMjEgICAgIDAgICAgIDAgICAg IDAgIERMICAgICAgZmxvd2NsZWEgMHhmZmZmZmZmZjgwN2Y2ZmYwIFtmbG93Y2xlYW5lcl0KICAg MjAgICAgIDAgICAgIDAgICAgIDAgIERMICAgICAgc2RmbHVzaCAgMHhmZmZmZmZmZjgwODA2MTE4 IFtzb2Z0ZGVwZmx1c2hdCiAgIDE5ICAgICAwICAgICAwICAgICAwICBETCAgICAgIHZscnV3dCAg IDB4ZmZmZmZmMDAwNDU2NTAwMCBbdm5scnVdCiAgIDE4ICAgICAwICAgICAwICAgICAwICBETCAg ICAgIHBzbGVlcCAgIDB4ZmZmZmZmZmY4MDdmNjhlOCBbYnVmZGFlbW9uXQogICAgOSAgICAgMCAg ICAgMCAgICAgMCAgREwgICAgICBwZ3plcm8gICAweGZmZmZmZmZmODA4MDdlNGMgW3BhZ2V6ZXJv XQogICAgOCAgICAgMCAgICAgMCAgICAgMCAgREwgICAgICBwc2xlZXAgICAweGZmZmZmZmZmODA4 MDcxZTggW3ZtZGFlbW9uXQogICAgNyAgICAgMCAgICAgMCAgICAgMCAgREwgICAgICBwc2xlZXAg ICAweGZmZmZmZmZmODA4MDcxYWMgW3BhZ2VkYWVtb25dCiAgICA2ICAgICAwICAgICAwICAgICAw ICBETCAgICAgIGNjYl9zY2FuIDB4ZmZmZmZmZmY4MDdiODE2MCBbeHB0X3RocmRdCiAgICA1ICAg ICAwICAgICAwICAgICAwICBETCAgICAgICh0aHJlYWRlZCkgICAgICAgICAgICAgICAgICBbemZz a2Vybl0KMTAwMTIyICAgICAgICAgICAgICAgICAgIEQgICAgICAgdHgtPnR4X3MgMHhmZmZmZmYw MDA0NWFmZTQwIFt0eGdfdGhyZWFkX2VudGVyXQoxMDAxMjEgICAgICAgICAgICAgICAgICAgRCAg ICAgICB0eC0+dHhfcSAweGZmZmZmZjAwMDQ1YWZlNjAgW3R4Z190aHJlYWRfZW50ZXJdCjEwMDEx OSAgICAgICAgICAgICAgICAgICBEICAgICAgIHZnZW9tOmlvIDB4ZmZmZmZmMDAwNDVjMTU5MCBb dmRldiBncHQvZGlzazFdCjEwMDA3NCAgICAgICAgICAgICAgICAgICBEICAgICAgIGwyYXJjX2Zl IDB4ZmZmZmZmZmY4MGIxN2JjMCBbbDJhcmNfZmVlZF90aHJlYWRdCjEwMDA3MyAgICAgICAgICAg ICAgICAgICBEICAgICAgIGFyY19yZWNsIDB4ZmZmZmZmZmY4MGIwN2QyMCBbYXJjX3JlY2xhaW1f dGhyZWFkXQogICAxNiAgICAgMCAgICAgMCAgICAgMCAgREwgICAgICB0enBvbGwgICAweGZmZmZm ZmZmODA3YmM4OTAgW2FjcGlfdGhlcm1hbF0KICAgMTUgICAgIDAgICAgIDAgICAgIDAgIERMICAg ICAgKHRocmVhZGVkKSAgICAgICAgICAgICAgICAgIFt1c2JdCjEwMDA2NiAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDMzNmRkMCBbdXNidXM3XQoxMDAwNjUg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAzMzZkNzggW3Vz YnVzN10KMTAwMDY0ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4 MDAwMzM2ZDIwIFt1c2J1czddCjEwMDA2MyAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAg ICAgIDB4ZmZmZmZmODAwMDMzNmNjOCBbdXNidXM3XQoxMDAwNjIgICAgICAgICAgICAgICAgICAg RCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAzMmRlZjAgW3VzYnVzNl0KMTAwMDYxICAgICAg ICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwMzJkZTk4IFt1c2J1czZd CjEwMDA2MCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDMy ZGU0MCBbdXNidXM2XQoxMDAwNTkgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAw eGZmZmZmZjgwMDAzMmRkZTggW3VzYnVzNl0KMTAwMDU3ICAgICAgICAgICAgICAgICAgIEQgICAg ICAgLSAgICAgICAgMHhmZmZmZmY4MDAwMzI0ZWYwIFt1c2J1czVdCjEwMDA1NiAgICAgICAgICAg ICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDMyNGU5OCBbdXNidXM1XQoxMDAw NTUgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAzMjRlNDAg W3VzYnVzNV0KMTAwMDU0ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZm ZmY4MDAwMzI0ZGU4IFt1c2J1czVdCjEwMDA1MyAgICAgICAgICAgICAgICAgICBEICAgICAgIC0g ICAgICAgIDB4ZmZmZmZmODAwMDMxYmVmMCBbdXNidXM0XQoxMDAwNTIgICAgICAgICAgICAgICAg ICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAzMWJlOTggW3VzYnVzNF0KMTAwMDUxICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwMzFiZTQwIFt1c2J1 czRdCjEwMDA1MCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAw MDMxYmRlOCBbdXNidXM0XQoxMDAwNDQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAg ICAweGZmZmZmZjgwMDAyZDZkZDAgW3VzYnVzM10KMTAwMDQzICAgICAgICAgICAgICAgICAgIEQg ICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwMmQ2ZDc4IFt1c2J1czNdCjEwMDA0MiAgICAgICAg ICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDJkNmQyMCBbdXNidXMzXQox MDAwNDEgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAyZDZj YzggW3VzYnVzM10KMTAwMDQwICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhm ZmZmZmY4MDAwMmNkZWYwIFt1c2J1czJdCjEwMDAzOSAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmODAwMDJjZGU5OCBbdXNidXMyXQoxMDAwMzggICAgICAgICAgICAg ICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAyY2RlNDAgW3VzYnVzMl0KMTAwMDM3 ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwMmNkZGU4IFt1 c2J1czJdCjEwMDAzNSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZm ODAwMDJjNGVmMCBbdXNidXMxXQoxMDAwMzQgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAg ICAgICAweGZmZmZmZjgwMDAyYzRlOTggW3VzYnVzMV0KMTAwMDMzICAgICAgICAgICAgICAgICAg IEQgICAgICAgLSAgICAgICAgMHhmZmZmZmY4MDAwMmM0ZTQwIFt1c2J1czFdCjEwMDAzMiAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDJjNGRlOCBbdXNidXMx XQoxMDAwMzAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAy YmJlZjAgW3VzYnVzMF0KMTAwMDI5ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAg MHhmZmZmZmY4MDAwMmJiZTk4IFt1c2J1czBdCjEwMDAyOCAgICAgICAgICAgICAgICAgICBEICAg ICAgIC0gICAgICAgIDB4ZmZmZmZmODAwMDJiYmU0MCBbdXNidXMwXQoxMDAwMjcgICAgICAgICAg ICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjgwMDAyYmJkZTggW3VzYnVzMF0KICAg MTQgICAgIDAgICAgIDAgICAgIDAgIERMICAgICAgLSAgICAgICAgMHhmZmZmZmZmZjgwN2QyYjI0 IFt5YXJyb3ddCiAgICA0ICAgICAwICAgICAwICAgICAwICBETCAgICAgIC0gICAgICAgIDB4ZmZm ZmZmZmY4MDdjZjIwOCBbZ19kb3duXQogICAgMyAgICAgMCAgICAgMCAgICAgMCAgREwgICAgICAt ICAgICAgICAweGZmZmZmZmZmODA3Y2YyMDAgW2dfdXBdCiAgICAyICAgICAwICAgICAwICAgICAw ICBETCAgICAgIC0gICAgICAgIDB4ZmZmZmZmZmY4MDdjZjFmMCBbZ19ldmVudF0KICAgMTMgICAg IDAgICAgIDAgICAgIDAgIERMICAgICAgKHRocmVhZGVkKSAgICAgICAgICAgICAgICAgIFtuZ19x dWV1ZV0KMTAwMDEwICAgICAgICAgICAgICAgICAgIEQgICAgICAgc2xlZXAgICAgMHhmZmZmZmZm ZjgwYzM5ZWIwIFtuZ19xdWV1ZTFdCjEwMDAwOSAgICAgICAgICAgICAgICAgICBEICAgICAgIHNs ZWVwICAgIDB4ZmZmZmZmZmY4MGMzOWViMCBbbmdfcXVldWUwXQogICAxMiAgICAgMCAgICAgMCAg ICAgMCAgV0wgICAgICAodGhyZWFkZWQpICAgICAgICAgICAgICAgICAgW2ludHJdCjEwMDIwNCAg ICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbaXJx MjU2Ol0KMTAwMDcwICAgICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtpcnExMjogcHNtMF0KMTAwMDY5ICAgICAgICAgICAgICAgICAgIEkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtpcnExOiBhdGtiZDBdCjEwMDA2NyAgICAgICAg ICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbaXJxMjYwOiBh aGNpMF0KMTAwMDU4ICAgICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtpcnExODogdWhjaTVdCjEwMDA0OSAgICAgICAgICAgICAgICAgICBJICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbaXJxMjM6IHVoY2kzIGVoY2kxXQoxMDAwNDcg ICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2ly cTI1ODogaXduMF0KMTAwMDQ1ICAgICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtpcnEyNTc6IGhkYWMwXQoxMDAwMzYgICAgICAgICAgICAgICAgICAg SSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2lycTE5OiB1aGNpMiBlaGNpMCtd CjEwMDAzMSAgICAgICAgICAgICAgICAgICBJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbaXJxMjE6IHVoY2kxXQoxMDAwMjYgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW2lycTE2OiB1aGNpMF0KMTAwMDI1ICAgICAgICAgICAg ICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtpcnE5OiBhY3BpMF0K MTAwMDI0ICAgICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFtzd2kyOiBjYW1iaW9dCjEwMDAxOSAgICAgICAgICAgICAgICAgICBJICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbc3dpNjogdGFzayBxdWV1ZV0KMTAwMDE4ICAgICAgICAg ICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtzd2k2OiBHaWFu dCB0YXNrcV0KMTAwMDE2ICAgICAgICAgICAgICAgICAgIEkgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtzd2k1OiArXQoxMDAwMDggICAgICAgICAgICAgICAgICAgSSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW3N3aTE6IG5ldGlzciAwXQoxMDAwMDcgICAgICAg ICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW3N3aTM6IHZt XQoxMDAwMDYgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW3N3aTQ6IGNsb2NrXQoxMDAwMDUgICAgICAgICAgICAgICAgICAgSSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW3N3aTQ6IGNsb2NrXQogICAxMSAgICAgMCAgICAgMCAg ICAgMCAgUkwgICAgICAodGhyZWFkZWQpICAgICAgICAgICAgICAgICAgW2lkbGVdCjEwMDAwNCAg ICAgICAgICAgICAgICAgICBSdW4gICAgIENQVSAwICAgICAgICAgICAgICAgICAgICAgICBbaWRs ZTogY3B1MF0KMTAwMDAzICAgICAgICAgICAgICAgICAgIFJ1biAgICAgQ1BVIDEgICAgICAgICAg ICAgICAgICAgICAgIFtpZGxlOiBjcHUxXQogICAgMSAgICAgMCAgICAgMSAgICAgMCAgU0xzICAg ICB3YWl0ICAgICAweGZmZmZmZjAwMDE1MDM4YzAgW2luaXRdCiAgIDEwICAgICAwICAgICAwICAg ICAwICBETCAgICAgIGF1ZGl0X3dvIDB4ZmZmZmZmZmY4MDgwNTQ1MCBbYXVkaXRdCiAgICAwICAg ICAwICAgICAwICAgICAwICBETHMgICAgICh0aHJlYWRlZCkgICAgICAgICAgICAgICAgICBba2Vy bmVsXQoxMDAxNzIgICAgICAgICAgICAgICAgICAgRCAgICAgICBzeW5jZXIgICAweGZmZmZmZjAw MDRhYzk5MDAgW3N5bmNlciBuZnM6Ml0KMTAwMTcxICAgICAgICAgICAgICAgICAgIEQgICAgICAg c3luY2VyICAgMHhmZmZmZmYwMDA0NWI2MTAwIFtzeW5jZXIgbmZzOjJdCjEwMDE0OSAgICAgICAg ICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNGI2NWIwMCBbemlsX2NsZWFu XQoxMDAxNDggICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDRi NjYxODAgW3ppbF9jbGVhbl0KMTAwMTQ3ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAg ICAgMHhmZmZmZmYwMDA0YjY2NzAwIFt6aWxfY2xlYW5dCjEwMDE0NiAgICAgICAgICAgICAgICAg ICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNGIxOGUwMCBbemlsX2NsZWFuXQoxMDAxNDUg ICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDRiMmQ1MDAgW3pp bF9jbGVhbl0KMTAwMTQ0ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZm ZmYwMDA0YjJkYTgwIFt6aWxfY2xlYW5dCjEwMDE0MyAgICAgICAgICAgICAgICAgICBEICAgICAg IC0gICAgICAgIDB4ZmZmZmZmMDAwNGIyZWIwMCBbemlsX2NsZWFuXQoxMDAxNDIgICAgICAgICAg ICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDRiMmYyODAgW3ppbF9jbGVhbl0K MTAwMTQxICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA0YjMw NDgwIFt6aWxfY2xlYW5dCjEwMDE0MCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAg IDB4ZmZmZmZmMDAwNGIzMGEwMCBbemlsX2NsZWFuXQoxMDAxMzkgICAgICAgICAgICAgICAgICAg RCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDRiMTc3MDAgW3ppbF9jbGVhbl0KMTAwMTM4ICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA0YjE4MDAwIFt6aWxf Y2xlYW5dCjEwMDEzNyAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZm MDAwNDg3N2QwMCBbemlsX2NsZWFuXQoxMDAxMzYgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwMDQ4NzgxMDAgW3ppbF9jbGVhbl0KMTAwMTM1ICAgICAgICAgICAg ICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA0NmI5NDgwIFt6aWxfY2xlYW5dCjEw MDEzNCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNDg3OWI4 MCBbemlsX2NsZWFuXQoxMDAxMzMgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAw eGZmZmZmZjAwMDQ2YmExMDAgW3ppbF9jbGVhbl0KMTAwMTMyICAgICAgICAgICAgICAgICAgIEQg ICAgICAgc3luY2VyICAgMHhmZmZmZmYwMDA0NWMyNTAwIFtzeW5jZXIgdWZzOjFdCjEwMDEyMCAg ICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNDZiOWM4MCBbemZz X3ZuX3JlbGVfdGFza3FdCjEwMDExOCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAg IDB4ZmZmZmZmMDAwNDZiODg4MCBbc3BhX3ppb10KMTAwMTE3ICAgICAgICAgICAgICAgICAgIEQg ICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA0NmI4OTAwIFtzcGFfemlvXQoxMDAxMTYgICAgICAg ICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDQ2Yjg5ODAgW3NwYV96aW9d CjEwMDExNSAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNDZi OGEwMCBbc3BhX3ppb10KMTAwMTE0ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAg MHhmZmZmZmYwMDA0NmI4YTgwIFtzcGFfemlvXQoxMDAxMTMgICAgICAgICAgICAgICAgICAgRCAg ICAgICAtICAgICAgICAweGZmZmZmZjAwMDQ2YjhiMDAgW3NwYV96aW9dCjEwMDExMiAgICAgICAg ICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNDZiOGI4MCBbc3BhX3ppb10K MTAwMTExICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA0NmI4 YzAwIFtzcGFfemlvXzddCjEwMDExMCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAg IDB4ZmZmZmZmMDAwNDZiOGMwMCBbc3BhX3ppb182XQoxMDAxMDkgICAgICAgICAgICAgICAgICAg RCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDQ2YjhjMDAgW3NwYV96aW9fNV0KMTAwMTA4ICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA0NmI4YzAwIFtzcGFf emlvXzRdCjEwMDEwNyAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZm MDAwNDZiOGMwMCBbc3BhX3ppb18zXQoxMDAxMDYgICAgICAgICAgICAgICAgICAgRCAgICAgICAt ICAgICAgICAweGZmZmZmZjAwMDQ2YjhjMDAgW3NwYV96aW9fMl0KMTAwMTA1ICAgICAgICAgICAg ICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA0NmI4YzAwIFtzcGFfemlvXzFdCjEw MDEwNCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNDZiOGMw MCBbc3BhX3ppb18wXQoxMDAxMDMgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAw eGZmZmZmZjAwMDQ2YjhjODAgW3NwYV96aW9fN10KMTAwMTAyICAgICAgICAgICAgICAgICAgIEQg ICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA0NmI4YzgwIFtzcGFfemlvXzZdCjEwMDEwMSAgICAg ICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNDZiOGM4MCBbc3BhX3pp b181XQoxMDAxMDAgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAw MDQ2YjhjODAgW3NwYV96aW9fNF0KMTAwMDk5ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAg ICAgICAgMHhmZmZmZmYwMDA0NmI4YzgwIFtzcGFfemlvXzNdCjEwMDA5OCAgICAgICAgICAgICAg ICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNDZiOGM4MCBbc3BhX3ppb18yXQoxMDAw OTcgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDQ2YjhjODAg W3NwYV96aW9fMV0KMTAwMDk2ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhm ZmZmZmYwMDA0NmI4YzgwIFtzcGFfemlvXzBdCjEwMDA5NSAgICAgICAgICAgICAgICAgICBEICAg ICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNDZiOGQwMCBbc3BhX3ppb10KMTAwMDk0ICAgICAgICAg ICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDA0NmI4ZDgwIFtzcGFfemlvXQox MDAwOTMgICAgICAgICAgICAgICAgICAgRCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDQ2Yjlj MDAgW3NwYV96aW9dCjEwMDA3MiAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4 ZmZmZmZmMDAwNDRiZjAwMCBbc3lzdGVtX3Rhc2txXzFdCjEwMDA3MSAgICAgICAgICAgICAgICAg ICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwNDRiZjAwMCBbc3lzdGVtX3Rhc2txXzBdCjEw MDA0OCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZmZmZmMDAwMjFiYjUw MCBbYmdlMCB0YXNrcV0KMTAwMDQ2ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAg MHhmZmZmZmYwMDAyMTllNDgwIFtpd24wIHRhc2txXQoxMDAwMjMgICAgICAgICAgICAgICAgICAg RCAgICAgICAtICAgICAgICAweGZmZmZmZjAwMDE1ZTI1MDAgW2txdWV1ZSB0YXNrcV0KMTAwMDIy ICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDAxNWUyNTgwIFth Y3BpX3Rhc2tfMl0KMTAwMDIxICAgICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhm ZmZmZmYwMDAxNWUyNTgwIFthY3BpX3Rhc2tfMV0KMTAwMDIwICAgICAgICAgICAgICAgICAgIEQg ICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDAxNWUyNTgwIFthY3BpX3Rhc2tfMF0KMTAwMDE3ICAg ICAgICAgICAgICAgICAgIEQgICAgICAgLSAgICAgICAgMHhmZmZmZmYwMDAxNThiYzAwIFt0aHJl YWQgdGFza3FdCjEwMDAxNCAgICAgICAgICAgICAgICAgICBEICAgICAgIC0gICAgICAgIDB4ZmZm ZmZmMDAwMTUwMTgwMCBbZmlybXdhcmUgdGFza3FdCjEwMDAwMCAgICAgICAgICAgICAgICAgICBE ICAgICAgIHNjaGVkICAgIDB4ZmZmZmZmZmY4MDdjZjM0MCBbc3dhcHBlcl0KZGI+IGFsbHRyYWNl CgoKVHJhY2luZyBjb21tYW5kIHRjc2ggcGlkIDUxMDI2IHRpZCAxMDAyODMgdGQgMHhmZmZmZmYw MGE4Zjg1NzIwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0Y2go KSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0 Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhj Cl9jdl93YWl0X3NpZygpIGF0IF9jdl93YWl0X3NpZysweDEyMAp0dHlfd2FpdCgpIGF0IHR0eV93 YWl0KzB4MjUKdHR5ZGlzY19yZWFkKCkgYXQgdHR5ZGlzY19yZWFkKzB4MmIxCnR0eWRldl9yZWFk KCkgYXQgdHR5ZGV2X3JlYWQrMHgxMGUKZGV2ZnNfcmVhZF9mKCkgYXQgZGV2ZnNfcmVhZF9mKzB4 ODYKZG9maWxlcmVhZCgpIGF0IGRvZmlsZXJlYWQrMHhhMQprZXJuX3JlYWR2KCkgYXQga2Vybl9y ZWFkdisweDYwCnJlYWQoKSBhdCByZWFkKzB4NTUKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyNGYK WGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoMywgRnJl ZUJTRCBFTEY2NCwgcmVhZCksIHJpcCA9IDB4ODAwOWYwZDZjLCByc3AgPSAweDdmZmZmZmZmZTJh OCwgcmJwID0gMHgxIC0tLQoKVHJhY2luZyBjb21tYW5kIHh0ZXJtIHBpZCA1MTAyNCB0aWQgMTAw MDc1IHRkIDB4ZmZmZmZmMDAwNDRhMTcyMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2gr MHgxMDcKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxz KCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xl ZXBxX3dhaXRfc2lnKzB4YwpfY3Zfd2FpdF9zaWcoKSBhdCBfY3Zfd2FpdF9zaWcrMHgxMjAKc2Vs dGR3YWl0KCkgYXQgc2VsdGR3YWl0KzB4ZjYKa2Vybl9zZWxlY3QoKSBhdCBrZXJuX3NlbGVjdCsw eDY0ZApzZWxlY3QoKSBhdCBzZWxlY3QrMHg1ZApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI0ZgpY ZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg5MywgRnJl ZUJTRCBFTEY2NCwgc2VsZWN0KSwgcmlwID0gMHg4MDBkNjljZWMsIHJzcCA9IDB4N2ZmZmZmZmZl OWQ4LCByYnAgPSAweDgwMjVlMDAwMCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94U1ZDIHBpZCA0 NTE0MCB0aWQgMTAwMjk3IHRkIDB4ZmZmZmZmMDBhOGY1ZjcyMApzY2hlZF9zd2l0Y2goKSBhdCBz Y2hlZF9zd2l0Y2grMHgxMDcKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9j YXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRf c2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKZG9f Y3Zfd2FpdCgpIGF0IGRvX2N2X3dhaXQrMHg3ZGQKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3Vt dHhfb3BfY3Zfd2FpdCsweDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjRmClhmYXN0X3N5c2Nh bGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2 NCwgX3VtdHhfb3ApLCByaXAgPSAweDgwMTM0ZWRmYywgcnNwID0gMHg3ZmZmZmY5YjhkZjgsIHJi cCA9IDB4ODAyODA3YzQwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hTVkMgcGlkIDQ1MTQwIHRp ZCAxMDAyOTYgdGQgMHhmZmZmZmYwMGE4Zjg2YWIwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3 aXRjaCsweDEwNwptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3Np Z25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBh dCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93YWl0 KCkgYXQgZG9fY3Zfd2FpdCsweDdkZApfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9j dl93YWl0KzB4NWMKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyNGYKWGZhc3Rfc3lzY2FsbCgpIGF0 IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10 eF9vcCksIHJpcCA9IDB4ODAxMzRlZGZjLCByc3AgPSAweDdmZmZmZmEzOWQ3OCwgcmJwID0gMHg4 MDI4MDdhODAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveFNWQyBwaWQgNDUxNDAgdGlkIDEwMDI5 NSB0ZCAweGZmZmZmZjAxMjBhZjdhYjAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4 MTA3Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygp IGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV90aW1lZHdhaXRfc2lnKCkgYXQg c2xlZXBxX3RpbWVkd2FpdF9zaWcrMHgxOQpfc2xlZXAoKSBhdCBfc2xlZXArMHgxYTMKZG9fY3Zf d2FpdCgpIGF0IGRvX2N2X3dhaXQrMHg1OTAKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhf b3BfY3Zfd2FpdCsweDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjRmClhmYXN0X3N5c2NhbGwo KSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwg X3VtdHhfb3ApLCByaXAgPSAweDgwMTM0ZWRmYywgcnNwID0gMHg3ZmZmZmZhYmFjYzgsIHJicCA9 IDB4ODAyODA3OGMwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hTVkMgcGlkIDQ1MTQwIHRpZCAx MDAyOTQgdGQgMHhmZmZmZmYwMTIwYWY2MDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRj aCsweDEwNwptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25h bHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfdGltZWR3YWl0X3NpZygp IGF0IHNsZWVwcV90aW1lZHdhaXRfc2lnKzB4MTkKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MWEzCmRv X2N2X3dhaXQoKSBhdCBkb19jdl93YWl0KzB4NTkwCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191 bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI0ZgpYZmFzdF9zeXNj YWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxG NjQsIF91bXR4X29wKSwgcmlwID0gMHg4MDEzNGVkZmMsIHJzcCA9IDB4N2ZmZmZmYjNiZTI4LCBy YnAgPSAweDgwMjgwNzU0MCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94U1ZDIHBpZCA0NTE0MCB0 aWQgMTAwMjkzIHRkIDB4ZmZmZmZmMDA4NDFmNWFiMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9z d2l0Y2grMHgxMDcKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9z aWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkg YXQgc2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKZG9fY3Zfd2Fp dCgpIGF0IGRvX2N2X3dhaXQrMHg3ZGQKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhfb3Bf Y3Zfd2FpdCsweDVjCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjRmClhmYXN0X3N5c2NhbGwoKSBh dCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwgX3Vt dHhfb3ApLCByaXAgPSAweDgwMTM0ZWRmYywgcnNwID0gMHg3ZmZmZmZiYmNlMjgsIHJicCA9IDB4 ODAyMDA3ZTAwIC0tLQoKVHJhY2luZyBjb21tYW5kIFZCb3hTVkMgcGlkIDQ1MTQwIHRpZCAxMDAy OTIgdGQgMHhmZmZmZmYwMGE4Zjg1MzkwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsw eDEwNwptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMo KSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVl cHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93YWl0KCkgYXQg ZG9fY3Zfd2FpdCsweDdkZApfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9jdl93YWl0 KzB4NWMKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyNGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0 X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10eF9vcCks IHJpcCA9IDB4ODAxMzRlZGZjLCByc3AgPSAweDdmZmZmZmJkZGRmOCwgcmJwID0gMHg4MDIwMDdj NDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVkJveFNWQyBwaWQgNDUxNDAgdGlkIDEwMDI5MSB0ZCAw eGZmZmZmZjAwODQxZjUwMDAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA3Cm1p X3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNs ZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0 X3NpZysweGMKX2N2X3dhaXRfc2lnKCkgYXQgX2N2X3dhaXRfc2lnKzB4MTIwCnNlbHRkd2FpdCgp IGF0IHNlbHRkd2FpdCsweGY2CnBvbGwoKSBhdCBwb2xsKzB4MmY4CnN5c2NhbGwoKSBhdCBzeXNj YWxsKzB4MjRmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2Nh bGwgKDIwOSwgRnJlZUJTRCBFTEY2NCwgcG9sbCksIHJpcCA9IDB4ODAxMTllYjRjLCByc3AgPSAw eDdmZmZmZmJmZTg0OCwgcmJwID0gMHg3ZmZmZmZiZmU4OTQgLS0tCgpUcmFjaW5nIGNvbW1hbmQg VkJveFNWQyBwaWQgNDUxNDAgdGlkIDEwMDI1NyB0ZCAweGZmZmZmZjAwYThmODY3MjAKc2NoZWRf c3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA3Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsw eDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFm CnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3Ns ZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBkb19jdl93YWl0KzB4N2RkCl9fdW10eF9vcF9jdl93 YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI0 ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg0NTQs IEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwgcmlwID0gMHg4MDEzNGVkZmMsIHJzcCA9IDB4N2Zm ZmZmZmZlNzY4LCByYnAgPSAweDgwMjAwNzFjMCAtLS0KClRyYWNpbmcgY29tbWFuZCBWQm94WFBD T01JUENEIHBpZCA0NTEzNyB0aWQgMTAwMTc5IHRkIDB4ZmZmZmZmMDAwNGRmOTAwMApzY2hlZF9z d2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDcKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4 MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYK c2xlZXBxX3RpbWVkd2FpdF9zaWcoKSBhdCBzbGVlcHFfdGltZWR3YWl0X3NpZysweDE5Cl9jdl90 aW1lZHdhaXRfc2lnKCkgYXQgX2N2X3RpbWVkd2FpdF9zaWcrMHgxMjkKc2VsdGR3YWl0KCkgYXQg c2VsdGR3YWl0KzB4OGQKcG9sbCgpIGF0IHBvbGwrMHgyZjgKc3lzY2FsbCgpIGF0IHN5c2NhbGwr MHgyNGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAo MjA5LCBGcmVlQlNEIEVMRjY0LCBwb2xsKSwgcmlwID0gMHg4MDEwMTNiNGMsIHJzcCA9IDB4N2Zm ZmZmZmZlNTg4LCByYnAgPSAweDI5OTNjZmY4IC0tLQoKVHJhY2luZyBjb21tYW5kIFZpcnR1YWxC b3ggcGlkIDQ1MDc5IHRpZCAxMDAyODkgdGQgMHhmZmZmZmYwMTIwYWY0NzIwCnNjaGVkX3N3aXRj aCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYK c2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVl cHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsw eDI2Ygpkb19jdl93YWl0KCkgYXQgZG9fY3Zfd2FpdCsweDdkZApfX3VtdHhfb3BfY3Zfd2FpdCgp IGF0IF9fdW10eF9vcF9jdl93YWl0KzB4NWMKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyNGYKWGZh c3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVl QlNEIEVMRjY0LCBfdW10eF9vcCksIHJpcCA9IDB4ODAwNjVjZGZjLCByc3AgPSAweDdmZmZmZmJi Y2RmOCwgcmJwID0gMHg4MDEwMDgxODAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVmlydHVhbEJveCBw aWQgNDUwNzkgdGlkIDEwMDIyOCB0ZCAweGZmZmZmZjAwODQxZjU3MjAKc2NoZWRfc3dpdGNoKCkg YXQgc2NoZWRfc3dpdGNoKzB4MTA3Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVl cHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93 YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX2N2X3dhaXRfc2lnKCkgYXQgX2N2X3dh aXRfc2lnKzB4MTIwCnNlbHRkd2FpdCgpIGF0IHNlbHRkd2FpdCsweGY2CnBvbGwoKSBhdCBwb2xs KzB4MmY4CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjRmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFz dF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDIwOSwgRnJlZUJTRCBFTEY2NCwgcG9sbCksIHJp cCA9IDB4ODAwYzNjYjRjLCByc3AgPSAweDdmZmZmZmJkZDgxOCwgcmJwID0gMHg3ZmZmZmZiZGQ4 OTQgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVmlydHVhbEJveCBwaWQgNDUwNzkgdGlkIDEwMDIyMyB0 ZCAweGZmZmZmZjAxMjA1OGE3MjAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA3 Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0 IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93 YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmtlcm5fd2FpdCgpIGF0IGtlcm5f d2FpdCsweDgxNwp3YWl0NCgpIGF0IHdhaXQ0KzB4MzUKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgy NGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNywg RnJlZUJTRCBFTEY2NCwgd2FpdDQpLCByaXAgPSAweDgwMGMwODQxYywgcnNwID0gMHg3ZmZmZmZi ZmVlYzgsIHJicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgVmlydHVhbEJveCBwaWQgNDUwNzkg dGlkIDEwMDIzMCB0ZCAweGZmZmZmZjAwYThmODQ3MjAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRf c3dpdGNoKzB4MTA3Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hf c2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV90aW1lZHdhaXRf c2lnKCkgYXQgc2xlZXBxX3RpbWVkd2FpdF9zaWcrMHgxOQpfY3ZfdGltZWR3YWl0X3NpZygpIGF0 IF9jdl90aW1lZHdhaXRfc2lnKzB4MTI5CnNlbHRkd2FpdCgpIGF0IHNlbHRkd2FpdCsweDhkCnBv bGwoKSBhdCBwb2xsKzB4MmY4CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjRmClhmYXN0X3N5c2Nh bGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDIwOSwgRnJlZUJTRCBFTEY2 NCwgcG9sbCksIHJpcCA9IDB4ODAwYzNjYjRjLCByc3AgPSAweDdmZmZmZmZmZDRkOCwgcmJwID0g MHgzIC0tLQoKVHJhY2luZyBjb21tYW5kIFRJTUVSIHBpZCA0NDczMCB0aWQgMTAwMjQyIHRkIDB4 ZmZmZmZmMDEyMGFmYTcyMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDcKbWlf c3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV93YWl0KCkgYXQgc2xlZXBxX3dhaXQr MHg0MgpydFNlbUV2ZW50V2FpdCgpIGF0IHJ0U2VtRXZlbnRXYWl0KzB4MjVhCnJ0VGltZXJUaHJl YWQoKSBhdCBydFRpbWVyVGhyZWFkKzB4M2UKcnRUaHJlYWRNYWluKCkgYXQgcnRUaHJlYWRNYWlu KzB4MmMKcnRUaHJlYWROYXRpdmVNYWluKCkgYXQgcnRUaHJlYWROYXRpdmVNYWluKzB4MTYKZm9y a19leGl0KCkgYXQgZm9ya19leGl0KzB4MTE4CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJh bXBvbGluZSsweGUKLS0tIHRyYXAgMCwgcmlwID0gMCwgcnNwID0gMHhmZmZmZmY4MDc4ZTQzZDMw LCByYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIHRjc2ggcGlkIDQxODMyIHRpZCAxMDAyNzQg dGQgMHhmZmZmZmYwMGE4Zjg1YWIwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEw NwptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBh dCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFf d2FpdF9zaWcrMHhjCl9jdl93YWl0X3NpZygpIGF0IF9jdl93YWl0X3NpZysweDEyMAp0dHlfd2Fp dCgpIGF0IHR0eV93YWl0KzB4MjUKdHR5ZGlzY19yZWFkKCkgYXQgdHR5ZGlzY19yZWFkKzB4MmIx CnR0eWRldl9yZWFkKCkgYXQgdHR5ZGV2X3JlYWQrMHgxMGUKZGV2ZnNfcmVhZF9mKCkgYXQgZGV2 ZnNfcmVhZF9mKzB4ODYKZG9maWxlcmVhZCgpIGF0IGRvZmlsZXJlYWQrMHhhMQprZXJuX3JlYWR2 KCkgYXQga2Vybl9yZWFkdisweDYwCnJlYWQoKSBhdCByZWFkKzB4NTUKc3lzY2FsbCgpIGF0IHN5 c2NhbGwrMHgyNGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lz Y2FsbCAoMywgRnJlZUJTRCBFTEY2NCwgcmVhZCksIHJpcCA9IDB4ODAwOWYwZDZjLCByc3AgPSAw eDdmZmZmZmZmZTJhOCwgcmJwID0gMHgxIC0tLQoKVHJhY2luZyBjb21tYW5kIHh0ZXJtIHBpZCA0 MTgyOCB0aWQgMTAwMjIyIHRkIDB4ZmZmZmZmMDEyMDViZDAwMApzY2hlZF9zd2l0Y2goKSBhdCBz Y2hlZF9zd2l0Y2grMHgxMDcKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9j YXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRf c2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4YwpfY3Zfd2FpdF9zaWcoKSBhdCBfY3Zfd2FpdF9z aWcrMHgxMjAKc2VsdGR3YWl0KCkgYXQgc2VsdGR3YWl0KzB4ZjYKa2Vybl9zZWxlY3QoKSBhdCBr ZXJuX3NlbGVjdCsweDY0ZApzZWxlY3QoKSBhdCBzZWxlY3QrMHg1ZApzeXNjYWxsKCkgYXQgc3lz Y2FsbCsweDI0ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNj YWxsICg5MywgRnJlZUJTRCBFTEY2NCwgc2VsZWN0KSwgcmlwID0gMHg4MDBkNjljZWMsIHJzcCA9 IDB4N2ZmZmZmZmZlOWQ4LCByYnAgPSAweDgwMjVlMDAwMCAtLS0KClRyYWNpbmcgY29tbWFuZCBu cHZpZXdlci5iaW4gcGlkIDkwNzk1IHRpZCAxMDAyMTUgdGQgMHhmZmZmZmYwMDA0YjU2MDAwCnNj aGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0Y2goKSBhdCBtaV9zd2l0 Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysw eDMxZgpzbGVlcHFfdGltZWR3YWl0X3NpZygpIGF0IHNsZWVwcV90aW1lZHdhaXRfc2lnKzB4MTkK X2N2X3RpbWVkd2FpdF9zaWcoKSBhdCBfY3ZfdGltZWR3YWl0X3NpZysweDEyOQpzZWx0ZHdhaXQo KSBhdCBzZWx0ZHdhaXQrMHg4ZApwb2xsKCkgYXQgcG9sbCsweDJmOAppYTMyX3N5c2NhbGwoKSBh dCBpYTMyX3N5c2NhbGwrMHgxZWIKWGludDB4ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2Nh bGwrMHg5NQotLS0gc3lzY2FsbCAoMTY4LCBMaW51eCBFTEYzMiwgcG9sbCksIHJpcCA9IDB4Mjg4 OTc4MmQsIHJzcCA9IDB4ZmZmZmQ2ZDQsIHJicCA9IDB4ZmZmZmQ2ZTggLS0tCgpUcmFjaW5nIGNv bW1hbmQgZmlyZWZveC1iaW4gcGlkIDkwNzc3IHRpZCAxMDAyNTkgdGQgMHhmZmZmZmYwMDQxY2Fj MDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0Y2goKSBhdCBt aV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2ln bmFscysweDMxZgpzbGVlcHFfdGltZWR3YWl0X3NpZygpIGF0IHNsZWVwcV90aW1lZHdhaXRfc2ln KzB4MTkKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MWEzCmRvX2N2X3dhaXQoKSBhdCBkb19jdl93YWl0 KzB4NTkwCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNj YWxsKCkgYXQgc3lzY2FsbCsweDI0ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsw eGUxCi0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwgcmlwID0gMHg4 MDRlMGVkZmMsIHJzcCA9IDB4N2ZmZmZlZGY3ZTA4LCByYnAgPSAweDgwYzFjN2RjMCAtLS0KClRy YWNpbmcgY29tbWFuZCBmaXJlZm94LWJpbiBwaWQgOTA3NzcgdGlkIDEwMDI5MCB0ZCAweGZmZmZm ZjAwMDRkZmJhYjAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA3Cm1pX3N3aXRj aCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9j YXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysw eGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBkb19jdl93YWl0KzB4 N2RkCl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNjYWxs KCkgYXQgc3lzY2FsbCsweDI0ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUx Ci0tLSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwgcmlwID0gMHg4MDRl MGVkZmMsIHJzcCA9IDB4N2ZmZmZjZGU3ZGQ4LCByYnAgPSAweDgwYzFjNmM0MCAtLS0KClRyYWNp bmcgY29tbWFuZCBmaXJlZm94LWJpbiBwaWQgOTA3NzcgdGlkIDEwMDI0MSB0ZCAweGZmZmZmZjAx MjBhZmIzOTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA3Cm1pX3N3aXRjaCgp IGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRj aF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMK X3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBkb19jdl93YWl0KzB4N2Rk Cl9fdW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkg YXQgc3lzY2FsbCsweDI0ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0t LSBzeXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwgcmlwID0gMHg4MDRlMGVk ZmMsIHJzcCA9IDB4N2ZmZmZlYmY2ZGQ4LCByYnAgPSAweDgwOTc2YWZjMCAtLS0KClRyYWNpbmcg Y29tbWFuZCBmaXJlZm94LWJpbiBwaWQgOTA3NzcgdGlkIDEwMDIyNiB0ZCAweGZmZmZmZjAxMjBh ZmJhYjAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA3Cm1pX3N3aXRjaCgpIGF0 IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9z aWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3Ns ZWVwKCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBkb19jdl93YWl0KzB4N2RkCl9f dW10eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQg c3lzY2FsbCsweDI0ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBz eXNjYWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwgcmlwID0gMHg4MDRlMGVkZmMs IHJzcCA9IDB4N2ZmZmZlZmY4ZTg4LCByYnAgPSAweDgwOTc2YThjMCAtLS0KClRyYWNpbmcgY29t bWFuZCBmaXJlZm94LWJpbiBwaWQgOTA3NzcgdGlkIDEwMDIyNCB0ZCAweGZmZmZmZjAwMjlkZjMw MDAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA3Cm1pX3N3aXRjaCgpIGF0IG1p X3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWdu YWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVw KCkgYXQgX3NsZWVwKzB4MjZiCmRvX2N2X3dhaXQoKSBhdCBkb19jdl93YWl0KzB4N2RkCl9fdW10 eF9vcF9jdl93YWl0KCkgYXQgX191bXR4X29wX2N2X3dhaXQrMHg1YwpzeXNjYWxsKCkgYXQgc3lz Y2FsbCsweDI0ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNj YWxsICg0NTQsIEZyZWVCU0QgRUxGNjQsIF91bXR4X29wKSwgcmlwID0gMHg4MDRlMGVkZmMsIHJz cCA9IDB4N2ZmZmZmMWY5ZTY4LCByYnAgPSAweDgwOTc2YTU0MCAtLS0KClRyYWNpbmcgY29tbWFu ZCBmaXJlZm94LWJpbiBwaWQgOTA3NzcgdGlkIDEwMDIyMSB0ZCAweGZmZmZmZjAwMjlkZjMzOTAK c2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA3Cm1pX3N3aXRjaCgpIGF0IG1pX3N3 aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxz KzB4MzFmCnNsZWVwcV90aW1lZHdhaXRfc2lnKCkgYXQgc2xlZXBxX3RpbWVkd2FpdF9zaWcrMHgx OQpfc2xlZXAoKSBhdCBfc2xlZXArMHgxYTMKZG9fY3Zfd2FpdCgpIGF0IGRvX2N2X3dhaXQrMHg1 OTAKX191bXR4X29wX2N2X3dhaXQoKSBhdCBfX3VtdHhfb3BfY3Zfd2FpdCsweDVjCnN5c2NhbGwo KSBhdCBzeXNjYWxsKzB4MjRmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEK LS0tIHN5c2NhbGwgKDQ1NCwgRnJlZUJTRCBFTEY2NCwgX3VtdHhfb3ApLCByaXAgPSAweDgwNGUw ZWRmYywgcnNwID0gMHg3ZmZmZmY1ZmJkYjgsIHJicCA9IDB4ODA2YzA5NGMwIC0tLQoKVHJhY2lu ZyBjb21tYW5kIGZpcmVmb3gtYmluIHBpZCA5MDc3NyB0aWQgMTAwMjIwIHRkIDB4ZmZmZmZmMDAy OWRmMzcyMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDcKbWlfc3dpdGNoKCkg YXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNo X3NpZ25hbHMrMHgzMWYKc2xlZXBxX3RpbWVkd2FpdF9zaWcoKSBhdCBzbGVlcHFfdGltZWR3YWl0 X3NpZysweDE5Cl9zbGVlcCgpIGF0IF9zbGVlcCsweDFhMwpkb19jdl93YWl0KCkgYXQgZG9fY3Zf d2FpdCsweDU5MApfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9jdl93YWl0KzB4NWMK c3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyNGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2Nh bGwrMHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10eF9vcCksIHJpcCA9 IDB4ODA0ZTBlZGZjLCByc3AgPSAweDdmZmZmZjdmY2U2OCwgcmJwID0gMHg4MDZjMDg2YzAgLS0t CgpUcmFjaW5nIGNvbW1hbmQgZmlyZWZveC1iaW4gcGlkIDkwNzc3IHRpZCAxMDAyMTkgdGQgMHhm ZmZmZmYwMDI5ZGYzYWIwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9z d2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVl cHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9z aWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2Ygpkb19jdl93YWl0KCkgYXQgZG9fY3Zfd2Fp dCsweDdkZApfX3VtdHhfb3BfY3Zfd2FpdCgpIGF0IF9fdW10eF9vcF9jdl93YWl0KzB4NWMKc3lz Y2FsbCgpIGF0IHN5c2NhbGwrMHgyNGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwr MHhlMQotLS0gc3lzY2FsbCAoNDU0LCBGcmVlQlNEIEVMRjY0LCBfdW10eF9vcCksIHJpcCA9IDB4 ODA0ZTBlZGZjLCByc3AgPSAweDdmZmZmZjlmZGVhOCwgcmJwID0gMHg4MDZjMDg1MDAgLS0tCgpU cmFjaW5nIGNvbW1hbmQgZmlyZWZveC1iaW4gcGlkIDkwNzc3IHRpZCAxMDAyMTggdGQgMHhmZmZm ZmYwMGE4MzAyYWIwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0 Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFf Y2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfdGltZWR3YWl0X3NpZygpIGF0IHNsZWVwcV90aW1l ZHdhaXRfc2lnKzB4MTkKX2N2X3RpbWVkd2FpdF9zaWcoKSBhdCBfY3ZfdGltZWR3YWl0X3NpZysw eDEyOQpzZWx0ZHdhaXQoKSBhdCBzZWx0ZHdhaXQrMHg4ZApwb2xsKCkgYXQgcG9sbCsweDJmOApz eXNjYWxsKCkgYXQgc3lzY2FsbCsweDI0ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2Fs bCsweGUxCi0tLSBzeXNjYWxsICgyMDksIEZyZWVCU0QgRUxGNjQsIHBvbGwpLCByaXAgPSAweDgw NGI1MWI0YywgcnNwID0gMHg3ZmZmZmZiZmViMzgsIHJicCA9IDB4Mjk5NTBhYzggLS0tCgpUcmFj aW5nIGNvbW1hbmQgZmlyZWZveC1iaW4gcGlkIDkwNzc3IHRpZCAxMDAyMjcgdGQgMHhmZmZmZmYw MTIwYWZhYWIwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0Y2go KSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0 Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhj Cl9jdl93YWl0X3NpZygpIGF0IF9jdl93YWl0X3NpZysweDEyMApzZWx0ZHdhaXQoKSBhdCBzZWx0 ZHdhaXQrMHhmNgpwb2xsKCkgYXQgcG9sbCsweDJmOApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI0 ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICgyMDks IEZyZWVCU0QgRUxGNjQsIHBvbGwpLCByaXAgPSAweDgwNGI1MWI0YywgcnNwID0gMHg3ZmZmZmZm ZmRmYzgsIHJicCA9IDB4NSAtLS0KClRyYWNpbmcgY29tbWFuZCBzaCBwaWQgOTA3NzMgdGlkIDEw MDE1MCB0ZCAweGZmZmZmZjAwMDQ2YjUzOTAKClRyYWNpbmcgY29tbWFuZCBzaCBwaWQgOTA3NjEg dGlkIDEwMDIxMSB0ZCAweGZmZmZmZjAwMDRiNTcwMDAKClRyYWNpbmcgY29tbWFuZCB0Y3NoIHBp ZCA5MDcxOSB0aWQgMTAwMjgwIHRkIDB4ZmZmZmZmMDEyMDViZGFiMApzY2hlZF9zd2l0Y2goKSBh dCBzY2hlZF9zd2l0Y2grMHgxMDcKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVw cV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dh aXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4YwpfY3Zfd2FpdF9zaWcoKSBhdCBfY3Zfd2Fp dF9zaWcrMHgxMjAKdHR5X3dhaXQoKSBhdCB0dHlfd2FpdCsweDI1CnR0eWRpc2NfcmVhZCgpIGF0 IHR0eWRpc2NfcmVhZCsweDJiMQp0dHlkZXZfcmVhZCgpIGF0IHR0eWRldl9yZWFkKzB4MTBlCmRl dmZzX3JlYWRfZigpIGF0IGRldmZzX3JlYWRfZisweDg2CmRvZmlsZXJlYWQoKSBhdCBkb2ZpbGVy ZWFkKzB4YTEKa2Vybl9yZWFkdigpIGF0IGtlcm5fcmVhZHYrMHg2MApyZWFkKCkgYXQgcmVhZCsw eDU1CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjRmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9z eXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDMsIEZyZWVCU0QgRUxGNjQsIHJlYWQpLCByaXAgPSAw eDgwMDlmMGQ2YywgcnNwID0gMHg3ZmZmZmZmZmUxYjgsIHJicCA9IDB4MSAtLS0KClRyYWNpbmcg Y29tbWFuZCB0Y3NoIHBpZCA1OTc5NyB0aWQgMTAwMTU0IHRkIDB4ZmZmZmZmMDAwNDZiM2FiMApz Y2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDcKbWlfc3dpdGNoKCkgYXQgbWlfc3dp dGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMr MHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4YwpfY3Zfd2FpdF9z aWcoKSBhdCBfY3Zfd2FpdF9zaWcrMHgxMjAKdHR5X3dhaXQoKSBhdCB0dHlfd2FpdCsweDI1CnR0 eWRpc2NfcmVhZCgpIGF0IHR0eWRpc2NfcmVhZCsweDJiMQp0dHlkZXZfcmVhZCgpIGF0IHR0eWRl dl9yZWFkKzB4MTBlCmRldmZzX3JlYWRfZigpIGF0IGRldmZzX3JlYWRfZisweDg2CmRvZmlsZXJl YWQoKSBhdCBkb2ZpbGVyZWFkKzB4YTEKa2Vybl9yZWFkdigpIGF0IGtlcm5fcmVhZHYrMHg2MApy ZWFkKCkgYXQgcmVhZCsweDU1CnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjRmClhmYXN0X3N5c2Nh bGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDMsIEZyZWVCU0QgRUxGNjQs IHJlYWQpLCByaXAgPSAweDgwMDlmMGQ2YywgcnNwID0gMHg3ZmZmZmZmZmUxYjgsIHJicCA9IDB4 MSAtLS0KClRyYWNpbmcgY29tbWFuZCB0bXV4IHBpZCA1OTc5NiB0aWQgMTAwMjA5IHRkIDB4ZmZm ZmZmMDAwNGI1NzcyMAoKVHJhY2luZyBjb21tYW5kIHRjc2ggcGlkIDU5NzYyIHRpZCAxMDAyNDgg dGQgMHhmZmZmZmYwMGE4ZjVmYWIwCgpUcmFjaW5nIGNvbW1hbmQgeHRlcm0gcGlkIDU5NzYwIHRp ZCAxMDAyODEgdGQgMHhmZmZmZmYwMTIwYWY0MzkwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3 aXRjaCsweDEwNwptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3Np Z25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBh dCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9jdl93YWl0X3NpZygpIGF0IF9jdl93YWl0X3NpZysweDEy MApzZWx0ZHdhaXQoKSBhdCBzZWx0ZHdhaXQrMHhmNgprZXJuX3NlbGVjdCgpIGF0IGtlcm5fc2Vs ZWN0KzB4NjRkCnNlbGVjdCgpIGF0IHNlbGVjdCsweDVkCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4 MjRmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDkz LCBGcmVlQlNEIEVMRjY0LCBzZWxlY3QpLCByaXAgPSAweDgwMGQ2OWNlYywgcnNwID0gMHg3ZmZm ZmZmZmU5ZDgsIHJicCA9IDB4ODAyNWUwMDAwIC0tLQoKVHJhY2luZyBjb21tYW5kIG1vcmUgcGlk IDU5NjQ4IHRpZCAxMDAxNjMgdGQgMHhmZmZmZmYwMDA0NmM1MDAwCnNjaGVkX3N3aXRjaCgpIGF0 IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBx X2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2Fp dF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9jdl93YWl0X3NpZygpIGF0IF9jdl93YWl0 X3NpZysweDEyMAp0dHlfd2FpdCgpIGF0IHR0eV93YWl0KzB4MjUKdHR5ZGlzY19yZWFkKCkgYXQg dHR5ZGlzY19yZWFkKzB4MmIxCnR0eWRldl9yZWFkKCkgYXQgdHR5ZGV2X3JlYWQrMHgxMGUKZGV2 ZnNfcmVhZF9mKCkgYXQgZGV2ZnNfcmVhZF9mKzB4ODYKZG9maWxlcmVhZCgpIGF0IGRvZmlsZXJl YWQrMHhhMQprZXJuX3JlYWR2KCkgYXQga2Vybl9yZWFkdisweDYwCnJlYWQoKSBhdCByZWFkKzB4 NTUKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyNGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5 c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoMywgRnJlZUJTRCBFTEY2NCwgcmVhZCksIHJpcCA9IDB4 ODAwOGE1ZDZjLCByc3AgPSAweDdmZmZmZmZmZTYwOCwgcmJwID0gMHhmZmZmZmZlMCAtLS0KClRy YWNpbmcgY29tbWFuZCBzaCBwaWQgNTk2NDMgdGlkIDEwMDI1MSB0ZCAweGZmZmZmZjAwYTgyN2Jh YjAKClRyYWNpbmcgY29tbWFuZCBzeXN0YXQgcGlkIDU4MDI3IHRpZCAxMDAxNjUgdGQgMHhmZmZm ZmYwMDA0ZGZiNzIwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0 Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFf Y2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcr MHhjCl9jdl93YWl0X3NpZygpIGF0IF9jdl93YWl0X3NpZysweDEyMAp0dHlfd2FpdCgpIGF0IHR0 eV93YWl0KzB4MjUKdHR5ZGlzY19yZWFkKCkgYXQgdHR5ZGlzY19yZWFkKzB4MmIxCnR0eWRldl9y ZWFkKCkgYXQgdHR5ZGV2X3JlYWQrMHgxMGUKZGV2ZnNfcmVhZF9mKCkgYXQgZGV2ZnNfcmVhZF9m KzB4ODYKZG9maWxlcmVhZCgpIGF0IGRvZmlsZXJlYWQrMHhhMQprZXJuX3JlYWR2KCkgYXQga2Vy bl9yZWFkdisweDYwCnJlYWQoKSBhdCByZWFkKzB4NTUKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgy NGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoMywg RnJlZUJTRCBFTEY2NCwgcmVhZCksIHJpcCA9IDB4ODAwYmQ1ZDZjLCByc3AgPSAweDdmZmZmZmZm ZGQ2OCwgcmJwID0gMHg4MDExMDgwMDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgdGNzaCBwaWQgNTc3 OTYgdGlkIDEwMDI0NSB0ZCAweGZmZmZmZjAxMjBhZmEzOTAKClRyYWNpbmcgY29tbWFuZCB4dGVy bSBwaWQgNTc3OTQgdGlkIDEwMDIxNiB0ZCAweGZmZmZmZjAwYThmYmMzOTAKc2NoZWRfc3dpdGNo KCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA3Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2Zgpz bGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVw cV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX2N2X3dhaXRfc2lnKCkgYXQgX2N2 X3dhaXRfc2lnKzB4MTIwCnNlbHRkd2FpdCgpIGF0IHNlbHRkd2FpdCsweGY2Cmtlcm5fc2VsZWN0 KCkgYXQga2Vybl9zZWxlY3QrMHg2NGQKc2VsZWN0KCkgYXQgc2VsZWN0KzB4NWQKc3lzY2FsbCgp IGF0IHN5c2NhbGwrMHgyNGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQot LS0gc3lzY2FsbCAoOTMsIEZyZWVCU0QgRUxGNjQsIHNlbGVjdCksIHJpcCA9IDB4ODAwZDY5Y2Vj LCByc3AgPSAweDdmZmZmZmZmZTlkOCwgcmJwID0gMHg4MDI1ZTAwMDAgLS0tCgpUcmFjaW5nIGNv bW1hbmQgbWFuIHBpZCA1NjkyMyB0aWQgMTAwMjQwIHRkIDB4ZmZmZmZmMDEyMDU4YWFiMAoKVHJh Y2luZyBjb21tYW5kIHRjc2ggcGlkIDU0NTQ3IHRpZCAxMDAyMzggdGQgMHhmZmZmZmYwMTIwNThk MzkwCgpUcmFjaW5nIGNvbW1hbmQgdG11eCBwaWQgNTQ1NDYgdGlkIDEwMDI0OSB0ZCAweGZmZmZm ZjAwYThmYmM3MjAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA3Cm1pX3N3aXRj aCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9j YXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV90aW1lZHdhaXRfc2lnKCkgYXQgc2xlZXBxX3RpbWVk d2FpdF9zaWcrMHgxOQpfc2xlZXAoKSBhdCBfc2xlZXArMHgxYTMKa2Vybl9rZXZlbnQoKSBhdCBr ZXJuX2tldmVudCsweDM2NQprZXZlbnQoKSBhdCBrZXZlbnQrMHg5MApzeXNjYWxsKCkgYXQgc3lz Y2FsbCsweDI0ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNj YWxsICgzNjMsIEZyZWVCU0QgRUxGNjQsIGtldmVudCksIHJpcCA9IDB4ODAwYmVjZTZjLCByc3Ag PSAweDdmZmZmZmZmZDBiOCwgcmJwID0gMHg4MDEwNzAwMDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQg dGNzaCBwaWQgNDQxNjYgdGlkIDEwMDE4MyB0ZCAweGZmZmZmZjAwMDRkZjgwMDAKc2NoZWRfc3dp dGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA3Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2 ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNs ZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX2N2X3dhaXRfc2lnKCkgYXQg X2N2X3dhaXRfc2lnKzB4MTIwCnR0eV93YWl0KCkgYXQgdHR5X3dhaXQrMHgyNQp0dHlkaXNjX3Jl YWQoKSBhdCB0dHlkaXNjX3JlYWQrMHgyYjEKdHR5ZGV2X3JlYWQoKSBhdCB0dHlkZXZfcmVhZCsw eDEwZQpkZXZmc19yZWFkX2YoKSBhdCBkZXZmc19yZWFkX2YrMHg4Ngpkb2ZpbGVyZWFkKCkgYXQg ZG9maWxlcmVhZCsweGExCmtlcm5fcmVhZHYoKSBhdCBrZXJuX3JlYWR2KzB4NjAKcmVhZCgpIGF0 IHJlYWQrMHg1NQpzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI0ZgpYZmFzdF9zeXNjYWxsKCkgYXQg WGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICgzLCBGcmVlQlNEIEVMRjY0LCByZWFkKSwg cmlwID0gMHg4MDA5ZjBkNmMsIHJzcCA9IDB4N2ZmZmZmZmZlMmE4LCByYnAgPSAweDEgLS0tCgpU cmFjaW5nIGNvbW1hbmQgeHRlcm0gcGlkIDQ0MTYzIHRpZCAxMDAyNjQgdGQgMHhmZmZmZmYwMTIw NTg5MDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0Y2goKSBh dCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hf c2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9j dl93YWl0X3NpZygpIGF0IF9jdl93YWl0X3NpZysweDEyMApzZWx0ZHdhaXQoKSBhdCBzZWx0ZHdh aXQrMHhmNgprZXJuX3NlbGVjdCgpIGF0IGtlcm5fc2VsZWN0KzB4NjRkCnNlbGVjdCgpIGF0IHNl bGVjdCsweDVkCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjRmClhmYXN0X3N5c2NhbGwoKSBhdCBY ZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDkzLCBGcmVlQlNEIEVMRjY0LCBzZWxlY3Qp LCByaXAgPSAweDgwMGQ2OWNlYywgcnNwID0gMHg3ZmZmZmZmZmU5ZDgsIHJicCA9IDB4ODAyNWUw MDAwIC0tLQoKVHJhY2luZyBjb21tYW5kIGRoY2xpZW50IHBpZCAxODY1IHRpZCAxMDAwODkgdGQg MHhmZmZmZmYwMDA0NjMwMDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwpt aV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBz bGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfdGltZWR3YWl0X3NpZygpIGF0IHNsZWVw cV90aW1lZHdhaXRfc2lnKzB4MTkKX2N2X3RpbWVkd2FpdF9zaWcoKSBhdCBfY3ZfdGltZWR3YWl0 X3NpZysweDEyOQpzZWx0ZHdhaXQoKSBhdCBzZWx0ZHdhaXQrMHg4ZApwb2xsKCkgYXQgcG9sbCsw eDJmOApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI0ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rf c3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICgyMDksIEZyZWVCU0QgRUxGNjQsIHBvbGwpLCByaXAg PSAweDgwMDZmYWI0YywgcnNwID0gMHg3ZmZmZmZmZmVjZTgsIHJicCA9IDB4MmZkNjE4IC0tLQoK VHJhY2luZyBjb21tYW5kIGRoY2xpZW50IHBpZCAxODIxIHRpZCAxMDAyMDcgdGQgMHhmZmZmZmYw MDA0YjU5MDAwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0Y2go KSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0 Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhj Cl9jdl93YWl0X3NpZygpIGF0IF9jdl93YWl0X3NpZysweDEyMApzZWx0ZHdhaXQoKSBhdCBzZWx0 ZHdhaXQrMHhmNgpwb2xsKCkgYXQgcG9sbCsweDJmOApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI0 ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICgyMDks IEZyZWVCU0QgRUxGNjQsIHBvbGwpLCByaXAgPSAweDgwMDZmYWI0YywgcnNwID0gMHg3ZmZmZmZm ZmVjZTgsIHJicCA9IDB4YSAtLS0KClRyYWNpbmcgY29tbWFuZCBoYWxkLWFkZG9uLW1vdXNlLXN5 IHBpZCAxNzQwIHRpZCAxMDAyMTQgdGQgMHhmZmZmZmYwMDA0YjU2MzkwCgpUcmFjaW5nIGNvbW1h bmQgbW91c2VkIHBpZCAxNzIyIHRpZCAxMDAyMTAgdGQgMHhmZmZmZmYwMDA0YjU3MzkwCnNjaGVk X3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2gr MHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMx ZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9jdl93YWl0X3NpZygp IGF0IF9jdl93YWl0X3NpZysweDEyMApzZWx0ZHdhaXQoKSBhdCBzZWx0ZHdhaXQrMHhmNgprZXJu X3NlbGVjdCgpIGF0IGtlcm5fc2VsZWN0KzB4NjRkCnNlbGVjdCgpIGF0IHNlbGVjdCsweDVkCnN5 c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjRmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxs KzB4ZTEKLS0tIHN5c2NhbGwgKDkzLCBGcmVlQlNEIEVMRjY0LCBzZWxlY3QpLCByaXAgPSAweDgw MDk3NGNlYywgcnNwID0gMHg3ZmZmZmZmZmU4NDgsIHJicCA9IDB4N2ZmZmZmZmZlZDEwIC0tLQoK VHJhY2luZyBjb21tYW5kIGRidXMtZGFlbW9uIHBpZCAxNTgzIHRpZCAxMDAyMDUgdGQgMHhmZmZm ZmYwMDA0YjU5NzIwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0 Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFf Y2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcr MHhjCl9jdl93YWl0X3NpZygpIGF0IF9jdl93YWl0X3NpZysweDEyMApzZWx0ZHdhaXQoKSBhdCBz ZWx0ZHdhaXQrMHhmNgpwb2xsKCkgYXQgcG9sbCsweDJmOApzeXNjYWxsKCkgYXQgc3lzY2FsbCsw eDI0ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICgy MDksIEZyZWVCU0QgRUxGNjQsIHBvbGwpLCByaXAgPSAweDgwMDk2Y2I0YywgcnNwID0gMHg3ZmZm ZmZmZmU1NTgsIHJicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgZGJ1cy1sYXVuY2ggcGlkIDE1 ODIgdGlkIDEwMDE1OCB0ZCAweGZmZmZmZjAwMDQ2YjMzOTAKc2NoZWRfc3dpdGNoKCkgYXQgc2No ZWRfc3dpdGNoKzB4MTA3Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0 Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3Np ZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX2N2X3dhaXRfc2lnKCkgYXQgX2N2X3dhaXRfc2ln KzB4MTIwCnNlbHRkd2FpdCgpIGF0IHNlbHRkd2FpdCsweGY2Cmtlcm5fc2VsZWN0KCkgYXQga2Vy bl9zZWxlY3QrMHg2NGQKc2VsZWN0KCkgYXQgc2VsZWN0KzB4NWQKc3lzY2FsbCgpIGF0IHN5c2Nh bGwrMHgyNGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2Fs bCAoOTMsIEZyZWVCU0QgRUxGNjQsIHNlbGVjdCksIHJpcCA9IDB4ODAxMWQ3Y2VjLCByc3AgPSAw eDdmZmZmZmZmZTUxOCwgcmJwID0gMHg2IC0tLQoKVHJhY2luZyBjb21tYW5kIGNvbmt5IHBpZCAx NTc2IHRpZCAxMDAxNTMgdGQgMHhmZmZmZmYwMDA0NmI0MzkwCnNjaGVkX3N3aXRjaCgpIGF0IHNj aGVkX3N3aXRjaCsweDEwNwptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX3Rp bWVkd2FpdCgpIGF0IHNsZWVwcV90aW1lZHdhaXQrMHg0Mgpfc2xlZXAoKSBhdCBfc2xlZXArMHgz MDgKQWNwaUV4U3lzdGVtRG9TdXNwZW5kKCkgYXQgQWNwaUV4U3lzdGVtRG9TdXNwZW5kKzB4MTkK QWNwaURzRXhlY0VuZE9wKCkgYXQgQWNwaURzRXhlY0VuZE9wKzB4MzgzCkFjcGlQc1BhcnNlTG9v cCgpIGF0IEFjcGlQc1BhcnNlTG9vcCsweDNhNwpBY3BpUHNQYXJzZUFtbCgpIGF0IEFjcGlQc1Bh cnNlQW1sKzB4MWJkCkFjcGlQc0V4ZWN1dGVNZXRob2QoKSBhdCBBY3BpUHNFeGVjdXRlTWV0aG9k KzB4MWRkCkFjcGlOc0V2YWx1YXRlKCkgYXQgQWNwaU5zRXZhbHVhdGUrMHgxYzIKQWNwaUV2YWx1 YXRlT2JqZWN0KCkgYXQgQWNwaUV2YWx1YXRlT2JqZWN0KzB4YjEKYWNwaV9HZXRJbnRlZ2VyKCkg YXQgYWNwaV9HZXRJbnRlZ2VyKzB4NTQKYWNwaV9hY2FkX2dldF9zdGF0dXMoKSBhdCBhY3BpX2Fj YWRfZ2V0X3N0YXR1cysweDhhCmFjcGlfYWNhZF9nZXRfYWNsaW5lKCkgYXQgYWNwaV9hY2FkX2dl dF9hY2xpbmUrMHg0NQphY3BpX2FjYWRfc3lzY3RsKCkgYXQgYWNwaV9hY2FkX3N5c2N0bCsweDI2 CnN5c2N0bF9yb290KCkgYXQgc3lzY3RsX3Jvb3QrMHgxMjgKdXNlcmxhbmRfc3lzY3RsKCkgYXQg dXNlcmxhbmRfc3lzY3RsKzB4MWMxCl9fc3lzY3RsKCkgYXQgX19zeXNjdGwrMHhhYQpzeXNjYWxs KCkgYXQgc3lzY2FsbCsweDI0ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUx Ci0tLSBzeXNjYWxsICgyMDIsIEZyZWVCU0QgRUxGNjQsIF9fc3lzY3RsKSwgcmlwID0gMHg4MDE4 MTlmOWMsIHJzcCA9IDB4N2ZmZmZmZmY5MDY4LCByYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5k IHN5bmRhZW1vbiBwaWQgMTU3MyB0aWQgMTAwMTI4IHRkIDB4ZmZmZmZmMDAwNDU2YTAwMApzY2hl ZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0Y2grMHgxMDcKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNo KzB4MTZmCnNsZWVwcV9jYXRjaF9zaWduYWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgz MWYKc2xlZXBxX3RpbWVkd2FpdF9zaWcoKSBhdCBzbGVlcHFfdGltZWR3YWl0X3NpZysweDE5Cl9z bGVlcCgpIGF0IF9zbGVlcCsweDFhMwprZXJuX25hbm9zbGVlcCgpIGF0IGtlcm5fbmFub3NsZWVw KzB4MTE4Cm5hbm9zbGVlcCgpIGF0IG5hbm9zbGVlcCsweDZlCnN5c2NhbGwoKSBhdCBzeXNjYWxs KzB4MjRmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwg KDI0MCwgRnJlZUJTRCBFTEY2NCwgbmFub3NsZWVwKSwgcmlwID0gMHg4MDEwOTllM2MsIHJzcCA9 IDB4N2ZmZmZmZmZlYjA4LCByYnAgPSAweDdmZmZmZmZmZWI3MCAtLS0KClRyYWNpbmcgY29tbWFu ZCBvcGVuYm94IHBpZCAxNTU4IHRpZCAxMDAwOTIgdGQgMHhmZmZmZmYwMDA0NjJmNzIwCnNjaGVk X3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2gr MHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMx ZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9jdl93YWl0X3NpZygp IGF0IF9jdl93YWl0X3NpZysweDEyMApzZWx0ZHdhaXQoKSBhdCBzZWx0ZHdhaXQrMHhmNgprZXJu X3NlbGVjdCgpIGF0IGtlcm5fc2VsZWN0KzB4NjRkCnNlbGVjdCgpIGF0IHNlbGVjdCsweDVkCnN5 c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjRmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxs KzB4ZTEKLS0tIHN5c2NhbGwgKDkzLCBGcmVlQlNEIEVMRjY0LCBzZWxlY3QpLCByaXAgPSAweDgw MmU2YWNlYywgcnNwID0gMHg3ZmZmZmZmZmU5NjgsIHJicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1h bmQgeGRtIHBpZCAxNTQ5IHRpZCAxMDAxMjUgdGQgMHhmZmZmZmYwMDA0NTZhYWIwCgpUcmFjaW5n IGNvbW1hbmQgaGFsZC1hZGRvbi1tb3VzZS1zeSBwaWQgMTUxNyB0aWQgMTAwMTY3IHRkIDB4ZmZm ZmZmMDAwNGRmYjAwMAoKVHJhY2luZyBjb21tYW5kIGhhbGQtcnVubmVyIHBpZCAxNTEyIHRpZCAx MDAxODIgdGQgMHhmZmZmZmYwMDA0ZGY4MzkwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRj aCsweDEwNwptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25h bHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBz bGVlcHFfd2FpdF9zaWcrMHhjCl9jdl93YWl0X3NpZygpIGF0IF9jdl93YWl0X3NpZysweDEyMApz ZWx0ZHdhaXQoKSBhdCBzZWx0ZHdhaXQrMHhmNgpwb2xsKCkgYXQgcG9sbCsweDJmOApzeXNjYWxs KCkgYXQgc3lzY2FsbCsweDI0ZgpYZmFzdF9zeXNjYWxsKCkgYXQgWGZhc3Rfc3lzY2FsbCsweGUx Ci0tLSBzeXNjYWxsICgyMDksIEZyZWVCU0QgRUxGNjQsIHBvbGwpLCByaXAgPSAweDgwMGMyYmI0 YywgcnNwID0gMHg3ZmZmZmZmZmViNjgsIHJicCA9IDB4MSAtLS0KClRyYWNpbmcgY29tbWFuZCBj b25zb2xlLWtpdC1kYWVtb24gcGlkIDE1MTEgdGlkIDEwMDE4OSB0ZCAweGZmZmZmZjAwMzZkNjYz OTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA3Cm1pX3N3aXRjaCgpIGF0IG1p X3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWdu YWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVw KCkgYXQgX3NsZWVwKzB4MjZiCnNjdHR5X2lvY3RsKCkgYXQgc2N0dHlfaW9jdGwrMHg2ZWIKdHR5 X2lvY3RsKCkgYXQgdHR5X2lvY3RsKzB4NWQKdHR5ZGV2X2lvY3RsKCkgYXQgdHR5ZGV2X2lvY3Rs KzB4MjEzCmRldmZzX2lvY3RsX2YoKSBhdCBkZXZmc19pb2N0bF9mKzB4NzcKa2Vybl9pb2N0bCgp IGF0IGtlcm5faW9jdGwrMHhmNgppb2N0bCgpIGF0IGlvY3RsKzB4ZmQKc3lzY2FsbCgpIGF0IHN5 c2NhbGwrMHgyNGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lz Y2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQsIGlvY3RsKSwgcmlwID0gMHg4MDE5MjJkMGMsIHJzcCA9 IDB4N2ZmZmZmYmVkZjM4LCByYnAgPSAweDkgLS0tCgpUcmFjaW5nIGNvbW1hbmQgY29uc29sZS1r aXQtZGFlbW9uIHBpZCAxNTExIHRpZCAxMDAyMDMgdGQgMHhmZmZmZmYwMGE4MjdjMzkwCnNjaGVk X3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2gr MHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMx ZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9z bGVlcCsweDI2YgpzY3R0eV9pb2N0bCgpIGF0IHNjdHR5X2lvY3RsKzB4NmViCnR0eV9pb2N0bCgp IGF0IHR0eV9pb2N0bCsweDVkCnR0eWRldl9pb2N0bCgpIGF0IHR0eWRldl9pb2N0bCsweDIxMwpk ZXZmc19pb2N0bF9mKCkgYXQgZGV2ZnNfaW9jdGxfZisweDc3Cmtlcm5faW9jdGwoKSBhdCBrZXJu X2lvY3RsKzB4ZjYKaW9jdGwoKSBhdCBpb2N0bCsweGZkCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4 MjRmClhmYXN0X3N5c2NhbGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDU0 LCBGcmVlQlNEIEVMRjY0LCBpb2N0bCksIHJpcCA9IDB4ODAxOTIyZDBjLCByc3AgPSAweDdmZmZm ZmFmZmYzOCwgcmJwID0gMHgxMCAtLS0KClRyYWNpbmcgY29tbWFuZCBjb25zb2xlLWtpdC1kYWVt b24gcGlkIDE1MTEgdGlkIDEwMDIwMiB0ZCAweGZmZmZmZjAwYTgyN2M3MjAKc2NoZWRfc3dpdGNo KCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA3Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2Zgpz bGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVw cV93YWl0X3NpZygpIGF0IHNsZWVwcV93YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4 MjZiCnNjdHR5X2lvY3RsKCkgYXQgc2N0dHlfaW9jdGwrMHg2ZWIKdHR5X2lvY3RsKCkgYXQgdHR5 X2lvY3RsKzB4NWQKdHR5ZGV2X2lvY3RsKCkgYXQgdHR5ZGV2X2lvY3RsKzB4MjEzCmRldmZzX2lv Y3RsX2YoKSBhdCBkZXZmc19pb2N0bF9mKzB4NzcKa2Vybl9pb2N0bCgpIGF0IGtlcm5faW9jdGwr MHhmNgppb2N0bCgpIGF0IGlvY3RsKzB4ZmQKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyNGYKWGZh c3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNTQsIEZyZWVC U0QgRUxGNjQsIGlvY3RsKSwgcmlwID0gMHg4MDE5MjJkMGMsIHJzcCA9IDB4N2ZmZmZmYjEwZjM4 LCByYnAgPSAweGYgLS0tCgpUcmFjaW5nIGNvbW1hbmQgY29uc29sZS1raXQtZGFlbW9uIHBpZCAx NTExIHRpZCAxMDAyMDEgdGQgMHhmZmZmZmYwMGE4MjdjYWIwCnNjaGVkX3N3aXRjaCgpIGF0IHNj aGVkX3N3aXRjaCsweDEwNwptaV9zd2l0Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2Nh dGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFfY2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9z aWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2YgpzY3R0 eV9pb2N0bCgpIGF0IHNjdHR5X2lvY3RsKzB4NmViCnR0eV9pb2N0bCgpIGF0IHR0eV9pb2N0bCsw eDVkCnR0eWRldl9pb2N0bCgpIGF0IHR0eWRldl9pb2N0bCsweDIxMwpkZXZmc19pb2N0bF9mKCkg YXQgZGV2ZnNfaW9jdGxfZisweDc3Cmtlcm5faW9jdGwoKSBhdCBrZXJuX2lvY3RsKzB4ZjYKaW9j dGwoKSBhdCBpb2N0bCsweGZkCnN5c2NhbGwoKSBhdCBzeXNjYWxsKzB4MjRmClhmYXN0X3N5c2Nh bGwoKSBhdCBYZmFzdF9zeXNjYWxsKzB4ZTEKLS0tIHN5c2NhbGwgKDU0LCBGcmVlQlNEIEVMRjY0 LCBpb2N0bCksIHJpcCA9IDB4ODAxOTIyZDBjLCByc3AgPSAweDdmZmZmZmIyMWYzOCwgcmJwID0g MHhlIC0tLQoKVHJhY2luZyBjb21tYW5kIGNvbnNvbGUta2l0LWRhZW1vbiBwaWQgMTUxMSB0aWQg MTAwMjAwIHRkIDB4ZmZmZmZmMDBhODI3ZDAwMApzY2hlZF9zd2l0Y2goKSBhdCBzY2hlZF9zd2l0 Y2grMHgxMDcKbWlfc3dpdGNoKCkgYXQgbWlfc3dpdGNoKzB4MTZmCnNsZWVwcV9jYXRjaF9zaWdu YWxzKCkgYXQgc2xlZXBxX2NhdGNoX3NpZ25hbHMrMHgzMWYKc2xlZXBxX3dhaXRfc2lnKCkgYXQg c2xlZXBxX3dhaXRfc2lnKzB4Ywpfc2xlZXAoKSBhdCBfc2xlZXArMHgyNmIKc2N0dHlfaW9jdGwo KSBhdCBzY3R0eV9pb2N0bCsweDZlYgp0dHlfaW9jdGwoKSBhdCB0dHlfaW9jdGwrMHg1ZAp0dHlk ZXZfaW9jdGwoKSBhdCB0dHlkZXZfaW9jdGwrMHgyMTMKZGV2ZnNfaW9jdGxfZigpIGF0IGRldmZz X2lvY3RsX2YrMHg3NwprZXJuX2lvY3RsKCkgYXQga2Vybl9pb2N0bCsweGY2CmlvY3RsKCkgYXQg aW9jdGwrMHhmZApzeXNjYWxsKCkgYXQgc3lzY2FsbCsweDI0ZgpYZmFzdF9zeXNjYWxsKCkgYXQg WGZhc3Rfc3lzY2FsbCsweGUxCi0tLSBzeXNjYWxsICg1NCwgRnJlZUJTRCBFTEY2NCwgaW9jdGwp LCByaXAgPSAweDgwMTkyMmQwYywgcnNwID0gMHg3ZmZmZmZiMzJmMzgsIHJicCA9IDB4ZCAtLS0K ClRyYWNpbmcgY29tbWFuZCBjb25zb2xlLWtpdC1kYWVtb24gcGlkIDE1MTEgdGlkIDEwMDE5OSB0 ZCAweGZmZmZmZjAwYTgyN2QzOTAKc2NoZWRfc3dpdGNoKCkgYXQgc2NoZWRfc3dpdGNoKzB4MTA3 Cm1pX3N3aXRjaCgpIGF0IG1pX3N3aXRjaCsweDE2ZgpzbGVlcHFfY2F0Y2hfc2lnbmFscygpIGF0 IHNsZWVwcV9jYXRjaF9zaWduYWxzKzB4MzFmCnNsZWVwcV93YWl0X3NpZygpIGF0IHNsZWVwcV93 YWl0X3NpZysweGMKX3NsZWVwKCkgYXQgX3NsZWVwKzB4MjZiCnNjdHR5X2lvY3RsKCkgYXQgc2N0 dHlfaW9jdGwrMHg2ZWIKdHR5X2lvY3RsKCkgYXQgdHR5X2lvY3RsKzB4NWQKdHR5ZGV2X2lvY3Rs KCkgYXQgdHR5ZGV2X2lvY3RsKzB4MjEzCmRldmZzX2lvY3RsX2YoKSBhdCBkZXZmc19pb2N0bF9m KzB4NzcKa2Vybl9pb2N0bCgpIGF0IGtlcm5faW9jdGwrMHhmNgppb2N0bCgpIGF0IGlvY3RsKzB4 ZmQKc3lzY2FsbCgpIGF0IHN5c2NhbGwrMHgyNGYKWGZhc3Rfc3lzY2FsbCgpIGF0IFhmYXN0X3N5 c2NhbGwrMHhlMQotLS0gc3lzY2FsbCAoNTQsIEZyZWVCU0QgRUxGNjQsIGlvY3RsKSwgcmlwID0g MHg4MDE5MjJkMGMsIHJzcCA9IDB4N2ZmZmZmYjQzZjM4LCByYnAgPSAweGMgLS0tCgpUcmFjaW5n IGNvbW1hbmQgY29uc29sZS1raXQtZGFlbW9uIHBpZCAxNTExIHRpZCAxMDAxOTggdGQgMHhmZmZm ZmYwMGE4MjdkNzIwCnNjaGVkX3N3aXRjaCgpIGF0IHNjaGVkX3N3aXRjaCsweDEwNwptaV9zd2l0 Y2goKSBhdCBtaV9zd2l0Y2grMHgxNmYKc2xlZXBxX2NhdGNoX3NpZ25hbHMoKSBhdCBzbGVlcHFf Y2F0Y2hfc2lnbmFscysweDMxZgpzbGVlcHFfd2FpdF9zaWcoKSBhdCBzbGVlcHFfd2FpdF9zaWcr MHhjCl9zbGVlcCgpIGF0IF9zbGVlcCsweDI2YgpzY3R0eV9pb2N0bCgpIGF0IHNjdHR5X2lvY3Rs KzB4NmViCnR0eV9pb2N0bChtc2didWYudHh0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMDYwMAAAAAAwAAAAAAAAADAAAAAAAAAANDAzNzAAAAAAAAAAMTEzNjQyNDY0MjMAICA3NTYy ACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyAAAAcm9v dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3aGVlbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAENvcHlyaWdodCAoYykgMTk5Mi0yMDEwIFRoZSBGcmVlQlNEIFByb2pl Y3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5 MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2Fs aWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJh ZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgOS4wLUNVUlJFTlQgIzAg cjIwNzA1MU06IFRodSBBcHIgMjIgMDE6NTY6MzAgQ0RUIDIwMTAKICAgIHJvb3RAYWRhbW86L3Vz ci9vYmovdXNyL3NyYy9zeXMvQURBTU8gYW1kNjQKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVu Y3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKQ1BVOiBJbnRlbChSKSBDb3JlKFRNKTIgRHVvIENQVSAg ICAgVTk0MDAgIEAgMS40MEdIeiAoMTQwMC4wNi1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbiA9 ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4MTA2NzYgIEZhbWlseSA9IDYgIE1vZGVsID0gMTcgIFN0 ZXBwaW5nID0gNgogIEZlYXR1cmVzPTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQ QUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxE VFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxIVFQsVE0sUEJFPgogIEZlYXR1cmVzMj0weDhl M2ZkPFNTRTMsRFRFUzY0LE1PTixEU19DUEwsVk1YLFNNWCxFU1QsVE0yLFNTU0UzLENYMTYseFRQ UixQRENNLFNTRTQuMT4KICBBTUQgRmVhdHVyZXM9MHgyMDEwMDgwMDxTWVNDQUxMLE5YLExNPgog IEFNRCBGZWF0dXJlczI9MHgxPExBSEY+CiAgVFNDOiBQLXN0YXRlIGludmFyaWFudApyZWFsIG1l bW9yeSAgPSA0Mjk0OTY3Mjk2ICg0MDk2IE1CKQphdmFpbCBtZW1vcnkgPSA0MDU2NzE1MjY0ICgz ODY4IE1CKQpBQ1BJIEFQSUMgVGFibGU6IDxQVExURCAgCSBBUElDICA+CkZyZWVCU0QvU01QOiBN dWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDIgQ1BVcwpGcmVlQlNEL1NNUDogMSBwYWNr YWdlKHMpIHggMiBjb3JlKHMpCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1MSAoQVApOiBB UElDIElEOiAgMQppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJk CmtiZDEgYXQga2JkbXV4MAphY3BpMDogPERFTEwgUUEwOSAgID4gb24gbW90aGVyYm9hcmQKYWNw aTA6IFtJVEhSRUFEXQphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKVGltZWNvdW50ZXIgIkhQ RVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDkwMApUaW1lY291bnRlciAiQUNQSS1z YWZlIiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDg1MAphY3BpX3RpbWVyMDogPDI0LWJp dCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwOC0weDQwYiBvbiBhY3BpMApjcHUwOiA8 QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKYWNwaV9lYzA6IDxF bWJlZGRlZCBDb250cm9sbGVyOiBHUEUgMHgxYz4gcG9ydCAweDYyLDB4NjYgb24gYWNwaTAKcGNp YjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kw OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMAp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxh eT4gcG9ydCAweDE4MDAtMHgxODA3IG1lbSAweGY4MDAwMDAwLTB4ZjgzZmZmZmYsMHhkMDAwMDAw MC0weGRmZmZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMi4wIG9uIHBjaTAKYWdwMDogPEludGVsIEdN NDUgU1ZHQSBjb250cm9sbGVyPiBvbiB2Z2FwY2kwCmFncDA6IGFwZXJ0dXJlIHNpemUgaXMgMjU2 TSwgZGV0ZWN0ZWQgMzI3NjRrIHN0b2xlbiBtZW1vcnkKYWNwaV92aWRlbzA6IDxBQ1BJIHZpZGVv IGV4dGVuc2lvbj4gb24gdmdhcGNpMApkcm0wOiA8TW9iaWxlIEludGVswq4gR000NSBFeHByZXNz IENoaXBzZXQ+IG9uIHZnYXBjaTAKaW5mbzogW2RybV0gTVNJIGVuYWJsZWQgMSBtZXNzYWdlKHMp CnZnYXBjaTA6IGNoaWxkIGRybTAgcmVxdWVzdGVkIHBjaV9lbmFibGVfYnVzbWFzdGVyCmluZm86 IFtkcm1dIEFHUCBhdCAweGQwMDAwMDAwIDI1Nk1CCmluZm86IFtkcm1dIEluaXRpYWxpemVkIGk5 MTUgMS42LjAgMjAwODA3MzAKdmdhcGNpMTogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IG1lbSAw eGY4NDAwMDAwLTB4Zjg0ZmZmZmYgYXQgZGV2aWNlIDIuMSBvbiBwY2kwCnVoY2kwOiA8SW50ZWwg ODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDE4MjAtMHgxODNmIGlycSAxNiBh dCBkZXZpY2UgMjYuMCBvbiBwY2kwCnVoY2kwOiBbSVRIUkVBRF0KdXNidXMwOiA8SW50ZWwgODI4 MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTAKdWhjaTE6IDxJbnRlbCA4MjgwMUkg KElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4MTg0MC0weDE4NWYgaXJxIDIxIGF0IGRldmlj ZSAyNi4xIG9uIHBjaTAKdWhjaTE6IFtJVEhSRUFEXQp1c2J1czE6IDxJbnRlbCA4MjgwMUkgKElD SDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMQp1aGNpMjogPEludGVsIDgyODAxSSAoSUNIOSkg VVNCIGNvbnRyb2xsZXI+IHBvcnQgMHgxODYwLTB4MTg3ZiBpcnEgMTkgYXQgZGV2aWNlIDI2LjIg b24gcGNpMAp1aGNpMjogW0lUSFJFQURdCnVzYnVzMjogPEludGVsIDgyODAxSSAoSUNIOSkgVVNC IGNvbnRyb2xsZXI+IG9uIHVoY2kyCmVoY2kwOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgMi4w IGNvbnRyb2xsZXI+IG1lbSAweGY4ODA0ODAwLTB4Zjg4MDRiZmYgaXJxIDE5IGF0IGRldmljZSAy Ni43IG9uIHBjaTAKZWhjaTA6IFtJVEhSRUFEXQp1c2J1czM6IEVIQ0kgdmVyc2lvbiAxLjAKdXNi dXMzOiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwCmhk YWMwOiA8SW50ZWwgODI4MDFJIEhpZ2ggRGVmaW5pdGlvbiBBdWRpbyBDb250cm9sbGVyPiBtZW0g MHhmODYwMDAwMC0weGY4NjAzZmZmIGlycSAyMiBhdCBkZXZpY2UgMjcuMCBvbiBwY2kwCmhkYWMw OiBIREEgRHJpdmVyIFJldmlzaW9uOiAyMDEwMDIyNl8wMTQyCmhkYWMwOiBbSVRIUkVBRF0KcGNp YjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTcgYXQgZGV2aWNlIDI4LjAgb24gcGNpMApw Y2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGlycSAxNiBhdCBkZXZpY2UgMjguMSBvbiBwY2kwCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWIyCml3bjA6IDxJbnRlbChSKSBQUk8vV2lyZWxlc3MgNTMwMD4gbWVtIDB4ZjYwMDAwMDAtMHhm NjAwMWZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2k0Cml3bjA6IE1JTU8gM1QzUiwgTW9X LCBhZGRyZXNzIDAwOjIxOjZhOjc3OmNkOjkyCml3bjA6IFtJVEhSRUFEXQppd24wOiAxMWEgcmF0 ZXM6IDZNYnBzIDlNYnBzIDEyTWJwcyAxOE1icHMgMjRNYnBzIDM2TWJwcyA0OE1icHMgNTRNYnBz Cml3bjA6IDExYiByYXRlczogMU1icHMgMk1icHMgNS41TWJwcyAxMU1icHMKaXduMDogMTFnIHJh dGVzOiAxTWJwcyAyTWJwcyA1LjVNYnBzIDExTWJwcyA2TWJwcyA5TWJwcyAxMk1icHMgMThNYnBz IDI0TWJwcyAzNk1icHMgNDhNYnBzIDU0TWJwcwpwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGlycSAxNiBhdCBkZXZpY2UgMjguNSBvbiBwY2kwCnBjaTY6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWIzCmJnZTA6IDxCcm9hZGNvbSBOZXRMaW5rIEdpZ2FiaXQgRXRoZXJuZXQgQ29udHJvbGxlciAg ICAsIEFTSUMgcmV2LiAweDU3ODQxMDA+IG1lbSAweGY4NTAwMDAwLTB4Zjg1MGZmZmYgaXJxIDE3 IGF0IGRldmljZSAwLjAgb24gcGNpNgptaWlidXMwOiA8TUlJIGJ1cz4gb24gYmdlMApicmdwaHkw OiA8QkNNNTc4NCAxMC8xMDAvMTAwMGJhc2VUWCBQSFk+IFBIWSAxIG9uIG1paWJ1czAKYnJncGh5 MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBi YXNlVCwgMTAwMGJhc2VULUZEWCwgYXV0bwpiZ2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoyMjox OTplNTpjYTo1MQpiZ2UwOiBbRklMVEVSXQp1aGNpMzogPEludGVsIDgyODAxSSAoSUNIOSkgVVNC IGNvbnRyb2xsZXI+IHBvcnQgMHgxODgwLTB4MTg5ZiBpcnEgMjMgYXQgZGV2aWNlIDI5LjAgb24g cGNpMAp1aGNpMzogW0lUSFJFQURdCnVzYnVzNDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNv bnRyb2xsZXI+IG9uIHVoY2kzCnVoY2k0OiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJv bGxlcj4gcG9ydCAweDE4YTAtMHgxOGJmIGlycSAxOSBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVo Y2k0OiBbSVRIUkVBRF0KdXNidXM1OiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxl cj4gb24gdWhjaTQKdWhjaTU6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBw b3J0IDB4MThjMC0weDE4ZGYgaXJxIDE4IGF0IGRldmljZSAyOS4yIG9uIHBjaTAKdWhjaTU6IFtJ VEhSRUFEXQp1c2J1czY6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1 aGNpNQplaGNpMTogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0g MHhmODgwNGMwMC0weGY4ODA0ZmZmIGlycSAyMyBhdCBkZXZpY2UgMjkuNyBvbiBwY2kwCmVoY2kx OiBbSVRIUkVBRF0KdXNidXM3OiBFSENJIHZlcnNpb24gMS4wCnVzYnVzNzogPEludGVsIDgyODAx SSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMQpwY2liNDogPEFDUEkgUENJLVBD SSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9uIHBjaTAKcGNpNzogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjQKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2Ew OiA8SVNBIGJ1cz4gb24gaXNhYjAKYWhjaTA6IDxJbnRlbCBJQ0g5TSBBSENJIFNBVEEgY29udHJv bGxlcj4gcG9ydCAweDE4MTgtMHgxODFmLDB4MTgwYy0weDE4MGYsMHgxODEwLTB4MTgxNywweDE4 MDgtMHgxODBiLDB4MThlMC0weDE4ZmYgbWVtIDB4Zjg4MDQwMDAtMHhmODgwNDdmZiBpcnEgMTkg YXQgZGV2aWNlIDMxLjIgb24gcGNpMAphaGNpMDogW0lUSFJFQURdCmFoY2kwOiBBSENJIHYxLjIw IHdpdGggNCAzR2JwcyBwb3J0cywgUG9ydCBNdWx0aXBsaWVyIHN1cHBvcnRlZAphaGNpY2gwOiA8 QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24gYWhjaTAKYWhjaWNoMDogW0lUSFJFQURdCmFo Y2ljaDE6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMSBvbiBhaGNpMAphaGNpY2gxOiBbSVRI UkVBRF0KcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAobm8gZHJpdmVy IGF0dGFjaGVkKQphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwCmFjcGlfYnV0 dG9uMTogPFNsZWVwIEJ1dHRvbj4gb24gYWNwaTAKYWNwaV9saWQwOiA8Q29udHJvbCBNZXRob2Qg TGlkIFN3aXRjaD4gb24gYWNwaTAKYWNwaV9saWQwOiBlbmFibGUgd2FrZSBmYWlsZWQKYWNwaV9h Y2FkMDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwCmJhdHRlcnkwOiA8QUNQSSBDb250cm9sIE1ldGhv ZCBCYXR0ZXJ5PiBvbiBhY3BpMAphY3BpX3R6MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAKYWNw aV90ejE6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCmFjcGlfdHoyOiA8VGhlcm1hbCBab25lPiBv biBhY3BpMAphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4NzcgaXJxIDgg b24gYWNwaTAKYXRydGMwOiBXYXJuaW5nOiBDb3VsZG4ndCBtYXAgSS9PLgphdGtiZGMwOiA8S2V5 Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAph dGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGti ZDA6IFtHSUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJFQURdCnBzbTA6IDxQUy8yIE1vdXNlPiBp cnEgMTIgb24gYXRrYmRjMApwc20wOiBbR0lBTlQtTE9DS0VEXQpwc20wOiBbSVRIUkVBRF0KcHNt MDogbW9kZWwgU3luYXB0aWNzIFRvdWNocGFkLCBkZXZpY2UgSUQgMApzYzA6IDxTeXN0ZW0gY29u c29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xl cywgZmxhZ3M9MHgzMDA+CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgz ZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKZXN0MDogPEVuaGFuY2VkIFNwZWVkU3Rl cCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MAplc3QxOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZy ZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUxClpGUyBOT1RJQ0U6IFByZWZldGNoIGlzIGRpc2FibGVk IGJ5IGRlZmF1bHQgaWYgbGVzcyB0aGFuIDRHQiBvZiBSQU0gaXMgcHJlc2VudDsKICAgICAgICAg ICAgdG8gZW5hYmxlLCBhZGQgInZmcy56ZnMucHJlZmV0Y2hfZGlzYWJsZT0wIiB0byAvYm9vdC9s b2FkZXIuY29uZi4KWkZTIGZpbGVzeXN0ZW0gdmVyc2lvbiAzClpGUyBzdG9yYWdlIHBvb2wgdmVy c2lvbiAxNApUaW1lY291bnRlcnMgdGljayBldmVyeSAxMC4wMDAgbXNlYwp2Ym94TmV0Rmx0SW5p dEdsb2JhbHNBbmRJZGMgZmFpbGVkIC0yCm1vZHVsZV9yZWdpc3Rlcl9pbml0OiBNT0RfTE9BRCAo bmdfdmJveG5ldGZsdCwgMHhmZmZmZmZmZjgwYzMzNTgwLCAweGZmZmZmZmZmODBlMzAzMjApIGVy cm9yIDIyCnZib3hkcnY6IGZBc3luYz0wIG9mZk1pbj0weGU3IG9mZk1heD0weDIzMAp2Ym94bmV0 MDogRXRoZXJuZXQgYWRkcmVzczogMGE6MDA6Mjc6MDA6MDA6MDAKaGRhYzA6IEhEQSBDb2RlYyAj MDogSURUIDkySEQ3M0MxCmhkYWMwOiBIREEgQ29kZWMgIzE6IEludGVsIEc0NSBIRE1JCnBjbTA6 IDxIREEgSURUIDkySEQ3M0MxIFBDTSAjMCBBbmFsb2c+IGF0IGNhZCAwIG5pZCAxIG9uIGhkYWMw CnBjbTE6IDxIREEgSW50ZWwgRzQ1IEhETUkgUENNICMwIEhETUk+IGF0IGNhZCAxIG5pZCAxIG9u IGhkYWMwCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMxOiAxMk1icHMg RnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czI6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVz YnVzMzogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVzYnVzNDogMTJNYnBzIEZ1bGwgU3Bl ZWQgVVNCIHYxLjAKdXNidXM1OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czY6IDEy TWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNzogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2 Mi4wCmFkYTAgYXQgYWhjaWNoMCBidXMgMCBzY2J1czAgdGFyZ2V0IDAgbHVuIDAKYWRhMDogPFNB TVNVTkcgU1NEIFBCMjItQ1MzIFRNIDI1NkdCIFZCTTIzRDFRPiBBVEEtNyBTQVRBIDIueCBkZXZp Y2UKYWRhMDogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTUsIFBJTyA4MTky Ynl0ZXMpCmFkYTA6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGEwOiAyNDQxOThNQiAoNTAw MTE4MTkyIDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpClNNUDogQVAgQ1BVICMx IExhdW5jaGVkIQp1Z2VuMC4xOiA8SW50ZWw+IGF0IHVzYnVzMAp1aHViMDogPEludGVsIFVIQ0kg cm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdWdl bjEuMTogPEludGVsPiBhdCB1c2J1czEKdWh1YjE6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFz cyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxCnVnZW4yLjE6IDxJbnRlbD4g YXQgdXNidXMydWdlbjMuMTogPEludGVsPiBhdCB1c2J1czMKCnVodWIyOiA8SW50ZWwgVUhDSSBy b290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMgp1aHVi MzogPEludGVsIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAx PiBvbiB1c2J1czMKdWdlbjQuMTogPEludGVsPiBhdCB1c2J1czR1Z2VuNS4xOiA8SW50ZWw+IGF0 IHVzYnVzNQoKdWh1YjQ6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAw LzEuMDAsIGFkZHIgMT4gb24gdXNidXM0CnVodWI1OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xh c3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNQp1Z2VuNi4xOiA8SW50ZWw+ IGF0IHVzYnVzNnVnZW43LjE6IDxJbnRlbD4gYXQgdXNidXM3Cgp1aHViNjogPEludGVsIFVIQ0kg cm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czYKdWh1 Yjc6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIg MT4gb24gdXNidXM3ClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNyB1c2J1czYgdXNidXM1 IHVzYnVzNCB1c2J1czMgdXNidXMyIHVzYnVzMSB1c2J1czAKdWh1YjE6IDIgcG9ydHMgd2l0aCAy IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUs IHNlbGYgcG93ZXJlZAp1aHViNTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2Vy ZWQKdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI0OiAy IHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNjogMiBwb3J0cyB3aXRo IDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM3 IHVzYnVzMwpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czcgdXNidXMzCnVodWIzOiA2IHBv cnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNzogNiBwb3J0cyB3aXRoIDYg cmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM3CnVz Yl9hbGxvY19kZXZpY2U6IGdldHRpbmcgZGV2aWNlIGRlc2NyaXB0b3IgYXQgYWRkciAyIGZhaWxl ZCwgVVNCX0VSUl9USU1FT1VUClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNwpSb290IG1v dW50IHdhaXRpbmcgZm9yOiB1c2J1czcKdXNiZF9yZXFfcmVfZW51bWVyYXRlOiBnZXR0aW5nIGRl dmljZSBkZXNjcmlwdG9yIGF0IGFkZHIgMiBmYWlsZWQsIFVTQl9FUlJfVElNRU9VVApSb290IG1v dW50IHdhaXRpbmcgZm9yOiB1c2J1czcKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM3CnVz YmRfcmVxX3JlX2VudW1lcmF0ZTogZ2V0dGluZyBkZXZpY2UgZGVzY3JpcHRvciBhdCBhZGRyIDIg ZmFpbGVkLCBVU0JfRVJSX1RJTUVPVVQKdWdlbjcuMjogPChudWxsKT4gYXQgdXNidXM3IChkaXNj b25uZWN0ZWQpCnVodWJfcmVhdHRhY2hfcG9ydDogY291bGQgbm90IGFsbG9jYXRlIG5ldyBkZXZp Y2UKVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9ncHQvZGlzazAKPDExOD5TZXR0 aW5nIGhvc3R1dWlkOiAxNmQ3NjczOC0zN2I2LTExZGYtYjMxNS0wMDIyMTllNWNhNTEuCjwxMTg+ U2V0dGluZyBob3N0aWQ6IDB4MjQ2MWJmZTYuCjwxMTg+RW50cm9weSBoYXJ2ZXN0aW5nOgo8MTE4 PiBpbnRlcnJ1cHRzCjwxMTg+IGV0aGVybmV0CjwxMTg+IHBvaW50X3RvX3BvaW50CjwxMTg+IGtp Y2tzdGFydAo8MTE4Pi4KPDExOD5TdGFydGluZyBmaWxlIHN5c3RlbSBjaGVja3M6CjwxMTg+L2Rl di9ncHQvZGlzazA6IEZJTEUgU1lTVEVNIENMRUFOOyBTS0lQUElORyBDSEVDS1MKPDExOD4vZGV2 L2dwdC9kaXNrMDogY2xlYW4sIDE3MTc3NTQgZnJlZSAoMTgwMiBmcmFncywgMjE0NDk0IGJsb2Nr cywgMC4xJSBmcmFnbWVudGF0aW9uKQo8MTE4Pk1vdW50aW5nIGxvY2FsIGZpbGUgc3lzdGVtczoK PDExOD4uCjwxMTg+U2V0dGluZyBob3N0bmFtZTogYWRhbW8KPDExOD4uCndsYW4wOiBFdGhlcm5l dCBhZGRyZXNzOiAwMDoyMTo2YTo3NzpjZDo5Mgo8MTE4PlN0YXJ0aW5nIHdwYV9zdXBwbGljYW50 Lgppd24wOiByYWRpbyBpcyBkaXNhYmxlZCBieSBoYXJkd2FyZSBzd2l0Y2gKPDExOD5TdGFydGlu ZyBOZXR3b3JrOiBsbzAgaXduMCBiZ2UwIHZib3huZXQwLgo8MTE4PmxvMDogZmxhZ3M9ODA0OTxV UCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE2Mzg0CjwxMTg+CW9w dGlvbnM9MzxSWENTVU0sVFhDU1VNPgo8MTE4PglpbmV0IDEyNy4wLjAuMSBuZXRtYXNrIDB4ZmYw MDAwMDAgCjwxMTg+CWluZXQ2IDo6MSBwcmVmaXhsZW4gMTI4IAo8MTE4PglpbmV0NiBmZTgwOjox JWxvMCBwcmVmaXhsZW4gNjQgc2NvcGVpZCAweDQgCjwxMTg+CW5kNiBvcHRpb25zPTIxPFBFUkZP Uk1OVUQsQVVUT19MSU5LTE9DQUw+CjwxMTg+aXduMDogZmxhZ3M9ODgwMzxVUCxCUk9BRENBU1Qs U0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAyMjkwCjwxMTg+CWV0aGVyIDAwOjIxOjZh Ojc3OmNkOjkyCjwxMTg+CW1lZGlhOiBJRUVFIDgwMi4xMSBXaXJlbGVzcyBFdGhlcm5ldCBhdXRv c2VsZWN0IG1vZGUgMTFiCjwxMTg+CXN0YXR1czogYXNzb2NpYXRlZAo8MTE4PmJnZTA6IGZsYWdz PTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10 dSAxNTAwCjwxMTg+CW9wdGlvbnM9YzAxOWI8UlhDU1VNLFRYQ1NVTSxWTEFOX01UVSxWTEFOX0hX VEFHR0lORyxWTEFOX0hXQ1NVTSxUU080LFZMQU5fSFdUU08sTElOS1NUQVRFPgo8MTE4PglldGhl ciAwMDoyMjoxOTplNTpjYTo1MQo8MTE4PgltZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVjdCAobm9u ZSkKPDExOD4Jc3RhdHVzOiBubyBjYXJyaWVyCjwxMTg+dmJveG5ldDA6IGZsYWdzPTg4MDI8QlJP QURDQVNULFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAo8MTE4PglldGhlciAw YTowMDoyNzowMDowMDowMAo8MTE4PlN0YXJ0aW5nIGRldmQuCjwxMTg+U3RhcnRpbmcgTmV0d29y azogdmJveG5ldDAuCjwxMTg+dmJveG5ldDA6IGZsYWdzPTg4MDI8QlJPQURDQVNULFNJTVBMRVgs TVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAo8MTE4PglldGhlciAwYTowMDoyNzowMDowMDow MAo8MTE4PmFkZCBuZXQgOjpmZmZmOjAuMC4wLjA6IGdhdGV3YXkgOjoxCjwxMTg+YWRkIG5ldCA6 OjAuMC4wLjA6IGdhdGV3YXkgOjoxCjwxMTg+YWRkIG5ldCBmZTgwOjo6IGdhdGV3YXkgOjoxCjwx MTg+YWRkIG5ldCBmZjAyOjo6IGdhdGV3YXkgOjoxCjwxMTg+RUxGIGxkY29uZmlnIHBhdGg6IC9s aWIgL3Vzci9saWIgL3Vzci9saWIvY29tcGF0IC91c3IvbG9jYWwvbGliIC91c3IvbG9jYWwvbGli L3F0NCAvdXNyL2xvY2FsL2xpYi92aXJ0dWFsYm94CjwxMTg+MzItYml0IGNvbXBhdGliaWxpdHkg bGRjb25maWcgcGF0aDogL3Vzci9saWIzMgo8MTE4PkNyZWF0aW5nIGFuZC9vciB0cmltbWluZyBs b2cgZmlsZXMKPDExOD4uCjwxMTg+U3RhcnRpbmcgc3lzbG9nZC4KPDExOD5ObyBjb3JlIGR1bXBz IGZvdW5kLgo8MTE4PkFkZGl0aW9uYWwgQUJJIHN1cHBvcnQ6CjwxMTg+IGxpbnV4CjwxMTg+Lgo8 MTE4PlN0YXJ0aW5nIHJwY2JpbmQuCjwxMTg+TkZTIGFjY2VzcyBjYWNoZSB0aW1lPTYwCjwxMTg+ U3RhcnRpbmcgYW1kLgo8MTE4PkNsZWFyaW5nIC90bXAgKFggcmVsYXRlZCkuCjwxMTg+L2V0Yy9y YzogV0FSTklORzogL2V0Yy9leHBvcnRzIGlzIG5vdCByZWFkYWJsZS4KPDExOD4vZXRjL3JjOiBX QVJOSU5HOiBmYWlsZWQgcHJlY21kIHJvdXRpbmUgZm9yIG1vdW50ZAo8MTE4PlN0YXJ0aW5nIG5m c2QuCjwxMTg+U3RhcnRpbmcgZGJ1cy4KPDExOD5TdGFydGluZyBoYWxkLgo8MTE4PlVwZGF0aW5n IG1vdGQ6CjwxMTg+Lgo8MTE4PlN0YXJ0aW5nIHBvd2VyZC4KPDExOD5Db25maWd1cmluZyBzeXNj b25zOgo8MTE4PiBrZXlyYXRlCjwxMTg+IGJsYW5rdGltZQo8MTE4Pi4KPDExOD5TdGFydGluZyBz c2hkLgo8MTE4PlN0YXJ0aW5nIGNyb24uCjwxMTg+U3RhcnRpbmcgYmFja2dyb3VuZCBmaWxlIHN5 c3RlbSBjaGVja3MgaW4gNjAgc2Vjb25kcy4KPDExOD4KPDExOD5UaHUgQXByIDIyIDIxOjEwOjA0 IENEVCAyMDEwCmRybTA6IFtJVEhSRUFEXQppd24wOiBSRiBzd2l0Y2g6IHJhZGlvIGVuYWJsZWQK dWdlbjYuMjogPEJyb2FkY29tPiBhdCB1c2J1czYKdWh1Yjg6IDxCcm9hZGNvbSBCQ00yMDQ2QjEs IGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAyPiBvbiB1c2J1czYKdWh1Yjg6IDMgcG9y dHMgd2l0aCAwIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVnZW42LjM6IDx2ZW5kb3IgMHg0MTNj PiBhdCB1c2J1czYKdWtiZDA6IDx2ZW5kb3IgMHg0MTNjIHByb2R1Y3QgMHg4MTU3LCBjbGFzcyAw LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMz4gb24gdXNidXM2CmtiZDIgYXQgdWtiZDAKdWdlbjYu NDogPHZlbmRvciAweDQxM2M+IGF0IHVzYnVzNgp1bXMwOiA8dmVuZG9yIDB4NDEzYyBwcm9kdWN0 IDB4ODE1OCwgY2xhc3MgMC8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDQ+IG9uIHVzYnVzNgp1bXMw OiAzIGJ1dHRvbnMgYW5kIFtYWV0gY29vcmRpbmF0ZXMgSUQ9Mgo8NT53bGFuMDogbGluayBzdGF0 ZSBjaGFuZ2VkIHRvIFVQCkdFT01fU0NIRUQ6IEluaXRpYWxpemluZyBnbG9iYWwgZGF0YS4KR0VP TV9TQ0hFRDogTG9hZGluZzogbXAgPSAweGZmZmZmZmZmODEwMzYwMDAsIGdfc2NoZWRfY2xhc3Mg PSAweGZmZmZmZmZmODEwMzYwMDAuCjw1PndsYW4wOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9X Tgo8NT53bGFuMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCjw1PndsYW4wOiBsaW5rIHN0YXRl IGNoYW5nZWQgdG8gRE9XTgo8NT53bGFuMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCjw1Pnds YW4wOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9XTgo8NT53bGFuMDogbGluayBzdGF0ZSBjaGFu Z2VkIHRvIFVQCjw1PndsYW4wOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9XTgo8NT53bGFuMDog bGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCkdFT01fU0NIRUQ6IE1vZGV2ZW50IDAuCkdFT01fU0NI RUQ6IExvYWRlZCBtb2R1bGUgcnIgZXJyb3IgMC4KR0VPTV9TQ0hFRDogRGV2aWNlIGFkYTAuc2No ZWQuIGNyZWF0ZWQuCmRybTA6IFtJVEhSRUFEXQprbGR1bmxvYWQ6IGF0dGVtcHQgdG8gdW5sb2Fk IGZpbGUgdGhhdCB3YXMgbG9hZGVkIGJ5IHRoZSBrZXJuZWwKYmF0dGVyeTA6IGNyaXRpY2FsbHkg bG93IGNoYXJnZSEKZHJtMDogW0lUSFJFQURdCldhcm5pbmc6IG1lbW9yeSB0eXBlIGlwcnRoZWFw IGxlYWtlZCBtZW1vcnkgb24gZGVzdHJveSAoMiBhbGxvY2F0aW9ucywgNjQgYnl0ZXMgbGVha2Vk KS4KdmJveGRydjogZkFzeW5jPTAgb2ZmTWluPTB4MTg4IG9mZk1heD0weDk2MQp2Ym94bmV0MDog RXRoZXJuZXQgYWRkcmVzczogMGE6MDA6Mjc6MDA6MDA6MDAKPDExOD5BcHIgMjMgMDA6MDQ6MDAg YWRhbW8gZGF0ZTogZGF0ZSBzZXQgYnkgYnJhbmRvbgprZXJuZWwgdHJhcCAxMiB3aXRoIGludGVy cnVwdHMgZGlzYWJsZWQKCgpGYXRhbCB0cmFwIDEyOiBwYWdlIGZhdWx0IHdoaWxlIGluIGtlcm5l bCBtb2RlCmNwdWlkID0gMDsgYXBpYyBpZCA9IDAwCmZhdWx0IHZpcnR1YWwgYWRkcmVzcwk9IDB4 MTAKZmF1bHQgY29kZQkJPSBzdXBlcnZpc29yIHJlYWQgZGF0YSwgcGFnZSBub3QgcHJlc2VudApp bnN0cnVjdGlvbiBwb2ludGVyCT0gMHgyMDoweGZmZmZmZmZmODAyZTgzNDEKc3RhY2sgcG9pbnRl cgkgICAgICAgID0gMHgyODoweGZmZmZmZjgwMDAwMzliNTAKZnJhbWUgcG9pbnRlcgkgICAgICAg ID0gMHgyODoweGZmZmZmZjgwMDAwMzliYTAKY29kZSBzZWdtZW50CQk9IGJhc2UgMHgwLCBsaW1p dCAweGZmZmZmLCB0eXBlIDB4MWIKCQkJPSBEUEwgMCwgcHJlcyAxLCBsb25nIDEsIGRlZjMyIDAs IGdyYW4gMQpwcm9jZXNzb3IgZWZsYWdzCT0gcmVzdW1lLCBJT1BMID0gMApjdXJyZW50IHByb2Nl c3MJCT0gMTEgKGlkbGU6IGNwdTApCmZpcm13YXJlIGVycm9yIGxvZzoKICBlcnJvciB0eXBlICAg ICAgPSAiTk1JX0lOVEVSUlVQVF9XREciICgweDAwMDAwMDA0KQogIHByb2dyYW0gY291bnRlciA9 IDB4MDAwMDA2RTQKICBzb3VyY2UgbGluZSAgICAgPSAweDAwMDAwMTI2CiAgZXJyb3IgZGF0YSAg ICAgID0gMHgwMDAwMDAwMjAzMjMwMDAwCiAgYnJhbmNoIGxpbmsgICAgID0gMHgwMDAwMDVBQTAw MDAwNkU4CiAgaW50ZXJydXB0IGxpbmsgID0gMHgwMDAwMDhCMjAwMDAyMkJBCiAgdGltZSAgICAg ICAgICAgID0gNDI1NzA0OTkyMgpkcml2ZXIgc3RhdHVzOgogIHR4IHJpbmcgIDA6IHFpZD0wICBj dXI9MjQzIHF1ZXVlZD0wICAKICB0eCByaW5nICAxOiBxaWQ9MSAgY3VyPTAgICBxdWV1ZWQ9MCAg CiAgdHggcmluZyAgMjogcWlkPTIgIGN1cj0wICAgcXVldWVkPTAgIAogIHR4IHJpbmcgIDM6IHFp ZD0zICBjdXI9MjUgIHF1ZXVlZD0wICAKICB0eCByaW5nICA0OiBxaWQ9NCAgY3VyPTI1MSBxdWV1 ZWQ9MCAgCiAgdHggcmluZyAgNTogcWlkPTUgIGN1cj0wICAgcXVldWVkPTAgIAogIHR4IHJpbmcg IDY6IHFpZD02ICBjdXI9MCAgIHF1ZXVlZD0wICAKICB0eCByaW5nICA3OiBxaWQ9NyAgY3VyPTAg ICBxdWV1ZWQ9MCAgCiAgdHggcmluZyAgODogcWlkPTggIGN1cj0wICAgcXVldWVkPTAgIAogIHR4 IHJpbmcgIDk6IHFpZD05ICBjdXI9MCAgIHF1ZXVlZD0wICAKICB0eCByaW5nIDEwOiBxaWQ9MTAg Y3VyPTAgICBxdWV1ZWQ9MCAgCiAgdHggcmluZyAxMTogcWlkPTExIGN1cj0wICAgcXVldWVkPTAg IAogIHR4IHJpbmcgMTI6IHFpZD0xMiBjdXI9MCAgIHF1ZXVlZD0wICAKICB0eCByaW5nIDEzOiBx aWQ9MTMgY3VyPTAgICBxdWV1ZWQ9MCAgCiAgdHggcmluZyAxNDogcWlkPTE0IGN1cj0wICAgcXVl dWVkPTAgIAogIHR4IHJpbmcgMTU6IHFpZD0xNSBjdXI9MCAgIHF1ZXVlZD0wICAKICB0eCByaW5n IDE2OiBxaWQ9MTYgY3VyPTAgICBxdWV1ZWQ9MCAgCiAgdHggcmluZyAxNzogcWlkPTE3IGN1cj0w ICAgcXVldWVkPTAgIAogIHR4IHJpbmcgMTg6IHFpZD0xOCBjdXI9MCAgIHF1ZXVlZD0wICAKICB0 eCByaW5nIDE5OiBxaWQ9MTkgY3VyPTAgICBxdWV1ZWQ9MCAgCiAgcnggcmluZzogY3VyPTEyCmtl cm5lbCB0cmFwIDEyIHdpdGggaW50ZXJydXB0cyBkaXNhYmxlZAoKCkZhdGFsIHRyYXAgMTI6IHBh Z2UgZmF1bHQgd2hpbGUgaW4ga2VybmVsIG1vZGUKY3B1aWQgPSAwOyBhcGljIGlkID0gMDAKZmF1 bHQgdmlydHVhbCBhZGRyZXNzCT0gMHgxMApmYXVsdCBjb2RlCQk9IHN1cGVydmlzb3IgcmVhZCBk YXRhLCBwYWdlIG5vdCBwcmVzZW50Cmluc3RydWN0aW9uIHBvaW50ZXIJPSAweDIwOjB4ZmZmZmZm ZmY4MDJlODM0MQpzdGFjayBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZmODAwMDAzOWI1 MApmcmFtZSBwb2ludGVyCSAgICAgICAgPSAweDI4OjB4ZmZmZmZmODAwMDAzOWJhMApjb2RlIHNl Z21lbnQJCT0gYmFzZSAweDAsIGxpbWl0IDB4ZmZmZmYsIHR5cGUgMHgxYgoJCQk9IERQTCAwLCBw cmVzIDEsIGxvbmcgMSwgZGVmMzIgMCwgZ3JhbiAxCnByb2Nlc3NvciBlZmxhZ3MJPSB0cmFjZSB0 cmFwLCByZXN1bWUsIElPUEwgPSAwCmN1cnJlbnQgcHJvY2VzcwkJPSAxMSAoaWRsZTogY3B1MCkK a2VybmVsIHRyYXAgMTIgd2l0aCBpbnRlcnJ1cHRzIGRpc2FibGVkCgoKRmF0YWwgdHJhcCAxMjog cGFnZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQpjcHVpZCA9IDA7IGFwaWMgaWQgPSAwMApm YXVsdCB2aXJ0dWFsIGFkZHJlc3MJPSAweDEwCmZhdWx0IGNvZGUJCT0gc3VwZXJ2aXNvciByZWFk IGRhdGEsIHBhZ2Ugbm90IHByZXNlbnQKaW5zdHJ1Y3Rpb24gcG9pbnRlcgk9IDB4MjA6MHhmZmZm ZmZmZjgwMmU4MzQxCnN0YWNrIHBvaW50ZXIJICAgICAgICA9IDB4Mjg6MHhmZmZmZmY4MDAwMDM5 YjUwCmZyYW1lIHBvaW50ZXIJICAgICAgICA9IDB4Mjg6MHhmZmZmZmY4MDAwMDM5YmEwCmNvZGUg c2VnbWVudAkJPSBiYXNlIDB4MCwgbGltaXQgMHhmZmZmZiwgdHlwZSAweDFiCgkJCT0gRFBMIDAs IHByZXMgMSwgbG9uZyAxLCBkZWYzMiAwLCBncmFuIDEKcHJvY2Vzc29yIGVmbGFncwk9IHRyYWNl IHRyYXAsIHJlc3VtZSwgSU9QTCA9IDAKY3VycmVudCBwcm9jZXNzCQk9IDExIChpZGxlOiBjcHUw KQprZXJuZWwgdHJhcCAxMiB3aXRoIGludGVycnVwdHMgZGlzYWJsZWQKCgpGYXRhbCB0cmFwIDEy OiBwYWdlIGZhdWx0IHdoaWxlIGluIGtlcm5lbCBtb2RlCmNwdWlkID0gMDsgYXBpYyBpZCA9IDAw CmZhdWx0IHZpcnR1YWwgYWRkcmVzcwk9IDB4MTAKZmF1bHQgY29kZQkJPSBzdXBlcnZpc29yIHJl YWQgZGF0YSwgcGFnZSBub3QgcHJlc2VudAppbnN0cnVjdGlvbiBwb2ludGVyCT0gMHgyMDoweGZm ZmZmZmZmODAyZTgzNDEKc3RhY2sgcG9pbnRlcgkgICAgICAgID0gMHgyODoweGZmZmZmZjgwMDAw MzliNTAKZnJhbWUgcG9pbnRlcgkgICAgICAgID0gMHgyODoweGZmZmZmZjgwMDAwMzliYTAKY29k ZSBzZWdtZW50CQk9IGJhc2UgMHgwLCBsaW1pdCAweGZmZmZmLCB0eXBlIDB4MWIKCQkJPSBEUEwg MCwgcHJlcyAxLCBsb25nIDEsIGRlZjMyIDAsIGdyYW4gMQpwcm9jZXNzb3IgZWZsYWdzCT0gdHJh Y2UgdHJhcCwgcmVzdW1lLCBJT1BMID0gMApjdXJyZW50IHByb2Nlc3MJCT0gMTEgKGlkbGU6IGNw dTApCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZlcnNpb24udHh0AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwNjAwAAAAADAAAAAAAAAAMAAAAAAAAAAxNTAAAAAA AAAAAAAxMTM2NDI0NjQyMwAgIDc2MTQAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAdXN0YXIAAAByb290AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHdoZWVs AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARnJlZUJTRCA5LjAtQ1VSUkVO VCAjMCByMjA3MDUxTTogVGh1IEFwciAyMiAwMTo1NjozMCBDRFQgMjAxMAogICAgcm9vdEBhZGFt bzovdXNyL29iai91c3Ivc3JjL3N5cy9BREFNTwoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --0016e64652882349f90484f2d1ef-- From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 04:42:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB575106564A for ; Sat, 24 Apr 2010 04:42:51 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE9B8FC16 for ; Sat, 24 Apr 2010 04:42:51 +0000 (UTC) Received: by qyk11 with SMTP id 11so12420865qyk.13 for ; Fri, 23 Apr 2010 21:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Wzw/GrsonQyqbstRTxuKZrK62JFaU9Jwm5dhIZiWjlU=; b=D76FSA5QauNLuWzBmU3ODOsrUfB61LEu+PKviggvla8gYVS9A1DXNKr/9IOk262bhq NRHzxD9MWZVDKng2L/4OQI+QCSOuRQcnSd5KoIlfDi3ggLtcSmo/um7mSmhjhOIcW5mr II9p9eV29SUKjf+BwNJPHU4QcuCnDsUF8fsZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vmEBbN9tMNL3dhc4EetAVB3mUPtiLIxRplz3+0RbK3vEVzsKP0LFDuc/+Ase2P8PV4 WI5y2NUYWyDBVWGRyByN5gpVKv7gt/S6j6zg1W+HYY7cRbqnuYZ4cMZFHyAbLLfWfuGL xJhXBHVM+9Lw01UsQaXt7BIKEN/gxY0DKiMys= MIME-Version: 1.0 Received: by 10.229.227.5 with SMTP id iy5mr1219812qcb.29.1272084170365; Fri, 23 Apr 2010 21:42:50 -0700 (PDT) Received: by 10.229.233.11 with HTTP; Fri, 23 Apr 2010 21:42:50 -0700 (PDT) In-Reply-To: References: <20100418081400.GA40496@mx.techwires.net> Date: Fri, 23 Apr 2010 21:42:50 -0700 Message-ID: From: Garrett Cooper To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= , Bernhard Schmidt , freebsd-stable@freebsd.org Subject: Re: iwn firmware instability with an up-to-date stable kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 04:42:51 -0000 On Fri, Apr 23, 2010 at 8:05 PM, Brandon Gooch wrote: > 2010/4/23 Garrett Cooper : >> 2010/4/23 Garrett Cooper : >>> 2010/4/18 Olivier Cochard-Labb=E9 : >>>> 2010/4/18 Bernhard Schmidt : >>>>> Are you able to reproduce this on demand? As in type a few commands a= nd >>>>> the firmware error occurs? >>>>> >>>> >>>> No, I'm not able to reproduce on demand this problem. >>> >>> I'm seeing similar issues on occasion with my Lenovo as well: >>> >>> Apr 23 19:25:24 garrcoop-fbsd kernel: firmware error log: >>> Apr 23 19:25:24 garrcoop-fbsd kernel: error type =A0 =A0 =A0=3D >>> "NMI_INTERRUPT_WDG" (0x00000004) >>> Apr 23 19:25:24 garrcoop-fbsd kernel: program counter =3D 0x0000046C >>> Apr 23 19:25:24 garrcoop-fbsd kernel: source line =A0 =A0 =3D 0x000000D= 0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: error data =A0 =A0 =A0=3D 0x00000= 00207030000 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: branch link =A0 =A0 =3D 0x0000837= 0000004C2 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: interrupt link =A0=3D 0x000006DA0= 00018B8 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: time =A0 =A0 =A0 =A0 =A0 =A0=3D 4= 287402440 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: driver status: >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A00: qid=3D0 =A0cur=3D1 = =A0 queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A01: qid=3D1 =A0cur=3D0 = =A0 queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A02: qid=3D2 =A0cur=3D0 = =A0 queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A03: qid=3D3 =A0cur=3D36= =A0queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A04: qid=3D4 =A0cur=3D12= 3 queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A05: qid=3D5 =A0cur=3D0 = =A0 queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A06: qid=3D6 =A0cur=3D0 = =A0 queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A07: qid=3D7 =A0cur=3D0 = =A0 queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A08: qid=3D8 =A0cur=3D0 = =A0 queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A09: qid=3D9 =A0cur=3D0 = =A0 queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 10: qid=3D10 cur=3D0 =A0 = queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 11: qid=3D11 cur=3D0 =A0 = queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 12: qid=3D12 cur=3D0 =A0 = queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 13: qid=3D13 cur=3D0 =A0 = queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 14: qid=3D14 cur=3D0 =A0 = queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 15: qid=3D15 cur=3D0 =A0 = queued=3D0 >>> Apr 23 19:25:24 garrcoop-fbsd kernel: rx ring: cur=3D8 >>> >>> This may be because the system was under load (I was installing a port >>> shortly before the connection dropped). I'll try poking at this >>> further because it's going to be an annoying productivity loss :/. >> >> =A0 =A0Sorry... should have included more helpful details. >> Thanks, >> -Garrett >> >> dmesg: >> >> iwn0: mem 0xdf2fe000-0xdf2fffff irq 17 >> at device 0.0 on pci3 >> iwn0: MIMO 2T3R, MoW1, address 00:1d:e0:7d:9f:c7 >> iwn0: [ITHREAD] >> iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps >> iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >> iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps >> 24Mbps 36Mbps 48Mbps 54Mbps >> >> pciconf -lv snippet: >> >> iwn0@pci0:3:0:0: =A0 =A0 =A0 =A0class=3D0x028000 card=3D0x11108086 chip= =3D0x42308086 >> rev=3D0x61 hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' >> =A0 =A0device =A0 =A0 =3D 'Intel Wireless WiFi Link 4965AGN (Intel 4965A= GN)' >> =A0 =A0class =A0 =A0 =A0=3D network >> cbb0@pci0:21:0:0: =A0 =A0 =A0 class=3D0x060700 card=3D0x20c617aa chip=3D= 0x04761180 >> rev=3D0xba hdr=3D0x02 >> >> uname -a: >> >> $ uname -a >> FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #0 >> r207006: Wed Apr 21 13:18:44 PDT 2010 >> root@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86 =A0i386 > > I'm actually looking at this right now. For me, it's actually > happening when my machine stays on overnight (or for long periods of > time, idle). > > Also, it seems to be causing the kernel to panic, although I'm now > wondering if the Machine Check Architecture is somehow catching this > device error and causing an exception (hw.mca.enabled=3D1)(?) -- not > possible, right ??? > > Whatever the case, I can't seem to get the firmware error to occur > with iwn(4) debugging or wlandebug options enabled, so who knows > exactly what leads to this. > > I know Bernhard has worked hard on this driver, it's a shame that this > freaky bug has bit us all now, without leaving many clues :( > > I've attached a textdump for posterity if nothing else :) Connectivity appears to be shoddy in my neck of the woods (kind of ironic... but meh). Just running buildworld, buildkernel, then doing a tcpdump in parallel causes the pseudo device to go up and down a lot. I assume this isn't standard behavior? Just for reference buildworld was started shortly after 19:39:05, and it finished at 21:29. The interface has also gone up and down once since then while the system's been basically idle. Thanks, -Garrett Apr 23 19:39:05 garrcoop-fbsd kernel: wlan0: promiscuous mode enabled Apr 23 19:41:04 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 19:41:04 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:7f:81:90 (SSID=3D'blizzard' freq=3D2412 MHz) Apr 23 19:41:04 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Apr 23 19:41:04 garrcoop-fbsd kernel: wlan0: link state changed to DOWN Apr 23 19:41:14 garrcoop-fbsd wpa_supplicant[17226]: Authentication with 00:00:00:00:00:00 timed out. Apr 23 19:41:14 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 19:41:14 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:7f:81:90 (SSID=3D'blizzard' freq=3D2412 MHz) Apr 23 19:41:14 garrcoop-fbsd wpa_supplicant[17226]: Associated with 00:1a:30:7f:81:90 Apr 23 19:41:14 garrcoop-fbsd kernel: wlan0: link state changed to UP Apr 23 19:41:14 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-STARTED EAP authentication started Apr 23 19:41:14 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Apr 23 19:41:14 garrcoop-fbsd wpa_supplicant[17226]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Apr 23 19:41:14 garrcoop-fbsd wpa_supplicant[17226]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Apr 23 19:41:14 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Apr 23 19:41:14 garrcoop-fbsd wpa_supplicant[17226]: WPA: Key negotiation completed with 00:1a:30:7f:81:90 [PTK=3DTKIP GTK=3DTKIP] Apr 23 19:41:14 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-CONNECTED - Connection to 00:1a:30:7f:81:90 completed (reauth) [id=3D0 id_str=3D] Apr 23 19:41:18 garrcoop-fbsd dhclient: New IP Address (wlan0): 173.37.1.93 Apr 23 19:41:18 garrcoop-fbsd dhclient: New Subnet Mask (wlan0): 255.255.25= 4.0 Apr 23 19:41:18 garrcoop-fbsd dhclient: New Broadcast Address (wlan0): 255.255.255.255 Apr 23 19:41:18 garrcoop-fbsd dhclient: New Routers (wlan0): 173.37.0.1 Apr 23 19:44:03 garrcoop-fbsd sudo: garrcoop : TTY=3Dpts/3 ; PWD=3D/usr/home/garrcoop ; USER=3Droot ; COMMAND=3D/usr/local/bin/bash Apr 23 19:46:06 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 19:46:06 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:7f:7d:d0 (SSID=3D'blizzard' freq=3D2462 MHz) Apr 23 19:46:06 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Apr 23 19:46:06 garrcoop-fbsd kernel: wlan0: link state changed to DOWN Apr 23 19:46:16 garrcoop-fbsd wpa_supplicant[17226]: Authentication with 00:00:00:00:00:00 timed out. Apr 23 19:46:16 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 19:46:16 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:7f:7d:d0 (SSID=3D'blizzard' freq=3D2462 MHz) Apr 23 19:46:16 garrcoop-fbsd wpa_supplicant[17226]: Associated with 00:1a:30:7f:7d:d0 Apr 23 19:46:16 garrcoop-fbsd kernel: wlan0: link state changed to UP Apr 23 19:46:16 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-STARTED EAP authentication started Apr 23 19:46:16 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Apr 23 19:46:16 garrcoop-fbsd wpa_supplicant[17226]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Apr 23 19:46:16 garrcoop-fbsd wpa_supplicant[17226]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Apr 23 19:46:16 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Apr 23 19:46:16 garrcoop-fbsd wpa_supplicant[17226]: WPA: Key negotiation completed with 00:1a:30:7f:7d:d0 [PTK=3DTKIP GTK=3DTKIP] Apr 23 19:46:16 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-CONNECTED - Connection to 00:1a:30:7f:7d:d0 completed (reauth) [id=3D0 id_str=3D] Apr 23 19:46:16 garrcoop-fbsd dhclient: New IP Address (wlan0): 173.37.1.93 Apr 23 19:46:16 garrcoop-fbsd dhclient: New Subnet Mask (wlan0): 255.255.25= 4.0 Apr 23 19:46:16 garrcoop-fbsd dhclient: New Broadcast Address (wlan0): 255.255.255.255 Apr 23 19:46:16 garrcoop-fbsd dhclient: New Routers (wlan0): 173.37.0.1 Apr 23 19:51:08 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 19:56:10 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 19:56:10 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:7f:81:90 (SSID=3D'blizzard' freq=3D2412 MHz) Apr 23 19:56:10 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Apr 23 19:56:10 garrcoop-fbsd kernel: wlan0: link state changed to DOWN Apr 23 19:56:20 garrcoop-fbsd wpa_supplicant[17226]: Authentication with 00:00:00:00:00:00 timed out. Apr 23 19:56:20 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 19:56:20 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:7f:81:90 (SSID=3D'blizzard' freq=3D2412 MHz) Apr 23 19:56:20 garrcoop-fbsd wpa_supplicant[17226]: Associated with 00:1a:30:7f:81:90 Apr 23 19:56:20 garrcoop-fbsd kernel: wlan0: link state changed to UP Apr 23 19:56:20 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-STARTED EAP authentication started Apr 23 19:56:20 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Apr 23 19:56:20 garrcoop-fbsd wpa_supplicant[17226]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Apr 23 19:56:20 garrcoop-fbsd wpa_supplicant[17226]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Apr 23 19:56:20 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Apr 23 19:56:20 garrcoop-fbsd wpa_supplicant[17226]: WPA: Key negotiation completed with 00:1a:30:7f:81:90 [PTK=3DTKIP GTK=3DTKIP] Apr 23 19:56:20 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-CONNECTED - Connection to 00:1a:30:7f:81:90 completed (reauth) [id=3D0 id_str=3D] Apr 23 19:56:27 garrcoop-fbsd dhclient: New IP Address (wlan0): 173.37.1.93 Apr 23 19:56:27 garrcoop-fbsd dhclient: New Subnet Mask (wlan0): 255.255.25= 4.0 Apr 23 19:56:27 garrcoop-fbsd dhclient: New Broadcast Address (wlan0): 255.255.255.255 Apr 23 19:56:27 garrcoop-fbsd dhclient: New Routers (wlan0): 173.37.0.1 Apr 23 20:01:12 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 20:06:14 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 20:11:16 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 20:11:16 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:c0:fd:c0 (SSID=3D'blizzard' freq=3D2462 MHz) Apr 23 20:11:16 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Apr 23 20:11:16 garrcoop-fbsd kernel: wlan0: link state changed to DOWN Apr 23 20:11:26 garrcoop-fbsd wpa_supplicant[17226]: Authentication with 00:00:00:00:00:00 timed out. Apr 23 20:11:26 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 20:11:26 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:c0:fd:c0 (SSID=3D'blizzard' freq=3D2462 MHz) Apr 23 20:11:26 garrcoop-fbsd wpa_supplicant[17226]: Associated with 00:1a:30:c0:fd:c0 Apr 23 20:11:26 garrcoop-fbsd kernel: wlan0: link state changed to UP Apr 23 20:11:26 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-STARTED EAP authentication started Apr 23 20:11:26 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Apr 23 20:11:26 garrcoop-fbsd wpa_supplicant[17226]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Apr 23 20:11:26 garrcoop-fbsd wpa_supplicant[17226]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Apr 23 20:11:26 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Apr 23 20:11:26 garrcoop-fbsd wpa_supplicant[17226]: WPA: Key negotiation completed with 00:1a:30:c0:fd:c0 [PTK=3DTKIP GTK=3DTKIP] Apr 23 20:11:26 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-CONNECTED - Connection to 00:1a:30:c0:fd:c0 completed (reauth) [id=3D0 id_str=3D] Apr 23 20:11:31 garrcoop-fbsd dhclient: New IP Address (wlan0): 173.37.1.93 Apr 23 20:11:31 garrcoop-fbsd dhclient: New Subnet Mask (wlan0): 255.255.25= 4.0 Apr 23 20:11:31 garrcoop-fbsd dhclient: New Broadcast Address (wlan0): 255.255.255.255 Apr 23 20:11:31 garrcoop-fbsd dhclient: New Routers (wlan0): 173.37.0.1 Apr 23 20:16:18 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 20:21:20 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 20:26:22 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 20:31:24 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 20:41:28 garrcoop-fbsd last message repeated 2 times Apr 23 20:46:31 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 20:46:31 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:7f:7d:d0 (SSID=3D'blizzard' freq=3D2462 MHz) Apr 23 20:46:31 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Apr 23 20:46:31 garrcoop-fbsd kernel: wlan0: link state changed to DOWN Apr 23 20:46:41 garrcoop-fbsd wpa_supplicant[17226]: Authentication with 00:00:00:00:00:00 timed out. Apr 23 20:46:41 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 20:46:41 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:7f:7d:d0 (SSID=3D'blizzard' freq=3D2462 MHz) Apr 23 20:46:41 garrcoop-fbsd wpa_supplicant[17226]: Associated with 00:1a:30:7f:7d:d0 Apr 23 20:46:41 garrcoop-fbsd kernel: wlan0: link state changed to UP Apr 23 20:46:41 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-STARTED EAP authentication started Apr 23 20:46:41 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Apr 23 20:46:41 garrcoop-fbsd wpa_supplicant[17226]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Apr 23 20:46:41 garrcoop-fbsd wpa_supplicant[17226]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Apr 23 20:46:43 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Apr 23 20:46:43 garrcoop-fbsd wpa_supplicant[17226]: WPA: Key negotiation completed with 00:1a:30:7f:7d:d0 [PTK=3DTKIP GTK=3DTKIP] Apr 23 20:46:43 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-CONNECTED - Connection to 00:1a:30:7f:7d:d0 completed (reauth) [id=3D0 id_str=3D] Apr 23 20:46:45 garrcoop-fbsd dhclient: New IP Address (wlan0): 173.37.1.93 Apr 23 20:46:45 garrcoop-fbsd dhclient: New Subnet Mask (wlan0): 255.255.25= 4.0 Apr 23 20:46:45 garrcoop-fbsd dhclient: New Broadcast Address (wlan0): 255.255.255.255 Apr 23 20:46:45 garrcoop-fbsd dhclient: New Routers (wlan0): 173.37.0.1 Apr 23 20:51:33 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 20:51:33 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:c0:fd:c0 (SSID=3D'blizzard' freq=3D2462 MHz) Apr 23 20:51:33 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Apr 23 20:51:33 garrcoop-fbsd kernel: wlan0: link state changed to DOWN Apr 23 20:51:43 garrcoop-fbsd wpa_supplicant[17226]: Authentication with 00:00:00:00:00:00 timed out. Apr 23 20:51:43 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 20:51:43 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:c0:fd:c0 (SSID=3D'blizzard' freq=3D2462 MHz) Apr 23 20:51:43 garrcoop-fbsd wpa_supplicant[17226]: Associated with 00:1a:30:c0:fd:c0 Apr 23 20:51:43 garrcoop-fbsd kernel: wlan0: link state changed to UP Apr 23 20:51:43 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-STARTED EAP authentication started Apr 23 20:51:43 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Apr 23 20:51:43 garrcoop-fbsd wpa_supplicant[17226]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Apr 23 20:51:43 garrcoop-fbsd wpa_supplicant[17226]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Apr 23 20:51:43 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Apr 23 20:51:43 garrcoop-fbsd wpa_supplicant[17226]: WPA: Key negotiation completed with 00:1a:30:c0:fd:c0 [PTK=3DTKIP GTK=3DTKIP] Apr 23 20:51:43 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-CONNECTED - Connection to 00:1a:30:c0:fd:c0 completed (reauth) [id=3D0 id_str=3D] Apr 23 20:51:51 garrcoop-fbsd dhclient: New IP Address (wlan0): 173.37.1.93 Apr 23 20:51:51 garrcoop-fbsd dhclient: New Subnet Mask (wlan0): 255.255.25= 4.0 Apr 23 20:51:51 garrcoop-fbsd dhclient: New Broadcast Address (wlan0): 255.255.255.255 Apr 23 20:51:51 garrcoop-fbsd dhclient: New Routers (wlan0): 173.37.0.1 Apr 23 20:56:35 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 21:01:37 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 21:04:22 garrcoop-fbsd wpa_supplicant[17226]: WPA: Group rekeying completed with 00:1a:30:c0:fd:c0 [GTK=3DTKIP] Apr 23 21:06:39 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 21:06:39 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:7f:7d:d0 (SSID=3D'blizzard' freq=3D2462 MHz) Apr 23 21:06:39 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Apr 23 21:06:39 garrcoop-fbsd kernel: wlan0: link state changed to DOWN Apr 23 21:06:49 garrcoop-fbsd wpa_supplicant[17226]: Authentication with 00:00:00:00:00:00 timed out. Apr 23 21:06:49 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 21:06:49 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:7f:7d:d0 (SSID=3D'blizzard' freq=3D2462 MHz) Apr 23 21:06:49 garrcoop-fbsd wpa_supplicant[17226]: Associated with 00:1a:30:7f:7d:d0 Apr 23 21:06:49 garrcoop-fbsd kernel: wlan0: link state changed to UP Apr 23 21:06:49 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-STARTED EAP authentication started Apr 23 21:06:49 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Apr 23 21:06:49 garrcoop-fbsd wpa_supplicant[17226]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Apr 23 21:06:49 garrcoop-fbsd wpa_supplicant[17226]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Apr 23 21:06:49 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Apr 23 21:06:49 garrcoop-fbsd wpa_supplicant[17226]: WPA: Key negotiation completed with 00:1a:30:7f:7d:d0 [PTK=3DTKIP GTK=3DTKIP] Apr 23 21:06:49 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-CONNECTED - Connection to 00:1a:30:7f:7d:d0 completed (reauth) [id=3D0 id_str=3D] Apr 23 21:06:49 garrcoop-fbsd dhclient: New IP Address (wlan0): 173.37.1.93 Apr 23 21:06:49 garrcoop-fbsd dhclient: New Subnet Mask (wlan0): 255.255.25= 4.0 Apr 23 21:06:49 garrcoop-fbsd dhclient: New Broadcast Address (wlan0): 255.255.255.255 Apr 23 21:06:49 garrcoop-fbsd dhclient: New Routers (wlan0): 173.37.0.1 Apr 23 21:11:41 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 21:16:43 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 21:16:43 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:7f:81:90 (SSID=3D'blizzard' freq=3D2412 MHz) Apr 23 21:16:43 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Apr 23 21:16:43 garrcoop-fbsd kernel: wlan0: link state changed to DOWN Apr 23 21:16:53 garrcoop-fbsd wpa_supplicant[17226]: Authentication with 00:00:00:00:00:00 timed out. Apr 23 21:16:53 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 21:16:53 garrcoop-fbsd wpa_supplicant[17226]: Trying to associate with 00:1a:30:7f:81:90 (SSID=3D'blizzard' freq=3D2412 MHz) Apr 23 21:16:53 garrcoop-fbsd wpa_supplicant[17226]: Associated with 00:1a:30:7f:81:90 Apr 23 21:16:53 garrcoop-fbsd kernel: wlan0: link state changed to UP Apr 23 21:16:53 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-STARTED EAP authentication started Apr 23 21:16:53 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected Apr 23 21:16:53 garrcoop-fbsd wpa_supplicant[17226]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) Apr 23 21:16:53 garrcoop-fbsd wpa_supplicant[17226]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed Apr 23 21:16:53 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Apr 23 21:16:53 garrcoop-fbsd wpa_supplicant[17226]: WPA: Key negotiation completed with 00:1a:30:7f:81:90 [PTK=3DTKIP GTK=3DTKIP] Apr 23 21:16:53 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-CONNECTED - Connection to 00:1a:30:7f:81:90 completed (reauth) [id=3D0 id_str=3D] Apr 23 21:16:53 garrcoop-fbsd dhclient: New IP Address (wlan0): 173.37.1.93 Apr 23 21:16:53 garrcoop-fbsd dhclient: New Subnet Mask (wlan0): 255.255.25= 4.0 Apr 23 21:16:53 garrcoop-fbsd dhclient: New Broadcast Address (wlan0): 255.255.255.255 Apr 23 21:16:53 garrcoop-fbsd dhclient: New Routers (wlan0): 173.37.0.1 Apr 23 21:18:34 garrcoop-fbsd wpa_supplicant[17226]: WPA: Group rekeying completed with 00:1a:30:7f:81:90 [GTK=3DTKIP] Apr 23 21:21:45 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 21:26:47 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 21:31:49 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S Apr 23 21:32:57 garrcoop-fbsd kernel: wlan0: promiscuous mode disabled Apr 23 21:36:50 garrcoop-fbsd wpa_supplicant[17226]: CTRL-EVENT-SCAN-RESULT= S From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 04:59:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9331E106564A for ; Sat, 24 Apr 2010 04:59:19 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 445908FC0C for ; Sat, 24 Apr 2010 04:59:18 +0000 (UTC) Received: by qyk11 with SMTP id 11so12430883qyk.13 for ; Fri, 23 Apr 2010 21:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=O45gcc2PC0GeRlDLqVYWnBlK96F0j4v1MNrIy+WBUN0=; b=VVHjFt06gYVUsoB6hvdnNM/r/mepV4yEpF7xxlERkTQ0OJNXYmPfz3MmHqUhzMR0gE 7MCKvG0EEe/mLk2o0kNxzsnpFDzht5xTidMAQr5k8aikUDp+4hG9JUp+wsI7hCQWIDHj kEA4o0Puf7SWt0qWkcHc2Bxdyafg261rty29Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=URsVOeqerkvHAbpKnwQGLh4jeb628u1hSVyy1VxmIp/3W8Wr0NVjiXkI9gn7vdVEVp nYN4HQMYpKmgmHz0XNgOSQIdijdUQ1latvNRpfE8w71m3EeO/d5mNRKsF2lg0yqPQA2j XIqjnlVnN/TPNwZgokKwjuiGxHXN8Fj8Ji0Ms= MIME-Version: 1.0 Received: by 10.229.230.65 with SMTP id jl1mr1260489qcb.7.1272085158001; Fri, 23 Apr 2010 21:59:18 -0700 (PDT) Received: by 10.229.233.11 with HTTP; Fri, 23 Apr 2010 21:59:17 -0700 (PDT) In-Reply-To: References: <20100418081400.GA40496@mx.techwires.net> Date: Fri, 23 Apr 2010 21:59:17 -0700 Message-ID: From: Garrett Cooper To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= , Bernhard Schmidt , freebsd-stable@freebsd.org Subject: Re: iwn firmware instability with an up-to-date stable kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 04:59:19 -0000 On Fri, Apr 23, 2010 at 9:42 PM, Garrett Cooper wrote: > On Fri, Apr 23, 2010 at 8:05 PM, Brandon Gooch > wrote: >> 2010/4/23 Garrett Cooper : >>> 2010/4/23 Garrett Cooper : >>>> 2010/4/18 Olivier Cochard-Labb=E9 : >>>>> 2010/4/18 Bernhard Schmidt : >>>>>> Are you able to reproduce this on demand? As in type a few commands = and >>>>>> the firmware error occurs? >>>>>> >>>>> >>>>> No, I'm not able to reproduce on demand this problem. >>>> >>>> I'm seeing similar issues on occasion with my Lenovo as well: >>>> >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: firmware error log: >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: error type =A0 =A0 =A0=3D >>>> "NMI_INTERRUPT_WDG" (0x00000004) >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: program counter =3D 0x0000046C >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: source line =A0 =A0 =3D 0x000000= D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: error data =A0 =A0 =A0=3D 0x0000= 000207030000 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: branch link =A0 =A0 =3D 0x000083= 70000004C2 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: interrupt link =A0=3D 0x000006DA= 000018B8 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: time =A0 =A0 =A0 =A0 =A0 =A0=3D = 4287402440 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: driver status: >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A00: qid=3D0 =A0cur=3D1= =A0 queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A01: qid=3D1 =A0cur=3D0= =A0 queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A02: qid=3D2 =A0cur=3D0= =A0 queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A03: qid=3D3 =A0cur=3D3= 6 =A0queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A04: qid=3D4 =A0cur=3D1= 23 queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A05: qid=3D5 =A0cur=3D0= =A0 queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A06: qid=3D6 =A0cur=3D0= =A0 queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A07: qid=3D7 =A0cur=3D0= =A0 queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A08: qid=3D8 =A0cur=3D0= =A0 queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A09: qid=3D9 =A0cur=3D0= =A0 queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 10: qid=3D10 cur=3D0 =A0= queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 11: qid=3D11 cur=3D0 =A0= queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 12: qid=3D12 cur=3D0 =A0= queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 13: qid=3D13 cur=3D0 =A0= queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 14: qid=3D14 cur=3D0 =A0= queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 15: qid=3D15 cur=3D0 =A0= queued=3D0 >>>> Apr 23 19:25:24 garrcoop-fbsd kernel: rx ring: cur=3D8 >>>> >>>> This may be because the system was under load (I was installing a port >>>> shortly before the connection dropped). I'll try poking at this >>>> further because it's going to be an annoying productivity loss :/. >>> >>> =A0 =A0Sorry... should have included more helpful details. >>> Thanks, >>> -Garrett >>> >>> dmesg: >>> >>> iwn0: mem 0xdf2fe000-0xdf2fffff irq 17 >>> at device 0.0 on pci3 >>> iwn0: MIMO 2T3R, MoW1, address 00:1d:e0:7d:9f:c7 >>> iwn0: [ITHREAD] >>> iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps >>> iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >>> iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps >>> 24Mbps 36Mbps 48Mbps 54Mbps >>> >>> pciconf -lv snippet: >>> >>> iwn0@pci0:3:0:0: =A0 =A0 =A0 =A0class=3D0x028000 card=3D0x11108086 chip= =3D0x42308086 >>> rev=3D0x61 hdr=3D0x00 >>> =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' >>> =A0 =A0device =A0 =A0 =3D 'Intel Wireless WiFi Link 4965AGN (Intel 4965= AGN)' >>> =A0 =A0class =A0 =A0 =A0=3D network >>> cbb0@pci0:21:0:0: =A0 =A0 =A0 class=3D0x060700 card=3D0x20c617aa chip= =3D0x04761180 >>> rev=3D0xba hdr=3D0x02 >>> >>> uname -a: >>> >>> $ uname -a >>> FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #0 >>> r207006: Wed Apr 21 13:18:44 PDT 2010 >>> root@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86 =A0i386 >> >> I'm actually looking at this right now. For me, it's actually >> happening when my machine stays on overnight (or for long periods of >> time, idle). >> >> Also, it seems to be causing the kernel to panic, although I'm now >> wondering if the Machine Check Architecture is somehow catching this >> device error and causing an exception (hw.mca.enabled=3D1)(?) -- not >> possible, right ??? >> >> Whatever the case, I can't seem to get the firmware error to occur >> with iwn(4) debugging or wlandebug options enabled, so who knows >> exactly what leads to this. >> >> I know Bernhard has worked hard on this driver, it's a shame that this >> freaky bug has bit us all now, without leaving many clues :( >> >> I've attached a textdump for posterity if nothing else :) > > =A0 =A0Connectivity appears to be shoddy in my neck of the woods (kind of > ironic... but meh). Just running buildworld, buildkernel, then doing a > tcpdump in parallel causes the pseudo device to go up and down a lot. > I assume this isn't standard behavior? > =A0 =A0Just for reference buildworld was started shortly after 19:39:05, > and it finished at 21:29. The interface has also gone up and down once > since then while the system's been basically idle. Hmmm... I'm seem to be in an excellent position to reproduce this issue. I've reproduced it twice by merely bringing the interface up and down several times using: ifconfig_wlan0=3D"WPA DHCP" instead of my usual: ifconfig_wlan0=3D"WPA ssid DHCP" Maybe others who are experiencing the issue should try that? I'll do more testing when I get home... Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 05:08:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF93D106564A for ; Sat, 24 Apr 2010 05:08:53 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-yw0-f193.google.com (mail-yw0-f193.google.com [209.85.211.193]) by mx1.freebsd.org (Postfix) with ESMTP id 90D8A8FC12 for ; Sat, 24 Apr 2010 05:08:53 +0000 (UTC) Received: by ywh31 with SMTP id 31so5169513ywh.3 for ; Fri, 23 Apr 2010 22:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iWXzvh9wanA7tQJcWjVIRNuxHMEupsXFY77g1c7InfA=; b=rZUPbVazvwkUYoLPCtGmNNzCmuVU3gKvHFJQBt4AzUjqlvLg7RdPSGfkvfH0xdoCqK 0GyD4KLBPH72bXlvng7maEXZqhtv83w1fpZtVqeZB4rx7SBTBmuMDVAs5krO2MeQWw+5 f44F8iBCnC/gCP3q+J4YwgKXk54BdxWchBzss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dZw4qgc8b7w7ESTR+vegH1Afe+FnXSwIVm1p7hcFuUgUbCvoil+WRkmJuh1Acu4Hti k6ugJqLpNB5xzcCqk0DmFf88aDFmvxL5prOhhvpTbttZOIxU2pB4dHE1YgObo1PUeaT1 obsvXUmQVLzFzfAiA+XUN9RcigVKxp3D4gcd4= MIME-Version: 1.0 Received: by 10.101.131.35 with SMTP id i35mr1318251ann.39.1272085732542; Fri, 23 Apr 2010 22:08:52 -0700 (PDT) Received: by 10.231.113.36 with HTTP; Fri, 23 Apr 2010 22:08:52 -0700 (PDT) In-Reply-To: References: <20100418081400.GA40496@mx.techwires.net> Date: Sat, 24 Apr 2010 05:08:52 +0000 Message-ID: From: Brandon Gooch To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= , Bernhard Schmidt , freebsd-stable@freebsd.org Subject: Re: iwn firmware instability with an up-to-date stable kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 05:08:54 -0000 On Sat, Apr 24, 2010 at 4:59 AM, Garrett Cooper wrote: > On Fri, Apr 23, 2010 at 9:42 PM, Garrett Cooper wrot= e: >> On Fri, Apr 23, 2010 at 8:05 PM, Brandon Gooch >> wrote: >>> 2010/4/23 Garrett Cooper : >>>> 2010/4/23 Garrett Cooper : >>>>> 2010/4/18 Olivier Cochard-Labb=E9 : >>>>>> 2010/4/18 Bernhard Schmidt : >>>>>>> Are you able to reproduce this on demand? As in type a few commands= and >>>>>>> the firmware error occurs? >>>>>>> >>>>>> >>>>>> No, I'm not able to reproduce on demand this problem. >>>>> >>>>> I'm seeing similar issues on occasion with my Lenovo as well: >>>>> >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: firmware error log: >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: error type =A0 =A0 =A0=3D >>>>> "NMI_INTERRUPT_WDG" (0x00000004) >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: program counter =3D 0x0000046C >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: source line =A0 =A0 =3D 0x00000= 0D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: error data =A0 =A0 =A0=3D 0x000= 0000207030000 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: branch link =A0 =A0 =3D 0x00008= 370000004C2 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: interrupt link =A0=3D 0x000006D= A000018B8 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: time =A0 =A0 =A0 =A0 =A0 =A0=3D= 4287402440 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: driver status: >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A00: qid=3D0 =A0cur=3D= 1 =A0 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A01: qid=3D1 =A0cur=3D= 0 =A0 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A02: qid=3D2 =A0cur=3D= 0 =A0 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A03: qid=3D3 =A0cur=3D= 36 =A0queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A04: qid=3D4 =A0cur=3D= 123 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A05: qid=3D5 =A0cur=3D= 0 =A0 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A06: qid=3D6 =A0cur=3D= 0 =A0 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A07: qid=3D7 =A0cur=3D= 0 =A0 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A08: qid=3D8 =A0cur=3D= 0 =A0 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A09: qid=3D9 =A0cur=3D= 0 =A0 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 10: qid=3D10 cur=3D0 = =A0 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 11: qid=3D11 cur=3D0 = =A0 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 12: qid=3D12 cur=3D0 = =A0 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 13: qid=3D13 cur=3D0 = =A0 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 14: qid=3D14 cur=3D0 = =A0 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 15: qid=3D15 cur=3D0 = =A0 queued=3D0 >>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: rx ring: cur=3D8 >>>>> >>>>> This may be because the system was under load (I was installing a por= t >>>>> shortly before the connection dropped). I'll try poking at this >>>>> further because it's going to be an annoying productivity loss :/. >>>> >>>> =A0 =A0Sorry... should have included more helpful details. >>>> Thanks, >>>> -Garrett >>>> >>>> dmesg: >>>> >>>> iwn0: mem 0xdf2fe000-0xdf2fffff irq 17 >>>> at device 0.0 on pci3 >>>> iwn0: MIMO 2T3R, MoW1, address 00:1d:e0:7d:9f:c7 >>>> iwn0: [ITHREAD] >>>> iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps >>>> iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >>>> iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps >>>> 24Mbps 36Mbps 48Mbps 54Mbps >>>> >>>> pciconf -lv snippet: >>>> >>>> iwn0@pci0:3:0:0: =A0 =A0 =A0 =A0class=3D0x028000 card=3D0x11108086 chi= p=3D0x42308086 >>>> rev=3D0x61 hdr=3D0x00 >>>> =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' >>>> =A0 =A0device =A0 =A0 =3D 'Intel Wireless WiFi Link 4965AGN (Intel 496= 5AGN)' >>>> =A0 =A0class =A0 =A0 =A0=3D network >>>> cbb0@pci0:21:0:0: =A0 =A0 =A0 class=3D0x060700 card=3D0x20c617aa chip= =3D0x04761180 >>>> rev=3D0xba hdr=3D0x02 >>>> >>>> uname -a: >>>> >>>> $ uname -a >>>> FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #0 >>>> r207006: Wed Apr 21 13:18:44 PDT 2010 >>>> root@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86 =A0i386 >>> >>> I'm actually looking at this right now. For me, it's actually >>> happening when my machine stays on overnight (or for long periods of >>> time, idle). >>> >>> Also, it seems to be causing the kernel to panic, although I'm now >>> wondering if the Machine Check Architecture is somehow catching this >>> device error and causing an exception (hw.mca.enabled=3D1)(?) -- not >>> possible, right ??? >>> >>> Whatever the case, I can't seem to get the firmware error to occur >>> with iwn(4) debugging or wlandebug options enabled, so who knows >>> exactly what leads to this. >>> >>> I know Bernhard has worked hard on this driver, it's a shame that this >>> freaky bug has bit us all now, without leaving many clues :( >>> >>> I've attached a textdump for posterity if nothing else :) >> >> =A0 =A0Connectivity appears to be shoddy in my neck of the woods (kind o= f >> ironic... but meh). Just running buildworld, buildkernel, then doing a >> tcpdump in parallel causes the pseudo device to go up and down a lot. >> I assume this isn't standard behavior? >> =A0 =A0Just for reference buildworld was started shortly after 19:39:05, >> and it finished at 21:29. The interface has also gone up and down once >> since then while the system's been basically idle. > > =A0 =A0Hmmm... I'm seem to be in an excellent position to reproduce this > issue. I've reproduced it twice by merely bringing the interface up > and down several times using: > > ifconfig_wlan0=3D"WPA DHCP" > > =A0 =A0instead of my usual: > > ifconfig_wlan0=3D"WPA ssid DHCP" > > =A0 =A0Maybe others who are experiencing the issue should try that? I'll > do more testing when I get home... > Thanks, > -Garrett > My rc.conf is: ifconfig_wlan0=3D"WPA DHCP" ...as well, although I haven't tried manually taking the interface down and bringing it back up. Are you waiting for the device to associate and begin passing traffic before you each up/down cycle? -Brandon From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 06:27:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A114B1065677 for ; Sat, 24 Apr 2010 06:27:33 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 51C2D8FC24 for ; Sat, 24 Apr 2010 06:27:33 +0000 (UTC) Received: by qyk11 with SMTP id 11so12479572qyk.13 for ; Fri, 23 Apr 2010 23:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IXNT7FlFmqOn1X35AFxXwzsPuFs69B1SG7u90JHQfpw=; b=qKFL2Z5R1XidSeWlr9WI60kVn2TvOzROGmg8daJgOySUUNjlhwFTTB5EV36qSdbwA1 QyKCd1MBh00I74MbzqX0YkxhMZHq4phaut3elnuBzzAKm8fyUzb8MEk71EfNA2x6hJ39 fVEi21x4qgC805fi89Y5Y9uCByrntkZwElXDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VkHHUazDNWxqvph34Ld6T2X4jqJzzAIQhxmhJ54Y3O+Om3LceCXPjEok/nsOL7b5XT jgMTs7bTh2LENGOMfqrida3jBiwp10g0K85DtVKTYw0l57fuv6Ba2sJpgcD2IwEdWEsN Q2yu4UAKNIwwfM6I5BO4RpWD/75vgOQ1GyLnU= MIME-Version: 1.0 Received: by 10.229.227.5 with SMTP id iy5mr1296024qcb.29.1272090452339; Fri, 23 Apr 2010 23:27:32 -0700 (PDT) Received: by 10.229.233.11 with HTTP; Fri, 23 Apr 2010 23:27:32 -0700 (PDT) In-Reply-To: References: <20100418081400.GA40496@mx.techwires.net> Date: Fri, 23 Apr 2010 23:27:32 -0700 Message-ID: From: Garrett Cooper To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= , Bernhard Schmidt , freebsd-stable@freebsd.org Subject: Re: iwn firmware instability with an up-to-date stable kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 06:27:33 -0000 On Fri, Apr 23, 2010 at 10:08 PM, Brandon Gooch wrote: > On Sat, Apr 24, 2010 at 4:59 AM, Garrett Cooper wrot= e: >> On Fri, Apr 23, 2010 at 9:42 PM, Garrett Cooper wro= te: >>> On Fri, Apr 23, 2010 at 8:05 PM, Brandon Gooch >>> wrote: >>>> 2010/4/23 Garrett Cooper : >>>>> 2010/4/23 Garrett Cooper : >>>>>> 2010/4/18 Olivier Cochard-Labb=E9 : >>>>>>> 2010/4/18 Bernhard Schmidt : >>>>>>>> Are you able to reproduce this on demand? As in type a few command= s and >>>>>>>> the firmware error occurs? >>>>>>>> >>>>>>> >>>>>>> No, I'm not able to reproduce on demand this problem. >>>>>> >>>>>> I'm seeing similar issues on occasion with my Lenovo as well: >>>>>> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: firmware error log: >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: error type =A0 =A0 =A0=3D >>>>>> "NMI_INTERRUPT_WDG" (0x00000004) >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: program counter =3D 0x0000046C >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: source line =A0 =A0 =3D 0x0000= 00D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: error data =A0 =A0 =A0=3D 0x00= 00000207030000 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: branch link =A0 =A0 =3D 0x0000= 8370000004C2 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: interrupt link =A0=3D 0x000006= DA000018B8 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: time =A0 =A0 =A0 =A0 =A0 =A0= =3D 4287402440 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: driver status: >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A00: qid=3D0 =A0cur= =3D1 =A0 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A01: qid=3D1 =A0cur= =3D0 =A0 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A02: qid=3D2 =A0cur= =3D0 =A0 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A03: qid=3D3 =A0cur= =3D36 =A0queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A04: qid=3D4 =A0cur= =3D123 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A05: qid=3D5 =A0cur= =3D0 =A0 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A06: qid=3D6 =A0cur= =3D0 =A0 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A07: qid=3D7 =A0cur= =3D0 =A0 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A08: qid=3D8 =A0cur= =3D0 =A0 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A09: qid=3D9 =A0cur= =3D0 =A0 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 10: qid=3D10 cur=3D0 = =A0 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 11: qid=3D11 cur=3D0 = =A0 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 12: qid=3D12 cur=3D0 = =A0 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 13: qid=3D13 cur=3D0 = =A0 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 14: qid=3D14 cur=3D0 = =A0 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 15: qid=3D15 cur=3D0 = =A0 queued=3D0 >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: rx ring: cur=3D8 >>>>>> >>>>>> This may be because the system was under load (I was installing a po= rt >>>>>> shortly before the connection dropped). I'll try poking at this >>>>>> further because it's going to be an annoying productivity loss :/. >>>>> >>>>> =A0 =A0Sorry... should have included more helpful details. >>>>> Thanks, >>>>> -Garrett >>>>> >>>>> dmesg: >>>>> >>>>> iwn0: mem 0xdf2fe000-0xdf2fffff irq 1= 7 >>>>> at device 0.0 on pci3 >>>>> iwn0: MIMO 2T3R, MoW1, address 00:1d:e0:7d:9f:c7 >>>>> iwn0: [ITHREAD] >>>>> iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbp= s >>>>> iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >>>>> iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps >>>>> 24Mbps 36Mbps 48Mbps 54Mbps >>>>> >>>>> pciconf -lv snippet: >>>>> >>>>> iwn0@pci0:3:0:0: =A0 =A0 =A0 =A0class=3D0x028000 card=3D0x11108086 ch= ip=3D0x42308086 >>>>> rev=3D0x61 hdr=3D0x00 >>>>> =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' >>>>> =A0 =A0device =A0 =A0 =3D 'Intel Wireless WiFi Link 4965AGN (Intel 49= 65AGN)' >>>>> =A0 =A0class =A0 =A0 =A0=3D network >>>>> cbb0@pci0:21:0:0: =A0 =A0 =A0 class=3D0x060700 card=3D0x20c617aa chip= =3D0x04761180 >>>>> rev=3D0xba hdr=3D0x02 >>>>> >>>>> uname -a: >>>>> >>>>> $ uname -a >>>>> FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #0 >>>>> r207006: Wed Apr 21 13:18:44 PDT 2010 >>>>> root@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86 =A0i386 >>>> >>>> I'm actually looking at this right now. For me, it's actually >>>> happening when my machine stays on overnight (or for long periods of >>>> time, idle). >>>> >>>> Also, it seems to be causing the kernel to panic, although I'm now >>>> wondering if the Machine Check Architecture is somehow catching this >>>> device error and causing an exception (hw.mca.enabled=3D1)(?) -- not >>>> possible, right ??? >>>> >>>> Whatever the case, I can't seem to get the firmware error to occur >>>> with iwn(4) debugging or wlandebug options enabled, so who knows >>>> exactly what leads to this. >>>> >>>> I know Bernhard has worked hard on this driver, it's a shame that this >>>> freaky bug has bit us all now, without leaving many clues :( >>>> >>>> I've attached a textdump for posterity if nothing else :) >>> >>> =A0 =A0Connectivity appears to be shoddy in my neck of the woods (kind = of >>> ironic... but meh). Just running buildworld, buildkernel, then doing a >>> tcpdump in parallel causes the pseudo device to go up and down a lot. >>> I assume this isn't standard behavior? >>> =A0 =A0Just for reference buildworld was started shortly after 19:39:05= , >>> and it finished at 21:29. The interface has also gone up and down once >>> since then while the system's been basically idle. >> >> =A0 =A0Hmmm... I'm seem to be in an excellent position to reproduce this >> issue. I've reproduced it twice by merely bringing the interface up >> and down several times using: >> >> ifconfig_wlan0=3D"WPA DHCP" >> >> =A0 =A0instead of my usual: >> >> ifconfig_wlan0=3D"WPA ssid DHCP" >> >> =A0 =A0Maybe others who are experiencing the issue should try that? I'll >> do more testing when I get home... > > My rc.conf is: > > ifconfig_wlan0=3D"WPA DHCP" > > ...as well, although I haven't tried manually taking the interface > down and bringing it back up. Hmmm... that is interesting. I wish I could do that, but it seems to be alluding my grasp right now. The driver just kind of freaks out with a bunch of SSIDs, one being my target SSID, a bunch of NUL string ones, and then finally it just croaks. I need to figure out whether or not the SSIDs are valid when I boot it up at my desk again. > Are you waiting for the device to associate and begin passing traffic > before you each up/down cycle? I was, but I'm not sure whether or not the Ajax pieces in GMail were. I'll try some more rudimentary tests when I get back to work on Monday in that environment, but I need to try out other things at home as well in the meantime. Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 07:02:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2E0D106564A for ; Sat, 24 Apr 2010 07:02:33 +0000 (UTC) (envelope-from ukrzilla@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 847C78FC1A for ; Sat, 24 Apr 2010 07:02:33 +0000 (UTC) Received: by wwa36 with SMTP id 36so6754830wwa.13 for ; Sat, 24 Apr 2010 00:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tr4BssY94x2fGQ0mju4qVeEGXjiC6yGZEjBhxBO75Cw=; b=NzkX6eUvLYRAUhtJ/Ye3FhxCiiF3dGofpXAqZvJhTxD3Vp782SGDbMcd4q2NY7Cs/U kSMdJna7XQajjKc2/hVNAxlB3L0d97/X9XB7pFA2efjqsiWQBxkTXOiEmcxQz6EuwaAT 2C0dfFyT/G/Bhb+iI0kPMB68ty0VD6EMjeuqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=K4AEtP1bX4kQaGkp+Jx8UbwDfOFhn/sk+QASgMrkSs7c194E8rLL7NnoYsP3EOVOBH XiR1BRAW9QaQlOzVLVqbTf05Y7n57ZsUtr8RHAwdOJ29uvWILHc/TrYDk+/Klobl2Ay2 1hLr6PspBgqgiV9R06oOlVYjUewhtVT3tHBZ8= MIME-Version: 1.0 Received: by 10.216.93.19 with SMTP id k19mr1467912wef.5.1272092552362; Sat, 24 Apr 2010 00:02:32 -0700 (PDT) Received: by 10.216.24.149 with HTTP; Sat, 24 Apr 2010 00:02:32 -0700 (PDT) In-Reply-To: <20100421195127.Y40281@maildrop.int.zabbadoz.net> References: <20100421174142.N40281@maildrop.int.zabbadoz.net> <20100421195127.Y40281@maildrop.int.zabbadoz.net> Date: Sat, 24 Apr 2010 10:02:32 +0300 Message-ID: From: Denis Lamanov To: "Bjoern A. Zeeb" , freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Petrovsky Subject: Re: kernel: arpresolve: can't allocate llinfo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 07:02:34 -0000 I am upgraded to FreeBSD vpn3 8.0-STABLE FreeBSD 8.0-STABLE #2 r207058M: Thu Apr 22 15:40:40 EEST 2010 admin@vpn3:/usr/obj/usr/src/sys/GENERICVPN i386 but memory still leak: after 1 day uptime: vmstat -m | grep lltable lltable 24966 3158K - 57483 128,256 mpd5.5 provide real IP address, may be create script if-down.sh to clear link in arp lltable? 2010/4/21 Bjoern A. Zeeb > On Wed, 21 Apr 2010, Bjoern A. Zeeb wrote: > > On Wed, 21 Apr 2010, Denis Lamanov wrote: >> >> Hi, >> >> vmstat -m | grep lltable >>> every 3 minutes increases :( >>> lltable 16938 2149K - 17779 128,256 >>> >> >> I'll MFC the patches to fix that the next couple of days, maybe >> tommorow morning. In case you want to try them, you'd need >> SVN r206469,206470,206481 applied to 8-STABLE. >> > > > Actually I just merged them. If you wait an hour or two for the > changes to show up on your local mirror 8-STABLE should be fine. > > Please note that if you are using option FLOWTABLE you will still see > the leak. I haven't gotten around to update my patches for that. > I'll try to remember to post them once done. > > > /bz > > -- > Bjoern A. Zeeb It will not break if you know what you are doing. > From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 07:34:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C2331065677 for ; Sat, 24 Apr 2010 07:34:33 +0000 (UTC) (envelope-from bschmidt@mx.techwires.net) Received: from mx.techwires.net (mx.techwires.net [IPv6:2001:4d88:100f:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA4A8FC17 for ; Sat, 24 Apr 2010 07:34:32 +0000 (UTC) Received: by mx.techwires.net (Postfix, from userid 1001) id BE4D51D8BE; Sat, 24 Apr 2010 09:34:30 +0200 (CEST) Date: Sat, 24 Apr 2010 09:34:30 +0200 From: Bernhard Schmidt To: Garrett Cooper Message-ID: <20100424073430.GB62910@mx.techwires.net> References: <20100418081400.GA40496@mx.techwires.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Brandon Gooch , Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= , freebsd-stable@freebsd.org Subject: Re: iwn firmware instability with an up-to-date stable kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 07:34:33 -0000 On Fri, Apr 23, 2010 at 11:27:32PM -0700, Garrett Cooper wrote: > On Fri, Apr 23, 2010 at 10:08 PM, Brandon Gooch > wrote: > > On Sat, Apr 24, 2010 at 4:59 AM, Garrett Cooper wrote: > >> On Fri, Apr 23, 2010 at 9:42 PM, Garrett Cooper wrote: > >>> On Fri, Apr 23, 2010 at 8:05 PM, Brandon Gooch > >>> wrote: > >>>> 2010/4/23 Garrett Cooper : > >>>>> 2010/4/23 Garrett Cooper : > >>>>>> 2010/4/18 Olivier Cochard-Labbé : > >>>>>>> 2010/4/18 Bernhard Schmidt : > >>>>>>>> Are you able to reproduce this on demand? As in type a few commands and > >>>>>>>> the firmware error occurs? > >>>>>>>> > >>>>>>> > >>>>>>> No, I'm not able to reproduce on demand this problem. > >>>>>> > >>>>>> I'm seeing similar issues on occasion with my Lenovo as well: > >>>>>> > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: firmware error log: > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: error type      = > >>>>>> "NMI_INTERRUPT_WDG" (0x00000004) > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: program counter = 0x0000046C > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: source line     = 0x000000D0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: error data      = 0x0000000207030000 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: branch link     = 0x00008370000004C2 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: interrupt link  = 0x000006DA000018B8 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: time            = 4287402440 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: driver status: > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  0: qid=0  cur=1   queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  1: qid=1  cur=0   queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  2: qid=2  cur=0   queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  3: qid=3  cur=36  queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  4: qid=4  cur=123 queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  5: qid=5  cur=0   queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  6: qid=6  cur=0   queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  7: qid=7  cur=0   queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  8: qid=8  cur=0   queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  9: qid=9  cur=0   queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 10: qid=10 cur=0   queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 11: qid=11 cur=0   queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 12: qid=12 cur=0   queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 13: qid=13 cur=0   queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 14: qid=14 cur=0   queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 15: qid=15 cur=0   queued=0 > >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: rx ring: cur=8 > >>>>>> > >>>>>> This may be because the system was under load (I was installing a port > >>>>>> shortly before the connection dropped). I'll try poking at this > >>>>>> further because it's going to be an annoying productivity loss :/. > >>>>> > >>>>>    Sorry... should have included more helpful details. > >>>>> Thanks, > >>>>> -Garrett > >>>>> > >>>>> dmesg: > >>>>> > >>>>> iwn0: mem 0xdf2fe000-0xdf2fffff irq 17 > >>>>> at device 0.0 on pci3 > >>>>> iwn0: MIMO 2T3R, MoW1, address 00:1d:e0:7d:9f:c7 > >>>>> iwn0: [ITHREAD] > >>>>> iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > >>>>> iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > >>>>> iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps > >>>>> 24Mbps 36Mbps 48Mbps 54Mbps > >>>>> > >>>>> pciconf -lv snippet: > >>>>> > >>>>> iwn0@pci0:3:0:0:        class=0x028000 card=0x11108086 chip=0x42308086 > >>>>> rev=0x61 hdr=0x00 > >>>>>    vendor     = 'Intel Corporation' > >>>>>    device     = 'Intel Wireless WiFi Link 4965AGN (Intel 4965AGN)' > >>>>>    class      = network > >>>>> cbb0@pci0:21:0:0:       class=0x060700 card=0x20c617aa chip=0x04761180 > >>>>> rev=0xba hdr=0x02 > >>>>> > >>>>> uname -a: > >>>>> > >>>>> $ uname -a > >>>>> FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #0 > >>>>> r207006: Wed Apr 21 13:18:44 PDT 2010 > >>>>> root@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86  i386 > >>>> > >>>> I'm actually looking at this right now. For me, it's actually > >>>> happening when my machine stays on overnight (or for long periods of > >>>> time, idle). > >>>> > >>>> Also, it seems to be causing the kernel to panic, although I'm now > >>>> wondering if the Machine Check Architecture is somehow catching this > >>>> device error and causing an exception (hw.mca.enabled=1)(?) -- not > >>>> possible, right ??? > >>>> > >>>> Whatever the case, I can't seem to get the firmware error to occur > >>>> with iwn(4) debugging or wlandebug options enabled, so who knows > >>>> exactly what leads to this. > >>>> > >>>> I know Bernhard has worked hard on this driver, it's a shame that this > >>>> freaky bug has bit us all now, without leaving many clues :( > >>>> > >>>> I've attached a textdump for posterity if nothing else :) > >>> > >>>    Connectivity appears to be shoddy in my neck of the woods (kind of > >>> ironic... but meh). Just running buildworld, buildkernel, then doing a > >>> tcpdump in parallel causes the pseudo device to go up and down a lot. > >>> I assume this isn't standard behavior? > >>>    Just for reference buildworld was started shortly after 19:39:05, > >>> and it finished at 21:29. The interface has also gone up and down once > >>> since then while the system's been basically idle. > >> > >>    Hmmm... I'm seem to be in an excellent position to reproduce this > >> issue. I've reproduced it twice by merely bringing the interface up > >> and down several times using: > >> > >> ifconfig_wlan0="WPA DHCP" > >> > >>    instead of my usual: > >> > >> ifconfig_wlan0="WPA ssid DHCP" > >> > >>    Maybe others who are experiencing the issue should try that? I'll > >> do more testing when I get home... How did you do that? Reloading the module, or with ifconfig? > > > > My rc.conf is: > > > > ifconfig_wlan0="WPA DHCP" > > > > ...as well, although I haven't tried manually taking the interface > > down and bringing it back up. > > Hmmm... that is interesting. I wish I could do that, but it seems to > be alluding my grasp right now. The driver just kind of freaks out > with a bunch of SSIDs, one being my target SSID, a bunch of NUL string > ones, and then finally it just croaks. I need to figure out whether or > not the SSIDs are valid when I boot it up at my desk again. > > > Are you waiting for the device to associate and begin passing traffic > > before you each up/down cycle? > > I was, but I'm not sure whether or not the Ajax pieces in GMail were. > I'll try some more rudimentary tests when I get back to work on Monday > in that environment, but I need to try out other things at home as > well in the meantime. > > Thanks, > -Garrett -- Bernhard From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 07:45:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C5F106566C for ; Sat, 24 Apr 2010 07:45:15 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 73CDE8FC13 for ; Sat, 24 Apr 2010 07:45:15 +0000 (UTC) Received: by qyk11 with SMTP id 11so12517641qyk.13 for ; Sat, 24 Apr 2010 00:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TLU/3bAZcw0g8BGYz/ycAibxk9uTBwAGpNZ+3MjVrdo=; b=Qs0k/wVwmYPlm9yGABA6im4kU5IiTSqIzYW1Cbah00+BsxmsLWgsgiPhGcpbaKmKm7 9Ju+kvsoLU/Zq+L4Z83nQ9SRWcs7jtWAsj1TWLCWTXzSE7hNH3b3U2t3oyssJHE1oCZm ZdFP/bm+Nio3dus5619mHwjcc+dOMNj530rQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GfNd82GagUiDmblxBZ3/jWA91usaGVUwEILmd93B4hPrqilyB9PA+VmhnkO6mY4q8F kLFcENCbuED8JIXvXFrgqIQf16bkalNpsxAjJ7Er/hn4lZs4bsBSHi/iPlaNn+gndycd C0mKb2TuCM4N8aWKX0833uFn9tYi3OWNUGJUg= MIME-Version: 1.0 Received: by 10.229.190.213 with SMTP id dj21mr1310652qcb.66.1272095114110; Sat, 24 Apr 2010 00:45:14 -0700 (PDT) Received: by 10.229.233.11 with HTTP; Sat, 24 Apr 2010 00:45:14 -0700 (PDT) In-Reply-To: <20100424073430.GB62910@mx.techwires.net> References: <20100424073430.GB62910@mx.techwires.net> Date: Sat, 24 Apr 2010 00:45:14 -0700 Message-ID: From: Garrett Cooper To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Brandon Gooch , =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= , freebsd-stable@freebsd.org Subject: Re: iwn firmware instability with an up-to-date stable kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 07:45:15 -0000 On Sat, Apr 24, 2010 at 12:34 AM, Bernhard Schmidt wrote: > On Fri, Apr 23, 2010 at 11:27:32PM -0700, Garrett Cooper wrote: >> On Fri, Apr 23, 2010 at 10:08 PM, Brandon Gooch >> wrote: >> > On Sat, Apr 24, 2010 at 4:59 AM, Garrett Cooper w= rote: >> >> On Fri, Apr 23, 2010 at 9:42 PM, Garrett Cooper = wrote: >> >>> On Fri, Apr 23, 2010 at 8:05 PM, Brandon Gooch >> >>> wrote: >> >>>> 2010/4/23 Garrett Cooper : >> >>>>> 2010/4/23 Garrett Cooper : >> >>>>>> 2010/4/18 Olivier Cochard-Labb=E9 : >> >>>>>>> 2010/4/18 Bernhard Schmidt : >> >>>>>>>> Are you able to reproduce this on demand? As in type a few comm= ands and >> >>>>>>>> the firmware error occurs? >> >>>>>>>> >> >>>>>>> >> >>>>>>> No, I'm not able to reproduce on demand this problem. >> >>>>>> >> >>>>>> I'm seeing similar issues on occasion with my Lenovo as well: >> >>>>>> >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: firmware error log: >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: error type =A0 =A0 =A0=3D >> >>>>>> "NMI_INTERRUPT_WDG" (0x00000004) >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: program counter =3D 0x00000= 46C >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: source line =A0 =A0 =3D 0x0= 00000D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: error data =A0 =A0 =A0=3D 0= x0000000207030000 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: branch link =A0 =A0 =3D 0x0= 0008370000004C2 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: interrupt link =A0=3D 0x000= 006DA000018B8 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: time =A0 =A0 =A0 =A0 =A0 = =A0=3D 4287402440 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: driver status: >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A00: qid=3D0 =A0cu= r=3D1 =A0 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A01: qid=3D1 =A0cu= r=3D0 =A0 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A02: qid=3D2 =A0cu= r=3D0 =A0 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A03: qid=3D3 =A0cu= r=3D36 =A0queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A04: qid=3D4 =A0cu= r=3D123 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A05: qid=3D5 =A0cu= r=3D0 =A0 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A06: qid=3D6 =A0cu= r=3D0 =A0 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A07: qid=3D7 =A0cu= r=3D0 =A0 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A08: qid=3D8 =A0cu= r=3D0 =A0 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring =A09: qid=3D9 =A0cu= r=3D0 =A0 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 10: qid=3D10 cur=3D= 0 =A0 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 11: qid=3D11 cur=3D= 0 =A0 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 12: qid=3D12 cur=3D= 0 =A0 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 13: qid=3D13 cur=3D= 0 =A0 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 14: qid=3D14 cur=3D= 0 =A0 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 15: qid=3D15 cur=3D= 0 =A0 queued=3D0 >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: rx ring: cur=3D8 >> >>>>>> >> >>>>>> This may be because the system was under load (I was installing a= port >> >>>>>> shortly before the connection dropped). I'll try poking at this >> >>>>>> further because it's going to be an annoying productivity loss :/= . >> >>>>> >> >>>>> =A0 =A0Sorry... should have included more helpful details. >> >>>>> Thanks, >> >>>>> -Garrett >> >>>>> >> >>>>> dmesg: >> >>>>> >> >>>>> iwn0: mem 0xdf2fe000-0xdf2fffff ir= q 17 >> >>>>> at device 0.0 on pci3 >> >>>>> iwn0: MIMO 2T3R, MoW1, address 00:1d:e0:7d:9f:c7 >> >>>>> iwn0: [ITHREAD] >> >>>>> iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54= Mbps >> >>>>> iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >> >>>>> iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18M= bps >> >>>>> 24Mbps 36Mbps 48Mbps 54Mbps >> >>>>> >> >>>>> pciconf -lv snippet: >> >>>>> >> >>>>> iwn0@pci0:3:0:0: =A0 =A0 =A0 =A0class=3D0x028000 card=3D0x11108086= chip=3D0x42308086 >> >>>>> rev=3D0x61 hdr=3D0x00 >> >>>>> =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' >> >>>>> =A0 =A0device =A0 =A0 =3D 'Intel Wireless WiFi Link 4965AGN (Intel= 4965AGN)' >> >>>>> =A0 =A0class =A0 =A0 =A0=3D network >> >>>>> cbb0@pci0:21:0:0: =A0 =A0 =A0 class=3D0x060700 card=3D0x20c617aa c= hip=3D0x04761180 >> >>>>> rev=3D0xba hdr=3D0x02 >> >>>>> >> >>>>> uname -a: >> >>>>> >> >>>>> $ uname -a >> >>>>> FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #0 >> >>>>> r207006: Wed Apr 21 13:18:44 PDT 2010 >> >>>>> root@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86 =A0i38= 6 >> >>>> >> >>>> I'm actually looking at this right now. For me, it's actually >> >>>> happening when my machine stays on overnight (or for long periods o= f >> >>>> time, idle). >> >>>> >> >>>> Also, it seems to be causing the kernel to panic, although I'm now >> >>>> wondering if the Machine Check Architecture is somehow catching thi= s >> >>>> device error and causing an exception (hw.mca.enabled=3D1)(?) -- no= t >> >>>> possible, right ??? >> >>>> >> >>>> Whatever the case, I can't seem to get the firmware error to occur >> >>>> with iwn(4) debugging or wlandebug options enabled, so who knows >> >>>> exactly what leads to this. >> >>>> >> >>>> I know Bernhard has worked hard on this driver, it's a shame that t= his >> >>>> freaky bug has bit us all now, without leaving many clues :( >> >>>> >> >>>> I've attached a textdump for posterity if nothing else :) >> >>> >> >>> =A0 =A0Connectivity appears to be shoddy in my neck of the woods (ki= nd of >> >>> ironic... but meh). Just running buildworld, buildkernel, then doing= a >> >>> tcpdump in parallel causes the pseudo device to go up and down a lot= . >> >>> I assume this isn't standard behavior? >> >>> =A0 =A0Just for reference buildworld was started shortly after 19:39= :05, >> >>> and it finished at 21:29. The interface has also gone up and down on= ce >> >>> since then while the system's been basically idle. >> >> >> >> =A0 =A0Hmmm... I'm seem to be in an excellent position to reproduce t= his >> >> issue. I've reproduced it twice by merely bringing the interface up >> >> and down several times using: >> >> >> >> ifconfig_wlan0=3D"WPA DHCP" >> >> >> >> =A0 =A0instead of my usual: >> >> >> >> ifconfig_wlan0=3D"WPA ssid DHCP" >> >> >> >> =A0 =A0Maybe others who are experiencing the issue should try that? I= 'll >> >> do more testing when I get home... > > How did you do that? Reloading the module, or with ifconfig? /etc/rc.d/netif restart , which does the ifconfig operations (no module change occurred AFAIK, but wlan0 did of course do some device_printf's when it was associating itself with iwn(4)). >> > >> > My rc.conf is: >> > >> > ifconfig_wlan0=3D"WPA DHCP" >> > >> > ...as well, although I haven't tried manually taking the interface >> > down and bringing it back up. >> >> Hmmm... that is interesting. I wish I could do that, but it seems to >> be alluding my grasp right now. The driver just kind of freaks out >> with a bunch of SSIDs, one being my target SSID, a bunch of NUL string >> ones, and then finally it just croaks. I need to figure out whether or >> not the SSIDs are valid when I boot it up at my desk again. >> >> > Are you waiting for the device to associate and begin passing traffic >> > before you each up/down cycle? >> >> I was, but I'm not sure whether or not the Ajax pieces in GMail were. >> I'll try some more rudimentary tests when I get back to work on Monday >> in that environment, but I need to try out other things at home as >> well in the meantime. Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 07:50:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F26F9106564A for ; Sat, 24 Apr 2010 07:50:32 +0000 (UTC) (envelope-from bschmidt@mx.techwires.net) Received: from mx.techwires.net (mx.techwires.net [IPv6:2001:4d88:100f:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 3CBF78FC12 for ; Sat, 24 Apr 2010 07:50:32 +0000 (UTC) Received: by mx.techwires.net (Postfix, from userid 1001) id 85A101D922; Sat, 24 Apr 2010 09:50:31 +0200 (CEST) Date: Sat, 24 Apr 2010 09:50:31 +0200 From: Bernhard Schmidt To: Garrett Cooper Message-ID: <20100424075031.GA98660@mx.techwires.net> References: <20100424073430.GB62910@mx.techwires.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Brandon Gooch , Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= , freebsd-stable@freebsd.org Subject: Re: iwn firmware instability with an up-to-date stable kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 07:50:33 -0000 On Sat, Apr 24, 2010 at 12:45:14AM -0700, Garrett Cooper wrote: > On Sat, Apr 24, 2010 at 12:34 AM, Bernhard Schmidt > wrote: > > On Fri, Apr 23, 2010 at 11:27:32PM -0700, Garrett Cooper wrote: > >> On Fri, Apr 23, 2010 at 10:08 PM, Brandon Gooch > >> wrote: > >> > On Sat, Apr 24, 2010 at 4:59 AM, Garrett Cooper wrote: > >> >> On Fri, Apr 23, 2010 at 9:42 PM, Garrett Cooper wrote: > >> >>> On Fri, Apr 23, 2010 at 8:05 PM, Brandon Gooch > >> >>> wrote: > >> >>>> 2010/4/23 Garrett Cooper : > >> >>>>> 2010/4/23 Garrett Cooper : > >> >>>>>> 2010/4/18 Olivier Cochard-Labbé : > >> >>>>>>> 2010/4/18 Bernhard Schmidt : > >> >>>>>>>> Are you able to reproduce this on demand? As in type a few commands and > >> >>>>>>>> the firmware error occurs? > >> >>>>>>>> > >> >>>>>>> > >> >>>>>>> No, I'm not able to reproduce on demand this problem. > >> >>>>>> > >> >>>>>> I'm seeing similar issues on occasion with my Lenovo as well: > >> >>>>>> > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: firmware error log: > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: error type      = > >> >>>>>> "NMI_INTERRUPT_WDG" (0x00000004) > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: program counter = 0x0000046C > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: source line     = 0x000000D0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: error data      = 0x0000000207030000 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: branch link     = 0x00008370000004C2 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: interrupt link  = 0x000006DA000018B8 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: time            = 4287402440 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: driver status: > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  0: qid=0  cur=1   queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  1: qid=1  cur=0   queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  2: qid=2  cur=0   queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  3: qid=3  cur=36  queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  4: qid=4  cur=123 queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  5: qid=5  cur=0   queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  6: qid=6  cur=0   queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  7: qid=7  cur=0   queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  8: qid=8  cur=0   queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring  9: qid=9  cur=0   queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 10: qid=10 cur=0   queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 11: qid=11 cur=0   queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 12: qid=12 cur=0   queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 13: qid=13 cur=0   queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 14: qid=14 cur=0   queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 15: qid=15 cur=0   queued=0 > >> >>>>>> Apr 23 19:25:24 garrcoop-fbsd kernel: rx ring: cur=8 > >> >>>>>> > >> >>>>>> This may be because the system was under load (I was installing a port > >> >>>>>> shortly before the connection dropped). I'll try poking at this > >> >>>>>> further because it's going to be an annoying productivity loss :/. > >> >>>>> > >> >>>>>    Sorry... should have included more helpful details. > >> >>>>> Thanks, > >> >>>>> -Garrett > >> >>>>> > >> >>>>> dmesg: > >> >>>>> > >> >>>>> iwn0: mem 0xdf2fe000-0xdf2fffff irq 17 > >> >>>>> at device 0.0 on pci3 > >> >>>>> iwn0: MIMO 2T3R, MoW1, address 00:1d:e0:7d:9f:c7 > >> >>>>> iwn0: [ITHREAD] > >> >>>>> iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > >> >>>>> iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > >> >>>>> iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps > >> >>>>> 24Mbps 36Mbps 48Mbps 54Mbps > >> >>>>> > >> >>>>> pciconf -lv snippet: > >> >>>>> > >> >>>>> iwn0@pci0:3:0:0:        class=0x028000 card=0x11108086 chip=0x42308086 > >> >>>>> rev=0x61 hdr=0x00 > >> >>>>>    vendor     = 'Intel Corporation' > >> >>>>>    device     = 'Intel Wireless WiFi Link 4965AGN (Intel 4965AGN)' > >> >>>>>    class      = network > >> >>>>> cbb0@pci0:21:0:0:       class=0x060700 card=0x20c617aa chip=0x04761180 > >> >>>>> rev=0xba hdr=0x02 > >> >>>>> > >> >>>>> uname -a: > >> >>>>> > >> >>>>> $ uname -a > >> >>>>> FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #0 > >> >>>>> r207006: Wed Apr 21 13:18:44 PDT 2010 > >> >>>>> root@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86  i386 > >> >>>> > >> >>>> I'm actually looking at this right now. For me, it's actually > >> >>>> happening when my machine stays on overnight (or for long periods of > >> >>>> time, idle). > >> >>>> > >> >>>> Also, it seems to be causing the kernel to panic, although I'm now > >> >>>> wondering if the Machine Check Architecture is somehow catching this > >> >>>> device error and causing an exception (hw.mca.enabled=1)(?) -- not > >> >>>> possible, right ??? > >> >>>> > >> >>>> Whatever the case, I can't seem to get the firmware error to occur > >> >>>> with iwn(4) debugging or wlandebug options enabled, so who knows > >> >>>> exactly what leads to this. > >> >>>> > >> >>>> I know Bernhard has worked hard on this driver, it's a shame that this > >> >>>> freaky bug has bit us all now, without leaving many clues :( > >> >>>> > >> >>>> I've attached a textdump for posterity if nothing else :) > >> >>> > >> >>>    Connectivity appears to be shoddy in my neck of the woods (kind of > >> >>> ironic... but meh). Just running buildworld, buildkernel, then doing a > >> >>> tcpdump in parallel causes the pseudo device to go up and down a lot. > >> >>> I assume this isn't standard behavior? > >> >>>    Just for reference buildworld was started shortly after 19:39:05, > >> >>> and it finished at 21:29. The interface has also gone up and down once > >> >>> since then while the system's been basically idle. > >> >> > >> >>    Hmmm... I'm seem to be in an excellent position to reproduce this > >> >> issue. I've reproduced it twice by merely bringing the interface up > >> >> and down several times using: > >> >> > >> >> ifconfig_wlan0="WPA DHCP" > >> >> > >> >>    instead of my usual: > >> >> > >> >> ifconfig_wlan0="WPA ssid DHCP" > >> >> > >> >>    Maybe others who are experiencing the issue should try that? I'll > >> >> do more testing when I get home... > > > > How did you do that? Reloading the module, or with ifconfig? > > /etc/rc.d/netif restart , which does the ifconfig operations (no > module change occurred AFAIK, but wlan0 did of course do some > device_printf's when it was associating itself with iwn(4)). Can you do ps xa | grep wpa? Just wondering if wpa_supplicant gets started twice. > >> > > >> > My rc.conf is: > >> > > >> > ifconfig_wlan0="WPA DHCP" > >> > > >> > ...as well, although I haven't tried manually taking the interface > >> > down and bringing it back up. > >> > >> Hmmm... that is interesting. I wish I could do that, but it seems to > >> be alluding my grasp right now. The driver just kind of freaks out > >> with a bunch of SSIDs, one being my target SSID, a bunch of NUL string > >> ones, and then finally it just croaks. I need to figure out whether or > >> not the SSIDs are valid when I boot it up at my desk again. > >> > >> > Are you waiting for the device to associate and begin passing traffic > >> > before you each up/down cycle? > >> > >> I was, but I'm not sure whether or not the Ajax pieces in GMail were. > >> I'll try some more rudimentary tests when I get back to work on Monday > >> in that environment, but I need to try out other things at home as > >> well in the meantime. > > Thanks, > -Garrett -- Bernhard From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 11:34:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 775591065674 for ; Sat, 24 Apr 2010 11:34:51 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3DB8FC18 for ; Sat, 24 Apr 2010 11:34:50 +0000 (UTC) Received: from baby-jane.lamaiziere.net (unknown [192.168.1.10]) by smtp.lamaiziere.net (Postfix) with ESMTP id 4A79763319D; Sat, 24 Apr 2010 13:34:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id E52542CEE80; Sat, 24 Apr 2010 13:34:50 +0200 (CEST) Date: Sat, 24 Apr 2010 13:34:46 +0200 From: Patrick Lamaiziere To: freebsd-stable@freebsd.org Message-ID: <20100424133446.06dc78ad@davenulle.org> In-Reply-To: <5FE5B136-ADE3-4E44-BF62-3ACD03178CB3@pean.org> References: <5FE5B136-ADE3-4E44-BF62-3ACD03178CB3@pean.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Peter =?ISO-8859-1?Q?Ankerst=E5l?= Subject: Re: FreeBSD on MacBook Pro. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 11:34:51 -0000 Le Fri, 23 Apr 2010 23:42:37 +0200, Peter Ankerstål a écrit : > Im trying to install FreeBSD on a macbook with dualboot. Everyting > works out fine but the keymap doesnt work at all. I've tried alot of > keymaps but everyting it produces is "mumbojumbo". What keymap should > I use to get the macbook working in console? -- There is a french keymap fr.macbook.acc.kbd. May be you can adapt it? This it not very hard to do. There is a new and small utility to get the scancode (use it in a console, not under X): http://hack.org/mc/hacks/kbdscan/ From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 12:31:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B11971065680 for ; Sat, 24 Apr 2010 12:31:23 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (unknown [IPv6:2001:16d8:cc1e:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5E6D68FC14 for ; Sat, 24 Apr 2010 12:31:23 +0000 (UTC) Received: from localhost (system.jails.se [87.237.210.209]) by system.jails.se (Postfix) with SMTP id 75C72BC5D4 for ; Sat, 24 Apr 2010 14:31:16 +0200 (CEST) Received: from [172.25.1.40] (c-ae06e155.166-7-64736c14.cust.bredbandsbolaget.se [85.225.6.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by system.jails.se (Postfix) with ESMTPSA id 07A8DBC5CC; Sat, 24 Apr 2010 14:31:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= In-Reply-To: <20100424133446.06dc78ad@davenulle.org> Date: Sat, 24 Apr 2010 14:31:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <245B41F6-B2EE-4263-BB85-2F1F14E7A5EF@pean.org> References: <5FE5B136-ADE3-4E44-BF62-3ACD03178CB3@pean.org> <20100424133446.06dc78ad@davenulle.org> To: Patrick Lamaiziere X-Mailer: Apple Mail (2.1078) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Apr 24 14:31:16 2010 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 4bd2e49416292117916966 X-DSPAM-Factors: 27, keymap, 0.40000, keymap, 0.40000, but, 0.40000, but, 0.40000, it+not, 0.40000, Received*cipher+AES128, 0.40000, Mime-Version*Message, 0.40000, Date*Apr, 0.40000, the+keyboard, 0.40000, not+very, 0.40000, org>+a, 0.40000, (use, 0.40000, 37+0200, 0.40000, In-Reply-To*<20100424133446.06dc78ad, 0.40000, What+keymap, 0.40000, Date*24+Apr, 0.40000, org, 0.40000, Message-Id*BB85+2F1F14E7A5EF, 0.40000, almost+seems, 0.40000, a+écrit, 0.40000, of, 0.40000, adapt+it?, 0.40000, >+There, 0.40000, >+There, 0.40000, List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 12:31:23 -0000 Actuall it seems to work with US ISO och US UNIX too but only with the = fixit cd. In the FreeBSD boot-meny I also can use the keyboard properly, but when = Im trying to log in on the booted system no keys work properly. It almost seems like the ctrl-key is constantly = pressed. (pressing say F gives me ^F on the screen and L clears it like ctrl+L does) -- Peter Ankerst=E5l peter@pean.org http://www.pean.org/ On 24 apr 2010, at 13.34, Patrick Lamaiziere wrote: > Le Fri, 23 Apr 2010 23:42:37 +0200, > Peter Ankerst=E5l a =E9crit : >=20 >> Im trying to install FreeBSD on a macbook with dualboot. Everyting >> works out fine but the keymap doesnt work at all. I've tried alot of >> keymaps but everyting it produces is "mumbojumbo". What keymap should >> I use to get the macbook working in console? -- >=20 > There is a french keymap fr.macbook.acc.kbd. May be you can adapt it? > This it not very hard to do. >=20 > There is a new and small utility to get the scancode (use it in a > console, not under X): http://hack.org/mc/hacks/kbdscan/ >=20 From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 15:28:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E51331065676 for ; Sat, 24 Apr 2010 15:28:51 +0000 (UTC) (envelope-from andy@neu.net) Received: from neu.net (neu.net [199.237.202.236]) by mx1.freebsd.org (Postfix) with ESMTP id 956558FC14 for ; Sat, 24 Apr 2010 15:28:51 +0000 (UTC) Received: from neu.net (neu.net [199.237.202.236]) by neu.net (8.14.4/8.13.6) with ESMTP id o3OF2n3S034086 for ; Sat, 24 Apr 2010 15:02:51 GMT Date: Sat, 24 Apr 2010 15:02:49 +0000 (GMT) From: AN To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.95.2 at neu.net X-Virus-Status: Clean Subject: display r number X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 15:28:52 -0000 I recently saw the following in a post to the list, "8.0-STABLE FreeBSD 8.0-STABLE #2 r207058M:". My question is how do you get the r number to display? My uname -a says:"8.0-STABLE FreeBSD 8.0-STABLE #2: Sat Apr 17 20:56:53". Is there a command line option, or a configuration setting somewhere? tia From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 15:48:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 405F8106566B for ; Sat, 24 Apr 2010 15:48:39 +0000 (UTC) (envelope-from njm@njm.me.uk) Received: from smtp004.apm-internet.net (smtp004.apm-internet.net [85.119.248.54]) by mx1.freebsd.org (Postfix) with SMTP id 8E6878FC0A for ; Sat, 24 Apr 2010 15:48:38 +0000 (UTC) Received: (qmail 84109 invoked from network); 24 Apr 2010 15:48:36 -0000 Received: from unknown (HELO oberon.njm.me.uk) (81.155.116.165) by smtp004.apm-internet.net with SMTP; 24 Apr 2010 15:48:36 -0000 Received: from titania.njm.me.uk (titania.njm.me.uk [192.168.144.130]) by oberon.njm.me.uk (8.14.4/8.14.4) with ESMTP id o3OFmagW027167; Sat, 24 Apr 2010 16:48:36 +0100 (BST) (envelope-from njm@njm.me.uk) Received: from titania.njm.me.uk (localhost [127.0.0.1]) by titania.njm.me.uk (8.14.4/8.14.4) with ESMTP id o3OFmZPV058316; Sat, 24 Apr 2010 16:48:35 +0100 (BST) (envelope-from njm@njm.me.uk) Received: (from njm@localhost) by titania.njm.me.uk (8.14.4/8.14.4/Submit) id o3OFmZkE058315; Sat, 24 Apr 2010 16:48:35 +0100 (BST) (envelope-from njm@njm.me.uk) Date: Sat, 24 Apr 2010 16:48:35 +0100 From: "N.J. Mann" To: AN Message-ID: <20100424154835.GA78736@titania.njm.me.uk> Mail-Followup-To: AN , freebsd-stable@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 7.3-STABLE User-Agent: mutt-NJM (2009-12-30) Cc: freebsd-stable@freebsd.org Subject: Re: display r number X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 15:48:39 -0000 In message , AN (andy@neu.net) wrote: > I recently saw the following in a post to the list, "8.0-STABLE FreeBSD > 8.0-STABLE #2 r207058M:". My question is how do you get the r number to > display? My uname -a says:"8.0-STABLE FreeBSD 8.0-STABLE #2: Sat Apr 17 > 20:56:53". Is there a command line option, or a configuration setting > somewhere? You use SVN instead of CVSup or CVS to update your source tree. Cheers, Nick. -- From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 15:49:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7953D106566B for ; Sat, 24 Apr 2010 15:49:56 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 410EF8FC24 for ; Sat, 24 Apr 2010 15:49:56 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id 0658660E2; Sat, 24 Apr 2010 11:49:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1272124195; bh=MhqSzty68OwQ5JTcYanx6aL/rTTeT5fKqrXEbAZ/nGs=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GY0bgmq5GUavn2eatJm/NhMLuIEAOB6z3K43fZceNjv7TRheBoBHkruvkitwoUUe7 bH/V0HGWU0NmyaZAM6S20d3OI2gjJUDDfZcduDyyym8VLZATJMQ2kzkOCtK5uO8 DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=hv4zJIn39jwcy+qAn1iHGuhOf5bRUjA+j++T3vMSdtyTn/6S6Gc39tHPLvcQwVtWG jBLo6FBE90r+tw13VujuezlfXI4eM0TWLSShs6/5iG+8L9S9+D+WtLT6vd0TjVT Message-ID: <4BD3131F.8020104@protected-networks.net> Date: Sat, 24 Apr 2010 11:49:51 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100422 Thunderbird/3.0.4 MIME-Version: 1.0 To: AN References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: display r number X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 15:49:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/24/10 11:02, AN wrote: > I recently saw the following in a post to the list, "8.0-STABLE FreeBSD > 8.0-STABLE #2 r207058M:". My question is how do you get the r number to > display? My uname -a says:"8.0-STABLE FreeBSD 8.0-STABLE #2: Sat Apr 17 > 20:56:53". Is there a command line option, or a configuration setting > somewhere? This indicates the type of source-code repository in use. If you use cvsup or csup, you get the result you see. If you use a subversion repository from which to build, you get the revision number (plus an 'M', if there are local changes applied), imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvTEx4ACgkQQv9rrgRC1JL0kACdFP/dF6J3LQzQZKWAeDQIqsTJ 8f0AmgNnKFyCZmfb74Fm9W3IyMoRFWXm =rEK/ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 15:49:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 858AD106566C for ; Sat, 24 Apr 2010 15:49:56 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by mx1.freebsd.org (Postfix) with ESMTP id 3FF9C8FC16 for ; Sat, 24 Apr 2010 15:49:55 +0000 (UTC) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta06.westchester.pa.mail.comcast.net with comcast id 9Pb61e0040mv7h056TpwXB; Sat, 24 Apr 2010 15:49:56 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta11.westchester.pa.mail.comcast.net with comcast id 9Tpv1e0043S48mS3XTpv8j; Sat, 24 Apr 2010 15:49:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C7B5E9B425; Sat, 24 Apr 2010 08:49:53 -0700 (PDT) Date: Sat, 24 Apr 2010 08:49:53 -0700 From: Jeremy Chadwick To: AN Message-ID: <20100424154953.GA82950@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: display r number X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 15:49:56 -0000 On Sat, Apr 24, 2010 at 03:02:49PM +0000, AN wrote: > I recently saw the following in a post to the list, "8.0-STABLE > FreeBSD 8.0-STABLE #2 r207058M:". My question is how do you get the > r number to display? My uname -a says:"8.0-STABLE FreeBSD > 8.0-STABLE #2: Sat Apr 17 20:56:53". Is there a command line > option, or a configuration setting somewhere? Those people are using freebsd-update(8). You're not. Don't worry about it. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 15:51:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC3021065674 for ; Sat, 24 Apr 2010 15:51:55 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1E5D28FC15 for ; Sat, 24 Apr 2010 15:51:54 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id o3OFpoBF099774 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 24 Apr 2010 16:51:50 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Message-ID: <4BD31395.6070305@infracaninophile.co.uk> Date: Sat, 24 Apr 2010 16:51:49 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: AN References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96 at happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on happy-idiot-talk.infracaninophile.co.uk Cc: freebsd-stable@freebsd.org Subject: Re: display r number X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 15:51:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/04/2010 16:02:49, AN wrote: > I recently saw the following in a post to the list, "8.0-STABLE FreeBSD > 8.0-STABLE #2 r207058M:". My question is how do you get the r number to > display? My uname -a says:"8.0-STABLE FreeBSD 8.0-STABLE #2: Sat Apr 17 > 20:56:53". Is there a command line option, or a configuration setting > somewhere? If you get your kernel+system sources via cvsup then you won't be able to see the Subversion revision number -- CVS overwrites the $FreeBSD$ and similar tags in the source code when sources are imported from SVN to CVS. I believe the same applies to freebsd-update, although in that case, you can only get the -RELEASE branches. Presumably if you were to check out 8-Stable directly from a SVN server, you would see the global version. However, unless you are a FreeBSD committer, checking sources out of SVN is (I believe) discouraged in order to reduce the load on the SVN servers. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvTE5UACgkQ8Mjk52CukIzu7wCeKdHtnqVRs7mKfnYBZuu8lLFs hgUAnin6jzpuKH5baOFlcq5gaqinm0F6 =+UNZ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 15:54:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B680106566C for ; Sat, 24 Apr 2010 15:54:16 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A50318FC1C for ; Sat, 24 Apr 2010 15:54:15 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id o3OFsBBh099793 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 24 Apr 2010 16:54:11 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Message-ID: <4BD31423.9060803@infracaninophile.co.uk> Date: Sat, 24 Apr 2010 16:54:11 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jeremy Chadwick References: <20100424154953.GA82950@icarus.home.lan> In-Reply-To: <20100424154953.GA82950@icarus.home.lan> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96 at happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, SPF_FAIL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on happy-idiot-talk.infracaninophile.co.uk Cc: AN , freebsd-stable@freebsd.org Subject: Re: display r number X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 15:54:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/04/2010 16:49:53, Jeremy Chadwick wrote: > On Sat, Apr 24, 2010 at 03:02:49PM +0000, AN wrote: >> I recently saw the following in a post to the list, "8.0-STABLE >> FreeBSD 8.0-STABLE #2 r207058M:". My question is how do you get the >> r number to display? My uname -a says:"8.0-STABLE FreeBSD >> 8.0-STABLE #2: Sat Apr 17 20:56:53". Is there a command line >> option, or a configuration setting somewhere? > > Those people are using freebsd-update(8). You're not. Don't worry > about it. :-) > Not to get 8-Stable they aren't. freebsd-update(8) will get you 8.0-RELEASE. Checking out of subversion causes the observed effect. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvTFCMACgkQ8Mjk52CukIxYYwCgi1DlCwQFBqdYmiVkkCllF/hr 8doAnixQk5u57xEoDLQppWGH/0uKti9r =90dQ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sat Apr 24 16:24:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D233106564A for ; Sat, 24 Apr 2010 16:24:30 +0000 (UTC) (envelope-from demolidoramundial@terra.com.br) Received: from if09-mail-fb03-mia.mta.terra.com (if09-mail-fb03-mia.mta.terra.com [208.84.243.227]) by mx1.freebsd.org (Postfix) with ESMTP id 197178FC17 for ; Sat, 24 Apr 2010 16:24:29 +0000 (UTC) Received: from if04-mail-sr05-mia.mta.terra.com (if04-mail-sr05-mia.mta.terra.com [208.84.243.52]) by mail-fb03-mia.tpn.terra.com (Postfix) with ESMTP id 5675D40087F68 for ; Sat, 24 Apr 2010 16:29:59 +0000 (UTC) Received: from 1n0.tpn.terra.com (1n0.tpn.terra.com [10.235.200.56]) by mail-sr05-mia.tpn.terra.com (Postfix) with ESMTP id 6AB5D400801D4 for ; Sat, 24 Apr 2010 12:30:38 -0400 (EDT) X-Terra-Karma: -2% X-Terra-Hash: 0514e79bfa21b90a6bd5c6c16bd5fe37 Received-SPF: pass (1n0.tpn.terra.com: domain of terra.com.br designates 208.84.242.62 as permitted sender) client-ip=208.84.242.62; envelope-from=demolidoramundial@terra.com.br; helo=terra.com.br; Received: from terra.com.br (margo.terra.com [208.84.242.175]) (authenticated user demolidoramundial) by 1n0.tpn.terra.com (Postfix) with ESMTPA id 5C02980080332 for ; Sat, 24 Apr 2010 16:05:49 +0000 (UTC) MIME-Version: 1.0 X-Mailer: TerraMail PHP 5.2 Message-ID: <4004.1272125149@terra.com.br> To: X-Origin: 67.219.60.234 Date: Sat, 24 Apr 2010 16:05:49 +0000 From: Krapeta Moda Intima. Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: =?utf-8?q?Conhe=C3=A7a_nossos_pre=C3=A7os_e_ofertas=2E?= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: demolidoramundial@terra.com.br List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 16:24:30 -0000 Krapeta Moda Íntima =20 Krapeta Moda Íntima =20 Confira nossos Preços. =20 http://www.krapeta.com =20 Tabela de Preços - Krapeta - Moda Íntima. Conjunto Sutiãn Bojo Poliester Renda R$ 10,00 Sutiãn Bojo Poliester Renda R$ 8,00 Sutiãn Simples de Cotton R$ 3,50 Calcinha Renda Poliester R$ 2,50 Calcinha Fio Dental R$ 2,50 Calcinha Cotton Lisa R$ 2,00 Calcinha Cotton Estampada R$ 2,50 =20 Descontos Para Revenda. =20 Email e MSN: krapeta@hotmail.com =20 Krapeta A Moda da Mulher Brasileira. =20