From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 17:38:05 2008 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 66EDC1065677 for ; Sun, 27 Jul 2008 17:38:05 +0000 (UTC) (envelope-from freebsd.mtoth@queldor.net) Received: from queldor.net (queldor.com [216.164.83.38]) by mx1.freebsd.org (Postfix) with ESMTP id 3CD5A8FC08 for ; Sun, 27 Jul 2008 17:38:05 +0000 (UTC) (envelope-from freebsd.mtoth@queldor.net) Received: from c-71-192-238-70.hsd1.ma.comcast.net ([71.192.238.70] helo=[192.168.1.197]) by queldor.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KN9hY-000Iw0-4h for freebsd-stable@freebsd.org; Sun, 27 Jul 2008 12:06:32 -0500 Message-ID: <488CACD9.7060002@queldor.net> Date: Sun, 27 Jul 2008 13:14:01 -0400 From: Michael Toth User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 7.0 Crashing 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, 27 Jul 2008 17:38:05 -0000 Hi, I am running 7.0 stable on a Dell Power Edge 2950 and it is core dumping on me. Below is the dmesg and some core info I am hoping that someone can help me find out why it keeps core dumping on me. Thanks # cd /usr/obj/usr/src/sys/GENERIC/ # kgdb kernel.debug /var/crash/vmcore.5 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 trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x188 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0775284 stack pointer = 0x28:0xe7d6bad0 frame pointer = 0x28:0xe7d6bae8 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 = 4838 (egrep) trap number = 12 panic: page fault cpuid = 4 Uptime: 1h2m48s Physical memory: 2035 MB Dumping 87 MB: 72 56 40 24 8 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb)q # cat /var/run/dmesg.boot Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #0: Sun Jul 27 08:58:11 EDT 2008 mtoth@phpmyadmin.web.rcn.net:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.20-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf48 Stepping = 8 Features=0xbfebfbff Features2=0x649d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 Logical CPUs per core: 2 real memory = 2147221504 (2047 MB) avail memory = 2091675648 (1994 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 ioapic3: Changing APIC ID to 11 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard ioapic3 irqs 96-119 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 amr0: mem 0xf81f0000-0xf81fffff,0xfe9c0000-0xfe9fffff irq 46 at device 14.0 on pci2 amr0: [ITHREAD] amr0: delete logical drives supported by controller amr0: Firmware 521S, BIOS H430, 256MB RAM pcib3: at device 0.2 on pci1 pci3: on pcib3 pcib4: at device 4.0 on pci0 pci4: on pcib4 pcib5: at device 5.0 on pci0 pci5: on pcib5 pcib6: at device 0.0 on pci5 pci6: on pcib6 em0: port 0xecc0-0xecff mem 0xfe6e0000-0xfe6fffff irq 64 at device 7.0 on pci6 em0: [FILTER] em0: Ethernet address: 00:14:22:21:da:67 pcib7: at device 0.2 on pci5 pci7: on pcib7 em1: port 0xdcc0-0xdcff mem 0xfe4e0000-0xfe4fffff irq 65 at device 8.0 on pci7 em1: [FILTER] em1: Ethernet address: 00:14:22:21:da:68 pcib8: at device 6.0 on pci0 pci8: on pcib8 pcib9: at device 0.0 on pci8 pci9: on pcib9 amr1: mem 0xf80f0000-0xf80fffff irq 106 at device 4.0 on pci9 amr1: [ITHREAD] amr1: delete logical drives supported by controller amr1: Firmware 351S, BIOS 1.10, 128MB RAM pcib10: at device 0.2 on pci8 pci10: on pcib10 uhci0: port 0xbce0-0xbcff 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 0xbcc0-0xbcdf 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 0xbca0-0xbcbf 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 0xfeb00000-0xfeb003ff 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 uhub4: on uhub3 uhub4: multiple transaction translators uhub4: 2 ports with 2 removable, self powered pcib11: at device 30.0 on pci0 pci11: on pcib11 vgapci0: port 0xcc00-0xccff mem 0xf0000000-0xf7ffffff,0xfdff0000-0xfdffffff irq 18 at device 13.0 on pci11 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr e2900000e29 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr e2900000e29 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr e2900000e29 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr e2900000e29 device_attach: est3 attach returned 6 p4tcc3: on cpu3 cpu4: on acpi0 est4: on cpu4 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr e2900000e29 device_attach: est4 attach returned 6 p4tcc4: on cpu4 cpu5: on acpi0 est5: on cpu5 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr e2900000e29 device_attach: est5 attach returned 6 p4tcc5: on cpu5 cpu6: on acpi0 est6: on cpu6 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr e2900000e29 device_attach: est6 attach returned 6 p4tcc6: on cpu6 cpu7: on acpi0 est7: on cpu7 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr e2900000e29 device_attach: est7 attach returned 6 p4tcc7: on cpu7 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xec000-0xeffff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: CDROM at ata0-master UDMA33 amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 34680MB (71024640 sectors) RAID 1 (optimal) amr1: delete logical drives supported by controller SMP: AP CPU #6 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #4 Launched! Trying to mount root from ufs:/dev/amrd0s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 18:14:27 2008 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 9E05D1065676 for ; Sun, 27 Jul 2008 18:14:27 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 28EE68FC17; Sun, 27 Jul 2008 18:14:25 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <488CBB02.1020105@FreeBSD.org> Date: Sun, 27 Jul 2008 20:14:26 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Michael Toth References: <488CACD9.7060002@queldor.net> In-Reply-To: <488CACD9.7060002@queldor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 7.0 Crashing 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, 27 Jul 2008 18:14:27 -0000 Michael Toth wrote: > Hi, I am running 7.0 stable on a Dell Power Edge 2950 and it is core > dumping on me. > > Below is the dmesg and some core info > > I am hoping that someone can help me find out why it keeps core dumping > on me. > > Thanks > > # cd /usr/obj/usr/src/sys/GENERIC/ > # kgdb kernel.debug /var/crash/vmcore.5 > 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 trap 12: page fault while in kernel mode > cpuid = 4; apic id = 04 > fault virtual address = 0x188 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0775284 > stack pointer = 0x28:0xe7d6bad0 > frame pointer = 0x28:0xe7d6bae8 > 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 = 4838 (egrep) > trap number = 12 > panic: page fault > cpuid = 4 > Uptime: 1h2m48s > Physical memory: 2035 MB > Dumping 87 MB: 72 56 40 24 8 > > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb)q > > > # cat /var/run/dmesg.boot > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-STABLE #0: Sun Jul 27 08:58:11 EDT 2008 > mtoth@phpmyadmin.web.rcn.net:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.20-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf48 Stepping = 8 > > Features=0xbfebfbff > > Features2=0x649d > AMD Features=0x20100000 > AMD Features2=0x1 > Cores per package: 2 > Logical CPUs per core: 2 > real memory = 2147221504 (2047 MB) > avail memory = 2091675648 (1994 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > cpu4 (AP): APIC ID: 4 > cpu5 (AP): APIC ID: 5 > cpu6 (AP): APIC ID: 6 > cpu7 (AP): APIC ID: 7 > ioapic0: Changing APIC ID to 8 > ioapic1: Changing APIC ID to 9 > ioapic2: Changing APIC ID to 10 > ioapic3: Changing APIC ID to 11 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 32-55 on motherboard > ioapic2 irqs 64-87 on motherboard > ioapic3 irqs 96-119 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 0.0 on pci1 > pci2: on pcib2 > amr0: mem > 0xf81f0000-0xf81fffff,0xfe9c0000-0xfe9fffff irq 46 at device 14.0 on pci2 > amr0: [ITHREAD] > amr0: delete logical drives supported by controller > amr0: Firmware 521S, BIOS H430, 256MB RAM > pcib3: at device 0.2 on pci1 > pci3: on pcib3 > pcib4: at device 4.0 on pci0 > pci4: on pcib4 > pcib5: at device 5.0 on pci0 > pci5: on pcib5 > pcib6: at device 0.0 on pci5 > pci6: on pcib6 > em0: port 0xecc0-0xecff mem > 0xfe6e0000-0xfe6fffff irq 64 at device 7.0 on pci6 > em0: [FILTER] > em0: Ethernet address: 00:14:22:21:da:67 > pcib7: at device 0.2 on pci5 > pci7: on pcib7 > em1: port 0xdcc0-0xdcff mem > 0xfe4e0000-0xfe4fffff irq 65 at device 8.0 on pci7 > em1: [FILTER] > em1: Ethernet address: 00:14:22:21:da:68 > pcib8: at device 6.0 on pci0 > pci8: on pcib8 > pcib9: at device 0.0 on pci8 > pci9: on pcib9 > amr1: mem 0xf80f0000-0xf80fffff irq 106 at > device 4.0 on pci9 > amr1: [ITHREAD] > amr1: delete logical drives supported by controller > amr1: Firmware 351S, BIOS 1.10, 128MB RAM > pcib10: at device 0.2 on pci8 > pci10: on pcib10 > uhci0: port 0xbce0-0xbcff > 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 0xbcc0-0xbcdf > 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 0xbca0-0xbcbf > 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 > 0xfeb00000-0xfeb003ff 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 > uhub4: > on uhub3 > uhub4: multiple transaction translators > uhub4: 2 ports with 2 removable, self powered > pcib11: at device 30.0 on pci0 > pci11: on pcib11 > vgapci0: port 0xcc00-0xccff mem > 0xf0000000-0xf7ffffff,0xfdff0000-0xfdffffff irq 18 at device 13.0 on pci11 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr e2900000e29 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr e2900000e29 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > cpu2: on acpi0 > est2: on cpu2 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr e2900000e29 > device_attach: est2 attach returned 6 > p4tcc2: on cpu2 > cpu3: on acpi0 > est3: on cpu3 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr e2900000e29 > device_attach: est3 attach returned 6 > p4tcc3: on cpu3 > cpu4: on acpi0 > est4: on cpu4 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr e2900000e29 > device_attach: est4 attach returned 6 > p4tcc4: on cpu4 > cpu5: on acpi0 > est5: on cpu5 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr e2900000e29 > device_attach: est5 attach returned 6 > p4tcc5: on cpu5 > cpu6: on acpi0 > est6: on cpu6 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr e2900000e29 > device_attach: est6 attach returned 6 > p4tcc6: on cpu6 > cpu7: on acpi0 > est7: on cpu7 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr e2900000e29 > device_attach: est7 attach returned 6 > p4tcc7: on cpu7 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FILTER] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > sio0: type 16550A > sio0: [FILTER] > pmtimer0 on isa0 > orm0: at iomem > 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xec000-0xeffff pnpid > ORM0000 on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > ppc0: parallel port not found. > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > acd0: CDROM at ata0-master UDMA33 > amr0: delete logical drives supported by controller > amrd0: on amr0 > amrd0: 34680MB (71024640 sectors) RAID 1 (optimal) > amr1: delete logical drives supported by controller > SMP: AP CPU #6 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #5 Launched! > SMP: AP CPU #7 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #4 Launched! > Trying to mount root from ufs:/dev/amrd0s1a > WARNING: / was not properly dismounted > WARNING: /tmp was not properly dismounted > WARNING: /usr was not properly dismounted > WARNING: /var was not properly dismounted > > > > > _______________________________________________ > 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" > > We need the backtrace. Kris From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 18:17:19 2008 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 374AD1065674 for ; Sun, 27 Jul 2008 18:17:19 +0000 (UTC) (envelope-from freebsd.mtoth@queldor.net) Received: from queldor.net (queldor.com [216.164.83.38]) by mx1.freebsd.org (Postfix) with ESMTP id F31218FC13 for ; Sun, 27 Jul 2008 18:17:18 +0000 (UTC) (envelope-from freebsd.mtoth@queldor.net) Received: from c-71-192-238-70.hsd1.ma.comcast.net ([71.192.238.70] helo=[192.168.1.197]) by queldor.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNAgh-000Lrp-SR; Sun, 27 Jul 2008 13:09:44 -0500 Message-ID: <488CBBAC.7040507@queldor.net> Date: Sun, 27 Jul 2008 14:17:16 -0400 From: Michael Toth User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Kris Kennaway References: <488CACD9.7060002@queldor.net> <488CBB02.1020105@FreeBSD.org> In-Reply-To: <488CBB02.1020105@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 7.0 Crashing 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, 27 Jul 2008 18:17:19 -0000 Kris Kennaway wrote: > Michael Toth wrote: >> Hi, I am running 7.0 stable on a Dell Power Edge 2950 and it is core >> dumping on me. >> >> Below is the dmesg and some core info >> >> I am hoping that someone can help me find out why it keeps core >> dumping on me. >> >> Thanks >> >> # cd /usr/obj/usr/src/sys/GENERIC/ >> # kgdb kernel.debug /var/crash/vmcore.5 >> 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 trap 12: page fault while in kernel mode >> cpuid = 4; apic id = 04 >> fault virtual address = 0x188 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc0775284 >> stack pointer = 0x28:0xe7d6bad0 >> frame pointer = 0x28:0xe7d6bae8 >> 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 = 4838 (egrep) >> trap number = 12 >> panic: page fault >> cpuid = 4 >> Uptime: 1h2m48s >> Physical memory: 2035 MB >> Dumping 87 MB: 72 56 40 24 8 >> >> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >> /boot/kernel/acpi.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/acpi.ko >> #0 doadump () at pcpu.h:195 >> 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); >> (kgdb)q >> >> >> # cat /var/run/dmesg.boot >> Copyright (c) 1992-2008 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 7.0-STABLE #0: Sun Jul 27 08:58:11 EDT 2008 >> mtoth@phpmyadmin.web.rcn.net:/usr/obj/usr/src/sys/GENERIC >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.20-MHz 686-class CPU) >> Origin = "GenuineIntel" Id = 0xf48 Stepping = 8 >> >> Features=0xbfebfbff >> >> Features2=0x649d >> AMD Features=0x20100000 >> AMD Features2=0x1 >> Cores per package: 2 >> Logical CPUs per core: 2 >> real memory = 2147221504 (2047 MB) >> avail memory = 2091675648 (1994 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> cpu2 (AP): APIC ID: 2 >> cpu3 (AP): APIC ID: 3 >> cpu4 (AP): APIC ID: 4 >> cpu5 (AP): APIC ID: 5 >> cpu6 (AP): APIC ID: 6 >> cpu7 (AP): APIC ID: 7 >> ioapic0: Changing APIC ID to 8 >> ioapic1: Changing APIC ID to 9 >> ioapic2: Changing APIC ID to 10 >> ioapic3: Changing APIC ID to 11 >> ioapic0 irqs 0-23 on motherboard >> ioapic1 irqs 32-55 on motherboard >> ioapic2 irqs 64-87 on motherboard >> ioapic3 irqs 96-119 on motherboard >> kbd1 at kbdmux0 >> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >> RF5413) >> acpi0: on motherboard >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pcib1: at device 2.0 on pci0 >> pci1: on pcib1 >> pcib2: at device 0.0 on pci1 >> pci2: on pcib2 >> amr0: mem >> 0xf81f0000-0xf81fffff,0xfe9c0000-0xfe9fffff irq 46 at device 14.0 on >> pci2 >> amr0: [ITHREAD] >> amr0: delete logical drives supported by controller >> amr0: Firmware 521S, BIOS H430, 256MB RAM >> pcib3: at device 0.2 on pci1 >> pci3: on pcib3 >> pcib4: at device 4.0 on pci0 >> pci4: on pcib4 >> pcib5: at device 5.0 on pci0 >> pci5: on pcib5 >> pcib6: at device 0.0 on pci5 >> pci6: on pcib6 >> em0: port 0xecc0-0xecff >> mem 0xfe6e0000-0xfe6fffff irq 64 at device 7.0 on pci6 >> em0: [FILTER] >> em0: Ethernet address: 00:14:22:21:da:67 >> pcib7: at device 0.2 on pci5 >> pci7: on pcib7 >> em1: port 0xdcc0-0xdcff >> mem 0xfe4e0000-0xfe4fffff irq 65 at device 8.0 on pci7 >> em1: [FILTER] >> em1: Ethernet address: 00:14:22:21:da:68 >> pcib8: at device 6.0 on pci0 >> pci8: on pcib8 >> pcib9: at device 0.0 on pci8 >> pci9: on pcib9 >> amr1: mem 0xf80f0000-0xf80fffff irq 106 at >> device 4.0 on pci9 >> amr1: [ITHREAD] >> amr1: delete logical drives supported by controller >> amr1: Firmware 351S, BIOS 1.10, 128MB RAM >> pcib10: at device 0.2 on pci8 >> pci10: on pcib10 >> uhci0: port 0xbce0-0xbcff >> 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 0xbcc0-0xbcdf >> 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 0xbca0-0xbcbf >> 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 >> 0xfeb00000-0xfeb003ff 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 >> uhub4: > 2> on uhub3 >> uhub4: multiple transaction translators >> uhub4: 2 ports with 2 removable, self powered >> pcib11: at device 30.0 on pci0 >> pci11: on pcib11 >> vgapci0: port 0xcc00-0xccff mem >> 0xf0000000-0xf7ffffff,0xfdff0000-0xfdffffff irq 18 at device 13.0 on >> pci11 >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 >> ata0: on atapci0 >> ata0: [ITHREAD] >> ata1: on atapci0 >> ata1: [ITHREAD] >> acpi_hpet0: iomem 0xfed00000-0xfed003ff >> on acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> cpu0: on acpi0 >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr e2900000e29 >> device_attach: est0 attach returned 6 >> p4tcc0: on cpu0 >> cpu1: on acpi0 >> est1: on cpu1 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr e2900000e29 >> device_attach: est1 attach returned 6 >> p4tcc1: on cpu1 >> cpu2: on acpi0 >> est2: on cpu2 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr e2900000e29 >> device_attach: est2 attach returned 6 >> p4tcc2: on cpu2 >> cpu3: on acpi0 >> est3: on cpu3 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr e2900000e29 >> device_attach: est3 attach returned 6 >> p4tcc3: on cpu3 >> cpu4: on acpi0 >> est4: on cpu4 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr e2900000e29 >> device_attach: est4 attach returned 6 >> p4tcc4: on cpu4 >> cpu5: on acpi0 >> est5: on cpu5 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr e2900000e29 >> device_attach: est5 attach returned 6 >> p4tcc5: on cpu5 >> cpu6: on acpi0 >> est6: on cpu6 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr e2900000e29 >> device_attach: est6 attach returned 6 >> p4tcc6: on cpu6 >> cpu7: on acpi0 >> est7: on cpu7 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr e2900000e29 >> device_attach: est7 attach returned 6 >> p4tcc7: on cpu7 >> fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on >> acpi0 >> fdc0: [FILTER] >> fd0: <1440-KB 3.5" drive> on fdc0 drive 0 >> sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 >> on acpi0 >> sio0: type 16550A >> sio0: [FILTER] >> pmtimer0 on isa0 >> orm0: at iomem >> 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xec000-0xeffff pnpid >> ORM0000 on isa0 >> atkbdc0: at port 0x60,0x64 on isa0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> ppc0: parallel port not found. >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> sio1: configured irq 3 not in bitmap of probed irqs 0 >> sio1: port may not be enabled >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on >> isa0 >> Timecounters tick every 1.000 msec >> acd0: CDROM at ata0-master UDMA33 >> amr0: delete logical drives supported by controller >> amrd0: on amr0 >> amrd0: 34680MB (71024640 sectors) RAID 1 (optimal) >> amr1: delete logical drives supported by controller >> SMP: AP CPU #6 Launched! >> SMP: AP CPU #1 Launched! >> SMP: AP CPU #2 Launched! >> SMP: AP CPU #5 Launched! >> SMP: AP CPU #7 Launched! >> SMP: AP CPU #3 Launched! >> SMP: AP CPU #4 Launched! >> Trying to mount root from ufs:/dev/amrd0s1a >> WARNING: / was not properly dismounted >> WARNING: /tmp was not properly dismounted >> WARNING: /usr was not properly dismounted >> WARNING: /var was not properly dismounted >> >> >> >> >> _______________________________________________ >> 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" >> >> > > We need the backtrace. > > Kris Backtrace added, please let me know if there is anything else that is needed =) Thanks # kgdb kernel.debug /var/crash/vmcore.5 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 trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x188 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0775284 stack pointer = 0x28:0xe7d6bad0 frame pointer = 0x28:0xe7d6bae8 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 = 4838 (egrep) trap number = 12 panic: page fault cpuid = 4 Uptime: 1h2m48s Physical memory: 2035 MB Dumping 87 MB: 72 56 40 24 8 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc0782597 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0782859 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc0a8b39c in trap_fatal (frame=0xe7d6ba90, eva=392) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a8b620 in trap_pfault (frame=0xe7d6ba90, usermode=0, eva=392) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a8bfcc in trap (frame=0xe7d6ba90) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0775284 in _mtx_lock_sleep (m=0xc600d174, tid=3318745216, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339 #8 0xc09a93d7 in vm_fault (map=0xc56b5570, vaddr=671809536, fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:293 #9 0xc0a8b50b in trap_pfault (frame=0xe7d6bd38, usermode=1, eva=671813488) at /usr/src/sys/i386/i386/trap.c:789 #10 0xc0a8be57 in trap (frame=0xe7d6bd38) at /usr/src/sys/i386/i386/trap.c:357 #11 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #12 0x2806e607 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) q From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 18:41:08 2008 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 C15931065670 for ; Sun, 27 Jul 2008 18:41:08 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 017B38FC13; Sun, 27 Jul 2008 18:41:07 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <488CC13F.1020204@FreeBSD.org> Date: Sun, 27 Jul 2008 20:41:03 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Michael Toth References: <488CACD9.7060002@queldor.net> <488CBB02.1020105@FreeBSD.org> <488CBBAC.7040507@queldor.net> In-Reply-To: <488CBBAC.7040507@queldor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 7.0 Crashing 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, 27 Jul 2008 18:41:08 -0000 Michael Toth wrote: > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) backtrace > #0 doadump () at pcpu.h:195 > #1 0xc0782597 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc0782859 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:572 > #3 0xc0a8b39c in trap_fatal (frame=0xe7d6ba90, eva=392) at > /usr/src/sys/i386/i386/trap.c:899 > #4 0xc0a8b620 in trap_pfault (frame=0xe7d6ba90, usermode=0, eva=392) at > /usr/src/sys/i386/i386/trap.c:812 > #5 0xc0a8bfcc in trap (frame=0xe7d6ba90) at > /usr/src/sys/i386/i386/trap.c:490 > #6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc0775284 in _mtx_lock_sleep (m=0xc600d174, tid=3318745216, opts=0, > file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339 > #8 0xc09a93d7 in vm_fault (map=0xc56b5570, vaddr=671809536, > fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:293 > #9 0xc0a8b50b in trap_pfault (frame=0xe7d6bd38, usermode=1, > eva=671813488) at /usr/src/sys/i386/i386/trap.c:789 > #10 0xc0a8be57 in trap (frame=0xe7d6bd38) at > /usr/src/sys/i386/i386/trap.c:357 > #11 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #12 0x2806e607 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) q Not much there, check for RAM/hardware problems. Kris From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 19:07:48 2008 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 506411065673; Sun, 27 Jul 2008 19:07:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id DFEB78FC13; Sun, 27 Jul 2008 19:07:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 m6RJ7hTW077029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jul 2008 22:07:43 +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.2/8.14.2) with ESMTP id m6RJ7hVA007377; Sun, 27 Jul 2008 22:07:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6RJ7gnb007376; Sun, 27 Jul 2008 22:07:42 +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, 27 Jul 2008 22:07:42 +0300 From: Kostik Belousov To: Michael Toth Message-ID: <20080727190742.GF97161@deviant.kiev.zoral.com.ua> References: <488CACD9.7060002@queldor.net> <488CBB02.1020105@FreeBSD.org> <488CBBAC.7040507@queldor.net> <488CC13F.1020204@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gqO6s7S91gFL8ZIQ" Content-Disposition: inline In-Reply-To: <488CC13F.1020204@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Kris Kennaway , freebsd-stable@freebsd.org Subject: Re: 7.0 Crashing 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, 27 Jul 2008 19:07:48 -0000 --gqO6s7S91gFL8ZIQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 27, 2008 at 08:41:03PM +0200, Kris Kennaway wrote: > Michael Toth wrote: >=20 > >Reading symbols from /boot/kernel/acpi.ko...Reading symbols from=20 > >/boot/kernel/acpi.ko.symbols...done. > >done. > >Loaded symbols for /boot/kernel/acpi.ko > >#0 doadump () at pcpu.h:195 > >195 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); > >(kgdb) backtrace > >#0 doadump () at pcpu.h:195 > >#1 0xc0782597 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.= c:418 > >#2 0xc0782859 in panic (fmt=3DVariable "fmt" is not available. > >) at /usr/src/sys/kern/kern_shutdown.c:572 > >#3 0xc0a8b39c in trap_fatal (frame=3D0xe7d6ba90, eva=3D392) at=20 > >/usr/src/sys/i386/i386/trap.c:899 > >#4 0xc0a8b620 in trap_pfault (frame=3D0xe7d6ba90, usermode=3D0, eva=3D3= 92) at=20 > >/usr/src/sys/i386/i386/trap.c:812 > >#5 0xc0a8bfcc in trap (frame=3D0xe7d6ba90) at=20 > >/usr/src/sys/i386/i386/trap.c:490 > >#6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > >#7 0xc0775284 in _mtx_lock_sleep (m=3D0xc600d174, tid=3D3318745216, opt= s=3D0,=20 > >file=3D0x0, line=3D0) at /usr/src/sys/kern/kern_mutex.c:339 > >#8 0xc09a93d7 in vm_fault (map=3D0xc56b5570, vaddr=3D671809536,=20 > >fault_type=3D2 '\002', fault_flags=3D8) at /usr/src/sys/vm/vm_fault.c:293 > >#9 0xc0a8b50b in trap_pfault (frame=3D0xe7d6bd38, usermode=3D1,=20 > >eva=3D671813488) at /usr/src/sys/i386/i386/trap.c:789 > >#10 0xc0a8be57 in trap (frame=3D0xe7d6bd38) at=20 > >/usr/src/sys/i386/i386/trap.c:357 > >#11 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > >#12 0x2806e607 in ?? () > >Previous frame inner to this frame (corrupt stack?) > >(kgdb) q >=20 > Not much there, check for RAM/hardware problems. Yes, it does not look sensible. Just to be sure, show the source lines around vm/vm_fault.c:293, and, from the frame 8, print the content of the fs and fs.first_object. The fault address 0x188 would suggest that some NULL pointer dereference is being performed, but assuming faulted line is VM_OBJECT_LOCK(fs.first_object); no appropriate structure member with offset 0x188 could be imagined. --gqO6s7S91gFL8ZIQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiMx30ACgkQC3+MBN1Mb4gf7QCfTS8buwH+Z/5r0ZROhLZXY8LF DKEAn0dXfcszhvQMhweY5DDGfZsKMPvV =Hua8 -----END PGP SIGNATURE----- --gqO6s7S91gFL8ZIQ-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 20:43:44 2008 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 9CF231065682; Sun, 27 Jul 2008 20:43:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 383C88FC31; Sun, 27 Jul 2008 20:43:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 m6RKhdM3080391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Jul 2008 23:43:40 +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.2/8.14.2) with ESMTP id m6RKhdTn024116; Sun, 27 Jul 2008 23:43:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6RKhdHY024115; Sun, 27 Jul 2008 23:43:39 +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, 27 Jul 2008 23:43:39 +0300 From: Kostik Belousov To: Michael toth Message-ID: <20080727204339.GG97161@deviant.kiev.zoral.com.ua> References: <488CACD9.7060002@queldor.net> <488CBB02.1020105@FreeBSD.org> <488CBBAC.7040507@queldor.net> <488CC13F.1020204@FreeBSD.org> <20080727190742.GF97161@deviant.kiev.zoral.com.ua> <488CD9AB.8040401@queldor.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XSfi1pJWPNAvuBPy" Content-Disposition: inline In-Reply-To: <488CD9AB.8040401@queldor.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Kris Kennaway , freebsd-stable@freebsd.org Subject: Re: 7.0 Crashing 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, 27 Jul 2008 20:43:44 -0000 --XSfi1pJWPNAvuBPy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 27, 2008 at 04:25:15PM -0400, Michael toth wrote: > Fatal trap 12: page fault while in kernel mode > cpuid =3D 4; apic id =3D 04 > fault virtual address =3D 0x188 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x20:0xc0775284 > stack pointer =3D 0x28:0xe7d6bad0 > frame pointer =3D 0x28:0xe7d6bae8 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 4838 (egrep) > trap number =3D 12 > panic: page fault > cpuid =3D 4 > Uptime: 1h2m48s > Physical memory: 2035 MB > Dumping 87 MB: 72 56 40 24 8 >=20 > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from=20 > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); > (kgdb) backtrace > #0 doadump () at pcpu.h:195 > #1 0xc0782597 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c= :418 > #2 0xc0782859 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:572 > #3 0xc0a8b39c in trap_fatal (frame=3D0xe7d6ba90, eva=3D392) at=20 > /usr/src/sys/i386/i386/trap.c:899 > #4 0xc0a8b620 in trap_pfault (frame=3D0xe7d6ba90, usermode=3D0, eva=3D39= 2) at=20 > /usr/src/sys/i386/i386/trap.c:812 > #5 0xc0a8bfcc in trap (frame=3D0xe7d6ba90) at=20 > /usr/src/sys/i386/i386/trap.c:490 > #6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc0775284 in _mtx_lock_sleep (m=3D0xc600d174, tid=3D3318745216, opts= =3D0,=20 > file=3D0x0, line=3D0) at /usr/src/sys/kern/kern_mutex.c:339 > #8 0xc09a93d7 in vm_fault (map=3D0xc56b5570, vaddr=3D671809536,=20 > fault_type=3D2 '\002', fault_flags=3D8) at /usr/src/sys/vm/vm_fault.c:293 > #9 0xc0a8b50b in trap_pfault (frame=3D0xe7d6bd38, usermode=3D1,=20 > eva=3D671813488) at /usr/src/sys/i386/i386/trap.c:789 > #10 0xc0a8be57 in trap (frame=3D0xe7d6bd38) at=20 > /usr/src/sys/i386/i386/trap.c:357 > #11 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #12 0x2806e607 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) up > #1 0xc0782597 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c= :418 > 418 doadump(); > (kgdb) up > #2 0xc0782859 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:572 > 572 boot(bootopt); > (kgdb) up > #3 0xc0a8b39c in trap_fatal (frame=3D0xe7d6ba90, eva=3D392) at=20 > /usr/src/sys/i386/i386/trap.c:899 > 899 panic("%s", trap_msg[type]); > (kgdb) up > #4 0xc0a8b620 in trap_pfault (frame=3D0xe7d6ba90, usermode=3D0, eva=3D39= 2) at=20 > /usr/src/sys/i386/i386/trap.c:812 > 812 trap_fatal(frame, eva); > (kgdb) up > #5 0xc0a8bfcc in trap (frame=3D0xe7d6ba90) at=20 > /usr/src/sys/i386/i386/trap.c:490 > 490 (void) trap_pfault(frame, FALSE, eva); > (kgdb) up > #6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > 139 call trap > Current language: auto; currently asm > (kgdb) up > #7 0xc0775284 in _mtx_lock_sleep (m=3D0xc600d174, tid=3D3318745216, opts= =3D0,=20 > file=3D0x0, line=3D0) at /usr/src/sys/kern/kern_mutex.c:339 > 339 owner =3D (struct thread *)(v &=20 > ~MTX_FLAGMASK); > Current language: auto; currently c > (kgdb) up > #8 0xc09a93d7 in vm_fault (map=3D0xc56b5570, vaddr=3D671809536,=20 > fault_type=3D2 '\002', fault_flags=3D8) at /usr/src/sys/vm/vm_fault.c:293 > 293 VM_OBJECT_LOCK(fs.first_object); > (kgdb) p fs > $1 =3D {m =3D 0x0, object =3D 0x12, pindex =3D 13878757899709627520, firs= t_m =3D=20 > 0xc5f0a8b8, first_object =3D 0xc600d174, first_pindex =3D 0, map =3D=20 > 0xc56b5570, entry =3D 0xc59fc7f8, lookup_still_valid =3D 2, vp =3D 0xc55c= 5220} > (kgdb) p fs.first_object > $2 =3D 0xc600d174 > (kgdb) Please, show the output of p/x *(fs.first_object) BTW, you have said that you got a lot of the panics. Are backtraces the same for all of them ? --XSfi1pJWPNAvuBPy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiM3foACgkQC3+MBN1Mb4jDFgCgxt70lsWENEFNztFryD1PSD/h npoAn0QWcijsnyS5EDRVSDbVQcXpgT1X =y52L -----END PGP SIGNATURE----- --XSfi1pJWPNAvuBPy-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 21:07:58 2008 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 9D2771065684; Sun, 27 Jul 2008 21:07:58 +0000 (UTC) (envelope-from mtoth@queldor.net) Received: from queldor.net (queldor.com [216.164.83.38]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7458FC0C; Sun, 27 Jul 2008 21:07:58 +0000 (UTC) (envelope-from mtoth@queldor.net) Received: from c-71-192-238-70.hsd1.ma.comcast.net ([71.192.238.70] helo=[192.168.1.197]) by queldor.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNCgY-0001tP-Ea; Sun, 27 Jul 2008 15:17:42 -0500 Message-ID: <488CD9AB.8040401@queldor.net> Date: Sun, 27 Jul 2008 16:25:15 -0400 From: Michael toth User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Kostik Belousov References: <488CACD9.7060002@queldor.net> <488CBB02.1020105@FreeBSD.org> <488CBBAC.7040507@queldor.net> <488CC13F.1020204@FreeBSD.org> <20080727190742.GF97161@deviant.kiev.zoral.com.ua> In-Reply-To: <20080727190742.GF97161@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kris Kennaway , Michael Toth , freebsd-stable@freebsd.org Subject: Re: 7.0 Crashing 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, 27 Jul 2008 21:07:58 -0000 Kostik Belousov wrote: > On Sun, Jul 27, 2008 at 08:41:03PM +0200, Kris Kennaway wrote: > >> Michael Toth wrote: >> >> >>> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >>> /boot/kernel/acpi.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/acpi.ko >>> #0 doadump () at pcpu.h:195 >>> 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); >>> (kgdb) backtrace >>> #0 doadump () at pcpu.h:195 >>> #1 0xc0782597 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 >>> #2 0xc0782859 in panic (fmt=Variable "fmt" is not available. >>> ) at /usr/src/sys/kern/kern_shutdown.c:572 >>> #3 0xc0a8b39c in trap_fatal (frame=0xe7d6ba90, eva=392) at >>> /usr/src/sys/i386/i386/trap.c:899 >>> #4 0xc0a8b620 in trap_pfault (frame=0xe7d6ba90, usermode=0, eva=392) at >>> /usr/src/sys/i386/i386/trap.c:812 >>> #5 0xc0a8bfcc in trap (frame=0xe7d6ba90) at >>> /usr/src/sys/i386/i386/trap.c:490 >>> #6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >>> #7 0xc0775284 in _mtx_lock_sleep (m=0xc600d174, tid=3318745216, opts=0, >>> file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339 >>> #8 0xc09a93d7 in vm_fault (map=0xc56b5570, vaddr=671809536, >>> fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:293 >>> #9 0xc0a8b50b in trap_pfault (frame=0xe7d6bd38, usermode=1, >>> eva=671813488) at /usr/src/sys/i386/i386/trap.c:789 >>> #10 0xc0a8be57 in trap (frame=0xe7d6bd38) at >>> /usr/src/sys/i386/i386/trap.c:357 >>> #11 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >>> #12 0x2806e607 in ?? () >>> Previous frame inner to this frame (corrupt stack?) >>> (kgdb) q >>> >> Not much there, check for RAM/hardware problems. >> > > Yes, it does not look sensible. Just to be sure, show the source > lines around vm/vm_fault.c:293, and, from the frame 8, > print the content of the fs and fs.first_object. > > The fault address 0x188 would suggest that some NULL pointer dereference > is being performed, but assuming faulted line is > VM_OBJECT_LOCK(fs.first_object); > no appropriate structure member with offset 0x188 could be imagined. > Here is the kgdb with (what I hope) is the information you wanted to see. (I do not know how to use kgdb very well) Thanks # kgdb kernel.debug /var/crash/vmcore.5 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 trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x188 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0775284 stack pointer = 0x28:0xe7d6bad0 frame pointer = 0x28:0xe7d6bae8 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 = 4838 (egrep) trap number = 12 panic: page fault cpuid = 4 Uptime: 1h2m48s Physical memory: 2035 MB Dumping 87 MB: 72 56 40 24 8 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc0782597 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0782859 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc0a8b39c in trap_fatal (frame=0xe7d6ba90, eva=392) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a8b620 in trap_pfault (frame=0xe7d6ba90, usermode=0, eva=392) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a8bfcc in trap (frame=0xe7d6ba90) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0775284 in _mtx_lock_sleep (m=0xc600d174, tid=3318745216, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339 #8 0xc09a93d7 in vm_fault (map=0xc56b5570, vaddr=671809536, fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:293 #9 0xc0a8b50b in trap_pfault (frame=0xe7d6bd38, usermode=1, eva=671813488) at /usr/src/sys/i386/i386/trap.c:789 #10 0xc0a8be57 in trap (frame=0xe7d6bd38) at /usr/src/sys/i386/i386/trap.c:357 #11 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #12 0x2806e607 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) up #1 0xc0782597 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 418 doadump(); (kgdb) up #2 0xc0782859 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 572 boot(bootopt); (kgdb) up #3 0xc0a8b39c in trap_fatal (frame=0xe7d6ba90, eva=392) at /usr/src/sys/i386/i386/trap.c:899 899 panic("%s", trap_msg[type]); (kgdb) up #4 0xc0a8b620 in trap_pfault (frame=0xe7d6ba90, usermode=0, eva=392) at /usr/src/sys/i386/i386/trap.c:812 812 trap_fatal(frame, eva); (kgdb) up #5 0xc0a8bfcc in trap (frame=0xe7d6ba90) at /usr/src/sys/i386/i386/trap.c:490 490 (void) trap_pfault(frame, FALSE, eva); (kgdb) up #6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 139 call trap Current language: auto; currently asm (kgdb) up #7 0xc0775284 in _mtx_lock_sleep (m=0xc600d174, tid=3318745216, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339 339 owner = (struct thread *)(v & ~MTX_FLAGMASK); Current language: auto; currently c (kgdb) up #8 0xc09a93d7 in vm_fault (map=0xc56b5570, vaddr=671809536, fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:293 293 VM_OBJECT_LOCK(fs.first_object); (kgdb) p fs $1 = {m = 0x0, object = 0x12, pindex = 13878757899709627520, first_m = 0xc5f0a8b8, first_object = 0xc600d174, first_pindex = 0, map = 0xc56b5570, entry = 0xc59fc7f8, lookup_still_valid = 2, vp = 0xc55c5220} (kgdb) p fs.first_object $2 = 0xc600d174 (kgdb) -- -- [ Queldor ] (Warning: This message may cause you to understand something) From owner-freebsd-stable@FreeBSD.ORG Sun Jul 27 22:55:02 2008 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 2FFAB106566C; Sun, 27 Jul 2008 22:55:02 +0000 (UTC) (envelope-from freebsd.mtoth@queldor.net) Received: from queldor.net (queldor.com [216.164.83.38]) by mx1.freebsd.org (Postfix) with ESMTP id 0F5908FC16; Sun, 27 Jul 2008 22:55:02 +0000 (UTC) (envelope-from freebsd.mtoth@queldor.net) Received: from c-71-192-238-70.hsd1.ma.comcast.net ([71.192.238.70] helo=[192.168.1.197]) by queldor.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNF1R-00097S-Lt; Sun, 27 Jul 2008 17:47:25 -0500 Message-ID: <488CFCC3.2030504@queldor.net> Date: Sun, 27 Jul 2008 18:54:59 -0400 From: Michael Toth User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Kostik Belousov References: <488CACD9.7060002@queldor.net> <488CBB02.1020105@FreeBSD.org> <488CBBAC.7040507@queldor.net> <488CC13F.1020204@FreeBSD.org> <20080727190742.GF97161@deviant.kiev.zoral.com.ua> <488CD9AB.8040401@queldor.net> <20080727204339.GG97161@deviant.kiev.zoral.com.ua> In-Reply-To: <20080727204339.GG97161@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kris Kennaway , freebsd-stable@freebsd.org Subject: Re: 7.0 Crashing 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, 27 Jul 2008 22:55:02 -0000 Kostik Belousov wrote: > On Sun, Jul 27, 2008 at 04:25:15PM -0400, Michael toth wrote: > >> Fatal trap 12: page fault while in kernel mode >> cpuid = 4; apic id = 04 >> fault virtual address = 0x188 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc0775284 >> stack pointer = 0x28:0xe7d6bad0 >> frame pointer = 0x28:0xe7d6bae8 >> 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 = 4838 (egrep) >> trap number = 12 >> panic: page fault >> cpuid = 4 >> Uptime: 1h2m48s >> Physical memory: 2035 MB >> Dumping 87 MB: 72 56 40 24 8 >> >> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >> /boot/kernel/acpi.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/acpi.ko >> #0 doadump () at pcpu.h:195 >> 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); >> (kgdb) backtrace >> #0 doadump () at pcpu.h:195 >> #1 0xc0782597 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 >> #2 0xc0782859 in panic (fmt=Variable "fmt" is not available. >> ) at /usr/src/sys/kern/kern_shutdown.c:572 >> #3 0xc0a8b39c in trap_fatal (frame=0xe7d6ba90, eva=392) at >> /usr/src/sys/i386/i386/trap.c:899 >> #4 0xc0a8b620 in trap_pfault (frame=0xe7d6ba90, usermode=0, eva=392) at >> /usr/src/sys/i386/i386/trap.c:812 >> #5 0xc0a8bfcc in trap (frame=0xe7d6ba90) at >> /usr/src/sys/i386/i386/trap.c:490 >> #6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >> #7 0xc0775284 in _mtx_lock_sleep (m=0xc600d174, tid=3318745216, opts=0, >> file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339 >> #8 0xc09a93d7 in vm_fault (map=0xc56b5570, vaddr=671809536, >> fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:293 >> #9 0xc0a8b50b in trap_pfault (frame=0xe7d6bd38, usermode=1, >> eva=671813488) at /usr/src/sys/i386/i386/trap.c:789 >> #10 0xc0a8be57 in trap (frame=0xe7d6bd38) at >> /usr/src/sys/i386/i386/trap.c:357 >> #11 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >> #12 0x2806e607 in ?? () >> Previous frame inner to this frame (corrupt stack?) >> (kgdb) up >> #1 0xc0782597 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 >> 418 doadump(); >> (kgdb) up >> #2 0xc0782859 in panic (fmt=Variable "fmt" is not available. >> ) at /usr/src/sys/kern/kern_shutdown.c:572 >> 572 boot(bootopt); >> (kgdb) up >> #3 0xc0a8b39c in trap_fatal (frame=0xe7d6ba90, eva=392) at >> /usr/src/sys/i386/i386/trap.c:899 >> 899 panic("%s", trap_msg[type]); >> (kgdb) up >> #4 0xc0a8b620 in trap_pfault (frame=0xe7d6ba90, usermode=0, eva=392) at >> /usr/src/sys/i386/i386/trap.c:812 >> 812 trap_fatal(frame, eva); >> (kgdb) up >> #5 0xc0a8bfcc in trap (frame=0xe7d6ba90) at >> /usr/src/sys/i386/i386/trap.c:490 >> 490 (void) trap_pfault(frame, FALSE, eva); >> (kgdb) up >> #6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >> 139 call trap >> Current language: auto; currently asm >> (kgdb) up >> #7 0xc0775284 in _mtx_lock_sleep (m=0xc600d174, tid=3318745216, opts=0, >> file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339 >> 339 owner = (struct thread *)(v & >> ~MTX_FLAGMASK); >> Current language: auto; currently c >> (kgdb) up >> #8 0xc09a93d7 in vm_fault (map=0xc56b5570, vaddr=671809536, >> fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:293 >> 293 VM_OBJECT_LOCK(fs.first_object); >> (kgdb) p fs >> $1 = {m = 0x0, object = 0x12, pindex = 13878757899709627520, first_m = >> 0xc5f0a8b8, first_object = 0xc600d174, first_pindex = 0, map = >> 0xc56b5570, entry = 0xc59fc7f8, lookup_still_valid = 2, vp = 0xc55c5220} >> (kgdb) p fs.first_object >> $2 = 0xc600d174 >> (kgdb) >> > > Please, show the output of > p/x *(fs.first_object) > > BTW, you have said that you got a lot of the panics. Are backtraces > the same for all of them ? > Here is the p/x *(fs.first_object) .. and it appears that vmcore.6 is different (vmcore.6 is new from a few hours ago) So does this point to a hardware issue? Thanks # kgdb kernel.debug /var/crash/vmcore.5 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 trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x188 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0775284 stack pointer = 0x28:0xe7d6bad0 frame pointer = 0x28:0xe7d6bae8 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 = 4838 (egrep) trap number = 12 panic: page fault cpuid = 4 Uptime: 1h2m48s Physical memory: 2035 MB Dumping 87 MB: 72 56 40 24 8 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) up #1 0xc0782597 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 418 doadump(); (kgdb) up #2 0xc0782859 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 572 boot(bootopt); (kgdb) up #3 0xc0a8b39c in trap_fatal (frame=0xe7d6ba90, eva=392) at /usr/src/sys/i386/i386/trap.c:899 899 panic("%s", trap_msg[type]); (kgdb) up #4 0xc0a8b620 in trap_pfault (frame=0xe7d6ba90, usermode=0, eva=392) at /usr/src/sys/i386/i386/trap.c:812 812 trap_fatal(frame, eva); (kgdb) up #5 0xc0a8bfcc in trap (frame=0xe7d6ba90) at /usr/src/sys/i386/i386/trap.c:490 490 (void) trap_pfault(frame, FALSE, eva); (kgdb) up #6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 139 call trap Current language: auto; currently asm (kgdb) up #7 0xc0775284 in _mtx_lock_sleep (m=0xc600d174, tid=3318745216, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339 339 owner = (struct thread *)(v & ~MTX_FLAGMASK); Current language: auto; currently c (kgdb) up #8 0xc09a93d7 in vm_fault (map=0xc56b5570, vaddr=671809536, fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:293 293 VM_OBJECT_LOCK(fs.first_object); (kgdb) p/x *(fs.first_object) $1 = {mtx = {lock_object = {lo_name = 0x0, lo_type = 0x0, lo_flags = 0x0, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 0x0, mtx_recurse = 0x0}, object_list = {tqe_next = 0x0, tqe_prev = 0xc5f3a300}, shadow_head = {lh_first = 0x0}, shadow_list = {le_next = 0xc5f3a2e8, le_prev = 0xc55c39d0}, memq = {tqh_first = 0x0, tqh_last = 0xc600d1a0}, root = 0x0, size = 0x1, generation = 0x1, ref_count = 0x1, shadow_count = 0x0, type = 0x0, flags = 0x2000, pg_color = 0x0, paging_in_progress = 0x0, resident_page_count = 0x0, backing_object = 0xc55c39b0, backing_object_offset = 0xf000, pager_object_list = { tqe_next = 0x0, tqe_prev = 0x0}, cache = 0x0, handle = 0x0, un_pager = {vnp = {vnp_size = 0x0}, devp = {devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = {swp_bcount = 0x0}}} (kgdb) # kgdb kernel.debug /var/crash/vmcore.6 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: TPTE at 0xbfefeffc IS ZERO @ VA bfbff000 panic: bad pte cpuid = 2 Uptime: 4h12m47s Physical memory: 2035 MB Dumping 121 MB: 106 90 74 58 42 26 10 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0782597 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0782859 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc0a86f26 in pmap_remove_pages (pmap=0xc5527c54) at /usr/src/sys/i386/i386/pmap.c:3093 #4 0xc09b294c in vmspace_exit (td=0xc5fb9aa0) at /usr/src/sys/vm/vm_map.c:404 #5 0xc075e780 in exit1 (td=0xc5fb9aa0, rv=0) at /usr/src/sys/kern/kern_exit.c:294 #6 0xc075fadd in sys_exit (td=Could not find the frame base for "sys_exit". ) at /usr/src/sys/kern/kern_exit.c:98 #7 0xc0a8b975 in syscall (frame=0xe7e6cd38) at /usr/src/sys/i386/i386/trap.c:1035 #8 0xc0a71c40 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #9 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 08:13:55 2008 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 0793D1065672 for ; Mon, 28 Jul 2008 08:13:55 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57014.mail.re3.yahoo.com (web57014.mail.re3.yahoo.com [66.196.97.118]) by mx1.freebsd.org (Postfix) with SMTP id 8F70D8FC13 for ; Mon, 28 Jul 2008 08:13:54 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 79379 invoked by uid 60001); 28 Jul 2008 08:13:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=opWbsr+EYUBfbgJ1PgdNcLtylUb2LYc75MF4vBG1Fu4hvO6uSbVrj4IKvr7n8OtsuLxNtbB1AqIJgS73ERrI5Y9SJV8y1wAi9+5XVJP8BaVTPllkzAY8A3zjdCX9aWVNbFjrPBIqcKGD8Y4CSEefhE2L82ZdQZrRKJMoPwiRRfE=; Received: from [165.21.155.74] by web57014.mail.re3.yahoo.com via HTTP; Mon, 28 Jul 2008 01:13:53 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Mon, 28 Jul 2008 01:13:53 -0700 (PDT) From: Unga To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <757320.79120.qm@web57014.mail.re3.yahoo.com> Subject: undefined reference to SYS_cpuset X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: unga888@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2008 08:13:55 -0000 Hi all Today (28th July) I upgraded the FreeBSD sources (/usr/src) using cvsup and when try to compile a test C program I get following: echo 'main(){}' > dummy.c cc dummy.c -v -Wl,--verbose /usr/lib/libc.so: undefined reference to `SYS_cpuset_getaffinity' /usr/lib/libc.so: undefined reference to `SYS_cpuset' /usr/lib/libc.so: undefined reference to `SYS_cpuset_setaffinity' /usr/lib/libc.so: undefined reference to `SYS_cpuset_getid' /usr/lib/libc.so: undefined reference to `SYS_cpuset_setid' /usr/lib/libc.so: undefined reference to `SYS_setfib' collect2: ld returned 1 exit status I can see in logs following programs compiled without any error: cpuset_getaffinity.S cpuset.S cpuset_setaffinity.S cpuset_getid.S cpuset_setid.S setfib.S What's gone wrong now? Am I in the middle of a FreeBSD update? or have I made some mistake? or multiple routing tables update on 20080724 broken something? Any ideas? Kind regards Unga From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 10:18:47 2008 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 380EA1065677; Mon, 28 Jul 2008 10:18:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 890198FC20; Mon, 28 Jul 2008 10:18:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 m6SAIfkm044647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 13:18:41 +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.2/8.14.2) with ESMTP id m6SAIesV040006; Mon, 28 Jul 2008 13:18:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6SAIecA040005; Mon, 28 Jul 2008 13:18:40 +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: Mon, 28 Jul 2008 13:18:40 +0300 From: Kostik Belousov To: Michael Toth Message-ID: <20080728101840.GK97161@deviant.kiev.zoral.com.ua> References: <488CACD9.7060002@queldor.net> <488CBB02.1020105@FreeBSD.org> <488CBBAC.7040507@queldor.net> <488CC13F.1020204@FreeBSD.org> <20080727190742.GF97161@deviant.kiev.zoral.com.ua> <488CD9AB.8040401@queldor.net> <20080727204339.GG97161@deviant.kiev.zoral.com.ua> <488CFCC3.2030504@queldor.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D85EWoRcDXv1uhH1" Content-Disposition: inline In-Reply-To: <488CFCC3.2030504@queldor.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Kris Kennaway , freebsd-stable@freebsd.org Subject: Re: 7.0 Crashing 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, 28 Jul 2008 10:18:47 -0000 --D85EWoRcDXv1uhH1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 27, 2008 at 06:54:59PM -0400, Michael Toth wrote: >=20 >=20 >=20 > Kostik Belousov wrote: > >On Sun, Jul 27, 2008 at 04:25:15PM -0400, Michael toth wrote: > > =20 > >>Fatal trap 12: page fault while in kernel mode > >>cpuid =3D 4; apic id =3D 04 > >>fault virtual address =3D 0x188 > >>fault code =3D supervisor read, page not present > >>instruction pointer =3D 0x20:0xc0775284 > >>stack pointer =3D 0x28:0xe7d6bad0 > >>frame pointer =3D 0x28:0xe7d6bae8 > >>code segment =3D base 0x0, limit 0xfffff, type 0x1b > >> =3D DPL 0, pres 1, def32 1, gran 1 > >>processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > >>current process =3D 4838 (egrep) > >>trap number =3D 12 > >>panic: page fault > >>cpuid =3D 4 > >>Uptime: 1h2m48s > >>Physical memory: 2035 MB > >>Dumping 87 MB: 72 56 40 24 8 > >> > >>Reading symbols from /boot/kernel/acpi.ko...Reading symbols from=20 > >>/boot/kernel/acpi.ko.symbols...done. > >>done. > >>Loaded symbols for /boot/kernel/acpi.ko > >>#0 doadump () at pcpu.h:195 > >>195 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); > >>(kgdb) backtrace > >>#0 doadump () at pcpu.h:195 > >>#1 0xc0782597 in boot (howto=3D260) at=20 > >>/usr/src/sys/kern/kern_shutdown.c:418 > >>#2 0xc0782859 in panic (fmt=3DVariable "fmt" is not available. > >>) at /usr/src/sys/kern/kern_shutdown.c:572 > >>#3 0xc0a8b39c in trap_fatal (frame=3D0xe7d6ba90, eva=3D392) at=20 > >>/usr/src/sys/i386/i386/trap.c:899 > >>#4 0xc0a8b620 in trap_pfault (frame=3D0xe7d6ba90, usermode=3D0, eva=3D= 392) at=20 > >>/usr/src/sys/i386/i386/trap.c:812 > >>#5 0xc0a8bfcc in trap (frame=3D0xe7d6ba90) at=20 > >>/usr/src/sys/i386/i386/trap.c:490 > >>#6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > >>#7 0xc0775284 in _mtx_lock_sleep (m=3D0xc600d174, tid=3D3318745216, op= ts=3D0,=20 > >>file=3D0x0, line=3D0) at /usr/src/sys/kern/kern_mutex.c:339 > >>#8 0xc09a93d7 in vm_fault (map=3D0xc56b5570, vaddr=3D671809536,=20 > >>fault_type=3D2 '\002', fault_flags=3D8) at /usr/src/sys/vm/vm_fault.c:2= 93 > >>#9 0xc0a8b50b in trap_pfault (frame=3D0xe7d6bd38, usermode=3D1,=20 > >>eva=3D671813488) at /usr/src/sys/i386/i386/trap.c:789 > >>#10 0xc0a8be57 in trap (frame=3D0xe7d6bd38) at=20 > >>/usr/src/sys/i386/i386/trap.c:357 > >>#11 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > >>#12 0x2806e607 in ?? () > >>Previous frame inner to this frame (corrupt stack?) > >>(kgdb) up > >>#1 0xc0782597 in boot (howto=3D260) at=20 > >>/usr/src/sys/kern/kern_shutdown.c:418 > >>418 doadump(); > >>(kgdb) up > >>#2 0xc0782859 in panic (fmt=3DVariable "fmt" is not available. > >>) at /usr/src/sys/kern/kern_shutdown.c:572 > >>572 boot(bootopt); > >>(kgdb) up > >>#3 0xc0a8b39c in trap_fatal (frame=3D0xe7d6ba90, eva=3D392) at=20 > >>/usr/src/sys/i386/i386/trap.c:899 > >>899 panic("%s", trap_msg[type]); > >>(kgdb) up > >>#4 0xc0a8b620 in trap_pfault (frame=3D0xe7d6ba90, usermode=3D0, eva=3D= 392) at=20 > >>/usr/src/sys/i386/i386/trap.c:812 > >>812 trap_fatal(frame, eva); > >>(kgdb) up > >>#5 0xc0a8bfcc in trap (frame=3D0xe7d6ba90) at=20 > >>/usr/src/sys/i386/i386/trap.c:490 > >>490 (void) trap_pfault(frame, FALSE, eva); > >>(kgdb) up > >>#6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > >>139 call trap > >>Current language: auto; currently asm > >>(kgdb) up > >>#7 0xc0775284 in _mtx_lock_sleep (m=3D0xc600d174, tid=3D3318745216, op= ts=3D0,=20 > >>file=3D0x0, line=3D0) at /usr/src/sys/kern/kern_mutex.c:339 > >>339 owner =3D (struct thread *)(v &=20 > >>~MTX_FLAGMASK); > >>Current language: auto; currently c > >>(kgdb) up > >>#8 0xc09a93d7 in vm_fault (map=3D0xc56b5570, vaddr=3D671809536,=20 > >>fault_type=3D2 '\002', fault_flags=3D8) at /usr/src/sys/vm/vm_fault.c:2= 93 > >>293 VM_OBJECT_LOCK(fs.first_object); > >>(kgdb) p fs > >>$1 =3D {m =3D 0x0, object =3D 0x12, pindex =3D 13878757899709627520, fi= rst_m =3D=20 > >>0xc5f0a8b8, first_object =3D 0xc600d174, first_pindex =3D 0, map =3D=20 > >>0xc56b5570, entry =3D 0xc59fc7f8, lookup_still_valid =3D 2, vp =3D 0xc5= 5c5220} > >>(kgdb) p fs.first_object > >>$2 =3D 0xc600d174 > >>(kgdb) > >> =20 > > > >Please, show the output of > > p/x *(fs.first_object) > > > >BTW, you have said that you got a lot of the panics. Are backtraces > >the same for all of them ? > > =20 > Here is the p/x *(fs.first_object) .. > and it appears that vmcore.6 is different (vmcore.6 is new from a few= =20 > hours ago) >=20 > So does this point to a hardware issue? >=20 > Thanks >=20 > # kgdb kernel.debug /var/crash/vmcore.5 > 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=20 > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: >=20 >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 4; apic id =3D 04 > fault virtual address =3D 0x188 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x20:0xc0775284 > stack pointer =3D 0x28:0xe7d6bad0 > frame pointer =3D 0x28:0xe7d6bae8 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 4838 (egrep) > trap number =3D 12 > panic: page fault > cpuid =3D 4 > Uptime: 1h2m48s > Physical memory: 2035 MB > Dumping 87 MB: 72 56 40 24 8 >=20 > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from=20 > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); > (kgdb) up > #1 0xc0782597 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c= :418 > 418 doadump(); > (kgdb) up > #2 0xc0782859 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:572 > 572 boot(bootopt); > (kgdb) up > #3 0xc0a8b39c in trap_fatal (frame=3D0xe7d6ba90, eva=3D392) at=20 > /usr/src/sys/i386/i386/trap.c:899 > 899 panic("%s", trap_msg[type]); > (kgdb) up > #4 0xc0a8b620 in trap_pfault (frame=3D0xe7d6ba90, usermode=3D0, eva=3D39= 2) at=20 > /usr/src/sys/i386/i386/trap.c:812 > 812 trap_fatal(frame, eva); > (kgdb) up > #5 0xc0a8bfcc in trap (frame=3D0xe7d6ba90) at=20 > /usr/src/sys/i386/i386/trap.c:490 > 490 (void) trap_pfault(frame, FALSE, eva); > (kgdb) up > #6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > 139 call trap > Current language: auto; currently asm > (kgdb) up > #7 0xc0775284 in _mtx_lock_sleep (m=3D0xc600d174, tid=3D3318745216, opts= =3D0,=20 > file=3D0x0, line=3D0) at /usr/src/sys/kern/kern_mutex.c:339 > 339 owner =3D (struct thread *)(v &=20 > ~MTX_FLAGMASK); > Current language: auto; currently c > (kgdb) up > #8 0xc09a93d7 in vm_fault (map=3D0xc56b5570, vaddr=3D671809536,=20 > fault_type=3D2 '\002', fault_flags=3D8) at /usr/src/sys/vm/vm_fault.c:293 > 293 VM_OBJECT_LOCK(fs.first_object); > (kgdb) p/x *(fs.first_object) > $1 =3D {mtx =3D {lock_object =3D {lo_name =3D 0x0, lo_type =3D 0x0, lo_fl= ags =3D=20 > 0x0, lo_witness_data =3D {lod_list =3D {stqe_next =3D 0x0}, lod_witness = =3D=20 > 0x0}}, mtx_lock =3D 0x0, mtx_recurse =3D 0x0}, object_list =3D {tqe_next = =3D 0x0, > tqe_prev =3D 0xc5f3a300}, shadow_head =3D {lh_first =3D 0x0}, shadow_l= ist=20 > =3D {le_next =3D 0xc5f3a2e8, le_prev =3D 0xc55c39d0}, memq =3D {tqh_first= =3D 0x0,=20 > tqh_last =3D 0xc600d1a0}, root =3D 0x0, size =3D 0x1, generation =3D 0x1, > ref_count =3D 0x1, shadow_count =3D 0x0, type =3D 0x0, flags =3D 0x2000,= =20 > pg_color =3D 0x0, paging_in_progress =3D 0x0, resident_page_count =3D 0x0= ,=20 > backing_object =3D 0xc55c39b0, backing_object_offset =3D 0xf000,=20 > pager_object_list =3D { > tqe_next =3D 0x0, tqe_prev =3D 0x0}, cache =3D 0x0, handle =3D 0x0, un= _pager=20 > =3D {vnp =3D {vnp_size =3D 0x0}, devp =3D {devp_pglist =3D {tqh_first =3D= 0x0,=20 > tqh_last =3D 0x0}}, swp =3D {swp_bcount =3D 0x0}}} > (kgdb) >=20 >=20 >=20 >=20 > # kgdb kernel.debug /var/crash/vmcore.6 > 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=20 > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: > TPTE at 0xbfefeffc IS ZERO @ VA bfbff000 > panic: bad pte > cpuid =3D 2 > Uptime: 4h12m47s > Physical memory: 2035 MB > Dumping 121 MB: 106 90 74 58 42 26 10 >=20 > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from=20 > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movl %%fs:0,%0" : "=3Dr" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc0782597 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c= :418 > #2 0xc0782859 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:572 > #3 0xc0a86f26 in pmap_remove_pages (pmap=3D0xc5527c54) at=20 > /usr/src/sys/i386/i386/pmap.c:3093 > #4 0xc09b294c in vmspace_exit (td=3D0xc5fb9aa0) at=20 > /usr/src/sys/vm/vm_map.c:404 > #5 0xc075e780 in exit1 (td=3D0xc5fb9aa0, rv=3D0) at=20 > /usr/src/sys/kern/kern_exit.c:294 > #6 0xc075fadd in sys_exit (td=3DCould not find the frame base for "sys_e= xit". > ) at /usr/src/sys/kern/kern_exit.c:98 > #7 0xc0a8b975 in syscall (frame=3D0xe7e6cd38) at=20 > /usr/src/sys/i386/i386/trap.c:1035 > #8 0xc0a71c40 in Xint0x80_syscall () at=20 > /usr/src/sys/i386/i386/exception.s:196 > #9 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) Both panics you shown are caused by zeroing kernel memory in what seems to be random locations. This might be caused by the bug, but I would suggest first making the thorough test of the hardware. --D85EWoRcDXv1uhH1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiNnP8ACgkQC3+MBN1Mb4jtsQCffO6VzX00I/g2Li+31l8hrnMt Yy4AoNz8Bk30rl/kVfplcixBCEw/+a5u =R4DW -----END PGP SIGNATURE----- --D85EWoRcDXv1uhH1-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 10:37:32 2008 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 C15921065685; Mon, 28 Jul 2008 10:37:32 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id A7CF48FC12; Mon, 28 Jul 2008 10:37:32 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id A085F1CC0A9; Mon, 28 Jul 2008 03:37:32 -0700 (PDT) Date: Mon, 28 Jul 2008 03:37:32 -0700 From: Jeremy Chadwick To: Unga Message-ID: <20080728103732.GA95101@eos.sc1.parodius.com> References: <757320.79120.qm@web57014.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <757320.79120.qm@web57014.mail.re3.yahoo.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ps@freebsd.org, brooks@freebsd.org, freebsd-stable@freebsd.org, jhb@freebsd.org Subject: Re: undefined reference to SYS_cpuset 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, 28 Jul 2008 10:37:32 -0000 On Mon, Jul 28, 2008 at 01:13:53AM -0700, Unga wrote: > Hi all > > Today (28th July) I upgraded the FreeBSD sources (/usr/src) using cvsup and when try to compile a test C program I get following: > > echo 'main(){}' > dummy.c > cc dummy.c -v -Wl,--verbose > > /usr/lib/libc.so: undefined reference to `SYS_cpuset_getaffinity' > /usr/lib/libc.so: undefined reference to `SYS_cpuset' > /usr/lib/libc.so: undefined reference to `SYS_cpuset_setaffinity' > /usr/lib/libc.so: undefined reference to `SYS_cpuset_getid' > /usr/lib/libc.so: undefined reference to `SYS_cpuset_setid' > /usr/lib/libc.so: undefined reference to `SYS_setfib' > collect2: ld returned 1 exit status > > I can see in logs following programs compiled without any error: > cpuset_getaffinity.S > cpuset.S > cpuset_setaffinity.S > cpuset_getid.S > cpuset_setid.S > setfib.S > > What's gone wrong now? Am I in the middle of a FreeBSD update? or have I made some mistake? or multiple routing tables update on 20080724 broken something? Any ideas? These were recent changes (past 24 hours or so), which stem from the addition of framework + utilities to allow FreeBSD to bind a process to a specific CPU (via userland utility). See the most recent commit message (it applies to more than just this file, however): http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/cpuset/cpuset.c -- | Jeremy Chadwick jdc at 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 Jul 28 13:31:48 2008 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 2A92D1065670 for ; Mon, 28 Jul 2008 13:31:48 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id D5DFF8FC0C for ; Mon, 28 Jul 2008 13:31:47 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m6SDJNjZ029388; Mon, 28 Jul 2008 09:19:23 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Mon, 28 Jul 2008 09:19:23 -0400 (EDT) Date: Mon, 28 Jul 2008 09:19:23 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Unga In-Reply-To: <757320.79120.qm@web57014.mail.re3.yahoo.com> Message-ID: References: <757320.79120.qm@web57014.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: undefined reference to SYS_cpuset X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2008 13:31:48 -0000 On Mon, 28 Jul 2008, Unga wrote: > Hi all > > Today (28th July) I upgraded the FreeBSD sources (/usr/src) using > cvsup and when try to compile a test C program I get following: > > echo 'main(){}' > dummy.c > cc dummy.c -v -Wl,--verbose > > /usr/lib/libc.so: undefined reference to `SYS_cpuset_getaffinity' > /usr/lib/libc.so: undefined reference to `SYS_cpuset' > /usr/lib/libc.so: undefined reference to `SYS_cpuset_setaffinity' > /usr/lib/libc.so: undefined reference to `SYS_cpuset_getid' > /usr/lib/libc.so: undefined reference to `SYS_cpuset_setid' > /usr/lib/libc.so: undefined reference to `SYS_setfib' > collect2: ld returned 1 exit status > > I can see in logs following programs compiled without any error: > cpuset_getaffinity.S > cpuset.S > cpuset_setaffinity.S > cpuset_getid.S > cpuset_setid.S > setfib.S > > What's gone wrong now? Am I in the middle of a FreeBSD update? or have > I made some mistake? or multiple routing tables update on 20080724 > broken something? Any ideas? Did you build and install the kernel first? -- DE From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 13:48:11 2008 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 7C15C1065672 for ; Mon, 28 Jul 2008 13:48:11 +0000 (UTC) (envelope-from cristiano.deana@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by mx1.freebsd.org (Postfix) with ESMTP id 2CDB28FC14 for ; Mon, 28 Jul 2008 13:48:10 +0000 (UTC) (envelope-from cristiano.deana@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so3974847wra.27 for ; Mon, 28 Jul 2008 06:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=nigfDyDi2+Hqfr5cUDYItytK+/KnbhdYzu2jtnYuEyA=; b=Unxmw1diXFrJdG5Y4ISeB4ZFZ5TSQxYFkT7FbFhxzz0VNVVe6BFeBkskph4FzPBlrT Zgukw9Pe5/hztChDEnDappzX5kJoR3DIVRTsrmZygSU5hG6CxwdRcdgGvC5PddVQ94tC V9fFLqPQXM1MUaraXx276hkR1tMtBcxsUC49s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=K+ZDj6bUbYddmzxVJ5R1cY8Kp3I8v3FvkDFtvd/NQKZSpW0NFsVMRJvuMZW0ZSW0R2 x8Eggigw8NKTkI93ye58y7DrDCTqaweP3XkRLDhFdi3TGrlDgBOoAdTPqZjWQonTY2aN 9815fBZZflwRUPu8zAu59vpD+82VhhIC9WJ7E= Received: by 10.90.74.7 with SMTP id w7mr2620130aga.59.1217251250403; Mon, 28 Jul 2008 06:20:50 -0700 (PDT) Received: by 10.90.80.15 with HTTP; Mon, 28 Jul 2008 06:20:50 -0700 (PDT) Message-ID: Date: Mon, 28 Jul 2008 15:20:50 +0200 From: "Cristiano Deana" To: "FreeBSD Stable Mailing List" , cnst@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Sensorsd framework in 7.X ? 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, 28 Jul 2008 13:48:11 -0000 Hi, any news about a MFC from -current to -stable (or 7.1) for the sensorsd framework? I find it very useful in openbsd, so i hoped to have it soon in free. tnx -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 14:01:48 2008 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 55E431065679 for ; Mon, 28 Jul 2008 14:01:48 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57008.mail.re3.yahoo.com (web57008.mail.re3.yahoo.com [66.196.97.112]) by mx1.freebsd.org (Postfix) with SMTP id 024658FC29 for ; Mon, 28 Jul 2008 14:01:47 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 75018 invoked by uid 60001); 28 Jul 2008 14:01:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=EZ0hVFwp4m4owKmhZab41TdnPaIgQYW4D7Oy8tlgL+EVeplImIUvHcSYP8h+UTZU3eM7/4J7hOTY1shjlVVxtNcjsOwSalyXozYwy5nFge7WUMvwzFyD685Ql0F0gNDiEVapa0glTLS/8+CQdBT+XHZ4cVAtXA+0ss7zQb8LXFQ=; Received: from [165.21.155.11] by web57008.mail.re3.yahoo.com via HTTP; Mon, 28 Jul 2008 07:01:46 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Mon, 28 Jul 2008 07:01:46 -0700 (PDT) From: Unga To: Daniel Eischen In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <912152.75006.qm@web57008.mail.re3.yahoo.com> Cc: ps@freebsd.org, brooks@freebsd.org, freebsd-stable@freebsd.org, jhb@freebsd.org Subject: Re: undefined reference to SYS_cpuset X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: unga888@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2008 14:01:48 -0000 --- On Mon, 7/28/08, Daniel Eischen wrote: > From: Daniel Eischen > Subject: Re: undefined reference to SYS_cpuset > To: "Unga" > Cc: freebsd-stable@freebsd.org > Date: Monday, July 28, 2008, 9:19 PM > On Mon, 28 Jul 2008, Unga wrote: > > > Hi all > > > > Today (28th July) I upgraded the FreeBSD sources > (/usr/src) using > > cvsup and when try to compile a test C program I get > following: > > > > echo 'main(){}' > dummy.c > > cc dummy.c -v -Wl,--verbose > > > > /usr/lib/libc.so: undefined reference to > `SYS_cpuset_getaffinity' > > /usr/lib/libc.so: undefined reference to > `SYS_cpuset' > > /usr/lib/libc.so: undefined reference to > `SYS_cpuset_setaffinity' > > /usr/lib/libc.so: undefined reference to > `SYS_cpuset_getid' > > /usr/lib/libc.so: undefined reference to > `SYS_cpuset_setid' > > /usr/lib/libc.so: undefined reference to > `SYS_setfib' > > collect2: ld returned 1 exit status > > > > I can see in logs following programs compiled without > any error: > > cpuset_getaffinity.S > > cpuset.S > > cpuset_setaffinity.S > > cpuset_getid.S > > cpuset_setid.S > > setfib.S > > > > What's gone wrong now? Am I in the middle of a > FreeBSD update? or have > > I made some mistake? or multiple routing tables update > on 20080724 > > broken something? Any ideas? > > Did you build and install the kernel first? > I have compiled and installed **only** following to a separate location: - FreeBSD Headers - lib/csu - lib/libc - lib/msun - lib/libc_r And tested with a simple script whether I can compile and link against new libs successfully before I can proceed with my project. That test, as mentioned in the original post, failed to link against the new C libraries. That is, it looks to me, the libc is now broken. Of course, the system I'm running is old, uname -a shows May 25. I don't think I have to run the latest kernel for me to separately link against a different copy of libc, do I? If there a fix or a patch, I can apply against the libc and let you guys know the result. Unga From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 14:26:21 2008 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 AD7E11065676; Mon, 28 Jul 2008 14:26:21 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 438B18FC1B; Mon, 28 Jul 2008 14:26:20 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m6SEQJwr017898; Mon, 28 Jul 2008 10:26:19 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Mon, 28 Jul 2008 10:26:20 -0400 (EDT) Date: Mon, 28 Jul 2008 10:26:19 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Unga In-Reply-To: <912152.75006.qm@web57008.mail.re3.yahoo.com> Message-ID: References: <912152.75006.qm@web57008.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, brooks@freebsd.org, ps@freebsd.org, jhb@freebsd.org Subject: Re: undefined reference to SYS_cpuset X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2008 14:26:21 -0000 On Mon, 28 Jul 2008, Unga wrote: > --- On Mon, 7/28/08, Daniel Eischen wrote: > >> From: Daniel Eischen >> Subject: Re: undefined reference to SYS_cpuset >> To: "Unga" >> Cc: freebsd-stable@freebsd.org >> Date: Monday, July 28, 2008, 9:19 PM >> On Mon, 28 Jul 2008, Unga wrote: >> >>> Hi all >>> >>> Today (28th July) I upgraded the FreeBSD sources >> (/usr/src) using >>> cvsup and when try to compile a test C program I get >> following: >>> >>> echo 'main(){}' > dummy.c >>> cc dummy.c -v -Wl,--verbose >>> >>> /usr/lib/libc.so: undefined reference to >> `SYS_cpuset_getaffinity' >>> /usr/lib/libc.so: undefined reference to >> `SYS_cpuset' >>> /usr/lib/libc.so: undefined reference to >> `SYS_cpuset_setaffinity' >>> /usr/lib/libc.so: undefined reference to >> `SYS_cpuset_getid' >>> /usr/lib/libc.so: undefined reference to >> `SYS_cpuset_setid' >>> /usr/lib/libc.so: undefined reference to >> `SYS_setfib' >>> collect2: ld returned 1 exit status >>> >>> I can see in logs following programs compiled without >> any error: >>> cpuset_getaffinity.S >>> cpuset.S >>> cpuset_setaffinity.S >>> cpuset_getid.S >>> cpuset_setid.S >>> setfib.S >>> >>> What's gone wrong now? Am I in the middle of a >> FreeBSD update? or have >>> I made some mistake? or multiple routing tables update >> on 20080724 >>> broken something? Any ideas? >> >> Did you build and install the kernel first? >> > > I have compiled and installed **only** following to a separate location: > - FreeBSD Headers > - lib/csu > - lib/libc > - lib/msun > - lib/libc_r > > And tested with a simple script whether I can compile and link against new libs successfully before I can proceed with my project. That test, as mentioned in the original post, failed to link against the new C libraries. That is, it looks to me, the libc is now broken. > > Of course, the system I'm running is old, uname -a shows May 25. I don't think I have to run the latest kernel for me to separately link against a different copy of libc, do I? > > If there a fix or a patch, I can apply against the libc and let you guys know the result. The only supported way is to buildkernel and buildworld. You're on your own if you choose not to go along with the procedure in src/UPDATING. -- DE From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 14:46:58 2008 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 CF689106566C; Mon, 28 Jul 2008 14:46:58 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4B98B8FC2C; Mon, 28 Jul 2008 14:46:58 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from vhoffman-macbook.lon.namesco.net (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id m6SEktIm030335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 15:46:56 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <488DDBDF.40008@unsane.co.uk> Date: Mon, 28 Jul 2008 15:46:55 +0100 From: Vincent Hoffman User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Cristiano Deana References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Mailing List , cnst@freebsd.org Subject: Re: Sensorsd framework in 7.X ? 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, 28 Jul 2008 14:46:58 -0000 Cristiano Deana wrote: > Hi, > > any news about a MFC from -current to -stable (or 7.1) for the > sensorsd framework? > I find it very useful in openbsd, so i hoped to have it soon in free. > > tnx > > As far as i can understand it was backed out from -CURRENT soon after the initial commit and so will not be coming to 7.x any time soon. see the (rather long) thread here for details. http://lists.freebsd.org/pipermail/cvs-src/2007-October/082398.html Vince From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 14:48:26 2008 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 376821065674 for ; Mon, 28 Jul 2008 14:48:26 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57011.mail.re3.yahoo.com (web57011.mail.re3.yahoo.com [66.196.97.115]) by mx1.freebsd.org (Postfix) with SMTP id E3B2F8FC28 for ; Mon, 28 Jul 2008 14:48:25 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 51441 invoked by uid 60001); 28 Jul 2008 14:48:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=oUdfKVHnjZfuPTeb/n6ZjAo/cihjqbsiedJWQaFZmSylJz5rGFbH7iBJMhG5hpF2NvUo/HeMXuap9W44Xmz4oEFPBKk7E23rjUQX1FDPKjhIbHvFlQOgdZTQ6xyHJaLjXTfW94X9WbwIirY1BUpWhw/1Y6Stmx1YGIb6ErOOdfc=; Received: from [165.21.155.13] by web57011.mail.re3.yahoo.com via HTTP; Mon, 28 Jul 2008 07:48:22 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Mon, 28 Jul 2008 07:48:22 -0700 (PDT) From: Unga To: Daniel Eischen In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <557751.50935.qm@web57011.mail.re3.yahoo.com> Cc: freebsd-stable@freebsd.org Subject: Re: undefined reference to SYS_cpuset X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: unga888@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2008 14:48:26 -0000 --- On Mon, 7/28/08, Daniel Eischen wrote: > From: Daniel Eischen > Subject: Re: undefined reference to SYS_cpuset > To: "Unga" > Cc: ps@freebsd.org, brooks@freebsd.org, freebsd-stable@freebsd.org, jhb@freebsd.org > Date: Monday, July 28, 2008, 10:26 PM > On Mon, 28 Jul 2008, Unga wrote: > > > --- On Mon, 7/28/08, Daniel Eischen > wrote: > > > >> From: Daniel Eischen > >> Subject: Re: undefined reference to SYS_cpuset > >> To: "Unga" > >> Cc: freebsd-stable@freebsd.org > >> Date: Monday, July 28, 2008, 9:19 PM > >> On Mon, 28 Jul 2008, Unga wrote: > >> > >>> Hi all > >>> > >>> Today (28th July) I upgraded the FreeBSD > sources > >> (/usr/src) using > >>> cvsup and when try to compile a test C program > I get > >> following: > >>> > >>> echo 'main(){}' > dummy.c > >>> cc dummy.c -v -Wl,--verbose > >>> > >>> /usr/lib/libc.so: undefined reference to > >> `SYS_cpuset_getaffinity' > >>> /usr/lib/libc.so: undefined reference to > >> `SYS_cpuset' > >>> /usr/lib/libc.so: undefined reference to > >> `SYS_cpuset_setaffinity' > >>> /usr/lib/libc.so: undefined reference to > >> `SYS_cpuset_getid' > >>> /usr/lib/libc.so: undefined reference to > >> `SYS_cpuset_setid' > >>> /usr/lib/libc.so: undefined reference to > >> `SYS_setfib' > >>> collect2: ld returned 1 exit status > >>> > >>> I can see in logs following programs compiled > without > >> any error: > >>> cpuset_getaffinity.S > >>> cpuset.S > >>> cpuset_setaffinity.S > >>> cpuset_getid.S > >>> cpuset_setid.S > >>> setfib.S > >>> > >>> What's gone wrong now? Am I in the middle > of a > >> FreeBSD update? or have > >>> I made some mistake? or multiple routing > tables update > >> on 20080724 > >>> broken something? Any ideas? > >> > >> Did you build and install the kernel first? > >> > > > > I have compiled and installed **only** following to a > separate location: > > - FreeBSD Headers > > - lib/csu > > - lib/libc > > - lib/msun > > - lib/libc_r > > > > And tested with a simple script whether I can compile > and link against new libs successfully before I can proceed > with my project. That test, as mentioned in the original > post, failed to link against the new C libraries. That is, > it looks to me, the libc is now broken. > > > > Of course, the system I'm running is old, uname -a > shows May 25. I don't think I have to run the latest > kernel for me to separately link against a different copy > of libc, do I? > > > > If there a fix or a patch, I can apply against the > libc and let you guys know the result. > > The only supported way is to buildkernel and buildworld. > You're on your > own if you choose not to go along with the procedure in > src/UPDATING. > That may the only way you know how build FreeBSD :( Unga From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 14:58:23 2008 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 DAFCA1065673 for ; Mon, 28 Jul 2008 14:58:23 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id A2C668FC0A for ; Mon, 28 Jul 2008 14:58:23 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m6SEwM1i012110; Mon, 28 Jul 2008 10:58:22 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Mon, 28 Jul 2008 10:58:22 -0400 (EDT) Date: Mon, 28 Jul 2008 10:58:22 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Unga In-Reply-To: <557751.50935.qm@web57011.mail.re3.yahoo.com> Message-ID: References: <557751.50935.qm@web57011.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: undefined reference to SYS_cpuset X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2008 14:58:24 -0000 On Mon, 28 Jul 2008, Unga wrote: > --- On Mon, 7/28/08, Daniel Eischen wrote: > >> From: Daniel Eischen >> Subject: Re: undefined reference to SYS_cpuset >> To: "Unga" >> Cc: ps@freebsd.org, brooks@freebsd.org, freebsd-stable@freebsd.org, jhb@freebsd.org >> Date: Monday, July 28, 2008, 10:26 PM >> On Mon, 28 Jul 2008, Unga wrote: >> >>> --- On Mon, 7/28/08, Daniel Eischen >> wrote: >>> >>>> From: Daniel Eischen >>>> Subject: Re: undefined reference to SYS_cpuset >>>> To: "Unga" >>>> Cc: freebsd-stable@freebsd.org >>>> Date: Monday, July 28, 2008, 9:19 PM >>>> On Mon, 28 Jul 2008, Unga wrote: >>>> >>>>> Hi all >>>>> >>>>> Today (28th July) I upgraded the FreeBSD >> sources >>>> (/usr/src) using >>>>> cvsup and when try to compile a test C program >> I get >>>> following: >>>>> >>>>> echo 'main(){}' > dummy.c >>>>> cc dummy.c -v -Wl,--verbose >>>>> >>>>> /usr/lib/libc.so: undefined reference to >>>> `SYS_cpuset_getaffinity' >>>>> /usr/lib/libc.so: undefined reference to >>>> `SYS_cpuset' >>>>> /usr/lib/libc.so: undefined reference to >>>> `SYS_cpuset_setaffinity' >>>>> /usr/lib/libc.so: undefined reference to >>>> `SYS_cpuset_getid' >>>>> /usr/lib/libc.so: undefined reference to >>>> `SYS_cpuset_setid' >>>>> /usr/lib/libc.so: undefined reference to >>>> `SYS_setfib' >>>>> collect2: ld returned 1 exit status >>>>> >>>>> I can see in logs following programs compiled >> without >>>> any error: >>>>> cpuset_getaffinity.S >>>>> cpuset.S >>>>> cpuset_setaffinity.S >>>>> cpuset_getid.S >>>>> cpuset_setid.S >>>>> setfib.S >>>>> >>>>> What's gone wrong now? Am I in the middle >> of a >>>> FreeBSD update? or have >>>>> I made some mistake? or multiple routing >> tables update >>>> on 20080724 >>>>> broken something? Any ideas? >>>> >>>> Did you build and install the kernel first? >>>> >>> >>> I have compiled and installed **only** following to a >> separate location: >>> - FreeBSD Headers >>> - lib/csu >>> - lib/libc >>> - lib/msun >>> - lib/libc_r >>> >>> And tested with a simple script whether I can compile >> and link against new libs successfully before I can proceed >> with my project. That test, as mentioned in the original >> post, failed to link against the new C libraries. That is, >> it looks to me, the libc is now broken. >>> >>> Of course, the system I'm running is old, uname -a >> shows May 25. I don't think I have to run the latest >> kernel for me to separately link against a different copy >> of libc, do I? >>> >>> If there a fix or a patch, I can apply against the >> libc and let you guys know the result. >> >> The only supported way is to buildkernel and buildworld. >> You're on your >> own if you choose not to go along with the procedure in >> src/UPDATING. >> > > That may the only way you know how build FreeBSD :( No, it's not the only way *I* know how to, but if you aren't going to follow UPDATING, then *you* are expected to figure it out :-) Your problem is that you don't have an up-to-date kernel src (src/sys) directory with includes in your build environment. Your libc is being built against an old set of includes, so it is up to you how to want to modify your build environment to account for this. -- DE From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 15:27:17 2008 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 15BE01065675 for ; Mon, 28 Jul 2008 15:27:17 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: from web57001.mail.re3.yahoo.com (web57001.mail.re3.yahoo.com [66.196.97.105]) by mx1.freebsd.org (Postfix) with SMTP id ADF9B8FC1A for ; Mon, 28 Jul 2008 15:27:16 +0000 (UTC) (envelope-from unga888@yahoo.com) Received: (qmail 54100 invoked by uid 60001); 28 Jul 2008 15:27:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=GPPSB6k8e0yc7Rme1FhmpH5EPLeMXg4qhvvtWNBdsPXfz9v2zJjdl1E5c4ivWrfvoGxeGpF42ClCp4qfLocAivzGmAMuziuo6+tejbLSPdsRaEJn9BWVuIFK04lPeWnnB31739T8s53KqglsMXbcY8fgknt4gmR2dhqkWvIeuJc=; Received: from [165.21.155.10] by web57001.mail.re3.yahoo.com via HTTP; Mon, 28 Jul 2008 08:27:16 PDT X-Mailer: YahooMailWebService/0.7.218 Date: Mon, 28 Jul 2008 08:27:16 -0700 (PDT) From: Unga To: Daniel Eischen In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <217498.53801.qm@web57001.mail.re3.yahoo.com> Cc: freebsd-stable@freebsd.org Subject: Re: undefined reference to SYS_cpuset X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: unga888@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2008 15:27:17 -0000 --- On Mon, 7/28/08, Daniel Eischen wrote: > From: Daniel Eischen > Subject: Re: undefined reference to SYS_cpuset > To: "Unga" > Cc: freebsd-stable@freebsd.org > Date: Monday, July 28, 2008, 10:58 PM > On Mon, 28 Jul 2008, Unga wrote: > > > --- On Mon, 7/28/08, Daniel Eischen > wrote: > > > >> From: Daniel Eischen > >> Subject: Re: undefined reference to SYS_cpuset > >> To: "Unga" > >> Cc: ps@freebsd.org, brooks@freebsd.org, > freebsd-stable@freebsd.org, jhb@freebsd.org > >> Date: Monday, July 28, 2008, 10:26 PM > >> On Mon, 28 Jul 2008, Unga wrote: > >> > >>> --- On Mon, 7/28/08, Daniel Eischen > >> wrote: > >>> > >>>> From: Daniel Eischen > > >>>> Subject: Re: undefined reference to > SYS_cpuset > >>>> To: "Unga" > > >>>> Cc: freebsd-stable@freebsd.org > >>>> Date: Monday, July 28, 2008, 9:19 PM > >>>> On Mon, 28 Jul 2008, Unga wrote: > >>>> > >>>>> Hi all > >>>>> > >>>>> Today (28th July) I upgraded the > FreeBSD > >> sources > >>>> (/usr/src) using > >>>>> cvsup and when try to compile a test C > program > >> I get > >>>> following: > >>>>> > >>>>> echo 'main(){}' > dummy.c > >>>>> cc dummy.c -v -Wl,--verbose > >>>>> > >>>>> /usr/lib/libc.so: undefined reference > to > >>>> `SYS_cpuset_getaffinity' > >>>>> /usr/lib/libc.so: undefined reference > to > >>>> `SYS_cpuset' > >>>>> /usr/lib/libc.so: undefined reference > to > >>>> `SYS_cpuset_setaffinity' > >>>>> /usr/lib/libc.so: undefined reference > to > >>>> `SYS_cpuset_getid' > >>>>> /usr/lib/libc.so: undefined reference > to > >>>> `SYS_cpuset_setid' > >>>>> /usr/lib/libc.so: undefined reference > to > >>>> `SYS_setfib' > >>>>> collect2: ld returned 1 exit status > >>>>> > >>>>> I can see in logs following programs > compiled > >> without > >>>> any error: > >>>>> cpuset_getaffinity.S > >>>>> cpuset.S > >>>>> cpuset_setaffinity.S > >>>>> cpuset_getid.S > >>>>> cpuset_setid.S > >>>>> setfib.S > >>>>> > >>>>> What's gone wrong now? Am I in the > middle > >> of a > >>>> FreeBSD update? or have > >>>>> I made some mistake? or multiple > routing > >> tables update > >>>> on 20080724 > >>>>> broken something? Any ideas? > >>>> > >>>> Did you build and install the kernel > first? > >>>> > >>> > >>> I have compiled and installed **only** > following to a > >> separate location: > >>> - FreeBSD Headers > >>> - lib/csu > >>> - lib/libc > >>> - lib/msun > >>> - lib/libc_r > >>> > >>> And tested with a simple script whether I can > compile > >> and link against new libs successfully before I > can proceed > >> with my project. That test, as mentioned in the > original > >> post, failed to link against the new C libraries. > That is, > >> it looks to me, the libc is now broken. > >>> > >>> Of course, the system I'm running is old, > uname -a > >> shows May 25. I don't think I have to run the > latest > >> kernel for me to separately link against a > different copy > >> of libc, do I? > >>> > >>> If there a fix or a patch, I can apply against > the > >> libc and let you guys know the result. > >> > >> The only supported way is to buildkernel and > buildworld. > >> You're on your > >> own if you choose not to go along with the > procedure in > >> src/UPDATING. > >> > > > > That may the only way you know how build FreeBSD :( > > No, it's not the only way *I* know how to, but if you > aren't > going to follow UPDATING, then *you* are expected to figure > it out :-) > That's good if you know there are many ways of doing the same thing. I have never seen anywhere that this mailing list is ONLY for people who follow UPDATING. There are many who just use parts of the FreeBSD for their projects, and in return fund the FreeBSD project and offer employment to developers. > Your problem is that you don't have an up-to-date > kernel src > (src/sys) directory with includes in your build > environment. I have nothing to do with src/sys. I link against FreeBSD libs for a long time, it just today onwards did not work. That's all. > Your libc is being built against an old set of includes, so > it is up to you how to want to modify your build > environment > to account for this. > I install FreeBSD includes from /usr/src/include and libs from /usr/src/lib. From the today onwards if the make in /usr/src/include does not install all the headers required for libs building that should be clearly documented and notified prominently, that I don't see it in UPDATING or any where. FYI, my libc is build against the **latest** set of includes installed by the make in the /usr/src/include and nothing but that, ie, there are no other headers in /mypath/include, the compilation and installation of libc goes **without** any error. So that "Your libc is being built against an old set of includes" is just pure nonsense, and stupid statement made without knowing what people are doing. Unga Unga From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 17:16:51 2008 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 5F5421065679; Mon, 28 Jul 2008 17:16:51 +0000 (UTC) (envelope-from mtoth@queldor.net) Received: from queldor.net (queldor.com [216.164.83.38]) by mx1.freebsd.org (Postfix) with ESMTP id 236078FC1A; Mon, 28 Jul 2008 17:16:51 +0000 (UTC) (envelope-from mtoth@queldor.net) Received: from c-71-192-238-70.hsd1.ma.comcast.net ([71.192.238.70] helo=[192.168.1.197]) by queldor.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KNWDd-0009MK-Rk; Mon, 28 Jul 2008 12:09:10 -0500 Message-ID: <488DFEF7.5000802@queldor.net> Date: Mon, 28 Jul 2008 13:16:39 -0400 From: Michael toth User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Kostik Belousov References: <488CACD9.7060002@queldor.net> <488CBB02.1020105@FreeBSD.org> <488CBBAC.7040507@queldor.net> <488CC13F.1020204@FreeBSD.org> <20080727190742.GF97161@deviant.kiev.zoral.com.ua> <488CD9AB.8040401@queldor.net> <20080727204339.GG97161@deviant.kiev.zoral.com.ua> <488CFCC3.2030504@queldor.net> <20080728101840.GK97161@deviant.kiev.zoral.com.ua> In-Reply-To: <20080728101840.GK97161@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kris Kennaway , Michael Toth , freebsd-stable@freebsd.org Subject: Re: 7.0 Crashing 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, 28 Jul 2008 17:16:51 -0000 Kostik Belousov wrote: > On Sun, Jul 27, 2008 at 06:54:59PM -0400, Michael Toth wrote: > >> >> Kostik Belousov wrote: >> >>> On Sun, Jul 27, 2008 at 04:25:15PM -0400, Michael toth wrote: >>> >>> >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid = 4; apic id = 04 >>>> fault virtual address = 0x188 >>>> fault code = supervisor read, page not present >>>> instruction pointer = 0x20:0xc0775284 >>>> stack pointer = 0x28:0xe7d6bad0 >>>> frame pointer = 0x28:0xe7d6bae8 >>>> 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 = 4838 (egrep) >>>> trap number = 12 >>>> panic: page fault >>>> cpuid = 4 >>>> Uptime: 1h2m48s >>>> Physical memory: 2035 MB >>>> Dumping 87 MB: 72 56 40 24 8 >>>> >>>> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >>>> /boot/kernel/acpi.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/acpi.ko >>>> #0 doadump () at pcpu.h:195 >>>> 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); >>>> (kgdb) backtrace >>>> #0 doadump () at pcpu.h:195 >>>> #1 0xc0782597 in boot (howto=260) at >>>> /usr/src/sys/kern/kern_shutdown.c:418 >>>> #2 0xc0782859 in panic (fmt=Variable "fmt" is not available. >>>> ) at /usr/src/sys/kern/kern_shutdown.c:572 >>>> #3 0xc0a8b39c in trap_fatal (frame=0xe7d6ba90, eva=392) at >>>> /usr/src/sys/i386/i386/trap.c:899 >>>> #4 0xc0a8b620 in trap_pfault (frame=0xe7d6ba90, usermode=0, eva=392) at >>>> /usr/src/sys/i386/i386/trap.c:812 >>>> #5 0xc0a8bfcc in trap (frame=0xe7d6ba90) at >>>> /usr/src/sys/i386/i386/trap.c:490 >>>> #6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >>>> #7 0xc0775284 in _mtx_lock_sleep (m=0xc600d174, tid=3318745216, opts=0, >>>> file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339 >>>> #8 0xc09a93d7 in vm_fault (map=0xc56b5570, vaddr=671809536, >>>> fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:293 >>>> #9 0xc0a8b50b in trap_pfault (frame=0xe7d6bd38, usermode=1, >>>> eva=671813488) at /usr/src/sys/i386/i386/trap.c:789 >>>> #10 0xc0a8be57 in trap (frame=0xe7d6bd38) at >>>> /usr/src/sys/i386/i386/trap.c:357 >>>> #11 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >>>> #12 0x2806e607 in ?? () >>>> Previous frame inner to this frame (corrupt stack?) >>>> (kgdb) up >>>> #1 0xc0782597 in boot (howto=260) at >>>> /usr/src/sys/kern/kern_shutdown.c:418 >>>> 418 doadump(); >>>> (kgdb) up >>>> #2 0xc0782859 in panic (fmt=Variable "fmt" is not available. >>>> ) at /usr/src/sys/kern/kern_shutdown.c:572 >>>> 572 boot(bootopt); >>>> (kgdb) up >>>> #3 0xc0a8b39c in trap_fatal (frame=0xe7d6ba90, eva=392) at >>>> /usr/src/sys/i386/i386/trap.c:899 >>>> 899 panic("%s", trap_msg[type]); >>>> (kgdb) up >>>> #4 0xc0a8b620 in trap_pfault (frame=0xe7d6ba90, usermode=0, eva=392) at >>>> /usr/src/sys/i386/i386/trap.c:812 >>>> 812 trap_fatal(frame, eva); >>>> (kgdb) up >>>> #5 0xc0a8bfcc in trap (frame=0xe7d6ba90) at >>>> /usr/src/sys/i386/i386/trap.c:490 >>>> 490 (void) trap_pfault(frame, FALSE, eva); >>>> (kgdb) up >>>> #6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >>>> 139 call trap >>>> Current language: auto; currently asm >>>> (kgdb) up >>>> #7 0xc0775284 in _mtx_lock_sleep (m=0xc600d174, tid=3318745216, opts=0, >>>> file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339 >>>> 339 owner = (struct thread *)(v & >>>> ~MTX_FLAGMASK); >>>> Current language: auto; currently c >>>> (kgdb) up >>>> #8 0xc09a93d7 in vm_fault (map=0xc56b5570, vaddr=671809536, >>>> fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:293 >>>> 293 VM_OBJECT_LOCK(fs.first_object); >>>> (kgdb) p fs >>>> $1 = {m = 0x0, object = 0x12, pindex = 13878757899709627520, first_m = >>>> 0xc5f0a8b8, first_object = 0xc600d174, first_pindex = 0, map = >>>> 0xc56b5570, entry = 0xc59fc7f8, lookup_still_valid = 2, vp = 0xc55c5220} >>>> (kgdb) p fs.first_object >>>> $2 = 0xc600d174 >>>> (kgdb) >>>> >>>> >>> Please, show the output of >>> p/x *(fs.first_object) >>> >>> BTW, you have said that you got a lot of the panics. Are backtraces >>> the same for all of them ? >>> >>> >> Here is the p/x *(fs.first_object) .. >> and it appears that vmcore.6 is different (vmcore.6 is new from a few >> hours ago) >> >> So does this point to a hardware issue? >> >> Thanks >> >> # kgdb kernel.debug /var/crash/vmcore.5 >> 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 trap 12: page fault while in kernel mode >> cpuid = 4; apic id = 04 >> fault virtual address = 0x188 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc0775284 >> stack pointer = 0x28:0xe7d6bad0 >> frame pointer = 0x28:0xe7d6bae8 >> 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 = 4838 (egrep) >> trap number = 12 >> panic: page fault >> cpuid = 4 >> Uptime: 1h2m48s >> Physical memory: 2035 MB >> Dumping 87 MB: 72 56 40 24 8 >> >> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >> /boot/kernel/acpi.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/acpi.ko >> #0 doadump () at pcpu.h:195 >> 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); >> (kgdb) up >> #1 0xc0782597 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 >> 418 doadump(); >> (kgdb) up >> #2 0xc0782859 in panic (fmt=Variable "fmt" is not available. >> ) at /usr/src/sys/kern/kern_shutdown.c:572 >> 572 boot(bootopt); >> (kgdb) up >> #3 0xc0a8b39c in trap_fatal (frame=0xe7d6ba90, eva=392) at >> /usr/src/sys/i386/i386/trap.c:899 >> 899 panic("%s", trap_msg[type]); >> (kgdb) up >> #4 0xc0a8b620 in trap_pfault (frame=0xe7d6ba90, usermode=0, eva=392) at >> /usr/src/sys/i386/i386/trap.c:812 >> 812 trap_fatal(frame, eva); >> (kgdb) up >> #5 0xc0a8bfcc in trap (frame=0xe7d6ba90) at >> /usr/src/sys/i386/i386/trap.c:490 >> 490 (void) trap_pfault(frame, FALSE, eva); >> (kgdb) up >> #6 0xc0a71bdb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >> 139 call trap >> Current language: auto; currently asm >> (kgdb) up >> #7 0xc0775284 in _mtx_lock_sleep (m=0xc600d174, tid=3318745216, opts=0, >> file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339 >> 339 owner = (struct thread *)(v & >> ~MTX_FLAGMASK); >> Current language: auto; currently c >> (kgdb) up >> #8 0xc09a93d7 in vm_fault (map=0xc56b5570, vaddr=671809536, >> fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:293 >> 293 VM_OBJECT_LOCK(fs.first_object); >> (kgdb) p/x *(fs.first_object) >> $1 = {mtx = {lock_object = {lo_name = 0x0, lo_type = 0x0, lo_flags = >> 0x0, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = >> 0x0}}, mtx_lock = 0x0, mtx_recurse = 0x0}, object_list = {tqe_next = 0x0, >> tqe_prev = 0xc5f3a300}, shadow_head = {lh_first = 0x0}, shadow_list >> = {le_next = 0xc5f3a2e8, le_prev = 0xc55c39d0}, memq = {tqh_first = 0x0, >> tqh_last = 0xc600d1a0}, root = 0x0, size = 0x1, generation = 0x1, >> ref_count = 0x1, shadow_count = 0x0, type = 0x0, flags = 0x2000, >> pg_color = 0x0, paging_in_progress = 0x0, resident_page_count = 0x0, >> backing_object = 0xc55c39b0, backing_object_offset = 0xf000, >> pager_object_list = { >> tqe_next = 0x0, tqe_prev = 0x0}, cache = 0x0, handle = 0x0, un_pager >> = {vnp = {vnp_size = 0x0}, devp = {devp_pglist = {tqh_first = 0x0, >> tqh_last = 0x0}}, swp = {swp_bcount = 0x0}}} >> (kgdb) >> >> >> >> >> # kgdb kernel.debug /var/crash/vmcore.6 >> 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: >> TPTE at 0xbfefeffc IS ZERO @ VA bfbff000 >> panic: bad pte >> cpuid = 2 >> Uptime: 4h12m47s >> Physical memory: 2035 MB >> Dumping 121 MB: 106 90 74 58 42 26 10 >> >> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >> /boot/kernel/acpi.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/acpi.ko >> #0 doadump () at pcpu.h:195 >> 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); >> (kgdb) bt >> #0 doadump () at pcpu.h:195 >> #1 0xc0782597 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 >> #2 0xc0782859 in panic (fmt=Variable "fmt" is not available. >> ) at /usr/src/sys/kern/kern_shutdown.c:572 >> #3 0xc0a86f26 in pmap_remove_pages (pmap=0xc5527c54) at >> /usr/src/sys/i386/i386/pmap.c:3093 >> #4 0xc09b294c in vmspace_exit (td=0xc5fb9aa0) at >> /usr/src/sys/vm/vm_map.c:404 >> #5 0xc075e780 in exit1 (td=0xc5fb9aa0, rv=0) at >> /usr/src/sys/kern/kern_exit.c:294 >> #6 0xc075fadd in sys_exit (td=Could not find the frame base for "sys_exit". >> ) at /usr/src/sys/kern/kern_exit.c:98 >> #7 0xc0a8b975 in syscall (frame=0xe7e6cd38) at >> /usr/src/sys/i386/i386/trap.c:1035 >> #8 0xc0a71c40 in Xint0x80_syscall () at >> /usr/src/sys/i386/i386/exception.s:196 >> #9 0x00000033 in ?? () >> Previous frame inner to this frame (corrupt stack?) >> (kgdb) >> > > Both panics you shown are caused by zeroing kernel memory in what seems to > be random locations. This might be caused by the bug, but I would suggest > first making the thorough test of the hardware. > I had someone run a Dell Diags CD on the machine and it passed all tests. Before that it core'd again; here is the backtrace from that one. Is there any other want (maybe in freebsd) to test the hardware better? and/or should I submit a bug report for this? Thanks for all the help # 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: TPTE at 0xbfca027c IS ZERO @ VA 2809f000 panic: bad pte cpuid = 0 Uptime: 17h17m50s Physical memory: 2035 MB Dumping 222 MB: 207 191 175 159 143 127 111 95 79 63 47 31 15 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc0782597 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0782859 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc0a86f26 in pmap_remove_pages (pmap=0xc5bf142c) at /usr/src/sys/i386/i386/pmap.c:3093 #4 0xc09b294c in vmspace_exit (td=0xc5f2a440) at /usr/src/sys/vm/vm_map.c:404 #5 0xc075e780 in exit1 (td=0xc5f2a440, rv=0) at /usr/src/sys/kern/kern_exit.c:294 #6 0xc075fadd in sys_exit (td=Could not find the frame base for "sys_exit". ) at /usr/src/sys/kern/kern_exit.c:98 #7 0xc0a8b975 in syscall (frame=0xe7e9bd38) at /usr/src/sys/i386/i386/trap.c:1035 #8 0xc0a71c40 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #9 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) q -- -- [ Queldor ] (Warning: This message may cause you to understand something) From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 18:05:57 2008 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 BAAFB1065671 for ; Mon, 28 Jul 2008 18:05:57 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 52F948FC17 for ; Mon, 28 Jul 2008 18:05:57 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id m6SI5tWM027857; Mon, 28 Jul 2008 14:05:55 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Mon, 28 Jul 2008 14:05:56 -0400 (EDT) Date: Mon, 28 Jul 2008 14:05:55 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Unga In-Reply-To: <217498.53801.qm@web57001.mail.re3.yahoo.com> Message-ID: References: <217498.53801.qm@web57001.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: undefined reference to SYS_cpuset X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2008 18:05:57 -0000 On Mon, 28 Jul 2008, Unga wrote: > --- On Mon, 7/28/08, Daniel Eischen wrote: > >> Your problem is that you don't have an up-to-date >> kernel src >> (src/sys) directory with includes in your build >> environment. > > I have nothing to do with src/sys. I link against FreeBSD libs for a > long time, it just today onwards did not work. That's all. I don't care that *you* have nothing to do with src/sys, but libc (and other base libs and utilities) do care. >> Your libc is being built against an old set of includes, so >> it is up to you how to want to modify your build >> environment >> to account for this. >> > > I install FreeBSD includes from /usr/src/include and libs from > /usr/src/lib. From the today onwards if the make in /usr/src/include > does not install all the headers required for libs building that > should be clearly documented and notified prominently, that I don't > see it in UPDATING or any where. > > FYI, my libc is build against the **latest** set of includes installed > by the make in the /usr/src/include and nothing but that, ie, there > are no other headers in /mypath/include, the compilation and > installation of libc goes **without** any error. So that "Your libc is > being built against an old set of includes" is just pure nonsense, and > stupid statement made without knowing what people are doing. It's not nonsense, it is the truth. "old set of includes" includes /usr/include and everything under it (/usr/include/sys, /usr/include/machine, etc), with sys and machine notably being part of src/sys. The files in /usr/src/include are not the complete set of includes, and a 'make install' from there does not install all the includes. Depending on what you are doing and what you require, you need to at least setup an include directory that includes the files from /usr/src/include, /usr/src/sys/sys (as and /usr/src/sys//include (as ). You should do a 'ls -1F /usr/include | grep /' and see just what you are missing by only relying on /usr/src/include. -- DE From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 19:38:53 2008 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 5902E1065680; Mon, 28 Jul 2008 19:38:52 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing01.lava.net (cake.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b50]) by mx1.freebsd.org (Postfix) with ESMTP id B74898FC1C; Mon, 28 Jul 2008 19:38:51 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTP id 99D83D00F1; Mon, 28 Jul 2008 09:38:48 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id 47514153882; Mon, 28 Jul 2008 09:38:48 -1000 (HST) Date: Mon, 28 Jul 2008 09:38:48 -1000 From: Clifton Royston To: Daniel Eischen Message-ID: <20080728193847.GB19904@lava.net> Mail-Followup-To: Daniel Eischen , Unga , freebsd-stable@freebsd.org References: <217498.53801.qm@web57001.mail.re3.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: Unga , freebsd-stable@freebsd.org Subject: Re: undefined reference to SYS_cpuset 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, 28 Jul 2008 19:38:53 -0000 On Mon, Jul 28, 2008 at 02:05:55PM -0400, Daniel Eischen wrote: > On Mon, 28 Jul 2008, Unga wrote: > > >--- On Mon, 7/28/08, Daniel Eischen wrote: > > > >>Your problem is that you don't have an up-to-date > >>kernel src > >>(src/sys) directory with includes in your build > >>environment. > > > >I have nothing to do with src/sys. I link against FreeBSD libs for a > >long time, it just today onwards did not work. That's all. ... > >>Your libc is being built against an old set of includes, so > >>it is up to you how to want to modify your build > >>environment > >> > > > >I install FreeBSD includes from /usr/src/include and libs from > >/usr/src/lib. From the today onwards if the make in /usr/src/include > >does not install all the headers required for libs building that > >should be clearly documented and notified prominently, that I don't > >see it in UPDATING or any where. > > > >FYI, my libc is build against the **latest** set of includes installed > >by the make in the /usr/src/include and nothing but that, ie, there > >are no other headers in /mypath/include, the compilation and > >installation of libc goes **without** any error. So that "Your libc is > >being built against an old set of includes" is just pure nonsense, and > >stupid statement made without knowing what people are doing. If your initial complaint is "it doesn't work", and other people explain to you that the way you're doing it is wrong, then "the way I do it always works fine" is not a very useful reply - you started by saying it doesn't! What you have been doing happens to work (usually, most of the time) because as long as nothing changes much in the interface to the kernel, it doesn't hurt too much to have stale system include files. (It may be that there were subtle problems along the way which you never noticed because they didn't block the build from completing.) There is only one approved and "guaranteed" by the maintainers way to build things. That doesn't mean it's the only way to do things, but if you build things differently, it's up to you to understand how your system works differently from the base system and to accept the responsibility for fixing problems. That's not a huge deal in this case, as you've been given the answers as to what's missing from your build procedure. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 19:40:31 2008 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 0A4AB106564A; Mon, 28 Jul 2008 19:40:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 63CC28FC16; Mon, 28 Jul 2008 19:40:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 m6SJeQ4M068974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 22:40:26 +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.2/8.14.2) with ESMTP id m6SJePUi004798; Mon, 28 Jul 2008 22:40:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6SJeONM004797; Mon, 28 Jul 2008 22:40:24 +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: Mon, 28 Jul 2008 22:40:24 +0300 From: Kostik Belousov To: Michael toth Message-ID: <20080728194024.GM97161@deviant.kiev.zoral.com.ua> References: <488CACD9.7060002@queldor.net> <488CBB02.1020105@FreeBSD.org> <488CBBAC.7040507@queldor.net> <488CC13F.1020204@FreeBSD.org> <20080727190742.GF97161@deviant.kiev.zoral.com.ua> <488CD9AB.8040401@queldor.net> <20080727204339.GG97161@deviant.kiev.zoral.com.ua> <488CFCC3.2030504@queldor.net> <20080728101840.GK97161@deviant.kiev.zoral.com.ua> <488DFEF7.5000802@queldor.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/pvEKOcHgREgBce" Content-Disposition: inline In-Reply-To: <488DFEF7.5000802@queldor.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Kris Kennaway , Michael Toth , freebsd-stable@freebsd.org Subject: Re: 7.0 Crashing 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, 28 Jul 2008 19:40:31 -0000 --J/pvEKOcHgREgBce Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 28, 2008 at 01:16:39PM -0400, Michael toth wrote: > I had someone run a Dell Diags CD on the machine and it passed all tests. >=20 > Before that it core'd again; here is the backtrace from that one. >=20 > Is there any other want (maybe in freebsd) to test the hardware better?= =20 > and/or should I submit a bug report for this? Sure, you can submit bug report. From my POV, there is actually no data to resolve it. You may use memtest86 (Google for it) for memory/chipset/cpu cache test. --J/pvEKOcHgREgBce Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiOIKgACgkQC3+MBN1Mb4jnKgCg2g15P+T30ClIj3tq8SWtlyLl Qo8AniMt8Ioh6yK1fzRRRww5UIGR50zB =E2+9 -----END PGP SIGNATURE----- --J/pvEKOcHgREgBce-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 19:52:46 2008 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 1A4B3106566B for ; Mon, 28 Jul 2008 19:52:46 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 717658FC08; Mon, 28 Jul 2008 19:52:44 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <488E238D.5010807@FreeBSD.org> Date: Mon, 28 Jul 2008 21:52:45 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Kostik Belousov References: <488CACD9.7060002@queldor.net> <488CBB02.1020105@FreeBSD.org> <488CBBAC.7040507@queldor.net> <488CC13F.1020204@FreeBSD.org> <20080727190742.GF97161@deviant.kiev.zoral.com.ua> <488CD9AB.8040401@queldor.net> <20080727204339.GG97161@deviant.kiev.zoral.com.ua> <488CFCC3.2030504@queldor.net> <20080728101840.GK97161@deviant.kiev.zoral.com.ua> <488DFEF7.5000802@queldor.net> <20080728194024.GM97161@deviant.kiev.zoral.com.ua> In-Reply-To: <20080728194024.GM97161@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Michael Toth , Michael toth Subject: Re: 7.0 Crashing 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, 28 Jul 2008 19:52:46 -0000 Kostik Belousov wrote: > On Mon, Jul 28, 2008 at 01:16:39PM -0400, Michael toth wrote: >> I had someone run a Dell Diags CD on the machine and it passed all tests. >> >> Before that it core'd again; here is the backtrace from that one. >> >> Is there any other want (maybe in freebsd) to test the hardware better? >> and/or should I submit a bug report for this? > Sure, you can submit bug report. From my POV, there is actually no > data to resolve it. i.e. you should have no expectation that anyone else will be able to resolve it either. Note that diagnostics can tell you when a machine has failed, but can never tell you when a machine is working perfectly. Kris > > You may use memtest86 (Google for it) for memory/chipset/cpu cache > test. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 20:06:59 2008 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 1BF85106568D; Mon, 28 Jul 2008 20:06:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 743668FC1B; Mon, 28 Jul 2008 20:06:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 m6SK6rIu070061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 23:06:54 +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.2/8.14.2) with ESMTP id m6SK6rkW005295; Mon, 28 Jul 2008 23:06:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6SK6r2X005294; Mon, 28 Jul 2008 23:06:53 +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: Mon, 28 Jul 2008 23:06:53 +0300 From: Kostik Belousov To: Kris Kennaway Message-ID: <20080728200653.GN97161@deviant.kiev.zoral.com.ua> References: <488CBBAC.7040507@queldor.net> <488CC13F.1020204@FreeBSD.org> <20080727190742.GF97161@deviant.kiev.zoral.com.ua> <488CD9AB.8040401@queldor.net> <20080727204339.GG97161@deviant.kiev.zoral.com.ua> <488CFCC3.2030504@queldor.net> <20080728101840.GK97161@deviant.kiev.zoral.com.ua> <488DFEF7.5000802@queldor.net> <20080728194024.GM97161@deviant.kiev.zoral.com.ua> <488E238D.5010807@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KQSGybwJm5+gcNx6" Content-Disposition: inline In-Reply-To: <488E238D.5010807@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham 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, Michael Toth , Michael toth Subject: Re: 7.0 Crashing 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, 28 Jul 2008 20:06:59 -0000 --KQSGybwJm5+gcNx6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 28, 2008 at 09:52:45PM +0200, Kris Kennaway wrote: > Kostik Belousov wrote: > >On Mon, Jul 28, 2008 at 01:16:39PM -0400, Michael toth wrote: > >>I had someone run a Dell Diags CD on the machine and it passed all test= s. > >> > >>Before that it core'd again; here is the backtrace from that one. > >> > >>Is there any other want (maybe in freebsd) to test the hardware better?= =20 > >>and/or should I submit a bug report for this? > >Sure, you can submit bug report. From my POV, there is actually no > >data to resolve it. >=20 > i.e. you should have no expectation that anyone else will be able to=20 > resolve it either. Why ?! >=20 > Note that diagnostics can tell you when a machine has failed, but can=20 > never tell you when a machine is working perfectly. >=20 > Kris >=20 > > > >You may use memtest86 (Google for it) for memory/chipset/cpu cache > >test. --KQSGybwJm5+gcNx6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiOJtwACgkQC3+MBN1Mb4jFagCg93XNJkcuB2Vf6SLSiWC1bJWP HdMAnRaMg1BgJihCW1nNYn72uBTsM549 =e0+o -----END PGP SIGNATURE----- --KQSGybwJm5+gcNx6-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 28 20:41:12 2008 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 18FAF1065676 for ; Mon, 28 Jul 2008 20:41:12 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A296E8FC1D; Mon, 28 Jul 2008 20:41:10 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <488E2EE8.5080101@FreeBSD.org> Date: Mon, 28 Jul 2008 22:41:12 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Kostik Belousov References: <488CBBAC.7040507@queldor.net> <488CC13F.1020204@FreeBSD.org> <20080727190742.GF97161@deviant.kiev.zoral.com.ua> <488CD9AB.8040401@queldor.net> <20080727204339.GG97161@deviant.kiev.zoral.com.ua> <488CFCC3.2030504@queldor.net> <20080728101840.GK97161@deviant.kiev.zoral.com.ua> <488DFEF7.5000802@queldor.net> <20080728194024.GM97161@deviant.kiev.zoral.com.ua> <488E238D.5010807@FreeBSD.org> <20080728200653.GN97161@deviant.kiev.zoral.com.ua> In-Reply-To: <20080728200653.GN97161@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Michael Toth , Michael toth Subject: Re: 7.0 Crashing 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, 28 Jul 2008 20:41:12 -0000 Kostik Belousov wrote: > On Mon, Jul 28, 2008 at 09:52:45PM +0200, Kris Kennaway wrote: >> Kostik Belousov wrote: >>> On Mon, Jul 28, 2008 at 01:16:39PM -0400, Michael toth wrote: >>>> I had someone run a Dell Diags CD on the machine and it passed all tests. >>>> >>>> Before that it core'd again; here is the backtrace from that one. >>>> >>>> Is there any other want (maybe in freebsd) to test the hardware better? >>>> and/or should I submit a bug report for this? >>> Sure, you can submit bug report. From my POV, there is actually no >>> data to resolve it. >> i.e. you should have no expectation that anyone else will be able to >> resolve it either. > Why ?! This was directed to Michael, sorry. Kris > >> Note that diagnostics can tell you when a machine has failed, but can >> never tell you when a machine is working perfectly. >> >> Kris >> >>> You may use memtest86 (Google for it) for memory/chipset/cpu cache >>> test. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 29 00:27:46 2008 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 5A8A91065673 for ; Tue, 29 Jul 2008 00:27:46 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 0B00E8FC1D for ; Tue, 29 Jul 2008 00:27:45 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from MailerDaemon by fish.ish.com.au with local-bsmtp (Exim 4.63) (envelope-from ) id 1KNdEx-0007ez-Lt for freebsd-stable@freebsd.org; Tue, 29 Jul 2008 10:38:59 +1000 Received: from ip-132.ish.com.au ([203.29.62.132]:57887) by fish.ish.com.au with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1KNdEo-0007eh-8L for freebsd-stable@freebsd.org; Tue, 29 Jul 2008 10:38:50 +1000 / CTCH-RefIDstr=0001.0A150203.488E6400.0001,ss=1,fgs=0 Message-Id: <2D040167-B600-4B4B-B08C-7AD692C9BB2C@ish.com.au> From: Aristedes Maniatis To: FreeBSD Stable Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 29 Jul 2008 10:27:37 +1000 X-Mailer: Apple Mail (2.926) X-CTCH-RefID: str=0001.0A150203.488E6400.0001,ss=1,fgs=0 X-cff-SpamScore: 0(/) X-cff-SpamReport: ----- ----- Message is unknown to the spam scanner. X-cff-LastScanner: antispam Subject: infrastructure 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, 29 Jul 2008 00:27:46 -0000 How do I get in touch with FreeBSD infrastructure people about mailing list set up? Sorry to post here, but I've scoured the web site and cannot find anything more appropriate. Is there a infrastructure@freebsd.org or something similar? I tried svn-src-owner@freebsd.org in relation to the specific question I had, but that address bounced, even though mailman has it advertised as the owner address for the list in question. Thanks Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-stable@FreeBSD.ORG Tue Jul 29 00:34:18 2008 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 518421065674 for ; Tue, 29 Jul 2008 00:34:18 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id B319A8FC13 for ; Tue, 29 Jul 2008 00:34:17 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m6T0YuX8087811; Mon, 28 Jul 2008 19:34:56 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m6T0Yulj087810; Mon, 28 Jul 2008 19:34:56 -0500 (CDT) (envelope-from brooks) Date: Mon, 28 Jul 2008 19:34:56 -0500 From: Brooks Davis To: Aristedes Maniatis Message-ID: <20080729003456.GB87699@lor.one-eyed-alien.net> References: <2D040167-B600-4B4B-B08C-7AD692C9BB2C@ish.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l76fUT7nc3MelDdI" Content-Disposition: inline In-Reply-To: <2D040167-B600-4B4B-B08C-7AD692C9BB2C@ish.com.au> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: FreeBSD Stable Subject: Re: infrastructure 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, 29 Jul 2008 00:34:18 -0000 --l76fUT7nc3MelDdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 29, 2008 at 10:27:37AM +1000, Aristedes Maniatis wrote: > How do I get in touch with FreeBSD infrastructure people about mailing li= st=20 > set up? Sorry to post here, but I've scoured the web site and cannot find= =20 > anything more appropriate. Is there a infrastructure@freebsd.org or=20 > something similar? >=20 > I tried svn-src-owner@freebsd.org in relation to the specific question I= =20 > had, but that address bounced, even though mailman has it advertised as t= he=20 > owner address for the list in question. You can always address questions about e-mail to postmaster@freebsd.org. -- Brooks >=20 > Thanks > Ari Maniatis >=20 >=20 >=20 >=20 > --------------------------> > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >=20 >=20 > _______________________________________________ > 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 --l76fUT7nc3MelDdI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIjmWwXY6L6fI4GtQRAiV5AJ9BQsVDN9v0ntFSvQKeSRMC+oO/AgCggGEM 1K5lAqcboWbEilA5AhuGfrQ= =iCnb -----END PGP SIGNATURE----- --l76fUT7nc3MelDdI-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 29 09:38:30 2008 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 B4939106566B; Tue, 29 Jul 2008 09:38:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 797CC8FC20; Tue, 29 Jul 2008 09:38:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m6T9cSIJ012785; Tue, 29 Jul 2008 05:38:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m6T9cSXi099789; Tue, 29 Jul 2008 05:38:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 83B551B5078; Tue, 29 Jul 2008 05:38:28 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080729093828.83B551B5078@freebsd-stable.sentex.ca> Date: Tue, 29 Jul 2008 05:38:28 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7873/Tue Jul 29 01:16:14 2008 clamav-milter version 0.93 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_7 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, 29 Jul 2008 09:38:30 -0000 TB --- 2008-07-29 09:37:14 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-07-29 09:37:14 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2008-07-29 09:37:14 - cleaning the object tree TB --- 2008-07-29 09:37:32 - cvsupping the source tree TB --- 2008-07-29 09:37:32 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB --- 2008-07-29 09:37:41 - building world (CFLAGS=-O2 -pipe) TB --- 2008-07-29 09:37:41 - cd /src TB --- 2008-07-29 09:37:41 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 29 09:37:43 UTC 2008 >>> 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 [...] rm -f termcap termcap.db termcap.5.gz termcap.5.cat.gz ===> share/timedef (cleandir) rm -f am_ET.UTF-8.out be_BY.CP1131.out be_BY.CP1251.out be_BY.ISO8859-5.out be_BY.UTF-8.out bg_BG.CP1251.out bg_BG.UTF-8.out ca_ES.ISO8859-1.out ca_ES.UTF-8.out cs_CZ.ISO8859-2.out cs_CZ.UTF-8.out da_DK.ISO8859-1.out da_DK.UTF-8.out de_AT.ISO8859-1.out de_AT.UTF-8.out de_DE.ISO8859-1.out de_DE.UTF-8.out el_GR.ISO8859-7.out el_GR.UTF-8.out en_GB.ISO8859-1.out en_US.ISO8859-1.out es_ES.ISO8859-1.out es_ES.UTF-8.out et_EE.ISO8859-15.out et_EE.UTF-8.out eu_ES.ISO8859-1.out fi_FI.ISO8859-1.out fi_FI.UTF-8.out fr_FR.ISO8859-1.out fr_FR.UTF-8.out he_IL.UTF-8.out hi_IN.ISCII-DEV.out hr_HR.ISO8859-2.out hr_HR.UTF-8.out hu_HU.ISO8859-2.out hu_HU.UTF-8.out hy_AM.ARMSCII-8.out hy_AM.UTF-8.out is_IS.ISO8859-1.out is_IS.UTF-8.out ja_JP.eucJP.out ja_JP.SJIS.out ja_JP.UTF-8.out it_IT.ISO8859-1.out it_IT.UTF-8.out kk_KZ.PT154.out kk_KZ.UTF-8.out ko_KR.eucKR.out ko_KR.UTF-8.out la_LN.ISO8859-1.out lt_LT.ISO8859-4.out lt_LT.ISO8859-13.out lt_LT.UTF-8.out mn_MN.UTF-8.out nl_NL.ISO8859-1.out nn_N O.ISO8859-1.out nn_NO.UTF-8.out no_NO.ISO8859-1.out no_NO.UTF-8.out pl_PL.ISO8859-2.out pl_PL.UTF-8.out pt_BR.ISO8859-1.out pt_BR.UTF-8.out pt_PT.ISO8859-1.out pt_PT.UTF-8.out ro_RO.ISO8859-2.out ro_RO.UTF-8.out ru_RU.CP1251.out ru_RU.CP866.out ru_RU.ISO8859-5.out ru_RU.KOI8-R.out ru_RU.UTF-8.out sk_SK.ISO8859-2.out sk_SK.UTF-8.out sl_SI.ISO8859-2.out sl_SI.UTF-8.out sr_YU.ISO8859-2.out sr_YU.ISO8859-5.out sr_YU.UTF-8.out sv_SE.ISO8859-1.out sv_SE.UTF-8.out tr_TR.ISO8859-9.out tr_TR.UTF-8.out uk_UA.CP1251.out uk_UA.ISO8859-5.out uk_UA.KOI8-U.out uk_UA.UTF-8.out zh_CN.eucCN.out zh_CN.GB18030.out zh_CN.GB2312.out zh_CN.UTF-8.out zh_TW.Big5.out zh_TW.UTF-8.out ===> share/zoneinfo (cleandir) rm -f yearistype ===> sys (cleandir) "Makefile", line 15: Unassociated shell command "sys ufs vm xdr ${ARCHDIR}" make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-07-29 09:38:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-07-29 09:38:28 - ERROR: failed to build world TB --- 2008-07-29 09:38:28 - tinderbox aborted TB --- 22.80 user 9.47 system 74.10 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Tue Jul 29 15:45:53 2008 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 26A7D106573F; Tue, 29 Jul 2008 15:45:53 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id DD0BA8FC17; Tue, 29 Jul 2008 15:45:52 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id m6TFjjku008758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 11:45:45 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-current , freebsd-stable Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-elH5HRNB70HcCHq/uHzT" Organization: U. Buffalo CSE Department Date: Tue, 29 Jul 2008 11:45:45 -0400 Message-Id: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Cc: Subject: Upcoming ABI Breakage in RELENG_7 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, 29 Jul 2008 15:45:53 -0000 --=-elH5HRNB70HcCHq/uHzT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Normally the FreeBSD Project tries very hard to avoid ABI breakage in "Stable Branches". However occasionally the fix for a bug can not be implemented without ABI breakage, and it is decided that the fix warrants the impact of the ABI breakage. We have one of those situations coming along for RELENG_7 (what will become FreeBSD 7.1). The ABI breakage should only impact kernel modules that are not part of the baseline system (those will be patched by the MFC) which deal with advisory locks. As such the impact should not cause many people problems. The work that will be MFCed fixes issues with filesystem advisory locks, and moves the advisory locks list from filesystem-private data structures into the vnode structure. The MFC will be done by Kostantin Belousov some time this coming Friday (August 1st, 2008) if you have concerns and want to watch for it. Thanks. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-elH5HRNB70HcCHq/uHzT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkiPOx4ACgkQ/G14VSmup/ZpiQCeLnmSiq72AvS/5fFs5ZD+8XpT ZhsAn1CIgEZ/jIt7D0HpoX2Tu6pSSozX =izSx -----END PGP SIGNATURE----- --=-elH5HRNB70HcCHq/uHzT-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 29 18:41:30 2008 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 00787106566B for ; Tue, 29 Jul 2008 18:41:30 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.freebsd.org (Postfix) with ESMTP id D55518FC0A for ; Tue, 29 Jul 2008 18:41:29 +0000 (UTC) (envelope-from smallhand@crawblog.com) Received: by wf-out-1314.google.com with SMTP id 24so2227wfg.7 for ; Tue, 29 Jul 2008 11:41:29 -0700 (PDT) Received: by 10.142.44.11 with SMTP id r11mr2273462wfr.178.1217356889348; Tue, 29 Jul 2008 11:41:29 -0700 (PDT) Received: by 10.142.194.9 with HTTP; Tue, 29 Jul 2008 11:41:29 -0700 (PDT) Message-ID: <919383240807291141u506d6e47o8db784117a9ccc66@mail.gmail.com> Date: Tue, 29 Jul 2008 13:41:29 -0500 From: "Edward Ruggeri" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: How to rollback a driver? 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, 29 Jul 2008 18:41:30 -0000 Hi, I have had problems with the Atheros driver under FreeBSD 7-STABLE (specifically, kernel panics on even trivial network load); under 7.0-RELEASE, I had none. I filed a PR, but I'm not sure how quickly we can solve the issue. Other than this driver issue, I'd prefer to use the STABLE branch. Is it possible to swap out the current ath driver for an older one? Could I still build it in the kernel? Besides this issue, everything seems to work fine. Thanks! Sincerely, -- Ned Ruggeri From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 09:25:01 2008 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 63A141065679 for ; Wed, 30 Jul 2008 09:25:01 +0000 (UTC) (envelope-from david@vizion2000.net) Received: from dns1.vizion2000.net (77-99-36-42.cable.ubr04.chap.blueyonder.co.uk [77.99.36.42]) by mx1.freebsd.org (Postfix) with ESMTP id 296748FC22 for ; Wed, 30 Jul 2008 09:25:01 +0000 (UTC) (envelope-from david@vizion2000.net) Received: by dns1.vizion2000.net (Postfix, from userid 1007) id 296B81CC82; Wed, 30 Jul 2008 02:47:35 -0700 (PDT) From: David Southwell Organization: Voice and Vision To: freebsd-stable@freebsd.org Date: Wed, 30 Jul 2008 02:47:34 -0700 User-Agent: KMail/1.9.7 References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> In-Reply-To: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807300247.34948.david@vizion2000.net> Cc: Ken Smith , freebsd-current Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 09:25:01 -0000 On Tuesday 29 July 2008 08:45:45 Ken Smith wrote: > Normally the FreeBSD Project tries very hard to avoid ABI breakage in > "Stable Branches". However occasionally the fix for a bug can not be > implemented without ABI breakage, and it is decided that the fix > warrants the impact of the ABI breakage. We have one of those > situations coming along for RELENG_7 (what will become FreeBSD 7.1). > The ABI breakage should only impact kernel modules that are not part of > the baseline system (those will be patched by the MFC) which deal with > advisory locks. As such the impact should not cause many people > problems. > > The work that will be MFCed fixes issues with filesystem advisory locks, > and moves the advisory locks list from filesystem-private data > structures into the vnode structure. > > The MFC will be done by Kostantin Belousov some time this coming Friday > (August 1st, 2008) if you have concerns and want to watch for it. > > Thanks. Sometimes information gets posted to this list on the assumption that everyone understand what the writer means. This is one of those occasions!! For those of us who are not as well informed and experienced as others could someone please explain what is meant by an ABI breakage, its implications and how to deal with them. Thanks David From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 09:34:48 2008 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 67D051065672 for ; Wed, 30 Jul 2008 09:34:48 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out2.tiscali.nl (smtp-out2.tiscali.nl [195.241.79.177]) by mx1.freebsd.org (Postfix) with ESMTP id 314B88FC13 for ; Wed, 30 Jul 2008 09:34:48 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from [212.123.145.58] (helo=guido.klop.ws) by smtp-out2.tiscali.nl with smtp id 1KO850-0001L2-MN for ; Wed, 30 Jul 2008 11:34:46 +0200 Received: (qmail 1339 invoked from network); 30 Jul 2008 09:34:44 -0000 Received: from localhost (HELO 82-170-177-25.ip.telfort.nl) (127.0.0.1) by localhost with SMTP; 30 Jul 2008 09:34:44 -0000 Date: Wed, 30 Jul 2008 11:34:42 +0200 To: "David Southwell" , freebsd-stable@freebsd.org From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807300247.34948.david@vizion2000.net> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <200807300247.34948.david@vizion2000.net> User-Agent: Opera Mail/9.51 (FreeBSD) Cc: Ken Smith , freebsd-current Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 09:34:48 -0000 On Wed, 30 Jul 2008 11:47:34 +0200, David Southwell wrote: > On Tuesday 29 July 2008 08:45:45 Ken Smith wrote: >> Normally the FreeBSD Project tries very hard to avoid ABI breakage in >> "Stable Branches". However occasionally the fix for a bug can not be >> implemented without ABI breakage, and it is decided that the fix >> warrants the impact of the ABI breakage. We have one of those >> situations coming along for RELENG_7 (what will become FreeBSD 7.1). >> The ABI breakage should only impact kernel modules that are not part of >> the baseline system (those will be patched by the MFC) which deal with >> advisory locks. As such the impact should not cause many people >> problems. >> >> The work that will be MFCed fixes issues with filesystem advisory locks, >> and moves the advisory locks list from filesystem-private data >> structures into the vnode structure. >> >> The MFC will be done by Kostantin Belousov some time this coming Friday >> (August 1st, 2008) if you have concerns and want to watch for it. >> >> Thanks. > Sometimes information gets posted to this list on the assumption that > everyone > understand what the writer means. > > This is one of those occasions!! > > For those of us who are not as well informed and experienced as others > could > someone please explain what is meant by an ABI breakage, its > implications > and how to deal with them. > > Thanks > > David Googling for ABI gives me this: http://en.wikipedia.org/wiki/Application_binary_interface That is part of what you want to know. Ronald. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 09:47:18 2008 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 A0E211065690 for ; Wed, 30 Jul 2008 09:47:18 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 3A9118FC17 for ; Wed, 30 Jul 2008 09:47:18 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-023-173.pools.arcor-ip.net [88.66.23.173]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1KO8H70b4A-0004pd; Wed, 30 Jul 2008 11:47:17 +0200 Received: (qmail 22939 invoked from network); 30 Jul 2008 09:47:16 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by laiers.local with SMTP; 30 Jul 2008 09:47:16 -0000 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Wed, 30 Jul 2008 11:47:14 +0200 User-Agent: KMail/1.9.52 (FreeBSD/8.0-CURRENT; KDE/4.0.83; i386; ; ) References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807300247.34948.david@vizion2000.net> In-Reply-To: <200807300247.34948.david@vizion2000.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807301147.15039.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19ohBMtGDogSlK6sNtTlmmLHu19XDoI3mGaTo1 VnfT3dqpC8uGiwp4JX50rQxjil5+02BrDLIGsBF3ICi67tvmAM 0Y3oLM/WRTxfLcoJVsH4A== Cc: Ken Smith , David Southwell , freebsd-current Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 09:47:18 -0000 On Wednesday 30 July 2008 11:47:34 David Southwell wrote: > On Tuesday 29 July 2008 08:45:45 Ken Smith wrote: ... > For those of us who are not as well informed and experienced as others > could someone please explain what is meant by an ABI breakage, its > implications and how to deal with them. An Application Binary Interface (ABI) breakage means a change of a complex datatype, or a function prototype - in C usually the change of a struct in size or field sort order. This change will effect all consumers of this Interface unless they are recompiled with the changed header files to also use the new interface. The impact depends greatly on the interface that is being changed. As Ken described in the initial mail this change is in the filesystem/vnode layer interface and thus will (only) concern consumers of that ABI. The changed interface is also a kernel-only interface - that means that only 3rd party kernel modules will be affected. I personally don't know of any 3rd party modules that muck about with filesystems (for which you can't get the source). That said, you might have to rebuild stuff like fuse after the breakage has happened. I assume that port maintainers of affected (kernel module) ports will bump the port revision after the change to give you/portupgrade a hint. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 09:55:46 2008 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 1F8541065679; Wed, 30 Jul 2008 09:55:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 935428FC1A; Wed, 30 Jul 2008 09:55:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 m6U9tZ5l088540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 12:55:35 +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.2/8.14.2) with ESMTP id m6U9tYob015389; Wed, 30 Jul 2008 12:55:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6U9tYff015388; Wed, 30 Jul 2008 12:55:34 +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: Wed, 30 Jul 2008 12:55:34 +0300 From: Kostik Belousov To: David Southwell Message-ID: <20080730095534.GR97161@deviant.kiev.zoral.com.ua> References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807300247.34948.david@vizion2000.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lYtTbTuCUQxZgETo" Content-Disposition: inline In-Reply-To: <200807300247.34948.david@vizion2000.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ken Smith , freebsd-stable@freebsd.org, freebsd-current Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 09:55:46 -0000 --lYtTbTuCUQxZgETo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 30, 2008 at 02:47:34AM -0700, David Southwell wrote: > On Tuesday 29 July 2008 08:45:45 Ken Smith wrote: > > Normally the FreeBSD Project tries very hard to avoid ABI breakage in > > "Stable Branches". However occasionally the fix for a bug can not be > > implemented without ABI breakage, and it is decided that the fix > > warrants the impact of the ABI breakage. We have one of those > > situations coming along for RELENG_7 (what will become FreeBSD 7.1). > > The ABI breakage should only impact kernel modules that are not part of > > the baseline system (those will be patched by the MFC) which deal with > > advisory locks. As such the impact should not cause many people > > problems. > > > > The work that will be MFCed fixes issues with filesystem advisory locks, > > and moves the advisory locks list from filesystem-private data > > structures into the vnode structure. > > > > The MFC will be done by Kostantin Belousov some time this coming Friday > > (August 1st, 2008) if you have concerns and want to watch for it. > > > > Thanks. > Sometimes information gets posted to this list on the assumption that eve= ryone=20 > understand what the writer means. >=20 > This is one of those occasions!! >=20 > For those of us who are not as well informed and experienced as others c= ould=20 > someone please explain what is meant by an ABI breakage, its implication= s=20 > and how to deal with them. The small glitch in the announcement is use of the ABI =3D=3D Application Binary Interface term, that is better be replaced by KBI =3D=3D Kernel Bina= ry Interface. No usermode breakage is expected to result from MFC. The only consequence is the need to adopt some out-of-tree filesystems, not that I am aware of any ATM. If you are the author or maintainer of such module, then you need to watch this out. --lYtTbTuCUQxZgETo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiQOpUACgkQC3+MBN1Mb4hkrwCgjPiVpsaxrbcY9dNxzkgjlz5y mnMAnAjqc2yGSdsEkfbHm7MnScPocIOp =I0hU -----END PGP SIGNATURE----- --lYtTbTuCUQxZgETo-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 10:04:44 2008 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 AF7F51065678 for ; Wed, 30 Jul 2008 10:04:44 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 531158FC15 for ; Wed, 30 Jul 2008 10:04:43 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fg-out-1718.google.com with SMTP id l26so339240fgb.35 for ; Wed, 30 Jul 2008 03:04:42 -0700 (PDT) Received: by 10.103.49.12 with SMTP id b12mr3559926muk.72.1217410595964; Wed, 30 Jul 2008 02:36:35 -0700 (PDT) Received: by 10.103.225.8 with HTTP; Wed, 30 Jul 2008 02:36:35 -0700 (PDT) Message-ID: Date: Wed, 30 Jul 2008 12:36:35 +0300 From: "Vlad GALU" To: "David Southwell" In-Reply-To: <200807300247.34948.david@vizion2000.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807300247.34948.david@vizion2000.net> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 10:04:44 -0000 On 7/30/08, David Southwell wrote: > On Tuesday 29 July 2008 08:45:45 Ken Smith wrote: > > Normally the FreeBSD Project tries very hard to avoid ABI breakage in > > "Stable Branches". However occasionally the fix for a bug can not be > > implemented without ABI breakage, and it is decided that the fix > > warrants the impact of the ABI breakage. We have one of those > > situations coming along for RELENG_7 (what will become FreeBSD 7.1). > > The ABI breakage should only impact kernel modules that are not part of > > the baseline system (those will be patched by the MFC) which deal with > > advisory locks. As such the impact should not cause many people > > problems. > > > > The work that will be MFCed fixes issues with filesystem advisory locks, > > and moves the advisory locks list from filesystem-private data > > structures into the vnode structure. > > > > The MFC will be done by Kostantin Belousov some time this coming Friday > > (August 1st, 2008) if you have concerns and want to watch for it. > > > > Thanks. > > Sometimes information gets posted to this list on the assumption that everyone > understand what the writer means. > > This is one of those occasions!! > > For those of us who are not as well informed and experienced as others could > someone please explain what is meant by an ABI breakage, its implications > and how to deal with them. > ABI breakage occurs when internal data structures change (for instance, when members of the structure are removed or added). Kernel modules which expect those structures to look in a certain way will need to be recompiled. Also, depending on what data structures suffer the changes, ioctl() operations may fail, requiring a rebuild of the userland programs which issue the ioctl()s. And I'm sure that there are many other examples that I can't think of right now :) -- ~/.signature: no such file or directory From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 10:07:54 2008 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 906A41065679 for ; Wed, 30 Jul 2008 10:07:54 +0000 (UTC) (envelope-from modelnine@modelnine.org) Received: from jord.modelnine.org (jord.modelnine.org [83.246.72.120]) by mx1.freebsd.org (Postfix) with ESMTP id 2CD708FC21 for ; Wed, 30 Jul 2008 10:07:53 +0000 (UTC) (envelope-from modelnine@modelnine.org) Received: from [192.168.1.37] (a89-182-17-67.net-htp.de [89.182.17.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: modelnine) by jord.modelnine.org (Postfix) with ESMTPSA id 20C47A40CC0 for ; Wed, 30 Jul 2008 12:07:53 +0200 (CEST) From: Heiko Wundram To: freebsd-stable@freebsd.org Date: Wed, 30 Jul 2008 12:11:54 +0200 User-Agent: KMail/1.9.7 References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807300247.34948.david@vizion2000.net> In-Reply-To: <200807300247.34948.david@vizion2000.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807301211.54974.modelnine@modelnine.org> Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 10:07:54 -0000 Am Mittwoch, 30. Juli 2008 11:47:34 schrieb David Southwell: > For those of us who are not as well informed and experienced as others > could someone please explain what is meant by an ABI breakage, its > implications and how to deal with them. ABI (Application Binary Interface) is a term used to describe the characteristics of binary (i.e. object-) code when accessed from other binary code. Generally, this entails everything from method signatures over structure sizes to global data (exported symbols) sizes. One example of ABI-breakage, if you're somewhat proficient in C, could be the following: -- Old code (library header) /* Some structure which contains a long, and so has total size four bytes on i386. */ struct x { long y; } __attribute__((packed))__; /* Get access to two x objects. This function is implemented in a shared library. It returns a pointer to eight bytes of memory (2*struct x). */ extern const struct x* getSomeData(); -- Old code (user) long test() { const struct x* ref = getSomeData(); return ref[0].y + ref[1].y; } -- Now, when compiling the user code, it will pick up the specification of the structure x through the library supplied header file, seeing that ref[...].y is a long value (four bytes on i386), and so that will be translated to some machine code which adds four bytes from offset zero (ref[0].y) of the pointer that getSomeData() returns to four bytes from offset four (ref[1].y), and returns the result as a long value. What happens if the following change to the library is made? -- New code (library header) /* Some structure which now contains a short. This reduces the size of the structure to two bytes on i386. */ struct x { short y; } __attribute__((packed))__; /* Get access to two x objects. This function is implemented in a shared library. Due to the change in struct x, this now returns a pointer to (only!) four bytes of storage (2*struct x). */ extern const struct x* getSomeData(); -- The size of the structure member y of structure x has now been reduced to two bytes (because the type was changed from long to short), but the user code doesn't know this, because it was compiled with the old headers. When installing the changed shared library, the old user code will load (!) as before, because the symbol getSomeData() is still exported from the shared library, but will now erraneously load in total eight bytes from a location (because that's hardcoded in the machine code produced for the user binary) where it should only load four bytes from after the incompatible change to the layout of the structure. If you were to recompile the user code after installing the updated shared library, everything would go back to functioning normally, because now the user code picks up the redefined structure x specification which now says that it should load only two bytes from offset zero (ref[0].y) and two bytes from offset two (ref[1].y) of the returned pointer. The API has not changed, because the user code would still compile properly, but the ABI has, and as such object code compiled before the change in the shared library breaks (most often in very mysterious ways). I don't know exactly what will be changed in the kernel to warrant the heads up for this specific case, but as was said, the vnode structure is changed (because data was added to it), and as such the structure specification has changed. If you now have a KLM which expects the old structure layout (because it was compiled before the change), you're bound for trouble, because it does not yet know that the offsets for members and the total size of the vnode structure has changed, and as such all offsets it uses in the vnode structure are broken. So, if you have a binary only kernel module which requires access/uses the vnode structure, you'll have a problem. If not, you don't. Does this help? -- Heiko Wundram From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 10:48:57 2008 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 47A6C106567B for ; Wed, 30 Jul 2008 10:48:57 +0000 (UTC) (envelope-from david@vizion2000.net) Received: from dns1.vizion2000.net (77-99-36-42.cable.ubr04.chap.blueyonder.co.uk [77.99.36.42]) by mx1.freebsd.org (Postfix) with ESMTP id BE5278FC1E for ; Wed, 30 Jul 2008 10:48:56 +0000 (UTC) (envelope-from david@vizion2000.net) Received: by dns1.vizion2000.net (Postfix, from userid 1007) id C32371CC21; Wed, 30 Jul 2008 04:11:31 -0700 (PDT) From: David Southwell Organization: Voice and Vision To: freebsd-stable@freebsd.org Date: Wed, 30 Jul 2008 04:11:31 -0700 User-Agent: KMail/1.9.7 References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807300247.34948.david@vizion2000.net> <200807301211.54974.modelnine@modelnine.org> In-Reply-To: <200807301211.54974.modelnine@modelnine.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807300411.31557.david@vizion2000.net> Cc: Heiko Wundram Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 10:48:57 -0000 On Wednesday 30 July 2008 03:11:54 Heiko Wundram wrote: > Am Mittwoch, 30. Juli 2008 11:47:34 schrieb David Southwell: > > For those of us who are not as well informed and experienced as others > > could someone please explain what is meant by an ABI breakage, its > > implications and how to deal with them. > > ABI (Application Binary Interface) is a term used to describe the > characteristics of binary (i.e. object-) code when accessed from other > binary code. Generally, this entails everything from method signatures over > structure sizes to global data (exported symbols) sizes. > > One example of ABI-breakage, if you're somewhat proficient in C, could be > the following: > > -- Old code (library header) > > /* Some structure which contains a long, and so has total size four bytes > on i386. */ > struct x { > long y; > } __attribute__((packed))__; > > /* Get access to two x objects. This function is implemented in a shared > library. It returns a pointer to eight bytes of memory (2*struct x). */ > extern const struct x* getSomeData(); > > -- Old code (user) > > long test() { > const struct x* ref = getSomeData(); > return ref[0].y + ref[1].y; > } > > -- > > Now, when compiling the user code, it will pick up the specification of the > structure x through the library supplied header file, seeing that > ref[...].y is a long value (four bytes on i386), and so that will be > translated to some machine code which adds four bytes from offset zero > (ref[0].y) of the pointer that getSomeData() returns to four bytes from > offset four (ref[1].y), and returns the result as a long value. > > What happens if the following change to the library is made? > > -- New code (library header) > > /* Some structure which now contains a short. This reduces the size of the > structure to two bytes on i386. */ > struct x { > short y; > } __attribute__((packed))__; > > /* Get access to two x objects. This function is implemented in a shared > library. Due to the change in struct x, this now returns a pointer to > (only!) four bytes of storage (2*struct x). */ > extern const struct x* getSomeData(); > > -- > > The size of the structure member y of structure x has now been reduced to > two bytes (because the type was changed from long to short), but the user > code doesn't know this, because it was compiled with the old headers. When > installing the changed shared library, the old user code will load (!) as > before, because the symbol getSomeData() is still exported from the shared > library, but will now erraneously load in total eight bytes from a location > (because that's hardcoded in the machine code produced for the user binary) > where it should only load four bytes from after the incompatible change to > the layout of the structure. > > If you were to recompile the user code after installing the updated shared > library, everything would go back to functioning normally, because now the > user code picks up the redefined structure x specification which now says > that it should load only two bytes from offset zero (ref[0].y) and two > bytes from offset two (ref[1].y) of the returned pointer. > > The API has not changed, because the user code would still compile > properly, but the ABI has, and as such object code compiled before the > change in the shared library breaks (most often in very mysterious ways). > > I don't know exactly what will be changed in the kernel to warrant the > heads up for this specific case, but as was said, the vnode structure is > changed (because data was added to it), and as such the structure > specification has changed. If you now have a KLM which expects the old > structure layout (because it was compiled before the change), you're bound > for trouble, because it does not yet know that the offsets for members and > the total size of the vnode structure has changed, and as such all offsets > it uses in the vnode structure are broken. > > So, if you have a binary only kernel module which requires access/uses the > vnode structure, you'll have a problem. If not, you don't. > > Does this help? It sure helps the understanding bit but how about specific instructions about who is to what to do in this instance? i.e. Circumstances and what commands to apply in those circumstances? The general helps understanding.. the specifics provide solutions for the problems!! Thanks again David From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 10:58:53 2008 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 347671065676 for ; Wed, 30 Jul 2008 10:58:53 +0000 (UTC) (envelope-from modelnine@modelnine.org) Received: from jord.modelnine.org (jord.modelnine.org [83.246.72.120]) by mx1.freebsd.org (Postfix) with ESMTP id F1CB18FC34 for ; Wed, 30 Jul 2008 10:58:52 +0000 (UTC) (envelope-from modelnine@modelnine.org) Received: from [192.168.1.37] (a89-182-17-67.net-htp.de [89.182.17.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: modelnine) by jord.modelnine.org (Postfix) with ESMTPSA id 65F38A40CC0 for ; Wed, 30 Jul 2008 12:58:50 +0200 (CEST) From: Heiko Wundram To: freebsd-stable@freebsd.org Date: Wed, 30 Jul 2008 13:02:52 +0200 User-Agent: KMail/1.9.7 References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807301211.54974.modelnine@modelnine.org> <200807300411.31557.david@vizion2000.net> In-Reply-To: <200807300411.31557.david@vizion2000.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807301302.52450.modelnine@modelnine.org> Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 10:58:53 -0000 Am Mittwoch, 30. Juli 2008 13:11:31 schrieb David Southwell: > i.e. Circumstances and what commands to apply in those circumstances? If you don't know what to do, don't run -STABLE? -- Heiko Wundram From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 11:03:37 2008 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 299EC106567A for ; Wed, 30 Jul 2008 11:03:37 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out0.tiscali.nl (smtp-out0.tiscali.nl [195.241.79.175]) by mx1.freebsd.org (Postfix) with ESMTP id E95928FC1E for ; Wed, 30 Jul 2008 11:03:36 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from [212.123.145.58] (helo=guido.klop.ws) by smtp-out0.tiscali.nl with smtp id 1KO9Sx-00030T-Lm for ; Wed, 30 Jul 2008 13:03:35 +0200 Received: (qmail 1666 invoked from network); 30 Jul 2008 11:03:35 -0000 Received: from localhost (HELO 82-170-177-25.ip.telfort.nl) (127.0.0.1) by localhost with SMTP; 30 Jul 2008 11:03:35 -0000 Date: Wed, 30 Jul 2008 13:03:34 +0200 To: "Heiko Wundram" , freebsd-stable@freebsd.org From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807301211.54974.modelnine@modelnine.org> <200807300411.31557.david@vizion2000.net> <200807301302.52450.modelnine@modelnine.org> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <200807301302.52450.modelnine@modelnine.org> User-Agent: Opera Mail/9.51 (FreeBSD) Cc: Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 11:03:37 -0000 On Wed, 30 Jul 2008 13:02:52 +0200, Heiko Wundram wrote: > Am Mittwoch, 30. Juli 2008 13:11:31 schrieb David Southwell: >> i.e. Circumstances and what commands to apply in those circumstances? > > If you don't know what to do, don't run -STABLE? > I think in this case (the ABI breakage) it is more nice to say: "If you don't know what to do, you wil probably not see any problem because of this." The edge case of what can go wrong is so small, that you must be doing quite specialized stuff to see breakage. In that case you would understand what is going on. (IMHO) Ronald. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 11:22:33 2008 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 BD1CC106564A for ; Wed, 30 Jul 2008 11:22:33 +0000 (UTC) (envelope-from modelnine@modelnine.org) Received: from jord.modelnine.org (jord.modelnine.org [83.246.72.120]) by mx1.freebsd.org (Postfix) with ESMTP id 588828FC23 for ; Wed, 30 Jul 2008 11:22:33 +0000 (UTC) (envelope-from modelnine@modelnine.org) Received: from [192.168.1.37] (a89-182-17-67.net-htp.de [89.182.17.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: modelnine) by jord.modelnine.org (Postfix) with ESMTPSA id E6A78A40CC0 for ; Wed, 30 Jul 2008 13:22:31 +0200 (CEST) From: Heiko Wundram To: freebsd-stable@freebsd.org Date: Wed, 30 Jul 2008 13:26:33 +0200 User-Agent: KMail/1.9.7 References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807301302.52450.modelnine@modelnine.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807301326.33227.modelnine@modelnine.org> Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 11:22:33 -0000 Am Mittwoch, 30. Juli 2008 13:03:34 schrieb Ronald Klop: > I think in this case (the ABI breakage) it is more nice to say: "If you > don't know what to do, you wil probably not see any problem because of > this." > The edge case of what can go wrong is so small, that you must be doing > quite specialized stuff to see breakage. In that case you would understand > what is going on. (IMHO) Err, no. As someone else has already noted, a prominent KLM that's distributed separately from the kernel which uses the vnode structure extensively (which I didn't think of at all until I read the respective mail) is fuse. A pre-upgrade compiled fuse is most certainly going to break because of this change. Some people have dual installations of Windows/FreeBSD (at least I'd presume that's the case with the fiddlers like me that track -STABLE as a hobby, not as a developer, or those developers who program for Windows as a day-job, also like me) who use ntfs-3g to mount their NTFS-data; additionally, I also extensively use ssh-fs, which is also fuse-based, and I guess there are also others who use it, and so the reach of this ABI-change, at least IMHO, is much larger than the original message makes you believe. Now, after the update, a lot can go wrong, because the fuse KLM is loaded by an init-script, and your system is most probably going to Oops while booting if you didn't think of disabling the fuse init-script before you update your kernel, and will NOT fail "gracefully". If the respective person doesn't know how he/she should boot to single-user-mode, update rc.conf to disable this, reboot, rebuild the module to get the system back up, the only thing I can possibly say is: "don't track stable." It might've sounded a bit harsh what I wrote, but tracking -STABLE means knowing your system enough so that you know how to fix things if they come back to bite you (especially after getting a HEADS UP). And that doesn't seem to be the case here if the respective person asks for SPECIFIC instructions what to do. So, again: DON'T track -STABLE if you can't fix the system if it breaks, and AFAICT this change is most certainly going to break quite a few systems. -- Heiko Wundram From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 11:30:36 2008 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 080C31065671 for ; Wed, 30 Jul 2008 11:30:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 8065D8FC1B for ; Wed, 30 Jul 2008 11:30:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 m6UBUV9L094124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 14:30:31 +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.2/8.14.2) with ESMTP id m6UBUVGJ017137; Wed, 30 Jul 2008 14:30:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m6UBUV2P017136; Wed, 30 Jul 2008 14:30:31 +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: Wed, 30 Jul 2008 14:30:31 +0300 From: Kostik Belousov To: Heiko Wundram Message-ID: <20080730113031.GS97161@deviant.kiev.zoral.com.ua> References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807301302.52450.modelnine@modelnine.org> <200807301326.33227.modelnine@modelnine.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dx1O6sYEs5STvSrm" Content-Disposition: inline In-Reply-To: <200807301326.33227.modelnine@modelnine.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham 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 Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 11:30:36 -0000 --Dx1O6sYEs5STvSrm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 30, 2008 at 01:26:33PM +0200, Heiko Wundram wrote: > Am Mittwoch, 30. Juli 2008 13:03:34 schrieb Ronald Klop: > > I think in this case (the ABI breakage) it is more nice to say: "If you > > don't know what to do, you wil probably not see any problem because of > > this." > > The edge case of what can go wrong is so small, that you must be doing > > quite specialized stuff to see breakage. In that case you would underst= and > > what is going on. (IMHO) >=20 > Err, no. >=20 > As someone else has already noted, a prominent KLM that's distributed=20 > separately from the kernel which uses the vnode structure extensively (wh= ich=20 > I didn't think of at all until I read the respective mail) is fuse. A=20 > pre-upgrade compiled fuse is most certainly going to break because of thi= s=20 > change. Some people have dual installations of Windows/FreeBSD (at least = I'd=20 > presume that's the case with the fiddlers like me that track -STABLE as a= =20 > hobby, not as a developer, or those developers who program for Windows as= a=20 > day-job, also like me) who use ntfs-3g to mount their NTFS-data;=20 > additionally, I also extensively use ssh-fs, which is also fuse-based, an= d I=20 > guess there are also others who use it, and so the reach of this ABI-chan= ge,=20 > at least IMHO, is much larger than the original message makes you believe. >=20 > Now, after the update, a lot can go wrong, because the fuse KLM is loaded= by=20 > an init-script, and your system is most probably going to Oops while boot= ing=20 > if you didn't think of disabling the fuse init-script before you update y= our=20 > kernel, and will NOT fail "gracefully". If the respective person doesn't = know=20 > how he/she should boot to single-user-mode, update rc.conf to disable thi= s,=20 > reboot, rebuild the module to get the system back up, the only thing I ca= n=20 > possibly say is: "don't track stable." >=20 > It might've sounded a bit harsh what I wrote, but tracking -STABLE means= =20 > knowing your system enough so that you know how to fix things if they com= e=20 > back to bite you (especially after getting a HEADS UP). And that doesn't = seem=20 > to be the case here if the respective person asks for SPECIFIC instructio= ns=20 > what to do. >=20 > So, again: DON'T track -STABLE if you can't fix the system if it breaks, = and=20 > AFAICT this change is most certainly going to break quite a few systems. I do not use the fuse fs myself. But the issue was raised during the internal discussion of the MFC, and it seems that fuse could be not affected. The change only adds the field at the end of the vnode structure, so all existing fields offsets are intact. --Dx1O6sYEs5STvSrm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiQUNYACgkQC3+MBN1Mb4hJVgCgrOIoA44UuxdRneRX/MLiX7dB RBgAoL6NH0LCWyIRbmusyI7GLrnXg76p =WTkT -----END PGP SIGNATURE----- --Dx1O6sYEs5STvSrm-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 13:20:53 2008 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 B1E601065670 for ; Wed, 30 Jul 2008 13:20:53 +0000 (UTC) (envelope-from dm-lists@meisternet.ch) Received: from mercury.meisternet.ch (mercury.meisternet.ch [62.65.147.122]) by mx1.freebsd.org (Postfix) with ESMTP id 3DE3B8FC08 for ; Wed, 30 Jul 2008 13:20:53 +0000 (UTC) (envelope-from dm-lists@meisternet.ch) Received: by mercury.meisternet.ch (Postfix, from userid 1001) id 5ACC2B82B; Wed, 30 Jul 2008 15:20:32 +0200 (CEST) Date: Wed, 30 Jul 2008 15:20:32 +0200 From: Dominik Meister To: freebsd-stable@freebsd.org Message-ID: <20080730132032.GA21261@mercury.meisternet.ch> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: btxhalt2008@schottelius.org Subject: BTX halted on boot 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, 30 Jul 2008 13:20:53 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi We are experiencing a problem with one of our FreBSD 6.2 machines. The machine has been running fine for months until we had to reboot it. Now it doesn't boot anymore. After the boot loader we get what looks like a register dump: FreeBSD/i386 boot Default: 0:ad(0,a)heap boot: /boot/kernel/kernel\ int=3D0000000e err=3D00000002 efl=3D00010086 eip=3Dc042426a eax=3Dc06da7a8 ebx=3Dc06da7a0 ecx=3D00000000 edx=3Df000ff53 esi=3D00000000 edi=3Dc06da57f ebp=3Dc08f6d4c esp=3Dc08f6d40 cs=3D0008 ds=3D0010 es=3D0010 fs=3D0010 gs=3D0010 ss=3D0010 cs:eip=3D89 42 0c eb 07 90 8d 43-08 89 46 14 89 5e 10 8d 46 10 89 43 0c 8b 47 0c-89 43 10 85 c0 74 0b 8b ss:esp=3D7f a5 6d c0 00 00 8f 00-00 e0 8f 00 64 6d 8f c0 75 3b 42 c0 a0 a7 6d c0-7f a5 6d c0 20 a5 6d c0 BTX halted and the machine reboots. Any suggestions what might be the problem? All I can find about "BTX halted" references to problems when installing a fresh system and not out of a sudden on machine which has been running fine before. Any hints are highly appreciated. Thanks, Dominik --=20 Dominik Meister My public GnuPG key is available at http://www.meisternet.ch/gpg.txt --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiQaqAACgkQVD1CCgD/XK0fwACeP98QSiD0ZH6MSY1DIvOpRmyf D3MAnjyy7bYQMsHA0NIfWkvwflPojSoV =kMJ0 -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 13:29:22 2008 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 601471065677 for ; Wed, 30 Jul 2008 13:29:22 +0000 (UTC) (envelope-from david@vizion2000.net) Received: from dns1.vizion2000.net (77-99-36-42.cable.ubr04.chap.blueyonder.co.uk [77.99.36.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1B8858FC20 for ; Wed, 30 Jul 2008 13:29:22 +0000 (UTC) (envelope-from david@vizion2000.net) Received: by dns1.vizion2000.net (Postfix, from userid 1007) id 82F601CC21; Wed, 30 Jul 2008 06:51:57 -0700 (PDT) From: David Southwell Organization: Voice and Vision To: freebsd-stable@freebsd.org Date: Wed, 30 Jul 2008 06:51:57 -0700 User-Agent: KMail/1.9.7 References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807301326.33227.modelnine@modelnine.org> In-Reply-To: <200807301326.33227.modelnine@modelnine.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807300651.57320.david@vizion2000.net> Cc: Heiko Wundram Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 13:29:22 -0000 On Wednesday 30 July 2008 04:26:33 Heiko Wundram wrote: > Am Mittwoch, 30. Juli 2008 13:03:34 schrieb Ronald Klop: > > I think in this case (the ABI breakage) it is more nice to say: "If you > > don't know what to do, you wil probably not see any problem because of > > this." > > The edge case of what can go wrong is so small, that you must be doing > > quite specialized stuff to see breakage. In that case you would > > understand what is going on. (IMHO) > > Err, no. > > As someone else has already noted, a prominent KLM that's distributed > separately from the kernel which uses the vnode structure extensively > (which I didn't think of at all until I read the respective mail) is fuse. > A pre-upgrade compiled fuse is most certainly going to break because of > this change. Some people have dual installations of Windows/FreeBSD (at > least I'd presume that's the case with the fiddlers like me that track > -STABLE as a hobby, not as a developer, or those developers who program for > Windows as a day-job, also like me) who use ntfs-3g to mount their > NTFS-data; > additionally, I also extensively use ssh-fs, which is also fuse-based, and > I guess there are also others who use it, and so the reach of this > ABI-change, at least IMHO, is much larger than the original message makes > you believe. > > Now, after the update, a lot can go wrong, because the fuse KLM is loaded > by an init-script, and your system is most probably going to Oops while > booting if you didn't think of disabling the fuse init-script before you > update your kernel, and will NOT fail "gracefully". If the respective > person doesn't know how he/she should boot to single-user-mode, update > rc.conf to disable this, reboot, rebuild the module to get the system back > up, the only thing I can possibly say is: "don't track stable." > > It might've sounded a bit harsh what I wrote, but tracking -STABLE means > knowing your system enough so that you know how to fix things if they come > back to bite you (especially after getting a HEADS UP). And that doesn't > seem to be the case here if the respective person asks for SPECIFIC > instructions what to do. > > So, again: DON'T track -STABLE if you can't fix the system if it breaks, > and AFAICT this change is most certainly going to break quite a few > systems. Hey I want to thank those that have taken the trouble to explain stuff BUT I also feel the need to object to "If you cant then don't" kind of mentality. Everyone has to start somewhere!!! A contribution that sounds a bit like saying: "Well if you do not have the experience on tracking stable then do not bother to start" OR "If you do not understand my jargon why should it be explained" seems to me to invite a gentle reproof David From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 13:37:06 2008 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 B02F21065674 for ; Wed, 30 Jul 2008 13:37:06 +0000 (UTC) (envelope-from dm-lists@meisternet.ch) Received: from mercury.meisternet.ch (mercury.meisternet.ch [62.65.147.122]) by mx1.freebsd.org (Postfix) with ESMTP id 749D08FC23 for ; Wed, 30 Jul 2008 13:37:06 +0000 (UTC) (envelope-from dm-lists@meisternet.ch) Received: by mercury.meisternet.ch (Postfix, from userid 1001) id 73726B82B; Wed, 30 Jul 2008 15:36:47 +0200 (CEST) Date: Wed, 30 Jul 2008 15:36:47 +0200 From: Dominik Meister To: freebsd-stable@freebsd.org Message-ID: <20080730133647.GB21261@mercury.meisternet.ch> References: <20080730132032.GA21261@mercury.meisternet.ch> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline In-Reply-To: <20080730132032.GA21261@mercury.meisternet.ch> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: BTX halted on boot 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, 30 Jul 2008 13:37:06 -0000 --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dominik Meister [Wed, Jul 30, 2008 at 03:20:32PM +0200]: > Hi Sorry, wrong mailing list, will re-post it to freebsd-questions. Sorry, Dominik --=20 Dominik Meister My public GnuPG key is available at http://www.meisternet.ch/gpg.txt --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiQbm8ACgkQVD1CCgD/XK0IpwCfdkJZXe9GIMVP+ornOiaorfcj QEUAn3Zl2mJ/BmwPr1gcoab5ifqx1iyA =bneC -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 14:32:55 2008 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 15B511065675; Wed, 30 Jul 2008 14:32:55 +0000 (UTC) (envelope-from david@vizion2000.net) Received: from dns1.vizion2000.net (77-99-36-42.cable.ubr04.chap.blueyonder.co.uk [77.99.36.42]) by mx1.freebsd.org (Postfix) with ESMTP id CCB968FC14; Wed, 30 Jul 2008 14:32:54 +0000 (UTC) (envelope-from david@vizion2000.net) Received: by dns1.vizion2000.net (Postfix, from userid 1007) id 994BB1CC41; Wed, 30 Jul 2008 07:55:30 -0700 (PDT) From: David Southwell Organization: Voice and Vision To: Ian FREISLICH Date: Wed, 30 Jul 2008 07:55:29 -0700 User-Agent: KMail/1.9.7 References: <200807300247.34948.david@vizion2000.net> <1217346345.12322.31.camel@bauer.cse.buffalo.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807300755.30414.david@vizion2000.net> Cc: Ken Smith , freebsd-stable@freebsd.org, freebsd-current Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 14:32:55 -0000 On Wednesday 30 July 2008 07:27:27 Ian FREISLICH wrote: > David Southwell wrote: > > On Tuesday 29 July 2008 08:45:45 Ken Smith wrote: > > > Normally the FreeBSD Project tries very hard to avoid ABI breakage in > > > "Stable Branches". However occasionally the fix for a bug can not be > > > > Sometimes information gets posted to this list on the assumption that > > everyone understand what the writer means. > > > > This is one of those occasions!! > > > > For those of us who are not as well informed and experienced as others > > could someone please explain what is meant by an ABI breakage, its > > implications and how to deal with them. > > Within a major release, the project tries very hard to maintain > Binary Interface campatibility, or stability. In fact as far as I > know, this is where the name "Stable Branch" originates. > > What this means is that a binary compiled on 7.0-RELEASE should > continue to work without needing to be recompiled over the lifetime > of the 7 branch. > > ABI breakage that Ken refers to here means that a change required > to fix a bug cannot be made while maintaining binary compatibility > with previous versions. Any program that makes use of (I'm guessing) > fcntl(2) or flock(2) that runs on 7.0, will not run on >= 7.1 without > being recompiled. > > Ian > > -- > Ian Freislich Thanks that is very concise and very helpful. Question is what is the best way to determine which programs (if any) depend upon fcntl or flock on a running system? David From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 14:47:22 2008 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 870461065673; Wed, 30 Jul 2008 14:47:22 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 536A78FC12; Wed, 30 Jul 2008 14:47:22 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:cc:From:Subject:In-Reply-To:References:X-Attribution:Date:Message-Id; b=Q4zyojR6om3QvD7IsDxJA2L30zJomSwQ/GlhUjbKYsEU2QmzN01VFLlOrVx/wCZ8cujONGhRKp0CSSm/dypvvwl5bmd8vOV1y5KBpTQnA5FkNnc3+9Awte40Ud2pdrhfh2Hrcx5r1SrpeyM+0ld0Mz1XDAuaP9Hz6V27pKznosbXv/MxhCd0xT3PWDC/SgqSMWFfT6gWJ6XIclTFi406nJyCx3XL6WpSCOuQFyKNBrIJHJe2fboXIpAku1HYY2fc; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.67) (envelope-from ) id 1KOCev-0001pQ-6H; Wed, 30 Jul 2008 14:28:09 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KOCeJ-0000Dn-7D; Wed, 30 Jul 2008 14:27:31 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOCeF-0001Bi-Oo; Wed, 30 Jul 2008 16:27:27 +0200 To: David Southwell From: Ian FREISLICH In-Reply-To: <200807300247.34948.david@vizion2000.net> References: <200807300247.34948.david@vizion2000.net> <1217346345.12322.31.camel@bauer.cse.buffalo.edu> X-Attribution: BOFH Date: Wed, 30 Jul 2008 16:27:27 +0200 Message-Id: Cc: Ken Smith , freebsd-stable@freebsd.org, freebsd-current Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 14:47:22 -0000 David Southwell wrote: > On Tuesday 29 July 2008 08:45:45 Ken Smith wrote: > > Normally the FreeBSD Project tries very hard to avoid ABI breakage in > > "Stable Branches". However occasionally the fix for a bug can not be > > Sometimes information gets posted to this list on the assumption that > everyone understand what the writer means. > > This is one of those occasions!! > > For those of us who are not as well informed and experienced as others > could someone please explain what is meant by an ABI breakage, its > implications and how to deal with them. Within a major release, the project tries very hard to maintain Binary Interface campatibility, or stability. In fact as far as I know, this is where the name "Stable Branch" originates. What this means is that a binary compiled on 7.0-RELEASE should continue to work without needing to be recompiled over the lifetime of the 7 branch. ABI breakage that Ken refers to here means that a change required to fix a bug cannot be made while maintaining binary compatibility with previous versions. Any program that makes use of (I'm guessing) fcntl(2) or flock(2) that runs on 7.0, will not run on >= 7.1 without being recompiled. Ian -- Ian Freislich From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 14:55:05 2008 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 A26E41065671; Wed, 30 Jul 2008 14:55:05 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 7952A8FC08; Wed, 30 Jul 2008 14:55:05 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id m6UEstZi019923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 10:54:55 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: David Southwell In-Reply-To: <200807300755.30414.david@vizion2000.net> References: <200807300247.34948.david@vizion2000.net> <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807300755.30414.david@vizion2000.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7QjMtSdC065sW1EWh7sj" Organization: U. Buffalo CSE Department Date: Wed, 30 Jul 2008 10:54:55 -0400 Message-Id: <1217429695.63703.36.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Cc: Ian FREISLICH , freebsd-stable@freebsd.org, freebsd-current Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 14:55:05 -0000 --=-7QjMtSdC065sW1EWh7sj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-07-30 at 07:55 -0700, David Southwell wrote: > On Wednesday 30 July 2008 07:27:27 Ian FREISLICH wrote: > > David Southwell wrote: > > > On Tuesday 29 July 2008 08:45:45 Ken Smith wrote: > > > > Normally the FreeBSD Project tries very hard to avoid ABI breakage = in > > > > "Stable Branches". However occasionally the fix for a bug can not = be > > > > > > Sometimes information gets posted to this list on the assumption that > > > everyone understand what the writer means. > > > > > > This is one of those occasions!! > > > > > > For those of us who are not as well informed and experienced as other= s > > > could someone please explain what is meant by an ABI breakage, its > > > implications and how to deal with them. > > > > Within a major release, the project tries very hard to maintain > > Binary Interface campatibility, or stability. In fact as far as I > > know, this is where the name "Stable Branch" originates. > > > > What this means is that a binary compiled on 7.0-RELEASE should > > continue to work without needing to be recompiled over the lifetime > > of the 7 branch. > > > > ABI breakage that Ken refers to here means that a change required > > to fix a bug cannot be made while maintaining binary compatibility > > with previous versions. Any program that makes use of (I'm guessing) > > fcntl(2) or flock(2) that runs on 7.0, will not run on >=3D 7.1 without > > being recompiled. > > Actually not quite, and that's why Konstantin mentioned I made a slight mistake in my original announcement. ABI stands for *Application* Binary Interface but (sorry) that's not quite what is being broken here. It is a KBI (Kernel Binary Interface) that's being broken. The difference is that the data structures being changed are strictly internal to the kernel. Back in the days of "strictly monolithic kernels" when the only way to get something into the kernel was to rebuild the whole kernel and reboot with it this sort of thing was less of a concern. But now that "kernel modules" can be loaded while the machine is up and running we need to be a bit more careful about announcing when a very important kernel data structure gets modified in such a way that already-compiled modules might not be compatible because of, as someone else mentioned, that very important data structure changing in size or the elements inside that structure changing position. So because this is a KBI being broken it should NOT have any impact on user-level executable files. It should only impact loadable kernel modules that deal with filesystems. IF this change did indeed change user-level programs to the degree mentioned above that would "raise the bar" *dramatically* on whether we would consider the fix worth the fall-out that would occur. Frankly I think we would have rejected the fix if it were that drastic. > Thanks that is very concise and very helpful. >=20 > Question is what is the best way to determine which programs (if any) dep= end=20 > upon fcntl or flock on a running system? No need to. :-) But one way to do it if you ever needed to is with nm(1), something like: nm file | grep fcntl though that would only tell you if that executable directly calls fcntl(2) itself (functions inside libraries may wind up calling fcntl(2) so if you really needed to be thorough you would need to also check the libraries the executable is linked against, ldd(1) can help you figure out what those are). There are likely better/easier ways to do it. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-7QjMtSdC065sW1EWh7sj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkiQgLYACgkQ/G14VSmup/ZuiwCgl6dF2x008XX0DA+m6VWaPXvt 20wAoI3rlPXyoI6Ayrjssypg22HvYngg =Li67 -----END PGP SIGNATURE----- --=-7QjMtSdC065sW1EWh7sj-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 14:57:23 2008 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 459AB1065676; Wed, 30 Jul 2008 14:57:23 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 112378FC0A; Wed, 30 Jul 2008 14:57:23 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:cc:From:Subject:In-Reply-To:References:X-Attribution:Date:Message-Id; b=bLE5zqLkik5sp6lmMunSdh2DqiGRDVRG4lXL9BxMYA7a68X0xvQAAo11oGJzR8Efv8B3D6m/4w6a/56rcWHpc5b0XH9gTBDX1n8SxMIxo2EHngf9THF9X751HhZloOse8ZTDHk0qAeEsqJ+/aUG22VRaQDBKAkBoMUKy4yTkfRZZ3UbWyQZ71mZAkWYq0Fa3awt1K/zgrBmd+eULgrN/heVQ4UHkjlmoWHCxOVDjk7po3sZ+wtcJWdZC+brYU7H+; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.67) (envelope-from ) id 1KOD7C-0004Py-La; Wed, 30 Jul 2008 14:57:22 +0000 Received: from ianf.clue.co.za ([10.0.0.6] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1KOD6X-0000Tf-E3; Wed, 30 Jul 2008 14:56:41 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KOD6S-0001FE-Qr; Wed, 30 Jul 2008 16:56:36 +0200 To: David Southwell From: Ian FREISLICH In-Reply-To: <200807300755.30414.david@vizion2000.net> References: <200807300755.30414.david@vizion2000.net> <200807300247.34948.david@vizion2000.net> <1217346345.12322.31.camel@bauer.cse.buffalo.edu> X-Attribution: BOFH Date: Wed, 30 Jul 2008 16:56:36 +0200 Message-Id: Cc: Ken Smith , freebsd-stable@freebsd.org, freebsd-current Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 14:57:23 -0000 David Southwell wrote: > On Wednesday 30 July 2008 07:27:27 Ian FREISLICH wrote: > > ABI breakage that Ken refers to here means that a change required > > to fix a bug cannot be made while maintaining binary compatibility > > with previous versions. Any program that makes use of (I'm guessing) > > fcntl(2) or flock(2) that runs on 7.0, will not run on >= 7.1 without > > being recompiled. > > Thanks that is very concise and very helpful. > > Question is what is the best way to determine which programs (if any) depend > upon fcntl or flock on a running system? That will be just about anything that opens and locks files. RDBMS, editors, browsers, MTAs spring to mind. This of course depends on my initial guess being correct. Ian -- Ian Freislich From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 15:10:28 2008 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 7A6B01065676; Wed, 30 Jul 2008 15:10:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 456F08FC18; Wed, 30 Jul 2008 15:10:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 7317A1CD38; Wed, 30 Jul 2008 17:10:27 +0200 (CEST) Date: Wed, 30 Jul 2008 17:10:27 +0200 From: Ed Schouten To: Ian FREISLICH Message-ID: <20080730151027.GJ99951@hoeg.nl> References: <200807300247.34948.david@vizion2000.net> <1217346345.12322.31.camel@bauer.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLfjTIIQuAzj8yil" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, Ken Smith , David Southwell , FreeBSD Current Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 15:10:28 -0000 --SLfjTIIQuAzj8yil Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ian FREISLICH wrote: > ABI breakage that Ken refers to here means that a change required > to fix a bug cannot be made while maintaining binary compatibility > with previous versions. Any program that makes use of (I'm guessing) > fcntl(2) or flock(2) that runs on 7.0, will not run on >=3D 7.1 without > being recompiled. Are you sure? I fcntl(2) and flock(2) will not change. Only some kernel space bits will. --=20 Ed Schouten WWW: http://80386.nl/ --SLfjTIIQuAzj8yil Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiQhGMACgkQ52SDGA2eCwUseACfeB7aWH1wrZwwjX7nccmZKXPs luMAnA5Ur8bMUyi6JsNFF3sGVwp9oLQi =Fyuq -----END PGP SIGNATURE----- --SLfjTIIQuAzj8yil-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 18:33:54 2008 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 B70EF1065698 for ; Wed, 30 Jul 2008 18:33:54 +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 54B728FC1A for ; Wed, 30 Jul 2008 18:33:54 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 18821 invoked by uid 399); 30 Jul 2008 18:33:53 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 30 Jul 2008 18:33:53 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4890B40F.50200@FreeBSD.org> Date: Wed, 30 Jul 2008 11:33:51 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: Dominik Meister References: <20080730132032.GA21261@mercury.meisternet.ch> In-Reply-To: <20080730132032.GA21261@mercury.meisternet.ch> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: btxhalt2008@schottelius.org, freebsd-stable@freebsd.org Subject: Re: BTX halted on boot 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, 30 Jul 2008 18:33:54 -0000 Dominik Meister wrote: > Hi > > We are experiencing a problem with one of our FreBSD 6.2 machines. The > machine has been running fine for months until we had to reboot it. Now > it doesn't boot anymore. After the boot loader we get what looks like a > register dump: Assuming you simply rebooted the machine and did no other changes, this is likely to be disk corruption (probably due to age). If the symptoms persist, try taking this opportunity to install 6.3 (you have backups of all the data and configurations, right?) and see if that helps. If not, your disk is toast. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 18:45:36 2008 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 0AFEA106567D for ; Wed, 30 Jul 2008 18:45:36 +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 B4CB78FC12 for ; Wed, 30 Jul 2008 18:45:35 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 9526 invoked by uid 399); 30 Jul 2008 18:45:35 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 30 Jul 2008 18:45:35 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4890B6CD.5090304@FreeBSD.org> Date: Wed, 30 Jul 2008 11:45:33 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: David Southwell References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807300247.34948.david@vizion2000.net> <200807301211.54974.modelnine@modelnine.org> <200807300411.31557.david@vizion2000.net> In-Reply-To: <200807300411.31557.david@vizion2000.net> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Heiko Wundram , freebsd-stable@freebsd.org Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 18:45:36 -0000 David Southwell wrote: > It sure helps the understanding bit but how about specific instructions about > who is to what to do in this instance? I fear that the forest is getting lost for the trees here. :) Under most (90% or more) circumstances "stuff," be that kernel modules or userland binaries, that is on a -stable system will still work in its current form after you do an upgrade. In the event of an actual ABI breakage you would be informed of when and where to tune for additional .... wait, wrong PSA. If this had actually been an ABI breakage then any userland binaries that depend on the thing that changed would have to be recompiled after the update in order to continue working. Since this is actually a KERNEL interface that's changing, any kernel modules that use this interface (which is quite a lot) will have to be recompiled _as part of the update_ for them to work. If you are not using any 3rd party kernel modules (commercial, ports tree, etc.) then you have nothing to worry about. Your FreeBSD kernel modules will be updated along with the kernel, and everyone is happy. If you are using a 3rd party module from ports that deals with file systems (and yes, FUSE is an obvious example here) then you'll need to pkg_delete it, do the update, then recompile. Q.E.D. If you happen to be using a commercial (i.e., you don't have the source) kernel module that deals with file systems now is the time to contact your vendor and let them know about this issue. However, as Ken rightly pointed out this change will actually impact a very small percentage of FreeBSD users, and the majority of that impact will be recompiling a port as described above. I should also point out that FreeBSD developers deal with this issue all the time on -current since things there are allowed to change, and sometimes do change quite often. Therefore it's easy for us to forget to list important details about a change like this since it's second nature to us. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 18:52:32 2008 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 BB86B106567E for ; Wed, 30 Jul 2008 18:52:32 +0000 (UTC) (envelope-from dm-lists@meisternet.ch) Received: from mercury.meisternet.ch (mercury.meisternet.ch [62.65.147.122]) by mx1.freebsd.org (Postfix) with ESMTP id 772C58FC19 for ; Wed, 30 Jul 2008 18:52:32 +0000 (UTC) (envelope-from dm-lists@meisternet.ch) Received: by mercury.meisternet.ch (Postfix, from userid 1001) id 5E55EB82B; Wed, 30 Jul 2008 20:52:12 +0200 (CEST) Date: Wed, 30 Jul 2008 20:52:12 +0200 From: Dominik Meister To: freebsd-stable@freebsd.org Message-ID: <20080730185212.GC88942@mercury.meisternet.ch> References: <20080730132032.GA21261@mercury.meisternet.ch> <4890B40F.50200@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="19uQFt6ulqmgNgg1" Content-Disposition: inline In-Reply-To: <4890B40F.50200@FreeBSD.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: nico-freebsd-btxhalt2008@schottelius.org Subject: Re: BTX halted on boot 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, 30 Jul 2008 18:52:32 -0000 --19uQFt6ulqmgNgg1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Doug Thanks a lot for your answer. Doug Barton [Wed, Jul 30, 2008 at 11:33:51AM -0700]: > Assuming you simply rebooted the machine and did no other changes,=20 > this is likely to be disk corruption (probably due to age). If the=20 > symptoms persist, try taking this opportunity to install 6.3 (you have=20 > backups of all the data and configurations, right?) and see if that=20 > helps. If not, your disk is toast. Seems like it's really a hardware problem. We are currently restoring to another machine/disk and hopefully this will do the trick. Unfortunately we are not yet able to move to 6.3 (or even 7.0) because of a third party application which runs on this server and which does only support 6.2 atm. Thanks, Dominik --=20 Dominik Meister My public GnuPG key is available at http://www.meisternet.ch/gpg.txt --19uQFt6ulqmgNgg1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiQuFwACgkQVD1CCgD/XK3xlgCfbbklJD3IARI5sbvOYtKRwju3 sckAnioVYV2IiE1LxgoIlapmnCS+qsyf =UvbD -----END PGP SIGNATURE----- --19uQFt6ulqmgNgg1-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 19:05:42 2008 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 746A2106566B for ; Wed, 30 Jul 2008 19:05:42 +0000 (UTC) (envelope-from modelnine@modelnine.org) Received: from jord.modelnine.org (jord.modelnine.org [83.246.72.120]) by mx1.freebsd.org (Postfix) with ESMTP id 3910A8FC17 for ; Wed, 30 Jul 2008 19:05:41 +0000 (UTC) (envelope-from modelnine@modelnine.org) Received: from phoenix (port-92-196-44-243.dynamic.qsc.de [92.196.44.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: modelnine) by jord.modelnine.org (Postfix) with ESMTPSA id A0EB6A40CC0; Wed, 30 Jul 2008 21:05:40 +0200 (CEST) From: Heiko Wundram To: Kostik Belousov Date: Wed, 30 Jul 2008 21:09:38 +0200 User-Agent: KMail/1.9.7 References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807301326.33227.modelnine@modelnine.org> <20080730113031.GS97161@deviant.kiev.zoral.com.ua> In-Reply-To: <20080730113031.GS97161@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807302109.39405.modelnine@modelnine.org> Cc: freebsd-stable@freebsd.org Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 30 Jul 2008 19:05:42 -0000 Am Mittwoch, 30. Juli 2008 13:30:31 schrieben Sie: > I do not use the fuse fs myself. But the issue was raised during the > internal discussion of the MFC, and it seems that fuse could be not > affected. > > The change only adds the field at the end of the vnode structure, so all > existing fields offsets are intact. I just half-throughly waded through the sysutils/fusefs-kmod sources, and you're right; there's no mentioning of sizeof(struct vnode) in all of the preprocessed sources (at least none that I could find, directly or indirectly). So, if struct vnode only grows and none of the original fields are moved due to padding issues (or gcc reordering fields because of padding), the old kernel module should work unchanged. To finish: sorry for the noise, and sorry for the panic I might've provoked. -- Heiko Wundram From owner-freebsd-stable@FreeBSD.ORG Thu Jul 31 05:55:20 2008 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 4EC31106564A for ; Thu, 31 Jul 2008 05:55:20 +0000 (UTC) (envelope-from jeff.dowsley@mac.com) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by mx1.freebsd.org (Postfix) with ESMTP id 3FE728FC13 for ; Thu, 31 Jul 2008 05:55:20 +0000 (UTC) (envelope-from jeff.dowsley@mac.com) MIME-version: 1.0 Received: from [192.168.1.101] (87.64.99.122.cable.dyn.bal.ncable.com.au [122.99.64.87]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K4U00MCOTO56X60@asmtp011.mac.com> for freebsd-stable@freebsd.org; Wed, 30 Jul 2008 21:55:19 -0700 (PDT) Sender: jeff.dowsley@mac.com To: freebsd-stable@freebsd.org Message-id: From: Jeff Dowsley Date: Thu, 31 Jul 2008 14:55:15 +1000 X-Mailer: Apple Mail (2.753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: buildworld failure 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, 31 Jul 2008 05:55:20 -0000 Greetings Installed 7 RC2 some time ago, and just tried a cvsup to 7_STABLE. Buildworld fails with mkmagic: Printf format, after hundreds of warnings - magic, 6xxxx: Warning offset invalid. I searched the archive, and see that someone else had this problem when upgrading to 6.3, but the answer wasn't in the archive. (Built the 7.0 STABLE kernel and installed without any problems.) Any clues? TIA JeffD _____________________________ M 0427565791 jeff.dowsley@mac.com From owner-freebsd-stable@FreeBSD.ORG Thu Jul 31 07:46:38 2008 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 EC54B1065673; Thu, 31 Jul 2008 07:46:37 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id 40F978FC18; Thu, 31 Jul 2008 07:46:36 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from [10.20.1.5] (unknown [10.0.0.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by netasq.netasq.com (Postfix) with ESMTP id 0C6301E973; Thu, 31 Jul 2008 09:15:30 +0200 (CEST) Message-Id: <02AE4AED-5A25-4781-B710-4512DBEBF176@netasq.com> From: Fabien Thomas To: FreeBSD Stable List , FreeBSD Hackers In-Reply-To: <84dead720807122205i33bf6eb0p998d473df9e52304@mail.gmail.com> Content-Type: multipart/signed; boundary=Apple-Mail-4-737520214; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v926) Date: Wed, 30 Jul 2008 12:56:44 +0200 References: <84dead720807122205i33bf6eb0p998d473df9e52304@mail.gmail.com> X-Mailer: Apple Mail (2.926) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Joseph Koshy Subject: Re: Announcement: PmcTools callchain capture for RELENG_7 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, 31 Jul 2008 07:46:38 -0000 --Apple-Mail-4-737520214 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable For those like me that need FreeBSD 6.3 support i can provide a =20 patchset upon request (That have only been tested on system wide =20 profiling). Fabien Le 13 juil. 08 =E0 07:05, Joseph Koshy a =E9crit : > Hello List(s), > > I am very pleased to announce a patch, by Fabien Thomas, that brings > PmcTools' callchain capture features to 7-STABLE. Thank you, Fabien! > > The patch is linked to from the PmcTools wiki page: > http://wiki.freebsd.org/PmcTools. > > The current file name is: "patch-callchain-FreeBSD-7-=20 > STABLE-2008-07-12.gz". > As the file name indicates, it should apply against a 7-STABLE tree of > 2008-07-12 > vintage. > > To apply the patch: > % cd /home/src-7x # or whereever your RELENG_7 tree resides > % patch < PATCH-FILE > > Then you should follow the full procedure to update userland > and kernel from source as spelled out in src/UPDATING. > > Please note that HWPMC(4) log files that contain callchain =20 > information are > not binary compatible with prior versions of pmc(3) and pmcstat(8). > > Please do test on your systems and let Fabien and me know > how you fared. > > Koshy > --Apple-Mail-4-737520214-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 31 19:53:03 2008 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 533CD106568A for ; Thu, 31 Jul 2008 19:53:03 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 8F72C8FC18 for ; Thu, 31 Jul 2008 19:53:02 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: (qmail 88835 invoked from network); 31 Jul 2008 19:53:00 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 31 Jul 2008 19:53:00 -0000 Date: Thu, 31 Jul 2008 21:53:00 +0200 (CEST) Message-Id: <20080731.215300.74706878.sthaug@nethelp.no> To: freebsd-stable@freebsd.org From: sthaug@nethelp.no In-Reply-To: <20080722.200709.74704291.sthaug@nethelp.no> References: <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <20080722.200709.74704291.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 7.1 and BIND exploit 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, 31 Jul 2008 19:53:03 -0000 I wrote in an earlier message: > I've been trying out unbound-1.0.1 on a 7.0-STABLE box (2.67 GHz i86, > uniprocessor, 32 bit mode, 2 GB memory). > > Don't know what I'm doing wrong so far - but I've been unable to scale > Unbound to more than a couple of hundred q/s. Any more than that and > I get serious (several hundred ms) delays on lots of queries, including > stuff which is known to be in the cache. > > I'll be doing some more Unbound tests the next few days. For now, both > CNS and PowerDNS handle our load (around 2.5K q/s) fine. As a followup: I'm now happily running Unbound (together with Nominum CNS) in our standard anycast configuration. I've gotten Unbound to handle our regular query load of 2000 - 2500 q/s just fine. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Thu Jul 31 20:01:39 2008 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 C25AC106564A for ; Thu, 31 Jul 2008 20:01:39 +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 58C568FC13 for ; Thu, 31 Jul 2008 20:01:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 31948 invoked by uid 399); 31 Jul 2008 20:01:38 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 31 Jul 2008 20:01:38 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <48921A21.5040401@FreeBSD.org> Date: Thu, 31 Jul 2008 13:01:37 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: sthaug@nethelp.no References: <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <20080722.200709.74704291.sthaug@nethelp.no> <20080731.215300.74706878.sthaug@nethelp.no> In-Reply-To: <20080731.215300.74706878.sthaug@nethelp.no> X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Unbound success (was: Re: FreeBSD 7.1 and BIND exploit) 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, 31 Jul 2008 20:01:39 -0000 sthaug@nethelp.no wrote: > As a followup: I'm now happily running Unbound (together with Nominum > CNS) in our standard anycast configuration. I've gotten Unbound to > handle our regular query load of 2000 - 2500 q/s just fine. Don't leave us all in suspense, what did you have to twiddle? :) Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Thu Jul 31 21:03:15 2008 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 626F61065672 for ; Thu, 31 Jul 2008 21:03:15 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 9CC918FC2E for ; Thu, 31 Jul 2008 21:03:14 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: (qmail 97874 invoked from network); 31 Jul 2008 21:03:12 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 31 Jul 2008 21:03:12 -0000 Date: Thu, 31 Jul 2008 23:03:12 +0200 (CEST) Message-Id: <20080731.230312.41678234.sthaug@nethelp.no> To: dougb@FreeBSD.org From: sthaug@nethelp.no In-Reply-To: <48921A21.5040401@FreeBSD.org> References: <20080722.200709.74704291.sthaug@nethelp.no> <20080731.215300.74706878.sthaug@nethelp.no> <48921A21.5040401@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Unbound success 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, 31 Jul 2008 21:03:15 -0000 > > As a followup: I'm now happily running Unbound (together with Nominum > > CNS) in our standard anycast configuration. I've gotten Unbound to > > handle our regular query load of 2000 - 2500 q/s just fine. > > Don't leave us all in suspense, what did you have to twiddle? :) Need to check some more details here (because I changed considerably more than one parameter). Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Thu Jul 31 22:02:30 2008 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 6D2491065671 for ; Thu, 31 Jul 2008 22:02:30 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id A3F428FC15 for ; Thu, 31 Jul 2008 22:02:29 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 11322 invoked by uid 89); 31 Jul 2008 21:11:23 -0000 Received: from unknown (HELO ?192.168.0.16?) (danallen46@airwired.net@66.29.174.6) by 0 with ESMTPA; 31 Jul 2008 21:11:23 -0000 Message-Id: <0D693A13-8A3A-4ECD-A994-6EB6C61ACE16@airwired.net> From: Dan Allen To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 31 Jul 2008 15:35:45 -0600 X-Mailer: Apple Mail (2.926) Subject: no toe capability message 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, 31 Jul 2008 22:02:30 -0000 On July 29th a change was made to /usr/src/sys/netinet/tcp_offload.c, the rlog info being that code has been added but not turned on yet. Well, I keep getting printed to the system console a string of messages saying "no toe capability on 0x12348348". It appears that line 74 of tcp_offload.c has a printf statement which probably is debug code and should be repressed, commented out, or whatever, for RELENG_7. Dan From owner-freebsd-stable@FreeBSD.ORG Thu Jul 31 23:48:59 2008 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 958E61065677 for ; Thu, 31 Jul 2008 23:48:59 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by mx1.freebsd.org (Postfix) with ESMTP id DB3028FC0C for ; Thu, 31 Jul 2008 23:48:58 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so970970fkk.11 for ; Thu, 31 Jul 2008 16:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=/ARyEAEKBEAEF3laS/KSTy4qN7ihXhE7V1o7znWgHP0=; b=AM/rVVEiZEBPVVuuXjNauQ93s7q8i8vQejrnALgmYHm/yVN4Wk6D9xRWGAjkhESDRA 7JtsfVsr4ym9GxGQRxA9HfQCp0B0IvSiqSmdYZEqiZcoZHzizSfqUBNZFcbqdQ3ym1bx oYNiawNIhdg3kl+JrzsrX4nUd34/USbG7/P1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rPyYKl4JJm0b29lTK2awYewPnbrLtI3wZB9RXWRQYLJvncurdjTb3Rhz3ezIv6EiEj SY26ZHJQtYe4MNwZ0quR1KoyhgveZBOFr/HVSlcRnyJEd2pOgyKo00zhQv5fdGgLNCSW /vBoD6DmkzLPyUUXvRtO7onq4kkVZQesUAgaY= Received: by 10.125.100.8 with SMTP id c8mr523045mkm.144.1217546427092; Thu, 31 Jul 2008 16:20:27 -0700 (PDT) Received: by 10.125.139.12 with HTTP; Thu, 31 Jul 2008 16:20:27 -0700 (PDT) Message-ID: <3c1674c90807311620g766a32d8y8589f98fafa181bf@mail.gmail.com> Date: Thu, 31 Jul 2008 16:20:27 -0700 From: "Matthew Macy" To: "Dan Allen" In-Reply-To: <0D693A13-8A3A-4ECD-A994-6EB6C61ACE16@airwired.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0D693A13-8A3A-4ECD-A994-6EB6C61ACE16@airwired.net> Cc: freebsd-stable@freebsd.org Subject: Re: no toe capability message 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, 31 Jul 2008 23:48:59 -0000 It was fixed by a subsequent MFC. -Kip On Thu, Jul 31, 2008 at 2:35 PM, Dan Allen wrote: > On July 29th a change was made to /usr/src/sys/netinet/tcp_offload.c, the > rlog info being that code has been added but not turned on yet. > > Well, I keep getting printed to the system console a string of messages > saying "no toe capability on 0x12348348". It appears that line 74 of > tcp_offload.c has a printf statement which probably is debug code and should > be repressed, commented out, or whatever, for RELENG_7. > > Dan > > > > _______________________________________________ > 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 Thu Jul 31 23:53:13 2008 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 332A8106566B for ; Thu, 31 Jul 2008 23:53:13 +0000 (UTC) (envelope-from flo@kasimir.com) Received: from mail.solomo.de (mail.solomo.de [85.214.49.72]) by mx1.freebsd.org (Postfix) with ESMTP id E2C658FC0C for ; Thu, 31 Jul 2008 23:53:12 +0000 (UTC) (envelope-from flo@kasimir.com) Received: from localhost (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 427303F5B1; Fri, 1 Aug 2008 01:37:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by localhost (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tT2E4Gy-lZ7W; Fri, 1 Aug 2008 01:37:55 +0200 (CEST) Received: from nibbler-osx.local (pd95b71ae.dip0.t-ipconnect.de [217.91.113.174]) by mail.solomo.de (Postfix) with ESMTPA id 382553F433; Fri, 1 Aug 2008 01:37:55 +0200 (CEST) Message-ID: <48924CD2.2000604@kasimir.com> Date: Fri, 01 Aug 2008 01:37:54 +0200 From: Florian Smeets User-Agent: Thunderbird/3.0b1pre (Macintosh; 2008073100) MIME-Version: 1.0 To: Dan Allen References: <0D693A13-8A3A-4ECD-A994-6EB6C61ACE16@airwired.net> In-Reply-To: <0D693A13-8A3A-4ECD-A994-6EB6C61ACE16@airwired.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: no toe capability message 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, 31 Jul 2008 23:53:13 -0000 Dan Allen wrote: > On July 29th a change was made to /usr/src/sys/netinet/tcp_offload.c, > the rlog info being that code has been added but not turned on yet. > This has been fixed in the meantime. Try csuping again. It should work then. Cheers, Florian From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 01:40:01 2008 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 994F31065674 for ; Fri, 1 Aug 2008 01:40:01 +0000 (UTC) (envelope-from ebutusov@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 2B5838FC14 for ; Fri, 1 Aug 2008 01:40:00 +0000 (UTC) (envelope-from ebutusov@gmail.com) Received: by ug-out-1314.google.com with SMTP id q2so492298uge.37 for ; Thu, 31 Jul 2008 18:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=5Jwn179lMietLchGzkFnFIx2tvQnvZFkwCTS//cuBns=; b=KShmjv9613yPsp/v6OCdpk88X8PDBzNY01Hx8yystKOuangi+3PZJ/3Ts9+LNuKVS6 gIcYuPONbTYwRDDIBbJKtzFQUBcTsyVDyeQaYhk1iUuH3meEkJg+GoqhxnVM746DR/6F JJGPz866F2XiGsYL9Ri0cKd43DhMApP9QS9c8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=AqbaSmfcBqHgY1PM7Zp9kEumZgHA2x2Jyij6bYNKyAV8+kTHzEA56BCk8q2k540zLh LiqRu4eT+6Q68mwDnnU1jEjOH5HHqRp7a2DSTkQ5GIMRFCgyDC3r0CxjLxeI6/fik51A hDcY4o8VYc17Dwc+T4p5v/65F5cP0o9fIvLlU= Received: by 10.66.245.10 with SMTP id s10mr744524ugh.30.1217553166238; Thu, 31 Jul 2008 18:12:46 -0700 (PDT) Received: from ?192.168.0.51? ( [195.136.67.137]) by mx.google.com with ESMTPS id s7sm12888452uge.26.2008.07.31.18.12.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 31 Jul 2008 18:12:45 -0700 (PDT) Message-ID: <489262E5.3010304@gmail.com> Date: Fri, 01 Aug 2008 03:12:05 +0200 From: Eugene Butusov User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: FreeBSD-STABLE-LIST Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: Realtek RTL8110 (SB) watchdog timeout. 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, 01 Aug 2008 01:40:01 -0000 Hi, After updating from 7.0-RELEASE to STABLE (around 15/08) my NIC refuses to handle large file transfers. pciconf -lv re0@pci0:4:0:0: class=0x020000 card=0x001a6409 chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8110SB Single-Chip Gigabit LOM Ethernet Controller' class = network subclass = ethernet Log messages: re: watchdog timeout re: link changed to DOWN re: link changed to UP When someone tried to copy large (i.e. 700MB) file from samba share (local gigabit network) or ftp (same LAN), the NIC was reseted. For a while host was not accesible from the network, and then it came back with log messages shown above. I've tried to tune samba socket options (SO_RCVBUF=16384 SO_SNDBUF=16384), and this fixed the problem for samba users. One interesting thing: copying file to windows XP machine worked fine, while Vista (SP1 x64) caused the problem. What solved the problem definitely was disabling TSO for re0 (ifconfig re0 -tso). I haven't notice any performance drop and it works fine, but I'm just curious what happened to the 'good' driver from 7.0-RELEASE. Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 08:09:34 2008 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 54DF21065682 for ; Fri, 1 Aug 2008 08:09:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id 1E6298FC1B for ; Fri, 1 Aug 2008 08:09:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1278449rvf.43 for ; Fri, 01 Aug 2008 01:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=yF7FRWbu3C3B6v7P7iYUG20kvy6uHyNjaA8Ag/FwgLs=; b=c1r09h5B2yz+Mpi2B587WO1kI+5eu0TRoaD0UR+qMgIYeR2gwT+0TydUgEO72vbwu2 hXhIcNjoSGqBG/bTaRTnrCnhT6C/nJItHyH2evBs5Yx8eCcTW1ZrhwRmVl03EzHvR0v7 plRRE4nuVPW+lu4XgQH36F8K47ERpkmZV57wM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=GmBJz9fVrIwolhjF8tdQq5JdVfwOUvmq0aoN11qQdULi2up6Ri7DXcbvmvBxGq4W1Q 8kNtQOrpdKlKyOL6JkdAM+BpWYNs5Qmu4tkOP7mdevr6B94vBaqEq34716Ria7LulMnu 9ERPIHJ50dWkrH5AI616gUX2Wbe+1hNWLe1O0= Received: by 10.141.49.6 with SMTP id b6mr5798086rvk.89.1217578173785; Fri, 01 Aug 2008 01:09:33 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id k2sm1249193rvb.4.2008.08.01.01.09.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 01 Aug 2008 01:09:32 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m7187MOw010579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2008 17:07:22 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m7187LtN010578; Fri, 1 Aug 2008 17:07:21 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 1 Aug 2008 17:07:21 +0900 From: Pyun YongHyeon To: Eugene Butusov Message-ID: <20080801080721.GB9206@cdnetworks.co.kr> References: <489262E5.3010304@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <489262E5.3010304@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD-STABLE-LIST Subject: Re: Realtek RTL8110 (SB) watchdog timeout. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 08:09:34 -0000 On Fri, Aug 01, 2008 at 03:12:05AM +0200, Eugene Butusov wrote: > Hi, > > After updating from 7.0-RELEASE to STABLE (around 15/08) my NIC > refuses to handle large file transfers. > > pciconf -lv > > re0@pci0:4:0:0: class=0x020000 card=0x001a6409 chip=0x816910ec > rev=0x10 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8110SB Single-Chip Gigabit LOM Ethernet Controller' > class = network > subclass = ethernet > > Log messages: > > re: watchdog timeout > re: link changed to DOWN > re: link changed to UP > > When someone tried to copy large (i.e. 700MB) file from samba share > (local gigabit network) or ftp (same LAN), > the NIC was reseted. For a while host was not accesible from the > network, and then it came back with log messages shown above. > I've tried to tune samba socket options (SO_RCVBUF=16384 > SO_SNDBUF=16384), and this fixed the problem for samba users. One > interesting thing: copying file to windows XP machine worked fine, > while Vista (SP1 x64) caused the problem. > > What solved the problem definitely was disabling TSO for re0 (ifconfig One of developer also reported TSO issue. But his hardware was a plain 8169S. Given that you're seeing TSO issues on 8110SB I'm afraid all RealTek 8169/8110 series may suffer from the TSO issues. Under certain circumtances, the controller generates corrupted frames for TSO case and this seem to be resulted in watchdog timeouts. I'm not sure recent PCIe based 8168/8110 family also suffers from the issue as no one have complained the issue. > re0 -tso). I haven't notice any performance drop and it works fine, > but I'm just curious what happened to the 'good' driver from 7.0-RELEASE. > I don't think re(4) in 7.0-RELEASE is bug free. If you check commit logs in RELENG_7 you may see what I mean. At the time of re(4) overhauling, I added TSO to re(4). Generally TSO shall not increase Tx performance but TSO significantly saves CPU cycles for TCP bulk transfers. The saved CPU power could be used for other tasks. Anyway, thanks for reporting, I'll disable TSO in next monday. -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 12:20:13 2008 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 C78D51065702 for ; Fri, 1 Aug 2008 12:20:13 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate01.web.de (fmmailgate01.web.de [217.72.192.221]) by mx1.freebsd.org (Postfix) with ESMTP id 827088FC18 for ; Fri, 1 Aug 2008 12:20:13 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate01.web.de (Postfix) with ESMTP id B1AE3E9FD317 for ; Fri, 1 Aug 2008 14:20:11 +0200 (CEST) Received: from [217.236.6.45] (helo=zelda.local) by smtp08.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1KOtcB-0005gd-00 for freebsd-stable@freebsd.org; Fri, 01 Aug 2008 14:20:11 +0200 Date: Fri, 1 Aug 2008 14:20:05 +0200 From: Martin To: Message-ID: <20080801142005.473c17ca@zelda.local> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_//ZCC3lHZ6IStEPMiFbQwJby"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX19PL8BctbCltHAelYqWIfvD2xyg95o6spDASPNO KKRkV8GdLmq0HI2KEQeFoQFdsPcPzOOsRnM1xaRuXHS6GkzEDL NNB0RwBTw= Subject: em(4) on FreeBSD is sometimes annoying 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, 01 Aug 2008 12:20:13 -0000 --Sig_//ZCC3lHZ6IStEPMiFbQwJby Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, I don't remember anymore when I reported it the first time. I think it was around 4.x or something like that. The em(4) bug is still there after years. Hasn't anyone really noticed yet that em(4) only appears when you boot FreeBSD with the interface physically attached to a switch for example? If you attach it later, after boot up, the interface won't power up and appear in the interface list (ifconfig)? Steps to reproduce: 1) Switch your PC/laptop off. Really OFF, no reboot. 2) Disconnect the em(4) NIC from your switch. 3) Boot FreeBSD. 4) Plug in the ethernet cable. 5) Tataa! All leds at the NIC stay off. You won't be able to use em(4) unless you reboot your machine. Something is not being initialized properly on em(4) devices, it seems.=20 I have had 3 of 3 em(4) NICs so far, where this bug shows up. And it's extremely annoying on Thinkpads, when you just want to plug in your laptop somewhere. -- Martin --Sig_//ZCC3lHZ6IStEPMiFbQwJby Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiS/3UACgkQC3yNaKlBCg0rVACgokyotrDnFIIdoN2b/y56J4Qp is8An3GOJSF/It6om1AzDj5DHPX7bED7 =eQwX -----END PGP SIGNATURE----- --Sig_//ZCC3lHZ6IStEPMiFbQwJby-- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 12:27:31 2008 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 181FD106564A for ; Fri, 1 Aug 2008 12:27:31 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 569538FC08 for ; Fri, 1 Aug 2008 12:27:30 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: (qmail 12433 invoked from network); 1 Aug 2008 12:27:28 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 1 Aug 2008 12:27:28 -0000 Date: Fri, 01 Aug 2008 14:27:28 +0200 (CEST) Message-Id: <20080801.142728.74660240.sthaug@nethelp.no> To: nakal@web.de From: sthaug@nethelp.no In-Reply-To: <20080801142005.473c17ca@zelda.local> References: <20080801142005.473c17ca@zelda.local> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: em(4) on FreeBSD is sometimes annoying 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, 01 Aug 2008 12:27:31 -0000 > Hasn't anyone really noticed yet that em(4) only appears when you boot > FreeBSD with the interface physically attached to a switch for example? > If you attach it later, after boot up, the interface won't power up and > appear in the interface list (ifconfig)? I'm afraid I don't see your problem at all. My em interfaces appear as they should, even if not connected to a switch. And when I connect an em interface to a switch, I get link and things work as expected. > Steps to reproduce: > 1) Switch your PC/laptop off. Really OFF, no reboot. > 2) Disconnect the em(4) NIC from your switch. > 3) Boot FreeBSD. > 4) Plug in the ethernet cable. > 5) Tataa! All leds at the NIC stay off. You won't be able to use em(4) > unless you reboot your machine. > > Something is not being initialized properly on em(4) devices, it seems. This may well be the case - but not that the em driver handles several different chip models. You may have a problem which is specific to one or a few chip models. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 12:42:24 2008 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 ADFE91065684 for ; Fri, 1 Aug 2008 12:42:24 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8058FC1C for ; Fri, 1 Aug 2008 12:42:24 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 867B31CC0B4; Fri, 1 Aug 2008 05:42:24 -0700 (PDT) Date: Fri, 1 Aug 2008 05:42:24 -0700 From: Jeremy Chadwick To: Martin Message-ID: <20080801124224.GA17183@eos.sc1.parodius.com> References: <20080801142005.473c17ca@zelda.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080801142005.473c17ca@zelda.local> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: em(4) on FreeBSD is sometimes annoying 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, 01 Aug 2008 12:42:24 -0000 On Fri, Aug 01, 2008 at 02:20:05PM +0200, Martin wrote: > I don't remember anymore when I reported it the first time. I think it > was around 4.x or something like that. The em(4) bug is still there > after years. > > Hasn't anyone really noticed yet that em(4) only appears when you boot > FreeBSD with the interface physically attached to a switch for example? > If you attach it later, after boot up, the interface won't power up and > appear in the interface list (ifconfig)? > > Steps to reproduce: > 1) Switch your PC/laptop off. Really OFF, no reboot. > 2) Disconnect the em(4) NIC from your switch. > 3) Boot FreeBSD. > 4) Plug in the ethernet cable. > 5) Tataa! All leds at the NIC stay off. You won't be able to use em(4) > unless you reboot your machine. > > Something is not being initialized properly on em(4) devices, it seems. Generally speaking (with my other NICs, specifically Pro/1000 NICs), I have not seen this behaviour. The em(4) driver behaves very well and does 802.3u auto-neg of speed/duplex properly. I have used many different revisions of Pro/1000 on FreeBSD and haven't seen this behaviour. Most commonly what you're reporting is the result of a switch upstream which isn't fully compatible or properly doing 802.3u auto-neg. Rebooting the machine (thus tearing down link hard, and resetting the entire chip) often works in this situation. You can also try setting the speed and duplex (media and mediaopt) in your ifconfig_emX line in rc.conf to see if that helps (on some switches it does). The behaviour you're reporting I've seen on old 3Com XL 509x cards with Cisco switches, for example. I gladly await more flame mails from people telling me "Yes, that is a known problem with Cisco switches in the past, but it does not happen any more", but even present-day Cisco switches we use at our workplace (alongside em(4) NICs) behave erroneously just like "in the past". *shrug* Everyone has a different experience. > I have had 3 of 3 em(4) NICs so far, where this bug shows up. And it's > extremely annoying on Thinkpads, when you just want to plug in your > laptop somewhere. I have a Thinkpad T60p. I'll try booting FreeBSD on it next week and see if I can reproduce the behaviour. I'll also include what switch brands/models are being plugged into. -- | Jeremy Chadwick jdc at 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 Aug 1 12:44:18 2008 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 18F981065688 for ; Fri, 1 Aug 2008 12:44:18 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 01D638FC12 for ; Fri, 1 Aug 2008 12:44:17 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id DA8D01A4D80; Fri, 1 Aug 2008 05:44:17 -0700 (PDT) Date: Fri, 1 Aug 2008 05:44:17 -0700 From: Alfred Perlstein To: Ken Smith Message-ID: <20080801124417.GA76659@elvis.mu.org> References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current , freebsd-stable Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 01 Aug 2008 12:44:18 -0000 * Ken Smith [080729 08:47] wrote: > > Normally the FreeBSD Project tries very hard to avoid ABI breakage in > "Stable Branches". However occasionally the fix for a bug can not be > implemented without ABI breakage, and it is decided that the fix > warrants the impact of the ABI breakage. We have one of those > situations coming along for RELENG_7 (what will become FreeBSD 7.1). > The ABI breakage should only impact kernel modules that are not part of > the baseline system (those will be patched by the MFC) which deal with > advisory locks. As such the impact should not cause many people > problems. > > The work that will be MFCed fixes issues with filesystem advisory locks, > and moves the advisory locks list from filesystem-private data > structures into the vnode structure. > > The MFC will be done by Kostantin Belousov some time this coming Friday > (August 1st, 2008) if you have concerns and want to watch for it. Ken, Can you point at a cvs/svn log or two that details the change and why? Everyone else: For those confused about what ABI breakage means: It means that you'll need to recompile your kernel modules and potentially your system utilities that access kernel data structures to display statistics. It seems like in this particular case you won't need to recompile, but it's a good idea just to be safe to recompile kernel, world and any third party kernel modules you have. thank you, -Alfred From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 12:50:39 2008 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 012611065672; Fri, 1 Aug 2008 12:50:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4C2348FC21; Fri, 1 Aug 2008 12:50:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 m71Co69r012736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2008 15:50:06 +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.2/8.14.2) with ESMTP id m71Co6Dl071028; Fri, 1 Aug 2008 15:50:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m71Co5aX071027; Fri, 1 Aug 2008 15:50: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, 1 Aug 2008 15:50:05 +0300 From: Kostik Belousov To: Alfred Perlstein Message-ID: <20080801125005.GI97161@deviant.kiev.zoral.com.ua> References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <20080801124417.GA76659@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BRF4e1IEQp0HoEFj" Content-Disposition: inline In-Reply-To: <20080801124417.GA76659@elvis.mu.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Ken Smith , freebsd-stable , freebsd-current Subject: Re: Upcoming ABI Breakage in RELENG_7 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, 01 Aug 2008 12:50:39 -0000 --BRF4e1IEQp0HoEFj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 01, 2008 at 05:44:17AM -0700, Alfred Perlstein wrote: > * Ken Smith [080729 08:47] wrote: > >=20 > > Normally the FreeBSD Project tries very hard to avoid ABI breakage in > > "Stable Branches". However occasionally the fix for a bug can not be > > implemented without ABI breakage, and it is decided that the fix > > warrants the impact of the ABI breakage. We have one of those > > situations coming along for RELENG_7 (what will become FreeBSD 7.1). > > The ABI breakage should only impact kernel modules that are not part of > > the baseline system (those will be patched by the MFC) which deal with > > advisory locks. As such the impact should not cause many people > > problems. > >=20 > > The work that will be MFCed fixes issues with filesystem advisory locks, > > and moves the advisory locks list from filesystem-private data > > structures into the vnode structure. > >=20 > > The MFC will be done by Kostantin Belousov some time this coming Friday > > (August 1st, 2008) if you have concerns and want to watch for it. >=20 > Ken, >=20 > Can you point at a cvs/svn log or two that details the change and > why? MFCed as r181119. See the log for all details. --BRF4e1IEQp0HoEFj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiTBn0ACgkQC3+MBN1Mb4g9+QCcCcUYWfyVDLMXYyYUbE6rkwxu Lm4AoOcvJNogNIX8MCQRhV3H9uNQFbm6 =Z8AX -----END PGP SIGNATURE----- --BRF4e1IEQp0HoEFj-- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 13:20:19 2008 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 2F8B01065670 for ; Fri, 1 Aug 2008 13:20:19 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) by mx1.freebsd.org (Postfix) with ESMTP id 165878FC23 for ; Fri, 1 Aug 2008 13:20:18 +0000 (UTC) (envelope-from danallen46@airwired.net) Received: (qmail 17080 invoked by uid 89); 1 Aug 2008 12:55:44 -0000 Received: from unknown (HELO ?192.168.0.16?) (danallen46@airwired.net@66.29.174.6) by 0 with ESMTPA; 1 Aug 2008 12:55:44 -0000 Message-Id: From: Dan Allen To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 1 Aug 2008 07:20:15 -0600 X-Mailer: Apple Mail (2.926) Subject: re: no toe capability message 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, 01 Aug 2008 13:20:19 -0000 I had just cvsup'd when I found this, but having done so again it now appears fixed. Thanks! Dan From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 13:27:51 2008 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 870231065672 for ; Fri, 1 Aug 2008 13:27:51 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gidgate.gid.co.uk (host-83-146-60-88.dslgb.com [83.146.60.88]) by mx1.freebsd.org (Postfix) with ESMTP id 2BAD38FC1E for ; Fri, 1 Aug 2008 13:27:49 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.28] ([194.32.164.6]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id m71DGvlR033272; Fri, 1 Aug 2008 14:16:57 +0100 (BST) (envelope-from rb@gid.co.uk) Message-Id: From: Bob Bishop To: Martin In-Reply-To: <20080801142005.473c17ca@zelda.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 1 Aug 2008 14:16:57 +0100 References: <20080801142005.473c17ca@zelda.local> X-Mailer: Apple Mail (2.928.1) Cc: freebsd-stable@freebsd.org Subject: Re: em(4) on FreeBSD is sometimes annoying 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, 01 Aug 2008 13:27:51 -0000 Hi, On 1 Aug 2008, at 13:20, Martin wrote: > > Hello, > > I don't remember anymore when I reported it the first time. I think it > was around 4.x or something like that. The em(4) bug is still there > after years. > > Hasn't anyone really noticed yet that em(4) only appears when you boot > FreeBSD with the interface physically attached to a switch for > example? > If you attach it later, after boot up, the interface won't power up > and > appear in the interface list (ifconfig)? > > Steps to reproduce: > 1) Switch your PC/laptop off. Really OFF, no reboot. > 2) Disconnect the em(4) NIC from your switch. > 3) Boot FreeBSD. > 4) Plug in the ethernet cable. > 5) Tataa! All leds at the NIC stay off. You won't be able to use em(4) > unless you reboot your machine. > > Something is not being initialized properly on em(4) devices, it > seems. > > I have had 3 of 3 em(4) NICs so far, where this bug shows up. And it's > extremely annoying on Thinkpads, when you just want to plug in your > laptop somewhere. Well it's not a problem for my TP T41 (just tested with 5.0R and 7.0R), the NIC probes as: and I've never seen it on sundry other boxes with em. That doesn't mean it can't happen, of course. > -- > Martin -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 mobile +44 (0)783 626 4518 From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 15:00:27 2008 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 C50AD106567C for ; Fri, 1 Aug 2008 15:00:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9CE738FC1D for ; Fri, 1 Aug 2008 15:00:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7D12446B9D; Fri, 1 Aug 2008 10:43:36 -0400 (EDT) Date: Fri, 1 Aug 2008 15:43:36 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Martin In-Reply-To: <20080801142005.473c17ca@zelda.local> Message-ID: <20080801154208.W6085@fledge.watson.org> References: <20080801142005.473c17ca@zelda.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: jfv@FreeBSD.org, freebsd-stable@freebsd.org Subject: Re: em(4) on FreeBSD is sometimes annoying 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, 01 Aug 2008 15:00:27 -0000 On Fri, 1 Aug 2008, Martin wrote: > I don't remember anymore when I reported it the first time. I think it was > around 4.x or something like that. The em(4) bug is still there after years. > > Hasn't anyone really noticed yet that em(4) only appears when you boot > FreeBSD with the interface physically attached to a switch for example? If > you attach it later, after boot up, the interface won't power up and appear > in the interface list (ifconfig)? The card range supported by the if_em driver is huge, so it wouldn't be surprising if this is a hardware bug affecting a relatively narrow line of parts. I've added Jack Vogel to the CC line, as he's the Intel developer responsible for maintaining our if_em driver. I don't promise he can help either, but it's worth a try :-). Robert > > Steps to reproduce: > 1) Switch your PC/laptop off. Really OFF, no reboot. > 2) Disconnect the em(4) NIC from your switch. > 3) Boot FreeBSD. > 4) Plug in the ethernet cable. > 5) Tataa! All leds at the NIC stay off. You won't be able to use em(4) > unless you reboot your machine. > > Something is not being initialized properly on em(4) devices, it seems. > > I have had 3 of 3 em(4) NICs so far, where this bug shows up. And it's > extremely annoying on Thinkpads, when you just want to plug in your > laptop somewhere. > > -- > Martin > From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 16:10:00 2008 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 89F3A106566B for ; Fri, 1 Aug 2008 16:10:00 +0000 (UTC) (envelope-from royce@alaska.net) Received: from iris.acsalaska.net (iris.acsalaska.net [209.112.173.229]) by mx1.freebsd.org (Postfix) with ESMTP id 624458FC19 for ; Fri, 1 Aug 2008 16:10:00 +0000 (UTC) (envelope-from royce@alaska.net) Received: from [10.0.102.101] (209-112-156-40-adslb0fh.acsalaska.net [209.112.156.40]) by iris.acsalaska.net (8.14.1/8.14.1) with ESMTP id m71G9xYH014479; Fri, 1 Aug 2008 08:09:59 -0800 (AKDT) (envelope-from royce@alaska.net) Message-ID: <48933557.8010904@alaska.net> Date: Fri, 01 Aug 2008 08:09:59 -0800 From: Royce Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.16) Gecko/20080708 Thunderbird/2.0.0.16 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org References: <488638DA.7010005@alaska.net> <20080723053404.GA46617@eos.sc1.parodius.com> <4886D1E9.1090905@alaska.net> In-Reply-To: <4886D1E9.1090905@alaska.net> X-Enigmail-Version: 0.95.6 OpenPGP: url=http://www.tycho.org/royce/royce@alaska.net.asc X-Face: ">19[ShfDD9'g", GrH$'v:=qBVZdg.kXSBR6*ZC$am:D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.63; SA 3.2.4; spamdefang 1.122 Cc: Subject: Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ 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, 01 Aug 2008 16:10:00 -0000 Royce Williams wrote, on 7/22/2008 10:38 PM: > Jeremy Chadwick wrote, on 7/22/2008 9:34 PM: >> On Tue, Jul 22, 2008 at 11:45:30AM -0800, Royce Williams wrote: >>> We have 10 SuperMicro PDSMi+ 5015M-MTs that are panic'ing every few >>> days. This started shortly after upgrade from 6.2-RELEASE to >>> 6.3-RELEASE with freebsd-update. >> We use the same hardware (board and chassis), and have no such problems >> running both RELENG_6 and RELENG_7. >> >> I don't think your issue is specific to the board or chassis. Kris's >> explanation makes a lot more sense. :-) > > Jeremy/Kris/Clifton - > > Looks like we have consensus. :-) Thanks, all of you, for your > helpful insight. > > I've bumped vm.kmem_size up to 400M on half of the affected boxes, > leaving the other half as a control group. I'll report back once I > have something to report. After having bumped up to 400M, a few boxes panic'd again yesterday. I caught a core, and it is "kmem_map too small", just as Kris suspected: Jul 31 15:38:05 [redacted] savecore: reboot after panic: kmem_malloc(4096): kmem_map too small: 419430400 total allocated The docs state that 400M should be plenty for systems up to 6G, but Kris said earlier in this thread that it's better to say 'increase until the pain stops'. :-) Accordingly, I have some some follow-up questions; hopefully, this will be useful to others. - What is a reasonable increment? (I'm trying 448M next). - What are the practical and hard maximums? - I suspect that it's worth trying to make kmem 'as big as I need, but no bigger', so that non-kernel memory is also maximized? - In a larger sense, if 400M is probably big enough for 6G systems, and these are 4G systems, should I be suspicious that 400M isn't cutting it? In other words, is there a point at which should I be looking for obvious places where the kernel is eating too much memory and reduce them, rather than feeding it more? For example, I recall now that a network guy in my group did some sysctl tuning relating to networking on these systems, and I see from man tuning(7) that a number of these tweaks (obviously) can cause increased kernel consumption. $ egrep -v '^#|^$' /etc/sysctl.conf | sort kern.corefile=/var/cores/%U/%N-%P.core kern.ipc.maxsockbuf=8388608 kern.ipc.maxsockets=32768 kern.ipc.nmbclusters=65535 kern.ipc.somaxconn=4096 kern.maxfiles=262144 kern.maxfilesperproc=65535 net.inet.ip.portrange.first=8192 net.inet.ip.portrange.hifirst=8192 net.inet.ip.portrange.hilast=65535 net.inet.ip.portrange.last=65535 net.inet.ipf.fr_tcpclosed=60 net.inet.ipf.fr_tcpclosewait=120 net.inet.ipf.fr_tcphalfclosed=300 net.inet.ipf.fr_udptimeout=120 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.msl=10000 net.inet.tcp.mssdflt=1460 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendspace=65536 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65535 vfs.nfs.iodmax=32 vfs.nfs.iodmin=8 My apologies for not including this sooner. I didn't think of it until yesterday, primarily because it had been fine under 6.2. In retrospect, that was bad reasoning. Royce -- Royce D. Williams - http://royce.ws/ Reason is a very light rider, and easily shook off. - Jonathan Swift From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 16:18:45 2008 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 B1708106564A for ; Fri, 1 Aug 2008 16:18:45 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from raats.xs4all.nl (raats.xs4all.nl [82.95.230.43]) by mx1.freebsd.org (Postfix) with ESMTP id 6D1138FC0A for ; Fri, 1 Aug 2008 16:18:45 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from raats.xs4all.nl (localhost.jarasoft.net [127.0.0.1]) by raats.xs4all.nl (Postfix) with ESMTP id CEEB32284D; Fri, 1 Aug 2008 18:06:35 +0200 (CEST) Received: from jara3 (jara-3 [192.168.1.101]) by raats.xs4all.nl (Postfix) with ESMTPA id 1090E22830; Fri, 1 Aug 2008 18:06:35 +0200 (CEST) Message-ID: <6A7AD37501FA4199B44BBBB03B0EE368@jarasoft.net> From: "Jack Raats" To: "freebsd-stable" , Date: Fri, 1 Aug 2008 18:06:33 +0200 Organization: JaRaSoft, Steenbergen, Nederland MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 X-Signed-With-GnuPG: GPGrelay Version 0.959 (Win32) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP on orac.jarasoft.net Cc: Subject: Adding device to FreeBSD 6.3-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jack Raats List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2008 16:18:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I would like to add the zyd device to FreeBSD. The zyd driver allready is in FreeBSD 7.0. Which steps do I have to take to add the zyd device to FreeBSD? Jack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) - GPGrelay v0.959 iD8DBQFIkzSKPh5RwW/NzC4RAqMKAJ987kbR57nNejUHOaNPOLabP2jKWACgm6Ts iOvTzyGUw1evnXmmHSa6+RA=3D =3Df1r1 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 16:24:56 2008 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 0C98C1065672 for ; Fri, 1 Aug 2008 16:24:56 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by mx1.freebsd.org (Postfix) with ESMTP id 8ECB28FC15 for ; Fri, 1 Aug 2008 16:24:55 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so1436866fkk.11 for ; Fri, 01 Aug 2008 09:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=BHkBByYJdDAuo1kEkdMduyURHhEgKr2MYs6e3BipjIY=; b=TTTRdBVvoCFdgaD8iNQBR0U8ViuPBI8mTjcBYTszoioyoYoiPvM9LzdBvL4fqORxOX kkeswUcSDnlbDNKO4JnqgkS8uYxbxq9wMaeL8GHKpSPc89zR5R32loEeOJmf7iwbkSd1 lYw0E4vXVV2AR1AKoCnZ/MECbR7IFUX56WM0Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Gz3/hlOU6qgxrPKvClQN6z8j1rvqhjdFnXY2zVsfonQVXph+5iydVeczfyfJEJesPT YgZq2RdwF8+t78pF9TGmVG1wsyMiGCN6BDDtVVhm20YoVNe8w1WJniGe+VwAfLlrqmSK GC6dZ3zsibUd5nH0GwBMsG2wR2fKSqbaat7/g= Received: by 10.180.208.5 with SMTP id f5mr4109563bkg.42.1217607894237; Fri, 01 Aug 2008 09:24:54 -0700 (PDT) Received: by 10.125.74.17 with HTTP; Fri, 1 Aug 2008 09:24:53 -0700 (PDT) Message-ID: <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> Date: Fri, 1 Aug 2008 09:24:53 -0700 From: "Jack Vogel" To: "Robert Watson" In-Reply-To: <20080801154208.W6085@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080801142005.473c17ca@zelda.local> <20080801154208.W6085@fledge.watson.org> Cc: jfv@freebsd.org, freebsd-stable@freebsd.org, Martin Subject: Re: em(4) on FreeBSD is sometimes annoying 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, 01 Aug 2008 16:24:56 -0000 If the poster gives me EXACT hardware list I will see about repro'ing the problem inhouse. We do not do much of anything with laptops but I will see. Oh and a pciconf would help too. Jack On Fri, Aug 1, 2008 at 7:43 AM, Robert Watson wrote: > > On Fri, 1 Aug 2008, Martin wrote: > >> I don't remember anymore when I reported it the first time. I think it was >> around 4.x or something like that. The em(4) bug is still there after years. >> >> Hasn't anyone really noticed yet that em(4) only appears when you boot >> FreeBSD with the interface physically attached to a switch for example? If >> you attach it later, after boot up, the interface won't power up and appear >> in the interface list (ifconfig)? > > The card range supported by the if_em driver is huge, so it wouldn't be > surprising if this is a hardware bug affecting a relatively narrow line of > parts. I've added Jack Vogel to the CC line, as he's the Intel developer > responsible for maintaining our if_em driver. I don't promise he can help > either, but it's worth a try :-). > > Robert > >> >> Steps to reproduce: >> 1) Switch your PC/laptop off. Really OFF, no reboot. >> 2) Disconnect the em(4) NIC from your switch. >> 3) Boot FreeBSD. >> 4) Plug in the ethernet cable. >> 5) Tataa! All leds at the NIC stay off. You won't be able to use em(4) >> unless you reboot your machine. >> >> Something is not being initialized properly on em(4) devices, it seems. >> >> I have had 3 of 3 em(4) NICs so far, where this bug shows up. And it's >> extremely annoying on Thinkpads, when you just want to plug in your >> laptop somewhere. >> >> -- >> Martin >> > From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 16:45:53 2008 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 820C41065674 for ; Fri, 1 Aug 2008 16:45:53 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id 4860A8FC2B for ; Fri, 1 Aug 2008 16:45:53 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from max.local (rrcs-74-218-226-253.se.biz.rr.com [74.218.226.253]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id m71GD3JP002865; Fri, 1 Aug 2008 12:13:03 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-questions@freebsd.org, Jack Raats Date: Fri, 1 Aug 2008 12:13:41 -0400 User-Agent: KMail/1.9.7 References: <6A7AD37501FA4199B44BBBB03B0EE368@jarasoft.net> In-Reply-To: <6A7AD37501FA4199B44BBBB03B0EE368@jarasoft.net> X-Face: #X5#Y*q>F:]zT!DegL3z5Xo'^MN[$8k\[4^3rN~wm=s=Uw(sW}R?3b^*f1Wu*.<=?utf-8?q?of=5F4NrS=0A=09P*M/9CpxDo!D6?=)IY1w<9B1jB; tBQf[RU-R<,I)e"$q7N7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808011213.41335.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-stable Subject: Re: Adding device to FreeBSD 6.3-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: Fri, 01 Aug 2008 16:45:53 -0000 On Friday 01 August 2008, Jack Raats wrote: > I would like to add the zyd device to FreeBSD. > The zyd driver allready is in FreeBSD 7.0. > Which steps do I have to take to add the zyd device to FreeBSD? Sorry, what are you asking? What version of FreeBSD are you using and what do you need help doing? JN From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 17:02:01 2008 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 3840B1065671 for ; Fri, 1 Aug 2008 17:02:01 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from fmailhost02.isp.att.net (fmailhost02.isp.att.net [204.127.217.102]) by mx1.freebsd.org (Postfix) with ESMTP id 209708FC08 for ; Fri, 1 Aug 2008 17:02:01 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from [10.5.21.122] (adsl-19-255-192.bna.bellsouth.net[68.19.255.192]) by isp.att.net (frfwmhc02) with ESMTP id <20080801165156H02000v0b0e>; Fri, 1 Aug 2008 16:51:58 +0000 X-Originating-IP: [68.19.255.192] Message-ID: <48933F23.1050201@datapipe.com> Date: Fri, 01 Aug 2008 11:51:47 -0500 From: Paul Procacci User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: John Nielsen References: <6A7AD37501FA4199B44BBBB03B0EE368@jarasoft.net> <200808011213.41335.lists@jnielsen.net> In-Reply-To: <200808011213.41335.lists@jnielsen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable , "freebsd-questions@freebsd.org" Subject: Re: Adding device to FreeBSD 6.3-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: Fri, 01 Aug 2008 17:02:01 -0000 John Nielsen wrote: > On Friday 01 August 2008, Jack Raats wrote: > >> I would like to add the zyd device to FreeBSD. >> The zyd driver allready is in FreeBSD 7.0. >> Which steps do I have to take to add the zyd device to FreeBSD? >> > > Sorry, what are you asking? What version of FreeBSD are you using and what > do you need help doing? > > JN > _______________________________________________ > 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" > To make the device available without recompiling your kernel you do the following: kldload if_zyd To have zyd available after reboots add it to /boot/loader.conf as: if_zyd_load="YES" From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 18:07:51 2008 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 778661065674 for ; Fri, 1 Aug 2008 18:07:51 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EFA038FC0C; Fri, 1 Aug 2008 18:07:49 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <489350F4.5070009@FreeBSD.org> Date: Fri, 01 Aug 2008 20:07:48 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Royce Williams References: <488638DA.7010005@alaska.net> <20080723053404.GA46617@eos.sc1.parodius.com> <4886D1E9.1090905@alaska.net> <48933557.8010904@alaska.net> In-Reply-To: <48933557.8010904@alaska.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ 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, 01 Aug 2008 18:07:51 -0000 Royce Williams wrote: > Royce Williams wrote, on 7/22/2008 10:38 PM: >> Jeremy Chadwick wrote, on 7/22/2008 9:34 PM: >>> On Tue, Jul 22, 2008 at 11:45:30AM -0800, Royce Williams wrote: >>>> We have 10 SuperMicro PDSMi+ 5015M-MTs that are panic'ing every few >>>> days. This started shortly after upgrade from 6.2-RELEASE to >>>> 6.3-RELEASE with freebsd-update. >>> We use the same hardware (board and chassis), and have no such problems >>> running both RELENG_6 and RELENG_7. >>> >>> I don't think your issue is specific to the board or chassis. Kris's >>> explanation makes a lot more sense. :-) >> Jeremy/Kris/Clifton - >> >> Looks like we have consensus. :-) Thanks, all of you, for your >> helpful insight. >> >> I've bumped vm.kmem_size up to 400M on half of the affected boxes, >> leaving the other half as a control group. I'll report back once I >> have something to report. > > After having bumped up to 400M, a few boxes panic'd again yesterday. > I caught a core, and it is "kmem_map too small", just as Kris > suspected: > > Jul 31 15:38:05 [redacted] savecore: reboot after panic: kmem_malloc(4096): kmem_map too small: 419430400 total allocated > > > The docs state that 400M should be plenty for systems up to 6G, but > Kris said earlier in this thread that it's better to say 'increase > until the pain stops'. :-) Accordingly, I have some some follow-up > questions; hopefully, this will be useful to others. > > - What is a reasonable increment? (I'm trying 448M next). > > - What are the practical and hard maximums? > > - I suspect that it's worth trying to make kmem 'as big as I need, but > no bigger', so that non-kernel memory is also maximized? > > - In a larger sense, if 400M is probably big enough for 6G systems, > and these are 4G systems, should I be suspicious that 400M isn't > cutting it? In other words, is there a point at which should I be > looking for obvious places where the kernel is eating too much memory > and reduce them, rather than feeding it more? > > For example, I recall now that a network guy in my group did some > sysctl tuning relating to networking on these systems, and I see > from man tuning(7) that a number of these tweaks (obviously) can > cause increased kernel consumption. > > $ egrep -v '^#|^$' /etc/sysctl.conf | sort > kern.corefile=/var/cores/%U/%N-%P.core > kern.ipc.maxsockbuf=8388608 > kern.ipc.maxsockets=32768 > kern.ipc.nmbclusters=65535 > kern.ipc.somaxconn=4096 > kern.maxfiles=262144 > kern.maxfilesperproc=65535 > net.inet.ip.portrange.first=8192 > net.inet.ip.portrange.hifirst=8192 > net.inet.ip.portrange.hilast=65535 > net.inet.ip.portrange.last=65535 > net.inet.ipf.fr_tcpclosed=60 > net.inet.ipf.fr_tcpclosewait=120 > net.inet.ipf.fr_tcphalfclosed=300 > net.inet.ipf.fr_udptimeout=120 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.inflight.enable=0 > net.inet.tcp.msl=10000 > net.inet.tcp.mssdflt=1460 > net.inet.tcp.recvspace=65536 > net.inet.tcp.rfc1323=1 > net.inet.tcp.sendspace=65536 > net.inet.udp.maxdgram=57344 > net.inet.udp.recvspace=65535 > vfs.nfs.iodmax=32 > vfs.nfs.iodmin=8 > > > My apologies for not including this sooner. I didn't think of it > until yesterday, primarily because it had been fine under 6.2. In > retrospect, that was bad reasoning. > > Royce > The statement that "400MB should be enough for up to 6GB" is completely bogus. The amount of memory your kernel needs is a function of the work you give it to do. On i386 the kernel only has 1GB of address space though you can increase it by tuning KVA_PAGES at the expense of less memory available to user processes (everything comes out of 4GB address space). So that is the upper bound although other things need to fit in there too. On amd64 the situation is more complicated but on older versions than 8.0 there is 2GB for the kernel address space and in practise a limit of about 1500MB of kmem. It is possible that you are hitting a memory leak but I would just increase kmem further and see if it persists. Looking at vmstat -m etc may help to figure out if something is leaking over time. Kris From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 19:26:31 2008 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 D2E0910656D7; Fri, 1 Aug 2008 19:26:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6DC8B8FC08; Fri, 1 Aug 2008 19:26:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m71JQCvx051362; Fri, 1 Aug 2008 15:26:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 1 Aug 2008 14:42:36 -0400 User-Agent: KMail/1.9.7 References: <6A7AD37501FA4199B44BBBB03B0EE368@jarasoft.net> <200808011213.41335.lists@jnielsen.net> In-Reply-To: <200808011213.41335.lists@jnielsen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200808011442.37048.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Fri, 01 Aug 2008 15:26:25 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7911/Fri Aug 1 08:10:36 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-questions@freebsd.org Subject: Re: Adding device to FreeBSD 6.3-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: Fri, 01 Aug 2008 19:26:31 -0000 On Friday 01 August 2008 12:13:41 pm John Nielsen wrote: > On Friday 01 August 2008, Jack Raats wrote: > > I would like to add the zyd device to FreeBSD. > > The zyd driver allready is in FreeBSD 7.0. > > Which steps do I have to take to add the zyd device to FreeBSD? >=20 > Sorry, what are you asking? What version of FreeBSD are you using and wha= t=20 > do you need help doing? =46rom the subject line, I imagine Jack is using 6.3-STABLE and wants to=20 backport the driver from 7.0 to 6.3. Backporting most drivers from 7.0 to= =20 6.x isn't a big deal (can generally just copy over and compile). However,= =20 zyd(4) is a wireless driver and the net80211 wireless networking stack is=20 quite different in 6.x vs 7.0, so that is where it would be complicated to= =20 backport the driver. I'm not intimately familiar with net80211 in either=20 branch, so I'm unsure how much work the backport would be. =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Aug 1 19:34:16 2008 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 39286106567A for ; Fri, 1 Aug 2008 19:34:16 +0000 (UTC) (envelope-from burt.rosenberg@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id EFD5C8FC1A for ; Fri, 1 Aug 2008 19:34:15 +0000 (UTC) (envelope-from burt.rosenberg@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1619094rvf.43 for ; Fri, 01 Aug 2008 12:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:x-google-sender-auth; bh=rZKL/U0RyagKraU5D+tv2UrddlvIAAJKq9mmFI3baV4=; b=W8/PoqP0m9suqgQ1srdFkGNEI1/URQjMX2GPeDMWUiq27dkif4TIyKv4UMnk5m/kmd YVavE1a6f1TBpsf7L3Hi8Dhl/HBLNQhCfBgG5ZCoy2deBPUm7C5dIee2mrIAeIGj6Pi4 6bgyn/UlxyDzFOvAC4aQ23SWFW+e/LND2A4fk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :x-google-sender-auth; b=mSli/BjRJPEnrfjKmVmeyrDgHyi140JetQlAd5DomLiLWlepJDl8/XWNTl6Q2jZnLw nmCsB7KmyqaBFn4UAsoYFEaRrNLv/LoXf+9Ip7omf9dDmK9tIZwafKFdep1aGbRh94/i 9/yxdqFLYPvr3Pu/kZ7AUZiZPPAEAeOYKctU0= Received: by 10.141.137.8 with SMTP id p8mr6130354rvn.163.1217617634468; Fri, 01 Aug 2008 12:07:14 -0700 (PDT) Received: by 10.141.63.16 with HTTP; Fri, 1 Aug 2008 12:07:14 -0700 (PDT) Message-ID: Date: Fri, 1 Aug 2008 15:07:14 -0400 From: "burt rosenberg" Sender: burt.rosenberg@gmail.com To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_11775_2907320.1217617634432" X-Google-Sender-Auth: 220b5b7481c09940 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: reboot sometimes freezes, adaptic scsi card possible problem 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, 01 Aug 2008 19:34:16 -0000 ------=_Part_11775_2907320.1217617634432 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On reboot, one out of 10 times, reboot (from hardware initialization) stops. Referring to this portion of the dmesg -v output, of a successful boot, where i have marked ">>>HERE<<<" is where the boot freezes on an unsuccessful boot. This is a constnat problem, on 6.2 as well as 6.3 unchanged. ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on 63XXESB2 chip acd0: setting UDMA33 on 63XXESB2 chip acd0: CDRW drive at ata0 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 1536KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc mfid0: on mfi0 mfid0: 139392MB (285474816 sectors) RAID volume '' is optimal GEOM: new disk mfid0 mfi0: 3796 (270874608s/0x0008/0) - Battery temperature is normal mfi0: 3797 (270874608s/0x0008/0) - Battery started charging mfi0: 3798 (270874608s/0x0008/0) - Current capacity of the battery is above threshold >>>>>>>>>>>HERE<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ahd0: Selection Timeout on A:10. 0 SCBs aborted ahd1: Selection Timeout on A:0. 0 SCBs aborted ahd0: Selection Timeout on A:11. 0 SCBs aborted ahd1: Selection Timeout on A:1. 0 SCBs aborted ahd0: Selection Timeout on A:0. 0 SCBs aborted ahd1: Selection Timeout on A:10. 0 SCBs aborted ahd0: Selection Timeout on A:1. 0 SCBs aborted ahd1: Selection Timeout on A:11. 0 SCBs aborted ahd0: Selection Timeout on A:2. 0 SCBs aborted ahd1: Selection Timeout on A:12. 0 SCBs aborted ahd0: Selection Timeout on A:3. 0 SCBs aborted I have enclose various files with my hardware profile. [burt@mcclellan ~]$ uname -a FreeBSD mcclellan.cs.miami.edu 6.3-RELEASE-p3 FreeBSD 6.3-RELEASE-p3 #8: Wed Jul 30 13:02:03 EDT 2008 burt@mcclellan.cs.miami.edu:/usr/obj/usr/src/sys/MCCLELLAN amd64 Dell PowerEdge 2950; ahd0@pci15:3:0: class=0x010000 card=0x00409005 chip=0x80169005 rev=0x10 hdr=0x00 vendor = 'Adaptec Inc' device = 'ASC-39320A Ultra320 SCSI Controller' class = mass storage subclass = SCSI scbus0 on ahd0 bus 0: at scbus0 target 6 lun 0 (sa0,pass0) < > at scbus0 target -1 lun -1 () scbus1 on ahd1 bus 0: < > at scbus1 target -1 lun -1 () scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) Thanks. ------=_Part_11775_2907320.1217617634432 Content-Type: application/octet-stream; name=camcontrol_devlist.out Content-Transfer-Encoding: base64 X-Attachment-Id: f_fjd5tb8s0 Content-Disposition: attachment; filename=camcontrol_devlist.out c2NidXMwIG9uIGFoZDAgYnVzIDA6CjxTRUFHQVRFIERBVCAgICBEQVQ3Mi0wNTIgQTE2RT4gICAg YXQgc2NidXMwIHRhcmdldCA2IGx1biAwIChzYTAscGFzczApCjwgID4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgYXQgc2NidXMwIHRhcmdldCAtMSBsdW4gLTEgKCkKc2NidXMxIG9uIGFo ZDEgYnVzIDA6CjwgID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXQgc2NidXMxIHRh cmdldCAtMSBsdW4gLTEgKCkKc2NidXMtMSBvbiB4cHQwIGJ1cyAwOgo8ICA+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGF0IHNjYnVzLTEgdGFyZ2V0IC0xIGx1biAtMSAoeHB0MCkK ------=_Part_11775_2907320.1217617634432 Content-Type: application/octet-stream; name=dmesg.out Content-Transfer-Encoding: base64 X-Attachment-Id: f_fjd5tke41 Content-Disposition: attachment; filename=dmesg.out Q29weXJpZ2h0IChjKSAxOTkyLTIwMDggVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA2LjMtUkVMRUFTRS1wMyAjODogV2VkIEp1bCAzMCAx MzowMjowMyBFRFQgMjAwOAogICAgYnVydEBtY2NsZWxsYW4uY3MubWlhbWkuZWR1Oi91c3Ivb2Jq L3Vzci9zcmMvc3lzL01DQ0xFTExBTgpQcmVsb2FkZWQgZWxmIGtlcm5lbCAiL2Jvb3Qva2VybmVs L2tlcm5lbCIgYXQgMHhmZmZmZmZmZjgwN2U5MDAwLgpJTlRSOiBBZGRpbmcgbG9jYWwgQVBJQyAw IGFzIGEgdGFyZ2V0CkFDUEkgQVBJQyBUYWJsZTogPERFTEwgICBQRV9TQzMgID4KQ2FsaWJyYXRp bmcgY2xvY2socykgLi4uIGk4MjU0IGNsb2NrOiAxMTkzMTQzIEh6CkNMS19VU0VfSTgyNTRfQ0FM SUJSQVRJT04gbm90IHNwZWNpZmllZCAtIHVzaW5nIGRlZmF1bHQgZnJlcXVlbmN5ClRpbWVjb3Vu dGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNhbGlicmF0aW5nIFRT QyBjbG9jayAuLi4gVFNDIGNsb2NrOiAxOTk1MDMzNTQ2IEh6CkNQVTogSW50ZWwoUikgWGVvbihS KSBDUFUgICAgICAgICAgICA1MTMwICBAIDIuMDBHSHogKDE5OTUuMDMtTUh6IEs4LWNsYXNzIENQ VSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDZmNiAgU3RlcHBpbmcgPSA2CiAg RmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQ SUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxG WFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4NGUzM2Q8U1NFMyxSU1ZE MixNT04sRFNfQ1BMLFZNWCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00sRENBPgogIEFNRCBGZWF0 dXJlcz0weDIwMTAwODAwPFNZU0NBTEwsTlgsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4K ICBDb3JlcyBwZXIgcGFja2FnZTogMgpyZWFsIG1lbW9yeSAgPSAyMTQ3MTIzMjAwICgyMDQ3IE1C KQpQaHlzaWNhbCBtZW1vcnkgY2h1bmsocyk6CjB4MDAwMDAwMDAwMDAwMTAwMCAtIDB4MDAwMDAw MDAwMDA5YmZmZiwgNjM0ODgwIGJ5dGVzICgxNTUgcGFnZXMpCjB4MDAwMDAwMDAwMDhlNjAwMCAt IDB4MDAwMDAwMDA3YzM1YWZmZiwgMjA3NDU2MjU2MCBieXRlcyAoNTA2NDg1IHBhZ2VzKQphdmFp bCBtZW1vcnkgPSAyMDY0Mjk3OTg0ICgxOTY4IE1CKQpJTlRSOiBBZGRpbmcgbG9jYWwgQVBJQyAx IGFzIGEgdGFyZ2V0CkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6 IDIgQ1BVcwogY3B1MCAoQlNQKTogQVBJQyBJRDogIDAKIGNwdTEgKEFQKTogQVBJQyBJRDogIDEK QVBJQzogQ1BVIDAgaGFzIEFDUEkgSUQgMQpBUElDOiBDUFUgMSBoYXMgQUNQSSBJRCAyCk1BRFQ6 IEZvdW5kIElPIEFQSUMgSUQgMiwgSW50ZXJydXB0IDAgYXQgMHhmZWMwMDAwMAppb2FwaWMwOiBD aGFuZ2luZyBBUElDIElEIHRvIDIKaW9hcGljMDogUm91dGluZyBleHRlcm5hbCA4MjU5QSdzIC0+ IGludHBpbiAwCk1BRFQ6IEZvdW5kIElPIEFQSUMgSUQgMywgSW50ZXJydXB0IDY0IGF0IDB4ZmVj ODEwMDAKaW9hcGljMTogQ2hhbmdpbmcgQVBJQyBJRCB0byAzCmlvYXBpYzE6IFdBUk5JTkc6IGlu dGJhc2UgNjQgIT0gZXhwZWN0ZWQgYmFzZSAyNApNQURUOiBGb3VuZCBJTyBBUElDIElEIDQsIElu dGVycnVwdCAxNjAgYXQgMHhmZWM4NDAwMAppb2FwaWMyOiBDaGFuZ2luZyBBUElDIElEIHRvIDQK aW9hcGljMjogV0FSTklORzogaW50YmFzZSAxNjAgIT0gZXhwZWN0ZWQgYmFzZSA4OApNQURUOiBG b3VuZCBJTyBBUElDIElEIDUsIEludGVycnVwdCAyMjQgYXQgMHhmZWM4NDgwMAppb2FwaWMzOiBD aGFuZ2luZyBBUElDIElEIHRvIDUKaW9hcGljMzogV0FSTklORzogaW50YmFzZSAyMjQgIT0gZXhw ZWN0ZWQgYmFzZSAxODQKbGFwaWMwOiBSb3V0aW5nIE5NSSAtPiBMSU5UMQpsYXBpYzA6IExJTlQx IHRyaWdnZXI6IGVkZ2UKbGFwaWMwOiBMSU5UMSBwb2xhcml0eTogaGlnaApsYXBpYzE6IFJvdXRp bmcgTk1JIC0+IExJTlQxCmxhcGljMTogTElOVDEgdHJpZ2dlcjogZWRnZQpsYXBpYzE6IExJTlQx IHBvbGFyaXR5OiBoaWdoCk1BRFQ6IElnbm9yaW5nIGxvY2FsIE5NSSByb3V0ZWQgdG8gQUNQSSBD UFUgMwpNQURUOiBJZ25vcmluZyBsb2NhbCBOTUkgcm91dGVkIHRvIEFDUEkgQ1BVIDQKTUFEVDog SWdub3JpbmcgbG9jYWwgTk1JIHJvdXRlZCB0byBBQ1BJIENQVSA1Ck1BRFQ6IElnbm9yaW5nIGxv Y2FsIE5NSSByb3V0ZWQgdG8gQUNQSSBDUFUgNgpNQURUOiBJZ25vcmluZyBsb2NhbCBOTUkgcm91 dGVkIHRvIEFDUEkgQ1BVIDcKTUFEVDogSWdub3JpbmcgbG9jYWwgTk1JIHJvdXRlZCB0byBBQ1BJ IENQVSA4Ck1BRFQ6IEludGVycnVwdCBvdmVycmlkZTogc291cmNlIDAsIGlycSAyCmlvYXBpYzA6 IFJvdXRpbmcgSVJRIDAgLT4gaW50cGluIDIKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3Vy Y2UgOSwgaXJxIDkKaW9hcGljMDogaW50cGluIDkgdHJpZ2dlcjogbGV2ZWwKaW9hcGljMCA8VmVy c2lvbiAyLjA+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZAppb2FwaWMxIDxWZXJzaW9uIDIuMD4g aXJxcyA2NC04NyBvbiBtb3RoZXJib2FyZAppb2FwaWMyIDxWZXJzaW9uIDIuMD4gaXJxcyAxNjAt MTgzIG9uIG1vdGhlcmJvYXJkCmlvYXBpYzMgPFZlcnNpb24gMi4wPiBpcnFzIDIyNC0yNDcgb24g bW90aGVyYm9hcmQKY3B1MCBCU1A6CiAgICAgSUQ6IDB4MDAwMDAwMDAgICBWRVI6IDB4MDAwNTAw MTQgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxp bnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjog MHgwMDAxMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMTAwMDAgcGNtOiAweDAwMDEw MDAwCndsYW46IDw4MDIuMTEgTGluayBMYXllcj4KcmFuZG9tOiA8ZW50cm9weSBzb3VyY2UsIFNv ZnR3YXJlLCBZYXJyb3c+Cm5mc2xvY2s6IHBzZXVkby1kZXZpY2UKa2JkMCBhdCBrYmRtdXgwCm1l bTogPG1lbW9yeT4KaW86IDxJL08+Cm51bGw6IDxudWxsIGRldmljZSwgemVybyBkZXZpY2U+CmFj cGkwOiA8REVMTCBQRV9TQzM+IG9uIG1vdGhlcmJvYXJkCmlvYXBpYzA6IHJvdXRpbmcgaW50cGlu IDkgKElTQSBJUlEgOSkgdG8gdmVjdG9yIDQ4CmFjcGkwOiBbTVBTQUZFXQpBY3BpT3NEZXJpdmVQ Y2lJZDogXFxfU0JfLlBDSTAuSVNBXy5MUENDIC0+IGJ1cyAwIGRldiAzMSBmdW5jIDAKYWNwaTA6 IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCkFjcGlPc0Rlcml2ZVBjaUlkOiBcXF9TQl8uUENJMC5NQ0hN Lk1DSDAgLT4gYnVzIDAgZGV2IDE2IGZ1bmMgMQpBY3BpT3NEZXJpdmVQY2lJZDogXFxfU0JfLlBD STAuTUNIRC5NQ0gwIC0+IGJ1cyAwIGRldiAxNiBmdW5jIDAKQUNQSSB0aW1lcjogMS8xIDEvMSAx LzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIC0+IDEwClRpbWVjb3VudGVyICJBQ1BJLWZh c3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJp dCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDgwOC0weDgwYiBvbiBhY3BpMApwY2lfbGlu azA6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAg ICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAg ICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2IDcgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyAxMCAxMSAxMgpwY2lfbGluazE6ICAg ICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAg IDEwICAgTiAgICAgMCAgMyA0IDUgNiA3IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAgICAgICAw ICAgMTAgICBOICAgICAwICAzIDQgNSA2IDcgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxlICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyAxMCAxMSAxMgpwY2lfbGluazI6ICAgICAgICBJ bmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgICA1ICAg TiAgICAgMCAgMyA0IDUgNiA3IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgIDUg ICBOICAgICAwICAzIDQgNSA2IDcgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDMgNCA1IDYgNyAxMCAxMSAxMgpwY2lfbGluazM6ICAgICAgICBJbmRleCAg SVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgICA1ICAgTiAgICAg MCAgMyA0IDUgNiA3IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgIDUgICBOICAg ICAwICAzIDQgNSA2IDcgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDMgNCA1IDYgNyAxMCAxMSAxMgpwY2lfbGluazQ6ICAgICAgICBJbmRleCAgSVJRICBS dGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDEwICAgTiAgICAgMCAgMyA0 IDUgNiA3IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTAgICBOICAgICAwICAz IDQgNSA2IDcgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDMgNCA1IDYgNyAxMCAxMSAxMgpwY2lfbGluazU6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJl ZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNiA3 IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA2 IDcgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1 IDYgNyAxMCAxMSAxMgpwY2lfbGluazY6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJR cwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDEwIDEx IDEyCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgMTAg MTEgMTIKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyAx MCAxMSAxMgpwY2lfbGluazc6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIElu aXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDEwIDExIDEyCiAg VmFsaWRhdGlvbiAgICAgICAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgMTAgMTEgMTIK ICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyAxMCAxMSAx MgphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAw MDAtMHhmZWQwMDNmZiBvbiBhY3BpMAphY3BpX2hwZXQwOiB2ZW5kOiAweDgwODYgcmV2OiAweDEg bnVtOiAxIGh6OiAxNDMxODE4MCBvcHRzOiBsZWdfcm91dGUgY291bnRfc2l6ZQpUaW1lY291bnRl ciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTAwCmNwdTA6IDxBQ1BJIENQ VT4gb24gYWNwaTAKY3B1MDogc3dpdGNoaW5nIHRvIGdlbmVyaWMgQ3ggbW9kZQpjcHUxOiA8QUNQ SSBDUFU+IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgt MHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpMDogcGh5c2lj YWwgYnVzPTAKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNWMwLCByZXZpZD0weDEyCgli dXM9MCwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTAKCWNtZHJlZz0weDAxNDQsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykK CWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQoJaW50cGluPWEsIGlycT0yNTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3Vy cmVudCBEMAoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgyNWUyLCByZXZpZD0weDEyCglidXM9MCwgc2xvdD0yLCBmdW5jPTAKCWNsYXNzPTA2LTA0 LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAxNDcsIHN0YXRyZWc9MHgwMDEw LCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgw MyAoNzUwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTI1NQoJcG93ZXJz cGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMiBtZXNzYWdl cwpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI1ZTMsIHJldmlkPTB4MTIKCWJ1cz0wLCBz bG90PTMsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21k cmVnPTB4MDE0Nywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK CWludHBpbj1hLCBpcnE9MjU1Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQg RDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4 MjVmOCwgcmV2aWQ9MHgxMgoJYnVzPTAsIHNsb3Q9NCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwg aGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMTQ3LCBzdGF0cmVnPTB4MDAxMCwgY2Fj aGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDMgKDc1 MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0yNTUKCXBvd2Vyc3BlYyAy ICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMKZm91 bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNWU1LCByZXZpZD0weDEyCglidXM9MCwgc2xvdD01 LCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0w eDAxNDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4 MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJcG93ZXJz cGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMiBtZXNzYWdl cwpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI1ZjksIHJldmlkPTB4MTIKCWJ1cz0wLCBz bG90PTYsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21k cmVnPTB4MDE0Nywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK CWludHBpbj1hLCBpcnE9MjU1Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQg RDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4 MjVlNywgcmV2aWQ9MHgxMgoJYnVzPTAsIHNsb3Q9NywgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwg aGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMTQ3LCBzdGF0cmVnPTB4MDAxMCwgY2Fj aGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3Vy cmVudCBEMAoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgyNWYwLCByZXZpZD0weDEyCglidXM9MCwgc2xvdD0xNiwgZnVuYz0wCgljbGFzcz0wNi0w MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAw MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgw MCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0w eDI1ZjAsIHJldmlkPTB4MTIKCWJ1cz0wLCBzbG90PTE2LCBmdW5jPTEKCWNsYXNzPTA2LTAwLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDAwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjVm MCwgcmV2aWQ9MHgxMgoJYnVzPTAsIHNsb3Q9MTYsIGZ1bmM9MgoJY2xhc3M9MDYtMDAtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNWYxLCBy ZXZpZD0weDEyCglidXM9MCwgc2xvdD0xNywgZnVuYz0wCgljbGFzcz0wNi0wMC0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAwMCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI1ZjMsIHJldmlk PTB4MTIKCWJ1cz0wLCBzbG90PTE5LCBmdW5jPTAKCWNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDAwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjVmNSwgcmV2aWQ9MHgx MgoJYnVzPTAsIHNsb3Q9MjEsIGZ1bmM9MAoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwg bWZkZXY9MAoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0wIChkd29y ZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNWY2LCByZXZpZD0weDEyCgli dXM9MCwgc2xvdD0yMiwgZnVuYz0wCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRl dj0wCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAwMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykK CWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI2OTAsIHJldmlkPTB4MDkKCWJ1cz0w LCBzbG90PTI4LCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTEK CWNtZHJlZz0weDAxNDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxh dHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMyAoNzUwIG5zKSwgbWF4bGF0PTB4MDAgKDAg bnMpCglpbnRwaW49YSwgaXJxPTI1NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJy ZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2 PTB4MjY4OCwgcmV2aWQ9MHgwOQoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MAoJY2xhc3M9MGMtMDMt MDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyODAs IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCW1hcFsyMF06IHR5 cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGNjZTAsIHNpemUgIDUsIGVuYWJsZWQKcGNpYjA6IG1h dGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQQpwY2liMDogc2xvdCAyOSBJTlRBIGhhcmR3aXJlZCB0 byBJUlEgMjEKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNjg5LCByZXZpZD0weDA5Cgli dXM9MCwgc2xvdD0yOSwgZnVuYz0xCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRl dj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykK CWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQoJaW50cGluPWIsIGlycT0xMAoJbWFwWzIwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAw MDAwY2NjMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5J TlRCCnBjaWIwOiBzbG90IDI5IElOVEIgaGFyZHdpcmVkIHRvIElSUSAyMApmb3VuZC0+CXZlbmRv cj0weDgwODYsIGRldj0weDI2OGEsIHJldmlkPTB4MDkKCWJ1cz0wLCBzbG90PTI5LCBmdW5jPTIK CWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0 YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyks IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YywgaXJxPTEx CgltYXBbMjBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBjY2EwLCBzaXplICA1LCBlbmFi bGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEMKcGNpYjA6IHNsb3QgMjkgSU5U QyBoYXJkd2lyZWQgdG8gSVJRIDIxCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjY4Yywg cmV2aWQ9MHgwOQoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9NwoJY2xhc3M9MGMtMDMtMjAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNiwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5z ej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBt YXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmYzkw MDAwMCwgc2l6ZSAxMCwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRB CnBjaWIwOiBzbG90IDI5IElOVEEgaGFyZHdpcmVkIHRvIElSUSAyMQpmb3VuZC0+CXZlbmRvcj0w eDgwODYsIGRldj0weDI0NGUsIHJldmlkPTB4ZDkKCWJ1cz0wLCBzbG90PTMwLCBmdW5jPTAKCWNs YXNzPTA2LTA0LTAxLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAxNDcsIHN0YXRy ZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDBiICgyNzUwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4 ODA4NiwgZGV2PTB4MjY3MCwgcmV2aWQ9MHgwOQoJYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9MAoJY2xh c3M9MDYtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDE0Nywgc3RhdHJl Zz0weDAyMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHg4MDg2 LCBkZXY9MHgyNjllLCByZXZpZD0weDA5CglidXM9MCwgc2xvdD0zMSwgZnVuYz0xCgljbGFzcz0w MS0wMS04YSwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4 MDI4OCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0yNTUKCW1hcFsy MF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGZjMDAsIHNpemUgIDQsIGVuYWJsZWQKcGNp YjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMi4wIG9uIHBjaTAKcGNpYjE6ICAg c2Vjb25kYXJ5IGJ1cyAgICAgNgpwY2liMTogICBzdWJvcmRpbmF0ZSBidXMgICAxMQpwY2liMTog ICBJL08gZGVjb2RlICAgICAgICAweGYwMDAtMHhmZmYKcGNpYjE6ICAgbWVtb3J5IGRlY29kZSAg ICAgMHhmMjAwMDAwMC0weGY3ZmZmZmZmCnBjaWIxOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZmZm MDAwMDAtMHhmZmZmZgpwY2k2OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2k2OiBwaHlzaWNh bCBidXM9Ngpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDM1MDAsIHJldmlkPTB4MDEKCWJ1 cz02LCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9 MQoJY21kcmVnPTB4MDE0Nywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJ bGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDA3ICgxNzUwIG5zKSwgbWF4bGF0PTB4MDAg KDAgbnMpCglpbnRwaW49YSwgaXJxPTI1NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBj dXJyZW50IEQwCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzUwYywgcmV2aWQ9MHgwMQoJ YnVzPTYsIHNsb3Q9MCwgZnVuYz0zCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRl dj0xCgljbWRyZWc9MHgwMTQ3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMp CglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDcgKDE3NTAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMApwY2liMjog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjAgb24gcGNpNgpwY2liMjogICBzZWNv bmRhcnkgYnVzICAgICA3CnBjaWIyOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEwCnBjaWIyOiAgIEkv TyBkZWNvZGUgICAgICAgIDB4ZjAwMC0weGZmZgpwY2liMjogICBtZW1vcnkgZGVjb2RlICAgICAw eGY0MDAwMDAwLTB4ZjdmZmZmZmYKcGNpYjI6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmZmYwMDAw MC0weGZmZmZmCnBjaTc6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCnBjaTc6IHBoeXNpY2FsIGJ1 cz03CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzUxMCwgcmV2aWQ9MHgwMQoJYnVzPTcs IHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCglj bWRyZWc9MHgwMTQ3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0 aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAwICgwIG5z KQoJaW50cGluPWEsIGlycT0yNTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVu dCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0CmZvdW5kLT4JdmVuZG9yPTB4ODA4 NiwgZGV2PTB4MzUxNCwgcmV2aWQ9MHgwMQoJYnVzPTcsIHNsb3Q9MSwgZnVuYz0wCgljbGFzcz0w Ni0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMTQ3LCBzdGF0cmVnPTB4 MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0yNTUKCXBv d2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVz c2FnZSwgNjQgYml0CnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDAuMCBv biBwY2k3CnBjaWIzOiAgIHNlY29uZGFyeSBidXMgICAgIDgKcGNpYjM6ICAgc3Vib3JkaW5hdGUg YnVzICAgOQpwY2liMzogICBJL08gZGVjb2RlICAgICAgICAweGYwMDAtMHhmZmYKcGNpYjM6ICAg bWVtb3J5IGRlY29kZSAgICAgMHhmNDAwMDAwMC0weGY3ZmZmZmZmCnBjaWIzOiAgIHByZWZldGNo ZWQgZGVjb2RlIDB4ZmZmMDAwMDAtMHhmZmZmZgpwY2k4OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li MwpwY2k4OiBwaHlzaWNhbCBidXM9OApmb3VuZC0+CXZlbmRvcj0weDExNjYsIGRldj0weDAxMDMs IHJldmlkPTB4YzIKCWJ1cz04LCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5 cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDE0Nywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5z ej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDA2ICgxNTAwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJl bnQgRDAKcGNpYjQ6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDAuMCBvbiBwY2k4CnBjaWI0 OiAgIHNlY29uZGFyeSBidXMgICAgIDkKcGNpYjQ6ICAgc3Vib3JkaW5hdGUgYnVzICAgOQpwY2li NDogICBJL08gZGVjb2RlICAgICAgICAweGYwMDAtMHhmZmYKcGNpYjQ6ICAgbWVtb3J5IGRlY29k ZSAgICAgMHhmNDAwMDAwMC0weGY3ZmZmZmZmCnBjaWI0OiAgIHByZWZldGNoZWQgZGVjb2RlIDB4 ZmZmMDAwMDAtMHhmZmZmZgpwY2k5OiA8UENJIGJ1cz4gb24gcGNpYjQKcGNpOTogcGh5c2ljYWwg YnVzPTkKZm91bmQtPgl2ZW5kb3I9MHgxNGU0LCBkZXY9MHgxNjRjLCByZXZpZD0weDExCglidXM9 OSwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAK CWNtZHJlZz0weDAxNWUsIHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxh dHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHg0MCAoMTYwMDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAg Y3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0CgltYXBbMTBdOiB0eXBl IDEsIHJhbmdlIDY0LCBiYXNlIGY0MDAwMDAwLCBzaXplIDI1LCBlbmFibGVkCnBjaWI0OiByZXF1 ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZjQwMDAwMDAtMHhmNWZmZmZmZjogZ29vZApwY2liMzogcmVx dWVzdGVkIG1lbW9yeSByYW5nZSAweGY0MDAwMDAwLTB4ZjVmZmZmZmY6IGdvb2QKcGNpYjI6IHJl cXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmNDAwMDAwMC0weGY1ZmZmZmZmOiBnb29kCnBjaWIxOiBy ZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZjQwMDAwMDAtMHhmNWZmZmZmZjogZ29vZApwY2liMzog bWF0Y2hlZCBlbnRyeSBmb3IgOC4wLklOVEEKcGNpYjM6IHNsb3QgMCBJTlRBIGhhcmR3aXJlZCB0 byBJUlEgMTYKcGNpYjQ6IHNsb3QgMCBJTlRBIGlzIHJvdXRlZCB0byBpcnEgMTYKYmNlMDogPEJy b2FkY29tIE5ldFh0cmVtZSBJSSBCQ001NzA4IDEwMDBCYXNlLVQgKEIxKT4gbWVtIDB4ZjQwMDAw MDAtMHhmNWZmZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2k5CmJjZTA6IFJlc2VydmVk IDB4MjAwMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZjQwMDAwMDAKbWlpYnVz MDogPE1JSSBidXM+IG9uIGJjZTAKYnJncGh5MDogPEJDTTU3MDhDIDEwLzEwMC8xMDAwYmFzZVRY IFBIWT4gb24gbWlpYnVzMApicmdwaHkwOiBPVUkgMHgwMDA4MTgsIG1vZGVsIDB4MDAzNiwgcmV2 LiA1CmJyZ3BoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgt RkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1GRFgsIGF1dG8KYmNlMDogYnBmIGF0dGFjaGVkCmJj ZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjE4OjhiOjc1OjFkOmUwCmlvYXBpYzA6IHJvdXRpbmcg aW50cGluIDE2IChQQ0kgSVJRIDE2KSB0byB2ZWN0b3IgNDkKYmNlMDogW01QU0FGRV0KYmNlMDog QVNJQyAoMHg1NzA4MTAxMCk7IFJldiAoQjEpOyBCdXMgKFBDSS1YLCA2NC1iaXQsIDEzM01Ieik7 IEYvVyAoMHgwMTA4MDAwNSk7IEZsYWdzKCBNRlcgKQpwY2liNTogPEFDUEkgUENJLVBDSSBicmlk Z2U+IGF0IGRldmljZSAxLjAgb24gcGNpNwpwY2liNTogICBzZWNvbmRhcnkgYnVzICAgICAxMApw Y2liNTogICBzdWJvcmRpbmF0ZSBidXMgICAxMApwY2liNTogICBJL08gZGVjb2RlICAgICAgICAw eGYwMDAtMHhmZmYKcGNpYjU6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmZmYwMDAwMC0weGZmZmZm CnBjaWI1OiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZmZmMDAwMDAtMHhmZmZmZgpwY2kxMDogPEFD UEkgUENJIGJ1cz4gb24gcGNpYjUKcGNpMTA6IHBoeXNpY2FsIGJ1cz0xMApwY2liNjogPFBDSS1Q Q0kgYnJpZGdlPiBhdCBkZXZpY2UgMC4zIG9uIHBjaTYKcGNpYjY6ICAgc2Vjb25kYXJ5IGJ1cyAg ICAgMTEKcGNpYjY6ICAgc3Vib3JkaW5hdGUgYnVzICAgMTEKcGNpYjY6ICAgSS9PIGRlY29kZSAg ICAgICAgMHhmMDAwLTB4ZmZmCnBjaWI2OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZmZmMDAwMDAt MHhmZmZmZgpwY2liNjogICBwcmVmZXRjaGVkIGRlY29kZSAweGZmZjAwMDAwLTB4ZmZmZmYKcGNp MTE6IDxQQ0kgYnVzPiBvbiBwY2liNgpwY2kxMTogcGh5c2ljYWwgYnVzPTExCnBjaWI3OiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMuMCBvbiBwY2kwCnBjaWI3OiAgIHNlY29uZGFy eSBidXMgICAgIDEKcGNpYjc6ICAgc3Vib3JkaW5hdGUgYnVzICAgMwpwY2liNzogICBJL08gZGVj b2RlICAgICAgICAweGYwMDAtMHhmZmYKcGNpYjc6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmYzYw MDAwMC0weGZjOGZmZmZmCnBjaWI3OiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZDgwMDAwMDAtMHhk ODBmZmZmZgpwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNwpwY2kxOiBwaHlzaWNhbCBidXM9 MQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDAzNzAsIHJldmlkPTB4MDAKCWJ1cz0xLCBz bG90PTAsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MQoJY21k cmVnPTB4MDE0Nywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDA2ICgxNTAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMp Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAx IG1lc3NhZ2UsIDY0IGJpdApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDAzNzIsIHJldmlk PTB4MDAKCWJ1cz0xLCBzbG90PTAsIGZ1bmM9MgoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgw MSwgbWZkZXY9MQoJY21kcmVnPTB4MDE0Nywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAo ZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDA2ICgxNTAwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAK CU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0IGJpdApwY2liODogPEFDUEkgUENJLVBDSSBicmlk Z2U+IGF0IGRldmljZSAwLjAgb24gcGNpMQpwY2liODogICBzZWNvbmRhcnkgYnVzICAgICAyCnBj aWI4OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDIKcGNpYjg6ICAgSS9PIGRlY29kZSAgICAgICAgMHhm MDAwLTB4ZmZmCnBjaWI4OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZmM3MDAwMDAtMHhmYzhmZmZm ZgpwY2liODogICBwcmVmZXRjaGVkIGRlY29kZSAweGQ4MDAwMDAwLTB4ZDgwZmZmZmYKcGNpMjog PEFDUEkgUENJIGJ1cz4gb24gcGNpYjgKcGNpMjogcGh5c2ljYWwgYnVzPTIKZm91bmQtPgl2ZW5k b3I9MHgxMDI4LCBkZXY9MHgwMDE1LCByZXZpZD0weDAwCglidXM9Miwgc2xvdD0xNCwgZnVuYz0w CgljbGFzcz0wMS0wNC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMWQ2LCBz dGF0cmVnPTB4MDIzMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDIwICg5NjAg bnMpLCBtaW5nbnQ9MHg4MCAoMzIwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1h LCBpcnE9NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQzICBjdXJyZW50IEQwCglNU0kg c3VwcG9ydHMgMiBtZXNzYWdlcywgNjQgYml0CgltYXBbMTBdOiB0eXBlIDMsIHJhbmdlIDMyLCBi YXNlIGQ4MGYwMDAwLCBzaXplIDE2LCBlbmFibGVkCnBjaWI4OiByZXF1ZXN0ZWQgbWVtb3J5IHJh bmdlIDB4ZDgwZjAwMDAtMHhkODBmZmZmZjogZ29vZApwY2liNzogcmVxdWVzdGVkIG1lbW9yeSBy YW5nZSAweGQ4MGYwMDAwLTB4ZDgwZmZmZmY6IGdvb2QKCW1hcFsxOF06IHR5cGUgMSwgcmFuZ2Ug MzIsIGJhc2UgZmM3ZTAwMDAsIHNpemUgMTcsIGVuYWJsZWQKcGNpYjg6IHJlcXVlc3RlZCBtZW1v cnkgcmFuZ2UgMHhmYzdlMDAwMC0weGZjN2ZmZmZmOiBnb29kCnBjaWI3OiByZXF1ZXN0ZWQgbWVt b3J5IHJhbmdlIDB4ZmM3ZTAwMDAtMHhmYzdmZmZmZjogZ29vZApwY2liODogbWF0Y2hlZCBlbnRy eSBmb3IgMi4xNC5JTlRBCnBjaWI4OiBzbG90IDE0IElOVEEgaGFyZHdpcmVkIHRvIElSUSA3OApt ZmkwOiA8RGVsbCBQRVJDIDUvaT4gbWVtIDB4ZDgwZjAwMDAtMHhkODBmZmZmZiwweGZjN2UwMDAw LTB4ZmM3ZmZmZmYgaXJxIDc4IGF0IGRldmljZSAxNC4wIG9uIHBjaTIKbWZpMDogUmVzZXJ2ZWQg MHgxMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZDgwZjAwMDAKbWZpMDogTWVn YXJhaWQgU0FTIGRyaXZlciBWZXIgMi4wMCAKbWZpMDogMzc4NCAoMjcwODc0NDg1cy8weDAwMjAv MCkgLSBTaHV0ZG93biBjb21tYW5kIHJlY2VpdmVkIGZyb20gaG9zdAptZmkwOiAzNzg1ICg0Mjc4 MTkwMDgwcy8weDAwMjAvMCkgLSBQQ0kgMHgwNDEwMjggMHgwNDE1IDB4MDQxMDI4IDB4MDQxZjAz OiBGaXJtd2FyZSBpbml0aWFsaXphdGlvbiBzdGFydGVkIChQQ0kgSUQgMDAxNS8xMDI4LzFmMDMv MTAyOCkKbWZpMDogMzc4NiAoNDI3ODE5MDA4MHMvMHgwMDIwLzApIC0gVHlwZSAxODogRmlybXdh cmUgdmVyc2lvbiAxLjAwLjAxLTAwODgKbWZpMDogMzc4NyAoNDI3ODE5MDEwNnMvMHgwMDA4LzAp IC0gQmF0dGVyeSBQcmVzZW50Cm1maTA6IDM3ODggKDQyNzgxOTAxMzRzLzB4MDAwNC8wKSAtIFBE IDA4KGUxL3MyNTUpIGV2ZW50OiBFbmNsb3N1cmUgKFNFUykgZGlzY292ZXJlZCBvbiBQRCAwOChl MS9zMjU1KQptZmkwOiAzNzg5ICg0Mjc4MTkwMTM0cy8weDAwMDIvMCkgLSBQRCAwOChlMS9zMjU1 KSBldmVudDogSW5zZXJ0ZWQ6IFBEIDA4KGUxL3MyNTUpCm1maTA6IDM3OTAgKDQyNzgxOTAxMzRz LzB4MDAwMi8wKSAtIFR5cGUgMjk6IEluc2VydGVkOiBQRCAwOChlMS9zMjU1KSBJbmZvOiBlbmNs UGQ9MDgsIHNjc2lUeXBlPWQsIHBvcnRNYXA9MDAsIHNhc0FkZHI9NTAwMTgwYjA0MDkwNmIwMCww MDAwMDAwMDAwMDAwMDAwCm1maTA6IDM3OTEgKDQyNzgxOTAxMzRzLzB4MDAwMi8wKSAtIFBEIDAw KGUxL3MwKSBldmVudDogSW5zZXJ0ZWQ6IFBEIDAwKGUxL3MwKQptZmkwOiAzNzkyICg0Mjc4MTkw MTM0cy8weDAwMDIvMCkgLSBUeXBlIDI5OiBJbnNlcnRlZDogUEQgMDAoZTEvczApIEluZm86IGVu Y2xQZD0wOCwgc2NzaVR5cGU9MCwgcG9ydE1hcD0wMSwgc2FzQWRkcj01MDAxMGI5MDAwMzkwZmVl LDAwMDAwMDAwMDAwMDAwMDAKbWZpMDogMzc5MyAoNDI3ODE5MDEzNHMvMHgwMDAyLzApIC0gUEQg MDEoZTEvczEpIGV2ZW50OiBJbnNlcnRlZDogUEQgMDEoZTEvczEpCm1maTA6IDM3OTQgKDQyNzgx OTAxMzRzLzB4MDAwMi8wKSAtIFR5cGUgMjk6IEluc2VydGVkOiBQRCAwMShlMS9zMSkgSW5mbzog ZW5jbFBkPTA4LCBzY3NpVHlwZT0wLCBwb3J0TWFwPTAyLCBzYXNBZGRyPTUwMDEwYjkwMDAzOTBm OGUsMDAwMDAwMDAwMDAwMDAwMAptZmkwOiAzNzk1ICgyNzA4NzQ1NTJzLzB4MDAyMC8wKSAtIEFk YXB0ZXIgdGlja3MgMjcwODc0NTUyIGVsYXBzZWQgNTVzOiBUaW1lIGVzdGFibGlzaGVkIGFzIDA4 LzAxLzA4ICAyOjU1OjUyOyAoNTUgc2Vjb25kcyBzaW5jZSBwb3dlciBvbikKaW9hcGljMTogcm91 dGluZyBpbnRwaW4gMTQgKFBDSSBJUlEgNzgpIHRvIHZlY3RvciA1MAptZmkwOiBbTVBTQUZFXQpw Y2liOTogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMC4yIG9uIHBjaTEKcGNpYjk6ICAgc2Vj b25kYXJ5IGJ1cyAgICAgMwpwY2liOTogICBzdWJvcmRpbmF0ZSBidXMgICAzCnBjaWI5OiAgIEkv TyBkZWNvZGUgICAgICAgIDB4ZjAwMC0weGZmZgpwY2liOTogICBtZW1vcnkgZGVjb2RlICAgICAw eGZmZjAwMDAwLTB4ZmZmZmYKcGNpYjk6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmZmYwMDAwMC0w eGZmZmZmCnBjaTM6IDxQQ0kgYnVzPiBvbiBwY2liOQpwY2kzOiBwaHlzaWNhbCBidXM9MwpwY2li MTA6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNC4wIG9uIHBjaTAKcGNpYjEwOiAg IHNlY29uZGFyeSBidXMgICAgIDEyCnBjaWIxMDogICBzdWJvcmRpbmF0ZSBidXMgICAxMgpwY2li MTA6ICAgSS9PIGRlY29kZSAgICAgICAgMHhmMDAwLTB4ZmZmCnBjaWIxMDogICBtZW1vcnkgZGVj b2RlICAgICAweGZmZjAwMDAwLTB4ZmZmZmYKcGNpYjEwOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4 ZmZmMDAwMDAtMHhmZmZmZgpwY2kxMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEwCnBjaTEyOiBw aHlzaWNhbCBidXM9MTIKcGNpYjExOiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA1LjAgb24g cGNpMApwY2liMTE6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMTMKcGNpYjExOiAgIHN1Ym9yZGluYXRl IGJ1cyAgIDEzCnBjaWIxMTogICBJL08gZGVjb2RlICAgICAgICAweGYwMDAtMHhmZmYKcGNpYjEx OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZmZmMDAwMDAtMHhmZmZmZgpwY2liMTE6ICAgcHJlZmV0 Y2hlZCBkZWNvZGUgMHhmZmYwMDAwMC0weGZmZmZmCnBjaTEzOiA8UENJIGJ1cz4gb24gcGNpYjEx CnBjaTEzOiBwaHlzaWNhbCBidXM9MTMKcGNpYjEyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQg ZGV2aWNlIDYuMCBvbiBwY2kwCnBjaWIxMjogICBzZWNvbmRhcnkgYnVzICAgICAxNApwY2liMTI6 ICAgc3Vib3JkaW5hdGUgYnVzICAgMTYKcGNpYjEyOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ZTAw MC0weGVmZmYKcGNpYjEyOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZmMzMDAwMDAtMHhmYzVmZmZm ZgpwY2liMTI6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmZmYwMDAwMC0weGZmZmZmCnBjaTE0OiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liMTIKcGNpMTQ6IHBoeXNpY2FsIGJ1cz0xNApmb3VuZC0+CXZl bmRvcj0weDgwODYsIGRldj0weDAzMjksIHJldmlkPTB4MDkKCWJ1cz0xNCwgc2xvdD0wLCBmdW5j PTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTEKCWNtZHJlZz0weDAxNDcs IHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAg bnMpLCBtaW5nbnQ9MHgwNiAoMTUwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJcG93ZXJzcGVj IDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlLCA2 NCBiaXQKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgwMzJhLCByZXZpZD0weDA5CglidXM9 MTQsIHNsb3Q9MCwgZnVuYz0yCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0x CgljbWRyZWc9MHgwMTQ3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDYgKDE1MDAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBv cnRzIDEgbWVzc2FnZSwgNjQgYml0CnBjaWIxMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSAwLjAgb24gcGNpMTQKcGNpYjEzOiAgIHNlY29uZGFyeSBidXMgICAgIDE1CnBjaWIxMzog ICBzdWJvcmRpbmF0ZSBidXMgICAxNQpwY2liMTM6ICAgSS9PIGRlY29kZSAgICAgICAgMHhlMDAw LTB4ZWZmZgpwY2liMTM6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmYzQwMDAwMC0weGZjNWZmZmZm CnBjaWIxMzogICBwcmVmZXRjaGVkIGRlY29kZSAweGZmZjAwMDAwLTB4ZmZmZmYKcGNpMTU6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIxMwpwY2kxNTogcGh5c2ljYWwgYnVzPTE1CmZvdW5kLT4JdmVu ZG9yPTB4OTAwNSwgZGV2PTB4ODAxNiwgcmV2aWQ9MHgxMAoJYnVzPTE1LCBzbG90PTMsIGZ1bmM9 MAoJY2xhc3M9MDEtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDE1Nywg c3RhdHJlZz0weDA0MzAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTky MCBucyksIG1pbmdudD0weDI4ICgxMDAwMCBucyksIG1heGxhdD0weDE5ICg2MjUwIG5zKQoJaW50 cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglN U0kgc3VwcG9ydHMgMiBtZXNzYWdlcywgNjQgYml0CgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMy LCBiYXNlIDAwMDBlYzAwLCBzaXplICA4LCBlbmFibGVkCnBjaWIxMzogcmVxdWVzdGVkIEkvTyBy YW5nZSAweGVjMDAtMHhlY2ZmOiBpbiByYW5nZQpwY2liMTI6IHJlcXVlc3RlZCBJL08gcmFuZ2Ug MHhlYzAwLTB4ZWNmZjogaW4gcmFuZ2UKCW1hcFsxNF06IHR5cGUgMSwgcmFuZ2UgNjQsIGJhc2Ug ZmM0ZmUwMDAsIHNpemUgMTMsIGVuYWJsZWQKcGNpYjEzOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdl IDB4ZmM0ZmUwMDAtMHhmYzRmZmZmZjogZ29vZApwY2liMTI6IHJlcXVlc3RlZCBtZW1vcnkgcmFu Z2UgMHhmYzRmZTAwMC0weGZjNGZmZmZmOiBnb29kCgltYXBbMWNdOiB0eXBlIDQsIHJhbmdlIDMy LCBiYXNlIDAwMDBlODAwLCBzaXplICA4LCBlbmFibGVkCnBjaWIxMzogcmVxdWVzdGVkIEkvTyBy YW5nZSAweGU4MDAtMHhlOGZmOiBpbiByYW5nZQpwY2liMTI6IHJlcXVlc3RlZCBJL08gcmFuZ2Ug MHhlODAwLTB4ZThmZjogaW4gcmFuZ2UKcGNpYjEzOiBtYXRjaGVkIGVudHJ5IGZvciAxNS4zLklO VEEKcGNpYjEzOiBzbG90IDMgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2MApmb3VuZC0+CXZlbmRv cj0weDkwMDUsIGRldj0weDgwMTYsIHJldmlkPTB4MTAKCWJ1cz0xNSwgc2xvdD0zLCBmdW5jPTEK CWNsYXNzPTAxLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAxNTcsIHN0 YXRyZWc9MHgwNDMwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAg bnMpLCBtaW5nbnQ9MHgyOCAoMTAwMDAgbnMpLCBtYXhsYXQ9MHgxOSAoNjI1MCBucykKCWludHBp bj1iLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJ IHN1cHBvcnRzIDIgbWVzc2FnZXMsIDY0IGJpdAoJbWFwWzEwXTogdHlwZSA0LCByYW5nZSAzMiwg YmFzZSAwMDAwZTQwMCwgc2l6ZSAgOCwgZW5hYmxlZApwY2liMTM6IHJlcXVlc3RlZCBJL08gcmFu Z2UgMHhlNDAwLTB4ZTRmZjogaW4gcmFuZ2UKcGNpYjEyOiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4 ZTQwMC0weGU0ZmY6IGluIHJhbmdlCgltYXBbMTRdOiB0eXBlIDEsIHJhbmdlIDY0LCBiYXNlIGZj NGZjMDAwLCBzaXplIDEzLCBlbmFibGVkCnBjaWIxMzogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAw eGZjNGZjMDAwLTB4ZmM0ZmRmZmY6IGdvb2QKcGNpYjEyOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdl IDB4ZmM0ZmMwMDAtMHhmYzRmZGZmZjogZ29vZAoJbWFwWzFjXTogdHlwZSA0LCByYW5nZSAzMiwg YmFzZSAwMDAwZTAwMCwgc2l6ZSAgOCwgZW5hYmxlZApwY2liMTM6IHJlcXVlc3RlZCBJL08gcmFu Z2UgMHhlMDAwLTB4ZTBmZjogaW4gcmFuZ2UKcGNpYjEyOiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4 ZTAwMC0weGUwZmY6IGluIHJhbmdlCnBjaWIxMzogbWF0Y2hlZCBlbnRyeSBmb3IgMTUuMy5JTlRC CnBjaWIxMzogc2xvdCAzIElOVEIgaGFyZHdpcmVkIHRvIElSUSAxNjEKYWhkMDogPEFkYXB0ZWMg MzkzMjBBIFVsdHJhMzIwIFNDU0kgYWRhcHRlcj4gcG9ydCAweGVjMDAtMHhlY2ZmLDB4ZTgwMC0w eGU4ZmYgbWVtIDB4ZmM0ZmUwMDAtMHhmYzRmZmZmZiBpcnEgMTYwIGF0IGRldmljZSAzLjAgb24g cGNpMTUKYWhkMDogRGVmYXVsdGluZyB0byBNRU1JTyBvbgphaGQwOiBSZXNlcnZlZCAweDEwMCBi eXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4ZWMwMAphaGQwOiBSZXNlcnZlZCAweDEwMCBi eXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4ZTgwMAphaGQwOiBFbmFibGluZyAzOUJpdCBB ZGRyZXNzaW5nCmFoZDA6IFJlYWRpbmcgVlBEIGZyb20gU0VFUFJPTS4uLmFoZDA6IFZQRCBwYXJz aW5nIHN1Y2Nlc3NmdWwKYWhkMDogUmVhZGluZyBTRUVQUk9NLi4uZG9uZS4KYWhkMDogU1RQV0xF VkVMIGlzIG9uCmFoZDA6IE1hbnVhbCBQcmltYXJ5IFRlcm1pbmF0aW9uCmFoZDA6IE1hbnVhbCBT ZWNvbmRhcnkgVGVybWluYXRpb24KYWhkMDogUHJpbWFyeSBIaWdoIGJ5dGUgdGVybWluYXRpb24g RGlzYWJsZWQKYWhkMDogUHJpbWFyeSBMb3cgYnl0ZSB0ZXJtaW5hdGlvbiBFbmFibGVkCmFoZDA6 IFNlY29uZGFyeSBIaWdoIGJ5dGUgdGVybWluYXRpb24gRGlzYWJsZWQKYWhkMDogU2Vjb25kYXJ5 IExvdyBieXRlIHRlcm1pbmF0aW9uIERpc2FibGVkCmFoZDA6IERvd25sb2FkaW5nIFNlcXVlbmNl ciBQcm9ncmFtLi4uIDY5NyBpbnN0cnVjdGlvbnMgZG93bmxvYWRlZAphaGQwOiBGZWF0dXJlcyAw eDNjMTAxLCBCdWdzIDB4NzQwMDAyLCBGbGFncyAweDE0M2YxCmlvYXBpYzI6IHJvdXRpbmcgaW50 cGluIDAgKFBDSSBJUlEgMTYwKSB0byB2ZWN0b3IgNTEKYWhkMDogW0dJQU5ULUxPQ0tFRF0KYWlj NzkwMjogVWx0cmEzMjAgV2lkZSBDaGFubmVsIEEsIFNDU0kgSWQ9NywgUENJLVggMTAxLTEzM01o eiwgNTEyIFNDQnMKYWhkMTogPEFkYXB0ZWMgMzkzMjBBIFVsdHJhMzIwIFNDU0kgYWRhcHRlcj4g cG9ydCAweGU0MDAtMHhlNGZmLDB4ZTAwMC0weGUwZmYgbWVtIDB4ZmM0ZmMwMDAtMHhmYzRmZGZm ZiBpcnEgMTYxIGF0IGRldmljZSAzLjEgb24gcGNpMTUKYWhkMTogRGVmYXVsdGluZyB0byBNRU1J TyBvbgphaGQxOiBSZXNlcnZlZCAweDEwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4 ZTQwMAphaGQxOiBSZXNlcnZlZCAweDEwMCBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4 ZTAwMAphaGQxOiBFbmFibGluZyAzOUJpdCBBZGRyZXNzaW5nCmFoZDE6IFJlYWRpbmcgVlBEIGZy b20gU0VFUFJPTS4uLmFoZDE6IFZQRCBwYXJzaW5nIHN1Y2Nlc3NmdWwKYWhkMTogUmVhZGluZyBT RUVQUk9NLi4uZG9uZS4KYWhkMTogU1RQV0xFVkVMIGlzIG9uCmFoZDE6IE1hbnVhbCBQcmltYXJ5 IFRlcm1pbmF0aW9uCmFoZDE6IE1hbnVhbCBTZWNvbmRhcnkgVGVybWluYXRpb24KYWhkMTogUHJp bWFyeSBIaWdoIGJ5dGUgdGVybWluYXRpb24gRGlzYWJsZWQKYWhkMTogUHJpbWFyeSBMb3cgYnl0 ZSB0ZXJtaW5hdGlvbiBFbmFibGVkCmFoZDE6IFNlY29uZGFyeSBIaWdoIGJ5dGUgdGVybWluYXRp b24gRGlzYWJsZWQKYWhkMTogU2Vjb25kYXJ5IExvdyBieXRlIHRlcm1pbmF0aW9uIERpc2FibGVk CmFoZDE6IERvd25sb2FkaW5nIFNlcXVlbmNlciBQcm9ncmFtLi4uIDY5NyBpbnN0cnVjdGlvbnMg ZG93bmxvYWRlZAphaGQxOiBGZWF0dXJlcyAweDNjMTAxLCBCdWdzIDB4NzQwMDAyLCBGbGFncyAw eDE0M2YwCmlvYXBpYzI6IHJvdXRpbmcgaW50cGluIDEgKFBDSSBJUlEgMTYxKSB0byB2ZWN0b3Ig NTIKYWhkMTogW0dJQU5ULUxPQ0tFRF0KYWljNzkwMjogVWx0cmEzMjAgV2lkZSBDaGFubmVsIEIs IFNDU0kgSWQ9NywgUENJLVggMTAxLTEzM01oeiwgNTEyIFNDQnMKcGNpYjE0OiA8QUNQSSBQQ0kt UENJIGJyaWRnZT4gYXQgZGV2aWNlIDAuMiBvbiBwY2kxNApwY2liMTQ6ICAgc2Vjb25kYXJ5IGJ1 cyAgICAgMTYKcGNpYjE0OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDE2CnBjaWIxNDogICBJL08gZGVj b2RlICAgICAgICAweGYwMDAtMHhmZmYKcGNpYjE0OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZmZm MDAwMDAtMHhmZmZmZgpwY2liMTQ6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmZmYwMDAwMC0weGZm ZmZmCnBjaTE2OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMTQKcGNpMTY6IHBoeXNpY2FsIGJ1cz0x NgpwY2liMTU6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDcuMCBvbiBwY2kwCnBjaWIxNTog ICBzZWNvbmRhcnkgYnVzICAgICAxNwpwY2liMTU6ICAgc3Vib3JkaW5hdGUgYnVzICAgMTcKcGNp YjE1OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ZjAwMC0weGZmZgpwY2liMTU6ICAgbWVtb3J5IGRl Y29kZSAgICAgMHhmZmYwMDAwMC0weGZmZmZmCnBjaWIxNTogICBwcmVmZXRjaGVkIGRlY29kZSAw eGZmZjAwMDAwLTB4ZmZmZmYKcGNpMTc6IDxQQ0kgYnVzPiBvbiBwY2liMTUKcGNpMTc6IHBoeXNp Y2FsIGJ1cz0xNwpwY2liMTY6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMjguMCBv biBwY2kwCnBjaWIxNjogICBzZWNvbmRhcnkgYnVzICAgICA0CnBjaWIxNjogICBzdWJvcmRpbmF0 ZSBidXMgICA1CnBjaWIxNjogICBJL08gZGVjb2RlICAgICAgICAweGYwMDAtMHhmZmYKcGNpYjE2 OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZjgwMDAwMDAtMHhmYmZmZmZmZgpwY2liMTY6ICAgcHJl ZmV0Y2hlZCBkZWNvZGUgMHhmZmYwMDAwMC0weGZmZmZmCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWIxNgpwY2k0OiBwaHlzaWNhbCBidXM9NApmb3VuZC0+CXZlbmRvcj0weDExNjYsIGRldj0w eDAxMDMsIHJldmlkPTB4YzIKCWJ1cz00LCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAs IGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDE0Nywgc3RhdHJlZz0weDAwMTAsIGNh Y2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDA2ICgx NTAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMg IGN1cnJlbnQgRDAKcGNpYjE3OiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjAgb24gcGNp NApwY2liMTc6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgNQpwY2liMTc6ICAgc3Vib3JkaW5hdGUgYnVz ICAgNQpwY2liMTc6ICAgSS9PIGRlY29kZSAgICAgICAgMHhmMDAwLTB4ZmZmCnBjaWIxNzogICBt ZW1vcnkgZGVjb2RlICAgICAweGY4MDAwMDAwLTB4ZmJmZmZmZmYKcGNpYjE3OiAgIHByZWZldGNo ZWQgZGVjb2RlIDB4ZmZmMDAwMDAtMHhmZmZmZgpwY2k1OiA8UENJIGJ1cz4gb24gcGNpYjE3CnBj aTU6IHBoeXNpY2FsIGJ1cz01CmZvdW5kLT4JdmVuZG9yPTB4MTRlNCwgZGV2PTB4MTY0YywgcmV2 aWQ9MHgxMQoJYnVzPTUsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0w eDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTVlLCBzdGF0cmVnPTB4MDJiMCwgY2FjaGVsbnN6PTE2 IChkd29yZHMpCglsYXR0aW1lcj0weDIwICg5NjAgbnMpLCBtaW5nbnQ9MHg0MCAoMTYwMDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBw b3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0Cglt YXBbMTBdOiB0eXBlIDEsIHJhbmdlIDY0LCBiYXNlIGY4MDAwMDAwLCBzaXplIDI1LCBlbmFibGVk CnBjaWIxNzogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGY4MDAwMDAwLTB4ZjlmZmZmZmY6IGdv b2QKcGNpYjE2OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZjgwMDAwMDAtMHhmOWZmZmZmZjog Z29vZApwY2liMTY6IG1hdGNoZWQgZW50cnkgZm9yIDQuMC5JTlRBCnBjaWIxNjogc2xvdCAwIElO VEEgaGFyZHdpcmVkIHRvIElSUSAxNgpwY2liMTc6IHNsb3QgMCBJTlRBIGlzIHJvdXRlZCB0byBp cnEgMTYKYmNlMTogPEJyb2FkY29tIE5ldFh0cmVtZSBJSSBCQ001NzA4IDEwMDBCYXNlLVQgKEIx KT4gbWVtIDB4ZjgwMDAwMDAtMHhmOWZmZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2k1 CmJjZTE6IFJlc2VydmVkIDB4MjAwMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4 ZjgwMDAwMDAKbWlpYnVzMTogPE1JSSBidXM+IG9uIGJjZTEKYnJncGh5MTogPEJDTTU3MDhDIDEw LzEwMC8xMDAwYmFzZVRYIFBIWT4gb24gbWlpYnVzMQpicmdwaHkxOiBPVUkgMHgwMDA4MTgsIG1v ZGVsIDB4MDAzNiwgcmV2LiA1CmJyZ3BoeTE6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFz ZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1GRFgsIGF1dG8KYmNlMTog YnBmIGF0dGFjaGVkCmJjZTE6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjE4OjhiOjc1OjFkOmRlCmJj ZTE6IFtNUFNBRkVdCmJjZTE6IEFTSUMgKDB4NTcwODEwMTApOyBSZXYgKEIxKTsgQnVzIChQQ0kt WCwgNjQtYml0LCAxMzNNSHopOyBGL1cgKDB4MDEwODAwMDUpOyBGbGFncyggTUZXICkKdWhjaTA6 IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGNjZTAtMHhjY2ZmIGlycSAy MSBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwCnVoY2kwOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciBy aWQgMHgyMCB0eXBlIDQgYXQgMHhjY2UwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIxIChQQ0kg SVJRIDIxKSB0byB2ZWN0b3IgNTMKdWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IDxVSENJIChn ZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTAKdXNiMDogVVNCIHJldmlzaW9uIDEuMAp1 aHViMDogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRy IDEKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2kxOiA8 VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhjY2MwLTB4Y2NkZiBpcnEgMjAg YXQgZGV2aWNlIDI5LjEgb24gcGNpMAp1aGNpMTogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3Igcmlk IDB4MjAgdHlwZSA0IGF0IDB4Y2NjMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMCAoUENJIElS USAyMCkgdG8gdmVjdG9yIDU0CnVoY2kxOiBbR0lBTlQtTE9DS0VEXQp1c2IxOiA8VUhDSSAoZ2Vu ZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kxCnVzYjE6IFVTQiByZXZpc2lvbiAxLjAKdWh1 YjE6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAx CnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aGNpMjogPFVI Q0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4Y2NhMC0weGNjYmYgaXJxIDIxIGF0 IGRldmljZSAyOS4yIG9uIHBjaTAKdWhjaTI6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAw eDIwIHR5cGUgNCBhdCAweGNjYTAKdWhjaTI6IFtHSUFOVC1MT0NLRURdCnVzYjI6IDxVSENJIChn ZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTIKdXNiMjogVVNCIHJldmlzaW9uIDEuMAp1 aHViMjogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRy IDEKdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmVoY2kwOiA8 RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmYzkwMDAwMC0weGZjOTAw M2ZmIGlycSAyMSBhdCBkZXZpY2UgMjkuNyBvbiBwY2kwCmVoY2kwOiBSZXNlcnZlZCAweDQwMCBi eXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmM5MDAwMDAKZWhjaTA6IFtHSUFOVC1MT0NL RURdCnVzYjM6IEVIQ0kgdmVyc2lvbiAxLjAKdXNiMzogY29tcGFuaW9uIGNvbnRyb2xsZXJzLCAy IHBvcnRzIGVhY2g6IHVzYjAgdXNiMSB1c2IyCnVzYjM6IDxFSENJIChnZW5lcmljKSBVU0IgMi4w IGNvbnRyb2xsZXI+IG9uIGVoY2kwCnVzYjM6IFVTQiByZXZpc2lvbiAyLjAKdWh1YjM6IEludGVs IEVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxCnVodWIzOiA2 IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNDogdmVuZG9yIDB4MDRi NCBwcm9kdWN0IDB4NjU2MCwgY2xhc3MgOS8wLCByZXYgMi4wMC8wLjBiLCBhZGRyIDIKdWh1YjQ6 IG11bHRpcGxlIHRyYW5zYWN0aW9uIHRyYW5zbGF0b3JzCnVodWI0OiA0IHBvcnRzIHdpdGggNCBy ZW1vdmFibGUsIHNlbGYgcG93ZXJlZApwY2liMTg6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMzAuMCBvbiBwY2kwCnBjaWIxODogICBzZWNvbmRhcnkgYnVzICAgICAxOApwY2liMTg6 ICAgc3Vib3JkaW5hdGUgYnVzICAgMTgKcGNpYjE4OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ZDAw MC0weGRmZmYKcGNpYjE4OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZmMxMDAwMDAtMHhmYzJmZmZm ZgpwY2liMTg6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhkMDAwMDAwMC0weGQ3ZmZmZmZmCnBjaWIx ODogICBTdWJ0cmFjdGl2ZWx5IGRlY29kZWQgYnJpZGdlLgpwY2kxODogPEFDUEkgUENJIGJ1cz4g b24gcGNpYjE4CnBjaTE4OiBwaHlzaWNhbCBidXM9MTgKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBk ZXY9MHg1MTVlLCByZXZpZD0weDAyCglidXM9MTgsIHNsb3Q9MTMsIGZ1bmM9MAoJY2xhc3M9MDMt MDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDFhNywgc3RhdHJlZz0weDAy OTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgyMCAoOTYwIG5zKSwgbWluZ250 PTB4MDggKDIwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9NQoJcG93 ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBl IDMsIHJhbmdlIDMyLCBiYXNlIGQwMDAwMDAwLCBzaXplIDI3LCBlbmFibGVkCnBjaWIxODogcmVx dWVzdGVkIG1lbW9yeSByYW5nZSAweGQwMDAwMDAwLTB4ZDdmZmZmZmY6IGdvb2QKCW1hcFsxNF06 IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGRjMDAsIHNpemUgIDgsIGVuYWJsZWQKcGNpYjE4 OiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4ZGMwMC0weGRjZmY6IGluIHJhbmdlCgltYXBbMThdOiB0 eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGZjMWYwMDAwLCBzaXplIDE2LCBlbmFibGVkCnBjaWIxODog cmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGZjMWYwMDAwLTB4ZmMxZmZmZmY6IGdvb2QKcGNpYjE4 OiBtYXRjaGVkIGVudHJ5IGZvciAxOC4xMy5JTlRBCnBjaWIxODogc2xvdCAxMyBJTlRBIGhhcmR3 aXJlZCB0byBJUlEgMTkKcGNpMTg6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSAxMy4wIChubyBk cml2ZXIgYXR0YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9u IHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCA2M1hYRVNCMiBV RE1BMTAwIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgz NzYsMHhmYzAwLTB4ZmMwZiBhdCBkZXZpY2UgMzEuMSBvbiBwY2kwCmF0YXBjaTA6IFJlc2VydmVk IDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGZjMDAKYXRhMDogPEFUQSBjaGFu bmVsIDA+IG9uIGF0YXBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgx MCB0eXBlIDQgYXQgMHgxZjAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgxIGJ5dGVzIGZvciByaWQgMHgx NCB0eXBlIDQgYXQgMHgzZjYKYXRhMDogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTUwIG9zdGF0 MT0wMAphdGEwOiBzdGF0MD0weDUwIGVycj0weDAxIGxzYj0weDE0IG1zYj0weGViCmF0YTA6IHN0 YXQxPTB4MDAgZXJyPTB4MDQgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMDogcmVzZXQgdHAyIHN0YXQw PTUwIHN0YXQxPTAwIGRldmljZXM9MHg0PEFUQVBJX01BU1RFUj4KaW9hcGljMDogcm91dGluZyBp bnRwaW4gMTQgKElTQSBJUlEgMTQpIHRvIHZlY3RvciA1NQphdGEwOiBbTVBTQUZFXQphdGExOiA8 QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9y IHJpZCAweDE4IHR5cGUgNCBhdCAweDE3MAphdGFwY2kwOiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9y IHJpZCAweDFjIHR5cGUgNCBhdCAweDM3NgphdGExOiByZXNldCB0cDEgbWFzaz0wMCBvc3RhdDA9 ZmYgb3N0YXQxPWZmCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE1IChJU0EgSVJRIDE1KSB0byB2 ZWN0b3IgNTYKYXRhMTogW01QU0FGRV0KZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyPiBw b3J0IDB4M2YwLTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGFjcGkwCmZkYzA6IGljX3R5cGUg OTAgcGFydF9pZCA4MAppb2FwaWMwOiByb3V0aW5nIGludHBpbiA2IChJU0EgSVJRIDYpIHRvIHZl Y3RvciA1NwpmZGMwOiBbTVBTQUZFXQpmZGMwOiBbRkFTVF0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRy aXZlPiBvbiBmZGMwIGRyaXZlIDAKc2lvMDogY29uZmlndXJlZCBpcnEgNCBub3QgaW4gYml0bWFw IG9mIHByb2JlZCBpcnFzIDAKc2lvMDogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQKc2lvMDogaXJx IG1hcHM6IDAgMCAwIDAKc2lvMDogPDE2NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4 M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gYWNwaTAKc2lvMDogdHlwZSAxNjU1MEEKaW9h cGljMDogcm91dGluZyBpbnRwaW4gNCAoSVNBIElSUSA0KSB0byB2ZWN0b3IgNTgKc2lvMTogY29u ZmlndXJlZCBpcnEgMyBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMTogcG9ydCBt YXkgbm90IGJlIGVuYWJsZWQKc2lvMTogaXJxIG1hcHM6IDAgMCAwIDAKc2lvMTogPDE2NTUwQS1j b21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGFjcGkwCnNpbzE6 IHR5cGUgMTY1NTBBCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDMgKElTQSBJUlEgMykgdG8gdmVj dG9yIDU5CmFoY19pc2FfcHJvYmUgMDogaW9wb3J0IDB4YzAwIGFsbG9jIGZhaWxlZAphaGNfaXNh X3Byb2JlIDEyOiBpb3BvcnQgMHhjYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDEzOiBp b3BvcnQgMHhkYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDE0OiBpb3BvcnQgMHhlYzAw IGFsbG9jIGZhaWxlZApmZGM6IGZkYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnNpbzog c2lvMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKc2lvOiBzaW8xIGFscmVhZHkgZXhpc3Rz OyBza2lwcGluZyBpdApwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjAzCnBucF9p ZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyNDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVh ZF9Qb3J0IGF0IDI4MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMmMzCnBucF9p ZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzMDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVh ZF9Qb3J0IGF0IDM0MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzgzCnBucF9p ZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzYzMKUE5QIElkZW50aWZ5IGNvbXBsZXRlCnNj OiBzYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnZnYTogdmdhMCBhbHJlYWR5IGV4aXN0 czsgc2tpcHBpbmcgaXQKaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNhYmxpbmcgUG5QIGRldmljZXMK aXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIG5vbi1QblAgZGV2aWNlcwpvcm0wOiA8SVNBIE9w dGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4YzhmZmYsMHhjOTAwMC0weGM5ZmZmLDB4Y2Ew MDAtMHhjYjdmZiwweGVjMDAwLTB4ZWZmZmYgb24gaXNhMAphdGtiZGMwIGZhaWxlZCB0byBwcm9i ZSBhdCBwb3J0IDB4NjAgb24gaXNhMApwcGMwOiBjYW5ub3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5n ZQpwcGMwOiA8UGFyYWxsZWwgcG9ydD4gZmFpbGVkIHRvIHByb2JlIGF0IGlycSA3IG9uIGlzYTAK c2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2 IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgpzYzA6IGZiMCwga2JkMCwgdGVybWluYWwg ZW11bGF0b3I6IHNjIChzeXNjb25zIHRlcm1pbmFsKQpzaW8yOiBub3QgcHJvYmVkIChkaXNhYmxl ZCkKc2lvMzogbm90IHByb2JlZCAoZGlzYWJsZWQpCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0 IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKaXNhX3Byb2Jl X2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZpY2VzCnVrYmQwOiBKdXN0Y29tIFRlY2hub2xvZ3kg VVNCIEtWTSBTd2l0Y2gsIHJldiAxLjEwLzEuMDAsIGFkZHIgMiwgaWNsYXNzIDMvMQprYmQ6IG5l dyBhcnJheSBzaXplIDQKa2JkMSBhdCB1a2JkMAprYmQxOiB1a2JkMCwgZ2VuZXJpYyAoMCksIGNv bmZpZzoweDAsIGZsYWdzOjB4M2QwMDAwCnVtczA6IEp1c3Rjb20gVGVjaG5vbG9neSBVU0IgS1ZN IFN3aXRjaCwgcmV2IDEuMTAvMS4wMCwgYWRkciAyLCBpY2xhc3MgMy8xCnVtczA6IDUgYnV0dG9u cyBhbmQgWiBkaXIuCkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLgpSZWR1Y2luZyBrZXJu Lm1heHZub2RlcyAxMzI4MjQgLT4gMTAwMDAwCnByb2NmcyByZWdpc3RlcmVkCmxpbnByb2NmcyBy ZWdpc3RlcmVkCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1ZW5jeSAxNjYyNTI4MDcgaHoKVGltZWNv dW50ZXIgIlRTQyIgZnJlcXVlbmN5IDE5OTUwMzM1NDYgSHogcXVhbGl0eSAtMTAwClRpbWVjb3Vu dGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKTGludXggRUxGIGV4ZWMgaGFuZGxlciBpbnN0YWxs ZWQKbG8wOiBicGYgYXR0YWNoZWQKV2FpdGluZyAyMCBzZWNvbmRzIGZvciBTQ1NJIGRldmljZXMg dG8gc2V0dGxlCihub3BlcmlwaDphaGQwOjA6LTE6LTEpOiBTQ1NJIGJ1cyByZXNldCBkZWxpdmVy ZWQuIDAgU0NCcyBhYm9ydGVkLgoobm9wZXJpcGg6YWhkMTowOi0xOi0xKTogU0NTSSBidXMgcmVz ZXQgZGVsaXZlcmVkLiAwIFNDQnMgYWJvcnRlZC4KYXRhMC1tYXN0ZXI6IHBpbz1QSU80IHdkbWE9 V0RNQTIgdWRtYT1VRE1BMzMgY2FibGU9NDAgd2lyZQphY2QwOiBzZXR0aW5nIFBJTzQgb24gNjNY WEVTQjIgY2hpcAphY2QwOiBzZXR0aW5nIFVETUEzMyBvbiA2M1hYRVNCMiBjaGlwCmFjZDA6IDxU U1NUY29ycENELVJXL0RWRC1ST00gVFNMNDYyRC9ERTAxPiBDRFJXIGRyaXZlIGF0IGF0YTAgYXMg bWFzdGVyCmFjZDA6IHJlYWQgNDEzNEtCL3MgKDQxMzRLQi9zKSB3cml0ZSA0MTM0S0IvcyAoNDEz NEtCL3MpLCAxNTM2S0IgYnVmZmVyLCBVRE1BMzMKYWNkMDogUmVhZHM6IENEUiwgQ0RSVywgQ0RE QSBzdHJlYW0sIERWRFJPTSwgRFZEUiwgcGFja2V0CmFjZDA6IFdyaXRlczogQ0RSLCBDRFJXLCB0 ZXN0IHdyaXRlLCBidXJucHJvb2YKYWNkMDogQXVkaW86IHBsYXksIDI1NiB2b2x1bWUgbGV2ZWxz CmFjZDA6IE1lY2hhbmlzbTogZWplY3RhYmxlIHRyYXksIHVubG9ja2VkCmFjZDA6IE1lZGl1bTog bm8vYmxhbmsgZGlzYwptZmlkMDogPE1GSSBMb2dpY2FsIERpc2s+IG9uIG1maTAKbWZpZDA6IDEz OTM5Mk1CICgyODU0NzQ4MTYgc2VjdG9ycykgUkFJRCB2b2x1bWUgJycgaXMgb3B0aW1hbApHRU9N OiBuZXcgZGlzayBtZmlkMAptZmkwOiAzNzk2ICgyNzA4NzQ2MDhzLzB4MDAwOC8wKSAtIEJhdHRl cnkgdGVtcGVyYXR1cmUgaXMgbm9ybWFsCm1maTA6IDM3OTcgKDI3MDg3NDYwOHMvMHgwMDA4LzAp IC0gQmF0dGVyeSBzdGFydGVkIGNoYXJnaW5nCm1maTA6IDM3OTggKDI3MDg3NDYwOHMvMHgwMDA4 LzApIC0gQ3VycmVudCBjYXBhY2l0eSBvZiB0aGUgYmF0dGVyeSBpcyBhYm92ZSB0aHJlc2hvbGQK YWhkMDogU2VsZWN0aW9uIFRpbWVvdXQgb24gQToxMC4gMCBTQ0JzIGFib3J0ZWQKYWhkMTogU2Vs ZWN0aW9uIFRpbWVvdXQgb24gQTowLiAwIFNDQnMgYWJvcnRlZAphaGQwOiBTZWxlY3Rpb24gVGlt ZW91dCBvbiBBOjExLiAwIFNDQnMgYWJvcnRlZAphaGQxOiBTZWxlY3Rpb24gVGltZW91dCBvbiBB OjEuIDAgU0NCcyBhYm9ydGVkCmFoZDA6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6MC4gMCBTQ0Jz IGFib3J0ZWQKYWhkMTogU2VsZWN0aW9uIFRpbWVvdXQgb24gQToxMC4gMCBTQ0JzIGFib3J0ZWQK YWhkMDogU2VsZWN0aW9uIFRpbWVvdXQgb24gQToxLiAwIFNDQnMgYWJvcnRlZAphaGQxOiBTZWxl Y3Rpb24gVGltZW91dCBvbiBBOjExLiAwIFNDQnMgYWJvcnRlZAphaGQwOiBTZWxlY3Rpb24gVGlt ZW91dCBvbiBBOjIuIDAgU0NCcyBhYm9ydGVkCmFoZDE6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6 MTIuIDAgU0NCcyBhYm9ydGVkCmFoZDA6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6My4gMCBTQ0Jz IGFib3J0ZWQKYWhkMTogU2VsZWN0aW9uIFRpbWVvdXQgb24gQToxMy4gMCBTQ0JzIGFib3J0ZWQK YWhkMDogU2VsZWN0aW9uIFRpbWVvdXQgb24gQTo0LiAwIFNDQnMgYWJvcnRlZAphaGQxOiBTZWxl Y3Rpb24gVGltZW91dCBvbiBBOjE0LiAwIFNDQnMgYWJvcnRlZAphaGQwOiBTZWxlY3Rpb24gVGlt ZW91dCBvbiBBOjUuIDAgU0NCcyBhYm9ydGVkCmFoZDE6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6 MTUuIDAgU0NCcyBhYm9ydGVkCmFoZDE6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6Mi4gMCBTQ0Jz IGFib3J0ZWQKYWhkMDogU2VsZWN0aW9uIFRpbWVvdXQgb24gQTo4LiAwIFNDQnMgYWJvcnRlZAph aGQxOiBTZWxlY3Rpb24gVGltZW91dCBvbiBBOjMuIDAgU0NCcyBhYm9ydGVkCmFoZDA6IFNlbGVj dGlvbiBUaW1lb3V0IG9uIEE6OS4gMCBTQ0JzIGFib3J0ZWQKYWhkMTogU2VsZWN0aW9uIFRpbWVv dXQgb24gQTo0LiAwIFNDQnMgYWJvcnRlZAphaGQwOiBTZWxlY3Rpb24gVGltZW91dCBvbiBBOjEy LiAwIFNDQnMgYWJvcnRlZAphaGQxOiBTZWxlY3Rpb24gVGltZW91dCBvbiBBOjUuIDAgU0NCcyBh Ym9ydGVkCmFoZDA6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6MTMuIDAgU0NCcyBhYm9ydGVkCmFo ZDE6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6Ni4gMCBTQ0JzIGFib3J0ZWQKYWhkMDogU2VsZWN0 aW9uIFRpbWVvdXQgb24gQToxNC4gMCBTQ0JzIGFib3J0ZWQKYWhkMTogU2VsZWN0aW9uIFRpbWVv dXQgb24gQTo4LiAwIFNDQnMgYWJvcnRlZAphaGQwOiBTZWxlY3Rpb24gVGltZW91dCBvbiBBOjE1 LiAwIFNDQnMgYWJvcnRlZAphaGQxOiBTZWxlY3Rpb24gVGltZW91dCBvbiBBOjkuIDAgU0NCcyBh Ym9ydGVkCihhaGQwOkE6NjowKTogU2VuZGluZyBXRFRSIDEKKGFoZDA6QTo2OjApOiBSZWNlaXZl ZCBXRFRSIDEgZmlsdGVyZWQgdG8gMQphaGQwOiB0YXJnZXQgNiB1c2luZyAxNmJpdCB0cmFuc2Zl cnMKKGFoZDA6QTo2OjApOiBTZW5kaW5nIFNEVFIgcGVyaW9kIGEsIG9mZnNldCA3ZgooYWhkMDpB OjY6MCk6IFJlY2VpdmVkIFNEVFIgcGVyaW9kIGEsIG9mZnNldCAyMAoJRmlsdGVyZWQgdG8gcGVy aW9kIGEsIG9mZnNldCAyMAphaGQwOiB0YXJnZXQgNiBzeW5jaHJvbm91cyB3aXRoIHBlcmlvZCA9 IDB4YSwgb2Zmc2V0ID0gMHgyMAooYWhkMDpBOjY6MCk6IFNlbmRpbmcgV0RUUiAxCihhaGQwOkE6 NjowKTogUmVjZWl2ZWQgV0RUUiAxIGZpbHRlcmVkIHRvIDEKYWhkMDogdGFyZ2V0IDYgdXNpbmcg MTZiaXQgdHJhbnNmZXJzCihhaGQwOkE6NjowKTogU2VuZGluZyBTRFRSIHBlcmlvZCBhLCBvZmZz ZXQgMjAKKGFoZDA6QTo2OjApOiBSZWNlaXZlZCBTRFRSIHBlcmlvZCBhLCBvZmZzZXQgMjAKCUZp bHRlcmVkIHRvIHBlcmlvZCBhLCBvZmZzZXQgMjAKYWhkMDogdGFyZ2V0IDYgc3luY2hyb25vdXMg d2l0aCBwZXJpb2QgPSAweGEsIG9mZnNldCA9IDB4MjAKcGFzczAgYXQgYWhkMCBidXMgMCB0YXJn ZXQgNiBsdW4gMApwYXNzMDogPFNFQUdBVEUgREFUICAgIERBVDcyLTA1MiBBMTZFPiBSZW1vdmFi bGUgU2VxdWVudGlhbCBBY2Nlc3MgU0NTSS0zIGRldmljZSAKcGFzczA6IFNlcmlhbCBOdW1iZXIg SFYwREI1NwpwYXNzMDogODAuMDAwTUIvcyB0cmFuc2ZlcnMgKDQwLjAwME1Ieiwgb2Zmc2V0IDMy LCAxNmJpdCkKc2EwIGF0IGFoZDAgYnVzIDAgdGFyZ2V0IDYgbHVuIDAKc2EwOiA8U0VBR0FURSBE QVQgICAgREFUNzItMDUyIEExNkU+IFJlbW92YWJsZSBTZXF1ZW50aWFsIEFjY2VzcyBTQ1NJLTMg ZGV2aWNlIApzYTA6IFNlcmlhbCBOdW1iZXIgSFYwREI1NwpzYTA6IDgwLjAwME1CL3MgdHJhbnNm ZXJzICg0MC4wMDBNSHosIG9mZnNldCAzMiwgMTZiaXQpCkFUQSBQc2V1ZG9SQUlEIGxvYWRlZApT TVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKY3B1MSBBUDoKICAgICBJRDogMHgwMTAwMDAwMCAgIFZF UjogMHgwMDA1MDAxNCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6IDB4 MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFm ZgogIHRpbWVyOiAweDAwMDIwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAxMDAwMCBw Y206IDB4MDAwMTAwMDAKaW9hcGljMDogQXNzaWduaW5nIElTQSBJUlEgMyB0byBsb2NhbCBBUElD IDAKaW9hcGljMDogQXNzaWduaW5nIElTQSBJUlEgNCB0byBsb2NhbCBBUElDIDEKaW9hcGljMDog QXNzaWduaW5nIElTQSBJUlEgNiB0byBsb2NhbCBBUElDIDAKaW9hcGljMDogQXNzaWduaW5nIElT QSBJUlEgOSB0byBsb2NhbCBBUElDIDEKaW9hcGljMDogQXNzaWduaW5nIElTQSBJUlEgMTQgdG8g bG9jYWwgQVBJQyAwCmlvYXBpYzA6IEFzc2lnbmluZyBJU0EgSVJRIDE1IHRvIGxvY2FsIEFQSUMg MQppb2FwaWMwOiBBc3NpZ25pbmcgUENJIElSUSAxNiB0byBsb2NhbCBBUElDIDAKaW9hcGljMDog QXNzaWduaW5nIFBDSSBJUlEgMjAgdG8gbG9jYWwgQVBJQyAxCmlvYXBpYzA6IEFzc2lnbmluZyBQ Q0kgSVJRIDIxIHRvIGxvY2FsIEFQSUMgMAppb2FwaWMxOiBBc3NpZ25pbmcgUENJIElSUSA3OCB0 byBsb2NhbCBBUElDIDEKaW9hcGljMjogQXNzaWduaW5nIFBDSSBJUlEgMTYwIHRvIGxvY2FsIEFQ SUMgMAppb2FwaWMyOiBBc3NpZ25pbmcgUENJIElSUSAxNjEgdG8gbG9jYWwgQVBJQyAxClRyeWlu ZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvbWZpZDBzMWEKc3RhcnRfaW5pdDogdHJ5aW5n IC9zYmluL2luaXQKcGlkIDExMjIgKHNtYmQpLCB1aWQgMDogZXhpdGVkIG9uIHNpZ25hbCA2Cm1m aTA6IDM3OTkgKDI3MDg3NjM2M3MvMHgwMDA4LzApIC0gQmF0dGVyeSBjaGFyZ2UgY29tcGxldGUK cGlkIDEzNDIgKHNtYmQpLCB1aWQgMDogZXhpdGVkIG9uIHNpZ25hbCA2CnBpZCAxMzQzIChzbWJk KSwgdWlkIDA6IGV4aXRlZCBvbiBzaWduYWwgNgpwaWQgMTM0NSAoc21iZCksIHVpZCAwOiBleGl0 ZWQgb24gc2lnbmFsIDYKcGlkIDEzNDYgKHNtYmQpLCB1aWQgMDogZXhpdGVkIG9uIHNpZ25hbCA2 CnBpZCAxMzUwIChzbWJkKSwgdWlkIDA6IGV4aXRlZCBvbiBzaWduYWwgNgpwaWQgMTM1NyAoc21i ZCksIHVpZCAwOiBleGl0ZWQgb24gc2lnbmFsIDYKcGlkIDEzNTggKHNtYmQpLCB1aWQgMDogZXhp dGVkIG9uIHNpZ25hbCA2CnBpZCAxMzYxIChzbWJkKSwgdWlkIDA6IGV4aXRlZCBvbiBzaWduYWwg NgpwaWQgMTM3MyAoc21iZCksIHVpZCAwOiBleGl0ZWQgb24gc2lnbmFsIDYKcGlkIDEzNzQgKHNt YmQpLCB1aWQgMDogZXhpdGVkIG9uIHNpZ25hbCA2CnBpZCAxMzc1IChzbWJkKSwgdWlkIDA6IGV4 aXRlZCBvbiBzaWduYWwgNgpwaWQgMTM5MyAoc21iZCksIHVpZCAwOiBleGl0ZWQgb24gc2lnbmFs IDYKcGlkIDE0NDYgKHNtYmQpLCB1aWQgMDogZXhpdGVkIG9uIHNpZ25hbCA2CnBpZCAxNDYyIChz bWJkKSwgdWlkIDA6IGV4aXRlZCBvbiBzaWduYWwgNgpwaWQgMTQ2MyAoc21iZCksIHVpZCAwOiBl eGl0ZWQgb24gc2lnbmFsIDYKcGlkIDE0NjUgKHNtYmQpLCB1aWQgMDogZXhpdGVkIG9uIHNpZ25h bCA2CnBpZCAxNDk5IChzbWJkKSwgdWlkIDA6IGV4aXRlZCBvbiBzaWduYWwgNgpwaWQgMTUwNCAo c21iZCksIHVpZCAwOiBleGl0ZWQgb24gc2lnbmFsIDYKcGlkIDE1MDUgKHNtYmQpLCB1aWQgMDog ZXhpdGVkIG9uIHNpZ25hbCA2Cg== ------=_Part_11775_2907320.1217617634432 Content-Type: application/octet-stream; name=dmidecode.out Content-Transfer-Encoding: base64 X-Attachment-Id: f_fjd5tqd82 Content-Disposition: attachment; filename=dmidecode.out IyBkbWlkZWNvZGUgMi45ClNNQklPUyAyLjQgcHJlc2VudC4KNjIgc3RydWN0dXJlcyBvY2N1cHlp bmcgMzE2MSBieXRlcy4KVGFibGUgYXQgMHg3RkZCQzAwMC4KCkhhbmRsZSAweERBMDAsIERNSSB0 eXBlIDIxOCwgMTEgYnl0ZXMKT0VNLXNwZWNpZmljIFR5cGUKCUhlYWRlciBhbmQgRGF0YToKCQlE QSAwQiAwMCBEQSBCMiAwMCAxNyAwMCAwRSAyMCAwMAoKSGFuZGxlIDB4MDAwMCwgRE1JIHR5cGUg MCwgMjQgYnl0ZXMKQklPUyBJbmZvcm1hdGlvbgoJVmVuZG9yOiBEZWxsIEluYy4KCVZlcnNpb246 IDEuMi4wCglSZWxlYXNlIERhdGU6IDEwLzE4LzIwMDYKCUFkZHJlc3M6IDB4RjAwMDAKCVJ1bnRp bWUgU2l6ZTogNjQga0IKCVJPTSBTaXplOiAxMDI0IGtCCglDaGFyYWN0ZXJpc3RpY3M6CgkJSVNB IGlzIHN1cHBvcnRlZAoJCVBDSSBpcyBzdXBwb3J0ZWQKCQlQTlAgaXMgc3VwcG9ydGVkCgkJQklP UyBpcyB1cGdyYWRlYWJsZQoJCUJJT1Mgc2hhZG93aW5nIGlzIGFsbG93ZWQKCQlFU0NEIHN1cHBv cnQgaXMgYXZhaWxhYmxlCgkJQm9vdCBmcm9tIENEIGlzIHN1cHBvcnRlZAoJCVNlbGVjdGFibGUg Ym9vdCBpcyBzdXBwb3J0ZWQKCQlFREQgaXMgc3VwcG9ydGVkCgkJSmFwYW5lc2UgZmxvcHB5IGZv ciBUb3NoaWJhIDEuMiBNQiBpcyBzdXBwb3J0ZWQgKGludCAxM2gpCgkJNS4yNSIvMzYwIEtCIGZs b3BweSBzZXJ2aWNlcyBhcmUgc3VwcG9ydGVkIChpbnQgMTNoKQoJCTUuMjUiLzEuMiBNQiBmbG9w cHkgc2VydmljZXMgYXJlIHN1cHBvcnRlZCAoaW50IDEzaCkKCQkzLjUiLzcyMCBLQiBmbG9wcHkg c2VydmljZXMgYXJlIHN1cHBvcnRlZCAoaW50IDEzaCkKCQlQcmludCBzY3JlZW4gc2VydmljZSBp cyBzdXBwb3J0ZWQgKGludCA1aCkKCQk4MDQyIGtleWJvYXJkIHNlcnZpY2VzIGFyZSBzdXBwb3J0 ZWQgKGludCA5aCkKCQlTZXJpYWwgc2VydmljZXMgYXJlIHN1cHBvcnRlZCAoaW50IDE0aCkKCQlQ cmludGVyIHNlcnZpY2VzIGFyZSBzdXBwb3J0ZWQgKGludCAxN2gpCgkJQ0dBL21vbm8gdmlkZW8g c2VydmljZXMgYXJlIHN1cHBvcnRlZCAoaW50IDEwaCkKCQlBQ1BJIGlzIHN1cHBvcnRlZAoJCVVT QiBsZWdhY3kgaXMgc3VwcG9ydGVkCgkJQklPUyBib290IHNwZWNpZmljYXRpb24gaXMgc3VwcG9y dGVkCgkJRnVuY3Rpb24ga2V5LWluaXRpYXRlZCBuZXR3b3JrIGJvb3QgaXMgc3VwcG9ydGVkCgkJ VGFyZ2V0ZWQgY29udGVudCBkaXN0cmlidXRpb24gaXMgc3VwcG9ydGVkCglCSU9TIFJldmlzaW9u OiAyLjAKCkhhbmRsZSAweDAxMDAsIERNSSB0eXBlIDEsIDI3IGJ5dGVzClN5c3RlbSBJbmZvcm1h dGlvbgoJTWFudWZhY3R1cmVyOiBEZWxsIEluYy4KCVByb2R1Y3QgTmFtZTogUG93ZXJFZGdlIDI5 NTAKCVZlcnNpb246IE5vdCBTcGVjaWZpZWQKCVNlcmlhbCBOdW1iZXI6IDVINjQ0QzEKCVVVSUQ6 IDQ0NDU0QzRDLTQ4MDAtMTAzNi04MDM0LUI1QzA0RjM0NDMzMQoJV2FrZS11cCBUeXBlOiBQb3dl ciBTd2l0Y2gKCVNLVSBOdW1iZXI6IE5vdCBTcGVjaWZpZWQKCUZhbWlseTogTm90IFNwZWNpZmll ZAoKSGFuZGxlIDB4MDIwMCwgRE1JIHR5cGUgMiwgOSBieXRlcwpCYXNlIEJvYXJkIEluZm9ybWF0 aW9uCglNYW51ZmFjdHVyZXI6IERlbGwgSW5jLgoJUHJvZHVjdCBOYW1lOiAwUFIyNzgKCVZlcnNp b246IEEwMAoJU2VyaWFsIE51bWJlcjogLi5DTjcwODIxNkFOMDBBQS4KCkhhbmRsZSAweDAzMDAs IERNSSB0eXBlIDMsIDIxIGJ5dGVzCkNoYXNzaXMgSW5mb3JtYXRpb24KCU1hbnVmYWN0dXJlcjog RGVsbCBJbmMuCglUeXBlOiBSYWNrIE1vdW50IENoYXNzaXMKCUxvY2s6IFByZXNlbnQKCVZlcnNp b246IE5vdCBTcGVjaWZpZWQKCVNlcmlhbCBOdW1iZXI6IDVINjQ0QzEKCUFzc2V0IFRhZzogTm90 IFNwZWNpZmllZAoJQm9vdC11cCBTdGF0ZTogU2FmZQoJUG93ZXIgU3VwcGx5IFN0YXRlOiBTYWZl CglUaGVybWFsIFN0YXRlOiBTYWZlCglTZWN1cml0eSBTdGF0dXM6IFVua25vd24KCU9FTSBJbmZv cm1hdGlvbjogMHgwMDAwMDAwMAoJSGVpZ2h0OiAyIFUKCU51bWJlciBPZiBQb3dlciBDb3Jkczog VW5zcGVjaWZpZWQKCUNvbnRhaW5lZCBFbGVtZW50czogMAoKSGFuZGxlIDB4MDQwMCwgRE1JIHR5 cGUgNCwgNDAgYnl0ZXMKUHJvY2Vzc29yIEluZm9ybWF0aW9uCglTb2NrZXQgRGVzaWduYXRpb246 IENQVTEKCVR5cGU6IENlbnRyYWwgUHJvY2Vzc29yCglGYW1pbHk6IFhlb24KCU1hbnVmYWN0dXJl cjogSW50ZWwKCUlEOiBGNiAwNiAwMCAwMCBGRiBGQiBFQiBCRgoJU2lnbmF0dXJlOiBUeXBlIDAs IEZhbWlseSA2LCBNb2RlbCAxNSwgU3RlcHBpbmcgNgoJRmxhZ3M6CgkJRlBVIChGbG9hdGluZy1w b2ludCB1bml0IG9uLWNoaXApCgkJVk1FIChWaXJ0dWFsIG1vZGUgZXh0ZW5zaW9uKQoJCURFIChE ZWJ1Z2dpbmcgZXh0ZW5zaW9uKQoJCVBTRSAoUGFnZSBzaXplIGV4dGVuc2lvbikKCQlUU0MgKFRp bWUgc3RhbXAgY291bnRlcikKCQlNU1IgKE1vZGVsIHNwZWNpZmljIHJlZ2lzdGVycykKCQlQQUUg KFBoeXNpY2FsIGFkZHJlc3MgZXh0ZW5zaW9uKQoJCU1DRSAoTWFjaGluZSBjaGVjayBleGNlcHRp b24pCgkJQ1g4IChDTVBYQ0hHOCBpbnN0cnVjdGlvbiBzdXBwb3J0ZWQpCgkJQVBJQyAoT24tY2hp cCBBUElDIGhhcmR3YXJlIHN1cHBvcnRlZCkKCQlTRVAgKEZhc3Qgc3lzdGVtIGNhbGwpCgkJTVRS UiAoTWVtb3J5IHR5cGUgcmFuZ2UgcmVnaXN0ZXJzKQoJCVBHRSAoUGFnZSBnbG9iYWwgZW5hYmxl KQoJCU1DQSAoTWFjaGluZSBjaGVjayBhcmNoaXRlY3R1cmUpCgkJQ01PViAoQ29uZGl0aW9uYWwg bW92ZSBpbnN0cnVjdGlvbiBzdXBwb3J0ZWQpCgkJUEFUIChQYWdlIGF0dHJpYnV0ZSB0YWJsZSkK CQlQU0UtMzYgKDM2LWJpdCBwYWdlIHNpemUgZXh0ZW5zaW9uKQoJCUNMRlNIIChDTEZMVVNIIGlu c3RydWN0aW9uIHN1cHBvcnRlZCkKCQlEUyAoRGVidWcgc3RvcmUpCgkJQUNQSSAoQUNQSSBzdXBw b3J0ZWQpCgkJTU1YIChNTVggdGVjaG5vbG9neSBzdXBwb3J0ZWQpCgkJRlhTUiAoRmFzdCBmbG9h dGluZy1wb2ludCBzYXZlIGFuZCByZXN0b3JlKQoJCVNTRSAoU3RyZWFtaW5nIFNJTUQgZXh0ZW5z aW9ucykKCQlTU0UyIChTdHJlYW1pbmcgU0lNRCBleHRlbnNpb25zIDIpCgkJU1MgKFNlbGYtc25v b3ApCgkJSFRUIChIeXBlci10aHJlYWRpbmcgdGVjaG5vbG9neSkKCQlUTSAoVGhlcm1hbCBtb25p dG9yIHN1cHBvcnRlZCkKCQlQQkUgKFBlbmRpbmcgYnJlYWsgZW5hYmxlZCkKCVZlcnNpb246IElu dGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAgICAgNTEzMCAgQCAyLjAwR0h6CglWb2x0YWdlOiAx LjQgVgoJRXh0ZXJuYWwgQ2xvY2s6IDEzMzMgTUh6CglNYXggU3BlZWQ6IDM2MDAgTUh6CglDdXJy ZW50IFNwZWVkOiAyMDAwIE1IegoJU3RhdHVzOiBQb3B1bGF0ZWQsIEVuYWJsZWQKCVVwZ3JhZGU6 IFNvY2tldCBMR0E3NzEKCUwxIENhY2hlIEhhbmRsZTogMHgwNzAwCglMMiBDYWNoZSBIYW5kbGU6 IDB4MDcwMQoJTDMgQ2FjaGUgSGFuZGxlOiAweDA3MDIKCVNlcmlhbCBOdW1iZXI6IE5vdCBTcGVj aWZpZWQKCUFzc2V0IFRhZzogTm90IFNwZWNpZmllZAoJUGFydCBOdW1iZXI6IE5vdCBTcGVjaWZp ZWQKCUNvcmUgQ291bnQ6IDIKCUNvcmUgRW5hYmxlZDogMgoJVGhyZWFkIENvdW50OiAyCglDaGFy YWN0ZXJpc3RpY3M6CgkJNjQtYml0IGNhcGFibGUKCkhhbmRsZSAweDA0MDEsIERNSSB0eXBlIDQs IDQwIGJ5dGVzClByb2Nlc3NvciBJbmZvcm1hdGlvbgoJU29ja2V0IERlc2lnbmF0aW9uOiBDUFUy CglUeXBlOiBDZW50cmFsIFByb2Nlc3NvcgoJRmFtaWx5OiBYZW9uCglNYW51ZmFjdHVyZXI6IElu dGVsCglJRDogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAKCVNpZ25hdHVyZTogVHlwZSAwLCBGYW1p bHkgMCwgTW9kZWwgMCwgU3RlcHBpbmcgMAoJRmxhZ3M6IE5vbmUKCVZlcnNpb246IE5vdCBTcGVj aWZpZWQKCVZvbHRhZ2U6IDEuNCBWCglFeHRlcm5hbCBDbG9jazogVW5rbm93bgoJTWF4IFNwZWVk OiAzNjAwIE1IegoJQ3VycmVudCBTcGVlZDogVW5rbm93bgoJU3RhdHVzOiBVbnBvcHVsYXRlZAoJ VXBncmFkZTogU29ja2V0IExHQTc3MQoJTDEgQ2FjaGUgSGFuZGxlOiAweDA3MDMKCUwyIENhY2hl IEhhbmRsZTogMHgwNzA0CglMMyBDYWNoZSBIYW5kbGU6IDB4MDcwNQoJU2VyaWFsIE51bWJlcjog Tm90IFNwZWNpZmllZAoJQXNzZXQgVGFnOiBOb3QgU3BlY2lmaWVkCglQYXJ0IE51bWJlcjogTm90 IFNwZWNpZmllZAoJQ2hhcmFjdGVyaXN0aWNzOgoJCTY0LWJpdCBjYXBhYmxlCgpIYW5kbGUgMHgw NzAwLCBETUkgdHlwZSA3LCAxOSBieXRlcwpDYWNoZSBJbmZvcm1hdGlvbgoJU29ja2V0IERlc2ln bmF0aW9uOiBOb3QgU3BlY2lmaWVkCglDb25maWd1cmF0aW9uOiBFbmFibGVkLCBOb3QgU29ja2V0 ZWQsIExldmVsIDEKCU9wZXJhdGlvbmFsIE1vZGU6IFdyaXRlIEJhY2sKCUxvY2F0aW9uOiBJbnRl cm5hbAoJSW5zdGFsbGVkIFNpemU6IDY0IEtCCglNYXhpbXVtIFNpemU6IDY0IEtCCglTdXBwb3J0 ZWQgU1JBTSBUeXBlczoKCQlVbmtub3duCglJbnN0YWxsZWQgU1JBTSBUeXBlOiBVbmtub3duCglT cGVlZDogVW5rbm93bgoJRXJyb3IgQ29ycmVjdGlvbiBUeXBlOiBTaW5nbGUtYml0IEVDQwoJU3lz dGVtIFR5cGU6IERhdGEKCUFzc29jaWF0aXZpdHk6IDgtd2F5IFNldC1hc3NvY2lhdGl2ZQoKSGFu ZGxlIDB4MDcwMSwgRE1JIHR5cGUgNywgMTkgYnl0ZXMKQ2FjaGUgSW5mb3JtYXRpb24KCVNvY2tl dCBEZXNpZ25hdGlvbjogTm90IFNwZWNpZmllZAoJQ29uZmlndXJhdGlvbjogRW5hYmxlZCwgTm90 IFNvY2tldGVkLCBMZXZlbCAyCglPcGVyYXRpb25hbCBNb2RlOiBXcml0ZSBCYWNrCglMb2NhdGlv bjogSW50ZXJuYWwKCUluc3RhbGxlZCBTaXplOiA0MDk2IEtCCglNYXhpbXVtIFNpemU6IDQwOTYg S0IKCVN1cHBvcnRlZCBTUkFNIFR5cGVzOgoJCVVua25vd24KCUluc3RhbGxlZCBTUkFNIFR5cGU6 IFVua25vd24KCVNwZWVkOiBVbmtub3duCglFcnJvciBDb3JyZWN0aW9uIFR5cGU6IFNpbmdsZS1i aXQgRUNDCglTeXN0ZW0gVHlwZTogVW5pZmllZAoJQXNzb2NpYXRpdml0eTogMTYtd2F5IFNldC1h c3NvY2lhdGl2ZQoKSGFuZGxlIDB4MDcwMiwgRE1JIHR5cGUgNywgMTkgYnl0ZXMKQ2FjaGUgSW5m b3JtYXRpb24KCVNvY2tldCBEZXNpZ25hdGlvbjogTm90IFNwZWNpZmllZAoJQ29uZmlndXJhdGlv bjogRW5hYmxlZCwgTm90IFNvY2tldGVkLCBMZXZlbCAzCglPcGVyYXRpb25hbCBNb2RlOiBXcml0 ZSBCYWNrCglMb2NhdGlvbjogSW50ZXJuYWwKCUluc3RhbGxlZCBTaXplOiAwIEtCCglNYXhpbXVt IFNpemU6IDAgS0IKCVN1cHBvcnRlZCBTUkFNIFR5cGVzOgoJCVVua25vd24KCUluc3RhbGxlZCBT UkFNIFR5cGU6IFVua25vd24KCVNwZWVkOiBVbmtub3duCglFcnJvciBDb3JyZWN0aW9uIFR5cGU6 IFNpbmdsZS1iaXQgRUNDCglTeXN0ZW0gVHlwZTogVW5pZmllZAoJQXNzb2NpYXRpdml0eTogVW5r bm93bgoKSGFuZGxlIDB4MDcwMywgRE1JIHR5cGUgNywgMTkgYnl0ZXMKQ2FjaGUgSW5mb3JtYXRp b24KCVNvY2tldCBEZXNpZ25hdGlvbjogTm90IFNwZWNpZmllZAoJQ29uZmlndXJhdGlvbjogRW5h YmxlZCwgTm90IFNvY2tldGVkLCBMZXZlbCAxCglPcGVyYXRpb25hbCBNb2RlOiBXcml0ZSBUaHJv dWdoCglMb2NhdGlvbjogSW50ZXJuYWwKCUluc3RhbGxlZCBTaXplOiAwIEtCCglNYXhpbXVtIFNp emU6IDE2IEtCCglTdXBwb3J0ZWQgU1JBTSBUeXBlczoKCQlVbmtub3duCglJbnN0YWxsZWQgU1JB TSBUeXBlOiBVbmtub3duCglTcGVlZDogVW5rbm93bgoJRXJyb3IgQ29ycmVjdGlvbiBUeXBlOiBQ YXJpdHkKCVN5c3RlbSBUeXBlOiBEYXRhCglBc3NvY2lhdGl2aXR5OiA8T1VUIE9GIFNQRUM+CgpI YW5kbGUgMHgwNzA0LCBETUkgdHlwZSA3LCAxOSBieXRlcwpDYWNoZSBJbmZvcm1hdGlvbgoJU29j a2V0IERlc2lnbmF0aW9uOiBOb3QgU3BlY2lmaWVkCglDb25maWd1cmF0aW9uOiBFbmFibGVkLCBO b3QgU29ja2V0ZWQsIExldmVsIDIKCU9wZXJhdGlvbmFsIE1vZGU6IFdyaXRlIEJhY2sKCUxvY2F0 aW9uOiBJbnRlcm5hbAoJSW5zdGFsbGVkIFNpemU6IDAgS0IKCU1heGltdW0gU2l6ZTogMjA0OCBL QgoJU3VwcG9ydGVkIFNSQU0gVHlwZXM6CgkJVW5rbm93bgoJSW5zdGFsbGVkIFNSQU0gVHlwZTog VW5rbm93bgoJU3BlZWQ6IFVua25vd24KCUVycm9yIENvcnJlY3Rpb24gVHlwZTogU2luZ2xlLWJp dCBFQ0MKCVN5c3RlbSBUeXBlOiBVbmlmaWVkCglBc3NvY2lhdGl2aXR5OiA8T1VUIE9GIFNQRUM+ CgpIYW5kbGUgMHgwNzA1LCBETUkgdHlwZSA3LCAxOSBieXRlcwpDYWNoZSBJbmZvcm1hdGlvbgoJ U29ja2V0IERlc2lnbmF0aW9uOiBOb3QgU3BlY2lmaWVkCglDb25maWd1cmF0aW9uOiBFbmFibGVk LCBOb3QgU29ja2V0ZWQsIExldmVsIDMKCU9wZXJhdGlvbmFsIE1vZGU6IFdyaXRlIEJhY2sKCUxv Y2F0aW9uOiBJbnRlcm5hbAoJSW5zdGFsbGVkIFNpemU6IDAgS0IKCU1heGltdW0gU2l6ZTogMCBL QgoJU3VwcG9ydGVkIFNSQU0gVHlwZXM6CgkJVW5rbm93bgoJSW5zdGFsbGVkIFNSQU0gVHlwZTog VW5rbm93bgoJU3BlZWQ6IFVua25vd24KCUVycm9yIENvcnJlY3Rpb24gVHlwZTogU2luZ2xlLWJp dCBFQ0MKCVN5c3RlbSBUeXBlOiBVbmlmaWVkCglBc3NvY2lhdGl2aXR5OiA8T1VUIE9GIFNQRUM+ CgpIYW5kbGUgMHgwODAwLCBETUkgdHlwZSA4LCA5IGJ5dGVzClBvcnQgQ29ubmVjdG9yIEluZm9y bWF0aW9uCglJbnRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogTm90IFNwZWNpZmllZAoJSW50 ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE5vbmUKCUV4dGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9y OiBOb3QgU3BlY2lmaWVkCglFeHRlcm5hbCBDb25uZWN0b3IgVHlwZTogREItMTUgZmVtYWxlCglQ b3J0IFR5cGU6IFZpZGVvIFBvcnQKCkhhbmRsZSAweDA4MDEsIERNSSB0eXBlIDgsIDkgYnl0ZXMK UG9ydCBDb25uZWN0b3IgSW5mb3JtYXRpb24KCUludGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9y OiBOb3QgU3BlY2lmaWVkCglJbnRlcm5hbCBDb25uZWN0b3IgVHlwZTogTm9uZQoJRXh0ZXJuYWwg UmVmZXJlbmNlIERlc2lnbmF0b3I6IE5vdCBTcGVjaWZpZWQKCUV4dGVybmFsIENvbm5lY3RvciBU eXBlOiBEQi0xNSBmZW1hbGUKCVBvcnQgVHlwZTogVmlkZW8gUG9ydAoKSGFuZGxlIDB4MDgwMiwg RE1JIHR5cGUgOCwgOSBieXRlcwpQb3J0IENvbm5lY3RvciBJbmZvcm1hdGlvbgoJSW50ZXJuYWwg UmVmZXJlbmNlIERlc2lnbmF0b3I6IE5vdCBTcGVjaWZpZWQKCUludGVybmFsIENvbm5lY3RvciBU eXBlOiBOb25lCglFeHRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogTm90IFNwZWNpZmllZAoJ RXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IEFjY2VzcyBCdXMgKFVTQikKCVBvcnQgVHlwZTogVVNC CgpIYW5kbGUgMHgwODAzLCBETUkgdHlwZSA4LCA5IGJ5dGVzClBvcnQgQ29ubmVjdG9yIEluZm9y bWF0aW9uCglJbnRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogTm90IFNwZWNpZmllZAoJSW50 ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE5vbmUKCUV4dGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9y OiBOb3QgU3BlY2lmaWVkCglFeHRlcm5hbCBDb25uZWN0b3IgVHlwZTogQWNjZXNzIEJ1cyAoVVNC KQoJUG9ydCBUeXBlOiBVU0IKCkhhbmRsZSAweDA4MDQsIERNSSB0eXBlIDgsIDkgYnl0ZXMKUG9y dCBDb25uZWN0b3IgSW5mb3JtYXRpb24KCUludGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9yOiBO b3QgU3BlY2lmaWVkCglJbnRlcm5hbCBDb25uZWN0b3IgVHlwZTogTm9uZQoJRXh0ZXJuYWwgUmVm ZXJlbmNlIERlc2lnbmF0b3I6IE5vdCBTcGVjaWZpZWQKCUV4dGVybmFsIENvbm5lY3RvciBUeXBl OiBBY2Nlc3MgQnVzIChVU0IpCglQb3J0IFR5cGU6IFVTQgoKSGFuZGxlIDB4MDgwNSwgRE1JIHR5 cGUgOCwgOSBieXRlcwpQb3J0IENvbm5lY3RvciBJbmZvcm1hdGlvbgoJSW50ZXJuYWwgUmVmZXJl bmNlIERlc2lnbmF0b3I6IE5vdCBTcGVjaWZpZWQKCUludGVybmFsIENvbm5lY3RvciBUeXBlOiBO b25lCglFeHRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogTm90IFNwZWNpZmllZAoJRXh0ZXJu YWwgQ29ubmVjdG9yIFR5cGU6IEFjY2VzcyBCdXMgKFVTQikKCVBvcnQgVHlwZTogVVNCCgpIYW5k bGUgMHgwODA2LCBETUkgdHlwZSAxMjYsIDkgYnl0ZXMKSW5hY3RpdmUKCkhhbmRsZSAweDA4MDcs IERNSSB0eXBlIDEyNiwgOSBieXRlcwpJbmFjdGl2ZQoKSGFuZGxlIDB4MDgwOCwgRE1JIHR5cGUg OCwgOSBieXRlcwpQb3J0IENvbm5lY3RvciBJbmZvcm1hdGlvbgoJSW50ZXJuYWwgUmVmZXJlbmNl IERlc2lnbmF0b3I6IE5vdCBTcGVjaWZpZWQKCUludGVybmFsIENvbm5lY3RvciBUeXBlOiBOb25l CglFeHRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogTm90IFNwZWNpZmllZAoJRXh0ZXJuYWwg Q29ubmVjdG9yIFR5cGU6IFJKLTQ1CglQb3J0IFR5cGU6IE5ldHdvcmsgUG9ydAoKSGFuZGxlIDB4 MDgwOSwgRE1JIHR5cGUgOCwgOSBieXRlcwpQb3J0IENvbm5lY3RvciBJbmZvcm1hdGlvbgoJSW50 ZXJuYWwgUmVmZXJlbmNlIERlc2lnbmF0b3I6IE5vdCBTcGVjaWZpZWQKCUludGVybmFsIENvbm5l Y3RvciBUeXBlOiBOb25lCglFeHRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogTm90IFNwZWNp ZmllZAoJRXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IFJKLTQ1CglQb3J0IFR5cGU6IE5ldHdvcmsg UG9ydAoKSGFuZGxlIDB4MDgwQSwgRE1JIHR5cGUgOCwgOSBieXRlcwpQb3J0IENvbm5lY3RvciBJ bmZvcm1hdGlvbgoJSW50ZXJuYWwgUmVmZXJlbmNlIERlc2lnbmF0b3I6IE5vdCBTcGVjaWZpZWQK CUludGVybmFsIENvbm5lY3RvciBUeXBlOiBOb25lCglFeHRlcm5hbCBSZWZlcmVuY2UgRGVzaWdu YXRvcjogTm90IFNwZWNpZmllZAoJRXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IERCLTkgbWFsZQoJ UG9ydCBUeXBlOiBTZXJpYWwgUG9ydCAxNjU1MEEgQ29tcGF0aWJsZQoKSGFuZGxlIDB4MDkwMCwg RE1JIHR5cGUgOSwgMTMgYnl0ZXMKU3lzdGVtIFNsb3QgSW5mb3JtYXRpb24KCURlc2lnbmF0aW9u OiBQQ0kxCglUeXBlOiB4OCBQQ0kgRXhwcmVzcwoJQ3VycmVudCBVc2FnZTogQXZhaWxhYmxlCglM ZW5ndGg6IExvbmcKCUlEOiAxCglDaGFyYWN0ZXJpc3RpY3M6CgkJMy4zIFYgaXMgcHJvdmlkZWQK CQlQTUUgc2lnbmFsIGlzIHN1cHBvcnRlZAoKSGFuZGxlIDB4MDkwMSwgRE1JIHR5cGUgOSwgMTMg Ynl0ZXMKU3lzdGVtIFNsb3QgSW5mb3JtYXRpb24KCURlc2lnbmF0aW9uOiBQQ0kyCglUeXBlOiA2 NC1iaXQgUENJLVgKCUN1cnJlbnQgVXNhZ2U6IEluIFVzZQoJTGVuZ3RoOiBMb25nCglJRDogMgoJ Q2hhcmFjdGVyaXN0aWNzOgoJCTMuMyBWIGlzIHByb3ZpZGVkCgkJUE1FIHNpZ25hbCBpcyBzdXBw b3J0ZWQKCkhhbmRsZSAweDA5MDIsIERNSSB0eXBlIDksIDEzIGJ5dGVzClN5c3RlbSBTbG90IElu Zm9ybWF0aW9uCglEZXNpZ25hdGlvbjogUENJMwoJVHlwZTogNjQtYml0IFBDSS1YCglDdXJyZW50 IFVzYWdlOiBBdmFpbGFibGUKCUxlbmd0aDogTG9uZwoJSUQ6IDMKCUNoYXJhY3RlcmlzdGljczoK CQkzLjMgViBpcyBwcm92aWRlZAoJCVBNRSBzaWduYWwgaXMgc3VwcG9ydGVkCgpIYW5kbGUgMHgw OTAzLCBETUkgdHlwZSAxMjYsIDEzIGJ5dGVzCkluYWN0aXZlCgpIYW5kbGUgMHgwOTA0LCBETUkg dHlwZSAxMjYsIDEzIGJ5dGVzCkluYWN0aXZlCgpIYW5kbGUgMHgwOTA1LCBETUkgdHlwZSAxMjYs IDEzIGJ5dGVzCkluYWN0aXZlCgpIYW5kbGUgMHgwQTAwLCBETUkgdHlwZSAxMCwgMTAgYnl0ZXMK T24gQm9hcmQgRGV2aWNlIDEgSW5mb3JtYXRpb24KCVR5cGU6IFZpZGVvCglTdGF0dXM6IEVuYWJs ZWQKCURlc2NyaXB0aW9uOiBFbWJlZGRlZCBBVEkgRVMxMDAwIFZpZGVvCk9uIEJvYXJkIERldmlj ZSAyIEluZm9ybWF0aW9uCglUeXBlOiBFdGhlcm5ldAoJU3RhdHVzOiBFbmFibGVkCglEZXNjcmlw dGlvbjogRW1iZWRkZWQgQnJvYWRjb20gNTcwOCBOSUMgMQpPbiBCb2FyZCBEZXZpY2UgMyBJbmZv cm1hdGlvbgoJVHlwZTogRXRoZXJuZXQKCVN0YXR1czogRW5hYmxlZAoJRGVzY3JpcHRpb246IEVt YmVkZGVkIEJyb2FkY29tIDU3MDggTklDIDIKCkhhbmRsZSAweDBCMDAsIERNSSB0eXBlIDExLCA1 IGJ5dGVzCk9FTSBTdHJpbmdzCglTdHJpbmcgMTogRGVsbCBTeXN0ZW0KCVN0cmluZyAyOiA1WzAw MDBdCgpIYW5kbGUgMHg3RTAwLCBETUkgdHlwZSAxMjYsIDE1NCBieXRlcwpJbmFjdGl2ZQoKSGFu ZGxlIDB4MEMwMCwgRE1JIHR5cGUgMTIsIDUgYnl0ZXMKU3lzdGVtIENvbmZpZ3VyYXRpb24gT3B0 aW9ucwoJT3B0aW9uIDE6IE5WUkFNX0NMUjogIENsZWFyIHVzZXIgc2V0dGFibGUgTlZSQU0gYXJl YXMgYW5kIHNldCBkZWZhdWx0cwoJT3B0aW9uIDI6IFBBU1NXRDogIENsb3NlIHRvIGVuYWJsZSBw YXNzd29yZAoKSGFuZGxlIDB4MEQwMCwgRE1JIHR5cGUgMTMsIDIyIGJ5dGVzCkJJT1MgTGFuZ3Vh Z2UgSW5mb3JtYXRpb24KCUluc3RhbGxhYmxlIExhbmd1YWdlczogMQoJCWVufFVTfGlzbzg4NTkt MQoJQ3VycmVudGx5IEluc3RhbGxlZCBMYW5ndWFnZTogZW58VVN8aXNvODg1OS0xCgpIYW5kbGUg MHgxMDAwLCBETUkgdHlwZSAxNiwgMTUgYnl0ZXMKUGh5c2ljYWwgTWVtb3J5IEFycmF5CglMb2Nh dGlvbjogU3lzdGVtIEJvYXJkIE9yIE1vdGhlcmJvYXJkCglVc2U6IFN5c3RlbSBNZW1vcnkKCUVy cm9yIENvcnJlY3Rpb24gVHlwZTogTXVsdGktYml0IEVDQwoJTWF4aW11bSBDYXBhY2l0eTogMzIg R0IKCUVycm9yIEluZm9ybWF0aW9uIEhhbmRsZTogTm90IFByb3ZpZGVkCglOdW1iZXIgT2YgRGV2 aWNlczogOAoKSGFuZGxlIDB4MTEwMCwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZp Y2UKCUFycmF5IEhhbmRsZTogMHgxMDAwCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQ cm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6 IDUxMiBNQgoJRm9ybSBGYWN0b3I6IEZCLURJTU0KCVNldDogMQoJTG9jYXRvcjogRElNTTEgCglC YW5rIExvY2F0b3I6IE5vdCBTcGVjaWZpZWQKCVR5cGU6IEREUjIgRkItRElNTQoJVHlwZSBEZXRh aWw6IFN5bmNocm9ub3VzCglTcGVlZDogNjY3IE1IeiAoMS41IG5zKQoJTWFudWZhY3R1cmVyOiA4 MENFODBCMzgwQ0UKCVNlcmlhbCBOdW1iZXI6IDAyMkJCQjQwCglBc3NldCBUYWc6IDAxMDY0MgoJ UGFydCBOdW1iZXI6IE0zOTVUNjU1M0NaNC1DRTYxIAoKSGFuZGxlIDB4MTEwMSwgRE1JIHR5cGUg MTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgxMDAwCglFcnJvciBJ bmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMKCURh dGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDUxMiBNQgoJRm9ybSBGYWN0b3I6IEZCLURJTU0KCVNl dDogMQoJTG9jYXRvcjogRElNTTIgCglCYW5rIExvY2F0b3I6IE5vdCBTcGVjaWZpZWQKCVR5cGU6 IEREUjIgRkItRElNTQoJVHlwZSBEZXRhaWw6IFN5bmNocm9ub3VzCglTcGVlZDogNjY3IE1IeiAo MS41IG5zKQoJTWFudWZhY3R1cmVyOiA4MENFODBCMzgwQ0UKCVNlcmlhbCBOdW1iZXI6IDAyMkJC QjJDCglBc3NldCBUYWc6IDAxMDY0MgoJUGFydCBOdW1iZXI6IE0zOTVUNjU1M0NaNC1DRTYxIAoK SGFuZGxlIDB4MTEwMiwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5 IEhhbmRsZTogMHgxMDAwCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJ VG90YWwgV2lkdGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IDUxMiBNQgoJ Rm9ybSBGYWN0b3I6IEZCLURJTU0KCVNldDogMgoJTG9jYXRvcjogRElNTTMgCglCYW5rIExvY2F0 b3I6IE5vdCBTcGVjaWZpZWQKCVR5cGU6IEREUjIgRkItRElNTQoJVHlwZSBEZXRhaWw6IFN5bmNo cm9ub3VzCglTcGVlZDogNjY3IE1IeiAoMS41IG5zKQoJTWFudWZhY3R1cmVyOiA4MENFODBCMzgw Q0UKCVNlcmlhbCBOdW1iZXI6IDAyMkJCQjVCCglBc3NldCBUYWc6IDAxMDY0MgoJUGFydCBOdW1i ZXI6IE0zOTVUNjU1M0NaNC1DRTYxIAoKSGFuZGxlIDB4MTEwMywgRE1JIHR5cGUgMTcsIDI4IGJ5 dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgxMDAwCglFcnJvciBJbmZvcm1hdGlv biBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6 IDY0IGJpdHMKCVNpemU6IDUxMiBNQgoJRm9ybSBGYWN0b3I6IEZCLURJTU0KCVNldDogMgoJTG9j YXRvcjogRElNTTQgCglCYW5rIExvY2F0b3I6IE5vdCBTcGVjaWZpZWQKCVR5cGU6IEREUjIgRkIt RElNTQoJVHlwZSBEZXRhaWw6IFN5bmNocm9ub3VzCglTcGVlZDogNjY3IE1IeiAoMS41IG5zKQoJ TWFudWZhY3R1cmVyOiA4MENFODBCMzgwQ0UKCVNlcmlhbCBOdW1iZXI6IDAyMkJCQjM1CglBc3Nl dCBUYWc6IDAxMDY0MgoJUGFydCBOdW1iZXI6IE0zOTVUNjU1M0NaNC1DRTYxIAoKSGFuZGxlIDB4 MTEwNCwgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTog MHgxMDAwCglFcnJvciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lk dGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6IDY0IGJpdHMKCVNpemU6IE5vIE1vZHVsZSBJbnN0YWxs ZWQKCUZvcm0gRmFjdG9yOiBGQi1ESU1NCglTZXQ6IDMKCUxvY2F0b3I6IERJTU01IAoJQmFuayBM b2NhdG9yOiBOb3QgU3BlY2lmaWVkCglUeXBlOiBERFIyIEZCLURJTU0KCVR5cGUgRGV0YWlsOiBT eW5jaHJvbm91cwoJU3BlZWQ6IFVua25vd24KCU1hbnVmYWN0dXJlcjogICAgICAgICAgICAgCglT ZXJpYWwgTnVtYmVyOiAgICAgICAgIAoJQXNzZXQgVGFnOiAgICAgICAKCVBhcnQgTnVtYmVyOiAg ICAgICAgICAgICAgICAgICAKCkhhbmRsZSAweDExMDUsIERNSSB0eXBlIDE3LCAyOCBieXRlcwpN ZW1vcnkgRGV2aWNlCglBcnJheSBIYW5kbGU6IDB4MTAwMAoJRXJyb3IgSW5mb3JtYXRpb24gSGFu ZGxlOiBOb3QgUHJvdmlkZWQKCVRvdGFsIFdpZHRoOiA3MiBiaXRzCglEYXRhIFdpZHRoOiA2NCBi aXRzCglTaXplOiBObyBNb2R1bGUgSW5zdGFsbGVkCglGb3JtIEZhY3RvcjogRkItRElNTQoJU2V0 OiAzCglMb2NhdG9yOiBESU1NNiAKCUJhbmsgTG9jYXRvcjogTm90IFNwZWNpZmllZAoJVHlwZTog RERSMiBGQi1ESU1NCglUeXBlIERldGFpbDogU3luY2hyb25vdXMKCVNwZWVkOiBVbmtub3duCglN YW51ZmFjdHVyZXI6ICAgICAgICAgICAgIAoJU2VyaWFsIE51bWJlcjogICAgICAgICAKCUFzc2V0 IFRhZzogICAgICAgCglQYXJ0IE51bWJlcjogICAgICAgICAgICAgICAgICAgCgpIYW5kbGUgMHgx MTA2LCBETUkgdHlwZSAxNywgMjggYnl0ZXMKTWVtb3J5IERldmljZQoJQXJyYXkgSGFuZGxlOiAw eDEwMDAKCUVycm9yIEluZm9ybWF0aW9uIEhhbmRsZTogTm90IFByb3ZpZGVkCglUb3RhbCBXaWR0 aDogNzIgYml0cwoJRGF0YSBXaWR0aDogNjQgYml0cwoJU2l6ZTogTm8gTW9kdWxlIEluc3RhbGxl ZAoJRm9ybSBGYWN0b3I6IEZCLURJTU0KCVNldDogNAoJTG9jYXRvcjogRElNTTcgCglCYW5rIExv Y2F0b3I6IE5vdCBTcGVjaWZpZWQKCVR5cGU6IEREUjIgRkItRElNTQoJVHlwZSBEZXRhaWw6IFN5 bmNocm9ub3VzCglTcGVlZDogVW5rbm93bgoJTWFudWZhY3R1cmVyOiAgICAgICAgICAgICAKCVNl cmlhbCBOdW1iZXI6ICAgICAgICAgCglBc3NldCBUYWc6ICAgICAgIAoJUGFydCBOdW1iZXI6ICAg ICAgICAgICAgICAgICAgIAoKSGFuZGxlIDB4MTEwNywgRE1JIHR5cGUgMTcsIDI4IGJ5dGVzCk1l bW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgxMDAwCglFcnJvciBJbmZvcm1hdGlvbiBIYW5k bGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDcyIGJpdHMKCURhdGEgV2lkdGg6IDY0IGJp dHMKCVNpemU6IE5vIE1vZHVsZSBJbnN0YWxsZWQKCUZvcm0gRmFjdG9yOiBGQi1ESU1NCglTZXQ6 IDQKCUxvY2F0b3I6IERJTU04IAoJQmFuayBMb2NhdG9yOiBOb3QgU3BlY2lmaWVkCglUeXBlOiBE RFIyIEZCLURJTU0KCVR5cGUgRGV0YWlsOiBTeW5jaHJvbm91cwoJU3BlZWQ6IFVua25vd24KCU1h bnVmYWN0dXJlcjogICAgICAgICAgICAgCglTZXJpYWwgTnVtYmVyOiAgICAgICAgIAoJQXNzZXQg VGFnOiAgICAgICAKCVBhcnQgTnVtYmVyOiAgICAgICAgICAgICAgICAgICAKCkhhbmRsZSAweDEx MDgsIERNSSB0eXBlIDEyNiwgMjggYnl0ZXMKSW5hY3RpdmUKCkhhbmRsZSAweDExMDksIERNSSB0 eXBlIDEyNiwgMjggYnl0ZXMKSW5hY3RpdmUKCkhhbmRsZSAweDExMEEsIERNSSB0eXBlIDEyNiwg MjggYnl0ZXMKSW5hY3RpdmUKCkhhbmRsZSAweDExMEIsIERNSSB0eXBlIDEyNiwgMjggYnl0ZXMK SW5hY3RpdmUKCkhhbmRsZSAweDEzMDAsIERNSSB0eXBlIDE5LCAxNSBieXRlcwpNZW1vcnkgQXJy YXkgTWFwcGVkIEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAwMDAwMDAwMDAKCUVuZGlu ZyBBZGRyZXNzOiAweDAwMDdGRkZGRkZGCglSYW5nZSBTaXplOiAyIEdCCglQaHlzaWNhbCBBcnJh eSBIYW5kbGU6IDB4MTAwMAoJUGFydGl0aW9uIFdpZHRoOiAwCgpIYW5kbGUgMHgxMzAxLCBETUkg dHlwZSAxMjYsIDE1IGJ5dGVzCkluYWN0aXZlCgpIYW5kbGUgMHgyMDAwLCBETUkgdHlwZSAzMiwg MTEgYnl0ZXMKU3lzdGVtIEJvb3QgSW5mb3JtYXRpb24KCVN0YXR1czogTm8gZXJyb3JzIGRldGVj dGVkCgpIYW5kbGUgMHgyNjAwLCBETUkgdHlwZSAzOCwgMTggYnl0ZXMKSVBNSSBEZXZpY2UgSW5m b3JtYXRpb24KCUludGVyZmFjZSBUeXBlOiBLQ1MgKEtleWJvYXJkIENvbnRyb2wgU3R5bGUpCglT cGVjaWZpY2F0aW9uIFZlcnNpb246IDIuMAoJSTJDIFNsYXZlIEFkZHJlc3M6IDB4MTAKCU5WIFN0 b3JhZ2UgRGV2aWNlOiBOb3QgUHJlc2VudAoJQmFzZSBBZGRyZXNzOiAweDAwMDAwMDAwMDAwMDBD QTggKEkvTykKCVJlZ2lzdGVyIFNwYWNpbmc6IDMyLWJpdCBCb3VuZGFyaWVzCgpIYW5kbGUgMHhE MDAwLCBETUkgdHlwZSAyMDgsIDEwIGJ5dGVzCk9FTS1zcGVjaWZpYyBUeXBlCglIZWFkZXIgYW5k IERhdGE6CgkJRDAgMEEgMDAgRDAgMDIgMDAgRkUgMDAgQjIgMDEKCkhhbmRsZSAweEQyMDAsIERN SSB0eXBlIDIxMCwgMTIgYnl0ZXMKT0VNLXNwZWNpZmljIFR5cGUKCUhlYWRlciBhbmQgRGF0YToK CQlEMiAwQyAwMCBEMiBGOCAwMyAwNCAwMyAwNiA4MCAwNCAwNQoKSGFuZGxlIDB4RDQwMCwgRE1J IHR5cGUgMjEyLCAxMjcgYnl0ZXMKT0VNLXNwZWNpZmljIFR5cGUKCUhlYWRlciBhbmQgRGF0YToK CQlENCA3RiAwMCBENCA3MCAwMCA3MSAwMCAwMCAxMCAyRCAyRSAwMyAwMCAxMSA3RgoJCTgwIDA0 IDAwIDExIDdGIDAwIDQyIDAwIDExIEZFIDAxIDQzIDAwIDExIEZFIDAwCgkJMDAgMDAgMTEgOUYg MjAgMDAgMDAgMTEgOUYgMDAgNkUgMDEgMTEgOUYgMjAgNkQKCQkwMSAxMSA5RiAwMCAzMSA0MCAx MSBGQiAwMCAzMiA0MCAxMSBGQiAwNCA5RCAwMAoJCTExIEZEIDAyIDlFIDAwIDExIEZEIDAwIDlG IDAwIDI2IEZFIDAxIEEwIDAwIDI2CgkJRkUgMDAgNTEgMDAgMjYgM0YgMDAgNTIgMDAgMjYgM0Yg NDAgNTMgMDAgMjYgM0YKCQk4MCA1NCAwMCAyNiAzRiBDMCAyOCA0MCAyNiBERiAyMCAyOSA0MCAy NiBERiAwMAoJCUQ2IDAxIDI2IEY3IDAwIEQ3IDAxIDI2IEY3IDA4IEZGIEZGIDAwIDAwIDAwCgpI YW5kbGUgMHhENDAxLCBETUkgdHlwZSAyMTIsIDE5NyBieXRlcwpPRU0tc3BlY2lmaWMgVHlwZQoJ SGVhZGVyIGFuZCBEYXRhOgoJCUQ0IEM1IDAxIEQ0IDcwIDAwIDcxIDAwIDAzIDQwIDVBIDZEIDZC IDAwIDc4IDdGCgkJODAgNkMgMDAgNzggN0YgMDAgNTggMDAgNzggRkEgMDUgNTkgMDAgNzggRkEg MDAKCQk1QyAwMCA3OCBCRiA0MCA1RCAwMCA3OCBCRiAwMCAwNCA4MCA3OCBGRCAwMiAwMQoJCUEw IDc4IEZEIDAwIDE5IDAwIDU1IEU3IDAwIDFBIDAwIDU1IEU3IDA4IDFCIDAwCgkJNTUgRTcgMTAg NkMgMDEgNTcgRkMgMDAgNkIgMDEgNTcgRkMgMDEgNkEgMDEgNTcKCQlGQyAwMiA3NyAwMSA1NCBG QyAwMCA3OCAwMSA1NCBGQyAwMSA3OSAwMSA1NCBGQwoJCTAyIDdBIDAxIDU0IEZDIDAzIDMzIDQw IDU0IENGIDAwIDM0IDQwIDU0IENGIDEwCgkJMzUgNDAgNTQgQ0YgMjAgMzYgNDAgNTQgQ0YgMzAg MUEgNDAgNTQgRkIgMDQgMUIKCQk0MCA1NCBGQiAwMCAxQyA0MCA1NCBGNyAwOCAxRCA0MCA1NCBG NyAwMCA0MyA0MAoJCTU4IERGIDIwIDQyIDQwIDU4IERGIDAwIDZFIDAwIDU4IEZDIDAxIDJEIDAw IDU4CgkJRkMgMDIgMkUgMDAgNTggRkMgMDAgMjIgNDAgNTggRUYgMTAgMjMgNDAgNTggRUYKCQkw MCBCQiAwMCA1OCBGMyAwNCBCQyAwMCA1OCBGMyAwOCBCQSAwMCA1OCBGMyAwMAoJCUZGIEZGIDAw IDAwIDAwCgpIYW5kbGUgMHhENDAyLCBETUkgdHlwZSAyMTIsIDQ3IGJ5dGVzCk9FTS1zcGVjaWZp YyBUeXBlCglIZWFkZXIgYW5kIERhdGE6CgkJRDQgMkYgMDIgRDQgNzAgMDAgNzEgMDAgMDMgNDAg NUEgNkQgRDggMDAgNTUgN0YKCQk4MCBEOSAwMCA1NSA3RiAwMCAwMCBDMCA1QyAwMCAwQSAwMyBD MCA2NyAwMCAwNQoJCTgzIDAwIDc2IDAwIDAwIDg0IDAwIDc3IDAwIDAwIEZGIEZGIDAwIDAwIDAw CgpIYW5kbGUgMHhENDAzLCBETUkgdHlwZSAyMTIsIDI0NyBieXRlcwpPRU0tc3BlY2lmaWMgVHlw ZQoJSGVhZGVyIGFuZCBEYXRhOgoJCUQ0IEY3IDAzIEQ0IDcyIDAwIDczIDAwIDAwIDQwIDVEIDVF IDcxIDAxIDQ2IEZCCgkJMDQgNzIgMDEgNDYgRkIgMDAgNzMgMDEgNDYgRjcgMDggNzQgMDEgNDYg RjcgMDAKCQkwMCAwMCA0NiBGRSAwMCAwMCAwMCA0NiBGRSAwMSA0QSAwMSA0NiBCRiA0MCA0QgoJ CTAxIDQ2IEJGIDAwIEQzIDAwIDAwIDAwIDAyIEQ0IDAwIDAyIDAwIDAyIDAwIDkwCgkJMkMgMDAg MDAgMDEgOTAgMkQgMDAgMDAgMDAgMDAgNDkgRUIgMTQgREIgMDAgNDkKCQlFQiAwMCAwMCAwMCA0 OSBGQyAwMCAwMCAwMCA0OSBGQyAwMSAwMCAwMCA0OSBGQwoJCTAyIDAwIDAwIDQ5IDdGIDAwIDAw IDAwIDQ5IDdGIDgwIDE3IDAxIDRBIEZFIDAwCgkJMTggMDEgNEEgRkUgMDEgMTkgMDEgNEEgRkQg MDAgMUEgMDEgNEEgRkQgMDIgMDAKCQkwMCA0QSBGQiAwMCAwMCAwMCA0QSBGQiAwNCAwMCAwMCA0 QSBGNyAwMCAwMCAwMAoJCTRBIEY3IDA4IDM1IDAxIDRCIEZDIDAwIDM3IDAxIDRCIEZDIDAxIDNC IDAxIDRCCgkJRjMgMDQgREUgMDAgNjMgRkUgMDEgMjYgNDAgNDIgRkUgMDEgMjcgNDAgNDIgRkUK CQkwMCAwMCAwMCA0NyBGRSAwMSAwMCAwMCA0NyBGRSAwMCBBMSAwMCA0NSBDRiAyMAoJCUEzIDAw IDQ1IENGIDEwIEEyIDAwIDQ1IENGIDAwIDAyIDQwIDQ2IERGIDAwIDAxCgkJNDAgNDYgREYgMjAg OTUgMDEgN0UgRkMgMDAgOTYgMDEgN0UgRkMgMDEgOTcgMDEKCQk3RSBGQyAwMiAwOSA4MCA3RSBG MyAwMCAwQSA4MCA3RSBGMyAwNCAwQiA4MCA3RQoJCUYzIDA4IEZGIEZGIDAwIDAwIDAwCgpIYW5k bGUgMHhENDA0LCBETUkgdHlwZSAyMTIsIDM3IGJ5dGVzCk9FTS1zcGVjaWZpYyBUeXBlCglIZWFk ZXIgYW5kIERhdGE6CgkJRDQgMjUgMDQgRDQgNzIgMDAgNzMgMDAgMDAgNDAgNUQgNUUgNDEgNDAg NDAgRkUKCQkwMSA0MCA0MCA0MCBGRSAwMCBDRiAwMSA0MCBGRCAwMiBEMCAwMSA0MCBGRCAwMAoJ CUZGIEZGIDAwIDAwIDAwCgpIYW5kbGUgMHhEODAwLCBETUkgdHlwZSAyMTYsIDkgYnl0ZXMKT0VN LXNwZWNpZmljIFR5cGUKCUhlYWRlciBhbmQgRGF0YToKCQlEOCAwOSAwMCBEOCAwMSAwMiAwMSAw MCAwMAoJU3RyaW5nczoKCQlBVEkKCQlSTjUwIEEyMCBCSU9TCgpIYW5kbGUgMHhERTAwLCBETUkg dHlwZSAyMjIsIDE2IGJ5dGVzCk9FTS1zcGVjaWZpYyBUeXBlCglIZWFkZXIgYW5kIERhdGE6CgkJ REUgMTAgMDAgREUgMDEgMDQgRkYgRkYgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDEKCkhhbmRsZSAw eDdGMDAsIERNSSB0eXBlIDEyNywgNCBieXRlcwpFbmQgT2YgVGFibGUKCg== ------=_Part_11775_2907320.1217617634432 Content-Type: application/octet-stream; name=pciconf_-l_-i.out Content-Transfer-Encoding: base64 X-Attachment-Id: f_fjd5tv3g3 Content-Disposition: attachment; filename=pciconf_-l_-i.out aG9zdGIwQHBjaTA6MDowOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4ODA4NjgwODYgY2hpcD0weDI1 YzA4MDg2IHJldj0weDEyIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0 aW9uJwogICAgZGV2aWNlICAgICA9ICc1MDAwWCBDaGlwc2V0IE1lbW9yeSBDb250cm9sbGVyIEh1 YicKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpwY2li MUBwY2kwOjI6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgyNWUyODA4 NiByZXY9MHgxMiBoZHI9MHgwMQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicK ICAgIGRldmljZSAgICAgPSAnNTAwMCBTZXJpZXMgQ2hpcHNldCBQQ0llIHg0IFBvcnQgMicKICAg IGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCnBjaWI3QHBjaTA6 MzowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDI1ZTM4MDg2IHJldj0w eDEyIGhkcj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2 aWNlICAgICA9ICc1MDAwIFNlcmllcyBDaGlwc2V0IFBDSWUgeDQgUG9ydCAzJwogICAgY2xhc3Mg ICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kKcGNpYjEwQHBjaTA6NDowOglj bGFzcz0weDA2MDQwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDI1Zjg4MDg2IHJldj0weDEyIGhk cj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAg ICA9ICc1MDAwIFNlcmllcyBDaGlwc2V0IFBDSWUgeDggUG9ydCA0LTUnCiAgICBjbGFzcyAgICAg ID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQpwY2liMTFAcGNpMDo1OjA6CWNsYXNz PTB4MDYwNDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MjVlNTgwODYgcmV2PTB4MTIgaGRyPTB4 MDEKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0g JzUwMDAgU2VyaWVzIENoaXBzZXQgUENJZSB4NCBQb3J0IDUnCiAgICBjbGFzcyAgICAgID0gYnJp ZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQpwY2liMTJAcGNpMDo2OjA6CWNsYXNzPTB4MDYw NDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MjVmOTgwODYgcmV2PTB4MTIgaGRyPTB4MDEKICAg IHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJzUwMDAg U2VyaWVzIENoaXBzZXQgUENJZSB4OCBQb3J0IDYtNycKICAgIGNsYXNzICAgICAgPSBicmlkZ2UK ICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCnBjaWIxNUBwY2kwOjc6MDoJY2xhc3M9MHgwNjA0MDAg Y2FyZD0weDAwMDAwMDAwIGNoaXA9MHgyNWU3ODA4NiByZXY9MHgxMiBoZHI9MHgwMQogICAgdmVu ZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnNTAwMCBTZXJp ZXMgQ2hpcHNldCBQQ0llIHg0IFBvcnQgNycKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1 YmNsYXNzICAgPSBQQ0ktUENJCmhvc3RiMUBwY2kwOjE2OjA6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9 MHgwMWIyMTAyOCBjaGlwPTB4MjVmMDgwODYgcmV2PTB4MTIgaGRyPTB4MDAKICAgIHZlbmRvciAg ICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJzUwMDAgU2VyaWVzIENo aXBzZXQgRXJyb3IgUmVwb3J0aW5nIFJlZ2lzdGVycycKICAgIGNsYXNzICAgICAgPSBicmlkZ2UK ICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpob3N0YjJAcGNpMDoxNjoxOgljbGFzcz0weDA2MDAw MCBjYXJkPTB4MDFiMjEwMjggY2hpcD0weDI1ZjA4MDg2IHJldj0weDEyIGhkcj0weDAwCiAgICB2 ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICc1MDAwIFNl cmllcyBDaGlwc2V0IEVycm9yIFJlcG9ydGluZyBSZWdpc3RlcnMnCiAgICBjbGFzcyAgICAgID0g YnJpZGdlCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kKaG9zdGIzQHBjaTA6MTY6MjoJY2xhc3M9 MHgwNjAwMDAgY2FyZD0weDAxYjIxMDI4IGNoaXA9MHgyNWYwODA4NiByZXY9MHgxMiBoZHI9MHgw MAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAn NTAwMCBTZXJpZXMgQ2hpcHNldCBFcnJvciBSZXBvcnRpbmcgUmVnaXN0ZXJzJwogICAgY2xhc3Mg ICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCmhvc3RiNEBwY2kwOjE3OjA6 CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHg4MDg2ODA4NiBjaGlwPTB4MjVmMTgwODYgcmV2PTB4MTIg aGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2Ug ICAgID0gJzUwMDAgU2VyaWVzIENoaXBzZXQgUmVzZXJ2ZWQgUmVnaXN0ZXJzJwogICAgY2xhc3Mg ICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCmhvc3RiNUBwY2kwOjE5OjA6 CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHg4MDg2ODA4NiBjaGlwPTB4MjVmMzgwODYgcmV2PTB4MTIg aGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2Ug ICAgID0gJzUwMDAgU2VyaWVzIENoaXBzZXQgUmVzZXJ2ZWQgUmVnaXN0ZXJzJwogICAgY2xhc3Mg ICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCmhvc3RiNkBwY2kwOjIxOjA6 CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHg4MDg2ODA4NiBjaGlwPTB4MjVmNTgwODYgcmV2PTB4MTIg aGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2Ug ICAgID0gJzUwMDAgU2VyaWVzIENoaXBzZXQgRkJEIFJlZ2lzdGVycycKICAgIGNsYXNzICAgICAg PSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQpob3N0YjdAcGNpMDoyMjowOgljbGFz cz0weDA2MDAwMCBjYXJkPTB4ODA4NjgwODYgY2hpcD0weDI1ZjY4MDg2IHJldj0weDEyIGhkcj0w eDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9 ICc1MDAwIFNlcmllcyBDaGlwc2V0IEZCRCBSZWdpc3RlcnMnCiAgICBjbGFzcyAgICAgID0gYnJp ZGdlCiAgICBzdWJjbGFzcyAgID0gSE9TVC1QQ0kKcGNpYjE2QHBjaTA6Mjg6MDoJY2xhc3M9MHgw NjA0MDAgY2FyZD0weDAxYjIxMDI4IGNoaXA9MHgyNjkwODA4NiByZXY9MHgwOSBoZHI9MHgwMQog ICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnNjMx eEVTQi82MzJ4RVNCLzMxMDAgUENJZSBSb290IFBvcnQgMScKICAgIGNsYXNzICAgICAgPSBicmlk Z2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCnVoY2kwQHBjaTA6Mjk6MDoJY2xhc3M9MHgwYzAz MDAgY2FyZD0weDAxYjIxMDI4IGNoaXA9MHgyNjg4ODA4NiByZXY9MHgwOSBoZHI9MHgwMAogICAg dmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnNjMxeEVT Qi82MzJ4RVNCLzMxMDAgQ2hpcHNldCBVU0IgVW5pdmVyc2FsIEhvc3QgQ29udHJvbGxlcicKICAg IGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCnVoY2kxQHBjaTA6 Mjk6MToJY2xhc3M9MHgwYzAzMDAgY2FyZD0weDAxYjIxMDI4IGNoaXA9MHgyNjg5ODA4NiByZXY9 MHgwOSBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRl dmljZSAgICAgPSAnNjMxeEVTQi82MzJ4RVNCLzMxMDAgQ2hpcHNldCBVU0IgVW5pdmVyc2FsIEhv c3QgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAg ID0gVVNCCnVoY2kyQHBjaTA6Mjk6MjoJY2xhc3M9MHgwYzAzMDAgY2FyZD0weDAxYjIxMDI4IGNo aXA9MHgyNjhhODA4NiByZXY9MHgwOSBoZHI9MHgwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBD b3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnNjMxeEVTQi82MzJ4RVNCLzMxMDAgQ2hpcHNl dCBVU0IgVW5pdmVyc2FsIEhvc3QgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwg YnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCmVoY2kwQHBjaTA6Mjk6NzoJY2xhc3M9MHgwYzAzMjAg Y2FyZD0weDAxYjIxMDI4IGNoaXA9MHgyNjhjODA4NiByZXY9MHgwOSBoZHI9MHgwMAogICAgdmVu ZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnNjMxeEVTQi82 MzJ4RVNCLzMxMDAgQ2hpcHNldCBVU0IyIEVuaGFuY2VkIEhvc3QgQ29udHJvbGxlcicKICAgIGNs YXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCnBjaWIxOEBwY2kwOjMw OjA6CWNsYXNzPTB4MDYwNDAxIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MjQ0ZTgwODYgcmV2PTB4 ZDkgaGRyPTB4MDEKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZp Y2UgICAgID0gJzgyODAxIEZhbWlseSAoSUNIMi8zLzQvNC81LzUvNi83LzgvOSw2M3h4RVNCKSBI dWIgSW50ZXJmYWNlIHRvIFBDSSBCcmlkZ2UnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBz dWJjbGFzcyAgID0gUENJLVBDSQppc2FiMEBwY2kwOjMxOjA6CWNsYXNzPTB4MDYwMTAwIGNhcmQ9 MHgwMDAwMDAwMCBjaGlwPTB4MjY3MDgwODYgcmV2PTB4MDkgaGRyPTB4MDAKICAgIHZlbmRvciAg ICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJzYzMXhFU0IvNjMyeEVT Qi8zMTAwIExQQyBJbnRlcmZhY2UgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBicmlkZ2UK ICAgIHN1YmNsYXNzICAgPSBQQ0ktSVNBCmF0YXBjaTBAcGNpMDozMToxOgljbGFzcz0weDAxMDE4 YSBjYXJkPTB4MDFiMjEwMjggY2hpcD0weDI2OWU4MDg2IHJldj0weDA5IGhkcj0weDAwCiAgICB2 ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICc2MzF4RVNC LzYzMnhFU0IvMzEwMCBVbHRyYSBBVEEgU3RvcmFnZSBDb250cm9sbGVyJwogICAgY2xhc3MgICAg ICA9IG1hc3Mgc3RvcmFnZQogICAgc3ViY2xhc3MgICA9IEFUQQpwY2liMkBwY2k2OjA6MDoJY2xh c3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgzNTAwODA4NiByZXY9MHgwMSBoZHI9 MHgwMQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAg PSAnNjMxeEVTQi82MzJ4RVNCIFBDSWUgVXBzdHJlYW0gUG9ydCcKICAgIGNsYXNzICAgICAgPSBi cmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCnBjaWI2QHBjaTY6MDozOgljbGFzcz0weDA2 MDQwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDM1MGM4MDg2IHJldj0weDAxIGhkcj0weDAxCiAg ICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICc2MzF4 RVNCLzYzMnhFU0IgUENJZSB0byBQQ0ktWCBCcmlkZ2UnCiAgICBjbGFzcyAgICAgID0gYnJpZGdl CiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQpwY2liM0BwY2k3OjA6MDoJY2xhc3M9MHgwNjA0MDAg Y2FyZD0weDAwMDAwMDAwIGNoaXA9MHgzNTEwODA4NiByZXY9MHgwMSBoZHI9MHgwMQogICAgdmVu ZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnNjMxeEVTQi82 MzJ4RVNCIFBDSWUgRG93bnN0cmVhbSBQb3J0IEUxJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQog ICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kKcGNpYjVAcGNpNzoxOjA6CWNsYXNzPTB4MDYwNDAwIGNh cmQ9MHgwMDAwMDAwMCBjaGlwPTB4MzUxNDgwODYgcmV2PTB4MDEgaGRyPTB4MDEKICAgIHZlbmRv ciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJzYzMXhFU0IvNjMy eEVTQiBQQ0llIERvd25zdHJlYW0gUG9ydCBFMicKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAg IHN1YmNsYXNzICAgPSBQQ0ktUENJCnBjaWI0QHBjaTg6MDowOgljbGFzcz0weDA2MDQwMCBjYXJk PTB4MDAwMDAwMDAgY2hpcD0weDAxMDMxMTY2IHJldj0weGMyIGhkcj0weDAxCiAgICB2ZW5kb3Ig ICAgID0gJ1NlcnZlcldvcmtzIChXYXM6IFJlbGlhbmNlIENvbXB1dGVyIENvcnApJwogICAgZGV2 aWNlICAgICA9ICdCQ001NzE1IEJyb2FkY29tIGR1YWwgZ2lnYWJpdCwgcGNpIGJyaWRnZScKICAg IGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCmJjZTBAcGNpOTow OjA6CWNsYXNzPTB4MDIwMDAwIGNhcmQ9MHgwMWIyMTAyOCBjaGlwPTB4MTY0YzE0ZTQgcmV2PTB4 MTEgaGRyPTB4MDAKICAgIHZlbmRvciAgICAgPSAnQnJvYWRjb20gQ29ycG9yYXRpb24nCiAgICBk ZXZpY2UgICAgID0gJzU3MDhDIEJyb2FkY29tIE5ldFh0cmVtZSBJSSBHaWdhYml0IEV0aGVybmV0 IEFkYXB0ZXInCiAgICBjbGFzcyAgICAgID0gbmV0d29yawogICAgc3ViY2xhc3MgICA9IGV0aGVy bmV0CnBjaWI4QHBjaTE6MDowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0w eDAzNzA4MDg2IHJldj0weDAwIGhkcj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBv cmF0aW9uJwogICAgZGV2aWNlICAgICA9ICc4MDMzMyBTZWdtZW50LUEgUENJIEV4cHJlc3MtdG8t UENJIEV4cHJlc3MgQnJpZGdlJwogICAgY2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3Mg ICA9IFBDSS1QQ0kKcGNpYjlAcGNpMTowOjI6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAwMDAw MCBjaGlwPTB4MDM3MjgwODYgcmV2PTB4MDAgaGRyPTB4MDEKICAgIHZlbmRvciAgICAgPSAnSW50 ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJzgwMzMzIFNlZ21lbnQtQiBQQ0kgRXhw cmVzcy10by1QQ0kgRXhwcmVzcyBCcmlkZ2UnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBz dWJjbGFzcyAgID0gUENJLVBDSQptZmkwQHBjaTI6MTQ6MDoJY2xhc3M9MHgwMTA0MDAgY2FyZD0w eDFmMDMxMDI4IGNoaXA9MHgwMDE1MTAyOCByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAg ICA9ICdEZWxsIENvbXB1dGVyIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdQRVJDIDUv aSBSQUlEIENvbnRyb2xsZXIgSW50ZWdyYXRlZCBSQUlEIGNvbnRyb2xsZXInCiAgICBjbGFzcyAg ICAgID0gbWFzcyBzdG9yYWdlCiAgICBzdWJjbGFzcyAgID0gUkFJRApwY2liMTNAcGNpMTQ6MDow OgljbGFzcz0weDA2MDQwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDAzMjk4MDg2IHJldj0weDA5 IGhkcj0weDAxCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNl ICAgICA9ICc2NzAwUFhIIFBDSSBFeHByZXNzLXRvLVBDSSBFeHByZXNzIEJyaWRnZSBBJwogICAg Y2xhc3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kKcGNpYjE0QHBjaTE0 OjA6MjoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgwMzJhODA4NiByZXY9 MHgwOSBoZHI9MHgwMQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRl dmljZSAgICAgPSAnNjcwMFBYSCBQQ0kgRXhwcmVzcy10by1QQ0kgRXhwcmVzcyBCcmlkZ2UgQicK ICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJCmFoZDBAcGNp MTU6MzowOgljbGFzcz0weDAxMDAwMCBjYXJkPTB4MDA0MDkwMDUgY2hpcD0weDgwMTY5MDA1IHJl dj0weDEwIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0FkYXB0ZWMgSW5jJwogICAgZGV2aWNl ICAgICA9ICdBU0MtMzkzMjBBIFVsdHJhMzIwIFNDU0kgQ29udHJvbGxlcicKICAgIGNsYXNzICAg ICAgPSBtYXNzIHN0b3JhZ2UKICAgIHN1YmNsYXNzICAgPSBTQ1NJCmFoZDFAcGNpMTU6MzoxOglj bGFzcz0weDAxMDAwMCBjYXJkPTB4MDA0MDkwMDUgY2hpcD0weDgwMTY5MDA1IHJldj0weDEwIGhk cj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0FkYXB0ZWMgSW5jJwogICAgZGV2aWNlICAgICA9ICdB U0MtMzkzMjBBIFVsdHJhMzIwIFNDU0kgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBtYXNz IHN0b3JhZ2UKICAgIHN1YmNsYXNzICAgPSBTQ1NJCnBjaWIxN0BwY2k0OjA6MDoJY2xhc3M9MHgw NjA0MDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgwMTAzMTE2NiByZXY9MHhjMiBoZHI9MHgwMQog ICAgdmVuZG9yICAgICA9ICdTZXJ2ZXJXb3JrcyAoV2FzOiBSZWxpYW5jZSBDb21wdXRlciBDb3Jw KScKICAgIGRldmljZSAgICAgPSAnQkNNNTcxNSBCcm9hZGNvbSBkdWFsIGdpZ2FiaXQsIHBjaSBi cmlkZ2UnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQpi Y2UxQHBjaTU6MDowOgljbGFzcz0weDAyMDAwMCBjYXJkPTB4MDFiMjEwMjggY2hpcD0weDE2NGMx NGU0IHJldj0weDExIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0gJ0Jyb2FkY29tIENvcnBvcmF0 aW9uJwogICAgZGV2aWNlICAgICA9ICc1NzA4QyBCcm9hZGNvbSBOZXRYdHJlbWUgSUkgR2lnYWJp dCBFdGhlcm5ldCBBZGFwdGVyJwogICAgY2xhc3MgICAgICA9IG5ldHdvcmsKICAgIHN1YmNsYXNz ICAgPSBldGhlcm5ldApub25lMEBwY2kxODoxMzowOgljbGFzcz0weDAzMDAwMCBjYXJkPTB4MDFi MjEwMjggY2hpcD0weDUxNWUxMDAyIHJldj0weDAyIGhkcj0weDAwCiAgICB2ZW5kb3IgICAgID0g J0FUSSBUZWNobm9sb2dpZXMgSW5jJwogICAgZGV2aWNlICAgICA9ICdSYWRlb24gRVMxMDAwIFJh ZGVvbiBFUzEwMDAnCiAgICBjbGFzcyAgICAgID0gZGlzcGxheQogICAgc3ViY2xhc3MgICA9IFZH QQo= ------=_Part_11775_2907320.1217617634432-- From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 00:24:46 2008 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 ED1A6106566C for ; Sat, 2 Aug 2008 00:24:46 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by mx1.freebsd.org (Postfix) with ESMTP id A79E58FC2B for ; Sat, 2 Aug 2008 00:24:46 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so1243452wra.27 for ; Fri, 01 Aug 2008 17:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=JpZSwH4dDUWHQzODZ9JcXrVLjJgLQldIB6gThxJGmBQ=; b=mfV9WxPizF8hcoH0svTRAav2k6o1eS0reaMd23lUVRZG3x2xPdVUPishfLimqBcslx wov7NfQ0BYzK8PFgXdEri+ehe31gW/LOFQ/cDrth2c3+JMgf2oGUvxqenshi66TPHopq 0cDoVkRgsPil7qftbrHrc1CXQNywDjQ/4Wl1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=IAgJI+TY/PTwE0S+f87/zd1PBfZViUW7XzGReT9d5aylMuyFKJ1k4rxBsPElu5lv7p GKcLK4bq7m9rm7tyTLKms1mE9RuV0KMHdZWx1C9eBfx0Ad/CZ9OgUuOJVm33FFXMeCl8 cPdFvap/eunbXr9EG50Zx3MfJ0zSNIWfFCoNg= Received: by 10.90.31.8 with SMTP id e8mr10979927age.68.1217636685971; Fri, 01 Aug 2008 17:24:45 -0700 (PDT) Received: by 10.90.30.10 with HTTP; Fri, 1 Aug 2008 17:24:45 -0700 (PDT) Message-ID: <790a9fff0808011724n25179c9coeaa94393ffd40dd7@mail.gmail.com> Date: Fri, 1 Aug 2008 19:24:45 -0500 From: "Scot Hetzel" To: "Jack Raats" In-Reply-To: <6A7AD37501FA4199B44BBBB03B0EE368@jarasoft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6A7AD37501FA4199B44BBBB03B0EE368@jarasoft.net> Cc: freebsd-stable , freebsd-questions@freebsd.org Subject: Re: Adding device to FreeBSD 6.3-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: Sat, 02 Aug 2008 00:24:47 -0000 On 8/1/08, Jack Raats wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I would like to add the zyd device to FreeBSD. > The zyd driver allready is in FreeBSD 7.0. > Which steps do I have to take to add the zyd device to FreeBSD? > You need to obtain these revisions to compile zyd: sys/dev/usb/if_zyd.c 1.13 sys/modules/zyd/Makefile 1.1 Revision 1.14 was when the net80211 wireless networking stack was committed. Scot From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 03:04:32 2008 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 D015F1065677; Sat, 2 Aug 2008 03:04:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7D2E48FC0A; Sat, 2 Aug 2008 03:04:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7234T8J059375; Fri, 1 Aug 2008 23:04:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m7234Tup057866; Fri, 1 Aug 2008 23:04:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id 55069241A2; Fri, 1 Aug 2008 23:04:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080802030436.55069241A2@freebsd-legacy.sentex.ca> Date: Fri, 1 Aug 2008 23:04:36 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.3/7824/Thu Jul 24 21:48:33 2008 clamav-milter version 0.93 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_6 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: Sat, 02 Aug 2008 03:04:33 -0000 TB --- 2008-08-02 01:59:54 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-08-02 01:59:54 - starting RELENG_6 tinderbox run for i386/pc98 TB --- 2008-08-02 01:59:54 - cleaning the object tree TB --- 2008-08-02 02:00:23 - cvsupping the source tree TB --- 2008-08-02 02:00:23 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/i386/pc98/supfile TB --- 2008-08-02 02:00:35 - building world (CFLAGS=-O2 -pipe) TB --- 2008-08-02 02:00:35 - cd /src TB --- 2008-08-02 02:00:35 - /usr/bin/make -B buildworld >>> 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 TB --- 2008-08-02 02:54:18 - generating LINT kernel config TB --- 2008-08-02 02:54:18 - cd /src/sys/pc98/conf TB --- 2008-08-02 02:54:18 - /usr/bin/make -B LINT TB --- 2008-08-02 02:54:18 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-08-02 02:54:18 - cd /src TB --- 2008-08-02 02:54:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Aug 2 02:54:18 UTC 2008 >>> 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 [...] machdep.o(.text+0xa92): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xa9c): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xaeb): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xaf8): In function `init386': : undefined reference to `SMP_prvspace' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-08-02 03:04:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-08-02 03:04:36 - ERROR: failed to build lint kernel TB --- 2008-08-02 03:04:36 - tinderbox aborted TB --- 3044.68 user 361.33 system 3881.68 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 04:47:31 2008 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 034761065671 for ; Sat, 2 Aug 2008 04:47:31 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate02.web.de (fmmailgate02.web.de [217.72.192.227]) by mx1.freebsd.org (Postfix) with ESMTP id 75A898FC0C for ; Sat, 2 Aug 2008 04:47:30 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate02.web.de (Postfix) with ESMTP id CA711E7D40DB; Sat, 2 Aug 2008 06:47:28 +0200 (CEST) Received: from [217.236.1.240] (helo=localhost) by smtp06.web.de with asmtp (WEB.DE 4.109 #226) id 1KP91c-0007mT-00; Sat, 02 Aug 2008 06:47:28 +0200 Date: Sat, 2 Aug 2008 06:47:27 +0200 From: Martin To: "Jack Vogel" Message-ID: <20080802064727.042d5e3d@web.de> In-Reply-To: <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> References: <20080801142005.473c17ca@zelda.local> <20080801154208.W6085@fledge.watson.org> <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX1+5oilQu9+oQ650lJlVGcywe+SyV9Q9CR9skMeW Xv/b+FW51vVPG6sGy9NZowP/bN6sCVaMWSrF52CTNe0FHfSagN uPJzmiYFo= Cc: jfv@freebsd.org, freebsd-stable@freebsd.org, Robert Watson Subject: Re: em(4) on FreeBSD is sometimes annoying 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, 02 Aug 2008 04:47:31 -0000 On Fri, 1 Aug 2008 09:24:53 -0700 "Jack Vogel" wrote: > If the poster gives me EXACT hardware list I will see about repro'ing the > problem inhouse. We do not do much of anything with laptops but I > will see. Oh and a pciconf would help too. Hi Jack, pciconf -lv gives me: em0@pci0:2:0:0: class=0x020000 card=0x200117aa chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet One thing, I have to add. I described the behavior wrong. The adapter actually IS available in the interface list, but it gets "no carrier". Sorry for that. This is what I get from ifconfig when the NIC is plugged in: em0: flags=8843 metric 0 mtu 1500 options=19b ether xx:xx:xx:xx:xx:xx media: Ethernet autoselect status: no carrier All LEDs are off. Device was found on boot: em0: port 0x3000-0x301f mem 0xee000 000-0xee01ffff irq 16 at device 0.0 on pci2 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: xx:xx:xx:xx:xx:xx -- Martin From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 05:00:20 2008 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 B257C1065684 for ; Sat, 2 Aug 2008 05:00:20 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate01.web.de (fmmailgate01.web.de [217.72.192.221]) by mx1.freebsd.org (Postfix) with ESMTP id 6F25C8FC13 for ; Sat, 2 Aug 2008 05:00:20 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate01.web.de (Postfix) with ESMTP id C8027EA0B3DB; Sat, 2 Aug 2008 07:00:18 +0200 (CEST) Received: from [217.236.1.240] (helo=localhost) by smtp05.web.de with asmtp (WEB.DE 4.109 #226) id 1KP9E2-0002Oi-00; Sat, 02 Aug 2008 07:00:18 +0200 Date: Sat, 2 Aug 2008 07:00:15 +0200 From: Martin To: Jeremy Chadwick Message-ID: <20080802070015.7f64c862@web.de> In-Reply-To: <20080801124224.GA17183@eos.sc1.parodius.com> References: <20080801142005.473c17ca@zelda.local> <20080801124224.GA17183@eos.sc1.parodius.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX1+0iiGs6Q1kppAgSxbWtisZe9tmaE2J3DOUUEGk 7A7H7JqEuG/cAwBnB2T+FbgNPScg3cCslMkOT99ZwVa4jXbMoP rLhB66mzI= Cc: freebsd-stable@freebsd.org Subject: Re: em(4) on FreeBSD is sometimes annoying 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, 02 Aug 2008 05:00:20 -0000 On Fri, 1 Aug 2008 05:42:24 -0700 Jeremy Chadwick wrote: Hi Jeremy, > Most commonly what you're reporting is the result of a switch upstream > which isn't fully compatible or properly doing 802.3u auto-neg. It is attached to a cheap switch here. Also at my office it is not coming up. And I have NEVER this problem when the laptop is already plugged in. > Rebooting the machine (thus tearing down link hard, and resetting the > entire chip) often works in this situation. You can also try setting > the speed and duplex (media and mediaopt) in your ifconfig_emX line in > rc.conf to see if that helps (on some switches it does). This is what I get, when I plug it in and try to configure something: # ifconfig em0 mediaopt full-duplex ifconfig: SIOCSIFMEDIA (media): Device not configured But it accepts up, down and even inet
. LEDs are off and still "no carrier". > The behaviour you're reporting I've seen on old 3Com XL 509x cards with > Cisco switches, for example. I've heard of the autonegotiation problem, but it rather looks to my as if something is getting initialized during BIOS boot and FreeBSD is not doing it correctly. > I have a Thinkpad T60p. I'll try booting FreeBSD on it next week and > see if I can reproduce the behaviour. I'll also include what switch > brands/models are being plugged into. Once again. I made a mistake describing the problem. I'm really sorry for this. The interface actually appears in the ifconfig list, but I cannot get it up. It always shows "no carrier". No matter what I try. -- Martin From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 06:22:27 2008 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 D4C731065671 for ; Sat, 2 Aug 2008 06:22:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 95D2D8FC12 for ; Sat, 2 Aug 2008 06:22:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m726KOmM006709; Sat, 2 Aug 2008 00:20:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 02 Aug 2008 00:20:39 -0600 (MDT) Message-Id: <20080802.002039.58462077.imp@bsdimp.com> To: fbsd2@yahoo.com From: "M. Warner Losh" In-Reply-To: <372128.56919.qm@web51502.mail.re2.yahoo.com> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ? 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, 02 Aug 2008 06:22:27 -0000 In message: <372128.56919.qm@web51502.mail.re2.yahoo.com> fbsd2 writes: : Greetings list, : : Given recent EOL announcements, I'm trying to upgrade an ancient machine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster box. I've seen : : http://www.freebsd.org/releases/7.0R/relnotes.html and : http://marc.info/?l=freebsd-stable&m=121278826119286&w=2 : : which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 might not fit in an 80 Mb /. Must I partition a new disk to give more space to /, or can I find more space by deleting /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA Doesn't look like anybody has answered this question... 80MB is plenty, even for 7.x. However, you'll have to use nanobsd or tinybsd to get that small. You'll likely been unable to do a 'make installworld' to get this size. You'll have to create an image and push it over to this machine somehow. In the 3.x time frame, I had FreeBSD booting with the standard scripts in 13MB without compression. 4.x, 5.x and 6.x bloated these binaries to about 18MB (a few more were added). I haven't built a system based on 7.x with this system due to a change in employment, but expect that it wouldn't be much larger than 20MB for these same files. Some careful honing could reduce that a little, but maybe not a lot. Typical embedded systems that I shipped were on the order of 24MB without X11 and 32-60MB for those with an X11 server. What's this box used for? Warner From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 06:35:43 2008 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 7A1931065675 for ; Sat, 2 Aug 2008 06:35:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 13CFC8FC1B for ; Sat, 2 Aug 2008 06:35:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 m726ZXdq063079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Aug 2008 09:35:33 +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.2/8.14.2) with ESMTP id m726ZXd6003203; Sat, 2 Aug 2008 09:35:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m726ZXx2003202; Sat, 2 Aug 2008 09:35:33 +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: Sat, 2 Aug 2008 09:35:33 +0300 From: Kostik Belousov To: "M. Warner Losh" Message-ID: <20080802063533.GO97161@deviant.kiev.zoral.com.ua> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ensexbfp9Ul6anXl" Content-Disposition: inline In-Reply-To: <20080802.002039.58462077.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: fbsd2@yahoo.com, freebsd-stable@freebsd.org Subject: Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ? 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, 02 Aug 2008 06:35:43 -0000 --ensexbfp9Ul6anXl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 02, 2008 at 12:20:39AM -0600, M. Warner Losh wrote: > In message: <372128.56919.qm@web51502.mail.re2.yahoo.com> > fbsd2 writes: > : Greetings list, > :=20 > : Given recent EOL announcements, I'm trying to upgrade an ancient mac= hine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/= , /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, = and /usr/ports from a slightly newer/faster box. I've seen > :=20 > : http://www.freebsd.org/releases/7.0R/relnotes.html and > : http://marc.info/?l=3Dfreebsd-stable&m=3D121278826119286&w=3D2 > :=20 > : which seem to suggest that even with INSTALL_NODEBUG during buildkernel= , 7 might not fit in an 80 Mb /. Must I partition a new disk to give more = space to /, or can I find more space by deleting /stand/, /modules/, and po= ssibly /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA >=20 > Doesn't look like anybody has answered this question... >=20 > 80MB is plenty, even for 7.x. However, you'll have to use nanobsd or > tinybsd to get that small. You'll likely been unable to do a 'make > installworld' to get this size. You'll have to create an image and > push it over to this machine somehow. >=20 > In the 3.x time frame, I had FreeBSD booting with the standard scripts > in 13MB without compression. 4.x, 5.x and 6.x bloated these binaries > to about 18MB (a few more were added). I haven't built a system based > on 7.x with this system due to a change in employment, but expect that > it wouldn't be much larger than 20MB for these same files. Some > careful honing could reduce that a little, but maybe not a lot. > Typical embedded systems that I shipped were on the order of 24MB > without X11 and 32-60MB for those with an X11 server. >=20 > What's this box used for? Actually, on the normal RELENG_7/i386 install (i.e. done by buildworld/installworld), I get Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 257998 50422 186938 21% / /dev/ad0s1e 4129310 143676 3655290 4% /usr Note that you must supply INSTALL_NODEBUG=3Dyes for installkernel, and the numbers shown are for WITHOUT_PROFILE=3Dyes. Amd64 takes ~230Mb for merged / and /usr, this is both due to increased binary sizes and lib32. --ensexbfp9Ul6anXl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiUADQACgkQC3+MBN1Mb4iy3gCfYFpptXtjvAWKmcUW2FUsGkSw wrMAn0xCENPbGyjnr9cUpERlbD2oCstR =JIjY -----END PGP SIGNATURE----- --ensexbfp9Ul6anXl-- From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 06:58:06 2008 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 83DB8106564A for ; Sat, 2 Aug 2008 06:58:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 259108FC18 for ; Sat, 2 Aug 2008 06:58:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m726v3r2006972; Sat, 2 Aug 2008 00:57:03 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 02 Aug 2008 00:57:19 -0600 (MDT) Message-Id: <20080802.005719.-75255160.imp@bsdimp.com> To: kostikbel@gmail.com From: "M. Warner Losh" In-Reply-To: <20080802063533.GO97161@deviant.kiev.zoral.com.ua> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <20080802063533.GO97161@deviant.kiev.zoral.com.ua> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: fbsd2@yahoo.com, freebsd-stable@freebsd.org Subject: Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ? 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, 02 Aug 2008 06:58:06 -0000 In message: <20080802063533.GO97161@deviant.kiev.zoral.com.ua> Kostik Belousov writes: : > : Given recent EOL announcements, I'm trying to upgrade an ancient machine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster box. I've seen : > : : > : http://www.freebsd.org/releases/7.0R/relnotes.html and : > : http://marc.info/?l=freebsd-stable&m=121278826119286&w=2 : > : : > : which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 might not fit in an 80 Mb /. Must I partition a new disk to give more space to /, or can I find more space by deleting /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA : > : > Doesn't look like anybody has answered this question... : > : > 80MB is plenty, even for 7.x. However, you'll have to use nanobsd or : > tinybsd to get that small. You'll likely been unable to do a 'make : > installworld' to get this size. You'll have to create an image and : > push it over to this machine somehow. : > : > In the 3.x time frame, I had FreeBSD booting with the standard scripts : > in 13MB without compression. 4.x, 5.x and 6.x bloated these binaries : > to about 18MB (a few more were added). I haven't built a system based : > on 7.x with this system due to a change in employment, but expect that : > it wouldn't be much larger than 20MB for these same files. Some : > careful honing could reduce that a little, but maybe not a lot. : > Typical embedded systems that I shipped were on the order of 24MB : > without X11 and 32-60MB for those with an X11 server. : > : > What's this box used for? : : Actually, on the normal RELENG_7/i386 install (i.e. done by : buildworld/installworld), I get : : Filesystem 1K-blocks Used Avail Capacity Mounted on : /dev/ad0s1a 257998 50422 186938 21% / : /dev/ad0s1e 4129310 143676 3655290 4% /usr : : Note that you must supply INSTALL_NODEBUG=yes for installkernel, and : the numbers shown are for WITHOUT_PROFILE=yes. : : Amd64 takes ~230Mb for merged / and /usr, this is both due to increased : binary sizes and lib32. Right, the numbers I quoted were for an opt-in system like tinybsd... They are good numbers to have at hand, since it is hard to buy flash media that's smaller than 1GB these days... Warner From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 06:59:31 2008 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 CBE981065677; Sat, 2 Aug 2008 06:59:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7B35D8FC18; Sat, 2 Aug 2008 06:59:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m726xTpn027203; Sat, 2 Aug 2008 02:59:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.2/8.14.2) with ESMTP id m726xS0M033443; Sat, 2 Aug 2008 02:59:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 95D501B5078; Sat, 2 Aug 2008 02:59:28 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080802065928.95D501B5078@freebsd-stable.sentex.ca> Date: Sat, 2 Aug 2008 02:59:28 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [releng_7 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: Sat, 02 Aug 2008 06:59:31 -0000 TB --- 2008-08-02 05:40:06 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-08-02 05:40:06 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2008-08-02 05:40:06 - cleaning the object tree TB --- 2008-08-02 05:40:28 - cvsupping the source tree TB --- 2008-08-02 05:40:28 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2008-08-02 05:40:37 - building world (CFLAGS=-O2 -pipe) TB --- 2008-08-02 05:40:37 - cd /src TB --- 2008-08-02 05:40:37 - /usr/bin/make -B buildworld >>> World build started on Sat Aug 2 05:40:38 UTC 2008 >>> 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 Sat Aug 2 06:45:50 UTC 2008 TB --- 2008-08-02 06:45:50 - generating LINT kernel config TB --- 2008-08-02 06:45:50 - cd /src/sys/pc98/conf TB --- 2008-08-02 06:45:50 - /usr/bin/make -B LINT TB --- 2008-08-02 06:45:50 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-08-02 06:45:50 - cd /src TB --- 2008-08-02 06:45:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Aug 2 06:45:50 UTC 2008 >>> 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 [...] machdep.o(.text+0xc82): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xc8c): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xd11): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xd1d): In function `init386': : undefined reference to `SMP_prvspace' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-08-02 06:59:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-08-02 06:59:28 - ERROR: failed to build lint kernel TB --- 2008-08-02 06:59:28 - tinderbox aborted TB --- 3873.09 user 405.55 system 4762.05 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 07:18:45 2008 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 53A3A106564A for ; Sat, 2 Aug 2008 07:18:45 +0000 (UTC) (envelope-from h.schmalzbauer@OmniLAN.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id D36078FC12 for ; Sat, 2 Aug 2008 07:18:44 +0000 (UTC) (envelope-from h.schmalzbauer@OmniLAN.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id m727Ih91070914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 2 Aug 2008 09:18:43 +0200 (CEST) (envelope-from h.schmalzbauer@OmniLAN.de) Message-ID: <48940A53.3000004@OmniLAN.de> Date: Sat, 02 Aug 2008 09:18:43 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.14 (X11/20080710) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBBE19ADCDDD0C0B23DEE92E4" Subject: newfs-msdos and default fat32 parameters 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, 02 Aug 2008 07:18:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBBE19ADCDDD0C0B23DEE92E4 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, lately I wanted to create some DOS bootable SD-Cards (for simply BIOS=20 updates, disk diagnostic tools etc...) After newfs_msdos -F32 -B VBR.bin (2.5G partition) the system just=20 didn't continue booting after the MBR was loaded (VBR.bin is a 3 sectors = dump of the DOS boot record which sys creates). When I directly wrote the dump back to sectors 63-65 and 69-71 the=20 system booted! So I took my hex glasses and found some unfortunate default parameters=20 of newfs_msdos. - MediaType is f0 but probably should read f8 (fixed disk) - The backup boot record should be located at offset 6, not 2. - There should be defined 63 hidden sectors With 'newfs_msdos -F32 -m 0xf8 -B VBR.bin -k 0x6 -o 63 -i 0x1 /dev/da6s1'= every thing was fine. I'm no expert, I just found some FAT info. maybe the current defaults=20 are wisley chosen. Maybe not? Best regards, -Harry --------------enigBBE19ADCDDD0C0B23DEE92E4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiUClMACgkQLDqVQ9VXb8gxpACgjQF431rTobR87z3zVVeD1e5T XSYAn0dXMKFzPtY9wubfSGiJvyHnfnxr =yy39 -----END PGP SIGNATURE----- --------------enigBBE19ADCDDD0C0B23DEE92E4-- From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 07:19:05 2008 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 7749E1065710 for ; Sat, 2 Aug 2008 07:19:05 +0000 (UTC) (envelope-from h.schmalzbauer@OmniLAN.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 02A628FC28 for ; Sat, 2 Aug 2008 07:19:04 +0000 (UTC) (envelope-from h.schmalzbauer@OmniLAN.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id m7276K5D070805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 2 Aug 2008 09:06:23 +0200 (CEST) (envelope-from h.schmalzbauer@OmniLAN.de) Message-ID: <4894075E.6090602@OmniLAN.de> Date: Sat, 02 Aug 2008 09:06:06 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.14 (X11/20080710) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig357B4BD2A8DA21F3761E9254" Subject: 'diskinfo' problem with eSATA device (initio 1611) 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, 02 Aug 2008 07:19:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig357B4BD2A8DA21F3761E9254 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, for quick harddrive tests (SMART, noise, backup etc..) I bought a very=20 nice "docking" station connected to my ICH9 SATA controller=20 (http://www.sharkoon.com/html/produkte/externe_gehaeuse/sata_quickport_pr= o/index_en.html) I can read/write to inserted disks, also smartctl works, but my=20 favourite test doesn't run: diskinfo -t /dev/ad10 returns: ioctl(DIOCGMEDIASIZE) failed, probably not a disk.: Inappropriate ioctl=20 for device The eSATA bridge is a initio 1611 chip. I have another external SATA enclosure and there is the same problem. Any ideas what the reason is and how to "fix"? Best regards, -Harry --------------enig357B4BD2A8DA21F3761E9254 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiUB2wACgkQLDqVQ9VXb8h3bACfRXb3MRVs7uAtcLr3c1DytFtF 8kMAoKsofEm22XzTkQnL+QDd18XntEhO =GxDn -----END PGP SIGNATURE----- --------------enig357B4BD2A8DA21F3761E9254-- From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 08:42:53 2008 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 1B956106567A for ; Sat, 2 Aug 2008 08:42:53 +0000 (UTC) (envelope-from h.schmalzbauer@OmniLAN.de) Received: from host.omnisec.de (host.omnisec.de [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 9BD1F8FC1D for ; Sat, 2 Aug 2008 08:42:52 +0000 (UTC) (envelope-from h.schmalzbauer@OmniLAN.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnisec.de (8.13.8/8.13.8) with ESMTP id m728gokr071742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 2 Aug 2008 10:42:51 +0200 (CEST) (envelope-from h.schmalzbauer@OmniLAN.de) Message-ID: <48941E0A.1040300@OmniLAN.de> Date: Sat, 02 Aug 2008 10:42:50 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.14 (X11/20080710) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4E207735A779C0665BACB647" Subject: Feature request dev.ata.X.detached=1 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, 02 Aug 2008 08:42:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4E207735A779C0665BACB647 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, while eSATA get's widle used I don't like to detach a channel first=20 before I can hotplug a new disk. Would it be possible to implement a sysctl which tells the controller at = boot time to keep some channels detached? Best regards, -Harry --------------enig4E207735A779C0665BACB647 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkiUHgoACgkQLDqVQ9VXb8i2EQCgpS0WC3bG0wuWhxCc77mZzREw 9pwAoJ4KfwTAg4L7GiPPftZjZ8kkomgj =Ier4 -----END PGP SIGNATURE----- --------------enig4E207735A779C0665BACB647-- From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 09:21:15 2008 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 69333106566B; Sat, 2 Aug 2008 09:21:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 147028FC1A; Sat, 2 Aug 2008 09:21:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m729LBIT072504; Sat, 2 Aug 2008 05:21:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [64.7.128.104]) by smtp2.sentex.ca (8.14.2/8.14.2) with ESMTP id m729LBW7050637; Sat, 2 Aug 2008 05:21:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-legacy.sentex.ca (Postfix, from userid 666) id 113CF241A2; Sat, 2 Aug 2008 05:21:19 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080802092119.113CF241A2@freebsd-legacy.sentex.ca> Date: Sat, 2 Aug 2008 05:21:19 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.3/7824/Thu Jul 24 21:48:33 2008 clamav-milter version 0.93 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [releng_6 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: Sat, 02 Aug 2008 09:21:15 -0000 TB --- 2008-08-02 08:08:10 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-08-02 08:08:10 - starting RELENG_6 tinderbox run for i386/pc98 TB --- 2008-08-02 08:08:10 - cleaning the object tree TB --- 2008-08-02 08:08:34 - cvsupping the source tree TB --- 2008-08-02 08:08:34 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/i386/pc98/supfile TB --- 2008-08-02 08:08:40 - building world (CFLAGS=-O2 -pipe) TB --- 2008-08-02 08:08:40 - cd /src TB --- 2008-08-02 08:08:40 - /usr/bin/make -B buildworld >>> 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 TB --- 2008-08-02 09:10:55 - generating LINT kernel config TB --- 2008-08-02 09:10:55 - cd /src/sys/pc98/conf TB --- 2008-08-02 09:10:55 - /usr/bin/make -B LINT TB --- 2008-08-02 09:10:55 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-08-02 09:10:55 - cd /src TB --- 2008-08-02 09:10:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Aug 2 09:10:55 UTC 2008 >>> 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 [...] machdep.o(.text+0xa92): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xa9c): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xaeb): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xaf8): In function `init386': : undefined reference to `SMP_prvspace' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-08-02 09:21:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-08-02 09:21:18 - ERROR: failed to build lint kernel TB --- 2008-08-02 09:21:18 - tinderbox aborted TB --- 3051.72 user 368.83 system 4388.99 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 10:55:58 2008 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 5BD46106566C for ; Sat, 2 Aug 2008 10:55:58 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 136098FC14 for ; Sat, 2 Aug 2008 10:55:57 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0K4Y00EEXZP6CWE0@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 02 Aug 2008 12:55:54 +0200 (CEST) Received: from kg-work.kg4.no ([80.202.72.251]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0K4Y00CPRZP5ENS0@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 02 Aug 2008 12:55:54 +0200 (CEST) Date: Sat, 02 Aug 2008 12:55:53 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20080802125553.d9c83a55.torfinn.ingolfsen@broadpark.no> In-reply-to: <20080802070015.7f64c862@web.de> References: <20080801142005.473c17ca@zelda.local> <20080801124224.GA17183@eos.sc1.parodius.com> <20080802070015.7f64c862@web.de> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd6.3) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: em(4) on FreeBSD is sometimes annoying 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, 02 Aug 2008 10:55:58 -0000 On Sat, 02 Aug 2008 07:00:15 +0200 Martin wrote: > Once again. I made a mistake describing the problem. I'm really sorry > for this. The interface actually appears in the ifconfig list, but I > cannot get it up. It always shows "no carrier". No matter what I try. Just to be sure: also if the first command you try on the interface is 'ifconfig up'? -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 17:34:49 2008 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 C8F411065673 for ; Sat, 2 Aug 2008 17:34:49 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7A18FC19 for ; Sat, 2 Aug 2008 17:34:48 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so2030801fkk.11 for ; Sat, 02 Aug 2008 10:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=oMnfW2oZ2K9DSZiMa8F+IaCrvZhb/pXnqB6lX1aV0A8=; b=eMkNAtIWepfPu8lPp2w6+LqCzHmj+ufqgavtza09WJ1nCKdVoP7Gy8/0WqHbA6GRmb kM6/vFfs5Z7zHwXASUKFJkzcEbD0chv337guy+7cbITLz6S0eI6W0tNvECVbRNWXCDOs qMpODjp1V0h+un2/xdcMxqrFEJ3vMd7KFs4/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=igy6fjWpc+11Eq9ewsOv3CdlnpsDsvvCE/9TXmd8Ynw6Y+15Ojp9veFdP05DzEqKCG jUeaxT5yVlSqwR0rpHmVLKYTLSHe3IquqDtjR0onW95ytTfjfHYqL6p9u+dd6+CEQjZN nNdc7b9DTzeheaQVZTGMxv0teLu9lDLvuhq+k= Received: by 10.125.151.16 with SMTP id d16mr622678mko.52.1217698488023; Sat, 02 Aug 2008 10:34:48 -0700 (PDT) Received: by 10.125.74.17 with HTTP; Sat, 2 Aug 2008 10:34:47 -0700 (PDT) Message-ID: <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> Date: Sat, 2 Aug 2008 10:34:47 -0700 From: "Jack Vogel" To: Martin In-Reply-To: <20080802064727.042d5e3d@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080801142005.473c17ca@zelda.local> <20080801154208.W6085@fledge.watson.org> <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> <20080802064727.042d5e3d@web.de> Cc: jfv@freebsd.org, freebsd-stable@freebsd.org, Robert Watson Subject: Re: em(4) on FreeBSD is sometimes annoying 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, 02 Aug 2008 17:34:49 -0000 On Fri, Aug 1, 2008 at 9:47 PM, Martin wrote: > On Fri, 1 Aug 2008 09:24:53 -0700 > "Jack Vogel" wrote: > >> If the poster gives me EXACT hardware list I will see about repro'ing the >> problem inhouse. We do not do much of anything with laptops but I >> will see. Oh and a pciconf would help too. > > Hi Jack, > > pciconf -lv gives me: > > em0@pci0:2:0:0: class=0x020000 card=0x200117aa chip=0x109a8086 > rev=0x00 hdr=0x00 vendor = 'Intel Corporation' > device = '82573L Intel PRO/1000 PL Network Adaptor' > class = network > subclass = ethernet > > > One thing, I have to add. I described the behavior wrong. The adapter > actually IS available in the interface list, but it gets "no carrier". > Sorry for that. > > This is what I get from ifconfig when the NIC is plugged in: > > em0: flags=8843 metric 0 mtu > 1500 options=19b > ether xx:xx:xx:xx:xx:xx > media: Ethernet autoselect > status: no carrier > > All LEDs are off. > > Device was found on boot: > > em0: port 0x3000-0x301f > mem 0xee000 000-0xee01ffff irq 16 at device 0.0 on pci2 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: xx:xx:xx:xx:xx:xx > > -- > Martin > Telling me what kind of NIC it is isn't going to help, 82573's are working the world over :) What exactly is your laptop, what model, is the NIC a LOM (on the motherboard) or some addin. Some random thoughts: There should be NO need to specify full duplex, if you have to do that then you have some problem with your switch. Are you loading the driver as a module, or is it static? So, if you do this: get a cable and eliminate any switch, just a back to back connection between two machines, then if you load the driver and ifconfig address up... what happens?? Jack From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 18:39:24 2008 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 D152A1065682 for ; Sat, 2 Aug 2008 18:39:24 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8CD578FC2E for ; Sat, 2 Aug 2008 18:39:24 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m72IdKSq026707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Aug 2008 11:39:20 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4894A9D8.2090606@freebsd.org> Date: Sat, 02 Aug 2008 11:39:20 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: "M. Warner Losh" References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> In-Reply-To: <20080802.002039.58462077.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: fbsd2@yahoo.com, freebsd-stable@freebsd.org Subject: Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ? 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, 02 Aug 2008 18:39:25 -0000 M. Warner Losh wrote: > In message: <372128.56919.qm@web51502.mail.re2.yahoo.com> > fbsd2 writes: > : Greetings list, > : > : Given recent EOL announcements, I'm trying to upgrade an ancient machine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster box. I've seen > : > : http://www.freebsd.org/releases/7.0R/relnotes.html and > : http://marc.info/?l=freebsd-stable&m=121278826119286&w=2 > : > : which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 might not fit in an 80 Mb /. Must I partition a new disk to give more space to /, or can I find more space by deleting /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA > > Doesn't look like anybody has answered this question... > > 80MB is plenty, even for 7.x. However, you'll have to use nanobsd or > tinybsd to get that small. You'll likely been unable to do a 'make > installworld' to get this size. You'll have to create an image and > push it over to this machine somehow. > > In the 3.x time frame, I had FreeBSD booting with the standard scripts > in 13MB without compression. 4.x, 5.x and 6.x bloated these binaries > to about 18MB (a few more were added). I haven't built a system based > on 7.x with this system due to a change in employment, but expect that > it wouldn't be much larger than 20MB for these same files. Some > careful honing could reduce that a little, but maybe not a lot. > Typical embedded systems that I shipped were on the order of 24MB > without X11 and 32-60MB for those with an X11 server. > > What's this box used for? > > I've been looking at nanobsd for a couple of applications and working to reduce the footprint of the images without hacking special rules. With the existing set of WITHOUT knobs in the build system you get a 48M image. With my additional knobs I have this down to 24M. There are still numerous bits of junk that must be removed with special rules unless I go the complete route and add WITHOUT knobs for just about everything. I'd much prefer an opt-in configuration scheme but wasn't keen on what I see in existing packaging systems. Like you I have my own packaging system (works on HEAD and RELENG_[4567] though stuff <7 is probably rotted) but hope to move away from it. In the long run I doubt nanobsd will work for a true embedded application (with my private tools my current RELENG_7 firewall is 10M and includes bind+dhcpd). The other area that I hope to improve on in nanobsd is build time. At the moment you're required to build a bunch of stuff just to throw it away. This is unacceptable with our current build times being so long. My main motivation for improving nanobsd is to offer it as a way to package embedded cross-builds. I've got examples to cross-build images for the AVILA board (it's trivial and I'm sure can be done by other systems like tinybsd so long as they use the buildworld infrastructure). To get past the current 24M barrier I'll need to attack individual applications. For example bind is currently huge and ancillary tools like dig are almost as big! I haven't looked at why but for my current firewall I crunchgen bind and related tools into an image together w/ various other bits. If we're ever to consider building images for flash parts (not compact flash) then we'll need to do a lot of work to pare down the bloat--or replace current apps w/ special purpose replacements a la busybox (not something I find appealing). Sam From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 20:40:50 2008 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 CC9411065670 for ; Sat, 2 Aug 2008 20:40:50 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate01.web.de (fmmailgate01.web.de [217.72.192.221]) by mx1.freebsd.org (Postfix) with ESMTP id 8467E8FC17 for ; Sat, 2 Aug 2008 20:40:50 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate01.web.de (Postfix) with ESMTP id BCC0CEA162AB; Sat, 2 Aug 2008 22:40:48 +0200 (CEST) Received: from [217.236.1.240] (helo=localhost) by smtp08.web.de with asmtp (WEB.DE 4.109 #226) id 1KPNuC-0007Oa-00; Sat, 02 Aug 2008 22:40:48 +0200 Date: Sat, 2 Aug 2008 22:40:46 +0200 From: Martin To: Torfinn Ingolfsen Message-ID: <20080802224046.3b547283@web.de> In-Reply-To: <20080802125553.d9c83a55.torfinn.ingolfsen@broadpark.no> References: <20080801142005.473c17ca@zelda.local> <20080801124224.GA17183@eos.sc1.parodius.com> <20080802070015.7f64c862@web.de> <20080802125553.d9c83a55.torfinn.ingolfsen@broadpark.no> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX18O38PoU+3jVU2VBBFeJ6y+OCyaFdm5q0nREOYZ ENuITbODP9GkEjOqOI4CmpHSPMTC14bMkz3VOplGFVq0JfcPCI 1XJAR/gJM= Cc: freebsd-stable@freebsd.org Subject: Re: em(4) on FreeBSD is sometimes annoying 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, 02 Aug 2008 20:40:50 -0000 On Sat, 02 Aug 2008 12:55:53 +0200 Torfinn Ingolfsen wrote: > Just to be sure: also if the first command you try on the interface is > 'ifconfig up'? Hello Torfinn, good point, no. The problem appears when the first thing called on this interface is dhclient (caused by ifconfig_em0="DHCP"). I could also provoke this behavior after the interface was once up had an IP and was working (ping). All I need to do is to disconnect the NIC from the switch when I type "/etc/rc.d/netif restart". I have noticed further strange effects here. The behavior seems to be even more complex. After I typed "/etc/rc.d/netif restart", I waited until I get "giving up" message. Then I plugged the cable in. After about 30 seconds the link LED was on. I noticed that at this point I couldn't get an address using DHCP. So I disconnected physically the NIC (no cable) and link LED was still on! ifconfig showed me "state: active" with no cable plugged in. After further 30 seconds the LED went off. I attached the NIC again to the switch again and after 30 seconds again I got some other effect. The link LED went on (status: active) and the data LED was permanently blinking (about 2,5 times a second). I pulled the cable again and now the link LED is still on and the data LED still blinking (since about 10 minutes already). By the way... Now I'm typing this E-Mail without an ethernet cable plugged in and the link status LED is still on and the other data LED is blinking. -- Martin From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 21:15:35 2008 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 B9F8B1065677 for ; Sat, 2 Aug 2008 21:15:35 +0000 (UTC) (envelope-from ebutusov@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.238]) by mx1.freebsd.org (Postfix) with ESMTP id 6A3F28FC1A for ; Sat, 2 Aug 2008 21:15:35 +0000 (UTC) (envelope-from ebutusov@gmail.com) Received: by qb-out-0506.google.com with SMTP id e34so1887182qbe.35 for ; Sat, 02 Aug 2008 14:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=5YCXWVZgHmrn4b85jj0IweRYWZEwoRDLTv8o+vMqY6I=; b=M+mkQTf8PUlZvjQxI3HFgon/pMnR/72/5CJ1I0oqWHaxPymqMMkjVx2EJg8CDCrEFZ hT/L0sMHHP/v361AFoxRuwISmyeAUjeeIHDwvUhuv1UUmMvgCruvKvyxth61tLWpl9Fy xcrDHL9h8RtaHMKC/9gT+CW3XYSuusIfegVpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=MoXoUy61FW8uixGK8RSqnqBAEbKKUWB2N8FvrlR4SXWHNC7c2nUGz2LZCnJYzSret+ rZ0AkOGVuJDWK42qfQLTThoKbr+pNpKCePB0AvQSAxrRrY5v0l152K+wMjFvBY4HIusZ 9ZdjOwEVbTDiHQAjF9PAI682hvntKpmuXmY/Y= Received: by 10.67.15.15 with SMTP id s15mr5140452ugi.28.1217711733054; Sat, 02 Aug 2008 14:15:33 -0700 (PDT) Received: from ?192.168.0.51? ( [195.136.67.137]) by mx.google.com with ESMTPS id 30sm18813237ugf.63.2008.08.02.14.15.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 14:15:32 -0700 (PDT) Message-ID: <4894CE6D.2000204@gmail.com> Date: Sat, 02 Aug 2008 23:15:25 +0200 From: Eugene Butusov User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: FreeBSD-STABLE-LIST Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: 7-STABLE, gjournal and fsck. 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, 02 Aug 2008 21:15:35 -0000 Hi, Recently I've decided to play with gjournal. Main reason was a promise of avoiding full fsck check after unclean shutdown. I've successfuly configured gjournal on existing filesystems (all UFS). And then it happened - my system had a power failure. After boot, it forced me to run fsck manualy. Nothing special, I did it before... But this time it failed on gjournaled disks. So, when I was dropped to the single-user shell, I tried: fsck /dev/ad4s1g.journal It said: CANNOT READ BLK: xxxx CONTINUE? [yn] I typed 'y' and nothing happened. Here is the log: -8<- Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 4059706613: ad4s1g contains data. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 4059706613: ad4s1g contains journal. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad4s1g clean. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 188084099: ad6s1d contains data. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 188084099: ad6s1d contains journal. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad6s1d clean. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 2559963968: ad6s1e contains data. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 2559963968: ad6s1e contains journal. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad6s1e clean. ... Aug 2 19:13:43 matrix kernel: ** /dev/ad4s1g.journal Aug 2 19:13:43 matrix kernel: Aug 2 19:13:43 matrix kernel: CANNOT READ BLK: 727112224 Aug 2 19:13:43 matrix kernel: CONTINUE? [yn] Aug 2 19:13:43 matrix kernel: Aug 2 19:13:43 matrix kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ: 727112224, 727112225, 727112226, 727112227, Aug 2 19:13:43 matrix kernel: /dev/ad4s1g.journal: CANNOT FIGURE OUT FILE SYSTEM PARTITION ->8- After ctrl+d the system tried to continue boot, and again threw me into shell because of the same reason: -8<- Aug 2 19:13:43 matrix kernel: WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck Aug 2 19:13:43 matrix kernel: mount: ->8- Like I mentioned, only gjournaled filesystems failed to pass fsck. Other labels passed. I was in a hurry, because the machine acts as a local file server, and I was standing against the wall, because one of gjournaled disks was the share itself... What I did was mounting gjournaled partitions in ro mode (it warned me that they were not cleanly unmounted) and doing some backup. Then I removed gjournal (gjournal clear, tunefs -J disable) from journaled disks, ran fsck (few errors of type: PARTIALLY ALLOCATED INODE), and then I was able to turn on softupdates back and mount the fs in rw mode. I've double checked the disk's SMART results in case of hardware failure, but they were ok. My question is: what could cause such problem? Why only gjournaled fs are affected? Is there a solution? Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 21:50:12 2008 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 45BB71065679 for ; Sat, 2 Aug 2008 21:50:12 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id EFB508FC1B for ; Sat, 2 Aug 2008 21:50:11 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0K4Z00JUXTZMT640@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 02 Aug 2008 23:50:10 +0200 (CEST) Received: from kg-work.kg4.no ([80.202.72.251]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0K4Z00JQQTZMOT12@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 02 Aug 2008 23:50:10 +0200 (CEST) Date: Sat, 02 Aug 2008 23:50:10 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20080802235010.facd4cb9.torfinn.ingolfsen@broadpark.no> In-reply-to: <20080802224046.3b547283@web.de> References: <20080801142005.473c17ca@zelda.local> <20080801124224.GA17183@eos.sc1.parodius.com> <20080802070015.7f64c862@web.de> <20080802125553.d9c83a55.torfinn.ingolfsen@broadpark.no> <20080802224046.3b547283@web.de> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd6.3) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: em(4) on FreeBSD is sometimes annoying 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, 02 Aug 2008 21:50:12 -0000 On Sat, 02 Aug 2008 22:40:46 +0200 Martin wrote: > good point, no. The problem appears when the first thing called on > this interface is dhclient (caused by ifconfig_em0="DHCP"). I could So, if you don't automatically configure the interface, but instead do something like: 'ifconfig em0 up' and then the DHCP stuff does the interface work then? -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 21:58:14 2008 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 51B64106566C for ; Sat, 2 Aug 2008 21:58:14 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3EA098FC33 for ; Sat, 2 Aug 2008 21:58:14 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 27A961CC0B7; Sat, 2 Aug 2008 14:58:14 -0700 (PDT) Date: Sat, 2 Aug 2008 14:58:14 -0700 From: Jeremy Chadwick To: Eugene Butusov Message-ID: <20080802215814.GA20164@eos.sc1.parodius.com> References: <4894CE6D.2000204@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4894CE6D.2000204@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD-STABLE-LIST Subject: Re: 7-STABLE, gjournal and fsck. 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, 02 Aug 2008 21:58:14 -0000 On Sat, Aug 02, 2008 at 11:15:25PM +0200, Eugene Butusov wrote: > Aug 2 19:13:43 matrix kernel: ** /dev/ad4s1g.journal > Aug 2 19:13:43 matrix kernel: > Aug 2 19:13:43 matrix kernel: CANNOT READ BLK: 727112224 > Aug 2 19:13:43 matrix kernel: CONTINUE? [yn] > Aug 2 19:13:43 matrix kernel: > Aug 2 19:13:43 matrix kernel: THE FOLLOWING DISK SECTORS COULD NOT BE > READ: 727112224, 727112225, 727112226, 727112227, > Aug 2 19:13:43 matrix kernel: /dev/ad4s1g.journal: CANNOT FIGURE OUT > FILE SYSTEM PARTITION > ... > I've double checked the disk's SMART results in case of hardware > failure, but they were ok. > > My question is: what could cause such problem? Why only gjournaled fs > are affected? Is there a solution? 1) What brand of disks are these? Can you show them in dmesg? 2) Can you provide smartctl -a /dev/ad4 output please? -- | Jeremy Chadwick jdc at 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 Aug 2 22:07:38 2008 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 23973106566B for ; Sat, 2 Aug 2008 22:07:38 +0000 (UTC) (envelope-from jille@quis.cx) Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7C68FC13 for ; Sat, 2 Aug 2008 22:07:37 +0000 (UTC) (envelope-from jille@quis.cx) Received: (qmail 2913 invoked by uid 0); 2 Aug 2008 21:40:55 -0000 Received: from ip83-113-174-82.adsl2.static.versatel.nl (HELO istud.quis.cx) ([82.174.113.83]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 2 Aug 2008 21:40:55 -0000 Received: from [192.168.1.4] (ille [192.168.1.4]) by istud.quis.cx (Postfix) with ESMTP id E13055C1D; Sat, 2 Aug 2008 23:40:54 +0200 (CEST) Message-ID: <4894D462.5@quis.cx> Date: Sat, 02 Aug 2008 23:40:50 +0200 From: Jille User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eugene Butusov References: <4894CE6D.2000204@gmail.com> In-Reply-To: <4894CE6D.2000204@gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE-LIST Subject: Re: 7-STABLE, gjournal and fsck. 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, 02 Aug 2008 22:07:38 -0000 Hello, I also had those "PARTIALLY ALLOCATED INODE", errors. They only happened on one disk (SATA with PCI SATA converter), and my other ATA disks worked fine. I unplugged my SATA disk, and the ATA's started giving errors. Well, whatever, I screwed up my hardware with a really dumb mistake (don't even dare telling you) and that let it give some quite random errors. So you might want to do some real good hardware checks ;) -- Jille Eugene Butusov schreef: > Hi, > > Recently I've decided to play with gjournal. Main reason was a promise > of avoiding full fsck check after unclean shutdown. I've successfuly > configured gjournal on existing filesystems (all UFS). And then it > happened - my system had a power failure. After boot, it forced me to > run fsck manualy. Nothing special, I did it before... But this time it > failed on gjournaled disks. > > So, when I was dropped to the single-user shell, I tried: > > fsck /dev/ad4s1g.journal > > It said: > > CANNOT READ BLK: xxxx > CONTINUE? [yn] > > I typed 'y' and nothing happened. Here is the log: > > -8<- > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 4059706613: ad4s1g > contains data. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 4059706613: ad4s1g > contains journal. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad4s1g clean. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 188084099: ad6s1d > contains data. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 188084099: ad6s1d > contains journal. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad6s1d clean. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 2559963968: ad6s1e > contains data. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 2559963968: ad6s1e > contains journal. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad6s1e clean. > ... > Aug 2 19:13:43 matrix kernel: ** /dev/ad4s1g.journal > Aug 2 19:13:43 matrix kernel: > Aug 2 19:13:43 matrix kernel: CANNOT READ BLK: 727112224 > Aug 2 19:13:43 matrix kernel: CONTINUE? [yn] > Aug 2 19:13:43 matrix kernel: > Aug 2 19:13:43 matrix kernel: THE FOLLOWING DISK SECTORS COULD NOT BE > READ: 727112224, 727112225, 727112226, 727112227, > Aug 2 19:13:43 matrix kernel: /dev/ad4s1g.journal: CANNOT FIGURE OUT > FILE SYSTEM PARTITION > ->8- > > After ctrl+d the system tried to continue boot, and again threw me into > shell because of the same reason: > > -8<- > Aug 2 19:13:43 matrix kernel: > WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck > Aug 2 19:13:43 matrix kernel: mount: > ->8- > > Like I mentioned, only gjournaled filesystems failed to pass fsck. Other > labels passed. I was in a hurry, because the machine acts as a local > file server, and I was standing against the wall, because one of > gjournaled disks was the share itself... > > What I did was mounting gjournaled partitions in ro mode (it warned me > that they were not cleanly unmounted) and doing some backup. Then I > removed gjournal (gjournal clear, tunefs -J disable) from journaled > disks, ran fsck (few errors of type: PARTIALLY ALLOCATED INODE), and > then I was able to turn on softupdates back and mount the fs in rw mode. > I've double checked the disk's SMART results in case of hardware > failure, but they were ok. > > My question is: what could cause such problem? Why only gjournaled fs > are affected? Is there a solution? > > Best regards, From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 22:14:47 2008 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 AB0961065680 for ; Sat, 2 Aug 2008 22:14:47 +0000 (UTC) (envelope-from ebutusov@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.231]) by mx1.freebsd.org (Postfix) with ESMTP id 5A5C68FC13 for ; Sat, 2 Aug 2008 22:14:47 +0000 (UTC) (envelope-from ebutusov@gmail.com) Received: by qb-out-0506.google.com with SMTP id e34so1906611qbe.35 for ; Sat, 02 Aug 2008 15:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=cLP7NyMTsyG3qEQOYXqTNAfBvks1vpLFHbvnTHZNWrQ=; b=T06p8bw68ZrxdE7jcXdbTOxLlfzc1WvBzzSGlpSSIqwE6mCBeCG7q1bKo8j16yohXs hxKJksZxnvUIV5Ch85RZ98BDrAG7JYLOa15sPkzqZYrvkp29WhG1XIev/X15UxhEOkTk f18m/1lAipWFrym+vfqDs/PWnYhVRCORjMdZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Ov+b6MYRlc5oyqwE0kHttEs5FTzXYc1mGc5cuzPPni9odY8v2861YYcGCEUE36oX5c /E17eVjLC+acYYJ692a0FihLwnqsRtB/OXZeAp4Sim7dvE61GjCEeOeVVReoNu0hgMhZ Q9JMGcA3qyh92DRzv66D5LdyS/H1JLpxRbK0A= Received: by 10.210.110.5 with SMTP id i5mr6692881ebc.24.1217715284998; Sat, 02 Aug 2008 15:14:44 -0700 (PDT) Received: from ?192.168.0.51? ( [195.136.67.137]) by mx.google.com with ESMTPS id d2sm3799726nfc.31.2008.08.02.15.14.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 15:14:43 -0700 (PDT) Message-ID: <4894DC4C.7030001@gmail.com> Date: Sun, 03 Aug 2008 00:14:36 +0200 From: Eugene Butusov User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Jeremy Chadwick References: <4894CE6D.2000204@gmail.com> <20080802215814.GA20164@eos.sc1.parodius.com> In-Reply-To: <20080802215814.GA20164@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE-LIST Subject: Re: 7-STABLE, gjournal and fsck. 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, 02 Aug 2008 22:14:47 -0000 Jeremy Chadwick wrote: > On Sat, Aug 02, 2008 at 11:15:25PM +0200, Eugene Butusov wrote: >> Aug 2 19:13:43 matrix kernel: ** /dev/ad4s1g.journal >> Aug 2 19:13:43 matrix kernel: >> Aug 2 19:13:43 matrix kernel: CANNOT READ BLK: 727112224 >> Aug 2 19:13:43 matrix kernel: CONTINUE? [yn] >> Aug 2 19:13:43 matrix kernel: >> Aug 2 19:13:43 matrix kernel: THE FOLLOWING DISK SECTORS COULD NOT BE >> READ: 727112224, 727112225, 727112226, 727112227, >> Aug 2 19:13:43 matrix kernel: /dev/ad4s1g.journal: CANNOT FIGURE OUT >> FILE SYSTEM PARTITION >> ... >> I've double checked the disk's SMART results in case of hardware >> failure, but they were ok. >> >> My question is: what could cause such problem? Why only gjournaled fs >> are affected? Is there a solution? > > 1) What brand of disks are these? Can you show them in dmesg? > 2) Can you provide smartctl -a /dev/ad4 output please? > Here it is: 1) dmesg | grep WDC > ad4: 476940MB at ata2-master SATA150 ad6: 476940MB at ata3-master SATA150 2) smartctl -a /dev/ad4 > smartctl version 5.37 [i386-portbld-freebsd7.0] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: WDC WD5000AAKS-00A7B0 Serial Number: WD-WMASY1630383 Firmware Version: 01.03B01 User Capacity: 500 107 862 016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Sun Aug 3 00:10:53 2008 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (10800) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 127) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 155 155 021 Pre-fail Always - 5208 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 9 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 051 Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 192 10 Spin_Retry_Count 0x0032 100 253 051 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 051 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 9 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 8 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 9 194 Temperature_Celsius 0x0022 112 102 000 Old_age Always - 35 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 100 253 051 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 22:54:40 2008 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 A83F8106568A for ; Sat, 2 Aug 2008 22:54:40 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 5D78C8FC17 for ; Sat, 2 Aug 2008 22:54:39 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 270757308E; Sun, 3 Aug 2008 00:56:43 +0200 (CEST) Date: Sun, 3 Aug 2008 00:56:43 +0200 From: Luigi Rizzo To: Sam Leffler Message-ID: <20080802225643.GA84798@onelab2.iet.unipi.it> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4894A9D8.2090606@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: fbsd2@yahoo.com, freebsd-stable@freebsd.org Subject: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) 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, 02 Aug 2008 22:54:40 -0000 On Sat, Aug 02, 2008 at 11:39:20AM -0700, Sam Leffler wrote: ... > I've been looking at nanobsd for a couple of applications and working to > reduce the footprint of the images without hacking special rules. With ... > If we're ever to consider building images for flash parts (not compact > flash) then we'll need to do a lot of work to pare down the bloat--or > replace current apps w/ special purpose replacements a la busybox (not > something I find appealing). related to this thread -- does anyone have experience in trying to build busybox on FreeBSD ? Also, what would you suggest as a small scripting language to be used in this kind of platform for implementing CGI scripts (and preferably able to use sockets/select) ? The various perl/python/php and friend are in the 10MB range once you pick up a little bit of libraries (sockets etc) and the tangle of modules they require; awk (which is present in busybox) is ok-ish for some things, but doing I/O and calling external programs with it is very unfriendly; javascript/spidermonkey is on the 500KB range but it doesn't have a library to play with sockets... cheers luigi From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 23:01:37 2008 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 CE013106566B for ; Sat, 2 Aug 2008 23:01:37 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by mx1.freebsd.org (Postfix) with ESMTP id 54C688FC0C for ; Sat, 2 Aug 2008 23:01:37 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so2142617fkk.11 for ; Sat, 02 Aug 2008 16:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=nKa/SM37/X5qPi4HQ4Oxsf9DzYzE8W5k0p09NiWZfNk=; b=ZEjzTvA0qBqMU63aF4jiBuIkhN7GNkfeptfFiVOJDAA5bcJvZs9rx/elG3kqBXpS5O h1CbVBYNNUI5/RhKj2WfMDxuX173lD5FZCyR6PRfG0I7OJwxIOld6QDkOwm5IP3T3u0y iIY8vPqSqiWni8TA9Vo8gKvGyYmaRMx0kHv0E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=lq9PpOnvc6sMPFK1u3ClmQLhIITIvhmbpX8wvcfilg0J23Qror0ilH+IM7TXTlsai1 7qtQGsJQaDHdfFZkS7BQFfR5NlLYhKZmhn9ngujeQbbeuZvGjK9lLfh/qO5+kHbtFTtr kVEz3PsYlvjhakR/p3WHb4tmo4F9WvuFmJ6uM= Received: by 10.125.89.10 with SMTP id r10mr630004mkl.77.1217718095884; Sat, 02 Aug 2008 16:01:35 -0700 (PDT) Received: by 10.125.74.17 with HTTP; Sat, 2 Aug 2008 16:01:35 -0700 (PDT) Message-ID: <2a41acea0808021601u13147294r9dc44a737119648@mail.gmail.com> Date: Sat, 2 Aug 2008 16:01:35 -0700 From: "Jack Vogel" To: Martin In-Reply-To: <20080802224046.3b547283@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080801142005.473c17ca@zelda.local> <20080801124224.GA17183@eos.sc1.parodius.com> <20080802070015.7f64c862@web.de> <20080802125553.d9c83a55.torfinn.ingolfsen@broadpark.no> <20080802224046.3b547283@web.de> Cc: Torfinn Ingolfsen , freebsd-stable@freebsd.org Subject: Re: em(4) on FreeBSD is sometimes annoying 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, 02 Aug 2008 23:01:38 -0000 On Sat, Aug 2, 2008 at 1:40 PM, Martin wrote: > On Sat, 02 Aug 2008 12:55:53 +0200 > Torfinn Ingolfsen wrote: > >> Just to be sure: also if the first command you try on the interface is >> 'ifconfig up'? > > Hello Torfinn, > > good point, no. The problem appears when the first thing called on this > interface is dhclient (caused by ifconfig_em0="DHCP"). I could also > provoke this behavior after the interface was once up had an IP and was > working (ping). All I need to do is to disconnect the NIC from the > switch when I type "/etc/rc.d/netif restart". > > I have noticed further strange effects here. The behavior seems to > be even more complex. > > After I typed "/etc/rc.d/netif restart", I waited until I get "giving > up" message. Then I plugged the cable in. After about 30 seconds the > link LED was on. I noticed that at this point I couldn't get an address > using DHCP. Well DUH, the agent exited, thats why it said "giving up" :) That ain't complex behavior, its behaving as designed. > So I disconnected physically the NIC (no cable) and link LED was > still on! ifconfig showed me "state: active" with no cable plugged in. > After further 30 seconds the LED went off. > > I attached the NIC again to the switch again and after 30 seconds > again I got some other effect. The link LED went on (status: active) > and the data LED was permanently blinking (about 2,5 times a second). I > pulled the cable again and now the link LED is still on and the data > LED still blinking (since about 10 minutes already). Ya, so the update is slow, the fact that the LED is blinking means you have an autoneg failure, so again, its your switch not the NIC. Let me guess, you have some 100Mb home router and you are trying to plug a gig nic into it and forcing the speed maybe? I asked for a hardware list, now that includes the switch. Jack From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 23:06:27 2008 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 23F841065676 for ; Sat, 2 Aug 2008 23:06:27 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF578FC08 for ; Sat, 2 Aug 2008 23:06:26 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id C80251CC0B4; Sat, 2 Aug 2008 16:06:26 -0700 (PDT) Date: Sat, 2 Aug 2008 16:06:26 -0700 From: Jeremy Chadwick To: Eugene Butusov Message-ID: <20080802230626.GA24435@eos.sc1.parodius.com> References: <4894CE6D.2000204@gmail.com> <20080802215814.GA20164@eos.sc1.parodius.com> <4894DC4C.7030001@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4894DC4C.7030001@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD-STABLE-LIST Subject: Re: 7-STABLE, gjournal and fsck. 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, 02 Aug 2008 23:06:27 -0000 On Sun, Aug 03, 2008 at 12:14:36AM +0200, Eugene Butusov wrote: > 2) smartctl -a /dev/ad4 > ... > 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 > 200 Multi_Zone_Error_Rate 0x0008 100 253 051 Old_age Offline - 0 > ... The other SMART stats look okay, but can you run an offline test which should update counters 198 and 200? smartctl -t offline /dev/ad4 should do the trick. It may take some time, especially if the disk is being used. And for clarification: just because the test is called "offline" does not mean it brings the disk offline (it doesn't). :-) -- | Jeremy Chadwick jdc at 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 Aug 2 23:07:48 2008 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 47CEC106567C for ; Sat, 2 Aug 2008 23:07:48 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id EA4288FC1B for ; Sat, 2 Aug 2008 23:07:47 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from Macintosh-4.local ([10.0.0.194]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m72N7lYX028357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Aug 2008 16:07:47 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4894E8C3.5060004@freebsd.org> Date: Sat, 02 Aug 2008 16:07:47 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Luigi Rizzo References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> In-Reply-To: <20080802225643.GA84798@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: ebb.errno.com; whitelist Cc: fbsd2@yahoo.com, freebsd-stable@freebsd.org Subject: Re: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) 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, 02 Aug 2008 23:07:48 -0000 Luigi Rizzo wrote: > On Sat, Aug 02, 2008 at 11:39:20AM -0700, Sam Leffler wrote: > ... >> I've been looking at nanobsd for a couple of applications and working to >> reduce the footprint of the images without hacking special rules. With > ... >> If we're ever to consider building images for flash parts (not compact >> flash) then we'll need to do a lot of work to pare down the bloat--or >> replace current apps w/ special purpose replacements a la busybox (not >> something I find appealing). > > related to this thread -- does anyone have experience in trying > to build busybox on FreeBSD ? My last experience w/ busybox was >1 year ago and I'm not sure I was using anything close to up to date, but...it was utterly linux-specific. Given what it does and what I saw in the code I'd be more inclined to write one from scratch. But having said that I'm not really sure it's worthwhile; I think I'd rather put effort into putting some of the existing tools on a diet (possibly under #ifdefs) and then use crunchgen. I'm pretty sure you'd come up with something higher quality and with a similar footprint. > > Also, what would you suggest as a small scripting language to be used > in this kind of platform for implementing CGI scripts (and preferably > able to use sockets/select) ? > > The various perl/python/php and friend are in the 10MB range once you > pick up a little bit of libraries (sockets etc) and the tangle of > modules they require; awk (which is present in busybox) is ok-ish for > some things, but doing > I/O and calling external programs with it is very unfriendly; > javascript/spidermonkey is on the 500KB range but it doesn't have > a library to play with sockets... Not sure about scripting languages but what's really needed is a lightweight http solution that supports ssl. This can go a long way before you get to php et. al. My last project of this sort used tinyhttp (I think, whichever one Jeff Pozkanzer did) and php. But we didn't try to fit in flash, we used compact flash parts. I think tinyhttpd+php is also what m0n0wall and pfsense use but haven't looked in a while. Sam From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 23:24:30 2008 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 385D4106564A; Sat, 2 Aug 2008 23:24:30 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from kazon.borderworlds.dk (kazon.borderworlds.dk [213.239.213.48]) by mx1.freebsd.org (Postfix) with ESMTP id E756A8FC15; Sat, 2 Aug 2008 23:24:29 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from dominion.borderworlds.dk (localhost [127.0.0.1]) by kazon.borderworlds.dk (Postfix) with ESMTP id E8C7517169; Sun, 3 Aug 2008 01:07:52 +0200 (CEST) Received: by dominion.borderworlds.dk (Postfix, from userid 2000) id 9CBBC47D; Sun, 3 Aug 2008 01:07:52 +0200 (CEST) To: Luigi Rizzo References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> From: Christian Laursen Date: Sun, 03 Aug 2008 01:07:52 +0200 In-Reply-To: <20080802225643.GA84798@onelab2.iet.unipi.it> (Luigi Rizzo's message of "Sun\, 3 Aug 2008 00\:56\:43 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: fbsd2@yahoo.com, Sam Leffler , freebsd-stable@freebsd.org Subject: Re: busybox and small scripting languages on FreeBSD ? 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, 02 Aug 2008 23:24:30 -0000 Luigi Rizzo writes: > Also, what would you suggest as a small scripting language to be used > in this kind of platform for implementing CGI scripts (and preferably > able to use sockets/select) ? Take a look at lua. It should have a pretty small footprint looks pretty easy to use - either standalone or embedded in you own programs. -- Christian Laursen From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 23:34:09 2008 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 24A3A1065672; Sat, 2 Aug 2008 23:34:09 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id D150A8FC08; Sat, 2 Aug 2008 23:34:08 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 532517308B; Sun, 3 Aug 2008 01:36:13 +0200 (CEST) Date: Sun, 3 Aug 2008 01:36:13 +0200 From: Luigi Rizzo To: Sam Leffler Message-ID: <20080802233613.GA85083@onelab2.iet.unipi.it> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> <4894E8C3.5060004@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4894E8C3.5060004@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: fbsd2@yahoo.com, freebsd-stable@freebsd.org Subject: Re: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) 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, 02 Aug 2008 23:34:09 -0000 On Sat, Aug 02, 2008 at 04:07:47PM -0700, Sam Leffler wrote: > Luigi Rizzo wrote: ... > >Also, what would you suggest as a small scripting language to be used > >in this kind of platform for implementing CGI scripts (and preferably > >able to use sockets/select) ? ... > Not sure about scripting languages but what's really needed is a > lightweight http solution that supports ssl. This can go a long way > before you get to php et. al. My last project of this sort used > tinyhttp (I think, whichever one Jeff Pozkanzer did) and php. But we > didn't try to fit in flash, we used compact flash parts. I think > tinyhttpd+php is also what m0n0wall and pfsense use but haven't looked > in a while. I think this http/ssl problem is reasonably well addressed by mini_httpd (this is Jeff Pozkanzer's code, about 50kb) and a small SSL library which you find in ports/security/xyssl (300kb). Mini_httpd uses the regular openssl libraries, but the xyssl API is reasonably similar to the SSL_* calls in openssl so it should be relatively straightforward to use in mini_httpd -- I did this in another project, even though only on the client side of https http://info.iet.unipi.it/~luigi/FreeBSD/minixmlrpc/ and it took very short time to adapt the code from openssl to xyssl. cheers luigi From owner-freebsd-stable@FreeBSD.ORG Sat Aug 2 23:38:15 2008 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 402331065672 for ; Sat, 2 Aug 2008 23:38:15 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1BFB18FC08 for ; Sat, 2 Aug 2008 23:38:14 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id D85ED1CC0AE; Sat, 2 Aug 2008 16:38:14 -0700 (PDT) Date: Sat, 2 Aug 2008 16:38:14 -0700 From: Jeremy Chadwick To: Sam Leffler Message-ID: <20080802233814.GA25565@eos.sc1.parodius.com> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> <4894E8C3.5060004@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4894E8C3.5060004@freebsd.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, fbsd2@yahoo.com, Luigi Rizzo Subject: Re: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) 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, 02 Aug 2008 23:38:15 -0000 On Sat, Aug 02, 2008 at 04:07:47PM -0700, Sam Leffler wrote: > Luigi Rizzo wrote: >> On Sat, Aug 02, 2008 at 11:39:20AM -0700, Sam Leffler wrote: >> ... >>> I've been looking at nanobsd for a couple of applications and working >>> to reduce the footprint of the images without hacking special rules. >>> With >> ... >>> If we're ever to consider building images for flash parts (not >>> compact flash) then we'll need to do a lot of work to pare down the >>> bloat--or replace current apps w/ special purpose replacements a la >>> busybox (not something I find appealing). >> >> related to this thread -- does anyone have experience in trying >> to build busybox on FreeBSD ? > > My last experience w/ busybox was >1 year ago and I'm not sure I was > using anything close to up to date, but...it was utterly linux-specific. > Given what it does and what I saw in the code I'd be more inclined to > write one from scratch. I've also dealt with Busybox under Linux, specifically on embedded environments (Linksys WRT54G-series). And I agree -- the code is absolutely *horrible*. It resembles years of multiple people hacking on it, one line at a time, with code comments ranging from very few to none. I found a major file descriptor leak in the Busybox code, and Googling details revealed that the Debian folks had also found it. Throughout numerous parts of Busybox, close(2) wasn't being called. The implications here are tremendous, especially since this program is being toted as "a fantastic application suite for embedded systems". The bug has since been fixed, but that kind of mistake is negligent. I would highly recommend creating something else from the ground up, or as Sam recommended, slimming down existing applications. > Not sure about scripting languages but what's really needed is a > lightweight http solution that supports ssl. This can go a long way > before you get to php et. al. My last project of this sort used > tinyhttp (I think, whichever one Jeff Pozkanzer did) and php. But we > didn't try to fit in flash, we used compact flash parts. I think > tinyhttpd+php is also what m0n0wall and pfsense use but haven't looked > in a while. I'm sure PHP suffices for environments which have CF/SD cards, or actual ATA disks -- but for real embedded environments (read: 4-8MB flash, etc.) PHP won't work. The stripped binary comes out to a little over 2MB. If the webserver chosen supported something like an extended version of server-parsed HTML, that could be benefitial here. Also, I'll take a moment to point out that the webserver that's used on the WRT54G platform (I believe Busybox's internal HTTP server, but I could be wrong) is horrible performance-wise. It doesn't matter what flavour of release (Tomato, Thibor, DD-WRT, OpenWRT, etc.) you go with -- a single page load results in a good 40-50 individual TCP connections being made to the webserver. You can practically deadlock the box by continually clicking Reload in your browser. This is probably because the webserver doesn't support Keepalives or HTTP/1.1, but again, the implications are horrible when you consider these boxes are commonly being used for NAT; resource starvation seems likely. If tinyhttp supports 1.1 or Keepalives, great, problem solved. -- | Jeremy Chadwick jdc at 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 Aug 2 23:50:56 2008 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 AE6A61065670 for ; Sat, 2 Aug 2008 23:50:56 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id 671288FC19 for ; Sat, 2 Aug 2008 23:50:56 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0K4Z00JYMZKVT670@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 03 Aug 2008 01:50:55 +0200 (CEST) Received: from kg-work.kg4.no ([80.202.72.251]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0K4Z0085HZKTHLR0@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 03 Aug 2008 01:50:55 +0200 (CEST) Date: Sun, 03 Aug 2008 01:50:53 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20080803015053.e67a39ee.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i386-portbld-freebsd6.3) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Temperature monitoring on old desktop - Dell OptiPlex SX270? 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, 02 Aug 2008 23:50:56 -0000 Hello, got this old machine, a SX270[1] that I thought I would put to use as my workstation (yes, my current workstation have lower specs than this machine). I have installed FreeBSD[2] 7.0-stable on it (i386). Normal[3] and verbose[4] dmesgs are available. Everything seems to work, but there is one thing tha doesn't: it doesn't report thermal parameters via acpi: root@kg-work2# sysctl hw.acpi.thermal sysctl: unknown oid 'hw.acpi.thermal' n fact the whole acpi section from sysctl seems a bit incomplete: root@kg-work2# sysctl hw.acpi hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 There is an acpidump[5] available too (from 'acpidump -dt'). The bios on this machine is from 2004, and that might be the cause. I couldn't find a newer bios than version A06, release date 09/29/2004. Does anybody know about a newer bios for thios machine anywhere? Or does anybody know how to fix the DSDT in the bios to enable thernal reporting? Or perhaps there is a way to read the temperature off the cpu, like the coretemp(4) driver? For those who wonders: yes, I have tried mbmon, lmmon from ports, but they didn't report anything useful as far as temperature goes. root@kg-work2# mbmon -d -A ioctl(smb0:open): No such file or directory SMBus[Intel8XX(ICH/ICH2/ICH3/ICH4/ICH5/ICH6)] found, but No HWM available on it!! Summary of Detection: * No monitors found. InitMBInfo: Bad file descriptor This program needs "setuid root"!! Output from 'lmmon -si': Motherboard Temp Voltages 255C / 491F / 528K Vcore1: +3.984V Vcore2: +3.984V Fan Speeds + 3.3V: +3.984V + 5.0V: +6.654V 1: 0 rpm +12.0V: +15.938V 2: 0 rpm -12.0V: -15.938V 3: 0 rpm - 5.0V: -6.654V I think 255 degrees Celsius is a bit unrealistic, the machine can't fry eggs yet. :-) Any good hints will be gratefully accepted. References: 1) SX270 - http://tingox.googlepages.com/sx270 2) http://tingox.googlepages.com/sx270_freebsd 3) http://tingox.googlepages.com/w2-dmesg-7.0-stable-20080721.txt 4) http://tingox.googlepages.com/w2-dmesg-7.0-stable-20080721_verbose.txt 5) http://tingox.googlepages.com/sx270-acpidump-dt-20080721.txt.gz -- Regards, Torfinn Ingolfsen, Norway