From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 00:47:37 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A6A3106566B; Sun, 13 Nov 2011 00:47:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E992B8FC08; Sun, 13 Nov 2011 00:47:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAD0lZD6089066; Sat, 12 Nov 2011 19:47:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAD0lZ7l089036; Sun, 13 Nov 2011 00:47:35 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 13 Nov 2011 00:47:35 GMT Message-Id: <201111130047.pAD0lZ7l089036@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 00:47:37 -0000 TB --- 2011-11-12 23:15:28 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-12 23:15:28 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-12 23:15:28 - cleaning the object tree TB --- 2011-11-12 23:15:53 - cvsupping the source tree TB --- 2011-11-12 23:15:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-12 23:16:15 - building world TB --- 2011-11-12 23:16:15 - CROSS_BUILD_TESTING=YES TB --- 2011-11-12 23:16:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-12 23:16:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-12 23:16:15 - SRCCONF=/dev/null TB --- 2011-11-12 23:16:15 - TARGET=ia64 TB --- 2011-11-12 23:16:15 - TARGET_ARCH=ia64 TB --- 2011-11-12 23:16:15 - TZ=UTC TB --- 2011-11-12 23:16:15 - __MAKE_CONF=/dev/null TB --- 2011-11-12 23:16:15 - cd /src TB --- 2011-11-12 23:16:15 - /usr/bin/make -B buildworld >>> World build started on Sat Nov 12 23:16:16 UTC 2011 >>> 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 Sun Nov 13 00:44:59 UTC 2011 TB --- 2011-11-13 00:44:59 - generating LINT kernel config TB --- 2011-11-13 00:44:59 - cd /src/sys/ia64/conf TB --- 2011-11-13 00:44:59 - /usr/bin/make -B LINT TB --- 2011-11-13 00:44:59 - cd /src/sys/ia64/conf TB --- 2011-11-13 00:44:59 - /usr/sbin/config -m GENERIC TB --- 2011-11-13 00:44:59 - building GENERIC kernel TB --- 2011-11-13 00:44:59 - CROSS_BUILD_TESTING=YES TB --- 2011-11-13 00:44:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-13 00:44:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-13 00:44:59 - SRCCONF=/dev/null TB --- 2011-11-13 00:44:59 - TARGET=ia64 TB --- 2011-11-13 00:44:59 - TARGET_ARCH=ia64 TB --- 2011-11-13 00:44:59 - TZ=UTC TB --- 2011-11-13 00:44:59 - __MAKE_CONF=/dev/null TB --- 2011-11-13 00:44:59 - cd /src TB --- 2011-11-13 00:44:59 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Nov 13 00:44:59 UTC 2011 >>> 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 -------------------------------------------------------------- cd /obj/ia64.ia64/src/sys/GENERIC; MAKEOBJDIRPREFIX=/obj/ia64.ia64 MACHINE_ARCH=ia64 MACHINE=ia64 CPUTYPE= GROFF_BIN_PATH=/obj/ia64.ia64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/ia64.ia64/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/ia64.ia64/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/ia64.ia64/src/tmp VERSION="FreeBSD 8.2-STABLE amd64 802512" INSTALL="sh /src/tools/install.sh" PATH=/obj/ia64.ia64/src/tmp/legacy/usr/sbin:/obj/ia64.ia64/src/tmp/legacy/usr/bin:/obj/ia64.ia64/src/tmp/legacy/usr/games:/obj/ia64.ia64/src/tmp/usr/sbin:/obj/ia64.ia64/src/tmp/usr/bin:/obj/ia64.ia64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make KERNEL=kernel all -DNO_MODULES_OBJ cc -c -x assembler-with-cpp -Wa,-x -DLOCORE -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ia64/ia64/locore.S cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/cam.c In file included from /src/sys/cam/cam.c:29: /src/sys/sys/cdefs.h:257:5: error: "__cplusplus" is not defined *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-13 00:47:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-13 00:47:35 - ERROR: failed to build GENERIC kernel TB --- 2011-11-13 00:47:35 - 4299.79 user 858.35 system 5526.40 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 01:07:46 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B03E106564A for ; Sun, 13 Nov 2011 01:07:46 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 494908FC12 for ; Sun, 13 Nov 2011 01:07:45 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 03E14E65D0 for ; Sun, 13 Nov 2011 01:07:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=mail; bh=6RIUaL2EL36pE4j+B6I3kFMdD M4=; b=QP/UJlq9nn8RBKFWL0Wjhb5+kKj6hKQy2kh7+2eDMJe4BSNoe1fXE9tlK W1ReFu2S9C7EF5nZDZgmBGmMeplpcevAt8hdZSJf1VMLUX1ipecJL1feDZbsyaka dYr9K+06QnanKcStef1FS6S4XDG4NvqgKvbbfz5GK/l91aGK9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=mail; b=ThsvyX8JwkhH+KFpYq9 /hKfxHcOkR6hyDrRYtzHlRPIk1lw4jRiNr5hGKGHpQVfYsMjb+lr52hWlu5SYajV JEKgWefp/zECgpGj92GtNmbPCFIkbB5wEupstJkawBQsGHzt0uiH6hPpgXNIyaH/ t4H7HDezMw0dkn8kBJiDOFio= Received: from [192.168.1.68] (188-220-36-32.zone11.bethere.co.uk [188.220.36.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id D199DE6472 for ; Sun, 13 Nov 2011 01:07:43 +0000 (GMT) Message-ID: <4EBF185F.2080106@cran.org.uk> Date: Sun, 13 Nov 2011 01:07:43 +0000 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 9.0-RC1 fails to boot ("run_interrupt_driven_hooks: still waiting...") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 01:07:46 -0000 FreeBSD 9.0-RC1 doesn't boot on my Tyan S7025 system: it gets stuck at xpt_config: run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config Booting with -v doesn't produce any more information during the timeout. The first few lines of dmesg: CPU: Intel(R) Xen(R) CPU E5620 @ 2.40GHz (2400.13-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206c2 Family = 6 Model = 2c Stepping = 2 Features=0xbfebfbff Features2=0x29ee3ff AMD Features=0x2c100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 17179869184 (16384MB) avail memory = 12366131200 (11793 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: <033011 APIC1334> FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 18 cpu5 (AP): APIC ID: 19 cpu6 (AP): APIC ID: 20 cpu7 (AP): APIC ID: 21 cpu8 (AP): APIC ID: 32 cpu9 (AP): APIC ID: 33 cpu10 (AP): APIC ID: 34 cpu11 (AP): APIC ID: 35 cpu12 (AP): APIC ID: 50 cpu13 (AP): APIC ID: 51 cpu14 (AP): APIC ID: 52 cpu15 (AP): APIC ID: 53 ioapic0: Changing APIC ID to 6 ioapic1: Changing APIC ID to 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 acpi0: <033011 XSDT1334> on motherboard acpi0: Overriding SCI from IRQ 9 to IRQ 20 acpi0: Power Button (fixed) acpi0: reservation of 0, a000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 cpu8: on acpi0 cpu9: on acpi0 cpu10: on acpi0 cpu11: on acpi0 cpu12: on acpi0 cpu13: on acpi0 cpu14: on acpi0 cpu15: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pbib0 pcib1: at device 1.0 on pci0 pci9: on pbib1 pcib2: at device 3.0 on pci0 pci8: on pbib2 pci8: at device 0.0 (no driver attached) pcib3: at device 5.0 on pci0 pci7: on pbib3 pcib4: at device 7.0 on pci0 pci6: on pbib4 pcib5: at device 9.0 on pci0 pci5: on pbib5 pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) uhci0: port 0xb400-0xb41f irq 16 at device 26.0 on pci0 uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xb480-0xb49f irq 21 at device 26.1 on pci0 uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xb800-0xb81f irq 19 at device 26.2 on pci0 uhci0: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xfbbf4000-0xfbbf43ff irq 18 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3: on ehci0 hdac0: mem 0xfbbf0000-0xfbbf3fff irq 22 at device 27.0 on pci0 pcib6: irq 17 at device 28.0 on pci0 pci4: on pcib6 pcib7: on irq 17 at device 28.4 on pci0 pci3: on pcib7 em0: mem 0xfbde000-0xfbdfffff,0xfbddc000-0xfbddffff irq 16 at device 0.0 on pci3 em0: Using MSIX interrupts with 3 vectors em0: Ethernet address: xx:xx:xx:xx:xx:xx pcib8: irq 16 at device 28.5 on pci0 pci2: on pcib8 em1: port 0xec00-0xec1f mem 0xfbce0000-0xfbcfffff,0xfbcdc000-0xfbcdfff irq 17 at device 0.0 on pci2 em1: Using MSIX interrupts with 3 vectors em1: Ethernet address: xx:xx:xx:xx:xx:xx uhci3: port 0xb880-0xb89f irq 23 at device 29.0 on pci0 uhci3: LegSup = 0x2f00 usbus4: on uhci3 uhci4: port 0xbc00-0xbc1f irq 19 at device 29.1 on pci0 uhci4: LegSup = 0x2f00 usbus5: on uhci4 uhci5: port 0xc000-0xc01f irq 18 at device 29.2 on pci0 uhci5: LegSup = 0x2f00 usbus6: on uhci5 ehci1: mem 0xfbbf6000-0xfbbf63ff irq 18 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7: on ehci1 pcib9: at device 30.0 on pci0 pci1: on pbib9 vgapci0: port 0xdc00-0xdc7f mem 0xfb000000-0xfb7fffff,0xfafe0000-0xfaffffff irq 16 at device 0.0 on pci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xc080-0xc087,0xc880-0xc883,0xc800-xc807,0xc480-0xc483,0xc400-0xc41f mem 0xfbbf8000-0xfbbf87ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 pci0: at device 31.3 (no driver attached) pcib10: on acpi0 pci128: on pcib10 pcib11: at device 0.0 on pci128 pci132: on pcib11 pcib12: at device 1.0 on pci128 pci131: on pcib12 -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 01:30:36 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D724106564A for ; Sun, 13 Nov 2011 01:30:36 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 26A788FC13 for ; Sun, 13 Nov 2011 01:30:36 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 54679E65D0 for ; Sun, 13 Nov 2011 01:30:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=oXDWGp59SYpP EL1D44ZlfvGqeh0=; b=l68a7zFoDRY5nuNHg9/xLJTEssuFyDPitPQa0iYV1vj3 i7+HCR+CTxKMq9u/7Cj5mUD6kjge+0BJ8jz55K/tx8CQ30shksfweSkqSdoMHW9+ UUGNn4I5+cBqzbf5GM728CCRb5ITxPL6vCiVQCuFW0yBvPqzY66j8x8J0KBAhsQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=la0u1j gK6YZ4mnOwSAIpxSJauHbOM5K3/IpAsGV/82/NQygqw7OyKKSavxeWgEsHmly28T CABFB4d6Nydyh/SBrjdmxb8O7XabEJs3pMhFJ0SsgyOwJ+lgCcLNJs3mwIYANcyg K+TMBUCBCPvG4SNMQkOJ7ZAcdzJ6gY9WMzGyw= Received: from [192.168.1.68] (188-220-36-32.zone11.bethere.co.uk [188.220.36.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 3EA5EE6472 for ; Sun, 13 Nov 2011 01:30:35 +0000 (GMT) Message-ID: <4EBF1DBA.40205@cran.org.uk> Date: Sun, 13 Nov 2011 01:30:34 +0000 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: current@freebsd.org References: <4EBF185F.2080106@cran.org.uk> In-Reply-To: <4EBF185F.2080106@cran.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: 9.0-RC1 fails to boot ("run_interrupt_driven_hooks: still waiting...") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 01:30:36 -0000 On 13/11/2011 01:07, Bruce Cran wrote: > FreeBSD 9.0-RC1 doesn't boot on my Tyan S7025 system: it gets stuck at > xpt_config: > > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 120 seconds for > xpt_config > run_interrupt_driven_hooks: still waiting after 180 seconds for > xpt_config > run_interrupt_driven_hooks: still waiting after 240 seconds for > xpt_config > run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config I had a Firewire card in the machine - removing it caused the problem to go away. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 01:36:53 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B809106564A for ; Sun, 13 Nov 2011 01:36:53 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 55F4B8FC12 for ; Sun, 13 Nov 2011 01:36:53 +0000 (UTC) Received: by iakl21 with SMTP id l21so6151910iak.13 for ; Sat, 12 Nov 2011 17:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PFzXumXOUw6kneGDOI/bjQXLeviFA/iESXt9clgMm4Y=; b=V2y9Q1KyZL1/AUtjQ0Y+ZfN8c2LeQUNMNH1fTHCGnbGVC1zdE5X0b9Cv/LhihZ5NmC uFqrIJRhWHxGPJY5PXf7DhwfOTZX1G2dW1im/qlwp8+hXvctz1sXvhJ1UWgWKRuu3RGG fkjmHcTry4piRr79hKDOFxlz+11gVOEzzw5X4= Received: by 10.68.31.129 with SMTP id a1mr36751115pbi.131.1321148212468; Sat, 12 Nov 2011 17:36:52 -0800 (PST) Received: from [192.168.20.5] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id p6sm43560057pbf.3.2011.11.12.17.36.51 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Nov 2011 17:36:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <4EBF1DBA.40205@cran.org.uk> Date: Sat, 12 Nov 2011 17:36:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1AC45966-96F7-4D13-BD2E-0D9F8CFB8430@gmail.com> References: <4EBF185F.2080106@cran.org.uk> <4EBF1DBA.40205@cran.org.uk> To: Bruce Cran X-Mailer: Apple Mail (2.1084) Cc: current@freebsd.org Subject: Re: 9.0-RC1 fails to boot ("run_interrupt_driven_hooks: still waiting...") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 01:36:53 -0000 On Nov 12, 2011, at 5:30 PM, Bruce Cran wrote: > On 13/11/2011 01:07, Bruce Cran wrote: >> FreeBSD 9.0-RC1 doesn't boot on my Tyan S7025 system: it gets stuck = at xpt_config: >>=20 >> run_interrupt_driven_hooks: still waiting after 60 seconds for = xpt_config >> run_interrupt_driven_hooks: still waiting after 120 seconds for = xpt_config >> run_interrupt_driven_hooks: still waiting after 180 seconds for = xpt_config >> run_interrupt_driven_hooks: still waiting after 240 seconds for = xpt_config >> run_interrupt_driven_hooks: still waiting after 300 seconds for = xpt_config >=20 > I had a Firewire card in the machine - removing it caused the problem = to go away. Someone else reported the same issue IIRC. It sounds like sbp + = cam needs to be fixed. Thanks, -Garrett= From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 02:44:28 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30CA0106566B; Sun, 13 Nov 2011 02:44:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 02E598FC14; Sun, 13 Nov 2011 02:44:27 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAD2iRni050726; Sat, 12 Nov 2011 21:44:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAD2iQsI050688; Sun, 13 Nov 2011 02:44:27 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 13 Nov 2011 02:44:27 GMT Message-Id: <201111130244.pAD2iQsI050688@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 02:44:28 -0000 TB --- 2011-11-13 00:41:37 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-13 00:41:37 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-13 00:41:37 - cleaning the object tree TB --- 2011-11-13 00:41:46 - cvsupping the source tree TB --- 2011-11-13 00:41:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-13 00:42:15 - building world TB --- 2011-11-13 00:42:15 - CROSS_BUILD_TESTING=YES TB --- 2011-11-13 00:42:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-13 00:42:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-13 00:42:15 - SRCCONF=/dev/null TB --- 2011-11-13 00:42:15 - TARGET=powerpc TB --- 2011-11-13 00:42:15 - TARGET_ARCH=powerpc TB --- 2011-11-13 00:42:15 - TZ=UTC TB --- 2011-11-13 00:42:15 - __MAKE_CONF=/dev/null TB --- 2011-11-13 00:42:15 - cd /src TB --- 2011-11-13 00:42:15 - /usr/bin/make -B buildworld >>> World build started on Sun Nov 13 00:42:16 UTC 2011 >>> 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 Sun Nov 13 02:42:14 UTC 2011 TB --- 2011-11-13 02:42:14 - generating LINT kernel config TB --- 2011-11-13 02:42:14 - cd /src/sys/powerpc/conf TB --- 2011-11-13 02:42:14 - /usr/bin/make -B LINT TB --- 2011-11-13 02:42:14 - cd /src/sys/powerpc/conf TB --- 2011-11-13 02:42:14 - /usr/sbin/config -m GENERIC TB --- 2011-11-13 02:42:14 - building GENERIC kernel TB --- 2011-11-13 02:42:14 - CROSS_BUILD_TESTING=YES TB --- 2011-11-13 02:42:14 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-13 02:42:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-13 02:42:14 - SRCCONF=/dev/null TB --- 2011-11-13 02:42:14 - TARGET=powerpc TB --- 2011-11-13 02:42:14 - TARGET_ARCH=powerpc TB --- 2011-11-13 02:42:14 - TZ=UTC TB --- 2011-11-13 02:42:14 - __MAKE_CONF=/dev/null TB --- 2011-11-13 02:42:14 - cd /src TB --- 2011-11-13 02:42:14 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Nov 13 02:42:14 UTC 2011 >>> 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 -------------------------------------------------------------- cd /obj/powerpc.powerpc/src/sys/GENERIC; MAKEOBJDIRPREFIX=/obj/powerpc.powerpc MACHINE_ARCH=powerpc MACHINE=powerpc CPUTYPE= GROFF_BIN_PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/powerpc.powerpc/src/tmp VERSION="FreeBSD 8.2-STABLE amd64 802512" INSTALL="sh /src/tools/install.sh" PATH=/obj/powerpc.powerpc/src/tmp/legacy/usr/sbin:/obj/powerpc.powerpc/src/tmp/legacy/usr/bin:/obj/powerpc.powerpc/src/tmp/legacy/usr/games:/obj/powerpc.powerpc/src/tmp/usr/sbin:/obj/powerpc.powerpc/src/tmp/usr/bin:/obj/powerpc.powerpc/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make KERNEL=kernel all -DNO_MODULES_OBJ cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/powerpc/aim/locore.S In file included from ./machine/asm.h:38, from /src/sys/powerpc/aim/locore32.S:66, from /src/sys/powerpc/aim/locore.S:6: /src/sys/sys/cdefs.h:257:5: error: "__cplusplus" is not defined *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-13 02:44:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-13 02:44:26 - ERROR: failed to build GENERIC kernel TB --- 2011-11-13 02:44:26 - 5899.60 user 1029.86 system 7368.83 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 08:02:50 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F9E31065674; Sun, 13 Nov 2011 08:02:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 54AD88FC13; Sun, 13 Nov 2011 08:02:48 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA14173; Sun, 13 Nov 2011 09:43:36 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RPUj2-000Ohk-A5; Sun, 13 Nov 2011 09:43:36 +0200 Message-ID: <4EBF7526.4090407@FreeBSD.org> Date: Sun, 13 Nov 2011 09:43:34 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Bruce Cran References: <4EBF185F.2080106@cran.org.uk> <4EBF1DBA.40205@cran.org.uk> In-Reply-To: <4EBF1DBA.40205@cran.org.uk> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sean Bruno , current@FreeBSD.org Subject: Re: 9.0-RC1 fails to boot ("run_interrupt_driven_hooks: still waiting...") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 08:02:50 -0000 on 13/11/2011 03:30 Bruce Cran said the following: > On 13/11/2011 01:07, Bruce Cran wrote: >> FreeBSD 9.0-RC1 doesn't boot on my Tyan S7025 system: it gets stuck at >> xpt_config: >> >> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config >> run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config >> run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config >> run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config >> run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config > > I had a Firewire card in the machine - removing it caused the problem to go away. > I think that Sean has been looking for someone who can reproduce the problem and is willing to help debugging it. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 08:32:19 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF0FE106564A; Sun, 13 Nov 2011 08:32:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6D98FC0A; Sun, 13 Nov 2011 08:32:19 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAD8WFQ9065459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Nov 2011 10:32:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAD8WFg4093418; Sun, 13 Nov 2011 10:32:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAD8WFZ1093417; Sun, 13 Nov 2011 10:32:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Nov 2011 10:32:15 +0200 From: Kostik Belousov To: arch@freebsd.org Message-ID: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RecmMh7zm4dDGtcP" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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: current@freebsd.org, avg@freebsd.org Subject: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 08:32:20 -0000 --RecmMh7zm4dDGtcP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I was tricked into finishing the work by Andrey Gapon, who developed the patch to reliably stop other processors on panic. The patch greatly improves the chances of getting dump on panic on SMP host. Several people already saw the patchset, and I remember that Andrey posted it to some lists. The change stops other (*) processors early upon the panic. This way, no parallel manipulation of the kernel memory is performed by CPUs. In particular, the kernel memory map is static. Patch prevents the panic thread from blocking and switching out. * - in the context of the description, other means not current. Since other threads are not run anymore, lock owner cannot release a lock which is required by panic thread. Due to this, we need to fake a lock acquisition after the panic, which adds minimal overhead to the locking cost. The patch tries to not add any overhead on the fast path of the lock acquire. The check for the after-panic condition was reduced to single memory access, done only when the quick cas lock attempt failed, and braced with __unlikely compiler hint. For now, the new mode of operation is disabled by default, since some further USB changes are needed to make USB keyboard usable in that environment. With the patch, getting a dump from the machine without debugger compiled in is much more realistic. Please comment, I will commit the change in 2 weeks unless strong reasons not to are given. http://people.freebsd.org/~kib/misc/stop_cpus_on_panic.1.patch --RecmMh7zm4dDGtcP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6/gI8ACgkQC3+MBN1Mb4hPZACdGVqOo6jiI4LP4qLX/9Kv19y6 U2UAni3euzO0s2e8m1kKpC00dSByyUR/ =tKJL -----END PGP SIGNATURE----- --RecmMh7zm4dDGtcP-- From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 06:33:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEBC5106564A; Sun, 13 Nov 2011 06:33:26 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward7.mail.yandex.net (forward7.mail.yandex.net [IPv6:2a02:6b8:0:202::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3ED258FC14; Sun, 13 Nov 2011 06:33:26 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward7.mail.yandex.net (Yandex) with ESMTP id 9B9241C454D; Sun, 13 Nov 2011 10:33:24 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1321166004; bh=90dfNniLgaAdkKZdV2cu0/R2Lt051ySvjgIn66ZMdWY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: Content-Transfer-Encoding; b=P5/qh4/uGglFJ7uLrZtByzSvf9Ikg0baH5vBgKSqgRH19kdnMRQhTUjM3SASH9fsL gGq/y/PYhHZ7enxr2VcpFZA1oGGJfEhxcSV621zqbzJ5nOUfmiZO8GzAtkYmy+DEVn ptScHPlGvJXjmSbHP/APEaisN9X+EVQuLgWVfG6U= Received: from smtp8.mail.yandex.net (localhost [127.0.0.1]) by smtp8.mail.yandex.net (Yandex) with ESMTP id 776DA1B603E0; Sun, 13 Nov 2011 10:33:24 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1321166004; bh=90dfNniLgaAdkKZdV2cu0/R2Lt051ySvjgIn66ZMdWY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: Content-Transfer-Encoding; b=P5/qh4/uGglFJ7uLrZtByzSvf9Ikg0baH5vBgKSqgRH19kdnMRQhTUjM3SASH9fsL gGq/y/PYhHZ7enxr2VcpFZA1oGGJfEhxcSV621zqbzJ5nOUfmiZO8GzAtkYmy+DEVn ptScHPlGvJXjmSbHP/APEaisN9X+EVQuLgWVfG6U= Received: from unknown (unknown [213.138.88.133]) by smtp8.mail.yandex.net (nwsmtp/Yandex) with ESMTP id XMO80ffR-XOOWGmoQ; Sun, 13 Nov 2011 10:33:24 +0400 X-Yandex-Spam: 1 Message-ID: <4EBF64A3.2090909@yandex.ru> Date: Sun, 13 Nov 2011 10:33:07 +0400 From: Ruslan Mahmatkhanov User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111109 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 13 Nov 2011 11:49:03 +0000 Cc: Adrian Chadd Subject: Problem with kernel memory dump after panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 06:33:26 -0000 Hi! I'm getting if_bwn panics with high traffic on -CURRENT: http://lists.freebsd.org/pipermail/freebsd-mobile/2011-November/012481.html And now i realize that it probably may be also reproduced on earlier FreeBSD versions, because i didn't do such high-trafficking before, so i got an illusion that this is -CURRENT-specific problem - it's an assumption nevertheless. I'm tried to investigate the causes (well, actually Adrian (adrian) tried :)), and i got some problem when i try to show backtrace to him: smeshariki3# kgdb -q -c /var/crash/vmcore.1 /boot/kernel/kernel (no debugging symbols found)...#0 0xc06f6aad in doadump () (kgdb) bt #0 0xc06f6aad in doadump () #1 0xc0af42e0 in show_busybufs () #2 0xefd25620 in ?? () #3 0xc06f7012 in kern_reboot () Previous frame inner to this frame (corrupt stack?) (kgdb) I have all the debugging disabled in my kernel, but Adrian claims that it still should carry some valuable data in backtrace, that is missed now, and he suggested me to ask freebsd-current@ about this. So I'm here. "Where is my backtrace, dude?" (C) PS. I have system sources, my kernel is in sync with world and third-party modules. -- Regards, Ruslan Tinderboxing kills... the drives. From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 16:47:19 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AA641065670; Sun, 13 Nov 2011 16:47:19 +0000 (UTC) (envelope-from dumbbell@FreeBSD.org) Received: from mail.made4.biz (unknown [IPv6:2001:41d0:1:7018::1:3]) by mx1.freebsd.org (Postfix) with ESMTP id DA2078FC0C; Sun, 13 Nov 2011 16:47:18 +0000 (UTC) Received: from [2a01:e35:2439:2440:290:f5ff:fe9d:b78c] (helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RPdDB-000OpX-Dq; Sun, 13 Nov 2011 17:47:18 +0100 Message-ID: <4EBFF494.2030501@FreeBSD.org> Date: Sun, 13 Nov 2011 17:47:16 +0100 From: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4EBE99A7.90500@FreeBSD.org> <4EBED0A5.5070308@FreeBSD.org> In-Reply-To: <4EBED0A5.5070308@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org Subject: Re: [Call for reviews] Support domain-search option in dhclient(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 16:47:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12.11.2011 21:01, Andrey V. Elsukov wrote: > I have several questions after a quick view of your patch: 1. > AFAIR, our dhclient was doing changes in the system configuration > via dhclient-script, but i don't see that your changes touched it. Yes, I forgot to include this in the patch. Here's a new version: http://people.freebsd.org/~dumbbell/dhclient/dhclient-domain-search-b.patch > 2. Your code handles compressed options. It's good. But it seems > you don't check names correctness. There were some checks for > "domain-name" option, probably you can use them. This is a nice suggestion. I added it in the new version. > 3. Also it would be good to update man pages :) Also fixed in the new patch. Thank you Andrey for your feedback! - -- Jean-Sébastien Pédron -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6/9JQACgkQa+xGJsFYOlNbzQCgnlpv8iEPsHlYmJXlBmFrD/CU 0pMAoLYrbwmtbnL9mmU3vIRgaP3bd0N2 =ykon -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 17:11:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57DFB106566B for ; Sun, 13 Nov 2011 17:11:40 +0000 (UTC) (envelope-from rdeiriar@spock.cl) Received: from mail.spock.cl (enteljoven2.enteljoven.cl [164.77.63.23]) by mx1.freebsd.org (Postfix) with ESMTP id BC0A38FC16 for ; Sun, 13 Nov 2011 17:11:39 +0000 (UTC) Received: from [192.168.1.100] (pc-17-182-45-190.cm.vtr.net [190.45.182.17]) (AUTH: PLAIN rdeiriar@spock.cl, TLS: TLSv1/SSLv3, 256bits, CAMELLIA256-SHA) by mail.spock.cl with ESMTPSA; Sun, 13 Nov 2011 14:11:35 -0300 id 000004F5.000000004EBFFA47.00002ADC Message-ID: <4EBFFA2E.6030203@spock.cl> Date: Sun, 13 Nov 2011 14:11:10 -0300 From: Roberto de Iriarte User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20110930 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EBF185F.2080106@cran.org.uk> <4EBF1DBA.40205@cran.org.uk> <4EBF7526.4090407@FreeBSD.org> In-Reply-To: <4EBF7526.4090407@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 9.0-RC1 fails to boot ("run_interrupt_driven_hooks: still waiting...") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 17:11:40 -0000 I have a machine, an IBM x3550 M3 with an IBM M1015 card flashed to IT mode, in which i can produce this very same problem in some EFI BIOS configurations. I would be glad to help testing/debugging the problem Best regards, Roberto > on 13/11/2011 03:30 Bruce Cran said the following: >> On 13/11/2011 01:07, Bruce Cran wrote: >>> FreeBSD 9.0-RC1 doesn't boot on my Tyan S7025 system: it gets stuck at >>> xpt_config: >>> >>> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config >>> run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config >>> run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config >>> run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config >>> run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config >> I had a Firewire card in the machine - removing it caused the problem to go away. >> > I think that Sean has been looking for someone who can reproduce the problem and > is willing to help debugging it. > From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 17:38:27 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 939931065670; Sun, 13 Nov 2011 17:38:27 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.freebsd.org (Postfix) with ESMTP id 794708FC14; Sun, 13 Nov 2011 17:38:27 +0000 (UTC) Received: from [127.0.0.1] (proxy6.corp.yahoo.com [216.145.48.19]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id pADHS5GW048385; Sun, 13 Nov 2011 09:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1321205285; bh=xdOV/vXxCklTH25uIinMjVdp6BeuZnoiqFUErB6DprU=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=unLIUaMmzn99K3jTxDU8oaB3PMfKzPKgI7HBWhTkf89e2o5K0ZMtmJEYecCsA3+3h wvpK6yLeoyT43I+HtU7QFChZN1ifgiPARl8VoD6tn+2rWwk2QVRl46zUOr+AiQKBwv vEP0pSi441chXrL54W3zCd/KmIq72xUPteNgr+2s= From: Sean Bruno To: Andriy Gapon In-Reply-To: <4EBF7526.4090407@FreeBSD.org> References: <4EBF185F.2080106@cran.org.uk> <4EBF1DBA.40205@cran.org.uk> <4EBF7526.4090407@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" Date: Sun, 13 Nov 2011 09:28:06 -0800 Message-ID: <1321205286.16999.7.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: Bruce Cran , Sean Bruno , "current@FreeBSD.org" Subject: Re: 9.0-RC1 fails to boot ("run_interrupt_driven_hooks: still waiting...") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 17:38:27 -0000 On Sat, 2011-11-12 at 23:43 -0800, Andriy Gapon wrote: > > I had a Firewire card in the machine - removing it caused the > problem to go away. > > > > I think that Sean has been looking for someone who can reproduce the > problem and > is willing to help debugging it. > > -- > Andriy Gapon Indeed. If you can setup a machine with a kernel with device sbp and get me root on the box I'd appreciate it. Bonus points for serial console! Sean From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 17:56:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2931B1065670 for ; Sun, 13 Nov 2011 17:56:14 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm27-vm0.bullet.mail.sp2.yahoo.com (nm27-vm0.bullet.mail.sp2.yahoo.com [98.139.91.232]) by mx1.freebsd.org (Postfix) with SMTP id 0853D8FC0C for ; Sun, 13 Nov 2011 17:56:13 +0000 (UTC) Received: from [98.139.91.62] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 13 Nov 2011 17:56:13 -0000 Received: from [98.136.185.41] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 13 Nov 2011 17:56:13 -0000 Received: from [127.0.0.1] by smtp102.mail.gq1.yahoo.com with NNFMP; 13 Nov 2011 17:56:13 -0000 X-Yahoo-Newman-Id: 717966.23941.bm@smtp102.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: GwUqq1sVM1koCGaXh91ij3ERrNjaKZqJIn0uT8kHTwBc5iz nK9hzSkCv2h5DMP4Rt.mSOicv9aWqbaGrZ9AIx_xtkd4oNBK1NwPCHgJ5QDp Xt24SpdAsifHUwnB1jDX6aXdzCLGU50P1H6OwzGPJD5TjohVqlr4PqPj6j4Q lFMrnTln3lo770rRFZ5U779DMm_u_7bi8yylU2mDSzH.WkTo6dXYtivBGWLH YE8lcWGByAumpy.4fVHOCjwpX0DMkKavDDgthSgwlapO2Ua_U5gwl6N7allo YBwH.opnmG5KXZN6wx_tZeIpMNqH2gQu9u1c1ozDuzO2OcPp4QYt1f_B5zXg _XGxjZYN7qxlu_ycgJ85qQja2lRVRYsrhkAuLbR4HOS1VFJkuAcXTuMoR_T. qqF3uI3BSH0ZTXQ-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.149.12 with plain) by smtp102.mail.gq1.yahoo.com with SMTP; 13 Nov 2011 09:56:13 -0800 PST Message-ID: <4EC004BC.6060406@freebsd.org> Date: Sun, 13 Nov 2011 18:56:12 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Attilio Rao References: <4EBB885E.9060908@freebsd.org> <4EBD10E6.9000302@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: [amd64] Reproducible cold boot failure (reboot succeeds) in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 17:56:14 -0000 Am 11.11.2011 13:15, schrieb Attilio Rao: > Can you try rebuilding your kernel and modules from scratch and see if > it fixes your problem? Sorry for the delay, but my system seems to need being turned off (S5) for many hours (whole night) to reproduce the problem ... I had already rebuilt my kernel multiple times in the last weeks. But just to be sure, I removed the build directories for kernel and world and built a new kernel after building and installing world from scratch. The next reboot (with boot blocks from the freshly built world) failed again ... But the first lines of boot messages look strange: ... WARNING: WITNESS option enabled, expect reduced performance. Table 'FACP' at 0xba918a58 Table 'APIC' at 0xba918b50 Table 'SSDT' at 0xba918be8 Table 'MCFG' at 0xba918dc0 Table 'HPET' at 0xba918e00 ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81109000 Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff81109370 <-- kldload: unexpected relocation type 67108875 kernel trap 12 with interrupts disabled The irritating detail is the load address of "zfs.ko", which is just 0x370 bytes above the kernel load address ... A verbose boot scrolls these lines off the screen to fast (and is to long to be preserved in dmesg.boot from the start), so I do not have any idea whether other values are reported in case of a successful boot. I had already assumed that memory was corrupted during early start-up, but now I think that gptzfsboot writes the zfs kernel module over the start of the loaded kernel. I'll try some more tests later today. Regards, STefan From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 20:52:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D2831065677 for ; Sun, 13 Nov 2011 20:52:37 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 506BF8FC0A for ; Sun, 13 Nov 2011 20:52:37 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so6733161vcb.13 for ; Sun, 13 Nov 2011 12:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=iVME6WyJzsnMd4Gah/oYmhR5KtT+328eytwZkX46MEE=; b=PjFg6PbMLSSlBCRo8XT3ea8GcIbqjWQ2ppsOfEnEw23OkjgMwqG8MPmzs08gxAQ9uu xe+Y0XtYy6wbeGxJwh/S4/KoJE2moaq6SLU00uztOFvXE5Sl8gxsJGl7/ADYcGc83ZwV YMhv/naUC9GbZlbukZFxjRl0/WR6STDGIvdio= MIME-Version: 1.0 Received: by 10.52.90.77 with SMTP id bu13mr32020593vdb.34.1321217556524; Sun, 13 Nov 2011 12:52:36 -0800 (PST) Received: by 10.52.156.135 with HTTP; Sun, 13 Nov 2011 12:52:36 -0800 (PST) Date: Sun, 13 Nov 2011 21:52:36 +0100 Message-ID: From: Davide Italiano To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [PATCH] Intel Sandy Bridge support for hwpmc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 20:52:37 -0000 Good evening folks. During last days I've written a patch to add sandy bridge support to hwpmc. Until now, the most recent Intel processor microarchitecture supported was Westmere. Testing is appreciated, in order to see if there's something that have to be fixed. You can find the diff here: http://davit.altervista.rg/hwpmc_sandy_bridge.diff I'd like to thanks a lot attilio@ that helped me to fix a bug and gnn@ and fabient@ for the useful suggestions. Best Davide From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 20:53:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ECBA1065675 for ; Sun, 13 Nov 2011 20:53:39 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5CCC78FC14 for ; Sun, 13 Nov 2011 20:53:39 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so6733589vcb.13 for ; Sun, 13 Nov 2011 12:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+2XmJwzMkwLn128D32mN1l6hMhjSfERm5P098DXxuh0=; b=pRiyBWHfVdCvNlgnD/Mz2wml6pgq36GruBwG3qE7c0huEfYUHFRET0skquvi/GByXH Rcoxn19dXcVSTUcKP4ubePeB2jWeCsOwmxV+jnGFY8F0YIFDUTpHUbEdehtT1cmRIeS3 pmCBdkK+QBKNpE/qgQzZxkRmC1wtAM9/vZ31k= MIME-Version: 1.0 Received: by 10.52.71.82 with SMTP id s18mr31538174vdu.68.1321217618802; Sun, 13 Nov 2011 12:53:38 -0800 (PST) Received: by 10.52.156.135 with HTTP; Sun, 13 Nov 2011 12:53:38 -0800 (PST) In-Reply-To: References: Date: Sun, 13 Nov 2011 21:53:38 +0100 Message-ID: From: Davide Italiano To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PATCH] Intel Sandy Bridge support for hwpmc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 20:53:39 -0000 On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano wrote: > Good evening folks. > During last days I've written a patch to add sandy bridge support to > hwpmc. Until now, the most recent Intel processor microarchitecture > supported was Westmere. > Testing is appreciated, in order to see if there's something that have > to be fixed. > You can find the diff here: http://davit.altervista.rg/hwpmc_sandy_bridge.diff > > I'd like to thanks a lot attilio@ that helped me to fix a bug and gnn@ > and fabient@ for the useful suggestions. > > Best > > Davide > Sorry, bad link. It should be: http://davit.altervista.org/hwpmc_sandy_bridge.diff From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 20:56:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3BD0106564A for ; Sun, 13 Nov 2011 20:56:34 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4BB5D8FC12 for ; Sun, 13 Nov 2011 20:56:33 +0000 (UTC) Received: by wwg14 with SMTP id 14so5455548wwg.31 for ; Sun, 13 Nov 2011 12:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ul0sEmqaR/Nyz7BpDyM3949+ANeW1u7NlFOVQhg200o=; b=e2LHH3mkDshpOf8zUhvBdS0/HKIzoHoj8VAiLXVyOd9rC/uauNtu92sJNDaOGUuDPz 7G4GTQju+aFRG5ZicMVayclFaeDD/vCDJHx5HFXWa3Za4lSRHVWvn92W2fX9whwQqkj7 fuWxSBu58NKDlvtjy0sEMeoK4JjGx5fS7T5l8= MIME-Version: 1.0 Received: by 10.216.137.10 with SMTP id x10mr735747wei.29.1321217792713; Sun, 13 Nov 2011 12:56:32 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Sun, 13 Nov 2011 12:56:32 -0800 (PST) In-Reply-To: References: Date: Sun, 13 Nov 2011 21:56:32 +0100 X-Google-Sender-Auth: NG2JzTJU1TLncOfLjGwGVvVE8co Message-ID: From: Attilio Rao To: Davide Italiano Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] Intel Sandy Bridge support for hwpmc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 20:56:34 -0000 2011/11/13 Davide Italiano : > On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano > wrote: >> Good evening folks. >> During last days I've written a patch to add sandy bridge support to >> hwpmc. Until now, the most recent Intel processor microarchitecture >> supported was Westmere. >> Testing is appreciated, in order to see if there's something that have >> to be fixed. >> You can find the diff here: http://davit.altervista.rg/hwpmc_sandy_bridge.diff >> >> I'd like to thanks a lot attilio@ that helped me to fix a bug and gnn@ >> and fabient@ for the useful suggestions. >> >> Best >> >> Davide >> > > Sorry, bad link. It should be: > http://davit.altervista.org/hwpmc_sandy_bridge.diff Ci sono un po di cose da pulire, ma quello posso farlo io. Mi dici come riprodurre il deadlock con THREAD_P? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 20:59:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B211106564A for ; Sun, 13 Nov 2011 20:59:36 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 27EBF8FC13 for ; Sun, 13 Nov 2011 20:59:35 +0000 (UTC) Received: by vws11 with SMTP id 11so6771489vws.13 for ; Sun, 13 Nov 2011 12:59:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fHdG5JK0txnleKBJZIvXIKVvZ6yqFUXtl5cYnQH0BAY=; b=IDjiIwZnGEtIJh14PXSGZdqwNxdJbp0qCfp1xa3KglC2x+7fq7G9auwJ6q/VFX9D8c Ot3cbEeus6CScvNxOFo6B9nzW18SS1tnVXDskm7oLOZ5Vx/uSJ8qO0fMGFXXPPQ7feZz 3gdqiMHPAoxEZmYwTV6J3HRcGEscHUogj+lP8= MIME-Version: 1.0 Received: by 10.52.33.51 with SMTP id o19mr21347421vdi.119.1321217974611; Sun, 13 Nov 2011 12:59:34 -0800 (PST) Received: by 10.52.156.135 with HTTP; Sun, 13 Nov 2011 12:59:34 -0800 (PST) In-Reply-To: References: Date: Sun, 13 Nov 2011 21:59:34 +0100 Message-ID: From: Davide Italiano To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] Intel Sandy Bridge support for hwpmc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 20:59:36 -0000 On Sun, Nov 13, 2011 at 9:56 PM, Attilio Rao wrote: > 2011/11/13 Davide Italiano : >> On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano >> wrote: >>> Good evening folks. >>> During last days I've written a patch to add sandy bridge support to >>> hwpmc. Until now, the most recent Intel processor microarchitecture >>> supported was Westmere. >>> Testing is appreciated, in order to see if there's something that have >>> to be fixed. >>> You can find the diff here: http://davit.altervista.rg/hwpmc_sandy_bridge.diff >>> >>> I'd like to thanks a lot attilio@ that helped me to fix a bug and gnn@ >>> and fabient@ for the useful suggestions. >>> >>> Best >>> >>> Davide >>> >> >> Sorry, bad link. It should be: >> http://davit.altervista.org/hwpmc_sandy_bridge.diff > > Ci sono un po di cose da pulire, ma quello posso farlo io. > > Mi dici come riprodurre il deadlock con THREAD_P? > > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > pmcstat -SCPU_CLK_UNHALTED.THREAD_P dovrebbe andare. (facendo partire pmcstat non in system-mode, ad esempio pmcstat -pCPU_CLK_UNHALTED.THREAD_P ls , non va in deadlock. From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 21:01:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FCC01065673 for ; Sun, 13 Nov 2011 21:01:00 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id B3B568FC1D for ; Sun, 13 Nov 2011 21:00:59 +0000 (UTC) Received: by wwg14 with SMTP id 14so5458263wwg.31 for ; Sun, 13 Nov 2011 13:00:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=auf7UqoChFqqRPIMm8YoT/rhloDHULfyCWPuE9fQbl0=; b=vPmFtw1AIqXwsoQSFbdlI+CaJEC12AoVLWI2VGcToqZ+5l8j9jipXuS7EVefjfoeDp uBlpY0RXzqNSXF1xo8EaqlG8k6ZH5jX8imIfWzfjMO8rhdrfzaeqsTr8ul4ELb9wq+1W NPOxRW6I/MUIwXSjttT/CHBwxn78BCLQPeRq4= MIME-Version: 1.0 Received: by 10.216.137.10 with SMTP id x10mr737300wei.29.1321218058545; Sun, 13 Nov 2011 13:00:58 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Sun, 13 Nov 2011 13:00:58 -0800 (PST) In-Reply-To: References: Date: Sun, 13 Nov 2011 22:00:58 +0100 X-Google-Sender-Auth: GtzQhylA4I0fPBP4LkhBBdpIxB0 Message-ID: From: Attilio Rao To: Davide Italiano Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] Intel Sandy Bridge support for hwpmc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 21:01:00 -0000 2011/11/13 Davide Italiano : > On Sun, Nov 13, 2011 at 9:56 PM, Attilio Rao wrote: >> 2011/11/13 Davide Italiano : >>> On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano >>> wrote: >>>> Good evening folks. >>>> During last days I've written a patch to add sandy bridge support to >>>> hwpmc. Until now, the most recent Intel processor microarchitecture >>>> supported was Westmere. >>>> Testing is appreciated, in order to see if there's something that have >>>> to be fixed. >>>> You can find the diff here: http://davit.altervista.rg/hwpmc_sandy_bridge.diff >>>> >>>> I'd like to thanks a lot attilio@ that helped me to fix a bug and gnn@ >>>> and fabient@ for the useful suggestions. >>>> >>>> Best >>>> >>>> Davide >>>> >>> >>> Sorry, bad link. It should be: >>> http://davit.altervista.org/hwpmc_sandy_bridge.diff >> >> Ci sono un po di cose da pulire, ma quello posso farlo io. >> >> Mi dici come riprodurre il deadlock con THREAD_P? >> >> Attilio >> >> >> -- >> Peace can only be achieved by understanding - A. Einstein >> > > pmcstat -SCPU_CLK_UNHALTED.THREAD_P dovrebbe andare. > (facendo partire pmcstat non in system-mode, ad esempio > pmcstat -pCPU_CLK_UNHALTED.THREAD_P ls , non va in deadlock. In pratica tu hai visto che cercando di andare con ctrl+c non termina? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 21:02:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A6F7106566C; Sun, 13 Nov 2011 21:02:32 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CAF008FC14; Sun, 13 Nov 2011 21:02:31 +0000 (UTC) Received: by wyf23 with SMTP id 23so4314194wyf.13 for ; Sun, 13 Nov 2011 13:02:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0P1tb+u7qnYSCSAmItvZZoVZ3L2RDqacnITlhH62nAk=; b=Osg/BQ8HoNG5dOGR++80PUbKBL8F02bDmHWScRxGx7+XHa6L167FHA1zcffE1nul03 JUO1/6s5jwABId9d5F/kt/VxGPcQJ3SceBBdkTv1xX0oq6LT3anllj0qfVFdof51DJqt nD+dVJH1ILcmpu2giQgeiPBodbELUpETpRYIY= MIME-Version: 1.0 Received: by 10.216.176.14 with SMTP id a14mr714454wem.14.1321218149848; Sun, 13 Nov 2011 13:02:29 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Sun, 13 Nov 2011 13:02:29 -0800 (PST) In-Reply-To: References: Date: Sun, 13 Nov 2011 22:02:29 +0100 X-Google-Sender-Auth: s2VyGPJj9S3eZOEU68xdg83FCiU Message-ID: From: Attilio Rao To: Davide Italiano Content-Type: text/plain; charset=UTF-8 Cc: George Neville-Neil , freebsd-current@freebsd.org, Fabien Thomas Subject: Re: [PATCH] Intel Sandy Bridge support for hwpmc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 21:02:32 -0000 2011/11/13 Davide Italiano : > On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano > wrote: >> Good evening folks. >> During last days I've written a patch to add sandy bridge support to >> hwpmc. Until now, the most recent Intel processor microarchitecture >> supported was Westmere. >> Testing is appreciated, in order to see if there's something that have >> to be fixed. >> You can find the diff here: http://davit.altervista.rg/hwpmc_sandy_bridge.diff >> >> I'd like to thanks a lot attilio@ that helped me to fix a bug and gnn@ >> and fabient@ for the useful suggestions. >> >> Best >> >> Davide >> > > Sorry, bad link. It should be: > http://davit.altervista.org/hwpmc_sandy_bridge.diff I can perform some small cleanups and likely test it too. If Fabien or George can review it I'm fine with committing as long as all that is settled. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 23:19:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA1B0106566C for ; Sun, 13 Nov 2011 23:19:30 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7F3968FC0C for ; Sun, 13 Nov 2011 23:19:30 +0000 (UTC) Received: by yenl11 with SMTP id l11so701327yen.13 for ; Sun, 13 Nov 2011 15:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=ImkZeVTOzwn8lrA568zE9ynwZB6h1Xqb6xsWrQ4PGIo=; b=JV3p5dn1wJd/SJSQMFcs30/jn39/Wmb45UWZ69G3aF/WuzKPOcnu3A/kroSCzOjkSq ndQeCzYQBdc6/s17Iw3OTJsH2KaEfgQOO3O+kEsBjFPG2pbzhOpBRbFcxrYSis9qB/yT 28UQY2YLZivATKYUKHcHTFi9be4z4eVc2/Cok= Received: by 10.182.216.105 with SMTP id op9mr4476973obc.57.1321224833098; Sun, 13 Nov 2011 14:53:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.28.227 with HTTP; Sun, 13 Nov 2011 14:53:32 -0800 (PST) From: Eir Nym Date: Mon, 14 Nov 2011 02:53:32 +0400 Message-ID: To: FreeBSD Questions , FreeBSD Mail Lists Content-Type: text/plain; charset=UTF-8 Cc: Subject: Re: What is current VIMAGE status? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 23:19:30 -0000 I'm sorry it's about VIMAGE option. -- Eir Nym On 14 November 2011 02:52, Eir Nym wrote: > I don't see it in NOTES for LINT and amd64/i386 arch, but it's > possible to turn it on. Can I consider that this option is currently > experimental and shouldn't be used critical places? > > -- Eir Nym > From owner-freebsd-current@FreeBSD.ORG Sun Nov 13 23:20:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BD65106566C for ; Sun, 13 Nov 2011 23:20:10 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id E6BF18FC1A for ; Sun, 13 Nov 2011 23:20:09 +0000 (UTC) Received: by ywe9 with SMTP id 9so2778930ywe.13 for ; Sun, 13 Nov 2011 15:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=zZfKtS5rojXHCIaRpTM05Jkq018bFmJhWVLB9uyAmzk=; b=BWSBr1JbV6lk4v7WTrbAowlz4vX5EBTDoZvqdfUKZez8f0IsWWqFQ6FYvqAFwRaZMD W7XF1X5gjEtr+lZv6LKwiHLYmZFRZGJynIzALAIgGPa/Msg/SPp1xQnDiVuWmu/I4kIK INI7Vi3MX0MX78GRZhnYo4AQotW4LKrMcar1U= Received: by 10.182.50.65 with SMTP id a1mr345711obo.17.1321224773093; Sun, 13 Nov 2011 14:52:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.28.227 with HTTP; Sun, 13 Nov 2011 14:52:29 -0800 (PST) From: Eir Nym Date: Mon, 14 Nov 2011 02:52:29 +0400 Message-ID: To: FreeBSD Questions , FreeBSD Mail Lists Content-Type: text/plain; charset=UTF-8 Cc: Subject: What is current VINET status? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 23:20:10 -0000 I don't see it in NOTES for LINT and amd64/i386 arch, but it's possible to turn it on. Can I consider that this option is currently experimental and shouldn't be used critical places? -- Eir Nym From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 00:38:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48BB2106566C; Mon, 14 Nov 2011 00:38:39 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9EC8A8FC0C; Mon, 14 Nov 2011 00:38:38 +0000 (UTC) Received: by wyf23 with SMTP id 23so4426357wyf.13 for ; Sun, 13 Nov 2011 16:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2ce63yKoz0NoEXN0FKOW7DuESYP496Pctl09OAakAJY=; b=s9qlOH0whWncb/pfS3wiJ8QlbIPe1dN69cg4aQIyM50jWn8tmRnT9IZWGzO9EseVUC NHEJuWZ4XUr2w6NsWTJaTcaMOkA4HNbEvjpTd8B1UhfnOskvIaT4TTLV86CZSJB2DL3u wUszU12oXCXEcjQaAulkwmgsSQyd6mlg4yzDA= MIME-Version: 1.0 Received: by 10.180.3.71 with SMTP id a7mr23417683wia.0.1321231117493; Sun, 13 Nov 2011 16:38:37 -0800 (PST) Received: by 10.180.81.200 with HTTP; Sun, 13 Nov 2011 16:38:37 -0800 (PST) In-Reply-To: <4EBABAC1.2090003@freebsd.org> References: <4EB9C469.9070208@freebsd.org> <4EB9E6FE.3060102@freebsd.org> <4EBABAC1.2090003@freebsd.org> Date: Sun, 13 Nov 2011 19:38:37 -0500 Message-ID: From: Arnaud Lacombe To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 00:38:39 -0000 Hi, On Wed, Nov 9, 2011 at 12:39 PM, Julian Elischer wrote= : > On 11/8/11 9:29 PM, Arnaud Lacombe wrote: > [...] > >> However, if you want to know, my heart tends to be with BSDs. >> Unfortunately, it's a sad love-story where your Beloved keeps >> deceiving you day after day. You want to change small bits at a time, >> make several iteration of progress to make things brighter, but your >> Beloved refuses any change because of too much inertia. Sad. > > mostly it's because you keep attacking your loved one with a steak knife. > flowers might get you further. Well, it would would seem that keeping sending patch is what you consider "attacking your loved one with a steak knife", because yes, this is what I will keep doing. >>> >>> so you are used to doing it that way.. but don't expect us to change ju= st >>> because that's what Linux does. >>> >> again, mentioning Linux is totally irrelevant. Use of Instruction >> Pointer are implementation details for a not so intrusive solution to >> the problem I pointed out, and which you are totally missing. > > since these modules were written many new options have come. Maybe this is the real problem, FreeBSD is unable to keep up and to make interfaces written +10 years ago evolves. Worst, you (committers) keep on taking decision based on changes made 10 to 12 years ago that are totally irrelevant today, making these decisions nothing but plain bad. >> well, you're lucky FreeBSD supports your device! Lately, we got lately >> a shiny multi-queue network cards with bypass mechanism... that is not >> supported in FreeBSD. So currently, we got an expensive paper-weight. > > well write a driver for it.. > my time is limited, and you (FreeBSD folks) seem to love making it even busier by your inability to make some parts of the system evolve, or by taking bad decision. This generally happens when I try to optimize some of our internal code path, hit a system bottleneck, try to prove the system is wrong, and then eventually, think about optimizing it, implement the solution one or twice, and get slammed hard when I go public with both the proof of performance hit/non-correctness/incompleteness and the correction. Unfortunately, the time complexity of the whole process is 2^O(n) :( > what do you think I'm doing with the driver I'm > talking about? > I wrote several bypass network card drivers when I was at cisco/ironport.= . > it's not rocket science, > though it would be nice if we were to come up with a standard interface f= or > bypass interfaces. indeed. > That is a different topic though.. > indeed. >>> 1/ half the time freebsd will just immediatly assert on something and >>> present you with the bug.. done. >>> >> well, certainly not from a release build; assertion are disabled. > > During development. we NEVER have bugs in production ;-) > [sic.] >> [0]: I am able to crash any kernel between 7-STABLE to 9.STABLE within >> minutes, with the right pattern and (mainstream and well supported) >> hardware. > > and who have you reported that to? =A0bug number? > http://lists.freebsd.org/pipermail/freebsd-net/2011-September/029722.html I suspect PR/155597 and a few other are related. >> [3]: FreeBSD (8-STABLE) is way to limited and un-integrated to be >> anywhere but useful, not to speak about kernel bug which leave the >> system so fracked up that you have no other choice but to hard-reboot. > > bug number? > usb/156725, amd64/156726 - Arnaud From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 01:30:05 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85384106564A; Mon, 14 Nov 2011 01:30:05 +0000 (UTC) (envelope-from das@freebsd.org) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 50A238FC12; Mon, 14 Nov 2011 01:30:05 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id pAE1U4tA053862; Sun, 13 Nov 2011 20:30:04 -0500 (EST) (envelope-from das@freebsd.org) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id pAE1U4lB053861; Sun, 13 Nov 2011 20:30:04 -0500 (EST) (envelope-from das@freebsd.org) Date: Sun, 13 Nov 2011 20:30:04 -0500 From: David Schultz To: Andrey Chernov , current@freebsd.org, secteam@freebsd.org Message-ID: <20111114013004.GA53392@zim.MIT.EDU> Mail-Followup-To: Andrey Chernov , current@freebsd.org, secteam@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> <20111112102241.GA75396@vniz.net> <20111112154135.GA21512@zim.MIT.EDU> <20111112171531.GA83419@vniz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111112171531.GA83419@vniz.net> Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:30:05 -0000 On Sat, Nov 12, 2011, Andrey Chernov wrote: > On Sat, Nov 12, 2011 at 10:41:35AM -0500, David Schultz wrote: > > On Sat, Nov 12, 2011, Andrey Chernov wrote: > > > On Tue, Sep 16, 2008 at 04:19:32PM -0400, David Schultz wrote: > > > > secteam@ already agreed to the idea of solving the fork problem as > > > > in OpenBSD over a month ago. > > > > > > On Wed, Sep 17, 2008 at 12:50:25PM +0400, Andrey Chernov wrote: > > > > I agree with your patch (BTW you can remove unneded #define RANDOMDEV). > > > > > > The question remains: why you don't commit this patch all that 3 > > > years, having secteam@ and mine agreements too? > > > > Sorry, but in the three years that have intervened, my brain has > > paged out the relevant context. As I recall, there were issues > > with some of your changes to arc4random() and I proposed tracking > > OpenBSD's implementation more closely. > > I can't say for secteam@ side (it was you who said that they agree), but > personally me still agree with your proposal and still see security > problem in our current implementation, like the same-generated tmp names > after fork in son and parent. > > > If everyone's in agreement on that, please go ahead and commit the changes. > > I can't... It seems I reach dead end talking to our @secteam. In few > words, they: > 1) Explicitly disallow my commits in all 'random' areas until their > review. > 2) They never do that review (I must to mention again that 3 years > passed since they promise it). > Being particular, I suggest them to use your patch at the end. Nothing > happens. > Hope you'll get more luck with them committing it by yourself. I don't have those patches anymore, but I redid them from scratch using the latest revision from OpenBSD. The patch at http://www.freebsd.org/~das/patches/vshead.diff syncs our arc4random.c with OpenBSD's to the extent possible, style bugs and all. It seems prudent to treat it as a vendor source and avoid gratuitous differences: Unlike our version, all the changes to OpenBSD's arc4random.c were vetted by several people. Switching to OpenBSD's version fixes the bug where a parent and child process see the same random sequence. The diff http://www.freebsd.org/~das/patches/vsobsd.diff shows the differences between our version and OpenBSD's after applying the patch. Most of the remaining differences are in arc4_stir(), where we use /dev/random instead of a sysctl to get entropy for the IV. In arc4_stir(), I also fixed the bug where the wrong buffer size was being passed to arc4_addrandom(), resulting in entropy loss. That change should be committed separately. When adding the XXX comment in the patch, I noticed that it isn't clearly documented what arc4random() is supposed to provide, and there seems to be a substantial amount of confusion on this point. I can think of three reasonable kinds of RNGs: 1. Low-quality pseudorandomness, e.g., for test generation. These are only "random" w.r.t. certain statistical tests. 2. High-quality, reproducible pseudorandomness, e.g., for deterministic encryption, or test generation with stronger statistical requirements. 3. High-quality, unpredictable pseudorandomness, e.g., for key generation. David Mazieres' original arc4random() implementation was intended to provide a less useful variant of #2, but was extended to provide #3 in OpenBSD. FreeBSD's version provides #3 most of the time, unless something goes wrong -- e.g., you forget to load random.ko or you run it in a jail where there's no /dev -- and then you get #2. It seems that most people think arc4random() is giving them #3, and if that's the case, then arc4random() should be fail-fast: it should abort if it's unable to obtain a high-quality IV. There's similar confusion evident in the revision history for random(), which really only provides #1. > On Tue, Sep 16, 2008 at 04:19:32PM -0400, David Schultz wrote: > > If getpid() really winds up being a serious problem, we can solve [...] > I run some tests but can't come to conclusion, is overhead is significant > or not for real life tasks (which usually don't call arc4random() very > often in the loop). I have a bunch of tests for floating point that use arc4random(), and they are substantially slower with the getpid() changes. Realistically they should be using mrand48(), though. Here's a TODO list of worthwhile improvements that I don't have time for. None of them seem terribly pressing. - Document what arc4random() actually provides. (The OpenBSD manpage is pretty good, albeit a bit technical.) - Like OpenBSD, implement and use a sysctl to get the IV in arc4random() instead of /dev/random. This is likely to be faster, and there's less than can go wrong (e.g., jails without a working /dev). - Make arc4random() abort if it can't get any cryptographic-quality entropy. Make sure it's still possible to boot in single-user mode without random.ko. - Either optimize getpid() or replace its use with a fork hook, so that it isn't necessary to do a syscall on every arc4random() call. If there's no speed advantage to using arc4random(), people might as well just be reading from /dev/random all the time. From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 08:50:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACDC81065672 for ; Mon, 14 Nov 2011 08:50:41 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6EEEA8FC15 for ; Mon, 14 Nov 2011 08:50:41 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 3DF9D119C6C; Mon, 14 Nov 2011 02:50:40 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1321260640; bh=GtcRkmHBz+TCCEedTB40UIT0/Biv6KLBa8REc/+Oxvc=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=WA9uYKV+I/J8SJOYQwDguW0+BzjD/zBJ7B1OqVyZiMLRaTNuWqzM7DYK2FotqYCKd eIFPqtUsQLD2VEv+t/sQMIyhp9ddCbB8/1VlNJe2NV0tEdSZkuCBPuI3udAGyE/U0g oYm/wzmEoHTVvv6tnSOFckzcKhlsx4uuPytEwB/Q= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 38D5A119C6B for ; Mon, 14 Nov 2011 02:50:40 -0600 (CST) Date: Mon, 14 Nov 2011 02:50:40 -0600 (CST) From: Dan The Man To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: NFSV4 readlink_stat X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 08:50:41 -0000 Just want to include some errors from rsync trying to copy files using NFSV4. These files copy fine using NFSV3.... rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/A-E/A/Ace of Base/The Bridge/Ace of Base-My D\#351j\#340 Vu-09-The Bridge.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/A-E/B/Bj\#366rn Skifs") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/A-E/B/Bjork/Bj\#366rk - Dancer in the Dark - My Favorite Things.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/A-E/B/Bjork/Bj\#366rk - Amphibian.mp3") failed: Invalid argument (22) IO error encountered -- skipping file deletion rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/A-E/C/Celine Dion/C\#351line Dion - I Drove All Night (Album Version).mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/A-E/E/The Eagles/The Eagles Greatest Hits, Vol. 2/05 The Sad Caf\#351.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/G/Georges Delerue/Georges Delerue - Le M\#351pris, Camille - Jean-Luc Godard.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/O\#264 Riada Sa Gaiety") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Athen Rye/Athenrye - Amhr\#341n Na Bhfiann.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Chieftans/Chieftains & Sin\#351ad O'Connor - Factory girl.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Chieftans/The Chieftains & Sin\#351ad O'Connor - The Foggy Dew.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Christy Moore/Christy Moore - Compa\#361eros - 06.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Clancy Brothers/Clancy Brothers & Tommy Makem - 12 - Cru\#354sc\#354n L\#340n.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Loreena McKennitt/Loreena McKennitt - The Mask and Mirror - 07. C\#351 H\#351 Mise Le Ulaingt - The Two Trees.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Planxty/Planxty - Raggletaggle Gypsy; Tabhair Dom Do L\#343mh - 01.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Planxty/Planxty - The Rambling Si\#372ler - 05.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Quilty/Quilty - Mist Covered Mountain Siobh\#341n O\#264donnels - Jig Reel.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Quilty/Quilty - I\#264m Here Because I\#264m Here.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Seamus Kennedy/Seamus Kennedy - Or\#363! S\#351 Do Bheatha 'Bhaile & The Rights Of Man (Instrumental).mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Seamus Kennedy/Seamus Kennedy - The Bodhr\#341n (Comedy).mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Sinead O'Connor/Sinead O'Connor - The Black Album ( 8 CD Set )/Cd 2/06_Mna Na H\#351ireann.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Sinead O'Connor/Sinead O'Connor - The Black Album ( 8 CD Set )/Cd 3/07_Rois\#355n Dubh.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/Wolfe Tones/2006 As Gaeilge/Wolfe Tones - T\#341 Na L\#341.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/aaa - Too Few, but Identified/Irish C\#351ili Band - The Black Velvet Band.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/aaa - Too Few, but Identified/Young Dubliners - The Bodhr\#341n.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/aaa - Too Few, but Identified/Jeff Johnson & Brian Dunning - C\#371Chulainn's Last Battle.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/aaa - Too Few, but Identified/Phil Coulter & Sin\#351ad O'Connor - The Shores Of The Swilly.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/aaa - Too Few, but Identified/M\#341ire Brennan - Eirigh Suas A Stoirin.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/aaa - Too Few, but Identified/Sin\#351ad O-connor - Factory Girl.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/history of ireland in song/53.Amhr\#341n na Bhfiann.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/history of ireland in song/46.Se\#341n South from Garryowen.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/history of ireland in song/32.Se\#341n Treacy.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/history of ireland in song/02.Rois\#355n Dubh.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/history of ireland in song/03.Se\#341n \#323 Duibhir A'Ghleanna.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish Scottish Celtic Music Collection/history of ireland in song/03.Se\#341n \#323 Duibhir A'Ghleanna (O'Dwyer of the Glen).mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/K-O/M/M\#366tley Cr\#374e") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Sort Me Music/New Folder(20)/Ivan Rebroff - Moskauer n\#344chte (rus).mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Bj\#366rn Skifs - H\#344rligt, h\#344rligt men farligt, farligt.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Bj\#366rk - Visur Vatnsenda Rosu.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/All Crap Tunes/F-L/La Mafia/Un Millon de Rosas/La Mafia-Yo Te Amar\#351-01-Un Millon de Rosas.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/All Crap Tunes/F-L/La Mafia/Un Millon de Rosas/La Mafia-Qui\#351n-04-Un Millon de Rosas.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/All Crap Tunes/F-L/La Mafia/Un Millon de Rosas/La Mafia-C\#363mo Pude Estar Tan Ciego-10-Un Millon de Rosas.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/All Crap Tunes/M-P/Moxy Fruvous/Moxy Fr\#374vous - Spiderman.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/All Crap Tunes/Old School/Santana/Supernatural/Corazon Espinado Man\#341; Santana Supernatural 09.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Dance/Bran Van 3000/Discosis/16 Love Clich\#351.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Dance/Bran Van 3000/Discosis/03 Montr\#351al.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley Cr\#374e - Generation Swine.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley Cr\#374e - Driftaway.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley Cr\#374e - Uncle Jack.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley Cr\#374e - Get It For Free.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley Cr\#374e - I Wanna Be Sedated.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley Cr\#374e - Live Wire [Kick Ass '91 Remix].wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley Cr\#374e - Black Widow.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley Cr\#374e - Rock 'N' Roll Junkie.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/Motley\#240Crue - Loveshine.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley Cr\#374e - Dragstrip Superstar.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley Cr\#374e - Hammered - 07.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley Cr\#374e - Poison Apples.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley Cr\#374e - Afraid.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley Cr\#374e - Kiss the Sky.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley Cr\#374e - Glitter - Generation Swine - 07.wma") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Original Soundtrack/Various Artists/Various Artists/Pure Dance 1998/U2 Discoth\#350que [DM Radio Mix] 07 Pure Dance 1998 Rock.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Original Soundtrack/Various Artists/Various Artists/Pure Dance 1998/Tony! Toni! Ton\#351! Let's Get Down [Fitch Bros. Club Radio Edit] 06 Pure Dance 1998 Rock.mp3") failed: Invalid argument (22) rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to Seperate/Z Favorite WMA - Songs/Rock n Roll/Q-S/Q/Queensryche/Queensr\#377che - Best I Can - 01.wma") failed: Invalid argument (22) Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 08:56:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54AC8106564A for ; Mon, 14 Nov 2011 08:56:21 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1F83D8FC08 for ; Mon, 14 Nov 2011 08:56:21 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id B4CA1119C6C; Mon, 14 Nov 2011 02:56:20 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1321260980; bh=UwlQBJIciMDfKCb34/1udFR7vmiCBVnjXrtQ9BJU8Pc=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=nLaz1k0Ht094yN045lKb0+AsHm52o+ItoCh6nrNmD6S3DKk4ci+LI3DdRZ1qyfyMK bQzc3rELwPvbOZIRZTCv+9lPpZH/01ihD19P/36xN2NdnPVYHlt1+gmTy+yA0vnjfn T07A4j1fxWQWrxp8r+0gGxI/7PAbDNlQ3lf3t4eU= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id AEE15119C6B; Mon, 14 Nov 2011 02:56:20 -0600 (CST) Date: Mon, 14 Nov 2011 02:56:20 -0600 (CST) From: Dan The Man To: Kurt Touet In-Reply-To: Message-ID: References: <82C85C01-62C4-4E75-B3F2-59D703CA5D78@gsoft.com.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2338054437-1620793793-1321260980=:1814" Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: samba+zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 08:56:21 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2338054437-1620793793-1321260980=:1814 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Running tcpdump to trace what samba is doing so maybe someone can give some insight, lan interface is sk0. 02:52:34.347357 IP (tos 0x0, ttl 64, id 56121, offset 0, flags [none], proto TCP (6), length 1500) asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0x5e3f (correct), seq 105687574:105689034, ack 63894978, win 256, length 1460SMB-over-TCP packet:(raw data or continuation?) 02:52:34.347361 IP (tos 0x0, ttl 64, id 56122, offset 0, flags [none], proto TCP (6), length 1500) asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0xbe99 (correct), seq 105689034:105690494, ack 63894978, win 256, length 1460SMB-over-TCP packet:(raw data or continuation?) 02:52:34.347365 IP (tos 0x0, ttl 64, id 56123, offset 0, flags [none], proto TCP (6), length 1500) asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0x0b31 (correct), seq 105690494:105691954, ack 63894978, win 256, length 1460SMB-over-TCP packet:(raw data or continuation?) 02:52:34.347369 IP (tos 0x0, ttl 64, id 56124, offset 0, flags [none], proto TCP (6), length 1500) asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0xaee6 (correct), seq 105691954:105693414, ack 63894978, win 256, length 1460SMB-over-TCP packet:(raw data or continuation?) 02:52:34.347372 IP (tos 0x0, ttl 64, id 56125, offset 0, flags [none], proto TCP (6), length 1500) asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0xcff5 (correct), seq 105693414:105694874, ack 63894978, win 256, length 1460SMB-over-TCP packet:(raw data or continuation?) 02:52:34.347376 IP (tos 0x0, ttl 64, id 56126, offset 0, flags [none], proto TCP (6), length 1500) asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0xd893 (correct), seq 105694874:105696334, ack 63894978, win 256, length 1460SMB-over-TCP packet:(raw data or continuation?) We get a ton of these, my mapped samba drive on Z: becomes nearly unresponsive after i start transferring things through it, yet I can jump on Y: drive which is NFS mount to same interface on machine and everything is fine and responsive.... Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com On Sat, 12 Nov 2011, Dan The Man wrote: > > > Well been running a week now and problems again. 3 3 terrabyte drives are > @85% with compression enabled, i have to wonder if that is part of the > problem. > > > > Dan. > > > > -- > Dan The Man > CTO/ Senior System Administrator > Websites, Domains and Everything else > http://www.SunSaturn.com > Email: Dan@SunSaturn.com > > On Wed, 9 Nov 2011, Kurt Touet wrote: > >> On Wed, Nov 9, 2011 at 1:07 AM, Daniel O'Connor >> wrote: >>> >>> On 09/11/2011, at 17:32, Garrett Cooper wrote >>>>> dd's of large files (spooled backups going to tape) to /dev/null are as >>>>> slow as Samba. >>>> >>>>    - Dedupe? >>> >>> Nope. >>> >>>>    - Compression? >>> >>> On the mail spool & ports, but not on the tape spool. >>> >>>>    - How much RAM? >>> >>> 8GB. >>> >>>>    - What debug options do you have enabled in the kernel? >>> >>> It is 8.2-GENERIC so.. no WITNESS (for example) >>> >>>>    I've been noticing a slowdown in some respects with NFS/SMB, but I >>>> suspected it was because I have an re(4) based NIC. ZFS has also wired >>>> down a lot of my system memory for the L2ARC… >>> >>> >>> re isn't great but I wouldn't expect it to slow down over time.. Unless >>> bounce buffers got used more and more or something. >>> >>> I have an em0 card in this system - but in any case it is slow locally >>> (i.e. dd a large file with 64k block size). >>> >>> -- >>> Daniel O'Connor software and network engineer >>> for Genesis Software - http://www.gsoft.com.au >>> "The nice thing about standards is that there >>> are so many of them to choose from." >>>  -- Andrew Tanenbaum >>> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >>> >>> >> >> Right now (while experience slow writes via samba+zfs) this is general >> read speed off a 4 x 1.5TB sata2 raidz1: >> >> # dd if=test.file of=/dev/null >> 13753502+1 records in >> 13753502+1 records out >> 7041793036 bytes transferred in 100.020897 secs (70403218 bytes/sec) >> >> That's not in the same ball park of slow writes, but it is below what >> I expect for reads. >> >> My setup is a little odd: 4x1.5tb raidz sata2 on mobo + 2 x 2tb >> mirror on sata1 pci controller, zfs v28, stable/9 r227357, amd x4 810 >> 2.6ghz, 4gb ram, no dedupe, no compression, daily snapshots saved for >> 7 days >> >> The above file read was stored before the 2 x 2tb mirror addition, so >> it was a solely read off the sata2 mobo ports. Reading off of >> something more recent (and split amongst both raidz1 and mirror >> vdevs): >> >> # dd if=test2.file of=/dev/null >> 9154715+1 records in >> 9154715+1 records out >> 4687214153 bytes transferred in 82.963181 secs (56497522 bytes/sec) >> >> This is, again, seems slower than usual, but not as terrible as the >> write speeds that I've been seeing via samba. > --2338054437-1620793793-1321260980=:1814-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 09:19:33 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2E79106566B; Mon, 14 Nov 2011 09:19:32 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0FCA08FC17; Mon, 14 Nov 2011 09:19:31 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA00316; Mon, 14 Nov 2011 11:19:28 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RPshL-0001vX-Ae; Mon, 14 Nov 2011 11:19:27 +0200 Message-ID: <4EC0DD1D.9050704@FreeBSD.org> Date: Mon, 14 Nov 2011 11:19:25 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: FreeBSD current , Alan Cox References: <4EBE4ECC.4060007@FreeBSD.org> In-Reply-To: <4EBE4ECC.4060007@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: problem with 1GB pages? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 09:19:33 -0000 Please disregard my report. I've tracked the problem to one of the new modules being faulty. But memtest86* tools still don't detect any issues with it. Apparently FreeBSD is a much more thorough memory tester than the specialized tools :-) Apologies for the noise. on 12/11/2011 12:47 Andriy Gapon said the following: > > Introduction. > I have an AMD-based system with a Fam10h CPU (with 1GB pages support), the > system chipset contains an integrated graphics device (that uses a region of the > main memory as a graphics memory). The chipset supports memory hoisting to > compensate for the PCI memory window and the graphics aperture both of which are > located below 4GB. > The latest OS version installed on this system is 9-CURRENT from the middle of > September (r225560), architecture is amd64. > Until recently the system had 4GB of RAM installed and I had no problems with it > whatsoever. > > Recently though I have added another 4GB of RAM to the system. Before booting > to FreeBSD I tested the memory with multiple passes of memtest86 and > memetest86+, no errors were detected by those. > However with FreeBSD I immediately started getting "flaky memory" symptoms like > multiple internal compiler errors during compilation of non-trivially sized > projects (world, libreoffice). > I re-run memory tests which again revealed nothing and then started playing with > various VM subsystem and memory related knobs in FreeBSD. I recalled that a > long while ago there were some problems with 1GB pages and so their use used to > be disabled. On a hunch I disabled 1GB pages again: > @@ -471,7 +471,7 @@ create_pagetables(vm_paddr_t *firstaddr) > ndmpdp = 4; > DMPDPphys = allocpages(firstaddr, NDMPML4E); > ndm1g = 0; > - if ((amd_feature & AMDID_PAGE1GB) != 0) > + if (0 && (amd_feature & AMDID_PAGE1GB) != 0) > ndm1g = ptoa(Maxmem) >> PDPSHIFT; > if (ndm1g < ndmpdp) > DMPDphys = allocpages(firstaddr, ndmpdp - ndm1g); > > And the flakiness went away. > > Not sure what kind of useful information I should provide with this report. > Here's couple of things that I think could be of use. > > - memcontrol list output > http://people.freebsd.org/~avg/8gb%2b512mb.memcontrol.list.txt > > - BIOS memory map > SMAP type=01 base=0000000000000000 end=000000000009f800 len=000000000009f800 > SMAP type=02 base=00000000000f0000 end=0000000000100000 len=0000000000010000 > SMAP type=02 base=00000000fec00000 end=0000000100000000 len=0000000001400000 > SMAP type=02 base=00000000e0000000 end=00000000f0000000 len=0000000010000000 > SMAP type=02 base=000000000009f800 end=00000000000a0000 len=0000000000000800 > SMAP type=02 base=00000000afdf0000 end=00000000afe00000 len=0000000000010000 > SMAP type=01 base=0000000000100000 end=00000000afde0000 len=00000000afce0000 > SMAP type=03 base=00000000afde3000 end=00000000afdf0000 len=000000000000d000 > SMAP type=04 base=00000000afde0000 end=00000000afde3000 len=0000000000003000 > SMAP type=01 base=0000000100000000 end=0000000230000000 len=0000000130000000 > > - dmesg snippet > CPU: AMD Athlon(tm) II X2 250 Processor (3013.78-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x100f62 Family = 10 Model = 6 Stepping = 2 > > Features=0x178bfbff > Features2=0x802009 > AMD Features=0xee500800 > AMD > Features2=0x37ff > TSC: P-state invariant > real memory = 8589934592 (8192 MB) > avail memory = 7617662976 (7264 MB) > > - Top Of Memory MSR > MSR 0xc001001a: 0x00000000 0xd0000000 > > - Top Of Memory 2 MSR > MSR 0xc001001d: 0x00000002 0x30000000 > > - System configuration MSR > MSR 0xc0010010: 0x00000000 0x00760600 > > Please let me know if you have any ideas or requests for additional information > or testing. > Thank you. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 09:58:06 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFDA6106564A for ; Mon, 14 Nov 2011 09:58:06 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CBC088FC0A for ; Mon, 14 Nov 2011 09:58:05 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA01715; Mon, 14 Nov 2011 11:58:03 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RPtIh-0001xQ-7Q; Mon, 14 Nov 2011 11:58:03 +0200 Message-ID: <4EC0E62A.4040708@FreeBSD.org> Date: Mon, 14 Nov 2011 11:58:02 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Kostik Belousov References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 09:58:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kostik, thanks a lot! I am not really sorry for taking part in tricking you into doing this :) I guess I now own that cognac back :) on 13/11/2011 10:32 Kostik Belousov said the following: > I was tricked into finishing the work by Andrey Gapon, who developed the > patch to reliably stop other processors on panic. The patch greatly > improves the chances of getting dump on panic on SMP host. Several people > already saw the patchset, and I remember that Andrey posted it to some > lists. > > The change stops other (*) processors early upon the panic. This way, no > parallel manipulation of the kernel memory is performed by CPUs. In > particular, the kernel memory map is static. Patch prevents the panic > thread from blocking and switching out. > > * - in the context of the description, other means not current. > > Since other threads are not run anymore, lock owner cannot release a lock > which is required by panic thread. Due to this, we need to fake a lock > acquisition after the panic, which adds minimal overhead to the locking > cost. The patch tries to not add any overhead on the fast path of the lock > acquire. The check for the after-panic condition was reduced to single > memory access, done only when the quick cas lock attempt failed, and > braced with __unlikely compiler hint. > > For now, the new mode of operation is disabled by default, since some > further USB changes are needed to make USB keyboard usable in that > environment. > > With the patch, getting a dump from the machine without debugger compiled > in is much more realistic. Please comment, I will commit the change in 2 > weeks unless strong reasons not to are given. > > http://people.freebsd.org/~kib/misc/stop_cpus_on_panic.1.patch > - -- Andriy Gapon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOwOYqAAoJEHSlLSemUf4v8VYH/13H/MXhxOc6Vz6r+M6x4yDn 03/TwS+QO7+689KEWvr5NQjPcV7cI3Ku3UIS3QlSUQIZYhhepJjK1UgQHM7ra5yr qzXwpEEealJc7GKSjMTIAsjpfcPgRdT66nwymPZWS3ojZJVXYPiGmc4p3uDVrAgv MnuKOdOVUaeI4tOqYa4wWoCSz++tTpbqIGQrlLTWn8yzhGDvNdj2YTEPoETbrTWO E/t8r+BPqeE5pkJjEoDMOpdZqzBB/45x5krocVVCWZL8gt5hp7c5CutGe6lsJ3on Agv5CGyCQb50AmyapDhc/miECtf4qEekFxO3wiqNBTgHxoN2uxvkIMvUhNlxqGg= =yxdc -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 09:59:17 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0D3F106566C for ; Mon, 14 Nov 2011 09:59:17 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 2F9DA8FC12 for ; Mon, 14 Nov 2011 09:59:16 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MFOim-1ReAWF2lV6-00EwMs; Mon, 14 Nov 2011 10:59:16 +0100 Message-ID: <4EC0E672.2030700@brockmann-consult.de> Date: Mon, 14 Nov 2011 10:59:14 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <82C85C01-62C4-4E75-B3F2-59D703CA5D78@gsoft.com.au> In-Reply-To: X-Enigmail-Version: 1.1.2 X-Provags-ID: V02:K0:11swLJ/d7Zs/MJlKRX234tpOT0QU9TZ5I2XP+tsSsJU yiRzbvNivkTEnyqqH4Hf9AlvIuvJsjU7MBCb/xghQpmdGokloJ LAkAP9JRa9gXJti+9YIkRIJnvdGhmvjvfz/1yli5vR6YU0Mttu g+A5WAnrVEOdALFyuTZT3r/gPVDx1/hZs8k4eVpLM2IiDs7dPr Ln8iV7RRI9wzEpILDMy4vjVNWB7d0GL5QSw43c0Z4fRvb7cO6I C0H6mgmjLRYk6AbAxyW1TwBmetSkajy5PaV77QsLEsXw8j8ntg t2QqYgNF8+QZOkAxISD0sDgErKziiye9E6TuFnpd3DuRpPZlho RubM88vwc+2eanulm5YWn9Uasf+pv/Jx2zu0uvYhN Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: samba+zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 09:59:17 -0000 Dan, I may have had the same problem and solved it. I'm not quite sure at all it is related though. Try adding these 2 lines to your [global] section of your smb.conf on the samba server: strict locking = no blocking locks = no I don't know if the above will cause some data integrity penalty associated with crashes, power failures, etc. with synchronous writes, or people opening and writing the same file. Details about my case: I have a tight security ZFS file server that uses NFS only. I have a second (virtual machine) file server with lots of user accounts (the reason it is a separate server) that actually has no files to serve, but uses the NFS mounts to share files over samba. Without the locking options set to "no", is a small amount of activity, maybe only with more than 1 client on the files, it seems like the samba share is totally locked up when trying to do a listing of a directory with more than 5 or so files in it. And *please *confirm that you have checked the io load % on your disks using gstat when doing this writing. If you don't do that, it could even be as simple as a single disk in an array having very poor access times (such as what would happen on a failing consumer grade disk with bad media). For example: http://fsk141.com/slow-zfs-zpool he ends with "I wish I would have ran an iostat before trying all the things that I did :(" My own example: I had a bad disk in a 16 disk array. It caused boot to take so long that I removed the disk and rebooted again instead of waiting. Scrubs would go 51 MB/s with the disk ONLINE, and 761 MB/s with the disk OFFLINE. Doing any testing would show the disk at 100-128% load with all other disks at 0%. Resilvering had similar results. Replacing the disk made everything perfectly normal again. Peter On 11/14/2011 09:56 AM, Dan The Man wrote: > > > Running tcpdump to trace what samba is doing so maybe someone can give > some insight, lan interface is sk0. > > > 02:52:34.347357 IP (tos 0x0, ttl 64, id 56121, offset 0, flags [none], > proto TCP (6), length 1500) > asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0x5e3f > (correct), seq 105687574:105689034, ack 63894978, win 256, length > 1460SMB-over-TCP packet:(raw data or continuation?) > > 02:52:34.347361 IP (tos 0x0, ttl 64, id 56122, offset 0, flags [none], > proto TCP (6), length 1500) > asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0xbe99 > (correct), seq 105689034:105690494, ack 63894978, win 256, length > 1460SMB-over-TCP packet:(raw data or continuation?) > > 02:52:34.347365 IP (tos 0x0, ttl 64, id 56123, offset 0, flags [none], > proto TCP (6), length 1500) > asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0x0b31 > (correct), seq 105690494:105691954, ack 63894978, win 256, length > 1460SMB-over-TCP packet:(raw data or continuation?) > > 02:52:34.347369 IP (tos 0x0, ttl 64, id 56124, offset 0, flags [none], > proto TCP (6), length 1500) > asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0xaee6 > (correct), seq 105691954:105693414, ack 63894978, win 256, length > 1460SMB-over-TCP packet:(raw data or continuation?) > > 02:52:34.347372 IP (tos 0x0, ttl 64, id 56125, offset 0, flags [none], > proto TCP (6), length 1500) > asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0xcff5 > (correct), seq 105693414:105694874, ack 63894978, win 256, length > 1460SMB-over-TCP packet:(raw data or continuation?) > > 02:52:34.347376 IP (tos 0x0, ttl 64, id 56126, offset 0, flags [none], > proto TCP (6), length 1500) > asterisk.microsoft-ds > desktop.58858: Flags [.], cksum 0xd893 > (correct), seq 105694874:105696334, ack 63894978, win 256, length > 1460SMB-over-TCP packet:(raw data or continuation?) > > We get a ton of these, my mapped samba drive on Z: becomes nearly > unresponsive after i start transferring things through it, yet I can > jump on Y: drive which is NFS mount to same interface on machine and > everything is fine and responsive.... > > > Dan. > > > -- > Dan The Man > CTO/ Senior System Administrator > Websites, Domains and Everything else > http://www.SunSaturn.com > Email: Dan@SunSaturn.com > > On Sat, 12 Nov 2011, Dan The Man wrote: > >> >> >> Well been running a week now and problems again. 3 3 terrabyte drives >> are @85% with compression enabled, i have to wonder if that is part >> of the problem. >> >> >> >> Dan. >> >> >> >> -- >> Dan The Man >> CTO/ Senior System Administrator >> Websites, Domains and Everything else >> http://www.SunSaturn.com >> Email: Dan@SunSaturn.com >> >> On Wed, 9 Nov 2011, Kurt Touet wrote: >> >>> On Wed, Nov 9, 2011 at 1:07 AM, Daniel O'Connor >>> wrote: >>>> >>>> On 09/11/2011, at 17:32, Garrett Cooper wrote >>>>>> dd's of large files (spooled backups going to tape) to /dev/null >>>>>> are as slow as Samba. >>>>> >>>>> - Dedupe? >>>> >>>> Nope. >>>> >>>>> - Compression? >>>> >>>> On the mail spool & ports, but not on the tape spool. >>>> >>>>> - How much RAM? >>>> >>>> 8GB. >>>> >>>>> - What debug options do you have enabled in the kernel? >>>> >>>> It is 8.2-GENERIC so.. no WITNESS (for example) >>>> >>>>> I've been noticing a slowdown in some respects with NFS/SMB, but I >>>>> suspected it was because I have an re(4) based NIC. ZFS has also >>>>> wired >>>>> down a lot of my system memory for the L2ARC… >>>> >>>> >>>> re isn't great but I wouldn't expect it to slow down over time.. >>>> Unless bounce buffers got used more and more or something. >>>> >>>> I have an em0 card in this system - but in any case it is slow >>>> locally (i.e. dd a large file with 64k block size). >>>> >>>> -- >>>> Daniel O'Connor software and network engineer >>>> for Genesis Software - http://www.gsoft.com.au >>>> "The nice thing about standards is that there >>>> are so many of them to choose from." >>>> -- Andrew Tanenbaum >>>> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >>>> >>>> >>> >>> Right now (while experience slow writes via samba+zfs) this is general >>> read speed off a 4 x 1.5TB sata2 raidz1: >>> >>> # dd if=test.file of=/dev/null >>> 13753502+1 records in >>> 13753502+1 records out >>> 7041793036 bytes transferred in 100.020897 secs (70403218 bytes/sec) >>> >>> That's not in the same ball park of slow writes, but it is below what >>> I expect for reads. >>> >>> My setup is a little odd: 4x1.5tb raidz sata2 on mobo + 2 x 2tb >>> mirror on sata1 pci controller, zfs v28, stable/9 r227357, amd x4 810 >>> 2.6ghz, 4gb ram, no dedupe, no compression, daily snapshots saved for >>> 7 days >>> >>> The above file read was stored before the 2 x 2tb mirror addition, so >>> it was a solely read off the sata2 mobo ports. Reading off of >>> something more recent (and split amongst both raidz1 and mirror >>> vdevs): >>> >>> # dd if=test2.file of=/dev/null >>> 9154715+1 records in >>> 9154715+1 records out >>> 4687214153 bytes transferred in 82.963181 secs (56497522 bytes/sec) >>> >>> This is, again, seems slower than usual, but not as terrible as the >>> write speeds that I've been seeing via samba. >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 10:06:52 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BAC01065672 for ; Mon, 14 Nov 2011 10:06:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B6FAA8FC15 for ; Mon, 14 Nov 2011 10:06:51 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA01903; Mon, 14 Nov 2011 12:06:49 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RPtRB-0001xu-1C; Mon, 14 Nov 2011 12:06:49 +0200 Message-ID: <4EC0E838.50609@FreeBSD.org> Date: Mon, 14 Nov 2011 12:06:48 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Kostik Belousov References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 10:06:52 -0000 on 13/11/2011 10:32 Kostik Belousov said the following: > I was tricked into finishing the work by Andrey Gapon, who developed the > patch to reliably stop other processors on panic. The patch greatly > improves the chances of getting dump on panic on SMP host. Several people > already saw the patchset, and I remember that Andrey posted it to some > lists. > > The change stops other (*) processors early upon the panic. This way, no > parallel manipulation of the kernel memory is performed by CPUs. In > particular, the kernel memory map is static. Patch prevents the panic > thread from blocking and switching out. > > * - in the context of the description, other means not current. > > Since other threads are not run anymore, lock owner cannot release a lock > which is required by panic thread. Due to this, we need to fake a lock > acquisition after the panic, which adds minimal overhead to the locking > cost. The patch tries to not add any overhead on the fast path of the lock > acquire. The check for the after-panic condition was reduced to single > memory access, done only when the quick cas lock attempt failed, and braced > with __unlikely compiler hint. > > For now, the new mode of operation is disabled by default, since some > further USB changes are needed to make USB keyboard usable in that > environment. > > With the patch, getting a dump from the machine without debugger compiled > in is much more realistic. Please comment, I will commit the change in 2 > weeks unless strong reasons not to are given. > > http://people.freebsd.org/~kib/misc/stop_cpus_on_panic.1.patch > On a more serious note: - some code in my latest version of the patch was contributed by or was based on the code or ideas contributed by jhb and mdf (so that attributions are not lost) - there was a concern about how sync-on-panic would work About the latter, I have never really tested it. mdf has suggested to move the sync-on-panic code to a place after we ensure that there is only one CPU in panic(), but before we stop other CPUs. I think that I've already sent you a list of the early testers for various WIP versions of the patch. And thanks a lot again. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 10:14:28 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BBB11065670 for ; Mon, 14 Nov 2011 10:14:28 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C4ED58FC0C for ; Mon, 14 Nov 2011 10:14:27 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA02019; Mon, 14 Nov 2011 12:14:25 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RPtYX-0001y5-HU; Mon, 14 Nov 2011 12:14:25 +0200 Message-ID: <4EC0EA00.8030608@FreeBSD.org> Date: Mon, 14 Nov 2011 12:14:24 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Arnaud Lacombe References: <4EB9C469.9070208@freebsd.org> <4EB9E6FE.3060102@freebsd.org> <4EBABAC1.2090003@freebsd.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 10:14:28 -0000 on 14/11/2011 02:38 Arnaud Lacombe said the following: > you (committers) I wonder how it would work out if you were made a committer and couldn't say "you (committers)" any more... :-) I.e. is it possible to change your mindset from "me (and us) versus you" to just "us"? The lines between committers and contributors and users are very blurry and are mostly in people's heads rather than in reality. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 11:45:37 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6FA9106564A for ; Mon, 14 Nov 2011 11:45:37 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id A23048FC0A for ; Mon, 14 Nov 2011 11:45:37 +0000 (UTC) Received: by qadb10 with SMTP id b10so1594211qad.13 for ; Mon, 14 Nov 2011 03:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=xXxqgiJ8EqVeA/jVu6Qg9Rn/DB190r6v8/elK/68on0=; b=NMH4hfstfv7c2KR7XoF4Ra8BJKOcqEsG8L7VQILL59OIFcTtNtv6y8Qh8Pv93b6nVN 1GZ/jJLxgBhOf48ADMYKYHTkGrr7CbDq4xv6llC1EnDovd+p0/gToq1jk/jIMbe7jmR6 oGvaIWwwu7gtsB/JKkB3IG5Vl0W1HneAHd4zY= MIME-Version: 1.0 Received: by 10.224.185.199 with SMTP id cp7mr13535123qab.68.1321271135794; Mon, 14 Nov 2011 03:45:35 -0800 (PST) Received: by 10.224.73.195 with HTTP; Mon, 14 Nov 2011 03:45:35 -0800 (PST) Date: Mon, 14 Nov 2011 06:45:35 -0500 Message-ID: From: Mehmet Erol Sanliturk To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: FreeBSD ftp mirror sites and pkg_add X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 11:45:38 -0000 In Arch Linux , package manager Pacman is using a configuration file /etc/pacman.conf with its included files . It is using a file such as the following ( some parts are deleted for message ) : ( obtained from http://www.archlinux.org/mirrorlist/all/ftp/ ) : --------------------------------- ## ## Arch Linux repository mirrorlist ## Generated on 2011-11-13 ## ## Any #Server = ftp://mirrors.kernel.org/archlinux/$repo/os/$arch ## Australia #Server = ftp://mirror.aarnet.edu.au/pub/archlinux/$repo/os/$arch #Server = ftp://ftp.iinet.net.au/pub/archlinux/$repo/os/$arch #Server = ftp://mirror.internode.on.net/pub/archlinux/$repo/os/$arch #Server = ftp://mirror.optus.net/archlinux/$repo/os/$arch ... ## Canada #Server = ftp://mirror.csclub.uwaterloo.ca/archlinux/$repo/os/$arch #Server = ftp://mirror.its.dal.ca/archlinux/$repo/os/$arch #Server = ftp://less.cogeco.net/pub/archlinux/$repo/os/$arch ... ## Great Britain #Server = ftp://mirror.lividpenguin.com/pub/archlinux/$repo/os/$arch #Server = ftp://mirror.cinosure.com/archlinux/$repo/os/$arch #Server = ftp://mirrors.uk2.net/pub/archlinux/$repo/os/$arch ... ## Turkey #Server = ftp://ftp.linux.org.tr/archlinux/$repo/os/$arch ... ## United States #Server = ftp://archlinux.supsec.org/pub/linux/arch/$repo/os/$arch #Server = ftp://cake.lib.fit.edu/archlinux/$repo/os/$arch #Server = ftp://cosmos.cites.illinois.edu/pub/archlinux/$repo/os/$arch #Server = ftp://ftp.archlinux.org/$repo/os/$arch #Server = ftp://ftp.gtlib.gatech.edu/pub/archlinux/$repo/os/$arch #Server = ftp://mirror.ancl.hawaii.edu/linux/archlinux/$repo/os/$arch #Server = ftp://mirror.us.leaseweb.net/archlinux/$repo/os/$arch #Server = ftp://locke.suu.edu/linux/dist/archlinux/$repo/os/$arch #Server = ftp://ftp.osuosl.org/pub/archlinux/$repo/os/$arch #Server = ftp://mirror.rit.edu/archlinux/$repo/os/$arch --------------------------------- The advised action is to edit this file and activate nearest or suitable mirrors by removing comment sign ( # ) in front of the relevant mirror . During package install , this file is used and traversed up to an available mirror , when a mirror fails from beginning . ................. In FreeBSD , pkg_add http://svnweb.freebsd.org/base/head/usr.sbin/pkg_install/add/main.c?view=markup the ONLY package site is taken by getpackagesite(void) from if (getenv("PACKAGESITE")) which it is ONLY ftp.FreeBSD.org . When the statement if ((packagesite = getpackagesite()) == NULL) fails , it is necessary either to wait up to a working state of the ftp.FreeBSD.org or edit the "PACKAGESITE" environment variable up to a success which is NOT an expected action from the beginners . Instead of this , it is possible to use a pkg_add.conf and insert into a list of ALL available ftp.*.FreeBSD.org sites http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html AND OTHER mirror ftp sites synchronized by central FreeBSD ftp sites . Every site will be commented out , but ftp://ftp.FreeBSD.org... will be available . For example : --------------------------------- # From # http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html : # The official sources for FreeBSD are available via anonymous FTP # from a worldwide set of mirror sites. # The site ftp://ftp.FreeBSD.org/pub/FreeBSD/ is well connected and # allows a large number of connections to it, # but you are probably better off finding a closer mirror site # (especially if you decide to set up some sort of mirror site). # The adviced action is the following : # Move the nearest mirror site link to top , # and second nearest mirror to second line , # up to mirrors suitable to use , # AND remove comment signs in front of them . ## Australia #ftp://ftp.au.freebsd.org/pub/FreeBSD/ #ftp://ftp2.au.freebsd.org/pub/FreeBSD/ ... ## Canada #ftp://ftp.ca.freebsd.org/pub/FreeBSD/ #ftp://ftp2.ca.freebsd.org/ #ftp://ftp3.ca.freebsd.org/pub/FreeBSD/ ... ## Turkey #ftp://ftp.tr.freebsd.org/pub/FreeBSD/ #ftp://ftp2.tr.freebsd.org/pub/FreeBSD/ ... ## United Kingdom #ftp://ftp.uk.freebsd.org/pub/FreeBSD/ #ftp://ftp2.uk.freebsd.org/pub/FreeBSD/ ... ## United States #ftp://ftp1.us.freebsd.org/pub/FreeBSD/ #ftp://ftp2.us.freebsd.org/pub/FreeBSD/ ... ftp://ftp.freebsd.org/pub/FreeBSD/ --------------------------------- This feature and what to do advise will be stated in the release notes . When pkg_add is started , it will load pkg_add.conf list into an array , AND traverse this array from element one to end , last being the ftp://ftp.freebsd.org/pub/FreeBSD/ . If a mirror site is successful , the package will be installed from this one , and the loop will be discontinued . The suggested structure does NOT change anything from the new user point of view . It is very likely that , experienced users will adhere to use nearest mirror usage advise to reduce load currently carried by the default FreeBSD ftp site . I think , the default ftp site is incurring cost for internet band width usage . Then any cost is saved may be transferred to projects to improve FreeBSD features . ................. I do NOT know such suggestions are irritative or useful , because sometimes it is possible to hear that "if you do ( or can ) not supply a patch , then shut up , ... , shut up" ( where "shut up , ... , shut up" is from "Titanic is sinking" ) . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 12:18:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D03A106564A for ; Mon, 14 Nov 2011 12:18:56 +0000 (UTC) (envelope-from jlaffaye.freebsd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9B1BC8FC0A for ; Mon, 14 Nov 2011 12:18:55 +0000 (UTC) Received: by wwg14 with SMTP id 14so6140490wwg.31 for ; Mon, 14 Nov 2011 04:18:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Qrlk0HK3MRMKOEBYSg1KZF1wuXBa+tAGACks+WCifws=; b=TSrXQKrGgG1SgyfTjmzC0pnWDJJX9kU0IDVspO5fOFPXYzuHB2rV0m6pT7UL5sKd8N bEG87+nYohY2zNQidzh1hk1W7XqJ3S2GPCNJW1rrVRrAK+/cjMO9K3ZQOC0cOro4HCjb CLs4iRGajtBGoQ7cWxSnbiphkfogMuelOi5+4= Received: by 10.227.198.77 with SMTP id en13mr14574710wbb.28.1321271606342; Mon, 14 Nov 2011 03:53:26 -0800 (PST) Received: from [10.42.116.106] (proxy.ovh.net. [213.186.50.98]) by mx.google.com with ESMTPS id en10sm16988152wbb.0.2011.11.14.03.53.24 (version=SSLv3 cipher=OTHER); Mon, 14 Nov 2011 03:53:24 -0800 (PST) Message-ID: <4EC10134.8010906@gmail.com> Date: Mon, 14 Nov 2011 12:53:24 +0100 From: Julien Laffaye User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 Nov 2011 12:31:33 +0000 Subject: Re: FreeBSD ftp mirror sites and pkg_add X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 12:18:56 -0000 On 11/14/2011 12:45 PM, Mehmet Erol Sanliturk wrote: > In Arch Linux , package manager Pacman is using a configuration file > /etc/pacman.conf with its included files . > > > It is using a file such as the following ( some parts are deleted for > message ) : > > ( obtained from > http://www.archlinux.org/mirrorlist/all/ftp/ > ) : > > --------------------------------- > > ## > ## Arch Linux repository mirrorlist > ## Generated on 2011-11-13 > ## > > ## Any > #Server = ftp://mirrors.kernel.org/archlinux/$repo/os/$arch > > ## Australia > #Server = ftp://mirror.aarnet.edu.au/pub/archlinux/$repo/os/$arch > #Server = ftp://ftp.iinet.net.au/pub/archlinux/$repo/os/$arch > #Server = ftp://mirror.internode.on.net/pub/archlinux/$repo/os/$arch > #Server = ftp://mirror.optus.net/archlinux/$repo/os/$arch > > ... > > ## Canada > #Server = ftp://mirror.csclub.uwaterloo.ca/archlinux/$repo/os/$arch > #Server = ftp://mirror.its.dal.ca/archlinux/$repo/os/$arch > #Server = ftp://less.cogeco.net/pub/archlinux/$repo/os/$arch > > ... > > ## Great Britain > #Server = ftp://mirror.lividpenguin.com/pub/archlinux/$repo/os/$arch > #Server = ftp://mirror.cinosure.com/archlinux/$repo/os/$arch > #Server = ftp://mirrors.uk2.net/pub/archlinux/$repo/os/$arch > > ... > > ## Turkey > #Server = ftp://ftp.linux.org.tr/archlinux/$repo/os/$arch > > ... > > ## United States > #Server = ftp://archlinux.supsec.org/pub/linux/arch/$repo/os/$arch > #Server = ftp://cake.lib.fit.edu/archlinux/$repo/os/$arch > #Server = ftp://cosmos.cites.illinois.edu/pub/archlinux/$repo/os/$arch > #Server = ftp://ftp.archlinux.org/$repo/os/$arch > #Server = ftp://ftp.gtlib.gatech.edu/pub/archlinux/$repo/os/$arch > #Server = ftp://mirror.ancl.hawaii.edu/linux/archlinux/$repo/os/$arch > #Server = ftp://mirror.us.leaseweb.net/archlinux/$repo/os/$arch > #Server = ftp://locke.suu.edu/linux/dist/archlinux/$repo/os/$arch > #Server = ftp://ftp.osuosl.org/pub/archlinux/$repo/os/$arch > #Server = ftp://mirror.rit.edu/archlinux/$repo/os/$arch > > --------------------------------- > > The advised action is to edit this file and activate nearest or > suitable mirrors by removing comment sign ( # ) in front of > the relevant mirror . > > During package install , this file is used and traversed up to > an available mirror , when a mirror fails from beginning . > > ................. > > > In FreeBSD , pkg_add > > > http://svnweb.freebsd.org/base/head/usr.sbin/pkg_install/add/main.c?view=markup > > the ONLY package site is taken by > > getpackagesite(void) > > from > > if (getenv("PACKAGESITE")) > > which it is ONLY ftp.FreeBSD.org . > > When the statement > > if ((packagesite = getpackagesite()) == NULL) > > fails , it is necessary either to wait up to a working state of the > ftp.FreeBSD.org > or edit the "PACKAGESITE" environment variable up to a success which > is NOT an expected action from the beginners . > > > Instead of this , it is possible to use a pkg_add.conf > and insert into a list of ALL available ftp.*.FreeBSD.org sites > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html > > AND > > OTHER mirror ftp sites synchronized by central FreeBSD ftp sites . > > Every site will be commented out , but > > ftp://ftp.FreeBSD.org... > > will be available . > > For example : > > --------------------------------- > > # From > > # http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html > > : > > # The official sources for FreeBSD are available via anonymous FTP > # from a worldwide set of mirror sites. > # The site ftp://ftp.FreeBSD.org/pub/FreeBSD/ is well connected and > # allows a large number of connections to it, > # but you are probably better off finding a closer mirror site > # (especially if you decide to set up some sort of mirror site). > > > # The adviced action is the following : > > > # Move the nearest mirror site link to top , > # and second nearest mirror to second line , > # up to mirrors suitable to use , > # AND remove comment signs in front of them . > > ## Australia > > #ftp://ftp.au.freebsd.org/pub/FreeBSD/ > #ftp://ftp2.au.freebsd.org/pub/FreeBSD/ > > ... > > ## Canada > > #ftp://ftp.ca.freebsd.org/pub/FreeBSD/ > #ftp://ftp2.ca.freebsd.org/ > #ftp://ftp3.ca.freebsd.org/pub/FreeBSD/ > > ... > > ## Turkey > > #ftp://ftp.tr.freebsd.org/pub/FreeBSD/ > #ftp://ftp2.tr.freebsd.org/pub/FreeBSD/ > > ... > > ## United Kingdom > > #ftp://ftp.uk.freebsd.org/pub/FreeBSD/ > #ftp://ftp2.uk.freebsd.org/pub/FreeBSD/ > > ... > > ## United States > > #ftp://ftp1.us.freebsd.org/pub/FreeBSD/ > #ftp://ftp2.us.freebsd.org/pub/FreeBSD/ > > ... > > ftp://ftp.freebsd.org/pub/FreeBSD/ > > --------------------------------- > > This feature and what to do advise will be stated in the release notes . > > When pkg_add is started , it will load pkg_add.conf list > into an array , AND traverse this array from element one to > end , last being the ftp://ftp.freebsd.org/pub/FreeBSD/ . > > If a mirror site is successful , the package will be installed from this > one , > and the loop will be discontinued . > > The suggested structure does NOT change anything from the new > user point of view . > > It is very likely that , experienced users will adhere to > use nearest mirror usage advise to reduce load currently > carried by the default FreeBSD ftp site . > > I think , the default ftp site is incurring cost for > internet band width usage . > > Then any cost is saved may be transferred to projects to > improve FreeBSD features . > > ................. > > I do NOT know such suggestions are irritative or useful , > because sometimes it is possible to hear that > > "if you do ( or can ) not supply a patch , > then shut up , ... , shut up" > > > ( where "shut up , ... , shut up" is from "Titanic is sinking" ) . > > > Thank you very much . > > > Mehmet Erol Sanliturk With the new pkgng tool, you can change the ftp site in a configuration file. Please also note that the distribution method might change in the near future (a CDN?). From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 13:09:03 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C75081065670; Mon, 14 Nov 2011 13:09:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C10DC8FC1A; Mon, 14 Nov 2011 13:09:02 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAED8vkE068215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2011 15:08:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAED8v7G098385; Mon, 14 Nov 2011 15:08:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAED8vKg098384; Mon, 14 Nov 2011 15:08:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 14 Nov 2011 15:08:57 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20111114130857.GC50300@deviant.kiev.zoral.com.ua> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <4EC0E838.50609@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YTXTVaVjKhDLKTix" Content-Disposition: inline In-Reply-To: <4EC0E838.50609@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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: arch@freebsd.org, current@freebsd.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 13:09:03 -0000 --YTXTVaVjKhDLKTix Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 14, 2011 at 12:06:48PM +0200, Andriy Gapon wrote: > on 13/11/2011 10:32 Kostik Belousov said the following: > > I was tricked into finishing the work by Andrey Gapon, who developed the > > patch to reliably stop other processors on panic. The patch greatly > > improves the chances of getting dump on panic on SMP host. Several peop= le > > already saw the patchset, and I remember that Andrey posted it to some > > lists. > >=20 > > The change stops other (*) processors early upon the panic. This way, = no > > parallel manipulation of the kernel memory is performed by CPUs. In > > particular, the kernel memory map is static. Patch prevents the panic > > thread from blocking and switching out. > >=20 > > * - in the context of the description, other means not current. > >=20 > > Since other threads are not run anymore, lock owner cannot release a lo= ck > > which is required by panic thread. Due to this, we need to fake a lock > > acquisition after the panic, which adds minimal overhead to the locking > > cost. The patch tries to not add any overhead on the fast path of the l= ock > > acquire. The check for the after-panic condition was reduced to single > > memory access, done only when the quick cas lock attempt failed, and br= aced > > with __unlikely compiler hint. > >=20 > > For now, the new mode of operation is disabled by default, since some= =20 > > further USB changes are needed to make USB keyboard usable in that=20 > > environment. > >=20 > > With the patch, getting a dump from the machine without debugger compil= ed > > in is much more realistic. Please comment, I will commit the change in= 2 > > weeks unless strong reasons not to are given. > >=20 > > http://people.freebsd.org/~kib/misc/stop_cpus_on_panic.1.patch > >=20 >=20 >=20 > On a more serious note: > - some code in my latest version of the patch was contributed by or was b= ased > on the code or ideas contributed by jhb and mdf (so that attributions are= not > lost) Please provide me with proper attribution for contributors and testers. > - there was a concern about how sync-on-panic would work >=20 > About the latter, I have never really tested it. mdf has suggested to > move the sync-on-panic code to a place after we ensure that there is > only one CPU in panic(), but before we stop other CPUs. sync_on_panic is incompatible with the patch. I argue that it provides non-zero chance of damaging good filesystems even if panic was unrelated to the fs/bio/device layer. As an example, consider the case when other CPU was modifying in-memory representation of the metadata, and panic happen on this CPU. If you write half-changed block back, you make more damage to the filesystem then if you do not. The half-backed sync spoils any journaling or SU consistency guarantees. The issues of multithreading nature of our storage subsystem are secondary. The user who sets either tunable shall know what he does. > > I think that I've already sent you a list of the early testers for > various WIP versions of the patch. I do not have the list. BTW, if you want, feel free to handle the commit youself. You definitely spent much more efforts on the stuff and deserve the credit. I was promised in private that a review will be provided during this weekend. --YTXTVaVjKhDLKTix Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7BEukACgkQC3+MBN1Mb4gE/wCggdI+mhzimk5hH5kOX6F70qMb AZcAnAx/abmVDuBXVq9zHSGIoEDJUhFX =dG36 -----END PGP SIGNATURE----- --YTXTVaVjKhDLKTix-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 13:30:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ADDD1065672 for ; Mon, 14 Nov 2011 13:30:42 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 59A1A8FC13 for ; Mon, 14 Nov 2011 13:30:42 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 62970119C69; Mon, 14 Nov 2011 07:30:41 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1321277441; bh=/7jb33TVT1yFt1Oq7DySbmvCvjXKGI2AgsgyVUqA+gY=; h=Date:From:To:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=ZRd9nXBe1pWR1V7o+5JFNXugbYnwC2WmC8TCa6CrKXQ/DNF/5bQwiefQ1hkW3hYO0 NRXIi5vJoEz3ufZsABNEG2e2JkNRPfgm1nMVUKWE1uthFPD3A01r6oRH0L1QoEpKRk PhZOZgPI0+LTjrP5RVnOT6nTQbzmPLTbHfyMVUPs= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 5D6DE119C66 for ; Mon, 14 Nov 2011 07:30:41 -0600 (CST) Date: Mon, 14 Nov 2011 07:30:41 -0600 (CST) From: Dan The Man To: freebsd-current@freebsd.org In-Reply-To: Message-ID: References: <82C85C01-62C4-4E75-B3F2-59D703CA5D78@gsoft.com.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: samba+zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 13:30:42 -0000 Thankyou for suggestion Peter , didn't solve it, and no its not the disks , I have been monitoring gstat and its doing what it should, NFS works just fine. Here is typical NFS session from tcpdump 07:13:42.192671 IP asterisk.nfsd > desktop.kink: Flags [.], ack 19048093, win 29124, length 0 07:13:42.192673 IP desktop.kink > asterisk.nfsd: Flags [.], seq 19048093:19049553, ack 16176768, win 16178, length 1460 07:13:42.192679 IP asterisk.nfsd > desktop.kink: Flags [.], ack 19049553, win 29124, length 0 07:13:42.192680 IP desktop.kink > asterisk.nfsd: Flags [.], seq 19049553:19051013, ack 16176768, win 16178, length 1460 07:13:42.192686 IP asterisk.nfsd > desktop.kink: Flags [.], ack 19051013, win 29124, length 0 07:13:42.192765 IP desktop.kink > asterisk.nfsd: Flags [.], seq 19051013:19052473, ack 16176768, win 16178, length 1460 07:13:42.192771 IP asterisk.nfsd > desktop.kink: Flags [.], ack 19052473, win 29124, length 0 07:13:42.192772 IP desktop.kink > asterisk.nfsd: Flags [.], seq 19052473:19053933, ack 16176768, win 16178, length 1460 07:13:42.192778 IP asterisk.nfsd > desktop.kink: Flags [.], ack 19053933, win 29124, length 0 07:13:42.192780 IP desktop.kink > asterisk.nfsd: Flags [.], seq 19053933:19055393, ack 16176768, win 16178, length 1460 07:13:42.192786 IP asterisk.nfsd > desktop.kink: Flags [.], ack 19055393, win 29124, length 0 07:13:42.192787 IP desktop.kink > asterisk.nfsd: Flags [.], seq 19055393:19056853, ack 16176768, win 16178, length 1460 07:13:42.192793 IP asterisk.nfsd > desktop.kink: Flags [.], ack 19056853, win 29124, length 0 07:13:42.192795 IP desktop.kink > asterisk.nfsd: Flags [.], seq 19056853:19058313, ack 16176768, win 16178, length 1460 Its always sitting in rpcsvc around 2% cpu doing what it should. Samba on other hand what I find interesting is I tried to see what truss would show on smbd while writing today and found the following: ################################################################################# geteuid() = 0 (0x0) write(36,"[2011/11/14 07:26:07.939217, 10]"...,67) = 67 (0x43) geteuid() = 0 (0x0) write(36," Running timed event "smbd_idle"...,60) = 60 (0x3c) gettimeofday({1321277167.939372 },0x0) = 0 (0x0) geteuid() = 0 (0x0) write(36,"[2011/11/14 07:26:07.939372, 10]"...,77) = 77 (0x4d) geteuid() = 0 (0x0) write(36," smbd_idle_event_handler: idle_"...,57) = 57 (0x39) gettimeofday({1321277167.939521 },0x0) = 0 (0x0) geteuid() = 0 (0x0) write(36,"[2011/11/14 07:26:07.939521, 10]"...,77) = 77 (0x4d) geteuid() = 0 (0x0) write(36," smbd_idle_event_handler: idle_"...,62) = 62 (0x3e) gettimeofday({1321277167.939671 },0x0) = 0 (0x0) gettimeofday({1321277167.939700 },0x0) = 0 (0x0) gettimeofday({1321277167.939728 },0x0) = 0 (0x0) geteuid() = 0 (0x0) write(36,"[2011/11/14 07:26:07.939728, 10]"...,67) = 67 (0x43) geteuid() = 0 (0x0) write(36," Running timed event "smbd_idle"...,60) = 60 (0x3c) gettimeofday({1321277167.939877 },0x0) = 0 (0x0) geteuid() = 0 (0x0) write(36,"[2011/11/14 07:26:07.939877, 10]"...,77) = 77 (0x4d) geteuid() = 0 (0x0) write(36," smbd_idle_event_handler: idle_"...,61) = 61 (0x3d) gettimeofday({1321277167.940031 },0x0) = 0 (0x0) geteuid() = 0 (0x0) write(36,"[2011/11/14 07:26:07.940031, 5]"...,70) = 70 (0x46) geteuid() = 0 (0x0) write(36," housekeeping\n",15) = 15 (0xf) gettimeofday({1321277167.940177 },0x0) = 0 (0x0) geteuid() = 0 (0x0) write(36,"[2011/11/14 07:26:07.940177, 4]"...,65) = 65 (0x41) geteuid() = 0 (0x0) write(36," setting sec ctx (0, 0) - sec_c"...,49) = 49 (0x31) gettimeofday({1321277167.940327 },0x0) = 0 (0x0) geteuid() = 0 (0x0) write(36,"[2011/11/14 07:26:07.940327, 5]"...,94) = 94 (0x5e) geteuid() = 0 (0x0) write(36," Security token: (NULL)\n",25) = 25 (0x19) gettimeofday({1321277167.940475 },0x0) = 0 (0x0) geteuid() = 0 (0x0) write(36,"[2011/11/14 07:26:07.940475, 5]"...,78) = 78 (0x4e) geteuid() = 0 (0x0) write(36," UNIX token of user 0\n",23) = 23 (0x17) geteuid() = 0 (0x0) write(36," Primary group is 0 and contain"...,57) = 57 (0x39) geteuid() = 0 (0x0) getegid() = 0 (0x0) __sysctl(0x7fffffffd170,0x2,0x7fffffffd18c,0x7fffffffd180,0x0,0x0) = 0 (0x0) It actually seems to be running some timed event smbd_idle literally holding up process for many seconds all the time.... Dan, -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 16:51:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B8D9106564A for ; Mon, 14 Nov 2011 16:51:34 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id B6BE18FC12 for ; Mon, 14 Nov 2011 16:51:33 +0000 (UTC) Received: by eyd10 with SMTP id 10so6677031eyd.13 for ; Mon, 14 Nov 2011 08:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bFS82h+NSGd1KpyDFFz93v3VSW6pk8ue6zKeIQBIp5I=; b=awiaJFQwoWYQQHbApVs5q6/emW+9RCv1rDAgupODyixJ3mLRSRdjkzrbhOCBo1Ghxt 3tTBUd5bMkIDxzekf/7lW+dB9cVtORa0tQ6Y/i2GwQBnGn1YQjDjnL+y/FQ5eXQWphxY RbU0Kc00mNDVcDRMJEWwYBU/PhNEn8JPjH7U4= MIME-Version: 1.0 Received: by 10.182.50.65 with SMTP id a1mr1095026obo.17.1321289492250; Mon, 14 Nov 2011 08:51:32 -0800 (PST) Received: by 10.182.7.34 with HTTP; Mon, 14 Nov 2011 08:51:32 -0800 (PST) In-Reply-To: References: <82C85C01-62C4-4E75-B3F2-59D703CA5D78@gsoft.com.au> Date: Mon, 14 Nov 2011 08:51:32 -0800 Message-ID: From: Garrett Cooper To: Dan The Man Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: samba+zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 16:51:34 -0000 On Mon, Nov 14, 2011 at 5:30 AM, Dan The Man wrote: > > > Thankyou for suggestion Peter , didn't solve it, and no its not the disks , > I have been monitoring gstat and its doing what it should, NFS works just > fine. ... > Its always sitting in rpcsvc around 2% cpu doing what it should. > > Samba on other hand what I find interesting is I tried to see what truss > would show on smbd while writing today and found the following: ... > It actually seems to be running some timed event smbd_idle literally holding > up process for many seconds all the time.... Hmm... samba seems slower (high latency opening files) today than before. Granted, I just reinstalled Windows 7 on my client box so I need to poke around it to determine what the issue is. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 16:42:36 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34937106566C; Mon, 14 Nov 2011 16:42:36 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by mx1.freebsd.org (Postfix) with ESMTP id B2E2A8FC1A; Mon, 14 Nov 2011 16:42:35 +0000 (UTC) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id pAEGLbnY014108; Mon, 14 Nov 2011 17:21:37 +0100 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail3.siemens.de (8.13.6/8.13.6) with ESMTP id pAEGLbGL002561; Mon, 14 Nov 2011 17:21:37 +0100 Received: (from localhost) by curry.mchp.siemens.de (8.14.5/8.14.4) id pAEGLbcw022881; Date: Mon, 14 Nov 2011 17:21:37 +0100 From: Andre Albsmeier To: Doug Barton Message-ID: <20111114162137.GA61487@curry.mchp.siemens.de> References: <200512022006.jB2K67AK078509@repoman.freebsd.org> <20051203004057.GA20872@nagual.pp.ru> <4390EFB6.3090307@FreeBSD.org> <20051203012324.GA34147@nagual.pp.ru> <4390F9A2.208@FreeBSD.org> <20051203020831.GA34619@nagual.pp.ru> <43910010.2050702@FreeBSD.org> <20051203023304.GA34859@nagual.pp.ru> <4391061D.3050105@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4391061D.3050105@FreeBSD.org> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 14 Nov 2011 16:53:32 +0000 Cc: freebsd-current@FreeBSD.org, Andrey Chernov , Andre.Albsmeier@siemens.com Subject: Re: cvs commit: src/etc rc rc.shutdown rc.subr src/etc/rc.d localpkg src/sys/sys param.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 16:42:36 -0000 Yes, this is an old mail I am replying to ;-) On Fri, 02-Dec-2005 at 18:42:37 -0800, Doug Barton wrote: > Andrey Chernov wrote: > > On Fri, Dec 02, 2005 at 06:16:48PM -0800, Doug Barton wrote: > >>> Do you mean that scripts without .sh runs in > >>> the subshell and not damage main shell? > >> Yes, that's what I mean. Once again, sorry I wasn't clear. I've been staring > >> at this for too long now. :) > > > > Just to clarify it finally. You state that there is a big difference > > between system /etc/rc.d scripts (without .sh) which all runs in the > > single shell > > No. The way things stand now, all scripts named foo.sh are sourced into the > main shell, and everything else (base scripts, local scripts, whatever) are Today I stumbled over the fact that this statement only applies to .sh scripts in /etc/rc.d but not to the ones in /usr/local/etc/rc.d. I need to source a script.sh and I put it into /usr/local/etc/rc.d -- only to recognise that it will be run in a subshell. This patch probably would fix this but maybe there is a reason not to do so: --- rc.subr.ORI 2011-11-14 17:18:39.000000000 +0100 +++ rc.subr 2011-11-14 17:19:15.000000000 +0100 @@ -938,7 +938,7 @@ eval unset ${_arg}_cmd ${_arg}_precmd ${_arg}_postcmd case "$_file" in - /etc/rc.d/*.sh) # run in current shell + /etc/rc.d/*.sh | /usr/local/etc/rc.d/*.sh) # run in current shell set $_arg; . $_file ;; *[~#]|*.OLD|*.bak|*.orig|*,v) # scratch file; skip Or even use *.sh) Thanks, -Andre > all run in subshells. You could answer this for yourself by looking in > /etc/rc.subr if it's still not clear. > > >> I should have mentioned in my last message that I did take a quick look at > >> the script itself, and didn't see anything that should be a problem, but as > > > > /usr/bin/limits is the problem there because it change limits for whole > > shell, not for command which just invoked. If all scripts runs in the same > > shell, all subsequential of them will be affected. > > Assuming you're right about that, then you should do something like what I > suggested in the patch I sent so that the script gets installed as apache > instead of apache.sh. > > hth, > > Doug > -- Failure is not an option -- it comes bundled with Windows. From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 17:01:55 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0643B106566C; Mon, 14 Nov 2011 17:01:55 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id C30EF8FC08; Mon, 14 Nov 2011 17:01:54 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id 6701E290EC0; Mon, 14 Nov 2011 11:01:53 -0600 (CST) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id D5512290EDF; Mon, 14 Nov 2011 11:01:52 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id D56UMGLnXxDp; Mon, 14 Nov 2011 11:01:52 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id 5AA52290F3C; Mon, 14 Nov 2011 11:01:48 -0600 (CST) Message-ID: <4EC1497B.20409@rice.edu> Date: Mon, 14 Nov 2011 11:01:47 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Andriy Gapon References: <4EBE4ECC.4060007@FreeBSD.org> <4EC0DD1D.9050704@FreeBSD.org> In-Reply-To: <4EC0DD1D.9050704@FreeBSD.org> Content-Type: text/plain; charset=x-viet-vps; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox , FreeBSD current Subject: Re: problem with 1GB pages? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 17:01:55 -0000 On 11/14/2011 03:19, Andriy Gapon wrote: > Please disregard my report. > I've tracked the problem to one of the new modules being faulty. But memtest86* > tools still don't detect any issues with it. Apparently FreeBSD is a much more > thorough memory tester than the specialized tools :-) > Apologies for the noise. Interesting, nonetheless. I would have never guessed that disabling 1 GB pages would mask a problem due to faulty memory. Alan > on 12/11/2011 12:47 Andriy Gapon said the following: >> Introduction. >> I have an AMD-based system with a Fam10h CPU (with 1GB pages support), the >> system chipset contains an integrated graphics device (that uses a region of the >> main memory as a graphics memory). The chipset supports memory hoisting to >> compensate for the PCI memory window and the graphics aperture both of which are >> located below 4GB. >> The latest OS version installed on this system is 9-CURRENT from the middle of >> September (r225560), architecture is amd64. >> Until recently the system had 4GB of RAM installed and I had no problems with it >> whatsoever. >> >> Recently though I have added another 4GB of RAM to the system. Before booting >> to FreeBSD I tested the memory with multiple passes of memtest86 and >> memetest86+, no errors were detected by those. >> However with FreeBSD I immediately started getting "flaky memory" symptoms like >> multiple internal compiler errors during compilation of non-trivially sized >> projects (world, libreoffice). >> I re-run memory tests which again revealed nothing and then started playing with >> various VM subsystem and memory related knobs in FreeBSD. I recalled that a >> long while ago there were some problems with 1GB pages and so their use used to >> be disabled. On a hunch I disabled 1GB pages again: >> @@ -471,7 +471,7 @@ create_pagetables(vm_paddr_t *firstaddr) >> ndmpdp = 4; >> DMPDPphys = allocpages(firstaddr, NDMPML4E); >> ndm1g = 0; >> - if ((amd_feature& AMDID_PAGE1GB) != 0) >> + if (0&& (amd_feature& AMDID_PAGE1GB) != 0) >> ndm1g = ptoa(Maxmem)>> PDPSHIFT; >> if (ndm1g< ndmpdp) >> DMPDphys = allocpages(firstaddr, ndmpdp - ndm1g); >> >> And the flakiness went away. >> >> Not sure what kind of useful information I should provide with this report. >> Here's couple of things that I think could be of use. >> >> - memcontrol list output >> http://people.freebsd.org/~avg/8gb%2b512mb.memcontrol.list.txt >> >> - BIOS memory map >> SMAP type=01 base=0000000000000000 end=000000000009f800 len=000000000009f800 >> SMAP type=02 base=00000000000f0000 end=0000000000100000 len=0000000000010000 >> SMAP type=02 base=00000000fec00000 end=0000000100000000 len=0000000001400000 >> SMAP type=02 base=00000000e0000000 end=00000000f0000000 len=0000000010000000 >> SMAP type=02 base=000000000009f800 end=00000000000a0000 len=0000000000000800 >> SMAP type=02 base=00000000afdf0000 end=00000000afe00000 len=0000000000010000 >> SMAP type=01 base=0000000000100000 end=00000000afde0000 len=00000000afce0000 >> SMAP type=03 base=00000000afde3000 end=00000000afdf0000 len=000000000000d000 >> SMAP type=04 base=00000000afde0000 end=00000000afde3000 len=0000000000003000 >> SMAP type=01 base=0000000100000000 end=0000000230000000 len=0000000130000000 >> >> - dmesg snippet >> CPU: AMD Athlon(tm) II X2 250 Processor (3013.78-MHz K8-class CPU) >> Origin = "AuthenticAMD" Id = 0x100f62 Family = 10 Model = 6 Stepping = 2 >> >> Features=0x178bfbff >> Features2=0x802009 >> AMD Features=0xee500800 >> AMD >> Features2=0x37ff >> TSC: P-state invariant >> real memory = 8589934592 (8192 MB) >> avail memory = 7617662976 (7264 MB) >> >> - Top Of Memory MSR >> MSR 0xc001001a: 0x00000000 0xd0000000 >> >> - Top Of Memory 2 MSR >> MSR 0xc001001d: 0x00000002 0x30000000 >> >> - System configuration MSR >> MSR 0xc0010010: 0x00000000 0x00760600 >> >> Please let me know if you have any ideas or requests for additional information >> or testing. >> Thank you. > From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 17:08:15 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8960E106566B; Mon, 14 Nov 2011 17:08:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9CE678FC12; Mon, 14 Nov 2011 17:08:14 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA08432; Mon, 14 Nov 2011 19:08:01 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EC14AF1.60907@FreeBSD.org> Date: Mon, 14 Nov 2011 19:08:01 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Alan Cox References: <4EBE4ECC.4060007@FreeBSD.org> <4EC0DD1D.9050704@FreeBSD.org> <4EC1497B.20409@rice.edu> In-Reply-To: <4EC1497B.20409@rice.edu> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Alan Cox , FreeBSD current Subject: Re: problem with 1GB pages? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 17:08:15 -0000 on 14/11/2011 19:01 Alan Cox said the following: > On 11/14/2011 03:19, Andriy Gapon wrote: >> Please disregard my report. >> I've tracked the problem to one of the new modules being faulty. But memtest86* >> tools still don't detect any issues with it. Apparently FreeBSD is a much more >> thorough memory tester than the specialized tools :-) >> Apologies for the noise. > > Interesting, nonetheless. I would have never guessed that disabling 1 GB pages > would mask a problem due to faulty memory. Apologies for withholding the information - the problems actually reappeared even with 1GB pages disable, but for some reason or purely by chance it just took longer than usual. It's then that I started torture tests (libreoffice builds) on individual modules. >> on 12/11/2011 12:47 Andriy Gapon said the following: >>> Introduction. >>> I have an AMD-based system with a Fam10h CPU (with 1GB pages support), the >>> system chipset contains an integrated graphics device (that uses a region of the >>> main memory as a graphics memory). The chipset supports memory hoisting to >>> compensate for the PCI memory window and the graphics aperture both of which are >>> located below 4GB. >>> The latest OS version installed on this system is 9-CURRENT from the middle of >>> September (r225560), architecture is amd64. >>> Until recently the system had 4GB of RAM installed and I had no problems with it >>> whatsoever. >>> >>> Recently though I have added another 4GB of RAM to the system. Before booting >>> to FreeBSD I tested the memory with multiple passes of memtest86 and >>> memetest86+, no errors were detected by those. >>> However with FreeBSD I immediately started getting "flaky memory" symptoms like >>> multiple internal compiler errors during compilation of non-trivially sized >>> projects (world, libreoffice). >>> I re-run memory tests which again revealed nothing and then started playing with >>> various VM subsystem and memory related knobs in FreeBSD. I recalled that a >>> long while ago there were some problems with 1GB pages and so their use used to >>> be disabled. On a hunch I disabled 1GB pages again: >>> @@ -471,7 +471,7 @@ create_pagetables(vm_paddr_t *firstaddr) >>> ndmpdp = 4; >>> DMPDPphys = allocpages(firstaddr, NDMPML4E); >>> ndm1g = 0; >>> - if ((amd_feature& AMDID_PAGE1GB) != 0) >>> + if (0&& (amd_feature& AMDID_PAGE1GB) != 0) >>> ndm1g = ptoa(Maxmem)>> PDPSHIFT; >>> if (ndm1g< ndmpdp) >>> DMPDphys = allocpages(firstaddr, ndmpdp - ndm1g); >>> >>> And the flakiness went away. >>> >>> Not sure what kind of useful information I should provide with this report. >>> Here's couple of things that I think could be of use. >>> >>> - memcontrol list output >>> http://people.freebsd.org/~avg/8gb%2b512mb.memcontrol.list.txt >>> >>> - BIOS memory map >>> SMAP type=01 base=0000000000000000 end=000000000009f800 len=000000000009f800 >>> SMAP type=02 base=00000000000f0000 end=0000000000100000 len=0000000000010000 >>> SMAP type=02 base=00000000fec00000 end=0000000100000000 len=0000000001400000 >>> SMAP type=02 base=00000000e0000000 end=00000000f0000000 len=0000000010000000 >>> SMAP type=02 base=000000000009f800 end=00000000000a0000 len=0000000000000800 >>> SMAP type=02 base=00000000afdf0000 end=00000000afe00000 len=0000000000010000 >>> SMAP type=01 base=0000000000100000 end=00000000afde0000 len=00000000afce0000 >>> SMAP type=03 base=00000000afde3000 end=00000000afdf0000 len=000000000000d000 >>> SMAP type=04 base=00000000afde0000 end=00000000afde3000 len=0000000000003000 >>> SMAP type=01 base=0000000100000000 end=0000000230000000 len=0000000130000000 >>> >>> - dmesg snippet >>> CPU: AMD Athlon(tm) II X2 250 Processor (3013.78-MHz K8-class CPU) >>> Origin = "AuthenticAMD" Id = 0x100f62 Family = 10 Model = 6 Stepping = 2 >>> >>> Features=0x178bfbff >>> >>> Features2=0x802009 >>> AMD Features=0xee500800 >>> AMD >>> Features2=0x37ff >>> >>> TSC: P-state invariant >>> real memory = 8589934592 (8192 MB) >>> avail memory = 7617662976 (7264 MB) >>> >>> - Top Of Memory MSR >>> MSR 0xc001001a: 0x00000000 0xd0000000 >>> >>> - Top Of Memory 2 MSR >>> MSR 0xc001001d: 0x00000002 0x30000000 >>> >>> - System configuration MSR >>> MSR 0xc0010010: 0x00000000 0x00760600 >>> >>> Please let me know if you have any ideas or requests for additional information >>> or testing. >>> Thank you. >> > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 17:22:56 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE3C2106566B; Mon, 14 Nov 2011 17:22:55 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E1D0A8FC0A; Mon, 14 Nov 2011 17:22:54 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA08690; Mon, 14 Nov 2011 19:22:52 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EC14E63.2090506@FreeBSD.org> Date: Mon, 14 Nov 2011 19:22:43 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kostik Belousov References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <4EC0E838.50609@FreeBSD.org> <20111114130857.GC50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111114130857.GC50300@deviant.kiev.zoral.com.ua> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5D8E014BB4D54A54E4F13B1A" Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 17:22:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5D8E014BB4D54A54E4F13B1A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable on 14/11/2011 15:08 Kostik Belousov said the following: > On Mon, Nov 14, 2011 at 12:06:48PM +0200, Andriy Gapon wrote: >> On a more serious note: >> - some code in my latest version of the patch was contributed by or wa= s based >> on the code or ideas contributed by jhb and mdf (so that attributions = are not >> lost) Oops, forgot the most recent and quite big contribution from Attilio. > Please provide me with proper attribution for contributors and testers.= My memory has faded a bit, so let's make it simple. In cooperation with: attilio, avg, jhb, kib, mdf Tested by: avg, Eugene Grosbein , gnn, Steven Hartland , glebius, kib [strike out obvious/unnecessary] >> - there was a concern about how sync-on-panic would work >> >> About the latter, I have never really tested it. mdf has suggested to >> move the sync-on-panic code to a place after we ensure that there is >> only one CPU in panic(), but before we stop other CPUs. > sync_on_panic is incompatible with the patch. I argue that it provides > non-zero chance of damaging good filesystems even if panic was unrelate= d > to the fs/bio/device layer. As an example, consider the case when other= > CPU was modifying in-memory representation of the metadata, and panic > happen on this CPU. If you write half-changed block back, you make more= > damage to the filesystem then if you do not. The half-backed sync spoil= s > any journaling or SU consistency guarantees. Not sure how this is different from what we have right now (without the p= atch). Perhaps I misunderstand what you say, but, just in case, the proposal was= to do sync-on-panic before stopping other CPUs. > The issues of multithreading nature of our storage subsystem are second= ary. >=20 > The user who sets either tunable shall know what he does. That has always been the case. and apparently there are people who still want this option to exist. >> I think that I've already sent you a list of the early testers for >> various WIP versions of the patch. > I do not have the list. Included above. > BTW, if you want, feel free to handle the commit youself. You definitel= y > spent much more efforts on the stuff and deserve the credit. >=20 > I was promised in private that a review will be provided during this > weekend. Unfortunately too little time and spare mind capacity to do the commit no= w. I do not care much about the credit (or commit-o-meter) as long as we get= functionality in. It was/is a collective effort in any case. Besides I won't be able to handle any potential regression reports in a sufficiently speedy manner. --=20 Andriy Gapon --------------enig5D8E014BB4D54A54E4F13B1A 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.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOwU5sAAoJEHSlLSemUf4vt/gIAK3ErPHwuIpwBFvSjvgP0OQF clr4Ox7yl8MfvXej43nqRnj00ySRpqpFT+kAbruKlnkiPJoIeD4DOJr1eMSi1/CD lt8J5guUPIon/or5V/e703jnv/KTaR63d2ihHZg9y1GVWww2iFZTamg4M46aGtF5 Y83J1tBWOROEy9MaFHGtyBSaQBgAMIpMLnY+L1ueXerzAaCfXVlXT4osEt95fJRg hPhfgfWK6CDwswwo01aom0x7bVl+xA5rXDUFpDVD8LDcGjpYVAstH181Uh4sO69w 61wQTaC7G9b+1jOx8eALK8k1ssBFamwaJ/pcmsBbXrvBUJCFgdb8wzwX0ZlZGb0= =o+eV -----END PGP SIGNATURE----- --------------enig5D8E014BB4D54A54E4F13B1A-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 18:21:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAEA2106566C for ; Mon, 14 Nov 2011 18:21:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 2EE768FC16 for ; Mon, 14 Nov 2011 18:21:07 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAD9bwU6DaFvO/2dsb2JhbABChQCmBIFyAQEEASMEUhsQCBEZAgRVBhOIAqYfkX+IaYEWBIgQjB6IfogPgQo X-IronPort-AV: E=Sophos;i="4.69,510,1315195200"; d="scan'208";a="143916591" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 14 Nov 2011 13:21:07 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 16346B3F08; Mon, 14 Nov 2011 13:21:07 -0500 (EST) Date: Mon, 14 Nov 2011 13:21:07 -0500 (EST) From: Rick Macklem To: Dan The Man Message-ID: <2051062775.1747384.1321294867077.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1747383_1573894577.1321294867074" X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: NFSV4 readlink_stat X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 18:21:08 -0000 ------=_Part_1747383_1573894577.1321294867074 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dan The Man wrote: > Just want to include some errors from rsync trying to copy files using > NFSV4. These files copy fine using NFSV3.... > > > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/A-E/A/Ace of > Base/The Bridge/Ace of Base-My D\#351j\#340 Vu-09-The Bridge.wma") > failed: > Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/A-E/B/Bj\#366rn > Skifs") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass > Tunes/A-E/B/Bjork/Bj\#366rk - Dancer in the Dark - My Favorite > Things.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass > Tunes/A-E/B/Bjork/Bj\#366rk - Amphibian.mp3") failed: Invalid argument > (22) > IO error encountered -- skipping file deletion > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/A-E/C/Celine > Dion/C\#351line Dion - I Drove All Night (Album Version).mp3") failed: > Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/A-E/E/The > Eagles/The > Eagles Greatest Hits, Vol. 2/05 The Sad Caf\#351.wma") failed: Invalid > argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/G/Georges > Delerue/Georges Delerue - Le M\#351pris, Camille - Jean-Luc > Godard.mp3") > failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/O\#264 Riada Sa Gaiety") failed: Invalid > argument > (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Athen Rye/Athenrye - Amhr\#341n Na > Bhfiann.mp3") > failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Chieftans/Chieftains & Sin\#351ad O'Connor - > Factory girl.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Chieftans/The Chieftains & Sin\#351ad O'Connor > - > The Foggy Dew.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Christy Moore/Christy Moore - Compa\#361eros - > 06.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Clancy Brothers/Clancy Brothers & Tommy Makem > - 12 > - Cru\#354sc\#354n L\#340n.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Loreena McKennitt/Loreena McKennitt - The Mask > and > Mirror - 07. C\#351 H\#351 Mise Le Ulaingt - The Two Trees.mp3") > failed: > Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Planxty/Planxty - Raggletaggle Gypsy; Tabhair > Dom > Do L\#343mh - 01.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Planxty/Planxty - The Rambling Si\#372ler - > 05.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Quilty/Quilty - Mist Covered Mountain > Siobh\#341n > O\#264donnels - Jig Reel.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Quilty/Quilty - I\#264m Here Because I\#264m > Here.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Seamus Kennedy/Seamus Kennedy - Or\#363! > S\#351 Do > Bheatha 'Bhaile & The Rights Of Man (Instrumental).mp3") failed: > Invalid > argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Seamus Kennedy/Seamus Kennedy - The > Bodhr\#341n > (Comedy).mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Sinead O'Connor/Sinead O'Connor - The Black > Album > ( 8 CD Set )/Cd 2/06_Mna Na H\#351ireann.mp3") failed: Invalid > argument > (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Sinead O'Connor/Sinead O'Connor - The Black > Album > ( 8 CD Set )/Cd 3/07_Rois\#355n Dubh.mp3") failed: Invalid argument > (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/Wolfe Tones/2006 As Gaeilge/Wolfe Tones - > T\#341 > Na L\#341.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/aaa - Too Few, but Identified/Irish C\#351ili > Band > - The Black Velvet Band.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/aaa - Too Few, but Identified/Young Dubliners > - > The Bodhr\#341n.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/aaa - Too Few, but Identified/Jeff Johnson & > Brian > Dunning - C\#371Chulainn's Last Battle.mp3") failed: Invalid argument > (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/aaa - Too Few, but Identified/Phil Coulter & > Sin\#351ad O'Connor - The Shores Of The Swilly.mp3") failed: Invalid > argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/aaa - Too Few, but Identified/M\#341ire > Brennan - > Eirigh Suas A Stoirin.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/aaa - Too Few, but Identified/Sin\#351ad > O-connor > - Factory Girl.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/history of ireland in song/53.Amhr\#341n na > Bhfiann.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/history of ireland in song/46.Se\#341n South > from > Garryowen.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/history of ireland in song/32.Se\#341n > Treacy.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/history of ireland in song/02.Rois\#355n > Dubh.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/history of ireland in song/03.Se\#341n \#323 > Duibhir A'Ghleanna.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/F-J/I/Irish > Scottish > Celtic Music Collection/history of ireland in song/03.Se\#341n \#323 > Duibhir A'Ghleanna (O'Dwyer of the Glen).mp3") failed: Invalid > argument > (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/K-O/M/M\#366tley > Cr\#374e") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Sort Me > Music/New > Folder(20)/Ivan Rebroff - Moskauer n\#344chte (rus).mp3") failed: > Invalid > argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Bj\#366rn Skifs - H\#344rligt, > h\#344rligt > men farligt, farligt.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Bj\#366rk - Visur Vatnsenda Rosu.mp3") > failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/All Crap Tunes/F-L/La Mafia/Un Millon > de > Rosas/La Mafia-Yo Te Amar\#351-01-Un Millon de Rosas.wma") failed: > Invalid > argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/All Crap Tunes/F-L/La Mafia/Un Millon > de > Rosas/La Mafia-Qui\#351n-04-Un Millon de Rosas.wma") failed: Invalid > argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/All Crap Tunes/F-L/La Mafia/Un Millon > de > Rosas/La Mafia-C\#363mo Pude Estar Tan Ciego-10-Un Millon de > Rosas.wma") > failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/All Crap Tunes/M-P/Moxy Fruvous/Moxy > Fr\#374vous - Spiderman.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/All Crap Tunes/Old > School/Santana/Supernatural/Corazon Espinado Man\#341; Santana > Supernatural 09.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Dance/Bran Van 3000/Discosis/16 Love > Clich\#351.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Dance/Bran Van 3000/Discosis/03 > Montr\#351al.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley > Cr\#374e - Generation Swine.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley > Cr\#374e - Driftaway.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley > Cr\#374e - Uncle Jack.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley > Cr\#374e - Get It For Free.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley > Cr\#374e - I Wanna Be Sedated.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley > Cr\#374e - Live Wire [Kick Ass '91 Remix].wma") failed: Invalid > argument > (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley > Cr\#374e - Black Widow.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley > Cr\#374e - Rock 'N' Roll Junkie.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely > Crue/Motley\#240Crue - > Loveshine.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley > Cr\#374e - Dragstrip Superstar.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley > Cr\#374e - Hammered - 07.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley > Cr\#374e - Poison Apples.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley > Cr\#374e - Afraid.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley > Cr\#374e - Kiss the Sky.wma") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Heavy Metal/Motely Crue/M\#366tley > Cr\#374e - Glitter - Generation Swine - 07.wma") failed: Invalid > argument > (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Original Soundtrack/Various > Artists/Various Artists/Pure Dance 1998/U2 Discoth\#350que [DM Radio > Mix] > 07 Pure Dance 1998 Rock.mp3") failed: Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Original Soundtrack/Various > Artists/Various Artists/Pure Dance 1998/Tony! Toni! Ton\#351! Let's > Get > Down [Fitch Bros. Club Radio Edit] 06 Pure Dance 1998 Rock.mp3") > failed: > Invalid argument (22) > rsync: readlink_stat("/asterisk/public/mp3/Kass Tunes/Z Too Small to > Seperate/Z Favorite WMA - Songs/Rock n > Roll/Q-S/Q/Queensryche/Queensr\#377che - Best I Can - 01.wma") failed: > Invalid argument (22) > Well, the most obvious reason for EINVAL being returned for a Readlink reply is that the server doesn't think the vnode type is VLNK. Two things you could do: 1 - Try the attached patch for the client. It doesn't really fix the problem, but it takes out the Getattr that preceeds the Readlink for the NFSv4 RPC. If it is this Getattr that is failing, it could make the problem "disappear". 2 - Look at a packet trace in wireshark and see if the reply to Readlink is returning EINVAL. (That will isolate the problem to the server vs client.) I don't mind looking at a packet trace, but it would be nice if you could get a fairly small one. (Can you reproduce it with a small rsync?) If you do either of the above, please let me know how it goes, rick > > > Dan. > > > > -- > Dan The Man > CTO/ Senior System Administrator > Websites, Domains and Everything else > http://www.SunSaturn.com > Email: Dan@SunSaturn.com > ------=_Part_1747383_1573894577.1321294867074 Content-Type: text/x-patch; name=readlink.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=readlink.patch LS0tIGZzL25mc2NsaWVudC9uZnNfY2xjb21zdWJzLmMuc2F2CTIwMTEtMDYtMTEgMTg6NTg6NTYu MDAwMDAwMDAwIC0wNDAwCisrKyBmcy9uZnNjbGllbnQvbmZzX2NsY29tc3Vicy5jCTIwMTEtMTEt MTQgMTI6MDc6MjMuMDAwMDAwMDAwIC0wNTAwCkBAIC02Miw3ICs2Miw3IEBAIHN0YXRpYyBzdHJ1 Y3QgewogCXsgTkZTVjRPUF9TRVRBVFRSLCAyLCAiU2V0YXR0ciIsIDcsIH0sCiAJeyBORlNWNE9Q X0xPT0tVUCwgMywgIkxvb2t1cCIsIDYsIH0sCiAJeyBORlNWNE9QX0FDQ0VTUywgMiwgIkFjY2Vz cyIsIDYsIH0sCi0JeyBORlNWNE9QX1JFQURMSU5LLCAyLCAiUmVhZGxpbmsiLCA4LCB9LAorCXsg TkZTVjRPUF9SRUFETElOSywgMSwgIlJlYWRsaW5rIiwgOCwgfSwKIAl7IE5GU1Y0T1BfUkVBRCwg MSwgIlJlYWQiLCA0LCB9LAogCXsgTkZTVjRPUF9XUklURSwgMiwgIldyaXRlIiwgNSwgfSwKIAl7 IE5GU1Y0T1BfT1BFTiwgMywgIk9wZW4iLCA0LCB9LAotLS0gZnMvbmZzY2xpZW50L25mc19jbHJw Y29wcy5jLnNhdgkyMDExLTExLTE0IDEyOjAzOjE4LjAwMDAwMDAwMCAtMDUwMAorKysgZnMvbmZz Y2xpZW50L25mc19jbHJwY29wcy5jCTIwMTEtMTEtMTQgMTI6MTk6MTYuMDAwMDAwMDAwIC0wNTAw CkBAIC0xMTY0LDExICsxMTY0LDE0IEBAIG5mc3JwY19yZWFkbGluayh2bm9kZV90IHZwLCBzdHJ1 Y3QgdWlvICoKIAl1X2ludDMyX3QgKnRsOwogCXN0cnVjdCBuZnNydl9kZXNjcmlwdCBuZnNkLCAq bmQgPSAmbmZzZDsKIAlzdHJ1Y3QgbmZzbm9kZSAqbnAgPSBWVE9ORlModnApOworI2lmZGVmIG5v dG5vdwogCW5mc2F0dHJiaXRfdCBhdHRyYml0czsKLQlpbnQgZXJyb3IsIGxlbiwgY2FuZ2V0YXR0 ciA9IDE7CisjZW5kaWYKKwlpbnQgZXJyb3IsIGxlbiwgY2FuZ2V0YXR0ciA9IDA7CiAKIAkqYXR0 cmZsYWdwID0gMDsKIAlORlNDTF9SRVFTVEFSVChuZCwgTkZTUFJPQ19SRUFETElOSywgdnApOwor I2lmZGVmIG5vdG5vdwogCWlmIChuZC0+bmRfZmxhZyAmIE5EX05GU1Y0KSB7CiAJCS8qCiAJCSAq IEFuZCBkbyBhIEdldGF0dHIgb3AuCkBAIC0xMTc4LDYgKzExODEsNyBAQCBuZnNycGNfcmVhZGxp bmsodm5vZGVfdCB2cCwgc3RydWN0IHVpbyAqCiAJCU5GU0dFVEFUVFJfQVRUUkJJVCgmYXR0cmJp dHMpOwogCQkodm9pZCkgbmZzcnZfcHV0YXR0cmJpdChuZCwgJmF0dHJiaXRzKTsKIAl9CisjZW5k aWYKIAllcnJvciA9IG5mc2NsX3JlcXVlc3QobmQsIHZwLCBwLCBjcmVkLCBzdHVmZik7CiAJaWYg KGVycm9yKQogCQlyZXR1cm4gKGVycm9yKTsK ------=_Part_1747383_1573894577.1321294867074-- From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 19:27:24 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 844EA106566B; Mon, 14 Nov 2011 19:27:24 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 056038FC0A; Mon, 14 Nov 2011 19:27:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.5/8.14.5) with ESMTP id pAEJRMGd020692; Mon, 14 Nov 2011 23:27:22 +0400 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.5/8.14.5/Submit) id pAEJRLTN020691; Mon, 14 Nov 2011 23:27:21 +0400 (MSK) (envelope-from ache) Date: Mon, 14 Nov 2011 23:27:21 +0400 From: Andrey Chernov To: das@freebsd.org, current@freebsd.org, secteam@freebsd.org Message-ID: <20111114192721.GA16834@vniz.net> Mail-Followup-To: Andrey Chernov , das@freebsd.org, current@freebsd.org, secteam@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> <20111112102241.GA75396@vniz.net> <20111112154135.GA21512@zim.MIT.EDU> <20111112171531.GA83419@vniz.net> <20111114013004.GA53392@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111114013004.GA53392@zim.MIT.EDU> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 19:27:24 -0000 On Sun, Nov 13, 2011 at 08:30:04PM -0500, David Schultz wrote: > I don't have those patches anymore, but I redid them from scratch > using the latest revision from OpenBSD. The patch at > http://www.freebsd.org/~das/patches/vshead.diff syncs our > arc4random.c with OpenBSD's to the extent possible, style bugs and > all. It seems prudent to treat it as a vendor source and avoid > gratuitous differences: Unlike our version, all the changes to > OpenBSD's arc4random.c were vetted by several people. Switching > to OpenBSD's version fixes the bug where a parent and child > process see the same random sequence. 1) We should use mib[0] = CTL_KERN; mib[1] = KERN_ARND; len = sizeof(rnd); sysctl(mib, 2, rnd, &len, NULL, 0); here instead of /dev/random, like OpenBSD did. It helps jails, and re-stearing not happens too often in anycase. Obviously it minimizes OpenBSD diffs too. > the IV. In arc4_stir(), I also fixed the bug where the wrong > buffer size was being passed to arc4_addrandom(), resulting in > entropy loss. That change should be committed separately. 2) I already explain this moment before. There is no bug here but intentional hack using time and pid entropy for stearing when read is fail: time/pid are at the beginning of the struct, successful read happens at the beginning of the struct too and beginning of the struct is passed as the key too. Key is always fixed KEYSIZE bytes. In your new patch you pass unneded stack garbadge at the beginning of the struct (often 0-s) in case good entropy is successfully readed into rdat.rnd, moreover, you pass more then KEYSIZE bytes - sizeof(rdat). When using KERN_ARND as in 1) this whole part becomes irrelevant. 3) (optional) I think we can lover initial permutations from our 1024 to at least OpenBSD's 256 here: for (i = 0; i < 1024; i++) (void)arc4_getbyte(); In my initial commit attemps I post several references to publicly available mathematical researches calculating estimated initial permutation count, some paper allows even 128. They can be found in the commit log. In all other moments your patch looks good for me. -- http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 20:58:56 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B168F1065676; Mon, 14 Nov 2011 20:58:56 +0000 (UTC) (envelope-from das@freebsd.org) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 707228FC1A; Mon, 14 Nov 2011 20:58:56 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id pAEKwtuX059140; Mon, 14 Nov 2011 15:58:55 -0500 (EST) (envelope-from das@freebsd.org) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id pAEKwtTO059139; Mon, 14 Nov 2011 15:58:55 -0500 (EST) (envelope-from das@freebsd.org) Date: Mon, 14 Nov 2011 15:58:55 -0500 From: David Schultz To: Andrey Chernov , current@freebsd.org, secteam@freebsd.org Message-ID: <20111114205855.GB58790@zim.MIT.EDU> Mail-Followup-To: Andrey Chernov , current@freebsd.org, secteam@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> <20111112102241.GA75396@vniz.net> <20111112154135.GA21512@zim.MIT.EDU> <20111112171531.GA83419@vniz.net> <20111114013004.GA53392@zim.MIT.EDU> <20111114192721.GA16834@vniz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111114192721.GA16834@vniz.net> Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 20:58:56 -0000 On Mon, Nov 14, 2011, Andrey Chernov wrote: > 1) We should use > mib[0] = CTL_KERN; > mib[1] = KERN_ARND; > > len = sizeof(rnd); > sysctl(mib, 2, rnd, &len, NULL, 0); > here instead of /dev/random, like OpenBSD did. It helps jails, and > re-stearing not happens too often in anycase. Obviously it minimizes > OpenBSD diffs too. Yes, that was in my list of suggested follow-on work, but I don't have time for it right now. > > the IV. In arc4_stir(), I also fixed the bug where the wrong > > buffer size was being passed to arc4_addrandom(), resulting in > > entropy loss. That change should be committed separately. > > 2) I already explain this moment before. There is no bug here but > intentional hack using time and pid entropy for stearing when read is > fail: time/pid are at the beginning of the struct, successful read happens > at the beginning of the struct too and beginning of the struct is passed > as the key too. Key is always fixed KEYSIZE bytes. > > In your new patch you pass unneded stack garbadge at the beginning of the > struct (often 0-s) in case good entropy is successfully readed into > rdat.rnd, moreover, you pass more then KEYSIZE bytes - sizeof(rdat). No, the "unneeded stack garbage" was passed in before. The difference is that previously you were calling arc4_addrandom() with a 148-byte struct rdat and a length parameter of 128 bytes. The result was that the last 20 bytes of the key obtained from /dev/random were unused. It's actually worrisome that you've got the predictable part of the key (pid and timestamp) first. The known-key attacks on RC4 that were used to break WEP rely on exactly this type of key. Specifically, because of the way the key scheduling algorithm works, the first few bytes of the state are strongly correlated with the first few bytes of the key. > 3) (optional) I think we can lover initial permutations from our 1024 to > at least OpenBSD's 256 here: > for (i = 0; i < 1024; i++) > (void)arc4_getbyte(); > In my initial commit attemps I post several references to publicly > available mathematical researches calculating estimated initial > permutation count, some paper allows even 128. They can be found in the > commit log. The revision history shows that you changed that parameter from 256 to 1024 to 512 to 768 to 1024 again. I'm not inclined to change it yet again unless an actual cryptographer weighs in and proscribes an appropriate level of paranoia. For what it's worth, I believe the attack you cited in the comments is unlikely to matter, assuming the initialization issue I mentioned above is fixed. arc4random() uses a larger-than-usual key size (1024 bits instead of the 64-128 used in most RC4 implementations). Thus, an attacker who can correlate the keystream with the first few bytes of the key gains negligible advantage, assuming that the key itself is random. But I'm not sufficiently well versed in the RC4 key schedule to preach that as the gospel truth. From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 21:09:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D4C6106566C; Mon, 14 Nov 2011 21:09:59 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3EBC78FC08; Mon, 14 Nov 2011 21:09:59 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RQ3mv-0007OX-PX; Mon, 14 Nov 2011 16:09:57 -0500 Date: Mon, 14 Nov 2011 16:09:57 -0500 From: Gary Palmer To: Alexander Motin Message-ID: <20111114210957.GA68559@in-addr.com> References: <4EAF00A6.5060903@FreeBSD.org> <05E0E64F-5EC4-425A-81E4-B6C35320608B@neveragain.de> <4EB05566.3060700@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB05566.3060700@FreeBSD.org> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: FreeBSD-Current , Dennis K?gel , freebsd-geom@freebsd.org Subject: Re: RFC: GEOM MULTIPATH rewrite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 21:09:59 -0000 On Tue, Nov 01, 2011 at 10:24:06PM +0200, Alexander Motin wrote: > On 01.11.2011 19:50, Dennis K?gel wrote: > > Not sure if replying on-list or off-list makes more sense... > > Replying on-list could share experience to other users. > > > Anyway, some first impressions, on stable/9: > > > > The lab environment here is a EMC VNX / Clariion SAN, which has two Storage Processors, connected to different switches, connected to two isp(4)s on the test machine. So at any time, the machine sees four paths, but only two are available (depending on which SP owns the LUN). > > > > 580# camcontrol devlist > > at scbus0 target 0 lun 0 (da0,pass0) > > at scbus0 target 1 lun 0 (da1,pass1) > > at scbus1 target 0 lun 0 (da2,pass2) > > at scbus1 target 1 lun 0 (da3,pass3) > > at scbus2 target 0 lun 0 (da4,pass4) > > at scbus2 target 1 lun 0 (da5,pass5) > > at scbus4 target 0 lun 0 (cd0,pass6) > > > > I miss the ability to "add" disks to automatic mode multipaths, but I (just now) realized this only makes sense when gmultipath has some kind of path checking facility (like periodically trying to read sector 0 of each configured device, this is was Linux' devicemapper-multipathd does). > > In automatic mode other paths supposed to be detected via metadata > reading. If in your case some paths are not readable, automatic mode > can't work as expected. By the way, could you describe how your > configuration supposed to work, like when other paths will start > working? Without knowledge of the particular Clariion SAN Dennis is working with, I've seen some so-called active/active RAID controllers force a LUN fail over from one controller to another (taking it offline for 3 seconds in the process) because the LUN received an I/O down a path to the controller that was formerly taking the standby role for that LUN (and it was per-LUN, so some would be owned by one controller and some by the other). During the controller switch, all I/O to the LUN would fail. Thankfully that particular RAID model where I observed this behaviour hasn't been sold in several years, but I would tend to expect such behaviour at the lower end of the storage market with the higher end units doing true active/active configurations. (and no, I won't name the manufacturer on a public list) This is exactly why Linux ships with a multipath configuration file, so it can describe exactly what form of brain damage the controller in question implements so it can work around it, and maybe even document some vendor-specific extensions so that the host can detect which controller is taking which role for a particular path. Even some controllers that don't have pathological behaviour when they receive I/O down the wrong path have sub-optimal behaviour unless you choose the right path. NetApp SANs in particular typically have two independant controllers with a high-speed internal interconnect, however there is a measurable and not-insignificant penalty for sending the I/O to the "partner" controller for a LUN, across the internal interconnect (called a "VTIC" I believe) to the "owner" controller. I've been told, although I have not measured this myself, that it can add several ms to a transaction, which when talking about SAN storage is potentially several times what it takes to do the same I/O directly to the controller that owns it. There's probably a way to make the "partner" controller not advertise the LUN until it takes over in a failover scenario, but every NetApp I've worked with is set (by default I believe) to advertise the LUN out both controllers. Gary From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 21:29:29 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E00011065670; Mon, 14 Nov 2011 21:29:28 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 5C2778FC14; Mon, 14 Nov 2011 21:29:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.5/8.14.5) with ESMTP id pAELTQDv030283; Tue, 15 Nov 2011 01:29:26 +0400 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.5/8.14.5/Submit) id pAELTQGV030282; Tue, 15 Nov 2011 01:29:26 +0400 (MSK) (envelope-from ache) Date: Tue, 15 Nov 2011 01:29:26 +0400 From: Andrey Chernov To: das@freebsd.org, current@freebsd.org, secteam@freebsd.org Message-ID: <20111114212926.GA28783@vniz.net> Mail-Followup-To: Andrey Chernov , das@freebsd.org, current@freebsd.org, secteam@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> <20111112102241.GA75396@vniz.net> <20111112154135.GA21512@zim.MIT.EDU> <20111112171531.GA83419@vniz.net> <20111114013004.GA53392@zim.MIT.EDU> <20111114192721.GA16834@vniz.net> <20111114205855.GB58790@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111114205855.GB58790@zim.MIT.EDU> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 21:29:29 -0000 On Mon, Nov 14, 2011 at 03:58:55PM -0500, David Schultz wrote: > On Mon, Nov 14, 2011, Andrey Chernov wrote: > > 1) We should use > > mib[0] = CTL_KERN; > > mib[1] = KERN_ARND; > > > > len = sizeof(rnd); > > sysctl(mib, 2, rnd, &len, NULL, 0); > > here instead of /dev/random, like OpenBSD did. It helps jails, and > > re-stearing not happens too often in anycase. Obviously it minimizes > > OpenBSD diffs too. > > Yes, that was in my list of suggested follow-on work, but I don't > have time for it right now. I can add this to your patch, we have the same semantics here as OpenBSD, so there will be no surprizes. > > 2) I already explain this moment before. There is no bug here but > > intentional hack using time and pid entropy for stearing when read is > > fail: time/pid are at the beginning of the struct, successful read happens > > at the beginning of the struct too and beginning of the struct is passed > > as the key too. Key is always fixed KEYSIZE bytes. > > > > In your new patch you pass unneded stack garbadge at the beginning of the > > struct (often 0-s) in case good entropy is successfully readed into > > rdat.rnd, moreover, you pass more then KEYSIZE bytes - sizeof(rdat). > > No, the "unneeded stack garbage" was passed in before. The > difference is that previously you were calling arc4_addrandom() > with a 148-byte struct rdat and a length parameter of 128 bytes. > The result was that the last 20 bytes of the key obtained from > /dev/random were unused. Lets go: #define KEYSIZE 128 if (_read(fd, &rdat, KEYSIZE) == KEYSIZE) ... arc4_addrandom((u_char *)&rdat, KEYSIZE); All 128 bytes read to &rdat pointer are used. Where you found unused 20 bytes? _read() call here is aligned not to rnd[] member, but to the beginnig of the structure. rnd[] member used just as space filler, key start is not there. > It's actually worrisome that you've got the predictable part of > the key (pid and timestamp) first. Only if _read() fails (for jails f.e.). Alternative solution will be to return error, but this branch us out of OpenBSD semantics too far, programs will not expect it, ignoring errno, which makes security problem even worse. Right solution will be using KERN_ARND. BTW, this way isn't my invention, it was in the OpenBSD code before they start using KERN_ARND (when it was imported to FreeBSD) in much less secure way than now. It still present in NetBSD: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/gen/arc4random.c?rev=1.9.40.1&content-type=text/x-cvsweb-markup They use non-random timeval part even if they read good entropy. > The known-key attacks on RC4 > that were used to break WEP rely on exactly this type of key. > Specifically, because of the way the key scheduling algorithm > works, the first few bytes of the state are strongly correlated > with the first few bytes of the key. This is well-known. > > 3) (optional) I think we can lover initial permutations from our 1024 to > > at least OpenBSD's 256 here: > > for (i = 0; i < 1024; i++) > > (void)arc4_getbyte(); > > In my initial commit attemps I post several references to publicly > > available mathematical researches calculating estimated initial > > permutation count, some paper allows even 128. They can be found in the > > commit log. > > The revision history shows that you changed that parameter from > 256 to 1024 to 512 to 768 to 1024 again. I'm not inclined to > change it yet again unless an actual cryptographer weighs in and > proscribes an appropriate level of paranoia. As I say, this my suggestion is optional. -- http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 22:22:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ADBA106564A for ; Mon, 14 Nov 2011 22:22:25 +0000 (UTC) (envelope-from chmiels@o2.pl) Received: from moh2-ve1.go2.pl (moh2-ve1.go2.pl [193.17.41.186]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3068FC0C for ; Mon, 14 Nov 2011 22:22:25 +0000 (UTC) Received: from moh2-ve1.go2.pl (unknown [10.0.0.186]) by moh2-ve1.go2.pl (Postfix) with ESMTP id 6F9AE44E356 for ; Mon, 14 Nov 2011 23:22:22 +0100 (CET) Received: from unknown (unknown [10.0.0.108]) by moh2-ve1.go2.pl (Postfix) with SMTP for ; Mon, 14 Nov 2011 23:22:22 +0100 (CET) Received: from staticline55990.toya.net.pl [77.237.11.229] by poczta.o2.pl with ESMTP id pWfjlQ; Mon, 14 Nov 2011 23:25:01 +0100 Date: Mon, 14 Nov 2011 23:22:31 +0100 From: Sebastian Chmielewski To: freebsd-current@freebsd.org Message-ID: <20111114232231.7e02b408@o2.pl> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-O2-Trust: 2, 63 X-O2-SPF: neutral Subject: Second SATA device lost after ZFS root is mount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 22:22:25 -0000 hi, I have laptop with two hard disks - SSD and HDD attached instead of optical drive, running 9.0-PRERELEASE, GENERIC and custom configured kernel (same symptoms for both). Second HDD is lost during boot (root is on ada0, ada0 and ada1 are partitioned using GPT): ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada1: Command Queueing enabled ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 .... Trying to mount root from zfs:zroot []... (ada1:ahcich1:0:0:0): lost device (ada1:ahcich1:0:0:0): removing device entry cryptosoft0: on motherboard GEOM_ELI: Device gpt/home0.eli created. loader.conf contains only few modules: # Kernel Options kern.ipc.shmseg=1024 kern.ipc.shmmni=1024 kern.maxproc=10000 # Required by Firefox sem_load="YES" # ACPI drivers acpi_load="YES" acpi_video_load="YES" acpi_ibm_load="YES" acpi_dock_load="YES" # Linuxulator linux_load="YES" # Linux specific pseudo-devices lindev_load="YES" # Bluetooth driver ng_ubt_load="YES" # Realtek driver if_re_load="YES" legal.intel_iwn.license_ack=1 # Virtualbox driver (kmod) vboxdrv_load="YES" # ZFS driver and settings zfs_load="YES" # open files kern.maxfiles=49312 kern.maxfilesperproc=16384 # ZFS Root file system vfs.root.mountfrom="zfs:zroot" The same symptoms are for original DVD Drive - it is lost during the boot when ZFS root is successfully mount and before GELI asks for password. What is most strange it doesn't occur when boot into single user mode. What can be the cause? -- Sebastian Chmielewski * jid:chmielsster@gmail.com * gg:3336919 * icq:224161389 -- Sebastian Chmielewski * jid:chmielsster@gmail.com * gg:3336919 * icq:224161389 From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 22:35:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11111106564A for ; Mon, 14 Nov 2011 22:35:32 +0000 (UTC) (envelope-from chmiels@o2.pl) Received: from moh2-ve2.go2.pl (moh2-ve2.go2.pl [193.17.41.200]) by mx1.freebsd.org (Postfix) with ESMTP id C3FF98FC08 for ; Mon, 14 Nov 2011 22:35:31 +0000 (UTC) Received: from moh2-ve2.go2.pl (unknown [10.0.0.200]) by moh2-ve2.go2.pl (Postfix) with ESMTP id CAC95DA4005 for ; Mon, 14 Nov 2011 23:35:30 +0100 (CET) Received: from unknown (unknown [10.0.0.108]) by moh2-ve2.go2.pl (Postfix) with SMTP for ; Mon, 14 Nov 2011 23:35:30 +0100 (CET) Received: from staticline55990.toya.net.pl [77.237.11.229] by poczta.o2.pl with ESMTP id UvlXCj; Mon, 14 Nov 2011 23:38:09 +0100 Date: Mon, 14 Nov 2011 23:35:41 +0100 From: Sebastian Chmielewski To: freebsd-current@freebsd.org Message-ID: <20111114233541.61483260@o2.pl> In-Reply-To: <20111114232231.7e02b408@o2.pl> References: <20111114232231.7e02b408@o2.pl> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-O2-Trust: 2, 63 X-O2-SPF: neutral Subject: Re: Second SATA device lost after ZFS root is mount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 22:35:32 -0000 On Mon, 14 Nov 2011 23:22:31 +0100 Sebastian Chmielewski wrote: For some reason some "DISCONNECT" happens, but documentation reveals nothing about it: Trying to mount root from zfs:zroot []... start_init: trying /sbin/init ahcich1: DISCONNECT requested ahcich1: AHCI reset... ahcich1: SATA connect timeout time=10000us status=00000000 ahcich1: AHCI reset: device not found (ada1:ahcich1:0:0:0): lost device (pass1:ahcich1:0:0:0): lost device (pass1:ahcich1:0:0:0): removing device entry (ada1:ahcich1:0:0:0): removing device entry crypto: cryptosoft0: on motherboard -- Sebastian Chmielewski * jid:chmielsster@gmail.com * gg:3336919 * icq:224161389 From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 22:39:54 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 782B8106566B for ; Mon, 14 Nov 2011 22:39:54 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id F02F18FC08 for ; Mon, 14 Nov 2011 22:39:53 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so8897881bkb.13 for ; Mon, 14 Nov 2011 14:39:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LGAaGNlTcUr6gereEUW0AVd9OVVhm7yXep6so5+DPhg=; b=H/nPdSBB3ZOyrt2/NJQb1Y5xWbF9FJ/ULOJjvI8yJov7nXBNkKNnp8teSBsUowfLQr sDcXI0NMz5HWoh5/J+wsUAlQjLzBZ3N94CMeJehs9YkHTHjojDmKG2VjYIhRhL+uUgcH HRVuSLfSGAEFKaJRAmVwQoguhLWXaXKbbg2oA= Received: by 10.204.38.16 with SMTP id z16mr21325175bkd.66.1321310392631; Mon, 14 Nov 2011 14:39:52 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id k26sm15245269fab.8.2011.11.14.14.39.51 (version=SSLv3 cipher=OTHER); Mon, 14 Nov 2011 14:39:51 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC198B8.1010901@FreeBSD.org> Date: Tue, 15 Nov 2011 00:39:52 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: Sebastian Chmielewski References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current Subject: Re: Second SATA device lost after ZFS root is mount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 22:39:54 -0000 On 15.11.2011 00:22, Sebastian Chmielewski wrote: > I have laptop with two hard disks - SSD and HDD attached instead of optical > drive, running 9.0-PRERELEASE, GENERIC and custom configured kernel (same symptoms for both). > Second HDD is lost during boot (root is on ada0, ada0 and ada1 are partitioned using GPT): > > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada1: ATA-8 SATA 2.x device > ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada1: Previously was known as ad6 > .... > Trying to mount root from zfs:zroot []... > (ada1:ahcich1:0:0:0): lost device > (ada1:ahcich1:0:0:0): removing device entry > cryptosoft0: on motherboard > GEOM_ELI: Device gpt/home0.eli created. > > The same symptoms are for original DVD Drive - it is lost during the boot > when ZFS root is successfully mount and before GELI asks for password. > What is most strange it doesn't occur when boot into single user mode. > What can be the cause? SATA device can be dropped because of error during reset/ probe/ initialization sequence or because controller reported disconnection. Verbose boot messages (boot -v from loader prompt) should give more information about what happened there. Show please full verbose dmesg. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 23:08:57 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 093351065670; Mon, 14 Nov 2011 23:08:57 +0000 (UTC) (envelope-from das@freebsd.org) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id C1B958FC0A; Mon, 14 Nov 2011 23:08:56 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id pAEN8tZe059746; Mon, 14 Nov 2011 18:08:55 -0500 (EST) (envelope-from das@freebsd.org) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id pAEN8t6h059745; Mon, 14 Nov 2011 18:08:55 -0500 (EST) (envelope-from das@freebsd.org) Date: Mon, 14 Nov 2011 18:08:55 -0500 From: David Schultz To: Andrey Chernov , current@freebsd.org, secteam@freebsd.org Message-ID: <20111114230855.GA59545@zim.MIT.EDU> Mail-Followup-To: Andrey Chernov , current@freebsd.org, secteam@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> <20111112102241.GA75396@vniz.net> <20111112154135.GA21512@zim.MIT.EDU> <20111112171531.GA83419@vniz.net> <20111114013004.GA53392@zim.MIT.EDU> <20111114192721.GA16834@vniz.net> <20111114205855.GB58790@zim.MIT.EDU> <20111114212926.GA28783@vniz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111114212926.GA28783@vniz.net> Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 23:08:57 -0000 On Tue, Nov 15, 2011, Andrey Chernov wrote: > On Mon, Nov 14, 2011 at 03:58:55PM -0500, David Schultz wrote: > > On Mon, Nov 14, 2011, Andrey Chernov wrote: > > > 1) We should use > > > mib[0] = CTL_KERN; > > > mib[1] = KERN_ARND; > > > > > > len = sizeof(rnd); > > > sysctl(mib, 2, rnd, &len, NULL, 0); > > > here instead of /dev/random, like OpenBSD did. It helps jails, and > > > re-stearing not happens too often in anycase. Obviously it minimizes > > > OpenBSD diffs too. > > > > Yes, that was in my list of suggested follow-on work, but I don't > > have time for it right now. > > I can add this to your patch, we have the same semantics here as OpenBSD, > so there will be no surprizes. Not quite. OpenBSD's implementation is more careful. I just noticed a funny thing about FreeBSD's KERN_ARND sysctl: If the random device isn't (or can't be) loaded, KERN_ARND silently decides to initialize itself with the output of random(). This means that whatever minuscule amount of entropy it might have picked up from the clock is reduced to a maximum of 31 bits. That's a fantastic way to provide a false sense of security... From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 23:17:42 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23057106567A for ; Mon, 14 Nov 2011 23:17:42 +0000 (UTC) (envelope-from gr@ubuntu64.secure-side.com) Received: from admin.secure-side.com (admin.secure-side.com [213.251.166.100]) by mx1.freebsd.org (Postfix) with SMTP id 98F6B8FC0A for ; Mon, 14 Nov 2011 23:17:41 +0000 (UTC) Received: (qmail 27563 invoked from network); 14 Nov 2011 22:51:04 -0000 Received: from localhost (HELO ubuntu64.secure-side.com) (@127.0.0.1) by qmail with SMTP; 14 Nov 2011 22:51:04 -0000 Received: from localhost (localhost [127.0.0.1]) by ubuntu64.secure-side.com (Postfix) with ESMTP id D1C20469E5; Mon, 14 Nov 2011 23:50:52 +0100 (CET) Received: from ubuntu64.secure-side.com ([127.0.0.1]) by localhost (ubuntu64.secure-side.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3J7PgkQRaTIZ; Mon, 14 Nov 2011 23:50:47 +0100 (CET) Received: from ubuntu64.secure-side.com (ubuntu64.secure-side.com [192.168.1.146]) by ubuntu64.secure-side.com (Postfix) with ESMTP id B652946859; Mon, 14 Nov 2011 23:50:47 +0100 (CET) Date: Mon, 14 Nov 2011 23:50:47 +0100 (CET) From: GR To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Message-ID: In-Reply-To: <40d293fd-1909-4ccd-a32d-750bdba58c21@ubuntu64> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Originating-IP: [82.231.148.242] X-Mailer: Zimbra 7.1.3_GA_3346 (ZimbraWebClient - GC15 ([unknown])/7.1.3_GA_3346) Cc: Subject: Something broken with libdnet? Or FreeBSD 9.0-RC1? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 23:17:42 -0000 Hello list, I was updating one of my Perl module (Net::Libdnet), and came accross a bug under FreeBSD 9.0-RC1 and libdnet. My setup is one interface configured with multiple aliases. See details at the end of the message. One host works ok (FreeBSD 8.2-RELEASE), and another fails to find correct IP information (FreeBSD 9.0-RC1). The main bug is that under 9.0-RC1, libdnet fails to find the correct inet address for the interface. It gets the first alias instead. I don't know if the bug comes from libdnet or 9.0-RC1, so I let knowledgeable people here to look at it (or not). For those who want to test, you can install libdnet from /usr/ports/net/libdnet. Host FreeBSD 8.2-RELEASE (ok): % ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=389b ether MAC_ADDR inet PUBLIC_IP4 netmask 0xffffff00 broadcast PUBLIC_IP4.255 inet6 LOCAL_IP6%re0 prefixlen 64 scopeid 0x1 inet 192.168.0.10 netmask 0xffffffff broadcast 192.168.0.10 [...many aliases...] inet6 PUBLIC_IP6::2 prefixlen 128 inet6 PUBLIC_IP6::3 prefixlen 128 inet6 PUBLIC_IP6::4 prefixlen 128 inet6 PUBLIC_IP6::5 prefixlen 128 inet6 PUBLIC_IP6::1 prefixlen 56 % dnet intf get re0 re0: flags=0x31 mtu 1500 inet PUBLIC_IP4/24 link MAC_ADDR alias fe80:1::21c:c0ff:feca:1178/64 alias 192.168.0.10 [...many aliases...] alias PUBLIC_IP6::2/0 alias PUBLIC_IP6::3/0 alias PUBLIC_IP6::4/0 alias PUBLIC_IP6::5/0 alias PUBLIC_IP6::1/0 Host FreeBSD 9.0-RC1 (not ok): % ifconfig re0 re0: flags=8943 metric 0 mtu 1500 options=389b ether MAC_ADDR inet 192.168.2.10 netmask 0xffffffff broadcast 192.168.2.10 [...many aliases...] inet 192.168.1.148 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active % dnet intf get re0 re0: flags=0x31 mtu 1500 inet 192.168.2.10 link MAC_ADDR alias 192.168.2.11 alias 192.168.2.12 alias 192.168.2.13 alias 192.168.2.14 alias 192.168.1.148 # Correct inet address -- ^ ___ ___ http://www.GomoR.org/ <-+ | / __ |__/ Senior Security Engineer | | \__/ | \ ---[ zsh$ alias psed='perl -pe ' ]--- | +--> Net::Frame <=> http://search.cpan.org/~gomor/ <---+ From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 23:25:37 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22693106564A for ; Mon, 14 Nov 2011 23:25:37 +0000 (UTC) (envelope-from chmiels@o2.pl) Received: from tur.go2.pl (tur.go2.pl [193.17.41.50]) by mx1.freebsd.org (Postfix) with ESMTP id A42048FC14 for ; Mon, 14 Nov 2011 23:25:36 +0000 (UTC) Received: from moh1-ve3.go2.pl (moh1-ve3.go2.pl [193.17.41.134]) by tur.go2.pl (Postfix) with ESMTP id 2017C231B17 for ; Tue, 15 Nov 2011 00:00:48 +0100 (CET) Received: from moh1-ve3.go2.pl (unknown [10.0.0.134]) by moh1-ve3.go2.pl (Postfix) with ESMTP id C2361664630 for ; Tue, 15 Nov 2011 00:00:44 +0100 (CET) Received: from unknown (unknown [10.0.0.42]) by moh1-ve3.go2.pl (Postfix) with SMTP for ; Tue, 15 Nov 2011 00:00:44 +0100 (CET) Received: from staticline55990.toya.net.pl [77.237.11.229] by poczta.o2.pl with ESMTP id GlUWlx; Tue, 15 Nov 2011 00:00:44 +0100 Date: Tue, 15 Nov 2011 00:00:55 +0100 From: Sebastian Chmielewski To: Alexander Motin Message-ID: <20111115000055.58b7a103@o2.pl> In-Reply-To: <4EC198B8.1010901@FreeBSD.org> References: <4EC198B8.1010901@FreeBSD.org> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-O2-Trust: 2, 65 X-O2-SPF: neutral Cc: current Subject: Re: Second SATA device lost after ZFS root is mount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 23:25:37 -0000 On Tue, 15 Nov 2011 00:39:52 +0200 Alexander Motin wrote: > SATA device can be dropped because of error during reset/ probe/ > initialization sequence or because controller reported disconnection. > Verbose boot messages (boot -v from loader prompt) should give more > information about what happened there. Show please full verbose dmesg. Using rc_debug="YES" in rc.conf I've found that my device is dropped during sysctl_start. With empty sysctl.conf my device is not lost. The contents of file seems quite innocent: # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. security.bsd.see_other_uids=1 # Enable/disable coredump kern.coredump=1 # Up the maxfiles to 4x default kern.maxfiles=49312 kern.ipc.shmmax=67108864 kern.ipc.shmall=32768 # Allow users to mount CD's vfs.usermount=1 vfs.hirunningspace=8388608 vfs.lorunningspace=1048576 kern.corefile="/var/coredumps/%U/%N.core" # Do not truncate command line arguments in ps(1) listing kern.ps_arg_cache_limit=10000 # Tune for desktop usage kern.sched.preempt_thresh=224 # Increase default setting - recommended for 2 GB of RAM kern.maxvnodes=400000 dev.acpi_ibm.0.lcd_brightness=6 dev.acpi_ibm.0.lcd_brightness=3 net.link.tap.user_open=1 net.link.tap.up_on_open=1 The device is lost even when sysctl is started with new file when booting finishes (I did service sysctl restart from X session). # sysctl debug.bootverbose=1 # service sysctl restart # dmesg ahcich1: DISCONNECT requested ahcich1: AHCI reset... ahcich1: SATA connect timeout time=10000us status=00000000 ahcich1: AHCI reset: device not found (ada1:ahcich1:0:0:0): lost device (pass1:ahcich1:0:0:0): lost device (pass1:ahcich1:0:0:0): removing device entry Crazy, isn't it? best regards, -- Sebastian Chmielewski * jid:chmielsster@gmail.com * gg:3336919 * icq:224161389 From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 23:43:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3494F1065672 for ; Mon, 14 Nov 2011 23:43:23 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD1A08FC15 for ; Mon, 14 Nov 2011 23:43:22 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so8967522bkb.13 for ; Mon, 14 Nov 2011 15:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2a4cGHB/Ui4PCoiJ68rS1F0KAswzO4lkZ92eWkK0J6c=; b=UBo2O3HyigM8/NA+PRmw30EcZohxoDmLVDdharO3VaoQNg7dx/zw4BncWwlmdsJSSA npK6DAso3/0xE30FYgT8kMTlReBN1G/uFAmd1w9XfTenZ7sXTbaByOdoq2AdpDnc6UKu /8nj0Sg6CDYC/y5uP/j8XLpdKKf+h24/BDuWU= Received: by 10.204.151.84 with SMTP id b20mr21480591bkw.22.1321314201335; Mon, 14 Nov 2011 15:43:21 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id k26sm15391731fab.8.2011.11.14.15.43.19 (version=SSLv3 cipher=OTHER); Mon, 14 Nov 2011 15:43:20 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC1A799.7050102@FreeBSD.org> Date: Tue, 15 Nov 2011 01:43:21 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: Sebastian Chmielewski References: <4EC198B8.1010901@FreeBSD.org> <20111115000055.58b7a103@o2.pl> In-Reply-To: <20111115000055.58b7a103@o2.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current Subject: Re: Second SATA device lost after ZFS root is mount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 23:43:23 -0000 On 15.11.2011 01:00, Sebastian Chmielewski wrote: > On Tue, 15 Nov 2011 00:39:52 +0200 > Alexander Motin wrote: > >> SATA device can be dropped because of error during reset/ probe/ >> initialization sequence or because controller reported disconnection. >> Verbose boot messages (boot -v from loader prompt) should give more >> information about what happened there. Show please full verbose dmesg. > Using rc_debug="YES" in rc.conf I've found that my device is dropped during > sysctl_start. With empty sysctl.conf my device is not lost. The contents of > file seems quite innocent: > > # Uncomment this to prevent users from seeing information about processes that > # are being run under another UID. > security.bsd.see_other_uids=1 > > # Enable/disable coredump > kern.coredump=1 > > # Up the maxfiles to 4x default > kern.maxfiles=49312 > > kern.ipc.shmmax=67108864 > kern.ipc.shmall=32768 > > # Allow users to mount CD's > vfs.usermount=1 > vfs.hirunningspace=8388608 > vfs.lorunningspace=1048576 > > kern.corefile="/var/coredumps/%U/%N.core" > > # Do not truncate command line arguments in ps(1) listing > kern.ps_arg_cache_limit=10000 > > # Tune for desktop usage > kern.sched.preempt_thresh=224 > > # Increase default setting - recommended for 2 GB of RAM > kern.maxvnodes=400000 > > dev.acpi_ibm.0.lcd_brightness=6 > dev.acpi_ibm.0.lcd_brightness=3 > net.link.tap.user_open=1 > net.link.tap.up_on_open=1 > > The device is lost even when sysctl is started with new file when booting finishes (I did service sysctl restart from X session). > # sysctl debug.bootverbose=1 > # service sysctl restart > # dmesg > > ahcich1: DISCONNECT requested > ahcich1: AHCI reset... > ahcich1: SATA connect timeout time=10000us status=00000000 > ahcich1: AHCI reset: device not found > (ada1:ahcich1:0:0:0): lost device > (pass1:ahcich1:0:0:0): lost device > (pass1:ahcich1:0:0:0): removing device entry > > Crazy, isn't it? It is. I've never heard about such things. Reset status looks like if device was indeed disconnected or powered down. I don't even know how to do it this way, at least on Intel chipsets. My laptop's BIOS has bug that disables SATA port after suspend/resume, but there it can be seen in reset status that port was explicitly disabled. I have only one crazy idea: while setting screen brightness you are calling ACPI code that is black box by definition and can do whatever it wants with hardware, including using any possible custom power control interfaces. Was the second disk initially planned in this laptop? Laptop vendors more then desktop ones tend to hardcode things. I would try two things: - bisecting list of sysctls found one that cause this; - tried to enable SATA interface power management for the device. If power management was somehow enabled on the device around the OS, it may cause false DISCONNECT messages, while it still it should not cause such reset status. Setting hint.ahcich.1.pm_level=1 in loader.conf will make ahci(4) driver do ignore link loss events. If device indeed lost, you should see command timeouts and only then device loss. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 23:16:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F3B9106566B for ; Mon, 14 Nov 2011 23:16:26 +0000 (UTC) (envelope-from gr@ubuntu64.secure-side.com) Received: from admin.secure-side.com (admin.secure-side.com [213.251.166.100]) by mx1.freebsd.org (Postfix) with SMTP id 8BAB98FC17 for ; Mon, 14 Nov 2011 23:16:25 +0000 (UTC) Received: (qmail 26624 invoked from network); 14 Nov 2011 22:49:48 -0000 Received: from localhost (HELO ubuntu64.secure-side.com) (@127.0.0.1) by qmail with SMTP; 14 Nov 2011 22:49:48 -0000 Received: from localhost (localhost [127.0.0.1]) by ubuntu64.secure-side.com (Postfix) with ESMTP id C2165469E5; Mon, 14 Nov 2011 23:49:35 +0100 (CET) Received: from ubuntu64.secure-side.com ([127.0.0.1]) by localhost (ubuntu64.secure-side.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05vKXvcjZsiu; Mon, 14 Nov 2011 23:49:31 +0100 (CET) Received: from ubuntu64.secure-side.com (ubuntu64.secure-side.com [192.168.1.146]) by ubuntu64.secure-side.com (Postfix) with ESMTP id 150CB46859; Mon, 14 Nov 2011 23:49:31 +0100 (CET) Date: Mon, 14 Nov 2011 23:49:30 +0100 (CET) From: GomoR To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Message-ID: <40d293fd-1909-4ccd-a32d-750bdba58c21@ubuntu64> In-Reply-To: <4279f879-81b0-4e08-a2d7-63aad377d437@ubuntu64> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Originating-IP: [82.231.148.242] X-Mailer: Zimbra 7.1.3_GA_3346 (ZimbraWebClient - GC15 ([unknown])/7.1.3_GA_3346) X-Mailman-Approved-At: Tue, 15 Nov 2011 00:04:55 +0000 Cc: Subject: Something broken with libdnet? Or FreeBSD 9.0-RC1? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 23:16:26 -0000 Hello list, I was updating one of my Perl module (Net::Libdnet), and came accross a bug under FreeBSD 9.0-RC1 and libdnet. My setup is one interface configured with multiple aliases. See details at the end of the message. One host works ok (FreeBSD 8.2-RELEASE), and another fails to find correct IP information (FreeBSD 9.0-RC1). The main bug is that under 9.0-RC1, libdnet fails to find the correct inet address for the interface. It gets the first alias instead. I don't know if the bug comes from libdnet or 9.0-RC1, so I let knowledgeable people here to look at it (or not). For those who want to test, you can install libdnet from /usr/ports/net/libdnet. Host FreeBSD 8.2-RELEASE (ok): % ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=389b ether MAC_ADDR inet PUBLIC_IP4 netmask 0xffffff00 broadcast PUBLIC_IP4.255 inet6 LOCAL_IP6%re0 prefixlen 64 scopeid 0x1 inet 192.168.0.10 netmask 0xffffffff broadcast 192.168.0.10 [...many aliases...] inet6 PUBLIC_IP6::2 prefixlen 128 inet6 PUBLIC_IP6::3 prefixlen 128 inet6 PUBLIC_IP6::4 prefixlen 128 inet6 PUBLIC_IP6::5 prefixlen 128 inet6 PUBLIC_IP6::1 prefixlen 56 % dnet intf get re0 re0: flags=0x31 mtu 1500 inet PUBLIC_IP4/24 link MAC_ADDR alias fe80:1::21c:c0ff:feca:1178/64 alias 192.168.0.10 [...many aliases...] alias PUBLIC_IP6::2/0 alias PUBLIC_IP6::3/0 alias PUBLIC_IP6::4/0 alias PUBLIC_IP6::5/0 alias PUBLIC_IP6::1/0 Host FreeBSD 9.0-RC1 (not ok): % ifconfig re0 re0: flags=8943 metric 0 mtu 1500 options=389b ether MAC_ADDR inet 192.168.2.10 netmask 0xffffffff broadcast 192.168.2.10 [...many aliases...] inet 192.168.1.148 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active % dnet intf get re0 re0: flags=0x31 mtu 1500 inet 192.168.2.10 link MAC_ADDR alias 192.168.2.11 alias 192.168.2.12 alias 192.168.2.13 alias 192.168.2.14 alias 192.168.1.148 # Correct inet address -- ^ ___ ___ http://www.GomoR.org/ <-+ | / __ |__/ Senior Security Engineer | | \__/ | \ ---[ zsh$ alias psed='perl -pe ' ]--- | +--> Net::Frame <=> http://search.cpan.org/~gomor/ <---+ From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 00:44:46 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85FCB106564A; Tue, 15 Nov 2011 00:44:46 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id F131F8FC13; Tue, 15 Nov 2011 00:44:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.5/8.14.5) with ESMTP id pAF0iikT058594; Tue, 15 Nov 2011 04:44:44 +0400 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.5/8.14.5/Submit) id pAF0ihvQ058593; Tue, 15 Nov 2011 04:44:44 +0400 (MSK) (envelope-from ache) Date: Tue, 15 Nov 2011 04:44:43 +0400 From: Andrey Chernov To: das@freebsd.org, current@freebsd.org, secteam@freebsd.org Message-ID: <20111115004443.GA50429@vniz.net> Mail-Followup-To: Andrey Chernov , das@freebsd.org, current@freebsd.org, secteam@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> <20111112102241.GA75396@vniz.net> <20111112154135.GA21512@zim.MIT.EDU> <20111112171531.GA83419@vniz.net> <20111114013004.GA53392@zim.MIT.EDU> <20111114192721.GA16834@vniz.net> <20111114205855.GB58790@zim.MIT.EDU> <20111114212926.GA28783@vniz.net> <20111114230855.GA59545@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111114230855.GA59545@zim.MIT.EDU> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 00:44:46 -0000 On Mon, Nov 14, 2011 at 06:08:55PM -0500, David Schultz wrote: > Not quite. OpenBSD's implementation is more careful. I just > noticed a funny thing about FreeBSD's KERN_ARND sysctl: If the > random device isn't (or can't be) loaded, KERN_ARND silently > decides to initialize itself with the output of random(). This > means that whatever minuscule amount of entropy it might have > picked up from the clock is reduced to a maximum of 31 bits. > That's a fantastic way to provide a false sense of security... I agree. Lets separate two things: "no /dev/random for jails" and "no random kernel module is loaded". IMHO kernel module should _not_ be optional anymore, it solves problem you describe and all similar problems at once. Adding KERN_ARND to arc4random() at this moment solves "no /dev/random for jails" problem alone and _not_ pretends to solve "no random kernel module is loaded" problem. When random kernel module will become non-optional, KERN_ARND automagically makes good security in that place too. P.S. Do I answer your doubts about &rdat key initialization in my prev. posting? -- http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 01:11:06 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38DB6106564A for ; Tue, 15 Nov 2011 01:11:06 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id C05FE8FC12 for ; Tue, 15 Nov 2011 01:11:04 +0000 (UTC) Received: by eyd10 with SMTP id 10so6762724eyd.13 for ; Mon, 14 Nov 2011 17:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rkFbAbc9KbvJsh1KMM3BYL2M7NNmrlxdXPuvyRYGFHE=; b=C6pnYrCkmPMtZipt+97vHP8SXGQW1ZjPxdkJoiZB+zxuVTHjMV2vhfgsqVatcYJgbK 7XIQlCw2UcfzqQWIUitLWbLBjS6NLM6m5m1pom0K6CCHAVCY8v6aUSMb5qcWnIxRep1b 2iLooAymtw046DpQWqX4D+Ef3loE4wnCVtdWU= MIME-Version: 1.0 Received: by 10.182.124.33 with SMTP id mf1mr2044856obb.24.1321319463892; Mon, 14 Nov 2011 17:11:03 -0800 (PST) Received: by 10.182.42.104 with HTTP; Mon, 14 Nov 2011 17:11:03 -0800 (PST) In-Reply-To: <20111115004443.GA50429@vniz.net> References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> <20111112102241.GA75396@vniz.net> <20111112154135.GA21512@zim.MIT.EDU> <20111112171531.GA83419@vniz.net> <20111114013004.GA53392@zim.MIT.EDU> <20111114192721.GA16834@vniz.net> <20111114205855.GB58790@zim.MIT.EDU> <20111114212926.GA28783@vniz.net> <20111114230855.GA59545@zim.MIT.EDU> <20111115004443.GA50429@vniz.net> Date: Tue, 15 Nov 2011 02:11:03 +0100 Message-ID: From: Oliver Pinter To: Andrey Chernov , das@freebsd.org, current@freebsd.org, secteam@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:11:06 -0000 On 11/15/11, Andrey Chernov wrote: > On Mon, Nov 14, 2011 at 06:08:55PM -0500, David Schultz wrote: >> Not quite. OpenBSD's implementation is more careful. I just >> noticed a funny thing about FreeBSD's KERN_ARND sysctl: If the >> random device isn't (or can't be) loaded, KERN_ARND silently >> decides to initialize itself with the output of random(). This >> means that whatever minuscule amount of entropy it might have >> picked up from the clock is reduced to a maximum of 31 bits. >> That's a fantastic way to provide a false sense of security... > > I agree. > > Lets separate two things: "no /dev/random for jails" and "no random kernel > module is loaded". > IMHO kernel module should _not_ be optional anymore, it solves problem you > describe and all similar problems at once. > > Adding KERN_ARND to arc4random() at this moment solves "no /dev/random for > jails" problem alone and _not_ pretends to solve "no random kernel module > is loaded" problem. When random kernel module will become non-optional, > KERN_ARND automagically makes good security in that place too. > > P.S. Do I answer your doubts about &rdat key initialization in my prev. > posting? I think it's a much correct solution, rather than the original patch, while it initializes the whole structure, not only the key array... (&rdat.key vs &rdat; and uninitialized pid and tv): fd = _open(RANDOMDEV, O_RDONLY, 0); done = 0; if (fd >= 0) { - if (_read(fd, &rdat, KEYSIZE) == KEYSIZE) + if (_read(fd, &rdat, sizeof(rdat)) == sizeof(rdat)) done = 1; (void)_close(fd); - } + } > > -- > http://ache.vniz.net/ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 02:39:22 2011 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75FAD106566B; Tue, 15 Nov 2011 02:39:22 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id C81978FC16; Tue, 15 Nov 2011 02:39:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.5/8.14.5) with ESMTP id pAF2dDcm069132; Tue, 15 Nov 2011 06:39:13 +0400 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.5/8.14.5/Submit) id pAF2dCl6069130; Tue, 15 Nov 2011 06:39:12 +0400 (MSK) (envelope-from ache) Date: Tue, 15 Nov 2011 06:39:12 +0400 From: Andrey Chernov To: Oliver Pinter Message-ID: <20111115023912.GA68523@vniz.net> Mail-Followup-To: Andrey Chernov , Oliver Pinter , das@FreeBSD.ORG, current@FreeBSD.ORG, secteam@FreeBSD.ORG References: <20111112102241.GA75396@vniz.net> <20111112154135.GA21512@zim.MIT.EDU> <20111112171531.GA83419@vniz.net> <20111114013004.GA53392@zim.MIT.EDU> <20111114192721.GA16834@vniz.net> <20111114205855.GB58790@zim.MIT.EDU> <20111114212926.GA28783@vniz.net> <20111114230855.GA59545@zim.MIT.EDU> <20111115004443.GA50429@vniz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: das@FreeBSD.ORG, current@FreeBSD.ORG, secteam@FreeBSD.ORG Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:39:22 -0000 On Tue, Nov 15, 2011 at 02:11:03AM +0100, Oliver Pinter wrote: > > P.S. Do I answer your doubts about &rdat key initialization in my prev. > > posting? > > I think it's a much correct solution, rather than the original patch, > while it initializes the whole structure, not only the key array... > (&rdat.key vs &rdat; and uninitialized pid and tv): > > fd = _open(RANDOMDEV, O_RDONLY, 0); > done = 0; > if (fd >= 0) { > - if (_read(fd, &rdat, KEYSIZE) == KEYSIZE) > + if (_read(fd, &rdat, sizeof(rdat)) == sizeof(rdat)) > done = 1; > (void)_close(fd); > - } > + } > Currently this change will have no any effect in the code because only first 128 bytes of the structure are passed later: arc4_addrandom((u_char *)&rdat, KEYSIZE); In case you mean passing later whole structure like: arc4_addrandom((u_char *)&rdat, sizeof(rdat)); it will be incorrect because it change known algorithm parameters, which defines exact 128 bytes and not anything else. -- http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 02:44:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4618C106566B; Tue, 15 Nov 2011 02:44:26 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4353F8FC17; Tue, 15 Nov 2011 02:44:24 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so9147664bkb.13 for ; Mon, 14 Nov 2011 18:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nyN49c39pD5ZqJpiRAz3b+l+tksCRP4WtEp7WeqkQsw=; b=pkeXEELkZSQFVU4/f0BnjXHBwFiufSojpwcrNe4JcEv4VaaOLR4lMJB0hffWoef080 LPznBbPDZSb5GhfKeTfWlKuzXaKJeOEZ7xrQfXrCe5mcHK9mzmlLpB9Mmlx0jOehGv4X 7odd9a3z3r5dTp1RAs+K973mXisbAew8xs7RY= MIME-Version: 1.0 Received: by 10.205.120.145 with SMTP id fy17mr11018682bkc.124.1321325063291; Mon, 14 Nov 2011 18:44:23 -0800 (PST) Received: by 10.223.116.145 with HTTP; Mon, 14 Nov 2011 18:44:22 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Nov 2011 10:44:22 +0800 Message-ID: From: Paul Ambrose To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Cc: George Neville-Neil , Davide Italiano , freebsd-current@freebsd.org, Fabien Thomas Subject: Re: [PATCH] Intel Sandy Bridge support for hwpmc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:44:26 -0000 hi, I apply your patch on this [root@capoor-daemon /usr/src]# git show commit 4ec1d958bad5e78bcd3cc61a0da6b5a1302f8ec2 Author: kensmith Date: Mon Nov 14 00:45:25 2011 +0000 The releng/9.0 release branch has been created so convert stable/9 over to our standard "Politically Correct" name for the balance of the 9.0-RELEASE release cycle. Approved by: re (implicit) when my machine shutdown in my absence yesterday evening, I find a kernel oops this morning,(sorry, just printf, I can not get a kernel dump) the kernel says it is at uncore_pcpu_fini+0x5b I check the source, and it is at static int uncore_pcpu_fini(struct pmc_mdep *md, int cpu) { ..... for (n = 0; n < npmc; n++) wrmsr(UCP_EVSEL0 + n, 0); //here ..... here is my cpu type, and build hwpmc into kernel Copyright (c) 1992-2011 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 9.0-PRERELEASE #0 r+4ec1d95-dirty: Mon Nov 14 15:31:45 CST 2011 root@capoor-daemon:/usr/obj/usr/src/sys/MYKERNEL amd64 CPU: Intel(R) Core(TM) i5-2300 CPU @ 2.80GHz (2793.02-MHz K8-class CPU) I will try to apply this to current to see if this is reproduced. 2011/11/14 Attilio Rao : > 2011/11/13 Davide Italiano : >> On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano >> wrote: >>> Good evening folks. >>> During last days I've written a patch to add sandy bridge support to >>> hwpmc. Until now, the most recent Intel processor microarchitecture >>> supported was Westmere. >>> Testing is appreciated, in order to see if there's something that have >>> to be fixed. >>> You can find the diff here: http://davit.altervista.rg/hwpmc_sandy_bridge.diff >>> >>> I'd like to thanks a lot attilio@ that helped me to fix a bug and gnn@ >>> and fabient@ for the useful suggestions. >>> >>> Best >>> >>> Davide >>> >> >> Sorry, bad link. It should be: >> http://davit.altervista.org/hwpmc_sandy_bridge.diff > > I can perform some small cleanups and likely test it too. > > If Fabien or George can review it I'm fine with committing as long as > all that is settled. > > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 05:49:31 2011 Return-Path: Delivered-To: current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35CE81065774; Tue, 15 Nov 2011 05:49:30 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id ADDED8FC13; Tue, 15 Nov 2011 05:49:30 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id pAF5nU8P096037; Tue, 15 Nov 2011 00:49:30 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id pAF5nT6C096036; Tue, 15 Nov 2011 00:49:29 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Tue, 15 Nov 2011 00:49:29 -0500 From: David Schultz To: Andrey Chernov , Oliver Pinter , current@FreeBSD.ORG, secteam@FreeBSD.ORG Message-ID: <20111115054929.GA27803@zim.MIT.EDU> Mail-Followup-To: Andrey Chernov , Oliver Pinter , current@FreeBSD.ORG, secteam@FreeBSD.ORG References: <20111112154135.GA21512@zim.MIT.EDU> <20111112171531.GA83419@vniz.net> <20111114013004.GA53392@zim.MIT.EDU> <20111114192721.GA16834@vniz.net> <20111114205855.GB58790@zim.MIT.EDU> <20111114212926.GA28783@vniz.net> <20111114230855.GA59545@zim.MIT.EDU> <20111115004443.GA50429@vniz.net> <20111115023912.GA68523@vniz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111115023912.GA68523@vniz.net> Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 05:49:31 -0000 On Tue, Nov 15, 2011, Andrey Chernov wrote: > In case you mean passing later whole structure like: > > arc4_addrandom((u_char *)&rdat, sizeof(rdat)); > > it will be incorrect because it change known algorithm parameters, which > defines exact 128 bytes and not anything else. No, RC4 keys are anything up to 256 bytes. I think what you really want is a union in any case, but relax. arc4_stir() works right now, so I think it can stay as is until we're ready to make further functional changes, e.g., getting entropy from the KERN_ARND sysctl. But that's complicated by the fact that KERN_ARND won't tell you if it has failed to produce any useful entropy, and I won't have the cycles to look into it for a little while. From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 06:57:13 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 622331065673 for ; Tue, 15 Nov 2011 06:57:13 +0000 (UTC) (envelope-from chmiels@o2.pl) Received: from moh1-ve2.go2.pl (moh1-ve2.go2.pl [193.17.41.132]) by mx1.freebsd.org (Postfix) with ESMTP id C5E268FC12 for ; Tue, 15 Nov 2011 06:57:12 +0000 (UTC) Received: from moh1-ve2.go2.pl (unknown [10.0.0.132]) by moh1-ve2.go2.pl (Postfix) with ESMTP id 9267E1065F29 for ; Tue, 15 Nov 2011 07:57:11 +0100 (CET) Received: from unknown (unknown [10.0.0.74]) by moh1-ve2.go2.pl (Postfix) with SMTP for ; Tue, 15 Nov 2011 07:57:11 +0100 (CET) Received: from staticline55990.toya.net.pl [77.237.11.229] by poczta.o2.pl with ESMTP id UKzdMA; Tue, 15 Nov 2011 07:57:11 +0100 Date: Tue, 15 Nov 2011 07:57:23 +0100 From: Sebastian Chmielewski To: Alexander Motin Message-ID: <20111115075723.28787610@o2.pl> In-Reply-To: <4EC1A799.7050102@FreeBSD.org> References: <4EC198B8.1010901@FreeBSD.org> <20111115000055.58b7a103@o2.pl> <4EC1A799.7050102@FreeBSD.org> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-O2-Trust: 2, 65 X-O2-SPF: neutral Cc: current Subject: Re: Second SATA device lost after ZFS root is mount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 06:57:13 -0000 On Tue, 15 Nov 2011 01:43:21 +0200 Alexander Motin wrote: > explicitly disabled. I have only one crazy idea: while setting screen > brightness you are calling ACPI code that is black box by definition and > can do whatever it wants with hardware, including using any possible > custom power control interfaces. You are right, sequence of sudo sysctl dev.acpi_ibm.0.lcd_brightness=6; sudo sysctl dev.acpi_ibm.0.lcd_brightness=3 causes device disconnect: ahcich1: DISCONNECT requested ahcich1: AHCI reset... ahcich1: SATA connect timeout time=10000us status=00000000 ahcich1: AHCI reset: device not found (ada1:ahcich1:0:0:0): lost device (pass1:ahcich1:0:0:0): lost device (pass1:ahcich1:0:0:0): removing device entry best regards, -- Sebastian Chmielewski * jid:chmielsster@gmail.com * gg:3336919 * icq:224161389 From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 07:08:46 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5748B106566C; Tue, 15 Nov 2011 07:08:46 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id C711C8FC13; Tue, 15 Nov 2011 07:08:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.5/8.14.5) with ESMTP id pAF78iRx089604; Tue, 15 Nov 2011 11:08:44 +0400 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.5/8.14.5/Submit) id pAF78hx6089602; Tue, 15 Nov 2011 11:08:43 +0400 (MSK) (envelope-from ache) Date: Tue, 15 Nov 2011 11:08:43 +0400 From: Andrey Chernov To: das@freebsd.org, Oliver Pinter , current@freebsd.org, secteam@freebsd.org Message-ID: <20111115070842.GA86944@vniz.net> Mail-Followup-To: Andrey Chernov , das@freebsd.org, Oliver Pinter , current@FreeBSD.ORG, secteam@FreeBSD.ORG References: <20111112171531.GA83419@vniz.net> <20111114013004.GA53392@zim.MIT.EDU> <20111114192721.GA16834@vniz.net> <20111114205855.GB58790@zim.MIT.EDU> <20111114212926.GA28783@vniz.net> <20111114230855.GA59545@zim.MIT.EDU> <20111115004443.GA50429@vniz.net> <20111115023912.GA68523@vniz.net> <20111115054929.GA27803@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20111115054929.GA27803@zim.MIT.EDU> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 07:08:46 -0000 On Tue, Nov 15, 2011 at 12:49:29AM -0500, David Schultz wrote: > On Tue, Nov 15, 2011, Andrey Chernov wrote: > > In case you mean passing later whole structure like: > >=20 > > arc4_addrandom((u_char *)&rdat, sizeof(rdat)); > >=20 > > it will be incorrect because it change known algorithm parameters, whic= h=20 > > defines exact 128 bytes and not anything else. >=20 > No, RC4 keys are anything up to 256 bytes. Of course. But changing it away from the reference implementation will=20 cause questions or paranoia. You can re-read your recent reasons against=20 lowering drop count from 1024, this is very similar. > I think what you really want is a union in any case, but relax. > arc4_stir() works right now, so I think it can stay as is until > we're ready to make further functional changes, e.g., getting > entropy from the KERN_ARND sysctl. =20 You can left the current stir code as is but please don't forget in the=20 future that the price is its weakness in jails without /dev/random. > But that's complicated by > the fact that KERN_ARND won't tell you if it has failed to produce > any useful entropy, and I won't have the cycles to look into it for > a little while. BTW, we can re-stir kernel arc4 one time more - when yarrow is feeded,=20 =66rom the yarrow code. In general it promises to be earlier that any of=20 userland programs is starting. --=20 http://ache.vniz.net/ From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 17:10:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F9C6106564A for ; Tue, 15 Nov 2011 17:10:18 +0000 (UTC) (envelope-from gr@ubuntu64.secure-side.com) Received: from admin.secure-side.com (admin.secure-side.com [213.251.166.100]) by mx1.freebsd.org (Postfix) with SMTP id 933708FC19 for ; Tue, 15 Nov 2011 17:10:17 +0000 (UTC) Received: (qmail 52672 invoked from network); 15 Nov 2011 17:10:20 -0000 Received: from localhost (HELO ubuntu64.secure-side.com) (@127.0.0.1) by qmail with SMTP; 15 Nov 2011 17:10:20 -0000 Received: from localhost (localhost [127.0.0.1]) by ubuntu64.secure-side.com (Postfix) with ESMTP id 3FCC246A39; Tue, 15 Nov 2011 18:10:08 +0100 (CET) Received: from ubuntu64.secure-side.com ([127.0.0.1]) by localhost (ubuntu64.secure-side.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfNBsByakRu4; Tue, 15 Nov 2011 18:10:01 +0100 (CET) Received: from ubuntu64.secure-side.com (ubuntu64.secure-side.com [192.168.1.146]) by ubuntu64.secure-side.com (Postfix) with ESMTP id 4455746A38; Tue, 15 Nov 2011 18:10:01 +0100 (CET) Date: Tue, 15 Nov 2011 18:10:01 +0100 (CET) From: GR To: freebsd-current@freebsd.org Message-ID: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Originating-IP: [90.32.174.62] X-Mailer: Zimbra 7.1.3_GA_3346 (ZimbraWebClient - GC14 (Linux)/7.1.3_GA_3346) Cc: freebsd-stable@freebsd.org Subject: SIOCGIFADDR broken on 9.0-RC1? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 17:10:18 -0000 Hello list, more insights since my last post. Here is a small code to trigger the bug (end of email). When you run it on 9.0-RC1, it gets an alias address instead of the main inet address: % ./get-ip re0 inet: 192.168.2.10 # Main address being 192.168.1.148 On 8.2-RELEASE, all goes well: % ./get-ip re0 inet: PUBLIC_IP4 Is something broken, or a behaviour has changed since 8.2-RELEASE? Best regards, --8<-- #include #include #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { int fd; struct ifreq ifr; const struct sockaddr_in *sa; fd = socket(AF_INET, SOCK_DGRAM, 0); if (fd < 0) { perror("socket"); exit(-1); } memset(&ifr, 0, sizeof(struct ifreq)); strlcpy(ifr.ifr_name, argv[1], sizeof(ifr.ifr_name)); if (ioctl(fd, SIOCGIFADDR, &ifr) == 0) { sa = (const struct sockaddr_in *) &ifr.ifr_addr; printf("inet: %s\n", inet_ntoa(sa->sin_addr)); } else { perror("ioctl"); exit(-1); } exit(0); } --8<-- -- ^ ___ ___ http://www.GomoR.org/ <-+ | / __ |__/ Senior Security Engineer | | \__/ | \ ---[ zsh$ alias psed='perl -pe ' ]--- | +--> Net::Frame <=> http://search.cpan.org/~gomor/ <---+ From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 16:58:05 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBEB01065677 for ; Tue, 15 Nov 2011 16:58:05 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by mx1.freebsd.org (Postfix) with ESMTP id D3D348FC1A for ; Tue, 15 Nov 2011 16:58:03 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 0A530D483B5 for ; Tue, 15 Nov 2011 17:57:57 +0100 (CET) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id CDBFC8ED; Tue, 15 Nov 2011 16:57:56 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 9506C13C37; Tue, 15 Nov 2011 16:57:56 +0000 (UTC) Date: Tue, 15 Nov 2011 17:57:56 +0100 From: Jeremie Le Hen To: Oliver Pinter Message-ID: <20111115165756.GA11894@felucia.tataz.chchile.org> References: <20111018090750.GG50300@deviant.kiev.zoral.com.ua> <20111018183219.GN50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 15 Nov 2011 17:13:24 +0000 Cc: Kostik Belousov , Garrett Cooper , current@freebsd.org, Arnaud Lacombe Subject: Re: [RFC] Enable nxstack by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 16:58:05 -0000 Hi, On Wed, Oct 19, 2011 at 12:37:44AM +0200, Oliver Pinter wrote: > In NetBSD has been some PaX feature [0] implemented. (ASLR, W^X > (~nxstack), mprotect restriction, veriexec, mmap randomization[2]...) > > [0] http://pax.grsecurity.net/docs/index.html > [1] http://www.netbsd.org/~elad/recent/man/security.8.html > [2] http://people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff Suleiman actually wrought two patches, one randomizing the stack (the one you pointed out) and another one randomizing non-fixed mmap(2) calls: http://people.freebsd.org/~ssouhlal/testing/mmap_random-20050528.diff FYI, they do not apply cleanly on recent source trees (the patches were made in 2005), but they can be applied with little fiddling. I'm running multiple 8.x production machines with them without any problem. I've always wanted them to be committed as opt-in knobs, but I can't remember why they hadn't at the time. Cheers, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 17:53:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C67EF106564A; Tue, 15 Nov 2011 17:53:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8828FC1A; Tue, 15 Nov 2011 17:53:19 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id F0ACE46B06; Tue, 15 Nov 2011 12:53:18 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5C8248A051; Tue, 15 Nov 2011 12:53:18 -0500 (EST) From: John Baldwin To: Baptiste Daroussin Date: Tue, 15 Nov 2011 12:46:41 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111111221058.GA1911@azathoth.lan> <20111111225907.GA1993@azathoth.lan> In-Reply-To: <20111111225907.GA1993@azathoth.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201111151246.42038.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 15 Nov 2011 12:53:18 -0500 (EST) Cc: freebsd-current@freebsd.org Subject: Re: No disks usable on a P5NE MB (aka regession is r219737) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 17:53:19 -0000 On Friday, November 11, 2011 5:59:07 pm Baptiste Daroussin wrote: > On Fri, Nov 11, 2011 at 11:10:58PM +0100, Baptiste Daroussin wrote: > > On Thu, Sep 29, 2011 at 12:22:54AM +0200, Baptiste Daroussin wrote: > > > On Sun, Sep 11, 2011 at 10:39:38PM +0200, Baptiste Daroussin wrote: > > > > > > the result is: > > > > > > db> show intrcnt > > > > > > cpu0: timer 4510 > > > > > > irq256: hdac0 1 > > > > > > cpu3: timer 29 > > > > > > cpu1: timer 3036 > > > > > > cpu2: timer 31 > > > > > > db> > > > > > > > > > > > > I did break at the mountfrom> prompt > > > > > > If I break before I only have the cpu0 and irq256 entries. > > > > > > > > > > Hmmm, is there any way you can build a 9 kernel without sound support (since > > > > > that clutters up bootverbose) and capture a verbose dmesg, using a serial > > > > > console or PXE booting to an NFS root of some sort? > > > > > > > > > I can't pxe boot, but I can record the build on my camera: > > > > http://people.freebsd.org/~bapt/9-fail.avi (18MB) > > > > > > > > (this is 9.0-BETA2 memstick) > > > > > > > > Hope that could help > > > > > > > > > > Apparently this doesn't help, given that I have no way to netboot this box, may > > > that be from pxe and that there is no serial console, what can I do more to help > > > fixing this? > > > > > > I would love to be able to run 9 on my box > > > > > > regards, > > > Bapt > > > > After trying lots of different kernel it appears that the regression was > > introduce in r219737. I'm trying to figure out to solve this. > > > > If you have any clue tell me. > > > > regards, > > Bapt > > > > With the help of cognet, I workaround this and have been able to boot both 9 and > 10 remove that block : > http://people.freebsd.org/~bapt/workaround-to-boot-p5ne.diff Yeah, the problem is that NVIDIA chipsets seem to have really odd behavior in that once you turn MSI mapping on for a given node in the HyperTransport tree it expects all child devices to only use MSI and not INTx. Linux has a lot of quirk code to try to handle this by only turning on the mapping window when MSI is enabled for a given device. However, it has lots of hacks to try to find the right Host-PCI Bridge that a given device is a child of. I'm mostly tempted to just disable MSI on NVIDIA chipsets that have these issues rather than adding the same number of quirks. However I haven't really had time to sit down and look at this. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 18:15:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28F801065670; Tue, 15 Nov 2011 18:15:04 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 13AB68FC17; Tue, 15 Nov 2011 18:15:02 +0000 (UTC) Received: by faar19 with SMTP id r19so1020482faa.13 for ; Tue, 15 Nov 2011 10:15:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=O+QPNLAEJ4A4tuasufnM1wdPbX/3AyuzfVaXEDXO3os=; b=snD6Nl2HBOAZh9PH84Zh9FDzuzrAOnedMtd9KfYPqT+AI75rk9+loL+HYXph2fGmBd S/Fqub5yA8M2Dwny8LRz3/4dP97hwoO1E1vEoRAcF6WVNUk/CfCPIRFpxOM9Op7NFTD4 bO6YqOrf/EL4iG6SlKLG1HNqFQ52477F4uy/k= MIME-Version: 1.0 Received: by 10.152.105.226 with SMTP id gp2mr17767509lab.28.1321380901158; Tue, 15 Nov 2011 10:15:01 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.152.21.104 with HTTP; Tue, 15 Nov 2011 10:15:01 -0800 (PST) In-Reply-To: <20111107193516.GA50300@deviant.kiev.zoral.com.ua> References: <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> <20111107193516.GA50300@deviant.kiev.zoral.com.ua> Date: Tue, 15 Nov 2011 19:15:01 +0100 X-Google-Sender-Auth: ooZX_iQmKFguhgChWmyjOkvOg8E Message-ID: From: Attilio Rao To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 18:15:04 -0000 2011/11/7 Kostik Belousov : > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: >> Ok. =C2=A0I'll offer one final suggestion. =C2=A0Please consider an alte= rnative >> suffix to "func". =C2=A0Perhaps, "kbi" or "KBI". =C2=A0In other words, s= omething >> that hints at the function's reason for existing. > > Sure. Below is the extraction of only vm_page_lock() bits, together > with the suggested rename. When Attilio provides the promised simplificat= ion > of the mutex KPI, this can be reduced. My tentative patch is here: http://www.freebsd.org/~attilio/mutexfileline.patch I need to make more compile testing later, but it already compiles GENERIC + modules fine on HEAD. The patch provides a common entrypoint, option independent, for both fast case and debug/compat case. Additively, it almost entirely fixes the standard violation of the reserved namespace, as you described (the notable exception being the macro used in the fast path, that I want to fix as well, but in a separate commit). Now the file/line couplet can be passed to the "_" suffix variant of the flag functions. eadler@ reviewed the mutex.h comment. Please let me know what you think about it, as long as we agree on the patch I'll commit it. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 18:46:38 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23B08106566C; Tue, 15 Nov 2011 18:46:38 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id C8C288FC0C; Tue, 15 Nov 2011 18:46:35 +0000 (UTC) Received: by pzk33 with SMTP id 33so32455038pzk.3 for ; Tue, 15 Nov 2011 10:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LfN8wVGyCtsv7s5Ld5S71FXQUCmq80uGeAZQ7Ms8tDM=; b=Y22npoFmI2g+nI1Yxd8l9tyIWxVigG8pLKkkfyEwk1PJylUZ3Sd0cZHwLhwAtdHF7n sPsKGtbK2T8JKpa3bGlkjMngK/YwB8mPs56qwk2ocPoyV84Mr0IsR+RkRqzVt4FTlm/A BszTnb7p9dZYQ52pru9f993C3vA9w53c2arZs= MIME-Version: 1.0 Received: by 10.68.72.168 with SMTP id e8mr61381841pbv.127.1321382795559; Tue, 15 Nov 2011 10:46:35 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.56.97 with HTTP; Tue, 15 Nov 2011 10:46:35 -0800 (PST) In-Reply-To: References: <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> <20111107193516.GA50300@deviant.kiev.zoral.com.ua> Date: Tue, 15 Nov 2011 10:46:35 -0800 X-Google-Sender-Auth: vIsi4O7pmTkPxtba8oKpabbePFc Message-ID: From: mdf@FreeBSD.org To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Kostik Belousov , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 18:46:38 -0000 On Tue, Nov 15, 2011 at 10:15 AM, Attilio Rao wrote: > 2011/11/7 Kostik Belousov : >> On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: >>> Ok. =A0I'll offer one final suggestion. =A0Please consider an alternati= ve >>> suffix to "func". =A0Perhaps, "kbi" or "KBI". =A0In other words, someth= ing >>> that hints at the function's reason for existing. >> >> Sure. Below is the extraction of only vm_page_lock() bits, together >> with the suggested rename. When Attilio provides the promised simplifica= tion >> of the mutex KPI, this can be reduced. > > My tentative patch is here: > http://www.freebsd.org/~attilio/mutexfileline.patch > > I need to make more compile testing later, but it already compiles > GENERIC + modules fine on HEAD. > > The patch provides a common entrypoint, option independent, for both > fast case and debug/compat case. > Additively, it almost entirely fixes the standard violation of the > reserved namespace, as you described (the notable exception being the > macro used in the fast path, that I want to fix as well, but in a > separate commit). > > Now the file/line couplet can be passed to the "_" suffix variant of > the flag functions. > > eadler@ reviewed the mutex.h comment. > > Please let me know what you think about it, as long as we agree on the > patch I'll commit it. Out of curiosity, why are function names explicitly spelled out in panic and log messages, instead of using %s and __func__? I've seen this all around FreeBSD, and if there's no reason otherwise, I'd just as soon change to a version that doesn't need updating when the function names change. Thanks, matthew From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 19:12:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6783F1065676; Tue, 15 Nov 2011 19:12:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 62ECD8FC14; Tue, 15 Nov 2011 19:12:53 +0000 (UTC) Received: by faar19 with SMTP id r19so1110741faa.13 for ; Tue, 15 Nov 2011 11:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2uIbwp9M5vN9TX5MkKv1lhBj241OGvGk16T1ErLK4cg=; b=TVFtCOPGe4hDo1n+I1a66EBOGpvyG5R2V/P51JWyMwzi09KeSRYeZqQqAIMbz+M93N V8WpZgzmekxZejb1HpEwtAd8QCcCzeez3YjJWDtRopI4BipcHXCW7NAIL3QhcRfmei8l DhbL1Cj8Avm5Q7LBiuvopMv27BmccooCLRdx8= MIME-Version: 1.0 Received: by 10.152.104.236 with SMTP id gh12mr18268308lab.49.1321384372897; Tue, 15 Nov 2011 11:12:52 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.152.21.104 with HTTP; Tue, 15 Nov 2011 11:12:52 -0800 (PST) In-Reply-To: References: <4EB40015.5040100@rice.edu> <20111104153004.GK50300@deviant.kiev.zoral.com.ua> <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> <20111107193516.GA50300@deviant.kiev.zoral.com.ua> Date: Tue, 15 Nov 2011 20:12:52 +0100 X-Google-Sender-Auth: eAM_R21KiG3wSzCVbpTbghg0Rpg Message-ID: From: Attilio Rao To: mdf@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Kostik Belousov , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 19:12:55 -0000 2011/11/15 : > On Tue, Nov 15, 2011 at 10:15 AM, Attilio Rao wrote= : >> 2011/11/7 Kostik Belousov : >>> On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: >>>> Ok. =C2=A0I'll offer one final suggestion. =C2=A0Please consider an al= ternative >>>> suffix to "func". =C2=A0Perhaps, "kbi" or "KBI". =C2=A0In other words,= something >>>> that hints at the function's reason for existing. >>> >>> Sure. Below is the extraction of only vm_page_lock() bits, together >>> with the suggested rename. When Attilio provides the promised simplific= ation >>> of the mutex KPI, this can be reduced. >> >> My tentative patch is here: >> http://www.freebsd.org/~attilio/mutexfileline.patch >> >> I need to make more compile testing later, but it already compiles >> GENERIC + modules fine on HEAD. >> >> The patch provides a common entrypoint, option independent, for both >> fast case and debug/compat case. >> Additively, it almost entirely fixes the standard violation of the >> reserved namespace, as you described (the notable exception being the >> macro used in the fast path, that I want to fix as well, but in a >> separate commit). >> >> Now the file/line couplet can be passed to the "_" suffix variant of >> the flag functions. >> >> eadler@ reviewed the mutex.h comment. >> >> Please let me know what you think about it, as long as we agree on the >> patch I'll commit it. > > Out of curiosity, why are function names explicitly spelled out in > panic and log messages, instead of using %s and __func__? =C2=A0I've seen > this all around FreeBSD, and if there's no reason otherwise, I'd just > as soon change to a version that doesn't need updating when the > function names change. I prefer the __func__ stuff as well but bde isn't in favor of it because it is more difficult to grep for the message in that case. I'm not sure I'd buy his point on this, honestly, but that is why. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 19:36:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 968DD1065676; Tue, 15 Nov 2011 19:36:25 +0000 (UTC) (envelope-from mva@FreeBSD.org) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) by mx1.freebsd.org (Postfix) with ESMTP id 599108FC17; Tue, 15 Nov 2011 19:36:25 +0000 (UTC) Received: from [89.182.9.211] (helo=localhost) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1RQOd1-0000hD-Nb; Tue, 15 Nov 2011 20:25:08 +0100 Date: Tue, 15 Nov 2011 20:29:22 +0100 From: Marcus von Appen To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Message-ID: <20111115192922.GA1922@medusa.sysfault.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Df-Sender: MzAzMjU2 Cc: Subject: uhid(4) and report structures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcus von Appen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 19:36:25 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I wonder, if I am correct with my assumption that the usb_ctl_report* structures mentioned in uhid(4) have to be defined and created by the code portion that uses the USB_GET_REPORT(), USB_SET_REPORT(), ... calls. In FreeBSD < 800063 we defined them in the header files of the USB subsystem. After the rewrite those struct definitions vanished. Will the USB_ macros mentioned in uhid(4) "just" return a byte sequence (that's what I understand from the UHID specification) so that code, which uses those calls, can implement its own struct container for the information retrieved? Thanks for shedding some light on this. In case i am correct with what I wrote above, it might make sense to mention it in uhid(4). Best regards Marcus --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7CvZIACgkQi68/ErJnpkdvkQCgy0tCFAI6HDwbLB5oGAZ6LNvJ zl8An0lm1gzCgZy1U9HIAAVxgy7Le0Ep =K+ol -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 20:11:06 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4822E1065673 for ; Tue, 15 Nov 2011 20:11:06 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CA73E8FC14 for ; Tue, 15 Nov 2011 20:11:05 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so10487222bkb.13 for ; Tue, 15 Nov 2011 12:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MKzEWoMfimv0RRrNgS0mQtZneqEXXFtyN7C3PF7VCz4=; b=jskzr0MASMVG+3vUo4/j0a+pzUmzimofQsgFChHsgJvM1fdazAMJnbmkEjEhQVc5cP gi4LQ/EC/UF4wi4Guf+ZxEds6qWE2RV/a0JWT3HfXRvakGU7wxZERrWkrXgebEOAXAar vxvTcQdNQiyrI4lrH/mB+Wx9TWK2Oq+QoZTn4= Received: by 10.205.130.1 with SMTP id hk1mr8345636bkc.68.1321387864308; Tue, 15 Nov 2011 12:11:04 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id i3sm18286650faf.0.2011.11.15.12.11.02 (version=SSLv3 cipher=OTHER); Tue, 15 Nov 2011 12:11:03 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC2C757.4060303@FreeBSD.org> Date: Tue, 15 Nov 2011 22:11:03 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: Marcus von Appen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current Subject: Re: uhid(4) and report structures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 20:11:06 -0000 On 15.11.2011 21:29, Marcus von Appen wrote: > I wonder, if I am correct with my assumption that the usb_ctl_report* > structures mentioned in uhid(4) have to be defined and created by the > code portion that uses the USB_GET_REPORT(), USB_SET_REPORT(), > ... calls. > > In FreeBSD< 800063 we defined them in the header files of the USB > subsystem. After the rewrite those struct definitions vanished. Will > the USB_ macros mentioned in uhid(4) "just" return a byte sequence > (that's what I understand from the UHID specification) so that code, > which uses those calls, can implement its own struct container for the > information retrieved? > > Thanks for shedding some light on this. In case i am correct with what I > wrote above, it might make sense to mention it in uhid(4). In new USB stack these calls use struct usb_gen_descriptor argument. Difficult to say why it was done, but it was. To hide that I've recently added two wrapper functions to the libusbhid in HEAD: hid_get_report() and hid_set_report(). -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 20:39:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AE341065744; Tue, 15 Nov 2011 20:39:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6D78FC17; Tue, 15 Nov 2011 20:39:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B3C7246B32; Tue, 15 Nov 2011 15:38:59 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 57E878A051; Tue, 15 Nov 2011 15:38:59 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 15 Nov 2011 15:38:58 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EB40015.5040100@rice.edu> <20111106164204.GY50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111106164204.GY50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201111151538.58323.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 15 Nov 2011 15:38:59 -0500 (EST) Cc: mdf@freebsd.org, "K. Macy" , Alan Cox , Andriy Gapon , Benjamin Kaduk , Kostik Belousov , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 20:39:00 -0000 On Sunday, November 06, 2011 11:42:04 am Kostik Belousov wrote: > On Sun, Nov 06, 2011 at 07:22:51AM -0800, mdf@freebsd.org wrote: > > On Sun, Nov 6, 2011 at 4:43 AM, Kostik Belousov wrote: > > > Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has > > > a lot of violations in regard of the namespaces, IMO. The __* namespace > > > is reserved for the language implementation, so our freestanding program > > > (kernel) ignores the requirements of the C standard with the names like > > > __mtx_lock_spin(). Using the name _vm_page_lock() is valid, but makes > > > it not unreasonable for other developers to introduce reserved names. > > > So I decided to use the suffixes. vm_map.h locking is free of these > > > violations. > > > > I'm pretty sure that when the C standard says, "the implementation", > > they're referring to the compiler and OS it runs on. Which makes the > > FreeBSD kernel part of "the implementation", which is precisely why so > > many headers have defines that start with __ and then, if certain > > posix defines are set, also uses non-__ versions of the name. > > For libc providing parts, required by standard, you are right. > But our kernel is a freestanding program using a compiler, so in-kernel > uses of the reserved namespace is a violation. I don't buy that argument at all. We have a libc for the kernel, it's called libkern and we own that, too. We depend on using _ and __ prefixes all over the kernel and trying to change that now would be excessively gratuitous. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 21:04:19 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6980B106566B for ; Tue, 15 Nov 2011 21:04:19 +0000 (UTC) (envelope-from mva@FreeBSD.org) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) by mx1.freebsd.org (Postfix) with ESMTP id F25C88FC15 for ; Tue, 15 Nov 2011 21:04:18 +0000 (UTC) Received: from [89.182.9.211] (helo=localhost) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1RQPx1-0005hf-Hu; Tue, 15 Nov 2011 21:49:52 +0100 Date: Tue, 15 Nov 2011 21:54:06 +0100 From: Marcus von Appen To: Alexander Motin , current Message-ID: <20111115205406.GB1922@medusa.sysfault.org> References: <4EC2C757.4060303@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tjCHc7DPkfUGtrlw" Content-Disposition: inline In-Reply-To: <4EC2C757.4060303@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Df-Sender: MzAzMjU2 Cc: Subject: Re: uhid(4) and report structures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcus von Appen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 21:04:19 -0000 --tjCHc7DPkfUGtrlw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On, Tue Nov 15, 2011, Alexander Motin wrote: > On 15.11.2011 21:29, Marcus von Appen wrote: > > I wonder, if I am correct with my assumption that the usb_ctl_report* > > structures mentioned in uhid(4) have to be defined and created by the > > code portion that uses the USB_GET_REPORT(), USB_SET_REPORT(), > > ... calls. > > > > In FreeBSD< 800063 we defined them in the header files of the USB > > subsystem. After the rewrite those struct definitions vanished. Will > > the USB_ macros mentioned in uhid(4) "just" return a byte sequence > > (that's what I understand from the UHID specification) so that code, > > which uses those calls, can implement its own struct container for the > > information retrieved? > > > > Thanks for shedding some light on this. In case i am correct with what I > > wrote above, it might make sense to mention it in uhid(4). >=20 > In new USB stack these calls use struct usb_gen_descriptor argument.=20 > Difficult to say why it was done, but it was. To hide that I've recently= =20 > added two wrapper functions to the libusbhid in HEAD: hid_get_report()=20 > and hid_set_report(). So the man page is currently not up to date and can - at least for now - be assumed to be wrong? To get the mappings correct, which fields would I have to use from usb_gen_descriptor? Earlier we had: struct usb_ctl_report { int ucr_report; u_char ucr_data[1024]; }; The mapping might be: usb_gen_descriptor.ugd_data =3D=3D usb_ctl_report.ucr_data usb_gen_descriptor.ugd_report_type =3D=3D usb_ctl_report.ucr_report Is that correct? Also, ugd_data is of variable size with ugd_actlen indicating the size of the ugd_data buffer? Best regards Marcus --tjCHc7DPkfUGtrlw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7C0W4ACgkQi68/ErJnpkdtLQCfcnouA0eQY5HlNl1oeKipItMQ wFYAoL4O3cgkTuGkjoiRUUB22e/9J7lb =ZbF3 -----END PGP SIGNATURE----- --tjCHc7DPkfUGtrlw-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 21:17:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ABFD1065675 for ; Tue, 15 Nov 2011 21:17:32 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id A0DA78FC08 for ; Tue, 15 Nov 2011 21:17:31 +0000 (UTC) X-T2-Spam-Status: No, hits=2.5 required=5.0 tests=ALL_TRUSTED, BAYES_99 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 205925778; Tue, 15 Nov 2011 22:17:29 +0100 From: Hans Petter Selasky To: Marcus von Appen Date: Tue, 15 Nov 2011 22:14:43 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <4EC2C757.4060303@FreeBSD.org> <20111115205406.GB1922@medusa.sysfault.org> In-Reply-To: <20111115205406.GB1922@medusa.sysfault.org> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq,NwSZ4V" =?iso-8859-1?q?=7CLR=2E+tj=7Dg5=0A=09=25V?=,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( =?iso-8859-1?q?=0A=09=3AAuzV9=3A=2EhESm-x4h240C=609=3Dw?= MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201111152214.43361.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: uhid(4) and report structures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 21:17:32 -0000 On Tuesday 15 November 2011 21:54:06 Marcus von Appen wrote: > struct usb_ctl_report { > int ucr_report; > u_char ucr_data[1024]; > }; Hi, Before the descriptor length was limited to 1024 bytes. Now it is limited to 65535 bytes, which is the USB maximum for control endpoints. Having a buffer this large by default does not make sense, so a pointer and length is the best solution. The application also sometimes know about what descriptor size(s) it expects. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 21:34:42 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9702E106566B; Tue, 15 Nov 2011 21:34:42 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E41A18FC0C; Tue, 15 Nov 2011 21:34:41 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so10595833bkb.13 for ; Tue, 15 Nov 2011 13:34:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VJBW3+hpq0BUjZZzESDxoWH2nlkiD1c7tHj/38tSLN0=; b=QyYf0m3gOs5eXjHrDuQPNZ8HIsPApaKl1B+OFAcn3ulqSMz1hp8ZMG7Gn2bE/4MgYI cnMlQRiwNMEJqY6VfnSYd8TYX3M6kJwYih35M+e/El4u2cFVH7eNOBsjuTLQ4MPWc9px j0R1Dw7gmMQk7V+ErznYBug6xZWTeatxERv9w= Received: by 10.205.138.129 with SMTP id is1mr18282901bkc.120.1321392880593; Tue, 15 Nov 2011 13:34:40 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id x19sm18482929fag.5.2011.11.15.13.34.38 (version=SSLv3 cipher=OTHER); Tue, 15 Nov 2011 13:34:39 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC2DAEF.70900@FreeBSD.org> Date: Tue, 15 Nov 2011 23:34:39 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: Marcus von Appen References: <4EC2C757.4060303@FreeBSD.org> <20111115205406.GB1922@medusa.sysfault.org> In-Reply-To: <20111115205406.GB1922@medusa.sysfault.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current Subject: Re: uhid(4) and report structures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 21:34:42 -0000 On 15.11.2011 22:54, Marcus von Appen wrote: > On, Tue Nov 15, 2011, Alexander Motin wrote: > >> On 15.11.2011 21:29, Marcus von Appen wrote: >>> I wonder, if I am correct with my assumption that the usb_ctl_report* >>> structures mentioned in uhid(4) have to be defined and created by the >>> code portion that uses the USB_GET_REPORT(), USB_SET_REPORT(), >>> ... calls. >>> >>> In FreeBSD< 800063 we defined them in the header files of the USB >>> subsystem. After the rewrite those struct definitions vanished. Will >>> the USB_ macros mentioned in uhid(4) "just" return a byte sequence >>> (that's what I understand from the UHID specification) so that code, >>> which uses those calls, can implement its own struct container for the >>> information retrieved? >>> >>> Thanks for shedding some light on this. In case i am correct with what I >>> wrote above, it might make sense to mention it in uhid(4). >> >> In new USB stack these calls use struct usb_gen_descriptor argument. >> Difficult to say why it was done, but it was. To hide that I've recently >> added two wrapper functions to the libusbhid in HEAD: hid_get_report() >> and hid_set_report(). > > So the man page is currently not up to date and can - at least for now - > be assumed to be wrong? > To get the mappings correct, which fields would I have to use from > usb_gen_descriptor? Earlier we had: > > struct usb_ctl_report { > int ucr_report; > u_char ucr_data[1024]; > }; > > The mapping might be: > > usb_gen_descriptor.ugd_data == usb_ctl_report.ucr_data > usb_gen_descriptor.ugd_report_type == usb_ctl_report.ucr_report > > Is that correct? Also, ugd_data is of variable size with ugd_actlen > indicating the size of the ugd_data buffer? Here is usage example: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libusbhid/data.c.diff?r1=1.9;r2=1.10;f=h -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 22:14:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79A891065675; Tue, 15 Nov 2011 22:14:56 +0000 (UTC) (envelope-from kp@sigsegv.be) Received: from mercury.codepro.be (mercury.codepro.be [IPv6:2001:4b98:dc0:51:216:3eff:feb7:3147]) by mx1.freebsd.org (Postfix) with ESMTP id 1299C8FC17; Tue, 15 Nov 2011 22:14:56 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (adrastea.jupiter.sigsegv.be [IPv6:2001:6f8:1498:1::3]) by mercury.codepro.be (Postfix) with ESMTP id BD888361; Tue, 15 Nov 2011 23:14:53 +0100 (CET) Received: from thebe.jupiter.sigsegv.be (thebe.jupiter.sigsegv.be [172.16.1.5]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id 69F61266B; Tue, 15 Nov 2011 23:14:53 +0100 (CET) Received: by thebe.jupiter.sigsegv.be (Postfix, from userid 1000) id 55F6534774; Tue, 15 Nov 2011 23:14:53 +0100 (CET) Date: Tue, 15 Nov 2011 23:14:53 +0100 From: Kristof Provost To: GR Message-ID: <20111115221453.GO53701@thebe.jupiter.sigsegv.be> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SIOCGIFADDR broken on 9.0-RC1? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 22:14:56 -0000 On 2011-11-15 18:10:01 (+0100), GR wrote: > more insights since my last post. Here is a small code to trigger the bug (end of email). > When you run it on 9.0-RC1, it gets an alias address instead of the main inet address: > > % ./get-ip re0 > inet: 192.168.2.10 > # Main address being 192.168.1.148 > > On 8.2-RELEASE, all goes well: > % ./get-ip re0 > inet: PUBLIC_IP4 > > Is something broken, or a behaviour has changed since 8.2-RELEASE? > I think the relevant bit of the code is found in sys/netinet/in.c. If your ioctl doesn't specify an IP address we end up in this bit: TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { iap = ifatoia(ifa); if (iap->ia_addr.sin_family == AF_INET) { if (td != NULL && prison_check_ip4(td->td_ucred, &iap->ia_addr.sin_addr) != 0) continue; ia = iap; break; } } The 'ia' pointer is later used to return the IP address. In other words: it returns the first address on the interface of type IF_INET (which isn't assigned to a jail). I think the order of the addresses is not fixed, or rather it depends on the order in which you assign addresses. In the handling of SIOCSIFADDR new addresses are just appended: TAILQ_INSERT_TAIL(&ifp->if_addrhead, ifa, ifa_link); I don't believe this has changed since 8.0. Is it possible something changed in the network initialisation, leading to the addresses being assigned in a different order? Eagerly awaiting to be told I'm wrong, Kristof From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 22:38:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18A12106566B; Tue, 15 Nov 2011 22:38:29 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6E1B18FC1A; Tue, 15 Nov 2011 22:38:27 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so10681670bkb.13 for ; Tue, 15 Nov 2011 14:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=L3rIWCPylJ7R9pp8VVSBFwG9hjYgAgwt/8Sbmb/2ba4=; b=GSFMKHDQ21YukXfJlnXiORDZiNZ/WOVFMPvwdmutTqaVFxw/jWZtVPUzPxxLjNftkZ Z2lUjMTOeBPmWDNeWqZuRudCP/jLx8+T2BxCl8vlbmd+Va3qGErw1q5M8MAQIB9SyvE2 5iRXgbOnF/dQXSZBjr8ZbairEm0YCjCrMJpDA= Received: by 10.204.141.8 with SMTP id k8mr26417959bku.14.1321395232056; Tue, 15 Nov 2011 14:13:52 -0800 (PST) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id q6sm37479428bka.6.2011.11.15.14.13.50 (version=SSLv3 cipher=OTHER); Tue, 15 Nov 2011 14:13:50 -0800 (PST) Date: Wed, 16 Nov 2011 00:13:49 +0200 From: Gleb Kurtsou To: GR Message-ID: <20111115221349.GA8701@reks> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SIOCGIFADDR broken on 9.0-RC1? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 22:38:29 -0000 On (15/11/2011 18:10), GR wrote: > Hello list, > > more insights since my last post. Here is a small code to trigger the bug (end of email). > When you run it on 9.0-RC1, it gets an alias address instead of the main inet address: > > % ./get-ip re0 > inet: 192.168.2.10 > # Main address being 192.168.1.148 > > On 8.2-RELEASE, all goes well: > % ./get-ip re0 > inet: PUBLIC_IP4 > > Is something broken, or a behaviour has changed since 8.2-RELEASE? Your test case looks ok and works as expexted for me on 10-CURRENT, both without aliases and after adding alias to interface. Perhaps it's the way you add aliases (libdnet ?). I've used: ifconfing em0 alias OTHERIP Thanks, Gleb. > > Best regards, > > > --8<-- > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > int > main(int argc, char *argv[]) > { > int fd; > struct ifreq ifr; > const struct sockaddr_in *sa; > > fd = socket(AF_INET, SOCK_DGRAM, 0); > if (fd < 0) { > perror("socket"); > exit(-1); > } > > memset(&ifr, 0, sizeof(struct ifreq)); > strlcpy(ifr.ifr_name, argv[1], sizeof(ifr.ifr_name)); > > if (ioctl(fd, SIOCGIFADDR, &ifr) == 0) { > sa = (const struct sockaddr_in *) &ifr.ifr_addr; > printf("inet: %s\n", inet_ntoa(sa->sin_addr)); > } > else { > perror("ioctl"); > exit(-1); > } > > exit(0); > } > --8<-- > > -- > ^ ___ ___ http://www.GomoR.org/ <-+ > | / __ |__/ Senior Security Engineer | > | \__/ | \ ---[ zsh$ alias psed='perl -pe ' ]--- | > +--> Net::Frame <=> http://search.cpan.org/~gomor/ <---+ > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 22:46:48 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A0211065670 for ; Tue, 15 Nov 2011 22:46:48 +0000 (UTC) (envelope-from gr@ubuntu64.secure-side.com) Received: from admin.secure-side.com (admin.secure-side.com [213.251.166.100]) by mx1.freebsd.org (Postfix) with SMTP id 7E2848FC08 for ; Tue, 15 Nov 2011 22:46:46 +0000 (UTC) Received: (qmail 1109 invoked from network); 15 Nov 2011 22:46:51 -0000 Received: from localhost (HELO ubuntu64.secure-side.com) (@127.0.0.1) by qmail with SMTP; 15 Nov 2011 22:46:51 -0000 Received: from localhost (localhost [127.0.0.1]) by ubuntu64.secure-side.com (Postfix) with ESMTP id 6513E469D9; Tue, 15 Nov 2011 23:35:42 +0100 (CET) Received: from ubuntu64.secure-side.com ([127.0.0.1]) by localhost (ubuntu64.secure-side.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLr7NCM5+jeH; Tue, 15 Nov 2011 23:35:37 +0100 (CET) Received: from ubuntu64.secure-side.com (ubuntu64.secure-side.com [192.168.1.146]) by ubuntu64.secure-side.com (Postfix) with ESMTP id 9B69D4694D; Tue, 15 Nov 2011 23:35:37 +0100 (CET) Date: Tue, 15 Nov 2011 23:35:37 +0100 (CET) From: GR To: Kristof Provost Message-ID: In-Reply-To: <20111115221453.GO53701@thebe.jupiter.sigsegv.be> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Originating-IP: [82.231.148.242] X-Mailer: Zimbra 7.1.3_GA_3346 (ZimbraWebClient - GC15 ([unknown])/7.1.3_GA_3346) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SIOCGIFADDR broken on 9.0-RC1? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 22:46:48 -0000 >From "Kristof Provost" : [..] > The 'ia' pointer is later used to return the IP address. > > In other words: it returns the first address on the interface > of type IF_INET (which isn't assigned to a jail). > > I think the order of the addresses is not fixed, or rather it depends > on > the order in which you assign addresses. In the handling of > SIOCSIFADDR > new addresses are just appended: > > TAILQ_INSERT_TAIL(&ifp->if_addrhead, ifa, ifa_link); > > I don't believe this has changed since 8.0. Is it possible something > changed in the network initialisation, leading to the addresses being > assigned in a different order? > > Eagerly awaiting to be told I'm wrong, > Kristof Thanks Kristof. It appears you are right, the order of assignement is important. I configured my interface using DHCP, and added aliases (all in /etc/rc.conf). But on the 8.2-RELEASE, I used static configuration. So, I switched to static assignement and it changes the behaviour (and "fixes" the "bug"). My guess is that during the time waiting for the DHCP offer, all aliases are already configured on the network interface, and the IP address given by DHCP is added at the end of the tail. Is that a wanted behaviour? I find it dangerous (i.e. not exactly what a user is expecting). Note: my aliases are attributed to jails. Regards, -- ^ ___ ___ http://www.GomoR.org/ <-+ | / __ |__/ Senior Security Engineer | | \__/ | \ ---[ zsh$ alias psed='perl -pe ' ]--- | +--> Net::Frame <=> http://search.cpan.org/~gomor/ <---+ From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 23:12:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B4FD106564A; Tue, 15 Nov 2011 23:12:57 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 72BA68FC13; Tue, 15 Nov 2011 23:12:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pAFNCvF0028365; Tue, 15 Nov 2011 23:12:57 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pAFNCv2r028364; Tue, 15 Nov 2011 23:12:57 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Wed, 16 Nov 2011 00:12:53 +0100 From: Baptiste Daroussin To: John Baldwin Message-ID: <20111115231253.GC96251@azathoth.lan> References: <20111111221058.GA1911@azathoth.lan> <20111111225907.GA1993@azathoth.lan> <201111151246.42038.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1SQmhf2mF2YjsYvc" Content-Disposition: inline In-Reply-To: <201111151246.42038.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: No disks usable on a P5NE MB (aka regession is r219737) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 23:12:57 -0000 --1SQmhf2mF2YjsYvc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 15, 2011 at 12:46:41PM -0500, John Baldwin wrote: [...] > and > > 10 remove that block : > > http://people.freebsd.org/~bapt/workaround-to-boot-p5ne.diff >=20 > Yeah, the problem is that NVIDIA chipsets seem to have really odd behavio= r in=20 > that once you turn MSI mapping on for a given node in the HyperTransport = tree=20 > it expects all child devices to only use MSI and not INTx. Linux has a l= ot of=20 > quirk code to try to handle this by only turning on the mapping window wh= en=20 > MSI is enabled for a given device. However, it has lots of hacks to try = to=20 > find the right Host-PCI Bridge that a given device is a child of. I'm mo= stly=20 > tempted to just disable MSI on NVIDIA chipsets that have these issues rat= her=20 > than adding the same number of quirks. However I haven't really had time= to=20 > sit down and look at this. >=20 Thanks for reply, if you can do some testing for you if you want. regards, Bapt --1SQmhf2mF2YjsYvc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7C8fUACgkQ8kTtMUmk6EzPVgCePcqORQByKFDJTm03pPV/Y8CO Z7gAoI2umAHLBs6U5ms5UHDW4ZF6p5vc =kqcD -----END PGP SIGNATURE----- --1SQmhf2mF2YjsYvc-- From owner-freebsd-current@FreeBSD.ORG Tue Nov 15 23:16:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89232106566C for ; Tue, 15 Nov 2011 23:16:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 35F208FC14 for ; Tue, 15 Nov 2011 23:16:26 +0000 (UTC) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta05.westchester.pa.mail.comcast.net with comcast id xbAL1h0080mv7h055bGT1H; Tue, 15 Nov 2011 23:16:27 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta11.westchester.pa.mail.comcast.net with comcast id xbGQ1h00S1t3BNj3XbGSAi; Tue, 15 Nov 2011 23:16:27 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8807D102C1D; Tue, 15 Nov 2011 15:16:23 -0800 (PST) Date: Tue, 15 Nov 2011 15:16:23 -0800 From: Jeremy Chadwick To: GR Message-ID: <20111115231623.GA5712@icarus.home.lan> References: <20111115221453.GO53701@thebe.jupiter.sigsegv.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 15 Nov 2011 23:29:08 +0000 Cc: Kristof Provost , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SIOCGIFADDR broken on 9.0-RC1? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 23:16:27 -0000 On Tue, Nov 15, 2011 at 11:35:37PM +0100, GR wrote: > >From "Kristof Provost" : > [..] > > The 'ia' pointer is later used to return the IP address. > > > > In other words: it returns the first address on the interface > > of type IF_INET (which isn't assigned to a jail). > > > > I think the order of the addresses is not fixed, or rather it depends > > on > > the order in which you assign addresses. In the handling of > > SIOCSIFADDR > > new addresses are just appended: > > > > TAILQ_INSERT_TAIL(&ifp->if_addrhead, ifa, ifa_link); > > > > I don't believe this has changed since 8.0. Is it possible something > > changed in the network initialisation, leading to the addresses being > > assigned in a different order? > > > > Eagerly awaiting to be told I'm wrong, > > Kristof > > Thanks Kristof. It appears you are right, the order of assignement is important. > I configured my interface using DHCP, and added aliases (all in /etc/rc.conf). > But on the 8.2-RELEASE, I used static configuration. > > So, I switched to static assignement and it changes the behaviour (and "fixes" the "bug"). > My guess is that during the time waiting for the DHCP offer, all aliases are already configured on the network interface, and the IP address given by DHCP is added at the end of the tail. > > Is that a wanted behaviour? I find it dangerous (i.e. not exactly what a user is expecting). > > Note: my aliases are attributed to jails. I would recommend adding synchronous_dhclient="yes" to /etc/rc.conf. This will cause dhclient (the DHCP client) to wait until it gets an answer + IP back from the DHCP server before continuing with the rc.d scripts. The default is "no". -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 00:09:22 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25CBF106570E for ; Wed, 16 Nov 2011 00:09:22 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 98EBB8FC0C for ; Wed, 16 Nov 2011 00:09:21 +0000 (UTC) Received: by wyf23 with SMTP id 23so7666615wyf.13 for ; Tue, 15 Nov 2011 16:09:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MEhhKc2riD8qlTT+XHQx9/5c+whkJdhedzfDZuEZYBw=; b=al+BjtUzFMwCzuZBib4BcZDYc7irr4the4t3Bwl/LmmHfhHGGzw4fXChXkamq5OXnX G/VH6BbJVClnjorQ/Ypdvk5CfGPoja1w5TVrST0aQrm9edEIOZ5rIDa9SVLnv2rYaf1L DDfl7QTbSqiUCJEv8gWmGS0k9Hju3SvLj8G1k= MIME-Version: 1.0 Received: by 10.182.21.134 with SMTP id v6mr6564022obe.64.1321402159833; Tue, 15 Nov 2011 16:09:19 -0800 (PST) Received: by 10.182.42.104 with HTTP; Tue, 15 Nov 2011 16:09:18 -0800 (PST) In-Reply-To: <20111115165756.GA11894@felucia.tataz.chchile.org> References: <20111018090750.GG50300@deviant.kiev.zoral.com.ua> <20111018183219.GN50300@deviant.kiev.zoral.com.ua> <20111115165756.GA11894@felucia.tataz.chchile.org> Date: Wed, 16 Nov 2011 01:09:18 +0100 Message-ID: From: Oliver Pinter To: Jeremie Le Hen Content-Type: multipart/mixed; boundary=14dae93b63ec57a2d904b1ceea11 Cc: Kostik Belousov , Garrett Cooper , current@freebsd.org, Arnaud Lacombe Subject: Re: [RFC] Enable nxstack by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 00:09:22 -0000 --14dae93b63ec57a2d904b1ceea11 Content-Type: text/plain; charset=ISO-8859-1 On 11/15/11, Jeremie Le Hen wrote: > Hi, > > On Wed, Oct 19, 2011 at 12:37:44AM +0200, Oliver Pinter wrote: >> In NetBSD has been some PaX feature [0] implemented. (ASLR, W^X >> (~nxstack), mprotect restriction, veriexec, mmap randomization[2]...) >> >> [0] http://pax.grsecurity.net/docs/index.html >> [1] http://www.netbsd.org/~elad/recent/man/security.8.html >> [2] http://people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff > > Suleiman actually wrought two patches, one randomizing the stack (the > one you pointed out) and another one randomizing non-fixed mmap(2) > calls: > > http://people.freebsd.org/~ssouhlal/testing/mmap_random-20050528.diff > > > FYI, they do not apply cleanly on recent source trees (the patches were > made in 2005), but they can be applied with little fiddling. I'm > running multiple 8.x production machines with them without any problem. Yeah, I use thins patch in 7-STABLE and 9-STABLE too. Patch for 9-STABLE has attached. > > I've always wanted them to be committed as opt-in knobs, but I can't > remember why they hadn't at the time. > > Cheers, > -- > Jeremie Le Hen > > Men are born free and equal. Later on, they're on their own. > Jean Yanne > --14dae93b63ec57a2d904b1ceea11 Content-Type: text/x-diff; charset=US-ASCII; name="randomize-stack-and-mmap.diff" Content-Disposition: attachment; filename="randomize-stack-and-mmap.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 Y29tbWl0IDc3OWE5NjI1MTllN2VhZDYzZGRhMjQzNDhiOThmNmNkZTgxNTY3NTIKQXV0aG9yOiBP bGl2ZXIgUGludGVyIDxvcG5Ab3BuLihub25lKT4KRGF0ZTogICBUdWUgT2N0IDQgMDA6MjQ6MDEg MjAxMSArMDIwMAoKICAgIGZvcndhcmRwb3J0IG1tYXAtcmFuZG9taXphdGlvbiBwYXRjaCBmcm9t IDctU1RBQkxFLW9wCiAgICAKICAgIFNpZ25lZC1vZmYtYnk6IE9saXZlciBQaW50ZXIgPG9saXZl ci5wbnRyQGdtYWlsLmNvbT4KCmRpZmYgLS1naXQgYS9zeXMva2Vybi9rZXJuX2V4ZWMuYyBiL3N5 cy9rZXJuL2tlcm5fZXhlYy5jCmluZGV4IGZlMDExNDIuLmRjNjZkYjYgMTAwNjQ0Ci0tLSBhL3N5 cy9rZXJuL2tlcm5fZXhlYy5jCisrKyBiL3N5cy9rZXJuL2tlcm5fZXhlYy5jCkBAIC0xMDYsNiAr MTA2LDcgQEAgTUFMTE9DX0RFRklORShNX1BBUkdTLCAicHJvYy1hcmdzIiwgIlByb2Nlc3MgYXJn dW1lbnRzIik7CiBzdGF0aWMgaW50IHN5c2N0bF9rZXJuX3BzX3N0cmluZ3MoU1lTQ1RMX0hBTkRM RVJfQVJHUyk7CiBzdGF0aWMgaW50IHN5c2N0bF9rZXJuX3VzcnN0YWNrKFNZU0NUTF9IQU5ETEVS X0FSR1MpOwogc3RhdGljIGludCBzeXNjdGxfa2Vybl9zdGFja3Byb3QoU1lTQ1RMX0hBTkRMRVJf QVJHUyk7CitzdGF0aWMgaW50IHN5c2N0bF9rZXJuX3N0YWNrZ2FwX3JhbmRvbShTWVNDVExfSEFO RExFUl9BUkdTKTsKIHN0YXRpYyBpbnQgZG9fZXhlY3ZlKHN0cnVjdCB0aHJlYWQgKnRkLCBzdHJ1 Y3QgaW1hZ2VfYXJncyAqYXJncywKICAgICBzdHJ1Y3QgbWFjICptYWNfcCk7CiAKQEAgLTEyMCw2 ICsxMjEsOSBAQCBTWVNDVExfUFJPQyhfa2VybiwgS0VSTl9VU1JTVEFDSywgdXNyc3RhY2ssIENU TFRZUEVfVUxPTkd8Q1RMRkxBR19SRHwKIFNZU0NUTF9QUk9DKF9rZXJuLCBPSURfQVVUTywgc3Rh Y2twcm90LCBDVExUWVBFX0lOVHxDVExGTEFHX1JELAogICAgIE5VTEwsIDAsIHN5c2N0bF9rZXJu X3N0YWNrcHJvdCwgIkkiLCAiIik7CiAKK1NZU0NUTF9QUk9DKF9rZXJuLCBPSURfQVVUTywgc3Rh Y2tnYXBfcmFuZG9tLCBDVExUWVBFX0lOVHxDVExGTEFHX1JXLAorICAgIE5VTEwsIDAsIHN5c2N0 bF9rZXJuX3N0YWNrZ2FwX3JhbmRvbSwgIkkiLCAic3RhY2tnYXAgbWF4aW11bSBvZmZzZXQiKTsK KwogdV9sb25nIHBzX2FyZ19jYWNoZV9saW1pdCA9IFBBR0VfU0laRSAvIDE2OwogU1lTQ1RMX1VM T05HKF9rZXJuLCBPSURfQVVUTywgcHNfYXJnX2NhY2hlX2xpbWl0LCBDVExGTEFHX1JXLCAKICAg ICAmcHNfYXJnX2NhY2hlX2xpbWl0LCAwLCAiIik7CkBAIC0xNzcsNiArMTgxLDMwIEBAIHN5c2N0 bF9rZXJuX3N0YWNrcHJvdChTWVNDVExfSEFORExFUl9BUkdTKQogCSAgICBzaXplb2YocC0+cF9z eXNlbnQtPnN2X3N0YWNrcHJvdCkpKTsKIH0KIAorc3RhdGljIGludAlzdGFja2dhcF9yYW5kb20g PSA2NCAqIDEwMjQ7CisKK3N0YXRpYyBpbnQKK3N5c2N0bF9rZXJuX3N0YWNrZ2FwX3JhbmRvbShT WVNDVExfSEFORExFUl9BUkdTKQoreworCWludAllcnI7CisJaW50CXZhbDsKKworCXZhbD1zdGFj a2dhcF9yYW5kb207CisJZXJyPXN5c2N0bF9oYW5kbGVfaW50KG9pZHAsICZ2YWwsIHNpemVvZihp bnQpLCByZXEpOworCWlmIChlcnIgfHwgIXJlcS0+bmV3cHRyKSB7CisJCXJldHVybiAoZXJyKTsK Kwl9CisKKwlpZiAoKHZhbDxBTElHTkJZVEVTICYmICh2YWwhPTApKQorCSAgICB8fCAhcG93ZXJv ZjIodmFsKSB8fCB2YWw+NjQqMTAyNCoxMDI0KSB7CisJCXJldHVybiAoRUlOVkFMKTsKKwl9CisK KwlzdGFja2dhcF9yYW5kb209dmFsOworCisJcmV0dXJuICgwKTsKK30KKwogLyoKICAqIEVhY2gg b2YgdGhlIGl0ZW1zIGlzIGEgcG9pbnRlciB0byBhIGBjb25zdCBzdHJ1Y3QgZXhlY3N3JywgaGVu Y2UgdGhlCiAgKiBkb3VibGUgcG9pbnRlciBoZXJlLgpAQCAtMTI0OCw2ICsxMjc2LDcgQEAgZXhl Y19jb3B5b3V0X3N0cmluZ3MoaW1ncCkKIAlzaXplX3QgZXhlY3BhdGhfbGVuOwogCWludCBzenNp Z2NvZGUsIHN6cHM7CiAJY2hhciBjYW5hcnlbc2l6ZW9mKGxvbmcpICogOF07CisJaW50IHNnYXA7 CiAKIAlzenBzID0gc2l6ZW9mKHBhZ2VzaXplc1swXSkgKiBNQVhQQUdFU0laRVM7CiAJLyoKQEAg LTEyNjUsNyArMTI5NCwxMSBAQCBleGVjX2NvcHlvdXRfc3RyaW5ncyhpbWdwKQogCQlpZiAocC0+ cF9zeXNlbnQtPnN2X3N6c2lnY29kZSAhPSBOVUxMKQogCQkJc3pzaWdjb2RlID0gKihwLT5wX3N5 c2VudC0+c3Zfc3pzaWdjb2RlKTsKIAl9Ci0JZGVzdHAgPQkoY2FkZHJfdClhcmdpbmZvIC0gc3pz aWdjb2RlIC0gU1BBUkVfVVNSU1BBQ0UgLQorCXNnYXA9MDsKKwlpZiAoc3RhY2tnYXBfcmFuZG9t IT0wKSB7CisJCXNnYXA9QUxJR04oYXJjNHJhbmRvbSgpJihzdGFja2dhcF9yYW5kb20tMSkpOwor CX0KKwlkZXN0cCA9CShjYWRkcl90KWFyZ2luZm8gLSBzenNpZ2NvZGUgLSBTUEFSRV9VU1JTUEFD RSAtIHNnYXAgLQogCSAgICByb3VuZHVwKGV4ZWNwYXRoX2xlbiwgc2l6ZW9mKGNoYXIgKikpIC0K IAkgICAgcm91bmR1cChzaXplb2YoY2FuYXJ5KSwgc2l6ZW9mKGNoYXIgKikpIC0KIAkgICAgcm91 bmR1cChzenBzLCBzaXplb2YoY2hhciAqKSkgLQpkaWZmIC0tZ2l0IGEvc3lzL3ZtL3ZtX21tYXAu YyBiL3N5cy92bS92bV9tbWFwLmMKaW5kZXggZTg1YjY4MS4uOTkxYTM3ZCAxMDA2NDQKLS0tIGEv c3lzL3ZtL3ZtX21tYXAuYworKysgYi9zeXMvdm0vdm1fbW1hcC5jCkBAIC02OCw2ICs2OCw3IEBA IF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxzeXMvc3RhdC5oPgogI2luY2x1ZGUg PHN5cy9zeXNlbnQuaD4KICNpbmNsdWRlIDxzeXMvdm1tZXRlci5oPgorI2luY2x1ZGUgPHN5cy9z eXNjdGwuaD4KIAogI2luY2x1ZGUgPHNlY3VyaXR5L21hYy9tYWNfZnJhbWV3b3JrLmg+CiAKQEAg LTk5LDYgKzEwMCwxMCBAQCBzdGF0aWMgaW50IHZtX21tYXBfY2RldihzdHJ1Y3QgdGhyZWFkICos IHZtX3NpemVfdCwgdm1fcHJvdF90LCB2bV9wcm90X3QgKiwKIHN0YXRpYyBpbnQgdm1fbW1hcF9z aG0oc3RydWN0IHRocmVhZCAqLCB2bV9zaXplX3QsIHZtX3Byb3RfdCwgdm1fcHJvdF90ICosCiAg ICAgaW50ICosIHN0cnVjdCBzaG1mZCAqLCB2bV9vb2Zmc2V0X3QsIHZtX29iamVjdF90ICopOwog CitzdGF0aWMgaW50IG1tYXBfcmFuZG9tPTE7CitTWVNDVExfSU5UKF92bSwgT0lEX0FVVE8sIG1t YXBfcmFuZG9tLCBDVExGTEFHX1JXLCAmbW1hcF9yYW5kb20sIDAsCisJCSJyYW5kb20gbW1hcCBv ZmZzZXQiKTsKKwogLyoKICAqIE1QU0FGRQogICovCkBAIC0yNTYsNyArMjYxLDggQEAgc3lzX21t YXAodGQsIHVhcCkKIAkJLyoKIAkJICogWFhYIGZvciBub24tZml4ZWQgbWFwcGluZ3Mgd2hlcmUg bm8gaGludCBpcyBwcm92aWRlZCBvcgogCQkgKiB0aGUgaGludCB3b3VsZCBmYWxsIGluIHRoZSBw b3RlbnRpYWwgaGVhcCBzcGFjZSwKLQkJICogcGxhY2UgaXQgYWZ0ZXIgdGhlIGVuZCBvZiB0aGUg bGFyZ2VzdCBwb3NzaWJsZSBoZWFwLgorCQkgKiBwbGFjZSBpdCBhZnRlciB0aGUgZW5kIG9mIHRo ZSBsYXJnZXN0IHBvc3NpYmxlIGhlYXAsCisJCSAqIHBsdXMgYSByYW5kb20gb2Zmc2V0LCBpZiBt bWFwX3JhbmRvbSBpcyBzZXQuCiAJCSAqCiAJCSAqIFRoZXJlIHNob3VsZCByZWFsbHkgYmUgYSBw bWFwIGNhbGwgdG8gZGV0ZXJtaW5lIGEgcmVhc29uYWJsZQogCQkgKiBsb2NhdGlvbi4KQEAgLTI2 NSw5ICsyNzEsMTMgQEAgc3lzX21tYXAodGQsIHVhcCkKIAkJaWYgKGFkZHIgPT0gMCB8fAogCQkg ICAgKGFkZHIgPj0gcm91bmRfcGFnZSgodm1fb2Zmc2V0X3Qpdm1zLT52bV90YWRkcikgJiYKIAkJ ICAgIGFkZHIgPCByb3VuZF9wYWdlKCh2bV9vZmZzZXRfdCl2bXMtPnZtX2RhZGRyICsKLQkJICAg IGxpbV9tYXgodGQtPnRkX3Byb2MsIFJMSU1JVF9EQVRBKSkpKQorCQkgICAgbGltX21heCh0ZC0+ dGRfcHJvYywgUkxJTUlUX0RBVEEpKSkpIHsKIAkJCWFkZHIgPSByb3VuZF9wYWdlKCh2bV9vZmZz ZXRfdCl2bXMtPnZtX2RhZGRyICsKIAkJCSAgICBsaW1fbWF4KHRkLT50ZF9wcm9jLCBSTElNSVRf REFUQSkpOworCQkJaWYgKG1tYXBfcmFuZG9tKSB7CisJCQkJYWRkcis9YXJjNHJhbmRvbSgpJigy NTYqMTAyNCoxMDI0LTEpOworCQkJfQorCQl9CiAJCVBST0NfVU5MT0NLKHRkLT50ZF9wcm9jKTsK IAl9CiAJaWYgKGZsYWdzICYgTUFQX0FOT04pIHsK --14dae93b63ec57a2d904b1ceea11-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 07:51:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C29C106564A; Wed, 16 Nov 2011 07:51:45 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 252328FC13; Wed, 16 Nov 2011 07:51:45 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id A07A2CB5C8; Wed, 16 Nov 2011 08:51:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Wed, 16 Nov 2011 08:51:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: GR X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-current Current , "freebsd-stable@freebsd.org List" Subject: Re: SIOCGIFADDR broken on 9.0-RC1? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 07:51:45 -0000 Am 15.11.2011 um 23:35 schrieb GR: > So, I switched to static assignement and it changes the behaviour (and = "fixes" the "bug"). > My guess is that during the time waiting for the DHCP offer, all = aliases are already configured on the network interface, and the IP = address given by DHCP is added at the end of the tail. >=20 > Is that a wanted behaviour? I find it dangerous (i.e. not exactly what = a user is expecting). A bit of background, as best I understand it and remember from Stevens: Interfaces in BSD do not have a notion of "primary" and "additional" = addresses; interfaces just have any number of addresses associated with = them. There's no inherent ordering in this list (except for how the = current implementation seems to keep them in the order they were = configured). To be able to associate proper routes with interface addresses, the = recommendation for multiple IPv4 addresses on an Ethernet interface is = to have one of them have the proper netmask for the network, and = configure the remainder with a netmask of 255.255.255.255. But that's = solely for the benefit of the routing table; the interface itself = doesn't really care. Reading the rc.conf man page could give you the impression that there = are primary and alias addresses, but the networking code doesn't really = work like that. The new ipv4_addrs_ syntax exposes the = actual behavior in a more direct way. Jeremy gave you a hint on how to fix your immediate problem, but the = real answer is that the program needs to be fixed that makes assumptions = about meaning attached to the first configured IPv4 address. HTH, Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 08:45:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41AD8106566B; Wed, 16 Nov 2011 08:45:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B5D688FC17; Wed, 16 Nov 2011 08:45:56 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAG8jis4041702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2011 10:45:44 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAG8jhR8006674; Wed, 16 Nov 2011 10:45:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAG8jgtg006673; Wed, 16 Nov 2011 10:45:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 16 Nov 2011 10:45:42 +0200 From: Kostik Belousov To: Attilio Rao Message-ID: <20111116084542.GY50300@deviant.kiev.zoral.com.ua> References: <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> <20111107193516.GA50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oe1auVEEt6MAu8AG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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: mdf@freebsd.org, "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 08:45:57 -0000 --oe1auVEEt6MAu8AG Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 15, 2011 at 07:15:01PM +0100, Attilio Rao wrote: > 2011/11/7 Kostik Belousov : > > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: > >> Ok. =9AI'll offer one final suggestion. =9APlease consider an alternat= ive > >> suffix to "func". =9APerhaps, "kbi" or "KBI". =9AIn other words, somet= hing > >> that hints at the function's reason for existing. > > > > Sure. Below is the extraction of only vm_page_lock() bits, together > > with the suggested rename. When Attilio provides the promised simplific= ation > > of the mutex KPI, this can be reduced. >=20 > My tentative patch is here: > http://www.freebsd.org/~attilio/mutexfileline.patch >=20 > I need to make more compile testing later, but it already compiles > GENERIC + modules fine on HEAD. >=20 > The patch provides a common entrypoint, option independent, for both > fast case and debug/compat case. > Additively, it almost entirely fixes the standard violation of the > reserved namespace, as you described (the notable exception being the > macro used in the fast path, that I want to fix as well, but in a > separate commit). >=20 > Now the file/line couplet can be passed to the "_" suffix variant of > the flag functions. Yes, this is exactly KPI that I would use when available for the vm_page_lock() patch. >=20 > eadler@ reviewed the mutex.h comment. >=20 > Please let me know what you think about it, as long as we agree on the > patch I'll commit it. But I also agree with John that imposing large churn due to the elimination of the '__' prefix is too late now. At least it will make the change non-MFCable. Besides, we already lived with the names for 10+ years. I will be happy to have the part of the patch that exports the mtx_XXX_(mtx, file, line) defines which can be used without taking care of LOCK_DEBUG or MUTEX_NOINLINE in the consumer code. --oe1auVEEt6MAu8AG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7DeDYACgkQC3+MBN1Mb4gr7QCgir16eqHqqf829VLsmpLBDqa1 hyEAn2kqYVWuBBwiXtfYczpr0tvoWXyx =ydW+ -----END PGP SIGNATURE----- --oe1auVEEt6MAu8AG-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 09:07:42 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFA06106566C for ; Wed, 16 Nov 2011 09:07:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 611F88FC08 for ; Wed, 16 Nov 2011 09:07:40 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAG97X9K046194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2011 11:07:33 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAG97XZs006762; Wed, 16 Nov 2011 11:07:33 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAG97Wgv006761; Wed, 16 Nov 2011 11:07:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 16 Nov 2011 11:07:32 +0200 From: Kostik Belousov To: Oliver Pinter Message-ID: <20111116090732.GZ50300@deviant.kiev.zoral.com.ua> References: <20111018183219.GN50300@deviant.kiev.zoral.com.ua> <20111115165756.GA11894@felucia.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FSvTb7d5Wg/QnVSK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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: Garrett Cooper , Jeremie Le Hen , current@freebsd.org, Arnaud Lacombe Subject: Re: [RFC] Enable nxstack by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 09:07:42 -0000 --FSvTb7d5Wg/QnVSK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 16, 2011 at 01:09:18AM +0100, Oliver Pinter wrote: > On 11/15/11, Jeremie Le Hen wrote: > > Hi, > > > > On Wed, Oct 19, 2011 at 12:37:44AM +0200, Oliver Pinter wrote: > >> In NetBSD has been some PaX feature [0] implemented. (ASLR, W^X > >> (~nxstack), mprotect restriction, veriexec, mmap randomization[2]...) > >> > >> [0] http://pax.grsecurity.net/docs/index.html > >> [1] http://www.netbsd.org/~elad/recent/man/security.8.html > >> [2] http://people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff > > > > Suleiman actually wrought two patches, one randomizing the stack (the > > one you pointed out) and another one randomizing non-fixed mmap(2) > > calls: > > > > http://people.freebsd.org/~ssouhlal/testing/mmap_random-20050528.diff > > > > > > FYI, they do not apply cleanly on recent source trees (the patches were > > made in 2005), but they can be applied with little fiddling. I'm > > running multiple 8.x production machines with them without any problem. >=20 > Yeah, I use thins patch in 7-STABLE and 9-STABLE too. > Patch for 9-STABLE has attached. One immediate issue, which is definitely not critical, is that the size of the stack of main thread becomes chopped by the random amount of bytes. This is not an issue for single-threaded process, because typical default stack size is around 64M. For the threaded process, libthr cuts the stack, see thr_init.c:init_main_thread(). There, the size of the stack is 2 or 4MB, and 64KB might be more significant part of it. Missed bit from the patch is some randomization at the load address for the PIE (which is the main feature of ASLR, I suspect). See imgact_elf.c:exec(), et_dyn_addr calculation. Another missed bit is the similar modification for freebsd32_copyout_strings(). The upper limit for the random offset for mmap() should be configurable in the same way as stack gap, instead of the dump enable/disable knob. There are numerous style violations in the patch, or rather, the patch fully violates the style. >=20 >=20 >=20 > > > > I've always wanted them to be committed as opt-in knobs, but I can't > > remember why they hadn't at the time. > > > > Cheers, > > -- > > Jeremie Le Hen > > > > Men are born free and equal. Later on, they're on their own. > > Jean Yanne > > --FSvTb7d5Wg/QnVSK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7DfVQACgkQC3+MBN1Mb4htwQCfYJFZqOyzH6JDMxDxhUN2MKEC vn4AoIa1xI+ZA0JAHmkx4LitRTmv0y/O =kK3I -----END PGP SIGNATURE----- --FSvTb7d5Wg/QnVSK-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 16:23:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E2D71065673; Wed, 16 Nov 2011 16:23:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4A8928FC1C; Wed, 16 Nov 2011 16:23:29 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0071B46B0A; Wed, 16 Nov 2011 11:23:27 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8D9848A050; Wed, 16 Nov 2011 11:23:27 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 16 Nov 2011 11:16:24 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EBB885E.9060908@freebsd.org> <4EC004BC.6060406@freebsd.org> In-Reply-To: <4EC004BC.6060406@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201111161116.24855.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 16 Nov 2011 11:23:27 -0500 (EST) Cc: Attilio Rao Subject: Re: [amd64] Reproducible cold boot failure (reboot succeeds) in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 16:23:29 -0000 On Sunday, November 13, 2011 12:56:12 pm Stefan Esser wrote: > Am 11.11.2011 13:15, schrieb Attilio Rao: > > Can you try rebuilding your kernel and modules from scratch and see if > > it fixes your problem? > > Sorry for the delay, but my system seems to need being turned off (S5) > for many hours (whole night) to reproduce the problem ... > > I had already rebuilt my kernel multiple times in the last weeks. But > just to be sure, I removed the build directories for kernel and world > and built a new kernel after building and installing world from scratch. > The next reboot (with boot blocks from the freshly built world) failed > again ... > > But the first lines of boot messages look strange: > > ... > WARNING: WITNESS option enabled, expect reduced performance. > Table 'FACP' at 0xba918a58 > Table 'APIC' at 0xba918b50 > Table 'SSDT' at 0xba918be8 > Table 'MCFG' at 0xba918dc0 > Table 'HPET' at 0xba918e00 > ACPI: No SRAT table found > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81109000 > Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff81109370 <-- > kldload: unexpected relocation type 67108875 > kernel trap 12 with interrupts disabled > > The irritating detail is the load address of "zfs.ko", which is just > 0x370 bytes above the kernel load address ... That isn't unusual. Those are the addresses of the metadata provided by the loader, not the base address of the kernel or zfs.ko object themselves. The unexpected relocation type is interesting however. That value in hex is 0x400000b. 0xb is the R_X86_64_32S relocation type which is normal for the kernel. I think you just have a single-bit memory error due to a failing DIMM. > A verbose boot scrolls these lines off the screen to fast (and is to > long to be preserved in dmesg.boot from the start), so I do not have any > idea whether other values are reported in case of a successful boot. > > I had already assumed that memory was corrupted during early start-up, > but now I think that gptzfsboot writes the zfs kernel module over the > start of the loaded kernel. I'll try some more tests later today. Nah, if zfs.ko were loaded over the beginning of the kernel you wouldn't even get to the point of the first kernel printf. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 17:56:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCF8C1065670; Wed, 16 Nov 2011 17:56:04 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 708378FC16; Wed, 16 Nov 2011 17:56:04 +0000 (UTC) Received: by iakl21 with SMTP id l21so1361252iak.13 for ; Wed, 16 Nov 2011 09:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=kwR8P3jzT3WihS41hugqBDDN/+fdezlS87ibzEQbTMw=; b=NvMWQ2jG+6lKGCWJThA9XigC9nn8AMN/IGqi8D7nv8KxGTs0sbvpAboxbJkDjohdle CkUcmXo2X1uFKGHKZI5oU825cPICU3MYBc8ZIrMYz/aG6JOTw4jlcsbaVFctYKH7J0/j drvSYYSQqDK6Q3VzPmcPk4iuJhVNse2akyNyw= MIME-Version: 1.0 Received: by 10.42.135.69 with SMTP id o5mr33096228ict.34.1321464435209; Wed, 16 Nov 2011 09:27:15 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.243.198 with HTTP; Wed, 16 Nov 2011 09:27:15 -0800 (PST) Date: Wed, 16 Nov 2011 18:27:15 +0100 X-Google-Sender-Auth: g_ZVFk04DyEWnpXFv4YxJp4aN6o Message-ID: From: Robert Millan To: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Content-Type: multipart/mixed; boundary=90e6ba6e836c3e770904b1dd6a9a Cc: Kostik Belousov , Adrian Chadd Subject: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 17:56:04 -0000 --90e6ba6e836c3e770904b1dd6a9a Content-Type: text/plain; charset=UTF-8 Hi! Out of the kernel headers that are installed in /usr/include/ hierracy, there are some which include support multiple operating systems (usually FreeBSD and other *BSD flavours). This patch adds support to detect GNU/kFreeBSD as well. In all cases, we match the same declarations as FreeBSD does (which is to be expected in kernel headers, since both systems share the same kernel). Does it look fine? --90e6ba6e836c3e770904b1dd6a9a Content-Type: text/x-diff; charset=US-ASCII; name="gnu-kfreebsd_headers.diff" Content-Disposition: attachment; filename="gnu-kfreebsd_headers.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gv2lkl460 ZGlmZiAtdXIgc3lzLm9sZC9jYW0vc2NzaS9zY3NpX2xvdy5oIHN5cy9jYW0vc2NzaS9zY3NpX2xv dy5oCi0tLSBzeXMub2xkL2NhbS9zY3NpL3Njc2lfbG93LmgJMjAwNy0xMi0yNSAxODo1MjowMi4w MDAwMDAwMDAgKzAxMDAKKysrIHN5cy9jYW0vc2NzaS9zY3NpX2xvdy5oCTIwMTEtMTEtMTMgMTQ6 MTI6NDEuMTIxOTA4MzgwICswMTAwCkBAIC01Myw3ICs1Myw3IEBACiAjZGVmaW5lCVNDU0lfTE9X X0lOVEVSRkFDRV9YUwogI2VuZGlmCS8qIF9fTmV0QlNEX18gKi8KIAotI2lmZGVmCV9fRnJlZUJT RF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVs X18pCiAjZGVmaW5lCVNDU0lfTE9XX0lOVEVSRkFDRV9DQU0KICNkZWZpbmUJQ0FNCiAjZW5kaWYJ LyogX19GcmVlQlNEX18gKi8KQEAgLTY0LDcgKzY0LDcgQEAKICNpbmNsdWRlIDxkZXYvaXNhL2Nj YnF1ZS5oPgogI2VuZGlmCS8qIF9fTmV0QlNEX18gKi8KIAotI2lmZGVmCV9fRnJlZUJTRF9fCisj aWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiAj aW5jbHVkZSA8c3lzL2RldmljZV9wb3J0Lmg+CiAjaW5jbHVkZSA8c3lzL2tkYi5oPgogI2luY2x1 ZGUgPGNhbS9jYW0uaD4KQEAgLTg1LDcgKzg1LDcgQEAKICNkZWZpbmUJU0NTSV9MT1dfQlpFUk8o cHQsIHNpemUpCW1lbXNldCgocHQpLCAwLCAoc2l6ZSkpCiAjZW5kaWYJLyogX19OZXRCU0RfXyAq LwogCi0jaWZkZWYJX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZp bmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKICN1bmRlZglNU0dfSURFTlRJRlkKICNkZWZpbmUJU0NT SV9MT1dfREVCVUdHRVIoZGV2KQlrZGJfZW50ZXIoS0RCX1dIWV9DQU0sIGRldikKICNkZWZpbmUJ U0NTSV9MT1dfREVMQVkobXUpCURFTEFZKChtdSkpCkBAIC0xMTEsNyArMTExLDcgQEAKIH07CiAj ZW5kaWYJLyogX19OZXRCU0RfXyAqLwogCi0jaWZkZWYJX19GcmVlQlNEX18KKyNpZiBkZWZpbmVk KF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIHR5cGVkZWYJc3Ry dWN0IHNjc2lfc2Vuc2VfZGF0YSBzY3NpX2xvd19vc2RlcF9zZW5zZV9kYXRhX3Q7CiAKIHN0cnVj dCBzY3NpX2xvd19vc2RlcF9pbnRlcmZhY2UgewpkaWZmIC11ciBzeXMub2xkL2NhbS9zY3NpL3Nj c2lfbG93X3Bpc2EuaCBzeXMvY2FtL3Njc2kvc2NzaV9sb3dfcGlzYS5oCi0tLSBzeXMub2xkL2Nh bS9zY3NpL3Njc2lfbG93X3Bpc2EuaAkyMDA1LTAxLTA1IDIzOjM0OjM3LjAwMDAwMDAwMCArMDEw MAorKysgc3lzL2NhbS9zY3NpL3Njc2lfbG93X3Bpc2EuaAkyMDExLTExLTEzIDE0OjEyOjQxLjEy MTkwODM4MCArMDEwMApAQCAtNDAsNyArNDAsNyBAQAogaW50IHNjc2lfbG93X25vdGlmeV9waXNh KHBpc2FfZGV2aWNlX2hhbmRsZV90LCBwaXNhX2V2ZW50X3QpOwogI2VuZGlmCS8qIF9fTmV0QlNE X18gKi8KIAotI2lmZGVmCV9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwg ZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiBpbnQgc2NzaV9sb3dfYWN0aXZhdGVfcGlzYShz dHJ1Y3Qgc2NzaV9sb3dfc29mdGMgKiwgaW50KTsKIGludCBzY3NpX2xvd19kZWFjdGl2YXRlX3Bp c2Eoc3RydWN0IHNjc2lfbG93X3NvZnRjICopOwogI2VuZGlmCS8qIF9fRnJlZUJTRF9fICovCmRp ZmYgLXVyIHN5cy5vbGQvY29udHJpYi9hbHRxL2FsdHEvYWx0cV92YXIuaCBzeXMvY29udHJpYi9h bHRxL2FsdHEvYWx0cV92YXIuaAotLS0gc3lzLm9sZC9jb250cmliL2FsdHEvYWx0cS9hbHRxX3Zh ci5oCTIwMTEtMDMtMTAgMTk6NDk6MTUuMDAwMDAwMDAwICswMTAwCisrKyBzeXMvY29udHJpYi9h bHRxL2FsdHEvYWx0cV92YXIuaAkyMDExLTExLTEzIDE0OjEyOjQxLjExODkwNzM0MSArMDEwMApA QCAtMjAxLDcgKzIwMSw3IEBACiAjZGVmaW5lCUNBTExPVVRfU1RPUChjKQkJdW50aW1lb3V0KChj KS0+Y19mdW5jLChjKS0+Y19hcmcpCiAjZGVmaW5lCUNBTExPVVRfSU5JVElBTElaRVIJeyBOVUxM LCBOVUxMIH0KICNlbmRpZgotI2lmICFkZWZpbmVkKF9fRnJlZUJTRF9fKQorI2lmICFkZWZpbmVk KF9fRnJlZUJTRF9fKSAmJiAhZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiB0eXBlZGVmIHZv aWQgKHRpbWVvdXRfdCkodm9pZCAqKTsKICNlbmRpZgogCmRpZmYgLXVyIHN5cy5vbGQvY29udHJp Yi9hbHRxL2FsdHEvaWZfYWx0cS5oIHN5cy9jb250cmliL2FsdHEvYWx0cS9pZl9hbHRxLmgKLS0t IHN5cy5vbGQvY29udHJpYi9hbHRxL2FsdHEvaWZfYWx0cS5oCTIwMTEtMDMtMTAgMTk6NDk6MTUu MDAwMDAwMDAwICswMTAwCisrKyBzeXMvY29udHJpYi9hbHRxL2FsdHEvaWZfYWx0cS5oCTIwMTEt MTEtMTMgMTQ6MTI6NDEuMTE5OTA3MTI4ICswMTAwCkBAIC0yOSw3ICsyOSw3IEBACiAjaWZuZGVm IF9BTFRRX0lGX0FMVFFfSF8KICNkZWZpbmUJX0FMVFFfSUZfQUxUUV9IXwogCi0jaWZkZWYgX19G cmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9r ZXJuZWxfXykKICNpbmNsdWRlIDxzeXMvbG9jay5oPgkJLyogWFhYICovCiAjaW5jbHVkZSA8c3lz L211dGV4Lmg+CQkvKiBYWFggKi8KICNpbmNsdWRlIDxzeXMvZXZlbnQuaD4JCS8qIFhYWCAqLwpA QCAtNTEsNyArNTEsNyBAQAogCWludAlpZnFfbGVuOwogCWludAlpZnFfbWF4bGVuOwogCWludAlp ZnFfZHJvcHM7Ci0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8 fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIAlzdHJ1Y3QJbXR4IGlmcV9tdHg7CiAjZW5k aWYKIApkaWZmIC11ciBzeXMub2xkL2NvbnRyaWIvcGYvbmV0L2lmX3BmbG9nLmggc3lzL2NvbnRy aWIvcGYvbmV0L2lmX3BmbG9nLmgKLS0tIHN5cy5vbGQvY29udHJpYi9wZi9uZXQvaWZfcGZsb2cu aAkyMDExLTA2LTI4IDEzOjU3OjI1LjAwMDAwMDAwMCArMDIwMAorKysgc3lzL2NvbnRyaWIvcGYv bmV0L2lmX3BmbG9nLmgJMjAxMS0xMS0xMyAxNDoxMjo0MS4xMzA5MDY0NjkgKzAxMDAKQEAgLTMw LDcgKzMwLDcgQEAKICNkZWZpbmUJUEZMT0dJRlNfTUFYCTE2CiAKIHN0cnVjdCBwZmxvZ19zb2Z0 YyB7Ci0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZp bmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIAlzdHJ1Y3QgaWZuZXQJCSpzY19pZnA7CS8qIHRoZSBp bnRlcmZhY2UgcG9pbnRlciAqLwogI2Vsc2UKIAlzdHJ1Y3QgaWZuZXQJCXNjX2lmOwkJLyogdGhl IGludGVyZmFjZSAqLwpAQCAtNzQsNyArNzQsNyBAQAogI2RlZmluZQlPTERfUEZMT0dfSERSTEVO CXNpemVvZihzdHJ1Y3Qgb2xkX3BmbG9naGRyKQogCiAjaWZkZWYgX0tFUk5FTAotI2lmZGVmIF9f RnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rf a2VybmVsX18pCiBzdHJ1Y3QgcGZfcnVsZTsKIHN0cnVjdCBwZl9ydWxlc2V0Owogc3RydWN0IHBm aV9raWY7CmRpZmYgLXVyIHN5cy5vbGQvY29udHJpYi9wZi9uZXQvaWZfcGZsb3cuaCBzeXMvY29u dHJpYi9wZi9uZXQvaWZfcGZsb3cuaAotLS0gc3lzLm9sZC9jb250cmliL3BmL25ldC9pZl9wZmxv dy5oCTIwMTEtMDYtMjggMTM6NTc6MjUuMDAwMDAwMDAwICswMjAwCisrKyBzeXMvY29udHJpYi9w Zi9uZXQvaWZfcGZsb3cuaAkyMDExLTExLTEzIDE0OjEyOjQxLjEzMDkwNjQ2OSArMDEwMApAQCAt NjYsNyArNjYsNyBAQAogCXVuc2lnbmVkIGludAkJIHNjX21heGNvdW50OwogCXVfaW50NjRfdAkJ IHNjX2djb3VudGVyOwogCXN0cnVjdCBpcF9tb3B0aW9ucwkgc2NfaW1vOwotI2lmZGVmIF9fRnJl ZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2Vy bmVsX18pCiAJc3RydWN0IGNhbGxvdXQJCSBzY190bW87CiAjZWxzZQogCXN0cnVjdCB0aW1lb3V0 CQkgc2NfdG1vOwpkaWZmIC11ciBzeXMub2xkL2NvbnRyaWIvcGYvbmV0L2lmX3Bmc3luYy5oIHN5 cy9jb250cmliL3BmL25ldC9pZl9wZnN5bmMuaAotLS0gc3lzLm9sZC9jb250cmliL3BmL25ldC9p Zl9wZnN5bmMuaAkyMDExLTA2LTI4IDEzOjU3OjI1LjAwMDAwMDAwMCArMDIwMAorKysgc3lzL2Nv bnRyaWIvcGYvbmV0L2lmX3Bmc3luYy5oCTIwMTEtMTEtMTMgMTQ6MTI6NDEuMTMxOTA2MjU3ICsw MTAwCkBAIC0yNjgsNyArMjY4LDcgQEAKIAlpbnQJCSBwZnN5bmNyX2F1dGhsZXZlbDsKIH07CiAK LSNpZmRlZiBfX0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQo X19GcmVlQlNEX2tlcm5lbF9fKQogI2RlZmluZQlTSU9DU0VUUEZTWU5DICAgX0lPVygnaScsIDI0 Nywgc3RydWN0IGlmcmVxKQogI2RlZmluZQlTSU9DR0VUUEZTWU5DICAgX0lPV1IoJ2knLCAyNDgs IHN0cnVjdCBpZnJlcSkKICNlbmRpZgpAQCAtMjg4LDcgKzI4OCw3IEBACiAjZGVmaW5lCVBGU1lO Q19TX0RFRkVSCTB4ZmUKICNkZWZpbmUJUEZTWU5DX1NfTk9ORQkweGZmCiAKLSNpZmRlZiBfX0Zy ZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tl cm5lbF9fKQogdm9pZAkJCXBmc3luY19pbnB1dChzdHJ1Y3QgbWJ1ZiAqLCBfX3VudXNlZCBpbnQp OwogI2Vsc2UKIHZvaWQJCQlwZnN5bmNfaW5wdXQoc3RydWN0IG1idWYgKiwgLi4uKTsKQEAgLTMw MCw3ICszMDAsNyBAQAogI2RlZmluZQlQRlNZTkNfU0lfQ0tTVU0JCTB4MDIKICNkZWZpbmUJUEZT WU5DX1NJX0FDSwkJMHgwNAogaW50CQkJcGZzeW5jX3N0YXRlX2ltcG9ydChzdHJ1Y3QgcGZzeW5j X3N0YXRlICosIHVfaW50OF90KTsKLSNpZm5kZWYgX19GcmVlQlNEX18KKyNpZiAhZGVmaW5lZChf X0ZyZWVCU0RfXykgJiYgIWRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogdm9pZAkJCXBmc3lu Y19zdGF0ZV9leHBvcnQoc3RydWN0IHBmc3luY19zdGF0ZSAqLAogCQkJICAgIHN0cnVjdCBwZl9z dGF0ZSAqKTsKICNlbmRpZgpkaWZmIC11ciBzeXMub2xkL2NvbnRyaWIvcGYvbmV0L3BmdmFyLmgg c3lzL2NvbnRyaWIvcGYvbmV0L3BmdmFyLmgKLS0tIHN5cy5vbGQvY29udHJpYi9wZi9uZXQvcGZ2 YXIuaAkyMDExLTEwLTIzIDEyOjA1OjI1LjAwMDAwMDAwMCArMDIwMAorKysgc3lzL2NvbnRyaWIv cGYvbmV0L3BmdmFyLmgJMjAxMS0xMS0xMyAxNDoxMjo0MS4xMzQ5MDY3MzggKzAxMDAKQEAgLTM3 LDcgKzM3LDcgQEAKICNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KICNpbmNsdWRlIDxzeXMvcXVldWUu aD4KICNpbmNsdWRlIDxzeXMvdHJlZS5oPgotI2lmZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5l ZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiAjaW5jbHVkZSA8 c3lzL2xvY2suaD4KICNpbmNsdWRlIDxzeXMvc3guaD4KICNlbHNlCkBAIC00Niw3ICs0Niw3IEBA CiAKICNpbmNsdWRlIDxuZXQvcmFkaXguaD4KICNpbmNsdWRlIDxuZXQvcm91dGUuaD4KLSNpZmRl ZiBfX0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVl QlNEX2tlcm5lbF9fKQogI2luY2x1ZGUgPG5ldC9pZl9jbG9uZS5oPgogI2luY2x1ZGUgPG5ldC9w Zl9tdGFnLmg+CiAjaW5jbHVkZSA8dm0vdW1hLmg+CkBAIC01NCw3ICs1NCw3IEBACiAjaW5jbHVk ZSA8bmV0aW5ldC9pcF9pcHNwLmg+CiAjZW5kaWYKIAotI2lmZGVmIF9fRnJlZUJTRF9fCisjaWYg ZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiAjaW5j bHVkZSA8bmV0aW5ldC9pbi5oPgogI2VuZGlmCiAKQEAgLTYyLDcgKzYyLDcgQEAKIAogc3RydWN0 IGlwOwogc3RydWN0IGlwNl9oZHI7Ci0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9f RnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIHN0cnVjdCBpbnBjYjsK ICNlbmRpZgogCkBAIC0xNzMsNyArMTczLDcgQEAKIAkJfQkJCSBhOwogCQljaGFyCQkJIGlmbmFt ZVtJRk5BTVNJWl07CiAJCWNoYXIJCQkgdGJsbmFtZVtQRl9UQUJMRV9OQU1FX1NJWkVdOwotI2lm ZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0Zy ZWVCU0Rfa2VybmVsX18pCiAjZGVmaW5lCVJUTEFCRUxfTEVOCTMyCiAjZW5kaWYKIAkJY2hhcgkJ CSBydGxhYmVsbmFtZVtSVExBQkVMX0xFTl07CkBAIC0yMTEsNyArMjExLDcgQEAKICAqIEFkZHJl c3MgbWFuaXB1bGF0aW9uIG1hY3JvcwogICovCiAKLSNpZmRlZiBfX0ZyZWVCU0RfXworI2lmIGRl ZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogI2RlZmlu ZQlzcGxzb2Z0bmV0KCkJc3BsbmV0KCkKIAogI2RlZmluZQlIVE9OTCh4KQkoeCkgPSBodG9ubCgo X191aW50MzJfdCkoeCkpCkBAIC0yMzYsNyArMjM2LDcgQEAKIAlpZiAodmFyKQkJCQkJXAogCQl1 bWFfemRlc3Ryb3kodmFyKQogCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJl ZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIGV4dGVybiBzdHJ1Y3QgbXR4 IHBmX3Rhc2tfbXR4OwogCiAjZGVmaW5lCVBGX0xPQ0tfQVNTRVJUKCkJbXR4X2Fzc2VydCgmcGZf dGFza19tdHgsIE1BX09XTkVEKQpAQCAtODMzLDcgKzgzMyw3IEBACiAJdV9pbnQ2NF90CQkgaWQ7 CiAJdV9pbnQzMl90CQkgY3JlYXRvcmlkOwogCXVfaW50OF90CQkgZGlyZWN0aW9uOwotI2lmZGVm IF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVC U0Rfa2VybmVsX18pCiAJdV9pbnQ4X3QJCSBwYWRbMl07CiAJdV9pbnQ4X3QJCSBsb2NhbF9mbGFn czsKICNkZWZpbmUJUEZTVEFURV9FWFBJUklORyAweDAxCkBAIC05MjMsNyArOTIzLDcgQEAKIAlz YV9mYW1pbHlfdAkgYWY7CiAJdV9pbnQ4X3QJIHByb3RvOwogCXVfaW50OF90CSBkaXJlY3Rpb247 Ci0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVk KF9fRnJlZUJTRF9rZXJuZWxfXykKIAl1X2ludDhfdAkgbG9jYWxfZmxhZ3M7CiAjZGVmaW5lCVBG U1RBVEVfRVhQSVJJTkcJCTB4MDEKIAl1X2ludDhfdAkgcGFkOwpAQCAtOTM1LDcgKzkzNSw3IEBA CiAJdV9pbnQ4X3QJIHVwZGF0ZXM7CiB9IF9fcGFja2VkOwogCi0jaWZkZWYgX19GcmVlQlNEX18K KyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykK ICNpZmRlZiBfS0VSTkVMCiAvKiBwZnN5bmMgKi8KIHR5cGVkZWYgaW50CQlwZnN5bmNfc3RhdGVf aW1wb3J0X3Qoc3RydWN0IHBmc3luY19zdGF0ZSAqLCB1X2ludDhfdCk7CkBAIC0xMjE1LDcgKzEy MTUsNyBAQAogUkJfSEVBRChwZmlfaWZoZWFkLCBwZmlfa2lmKTsKIAogLyogc3RhdGUgdGFibGVz ICovCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZp bmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKICNpZmRlZiBfS0VSTkVMCiBWTkVUX0RFQ0xBUkUoc3Ry dWN0IHBmX3N0YXRlX3RyZWUsCSBwZl9zdGF0ZXRibCk7CiAjZGVmaW5lCVZfcGZfc3RhdGV0YmwJ CQkgVk5FVChwZl9zdGF0ZXRibCkKQEAgLTEyNzcsNyArMTI3Nyw3IEBACiAJc3RydWN0IHBmX2Fk ZHIJKmRzdDsJCS8qIGRzdCBhZGRyZXNzICovCiAJdV9pbnQxNl90ICpzcG9ydDsKIAl1X2ludDE2 X3QgKmRwb3J0OwotI2lmZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykg fHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiAJc3RydWN0IHBmX210YWcJKnBmX210YWc7 CiAjZW5kaWYKIApAQCAtMTQwMyw3ICsxNDAzLDcgQEAKIAkJCSooYSkgPSAoeCk7IFwKIAl9IHdo aWxlICgwKQogCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8 fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKICNkZWZpbmUgUkVBU09OX1NFVChhLCB4KSBc CiAJZG8geyBcCiAJCWlmICgoYSkgIT0gTlVMTCkgXApAQCAtMTQ4OCw3ICsxNDg4LDcgQEAKIAl1 X2ludDMyX3QJCSBwYXJlbnRfcWlkOwkvKiBwYXJlbnQgcXVldWUgaWQgKi8KIAl1X2ludDMyX3QJ CSBiYW5kd2lkdGg7CS8qIHF1ZXVlIGJhbmR3aWR0aCAqLwogCXVfaW50OF90CQkgcHJpb3JpdHk7 CS8qIHByaW9yaXR5ICovCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJT RF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIAl1X2ludDhfdAkJIGxvY2FsX2Zs YWdzOwkvKiBkeW5hbWljIGludGVyZmFjZSAqLwogI2RlZmluZQlQRkFMVFFfRkxBR19JRl9SRU1P VkVECQkweDAxCiAjZW5kaWYKQEAgLTE3NjgsNyArMTc2OCw3IEBACiAjZGVmaW5lCURJT0NTRVRJ RkZMQUcJX0lPV1IoJ0QnLCA4OSwgc3RydWN0IHBmaW9jX2lmYWNlKQogI2RlZmluZQlESU9DQ0xS SUZGTEFHCV9JT1dSKCdEJywgOTAsIHN0cnVjdCBwZmlvY19pZmFjZSkKICNkZWZpbmUJRElPQ0tJ TExTUkNOT0RFUwlfSU9XUignRCcsIDkxLCBzdHJ1Y3QgcGZpb2Nfc3JjX25vZGVfa2lsbCkKLSNp ZmRlZiBfX0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19G cmVlQlNEX2tlcm5lbF9fKQogc3RydWN0IHBmX2lmc3BlZWQgewogCWNoYXIJCQlpZm5hbWVbSUZO QU1TSVpdOwogCXVfaW50MzJfdAkJYmF1ZHJhdGU7CkBAIC0xNzc5LDcgKzE3NzksNyBAQAogI2lm ZGVmIF9LRVJORUwKIFJCX0hFQUQocGZfc3JjX3RyZWUsIHBmX3NyY19ub2RlKTsKIFJCX1BST1RP VFlQRShwZl9zcmNfdHJlZSwgcGZfc3JjX25vZGUsIGVudHJ5LCBwZl9zcmNfY29tcGFyZSk7Ci0j aWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9f RnJlZUJTRF9rZXJuZWxfXykKIFZORVRfREVDTEFSRShzdHJ1Y3QgcGZfc3JjX3RyZWUsCSB0cmVl X3NyY190cmFja2luZyk7CiAjZGVmaW5lCVZfdHJlZV9zcmNfdHJhY2tpbmcJCSBWTkVUKHRyZWVf c3JjX3RyYWNraW5nKQogI2Vsc2UKQEAgLTE3ODksNyArMTc4OSw3IEBACiBSQl9IRUFEKHBmX3N0 YXRlX3RyZWVfaWQsIHBmX3N0YXRlKTsKIFJCX1BST1RPVFlQRShwZl9zdGF0ZV90cmVlX2lkLCBw Zl9zdGF0ZSwKICAgICBlbnRyeV9pZCwgcGZfc3RhdGVfY29tcGFyZV9pZCk7Ci0jaWZkZWYgX19G cmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9r ZXJuZWxfXykKIFZORVRfREVDTEFSRShzdHJ1Y3QgcGZfc3RhdGVfdHJlZV9pZCwJIHRyZWVfaWQp OwogI2RlZmluZQlWX3RyZWVfaWQJCQkgVk5FVCh0cmVlX2lkKQogVk5FVF9ERUNMQVJFKHN0cnVj dCBwZl9zdGF0ZV9xdWV1ZSwJIHN0YXRlX2xpc3QpOwpAQCAtMTgwMCwxNCArMTgwMCwxNCBAQAog I2VuZGlmCiAKIFRBSUxRX0hFQUQocGZfcG9vbHF1ZXVlLCBwZl9wb29sKTsKLSNpZmRlZiBfX0Zy ZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tl cm5lbF9fKQogVk5FVF9ERUNMQVJFKHN0cnVjdCBwZl9wb29scXVldWUsCSBwZl9wb29sc1syXSk7 CiAjZGVmaW5lCVZfcGZfcG9vbHMJCQkgVk5FVChwZl9wb29scykKICNlbHNlCiBleHRlcm4gc3Ry dWN0IHBmX3Bvb2xxdWV1ZQkJICBwZl9wb29sc1syXTsKICNlbmRpZgogVEFJTFFfSEVBRChwZl9h bHRxcXVldWUsIHBmX2FsdHEpOwotI2lmZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0Zy ZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiBWTkVUX0RFQ0xBUkUoc3Ry dWN0IHBmX2FsdHFxdWV1ZSwJIHBmX2FsdHFzWzJdKTsKICNkZWZpbmUJVl9wZl9hbHRxcwkJCSBW TkVUKHBmX2FsdHFzKQogVk5FVF9ERUNMQVJFKHN0cnVjdCBwZl9wYWxpc3QsCQkgcGZfcGFidWYp OwpAQCAtMTgxNyw3ICsxODE3LDcgQEAKIGV4dGVybiBzdHJ1Y3QgcGZfcGFsaXN0CQkJICBwZl9w YWJ1ZjsKICNlbmRpZgogCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJT RF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIFZORVRfREVDTEFSRSh1X2ludDMy X3QsCQkJIHRpY2tldF9hbHRxc19hY3RpdmUpOwogI2RlZmluZQlWX3RpY2tldF9hbHRxc19hY3Rp dmUJCSBWTkVUKHRpY2tldF9hbHRxc19hY3RpdmUpCiBWTkVUX0RFQ0xBUkUodV9pbnQzMl90LAkJ CSB0aWNrZXRfYWx0cXNfaW5hY3RpdmUpOwpAQCAtMTg0OSw3ICsxODQ5LDcgQEAKIGV4dGVybiB2 b2lkCQkJIHBmX3RibGFkZHJfcmVtb3ZlKHN0cnVjdCBwZl9hZGRyX3dyYXAgKik7CiBleHRlcm4g dm9pZAkJCSBwZl90YmxhZGRyX2NvcHlvdXQoc3RydWN0IHBmX2FkZHJfd3JhcCAqKTsKIGV4dGVy biB2b2lkCQkJIHBmX2NhbGNfc2tpcF9zdGVwcyhzdHJ1Y3QgcGZfcnVsZXF1ZXVlICopOwotI2lm ZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0Zy ZWVCU0Rfa2VybmVsX18pCiAjaWZkZWYgQUxUUQogZXh0ZXJuCXZvaWQJCQkgcGZfYWx0cV9pZm5l dF9ldmVudChzdHJ1Y3QgaWZuZXQgKiwgaW50KTsKICNlbmRpZgpAQCAtMTg4Niw3ICsxODg2LDcg QEAKIGV4dGVybiBzdHJ1Y3QgcG9vbAkJIHBmX3N0YXRlX3NjcnViX3BsOwogI2VuZGlmCiBleHRl cm4gdm9pZAkJCSBwZl9wdXJnZV90aHJlYWQodm9pZCAqKTsKLSNpZmRlZiBfX0ZyZWVCU0RfXwor I2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKQog ZXh0ZXJuIGludAkJCSBwZl9wdXJnZV9leHBpcmVkX3NyY19ub2RlcyhpbnQpOwogZXh0ZXJuIGlu dAkJCSBwZl9wdXJnZV9leHBpcmVkX3N0YXRlcyh1X2ludDMyX3QgLCBpbnQpOwogI2Vsc2UKQEAg LTE5MTEsNyArMTkxMSw3IEBACiBleHRlcm4gdV9pbnQxNl90CQkgcGZfY2tzdW1fZml4dXAodV9p bnQxNl90LCB1X2ludDE2X3QsIHVfaW50MTZfdCwKIAkJCQkgICAgdV9pbnQ4X3QpOwogCi0jaWZk ZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJl ZUJTRF9rZXJuZWxfXykKIFZORVRfREVDTEFSRShzdHJ1Y3QgaWZuZXQgKiwJCSBzeW5jX2lmcCk7 CiAjZGVmaW5lCVZfc3luY19pZnAJCSAJIFZORVQoc3luY19pZnApOwogVk5FVF9ERUNMQVJFKHN0 cnVjdCBwZl9ydWxlLAkJIHBmX2RlZmF1bHRfcnVsZSk7CkBAIC0xOTI0LDEyICsxOTI0LDEyIEBA CiAJCQkJICAgIHVfaW50OF90KTsKIHZvaWQJCQkJIHBmX3JtX3J1bGUoc3RydWN0IHBmX3J1bGVx dWV1ZSAqLAogCQkJCSAgICBzdHJ1Y3QgcGZfcnVsZSAqKTsKLSNpZm5kZWYgX19GcmVlQlNEX18K KyNpZiAhZGVmaW5lZChfX0ZyZWVCU0RfXykgJiYgIWRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9f KQogc3RydWN0IHBmX2RpdmVydAkJKnBmX2ZpbmRfZGl2ZXJ0KHN0cnVjdCBtYnVmICopOwogI2Vu ZGlmCiAKICNpZmRlZiBJTkVUCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJl ZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIGludAlwZl90ZXN0KGludCwg c3RydWN0IGlmbmV0ICosIHN0cnVjdCBtYnVmICoqLCBzdHJ1Y3QgZXRoZXJfaGVhZGVyICosCiAg ICAgc3RydWN0IGlucGNiICopOwogI2Vsc2UKQEAgLTE5MzgsNyArMTkzOCw3IEBACiAjZW5kaWYg LyogSU5FVCAqLwogCiAjaWZkZWYgSU5FVDYKLSNpZmRlZiBfX0ZyZWVCU0RfXworI2lmIGRlZmlu ZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogaW50CXBmX3Rl c3Q2KGludCwgc3RydWN0IGlmbmV0ICosIHN0cnVjdCBtYnVmICoqLCBzdHJ1Y3QgZXRoZXJfaGVh ZGVyICosCiAgICAgc3RydWN0IGlucGNiICopOwogI2Vsc2UKQEAgLTE5NDksNyArMTk0OSw3IEBA CiB2b2lkCXBmX2FkZHJfaW5jKHN0cnVjdCBwZl9hZGRyICosIHNhX2ZhbWlseV90KTsKICNlbmRp ZiAvKiBJTkVUNiAqLwogCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJT RF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIHVfaW50MzJfdAlwZl9uZXdfaXNu KHN0cnVjdCBwZl9zdGF0ZSAqKTsKICNlbmRpZgogdm9pZCAgICpwZl9wdWxsX2hkcihzdHJ1Y3Qg bWJ1ZiAqLCBpbnQsIHZvaWQgKiwgaW50LCB1X3Nob3J0ICosIHVfc2hvcnQgKiwKQEAgLTE5ODYs NyArMTk4Niw3IEBACiB2b2lkCXBmX3B1cmdlX2V4cGlyZWRfZnJhZ21lbnRzKHZvaWQpOwogaW50 CXBmX3JvdXRhYmxlKHN0cnVjdCBwZl9hZGRyICphZGRyLCBzYV9mYW1pbHlfdCBhZiwgc3RydWN0 IHBmaV9raWYgKik7CiBpbnQJcGZfcnRsYWJlbF9tYXRjaChzdHJ1Y3QgcGZfYWRkciAqLCBzYV9m YW1pbHlfdCwgc3RydWN0IHBmX2FkZHJfd3JhcCAqKTsKLSNpZmRlZiBfX0ZyZWVCU0RfXworI2lm IGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogaW50 CXBmX3NvY2tldF9sb29rdXAoaW50LCBzdHJ1Y3QgcGZfcGRlc2MgKiwgIHN0cnVjdCBpbnBjYiAq KTsKICNlbHNlCiBpbnQJcGZfc29ja2V0X2xvb2t1cChpbnQsIHN0cnVjdCBwZl9wZGVzYyAqKTsK QEAgLTIwMzEsNyArMjAzMSw3IEBACiBpbnQJcGZyX2luYV9kZWZpbmUoc3RydWN0IHBmcl90YWJs ZSAqLCBzdHJ1Y3QgcGZyX2FkZHIgKiwgaW50LCBpbnQgKiwKIAkgICAgaW50ICosIHVfaW50MzJf dCwgaW50KTsKIAotI2lmZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykg fHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiBWTkVUX0RFQ0xBUkUoc3RydWN0IHBmaV9r aWYgKiwJCSBwZmlfYWxsKTsKICNkZWZpbmUJVl9wZmlfYWxsCSAJCSBWTkVUKHBmaV9hbGwpCiAj ZWxzZQpAQCAtMjAzOSw3ICsyMDM5LDcgQEAKICNlbmRpZgogCiB2b2lkCQkgcGZpX2luaXRpYWxp emUodm9pZCk7Ci0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8 fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIHZvaWQJCSBwZmlfY2xlYW51cCh2b2lkKTsK ICNlbmRpZgogc3RydWN0IHBmaV9raWYJKnBmaV9raWZfZ2V0KGNvbnN0IGNoYXIgKik7CkBAIC0y MDYxLDcgKzIwNjEsNyBAQAogaW50CQkgcGZpX3NldF9mbGFncyhjb25zdCBjaGFyICosIGludCk7 CiBpbnQJCSBwZmlfY2xlYXJfZmxhZ3MoY29uc3QgY2hhciAqLCBpbnQpOwogCi0jaWZkZWYgX19G cmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9r ZXJuZWxfXykKIGludAkJIHBmX21hdGNoX3RhZyhzdHJ1Y3QgbWJ1ZiAqLCBzdHJ1Y3QgcGZfcnVs ZSAqLCBpbnQgKiwKIAkJICAgIHN0cnVjdCBwZl9tdGFnICopOwogI2Vsc2UKQEAgLTIwNzEsNyAr MjA3MSw3IEBACiB2b2lkCQkgcGZfdGFnMnRhZ25hbWUodV9pbnQxNl90LCBjaGFyICopOwogdm9p ZAkJIHBmX3RhZ19yZWYodV9pbnQxNl90KTsKIHZvaWQJCSBwZl90YWdfdW5yZWYodV9pbnQxNl90 KTsKLSNpZmRlZiBfX0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmlu ZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogaW50CQkgcGZfdGFnX3BhY2tldChzdHJ1Y3QgbWJ1ZiAq LCBpbnQsIGludCwgc3RydWN0IHBmX210YWcgKik7CiAjZWxzZQogaW50CQkgcGZfdGFnX3BhY2tl dChzdHJ1Y3QgbWJ1ZiAqLCBpbnQsIGludCk7CkBAIC0yMDgwLDE0ICsyMDgwLDE0IEBACiB2b2lk CQkgcGZfcWlkMnFuYW1lKHVfaW50MzJfdCwgY2hhciAqKTsKIHZvaWQJCSBwZl9xaWRfdW5yZWYo dV9pbnQzMl90KTsKIAotI2lmZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0Rf XykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pCiBWTkVUX0RFQ0xBUkUoc3RydWN0IHBm X3N0YXR1cywJCSBwZl9zdGF0dXMpOwogI2RlZmluZQlWX3BmX3N0YXR1cwkJCSBWTkVUKHBmX3N0 YXR1cykKICNlbHNlCiBleHRlcm4gc3RydWN0IHBmX3N0YXR1cwlwZl9zdGF0dXM7CiAjZW5kaWYK IAotI2lmZGVmIF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5l ZChfX0ZyZWVCU0Rfa2VybmVsX18pCiBWTkVUX0RFQ0xBUkUodW1hX3pvbmVfdCwJCSBwZl9mcmVu dF9wbCk7CiAjZGVmaW5lCVZfcGZfZnJlbnRfcGwJCQkgVk5FVChwZl9mcmVudF9wbCkKIFZORVRf REVDTEFSRSh1bWFfem9uZV90LAkJIHBmX2ZyYWdfcGwpOwpAQCAtMjEwMywxNCArMjEwMywxNCBA QAogCXZvaWQJCSpwcDsKIAl1bnNpZ25lZAkgbGltaXQ7CiB9OwotI2lmZGVmIF9fRnJlZUJTRF9f CisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18p CiBWTkVUX0RFQ0xBUkUoc3RydWN0IHBmX3Bvb2xfbGltaXQsCQkgcGZfcG9vbF9saW1pdHNbUEZf TElNSVRfTUFYXSk7CiAjZGVmaW5lCVZfcGZfcG9vbF9saW1pdHMJCQkgVk5FVChwZl9wb29sX2xp bWl0cykKICNlbHNlCiBleHRlcm4gc3RydWN0IHBmX3Bvb2xfbGltaXQJcGZfcG9vbF9saW1pdHNb UEZfTElNSVRfTUFYXTsKICNlbmRpZgogCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVk KF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIHN0cnVjdCBwZl9m cmVudCB7CiAJTElTVF9FTlRSWShwZl9mcmVudCkgZnJfbmV4dDsKIAlzdHJ1Y3QgaXAgKmZyX2lw OwpAQCAtMjE0NCw3ICsyMTQ0LDcgQEAKIAogI2VuZGlmIC8qIF9LRVJORUwgKi8KIAotI2lmZGVm IF9fRnJlZUJTRF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVC U0Rfa2VybmVsX18pCiAjaWZkZWYgX0tFUk5FTAogVk5FVF9ERUNMQVJFKHN0cnVjdCBwZl9hbmNo b3JfZ2xvYmFsLAkJIHBmX2FuY2hvcnMpOwogI2RlZmluZQlWX3BmX2FuY2hvcnMJCQkJIFZORVQo cGZfYW5jaG9ycykKQEAgLTIxNzIsNyArMjE3Miw3IEBACiBzdHJ1Y3QgcGZfcnVsZXNldAkqcGZf ZmluZF9vcl9jcmVhdGVfcnVsZXNldChjb25zdCBjaGFyICopOwogdm9pZAkJCSBwZl9yc19pbml0 aWFsaXplKHZvaWQpOwogCi0jaWZuZGVmIF9fRnJlZUJTRF9fCisjaWYgIWRlZmluZWQoX19GcmVl QlNEX18pICYmICFkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKICNpZmRlZiBfS0VSTkVMCiBp bnQJCQkgcGZfYW5jaG9yX2NvcHlvdXQoY29uc3Qgc3RydWN0IHBmX3J1bGVzZXQgKiwKIAkJCSAg ICBjb25zdCBzdHJ1Y3QgcGZfcnVsZSAqLCBzdHJ1Y3QgcGZpb2NfcnVsZSAqKTsKQEAgLTIxOTMs NyArMjE5Myw3IEBACiAJICAgIGNvbnN0IHN0cnVjdCB0Y3BoZHIgKik7CiB2b2lkCXBmX29zZnBf Zmx1c2godm9pZCk7CiBpbnQJcGZfb3NmcF9nZXQoc3RydWN0IHBmX29zZnBfaW9jdGwgKik7Ci0j aWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9f RnJlZUJTRF9rZXJuZWxfXykKIGludAlwZl9vc2ZwX2luaXRpYWxpemUodm9pZCk7CiB2b2lkCXBm X29zZnBfY2xlYW51cCh2b2lkKTsKICNlbHNlCmRpZmYgLXVyIHN5cy5vbGQvZGV2L2ZpcmV3aXJl L2ZpcmV3aXJlcmVnLmggc3lzL2Rldi9maXJld2lyZS9maXJld2lyZXJlZy5oCi0tLSBzeXMub2xk L2Rldi9maXJld2lyZS9maXJld2lyZXJlZy5oCTIwMDctMDctMjAgMDU6NDI6NTcuMDAwMDAwMDAw ICswMjAwCisrKyBzeXMvZGV2L2ZpcmV3aXJlL2ZpcmV3aXJlcmVnLmgJMjAxMS0xMS0xMyAxNDox Mjo0MS4xMjI5MDc2MDkgKzAxMDAKQEAgLTc1LDcgKzc1LDcgQEAKIH07CiAKIHN0cnVjdCBmaXJl d2lyZV9zb2Z0YyB7Ci0jaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgJiYgX19GcmVlQlNEX3ZlcnNp b24gPj0gNTAwMDAwCisjaWYgKGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVl QlNEX2tlcm5lbF9fKSkgJiYgX19GcmVlQlNEX3ZlcnNpb24gPj0gNTAwMDAwCiAJc3RydWN0IGNk ZXYgKmRldjsKICNlbmRpZgogCXN0cnVjdCBmaXJld2lyZV9jb21tICpmYzsKZGlmZiAtdXIgc3lz Lm9sZC9kZXYvbG1jL2lmX2xtYy5oIHN5cy9kZXYvbG1jL2lmX2xtYy5oCi0tLSBzeXMub2xkL2Rl di9sbWMvaWZfbG1jLmgJMjAwOS0xMS0xOSAxOToyMTo1MS4wMDAwMDAwMDAgKzAxMDAKKysrIHN5 cy9kZXYvbG1jL2lmX2xtYy5oCTIwMTEtMTEtMTMgMTQ6MTI6NDEuMTI0OTA4MzAyICswMTAwCkBA IC05ODQsNyArOTg0LDcgQEAKICNlbmRpZgogICB1X2ludDMyX3QgYWRkcmVzczE7CQkvKiBidWZm ZXIxIGJ1cyBhZGRyZXNzICovCiAgIHVfaW50MzJfdCBhZGRyZXNzMjsJCS8qIGJ1ZmZlcjIgYnVz IGFkZHJlc3MgKi8KLSNpZiAoZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX05ldEJT RF9fKSB8fCBkZWZpbmVkKF9fT3BlbkJTRF9fKSkKKyNpZiAoZGVmaW5lZChfX0ZyZWVCU0RfXykg fHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pIHx8IGRlZmluZWQoX19OZXRCU0RfXykgfHwg ZGVmaW5lZChfX09wZW5CU0RfXykpCiAgIGJ1c19kbWFtYXBfdCBtYXA7CQkvKiBidXMgZG1hbWFw IGZvciB0aGlzIGRlc2NyaXB0b3IgKi8KICMgZGVmaW5lIFRMUF9CVVNfRFNMX1ZBTAkoc2l6ZW9m KGJ1c19kbWFtYXBfdCkgJiBUTFBfQlVTX0RTTCkKICNlbHNlCkBAIC0xMDM1LDcgKzEwMzUsNyBA QAogI2VsaWYgQlNECiAgIHN0cnVjdCBtYnVmICpoZWFkOwkJLyogdGFpbC1xdWV1ZSBvZiBtYnVm cyAqLwogICBzdHJ1Y3QgbWJ1ZiAqdGFpbDsKLSMgaWYgKGRlZmluZWQoX19GcmVlQlNEX18pIHx8 IGRlZmluZWQoX19OZXRCU0RfXykgfHwgZGVmaW5lZChfX09wZW5CU0RfXykpCisjIGlmIChkZWZp bmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykgfHwgZGVmaW5l ZChfX05ldEJTRF9fKSB8fCBkZWZpbmVkKF9fT3BlbkJTRF9fKSkKICAgYnVzX2RtYV90YWdfdCB0 YWc7CQkvKiBidXNfZG1hIHRhZyBmb3IgZGVzYyBhcnJheSAqLwogICBidXNfZG1hbWFwX3QgbWFw OwkJLyogYnVzX2RtYSBtYXAgZm9yIGRlc2MgYXJyYXkgKi8KICAgYnVzX2RtYV9zZWdtZW50X3Qg c2Vnc1syXTsJLyogYnVzX2RtYW1hcF9sb2FkKCkgb3IgYnVzX2RtYW1lbV9hbGxvYygpICovCkBA IC0xMDY4LDcgKzEwNjgsNyBAQAogICovCiAjZGVmaW5lIElPUkVGX0NTUiAxICAvKiBhY2Nlc3Mg VHVsaXAgQ1NScyB3aXRoIElPIGN5Y2xlcyBpZiAxICovCiAKLSNpZiAoZGVmaW5lZChfX0ZyZWVC U0RfXykgJiYgZGVmaW5lZChERVZJQ0VfUE9MTElORykpCisjaWYgKChkZWZpbmVkKF9fRnJlZUJT RF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykpICYmIGRlZmluZWQoREVWSUNFX1BP TExJTkcpKQogIyBkZWZpbmUgREVWX1BPTEwgMQogI2Vsc2UKICMgZGVmaW5lIERFVl9QT0xMIDAK QEAgLTExNTEsNyArMTE1MSw3IEBACiAjIGVuZGlmCiAjZW5kaWYKIAotI2lmZGVmIF9fRnJlZUJT RF9fCisjaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVs X18pCiAgIHN0cnVjdCBjYWxsb3V0IGNhbGxvdXQ7CS8qIHdhdGNoZG9nIG5lZWRzIHRoaXMgICAg ICAgICAgICAgICAgICAqLwogICBzdHJ1Y3QgZGV2aWNlCSpkZXY7CQkvKiBiYXNlIGRldmljZSBw b2ludGVyICAgICAgICAgICAgICAgICAgICAgKi8KICAgYnVzX3NwYWNlX3RhZ190IGNzcl90YWc7 CS8qIGJ1c19zcGFjZSBuZWVkcyB0aGlzICAgICAgICAgICAgICAgICAgICAqLwpAQCAtMTIxMCw3 ICsxMjEwLDcgQEAKIAogLyogSGlkZSB0aGUgbWlub3IgZGlmZmVyZW5jZXMgYmV0d2VlbiBPUyB2 ZXJzaW9ucyAqLwogCi0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9f KSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKICAgdHlwZWRlZiB2b2lkIGludHJfcmV0 dXJuX3Q7CiAjIGRlZmluZSAgUkVBRF9QQ0lfQ0ZHKHNjLCBhZGRyKSAgICAgICBwY2lfcmVhZF9j b25maWcgKChzYyktPmRldiwgYWRkciwgNCkKICMgZGVmaW5lIFdSSVRFX1BDSV9DRkcoc2MsIGFk ZHIsIGRhdGEpIHBjaV93cml0ZV9jb25maWcoKHNjKS0+ZGV2LCBhZGRyLCBkYXRhLCA0KQpAQCAt MTQyOCw3ICsxNDI4LDcgQEAKICNlbmRpZgogCiAjaWYgKGRlZmluZWQoX19ic2RpX18pIHx8IC8q IHVuY29uZGl0aW9uYWxseSAqLyBcCi0gICAgKGRlZmluZWQoX19GcmVlQlNEX18pICYmIChfX0Zy ZWVCU0RfdmVyc2lvbiA8IDUwMzAwMCkpIHx8IFwKKyAgICAoKGRlZmluZWQoX19GcmVlQlNEX18p IHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKSkgJiYgKF9fRnJlZUJTRF92ZXJzaW9uIDwg NTAzMDAwKSkgfHwgXAogICAgIChkZWZpbmVkKF9fTmV0QlNEX18pICAmJiAoX19OZXRCU0RfVmVy c2lvbl9fIDwgMTA2MDAwMDAwKSkgfHwgXAogICAgIChkZWZpbmVkKF9fT3BlbkJTRF9fKSAmJiAo ICBPcGVuQlNEIDwgMjAwMTExKSkpCiAjIGRlZmluZSBJRlFfRU5RVUVVRShpZnEsIG0sIHBhLCBl cnIpICAgXApAQCAtMTUzMSw3ICsxNTMxLDcgQEAKIHN0YXRpYyBpbnQgIHQxX2lvY3RsKHNvZnRj X3QgKiwgc3RydWN0IGlvY3RsICopOwogCiAjaWYgSUZORVQKLSMgaWYgKChkZWZpbmVkKF9fRnJl ZUJTRF9fKSAmJiAoX19GcmVlQlNEX3ZlcnNpb24gPCA1MDAwMDApKSB8fFwKKyMgaWYgKCgoZGVm aW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pKSAmJiBfX0Zy ZWVCU0RfdmVyc2lvbiA8IDUwMDAwMCkgfHxcCiAgICAgICAgIGRlZmluZWQoX19OZXRCU0RfXykg fHwgZGVmaW5lZChfX09wZW5CU0RfXykgfHwgZGVmaW5lZChfX2JzZGlfXykpCiBzdGF0aWMgdm9p ZCBuZXRpc3JfZGlzcGF0Y2goaW50LCBzdHJ1Y3QgbWJ1ZiAqKTsKICMgZW5kaWYKQEAgLTE1NDEs NyArMTU0MSw3IEBACiAjaWYgQlNECiBzdGF0aWMgdm9pZCBtYnVmX2VucXVldWUoc3RydWN0IGRl c2NfcmluZyAqLCBzdHJ1Y3QgbWJ1ZiAqKTsKIHN0YXRpYyBzdHJ1Y3QgbWJ1ZiogbWJ1Zl9kZXF1 ZXVlKHN0cnVjdCBkZXNjX3JpbmcgKik7Ci0jIGlmZGVmIF9fRnJlZUJTRF9fCisjIGlmIGRlZmlu ZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogc3RhdGljIHZv aWQgZmJzZF9kbWFtYXBfbG9hZCh2b2lkICosIGJ1c19kbWFfc2VnbWVudF90ICosIGludCwgaW50 KTsKICMgZW5kaWYKIHN0YXRpYyBpbnQgY3JlYXRlX3Jpbmcoc29mdGNfdCAqLCBzdHJ1Y3QgZGVz Y19yaW5nICosIGludCk7CkBAIC0xNTcwLDcgKzE1NzAsNyBAQAogc3RhdGljIHZvaWQgY29yZV9p bnRlcnJ1cHQodm9pZCAqLCBpbnQpOwogc3RhdGljIHZvaWQgdXNlcl9pbnRlcnJ1cHQoc29mdGNf dCAqLCBpbnQpOwogI2lmIEJTRAotIyBpZiAoZGVmaW5lZChfX0ZyZWVCU0RfXykgJiYgZGVmaW5l ZChERVZJQ0VfUE9MTElORykpCisjIGlmIChkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVk KF9fRnJlZUJTRF9rZXJuZWxfXykpICYmIGRlZmluZWQoREVWSUNFX1BPTExJTkcpCiBzdGF0aWMg aW50IGZic2RfcG9sbChzdHJ1Y3QgaWZuZXQgKiwgZW51bSBwb2xsX2NtZCwgaW50KTsKICMgZW5k aWYKIHN0YXRpYyBpbnRyX3JldHVybl90IGJzZF9pbnRlcnJ1cHQodm9pZCAqKTsKQEAgLTE2Mzgs NyArMTYzOCw3IEBACiBzdGF0aWMgaW50IGF0dGFjaF9jYXJkKHNvZnRjX3QgKiwgY29uc3QgY2hh ciAqKTsKIHN0YXRpYyB2b2lkIGRldGFjaF9jYXJkKHNvZnRjX3QgKik7CiAKLSNpZmRlZiBfX0Zy ZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tl cm5lbF9fKQogc3RhdGljIGludCBmYnNkX3Byb2JlKGRldmljZV90KTsKIHN0YXRpYyBpbnQgZmJz ZF9kZXRhY2goZGV2aWNlX3QpOwogc3RhdGljIGludCBmYnNkX3NodXRkb3duKGRldmljZV90KTsK ZGlmZiAtdXIgc3lzLm9sZC9kZXYvbXB0L21waWxpYi9tcGlfdHlwZS5oIHN5cy9kZXYvbXB0L21w aWxpYi9tcGlfdHlwZS5oCi0tLSBzeXMub2xkL2Rldi9tcHQvbXBpbGliL21waV90eXBlLmgJMjAw Ni0wMi0yNiAyMzo1MDoxNC4wMDAwMDAwMDAgKzAxMDAKKysrIHN5cy9kZXYvbXB0L21waWxpYi9t cGlfdHlwZS5oCTIwMTEtMTEtMTMgMTQ6MTI6NDEuMTI1OTA2NjkzICswMTAwCkBAIC03Nyw3ICs3 Nyw3IEBACiB0eXBlZGVmIHNpZ25lZCAgIHNob3J0ICBTMTY7CiB0eXBlZGVmIHVuc2lnbmVkIHNo b3J0ICBVMTY7CiAKLSNpZmRlZglfX0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18p IHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogCiB0eXBlZGVmIGludDMyX3QgIFMzMjsK IHR5cGVkZWYgdWludDMyX3QgVTMyOwpkaWZmIC11ciBzeXMub2xkL2Rldi93aS9pZl93aXJlZy5o IHN5cy9kZXYvd2kvaWZfd2lyZWcuaAotLS0gc3lzLm9sZC9kZXYvd2kvaWZfd2lyZWcuaAkyMDA5 LTA1LTIwIDIyOjAwOjQwLjAwMDAwMDAwMCArMDIwMAorKysgc3lzL2Rldi93aS9pZl93aXJlZy5o CTIwMTEtMTEtMTMgMTQ6MTI6NDEuMTI3OTA2NTQ3ICswMTAwCkBAIC04NCw3ICs4NCw3IEBACiAj aWZkZWYgX19OZXRCU0RfXwogI2RlZmluZSBPU19TVFJJTkdfTkFNRQkiTmV0QlNEIgogI2VuZGlm Ci0jaWZkZWYgX19GcmVlQlNEX18KKyNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVk KF9fRnJlZUJTRF9rZXJuZWxfXykKICNkZWZpbmUgT1NfU1RSSU5HX05BTUUJIkZyZWVCU0QiCiAj ZW5kaWYKICNpZmRlZiBfX09wZW5CU0RfXwpkaWZmIC11ciBzeXMub2xkL2ZzL25mcy9uZnNfdmFy Lmggc3lzL2ZzL25mcy9uZnNfdmFyLmgKLS0tIHN5cy5vbGQvZnMvbmZzL25mc192YXIuaAkyMDEx LTA3LTE2IDEwOjA1OjE3LjAwMDAwMDAwMCArMDIwMAorKysgc3lzL2ZzL25mcy9uZnNfdmFyLmgJ MjAxMS0xMS0xMyAxNDoxMjo0MS4xMjg5MDY2MTUgKzAxMDAKQEAgLTc2LDcgKzc2LDcgQEAKIHN0 cnVjdCBuZnN2YXR0cjsKIHN0cnVjdCBuZnNfdmF0dHI7CiBzdHJ1Y3QgTkZTU1ZDQVJHUzsKLSNp ZmRlZiBfX0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19G cmVlQlNEX2tlcm5lbF9fKQogTkZTX0FDQ0VTU19BUkdTOwogTkZTX09QRU5fQVJHUzsKIE5GU19H RVRBVFRSX0FSR1M7CmRpZmYgLXVyIHN5cy5vbGQvbmV0L2lmX2F0bS5oIHN5cy9uZXQvaWZfYXRt LmgKLS0tIHN5cy5vbGQvbmV0L2lmX2F0bS5oCTIwMDktMDQtMTYgMjI6MzA6MjguMDAwMDAwMDAw ICswMjAwCisrKyBzeXMvbmV0L2lmX2F0bS5oCTIwMTEtMTEtMTMgMTQ6MTI6NDEuMTI5OTA2NDAy ICswMTAwCkBAIC0yMDIsNyArMjAyLDcgQEAKIAogI2lmIGRlZmluZWQoX19OZXRCU0RfXykgfHwg ZGVmaW5lZChfX09wZW5CU0RfXykgfHwgZGVmaW5lZChfX2JzZGlfXykKICNkZWZpbmUJUlRBTExP QzEoQSxCKQkJcnRhbGxvYzEoKEEpLChCKSkKLSNlbGlmIGRlZmluZWQoX19GcmVlQlNEX18pCisj ZWxpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykK ICNkZWZpbmUJUlRBTExPQzEoQSxCKQkJcnRhbGxvYzEoKEEpLChCKSwwVUwpCiAjZW5kaWYKIApk aWZmIC11ciBzeXMub2xkL25ldC96bGliLmggc3lzL25ldC96bGliLmgKLS0tIHN5cy5vbGQvbmV0 L3psaWIuaAkyMDEwLTAzLTAyIDA3OjU4OjU4LjAwMDAwMDAwMCArMDEwMAorKysgc3lzL25ldC96 bGliLmgJMjAxMS0xMS0xMyAxNDoxMjo0MS4xMzU5MDY1MjUgKzAxMDAKQEAgLTUxMCw3ICs1MTAs NyBAQAogICAgZG9uZSBieSBpbmZsYXRlKCkuCiAqLwogCi0jaWYgZGVmaW5lZChfX0ZyZWVCU0Rf XykgJiYgZGVmaW5lZChfS0VSTkVMKQorI2lmIChkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZp bmVkKF9fRnJlZUJTRF9rZXJuZWxfXykpICYmIGRlZmluZWQoX0tFUk5FTCkKICNkZWZpbmUgaW5m bGF0ZSAgICAgICBpbmZsYXRlX3BwcCAgICAgLyogRnJlZUJTRCBhbHJlYWR5IGhhcyBhbiBpbmZs YXRlIDotKCAqLwogI2VuZGlmCiAKZGlmZiAtdXIgc3lzLm9sZC9uZXQ4MDIxMS9pZWVlODAyMTFf aW9jdGwuaCBzeXMvbmV0ODAyMTEvaWVlZTgwMjExX2lvY3RsLmgKLS0tIHN5cy5vbGQvbmV0ODAy MTEvaWVlZTgwMjExX2lvY3RsLmgJMjAxMS0wNi0xNiAxMTozNzoyMC4wMDAwMDAwMDAgKzAyMDAK KysrIHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfaW9jdGwuaAkyMDExLTExLTEzIDE0OjEyOjQxLjEz NzkwNzc3NyArMDEwMApAQCAtNTY5LDcgKzU2OSw3IEBACiAJdWludDE2X3QJc3ZfdmxhbjsKIH07 CiAKLSNpZmRlZiBfX0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmlu ZWQoX19GcmVlQlNEX2tlcm5lbF9fKQogLyoKICAqIEZyZWVCU0Qtc3R5bGUgaW9jdGxzLgogICov CmRpZmYgLXVyIHN5cy5vbGQvbmV0ODAyMTEvaWVlZTgwMjExX3Zhci5oIHN5cy9uZXQ4MDIxMS9p ZWVlODAyMTFfdmFyLmgKLS0tIHN5cy5vbGQvbmV0ODAyMTEvaWVlZTgwMjExX3Zhci5oCTIwMTEt MDYtMjAgMTM6NDY6MDMuMDAwMDAwMDAwICswMjAwCisrKyBzeXMvbmV0ODAyMTEvaWVlZTgwMjEx X3Zhci5oCTIwMTEtMTEtMTMgMTQ6MTI6NDEuMTQxOTA5NzIxICswMTAwCkBAIC0zNCw3ICszNCw3 IEBACiAvKiBOQjogcG9ydGFiaWxpdHkgZ2x1ZSBtdXN0IGdvIGZpcnN0ICovCiAjaWYgZGVmaW5l ZChfX05ldEJTRF9fKQogI2luY2x1ZGUgPG5ldDgwMjExL2llZWU4MDIxMV9uZXRic2QuaD4KLSNl bGlmIGRlZmluZWQoX19GcmVlQlNEX18pCisjZWxpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBk ZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKICNpbmNsdWRlIDxuZXQ4MDIxMS9pZWVlODAyMTFf ZnJlZWJzZC5oPgogI2VsaWYgZGVmaW5lZChfX2xpbnV4X18pCiAjaW5jbHVkZSA8bmV0ODAyMTEv aWVlZTgwMjExX2xpbnV4Lmg+CmRpZmYgLXVyIHN5cy5vbGQvbmV0aW5ldC9zY3RwX2NvbnN0YW50 cy5oIHN5cy9uZXRpbmV0L3NjdHBfY29uc3RhbnRzLmgKLS0tIHN5cy5vbGQvbmV0aW5ldC9zY3Rw X2NvbnN0YW50cy5oCTIwMTEtMDktMTcgMTA6NTA6MjkuMDAwMDAwMDAwICswMjAwCisrKyBzeXMv bmV0aW5ldC9zY3RwX2NvbnN0YW50cy5oCTIwMTEtMTEtMTMgMTQ6MTI6NDEuMTQ1OTA4ODcyICsw MTAwCkBAIC0xMDIwLDcgKzEwMjAsNyBAQAogI2RlZmluZSBTQ1RQX0dFVFRJTUVfVElNRVZBTCh4 KQkoZ2V0bWljcm91cHRpbWUoeCkpCiAjZGVmaW5lIFNDVFBfR0VUUFRJTUVfVElNRVZBTCh4KQko bWljcm91cHRpbWUoeCkpCiAjZW5kaWYKLS8qI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRl ZmluZWQoX19BUFBMRV9fKSovCisvKiNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVk KF9fRnJlZUJTRF9rZXJuZWxfXykgfHwgZGVmaW5lZChfX0FQUExFX18pKi8KIC8qI2RlZmluZSBT Q1RQX0dFVFRJTUVfVElNRVZBTCh4KSB7IFwqLwogLyoJKHgpLT50dl9zZWMgPSB0aWNrcyAvIDEw MDA7IFwqLwogLyoJKHgpLT50dl91c2VjID0gKHRpY2tzICUgMTAwMCkgKiAxMDAwOyBcKi8KZGlm ZiAtdXIgc3lzLm9sZC9uZXRpbmV0L3NjdHBfcGNiLmggc3lzL25ldGluZXQvc2N0cF9wY2IuaAot LS0gc3lzLm9sZC9uZXRpbmV0L3NjdHBfcGNiLmgJMjAxMS0wOS0xNCAxMDoxNToyMS4wMDAwMDAw MDAgKzAyMDAKKysrIHN5cy9uZXRpbmV0L3NjdHBfcGNiLmgJMjAxMS0xMS0xMyAxNDoxMjo0MS4x NDg5MDk2MzIgKzAxMDAKQEAgLTI0MCw3ICsyNDAsNyBAQAogCSAqIEFsbCBzdGF0aWMgc3RydWN0 dXJlcyB0aGF0IGFuY2hvciB0aGUgc3lzdGVtIG11c3QgYmUgaGVyZS4KIAkgKi8KIAlzdHJ1Y3Qg c2N0cF9lcGluZm8gc2N0cHBjYmluZm87Ci0jaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgJiYgZGVm aW5lZChTTVApICYmIGRlZmluZWQoU0NUUF9VU0VfUEVSQ1BVX1NUQVQpCisjaWYgKGRlZmluZWQo X19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNEX2tlcm5lbF9fKSkgJiYgZGVmaW5lZChT TVApICYmIGRlZmluZWQoU0NUUF9VU0VfUEVSQ1BVX1NUQVQpCiAJc3RydWN0IHNjdHBzdGF0ICpz Y3Rwc3RhdDsKICNlbHNlCiAJc3RydWN0IHNjdHBzdGF0IHNjdHBzdGF0OwpAQCAtNjMyLDcgKzYz Miw3IEBACiAgICAgc3RydWN0IHNjdHBfaW5wY2IgKiwKICAgICB1aW50OF90IGNvX29mZik7CiAK LSNpZiBkZWZpbmVkKF9fRnJlZUJTRF9fKSAmJiBkZWZpbmVkKFNDVFBfTUNPUkVfSU5QVVQpICYm IGRlZmluZWQoU01QKQorI2lmIChkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJl ZUJTRF9rZXJuZWxfXykpICYmIGRlZmluZWQoU0NUUF9NQ09SRV9JTlBVVCkgJiYgZGVmaW5lZChT TVApCiB2b2lkCiAgICAgIHNjdHBfcXVldWVfdG9fbWNvcmUoc3RydWN0IG1idWYgKm0sIGludCBv ZmYsIGludCBjcHVfdG9fdXNlKTsKIApkaWZmIC11ciBzeXMub2xkL25ldGluZXQvc2N0cF9zdHJ1 Y3RzLmggc3lzL25ldGluZXQvc2N0cF9zdHJ1Y3RzLmgKLS0tIHN5cy5vbGQvbmV0aW5ldC9zY3Rw X3N0cnVjdHMuaAkyMDExLTEwLTEwIDE4OjMxOjE4LjAwMDAwMDAwMCArMDIwMAorKysgc3lzL25l dGluZXQvc2N0cF9zdHJ1Y3RzLmgJMjAxMS0xMS0xMyAxNDoxMjo0MS4xNTA5MDc1MzEgKzAxMDAK QEAgLTEwOCw3ICsxMDgsNyBAQAogdHlwZWRlZiBpbnQgKCppbnBfZnVuYykgKHN0cnVjdCBzY3Rw X2lucGNiICosIHZvaWQgKnB0ciwgdWludDMyX3QgdmFsKTsKIHR5cGVkZWYgdm9pZCAoKmVuZF9m dW5jKSAodm9pZCAqcHRyLCB1aW50MzJfdCB2YWwpOwogCi0jaWYgZGVmaW5lZChfX0ZyZWVCU0Rf XykgJiYgZGVmaW5lZChTQ1RQX01DT1JFX0lOUFVUKSAmJiBkZWZpbmVkKFNNUCkKKyNpZiAoZGVm aW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rfa2VybmVsX18pKSAmJiBkZWZp bmVkKFNDVFBfTUNPUkVfSU5QVVQpICYmIGRlZmluZWQoU01QKQogLyogd2hhdHMgb24gdGhlIG1j b3JlIGNvbnRyb2wgc3RydWN0ICovCiBzdHJ1Y3Qgc2N0cF9tY29yZV9xdWV1ZSB7CiAJVEFJTFFf RU5UUlkoc2N0cF9tY29yZV9xdWV1ZSkgbmV4dDsKZGlmZiAtdXIgc3lzLm9sZC9uZXRpbmV0L3Nj dHBfdWlvLmggc3lzL25ldGluZXQvc2N0cF91aW8uaAotLS0gc3lzLm9sZC9uZXRpbmV0L3NjdHBf dWlvLmgJMjAxMS0wOC0xNCAyMjo1NTozMi4wMDAwMDAwMDAgKzAyMDAKKysrIHN5cy9uZXRpbmV0 L3NjdHBfdWlvLmgJMjAxMS0xMS0xMyAxNDoxMjo0MS4xNTI5MDU5ODkgKzAxMDAKQEAgLTEwNTYs NyArMTA1Niw3IEBACiAKICNkZWZpbmUgU0NUUF9TVEFUX0lOQ1IoX3gpIFNDVFBfU1RBVF9JTkNS X0JZKF94LDEpCiAjZGVmaW5lIFNDVFBfU1RBVF9ERUNSKF94KSBTQ1RQX1NUQVRfREVDUl9CWShf eCwxKQotI2lmIGRlZmluZWQoX19GcmVlQlNEX18pICYmIGRlZmluZWQoU01QKSAmJiBkZWZpbmVk KFNDVFBfVVNFX1BFUkNQVV9TVEFUKQorI2lmIChkZWZpbmVkKF9fRnJlZUJTRF9fKSB8fCBkZWZp bmVkKF9fRnJlZUJTRF9rZXJuZWxfXykpICYmIGRlZmluZWQoU01QKSAmJiBkZWZpbmVkKFNDVFBf VVNFX1BFUkNQVV9TVEFUKQogI2RlZmluZSBTQ1RQX1NUQVRfSU5DUl9CWShfeCxfZCkgKFNDVFBf QkFTRV9TVEFUU1tQQ1BVX0dFVChjcHVpZCldLl94ICs9IF9kKQogI2RlZmluZSBTQ1RQX1NUQVRf REVDUl9CWShfeCxfZCkgKFNDVFBfQkFTRV9TVEFUU1tQQ1BVX0dFVChjcHVpZCldLl94IC09IF9k KQogI2Vsc2UKZGlmZiAtdXIgc3lzLm9sZC9zeXMvZGV2aWNlX3BvcnQuaCBzeXMvc3lzL2Rldmlj ZV9wb3J0LmgKLS0tIHN5cy5vbGQvc3lzL2RldmljZV9wb3J0LmgJMjAwNS0wMS0xOSAwMjozMToz My4wMDAwMDAwMDAgKzAxMDAKKysrIHN5cy9zeXMvZGV2aWNlX3BvcnQuaAkyMDExLTExLTEzIDE0 OjEyOjQxLjE1MzkwNzE3NCArMDEwMApAQCAtMjksNyArMjksNyBAQAogCiAjaWYgZGVmaW5lZChf X05ldEJTRF9fKQogIyBpbmNsdWRlIDxzeXMvZGV2aWNlLmg+Ci0jZWxpZiBkZWZpbmVkKF9fRnJl ZUJTRF9fKQorI2VsaWYgZGVmaW5lZChfX0ZyZWVCU0RfXykgfHwgZGVmaW5lZChfX0ZyZWVCU0Rf a2VybmVsX18pCiAjIGluY2x1ZGUgPHN5cy9tb2R1bGUuaD4KICMgaW5jbHVkZSA8c3lzL2J1cy5o PgogI2VuZGlmCkBAIC00Myw3ICs0Myw3IEBACiAjIGRlZmluZSBERVZQT1JUX0RFVk5BTUUoZGV2 KQkJKGRldikuZHZfeG5hbWUKICMgZGVmaW5lIERFVlBPUlRfREVWVU5JVChkZXYpCQkoZGV2KS5k dl91bml0CiAKLSNlbGlmIGRlZmluZWQoX19GcmVlQlNEX18pCisjZWxpZiBkZWZpbmVkKF9fRnJl ZUJTRF9fKSB8fCBkZWZpbmVkKF9fRnJlZUJTRF9rZXJuZWxfXykKIC8qCiAgKiBGcmVlQlNEIChj b21wYXRpYmlsaXR5IGZvciBzdHJ1Y3QgZGV2aWNlKQogICovCmRpZmYgLXVyIHN5cy5vbGQvc3lz L3RpbWV4Lmggc3lzL3N5cy90aW1leC5oCi0tLSBzeXMub2xkL3N5cy90aW1leC5oCTIwMDUtMDEt MDcgMDM6Mjk6MjcuMDAwMDAwMDAwICswMTAwCisrKyBzeXMvc3lzL3RpbWV4LmgJMjAxMS0xMS0x MyAxNDoxMjo0MS4xNTU5MDc1ODcgKzAxMDAKQEAgLTIxOCw3ICsyMTgsNyBAQAogCWxvbmcJc3Ri Y250OwkJLyogc3RhYmlsaXR5IGxpbWl0IGV4Y2VlZGVkIChybykgKi8KIH07CiAKLSNpZmRlZiBf X0ZyZWVCU0RfXworI2lmIGRlZmluZWQoX19GcmVlQlNEX18pIHx8IGRlZmluZWQoX19GcmVlQlNE X2tlcm5lbF9fKQogCiAjaWZkZWYgX0tFUk5FTAogdm9pZAludHBfdXBkYXRlX3NlY29uZChpbnQ2 NF90ICphZGp1c3RtZW50LCB0aW1lX3QgKm5ld3NlYyk7Cg== --90e6ba6e836c3e770904b1dd6a9a-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 18:07:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F23A1065676; Wed, 16 Nov 2011 18:07:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 030D68FC14; Wed, 16 Nov 2011 18:07:16 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 5A6793581; Wed, 16 Nov 2011 10:07:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1321466835; bh=jkJZaJhX/rrEb0YD/QYLuIEo+8OTJy3BAaSuUsRvJbc=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YFrq1LZwtR8fpuzwW1+bPyCOMO0G7rDYrcSFxEdJjywyBcv7sd+re5tockDUrmdlT 9Dtsb61soQNZMpndXW0L3Kaue0USEluiDGzD45W8IVyTcu1lUC7l12LYZkEbWQE95O jp97XT4JbE1UMDRYcDbQffEmxkPES0Dak3bcX8bE= Message-ID: <4EC3FBD2.4070009@delphij.net> Date: Wed, 16 Nov 2011 10:07:14 -0800 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: Robert Millan References: In-Reply-To: OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:07:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/16/11 09:27, Robert Millan wrote: > Hi! > > Out of the kernel headers that are installed in /usr/include/ > hierracy, there are some which include support multiple operating > systems (usually FreeBSD and other *BSD flavours). > > This patch adds support to detect GNU/kFreeBSD as well. In all > cases, we match the same declarations as FreeBSD does (which is to > be expected in kernel headers, since both systems share the same > kernel). > > Does it look fine? Just my $0.02 -- I think we should probably do it in a more centralized place -- otherwise in case someone imported some new code, they have to do the same defined(__FreeBSD__) || defined(__FreeBSD_kernel__)? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOw/vSAAoJEATO+BI/yjfBozIIAMuqmkNkDkWG4Kra/mQ5HQXZ Oe/bndGzfUl9H6epFZWc+eeT2zxnlvVUGwVf5si3THU23dZkmynbPj1NnY+oDewt TwB5nbG0tcClMMesK8L9lJB5AxKHsRtILK8l8xMzsJEj6fRjb8+yrjj8LLK7zUNk gTQA/sOVR2a4ZARkUlvbgNsE/BBx7NijxFS3uMA91AgsXAniBp4ND6dDwAudQIpW MqLH4DxJX/6EC2E9ibM5IBB8wguaUWF52oHLGnRAs2JkXzNS/qj6aSepjivSIUzh gtKKteCpRNexnWq+2pym9OE6tmxW8uoPNUuBxZqOP+laabcn392silZrE0yElh8= =XHtJ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 18:19:01 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 076FD1065689; Wed, 16 Nov 2011 18:19:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id CD7418FC0A; Wed, 16 Nov 2011 18:19:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAGIIxFn037602; Wed, 16 Nov 2011 13:18:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAGIIx5C037566; Wed, 16 Nov 2011 18:18:59 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 16 Nov 2011 18:18:59 GMT Message-Id: <201111161818.pAGIIx5C037566@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:19:01 -0000 TB --- 2011-11-16 15:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-16 15:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-11-16 15:30:00 - cleaning the object tree TB --- 2011-11-16 15:31:04 - cvsupping the source tree TB --- 2011-11-16 15:31:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-11-16 15:31:16 - building world TB --- 2011-11-16 15:31:16 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 15:31:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 15:31:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 15:31:16 - SRCCONF=/dev/null TB --- 2011-11-16 15:31:16 - TARGET=amd64 TB --- 2011-11-16 15:31:16 - TARGET_ARCH=amd64 TB --- 2011-11-16 15:31:16 - TZ=UTC TB --- 2011-11-16 15:31:16 - __MAKE_CONF=/dev/null TB --- 2011-11-16 15:31:16 - cd /src TB --- 2011-11-16 15:31:16 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 16 15:31:17 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Nov 16 18:08:28 UTC 2011 TB --- 2011-11-16 18:08:28 - generating LINT kernel config TB --- 2011-11-16 18:08:28 - cd /src/sys/amd64/conf TB --- 2011-11-16 18:08:28 - /usr/bin/make -B LINT TB --- 2011-11-16 18:08:28 - cd /src/sys/amd64/conf TB --- 2011-11-16 18:08:28 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-16 18:08:28 - building LINT-NOINET kernel TB --- 2011-11-16 18:08:28 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 18:08:28 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 18:08:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 18:08:28 - SRCCONF=/dev/null TB --- 2011-11-16 18:08:28 - TARGET=amd64 TB --- 2011-11-16 18:08:28 - TARGET_ARCH=amd64 TB --- 2011-11-16 18:08:28 - TZ=UTC TB --- 2011-11-16 18:08:28 - __MAKE_CONF=/dev/null TB --- 2011-11-16 18:08:28 - cd /src TB --- 2011-11-16 18:08:28 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Wed Nov 16 18:08:28 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/fs/procfs/procfs_type.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/fs/pseudofs/pseudofs.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/fs/pseudofs/pseudofs_fileno.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/fs/pseudofs/pseudofs_vncache.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/fs/pseudofs/pseudofs_vnops.c cc1: warnings being treated as errors /src/sys/fs/pseudofs/pseudofs_vnops.c: In function 'pfs_readdir': /src/sys/fs/pseudofs/pseudofs_vnops.c:837: warning: format '%zd' expects type 'signed size_t', but argument 2 has type 'int' [-Wformat] *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-16 18:18:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-16 18:18:59 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-16 18:18:59 - 7917.45 user 1540.29 system 10138.93 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 18:26:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F7CC106564A; Wed, 16 Nov 2011 18:26:10 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id EE3968FC18; Wed, 16 Nov 2011 18:26:09 +0000 (UTC) Received: by iakl21 with SMTP id l21so1417055iak.13 for ; Wed, 16 Nov 2011 10:26:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JqcReVnpsxN2/UqYZ4ljiP6p1hGT8tlS/83h2PRmvlM=; b=g3SX/IoACSD1+sg1kJwQP+7No2zwkSRSZSGj8gcoJ84hEvGfvkc/1fYk9bBCW78a4D mXzCUfSUT2Ea/j1ga0L8DfznGz9Ed9uvKwrM+6bc0e9b9DPs0X0Y0vENLRv6nQg0+pSu eMmu5V8vDYPoHU9jRTExma2ScIv6GZEolyskI= MIME-Version: 1.0 Received: by 10.42.135.66 with SMTP id o2mr33643126ict.0.1321467969092; Wed, 16 Nov 2011 10:26:09 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.243.198 with HTTP; Wed, 16 Nov 2011 10:26:09 -0800 (PST) In-Reply-To: <4EC3FBD2.4070009@delphij.net> References: <4EC3FBD2.4070009@delphij.net> Date: Wed, 16 Nov 2011 19:26:09 +0100 X-Google-Sender-Auth: ebUx-h__hYYpl6-mAj8rVFShKug Message-ID: From: Robert Millan To: d@delphij.net Content-Type: text/plain; charset=UTF-8 Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:26:10 -0000 2011/11/16 Xin LI : > Just my $0.02 -- I think we should probably do it in a more > centralized place -- otherwise in case someone imported some new code, > they have to do the same defined(__FreeBSD__) || > defined(__FreeBSD_kernel__)? How about something like: #if defined(__FreeBSD__) && !defined(__FreeBSD_kernel__) #define __FreeBSD_kernel__ #endif it can be placed at beginning of each header, then the rest becomes much simpler. Note this has the side-effect of defining __FreeBSD_kernel__ on FreeBSD, which I suspect some people won't be fond of. An alternative could be to come up with an ad-hoc macro that means "this system is either FreeBSD or uses the same kernel as FreeBSD" and define it where needed. From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 18:39:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE1B2106564A; Wed, 16 Nov 2011 18:39:14 +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 8743E8FC08; Wed, 16 Nov 2011 18:39:14 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pAGIWdJD001766 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2011 11:32:41 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 16 Nov 2011 11:32:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Robert Millan X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 16 Nov 2011 11:32:41 -0700 (MST) Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:39:15 -0000 Hey Robert, Thanks for jumping into this. Sadly, it is a bit of a mess. Many of = the "multiple BSD flavor" support #ifdefs are actually quite stale by = now, so they should be cleaned up. That's not something you have to = cope with, unless you want, but it colors my first reaction :) My second reaction was why not have #ifndef __FreeBSD_kernel__ #define __FreeBSD_kernel__ __FreeBSD__ #endif in sys/param.h and then just change __FreeBSD__ to __FreeBSD_kernel__ in = the headers that are affected? But I'm not quite sure what effects that = would have on your environment. Thanks for considering the above modification. Warner On Nov 16, 2011, at 10:27 AM, Robert Millan wrote: > Hi! >=20 > Out of the kernel headers that are installed in /usr/include/ = hierracy, there > are some which include support multiple operating systems (usually = FreeBSD and > other *BSD flavours). >=20 > This patch adds support to detect GNU/kFreeBSD as well. In all cases, = we > match the same declarations as FreeBSD does (which is to be expected = in kernel > headers, since both systems share the same kernel). >=20 > Does it look fine? > = _______________________________________________= > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 18:40:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C22FF106566B; Wed, 16 Nov 2011 18:40:36 +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 6C3998FC21; Wed, 16 Nov 2011 18:40:36 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pAGIWdJE001766 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2011 11:33:37 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 16 Nov 2011 11:33:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EC3FBD2.4070009@delphij.net> To: Robert Millan X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 16 Nov 2011 11:33:38 -0700 (MST) Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, d@delphij.net, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:40:36 -0000 On Nov 16, 2011, at 11:26 AM, Robert Millan wrote: > 2011/11/16 Xin LI : >> Just my $0.02 -- I think we should probably do it in a more >> centralized place -- otherwise in case someone imported some new = code, >> they have to do the same defined(__FreeBSD__) || >> defined(__FreeBSD_kernel__)? >=20 > How about something like: >=20 > #if defined(__FreeBSD__) && !defined(__FreeBSD_kernel__) > #define __FreeBSD_kernel__ > #endif >=20 > it can be placed at beginning of each header, then the rest becomes > much simpler. >=20 > Note this has the side-effect of defining __FreeBSD_kernel__ on > FreeBSD, which I suspect some people won't be fond of. An alternative > could be to come up with an ad-hoc macro that means "this system is > either FreeBSD or uses the same kernel as FreeBSD" and define it where > needed. I had a similar suggestion... Why do you think people wouldn't be fond of the __FreeBSD_kernel__ being = defined? Warner From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 18:41:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 623181065672; Wed, 16 Nov 2011 18:41:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id ED3838FC28; Wed, 16 Nov 2011 18:41:00 +0000 (UTC) Received: by vws11 with SMTP id 11so9531vws.13 for ; Wed, 16 Nov 2011 10:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3W/FTZltOIEIE8YP+TWBUcpi6czuk4wujwFySUOnu6I=; b=jaG+oXuLdKwcOsM47FNpNbzs/eoVq3XYy/sICKpi2I8zl/XoYrjm0eaMtOSX9pyOzx Kat6AVhUOjMQFxeRNC+PJ/PhzqKAAXjGubcP/+gBb2lhVBpiNfY6OaFnQHsA/OJPh56C vdxxO9MPdjh2M8T4AFW+NcFhoPbUh1v6Z9o0A= MIME-Version: 1.0 Received: by 10.52.92.84 with SMTP id ck20mr52164707vdb.88.1321468860328; Wed, 16 Nov 2011 10:41:00 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Wed, 16 Nov 2011 10:41:00 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Nov 2011 10:41:00 -0800 X-Google-Sender-Auth: ROGF-iUxe-RhCETRLlA9mA7GKOc Message-ID: From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Kostik Belousov , freebsd-arch@freebsd.org, freebsd-current@freebsd.org, Robert Millan Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:41:01 -0000 .. my suggestion (high level, fluffy) is to try to get approval/consensus on fixing the immediate problem so things are consistently horrible, then a second pass to make them consistently unhorrible. Adrian From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 18:44:34 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3E471065672 for ; Wed, 16 Nov 2011 18:44:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 3F0BE8FC0A for ; Wed, 16 Nov 2011 18:44:32 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAGIiSxh037229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2011 20:44:28 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAGIiSMW009638; Wed, 16 Nov 2011 20:44:28 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAGIiS26009637; Wed, 16 Nov 2011 20:44:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 16 Nov 2011 20:44:28 +0200 From: Kostik Belousov To: current@freebsd.org, amd64@freebsd.org Message-ID: <20111116184428.GK50300@deviant.kiev.zoral.com.ua> References: <201111161818.pAGIIx5C037566@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tgL6n6n9I302p8lD" Content-Disposition: inline In-Reply-To: <201111161818.pAGIIx5C037566@freebsd-current.sentex.ca> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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: Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:44:34 -0000 --tgL6n6n9I302p8lD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 16, 2011 at 06:18:59PM +0000, FreeBSD Tinderbox wrote: > TB --- 2011-11-16 15:30:00 - tinderbox 2.8 running on freebsd-current.sen= tex.ca > TB --- 2011-11-16 15:30:00 - starting HEAD tinderbox run for amd64/amd64 > TB --- 2011-11-16 15:30:00 - cleaning the object tree > TB --- 2011-11-16 15:31:04 - cvsupping the source tree > TB --- 2011-11-16 15:31:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sente= x.ca /tinderbox/HEAD/amd64/amd64/supfile > TB --- 2011-11-16 15:31:16 - building world > TB --- 2011-11-16 15:31:16 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-16 15:31:16 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-16 15:31:16 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-16 15:31:16 - SRCCONF=3D/dev/null > TB --- 2011-11-16 15:31:16 - TARGET=3Damd64 > TB --- 2011-11-16 15:31:16 - TARGET_ARCH=3Damd64 > TB --- 2011-11-16 15:31:16 - TZ=3DUTC > TB --- 2011-11-16 15:31:16 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-16 15:31:16 - cd /src > TB --- 2011-11-16 15:31:16 - /usr/bin/make -B buildworld > >>> World build started on Wed Nov 16 15:31:17 UTC 2011 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> stage 5.1: building 32 bit shim libraries > >>> World build completed on Wed Nov 16 18:08:28 UTC 2011 > TB --- 2011-11-16 18:08:28 - generating LINT kernel config > TB --- 2011-11-16 18:08:28 - cd /src/sys/amd64/conf > TB --- 2011-11-16 18:08:28 - /usr/bin/make -B LINT > TB --- 2011-11-16 18:08:28 - cd /src/sys/amd64/conf > TB --- 2011-11-16 18:08:28 - /usr/sbin/config -m LINT-NOINET > TB --- 2011-11-16 18:08:28 - building LINT-NOINET kernel > TB --- 2011-11-16 18:08:28 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-16 18:08:28 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-16 18:08:28 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-16 18:08:28 - SRCCONF=3D/dev/null > TB --- 2011-11-16 18:08:28 - TARGET=3Damd64 > TB --- 2011-11-16 18:08:28 - TARGET_ARCH=3Damd64 > TB --- 2011-11-16 18:08:28 - TZ=3DUTC > TB --- 2011-11-16 18:08:28 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-16 18:08:28 - cd /src > TB --- 2011-11-16 18:08:28 - /usr/bin/make -B buildkernel KERNCONF=3DLINT= -NOINET > >>> Kernel build for LINT-NOINET started on Wed Nov 16 18:08:28 UTC 2011 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > [...] > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fforma= t-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -= I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADER= S -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-un= it-growth=3D100 --param large-function-growth=3D1000 -DGPROF -falign-functi= ons=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -m= cmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwi= nd-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue = /src/sys/fs/procfs/procfs_type.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fforma= t-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -= I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADER= S -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-un= it-growth=3D100 --param large-function-growth=3D1000 -DGPROF -falign-functi= ons=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -m= cmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwi= nd-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue = /src/sys/fs/pseudofs/pseudofs.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fforma= t-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -= I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADER= S -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-un= it-growth=3D100 --param large-function-growth=3D1000 -DGPROF -falign-functi= ons=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -m= cmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwi= nd-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue = /src/sys/fs/pseudofs/pseudofs_fileno.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fforma= t-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -= I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADER= S -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-un= it-growth=3D100 --param large-function-growth=3D1000 -DGPROF -falign-functi= ons=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -m= cmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwi= nd-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue = /src/sys/fs/pseudofs/pseudofs_vncache.c > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -Wal= l -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototy= pes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fforma= t-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -= I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADER= S -include opt_global.h -fno-common -finline-limit=3D8000 --param inline-un= it-growth=3D100 --param large-function-growth=3D1000 -DGPROF -falign-functi= ons=3D16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mno-sse -m= cmodel=3Dkernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwi= nd-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue = /src/sys/fs/pseudofs/pseudofs_vnops.c > cc1: warnings being treated as errors > /src/sys/fs/pseudofs/pseudofs_vnops.c: In function 'pfs_readdir': > /src/sys/fs/pseudofs/pseudofs_vnops.c:837: warning: format '%zd' expects = type 'signed size_t', but argument 2 has type 'int' [-Wformat] > *** Error code 1 >=20 > Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. > *** Error code 1 >=20 > Stop in /src. > *** Error code 1 >=20 > Stop in /src. > TB --- 2011-11-16 18:18:59 - WARNING: /usr/bin/make returned exit code 1= =20 > TB --- 2011-11-16 18:18:59 - ERROR: failed to build LINT-NOINET kernel > TB --- 2011-11-16 18:18:59 - 7917.45 user 1540.29 system 10138.93 real >=20 >=20 > http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full Hopefully fixed by r227576. Sorry. --tgL6n6n9I302p8lD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7EBIsACgkQC3+MBN1Mb4iJmQCg2fgae51tXxScxWsz3OhlJzYl qvMAnjhcnbdCDjZYkOsR2xQXmZ9xyEUj =YYHB -----END PGP SIGNATURE----- --tgL6n6n9I302p8lD-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 19:26:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF890106566B for ; Wed, 16 Nov 2011 19:26:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6BB848FC0A for ; Wed, 16 Nov 2011 19:26:24 +0000 (UTC) Received: by iakl21 with SMTP id l21so1511130iak.13 for ; Wed, 16 Nov 2011 11:26:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=6yTbJlSZfkC5jFVJLAfVhLpd3vhRJ60YybRADZ+mKzA=; b=i04oDZ86Bk8uqmUk9vk207vVcFNxqFYLyo5Cz0XSsqCgfiEDzhCZJcfhwIMfikIJv/ D7jAfo5HiUr+0p1NY/kgzsk7LoAiMgtEgG3sXrrbsQUWfGyCDnIQC0XVAOedSKB0UyCM PnOADUk4aJ4vc57lDqFdUpryYHmq4XbLvd6Ds= Received: by 10.42.161.132 with SMTP id t4mr33883571icx.16.1321471582740; Wed, 16 Nov 2011 11:26:22 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id l28sm6630564ibc.3.2011.11.16.11.26.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Nov 2011 11:26:21 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 16 Nov 2011 11:24:21 -0800 From: YongHyeon PYUN Date: Wed, 16 Nov 2011 11:24:21 -0800 To: freebsd-current@FreeBSD.org Message-ID: <20111116192421.GA11828@michelle.cdnetworks.com> References: <20110527014043.GE18312@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110527014043.GE18312@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: CFT: msk(4) 64bit DMA support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 19:26:24 -0000 On Thu, May 26, 2011 at 06:40:43PM -0700, YongHyeon PYUN wrote: > Hi, > > Here is a patch that implements 64bit DMA on msk(4). If you use > msk(4) on a system that has more than 4GB memory, please try the > patch at the following URL and let me know whether it works or not. > You need latest msk(4) in HEAD to apply the patch. > http://people.freebsd.org/~yongari/msk/msk.64bit.dma.diff > > Previously msk(4) may have used bounce buffers on systems that have > more than 4GB memory. You can verify whether msk(4) is using bounce > buffers by checking the output of "sysctl hw.busdma". For instance, > hw.busdma.zone0.total_bounced counter would increase while network > operation is in progress. If patch above works you wouldn't see > the counter change anymore and it would also enhance network > performance since it wouldn't have to copy from or to bounce > buffers. > Committed to HEAD(r227582). > Thanks. From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 19:27:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4909106566B for ; Wed, 16 Nov 2011 19:27:35 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by mx1.freebsd.org (Postfix) with ESMTP id 65DF48FC15 for ; Wed, 16 Nov 2011 19:27:35 +0000 (UTC) Received: from [78.34.136.92] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1RQl8v-0004MB-Sx for freebsd-current@freebsd.org; Wed, 16 Nov 2011 20:27:33 +0100 Date: Wed, 16 Nov 2011 20:27:14 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20111116202714.5ee4bd53@fabiankeil.de> In-Reply-To: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/h6MFPkJbRJAFTE.EUo6PqE3"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 19:27:35 -0000 --Sig_/h6MFPkJbRJAFTE.EUo6PqE3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Kostik Belousov wrote: > I was tricked into finishing the work by Andrey Gapon, who developed > the patch to reliably stop other processors on panic. The patch > greatly improves the chances of getting dump on panic on SMP host. I tested the patch trying to get a dump (from the debugger) for kern/162036, which currently results in the double fault reported in: http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027766.ht= ml It didn't help, but also didn't make anything worse. Fabian --Sig_/h6MFPkJbRJAFTE.EUo6PqE3 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7EDpgACgkQBYqIVf93VJ2qUACgj5d58OgV4ed5oUuywPJRwW4S DbcAoK8aKcM86/sHLVKEZkys7uOQK5s+ =o+kI -----END PGP SIGNATURE----- --Sig_/h6MFPkJbRJAFTE.EUo6PqE3-- From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 20:41:31 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4A50106566B; Wed, 16 Nov 2011 20:41:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD208FC0A; Wed, 16 Nov 2011 20:41:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAGKfUvm092965; Wed, 16 Nov 2011 15:41:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAGKfUPd092960; Wed, 16 Nov 2011 20:41:30 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 16 Nov 2011 20:41:30 GMT Message-Id: <201111162041.pAGKfUPd092960@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 20:41:31 -0000 TB --- 2011-11-16 19:23:31 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-16 19:23:31 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-11-16 19:23:31 - cleaning the object tree TB --- 2011-11-16 19:23:44 - cvsupping the source tree TB --- 2011-11-16 19:23:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-11-16 19:23:56 - building world TB --- 2011-11-16 19:23:56 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 19:23:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 19:23:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 19:23:56 - SRCCONF=/dev/null TB --- 2011-11-16 19:23:56 - TARGET=sparc64 TB --- 2011-11-16 19:23:56 - TARGET_ARCH=sparc64 TB --- 2011-11-16 19:23:56 - TZ=UTC TB --- 2011-11-16 19:23:56 - __MAKE_CONF=/dev/null TB --- 2011-11-16 19:23:56 - cd /src TB --- 2011-11-16 19:23:56 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 16 19:23:57 UTC 2011 >>> 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 Wed Nov 16 20:27:49 UTC 2011 TB --- 2011-11-16 20:27:49 - generating LINT kernel config TB --- 2011-11-16 20:27:49 - cd /src/sys/sparc64/conf TB --- 2011-11-16 20:27:49 - /usr/bin/make -B LINT TB --- 2011-11-16 20:27:49 - cd /src/sys/sparc64/conf TB --- 2011-11-16 20:27:49 - /usr/sbin/config -m GENERIC TB --- 2011-11-16 20:27:49 - building GENERIC kernel TB --- 2011-11-16 20:27:49 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 20:27:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 20:27:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 20:27:49 - SRCCONF=/dev/null TB --- 2011-11-16 20:27:49 - TARGET=sparc64 TB --- 2011-11-16 20:27:49 - TARGET_ARCH=sparc64 TB --- 2011-11-16 20:27:49 - TZ=UTC TB --- 2011-11-16 20:27:49 - __MAKE_CONF=/dev/null TB --- 2011-11-16 20:27:49 - cd /src TB --- 2011-11-16 20:27:49 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 16 20:27:49 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-16 20:41:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-16 20:41:30 - ERROR: failed to build GENERIC kernel TB --- 2011-11-16 20:41:30 - 3513.79 user 796.52 system 4679.22 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 20:45:27 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 291571065670; Wed, 16 Nov 2011 20:45:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D118A8FC1A; Wed, 16 Nov 2011 20:45:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAGKjQHZ097705; Wed, 16 Nov 2011 15:45:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAGKjQgx097704; Wed, 16 Nov 2011 20:45:26 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 16 Nov 2011 20:45:26 GMT Message-Id: <201111162045.pAGKjQgx097704@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 20:45:27 -0000 TB --- 2011-11-16 18:54:30 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-16 18:54:30 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-16 18:54:30 - cleaning the object tree TB --- 2011-11-16 18:54:55 - cvsupping the source tree TB --- 2011-11-16 18:54:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-16 18:55:42 - building world TB --- 2011-11-16 18:55:42 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 18:55:42 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 18:55:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 18:55:42 - SRCCONF=/dev/null TB --- 2011-11-16 18:55:42 - TARGET=powerpc TB --- 2011-11-16 18:55:42 - TARGET_ARCH=powerpc64 TB --- 2011-11-16 18:55:42 - TZ=UTC TB --- 2011-11-16 18:55:42 - __MAKE_CONF=/dev/null TB --- 2011-11-16 18:55:42 - cd /src TB --- 2011-11-16 18:55:42 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 16 18:55:43 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Nov 16 20:32:23 UTC 2011 TB --- 2011-11-16 20:32:23 - generating LINT kernel config TB --- 2011-11-16 20:32:23 - cd /src/sys/powerpc/conf TB --- 2011-11-16 20:32:23 - /usr/bin/make -B LINT TB --- 2011-11-16 20:32:23 - cd /src/sys/powerpc/conf TB --- 2011-11-16 20:32:23 - /usr/sbin/config -m GENERIC TB --- 2011-11-16 20:32:23 - skipping GENERIC kernel TB --- 2011-11-16 20:32:23 - cd /src/sys/powerpc/conf TB --- 2011-11-16 20:32:23 - /usr/sbin/config -m GENERIC64 TB --- 2011-11-16 20:32:23 - building GENERIC64 kernel TB --- 2011-11-16 20:32:23 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 20:32:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 20:32:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 20:32:23 - SRCCONF=/dev/null TB --- 2011-11-16 20:32:23 - TARGET=powerpc TB --- 2011-11-16 20:32:23 - TARGET_ARCH=powerpc64 TB --- 2011-11-16 20:32:23 - TZ=UTC TB --- 2011-11-16 20:32:23 - __MAKE_CONF=/dev/null TB --- 2011-11-16 20:32:23 - cd /src TB --- 2011-11-16 20:32:23 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Wed Nov 16 20:32:23 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-16 20:45:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-16 20:45:25 - ERROR: failed to build GENERIC64 kernel TB --- 2011-11-16 20:45:25 - 5005.06 user 1138.82 system 6655.04 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 22:21:31 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3F11106564A; Wed, 16 Nov 2011 22:21:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BD35B8FC18; Wed, 16 Nov 2011 22:21:30 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA00782; Thu, 17 Nov 2011 00:21:28 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RQnrD-0008xf-Iz; Thu, 17 Nov 2011 00:21:27 +0200 Message-ID: <4EC43764.1020202@FreeBSD.org> Date: Thu, 17 Nov 2011 00:21:24 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Fabian Keil References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <20111116202714.5ee4bd53@fabiankeil.de> In-Reply-To: <20111116202714.5ee4bd53@fabiankeil.de> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Konstantin Belousov Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 22:21:31 -0000 on 16/11/2011 21:27 Fabian Keil said the following: > Kostik Belousov wrote: > >> I was tricked into finishing the work by Andrey Gapon, who developed >> the patch to reliably stop other processors on panic. The patch >> greatly improves the chances of getting dump on panic on SMP host. > > I tested the patch trying to get a dump (from the debugger) for > kern/162036, which currently results in the double fault reported in: > http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027766.html > > It didn't help, but also didn't make anything worse. > > Fabian The mi_switch recursion looks very familiar to me: mi_switch() at mi_switch+0x270 critical_exit() at critical_exit+0x9b spinlock_exit() at spinlock_exit+0x17 mi_switch() at mi_switch+0x275 critical_exit() at critical_exit+0x9b spinlock_exit() at spinlock_exit+0x17 [several pages of the previous three lines skipped] mi_switch() at mi_switch+0x275 critical_exit() at critical_exit+0x9b spinlock_exit() at spinlock_exit+0x17 intr_even_schedule_thread() at intr_event_schedule_thread+0xbb ahci_end_transaction() at ahci_end_transaction+0x398 ahci_ch_intr() at ahci_ch_intr+0x2b5 ahcipoll() at ahcipoll+0x15 xpt_polled_action() at xpt_polled_action+0xf7 In fact I once discussed with jhb this recursion triggered from a different place. To quote myself: spinlock_exit -> critical_exit -> mi_switch -> kdb_switch -> thread_unlock -> spinlock_exit -> critical_exit -> mi_switch -> ... in the kdb context this issue seems to be triggered by td_owepreempt being true at the time kdb is entered and there of course has to be an initial spinlock_exit call somewhere in my case it's because of usb keyboard I wonder if it would make sense to clear td_owepreempt right before calling kdb_switch in mi_switch instead of in sched_switch() clearing td_owepreempt seems like a scheduler-independent operation to me or is it better to just skip locking in usb when kdb_active is set ? The workaround described above should work in this case. Another possibility is to pessimize mtx_unlock_spin() implementations to check SCHEDULER_STOPPED() and to bypass any further actions in that case. But that would add unnecessary overhead to the sunny day code paths. Going further up the stack one can come up with the following proposals: - check SCHEDULER_STOPPED() swi_sched() and return early - do not call swi_sched() from xpt_done() if we somehow know that we are in a polling mode -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 22:21:46 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49AD710657A4 for ; Wed, 16 Nov 2011 22:21:46 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0DBF08FC0C for ; Wed, 16 Nov 2011 22:21:45 +0000 (UTC) Received: by yenl11 with SMTP id l11so355736yen.13 for ; Wed, 16 Nov 2011 14:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=yjrwqdsUU3D0M1f0tUhH7JTrBnVrTKTaKFEWGZ09dKo=; b=d9gKsm24Ey/6AbeUU+E/ehPCt9zmVObMAMQC5VL+2wqOHPrO0HtYiLoEkSpzKkQ2nr orKAS9puQl9VISfMbTfzJt0ghbBc+vOtTaeKe9y01etd2e/6GTlHaTIDuL9jRT62Jleh uxhLG6a2Dpsym0uEM1UzYMbh6Eqv59PS/2XzU= MIME-Version: 1.0 Received: by 10.101.206.33 with SMTP id i33mr10473041anq.65.1321480774090; Wed, 16 Nov 2011 13:59:34 -0800 (PST) Sender: maksim.yevmenkin@gmail.com Received: by 10.100.122.19 with HTTP; Wed, 16 Nov 2011 13:59:33 -0800 (PST) Date: Wed, 16 Nov 2011 13:59:33 -0800 X-Google-Sender-Auth: mLHzpJMH698KoasILjRjdZSUkRw Message-ID: From: Maksim Yevmenkin To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: mav@FreeBSD.org Subject: [RFC] ahci(4) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 22:21:46 -0000 hello, would anyone object to the following ahci(4) patch? == --- ahci.c.orig 2011-11-16 21:35:26.000000000 +0000 +++ ahci.c 2011-11-16 21:35:41.000000000 +0000 @@ -500,7 +500,7 @@ for (unit = 0; unit < ctlr->channels; unit++) { if ((ctlr->ichannels & (1 << unit)) == 0) continue; - child = device_add_child(dev, "ahcich", -1); + child = device_add_child(dev, "ahcich", unit); if (child == NULL) device_printf(dev, "failed to add channel device\n"); else == the idea is to have "static" numbering for ada(4) disks. thanks, max From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 22:33:51 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 782B1106564A; Wed, 16 Nov 2011 22:33:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2B95D8FC12; Wed, 16 Nov 2011 22:33:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAGMXovv058284; Wed, 16 Nov 2011 17:33:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAGMXoCC058267; Wed, 16 Nov 2011 22:33:50 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 16 Nov 2011 22:33:50 GMT Message-Id: <201111162233.pAGMXoCC058267@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 22:33:51 -0000 TB --- 2011-11-16 20:50:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-16 20:50:01 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-16 20:50:01 - cleaning the object tree TB --- 2011-11-16 20:50:27 - cvsupping the source tree TB --- 2011-11-16 20:50:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-16 20:50:52 - building world TB --- 2011-11-16 20:50:52 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 20:50:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 20:50:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 20:50:52 - SRCCONF=/dev/null TB --- 2011-11-16 20:50:52 - TARGET=arm TB --- 2011-11-16 20:50:52 - TARGET_ARCH=arm TB --- 2011-11-16 20:50:52 - TZ=UTC TB --- 2011-11-16 20:50:52 - __MAKE_CONF=/dev/null TB --- 2011-11-16 20:50:52 - cd /src TB --- 2011-11-16 20:50:52 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 16 20:50:52 UTC 2011 >>> 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 Wed Nov 16 21:45:02 UTC 2011 TB --- 2011-11-16 21:45:02 - cd /src/sys/arm/conf TB --- 2011-11-16 21:45:02 - /usr/sbin/config -m AVILA TB --- 2011-11-16 21:45:02 - building AVILA kernel TB --- 2011-11-16 21:45:02 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 21:45:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 21:45:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 21:45:02 - SRCCONF=/dev/null TB --- 2011-11-16 21:45:02 - TARGET=arm TB --- 2011-11-16 21:45:02 - TARGET_ARCH=arm TB --- 2011-11-16 21:45:02 - TZ=UTC TB --- 2011-11-16 21:45:02 - __MAKE_CONF=/dev/null TB --- 2011-11-16 21:45:02 - cd /src TB --- 2011-11-16 21:45:02 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Wed Nov 16 21:45:03 UTC 2011 >>> 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 >>> Kernel build for AVILA completed on Wed Nov 16 21:48:33 UTC 2011 TB --- 2011-11-16 21:48:33 - cd /src/sys/arm/conf TB --- 2011-11-16 21:48:33 - /usr/sbin/config -m BWCT TB --- 2011-11-16 21:48:33 - building BWCT kernel TB --- 2011-11-16 21:48:33 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 21:48:33 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 21:48:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 21:48:33 - SRCCONF=/dev/null TB --- 2011-11-16 21:48:33 - TARGET=arm TB --- 2011-11-16 21:48:33 - TARGET_ARCH=arm TB --- 2011-11-16 21:48:33 - TZ=UTC TB --- 2011-11-16 21:48:33 - __MAKE_CONF=/dev/null TB --- 2011-11-16 21:48:33 - cd /src TB --- 2011-11-16 21:48:33 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Wed Nov 16 21:48:33 UTC 2011 >>> 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 >>> Kernel build for BWCT completed on Wed Nov 16 21:50:40 UTC 2011 TB --- 2011-11-16 21:50:40 - cd /src/sys/arm/conf TB --- 2011-11-16 21:50:40 - /usr/sbin/config -m CAMBRIA TB --- 2011-11-16 21:50:41 - building CAMBRIA kernel TB --- 2011-11-16 21:50:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 21:50:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 21:50:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 21:50:41 - SRCCONF=/dev/null TB --- 2011-11-16 21:50:41 - TARGET=arm TB --- 2011-11-16 21:50:41 - TARGET_ARCH=arm TB --- 2011-11-16 21:50:41 - TZ=UTC TB --- 2011-11-16 21:50:41 - __MAKE_CONF=/dev/null TB --- 2011-11-16 21:50:41 - cd /src TB --- 2011-11-16 21:50:41 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Wed Nov 16 21:50:41 UTC 2011 >>> 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 >>> Kernel build for CAMBRIA completed on Wed Nov 16 21:53:37 UTC 2011 TB --- 2011-11-16 21:53:37 - cd /src/sys/arm/conf TB --- 2011-11-16 21:53:37 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-11-16 21:53:42 - building CNS11XXNAS kernel TB --- 2011-11-16 21:53:42 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 21:53:42 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 21:53:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 21:53:42 - SRCCONF=/dev/null TB --- 2011-11-16 21:53:42 - TARGET=arm TB --- 2011-11-16 21:53:42 - TARGET_ARCH=arm TB --- 2011-11-16 21:53:42 - TZ=UTC TB --- 2011-11-16 21:53:42 - __MAKE_CONF=/dev/null TB --- 2011-11-16 21:53:42 - cd /src TB --- 2011-11-16 21:53:42 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Wed Nov 16 21:53:42 UTC 2011 >>> 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 >>> Kernel build for CNS11XXNAS completed on Wed Nov 16 21:56:09 UTC 2011 TB --- 2011-11-16 21:56:09 - cd /src/sys/arm/conf TB --- 2011-11-16 21:56:09 - /usr/sbin/config -m CRB TB --- 2011-11-16 21:56:09 - building CRB kernel TB --- 2011-11-16 21:56:09 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 21:56:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 21:56:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 21:56:09 - SRCCONF=/dev/null TB --- 2011-11-16 21:56:09 - TARGET=arm TB --- 2011-11-16 21:56:09 - TARGET_ARCH=arm TB --- 2011-11-16 21:56:09 - TZ=UTC TB --- 2011-11-16 21:56:09 - __MAKE_CONF=/dev/null TB --- 2011-11-16 21:56:09 - cd /src TB --- 2011-11-16 21:56:09 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Wed Nov 16 21:56:09 UTC 2011 >>> 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 >>> Kernel build for CRB completed on Wed Nov 16 21:59:52 UTC 2011 TB --- 2011-11-16 21:59:52 - cd /src/sys/arm/conf TB --- 2011-11-16 21:59:52 - /usr/sbin/config -m DB-78XXX TB --- 2011-11-16 21:59:52 - building DB-78XXX kernel TB --- 2011-11-16 21:59:52 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 21:59:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 21:59:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 21:59:52 - SRCCONF=/dev/null TB --- 2011-11-16 21:59:52 - TARGET=arm TB --- 2011-11-16 21:59:52 - TARGET_ARCH=arm TB --- 2011-11-16 21:59:52 - TZ=UTC TB --- 2011-11-16 21:59:52 - __MAKE_CONF=/dev/null TB --- 2011-11-16 21:59:52 - cd /src TB --- 2011-11-16 21:59:52 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Wed Nov 16 21:59:52 UTC 2011 >>> 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 >>> Kernel build for DB-78XXX completed on Wed Nov 16 22:02:39 UTC 2011 TB --- 2011-11-16 22:02:39 - cd /src/sys/arm/conf TB --- 2011-11-16 22:02:39 - /usr/sbin/config -m DB-88F5XXX TB --- 2011-11-16 22:02:39 - building DB-88F5XXX kernel TB --- 2011-11-16 22:02:39 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 22:02:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 22:02:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 22:02:39 - SRCCONF=/dev/null TB --- 2011-11-16 22:02:39 - TARGET=arm TB --- 2011-11-16 22:02:39 - TARGET_ARCH=arm TB --- 2011-11-16 22:02:39 - TZ=UTC TB --- 2011-11-16 22:02:39 - __MAKE_CONF=/dev/null TB --- 2011-11-16 22:02:39 - cd /src TB --- 2011-11-16 22:02:39 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Wed Nov 16 22:02:39 UTC 2011 >>> 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 >>> Kernel build for DB-88F5XXX completed on Wed Nov 16 22:05:19 UTC 2011 TB --- 2011-11-16 22:05:19 - cd /src/sys/arm/conf TB --- 2011-11-16 22:05:19 - /usr/sbin/config -m DB-88F6XXX TB --- 2011-11-16 22:05:19 - building DB-88F6XXX kernel TB --- 2011-11-16 22:05:19 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 22:05:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 22:05:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 22:05:19 - SRCCONF=/dev/null TB --- 2011-11-16 22:05:19 - TARGET=arm TB --- 2011-11-16 22:05:19 - TARGET_ARCH=arm TB --- 2011-11-16 22:05:19 - TZ=UTC TB --- 2011-11-16 22:05:19 - __MAKE_CONF=/dev/null TB --- 2011-11-16 22:05:19 - cd /src TB --- 2011-11-16 22:05:19 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Wed Nov 16 22:05:19 UTC 2011 >>> 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 >>> Kernel build for DB-88F6XXX completed on Wed Nov 16 22:07:57 UTC 2011 TB --- 2011-11-16 22:07:57 - cd /src/sys/arm/conf TB --- 2011-11-16 22:07:57 - /usr/sbin/config -m DOCKSTAR TB --- 2011-11-16 22:07:57 - building DOCKSTAR kernel TB --- 2011-11-16 22:07:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 22:07:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 22:07:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 22:07:57 - SRCCONF=/dev/null TB --- 2011-11-16 22:07:57 - TARGET=arm TB --- 2011-11-16 22:07:57 - TARGET_ARCH=arm TB --- 2011-11-16 22:07:57 - TZ=UTC TB --- 2011-11-16 22:07:57 - __MAKE_CONF=/dev/null TB --- 2011-11-16 22:07:57 - cd /src TB --- 2011-11-16 22:07:57 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Wed Nov 16 22:07:57 UTC 2011 >>> 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 >>> Kernel build for DOCKSTAR completed on Wed Nov 16 22:10:59 UTC 2011 TB --- 2011-11-16 22:10:59 - cd /src/sys/arm/conf TB --- 2011-11-16 22:10:59 - /usr/sbin/config -m EP80219 TB --- 2011-11-16 22:10:59 - building EP80219 kernel TB --- 2011-11-16 22:10:59 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 22:10:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 22:10:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 22:10:59 - SRCCONF=/dev/null TB --- 2011-11-16 22:10:59 - TARGET=arm TB --- 2011-11-16 22:10:59 - TARGET_ARCH=arm TB --- 2011-11-16 22:10:59 - TZ=UTC TB --- 2011-11-16 22:10:59 - __MAKE_CONF=/dev/null TB --- 2011-11-16 22:10:59 - cd /src TB --- 2011-11-16 22:10:59 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Wed Nov 16 22:10:59 UTC 2011 >>> 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 >>> Kernel build for EP80219 completed on Wed Nov 16 22:13:50 UTC 2011 TB --- 2011-11-16 22:13:51 - WARNING: no kernel config for GENERIC TB --- 2011-11-16 22:13:51 - cd /src/sys/arm/conf TB --- 2011-11-16 22:13:51 - /usr/sbin/config -m GUMSTIX TB --- 2011-11-16 22:13:54 - building GUMSTIX kernel TB --- 2011-11-16 22:13:54 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 22:13:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 22:13:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 22:13:54 - SRCCONF=/dev/null TB --- 2011-11-16 22:13:54 - TARGET=arm TB --- 2011-11-16 22:13:54 - TARGET_ARCH=arm TB --- 2011-11-16 22:13:54 - TZ=UTC TB --- 2011-11-16 22:13:54 - __MAKE_CONF=/dev/null TB --- 2011-11-16 22:13:54 - cd /src TB --- 2011-11-16 22:13:54 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Wed Nov 16 22:13:54 UTC 2011 >>> 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 >>> Kernel build for GUMSTIX completed on Wed Nov 16 22:16:13 UTC 2011 TB --- 2011-11-16 22:16:13 - cd /src/sys/arm/conf TB --- 2011-11-16 22:16:13 - /usr/sbin/config -m HL200 TB --- 2011-11-16 22:16:13 - building HL200 kernel TB --- 2011-11-16 22:16:13 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 22:16:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 22:16:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 22:16:13 - SRCCONF=/dev/null TB --- 2011-11-16 22:16:13 - TARGET=arm TB --- 2011-11-16 22:16:13 - TARGET_ARCH=arm TB --- 2011-11-16 22:16:13 - TZ=UTC TB --- 2011-11-16 22:16:13 - __MAKE_CONF=/dev/null TB --- 2011-11-16 22:16:13 - cd /src TB --- 2011-11-16 22:16:13 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Wed Nov 16 22:16:13 UTC 2011 >>> 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 >>> Kernel build for HL200 completed on Wed Nov 16 22:18:50 UTC 2011 TB --- 2011-11-16 22:18:50 - cd /src/sys/arm/conf TB --- 2011-11-16 22:18:50 - /usr/sbin/config -m HL201 TB --- 2011-11-16 22:18:50 - building HL201 kernel TB --- 2011-11-16 22:18:50 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 22:18:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 22:18:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 22:18:50 - SRCCONF=/dev/null TB --- 2011-11-16 22:18:50 - TARGET=arm TB --- 2011-11-16 22:18:50 - TARGET_ARCH=arm TB --- 2011-11-16 22:18:50 - TZ=UTC TB --- 2011-11-16 22:18:50 - __MAKE_CONF=/dev/null TB --- 2011-11-16 22:18:50 - cd /src TB --- 2011-11-16 22:18:50 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Wed Nov 16 22:18:50 UTC 2011 >>> 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 >>> Kernel build for HL201 completed on Wed Nov 16 22:21:38 UTC 2011 TB --- 2011-11-16 22:21:38 - cd /src/sys/arm/conf TB --- 2011-11-16 22:21:38 - /usr/sbin/config -m IQ31244 TB --- 2011-11-16 22:21:40 - building IQ31244 kernel TB --- 2011-11-16 22:21:40 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 22:21:40 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 22:21:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 22:21:40 - SRCCONF=/dev/null TB --- 2011-11-16 22:21:40 - TARGET=arm TB --- 2011-11-16 22:21:40 - TARGET_ARCH=arm TB --- 2011-11-16 22:21:40 - TZ=UTC TB --- 2011-11-16 22:21:40 - __MAKE_CONF=/dev/null TB --- 2011-11-16 22:21:40 - cd /src TB --- 2011-11-16 22:21:40 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Wed Nov 16 22:21:40 UTC 2011 >>> 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 >>> Kernel build for IQ31244 completed on Wed Nov 16 22:24:54 UTC 2011 TB --- 2011-11-16 22:24:54 - cd /src/sys/arm/conf TB --- 2011-11-16 22:24:54 - /usr/sbin/config -m KB920X TB --- 2011-11-16 22:24:54 - building KB920X kernel TB --- 2011-11-16 22:24:54 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 22:24:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 22:24:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 22:24:54 - SRCCONF=/dev/null TB --- 2011-11-16 22:24:54 - TARGET=arm TB --- 2011-11-16 22:24:54 - TARGET_ARCH=arm TB --- 2011-11-16 22:24:54 - TZ=UTC TB --- 2011-11-16 22:24:54 - __MAKE_CONF=/dev/null TB --- 2011-11-16 22:24:54 - cd /src TB --- 2011-11-16 22:24:54 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Wed Nov 16 22:24:54 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-16 22:33:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-16 22:33:49 - ERROR: failed to build KB920X kernel TB --- 2011-11-16 22:33:49 - 4638.68 user 1145.70 system 6228.78 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 22:35:40 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B047D1065673 for ; Wed, 16 Nov 2011 22:35:40 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3AFBE8FC12 for ; Wed, 16 Nov 2011 22:35:39 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so1599821bkb.13 for ; Wed, 16 Nov 2011 14:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gFIkbonxzgnwvFnE5nPRjG0dg/+jY4Twudzvmgsm8uc=; b=ghBWUQurG6REYko2eAVtnP3U5iNpUpkZzejq+9em1mghCD2pDyieFQPaD9ovu+ke0m NoTsGjdZ6JNUjSjbfGoQKrJqL8v/vVsuAuILAkPepCFI+xeOCHLgS7pbli8eg6m9XhQ8 rLcBckg3KZJyF/9U084lrVYUzkqcgUmHALrOo= Received: by 10.204.152.87 with SMTP id f23mr22588447bkw.18.1321482938714; Wed, 16 Nov 2011 14:35:38 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id w11sm77646fad.7.2011.11.16.14.35.37 (version=SSLv3 cipher=OTHER); Wed, 16 Nov 2011 14:35:37 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC43ABA.7060407@FreeBSD.org> Date: Thu, 17 Nov 2011 00:35:38 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: Maksim Yevmenkin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: [RFC] ahci(4) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 22:35:40 -0000 Hi. On 16.11.2011 23:59, Maksim Yevmenkin wrote: > would anyone object to the following ahci(4) patch? > > == > > --- ahci.c.orig 2011-11-16 21:35:26.000000000 +0000 > +++ ahci.c 2011-11-16 21:35:41.000000000 +0000 > @@ -500,7 +500,7 @@ > for (unit = 0; unit< ctlr->channels; unit++) { > if ((ctlr->ichannels& (1<< unit)) == 0) > continue; > - child = device_add_child(dev, "ahcich", -1); > + child = device_add_child(dev, "ahcich", unit); > if (child == NULL) > device_printf(dev, "failed to add channel device\n"); > else > > == > > the idea is to have "static" numbering for ada(4) disks. I do. The only way I see this useful is if you have BIOS configured for non-hot-swappable disks, in which case you have some AHCI channels disabled, but want to keep numbers of the rest. While I don't like this mode in general, especially when it can't be disabled, that patch could be useful in these cases. But in other cases, when you have several AHCI controllers, it just wont not work. You will receive error on attempt to create second ahcich0. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 22:44:25 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A78B2106566B; Wed, 16 Nov 2011 22:44:25 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1FBA48FC08; Wed, 16 Nov 2011 22:44:25 +0000 (UTC) Received: by ywe9 with SMTP id 9so400366ywe.13 for ; Wed, 16 Nov 2011 14:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yDjf+b5F9Kld/aWyMVLaxJh3OqO6xpEr6gNU5vDl5oQ=; b=veVNNRzkjCu9nyzm7KlZHfxB5Cgr3VImEjA1Q4QV1HNOzgRe+Ze1JPdsEXhNbJsBYl iZ4C8PoZR1IZOkQ2fllkTt9ifo+oSXqf0noIXK0vBXNamuQU0deWna1mQjLlhaHzRvzf CP4+2bFXu2QoU4HsU5JEUjwQRbm8GUwNvlpKY= MIME-Version: 1.0 Received: by 10.101.206.33 with SMTP id i33mr10501839anq.65.1321483464583; Wed, 16 Nov 2011 14:44:24 -0800 (PST) Sender: maksim.yevmenkin@gmail.com Received: by 10.100.122.19 with HTTP; Wed, 16 Nov 2011 14:44:24 -0800 (PST) In-Reply-To: <4EC43ABA.7060407@FreeBSD.org> References: <4EC43ABA.7060407@FreeBSD.org> Date: Wed, 16 Nov 2011 14:44:24 -0800 X-Google-Sender-Auth: Smh9Y2G-sWfZnJHquQtz8ySbJuM Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: [RFC] ahci(4) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 22:44:25 -0000 On Wed, Nov 16, 2011 at 2:35 PM, Alexander Motin wrote: > Hi. > > On 16.11.2011 23:59, Maksim Yevmenkin wrote: >> >> would anyone object to the following ahci(4) patch? >> >> =3D=3D >> >> --- ahci.c.orig 2011-11-16 21:35:26.000000000 +0000 >> +++ ahci.c =A0 =A0 =A02011-11-16 21:35:41.000000000 +0000 >> @@ -500,7 +500,7 @@ >> =A0 =A0 =A0 =A0for (unit =3D 0; unit< =A0ctlr->channels; unit++) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ((ctlr->ichannels& =A0(1<< =A0unit)) = =3D=3D 0) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 child =3D device_add_child(dev, "ahcich", = -1); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 child =3D device_add_child(dev, "ahcich", = unit); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (child =3D=3D NULL) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_printf(dev, "faile= d to add channel >> device\n"); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else >> >> =3D=3D >> >> the idea is to have "static" numbering for ada(4) disks. > > I do. The only way I see this useful is if you have BIOS configured for > non-hot-swappable disks, in which case you have some AHCI channels disabl= ed, > but want to keep numbers of the rest. While I don't like this mode in > general, especially when it can't be disabled, that patch could be useful= in > these cases. But in other cases, when you have several AHCI controllers, = it > just wont not work. You will receive error on attempt to create second > ahcich0. shouldn't achcichX be destroyed when disk is detached/removed/etc.? the particular problem i'm trying to address is disk re-numbering when one of the disks fails/removed/etc. i'm trying to use hints to wire disks to controllers/busses. it works perfectly fine with da(4) disks (even hot swappable ones) , but i can not make it to work with ada(4) disks. i'm perfectly fine to hid this under some sort of option (something similar to ATA_STATIC_ID, AHCI_STATIC_ID for example) thanks, max From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 22:59:26 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29865106564A; Wed, 16 Nov 2011 22:59:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6ECCC8FC14; Wed, 16 Nov 2011 22:59:25 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so1634515bkb.13 for ; Wed, 16 Nov 2011 14:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FAepnCfv8uznzNllpsBrrklCJnYVgNxyPPdrOnTvguI=; b=x9yb21lUeYYhl50KCvsUN7azK+A39QfXe6II4OvoGr2umdopSMZ55DKsvG5eVvx9hx 0WU1wNK2y+xJq2WBevZ4l8ahMh6+GlrA8WrNe3v6U0STnm4DJaga2QGECyR76ZgcP3JU bWbPXf3Qi6qTI8nzKcrBqsFhmQ9XVITWc95G8= Received: by 10.205.128.138 with SMTP id he10mr30851198bkc.13.1321484364079; Wed, 16 Nov 2011 14:59:24 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id e20sm142135fab.2.2011.11.16.14.59.22 (version=SSLv3 cipher=OTHER); Wed, 16 Nov 2011 14:59:23 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC4404B.4070008@FreeBSD.org> Date: Thu, 17 Nov 2011 00:59:23 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: Maksim Yevmenkin References: <4EC43ABA.7060407@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: [RFC] ahci(4) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 22:59:26 -0000 On 17.11.2011 00:44, Maksim Yevmenkin wrote: > On Wed, Nov 16, 2011 at 2:35 PM, Alexander Motin wrote: >> On 16.11.2011 23:59, Maksim Yevmenkin wrote: >>> >>> would anyone object to the following ahci(4) patch? >>> >>> == >>> >>> --- ahci.c.orig 2011-11-16 21:35:26.000000000 +0000 >>> +++ ahci.c 2011-11-16 21:35:41.000000000 +0000 >>> @@ -500,7 +500,7 @@ >>> for (unit = 0; unit< ctlr->channels; unit++) { >>> if ((ctlr->ichannels& (1<< unit)) == 0) >>> continue; >>> - child = device_add_child(dev, "ahcich", -1); >>> + child = device_add_child(dev, "ahcich", unit); >>> if (child == NULL) >>> device_printf(dev, "failed to add channel >>> device\n"); >>> else >>> >>> == >>> >>> the idea is to have "static" numbering for ada(4) disks. >> >> I do. The only way I see this useful is if you have BIOS configured for >> non-hot-swappable disks, in which case you have some AHCI channels disabled, >> but want to keep numbers of the rest. While I don't like this mode in >> general, especially when it can't be disabled, that patch could be useful in >> these cases. But in other cases, when you have several AHCI controllers, it >> just wont not work. You will receive error on attempt to create second >> ahcich0. > > shouldn't achcichX be destroyed when disk is detached/removed/etc.? List of implemented AHCI channels to expose as ahcichX set by BIOS in vendor-specific way, but only during boot and not by many BIOSes. Destroying them on disk detach theoretically possible, but IMHO not right, as bus doesn't disappear on disk disconnect. > the particular problem i'm trying to address is disk re-numbering when > one of the disks fails/removed/etc. i'm trying to use hints to wire > disks to controllers/busses. it works perfectly fine with da(4) disks > (even hot swappable ones) , but i can not make it to work with ada(4) > disks. i'm perfectly fine to hid this under some sort of option > (something similar to ATA_STATIC_ID, AHCI_STATIC_ID for example) Wiring works for adaX also, unless your BIOS is so "intelligent" to report unconnected ports and not impliemented.. You should just wire CAM buses to ahcichX, not to ahciX. It could be done in other way changing just by one line around xpt_bus_register(), but now it is done so. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 23:07:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3D47106566C; Wed, 16 Nov 2011 23:07:40 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D62188FC16; Wed, 16 Nov 2011 23:07:39 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so1644984bkb.13 for ; Wed, 16 Nov 2011 15:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fV6khi+peTcjw0/mtHuGhDNDaJ269FN8CgWcrOlwtyI=; b=aB7/OphXFhMsHwbzANAHWS92D7vhNIZ/4oTAeLfWVjm+Pmh7OH8CixE9NMSLld1Wy/ 8rOSwJbWU2vjsUcU/NCZ5CSkcmiwkSqaxeNPu/hDi51GIgbB/oRF44V6NGcKfJCNKriz KWOnOlIE6jQioc/AHv6+f/CO6YzvpEdD6EVvU= Received: by 10.204.136.200 with SMTP id s8mr21650114bkt.49.1321484858712; Wed, 16 Nov 2011 15:07:38 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id a21sm138036fao.18.2011.11.16.15.07.36 (version=SSLv3 cipher=OTHER); Wed, 16 Nov 2011 15:07:37 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC4423A.3020904@FreeBSD.org> Date: Thu, 17 Nov 2011 01:07:38 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111112 Thunderbird/8.0 MIME-Version: 1.0 To: Andriy Gapon References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <20111116202714.5ee4bd53@fabiankeil.de> <4EC43764.1020202@FreeBSD.org> In-Reply-To: <4EC43764.1020202@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Konstantin Belousov Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 23:07:40 -0000 On 17.11.2011 00:21, Andriy Gapon wrote: > on 16/11/2011 21:27 Fabian Keil said the following: >> Kostik Belousov wrote: >> >>> I was tricked into finishing the work by Andrey Gapon, who developed >>> the patch to reliably stop other processors on panic. The patch >>> greatly improves the chances of getting dump on panic on SMP host. >> >> I tested the patch trying to get a dump (from the debugger) for >> kern/162036, which currently results in the double fault reported in: >> http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027766.html >> >> It didn't help, but also didn't make anything worse. >> >> Fabian > > The mi_switch recursion looks very familiar to me: > mi_switch() at mi_switch+0x270 > critical_exit() at critical_exit+0x9b > spinlock_exit() at spinlock_exit+0x17 > mi_switch() at mi_switch+0x275 > critical_exit() at critical_exit+0x9b > spinlock_exit() at spinlock_exit+0x17 > [several pages of the previous three lines skipped] > mi_switch() at mi_switch+0x275 > critical_exit() at critical_exit+0x9b > spinlock_exit() at spinlock_exit+0x17 > intr_even_schedule_thread() at intr_event_schedule_thread+0xbb > ahci_end_transaction() at ahci_end_transaction+0x398 > ahci_ch_intr() at ahci_ch_intr+0x2b5 > ahcipoll() at ahcipoll+0x15 > xpt_polled_action() at xpt_polled_action+0xf7 > > In fact I once discussed with jhb this recursion triggered from a different > place. To quote myself: > spinlock_exit -> critical_exit -> mi_switch -> kdb_switch -> > thread_unlock -> spinlock_exit -> critical_exit -> mi_switch -> ... > in the kdb context > this issue seems to be triggered by td_owepreempt being true at the time > kdb is entered > and there of course has to be an initial spinlock_exit call somewhere > in my case it's because of usb keyboard > I wonder if it would make sense to clear td_owepreempt right before > calling kdb_switch in mi_switch > instead of in sched_switch() > clearing td_owepreempt seems like a scheduler-independent operation to me > or is it better to just skip locking in usb when kdb_active is set > ? > > The workaround described above should work in this case. > Another possibility is to pessimize mtx_unlock_spin() implementations to check > SCHEDULER_STOPPED() and to bypass any further actions in that case. But that > would add unnecessary overhead to the sunny day code paths. > > Going further up the stack one can come up with the following proposals: > - check SCHEDULER_STOPPED() swi_sched() and return early > - do not call swi_sched() from xpt_done() if we somehow know that we are in a > polling mode There is no flag in CAM now to indicate polling mode, but if needed, it should not be difficult to add one and not call swi_sched(). -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 23:08:55 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84C8E1065670; Wed, 16 Nov 2011 23:08:55 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id A854A8FC0A; Wed, 16 Nov 2011 23:08:54 +0000 (UTC) Received: by ggnk3 with SMTP id k3so425364ggn.13 for ; Wed, 16 Nov 2011 15:08:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pButlvHzIXtawxHMQ/U/fiYUPuU9FM3hqMuTeA+ZV2w=; b=hjgc2/gzHXBD3/qpIB3N+Dz4WoXF0X7nl6FWyoMliWj6deAlVQMmAfyhiB4tCAfDiv rc6T9DebsJBse71ZgozoI36ABG6eg8H1b/h00UYC6zaeYxXpvx1sKxv9yEwldhVao/JJ C4l4HlAMevq0FqbZs2XJrW3MdoxMFF+6NP/ZE= MIME-Version: 1.0 Received: by 10.101.206.33 with SMTP id i33mr10517282anq.65.1321484934147; Wed, 16 Nov 2011 15:08:54 -0800 (PST) Sender: maksim.yevmenkin@gmail.com Received: by 10.100.122.19 with HTTP; Wed, 16 Nov 2011 15:08:54 -0800 (PST) In-Reply-To: <4EC4404B.4070008@FreeBSD.org> References: <4EC43ABA.7060407@FreeBSD.org> <4EC4404B.4070008@FreeBSD.org> Date: Wed, 16 Nov 2011 15:08:54 -0800 X-Google-Sender-Auth: 1m5tEueE96MNdlTaeIaVBf62qiM Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: [RFC] ahci(4) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 23:08:55 -0000 On Wed, Nov 16, 2011 at 2:59 PM, Alexander Motin wrote: > On 17.11.2011 00:44, Maksim Yevmenkin wrote: >> >> On Wed, Nov 16, 2011 at 2:35 PM, Alexander Motin =A0wro= te: >>> >>> On 16.11.2011 23:59, Maksim Yevmenkin wrote: >>>> >>>> would anyone object to the following ahci(4) patch? >>>> >>>> =3D=3D >>>> >>>> --- ahci.c.orig 2011-11-16 21:35:26.000000000 +0000 >>>> +++ ahci.c =A0 =A0 =A02011-11-16 21:35:41.000000000 +0000 >>>> @@ -500,7 +500,7 @@ >>>> =A0 =A0 =A0 =A0for (unit =3D 0; unit< =A0 =A0ctlr->channels; unit++) { >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ((ctlr->ichannels& =A0 =A0(1<< =A0 = =A0unit)) =3D=3D 0) >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; >>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 child =3D device_add_child(dev, "ahcich"= , -1); >>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 child =3D device_add_child(dev, "ahcich"= , unit); >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (child =3D=3D NULL) >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_printf(dev, "fai= led to add channel >>>> device\n"); >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else >>>> >>>> =3D=3D >>>> >>>> the idea is to have "static" numbering for ada(4) disks. >>> >>> I do. The only way I see this useful is if you have BIOS configured for >>> non-hot-swappable disks, in which case you have some AHCI channels >>> disabled, >>> but want to keep numbers of the rest. While I don't like this mode in >>> general, especially when it can't be disabled, that patch could be usef= ul >>> in >>> these cases. But in other cases, when you have several AHCI controllers= , >>> it >>> just wont not work. You will receive error on attempt to create second >>> ahcich0. >> >> shouldn't achcichX be destroyed when disk is detached/removed/etc.? > > List of implemented AHCI channels to expose as ahcichX set by BIOS in > vendor-specific way, but only during boot and not by many BIOSes. Destroy= ing > them on disk detach theoretically possible, but IMHO not right, as bus > doesn't disappear on disk disconnect. > >> the particular problem i'm trying to address is disk re-numbering when >> one of the disks fails/removed/etc. i'm trying to use hints to wire >> disks to controllers/busses. it works perfectly fine with da(4) disks >> (even hot swappable ones) , but i can not make it to work with ada(4) >> disks. i'm perfectly fine to hid this under some sort of option >> (something similar to ATA_STATIC_ID, AHCI_STATIC_ID for example) > > Wiring works for adaX also, unless your BIOS is so "intelligent" to repor= t > unconnected ports and not impliemented.. You should just wire CAM buses t= o > ahcichX, not to ahciX. It could be done in other way changing just by one > line around xpt_bus_register(), but now it is done so. ok. then i must be missing something, here is what i have in device.hints hint.scbus.0.at=3D"umass-sim0" hint.scbus.1.at=3D"ahcich0" hint.scbus.2.at=3D"ahcich1" hint.scbus.3.at=3D"ahcich2" hint.scbus.4.at=3D"ahcich3" hint.scbus.5.at=3D"ahcich4" hint.scbus.6.at=3D"ahcich5" hint.da.0.at=3D"scbus0" hint.ada.0.at=3D"scbus1" hint.ada.1.at=3D"scbus2" hint.ada.2.at=3D"scbus3" hint.ada.3.at=3D"scbus4" hint.ada.4.at=3D"scbus5" hint.ada.5.at=3D"scbus6" this is for 6-port ahci(4) compatible controller (intel) on the motherboard. no matter which achi(4) ports are connected, resulted adaX devices are always sequential starting from ada0. so, the question is: what am i doing wrong here? thanks, max From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 23:14:48 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 202B910656AC; Wed, 16 Nov 2011 23:14:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DF44B8FC13; Wed, 16 Nov 2011 23:14:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAGNElqk061262; Wed, 16 Nov 2011 18:14:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAGNElgC061227; Wed, 16 Nov 2011 23:14:47 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 16 Nov 2011 23:14:47 GMT Message-Id: <201111162314.pAGNElgC061227@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 23:14:48 -0000 TB --- 2011-11-16 20:50:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-16 20:50:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-16 20:50:01 - cleaning the object tree TB --- 2011-11-16 20:50:23 - cvsupping the source tree TB --- 2011-11-16 20:50:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-16 20:50:52 - building world TB --- 2011-11-16 20:50:52 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 20:50:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 20:50:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 20:50:52 - SRCCONF=/dev/null TB --- 2011-11-16 20:50:52 - TARGET=pc98 TB --- 2011-11-16 20:50:52 - TARGET_ARCH=i386 TB --- 2011-11-16 20:50:52 - TZ=UTC TB --- 2011-11-16 20:50:52 - __MAKE_CONF=/dev/null TB --- 2011-11-16 20:50:52 - cd /src TB --- 2011-11-16 20:50:52 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 16 20:50:52 UTC 2011 >>> 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 Wed Nov 16 22:59:15 UTC 2011 TB --- 2011-11-16 22:59:15 - generating LINT kernel config TB --- 2011-11-16 22:59:15 - cd /src/sys/pc98/conf TB --- 2011-11-16 22:59:15 - /usr/bin/make -B LINT TB --- 2011-11-16 22:59:15 - cd /src/sys/pc98/conf TB --- 2011-11-16 22:59:15 - /usr/sbin/config -m GENERIC TB --- 2011-11-16 22:59:15 - building GENERIC kernel TB --- 2011-11-16 22:59:15 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 22:59:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 22:59:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 22:59:15 - SRCCONF=/dev/null TB --- 2011-11-16 22:59:15 - TARGET=pc98 TB --- 2011-11-16 22:59:15 - TARGET_ARCH=i386 TB --- 2011-11-16 22:59:15 - TZ=UTC TB --- 2011-11-16 22:59:15 - __MAKE_CONF=/dev/null TB --- 2011-11-16 22:59:15 - cd /src TB --- 2011-11-16 22:59:15 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Nov 16 22:59:15 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-16 23:14:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-16 23:14:46 - ERROR: failed to build GENERIC kernel TB --- 2011-11-16 23:14:46 - 6931.77 user 1218.14 system 8685.56 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 23:32:19 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47D9A1065673; Wed, 16 Nov 2011 23:32:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 12B248FC08; Wed, 16 Nov 2011 23:32:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAGNWIVo090921; Wed, 16 Nov 2011 18:32:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAGNWIJa090914; Wed, 16 Nov 2011 23:32:18 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 16 Nov 2011 23:32:18 GMT Message-Id: <201111162332.pAGNWIJa090914@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 23:32:19 -0000 TB --- 2011-11-16 20:50:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-16 20:50:01 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-16 20:50:01 - cleaning the object tree TB --- 2011-11-16 20:50:43 - cvsupping the source tree TB --- 2011-11-16 20:50:43 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-16 20:56:06 - building world TB --- 2011-11-16 20:56:06 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 20:56:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 20:56:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 20:56:06 - SRCCONF=/dev/null TB --- 2011-11-16 20:56:06 - TARGET=i386 TB --- 2011-11-16 20:56:06 - TARGET_ARCH=i386 TB --- 2011-11-16 20:56:06 - TZ=UTC TB --- 2011-11-16 20:56:06 - __MAKE_CONF=/dev/null TB --- 2011-11-16 20:56:06 - cd /src TB --- 2011-11-16 20:56:06 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 16 20:56:07 UTC 2011 >>> 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 Wed Nov 16 23:05:52 UTC 2011 TB --- 2011-11-16 23:05:52 - generating LINT kernel config TB --- 2011-11-16 23:05:52 - cd /src/sys/i386/conf TB --- 2011-11-16 23:05:52 - /usr/bin/make -B LINT TB --- 2011-11-16 23:05:52 - cd /src/sys/i386/conf TB --- 2011-11-16 23:05:52 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-16 23:05:52 - building LINT-NOINET kernel TB --- 2011-11-16 23:05:52 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 23:05:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 23:05:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 23:05:52 - SRCCONF=/dev/null TB --- 2011-11-16 23:05:52 - TARGET=i386 TB --- 2011-11-16 23:05:52 - TARGET_ARCH=i386 TB --- 2011-11-16 23:05:52 - TZ=UTC TB --- 2011-11-16 23:05:52 - __MAKE_CONF=/dev/null TB --- 2011-11-16 23:05:52 - cd /src TB --- 2011-11-16 23:05:52 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Wed Nov 16 23:05:52 UTC 2011 >>> 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 [...] ld -Bshareable -d -warn-common -o if_sf.ko if_sf.kld objcopy --strip-debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT-NOINET/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/i386.i386/src/sys/LINT-NOINET -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT-NOINET/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/i386.i386/src/sys/LINT-NOINET -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-16 23:32:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-16 23:32:17 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-16 23:32:17 - 7520.59 user 1272.23 system 9736.88 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 00:22:27 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 367A4106566B; Thu, 17 Nov 2011 00:22:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0ACAF8FC0C; Thu, 17 Nov 2011 00:22:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAH0MQ6V030033; Wed, 16 Nov 2011 19:22:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAH0MQp7030032; Thu, 17 Nov 2011 00:22:26 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 00:22:26 GMT Message-Id: <201111170022.pAH0MQp7030032@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 00:22:27 -0000 TB --- 2011-11-16 22:33:50 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-16 22:33:50 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-16 22:33:50 - cleaning the object tree TB --- 2011-11-16 22:34:03 - cvsupping the source tree TB --- 2011-11-16 22:34:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-16 22:34:16 - building world TB --- 2011-11-16 22:34:16 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 22:34:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 22:34:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 22:34:16 - SRCCONF=/dev/null TB --- 2011-11-16 22:34:16 - TARGET=ia64 TB --- 2011-11-16 22:34:16 - TARGET_ARCH=ia64 TB --- 2011-11-16 22:34:16 - TZ=UTC TB --- 2011-11-16 22:34:16 - __MAKE_CONF=/dev/null TB --- 2011-11-16 22:34:16 - cd /src TB --- 2011-11-16 22:34:16 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 16 22:34:16 UTC 2011 >>> 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 Thu Nov 17 00:03:02 UTC 2011 TB --- 2011-11-17 00:03:02 - generating LINT kernel config TB --- 2011-11-17 00:03:02 - cd /src/sys/ia64/conf TB --- 2011-11-17 00:03:02 - /usr/bin/make -B LINT TB --- 2011-11-17 00:03:02 - cd /src/sys/ia64/conf TB --- 2011-11-17 00:03:02 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 00:03:02 - building GENERIC kernel TB --- 2011-11-17 00:03:02 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 00:03:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 00:03:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 00:03:02 - SRCCONF=/dev/null TB --- 2011-11-17 00:03:02 - TARGET=ia64 TB --- 2011-11-17 00:03:02 - TARGET_ARCH=ia64 TB --- 2011-11-17 00:03:02 - TZ=UTC TB --- 2011-11-17 00:03:02 - __MAKE_CONF=/dev/null TB --- 2011-11-17 00:03:02 - cd /src TB --- 2011-11-17 00:03:02 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 00:03:02 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 00:22:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 00:22:25 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 00:22:25 - 5165.77 user 952.78 system 6514.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 01:45:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54D2C1065670; Thu, 17 Nov 2011 01:45:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2060B8FC0A; Thu, 17 Nov 2011 01:45:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAH1jLq5003886; Wed, 16 Nov 2011 20:45:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAH1jLgh003877; Thu, 17 Nov 2011 01:45:21 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 01:45:21 GMT Message-Id: <201111170145.pAH1jLgh003877@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 01:45:23 -0000 TB --- 2011-11-17 00:22:26 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 00:22:26 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-11-17 00:22:26 - cleaning the object tree TB --- 2011-11-17 00:22:35 - cvsupping the source tree TB --- 2011-11-17 00:22:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-11-17 00:22:46 - building world TB --- 2011-11-17 00:22:46 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 00:22:46 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 00:22:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 00:22:46 - SRCCONF=/dev/null TB --- 2011-11-17 00:22:46 - TARGET=sparc64 TB --- 2011-11-17 00:22:46 - TARGET_ARCH=sparc64 TB --- 2011-11-17 00:22:46 - TZ=UTC TB --- 2011-11-17 00:22:46 - __MAKE_CONF=/dev/null TB --- 2011-11-17 00:22:46 - cd /src TB --- 2011-11-17 00:22:46 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 00:22:47 UTC 2011 >>> 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 Thu Nov 17 01:29:06 UTC 2011 TB --- 2011-11-17 01:29:06 - generating LINT kernel config TB --- 2011-11-17 01:29:06 - cd /src/sys/sparc64/conf TB --- 2011-11-17 01:29:06 - /usr/bin/make -B LINT TB --- 2011-11-17 01:29:06 - cd /src/sys/sparc64/conf TB --- 2011-11-17 01:29:06 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 01:29:06 - building GENERIC kernel TB --- 2011-11-17 01:29:06 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 01:29:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 01:29:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 01:29:06 - SRCCONF=/dev/null TB --- 2011-11-17 01:29:06 - TARGET=sparc64 TB --- 2011-11-17 01:29:06 - TARGET_ARCH=sparc64 TB --- 2011-11-17 01:29:06 - TZ=UTC TB --- 2011-11-17 01:29:06 - __MAKE_CONF=/dev/null TB --- 2011-11-17 01:29:06 - cd /src TB --- 2011-11-17 01:29:06 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 01:29:06 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 01:45:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 01:45:20 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 01:45:20 - 3722.67 user 828.26 system 4974.22 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 01:48:04 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7726C106564A; Thu, 17 Nov 2011 01:48:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 126A78FC14; Thu, 17 Nov 2011 01:47:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAH1lwgS013886; Wed, 16 Nov 2011 20:47:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAH1lwEI013879; Thu, 17 Nov 2011 01:47:58 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 01:47:58 GMT Message-Id: <201111170147.pAH1lwEI013879@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 01:48:04 -0000 TB --- 2011-11-16 23:32:18 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-16 23:32:18 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-16 23:32:18 - cleaning the object tree TB --- 2011-11-16 23:32:32 - cvsupping the source tree TB --- 2011-11-16 23:32:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-16 23:32:45 - building world TB --- 2011-11-16 23:32:45 - CROSS_BUILD_TESTING=YES TB --- 2011-11-16 23:32:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-16 23:32:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-16 23:32:45 - SRCCONF=/dev/null TB --- 2011-11-16 23:32:45 - TARGET=powerpc TB --- 2011-11-16 23:32:45 - TARGET_ARCH=powerpc TB --- 2011-11-16 23:32:45 - TZ=UTC TB --- 2011-11-16 23:32:45 - __MAKE_CONF=/dev/null TB --- 2011-11-16 23:32:45 - cd /src TB --- 2011-11-16 23:32:45 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 16 23:32:45 UTC 2011 >>> 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 Thu Nov 17 01:34:24 UTC 2011 TB --- 2011-11-17 01:34:24 - generating LINT kernel config TB --- 2011-11-17 01:34:24 - cd /src/sys/powerpc/conf TB --- 2011-11-17 01:34:24 - /usr/bin/make -B LINT TB --- 2011-11-17 01:34:24 - cd /src/sys/powerpc/conf TB --- 2011-11-17 01:34:24 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 01:34:24 - building GENERIC kernel TB --- 2011-11-17 01:34:24 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 01:34:24 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 01:34:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 01:34:24 - SRCCONF=/dev/null TB --- 2011-11-17 01:34:24 - TARGET=powerpc TB --- 2011-11-17 01:34:24 - TARGET_ARCH=powerpc TB --- 2011-11-17 01:34:24 - TZ=UTC TB --- 2011-11-17 01:34:24 - __MAKE_CONF=/dev/null TB --- 2011-11-17 01:34:24 - cd /src TB --- 2011-11-17 01:34:24 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 01:34:24 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 01:47:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 01:47:57 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 01:47:57 - 6523.34 user 1118.18 system 8139.15 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 02:07:32 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0934106564A; Thu, 17 Nov 2011 02:07:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9C1BF8FC13; Thu, 17 Nov 2011 02:07:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAH27VHx065439; Wed, 16 Nov 2011 21:07:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAH27Vha065438; Thu, 17 Nov 2011 02:07:31 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 02:07:31 GMT Message-Id: <201111170207.pAH27Vha065438@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 02:07:32 -0000 TB --- 2011-11-17 00:14:43 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 00:14:43 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-17 00:14:43 - cleaning the object tree TB --- 2011-11-17 00:15:00 - cvsupping the source tree TB --- 2011-11-17 00:15:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-17 00:15:12 - building world TB --- 2011-11-17 00:15:12 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 00:15:12 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 00:15:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 00:15:12 - SRCCONF=/dev/null TB --- 2011-11-17 00:15:12 - TARGET=powerpc TB --- 2011-11-17 00:15:12 - TARGET_ARCH=powerpc64 TB --- 2011-11-17 00:15:12 - TZ=UTC TB --- 2011-11-17 00:15:12 - __MAKE_CONF=/dev/null TB --- 2011-11-17 00:15:12 - cd /src TB --- 2011-11-17 00:15:12 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 00:15:13 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Nov 17 01:54:40 UTC 2011 TB --- 2011-11-17 01:54:40 - generating LINT kernel config TB --- 2011-11-17 01:54:40 - cd /src/sys/powerpc/conf TB --- 2011-11-17 01:54:40 - /usr/bin/make -B LINT TB --- 2011-11-17 01:54:40 - cd /src/sys/powerpc/conf TB --- 2011-11-17 01:54:40 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 01:54:40 - skipping GENERIC kernel TB --- 2011-11-17 01:54:40 - cd /src/sys/powerpc/conf TB --- 2011-11-17 01:54:40 - /usr/sbin/config -m GENERIC64 TB --- 2011-11-17 01:54:40 - building GENERIC64 kernel TB --- 2011-11-17 01:54:40 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 01:54:40 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 01:54:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 01:54:40 - SRCCONF=/dev/null TB --- 2011-11-17 01:54:40 - TARGET=powerpc TB --- 2011-11-17 01:54:40 - TARGET_ARCH=powerpc64 TB --- 2011-11-17 01:54:40 - TZ=UTC TB --- 2011-11-17 01:54:40 - __MAKE_CONF=/dev/null TB --- 2011-11-17 01:54:40 - cd /src TB --- 2011-11-17 01:54:40 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Thu Nov 17 01:54:40 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 02:07:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 02:07:31 - ERROR: failed to build GENERIC64 kernel TB --- 2011-11-17 02:07:31 - 5195.05 user 1149.83 system 6768.17 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 03:56:16 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E94A1065670; Thu, 17 Nov 2011 03:56:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5ECA08FC13; Thu, 17 Nov 2011 03:56:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAH3uFFl033507; Wed, 16 Nov 2011 22:56:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAH3uFug033494; Thu, 17 Nov 2011 03:56:15 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 03:56:15 GMT Message-Id: <201111170356.pAH3uFug033494@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 03:56:16 -0000 TB --- 2011-11-17 02:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 02:10:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-17 02:10:00 - cleaning the object tree TB --- 2011-11-17 02:10:21 - cvsupping the source tree TB --- 2011-11-17 02:10:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-17 02:10:36 - building world TB --- 2011-11-17 02:10:36 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 02:10:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 02:10:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 02:10:36 - SRCCONF=/dev/null TB --- 2011-11-17 02:10:36 - TARGET=arm TB --- 2011-11-17 02:10:36 - TARGET_ARCH=arm TB --- 2011-11-17 02:10:36 - TZ=UTC TB --- 2011-11-17 02:10:36 - __MAKE_CONF=/dev/null TB --- 2011-11-17 02:10:36 - cd /src TB --- 2011-11-17 02:10:36 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 02:10:37 UTC 2011 >>> 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 Thu Nov 17 03:07:09 UTC 2011 TB --- 2011-11-17 03:07:09 - cd /src/sys/arm/conf TB --- 2011-11-17 03:07:09 - /usr/sbin/config -m AVILA TB --- 2011-11-17 03:07:09 - building AVILA kernel TB --- 2011-11-17 03:07:09 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:07:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:07:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:07:09 - SRCCONF=/dev/null TB --- 2011-11-17 03:07:09 - TARGET=arm TB --- 2011-11-17 03:07:09 - TARGET_ARCH=arm TB --- 2011-11-17 03:07:09 - TZ=UTC TB --- 2011-11-17 03:07:09 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:07:09 - cd /src TB --- 2011-11-17 03:07:09 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Thu Nov 17 03:07:09 UTC 2011 >>> 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 >>> Kernel build for AVILA completed on Thu Nov 17 03:10:09 UTC 2011 TB --- 2011-11-17 03:10:09 - cd /src/sys/arm/conf TB --- 2011-11-17 03:10:09 - /usr/sbin/config -m BWCT TB --- 2011-11-17 03:10:09 - building BWCT kernel TB --- 2011-11-17 03:10:09 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:10:09 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:10:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:10:09 - SRCCONF=/dev/null TB --- 2011-11-17 03:10:09 - TARGET=arm TB --- 2011-11-17 03:10:09 - TARGET_ARCH=arm TB --- 2011-11-17 03:10:09 - TZ=UTC TB --- 2011-11-17 03:10:09 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:10:09 - cd /src TB --- 2011-11-17 03:10:09 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Thu Nov 17 03:10:09 UTC 2011 >>> 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 >>> Kernel build for BWCT completed on Thu Nov 17 03:12:16 UTC 2011 TB --- 2011-11-17 03:12:16 - cd /src/sys/arm/conf TB --- 2011-11-17 03:12:16 - /usr/sbin/config -m CAMBRIA TB --- 2011-11-17 03:12:16 - building CAMBRIA kernel TB --- 2011-11-17 03:12:16 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:12:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:12:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:12:16 - SRCCONF=/dev/null TB --- 2011-11-17 03:12:16 - TARGET=arm TB --- 2011-11-17 03:12:16 - TARGET_ARCH=arm TB --- 2011-11-17 03:12:16 - TZ=UTC TB --- 2011-11-17 03:12:16 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:12:16 - cd /src TB --- 2011-11-17 03:12:16 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Thu Nov 17 03:12:16 UTC 2011 >>> 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 >>> Kernel build for CAMBRIA completed on Thu Nov 17 03:15:42 UTC 2011 TB --- 2011-11-17 03:15:42 - cd /src/sys/arm/conf TB --- 2011-11-17 03:15:42 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-11-17 03:15:43 - building CNS11XXNAS kernel TB --- 2011-11-17 03:15:43 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:15:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:15:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:15:43 - SRCCONF=/dev/null TB --- 2011-11-17 03:15:43 - TARGET=arm TB --- 2011-11-17 03:15:43 - TARGET_ARCH=arm TB --- 2011-11-17 03:15:43 - TZ=UTC TB --- 2011-11-17 03:15:43 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:15:43 - cd /src TB --- 2011-11-17 03:15:43 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Thu Nov 17 03:15:43 UTC 2011 >>> 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 >>> Kernel build for CNS11XXNAS completed on Thu Nov 17 03:18:13 UTC 2011 TB --- 2011-11-17 03:18:13 - cd /src/sys/arm/conf TB --- 2011-11-17 03:18:13 - /usr/sbin/config -m CRB TB --- 2011-11-17 03:18:13 - building CRB kernel TB --- 2011-11-17 03:18:13 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:18:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:18:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:18:13 - SRCCONF=/dev/null TB --- 2011-11-17 03:18:13 - TARGET=arm TB --- 2011-11-17 03:18:13 - TARGET_ARCH=arm TB --- 2011-11-17 03:18:13 - TZ=UTC TB --- 2011-11-17 03:18:13 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:18:13 - cd /src TB --- 2011-11-17 03:18:13 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Thu Nov 17 03:18:13 UTC 2011 >>> 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 >>> Kernel build for CRB completed on Thu Nov 17 03:22:04 UTC 2011 TB --- 2011-11-17 03:22:04 - cd /src/sys/arm/conf TB --- 2011-11-17 03:22:04 - /usr/sbin/config -m DB-78XXX TB --- 2011-11-17 03:22:04 - building DB-78XXX kernel TB --- 2011-11-17 03:22:04 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:22:04 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:22:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:22:04 - SRCCONF=/dev/null TB --- 2011-11-17 03:22:04 - TARGET=arm TB --- 2011-11-17 03:22:04 - TARGET_ARCH=arm TB --- 2011-11-17 03:22:04 - TZ=UTC TB --- 2011-11-17 03:22:04 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:22:04 - cd /src TB --- 2011-11-17 03:22:04 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Thu Nov 17 03:22:04 UTC 2011 >>> 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 >>> Kernel build for DB-78XXX completed on Thu Nov 17 03:24:43 UTC 2011 TB --- 2011-11-17 03:24:43 - cd /src/sys/arm/conf TB --- 2011-11-17 03:24:43 - /usr/sbin/config -m DB-88F5XXX TB --- 2011-11-17 03:24:43 - building DB-88F5XXX kernel TB --- 2011-11-17 03:24:43 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:24:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:24:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:24:43 - SRCCONF=/dev/null TB --- 2011-11-17 03:24:43 - TARGET=arm TB --- 2011-11-17 03:24:43 - TARGET_ARCH=arm TB --- 2011-11-17 03:24:43 - TZ=UTC TB --- 2011-11-17 03:24:43 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:24:43 - cd /src TB --- 2011-11-17 03:24:43 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Thu Nov 17 03:24:43 UTC 2011 >>> 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 >>> Kernel build for DB-88F5XXX completed on Thu Nov 17 03:27:22 UTC 2011 TB --- 2011-11-17 03:27:22 - cd /src/sys/arm/conf TB --- 2011-11-17 03:27:22 - /usr/sbin/config -m DB-88F6XXX TB --- 2011-11-17 03:27:23 - building DB-88F6XXX kernel TB --- 2011-11-17 03:27:23 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:27:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:27:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:27:23 - SRCCONF=/dev/null TB --- 2011-11-17 03:27:23 - TARGET=arm TB --- 2011-11-17 03:27:23 - TARGET_ARCH=arm TB --- 2011-11-17 03:27:23 - TZ=UTC TB --- 2011-11-17 03:27:23 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:27:23 - cd /src TB --- 2011-11-17 03:27:23 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Thu Nov 17 03:27:24 UTC 2011 >>> 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 >>> Kernel build for DB-88F6XXX completed on Thu Nov 17 03:30:01 UTC 2011 TB --- 2011-11-17 03:30:01 - cd /src/sys/arm/conf TB --- 2011-11-17 03:30:01 - /usr/sbin/config -m DOCKSTAR TB --- 2011-11-17 03:30:01 - building DOCKSTAR kernel TB --- 2011-11-17 03:30:01 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:30:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:30:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:30:01 - SRCCONF=/dev/null TB --- 2011-11-17 03:30:01 - TARGET=arm TB --- 2011-11-17 03:30:01 - TARGET_ARCH=arm TB --- 2011-11-17 03:30:01 - TZ=UTC TB --- 2011-11-17 03:30:01 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:30:01 - cd /src TB --- 2011-11-17 03:30:01 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Thu Nov 17 03:30:01 UTC 2011 >>> 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 >>> Kernel build for DOCKSTAR completed on Thu Nov 17 03:33:05 UTC 2011 TB --- 2011-11-17 03:33:05 - cd /src/sys/arm/conf TB --- 2011-11-17 03:33:05 - /usr/sbin/config -m EP80219 TB --- 2011-11-17 03:33:05 - building EP80219 kernel TB --- 2011-11-17 03:33:05 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:33:05 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:33:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:33:05 - SRCCONF=/dev/null TB --- 2011-11-17 03:33:05 - TARGET=arm TB --- 2011-11-17 03:33:05 - TARGET_ARCH=arm TB --- 2011-11-17 03:33:05 - TZ=UTC TB --- 2011-11-17 03:33:05 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:33:05 - cd /src TB --- 2011-11-17 03:33:05 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Thu Nov 17 03:33:05 UTC 2011 >>> 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 >>> Kernel build for EP80219 completed on Thu Nov 17 03:35:55 UTC 2011 TB --- 2011-11-17 03:35:55 - WARNING: no kernel config for GENERIC TB --- 2011-11-17 03:35:55 - cd /src/sys/arm/conf TB --- 2011-11-17 03:35:55 - /usr/sbin/config -m GUMSTIX TB --- 2011-11-17 03:35:55 - building GUMSTIX kernel TB --- 2011-11-17 03:35:55 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:35:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:35:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:35:55 - SRCCONF=/dev/null TB --- 2011-11-17 03:35:55 - TARGET=arm TB --- 2011-11-17 03:35:55 - TARGET_ARCH=arm TB --- 2011-11-17 03:35:55 - TZ=UTC TB --- 2011-11-17 03:35:55 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:35:55 - cd /src TB --- 2011-11-17 03:35:55 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Thu Nov 17 03:35:55 UTC 2011 >>> 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 >>> Kernel build for GUMSTIX completed on Thu Nov 17 03:38:14 UTC 2011 TB --- 2011-11-17 03:38:14 - cd /src/sys/arm/conf TB --- 2011-11-17 03:38:14 - /usr/sbin/config -m HL200 TB --- 2011-11-17 03:38:15 - building HL200 kernel TB --- 2011-11-17 03:38:15 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:38:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:38:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:38:15 - SRCCONF=/dev/null TB --- 2011-11-17 03:38:15 - TARGET=arm TB --- 2011-11-17 03:38:15 - TARGET_ARCH=arm TB --- 2011-11-17 03:38:15 - TZ=UTC TB --- 2011-11-17 03:38:15 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:38:15 - cd /src TB --- 2011-11-17 03:38:15 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Thu Nov 17 03:38:15 UTC 2011 >>> 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 >>> Kernel build for HL200 completed on Thu Nov 17 03:41:21 UTC 2011 TB --- 2011-11-17 03:41:21 - cd /src/sys/arm/conf TB --- 2011-11-17 03:41:21 - /usr/sbin/config -m HL201 TB --- 2011-11-17 03:41:23 - building HL201 kernel TB --- 2011-11-17 03:41:23 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:41:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:41:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:41:23 - SRCCONF=/dev/null TB --- 2011-11-17 03:41:23 - TARGET=arm TB --- 2011-11-17 03:41:23 - TARGET_ARCH=arm TB --- 2011-11-17 03:41:23 - TZ=UTC TB --- 2011-11-17 03:41:23 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:41:23 - cd /src TB --- 2011-11-17 03:41:23 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Thu Nov 17 03:41:23 UTC 2011 >>> 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 >>> Kernel build for HL201 completed on Thu Nov 17 03:43:43 UTC 2011 TB --- 2011-11-17 03:43:43 - cd /src/sys/arm/conf TB --- 2011-11-17 03:43:43 - /usr/sbin/config -m IQ31244 TB --- 2011-11-17 03:43:44 - building IQ31244 kernel TB --- 2011-11-17 03:43:44 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:43:44 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:43:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:43:44 - SRCCONF=/dev/null TB --- 2011-11-17 03:43:44 - TARGET=arm TB --- 2011-11-17 03:43:44 - TARGET_ARCH=arm TB --- 2011-11-17 03:43:44 - TZ=UTC TB --- 2011-11-17 03:43:44 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:43:44 - cd /src TB --- 2011-11-17 03:43:44 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Thu Nov 17 03:43:44 UTC 2011 >>> 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 >>> Kernel build for IQ31244 completed on Thu Nov 17 03:46:56 UTC 2011 TB --- 2011-11-17 03:46:56 - cd /src/sys/arm/conf TB --- 2011-11-17 03:46:56 - /usr/sbin/config -m KB920X TB --- 2011-11-17 03:46:56 - building KB920X kernel TB --- 2011-11-17 03:46:56 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:46:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:46:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:46:56 - SRCCONF=/dev/null TB --- 2011-11-17 03:46:56 - TARGET=arm TB --- 2011-11-17 03:46:56 - TARGET_ARCH=arm TB --- 2011-11-17 03:46:56 - TZ=UTC TB --- 2011-11-17 03:46:56 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:46:56 - cd /src TB --- 2011-11-17 03:46:56 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Thu Nov 17 03:46:56 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 03:56:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 03:56:14 - ERROR: failed to build KB920X kernel TB --- 2011-11-17 03:56:14 - 4757.00 user 1169.62 system 6374.47 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 04:37:05 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35EAC1065670; Thu, 17 Nov 2011 04:37:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 019588FC0C; Thu, 17 Nov 2011 04:37:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAH4b44U032525; Wed, 16 Nov 2011 23:37:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAH4b4lc032490; Thu, 17 Nov 2011 04:37:04 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 04:37:04 GMT Message-Id: <201111170437.pAH4b4lc032490@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 04:37:05 -0000 TB --- 2011-11-17 02:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 02:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-17 02:10:00 - cleaning the object tree TB --- 2011-11-17 02:10:19 - cvsupping the source tree TB --- 2011-11-17 02:10:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-17 02:10:36 - building world TB --- 2011-11-17 02:10:36 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 02:10:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 02:10:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 02:10:36 - SRCCONF=/dev/null TB --- 2011-11-17 02:10:36 - TARGET=pc98 TB --- 2011-11-17 02:10:36 - TARGET_ARCH=i386 TB --- 2011-11-17 02:10:36 - TZ=UTC TB --- 2011-11-17 02:10:36 - __MAKE_CONF=/dev/null TB --- 2011-11-17 02:10:36 - cd /src TB --- 2011-11-17 02:10:36 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 02:10:37 UTC 2011 >>> 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 Thu Nov 17 04:21:31 UTC 2011 TB --- 2011-11-17 04:21:31 - generating LINT kernel config TB --- 2011-11-17 04:21:31 - cd /src/sys/pc98/conf TB --- 2011-11-17 04:21:31 - /usr/bin/make -B LINT TB --- 2011-11-17 04:21:31 - cd /src/sys/pc98/conf TB --- 2011-11-17 04:21:31 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 04:21:31 - building GENERIC kernel TB --- 2011-11-17 04:21:31 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 04:21:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 04:21:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 04:21:31 - SRCCONF=/dev/null TB --- 2011-11-17 04:21:31 - TARGET=pc98 TB --- 2011-11-17 04:21:31 - TARGET_ARCH=i386 TB --- 2011-11-17 04:21:31 - TZ=UTC TB --- 2011-11-17 04:21:31 - __MAKE_CONF=/dev/null TB --- 2011-11-17 04:21:31 - cd /src TB --- 2011-11-17 04:21:31 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 04:21:31 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 04:37:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 04:37:03 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 04:37:03 - 7058.98 user 1257.04 system 8823.07 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 04:48:04 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C11DD1065675; Thu, 17 Nov 2011 04:48:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 961698FC0C; Thu, 17 Nov 2011 04:48:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAH4m2fn013088; Wed, 16 Nov 2011 23:48:02 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAH4m21E013075; Thu, 17 Nov 2011 04:48:02 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 04:48:02 GMT Message-Id: <201111170448.pAH4m21E013075@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 04:48:04 -0000 TB --- 2011-11-17 02:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 02:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-17 02:10:00 - cleaning the object tree TB --- 2011-11-17 02:10:20 - cvsupping the source tree TB --- 2011-11-17 02:10:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-17 02:10:36 - building world TB --- 2011-11-17 02:10:36 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 02:10:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 02:10:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 02:10:36 - SRCCONF=/dev/null TB --- 2011-11-17 02:10:36 - TARGET=i386 TB --- 2011-11-17 02:10:36 - TARGET_ARCH=i386 TB --- 2011-11-17 02:10:36 - TZ=UTC TB --- 2011-11-17 02:10:36 - __MAKE_CONF=/dev/null TB --- 2011-11-17 02:10:36 - cd /src TB --- 2011-11-17 02:10:36 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 02:10:37 UTC 2011 >>> 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 Thu Nov 17 04:21:57 UTC 2011 TB --- 2011-11-17 04:21:57 - generating LINT kernel config TB --- 2011-11-17 04:21:57 - cd /src/sys/i386/conf TB --- 2011-11-17 04:21:57 - /usr/bin/make -B LINT TB --- 2011-11-17 04:21:57 - cd /src/sys/i386/conf TB --- 2011-11-17 04:21:57 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-17 04:21:57 - building LINT-NOINET kernel TB --- 2011-11-17 04:21:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 04:21:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 04:21:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 04:21:57 - SRCCONF=/dev/null TB --- 2011-11-17 04:21:57 - TARGET=i386 TB --- 2011-11-17 04:21:57 - TARGET_ARCH=i386 TB --- 2011-11-17 04:21:57 - TZ=UTC TB --- 2011-11-17 04:21:57 - __MAKE_CONF=/dev/null TB --- 2011-11-17 04:21:57 - cd /src TB --- 2011-11-17 04:21:57 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Nov 17 04:21:57 UTC 2011 >>> 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 [...] ld -Bshareable -d -warn-common -o if_sf.ko if_sf.kld objcopy --strip-debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT-NOINET/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/i386.i386/src/sys/LINT-NOINET -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT-NOINET/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/i386.i386/src/sys/LINT-NOINET -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 04:48:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 04:48:02 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-17 04:48:02 - 7625.78 user 1294.17 system 9482.07 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 05:44:08 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D196A1065670; Thu, 17 Nov 2011 05:44:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A614A8FC0A; Thu, 17 Nov 2011 05:44:08 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAH5i7oK096653; Thu, 17 Nov 2011 00:44:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAH5i74h096626; Thu, 17 Nov 2011 05:44:07 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 05:44:07 GMT Message-Id: <201111170544.pAH5i74h096626@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 05:44:08 -0000 TB --- 2011-11-17 03:56:15 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 03:56:15 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-17 03:56:15 - cleaning the object tree TB --- 2011-11-17 03:56:29 - cvsupping the source tree TB --- 2011-11-17 03:56:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-17 03:56:41 - building world TB --- 2011-11-17 03:56:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 03:56:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 03:56:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 03:56:41 - SRCCONF=/dev/null TB --- 2011-11-17 03:56:41 - TARGET=ia64 TB --- 2011-11-17 03:56:41 - TARGET_ARCH=ia64 TB --- 2011-11-17 03:56:41 - TZ=UTC TB --- 2011-11-17 03:56:41 - __MAKE_CONF=/dev/null TB --- 2011-11-17 03:56:41 - cd /src TB --- 2011-11-17 03:56:41 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 03:56:41 UTC 2011 >>> 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 Thu Nov 17 05:24:47 UTC 2011 TB --- 2011-11-17 05:24:48 - generating LINT kernel config TB --- 2011-11-17 05:24:48 - cd /src/sys/ia64/conf TB --- 2011-11-17 05:24:48 - /usr/bin/make -B LINT TB --- 2011-11-17 05:24:48 - cd /src/sys/ia64/conf TB --- 2011-11-17 05:24:48 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 05:24:48 - building GENERIC kernel TB --- 2011-11-17 05:24:48 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 05:24:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 05:24:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 05:24:48 - SRCCONF=/dev/null TB --- 2011-11-17 05:24:48 - TARGET=ia64 TB --- 2011-11-17 05:24:48 - TARGET_ARCH=ia64 TB --- 2011-11-17 05:24:48 - TZ=UTC TB --- 2011-11-17 05:24:48 - __MAKE_CONF=/dev/null TB --- 2011-11-17 05:24:48 - cd /src TB --- 2011-11-17 05:24:48 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 05:24:48 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 05:44:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 05:44:07 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 05:44:07 - 5123.00 user 961.82 system 6471.24 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 06:46:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1892106564A; Thu, 17 Nov 2011 06:46:41 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6962A8FC12; Thu, 17 Nov 2011 06:46:35 +0000 (UTC) Received: by iakl21 with SMTP id l21so2447280iak.13 for ; Wed, 16 Nov 2011 22:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k+M9Osvwlg6dTn3Exvf1g0+ocege0lVkUDWNtpVVqdQ=; b=lol/jPao/F6MahaL2Viu6PtX0TkpS6fvdy7Ij2hME9hXDhdObZ9chlC/eKTnsqLtru /Dyp2zsDza8NYl5LZmVKfNnqCKygapnH2uIEAQ9RKIXFtY5TjtthPOCEdBNzkSX6TYOT keL4HeXaeZ69eATfAG6OpHsIEilC00R1c316w= MIME-Version: 1.0 Received: by 10.42.150.135 with SMTP id a7mr38899287icw.53.1321512393803; Wed, 16 Nov 2011 22:46:33 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.243.198 with HTTP; Wed, 16 Nov 2011 22:46:33 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Nov 2011 07:46:33 +0100 X-Google-Sender-Auth: AiIl9JZNGtYPSiLuDzTOwqEBN1Q Message-ID: From: Robert Millan To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 06:46:41 -0000 2011/11/16 Warner Losh : > My second reaction was why not have > > #ifndef __FreeBSD_kernel__ > #define __FreeBSD_kernel__ __FreeBSD__ > #endif > > in sys/param.h and then just change __FreeBSD__ to __FreeBSD_kernel__ in = the headers that are affected? =C2=A0But I'm not quite sure what effects th= at would have on your environment. I'm fine with this. > Why do you think people wouldn't be fond of the __FreeBSD_kernel__ being = defined? See archived discussion: http://lists.freebsd.org/pipermail/freebsd-hackers/2011-July/035721.html particularly this mail in which you participated: http://lists.freebsd.org/pipermail/freebsd-hackers/2011-July/035823.html From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 07:03:21 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCA75106566C; Thu, 17 Nov 2011 07:03:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 78B558FC12; Thu, 17 Nov 2011 07:03:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAH73KQB055818; Thu, 17 Nov 2011 02:03:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAH73KKE055791; Thu, 17 Nov 2011 07:03:20 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 07:03:20 GMT Message-Id: <201111170703.pAH73KKE055791@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 07:03:21 -0000 TB --- 2011-11-17 04:48:03 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 04:48:03 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-17 04:48:03 - cleaning the object tree TB --- 2011-11-17 04:48:15 - cvsupping the source tree TB --- 2011-11-17 04:48:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-17 04:48:28 - building world TB --- 2011-11-17 04:48:28 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 04:48:28 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 04:48:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 04:48:28 - SRCCONF=/dev/null TB --- 2011-11-17 04:48:28 - TARGET=powerpc TB --- 2011-11-17 04:48:28 - TARGET_ARCH=powerpc TB --- 2011-11-17 04:48:28 - TZ=UTC TB --- 2011-11-17 04:48:28 - __MAKE_CONF=/dev/null TB --- 2011-11-17 04:48:28 - cd /src TB --- 2011-11-17 04:48:28 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 04:48:28 UTC 2011 >>> 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 Thu Nov 17 06:49:35 UTC 2011 TB --- 2011-11-17 06:49:35 - generating LINT kernel config TB --- 2011-11-17 06:49:35 - cd /src/sys/powerpc/conf TB --- 2011-11-17 06:49:35 - /usr/bin/make -B LINT TB --- 2011-11-17 06:49:35 - cd /src/sys/powerpc/conf TB --- 2011-11-17 06:49:35 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 06:49:35 - building GENERIC kernel TB --- 2011-11-17 06:49:35 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 06:49:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 06:49:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 06:49:35 - SRCCONF=/dev/null TB --- 2011-11-17 06:49:35 - TARGET=powerpc TB --- 2011-11-17 06:49:35 - TARGET_ARCH=powerpc TB --- 2011-11-17 06:49:35 - TZ=UTC TB --- 2011-11-17 06:49:35 - __MAKE_CONF=/dev/null TB --- 2011-11-17 06:49:35 - cd /src TB --- 2011-11-17 06:49:35 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 06:49:35 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 07:03:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 07:03:20 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 07:03:20 - 6508.77 user 1117.43 system 8116.96 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 07:06:17 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B891C1065673; Thu, 17 Nov 2011 07:06:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8BDA88FC13; Thu, 17 Nov 2011 07:06:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAH76GXK073381; Thu, 17 Nov 2011 02:06:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAH76GO3073376; Thu, 17 Nov 2011 07:06:16 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 07:06:16 GMT Message-Id: <201111170706.pAH76GO3073376@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 07:06:17 -0000 TB --- 2011-11-17 05:44:08 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 05:44:08 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-11-17 05:44:08 - cleaning the object tree TB --- 2011-11-17 05:44:19 - cvsupping the source tree TB --- 2011-11-17 05:44:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-11-17 05:44:33 - building world TB --- 2011-11-17 05:44:33 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 05:44:33 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 05:44:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 05:44:33 - SRCCONF=/dev/null TB --- 2011-11-17 05:44:33 - TARGET=sparc64 TB --- 2011-11-17 05:44:33 - TARGET_ARCH=sparc64 TB --- 2011-11-17 05:44:33 - TZ=UTC TB --- 2011-11-17 05:44:33 - __MAKE_CONF=/dev/null TB --- 2011-11-17 05:44:33 - cd /src TB --- 2011-11-17 05:44:33 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 05:44:34 UTC 2011 >>> 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 Thu Nov 17 06:50:43 UTC 2011 TB --- 2011-11-17 06:50:43 - generating LINT kernel config TB --- 2011-11-17 06:50:43 - cd /src/sys/sparc64/conf TB --- 2011-11-17 06:50:43 - /usr/bin/make -B LINT TB --- 2011-11-17 06:50:43 - cd /src/sys/sparc64/conf TB --- 2011-11-17 06:50:43 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 06:50:43 - building GENERIC kernel TB --- 2011-11-17 06:50:43 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 06:50:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 06:50:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 06:50:43 - SRCCONF=/dev/null TB --- 2011-11-17 06:50:43 - TARGET=sparc64 TB --- 2011-11-17 06:50:43 - TARGET_ARCH=sparc64 TB --- 2011-11-17 06:50:43 - TZ=UTC TB --- 2011-11-17 06:50:43 - __MAKE_CONF=/dev/null TB --- 2011-11-17 06:50:43 - cd /src TB --- 2011-11-17 06:50:43 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 06:50:43 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 07:06:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 07:06:16 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 07:06:16 - 3700.75 user 822.88 system 4928.24 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 07:29:07 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2C4D106566B; Thu, 17 Nov 2011 07:29:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BDD9A8FC13; Thu, 17 Nov 2011 07:29:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAH7T533033185; Thu, 17 Nov 2011 02:29:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAH7T5fh033184; Thu, 17 Nov 2011 07:29:05 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 07:29:05 GMT Message-Id: <201111170729.pAH7T5fh033184@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 07:29:07 -0000 TB --- 2011-11-17 05:36:49 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 05:36:49 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-17 05:36:49 - cleaning the object tree TB --- 2011-11-17 05:37:15 - cvsupping the source tree TB --- 2011-11-17 05:37:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-17 05:38:07 - building world TB --- 2011-11-17 05:38:07 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 05:38:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 05:38:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 05:38:07 - SRCCONF=/dev/null TB --- 2011-11-17 05:38:07 - TARGET=powerpc TB --- 2011-11-17 05:38:07 - TARGET_ARCH=powerpc64 TB --- 2011-11-17 05:38:07 - TZ=UTC TB --- 2011-11-17 05:38:07 - __MAKE_CONF=/dev/null TB --- 2011-11-17 05:38:07 - cd /src TB --- 2011-11-17 05:38:07 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 05:38:08 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Nov 17 07:16:01 UTC 2011 TB --- 2011-11-17 07:16:02 - generating LINT kernel config TB --- 2011-11-17 07:16:02 - cd /src/sys/powerpc/conf TB --- 2011-11-17 07:16:02 - /usr/bin/make -B LINT TB --- 2011-11-17 07:16:02 - cd /src/sys/powerpc/conf TB --- 2011-11-17 07:16:02 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 07:16:02 - skipping GENERIC kernel TB --- 2011-11-17 07:16:02 - cd /src/sys/powerpc/conf TB --- 2011-11-17 07:16:02 - /usr/sbin/config -m GENERIC64 TB --- 2011-11-17 07:16:02 - building GENERIC64 kernel TB --- 2011-11-17 07:16:02 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 07:16:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 07:16:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 07:16:02 - SRCCONF=/dev/null TB --- 2011-11-17 07:16:02 - TARGET=powerpc TB --- 2011-11-17 07:16:02 - TARGET_ARCH=powerpc64 TB --- 2011-11-17 07:16:02 - TZ=UTC TB --- 2011-11-17 07:16:02 - __MAKE_CONF=/dev/null TB --- 2011-11-17 07:16:02 - cd /src TB --- 2011-11-17 07:16:02 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Thu Nov 17 07:16:02 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 07:29:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 07:29:05 - ERROR: failed to build GENERIC64 kernel TB --- 2011-11-17 07:29:05 - 5170.92 user 1139.76 system 6735.75 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 08:15:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6108E106564A; Thu, 17 Nov 2011 08:15:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D41588FC0A; Thu, 17 Nov 2011 08:15:40 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAH8FX5T012366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2011 10:15:34 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAH8FXBd012030; Thu, 17 Nov 2011 10:15:33 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAH8FXQb012029; Thu, 17 Nov 2011 10:15:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 17 Nov 2011 10:15:33 +0200 From: Kostik Belousov To: Alexander Motin Message-ID: <20111117081533.GP50300@deviant.kiev.zoral.com.ua> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <20111116202714.5ee4bd53@fabiankeil.de> <4EC43764.1020202@FreeBSD.org> <4EC4423A.3020904@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rJakZGbrL8S1ZGl5" Content-Disposition: inline In-Reply-To: <4EC4423A.3020904@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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-current@freebsd.org, Andriy Gapon Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 08:15:41 -0000 --rJakZGbrL8S1ZGl5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote: > On 17.11.2011 00:21, Andriy Gapon wrote: > >on 16/11/2011 21:27 Fabian Keil said the following: > >>Kostik Belousov wrote: > >> > >>>I was tricked into finishing the work by Andrey Gapon, who developed > >>>the patch to reliably stop other processors on panic. The patch > >>>greatly improves the chances of getting dump on panic on SMP host. > >> > >>I tested the patch trying to get a dump (from the debugger) for > >>kern/162036, which currently results in the double fault reported in: > >>http://lists.freebsd.org/pipermail/freebsd-current/2011-September/02776= 6.html > >> > >>It didn't help, but also didn't make anything worse. > >> > >>Fabian > > > >The mi_switch recursion looks very familiar to me: > >mi_switch() at mi_switch+0x270 > >critical_exit() at critical_exit+0x9b > >spinlock_exit() at spinlock_exit+0x17 > >mi_switch() at mi_switch+0x275 > >critical_exit() at critical_exit+0x9b > >spinlock_exit() at spinlock_exit+0x17 > >[several pages of the previous three lines skipped] > >mi_switch() at mi_switch+0x275 > >critical_exit() at critical_exit+0x9b > >spinlock_exit() at spinlock_exit+0x17 > >intr_even_schedule_thread() at intr_event_schedule_thread+0xbb > >ahci_end_transaction() at ahci_end_transaction+0x398 > >ahci_ch_intr() at ahci_ch_intr+0x2b5 > >ahcipoll() at ahcipoll+0x15 > >xpt_polled_action() at xpt_polled_action+0xf7 > > > >In fact I once discussed with jhb this recursion triggered from a differ= ent > >place. To quote myself: > > spinlock_exit -> critical_exit -> mi_switch -> kdb_switch -> > >thread_unlock -> spinlock_exit -> critical_exit -> mi_switch -> ... > > in the kdb context > > this issue seems to be triggered by td_owepreempt being true at= =20 > >the time > >kdb is entered > > and there of course has to be an initial spinlock_exit call=20 > >somewhere > > in my case it's because of usb keyboard > > I wonder if it would make sense to clear td_owepreempt right=20 > >before > >calling kdb_switch in mi_switch > > instead of in sched_switch() > > clearing td_owepreempt seems like a scheduler-independent=20 > >operation to me > > or is it better to just skip locking in usb when kdb_active is = set > > ? > > > >The workaround described above should work in this case. > >Another possibility is to pessimize mtx_unlock_spin() implementations to= =20 > >check > >SCHEDULER_STOPPED() and to bypass any further actions in that case. But= =20 > >that > >would add unnecessary overhead to the sunny day code paths. > > > >Going further up the stack one can come up with the following proposals: > >- check SCHEDULER_STOPPED() swi_sched() and return early > >- do not call swi_sched() from xpt_done() if we somehow know that we are= =20 > >in a > >polling mode >=20 > There is no flag in CAM now to indicate polling mode, but if needed, it= =20 > should not be difficult to add one and not call swi_sched(). I have the following change for eons on my test boxes. Without it, I simply cannot get _any_ dump. diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c index 10b89c7..a38e42f 100644 --- a/sys/cam/cam_xpt.c +++ b/sys/cam/cam_xpt.c @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) TAILQ_INSERT_TAIL(&cam_simq, sim, links); mtx_unlock(&cam_simq_lock); sim->flags |=3D CAM_SIM_ON_DONEQ; - if (first) + if (first && panicstr =3D=3D NULL) swi_sched(cambio_ih, 0); } } --rJakZGbrL8S1ZGl5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7EwqQACgkQC3+MBN1Mb4iB3QCgvD8S2klE4Svfxy9maBIBZH2m lE4Ani/T7aqvzD2mUT+KSM51xfeir360 =/f4D -----END PGP SIGNATURE----- --rJakZGbrL8S1ZGl5-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 08:34:32 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF9C5106566B; Thu, 17 Nov 2011 08:34:32 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EA50C8FC14; Thu, 17 Nov 2011 08:34:31 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA09615; Thu, 17 Nov 2011 10:34:29 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RQxQS-000BfN-Jw; Thu, 17 Nov 2011 10:34:28 +0200 Message-ID: <4EC4C712.8040701@FreeBSD.org> Date: Thu, 17 Nov 2011 10:34:26 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Kostik Belousov References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <20111116202714.5ee4bd53@fabiankeil.de> <4EC43764.1020202@FreeBSD.org> <4EC4423A.3020904@FreeBSD.org> <20111117081533.GP50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111117081533.GP50300@deviant.kiev.zoral.com.ua> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@FreeBSD.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 08:34:32 -0000 on 17/11/2011 10:15 Kostik Belousov said the following: > On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote: >> On 17.11.2011 00:21, Andriy Gapon wrote: >>> Going further up the stack one can come up with the following proposals: >>> - check SCHEDULER_STOPPED() swi_sched() and return early >>> - do not call swi_sched() from xpt_done() if we somehow know that we are >>> in a >>> polling mode >> >> There is no flag in CAM now to indicate polling mode, but if needed, it >> should not be difficult to add one and not call swi_sched(). > > I have the following change for eons on my test boxes. Without it, > I simply cannot get _any_ dump. > > diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c > index 10b89c7..a38e42f 100644 > --- a/sys/cam/cam_xpt.c > +++ b/sys/cam/cam_xpt.c > @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) > TAILQ_INSERT_TAIL(&cam_simq, sim, links); > mtx_unlock(&cam_simq_lock); > sim->flags |= CAM_SIM_ON_DONEQ; > - if (first) > + if (first && panicstr == NULL) > swi_sched(cambio_ih, 0); > } > } I think that this (or similar) change should go into the patch and the tree. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 08:41:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C457D106564A; Thu, 17 Nov 2011 08:41:03 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 27EEA8FC16; Thu, 17 Nov 2011 08:41:02 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so2271366bkb.13 for ; Thu, 17 Nov 2011 00:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PPTq1XWz/3W4k/WOeHXZ7HvC7+rMNCWNX2wDqDEfEVs=; b=IiyX4jb+r3J63pFKHU0w9Vsv9OvbUW2+3BGX3vqygqbI8spRHL8UeFI7eh2MZgcbj5 z+HDKyx04W6lFunjddq/n2uXNhCSpbCBcgWvPi1+bBQwcGbBEVWxkAyWwwfC1VotfX8C 7OcIbmMXbEO0WQJ+MfvE4jfYwHmargeuYRcNE= Received: by 10.204.136.211 with SMTP id s19mr25748615bkt.28.1321519261272; Thu, 17 Nov 2011 00:41:01 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id y10sm1456420fal.10.2011.11.17.00.40.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 00:41:00 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC4C89A.2040208@FreeBSD.org> Date: Thu, 17 Nov 2011 10:40:58 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kostik Belousov References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <20111116202714.5ee4bd53@fabiankeil.de> <4EC43764.1020202@FreeBSD.org> <4EC4423A.3020904@FreeBSD.org> <20111117081533.GP50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111117081533.GP50300@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 08:41:03 -0000 On 11/17/11 10:15, Kostik Belousov wrote: > On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote: >> On 17.11.2011 00:21, Andriy Gapon wrote: >>> on 16/11/2011 21:27 Fabian Keil said the following: >>>> Kostik Belousov wrote: >>>> >>>>> I was tricked into finishing the work by Andrey Gapon, who developed >>>>> the patch to reliably stop other processors on panic. The patch >>>>> greatly improves the chances of getting dump on panic on SMP host. >>>> >>>> I tested the patch trying to get a dump (from the debugger) for >>>> kern/162036, which currently results in the double fault reported in: >>>> http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027766.html >>>> >>>> It didn't help, but also didn't make anything worse. >>>> >>>> Fabian >>> >>> The mi_switch recursion looks very familiar to me: >>> mi_switch() at mi_switch+0x270 >>> critical_exit() at critical_exit+0x9b >>> spinlock_exit() at spinlock_exit+0x17 >>> mi_switch() at mi_switch+0x275 >>> critical_exit() at critical_exit+0x9b >>> spinlock_exit() at spinlock_exit+0x17 >>> [several pages of the previous three lines skipped] >>> mi_switch() at mi_switch+0x275 >>> critical_exit() at critical_exit+0x9b >>> spinlock_exit() at spinlock_exit+0x17 >>> intr_even_schedule_thread() at intr_event_schedule_thread+0xbb >>> ahci_end_transaction() at ahci_end_transaction+0x398 >>> ahci_ch_intr() at ahci_ch_intr+0x2b5 >>> ahcipoll() at ahcipoll+0x15 >>> xpt_polled_action() at xpt_polled_action+0xf7 >>> >>> In fact I once discussed with jhb this recursion triggered from a different >>> place. To quote myself: >>> spinlock_exit -> critical_exit -> mi_switch -> kdb_switch -> >>> thread_unlock -> spinlock_exit -> critical_exit -> mi_switch -> ... >>> in the kdb context >>> this issue seems to be triggered by td_owepreempt being true at >>> the time >>> kdb is entered >>> and there of course has to be an initial spinlock_exit call >>> somewhere >>> in my case it's because of usb keyboard >>> I wonder if it would make sense to clear td_owepreempt right >>> before >>> calling kdb_switch in mi_switch >>> instead of in sched_switch() >>> clearing td_owepreempt seems like a scheduler-independent >>> operation to me >>> or is it better to just skip locking in usb when kdb_active is set >>> ? >>> >>> The workaround described above should work in this case. >>> Another possibility is to pessimize mtx_unlock_spin() implementations to >>> check >>> SCHEDULER_STOPPED() and to bypass any further actions in that case. But >>> that >>> would add unnecessary overhead to the sunny day code paths. >>> >>> Going further up the stack one can come up with the following proposals: >>> - check SCHEDULER_STOPPED() swi_sched() and return early >>> - do not call swi_sched() from xpt_done() if we somehow know that we are >>> in a >>> polling mode >> >> There is no flag in CAM now to indicate polling mode, but if needed, it >> should not be difficult to add one and not call swi_sched(). > > I have the following change for eons on my test boxes. Without it, > I simply cannot get _any_ dump. > > diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c > index 10b89c7..a38e42f 100644 > --- a/sys/cam/cam_xpt.c > +++ b/sys/cam/cam_xpt.c > @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) > TAILQ_INSERT_TAIL(&cam_simq, sim, links); > mtx_unlock(&cam_simq_lock); > sim->flags |= CAM_SIM_ON_DONEQ; > - if (first) > + if (first && panicstr == NULL) > swi_sched(cambio_ih, 0); > } > } That should be OK for kernel dumping. I was thinking about CAM abusing polling not only for dumping. But looking on cases where it does it now, may be it is better to rewrite them instead. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 08:59:44 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F1901065675 for ; Thu, 17 Nov 2011 08:59:44 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm21.bullet.mail.sp2.yahoo.com (nm21.bullet.mail.sp2.yahoo.com [98.139.91.91]) by mx1.freebsd.org (Postfix) with SMTP id 6EAE48FC16 for ; Thu, 17 Nov 2011 08:59:44 +0000 (UTC) Received: from [98.139.91.64] by nm21.bullet.mail.sp2.yahoo.com with NNFMP; 17 Nov 2011 08:59:44 -0000 Received: from [208.71.42.192] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 17 Nov 2011 08:59:44 -0000 Received: from [127.0.0.1] by smtp203.mail.gq1.yahoo.com with NNFMP; 17 Nov 2011 08:59:43 -0000 X-Yahoo-Newman-Id: 904142.39373.bm@smtp203.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: VRuUg40VM1kRKfDicZCyyJ3sqSbYjTBSH._8jJ_QbiaHh4j Zc_nSeAq7reATPHljkbWXbK3HEPKJl8rQ3m5EObKu.JRW732Ee2pTKP6Az4p VOzbhpF9ro_w63yoDys79Co1miy8dIyePT4ry769c.1T4mco3m4mRQxo5Wuv JhOA.eEvT6WMZyEuZIYstdU4T0oGvmdbrDyWmJyImgw24LcL4TyBg3sh3Ucv nWb0n9mMr4OwTPxLzsnmcm7UasMLJAUx0PIp4XqlOihqBQzqlSYMCK57pmRp lJeTPGAsugvGXv0W_M7IucASKbMuZWQqI.qQlLMXnOIOWpVqdzeFsUKvbMxU Dy36EpxVTb.wIW1m4KR7U4Buqix1OczglXeAevWwF4XaVau488e.1z9zmWci JagRMmn683kF1US8- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.142.172 with plain) by smtp203.mail.gq1.yahoo.com with SMTP; 17 Nov 2011 00:59:43 -0800 PST Message-ID: <4EC4CCFF.8040704@freebsd.org> Date: Thu, 17 Nov 2011 09:59:43 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: John Baldwin References: <4EBB885E.9060908@freebsd.org> <4EC004BC.6060406@freebsd.org> <201111161116.24855.jhb@freebsd.org> In-Reply-To: <201111161116.24855.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-current@freebsd.org Subject: Re: [amd64] Reproducible cold boot failure (reboot succeeds) in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 08:59:44 -0000 Am 16.11.2011 17:16, schrieb John Baldwin: > On Sunday, November 13, 2011 12:56:12 pm Stefan Esser wrote: >> ... >> WARNING: WITNESS option enabled, expect reduced performance. >> Table 'FACP' at 0xba918a58 >> Table 'APIC' at 0xba918b50 >> Table 'SSDT' at 0xba918be8 >> Table 'MCFG' at 0xba918dc0 >> Table 'HPET' at 0xba918e00 >> ACPI: No SRAT table found >> Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81109000 >> Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff81109370 <-- >> kldload: unexpected relocation type 67108875 >> kernel trap 12 with interrupts disabled >> >> The irritating detail is the load address of "zfs.ko", which is just >> 0x370 bytes above the kernel load address ... > > That isn't unusual. Those are the addresses of the metadata provided by the > loader, not the base address of the kernel or zfs.ko object themselves. The > unexpected relocation type is interesting however. That value in hex is > 0x400000b. 0xb is the R_X86_64_32S relocation type which is normal for the > kernel. I think you just have a single-bit memory error due to a failing > DIMM. Thanks for the information about the load address semantics. The other unexpected relocation type I observed was 268435457 == 0x10000001, which also hints at a single bit error. But today the system failed with a different error: ath0: ... ioapic0: routing interrupt 18 to ... panic: vm_page_insert: page already inserted This could of course also be caused by a single bit error ... But the strange thing is that the system runs perfectly stable under load (e.g. "make -j8 world") and that the ZFS ARC grows to some 6GB (of 8GB RAM installed) and I'd expect checksum errors to occur, if there is a bad DIMM. Anyway, I'll check with memtest86+ (or whatever best supports my system with 8GB RAM) over night. The system boots reliably when switched off for less than a few hours (I haven't determined the exact limit, but 3 hours are not sufficient to reproduce the boot failure, while 10 hours cause the first boot attempt to fail with 90% likelihood; the second one always succeeds). I'm wondering whether the system RAM is not correctly initialized after being powered off for 10 hours (but I do not understand why 3 hours should not lead to the exact same initial state). BTW: It suffices to have the system at power state S5 for 10 hours to cause the boot failure, while less than 3 hours (without any power or at S5) let the boot succeed on the first attempt. >> I had already assumed that memory was corrupted during early start-up, >> but now I think that gptzfsboot writes the zfs kernel module over the >> start of the loaded kernel. I'll try some more tests later today. > > Nah, if zfs.ko were loaded over the beginning of the kernel you wouldn't even > get to the point of the first kernel printf. Yes, I see that the failure would be less random (3 different kinds of panic and different warning messages before the panic occurs). But I still do not understand how the symptoms can be interpreted: 1) The system booted reliably for many months 2) It boots reliably when powered off for only a few hours 3) It fails on the first boot attempt after 10 hours or more 4) It never shows signs of instability after a successful boot Hmmm, perhaps there is a problem with components at room temperature and the system is still significantly warmer after 3 hours? I'll have to check for such a thermal effect too ... Best regards, STefan From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 09:07:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC7C5106566B; Thu, 17 Nov 2011 09:07:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 467CB8FC0A; Thu, 17 Nov 2011 09:07:00 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAH96sah017436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2011 11:06:54 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAH96rhj012197; Thu, 17 Nov 2011 11:06:53 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAH96r27012196; Thu, 17 Nov 2011 11:06:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 17 Nov 2011 11:06:53 +0200 From: Kostik Belousov To: Alexander Motin Message-ID: <20111117090653.GR50300@deviant.kiev.zoral.com.ua> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <20111116202714.5ee4bd53@fabiankeil.de> <4EC43764.1020202@FreeBSD.org> <4EC4423A.3020904@FreeBSD.org> <20111117081533.GP50300@deviant.kiev.zoral.com.ua> <4EC4C89A.2040208@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L9AyDL8231zxsA/w" Content-Disposition: inline In-Reply-To: <4EC4C89A.2040208@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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-current@freebsd.org, Andriy Gapon Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:07:01 -0000 --L9AyDL8231zxsA/w Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 17, 2011 at 10:40:58AM +0200, Alexander Motin wrote: > On 11/17/11 10:15, Kostik Belousov wrote: > > On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote: > >> On 17.11.2011 00:21, Andriy Gapon wrote: > >>> on 16/11/2011 21:27 Fabian Keil said the following: > >>>> Kostik Belousov wrote: > >>>> > >>>>> I was tricked into finishing the work by Andrey Gapon, who developed > >>>>> the patch to reliably stop other processors on panic. The patch > >>>>> greatly improves the chances of getting dump on panic on SMP host. > >>>> > >>>> I tested the patch trying to get a dump (from the debugger) for > >>>> kern/162036, which currently results in the double fault reported in: > >>>> http://lists.freebsd.org/pipermail/freebsd-current/2011-September/02= 7766.html > >>>> > >>>> It didn't help, but also didn't make anything worse. > >>>> > >>>> Fabian > >>> > >>> The mi_switch recursion looks very familiar to me: > >>> mi_switch() at mi_switch+0x270 > >>> critical_exit() at critical_exit+0x9b > >>> spinlock_exit() at spinlock_exit+0x17 > >>> mi_switch() at mi_switch+0x275 > >>> critical_exit() at critical_exit+0x9b > >>> spinlock_exit() at spinlock_exit+0x17 > >>> [several pages of the previous three lines skipped] > >>> mi_switch() at mi_switch+0x275 > >>> critical_exit() at critical_exit+0x9b > >>> spinlock_exit() at spinlock_exit+0x17 > >>> intr_even_schedule_thread() at intr_event_schedule_thread+0xbb > >>> ahci_end_transaction() at ahci_end_transaction+0x398 > >>> ahci_ch_intr() at ahci_ch_intr+0x2b5 > >>> ahcipoll() at ahcipoll+0x15 > >>> xpt_polled_action() at xpt_polled_action+0xf7 > >>> > >>> In fact I once discussed with jhb this recursion triggered from a dif= ferent > >>> place. To quote myself: > >>> spinlock_exit -> critical_exit -> mi_switch -> kdb_switch= -> > >>> thread_unlock -> spinlock_exit -> critical_exit -> mi_switch -> .= .. > >>> in the kdb context > >>> this issue seems to be triggered by td_owepreempt being true= at=20 > >>> the time > >>> kdb is entered > >>> and there of course has to be an initial spinlock_exit call= =20 > >>> somewhere > >>> in my case it's because of usb keyboard > >>> I wonder if it would make sense to clear td_owepreempt right= =20 > >>> before > >>> calling kdb_switch in mi_switch > >>> instead of in sched_switch() > >>> clearing td_owepreempt seems like a scheduler-independent=20 > >>> operation to me > >>> or is it better to just skip locking in usb when kdb_active = is set > >>> ? > >>> > >>> The workaround described above should work in this case. > >>> Another possibility is to pessimize mtx_unlock_spin() implementations= to=20 > >>> check > >>> SCHEDULER_STOPPED() and to bypass any further actions in that case. = But=20 > >>> that > >>> would add unnecessary overhead to the sunny day code paths. > >>> > >>> Going further up the stack one can come up with the following proposa= ls: > >>> - check SCHEDULER_STOPPED() swi_sched() and return early > >>> - do not call swi_sched() from xpt_done() if we somehow know that we = are=20 > >>> in a > >>> polling mode > >> > >> There is no flag in CAM now to indicate polling mode, but if needed, i= t=20 > >> should not be difficult to add one and not call swi_sched(). > >=20 > > I have the following change for eons on my test boxes. Without it, > > I simply cannot get _any_ dump. > >=20 > > diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c > > index 10b89c7..a38e42f 100644 > > --- a/sys/cam/cam_xpt.c > > +++ b/sys/cam/cam_xpt.c > > @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) > > TAILQ_INSERT_TAIL(&cam_simq, sim, links); > > mtx_unlock(&cam_simq_lock); > > sim->flags |=3D CAM_SIM_ON_DONEQ; > > - if (first) > > + if (first && panicstr =3D=3D NULL) > > swi_sched(cambio_ih, 0); > > } > > } >=20 > That should be OK for kernel dumping. I was thinking about CAM abusing > polling not only for dumping. But looking on cases where it does it now, > may be it is better to rewrite them instead. So, should I interpret your response as 'Reviewed by" ? --L9AyDL8231zxsA/w Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7Ezq0ACgkQC3+MBN1Mb4hbuQCgpbGVw/gU8OWAA/HefdszTLdk YYMAoItZnmQ4LsGQZhC5yOMhXgpJq5Xd =30t7 -----END PGP SIGNATURE----- --L9AyDL8231zxsA/w-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 09:14:51 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE9FB106564A; Thu, 17 Nov 2011 09:14:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB2E8FC1A; Thu, 17 Nov 2011 09:14:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAH9Eo9B001508; Thu, 17 Nov 2011 04:14:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAH9Eopd001507; Thu, 17 Nov 2011 09:14:50 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 09:14:50 GMT Message-Id: <201111170914.pAH9Eopd001507@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:14:52 -0000 TB --- 2011-11-17 07:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 07:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-17 07:30:00 - cleaning the object tree TB --- 2011-11-17 07:30:23 - cvsupping the source tree TB --- 2011-11-17 07:30:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-17 07:30:37 - building world TB --- 2011-11-17 07:30:37 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 07:30:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 07:30:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 07:30:37 - SRCCONF=/dev/null TB --- 2011-11-17 07:30:37 - TARGET=arm TB --- 2011-11-17 07:30:37 - TARGET_ARCH=arm TB --- 2011-11-17 07:30:37 - TZ=UTC TB --- 2011-11-17 07:30:37 - __MAKE_CONF=/dev/null TB --- 2011-11-17 07:30:37 - cd /src TB --- 2011-11-17 07:30:37 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 07:30:38 UTC 2011 >>> 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 Thu Nov 17 08:26:17 UTC 2011 TB --- 2011-11-17 08:26:17 - cd /src/sys/arm/conf TB --- 2011-11-17 08:26:17 - /usr/sbin/config -m AVILA TB --- 2011-11-17 08:26:17 - building AVILA kernel TB --- 2011-11-17 08:26:17 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 08:26:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 08:26:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 08:26:17 - SRCCONF=/dev/null TB --- 2011-11-17 08:26:17 - TARGET=arm TB --- 2011-11-17 08:26:17 - TARGET_ARCH=arm TB --- 2011-11-17 08:26:17 - TZ=UTC TB --- 2011-11-17 08:26:17 - __MAKE_CONF=/dev/null TB --- 2011-11-17 08:26:17 - cd /src TB --- 2011-11-17 08:26:17 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Thu Nov 17 08:26:18 UTC 2011 >>> 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 >>> Kernel build for AVILA completed on Thu Nov 17 08:29:46 UTC 2011 TB --- 2011-11-17 08:29:46 - cd /src/sys/arm/conf TB --- 2011-11-17 08:29:46 - /usr/sbin/config -m BWCT TB --- 2011-11-17 08:29:47 - building BWCT kernel TB --- 2011-11-17 08:29:47 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 08:29:47 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 08:29:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 08:29:47 - SRCCONF=/dev/null TB --- 2011-11-17 08:29:47 - TARGET=arm TB --- 2011-11-17 08:29:47 - TARGET_ARCH=arm TB --- 2011-11-17 08:29:47 - TZ=UTC TB --- 2011-11-17 08:29:47 - __MAKE_CONF=/dev/null TB --- 2011-11-17 08:29:47 - cd /src TB --- 2011-11-17 08:29:47 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Thu Nov 17 08:29:47 UTC 2011 >>> 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 >>> Kernel build for BWCT completed on Thu Nov 17 08:31:54 UTC 2011 TB --- 2011-11-17 08:31:54 - cd /src/sys/arm/conf TB --- 2011-11-17 08:31:54 - /usr/sbin/config -m CAMBRIA TB --- 2011-11-17 08:31:54 - building CAMBRIA kernel TB --- 2011-11-17 08:31:54 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 08:31:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 08:31:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 08:31:54 - SRCCONF=/dev/null TB --- 2011-11-17 08:31:54 - TARGET=arm TB --- 2011-11-17 08:31:54 - TARGET_ARCH=arm TB --- 2011-11-17 08:31:54 - TZ=UTC TB --- 2011-11-17 08:31:54 - __MAKE_CONF=/dev/null TB --- 2011-11-17 08:31:54 - cd /src TB --- 2011-11-17 08:31:54 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Thu Nov 17 08:31:54 UTC 2011 >>> 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 >>> Kernel build for CAMBRIA completed on Thu Nov 17 08:34:52 UTC 2011 TB --- 2011-11-17 08:34:52 - cd /src/sys/arm/conf TB --- 2011-11-17 08:34:52 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-11-17 08:34:52 - building CNS11XXNAS kernel TB --- 2011-11-17 08:34:52 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 08:34:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 08:34:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 08:34:52 - SRCCONF=/dev/null TB --- 2011-11-17 08:34:52 - TARGET=arm TB --- 2011-11-17 08:34:52 - TARGET_ARCH=arm TB --- 2011-11-17 08:34:52 - TZ=UTC TB --- 2011-11-17 08:34:52 - __MAKE_CONF=/dev/null TB --- 2011-11-17 08:34:52 - cd /src TB --- 2011-11-17 08:34:52 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Thu Nov 17 08:34:52 UTC 2011 >>> 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 >>> Kernel build for CNS11XXNAS completed on Thu Nov 17 08:37:24 UTC 2011 TB --- 2011-11-17 08:37:24 - cd /src/sys/arm/conf TB --- 2011-11-17 08:37:24 - /usr/sbin/config -m CRB TB --- 2011-11-17 08:37:24 - building CRB kernel TB --- 2011-11-17 08:37:24 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 08:37:24 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 08:37:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 08:37:24 - SRCCONF=/dev/null TB --- 2011-11-17 08:37:24 - TARGET=arm TB --- 2011-11-17 08:37:24 - TARGET_ARCH=arm TB --- 2011-11-17 08:37:24 - TZ=UTC TB --- 2011-11-17 08:37:24 - __MAKE_CONF=/dev/null TB --- 2011-11-17 08:37:24 - cd /src TB --- 2011-11-17 08:37:24 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Thu Nov 17 08:37:24 UTC 2011 >>> 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 >>> Kernel build for CRB completed on Thu Nov 17 08:41:13 UTC 2011 TB --- 2011-11-17 08:41:13 - cd /src/sys/arm/conf TB --- 2011-11-17 08:41:13 - /usr/sbin/config -m DB-78XXX TB --- 2011-11-17 08:41:13 - building DB-78XXX kernel TB --- 2011-11-17 08:41:13 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 08:41:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 08:41:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 08:41:13 - SRCCONF=/dev/null TB --- 2011-11-17 08:41:13 - TARGET=arm TB --- 2011-11-17 08:41:13 - TARGET_ARCH=arm TB --- 2011-11-17 08:41:13 - TZ=UTC TB --- 2011-11-17 08:41:13 - __MAKE_CONF=/dev/null TB --- 2011-11-17 08:41:13 - cd /src TB --- 2011-11-17 08:41:13 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Thu Nov 17 08:41:13 UTC 2011 >>> 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 >>> Kernel build for DB-78XXX completed on Thu Nov 17 08:43:56 UTC 2011 TB --- 2011-11-17 08:43:56 - cd /src/sys/arm/conf TB --- 2011-11-17 08:43:56 - /usr/sbin/config -m DB-88F5XXX TB --- 2011-11-17 08:43:57 - building DB-88F5XXX kernel TB --- 2011-11-17 08:43:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 08:43:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 08:43:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 08:43:57 - SRCCONF=/dev/null TB --- 2011-11-17 08:43:57 - TARGET=arm TB --- 2011-11-17 08:43:57 - TARGET_ARCH=arm TB --- 2011-11-17 08:43:57 - TZ=UTC TB --- 2011-11-17 08:43:57 - __MAKE_CONF=/dev/null TB --- 2011-11-17 08:43:57 - cd /src TB --- 2011-11-17 08:43:57 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Thu Nov 17 08:43:57 UTC 2011 >>> 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 >>> Kernel build for DB-88F5XXX completed on Thu Nov 17 08:46:35 UTC 2011 TB --- 2011-11-17 08:46:35 - cd /src/sys/arm/conf TB --- 2011-11-17 08:46:35 - /usr/sbin/config -m DB-88F6XXX TB --- 2011-11-17 08:46:35 - building DB-88F6XXX kernel TB --- 2011-11-17 08:46:35 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 08:46:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 08:46:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 08:46:35 - SRCCONF=/dev/null TB --- 2011-11-17 08:46:35 - TARGET=arm TB --- 2011-11-17 08:46:35 - TARGET_ARCH=arm TB --- 2011-11-17 08:46:35 - TZ=UTC TB --- 2011-11-17 08:46:35 - __MAKE_CONF=/dev/null TB --- 2011-11-17 08:46:35 - cd /src TB --- 2011-11-17 08:46:35 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Thu Nov 17 08:46:35 UTC 2011 >>> 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 >>> Kernel build for DB-88F6XXX completed on Thu Nov 17 08:49:12 UTC 2011 TB --- 2011-11-17 08:49:12 - cd /src/sys/arm/conf TB --- 2011-11-17 08:49:12 - /usr/sbin/config -m DOCKSTAR TB --- 2011-11-17 08:49:12 - building DOCKSTAR kernel TB --- 2011-11-17 08:49:12 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 08:49:12 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 08:49:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 08:49:12 - SRCCONF=/dev/null TB --- 2011-11-17 08:49:12 - TARGET=arm TB --- 2011-11-17 08:49:12 - TARGET_ARCH=arm TB --- 2011-11-17 08:49:12 - TZ=UTC TB --- 2011-11-17 08:49:12 - __MAKE_CONF=/dev/null TB --- 2011-11-17 08:49:12 - cd /src TB --- 2011-11-17 08:49:12 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Thu Nov 17 08:49:12 UTC 2011 >>> 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 >>> Kernel build for DOCKSTAR completed on Thu Nov 17 08:52:14 UTC 2011 TB --- 2011-11-17 08:52:14 - cd /src/sys/arm/conf TB --- 2011-11-17 08:52:14 - /usr/sbin/config -m EP80219 TB --- 2011-11-17 08:52:14 - building EP80219 kernel TB --- 2011-11-17 08:52:14 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 08:52:14 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 08:52:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 08:52:14 - SRCCONF=/dev/null TB --- 2011-11-17 08:52:14 - TARGET=arm TB --- 2011-11-17 08:52:14 - TARGET_ARCH=arm TB --- 2011-11-17 08:52:14 - TZ=UTC TB --- 2011-11-17 08:52:14 - __MAKE_CONF=/dev/null TB --- 2011-11-17 08:52:14 - cd /src TB --- 2011-11-17 08:52:14 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Thu Nov 17 08:52:14 UTC 2011 >>> 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 >>> Kernel build for EP80219 completed on Thu Nov 17 08:55:05 UTC 2011 TB --- 2011-11-17 08:55:05 - WARNING: no kernel config for GENERIC TB --- 2011-11-17 08:55:05 - cd /src/sys/arm/conf TB --- 2011-11-17 08:55:05 - /usr/sbin/config -m GUMSTIX TB --- 2011-11-17 08:55:05 - building GUMSTIX kernel TB --- 2011-11-17 08:55:05 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 08:55:05 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 08:55:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 08:55:05 - SRCCONF=/dev/null TB --- 2011-11-17 08:55:05 - TARGET=arm TB --- 2011-11-17 08:55:05 - TARGET_ARCH=arm TB --- 2011-11-17 08:55:05 - TZ=UTC TB --- 2011-11-17 08:55:05 - __MAKE_CONF=/dev/null TB --- 2011-11-17 08:55:05 - cd /src TB --- 2011-11-17 08:55:05 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Thu Nov 17 08:55:05 UTC 2011 >>> 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 >>> Kernel build for GUMSTIX completed on Thu Nov 17 08:57:23 UTC 2011 TB --- 2011-11-17 08:57:23 - cd /src/sys/arm/conf TB --- 2011-11-17 08:57:23 - /usr/sbin/config -m HL200 TB --- 2011-11-17 08:57:24 - building HL200 kernel TB --- 2011-11-17 08:57:24 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 08:57:24 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 08:57:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 08:57:24 - SRCCONF=/dev/null TB --- 2011-11-17 08:57:24 - TARGET=arm TB --- 2011-11-17 08:57:24 - TARGET_ARCH=arm TB --- 2011-11-17 08:57:24 - TZ=UTC TB --- 2011-11-17 08:57:24 - __MAKE_CONF=/dev/null TB --- 2011-11-17 08:57:24 - cd /src TB --- 2011-11-17 08:57:24 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Thu Nov 17 08:57:24 UTC 2011 >>> 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 >>> Kernel build for HL200 completed on Thu Nov 17 09:00:01 UTC 2011 TB --- 2011-11-17 09:00:01 - cd /src/sys/arm/conf TB --- 2011-11-17 09:00:01 - /usr/sbin/config -m HL201 TB --- 2011-11-17 09:00:02 - building HL201 kernel TB --- 2011-11-17 09:00:02 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 09:00:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 09:00:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 09:00:02 - SRCCONF=/dev/null TB --- 2011-11-17 09:00:02 - TARGET=arm TB --- 2011-11-17 09:00:02 - TARGET_ARCH=arm TB --- 2011-11-17 09:00:02 - TZ=UTC TB --- 2011-11-17 09:00:02 - __MAKE_CONF=/dev/null TB --- 2011-11-17 09:00:02 - cd /src TB --- 2011-11-17 09:00:02 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Thu Nov 17 09:00:02 UTC 2011 >>> 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 >>> Kernel build for HL201 completed on Thu Nov 17 09:02:17 UTC 2011 TB --- 2011-11-17 09:02:17 - cd /src/sys/arm/conf TB --- 2011-11-17 09:02:17 - /usr/sbin/config -m IQ31244 TB --- 2011-11-17 09:02:17 - building IQ31244 kernel TB --- 2011-11-17 09:02:17 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 09:02:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 09:02:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 09:02:17 - SRCCONF=/dev/null TB --- 2011-11-17 09:02:17 - TARGET=arm TB --- 2011-11-17 09:02:17 - TARGET_ARCH=arm TB --- 2011-11-17 09:02:17 - TZ=UTC TB --- 2011-11-17 09:02:17 - __MAKE_CONF=/dev/null TB --- 2011-11-17 09:02:17 - cd /src TB --- 2011-11-17 09:02:17 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Thu Nov 17 09:02:17 UTC 2011 >>> 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 >>> Kernel build for IQ31244 completed on Thu Nov 17 09:05:29 UTC 2011 TB --- 2011-11-17 09:05:29 - cd /src/sys/arm/conf TB --- 2011-11-17 09:05:29 - /usr/sbin/config -m KB920X TB --- 2011-11-17 09:05:29 - building KB920X kernel TB --- 2011-11-17 09:05:29 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 09:05:29 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 09:05:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 09:05:29 - SRCCONF=/dev/null TB --- 2011-11-17 09:05:29 - TARGET=arm TB --- 2011-11-17 09:05:29 - TARGET_ARCH=arm TB --- 2011-11-17 09:05:29 - TZ=UTC TB --- 2011-11-17 09:05:29 - __MAKE_CONF=/dev/null TB --- 2011-11-17 09:05:29 - cd /src TB --- 2011-11-17 09:05:29 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Thu Nov 17 09:05:30 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 09:14:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 09:14:50 - ERROR: failed to build KB920X kernel TB --- 2011-11-17 09:14:50 - 4684.11 user 1153.83 system 6289.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 09:29:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8562D106566B; Thu, 17 Nov 2011 09:29:08 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id E134A8FC12; Thu, 17 Nov 2011 09:29:07 +0000 (UTC) Received: by eyd10 with SMTP id 10so2473052eyd.13 for ; Thu, 17 Nov 2011 01:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=axBLy6wf+6mrq4RRsYquU7mP09vc8/ux5D6bKqN3/YU=; b=FyEg47dT2yQqlFXARbfjYr8tBrJnwbx37SDrjD+r0tVb9yFw0UMDwhxF6X0ddL/yXu aH0BxuBscaG8kkiy9MTklB++khzD6irigDHS+EUWhc22es27u/18OouVZXbA8Yh7OZ9y HDYZEagOACPoezhGTD7eF2jeLrcScanAInXnU= Received: by 10.14.16.23 with SMTP id g23mr2661717eeg.170.1321522145227; Thu, 17 Nov 2011 01:29:05 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id 49sm87897559eec.1.2011.11.17.01.29.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 01:29:04 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC4D3DE.8080103@FreeBSD.org> Date: Thu, 17 Nov 2011 11:29:02 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kostik Belousov References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <20111116202714.5ee4bd53@fabiankeil.de> <4EC43764.1020202@FreeBSD.org> <4EC4423A.3020904@FreeBSD.org> <20111117081533.GP50300@deviant.kiev.zoral.com.ua> <4EC4C89A.2040208@FreeBSD.org> <20111117090653.GR50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111117090653.GR50300@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:29:08 -0000 On 11/17/11 11:06, Kostik Belousov wrote: > On Thu, Nov 17, 2011 at 10:40:58AM +0200, Alexander Motin wrote: >> On 11/17/11 10:15, Kostik Belousov wrote: >>> On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote: >>>> On 17.11.2011 00:21, Andriy Gapon wrote: >>>>> on 16/11/2011 21:27 Fabian Keil said the following: >>>>>> Kostik Belousov wrote: >>>>>> >>>>>>> I was tricked into finishing the work by Andrey Gapon, who developed >>>>>>> the patch to reliably stop other processors on panic. The patch >>>>>>> greatly improves the chances of getting dump on panic on SMP host. >>>>>> >>>>>> I tested the patch trying to get a dump (from the debugger) for >>>>>> kern/162036, which currently results in the double fault reported in: >>>>>> http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027766.html >>>>>> >>>>>> It didn't help, but also didn't make anything worse. >>>>>> >>>>>> Fabian >>>>> >>>>> The mi_switch recursion looks very familiar to me: >>>>> mi_switch() at mi_switch+0x270 >>>>> critical_exit() at critical_exit+0x9b >>>>> spinlock_exit() at spinlock_exit+0x17 >>>>> mi_switch() at mi_switch+0x275 >>>>> critical_exit() at critical_exit+0x9b >>>>> spinlock_exit() at spinlock_exit+0x17 >>>>> [several pages of the previous three lines skipped] >>>>> mi_switch() at mi_switch+0x275 >>>>> critical_exit() at critical_exit+0x9b >>>>> spinlock_exit() at spinlock_exit+0x17 >>>>> intr_even_schedule_thread() at intr_event_schedule_thread+0xbb >>>>> ahci_end_transaction() at ahci_end_transaction+0x398 >>>>> ahci_ch_intr() at ahci_ch_intr+0x2b5 >>>>> ahcipoll() at ahcipoll+0x15 >>>>> xpt_polled_action() at xpt_polled_action+0xf7 >>>>> >>>>> In fact I once discussed with jhb this recursion triggered from a different >>>>> place. To quote myself: >>>>> spinlock_exit -> critical_exit -> mi_switch -> kdb_switch -> >>>>> thread_unlock -> spinlock_exit -> critical_exit -> mi_switch -> ... >>>>> in the kdb context >>>>> this issue seems to be triggered by td_owepreempt being true at >>>>> the time >>>>> kdb is entered >>>>> and there of course has to be an initial spinlock_exit call >>>>> somewhere >>>>> in my case it's because of usb keyboard >>>>> I wonder if it would make sense to clear td_owepreempt right >>>>> before >>>>> calling kdb_switch in mi_switch >>>>> instead of in sched_switch() >>>>> clearing td_owepreempt seems like a scheduler-independent >>>>> operation to me >>>>> or is it better to just skip locking in usb when kdb_active is set >>>>> ? >>>>> >>>>> The workaround described above should work in this case. >>>>> Another possibility is to pessimize mtx_unlock_spin() implementations to >>>>> check >>>>> SCHEDULER_STOPPED() and to bypass any further actions in that case. But >>>>> that >>>>> would add unnecessary overhead to the sunny day code paths. >>>>> >>>>> Going further up the stack one can come up with the following proposals: >>>>> - check SCHEDULER_STOPPED() swi_sched() and return early >>>>> - do not call swi_sched() from xpt_done() if we somehow know that we are >>>>> in a >>>>> polling mode >>>> >>>> There is no flag in CAM now to indicate polling mode, but if needed, it >>>> should not be difficult to add one and not call swi_sched(). >>> >>> I have the following change for eons on my test boxes. Without it, >>> I simply cannot get _any_ dump. >>> >>> diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c >>> index 10b89c7..a38e42f 100644 >>> --- a/sys/cam/cam_xpt.c >>> +++ b/sys/cam/cam_xpt.c >>> @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) >>> TAILQ_INSERT_TAIL(&cam_simq, sim, links); >>> mtx_unlock(&cam_simq_lock); >>> sim->flags |= CAM_SIM_ON_DONEQ; >>> - if (first) >>> + if (first && panicstr == NULL) >>> swi_sched(cambio_ih, 0); >>> } >>> } >> >> That should be OK for kernel dumping. I was thinking about CAM abusing >> polling not only for dumping. But looking on cases where it does it now, >> may be it is better to rewrite them instead. > > So, should I interpret your response as 'Reviewed by" ? It feels somehow dirty to me. I don't like these global variables. If you consider it is fine, proceed, I see no much harm. But if not, I can add polling flag to the CAM. Flip a coin for me. :) -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 09:47:48 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF416106566C; Thu, 17 Nov 2011 09:47:48 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 846B18FC16; Thu, 17 Nov 2011 09:47:47 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA10726; Thu, 17 Nov 2011 11:47:45 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RQyZM-000Bhv-Ru; Thu, 17 Nov 2011 11:47:45 +0200 Message-ID: <4EC4D83E.3090307@FreeBSD.org> Date: Thu, 17 Nov 2011 11:47:42 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Kostik Belousov References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <20111116202714.5ee4bd53@fabiankeil.de> <4EC43764.1020202@FreeBSD.org> <4EC4423A.3020904@FreeBSD.org> <20111117081533.GP50300@deviant.kiev.zoral.com.ua> <4EC4C712.8040701@FreeBSD.org> In-Reply-To: <4EC4C712.8040701@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@FreeBSD.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:47:49 -0000 on 17/11/2011 10:34 Andriy Gapon said the following: > on 17/11/2011 10:15 Kostik Belousov said the following: >> I have the following change for eons on my test boxes. Without it, >> I simply cannot get _any_ dump. >> >> diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c >> index 10b89c7..a38e42f 100644 >> --- a/sys/cam/cam_xpt.c >> +++ b/sys/cam/cam_xpt.c >> @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) >> TAILQ_INSERT_TAIL(&cam_simq, sim, links); >> mtx_unlock(&cam_simq_lock); >> sim->flags |= CAM_SIM_ON_DONEQ; >> - if (first) >> + if (first && panicstr == NULL) >> swi_sched(cambio_ih, 0); >> } >> } > > I think that this (or similar) change should go into the patch and the tree. > And, BTW, I still would like to do something like the following (perhaps with td_oncpu = NOCPU and td_flags &= ~TDF_NEEDRESCHED also moved to the common code): Index: sys/kern/sched_ule.c =================================================================== --- sys/kern/sched_ule.c (revision 227608) +++ sys/kern/sched_ule.c (working copy) @@ -1790,7 +1790,6 @@ sched_switch(struct thread *td, struct thread *new td->td_oncpu = NOCPU; if (!(flags & SW_PREEMPT)) td->td_flags &= ~TDF_NEEDRESCHED; - td->td_owepreempt = 0; tdq->tdq_switchcnt++; /* * The lock pointer in an idle thread should never change. Reset it Index: sys/kern/kern_synch.c =================================================================== --- sys/kern/kern_synch.c (revision 227608) +++ sys/kern/kern_synch.c (working copy) @@ -406,6 +406,8 @@ mi_switch(int flags, struct thread *newtd) ("mi_switch: switch must be voluntary or involuntary")); KASSERT(newtd != curthread, ("mi_switch: preempting back to ourself")); + td->td_owepreempt = 0; + /* * Don't perform context switches from the debugger. */ Index: sys/kern/sched_4bsd.c =================================================================== --- sys/kern/sched_4bsd.c (revision 227608) +++ sys/kern/sched_4bsd.c (working copy) @@ -940,7 +940,6 @@ sched_switch(struct thread *td, struct thread *new td->td_lastcpu = td->td_oncpu; if (!(flags & SW_PREEMPT)) td->td_flags &= ~TDF_NEEDRESCHED; - td->td_owepreempt = 0; td->td_oncpu = NOCPU; /* Does anybody see any potential problems with such a change? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 09:54:31 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66813106564A; Thu, 17 Nov 2011 09:54:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3B45D8FC08; Thu, 17 Nov 2011 09:54:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAH9sUih096393; Thu, 17 Nov 2011 04:54:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAH9sU4B096382; Thu, 17 Nov 2011 09:54:30 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 09:54:30 GMT Message-Id: <201111170954.pAH9sU4B096382@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:54:31 -0000 TB --- 2011-11-17 07:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 07:30:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-17 07:30:00 - cleaning the object tree TB --- 2011-11-17 07:30:22 - cvsupping the source tree TB --- 2011-11-17 07:30:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-17 07:30:37 - building world TB --- 2011-11-17 07:30:37 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 07:30:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 07:30:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 07:30:37 - SRCCONF=/dev/null TB --- 2011-11-17 07:30:37 - TARGET=pc98 TB --- 2011-11-17 07:30:37 - TARGET_ARCH=i386 TB --- 2011-11-17 07:30:37 - TZ=UTC TB --- 2011-11-17 07:30:37 - __MAKE_CONF=/dev/null TB --- 2011-11-17 07:30:37 - cd /src TB --- 2011-11-17 07:30:37 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 07:30:38 UTC 2011 >>> 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 Thu Nov 17 09:39:02 UTC 2011 TB --- 2011-11-17 09:39:02 - generating LINT kernel config TB --- 2011-11-17 09:39:02 - cd /src/sys/pc98/conf TB --- 2011-11-17 09:39:02 - /usr/bin/make -B LINT TB --- 2011-11-17 09:39:02 - cd /src/sys/pc98/conf TB --- 2011-11-17 09:39:02 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 09:39:02 - building GENERIC kernel TB --- 2011-11-17 09:39:02 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 09:39:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 09:39:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 09:39:02 - SRCCONF=/dev/null TB --- 2011-11-17 09:39:02 - TARGET=pc98 TB --- 2011-11-17 09:39:02 - TARGET_ARCH=i386 TB --- 2011-11-17 09:39:02 - TZ=UTC TB --- 2011-11-17 09:39:02 - __MAKE_CONF=/dev/null TB --- 2011-11-17 09:39:02 - cd /src TB --- 2011-11-17 09:39:02 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 09:39:02 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 09:54:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 09:54:30 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 09:54:30 - 6938.27 user 1220.23 system 8669.19 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 10:05:17 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BC96106566B; Thu, 17 Nov 2011 10:05:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 44CE28FC19; Thu, 17 Nov 2011 10:05:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHA5GDv079754; Thu, 17 Nov 2011 05:05:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHA5GiS079749; Thu, 17 Nov 2011 10:05:16 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 10:05:16 GMT Message-Id: <201111171005.pAHA5GiS079749@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 10:05:17 -0000 TB --- 2011-11-17 07:30:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 07:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-17 07:30:00 - cleaning the object tree TB --- 2011-11-17 07:30:22 - cvsupping the source tree TB --- 2011-11-17 07:30:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-17 07:30:37 - building world TB --- 2011-11-17 07:30:37 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 07:30:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 07:30:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 07:30:37 - SRCCONF=/dev/null TB --- 2011-11-17 07:30:37 - TARGET=i386 TB --- 2011-11-17 07:30:37 - TARGET_ARCH=i386 TB --- 2011-11-17 07:30:37 - TZ=UTC TB --- 2011-11-17 07:30:37 - __MAKE_CONF=/dev/null TB --- 2011-11-17 07:30:37 - cd /src TB --- 2011-11-17 07:30:37 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 07:30:38 UTC 2011 >>> 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 Thu Nov 17 09:39:23 UTC 2011 TB --- 2011-11-17 09:39:23 - generating LINT kernel config TB --- 2011-11-17 09:39:23 - cd /src/sys/i386/conf TB --- 2011-11-17 09:39:23 - /usr/bin/make -B LINT TB --- 2011-11-17 09:39:23 - cd /src/sys/i386/conf TB --- 2011-11-17 09:39:23 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-17 09:39:23 - building LINT-NOINET kernel TB --- 2011-11-17 09:39:23 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 09:39:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 09:39:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 09:39:23 - SRCCONF=/dev/null TB --- 2011-11-17 09:39:23 - TARGET=i386 TB --- 2011-11-17 09:39:23 - TARGET_ARCH=i386 TB --- 2011-11-17 09:39:23 - TZ=UTC TB --- 2011-11-17 09:39:23 - __MAKE_CONF=/dev/null TB --- 2011-11-17 09:39:23 - cd /src TB --- 2011-11-17 09:39:23 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Nov 17 09:39:23 UTC 2011 >>> 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 [...] ld -Bshareable -d -warn-common -o if_sf.ko if_sf.kld objcopy --strip-debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT-NOINET/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/i386.i386/src/sys/LINT-NOINET -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT-NOINET/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/i386.i386/src/sys/LINT-NOINET -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 10:05:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 10:05:16 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-17 10:05:16 - 7492.04 user 1272.04 system 9315.28 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 11:01:16 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 529D1106566C; Thu, 17 Nov 2011 11:01:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 260608FC17; Thu, 17 Nov 2011 11:01:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHB1Fil066107; Thu, 17 Nov 2011 06:01:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHB1Fel066091; Thu, 17 Nov 2011 11:01:15 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 11:01:15 GMT Message-Id: <201111171101.pAHB1Fel066091@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 11:01:16 -0000 TB --- 2011-11-17 09:14:51 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 09:14:51 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-17 09:14:51 - cleaning the object tree TB --- 2011-11-17 09:15:03 - cvsupping the source tree TB --- 2011-11-17 09:15:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-17 09:15:54 - building world TB --- 2011-11-17 09:15:54 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 09:15:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 09:15:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 09:15:54 - SRCCONF=/dev/null TB --- 2011-11-17 09:15:54 - TARGET=ia64 TB --- 2011-11-17 09:15:54 - TARGET_ARCH=ia64 TB --- 2011-11-17 09:15:54 - TZ=UTC TB --- 2011-11-17 09:15:54 - __MAKE_CONF=/dev/null TB --- 2011-11-17 09:15:54 - cd /src TB --- 2011-11-17 09:15:54 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 09:15:55 UTC 2011 >>> 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 Thu Nov 17 10:42:20 UTC 2011 TB --- 2011-11-17 10:42:21 - generating LINT kernel config TB --- 2011-11-17 10:42:21 - cd /src/sys/ia64/conf TB --- 2011-11-17 10:42:21 - /usr/bin/make -B LINT TB --- 2011-11-17 10:42:21 - cd /src/sys/ia64/conf TB --- 2011-11-17 10:42:21 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 10:42:21 - building GENERIC kernel TB --- 2011-11-17 10:42:21 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 10:42:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 10:42:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 10:42:21 - SRCCONF=/dev/null TB --- 2011-11-17 10:42:21 - TARGET=ia64 TB --- 2011-11-17 10:42:21 - TARGET_ARCH=ia64 TB --- 2011-11-17 10:42:21 - TZ=UTC TB --- 2011-11-17 10:42:21 - __MAKE_CONF=/dev/null TB --- 2011-11-17 10:42:21 - cd /src TB --- 2011-11-17 10:42:21 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 10:42:21 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 11:01:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 11:01:15 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 11:01:15 - 5025.78 user 943.96 system 6383.94 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 11:14:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED9DC1065672; Thu, 17 Nov 2011 11:14:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 86F4A8FC08; Thu, 17 Nov 2011 11:14:12 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAHBE5xI044102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2011 13:14:05 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAHBE5xB013006; Thu, 17 Nov 2011 13:14:05 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAHBE5Dm013005; Thu, 17 Nov 2011 13:14:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 17 Nov 2011 13:14:05 +0200 From: Kostik Belousov To: Alexander Motin Message-ID: <20111117111405.GT50300@deviant.kiev.zoral.com.ua> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <20111116202714.5ee4bd53@fabiankeil.de> <4EC43764.1020202@FreeBSD.org> <4EC4423A.3020904@FreeBSD.org> <20111117081533.GP50300@deviant.kiev.zoral.com.ua> <4EC4C89A.2040208@FreeBSD.org> <20111117090653.GR50300@deviant.kiev.zoral.com.ua> <4EC4D3DE.8080103@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qzzl9rayGpn1ceqJ" Content-Disposition: inline In-Reply-To: <4EC4D3DE.8080103@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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-current@freebsd.org, Andriy Gapon Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 11:14:13 -0000 --Qzzl9rayGpn1ceqJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 17, 2011 at 11:29:02AM +0200, Alexander Motin wrote: > On 11/17/11 11:06, Kostik Belousov wrote: > > On Thu, Nov 17, 2011 at 10:40:58AM +0200, Alexander Motin wrote: > >> On 11/17/11 10:15, Kostik Belousov wrote: > >>> On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote: > >>>> On 17.11.2011 00:21, Andriy Gapon wrote: > >>>>> on 16/11/2011 21:27 Fabian Keil said the following: > >>>>>> Kostik Belousov wrote: > >>>>>> > >>>>>>> I was tricked into finishing the work by Andrey Gapon, who develo= ped > >>>>>>> the patch to reliably stop other processors on panic. The patch > >>>>>>> greatly improves the chances of getting dump on panic on SMP host. > >>>>>> > >>>>>> I tested the patch trying to get a dump (from the debugger) for > >>>>>> kern/162036, which currently results in the double fault reported = in: > >>>>>> http://lists.freebsd.org/pipermail/freebsd-current/2011-September/= 027766.html > >>>>>> > >>>>>> It didn't help, but also didn't make anything worse. > >>>>>> > >>>>>> Fabian > >>>>> > >>>>> The mi_switch recursion looks very familiar to me: > >>>>> mi_switch() at mi_switch+0x270 > >>>>> critical_exit() at critical_exit+0x9b > >>>>> spinlock_exit() at spinlock_exit+0x17 > >>>>> mi_switch() at mi_switch+0x275 > >>>>> critical_exit() at critical_exit+0x9b > >>>>> spinlock_exit() at spinlock_exit+0x17 > >>>>> [several pages of the previous three lines skipped] > >>>>> mi_switch() at mi_switch+0x275 > >>>>> critical_exit() at critical_exit+0x9b > >>>>> spinlock_exit() at spinlock_exit+0x17 > >>>>> intr_even_schedule_thread() at intr_event_schedule_thread+0xbb > >>>>> ahci_end_transaction() at ahci_end_transaction+0x398 > >>>>> ahci_ch_intr() at ahci_ch_intr+0x2b5 > >>>>> ahcipoll() at ahcipoll+0x15 > >>>>> xpt_polled_action() at xpt_polled_action+0xf7 > >>>>> > >>>>> In fact I once discussed with jhb this recursion triggered from a d= ifferent > >>>>> place. To quote myself: > >>>>> spinlock_exit -> critical_exit -> mi_switch -> kdb_swit= ch -> > >>>>> thread_unlock -> spinlock_exit -> critical_exit -> mi_switch -> = ... > >>>>> in the kdb context > >>>>> this issue seems to be triggered by td_owepreempt being tr= ue at=20 > >>>>> the time > >>>>> kdb is entered > >>>>> and there of course has to be an initial spinlock_exit cal= l=20 > >>>>> somewhere > >>>>> in my case it's because of usb keyboard > >>>>> I wonder if it would make sense to clear td_owepreempt rig= ht=20 > >>>>> before > >>>>> calling kdb_switch in mi_switch > >>>>> instead of in sched_switch() > >>>>> clearing td_owepreempt seems like a scheduler-independent= =20 > >>>>> operation to me > >>>>> or is it better to just skip locking in usb when kdb_activ= e is set > >>>>> ? > >>>>> > >>>>> The workaround described above should work in this case. > >>>>> Another possibility is to pessimize mtx_unlock_spin() implementatio= ns to=20 > >>>>> check > >>>>> SCHEDULER_STOPPED() and to bypass any further actions in that case.= But=20 > >>>>> that > >>>>> would add unnecessary overhead to the sunny day code paths. > >>>>> > >>>>> Going further up the stack one can come up with the following propo= sals: > >>>>> - check SCHEDULER_STOPPED() swi_sched() and return early > >>>>> - do not call swi_sched() from xpt_done() if we somehow know that w= e are=20 > >>>>> in a > >>>>> polling mode > >>>> > >>>> There is no flag in CAM now to indicate polling mode, but if needed,= it=20 > >>>> should not be difficult to add one and not call swi_sched(). > >>> > >>> I have the following change for eons on my test boxes. Without it, > >>> I simply cannot get _any_ dump. > >>> > >>> diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c > >>> index 10b89c7..a38e42f 100644 > >>> --- a/sys/cam/cam_xpt.c > >>> +++ b/sys/cam/cam_xpt.c > >>> @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) > >>> TAILQ_INSERT_TAIL(&cam_simq, sim, links); > >>> mtx_unlock(&cam_simq_lock); > >>> sim->flags |=3D CAM_SIM_ON_DONEQ; > >>> - if (first) > >>> + if (first && panicstr =3D=3D NULL) > >>> swi_sched(cambio_ih, 0); > >>> } > >>> } > >> > >> That should be OK for kernel dumping. I was thinking about CAM abusing > >> polling not only for dumping. But looking on cases where it does it no= w, > >> may be it is better to rewrite them instead. > >=20 > > So, should I interpret your response as 'Reviewed by" ? >=20 > It feels somehow dirty to me. I don't like these global variables. If > you consider it is fine, proceed, I see no much harm. But if not, I can > add polling flag to the CAM. Flip a coin for me. :) You promised to add the polling at summer' meeting in Kiev. Will you do it now ? --Qzzl9rayGpn1ceqJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7E7H0ACgkQC3+MBN1Mb4hTQACfbU7Gf0DWa1tO4ZiC9fzlEv+d 92kAnRotW8eifQEaYvgGPjwlsFUqn/hW =IIQ4 -----END PGP SIGNATURE----- --Qzzl9rayGpn1ceqJ-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 12:08:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A76181065673 for ; Thu, 17 Nov 2011 12:08:58 +0000 (UTC) (envelope-from landimatte@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3D1FF8FC1D for ; Thu, 17 Nov 2011 12:08:57 +0000 (UTC) Received: by faap15 with SMTP id p15so1869735faa.13 for ; Thu, 17 Nov 2011 04:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=ad6BIiuvflhwtjnbgFX1FD0Cb9bQXz2J8P6rnmjkmFM=; b=v89Nb7myRbgfSXQW/ytC9T9BmdFZYjxBc2Z9wRLALOzulzuExWI7lSjhl/XtOufTLV ZphQ1CbLIlCptuy9NXDlr3m5iEjDF+zTSPaxhCPJXU2mkkfd+P+RN0lzxedtF8jVv2m4 7akUM2VVXeKOR3HRSE61wOTh82O/EmQPSFF8A= Received: by 10.152.104.167 with SMTP id gf7mr23089709lab.46.1321529923223; Thu, 17 Nov 2011 03:38:43 -0800 (PST) MIME-Version: 1.0 Sender: landimatte@gmail.com Received: by 10.152.25.74 with HTTP; Thu, 17 Nov 2011 03:38:21 -0800 (PST) From: Matteo Landi Date: Thu, 17 Nov 2011 12:38:21 +0100 X-Google-Sender-Auth: -B-Yu3B_fUBWUF3nOltcjdqokI4 Message-ID: To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ixgbe and fast interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 12:08:58 -0000 Hi everybody, trying to measure the interrupt latency of a 10G Intel network adapter, I find out that the the used driver (ixgbe) can can be configured to work with both fast and standard interrupts. From my understanding of the BUS_SETUP_INTR(9) man page and sys/kern/kern_intr.c file, it seems that drivers in need of registering fast interrupts should call bus_setup_intr() specifying a filter function instead of a handler. My question is: why ixgbe_allocate_legacy() says it is allocating a fast interrupt (comments and error messages say so) but instead passes a handler instead of a filter to pci_setup_intr()? Is there anything I am not taking into account? Regards, Matteo -- http://www.matteolandi.net/ From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 12:16:43 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBD84106566C; Thu, 17 Nov 2011 12:16:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8A1028FC13; Thu, 17 Nov 2011 12:16:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHCGg37024445; Thu, 17 Nov 2011 07:16:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHCGgiu024428; Thu, 17 Nov 2011 12:16:42 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 12:16:42 GMT Message-Id: <201111171216.pAHCGgiu024428@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 12:16:43 -0000 TB --- 2011-11-17 10:05:16 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 10:05:16 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-17 10:05:16 - cleaning the object tree TB --- 2011-11-17 10:05:30 - cvsupping the source tree TB --- 2011-11-17 10:05:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-17 10:05:43 - building world TB --- 2011-11-17 10:05:43 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 10:05:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 10:05:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 10:05:43 - SRCCONF=/dev/null TB --- 2011-11-17 10:05:43 - TARGET=powerpc TB --- 2011-11-17 10:05:43 - TARGET_ARCH=powerpc TB --- 2011-11-17 10:05:43 - TZ=UTC TB --- 2011-11-17 10:05:43 - __MAKE_CONF=/dev/null TB --- 2011-11-17 10:05:43 - cd /src TB --- 2011-11-17 10:05:43 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 10:05:43 UTC 2011 >>> 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 Thu Nov 17 12:03:15 UTC 2011 TB --- 2011-11-17 12:03:15 - generating LINT kernel config TB --- 2011-11-17 12:03:15 - cd /src/sys/powerpc/conf TB --- 2011-11-17 12:03:15 - /usr/bin/make -B LINT TB --- 2011-11-17 12:03:15 - cd /src/sys/powerpc/conf TB --- 2011-11-17 12:03:15 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 12:03:16 - building GENERIC kernel TB --- 2011-11-17 12:03:16 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 12:03:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 12:03:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 12:03:16 - SRCCONF=/dev/null TB --- 2011-11-17 12:03:16 - TARGET=powerpc TB --- 2011-11-17 12:03:16 - TARGET_ARCH=powerpc TB --- 2011-11-17 12:03:16 - TZ=UTC TB --- 2011-11-17 12:03:16 - __MAKE_CONF=/dev/null TB --- 2011-11-17 12:03:16 - cd /src TB --- 2011-11-17 12:03:16 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 12:03:16 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 12:16:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 12:16:41 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 12:16:41 - 6279.67 user 1097.94 system 7885.10 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 12:20:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FA80106566C; Thu, 17 Nov 2011 12:20:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5B4D48FC16; Thu, 17 Nov 2011 12:20:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHCKDdd043421; Thu, 17 Nov 2011 07:20:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHCKDAH043420; Thu, 17 Nov 2011 12:20:13 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 12:20:13 GMT Message-Id: <201111171220.pAHCKDAH043420@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 12:20:14 -0000 TB --- 2011-11-17 11:01:15 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 11:01:15 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-11-17 11:01:15 - cleaning the object tree TB --- 2011-11-17 11:01:26 - cvsupping the source tree TB --- 2011-11-17 11:01:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-11-17 11:01:38 - building world TB --- 2011-11-17 11:01:38 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 11:01:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 11:01:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 11:01:38 - SRCCONF=/dev/null TB --- 2011-11-17 11:01:38 - TARGET=sparc64 TB --- 2011-11-17 11:01:38 - TARGET_ARCH=sparc64 TB --- 2011-11-17 11:01:38 - TZ=UTC TB --- 2011-11-17 11:01:38 - __MAKE_CONF=/dev/null TB --- 2011-11-17 11:01:38 - cd /src TB --- 2011-11-17 11:01:38 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 11:01:38 UTC 2011 >>> 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 Thu Nov 17 12:05:07 UTC 2011 TB --- 2011-11-17 12:05:07 - generating LINT kernel config TB --- 2011-11-17 12:05:07 - cd /src/sys/sparc64/conf TB --- 2011-11-17 12:05:07 - /usr/bin/make -B LINT TB --- 2011-11-17 12:05:07 - cd /src/sys/sparc64/conf TB --- 2011-11-17 12:05:07 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 12:05:07 - building GENERIC kernel TB --- 2011-11-17 12:05:07 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 12:05:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 12:05:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 12:05:07 - SRCCONF=/dev/null TB --- 2011-11-17 12:05:07 - TARGET=sparc64 TB --- 2011-11-17 12:05:07 - TARGET_ARCH=sparc64 TB --- 2011-11-17 12:05:07 - TZ=UTC TB --- 2011-11-17 12:05:07 - __MAKE_CONF=/dev/null TB --- 2011-11-17 12:05:07 - cd /src TB --- 2011-11-17 12:05:07 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 12:05:07 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 12:20:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 12:20:13 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 12:20:13 - 3533.14 user 802.40 system 4737.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 12:40:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AF0D106567A; Thu, 17 Nov 2011 12:40:50 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 37AFF8FC25; Thu, 17 Nov 2011 12:40:49 +0000 (UTC) Received: by eyd10 with SMTP id 10so2767285eyd.13 for ; Thu, 17 Nov 2011 04:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=G38ieQvJBRUWS5QyuoIRlZWUZZvfA/GZD8wqpEseBTc=; b=slQYnjceFKw4rwo+h2APvIkxi5qzYtHogXa2ggx0qvrLMV0HzeXLJ/hKgtWQ7niCez NlUunVN/cJMsM84qBTuJmpwHwzVfoyM0ia1rSLYC2DUHUwglb2NZ/gBIJsYHa/0vMqzU AC2ixeXz+TQQWl488xi8QotTMMqKETF24UEI8= Received: by 10.213.22.133 with SMTP id n5mr4961ebb.149.1321533648562; Thu, 17 Nov 2011 04:40:48 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id q28sm89343784eea.6.2011.11.17.04.40.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 04:40:47 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC500CD.6040305@FreeBSD.org> Date: Thu, 17 Nov 2011 14:40:45 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kostik Belousov References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <20111116202714.5ee4bd53@fabiankeil.de> <4EC43764.1020202@FreeBSD.org> <4EC4423A.3020904@FreeBSD.org> <20111117081533.GP50300@deviant.kiev.zoral.com.ua> <4EC4C89A.2040208@FreeBSD.org> <20111117090653.GR50300@deviant.kiev.zoral.com.ua> <4EC4D3DE.8080103@FreeBSD.org> <20111117111405.GT50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111117111405.GT50300@deviant.kiev.zoral.com.ua> Content-Type: multipart/mixed; boundary="------------090104080008010605000800" Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 12:40:51 -0000 This is a multi-part message in MIME format. --------------090104080008010605000800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/17/11 13:14, Kostik Belousov wrote: > On Thu, Nov 17, 2011 at 11:29:02AM +0200, Alexander Motin wrote: >> On 11/17/11 11:06, Kostik Belousov wrote: >>> On Thu, Nov 17, 2011 at 10:40:58AM +0200, Alexander Motin wrote: >>>> On 11/17/11 10:15, Kostik Belousov wrote: >>>>> On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote: >>>>>> On 17.11.2011 00:21, Andriy Gapon wrote: >>>>>>> on 16/11/2011 21:27 Fabian Keil said the following: >>>>>>>> Kostik Belousov wrote: >>>>>>>> >>>>>>>>> I was tricked into finishing the work by Andrey Gapon, who developed >>>>>>>>> the patch to reliably stop other processors on panic. The patch >>>>>>>>> greatly improves the chances of getting dump on panic on SMP host. >>>>>>>> >>>>>>>> I tested the patch trying to get a dump (from the debugger) for >>>>>>>> kern/162036, which currently results in the double fault reported in: >>>>>>>> http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027766.html >>>>>>>> >>>>>>>> It didn't help, but also didn't make anything worse. >>>>>>>> >>>>>>>> Fabian >>>>>>> >>>>>>> The mi_switch recursion looks very familiar to me: >>>>>>> mi_switch() at mi_switch+0x270 >>>>>>> critical_exit() at critical_exit+0x9b >>>>>>> spinlock_exit() at spinlock_exit+0x17 >>>>>>> mi_switch() at mi_switch+0x275 >>>>>>> critical_exit() at critical_exit+0x9b >>>>>>> spinlock_exit() at spinlock_exit+0x17 >>>>>>> [several pages of the previous three lines skipped] >>>>>>> mi_switch() at mi_switch+0x275 >>>>>>> critical_exit() at critical_exit+0x9b >>>>>>> spinlock_exit() at spinlock_exit+0x17 >>>>>>> intr_even_schedule_thread() at intr_event_schedule_thread+0xbb >>>>>>> ahci_end_transaction() at ahci_end_transaction+0x398 >>>>>>> ahci_ch_intr() at ahci_ch_intr+0x2b5 >>>>>>> ahcipoll() at ahcipoll+0x15 >>>>>>> xpt_polled_action() at xpt_polled_action+0xf7 >>>>>>> >>>>>>> In fact I once discussed with jhb this recursion triggered from a different >>>>>>> place. To quote myself: >>>>>>> spinlock_exit -> critical_exit -> mi_switch -> kdb_switch -> >>>>>>> thread_unlock -> spinlock_exit -> critical_exit -> mi_switch -> ... >>>>>>> in the kdb context >>>>>>> this issue seems to be triggered by td_owepreempt being true at >>>>>>> the time >>>>>>> kdb is entered >>>>>>> and there of course has to be an initial spinlock_exit call >>>>>>> somewhere >>>>>>> in my case it's because of usb keyboard >>>>>>> I wonder if it would make sense to clear td_owepreempt right >>>>>>> before >>>>>>> calling kdb_switch in mi_switch >>>>>>> instead of in sched_switch() >>>>>>> clearing td_owepreempt seems like a scheduler-independent >>>>>>> operation to me >>>>>>> or is it better to just skip locking in usb when kdb_active is set >>>>>>> ? >>>>>>> >>>>>>> The workaround described above should work in this case. >>>>>>> Another possibility is to pessimize mtx_unlock_spin() implementations to >>>>>>> check >>>>>>> SCHEDULER_STOPPED() and to bypass any further actions in that case. But >>>>>>> that >>>>>>> would add unnecessary overhead to the sunny day code paths. >>>>>>> >>>>>>> Going further up the stack one can come up with the following proposals: >>>>>>> - check SCHEDULER_STOPPED() swi_sched() and return early >>>>>>> - do not call swi_sched() from xpt_done() if we somehow know that we are >>>>>>> in a >>>>>>> polling mode >>>>>> >>>>>> There is no flag in CAM now to indicate polling mode, but if needed, it >>>>>> should not be difficult to add one and not call swi_sched(). >>>>> >>>>> I have the following change for eons on my test boxes. Without it, >>>>> I simply cannot get _any_ dump. >>>>> >>>>> diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c >>>>> index 10b89c7..a38e42f 100644 >>>>> --- a/sys/cam/cam_xpt.c >>>>> +++ b/sys/cam/cam_xpt.c >>>>> @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) >>>>> TAILQ_INSERT_TAIL(&cam_simq, sim, links); >>>>> mtx_unlock(&cam_simq_lock); >>>>> sim->flags |= CAM_SIM_ON_DONEQ; >>>>> - if (first) >>>>> + if (first && panicstr == NULL) >>>>> swi_sched(cambio_ih, 0); >>>>> } >>>>> } >>>> >>>> That should be OK for kernel dumping. I was thinking about CAM abusing >>>> polling not only for dumping. But looking on cases where it does it now, >>>> may be it is better to rewrite them instead. >>> >>> So, should I interpret your response as 'Reviewed by" ? >> >> It feels somehow dirty to me. I don't like these global variables. If >> you consider it is fine, proceed, I see no much harm. But if not, I can >> add polling flag to the CAM. Flip a coin for me. :) > You promised to add the polling at summer' meeting in Kiev. Will you do > it now ? Sorry, I've probably forgot. The patch is attached. -- Alexander Motin --------------090104080008010605000800 Content-Type: text/plain; name="cam_poll.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cam_poll.patch" Index: cam_sim.h =================================================================== --- cam_sim.h (revision 227580) +++ cam_sim.h (working copy) @@ -104,7 +104,8 @@ u_int32_t flags; #define CAM_SIM_REL_TIMEOUT_PENDING 0x01 #define CAM_SIM_MPSAFE 0x02 -#define CAM_SIM_ON_DONEQ 0x04 +#define CAM_SIM_ON_DONEQ 0x04 +#define CAM_SIM_POLLED 0x08 struct callout callout; struct cam_devq *devq; /* Device Queue to use for this SIM */ int refcount; /* References to the SIM. */ Index: cam_xpt.c =================================================================== --- cam_xpt.c (revision 227580) +++ cam_xpt.c (working copy) @@ -2957,6 +2957,9 @@ mtx_assert(sim->mtx, MA_OWNED); + /* Don't use ISR for this SIM while polling. */ + sim->flags |= CAM_SIM_POLLED; + /* * Steal an opening so that no other queued requests * can get it before us while we simulate interrupts. @@ -2996,6 +2999,9 @@ } else { start_ccb->ccb_h.status = CAM_RESRC_UNAVAIL; } + + /* Use CAM ISR for this SIM again. */ + sim->flags &= ~CAM_SIM_POLLED; } /* @@ -4224,7 +4230,7 @@ TAILQ_INSERT_TAIL(&sim->sim_doneq, &done_ccb->ccb_h, sim_links.tqe); done_ccb->ccb_h.pinfo.index = CAM_DONEQ_INDEX; - if ((sim->flags & CAM_SIM_ON_DONEQ) == 0) { + if ((sim->flags & (CAM_SIM_ON_DONEQ | CAM_SIM_POLLED)) == 0) { mtx_lock(&cam_simq_lock); first = TAILQ_EMPTY(&cam_simq); TAILQ_INSERT_TAIL(&cam_simq, sim, links); --------------090104080008010605000800-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 12:42:03 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11ED41065678; Thu, 17 Nov 2011 12:42:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D89578FC15; Thu, 17 Nov 2011 12:42:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHCg1x3001166; Thu, 17 Nov 2011 07:42:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHCg1bx001165; Thu, 17 Nov 2011 12:42:01 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 12:42:01 GMT Message-Id: <201111171242.pAHCg1bx001165@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 12:42:03 -0000 TB --- 2011-11-17 10:53:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 10:53:01 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-17 10:53:01 - cleaning the object tree TB --- 2011-11-17 10:53:18 - cvsupping the source tree TB --- 2011-11-17 10:53:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-17 10:54:05 - building world TB --- 2011-11-17 10:54:05 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 10:54:05 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 10:54:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 10:54:05 - SRCCONF=/dev/null TB --- 2011-11-17 10:54:05 - TARGET=powerpc TB --- 2011-11-17 10:54:05 - TARGET_ARCH=powerpc64 TB --- 2011-11-17 10:54:05 - TZ=UTC TB --- 2011-11-17 10:54:05 - __MAKE_CONF=/dev/null TB --- 2011-11-17 10:54:05 - cd /src TB --- 2011-11-17 10:54:05 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 10:54:06 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Nov 17 12:29:05 UTC 2011 TB --- 2011-11-17 12:29:05 - generating LINT kernel config TB --- 2011-11-17 12:29:05 - cd /src/sys/powerpc/conf TB --- 2011-11-17 12:29:05 - /usr/bin/make -B LINT TB --- 2011-11-17 12:29:05 - cd /src/sys/powerpc/conf TB --- 2011-11-17 12:29:05 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 12:29:05 - skipping GENERIC kernel TB --- 2011-11-17 12:29:05 - cd /src/sys/powerpc/conf TB --- 2011-11-17 12:29:05 - /usr/sbin/config -m GENERIC64 TB --- 2011-11-17 12:29:05 - building GENERIC64 kernel TB --- 2011-11-17 12:29:05 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 12:29:05 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 12:29:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 12:29:05 - SRCCONF=/dev/null TB --- 2011-11-17 12:29:05 - TARGET=powerpc TB --- 2011-11-17 12:29:05 - TARGET_ARCH=powerpc64 TB --- 2011-11-17 12:29:05 - TZ=UTC TB --- 2011-11-17 12:29:05 - __MAKE_CONF=/dev/null TB --- 2011-11-17 12:29:05 - cd /src TB --- 2011-11-17 12:29:05 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Thu Nov 17 12:29:05 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 12:42:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 12:42:01 - ERROR: failed to build GENERIC64 kernel TB --- 2011-11-17 12:42:01 - 5024.95 user 1108.09 system 6540.22 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 13:37:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37392106564A for ; Thu, 17 Nov 2011 13:37:34 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 051218FC13 for ; Thu, 17 Nov 2011 13:37:34 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 89C7B119C7B; Thu, 17 Nov 2011 07:37:32 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1321537052; bh=LmkmVFiq1RQM+C3csVI6vr35eMH1LSDoYXf5isY81CY=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=LtHsgiOuNpjyCbVA2FzfiOtM3DSSz5euJAFSDC/eeb/EBfOztqCbq2gTbHzT29vKt T3on4c6SEws9/l7AaNdbhMXbO2Db1Sj/vzZo55TwaYBxih5KLl9ywOBa8ZGzm1gRNp VMwidLBfxFG6BYKLQ5jSjOuMR27/B7CgIf9viBhg= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 89392119C6C for ; Thu, 17 Nov 2011 07:37:32 -0600 (CST) Date: Thu, 17 Nov 2011 07:37:32 -0600 (CST) From: Dan The Man To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: spamcop abuse of power X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 13:37:34 -0000 Today I had an unhappy unix student try to submit an assignment to me and could not. Spamcop has decided to go off blacklisting all yahoo/shaw etc servers worldwide. Example Solution Postfix: remove: reject_rbl_client bl.spamcop.net from your smtpd_recipient_restrictions line until they fix their abuse issues. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 14:35:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1FF01065702; Thu, 17 Nov 2011 14:35:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 57D8B8FC12; Thu, 17 Nov 2011 14:35:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHEZApL059236; Thu, 17 Nov 2011 09:35:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHEZAfF059015; Thu, 17 Nov 2011 14:35:10 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 14:35:10 GMT Message-Id: <201111171435.pAHEZAfF059015@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 14:35:15 -0000 TB --- 2011-11-17 12:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 12:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-17 12:50:00 - cleaning the object tree TB --- 2011-11-17 12:50:29 - cvsupping the source tree TB --- 2011-11-17 12:50:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-17 12:50:57 - building world TB --- 2011-11-17 12:50:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 12:50:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 12:50:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 12:50:57 - SRCCONF=/dev/null TB --- 2011-11-17 12:50:57 - TARGET=arm TB --- 2011-11-17 12:50:57 - TARGET_ARCH=arm TB --- 2011-11-17 12:50:57 - TZ=UTC TB --- 2011-11-17 12:50:57 - __MAKE_CONF=/dev/null TB --- 2011-11-17 12:50:57 - cd /src TB --- 2011-11-17 12:50:57 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 12:50:57 UTC 2011 >>> 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 Thu Nov 17 13:45:59 UTC 2011 TB --- 2011-11-17 13:46:00 - cd /src/sys/arm/conf TB --- 2011-11-17 13:46:00 - /usr/sbin/config -m AVILA TB --- 2011-11-17 13:46:00 - building AVILA kernel TB --- 2011-11-17 13:46:00 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 13:46:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 13:46:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 13:46:00 - SRCCONF=/dev/null TB --- 2011-11-17 13:46:00 - TARGET=arm TB --- 2011-11-17 13:46:00 - TARGET_ARCH=arm TB --- 2011-11-17 13:46:00 - TZ=UTC TB --- 2011-11-17 13:46:00 - __MAKE_CONF=/dev/null TB --- 2011-11-17 13:46:00 - cd /src TB --- 2011-11-17 13:46:00 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Thu Nov 17 13:46:00 UTC 2011 >>> 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 >>> Kernel build for AVILA completed on Thu Nov 17 13:49:02 UTC 2011 TB --- 2011-11-17 13:49:02 - cd /src/sys/arm/conf TB --- 2011-11-17 13:49:02 - /usr/sbin/config -m BWCT TB --- 2011-11-17 13:49:02 - building BWCT kernel TB --- 2011-11-17 13:49:02 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 13:49:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 13:49:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 13:49:02 - SRCCONF=/dev/null TB --- 2011-11-17 13:49:02 - TARGET=arm TB --- 2011-11-17 13:49:02 - TARGET_ARCH=arm TB --- 2011-11-17 13:49:02 - TZ=UTC TB --- 2011-11-17 13:49:02 - __MAKE_CONF=/dev/null TB --- 2011-11-17 13:49:02 - cd /src TB --- 2011-11-17 13:49:02 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Thu Nov 17 13:49:02 UTC 2011 >>> 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 >>> Kernel build for BWCT completed on Thu Nov 17 13:51:13 UTC 2011 TB --- 2011-11-17 13:51:13 - cd /src/sys/arm/conf TB --- 2011-11-17 13:51:13 - /usr/sbin/config -m CAMBRIA TB --- 2011-11-17 13:51:13 - building CAMBRIA kernel TB --- 2011-11-17 13:51:13 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 13:51:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 13:51:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 13:51:13 - SRCCONF=/dev/null TB --- 2011-11-17 13:51:13 - TARGET=arm TB --- 2011-11-17 13:51:13 - TARGET_ARCH=arm TB --- 2011-11-17 13:51:13 - TZ=UTC TB --- 2011-11-17 13:51:13 - __MAKE_CONF=/dev/null TB --- 2011-11-17 13:51:13 - cd /src TB --- 2011-11-17 13:51:13 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Thu Nov 17 13:51:13 UTC 2011 >>> 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 >>> Kernel build for CAMBRIA completed on Thu Nov 17 13:54:38 UTC 2011 TB --- 2011-11-17 13:54:38 - cd /src/sys/arm/conf TB --- 2011-11-17 13:54:38 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-11-17 13:54:38 - building CNS11XXNAS kernel TB --- 2011-11-17 13:54:38 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 13:54:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 13:54:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 13:54:38 - SRCCONF=/dev/null TB --- 2011-11-17 13:54:38 - TARGET=arm TB --- 2011-11-17 13:54:38 - TARGET_ARCH=arm TB --- 2011-11-17 13:54:38 - TZ=UTC TB --- 2011-11-17 13:54:38 - __MAKE_CONF=/dev/null TB --- 2011-11-17 13:54:38 - cd /src TB --- 2011-11-17 13:54:38 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Thu Nov 17 13:54:38 UTC 2011 >>> 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 >>> Kernel build for CNS11XXNAS completed on Thu Nov 17 13:57:07 UTC 2011 TB --- 2011-11-17 13:57:07 - cd /src/sys/arm/conf TB --- 2011-11-17 13:57:07 - /usr/sbin/config -m CRB TB --- 2011-11-17 13:57:07 - building CRB kernel TB --- 2011-11-17 13:57:07 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 13:57:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 13:57:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 13:57:07 - SRCCONF=/dev/null TB --- 2011-11-17 13:57:07 - TARGET=arm TB --- 2011-11-17 13:57:07 - TARGET_ARCH=arm TB --- 2011-11-17 13:57:07 - TZ=UTC TB --- 2011-11-17 13:57:07 - __MAKE_CONF=/dev/null TB --- 2011-11-17 13:57:07 - cd /src TB --- 2011-11-17 13:57:07 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Thu Nov 17 13:57:07 UTC 2011 >>> 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 >>> Kernel build for CRB completed on Thu Nov 17 14:00:34 UTC 2011 TB --- 2011-11-17 14:00:34 - cd /src/sys/arm/conf TB --- 2011-11-17 14:00:34 - /usr/sbin/config -m DB-78XXX TB --- 2011-11-17 14:00:34 - building DB-78XXX kernel TB --- 2011-11-17 14:00:34 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 14:00:34 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 14:00:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 14:00:34 - SRCCONF=/dev/null TB --- 2011-11-17 14:00:34 - TARGET=arm TB --- 2011-11-17 14:00:34 - TARGET_ARCH=arm TB --- 2011-11-17 14:00:34 - TZ=UTC TB --- 2011-11-17 14:00:34 - __MAKE_CONF=/dev/null TB --- 2011-11-17 14:00:34 - cd /src TB --- 2011-11-17 14:00:34 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Thu Nov 17 14:00:34 UTC 2011 >>> 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 >>> Kernel build for DB-78XXX completed on Thu Nov 17 14:03:35 UTC 2011 TB --- 2011-11-17 14:03:35 - cd /src/sys/arm/conf TB --- 2011-11-17 14:03:35 - /usr/sbin/config -m DB-88F5XXX TB --- 2011-11-17 14:03:37 - building DB-88F5XXX kernel TB --- 2011-11-17 14:03:37 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 14:03:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 14:03:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 14:03:37 - SRCCONF=/dev/null TB --- 2011-11-17 14:03:37 - TARGET=arm TB --- 2011-11-17 14:03:37 - TARGET_ARCH=arm TB --- 2011-11-17 14:03:37 - TZ=UTC TB --- 2011-11-17 14:03:37 - __MAKE_CONF=/dev/null TB --- 2011-11-17 14:03:37 - cd /src TB --- 2011-11-17 14:03:37 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Thu Nov 17 14:03:37 UTC 2011 >>> 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 >>> Kernel build for DB-88F5XXX completed on Thu Nov 17 14:06:15 UTC 2011 TB --- 2011-11-17 14:06:15 - cd /src/sys/arm/conf TB --- 2011-11-17 14:06:15 - /usr/sbin/config -m DB-88F6XXX TB --- 2011-11-17 14:06:15 - building DB-88F6XXX kernel TB --- 2011-11-17 14:06:15 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 14:06:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 14:06:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 14:06:15 - SRCCONF=/dev/null TB --- 2011-11-17 14:06:15 - TARGET=arm TB --- 2011-11-17 14:06:15 - TARGET_ARCH=arm TB --- 2011-11-17 14:06:15 - TZ=UTC TB --- 2011-11-17 14:06:15 - __MAKE_CONF=/dev/null TB --- 2011-11-17 14:06:15 - cd /src TB --- 2011-11-17 14:06:15 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Thu Nov 17 14:06:15 UTC 2011 >>> 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 >>> Kernel build for DB-88F6XXX completed on Thu Nov 17 14:08:54 UTC 2011 TB --- 2011-11-17 14:08:54 - cd /src/sys/arm/conf TB --- 2011-11-17 14:08:54 - /usr/sbin/config -m DOCKSTAR TB --- 2011-11-17 14:08:54 - building DOCKSTAR kernel TB --- 2011-11-17 14:08:54 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 14:08:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 14:08:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 14:08:54 - SRCCONF=/dev/null TB --- 2011-11-17 14:08:54 - TARGET=arm TB --- 2011-11-17 14:08:54 - TARGET_ARCH=arm TB --- 2011-11-17 14:08:54 - TZ=UTC TB --- 2011-11-17 14:08:54 - __MAKE_CONF=/dev/null TB --- 2011-11-17 14:08:54 - cd /src TB --- 2011-11-17 14:08:54 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Thu Nov 17 14:08:54 UTC 2011 >>> 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 >>> Kernel build for DOCKSTAR completed on Thu Nov 17 14:11:58 UTC 2011 TB --- 2011-11-17 14:11:58 - cd /src/sys/arm/conf TB --- 2011-11-17 14:11:58 - /usr/sbin/config -m EP80219 TB --- 2011-11-17 14:11:58 - building EP80219 kernel TB --- 2011-11-17 14:11:58 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 14:11:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 14:11:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 14:11:58 - SRCCONF=/dev/null TB --- 2011-11-17 14:11:58 - TARGET=arm TB --- 2011-11-17 14:11:58 - TARGET_ARCH=arm TB --- 2011-11-17 14:11:58 - TZ=UTC TB --- 2011-11-17 14:11:58 - __MAKE_CONF=/dev/null TB --- 2011-11-17 14:11:58 - cd /src TB --- 2011-11-17 14:11:58 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Thu Nov 17 14:11:58 UTC 2011 >>> 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 >>> Kernel build for EP80219 completed on Thu Nov 17 14:14:50 UTC 2011 TB --- 2011-11-17 14:14:51 - WARNING: no kernel config for GENERIC TB --- 2011-11-17 14:14:51 - cd /src/sys/arm/conf TB --- 2011-11-17 14:14:51 - /usr/sbin/config -m GUMSTIX TB --- 2011-11-17 14:14:51 - building GUMSTIX kernel TB --- 2011-11-17 14:14:51 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 14:14:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 14:14:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 14:14:51 - SRCCONF=/dev/null TB --- 2011-11-17 14:14:51 - TARGET=arm TB --- 2011-11-17 14:14:51 - TARGET_ARCH=arm TB --- 2011-11-17 14:14:51 - TZ=UTC TB --- 2011-11-17 14:14:51 - __MAKE_CONF=/dev/null TB --- 2011-11-17 14:14:51 - cd /src TB --- 2011-11-17 14:14:51 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Thu Nov 17 14:14:51 UTC 2011 >>> 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 >>> Kernel build for GUMSTIX completed on Thu Nov 17 14:17:10 UTC 2011 TB --- 2011-11-17 14:17:10 - cd /src/sys/arm/conf TB --- 2011-11-17 14:17:10 - /usr/sbin/config -m HL200 TB --- 2011-11-17 14:17:10 - building HL200 kernel TB --- 2011-11-17 14:17:10 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 14:17:10 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 14:17:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 14:17:10 - SRCCONF=/dev/null TB --- 2011-11-17 14:17:10 - TARGET=arm TB --- 2011-11-17 14:17:10 - TARGET_ARCH=arm TB --- 2011-11-17 14:17:10 - TZ=UTC TB --- 2011-11-17 14:17:10 - __MAKE_CONF=/dev/null TB --- 2011-11-17 14:17:10 - cd /src TB --- 2011-11-17 14:17:10 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Thu Nov 17 14:17:10 UTC 2011 >>> 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 >>> Kernel build for HL200 completed on Thu Nov 17 14:20:16 UTC 2011 TB --- 2011-11-17 14:20:16 - cd /src/sys/arm/conf TB --- 2011-11-17 14:20:16 - /usr/sbin/config -m HL201 TB --- 2011-11-17 14:20:16 - building HL201 kernel TB --- 2011-11-17 14:20:16 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 14:20:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 14:20:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 14:20:16 - SRCCONF=/dev/null TB --- 2011-11-17 14:20:16 - TARGET=arm TB --- 2011-11-17 14:20:16 - TARGET_ARCH=arm TB --- 2011-11-17 14:20:16 - TZ=UTC TB --- 2011-11-17 14:20:16 - __MAKE_CONF=/dev/null TB --- 2011-11-17 14:20:16 - cd /src TB --- 2011-11-17 14:20:16 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Thu Nov 17 14:20:16 UTC 2011 >>> 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 >>> Kernel build for HL201 completed on Thu Nov 17 14:22:34 UTC 2011 TB --- 2011-11-17 14:22:34 - cd /src/sys/arm/conf TB --- 2011-11-17 14:22:34 - /usr/sbin/config -m IQ31244 TB --- 2011-11-17 14:22:34 - building IQ31244 kernel TB --- 2011-11-17 14:22:34 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 14:22:34 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 14:22:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 14:22:34 - SRCCONF=/dev/null TB --- 2011-11-17 14:22:34 - TARGET=arm TB --- 2011-11-17 14:22:34 - TARGET_ARCH=arm TB --- 2011-11-17 14:22:34 - TZ=UTC TB --- 2011-11-17 14:22:34 - __MAKE_CONF=/dev/null TB --- 2011-11-17 14:22:34 - cd /src TB --- 2011-11-17 14:22:34 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Thu Nov 17 14:22:34 UTC 2011 >>> 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 >>> Kernel build for IQ31244 completed on Thu Nov 17 14:25:47 UTC 2011 TB --- 2011-11-17 14:25:47 - cd /src/sys/arm/conf TB --- 2011-11-17 14:25:47 - /usr/sbin/config -m KB920X TB --- 2011-11-17 14:25:47 - building KB920X kernel TB --- 2011-11-17 14:25:47 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 14:25:47 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 14:25:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 14:25:47 - SRCCONF=/dev/null TB --- 2011-11-17 14:25:47 - TARGET=arm TB --- 2011-11-17 14:25:47 - TARGET_ARCH=arm TB --- 2011-11-17 14:25:47 - TZ=UTC TB --- 2011-11-17 14:25:47 - __MAKE_CONF=/dev/null TB --- 2011-11-17 14:25:47 - cd /src TB --- 2011-11-17 14:25:47 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Thu Nov 17 14:25:48 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 14:35:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 14:35:09 - ERROR: failed to build KB920X kernel TB --- 2011-11-17 14:35:09 - 4721.37 user 1164.45 system 6309.36 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 14:42:27 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E83E8106566C for ; Thu, 17 Nov 2011 14:42:27 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7B7D48FC08 for ; Thu, 17 Nov 2011 14:42:27 +0000 (UTC) Received: by eyd10 with SMTP id 10so2979076eyd.13 for ; Thu, 17 Nov 2011 06:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=Q0c85B+YViDnvZL2lOyEtXEf/nE4MsWe5N99SdD3PTM=; b=hwoduhGhbhaXJaQUXus2QfhXo1IjtaDCndhhJrrfVLw0Nm+EVrVy/kyVViSmYq4Kka gvASS//UJbGohuJl+ZdBLaU/zF8nMCAh1k1QsTCpo0f8p4yeWNAyyYNlXAbIJ0pzeKJf OZn2QXd93NARbFh/4aIaLFLPSq7DmS3ohQyBY= Received: by 10.229.233.213 with SMTP id jz21mr5043221qcb.1.1321539053118; Thu, 17 Nov 2011 06:10:53 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.229.53.78 with HTTP; Thu, 17 Nov 2011 06:10:32 -0800 (PST) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Thu, 17 Nov 2011 15:10:32 +0100 X-Google-Sender-Auth: txfnYFeUHx4-CbhWiZ-fZ9_x0n0 Message-ID: To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 17 Nov 2011 14:46:13 +0000 Subject: Can't install FreeBSD-amd64-9.0-RC2: "/mnt: out of inodes" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 14:42:28 -0000 Hi all, I tried to install FreeBSD-9.0-RC2-amd64-dvd1.iso (SHA256 verified) on a VM and meet a reproducible problem: The VM has 128Mo RAM and a 4Go hard drive. During install process I choose these distribution sets: ports and src only. And I'm using guided partitioning / Entire Disk / All Auto But each time (I delete and re-create a new VM multiple times) the installer failed during archive extraction of ports.txz (at about 88% progress of this file extraction) with this message: Error while extracting ports.txz: Can't create 'usr/ports/databases/p5-DBIx-Sunny/pkg-plist' And on the background there is this message: ...on /mnt: out of inodes Can someone else confirm this problem before I fill a PR ? Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 14:56:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E6F1106566C for ; Thu, 17 Nov 2011 14:56:10 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9CD7A8FC1F for ; Thu, 17 Nov 2011 14:56:09 +0000 (UTC) Received: by wwg14 with SMTP id 14so2973373wwg.31 for ; Thu, 17 Nov 2011 06:56:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZAUj82B5zf6kWnp1f1afpFvVYia5XzrYUTkeovHD3EA=; b=PwVr8/cFvI5eRGOXb3apJqGNhYjy71nyy7ykX99Hc9uOKzkmxW7YNC1ml2X+qIMHlo 4rnjFgBQm5g7l0kK7uXHhIfK992Rjk5sxxZ+m6ihzLH9NvNrwPwTWeciQ8URAZD+iJDK F+L/oTHhYJDvIjv+q/ENW37/zOWRgNCqEMdCE= MIME-Version: 1.0 Received: by 10.180.108.47 with SMTP id hh15mr651926wib.14.1321541768510; Thu, 17 Nov 2011 06:56:08 -0800 (PST) Received: by 10.180.95.104 with HTTP; Thu, 17 Nov 2011 06:56:08 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Nov 2011 09:56:08 -0500 Message-ID: From: Ryan Stone To: Matteo Landi Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: ixgbe and fast interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 14:56:10 -0000 The comments haven't kept up with the code. You are correct; in the legacy interrupt case ixgbe is using an ITHREAD, not a fast handler. From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 14:59:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E8881065674 for ; Thu, 17 Nov 2011 14:59:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 46B578FC1A for ; Thu, 17 Nov 2011 14:59:58 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EF5CD46B06; Thu, 17 Nov 2011 09:59:57 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 96DB98A051; Thu, 17 Nov 2011 09:59:57 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 17 Nov 2011 09:53:58 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111170953.58151.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 17 Nov 2011 09:59:57 -0500 (EST) Cc: Matteo Landi Subject: Re: ixgbe and fast interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 14:59:58 -0000 On Thursday, November 17, 2011 6:38:21 am Matteo Landi wrote: > Hi everybody, > > trying to measure the interrupt latency of a 10G Intel network > adapter, I find out that the the used driver (ixgbe) can can be > configured to work with both fast and standard interrupts. From my > understanding of the BUS_SETUP_INTR(9) man page and > sys/kern/kern_intr.c file, it seems that drivers in need of > registering fast interrupts should call bus_setup_intr() specifying a > filter function instead of a handler. > > My question is: why ixgbe_allocate_legacy() says it is allocating a > fast interrupt (comments and error messages say so) but instead passes > a handler instead of a filter to pci_setup_intr()? Is there anything I > am not taking into account? It is not a fast handler and is not using the fast handler stuff. OTOH, you probably want to be using MSI-X for a 10G NIC instead of INTx anyway. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 14:59:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE3A71065677; Thu, 17 Nov 2011 14:59:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A23498FC1B; Thu, 17 Nov 2011 14:59:58 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4F2AC46B0A; Thu, 17 Nov 2011 09:59:58 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DC1A78A053; Thu, 17 Nov 2011 09:59:57 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 17 Nov 2011 09:59:56 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201111170959.56767.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 17 Nov 2011 09:59:58 -0500 (EST) Cc: Kostik Belousov , Adrian Chadd , freebsd-arch@freebsd.org, Warner Losh , Robert Millan Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 14:59:58 -0000 On Thursday, November 17, 2011 1:46:33 am Robert Millan wrote: > 2011/11/16 Warner Losh : > > My second reaction was why not have > > > > #ifndef __FreeBSD_kernel__ > > #define __FreeBSD_kernel__ __FreeBSD__ > > #endif > > > > in sys/param.h and then just change __FreeBSD__ to __FreeBSD_kernel__ in the headers that are affected? But I'm not quite sure what effects that would have on your environment. > > I'm fine with this. > > > Why do you think people wouldn't be fond of the __FreeBSD_kernel__ being defined? > > See archived discussion: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2011-July/035721.html > > particularly this mail in which you participated: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2011-July/035823.html I recall the discussion from earlier. I can't recall if I had replied to it though. :-/ In my current opinion, I think it would be fine to define __FreeBSD_kernel__ on FreeBSD and to do it in for now until all the compilers we use have been updated to define it automatically (which may be a long time). I think it will also be fine to patch in-system headers to use __FreeBSD_kernel__ once is defined. Unfortunately headers in 3rd party software are going to have to check for both __FreeBSD__ and __FreeBSD_kernel__ to support both GNU/kFreeBSD and older FreeBSD for the foreseeable future. I think that is fine, but that the sooner we add __FreeBSD_kernel__ on FreeBSD the sooner we get the clock started for a day when those extra checks can go away. I would also be fine with MFC'ing the addition of __FreeBSD_kernel__ to older branches (at least 7 - 9) as well. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 15:16:19 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA9111065673; Thu, 17 Nov 2011 15:16:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A63FD8FC1A; Thu, 17 Nov 2011 15:16:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHFGI18058823; Thu, 17 Nov 2011 10:16:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHFGI8K058796; Thu, 17 Nov 2011 15:16:18 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 15:16:18 GMT Message-Id: <201111171516.pAHFGI8K058796@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 15:16:20 -0000 TB --- 2011-11-17 12:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 12:50:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-17 12:50:00 - cleaning the object tree TB --- 2011-11-17 12:50:28 - cvsupping the source tree TB --- 2011-11-17 12:50:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-17 12:50:57 - building world TB --- 2011-11-17 12:50:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 12:50:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 12:50:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 12:50:57 - SRCCONF=/dev/null TB --- 2011-11-17 12:50:57 - TARGET=pc98 TB --- 2011-11-17 12:50:57 - TARGET_ARCH=i386 TB --- 2011-11-17 12:50:57 - TZ=UTC TB --- 2011-11-17 12:50:57 - __MAKE_CONF=/dev/null TB --- 2011-11-17 12:50:57 - cd /src TB --- 2011-11-17 12:50:57 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 12:50:57 UTC 2011 >>> 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 Thu Nov 17 15:00:26 UTC 2011 TB --- 2011-11-17 15:00:27 - generating LINT kernel config TB --- 2011-11-17 15:00:27 - cd /src/sys/pc98/conf TB --- 2011-11-17 15:00:27 - /usr/bin/make -B LINT TB --- 2011-11-17 15:00:27 - cd /src/sys/pc98/conf TB --- 2011-11-17 15:00:27 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 15:00:27 - building GENERIC kernel TB --- 2011-11-17 15:00:27 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 15:00:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 15:00:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 15:00:27 - SRCCONF=/dev/null TB --- 2011-11-17 15:00:27 - TARGET=pc98 TB --- 2011-11-17 15:00:27 - TARGET_ARCH=i386 TB --- 2011-11-17 15:00:27 - TZ=UTC TB --- 2011-11-17 15:00:27 - __MAKE_CONF=/dev/null TB --- 2011-11-17 15:00:27 - cd /src TB --- 2011-11-17 15:00:27 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 15:00:27 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 15:16:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 15:16:18 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 15:16:18 - 7006.38 user 1243.28 system 8777.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 15:27:02 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAAB1106564A; Thu, 17 Nov 2011 15:27:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7516C8FC0C; Thu, 17 Nov 2011 15:27:01 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHFR0pF041679; Thu, 17 Nov 2011 10:27:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHFR09x041672; Thu, 17 Nov 2011 15:27:00 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 15:27:00 GMT Message-Id: <201111171527.pAHFR09x041672@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 15:27:02 -0000 TB --- 2011-11-17 12:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 12:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-17 12:50:00 - cleaning the object tree TB --- 2011-11-17 12:50:28 - cvsupping the source tree TB --- 2011-11-17 12:50:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-17 12:50:55 - building world TB --- 2011-11-17 12:50:55 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 12:50:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 12:50:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 12:50:55 - SRCCONF=/dev/null TB --- 2011-11-17 12:50:55 - TARGET=i386 TB --- 2011-11-17 12:50:55 - TARGET_ARCH=i386 TB --- 2011-11-17 12:50:55 - TZ=UTC TB --- 2011-11-17 12:50:55 - __MAKE_CONF=/dev/null TB --- 2011-11-17 12:50:55 - cd /src TB --- 2011-11-17 12:50:55 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 12:50:57 UTC 2011 >>> 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 Thu Nov 17 15:00:46 UTC 2011 TB --- 2011-11-17 15:00:46 - generating LINT kernel config TB --- 2011-11-17 15:00:46 - cd /src/sys/i386/conf TB --- 2011-11-17 15:00:46 - /usr/bin/make -B LINT TB --- 2011-11-17 15:00:47 - cd /src/sys/i386/conf TB --- 2011-11-17 15:00:47 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-17 15:00:47 - building LINT-NOINET kernel TB --- 2011-11-17 15:00:47 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 15:00:47 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 15:00:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 15:00:47 - SRCCONF=/dev/null TB --- 2011-11-17 15:00:47 - TARGET=i386 TB --- 2011-11-17 15:00:47 - TARGET_ARCH=i386 TB --- 2011-11-17 15:00:47 - TZ=UTC TB --- 2011-11-17 15:00:47 - __MAKE_CONF=/dev/null TB --- 2011-11-17 15:00:47 - cd /src TB --- 2011-11-17 15:00:47 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Nov 17 15:00:47 UTC 2011 >>> 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 [...] ld -Bshareable -d -warn-common -o if_sf.ko if_sf.kld objcopy --strip-debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT-NOINET/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/i386.i386/src/sys/LINT-NOINET -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT-NOINET/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/i386.i386/src/sys/LINT-NOINET -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 15:27:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 15:27:00 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-17 15:27:00 - 7566.49 user 1288.35 system 9419.92 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 16:09:18 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2110106567E; Thu, 17 Nov 2011 16:09:18 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 44B468FC1F; Thu, 17 Nov 2011 16:09:12 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so2966922bkb.13 for ; Thu, 17 Nov 2011 08:09:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WWMKWCCGaJmqJGB+ybwJuftI650Ir/+ihyrbRY1zI9s=; b=qd2u9mG5oy0vXz3hubO1hlJAWClZ5pXypUwzyC2vJJCweR3FCaUiMR1tYrF1BPHY0c gvhS0NqstC72J63pQ/35oO0w9tRKkqhnI/GpG0WqgdUrHl2kF/aRxVV72zAm1dSPkMGJ O+Vh4cRzYeL43r0i+GLIe9Q1wcVfzxLZu/V/g= Received: by 10.204.156.218 with SMTP id y26mr26223733bkw.103.1321546151121; Thu, 17 Nov 2011 08:09:11 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id i3sm2491894faf.0.2011.11.17.08.09.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 08:09:10 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC531A4.4000803@FreeBSD.org> Date: Thu, 17 Nov 2011 18:09:08 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Maksim Yevmenkin References: <4EC43ABA.7060407@FreeBSD.org> <4EC4404B.4070008@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: [RFC] ahci(4) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 16:09:19 -0000 On 11/17/11 01:08, Maksim Yevmenkin wrote: > On Wed, Nov 16, 2011 at 2:59 PM, Alexander Motin wrote: >> On 17.11.2011 00:44, Maksim Yevmenkin wrote: >>> >>> On Wed, Nov 16, 2011 at 2:35 PM, Alexander Motin wrote: >>>> >>>> On 16.11.2011 23:59, Maksim Yevmenkin wrote: >>>>> >>>>> would anyone object to the following ahci(4) patch? >>>>> >>>>> == >>>>> >>>>> --- ahci.c.orig 2011-11-16 21:35:26.000000000 +0000 >>>>> +++ ahci.c 2011-11-16 21:35:41.000000000 +0000 >>>>> @@ -500,7 +500,7 @@ >>>>> for (unit = 0; unit< ctlr->channels; unit++) { >>>>> if ((ctlr->ichannels& (1<< unit)) == 0) >>>>> continue; >>>>> - child = device_add_child(dev, "ahcich", -1); >>>>> + child = device_add_child(dev, "ahcich", unit); >>>>> if (child == NULL) >>>>> device_printf(dev, "failed to add channel >>>>> device\n"); >>>>> else >>>>> >>>>> == >>>>> >>>>> the idea is to have "static" numbering for ada(4) disks. >>>> >>>> I do. The only way I see this useful is if you have BIOS configured for >>>> non-hot-swappable disks, in which case you have some AHCI channels >>>> disabled, >>>> but want to keep numbers of the rest. While I don't like this mode in >>>> general, especially when it can't be disabled, that patch could be useful >>>> in >>>> these cases. But in other cases, when you have several AHCI controllers, >>>> it >>>> just wont not work. You will receive error on attempt to create second >>>> ahcich0. >>> >>> shouldn't achcichX be destroyed when disk is detached/removed/etc.? >> >> List of implemented AHCI channels to expose as ahcichX set by BIOS in >> vendor-specific way, but only during boot and not by many BIOSes. Destroying >> them on disk detach theoretically possible, but IMHO not right, as bus >> doesn't disappear on disk disconnect. >> >>> the particular problem i'm trying to address is disk re-numbering when >>> one of the disks fails/removed/etc. i'm trying to use hints to wire >>> disks to controllers/busses. it works perfectly fine with da(4) disks >>> (even hot swappable ones) , but i can not make it to work with ada(4) >>> disks. i'm perfectly fine to hid this under some sort of option >>> (something similar to ATA_STATIC_ID, AHCI_STATIC_ID for example) >> >> Wiring works for adaX also, unless your BIOS is so "intelligent" to report >> unconnected ports and not impliemented.. You should just wire CAM buses to >> ahcichX, not to ahciX. It could be done in other way changing just by one >> line around xpt_bus_register(), but now it is done so. > > ok. then i must be missing something, here is what i have in device.hints > > hint.scbus.0.at="umass-sim0" > hint.scbus.1.at="ahcich0" > hint.scbus.2.at="ahcich1" > hint.scbus.3.at="ahcich2" > hint.scbus.4.at="ahcich3" > hint.scbus.5.at="ahcich4" > hint.scbus.6.at="ahcich5" > > hint.da.0.at="scbus0" > hint.ada.0.at="scbus1" > hint.ada.1.at="scbus2" > hint.ada.2.at="scbus3" > hint.ada.3.at="scbus4" > hint.ada.4.at="scbus5" > hint.ada.5.at="scbus6" > > this is for 6-port ahci(4) compatible controller (intel) on the > motherboard. no matter which achi(4) ports are connected, resulted > adaX devices are always sequential starting from ada0. so, the > question is: what am i doing wrong here? Just put your lines into my loader.conf and got this: %camcontrol devlist -v scbus1 on ahcich0 bus 0: at scbus1 target 0 lun 0 (pass0,ada0) <> at scbus1 target -1 lun -1 () scbus2 on ahcich1 bus 0: <> at scbus2 target -1 lun -1 () scbus3 on ahcich2 bus 0: at scbus3 target 0 lun 0 (pass1,ada2) <> at scbus3 target -1 lun -1 () scbus4 on ahcich3 bus 0: <> at scbus4 target -1 lun -1 () scbus5 on ahcich4 bus 0: <> at scbus5 target -1 lun -1 () scbus6 on ahcich5 bus 0: <> at scbus6 target -1 lun -1 () ... I see no problem. What am I doing wrong? Let me repeat question not asked directly: Does your BIOS reports unused AHCI channels as implemented? Do you always have all 6 ahcich devices or not? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 16:23:48 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9492106564A; Thu, 17 Nov 2011 16:23:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9441F8FC08; Thu, 17 Nov 2011 16:23:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHGNlWE025638; Thu, 17 Nov 2011 11:23:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHGNlSG025637; Thu, 17 Nov 2011 16:23:47 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 16:23:47 GMT Message-Id: <201111171623.pAHGNlSG025637@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 16:23:48 -0000 TB --- 2011-11-17 14:35:10 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 14:35:10 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-17 14:35:10 - cleaning the object tree TB --- 2011-11-17 14:35:23 - cvsupping the source tree TB --- 2011-11-17 14:35:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-17 14:35:35 - building world TB --- 2011-11-17 14:35:35 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 14:35:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 14:35:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 14:35:35 - SRCCONF=/dev/null TB --- 2011-11-17 14:35:35 - TARGET=ia64 TB --- 2011-11-17 14:35:35 - TARGET_ARCH=ia64 TB --- 2011-11-17 14:35:35 - TZ=UTC TB --- 2011-11-17 14:35:35 - __MAKE_CONF=/dev/null TB --- 2011-11-17 14:35:35 - cd /src TB --- 2011-11-17 14:35:35 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 14:35:35 UTC 2011 >>> 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 Thu Nov 17 16:04:13 UTC 2011 TB --- 2011-11-17 16:04:14 - generating LINT kernel config TB --- 2011-11-17 16:04:14 - cd /src/sys/ia64/conf TB --- 2011-11-17 16:04:14 - /usr/bin/make -B LINT TB --- 2011-11-17 16:04:14 - cd /src/sys/ia64/conf TB --- 2011-11-17 16:04:14 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 16:04:14 - building GENERIC kernel TB --- 2011-11-17 16:04:14 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 16:04:14 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 16:04:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 16:04:14 - SRCCONF=/dev/null TB --- 2011-11-17 16:04:14 - TARGET=ia64 TB --- 2011-11-17 16:04:14 - TARGET_ARCH=ia64 TB --- 2011-11-17 16:04:14 - TZ=UTC TB --- 2011-11-17 16:04:14 - __MAKE_CONF=/dev/null TB --- 2011-11-17 16:04:14 - cd /src TB --- 2011-11-17 16:04:14 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 16:04:14 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 16:23:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 16:23:47 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 16:23:47 - 5175.51 user 961.45 system 6516.25 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 16:33:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE2E7106564A; Thu, 17 Nov 2011 16:33:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 925EC8FC0A; Thu, 17 Nov 2011 16:33:35 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4535946B0C; Thu, 17 Nov 2011 11:33:35 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D459A8A050; Thu, 17 Nov 2011 11:33:34 -0500 (EST) From: John Baldwin To: Stefan Esser Date: Thu, 17 Nov 2011 11:33:34 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <4EBB885E.9060908@freebsd.org> <201111161116.24855.jhb@freebsd.org> <4EC4CCFF.8040704@freebsd.org> In-Reply-To: <4EC4CCFF.8040704@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201111171133.34108.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 17 Nov 2011 11:33:34 -0500 (EST) Cc: Attilio Rao , freebsd-current@freebsd.org Subject: Re: [amd64] Reproducible cold boot failure (reboot succeeds) in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 16:33:35 -0000 On Thursday, November 17, 2011 3:59:43 am Stefan Esser wrote: > Am 16.11.2011 17:16, schrieb John Baldwin: > > On Sunday, November 13, 2011 12:56:12 pm Stefan Esser wrote: > >> ... > >> WARNING: WITNESS option enabled, expect reduced performance. > >> Table 'FACP' at 0xba918a58 > >> Table 'APIC' at 0xba918b50 > >> Table 'SSDT' at 0xba918be8 > >> Table 'MCFG' at 0xba918dc0 > >> Table 'HPET' at 0xba918e00 > >> ACPI: No SRAT table found > >> Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81109000 > >> Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff81109370 <-- > >> kldload: unexpected relocation type 67108875 > >> kernel trap 12 with interrupts disabled > >> > >> The irritating detail is the load address of "zfs.ko", which is just > >> 0x370 bytes above the kernel load address ... > > > > That isn't unusual. Those are the addresses of the metadata provided by the > > loader, not the base address of the kernel or zfs.ko object themselves. The > > unexpected relocation type is interesting however. That value in hex is > > 0x400000b. 0xb is the R_X86_64_32S relocation type which is normal for the > > kernel. I think you just have a single-bit memory error due to a failing > > DIMM. > > Thanks for the information about the load address semantics. The other > unexpected relocation type I observed was 268435457 == 0x10000001, which > also hints at a single bit error. But today the system failed with a > different error: > > ath0: ... > ioapic0: routing interrupt 18 to ... > panic: vm_page_insert: page already inserted > > This could of course also be caused by a single bit error ... Yes, very likely. > Hmmm, perhaps there is a problem with components at room temperature > and the system is still significantly warmer after 3 hours? Yes, I strongly suspect it is a thermal effect that the RAM "works" once it is warmed up. If you have data you care about on the machine, I would just go ahead and replace the RAM now before waiting for the RAM's failure to become worse. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 16:35:26 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 110961065670; Thu, 17 Nov 2011 16:35:26 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 477DB8FC12; Thu, 17 Nov 2011 16:35:22 +0000 (UTC) Received: by ggnk5 with SMTP id k5so1363752ggn.13 for ; Thu, 17 Nov 2011 08:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1HNt/biO0zSF+hFHG2Ktaq3529bkIlagJe3yV+8xPXs=; b=bwdwu/KdIK7wQZXM6e5FZQ9dKu1wnSOdQUYMK7KyaVmZhRlvYtpSQQyRz99BCDoHRh 5yP9crqhpBuSSGULo+WSw823yeNxTGp6iF8r2GTsYBY5qTJWE+/I7JgqYQfEMaqp0pCX n0D+DaMRXabY8M2kMU+ydrDZ/Gfa8X/k6zqG8= MIME-Version: 1.0 Received: by 10.236.161.4 with SMTP id v4mr10776228yhk.89.1321547721677; Thu, 17 Nov 2011 08:35:21 -0800 (PST) Sender: maksim.yevmenkin@gmail.com Received: by 10.100.122.19 with HTTP; Thu, 17 Nov 2011 08:35:21 -0800 (PST) In-Reply-To: <4EC531A4.4000803@FreeBSD.org> References: <4EC43ABA.7060407@FreeBSD.org> <4EC4404B.4070008@FreeBSD.org> <4EC531A4.4000803@FreeBSD.org> Date: Thu, 17 Nov 2011 08:35:21 -0800 X-Google-Sender-Auth: 3pgzlbvfu2fbONJOsWtOD97D83Q Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: [RFC] ahci(4) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 16:35:26 -0000 On Thu, Nov 17, 2011 at 8:09 AM, Alexander Motin wrote: > On 11/17/11 01:08, Maksim Yevmenkin wrote: >> On Wed, Nov 16, 2011 at 2:59 PM, Alexander Motin wrote= : >>> On 17.11.2011 00:44, Maksim Yevmenkin wrote: >>>> >>>> On Wed, Nov 16, 2011 at 2:35 PM, Alexander Motin =A0w= rote: >>>>> >>>>> On 16.11.2011 23:59, Maksim Yevmenkin wrote: >>>>>> >>>>>> would anyone object to the following ahci(4) patch? >>>>>> >>>>>> =3D=3D >>>>>> >>>>>> --- ahci.c.orig 2011-11-16 21:35:26.000000000 +0000 >>>>>> +++ ahci.c =A0 =A0 =A02011-11-16 21:35:41.000000000 +0000 >>>>>> @@ -500,7 +500,7 @@ >>>>>> =A0 =A0 =A0 =A0for (unit =3D 0; unit< =A0 =A0ctlr->channels; unit++)= { >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ((ctlr->ichannels& =A0 =A0(1<< =A0= =A0unit)) =3D=3D 0) >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; >>>>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 child =3D device_add_child(dev, "ahcic= h", -1); >>>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 child =3D device_add_child(dev, "ahcic= h", unit); >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (child =3D=3D NULL) >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_printf(dev, "f= ailed to add channel >>>>>> device\n"); >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else >>>>>> >>>>>> =3D=3D >>>>>> >>>>>> the idea is to have "static" numbering for ada(4) disks. >>>>> >>>>> I do. The only way I see this useful is if you have BIOS configured f= or >>>>> non-hot-swappable disks, in which case you have some AHCI channels >>>>> disabled, >>>>> but want to keep numbers of the rest. While I don't like this mode in >>>>> general, especially when it can't be disabled, that patch could be us= eful >>>>> in >>>>> these cases. But in other cases, when you have several AHCI controlle= rs, >>>>> it >>>>> just wont not work. You will receive error on attempt to create secon= d >>>>> ahcich0. >>>> >>>> shouldn't achcichX be destroyed when disk is detached/removed/etc.? >>> >>> List of implemented AHCI channels to expose as ahcichX set by BIOS in >>> vendor-specific way, but only during boot and not by many BIOSes. Destr= oying >>> them on disk detach theoretically possible, but IMHO not right, as bus >>> doesn't disappear on disk disconnect. >>> >>>> the particular problem i'm trying to address is disk re-numbering when >>>> one of the disks fails/removed/etc. i'm trying to use hints to wire >>>> disks to controllers/busses. it works perfectly fine with da(4) disks >>>> (even hot swappable ones) , but i can not make it to work with ada(4) >>>> disks. i'm perfectly fine to hid this under some sort of option >>>> (something similar to ATA_STATIC_ID, AHCI_STATIC_ID for example) >>> >>> Wiring works for adaX also, unless your BIOS is so "intelligent" to rep= ort >>> unconnected ports and not impliemented.. You should just wire CAM buses= to >>> ahcichX, not to ahciX. It could be done in other way changing just by o= ne >>> line around xpt_bus_register(), but now it is done so. >> >> ok. then i must be missing something, here is what i have in device.hint= s >> >> hint.scbus.0.at=3D"umass-sim0" >> hint.scbus.1.at=3D"ahcich0" >> hint.scbus.2.at=3D"ahcich1" >> hint.scbus.3.at=3D"ahcich2" >> hint.scbus.4.at=3D"ahcich3" >> hint.scbus.5.at=3D"ahcich4" >> hint.scbus.6.at=3D"ahcich5" >> >> hint.da.0.at=3D"scbus0" >> hint.ada.0.at=3D"scbus1" >> hint.ada.1.at=3D"scbus2" >> hint.ada.2.at=3D"scbus3" >> hint.ada.3.at=3D"scbus4" >> hint.ada.4.at=3D"scbus5" >> hint.ada.5.at=3D"scbus6" >> >> this is for 6-port ahci(4) compatible controller (intel) on the >> motherboard. no matter which achi(4) ports are connected, resulted >> adaX devices are always sequential starting from ada0. so, the >> question is: what am i doing wrong here? > > Just put your lines into my loader.conf and got this: > > %camcontrol devlist -v > scbus1 on ahcich0 bus 0: > =A0 =A0at scbus1 target 0 lun 0 (pass0,ad= a0) > <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at scb= us1 target -1 lun -1 () > scbus2 on ahcich1 bus 0: > <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at scb= us2 target -1 lun -1 () > scbus3 on ahcich2 bus 0: > =A0 =A0at scbus3 target 0 lun 0 (pass1,ad= a2) > <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at scb= us3 target -1 lun -1 () > scbus4 on ahcich3 bus 0: > <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at scb= us4 target -1 lun -1 () > scbus5 on ahcich4 bus 0: > <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at scb= us5 target -1 lun -1 () > scbus6 on ahcich5 bus 0: > <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at scb= us6 target -1 lun -1 () > ... > > I see no problem. What am I doing wrong? > > Let me repeat question not asked directly: Does your BIOS reports unused > AHCI channels as implemented? Do you always have all 6 ahcich devices or > not? i not exactly sure. below is the relevant dmesg. as far as i can tell, channels are correct, however, ahcich numbering is sequential and that is why hints dont work. Nov 16 11:18:00 PREPROD-red1 kernel: ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f mem 0xfbb21000-0xfbb217ff irq 19 at device 31.2 on pci0 Nov 16 11:18:00 PREPROD-red1 kernel: ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported Nov 16 11:18:00 PREPROD-red1 kernel: ahcich0: at channel 0 on ahci0 Nov 16 11:18:00 PREPROD-red1 kernel: ada0 at ahcich0 bus 0 scbus1 target 0 = lun 0 Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f mem 0xfbb21000-0xfbb217ff irq 19 at device 31.2 on pci0 Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: attempting to allocate 1 MSI vectors (1 supported) Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: using IRQ 270 for MSI Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: Caps: 64bit NCQ SNTF AL CLO 6Gbps PMD SSC PSC 32cmd EM 6ports Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: Caps2: APST Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: EM Caps: ALHD XMT SMB LED Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: at channel 0 on ahci0 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: Caps: Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: at channel 2 on ahci0 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: Caps: Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: at channel 5 on ahci0 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: Caps: Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: AHCI reset... Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: SATA connect time=3D100us status=3D00000133 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: AHCI reset: device found Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: AHCI reset: device ready afte= r 0ms Nov 17 09:22:51 PREPROD-red1 kernel: (aprobe0:ahcich0:0:0:0): SIGNATURE: 00= 00 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: AHCI reset... Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: SATA connect time=3D100us status=3D00000123 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: AHCI reset: device found Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: AHCI reset: device ready afte= r 0ms Nov 17 09:22:51 PREPROD-red1 kernel: (aprobe0:ahcich1:0:0:0): SIGNATURE: 00= 00 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: AHCI reset... Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: SATA connect time=3D100us status=3D00000123 Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: AHCI reset: device found Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: AHCI reset: device ready afte= r 0ms Nov 17 09:22:51 PREPROD-red1 kernel: (aprobe0:ahcich2:0:0:0): SIGNATURE: 00= 00 Nov 17 09:22:51 PREPROD-red1 kernel: ada0 at ahcich0 bus 0 scbus1 target 0 = lun 0 Nov 17 09:22:51 PREPROD-red1 kernel: ada1 at ahcich1 bus 0 scbus2 target 0 = lun 0 Nov 17 09:22:51 PREPROD-red1 kernel: ada2 at ahcich2 bus 0 scbus3 target 0 = lun 0 Nov 17 09:22:51 PREPROD-red1 kernel: pass0 at ahcich0 bus 0 scbus1 target 0 lun 0 Nov 17 09:22:51 PREPROD-red1 kernel: pass1 at ahcich1 bus 0 scbus2 target 0 lun 0 Nov 17 09:22:51 PREPROD-red1 kernel: pass2 at ahcich2 bus 0 scbus3 target 0 lun 0 thanks, max From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 16:37:20 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11833106567A; Thu, 17 Nov 2011 16:37:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DC9758FC0A; Thu, 17 Nov 2011 16:37:19 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 93CD346B17; Thu, 17 Nov 2011 11:37:19 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 25C0C8A050; Thu, 17 Nov 2011 11:37:19 -0500 (EST) From: John Baldwin To: Andriy Gapon Date: Thu, 17 Nov 2011 11:37:18 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <4EC4C712.8040701@FreeBSD.org> <4EC4D83E.3090307@FreeBSD.org> In-Reply-To: <4EC4D83E.3090307@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111171137.18663.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 17 Nov 2011 11:37:19 -0500 (EST) Cc: Kostik Belousov , Alexander Motin , freebsd-current@freebsd.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 16:37:20 -0000 On Thursday, November 17, 2011 4:47:42 am Andriy Gapon wrote: > on 17/11/2011 10:34 Andriy Gapon said the following: > > on 17/11/2011 10:15 Kostik Belousov said the following: > >> I have the following change for eons on my test boxes. Without it, > >> I simply cannot get _any_ dump. > >> > >> diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c > >> index 10b89c7..a38e42f 100644 > >> --- a/sys/cam/cam_xpt.c > >> +++ b/sys/cam/cam_xpt.c > >> @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) > >> TAILQ_INSERT_TAIL(&cam_simq, sim, links); > >> mtx_unlock(&cam_simq_lock); > >> sim->flags |= CAM_SIM_ON_DONEQ; > >> - if (first) > >> + if (first && panicstr == NULL) > >> swi_sched(cambio_ih, 0); > >> } > >> } > > > > I think that this (or similar) change should go into the patch and the tree. > > > > And, BTW, I still would like to do something like the following (perhaps with > td_oncpu = NOCPU and td_flags &= ~TDF_NEEDRESCHED also moved to the common code): > > Index: sys/kern/sched_ule.c > =================================================================== > --- sys/kern/sched_ule.c (revision 227608) > +++ sys/kern/sched_ule.c (working copy) > @@ -1790,7 +1790,6 @@ sched_switch(struct thread *td, struct thread *new > td->td_oncpu = NOCPU; > if (!(flags & SW_PREEMPT)) > td->td_flags &= ~TDF_NEEDRESCHED; > - td->td_owepreempt = 0; > tdq->tdq_switchcnt++; > /* > * The lock pointer in an idle thread should never change. Reset it > Index: sys/kern/kern_synch.c > =================================================================== > --- sys/kern/kern_synch.c (revision 227608) > +++ sys/kern/kern_synch.c (working copy) > @@ -406,6 +406,8 @@ mi_switch(int flags, struct thread *newtd) > ("mi_switch: switch must be voluntary or involuntary")); > KASSERT(newtd != curthread, ("mi_switch: preempting back to ourself")); > > + td->td_owepreempt = 0; > + > /* > * Don't perform context switches from the debugger. > */ > Index: sys/kern/sched_4bsd.c > =================================================================== > --- sys/kern/sched_4bsd.c (revision 227608) > +++ sys/kern/sched_4bsd.c (working copy) > @@ -940,7 +940,6 @@ sched_switch(struct thread *td, struct thread *new > td->td_lastcpu = td->td_oncpu; > if (!(flags & SW_PREEMPT)) > td->td_flags &= ~TDF_NEEDRESCHED; > - td->td_owepreempt = 0; > td->td_oncpu = NOCPU; > > /* > > Does anybody see any potential problems with such a change? Hmm, does this mean the preemption will be lost if you break into the debugger and continue in the non-panic case? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 16:58:12 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1097106564A; Thu, 17 Nov 2011 16:58:12 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A4E8E8FC0A; Thu, 17 Nov 2011 16:58:06 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA20814; Thu, 17 Nov 2011 18:58:04 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4EC53D1B.4000308@FreeBSD.org> Date: Thu, 17 Nov 2011 18:58:03 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Baldwin References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <4EC4C712.8040701@FreeBSD.org> <4EC4D83E.3090307@FreeBSD.org> <201111171137.18663.jhb@freebsd.org> In-Reply-To: <201111171137.18663.jhb@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Alexander Motin , freebsd-current@FreeBSD.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 16:58:12 -0000 on 17/11/2011 18:37 John Baldwin said the following: > On Thursday, November 17, 2011 4:47:42 am Andriy Gapon wrote: >> on 17/11/2011 10:34 Andriy Gapon said the following: >>> on 17/11/2011 10:15 Kostik Belousov said the following: >>>> I have the following change for eons on my test boxes. Without it, >>>> I simply cannot get _any_ dump. >>>> >>>> diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c >>>> index 10b89c7..a38e42f 100644 >>>> --- a/sys/cam/cam_xpt.c >>>> +++ b/sys/cam/cam_xpt.c >>>> @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) >>>> TAILQ_INSERT_TAIL(&cam_simq, sim, links); >>>> mtx_unlock(&cam_simq_lock); >>>> sim->flags |= CAM_SIM_ON_DONEQ; >>>> - if (first) >>>> + if (first && panicstr == NULL) >>>> swi_sched(cambio_ih, 0); >>>> } >>>> } >>> >>> I think that this (or similar) change should go into the patch and the tree. >>> >> >> And, BTW, I still would like to do something like the following (perhaps with >> td_oncpu = NOCPU and td_flags &= ~TDF_NEEDRESCHED also moved to the common code): >> >> Index: sys/kern/sched_ule.c >> =================================================================== >> --- sys/kern/sched_ule.c (revision 227608) >> +++ sys/kern/sched_ule.c (working copy) >> @@ -1790,7 +1790,6 @@ sched_switch(struct thread *td, struct thread *new >> td->td_oncpu = NOCPU; >> if (!(flags & SW_PREEMPT)) >> td->td_flags &= ~TDF_NEEDRESCHED; >> - td->td_owepreempt = 0; >> tdq->tdq_switchcnt++; >> /* >> * The lock pointer in an idle thread should never change. Reset it >> Index: sys/kern/kern_synch.c >> =================================================================== >> --- sys/kern/kern_synch.c (revision 227608) >> +++ sys/kern/kern_synch.c (working copy) >> @@ -406,6 +406,8 @@ mi_switch(int flags, struct thread *newtd) >> ("mi_switch: switch must be voluntary or involuntary")); >> KASSERT(newtd != curthread, ("mi_switch: preempting back to ourself")); >> >> + td->td_owepreempt = 0; >> + >> /* >> * Don't perform context switches from the debugger. >> */ >> Index: sys/kern/sched_4bsd.c >> =================================================================== >> --- sys/kern/sched_4bsd.c (revision 227608) >> +++ sys/kern/sched_4bsd.c (working copy) >> @@ -940,7 +940,6 @@ sched_switch(struct thread *td, struct thread *new >> td->td_lastcpu = td->td_oncpu; >> if (!(flags & SW_PREEMPT)) >> td->td_flags &= ~TDF_NEEDRESCHED; >> - td->td_owepreempt = 0; >> td->td_oncpu = NOCPU; >> >> /* >> >> Does anybody see any potential problems with such a change? > > Hmm, does this mean the preemption will be lost if you break into the > debugger and continue in the non-panic case? Not sure which exact scenario you have in mind. Please note that the above diff just moves resetting of td_owepreempt to an earlier place. As far as I can see there are no checks of td_owepreempt value between the new place and the old places. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 17:02:43 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 409BE106566B; Thu, 17 Nov 2011 17:02:43 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 82C718FC13; Thu, 17 Nov 2011 17:02:36 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so3064083bkb.13 for ; Thu, 17 Nov 2011 09:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=IOaG2kelgtqeAGH5yxlyYYZXDuD6gAkUQLIP60xh3S8=; b=EVee+wC7fVvWn4tJZRlcwPqR6HW+j4UjvcL4A3moiepWhFJcy4tV9WDla/A9gZoUzI 5nVbZXuxM+Ab733+1m8913Qr5U8aigv6e/j8LSiv8Pu/czXNB5jq7PPpopAP2hUotmSZ G3I9w6nQgrFkIsXiklghIg3L7neOcG5Pw6+pE= Received: by 10.204.155.141 with SMTP id s13mr34443578bkw.40.1321549355961; Thu, 17 Nov 2011 09:02:35 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id z3sm2598594faf.13.2011.11.17.09.02.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 09:02:35 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC53E28.2030609@FreeBSD.org> Date: Thu, 17 Nov 2011 19:02:32 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Maksim Yevmenkin References: <4EC43ABA.7060407@FreeBSD.org> <4EC4404B.4070008@FreeBSD.org> <4EC531A4.4000803@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: [RFC] ahci(4) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 17:02:43 -0000 On 11/17/11 18:35, Maksim Yevmenkin wrote: > On Thu, Nov 17, 2011 at 8:09 AM, Alexander Motin wrote: >> On 11/17/11 01:08, Maksim Yevmenkin wrote: >>> On Wed, Nov 16, 2011 at 2:59 PM, Alexander Motin wrote: >>>> On 17.11.2011 00:44, Maksim Yevmenkin wrote: >>>>> >>>>> On Wed, Nov 16, 2011 at 2:35 PM, Alexander Motin wrote: >>>>>> >>>>>> On 16.11.2011 23:59, Maksim Yevmenkin wrote: >>>>>>> >>>>>>> would anyone object to the following ahci(4) patch? >>>>>>> >>>>>>> == >>>>>>> >>>>>>> --- ahci.c.orig 2011-11-16 21:35:26.000000000 +0000 >>>>>>> +++ ahci.c 2011-11-16 21:35:41.000000000 +0000 >>>>>>> @@ -500,7 +500,7 @@ >>>>>>> for (unit = 0; unit< ctlr->channels; unit++) { >>>>>>> if ((ctlr->ichannels& (1<< unit)) == 0) >>>>>>> continue; >>>>>>> - child = device_add_child(dev, "ahcich", -1); >>>>>>> + child = device_add_child(dev, "ahcich", unit); >>>>>>> if (child == NULL) >>>>>>> device_printf(dev, "failed to add channel >>>>>>> device\n"); >>>>>>> else >>>>>>> >>>>>>> == >>>>>>> >>>>>>> the idea is to have "static" numbering for ada(4) disks. >>>>>> >>>>>> I do. The only way I see this useful is if you have BIOS configured for >>>>>> non-hot-swappable disks, in which case you have some AHCI channels >>>>>> disabled, >>>>>> but want to keep numbers of the rest. While I don't like this mode in >>>>>> general, especially when it can't be disabled, that patch could be useful >>>>>> in >>>>>> these cases. But in other cases, when you have several AHCI controllers, >>>>>> it >>>>>> just wont not work. You will receive error on attempt to create second >>>>>> ahcich0. >>>>> >>>>> shouldn't achcichX be destroyed when disk is detached/removed/etc.? >>>> >>>> List of implemented AHCI channels to expose as ahcichX set by BIOS in >>>> vendor-specific way, but only during boot and not by many BIOSes. Destroying >>>> them on disk detach theoretically possible, but IMHO not right, as bus >>>> doesn't disappear on disk disconnect. >>>> >>>>> the particular problem i'm trying to address is disk re-numbering when >>>>> one of the disks fails/removed/etc. i'm trying to use hints to wire >>>>> disks to controllers/busses. it works perfectly fine with da(4) disks >>>>> (even hot swappable ones) , but i can not make it to work with ada(4) >>>>> disks. i'm perfectly fine to hid this under some sort of option >>>>> (something similar to ATA_STATIC_ID, AHCI_STATIC_ID for example) >>>> >>>> Wiring works for adaX also, unless your BIOS is so "intelligent" to report >>>> unconnected ports and not impliemented.. You should just wire CAM buses to >>>> ahcichX, not to ahciX. It could be done in other way changing just by one >>>> line around xpt_bus_register(), but now it is done so. >>> >>> ok. then i must be missing something, here is what i have in device.hints >>> >>> hint.scbus.0.at="umass-sim0" >>> hint.scbus.1.at="ahcich0" >>> hint.scbus.2.at="ahcich1" >>> hint.scbus.3.at="ahcich2" >>> hint.scbus.4.at="ahcich3" >>> hint.scbus.5.at="ahcich4" >>> hint.scbus.6.at="ahcich5" >>> >>> hint.da.0.at="scbus0" >>> hint.ada.0.at="scbus1" >>> hint.ada.1.at="scbus2" >>> hint.ada.2.at="scbus3" >>> hint.ada.3.at="scbus4" >>> hint.ada.4.at="scbus5" >>> hint.ada.5.at="scbus6" >>> >>> this is for 6-port ahci(4) compatible controller (intel) on the >>> motherboard. no matter which achi(4) ports are connected, resulted >>> adaX devices are always sequential starting from ada0. so, the >>> question is: what am i doing wrong here? >> >> Just put your lines into my loader.conf and got this: >> >> %camcontrol devlist -v >> scbus1 on ahcich0 bus 0: >> at scbus1 target 0 lun 0 (pass0,ada0) >> <> at scbus1 target -1 lun -1 () >> scbus2 on ahcich1 bus 0: >> <> at scbus2 target -1 lun -1 () >> scbus3 on ahcich2 bus 0: >> at scbus3 target 0 lun 0 (pass1,ada2) >> <> at scbus3 target -1 lun -1 () >> scbus4 on ahcich3 bus 0: >> <> at scbus4 target -1 lun -1 () >> scbus5 on ahcich4 bus 0: >> <> at scbus5 target -1 lun -1 () >> scbus6 on ahcich5 bus 0: >> <> at scbus6 target -1 lun -1 () >> ... >> >> I see no problem. What am I doing wrong? >> >> Let me repeat question not asked directly: Does your BIOS reports unused >> AHCI channels as implemented? Do you always have all 6 ahcich devices or >> not? > > i not exactly sure. below is the relevant dmesg. as far as i can tell, > channels are correct, however, ahcich numbering is sequential and that > is why hints dont work. > > Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: SATA controller> port > 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f > mem 0xfbb21000-0xfbb217ff irq 19 at device 31.2 on pci0 > Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: attempting to allocate 1 > MSI vectors (1 supported) > Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: using IRQ 270 for MSI > Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: AHCI v1.30 with 6 6Gbps > ports, Port Multiplier not supported > Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: Caps: 64bit NCQ SNTF AL > CLO 6Gbps PMD SSC PSC 32cmd EM 6ports > Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: Caps2: APST > Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: EM Caps: ALHD XMT SMB LED > Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: at > channel 0 on ahci0 > Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: Caps: > Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: at > channel 2 on ahci0 > Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: Caps: > Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: at > channel 5 on ahci0 > Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: Caps: Yes, that's it. You should have six ahcichX devices, but have only three - only for connected devices. Some vendors (Supermicro was first I've heard about) last time randomly started to make BIOS mark unused AHCI channels as unimplemented. Sometimes it can be configured in BIOS setup (it may be called like "hot-swappable"), sometimes not. I believe that is wrong AHCI spec interpretation. If it is not configurable in BIOS, we could add respective hint to the ahci(4) to allow user ignore these fake "implemented" flags to always present all possible ports, but it is direct AHCI spec violation. Other possible way is to leave ahcichX device as-is, but instead register ports in CAM in different fashion -- as buses of the same controller. Patch may look like this: --- ahci.c (revision 227580) +++ ahci.c (working copy) @@ -985,8 +985,8 @@ goto err1; } /* Construct SIM entry */ - ch->sim = cam_sim_alloc(ahciaction, ahcipoll, "ahcich", ch, - device_get_unit(dev), &ch->mtx, + ch->sim = cam_sim_alloc(ahciaction, ahcipoll, "ahci", ch, + device_get_unit(device_get_parent(dev)), &ch->mtx, min(2, ch->numslots), (ch->caps & AHCI_CAP_SNCQ) ? ch->numslots : 0, devq); @@ -996,7 +996,7 @@ error = ENOMEM; goto err1; } - if (xpt_bus_register(ch->sim, dev, 0) != CAM_SUCCESS) { + if (xpt_bus_register(ch->sim, dev, ch->unit) != CAM_SUCCESS) { device_printf(dev, "unable to register xpt bus\n"); error = ENXIO; goto err2; Then output looks that way: %camcontrol devlist -v scbus1 on ahci0 bus 0: at scbus1 target 0 lun 0 (pass0,ada0) <> at scbus1 target -1 lun -1 () scbus2 on ahci0 bus 1: <> at scbus2 target -1 lun -1 () scbus3 on ahci0 bus 2: at scbus3 target 0 lun 0 (pass1,ada2) <> at scbus3 target -1 lun -1 () scbus4 on ahci0 bus 3: <> at scbus4 target -1 lun -1 () scbus5 on ahci0 bus 4: <> at scbus5 target -1 lun -1 () scbus6 on ahci0 bus 5: <> at scbus6 target -1 lun -1 () But in that case two problems remain: - per-port device hints still won't be usable, while changing them will break POLA; - it will also break POLA for users who are using wiring now. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 17:16:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C205D106566B for ; Thu, 17 Nov 2011 17:16:21 +0000 (UTC) (envelope-from nmisaghian@sandvine.com) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 4BE468FC16 for ; Thu, 17 Nov 2011 17:16:21 +0000 (UTC) Received: from WTL-EXCH-2.sandvine.com ([fe80::8959:ede3:2dbe:c1b]) by wtl-exch-1.sandvine.com ([fe80::f523:8e57:71d7:5206%14]) with mapi; Thu, 17 Nov 2011 12:16:20 -0500 From: Nima Misaghian To: Craig Rodrigues Thread-Topic: Adding disk firmware programming capability to camcontrol Thread-Index: AQHMlbRrwKeoBWVw4EqGdjjn5vvJXpWcRDYAgBUlc/A= Date: Thu, 17 Nov 2011 17:16:21 +0000 Message-ID: <0A3573FC36A1BE41AAA3DFF287C7968405688A@wtl-exch-2.sandvine.com> References: <20111028204706.GA57454@sandvine.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/mixed; boundary="_002_0A3573FC36A1BE41AAA3DFF287C7968405688Awtlexch2sandvinec_" MIME-Version: 1.0 Cc: "freebsd-current@freebsd.org" Subject: RE: Adding disk firmware programming capability to camcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 17:16:21 -0000 --_002_0A3573FC36A1BE41AAA3DFF287C7968405688Awtlexch2sandvinec_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have updated the patch according to feedbacks I received. The main modifi= cation was to warn the user and ask for confirmation before downloading a f= irmware image. A -y option has been added that suppresses the confirmation-= - the same as the one for the format command. The new patch is against HEAD and could be downloaded from: http://people.freebsd.org/~emaste/patches/fwdownload.diff Reviews/suggestions are greatly appreciated. Nima Misaghian=20 nmisaghian@sandvine.com > -----Original Message----- > From: crodr001@gmail.com [mailto:crodr001@gmail.com] On Behalf Of Craig > Rodrigues > Sent: Thursday, November 03, 2011 10:06 PM > To: Nima Misaghian > Cc: freebsd-current@freebsd.org > Subject: Re: Adding disk firmware programming capability to camcontrol >=20 > On Fri, Oct 28, 2011 at 1:47 PM, Nima Misaghian > wrote: > > Hi, > > > > I have got code developed by Andre Albsmeier that is capable of > > programming firmware of hard drives from several vendors and =A0turned > > it into a camcontrol command. >=20 > +1 >=20 > I took a look at your patch and it looks great. I have worked on a > storage product before where there > was a requirement to reprogram the firmware of hard drives. On tha > product, > proprietary Windows tools had to be used. It would have been nice to > be able to use camcontrol in FreeBSD. >=20 > I think the patch is fine in its current form. Very few "regular > users" need to reprogram hard drive firmware. > It is a special administrative operation. >=20 > -- > Craig Rodrigues > rodrigc@crodrigues.org --_002_0A3573FC36A1BE41AAA3DFF287C7968405688Awtlexch2sandvinec_ Content-Type: application/octet-stream; name="fwdownload.diff" Content-Description: fwdownload.diff Content-Disposition: attachment; filename="fwdownload.diff"; size=18521; creation-date="Thu, 17 Nov 2011 17:11:41 GMT"; modification-date="Thu, 17 Nov 2011 17:11:41 GMT" Content-Transfer-Encoding: base64 LS0tIG9sZC9jYW1jb250cm9sLmgJMjAxMS0xMS0xNyAxMTo1MTozMC4wMDAwMDAwMDAgLTA1MDAK KysrIG5ldy9jYW1jb250cm9sLmgJMjAxMS0xMS0xNyAxMTo1MTozMC4wMDAwMDAwMDAgLTA1MDAK QEAgLTQwLDYgKzQwLDggQEAKIAlpbnQgZ290OwogfTsKIAoraW50IGZ3ZG93bmxvYWQoc3RydWN0 IGNhbV9kZXZpY2UgKmRldmljZSwgaW50IGFyZ2MsIGNoYXIgKiphcmd2LAorCSAgICAgICBjaGFy ICpjb21iaW5lZG9wdCwgaW50IHZlcmJvc2UsIGludCByZXRyeV9jb3VudCwgaW50IHRpbWVvdXQp Owogdm9pZCBtb2RlX3NlbnNlKHN0cnVjdCBjYW1fZGV2aWNlICpkZXZpY2UsIGludCBtb2RlX3Bh Z2UsIGludCBwYWdlX2NvbnRyb2wsCiAJCWludCBkYmQsIGludCByZXRyeV9jb3VudCwgaW50IHRp bWVvdXQsIHVfaW50OF90ICpkYXRhLAogCQlpbnQgZGF0YWxlbik7CkBAIC00OSw4ICs1MSwxMSBA QAogCSAgICAgICBpbnQgZWRpdCwgaW50IGJpbmFyeSwgaW50IHJldHJ5X2NvdW50LCBpbnQgdGlt ZW91dCk7CiB2b2lkIG1vZGVfbGlzdChzdHJ1Y3QgY2FtX2RldmljZSAqZGV2aWNlLCBpbnQgcGFn ZV9jb250cm9sLCBpbnQgZGJkLAogCSAgICAgICBpbnQgcmV0cnlfY291bnQsIGludCB0aW1lb3V0 KTsKK2ludCBzY3NpZG9pbnF1aXJ5KHN0cnVjdCBjYW1fZGV2aWNlICpkZXZpY2UsIGludCBhcmdj LCBjaGFyICoqYXJndiwKKwkJICBjaGFyICpjb21iaW5lZG9wdCwgaW50IHJldHJ5X2NvdW50LCBp bnQgdGltZW91dCk7CiBjaGFyICpjZ2V0KHZvaWQgKmhvb2ssIGNoYXIgKm5hbWUpOwogaW50IGln ZXQodm9pZCAqaG9vaywgY2hhciAqbmFtZSk7CiB2b2lkIGFyZ19wdXQodm9pZCAqaG9vaywgaW50 IGxldHRlciwgdm9pZCAqYXJnLCBpbnQgY291bnQsIGNoYXIgKm5hbWUpOworaW50IGdldF9jb25m aXJtYXRpb24odm9pZCk7CiB2b2lkIHVzYWdlKGludCB2ZXJib3NlKTsKICNlbmRpZiAvKiBfQ0FN Q09OVFJPTF9IICovCi0tLSBvbGQvY2FtY29udHJvbC5jCTIwMTEtMTEtMTcgMTE6NTE6MzAuMDAw MDAwMDAwIC0wNTAwCisrKyBuZXcvY2FtY29udHJvbC5jCTIwMTEtMTEtMTcgMTE6NTE6MzAuMDAw MDAwMDAwIC0wNTAwCkBAIC04Niw3ICs4Niw4IEBACiAJQ0FNX0NNRF9TTVBfUkcJCT0gMHgwMDAw MDAxOCwKIAlDQU1fQ01EX1NNUF9QQwkJPSAweDAwMDAwMDE5LAogCUNBTV9DTURfU01QX1BIWUxJ U1QJPSAweDAwMDAwMDFhLAotCUNBTV9DTURfU01QX01BTklORk8JPSAweDAwMDAwMDFiCisJQ0FN X0NNRF9TTVBfTUFOSU5GTwk9IDB4MDAwMDAwMWIsCisJQ0FNX0NNRF9ET1dOTE9BRF9GVwk9IDB4 MDAwMDAwMWMKIH0gY2FtX2NtZG1hc2s7CiAKIHR5cGVkZWYgZW51bSB7CkBAIC0xODAsNiArMTgx LDcgQEAKIAl7ImlkbGUiLCBDQU1fQ01EX0lETEUsIENBTV9BUkdfTk9ORSwgInQ6In0sCiAJeyJz dGFuZGJ5IiwgQ0FNX0NNRF9TVEFOREJZLCBDQU1fQVJHX05PTkUsICJ0OiJ9LAogCXsic2xlZXAi LCBDQU1fQ01EX1NMRUVQLCBDQU1fQVJHX05PTkUsICIifSwKKwl7ImZ3ZG93bmxvYWQiLCBDQU1f Q01EX0RPV05MT0FEX0ZXLCBDQU1fQVJHX05PTkUsICJmOnlzIn0sCiAjZW5kaWYgLyogTUlOSU1B TElTVElDICovCiAJeyJoZWxwIiwgQ0FNX0NNRF9VU0FHRSwgQ0FNX0FSR19OT05FLCBOVUxMfSwK IAl7Ii0/IiwgQ0FNX0NNRF9VU0FHRSwgQ0FNX0FSR19OT05FLCBOVUxMfSwKQEAgLTY4Myw3ICs2 ODUsNyBAQAogCXJldHVybihlcnJvcik7CiB9CiAKLXN0YXRpYyBpbnQKK2ludAogc2NzaWRvaW5x dWlyeShzdHJ1Y3QgY2FtX2RldmljZSAqZGV2aWNlLCBpbnQgYXJnYywgY2hhciAqKmFyZ3YsCiAJ ICAgICAgY2hhciAqY29tYmluZWRvcHQsIGludCByZXRyeV9jb3VudCwgaW50IHRpbWVvdXQpCiB7 CkBAIC0zNTcxLDcgKzM1NzMsNyBAQAogCXVuaW9uIGNjYiAqY2NiOwogCWludCBjOwogCWludCB5 Y291bnQgPSAwLCBxdWlldCA9IDA7Ci0JaW50IGVycm9yID0gMCwgcmVzcG9uc2UgPSAwLCByZXR2 YWwgPSAwOworCWludCBlcnJvciA9IDAsIHJldHZhbCA9IDA7CiAJaW50IHVzZV90aW1lb3V0ID0g MTA4MDAgKiAxMDAwOwogCWludCBpbW1lZGlhdGUgPSAxOwogCXN0cnVjdCBmb3JtYXRfZGVmZWN0 X2xpc3RfaGVhZGVyIGZoOwpAQCAtMzYyNSwyNyArMzYyNyw3IEBACiAJfQogCiAJaWYgKHljb3Vu dCA9PSAwKSB7Ci0KLQkJZG8gewotCQkJY2hhciBzdHJbMTAyNF07Ci0KLQkJCWZwcmludGYoc3Rk b3V0LCAiQXJlIHlvdSBTVVJFIHlvdSB3YW50IHRvIGRvICIKLQkJCQkidGhpcz8gKHllcy9ubykg Iik7Ci0KLQkJCWlmIChmZ2V0cyhzdHIsIHNpemVvZihzdHIpLCBzdGRpbikgIT0gTlVMTCkgewot Ci0JCQkJaWYgKHN0cm5jYXNlY21wKHN0ciwgInllcyIsIDMpID09IDApCi0JCQkJCXJlc3BvbnNl ID0gMTsKLQkJCQllbHNlIGlmIChzdHJuY2FzZWNtcChzdHIsICJubyIsIDIpID09IDApCi0JCQkJ CXJlc3BvbnNlID0gLTE7Ci0JCQkJZWxzZSB7Ci0JCQkJCWZwcmludGYoc3Rkb3V0LCAiUGxlYXNl IGFuc3dlciIKLQkJCQkJCSIgXCJ5ZXNcIiBvciBcIm5vXCJcbiIpOwotCQkJCX0KLQkJCX0KLQkJ fSB3aGlsZSAocmVzcG9uc2UgPT0gMCk7Ci0KLQkJaWYgKHJlc3BvbnNlID09IC0xKSB7CisJCWlm ICghZ2V0X2NvbmZpcm1hdGlvbigpKSB7CiAJCQllcnJvciA9IDE7CiAJCQlnb3RvIHNjc2lmb3Jt YXRfYmFpbG91dDsKIAkJfQpAQCAtNTY5Myw2ICs1Njc1LDcgQEAKICIgICAgICAgIGNhbWNvbnRy b2wgaWRsZSAgICAgICBbZGV2X2lkXVtnZW5lcmljIGFyZ3NdWy10IHRpbWVdXG4iCiAiICAgICAg ICBjYW1jb250cm9sIHN0YW5kYnkgICAgW2Rldl9pZF1bZ2VuZXJpYyBhcmdzXVstdCB0aW1lXVxu IgogIiAgICAgICAgY2FtY29udHJvbCBzbGVlcCAgICAgIFtkZXZfaWRdW2dlbmVyaWMgYXJnc11c biIKKyIgICAgICAgIGNhbWNvbnRyb2wgZndkb3dubG9hZCBbZGV2X2lkXVtnZW5lcmljIGFyZ3Nd IDwtZiBmd19pbWFnZT4gWy15XVstc11cbiIKICNlbmRpZiAvKiBNSU5JTUFMSVNUSUMgKi8KICIg ICAgICAgIGNhbWNvbnRyb2wgaGVscFxuIik7CiAJaWYgKCF2ZXJib3NlKQpAQCAtNTcyOCw2ICs1 NzExLDcgQEAKICJpZGxlICAgICAgICBzZW5kIHRoZSBBVEEgSURMRSBjb21tYW5kIHRvIHRoZSBu YW1lZCBkZXZpY2VcbiIKICJzdGFuZGJ5ICAgICBzZW5kIHRoZSBBVEEgU1RBTkRCWSBjb21tYW5k IHRvIHRoZSBuYW1lZCBkZXZpY2VcbiIKICJzbGVlcCAgICAgICBzZW5kIHRoZSBBVEEgU0xFRVAg Y29tbWFuZCB0byB0aGUgbmFtZWQgZGV2aWNlXG4iCisiZndkb3dubG9hZCAgcHJvZ3JhbSBmaXJt d2FyZSBvZiB0aGUgbmFtZWQgZGV2aWNlIHdpdGggdGhlIGdpdmVuIGltYWdlIgogImhlbHAgICAg ICAgIHRoaXMgbWVzc2FnZVxuIgogIkRldmljZSBJZGVudGlmaWVyczpcbiIKICJidXM6dGFyZ2V0 ICAgICAgICBzcGVjaWZ5IHRoZSBidXMgYW5kIHRhcmdldCwgbHVuIGRlZmF1bHRzIHRvIDBcbiIK QEAgLTU4MTksNyArNTgwMywxMiBAQAogIi13ICAgICAgICAgICAgICAgIGRvbid0IHNlbmQgaW1t ZWRpYXRlIGZvcm1hdCBjb21tYW5kXG4iCiAiLXkgICAgICAgICAgICAgICAgZG9uJ3QgYXNrIGFu eSBxdWVzdGlvbnNcbiIKICJpZGxlL3N0YW5kYnkgYXJndW1lbnRzOlxuIgotIi10IDxhcmc+ICAg ICAgICAgIG51bWJlciBvZiBzZWNvbmRzIGJlZm9yZSByZXNwZWN0aXZlIHN0YXRlLlxuIik7Cisi LXQgPGFyZz4gICAgICAgICAgbnVtYmVyIG9mIHNlY29uZHMgYmVmb3JlIHJlc3BlY3RpdmUgc3Rh dGUuXG4iCisiZndkb3dubG9hZCBhcmd1bWVudHM6XG4iCisiLWYgZndfaW1hZ2UgICAgICAgcGF0 aCB0byBmaXJtd2FyZSBpbWFnZSBmaWxlXG4iCisiLXkgICAgICAgICAgICAgICAgZG9uJ3QgYXNr IGFueSBxdWVzdGlvbnNcbiIKKyItcyAgICAgICAgICAgICAgICBydW4gaW4gc2ltdWxhdGlvbiBt b2RlXG4iCisiLXYgICAgICAgICAgICAgICAgcHJpbnQgaW5mbyBmb3IgZXZlcnkgZmlybXdhcmUg c2VnbWVudCBzZW50IHRvIGRldmljZVxuIik7CiAjZW5kaWYgLyogTUlOSU1BTElTVElDICovCiB9 CiAKQEAgLTYxMzUsNiArNjEyNCwxMCBAQAogCQkJCQkJIGNvbWJpbmVkb3B0LCByZXRyeV9jb3Vu dCwKIAkJCQkJCSB0aW1lb3V0KTsKIAkJCWJyZWFrOworCQljYXNlIENBTV9DTURfRE9XTkxPQURf Rlc6CisJCQllcnJvciA9IGZ3ZG93bmxvYWQoY2FtX2RldiwgYXJnYywgYXJndiwgY29tYmluZWRv cHQsCisJCQkgICAgYXJnbGlzdCAmIENBTV9BUkdfVkVSQk9TRSwgcmV0cnlfY291bnQsIHRpbWVv dXQpOworCQkJYnJlYWs7CiAjZW5kaWYgLyogTUlOSU1BTElTVElDICovCiAJCWNhc2UgQ0FNX0NN RF9VU0FHRToKIAkJCXVzYWdlKDEpOwotLS0gb2xkL2Z3ZG93bmxvYWQuYwkxOTY5LTEyLTMxIDE5 OjAwOjAwLjAwMDAwMDAwMCAtMDUwMAorKysgbmV3L2Z3ZG93bmxvYWQuYwkyMDExLTExLTE3IDEx OjUxOjMwLjAwMDAwMDAwMCAtMDUwMApAQCAtMCwwICsxLDM3OCBAQAorLyotCisgKiBDb3B5cmln aHQgKGMpIDIwMTEgU2FuZHZpbmUgSW5jb3Jwb3JhdGVkLiBBbGwgcmlnaHRzIHJlc2VydmVkLgor ICogQ29weXJpZ2h0IChjKSAyMDAyLTIwMTEgQW5kcmUgQWxic21laWVyIDxhbmRyZUBhbGJzbWVp ZXIubmV0PgorICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBh bmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1v ZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29u ZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29k ZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlz dCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIsCisgKiAgICB3aXRo b3V0IG1vZGlmaWNhdGlvbiwgaW1tZWRpYXRlbHkgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgZmls ZS4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0 aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25z IGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBkb2N1bWVudGF0aW9u IGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLiAK KyAqICAgIAorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIGBgQVMg SVMnJyBBTkQgQU5ZIEVYUFJFU1MgT1IKKyAqIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5H LCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRSBJTVBMSUVEIFdBUlJBTlRJRVMKKyAqIE9GIE1FUkNI QU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQVJFIERJU0NM QUlNRUQuICAKKyAqIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgQkUgTElBQkxFIEZPUiBB TlkgRElSRUNULCBJTkRJUkVDVCwKKyAqIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwg T1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVAorICogTk9UIExJTUlURUQg VE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0Yg VVNFLAorICogREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dF VkVSIENBVVNFRCBBTkQgT04gQU5ZCisgKiBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElO IENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLCBPUiBUT1JUICAKKyAqIChJTkNMVURJTkcgTkVH TElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWSBPVVQgT0YgVEhFIFVTRSBP RgorICogVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBP RiBTVUNIIERBTUFHRS4KKyAqLworCisvKgorICogQkVXQVJFOgorICoKKyAqIFRoZSBmYWN0IHRo YXQgeW91IHNlZSB5b3VyIGZhdm9yaXRlIHZlbmRvciBsaXN0ZWQgYmVsb3cgZG9lcyBub3QKKyAq IGltcGx5IHRoYXQgeW91ciBlcXVpcG1lbnQgd29uJ3QgYnJlYWsgd2hlbiB5b3UgdXNlIHRoaXMg c29mdHdhcmUKKyAqIHdpdGggaXQuIEl0IG9ubHkgbWVhbnMgdGhhdCB0aGUgZmlybXdhcmUgb2Yg YXQgbGVhc3Qgb25lIGRldmljZSB0eXBlCisgKiBvZiBlYWNoIHZlbmRvciBsaXN0ZWQgaGFzIGJl ZW4gcHJvZ3JhbW1lZCBzdWNjZXNzZnVsbHkgdXNpbmcgdGhpcyBjb2RlLgorICoKKyAqIFRoZSAt cyBvcHRpb24gc2ltdWxhdGVzIGEgZG93bmxvYWQgYnV0IGRvZXMgbm90aGluZyBhcGFydCBmcm9t IHRoYXQuCisgKiBJdCBjYW4gYmUgdXNlZCB0byBjaGVjayB3aGF0IGNodW5rIHNpemVzIHdvdWxk IGhhdmUgYmVlbiB1c2VkIHdpdGggdGhlCisgKiBzcGVjaWZpZWQgZGV2aWNlLgorICovCisKKwor I2luY2x1ZGUgPHN5cy90eXBlcy5oPgorI2luY2x1ZGUgPHN5cy9zdGF0Lmg+CisKKyNpbmNsdWRl IDxlcnIuaD4KKyNpbmNsdWRlIDxmY250bC5oPgorI2luY2x1ZGUgPHN0ZGlvLmg+CisjaW5jbHVk ZSA8c3RkbGliLmg+CisjaW5jbHVkZSA8c3RyaW5nLmg+CisjaW5jbHVkZSA8dW5pc3RkLmg+CisK KyNpbmNsdWRlIDxjYW0vc2NzaS9zY3NpX2FsbC5oPgorI2luY2x1ZGUgPGNhbS9zY3NpL3Njc2lf bWVzc2FnZS5oPgorI2luY2x1ZGUgPGNhbWxpYi5oPgorCisjaW5jbHVkZSAiY2FtY29udHJvbC5o IgorCisjZGVmaW5lCUNNRF9USU1FT1VUIDUwMDAwCS8qIDUwIHNlY29uZHMgKi8KKwordHlwZWRl ZiBlbnVtIHsKKwlWRU5ET1JfSElUQUNISSwKKwlWRU5ET1JfSFAsCisJVkVORE9SX0lCTSwKKwlW RU5ET1JfUExFWFRPUiwKKwlWRU5ET1JfUVVBTlRVTSwKKwlWRU5ET1JfU0VBR0FURSwKKwlWRU5E T1JfVU5LTk9XTgorfSBmd192ZW5kb3JfdDsKKworc3RydWN0IGZ3X3ZlbmRvciB7CisJZndfdmVu ZG9yX3QgdHlwZTsKKwljb25zdCBjaGFyICpwYXR0ZXJuOworCWludCBtYXhfcGt0X3NpemU7CisJ dV9pbnQ4X3QgY2RiX2J5dGUyOworCXVfaW50OF90IGNkYl9ieXRlMl9sYXN0OworCWludCBpbmNf Y2RiX2J1ZmZlcl9pZDsKKwlpbnQgaW5jX2NkYl9vZmZzZXQ7Cit9OworCitzdHJ1Y3QgZndfdmVu ZG9yIHZlbmRvcnNfbGlzdFtdID0geworCXtWRU5ET1JfSElUQUNISSwJIkhJVEFDSEkiLAkweDgw MDAsIDB4MDUsIDB4MDUsIDEsIDB9LAorCXtWRU5ET1JfSFAsCQkiSFAiLAkJMHg4MDAwLCAweDA3 LCAweDA3LCAwLCAxfSwKKwl7VkVORE9SX0lCTSwJCSJJQk0iLAkJMHg4MDAwLCAweDA1LCAweDA1 LCAxLCAwfSwKKwl7VkVORE9SX1BMRVhUT1IsCSJQTEVYVE9SIiwJMHgyMDAwLCAweDA0LCAweDA1 LCAwLCAxfSwKKwl7VkVORE9SX1FVQU5UVU0sCSJRVUFOVFVNIiwJMHgyMDAwLCAweDA0LCAweDA1 LCAwLCAxfSwKKwl7VkVORE9SX1NFQUdBVEUsCSJTRUFHQVRFIiwJMHg4MDAwLCAweDA3LCAweDA3 LCAwLCAxfSwKKwl7VkVORE9SX1VOS05PV04sCU5VTEwsCQkweDAwMDAsIDB4MDAsIDB4MDAsIDAs IDB9Cit9OworCitzdGF0aWMgc3RydWN0IGZ3X3ZlbmRvciAqZndfZ2V0X3ZlbmRvcihzdHJ1Y3Qg Y2FtX2RldmljZSAqY2FtX2Rldik7CitzdGF0aWMgY2hhcgkqZndfcmVhZF9pbWcoY2hhciAqZndf aW1nX3BhdGgsIHN0cnVjdCBmd192ZW5kb3IgKnZwLAorCQkgICAgaW50ICpudW1fYnl0ZXMpOwor c3RhdGljIGludAkgZndfZG93bmxvYWRfaW1nKHN0cnVjdCBjYW1fZGV2aWNlICpjYW1fZGV2LAor CQkgICAgc3RydWN0IGZ3X3ZlbmRvciAqdnAsIGNoYXIgKmJ1ZiwgaW50IGltZ19zaXplLAorCQkg ICAgaW50IHNpbV9tb2RlLCBpbnQgdmVyYm9zZSwgaW50IHJldHJ5X2NvdW50LCBpbnQgdGltZW91 dCk7CisKKy8qCisgKiBGaW5kIGVudHJ5IGluIHZlbmRvcnMgbGlzdCB0aGF0IGJlbG9uZ3MgdG8K KyAqIHRoZSB2ZW5kb3Igb2YgZ2l2ZW4gY2FtIGRldmljZS4KKyAqLworc3RhdGljIHN0cnVjdCBm d192ZW5kb3IgKgorZndfZ2V0X3ZlbmRvcihzdHJ1Y3QgY2FtX2RldmljZSAqY2FtX2RldikKK3sK KwljaGFyIHZlbmRvcltTSURfVkVORE9SX1NJWkUgKyAxXTsKKwlzdHJ1Y3QgZndfdmVuZG9yICp2 cDsKKworCWlmIChjYW1fZGV2ID09IE5VTEwpCisJCXJldHVybiAoTlVMTCk7CisJY2FtX3N0cnZp cygodV9jaGFyICopdmVuZG9yLCAodV9jaGFyICopY2FtX2Rldi0+aW5xX2RhdGEudmVuZG9yLAor CSAgICBzaXplb2YoY2FtX2Rldi0+aW5xX2RhdGEudmVuZG9yKSwgc2l6ZW9mKHZlbmRvcikpOwor CWZvciAodnAgPSB2ZW5kb3JzX2xpc3Q7IHZwLT5wYXR0ZXJuICE9IE5VTEw7IHZwKyspIHsKKwkJ aWYgKCFjYW1fc3RybWF0Y2goKGNvbnN0IHVfY2hhciAqKXZlbmRvciwKKwkJICAgIChjb25zdCB1 X2NoYXIgKil2cC0+cGF0dGVybiwgc3RybGVuKHZlbmRvcikpKQorCQkJYnJlYWs7CisJfQorCXJl dHVybiAodnApOworfQorCisvKgorICogQWxsb2NhdGUgYSBidWZmZXIgYW5kIHJlYWQgZncgaW1h Z2UgZmlsZSBpbnRvIGl0CisgKiBmcm9tIGdpdmVuIHBhdGguIE51bWJlciBvZiBieXRlcyByZWFk IGlzIHN0b3JlZAorICogaW4gbnVtX2J5dGVzLgorICovCitzdGF0aWMgY2hhciAqCitmd19yZWFk X2ltZyhjaGFyICpmd19pbWdfcGF0aCwgc3RydWN0IGZ3X3ZlbmRvciAqdnAsIGludCAqbnVtX2J5 dGVzKQoreworCWludCBmZDsKKwlzdHJ1Y3Qgc3RhdCBzdGJ1ZjsKKwljaGFyICpidWY7CisJb2Zm X3QgaW1nX3NpemU7CisJaW50IHNraXBfYnl0ZXMgPSAwOworCisJaWYgKChmZCA9IG9wZW4oZndf aW1nX3BhdGgsIE9fUkRPTkxZKSkgPCAwKSB7CisJCXdhcm4oIkNvdWxkIG5vdCBvcGVuIGltYWdl IGZpbGUgJXMiLCBmd19pbWdfcGF0aCk7CisJCXJldHVybiAoTlVMTCk7CisJfQorCWlmIChmc3Rh dChmZCwgJnN0YnVmKSA8IDApIHsKKwkJd2FybigiQ291bGQgbm90IHN0YXQgaW1hZ2UgZmlsZSAl cyIsIGZ3X2ltZ19wYXRoKTsKKwkJZ290byBiYWlsb3V0MTsKKwl9CisJaWYgKChpbWdfc2l6ZSA9 IHN0YnVmLnN0X3NpemUpID09IDApIHsKKwkJd2FybngoIlplcm8gbGVuZ3RoIGltYWdlIGZpbGUg JXMiLCBmd19pbWdfcGF0aCk7CisJCWdvdG8gYmFpbG91dDE7CisJfQorCWlmICgoYnVmID0gbWFs bG9jKGltZ19zaXplKSkgPT0gTlVMTCkgeworCQl3YXJueCgiQ291bGQgbm90IGFsbG9jYXRlIGJ1 ZmZlciB0byByZWFkIGltYWdlIGZpbGUgJXMiLAorCQkgICAgZndfaW1nX3BhdGgpOworCQlnb3Rv IGJhaWxvdXQxOworCX0KKwkvKiBTa2lwIGhlYWRlcnMgaWYgYXBwbGljYWJsZS4gKi8KKwlzd2l0 Y2ggKHZwLT50eXBlKSB7CisJY2FzZSBWRU5ET1JfU0VBR0FURToKKwkJaWYgKHJlYWQoZmQsIGJ1 ZiwgMTYpICE9IDE2KSB7CisJCQl3YXJuKCJDb3VsZCBub3QgcmVhZCBpbWFnZSBmaWxlICVzIiwg ZndfaW1nX3BhdGgpOworCQkJZ290byBiYWlsb3V0OworCQl9CisJCWlmIChsc2VlayhmZCwgMCwg U0VFS19TRVQpID09IC0xKSB7CisJCQl3YXJuKCJVbmFibGUgdG8gbHNlZWsiKTsKKwkJCWdvdG8g YmFpbG91dDsKKwkJfQorCQlpZiAoKHN0cm5jbXAoYnVmLCAiU0VBR0FURSxTRUFHQVRFICIsIDE2 KSA9PSAwKSB8fAorCQkgICAgKGltZ19zaXplICUgNTEyID09IDgwKSkKKwkJCXNraXBfYnl0ZXMg PSA4MDsKKwkJYnJlYWs7CisJZGVmYXVsdDoKKwkJYnJlYWs7CisJfQorCWlmIChza2lwX2J5dGVz ICE9IDApIHsKKwkJZnByaW50ZihzdGRvdXQsICJTa2lwcGluZyAlZCBieXRlIGhlYWRlci5cbiIs IHNraXBfYnl0ZXMpOworCQlpZiAobHNlZWsoZmQsIHNraXBfYnl0ZXMsIFNFRUtfU0VUKSA9PSAt MSkgeworCQkJd2FybigiQ291bGQgbm90IGxzZWVrIik7CisJCQlnb3RvIGJhaWxvdXQ7CisJCX0K KwkJaW1nX3NpemUgLT0gc2tpcF9ieXRlczsKKwl9CisJLyogUmVhZCBpbWFnZSBpbnRvIGEgYnVm ZmVyLiAqLworCWlmIChyZWFkKGZkLCBidWYsIGltZ19zaXplKSAhPSBpbWdfc2l6ZSkgeworCQl3 YXJuKCJDb3VsZCBub3QgcmVhZCBpbWFnZSBmaWxlICVzIiwgZndfaW1nX3BhdGgpOworCQlnb3Rv IGJhaWxvdXQ7CisJfQorCSpudW1fYnl0ZXMgPSBpbWdfc2l6ZTsKKwlyZXR1cm4gKGJ1Zik7Citi YWlsb3V0OgorCWZyZWUoYnVmKTsKK2JhaWxvdXQxOgorCWNsb3NlKGZkKTsKKwkqbnVtX2J5dGVz ID0gMDsKKwlyZXR1cm4gKE5VTEwpOworfQorCisvKiAKKyAqIERvd25sb2FkIGZpcm13YXJlIHN0 b3JlZCBpbiBidWYgdG8gY2FtX2Rldi4gSWYgc2ltdWxhdGlvbiBtb2RlCisgKiBpcyBlbmFibGVk LCBvbmx5IHNob3cgd2hhdCBwYWNrZXQgc2l6ZXMgd291bGQgYmUgc2VudCB0byB0aGUgCisgKiBk ZXZpY2UgYnV0IGRvIG5vdCBzZW50IGFueSBhY3R1YWwgcGFja2V0cworICovCitzdGF0aWMgaW50 Citmd19kb3dubG9hZF9pbWcoc3RydWN0IGNhbV9kZXZpY2UgKmNhbV9kZXYsIHN0cnVjdCBmd192 ZW5kb3IgKnZwLAorICAgIGNoYXIgKmJ1ZiwgaW50IGltZ19zaXplLCBpbnQgc2ltX21vZGUsIGlu dCB2ZXJib3NlLCBpbnQgcmV0cnlfY291bnQsCisgICAgaW50IHRpbWVvdXQpCit7CisJc3RydWN0 IHNjc2lfd3JpdGVfYnVmZmVyIGNkYjsKKwl1bmlvbiBjY2IgKmNjYjsKKwlpbnQgcGt0X2NvdW50 ID0gMDsKKwl1X2ludDMyX3QgcGt0X3NpemUgPSAwOworCWNoYXIgKnBrdF9wdHIgPSBidWY7CisJ dV9pbnQzMl90IG9mZnNldDsKKwlpbnQgbGFzdF9wa3QgPSAwOworCisJaWYgKChjY2IgPSBjYW1f Z2V0Y2NiKGNhbV9kZXYpKSA9PSBOVUxMKSB7CisJCXdhcm54KCJDb3VsZCBub3QgYWxsb2NhdGUg Q0NCIik7CisJCXJldHVybiAoMSk7CisJfQorCXNjc2lfdGVzdF91bml0X3JlYWR5KCZjY2ItPmNz aW8sIDAsIE5VTEwsIE1TR19TSU1QTEVfUV9UQUcsCisJICAgIFNTRF9GVUxMX1NJWkUsIDUwMDAp OworCS8qIERpc2FibGUgZnJlZXppbmcgdGhlIGRldmljZSBxdWV1ZS4gKi8KKwljY2ItPmNjYl9o LmZsYWdzIHw9IENBTV9ERVZfUUZSWkRJUzsKKwlpZiAoY2FtX3NlbmRfY2NiKGNhbV9kZXYsIGNj YikgPCAwKSB7CisJCXdhcm54KCJFcnJvciBzZW5kaW5nIHRlc3QgdW5pdCByZWFkeSIpOworCQlp ZiAodmVyYm9zZSkKKwkJCWNhbV9lcnJvcl9wcmludChjYW1fZGV2LCBjY2IsIENBTV9FU0ZfQUxM LAorCQkJICAgIENBTV9FUEZfQUxMLCBzdGRlcnIpOworCQljYW1fZnJlZWNjYihjY2IpOworCQly ZXR1cm4oMSk7CisJfQorCWlmICgoY2NiLT5jY2JfaC5zdGF0dXMgJiBDQU1fU1RBVFVTX01BU0sp ICE9IENBTV9SRVFfQ01QKSB7CisJCXdhcm54KCJEZXZpY2UgaXMgbm90IHJlYWR5Iik7CisJCWlm ICh2ZXJib3NlKQorCQkJY2FtX2Vycm9yX3ByaW50KGNhbV9kZXYsIGNjYiwgQ0FNX0VTRl9BTEws CisJCQkgICAgQ0FNX0VQRl9BTEwsIHN0ZGVycik7CisJCWNhbV9mcmVlY2NiKGNjYik7CisJCXJl dHVybiAoMSk7CisJfQorCXBrdF9zaXplID0gdnAtPm1heF9wa3Rfc2l6ZTsKKwlpZiAodmVyYm9z ZSB8fCBzaW1fbW9kZSkgeworCQlmcHJpbnRmKHN0ZG91dCwKKwkJICAgICItLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLVxuIik7CisJCWZwcmludGYoc3Rk b3V0LAorCQkgICAgIlBrdE5vLglQa3RTaXplCSAgICAgICBCeXRlc1JlbWFpbmluZwlMYXN0UGt0 XG4iKTsKKwkJZnByaW50ZihzdGRvdXQsCisJCSAgICAiLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1cbiIpOworCX0KKwkvKiBEb3dubG9hZCBzaW5nbGUg ZncgcGFja2V0cy4gKi8KKwlkbyB7CisJCWlmIChpbWdfc2l6ZSA8PSB2cC0+bWF4X3BrdF9zaXpl KSB7CisJCQlsYXN0X3BrdCA9IDE7CisJCQlwa3Rfc2l6ZSA9IGltZ19zaXplOworCQl9CisJCWlm ICh2ZXJib3NlIHx8IHNpbV9tb2RlKQorCQkJZnByaW50ZihzdGRvdXQsICIlM3UgICAlNXUgKDB4 JTA1WCkgICAlN3UgKDB4JTA2WCkgICAiCisJCQkgICAgIiVkXG4iLCBwa3RfY291bnQsIHBrdF9z aXplLCBwa3Rfc2l6ZSwKKwkJCSAgICBpbWdfc2l6ZSAtIHBrdF9zaXplLCBpbWdfc2l6ZSAtIHBr dF9zaXplLAorCQkJICAgIGxhc3RfcGt0KTsKKwkJYnplcm8oJmNkYiwgc2l6ZW9mKGNkYikpOwor CQljZGIub3Bjb2RlICA9IFdSSVRFX0JVRkZFUjsKKwkJY2RiLmNvbnRyb2wgPSAwOworCQkvKiBQ YXJhbWV0ZXIgbGlzdCBsZW5ndGguICovCisJCXNjc2lfdWx0bzNiKHBrdF9zaXplLCAmY2RiLmxl bmd0aFswXSk7CisJCW9mZnNldCA9IHZwLT5pbmNfY2RiX29mZnNldCA/IChwa3RfcHRyIC0gYnVm KSA6IDA7CisJCXNjc2lfdWx0bzNiKG9mZnNldCwgJmNkYi5vZmZzZXRbMF0pOworCQljZGIuYnl0 ZTIgPSBsYXN0X3BrdCA/IHZwLT5jZGJfYnl0ZTJfbGFzdCA6IHZwLT5jZGJfYnl0ZTI7CisJCWNk Yi5idWZmZXJfaWQgPSB2cC0+aW5jX2NkYl9idWZmZXJfaWQgPyBwa3RfY291bnQgOiAwOworCQkv KiBaZXJvIG91dCBwYXlsb2FkIG9mIGNjYiB1bmlvbiBhZnRlciBjY2IgaGVhZGVyLiAqLworCQli emVybygodV9jaGFyICopY2NiICsgc2l6ZW9mKHN0cnVjdCBjY2JfaGRyKSwKKwkJICAgIHNpemVv ZihzdHJ1Y3QgY2NiX3Njc2lpbykgLSBzaXplb2Yoc3RydWN0IGNjYl9oZHIpKTsKKwkJLyogQ29w eSBwcmV2aW91c2x5IGNvbnN0cnVjdGVkIGNkYiBpbnRvIGNjYl9zY3NpaW8gc3RydWN0LiAqLwor CQliY29weSgmY2RiLCAmY2NiLT5jc2lvLmNkYl9pby5jZGJfYnl0ZXNbMF0sCisJCSAgICBzaXpl b2Yoc3RydWN0IHNjc2lfd3JpdGVfYnVmZmVyKSk7CisJCS8qIEZpbGwgcmVzdCBvZiBjY2Jfc2Nz aWlvIHN0cnVjdC4gKi8KKwkJaWYgKCFzaW1fbW9kZSkgeworCQkJY2FtX2ZpbGxfY3NpbygmY2Ni LT5jc2lvLAkJLyogY2NiX3Njc2lpbwkqLworCQkJICAgIHJldHJ5X2NvdW50LAkJCS8qIHJldHJp ZXMJKi8KKwkJCSAgICBOVUxMLAkJCQkvKiBjYmZjbnAJKi8KKwkJCSAgICBDQU1fRElSX09VVCB8 IENBTV9ERVZfUUZSWkRJUywJLyogZmxhZ3MJKi8KKwkJCSAgICBDQU1fVEFHX0FDVElPTl9OT05F LAkJLyogdGFnX2FjdGlvbgkqLworCQkJICAgICh1X2NoYXIgKilwa3RfcHRyLAkJCS8qIGRhdGFf cHRyCSovCisJCQkgICAgcGt0X3NpemUsCQkJCS8qIGR4ZmVyX2xlbgkqLworCQkJICAgIFNTRF9G VUxMX1NJWkUsCQkJLyogc2Vuc2VfbGVuCSovCisJCQkgICAgc2l6ZW9mKHN0cnVjdCBzY3NpX3dy aXRlX2J1ZmZlciksCS8qIGNkYl9sZW4JKi8KKwkJCSAgICB0aW1lb3V0ID8gdGltZW91dCA6IENN RF9USU1FT1VUKTsJLyogdGltZW91dAkqLworCQkJLyogRXhlY3V0ZSB0aGUgY29tbWFuZC4gKi8K KwkJCWlmIChjYW1fc2VuZF9jY2IoY2FtX2RldiwgY2NiKSA8IDApIHsKKwkJCQl3YXJueCgiRXJy b3Igd3JpdGluZyBpbWFnZSB0byBkZXZpY2UiKTsKKwkJCQlpZiAodmVyYm9zZSkKKwkJCQkJY2Ft X2Vycm9yX3ByaW50KGNhbV9kZXYsIGNjYiwgQ0FNX0VTRl9BTEwsCisJCQkJCSAgICBDQU1fRVBG X0FMTCwgc3RkZXJyKTsKKwkJCQlnb3RvIGJhaWxvdXQ7CisJCQl9CisJCX0KKwkJLyogUHJlcGFy ZSBuZXh0IHJvdW5kLiAqLworCQlwa3RfY291bnQrKzsKKwkJcGt0X3B0ciArPSBwa3Rfc2l6ZTsK KwkJaW1nX3NpemUgLT0gcGt0X3NpemU7CisJfSB3aGlsZSghbGFzdF9wa3QpOworCWlmICgoY2Ni LT5jY2JfaC5zdGF0dXMgJiBDQU1fU1RBVFVTX01BU0spICE9IENBTV9SRVFfQ01QKSB7CisJCWlm ICh2ZXJib3NlKQorCQkJY2FtX2Vycm9yX3ByaW50KGNhbV9kZXYsIGNjYiwgQ0FNX0VTRl9BTEws CisJCQkgICAgQ0FNX0VQRl9BTEwsIHN0ZGVycik7CisJCWdvdG8gYmFpbG91dDsKKwl9CisJY2Ft X2ZyZWVjY2IoY2NiKTsKKwlyZXR1cm4gKDApOworYmFpbG91dDoKKwljYW1fZnJlZWNjYihjY2Ip OworCXJldHVybiAoMSk7Cit9CisKK2ludAorZndkb3dubG9hZChzdHJ1Y3QgY2FtX2RldmljZSAq ZGV2aWNlLCBpbnQgYXJnYywgY2hhciAqKmFyZ3YsCisgICAgY2hhciAqY29tYmluZWRvcHQsIGlu dCB2ZXJib3NlLCBpbnQgcmV0cnlfY291bnQsIGludCB0aW1lb3V0KQoreworCXN0cnVjdCBmd192 ZW5kb3IgKnZwOworCWNoYXIgKmZ3X2ltZ19wYXRoID0gTlVMTDsKKwljaGFyICpidWY7CisJaW50 IGltZ19zaXplOworCWludCBjOworCWludCBzaW1fbW9kZSA9IDA7CisJaW50IGNvbmZpcm1lZCA9 IDA7CisKKwl3aGlsZSAoKGMgPSBnZXRvcHQoYXJnYywgYXJndiwgY29tYmluZWRvcHQpKSAhPSAt MSkgeworCQlzd2l0Y2ggKGMpIHsKKwkJY2FzZSAncyc6CisJCQlzaW1fbW9kZSA9IDE7CisJCQlj b25maXJtZWQgPSAxOworCQkJYnJlYWs7CisJCWNhc2UgJ2YnOgorCQkJZndfaW1nX3BhdGggPSBv cHRhcmc7CisJCQlicmVhazsKKwkJY2FzZSAneSc6CisJCQljb25maXJtZWQgPSAxOworCQkJYnJl YWs7CisJCWRlZmF1bHQ6CisJCQlicmVhazsKKwkJfQorCX0KKworCWlmIChmd19pbWdfcGF0aCA9 PSBOVUxMKQorCQllcnJ4KDEsCisJCSAgICAieW91IG11c3Qgc3BlY2lmeSBhIGZpcm13YXJlIGlt YWdlIGZpbGUgdXNpbmcgLWYgb3B0aW9uIik7CisKKwl2cCA9IGZ3X2dldF92ZW5kb3IoZGV2aWNl KTsKKwlpZiAodnAgPT0gTlVMTCB8fCB2cC0+dHlwZSA9PSBWRU5ET1JfVU5LTk9XTikKKwkJZXJy eCgxLCAiVW5zdXBwb3J0ZWQgZGV2aWNlIik7CisKKwlidWYgPSBmd19yZWFkX2ltZyhmd19pbWdf cGF0aCwgdnAsICZpbWdfc2l6ZSk7CisJaWYgKGJ1ZiA9PSBOVUxMKQorCQlnb3RvIGZhaWw7CisK KwlpZiAoIWNvbmZpcm1lZCkgeworCQlmcHJpbnRmKHN0ZG91dCwgIllvdSBhcmUgYWJvdXQgdG8g ZG93bmxvYWQgZmlybXdhcmUgaW1hZ2UgKCVzKSIKKwkJICAgICIgaW50byB0aGUgZm9sbG93aW5n IGRldmljZTpcbiIsCisJCSAgICBmd19pbWdfcGF0aCk7CisJCWlmIChzY3NpZG9pbnF1aXJ5KGRl dmljZSwgYXJnYywgYXJndiwgY29tYmluZWRvcHQsIDAsCisJCSAgICA1MDAwKSAhPSAwKSB7CisJ CQl3YXJueCgiRXJyb3Igc2VuZGluZyBpbnF1aXJ5Iik7CisJCQlnb3RvIGZhaWw7CisJCX0KKwkJ ZnByaW50ZihzdGRvdXQsICJcbkl0IG1heSBkYW1hZ2UgeW91ciBkcml2ZS4gIik7CisJCWlmICgh Z2V0X2NvbmZpcm1hdGlvbigpKQorCQkJZ290byBmYWlsOworCX0KKwlpZiAoc2ltX21vZGUpCisJ CWZwcmludGYoc3Rkb3V0LCAiUnVubmluZyBpbiBzaW11bGF0aW9uIG1vZGVcbiIpOworCisJaWYg KGZ3X2Rvd25sb2FkX2ltZyhkZXZpY2UsIHZwLCBidWYsIGltZ19zaXplLCBzaW1fbW9kZSwgdmVy Ym9zZSwKKwkgICAgcmV0cnlfY291bnQsIHRpbWVvdXQpICE9IDApIHsKKwkJZnByaW50ZihzdGRl cnIsICJGaXJtd2FyZSBkb3dubG9hZCBmYWlsZWRcbiIpOworCQlnb3RvIGZhaWw7CisJfSBlbHNl IAorCQlmcHJpbnRmKHN0ZG91dCwgIkZpcm13YXJlIGRvd25sb2FkIHN1Y2Nlc3NmdWxcbiIpOwor CisJZnJlZShidWYpOworCXJldHVybiAoMCk7CitmYWlsOgorCWlmIChidWYgIT0gTlVMTCkKKwkJ ZnJlZShidWYpOworCXJldHVybiAoMSk7Cit9CisKLS0tIG9sZC9jYW1jb250cm9sLjgJMjAxMS0x MS0xNyAxMTo1MTozMC4wMDAwMDAwMDAgLTA1MDAKKysrIG5ldy9jYW1jb250cm9sLjgJMjAxMS0x MS0xNyAxMTo1MTozMC4wMDAwMDAwMDAgLTA1MDAKQEAgLTI3LDcgKzI3LDcgQEAKIC5cIgogLlwi ICRGcmVlQlNEJAogLlwiCi0uRGQgTm92ZW1iZXIgMzAsIDIwMTAKKy5EZCBOb3ZlbWJlciAxNywg MjAxMQogLkR0IENBTUNPTlRST0wgOAogLk9zCiAuU2ggTkFNRQpAQCAtMjIwLDYgKzIyMCwxMyBA QAogLk9wIGRldmljZSBpZAogLk9wIGdlbmVyaWMgYXJncwogLk5tCisuSWMgZndkb3dubG9hZAor Lk9wIGRldmljZSBpZAorLk9wIGdlbmVyaWMgYXJncworLkFxIEZsIGYgQXIgZndfaW1hZ2UKKy5P cCBGbCB5CisuT3AgRmwgcworLk5tCiAuSWMgaGVscAogLlNoIERFU0NSSVBUSU9OCiBUaGUKQEAg LTEwNjAsNiArMTA2Nyw0OSBAQAogLkl0IEljIHNsZWVwCiBQdXQgQVRBIGRldmljZSBpbnRvIFNM RUVQIHN0YXRlLiBOb3RlIHRoYXQgdGhlIG9ubHkgd2F5IGdldCBkZXZpY2Ugb3V0IG9mCiB0aGlz IHN0YXRlIG1heSBiZSByZXNldC4KKy5JdCBJYyBmd2Rvd25sb2FkCitQcm9ncmFtIGZpcm13YXJl IG9mIHRoZSBuYW1lZCBTQ1NJIGRldmljZSB1c2luZyB0aGUgaW1hZ2UgZmlsZSBwcm92aWRlZC4K Ky5QcAorQ3VycmVudCBsaXN0IG9mIHN1cHBvcnRlZCB2ZW5kb3JzOgorLkJsIC1idWxsZXQgLW9m ZnNldCBpbmRlbnQgLWNvbXBhY3QKKy5JdAorSElUQUNISQorLkl0CitIUAorLkl0CitJQk0KKy5J dAorUExFWFRPUgorLkl0CitRVUFOVFVNCisuSXQKK1NFQUdBVEUKKy5FbAorLlBwCisuRW0gV0FS TklORyEgV0FSTklORyEgV0FSTklORyEKKy5QcAorVmVyeSBsaXR0bGUgdGVzdGluZyBoYXMgYmVl biBkb25lIHRvIG1ha2Ugc3VyZSB0aGF0IGRpZmZlcmVudCBkZXZpY2UgbW9kZWxzCitvZiBlYWNo IHZlbmRvciB3b3JrIGNvcnJlY3RseSB3aXRoIGZ3ZG93bmxvYWQgY29tbWFuZC4gU2hvd2luZyB1 cCBhIHZlbmRvciAKK25hbWUgaW4gdGhlIHN1cHBvcnRlZCBsaXN0IGJhc2ljYWxseSBtZWFucyBm aXJtd2FyZSBvZiBhdCBsZWFzdCBvbmUgZGV2aWNlCit0eXBlIGZyb20gdGhhdCB2ZW5kb3IgaGFz IHN1Y2Nlc3NmdWxseSBiZWVuIHByb2dyYW1tZWQgd2l0aCBmd2Rvd25sb2FkCitjb21tYW5kLiBF eHRyYSBjYXV0aW9uIHNob3VsZCBiZSB0YWtlbiB3aGVuIHVzaW5nIHRoaXMgY29tbWFuZCBzaW5j ZSB0aGVyZSBpcworbm8gZ3VhcmFudGVlIGl0IHdvdWxkIG5vdCBicmVhayBhIGRldmljZSBmcm9t IGxpc3RlZCB2ZW5kb3JzLgorLkJsIC10YWcgLXdpZHRoIDExbgorLkl0IEZsIGYgQXIgZndfaW1h Z2UKK1BhdGggdG8gdGhlIGZpcm13YXJlIGltYWdlIGZpbGUgdG8gYmUgZG93bmxvYWRlZCB0byB0 aGUgc3BlY2lmaWVkIGRldmljZS4KKy5JdCBGbCB5CitEbyBub3QgYXNrIHRoZSB1c2VyIGZvciBj b25maXJtYXRpb24uCisuSXQgRmwgcworUnVuIGluIHNpbXVsYXRpb24gbW9kZSB3aGVyZSBwYWNr ZXQgc2l6ZXMgdGhhdCBhcmUgZ29pbmcgdG8gYmUgc2VudCBhcmUgc2hvd24sCitidXQgbm8gYWN0 dWFsIHBhY2tldCBpcyBzZW50IHRvIHRoZSBkZXZpY2UuIE5vIGNvbmZpbWF0aW9uIHF1ZXN0aW9u IGlzIGFza2VkIAorZnJvbSB1c2VyIGluIHNpbXVsYXRpb24gbW9kZS4KKy5JdCBGbCB2CitCZXNp ZGVzIHNob3dpbmcgc2Vuc2UgaW5mb3JtYXRpb24gaW4gY2FzZSBvZiBhIGZhaWx1cmUsIHRoZSB2 ZXJib3NlIG9wdGlvbiBjYXVzZXMKKy5ObQordG8gb3V0cHV0IGEgbGluZSBmb3IgZXZlcnkgZmly bXdhcmUgc2VnbWVudCB0aGF0IGlzIHNlbnQgdG8gdGhlIGRldmljZSBieSB0aGUKK2Z3ZG93bmxv YWQgY29tbWFuZAorLS0gdGhlIHNhbWUgYXMgdGhlIG9uZXMgc2hvd24gaW4gc2ltdWxhdGlvbiBt b2RlLgorLkVsCiAuSXQgSWMgaGVscAogUHJpbnQgb3V0IHZlcmJvc2UgdXNhZ2UgaW5mb3JtYXRp b24uCiAuRWwKLS0tIG9sZC9NYWtlZmlsZQkyMDExLTExLTE3IDExOjUxOjMwLjAwMDAwMDAwMCAt MDUwMAorKysgbmV3L01ha2VmaWxlCTIwMTEtMTEtMTcgMTE6NTE6MzAuMDAwMDAwMDAwIC0wNTAw CkBAIC0xLDcgKzEsNyBAQAogIyAkRnJlZUJTRCQKIAogUFJPRz0JY2FtY29udHJvbAotU1JDUz0J Y2FtY29udHJvbC5jIHV0aWwuYworU1JDUz0JY2FtY29udHJvbC5jIGZ3ZG93bmxvYWQuYyB1dGls LmMKIC5pZiAhZGVmaW5lZChSRUxFQVNFX0NSVU5DSCkKIFNSQ1MrPQltb2RlZWRpdC5jCiAuZWxz ZQotLS0gb2xkL3V0aWwuYwkyMDExLTExLTE3IDExOjUxOjMwLjAwMDAwMDAwMCAtMDUwMAorKysg bmV3L3V0aWwuYwkyMDExLTExLTE3IDExOjUxOjMwLjAwMDAwMDAwMCAtMDUwMApAQCAtMTU0LDMg KzE1NCwzMSBAQAogCWlmICh2ZXJib3NlKQogCQlwdXRjaGFyKCdcbicpOwogfQorCisvKgorICog R2V0IGNvbmZpcm1hdGlvbiBmcm9tIHVzZXIKKyAqIFJldHVybiB2YWx1ZXM6CisgKiAgICAxOiBj b25maXJtZWQKKyAqICAgIDA6IHVuY29uZmlybWVkCisgKi8KK2ludAorZ2V0X2NvbmZpcm1hdGlv bigpCit7CisJY2hhciBzdHJbMTAyNF07CisJaW50IHJlc3BvbnNlID0gLTE7CisKKwlkbyB7CisJ CWZwcmludGYoc3Rkb3V0LCAiQXJlIHlvdSBTVVJFIHlvdSB3YW50IHRvIGRvIHRoaXM/ICh5ZXMv bm8pICIpOworCQlpZiAoZmdldHMoc3RyLCBzaXplb2Yoc3RyKSwgc3RkaW4pICE9IE5VTEwpIHsK KwkJCWlmIChzdHJuY2FzZWNtcChzdHIsICJ5ZXMiLCAzKSA9PSAwKQorCQkJCXJlc3BvbnNlID0g MTsKKwkJCWVsc2UgaWYgKHN0cm5jYXNlY21wKHN0ciwgIm5vIiwgMikgPT0gMCkKKwkJCQlyZXNw b25zZSA9IDA7CisJCQllbHNlCisJCQkJZnByaW50ZihzdGRvdXQsCisJCQkJICAgICJQbGVhc2Ug YW5zd2VyIFwieWVzXCIgb3IgXCJub1wiXG4iKTsKKwkJfSBlbHNlCisJCQlyZXNwb25zZSA9IDA7 CisJfSB3aGlsZSAocmVzcG9uc2UgPT0gLTEpOworCXJldHVybiAocmVzcG9uc2UpOworfQo= --_002_0A3573FC36A1BE41AAA3DFF287C7968405688Awtlexch2sandvinec_-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 17:28:24 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2687A1065673; Thu, 17 Nov 2011 17:28:24 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id D239A8FC17; Thu, 17 Nov 2011 17:28:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id C776B446004; Thu, 17 Nov 2011 12:11:24 -0500 (EST) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqOiyXUH4ZgV; Thu, 17 Nov 2011 12:11:23 -0500 (EST) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 7E560446003; Thu, 17 Nov 2011 12:11:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> Date: Thu, 17 Nov 2011 12:11:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0850D6DB-386B-4588-A362-D53637D25F7D@averesystems.com> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1084) Cc: arch@freebsd.org, current@freebsd.org, avg@freebsd.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 17:28:24 -0000 On Nov 13, 2011, at 3:32 AM, Kostik Belousov wrote: > I was tricked into finishing the work by Andrey Gapon, who developed > the patch to reliably stop other processors on panic. The patch > greatly improves the chances of getting dump on panic on SMP host. > Several people already saw the patchset, and I remember that Andrey > posted it to some lists. >=20 > The change stops other (*) processors early upon the panic. This way, > no parallel manipulation of the kernel memory is performed by CPUs. > In particular, the kernel memory map is static. Patch prevents the > panic thread from blocking and switching out. >=20 > * - in the context of the description, other means not current. >=20 > Since other threads are not run anymore, lock owner cannot release a > lock which is required by panic thread. Due to this, we need to fake > a lock acquisition after the panic, which adds minimal overhead to the > locking cost. The patch tries to not add any overhead on the fast path > of the lock acquire. The check for the after-panic condition was > reduced to single memory access, done only when the quick cas lock > attempt failed, and braced with __unlikely compiler hint. >=20 > For now, the new mode of operation is disabled by default, since some > further USB changes are needed to make USB keyboard usable in that > environment. >=20 > With the patch, getting a dump from the machine without debugger > compiled in is much more realistic. Please comment, I will commit the > change in 2 weeks unless strong reasons not to are given. >=20 > http://people.freebsd.org/~kib/misc/stop_cpus_on_panic.1.patch >=20 We have many systems running Andriy's latest version of the patch under = 8.2. I also brought in the related USB patch; without it, the system = hangs up while dumping almost every time. With both patches in place* = it has worked flawlessly for us. -Andrew * - with one change: always do the critical_enter() / critical_exit(). = Using spinlock_enter() blocks the software watchdog, which needs to = still be active in case the dump hangs for other reasons. This is = obviously not ideal but the best solution I have right now. We also = stop all of the network interfaces at the beginning of boot(). -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 17:29:33 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6C241065693; Thu, 17 Nov 2011 17:29:33 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4FE8FC16; Thu, 17 Nov 2011 17:29:33 +0000 (UTC) Received: by mail-yw0-f54.google.com with SMTP id 9so2016958ywe.13 for ; Thu, 17 Nov 2011 09:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=06M+gcREvGq+x5j3iRhAUi4TUL8N1V518bfWHG4MUNQ=; b=ifHTmccbWkg+qzUNHF/1ujWksu0e0WuWxE3jmxRG8/kwAAR0anB3IykdG3KIcaOI3G oj3DCqB6bTSoymnm08ADHAyHkZSSWV/PEMV10rPxt+fWFv1b7wNKe0axIlQ4NjIARQwe pDjm/up1Wo5Fo38TCNM/oC6un9F+9PmOeh4yg= MIME-Version: 1.0 Received: by 10.146.200.27 with SMTP id x27mr2570367yaf.31.1321550972211; Thu, 17 Nov 2011 09:29:32 -0800 (PST) Sender: maksim.yevmenkin@gmail.com Received: by 10.100.122.19 with HTTP; Thu, 17 Nov 2011 09:29:32 -0800 (PST) In-Reply-To: <4EC53E28.2030609@FreeBSD.org> References: <4EC43ABA.7060407@FreeBSD.org> <4EC4404B.4070008@FreeBSD.org> <4EC531A4.4000803@FreeBSD.org> <4EC53E28.2030609@FreeBSD.org> Date: Thu, 17 Nov 2011 09:29:32 -0800 X-Google-Sender-Auth: j_sKwC9enIx_hdSu1-XYbTCqotg Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: [RFC] ahci(4) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 17:29:33 -0000 On Thu, Nov 17, 2011 at 9:02 AM, Alexander Motin wrote: > On 11/17/11 18:35, Maksim Yevmenkin wrote: >> On Thu, Nov 17, 2011 at 8:09 AM, Alexander Motin wrote= : >>> On 11/17/11 01:08, Maksim Yevmenkin wrote: >>>> On Wed, Nov 16, 2011 at 2:59 PM, Alexander Motin wro= te: >>>>> On 17.11.2011 00:44, Maksim Yevmenkin wrote: >>>>>> >>>>>> On Wed, Nov 16, 2011 at 2:35 PM, Alexander Motin = =A0wrote: >>>>>>> >>>>>>> On 16.11.2011 23:59, Maksim Yevmenkin wrote: >>>>>>>> >>>>>>>> would anyone object to the following ahci(4) patch? >>>>>>>> >>>>>>>> =3D=3D >>>>>>>> >>>>>>>> --- ahci.c.orig 2011-11-16 21:35:26.000000000 +0000 >>>>>>>> +++ ahci.c =A0 =A0 =A02011-11-16 21:35:41.000000000 +0000 >>>>>>>> @@ -500,7 +500,7 @@ >>>>>>>> =A0 =A0 =A0 =A0for (unit =3D 0; unit< =A0 =A0ctlr->channels; unit+= +) { >>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ((ctlr->ichannels& =A0 =A0(1<< = =A0 =A0unit)) =3D=3D 0) >>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; >>>>>>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 child =3D device_add_child(dev, "ahc= ich", -1); >>>>>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 child =3D device_add_child(dev, "ahc= ich", unit); >>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (child =3D=3D NULL) >>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_printf(dev, = "failed to add channel >>>>>>>> device\n"); >>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else >>>>>>>> >>>>>>>> =3D=3D >>>>>>>> >>>>>>>> the idea is to have "static" numbering for ada(4) disks. >>>>>>> >>>>>>> I do. The only way I see this useful is if you have BIOS configured= for >>>>>>> non-hot-swappable disks, in which case you have some AHCI channels >>>>>>> disabled, >>>>>>> but want to keep numbers of the rest. While I don't like this mode = in >>>>>>> general, especially when it can't be disabled, that patch could be = useful >>>>>>> in >>>>>>> these cases. But in other cases, when you have several AHCI control= lers, >>>>>>> it >>>>>>> just wont not work. You will receive error on attempt to create sec= ond >>>>>>> ahcich0. >>>>>> >>>>>> shouldn't achcichX be destroyed when disk is detached/removed/etc.? >>>>> >>>>> List of implemented AHCI channels to expose as ahcichX set by BIOS in >>>>> vendor-specific way, but only during boot and not by many BIOSes. Des= troying >>>>> them on disk detach theoretically possible, but IMHO not right, as bu= s >>>>> doesn't disappear on disk disconnect. >>>>> >>>>>> the particular problem i'm trying to address is disk re-numbering wh= en >>>>>> one of the disks fails/removed/etc. i'm trying to use hints to wire >>>>>> disks to controllers/busses. it works perfectly fine with da(4) disk= s >>>>>> (even hot swappable ones) , but i can not make it to work with ada(4= ) >>>>>> disks. i'm perfectly fine to hid this under some sort of option >>>>>> (something similar to ATA_STATIC_ID, AHCI_STATIC_ID for example) >>>>> >>>>> Wiring works for adaX also, unless your BIOS is so "intelligent" to r= eport >>>>> unconnected ports and not impliemented.. You should just wire CAM bus= es to >>>>> ahcichX, not to ahciX. It could be done in other way changing just by= one >>>>> line around xpt_bus_register(), but now it is done so. >>>> >>>> ok. then i must be missing something, here is what i have in device.hi= nts >>>> >>>> hint.scbus.0.at=3D"umass-sim0" >>>> hint.scbus.1.at=3D"ahcich0" >>>> hint.scbus.2.at=3D"ahcich1" >>>> hint.scbus.3.at=3D"ahcich2" >>>> hint.scbus.4.at=3D"ahcich3" >>>> hint.scbus.5.at=3D"ahcich4" >>>> hint.scbus.6.at=3D"ahcich5" >>>> >>>> hint.da.0.at=3D"scbus0" >>>> hint.ada.0.at=3D"scbus1" >>>> hint.ada.1.at=3D"scbus2" >>>> hint.ada.2.at=3D"scbus3" >>>> hint.ada.3.at=3D"scbus4" >>>> hint.ada.4.at=3D"scbus5" >>>> hint.ada.5.at=3D"scbus6" >>>> >>>> this is for 6-port ahci(4) compatible controller (intel) on the >>>> motherboard. no matter which achi(4) ports are connected, resulted >>>> adaX devices are always sequential starting from ada0. so, the >>>> question is: what am i doing wrong here? >>> >>> Just put your lines into my loader.conf and got this: >>> >>> %camcontrol devlist -v >>> scbus1 on ahcich0 bus 0: >>> =A0 =A0at scbus1 target 0 lun 0 (pass0,= ada0) >>> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at s= cbus1 target -1 lun -1 () >>> scbus2 on ahcich1 bus 0: >>> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at s= cbus2 target -1 lun -1 () >>> scbus3 on ahcich2 bus 0: >>> =A0 =A0at scbus3 target 0 lun 0 (pass1,= ada2) >>> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at s= cbus3 target -1 lun -1 () >>> scbus4 on ahcich3 bus 0: >>> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at s= cbus4 target -1 lun -1 () >>> scbus5 on ahcich4 bus 0: >>> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at s= cbus5 target -1 lun -1 () >>> scbus6 on ahcich5 bus 0: >>> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at s= cbus6 target -1 lun -1 () >>> ... >>> >>> I see no problem. What am I doing wrong? >>> >>> Let me repeat question not asked directly: Does your BIOS reports unuse= d >>> AHCI channels as implemented? Do you always have all 6 ahcich devices o= r >>> not? >> >> i not exactly sure. below is the relevant dmesg. as far as i can tell, >> channels are correct, however, ahcich numbering is sequential and that >> is why hints dont work. >> >> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: > SATA controller> port >> 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f >> mem 0xfbb21000-0xfbb217ff irq 19 at device 31.2 on pci0 >> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: attempting to allocate 1 >> MSI vectors (1 supported) >> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: using IRQ 270 for MSI >> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: AHCI v1.30 with 6 6Gbps >> ports, Port Multiplier not supported >> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: Caps: 64bit NCQ SNTF AL >> CLO 6Gbps PMD SSC PSC 32cmd EM 6ports >> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: Caps2: APST >> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: EM Caps: ALHD XMT SMB LED >> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: at >> channel 0 on ahci0 >> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: Caps: >> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: at >> channel 2 on ahci0 >> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: Caps: >> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: at >> channel 5 on ahci0 >> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: Caps: > > Yes, that's it. You should have six ahcichX devices, but have only three > - only for connected devices. Some vendors (Supermicro was first I've > heard about) last time randomly started to make BIOS mark unused AHCI > channels as unimplemented. Sometimes it can be configured in BIOS setup > (it may be called like "hot-swappable"), sometimes not. I believe that > is wrong AHCI spec interpretation. > > If it is not configurable in BIOS, we could add respective hint to the > ahci(4) to allow user ignore these fake "implemented" flags to always > present all possible ports, but it is direct AHCI spec violation. aha! yes, there is a bios option for each sata port that is called hot plug: enable/disable. each sata port had "hot plug" disabled by default. after i enabled it, it started to work as expected. thanks! and, yes, it is a supermicro motherboard. thanks max From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 17:36:41 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03F2F106566C; Thu, 17 Nov 2011 17:36:41 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 47B4F8FC12; Thu, 17 Nov 2011 17:36:40 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so3122984bkb.13 for ; Thu, 17 Nov 2011 09:36:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=y2h1dhdFWF91Pj8uBNvK1l05CLgRo8MvgRk6I4My4Lw=; b=lqWIYoe1amoTcu2j5VluwOw8NHwhnesWzgzFnIIzzD3ymio3ZNn3gVOxiy2jl2hmQA 15PGrjNCBVj/PgdTi3rB0yZQXggwZP2l45IJU8njWVPg6k8qOLfNS+NpAwKYB33ZwXwO rTzT40rB9OFXkMfYnuEgJHSVz875KhBDsLK9M= Received: by 10.205.118.13 with SMTP id fo13mr27040188bkc.123.1321551399100; Thu, 17 Nov 2011 09:36:39 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id i3sm2682993fah.11.2011.11.17.09.36.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 09:36:38 -0800 (PST) Sender: Alexander Motin Message-ID: <4EC54624.4000409@FreeBSD.org> Date: Thu, 17 Nov 2011 19:36:36 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: Maksim Yevmenkin References: <4EC43ABA.7060407@FreeBSD.org> <4EC4404B.4070008@FreeBSD.org> <4EC531A4.4000803@FreeBSD.org> <4EC53E28.2030609@FreeBSD.org> In-Reply-To: <4EC53E28.2030609@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: [RFC] ahci(4) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 17:36:41 -0000 On 11/17/11 19:02, Alexander Motin wrote: > On 11/17/11 18:35, Maksim Yevmenkin wrote: >> On Thu, Nov 17, 2011 at 8:09 AM, Alexander Motin wrote: >>> On 11/17/11 01:08, Maksim Yevmenkin wrote: >>>> On Wed, Nov 16, 2011 at 2:59 PM, Alexander Motin wrote: >>>>> On 17.11.2011 00:44, Maksim Yevmenkin wrote: >>>>>> >>>>>> On Wed, Nov 16, 2011 at 2:35 PM, Alexander Motin wrote: >>>>>>> >>>>>>> On 16.11.2011 23:59, Maksim Yevmenkin wrote: >>>>>>>> >>>>>>>> would anyone object to the following ahci(4) patch? >>>>>>>> >>>>>>>> == >>>>>>>> >>>>>>>> --- ahci.c.orig 2011-11-16 21:35:26.000000000 +0000 >>>>>>>> +++ ahci.c 2011-11-16 21:35:41.000000000 +0000 >>>>>>>> @@ -500,7 +500,7 @@ >>>>>>>> for (unit = 0; unit< ctlr->channels; unit++) { >>>>>>>> if ((ctlr->ichannels& (1<< unit)) == 0) >>>>>>>> continue; >>>>>>>> - child = device_add_child(dev, "ahcich", -1); >>>>>>>> + child = device_add_child(dev, "ahcich", unit); >>>>>>>> if (child == NULL) >>>>>>>> device_printf(dev, "failed to add channel >>>>>>>> device\n"); >>>>>>>> else >>>>>>>> >>>>>>>> == >>>>>>>> >>>>>>>> the idea is to have "static" numbering for ada(4) disks. >>>>>>> >>>>>>> I do. The only way I see this useful is if you have BIOS configured for >>>>>>> non-hot-swappable disks, in which case you have some AHCI channels >>>>>>> disabled, >>>>>>> but want to keep numbers of the rest. While I don't like this mode in >>>>>>> general, especially when it can't be disabled, that patch could be useful >>>>>>> in >>>>>>> these cases. But in other cases, when you have several AHCI controllers, >>>>>>> it >>>>>>> just wont not work. You will receive error on attempt to create second >>>>>>> ahcich0. >>>>>> >>>>>> shouldn't achcichX be destroyed when disk is detached/removed/etc.? >>>>> >>>>> List of implemented AHCI channels to expose as ahcichX set by BIOS in >>>>> vendor-specific way, but only during boot and not by many BIOSes. Destroying >>>>> them on disk detach theoretically possible, but IMHO not right, as bus >>>>> doesn't disappear on disk disconnect. >>>>> >>>>>> the particular problem i'm trying to address is disk re-numbering when >>>>>> one of the disks fails/removed/etc. i'm trying to use hints to wire >>>>>> disks to controllers/busses. it works perfectly fine with da(4) disks >>>>>> (even hot swappable ones) , but i can not make it to work with ada(4) >>>>>> disks. i'm perfectly fine to hid this under some sort of option >>>>>> (something similar to ATA_STATIC_ID, AHCI_STATIC_ID for example) >>>>> >>>>> Wiring works for adaX also, unless your BIOS is so "intelligent" to report >>>>> unconnected ports and not impliemented.. You should just wire CAM buses to >>>>> ahcichX, not to ahciX. It could be done in other way changing just by one >>>>> line around xpt_bus_register(), but now it is done so. >>>> >>>> ok. then i must be missing something, here is what i have in device.hints >>>> >>>> hint.scbus.0.at="umass-sim0" >>>> hint.scbus.1.at="ahcich0" >>>> hint.scbus.2.at="ahcich1" >>>> hint.scbus.3.at="ahcich2" >>>> hint.scbus.4.at="ahcich3" >>>> hint.scbus.5.at="ahcich4" >>>> hint.scbus.6.at="ahcich5" >>>> >>>> hint.da.0.at="scbus0" >>>> hint.ada.0.at="scbus1" >>>> hint.ada.1.at="scbus2" >>>> hint.ada.2.at="scbus3" >>>> hint.ada.3.at="scbus4" >>>> hint.ada.4.at="scbus5" >>>> hint.ada.5.at="scbus6" >>>> >>>> this is for 6-port ahci(4) compatible controller (intel) on the >>>> motherboard. no matter which achi(4) ports are connected, resulted >>>> adaX devices are always sequential starting from ada0. so, the >>>> question is: what am i doing wrong here? >>> >>> Just put your lines into my loader.conf and got this: >>> >>> %camcontrol devlist -v >>> scbus1 on ahcich0 bus 0: >>> at scbus1 target 0 lun 0 (pass0,ada0) >>> <> at scbus1 target -1 lun -1 () >>> scbus2 on ahcich1 bus 0: >>> <> at scbus2 target -1 lun -1 () >>> scbus3 on ahcich2 bus 0: >>> at scbus3 target 0 lun 0 (pass1,ada2) >>> <> at scbus3 target -1 lun -1 () >>> scbus4 on ahcich3 bus 0: >>> <> at scbus4 target -1 lun -1 () >>> scbus5 on ahcich4 bus 0: >>> <> at scbus5 target -1 lun -1 () >>> scbus6 on ahcich5 bus 0: >>> <> at scbus6 target -1 lun -1 () >>> ... >>> >>> I see no problem. What am I doing wrong? >>> >>> Let me repeat question not asked directly: Does your BIOS reports unused >>> AHCI channels as implemented? Do you always have all 6 ahcich devices or >>> not? >> >> i not exactly sure. below is the relevant dmesg. as far as i can tell, >> channels are correct, however, ahcich numbering is sequential and that >> is why hints dont work. >> >> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: > SATA controller> port >> 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f >> mem 0xfbb21000-0xfbb217ff irq 19 at device 31.2 on pci0 >> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: attempting to allocate 1 >> MSI vectors (1 supported) >> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: using IRQ 270 for MSI >> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: AHCI v1.30 with 6 6Gbps >> ports, Port Multiplier not supported >> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: Caps: 64bit NCQ SNTF AL >> CLO 6Gbps PMD SSC PSC 32cmd EM 6ports >> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: Caps2: APST >> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: EM Caps: ALHD XMT SMB LED >> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: at >> channel 0 on ahci0 >> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: Caps: >> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: at >> channel 2 on ahci0 >> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: Caps: >> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: at >> channel 5 on ahci0 >> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: Caps: > > Yes, that's it. You should have six ahcichX devices, but have only three > - only for connected devices. Some vendors (Supermicro was first I've > heard about) last time randomly started to make BIOS mark unused AHCI > channels as unimplemented. Sometimes it can be configured in BIOS setup > (it may be called like "hot-swappable"), sometimes not. I believe that > is wrong AHCI spec interpretation. > > If it is not configurable in BIOS, we could add respective hint to the > ahci(4) to allow user ignore these fake "implemented" flags to always > present all possible ports, but it is direct AHCI spec violation. > > Other possible way is to leave ahcichX device as-is, but instead > register ports in CAM in different fashion -- as buses of the same > controller. Patch may look like this: > > --- ahci.c (revision 227580) > +++ ahci.c (working copy) > @@ -985,8 +985,8 @@ > goto err1; > } > /* Construct SIM entry */ > - ch->sim = cam_sim_alloc(ahciaction, ahcipoll, "ahcich", ch, > - device_get_unit(dev), &ch->mtx, > + ch->sim = cam_sim_alloc(ahciaction, ahcipoll, "ahci", ch, > + device_get_unit(device_get_parent(dev)), &ch->mtx, > min(2, ch->numslots), > (ch->caps & AHCI_CAP_SNCQ) ? ch->numslots : 0, > devq); > @@ -996,7 +996,7 @@ > error = ENOMEM; > goto err1; > } > - if (xpt_bus_register(ch->sim, dev, 0) != CAM_SUCCESS) { > + if (xpt_bus_register(ch->sim, dev, ch->unit) != CAM_SUCCESS) { > device_printf(dev, "unable to register xpt bus\n"); > error = ENXIO; > goto err2; > > Then output looks that way: > %camcontrol devlist -v > scbus1 on ahci0 bus 0: > at scbus1 target 0 lun 0 (pass0,ada0) > <> at scbus1 target -1 lun -1 () > scbus2 on ahci0 bus 1: > <> at scbus2 target -1 lun -1 () > scbus3 on ahci0 bus 2: > at scbus3 target 0 lun 0 (pass1,ada2) > <> at scbus3 target -1 lun -1 () > scbus4 on ahci0 bus 3: > <> at scbus4 target -1 lun -1 () > scbus5 on ahci0 bus 4: > <> at scbus5 target -1 lun -1 () > scbus6 on ahci0 bus 5: > <> at scbus6 target -1 lun -1 () > > But in that case two problems remain: > - per-port device hints still won't be usable, while changing them will > break POLA; > - it will also break POLA for users who are using wiring now. One more idea. We can create ahcichX devices for every AHCI channel, but disable them for channels marked as not implemented: --- ahci.c (revision 227580) +++ ahci.c (working copy) @@ -498,13 +498,14 @@ } /* Attach all channels on this controller */ for (unit = 0; unit < ctlr->channels; unit++) { - if ((ctlr->ichannels & (1 << unit)) == 0) - continue; child = device_add_child(dev, "ahcich", -1); - if (child == NULL) + if (child == NULL) { device_printf(dev, "failed to add channel device\n"); - else - device_set_ivars(child, (void *)(intptr_t)unit); + continue; + } + device_set_ivars(child, (void *)(intptr_t)unit); + if ((ctlr->ichannels & (1 << unit)) == 0) + device_disable(child); } bus_generic_attach(dev); return 0; Device disabling is not very used functionality now, but it seems fit perfectly for this case: ahcich0: at channel 0 on ahci0 ahcich0: Caps: HPCP ahcich1: not probed (disabled) ahcich2: at channel 2 on ahci0 ahcich2: Caps: HPCP ahcich3: at channel 3 on ahci0 ahcich3: Caps: HPCP ahcich4: not probed (disabled) ahcich5: not probed (disabled) -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 17:43:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69C9E10657A5; Thu, 17 Nov 2011 17:43:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 33E5A8FC13; Thu, 17 Nov 2011 17:43:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHHhMwG086281; Thu, 17 Nov 2011 12:43:22 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHHhMs5086252; Thu, 17 Nov 2011 17:43:22 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 17:43:22 GMT Message-Id: <201111171743.pAHHhMs5086252@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 17:43:23 -0000 TB --- 2011-11-17 15:27:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 15:27:01 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-17 15:27:01 - cleaning the object tree TB --- 2011-11-17 15:27:13 - cvsupping the source tree TB --- 2011-11-17 15:27:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-17 15:27:26 - building world TB --- 2011-11-17 15:27:26 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 15:27:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 15:27:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 15:27:26 - SRCCONF=/dev/null TB --- 2011-11-17 15:27:26 - TARGET=powerpc TB --- 2011-11-17 15:27:26 - TARGET_ARCH=powerpc TB --- 2011-11-17 15:27:26 - TZ=UTC TB --- 2011-11-17 15:27:26 - __MAKE_CONF=/dev/null TB --- 2011-11-17 15:27:26 - cd /src TB --- 2011-11-17 15:27:26 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 15:27:26 UTC 2011 >>> 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 Thu Nov 17 17:29:36 UTC 2011 TB --- 2011-11-17 17:29:36 - generating LINT kernel config TB --- 2011-11-17 17:29:36 - cd /src/sys/powerpc/conf TB --- 2011-11-17 17:29:36 - /usr/bin/make -B LINT TB --- 2011-11-17 17:29:36 - cd /src/sys/powerpc/conf TB --- 2011-11-17 17:29:36 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 17:29:36 - building GENERIC kernel TB --- 2011-11-17 17:29:36 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 17:29:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 17:29:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 17:29:36 - SRCCONF=/dev/null TB --- 2011-11-17 17:29:36 - TARGET=powerpc TB --- 2011-11-17 17:29:36 - TARGET_ARCH=powerpc TB --- 2011-11-17 17:29:36 - TZ=UTC TB --- 2011-11-17 17:29:36 - __MAKE_CONF=/dev/null TB --- 2011-11-17 17:29:36 - cd /src TB --- 2011-11-17 17:29:36 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 17:29:36 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 17:43:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 17:43:21 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 17:43:21 - 6557.05 user 1120.39 system 8180.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 17:46:14 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AE87106567C; Thu, 17 Nov 2011 17:46:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4E1A38FC1F; Thu, 17 Nov 2011 17:46:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHHkDqu001865; Thu, 17 Nov 2011 12:46:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHHkDjD001860; Thu, 17 Nov 2011 17:46:13 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 17:46:13 GMT Message-Id: <201111171746.pAHHkDjD001860@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 17:46:14 -0000 TB --- 2011-11-17 16:23:47 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 16:23:47 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-11-17 16:23:47 - cleaning the object tree TB --- 2011-11-17 16:24:06 - cvsupping the source tree TB --- 2011-11-17 16:24:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-11-17 16:24:19 - building world TB --- 2011-11-17 16:24:19 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 16:24:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 16:24:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 16:24:19 - SRCCONF=/dev/null TB --- 2011-11-17 16:24:19 - TARGET=sparc64 TB --- 2011-11-17 16:24:19 - TARGET_ARCH=sparc64 TB --- 2011-11-17 16:24:19 - TZ=UTC TB --- 2011-11-17 16:24:19 - __MAKE_CONF=/dev/null TB --- 2011-11-17 16:24:19 - cd /src TB --- 2011-11-17 16:24:19 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 16:24:20 UTC 2011 >>> 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 Thu Nov 17 17:30:41 UTC 2011 TB --- 2011-11-17 17:30:41 - generating LINT kernel config TB --- 2011-11-17 17:30:41 - cd /src/sys/sparc64/conf TB --- 2011-11-17 17:30:41 - /usr/bin/make -B LINT TB --- 2011-11-17 17:30:41 - cd /src/sys/sparc64/conf TB --- 2011-11-17 17:30:41 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 17:30:41 - building GENERIC kernel TB --- 2011-11-17 17:30:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 17:30:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 17:30:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 17:30:41 - SRCCONF=/dev/null TB --- 2011-11-17 17:30:41 - TARGET=sparc64 TB --- 2011-11-17 17:30:41 - TARGET_ARCH=sparc64 TB --- 2011-11-17 17:30:41 - TZ=UTC TB --- 2011-11-17 17:30:41 - __MAKE_CONF=/dev/null TB --- 2011-11-17 17:30:41 - cd /src TB --- 2011-11-17 17:30:41 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 17:30:41 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 17:46:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 17:46:13 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 17:46:13 - 3701.98 user 825.16 system 4945.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 18:08:49 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F24DB106566C; Thu, 17 Nov 2011 18:08:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BDA5A8FC13; Thu, 17 Nov 2011 18:08:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHI8mU2068832; Thu, 17 Nov 2011 13:08:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHI8mpK068831; Thu, 17 Nov 2011 18:08:48 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 18:08:48 GMT Message-Id: <201111171808.pAHI8mpK068831@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 18:08:50 -0000 TB --- 2011-11-17 16:16:44 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 16:16:44 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-17 16:16:44 - cleaning the object tree TB --- 2011-11-17 16:17:00 - cvsupping the source tree TB --- 2011-11-17 16:17:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-17 16:17:13 - building world TB --- 2011-11-17 16:17:13 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 16:17:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 16:17:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 16:17:13 - SRCCONF=/dev/null TB --- 2011-11-17 16:17:13 - TARGET=powerpc TB --- 2011-11-17 16:17:13 - TARGET_ARCH=powerpc64 TB --- 2011-11-17 16:17:13 - TZ=UTC TB --- 2011-11-17 16:17:13 - __MAKE_CONF=/dev/null TB --- 2011-11-17 16:17:13 - cd /src TB --- 2011-11-17 16:17:13 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 16:17:13 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Nov 17 17:55:57 UTC 2011 TB --- 2011-11-17 17:55:57 - generating LINT kernel config TB --- 2011-11-17 17:55:57 - cd /src/sys/powerpc/conf TB --- 2011-11-17 17:55:57 - /usr/bin/make -B LINT TB --- 2011-11-17 17:55:57 - cd /src/sys/powerpc/conf TB --- 2011-11-17 17:55:57 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 17:55:57 - skipping GENERIC kernel TB --- 2011-11-17 17:55:57 - cd /src/sys/powerpc/conf TB --- 2011-11-17 17:55:57 - /usr/sbin/config -m GENERIC64 TB --- 2011-11-17 17:55:57 - building GENERIC64 kernel TB --- 2011-11-17 17:55:57 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 17:55:57 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 17:55:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 17:55:57 - SRCCONF=/dev/null TB --- 2011-11-17 17:55:57 - TARGET=powerpc TB --- 2011-11-17 17:55:57 - TARGET_ARCH=powerpc64 TB --- 2011-11-17 17:55:57 - TZ=UTC TB --- 2011-11-17 17:55:57 - __MAKE_CONF=/dev/null TB --- 2011-11-17 17:55:57 - cd /src TB --- 2011-11-17 17:55:57 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Thu Nov 17 17:55:57 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 18:08:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 18:08:48 - ERROR: failed to build GENERIC64 kernel TB --- 2011-11-17 18:08:48 - 5186.77 user 1138.12 system 6724.20 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 18:19:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A8A31065738; Thu, 17 Nov 2011 18:19:35 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmail.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5AB1C8FC08; Thu, 17 Nov 2011 18:19:35 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 785DECE47; Thu, 17 Nov 2011 13:19:34 -0500 (EST) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id 30491B8DE; Thu, 17 Nov 2011 13:19:31 -0500 (EST) Received: from smtp1.acsu.buffalo.edu (smtp1.acsu.buffalo.edu [128.205.5.253]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id 14EDCD51A; Thu, 17 Nov 2011 13:19:31 -0500 (EST) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (Authenticated sender: kensmith@buffalo.edu) by smtp1.acsu.buffalo.edu (Postfix) with ESMTPSA id 088AB48EED; Thu, 17 Nov 2011 13:19:31 -0500 (EST) From: Ken Smith To: freebsd-current , freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-4X3a6ZpsEuSjvxhdzbe6" Date: Thu, 17 Nov 2011 13:19:30 -0500 Message-ID: <1321553970.82271.66.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: Subject: FreeBSD 9.0-RC2 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 18:19:35 -0000 --=-4X3a6ZpsEuSjvxhdzbe6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The second of the Release Candidate builds for the 9.0-RELEASE release cycle is now available. Since this is the first release of a brand new branch I cross-post the announcements on both -current and -stable. But just so you know most of the developers active in head and stable/9 pay more attention to the -current mailing list. If you notice problems you can report them through the normal Gnats PR system or on the -current mailing list. At the current plans are for one more RC build, which will be followed by the release. The 9.0-RELEASE cycle will be tracked here: http://wiki.freebsd.org/Releng/9.0TODO NOTE: The location of the FTP install tree and ISOs is the same as it had been for BETA2/BETA3/RC1, though we are still deciding if this will be the layout we switch to for the release. ISO images for the following architectures are available, with pathnames given relative to the top-level of the FTP site: amd64: .../releases/amd64/amd64/ISO-IMAGES/9.0/ i386: .../releases/i386/i386/ISO-IMAGES/9.0/ ia64: .../releases/ia64/ia64/ISO-IMAGES/9.0/ powerpc: .../releases/powerpc/powerpc/ISO-IMAGES/9.0/ powerpc64: .../releases/powerpc/powerpc64/ISO-IMAGES/9.0/ sparc64: .../releases/sparc64/sparc64/ISO-IMAGES/9.0/ MD5/SHA256 checksums are tacked on below. If you would like to use csup/cvsup mechanisms to access the source tree the branch tag to use is now "RELENG_9_0", if you use "." (head) you will get 10-CURRENT. If you would like to access the source tree via SVN it is "svn://svn.freebsd.org/base/releng/9.0/". We still have the nit that the creation of a new SVN branch winds up causing what looks like a check-in of the entire tree in CVS (a side-effect of the svn2cvs exporter) so "mergemaster -F" is your friend if you are using csup/cvsup. FreeBSD Update -------------- The freebsd-update(8) utility supports binary upgrades of i386 and amd64 sy= stems running earlier FreeBSD releases. Systems running 7.[34]-RELEASE, 8.[12]-RELEASE, 9.0-BETA[123], or 9.0-RC1 can upgrade as follows: First, a minor change must be made to the freebsd-update code in order for it to accept file names appearing in FreeBSD 9.0 which contain the '%' and '@' characters; without this change, freebsd-update will error out with the message "The update metadata is correctly signed, but failed an integrity check". # sed -i '' -e 's/=3D_/=3D%@_/' /usr/sbin/freebsd-update Now freebsd-update can fetch bits belonging to 9.0-RC2. During this proces= s freebsd-update will ask for help in merging configuration files. # freebsd-update upgrade -r 9.0-RC2 Due to changes in the way that FreeBSD is packaged on the release media, tw= o complications may arise in this process if upgrading from FreeBSD 7.x or 8.= x: 1. The FreeBSD kernel, which previously could appear in either /boot/kernel or /boot/GENERIC, now only appears as /boot/kernel. As a result, any kerne= l appearing in /boot/GENERIC will be deleted. Please carefully read the outp= ut printed by freebsd-update and confirm that an updated kernel will be placed into /boot/kernel before proceeding beyond this point. 2. The FreeBSD source tree in /usr/src (if present) will be deleted. (Norm= ally freebsd-update will update a source tree, but in this case the changes in release packaging result in freebsd-update not recognizing that the source = tree from the old release and the source tree from the new release correspond to= the same part of FreeBSD.) # freebsd-update install The system must now be rebooted with the newly installed kernel before the non-kernel components are updated. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install At this point, users of systems being upgraded from FreeBSD 8.2-RELEASE or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install Finally, reboot into 9.0-RC2: # shutdown -r now Checksums: MD5 (FreeBSD-9.0-RC2-amd64-bootonly.iso) =3D 0165f0a2a1141a4c69413ec0c0b7d7= 54 MD5 (FreeBSD-9.0-RC2-amd64-memstick.img) =3D 84713f2f556cdd58aa18e36093525e= 6c MD5 (FreeBSD-9.0-RC2-amd64-dvd1.iso) =3D 59792b2012e6feff6981d3cf58c0b901 MD5 (FreeBSD-9.0-RC2-i386-bootonly.iso) =3D ed3e7b8ac2fdadd2c41c0d5c8b26943= c MD5 (FreeBSD-9.0-RC2-i386-memstick.img) =3D f396728fbd72c61078a7f9511b0c71f= f MD5 (FreeBSD-9.0-RC2-i386-dvd1.iso) =3D cacc9962fa80a6b9a5067c907f127e8b MD5 (FreeBSD-9.0-RC2-ia64-bootonly.iso) =3D faaf6f0c529b8ec59b9d4252ae666dc= 7 MD5 (FreeBSD-9.0-RC2-ia64-memstick) =3D b937883e7634334bef1ddf3eb1e06ffb MD5 (FreeBSD-9.0-RC2-ia64-release.iso) =3D c1f5623734132ea80a9fa2298262884c MD5 (FreeBSD-9.0-RC2-powerpc-bootonly.iso) =3D 35e667deaa7223e0829677c37621= 63d8 MD5 (FreeBSD-9.0-RC2-powerpc-memstick) =3D 01b06227124fc7f9ad224d0512940ea8 MD5 (FreeBSD-9.0-RC2-powerpc-release.iso) =3D 055e06744fa1b8c584cfda8be2352= 462 MD5 (FreeBSD-9.0-RC2-powerpc64-bootonly.iso) =3D 38d240e6cdfd5f986f0690ba12= 56eb0f MD5 (FreeBSD-9.0-RC2-powerpc64-memstick) =3D b820ed78bce87b69a04e9d473c63ec= fc MD5 (FreeBSD-9.0-RC2-powerpc64-release.iso) =3D 44d550342db5090c1d0fb5f6070= 5cb0c MD5 (FreeBSD-9.0-RC2-sparc64-bootonly.iso) =3D 7ffb3dc55bb02506cbc95d0f7a94= edab MD5 (FreeBSD-9.0-RC2-sparc64-dvd1.iso) =3D fe4b87eff3f3cde33c2908b071e45c0f SHA256 (FreeBSD-9.0-RC2-amd64-bootonly.iso) =3D 81daa3aa92b8eb6f1bf0c6196c1= cae138c881fe53dce22b9fbf2f19a8cf30551 SHA256 (FreeBSD-9.0-RC2-amd64-memstick.img) =3D fda9025bb8c3ee8c3a4f8db3a01= 44c669408707eab3dc7c5e2070342e979e33e SHA256 (FreeBSD-9.0-RC2-amd64-dvd1.iso) =3D d7071da7cf440f79a7368f8a8b26ba9= b6e18dcb3785aec83df866ddf576ef418 SHA256 (FreeBSD-9.0-RC2-i386-bootonly.iso) =3D 200ac2b9e950548c873cba93f3b3= c669e529720522897220d6b6dd438f806490 SHA256 (FreeBSD-9.0-RC2-i386-memstick.img) =3D 7888f9ed58da415a7356810c0776= 8587c6d2b5d4734f9ca47c92bfc10dab1b0a SHA256 (FreeBSD-9.0-RC2-i386-dvd1.iso) =3D 41a1e12496ba5a44dba4c6e6cfb27c6d= d5f49fb62378e05c1a61909a4f29d06c SHA256 (FreeBSD-9.0-RC2-ia64-bootonly.iso) =3D 059a05b4e779f94cb221fcb7ce26= 1db13e45092510b1fbeac7e17d5f2f6c7c36 SHA256 (FreeBSD-9.0-RC2-ia64-memstick) =3D 3e9985eb02c0f8cd8e5d84356048a019= c98d9628e5836ca777426a3abec3f83f SHA256 (FreeBSD-9.0-RC2-ia64-release.iso) =3D 49524a249f72ad6a8a21ba1ad0d1e= 738ddc09342c7086cf1a20c08ad06885539 SHA256 (FreeBSD-9.0-RC2-powerpc-bootonly.iso) =3D 3a584930ecfd772defa3d8687= 9c62199b7a15f6e502bf4809a04a3fc8d10e10e SHA256 (FreeBSD-9.0-RC2-powerpc-memstick) =3D 06b2985c278362801e2c454d72a3a= e0f873ad2e050a058e76f7b6da84f2d4812 SHA256 (FreeBSD-9.0-RC2-powerpc-release.iso) =3D 0402cca90eb4123fbf1d5dc46d= 9a36ba08b38c0e7b5e83a3a5c0cd7cd1095124 SHA256 (FreeBSD-9.0-RC2-powerpc64-bootonly.iso) =3D 7510745f1fbd3f1a4e1d7c9= d0fed39f8ea3e2dc37de029e931f06856729e5183 SHA256 (FreeBSD-9.0-RC2-powerpc64-memstick) =3D a29bf56f7461be20b0fd15e6ff7= ed08ea0a2baabcbf04430d337893113d19a68 SHA256 (FreeBSD-9.0-RC2-powerpc64-release.iso) =3D 54b1e14798839ced94863a5f= b95b08c20a46474854effc022602cad018789b98 SHA256 (FreeBSD-9.0-RC2-sparc64-bootonly.iso) =3D 9e08825e9549d330384817296= d832f9e00288357ccd1b2d6cce99d0f656b096b SHA256 (FreeBSD-9.0-RC2-sparc64-dvd1.iso) =3D f53810ff78e4015833e0ac9e81865= c1abd93c622607d14aa2a74b918d2bc469c --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | --=-4X3a6ZpsEuSjvxhdzbe6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk7FUDIACgkQ/G14VSmup/aGgQCcCAytIwLB5y1FwFCmxaO4DoQV PaQAnielWVf9F02a6oRYQWE2qSqgLUw8 =BFfv -----END PGP SIGNATURE----- --=-4X3a6ZpsEuSjvxhdzbe6-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 18:25:10 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58C6C106567B; Thu, 17 Nov 2011 18:25:10 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7B5048FC14; Thu, 17 Nov 2011 18:25:03 +0000 (UTC) Received: by ywe9 with SMTP id 9so2119308ywe.13 for ; Thu, 17 Nov 2011 10:25:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nIfnnM98luUkP9aUadIkLRdF5RrYeoKHv3z5dwmPh5o=; b=ctObwYgcORBdbP+7Z8LQo/ITbO7VC4ToRVJYr7vIVoK2s0HoZx+ePNQXOydkmqJQfN L3zy/Ue746YQMO2zzRBeKXwRSwitgC1SqTBBKbLvz1hL2Zf30Lp1TPbHjWbc/714TRM9 GV+cpEATPkLw40cWHweXjL5u3ng865BmPKdOM= MIME-Version: 1.0 Received: by 10.236.22.136 with SMTP id t8mr11805922yht.30.1321554302698; Thu, 17 Nov 2011 10:25:02 -0800 (PST) Sender: maksim.yevmenkin@gmail.com Received: by 10.100.122.19 with HTTP; Thu, 17 Nov 2011 10:25:02 -0800 (PST) In-Reply-To: <4EC54624.4000409@FreeBSD.org> References: <4EC43ABA.7060407@FreeBSD.org> <4EC4404B.4070008@FreeBSD.org> <4EC531A4.4000803@FreeBSD.org> <4EC53E28.2030609@FreeBSD.org> <4EC54624.4000409@FreeBSD.org> Date: Thu, 17 Nov 2011 10:25:02 -0800 X-Google-Sender-Auth: e7olkSEmUsH0JXy3RYUuiWpWYNQ Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: [RFC] ahci(4) patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 18:25:10 -0000 On Thu, Nov 17, 2011 at 9:36 AM, Alexander Motin wrote: > On 11/17/11 19:02, Alexander Motin wrote: >> On 11/17/11 18:35, Maksim Yevmenkin wrote: >>> On Thu, Nov 17, 2011 at 8:09 AM, Alexander Motin wrot= e: >>>> On 11/17/11 01:08, Maksim Yevmenkin wrote: >>>>> On Wed, Nov 16, 2011 at 2:59 PM, Alexander Motin wr= ote: >>>>>> On 17.11.2011 00:44, Maksim Yevmenkin wrote: >>>>>>> >>>>>>> On Wed, Nov 16, 2011 at 2:35 PM, Alexander Motin = =A0wrote: >>>>>>>> >>>>>>>> On 16.11.2011 23:59, Maksim Yevmenkin wrote: >>>>>>>>> >>>>>>>>> would anyone object to the following ahci(4) patch? >>>>>>>>> >>>>>>>>> =3D=3D >>>>>>>>> >>>>>>>>> --- ahci.c.orig 2011-11-16 21:35:26.000000000 +0000 >>>>>>>>> +++ ahci.c =A0 =A0 =A02011-11-16 21:35:41.000000000 +0000 >>>>>>>>> @@ -500,7 +500,7 @@ >>>>>>>>> =A0 =A0 =A0 =A0for (unit =3D 0; unit< =A0 =A0ctlr->channels; unit= ++) { >>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ((ctlr->ichannels& =A0 =A0(1<< = =A0 =A0unit)) =3D=3D 0) >>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; >>>>>>>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 child =3D device_add_child(dev, "ah= cich", -1); >>>>>>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 child =3D device_add_child(dev, "ah= cich", unit); >>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (child =3D=3D NULL) >>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_printf(dev,= "failed to add channel >>>>>>>>> device\n"); >>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else >>>>>>>>> >>>>>>>>> =3D=3D >>>>>>>>> >>>>>>>>> the idea is to have "static" numbering for ada(4) disks. >>>>>>>> >>>>>>>> I do. The only way I see this useful is if you have BIOS configure= d for >>>>>>>> non-hot-swappable disks, in which case you have some AHCI channels >>>>>>>> disabled, >>>>>>>> but want to keep numbers of the rest. While I don't like this mode= in >>>>>>>> general, especially when it can't be disabled, that patch could be= useful >>>>>>>> in >>>>>>>> these cases. But in other cases, when you have several AHCI contro= llers, >>>>>>>> it >>>>>>>> just wont not work. You will receive error on attempt to create se= cond >>>>>>>> ahcich0. >>>>>>> >>>>>>> shouldn't achcichX be destroyed when disk is detached/removed/etc.? >>>>>> >>>>>> List of implemented AHCI channels to expose as ahcichX set by BIOS i= n >>>>>> vendor-specific way, but only during boot and not by many BIOSes. De= stroying >>>>>> them on disk detach theoretically possible, but IMHO not right, as b= us >>>>>> doesn't disappear on disk disconnect. >>>>>> >>>>>>> the particular problem i'm trying to address is disk re-numbering w= hen >>>>>>> one of the disks fails/removed/etc. i'm trying to use hints to wire >>>>>>> disks to controllers/busses. it works perfectly fine with da(4) dis= ks >>>>>>> (even hot swappable ones) , but i can not make it to work with ada(= 4) >>>>>>> disks. i'm perfectly fine to hid this under some sort of option >>>>>>> (something similar to ATA_STATIC_ID, AHCI_STATIC_ID for example) >>>>>> >>>>>> Wiring works for adaX also, unless your BIOS is so "intelligent" to = report >>>>>> unconnected ports and not impliemented.. You should just wire CAM bu= ses to >>>>>> ahcichX, not to ahciX. It could be done in other way changing just b= y one >>>>>> line around xpt_bus_register(), but now it is done so. >>>>> >>>>> ok. then i must be missing something, here is what i have in device.h= ints >>>>> >>>>> hint.scbus.0.at=3D"umass-sim0" >>>>> hint.scbus.1.at=3D"ahcich0" >>>>> hint.scbus.2.at=3D"ahcich1" >>>>> hint.scbus.3.at=3D"ahcich2" >>>>> hint.scbus.4.at=3D"ahcich3" >>>>> hint.scbus.5.at=3D"ahcich4" >>>>> hint.scbus.6.at=3D"ahcich5" >>>>> >>>>> hint.da.0.at=3D"scbus0" >>>>> hint.ada.0.at=3D"scbus1" >>>>> hint.ada.1.at=3D"scbus2" >>>>> hint.ada.2.at=3D"scbus3" >>>>> hint.ada.3.at=3D"scbus4" >>>>> hint.ada.4.at=3D"scbus5" >>>>> hint.ada.5.at=3D"scbus6" >>>>> >>>>> this is for 6-port ahci(4) compatible controller (intel) on the >>>>> motherboard. no matter which achi(4) ports are connected, resulted >>>>> adaX devices are always sequential starting from ada0. so, the >>>>> question is: what am i doing wrong here? >>>> >>>> Just put your lines into my loader.conf and got this: >>>> >>>> %camcontrol devlist -v >>>> scbus1 on ahcich0 bus 0: >>>> =A0 =A0at scbus1 target 0 lun 0 (pass0= ,ada0) >>>> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at = scbus1 target -1 lun -1 () >>>> scbus2 on ahcich1 bus 0: >>>> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at = scbus2 target -1 lun -1 () >>>> scbus3 on ahcich2 bus 0: >>>> =A0 =A0at scbus3 target 0 lun 0 (pass1= ,ada2) >>>> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at = scbus3 target -1 lun -1 () >>>> scbus4 on ahcich3 bus 0: >>>> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at = scbus4 target -1 lun -1 () >>>> scbus5 on ahcich4 bus 0: >>>> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at = scbus5 target -1 lun -1 () >>>> scbus6 on ahcich5 bus 0: >>>> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at = scbus6 target -1 lun -1 () >>>> ... >>>> >>>> I see no problem. What am I doing wrong? >>>> >>>> Let me repeat question not asked directly: Does your BIOS reports unus= ed >>>> AHCI channels as implemented? Do you always have all 6 ahcich devices = or >>>> not? >>> >>> i not exactly sure. below is the relevant dmesg. as far as i can tell, >>> channels are correct, however, ahcich numbering is sequential and that >>> is why hints dont work. >>> >>> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: >> SATA controller> port >>> 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f >>> mem 0xfbb21000-0xfbb217ff irq 19 at device 31.2 on pci0 >>> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: attempting to allocate 1 >>> MSI vectors (1 supported) >>> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: using IRQ 270 for MSI >>> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: AHCI v1.30 with 6 6Gbps >>> ports, Port Multiplier not supported >>> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: Caps: 64bit NCQ SNTF AL >>> CLO 6Gbps PMD SSC PSC 32cmd EM 6ports >>> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: Caps2: APST >>> Nov 17 09:22:51 PREPROD-red1 kernel: ahci0: EM Caps: ALHD XMT SMB LED >>> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: at >>> channel 0 on ahci0 >>> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich0: Caps: >>> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: at >>> channel 2 on ahci0 >>> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich1: Caps: >>> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: at >>> channel 5 on ahci0 >>> Nov 17 09:22:51 PREPROD-red1 kernel: ahcich2: Caps: >> >> Yes, that's it. You should have six ahcichX devices, but have only three >> - only for connected devices. Some vendors (Supermicro was first I've >> heard about) last time randomly started to make BIOS mark unused AHCI >> channels as unimplemented. Sometimes it can be configured in BIOS setup >> (it may be called like "hot-swappable"), sometimes not. I believe that >> is wrong AHCI spec interpretation. >> >> If it is not configurable in BIOS, we could add respective hint to the >> ahci(4) to allow user ignore these fake "implemented" flags to always >> present all possible ports, but it is direct AHCI spec violation. >> >> Other possible way is to leave ahcichX device as-is, but instead >> register ports in CAM in different fashion -- as buses of the same >> controller. Patch may look like this: >> >> --- ahci.c =A0 =A0 =A0(revision 227580) >> +++ ahci.c =A0 =A0 =A0(working copy) >> @@ -985,8 +985,8 @@ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err1; >> =A0 =A0 =A0 =A0 } >> =A0 =A0 =A0 =A0 /* Construct SIM entry */ >> - =A0 =A0 =A0 ch->sim =3D cam_sim_alloc(ahciaction, ahcipoll, "ahcich", = ch, >> - =A0 =A0 =A0 =A0 =A0 device_get_unit(dev), &ch->mtx, >> + =A0 =A0 =A0 ch->sim =3D cam_sim_alloc(ahciaction, ahcipoll, "ahci", ch= , >> + =A0 =A0 =A0 =A0 =A0 device_get_unit(device_get_parent(dev)), &ch->mtx, >> =A0 =A0 =A0 =A0 =A0 =A0 min(2, ch->numslots), >> =A0 =A0 =A0 =A0 =A0 =A0 (ch->caps & AHCI_CAP_SNCQ) ? ch->numslots : 0, >> =A0 =A0 =A0 =A0 =A0 =A0 devq); >> @@ -996,7 +996,7 @@ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D ENOMEM; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err1; >> =A0 =A0 =A0 =A0 } >> - =A0 =A0 =A0 if (xpt_bus_register(ch->sim, dev, 0) !=3D CAM_SUCCESS) { >> + =A0 =A0 =A0 if (xpt_bus_register(ch->sim, dev, ch->unit) !=3D CAM_SUCC= ESS) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_printf(dev, "unable to register x= pt bus\n"); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 error =3D ENXIO; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err2; >> >> Then output looks that way: >> %camcontrol devlist -v >> scbus1 on ahci0 bus 0: >> =A0 =A0at scbus1 target 0 lun 0 (pass0,a= da0) >> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at sc= bus1 target -1 lun -1 () >> scbus2 on ahci0 bus 1: >> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at sc= bus2 target -1 lun -1 () >> scbus3 on ahci0 bus 2: >> =A0 =A0at scbus3 target 0 lun 0 (pass1,a= da2) >> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at sc= bus3 target -1 lun -1 () >> scbus4 on ahci0 bus 3: >> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at sc= bus4 target -1 lun -1 () >> scbus5 on ahci0 bus 4: >> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at sc= bus5 target -1 lun -1 () >> scbus6 on ahci0 bus 5: >> <> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at sc= bus6 target -1 lun -1 () >> >> But in that case two problems remain: >> =A0- per-port device hints still won't be usable, while changing them wi= ll >> break POLA; >> =A0- it will also break POLA for users who are using wiring now. > > One more idea. We can create ahcichX devices for every AHCI channel, but > disable them for channels marked as not implemented: > > --- ahci.c =A0 =A0 =A0(revision 227580) > +++ ahci.c =A0 =A0 =A0(working copy) > @@ -498,13 +498,14 @@ > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0/* Attach all channels on this controller */ > =A0 =A0 =A0 =A0for (unit =3D 0; unit < ctlr->channels; unit++) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ctlr->ichannels & (1 << unit)) =3D=3D = 0) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0child =3D device_add_child(dev, "ahcich", = -1); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (child =3D=3D NULL) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (child =3D=3D NULL) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_printf(dev, "failed= to add channel > device\n"); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 else > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_set_ivars(child, (vo= id *)(intptr_t)unit); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_set_ivars(child, (void *)(intptr_t)u= nit); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ctlr->ichannels & (1 << unit)) =3D=3D = 0) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_disable(child); > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0bus_generic_attach(dev); > =A0 =A0 =A0 =A0return 0; > > Device disabling is not very used functionality now, but it seems fit > perfectly for this case: > > ahcich0: at channel 0 on ahci0 > ahcich0: Caps: HPCP > ahcich1: not probed (disabled) > ahcich2: at channel 2 on ahci0 > ahcich2: Caps: HPCP > ahcich3: at channel 3 on ahci0 > ahcich3: Caps: HPCP > ahcich4: not probed (disabled) > ahcich5: not probed (disabled) it looks fine as long as i can wire ada(4) disks to prevent re-ordering thanks max From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 18:32:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0E51106566B; Thu, 17 Nov 2011 18:32:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 234488FC19; Thu, 17 Nov 2011 18:32:54 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAHIWn3k016623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2011 20:32:49 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAHIWndK014524; Thu, 17 Nov 2011 20:32:49 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAHIWns1014523; Thu, 17 Nov 2011 20:32:49 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 17 Nov 2011 20:32:49 +0200 From: Kostik Belousov To: Alexander Motin Message-ID: <20111117183249.GY50300@deviant.kiev.zoral.com.ua> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <20111116202714.5ee4bd53@fabiankeil.de> <4EC43764.1020202@FreeBSD.org> <4EC4423A.3020904@FreeBSD.org> <20111117081533.GP50300@deviant.kiev.zoral.com.ua> <4EC4C89A.2040208@FreeBSD.org> <20111117090653.GR50300@deviant.kiev.zoral.com.ua> <4EC4D3DE.8080103@FreeBSD.org> <20111117111405.GT50300@deviant.kiev.zoral.com.ua> <4EC500CD.6040305@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IchbHJI4BusCGQwO" Content-Disposition: inline In-Reply-To: <4EC500CD.6040305@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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-current@freebsd.org, Andriy Gapon Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 18:32:55 -0000 --IchbHJI4BusCGQwO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 17, 2011 at 02:40:45PM +0200, Alexander Motin wrote: > On 11/17/11 13:14, Kostik Belousov wrote: > > On Thu, Nov 17, 2011 at 11:29:02AM +0200, Alexander Motin wrote: > >> On 11/17/11 11:06, Kostik Belousov wrote: > >>> On Thu, Nov 17, 2011 at 10:40:58AM +0200, Alexander Motin wrote: > >>>> On 11/17/11 10:15, Kostik Belousov wrote: > >>>>> On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote: > >>>>>> On 17.11.2011 00:21, Andriy Gapon wrote: > >>>>>>> on 16/11/2011 21:27 Fabian Keil said the following: > >>>>>>>> Kostik Belousov wrote: > >>>>>>>> > >>>>>>>>> I was tricked into finishing the work by Andrey Gapon, who deve= loped > >>>>>>>>> the patch to reliably stop other processors on panic. The patch > >>>>>>>>> greatly improves the chances of getting dump on panic on SMP ho= st. > >>>>>>>> > >>>>>>>> I tested the patch trying to get a dump (from the debugger) for > >>>>>>>> kern/162036, which currently results in the double fault reporte= d in: > >>>>>>>> http://lists.freebsd.org/pipermail/freebsd-current/2011-Septembe= r/027766.html > >>>>>>>> > >>>>>>>> It didn't help, but also didn't make anything worse. > >>>>>>>> > >>>>>>>> Fabian > >>>>>>> > >>>>>>> The mi_switch recursion looks very familiar to me: > >>>>>>> mi_switch() at mi_switch+0x270 > >>>>>>> critical_exit() at critical_exit+0x9b > >>>>>>> spinlock_exit() at spinlock_exit+0x17 > >>>>>>> mi_switch() at mi_switch+0x275 > >>>>>>> critical_exit() at critical_exit+0x9b > >>>>>>> spinlock_exit() at spinlock_exit+0x17 > >>>>>>> [several pages of the previous three lines skipped] > >>>>>>> mi_switch() at mi_switch+0x275 > >>>>>>> critical_exit() at critical_exit+0x9b > >>>>>>> spinlock_exit() at spinlock_exit+0x17 > >>>>>>> intr_even_schedule_thread() at intr_event_schedule_thread+0xbb > >>>>>>> ahci_end_transaction() at ahci_end_transaction+0x398 > >>>>>>> ahci_ch_intr() at ahci_ch_intr+0x2b5 > >>>>>>> ahcipoll() at ahcipoll+0x15 > >>>>>>> xpt_polled_action() at xpt_polled_action+0xf7 > >>>>>>> > >>>>>>> In fact I once discussed with jhb this recursion triggered from a= different > >>>>>>> place. To quote myself: > >>>>>>> spinlock_exit -> critical_exit -> mi_switch -> kdb_sw= itch -> > >>>>>>> thread_unlock -> spinlock_exit -> critical_exit -> mi_switch -= > ... > >>>>>>> in the kdb context > >>>>>>> this issue seems to be triggered by td_owepreempt being = true at=20 > >>>>>>> the time > >>>>>>> kdb is entered > >>>>>>> and there of course has to be an initial spinlock_exit c= all=20 > >>>>>>> somewhere > >>>>>>> in my case it's because of usb keyboard > >>>>>>> I wonder if it would make sense to clear td_owepreempt r= ight=20 > >>>>>>> before > >>>>>>> calling kdb_switch in mi_switch > >>>>>>> instead of in sched_switch() > >>>>>>> clearing td_owepreempt seems like a scheduler-independen= t=20 > >>>>>>> operation to me > >>>>>>> or is it better to just skip locking in usb when kdb_act= ive is set > >>>>>>> ? > >>>>>>> > >>>>>>> The workaround described above should work in this case. > >>>>>>> Another possibility is to pessimize mtx_unlock_spin() implementat= ions to=20 > >>>>>>> check > >>>>>>> SCHEDULER_STOPPED() and to bypass any further actions in that cas= e. But=20 > >>>>>>> that > >>>>>>> would add unnecessary overhead to the sunny day code paths. > >>>>>>> > >>>>>>> Going further up the stack one can come up with the following pro= posals: > >>>>>>> - check SCHEDULER_STOPPED() swi_sched() and return early > >>>>>>> - do not call swi_sched() from xpt_done() if we somehow know that= we are=20 > >>>>>>> in a > >>>>>>> polling mode > >>>>>> > >>>>>> There is no flag in CAM now to indicate polling mode, but if neede= d, it=20 > >>>>>> should not be difficult to add one and not call swi_sched(). > >>>>> > >>>>> I have the following change for eons on my test boxes. Without it, > >>>>> I simply cannot get _any_ dump. > >>>>> > >>>>> diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c > >>>>> index 10b89c7..a38e42f 100644 > >>>>> --- a/sys/cam/cam_xpt.c > >>>>> +++ b/sys/cam/cam_xpt.c > >>>>> @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) > >>>>> TAILQ_INSERT_TAIL(&cam_simq, sim, links); > >>>>> mtx_unlock(&cam_simq_lock); > >>>>> sim->flags |=3D CAM_SIM_ON_DONEQ; > >>>>> - if (first) > >>>>> + if (first && panicstr =3D=3D NULL) > >>>>> swi_sched(cambio_ih, 0); > >>>>> } > >>>>> } > >>>> > >>>> That should be OK for kernel dumping. I was thinking about CAM abusi= ng > >>>> polling not only for dumping. But looking on cases where it does it = now, > >>>> may be it is better to rewrite them instead. > >>> > >>> So, should I interpret your response as 'Reviewed by" ? > >> > >> It feels somehow dirty to me. I don't like these global variables. If > >> you consider it is fine, proceed, I see no much harm. But if not, I can > >> add polling flag to the CAM. Flip a coin for me. :) > > You promised to add the polling at summer' meeting in Kiev. Will you do > > it now ? >=20 > Sorry, I've probably forgot. The patch is attached. >=20 > --=20 > Alexander Motin > Index: cam_sim.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- cam_sim.h (revision 227580) > +++ cam_sim.h (working copy) > @@ -104,7 +104,8 @@ > u_int32_t flags; > #define CAM_SIM_REL_TIMEOUT_PENDING 0x01 > #define CAM_SIM_MPSAFE 0x02 > -#define CAM_SIM_ON_DONEQ 0x04 > +#define CAM_SIM_ON_DONEQ 0x04 > +#define CAM_SIM_POLLED 0x08 > struct callout callout; > struct cam_devq *devq; /* Device Queue to use for this SIM */ > int refcount; /* References to the SIM. */ > Index: cam_xpt.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- cam_xpt.c (revision 227580) > +++ cam_xpt.c (working copy) > @@ -2957,6 +2957,9 @@ > =20 > mtx_assert(sim->mtx, MA_OWNED); > =20 > + /* Don't use ISR for this SIM while polling. */ > + sim->flags |=3D CAM_SIM_POLLED; > + > /* > * Steal an opening so that no other queued requests > * can get it before us while we simulate interrupts. > @@ -2996,6 +2999,9 @@ > } else { > start_ccb->ccb_h.status =3D CAM_RESRC_UNAVAIL; > } > + > + /* Use CAM ISR for this SIM again. */ > + sim->flags &=3D ~CAM_SIM_POLLED; > } > =20 > /* > @@ -4224,7 +4230,7 @@ > TAILQ_INSERT_TAIL(&sim->sim_doneq, &done_ccb->ccb_h, > sim_links.tqe); > done_ccb->ccb_h.pinfo.index =3D CAM_DONEQ_INDEX; > - if ((sim->flags & CAM_SIM_ON_DONEQ) =3D=3D 0) { > + if ((sim->flags & (CAM_SIM_ON_DONEQ | CAM_SIM_POLLED)) =3D=3D 0) { > mtx_lock(&cam_simq_lock); > first =3D TAILQ_EMPTY(&cam_simq); > TAILQ_INSERT_TAIL(&cam_simq, sim, links); Seems it worked for me, on the same machine where I absolutely needed my change before. Thanks. --IchbHJI4BusCGQwO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7FU1AACgkQC3+MBN1Mb4jT+wCgqyLadu1mCsiDNz2unAyGpj7d QdQAn2SSW/UurJ5yPhQhRZkz7XzwCQWs =KguT -----END PGP SIGNATURE----- --IchbHJI4BusCGQwO-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 18:36:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10B41106566C for ; Thu, 17 Nov 2011 18:36:45 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id EC8758FC0C for ; Thu, 17 Nov 2011 18:36:43 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp026.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LUT000SXID2BU40@asmtp026.mac.com> for freebsd-current@freebsd.org; Thu, 17 Nov 2011 10:36:39 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2011-11-17_08:2011-11-17, 2011-11-17, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1111170195 From: Chuck Swiger In-reply-to: Date: Thu, 17 Nov 2011 10:36:37 -0800 Message-id: <618E8CA8-84B2-4FA8-A13E-978004FD68E8@mac.com> References: To: Dan The Man X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: spamcop abuse of power X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 18:36:45 -0000 On Nov 17, 2011, at 5:37 AM, Dan The Man wrote: > Today I had an unhappy unix student try to submit an assignment to me and could not. Spamcop has decided to go off blacklisting all yahoo/shaw etc servers worldwide. I'm seeing about 40 spams per month from Yahoo's *.bullet.mail.sp2.yahoo.com; they're almost certainly the single largest source of spammy email I get. > Example Solution Postfix: > remove: reject_rbl_client bl.spamcop.net > from your smtpd_recipient_restrictions line until they fix their abuse issues. I probably wouldn't use any RBL for pass/fail blocking-- aside from postmaster.rfc-ignorant.org, maybe, and even that one likely needs some whitelisting if your mail system has a non-trivial # of users-- instead, consider using RBLs for scoring. Regards, -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 18:52:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B28B81065670; Thu, 17 Nov 2011 18:52:16 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1DA778FC1C; Thu, 17 Nov 2011 18:52:15 +0000 (UTC) Received: by vcbfy13 with SMTP id fy13so2216202vcb.13 for ; Thu, 17 Nov 2011 10:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=23aUTagf/uZwyU+yHYhmB/dgdoUCL6o/Umb5hlKi1U4=; b=DQBYI+MRTHapw7MEY5L7p29KPbgjppVHpW4fBoOykecyrB15UBmdT88GCq2KRWWAgr /yXBepdo2fVttXaxYsUgfm2zRwm+j9dPTkoEIl5rt69CTjJgknogkqap6+Qhmh40a/kV mISOQKnDx68CH6bboJqhpwepFVwZzht2cM4IY= MIME-Version: 1.0 Received: by 10.52.97.10 with SMTP id dw10mr25266393vdb.51.1321555934406; Thu, 17 Nov 2011 10:52:14 -0800 (PST) Received: by 10.52.156.135 with HTTP; Thu, 17 Nov 2011 10:52:14 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Nov 2011 19:52:14 +0100 Message-ID: From: Davide Italiano To: Paul Ambrose Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Attilio Rao , George Neville-Neil , freebsd-current@freebsd.org, Fabien Thomas Subject: Re: [PATCH] Intel Sandy Bridge support for hwpmc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 18:52:16 -0000 On Tue, Nov 15, 2011 at 3:44 AM, Paul Ambrose wrote: > hi, I apply your patch on this > [root@capoor-daemon /usr/src]# git show > commit 4ec1d958bad5e78bcd3cc61a0da6b5a1302f8ec2 > Author: kensmith > Date: =A0 Mon Nov 14 00:45:25 2011 +0000 > > =A0 =A0The releng/9.0 release branch has been created so convert stable/9= over > =A0 =A0to our standard "Politically Correct" name for the balance of the > 9.0-RELEASE > =A0 =A0release cycle. > > =A0 =A0Approved by: =A0 =A0 =A0 =A0re (implicit) > > when my machine shutdown in my absence yesterday evening, I find a > kernel oops this morning,(sorry, just printf, I can not get a kernel > dump) > the kernel says it is at uncore_pcpu_fini+0x5b > I check the source, and it is at > static int > uncore_pcpu_fini(struct pmc_mdep *md, int cpu) > { > ..... > =A0 =A0 =A0 =A0for (n =3D 0; n < npmc; n++) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wrmsr(UCP_EVSEL0 + n, 0); //here > ..... > here is my cpu type, and build hwpmc into kernel > > Copyright (c) 1992-2011 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > =A0 =A0 =A0 =A0The Regents of the University of California. All rights re= served. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-PRERELEASE #0 r+4ec1d95-dirty: Mon Nov 14 15:31:45 CST 2011 > =A0 =A0root@capoor-daemon:/usr/obj/usr/src/sys/MYKERNEL amd64 > CPU: Intel(R) Core(TM) i5-2300 CPU @ 2.80GHz (2793.02-MHz K8-class CPU) > > I will try to apply this to current to see if this is reproduced. > > 2011/11/14 Attilio Rao : >> 2011/11/13 Davide Italiano : >>> On Sun, Nov 13, 2011 at 9:52 PM, Davide Italiano >>> wrote: >>>> Good evening folks. >>>> During last days I've written a patch to add sandy bridge support to >>>> hwpmc. Until now, the most recent Intel processor microarchitecture >>>> supported was Westmere. >>>> Testing is appreciated, in order to see if there's something that have >>>> to be fixed. >>>> You can find the diff here: http://davit.altervista.rg/hwpmc_sandy_bri= dge.diff >>>> >>>> I'd like to thanks a lot attilio@ that helped me to fix a bug and gnn@ >>>> and fabient@ for the useful suggestions. >>>> >>>> Best >>>> >>>> Davide >>>> >>> >>> Sorry, bad link. It should be: >>> http://davit.altervista.org/hwpmc_sandy_bridge.diff >> >> I can perform some small cleanups and likely test it too. >> >> If Fabien or George can review it I'm fine with committing as long as >> all that is settled. >>+ >> Attilio >> >> >> -- >> Peace can only be achieved by understanding - A. Einstein >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >> > Have you tried on -current? If yes, what are the results? Can you provide a kernel dump and/or the instruction to reproduce this bug? Best Davide From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 19:02:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A64B106566B; Thu, 17 Nov 2011 19:02:04 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id EAA148FC0C; Thu, 17 Nov 2011 19:02:02 +0000 (UTC) Received: by iakl21 with SMTP id l21so3645416iak.13 for ; Thu, 17 Nov 2011 11:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8LwgUESB/Z7RfXwnSrQ7hBbBfbrOQZxR/t8gOgpcY2U=; b=WgihhmTattVPMjmNKoYt8jyHq/aXZmm7agj45g3VTjHas9UMCdFlRCul2aivCXoZIA 7MFPEiMw6lJv0uu699fyO0rEnnND+qTg/KpFBAwkfWUofzfie6xktEwWlP3+EpwO2J+P fLiHxNVGLvHwLKJ31DvIbZYuP3dDwp1knrnL8= MIME-Version: 1.0 Received: by 10.42.96.132 with SMTP id j4mr103194icn.50.1321556522642; Thu, 17 Nov 2011 11:02:02 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.243.198 with HTTP; Thu, 17 Nov 2011 11:02:02 -0800 (PST) In-Reply-To: <201111170959.56767.jhb@freebsd.org> References: <201111170959.56767.jhb@freebsd.org> Date: Thu, 17 Nov 2011 20:02:02 +0100 X-Google-Sender-Auth: aY09Fz8sb6SxrRzTrLVeJbcrTAg Message-ID: From: Robert Millan To: John Baldwin Content-Type: multipart/mixed; boundary=20cf303ea614152c2d04b1f2db2b Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, Warner Losh , freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 19:02:04 -0000 --20cf303ea614152c2d04b1f2db2b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2011/11/17 John Baldwin : > I recall the discussion from earlier. =C2=A0I can't recall if I had repli= ed to it > though. :-/ =C2=A0In my current opinion, I think it would be fine to defi= ne > __FreeBSD_kernel__ on FreeBSD and to do it in for now until= all > the compilers we use have been updated to define it automatically (which = may > be a long time). =C2=A0I think it will also be fine to patch in-system he= aders to > use __FreeBSD_kernel__ once is defined. =C2=A0Unfortunately= headers > in 3rd party software are going to have to check for both __FreeBSD__ and > __FreeBSD_kernel__ to support both GNU/kFreeBSD and older FreeBSD for the > foreseeable future. =C2=A0I think that is fine, but that the sooner we ad= d > __FreeBSD_kernel__ on FreeBSD the sooner we get the clock started for a d= ay > when those extra checks can go away. =C2=A0I would also be fine with MFC'= ing the > addition of __FreeBSD_kernel__ to older branches (at least 7 - 9) as well= . Well, here's a patch then. I wrote a comment in it trying to explain the situation. Please let me know what you think. --20cf303ea614152c2d04b1f2db2b Content-Type: text/x-diff; charset=US-ASCII; name="freebsd_kernel.diff" Content-Disposition: attachment; filename="freebsd_kernel.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gv44mibq0 SW5kZXg6IHN5cy9zeXMvcGFyYW0uaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvc3lzL3BhcmFtLmgJKHJl dmlzaW9uIDIyNzU4MCkKKysrIHN5cy9zeXMvcGFyYW0uaAkod29ya2luZyBjb3B5KQpAQCAtNjAs NiArNjAsMjMgQEAKICN1bmRlZiBfX0ZyZWVCU0RfdmVyc2lvbgogI2RlZmluZSBfX0ZyZWVCU0Rf dmVyc2lvbiAxMDAwMDAxCS8qIE1hc3RlciwgcHJvcGFnYXRlZCB0byBuZXd2ZXJzICovCiAKKy8q CisgKiBfX0ZyZWVCU0Rfa2VybmVsX18gaW5kaWNhdGVzIHRoYXQgdGhpcyBzeXN0ZW0gdXNlcyB0 aGUga2VybmVsIG9mIEZyZWVCU0QsCisgKiB3aGljaCBieSBkZWZpbml0aW9uIGlzIGFsd2F5cyB0 cnVlIG9uIEZyZWVCU0QgOi0pLiBUaGlzIG1hY3JvIG1heSBhbHNvCisgKiBiZSBkZWZpbmVkIG9u IG90aGVyIHN5c3RlbXMgdGhhdCB1c2UgdGhlIGtlcm5lbCBvZiBGcmVlQlNELCBzdWNoIGFzCisg KiBHTlUva0ZyZWVCU0QuCisgKgorICogSXQgaXMgdGVtcHRpbmcgdG8gdXNlIHRoaXMgbWFjcm8g aW4gdXNlcmxhbmQgY29kZSB3aGVuIHdlIHdhbnQgdG8gZW5hYmxlCisgKiBrZXJuZWwtc3BlY2lm aWMgcm91dGluZXMsIGFuZCBpbiBmYWN0IGl0J3MgZmluZSB0byBkbyB0aGlzIGluIGNvZGUgdGhh dAorICogaXMgcGFydCBvZiBGcmVlQlNEIGl0c2VsZi4gIEhvd2V2ZXIsIGJlIGF3YXJlIHRoYXQg YXMgcHJlc2VuY2Ugb2YgdGhpcworICogbWFjcm8gaXMgc3RpbGwgbm90IHdpZGVzcHJlYWQgKGUu Zy4gb2xkZXIgRnJlZUJTRCB2ZXJzaW9ucywgM3JkIHBhcnR5CisgKiBjb21waWxlcnMsIGV0Yyks IGl0IGlzIFNUUk9OR0xZIERJU0NPVVJBR0VEIHRvIGNoZWNrIGZvciB0aGlzIG1hY3JvIGluCisg KiBleHRlcm5hbCBhcHBsaWNhdGlvbnMgd2l0aG91dCBhbHNvIGNoZWNraW5nIGZvciBfX0ZyZWVC U0RfXyBhcyBhbgorICogYWx0ZXJuYXRpdmUuCisgKi8KKyN1bmRlZiBfX0ZyZWVCU0Rfa2VybmVs X18KKyNkZWZpbmUgX19GcmVlQlNEX2tlcm5lbF9fIF9fRnJlZUJTRF9fCisKICNpZmRlZiBfS0VS TkVMCiAjZGVmaW5lCVBfT1NSRUxfU0lHV0FJVAkJNzAwMDAwCiAjZGVmaW5lCVBfT1NSRUxfU0lH U0VHVgkJNzAwMDA0Cg== --20cf303ea614152c2d04b1f2db2b-- From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 19:16:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF8E2106566B; Thu, 17 Nov 2011 19:16:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1FF8FC0A; Thu, 17 Nov 2011 19:16:49 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0585946B09; Thu, 17 Nov 2011 14:16:49 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8EFAF8A051; Thu, 17 Nov 2011 14:16:48 -0500 (EST) From: John Baldwin To: Andriy Gapon Date: Thu, 17 Nov 2011 14:09:37 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111171137.18663.jhb@freebsd.org> <4EC53D1B.4000308@FreeBSD.org> In-Reply-To: <4EC53D1B.4000308@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111171409.37629.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 17 Nov 2011 14:16:48 -0500 (EST) Cc: Kostik Belousov , Alexander Motin , freebsd-current@freebsd.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 19:16:49 -0000 On Thursday, November 17, 2011 11:58:03 am Andriy Gapon wrote: > on 17/11/2011 18:37 John Baldwin said the following: > > On Thursday, November 17, 2011 4:47:42 am Andriy Gapon wrote: > >> on 17/11/2011 10:34 Andriy Gapon said the following: > >>> on 17/11/2011 10:15 Kostik Belousov said the following: > >>>> I have the following change for eons on my test boxes. Without it, > >>>> I simply cannot get _any_ dump. > >>>> > >>>> diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c > >>>> index 10b89c7..a38e42f 100644 > >>>> --- a/sys/cam/cam_xpt.c > >>>> +++ b/sys/cam/cam_xpt.c > >>>> @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) > >>>> TAILQ_INSERT_TAIL(&cam_simq, sim, links); > >>>> mtx_unlock(&cam_simq_lock); > >>>> sim->flags |= CAM_SIM_ON_DONEQ; > >>>> - if (first) > >>>> + if (first && panicstr == NULL) > >>>> swi_sched(cambio_ih, 0); > >>>> } > >>>> } > >>> > >>> I think that this (or similar) change should go into the patch and the tree. > >>> > >> > >> And, BTW, I still would like to do something like the following (perhaps with > >> td_oncpu = NOCPU and td_flags &= ~TDF_NEEDRESCHED also moved to the common code): > >> > >> Index: sys/kern/sched_ule.c > >> =================================================================== > >> --- sys/kern/sched_ule.c (revision 227608) > >> +++ sys/kern/sched_ule.c (working copy) > >> @@ -1790,7 +1790,6 @@ sched_switch(struct thread *td, struct thread *new > >> td->td_oncpu = NOCPU; > >> if (!(flags & SW_PREEMPT)) > >> td->td_flags &= ~TDF_NEEDRESCHED; > >> - td->td_owepreempt = 0; > >> tdq->tdq_switchcnt++; > >> /* > >> * The lock pointer in an idle thread should never change. Reset it > >> Index: sys/kern/kern_synch.c > >> =================================================================== > >> --- sys/kern/kern_synch.c (revision 227608) > >> +++ sys/kern/kern_synch.c (working copy) > >> @@ -406,6 +406,8 @@ mi_switch(int flags, struct thread *newtd) > >> ("mi_switch: switch must be voluntary or involuntary")); > >> KASSERT(newtd != curthread, ("mi_switch: preempting back to ourself")); > >> > >> + td->td_owepreempt = 0; > >> + > >> /* > >> * Don't perform context switches from the debugger. > >> */ > >> Index: sys/kern/sched_4bsd.c > >> =================================================================== > >> --- sys/kern/sched_4bsd.c (revision 227608) > >> +++ sys/kern/sched_4bsd.c (working copy) > >> @@ -940,7 +940,6 @@ sched_switch(struct thread *td, struct thread *new > >> td->td_lastcpu = td->td_oncpu; > >> if (!(flags & SW_PREEMPT)) > >> td->td_flags &= ~TDF_NEEDRESCHED; > >> - td->td_owepreempt = 0; > >> td->td_oncpu = NOCPU; > >> > >> /* > >> > >> Does anybody see any potential problems with such a change? > > > > Hmm, does this mean the preemption will be lost if you break into the > > debugger and continue in the non-panic case? > > Not sure which exact scenario you have in mind. > Please note that the above diff just moves resetting of td_owepreempt to an > earlier place. As far as I can see there are no checks of td_owepreempt value > between the new place and the old places. I'm worried that you are clearing td_owepreempt even in cases where a context switch is not performed. So say you enter DDB with td_owepreempt set and that DDB bails on a context switch. With your change it will now clear td_owepreempt and "lose" the preemption. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 19:42:57 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05982106564A; Thu, 17 Nov 2011 19:42:57 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D5D0C8FC13; Thu, 17 Nov 2011 19:42:55 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA22942; Thu, 17 Nov 2011 21:42:54 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RR7rK-000C6b-2G; Thu, 17 Nov 2011 21:42:54 +0200 Message-ID: <4EC563BB.60209@FreeBSD.org> Date: Thu, 17 Nov 2011 21:42:51 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: John Baldwin References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111171137.18663.jhb@freebsd.org> <4EC53D1B.4000308@FreeBSD.org> <201111171409.37629.jhb@freebsd.org> In-Reply-To: <201111171409.37629.jhb@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Alexander Motin , freebsd-current@FreeBSD.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 19:42:57 -0000 on 17/11/2011 21:09 John Baldwin said the following: > On Thursday, November 17, 2011 11:58:03 am Andriy Gapon wrote: >> on 17/11/2011 18:37 John Baldwin said the following: >>> On Thursday, November 17, 2011 4:47:42 am Andriy Gapon wrote: >>>> on 17/11/2011 10:34 Andriy Gapon said the following: >>>>> on 17/11/2011 10:15 Kostik Belousov said the following: >>>>>> I have the following change for eons on my test boxes. Without it, >>>>>> I simply cannot get _any_ dump. >>>>>> >>>>>> diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c >>>>>> index 10b89c7..a38e42f 100644 >>>>>> --- a/sys/cam/cam_xpt.c >>>>>> +++ b/sys/cam/cam_xpt.c >>>>>> @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) >>>>>> TAILQ_INSERT_TAIL(&cam_simq, sim, links); >>>>>> mtx_unlock(&cam_simq_lock); >>>>>> sim->flags |= CAM_SIM_ON_DONEQ; >>>>>> - if (first) >>>>>> + if (first && panicstr == NULL) >>>>>> swi_sched(cambio_ih, 0); >>>>>> } >>>>>> } >>>>> >>>>> I think that this (or similar) change should go into the patch and the tree. >>>>> >>>> >>>> And, BTW, I still would like to do something like the following (perhaps with >>>> td_oncpu = NOCPU and td_flags &= ~TDF_NEEDRESCHED also moved to the common code): >>>> >>>> Index: sys/kern/sched_ule.c >>>> =================================================================== >>>> --- sys/kern/sched_ule.c (revision 227608) >>>> +++ sys/kern/sched_ule.c (working copy) >>>> @@ -1790,7 +1790,6 @@ sched_switch(struct thread *td, struct thread *new >>>> td->td_oncpu = NOCPU; >>>> if (!(flags & SW_PREEMPT)) >>>> td->td_flags &= ~TDF_NEEDRESCHED; >>>> - td->td_owepreempt = 0; >>>> tdq->tdq_switchcnt++; >>>> /* >>>> * The lock pointer in an idle thread should never change. Reset it >>>> Index: sys/kern/kern_synch.c >>>> =================================================================== >>>> --- sys/kern/kern_synch.c (revision 227608) >>>> +++ sys/kern/kern_synch.c (working copy) >>>> @@ -406,6 +406,8 @@ mi_switch(int flags, struct thread *newtd) >>>> ("mi_switch: switch must be voluntary or involuntary")); >>>> KASSERT(newtd != curthread, ("mi_switch: preempting back to ourself")); >>>> >>>> + td->td_owepreempt = 0; >>>> + >>>> /* >>>> * Don't perform context switches from the debugger. >>>> */ >>>> Index: sys/kern/sched_4bsd.c >>>> =================================================================== >>>> --- sys/kern/sched_4bsd.c (revision 227608) >>>> +++ sys/kern/sched_4bsd.c (working copy) >>>> @@ -940,7 +940,6 @@ sched_switch(struct thread *td, struct thread *new >>>> td->td_lastcpu = td->td_oncpu; >>>> if (!(flags & SW_PREEMPT)) >>>> td->td_flags &= ~TDF_NEEDRESCHED; >>>> - td->td_owepreempt = 0; >>>> td->td_oncpu = NOCPU; >>>> >>>> /* >>>> >>>> Does anybody see any potential problems with such a change? >>> >>> Hmm, does this mean the preemption will be lost if you break into the >>> debugger and continue in the non-panic case? >> >> Not sure which exact scenario you have in mind. >> Please note that the above diff just moves resetting of td_owepreempt to an >> earlier place. As far as I can see there are no checks of td_owepreempt value >> between the new place and the old places. > > I'm worried that you are clearing td_owepreempt even in cases where a context > switch is not performed. So say you enter DDB with td_owepreempt set and that > DDB bails on a context switch. With your change it will now clear td_owepreempt > and "lose" the preemption. > And without the change we get the recursion and double-fault because of kdb_switch -> thread_unlock -> spinlock_exit -> critical_exit -> mi_switch in this case ? BTW, it is my opinion that we really should not let the debugger code call mi_switch for any reason. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 19:51:20 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFF43106566B for ; Thu, 17 Nov 2011 19:51:20 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 20CEF8FC08 for ; Thu, 17 Nov 2011 19:51:19 +0000 (UTC) Received: from [IPv6:2001:470:28:140:e8a7:587b:e87a:a0ec] ([IPv6:2001:470:28:140:e8a7:587b:e87a:a0ec]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.5) with ESMTP id pAHJpEV9036107 for ; Thu, 17 Nov 2011 21:51:14 +0200 (EET) (envelope-from universite@ukr.net) Message-ID: <4EC565A0.8090708@ukr.net> Date: Thu, 17 Nov 2011 21:50:56 +0200 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Thu, 17 Nov 2011 21:51:14 +0200 (EET) X-Spam-Status: No, score=-94.3 required=5.0 tests=FREEMAIL_FROM,RDNS_NONE, SPF_SOFTFAIL, TO_NO_BRKTS_DIRECT, T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua Cc: Subject: Why not on the ftp fresh snapshot iso? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 19:51:20 -0000 I'm interested in 8.2 (August-September) and 9.0 (beta) for amd64. Where to download their iso? -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 19:55:20 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A37E0106566C; Thu, 17 Nov 2011 19:55:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2A4268FC0C; Thu, 17 Nov 2011 19:55:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHJtJ1h028604; Thu, 17 Nov 2011 14:55:19 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHJtJj5028599; Thu, 17 Nov 2011 19:55:19 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 19:55:19 GMT Message-Id: <201111171955.pAHJtJj5028599@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 19:55:20 -0000 TB --- 2011-11-17 18:10:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 18:10:01 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-17 18:10:01 - cleaning the object tree TB --- 2011-11-17 18:10:26 - cvsupping the source tree TB --- 2011-11-17 18:10:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-17 18:11:12 - building world TB --- 2011-11-17 18:11:12 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 18:11:12 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 18:11:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 18:11:12 - SRCCONF=/dev/null TB --- 2011-11-17 18:11:12 - TARGET=arm TB --- 2011-11-17 18:11:12 - TARGET_ARCH=arm TB --- 2011-11-17 18:11:12 - TZ=UTC TB --- 2011-11-17 18:11:12 - __MAKE_CONF=/dev/null TB --- 2011-11-17 18:11:12 - cd /src TB --- 2011-11-17 18:11:12 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 18:11:12 UTC 2011 >>> 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 Thu Nov 17 19:06:31 UTC 2011 TB --- 2011-11-17 19:06:31 - cd /src/sys/arm/conf TB --- 2011-11-17 19:06:31 - /usr/sbin/config -m AVILA TB --- 2011-11-17 19:06:31 - building AVILA kernel TB --- 2011-11-17 19:06:31 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:06:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:06:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:06:31 - SRCCONF=/dev/null TB --- 2011-11-17 19:06:31 - TARGET=arm TB --- 2011-11-17 19:06:31 - TARGET_ARCH=arm TB --- 2011-11-17 19:06:31 - TZ=UTC TB --- 2011-11-17 19:06:31 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:06:31 - cd /src TB --- 2011-11-17 19:06:31 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Thu Nov 17 19:06:31 UTC 2011 >>> 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 >>> Kernel build for AVILA completed on Thu Nov 17 19:09:34 UTC 2011 TB --- 2011-11-17 19:09:34 - cd /src/sys/arm/conf TB --- 2011-11-17 19:09:34 - /usr/sbin/config -m BWCT TB --- 2011-11-17 19:09:35 - building BWCT kernel TB --- 2011-11-17 19:09:35 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:09:35 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:09:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:09:35 - SRCCONF=/dev/null TB --- 2011-11-17 19:09:35 - TARGET=arm TB --- 2011-11-17 19:09:35 - TARGET_ARCH=arm TB --- 2011-11-17 19:09:35 - TZ=UTC TB --- 2011-11-17 19:09:35 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:09:35 - cd /src TB --- 2011-11-17 19:09:35 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Thu Nov 17 19:09:35 UTC 2011 >>> 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 >>> Kernel build for BWCT completed on Thu Nov 17 19:12:13 UTC 2011 TB --- 2011-11-17 19:12:13 - cd /src/sys/arm/conf TB --- 2011-11-17 19:12:13 - /usr/sbin/config -m CAMBRIA TB --- 2011-11-17 19:12:13 - building CAMBRIA kernel TB --- 2011-11-17 19:12:13 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:12:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:12:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:12:13 - SRCCONF=/dev/null TB --- 2011-11-17 19:12:13 - TARGET=arm TB --- 2011-11-17 19:12:13 - TARGET_ARCH=arm TB --- 2011-11-17 19:12:13 - TZ=UTC TB --- 2011-11-17 19:12:13 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:12:13 - cd /src TB --- 2011-11-17 19:12:13 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Thu Nov 17 19:12:13 UTC 2011 >>> 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 >>> Kernel build for CAMBRIA completed on Thu Nov 17 19:15:10 UTC 2011 TB --- 2011-11-17 19:15:10 - cd /src/sys/arm/conf TB --- 2011-11-17 19:15:10 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-11-17 19:15:11 - building CNS11XXNAS kernel TB --- 2011-11-17 19:15:11 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:15:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:15:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:15:11 - SRCCONF=/dev/null TB --- 2011-11-17 19:15:11 - TARGET=arm TB --- 2011-11-17 19:15:11 - TARGET_ARCH=arm TB --- 2011-11-17 19:15:11 - TZ=UTC TB --- 2011-11-17 19:15:11 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:15:11 - cd /src TB --- 2011-11-17 19:15:11 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Thu Nov 17 19:15:11 UTC 2011 >>> 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 >>> Kernel build for CNS11XXNAS completed on Thu Nov 17 19:17:41 UTC 2011 TB --- 2011-11-17 19:17:41 - cd /src/sys/arm/conf TB --- 2011-11-17 19:17:41 - /usr/sbin/config -m CRB TB --- 2011-11-17 19:17:41 - building CRB kernel TB --- 2011-11-17 19:17:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:17:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:17:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:17:41 - SRCCONF=/dev/null TB --- 2011-11-17 19:17:41 - TARGET=arm TB --- 2011-11-17 19:17:41 - TARGET_ARCH=arm TB --- 2011-11-17 19:17:41 - TZ=UTC TB --- 2011-11-17 19:17:41 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:17:41 - cd /src TB --- 2011-11-17 19:17:41 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Thu Nov 17 19:17:41 UTC 2011 >>> 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 >>> Kernel build for CRB completed on Thu Nov 17 19:21:31 UTC 2011 TB --- 2011-11-17 19:21:31 - cd /src/sys/arm/conf TB --- 2011-11-17 19:21:31 - /usr/sbin/config -m DB-78XXX TB --- 2011-11-17 19:21:31 - building DB-78XXX kernel TB --- 2011-11-17 19:21:31 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:21:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:21:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:21:31 - SRCCONF=/dev/null TB --- 2011-11-17 19:21:31 - TARGET=arm TB --- 2011-11-17 19:21:31 - TARGET_ARCH=arm TB --- 2011-11-17 19:21:31 - TZ=UTC TB --- 2011-11-17 19:21:31 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:21:31 - cd /src TB --- 2011-11-17 19:21:31 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Thu Nov 17 19:21:31 UTC 2011 >>> 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 >>> Kernel build for DB-78XXX completed on Thu Nov 17 19:24:08 UTC 2011 TB --- 2011-11-17 19:24:08 - cd /src/sys/arm/conf TB --- 2011-11-17 19:24:08 - /usr/sbin/config -m DB-88F5XXX TB --- 2011-11-17 19:24:08 - building DB-88F5XXX kernel TB --- 2011-11-17 19:24:08 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:24:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:24:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:24:08 - SRCCONF=/dev/null TB --- 2011-11-17 19:24:08 - TARGET=arm TB --- 2011-11-17 19:24:08 - TARGET_ARCH=arm TB --- 2011-11-17 19:24:08 - TZ=UTC TB --- 2011-11-17 19:24:08 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:24:08 - cd /src TB --- 2011-11-17 19:24:08 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Thu Nov 17 19:24:08 UTC 2011 >>> 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 >>> Kernel build for DB-88F5XXX completed on Thu Nov 17 19:26:47 UTC 2011 TB --- 2011-11-17 19:26:47 - cd /src/sys/arm/conf TB --- 2011-11-17 19:26:47 - /usr/sbin/config -m DB-88F6XXX TB --- 2011-11-17 19:26:48 - building DB-88F6XXX kernel TB --- 2011-11-17 19:26:48 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:26:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:26:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:26:48 - SRCCONF=/dev/null TB --- 2011-11-17 19:26:48 - TARGET=arm TB --- 2011-11-17 19:26:48 - TARGET_ARCH=arm TB --- 2011-11-17 19:26:48 - TZ=UTC TB --- 2011-11-17 19:26:48 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:26:48 - cd /src TB --- 2011-11-17 19:26:48 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Thu Nov 17 19:26:48 UTC 2011 >>> 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 >>> Kernel build for DB-88F6XXX completed on Thu Nov 17 19:29:54 UTC 2011 TB --- 2011-11-17 19:29:54 - cd /src/sys/arm/conf TB --- 2011-11-17 19:29:54 - /usr/sbin/config -m DOCKSTAR TB --- 2011-11-17 19:29:54 - building DOCKSTAR kernel TB --- 2011-11-17 19:29:54 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:29:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:29:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:29:54 - SRCCONF=/dev/null TB --- 2011-11-17 19:29:54 - TARGET=arm TB --- 2011-11-17 19:29:54 - TARGET_ARCH=arm TB --- 2011-11-17 19:29:54 - TZ=UTC TB --- 2011-11-17 19:29:54 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:29:54 - cd /src TB --- 2011-11-17 19:29:54 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Thu Nov 17 19:29:55 UTC 2011 >>> 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 >>> Kernel build for DOCKSTAR completed on Thu Nov 17 19:32:30 UTC 2011 TB --- 2011-11-17 19:32:30 - cd /src/sys/arm/conf TB --- 2011-11-17 19:32:30 - /usr/sbin/config -m EP80219 TB --- 2011-11-17 19:32:30 - building EP80219 kernel TB --- 2011-11-17 19:32:30 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:32:30 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:32:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:32:30 - SRCCONF=/dev/null TB --- 2011-11-17 19:32:30 - TARGET=arm TB --- 2011-11-17 19:32:30 - TARGET_ARCH=arm TB --- 2011-11-17 19:32:30 - TZ=UTC TB --- 2011-11-17 19:32:30 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:32:30 - cd /src TB --- 2011-11-17 19:32:30 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Thu Nov 17 19:32:30 UTC 2011 >>> 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 >>> Kernel build for EP80219 completed on Thu Nov 17 19:35:22 UTC 2011 TB --- 2011-11-17 19:35:22 - WARNING: no kernel config for GENERIC TB --- 2011-11-17 19:35:22 - cd /src/sys/arm/conf TB --- 2011-11-17 19:35:22 - /usr/sbin/config -m GUMSTIX TB --- 2011-11-17 19:35:22 - building GUMSTIX kernel TB --- 2011-11-17 19:35:22 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:35:22 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:35:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:35:22 - SRCCONF=/dev/null TB --- 2011-11-17 19:35:22 - TARGET=arm TB --- 2011-11-17 19:35:22 - TARGET_ARCH=arm TB --- 2011-11-17 19:35:22 - TZ=UTC TB --- 2011-11-17 19:35:22 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:35:22 - cd /src TB --- 2011-11-17 19:35:22 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Thu Nov 17 19:35:22 UTC 2011 >>> 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 >>> Kernel build for GUMSTIX completed on Thu Nov 17 19:37:40 UTC 2011 TB --- 2011-11-17 19:37:40 - cd /src/sys/arm/conf TB --- 2011-11-17 19:37:40 - /usr/sbin/config -m HL200 TB --- 2011-11-17 19:37:40 - building HL200 kernel TB --- 2011-11-17 19:37:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:37:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:37:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:37:41 - SRCCONF=/dev/null TB --- 2011-11-17 19:37:41 - TARGET=arm TB --- 2011-11-17 19:37:41 - TARGET_ARCH=arm TB --- 2011-11-17 19:37:41 - TZ=UTC TB --- 2011-11-17 19:37:41 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:37:41 - cd /src TB --- 2011-11-17 19:37:41 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Thu Nov 17 19:37:41 UTC 2011 >>> 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 >>> Kernel build for HL200 completed on Thu Nov 17 19:40:46 UTC 2011 TB --- 2011-11-17 19:40:46 - cd /src/sys/arm/conf TB --- 2011-11-17 19:40:46 - /usr/sbin/config -m HL201 TB --- 2011-11-17 19:40:50 - building HL201 kernel TB --- 2011-11-17 19:40:50 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:40:50 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:40:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:40:50 - SRCCONF=/dev/null TB --- 2011-11-17 19:40:50 - TARGET=arm TB --- 2011-11-17 19:40:50 - TARGET_ARCH=arm TB --- 2011-11-17 19:40:50 - TZ=UTC TB --- 2011-11-17 19:40:50 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:40:50 - cd /src TB --- 2011-11-17 19:40:50 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Thu Nov 17 19:40:50 UTC 2011 >>> 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 >>> Kernel build for HL201 completed on Thu Nov 17 19:43:10 UTC 2011 TB --- 2011-11-17 19:43:10 - cd /src/sys/arm/conf TB --- 2011-11-17 19:43:10 - /usr/sbin/config -m IQ31244 TB --- 2011-11-17 19:43:10 - building IQ31244 kernel TB --- 2011-11-17 19:43:10 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:43:10 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:43:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:43:10 - SRCCONF=/dev/null TB --- 2011-11-17 19:43:10 - TARGET=arm TB --- 2011-11-17 19:43:10 - TARGET_ARCH=arm TB --- 2011-11-17 19:43:10 - TZ=UTC TB --- 2011-11-17 19:43:10 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:43:10 - cd /src TB --- 2011-11-17 19:43:10 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Thu Nov 17 19:43:10 UTC 2011 >>> 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 >>> Kernel build for IQ31244 completed on Thu Nov 17 19:46:26 UTC 2011 TB --- 2011-11-17 19:46:26 - cd /src/sys/arm/conf TB --- 2011-11-17 19:46:26 - /usr/sbin/config -m KB920X TB --- 2011-11-17 19:46:26 - building KB920X kernel TB --- 2011-11-17 19:46:26 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:46:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:46:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:46:26 - SRCCONF=/dev/null TB --- 2011-11-17 19:46:26 - TARGET=arm TB --- 2011-11-17 19:46:26 - TARGET_ARCH=arm TB --- 2011-11-17 19:46:26 - TZ=UTC TB --- 2011-11-17 19:46:26 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:46:26 - cd /src TB --- 2011-11-17 19:46:26 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Thu Nov 17 19:46:27 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 19:55:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 19:55:18 - ERROR: failed to build KB920X kernel TB --- 2011-11-17 19:55:18 - 4700.88 user 1163.87 system 6317.81 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 20:36:29 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A8BF106566B; Thu, 17 Nov 2011 20:36:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D1CCE8FC0A; Thu, 17 Nov 2011 20:36:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHKaSor027778; Thu, 17 Nov 2011 15:36:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHKaSrT027743; Thu, 17 Nov 2011 20:36:28 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 20:36:28 GMT Message-Id: <201111172036.pAHKaSrT027743@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 20:36:29 -0000 TB --- 2011-11-17 18:10:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 18:10:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-17 18:10:01 - cleaning the object tree TB --- 2011-11-17 18:10:25 - cvsupping the source tree TB --- 2011-11-17 18:10:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-17 18:11:12 - building world TB --- 2011-11-17 18:11:12 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 18:11:12 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 18:11:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 18:11:12 - SRCCONF=/dev/null TB --- 2011-11-17 18:11:12 - TARGET=pc98 TB --- 2011-11-17 18:11:12 - TARGET_ARCH=i386 TB --- 2011-11-17 18:11:12 - TZ=UTC TB --- 2011-11-17 18:11:12 - __MAKE_CONF=/dev/null TB --- 2011-11-17 18:11:12 - cd /src TB --- 2011-11-17 18:11:12 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 18:11:12 UTC 2011 >>> 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 Thu Nov 17 20:21:00 UTC 2011 TB --- 2011-11-17 20:21:01 - generating LINT kernel config TB --- 2011-11-17 20:21:01 - cd /src/sys/pc98/conf TB --- 2011-11-17 20:21:01 - /usr/bin/make -B LINT TB --- 2011-11-17 20:21:01 - cd /src/sys/pc98/conf TB --- 2011-11-17 20:21:01 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 20:21:01 - building GENERIC kernel TB --- 2011-11-17 20:21:01 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 20:21:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 20:21:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 20:21:01 - SRCCONF=/dev/null TB --- 2011-11-17 20:21:01 - TARGET=pc98 TB --- 2011-11-17 20:21:01 - TARGET_ARCH=i386 TB --- 2011-11-17 20:21:01 - TZ=UTC TB --- 2011-11-17 20:21:01 - __MAKE_CONF=/dev/null TB --- 2011-11-17 20:21:01 - cd /src TB --- 2011-11-17 20:21:01 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 20:21:01 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 20:36:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 20:36:27 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 20:36:27 - 7004.05 user 1232.66 system 8786.56 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 20:47:48 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6649D106567A; Thu, 17 Nov 2011 20:47:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 30A6D8FC15; Thu, 17 Nov 2011 20:47:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHKll8f011785; Thu, 17 Nov 2011 15:47:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHKllhq011737; Thu, 17 Nov 2011 20:47:47 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 20:47:47 GMT Message-Id: <201111172047.pAHKllhq011737@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 20:47:48 -0000 TB --- 2011-11-17 18:10:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 18:10:01 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-17 18:10:01 - cleaning the object tree TB --- 2011-11-17 18:10:25 - cvsupping the source tree TB --- 2011-11-17 18:10:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-17 18:11:12 - building world TB --- 2011-11-17 18:11:12 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 18:11:12 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 18:11:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 18:11:12 - SRCCONF=/dev/null TB --- 2011-11-17 18:11:12 - TARGET=i386 TB --- 2011-11-17 18:11:12 - TARGET_ARCH=i386 TB --- 2011-11-17 18:11:12 - TZ=UTC TB --- 2011-11-17 18:11:12 - __MAKE_CONF=/dev/null TB --- 2011-11-17 18:11:12 - cd /src TB --- 2011-11-17 18:11:12 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 18:11:12 UTC 2011 >>> 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 Thu Nov 17 20:21:21 UTC 2011 TB --- 2011-11-17 20:21:21 - generating LINT kernel config TB --- 2011-11-17 20:21:21 - cd /src/sys/i386/conf TB --- 2011-11-17 20:21:21 - /usr/bin/make -B LINT TB --- 2011-11-17 20:21:21 - cd /src/sys/i386/conf TB --- 2011-11-17 20:21:21 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-17 20:21:21 - building LINT-NOINET kernel TB --- 2011-11-17 20:21:21 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 20:21:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 20:21:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 20:21:21 - SRCCONF=/dev/null TB --- 2011-11-17 20:21:21 - TARGET=i386 TB --- 2011-11-17 20:21:21 - TARGET_ARCH=i386 TB --- 2011-11-17 20:21:21 - TZ=UTC TB --- 2011-11-17 20:21:21 - __MAKE_CONF=/dev/null TB --- 2011-11-17 20:21:21 - cd /src TB --- 2011-11-17 20:21:21 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Nov 17 20:21:21 UTC 2011 >>> 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 [...] ld -Bshareable -d -warn-common -o if_sf.ko if_sf.kld objcopy --strip-debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT-NOINET/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/i386.i386/src/sys/LINT-NOINET -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT-NOINET/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/i386.i386/src/sys/LINT-NOINET -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 20:47:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 20:47:47 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-17 20:47:47 - 7591.70 user 1277.73 system 9465.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 20:54:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1DA71065804; Thu, 17 Nov 2011 20:54:22 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id C2EF08FC0C; Thu, 17 Nov 2011 20:54:20 +0000 (UTC) Received: by wwg14 with SMTP id 14so3671721wwg.31 for ; Thu, 17 Nov 2011 12:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zDmUEm1cvECcP8j2dN+OcgeS6b2WD6i+TlqxjXFZExE=; b=CebhFPw5z+PfVnKBhVnegh6f/8ERFYGHG+rS2M0QNfA86KZ748alpdbOAh9ekxSDMW 53VQUj7ydvseLOklB1t0m5GXTlyNMJ/QYZBMh4eCkOMJZkm8Prl/KQk2VGFRxrznvwux ImNzayuEPcpeyplxQpZg0NihAtlBtG673yN60= MIME-Version: 1.0 Received: by 10.227.205.11 with SMTP id fo11mr172272wbb.16.1321563259865; Thu, 17 Nov 2011 12:54:19 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.85.8 with HTTP; Thu, 17 Nov 2011 12:54:19 -0800 (PST) In-Reply-To: <4EC563BB.60209@FreeBSD.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111171137.18663.jhb@freebsd.org> <4EC53D1B.4000308@FreeBSD.org> <201111171409.37629.jhb@freebsd.org> <4EC563BB.60209@FreeBSD.org> Date: Thu, 17 Nov 2011 21:54:19 +0100 X-Google-Sender-Auth: 8CxYW3poKDwinW9YCARc-gtLoUQ Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Alexander Motin , freebsd-current@freebsd.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 20:54:32 -0000 2011/11/17 Andriy Gapon : > on 17/11/2011 21:09 John Baldwin said the following: >> On Thursday, November 17, 2011 11:58:03 am Andriy Gapon wrote: >>> on 17/11/2011 18:37 John Baldwin said the following: >>>> On Thursday, November 17, 2011 4:47:42 am Andriy Gapon wrote: >>>>> on 17/11/2011 10:34 Andriy Gapon said the following: >>>>>> on 17/11/2011 10:15 Kostik Belousov said the following: >>>>>>> I have the following change for eons on my test boxes. Without it, >>>>>>> I simply cannot get _any_ dump. >>>>>>> >>>>>>> diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c >>>>>>> index 10b89c7..a38e42f 100644 >>>>>>> --- a/sys/cam/cam_xpt.c >>>>>>> +++ b/sys/cam/cam_xpt.c >>>>>>> @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0TAILQ_INSERT_TAIL(&cam_simq, sim, links); >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0mtx_unlock(&cam_simq_lock); >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0sim->flags |=3D CAM_SIM_ON_DONEQ; >>>>>>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0if (first) >>>>>>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0if (first && panicstr =3D=3D NULL) >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0swi_sched(cambio_ih, 0)= ; >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} >>>>>> >>>>>> I think that this (or similar) change should go into the patch and t= he tree. >>>>>> >>>>> >>>>> And, BTW, I still would like to do something like the following (perh= aps with >>>>> td_oncpu =3D NOCPU and td_flags &=3D ~TDF_NEEDRESCHED also moved to t= he common code): >>>>> >>>>> Index: sys/kern/sched_ule.c >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> --- sys/kern/sched_ule.c =C2=A0 (revision 227608) >>>>> +++ sys/kern/sched_ule.c =C2=A0 (working copy) >>>>> @@ -1790,7 +1790,6 @@ sched_switch(struct thread *td, struct thread *= new >>>>> =C2=A0 =C2=A0td->td_oncpu =3D NOCPU; >>>>> =C2=A0 =C2=A0if (!(flags & SW_PREEMPT)) >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0td->td_flags &=3D ~TDF_NEEDR= ESCHED; >>>>> - =C2=A0td->td_owepreempt =3D 0; >>>>> =C2=A0 =C2=A0tdq->tdq_switchcnt++; >>>>> =C2=A0 =C2=A0/* >>>>> =C2=A0 =C2=A0 * The lock pointer in an idle thread should never chang= e. =C2=A0Reset it >>>>> Index: sys/kern/kern_synch.c >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> --- sys/kern/kern_synch.c =C2=A0(revision 227608) >>>>> +++ sys/kern/kern_synch.c =C2=A0(working copy) >>>>> @@ -406,6 +406,8 @@ mi_switch(int flags, struct thread *newtd) >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0("mi_switch: switch must be voluntary or i= nvoluntary")); >>>>> =C2=A0 =C2=A0KASSERT(newtd !=3D curthread, ("mi_switch: preempting ba= ck to ourself")); >>>>> >>>>> + =C2=A0td->td_owepreempt =3D 0; >>>>> + >>>>> =C2=A0 =C2=A0/* >>>>> =C2=A0 =C2=A0 * Don't perform context switches from the debugger. >>>>> =C2=A0 =C2=A0 */ >>>>> Index: sys/kern/sched_4bsd.c >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> --- sys/kern/sched_4bsd.c =C2=A0(revision 227608) >>>>> +++ sys/kern/sched_4bsd.c =C2=A0(working copy) >>>>> @@ -940,7 +940,6 @@ sched_switch(struct thread *td, struct thread *ne= w >>>>> =C2=A0 =C2=A0td->td_lastcpu =3D td->td_oncpu; >>>>> =C2=A0 =C2=A0if (!(flags & SW_PREEMPT)) >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0td->td_flags &=3D ~TDF_NEEDR= ESCHED; >>>>> - =C2=A0td->td_owepreempt =3D 0; >>>>> =C2=A0 =C2=A0td->td_oncpu =3D NOCPU; >>>>> >>>>> =C2=A0 =C2=A0/* >>>>> >>>>> Does anybody see any potential problems with such a change? >>>> >>>> Hmm, does this mean the preemption will be lost if you break into the >>>> debugger and continue in the non-panic case? >>> >>> Not sure which exact scenario you have in mind. >>> Please note that the above diff just moves resetting of td_owepreempt t= o an >>> earlier place. =C2=A0As far as I can see there are no checks of td_owep= reempt value >>> between the new place and the old places. >> >> I'm worried that you are clearing td_owepreempt even in cases where a co= ntext >> switch is not performed. =C2=A0So say you enter DDB with td_owepreempt s= et and that >> DDB bails on a context switch. =C2=A0With your change it will now clear = td_owepreempt >> and "lose" the preemption. >> > > And without the change we get the recursion and double-fault because of > kdb_switch -> thread_unlock -> =C2=A0spinlock_exit -> =C2=A0critical_exit= -> > mi_switch in this case ? > > BTW, it is my opinion that we really should not let the debugger code cal= l > mi_switch for any reason. Yes, I agree with this, this is why the sched_bind() in boot() is broken (immagine calling things like doadump from KDB. KDB right now can be thought as a first cut of this patch because it does disable the CPUs when entering the context, thus, the bug here is that if you stop all CPUs including CPU0 and later on you want bind on it you are death). We need to discuss this and the patch more extensively, I'm taking my time and hopefully will do a full review during the weekend. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 21:02:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3081D1065673; Thu, 17 Nov 2011 21:02:04 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id DE8DC8FC08; Thu, 17 Nov 2011 21:02:03 +0000 (UTC) Received: by pzk33 with SMTP id 33so7198675pzk.3 for ; Thu, 17 Nov 2011 13:02:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=g2/bSSisEi1VRmd2dbONUFes9u9R4O7kSG/PUHp7PKk=; b=AxxgghNMcIZLZy+6olnAqDy2mbgy+AExqzjB/cLI+3vWjxiMSUMXLJlLoZmtv5LLnt bGUu7MpkPcdH+GeeG0gAoQmaTjA6Zipz5/yqMSbHuAjt7jN2hvF/FQfbAOEXGW+FGbjj ABn7NASzrSM7tDxNWpN7KPjbKfSFjeUUdJ0HY= MIME-Version: 1.0 Received: by 10.68.33.134 with SMTP id r6mr2229482pbi.76.1321563723370; Thu, 17 Nov 2011 13:02:03 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.56.97 with HTTP; Thu, 17 Nov 2011 13:02:03 -0800 (PST) In-Reply-To: References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111171137.18663.jhb@freebsd.org> <4EC53D1B.4000308@FreeBSD.org> <201111171409.37629.jhb@freebsd.org> <4EC563BB.60209@FreeBSD.org> Date: Thu, 17 Nov 2011 13:02:03 -0800 X-Google-Sender-Auth: U_DQZcUjUPejYz1lF3mhFsd3gRI Message-ID: From: mdf@FreeBSD.org To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Cc: Kostik Belousov , Alexander Motin , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 21:02:04 -0000 On Thu, Nov 17, 2011 at 12:54 PM, Attilio Rao wrote: > 2011/11/17 Andriy Gapon : >> BTW, it is my opinion that we really should not let the debugger code call >> mi_switch for any reason. > > Yes, I agree with this, this is why the sched_bind() in boot() is > broken (immagine calling things like doadump from KDB. KDB right now > can be thought as a first cut of this patch because it does disable > the CPUs when entering the context, thus, the bug here is that if you > stop all CPUs including CPU0 and later on you want bind on it you are > death). Another patch related to this area we have at $WORK: #if defined(SMP) - /* - * Bind us to CPU 0 so that all shutdown code runs there. Some - * systems don't shutdown properly (i.e., ACPI power off) if we - * run on another processor. - */ - thread_lock(curthread); - sched_bind(curthread, 0); - thread_unlock(curthread); - KASSERT(PCPU_GET(cpuid) == 0, ("%s: not running on cpu 0", __func__)); + /* + * sched_bind can't be done reliably inside of panic. cpu_reset() will + * rebind us in any case, more reliably. + */ + if (panicstr == NULL) { + /* + * Bind us to CPU 0 so that all shutdown code runs there. Some + * systems don't shutdown properly (i.e., ACPI power off) if we + * run on another processor. + */ + thread_lock(curthread); + sched_bind(curthread, 0); + thread_unlock(curthread); + KASSERT(PCPU_GET(cpuid) == 0, ("boot: not running on cpu 0")); + } #endif /* We're in the process of rebooting. */ rebooting = 1; Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 21:05:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5493E106566C; Thu, 17 Nov 2011 21:05:31 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 689598FC18; Thu, 17 Nov 2011 21:05:29 +0000 (UTC) Received: by wwg14 with SMTP id 14so3692494wwg.31 for ; Thu, 17 Nov 2011 13:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D3fW5UCMKPV81t32YmdD1TJu4NU8wHdctkclM8vigZs=; b=HuwZ+CzAZbpOSeHKnnUg9z/MTzJoD/kS3EJFNwYjQGoqkr99oSDQu0lLut0tlg4HGr G10nd7/MutCE3LjD4A17ljLuToAPRGJ1YEddjAnC9lwPE5a9az1ZFzdsQTtJX3ajS+1b VZhBT8NMbBYMaO+LeLzBbQiR7JPdmoeqezZx4= MIME-Version: 1.0 Received: by 10.227.205.11 with SMTP id fo11mr194328wbb.16.1321563929227; Thu, 17 Nov 2011 13:05:29 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.85.8 with HTTP; Thu, 17 Nov 2011 13:05:29 -0800 (PST) In-Reply-To: References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111171137.18663.jhb@freebsd.org> <4EC53D1B.4000308@FreeBSD.org> <201111171409.37629.jhb@freebsd.org> <4EC563BB.60209@FreeBSD.org> Date: Thu, 17 Nov 2011 22:05:29 +0100 X-Google-Sender-Auth: mgQ3_2WR5C45wHkpQ8LrlDVEbUY Message-ID: From: Attilio Rao To: mdf@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Alexander Motin , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 21:05:31 -0000 2011/11/17 : > On Thu, Nov 17, 2011 at 12:54 PM, Attilio Rao wrote= : >> 2011/11/17 Andriy Gapon : >>> BTW, it is my opinion that we really should not let the debugger code c= all >>> mi_switch for any reason. >> >> Yes, I agree with this, this is why the sched_bind() in boot() is >> broken (immagine calling things like doadump from KDB. KDB right now >> can be thought as a first cut of this patch because it does disable >> the CPUs when entering the context, thus, the bug here is that if you >> stop all CPUs including CPU0 and later on you want bind on it you are >> death). > > Another patch related to this area we have at $WORK: > > =C2=A0#if defined(SMP) > - =C2=A0 =C2=A0 =C2=A0 /* > - =C2=A0 =C2=A0 =C2=A0 =C2=A0* Bind us to CPU 0 so that all shutdown code= runs there. =C2=A0Some > - =C2=A0 =C2=A0 =C2=A0 =C2=A0* systems don't shutdown properly (i.e., ACP= I power off) if we > - =C2=A0 =C2=A0 =C2=A0 =C2=A0* run on another processor. > - =C2=A0 =C2=A0 =C2=A0 =C2=A0*/ > - =C2=A0 =C2=A0 =C2=A0 thread_lock(curthread); > - =C2=A0 =C2=A0 =C2=A0 sched_bind(curthread, 0); > - =C2=A0 =C2=A0 =C2=A0 thread_unlock(curthread); > - =C2=A0 =C2=A0 =C2=A0 KASSERT(PCPU_GET(cpuid) =3D=3D 0, ("%s: not runnin= g on cpu 0", __func__)); > + =C2=A0 =C2=A0 =C2=A0 /* > + =C2=A0 =C2=A0 =C2=A0 =C2=A0* sched_bind can't be done reliably inside o= f panic. =C2=A0cpu_reset() will > + =C2=A0 =C2=A0 =C2=A0 =C2=A0* rebind us in any case, more reliably. > + =C2=A0 =C2=A0 =C2=A0 =C2=A0*/ > + =C2=A0 =C2=A0 =C2=A0 if (panicstr =3D=3D NULL) { > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Bind us to CPU= 0 so that all shutdown code runs there. =C2=A0Some > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* systems don't = shutdown properly (i.e., ACPI power off) if we > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* run on another= processor. > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/ > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 thread_lock(curthread)= ; > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sched_bind(curthread, = 0); > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 thread_unlock(curthrea= d); > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 KASSERT(PCPU_GET(cpuid= ) =3D=3D 0, ("boot: not running on cpu 0")); > + =C2=A0 =C2=A0 =C2=A0 } > =C2=A0#endif > =C2=A0 =C2=A0 =C2=A0 =C2=A0/* We're in the process of rebooting. */ > =C2=A0 =C2=A0 =C2=A0 =C2=A0rebooting =3D 1; This doesn't cover the KDB case which is the most broken here. (I'm a bit unsure about the name of functions and I cannot check now, but in short): - you enter KDB via debug.kdb.enter=3D1 (for example) - kdb_enter() stop CPUs and if it is on CPU1 it stops CPU0 - you call functions entering boot() from KDB prompt (IIRC "call doadump" should do it) - boot() wants to bind on CPU0 which is turned off This case only take care of panic, which is not enough. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 21:08:33 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2277106566B for ; Thu, 17 Nov 2011 21:08:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D9F738FC14 for ; Thu, 17 Nov 2011 21:08:32 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA23859; Thu, 17 Nov 2011 23:08:31 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RR9CA-000C9O-Le; Thu, 17 Nov 2011 23:08:30 +0200 Message-ID: <4EC577CD.8020207@FreeBSD.org> Date: Thu, 17 Nov 2011 23:08:29 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: mdf@FreeBSD.org References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111171137.18663.jhb@freebsd.org> <4EC53D1B.4000308@FreeBSD.org> <201111171409.37629.jhb@freebsd.org> <4EC563BB.60209@FreeBSD.org> In-Reply-To: X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 21:08:33 -0000 on 17/11/2011 23:02 mdf@FreeBSD.org said the following: > Another patch related to this area we have at $WORK: > > #if defined(SMP) > - /* > - * Bind us to CPU 0 so that all shutdown code runs there. Some > - * systems don't shutdown properly (i.e., ACPI power off) if we > - * run on another processor. > - */ > - thread_lock(curthread); > - sched_bind(curthread, 0); > - thread_unlock(curthread); > - KASSERT(PCPU_GET(cpuid) == 0, ("%s: not running on cpu 0", __func__)); > + /* > + * sched_bind can't be done reliably inside of panic. cpu_reset() will > + * rebind us in any case, more reliably. > + */ > + if (panicstr == NULL) { > + /* > + * Bind us to CPU 0 so that all shutdown code runs there. Some > + * systems don't shutdown properly (i.e., ACPI power off) if we > + * run on another processor. > + */ > + thread_lock(curthread); > + sched_bind(curthread, 0); > + thread_unlock(curthread); > + KASSERT(PCPU_GET(cpuid) == 0, ("boot: not running on cpu 0")); > + } > #endif > /* We're in the process of rebooting. */ > rebooting = 1; Yes, you have contributed this patch before and it is a part of the bigger stop-scheduler-on-panic patches. Have you had a chance to review those? :) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 21:20:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 059851065670; Thu, 17 Nov 2011 21:20:59 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id C2D3B8FC14; Thu, 17 Nov 2011 21:20:58 +0000 (UTC) Received: by pzk33 with SMTP id 33so7284778pzk.3 for ; Thu, 17 Nov 2011 13:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dm/EZ93Hbp44JEFUp9XqnBg6J+VitqW6ptBMk7GuSIY=; b=ZywC1OdmBd0DyzjgaIeMPfK0Fw8jKcZaS82kB6oQ5HeH5WTWdPZeCkCWTpcnXeJkyz +ubG8JBduOx+U9w595dgJEW3AsPrraOTGDK/rDpIAY8yuxx+OmzlOMWXa3vHuQqHECqt ZsAj1Rtr3eaXvg2Vm65lQp4F38OER1qL68UoU= MIME-Version: 1.0 Received: by 10.68.38.5 with SMTP id c5mr2361339pbk.93.1321564858103; Thu, 17 Nov 2011 13:20:58 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.56.97 with HTTP; Thu, 17 Nov 2011 13:20:58 -0800 (PST) In-Reply-To: <4EC577CD.8020207@FreeBSD.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111171137.18663.jhb@freebsd.org> <4EC53D1B.4000308@FreeBSD.org> <201111171409.37629.jhb@freebsd.org> <4EC563BB.60209@FreeBSD.org> <4EC577CD.8020207@FreeBSD.org> Date: Thu, 17 Nov 2011 13:20:58 -0800 X-Google-Sender-Auth: bvrwynSikvHo4oJ44gVWSLE5a9Y Message-ID: From: mdf@FreeBSD.org To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 21:20:59 -0000 On Thu, Nov 17, 2011 at 1:08 PM, Andriy Gapon wrote: > on 17/11/2011 23:02 mdf@FreeBSD.org said the following: >> Another patch related to this area we have at $WORK: >> >> =A0#if defined(SMP) >> - =A0 =A0 =A0 /* >> - =A0 =A0 =A0 =A0* Bind us to CPU 0 so that all shutdown code runs there= . =A0Some >> - =A0 =A0 =A0 =A0* systems don't shutdown properly (i.e., ACPI power off= ) if we >> - =A0 =A0 =A0 =A0* run on another processor. >> - =A0 =A0 =A0 =A0*/ >> - =A0 =A0 =A0 thread_lock(curthread); >> - =A0 =A0 =A0 sched_bind(curthread, 0); >> - =A0 =A0 =A0 thread_unlock(curthread); >> - =A0 =A0 =A0 KASSERT(PCPU_GET(cpuid) =3D=3D 0, ("%s: not running on cpu= 0", __func__)); >> + =A0 =A0 =A0 /* >> + =A0 =A0 =A0 =A0* sched_bind can't be done reliably inside of panic. = =A0cpu_reset() will >> + =A0 =A0 =A0 =A0* rebind us in any case, more reliably. >> + =A0 =A0 =A0 =A0*/ >> + =A0 =A0 =A0 if (panicstr =3D=3D NULL) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Bind us to CPU 0 so that all shutdown= code runs there. =A0Some >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* systems don't shutdown properly (i.e.= , ACPI power off) if we >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* run on another processor. >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 thread_lock(curthread); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 sched_bind(curthread, 0); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 thread_unlock(curthread); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 KASSERT(PCPU_GET(cpuid) =3D=3D 0, ("boot: = not running on cpu 0")); >> + =A0 =A0 =A0 } >> =A0#endif >> =A0 =A0 =A0 =A0 /* We're in the process of rebooting. */ >> =A0 =A0 =A0 =A0 rebooting =3D 1; > > Yes, you have contributed this patch before and it is a part of the bigge= r > stop-scheduler-on-panic patches. =A0Have you had a chance to review those= ? :) It's been so long I don't remember what I've sent where. I did look over the patch but had no additional comments. Cheers, matthew From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 21:29:00 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D31B106564A for ; Thu, 17 Nov 2011 21:29:00 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 21DA58FC16 for ; Thu, 17 Nov 2011 21:28:59 +0000 (UTC) Received: by faap15 with SMTP id p15so2948360faa.13 for ; Thu, 17 Nov 2011 13:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GxvnAMxXOh5JHBwx/iS6a1C/wRnowWYFypeKLx3EmxU=; b=rh4EVxZvk4z24G7wxlZEA54nKjvHUjvV8CGDrWE3zOTpkc9X79YxEV+HnGELhXPLJm dladSyu3hogyX8DpWmCSsrJ1s8NIoV3D88HTuP74w227mPD3VEM3dgRWnM71YRzXVy3n htphxWu7gd7wyNkr8/3/3ODLFWOspQxg10rcI= MIME-Version: 1.0 Received: by 10.182.50.65 with SMTP id a1mr87439obo.17.1321565338405; Thu, 17 Nov 2011 13:28:58 -0800 (PST) Received: by 10.182.7.34 with HTTP; Thu, 17 Nov 2011 13:28:58 -0800 (PST) In-Reply-To: <4EC565A0.8090708@ukr.net> References: <4EC565A0.8090708@ukr.net> Date: Thu, 17 Nov 2011 13:28:58 -0800 Message-ID: From: Garrett Cooper To: "Vladislav V. Prodan" Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org Subject: Re: Why not on the ftp fresh snapshot iso? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 21:29:00 -0000 On Thu, Nov 17, 2011 at 11:50 AM, Vladislav V. Prodan wrote: > I'm interested in 8.2 (August-September) and 9.0 (beta) for amd64. > Where to download their iso? http://lists.freebsd.org/pipermail/freebsd-current/2011-November/029373.html From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 21:31:24 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3237B1065674 for ; Thu, 17 Nov 2011 21:31:24 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id A55938FC12 for ; Thu, 17 Nov 2011 21:31:23 +0000 (UTC) Received: by faap15 with SMTP id p15so2952828faa.13 for ; Thu, 17 Nov 2011 13:31:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=q7LabkcteFZ45lyeLWsXAzqj2Cmy1+H0+sQFcnJv0S8=; b=ccPhj6NDIaYyDdJ+SfNUDIAbl0db0lL4sl/9Nr+rHEBA6VsZtlWz/Z12XpJIA9mOfo +MjSsZXngNxENjMKfzlwCpcFXBr1BszL11yybp+Mds19Ad8jdmTv0N+pAsSRUJltOITB yYgNqULqULXb2u+ZDP2P6LZqJvmFEw8wuM8Bo= MIME-Version: 1.0 Received: by 10.182.59.49 with SMTP id w17mr77058obq.37.1321565482015; Thu, 17 Nov 2011 13:31:22 -0800 (PST) Received: by 10.182.7.34 with HTTP; Thu, 17 Nov 2011 13:31:21 -0800 (PST) In-Reply-To: <201111171955.pAHJtJj5028599@freebsd-current.sentex.ca> References: <201111171955.pAHJtJj5028599@freebsd-current.sentex.ca> Date: Thu, 17 Nov 2011 13:31:21 -0800 Message-ID: From: Garrett Cooper To: FreeBSD Tinderbox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arm@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 21:31:24 -0000 On Thu, Nov 17, 2011 at 11:55 AM, FreeBSD Tinderbox wrote: > TB --- 2011-11-17 18:10:01 - tinderbox 2.8 running on freebsd-current.sen= tex.ca > TB --- 2011-11-17 18:10:01 - starting HEAD tinderbox run for arm/arm > TB --- 2011-11-17 18:10:01 - cleaning the object tree > TB --- 2011-11-17 18:10:26 - cvsupping the source tree > TB --- 2011-11-17 18:10:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sente= x.ca /tinderbox/HEAD/arm/arm/supfile > TB --- 2011-11-17 18:11:12 - building world > TB --- 2011-11-17 18:11:12 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 18:11:12 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 18:11:12 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 18:11:12 - SRCCONF=3D/dev/null > TB --- 2011-11-17 18:11:12 - TARGET=3Darm > TB --- 2011-11-17 18:11:12 - TARGET_ARCH=3Darm > TB --- 2011-11-17 18:11:12 - TZ=3DUTC > TB --- 2011-11-17 18:11:12 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 18:11:12 - cd /src > TB --- 2011-11-17 18:11:12 - /usr/bin/make -B buildworld >>>> World build started on Thu Nov 17 18:11:12 UTC 2011 >>>> 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 Thu Nov 17 19:06:31 UTC 2011 > TB --- 2011-11-17 19:06:31 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:06:31 - /usr/sbin/config -m AVILA > TB --- 2011-11-17 19:06:31 - building AVILA kernel > TB --- 2011-11-17 19:06:31 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:06:31 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:06:31 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:06:31 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:06:31 - TARGET=3Darm > TB --- 2011-11-17 19:06:31 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:06:31 - TZ=3DUTC > TB --- 2011-11-17 19:06:31 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:06:31 - cd /src > TB --- 2011-11-17 19:06:31 - /usr/bin/make -B buildkernel KERNCONF=3DAVIL= A >>>> Kernel build for AVILA started on Thu Nov 17 19:06:31 UTC 2011 >>>> 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 >>>> Kernel build for AVILA completed on Thu Nov 17 19:09:34 UTC 2011 > TB --- 2011-11-17 19:09:34 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:09:34 - /usr/sbin/config -m BWCT > TB --- 2011-11-17 19:09:35 - building BWCT kernel > TB --- 2011-11-17 19:09:35 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:09:35 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:09:35 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:09:35 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:09:35 - TARGET=3Darm > TB --- 2011-11-17 19:09:35 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:09:35 - TZ=3DUTC > TB --- 2011-11-17 19:09:35 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:09:35 - cd /src > TB --- 2011-11-17 19:09:35 - /usr/bin/make -B buildkernel KERNCONF=3DBWCT >>>> Kernel build for BWCT started on Thu Nov 17 19:09:35 UTC 2011 >>>> 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 >>>> Kernel build for BWCT completed on Thu Nov 17 19:12:13 UTC 2011 > TB --- 2011-11-17 19:12:13 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:12:13 - /usr/sbin/config -m CAMBRIA > TB --- 2011-11-17 19:12:13 - building CAMBRIA kernel > TB --- 2011-11-17 19:12:13 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:12:13 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:12:13 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:12:13 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:12:13 - TARGET=3Darm > TB --- 2011-11-17 19:12:13 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:12:13 - TZ=3DUTC > TB --- 2011-11-17 19:12:13 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:12:13 - cd /src > TB --- 2011-11-17 19:12:13 - /usr/bin/make -B buildkernel KERNCONF=3DCAMB= RIA >>>> Kernel build for CAMBRIA started on Thu Nov 17 19:12:13 UTC 2011 >>>> 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 >>>> Kernel build for CAMBRIA completed on Thu Nov 17 19:15:10 UTC 2011 > TB --- 2011-11-17 19:15:10 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:15:10 - /usr/sbin/config -m CNS11XXNAS > TB --- 2011-11-17 19:15:11 - building CNS11XXNAS kernel > TB --- 2011-11-17 19:15:11 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:15:11 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:15:11 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:15:11 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:15:11 - TARGET=3Darm > TB --- 2011-11-17 19:15:11 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:15:11 - TZ=3DUTC > TB --- 2011-11-17 19:15:11 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:15:11 - cd /src > TB --- 2011-11-17 19:15:11 - /usr/bin/make -B buildkernel KERNCONF=3DCNS1= 1XXNAS >>>> Kernel build for CNS11XXNAS started on Thu Nov 17 19:15:11 UTC 2011 >>>> 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 >>>> Kernel build for CNS11XXNAS completed on Thu Nov 17 19:17:41 UTC 2011 > TB --- 2011-11-17 19:17:41 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:17:41 - /usr/sbin/config -m CRB > TB --- 2011-11-17 19:17:41 - building CRB kernel > TB --- 2011-11-17 19:17:41 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:17:41 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:17:41 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:17:41 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:17:41 - TARGET=3Darm > TB --- 2011-11-17 19:17:41 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:17:41 - TZ=3DUTC > TB --- 2011-11-17 19:17:41 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:17:41 - cd /src > TB --- 2011-11-17 19:17:41 - /usr/bin/make -B buildkernel KERNCONF=3DCRB >>>> Kernel build for CRB started on Thu Nov 17 19:17:41 UTC 2011 >>>> 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 >>>> Kernel build for CRB completed on Thu Nov 17 19:21:31 UTC 2011 > TB --- 2011-11-17 19:21:31 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:21:31 - /usr/sbin/config -m DB-78XXX > TB --- 2011-11-17 19:21:31 - building DB-78XXX kernel > TB --- 2011-11-17 19:21:31 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:21:31 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:21:31 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:21:31 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:21:31 - TARGET=3Darm > TB --- 2011-11-17 19:21:31 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:21:31 - TZ=3DUTC > TB --- 2011-11-17 19:21:31 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:21:31 - cd /src > TB --- 2011-11-17 19:21:31 - /usr/bin/make -B buildkernel KERNCONF=3DDB-7= 8XXX >>>> Kernel build for DB-78XXX started on Thu Nov 17 19:21:31 UTC 2011 >>>> 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 >>>> Kernel build for DB-78XXX completed on Thu Nov 17 19:24:08 UTC 2011 > TB --- 2011-11-17 19:24:08 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:24:08 - /usr/sbin/config -m DB-88F5XXX > TB --- 2011-11-17 19:24:08 - building DB-88F5XXX kernel > TB --- 2011-11-17 19:24:08 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:24:08 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:24:08 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:24:08 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:24:08 - TARGET=3Darm > TB --- 2011-11-17 19:24:08 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:24:08 - TZ=3DUTC > TB --- 2011-11-17 19:24:08 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:24:08 - cd /src > TB --- 2011-11-17 19:24:08 - /usr/bin/make -B buildkernel KERNCONF=3DDB-8= 8F5XXX >>>> Kernel build for DB-88F5XXX started on Thu Nov 17 19:24:08 UTC 2011 >>>> 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 >>>> Kernel build for DB-88F5XXX completed on Thu Nov 17 19:26:47 UTC 2011 > TB --- 2011-11-17 19:26:47 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:26:47 - /usr/sbin/config -m DB-88F6XXX > TB --- 2011-11-17 19:26:48 - building DB-88F6XXX kernel > TB --- 2011-11-17 19:26:48 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:26:48 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:26:48 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:26:48 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:26:48 - TARGET=3Darm > TB --- 2011-11-17 19:26:48 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:26:48 - TZ=3DUTC > TB --- 2011-11-17 19:26:48 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:26:48 - cd /src > TB --- 2011-11-17 19:26:48 - /usr/bin/make -B buildkernel KERNCONF=3DDB-8= 8F6XXX >>>> Kernel build for DB-88F6XXX started on Thu Nov 17 19:26:48 UTC 2011 >>>> 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 >>>> Kernel build for DB-88F6XXX completed on Thu Nov 17 19:29:54 UTC 2011 > TB --- 2011-11-17 19:29:54 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:29:54 - /usr/sbin/config -m DOCKSTAR > TB --- 2011-11-17 19:29:54 - building DOCKSTAR kernel > TB --- 2011-11-17 19:29:54 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:29:54 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:29:54 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:29:54 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:29:54 - TARGET=3Darm > TB --- 2011-11-17 19:29:54 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:29:54 - TZ=3DUTC > TB --- 2011-11-17 19:29:54 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:29:54 - cd /src > TB --- 2011-11-17 19:29:54 - /usr/bin/make -B buildkernel KERNCONF=3DDOCK= STAR >>>> Kernel build for DOCKSTAR started on Thu Nov 17 19:29:55 UTC 2011 >>>> 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 >>>> Kernel build for DOCKSTAR completed on Thu Nov 17 19:32:30 UTC 2011 > TB --- 2011-11-17 19:32:30 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:32:30 - /usr/sbin/config -m EP80219 > TB --- 2011-11-17 19:32:30 - building EP80219 kernel > TB --- 2011-11-17 19:32:30 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:32:30 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:32:30 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:32:30 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:32:30 - TARGET=3Darm > TB --- 2011-11-17 19:32:30 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:32:30 - TZ=3DUTC > TB --- 2011-11-17 19:32:30 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:32:30 - cd /src > TB --- 2011-11-17 19:32:30 - /usr/bin/make -B buildkernel KERNCONF=3DEP80= 219 >>>> Kernel build for EP80219 started on Thu Nov 17 19:32:30 UTC 2011 >>>> 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 >>>> Kernel build for EP80219 completed on Thu Nov 17 19:35:22 UTC 2011 > TB --- 2011-11-17 19:35:22 - WARNING: no kernel config for GENERIC > TB --- 2011-11-17 19:35:22 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:35:22 - /usr/sbin/config -m GUMSTIX > TB --- 2011-11-17 19:35:22 - building GUMSTIX kernel > TB --- 2011-11-17 19:35:22 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:35:22 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:35:22 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:35:22 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:35:22 - TARGET=3Darm > TB --- 2011-11-17 19:35:22 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:35:22 - TZ=3DUTC > TB --- 2011-11-17 19:35:22 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:35:22 - cd /src > TB --- 2011-11-17 19:35:22 - /usr/bin/make -B buildkernel KERNCONF=3DGUMS= TIX >>>> Kernel build for GUMSTIX started on Thu Nov 17 19:35:22 UTC 2011 >>>> 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 >>>> Kernel build for GUMSTIX completed on Thu Nov 17 19:37:40 UTC 2011 > TB --- 2011-11-17 19:37:40 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:37:40 - /usr/sbin/config -m HL200 > TB --- 2011-11-17 19:37:40 - building HL200 kernel > TB --- 2011-11-17 19:37:41 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:37:41 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:37:41 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:37:41 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:37:41 - TARGET=3Darm > TB --- 2011-11-17 19:37:41 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:37:41 - TZ=3DUTC > TB --- 2011-11-17 19:37:41 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:37:41 - cd /src > TB --- 2011-11-17 19:37:41 - /usr/bin/make -B buildkernel KERNCONF=3DHL20= 0 >>>> Kernel build for HL200 started on Thu Nov 17 19:37:41 UTC 2011 >>>> 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 >>>> Kernel build for HL200 completed on Thu Nov 17 19:40:46 UTC 2011 > TB --- 2011-11-17 19:40:46 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:40:46 - /usr/sbin/config -m HL201 > TB --- 2011-11-17 19:40:50 - building HL201 kernel > TB --- 2011-11-17 19:40:50 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:40:50 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:40:50 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:40:50 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:40:50 - TARGET=3Darm > TB --- 2011-11-17 19:40:50 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:40:50 - TZ=3DUTC > TB --- 2011-11-17 19:40:50 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:40:50 - cd /src > TB --- 2011-11-17 19:40:50 - /usr/bin/make -B buildkernel KERNCONF=3DHL20= 1 >>>> Kernel build for HL201 started on Thu Nov 17 19:40:50 UTC 2011 >>>> 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 >>>> Kernel build for HL201 completed on Thu Nov 17 19:43:10 UTC 2011 > TB --- 2011-11-17 19:43:10 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:43:10 - /usr/sbin/config -m IQ31244 > TB --- 2011-11-17 19:43:10 - building IQ31244 kernel > TB --- 2011-11-17 19:43:10 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:43:10 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:43:10 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:43:10 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:43:10 - TARGET=3Darm > TB --- 2011-11-17 19:43:10 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:43:10 - TZ=3DUTC > TB --- 2011-11-17 19:43:10 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:43:10 - cd /src > TB --- 2011-11-17 19:43:10 - /usr/bin/make -B buildkernel KERNCONF=3DIQ31= 244 >>>> Kernel build for IQ31244 started on Thu Nov 17 19:43:10 UTC 2011 >>>> 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 >>>> Kernel build for IQ31244 completed on Thu Nov 17 19:46:26 UTC 2011 > TB --- 2011-11-17 19:46:26 - cd /src/sys/arm/conf > TB --- 2011-11-17 19:46:26 - /usr/sbin/config -m KB920X > TB --- 2011-11-17 19:46:26 - building KB920X kernel > TB --- 2011-11-17 19:46:26 - CROSS_BUILD_TESTING=3DYES > TB --- 2011-11-17 19:46:26 - MAKEOBJDIRPREFIX=3D/obj > TB --- 2011-11-17 19:46:26 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2011-11-17 19:46:26 - SRCCONF=3D/dev/null > TB --- 2011-11-17 19:46:26 - TARGET=3Darm > TB --- 2011-11-17 19:46:26 - TARGET_ARCH=3Darm > TB --- 2011-11-17 19:46:26 - TZ=3DUTC > TB --- 2011-11-17 19:46:26 - __MAKE_CONF=3D/dev/null > TB --- 2011-11-17 19:46:26 - cd /src > TB --- 2011-11-17 19:46:26 - /usr/bin/make -B buildkernel KERNCONF=3DKB92= 0X >>>> Kernel build for KB920X started on Thu Nov 17 19:46:27 UTC 2011 >>>> 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 > [...] > objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols > objcopy --strip-debug --add-gnu-debuglink=3Dif_sf.ko.symbols if_sf.ko.deb= ug if_sf.ko > =3D=3D=3D> sfxge (all) > cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc =A0 -DHAVE_KERNEL_OP= TION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/= contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param= large-function-growth=3D1000 -fno-common -g -DDEBUG=3D1 -I/obj/arm.arm/src= /sys/KB920X -mcpu=3Darm9 -ffreestanding -std=3Diso9899:1999 -Wall -Wredunda= nt-decls -Wnested-externs -Wstrict-prototypes =A0-Wmissing-prototypes -Wpoi= nter-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign -fformat-exten= sions =A0-Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modul= es/sfxge/../../dev/sfxge/sfxge.c > cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc =A0 -DHAVE_KERNEL_OP= TION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/= contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 --param= large-function-growth=3D1000 -fno-common -g -DDEBUG=3D1 -I/obj/arm.arm/src= /sys/KB920X -mcpu=3Darm9 -ffreestanding -std=3Diso9899:1999 -Wall -Wredunda= nt-decls -Wnested-externs -Wstrict-prototypes =A0-Wmissing-prototypes -Wpoi= nter-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign -fformat-exten= sions =A0-Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modul= es/sfxge/../../dev/sfxge/sfxge_dma.c > cc1: warnings being treated as errors > /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dm= a_alloc': > /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large in= teger implicitly truncated to unsigned type [-Woverflow] > *** Error code 1 I've already contacted philip about these build issues (all 32-bit archs -- and I think ia64 -- currently fail to build via tinderbox because of this error). Bottom line is that I think this driver should be removed from all 32-bit builds.. was waiting for feedback from him on that. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 21:32:36 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1C551065673; Thu, 17 Nov 2011 21:32:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 850F18FC0C; Thu, 17 Nov 2011 21:32:36 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2218946B06; Thu, 17 Nov 2011 16:32:36 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A27508A050; Thu, 17 Nov 2011 16:32:35 -0500 (EST) From: John Baldwin To: Robert Millan Date: Thu, 17 Nov 2011 16:32:34 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201111170959.56767.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201111171632.34979.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 17 Nov 2011 16:32:35 -0500 (EST) Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, Warner Losh , freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 21:32:36 -0000 On Thursday, November 17, 2011 2:02:02 pm Robert Millan wrote: > 2011/11/17 John Baldwin : > > I recall the discussion from earlier. I can't recall if I had replied to it > > though. :-/ In my current opinion, I think it would be fine to define > > __FreeBSD_kernel__ on FreeBSD and to do it in for now until all > > the compilers we use have been updated to define it automatically (which may > > be a long time). I think it will also be fine to patch in-system headers to > > use __FreeBSD_kernel__ once is defined. Unfortunately headers > > in 3rd party software are going to have to check for both __FreeBSD__ and > > __FreeBSD_kernel__ to support both GNU/kFreeBSD and older FreeBSD for the > > foreseeable future. I think that is fine, but that the sooner we add > > __FreeBSD_kernel__ on FreeBSD the sooner we get the clock started for a day > > when those extra checks can go away. I would also be fine with MFC'ing the > > addition of __FreeBSD_kernel__ to older branches (at least 7 - 9) as well. > > Well, here's a patch then. I wrote a comment in it trying to explain > the situation. Please let me know what you think. Hmm, I wonder if it's better to use the #ifndef approach rather than #undef so that when compilers are updated to DTRT we will honor their settings? (And eventually this could be maybe removed from param.h altogether.) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 21:35:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F21D106564A; Thu, 17 Nov 2011 21:35:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2F7608FC12; Thu, 17 Nov 2011 21:35:09 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 832A946B06; Thu, 17 Nov 2011 16:35:08 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 264B98A050; Thu, 17 Nov 2011 16:35:08 -0500 (EST) From: John Baldwin To: Andriy Gapon Date: Thu, 17 Nov 2011 16:35:07 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111171409.37629.jhb@freebsd.org> <4EC563BB.60209@FreeBSD.org> In-Reply-To: <4EC563BB.60209@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111171635.07278.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 17 Nov 2011 16:35:08 -0500 (EST) Cc: Kostik Belousov , Alexander Motin , freebsd-current@freebsd.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 21:35:09 -0000 On Thursday, November 17, 2011 2:42:51 pm Andriy Gapon wrote: > on 17/11/2011 21:09 John Baldwin said the following: > > On Thursday, November 17, 2011 11:58:03 am Andriy Gapon wrote: > >> on 17/11/2011 18:37 John Baldwin said the following: > >>> On Thursday, November 17, 2011 4:47:42 am Andriy Gapon wrote: > >>>> on 17/11/2011 10:34 Andriy Gapon said the following: > >>>>> on 17/11/2011 10:15 Kostik Belousov said the following: > >>>>>> I have the following change for eons on my test boxes. Without it, > >>>>>> I simply cannot get _any_ dump. > >>>>>> > >>>>>> diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c > >>>>>> index 10b89c7..a38e42f 100644 > >>>>>> --- a/sys/cam/cam_xpt.c > >>>>>> +++ b/sys/cam/cam_xpt.c > >>>>>> @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) > >>>>>> TAILQ_INSERT_TAIL(&cam_simq, sim, links); > >>>>>> mtx_unlock(&cam_simq_lock); > >>>>>> sim->flags |= CAM_SIM_ON_DONEQ; > >>>>>> - if (first) > >>>>>> + if (first && panicstr == NULL) > >>>>>> swi_sched(cambio_ih, 0); > >>>>>> } > >>>>>> } > >>>>> > >>>>> I think that this (or similar) change should go into the patch and the tree. > >>>>> > >>>> > >>>> And, BTW, I still would like to do something like the following (perhaps with > >>>> td_oncpu = NOCPU and td_flags &= ~TDF_NEEDRESCHED also moved to the common code): > >>>> > >>>> Index: sys/kern/sched_ule.c > >>>> =================================================================== > >>>> --- sys/kern/sched_ule.c (revision 227608) > >>>> +++ sys/kern/sched_ule.c (working copy) > >>>> @@ -1790,7 +1790,6 @@ sched_switch(struct thread *td, struct thread *new > >>>> td->td_oncpu = NOCPU; > >>>> if (!(flags & SW_PREEMPT)) > >>>> td->td_flags &= ~TDF_NEEDRESCHED; > >>>> - td->td_owepreempt = 0; > >>>> tdq->tdq_switchcnt++; > >>>> /* > >>>> * The lock pointer in an idle thread should never change. Reset it > >>>> Index: sys/kern/kern_synch.c > >>>> =================================================================== > >>>> --- sys/kern/kern_synch.c (revision 227608) > >>>> +++ sys/kern/kern_synch.c (working copy) > >>>> @@ -406,6 +406,8 @@ mi_switch(int flags, struct thread *newtd) > >>>> ("mi_switch: switch must be voluntary or involuntary")); > >>>> KASSERT(newtd != curthread, ("mi_switch: preempting back to ourself")); > >>>> > >>>> + td->td_owepreempt = 0; > >>>> + > >>>> /* > >>>> * Don't perform context switches from the debugger. > >>>> */ > >>>> Index: sys/kern/sched_4bsd.c > >>>> =================================================================== > >>>> --- sys/kern/sched_4bsd.c (revision 227608) > >>>> +++ sys/kern/sched_4bsd.c (working copy) > >>>> @@ -940,7 +940,6 @@ sched_switch(struct thread *td, struct thread *new > >>>> td->td_lastcpu = td->td_oncpu; > >>>> if (!(flags & SW_PREEMPT)) > >>>> td->td_flags &= ~TDF_NEEDRESCHED; > >>>> - td->td_owepreempt = 0; > >>>> td->td_oncpu = NOCPU; > >>>> > >>>> /* > >>>> > >>>> Does anybody see any potential problems with such a change? > >>> > >>> Hmm, does this mean the preemption will be lost if you break into the > >>> debugger and continue in the non-panic case? > >> > >> Not sure which exact scenario you have in mind. > >> Please note that the above diff just moves resetting of td_owepreempt to an > >> earlier place. As far as I can see there are no checks of td_owepreempt value > >> between the new place and the old places. > > > > I'm worried that you are clearing td_owepreempt even in cases where a context > > switch is not performed. So say you enter DDB with td_owepreempt set and that > > DDB bails on a context switch. With your change it will now clear td_owepreempt > > and "lose" the preemption. > > > > And without the change we get the recursion and double-fault because of > kdb_switch -> thread_unlock -> spinlock_exit -> critical_exit -> > mi_switch in this case ? > > BTW, it is my opinion that we really should not let the debugger code call > mi_switch for any reason. Hmmm, you could also make critical_exit() not perform deferred preemptions if SCHEDULER_STOPPED? That would fix the recursion and still let the preemption "work" when resuming from the debugger? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 21:38:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0DB51065675; Thu, 17 Nov 2011 21:38:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B6C2E8FC13; Thu, 17 Nov 2011 21:38:04 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 66B4A46B0A; Thu, 17 Nov 2011 16:38:04 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C50E38A050; Thu, 17 Nov 2011 16:38:03 -0500 (EST) From: John Baldwin To: Andriy Gapon Date: Thu, 17 Nov 2011 16:38:03 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <4EC563BB.60209@FreeBSD.org> <201111171635.07278.jhb@freebsd.org> In-Reply-To: <201111171635.07278.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111171638.03208.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 17 Nov 2011 16:38:04 -0500 (EST) Cc: Kostik Belousov , Alexander Motin , freebsd-current@freebsd.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 21:38:05 -0000 On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote: > On Thursday, November 17, 2011 2:42:51 pm Andriy Gapon wrote: > > on 17/11/2011 21:09 John Baldwin said the following: > > > On Thursday, November 17, 2011 11:58:03 am Andriy Gapon wrote: > > >> on 17/11/2011 18:37 John Baldwin said the following: > > >>> On Thursday, November 17, 2011 4:47:42 am Andriy Gapon wrote: > > >>>> on 17/11/2011 10:34 Andriy Gapon said the following: > > >>>>> on 17/11/2011 10:15 Kostik Belousov said the following: > > >>>>>> I have the following change for eons on my test boxes. Without it, > > >>>>>> I simply cannot get _any_ dump. > > >>>>>> > > >>>>>> diff --git a/sys/cam/cam_xpt.c b/sys/cam/cam_xpt.c > > >>>>>> index 10b89c7..a38e42f 100644 > > >>>>>> --- a/sys/cam/cam_xpt.c > > >>>>>> +++ b/sys/cam/cam_xpt.c > > >>>>>> @@ -4230,7 +4230,7 @@ xpt_done(union ccb *done_ccb) > > >>>>>> TAILQ_INSERT_TAIL(&cam_simq, sim, links); > > >>>>>> mtx_unlock(&cam_simq_lock); > > >>>>>> sim->flags |= CAM_SIM_ON_DONEQ; > > >>>>>> - if (first) > > >>>>>> + if (first && panicstr == NULL) > > >>>>>> swi_sched(cambio_ih, 0); > > >>>>>> } > > >>>>>> } > > >>>>> > > >>>>> I think that this (or similar) change should go into the patch and the tree. > > >>>>> > > >>>> > > >>>> And, BTW, I still would like to do something like the following (perhaps with > > >>>> td_oncpu = NOCPU and td_flags &= ~TDF_NEEDRESCHED also moved to the common code): > > >>>> > > >>>> Index: sys/kern/sched_ule.c > > >>>> =================================================================== > > >>>> --- sys/kern/sched_ule.c (revision 227608) > > >>>> +++ sys/kern/sched_ule.c (working copy) > > >>>> @@ -1790,7 +1790,6 @@ sched_switch(struct thread *td, struct thread *new > > >>>> td->td_oncpu = NOCPU; > > >>>> if (!(flags & SW_PREEMPT)) > > >>>> td->td_flags &= ~TDF_NEEDRESCHED; > > >>>> - td->td_owepreempt = 0; > > >>>> tdq->tdq_switchcnt++; > > >>>> /* > > >>>> * The lock pointer in an idle thread should never change. Reset it > > >>>> Index: sys/kern/kern_synch.c > > >>>> =================================================================== > > >>>> --- sys/kern/kern_synch.c (revision 227608) > > >>>> +++ sys/kern/kern_synch.c (working copy) > > >>>> @@ -406,6 +406,8 @@ mi_switch(int flags, struct thread *newtd) > > >>>> ("mi_switch: switch must be voluntary or involuntary")); > > >>>> KASSERT(newtd != curthread, ("mi_switch: preempting back to ourself")); > > >>>> > > >>>> + td->td_owepreempt = 0; > > >>>> + > > >>>> /* > > >>>> * Don't perform context switches from the debugger. > > >>>> */ > > >>>> Index: sys/kern/sched_4bsd.c > > >>>> =================================================================== > > >>>> --- sys/kern/sched_4bsd.c (revision 227608) > > >>>> +++ sys/kern/sched_4bsd.c (working copy) > > >>>> @@ -940,7 +940,6 @@ sched_switch(struct thread *td, struct thread *new > > >>>> td->td_lastcpu = td->td_oncpu; > > >>>> if (!(flags & SW_PREEMPT)) > > >>>> td->td_flags &= ~TDF_NEEDRESCHED; > > >>>> - td->td_owepreempt = 0; > > >>>> td->td_oncpu = NOCPU; > > >>>> > > >>>> /* > > >>>> > > >>>> Does anybody see any potential problems with such a change? > > >>> > > >>> Hmm, does this mean the preemption will be lost if you break into the > > >>> debugger and continue in the non-panic case? > > >> > > >> Not sure which exact scenario you have in mind. > > >> Please note that the above diff just moves resetting of td_owepreempt to an > > >> earlier place. As far as I can see there are no checks of td_owepreempt value > > >> between the new place and the old places. > > > > > > I'm worried that you are clearing td_owepreempt even in cases where a context > > > switch is not performed. So say you enter DDB with td_owepreempt set and that > > > DDB bails on a context switch. With your change it will now clear td_owepreempt > > > and "lose" the preemption. > > > > > > > And without the change we get the recursion and double-fault because of > > kdb_switch -> thread_unlock -> spinlock_exit -> critical_exit -> > > mi_switch in this case ? > > > > BTW, it is my opinion that we really should not let the debugger code call > > mi_switch for any reason. > > Hmmm, you could also make critical_exit() not perform deferred preemptions > if SCHEDULER_STOPPED? That would fix the recursion and still let the > preemption "work" when resuming from the debugger? Or you could let the debugger run in a permament critical section (though perhaps that breaks too many other things like debugger routines that try to use locks like the 'kill' command (which is useful!)). Effectively what you are trying to do is having the debugger run in a critical section until the debugger is exited. It would be cleanest to let it run that way explicitly if possible since then you don't have to catch as many edge cases. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 21:44:06 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 479C9106566B; Thu, 17 Nov 2011 21:44:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 15FD18FC19; Thu, 17 Nov 2011 21:44:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHLi5XX093486; Thu, 17 Nov 2011 16:44:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHLi5Bx093477; Thu, 17 Nov 2011 21:44:05 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 21:44:05 GMT Message-Id: <201111172144.pAHLi5Bx093477@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 21:44:06 -0000 TB --- 2011-11-17 19:55:19 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 19:55:19 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-17 19:55:19 - cleaning the object tree TB --- 2011-11-17 19:55:32 - cvsupping the source tree TB --- 2011-11-17 19:55:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-17 19:55:45 - building world TB --- 2011-11-17 19:55:45 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 19:55:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 19:55:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 19:55:45 - SRCCONF=/dev/null TB --- 2011-11-17 19:55:45 - TARGET=ia64 TB --- 2011-11-17 19:55:45 - TARGET_ARCH=ia64 TB --- 2011-11-17 19:55:45 - TZ=UTC TB --- 2011-11-17 19:55:45 - __MAKE_CONF=/dev/null TB --- 2011-11-17 19:55:45 - cd /src TB --- 2011-11-17 19:55:45 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 19:55:45 UTC 2011 >>> 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 Thu Nov 17 21:24:15 UTC 2011 TB --- 2011-11-17 21:24:15 - generating LINT kernel config TB --- 2011-11-17 21:24:15 - cd /src/sys/ia64/conf TB --- 2011-11-17 21:24:15 - /usr/bin/make -B LINT TB --- 2011-11-17 21:24:15 - cd /src/sys/ia64/conf TB --- 2011-11-17 21:24:15 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 21:24:15 - building GENERIC kernel TB --- 2011-11-17 21:24:15 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 21:24:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 21:24:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 21:24:15 - SRCCONF=/dev/null TB --- 2011-11-17 21:24:15 - TARGET=ia64 TB --- 2011-11-17 21:24:15 - TARGET_ARCH=ia64 TB --- 2011-11-17 21:24:15 - TZ=UTC TB --- 2011-11-17 21:24:15 - __MAKE_CONF=/dev/null TB --- 2011-11-17 21:24:15 - cd /src TB --- 2011-11-17 21:24:15 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 21:24:16 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/ia64.ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/ia64.ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64.ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 21:44:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 21:44:04 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 21:44:04 - 5182.73 user 962.91 system 6525.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 22:52:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9B55106566C for ; Thu, 17 Nov 2011 22:52:01 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id 179E28FC15 for ; Thu, 17 Nov 2011 22:52:00 +0000 (UTC) Received: from [IPv6:2001:470:28:140:e8a7:587b:e87a:a0ec] ([IPv6:2001:470:28:140:e8a7:587b:e87a:a0ec]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.5) with ESMTP id pAHMpukT068319 for ; Fri, 18 Nov 2011 00:51:57 +0200 (EET) (envelope-from universite@ukr.net) Message-ID: <4EC58FFA.6070602@ukr.net> Date: Fri, 18 Nov 2011 00:51:38 +0200 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4EC565A0.8090708@ukr.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Fri, 18 Nov 2011 00:51:57 +0200 (EET) X-Spam-Status: No, score=-97.7 required=5.0 tests=FREEMAIL_FROM,RDNS_NONE, SPF_SOFTFAIL,T_TO_NO_BRKTS_FREEMAIL,USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua Subject: Re: Why not on the ftp fresh snapshot iso? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 22:52:01 -0000 17.11.2011 23:28, Garrett Cooper wrote: > On Thu, Nov 17, 2011 at 11:50 AM, Vladislav V. Prodan > wrote: >> I'm interested in 8.2 (August-September) and 9.0 (beta) for amd64. >> Where to download their iso? > > http://lists.freebsd.org/pipermail/freebsd-current/2011-November/029373.html And why could not create ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/9.0-RC2/ ? And put in a non-obvious directory ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/9.0/ ? -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 23:03:46 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1269A1065673; Thu, 17 Nov 2011 23:03:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D179D8FC15; Thu, 17 Nov 2011 23:03:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHN3ihG056129; Thu, 17 Nov 2011 18:03:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHN3hTs056091; Thu, 17 Nov 2011 23:03:44 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 23:03:44 GMT Message-Id: <201111172303.pAHN3hTs056091@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 23:03:46 -0000 TB --- 2011-11-17 20:47:47 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 20:47:47 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-17 20:47:47 - cleaning the object tree TB --- 2011-11-17 20:48:01 - cvsupping the source tree TB --- 2011-11-17 20:48:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-17 20:48:15 - building world TB --- 2011-11-17 20:48:15 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 20:48:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 20:48:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 20:48:15 - SRCCONF=/dev/null TB --- 2011-11-17 20:48:15 - TARGET=powerpc TB --- 2011-11-17 20:48:15 - TARGET_ARCH=powerpc TB --- 2011-11-17 20:48:15 - TZ=UTC TB --- 2011-11-17 20:48:15 - __MAKE_CONF=/dev/null TB --- 2011-11-17 20:48:15 - cd /src TB --- 2011-11-17 20:48:15 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 20:48:15 UTC 2011 >>> 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 Thu Nov 17 22:50:00 UTC 2011 TB --- 2011-11-17 22:50:00 - generating LINT kernel config TB --- 2011-11-17 22:50:00 - cd /src/sys/powerpc/conf TB --- 2011-11-17 22:50:00 - /usr/bin/make -B LINT TB --- 2011-11-17 22:50:00 - cd /src/sys/powerpc/conf TB --- 2011-11-17 22:50:00 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 22:50:00 - building GENERIC kernel TB --- 2011-11-17 22:50:00 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 22:50:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 22:50:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 22:50:00 - SRCCONF=/dev/null TB --- 2011-11-17 22:50:00 - TARGET=powerpc TB --- 2011-11-17 22:50:00 - TARGET_ARCH=powerpc TB --- 2011-11-17 22:50:00 - TZ=UTC TB --- 2011-11-17 22:50:00 - __MAKE_CONF=/dev/null TB --- 2011-11-17 22:50:00 - cd /src TB --- 2011-11-17 22:50:00 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 22:50:01 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 23:03:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 23:03:43 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 23:03:43 - 6528.48 user 1127.16 system 8155.85 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 23:06:16 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D40F106564A; Thu, 17 Nov 2011 23:06:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 591398FC14; Thu, 17 Nov 2011 23:06:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHN6F0k069825; Thu, 17 Nov 2011 18:06:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHN6FPO069824; Thu, 17 Nov 2011 23:06:15 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 23:06:15 GMT Message-Id: <201111172306.pAHN6FPO069824@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 23:06:16 -0000 TB --- 2011-11-17 21:44:05 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 21:44:05 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-11-17 21:44:05 - cleaning the object tree TB --- 2011-11-17 21:44:16 - cvsupping the source tree TB --- 2011-11-17 21:44:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-11-17 21:44:27 - building world TB --- 2011-11-17 21:44:27 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 21:44:27 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 21:44:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 21:44:27 - SRCCONF=/dev/null TB --- 2011-11-17 21:44:27 - TARGET=sparc64 TB --- 2011-11-17 21:44:27 - TARGET_ARCH=sparc64 TB --- 2011-11-17 21:44:27 - TZ=UTC TB --- 2011-11-17 21:44:27 - __MAKE_CONF=/dev/null TB --- 2011-11-17 21:44:27 - cd /src TB --- 2011-11-17 21:44:27 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 21:44:28 UTC 2011 >>> 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 Thu Nov 17 22:50:44 UTC 2011 TB --- 2011-11-17 22:50:44 - generating LINT kernel config TB --- 2011-11-17 22:50:44 - cd /src/sys/sparc64/conf TB --- 2011-11-17 22:50:44 - /usr/bin/make -B LINT TB --- 2011-11-17 22:50:44 - cd /src/sys/sparc64/conf TB --- 2011-11-17 22:50:44 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 22:50:44 - building GENERIC kernel TB --- 2011-11-17 22:50:44 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 22:50:44 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 22:50:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 22:50:44 - SRCCONF=/dev/null TB --- 2011-11-17 22:50:44 - TARGET=sparc64 TB --- 2011-11-17 22:50:44 - TARGET_ARCH=sparc64 TB --- 2011-11-17 22:50:44 - TZ=UTC TB --- 2011-11-17 22:50:44 - __MAKE_CONF=/dev/null TB --- 2011-11-17 22:50:44 - cd /src TB --- 2011-11-17 22:50:44 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Nov 17 22:50:44 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64.sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/sparc64.sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 23:06:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 23:06:15 - ERROR: failed to build GENERIC kernel TB --- 2011-11-17 23:06:15 - 3704.20 user 822.79 system 4930.11 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Nov 17 23:28:55 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D947106564A; Thu, 17 Nov 2011 23:28:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7179F8FC14; Thu, 17 Nov 2011 23:28:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAHNSsG1036596; Thu, 17 Nov 2011 18:28:54 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAHNSsYP036595; Thu, 17 Nov 2011 23:28:54 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 17 Nov 2011 23:28:54 GMT Message-Id: <201111172328.pAHNSsYP036595@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 23:28:55 -0000 TB --- 2011-11-17 21:36:51 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 21:36:51 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-17 21:36:51 - cleaning the object tree TB --- 2011-11-17 21:37:07 - cvsupping the source tree TB --- 2011-11-17 21:37:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-17 21:37:19 - building world TB --- 2011-11-17 21:37:19 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 21:37:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 21:37:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 21:37:19 - SRCCONF=/dev/null TB --- 2011-11-17 21:37:19 - TARGET=powerpc TB --- 2011-11-17 21:37:19 - TARGET_ARCH=powerpc64 TB --- 2011-11-17 21:37:19 - TZ=UTC TB --- 2011-11-17 21:37:19 - __MAKE_CONF=/dev/null TB --- 2011-11-17 21:37:19 - cd /src TB --- 2011-11-17 21:37:19 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 21:37:20 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Nov 17 23:15:55 UTC 2011 TB --- 2011-11-17 23:15:55 - generating LINT kernel config TB --- 2011-11-17 23:15:55 - cd /src/sys/powerpc/conf TB --- 2011-11-17 23:15:55 - /usr/bin/make -B LINT TB --- 2011-11-17 23:15:55 - cd /src/sys/powerpc/conf TB --- 2011-11-17 23:15:55 - /usr/sbin/config -m GENERIC TB --- 2011-11-17 23:15:55 - skipping GENERIC kernel TB --- 2011-11-17 23:15:55 - cd /src/sys/powerpc/conf TB --- 2011-11-17 23:15:55 - /usr/sbin/config -m GENERIC64 TB --- 2011-11-17 23:15:55 - building GENERIC64 kernel TB --- 2011-11-17 23:15:55 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 23:15:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 23:15:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 23:15:55 - SRCCONF=/dev/null TB --- 2011-11-17 23:15:55 - TARGET=powerpc TB --- 2011-11-17 23:15:55 - TARGET_ARCH=powerpc64 TB --- 2011-11-17 23:15:55 - TZ=UTC TB --- 2011-11-17 23:15:55 - __MAKE_CONF=/dev/null TB --- 2011-11-17 23:15:55 - cd /src TB --- 2011-11-17 23:15:55 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Thu Nov 17 23:15:55 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc64/src/sys/GENERIC64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc64/src/sys/GENERIC64 -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c: In function 'sfxge_ev_rx': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: implicit declaration of function 'prefetch_read_many' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c:120: warning: nested extern declaration of 'prefetch_read_many' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/GENERIC64. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-17 23:28:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-17 23:28:54 - ERROR: failed to build GENERIC64 kernel TB --- 2011-11-17 23:28:54 - 5182.24 user 1140.85 system 6723.12 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 01:15:02 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4277106564A; Fri, 18 Nov 2011 01:15:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6C5BB8FC17; Fri, 18 Nov 2011 01:15:01 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAI1F0l8004670; Thu, 17 Nov 2011 20:15:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAI1F0CE004665; Fri, 18 Nov 2011 01:15:00 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 18 Nov 2011 01:15:00 GMT Message-Id: <201111180115.pAI1F0CE004665@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 01:15:02 -0000 TB --- 2011-11-17 23:30:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 23:30:01 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-17 23:30:01 - cleaning the object tree TB --- 2011-11-17 23:30:26 - cvsupping the source tree TB --- 2011-11-17 23:30:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-17 23:30:43 - building world TB --- 2011-11-17 23:30:43 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 23:30:43 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 23:30:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 23:30:43 - SRCCONF=/dev/null TB --- 2011-11-17 23:30:43 - TARGET=arm TB --- 2011-11-17 23:30:43 - TARGET_ARCH=arm TB --- 2011-11-17 23:30:43 - TZ=UTC TB --- 2011-11-17 23:30:43 - __MAKE_CONF=/dev/null TB --- 2011-11-17 23:30:43 - cd /src TB --- 2011-11-17 23:30:43 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 23:30:45 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 18 00:26:20 UTC 2011 TB --- 2011-11-18 00:26:20 - cd /src/sys/arm/conf TB --- 2011-11-18 00:26:20 - /usr/sbin/config -m AVILA TB --- 2011-11-18 00:26:20 - building AVILA kernel TB --- 2011-11-18 00:26:20 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 00:26:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 00:26:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 00:26:20 - SRCCONF=/dev/null TB --- 2011-11-18 00:26:20 - TARGET=arm TB --- 2011-11-18 00:26:20 - TARGET_ARCH=arm TB --- 2011-11-18 00:26:20 - TZ=UTC TB --- 2011-11-18 00:26:20 - __MAKE_CONF=/dev/null TB --- 2011-11-18 00:26:20 - cd /src TB --- 2011-11-18 00:26:20 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Fri Nov 18 00:26:20 UTC 2011 >>> 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 >>> Kernel build for AVILA completed on Fri Nov 18 00:29:32 UTC 2011 TB --- 2011-11-18 00:29:32 - cd /src/sys/arm/conf TB --- 2011-11-18 00:29:32 - /usr/sbin/config -m BWCT TB --- 2011-11-18 00:29:32 - building BWCT kernel TB --- 2011-11-18 00:29:32 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 00:29:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 00:29:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 00:29:32 - SRCCONF=/dev/null TB --- 2011-11-18 00:29:32 - TARGET=arm TB --- 2011-11-18 00:29:32 - TARGET_ARCH=arm TB --- 2011-11-18 00:29:32 - TZ=UTC TB --- 2011-11-18 00:29:32 - __MAKE_CONF=/dev/null TB --- 2011-11-18 00:29:32 - cd /src TB --- 2011-11-18 00:29:32 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Fri Nov 18 00:29:32 UTC 2011 >>> 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 >>> Kernel build for BWCT completed on Fri Nov 18 00:31:55 UTC 2011 TB --- 2011-11-18 00:31:55 - cd /src/sys/arm/conf TB --- 2011-11-18 00:31:55 - /usr/sbin/config -m CAMBRIA TB --- 2011-11-18 00:31:55 - building CAMBRIA kernel TB --- 2011-11-18 00:31:55 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 00:31:55 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 00:31:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 00:31:55 - SRCCONF=/dev/null TB --- 2011-11-18 00:31:55 - TARGET=arm TB --- 2011-11-18 00:31:55 - TARGET_ARCH=arm TB --- 2011-11-18 00:31:55 - TZ=UTC TB --- 2011-11-18 00:31:55 - __MAKE_CONF=/dev/null TB --- 2011-11-18 00:31:55 - cd /src TB --- 2011-11-18 00:31:55 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Fri Nov 18 00:31:55 UTC 2011 >>> 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 >>> Kernel build for CAMBRIA completed on Fri Nov 18 00:34:51 UTC 2011 TB --- 2011-11-18 00:34:51 - cd /src/sys/arm/conf TB --- 2011-11-18 00:34:51 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-11-18 00:34:51 - building CNS11XXNAS kernel TB --- 2011-11-18 00:34:51 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 00:34:51 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 00:34:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 00:34:51 - SRCCONF=/dev/null TB --- 2011-11-18 00:34:51 - TARGET=arm TB --- 2011-11-18 00:34:51 - TARGET_ARCH=arm TB --- 2011-11-18 00:34:51 - TZ=UTC TB --- 2011-11-18 00:34:51 - __MAKE_CONF=/dev/null TB --- 2011-11-18 00:34:51 - cd /src TB --- 2011-11-18 00:34:51 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Fri Nov 18 00:34:51 UTC 2011 >>> 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 >>> Kernel build for CNS11XXNAS completed on Fri Nov 18 00:37:20 UTC 2011 TB --- 2011-11-18 00:37:20 - cd /src/sys/arm/conf TB --- 2011-11-18 00:37:20 - /usr/sbin/config -m CRB TB --- 2011-11-18 00:37:20 - building CRB kernel TB --- 2011-11-18 00:37:20 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 00:37:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 00:37:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 00:37:20 - SRCCONF=/dev/null TB --- 2011-11-18 00:37:20 - TARGET=arm TB --- 2011-11-18 00:37:20 - TARGET_ARCH=arm TB --- 2011-11-18 00:37:20 - TZ=UTC TB --- 2011-11-18 00:37:20 - __MAKE_CONF=/dev/null TB --- 2011-11-18 00:37:20 - cd /src TB --- 2011-11-18 00:37:20 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Fri Nov 18 00:37:20 UTC 2011 >>> 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 >>> Kernel build for CRB completed on Fri Nov 18 00:41:07 UTC 2011 TB --- 2011-11-18 00:41:07 - cd /src/sys/arm/conf TB --- 2011-11-18 00:41:07 - /usr/sbin/config -m DB-78XXX TB --- 2011-11-18 00:41:07 - building DB-78XXX kernel TB --- 2011-11-18 00:41:07 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 00:41:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 00:41:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 00:41:07 - SRCCONF=/dev/null TB --- 2011-11-18 00:41:07 - TARGET=arm TB --- 2011-11-18 00:41:07 - TARGET_ARCH=arm TB --- 2011-11-18 00:41:07 - TZ=UTC TB --- 2011-11-18 00:41:07 - __MAKE_CONF=/dev/null TB --- 2011-11-18 00:41:07 - cd /src TB --- 2011-11-18 00:41:07 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Fri Nov 18 00:41:07 UTC 2011 >>> 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 >>> Kernel build for DB-78XXX completed on Fri Nov 18 00:43:58 UTC 2011 TB --- 2011-11-18 00:43:58 - cd /src/sys/arm/conf TB --- 2011-11-18 00:43:58 - /usr/sbin/config -m DB-88F5XXX TB --- 2011-11-18 00:43:58 - building DB-88F5XXX kernel TB --- 2011-11-18 00:43:58 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 00:43:58 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 00:43:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 00:43:58 - SRCCONF=/dev/null TB --- 2011-11-18 00:43:58 - TARGET=arm TB --- 2011-11-18 00:43:58 - TARGET_ARCH=arm TB --- 2011-11-18 00:43:58 - TZ=UTC TB --- 2011-11-18 00:43:58 - __MAKE_CONF=/dev/null TB --- 2011-11-18 00:43:58 - cd /src TB --- 2011-11-18 00:43:58 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Fri Nov 18 00:43:58 UTC 2011 >>> 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 >>> Kernel build for DB-88F5XXX completed on Fri Nov 18 00:46:36 UTC 2011 TB --- 2011-11-18 00:46:36 - cd /src/sys/arm/conf TB --- 2011-11-18 00:46:36 - /usr/sbin/config -m DB-88F6XXX TB --- 2011-11-18 00:46:36 - building DB-88F6XXX kernel TB --- 2011-11-18 00:46:36 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 00:46:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 00:46:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 00:46:36 - SRCCONF=/dev/null TB --- 2011-11-18 00:46:36 - TARGET=arm TB --- 2011-11-18 00:46:36 - TARGET_ARCH=arm TB --- 2011-11-18 00:46:36 - TZ=UTC TB --- 2011-11-18 00:46:36 - __MAKE_CONF=/dev/null TB --- 2011-11-18 00:46:36 - cd /src TB --- 2011-11-18 00:46:36 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Fri Nov 18 00:46:36 UTC 2011 >>> 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 >>> Kernel build for DB-88F6XXX completed on Fri Nov 18 00:49:15 UTC 2011 TB --- 2011-11-18 00:49:15 - cd /src/sys/arm/conf TB --- 2011-11-18 00:49:15 - /usr/sbin/config -m DOCKSTAR TB --- 2011-11-18 00:49:15 - building DOCKSTAR kernel TB --- 2011-11-18 00:49:15 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 00:49:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 00:49:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 00:49:15 - SRCCONF=/dev/null TB --- 2011-11-18 00:49:15 - TARGET=arm TB --- 2011-11-18 00:49:15 - TARGET_ARCH=arm TB --- 2011-11-18 00:49:15 - TZ=UTC TB --- 2011-11-18 00:49:15 - __MAKE_CONF=/dev/null TB --- 2011-11-18 00:49:15 - cd /src TB --- 2011-11-18 00:49:15 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Fri Nov 18 00:49:15 UTC 2011 >>> 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 >>> Kernel build for DOCKSTAR completed on Fri Nov 18 00:52:11 UTC 2011 TB --- 2011-11-18 00:52:11 - cd /src/sys/arm/conf TB --- 2011-11-18 00:52:11 - /usr/sbin/config -m EP80219 TB --- 2011-11-18 00:52:11 - building EP80219 kernel TB --- 2011-11-18 00:52:11 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 00:52:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 00:52:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 00:52:11 - SRCCONF=/dev/null TB --- 2011-11-18 00:52:11 - TARGET=arm TB --- 2011-11-18 00:52:11 - TARGET_ARCH=arm TB --- 2011-11-18 00:52:11 - TZ=UTC TB --- 2011-11-18 00:52:11 - __MAKE_CONF=/dev/null TB --- 2011-11-18 00:52:11 - cd /src TB --- 2011-11-18 00:52:11 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Fri Nov 18 00:52:11 UTC 2011 >>> 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 >>> Kernel build for EP80219 completed on Fri Nov 18 00:55:07 UTC 2011 TB --- 2011-11-18 00:55:07 - WARNING: no kernel config for GENERIC TB --- 2011-11-18 00:55:07 - cd /src/sys/arm/conf TB --- 2011-11-18 00:55:07 - /usr/sbin/config -m GUMSTIX TB --- 2011-11-18 00:55:07 - building GUMSTIX kernel TB --- 2011-11-18 00:55:07 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 00:55:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 00:55:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 00:55:07 - SRCCONF=/dev/null TB --- 2011-11-18 00:55:07 - TARGET=arm TB --- 2011-11-18 00:55:07 - TARGET_ARCH=arm TB --- 2011-11-18 00:55:07 - TZ=UTC TB --- 2011-11-18 00:55:07 - __MAKE_CONF=/dev/null TB --- 2011-11-18 00:55:07 - cd /src TB --- 2011-11-18 00:55:07 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Fri Nov 18 00:55:07 UTC 2011 >>> 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 >>> Kernel build for GUMSTIX completed on Fri Nov 18 00:57:26 UTC 2011 TB --- 2011-11-18 00:57:26 - cd /src/sys/arm/conf TB --- 2011-11-18 00:57:26 - /usr/sbin/config -m HL200 TB --- 2011-11-18 00:57:26 - building HL200 kernel TB --- 2011-11-18 00:57:26 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 00:57:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 00:57:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 00:57:26 - SRCCONF=/dev/null TB --- 2011-11-18 00:57:26 - TARGET=arm TB --- 2011-11-18 00:57:26 - TARGET_ARCH=arm TB --- 2011-11-18 00:57:26 - TZ=UTC TB --- 2011-11-18 00:57:26 - __MAKE_CONF=/dev/null TB --- 2011-11-18 00:57:26 - cd /src TB --- 2011-11-18 00:57:26 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Fri Nov 18 00:57:26 UTC 2011 >>> 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 >>> Kernel build for HL200 completed on Fri Nov 18 01:00:05 UTC 2011 TB --- 2011-11-18 01:00:05 - cd /src/sys/arm/conf TB --- 2011-11-18 01:00:05 - /usr/sbin/config -m HL201 TB --- 2011-11-18 01:00:05 - building HL201 kernel TB --- 2011-11-18 01:00:05 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 01:00:05 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 01:00:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 01:00:05 - SRCCONF=/dev/null TB --- 2011-11-18 01:00:05 - TARGET=arm TB --- 2011-11-18 01:00:05 - TARGET_ARCH=arm TB --- 2011-11-18 01:00:05 - TZ=UTC TB --- 2011-11-18 01:00:05 - __MAKE_CONF=/dev/null TB --- 2011-11-18 01:00:05 - cd /src TB --- 2011-11-18 01:00:05 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Fri Nov 18 01:00:05 UTC 2011 >>> 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 >>> Kernel build for HL201 completed on Fri Nov 18 01:02:21 UTC 2011 TB --- 2011-11-18 01:02:21 - cd /src/sys/arm/conf TB --- 2011-11-18 01:02:21 - /usr/sbin/config -m IQ31244 TB --- 2011-11-18 01:02:21 - building IQ31244 kernel TB --- 2011-11-18 01:02:21 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 01:02:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 01:02:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 01:02:21 - SRCCONF=/dev/null TB --- 2011-11-18 01:02:21 - TARGET=arm TB --- 2011-11-18 01:02:21 - TARGET_ARCH=arm TB --- 2011-11-18 01:02:21 - TZ=UTC TB --- 2011-11-18 01:02:21 - __MAKE_CONF=/dev/null TB --- 2011-11-18 01:02:21 - cd /src TB --- 2011-11-18 01:02:21 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Fri Nov 18 01:02:21 UTC 2011 >>> 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 >>> Kernel build for IQ31244 completed on Fri Nov 18 01:05:35 UTC 2011 TB --- 2011-11-18 01:05:35 - cd /src/sys/arm/conf TB --- 2011-11-18 01:05:35 - /usr/sbin/config -m KB920X TB --- 2011-11-18 01:05:36 - building KB920X kernel TB --- 2011-11-18 01:05:36 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 01:05:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 01:05:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 01:05:36 - SRCCONF=/dev/null TB --- 2011-11-18 01:05:36 - TARGET=arm TB --- 2011-11-18 01:05:36 - TARGET_ARCH=arm TB --- 2011-11-18 01:05:36 - TZ=UTC TB --- 2011-11-18 01:05:36 - __MAKE_CONF=/dev/null TB --- 2011-11-18 01:05:36 - cd /src TB --- 2011-11-18 01:05:36 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Fri Nov 18 01:05:36 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-18 01:15:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-18 01:15:00 - ERROR: failed to build KB920X kernel TB --- 2011-11-18 01:15:00 - 4679.62 user 1157.59 system 6299.07 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 01:26:34 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F2371065670 for ; Fri, 18 Nov 2011 01:26:34 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id CBAB38FC14 for ; Fri, 18 Nov 2011 01:26:33 +0000 (UTC) Received: by iakl21 with SMTP id l21so4263098iak.13 for ; Thu, 17 Nov 2011 17:26:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=npWgE1RwjEFuUvA6pJiiQs7BrzOGY7UHwfYNeg87DwU=; b=JM0eejiwn2wWE6rhoiLIkfHRyL2pcEgE+Tqzdie6472H5Swn4VuxsrpgHDtHfw/e67 abUMvfAwUSpgNnSTYgbHZojO2xXokERFrS7lWgNzSXDAe6IyBfQ7RF2BAmLJl/dObWFA 50nUvQWq89QfSCn33g2Oc3hdRqiuMmgl1XdLk= Received: by 10.42.19.195 with SMTP id d3mr31720icb.21.1321579593227; Thu, 17 Nov 2011 17:26:33 -0800 (PST) Received: from kruse-180.4.ixsystems.com (drawbridge.ixsystems.com. [206.40.55.65]) by mx.google.com with ESMTPS id dd36sm64599535ibb.7.2011.11.17.17.26.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 17:26:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <4EC58FFA.6070602@ukr.net> Date: Thu, 17 Nov 2011 17:26:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <11BCAFDD-71D9-404A-82C4-0160E751880C@gmail.com> References: <4EC565A0.8090708@ukr.net> <4EC58FFA.6070602@ukr.net> To: "Vladislav V. Prodan" X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: Why not on the ftp fresh snapshot iso? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 01:26:34 -0000 On Nov 17, 2011, at 2:51 PM, Vladislav V. Prodan wrote: > 17.11.2011 23:28, Garrett Cooper wrote: >> On Thu, Nov 17, 2011 at 11:50 AM, Vladislav V. Prodan >> wrote: >>> I'm interested in 8.2 (August-September) and 9.0 (beta) for amd64. >>> Where to download their iso? >>=20 >> = http://lists.freebsd.org/pipermail/freebsd-current/2011-November/029373.ht= ml >=20 > And why could not create > ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/9.0-RC2/ ? > And put in a non-obvious directory > ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/9.0/ = ? Search through the archives and you'll discover why things are this way. -Garrett= From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 01:36:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E98E106566C for ; Fri, 18 Nov 2011 01:36:59 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id E7EF98FC15 for ; Fri, 18 Nov 2011 01:36:58 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBE919.dip.t-dialin.net [93.203.233.25]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id pAI1ath8059645; Fri, 18 Nov 2011 01:36:56 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id pAI1ags6012716; Fri, 18 Nov 2011 02:36:43 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id pAI1aUYg039671; Fri, 18 Nov 2011 01:36:36 GMT (envelope-from jhs@fire.js.berklix.net) Message-Id: <201111180136.pAI1aUYg039671@fire.js.berklix.net> To: Dan The Man From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 17 Nov 2011 07:37:32 CST." Date: Fri, 18 Nov 2011 02:36:30 +0100 Sender: jhs@berklix.com Cc: freebsd-current@freebsd.org Subject: Re: spamcop abuse of power X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 01:36:59 -0000 Reference: > From: Dan The Man > Date: Thu, 17 Nov 2011 07:37:32 -0600 (CST) Dan The Man wrote: > > Today I had an unhappy unix student try to submit an assignment to me and > could not. Spamcop has decided to go off blacklisting all yahoo/shaw etc > servers worldwide. > > Example Solution Postfix: > remove: reject_rbl_client bl.spamcop.net > from your smtpd_recipient_restrictions line until they fix their abuse > issues. Better not dump Spamcop, Better let people dump Yahoo. Yahoo deserve grief since they abandoned their abuse@ address some time back. Yahoo make money hosting email, some inevitably spammers, but when innocent domain admin recipients (inc. me) forward spam from Yahoo customers back to abuse@Yahoo, Yahoo toss it back demanding we work unpaid for Yahoo, analaysing their spam & filling a Yahoo web form. I'm an unpaid admin, & Yahoo wastes my time. I recall Yahoo laid off some admins a while after they abandoned abuse@, offloading spam processing on innocent recipients must have helped reduce their business. Though latest RFC may no longer require an abuse@ address, & might consider an http: form acceptable, who but a commercial ISP's lobbyist would consider that transfer & imposition of work from polluting transmitter domain to innocent recioient domain as fair ? From a paid profiting commercial ISP source of the spam, paid to work, to instead burden innocent admins, some of whom arent even paid to admin. BTW One can still forward spam back to postmaster@yahoo, (eg after it bounces from abuse@) (prob cos if no postmaster@ they'd be in breach of RFCs , another reason to block). Yahoo then don't just send "We zapped that spammer account" responses - Yahoo send questionaires to consume more of your time. Yahoo need disciplining. Spamcop does not report blocked @ Fri Nov 18 02:10:40 CET 2011 http://www.spamcop.net/w3m?action=checkblock&ip=212.82.109.132 Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, & indent with "> ". Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 01:54:48 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE1EE1065672; Fri, 18 Nov 2011 01:54:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8958FC12; Fri, 18 Nov 2011 01:54:48 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAI1sl2P004054; Thu, 17 Nov 2011 20:54:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAI1slwF004031; Fri, 18 Nov 2011 01:54:47 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 18 Nov 2011 01:54:47 GMT Message-Id: <201111180154.pAI1slwF004031@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 01:54:48 -0000 TB --- 2011-11-17 23:30:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 23:30:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-11-17 23:30:01 - cleaning the object tree TB --- 2011-11-17 23:30:25 - cvsupping the source tree TB --- 2011-11-17 23:30:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-11-17 23:30:41 - building world TB --- 2011-11-17 23:30:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 23:30:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 23:30:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 23:30:41 - SRCCONF=/dev/null TB --- 2011-11-17 23:30:41 - TARGET=pc98 TB --- 2011-11-17 23:30:41 - TARGET_ARCH=i386 TB --- 2011-11-17 23:30:41 - TZ=UTC TB --- 2011-11-17 23:30:41 - __MAKE_CONF=/dev/null TB --- 2011-11-17 23:30:41 - cd /src TB --- 2011-11-17 23:30:41 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 23:30:42 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 18 01:39:16 UTC 2011 TB --- 2011-11-18 01:39:16 - generating LINT kernel config TB --- 2011-11-18 01:39:16 - cd /src/sys/pc98/conf TB --- 2011-11-18 01:39:16 - /usr/bin/make -B LINT TB --- 2011-11-18 01:39:17 - cd /src/sys/pc98/conf TB --- 2011-11-18 01:39:17 - /usr/sbin/config -m GENERIC TB --- 2011-11-18 01:39:17 - building GENERIC kernel TB --- 2011-11-18 01:39:17 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 01:39:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 01:39:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 01:39:17 - SRCCONF=/dev/null TB --- 2011-11-18 01:39:17 - TARGET=pc98 TB --- 2011-11-18 01:39:17 - TARGET_ARCH=i386 TB --- 2011-11-18 01:39:17 - TZ=UTC TB --- 2011-11-18 01:39:17 - __MAKE_CONF=/dev/null TB --- 2011-11-18 01:39:17 - cd /src TB --- 2011-11-18 01:39:17 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Nov 18 01:39:17 UTC 2011 >>> 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 [...] objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98.i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/pc98.i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98.i386/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-18 01:54:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-18 01:54:47 - ERROR: failed to build GENERIC kernel TB --- 2011-11-18 01:54:47 - 6939.74 user 1226.12 system 8686.42 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 02:05:54 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27F771065670; Fri, 18 Nov 2011 02:05:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id EF1378FC08; Fri, 18 Nov 2011 02:05:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAI25qKV086842; Thu, 17 Nov 2011 21:05:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAI25q7d086837; Fri, 18 Nov 2011 02:05:52 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 18 Nov 2011 02:05:52 GMT Message-Id: <201111180205.pAI25q7d086837@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 02:05:54 -0000 TB --- 2011-11-17 23:30:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-17 23:30:01 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-17 23:30:01 - cleaning the object tree TB --- 2011-11-17 23:30:25 - cvsupping the source tree TB --- 2011-11-17 23:30:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-17 23:30:41 - building world TB --- 2011-11-17 23:30:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-17 23:30:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-17 23:30:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-17 23:30:41 - SRCCONF=/dev/null TB --- 2011-11-17 23:30:41 - TARGET=i386 TB --- 2011-11-17 23:30:41 - TARGET_ARCH=i386 TB --- 2011-11-17 23:30:41 - TZ=UTC TB --- 2011-11-17 23:30:41 - __MAKE_CONF=/dev/null TB --- 2011-11-17 23:30:41 - cd /src TB --- 2011-11-17 23:30:41 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 17 23:30:42 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 18 01:39:48 UTC 2011 TB --- 2011-11-18 01:39:48 - generating LINT kernel config TB --- 2011-11-18 01:39:48 - cd /src/sys/i386/conf TB --- 2011-11-18 01:39:48 - /usr/bin/make -B LINT TB --- 2011-11-18 01:39:48 - cd /src/sys/i386/conf TB --- 2011-11-18 01:39:48 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-18 01:39:48 - building LINT-NOINET kernel TB --- 2011-11-18 01:39:48 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 01:39:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 01:39:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 01:39:48 - SRCCONF=/dev/null TB --- 2011-11-18 01:39:48 - TARGET=i386 TB --- 2011-11-18 01:39:48 - TARGET_ARCH=i386 TB --- 2011-11-18 01:39:48 - TZ=UTC TB --- 2011-11-18 01:39:48 - __MAKE_CONF=/dev/null TB --- 2011-11-18 01:39:48 - cd /src TB --- 2011-11-18 01:39:48 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Fri Nov 18 01:39:48 UTC 2011 >>> 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 [...] ld -Bshareable -d -warn-common -o if_sf.ko if_sf.kld objcopy --strip-debug if_sf.ko ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT-NOINET/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/i386.i386/src/sys/LINT-NOINET -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/LINT-NOINET/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/i386.i386/src/sys/LINT-NOINET -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function 'sfxge_dma_alloc': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large integer implicitly truncated to unsigned type [-Woverflow] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-18 02:05:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-18 02:05:52 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-18 02:05:52 - 7506.80 user 1268.89 system 9351.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 03:54:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF5921065673 for ; Fri, 18 Nov 2011 03:54:50 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id 49B038FC0C for ; Fri, 18 Nov 2011 03:54:49 +0000 (UTC) X-AuditID: 12074422-b7ff56d00000092f-e7-4ec5d709232b Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 27.A1.02351.907D5CE4; Thu, 17 Nov 2011 22:54:49 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id pAI3smxd013753; Thu, 17 Nov 2011 22:54:49 -0500 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pAI3shnG004441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Nov 2011 22:54:46 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id pAI3sfgA008021; Thu, 17 Nov 2011 22:54:41 -0500 (EST) Date: Thu, 17 Nov 2011 22:54:39 -0500 (EST) From: Benjamin Kaduk To: =?ISO-8859-15?Q?Olivier_Cochard-Labb=E9?= In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-2067485818-1321588480=:882" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42IRYrdT1+W8ftTP4O88IYs5bz4wWcw5+ZLZ 4tnWZhYHZo9pX3I8ZnyazxLAFMVlk5Kak1mWWqRvl8CVMaNxNkvBHf6KhXv3MDUw3uPpYuTk kBAwkfiz4zQjhC0mceHeerYuRi4OIYF9jBJTX92DcjYwSnTcaWaCcA4wSVydf5kFwmlglJh1 /gwrSD+LgLbEwtVn2EFsNgEViZlvNrKB2CICThJffswDizMLmEssmPaVGcQWFnCXePz+Plgv p0CgxN3n58HivAL2EncXngK7SUggQOLjzAksILaogI7E6v1TWCBqBCVOznzCAjHTX+Lrx7NM ExgFZyFJzUKSmsXIAWRbSzw7bwER1pa4f7ONbQEjyypG2ZTcKt3cxMyc4tRk3eLkxLy81CJd U73czBK91JTSTYzgEHdR2sH486DSIUYBDkYlHt6Jtkf9hFgTy4orcw8xSnIwKYnySlwDCvEl 5adUZiQWZ8QXleakFh9ilOBgVhLhbVoJlONNSaysSi3Kh0lJc7AoifNy7XTwExJITyxJzU5N LUgtgsnKcHAoSfAaXQRqFCxKTU+tSMvMKUFIM3FwggznARoeDrKYt7ggMbc4Mx0if4pRUUqc 9wNIswBIIqM0D64XloJeMYoDvSIM0c4DTF9w3a+ABjMBDc7dcwRkcEkiQkqqgbFrY0yVT5zC g6snVvTyzqhb31KpM6P1Sca959snXzGYxdh+IsD19WZOtevGE8Q69llXpE26Orew9d3xO+tE NAq7gg9bH64ob9Pfc2v/Zd8M/eaZr4SFpZ9nh66/kKIw13SOlfmC4LlLG7LFCnxEUhtKgy7a +DEfXfF/gVeU1qWPVkclutVP1SixFGckGmoxFxUnAgCGFNO2HAMAAA== Cc: freebsd-current@freebsd.org, nwhitehorn@freebsd.org Subject: Re: Can't install FreeBSD-amd64-9.0-RC2: "/mnt: out of inodes" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 03:54:50 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-2067485818-1321588480=:882 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 17 Nov 2011, Olivier Cochard-Labb=E9 wrote: > Hi all, > > I tried to install FreeBSD-9.0-RC2-amd64-dvd1.iso (SHA256 verified) on > a VM and meet a reproducible problem: > The VM has 128Mo RAM and a 4Go hard drive. > > During install process I choose these distribution sets: ports and src on= ly. > And I'm using guided partitioning / Entire Disk / All Auto > > But each time (I delete and re-create a new VM multiple times) the > installer failed during archive extraction of ports.txz (at about 88% > progress of this file extraction) with this message: > > Error while extracting ports.txz: > Can't create > 'usr/ports/databases/p5-DBIx-Sunny/pkg-plist' > > And on the background there is this message: > ...on /mnt: out of inodes > > Can someone else confirm this problem before I fill a PR ? A 4G disk is perhaps quite rare these days, but I expect that the issue is= =20 real. Please file the PR. The default block and fragment size for UFS/FFS were bumped by mckusick in= =20 r222319 (to general assent); presumably the installer should gain some=20 logic to use smaller values for smaller disks, so that the available=20 number of inodes is larger. (I presume that you have successfully=20 installed earlier releases on 4G disk, of course. Though ... I think I=20 may have, myself.) The ports tree has a very large number of small files,= =20 and is thus a very intensive user of inodes. Alas, my five minutes of searching were not enough to find where=20 bsdinstall is actually generating default filesystem options, so I=20 couldn't confirm this assumption. Thanks for the report, Ben Kaduk ---559023410-2067485818-1321588480=:882-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 04:18:07 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51EC1106566B; Fri, 18 Nov 2011 04:18:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1C28C8FC12; Fri, 18 Nov 2011 04:18:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAI4I6Sv031630; Thu, 17 Nov 2011 23:18:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAI4I6AD031610; Fri, 18 Nov 2011 04:18:06 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 18 Nov 2011 04:18:06 GMT Message-Id: <201111180418.pAI4I6AD031610@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 04:18:07 -0000 TB --- 2011-11-18 02:05:53 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-18 02:05:53 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-18 02:05:53 - cleaning the object tree TB --- 2011-11-18 02:06:04 - cvsupping the source tree TB --- 2011-11-18 02:06:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-18 02:06:17 - building world TB --- 2011-11-18 02:06:17 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 02:06:17 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 02:06:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 02:06:17 - SRCCONF=/dev/null TB --- 2011-11-18 02:06:17 - TARGET=powerpc TB --- 2011-11-18 02:06:17 - TARGET_ARCH=powerpc TB --- 2011-11-18 02:06:17 - TZ=UTC TB --- 2011-11-18 02:06:17 - __MAKE_CONF=/dev/null TB --- 2011-11-18 02:06:17 - cd /src TB --- 2011-11-18 02:06:17 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 18 02:06:17 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 18 04:04:45 UTC 2011 TB --- 2011-11-18 04:04:45 - generating LINT kernel config TB --- 2011-11-18 04:04:45 - cd /src/sys/powerpc/conf TB --- 2011-11-18 04:04:45 - /usr/bin/make -B LINT TB --- 2011-11-18 04:04:45 - cd /src/sys/powerpc/conf TB --- 2011-11-18 04:04:45 - /usr/sbin/config -m GENERIC TB --- 2011-11-18 04:04:45 - building GENERIC kernel TB --- 2011-11-18 04:04:45 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 04:04:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 04:04:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 04:04:45 - SRCCONF=/dev/null TB --- 2011-11-18 04:04:45 - TARGET=powerpc TB --- 2011-11-18 04:04:45 - TARGET_ARCH=powerpc TB --- 2011-11-18 04:04:45 - TZ=UTC TB --- 2011-11-18 04:04:45 - __MAKE_CONF=/dev/null TB --- 2011-11-18 04:04:45 - cd /src TB --- 2011-11-18 04:04:45 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Nov 18 04:04:45 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_intr.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_intr.c: In function 'sfxge_intr_message': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_intr.c:150: warning: passing argument 1 of 'atomic_cmpset_int' from incompatible pointer type *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-18 04:18:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-18 04:18:05 - ERROR: failed to build GENERIC kernel TB --- 2011-11-18 04:18:05 - 6325.37 user 1102.67 system 7932.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 06:31:23 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4AEB106566B; Fri, 18 Nov 2011 06:31:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 76C658FC0A; Fri, 18 Nov 2011 06:31:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAI6VHqj086560; Fri, 18 Nov 2011 01:31:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAI6VHPZ086559; Fri, 18 Nov 2011 06:31:17 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 18 Nov 2011 06:31:17 GMT Message-Id: <201111180631.pAI6VHPZ086559@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 06:31:23 -0000 TB --- 2011-11-18 04:50:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-18 04:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-18 04:50:00 - cleaning the object tree TB --- 2011-11-18 04:50:25 - cvsupping the source tree TB --- 2011-11-18 04:50:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-18 04:50:41 - building world TB --- 2011-11-18 04:50:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 04:50:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 04:50:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 04:50:41 - SRCCONF=/dev/null TB --- 2011-11-18 04:50:41 - TARGET=arm TB --- 2011-11-18 04:50:41 - TARGET_ARCH=arm TB --- 2011-11-18 04:50:41 - TZ=UTC TB --- 2011-11-18 04:50:41 - __MAKE_CONF=/dev/null TB --- 2011-11-18 04:50:41 - cd /src TB --- 2011-11-18 04:50:41 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 18 04:50:41 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 18 05:44:30 UTC 2011 TB --- 2011-11-18 05:44:30 - cd /src/sys/arm/conf TB --- 2011-11-18 05:44:30 - /usr/sbin/config -m AVILA TB --- 2011-11-18 05:44:31 - building AVILA kernel TB --- 2011-11-18 05:44:31 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 05:44:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 05:44:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 05:44:31 - SRCCONF=/dev/null TB --- 2011-11-18 05:44:31 - TARGET=arm TB --- 2011-11-18 05:44:31 - TARGET_ARCH=arm TB --- 2011-11-18 05:44:31 - TZ=UTC TB --- 2011-11-18 05:44:31 - __MAKE_CONF=/dev/null TB --- 2011-11-18 05:44:31 - cd /src TB --- 2011-11-18 05:44:31 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Fri Nov 18 05:44:31 UTC 2011 >>> 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 >>> Kernel build for AVILA completed on Fri Nov 18 05:47:34 UTC 2011 TB --- 2011-11-18 05:47:34 - cd /src/sys/arm/conf TB --- 2011-11-18 05:47:34 - /usr/sbin/config -m BWCT TB --- 2011-11-18 05:47:34 - building BWCT kernel TB --- 2011-11-18 05:47:34 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 05:47:34 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 05:47:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 05:47:34 - SRCCONF=/dev/null TB --- 2011-11-18 05:47:34 - TARGET=arm TB --- 2011-11-18 05:47:34 - TARGET_ARCH=arm TB --- 2011-11-18 05:47:34 - TZ=UTC TB --- 2011-11-18 05:47:34 - __MAKE_CONF=/dev/null TB --- 2011-11-18 05:47:34 - cd /src TB --- 2011-11-18 05:47:34 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Fri Nov 18 05:47:34 UTC 2011 >>> 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 >>> Kernel build for BWCT completed on Fri Nov 18 05:49:40 UTC 2011 TB --- 2011-11-18 05:49:40 - cd /src/sys/arm/conf TB --- 2011-11-18 05:49:40 - /usr/sbin/config -m CAMBRIA TB --- 2011-11-18 05:49:41 - building CAMBRIA kernel TB --- 2011-11-18 05:49:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 05:49:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 05:49:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 05:49:41 - SRCCONF=/dev/null TB --- 2011-11-18 05:49:41 - TARGET=arm TB --- 2011-11-18 05:49:41 - TARGET_ARCH=arm TB --- 2011-11-18 05:49:41 - TZ=UTC TB --- 2011-11-18 05:49:41 - __MAKE_CONF=/dev/null TB --- 2011-11-18 05:49:41 - cd /src TB --- 2011-11-18 05:49:41 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Fri Nov 18 05:49:41 UTC 2011 >>> 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 >>> Kernel build for CAMBRIA completed on Fri Nov 18 05:52:37 UTC 2011 TB --- 2011-11-18 05:52:37 - cd /src/sys/arm/conf TB --- 2011-11-18 05:52:37 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-11-18 05:52:37 - building CNS11XXNAS kernel TB --- 2011-11-18 05:52:37 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 05:52:37 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 05:52:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 05:52:37 - SRCCONF=/dev/null TB --- 2011-11-18 05:52:37 - TARGET=arm TB --- 2011-11-18 05:52:37 - TARGET_ARCH=arm TB --- 2011-11-18 05:52:37 - TZ=UTC TB --- 2011-11-18 05:52:37 - __MAKE_CONF=/dev/null TB --- 2011-11-18 05:52:37 - cd /src TB --- 2011-11-18 05:52:38 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Fri Nov 18 05:52:38 UTC 2011 >>> 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 >>> Kernel build for CNS11XXNAS completed on Fri Nov 18 05:55:08 UTC 2011 TB --- 2011-11-18 05:55:08 - cd /src/sys/arm/conf TB --- 2011-11-18 05:55:08 - /usr/sbin/config -m CRB TB --- 2011-11-18 05:55:08 - building CRB kernel TB --- 2011-11-18 05:55:08 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 05:55:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 05:55:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 05:55:08 - SRCCONF=/dev/null TB --- 2011-11-18 05:55:08 - TARGET=arm TB --- 2011-11-18 05:55:08 - TARGET_ARCH=arm TB --- 2011-11-18 05:55:08 - TZ=UTC TB --- 2011-11-18 05:55:08 - __MAKE_CONF=/dev/null TB --- 2011-11-18 05:55:08 - cd /src TB --- 2011-11-18 05:55:08 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Fri Nov 18 05:55:09 UTC 2011 >>> 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 >>> Kernel build for CRB completed on Fri Nov 18 05:58:31 UTC 2011 TB --- 2011-11-18 05:58:31 - cd /src/sys/arm/conf TB --- 2011-11-18 05:58:31 - /usr/sbin/config -m DB-78XXX TB --- 2011-11-18 05:58:32 - building DB-78XXX kernel TB --- 2011-11-18 05:58:32 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 05:58:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 05:58:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 05:58:32 - SRCCONF=/dev/null TB --- 2011-11-18 05:58:32 - TARGET=arm TB --- 2011-11-18 05:58:32 - TARGET_ARCH=arm TB --- 2011-11-18 05:58:32 - TZ=UTC TB --- 2011-11-18 05:58:32 - __MAKE_CONF=/dev/null TB --- 2011-11-18 05:58:32 - cd /src TB --- 2011-11-18 05:58:32 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Fri Nov 18 05:58:32 UTC 2011 >>> 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 >>> Kernel build for DB-78XXX completed on Fri Nov 18 06:01:12 UTC 2011 TB --- 2011-11-18 06:01:12 - cd /src/sys/arm/conf TB --- 2011-11-18 06:01:12 - /usr/sbin/config -m DB-88F5XXX TB --- 2011-11-18 06:01:12 - building DB-88F5XXX kernel TB --- 2011-11-18 06:01:12 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 06:01:12 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 06:01:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 06:01:12 - SRCCONF=/dev/null TB --- 2011-11-18 06:01:12 - TARGET=arm TB --- 2011-11-18 06:01:12 - TARGET_ARCH=arm TB --- 2011-11-18 06:01:12 - TZ=UTC TB --- 2011-11-18 06:01:12 - __MAKE_CONF=/dev/null TB --- 2011-11-18 06:01:12 - cd /src TB --- 2011-11-18 06:01:12 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Fri Nov 18 06:01:12 UTC 2011 >>> 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 >>> Kernel build for DB-88F5XXX completed on Fri Nov 18 06:03:49 UTC 2011 TB --- 2011-11-18 06:03:49 - cd /src/sys/arm/conf TB --- 2011-11-18 06:03:49 - /usr/sbin/config -m DB-88F6XXX TB --- 2011-11-18 06:03:49 - building DB-88F6XXX kernel TB --- 2011-11-18 06:03:49 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 06:03:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 06:03:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 06:03:49 - SRCCONF=/dev/null TB --- 2011-11-18 06:03:49 - TARGET=arm TB --- 2011-11-18 06:03:49 - TARGET_ARCH=arm TB --- 2011-11-18 06:03:49 - TZ=UTC TB --- 2011-11-18 06:03:49 - __MAKE_CONF=/dev/null TB --- 2011-11-18 06:03:49 - cd /src TB --- 2011-11-18 06:03:49 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Fri Nov 18 06:03:49 UTC 2011 >>> 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 >>> Kernel build for DB-88F6XXX completed on Fri Nov 18 06:06:28 UTC 2011 TB --- 2011-11-18 06:06:28 - cd /src/sys/arm/conf TB --- 2011-11-18 06:06:28 - /usr/sbin/config -m DOCKSTAR TB --- 2011-11-18 06:06:28 - building DOCKSTAR kernel TB --- 2011-11-18 06:06:28 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 06:06:28 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 06:06:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 06:06:28 - SRCCONF=/dev/null TB --- 2011-11-18 06:06:28 - TARGET=arm TB --- 2011-11-18 06:06:28 - TARGET_ARCH=arm TB --- 2011-11-18 06:06:28 - TZ=UTC TB --- 2011-11-18 06:06:28 - __MAKE_CONF=/dev/null TB --- 2011-11-18 06:06:28 - cd /src TB --- 2011-11-18 06:06:28 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Fri Nov 18 06:06:28 UTC 2011 >>> 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 >>> Kernel build for DOCKSTAR completed on Fri Nov 18 06:09:02 UTC 2011 TB --- 2011-11-18 06:09:02 - cd /src/sys/arm/conf TB --- 2011-11-18 06:09:02 - /usr/sbin/config -m EP80219 TB --- 2011-11-18 06:09:02 - building EP80219 kernel TB --- 2011-11-18 06:09:02 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 06:09:02 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 06:09:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 06:09:02 - SRCCONF=/dev/null TB --- 2011-11-18 06:09:02 - TARGET=arm TB --- 2011-11-18 06:09:02 - TARGET_ARCH=arm TB --- 2011-11-18 06:09:02 - TZ=UTC TB --- 2011-11-18 06:09:02 - __MAKE_CONF=/dev/null TB --- 2011-11-18 06:09:02 - cd /src TB --- 2011-11-18 06:09:02 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Fri Nov 18 06:09:02 UTC 2011 >>> 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 >>> Kernel build for EP80219 completed on Fri Nov 18 06:11:54 UTC 2011 TB --- 2011-11-18 06:11:54 - WARNING: no kernel config for GENERIC TB --- 2011-11-18 06:11:54 - cd /src/sys/arm/conf TB --- 2011-11-18 06:11:54 - /usr/sbin/config -m GUMSTIX TB --- 2011-11-18 06:11:54 - building GUMSTIX kernel TB --- 2011-11-18 06:11:54 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 06:11:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 06:11:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 06:11:54 - SRCCONF=/dev/null TB --- 2011-11-18 06:11:54 - TARGET=arm TB --- 2011-11-18 06:11:54 - TARGET_ARCH=arm TB --- 2011-11-18 06:11:54 - TZ=UTC TB --- 2011-11-18 06:11:54 - __MAKE_CONF=/dev/null TB --- 2011-11-18 06:11:54 - cd /src TB --- 2011-11-18 06:11:54 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Fri Nov 18 06:11:54 UTC 2011 >>> 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 >>> Kernel build for GUMSTIX completed on Fri Nov 18 06:14:12 UTC 2011 TB --- 2011-11-18 06:14:12 - cd /src/sys/arm/conf TB --- 2011-11-18 06:14:12 - /usr/sbin/config -m HL200 TB --- 2011-11-18 06:14:12 - building HL200 kernel TB --- 2011-11-18 06:14:12 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 06:14:12 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 06:14:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 06:14:12 - SRCCONF=/dev/null TB --- 2011-11-18 06:14:12 - TARGET=arm TB --- 2011-11-18 06:14:12 - TARGET_ARCH=arm TB --- 2011-11-18 06:14:12 - TZ=UTC TB --- 2011-11-18 06:14:12 - __MAKE_CONF=/dev/null TB --- 2011-11-18 06:14:12 - cd /src TB --- 2011-11-18 06:14:12 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Fri Nov 18 06:14:12 UTC 2011 >>> 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 >>> Kernel build for HL200 completed on Fri Nov 18 06:16:49 UTC 2011 TB --- 2011-11-18 06:16:49 - cd /src/sys/arm/conf TB --- 2011-11-18 06:16:49 - /usr/sbin/config -m HL201 TB --- 2011-11-18 06:16:49 - building HL201 kernel TB --- 2011-11-18 06:16:49 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 06:16:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 06:16:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 06:16:49 - SRCCONF=/dev/null TB --- 2011-11-18 06:16:49 - TARGET=arm TB --- 2011-11-18 06:16:49 - TARGET_ARCH=arm TB --- 2011-11-18 06:16:49 - TZ=UTC TB --- 2011-11-18 06:16:49 - __MAKE_CONF=/dev/null TB --- 2011-11-18 06:16:49 - cd /src TB --- 2011-11-18 06:16:49 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Fri Nov 18 06:16:49 UTC 2011 >>> 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 >>> Kernel build for HL201 completed on Fri Nov 18 06:19:05 UTC 2011 TB --- 2011-11-18 06:19:05 - cd /src/sys/arm/conf TB --- 2011-11-18 06:19:05 - /usr/sbin/config -m IQ31244 TB --- 2011-11-18 06:19:06 - building IQ31244 kernel TB --- 2011-11-18 06:19:06 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 06:19:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 06:19:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 06:19:06 - SRCCONF=/dev/null TB --- 2011-11-18 06:19:06 - TARGET=arm TB --- 2011-11-18 06:19:06 - TARGET_ARCH=arm TB --- 2011-11-18 06:19:06 - TZ=UTC TB --- 2011-11-18 06:19:06 - __MAKE_CONF=/dev/null TB --- 2011-11-18 06:19:06 - cd /src TB --- 2011-11-18 06:19:06 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Fri Nov 18 06:19:06 UTC 2011 >>> 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 >>> Kernel build for IQ31244 completed on Fri Nov 18 06:22:22 UTC 2011 TB --- 2011-11-18 06:22:22 - cd /src/sys/arm/conf TB --- 2011-11-18 06:22:22 - /usr/sbin/config -m KB920X TB --- 2011-11-18 06:22:22 - building KB920X kernel TB --- 2011-11-18 06:22:22 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 06:22:22 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 06:22:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 06:22:22 - SRCCONF=/dev/null TB --- 2011-11-18 06:22:22 - TARGET=arm TB --- 2011-11-18 06:22:22 - TARGET_ARCH=arm TB --- 2011-11-18 06:22:22 - TZ=UTC TB --- 2011-11-18 06:22:22 - __MAKE_CONF=/dev/null TB --- 2011-11-18 06:22:22 - cd /src TB --- 2011-11-18 06:22:22 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Fri Nov 18 06:22:22 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_mcdi.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_port.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_rx.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_tx.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_tx.c: In function 'sfxge_tx_qdpl_swizzle': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_tx.c:138: warning: implicit declaration of function 'atomic_readandclear_ptr' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_tx.c:138: warning: nested extern declaration of 'atomic_readandclear_ptr' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-18 06:31:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-18 06:31:16 - ERROR: failed to build KB920X kernel TB --- 2011-11-18 06:31:16 - 4518.70 user 1133.77 system 6076.15 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 06:43:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14C11106564A; Fri, 18 Nov 2011 06:43:06 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id B42A68FC0A; Fri, 18 Nov 2011 06:43:05 +0000 (UTC) Received: by yenl11 with SMTP id l11so3098420yen.13 for ; Thu, 17 Nov 2011 22:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SLQAcJpL6DrT4zZZeAgjEWVnVrlooF1EK59+SQFDeJE=; b=TQeWS8H8suTswY/cKZ5+hC7qWiytXKn3zFFNFfm29r8aaZ73uVOAgH9WJI8be2YbFj zfp9UjVb1gJGB07MmPYuHMKchb8gI9/up2mjtdcRFXnmuYxzykR3Gdto2L6F6U2z2TPY oJ7JEnMuP7ZyHH3ngYVrsil21p6KsDcSIFlMc= MIME-Version: 1.0 Received: by 10.182.225.3 with SMTP id rg3mr400917obc.77.1321598584631; Thu, 17 Nov 2011 22:43:04 -0800 (PST) Received: by 10.182.7.34 with HTTP; Thu, 17 Nov 2011 22:43:04 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Nov 2011 22:43:04 -0800 Message-ID: From: Garrett Cooper To: Benjamin Kaduk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= , freebsd-current@freebsd.org, nwhitehorn@freebsd.org Subject: Re: Can't install FreeBSD-amd64-9.0-RC2: "/mnt: out of inodes" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 06:43:06 -0000 2011/11/17 Benjamin Kaduk : > On Thu, 17 Nov 2011, Olivier Cochard-Labb=E9 wrote: > >> Hi all, >> >> I tried to install FreeBSD-9.0-RC2-amd64-dvd1.iso (SHA256 verified) on >> a VM and meet a reproducible problem: >> The VM has 128Mo RAM and a 4Go hard drive. >> >> During install process I choose these distribution sets: ports and src >> only. >> And I'm using guided partitioning / Entire Disk / All Auto >> >> But each time (I delete and re-create a new VM multiple times) the >> installer failed during archive extraction of ports.txz (at about 88% >> progress of this file extraction) with this message: >> >> Error while extracting ports.txz: >> Can't create >> 'usr/ports/databases/p5-DBIx-Sunny/pkg-plist' >> >> And on the background there is this message: >> ...on /mnt: out of inodes >> >> Can someone else confirm this problem before I fill a PR ? > > A 4G disk is perhaps quite rare these days, but I expect that the issue i= s > real. =A0Please file the PR. > > The default block and fragment size for UFS/FFS were bumped by mckusick i= n > r222319 (to general assent); presumably the installer should gain some lo= gic > to use smaller values for smaller disks, so that the available number of > inodes is larger. =A0(I presume that you have successfully installed earl= ier > releases on 4G disk, of course. =A0Though ... I think I may have, myself.= ) > =A0The ports tree has a very large number of small files, and is thus a v= ery > intensive user of inodes. > > > Alas, my five minutes of searching were not enough to find where bsdinsta= ll > is actually generating default filesystem options, so I couldn't confirm > this assumption. Look for newfs_command in gpart_ops.c . -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 06:47:21 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AEAF106568C; Fri, 18 Nov 2011 06:47:21 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E00C28FC0A; Fri, 18 Nov 2011 06:47:20 +0000 (UTC) Received: by iakl21 with SMTP id l21so4680114iak.13 for ; Thu, 17 Nov 2011 22:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Wya4bzIxnif0+Z1je+0QPhKvYLh5o6dnK4POQj8O5Os=; b=Mav0/furJu7zn7RK/Z6xhnPy+VB8pJRcGbqbrb1WqygfvhecEIyg56WAbGNtSt2ZoH lUi8m8mGLPo34IIPkWpUYQ/fkDbZi9hNMsoK4k4LZAB+4ZBCnGKn81Fzo989z31GBhjy HjrdjgkhxRFqhgiJGHx7hh3NePxLk8y6LA1YQ= MIME-Version: 1.0 Received: by 10.42.135.66 with SMTP id o2mr1295447ict.0.1321598839444; Thu, 17 Nov 2011 22:47:19 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.243.198 with HTTP; Thu, 17 Nov 2011 22:47:19 -0800 (PST) In-Reply-To: <201111171632.34979.jhb@freebsd.org> References: <201111170959.56767.jhb@freebsd.org> <201111171632.34979.jhb@freebsd.org> Date: Fri, 18 Nov 2011 07:47:19 +0100 X-Google-Sender-Auth: 7GOt4SHay_RPr6AKNyeK6txG96U Message-ID: From: Robert Millan To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, Warner Losh , freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 06:47:21 -0000 2011/11/17 John Baldwin : > Hmm, I wonder if it's better to use the #ifndef approach rather than #undef > so that when compilers are updated to DTRT we will honor their settings? Well, the compiler is supposed to know better than sys/param.h, because it inherited this number from the runtime kernel when it was built. However, __FreeBSD__ comes from the compiler already so if you "#define __FreeBSD_kernel__ __FreeBSD__" you get the information from the compiler anyway. As both approaches do the same thing, I really don't mind either way. From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 08:02:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 61DC51065677; Fri, 18 Nov 2011 08:02:40 +0000 (UTC) Date: Fri, 18 Nov 2011 08:02:40 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20111118080240.GA78563@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: freebsd-usb@freebsd.org Subject: issue with usb hdd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 08:02:40 -0000 hi there, i recently bought a western digital 1 terrabyte usb2/usb3 hdd: [83611.209514] umass0: on usbus3 [83613.618514] da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 [83613.618514] da0: Fixed Direct Access SCSI-6 device [83613.618514] da0: 40.000MB/s transfers [83613.618514] da0: 953837MB (1953458176 512 byte sectors: 255H 63S/T 121597C) i partitioned it via the gpt scheme and one big ufs2 partition with SU+J enabled: Geom name: da0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 1953458142 first: 34 entries: 128 scheme: GPT Providers: 1. Name: da0p1 Mediasize: 1000170551808 (931G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 17408 Mode: r0w0e0 rawuuid: 39d3bf09-fb47-11e0-ade1-000fb58207c8 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 1000170551808 offset: 17408 type: freebsd-ufs index: 1 end: 1953458142 start: 34 Consumers: 1. Name: da0 Mediasize: 1000170586112 (931G) Sectorsize: 512 Mode: r0w0e0 => 34 1953458109 da0 GPT (931G) 34 1953458109 1 freebsd-ufs (931G) tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) wd mounting and everything works great. however if i don't access the monted hdd for a couple of hours, and then do `ls /mnt/wd`, nothing is there. `mount -p` reports that the hdd is still mounted: /dev/ufs/rootfs / ufs ro 1 1 devfs /dev devfs rw 0 0 /dev/ufs/varfs /var ufs rw 1 2 /dev/ufs/usrfs /usr ufs rw 1 2 linprocfs /usr/compat/linux/proc linprocfs rw 0 0 linsysfs /usr/compat/linux/sys linsysfs rw 0 0 devfs /usr/compat/linux/dev devfs rw 0 0 linprocfs /usr/local/gentoo-stage3/proc linprocfs rw 0 0 linsysfs /usr/local/gentoo-stage3/sys linsysfs rw 0 0 devfs /usr/local/gentoo-stage3/dev devfs rw 0 0 tmpfs /tmp tmpfs rw 0 0 tmpfs /var/tmp tmpfs rw 0 0 /dev/ufs/wd /mnt/wd ufs rw,noexec,nosuid 0 0 `pwd` executed will return ENXIO. i can then do `umount /mnt/wd`, but re-mounting the hdd fails with the following dmesg warnings: [96836.840512] (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 0 0 0 0 0 [96836.840512] (probe0:umass-sim0:0:0:1): CAM status: SCSI Status Error [96836.840512] (probe0:umass-sim0:0:0:1): SCSI status: Check Condition [96836.840512] (probe0:umass-sim0:0:0:1): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) [97109.824517] WARNING: R/W mount of /mnt/wd denied. Filesystem is not clean - run fsck [97109.824517] WARNING: Forced mount will invalidate journal contents [97126.200518] WARNING: R/W mount of /mnt/wd denied. Filesystem is not clean - run fsck [97126.200518] WARNING: Forced mount will invalidate journal contents [97129.283518] WARNING: R/W mount of /mnt/wd denied. Filesystem is not clean - run fsck [97129.283518] WARNING: Forced mount will invalidate journal contents [97133.904518] WARNING: R/W mount of /mnt/wd denied. Filesystem is not clean - run fsck [97133.904518] WARNING: Forced mount will invalidate journal contents (i believe the "probe0" stuff is from the umount) `mount` fails with EPERM btw. what i have to do is: `fsck /dev/ufs/wd`. this complains about the following: ** /dev/ufs/wd USE JOURNAL? [yn] y ** SU+J Recovering /dev/ufs/wd ** Reading 33554432 byte journal from inode 4. RECOVER? [yn] y ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ***** FILE SYSTEM MARKED CLEAN ***** ...now everything is back to normal and i can mount the hdd again. any suggestions? i'm running a very recent HEAD on amd64. cheers. alex From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 08:46:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 445781065675 for ; Fri, 18 Nov 2011 08:46:24 +0000 (UTC) (envelope-from landimatte@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id E7C3B8FC18 for ; Fri, 18 Nov 2011 08:46:23 +0000 (UTC) Received: by ghbg20 with SMTP id g20so176296ghb.13 for ; Fri, 18 Nov 2011 00:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=V2RhuIJkm8JY1KLsKDaAr1L+w/KOcavFxwRaNmaqeAM=; b=riHdnlv+DwCKRlUikU4NPmvzlr93+EZmGWGL5rnRXOEAWQQK0MDs+W0DCb9LMg1mQQ PH31mj8Bo4FTZWQjvkWiBzXaEEL9mE7pzwE/7+vYDF+j/p5e3GLO1XzzYzPTcWvUrUEN sNlFkY79gsNRIUNTavD/aFX8F216IzL0bvEs0= Received: by 10.50.89.227 with SMTP id br3mr2290681igb.14.1321605983060; Fri, 18 Nov 2011 00:46:23 -0800 (PST) MIME-Version: 1.0 Sender: landimatte@gmail.com Received: by 10.50.47.197 with HTTP; Fri, 18 Nov 2011 00:46:02 -0800 (PST) In-Reply-To: <201111170953.58151.jhb@freebsd.org> References: <201111170953.58151.jhb@freebsd.org> From: Matteo Landi Date: Fri, 18 Nov 2011 09:46:02 +0100 X-Google-Sender-Auth: BNMhQVguqlf99QxZbUONNdYLZGE Message-ID: To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: ixgbe and fast interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 08:46:24 -0000 > you probably want to be using MSI-X for a 10G NIC instead of INTx anyway. Why do you say that? Is MSI-X faster than INTx in terms of interrupt latency? When should I use MSI-X, instead of fast filters interrupts (fast interrupt?), instead of ithread interrupts? Thanks in advace. Regards, Matteo -- http://www.matteolandi.net/ From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 08:50:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57C80106566C for ; Fri, 18 Nov 2011 08:50:12 +0000 (UTC) (envelope-from landimatte@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 22FF78FC0A for ; Fri, 18 Nov 2011 08:50:12 +0000 (UTC) Received: by iakl21 with SMTP id l21so4849858iak.13 for ; Fri, 18 Nov 2011 00:50:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=vXj+RPbh3hkOpgbR5KAzbkG75CRadui25v6El3KluVg=; b=gUa25NvdVL72OKZxCrf9en/D7TYCO618KQsii8d3SXf79DSHv9nqrl1s+SSpLKhAbB KHRQ6GCdLiDPMQU64sMknr8OWw2j2Rd4dTJu8R3V32UBcm/ewi7E6K5dO0mJkH2cHasu 1P7+dUTs2kHG4NEdYq/kfkpZ4S9Ao+2elJdYs= Received: by 10.42.154.7 with SMTP id o7mr2018598icw.48.1321606211041; Fri, 18 Nov 2011 00:50:11 -0800 (PST) MIME-Version: 1.0 Sender: landimatte@gmail.com Received: by 10.50.47.197 with HTTP; Fri, 18 Nov 2011 00:49:50 -0800 (PST) In-Reply-To: References: From: Matteo Landi Date: Fri, 18 Nov 2011 09:49:50 +0100 X-Google-Sender-Auth: G41SMADSJbNCpQ3jpMwmREghh9Y Message-ID: To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: ixgbe and fast interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 08:50:12 -0000 On Thu, Nov 17, 2011 at 3:56 PM, Ryan Stone wrote: > The comments haven't kept up with the code. =A0You are correct; in the > legacy interrupt case ixgbe is using an ITHREAD, not a fast handler. Do I have to send an email to the maintainer of the ixgbe driver and ask him to update the comments, or could I send you a patch for that? Regards, Matteo --=20 http://www.matteolandi.net/ From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 10:20:10 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FBF7106566C; Fri, 18 Nov 2011 10:20:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5159A8FC12; Fri, 18 Nov 2011 10:20:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAIAK9fe076710; Fri, 18 Nov 2011 05:20:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAIAK9KI076709; Fri, 18 Nov 2011 10:20:09 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 18 Nov 2011 10:20:09 GMT Message-Id: <201111181020.pAIAK9KI076709@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 10:20:10 -0000 TB --- 2011-11-18 08:12:18 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-18 08:12:18 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-18 08:12:18 - cleaning the object tree TB --- 2011-11-18 08:12:31 - cvsupping the source tree TB --- 2011-11-18 08:12:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-18 08:14:21 - building world TB --- 2011-11-18 08:14:21 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 08:14:21 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 08:14:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 08:14:21 - SRCCONF=/dev/null TB --- 2011-11-18 08:14:21 - TARGET=powerpc TB --- 2011-11-18 08:14:21 - TARGET_ARCH=powerpc TB --- 2011-11-18 08:14:21 - TZ=UTC TB --- 2011-11-18 08:14:21 - __MAKE_CONF=/dev/null TB --- 2011-11-18 08:14:21 - cd /src TB --- 2011-11-18 08:14:21 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 18 08:14:22 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 18 10:08:15 UTC 2011 TB --- 2011-11-18 10:08:15 - generating LINT kernel config TB --- 2011-11-18 10:08:15 - cd /src/sys/powerpc/conf TB --- 2011-11-18 10:08:15 - /usr/bin/make -B LINT TB --- 2011-11-18 10:08:15 - cd /src/sys/powerpc/conf TB --- 2011-11-18 10:08:15 - /usr/sbin/config -m GENERIC TB --- 2011-11-18 10:08:15 - building GENERIC kernel TB --- 2011-11-18 10:08:15 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 10:08:15 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 10:08:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 10:08:15 - SRCCONF=/dev/null TB --- 2011-11-18 10:08:15 - TARGET=powerpc TB --- 2011-11-18 10:08:15 - TARGET_ARCH=powerpc TB --- 2011-11-18 10:08:15 - TZ=UTC TB --- 2011-11-18 10:08:15 - __MAKE_CONF=/dev/null TB --- 2011-11-18 10:08:15 - cd /src TB --- 2011-11-18 10:08:15 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Nov 18 10:08:15 UTC 2011 >>> 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 [...] ===> sfxge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_ev.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc.powerpc/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -mlongcall -fno-omit-frame-pointer -I/obj/powerpc.powerpc/src/sys/GENERIC -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_intr.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_intr.c: In function 'sfxge_intr_message': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_intr.c:150: warning: passing argument 1 of 'atomic_cmpset_int' from incompatible pointer type *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-18 10:20:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-18 10:20:09 - ERROR: failed to build GENERIC kernel TB --- 2011-11-18 10:20:09 - 6136.88 user 1062.02 system 7671.08 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 10:40:30 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5CC61065674; Fri, 18 Nov 2011 10:40:30 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id B2DFD8FC12; Fri, 18 Nov 2011 10:40:29 +0000 (UTC) Received: by wwg14 with SMTP id 14so4722813wwg.31 for ; Fri, 18 Nov 2011 02:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PfInaVEPJ86O8EasK7bCihcdMa21xqCYWdz1QY3vQCU=; b=LQv0G0YgI3/8CQuY6FYcgCCd9mUDs3ystdgrlrCbPS4RdBvyvsDUWYO8pYF1NzlItr tXF2gyEaNUvJEuTw93Q4ua0iASHRTayfVQfPoOAFz1sKk4vG5AgNIeAdQlsSPHTvtHxa Xci/d/5gfevQ/BiBIQXIjbXI8lsI1c1iDf/HY= MIME-Version: 1.0 Received: by 10.216.166.212 with SMTP id g62mr420481wel.29.1321612828577; Fri, 18 Nov 2011 02:40:28 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.85.8 with HTTP; Fri, 18 Nov 2011 02:40:28 -0800 (PST) In-Reply-To: <20111116084542.GY50300@deviant.kiev.zoral.com.ua> References: <4EB4095D.3030303@rice.edu> <20111104160339.GM50300@deviant.kiev.zoral.com.ua> <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> <20111107193516.GA50300@deviant.kiev.zoral.com.ua> <20111116084542.GY50300@deviant.kiev.zoral.com.ua> Date: Fri, 18 Nov 2011 11:40:28 +0100 X-Google-Sender-Auth: mH73E1qmpvLLZ85PhP0IZn3liQs Message-ID: From: Attilio Rao To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 10:40:30 -0000 2011/11/16 Kostik Belousov : > On Tue, Nov 15, 2011 at 07:15:01PM +0100, Attilio Rao wrote: >> 2011/11/7 Kostik Belousov : >> > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: >> >> Ok. =C2=A0I'll offer one final suggestion. =C2=A0Please consider an a= lternative >> >> suffix to "func". =C2=A0Perhaps, "kbi" or "KBI". =C2=A0In other words= , something >> >> that hints at the function's reason for existing. >> > >> > Sure. Below is the extraction of only vm_page_lock() bits, together >> > with the suggested rename. When Attilio provides the promised simplifi= cation >> > of the mutex KPI, this can be reduced. >> >> My tentative patch is here: >> http://www.freebsd.org/~attilio/mutexfileline.patch >> >> I need to make more compile testing later, but it already compiles >> GENERIC + modules fine on HEAD. >> >> The patch provides a common entrypoint, option independent, for both >> fast case and debug/compat case. >> Additively, it almost entirely fixes the standard violation of the >> reserved namespace, as you described (the notable exception being the >> macro used in the fast path, that I want to fix as well, but in a >> separate commit). >> >> Now the file/line couplet can be passed to the "_" suffix variant of >> the flag functions. > Yes, this is exactly KPI that I would use when available for the > vm_page_lock() patch. > >> >> eadler@ reviewed the mutex.h comment. >> >> Please let me know what you think about it, as long as we agree on the >> patch I'll commit it. > But I also agree with John that imposing large churn due to the eliminati= on > of the '__' prefix is too late now. At least it will make the change > non-MFCable. Besides, we already lived with the names for 10+ years. > > I will be happy to have the part of the patch that exports the mtx_XXX_(m= tx, > file, line) defines which can be used without taking care of LOCK_DEBUG > or MUTEX_NOINLINE in the consumer code. Ok, this patch should just add the compat stub: http://www.freebsd.org/~attilio/mutexfileline2.patch I'll make more test-compiling later in the day, if you agree on it I will commit the patch tomorrow. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 10:41:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41933106564A for ; Fri, 18 Nov 2011 10:41:00 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id DCCE88FC19 for ; Fri, 18 Nov 2011 10:40:59 +0000 (UTC) Received: by ggnk5 with SMTP id k5so2862081ggn.13 for ; Fri, 18 Nov 2011 02:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=h6b42S3v4zUFkNU5IlrZqCKlNEgGmy6bezGbSxKQSlQ=; b=TBubJQruOJCowKU92KEcUy1FnW8Uc7dphHPj5oXeDeHXbqbfiY6quxQ98drLDEgEpe O+y4puJCM7Isw4eDHAf8FD7FJf5/aEdFH07T7MAyrx05fJNnJhMCjXF6tsQRK6H55EIR BqD6t8DbV9R8RZn4+uyB9TVaBQ8oNGWavfZ4I= Received: by 10.229.13.11 with SMTP id z11mr236779qcz.115.1321612859124; Fri, 18 Nov 2011 02:40:59 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.229.53.78 with HTTP; Fri, 18 Nov 2011 02:40:38 -0800 (PST) In-Reply-To: References: From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Fri, 18 Nov 2011 11:40:38 +0100 X-Google-Sender-Auth: I2ZVh1xDNvhIrJlPeklj3XXvnjc Message-ID: To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Benjamin Kaduk , nwhitehorn@freebsd.org Subject: Re: Can't install FreeBSD-amd64-9.0-RC2: "/mnt: out of inodes" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 10:41:00 -0000 On Fri, Nov 18, 2011 at 7:43 AM, Garrett Cooper wrote: >> >> A 4G disk is perhaps quite rare these days, but I expect that the issue = is >> real. =A0Please file the PR. >> Using flash media or setting small hard drive in a virtual machine is not very rare :-) And once installed (I need to use a minimal 6G hard drive for solving this problem) the system (ports and src distributions sets) consume only 2.7G of disk space. The PR was filled : bin/162659 Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 10:52:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3B46106564A; Fri, 18 Nov 2011 10:52:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8D4618FC15; Fri, 18 Nov 2011 10:52:34 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAIAqO2l013249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Nov 2011 12:52:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAIAqO5H017781; Fri, 18 Nov 2011 12:52:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAIAqOdh017780; Fri, 18 Nov 2011 12:52:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 Nov 2011 12:52:24 +0200 From: Kostik Belousov To: Attilio Rao Message-ID: <20111118105224.GB50300@deviant.kiev.zoral.com.ua> References: <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> <20111107193516.GA50300@deviant.kiev.zoral.com.ua> <20111116084542.GY50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="owW3RB2klY9QKIRa" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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: mdf@freebsd.org, "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 10:52:35 -0000 --owW3RB2klY9QKIRa Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 18, 2011 at 11:40:28AM +0100, Attilio Rao wrote: > 2011/11/16 Kostik Belousov : > > On Tue, Nov 15, 2011 at 07:15:01PM +0100, Attilio Rao wrote: > >> 2011/11/7 Kostik Belousov : > >> > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: > >> >> Ok. =9AI'll offer one final suggestion. =9APlease consider an alter= native > >> >> suffix to "func". =9APerhaps, "kbi" or "KBI". =9AIn other words, so= mething > >> >> that hints at the function's reason for existing. > >> > > >> > Sure. Below is the extraction of only vm_page_lock() bits, together > >> > with the suggested rename. When Attilio provides the promised simpli= fication > >> > of the mutex KPI, this can be reduced. > >> > >> My tentative patch is here: > >> http://www.freebsd.org/~attilio/mutexfileline.patch > >> > >> I need to make more compile testing later, but it already compiles > >> GENERIC + modules fine on HEAD. > >> > >> The patch provides a common entrypoint, option independent, for both > >> fast case and debug/compat case. > >> Additively, it almost entirely fixes the standard violation of the > >> reserved namespace, as you described (the notable exception being the > >> macro used in the fast path, that I want to fix as well, but in a > >> separate commit). > >> > >> Now the file/line couplet can be passed to the "_" suffix variant of > >> the flag functions. > > Yes, this is exactly KPI that I would use when available for the > > vm_page_lock() patch. > > > >> > >> eadler@ reviewed the mutex.h comment. > >> > >> Please let me know what you think about it, as long as we agree on the > >> patch I'll commit it. > > But I also agree with John that imposing large churn due to the elimina= tion > > of the '__' prefix is too late now. At least it will make the change > > non-MFCable. Besides, we already lived with the names for 10+ years. > > > > I will be happy to have the part of the patch that exports the mtx_XXX_= (mtx, > > file, line) defines which can be used without taking care of LOCK_DEBUG > > or MUTEX_NOINLINE in the consumer code. >=20 > Ok, this patch should just add the compat stub: > http://www.freebsd.org/~attilio/mutexfileline2.patch Am I right that I would use mtx_lock_(mtx, file, line) etc ? If yes, I am fine with it. >=20 > I'll make more test-compiling later in the day, if you agree on it I > will commit the patch tomorrow. >=20 > Attilio >=20 >=20 > --=20 > Peace can only be achieved by understanding - A. Einstein --owW3RB2klY9QKIRa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7GOOcACgkQC3+MBN1Mb4iNLwCfYhIi5vBc0OB9CG46r0gKlD7b 3CQAn2INTEPYoeAU6xRUUegAHA2XHOPv =8UJS -----END PGP SIGNATURE----- --owW3RB2klY9QKIRa-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 10:53:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CE9D1065688 for ; Fri, 18 Nov 2011 10:53:39 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost05.isp.att.net (fmailhost05.isp.att.net [207.115.11.55]) by mx1.freebsd.org (Postfix) with ESMTP id C175A8FC1D for ; Fri, 18 Nov 2011 10:53:38 +0000 (UTC) Date: Fri, 18 Nov 2011 10:53:38 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-18-111-140.sdf.bellsouth.net[68.18.111.140]) by isp.att.net (frfwmhc05) with SMTP id <20111118105337H0500du9p6e>; Fri, 18 Nov 2011 10:53:37 +0000 X-Originating-IP: [68.18.111.140] From: "Thomas Mueller" To: freebsd-current@freebsd.org References: <1321553970.82271.66.camel@bauer.cse.buffalo.edu> Message-Id: <20111118105339.1CE9D1065688@hub.freebsd.org> Cc: Ken Smith Subject: Re: FreeBSD 9.0-RC2 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 10:53:39 -0000 > If you would like to use csup/cvsup mechanisms to access the source > tree the branch tag to use is now "RELENG_9_0", if you use "." (head) > you will get 10-CURRENT. If you would like to access the source tree > via SVN it is "svn://svn.freebsd.org/base/releng/9.0/". We still have > the nit that the creation of a new SVN branch winds up causing what > looks like a check-in of the entire tree in CVS (a side-effect of the > svn2cvs exporter) so "mergemaster -F" is your friend if you are using > csup/cvsup. About a couple days before seeing this message, or the message on the FreeBSD web site, but after seeing RC2 on the ftp.freebsd.org server, I already ran csup with *default release=cvs tag=RELENG_9 Am I screwed, am I OK, or do I simply have to rerun csup with RELENG_9_0 instead of RELENG_9 ? Again, I can't find that file (needle in the haystack) in /usr/src tree that shows version number such as RC2. Tom From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 10:56:58 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 364091065674; Fri, 18 Nov 2011 10:56:58 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 339718FC1C; Fri, 18 Nov 2011 10:56:56 +0000 (UTC) Received: by eyd10 with SMTP id 10so4496182eyd.13 for ; Fri, 18 Nov 2011 02:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=frprEAxjFjGx5jjPSbaPRwI3CyQc8S1vgFT4LLDj+4c=; b=Ki/78r9+vbFdE0SN2s2weT2rDgKA/++wgXqL64R0sncPdoaajepiXaxjlXvIlppLyy zG+iuECX3ZD2K9W4M5JHyXZMJdRCOykQyCbgdyrLIUs/pkfP4X0u+NtzVSEAhXaauICL IOvAlJ3H8rdcDou3cb55slZVD6p/TF52vKe3Y= MIME-Version: 1.0 Received: by 10.180.109.106 with SMTP id hr10mr3417837wib.9.1321613815978; Fri, 18 Nov 2011 02:56:55 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.85.8 with HTTP; Fri, 18 Nov 2011 02:56:55 -0800 (PST) In-Reply-To: <20111118105224.GB50300@deviant.kiev.zoral.com.ua> References: <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> <20111107193516.GA50300@deviant.kiev.zoral.com.ua> <20111116084542.GY50300@deviant.kiev.zoral.com.ua> <20111118105224.GB50300@deviant.kiev.zoral.com.ua> Date: Fri, 18 Nov 2011 11:56:55 +0100 X-Google-Sender-Auth: 6Sx9jCA4uQrvAXh8ISs0WRiIOM8 Message-ID: From: Attilio Rao To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 10:56:58 -0000 2011/11/18 Kostik Belousov : > On Fri, Nov 18, 2011 at 11:40:28AM +0100, Attilio Rao wrote: >> 2011/11/16 Kostik Belousov : >> > On Tue, Nov 15, 2011 at 07:15:01PM +0100, Attilio Rao wrote: >> >> 2011/11/7 Kostik Belousov : >> >> > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: >> >> >> Ok. =C2=A0I'll offer one final suggestion. =C2=A0Please consider a= n alternative >> >> >> suffix to "func". =C2=A0Perhaps, "kbi" or "KBI". =C2=A0In other wo= rds, something >> >> >> that hints at the function's reason for existing. >> >> > >> >> > Sure. Below is the extraction of only vm_page_lock() bits, together >> >> > with the suggested rename. When Attilio provides the promised simpl= ification >> >> > of the mutex KPI, this can be reduced. >> >> >> >> My tentative patch is here: >> >> http://www.freebsd.org/~attilio/mutexfileline.patch >> >> >> >> I need to make more compile testing later, but it already compiles >> >> GENERIC + modules fine on HEAD. >> >> >> >> The patch provides a common entrypoint, option independent, for both >> >> fast case and debug/compat case. >> >> Additively, it almost entirely fixes the standard violation of the >> >> reserved namespace, as you described (the notable exception being the >> >> macro used in the fast path, that I want to fix as well, but in a >> >> separate commit). >> >> >> >> Now the file/line couplet can be passed to the "_" suffix variant of >> >> the flag functions. >> > Yes, this is exactly KPI that I would use when available for the >> > vm_page_lock() patch. >> > >> >> >> >> eadler@ reviewed the mutex.h comment. >> >> >> >> Please let me know what you think about it, as long as we agree on th= e >> >> patch I'll commit it. >> > But I also agree with John that imposing large churn due to the elimin= ation >> > of the '__' prefix is too late now. At least it will make the change >> > non-MFCable. Besides, we already lived with the names for 10+ years. >> > >> > I will be happy to have the part of the patch that exports the mtx_XXX= _(mtx, >> > file, line) defines which can be used without taking care of LOCK_DEBU= G >> > or MUTEX_NOINLINE in the consumer code. >> >> Ok, this patch should just add the compat stub: >> http://www.freebsd.org/~attilio/mutexfileline2.patch > Am I right that I would use mtx_lock_(mtx, file, line) etc ? > If yes, I am fine with it. Yes that is correct. However, I'm a bit confused on one aspect: would you mind using _mtx_lock_flags() instead? If you don't mind the "underscore namespace violation" I think I can make a much smaller patch against HEAD for it. Otherwise, the one now posted should be ok. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 10:59:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3323C106564A for ; Fri, 18 Nov 2011 10:59:35 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id B5F388FC0A for ; Fri, 18 Nov 2011 10:59:34 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mail.0x20.net (Postfix) with ESMTP id 3E1C46A61CD; Fri, 18 Nov 2011 11:59:33 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.0x20.net Received: from mail.0x20.net ([217.69.76.211]) by mail.0x20.net (mail.0x20.net [217.69.76.211]) (amavisd-new, port 10024) with ESMTP id ZAqI8rTxNZUY; Fri, 18 Nov 2011 11:59:33 +0100 (CET) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id E6DC26A61CB; Fri, 18 Nov 2011 11:59:32 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.4/8.14.4) with ESMTP id pAIAxWri060617; Fri, 18 Nov 2011 11:59:32 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.4/8.14.4/Submit) id pAIAxWrJ060426; Fri, 18 Nov 2011 11:59:32 +0100 (CET) (envelope-from lars) Date: Fri, 18 Nov 2011 11:59:32 +0100 From: Lars Engels To: Thomas Mueller Message-ID: <20111118105931.GH82426@e-new.0x20.net> References: <1321553970.82271.66.camel@bauer.cse.buffalo.edu> <20111118105339.1CE9D1065688@hub.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dMyqICaxQaaUjrCL" Content-Disposition: inline In-Reply-To: <20111118105339.1CE9D1065688@hub.freebsd.org> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.2-RELEASE-p3 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Ken Smith Subject: Re: FreeBSD 9.0-RC2 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 10:59:35 -0000 --dMyqICaxQaaUjrCL Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 18, 2011 at 10:53:38AM +0000, Thomas Mueller wrote: > > If you would like to use csup/cvsup mechanisms to access the source > > tree the branch tag to use is now "RELENG_9_0", if you use "." (head) > > you will get 10-CURRENT. If you would like to access the source tree > > via SVN it is "svn://svn.freebsd.org/base/releng/9.0/". We still have > > the nit that the creation of a new SVN branch winds up causing what > > looks like a check-in of the entire tree in CVS (a side-effect of the > > svn2cvs exporter) so "mergemaster -F" is your friend if you are using > > csup/cvsup. >=20 > About a couple days before seeing this message, or the message on the > FreeBSD web site, but after seeing RC2 on the ftp.freebsd.org server, > I already ran csup with >=20 > *default release=3Dcvs tag=3DRELENG_9 >=20 > Am I screwed, am I OK, or do I simply have to rerun csup with > RELENG_9_0 instead of RELENG_9 ? >=20 > Again, I can't find that file (needle in the haystack) in /usr/src > tree that shows version number such as RC2. Take a look at /sys/conf/newvers.sh --dMyqICaxQaaUjrCL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7GOpMACgkQKc512sD3afgJowCff46UyVwvYH0yZjufbgteIdiE sjIAnjr7HJJwWVG553kSjTtz/mQ+nIYv =pAcu -----END PGP SIGNATURE----- --dMyqICaxQaaUjrCL-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 11:01:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A5E61065670; Fri, 18 Nov 2011 11:01:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 19D508FC13; Fri, 18 Nov 2011 11:01:11 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAIB1345014167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Nov 2011 13:01:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAIB131X017881; Fri, 18 Nov 2011 13:01:03 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAIB13Lu017880; Fri, 18 Nov 2011 13:01:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 Nov 2011 13:01:03 +0200 From: Kostik Belousov To: Attilio Rao Message-ID: <20111118110103.GE50300@deviant.kiev.zoral.com.ua> References: <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> <20111107193516.GA50300@deviant.kiev.zoral.com.ua> <20111116084542.GY50300@deviant.kiev.zoral.com.ua> <20111118105224.GB50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bmCMfij1YEBRfNho" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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: mdf@freebsd.org, "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 11:01:12 -0000 --bmCMfij1YEBRfNho Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 18, 2011 at 11:56:55AM +0100, Attilio Rao wrote: > 2011/11/18 Kostik Belousov : > > On Fri, Nov 18, 2011 at 11:40:28AM +0100, Attilio Rao wrote: > >> 2011/11/16 Kostik Belousov : > >> > On Tue, Nov 15, 2011 at 07:15:01PM +0100, Attilio Rao wrote: > >> >> 2011/11/7 Kostik Belousov : > >> >> > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: > >> >> >> Ok. =9AI'll offer one final suggestion. =9APlease consider an al= ternative > >> >> >> suffix to "func". =9APerhaps, "kbi" or "KBI". =9AIn other words,= something > >> >> >> that hints at the function's reason for existing. > >> >> > > >> >> > Sure. Below is the extraction of only vm_page_lock() bits, togeth= er > >> >> > with the suggested rename. When Attilio provides the promised sim= plification > >> >> > of the mutex KPI, this can be reduced. > >> >> > >> >> My tentative patch is here: > >> >> http://www.freebsd.org/~attilio/mutexfileline.patch > >> >> > >> >> I need to make more compile testing later, but it already compiles > >> >> GENERIC + modules fine on HEAD. > >> >> > >> >> The patch provides a common entrypoint, option independent, for both > >> >> fast case and debug/compat case. > >> >> Additively, it almost entirely fixes the standard violation of the > >> >> reserved namespace, as you described (the notable exception being t= he > >> >> macro used in the fast path, that I want to fix as well, but in a > >> >> separate commit). > >> >> > >> >> Now the file/line couplet can be passed to the "_" suffix variant of > >> >> the flag functions. > >> > Yes, this is exactly KPI that I would use when available for the > >> > vm_page_lock() patch. > >> > > >> >> > >> >> eadler@ reviewed the mutex.h comment. > >> >> > >> >> Please let me know what you think about it, as long as we agree on = the > >> >> patch I'll commit it. > >> > But I also agree with John that imposing large churn due to the elim= ination > >> > of the '__' prefix is too late now. At least it will make the change > >> > non-MFCable. Besides, we already lived with the names for 10+ years. > >> > > >> > I will be happy to have the part of the patch that exports the mtx_X= XX_(mtx, > >> > file, line) defines which can be used without taking care of LOCK_DE= BUG > >> > or MUTEX_NOINLINE in the consumer code. > >> > >> Ok, this patch should just add the compat stub: > >> http://www.freebsd.org/~attilio/mutexfileline2.patch > > Am I right that I would use mtx_lock_(mtx, file, line) etc ? > > If yes, I am fine with it. >=20 > Yes that is correct. >=20 > However, I'm a bit confused on one aspect: would you mind using > _mtx_lock_flags() instead? > If you don't mind the "underscore namespace violation" I think I can > make a much smaller patch against HEAD for it. _mtx_lock_flags() is fine. The reserved names start with __ or _[A-Z]. >=20 > Otherwise, the one now posted should be ok. >=20 > Attilio >=20 >=20 > --=20 > Peace can only be achieved by understanding - A. Einstein --bmCMfij1YEBRfNho Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7GOu8ACgkQC3+MBN1Mb4jqwQCg3iRmUyrlvvsSrzbB1E9IjIqf nDoAmgPXNbLBOTdyBuBGte9/RSnsoRBJ =z+XH -----END PGP SIGNATURE----- --bmCMfij1YEBRfNho-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 11:26:57 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1B2E1065672; Fri, 18 Nov 2011 11:26:57 +0000 (UTC) (envelope-from philip@freebsd.org) Received: from rincewind.paeps.cx (rincewind.paeps.cx [IPv6:2002:596a:f092::149]) by mx1.freebsd.org (Postfix) with ESMTP id 30BB38FC12; Fri, 18 Nov 2011 11:26:57 +0000 (UTC) Received: from [192.168.2.103] (unknown [87.68.144.35]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: philip) by rincewind.paeps.cx (Postfix) with ESMTPSA id 77A31D74403; Fri, 18 Nov 2011 12:26:49 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Philip Paeps In-Reply-To: Date: Fri, 18 Nov 2011 13:26:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201111171955.pAHJtJj5028599@freebsd-current.sentex.ca> To: Garrett Cooper X-Mailer: Apple Mail (2.1251.1) Cc: arm@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 11:26:58 -0000 On 17 Nov 2011, at 23:31, Garrett Cooper wrote: > On Thu, Nov 17, 2011 at 11:55 AM, FreeBSD Tinderbox > wrote: >> TB --- 2011-11-17 18:10:01 - tinderbox 2.8 running on = freebsd-current.sentex.ca >> TB --- 2011-11-17 18:10:01 - starting HEAD tinderbox run for arm/arm >> TB --- 2011-11-17 18:10:01 - cleaning the object tree >> TB --- 2011-11-17 18:10:26 - cvsupping the source tree >> TB --- 2011-11-17 18:10:26 - /usr/bin/csup -z -r 3 -g -L 1 -h = cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile >> TB --- 2011-11-17 18:11:12 - building world >> TB --- 2011-11-17 18:11:12 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 18:11:12 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 18:11:12 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 18:11:12 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 18:11:12 - TARGET=3Darm >> TB --- 2011-11-17 18:11:12 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 18:11:12 - TZ=3DUTC >> TB --- 2011-11-17 18:11:12 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 18:11:12 - cd /src >> TB --- 2011-11-17 18:11:12 - /usr/bin/make -B buildworld >>>>> World build started on Thu Nov 17 18:11:12 UTC 2011 >>>>> 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 Thu Nov 17 19:06:31 UTC 2011 >> TB --- 2011-11-17 19:06:31 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:06:31 - /usr/sbin/config -m AVILA >> TB --- 2011-11-17 19:06:31 - building AVILA kernel >> TB --- 2011-11-17 19:06:31 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:06:31 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:06:31 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:06:31 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:06:31 - TARGET=3Darm >> TB --- 2011-11-17 19:06:31 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:06:31 - TZ=3DUTC >> TB --- 2011-11-17 19:06:31 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:06:31 - cd /src >> TB --- 2011-11-17 19:06:31 - /usr/bin/make -B buildkernel = KERNCONF=3DAVILA >>>>> Kernel build for AVILA started on Thu Nov 17 19:06:31 UTC 2011 >>>>> 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 >>>>> Kernel build for AVILA completed on Thu Nov 17 19:09:34 UTC 2011 >> TB --- 2011-11-17 19:09:34 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:09:34 - /usr/sbin/config -m BWCT >> TB --- 2011-11-17 19:09:35 - building BWCT kernel >> TB --- 2011-11-17 19:09:35 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:09:35 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:09:35 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:09:35 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:09:35 - TARGET=3Darm >> TB --- 2011-11-17 19:09:35 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:09:35 - TZ=3DUTC >> TB --- 2011-11-17 19:09:35 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:09:35 - cd /src >> TB --- 2011-11-17 19:09:35 - /usr/bin/make -B buildkernel = KERNCONF=3DBWCT >>>>> Kernel build for BWCT started on Thu Nov 17 19:09:35 UTC 2011 >>>>> 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 >>>>> Kernel build for BWCT completed on Thu Nov 17 19:12:13 UTC 2011 >> TB --- 2011-11-17 19:12:13 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:12:13 - /usr/sbin/config -m CAMBRIA >> TB --- 2011-11-17 19:12:13 - building CAMBRIA kernel >> TB --- 2011-11-17 19:12:13 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:12:13 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:12:13 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:12:13 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:12:13 - TARGET=3Darm >> TB --- 2011-11-17 19:12:13 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:12:13 - TZ=3DUTC >> TB --- 2011-11-17 19:12:13 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:12:13 - cd /src >> TB --- 2011-11-17 19:12:13 - /usr/bin/make -B buildkernel = KERNCONF=3DCAMBRIA >>>>> Kernel build for CAMBRIA started on Thu Nov 17 19:12:13 UTC 2011 >>>>> 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 >>>>> Kernel build for CAMBRIA completed on Thu Nov 17 19:15:10 UTC 2011 >> TB --- 2011-11-17 19:15:10 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:15:10 - /usr/sbin/config -m CNS11XXNAS >> TB --- 2011-11-17 19:15:11 - building CNS11XXNAS kernel >> TB --- 2011-11-17 19:15:11 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:15:11 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:15:11 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:15:11 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:15:11 - TARGET=3Darm >> TB --- 2011-11-17 19:15:11 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:15:11 - TZ=3DUTC >> TB --- 2011-11-17 19:15:11 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:15:11 - cd /src >> TB --- 2011-11-17 19:15:11 - /usr/bin/make -B buildkernel = KERNCONF=3DCNS11XXNAS >>>>> Kernel build for CNS11XXNAS started on Thu Nov 17 19:15:11 UTC = 2011 >>>>> 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 >>>>> Kernel build for CNS11XXNAS completed on Thu Nov 17 19:17:41 UTC = 2011 >> TB --- 2011-11-17 19:17:41 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:17:41 - /usr/sbin/config -m CRB >> TB --- 2011-11-17 19:17:41 - building CRB kernel >> TB --- 2011-11-17 19:17:41 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:17:41 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:17:41 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:17:41 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:17:41 - TARGET=3Darm >> TB --- 2011-11-17 19:17:41 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:17:41 - TZ=3DUTC >> TB --- 2011-11-17 19:17:41 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:17:41 - cd /src >> TB --- 2011-11-17 19:17:41 - /usr/bin/make -B buildkernel = KERNCONF=3DCRB >>>>> Kernel build for CRB started on Thu Nov 17 19:17:41 UTC 2011 >>>>> 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 >>>>> Kernel build for CRB completed on Thu Nov 17 19:21:31 UTC 2011 >> TB --- 2011-11-17 19:21:31 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:21:31 - /usr/sbin/config -m DB-78XXX >> TB --- 2011-11-17 19:21:31 - building DB-78XXX kernel >> TB --- 2011-11-17 19:21:31 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:21:31 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:21:31 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:21:31 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:21:31 - TARGET=3Darm >> TB --- 2011-11-17 19:21:31 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:21:31 - TZ=3DUTC >> TB --- 2011-11-17 19:21:31 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:21:31 - cd /src >> TB --- 2011-11-17 19:21:31 - /usr/bin/make -B buildkernel = KERNCONF=3DDB-78XXX >>>>> Kernel build for DB-78XXX started on Thu Nov 17 19:21:31 UTC 2011 >>>>> 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 >>>>> Kernel build for DB-78XXX completed on Thu Nov 17 19:24:08 UTC = 2011 >> TB --- 2011-11-17 19:24:08 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:24:08 - /usr/sbin/config -m DB-88F5XXX >> TB --- 2011-11-17 19:24:08 - building DB-88F5XXX kernel >> TB --- 2011-11-17 19:24:08 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:24:08 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:24:08 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:24:08 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:24:08 - TARGET=3Darm >> TB --- 2011-11-17 19:24:08 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:24:08 - TZ=3DUTC >> TB --- 2011-11-17 19:24:08 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:24:08 - cd /src >> TB --- 2011-11-17 19:24:08 - /usr/bin/make -B buildkernel = KERNCONF=3DDB-88F5XXX >>>>> Kernel build for DB-88F5XXX started on Thu Nov 17 19:24:08 UTC = 2011 >>>>> 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 >>>>> Kernel build for DB-88F5XXX completed on Thu Nov 17 19:26:47 UTC = 2011 >> TB --- 2011-11-17 19:26:47 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:26:47 - /usr/sbin/config -m DB-88F6XXX >> TB --- 2011-11-17 19:26:48 - building DB-88F6XXX kernel >> TB --- 2011-11-17 19:26:48 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:26:48 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:26:48 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:26:48 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:26:48 - TARGET=3Darm >> TB --- 2011-11-17 19:26:48 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:26:48 - TZ=3DUTC >> TB --- 2011-11-17 19:26:48 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:26:48 - cd /src >> TB --- 2011-11-17 19:26:48 - /usr/bin/make -B buildkernel = KERNCONF=3DDB-88F6XXX >>>>> Kernel build for DB-88F6XXX started on Thu Nov 17 19:26:48 UTC = 2011 >>>>> 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 >>>>> Kernel build for DB-88F6XXX completed on Thu Nov 17 19:29:54 UTC = 2011 >> TB --- 2011-11-17 19:29:54 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:29:54 - /usr/sbin/config -m DOCKSTAR >> TB --- 2011-11-17 19:29:54 - building DOCKSTAR kernel >> TB --- 2011-11-17 19:29:54 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:29:54 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:29:54 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:29:54 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:29:54 - TARGET=3Darm >> TB --- 2011-11-17 19:29:54 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:29:54 - TZ=3DUTC >> TB --- 2011-11-17 19:29:54 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:29:54 - cd /src >> TB --- 2011-11-17 19:29:54 - /usr/bin/make -B buildkernel = KERNCONF=3DDOCKSTAR >>>>> Kernel build for DOCKSTAR started on Thu Nov 17 19:29:55 UTC 2011 >>>>> 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 >>>>> Kernel build for DOCKSTAR completed on Thu Nov 17 19:32:30 UTC = 2011 >> TB --- 2011-11-17 19:32:30 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:32:30 - /usr/sbin/config -m EP80219 >> TB --- 2011-11-17 19:32:30 - building EP80219 kernel >> TB --- 2011-11-17 19:32:30 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:32:30 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:32:30 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:32:30 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:32:30 - TARGET=3Darm >> TB --- 2011-11-17 19:32:30 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:32:30 - TZ=3DUTC >> TB --- 2011-11-17 19:32:30 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:32:30 - cd /src >> TB --- 2011-11-17 19:32:30 - /usr/bin/make -B buildkernel = KERNCONF=3DEP80219 >>>>> Kernel build for EP80219 started on Thu Nov 17 19:32:30 UTC 2011 >>>>> 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 >>>>> Kernel build for EP80219 completed on Thu Nov 17 19:35:22 UTC 2011 >> TB --- 2011-11-17 19:35:22 - WARNING: no kernel config for GENERIC >> TB --- 2011-11-17 19:35:22 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:35:22 - /usr/sbin/config -m GUMSTIX >> TB --- 2011-11-17 19:35:22 - building GUMSTIX kernel >> TB --- 2011-11-17 19:35:22 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:35:22 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:35:22 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:35:22 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:35:22 - TARGET=3Darm >> TB --- 2011-11-17 19:35:22 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:35:22 - TZ=3DUTC >> TB --- 2011-11-17 19:35:22 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:35:22 - cd /src >> TB --- 2011-11-17 19:35:22 - /usr/bin/make -B buildkernel = KERNCONF=3DGUMSTIX >>>>> Kernel build for GUMSTIX started on Thu Nov 17 19:35:22 UTC 2011 >>>>> 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 >>>>> Kernel build for GUMSTIX completed on Thu Nov 17 19:37:40 UTC 2011 >> TB --- 2011-11-17 19:37:40 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:37:40 - /usr/sbin/config -m HL200 >> TB --- 2011-11-17 19:37:40 - building HL200 kernel >> TB --- 2011-11-17 19:37:41 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:37:41 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:37:41 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:37:41 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:37:41 - TARGET=3Darm >> TB --- 2011-11-17 19:37:41 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:37:41 - TZ=3DUTC >> TB --- 2011-11-17 19:37:41 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:37:41 - cd /src >> TB --- 2011-11-17 19:37:41 - /usr/bin/make -B buildkernel = KERNCONF=3DHL200 >>>>> Kernel build for HL200 started on Thu Nov 17 19:37:41 UTC 2011 >>>>> 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 >>>>> Kernel build for HL200 completed on Thu Nov 17 19:40:46 UTC 2011 >> TB --- 2011-11-17 19:40:46 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:40:46 - /usr/sbin/config -m HL201 >> TB --- 2011-11-17 19:40:50 - building HL201 kernel >> TB --- 2011-11-17 19:40:50 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:40:50 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:40:50 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:40:50 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:40:50 - TARGET=3Darm >> TB --- 2011-11-17 19:40:50 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:40:50 - TZ=3DUTC >> TB --- 2011-11-17 19:40:50 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:40:50 - cd /src >> TB --- 2011-11-17 19:40:50 - /usr/bin/make -B buildkernel = KERNCONF=3DHL201 >>>>> Kernel build for HL201 started on Thu Nov 17 19:40:50 UTC 2011 >>>>> 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 >>>>> Kernel build for HL201 completed on Thu Nov 17 19:43:10 UTC 2011 >> TB --- 2011-11-17 19:43:10 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:43:10 - /usr/sbin/config -m IQ31244 >> TB --- 2011-11-17 19:43:10 - building IQ31244 kernel >> TB --- 2011-11-17 19:43:10 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:43:10 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:43:10 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:43:10 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:43:10 - TARGET=3Darm >> TB --- 2011-11-17 19:43:10 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:43:10 - TZ=3DUTC >> TB --- 2011-11-17 19:43:10 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:43:10 - cd /src >> TB --- 2011-11-17 19:43:10 - /usr/bin/make -B buildkernel = KERNCONF=3DIQ31244 >>>>> Kernel build for IQ31244 started on Thu Nov 17 19:43:10 UTC 2011 >>>>> 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 >>>>> Kernel build for IQ31244 completed on Thu Nov 17 19:46:26 UTC 2011 >> TB --- 2011-11-17 19:46:26 - cd /src/sys/arm/conf >> TB --- 2011-11-17 19:46:26 - /usr/sbin/config -m KB920X >> TB --- 2011-11-17 19:46:26 - building KB920X kernel >> TB --- 2011-11-17 19:46:26 - CROSS_BUILD_TESTING=3DYES >> TB --- 2011-11-17 19:46:26 - MAKEOBJDIRPREFIX=3D/obj >> TB --- 2011-11-17 19:46:26 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:46:26 - SRCCONF=3D/dev/null >> TB --- 2011-11-17 19:46:26 - TARGET=3Darm >> TB --- 2011-11-17 19:46:26 - TARGET_ARCH=3Darm >> TB --- 2011-11-17 19:46:26 - TZ=3DUTC >> TB --- 2011-11-17 19:46:26 - __MAKE_CONF=3D/dev/null >> TB --- 2011-11-17 19:46:26 - cd /src >> TB --- 2011-11-17 19:46:26 - /usr/bin/make -B buildkernel = KERNCONF=3DKB920X >>>>> Kernel build for KB920X started on Thu Nov 17 19:46:27 UTC 2011 >>>>> 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 >> [...] >> objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols >> objcopy --strip-debug --add-gnu-debuglink=3Dif_sf.ko.symbols = if_sf.ko.debug if_sf.ko >> =3D=3D=3D> sfxge (all) >> cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include = /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq = -finline-limit=3D8000 --param inline-unit-growth=3D100 --param = large-function-growth=3D1000 -fno-common -g -DDEBUG=3D1 = -I/obj/arm.arm/src/sys/KB920X -mcpu=3Darm9 -ffreestanding = -std=3Diso9899:1999 -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions = -Wmissing-include-dirs -fdiagnostics-show-option -c = /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c >> cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include = /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq = -finline-limit=3D8000 --param inline-unit-growth=3D100 --param = large-function-growth=3D1000 -fno-common -g -DDEBUG=3D1 = -I/obj/arm.arm/src/sys/KB920X -mcpu=3Darm9 -ffreestanding = -std=3Diso9899:1999 -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions = -Wmissing-include-dirs -fdiagnostics-show-option -c = /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c >> cc1: warnings being treated as errors >> /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function = 'sfxge_dma_alloc': >> /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: = large integer implicitly truncated to unsigned type [-Woverflow] >> *** Error code 1 >=20 > I've already contacted philip about these build issues (all 32-bit > archs -- and I think ia64 -- currently fail to build via tinderbox > because of this error). Bottom line is that I think this driver should > be removed from all 32-bit builds.. was waiting for feedback from him > on that. I have just committed a change to modules/Makefile to limit the build to amd64. I see that Marius has committed changes to fix the build on = other architectures, but I'd like to make sure the driver actually runs on = them before adding the driver to them again. - Philip --=20 Philip Paeps Senior Reality Engineer Ministry of Information From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 11:27:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D7EC10656F5 for ; Fri, 18 Nov 2011 11:27:50 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3fd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id D21E88FC13 for ; Fri, 18 Nov 2011 11:27:49 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id pAIBRdgG004480 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 18 Nov 2011 11:27:40 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: OpenDKIM Filter v2.4.1 smtp.infracaninophile.co.uk pAIBRdgG004480 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1321615660; bh=nNivh5OD2gEadvxWM3WK5A1ZJePDRsqvkK2RGZLvYvo=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Cc; b=r8Xgx0UWHBNoBdmrUHZIuFeLENkgNcuSXxulp7xNhDGLBqBzUToP3d7+uaOwHRV5G 2p9nWxOcw1Pb1hKU8x8HmSYrTe02JBs2f19S0ncz5+c4pithnNgrLSvzsvIm4B+DfY euX6kj9YpEwAke5MFSLiUxMZg2jH0BoQ4Lrxftfs= Message-ID: <4EC6411A.2030703@infracaninophile.co.uk> Date: Fri, 18 Nov 2011 11:27:22 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <1321553970.82271.66.camel@bauer.cse.buffalo.edu> <20111118105339.1CE9D1065688@hub.freebsd.org> In-Reply-To: <20111118105339.1CE9D1065688@hub.freebsd.org> X-Enigmail-Version: 1.3.3 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig67E661D6B6800E832D2EA294" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_FAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Subject: Re: FreeBSD 9.0-RC2 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 11:27:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig67E661D6B6800E832D2EA294 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 18/11/2011 10:53, Thomas Mueller wrote: > *default release=3Dcvs tag=3DRELENG_9 >=20 > Am I screwed, am I OK, or do I simply have to rerun csup with RELENG_9_= 0 instead of RELENG_9 ? Not screwed, but you'll be running 9.0-PRERELEASE rather than 9.0-RC2. If you want to switch to the 9.0-RELEASE branch, change the tag to RELENG_9_0 and cvsup again. Then redo the whole buildworld dance. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig67E661D6B6800E832D2EA294 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7GQSoACgkQ8Mjk52CukIwVAgCfdx4Z+nEIUx4SaywcfaaqxSZu 7gEAn2btuwsRsNG31NyqzhwQx8kJ3qqK =8rsB -----END PGP SIGNATURE----- --------------enig67E661D6B6800E832D2EA294-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 11:36:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C75F1065670 for ; Fri, 18 Nov 2011 11:36:04 +0000 (UTC) (envelope-from luchesar.iliev@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id B28A58FC15 for ; Fri, 18 Nov 2011 11:36:03 +0000 (UTC) Received: by eyd10 with SMTP id 10so4547890eyd.13 for ; Fri, 18 Nov 2011 03:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=XNN7n9BYkWAuIMXbb0Xdt/xWkgwuPdwvDTEFzOotyzM=; b=xTcz/edB3HVyRF/NHoZEDB+cP07rHf8GSTptOzsNxwuAKuPXJobilIEpZlyGQMq2DQ GQ57hpu0AGxCIDdjlZtRBeKXtsFkfj8XuoNXeNo/SiezWosRCxg8W+B+g03EW9vsPoT1 frZXW4KhAwbZSQmQ4fpazGRdKwHDpPqvxnuTE= Received: by 10.213.29.131 with SMTP id q3mr946198ebc.115.1321616162528; Fri, 18 Nov 2011 03:36:02 -0800 (PST) Received: from [79.124.93.41] ([79.124.93.41]) by mx.google.com with ESMTPS id t6sm1582788eeb.11.2011.11.18.03.36.00 (version=SSLv3 cipher=OTHER); Fri, 18 Nov 2011 03:36:01 -0800 (PST) Message-ID: <4EC6431F.7000806@gmail.com> Date: Fri, 18 Nov 2011 13:35:59 +0200 From: "Luchesar V. ILIEV" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Thomas Mueller References: <1321553970.82271.66.camel@bauer.cse.buffalo.edu> <20111118105339.1CE9D1065688@hub.freebsd.org> In-Reply-To: <20111118105339.1CE9D1065688@hub.freebsd.org> X-Enigmail-Version: undefined OpenPGP: id=9A1FEEFF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ken Smith Subject: Re: FreeBSD 9.0-RC2 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 11:36:04 -0000 On 18/11/2011 12:53, Thomas Mueller wrote: >> If you would like to use csup/cvsup mechanisms to access the source >> tree the branch tag to use is now "RELENG_9_0", if you use "." (head) >> you will get 10-CURRENT. If you would like to access the source tree >> via SVN it is "svn://svn.freebsd.org/base/releng/9.0/". We still have >> the nit that the creation of a new SVN branch winds up causing what >> looks like a check-in of the entire tree in CVS (a side-effect of the >> svn2cvs exporter) so "mergemaster -F" is your friend if you are using >> csup/cvsup. > > About a couple days before seeing this message, or the message on the FreeBSD web site, but after seeing RC2 on the ftp.freebsd.org server, > I already ran csup with > > *default release=cvs tag=RELENG_9 > > Am I screwed, am I OK, or do I simply have to rerun csup with RELENG_9_0 instead of RELENG_9 ? RELENG_9 (cvs) = stable/9 (svn) = 9.N-STABLE (newvers.sh, `uname -r`) RELENG_9_0 (cvs) = releng/9.0 (svn) = 9.0-RELEASE (newvers.sh, uname) In short, if you want to use the 9.0-RELEASE (when it finally gets ready), then you need to switch to RELENG_9_0. If you prefer using -STABLE for your systems, then you're OK with RELENG_9. In case you don't know or are not quite sure about the differences between -RELEASE and -STABLE, I'd recommend switching to RELENG_9_0. > Again, I can't find that file (needle in the haystack) in /usr/src tree that shows version number such as RC2. This has already been answered, but just a quick note. If you've recently updated your sources using the RELENG_9 tag, you'll most likely see the version in newvers.sh as: REVISION="9.0" BRANCH="PRERELEASE" If you switch to RELENG_9_0 and update your sources again, you should see the familiar: REVISION="9.0" BRANCH="RC2" HTH, Luchesar -- i.dea.is/luchesar From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 12:21:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5C451065670 for ; Fri, 18 Nov 2011 12:21:59 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.98]) by mx1.freebsd.org (Postfix) with ESMTP id 76B8B8FC15 for ; Fri, 18 Nov 2011 12:21:59 +0000 (UTC) Received: from [78.35.81.42] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1RRNS9-0000Bc-Lb for freebsd-current@freebsd.org; Fri, 18 Nov 2011 13:21:57 +0100 Date: Fri, 18 Nov 2011 13:21:54 +0100 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20111118132154.6111dfc3@fabiankeil.de> In-Reply-To: <4EC500CD.6040305@FreeBSD.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <20111116202714.5ee4bd53@fabiankeil.de> <4EC43764.1020202@FreeBSD.org> <4EC4423A.3020904@FreeBSD.org> <20111117081533.GP50300@deviant.kiev.zoral.com.ua> <4EC4C89A.2040208@FreeBSD.org> <20111117090653.GR50300@deviant.kiev.zoral.com.ua> <4EC4D3DE.8080103@FreeBSD.org> <20111117111405.GT50300@deviant.kiev.zoral.com.ua> <4EC500CD.6040305@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/bbrVtMXU2KCXmKRPHha6=ZC"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 12:22:00 -0000 --Sig_/bbrVtMXU2KCXmKRPHha6=ZC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Alexander Motin wrote: > On 11/17/11 13:14, Kostik Belousov wrote: > > On Thu, Nov 17, 2011 at 11:29:02AM +0200, Alexander Motin wrote: > >> On 11/17/11 11:06, Kostik Belousov wrote: > >>> On Thu, Nov 17, 2011 at 10:40:58AM +0200, Alexander Motin wrote: > >>>> On 11/17/11 10:15, Kostik Belousov wrote: > >>>>> On Thu, Nov 17, 2011 at 01:07:38AM +0200, Alexander Motin wrote: > >>>>>> On 17.11.2011 00:21, Andriy Gapon wrote: > >>>>>>> on 16/11/2011 21:27 Fabian Keil said the following: > >>>>>>>> Kostik Belousov wrote: > >>>>>>>> > >>>>>>>>> I was tricked into finishing the work by Andrey Gapon, who deve= loped > >>>>>>>>> the patch to reliably stop other processors on panic. The patch > >>>>>>>>> greatly improves the chances of getting dump on panic on SMP ho= st. > >>>>>>>> > >>>>>>>> I tested the patch trying to get a dump (from the debugger) for > >>>>>>>> kern/162036, which currently results in the double fault reporte= d in: > >>>>>>>> http://lists.freebsd.org/pipermail/freebsd-current/2011-Septembe= r/027766.html > >>>>>>>> > >>>>>>>> It didn't help, but also didn't make anything worse. > >>>>>>> The mi_switch recursion looks very familiar to me: > >>>>>>> mi_switch() at mi_switch+0x270 > >>>>>>> critical_exit() at critical_exit+0x9b > >>>>>>> spinlock_exit() at spinlock_exit+0x17 > >>>>>>> mi_switch() at mi_switch+0x275 > >>>>>>> critical_exit() at critical_exit+0x9b > >>>>>>> spinlock_exit() at spinlock_exit+0x17 > >>>>>>> [several pages of the previous three lines skipped] > >>>>>>> mi_switch() at mi_switch+0x275 > >>>>>>> critical_exit() at critical_exit+0x9b > >>>>>>> spinlock_exit() at spinlock_exit+0x17 > >>>>>>> intr_even_schedule_thread() at intr_event_schedule_thread+0xbb > >>>>>>> ahci_end_transaction() at ahci_end_transaction+0x398 > >>>>>>> ahci_ch_intr() at ahci_ch_intr+0x2b5 > >>>>>>> ahcipoll() at ahcipoll+0x15 > >>>>>>> xpt_polled_action() at xpt_polled_action+0xf7 > >>>>>>> > >>>>>>> In fact I once discussed with jhb this recursion triggered from a= different > >>>>>>> place. To quote myself: > >>>>>>> spinlock_exit -> critical_exit -> mi_switch -> kdb_sw= itch -> > >>>>>>> thread_unlock -> spinlock_exit -> critical_exit -> mi_switch -= > ... > >>>>>>> in the kdb context > >>>>>>> this issue seems to be triggered by td_owepreempt being = true at=20 > >>>>>>> the time > >>>>>>> kdb is entered > >>>>>>> and there of course has to be an initial spinlock_exit c= all=20 > >>>>>>> somewhere > >>>>>>> in my case it's because of usb keyboard > >>>>>>> I wonder if it would make sense to clear td_owepreempt r= ight=20 > >>>>>>> before > >>>>>>> calling kdb_switch in mi_switch > >>>>>>> instead of in sched_switch() > >>>>>>> clearing td_owepreempt seems like a scheduler-independen= t=20 > >>>>>>> operation to me > >>>>>>> or is it better to just skip locking in usb when kdb_act= ive is set > >>>>>>> ? > >>>>>>> > >>>>>>> The workaround described above should work in this case. > >>>>>>> Another possibility is to pessimize mtx_unlock_spin() implementat= ions to=20 > >>>>>>> check > >>>>>>> SCHEDULER_STOPPED() and to bypass any further actions in that cas= e. But=20 > >>>>>>> that > >>>>>>> would add unnecessary overhead to the sunny day code paths. > >>>>>>> > >>>>>>> Going further up the stack one can come up with the following pro= posals: > >>>>>>> - check SCHEDULER_STOPPED() swi_sched() and return early > >>>>>>> - do not call swi_sched() from xpt_done() if we somehow know that= we are=20 > >>>>>>> in a > >>>>>>> polling mode > >>>>>> > >>>>>> There is no flag in CAM now to indicate polling mode, but if neede= d, it=20 > >>>>>> should not be difficult to add one and not call swi_sched(). > >>>>> > >>>>> I have the following change for eons on my test boxes. Without it, > >>>>> I simply cannot get _any_ dump. > >>>> That should be OK for kernel dumping. I was thinking about CAM abusi= ng > >>>> polling not only for dumping. But looking on cases where it does it = now, > >>>> may be it is better to rewrite them instead. > >>> > >>> So, should I interpret your response as 'Reviewed by" ? > >> > >> It feels somehow dirty to me. I don't like these global variables. If > >> you consider it is fine, proceed, I see no much harm. But if not, I can > >> add polling flag to the CAM. Flip a coin for me. :) > > You promised to add the polling at summer' meeting in Kiev. Will you do > > it now ? >=20 > Sorry, I've probably forgot. The patch is attached. After rebasing on r227637 dumping core from the debugger works and the backtrace is at least partly usable. PR updated. Thanks a lot. Fabian --Sig_/bbrVtMXU2KCXmKRPHha6=ZC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7GTecACgkQBYqIVf93VJ1DVACfQYJGodBgUcqaf2XykzMfO8QI oUUAoM54oBHFdNYIi+KOCGvQ7M8MlUNq =eIDt -----END PGP SIGNATURE----- --Sig_/bbrVtMXU2KCXmKRPHha6=ZC-- From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 12:41:13 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DB8C1065670; Fri, 18 Nov 2011 12:41:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D08538FC08; Fri, 18 Nov 2011 12:41:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.4) with ESMTP id pAICfChY003307; Fri, 18 Nov 2011 07:41:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.4/Submit) id pAICfBId003282; Fri, 18 Nov 2011 12:41:11 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 18 Nov 2011 12:41:11 GMT Message-Id: <201111181241.pAICfBId003282@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 12:41:13 -0000 TB --- 2011-11-18 11:00:01 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-18 11:00:01 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-18 11:00:01 - cleaning the object tree TB --- 2011-11-18 11:00:24 - cvsupping the source tree TB --- 2011-11-18 11:00:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-18 11:01:12 - building world TB --- 2011-11-18 11:01:12 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 11:01:12 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 11:01:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 11:01:12 - SRCCONF=/dev/null TB --- 2011-11-18 11:01:12 - TARGET=arm TB --- 2011-11-18 11:01:12 - TARGET_ARCH=arm TB --- 2011-11-18 11:01:12 - TZ=UTC TB --- 2011-11-18 11:01:12 - __MAKE_CONF=/dev/null TB --- 2011-11-18 11:01:12 - cd /src TB --- 2011-11-18 11:01:12 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 18 11:01:13 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 18 11:54:23 UTC 2011 TB --- 2011-11-18 11:54:24 - cd /src/sys/arm/conf TB --- 2011-11-18 11:54:24 - /usr/sbin/config -m AVILA TB --- 2011-11-18 11:54:24 - building AVILA kernel TB --- 2011-11-18 11:54:24 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 11:54:24 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 11:54:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 11:54:24 - SRCCONF=/dev/null TB --- 2011-11-18 11:54:24 - TARGET=arm TB --- 2011-11-18 11:54:24 - TARGET_ARCH=arm TB --- 2011-11-18 11:54:24 - TZ=UTC TB --- 2011-11-18 11:54:24 - __MAKE_CONF=/dev/null TB --- 2011-11-18 11:54:24 - cd /src TB --- 2011-11-18 11:54:24 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Fri Nov 18 11:54:24 UTC 2011 >>> 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 >>> Kernel build for AVILA completed on Fri Nov 18 11:57:26 UTC 2011 TB --- 2011-11-18 11:57:26 - cd /src/sys/arm/conf TB --- 2011-11-18 11:57:26 - /usr/sbin/config -m BWCT TB --- 2011-11-18 11:57:26 - building BWCT kernel TB --- 2011-11-18 11:57:26 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 11:57:26 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 11:57:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 11:57:26 - SRCCONF=/dev/null TB --- 2011-11-18 11:57:26 - TARGET=arm TB --- 2011-11-18 11:57:26 - TARGET_ARCH=arm TB --- 2011-11-18 11:57:26 - TZ=UTC TB --- 2011-11-18 11:57:26 - __MAKE_CONF=/dev/null TB --- 2011-11-18 11:57:26 - cd /src TB --- 2011-11-18 11:57:26 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Fri Nov 18 11:57:26 UTC 2011 >>> 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 >>> Kernel build for BWCT completed on Fri Nov 18 11:59:33 UTC 2011 TB --- 2011-11-18 11:59:33 - cd /src/sys/arm/conf TB --- 2011-11-18 11:59:33 - /usr/sbin/config -m CAMBRIA TB --- 2011-11-18 11:59:33 - building CAMBRIA kernel TB --- 2011-11-18 11:59:33 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 11:59:33 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 11:59:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 11:59:33 - SRCCONF=/dev/null TB --- 2011-11-18 11:59:33 - TARGET=arm TB --- 2011-11-18 11:59:33 - TARGET_ARCH=arm TB --- 2011-11-18 11:59:33 - TZ=UTC TB --- 2011-11-18 11:59:33 - __MAKE_CONF=/dev/null TB --- 2011-11-18 11:59:33 - cd /src TB --- 2011-11-18 11:59:33 - /usr/bin/make -B buildkernel KERNCONF=CAMBRIA >>> Kernel build for CAMBRIA started on Fri Nov 18 11:59:33 UTC 2011 >>> 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 >>> Kernel build for CAMBRIA completed on Fri Nov 18 12:02:31 UTC 2011 TB --- 2011-11-18 12:02:31 - cd /src/sys/arm/conf TB --- 2011-11-18 12:02:31 - /usr/sbin/config -m CNS11XXNAS TB --- 2011-11-18 12:02:31 - building CNS11XXNAS kernel TB --- 2011-11-18 12:02:31 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 12:02:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 12:02:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 12:02:31 - SRCCONF=/dev/null TB --- 2011-11-18 12:02:31 - TARGET=arm TB --- 2011-11-18 12:02:31 - TARGET_ARCH=arm TB --- 2011-11-18 12:02:31 - TZ=UTC TB --- 2011-11-18 12:02:31 - __MAKE_CONF=/dev/null TB --- 2011-11-18 12:02:31 - cd /src TB --- 2011-11-18 12:02:31 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Fri Nov 18 12:02:31 UTC 2011 >>> 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 >>> Kernel build for CNS11XXNAS completed on Fri Nov 18 12:05:01 UTC 2011 TB --- 2011-11-18 12:05:01 - cd /src/sys/arm/conf TB --- 2011-11-18 12:05:01 - /usr/sbin/config -m CRB TB --- 2011-11-18 12:05:01 - building CRB kernel TB --- 2011-11-18 12:05:01 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 12:05:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 12:05:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 12:05:01 - SRCCONF=/dev/null TB --- 2011-11-18 12:05:01 - TARGET=arm TB --- 2011-11-18 12:05:01 - TARGET_ARCH=arm TB --- 2011-11-18 12:05:01 - TZ=UTC TB --- 2011-11-18 12:05:01 - __MAKE_CONF=/dev/null TB --- 2011-11-18 12:05:01 - cd /src TB --- 2011-11-18 12:05:01 - /usr/bin/make -B buildkernel KERNCONF=CRB >>> Kernel build for CRB started on Fri Nov 18 12:05:01 UTC 2011 >>> 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 >>> Kernel build for CRB completed on Fri Nov 18 12:08:23 UTC 2011 TB --- 2011-11-18 12:08:23 - cd /src/sys/arm/conf TB --- 2011-11-18 12:08:23 - /usr/sbin/config -m DB-78XXX TB --- 2011-11-18 12:08:23 - building DB-78XXX kernel TB --- 2011-11-18 12:08:23 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 12:08:23 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 12:08:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 12:08:23 - SRCCONF=/dev/null TB --- 2011-11-18 12:08:23 - TARGET=arm TB --- 2011-11-18 12:08:23 - TARGET_ARCH=arm TB --- 2011-11-18 12:08:23 - TZ=UTC TB --- 2011-11-18 12:08:23 - __MAKE_CONF=/dev/null TB --- 2011-11-18 12:08:23 - cd /src TB --- 2011-11-18 12:08:23 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Fri Nov 18 12:08:23 UTC 2011 >>> 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 >>> Kernel build for DB-78XXX completed on Fri Nov 18 12:11:01 UTC 2011 TB --- 2011-11-18 12:11:01 - cd /src/sys/arm/conf TB --- 2011-11-18 12:11:01 - /usr/sbin/config -m DB-88F5XXX TB --- 2011-11-18 12:11:01 - building DB-88F5XXX kernel TB --- 2011-11-18 12:11:01 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 12:11:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 12:11:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 12:11:01 - SRCCONF=/dev/null TB --- 2011-11-18 12:11:01 - TARGET=arm TB --- 2011-11-18 12:11:01 - TARGET_ARCH=arm TB --- 2011-11-18 12:11:01 - TZ=UTC TB --- 2011-11-18 12:11:01 - __MAKE_CONF=/dev/null TB --- 2011-11-18 12:11:01 - cd /src TB --- 2011-11-18 12:11:01 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Fri Nov 18 12:11:01 UTC 2011 >>> 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 >>> Kernel build for DB-88F5XXX completed on Fri Nov 18 12:13:38 UTC 2011 TB --- 2011-11-18 12:13:38 - cd /src/sys/arm/conf TB --- 2011-11-18 12:13:38 - /usr/sbin/config -m DB-88F6XXX TB --- 2011-11-18 12:13:39 - building DB-88F6XXX kernel TB --- 2011-11-18 12:13:39 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 12:13:39 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 12:13:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 12:13:39 - SRCCONF=/dev/null TB --- 2011-11-18 12:13:39 - TARGET=arm TB --- 2011-11-18 12:13:39 - TARGET_ARCH=arm TB --- 2011-11-18 12:13:39 - TZ=UTC TB --- 2011-11-18 12:13:39 - __MAKE_CONF=/dev/null TB --- 2011-11-18 12:13:39 - cd /src TB --- 2011-11-18 12:13:39 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Fri Nov 18 12:13:39 UTC 2011 >>> 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 >>> Kernel build for DB-88F6XXX completed on Fri Nov 18 12:16:19 UTC 2011 TB --- 2011-11-18 12:16:19 - cd /src/sys/arm/conf TB --- 2011-11-18 12:16:19 - /usr/sbin/config -m DOCKSTAR TB --- 2011-11-18 12:16:19 - building DOCKSTAR kernel TB --- 2011-11-18 12:16:19 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 12:16:19 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 12:16:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 12:16:19 - SRCCONF=/dev/null TB --- 2011-11-18 12:16:19 - TARGET=arm TB --- 2011-11-18 12:16:19 - TARGET_ARCH=arm TB --- 2011-11-18 12:16:19 - TZ=UTC TB --- 2011-11-18 12:16:19 - __MAKE_CONF=/dev/null TB --- 2011-11-18 12:16:19 - cd /src TB --- 2011-11-18 12:16:19 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Fri Nov 18 12:16:19 UTC 2011 >>> 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 >>> Kernel build for DOCKSTAR completed on Fri Nov 18 12:18:53 UTC 2011 TB --- 2011-11-18 12:18:53 - cd /src/sys/arm/conf TB --- 2011-11-18 12:18:53 - /usr/sbin/config -m EP80219 TB --- 2011-11-18 12:18:53 - building EP80219 kernel TB --- 2011-11-18 12:18:53 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 12:18:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 12:18:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 12:18:53 - SRCCONF=/dev/null TB --- 2011-11-18 12:18:53 - TARGET=arm TB --- 2011-11-18 12:18:53 - TARGET_ARCH=arm TB --- 2011-11-18 12:18:53 - TZ=UTC TB --- 2011-11-18 12:18:53 - __MAKE_CONF=/dev/null TB --- 2011-11-18 12:18:53 - cd /src TB --- 2011-11-18 12:18:53 - /usr/bin/make -B buildkernel KERNCONF=EP80219 >>> Kernel build for EP80219 started on Fri Nov 18 12:18:53 UTC 2011 >>> 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 >>> Kernel build for EP80219 completed on Fri Nov 18 12:21:45 UTC 2011 TB --- 2011-11-18 12:21:45 - WARNING: no kernel config for GENERIC TB --- 2011-11-18 12:21:45 - cd /src/sys/arm/conf TB --- 2011-11-18 12:21:45 - /usr/sbin/config -m GUMSTIX TB --- 2011-11-18 12:21:45 - building GUMSTIX kernel TB --- 2011-11-18 12:21:45 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 12:21:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 12:21:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 12:21:45 - SRCCONF=/dev/null TB --- 2011-11-18 12:21:45 - TARGET=arm TB --- 2011-11-18 12:21:45 - TARGET_ARCH=arm TB --- 2011-11-18 12:21:45 - TZ=UTC TB --- 2011-11-18 12:21:45 - __MAKE_CONF=/dev/null TB --- 2011-11-18 12:21:45 - cd /src TB --- 2011-11-18 12:21:45 - /usr/bin/make -B buildkernel KERNCONF=GUMSTIX >>> Kernel build for GUMSTIX started on Fri Nov 18 12:21:45 UTC 2011 >>> 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 >>> Kernel build for GUMSTIX completed on Fri Nov 18 12:24:03 UTC 2011 TB --- 2011-11-18 12:24:03 - cd /src/sys/arm/conf TB --- 2011-11-18 12:24:03 - /usr/sbin/config -m HL200 TB --- 2011-11-18 12:24:03 - building HL200 kernel TB --- 2011-11-18 12:24:03 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 12:24:03 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 12:24:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 12:24:03 - SRCCONF=/dev/null TB --- 2011-11-18 12:24:03 - TARGET=arm TB --- 2011-11-18 12:24:03 - TARGET_ARCH=arm TB --- 2011-11-18 12:24:03 - TZ=UTC TB --- 2011-11-18 12:24:03 - __MAKE_CONF=/dev/null TB --- 2011-11-18 12:24:03 - cd /src TB --- 2011-11-18 12:24:03 - /usr/bin/make -B buildkernel KERNCONF=HL200 >>> Kernel build for HL200 started on Fri Nov 18 12:24:03 UTC 2011 >>> 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 >>> Kernel build for HL200 completed on Fri Nov 18 12:26:41 UTC 2011 TB --- 2011-11-18 12:26:41 - cd /src/sys/arm/conf TB --- 2011-11-18 12:26:41 - /usr/sbin/config -m HL201 TB --- 2011-11-18 12:26:41 - building HL201 kernel TB --- 2011-11-18 12:26:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 12:26:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 12:26:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 12:26:41 - SRCCONF=/dev/null TB --- 2011-11-18 12:26:41 - TARGET=arm TB --- 2011-11-18 12:26:41 - TARGET_ARCH=arm TB --- 2011-11-18 12:26:41 - TZ=UTC TB --- 2011-11-18 12:26:41 - __MAKE_CONF=/dev/null TB --- 2011-11-18 12:26:41 - cd /src TB --- 2011-11-18 12:26:41 - /usr/bin/make -B buildkernel KERNCONF=HL201 >>> Kernel build for HL201 started on Fri Nov 18 12:26:41 UTC 2011 >>> 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 >>> Kernel build for HL201 completed on Fri Nov 18 12:28:58 UTC 2011 TB --- 2011-11-18 12:28:58 - cd /src/sys/arm/conf TB --- 2011-11-18 12:28:58 - /usr/sbin/config -m IQ31244 TB --- 2011-11-18 12:28:59 - building IQ31244 kernel TB --- 2011-11-18 12:28:59 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 12:28:59 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 12:28:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 12:28:59 - SRCCONF=/dev/null TB --- 2011-11-18 12:28:59 - TARGET=arm TB --- 2011-11-18 12:28:59 - TARGET_ARCH=arm TB --- 2011-11-18 12:28:59 - TZ=UTC TB --- 2011-11-18 12:28:59 - __MAKE_CONF=/dev/null TB --- 2011-11-18 12:28:59 - cd /src TB --- 2011-11-18 12:28:59 - /usr/bin/make -B buildkernel KERNCONF=IQ31244 >>> Kernel build for IQ31244 started on Fri Nov 18 12:28:59 UTC 2011 >>> 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 >>> Kernel build for IQ31244 completed on Fri Nov 18 12:32:16 UTC 2011 TB --- 2011-11-18 12:32:16 - cd /src/sys/arm/conf TB --- 2011-11-18 12:32:16 - /usr/sbin/config -m KB920X TB --- 2011-11-18 12:32:16 - building KB920X kernel TB --- 2011-11-18 12:32:16 - CROSS_BUILD_TESTING=YES TB --- 2011-11-18 12:32:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-18 12:32:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-18 12:32:16 - SRCCONF=/dev/null TB --- 2011-11-18 12:32:16 - TARGET=arm TB --- 2011-11-18 12:32:16 - TARGET_ARCH=arm TB --- 2011-11-18 12:32:16 - TZ=UTC TB --- 2011-11-18 12:32:16 - __MAKE_CONF=/dev/null TB --- 2011-11-18 12:32:16 - cd /src TB --- 2011-11-18 12:32:16 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>> Kernel build for KB920X started on Fri Nov 18 12:32:16 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_mcdi.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_port.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_rx.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -DDEBUG=1 -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge_tx.c cc1: warnings being treated as errors /src/sys/modules/sfxge/../../dev/sfxge/sfxge_tx.c: In function 'sfxge_tx_qdpl_swizzle': /src/sys/modules/sfxge/../../dev/sfxge/sfxge_tx.c:138: warning: implicit declaration of function 'atomic_readandclear_ptr' /src/sys/modules/sfxge/../../dev/sfxge/sfxge_tx.c:138: warning: nested extern declaration of 'atomic_readandclear_ptr' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/sfxge. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/KB920X. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-18 12:41:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-18 12:41:11 - ERROR: failed to build KB920X kernel TB --- 2011-11-18 12:41:11 - 4489.87 user 1127.65 system 6070.23 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 13:14:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BEC9106566C for ; Fri, 18 Nov 2011 13:14:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 021088FC0A for ; Fri, 18 Nov 2011 13:14:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id AC9A346B23; Fri, 18 Nov 2011 08:14:44 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 54BE08A052; Fri, 18 Nov 2011 08:14:44 -0500 (EST) From: John Baldwin To: Matteo Landi Date: Fri, 18 Nov 2011 08:00:06 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201111170953.58151.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111180800.06593.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 18 Nov 2011 08:14:44 -0500 (EST) Cc: freebsd-current@freebsd.org Subject: Re: ixgbe and fast interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 13:14:45 -0000 On Friday, November 18, 2011 3:46:02 am Matteo Landi wrote: > > you probably want to be using MSI-X for a 10G NIC instead of INTx anyway. > > Why do you say that? Is MSI-X faster than INTx in terms of interrupt > latency? When should I use MSI-X, instead of fast filters interrupts > (fast interrupt?), instead of ithread interrupts? Thanks in advace. With MSI-X you can have more than one interrupt and those interrupts can be distributed across CPUs. This means you can (somewhat) tie each queue on your NIC to a different CPU. MSI-X vs INTx is orthogonal to fast vs filter, but in general MSI and MSI-X interrupts are not shared, and require no interrupt masking in hardware (they are effectively edge-triggered), so using a filter for MSI is rather pointless and only adds needless complexity. For MSI I would just use a theraded interrupt handler. For INTx, I would only use a fast interrupt handler if there is a really good reason to do so (e.g. em(4) does so to work around broken Intel Host-PCI bridges). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 13:51:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F303106566B; Fri, 18 Nov 2011 13:51:31 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7179D8FC08; Fri, 18 Nov 2011 13:51:30 +0000 (UTC) Received: by eyd10 with SMTP id 10so4742922eyd.13 for ; Fri, 18 Nov 2011 05:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Thoi2ZrHlQGgs2CJ4fusDoGwpaAS1ht7IZtaOttUUuI=; b=qgFg5/ByLgpq/xXdN3qz4g28W+mDfYCeTBdGzyg1+1sRl4yCXSwnGU8XUFy09aKYC2 eNAUrk2wPBtkIsq8XUUmzkdG/jrVD/6cl5SFr8uVz8fPuc+VLe46ZCfcP2tmcstOn0lW TBZFQKtFflqSfghHDfOSY1ZHBLq7Czw5aUCQw= MIME-Version: 1.0 Received: by 10.180.109.106 with SMTP id hr10mr4277431wib.9.1321624289015; Fri, 18 Nov 2011 05:51:29 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.85.8 with HTTP; Fri, 18 Nov 2011 05:51:28 -0800 (PST) In-Reply-To: References: <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> <20111107193516.GA50300@deviant.kiev.zoral.com.ua> <20111116084542.GY50300@deviant.kiev.zoral.com.ua> <20111118105224.GB50300@deviant.kiev.zoral.com.ua> Date: Fri, 18 Nov 2011 14:51:28 +0100 X-Google-Sender-Auth: rNJ_m3f2i2bLYkDrt9AI_g3It_k Message-ID: From: Attilio Rao To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mdf@freebsd.org, "K. Macy" , Alan Cox , Andriy Gapon , freebsd-current@freebsd.org, Benjamin Kaduk , Penta Upa Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 13:51:31 -0000 2011/11/18 Attilio Rao : > 2011/11/18 Kostik Belousov : >> On Fri, Nov 18, 2011 at 11:40:28AM +0100, Attilio Rao wrote: >>> 2011/11/16 Kostik Belousov : >>> > On Tue, Nov 15, 2011 at 07:15:01PM +0100, Attilio Rao wrote: >>> >> 2011/11/7 Kostik Belousov : >>> >> > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: >>> >> >> Ok. =C2=A0I'll offer one final suggestion. =C2=A0Please consider = an alternative >>> >> >> suffix to "func". =C2=A0Perhaps, "kbi" or "KBI". =C2=A0In other w= ords, something >>> >> >> that hints at the function's reason for existing. >>> >> > >>> >> > Sure. Below is the extraction of only vm_page_lock() bits, togethe= r >>> >> > with the suggested rename. When Attilio provides the promised simp= lification >>> >> > of the mutex KPI, this can be reduced. >>> >> >>> >> My tentative patch is here: >>> >> http://www.freebsd.org/~attilio/mutexfileline.patch >>> >> >>> >> I need to make more compile testing later, but it already compiles >>> >> GENERIC + modules fine on HEAD. >>> >> >>> >> The patch provides a common entrypoint, option independent, for both >>> >> fast case and debug/compat case. >>> >> Additively, it almost entirely fixes the standard violation of the >>> >> reserved namespace, as you described (the notable exception being th= e >>> >> macro used in the fast path, that I want to fix as well, but in a >>> >> separate commit). >>> >> >>> >> Now the file/line couplet can be passed to the "_" suffix variant of >>> >> the flag functions. >>> > Yes, this is exactly KPI that I would use when available for the >>> > vm_page_lock() patch. >>> > >>> >> >>> >> eadler@ reviewed the mutex.h comment. >>> >> >>> >> Please let me know what you think about it, as long as we agree on t= he >>> >> patch I'll commit it. >>> > But I also agree with John that imposing large churn due to the elimi= nation >>> > of the '__' prefix is too late now. At least it will make the change >>> > non-MFCable. Besides, we already lived with the names for 10+ years. >>> > >>> > I will be happy to have the part of the patch that exports the mtx_XX= X_(mtx, >>> > file, line) defines which can be used without taking care of LOCK_DEB= UG >>> > or MUTEX_NOINLINE in the consumer code. >>> >>> Ok, this patch should just add the compat stub: >>> http://www.freebsd.org/~attilio/mutexfileline2.patch >> Am I right that I would use mtx_lock_(mtx, file, line) etc ? >> If yes, I am fine with it. > > Yes that is correct. > > However, I'm a bit confused on one aspect: would you mind using > _mtx_lock_flags() instead? > If you don't mind the "underscore namespace violation" I think I can > make a much smaller patch against HEAD for it. > > Otherwise, the one now posted should be ok. After thinking more about it, I think that is basically the shorter version I can came up with. Please consider: http://www.freebsd.org/~attilio/mutexfileline2.patch as a possible commit candidate for me. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 16:21:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 209A0106566C for ; Fri, 18 Nov 2011 16:21:51 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id DFF018FC0A for ; Fri, 18 Nov 2011 16:21:50 +0000 (UTC) Received: by iakl21 with SMTP id l21so5620926iak.13 for ; Fri, 18 Nov 2011 08:21:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XMkdb6rR2s/xbHgRkO6QgsKfWoGzq4WRmXhqsJjMPzw=; b=rii1BlStihi90eFxbLu0oT+qLxNuvDBB0ve7jKqd7pZ3xGgrmdBg6o9mgXbx36MCp1 UeqOc6yYLJquBiBCM5MrkS3F6XWO9dOfGf4f332RUV+LGGb5lb/0b+lKbnmZHQnI+Uya JYjQSYenbER2ZYNHwr2WDY/n5xCQD2U7MWTSQ= MIME-Version: 1.0 Received: by 10.231.50.202 with SMTP id a10mr872295ibg.39.1321633310303; Fri, 18 Nov 2011 08:21:50 -0800 (PST) Received: by 10.231.15.7 with HTTP; Fri, 18 Nov 2011 08:21:50 -0800 (PST) In-Reply-To: <4EC6431F.7000806@gmail.com> References: <1321553970.82271.66.camel@bauer.cse.buffalo.edu> <20111118105339.1CE9D1065688@hub.freebsd.org> <4EC6431F.7000806@gmail.com> Date: Fri, 18 Nov 2011 18:21:50 +0200 Message-ID: From: George Kontostanos To: "Luchesar V. ILIEV" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Mueller , freebsd-current@freebsd.org, Ken Smith Subject: Re: FreeBSD 9.0-RC2 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 16:21:51 -0000 On Fri, Nov 18, 2011 at 1:35 PM, Luchesar V. ILIEV wrote: > On 18/11/2011 12:53, Thomas Mueller wrote: >>> If you would like to use csup/cvsup mechanisms to access the source >>> tree the branch tag to use is now "RELENG_9_0", if you use "." (head) >>> you will get 10-CURRENT. =A0If you would like to access the source tree >>> via SVN it is "svn://svn.freebsd.org/base/releng/9.0/". =A0We still hav= e >>> the nit that the creation of a new SVN branch winds up causing what >>> looks like a check-in of the entire tree in CVS (a side-effect of the >>> svn2cvs exporter) so "mergemaster -F" is your friend if you are using >>> csup/cvsup. >> >> About a couple days before seeing this message, or the message on the Fr= eeBSD web site, but after seeing RC2 on the ftp.freebsd.org server, >> I already ran csup with >> >> *default release=3Dcvs tag=3DRELENG_9 >> >> Am I screwed, am I OK, or do I simply have to rerun csup with RELENG_9_0= instead of RELENG_9 ? > > RELENG_9 (cvs) =3D stable/9 (svn) =3D 9.N-STABLE (newvers.sh, `uname -r`) > RELENG_9_0 (cvs) =3D releng/9.0 (svn) =3D 9.0-RELEASE (newvers.sh, uname) > > In short, if you want to use the 9.0-RELEASE (when it finally gets > ready), then you need to switch to RELENG_9_0. If you prefer using > -STABLE for your systems, then you're OK with RELENG_9. > > In case you don't know or are not quite sure about the differences > between -RELEASE and -STABLE, I'd recommend switching to RELENG_9_0. > >> Again, I can't find that file (needle in the haystack) in /usr/src tree = that shows version number such as RC2. > > This has already been answered, but just a quick note. If you've > recently updated your sources using the RELENG_9 tag, you'll most likely > see the version in newvers.sh as: > > REVISION=3D"9.0" > BRANCH=3D"PRERELEASE" > > If you switch to RELENG_9_0 and update your sources again, you should > see the familiar: > > REVISION=3D"9.0" > BRANCH=3D"RC2" > > HTH, > Luchesar > > -- > i.dea.is/luchesar > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > Correct me if I am wrong but up until 9.0 is released there isn't any practical difference between RELENG_9 & RELENG_9_0 --=20 George Kontostanos Aicom telecoms ltd http://www.barebsd.com From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 17:07:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C8BC1065670; Fri, 18 Nov 2011 17:07:51 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 4AC7E8FC15; Fri, 18 Nov 2011 17:07:51 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 73A747300A; Fri, 18 Nov 2011 18:06:15 +0100 (CET) Date: Fri, 18 Nov 2011 18:06:15 +0100 From: Luigi Rizzo To: John Baldwin Message-ID: <20111118170615.GA9762@onelab2.iet.unipi.it> References: <201111170953.58151.jhb@freebsd.org> <201111180800.06593.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111180800.06593.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Matteo Landi , freebsd-current@freebsd.org Subject: Re: ixgbe and fast interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 17:07:51 -0000 On Fri, Nov 18, 2011 at 08:00:06AM -0500, John Baldwin wrote: > On Friday, November 18, 2011 3:46:02 am Matteo Landi wrote: > > > you probably want to be using MSI-X for a 10G NIC instead of INTx anyway. > > > > Why do you say that? Is MSI-X faster than INTx in terms of interrupt > > latency? When should I use MSI-X, instead of fast filters interrupts > > (fast interrupt?), instead of ithread interrupts? Thanks in advace. > > With MSI-X you can have more than one interrupt and those interrupts can be > distributed across CPUs. This means you can (somewhat) tie each queue on your > NIC to a different CPU. > > MSI-X vs INTx is orthogonal to fast vs filter, but in general MSI and MSI-X > interrupts are not shared, and require no interrupt masking in hardware (they > are effectively edge-triggered), so using a filter for MSI is rather pointless > and only adds needless complexity. For MSI I would just use a theraded > interrupt handler. For INTx, I would only use a fast interrupt handler if > there is a really good reason to do so (e.g. em(4) does so to work around > broken Intel Host-PCI bridges). A bit more context: Matteo is looking at the latency of RPCs across the network involving userspace processes, and possibly using the netmap API. As we understand it: if you are not using a filter, the interrupt calls a "predefined" filter (kern_intr.c::intr_event_schedule_thread() ? ) which wakes up the handler thread which in turn wakes up the user process. This means two scheduler invocations on each side. In the case of netmap, all the handler needs to do is a selwakeup() of the user thread blocked on the file descriptor, so if this can be done in the filter we can save an extra step through the scheduler. cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 17:15:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA255106566C; Fri, 18 Nov 2011 17:15:54 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE7C8FC15; Fri, 18 Nov 2011 17:15:54 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so518146vbb.13 for ; Fri, 18 Nov 2011 09:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=xNbtsJiw94fYeLw3F9lSRqFMe9XCIsmIn/DtdUU1f3M=; b=Edca7CEj5DoOxVBYSV5m5ioHT3ZsFjmSeoWKFgdOtMwbjfJTspau2ggWRE+XHJW7dT d447X7JfjWh0FkqVLIGj6eTptNK8yyinqvPDJt9rWR8A/YC6KPeL0UEo16f0YMGYj/HD C9yKy+RqNwn5cyP55DIP7qN7Yzk6KubaWA4e0= MIME-Version: 1.0 Received: by 10.52.65.77 with SMTP id v13mr4195166vds.95.1321634900786; Fri, 18 Nov 2011 08:48:20 -0800 (PST) Received: by 10.52.101.132 with HTTP; Fri, 18 Nov 2011 08:48:20 -0800 (PST) Date: Fri, 18 Nov 2011 16:48:20 +0000 Message-ID: From: "Paul B. Mahol" To: FreeBSD-Current , FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Reprobing of devices after module load? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 17:15:54 -0000 Hi, Is there nice way in FreeBSD to force reprobe of devices for specific driver like it is done when kernel module is loaded (via DRIVER_MODULE(...) stuff)? From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 17:20:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BC30106564A for ; Fri, 18 Nov 2011 17:20:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F10F38FC1F for ; Fri, 18 Nov 2011 17:20:05 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A8C6846B0D; Fri, 18 Nov 2011 12:20:05 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3F1F88A050; Fri, 18 Nov 2011 12:20:05 -0500 (EST) From: John Baldwin To: Luigi Rizzo Date: Fri, 18 Nov 2011 12:20:04 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <201111180800.06593.jhb@freebsd.org> <20111118170615.GA9762@onelab2.iet.unipi.it> In-Reply-To: <20111118170615.GA9762@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111181220.04846.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 18 Nov 2011 12:20:05 -0500 (EST) Cc: Matteo Landi , freebsd-current@freebsd.org Subject: Re: ixgbe and fast interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 17:20:06 -0000 On Friday, November 18, 2011 12:06:15 pm Luigi Rizzo wrote: > On Fri, Nov 18, 2011 at 08:00:06AM -0500, John Baldwin wrote: > > On Friday, November 18, 2011 3:46:02 am Matteo Landi wrote: > > > > you probably want to be using MSI-X for a 10G NIC instead of INTx anyway. > > > > > > Why do you say that? Is MSI-X faster than INTx in terms of interrupt > > > latency? When should I use MSI-X, instead of fast filters interrupts > > > (fast interrupt?), instead of ithread interrupts? Thanks in advace. > > > > With MSI-X you can have more than one interrupt and those interrupts can be > > distributed across CPUs. This means you can (somewhat) tie each queue on your > > NIC to a different CPU. > > > > MSI-X vs INTx is orthogonal to fast vs filter, but in general MSI and MSI-X > > interrupts are not shared, and require no interrupt masking in hardware (they > > are effectively edge-triggered), so using a filter for MSI is rather pointless > > and only adds needless complexity. For MSI I would just use a theraded > > interrupt handler. For INTx, I would only use a fast interrupt handler if > > there is a really good reason to do so (e.g. em(4) does so to work around > > broken Intel Host-PCI bridges). > > A bit more context: Matteo is looking at the latency of RPCs across > the network involving userspace processes, and possibly using the > netmap API. As we understand it: > > if you are not using a filter, the interrupt calls a "predefined" > filter (kern_intr.c::intr_event_schedule_thread() ? ) which wakes > up the handler thread which in turn wakes up the user process. This > means two scheduler invocations on each side. Yes, but if you use a filter you still have to do that as your filter would just be queueing a task to on a taskqueue which would then do the actual selwakeup() from a taskqueue thread. Filters are typically used to avoid masking the interrupt in the PIC, or to limit the handlers executed on a shared interrupt. > In the case of netmap, all the handler needs to do is a selwakeup() > of the user thread blocked on the file descriptor, so if this > can be done in the filter we can save an extra step through the > scheduler. You can't call selwakeup() from a filter, it is not safe since it uses mutexes, etc. There are only a few things you can do from a filter. You could do a plain wakeup() if you let userland use a custom ioctl to block on the filter, but not selwakeup(). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 17:38:40 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E5E9106564A for ; Fri, 18 Nov 2011 17:38:40 +0000 (UTC) (envelope-from luchesar.iliev@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 202C98FC08 for ; Fri, 18 Nov 2011 17:38:39 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so5012284bkb.13 for ; Fri, 18 Nov 2011 09:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=gnvnVTczVmrDLhihdX0VlpGdZ1hT5whuWbMrQg+LCew=; b=QWGZd+Wln6YQLb570ZfEQUROfwAM5iT1XjGB3xqKfAlloMB99OnQ28lNko8MyT4DjL neTnoW+Hpn/I4rrTlKnuYdY0d1uK/Gg/dPlEajf3GEdbBGwfucm5YWYp9si6uN8Xwr22 Dpr4avLtrAFZtRvVAsuumuEgIzx6YkaQoNbK8= Received: by 10.204.156.141 with SMTP id x13mr4402620bkw.54.1321637917941; Fri, 18 Nov 2011 09:38:37 -0800 (PST) Received: from [79.124.93.41] ([79.124.93.41]) by mx.google.com with ESMTPS id a21sm5943477fao.18.2011.11.18.09.38.36 (version=SSLv3 cipher=OTHER); Fri, 18 Nov 2011 09:38:36 -0800 (PST) Message-ID: <4EC6981B.3060507@gmail.com> Date: Fri, 18 Nov 2011 19:38:35 +0200 From: "Luchesar V. ILIEV" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: George Kontostanos References: <1321553970.82271.66.camel@bauer.cse.buffalo.edu> <20111118105339.1CE9D1065688@hub.freebsd.org> <4EC6431F.7000806@gmail.com> In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=9A1FEEFF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Mueller , freebsd-current@freebsd.org, Ken Smith Subject: Re: FreeBSD 9.0-RC2 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 17:38:40 -0000 On 18/11/2011 18:21, George Kontostanos wrote: > On Fri, Nov 18, 2011 at 1:35 PM, Luchesar V. ILIEV > wrote: >> On 18/11/2011 12:53, Thomas Mueller wrote: >>>> If you would like to use csup/cvsup mechanisms to access the source >>>> tree the branch tag to use is now "RELENG_9_0", if you use "." (head) >>>> you will get 10-CURRENT. If you would like to access the source tree >>>> via SVN it is "svn://svn.freebsd.org/base/releng/9.0/". We still have >>>> the nit that the creation of a new SVN branch winds up causing what >>>> looks like a check-in of the entire tree in CVS (a side-effect of the >>>> svn2cvs exporter) so "mergemaster -F" is your friend if you are using >>>> csup/cvsup. >>> >>> About a couple days before seeing this message, or the message on the FreeBSD web site, but after seeing RC2 on the ftp.freebsd.org server, >>> I already ran csup with >>> >>> *default release=cvs tag=RELENG_9 >>> >>> Am I screwed, am I OK, or do I simply have to rerun csup with RELENG_9_0 instead of RELENG_9 ? >> >> RELENG_9 (cvs) = stable/9 (svn) = 9.N-STABLE (newvers.sh, `uname -r`) >> RELENG_9_0 (cvs) = releng/9.0 (svn) = 9.0-RELEASE (newvers.sh, uname) >> >> In short, if you want to use the 9.0-RELEASE (when it finally gets >> ready), then you need to switch to RELENG_9_0. If you prefer using >> -STABLE for your systems, then you're OK with RELENG_9. >> >> In case you don't know or are not quite sure about the differences >> between -RELEASE and -STABLE, I'd recommend switching to RELENG_9_0. >> >>> Again, I can't find that file (needle in the haystack) in /usr/src tree that shows version number such as RC2. >> >> This has already been answered, but just a quick note. If you've >> recently updated your sources using the RELENG_9 tag, you'll most likely >> see the version in newvers.sh as: >> >> REVISION="9.0" >> BRANCH="PRERELEASE" >> >> If you switch to RELENG_9_0 and update your sources again, you should >> see the familiar: >> >> REVISION="9.0" >> BRANCH="RC2" >> >> HTH, >> Luchesar >> >> -- >> i.dea.is/luchesar >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > Correct me if I am wrong but up until 9.0 is released there isn't any > practical difference between RELENG_9 & RELENG_9_0 Yes, but it's never a nice feeling to realize you've taken the wrong train only when you see it going not quite your way, isn't it? ;) Cheers, Luchesar From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 17:38:54 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62FF2106564A; Fri, 18 Nov 2011 17:38:54 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 213778FC16; Fri, 18 Nov 2011 17:38:53 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 7A4AD7300A; Fri, 18 Nov 2011 18:54:33 +0100 (CET) Date: Fri, 18 Nov 2011 18:54:33 +0100 From: Luigi Rizzo To: John Baldwin Message-ID: <20111118175433.GA13459@onelab2.iet.unipi.it> References: <201111180800.06593.jhb@freebsd.org> <20111118170615.GA9762@onelab2.iet.unipi.it> <201111181220.04846.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111181220.04846.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Matteo Landi , freebsd-current@freebsd.org Subject: Re: ixgbe and fast interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 17:38:54 -0000 On Fri, Nov 18, 2011 at 12:20:04PM -0500, John Baldwin wrote: > On Friday, November 18, 2011 12:06:15 pm Luigi Rizzo wrote: ... > > A bit more context: Matteo is looking at the latency of RPCs across > > the network involving userspace processes, and possibly using the > > netmap API. As we understand it: > > > > if you are not using a filter, the interrupt calls a "predefined" > > filter (kern_intr.c::intr_event_schedule_thread() ? ) which wakes > > up the handler thread which in turn wakes up the user process. This > > means two scheduler invocations on each side. > > Yes, but if you use a filter you still have to do that as your filter would > just be queueing a task to on a taskqueue which would then do the actual > selwakeup() from a taskqueue thread. Filters are typically used to avoid > masking the interrupt in the PIC, or to limit the handlers executed on a > shared interrupt. > > > In the case of netmap, all the handler needs to do is a selwakeup() > > of the user thread blocked on the file descriptor, so if this > > can be done in the filter we can save an extra step through the > > scheduler. > > You can't call selwakeup() from a filter, it is not safe since it uses > mutexes, etc. There are only a few things you can do from a filter. > You could do a plain wakeup() if you let userland use a custom ioctl to > block on the filter, but not selwakeup(). ok, this is good to know - i wasn't sure if selwakeup() could block (and i am a bit unclear why). Will look at the selrecord/selwakeup pair, thanks for the suggestion. One more thing (i am mentioning it here for archival purposes, as i keep forgetting to test it). Is entropy harvesting expensive ? I see it is on by default > sysctl -a | grep rando kern.randompid: 0 kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 192 kern.random.yarrow.slowthresh: 256 kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 0 ... and there seems to be a call to random_harvest() in the default filter that wakes up the threaded handler. cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 19:16:01 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 553F5106564A; Fri, 18 Nov 2011 19:16:01 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 02AED157E72; Fri, 18 Nov 2011 19:16:00 +0000 (UTC) Message-ID: <4EC6AEF0.1010402@FreeBSD.org> Date: Fri, 18 Nov 2011 11:16:00 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Luigi Rizzo References: <201111180800.06593.jhb@freebsd.org> <20111118170615.GA9762@onelab2.iet.unipi.it> <201111181220.04846.jhb@freebsd.org> <20111118175433.GA13459@onelab2.iet.unipi.it> In-Reply-To: <20111118175433.GA13459@onelab2.iet.unipi.it> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Matteo Landi , freebsd-current@freebsd.org Subject: Re: ixgbe and fast interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 19:16:01 -0000 On 11/18/2011 09:54, Luigi Rizzo wrote: > One more thing (i am mentioning it here for archival purposes, > as i keep forgetting to test it). Is entropy harvesting expensive ? No. It was designed to be inexpensive on purpose. :) -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 21:49:19 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 305A4106566C; Fri, 18 Nov 2011 21:49:19 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id DFB848FC14; Fri, 18 Nov 2011 21:49:18 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 1DE5D7300A; Fri, 18 Nov 2011 23:04:58 +0100 (CET) Date: Fri, 18 Nov 2011 23:04:58 +0100 From: Luigi Rizzo To: Doug Barton Message-ID: <20111118220458.GA21152@onelab2.iet.unipi.it> References: <201111180800.06593.jhb@freebsd.org> <20111118170615.GA9762@onelab2.iet.unipi.it> <201111181220.04846.jhb@freebsd.org> <20111118175433.GA13459@onelab2.iet.unipi.it> <4EC6AEF0.1010402@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC6AEF0.1010402@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Matteo Landi , freebsd-current@freebsd.org Subject: Re: ixgbe and fast interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 21:49:19 -0000 On Fri, Nov 18, 2011 at 11:16:00AM -0800, Doug Barton wrote: > On 11/18/2011 09:54, Luigi Rizzo wrote: > > One more thing (i am mentioning it here for archival purposes, > > as i keep forgetting to test it). Is entropy harvesting expensive ? > > No. It was designed to be inexpensive on purpose. :) hmmm.... unfortunately I don't have a chance to test it until monday (probably one could see if the ping times change by modifying the value of kern.random.sys.harvest.* ). But in the code i see the following: - the harvest routine is this: void random_harvest(void *entropy, u_int count, u_int bits, u_int frac, enum esource origin) { if (reap_func) (*reap_func)(get_cyclecount(), entropy, count, bits, frac, origin); } - the reap_func seems to be bound to dev/random/randomdev_soft.c::random_harvest_internal() which internally uses a spinlock and then moves entries between two lists. I am concerned that the get_cyclecount() might end up querying an expensive device (is it using kern.timecounter.hardware ?) > sysctl -a | grep timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast So between the indirect function call, spinlock, list manipulation and the cyclecounter i wouldn't be surprised it the whole thing takes a microsecond or so. Anyways, on monday i'll know better. in the meantime, if someone wants to give it a try... in our tests between two machines and ixgbe (10G) interfaces, an unmodified 9.0 kernel has a median ping time of 30us with "slow" pings (say -i 0.01 or larger) and 17us with a ping -f . BTW the reason for the difference is totally unclear to me (ping -f uses a non-blocking select() but i don't think it can explain such a large delta). cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 21:59:38 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EBFC106564A; Fri, 18 Nov 2011 21:59:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 16DA88FC08; Fri, 18 Nov 2011 21:59:36 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA14238; Fri, 18 Nov 2011 23:59:34 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RRWT8-000FOG-Fn; Fri, 18 Nov 2011 23:59:34 +0200 Message-ID: <4EC6D544.5040803@FreeBSD.org> Date: Fri, 18 Nov 2011 23:59:32 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: John Baldwin References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <4EC563BB.60209@FreeBSD.org> <201111171635.07278.jhb@freebsd.org> <201111171638.03208.jhb@freebsd.org> In-Reply-To: <201111171638.03208.jhb@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Alexander Motin , freebsd-current@FreeBSD.org Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 21:59:38 -0000 on 17/11/2011 23:38 John Baldwin said the following: > On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote: >> Hmmm, you could also make critical_exit() not perform deferred preemptions >> if SCHEDULER_STOPPED? That would fix the recursion and still let the >> preemption "work" when resuming from the debugger? Yes, that's a good solution, I think. I just didn't want to touch such a "low level" code, but I guess there is no rational reason for that. > Or you could let the debugger run in a permament critical section (though > perhaps that breaks too many other things like debugger routines that try > to use locks like the 'kill' command (which is useful!)). Effectively what you > are trying to do is having the debugger run in a critical section until the > debugger is exited. It would be cleanest to let it run that way explicitly > if possible since then you don't have to catch as many edge cases. I like this idea, but likely it would take some effort to get done. Related to this is something that I attempted to discuss before. I think that because the debugger acts on a frozen system image (the debugger is a sole actor and observer), the debugger should try to minimize its interaction with the debugged system. In this vein I think that the debugger should also bypass any locks just like with SCHEDULER_STOPPED. The debugger should also be careful to note a state of any subsystems that it uses (e.g. the keyboard) and return them to the initial state if it had to be changed. But that's a bit different story. And I really get beyond my knowledge zone when I try to think about things like handling 'call func_xxxx' in the debugger where func_xxxx may want to acquire some locks or noticeably change some state within a system. But to continue about the locks... I have this idea to re-implement SCHEDULER_STOPPED as some more general check that could be abstractly denoted as LOCKING_POLICY_CHECK(context). Where the context could be defined by flags like normal, in-panic, in-debugger, etc. And the locking policies could be: normal, bypass, warn, panic, etc. However, I am not sure if this could be useful (and doable properly) in practice. I am just concerned with the interaction between the debugger and the locks. It still seems to me inconsistent that we are going with SCHEDULER_STOPPED for panic, but we are continuing to use "if (!kdb_active)" around some locks that could be problematic under kdb (e.g. in USB). In my opinion the amount of code shared between normal context and kdb context is about the same as amount of code shared between normal context and panic context. But I haven't really quantified those. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 23:33:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35A9F1065672 for ; Fri, 18 Nov 2011 23:33:46 +0000 (UTC) (envelope-from nevtic@tx.net) Received: from area51.tx.net (area51.tx.net [141.198.160.99]) by mx1.freebsd.org (Postfix) with ESMTP id E18318FC14 for ; Fri, 18 Nov 2011 23:33:45 +0000 (UTC) Received: from area51.tx.net (localhost [127.0.0.1]) by area51.tx.net (8.14.4/8.14.4) with ESMTP id pAIN9l1l007602 for ; Fri, 18 Nov 2011 17:09:47 -0600 (CST) (envelope-from nevtic@area51.capnet.state.tx.us) Received: from localhost (stu@localhost) by area51.tx.net (8.14.4/8.14.4/Submit) with ESMTP id pAIN9lxk007599 for ; Fri, 18 Nov 2011 17:09:47 -0600 (CST) (envelope-from nevtic@area51.capnet.state.tx.us) Date: Fri, 18 Nov 2011 17:09:47 -0600 (CST) From: nevtic@tx.net To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Mailman-Approved-At: Sat, 19 Nov 2011 00:42:31 +0000 Subject: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nevtic@tx.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 23:33:46 -0000 If you are performating a manual partion in 9.0-RC2 bsdinstall and you delete any created partition except the most recently created one, the total remaining space will be miscalculated. Reproducable as shown below. Workaround: if you delete a partition that is not the last partition that was created, delete all partitions created after that partition before continuing. Order does not seem to be important. The results are similar with other hard drive sizes, with the i386 or amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go back and check install discs prior to RC1) Reproducing the miscount: A 114 GB drive is used for this example: Select Manual Partitioning Perform the first Create on the drive and select GPT Creating the first partition: "Add Partition" "size" shows 114GB Change size to 4GB, set mountpoint to / and tab to OK (agree to the boot partition creation) Create a second partition: "Add Partition" "size" shows 110GB Adjust size to 10GB, set mountpoint to /usr and tab to OK Create a third partition: "Add Partition" "size" shows 100GB Adjust size to 20GB, set mountpoint to /var, and tab to OK Create a 4th partition: "size" shows 80GB remaining Adjust size to 40GB, set mountpoint to /data, and tab to OK. There is 40 GB remaining on the drive. Now change the size of /var. First, delete the currently configured /var partition. In the Partition Editor, adding up all the lines on the screen shows 54GB (plus a 64K boot) as allocated, so there should now be 60GB remaining. But the deleted /var space has not been added back into the total. Select Create again: "Add Partition" "size" shows 40GB Adjust size to 30GB, set mountpoint as /var, tab to OK A subsequent "Create" will show that 20GB is remaining, rather than the actual remaining 30GB. Selecting any size 20GB or larger for /home will give you a 20GB partition, and then an additional create will show the 10GB. From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 01:01:05 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C5D9106564A; Sat, 19 Nov 2011 01:01:05 +0000 (UTC) (envelope-from rcm@fuzzwad.org) Received: from mail.volente.us (unknown [IPv6:2001:470:7:d47::2]) by mx1.freebsd.org (Postfix) with ESMTP id C8EB08FC13; Sat, 19 Nov 2011 01:01:04 +0000 (UTC) Received: from zombie.fuzzwad.net (localhost [127.0.0.1]) by mail.volente.us (8.14.4/8.14.4) with ESMTP id pAJ112pC080508; Fri, 18 Nov 2011 19:01:02 -0600 (CST) (envelope-from rcm@fuzzwad.org) Message-ID: <4EC6FFCD.4080509@fuzzwad.org> Date: Fri, 18 Nov 2011 19:01:01 -0600 From: Ron McDowell User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Benjamin Kaduk References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Olivier_Cochard-Labb=E9?= , freebsd-current@freebsd.org, nwhitehorn@freebsd.org Subject: Re: Can't install FreeBSD-amd64-9.0-RC2: "/mnt: out of inodes" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 01:01:05 -0000 Benjamin Kaduk wrote: > On Thu, 17 Nov 2011, Olivier Cochard-Labb=E9 wrote: > >> Hi all, >> >> I tried to install FreeBSD-9.0-RC2-amd64-dvd1.iso (SHA256 verified) on= >> a VM and meet a reproducible problem: >> The VM has 128Mo RAM and a 4Go hard drive. >> >> During install process I choose these distribution sets: ports and=20 >> src only. >> And I'm using guided partitioning / Entire Disk / All Auto >> >> But each time (I delete and re-create a new VM multiple times) the >> installer failed during archive extraction of ports.txz (at about 88% >> progress of this file extraction) with this message: >> >> Error while extracting ports.txz: >> Can't create >> 'usr/ports/databases/p5-DBIx-Sunny/pkg-plist' >> >> And on the background there is this message: >> ...on /mnt: out of inodes >> >> Can someone else confirm this problem before I fill a PR ? > > A 4G disk is perhaps quite rare these days, but I expect that the=20 > issue is real. Please file the PR. > > The default block and fragment size for UFS/FFS were bumped by=20 > mckusick in r222319 (to general assent); presumably the installer=20 > should gain some logic to use smaller values for smaller disks, so=20 > that the available number of inodes is larger. (I presume that you=20 > have successfully installed earlier releases on 4G disk, of course. =20 > Though ... I think I may have, myself.) The ports tree has a very=20 > large number of small files, and is thus a very intensive user of inode= s. > > > Alas, my five minutes of searching were not enough to find where=20 > bsdinstall is actually generating default filesystem options, so I=20 > couldn't confirm this assumption. > > Thanks for the report, > > Ben Kaduk I see the same thing by creating 4gb filesystems for /usr/src and=20 /usr/obj on a larger hard disk, which, IMO, _is_ a reasonable thing to=20 do, and works fine on 8.2. --=20 Ron McDowell San Antonio TX From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 01:39:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBCC31065670 for ; Sat, 19 Nov 2011 01:39:45 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id D015C8FC15 for ; Sat, 19 Nov 2011 01:39:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; q=dns/txt; s=DKIM-NAME-SERVICES; d=a1poweruser.com; h=From:To:Cc:Subject:Message-ID:X-Sender:X-Envelope-From; l=500; bh=YZZq2GZopAUY+1RiErmUq99YL6A5RaMkPePcf0rElkQ=; b=NZC26FKtGDFY+ShH6caAg41O7RHVk8IWjtB1kRV4vwjS8ocJmPQGlm0zzfbl6GMcMo3E08OOtzftcfGlTNx57X+GR+siwzCIGxIzL953kLVo/xlhswEmuMGGzpGXEER00qvDEc3M9S1G7sTvmdIU1lkgrAqg9ewP6tZ6lGEnnqA= Received: from [192.168.1.104] ([120.29.65.225]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Nov 2011 17:39:42 -0800 Message-ID: <4EC708D9.8050709@a1poweruser.com> Date: Sat, 19 Nov 2011 09:39:37 +0800 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: nevtic@tx.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2011 01:39:42.0525 (UTC) FILETIME=[1C151ED0:01CCA65C] X-Sender: fbsd8@a1poweruser.com X-Envelope-From: fbsd8*a1poweruser.com Cc: freebsd-current@freebsd.org Subject: Re: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 01:39:46 -0000 nevtic@tx.net wrote: > > If you are performating a manual partion in 9.0-RC2 bsdinstall and you > delete any created partition except the most recently created one, the > total remaining space will be miscalculated. Reproducable as shown below. > > Workaround: if you delete a partition that is not the last partition > that was created, delete all partitions created after that partition > before continuing. Order does not seem to be important. > > The results are similar with other hard drive sizes, with the i386 or > amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go > back and check install discs prior to RC1) > > Reproducing the miscount: > > A 114 GB drive is used for this example: > > Select Manual Partitioning > > Perform the first Create on the drive and select GPT > > Creating the first partition: "Add Partition" "size" shows 114GB > > Change size to 4GB, set mountpoint to / and tab to OK > (agree to the boot partition creation) > > Create a second partition: "Add Partition" "size" shows 110GB > > Adjust size to 10GB, set mountpoint to /usr and tab to OK > > Create a third partition: "Add Partition" "size" shows 100GB > > Adjust size to 20GB, set mountpoint to /var, and tab to OK > > Create a 4th partition: "size" shows 80GB remaining > > Adjust size to 40GB, set mountpoint to /data, and tab to OK. > > There is 40 GB remaining on the drive. Now change the size of /var. > First, delete the currently configured /var partition. > > In the Partition Editor, adding up all the lines on the screen shows > 54GB (plus a 64K boot) as allocated, so there should now be 60GB > remaining. But the deleted /var space has not been added back into the > total. > > Select Create again: "Add Partition" "size" shows 40GB > > Adjust size to 30GB, set mountpoint as /var, tab to OK > > A subsequent "Create" will show that 20GB is remaining, rather than the > actual remaining 30GB. Selecting any size 20GB or larger for /home will > give you a 20GB partition, and then an additional create will show the > 10GB. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > You should submit this as a pr. From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 00:21:09 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EDB21065677; Sat, 19 Nov 2011 00:21:09 +0000 (UTC) (envelope-from milu@dat.pl) Received: from jab.dat.pl (dat.pl [80.51.155.34]) by mx1.freebsd.org (Postfix) with ESMTP id 086158FC16; Sat, 19 Nov 2011 00:21:08 +0000 (UTC) Received: from jab.dat.pl (jsrv.dat.pl [127.0.0.1]) by jab.dat.pl (Postfix) with ESMTP id D008885; Sat, 19 Nov 2011 01:04:51 +0100 (CET) X-Virus-Scanned: amavisd-new at dat.pl Received: from jab.dat.pl ([127.0.0.1]) by jab.dat.pl (jab.dat.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2m_MzGP7aFzt; Sat, 19 Nov 2011 01:04:48 +0100 (CET) Received: from snifi.laptop (178-36-161-135.adsl.inetia.pl [178.36.161.135]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by jab.dat.pl (Postfix) with ESMTPSA id 9E47C84; Sat, 19 Nov 2011 01:04:48 +0100 (CET) Message-ID: <4EC6F2B9.70107@dat.pl> Date: Sat, 19 Nov 2011 01:05:13 +0100 From: Maciej Milewski User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111118 Thunderbird/8.0 MIME-Version: 1.0 To: Doug Barton , freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------070500010802070004020009" X-Mailman-Approved-At: Sat, 19 Nov 2011 02:46:56 +0000 Cc: Subject: sys/conf/newvers.sh broken for work with git X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 00:21:09 -0000 This is a multi-part message in MIME format. --------------070500010802070004020009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I encountered newvers.sh issue while working locally with git tree. The last patch broke correct versioning. The issue is the "break" after checking the svnversion cmd. I use git for local work and have svnversion cmd too. So the first check is true and break makes exit from further processing for loop. This way there is no check if git is in path. Quick hack would be changing the order of this "if" to first check if there is .git dir and git cmd and then go further to check svnversion. This solution might be not perfect but atleast is working for me. Greetings, Maciek Quick patch is attached. --------------070500010802070004020009 Content-Type: text/plain; name="git-newvers.sh.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="git-newvers.sh.patch" --- sys/conf/newvers.sh 2011-11-19 00:56:50.795815738 +0100 +++ sys/conf/newvers-patched.sh 2011-11-19 00:58:21.187818982 +0100 @@ -88,14 +88,14 @@ i=`${MAKE:-make} -V KERN_IDENT` for dir in /bin /usr/bin /usr/local/bin; do - if [ -x "${dir}/svnversion" ] ; then - svnversion=${dir}/svnversion - break - fi if [ -d "${SYSDIR}/../.git" -a -x "${dir}/git" ] ; then git_cmd="${dir}/git --git-dir=${SYSDIR}/../.git" break fi + if [ -x "${dir}/svnversion" ] ; then + svnversion=${dir}/svnversion + break + fi done if [ -n "$svnversion" ] ; then --------------070500010802070004020009-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 09:32:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6EBA106566B; Sat, 19 Nov 2011 09:32:51 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 83E048FC13; Sat, 19 Nov 2011 09:32:51 +0000 (UTC) Received: by iakl21 with SMTP id l21so6968002iak.13 for ; Sat, 19 Nov 2011 01:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IBpB9xe8t6fN3MPJ8zOJtiwDnLxth/0H0Bqjoy59rIA=; b=rCEu1Etv6kMjKoVUQLj8sKfE4BMLCOkoCNDyeNQ9AAdYUGGexBH6vXJjbcRcfhUSAt VKl0iQOWjJdI4GwfZyMV1tzh0oKVrov68QfYKn2/ql3dN04HM6cj8NGdqghcXvtgRoqj afh2VshF0xVWYNNOAKtnlTEaytB3yzDkuRAKY= MIME-Version: 1.0 Received: by 10.42.135.66 with SMTP id o2mr6220493ict.0.1321695170889; Sat, 19 Nov 2011 01:32:50 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.42.243.198 with HTTP; Sat, 19 Nov 2011 01:32:50 -0800 (PST) In-Reply-To: References: <201111170959.56767.jhb@freebsd.org> <201111171632.34979.jhb@freebsd.org> Date: Sat, 19 Nov 2011 10:32:50 +0100 X-Google-Sender-Auth: 5ZcxXZGkHpU2HiuEor9e23h8dik Message-ID: From: Robert Millan To: John Baldwin Content-Type: multipart/mixed; boundary=90e6ba6e89d62986f104b21323a0 Cc: Kostik Belousov , Adrian Chadd , freebsd-current@freebsd.org, Warner Losh , freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 09:32:52 -0000 --90e6ba6e89d62986f104b21323a0 Content-Type: text/plain; charset=UTF-8 2011/11/18 Robert Millan : > 2011/11/17 John Baldwin : >> Hmm, I wonder if it's better to use the #ifndef approach rather than #undef >> so that when compilers are updated to DTRT we will honor their settings? > > Well, the compiler is supposed to know better than sys/param.h, I gave this a bit more thought.... The compiler knows about the system it was intended to build for, but sys/param.h *is* part of the system we're building for. It's impossible for sys/param.h to have the wrong information unless it's out of sync with the rest of the headers. As for the compiler, on FreeBSD it's hard for the compiler to be out of sync, because the system (in comparison with others) is tightly packaed and upgrade procedures are well defined. But if you take Debian, for example, we use the same compiler to build 8-STABLE, 9-STABLE and 10-CURRENT kernels. The compiler has no idea which version of FreeBSD the sources it is building come from. I wouldn't put compilers in general in a position where they're forced to know the FreeBSD major version beforehand because sys/param.h will give preference to the information coming from compiler. I propose this alternate patch which derives the major number from __FreeBSD_version instead. --90e6ba6e89d62986f104b21323a0 Content-Type: text/x-diff; charset=US-ASCII; name="freebsd_kernel.diff" Content-Disposition: attachment; filename="freebsd_kernel.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gv6f4hap0 SW5kZXg6IHN5cy9zeXMvcGFyYW0uaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvc3lzL3BhcmFtLmgJKHJl dmlzaW9uIDIyNzU4MCkKKysrIHN5cy9zeXMvcGFyYW0uaAkod29ya2luZyBjb3B5KQpAQCAtNjAs NiArNjAsMjMgQEAKICN1bmRlZiBfX0ZyZWVCU0RfdmVyc2lvbgogI2RlZmluZSBfX0ZyZWVCU0Rf dmVyc2lvbiAxMDAwMDAxCS8qIE1hc3RlciwgcHJvcGFnYXRlZCB0byBuZXd2ZXJzICovCiAKKy8q CisgKiBfX0ZyZWVCU0Rfa2VybmVsX18gaW5kaWNhdGVzIHRoYXQgdGhpcyBzeXN0ZW0gdXNlcyB0 aGUga2VybmVsIG9mIEZyZWVCU0QsCisgKiB3aGljaCBieSBkZWZpbml0aW9uIGlzIGFsd2F5cyB0 cnVlIG9uIEZyZWVCU0QgOi0pLiBUaGlzIG1hY3JvIG1heSBhbHNvCisgKiBiZSBkZWZpbmVkIG9u IG90aGVyIHN5c3RlbXMgdGhhdCB1c2UgdGhlIGtlcm5lbCBvZiBGcmVlQlNELCBzdWNoIGFzCisg KiBHTlUva0ZyZWVCU0QuCisgKgorICogSXQgaXMgdGVtcHRpbmcgdG8gdXNlIHRoaXMgbWFjcm8g aW4gdXNlcmxhbmQgY29kZSB3aGVuIHdlIHdhbnQgdG8gZW5hYmxlCisgKiBrZXJuZWwtc3BlY2lm aWMgcm91dGluZXMsIGFuZCBpbiBmYWN0IGl0J3MgZmluZSB0byBkbyB0aGlzIGluIGNvZGUgdGhh dAorICogaXMgcGFydCBvZiBGcmVlQlNEIGl0c2VsZi4gIEhvd2V2ZXIsIGJlIGF3YXJlIHRoYXQg YXMgcHJlc2VuY2Ugb2YgdGhpcworICogbWFjcm8gaXMgc3RpbGwgbm90IHdpZGVzcHJlYWQgKGUu Zy4gb2xkZXIgRnJlZUJTRCB2ZXJzaW9ucywgM3JkIHBhcnR5CisgKiBjb21waWxlcnMsIGV0Yyks IGl0IGlzIFNUUk9OR0xZIERJU0NPVVJBR0VEIHRvIGNoZWNrIGZvciB0aGlzIG1hY3JvIGluCisg KiBleHRlcm5hbCBhcHBsaWNhdGlvbnMgd2l0aG91dCBhbHNvIGNoZWNraW5nIGZvciBfX0ZyZWVC U0RfXyBhcyBhbgorICogYWx0ZXJuYXRpdmUuCisgKi8KKyN1bmRlZiBfX0ZyZWVCU0Rfa2VybmVs X18KKyNkZWZpbmUgX19GcmVlQlNEX2tlcm5lbF9fIChfX0ZyZWVCU0RfdmVyc2lvbiAvIDEwMDAw MCkKKwogI2lmZGVmIF9LRVJORUwKICNkZWZpbmUJUF9PU1JFTF9TSUdXQUlUCQk3MDAwMDAKICNk ZWZpbmUJUF9PU1JFTF9TSUdTRUdWCQk3MDAwMDQK --90e6ba6e89d62986f104b21323a0-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 10:05:32 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28B5E106564A for ; Sat, 19 Nov 2011 10:05:32 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 071B38FC15 for ; Sat, 19 Nov 2011 10:05:31 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RRhne-0003pV-OP for freebsd-current@freebsd.org; Sat, 19 Nov 2011 02:05:30 -0800 Date: Sat, 19 Nov 2011 02:05:30 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1321697130749-5006547.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: 9RC2 amd64 "Can't work out which disk we are booting from" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 10:05:32 -0000 Hello. I'm almost positive it's probably my fault, but anyway, I have installed FreeBSD on laptop from source (9-STABLE), on the same machine I can't boot RC2 usb.img due to "Can't work out which disk we are booting.." and after installing RC2 on usbstick and trying to boot it, same problem occurs. (well, surprise). I have used default layout on usbdrive. Any ideas? ls show files structure, but boot /boot/kernel doesn't work. On the side note, Verbatim STORE N GO 2.66 8GB gave me nothing but problems, not recommended. (it's actually "Blaze Drive" but it's recognised as store 'n go) best regards, - Jakub Lach -- View this message in context: http://freebsd.1045724.n5.nabble.com/9RC2-amd64-Can-t-work-out-which-disk-we-are-booting-from-tp5006547p5006547.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 10:32:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F08CE106564A for ; Sat, 19 Nov 2011 10:32:29 +0000 (UTC) (envelope-from mueller6727@bellsouth.net) Received: from fmailhost03.isp.att.net (fmailhost03.isp.att.net [207.115.11.53]) by mx1.freebsd.org (Postfix) with ESMTP id E05188FC13 for ; Sat, 19 Nov 2011 10:32:29 +0000 (UTC) Date: Sat, 19 Nov 2011 10:29:38 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium Received: from localhost (adsl-68-18-111-140.sdf.bellsouth.net[68.18.111.140]) by isp.att.net (frfwmhc03) with SMTP id <20111119102937H03005rl4le>; Sat, 19 Nov 2011 10:29:38 +0000 X-Originating-IP: [68.18.111.140] From: "Thomas Mueller" To: freebsd-current@freebsd.org References: <4EC6411A.2030703@infracaninophile.co.uk> Message-Id: <20111119103229.F08CE106564A@hub.freebsd.org> Subject: Re: FreeBSD 9.0-RC2 Available... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 10:32:30 -0000 > On 18/11/2011 10:53, Thomas Mueller wrote: > > *default release=cvs tag=RELENG_9 > > Am I screwed, am I OK, or do I simply have to rerun csup with RELENG_9_0 instead of RELENG_9 ? > Not screwed, but you'll be running 9.0-PRERELEASE rather than 9.0-RC2. > If you want to switch to the 9.0-RELEASE branch, change the tag to > RELENG_9_0 and cvsup again. Then redo the whole buildworld dance. > Cheers, > Matthew > -- > Dr Matthew J Seaman MA, D.Phil. Good to know I'm not screwed, that I can recover simply by rerunning csup, this time with RELENG_9_0 instead of RELENG_9. But I hadn't got to making buildworld yet on this update. Possibly there may be no serious difference between 9.0-PRERELEASE and 9.0-RC2 at this stage. As for the difference between STABLE and RELEASE, I believe STABLE is a sort of POSTRELEASE, like the post-release update to NetBSD 5.1 that permitted access to Linux ext2fs partition that didn't work previously with NetBSD; inode was 256 bytes. I think FreeBSD 9-STABLE (RELENG_9) would be development work toward FreeBSD 9.1, after FreeBSD 9.0 is released, but stabler than current/head. I looked in /usr/src/sys/conf/newvars.sh and indeed found that I had 9.0-PRERELEASE rather than RC2. Tom From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 14:28:31 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69E35106566C for ; Sat, 19 Nov 2011 14:28:31 +0000 (UTC) (envelope-from nikodemus@random-state.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 338D18FC0A for ; Sat, 19 Nov 2011 14:28:31 +0000 (UTC) Received: by ggnk5 with SMTP id k5so4463695ggn.13 for ; Sat, 19 Nov 2011 06:28:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.85.129 with SMTP id h1mr7212032igz.47.1321711167445; Sat, 19 Nov 2011 05:59:27 -0800 (PST) Received: by 10.50.180.201 with HTTP; Sat, 19 Nov 2011 05:59:27 -0800 (PST) In-Reply-To: <86mxd7qdzk.fsf@gmail.com> References: <86mxd7qdzk.fsf@gmail.com> Date: Sat, 19 Nov 2011 15:59:27 +0200 Message-ID: From: Nikodemus Siivola To: Nali Toja Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 19 Nov 2011 14:34:05 +0000 Cc: freebsd-current@freebsd.org Subject: Re: [Sbcl-bugs] crash in sb-concurrency tests after r216641 on x86-64/freebsd9/sb-thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 14:28:31 -0000 On 12 October 2011 03:00, Nali Toja wrote: > After r216641 sbcl built with sb-thread dies on mailbox tests. It also > dies when I try to complete a symbol in slime. The workaround seems to > be to revert libthr to r216640. > Any clue whether it's a FreeBSD bug or a SBCL bug? I've Bcc'd sbcl-bugs@ > in case it's the latter one. I find it quite possible that this was an SBCL bug. It would be much appreciated if you could try with current HEAD from SBCL's git repository if it makes things better. Cheers, =C2=A0-- Nikodemus From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 16:29:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63398106566B for ; Sat, 19 Nov 2011 16:29:10 +0000 (UTC) (envelope-from sub.mesa@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2A27D8FC0C for ; Sat, 19 Nov 2011 16:29:09 +0000 (UTC) Received: by ghbg20 with SMTP id g20so2011904ghb.13 for ; Sat, 19 Nov 2011 08:29:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=uNIwdkJpzICixgx9HluSaw/HopIZuf5mHNsI05oKSHU=; b=tldBepb1KfZJPrdrozZ0X/ZJzjkVqNrGrhDrC1ncpRhUQxVPDXhroGnlR++jS3x+Gm W465pif2TacTXZeAEkfiaNDfgkHcNjXMn5Hw0YVqXNU/riI7jA4T3IY/wDPy4xWuIthc XEf70kJ5pHihkrlhyPGnGCzmMQczCtjS1aCBo= MIME-Version: 1.0 Received: by 10.100.121.10 with SMTP id t10mr1764606anc.129.1321720149382; Sat, 19 Nov 2011 08:29:09 -0800 (PST) Received: by 10.236.79.233 with HTTP; Sat, 19 Nov 2011 08:29:09 -0800 (PST) Date: Sat, 19 Nov 2011 17:29:09 +0100 Message-ID: From: Jason Edwards To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ee (easy editor) bugged on 9.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 16:29:10 -0000 Dear list, Has anyone noticed the easy editor is quite bugged on 9.0? On console direct access, opening the easy editor has several bugs: 1) the cursor starts on line 2 instead of line 1 2) the line numbering is printed on line 1 instead of the boundary (line 0) 3) the keys page up and page down bring the escape menu Strange enough, if I SSH into the box the ee editor works normally. So I'm wondering if this is something other people have noticed? Just want to exclude the possibility of me doing something wrong. I've noticed this behavior on 9-CURRENT, 9.0-RC1 as well as 9.0-RC2, amd64. GENERIC kernel and tested inside Virtualbox. Regards, Jason From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 16:59:12 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45298106566B for ; Sat, 19 Nov 2011 16:59:12 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 9CF808FC1E for ; Sat, 19 Nov 2011 16:59:11 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 25EAA359317; Sat, 19 Nov 2011 17:59:09 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 0614D28468; Sat, 19 Nov 2011 17:59:09 +0100 (CET) Date: Sat, 19 Nov 2011 17:59:08 +0100 From: Jilles Tjoelker To: Nali Toja Message-ID: <20111119165908.GA92476@stack.nl> References: <86mxd7qdzk.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86mxd7qdzk.fsf@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org Subject: Re: crash in sb-concurrency tests after r216641 on x86-64/freebsd9/sb-thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 16:59:12 -0000 On Wed, Oct 12, 2011 at 12:00:07AM +0000, Nali Toja wrote: > After r216641 sbcl built with sb-thread dies on mailbox tests. It also > dies when I try to complete a symbol in slime. The workaround seems to > be to revert libthr to r216640. > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/154050 > http://svn.freebsd.org/changeset/base/216641 > http://www.freshports.org/lang/sbcl # or see ports/161444 for sbcl-1.0.52 > Any clue whether it's a FreeBSD bug or a SBCL bug? I've Bcc'd sbcl-bugs@ > in case it's the latter one. [snip] > Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) [snip] > (gdb) bt > #0 0x0000000800c5c7ec in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > #1 0x0000000800c5423e in _thr_umtx_timedwait_uint (mtx=0x8006d4ea8, id=0, clockid=0, abstime=0x0, shared=0) at /usr/src/lib/libthr/thread/thr_umtx.c:214 > #2 0x0000000800c5c04b in _thr_sleep (curthread=0x828d5d400, clockid=0, abstime=0x0) at /usr/src/lib/libthr/thread/thr_kern.c:212 > #3 0x0000000800c5f5dd in cond_wait_user (cvp=0x828fdf850, mp=0x828fe0970, abstime=0x0, cancel=1) at /usr/src/lib/libthr/thread/thr_cond.c:243 > #4 0x0000000800c5f856 in cond_wait_common (cond=0x8480f0008, mutex=0x8480f0000, abstime=0x0, cancel=1) at /usr/src/lib/libthr/thread/thr_cond.c:299 > #5 0x0000000800c5f8b7 in __pthread_cond_wait (cond=0x8480f0008, mutex=0x8480f0000) at /usr/src/lib/libthr/thread/thr_cond.c:313 > #6 0x00000008009e9fa0 in pthread_cond_wait_exp (p0=0x8480f0008, p1=0x8480f0000) at /usr/src/lib/libc/gen/_pthread_stubs.c:217 > #7 0x0000000000413574 in wait_for_thread_state_change (thread=0x8480f0010, state=16) at thread.h:53 > #8 0x00000000004133a8 in sig_stop_for_gc_handler (signal=31, info=0x847eef630, context=0x847eef2c0) at interrupt.c:1265 > #9 0x000000000041427d in low_level_handle_now_handler (signal=31, info=0x847eef630, void_context=0x847eef2c0) at interrupt.c:1729 > #10 0x00007ffffffff023 in ?? () > #11 0x0000000000414220 in low_level_unblock_me_trampoline () at interrupt.c:1723 > #12 0x000000100154c990 in ?? () > #13 0x000000000063eaa0 in interrupt_handlers () > #14 0x0000000200411d4f in ?? () > #15 0x0000001003375721 in ?? () > #16 0x38b485040000001a in ?? () > #17 0x00000000000a81f0 in ?? () > #18 0x0000000000000000 in ?? () > #19 0x0000000847eef840 in ?? () > #20 0x0000001003af2a2f in ?? () > #21 0x0000002004e9c3e1 in ?? () > #22 0x0000000800c58570 in _sigprocmask (how=Could not find the frame base for "_sigprocmask". > ) at /usr/src/lib/libthr/thread/thr_sig.c:584 > Previous frame inner to this frame (corrupt stack?) > (gdb) f 7 > #7 0x0000000000413574 in wait_for_thread_state_change (thread=0x8480f0010, state=16) at thread.h:53 > 53 pthread_cond_wait(thread->state_cond, thread->state_lock); > (gdb) l > 48 static inline void > 49 wait_for_thread_state_change(struct thread *thread, lispobj state) > 50 { > 51 pthread_mutex_lock(thread->state_lock); > 52 while (thread->state == state) > 53 pthread_cond_wait(thread->state_cond, thread->state_lock); > 54 pthread_mutex_unlock(thread->state_lock); > 55 } > 56 > 57 extern pthread_key_t lisp_thread; The cause of the trouble appears to be that pthread_cond_wait() is interrupted by a signal handler and the signal handler calls pthread_cond_wait() again (no matter whether it is on the same or a different condition variable). POSIX forbids this because (like most of the pthread functions) pthread_cond_wait() is not async-signal-safe. While the pre-r216641 code is not async-signal-safe either, it would usually work fine. With the r216641 code, the second call to pthread_cond_wait() aborts immediately with the 'thread was already on queue' message. The immediate issue could be fixed in libthr fairly easily by enabling its code to postpone signal handlers also during pthread_cond_wait() (a signal will still interrupt the wait). However, this does not fix issues due to signal handlers interrupting other pthread functions which may still cause erratic undefined behaviour. Therefore, it may not be desirable to do this. An alternative is to use pthread_suspend_np(). This function will wait for the thread to stop before returning, although it may stop almost anywhere. I have not tried this but calling it on a thread in pthread_cond_wait() should be safe. Ideally, it would not be necessary to stop all other threads while collecting garbage, but this may be hard to fix. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 17:07:35 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 310DD106566C for ; Sat, 19 Nov 2011 17:07:35 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id ED2D88FC12 for ; Sat, 19 Nov 2011 17:07:34 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id C2F3C10D0C4; Sat, 19 Nov 2011 18:07:33 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: Date: Sat, 19 Nov 2011 18:07:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5D3FFA12-BB54-4297-A098-3B85951ECEC5@lassitu.de> References: To: Jason Edwards X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-current@freebsd.org Subject: Re: ee (easy editor) bugged on 9.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 17:07:35 -0000 Am 19.11.2011 um 17:29 schrieb Jason Edwards: > Dear list, >=20 > Has anyone noticed the easy editor is quite bugged on 9.0? On console > direct access, opening the easy editor has several bugs: >=20 > 1) the cursor starts on line 2 instead of line 1 > 2) the line numbering is printed on line 1 instead of the boundary = (line 0) > 3) the keys page up and page down bring the escape menu >=20 > Strange enough, if I SSH into the box the ee editor works normally. So > I'm wondering if this is something other people have noticed? Just > want to exclude the possibility of me doing something wrong. >=20 > I've noticed this behavior on 9-CURRENT, 9.0-RC1 as well as 9.0-RC2, > amd64. GENERIC kernel and tested inside Virtualbox. Working fine here on 9.0-RC1. Is this a fresh install, or did you upgrade? Have you updated your ttys = to set the terminal type to xterm instead of cons25? Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 17:14:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A93D1065686 for ; Sat, 19 Nov 2011 17:14:56 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 293BE8FC0C for ; Sat, 19 Nov 2011 17:14:56 +0000 (UTC) Received: by ywe9 with SMTP id 9so5127604ywe.13 for ; Sat, 19 Nov 2011 09:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JcNd2NUHGXQGDS9uTShO7+rr9millaA6PnH6HmL89/Y=; b=q/W7U4q6x7+sWJXPk2IGHFcvqz/CBHDC8NW5PbAc4/fKXBTMxFDdJLl1qCPrdyrZeD sMuaEFpZjRGadnHWT1PQLg2tD5pV6bU9Rpaz64Az0wwz6D2nksTKiz95B9bKPkNcsDux sHAuQlwt/GgHJMNNWcWUQAh2BG1wLCzMeomMg= MIME-Version: 1.0 Received: by 10.236.173.202 with SMTP id v50mr11690843yhl.102.1321722895564; Sat, 19 Nov 2011 09:14:55 -0800 (PST) Received: by 10.151.92.7 with HTTP; Sat, 19 Nov 2011 09:14:55 -0800 (PST) In-Reply-To: <1321697130749-5006547.post@n5.nabble.com> References: <1321697130749-5006547.post@n5.nabble.com> Date: Sat, 19 Nov 2011 19:14:55 +0200 Message-ID: From: Alexander Yerenkow To: Jakub Lach Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: 9RC2 amd64 "Can't work out which disk we are booting from" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 17:14:56 -0000 Actually when I was trying to build amd64 image from sources from about PRE-RC1 I have exactly same error. But I have not found what it was, and switched to build i386 images only yet. 2011/11/19 Jakub Lach > Hello. > > I'm almost positive it's probably my fault, > but anyway, I have installed FreeBSD on > laptop from source (9-STABLE), on the same > machine I can't boot RC2 usb.img due to "Can't > work out which disk we are booting.." and after > installing RC2 on usbstick and trying to boot > it, same problem occurs. > (well, surprise). > > I have used default layout on usbdrive. > > Any ideas? > > ls show files structure, but boot /boot/kernel > doesn't work. > > On the side note, Verbatim STORE N GO 2.66 > 8GB gave me nothing but problems, not > recommended. (it's actually "Blaze Drive" > but it's recognised as store 'n go) > > best regards, > - Jakub Lach > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/9RC2-amd64-Can-t-work-out-which-disk-we-are-booting-from-tp5006547p5006547.html > Sent from the freebsd-current mailing list archive at Nabble.com. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Regards, Alexander Yerenkow From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 17:38:06 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0D3F106566B for ; Sat, 19 Nov 2011 17:38:06 +0000 (UTC) (envelope-from jakub_lach@mailplus.pl) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id AB8228FC13 for ; Sat, 19 Nov 2011 17:38:06 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1RRord-0003Qb-SN for freebsd-current@freebsd.org; Sat, 19 Nov 2011 09:38:05 -0800 Date: Sat, 19 Nov 2011 09:38:05 -0800 (PST) From: Jakub Lach To: freebsd-current@freebsd.org Message-ID: <1321724285873-5007183.post@n5.nabble.com> In-Reply-To: References: <1321697130749-5006547.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: 9RC2 amd64 "Can't work out which disk we are booting from" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 17:38:06 -0000 ...and booting dvd rc2 iso works. I actually installed from it to the usbdisk, just booting usb is broken. On the side note, bsdinstall is OK, missing maybe space/enter mapped action reminder, and certainly "back" button. -- View this message in context: http://freebsd.1045724.n5.nabble.com/9RC2-amd64-Can-t-work-out-which-disk-we-are-booting-from-tp5006547p5007183.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 17:56:29 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D14461065673; Sat, 19 Nov 2011 17:56:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5915F8FC15; Sat, 19 Nov 2011 17:56:28 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAJHuKtU091923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Nov 2011 19:56:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAJHuKtm027532; Sat, 19 Nov 2011 19:56:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAJHuKLL027531; Sat, 19 Nov 2011 19:56:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 Nov 2011 19:56:20 +0200 From: Kostik Belousov To: Robert Millan Message-ID: <20111119175620.GV50300@deviant.kiev.zoral.com.ua> References: <201111170959.56767.jhb@freebsd.org> <201111171632.34979.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U9/8TDFnS6G07P4u" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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: Adrian Chadd , freebsd-current@freebsd.org, Warner Losh , freebsd-arch@freebsd.org Subject: Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 17:56:30 -0000 --U9/8TDFnS6G07P4u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 19, 2011 at 10:32:50AM +0100, Robert Millan wrote: > 2011/11/18 Robert Millan : > > 2011/11/17 John Baldwin : > >> Hmm, I wonder if it's better to use the #ifndef approach rather than #= undef > >> so that when compilers are updated to DTRT we will honor their setting= s? > > > > Well, the compiler is supposed to know better than sys/param.h, >=20 > I gave this a bit more thought.... >=20 > The compiler knows about the system it was intended to build for, but > sys/param.h *is* part of the system we're building for. It's > impossible for sys/param.h to have the wrong information unless it's > out of sync with the rest of the headers. >=20 > As for the compiler, on FreeBSD it's hard for the compiler to be out > of sync, because the system (in comparison with others) is tightly > packaed and upgrade procedures are well defined. >=20 > But if you take Debian, for example, we use the same compiler to build > 8-STABLE, 9-STABLE and 10-CURRENT kernels. The compiler has no idea > which version of FreeBSD the sources it is building come from. >=20 > I wouldn't put compilers in general in a position where they're forced > to know the FreeBSD major version beforehand because sys/param.h will > give preference to the information coming from compiler. >=20 > I propose this alternate patch which derives the major number from > __FreeBSD_version instead. I fully agree with an idea that compiler is not an authorative source of the knowledge of the FreeBSD version. Even more, I argue that we shall not rely on compiler for this at all. Ideally, we should be able to build FreeBSD using the stock compilers without local modifications. Thus relying on the symbols defined by compiler, and not the source is the thing to avoid and consistently remove. We must do this to be able to use third-party tooldchain for FreeBSD builds. That said, why not define __FreeBSD_kernel as equal to __FreeBSD_version ? And then make more strong wording about other systems that use the macro, e.g. remove 'may' from the kFreeBSD example. Also, please remove the smile from comment. --U9/8TDFnS6G07P4u Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7H7cQACgkQC3+MBN1Mb4jt8QCeKe7cMDkJUgAl1cprocxvpoE9 khMAniVomr/Laq0OfqDRj4yk5wB1Cbog =WiER -----END PGP SIGNATURE----- --U9/8TDFnS6G07P4u-- From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 18:30:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A7891065677 for ; Sat, 19 Nov 2011 18:30:18 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:fc50:1000:8200:216:3eff:fe2c:dc8f]) by mx1.freebsd.org (Postfix) with ESMTP id 085C78FC1F for ; Sat, 19 Nov 2011 18:30:17 +0000 (UTC) Received: from [IPv6:2604:8800:137::21b:63ff:fe91:4123] ([IPv6:2604:8800:137:0:21b:63ff:fe91:4123]) (authenticated bits=0) by orthanc.ca (8.14.4/8.14.4) with ESMTP id pAJIUFCs037504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 19 Nov 2011 10:30:17 -0800 (PST) (envelope-from lyndon@orthanc.ca) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lyndon Nerenberg In-Reply-To: Date: Sat, 19 Nov 2011 10:30:15 -0800 Content-Transfer-Encoding: 7bit Message-Id: <084D61AD-9CA8-4C9E-848B-E058C1A8C764@orthanc.ca> References: To: Jason Edwards X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: ee (easy editor) bugged on 9.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 18:30:18 -0000 Methinks your $TERM is set incorrectly. From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 19:05:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C1241065670 for ; Sat, 19 Nov 2011 19:05:47 +0000 (UTC) (envelope-from jbeich@tormail.net) Received: from server2.hudsonvalleyhost.com (server2.hudsonvalleyhost.com [66.7.195.77]) by mx1.freebsd.org (Postfix) with ESMTP id 470888FC13 for ; Sat, 19 Nov 2011 19:05:46 +0000 (UTC) Received: from politkovskaja.torservers.net ([77.247.181.165]:21176 helo=internal.tormail.net) by server2.hudsonvalleyhost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1RRp38-002vBw-A0; Sat, 19 Nov 2011 12:50:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.net; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:Date:References:In-Reply-To:Subject:Cc:To:From; bh=togs5Fv7Amguk594O1+izw2ZtJakGSO0M1XFPOzzYdM=; b=UL8iwxFJBRdBBXPezl+BHpcEjqpqpmGP56GupXvFE6kjP3Ti4Bd2lTOL2DizgRLZXlmgcvR7Rp8Exf1T3Kp8UewBXL4ld1/GnPtdgGTte8QsjKcP4f55WUtK1AoygpH48ahDPSrZO2Xfvtc9PzXn6bHSyMaOnFEnwWCSIgAL8zQ=; Received: from jbeich by internal.tormail.net with local (Exim 4.63) (envelope-from ) id 1RRp24-000H7A-AW; Sat, 19 Nov 2011 17:48:55 +0000 From: Jan Beich To: Nikodemus Siivola In-Reply-To: (Nikodemus Siivola's message of "Sat, 19 Nov 2011 15:59:27 +0200") References: <86mxd7qdzk.fsf@gmail.com> Date: Sat, 19 Nov 2011 21:48:30 +0400 MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1RRp24-000H7A-AW@internal.tormail.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server2.hudsonvalleyhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tormail.net X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org, Nali Toja Subject: Re: [Sbcl-bugs] crash in sb-concurrency tests after r216641 on x86-64/freebsd9/sb-thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 19:05:47 -0000 Nikodemus Siivola writes: >> After r216641 sbcl built with sb-thread dies on mailbox tests. It also >> dies when I try to complete a symbol in slime. The workaround seems to >> be to revert libthr to r216640. > >> Any clue whether it's a FreeBSD bug or a SBCL bug? I've Bcc'd sbcl-bugs@ >> in case it's the latter one. > > I find it quite possible that this was an SBCL bug. > > It would be much appreciated if you could try with current HEAD from > SBCL's git repository if it makes things better. I've tried git master (as of d0d44cc) and sb-thread build passes fine, mailbox.interrupts-safety.1 test no longer hangs. Also tried on stumpwm + slime (:spawn) setup, it no longer crashes. -- FreeBSD 10.0-CURRENT r227674M amd64 From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 19:05:50 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD03D106564A for ; Sat, 19 Nov 2011 19:05:50 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 920298FC14 for ; Sat, 19 Nov 2011 19:05:50 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so1916190vbb.13 for ; Sat, 19 Nov 2011 11:05:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6JE+U1pWMKQcrmFryFJdlZLJEyCYE/oNcViMteaCJ08=; b=IQXApvvD4MtekJSKyLpkEBsVF1n8aJiJ2cTmWkuiPz/ohWYVPMoTxjgT9rPqBzx27E nqxhtNgoamakyCEIEf+tCHOeHDVrXPpp1lhl12EUHBRD+YMZj5CfwbHy/Y0km/oN8xaK 3b2wUE2Pg6gtaU6rli4cmncjcUc0sz+kWTnzM= MIME-Version: 1.0 Received: by 10.52.174.193 with SMTP id bu1mr8702597vdc.71.1321729549762; Sat, 19 Nov 2011 11:05:49 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Sat, 19 Nov 2011 11:05:49 -0800 (PST) In-Reply-To: <084D61AD-9CA8-4C9E-848B-E058C1A8C764@orthanc.ca> References: <084D61AD-9CA8-4C9E-848B-E058C1A8C764@orthanc.ca> Date: Sat, 19 Nov 2011 11:05:49 -0800 X-Google-Sender-Auth: RwjE8nK-ifPJt4PlF1jgzPxiWSo Message-ID: From: Adrian Chadd To: Lyndon Nerenberg Content-Type: text/plain; charset=ISO-8859-1 Cc: Jason Edwards , freebsd-current@freebsd.org Subject: Re: ee (easy editor) bugged on 9.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 19:05:50 -0000 .. how many users is this going to trip up? adrian From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 20:51:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1CED106564A; Sat, 19 Nov 2011 20:51:10 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5FFAA8FC0C; Sat, 19 Nov 2011 20:51:10 +0000 (UTC) Received: by ghbg20 with SMTP id g20so2165449ghb.13 for ; Sat, 19 Nov 2011 12:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SK0oWP7ZSXiFg9YyQo48/mbChK47zMRs8lR5Y/ADN1E=; b=HQdwb/+qRo2aDxPoYHnEQLV1T0uxHogAz81aOsD3yFoKfegLUceotZeV6KPWGnv6rF JkrSz1+PQqi/G3QNmncFcKH83FPC8F6eWHbGFSWZKLp9se4gxT8/reggBxm9uw2pFgSD Ny6Z3lSxetzZjRbqurT/vcYqkBhN0f2W9MPvQ= MIME-Version: 1.0 Received: by 10.182.59.49 with SMTP id w17mr1781298obq.37.1321735869728; Sat, 19 Nov 2011 12:51:09 -0800 (PST) Received: by 10.182.7.34 with HTTP; Sat, 19 Nov 2011 12:51:09 -0800 (PST) In-Reply-To: References: <084D61AD-9CA8-4C9E-848B-E058C1A8C764@orthanc.ca> Date: Sat, 19 Nov 2011 12:51:09 -0800 Message-ID: From: Garrett Cooper To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Jason Edwards , Lyndon Nerenberg , freebsd-current@freebsd.org Subject: Re: ee (easy editor) bugged on 9.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 20:51:10 -0000 On Sat, Nov 19, 2011 at 11:05 AM, Adrian Chadd wrote: > .. how many users is this going to trip up? cons25 is pretty much FUBAR on 9.x+ compared to previous releases. I went through several iterations with ed@ over the fact that various curses based apps were broken with the libteken work, but then just gave in and set 'xterm'. That being said, I can't reproduce the issue Jason mentioned in the first post. 1. Have you rebuilt your termcap database? 2. What is your $TERM in the ssh case and the console case? Etc. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 20:53:39 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 9AFD31065670; Sat, 19 Nov 2011 20:53:39 +0000 (UTC) Date: Sat, 19 Nov 2011 20:53:39 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20111119205339.GA35973@freebsd.org> References: <084D61AD-9CA8-4C9E-848B-E058C1A8C764@orthanc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Adrian Chadd , Jason Edwards , Lyndon Nerenberg , freebsd-current@freebsd.org Subject: Re: ee (easy editor) bugged on 9.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 20:53:39 -0000 On Sat Nov 19 11, Garrett Cooper wrote: > On Sat, Nov 19, 2011 at 11:05 AM, Adrian Chadd wrote: > > .. how many users is this going to trip up? > > cons25 is pretty much FUBAR on 9.x+ compared to previous releases. I > went through several iterations with ed@ over the fact that various > curses based apps were broken with the libteken work, but then just > gave in and set 'xterm'. > > That being said, I can't reproduce the issue Jason mentioned in the first post. running a very recent HEAD doing 'export TERM=cons25' in zsh and then running 'ee', i can exactly reproduce this issue. cheers. alex > > 1. Have you rebuilt your termcap database? > 2. What is your $TERM in the ssh case and the console case? > Etc. > > Thanks, > -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 20:57:49 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13CF2106566B; Sat, 19 Nov 2011 20:57:49 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id A24E98FC16; Sat, 19 Nov 2011 20:57:48 +0000 (UTC) Received: by ggnk5 with SMTP id k5so4704585ggn.13 for ; Sat, 19 Nov 2011 12:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=85aCDlISN1U2CPZ+U6TrQikajovwN2vrcB4ze6PqPRg=; b=T7alkUNW6kZsXtXp8Yz0JbpsZVL1nnr1kO1soI6FZBFtEH9T7cuOF3rySLb8BdjLzL 8BIc2sU8h8777iG2Bisi7FCy95m1zc70jqf3N2IH1SYOwkORP5Mmn7t360eUOe9RlhMh BgbI8Z93v0FJHeXaXAi3Fm1MASRdfvUDK5Zko= MIME-Version: 1.0 Received: by 10.182.169.34 with SMTP id ab2mr1814401obc.27.1321736267797; Sat, 19 Nov 2011 12:57:47 -0800 (PST) Received: by 10.182.7.34 with HTTP; Sat, 19 Nov 2011 12:57:47 -0800 (PST) In-Reply-To: <20111119205339.GA35973@freebsd.org> References: <084D61AD-9CA8-4C9E-848B-E058C1A8C764@orthanc.ca> <20111119205339.GA35973@freebsd.org> Date: Sat, 19 Nov 2011 12:57:47 -0800 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: Adrian Chadd , Jason Edwards , Lyndon Nerenberg , freebsd-current@freebsd.org Subject: Re: ee (easy editor) bugged on 9.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 20:57:49 -0000 On Sat, Nov 19, 2011 at 12:53 PM, Alexander Best wrote: > On Sat Nov 19 11, Garrett Cooper wrote: >> On Sat, Nov 19, 2011 at 11:05 AM, Adrian Chadd wrote: >> > .. how many users is this going to trip up? >> >> cons25 is pretty much FUBAR on 9.x+ compared to previous releases. I >> went through several iterations with ed@ over the fact that various >> curses based apps were broken with the libteken work, but then just >> gave in and set 'xterm'. >> >> That being said, I can't reproduce the issue Jason mentioned in the first post. > > running a very recent HEAD doing 'export TERM=cons25' in zsh and then running > 'ee', i can exactly reproduce this issue. How are you accessing the terminal? I ask in part because of this email thread: http://comments.gmane.org/gmane.os.freebsd.current/136528 . Cheers, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 21:04:56 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1FA7A1065672; Sat, 19 Nov 2011 21:04:56 +0000 (UTC) Date: Sat, 19 Nov 2011 21:04:56 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20111119210456.GA38383@freebsd.org> References: <084D61AD-9CA8-4C9E-848B-E058C1A8C764@orthanc.ca> <20111119205339.GA35973@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Adrian Chadd , Jason Edwards , Lyndon Nerenberg , freebsd-current@freebsd.org Subject: Re: ee (easy editor) bugged on 9.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 21:04:56 -0000 On Sat Nov 19 11, Garrett Cooper wrote: > On Sat, Nov 19, 2011 at 12:53 PM, Alexander Best wrote: > > On Sat Nov 19 11, Garrett Cooper wrote: > >> On Sat, Nov 19, 2011 at 11:05 AM, Adrian Chadd wrote: > >> > .. how many users is this going to trip up? > >> > >> cons25 is pretty much FUBAR on 9.x+ compared to previous releases. I > >> went through several iterations with ed@ over the fact that various > >> curses based apps were broken with the libteken work, but then just > >> gave in and set 'xterm'. > >> > >> That being said, I can't reproduce the issue Jason mentioned in the first post. > > > > running a very recent HEAD doing 'export TERM=cons25' in zsh and then running > > 'ee', i can exactly reproduce this issue. > > How are you accessing the terminal? I ask in part because of this > email thread: http://comments.gmane.org/gmane.os.freebsd.current/136528 what do you mean? i fire up xterm (actually sakura in my case) and simply type 'export TERM=cons25'. this is on my local machine. however i tried the same over ssh, connecting to hub.freebsd.org (which is running7.4-STABLE, and got the same result. cheers. alex > . > Cheers, > -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Nov 19 21:14:08 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91DF9106566C for ; Sat, 19 Nov 2011 21:14:08 +0000 (UTC) (envelope-from jbeich@tormail.net) Received: from server2.hudsonvalleyhost.com (server2.hudsonvalleyhost.com [66.7.195.77]) by mx1.freebsd.org (Postfix) with ESMTP id 5F53C8FC08 for ; Sat, 19 Nov 2011 21:14:07 +0000 (UTC) Received: from s01064ce676507e00.cg.shawcable.net ([68.144.78.238]:52848 helo=internal.tormail.net) by server2.hudsonvalleyhost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1RRsEg-003Tvq-Ll; Sat, 19 Nov 2011 16:14:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.net; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:Date:References:In-Reply-To:Subject:Cc:To:From; bh=r5OKOTPSh9riYtxaizU5r7pPAcXUoX0nn3bzTmj7Lus=; b=oC9QOJFQdYBHYX0Hd0gClNyoZDc2nHuAarUrLKHtDiAh26a7sq312UdE/ZEsA8UrpyM52ZbJQdJ3oiUdBfRRNJ0gFVT6vXhGhwG2uwcwxsOdyLrsjjGtX3QJbFUBNcdO2J31UsOb/fjZRyLcakGi4vztyVpilt7CD+UxfPLIpoY=; Received: from jbeich by internal.tormail.net with local (Exim 4.63) (envelope-from ) id 1RRsEK-000Kzw-4x; Sat, 19 Nov 2011 21:13:47 +0000 From: Jan Beich To: Jason Edwards In-Reply-To: (Jason Edwards's message of "Sat, 19 Nov 2011 17:29:09 +0100") References: Date: Sat, 19 Nov 2011 23:13:25 +0200 MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1RRsEK-000Kzw-4x@internal.tormail.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server2.hudsonvalleyhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tormail.net X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current@freebsd.org Subject: Re: ee (easy editor) bugged on 9.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 21:14:08 -0000 Jason Edwards writes: > Has anyone noticed the easy editor is quite bugged on 9.0? On console > direct access, opening the easy editor has several bugs: > > 1) the cursor starts on line 2 instead of line 1 > 2) the line numbering is printed on line 1 instead of the boundary (line 0) > 3) the keys page up and page down bring the escape menu Try to use cons25 emulation beforehand $ vidcontrol -T cons25 # aka TEKEN_CONS25 in kernel config unless you've updated etc/ttys to use `xterm'.