From owner-freebsd-sparc64@freebsd.org Fri Jan 8 15:42:42 2016 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F078A67713; Fri, 8 Jan 2016 15:42:42 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:10::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies, LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EE5831314; Fri, 8 Jan 2016 15:42:41 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net ([IPv6:2001:470:e254:11:52:fed0:33f2:51b0]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id u08FgXfU086972; Fri, 8 Jan 2016 10:42:40 -0500 (EST) (envelope-from lidl@pix.net) X-Authentication-Warning: hydra.pix.net: Host [IPv6:2001:470:e254:11:52:fed0:33f2:51b0] claimed to be torb.pix.net From: Kurt Lidl Subject: sparc64 traps during probe (r293243) Cc: FreeBSD-Current To: freebsd-sparc64@freebsd.org Message-ID: <568FD8E9.30702@pix.net> Date: Fri, 8 Jan 2016 10:42:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 15:42:42 -0000 I recently updated a sparc64 V120 from r291993 to r293243, and it now traps during the autoconfiguration phase of the kernel boot: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... jumping to kernel entry at 0xc00b0000. GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2016 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 11.0-CURRENT #4 r293243M: Thu Jan 7 13:50:04 EST 2016 lidl@ton.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64 gcc version 4.2.1 20070831 patched [FreeBSD] WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. real memory = 2147483648 (2048 MB) avail memory = 2063785984 (1968 MB) cpu0: Sun Microsystems UltraSparc-IIe Processor (648.00 MHz CPU) [...] da0 at sym0 bus 0 scbus2 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: Serial Number UPL3P310365J da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) da0: Command Queueing enabled da0: 34732MB (71132959 512 byte sectors) cd0 at ata2 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: 393MB (201600 2048 byte sectors) da1 at sym0 bus 0 scbus2 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: Serial Number UPL3P3506STC da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) da1: Command Queueing enabled da1: 34732MB (71132959 512 byte sectors) WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from zfs:sys/ROOT/default []... GEOM_MIRROR: Device mirror/gswap launched (2/2). [ thread pid 1 tid 100002 ] Stopped at tl0_utrap+0x20: ldx [%l0 + %l1], %l0 db> bt Tracing pid 1 tid 100002 td 0xfffff800016164d0 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- data access exception sfar=0xfffffcf821ca0218 sfsr=0x41029 %o7=0xc06165e8 -- sched_clock() at sched_clock+0x94 statclock_cnt() at statclock_cnt+0x1c0 handleevents() at handleevents+0x138 timercb() at timercb+0x410 tick_intr() at tick_intr+0x220 -- interrupt level=0xe pil=0 %o7=0xc09c6c20 -- -- kernel stack fault %o7=0xc00b1288 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011f8f0 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc And then the stack backtrace just keeps repeating. -Kurt From owner-freebsd-sparc64@freebsd.org Fri Jan 8 17:15:13 2016 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79FDAA6753A; Fri, 8 Jan 2016 17:15:13 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 231771B37; Fri, 8 Jan 2016 17:15:12 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from host86-147-229-66.range86-147.btcentralplus.com ([86.147.229.66] helo=[192.168.1.65]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1aHaMv-0001xV-Se; Fri, 08 Jan 2016 16:58:32 +0000 To: Kurt Lidl , freebsd-sparc64@freebsd.org References: <568FD8E9.30702@pix.net> Cc: FreeBSD-Current From: Mark Cave-Ayland Message-ID: <568FEA96.9010003@ilande.co.uk> Date: Fri, 8 Jan 2016 16:57:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <568FD8E9.30702@pix.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 86.147.229.66 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on s16892447.onlinehome-server.info X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=ham version=3.3.2 Subject: Re: sparc64 traps during probe (r293243) X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: Yes (on s16892447.onlinehome-server.info) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 17:15:13 -0000 On 08/01/16 15:42, Kurt Lidl wrote: > I recently updated a sparc64 V120 from r291993 > to r293243, and it now traps during the > autoconfiguration phase of the kernel boot: > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > jumping to kernel entry at 0xc00b0000. > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2016 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 11.0-CURRENT #4 r293243M: Thu Jan 7 13:50:04 EST 2016 > lidl@ton.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64 > gcc version 4.2.1 20070831 patched [FreeBSD] > WARNING: WITNESS option enabled, expect reduced performance. > VT: init without driver. > real memory = 2147483648 (2048 MB) > avail memory = 2063785984 (1968 MB) > cpu0: Sun Microsystems UltraSparc-IIe Processor (648.00 MHz CPU) > > [...] > > da0 at sym0 bus 0 scbus2 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: Serial Number UPL3P310365J > da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > da0: Command Queueing enabled > da0: 34732MB (71132959 512 byte sectors) > cd0 at ata2 bus 0 scbus0 target 0 lun 0 > cd0: Removable CD-ROM SCSI device > cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd0: 393MB (201600 2048 byte sectors) > da1 at sym0 bus 0 scbus2 target 1 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: Serial Number UPL3P3506STC > da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > da1: Command Queueing enabled > da1: 34732MB (71132959 512 byte sectors) > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from zfs:sys/ROOT/default []... > GEOM_MIRROR: Device mirror/gswap launched (2/2). > [ thread pid 1 tid 100002 ] > Stopped at tl0_utrap+0x20: ldx [%l0 + %l1], %l0 > db> bt > Tracing pid 1 tid 100002 td 0xfffff800016164d0 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- data access exception sfar=0xfffffcf821ca0218 sfsr=0x41029 > %o7=0xc06165e8 -- > sched_clock() at sched_clock+0x94 > statclock_cnt() at statclock_cnt+0x1c0 > handleevents() at handleevents+0x138 > timercb() at timercb+0x410 > tick_intr() at tick_intr+0x220 > -- interrupt level=0xe pil=0 %o7=0xc09c6c20 -- > -- kernel stack fault %o7=0xc00b1288 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011f8f0 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > > And then the stack backtrace just keeps repeating. This looks amazingly similar to what I get trying to boot FreeBSD under QEMU, i.e. pointing at sched_clock(): Booting [/boot/kernel/kernel]... jumping to kernel entry at 0xc00b0000. GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2015 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 11.0-CURRENT #0 1eb7424(master): Thu Sep 24 06:41:18 BST 2015 mca@freebsd:/usr/home/mca/obj/sparc64.sparc64/usr/home/mca/src/sys/GENERIC sparc64 gcc version 4.2.1 20070831 patched [FreeBSD] WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. real memory = 134217728 (128 MB) avail memory = 98312192 (93 MB) cpu0: Sun Microsystems UltraSparc-IIi Processor (100.00 MHz CPU) random: entropy device external interface kbd0 at kbdmux0 nexus0: nexus0: : incomplete pcib0: mem 0x1fe00000000-0x1fe01ffffff irq 2032,2030,2031,2021 on nexus0 pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 33MHz pcib0: DVMA map: 0xc0000000 to 0xc3ffffff 8192 entries pcib0: [GIANT-LOCKED] pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 1.1 on pci0 pci2: on pcib2 ebus0: port 0x4000-0x7fff mem 0x3000000-0x3ffffff at device 3.0 on pci0 vgapci0: mem 0x1000000-0x1ffffff,0x2000000-0x2000fff at device 2.0 on pci0 vgapci0: Boot video device eeprom0: addr 0x1400002000-0x1400003fff on ebus0 eeprom0: model mk48t59 ebus0: addr 0 (no driver attached) uart0: <16550 or compatible> addr 0x14000003f8-0x14000003ff irq 43 on ebus0 uart0: console (9600,n,8,1) ebus0: addr 0x1400000060-0x1400000067 (no driver attached) pci0: at device 4.0 (no driver attached) atapci0: port 0x8100-0x8107,0x8180-0x8183,0x8200-0x8207,0x8280-0x8283,0x8300-0x830f at device 5.0 on pci0 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 cryptosoft0: on nexus0 nexus0: type unknown (no driver attached) Timecounter "tick" frequency 100000000 Hz quality 1000 Event timer "tick" frequency 100000000 Hz quality 1000 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. cd0 at ata3 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number QM00003 cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: cd present [250560 x 2048 byte records] WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from cd9660:/dev/iso9660/TEST [ro]... [ thread pid 1 tid 100002 ] Stopped at tl1_trap+0x24: stx %o0, [%sp + 0x997] db> bt Tracing pid 1 tid 100002 td 0xfffff800015e84d0 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc05743e0 -- sched_clock() at sched_clock+0x94 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- db_read_bytes() at db_read_bytes+0x44 KDB: reentering KDB: stack backtrace: kdb_reenter() at kdb_reenter+0x5c trap() at trap+0x2fc -- kernel stack fault %o7=0xc011a050 -- panic: longjmp botch cpuid = -1012475520 KDB: stack backtrace: Uptime: 3s Note also the "longjmp botch" error right at the end. This is with the sun4u timer fix patch developed with help from Marius which has recently been applied to QEMU git master. So maybe this is a kernel bug after all? ATB, Mark. From owner-freebsd-sparc64@freebsd.org Fri Jan 8 18:58:06 2016 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4E87A68087; Fri, 8 Jan 2016 18:58:06 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F83F180C; Fri, 8 Jan 2016 18:58:06 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id u08Iw2rt087230 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Jan 2016 19:58:02 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id u08Iw1Xl087229; Fri, 8 Jan 2016 19:58:01 +0100 (CET) (envelope-from marius) Date: Fri, 8 Jan 2016 19:58:01 +0100 From: Marius Strobl To: Kurt Lidl Cc: freebsd-sparc64@freebsd.org, FreeBSD-Current Subject: Re: sparc64 traps during probe (r293243) Message-ID: <20160108185801.GA87189@alchemy.franken.de> References: <568FD8E9.30702@pix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <568FD8E9.30702@pix.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Fri, 08 Jan 2016 19:58:02 +0100 (CET) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 18:58:07 -0000 On Fri, Jan 08, 2016 at 10:42:33AM -0500, Kurt Lidl wrote: > I recently updated a sparc64 V120 from r291993 > to r293243, and it now traps during the > autoconfiguration phase of the kernel boot: > <...> > -- data access exception sfar=0xfffffcf821ca0218 sfsr=0x41029 > %o7=0xc06165e8 -- What code line does 0xc06165e8 translate to? Marius From owner-freebsd-sparc64@freebsd.org Fri Jan 8 19:04:07 2016 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18680A68406; Fri, 8 Jan 2016 19:04:07 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A676A1F5A; Fri, 8 Jan 2016 19:04:06 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id u08J44PH087279 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Jan 2016 20:04:04 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id u08J43Og087278; Fri, 8 Jan 2016 20:04:03 +0100 (CET) (envelope-from marius) Date: Fri, 8 Jan 2016 20:04:03 +0100 From: Marius Strobl To: Mark Cave-Ayland Cc: Kurt Lidl , freebsd-sparc64@freebsd.org, FreeBSD-Current Subject: Re: sparc64 traps during probe (r293243) Message-ID: <20160108190403.GB87189@alchemy.franken.de> References: <568FD8E9.30702@pix.net> <568FEA96.9010003@ilande.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <568FEA96.9010003@ilande.co.uk> User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Fri, 08 Jan 2016 20:04:04 +0100 (CET) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 19:04:07 -0000 On Fri, Jan 08, 2016 at 04:57:58PM +0000, Mark Cave-Ayland wrote: > On 08/01/16 15:42, Kurt Lidl wrote: > > This looks amazingly similar to what I get trying to boot FreeBSD under > QEMU, i.e. pointing at sched_clock(): > <...> > -- kernel stack fault %o7=0xc011a050 -- > panic: longjmp botch > cpuid = -1012475520 > KDB: stack backtrace: > Uptime: 3s > > Note also the "longjmp botch" error right at the end. This is with the > sun4u timer fix patch developed with help from Marius which has recently > been applied to QEMU git master. So maybe this is a kernel bug after all? No, that still is a completely trashed kernel stack as previously seen when running under QEMU so the whole backtrace is questionable. Apart from that, sched_clock() is called rather frequently so it is not unlikely to show up in a kernel back trace but neither of the two back traces in question suggest it's the culprit (assuming that the one seen with QEMU actually is sane). Marius From owner-freebsd-sparc64@freebsd.org Fri Jan 8 20:42:25 2016 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2242CA67A07; Fri, 8 Jan 2016 20:42:25 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:10::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies, LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EB2701F30; Fri, 8 Jan 2016 20:42:24 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net ([IPv6:2001:470:e254:11:52:fed0:33f2:51b0]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id u08KgG1w058952; Fri, 8 Jan 2016 15:42:23 -0500 (EST) (envelope-from lidl@pix.net) X-Authentication-Warning: hydra.pix.net: Host [IPv6:2001:470:e254:11:52:fed0:33f2:51b0] claimed to be torb.pix.net Subject: Re: sparc64 traps during probe (r293243) To: Mark Cave-Ayland , freebsd-sparc64@freebsd.org References: <568FD8E9.30702@pix.net> <568FEA96.9010003@ilande.co.uk> Cc: FreeBSD-Current From: Kurt Lidl Message-ID: <56901F28.2040002@pix.net> Date: Fri, 8 Jan 2016 15:42:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568FEA96.9010003@ilande.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 20:42:25 -0000 On 1/8/16 11:57 AM, Mark Cave-Ayland wrote: > On 08/01/16 15:42, Kurt Lidl wrote: > >> I recently updated a sparc64 V120 from r291993 >> to r293243, and it now traps during the >> autoconfiguration phase of the kernel boot: >> >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> jumping to kernel entry at 0xc00b0000. >> GDB: no debug ports present >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2016 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 11.0-CURRENT #4 r293243M: Thu Jan 7 13:50:04 EST 2016 >> lidl@ton.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64 >> gcc version 4.2.1 20070831 patched [FreeBSD] >> WARNING: WITNESS option enabled, expect reduced performance. >> VT: init without driver. >> real memory = 2147483648 (2048 MB) >> avail memory = 2063785984 (1968 MB) >> cpu0: Sun Microsystems UltraSparc-IIe Processor (648.00 MHz CPU) >> >> [...] >> >> da0 at sym0 bus 0 scbus2 target 0 lun 0 >> da0: Fixed Direct Access SCSI-3 device >> da0: Serial Number UPL3P310365J >> da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) >> da0: Command Queueing enabled >> da0: 34732MB (71132959 512 byte sectors) >> cd0 at ata2 bus 0 scbus0 target 0 lun 0 >> cd0: Removable CD-ROM SCSI device >> cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >> cd0: 393MB (201600 2048 byte sectors) >> da1 at sym0 bus 0 scbus2 target 1 lun 0 >> da1: Fixed Direct Access SCSI-3 device >> da1: Serial Number UPL3P3506STC >> da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) >> da1: Command Queueing enabled >> da1: 34732MB (71132959 512 byte sectors) >> WARNING: WITNESS option enabled, expect reduced performance. >> Trying to mount root from zfs:sys/ROOT/default []... >> GEOM_MIRROR: Device mirror/gswap launched (2/2). >> [ thread pid 1 tid 100002 ] >> Stopped at tl0_utrap+0x20: ldx [%l0 + %l1], %l0 >> db> bt >> Tracing pid 1 tid 100002 td 0xfffff800016164d0 >> KDB: reentering >> KDB: stack backtrace: >> kdb_reenter() at kdb_reenter+0x5c >> trap() at trap+0x2fc >> -- data access exception sfar=0xfffffcf821ca0218 sfsr=0x41029 >> %o7=0xc06165e8 -- >> sched_clock() at sched_clock+0x94 >> statclock_cnt() at statclock_cnt+0x1c0 >> handleevents() at handleevents+0x138 >> timercb() at timercb+0x410 >> tick_intr() at tick_intr+0x220 >> -- interrupt level=0xe pil=0 %o7=0xc09c6c20 -- >> -- kernel stack fault %o7=0xc00b1288 -- >> db_read_bytes() at db_read_bytes+0x44 >> KDB: reentering >> KDB: stack backtrace: >> kdb_reenter() at kdb_reenter+0x5c >> trap() at trap+0x2fc >> -- kernel stack fault %o7=0xc011f8f0 -- >> db_read_bytes() at db_read_bytes+0x44 >> KDB: reentering >> KDB: stack backtrace: >> kdb_reenter() at kdb_reenter+0x5c >> trap() at trap+0x2fc >> >> And then the stack backtrace just keeps repeating. > > This looks amazingly similar to what I get trying to boot FreeBSD under > QEMU, i.e. pointing at sched_clock(): > > > Booting [/boot/kernel/kernel]... > jumping to kernel entry at 0xc00b0000. > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2015 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 11.0-CURRENT #0 1eb7424(master): Thu Sep 24 06:41:18 BST 2015 > > mca@freebsd:/usr/home/mca/obj/sparc64.sparc64/usr/home/mca/src/sys/GENERIC > sparc64 > gcc version 4.2.1 20070831 patched [FreeBSD] > WARNING: WITNESS option enabled, expect reduced performance. > VT: init without driver. > real memory = 134217728 (128 MB) > avail memory = 98312192 (93 MB) > cpu0: Sun Microsystems UltraSparc-IIi Processor (100.00 MHz CPU) > random: entropy device external interface > kbd0 at kbdmux0 > nexus0: > nexus0: : incomplete > pcib0: mem 0x1fe00000000-0x1fe01ffffff irq > 2032,2030,2031,2021 on nexus0 > pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 33MHz > pcib0: DVMA map: 0xc0000000 to 0xc3ffffff 8192 entries > pcib0: [GIANT-LOCKED] > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > pcib2: at device 1.1 on pci0 > pci2: on pcib2 > ebus0: port 0x4000-0x7fff mem 0x3000000-0x3ffffff at > device 3.0 on pci0 > vgapci0: mem > 0x1000000-0x1ffffff,0x2000000-0x2000fff at device 2.0 on pci0 > vgapci0: Boot video device > eeprom0: addr 0x1400002000-0x1400003fff on ebus0 > eeprom0: model mk48t59 > ebus0: addr 0 (no driver attached) > uart0: <16550 or compatible> addr 0x14000003f8-0x14000003ff irq 43 on ebus0 > uart0: console (9600,n,8,1) > ebus0: addr 0x1400000060-0x1400000067 (no driver attached) > pci0: at device 4.0 (no driver attached) > atapci0: port > 0x8100-0x8107,0x8180-0x8183,0x8200-0x8207,0x8280-0x8283,0x8300-0x830f at > device 5.0 on pci0 > ata2: at channel 0 on atapci0 > ata3: at channel 1 on atapci0 > cryptosoft0: on nexus0 > nexus0: type unknown (no driver attached) > Timecounter "tick" frequency 100000000 Hz quality 1000 > Event timer "tick" frequency 100000000 Hz quality 1000 > Timecounters tick every 1.000 msec > IPsec: Initialized Security Association Processing. > cd0 at ata3 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI device > cd0: Serial Number QM00003 > cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd0: cd present [250560 x 2048 byte records] > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from cd9660:/dev/iso9660/TEST [ro]... > [ thread pid 1 tid 100002 ] > Stopped at tl1_trap+0x24: stx %o0, [%sp + 0x997] > db> bt > Tracing pid 1 tid 100002 td 0xfffff800015e84d0 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc05743e0 -- > sched_clock() at sched_clock+0x94 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > db_read_bytes() at db_read_bytes+0x44 > KDB: reentering > KDB: stack backtrace: > kdb_reenter() at kdb_reenter+0x5c > trap() at trap+0x2fc > -- kernel stack fault %o7=0xc011a050 -- > panic: longjmp botch > cpuid = -1012475520 > KDB: stack backtrace: > Uptime: 3s > > > Note also the "longjmp botch" error right at the end. This is with the > sun4u timer fix patch developed with help from Marius which has recently > been applied to QEMU git master. So maybe this is a kernel bug after all? > > > ATB, > > Mark. > I decided to try a completely up to date tree, so I cross-built r293425 on an amd64 machine and copied to the sparc64. That kernel did work, much to my surprise. I have updated the source tree on the sparc64 to the same version and am now doing a buildworld natively. -Kurt From owner-freebsd-sparc64@freebsd.org Fri Jan 8 20:45:33 2016 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF381A67BB9; Fri, 8 Jan 2016 20:45:33 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:10::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies, LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AF37712C6; Fri, 8 Jan 2016 20:45:33 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net ([IPv6:2001:470:e254:11:52:fed0:33f2:51b0]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id u08Kj2Px059004; Fri, 8 Jan 2016 15:45:10 -0500 (EST) (envelope-from lidl@pix.net) X-Authentication-Warning: hydra.pix.net: Host [IPv6:2001:470:e254:11:52:fed0:33f2:51b0] claimed to be torb.pix.net Subject: Re: sparc64 traps during probe (r293243) To: Marius Strobl References: <568FD8E9.30702@pix.net> <20160108185801.GA87189@alchemy.franken.de> Cc: FreeBSD-Current , freebsd-sparc64@freebsd.org From: Kurt Lidl Message-ID: <56901FCE.1040605@pix.net> Date: Fri, 8 Jan 2016 15:45:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160108185801.GA87189@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 20:45:34 -0000 On 1/8/16 1:58 PM, Marius Strobl wrote: > On Fri, Jan 08, 2016 at 10:42:33AM -0500, Kurt Lidl wrote: >> I recently updated a sparc64 V120 from r291993 >> to r293243, and it now traps during the >> autoconfiguration phase of the kernel boot: >> > > <...> > >> -- data access exception sfar=0xfffffcf821ca0218 sfsr=0x41029 >> %o7=0xc06165e8 -- > > What code line does 0xc06165e8 translate to? > > Marius Unfortunately, I cannot tell you. I managed to destroy the /usr/lib/debug/boot/kernel directory for the kernel that didn't work properly. As noted in a different reply, a cross-built r293425 kernel did boot, and I'm now re-building a native r293425 world on the sparc64 host. If it the native build doesn't work, I'll get the information you wanted from that build. Thanks. -Kurt