From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 11 00:40:07 2009 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89E611065672 for ; Sun, 11 Jan 2009 00:40:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 65ED38FC13 for ; Sun, 11 Jan 2009 00:40:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0B0e5qB046292 for ; Sun, 11 Jan 2009 00:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0B0e55Q046291; Sun, 11 Jan 2009 00:40:05 GMT (envelope-from gnats) Resent-Date: Sun, 11 Jan 2009 00:40:05 GMT Resent-Message-Id: <200901110040.n0B0e55Q046291@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Gary Byers Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61C38106566B for ; Sun, 11 Jan 2009 00:35:14 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 4FA6F8FC13 for ; Sun, 11 Jan 2009 00:35:14 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n0B0ZDwq089906 for ; Sun, 11 Jan 2009 00:35:13 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n0B0ZDX5089905; Sun, 11 Jan 2009 00:35:13 GMT (envelope-from nobody) Message-Id: <200901110035.n0B0ZDX5089905@www.freebsd.org> Date: Sun, 11 Jan 2009 00:35:13 GMT From: Gary Byers To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Sun, 11 Jan 2009 00:52:47 +0000 Cc: Subject: amd64/130355: i386_set_fsbase() doesn't seem to set %fs for 32-bit process under 7.1/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 00:40:07 -0000 >Number: 130355 >Category: amd64 >Synopsis: i386_set_fsbase() doesn't seem to set %fs for 32-bit process under 7.1/amd64 >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jan 11 00:40:05 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Gary Byers >Release: 7.1-RELEASE/amd64 >Organization: Clozure Associates >Environment: FreeBSD f71.abq.clozure.com 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: i386_set_fsbase(void *addr) has the effect of causing memory references relative to %fs to reference the linear address "addr"; part of this effect is achieved by loading a segment descriptor (GSEL(GUFS_SEL, SEL_UPL), which is generally = 0x13) into %fs on return from the sysarch syscall. This works as expected on (at least) i386 versions of 6.4-RELEASE, 7.0-RELEASE, and 7.1-RELEASE and on amd64 versions of 6.4-RELEASE and 7.0-RELEASE, but on 7.1-RELEASE/amd64 the i386_set_fsbase() call returns 0 but %fs is unchanged on return and subsequent attempts to reference memory relative to %fs seem to be equivalent to references relative to address 0. >How-To-Repeat: Compile (in a 32-bit FreeBSD/i386 environment) a small program that uses i386_set_fsbase() and checks to ensure that %fs has changed on successful return from the call to i386_set_fsbase(). Run the program on i386 versions of FreeBSD (6.4, 7.0, 7.1) and on amd64 versions of 6.4 and 7.0 and note that %fs is changed by the syscall. Run the program on 7.1-RELEASE/amd64 and note that it fails. (I'm not really sure if I'm supposed to provide a simple test case on the web form that I'm using to report this; I can easily do so if requested.) >Fix: Unknown. To the extent that I understand the issue, it seems to have to do with code that tries to ensure that the correct value is loaded into %fs on return from the syscall and on subsequent context switches; the code that actually sets the fsbase msr seems to be unchanged between the released versions of 7.0 and 7.1. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 11 06:40:02 2009 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C399D1065674 for ; Sun, 11 Jan 2009 06:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A05298FC16 for ; Sun, 11 Jan 2009 06:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0B6e2hE024771 for ; Sun, 11 Jan 2009 06:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0B6e2xl024770; Sun, 11 Jan 2009 06:40:02 GMT (envelope-from gnats) Resent-Date: Sun, 11 Jan 2009 06:40:02 GMT Resent-Message-Id: <200901110640.n0B6e2xl024770@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Jack Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74B7C106564A for ; Sun, 11 Jan 2009 06:34:45 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 632298FC08 for ; Sun, 11 Jan 2009 06:34:45 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n0B6Yj1i094760 for ; Sun, 11 Jan 2009 06:34:45 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n0B6YjfX094759; Sun, 11 Jan 2009 06:34:45 GMT (envelope-from nobody) Message-Id: <200901110634.n0B6YjfX094759@www.freebsd.org> Date: Sun, 11 Jan 2009 06:34:45 GMT From: Jack To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: amd64/130365: Elitegroup A780GM-A Chipset:AMD 780G&SB700 IDE controller not recognized X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 06:40:03 -0000 >Number: 130365 >Category: amd64 >Synopsis: Elitegroup A780GM-A Chipset:AMD 780G&SB700 IDE controller not recognized >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jan 11 06:40:02 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Jack >Release: 7.1-RELEASE >Organization: >Environment: FreeBSD jack.musirc.com 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: The dmesg output shows: ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=7f ostat1=7f ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat1=0x7f err=0xff lsb=0xff msb=0xff ata0: reset tp2 stat0=ff stat1=ff devices=0x0 None of the IDE devices are detected by the system. Chipset is AMD 780G and SB700 >How-To-Repeat: Boot FreeBSD 7.1 from disk >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 11 07:10:06 2009 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC7591065687 for ; Sun, 11 Jan 2009 07:10:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A79878FC0A for ; Sun, 11 Jan 2009 07:10:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0B7A6uQ045756 for ; Sun, 11 Jan 2009 07:10:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0B7A6CE045755; Sun, 11 Jan 2009 07:10:06 GMT (envelope-from gnats) Resent-Date: Sun, 11 Jan 2009 07:10:06 GMT Resent-Message-Id: <200901110710.n0B7A6CE045755@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Jack Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C2A6106566C for ; Sun, 11 Jan 2009 07:06:29 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 28C3D8FC12 for ; Sun, 11 Jan 2009 07:06:29 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n0B76Sjh009734 for ; Sun, 11 Jan 2009 07:06:28 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n0B76SB1009733; Sun, 11 Jan 2009 07:06:28 GMT (envelope-from nobody) Message-Id: <200901110706.n0B76SB1009733@www.freebsd.org> Date: Sun, 11 Jan 2009 07:06:28 GMT From: Jack To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: amd64/130368: Switching from xorg to console locks up computer X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 07:10:07 -0000 >Number: 130368 >Category: amd64 >Synopsis: Switching from xorg to console locks up computer >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jan 11 07:10:05 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Jack >Release: 7.1-RELEASE >Organization: >Environment: FreeBSD jack.musirc.com 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: Switching from xorg to the console causes the system to freeze. Attached is the dmesg output Motherboard is ECS A780GM-A >How-To-Repeat: start xorg and logout or ctrl+alt+backspace and the system hangs and does not respond to any keyboard actions. >Fix: Patch attached with submission follows: ums0: 3 buttons and Z dir. Timecounters tick every 1.000 msec md0: Preloaded image 4194304 bytes at 0xffffffff80c4be40 ad4: 476940MB at ata2-master SATA300 ad6: 381554MB at ata3-master SATA300 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/md0 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...502 145 69 67 65 2 2 2 0 0 0 done All buffers synced. Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80cc0000. Preloaded elf obj module "/boot/kernel/sound.ko" at 0xffffffff80cc01d0. Preloaded elf obj module "/boot/kernel/snd_ich.ko" at 0xffffffff80cc0838. Preloaded elf obj module "/boot/kernel/accf_data.ko" at 0xffffffff80cc0e20. Preloaded elf obj module "/boot/kernel/accf_http.ko" at 0xffffffff80cc12d0. Calibrating clock(s) ... i8254 clock: 1193218 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3200136328 Hz CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6400+ (3200.14-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f33 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative usable memory = 8541208576 (8145 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000dc3000 - 0x00000000dfeaffff, 3742289920 bytes (913645 pages) 0x0000000100000000 - 0x000000020e16bfff, 4531339264 bytes (1106284 pages) avail memory = 8257953792 (7875 MB) ACPI APIC Table: <110608 APIC1133> INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ACPI: RSDP @ 0x0xf9e40/0x0014 (v 0 ACPIAM) ACPI: RSDT @ 0x0xdfeb0000/0x0038 (v 1 110608 RSDT1133 0x20081106 MSFT 0x00000097) ACPI: FACP @ 0x0xdfeb0200/0x0084 (v 2 110608 FACP1133 0x20081106 MSFT 0x00000097) ACPI: DSDT @ 0x0xdfeb0440/0x4D44 (v 1 1AAAA 1AAAA000 0x00000000 INTL 0x20051117) ACPI: FACS @ 0x0xdfebe000/0x0040 ACPI: APIC @ 0x0xdfeb0390/0x006C (v 1 110608 APIC1133 0x20081106 MSFT 0x00000097) ACPI: MCFG @ 0x0xdfeb0400/0x003C (v 1 110608 OEMMCFG 0x20081106 MSFT 0x00000097) ACPI: OEMB @ 0x0xdfebe040/0x0071 (v 1 110608 OEMB1133 0x20081106 MSFT 0x00000097) ACPI: HPET @ 0x0xdfeb5190/0x0038 (v 1 110608 OEMHPET 0x20081106 MSFT 0x00000097) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010000 ath_rate: version 1.2 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_buffersize=16384 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 wlan_amrr: wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Jan 1 2009 08:57:24) acpi0: <110608 RSDT1133> on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.RS78.NB2_ -> bus 0 dev 0 func 0 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 AcpiOsDerivePciId: \\_SB_.PCI0.SATA.SACS -> bus 0 dev 17 func 0 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of ffb80000, 80000 (3) failed acpi0: reservation of fec10000, 20 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dfe00000 (3) failed ACPI HPET table warning: Sequence is non-zero (2) ACPI timer: 0/3 0/5 0/3 0/3 0/3 0/3 1/2 0/3 0/3 0/3 -> 1 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 4 7 10 11 12 14 15 Validation 0 7 N 0 4 7 10 11 12 14 15 After Disable 0 255 N 0 4 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 4 N 0 4 7 10 11 12 14 15 Validation 0 4 N 0 4 7 10 11 12 14 15 After Disable 0 255 N 0 4 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 4 7 10 11 12 14 15 Validation 0 10 N 0 4 7 10 11 12 14 15 After Disable 0 255 N 0 4 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 4 7 10 11 12 14 15 Validation 0 10 N 0 4 7 10 11 12 14 15 After Disable 0 255 N 0 4 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 4 7 10 11 12 14 15 Validation 0 255 N 0 4 7 10 11 12 14 15 After Disable 0 255 N 0 4 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 4 7 10 11 12 14 15 Validation 0 255 N 0 4 7 10 11 12 14 15 After Disable 0 255 N 0 4 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 4 7 10 11 12 14 15 Validation 0 11 N 0 4 7 10 11 12 14 15 After Disable 0 255 N 0 4 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 4 7 10 11 12 14 15 Validation 0 255 N 0 4 7 10 11 12 14 15 After Disable 0 255 N 0 4 7 10 11 12 14 15 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x4353 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1022, dev=0x9600, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x9602, revid=0x00 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x1a (6500 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x9606, revid=0x00 domain=0, bus=0, slot=6, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.6.INTA pcib0: slot 6 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4391, revid=0x00 domain=0, bus=0, slot=17, func=0 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xb000, size 3, enabled map[14]: type I/O Port, range 32, base 0xa000, size 2, enabled map[18]: type I/O Port, range 32, base 0x9000, size 3, enabled map[1c]: type I/O Port, range 32, base 0x8000, size 2, enabled map[20]: type I/O Port, range 32, base 0x7000, size 4, enabled map[24]: type Memory, range 32, base 0xfe7ff800, size 10, enabled pcib0: matched entry for 0.17.INTA pcib0: slot 17 INTA hardwired to IRQ 22 found-> vendor=0x1002, dev=0x4397, revid=0x00 domain=0, bus=0, slot=18, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0102, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 map[10]: type Memory, range 32, base 0xfe7fe000, size 12, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4398, revid=0x00 domain=0, bus=0, slot=18, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 map[10]: type Memory, range 32, base 0xfe7fd000, size 12, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4396, revid=0x00 domain=0, bus=0, slot=18, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0102, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=4 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe7ff000, size 8, enabled pcib0: matched entry for 0.18.INTB pcib0: slot 18 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x4397, revid=0x00 domain=0, bus=0, slot=19, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type Memory, range 32, base 0xfe7fc000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4398, revid=0x00 domain=0, bus=0, slot=19, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type Memory, range 32, base 0xfe7f7000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4396, revid=0x00 domain=0, bus=0, slot=19, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0102, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe7f6800, size 8, enabled pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4385, revid=0x3a domain=0, bus=0, slot=20, func=0 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0403, statreg=0xd230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x439c, revid=0x00 domain=0, bus=0, slot=20, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 MSI supports 2 messages map[20]: type I/O Port, range 32, base 0xff00, size 4, enabled found-> vendor=0x1002, dev=0x4383, revid=0x00 domain=0, bus=0, slot=20, func=2 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0410, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xfe7f0000, size 14, enabled pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x439d, revid=0x00 domain=0, bus=0, slot=20, func=3 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4384, revid=0x00 domain=0, bus=0, slot=20, func=4 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4399, revid=0x00 domain=0, bus=0, slot=20, func=5 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0102, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type Memory, range 32, base 0xfe7f5000, size 12, enabled pcib0: matched entry for 0.20.INTC pcib0: slot 20 INTC hardwired to IRQ 18 found-> vendor=0x1022, dev=0x1100, revid=0x00 domain=0, bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 domain=0, bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 domain=0, bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 domain=0, bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xc000-0xcfff pcib1: memory decode 0xfe800000-0xfe9fffff pcib1: prefetched decode 0xfa000000-0xfbffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x9610, revid=0x00 domain=0, bus=1, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 32, base 0xfa000000, size 25, enabled pcib1: requested memory range 0xfa000000-0xfbffffff: good map[14]: type I/O Port, range 32, base 0xc000, size 8, enabled pcib1: requested I/O range 0xc000-0xc0ff: in range map[18]: type Memory, range 32, base 0xfe9f0000, size 16, enabled pcib1: requested memory range 0xfe9f0000-0xfe9fffff: good map[24]: type Memory, range 32, base 0xfe800000, size 20, enabled pcib1: requested memory range 0xfe800000-0xfe8fffff: good pcib1: matched entry for 1.5.INTA pcib1: slot 5 INTA hardwired to IRQ 18 vgapci0: port 0xc000-0xc0ff mem 0xfa000000-0xfbffffff,0xfe9f0000-0xfe9fffff,0xfe800000-0xfe8fffff irq 18 at device 5.0 on pci1 pcib2: irq 18 at device 6.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfea00000-0xfeafffff pcib2: prefetched decode 0xfdf00000-0xfdffffff pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.PCE6 - AE_NOT_FOUND pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x10ec, dev=0x8168, revid=0x02 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 2 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xd800, size 8, enabled pcib2: requested I/O range 0xd800-0xd8ff: in range map[18]: type Memory, range 64, base 0xfeaff000, size 12, enabled pcib2: requested memory range 0xfeaff000-0xfeafffff: good map[20]: type Prefetchable Memory, range 64, base 0xfdff0000, size 16, enabled pcib2: requested memory range 0xfdff0000-0xfdffffff: good pcib0: matched entry for 0.6.INTA pcib0: slot 6 INTA hardwired to IRQ 18 pcib2: slot 0 INTA is routed to irq 18 re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff,0xfdff0000-0xfdffffff irq 18 at device 0.0 on pci2 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xfeaff000 re0: MSI count : 1 re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: bpf attached re0: Ethernet address: 00:21:97:0f:0c:9f ioapic0: routing intpin 18 (PCI IRQ 18) to vector 49 re0: [MPSAFE] re0: [FILTER] atapci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at device 17.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x7000 atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfe7ff800 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 50 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci0 ata2: SATA connect time=0ms ata2: SIGNATURE: 00000101 ata2: ahci_reset devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: SATA connect time=0ms ata3: SIGNATURE: 00000101 ata3: ahci_reset devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci0 ata4: SATA connect status=00000000 ata4: ahci_reset devices=0x0 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci0 ata5: SATA connect status=00000000 ata5: ahci_reset devices=0x0 ata5: [MPSAFE] ata5: [ITHREAD] ohci0: mem 0xfe7fe000-0xfe7fefff irq 16 at device 18.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe7fe000 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 51 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfe7fd000-0xfe7fdfff irq 16 at device 18.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe7fd000 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xfe7ff000-0xfe7ff0ff irq 17 at device 18.2 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe7ff000 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 52 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] ehci0: Dropped interrupts workaround enabled usb2: EHCI version 1.0 usb2: companion controllers, 3 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 6 ports with 6 removable, self powered ohci2: mem 0xfe7fc000-0xfe7fcfff irq 18 at device 19.0 on pci0 ohci2: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe7fc000 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: SMM does not respond, resetting usb3: on ohci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 3 ports with 3 removable, self powered ohci3: mem 0xfe7f7000-0xfe7f7fff irq 18 at device 19.1 on pci0 ohci3: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe7f7000 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: SMM does not respond, resetting usb4: on ohci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 3 ports with 3 removable, self powered ehci1: mem 0xfe7f6800-0xfe7f68ff irq 19 at device 19.2 on pci0 ehci1: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe7f6800 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 53 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] ehci1: Dropped interrupts workaround enabled usb5: EHCI version 1.0 usb5: companion controllers, 3 ports each: usb3 usb4 usb5: on ehci1 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 6 ports with 6 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xff00 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=7f ostat1=7f ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat0=0x7f err=0xff lsb=0xff msb=0xff ata0: stat1=0x7f err=0xff lsb=0xff msb=0xff ata0: reset tp2 stat0=ff stat1=ff devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 ata0: [MPSAFE] ata0: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xe000-0xefff pcib3: memory decode 0xfeb00000-0xfebfffff pcib3: no prefetched decode pcib3: Subtractively decoded bridge. pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x8086, dev=0x1229, revid=0x0c domain=0, bus=3, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfebff000, size 12, enabled pcib3: requested memory range 0xfebff000-0xfebfffff: good map[14]: type I/O Port, range 32, base 0xe800, size 6, enabled pcib3: requested I/O range 0xe800-0xe83f: in range map[18]: type Memory, range 32, base 0xfebc0000, size 17, enabled pcib3: requested memory range 0xfebc0000-0xfebdffff: good pcib3: matched entry for 3.7.INTA pcib3: slot 7 INTA hardwired to IRQ 22 fxp0: port 0xe800-0xe83f mem 0xfebff000-0xfebfffff,0xfebc0000-0xfebdffff irq 22 at device 7.0 on pci3 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfebff000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1229 8086 0040 000c fxp0: Dynamic Standby mode is disabled miibus1: on fxp0 inphy0: PHY 1 on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:02:b3:33:cc:c1 fxp0: [MPSAFE] fxp0: [ITHREAD] ohci4: mem 0xfe7f5000-0xfe7f5fff irq 18 at device 20.5 on pci0 ohci4: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe7f5000 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb6: OHCI version 1.0, legacy support usb6: SMM does not respond, resetting usb6: on ohci4 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 55 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: failed to reset the aux device. acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to vector 56 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 cpu0: on acpi0 cpu0: switching to generic Cx mode acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x810 powernow0: on cpu0 powernow0: STATUS: 0x3104120604180218 powernow0: STATUS: maxfid: 0x18 powernow0: STATUS: maxvid: 0x04 device_attach: powernow0 attach returned 6 cpu1: on acpi0 powernow1: on cpu1 powernow1: STATUS: 0x3104120604180218 powernow1: STATUS: maxfid: 0x18 powernow1: STATUS: maxvid: 0x04 device_attach: powernow1 attach returned 6 ex_isa_identify() atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ahc_isa_probe 0: ioport 0xc00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xd1000-0xd27ff on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices ums0: on uhub0 ums0: 3 buttons and Z dir. Device configuration finished. Reducing kern.maxvnodes 235635 -> 100000 procfs registered lapic: Divisor 2, Frequency 100004269 hz Timecounter "TSC" frequency 3200136328 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 476940MB at ata2-master SATA300 ad4: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queue ad4: Silicon Image check3 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 381554MB at ata3-master SATA300 ad6: 781422768 sectors [775221C/16H/63S] 16 sectors/interrupt 1 depth queue ad6: Silicon Image check1 failed ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 6 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning PCI IRQ 16 to local APIC 1 ioapic0: Assigning PCI IRQ 17 to local APIC 0 ioapic0: Assigning PCI IRQ 18 to local APIC 1 ioapic0: Assigning PCI IRQ 19 to local APIC 0 ioapic0: Assigning PCI IRQ 22 to local APIC 1 GEOM: new disk ad4 GEOM: new disk ad6 Trying to mount root from ufs:/dev/ad4s1a start_init: trying /sbin/init acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x5a acpi: bad write to port 0x000 (8), val 0x7 acpi: bad write to port 0x001 (8), val 0x7 acpi: bad write to port 0x000 (8), val 0x30 acpi: bad read from port 0x001 (8) acpi: bad read from port 0x000 (8) acpi: bad write to port 0x000 (8), val 0xa5 Linux ELF exec handler installed linprocfs registered ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Sun Jan 11 22:52:31 2009 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F17A1065673; Sun, 11 Jan 2009 22:52:31 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D82098FC08; Sun, 11 Jan 2009 22:52:30 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0BMqU0n094906; Sun, 11 Jan 2009 22:52:30 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0BMqU1q094902; Sun, 11 Jan 2009 22:52:30 GMT (envelope-from gavin) Date: Sun, 11 Jan 2009 22:52:30 GMT Message-Id: <200901112252.n0BMqU1q094902@freefall.freebsd.org> To: xxjack12xx@gmail.com, gavin@FreeBSD.org, freebsd-amd64@FreeBSD.org, gavin@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: amd64/130365: [ata] Elitegroup A780GM-A Chipset:AMD 780G&SB700 IDE controller not recognized X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 22:52:31 -0000 Synopsis: [ata] Elitegroup A780GM-A Chipset:AMD 780G&SB700 IDE controller not recognized State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Sun Jan 11 22:50:36 UTC 2009 State-Changed-Why: To submitter: are you able to give the output of "pciconf -lv" for the ATA controller in question? If the machine doesn't have FreeBSD on it at the moment, you can boot the fixit CD or similar to obtain the output of that command Responsible-Changed-From-To: freebsd-amd64->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Sun Jan 11 22:50:36 UTC 2009 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=130365 From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 12 07:40:03 2009 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D642710656FA for ; Mon, 12 Jan 2009 07:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A937E8FC21 for ; Mon, 12 Jan 2009 07:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0C7e3Mq027483 for ; Mon, 12 Jan 2009 07:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0C7e3Ho027482; Mon, 12 Jan 2009 07:40:03 GMT (envelope-from gnats) Date: Mon, 12 Jan 2009 07:40:03 GMT Message-Id: <200901120740.n0C7e3Ho027482@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Gary Byers Cc: Subject: Re: amd64/130355: [kernel] i386_set_fsbase() doesn't seem to set %fs for 32-bit process under 7.1/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gary Byers List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 07:40:04 -0000 The following reply was made to PR amd64/130355; it has been noted by GNATS. From: Gary Byers To: bug-followup@FreeBSD.org, gb@clozure.com Cc: Subject: Re: amd64/130355: [kernel] i386_set_fsbase() doesn't seem to set %fs for 32-bit process under 7.1/amd64 Date: Sun, 11 Jan 2009 23:03:18 -0700 My claim that i386_set_fsbase() changed the value of %fs when used on other amd64 kernels was incorrect. As far as I can tell, there's no 7.1 kernel bug here. From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 12 08:58:40 2009 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 376611065675; Mon, 12 Jan 2009 08:58:40 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0BDB68FC16; Mon, 12 Jan 2009 08:58:40 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0C8wd7s090920; Mon, 12 Jan 2009 08:58:39 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0C8wdmD090916; Mon, 12 Jan 2009 08:58:39 GMT (envelope-from linimon) Date: Mon, 12 Jan 2009 08:58:39 GMT Message-Id: <200901120858.n0C8wdmD090916@freefall.freebsd.org> To: gb@clozure.com, linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org From: linimon@FreeBSD.org X-Mailman-Approved-At: Mon, 12 Jan 2009 12:19:52 +0000 Cc: Subject: Re: amd64/130355: [kernel] i386_set_fsbase() doesn't seem to set %fs for 32-bit process under 7.1/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 08:58:40 -0000 Synopsis: [kernel] i386_set_fsbase() doesn't seem to set %fs for 32-bit process under 7.1/amd64 State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Mon Jan 12 08:58:22 UTC 2009 State-Changed-Why: Closed at submitter's request. http://www.freebsd.org/cgi/query-pr.cgi?pr=130355 From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 12 11:06:48 2009 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEAEB1065674 for ; Mon, 12 Jan 2009 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CABC38FC31 for ; Mon, 12 Jan 2009 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0CB6mnb091922 for ; Mon, 12 Jan 2009 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0CB6mrl091918 for freebsd-amd64@FreeBSD.org; Mon, 12 Jan 2009 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Jan 2009 11:06:48 GMT Message-Id: <200901121106.n0CB6mrl091918@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-amd64@FreeBSD.org X-Mailman-Approved-At: Mon, 12 Jan 2009 12:25:19 +0000 Cc: Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 11:06:49 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/130368 amd64 Switching from xorg to console locks up computer o amd64/130303 amd64 [boot] [patch] FreeBSD 7.1-RELEASE amd64 cannot boot o o amd64/129889 amd64 [boot] The booting process stops at the line mounting o amd64/129721 amd64 [hang] Motherboard K9N2G Neo-FD hangs on boot of 7.0-R o amd64/129667 amd64 [ata] Elitegroup A780GM-A IDE controller not recognize o amd64/129488 amd64 [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o amd64/129426 amd64 [panic] FreeBSD 7.0 crash after subdiskXX: detached o amd64/129315 amd64 [boot] amd64 motherboard: Intel DG965WH motherboard co f amd64/128978 amd64 [install] FreeBSD 6.3 64-bit panics at boot time duri o amd64/128810 amd64 AMD 64 port installation o amd64/128765 amd64 [install] Install CD loads to Install choices but stop o amd64/128686 amd64 [ata] can't detect SATA Disk on 8.0-Current with NF550 o amd64/128524 amd64 No geom documentation for loading gjournal o amd64/128263 amd64 [panic] 2 amd64 dl380 g5 with dual quadcore xeons, 8 a o amd64/128259 amd64 csh(1): "`" crashes csh o amd64/128236 amd64 portsdb -Uu Indexing error f kern/128102 amd64 AsusRock 939N68PV-GLAN not recognized o amd64/127787 amd64 [lor] 3 lock LOR in recent CURRENT o amd64/127640 amd64 GCC will not build shared libraries with -fprofile-gen o amd64/127492 amd64 [zfs] System hang on ZFS input-output o amd64/127484 amd64 [timecounters] Drift problem with FreeBSD 7.0 and 7.1 o amd64/127451 amd64 [scheduler] incorrect load on quad core o amd64/127397 amd64 [amd64] 32bit application on FreeBSD-6.3 amd64 gets SI s amd64/127276 amd64 ldd(1) invokes linux yes o amd64/127129 amd64 mdconfig(8) is core dumping with Segmentation Fault 11 f amd64/125943 amd64 Serial Consoles do not work on amd64 freebsd o amd64/125873 amd64 [smbd] [panic] Repeated kernel panics, trap 12 page fa o amd64/125002 amd64 [install] amd64, SATA hard disks not detected o amd64/124432 amd64 [panic] 7.0-STABLE panic: invalbuf: dirty bufs o amd64/124134 amd64 [kernel] The kernel doesn't follow the calling convent o amd64/123562 amd64 [install] FreeBSD amd64 not installs o amd64/123520 amd64 [ahd] unable to boot from net while using ahd o amd64/123456 amd64 fstat(1): /usr/bin/fstat shows error messages and hang f amd64/123275 amd64 [cbb] [pcmcia] cbb/pcmcia drivers on amd64 failure [re o kern/122782 amd64 [modules] accf_http.ko kernel module is not loadable o amd64/122695 amd64 [cpufreq] Lack of cpufreq control using amd64 eith cor o amd64/122624 amd64 unusable minimal installation of FreeBSD-7.0 o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial o amd64/122468 amd64 Compile problems after upgrading to 7.0 o amd64/122174 amd64 [panic] 7.0 no longer includes "device atpic" so fails o amd64/121590 amd64 [est] [p4tcc] [acpi_perf] setting dev.cpu.0.freq somet o amd64/121439 amd64 [boot] Installation of FreeBSD 7.0 fails: ACPI problem o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, o amd64/119591 amd64 [amd64] [patch] time_t on 64-bit architecture o amd64/117418 amd64 [hang] FreeBSD 6.2 crash on amd64 4400+ with ssh o amd64/117316 amd64 [acpi] ACPI lockups on SuperMicro motherboard o amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A a amd64/117186 amd64 [modules] kldload Unsupported file type on STABLE amd6 s amd64/116689 amd64 [request] support for MSI K9MM-V f amd64/116670 amd64 [ata] onboard SATA RAID1 controllers not supported for o amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on o amd64/116322 amd64 [panic] At start fsck on current, the system panics o amd64/116159 amd64 [panic] Panic while debugging on CURRENT s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/115581 amd64 [Makefile] [patch] -mfancy-math-387 has no effect o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c o amd64/114270 amd64 [cpufreq] cpufreq doesnt work when compiled in to kern o amd64/114111 amd64 [nfs] System crashes while writing on NFS-mounted shar f amd64/113021 amd64 [re] ASUS M2A-VM onboard NIC does not work o amd64/112222 amd64 [libc] 32-bit libc incorrectly converts some FP number f amd64/111992 amd64 [boot] BTX failed - HP Laptop dv2315nr o amd64/110655 amd64 [threads] 32 bit threaded applications crash on amd64 o amd64/110599 amd64 [geli] geli attach to gmirror device hangs and cannot s amd64/108861 amd64 [nve] nve(4) driver on FreeBSD 6.2 AMD64 does not work o amd64/106186 amd64 [panic] panic in swap_pager_swap_init (amd64/smp/6.2-p f amd64/105629 amd64 [re] TrendNet TEG-BUSR 10/100/1000 disables itself on f amd64/105531 amd64 [ata] gigabyte GA-M51GM-S2G / nVidia nForce 430 - does f amd64/105514 amd64 [boot] FreeBSD/amd64 - Fails to boot on HP Pavilion dv o amd64/102716 amd64 ex with no argument in an xterm gets SIGSEGV o amd64/97337 amd64 [dri] xorg reboots system if dri module is enabled o amd64/95888 amd64 [ata] kernel: ad2: TIMEOUT - WRITE_DMA retrying on HP f amd64/94989 amd64 [boot] BTX Halts on Sun Fire X2100 w/6.1-BETA4 (amd64) o amd64/94677 amd64 [panic] panic in amd64 install at non-root user creati o amd64/93961 amd64 [busdma] Problem in bounce buffer handling in sys/amd6 o amd64/92337 amd64 [em] FreeBSD 6.0 Release Intel Pro 1000 MT em1 no buff f amd64/91492 amd64 [boot] BTX halted o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 o amd64/89501 amd64 [install] System crashes on install using ftp on local o amd64/88790 amd64 [panic] kernel panic on first boot (after the FreeBSD o amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not boot with usb o amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron 244 5-STABLE o amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD 6.0-RC1 amd6 o amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powerd results in f amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Areca ARC-1160 r f amd64/86080 amd64 [radeon] [hang] radeon DRI causes system hang on amd64 s amd64/85273 amd64 [install] FreeBSD (NetBSD or OpenBSD) not install on l o amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/ports' and sys o amd64/76136 amd64 [hang] system halts before reboot o amd64/74747 amd64 [panic] System panic on shutdown when process will not o amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdosfs locks up 90 problems total. From owner-freebsd-amd64@FreeBSD.ORG Mon Jan 12 16:23:53 2009 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E16521065673; Mon, 12 Jan 2009 16:23:53 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B4BC88FC1B; Mon, 12 Jan 2009 16:23:53 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (jkim@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0CGNr1m036585; Mon, 12 Jan 2009 16:23:53 GMT (envelope-from jkim@freefall.freebsd.org) Received: (from jkim@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0CGNqhi036581; Mon, 12 Jan 2009 16:23:52 GMT (envelope-from jkim) Date: Mon, 12 Jan 2009 16:23:52 GMT Message-Id: <200901121623.n0CGNqhi036581@freefall.freebsd.org> To: jkim@FreeBSD.org, freebsd-amd64@FreeBSD.org, jkim@FreeBSD.org From: jkim@FreeBSD.org Cc: Subject: Re: amd64/130303: [boot] [patch] FreeBSD 7.1-RELEASE amd64 cannot boot on VIA Nano equipped systems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 16:23:54 -0000 Synopsis: [boot] [patch] FreeBSD 7.1-RELEASE amd64 cannot boot on VIA Nano equipped systems Responsible-Changed-From-To: freebsd-amd64->jkim Responsible-Changed-By: jkim Responsible-Changed-When: Mon Jan 12 16:23:21 UTC 2009 Responsible-Changed-Why: I will take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=130303 From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 13 05:10:01 2009 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4C05106568A for ; Tue, 13 Jan 2009 05:10:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9FEEB8FC0A for ; Tue, 13 Jan 2009 05:10:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0D5A105025510 for ; Tue, 13 Jan 2009 05:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0D5A11l025509; Tue, 13 Jan 2009 05:10:01 GMT (envelope-from gnats) Resent-Date: Tue, 13 Jan 2009 05:10:01 GMT Resent-Message-Id: <200901130510.n0D5A11l025509@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Xiuchao Wu Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CF6F106566B for ; Tue, 13 Jan 2009 05:02:07 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 6B6398FC08 for ; Tue, 13 Jan 2009 05:02:07 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n0D527J0095568 for ; Tue, 13 Jan 2009 05:02:07 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n0D5275X095567; Tue, 13 Jan 2009 05:02:07 GMT (envelope-from nobody) Message-Id: <200901130502.n0D5275X095567@www.freebsd.org> Date: Tue, 13 Jan 2009 05:02:07 GMT From: Xiuchao Wu To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Tue, 13 Jan 2009 05:26:10 +0000 Cc: Subject: amd64/130483: MSI must be disabled when Myricom 10Gbps Card is used on Dell PowerEdge T300 Server X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2009 05:10:02 -0000 >Number: 130483 >Category: amd64 >Synopsis: MSI must be disabled when Myricom 10Gbps Card is used on Dell PowerEdge T300 Server >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jan 13 05:10:01 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Xiuchao Wu >Release: FreeBSD 7.0 >Organization: National University of Singapore >Environment: FreeBSD 7.0/7.1 Release >Description: Computer: Dell PowerEdge T300 Server NICs: Myricom 10G-PCIE-8AL-C OS: FreeBSD 7.0/7.1 Release After I rebuild the kernel (to include NIC driver "mxge") and reboot, kernel panic occurs and the computer is automatically rebooted. After contacting with engineers of Myricom, they suggest to disable message signaled interrupt (MSI) in /boot/loader.conf and these NICs can work now. " hw.pci.enable_msix=0 hw.pci.enable_msi=0 " However, MSI is really very important for high speed data transmission. Huge number of packets generate many interruptions. Considering that Fedora 9 works well on the same computer, it may be a bug of FreeBSD. Below is the screen when kernel panic occurs. ...... p4tcc3: on cpu3 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci3: on pcib1 pcib2: at device 3.0 on pci0 pci4: on pcib2 pcib3: at device 4.0 on pci0 pci5: on pcib3 mxge0: mem 0xd8000000-0xd8ffffff, 0xdfa00000-0xdfafffff irq 16 at device 0.0 on pci5 panic: nexus_add_irq: failed ..... Best Regards, Xiuchao Wu (wuxiuchao@gmail.com) >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 13 10:40:01 2009 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA6B51065676 for ; Tue, 13 Jan 2009 10:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8CE198FC21 for ; Tue, 13 Jan 2009 10:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0DAe1S5012138 for ; Tue, 13 Jan 2009 10:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0DAe169012137; Tue, 13 Jan 2009 10:40:01 GMT (envelope-from gnats) Resent-Date: Tue, 13 Jan 2009 10:40:01 GMT Resent-Message-Id: <200901131040.n0DAe169012137@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Felix J. Ogris" Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D5D7106566B for ; Tue, 13 Jan 2009 10:38:27 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1778FC08 for ; Tue, 13 Jan 2009 10:38:27 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n0DAcQVo066579 for ; Tue, 13 Jan 2009 10:38:26 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n0DAcQx2066577; Tue, 13 Jan 2009 10:38:26 GMT (envelope-from nobody) Message-Id: <200901131038.n0DAcQx2066577@www.freebsd.org> Date: Tue, 13 Jan 2009 10:38:26 GMT From: "Felix J. Ogris" To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Tue, 13 Jan 2009 12:19:19 +0000 Cc: Subject: amd64/130494: netbooting BTX fails on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2009 10:40:02 -0000 >Number: 130494 >Category: amd64 >Synopsis: netbooting BTX fails on amd64 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jan 13 10:40:01 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Felix J. Ogris >Release: 7.1-RELEASE amd64 >Organization: DTS Systeme GmbH >Environment: not possible due to BTX loader issues (see full description below) >Description: Hi, I am trying to netboot 7.1 amd64 on bare metal systems (HP blade class) and within VMware ESXi. In both scenarios I use PXE to boot memdisk from the Syslinux project which then loads a FreeBSD harddisk image. This disk image contains the BTX loader (as created by "bsdlabel -w -B") and the /boot directory from the 7.1-RELEASE-bootonly.iso. Booting this fails with various errors. Either the BTX halts and dumps CPU registers until the machine is reset, or BTX stops after loading text segment and powers off the machine after a while. Booting 7.0-RELEASE amd64 this way works fine, as 7.1-RELEASE i386 and 7.0-RELEASE i386 does. CD boot works fine for all 4 releases. Don't hesitate to contact me by mail if you need further info, dumps, etc. Regards Felix >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 14 02:10:02 2009 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89CF01065674 for ; Wed, 14 Jan 2009 02:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6397F8FC1E for ; Wed, 14 Jan 2009 02:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0E2A2mq011774 for ; Wed, 14 Jan 2009 02:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0E2A2E4011773; Wed, 14 Jan 2009 02:10:02 GMT (envelope-from gnats) Resent-Date: Wed, 14 Jan 2009 02:10:02 GMT Resent-Message-Id: <200901140210.n0E2A2E4011773@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Gary Byers Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ABB3106564A for ; Wed, 14 Jan 2009 02:01:04 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 6BC1D8FC12 for ; Wed, 14 Jan 2009 02:01:04 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n0E2140U006768 for ; Wed, 14 Jan 2009 02:01:04 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n0E214RK006767; Wed, 14 Jan 2009 02:01:04 GMT (envelope-from nobody) Message-Id: <200901140201.n0E214RK006767@www.freebsd.org> Date: Wed, 14 Jan 2009 02:01:04 GMT From: Gary Byers To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: amd64/130526: fsbase issues for i386 processes running on 7.1-RELEASE/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2009 02:10:02 -0000 >Number: 130526 >Category: amd64 >Synopsis: fsbase issues for i386 processes running on 7.1-RELEASE/amd64 >Confidential: no >Severity: critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Jan 14 02:10:01 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Gary Byers >Release: 7.1-RELEASE/amd64 >Organization: Clozure Associates >Environment: FreeBSD boddhi.abq.clozure.com 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: After using i386_set_fsbase() to make the %fs segment register point to a specified linear address, 32-bit processes running on 7.1-RELEASE amd64 can't reliably use %fs to access memory. Exactly when the process loses the ability to use %fs is unclear, but the enclosed example program seems to show that that ability is lost after a call to sleep(). I'm not familiar enough with x8664 system-level architecture to be fully comfortable in describing the symptom, but my limited understanding suggests that the symptom is consistent with the fsbase MSR not being restored correctly. >How-To-Repeat: The attached shell archive contains source to a small C program which seems to demonstrate the problem. (It likely needs to be compiled on a 32-bit FreeBSD system.) The program establishes a signal handler for SIGBUS and SIGSEGV; the handler simply prints some context information and exits. The program then allocates a 100-byte pointer ("p") via malloc() and uses the pointer returned as an argument to i386_set_fsbase(); this should have the effect of making the %fs segment register address the pointer, so the byte or word at %fs:0 is equivalent to p[0]. The program then executes 100 iterations of a loop which stores a 32-bit value at the malloc'ed pointer's address, reads the 32-bit word at %fs:0, sleeps for 1 second, and reads the word at %fs:0 again. After each read of %fs:0, the value read relative to %fs is compared to the value stored at the pointer address; if the values differ, the code calls i386_set_fsbase() to see the adderss it returns by reference matches the pointer address, prints these values, and exits. The program should therefore do little of interest and take about 100 seconds to do so. When run on a 7.1 amd64 release kernel, the program segfaults, usually after sleeping on the first iteration. (So the first attempt to reference memory at %fs:0 succeeded as expected; attempting to read the same value after calling sleep() fails.) This may indicate that the fsbase MSR is not restored correctly after context switch and/or syscall return. >Fix: Unknown. A few days ago, I submitted an invalid bug report (130355) which claimed that this symptom was caused by failure to set %fs to the proper selector on return from i386_set_fsbase() on 7.1/amd64. No amd64 kernel changes the %fs selector in the implementation of i386_set_fsbase; 64-bit kernels do arrange that the "fsbase" MSR is set appropriately. It seems that this works correctly (the test program can use %fs before sleeping on the first iteration), but that the fsbase MSR isn't set correctly (or something like that ...) on syscall return or after context switch, in at least some cases. Patch attached with submission follows: # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # i386_set_fsbase_test.c # echo x - i386_set_fsbase_test.c sed 's/^X//' >i386_set_fsbase_test.c << 'e02ffb4f5ccf0ea67f579a83c1cccce4' X/* This program should be compiled in a 32-bit i386 FreeBSD environment. */ X X#include X#include X#include X#include X#include X#include X#include X X Xvoid Xinstall_signal_handler(int signo, void * handler) X{ X struct sigaction sa; X X sa.sa_sigaction = (void *)handler; X sigfillset(&sa.sa_mask); X sa.sa_flags = SA_SIGINFO; X X sigaction(signo, &sa, NULL); X} X Xvoid *p, *check = NULL; Xint i; Xbool after_sleep = false; X Xvoid Xsignal_handler(int signo, siginfo_t *info, void *context) X{ X i386_get_fsbase(&check); X X fprintf(stderr, "terminating with signal %d on iteration %d, %s sleep, address = 0x%x, p = 0x%x, fsbase = 0x%x\n", X signo, X i, X after_sleep ? "after" : "before", X (uintptr_t)info->si_addr, X (uintptr_t)p, (uintptr_t)check); X exit(5); X X} X X/* return the contents of the first 32-bit word addressed by %fs */ Xunsigned long Xread_fs_contents() X{ X unsigned long res; X X __asm__ volatile ("movl %%fs:0,%0" : "=r" (res)); X return res; X} X X Xmain() X{ X int status; X X install_signal_handler(SIGBUS, signal_handler); X install_signal_handler(SIGSEGV, signal_handler); X p = malloc(100); X status = i386_set_fsbase(p); X if (status != 0) { X perror("i386_set_fsbase"); X exit(1); X } X /* it should now be true that %fs addresses the pointer 'p'; if we X store a 32-bit value at 'p', we should be able to read that X value back via read_fs_contents(), without getting any sort X of bus fault. X This seems to be true of all 32-bit FreeBSD kernels that I've X tried it on and is true of the 64-bit 6.4-RELEASE and 7.0-RELEASE; X it does not seem to be true of the 7.1/amd64-RELEASE kernel. X */ X for (i = 0; i < 100; i++) { X *((unsigned long *)p) = i; X after_sleep = false; X if (read_fs_contents() != i) { X i386_get_fsbase(&check); X fprintf (stderr, "%%fs base may have changed, now 0x%x, should be 0x%x\n",(uintptr_t)check,(uintptr_t)p); X exit(2); X } X sleep(1); X after_sleep = true; X if (read_fs_contents() != i) { X i386_get_fsbase(&check); X fprintf (stderr, "after sleep, %%fs base may have changed, now 0x%x, should be 0x%x\n",(uintptr_t)check,(uintptr_t)p); X exit(3); X } X } X exit(0); X} X e02ffb4f5ccf0ea67f579a83c1cccce4 exit >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 14 07:40:01 2009 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD9411065670 for ; Wed, 14 Jan 2009 07:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AD93E8FC18 for ; Wed, 14 Jan 2009 07:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0E7e1pO098872 for ; Wed, 14 Jan 2009 07:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0E7e1SB098871; Wed, 14 Jan 2009 07:40:01 GMT (envelope-from gnats) Resent-Date: Wed, 14 Jan 2009 07:40:01 GMT Resent-Message-Id: <200901140740.n0E7e1SB098871@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Nadir Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB2AF1065670 for ; Wed, 14 Jan 2009 07:35:59 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id A27EE8FC2B for ; Wed, 14 Jan 2009 07:35:59 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n0E7ZwNa071953 for ; Wed, 14 Jan 2009 07:35:58 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n0E7Zwu8071952; Wed, 14 Jan 2009 07:35:58 GMT (envelope-from nobody) Message-Id: <200901140735.n0E7Zwu8071952@www.freebsd.org> Date: Wed, 14 Jan 2009 07:35:58 GMT From: Nadir To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: amd64/130536: not X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2009 07:40:02 -0000 >Number: 130536 >Category: amd64 >Synopsis: not >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Jan 14 07:40:01 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Nadir >Release: 7.1-RELEASE-amd64 >Organization: Ultel >Environment: 7.1-RELEASE-amd64 >Description: hi. i have problems. i have HP Proliant DL 380 G5 server. when i insert installation cd and boot with ACPI DISABLED MODE my server gives kernel errors. but its not issues with i386 32bit platform. CPU: 2 x INTEL XEON 2.5 GHZ (1333 Mhz) RAM: 10 GB RAM. PC2 5300. ARRAY: SmartArray P400, 8 SAS DISK, (RAID5+online spare) >How-To-Repeat: when boot with ACPI DISABLED MODE >Fix: unknown >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 14 15:55:45 2009 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5D1F10657A0; Wed, 14 Jan 2009 15:55:45 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 89E248FC1B; Wed, 14 Jan 2009 15:55:45 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0EFtjYX097169; Wed, 14 Jan 2009 15:55:45 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0EFtjAs097164; Wed, 14 Jan 2009 15:55:45 GMT (envelope-from gavin) Date: Wed, 14 Jan 2009 15:55:45 GMT Message-Id: <200901141555.n0EFtjAs097164@freefall.freebsd.org> To: nadir@ultel.net, gavin@FreeBSD.org, freebsd-amd64@FreeBSD.org, gavin@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: amd64/130536: not X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2009 15:55:48 -0000 Synopsis: not State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Wed Jan 14 15:54:29 UTC 2009 State-Changed-Why: To submitter: Under amd64, ACPI is usually mandatory. Is there a reason you need to boot with ACPI disabled? Responsible-Changed-From-To: freebsd-amd64->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Wed Jan 14 15:54:29 UTC 2009 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=130536 From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 14 15:17:58 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07E8A1065672 for ; Wed, 14 Jan 2009 15:17:58 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from col0-omc3-s17.col0.hotmail.com (col0-omc3-s17.col0.hotmail.com [65.55.34.156]) by mx1.freebsd.org (Postfix) with ESMTP id DF8618FC27 for ; Wed, 14 Jan 2009 15:17:57 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from COL112-W32 ([65.55.34.135]) by col0-omc3-s17.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 07:09:57 -0800 Message-ID: X-Originating-IP: [217.133.1.92] From: Andrew Hotlab To: Date: Wed, 14 Jan 2009 15:09:57 +0000 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jan 2009 15:09:57.0505 (UTC) FILETIME=[29AC1F10:01C9765A] X-Mailman-Approved-At: Wed, 14 Jan 2009 16:33:36 +0000 Subject: Cross compiling FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2009 15:17:58 -0000 > From: andrew.hotlab@hotmail.com > To: freebsd-questions@freebsd.org > Subject: Builder for many architectures and releases > Date: Sat=2C 10 Jan 2009 02:37:37 +0000 > > [...] I looked for any documentation about setup a FreeBSD builder machin= e which will track sources and build binaries for all the hardware platform= and OS releases I need to support in my network. I have found some interes= ting articles (http://www.onlamp.com/pub/a/bsd/2006/04/13/freebsd-build-sys= tem.html - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/small-= lan.html)=2C but nothing which actually addresses my needs. [...] > At this time=2C I've tried to build RELENG_7_1 for the i386 architecture us= ing an amd64 machine (running RELENG_7_0 for amd64) then=2C exporting /usr/= src and /usr/obj via NFS in read-only mode to target machines=2C I've exper= ienced a lot of troubles trying to install both kernel and world=2C which m= ade impossible for me to install FreeBSD on target i386 machines. Can anyone kindly confirm that it's a supported procedure to compile FreeBS= D for a Tier1 architecture by using another Tier1-architecture machine? May= be I didn't understood documentation or I'm missing some essential steps in= the build process? Andrew P.S.: sorry for this cross-posting=2C but I don't have a clear understand a= bout what list best suits my question! _________________________________________________________________ News=2C entertainment and everything you care about at Live.com. Get it now= ! http://www.live.com/getstarted.aspx= From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 14 21:16:29 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86B161065680 for ; Wed, 14 Jan 2009 21:16:29 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by mx1.freebsd.org (Postfix) with ESMTP id 1B71D8FC1C for ; Wed, 14 Jan 2009 21:16:28 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0ELGKat023034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2009 08:16:21 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n0ELGHEO030025; Thu, 15 Jan 2009 08:16:17 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n0ELGHSl030024; Thu, 15 Jan 2009 08:16:17 +1100 (EST) (envelope-from peter) Date: Thu, 15 Jan 2009 08:16:17 +1100 From: Peter Jeremy To: Andrew Hotlab Message-ID: <20090114211616.GC16116@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-i386@amd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Cross compiling FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2009 21:16:29 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Please wrap your lines before 80 columns] On 2009-Jan-14 15:06:06 +0000, Andrew Hotlab wr= ote: >At this time, I've tried to build RELENG_7_1 for the i386 >architecture using an amd64 machine (running RELENG_7_0 for amd64) >then, exporting /usr/src and /usr/obj via NFS in read-only mode to >target machines, This won't work because install{world,kernel} uses programs (under /usr/obj) that were built to run on the build system (amd64 in your case) and so won't run on the target (i386) system. The supported approach is to NFS mount the target machines onto the build machine and run "make DESTDIR=3D/mount/point install{world,kernel}" on the build machine. Note that this will report errors since NFS cannot handle UFS flags - you will need to manually remove/add schg flags. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --K8nIJk4ghYZn606h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkluViAACgkQ/opHv/APuIe7uwCfY9BGyzbQAIqQBF5FRGFDHGjO /4UAoJaUBdgVy0eyN1PhLww9kzTEJkK5 =MgHu -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- From owner-freebsd-amd64@FreeBSD.ORG Thu Jan 15 04:05:25 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C5E810656BD for ; Thu, 15 Jan 2009 04:05:25 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwqsrv02p.mx.bigpond.com (nschwqsrv02p.mx.bigpond.com [61.9.189.234]) by mx1.freebsd.org (Postfix) with ESMTP id 847468FC13 for ; Thu, 15 Jan 2009 04:05:22 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx01p.mx.bigpond.com ([124.188.162.219]) by nschwmtas06p.mx.bigpond.com with ESMTP id <20090115031917.YIVW3101.nschwmtas06p.mx.bigpond.com@nschwotgx01p.mx.bigpond.com> for ; Thu, 15 Jan 2009 03:19:17 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx01p.mx.bigpond.com with ESMTP id <20090115031913.QJDJ6454.nschwotgx01p.mx.bigpond.com@areilly.bpa.nu> for ; Thu, 15 Jan 2009 03:19:13 +0000 Received: (qmail 53221 invoked by uid 501); 15 Jan 2009 03:18:47 -0000 Date: Thu, 15 Jan 2009 14:18:47 +1100 From: Andrew Reilly To: Peter Jeremy Message-ID: <20090115031847.GA52343@duncan.reilly.home> References: <20090114211616.GC16116@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090114211616.GC16116@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.496EAB31.007E,ss=1,fgs=0 Cc: Andrew Hotlab , freebsd-amd64@freebsd.org, freebsd-i386@amd.org, freebsd-arch@freebsd.org Subject: Re: Cross compiling FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 04:05:25 -0000 On Thu, Jan 15, 2009 at 08:16:17AM +1100, Peter Jeremy wrote: > This won't work because install{world,kernel} uses programs (under > /usr/obj) that were built to run on the build system (amd64 in > your case) and so won't run on the target (i386) system. > > The supported approach is to NFS mount the target machines onto the > build machine and run "make DESTDIR=/mount/point install{world,kernel}" > on the build machine. Note that this will report errors since NFS > cannot handle UFS flags - you will need to manually remove/add schg flags. Is there any reason (apart from using more space on the build machine) not to install to a DESTDIR (not /) on the build machine, and then tar/pax/cpio that tree across to the client system? Presumably something like that must be done for the distribution builds that go into making the CD and DVD images. NetBSD has (had? it's been a while since I looked) a cool mechanism that allowed the whole tree to be built (and "installed" to a DESTDIR) without root permissions, using a variation on install that copied the file as the running user and recorded the intended user/group/mod/flags in an mtree file. Then a subsequent task created a tarball that contained the file contents and the mtree permissions, all as a non-root user. So you don't even need to muck about with root-over-nfs issues for deployment: just log into the client and untar the distribution over the network (as root). Very, very neat, IMO. I used to build embedded i386 NetBSD installations on my amd64 FreeBSD system that way without much in the way of trouble. Haven't had to do it for a while, though, so perhaps it's all changed. I wouldn't hate to discover that FreeBSD can do that too, though... Cheers, Andrew From owner-freebsd-amd64@FreeBSD.ORG Thu Jan 15 05:07:36 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76BCA1065677; Thu, 15 Jan 2009 05:07:36 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 971B18FC18; Thu, 15 Jan 2009 05:07:35 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n0F4hARG072641; Wed, 14 Jan 2009 22:43:10 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n0F4h9dk072640; Wed, 14 Jan 2009 22:43:09 -0600 (CST) (envelope-from brooks) Date: Wed, 14 Jan 2009 22:43:09 -0600 From: Brooks Davis To: Andrew Reilly Message-ID: <20090115044309.GA72611@lor.one-eyed-alien.net> References: <20090114211616.GC16116@server.vk2pj.dyndns.org> <20090115031847.GA52343@duncan.reilly.home> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <20090115031847.GA52343@duncan.reilly.home> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 14 Jan 2009 22:43:10 -0600 (CST) X-Mailman-Approved-At: Thu, 15 Jan 2009 05:50:52 +0000 Cc: freebsd-arch@freebsd.org, freebsd-i386@amd.org, freebsd-amd64@freebsd.org, Andrew Hotlab Subject: Re: Cross compiling FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 05:07:37 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2009 at 02:18:47PM +1100, Andrew Reilly wrote: > On Thu, Jan 15, 2009 at 08:16:17AM +1100, Peter Jeremy wrote: > > This won't work because install{world,kernel} uses programs (under > > /usr/obj) that were built to run on the build system (amd64 in > > your case) and so won't run on the target (i386) system. > >=20 > > The supported approach is to NFS mount the target machines onto the > > build machine and run "make DESTDIR=3D/mount/point install{world,kernel= }" > > on the build machine. Note that this will report errors since NFS > > cannot handle UFS flags - you will need to manually remove/add schg fla= gs. >=20 > Is there any reason (apart from using more space on the build > machine) not to install to a DESTDIR (not /) on the build > machine, and then tar/pax/cpio that tree across to the client > system? Presumably something like that must be done for the > distribution builds that go into making the CD and DVD images. This should work just fine. I use installs to DESTDIR to build images to be run at NFS root file systems. > NetBSD has (had? it's been a while since I looked) a cool > mechanism that allowed the whole tree to be built (and > "installed" to a DESTDIR) without root permissions, using a > variation on install that copied the file as the running user > and recorded the intended user/group/mod/flags in an mtree file. > Then a subsequent task created a tarball that contained the file > contents and the mtree permissions, all as a non-root user. So > you don't even need to muck about with root-over-nfs issues for > deployment: just log into the client and untar the distribution > over the network (as root). Very, very neat, IMO. I used to > build embedded i386 NetBSD installations on my amd64 FreeBSD > system that way without much in the way of trouble. Haven't had > to do it for a while, though, so perhaps it's all changed. I > wouldn't hate to discover that FreeBSD can do that too, > though... We don't have this yet, but lots of people would like to see this (just not quite enough to do it yet :). -- Brooks --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJbr7dXY6L6fI4GtQRAgqSAJwPebbKBrXyApQ+0U7Vudbqh29iWwCeIg9H URW9B8dwCno/i5JjU8YaY2o= =OwxX -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- From owner-freebsd-amd64@FreeBSD.ORG Thu Jan 15 18:03:50 2009 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7B881065672; Thu, 15 Jan 2009 18:03:50 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8C88C8FC12; Thu, 15 Jan 2009 18:03:50 +0000 (UTC) (envelope-from kib@FreeBSD.org) Received: from freefall.freebsd.org (kib@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0FI3okA021689; Thu, 15 Jan 2009 18:03:50 GMT (envelope-from kib@freefall.freebsd.org) Received: (from kib@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0FI3o1I021685; Thu, 15 Jan 2009 18:03:50 GMT (envelope-from kib) Date: Thu, 15 Jan 2009 18:03:50 GMT Message-Id: <200901151803.n0FI3o1I021685@freefall.freebsd.org> To: gb@clozure.com, kib@FreeBSD.org, freebsd-amd64@FreeBSD.org, kib@FreeBSD.org From: kib@FreeBSD.org X-Mailman-Approved-At: Thu, 15 Jan 2009 18:45:14 +0000 Cc: Subject: Re: amd64/130526: fsbase issues for i386 processes running on 7.1-RELEASE/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 18:03:51 -0000 Synopsis: fsbase issues for i386 processes running on 7.1-RELEASE/amd64 State-Changed-From-To: open->analyzed State-Changed-By: kib State-Changed-When: Thu Jan 15 18:03:16 UTC 2009 State-Changed-Why: I have a patch for the issue. Responsible-Changed-From-To: freebsd-amd64->kib Responsible-Changed-By: kib Responsible-Changed-When: Thu Jan 15 18:03:16 UTC 2009 Responsible-Changed-Why: I have a patch for the issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=130526 From owner-freebsd-amd64@FreeBSD.ORG Thu Jan 15 22:47:36 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FB3410656C6; Thu, 15 Jan 2009 22:47: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 9BDC88FC1B; Thu, 15 Jan 2009 22:47:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 271D746B2D; Thu, 15 Jan 2009 17:47:30 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0FMkttK004922; Thu, 15 Jan 2009 17:47:24 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Jung-uk Kim Date: Thu, 15 Jan 2009 17:03:33 -0500 User-Agent: KMail/1.9.7 References: <200901051616.39069.jkim@FreeBSD.org> In-Reply-To: <200901051616.39069.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901151703.33608.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 15 Jan 2009 17:47:24 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8870/Thu Jan 15 15:57:00 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-amd64@freebsd.org Subject: Re: Via Nano CPU: Can boot 7.0-RELEASE-amd64, can't boot 7.1-RELEASE-amd64: "cpu doesn't support long mode" X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 22:47:39 -0000 On Monday 05 January 2009 4:16:36 pm Jung-uk Kim wrote: > On Monday 05 January 2009 02:24 pm, Koen Smits wrote: > > Hello all, > > > > I have some problems getting FreeBSD 7.1-RELEASE amd64 to boot on > > my VIA VB8001, which is a mini-ITX board with the new VIA Nano CPU. > > This CPU is fully 64bit capable. But, when I try to boot Disc1 from > > an IDE CD-ROM I get the error "cpu doesn't support long mode", > > which implies the CPU can't do 64bit, and booting halts asking for > > a kernel. > > The first thing I tried was running ubuntu 8.10 64bit. It installs > > and runs fine. And, trying FreeBSD 7.0-RELEASE Disc1 amd64 also > > boots and installs normally! > > Any help on fixing this is much appreciated. > > See: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=183667 > http://svn.freebsd.org/viewvc/base?view=revision&revision=183823 > > I am not sure removing Via CPU support was intentional, though. Definitely not. At the time the kernel didn't support the Via CPU either. It seems you have fixed both the loader and kernel since, however. -- John Baldwin From owner-freebsd-amd64@FreeBSD.ORG Thu Jan 15 23:09:53 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDB491065674; Thu, 15 Jan 2009 23:09:53 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id 805B08FC14; Thu, 15 Jan 2009 23:09:53 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0FN9och021194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 10:09:50 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n0FN9nOf091640; Fri, 16 Jan 2009 10:09:49 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n0FN9njx091634; Fri, 16 Jan 2009 10:09:49 +1100 (EST) (envelope-from peter) Date: Fri, 16 Jan 2009 10:09:49 +1100 From: Peter Jeremy To: Andrew Hotlab Message-ID: <20090115230949.GD16116@server.vk2pj.dyndns.org> References: <20090114211616.GC16116@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CblX+4bnyfN0pR09" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Cross compiling FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 23:09:55 -0000 --CblX+4bnyfN0pR09 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Jan-15 01:12:03 +0000, Andrew Hotlab wr= ote: >Ok, so I think that in a production environment I should deploy one builde= r machine >for each target architecture I have to support on my network... I'm right? A single build machine can cross-build for multiple environments so you really only need one machine. >One last question: I would expect the same issues if I wish to to support = many >FreeBSD releases running of one single type of architecture? (i.e.: both b= uilder >and targets are amd64 machines, but I run RELENG_7 on the builder and >RELENG_6_4 and RELENG_7_1 on the targets) In general, backward compatibility is supported, so a world built on a RELENG_7 box should be able to be installed by a RELENG_7_1 target (though not by a RELENG_6_4 target). And you can run into he same problem with different i386 variants - if your build machine is built with (eg) P4 options than a generic world built by that box cannot be installed by (eg) a P2 due to instruction differences. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --CblX+4bnyfN0pR09 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklvwj0ACgkQ/opHv/APuIegpACfWKtWC+t/iESLJVjpRQ6mq/lX JPYAmQHdSSR1/AG6M5P0NktdAGB8PkLm =xJ6f -----END PGP SIGNATURE----- --CblX+4bnyfN0pR09-- From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 06:33:06 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A43A1065672; Fri, 16 Jan 2009 06:33:06 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (merlin.alerce.com [64.62.142.94]) by mx1.freebsd.org (Postfix) with ESMTP id E69148FC12; Fri, 16 Jan 2009 06:33:05 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 1976333C62; Thu, 15 Jan 2009 22:06:20 -0800 (PST) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 8B4E233C5B; Thu, 15 Jan 2009 22:06:19 -0800 (PST) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18800.9179.709405.287763@almost.alerce.com> Date: Thu, 15 Jan 2009 22:06:19 -0800 To: John Baldwin In-Reply-To: <200901151703.33608.jhb@freebsd.org> References: <200901051616.39069.jkim@FreeBSD.org> <200901151703.33608.jhb@freebsd.org> X-Mailer: VM 7.19 under Emacs 22.1.50.1 X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Fri, 16 Jan 2009 07:05:03 +0000 Cc: freebsd-amd64@freebsd.org Subject: Re: Via Nano CPU: Can boot 7.0-RELEASE-amd64, can't boot 7.1-RELEASE-amd64: "cpu doesn't support long mode" X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 06:33:06 -0000 John Baldwin writes: > On Monday 05 January 2009 4:16:36 pm Jung-uk Kim wrote: > > On Monday 05 January 2009 02:24 pm, Koen Smits wrote: > > > Hello all, > > > > > > I have some problems getting FreeBSD 7.1-RELEASE amd64 to boot on > > > my VIA VB8001, which is a mini-ITX board with the new VIA Nano CPU. > > > This CPU is fully 64bit capable. But, when I try to boot Disc1 from > > > an IDE CD-ROM I get the error "cpu doesn't support long mode", > > > which implies the CPU can't do 64bit, and booting halts asking for > > > a kernel. > > > The first thing I tried was running ubuntu 8.10 64bit. It installs > > > and runs fine. And, trying FreeBSD 7.0-RELEASE Disc1 amd64 also > > > boots and installs normally! > > > Any help on fixing this is much appreciated. > > > > See: > > > > http://svn.freebsd.org/viewvc/base?view=revision&revision=183667 > > http://svn.freebsd.org/viewvc/base?view=revision&revision=183823 > > > > I am not sure removing Via CPU support was intentional, though. > > Definitely not. At the time the kernel didn't support the Via CPU either. It > seems you have fixed both the loader and kernel since, however. The fix to the loader has a comment about MFC'ing in a week, but there are a bunch of changes to support padlock, MSI, etc... that don't have any such directives. When there isn't an explicit MFC directive with the commit, what does that mean for plans to merge them back to -STABLE? Thanks, g. From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 11:52:41 2009 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B9C11065673; Fri, 16 Jan 2009 11:52:41 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 10A1B8FC19; Fri, 16 Jan 2009 11:52:41 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0GBqeDt061341; Fri, 16 Jan 2009 11:52:40 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0GBqedR061337; Fri, 16 Jan 2009 11:52:40 GMT (envelope-from gavin) Date: Fri, 16 Jan 2009 11:52:40 GMT Message-Id: <200901161152.n0GBqedR061337@freefall.freebsd.org> To: cristobal41@hotmail.com, gavin@FreeBSD.org, freebsd-amd64@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/128102: AsusRock 939N68PV-GLAN not recognized X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 11:52:41 -0000 Synopsis: AsusRock 939N68PV-GLAN not recognized State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Fri Jan 16 11:50:41 UTC 2009 State-Changed-Why: Close, from private correspondance (23 Oct 2008), submitter now has this working. http://www.freebsd.org/cgi/query-pr.cgi?pr=128102 From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 08:41:40 2009 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B13C1065672; Fri, 16 Jan 2009 08:41:40 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id 7CC4D8FC2B; Fri, 16 Jan 2009 08:41:39 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz13 with SMTP id 13so5155316bwz.19 for ; Fri, 16 Jan 2009 00:41:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=YAEQoVT7GNzyxuqW1SNDHZBtvVbXJhG7DWwJEp6RNSY=; b=eHrnRJr+vtmRFQVKwi+YtKTNx7yxK30dEHZR7vymlJ2TikyFHzRuKObNAdMLf2aKw0 WHiyDMU3KcHeyfOM8FoRD7JzXt71I2zjZxOPzdzw2McWhuNQEzOpdO9wk4D+sJfjkHN4 yDko7MxalU9RaKOwr+r7nTgKHRfIGz44C3Rkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=fdZXO7Ll9tSI5F2Tmx80h+h4SxhcpL5NzbSX81sQKFPJEo7B4l3n5hskih0v8OTOqr Tb4guzjFWlHzPUyNI5p8w0HxNOB6x13S3+87UzHdiZ2TeHXRlY38Cdt2QTKBYhvfHfXj dshBcMtXrNOKGfyqxsSsEJ6CYVBPKJldXCbUI= MIME-Version: 1.0 Received: by 10.181.135.5 with SMTP id m5mr764556bkn.87.1232095297847; Fri, 16 Jan 2009 00:41:37 -0800 (PST) Date: Fri, 16 Jan 2009 00:41:37 -0800 Message-ID: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> From: Garrett Cooper To: Hackers freeBSD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 16 Jan 2009 12:22:56 +0000 Cc: "amd64@freebsd.org" Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 08:41:40 -0000 Hi amd64 and Hackers, Uh, I'm really confused why 1) this error (errno => ENOMEM) would occur when I have more than enough free memory (both on x86 and amd64) and 2) why strerror would segfault in the call to errx in the attached sourcefile on amd64 only. Not initializing len causes the second output sample (errno => 14, which is EFAULT). Any ideas? Please CC me if mailing on amd64@ as I'm not subscribed to the list. Thanks, -Garrett /* Program */ #include #include #include #include #include int main() { int mib[4]; size_t len; if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { printf("Errno: %d\n", errno); errx(errno, "Error: %s", strerror(errno)); } printf("%lu\n", len); return 0; } # output for len preset to 0: [gcooper@optimus ~]$ ./test2 Errno: 12 test2: Segmentation fault: 11 (core dumped) [gcooper@optimus ~]$ uname -a FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Sun Jan 11 12:30:31 PST 2009 root@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64 [gcooper@orangebox /usr/home/gcooper]$ ./test Errno: 12 test: Error: Cannot allocate memory [gcooper@orangebox /usr/home/gcooper]$ uname -a FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Sat Jan 3 22:54:52 PST 2009 gcooper@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX i386 # output for len not preset to 0: [gcooper@optimus ~]$ ./test2 Errno: 14 test2: Segmentation fault: 11 (core dumped) From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 08:44:30 2009 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B107106564A; Fri, 16 Jan 2009 08:44:30 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4418FC08; Fri, 16 Jan 2009 08:44:29 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz13 with SMTP id 13so5158414bwz.19 for ; Fri, 16 Jan 2009 00:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hGrcKhFFjIh3K4rcDdNrb8YWRufMl73vZuOz4eomO/E=; b=AvVH3AAhP3tkxAXqhkBnv6OX9ZR/PG5mmDMu9ujwH06Y2BH3bCq5zVHEuMr/imDtXO vflR0kJS5Y66Duth9wbPioPEfr61+fs63WSxz7mDTmjQTNjIo7Bm515aXRs8Us0G3kjb YK8KxvtElwKKxRmQa5uWl7+GcTbNiqkAcat/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fGi1XjJU4A3TUuT795vhTwr6yBFbgAIz3Ci4cjG9piqexfmCZ6DXwYosI+KC1/yerQ nSJZzoG+X4uo7pXyKDq7WdgRONfwIaG7EOM5J8w8KzGBgDU77KQGfdJlXmArXDetHlzQ 7FN8ixzt+w1B+qfttXbSJlKYk0XzsqT4GzuAk= MIME-Version: 1.0 Received: by 10.181.192.10 with SMTP id u10mr758578bkp.185.1232095467960; Fri, 16 Jan 2009 00:44:27 -0800 (PST) In-Reply-To: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> Date: Fri, 16 Jan 2009 00:44:27 -0800 Message-ID: <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> From: Garrett Cooper To: Hackers freeBSD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 16 Jan 2009 12:23:09 +0000 Cc: "amd64@freebsd.org" Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 08:44:30 -0000 On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote: > Hi amd64 and Hackers, > Uh, I'm really confused why 1) this error (errno => ENOMEM) would > occur when I have more than enough free memory (both on x86 and amd64) > and 2) why strerror would segfault in the call to errx in the attached > sourcefile on amd64 only. Not initializing len causes the second > output sample (errno => 14, which is EFAULT). > Any ideas? > Please CC me if mailing on amd64@ as I'm not subscribed to the list. > Thanks, > -Garrett > > /* Program */ > #include > #include > #include > #include > #include > > int > main() { > > int mib[4]; > > size_t len; > > if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { > printf("Errno: %d\n", errno); > errx(errno, "Error: %s", strerror(errno)); > } > > printf("%lu\n", len); > > return 0; > > } > > # output for len preset to 0: > [gcooper@optimus ~]$ ./test2 > Errno: 12 > test2: Segmentation fault: 11 (core dumped) > [gcooper@optimus ~]$ uname -a > FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: > Sun Jan 11 12:30:31 PST 2009 > root@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64 > > [gcooper@orangebox /usr/home/gcooper]$ ./test > Errno: 12 > test: Error: Cannot allocate memory > [gcooper@orangebox /usr/home/gcooper]$ uname -a > FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT > #4: Sat Jan 3 22:54:52 PST 2009 > gcooper@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX > i386 > > # output for len not preset to 0: > [gcooper@optimus ~]$ ./test2 > Errno: 14 > test2: Segmentation fault: 11 (core dumped) Almost forgot -- here are the actual values reported by sysctl(1), just for reference: [gcooper@optimus ~]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax kern.ipc.shmall: 8192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 33554432 [gcooper@orangebox /usr/src/sys]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax kern.ipc.shmall: 8192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 33554432 Thanks, -Garrett From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 08:53:21 2009 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 077F3106564A; Fri, 16 Jan 2009 08:53:21 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id 56EC18FC14; Fri, 16 Jan 2009 08:53:20 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz13 with SMTP id 13so5168807bwz.19 for ; Fri, 16 Jan 2009 00:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tzNojY5j+qIwphmm/13LKzGKsS0ll8qLsfKya9TEXXM=; b=G2Rm+aHz8NIquPxnA/lwXsky4pa7FAdcHL6ZqfI4aR93zL45UXrnLROpuBV8qdHMXk zSlFrrTkUKyO9vS7a/Z/H1QhuokG0F6hAxesHxFCZE+f/XmR0S+LRMQv7qmpEzd06a0e XmLTs7WH1HQhBM86EJs/+iEQrsvo314s0mKwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oXvEQkX1YqcQuoTaPGD5JxqFMRRncGZsfBEwAFFOsluajIfVEu/xSl9m/dEWpgJj3H etKokDR3MGCvccCOn2MF+I3dWW9rByWJH6Zs2T06Tet2z1sRAiu+884b2AYO/XzCJlMm ttPfap4w3/gOqkXjxk+MW/Uis5xgKIs1zUk78= MIME-Version: 1.0 Received: by 10.181.60.13 with SMTP id n13mr771297bkk.39.1232095999355; Fri, 16 Jan 2009 00:53:19 -0800 (PST) In-Reply-To: References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> Date: Fri, 16 Jan 2009 00:53:19 -0800 Message-ID: <7d6fde3d0901160053y22b2f9c9vb37d0f0621c2a7c9@mail.gmail.com> From: Garrett Cooper To: Jacques Fourie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 16 Jan 2009 12:23:18 +0000 Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 08:53:21 -0000 On Fri, Jan 16, 2009 at 12:47 AM, Jacques Fourie wrote: > > You need to initialize len to the number of entries in the mib array. > Try adding 'len = 4' before calling sysctlnametomib() and see if your > issues go away. Ok, that solution works (I think). So, problem 2 down. Now: what about the segfaulting strerror(3) call on amd64 ;\? -Garrett From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 08:55:21 2009 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAB3A106567A; Fri, 16 Jan 2009 08:55:21 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (cl-2958.ham-01.de.sixxs.net [IPv6:2001:6f8:900:b8d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 715508FC12; Fri, 16 Jan 2009 08:55:21 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.14.2/8.14.2) with ESMTP id n0G8tJfh034193; Fri, 16 Jan 2009 11:55:20 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Fri, 16 Jan 2009 11:55:19 +0300 (MSK) From: Maxim Konovalov To: Garrett Cooper In-Reply-To: <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> Message-ID: <20090116115448.A32187@mp2.macomnet.net> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Fri, 16 Jan 2009 12:23:29 +0000 Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 08:55:22 -0000 On Fri, 16 Jan 2009, 00:44-0800, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote: > > Hi amd64 and Hackers, > > Uh, I'm really confused why 1) this error (errno => ENOMEM) would > > occur when I have more than enough free memory (both on x86 and amd64) > > and 2) why strerror would segfault in the call to errx in the attached > > sourcefile on amd64 only. Not initializing len causes the second > > output sample (errno => 14, which is EFAULT). > > Any ideas? - size_t len; + size_t len = 4; -- Maxim Konovalov From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 08:57:49 2009 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76A881065690 for ; Fri, 16 Jan 2009 08:57:49 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id F2E1F8FC0A for ; Fri, 16 Jan 2009 08:57:48 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so890497fgb.35 for ; Fri, 16 Jan 2009 00:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HePQbiZQ3484BaRkY2f44bzExWMH4dA+YbKta370Ep8=; b=LmRJRpLFj7wwq4RwAZC5nmPWIoNqn9vurmzb65iTl4zSzPhKZOZwEyge8jX2qUkIB2 2AMLIHO9x7ZagUNTDWLJhd8bWhEKNkPW8ykVHEkxtZ4UtuwfiYzAJVx+P9fMLx3/zKIt GpWx48xwujo1PH4s6AZ1Nxr2qS83kUXy1qF5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DnW/NMaVaVAwGvHzBaTSuJljoKRoWRcQveyoy0OZoyY8jChvk1duDP2Lo2hx+WSHuM iZZRWjrWn94h4RyoP7kQ1fFb6oXoaKtRJlUDMy6EhepJmiQUeXFY3c4sHQcufkcaA+ye J/6ryPnC+WgYJGXKKlxltyC0c+AUlhjVj/ICM= MIME-Version: 1.0 Received: by 10.86.86.12 with SMTP id j12mr1859683fgb.64.1232095851785; Fri, 16 Jan 2009 00:50:51 -0800 (PST) In-Reply-To: References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> Date: Fri, 16 Jan 2009 10:50:51 +0200 Message-ID: From: Jacques Fourie To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 16 Jan 2009 12:23:40 +0000 Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 08:57:50 -0000 On Fri, Jan 16, 2009 at 10:47 AM, Jacques Fourie wrote: > On Fri, Jan 16, 2009 at 10:44 AM, Garrett Cooper wrote: >> On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote: >>> Hi amd64 and Hackers, >>> Uh, I'm really confused why 1) this error (errno => ENOMEM) would >>> occur when I have more than enough free memory (both on x86 and amd64) >>> and 2) why strerror would segfault in the call to errx in the attached >>> sourcefile on amd64 only. Not initializing len causes the second >>> output sample (errno => 14, which is EFAULT). >>> Any ideas? >>> Please CC me if mailing on amd64@ as I'm not subscribed to the list. >>> Thanks, >>> -Garrett >>> >>> /* Program */ >>> #include >>> #include >>> #include >>> #include >>> #include >>> >>> int >>> main() { >>> >>> int mib[4]; >>> >>> size_t len; >>> >>> if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { >>> printf("Errno: %d\n", errno); >>> errx(errno, "Error: %s", strerror(errno)); >>> } >>> >>> printf("%lu\n", len); >>> >>> return 0; >>> >>> } >>> >>> # output for len preset to 0: >>> [gcooper@optimus ~]$ ./test2 >>> Errno: 12 >>> test2: Segmentation fault: 11 (core dumped) >>> [gcooper@optimus ~]$ uname -a >>> FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: >>> Sun Jan 11 12:30:31 PST 2009 >>> root@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64 >>> >>> [gcooper@orangebox /usr/home/gcooper]$ ./test >>> Errno: 12 >>> test: Error: Cannot allocate memory >>> [gcooper@orangebox /usr/home/gcooper]$ uname -a >>> FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT >>> #4: Sat Jan 3 22:54:52 PST 2009 >>> gcooper@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX >>> i386 >>> >>> # output for len not preset to 0: >>> [gcooper@optimus ~]$ ./test2 >>> Errno: 14 >>> test2: Segmentation fault: 11 (core dumped) >> >> Almost forgot -- here are the actual values reported by sysctl(1), >> just for reference: >> >> [gcooper@optimus ~]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax >> kern.ipc.shmall: 8192 >> kern.ipc.shmmin: 1 >> kern.ipc.shmmax: 33554432 >> >> [gcooper@orangebox /usr/src/sys]$ sysctl kern.ipc.shmall >> kern.ipc.shmmin kern.ipc.shmmax >> kern.ipc.shmall: 8192 >> kern.ipc.shmmin: 1 >> kern.ipc.shmmax: 33554432 >> >> Thanks, >> -Garrett >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > > You need to initialize len to the number of entries in the mib array. > Try adding 'len = 4' before calling sysctlnametomib() and see if your > issues go away. > Sorry, I only scanned through the code without reading the whole message before replying :) Please ignore... From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 08:58:59 2009 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5AA21065767; Fri, 16 Jan 2009 08:58:59 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id 204CF8FC1C; Fri, 16 Jan 2009 08:58:58 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz13 with SMTP id 13so5175193bwz.19 for ; Fri, 16 Jan 2009 00:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=isi9Q67NvNtHgnkzXN2oeP93jB1Lhv7ooINUAzhu6+k=; b=wDzvpuHpCo/tNoe8AdcJ0Q2xsEtHyCGUDewBcnQ894Mra3Ztu2nGBAasWpsUJY86gw MEfglH3IUptkGDyHkLIZEd2BOvmo0cdw69WnGHusO8ih6dD+G1YZVuap8k9ITgTayH6N uxmu3A5/AYg8CLzMhlkb2i5/W36piPmZkhGUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pdN3P3eIIE/Pl5lcqdLuZqC2F+2cW089AneWVeTCsd8wRa84g6+s8LRVL6l7mG/8bc w8J+JpgtvjwrnOBQ/WYorRfIMw4HpcXIA5r9Kn85OsPSvMuvNFb2ANuAoVyBlZ9rEd77 FwEhbQzOuf44koeQe0e5U/LmiDaYHEI+K5A3A= MIME-Version: 1.0 Received: by 10.181.208.11 with SMTP id k11mr775034bkq.19.1232096337822; Fri, 16 Jan 2009 00:58:57 -0800 (PST) In-Reply-To: <49704C13.60505@gmx.de> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <7d6fde3d0901160056y7c395cb1m4675a3957b85f33d@mail.gmail.com> <49704C13.60505@gmx.de> Date: Fri, 16 Jan 2009 00:58:57 -0800 Message-ID: <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> From: Garrett Cooper To: Christoph Mallon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 16 Jan 2009 12:23:55 +0000 Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 08:59:00 -0000 On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon wrote: > Garrett Cooper schrieb: >> >> Good point. I modified the source to do that. >> Thanks, >> -Garrett > > You should reply to all so the discussion stays on the list. Yeah, that was a goofup on my part. Go-go Gmail web interface! -Garrett From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 09:15:35 2009 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 052691065795 for ; Fri, 16 Jan 2009 09:15:35 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1B58FC2A for ; Fri, 16 Jan 2009 09:15:34 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so893114fgb.35 for ; Fri, 16 Jan 2009 01:15:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OMhlaqZMbr/0bphrBOYTN3bAizaMsimrYKcCd8OgqJQ=; b=u3L4Mkv73neQnNE+Kcyx3sZwQwKgPV9pxrbkAUYVKcIicgyawkvYFde5mFnHv6Xj8T 7zOBACG/zQsNw52ic8VxaBkXlgXWQtEO5pqKrvPJSqkaKml1+xnAqkj/7nuBi42qvh/s TvlovZ3N6fL5zvwLEtfpPp3FIVwldX8Ig+RZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tAo6ZWpjl+FgMACKRTkRPhDKDoU5sClcaAC4vwC8p7sJGTOhljnwR7jKxN7nl4hPPD EwYHMHZfT9l+GODPw/Px0HzLIxr5+9/sxscgaj34jM4K+i1PCswz1Li++N2rv0RQ9LAi wz4Dtb4MHhywV8STdaT808x3DJlvgbeLBlLOc= MIME-Version: 1.0 Received: by 10.86.89.20 with SMTP id m20mr1098228fgb.71.1232095641673; Fri, 16 Jan 2009 00:47:21 -0800 (PST) In-Reply-To: <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> Date: Fri, 16 Jan 2009 10:47:21 +0200 Message-ID: From: Jacques Fourie To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 16 Jan 2009 12:24:15 +0000 Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 09:15:36 -0000 On Fri, Jan 16, 2009 at 10:44 AM, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote: >> Hi amd64 and Hackers, >> Uh, I'm really confused why 1) this error (errno => ENOMEM) would >> occur when I have more than enough free memory (both on x86 and amd64) >> and 2) why strerror would segfault in the call to errx in the attached >> sourcefile on amd64 only. Not initializing len causes the second >> output sample (errno => 14, which is EFAULT). >> Any ideas? >> Please CC me if mailing on amd64@ as I'm not subscribed to the list. >> Thanks, >> -Garrett >> >> /* Program */ >> #include >> #include >> #include >> #include >> #include >> >> int >> main() { >> >> int mib[4]; >> >> size_t len; >> >> if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { >> printf("Errno: %d\n", errno); >> errx(errno, "Error: %s", strerror(errno)); >> } >> >> printf("%lu\n", len); >> >> return 0; >> >> } >> >> # output for len preset to 0: >> [gcooper@optimus ~]$ ./test2 >> Errno: 12 >> test2: Segmentation fault: 11 (core dumped) >> [gcooper@optimus ~]$ uname -a >> FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: >> Sun Jan 11 12:30:31 PST 2009 >> root@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64 >> >> [gcooper@orangebox /usr/home/gcooper]$ ./test >> Errno: 12 >> test: Error: Cannot allocate memory >> [gcooper@orangebox /usr/home/gcooper]$ uname -a >> FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT >> #4: Sat Jan 3 22:54:52 PST 2009 >> gcooper@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX >> i386 >> >> # output for len not preset to 0: >> [gcooper@optimus ~]$ ./test2 >> Errno: 14 >> test2: Segmentation fault: 11 (core dumped) > > Almost forgot -- here are the actual values reported by sysctl(1), > just for reference: > > [gcooper@optimus ~]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax > kern.ipc.shmall: 8192 > kern.ipc.shmmin: 1 > kern.ipc.shmmax: 33554432 > > [gcooper@orangebox /usr/src/sys]$ sysctl kern.ipc.shmall > kern.ipc.shmmin kern.ipc.shmmax > kern.ipc.shmall: 8192 > kern.ipc.shmmin: 1 > kern.ipc.shmmax: 33554432 > > Thanks, > -Garrett > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > You need to initialize len to the number of entries in the mib array. Try adding 'len = 4' before calling sysctlnametomib() and see if your issues go away. From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 09:19:43 2009 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD00910656BD for ; Fri, 16 Jan 2009 09:19:43 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id EE44E8FC1D for ; Fri, 16 Jan 2009 09:19:42 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 16 Jan 2009 08:53:01 -0000 Received: from p54A3E7DB.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.231.219] by mail.gmx.net (mp056) with SMTP; 16 Jan 2009 09:53:01 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18o3C8/cC0oIDTtXxxDZ+wo92yQJK/699sT82PYiv iRjmRnbw9N3jjG Message-ID: <49704AEC.3080709@gmx.de> Date: Fri, 16 Jan 2009 09:53:00 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> In-Reply-To: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 X-Mailman-Approved-At: Fri, 16 Jan 2009 12:24:30 +0000 Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 09:19:44 -0000 Garrett Cooper schrieb: > Hi amd64 and Hackers, > Uh, I'm really confused why 1) this error (errno => ENOMEM) would > occur when I have more than enough free memory (both on x86 and amd64) > and 2) why strerror would segfault in the call to errx in the attached > sourcefile on amd64 only. Not initializing len causes the second > output sample (errno => 14, which is EFAULT). > Any ideas? > Please CC me if mailing on amd64@ as I'm not subscribed to the list. > Thanks, > -Garrett len is not uninitialised. This leads to undefined behaviour. Anything can happen. Probably the syscall overwrites parts of the stack because len has some (random) high value. > /* Program */ > #include > #include > #include > #include > #include > > int > main() { > > int mib[4]; > > size_t len; > > if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { > printf("Errno: %d\n", errno); > errx(errno, "Error: %s", strerror(errno)); The use of errno is wrong. printf might change errno. Store the errno into a local variable before you do any call, which might modify it. From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 09:19:51 2009 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71B7B1065690; Fri, 16 Jan 2009 09:19:51 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-fx0-f11.google.com (mail-fx0-f11.google.com [209.85.220.11]) by mx1.freebsd.org (Postfix) with ESMTP id AA4098FC21; Fri, 16 Jan 2009 09:19:50 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fxm4 with SMTP id 4so349744fxm.19 for ; Fri, 16 Jan 2009 01:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kPTPDqfHts3ODwEQ3MbARfr8AopC4ZO86FKlSQSx7js=; b=XHb5NPny/VYC9QykZFxJ4xvmCrpO12P0LKDyGGT5bApM1FEC409Omg6UjpZU21+NM7 bRoelMAho2TagmdcKn09dtuO9hzm30WIE5KOxSuHresfwYqRfQnBnVwPJNgh8Oxyfljb dER4uyLP1pLRItSb/9v/WI07t9oIsNIZLi02A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aislnV7c99deiO3XVL5BSHfjUeMNdEeJeNh0H8G+pK47CqrrVDbjiAg+6HigsrO7Jd bd4C2KEiuq4jxvM8+q2w/WBzISNZIRhY8y9lG+pesFCN4yw/odu8NdieYh+YuxQnlwCL VIus+AwyBk4f42WwRRuxGSITf1c6G6VC0GzHw= MIME-Version: 1.0 Received: by 10.181.199.16 with SMTP id b16mr771011bkq.142.1232097589763; Fri, 16 Jan 2009 01:19:49 -0800 (PST) In-Reply-To: <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <7d6fde3d0901160056y7c395cb1m4675a3957b85f33d@mail.gmail.com> <49704C13.60505@gmx.de> <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> Date: Fri, 16 Jan 2009 01:19:49 -0800 Message-ID: <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> From: Garrett Cooper To: Christoph Mallon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 16 Jan 2009 12:24:39 +0000 Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 09:19:52 -0000 On Fri, Jan 16, 2009 at 12:58 AM, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon > wrote: >> Garrett Cooper schrieb: >>> >>> Good point. I modified the source to do that. >>> Thanks, >>> -Garrett >> >> You should reply to all so the discussion stays on the list. > > Yeah, that was a goofup on my part. Go-go Gmail web interface! > -Garrett Hmmm... looks like the strerror issue it could be a serious bug: #include #include #include int main() { struct stat sb; int o_errno; if (stat("/some/file/that/doesn't/exist", &sb) != 0) { o_errno = errno; printf("Errno: %d\n", errno); err(errno, "%s", strerror(o_errno)); } return 0; } [gcooper@optimus ~]$ ./badfile Errno: 2 badfile: Segmentation fault: 11 (core dumped) I rebuilt my kernel and installed it, and I rebuilt world, but haven't installed it yet though, so let me reboot the amd64 machine and see what happens (may be a mismatched ABI issue)... Cheers, -Garrett From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 09:38:20 2009 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B517E10656D9 for ; Fri, 16 Jan 2009 09:38:20 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 191248FC0C for ; Fri, 16 Jan 2009 09:38:19 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 16 Jan 2009 09:38:18 -0000 Received: from p54A3E7DB.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.231.219] by mail.gmx.net (mp046) with SMTP; 16 Jan 2009 10:38:18 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+j4g4acfqj1tOvhWSSKqOJjmun4qhgh7CQjnDg4t dFqZbVvF84PYZd Message-ID: <4970558A.1010705@gmx.de> Date: Fri, 16 Jan 2009 10:38:18 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <7d6fde3d0901160056y7c395cb1m4675a3957b85f33d@mail.gmail.com> <49704C13.60505@gmx.de> <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> In-Reply-To: <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 X-Mailman-Approved-At: Fri, 16 Jan 2009 12:24:48 +0000 Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 09:38:21 -0000 Garrett Cooper schrieb: > On Fri, Jan 16, 2009 at 12:58 AM, Garrett Cooper wrote: >> On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon >> wrote: >>> Garrett Cooper schrieb: >>>> Good point. I modified the source to do that. >>>> Thanks, >>>> -Garrett >>> You should reply to all so the discussion stays on the list. >> Yeah, that was a goofup on my part. Go-go Gmail web interface! >> -Garrett > > Hmmm... looks like the strerror issue it could be a serious bug: > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > err(errno, "%s", strerror(o_errno)); You are still using the wrong errno. Also err() itself prints the error string using strerror(). There might be some interference when the result of one call to strerror() (your call) is used after another call to strerror() (err() internally). I doubt there is a bug in the library, otherwise we would see many bugreports of segfaults on AMD64. From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 09:50:16 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B25D106571B; Fri, 16 Jan 2009 09:50:16 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from mx1.cksoft.de (mx1.cksoft.de [62.111.66.10]) by mx1.freebsd.org (Postfix) with ESMTP id DC89A8FC26; Fri, 16 Jan 2009 09:50:15 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from m.cksoft.de (m.cksoft.de [192.168.64.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTP id 1A1612EB862; Fri, 16 Jan 2009 10:32:48 +0100 (CET) Received: from amavis.ahti.cksoft.de (amavis.ahti.cksoft.de [IPv6:2001:4068:10:1::201]) by m.cksoft.de (Postfix) with ESMTP id 36816ED04B; Fri, 16 Jan 2009 10:32:48 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([192.168.64.204]) by amavis.ahti.cksoft.de (amavis.ahti.cksoft.de [192.168.64.201]) (amavisd-new, port 10024) with ESMTP id wFKyk25yLDZm; Fri, 16 Jan 2009 10:32:40 +0100 (CET) Received: from tapio.cksoft.de (tapio.cksoft.de [IPv6:2001:4068:10:1:218:8bff:fe76:5932]) by m.cksoft.de (Postfix) with ESMTP id 3213BECFB4; Fri, 16 Jan 2009 10:32:39 +0100 (CET) Received: by tapio.cksoft.de (Postfix, from userid 1000) id A6732B8DC; Fri, 16 Jan 2009 10:32:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tapio.cksoft.de (Postfix) with ESMTP id 98DCDB809; Fri, 16 Jan 2009 10:32:39 +0100 (CET) Date: Fri, 16 Jan 2009 10:32:39 +0100 (CET) From: Christian Kratzer X-X-Sender: ck@tapio.cksoft.de To: Andrew Hotlab In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 16 Jan 2009 12:24:59 +0000 Cc: freebsd-i386@amd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Cross compiling FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Kratzer List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 09:50:17 -0000 Hi, On Wed, 14 Jan 2009, Andrew Hotlab wrote: > >> From: andrew.hotlab@hotmail.com >> To: freebsd-questions@freebsd.org >> Subject: Builder for many architectures and releases >> Date: Sat, 10 Jan 2009 02:37:37 +0000 >> >> [...] I looked for any documentation about setup a FreeBSD builder machine which will track sources and build binaries for all the hardware platform and OS releases I need to support in my network. I have found some interesting articles (http://www.onlamp.com/pub/a/bsd/2006/04/13/freebsd-build-system.html - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/small-lan.html), but nothing which actually addresses my needs. [...] >> > > At this time, I've tried to build RELENG_7_1 for the i386 architecture using an amd64 machine (running RELENG_7_0 for amd64) then, exporting /usr/src and /usr/obj via NFS in read-only mode to target machines, I've experienced a lot of troubles trying to install both kernel and world, which made impossible for me to install FreeBSD on target i386 machines. > Can anyone kindly confirm that it's a supported procedure to compile FreeBSD for a Tier1 architecture by using another Tier1-architecture machine? Maybe I didn't understood documentation or I'm missing some essential steps in the build process? as you already found out this does not work as the crossbuild process will build the native host tools in /usr/obj and the target system binaries in /usr/obj/i386. On recent RELENG_7 or HEAD machines you should be able to build in an i386 chroot. This would produce a clean /usr/obj you can copy to your i386 machines and install from there. The hack to enable building in an i386 chroot is to set UNAME_m and UNAME_p to i386. I use following in the chroots .cshrc setenv UNAME_m i386 setenv UNAME_p i386 This will avoid any crossbuild magic and you will be able to build as if on an i386 machine. This of course only works for the amd64, i386 combination. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Schwarzwaldstr. 31 Phone: +49 7452 889 135 D-71131 Jettingen Fax: +49 7452 889 136 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 10:24:47 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47719106564A; Fri, 16 Jan 2009 10:24:47 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from col0-omc1-s7.col0.hotmail.com (col0-omc1-s7.col0.hotmail.com [65.55.34.17]) by mx1.freebsd.org (Postfix) with ESMTP id 254238FC0C; Fri, 16 Jan 2009 10:24:46 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from COL112-W78 ([65.55.34.9]) by col0-omc1-s7.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 02:24:46 -0800 Message-ID: X-Originating-IP: [217.133.1.92] From: Andrew Hotlab To: Date: Fri, 16 Jan 2009 10:24:46 +0000 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jan 2009 10:24:46.0794 (UTC) FILETIME=[A7B852A0:01C977C4] X-Mailman-Approved-At: Fri, 16 Jan 2009 12:25:09 +0000 Cc: freebsd-i386@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: RE: Cross compiling FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 10:24:47 -0000 > Date: Fri=2C 16 Jan 2009 10:32:39 +0100 > From: ck-lists@cksoft.de > > On Wed=2C 14 Jan 2009=2C Andrew Hotlab wrote: > >> At this time=2C I've tried to build RELENG_7_1 for the i386 architecture= using an amd64 >> machine (running RELENG_7_0 for amd64) then=2C exporting /usr/src and /u= sr/obj via >> NFS in read-only mode to target machines=2C I've experienced a lot of tr= oubles trying to >> install both kernel and world=2C which made impossible for me to install= FreeBSD on >> target i386 machines. >> Can anyone kindly confirm that it's a supported procedure to compile Fre= eBSD for >> a Tier1 architecture by using another Tier1-architecture machine? Maybe = I didn't >> understood documentation or I'm missing some essential steps in the buil= d process? > > as you already found out this does not work as the crossbuild process > will build the native host tools in /usr/obj and the target system > binaries in /usr/obj/i386. > > On recent RELENG_7 or HEAD machines you should be able to build > in an i386 chroot. This would produce a clean /usr/obj you > can copy to your i386 machines and install from there. > Sorry for my stupid question: I'll do the right thing if I'll build an i386= jail chroot/jail on the amd64 builder host with the following commands? (grabbed from the FreeBSD H= andbook) # cd /usr/src # make buildworld TARGET=3Di386 # make installworld TARGET=3Di386 DESTDIR=3D/path-to-jail # cd etc/ # make distribution DESTDIR=3D/path-to-jail # mount -t devfs devfs /path-to-jail/dev > The hack to enable building in an i386 chroot is to set UNAME_m > and UNAME_p to i386. I use following in the chroots .cshrc > > setenv UNAME_m i386 > setenv UNAME_p i386 > > This will avoid any crossbuild magic and you will be able to build > as if on an i386 machine. > > This of course only works for the amd64=2C i386 combination. Wonderful=2C I'll try this as soon as possible. Thank you! _________________________________________________________________ News=2C entertainment and everything you care about at Live.com. Get it now= ! http://www.live.com/getstarted.aspx= From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 10:57:02 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7F1D10657C3; Fri, 16 Jan 2009 10:57:02 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from mx1.cksoft.de (mx1.cksoft.de [62.111.66.10]) by mx1.freebsd.org (Postfix) with ESMTP id 550B28FC12; Fri, 16 Jan 2009 10:57:02 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from m.cksoft.de (m.cksoft.de [192.168.64.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTP id C8BAA2EB925; Fri, 16 Jan 2009 11:57:00 +0100 (CET) Received: from amavis.ahti.cksoft.de (amavis.ahti.cksoft.de [IPv6:2001:4068:10:1::201]) by m.cksoft.de (Postfix) with ESMTP id 6DC50ED02C; Fri, 16 Jan 2009 11:56:59 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([192.168.64.204]) by amavis.ahti.cksoft.de (amavis.ahti.cksoft.de [192.168.64.201]) (amavisd-new, port 10024) with ESMTP id YXBu0kI3xcO2; Fri, 16 Jan 2009 11:56:55 +0100 (CET) Received: from tapio.cksoft.de (tapio.cksoft.de [IPv6:2001:4068:10:1:218:8bff:fe76:5932]) by m.cksoft.de (Postfix) with ESMTP id AB21CED029; Fri, 16 Jan 2009 11:56:55 +0100 (CET) Received: by tapio.cksoft.de (Postfix, from userid 1000) id 84288B8DC; Fri, 16 Jan 2009 11:56:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tapio.cksoft.de (Postfix) with ESMTP id 767EEB809; Fri, 16 Jan 2009 11:56:55 +0100 (CET) Date: Fri, 16 Jan 2009 11:56:55 +0100 (CET) From: Christian Kratzer X-X-Sender: ck@tapio.cksoft.de To: Andrew Hotlab In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 16 Jan 2009 12:25:17 +0000 Cc: freebsd-i386@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: RE: Cross compiling FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Kratzer List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 10:57:03 -0000 Hi, On Fri, 16 Jan 2009, Andrew Hotlab wrote: > Sorry for my stupid question: I'll do the right thing if I'll build an i386 jail chroot/jail on the > amd64 builder host with the following commands? (grabbed from the FreeBSD Handbook) > # cd /usr/src > # make buildworld TARGET=i386 > # make installworld TARGET=i386 DESTDIR=/path-to-jail > # cd etc/ > # make distribution DESTDIR=/path-to-jail > # mount -t devfs devfs /path-to-jail/dev yes that should do it but I think you can skip the cd etc/ part. make distribution should work from /usr/src >> The hack to enable building in an i386 chroot is to set UNAME_m >> and UNAME_p to i386. I use following in the chroots .cshrc >> >> setenv UNAME_m i386 >> setenv UNAME_p i386 >> >> This will avoid any crossbuild magic and you will be able to build >> as if on an i386 machine. >> >> This of course only works for the amd64, i386 combination. > Wonderful, I'll try this as soon as possible. Thank you! let us know if it works out. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Schwarzwaldstr. 31 Phone: +49 7452 889 135 D-71131 Jettingen Fax: +49 7452 889 136 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer From owner-freebsd-amd64@FreeBSD.ORG Fri Jan 16 15:28:17 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44C2C10656C3; Fri, 16 Jan 2009 15:28:17 +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 147B68FC0A; Fri, 16 Jan 2009 15:28:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 9A35B46B23; Fri, 16 Jan 2009 10:28:16 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0GFS4KI011368; Fri, 16 Jan 2009 10:28:10 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: hartzell@alerce.com Date: Fri, 16 Jan 2009 09:28:15 -0500 User-Agent: KMail/1.9.7 References: <200901151703.33608.jhb@freebsd.org> <18800.9179.709405.287763@almost.alerce.com> In-Reply-To: <18800.9179.709405.287763@almost.alerce.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901160928.16069.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 16 Jan 2009 10:28:10 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8871/Thu Jan 15 23:16:59 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-amd64@freebsd.org Subject: Re: Via Nano CPU: Can boot 7.0-RELEASE-amd64, can't boot 7.1-RELEASE-amd64: "cpu doesn't support long mode" X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 15:28:17 -0000 On Friday 16 January 2009 1:06:19 am George Hartzell wrote: > John Baldwin writes: > > On Monday 05 January 2009 4:16:36 pm Jung-uk Kim wrote: > > > On Monday 05 January 2009 02:24 pm, Koen Smits wrote: > > > > Hello all, > > > > > > > > I have some problems getting FreeBSD 7.1-RELEASE amd64 to boot on > > > > my VIA VB8001, which is a mini-ITX board with the new VIA Nano CPU. > > > > This CPU is fully 64bit capable. But, when I try to boot Disc1 from > > > > an IDE CD-ROM I get the error "cpu doesn't support long mode", > > > > which implies the CPU can't do 64bit, and booting halts asking for > > > > a kernel. > > > > The first thing I tried was running ubuntu 8.10 64bit. It installs > > > > and runs fine. And, trying FreeBSD 7.0-RELEASE Disc1 amd64 also > > > > boots and installs normally! > > > > Any help on fixing this is much appreciated. > > > > > > See: > > > > > > http://svn.freebsd.org/viewvc/base?view=revision&revision=183667 > > > http://svn.freebsd.org/viewvc/base?view=revision&revision=183823 > > > > > > I am not sure removing Via CPU support was intentional, though. > > > > Definitely not. At the time the kernel didn't support the Via CPU either. It > > seems you have fixed both the loader and kernel since, however. > > The fix to the loader has a comment about MFC'ing in a week, but there > are a bunch of changes to support padlock, MSI, etc... that don't have > any such directives. > > When there isn't an explicit MFC directive with the commit, what does > that mean for plans to merge them back to -STABLE? Nothing, sometimes a developer forgets them, or sometimes they will key off one reminder to merge an entire set of related commits. And sometimes we decide not to merge something we set a reminder for. -- John Baldwin From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 17 01:25:53 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E61A10656C7; Sat, 17 Jan 2009 01:25:53 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from col0-omc1-s13.col0.hotmail.com (col0-omc1-s13.col0.hotmail.com [65.55.34.23]) by mx1.freebsd.org (Postfix) with ESMTP id 446FB8FC12; Sat, 17 Jan 2009 01:25:53 +0000 (UTC) (envelope-from andrew.hotlab@hotmail.com) Received: from COL112-W17 ([65.55.34.9]) by col0-omc1-s13.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jan 2009 17:25:53 -0800 Message-ID: X-Originating-IP: [217.133.1.92] From: Andrew Hotlab To: Date: Sat, 17 Jan 2009 01:25:53 +0000 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jan 2009 01:25:53.0465 (UTC) FILETIME=[89F79A90:01C97842] X-Mailman-Approved-At: Sat, 17 Jan 2009 01:52:45 +0000 Cc: freebsd-i386@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arch@freebsd.org Subject: RE: Cross compiling FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2009 01:25:57 -0000 > Date: Fri=2C 16 Jan 2009 11:56:55 +0100 > From: ck-lists@cksoft.de > > On Fri=2C 16 Jan 2009=2C Andrew Hotlab wrote: > >> Sorry for my stupid question: I'll do the right thing if I'll build an i= 386 jail chroot/jail on the >> amd64 builder host with the following commands? (grabbed from the FreeBS= D Handbook) >> # cd /usr/src >> # make buildworld TARGET=3Di386 >> # make installworld TARGET=3Di386 DESTDIR=3D/path-to-jail >> # cd etc/ >> # make distribution DESTDIR=3D/path-to-jail >> # mount -t devfs devfs /path-to-jail/dev > > yes that should do it but I think you can skip the cd etc/ part. > make distribution should work from /usr/src > >>> The hack to enable building in an i386 chroot is to set UNAME_m >>> and UNAME_p to i386. I use following in the chroots .cshrc >>> [...] >>> This of course only works for the amd64=2C i386 combination. >> Wonderful=2C I'll try this as soon as possible. Thank you! > > let us know if it works out. I've build and exported RELENG_7_0 into an i386 jail running on amd64 hardw= are=2C then I mounted sources and binaries on a RELENG_6_4/i386 machine and I have been a= ble to successfully upgrade without any trouble!! (only some warnings were display= ed installing the kernel=2C but that's a correct behaviour of the upgrade procedure=2C as= pointed out in this post: http://lists.freebsd.org/pipermail/freebsd-current/2005-November/0579= 63.html) Thank you so much=2C Christian! I'm thinking that it would be a great thing to prepare some materials expla= ining the methods for maintaining a managed FreeBSD infrastructure in a corporate production = environment. A lot of sysadmins are afraid that they'll have to spend so much time in soft= ware management tasks if they put FreeBSD in production for business applications=2C but it= seems that only a little of knowledge is required to manage such and environment obtaining a good TC= O. At present time I'm too much engaged with a lot of projects to be able to p= roduce any docs=2C but I'll surely advocate FreeBSD in such business scenarios! _________________________________________________________________ More than messages=96check out the rest of the Windows Live=99. http://www.microsoft.com/windows/windowslive/= From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 17 13:40:14 2009 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57C821065672 for ; Sat, 17 Jan 2009 13:40:14 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 1816C8FC21 for ; Sat, 17 Jan 2009 13:40:14 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 979F06D43F; Sat, 17 Jan 2009 13:23:49 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 7AD5E844EF; Sat, 17 Jan 2009 14:23:49 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Garrett Cooper References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> Date: Sat, 17 Jan 2009 14:23:49 +0100 In-Reply-To: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> (Garrett Cooper's message of "Fri, 16 Jan 2009 00:41:37 -0800") Message-ID: <86wscuyska.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2009 13:40:14 -0000 Garrett Cooper writes: > #include > #include > #include > #include > #include You should always put your sys includes before your non-sys includes, and in any case, should always come first. > printf("Errno: %d\n", errno); > errx(errno, "Error: %s", strerror(errno)); In addition to what everybody else said, errno is not an appropriate value for errx's first argument. Use 1 or EXIT_FAILURE (or one of the macros defined in , but I wouldn't recommend it). Also, you probably want to use err(), not errx(), and *always* compile with -Wall -Wextra, and unless you're going to run gdb on your program, -O2 (which enables additional code analysis) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 17 22:16:29 2009 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 152A21065677; Sat, 17 Jan 2009 22:16:29 +0000 (UTC) (envelope-from mbsd@pacbell.net) Received: from nlpi015.prodigy.net (nlpi015.sbcis.sbc.com [207.115.36.44]) by mx1.freebsd.org (Postfix) with ESMTP id BA1998FC08; Sat, 17 Jan 2009 22:16:28 +0000 (UTC) (envelope-from mbsd@pacbell.net) Received: from antec (adsl-99-22-93-85.dsl.pltn13.sbcglobal.net [99.22.93.85]) (authenticated bits=0) by nlpi015.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n0HM5WRs009370; Sat, 17 Jan 2009 16:05:52 -0600 Date: Sat, 17 Jan 2009 14:05:33 -0800 (PST) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= To: Garrett Cooper In-Reply-To: <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> Message-ID: <20090117140506.A2568@antec.home> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <7d6fde3d0901160056y7c395cb1m4675a3957b85f33d@mail.gmail.com> <49704C13.60505@gmx.de> <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "amd64@freebsd.org" , Hackers freeBSD , Christoph Mallon Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2009 22:16:29 -0000 Hi Garrett, On Fri, 16 Jan 2009, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 12:58 AM, Garrett Cooper wrote: >> On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon >> wrote: >>> Garrett Cooper schrieb: >>>> >>>> Good point. I modified the source to do that. >>>> Thanks, >>>> -Garrett >>> >>> You should reply to all so the discussion stays on the list. >> >> Yeah, that was a goofup on my part. Go-go Gmail web interface! >> -Garrett > > Hmmm... looks like the strerror issue it could be a serious bug: Add #include . Without it you don't get the strerror() prototype, so the return value defaults to an int. Thus the compiler will truncate the pointer value to junk. The crash happens when formatting the output. Compile with -Wall and pay attention to warnings (or use -Werror) to catch these things. $.02, /Mikko > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > err(errno, "%s", strerror(o_errno)); > } > > return 0; > > } > > [gcooper@optimus ~]$ ./badfile > Errno: 2 > badfile: Segmentation fault: 11 (core dumped) > > I rebuilt my kernel and installed it, and I rebuilt world, but > haven't installed it yet though, so let me reboot the amd64 machine > and see what happens (may be a mismatched ABI issue)... > Cheers, > -Garrett > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" >