From owner-freebsd-sparc64@FreeBSD.ORG Sun Jul 8 02:54:36 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76F031065672 for ; Sun, 8 Jul 2012 02:54:36 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 240AC8FC12 for ; Sun, 8 Jul 2012 02:54:36 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id q682sZRn013164 for ; Sat, 7 Jul 2012 22:54:35 -0400 (EDT) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.4 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id q682sZju013163 for freebsd-sparc64@freebsd.org; Sat, 7 Jul 2012 22:54:35 -0400 (EDT) (envelope-from lidl) Date: Sat, 7 Jul 2012 22:54:35 -0400 From: Kurt Lidl To: freebsd-sparc64@freebsd.org Message-ID: <20120708025435.GA12487@pix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: zfs booting feedback X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 02:54:36 -0000 I built a full 9.0-stable distribution on Friday night, and got to play with installing it on a spare Netra T1-105 today. Mostly I was interested in testing out the integrated ZFS boot support that was commited recently. First of all -- it works! Thanks very much to all who made it possible! After working through a couple of nits in my script that installs it all, I've got a fully functioning, ZFS-only sparc64 machine. Nice. The zfsboot bootblock's warning about not being able to open non-existant devices are pretty extranous, but other than that, it seems to function OK. The other thing that seems wrong is the 'bootpath="zfs:zroot:"' output -- notice the trailing ":" in the output, that's not there in the /boot/loader.conf file. And finally, the device attachment messages for da0 and cd0 seem to have gotten interspersed in the output on the kernel. A little confusing, but not the end of the world. Serial console capture from a boot is below. -Kurt ok boot disk Resetting ... Netra t1 (UltraSPARC-IIi 440MHz), No Keyboard OpenBoot 3.10.27 ME, 1024 MB memory installed, Serial #14313546. Ethernet address 8:0:20:da:68:4a, Host ID: 80da684a. Initializing Memory Executing last command: boot disk Boot device: /pci@1f,0/pci@1,1/scsi@2/disk@0,0 File and args: >> FreeBSD/sparc64 ZFS boot block Boot path: /pci@1f,0/pci@1,1/scsi@2/disk@0,0:a Consoles: Open Firmware console HDrive not ready ofwd_open: Could not open disk2: Drive not ready ofwd_open: Could not open disk3: Drive not ready ofwd_open: Could not open disk4: Drive not ready ofwd_open: Could not open disk5: Drive not ready ofwd_open: Could not open disk6: Drive not ready ofwd_open: Could not open disk7: Drive not ready ofwd_open: Could not open disk8: Drive not ready ofwd_open: Could not open disk9: FreeBSD/sparc64 ZFS enabled bootstrap loader, Revision 1.0 (lidl@spork.pix.net, Fri Jul 6 21:43:11 EDT 2012) bootpath="zfs:zroot:" Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0xb979d8+0xa9108 syms=[0x8+0xc7638+0x8+0xb8cec] /boot/kernel/zfs.ko text=0x20c498 data=0x5980+0x16f20 syms=[0x8+0x16968] loading required module 'opensolaris' /boot/kernel/opensolaris.ko text=0x2e48 data=0x2c8+0x2030 syms=[0x8+0xd50+0x8+0x90c] /boot/kernel/geom_mirror.ko text=0x37a10 data=0x5a0+0x18 syms=[0x8+0x1650+0x8+0x1159] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... jumping to kernel entry at 0xc0098000. Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-STABLE #0: Fri Jul 6 23:03:53 EDT 2012 lidl@spork.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64 real memory = 1073741824 (1024 MB) avail memory = 1021321216 (974 MB) cpu0: Sun Microsystems UltraSparc-IIi Processor (440.02 MHz CPU) kbd0 at kbdmux0 ctl: CAM Target Layer loaded nexus0: pcib0: mem 0x1fe00000000-0x1fe0000ffff,0x1fe01000000-0x1fe010000ff irq 2032,2030,2031,2021 on nexus0 pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 66MHz pcib0: DVMA map: 0xc0000000 to 0xc3ffffff 8192 entries pcib0: [GIANT-LOCKED] pci0: on pcib0 pcib1: at device 1.1 on pci0 pci1: on pcib1 ebus0: mem 0xf0000000-0xf0ffffff,0xf1000000-0xf17fffff at device 1.0 on pci1 pcib2: at device 1.0 on pci0 pci2: on pcib2 pcib3: at device 1.0 on pci2 pci3: on pcib3 pcib4: at device 15.0 on pci3 pci4: on pcib4 auxio0: addr 0x1400726000-0x1400726003,0x1400728000-0x1400728003,0x140072a000-0x140072a003,0x140072c000-0x140072c003,0x140072f000-0x140072f003 on ebus0 ebus0: addr 0x1400724000-0x1400724003 irq 37 (no driver attached) ebus0: addr 0x1400724000-0x1400724003 irq 37 (no driver attached) ebus0: addr 0x1400504000-0x1400504002 (no driver attached) uart0: <16550 or compatible> addr 0x14003803f8-0x14003803ff irq 28 on ebus0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> addr 0x14003602f8-0x14003602ff irq 20 on ebus0 ebus0: addr 0x1400340278-0x1400340287,0x140030015c-0x140030015d,0x1400700000-0x140070000f irq 34 (no driver attached) ebus0: addr 0x14003203f0-0x14003203f7,0x1400706000-0x140070600f,0x1400720000-0x1400720003 irq 39 (no driver attached) eeprom0: addr 0x1400000000-0x1400001fff on ebus0 eeprom0: model mk48t59 ebus0: addr 0x1000000000-0x10000fffff (no driver attached) ebus0: addr 0x1400200000-0x140020003f irq 4 (no driver attached) ebus0: addr 0x1400200040 (no driver attached) ebus0: addr 0x1400722000-0x1400722003 (no driver attached) ebus0: addr 0x1000400000-0x10005fffff (no driver attached) ebus0: addr 0x1000800000-0x10009fffff (no driver attached) ebus0: addr 0x1400600000-0x1400600003 irq 40 (no driver attached) ebus0: addr 0x1400100000-0x1400100003 irq 27 (no driver attached) ebus0: addr 0x1400400000-0x1400400063 (no driver attached) hme0: mem 0xe0000000-0xe0007fff at device 1.1 on pci1 miibus0: on hme0 ukphy0: PHY 0 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ukphy1: PHY 1 on miibus0 ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hme0: Ethernet address: 08:00:20:da:68:4a sym0: <875> port 0xc00000-0xc000ff mem 0xe0008000-0xe00080ff,0xe000a000-0xe000afff at device 2.0 on pci1 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking hme1: mem 0xe0010000-0xe0017fff at device 3.1 on pci1 miibus1: on hme1 ukphy2: PHY 0 on miibus1 ukphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hme1: Ethernet address: 08:00:20:da:68:4b atapci0: port 0x1000-0x1007,0x1008-0x100b,0x1010-0x1017,0x1018-0x101b,0x1020-0x102f at device 14.0 on pci3 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 pci4: at device 0.0 (no driver attached) hme2: mem 0x2800000-0x2807fff at device 0.1 on pci4 miibus2: on hme2 ukphy3: PHY 1 on miibus2 ukphy3: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hme2: Ethernet address: 08:00:20:ce:7d:9d pci4: at device 1.0 (no driver attached) hme3: mem 0x4800000-0x4807fff at device 1.1 on pci4 miibus3: on hme3 ukphy4: PHY 1 on miibus3 ukphy4: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hme3: Ethernet address: 08:00:20:ce:7d:9e pci4: at device 2.0 (no driver attached) hme4: mem 0x6800000-0x6807fff at device 2.1 on pci4 miibus4: on hme4 ukphy5: PHY 1 on miibus4 ukphy5: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hme4: Ethernet address: 08:00:20:ce:7d:9f pci4: at device 3.0 (no driver attached) hme5: mem 0x8800000-0x8807fff at device 3.1 on pci4 miibus5: on hme5 ukphy6: PHY 1 on miibus5 ukphy6: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hme5: Ethernet address: 08:00:20:ce:7d:a0 nexus0: type unknown (no driver attached) ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. Consider tuning vm.kmem_size and vm.kmem_size_max in /boot/loader.conf. ZFS filesystem version 5 ZFS storage pool version 28 Timecounter "tick" frequency 440024812 Hz quality 1000 Event timer "tick" frequency 440024812 Hz quality 1000 Timecounters tick every 1.000 msec da0 at sym0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 16, cd0 at ata3 bus 0 scbus2 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: cd present [249910 x 2048 byte records] 16bit) da0: Command Queueing enabled da0: 17274MB (35378533 512 byte sectors: 255H 63S/T 2202C) da1 at sym0 bus 0 scbus0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit) da1: Command Queueing enabled da1: 17274MB (35378533 512 byte sectors: 255H 63S/T 2202C) GEOM_MIRROR: Device mirror/gswap launched (1/2). GEOM_MIRROR: Device gswap: rebuilding provider da1b. Trying to mount root from zfs:zroot []... From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 9 09:50:01 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42BA2106564A; Mon, 9 Jul 2012 09:50:01 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id ED1F78FC14; Mon, 9 Jul 2012 09:50:00 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1SoAbP-0002vm-Um; Mon, 09 Jul 2012 10:50:00 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SoAbP-0007e6-Lw; Mon, 09 Jul 2012 10:49:59 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q699nxC9052989; Mon, 9 Jul 2012 10:49:59 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q699nxPl052988; Mon, 9 Jul 2012 10:49:59 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Mon, 9 Jul 2012 10:49:59 +0100 From: Anton Shterenlikht To: Marius Strobl Message-ID: <20120709094958.GB52954@mech-cluster241.men.bris.ac.uk> References: <20120619104247.GA13630@mech-cluster241.men.bris.ac.uk> <20120630121634.GA94551@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120630121634.GA94551@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: x11@freebsd.org, freebsd-sparc64@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: graphics/libGL regression on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 09:50:01 -0000 On Sat, Jun 30, 2012 at 02:16:34PM +0200, Marius Strobl wrote: > On Tue, Jun 19, 2012 at 11:42:47AM +0100, Anton Shterenlikht wrote: > > On sparc64 r235474, > > updating from libGL-7.4.4 to 7.6.1 I get: > > There are several problems preventing Xorg bits to build on sparc64 > (and powerpc) since the update to 7.5.2. First, make sure you have a > ports tree with graphics/libdrm/Makefile rev. 1.25. Then apply the > following patches: > http://people.freebsd.org/~bapt/fix-hal-on-sparc64.diff > http://people.freebsd.org/~marius/dri_libGL_libdrm.diff > > According to a quick test, the old server works fine with both the > mach64 and the sunffb driver on sparc64. When running `Xorg -configure` > you need to manually fix the resulting configuration file though > as any device on the PCI bus not being mach64 compatible is detected > as a radeon chip. > However, while the new server selected with WITH_NEW_XORG builds > just fine on sparc64 with these patches, it doesn't work there. For > mach64, there isn't any indication in the log why this doesn't work > besides "no screens found", although the configuration is correct, > libdrm is built without KMS support and the mach64 being detected. > For sunffb, it just segfaults. > > Marius Is there a PR on this? I'd like to track it. I'm sorry, but I don't have the skill or time to experiment with this. I guess I wouldn't upgrade until this is resolved. Thanks anyway -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 9 11:07:20 2012 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 609CB106566C for ; Mon, 9 Jul 2012 11:07:20 +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 4A3DA8FC18 for ; Mon, 9 Jul 2012 11:07:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q69B7K9g075555 for ; Mon, 9 Jul 2012 11:07:20 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q69B7Jbw075553 for freebsd-sparc64@FreeBSD.org; Mon, 9 Jul 2012 11:07:19 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Jul 2012 11:07:19 GMT Message-Id: <201207091107.q69B7Jbw075553@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 11:07:20 -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 sparc/164227 sparc64 [boot] Can't boot 9.0-RELEASE/sparc64 on Blade 1500 o sparc/164226 sparc64 [cd] Data corruption on 9.0-RELEASE when reading from o sparc/162513 sparc64 mpt(4), mptutil(8) reports variable, erroneous drive i o sparc/141918 sparc64 [ehci] ehci_interrupt: unrecoverable error, controller s sparc/139134 sparc64 kernel output corruption s sparc/107087 sparc64 [hang] system is hung during boot from CD o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 9 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 9 13:04:52 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5CC981065676; Mon, 9 Jul 2012 13:04:52 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id E007B8FC1B; Mon, 9 Jul 2012 13:04:51 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q69D4Vde067273; Mon, 9 Jul 2012 15:04:31 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q69D4VFU067272; Mon, 9 Jul 2012 15:04:31 +0200 (CEST) (envelope-from marius) Date: Mon, 9 Jul 2012 15:04:31 +0200 From: Marius Strobl To: Anton Shterenlikht Message-ID: <20120709130430.GN63893@alchemy.franken.de> References: <20120619104247.GA13630@mech-cluster241.men.bris.ac.uk> <20120630121634.GA94551@alchemy.franken.de> <20120709094958.GB52954@mech-cluster241.men.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120709094958.GB52954@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.4.2.3i Cc: miwi@freebsd.org, x11@freebsd.org, freebsd-sparc64@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: graphics/libGL regression on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 13:04:52 -0000 On Mon, Jul 09, 2012 at 10:49:59AM +0100, Anton Shterenlikht wrote: > On Sat, Jun 30, 2012 at 02:16:34PM +0200, Marius Strobl wrote: > > On Tue, Jun 19, 2012 at 11:42:47AM +0100, Anton Shterenlikht wrote: > > > On sparc64 r235474, > > > updating from libGL-7.4.4 to 7.6.1 I get: > > > > There are several problems preventing Xorg bits to build on sparc64 > > (and powerpc) since the update to 7.5.2. First, make sure you have a > > ports tree with graphics/libdrm/Makefile rev. 1.25. Then apply the > > following patches: > > http://people.freebsd.org/~bapt/fix-hal-on-sparc64.diff > > http://people.freebsd.org/~marius/dri_libGL_libdrm.diff > > > > According to a quick test, the old server works fine with both the > > mach64 and the sunffb driver on sparc64. When running `Xorg -configure` > > you need to manually fix the resulting configuration file though > > as any device on the PCI bus not being mach64 compatible is detected > > as a radeon chip. > > However, while the new server selected with WITH_NEW_XORG builds > > just fine on sparc64 with these patches, it doesn't work there. For > > mach64, there isn't any indication in the log why this doesn't work > > besides "no screens found", although the configuration is correct, > > libdrm is built without KMS support and the mach64 being detected. > > For sunffb, it just segfaults. > > > > Marius > > Is there a PR on this? I'd like to track it. No, not currently; I'm waiting for bapt@ to complete a -exp-run for the options fix and to commit that patch and on feedback from miwi@ regarding the patch for fixing the dri, libGL and libdrm ports on powerpc and sparc64. Marius From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 9 14:00:21 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7539E1065670 for ; Mon, 9 Jul 2012 14:00:21 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 942828FC0C for ; Mon, 9 Jul 2012 14:00:20 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q69E0JIA067500; Mon, 9 Jul 2012 16:00:19 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q69E0JjY067499; Mon, 9 Jul 2012 16:00:19 +0200 (CEST) (envelope-from marius) Date: Mon, 9 Jul 2012 16:00:19 +0200 From: Marius Strobl To: Kurt Lidl Message-ID: <20120709140019.GA67276@alchemy.franken.de> References: <20120708025435.GA12487@pix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120708025435.GA12487@pix.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: zfs booting feedback X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 14:00:21 -0000 On Sat, Jul 07, 2012 at 10:54:35PM -0400, Kurt Lidl wrote: > I built a full 9.0-stable distribution on Friday night, and got to play > with installing it on a spare Netra T1-105 today. Mostly I was > interested in testing out the integrated ZFS boot support that > was commited recently. > > First of all -- it works! Thanks very much to all who made it possible! > > After working through a couple of nits in my script that installs it all, > I've got a fully functioning, ZFS-only sparc64 machine. Nice. > > The zfsboot bootblock's warning about not being able to open non-existant > devices are pretty extranous, but other than that, it seems to function OK. That's more or less a cosmetic problem for now; there's no standard Open Firmware method allowing to test whether the device corresponding to a (automatically) created device alias actually exists short of trying to open it, with OFW causing at least the "Drive not ready" part on its own. There are some Sun specific extensions to the default methods whose names sound like they could be of some help here. I haven't gotten around to actually test whether this is the case or whether they actually exist in all OFW implementations of all sun4u models. If the aliases were artificially created via the `nvalias` command ("disk9" sounds a bit unusual for the automatically created ones) you can get rid of the none existing ones via `nvunalias` (needs a `reset-all` or power-cycle to take effect). > > The other thing that seems wrong is the 'bootpath="zfs:zroot:"' > output -- notice the trailing ":" in the output, that's not there in > the /boot/loader.conf file. I'm not really sure about this one; actually that's the bootpath created and internally used by the machine independent ZFS boot bits. I've never seen an x86 machine booting from ZFS so maybe it's just omitted there. > And finally, the device attachment messages for da0 and cd0 seem to > have gotten interspersed in the output on the kernel. A little confusing, > but not the end of the world. That still is an architecture independent problem with the console output, even with PRINTF_BUFR_SIZE=128 ... Marius From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 9 17:00:22 2012 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58483106566B for ; Mon, 9 Jul 2012 17:00:22 +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 427BE8FC14 for ; Mon, 9 Jul 2012 17:00:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q69H0Mka027827 for ; Mon, 9 Jul 2012 17:00:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q69H0MUT027826; Mon, 9 Jul 2012 17:00:22 GMT (envelope-from gnats) Date: Mon, 9 Jul 2012 17:00:22 GMT Message-Id: <201207091700.q69H0MUT027826@freefall.freebsd.org> To: freebsd-sparc64@FreeBSD.org From: Kurt Lidl Cc: Subject: Re: sparc64/164226: [cd] Data corruption on 9.0-RELEASE when reading from CDROM X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kurt Lidl List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 17:00:22 -0000 The following reply was made to PR sparc64/164226; it has been noted by GNATS. From: Kurt Lidl To: bug-followup@FreeBSD.org, cpghost@cordula.ws Cc: Subject: Re: sparc64/164226: [cd] Data corruption on 9.0-RELEASE when reading from CDROM Date: Mon, 09 Jul 2012 12:44:58 -0400 I built a 9.0-STABLE distribution on Friday (Fri Jul 6 21:43:11 EDT 2012), including building a .iso (make release). I then burned the resulting .iso onto a disks, and successfully booted from, and installed from that iso image on a netra-t1. I had no problems with DMA issues on the local DVD drive. (I replaced the CD-ROM in the machine with a slim-line DVD years ago.) So, I have successfully tested the patches referred to in this PR, I believe it can closed. -Kurt From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 10 05:45:56 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CE69106564A; Tue, 10 Jul 2012 05:45:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4C42A8FC0A; Tue, 10 Jul 2012 05:45:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6A5jtIw095677; Tue, 10 Jul 2012 01:45:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6A5jtE1095672; Tue, 10 Jul 2012 05:45:55 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 05:45:55 GMT Message-Id: <201207100545.q6A5jtE1095672@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 05:45:56 -0000 TB --- 2012-07-10 04:39:59 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 04:39:59 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 04:39:59 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-10 04:39:59 - cleaning the object tree TB --- 2012-07-10 04:39:59 - cvsupping the source tree TB --- 2012-07-10 04:39:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-10 04:41:35 - building world TB --- 2012-07-10 04:41:35 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 04:41:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 04:41:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 04:41:35 - SRCCONF=/dev/null TB --- 2012-07-10 04:41:35 - TARGET=sparc64 TB --- 2012-07-10 04:41:35 - TARGET_ARCH=sparc64 TB --- 2012-07-10 04:41:35 - TZ=UTC TB --- 2012-07-10 04:41:35 - __MAKE_CONF=/dev/null TB --- 2012-07-10 04:41:35 - cd /src TB --- 2012-07-10 04:41:35 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 04:41:36 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 05:41:59 UTC 2012 TB --- 2012-07-10 05:41:59 - generating LINT kernel config TB --- 2012-07-10 05:41:59 - cd /src/sys/sparc64/conf TB --- 2012-07-10 05:41:59 - /usr/bin/make -B LINT TB --- 2012-07-10 05:41:59 - cd /src/sys/sparc64/conf TB --- 2012-07-10 05:41:59 - /usr/sbin/config -m LINT TB --- 2012-07-10 05:41:59 - building LINT kernel TB --- 2012-07-10 05:41:59 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 05:41:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 05:41:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 05:41:59 - SRCCONF=/dev/null TB --- 2012-07-10 05:41:59 - TARGET=sparc64 TB --- 2012-07-10 05:41:59 - TARGET_ARCH=sparc64 TB --- 2012-07-10 05:41:59 - TZ=UTC TB --- 2012-07-10 05:41:59 - __MAKE_CONF=/dev/null TB --- 2012-07-10 05:41:59 - cd /src TB --- 2012-07-10 05:41:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 05:41:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tx_ht.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_tdma.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_sysctl.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_rx.c -I/src/sys/dev/ath cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath_rx_edma.c -I/src/sys/dev/ath cc1: warnings being treated as errors /src/sys/dev/ath/if_ath_rx_edma.c: In function 'ath_edma_rxfifo_flush': /src/sys/dev/ath/if_ath_rx_edma.c:543: warning: unused variable 'bf' [-Wunused-variable] *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 05:45:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 05:45:55 - ERROR: failed to build LINT kernel TB --- 2012-07-10 05:45:55 - 3120.60 user 547.45 system 3955.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 10 10:20:11 2012 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 993B5106564A for ; Tue, 10 Jul 2012 10:20:11 +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 832038FC19 for ; Tue, 10 Jul 2012 10:20:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6AAKBs1085560 for ; Tue, 10 Jul 2012 10:20:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6AAKBvp085559; Tue, 10 Jul 2012 10:20:11 GMT (envelope-from gnats) Date: Tue, 10 Jul 2012 10:20:11 GMT Message-Id: <201207101020.q6AAKBvp085559@freefall.freebsd.org> To: freebsd-sparc64@FreeBSD.org From: Marius Strobl Cc: Subject: Re: sparc64/164226: [cd] Data corruption on 9.0-RELEASE when reading from CDROM X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marius Strobl List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 10:20:11 -0000 The following reply was made to PR sparc64/164226; it has been noted by GNATS. From: Marius Strobl To: Kurt Lidl Cc: bug-followup@FreeBSD.org Subject: Re: sparc64/164226: [cd] Data corruption on 9.0-RELEASE when reading from CDROM Date: Tue, 10 Jul 2012 12:10:59 +0200 On Mon, Jul 09, 2012 at 05:00:22PM +0000, Kurt Lidl wrote: > The following reply was made to PR sparc64/164226; it has been noted by GNATS. > > From: Kurt Lidl > To: bug-followup@FreeBSD.org, cpghost@cordula.ws > Cc: > Subject: Re: sparc64/164226: [cd] Data corruption on 9.0-RELEASE when reading > from CDROM > Date: Mon, 09 Jul 2012 12:44:58 -0400 > > I built a 9.0-STABLE distribution on Friday > (Fri Jul 6 21:43:11 EDT 2012), including building a .iso > (make release). > > I then burned the resulting .iso onto a disks, and successfully booted > from, and installed from that iso image on a netra-t1. > > I had no problems with DMA issues on the local DVD > drive. (I replaced the CD-ROM in the machine with a slim-line > DVD years ago.) > > So, I have successfully tested the patches referred to in this > PR, I believe it can closed. > What's in the tree now is just a work around but the underlying problem still exists and is yet to be solved so it's appropriate to leave this PR in an open state. I'm not sure what's the best assignee though; as it turned out later this problem isn't sparc64-specific at all. As it's ATA_CAM related mav@ would be best, but he unfortunately doesn't seem to be interested that much in fixing it ... Marius From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 10 11:27:06 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 818011065670; Tue, 10 Jul 2012 11:27:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 50A878FC0A; Tue, 10 Jul 2012 11:27:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6ABR534081367; Tue, 10 Jul 2012 07:27:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6ABR5rc081366; Tue, 10 Jul 2012 11:27:05 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 11:27:05 GMT Message-Id: <201207101127.q6ABR5rc081366@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 11:27:06 -0000 TB --- 2012-07-10 10:19:41 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 10:19:41 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 10:19:41 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-10 10:19:41 - cleaning the object tree TB --- 2012-07-10 10:20:37 - cvsupping the source tree TB --- 2012-07-10 10:20:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-10 10:21:11 - building world TB --- 2012-07-10 10:21:11 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 10:21:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 10:21:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 10:21:11 - SRCCONF=/dev/null TB --- 2012-07-10 10:21:11 - TARGET=sparc64 TB --- 2012-07-10 10:21:11 - TARGET_ARCH=sparc64 TB --- 2012-07-10 10:21:11 - TZ=UTC TB --- 2012-07-10 10:21:11 - __MAKE_CONF=/dev/null TB --- 2012-07-10 10:21:11 - cd /src TB --- 2012-07-10 10:21:11 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 10:21:12 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 11:23:02 UTC 2012 TB --- 2012-07-10 11:23:02 - generating LINT kernel config TB --- 2012-07-10 11:23:02 - cd /src/sys/sparc64/conf TB --- 2012-07-10 11:23:02 - /usr/bin/make -B LINT TB --- 2012-07-10 11:23:02 - cd /src/sys/sparc64/conf TB --- 2012-07-10 11:23:02 - /usr/sbin/config -m LINT TB --- 2012-07-10 11:23:02 - building LINT kernel TB --- 2012-07-10 11:23:02 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 11:23:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 11:23:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 11:23:02 - SRCCONF=/dev/null TB --- 2012-07-10 11:23:02 - TARGET=sparc64 TB --- 2012-07-10 11:23:02 - TARGET_ARCH=sparc64 TB --- 2012-07-10 11:23:02 - TZ=UTC TB --- 2012-07-10 11:23:02 - __MAKE_CONF=/dev/null TB --- 2012-07-10 11:23:02 - cd /src TB --- 2012-07-10 11:23:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 11:23:02 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 11:27:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 11:27:05 - ERROR: failed to build LINT kernel TB --- 2012-07-10 11:27:05 - 3139.87 user 574.82 system 4044.06 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 10 16:54:36 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12375106564A for ; Tue, 10 Jul 2012 16:54:36 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2588FC0A for ; Tue, 10 Jul 2012 16:54:35 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id q6AGsX0x099996; Tue, 10 Jul 2012 12:54:33 -0400 (EDT) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.4 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id q6AGsX7s099995; Tue, 10 Jul 2012 12:54:33 -0400 (EDT) (envelope-from lidl) Date: Tue, 10 Jul 2012 12:54:33 -0400 From: Kurt Lidl To: Marius Strobl Message-ID: <20120710165433.GA98707@pix.net> References: <20120708025435.GA12487@pix.net> <20120709140019.GA67276@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120709140019.GA67276@alchemy.franken.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org Subject: Re: zfs booting feedback X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 16:54:36 -0000 On Mon, Jul 09, 2012 at 04:00:19PM +0200, Marius Strobl wrote: > On Sat, Jul 07, 2012 at 10:54:35PM -0400, Kurt Lidl wrote: > > I built a full 9.0-stable distribution on Friday night, and got to play > > with installing it on a spare Netra T1-105 today. Mostly I was > > interested in testing out the integrated ZFS boot support that > > was commited recently. > > > > First of all -- it works! Thanks very much to all who made it possible! > > > > After working through a couple of nits in my script that installs it all, > > I've got a fully functioning, ZFS-only sparc64 machine. Nice. > > > > The zfsboot bootblock's warning about not being able to open non-existant > > devices are pretty extranous, but other than that, it seems to function OK. > > That's more or less a cosmetic problem for now; there's no standard > Open Firmware method allowing to test whether the device corresponding > to a (automatically) created device alias actually exists short of > trying to open it, with OFW causing at least the "Drive not ready" > part on its own. There are some Sun specific extensions to the > default methods whose names sound like they could be of some help > here. I haven't gotten around to actually test whether this is the > case or whether they actually exist in all OFW implementations of > all sun4u models. > If the aliases were artificially created via the `nvalias` command > ("disk9" sounds a bit unusual for the automatically created ones) > you can get rid of the none existing ones via `nvunalias` (needs > a `reset-all` or power-cycle to take effect). All the disks that were probed were part of the normally defined devices on the machine. I only have two devices defined in my nvramrc: ok nvramrc type devalias rootdisk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 devalias rootmirror /pci@1f,0/pci@1,1/scsi@2/disk@1,0 And I have the system configured to boot from "rootdisk rootmirror". Here's the full output of a 'devalias' from the prom on the machine: ok devalias cdrom1 /pci@1f,0/pci@1,1/scsi@2/disk@6,0:f cdrom /pci@1f,0/pci@1/pci@1/ide@e/cdrom@2:f ide-disk /pci@1f,0/pci@1/pci@1/ide@e/disk@0:f ide-cdrom /pci@1f,0/pci@1/pci@1/ide@e/cdrom@2:f ide /pci@1f,0/pci@1/pci@1/ide@e rootmirror /pci@1f,0/pci@1,1/scsi@2/disk@1,0 rootdisk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 userprom2 /pci@1f,0/pci@1,1/ebus@1/flashprom@10,800000 userprom1 /pci@1f,0/pci@1,1/ebus@1/flashprom@10,400000 i2c-cs2 /pci@1f,0/pci@1,1/ebus@1/i2c@14,100000 i2c /pci@1f,0/pci@1,1/ebus@1/i2c@14,600000 systemprom /pci@1f,0/pci@1,1/ebus@1/flashprom@10,0 pcic /pci@1f,0/pci@1/pci@1 pcib /pci@1f,0/pci@1,1 pcia /pci@1f,0/pci@1 ebus /pci@1f,0/pci@1,1/ebus@1 net2 /pci@1f,0/pci@1,1/network@3,1 net /pci@1f,0/pci@1,1/network@1,1 floppy /pci@1f,0/pci@1,1/ebus@1/fdthree disk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 cdrom /pci@1f,0/pci@1,1/scsi@2/disk@6,0:f tape /pci@1f,0/pci@1,1/scsi@2/tape@4,0 tape1 /pci@1f,0/pci@1,1/scsi@2/tape@5,0 tape0 /pci@1f,0/pci@1,1/scsi@2/tape@4,0 diskf /pci@1f,0/pci@1,1/scsi@2/disk@f,0 diske /pci@1f,0/pci@1,1/scsi@2/disk@e,0 diskd /pci@1f,0/pci@1,1/scsi@2/disk@d,0 diskc /pci@1f,0/pci@1,1/scsi@2/disk@c,0 diskb /pci@1f,0/pci@1,1/scsi@2/disk@b,0 diska /pci@1f,0/pci@1,1/scsi@2/disk@a,0 disk9 /pci@1f,0/pci@1,1/scsi@2/disk@9,0 disk8 /pci@1f,0/pci@1,1/scsi@2/disk@8,0 disk7 /pci@1f,0/pci@1,1/scsi@2/disk@7,0 disk6 /pci@1f,0/pci@1,1/scsi@2/disk@6,0 disk5 /pci@1f,0/pci@1,1/scsi@2/disk@5,0 disk4 /pci@1f,0/pci@1,1/scsi@2/disk@4,0 disk3 /pci@1f,0/pci@1,1/scsi@2/disk@3,0 disk2 /pci@1f,0/pci@1,1/scsi@2/disk@2,0 disk1 /pci@1f,0/pci@1,1/scsi@2/disk@1,0 disk0 /pci@1f,0/pci@1,1/scsi@2/disk@0,0 scsi /pci@1f,0/pci@1,1/scsi@2 ttyb /pci@1f,0/pci@1,1/ebus@1/su@14,3602f8 ttya /pci@1f,0/pci@1,1/ebus@1/su@14,3803f8 ttyd /pci@1f,0/pci@1,1/ebus@1/se@14,400000:b ttyc /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a As you can see, the devices disk0..diskf exist, but something in the boot code "only" probes the first 10 devices. It's certainly not attempting to opening *all* the disk devices listed by 'devalias'. It looks like from the code in .../sys/boot/sparc64/loader/main.c that the first MAXDEV (==31) disk devices are probed (well, whatever disk%d is an alias to, I suppose) and the vtoc's loaded and examined for zfs partitions. -Kurt From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 10 17:22:03 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B4FD1065672; Tue, 10 Jul 2012 17:22:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 150028FC0A; Tue, 10 Jul 2012 17:22:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6AHM2eG094507; Tue, 10 Jul 2012 13:22:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6AHM27e094494; Tue, 10 Jul 2012 17:22:02 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 17:22:02 GMT Message-Id: <201207101722.q6AHM27e094494@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 17:22:03 -0000 TB --- 2012-07-10 16:11:37 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 16:11:37 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 16:11:37 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-10 16:11:37 - cleaning the object tree TB --- 2012-07-10 16:13:24 - cvsupping the source tree TB --- 2012-07-10 16:13:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-10 16:14:29 - building world TB --- 2012-07-10 16:14:29 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 16:14:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 16:14:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 16:14:29 - SRCCONF=/dev/null TB --- 2012-07-10 16:14:29 - TARGET=sparc64 TB --- 2012-07-10 16:14:29 - TARGET_ARCH=sparc64 TB --- 2012-07-10 16:14:29 - TZ=UTC TB --- 2012-07-10 16:14:29 - __MAKE_CONF=/dev/null TB --- 2012-07-10 16:14:29 - cd /src TB --- 2012-07-10 16:14:29 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 16:14:30 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 17:17:16 UTC 2012 TB --- 2012-07-10 17:17:16 - generating LINT kernel config TB --- 2012-07-10 17:17:16 - cd /src/sys/sparc64/conf TB --- 2012-07-10 17:17:16 - /usr/bin/make -B LINT TB --- 2012-07-10 17:17:16 - cd /src/sys/sparc64/conf TB --- 2012-07-10 17:17:16 - /usr/sbin/config -m LINT TB --- 2012-07-10 17:17:16 - building LINT kernel TB --- 2012-07-10 17:17:16 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 17:17:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 17:17:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 17:17:16 - SRCCONF=/dev/null TB --- 2012-07-10 17:17:16 - TARGET=sparc64 TB --- 2012-07-10 17:17:16 - TARGET_ARCH=sparc64 TB --- 2012-07-10 17:17:16 - TZ=UTC TB --- 2012-07-10 17:17:16 - __MAKE_CONF=/dev/null TB --- 2012-07-10 17:17:16 - cd /src TB --- 2012-07-10 17:17:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 17:17:16 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1628: error: 'HAL_INT_RXLP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c: In function 'ath_init': /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXHP' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1880: error: 'HAL_INT_RXLP' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 17:22:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 17:22:02 - ERROR: failed to build LINT kernel TB --- 2012-07-10 17:22:02 - 3149.62 user 578.56 system 4225.02 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 10 23:24:07 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8849106564A; Tue, 10 Jul 2012 23:24:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A4B468FC14; Tue, 10 Jul 2012 23:24:07 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6ANO6Aj002952; Tue, 10 Jul 2012 19:24:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6ANO6ov002949; Tue, 10 Jul 2012 23:24:06 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 10 Jul 2012 23:24:06 GMT Message-Id: <201207102324.q6ANO6ov002949@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 23:24:08 -0000 TB --- 2012-07-10 22:06:51 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-10 22:06:51 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-10 22:06:51 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-10 22:06:51 - cleaning the object tree TB --- 2012-07-10 22:09:06 - cvsupping the source tree TB --- 2012-07-10 22:09:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-10 22:10:37 - building world TB --- 2012-07-10 22:10:37 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 22:10:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 22:10:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 22:10:37 - SRCCONF=/dev/null TB --- 2012-07-10 22:10:37 - TARGET=sparc64 TB --- 2012-07-10 22:10:37 - TARGET_ARCH=sparc64 TB --- 2012-07-10 22:10:37 - TZ=UTC TB --- 2012-07-10 22:10:37 - __MAKE_CONF=/dev/null TB --- 2012-07-10 22:10:37 - cd /src TB --- 2012-07-10 22:10:37 - /usr/bin/make -B buildworld >>> World build started on Tue Jul 10 22:10:38 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 10 23:18:33 UTC 2012 TB --- 2012-07-10 23:18:33 - generating LINT kernel config TB --- 2012-07-10 23:18:33 - cd /src/sys/sparc64/conf TB --- 2012-07-10 23:18:33 - /usr/bin/make -B LINT TB --- 2012-07-10 23:18:33 - cd /src/sys/sparc64/conf TB --- 2012-07-10 23:18:33 - /usr/sbin/config -m LINT TB --- 2012-07-10 23:18:33 - building LINT kernel TB --- 2012-07-10 23:18:33 - CROSS_BUILD_TESTING=YES TB --- 2012-07-10 23:18:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-10 23:18:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-10 23:18:33 - SRCCONF=/dev/null TB --- 2012-07-10 23:18:33 - TARGET=sparc64 TB --- 2012-07-10 23:18:33 - TARGET_ARCH=sparc64 TB --- 2012-07-10 23:18:33 - TZ=UTC TB --- 2012-07-10 23:18:33 - __MAKE_CONF=/dev/null TB --- 2012-07-10 23:18:33 - cd /src TB --- 2012-07-10 23:18:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 10 23:18:33 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-10 23:24:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-10 23:24:06 - ERROR: failed to build LINT kernel TB --- 2012-07-10 23:24:06 - 3185.88 user 590.62 system 4635.41 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Wed Jul 11 05:23:51 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B1021065670; Wed, 11 Jul 2012 05:23:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 25F858FC17; Wed, 11 Jul 2012 05:23:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6B5Nib4047017; Wed, 11 Jul 2012 01:23:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6B5NiJD047004; Wed, 11 Jul 2012 05:23:44 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 05:23:44 GMT Message-Id: <201207110523.q6B5NiJD047004@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 05:23:51 -0000 TB --- 2012-07-11 04:07:46 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 04:07:46 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-11 04:07:46 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-11 04:07:46 - cleaning the object tree TB --- 2012-07-11 04:09:28 - cvsupping the source tree TB --- 2012-07-11 04:09:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-11 04:10:38 - building world TB --- 2012-07-11 04:10:38 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 04:10:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 04:10:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 04:10:38 - SRCCONF=/dev/null TB --- 2012-07-11 04:10:38 - TARGET=sparc64 TB --- 2012-07-11 04:10:38 - TARGET_ARCH=sparc64 TB --- 2012-07-11 04:10:38 - TZ=UTC TB --- 2012-07-11 04:10:38 - __MAKE_CONF=/dev/null TB --- 2012-07-11 04:10:38 - cd /src TB --- 2012-07-11 04:10:38 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 04:10:39 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 05:18:29 UTC 2012 TB --- 2012-07-11 05:18:29 - generating LINT kernel config TB --- 2012-07-11 05:18:29 - cd /src/sys/sparc64/conf TB --- 2012-07-11 05:18:29 - /usr/bin/make -B LINT TB --- 2012-07-11 05:18:29 - cd /src/sys/sparc64/conf TB --- 2012-07-11 05:18:29 - /usr/sbin/config -m LINT TB --- 2012-07-11 05:18:29 - building LINT kernel TB --- 2012-07-11 05:18:29 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 05:18:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 05:18:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 05:18:29 - SRCCONF=/dev/null TB --- 2012-07-11 05:18:29 - TARGET=sparc64 TB --- 2012-07-11 05:18:29 - TARGET_ARCH=sparc64 TB --- 2012-07-11 05:18:29 - TZ=UTC TB --- 2012-07-11 05:18:29 - __MAKE_CONF=/dev/null TB --- 2012-07-11 05:18:29 - cd /src TB --- 2012-07-11 05:18:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 05:18:29 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 05:23:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 05:23:44 - ERROR: failed to build LINT kernel TB --- 2012-07-11 05:23:44 - 3187.68 user 589.09 system 4557.54 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Wed Jul 11 11:30:56 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A29651065670; Wed, 11 Jul 2012 11:30:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4CC8FC0C; Wed, 11 Jul 2012 11:30:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6BBUtux080061; Wed, 11 Jul 2012 07:30:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6BBUtiu080060; Wed, 11 Jul 2012 11:30:55 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 11:30:55 GMT Message-Id: <201207111130.q6BBUtiu080060@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 11:30:56 -0000 TB --- 2012-07-11 10:15:05 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 10:15:05 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-11 10:15:05 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-11 10:15:05 - cleaning the object tree TB --- 2012-07-11 10:16:34 - cvsupping the source tree TB --- 2012-07-11 10:16:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-11 10:17:43 - building world TB --- 2012-07-11 10:17:43 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 10:17:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 10:17:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 10:17:43 - SRCCONF=/dev/null TB --- 2012-07-11 10:17:43 - TARGET=sparc64 TB --- 2012-07-11 10:17:43 - TARGET_ARCH=sparc64 TB --- 2012-07-11 10:17:43 - TZ=UTC TB --- 2012-07-11 10:17:43 - __MAKE_CONF=/dev/null TB --- 2012-07-11 10:17:43 - cd /src TB --- 2012-07-11 10:17:43 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 10:17:44 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 11:25:53 UTC 2012 TB --- 2012-07-11 11:25:53 - generating LINT kernel config TB --- 2012-07-11 11:25:53 - cd /src/sys/sparc64/conf TB --- 2012-07-11 11:25:53 - /usr/bin/make -B LINT TB --- 2012-07-11 11:25:53 - cd /src/sys/sparc64/conf TB --- 2012-07-11 11:25:53 - /usr/sbin/config -m LINT TB --- 2012-07-11 11:25:53 - building LINT kernel TB --- 2012-07-11 11:25:53 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 11:25:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 11:25:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 11:25:53 - SRCCONF=/dev/null TB --- 2012-07-11 11:25:53 - TARGET=sparc64 TB --- 2012-07-11 11:25:53 - TARGET_ARCH=sparc64 TB --- 2012-07-11 11:25:53 - TZ=UTC TB --- 2012-07-11 11:25:53 - __MAKE_CONF=/dev/null TB --- 2012-07-11 11:25:53 - cd /src TB --- 2012-07-11 11:25:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 11:25:53 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-via.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/dev/ath /src/sys/dev/ath/if_ath.c: In function 'ath_intr': /src/sys/dev/ath/if_ath.c:1499: error: 'ATH_KTR_INTR' undeclared (first use in this function) /src/sys/dev/ath/if_ath.c:1499: error: (Each undeclared identifier is reported only once /src/sys/dev/ath/if_ath.c:1499: error: for each function it appears in.) /src/sys/dev/ath/if_ath.c:1577: error: 'ATH_KTR_ERR' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 11:30:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 11:30:55 - ERROR: failed to build LINT kernel TB --- 2012-07-11 11:30:55 - 3185.70 user 589.66 system 4549.78 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Wed Jul 11 20:28:09 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EE661065670; Wed, 11 Jul 2012 20:28:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6D93D8FC14; Wed, 11 Jul 2012 20:28:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6BKS8Sb010901; Wed, 11 Jul 2012 16:28:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6BKS83q010900; Wed, 11 Jul 2012 20:28:08 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 11 Jul 2012 20:28:08 GMT Message-Id: <201207112028.q6BKS83q010900@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 20:28:09 -0000 TB --- 2012-07-11 19:18:06 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-11 19:18:06 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-11 19:18:06 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-11 19:18:06 - cleaning the object tree TB --- 2012-07-11 19:19:35 - cvsupping the source tree TB --- 2012-07-11 19:19:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-11 19:20:19 - building world TB --- 2012-07-11 19:20:19 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 19:20:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 19:20:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 19:20:19 - SRCCONF=/dev/null TB --- 2012-07-11 19:20:19 - TARGET=sparc64 TB --- 2012-07-11 19:20:19 - TARGET_ARCH=sparc64 TB --- 2012-07-11 19:20:19 - TZ=UTC TB --- 2012-07-11 19:20:19 - __MAKE_CONF=/dev/null TB --- 2012-07-11 19:20:19 - cd /src TB --- 2012-07-11 19:20:19 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 11 19:20:20 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 11 20:18:23 UTC 2012 TB --- 2012-07-11 20:18:23 - generating LINT kernel config TB --- 2012-07-11 20:18:23 - cd /src/sys/sparc64/conf TB --- 2012-07-11 20:18:23 - /usr/bin/make -B LINT TB --- 2012-07-11 20:18:23 - cd /src/sys/sparc64/conf TB --- 2012-07-11 20:18:23 - /usr/sbin/config -m LINT TB --- 2012-07-11 20:18:23 - building LINT kernel TB --- 2012-07-11 20:18:23 - CROSS_BUILD_TESTING=YES TB --- 2012-07-11 20:18:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-11 20:18:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-11 20:18:23 - SRCCONF=/dev/null TB --- 2012-07-11 20:18:23 - TARGET=sparc64 TB --- 2012-07-11 20:18:23 - TARGET_ARCH=sparc64 TB --- 2012-07-11 20:18:23 - TZ=UTC TB --- 2012-07-11 20:18:23 - __MAKE_CONF=/dev/null TB --- 2012-07-11 20:18:23 - cd /src TB --- 2012-07-11 20:18:23 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 11 20:18:23 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/subr_devstat.c cc1: warnings being treated as errors /src/sys/kern/subr_devstat.c: In function 'devstat_start_transaction_bio': /src/sys/kern/subr_devstat.c:295: warning: implicit declaration of function 'DTRACE_DEVSTAT_BIO_START' /src/sys/kern/subr_devstat.c:295: warning: nested extern declaration of 'DTRACE_DEVSTAT_BIO_START' [-Wnested-externs] /src/sys/kern/subr_devstat.c: In function 'devstat_end_transaction_bio': /src/sys/kern/subr_devstat.c:390: warning: implicit declaration of function 'DTRACE_DEVSTAT_BIO_DONE' /src/sys/kern/subr_devstat.c:390: warning: nested extern declaration of 'DTRACE_DEVSTAT_BIO_DONE' [-Wnested-externs] *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-11 20:28:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-11 20:28:08 - ERROR: failed to build LINT kernel TB --- 2012-07-11 20:28:08 - 3436.29 user 557.12 system 4201.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Thu Jul 12 03:31:37 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A8A9106566B for ; Thu, 12 Jul 2012 03:31:37 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200::ae25]) by mx1.freebsd.org (Postfix) with ESMTP id 567148FC15 for ; Thu, 12 Jul 2012 03:31:37 +0000 (UTC) Received: from magrathea.distal.com (magrathea.distal.com [IPv6:2001:470:e24c:200:ea06:88ff:feca:960e]) (authenticated bits=0) by mail.distal.com (8.14.3/8.14.3) with ESMTP id q6C3VZaA006141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Jul 2012 23:31:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Chris Ross In-Reply-To: <20120708025435.GA12487@pix.net> Date: Wed, 11 Jul 2012 23:31:35 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <20120708025435.GA12487@pix.net> To: Kurt Lidl X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.distal.com [IPv6:2001:470:e24c:200::ae25]); Wed, 11 Jul 2012 23:31:36 -0400 (EDT) Cc: freebsd-sparc64@freebsd.org Subject: Re: zfs booting feedback X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 03:31:37 -0000 On Jul 7, 2012, at 22:54 , Kurt Lidl wrote: > I built a full 9.0-stable distribution on Friday night, and got to play > with installing it on a spare Netra T1-105 today. Mostly I was > interested in testing out the integrated ZFS boot support that > was commited recently. > > First of all -- it works! Thanks very much to all who made it possible! On this front, I'm trying to find a FreeBSD sparc64 stable build to install on a v240 I have for testing. I've not found it easily by googling, so if someone on the list could point me to sparc64 nightly's of the 9.0-STABLE branch, or if you. Kurt, could make the ISO you built and have working available, I'd very much appreciate it. I'm looking forward to experimenting with FreeBSD sparc64, and zfs. I'm a zfs newbie. :-) - Chris From owner-freebsd-sparc64@FreeBSD.ORG Thu Jul 12 03:59:45 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5EBB106567A for ; Thu, 12 Jul 2012 03:59:45 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 940CD8FC0C for ; Thu, 12 Jul 2012 03:59:45 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id q6C3xiQv028730; Wed, 11 Jul 2012 23:59:44 -0400 (EDT) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.4 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id q6C3xige028729; Wed, 11 Jul 2012 23:59:44 -0400 (EDT) (envelope-from lidl) Date: Wed, 11 Jul 2012 23:59:44 -0400 From: Kurt Lidl To: Chris Ross Message-ID: <20120712035944.GA28500@pix.net> References: <20120708025435.GA12487@pix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org Subject: Re: zfs booting feedback X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 03:59:45 -0000 On Wed, Jul 11, 2012 at 11:31:35PM -0400, Chris Ross wrote: > > On Jul 7, 2012, at 22:54 , Kurt Lidl wrote: > > I built a full 9.0-stable distribution on Friday night, and got to play > > with installing it on a spare Netra T1-105 today. Mostly I was > > interested in testing out the integrated ZFS boot support that > > was commited recently. > > > > First of all -- it works! Thanks very much to all who made it possible! > > On this front, I'm trying to find a FreeBSD sparc64 stable build to install > on a v240 I have for testing. I've not found it easily by googling, so if > someone on the list could point me to sparc64 nightly's of the 9.0-STABLE > branch, or if you. Kurt, could make the ISO you built and have working > available, I'd very much appreciate it. > > I'm looking forward to experimenting with FreeBSD sparc64, and zfs. > I'm a zfs newbie. :-) I put the iso I built, along with a checksum file for it, and the script that I used for installing all the bit here: http://www.pix.net/ftp/pub/freebsd/ You might want to fiddle with the size of the ZFS partition that the script creates. I have Sun "18GB" drives, so I just told it use 12GB as ZFS, and the rest as swap. -Kurt From owner-freebsd-sparc64@FreeBSD.ORG Thu Jul 12 04:48:41 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABA89106567A for ; Thu, 12 Jul 2012 04:48:41 +0000 (UTC) (envelope-from cross+freebsd@distal.com) Received: from mail.distal.com (mail.distal.com [IPv6:2001:470:e24c:200::ae25]) by mx1.freebsd.org (Postfix) with ESMTP id 76F368FC0C for ; Thu, 12 Jul 2012 04:48:41 +0000 (UTC) Received: from magrathea.distal.com (magrathea.distal.com [IPv6:2001:470:e24c:200:ea06:88ff:feca:960e]) (authenticated bits=0) by mail.distal.com (8.14.3/8.14.3) with ESMTP id q6C4mevQ005346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Jul 2012 00:48:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Chris Ross In-Reply-To: <20120712035944.GA28500@pix.net> Date: Thu, 12 Jul 2012 00:48:40 -0400 Content-Transfer-Encoding: 7bit Message-Id: <3D42F02D-7771-4581-AC7D-FC6D75A7D113@distal.com> References: <20120708025435.GA12487@pix.net> <20120712035944.GA28500@pix.net> To: Kurt Lidl X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.distal.com [IPv6:2001:470:e24c:200::ae25]); Thu, 12 Jul 2012 00:48:40 -0400 (EDT) Cc: freebsd-sparc64@freebsd.org Subject: Re: zfs booting feedback X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 04:48:41 -0000 On Jul 11, 2012, at 23:59 , Kurt Lidl wrote: >> I'm looking forward to experimenting with FreeBSD sparc64, and zfs. >> I'm a zfs newbie. :-) > > I put the iso I built, along with a checksum file for it, and the script > that I used for installing all the bit here: > > http://www.pix.net/ftp/pub/freebsd/ > > You might want to fiddle with the size of the ZFS partition that the > script creates. I have Sun "18GB" drives, so I just told it use 12GB > as ZFS, and the rest as swap. Thanks. I read that there was an issue with freebsd swap vs. ZFS swap for FreeBSD dumping. Looking at your script, it looks like you're using the "freebsd-swap" which will allow for crash dumps. But, not being familiar with gmirror and what you've done with "gswap", I just wanted to confirm. I'll give it a go tomorrow! Thanks much... - Chris From owner-freebsd-sparc64@FreeBSD.ORG Thu Jul 12 07:02:57 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C870A1065672 for ; Thu, 12 Jul 2012 07:02:57 +0000 (UTC) (envelope-from gavin.mu@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8070D8FC19 for ; Thu, 12 Jul 2012 07:02:57 +0000 (UTC) Received: by qcsg15 with SMTP id g15so1481374qcs.13 for ; Thu, 12 Jul 2012 00:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vegoV30kPqQl7P6W9k+RZlfG+3BzeuPGm0f7Pf40KZU=; b=flNs0F45zlO8i6t36Gr516pahVrolKdurTypg9UD5YGa0cGN9GtDqbCEc75obnUk7l np6NRAXlNq/Yd6Z0PnjdzsUpgcrfEIBtPJW4G9Wk7YDSsc3BzgWTwe6Gm8O16wXt05Lg /chE6H8SP++faZlVPGI/caNZBFtB7ejZgZVSlP6OXAV7kWqnZYHB09FVyUsY8SLDPivX PVLB3JCSlXWGybUDV+YtVJIUw2SMWXXz1Xtr7lai88vNcfcj0eNobNg9cs9QH91Obq1k jdBwelnDd1269l5IPv+iq2LjdPJc0YuVTTF4l6dWJ5mTd8mW3oA6lsfhIj6bKFOb1Ovc zefg== MIME-Version: 1.0 Received: by 10.224.177.1 with SMTP id bg1mr1884993qab.68.1342076576791; Thu, 12 Jul 2012 00:02:56 -0700 (PDT) Received: by 10.229.229.206 with HTTP; Thu, 12 Jul 2012 00:02:56 -0700 (PDT) In-Reply-To: <20120710165433.GA98707@pix.net> References: <20120708025435.GA12487@pix.net> <20120709140019.GA67276@alchemy.franken.de> <20120710165433.GA98707@pix.net> Date: Thu, 12 Jul 2012 15:02:56 +0800 Message-ID: From: Gavin Mu To: Kurt Lidl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-sparc64@freebsd.org, Marius Strobl Subject: Re: zfs booting feedback X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 07:02:57 -0000 On Wed, Jul 11, 2012 at 12:54 AM, Kurt Lidl wrote: > On Mon, Jul 09, 2012 at 04:00:19PM +0200, Marius Strobl wrote: > > On Sat, Jul 07, 2012 at 10:54:35PM -0400, Kurt Lidl wrote: > > > I built a full 9.0-stable distribution on Friday night, and got to play > > > with installing it on a spare Netra T1-105 today. Mostly I was > > > interested in testing out the integrated ZFS boot support that > > > was commited recently. > > > > > > First of all -- it works! Thanks very much to all who made it > possible! > > > > > > After working through a couple of nits in my script that installs it > all, > > > I've got a fully functioning, ZFS-only sparc64 machine. Nice. > > > > > > The zfsboot bootblock's warning about not being able to open > non-existant > > > devices are pretty extranous, but other than that, it seems to > function OK. > > > > That's more or less a cosmetic problem for now; there's no standard > > Open Firmware method allowing to test whether the device corresponding > > to a (automatically) created device alias actually exists short of > > trying to open it, with OFW causing at least the "Drive not ready" > > part on its own. There are some Sun specific extensions to the > > default methods whose names sound like they could be of some help > > here. I haven't gotten around to actually test whether this is the > > case or whether they actually exist in all OFW implementations of > > all sun4u models. > > If the aliases were artificially created via the `nvalias` command > > ("disk9" sounds a bit unusual for the automatically created ones) > > you can get rid of the none existing ones via `nvunalias` (needs > > a `reset-all` or power-cycle to take effect). > > All the disks that were probed were part of the normally > defined devices on the machine. I only have two devices defined > in my nvramrc: > > ok nvramrc type > devalias rootdisk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > devalias rootmirror /pci@1f,0/pci@1,1/scsi@2/disk@1,0 > > And I have the system configured to boot from "rootdisk rootmirror". > > Here's the full output of a 'devalias' from the prom on the machine: > > ok devalias > cdrom1 /pci@1f,0/pci@1,1/scsi@2/disk@6,0:f > cdrom /pci@1f,0/pci@1/pci@1/ide@e/cdrom@2:f > ide-disk /pci@1f,0/pci@1/pci@1/ide@e/disk@0:f > ide-cdrom /pci@1f,0/pci@1/pci@1/ide@e/cdrom@2:f > ide /pci@1f,0/pci@1/pci@1/ide@e > rootmirror /pci@1f,0/pci@1,1/scsi@2/disk@1,0 > rootdisk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > userprom2 /pci@1f,0/pci@1,1/ebus@1/flashprom@10,800000 > userprom1 /pci@1f,0/pci@1,1/ebus@1/flashprom@10,400000 > i2c-cs2 /pci@1f,0/pci@1,1/ebus@1/i2c@14,100000 > i2c /pci@1f,0/pci@1,1/ebus@1/i2c@14,600000 > systemprom /pci@1f,0/pci@1,1/ebus@1/flashprom@10,0 > pcic /pci@1f,0/pci@1/pci@1 > pcib /pci@1f,0/pci@1,1 > pcia /pci@1f,0/pci@1 > ebus /pci@1f,0/pci@1,1/ebus@1 > net2 /pci@1f,0/pci@1,1/network@3,1 > net /pci@1f,0/pci@1,1/network@1,1 > floppy /pci@1f,0/pci@1,1/ebus@1/fdthree > disk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > cdrom /pci@1f,0/pci@1,1/scsi@2/disk@6,0:f > tape /pci@1f,0/pci@1,1/scsi@2/tape@4,0 > tape1 /pci@1f,0/pci@1,1/scsi@2/tape@5,0 > tape0 /pci@1f,0/pci@1,1/scsi@2/tape@4,0 > diskf /pci@1f,0/pci@1,1/scsi@2/disk@f,0 > diske /pci@1f,0/pci@1,1/scsi@2/disk@e,0 > diskd /pci@1f,0/pci@1,1/scsi@2/disk@d,0 > diskc /pci@1f,0/pci@1,1/scsi@2/disk@c,0 > diskb /pci@1f,0/pci@1,1/scsi@2/disk@b,0 > diska /pci@1f,0/pci@1,1/scsi@2/disk@a,0 > disk9 /pci@1f,0/pci@1,1/scsi@2/disk@9,0 > disk8 /pci@1f,0/pci@1,1/scsi@2/disk@8,0 > disk7 /pci@1f,0/pci@1,1/scsi@2/disk@7,0 > disk6 /pci@1f,0/pci@1,1/scsi@2/disk@6,0 > disk5 /pci@1f,0/pci@1,1/scsi@2/disk@5,0 > disk4 /pci@1f,0/pci@1,1/scsi@2/disk@4,0 > disk3 /pci@1f,0/pci@1,1/scsi@2/disk@3,0 > disk2 /pci@1f,0/pci@1,1/scsi@2/disk@2,0 > disk1 /pci@1f,0/pci@1,1/scsi@2/disk@1,0 > disk0 /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > scsi /pci@1f,0/pci@1,1/scsi@2 > ttyb /pci@1f,0/pci@1,1/ebus@1/su@14,3602f8 > ttya /pci@1f,0/pci@1,1/ebus@1/su@14,3803f8 > ttyd /pci@1f,0/pci@1,1/ebus@1/se@14,400000:b > ttyc /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a > > As you can see, the devices disk0..diskf exist, but something in the > boot code "only" probes the first 10 devices. It's certainly not > attempting to opening *all* the disk devices listed by 'devalias'. > > It looks like from the code in .../sys/boot/sparc64/loader/main.c > that the first MAXDEV (==31) disk devices are probed (well, whatever > disk%d is an alias to, I suppose) and the vtoc's > loaded and examined for zfs partitions. > > oops, I think I assumed that the disk name should be disk9, disk10, disk11, instead of disk9, diska, diskb... Is there any standards to name those disks? Regards, Gavin From owner-freebsd-sparc64@FreeBSD.ORG Thu Jul 12 13:32:43 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8329106564A for ; Thu, 12 Jul 2012 13:32:43 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 959778FC12 for ; Thu, 12 Jul 2012 13:32:43 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id q6CDWgBt042083; Thu, 12 Jul 2012 09:32:42 -0400 (EDT) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.4 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id q6CDWga9042082; Thu, 12 Jul 2012 09:32:42 -0400 (EDT) (envelope-from lidl) Date: Thu, 12 Jul 2012 09:32:42 -0400 From: Kurt Lidl To: Chris Ross Message-ID: <20120712133242.GA41839@pix.net> References: <20120708025435.GA12487@pix.net> <20120712035944.GA28500@pix.net> <3D42F02D-7771-4581-AC7D-FC6D75A7D113@distal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D42F02D-7771-4581-AC7D-FC6D75A7D113@distal.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org Subject: Re: zfs booting feedback X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 13:32:43 -0000 On Thu, Jul 12, 2012 at 12:48:40AM -0400, Chris Ross wrote: > > On Jul 11, 2012, at 23:59 , Kurt Lidl wrote: > >> I'm looking forward to experimenting with FreeBSD sparc64, and zfs. > >> I'm a zfs newbie. :-) > > > > I put the iso I built, along with a checksum file for it, and the script > > that I used for installing all the bit here: > > > > http://www.pix.net/ftp/pub/freebsd/ > > > > You might want to fiddle with the size of the ZFS partition that the > > script creates. I have Sun "18GB" drives, so I just told it use 12GB > > as ZFS, and the rest as swap. > > Thanks. I read that there was an issue with freebsd swap vs. ZFS swap > for FreeBSD dumping. Looking at your script, it looks like you're using the > "freebsd-swap" which will allow for crash dumps. But, not being familiar > with gmirror and what you've done with "gswap", I just wanted to confirm. Yes. As I understand it, freebsd doesn't deal with swapping to a zfs volume reliably -- ultimately it will deadlock. And it cannot crash dump to a zfs volume at all. So, yes, I have a geom mirror setup between two vtoc partitions on the sparc64, and use that as the swap/crash dump space. That's the reason for the (geom) mirrored swap partition. The name "gswap" is just to remind me that's it's a geom mirror -- the choice of name is really arbitrary. Sparc64 doesn't support minidump format either, as far as I know, so you must have a swap space >= physical memory for it to work. On amd64, minidump format crashes are supported, so only the active kernel memory is dumped, and not all of physical memory. > I'll give it a go tomorrow! Thanks much... Good luck. -Kurt From owner-freebsd-sparc64@FreeBSD.ORG Thu Jul 12 17:22:11 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57787106564A for ; Thu, 12 Jul 2012 17:22:11 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 030068FC12 for ; Thu, 12 Jul 2012 17:22:10 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id q6CHM8Ef048030; Thu, 12 Jul 2012 13:22:08 -0400 (EDT) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.4 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id q6CHM8t7048029; Thu, 12 Jul 2012 13:22:08 -0400 (EDT) (envelope-from lidl) Date: Thu, 12 Jul 2012 13:22:08 -0400 From: Kurt Lidl To: Gavin Mu Message-ID: <20120712172208.GA47484@pix.net> References: <20120708025435.GA12487@pix.net> <20120709140019.GA67276@alchemy.franken.de> <20120710165433.GA98707@pix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org, Marius Strobl Subject: Re: zfs booting feedback X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 17:22:11 -0000 On Thu, Jul 12, 2012 at 03:02:56PM +0800, Gavin Mu wrote: > On Wed, Jul 11, 2012 at 12:54 AM, Kurt Lidl wrote: > > > On Mon, Jul 09, 2012 at 04:00:19PM +0200, Marius Strobl wrote: > > > On Sat, Jul 07, 2012 at 10:54:35PM -0400, Kurt Lidl wrote: > > > > I built a full 9.0-stable distribution on Friday night, and got to play > > > > with installing it on a spare Netra T1-105 today. Mostly I was > > > > interested in testing out the integrated ZFS boot support that > > > > was commited recently. > > > > > > > > First of all -- it works! Thanks very much to all who made it > > possible! > > > > > > > > After working through a couple of nits in my script that installs it > > all, > > > > I've got a fully functioning, ZFS-only sparc64 machine. Nice. > > > > > > > > The zfsboot bootblock's warning about not being able to open > > non-existant > > > > devices are pretty extranous, but other than that, it seems to > > function OK. > > > > > > That's more or less a cosmetic problem for now; there's no standard > > > Open Firmware method allowing to test whether the device corresponding > > > to a (automatically) created device alias actually exists short of > > > trying to open it, with OFW causing at least the "Drive not ready" > > > part on its own. There are some Sun specific extensions to the > > > default methods whose names sound like they could be of some help > > > here. I haven't gotten around to actually test whether this is the > > > case or whether they actually exist in all OFW implementations of > > > all sun4u models. > > > If the aliases were artificially created via the `nvalias` command > > > ("disk9" sounds a bit unusual for the automatically created ones) > > > you can get rid of the none existing ones via `nvunalias` (needs > > > a `reset-all` or power-cycle to take effect). > > > > All the disks that were probed were part of the normally > > defined devices on the machine. I only have two devices defined > > in my nvramrc: > > > > ok nvramrc type > > devalias rootdisk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > > devalias rootmirror /pci@1f,0/pci@1,1/scsi@2/disk@1,0 > > > > And I have the system configured to boot from "rootdisk rootmirror". > > > > Here's the full output of a 'devalias' from the prom on the machine: > > > > ok devalias > > cdrom1 /pci@1f,0/pci@1,1/scsi@2/disk@6,0:f > > cdrom /pci@1f,0/pci@1/pci@1/ide@e/cdrom@2:f > > ide-disk /pci@1f,0/pci@1/pci@1/ide@e/disk@0:f > > ide-cdrom /pci@1f,0/pci@1/pci@1/ide@e/cdrom@2:f > > ide /pci@1f,0/pci@1/pci@1/ide@e > > rootmirror /pci@1f,0/pci@1,1/scsi@2/disk@1,0 > > rootdisk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > > userprom2 /pci@1f,0/pci@1,1/ebus@1/flashprom@10,800000 > > userprom1 /pci@1f,0/pci@1,1/ebus@1/flashprom@10,400000 > > i2c-cs2 /pci@1f,0/pci@1,1/ebus@1/i2c@14,100000 > > i2c /pci@1f,0/pci@1,1/ebus@1/i2c@14,600000 > > systemprom /pci@1f,0/pci@1,1/ebus@1/flashprom@10,0 > > pcic /pci@1f,0/pci@1/pci@1 > > pcib /pci@1f,0/pci@1,1 > > pcia /pci@1f,0/pci@1 > > ebus /pci@1f,0/pci@1,1/ebus@1 > > net2 /pci@1f,0/pci@1,1/network@3,1 > > net /pci@1f,0/pci@1,1/network@1,1 > > floppy /pci@1f,0/pci@1,1/ebus@1/fdthree > > disk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > > cdrom /pci@1f,0/pci@1,1/scsi@2/disk@6,0:f > > tape /pci@1f,0/pci@1,1/scsi@2/tape@4,0 > > tape1 /pci@1f,0/pci@1,1/scsi@2/tape@5,0 > > tape0 /pci@1f,0/pci@1,1/scsi@2/tape@4,0 > > diskf /pci@1f,0/pci@1,1/scsi@2/disk@f,0 > > diske /pci@1f,0/pci@1,1/scsi@2/disk@e,0 > > diskd /pci@1f,0/pci@1,1/scsi@2/disk@d,0 > > diskc /pci@1f,0/pci@1,1/scsi@2/disk@c,0 > > diskb /pci@1f,0/pci@1,1/scsi@2/disk@b,0 > > diska /pci@1f,0/pci@1,1/scsi@2/disk@a,0 > > disk9 /pci@1f,0/pci@1,1/scsi@2/disk@9,0 > > disk8 /pci@1f,0/pci@1,1/scsi@2/disk@8,0 > > disk7 /pci@1f,0/pci@1,1/scsi@2/disk@7,0 > > disk6 /pci@1f,0/pci@1,1/scsi@2/disk@6,0 > > disk5 /pci@1f,0/pci@1,1/scsi@2/disk@5,0 > > disk4 /pci@1f,0/pci@1,1/scsi@2/disk@4,0 > > disk3 /pci@1f,0/pci@1,1/scsi@2/disk@3,0 > > disk2 /pci@1f,0/pci@1,1/scsi@2/disk@2,0 > > disk1 /pci@1f,0/pci@1,1/scsi@2/disk@1,0 > > disk0 /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > > scsi /pci@1f,0/pci@1,1/scsi@2 > > ttyb /pci@1f,0/pci@1,1/ebus@1/su@14,3602f8 > > ttya /pci@1f,0/pci@1,1/ebus@1/su@14,3803f8 > > ttyd /pci@1f,0/pci@1,1/ebus@1/se@14,400000:b > > ttyc /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a > > > > As you can see, the devices disk0..diskf exist, but something in the > > boot code "only" probes the first 10 devices. It's certainly not > > attempting to opening *all* the disk devices listed by 'devalias'. > > > > It looks like from the code in .../sys/boot/sparc64/loader/main.c > > that the first MAXDEV (==31) disk devices are probed (well, whatever > > disk%d is an alias to, I suppose) and the vtoc's > > loaded and examined for zfs partitions. > > > > oops, I think I assumed that the disk name should be disk9, disk10, > disk11, instead of disk9, diska, diskb... > Is there any standards to name those disks? I do not really know. The above 'devalias' output is the same on the two netra-T1 105s that I tested. I looked on my SunFire V240, and it has many fewer entries: {1} ok devalias usb /pci@1e,600000/ide@d/disk xnet2 /pci@1d,700000/pci@1/SUNW,hme@0,1:dhcp, xnet1 /pci@1e,600000/pci@3/SUNW,hme@0,1:dhcp, xnet /pci@1e,600000/pci@2/SUNW,hme@0,1:dhcp, net3 /pci@1d,700000/network@2,1 net2 /pci@1d,700000/network@2 net1 /pci@1f,700000/network@2,1 net /pci@1f,700000/network@2 cdrom /pci@1e,600000/ide@d/cdrom@0,0:f ide /pci@1e,600000/ide@d disk3 /pci@1c,600000/scsi@2/disk@3,0 disk2 /pci@1c,600000/scsi@2/disk@2,0 disk1 /pci@1c,600000/scsi@2/disk@1,0 disk0 /pci@1c,600000/scsi@2/disk@0,0 disk /pci@1c,600000/scsi@2/disk@0,0 scsi /pci@1c,600000/scsi@2 sc-control /pci@1e,600000/isa@7/rmc-comm@0,3e8 ttyb /pci@1e,600000/isa@7/serial@0,2e8 ttya /pci@1e,600000/isa@7/serial@0,3f8 name aliases I would argue that what the loader ought to be looking at the devices/devalias entries values for the "boot-device" property. That way, if I wanted to boot from something like a zmirror of disk2 and disk3 on my sunfire, I would just set the "boot-device" to be "disk2 disk3", and the zfs boot code would just try to interate through those devices, rather than going from 0..31 and trying disk%d... If I had valid boot-code on disk0 and disk2, and I set the "boot-device" to "disk2 disk3", I think current code will do this: - prom load "zfsboot" block off disk2 - zfsboot block loads in the zfsloader binary from current disk (disk2) - which then probes disk0, disk1 .... and finally boots the kernel from the first freebsd-zfs partition that it finds on any of those disks. I think this is wrong, as there could be some data-only zfs partition on disk0, which doesn't have a kernel to boot from... Also, one other thing to keep in mind that the boot-device propery can be a devalias entry or just a straight-up device specifier, like this: /pci@1c,600000/scsi@2/disk@0,0:a (That's what I have on my SunFire, for various arcane reasons...) I guess we also have to worry when someone breaks into the prom and says "boot disk4", and that user input should override the "boot-device" settings in the prom. -Kurt From owner-freebsd-sparc64@FreeBSD.ORG Thu Jul 12 20:53:47 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81E64106564A; Thu, 12 Jul 2012 20:53:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1EDCD8FC12; Thu, 12 Jul 2012 20:53:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q6CKrkrs073943; Thu, 12 Jul 2012 16:53:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q6CKrkT1073942; Thu, 12 Jul 2012 20:53:46 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 12 Jul 2012 20:53:46 GMT Message-Id: <201207122053.q6CKrkT1073942@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:53:47 -0000 TB --- 2012-07-12 20:43:02 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-12 20:43:02 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-12 20:43:02 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-12 20:43:02 - cleaning the object tree TB --- 2012-07-12 20:43:02 - cvsupping the source tree TB --- 2012-07-12 20:43:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-12 20:44:43 - building world TB --- 2012-07-12 20:44:43 - CROSS_BUILD_TESTING=YES TB --- 2012-07-12 20:44:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-12 20:44:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-12 20:44:43 - SRCCONF=/dev/null TB --- 2012-07-12 20:44:43 - TARGET=sparc64 TB --- 2012-07-12 20:44:43 - TARGET_ARCH=sparc64 TB --- 2012-07-12 20:44:43 - TZ=UTC TB --- 2012-07-12 20:44:43 - __MAKE_CONF=/dev/null TB --- 2012-07-12 20:44:43 - cd /src TB --- 2012-07-12 20:44:43 - /usr/bin/make -B buildworld >>> World build started on Thu Jul 12 20:44:44 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes [...] ===> sbin/sysctl (installincludes) ===> sbin/tunefs (installincludes) ===> sbin/umount (installincludes) ===> secure (includes) cd /src/secure; /usr/bin/make buildincludes; /usr/bin/make installincludes ===> secure/lib (buildincludes) ===> secure/lib/libcrypto (buildincludes) make: don't know how to make tmdiff.h. Stop *** Error code 2 Stop in /src/secure/lib. *** Error code 1 Stop in /src/secure. *** Error code 1 Stop in /src/secure. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-07-12 20:53:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-07-12 20:53:46 - ERROR: failed to build world TB --- 2012-07-12 20:53:46 - 411.92 user 59.38 system 643.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Fri Jul 13 19:58:09 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93DAC1065672 for ; Fri, 13 Jul 2012 19:58:09 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id C5D4D8FC12 for ; Fri, 13 Jul 2012 19:58:08 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q6DJw7xO090492; Fri, 13 Jul 2012 21:58:07 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q6DJw7Jj090491; Fri, 13 Jul 2012 21:58:07 +0200 (CEST) (envelope-from marius) Date: Fri, 13 Jul 2012 21:58:07 +0200 From: Marius Strobl To: Kurt Lidl Message-ID: <20120713195807.GU63893@alchemy.franken.de> References: <20120708025435.GA12487@pix.net> <20120709140019.GA67276@alchemy.franken.de> <20120710165433.GA98707@pix.net> <20120712172208.GA47484@pix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120712172208.GA47484@pix.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: zfs booting feedback X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 19:58:09 -0000 On Thu, Jul 12, 2012 at 01:22:08PM -0400, Kurt Lidl wrote: > On Thu, Jul 12, 2012 at 03:02:56PM +0800, Gavin Mu wrote: > > On Wed, Jul 11, 2012 at 12:54 AM, Kurt Lidl wrote: > > > > > On Mon, Jul 09, 2012 at 04:00:19PM +0200, Marius Strobl wrote: > > > > On Sat, Jul 07, 2012 at 10:54:35PM -0400, Kurt Lidl wrote: > > > > > I built a full 9.0-stable distribution on Friday night, and got to play > > > > > with installing it on a spare Netra T1-105 today. Mostly I was > > > > > interested in testing out the integrated ZFS boot support that > > > > > was commited recently. > > > > > > > > > > First of all -- it works! Thanks very much to all who made it > > > possible! > > > > > > > > > > After working through a couple of nits in my script that installs it > > > all, > > > > > I've got a fully functioning, ZFS-only sparc64 machine. Nice. > > > > > > > > > > The zfsboot bootblock's warning about not being able to open > > > non-existant > > > > > devices are pretty extranous, but other than that, it seems to > > > function OK. > > > > > > > > That's more or less a cosmetic problem for now; there's no standard > > > > Open Firmware method allowing to test whether the device corresponding > > > > to a (automatically) created device alias actually exists short of > > > > trying to open it, with OFW causing at least the "Drive not ready" > > > > part on its own. There are some Sun specific extensions to the > > > > default methods whose names sound like they could be of some help > > > > here. I haven't gotten around to actually test whether this is the > > > > case or whether they actually exist in all OFW implementations of > > > > all sun4u models. > > > > If the aliases were artificially created via the `nvalias` command > > > > ("disk9" sounds a bit unusual for the automatically created ones) > > > > you can get rid of the none existing ones via `nvunalias` (needs > > > > a `reset-all` or power-cycle to take effect). > > > > > > All the disks that were probed were part of the normally > > > defined devices on the machine. I only have two devices defined > > > in my nvramrc: > > > > > > ok nvramrc type > > > devalias rootdisk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > > > devalias rootmirror /pci@1f,0/pci@1,1/scsi@2/disk@1,0 > > > > > > And I have the system configured to boot from "rootdisk rootmirror". > > > > > > Here's the full output of a 'devalias' from the prom on the machine: > > > > > > ok devalias > > > cdrom1 /pci@1f,0/pci@1,1/scsi@2/disk@6,0:f > > > cdrom /pci@1f,0/pci@1/pci@1/ide@e/cdrom@2:f > > > ide-disk /pci@1f,0/pci@1/pci@1/ide@e/disk@0:f > > > ide-cdrom /pci@1f,0/pci@1/pci@1/ide@e/cdrom@2:f > > > ide /pci@1f,0/pci@1/pci@1/ide@e > > > rootmirror /pci@1f,0/pci@1,1/scsi@2/disk@1,0 > > > rootdisk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > > > userprom2 /pci@1f,0/pci@1,1/ebus@1/flashprom@10,800000 > > > userprom1 /pci@1f,0/pci@1,1/ebus@1/flashprom@10,400000 > > > i2c-cs2 /pci@1f,0/pci@1,1/ebus@1/i2c@14,100000 > > > i2c /pci@1f,0/pci@1,1/ebus@1/i2c@14,600000 > > > systemprom /pci@1f,0/pci@1,1/ebus@1/flashprom@10,0 > > > pcic /pci@1f,0/pci@1/pci@1 > > > pcib /pci@1f,0/pci@1,1 > > > pcia /pci@1f,0/pci@1 > > > ebus /pci@1f,0/pci@1,1/ebus@1 > > > net2 /pci@1f,0/pci@1,1/network@3,1 > > > net /pci@1f,0/pci@1,1/network@1,1 > > > floppy /pci@1f,0/pci@1,1/ebus@1/fdthree > > > disk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > > > cdrom /pci@1f,0/pci@1,1/scsi@2/disk@6,0:f > > > tape /pci@1f,0/pci@1,1/scsi@2/tape@4,0 > > > tape1 /pci@1f,0/pci@1,1/scsi@2/tape@5,0 > > > tape0 /pci@1f,0/pci@1,1/scsi@2/tape@4,0 > > > diskf /pci@1f,0/pci@1,1/scsi@2/disk@f,0 > > > diske /pci@1f,0/pci@1,1/scsi@2/disk@e,0 > > > diskd /pci@1f,0/pci@1,1/scsi@2/disk@d,0 > > > diskc /pci@1f,0/pci@1,1/scsi@2/disk@c,0 > > > diskb /pci@1f,0/pci@1,1/scsi@2/disk@b,0 > > > diska /pci@1f,0/pci@1,1/scsi@2/disk@a,0 > > > disk9 /pci@1f,0/pci@1,1/scsi@2/disk@9,0 > > > disk8 /pci@1f,0/pci@1,1/scsi@2/disk@8,0 > > > disk7 /pci@1f,0/pci@1,1/scsi@2/disk@7,0 > > > disk6 /pci@1f,0/pci@1,1/scsi@2/disk@6,0 > > > disk5 /pci@1f,0/pci@1,1/scsi@2/disk@5,0 > > > disk4 /pci@1f,0/pci@1,1/scsi@2/disk@4,0 > > > disk3 /pci@1f,0/pci@1,1/scsi@2/disk@3,0 > > > disk2 /pci@1f,0/pci@1,1/scsi@2/disk@2,0 > > > disk1 /pci@1f,0/pci@1,1/scsi@2/disk@1,0 > > > disk0 /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > > > scsi /pci@1f,0/pci@1,1/scsi@2 > > > ttyb /pci@1f,0/pci@1,1/ebus@1/su@14,3602f8 > > > ttya /pci@1f,0/pci@1,1/ebus@1/su@14,3803f8 > > > ttyd /pci@1f,0/pci@1,1/ebus@1/se@14,400000:b > > > ttyc /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a > > > > > > As you can see, the devices disk0..diskf exist, but something in the > > > boot code "only" probes the first 10 devices. It's certainly not > > > attempting to opening *all* the disk devices listed by 'devalias'. > > > > > > It looks like from the code in .../sys/boot/sparc64/loader/main.c > > > that the first MAXDEV (==31) disk devices are probed (well, whatever > > > disk%d is an alias to, I suppose) and the vtoc's > > > loaded and examined for zfs partitions. > > > > > > oops, I think I assumed that the disk name should be disk9, disk10, > > disk11, instead of disk9, diska, diskb... > > Is there any standards to name those disks? > > I do not really know. The above 'devalias' output is the same on > the two netra-T1 105s that I tested. I looked on my SunFire V240, > and it has many fewer entries: > > {1} ok devalias > usb /pci@1e,600000/ide@d/disk > xnet2 /pci@1d,700000/pci@1/SUNW,hme@0,1:dhcp, > xnet1 /pci@1e,600000/pci@3/SUNW,hme@0,1:dhcp, > xnet /pci@1e,600000/pci@2/SUNW,hme@0,1:dhcp, > net3 /pci@1d,700000/network@2,1 > net2 /pci@1d,700000/network@2 > net1 /pci@1f,700000/network@2,1 > net /pci@1f,700000/network@2 > cdrom /pci@1e,600000/ide@d/cdrom@0,0:f > ide /pci@1e,600000/ide@d > disk3 /pci@1c,600000/scsi@2/disk@3,0 > disk2 /pci@1c,600000/scsi@2/disk@2,0 > disk1 /pci@1c,600000/scsi@2/disk@1,0 > disk0 /pci@1c,600000/scsi@2/disk@0,0 > disk /pci@1c,600000/scsi@2/disk@0,0 > scsi /pci@1c,600000/scsi@2 > sc-control /pci@1e,600000/isa@7/rmc-comm@0,3e8 > ttyb /pci@1e,600000/isa@7/serial@0,2e8 > ttya /pci@1e,600000/isa@7/serial@0,3f8 > name aliases > > I would argue that what the loader ought to be looking at the > devices/devalias entries values for the "boot-device" property. > > That way, if I wanted to boot from something like a zmirror of > disk2 and disk3 on my sunfire, I would just set the > "boot-device" to be "disk2 disk3", and the zfs boot code would > just try to interate through those devices, rather than going > from 0..31 and trying disk%d... > > If I had valid boot-code on disk0 and disk2, and I set the > "boot-device" to "disk2 disk3", I think current code will do > this: > - prom load "zfsboot" block off disk2 > - zfsboot block loads in the zfsloader binary from current disk (disk2) > - which then probes disk0, disk1 .... and finally boots > the kernel from the first freebsd-zfs partition that it finds > on any of those disks. > > I think this is wrong, as there could be some data-only zfs > partition on disk0, which doesn't have a kernel to boot from... > > Also, one other thing to keep in mind that the boot-device propery > can be a devalias entry or just a straight-up device specifier, > like this: > > /pci@1c,600000/scsi@2/disk@0,0:a > > (That's what I have on my SunFire, for various arcane reasons...) > > I guess we also have to worry when someone breaks into the prom > and says "boot disk4", and that user input should override the > "boot-device" settings in the prom. > What's currently implemented in the sparc64 ZFS loader resembles how the x86 version works as close as possible, i.e. basically trying to detect ZFS pools on all disks available via the firmware (i.e. BIOS in the x86 case). The current approach may not be ideal for sparc64, but before inventing yet another one it would be great if someone could check how this is done in (Open)Solaris, either by digging up the relevant documentation or by actually giving it a try. Marius From owner-freebsd-sparc64@FreeBSD.ORG Sat Jul 14 00:43:38 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AD0D106566C for ; Sat, 14 Jul 2012 00:43:38 +0000 (UTC) (envelope-from lidl@hydra.pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id F14158FC0A for ; Sat, 14 Jul 2012 00:43:37 +0000 (UTC) Received: from hydra.pix.net (localhost [127.0.0.1]) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id q6E0haXX093837; Fri, 13 Jul 2012 20:43:36 -0400 (EDT) (envelope-from lidl@hydra.pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.4 at mail.pix.net Received: (from lidl@localhost) by hydra.pix.net (8.14.5/8.14.5/Submit) id q6E0hZmw093836; Fri, 13 Jul 2012 20:43:35 -0400 (EDT) (envelope-from lidl) Date: Fri, 13 Jul 2012 20:43:35 -0400 From: Kurt Lidl To: Marius Strobl Message-ID: <20120714004335.GD92944@pix.net> References: <20120708025435.GA12487@pix.net> <20120709140019.GA67276@alchemy.franken.de> <20120710165433.GA98707@pix.net> <20120712172208.GA47484@pix.net> <20120713195807.GU63893@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120713195807.GU63893@alchemy.franken.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org Subject: Re: zfs booting feedback X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 00:43:38 -0000 On Fri, Jul 13, 2012 at 09:58:07PM +0200, Marius Strobl wrote: > On Thu, Jul 12, 2012 at 01:22:08PM -0400, Kurt Lidl wrote: > > On Thu, Jul 12, 2012 at 03:02:56PM +0800, Gavin Mu wrote: > > > On Wed, Jul 11, 2012 at 12:54 AM, Kurt Lidl wrote: > > > > > > > On Mon, Jul 09, 2012 at 04:00:19PM +0200, Marius Strobl wrote: > > > > > On Sat, Jul 07, 2012 at 10:54:35PM -0400, Kurt Lidl wrote: > > > > > > I built a full 9.0-stable distribution on Friday night, and got to play > > > > > > with installing it on a spare Netra T1-105 today. Mostly I was > > > > > > interested in testing out the integrated ZFS boot support that > > > > > > was commited recently. > > > > > > > > > > > > First of all -- it works! Thanks very much to all who made it > > > > possible! > > > > > > > > > > > > After working through a couple of nits in my script that installs it > > > > all, > > > > > > I've got a fully functioning, ZFS-only sparc64 machine. Nice. > > > > > > > > > > > > The zfsboot bootblock's warning about not being able to open > > > > non-existant > > > > > > devices are pretty extranous, but other than that, it seems to > > > > function OK. > > > > > > > > > > That's more or less a cosmetic problem for now; there's no standard > > > > > Open Firmware method allowing to test whether the device corresponding > > > > > to a (automatically) created device alias actually exists short of > > > > > trying to open it, with OFW causing at least the "Drive not ready" > > > > > part on its own. There are some Sun specific extensions to the > > > > > default methods whose names sound like they could be of some help > > > > > here. I haven't gotten around to actually test whether this is the > > > > > case or whether they actually exist in all OFW implementations of > > > > > all sun4u models. > > > > > If the aliases were artificially created via the `nvalias` command > > > > > ("disk9" sounds a bit unusual for the automatically created ones) > > > > > you can get rid of the none existing ones via `nvunalias` (needs > > > > > a `reset-all` or power-cycle to take effect). > > > > > > > > All the disks that were probed were part of the normally > > > > defined devices on the machine. I only have two devices defined > > > > in my nvramrc: > > > > > > > > ok nvramrc type > > > > devalias rootdisk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > > > > devalias rootmirror /pci@1f,0/pci@1,1/scsi@2/disk@1,0 > > > > > > > > And I have the system configured to boot from "rootdisk rootmirror". > > > > > > > > Here's the full output of a 'devalias' from the prom on the machine: > > > > > > > > ok devalias > > > > cdrom1 /pci@1f,0/pci@1,1/scsi@2/disk@6,0:f > > > > cdrom /pci@1f,0/pci@1/pci@1/ide@e/cdrom@2:f > > > > ide-disk /pci@1f,0/pci@1/pci@1/ide@e/disk@0:f > > > > ide-cdrom /pci@1f,0/pci@1/pci@1/ide@e/cdrom@2:f > > > > ide /pci@1f,0/pci@1/pci@1/ide@e > > > > rootmirror /pci@1f,0/pci@1,1/scsi@2/disk@1,0 > > > > rootdisk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > > > > userprom2 /pci@1f,0/pci@1,1/ebus@1/flashprom@10,800000 > > > > userprom1 /pci@1f,0/pci@1,1/ebus@1/flashprom@10,400000 > > > > i2c-cs2 /pci@1f,0/pci@1,1/ebus@1/i2c@14,100000 > > > > i2c /pci@1f,0/pci@1,1/ebus@1/i2c@14,600000 > > > > systemprom /pci@1f,0/pci@1,1/ebus@1/flashprom@10,0 > > > > pcic /pci@1f,0/pci@1/pci@1 > > > > pcib /pci@1f,0/pci@1,1 > > > > pcia /pci@1f,0/pci@1 > > > > ebus /pci@1f,0/pci@1,1/ebus@1 > > > > net2 /pci@1f,0/pci@1,1/network@3,1 > > > > net /pci@1f,0/pci@1,1/network@1,1 > > > > floppy /pci@1f,0/pci@1,1/ebus@1/fdthree > > > > disk /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > > > > cdrom /pci@1f,0/pci@1,1/scsi@2/disk@6,0:f > > > > tape /pci@1f,0/pci@1,1/scsi@2/tape@4,0 > > > > tape1 /pci@1f,0/pci@1,1/scsi@2/tape@5,0 > > > > tape0 /pci@1f,0/pci@1,1/scsi@2/tape@4,0 > > > > diskf /pci@1f,0/pci@1,1/scsi@2/disk@f,0 > > > > diske /pci@1f,0/pci@1,1/scsi@2/disk@e,0 > > > > diskd /pci@1f,0/pci@1,1/scsi@2/disk@d,0 > > > > diskc /pci@1f,0/pci@1,1/scsi@2/disk@c,0 > > > > diskb /pci@1f,0/pci@1,1/scsi@2/disk@b,0 > > > > diska /pci@1f,0/pci@1,1/scsi@2/disk@a,0 > > > > disk9 /pci@1f,0/pci@1,1/scsi@2/disk@9,0 > > > > disk8 /pci@1f,0/pci@1,1/scsi@2/disk@8,0 > > > > disk7 /pci@1f,0/pci@1,1/scsi@2/disk@7,0 > > > > disk6 /pci@1f,0/pci@1,1/scsi@2/disk@6,0 > > > > disk5 /pci@1f,0/pci@1,1/scsi@2/disk@5,0 > > > > disk4 /pci@1f,0/pci@1,1/scsi@2/disk@4,0 > > > > disk3 /pci@1f,0/pci@1,1/scsi@2/disk@3,0 > > > > disk2 /pci@1f,0/pci@1,1/scsi@2/disk@2,0 > > > > disk1 /pci@1f,0/pci@1,1/scsi@2/disk@1,0 > > > > disk0 /pci@1f,0/pci@1,1/scsi@2/disk@0,0 > > > > scsi /pci@1f,0/pci@1,1/scsi@2 > > > > ttyb /pci@1f,0/pci@1,1/ebus@1/su@14,3602f8 > > > > ttya /pci@1f,0/pci@1,1/ebus@1/su@14,3803f8 > > > > ttyd /pci@1f,0/pci@1,1/ebus@1/se@14,400000:b > > > > ttyc /pci@1f,0/pci@1,1/ebus@1/se@14,400000:a > > > > > > > > As you can see, the devices disk0..diskf exist, but something in the > > > > boot code "only" probes the first 10 devices. It's certainly not > > > > attempting to opening *all* the disk devices listed by 'devalias'. > > > > > > > > It looks like from the code in .../sys/boot/sparc64/loader/main.c > > > > that the first MAXDEV (==31) disk devices are probed (well, whatever > > > > disk%d is an alias to, I suppose) and the vtoc's > > > > loaded and examined for zfs partitions. > > > > > > > > oops, I think I assumed that the disk name should be disk9, disk10, > > > disk11, instead of disk9, diska, diskb... > > > Is there any standards to name those disks? > > > > I do not really know. The above 'devalias' output is the same on > > the two netra-T1 105s that I tested. I looked on my SunFire V240, > > and it has many fewer entries: > > > > {1} ok devalias > > usb /pci@1e,600000/ide@d/disk > > xnet2 /pci@1d,700000/pci@1/SUNW,hme@0,1:dhcp, > > xnet1 /pci@1e,600000/pci@3/SUNW,hme@0,1:dhcp, > > xnet /pci@1e,600000/pci@2/SUNW,hme@0,1:dhcp, > > net3 /pci@1d,700000/network@2,1 > > net2 /pci@1d,700000/network@2 > > net1 /pci@1f,700000/network@2,1 > > net /pci@1f,700000/network@2 > > cdrom /pci@1e,600000/ide@d/cdrom@0,0:f > > ide /pci@1e,600000/ide@d > > disk3 /pci@1c,600000/scsi@2/disk@3,0 > > disk2 /pci@1c,600000/scsi@2/disk@2,0 > > disk1 /pci@1c,600000/scsi@2/disk@1,0 > > disk0 /pci@1c,600000/scsi@2/disk@0,0 > > disk /pci@1c,600000/scsi@2/disk@0,0 > > scsi /pci@1c,600000/scsi@2 > > sc-control /pci@1e,600000/isa@7/rmc-comm@0,3e8 > > ttyb /pci@1e,600000/isa@7/serial@0,2e8 > > ttya /pci@1e,600000/isa@7/serial@0,3f8 > > name aliases > > > > I would argue that what the loader ought to be looking at the > > devices/devalias entries values for the "boot-device" property. > > > > That way, if I wanted to boot from something like a zmirror of > > disk2 and disk3 on my sunfire, I would just set the > > "boot-device" to be "disk2 disk3", and the zfs boot code would > > just try to interate through those devices, rather than going > > from 0..31 and trying disk%d... > > > > If I had valid boot-code on disk0 and disk2, and I set the > > "boot-device" to "disk2 disk3", I think current code will do > > this: > > - prom load "zfsboot" block off disk2 > > - zfsboot block loads in the zfsloader binary from current disk (disk2) > > - which then probes disk0, disk1 .... and finally boots > > the kernel from the first freebsd-zfs partition that it finds > > on any of those disks. > > > > I think this is wrong, as there could be some data-only zfs > > partition on disk0, which doesn't have a kernel to boot from... > > > > Also, one other thing to keep in mind that the boot-device propery > > can be a devalias entry or just a straight-up device specifier, > > like this: > > > > /pci@1c,600000/scsi@2/disk@0,0:a > > > > (That's what I have on my SunFire, for various arcane reasons...) > > > > I guess we also have to worry when someone breaks into the prom > > and says "boot disk4", and that user input should override the > > "boot-device" settings in the prom. > > > > What's currently implemented in the sparc64 ZFS loader resembles > how the x86 version works as close as possible, i.e. basically > trying to detect ZFS pools on all disks available via the firmware > (i.e. BIOS in the x86 case). The current approach may not be > ideal for sparc64, but before inventing yet another one it would > be great if someone could check how this is done in (Open)Solaris, > either by digging up the relevant documentation or by actually > giving it a try. The "diskroot" and "diskmirror" devaliases that I have on the netra-T1 date back to the time when I ran Solaris 9 with disk mirroring (remember DiskSuite?) on this machine. That's when/how I learned about using "boot-device" with a space seperated list of things to probe and boot from. I continued doing exactly the same thing for Solaris 10 - first with DiskSuite, and later when they introduced ZFS booting, the same thing continued on. -Kurt From owner-freebsd-sparc64@FreeBSD.ORG Sat Jul 14 12:18:49 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1886106564A; Sat, 14 Jul 2012 12:18:49 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 571EC8FC08; Sat, 14 Jul 2012 12:18:49 +0000 (UTC) Received: from server.rulingia.com (c220-239-248-69.belrs5.nsw.optusnet.com.au [220.239.248.69]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q6ECIQAa051449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Jul 2012 22:18:26 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q6ECIKtL084176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2012 22:18:20 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q6ECIKfM084175; Sat, 14 Jul 2012 22:18:20 +1000 (EST) (envelope-from peter) Date: Sat, 14 Jul 2012 22:18:20 +1000 From: Peter Jeremy To: Anton Shterenlikht Message-ID: <20120714121820.GA84132@server.rulingia.com> References: <20120621081705.GA41013@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <20120621081705.GA41013@mech-cluster241.men.bris.ac.uk> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: gerald@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: lang/gcc46 build failure on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 12:18:50 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Jun-21 09:17:05 +0100, Anton Shterenlikht wro= te: >Apologies if I have reported this already, >I lost track with all the png- triggered updates. > >On sparc64 10.0-CURRENT #4 r235474, updating from >gcc-4.6.4.20120413 to gcc-4.6-20120608 I get:=20 > >gmake[3]: Entering directory `/usr/ports/lang/gcc46/work/build/libcpp' >/usr/ports/lang/gcc46/work/build/./prev-gcc/xgcc -B/usr/ports/lang/gcc46/w= ork/build/./prev-gcc/ -B/usr/local/sparc64-portbld-freebsd10.0/bin/ -B/usr/= local/sparc64-portbld-freebsd10.0/bin/ -B/usr/local/sparc64-portbld-freebsd= 10.0/lib/ -isystem /usr/local/sparc64-portbld-freebsd10.0/include -isystem = /usr/local/sparc64-portbld-freebsd10.0/sys-include -I.././../gcc-4.6-20= 120608/libcpp -I. -I.././../gcc-4.6-20120608/libcpp/../include -I.././../gc= c-4.6-20120608/libcpp/include -g -O2 -gtoggle -W -Wall -Wwrite-strings -Wm= issing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-styl= e-definition -Wc++-compat -pedantic -Wno-long-long -I.././../gcc-4.6-20120= 608/libcpp -I. -I.././../gcc-4.6-20120608/libcpp/../include -I.././../gcc-4= =2E6-20120608/libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .d= eps/charset.Tpo .././../gcc-4.6-20120608/libcpp/charset.c >In file included from .././../gcc-4.6-20120608/libcpp/system.h:30:0, > from .././../gcc-4.6-20120608/libcpp/charset.c:22: >/usr/ports/lang/gcc46/work/build/./prev-gcc/include/stddef.h:150:26: error= : two or more data types in declaration specifiers >gmake[3]: *** [charset.o] Error 1 Sorry for the delay but I see exactly the same on 10.0-CURRENT r238247 As a work-around, I'd suggest using ports/lang/gcc - which is the stable branch of gcc-4.6 --=20 Peter Jeremy --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlABY4wACgkQ/opHv/APuIde/gCgk68ERgghxFb8uOjM2Xz78AG9 ucMAn3V3NSXH36+17V8t84uw1Rox8RZ3 =Do/j -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-sparc64@FreeBSD.ORG Sat Jul 14 13:33:30 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2DBB11065670; Sat, 14 Jul 2012 13:33:30 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 819F68FC12; Sat, 14 Jul 2012 13:33:29 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q6EDXDA5093957; Sat, 14 Jul 2012 15:33:13 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q6EDXDUN093956; Sat, 14 Jul 2012 15:33:13 +0200 (CEST) (envelope-from marius) Date: Sat, 14 Jul 2012 15:33:13 +0200 From: Marius Strobl To: x11@freebsd.org Message-ID: <20120714133313.GA93858@alchemy.franken.de> References: <20120619104247.GA13630@mech-cluster241.men.bris.ac.uk> <20120630121634.GA94551@alchemy.franken.de> <20120709094958.GB52954@mech-cluster241.men.bris.ac.uk> <20120709130430.GN63893@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120709130430.GN63893@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: miwi@freebsd.org, freebsd-sparc64@freebsd.org, freebsd-ppc@freebsd.org Subject: Re: graphics/libGL regression on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 13:33:30 -0000 On Mon, Jul 09, 2012 at 03:04:30PM +0200, Marius Strobl wrote: > On Mon, Jul 09, 2012 at 10:49:59AM +0100, Anton Shterenlikht wrote: > > On Sat, Jun 30, 2012 at 02:16:34PM +0200, Marius Strobl wrote: > > > On Tue, Jun 19, 2012 at 11:42:47AM +0100, Anton Shterenlikht wrote: > > > > On sparc64 r235474, > > > > updating from libGL-7.4.4 to 7.6.1 I get: > > > > > > There are several problems preventing Xorg bits to build on sparc64 > > > (and powerpc) since the update to 7.5.2. First, make sure you have a > > > ports tree with graphics/libdrm/Makefile rev. 1.25. Then apply the > > > following patches: > > > http://people.freebsd.org/~bapt/fix-hal-on-sparc64.diff > > > http://people.freebsd.org/~marius/dri_libGL_libdrm.diff > > > > > > According to a quick test, the old server works fine with both the > > > mach64 and the sunffb driver on sparc64. When running `Xorg -configure` > > > you need to manually fix the resulting configuration file though > > > as any device on the PCI bus not being mach64 compatible is detected > > > as a radeon chip. > > > However, while the new server selected with WITH_NEW_XORG builds > > > just fine on sparc64 with these patches, it doesn't work there. For > > > mach64, there isn't any indication in the log why this doesn't work > > > besides "no screens found", although the configuration is correct, > > > libdrm is built without KMS support and the mach64 being detected. > > > For sunffb, it just segfaults. > > > > > > Marius > > > > Is there a PR on this? I'd like to track it. > > No, not currently; I'm waiting for bapt@ to complete a -exp-run for > the options fix and to commit that patch and on feedback from miwi@ > regarding the patch for fixing the dri, libGL and libdrm ports on > powerpc and sparc64. > Given that I haven't received any feedback on the above mentioned dri_libGL_libdrm.diff so far, I'm going to commit it on June 16th unless someone comes up with an objection and given that I can get an approval from a ports committer. %% - Since the update to the Xorg 7.5.2 bits, graphics/libdrm no longer installs the necessary headers for compiling the Intel DRI drivers on !x86 (see graphics/libdrm/Makefile rev. 1.25), so exclude them on powerpc and sparc64 as they are of no use there anyway. This now generally follows the behavior used on Linux of only building the DRI drivers that are of possible use on a given architecture. This includes no longer building the i810 DRI driver on amd64 as there is no amd64 machine in existence where it could be used. - Fix/add some endian conversion bits also preventing things from building on powerpc and sparc64. %% Marius From owner-freebsd-sparc64@FreeBSD.ORG Sat Jul 14 16:20:30 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 148931065670; Sat, 14 Jul 2012 16:20:30 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id BDAE58FC16; Sat, 14 Jul 2012 16:20:29 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Sq54x-0007Lj-Bm; Sat, 14 Jul 2012 17:20:23 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Sq54w-0002Cx-GP; Sat, 14 Jul 2012 17:20:22 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q6EGKMkQ057009; Sat, 14 Jul 2012 17:20:22 +0100 (BST) (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q6EGKLXa057008; Sat, 14 Jul 2012 17:20:21 +0100 (BST) (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Sat, 14 Jul 2012 17:20:20 +0100 From: Anton Shterenlikht To: Peter Jeremy Message-ID: <20120714162020.GA56884@mech-cluster241.men.bris.ac.uk> References: <20120621081705.GA41013@mech-cluster241.men.bris.ac.uk> <20120714121820.GA84132@server.rulingia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120714121820.GA84132@server.rulingia.com> User-Agent: Mutt/1.4.2.3i Cc: gerald@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: lang/gcc46 build failure on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 16:20:30 -0000 On Sat, Jul 14, 2012 at 10:18:20PM +1000, Peter Jeremy wrote: > On 2012-Jun-21 09:17:05 +0100, Anton Shterenlikht wrote: > >Apologies if I have reported this already, > >I lost track with all the png- triggered updates. > > > >On sparc64 10.0-CURRENT #4 r235474, updating from > >gcc-4.6.4.20120413 to gcc-4.6-20120608 I get: > > > >gmake[3]: Entering directory `/usr/ports/lang/gcc46/work/build/libcpp' > >/usr/ports/lang/gcc46/work/build/./prev-gcc/xgcc -B/usr/ports/lang/gcc46/work/build/./prev-gcc/ -B/usr/local/sparc64-portbld-freebsd10.0/bin/ -B/usr/local/sparc64-portbld-freebsd10.0/bin/ -B/usr/local/sparc64-portbld-freebsd10.0/lib/ -isystem /usr/local/sparc64-portbld-freebsd10.0/include -isystem /usr/local/sparc64-portbld-freebsd10.0/sys-include -I.././../gcc-4.6-20120608/libcpp -I. -I.././../gcc-4.6-20120608/libcpp/../include -I.././../gcc-4.6-20120608/libcpp/include -g -O2 -gtoggle -W -Wall -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -pedantic -Wno-long-long -I.././../gcc-4.6-20120608/libcpp -I. -I.././../gcc-4.6-20120608/libcpp/../include -I.././../gcc-4.6-20120608/libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo .././../gcc-4.6-20120608/libcpp/charset.c > >In file included from .././../gcc-4.6-20120608/libcpp/system.h:30:0, > > from .././../gcc-4.6-20120608/libcpp/charset.c:22: > >/usr/ports/lang/gcc46/work/build/./prev-gcc/include/stddef.h:150:26: error: two or more data types in declaration specifiers > >gmake[3]: *** [charset.o] Error 1 > > Sorry for the delay but I see exactly the same on 10.0-CURRENT r238247 > > As a work-around, I'd suggest using ports/lang/gcc - which is the > stable branch of gcc-4.6 > > -- > Peter Jeremy http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53964 -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423