From owner-freebsd-ppc@FreeBSD.ORG Sun Sep 28 10:14:07 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 361745D0 for ; Sun, 28 Sep 2014 10:14:07 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5041E4B for ; Sun, 28 Sep 2014 10:14:06 +0000 (UTC) Received: (qmail 11265 invoked from network); 28 Sep 2014 10:13:59 -0000 Received: from unknown (HELO mail-cs-03.app.dca.reflexion.local) (10.81.19.3) by 0 (rfx-qmail) with SMTP; 28 Sep 2014 10:13:59 -0000 Received: by mail-cs-03.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Sun, 28 Sep 2014 06:13:59 -0400 (EDT) Received: (qmail 10288 invoked from network); 28 Sep 2014 10:13:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 28 Sep 2014 10:13:59 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 39D781C4062 for ; Sun, 28 Sep 2014 03:13:57 -0700 (PDT) From: Mark Millard Subject: 10.1-BETA2 PowerMac G5 panic dump failure: "- oversized DMA transfer attempt 65536 > 32768" Message-Id: <0C5799BD-90B3-4BC2-9BC5-C8531401ED8D@dsl-only.net> Date: Sun, 28 Sep 2014 03:13:53 -0700 To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 10:14:07 -0000 I induced a panic dump attempt well after booting but it reported: Dumping 606MB (160 chunks) Chunk 0: 574592 bytes ata2: failure - oversized DMA transfer attempt 65536 > 32768 ... So it would appear that by default I can not get dumps for panics, at = least not on the PowerMac G5 configurations. (I'd guess that the = PowerMac G4's would be similar.) Everything else has been working for = the SSD use (the only media in place at the time --or normally). Context: FreeBSD FBSDG5M1 10.1-BETA2 FreeBSD 10.1-BETA2 #22 r271944M: Sun Sep 28 = 00:29:03 PDT 2014 root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64 = powerpc GENERIC64 with options DDB and GDB added. WITH_DEBUG_FILES=3D = WITHOUT_CLANG=3D WITH_DEBUG=3D in /etc/make.conf. Odd DDB hack (internal = automatic script definition) for boot time reporting of information to = expose what is going on for a PowerMac G5 boot crash that happens fairly = frequently --reporting despite no input working at that early stage. = Also added a call to report a kernel backtrace at during the first = OF_ after the mmu is configured, before the actual ofwcall (which may = crash). The panic here was long after booting and logging in and it is from my = using Control-option-esc to get into DDB interactively (for the first = time) and my experimenting there. I'm not worried about the specific = panic at this point. But that dumps will fail is not so good. (It would = have been my first kernel dump.) Also possibly odd is that the only media is an SSD listed as ada0 with = partitions/slices listed as various ada0s. Yet the dump failure = messages referred to ata2. There is no /dev/ata2 present. The swap = partition was on ada0s9 that it should have used for the dump. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Mon Sep 29 10:22:09 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F87A54A for ; Mon, 29 Sep 2014 10:22:09 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB3511D6 for ; Mon, 29 Sep 2014 10:22:08 +0000 (UTC) Received: (qmail 6947 invoked from network); 29 Sep 2014 10:22:01 -0000 Received: from unknown (HELO mail-cs-04.app.dca.reflexion.local) (10.81.19.4) by 0 (rfx-qmail) with SMTP; 29 Sep 2014 10:22:01 -0000 Received: by mail-cs-04.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Mon, 29 Sep 2014 06:22:01 -0400 (EDT) Received: (qmail 6285 invoked from network); 29 Sep 2014 10:22:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Sep 2014 10:22:01 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 2A66A1C405F for ; Mon, 29 Sep 2014 03:21:59 -0700 (PDT) From: Mark Millard Subject: 10.1-BETA3 and powerpc64/GENERIC64 PowerMac G5 with ATI Radeon X1950 support: broken at boot time now... Message-Id: Date: Mon, 29 Sep 2014 03:21:58 -0700 To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 10:22:09 -0000 10.1-BETA3 powerpc64/GENERIC64 on PowerMac G5 with a 'Chipset: "ATI = Radeon X1950" (ChipID =3D 0x7240)' card with vt: boot text is only a = couple of pixels high/wide. Unreadable. Repeat the visual pattern across = the screen (across, not down). [Note: This is not an Xorg/xfce4 issue in = any way.] And it appeared to be stopping very early every time so I've no clue = what it was reporting. Context (uname -a taken from a working boot context for the same SSD, = see later): FreeBSD FBSDG5M1 10.1-BETA3 FreeBSD 10.1-BETA3 #28 r272167M: Mon Sep 29 = 02:34:31 PDT 2014 root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64 = powerpc Options DDB and GDB added to GENERIC64. WITH_DEBUG_FILES=3D = WITHOUT_CLANG=3D WITH_DEBUG=3D in /etc/make.conf . DDB default script = hack for dumping early-boot crash information. Added db_trace_self() = call executed during first openfirmware_core call with MMU programmed. = (So just before the classic before-copyright hang where OF_peer(0) fails = fairly frequently.) (That is the same context as for the prior 10.1-BETA2 activity. = 10.1-BETA2 did not have this problem for this context.) I tried reverting to using sc in GENERIC64 using the same 5 lines or so = for sc that are in GENERIC. But it got build failure: ps3fb_remap was = missing because ps3_syscons.c was not compiled. That in turn was because sys/conf/files.powerpc listed = "powerpc/ps3/ps3_syscons.c optional ps3 vt" (indicating it was not = needed for syscons builds?). I changed that to = "powerpc/ps3/ps3_syscons.c optional ps3 vt | ps3 sc" and tried again. More such sys/conf/files.powerpc and/or sys/conf/files issues showed up = preventing building for sc. I gave up on being able to build powerpc64/GENERIC64 for sc directly and = rebuilt again with vt (despite the boot results for the Radeon context). (I have a 10.1-BETA2 /boot/kernel.good/kernel to use in a manual unload = then load /boot/kernel.good/kernel then boot sequence from from not = letting the G5 time out and autoboot. 10.1-BETA3's world seems to = tolerate 10.1-BETA2's kernel. Otherwise this would have been a lot = messier to deal with.) A contrasting context that worked okay... GeForce 7800 GT based = powerpc64/GENERIC64 PowerMac G5. In this case the initial variant tried was: no use of WITH_DEBUG_FILES=3D = WITHOUT_CLANG=3D WITH_DEBUG=3D or of source code hacks for = early-boot-crash information. But still adding options DDB and GDB. = So... FreeBSD FBSDG5M0 10.1-BETA3 FreeBSD 10.1-BETA3 #2 r272167M: Mon Sep 29 = 01:24:54 PDT 2014 root@FBSDG5M0:/usr/obj/usr/src/sys/GENERIC64 = powerpc Index: /usr/src/sys/powerpc/conf/GENERIC64 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/conf/GENERIC64 (revision 272167) +++ /usr/src/sys/powerpc/conf/GENERIC64 (working copy) @@ -76,6 +76,8 @@ # Debugging support. Always need this: options KDB # Enable kernel debugger = support. options KDB_TRACE # Print a stack trace for a = panic. +options DDB +options GDB =20 # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor = Kernel But simply moving the earlier SSD (once rebuilt) from the Radeon = PowerMac G5 (where it failed to display right or boot) to the GeForce = based G5 resulted in normal text and a completed boot. It looks like the problem here is tied to Radeons, or possibly to the = model of Radeon (X1950). I may put back the other NVIDIA GeForce 7800 GT = and not try to involve a PowerMac G5 Radeon in my activities for now. [The before-Copyright crash still happens randomly. None of this is = directly about that issue.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 30 08:41:48 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 711F231D for ; Tue, 30 Sep 2014 08:41:48 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA4BA2C7 for ; Tue, 30 Sep 2014 08:41:47 +0000 (UTC) Received: (qmail 25347 invoked from network); 30 Sep 2014 08:41:45 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Sep 2014 08:41:45 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Tue, 30 Sep 2014 04:41:45 -0400 (EDT) Received: (qmail 6437 invoked from network); 30 Sep 2014 08:41:44 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Sep 2014 08:41:44 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 021011C405C for ; Tue, 30 Sep 2014 01:41:42 -0700 (PDT) From: Mark Millard Message-Id: <8703D7F8-126C-4677-8892-DF6A17DEDB17@dsl-only.net> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: A different PowerMac G5 boot crash but with a backtrace: fails at .pvo_vaddr_compare+0x14, instruction ld r0, r4, 0x58 Date: Tue, 30 Sep 2014 01:41:42 -0700 References: To: FreeBSD PowerPC ML In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 08:41:48 -0000 As I understand the reported but unusual pvo_vaddr_compare point of = failure was before the usual "before Copyright notice" (ofwcall) crash. = In other words: .pvo_vaddr_compare+0x14, instruction ld r0, r4, 0x58 [or ld r0,88(r4) in = an alternate notation] .pvo_tree_RB_FIND+0x38 .moea64_dev_direct_mapped_0x90 .pmap_dev_direct_mapped+0x84 .bs_remap_earlyboot_0x6c .moea64_late_bootstrap+0x178 .moea64_bootstrap_native+0x120 .pmap_bootstrap+0xac .powerpc_init+0x514 btext+0xa8 happens before the usual "before Copyright notice" crash point: (rest of call-chain to ofwcall for peer not shown) .OF_peer+0x8c .powermac_smp_first_cpu+0x3c .platform_smp_first_cpu+0x78 .cpu_mp_setmaxid+0x2c (via .mpt_fc_els_reply_handler+0x2e68 that is not = explicitly listed) .mp_setmaxid+0x14 .mi_startup0x10c btext+0xbc =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 24, 2014, at 12:20 AM, Mark Millard = wrote: powerpc64/GENERIC64 on PowerMac G5 Quad Core: I caught a different = kernel/boot crash with a backtrace, failing at .pvo_vaddr_compare+0x14: = ld r0,88(r4). Unfortunately with my current "show register; bt; show = regster/u; bt/u" the beginning of the text from before the show's = scrolled off screen. Still... register r4: 0x2e123e8 dar: 2e12440 srr0: 0x8b8648 .pvo_vaddr_compare+0x14 lr: 0x98b8fac .pvo_tree_RB_FIND_0x38 ctr: 0x883840 moea64_dev_direct_mapped .pvo_vaddr_compare+0x14, instruction ld r0, r4, 0x58 [or ld r0,88(r4) in = an alternate notation] .pvo_tree_RB_FIND+0x38 .moea64_dev_direct_mapped_0x90 .pmap_direct_mapped+0x84 .bs_remap_earlyboot_0x6c .moea64_late_bootstrap+0x178 .moea64_bootstrap_native+0x120 .pmap_bootstrap+0xac .powerpc_init+0x514 btext+0xa8 srr1: 9000000000003030 cr: 2400024 xer 0 dsisr: 40000000 r0: 0x98008000 r1: 0xbda9f0 tmpstk+0x39f0 r2: 0xd18468 r3: 0xbdab38 tmpstk+0x3938 r4: 0x2e123e8 r5: 0xe10000 __pcpu+0xa80 r6: 0 r7: 0 r8: 0xf r9: 0x98008000 r10: 0x1 r11: 0 r12: 0x10000000 r13: 0xbdd290 thread0 r14-r19: all 0 r20: 0x10c1000 r21: 0x4 r22: 0x1801bd4 r23: 0xe42bf0 earlyboot_mapping r24: 0 r25: 0 r26: 0x100000 kernbase r27: 0xe42bf0 earlyboot_mapping r28: 0xe10000 __pcpu_0xa80 r29: 0xbdab38 tmpstk+0x3938 r30: 0x2e123e8 r31: 0xbda9f0 tmpstk+0x39f0 Context: FreeBSD FBSDG5M1 10.1-BETA2 FreeBSD 10.1-BETA2 #4 r271944M: Tue Sep 23 = 22:39:02 PDT 2014 root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64 = powerpc $ svnlite diff /usr/src/sys Index: /usr/src/sys/ddb/db_script.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/ddb/db_script.c (revision 271944) +++ /usr/src/sys/ddb/db_script.c (working copy) @@ -319,10 +319,25 @@ { char scriptname[DB_MAXSCRIPTNAME]; =20 + /* HACK!!! : Additional lines to force a basic default script to = exist. + * Will dump information even if ddb input is not available for = early crash. + * Used to get more information about PowerMac G5 "before = Copyright" hangs. + */ + struct ddb_script *dsp =3D = db_script_lookup(DB_SCRIPT_KDBENTER_DEFAULT); + if (!dsp) db_script_set(DB_SCRIPT_KDBENTER_DEFAULT, "show = registers; bt; show registers/u; bt/u"); + snprintf(scriptname, sizeof(scriptname), "%s.%s", DB_SCRIPT_KDBENTER_PREFIX, eventname); if (db_script_exec(scriptname, 0) =3D=3D ENOENT) (void)db_script_exec(DB_SCRIPT_KDBENTER_DEFAULT, 0); + + /* HACK!!! : Additional lines to always use the default script, + * even if scriptname existed and was executed. + * Will dump information even if ddb input is not available for = early crash. + * Used to get more information about PowerMac G5 "before = Copyright" hangs. + */ + else + (void)db_script_exec(DB_SCRIPT_KDBENTER_DEFAULT, 0); } =20 /*- Index: /usr/src/sys/powerpc/conf/GENERIC64 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/conf/GENERIC64 (revision 271944) +++ /usr/src/sys/powerpc/conf/GENERIC64 (working copy) @@ -76,6 +76,8 @@ # Debugging support. Always need this: options KDB # Enable kernel debugger = support. options KDB_TRACE # Print a stack trace for a = panic. +options DDB +options GDB =20 # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor = Kernel =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 30 13:37:26 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1265EF86 for ; Tue, 30 Sep 2014 13:37:26 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8FDB0C4A for ; Tue, 30 Sep 2014 13:37:24 +0000 (UTC) Received: (qmail 16713 invoked from network); 30 Sep 2014 13:37:17 -0000 Received: from unknown (HELO mail-cs-03.app.dca.reflexion.local) (10.81.19.3) by 0 (rfx-qmail) with SMTP; 30 Sep 2014 13:37:17 -0000 Received: by mail-cs-03.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Tue, 30 Sep 2014 09:37:17 -0400 (EDT) Received: (qmail 9860 invoked from network); 30 Sep 2014 13:37:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Sep 2014 13:37:16 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id EE4371C4078; Tue, 30 Sep 2014 06:37:13 -0700 (PDT) From: Mark Millard Subject: powerpc64/GENERIC64: possible misuse of tlbsync instruction for moea64_cpu_bootstrap_native? Possible lack of isync instruction? Date: Tue, 30 Sep 2014 06:37:15 -0700 Message-Id: <901E3FCC-1387-46B0-98D4-78EF286D6E6C@dsl-only.net> To: Nathan Whitehorn , FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Justin Hibbits X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 13:37:26 -0000 PowerISA_V2.07_PUBLIC.pdf page labeled 935, section 5.10.1 Page table = Updates says of tlbsync... Software must execute tlbie and tlbsync instructions only as part of the = following sequence, and must ensure that no other thread will execute a = =93conflicting instruction=94 while the instructions in the sequence are = executing on the given thread. In addition to achieving the required = system synchronization, the sequence will cause transactions that = include accesses to the affected page(s) to fail. tlbie instruction(s) specifying the same LPID oper- and value eieio tlbsync ptesync There is also the prior page (labeled 934) which says (and older = documentation seems to agree)... tlbsync should not be used to synchronize the completion of tlbiel. [Other places in the document also report that. Some older documents are = explicit about ptesync use: "To synchronize the completion of this = processor local form of tlbie, only a ptesync is required (tlbsync = should not be used)." ] But /usr/src/sys/powerpc/aim/moea64_native.c has = moea64_cpu_bootstrap_native(...) doing...=20 ... /* * Install page table */ =20 __asm __volatile ("ptesync; mtsdr1 %0; isync" :: "r"((uintptr_t)moea64_pteg_table | (uintptr_t)(flsl(moea64_pteg_mask >> 11)))); tlbia(); } which in turn does... static void tlbia(void) { vm_offset_t i; #ifndef __powerpc64__ register_t msr, scratch; #endif TLBSYNC(); for (i =3D 0; i < 0xFF000; i +=3D 0x00001000) { #ifdef __powerpc64__ __asm __volatile("tlbiel %0" :: "r"(i)); #else __asm __volatile("\ mfmsr %0; \ mr %1, %0; \ insrdi %1,%3,1,0; \ mtmsrd %1; \ isync; \ \ tlbiel %2; \ \ mtmsrd %0; \ isync;" : "=3Dr"(msr), "=3Dr"(scratch) : "r"(i), "r"(1)); #endif } EIEIO(); TLBSYNC(); } which involves... #define TLBSYNC() __asm __volatile("tlbsync; ptesync"); The first TLBSYNC() above uses tlbsync without being part of a tlbie; = eieio; tlbsync; ptesync sequence, violating the first point that I = quoted. The second also has that property but there was also a tlbiel used = first, apparently violating the second point that I quoted. tlbiel is documented in boot III-S as requiring a context-synchronizing = instruction first and a ptesync after for data access. For instruction = access: nothing before but context-synchronizing after. No tlbsync is = listed as required. For the __powerpc64__ above the tlbiel's are not followed by a = context-sychronizing instruction (sc, isync, rfid, mtmsr[d] with L=3D0, = etc.) and so would need to not effectively be involved in later = instruction access. (The ptesync is listed as execution synchronizing, = not context synchronizing.) Another quote about tlbiel (page labeled 933): The primary use of this instruction by operating system software is to = invalidate TLB entries that were created by the hypervisor using an = implemen- tation-specific hypervisor-managed TLB facility, if such a = facility is provided. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 30 15:09:59 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFDFBAA for ; Tue, 30 Sep 2014 15:09:59 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9EDB89C0 for ; Tue, 30 Sep 2014 15:09:59 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8UF9sM5006755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 30 Sep 2014 08:09:55 -0700 Message-ID: <542AC7C2.6050309@freebsd.org> Date: Tue, 30 Sep 2014 08:09:54 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Mark Millard , FreeBSD PowerPC ML Subject: Re: backtrace information from the 2nd(?) most common boot crash place on PowerMac G5's: just after real memory = ... (... MB) References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZ7kERDAh8PIqj8EXKlS8miEt345ax346kiwsTf8PMGgRAqLqoXBQb3yEaQpsvgB8SkfUxSHazaKvsRZ74vKTKpJpulvHhF1Tw= X-Sonic-ID: C;BlWX1bNI5BGNP3yTE+W37Q== M;4jXk1bNI5BGNP3yTE+W37Q== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 15:09:59 -0000 How much RAM is in the machine? I've never ever heard of this happening before and have been using one of these daily for four years. Clearly, there's something special about your configuration. This error, in particular, means that the direct map has been evicted from the page table. I can't imagine any possible way for that to happen; it's basically the least likely fault that I can think of and almost certainly indicates memory corruption or a hardware fault. Do you see this with an unmodified 10.1-BETA2 kernel? -Nathan On 09/27/14 00:47, Mark Millard wrote: > The following includes backtrace information from the 2nd most common boot crash place in the boot message sequence on PowerMac G5's: just after it reports > > real memory = ... (... MB). > > Classically it reports data storage interrupt here and it did again. But more is dumped in my current configuration than before. > > FreeBSD FBSDG5M1 10.1-BETA2 FreeBSD 10.1-BETA2 #16 r271944M: Fri Sep 26 23:01:54 PDT 2014 root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64 powerpc > > but with options DDB and DGB in GENERIC64, WITH_DEBUG_FILES=, WITHOUT_CLANG=, WIHT_DEBUG= in /etc/make.conf. Also: DDB hacked to dump various things automatically so it happens during early boot crashes/hangs. > > The information reported was... > > fatal kernel trap > > exception = 0x300 (data storage interrupt) > virtual address = 0x75e0000 > dsisr = 0x42000000 > curthread = 0xdbc290 > pid = 0, comm = > > srr0: 0x885608 .moea64_zero_page+1ac (a dcbz r0,r10) > lr: 0x8ba31c .pmap_zero_page+0x7c > ctr: 0x88545c .moea64_zero_page > > 0x8ba318: .pmap_zero_page+0x78 > 0x84167c: .kmem_back+0x2d0 > 0x8417fc: .kmem_malloc+0x7c > 0x840dc4: .vm_ksubmap_init+0x8c > 0x882130: .cpu_startup+0x10c > 0x4d9c10: .mi_startup+0x10c > btext+0xbc (???) > > r0: 0x1 > r1: 0xc000000000008740 > r2: 0xd19468 > r3: 0xe4d3a8 mmu_kernel_obj > r4: 0xc000000002bfc290 > r5: 0xc7dfa0 mmu_zero_page_desc > r6: 0xc000000000063af8 > r7: 0x2 > r8: 0xe0c310 vm_phys_free_queues > r9: 0x80 dbsize+0xc > r10: 0x7f5e0000 > r11: 0x80 dbsize_0xc > r12: 0x24042042 > r13: 0xdbc290 thread0 > r14-r19: all 0 > r20: 0x10c2000 > r21: 0x4 > r22: 0x163f000 > r23: 0xc0000000d03fd000 > r24: 0x3800 > r25: 0x262 > r26: 0x400000000000000 > r27: 0xe4d3a8 mmu_kernel_obj > r28: 0xc000000002bfc290 > r29: 0xc000000002bfc290 (yes: again) > r30: 0x75e0000 > r31: 0xc000000000008740 > > cr: 0x44042044 > xer: 0 > (I did not write down srr1. Drat.) > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 30 15:22:56 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B09D9465 for ; Tue, 30 Sep 2014 15:22:56 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E961BB1 for ; Tue, 30 Sep 2014 15:22:56 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8UFMqqC018989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 30 Sep 2014 08:22:52 -0700 Message-ID: <542ACACC.1010208@freebsd.org> Date: Tue, 30 Sep 2014 08:22:52 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Mark Millard , FreeBSD PowerPC ML Subject: Re: powerpc64/GENERIC64: possible misuse of tlbsync instruction for moea64_cpu_bootstrap_native? Possible lack of isync instruction? References: <901E3FCC-1387-46B0-98D4-78EF286D6E6C@dsl-only.net> In-Reply-To: <901E3FCC-1387-46B0-98D4-78EF286D6E6C@dsl-only.net> X-Sonic-CAuth: UmFuZG9tSVYHPolRMVjVrC03eRFaI+3lXB2Q5ZUZvrd4O79tzR66yHWon6QoWnRwcu/78exBVw1YXyUScaP6zyzILBQGC+B37saSDIG4Xq8= X-Sonic-ID: C;kMsGpbVI5BGSQnyTE+W37Q== M;xNlBpbVI5BGSQnyTE+W37Q== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Justin Hibbits X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 15:22:56 -0000 This is all fine. These two sets of instructions are somewhat special (and one-offs). The tlbsync here is unnecessary, as you note, but harmless (it dates to when using tlbie instead of tlbiel). If you think it is causing a problem for some reason, you can try swapping it with a ptesync only. -Nathan On 09/30/14 06:37, Mark Millard wrote: > PowerISA_V2.07_PUBLIC.pdf page labeled 935, section 5.10.1 Page table > Updates says of tlbsync... > > Software must execute */tlbie /*and */tlbsync /*instructions only as > part of the following sequence, and must ensure that no other thread > will execute a “conflicting instruction” while the instructions in the > sequence are executing on the given thread. In addition to achieving > the required system synchronization, the sequence will cause > transactions that include accesses to the affected page(s) to fail. > > */tlbie /*instruction(s) specifying the same LPID oper- and value > */eieio > tlbsync/* > > */ptesync/* > > There is also the prior page (labeled 934) which says (and older > documentation seems to agree)... > > */tlbsync /*should not be used to synchronize the completion of > */tlbiel/*. > > [Other places in the document also report that. Some older documents > are explicit about ptesync use: "To synchronize the completion of this > processor local form of *tlbie*, only a *ptesync *is required > (*tlbsync *should not be used)." ] > > But /usr/src/sys/powerpc/aim/moea64_native.c has > moea64_cpu_bootstrap_native(...) doing... > > ... > /* > * Install page table > */ > > __asm __volatile ("ptesync; mtsdr1 %0; isync" > :: "r"((uintptr_t)moea64_pteg_table > | (uintptr_t)(flsl(moea64_pteg_mask >> 11)))); > tlbia(); > } > > which in turn does... > > static void > tlbia(void) > { > vm_offset_t i; > #ifndef __powerpc64__ > register_t msr, scratch; > #endif > > TLBSYNC(); > > for (i = 0; i < 0xFF000; i += 0x00001000) { > #ifdef __powerpc64__ > __asm __volatile("tlbiel %0" :: "r"(i)); > #else > __asm __volatile("\ > mfmsr %0; \ > mr %1, %0; \ > insrdi %1,%3,1,0; \ > mtmsrd %1; \ > isync; \ > \ > tlbiel %2; \ > \ > mtmsrd %0; \ > isync;" > : "=r"(msr), "=r"(scratch) : "r"(i), "r"(1)); > #endif > } > > EIEIO(); > TLBSYNC(); > } > > which involves... > > #define TLBSYNC() __asm __volatile("tlbsync; ptesync"); > > The first TLBSYNC() above uses tlbsync without being part of a tlbie; > eieio; tlbsync; ptesync sequence, violating the first point that I quoted. > > The second also has that property but there was also a tlbiel used > first, apparently violating the second point that I quoted. > > > tlbiel is documented in boot III-S as requiring a > context-synchronizing instruction first and a ptesync after for data > access. For instruction access: nothing before but > context-synchronizing after. No tlbsync is listed as required. > > For the __powerpc64__ above the tlbiel's are not followed by a > context-sychronizing instruction (sc, isync, rfid, mtmsr[d] with L=0, > etc.) and so would need to not effectively be involved in later > instruction access. (The ptesync is listed as execution synchronizing, > not context synchronizing.) > > > > Another quote about tlbiel (page labeled 933): > > The primary use of this instruction by operating system software is to > invalidate TLB entries that were created by the hypervisor using an > implemen- tation-specific hypervisor-managed TLB facility, if such a > facility is provided. > > > > > > > === > Mark Millard > markmi at dsl-only.net > From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 30 15:24:24 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EA32142 for ; Tue, 30 Sep 2014 15:24:24 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6ECF6BE3 for ; Tue, 30 Sep 2014 15:24:24 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8UFOKRI020316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 30 Sep 2014 08:24:21 -0700 Message-ID: <542ACB24.5070003@freebsd.org> Date: Tue, 30 Sep 2014 08:24:20 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Mark Millard , FreeBSD PowerPC ML Subject: Re: 10.1-BETA3 and powerpc64/GENERIC64 PowerMac G5 with ATI Radeon X1950 support: broken at boot time now... References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYsoKGGgo8QsPKHjEuoAZ3cReUg01H4ShwNUjYBN9bQ/XuO/gTJpLl7NtkliEntNC8X2LKOzs0+3Hqc2TtrgPfLhjj174MCY88= X-Sonic-ID: C;BK/F2bVI5BGiinyTE+W37Q== M;Evn+2bVI5BGiinyTE+W37Q== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 15:24:24 -0000 What is your screen resolution? I suspect you are overflowing vt's early-boot framebuffer area. syscons is not supported on PS3, but you can remove PS3 from your kernel configuration to use it on powermacs. -Nathan On 09/29/14 03:21, Mark Millard wrote: > 10.1-BETA3 powerpc64/GENERIC64 on PowerMac G5 with a 'Chipset: "ATI Radeon X1950" (ChipID = 0x7240)' card with vt: boot text is only a couple of pixels high/wide. Unreadable. Repeat the visual pattern across the screen (across, not down). [Note: This is not an Xorg/xfce4 issue in any way.] > > And it appeared to be stopping very early every time so I've no clue what it was reporting. > > > Context (uname -a taken from a working boot context for the same SSD, see later): > > FreeBSD FBSDG5M1 10.1-BETA3 FreeBSD 10.1-BETA3 #28 r272167M: Mon Sep 29 02:34:31 PDT 2014 root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64 powerpc > > Options DDB and GDB added to GENERIC64. WITH_DEBUG_FILES= WITHOUT_CLANG= WITH_DEBUG= in /etc/make.conf . DDB default script hack for dumping early-boot crash information. Added db_trace_self() call executed during first openfirmware_core call with MMU programmed. (So just before the classic before-copyright hang where OF_peer(0) fails fairly frequently.) > > (That is the same context as for the prior 10.1-BETA2 activity. 10.1-BETA2 did not have this problem for this context.) > > > > > I tried reverting to using sc in GENERIC64 using the same 5 lines or so for sc that are in GENERIC. But it got build failure: ps3fb_remap was missing because ps3_syscons.c was not compiled. > > That in turn was because sys/conf/files.powerpc listed "powerpc/ps3/ps3_syscons.c optional ps3 vt" (indicating it was not needed for syscons builds?). I changed that to "powerpc/ps3/ps3_syscons.c optional ps3 vt | ps3 sc" and tried again. > > More such sys/conf/files.powerpc and/or sys/conf/files issues showed up preventing building for sc. > > I gave up on being able to build powerpc64/GENERIC64 for sc directly and rebuilt again with vt (despite the boot results for the Radeon context). > > (I have a 10.1-BETA2 /boot/kernel.good/kernel to use in a manual unload then load /boot/kernel.good/kernel then boot sequence from from not letting the G5 time out and autoboot. 10.1-BETA3's world seems to tolerate 10.1-BETA2's kernel. Otherwise this would have been a lot messier to deal with.) > > > > A contrasting context that worked okay... GeForce 7800 GT based powerpc64/GENERIC64 PowerMac G5. > > In this case the initial variant tried was: no use of WITH_DEBUG_FILES= WITHOUT_CLANG= WITH_DEBUG= or of source code hacks for early-boot-crash information. But still adding options DDB and GDB. So... > > FreeBSD FBSDG5M0 10.1-BETA3 FreeBSD 10.1-BETA3 #2 r272167M: Mon Sep 29 01:24:54 PDT 2014 root@FBSDG5M0:/usr/obj/usr/src/sys/GENERIC64 powerpc > > Index: /usr/src/sys/powerpc/conf/GENERIC64 > =================================================================== > --- /usr/src/sys/powerpc/conf/GENERIC64 (revision 272167) > +++ /usr/src/sys/powerpc/conf/GENERIC64 (working copy) > @@ -76,6 +76,8 @@ > # Debugging support. Always need this: > options KDB # Enable kernel debugger support. > options KDB_TRACE # Print a stack trace for a panic. > +options DDB > +options GDB > > # Make an SMP-capable kernel by default > options SMP # Symmetric MultiProcessor Kernel > > > > But simply moving the earlier SSD (once rebuilt) from the Radeon PowerMac G5 (where it failed to display right or boot) to the GeForce based G5 resulted in normal text and a completed boot. > > It looks like the problem here is tied to Radeons, or possibly to the model of Radeon (X1950). I may put back the other NVIDIA GeForce 7800 GT and not try to involve a PowerMac G5 Radeon in my activities for now. > > [The before-Copyright crash still happens randomly. None of this is directly about that issue.] > > > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 30 20:49:40 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34566398 for ; Tue, 30 Sep 2014 20:49:40 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA63EB97 for ; Tue, 30 Sep 2014 20:49:38 +0000 (UTC) Received: (qmail 2386 invoked from network); 30 Sep 2014 20:42:45 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Sep 2014 20:42:45 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Tue, 30 Sep 2014 16:42:45 -0400 (EDT) Received: (qmail 5651 invoked from network); 30 Sep 2014 20:42:45 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Sep 2014 20:42:45 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 34A761C4056; Tue, 30 Sep 2014 13:42:40 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: backtrace information from the 2nd(?) most common boot crash place on PowerMac G5's: just after real memory = ... (... MB) From: Mark Millard In-Reply-To: <542AC7C2.6050309@freebsd.org> Date: Tue, 30 Sep 2014 13:42:39 -0700 Message-Id: <4215450E-4C67-4B68-9370-846F23D4789F@dsl-only.net> References: <542AC7C2.6050309@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 20:49:40 -0000 While crashing between the the real memory message place and the avail = message message place in the sequence of messages has been the second = most common place in the message sequence to fail, it has been rather = rare: In months I've only seen it a few times despite all my reboots = from the primary crash place issue and for deliberate testing/evidence = finding about the boot crashes. (My primary FreeBSD activity is = exploring FreeBSD via investigating the problems I have, primarily the = early boot crash.) I've seen it crash there on a variety of versions since I've been = updating regularly but it crashes there only rarely. Only in recent = times have I been building from source instead of using the MANIFEST and = *.txz files with bsdinstall or before that using the .iso images. It = crashed there back before I'd ever installed a kernel or world via my = own build. Of course with the DDB dump hack in place I get more information as = things are now. Unfortunately with the rarity I'm not able to effectively test if a = specific installation/version/build/... has the problem or not. The best = that I've got is to report the information I get on the rare occasion it = does fail. The 3 PowerMac G5's have: 8 GB (Dual processor), 12 GB (Quad core), 16 = GB (Quad core). I have tended to use the 16 GB one primarily/mostly. But = it sounds like I should switch to one of the others as the primary for a = few months to see how things go for this issue. While I think that I've seen that stopping place on more than one of the = G5's it is possible that I'm wrong about that given the rarity. If I'm = right about it then I may never have seen the problem on the 8 GB Dual = processor one: more likely the two Quad cores. But, again, I'm not = sure. I tend to use the Dual processor one the least by a noticeable = amount, however. I certainly have seen the primary crash relative to message timing = (before the Copyright notice) on all 3 G5's ever since I started = exploring FreeBSD. Of course only with the DDB dump hack in place do I = have evidence of just where those crashes happen internally. I have reported one backtrace that is earlier then the first ofwcall = with pmap_bootstrapped!=3D0. It is the only example I have of that so = far. Again: before the DDB hack I'd not have the evidence to make the = distinction in place and it seems too rare to deliberately test for any = specific build/version having the problem. I've not tested if the .iso's still have the during-openfirmware loading = boot-hang problem on the G5's in some time. So I do not know the status = for that. I'm really curious what the explanation is for the first ofwcall with = pmap_bootstrapped!=3D0 sometimes failing and sometimes not. And = similarly for other variability --but the other crashes seem to rare to = have much chance of learning the answer. =3D=3D=3D Mark Millard markmi@dsl-only.net On Sep 30, 2014, at 8:09 AM, Nathan Whitehorn = wrote: How much RAM is in the machine? I've never ever heard of this happening = before and have been using one of these daily for four years. Clearly, = there's something special about your configuration. This error, in = particular, means that the direct map has been evicted from the page = table. I can't imagine any possible way for that to happen; it's = basically the least likely fault that I can think of and almost = certainly indicates memory corruption or a hardware fault. Do you see = this with an unmodified 10.1-BETA2 kernel? -Nathan On 09/27/14 00:47, Mark Millard wrote: > The following includes backtrace information from the 2nd most common = boot crash place in the boot message sequence on PowerMac G5's: just = after it reports >=20 > real memory =3D ... (... MB). >=20 > Classically it reports data storage interrupt here and it did again. = But more is dumped in my current configuration than before. >=20 > FreeBSD FBSDG5M1 10.1-BETA2 FreeBSD 10.1-BETA2 #16 r271944M: Fri Sep = 26 23:01:54 PDT 2014 root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64 = powerpc >=20 > but with options DDB and DGB in GENERIC64, WITH_DEBUG_FILES=3D, = WITHOUT_CLANG=3D, WIHT_DEBUG=3D in /etc/make.conf. Also: DDB hacked to = dump various things automatically so it happens during early boot = crashes/hangs. >=20 > The information reported was... >=20 > fatal kernel trap >=20 > exception =3D 0x300 (data storage interrupt) > virtual address =3D 0x75e0000 > dsisr =3D 0x42000000 > curthread =3D 0xdbc290 > pid =3D 0, comm =3D >=20 > srr0: 0x885608 .moea64_zero_page+1ac (a dcbz r0,r10) > lr: 0x8ba31c .pmap_zero_page+0x7c > ctr: 0x88545c .moea64_zero_page >=20 > 0x8ba318: .pmap_zero_page+0x78 > 0x84167c: .kmem_back+0x2d0 > 0x8417fc: .kmem_malloc+0x7c > 0x840dc4: .vm_ksubmap_init+0x8c > 0x882130: .cpu_startup+0x10c > 0x4d9c10: .mi_startup+0x10c > btext+0xbc (???) >=20 > r0: 0x1 > r1: 0xc000000000008740 > r2: 0xd19468 > r3: 0xe4d3a8 mmu_kernel_obj > r4: 0xc000000002bfc290 > r5: 0xc7dfa0 mmu_zero_page_desc > r6: 0xc000000000063af8 > r7: 0x2 > r8: 0xe0c310 vm_phys_free_queues > r9: 0x80 dbsize+0xc > r10: 0x7f5e0000 > r11: 0x80 dbsize_0xc > r12: 0x24042042 > r13: 0xdbc290 thread0 > r14-r19: all 0 > r20: 0x10c2000 > r21: 0x4 > r22: 0x163f000 > r23: 0xc0000000d03fd000 > r24: 0x3800 > r25: 0x262 > r26: 0x400000000000000 > r27: 0xe4d3a8 mmu_kernel_obj > r28: 0xc000000002bfc290 > r29: 0xc000000002bfc290 (yes: again) > r30: 0x75e0000 > r31: 0xc000000000008740 >=20 > cr: 0x44042044 > xer: 0 > (I did not write down srr1. Drat.) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >=20 From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 30 21:36:39 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1AA508B1 for ; Tue, 30 Sep 2014 21:36:39 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9608A343 for ; Tue, 30 Sep 2014 21:36:38 +0000 (UTC) Received: (qmail 17714 invoked from network); 30 Sep 2014 21:36:37 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 Sep 2014 21:36:37 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Tue, 30 Sep 2014 17:36:36 -0400 (EDT) Received: (qmail 12987 invoked from network); 30 Sep 2014 21:36:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Sep 2014 21:36:36 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id A59011C4053; Tue, 30 Sep 2014 14:36:31 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: 10.1-BETA3 and powerpc64/GENERIC64 PowerMac G5 with ATI Radeon X1950 support: broken at boot time now... From: Mark Millard In-Reply-To: <542ACB24.5070003@freebsd.org> Date: Tue, 30 Sep 2014 14:36:34 -0700 Message-Id: <550AC539-0B97-4F4C-9B30-E435F67366E6@dsl-only.net> References: <542ACB24.5070003@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 21:36:39 -0000 I tried the 1920x1200 display instead of the 2560x1440 one and it then = worked. I should have thought of that test. 10.1-BETA2 used the whole screen for 2560x1440, although for a while the = far right hand side would show the start of the next line as well = (buffer width wrap). I prefer 10.1-BETA2's behavior for the size issue = to what happens now under 10.1-BETA3 (useless display). But (new experiment) the 2560x1440 display works when the card is a = GeForce 7800 GT instead of the Radeon X1950 (same boot SSD, same type of = PowerMac G5: Quad core). For the 7800 GT it just uses a small area in = the middle as the console instead of trying to use the whole display. = (Too bad it is as small as it is but it does work. I'd not be able to = see all the text from my early-crash DDB dumps in the little area used. = For now having lots of lines during boot is important for my context.) (Xorg does not seem to handle the X1950, leaving console mode as the = only option with that card. I can revert to another 7800 GT if I decide = it is appropriate.) =3D=3D=3D Mark Millard markmi@dsl-only.net On Sep 30, 2014, at 8:24 AM, Nathan Whitehorn = wrote: What is your screen resolution? I suspect you are overflowing vt's = early-boot framebuffer area. syscons is not supported on PS3, but you = can remove PS3 from your kernel configuration to use it on powermacs. -Nathan On 09/29/14 03:21, Mark Millard wrote: > 10.1-BETA3 powerpc64/GENERIC64 on PowerMac G5 with a 'Chipset: "ATI = Radeon X1950" (ChipID =3D 0x7240)' card with vt: boot text is only a = couple of pixels high/wide. Unreadable. Repeat the visual pattern across = the screen (across, not down). [Note: This is not an Xorg/xfce4 issue in = any way.] >=20 > And it appeared to be stopping very early every time so I've no clue = what it was reporting. >=20 >=20 > Context (uname -a taken from a working boot context for the same SSD, = see later): >=20 > FreeBSD FBSDG5M1 10.1-BETA3 FreeBSD 10.1-BETA3 #28 r272167M: Mon Sep = 29 02:34:31 PDT 2014 root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64 = powerpc >=20 > Options DDB and GDB added to GENERIC64. WITH_DEBUG_FILES=3D = WITHOUT_CLANG=3D WITH_DEBUG=3D in /etc/make.conf . DDB default script = hack for dumping early-boot crash information. Added db_trace_self() = call executed during first openfirmware_core call with MMU programmed. = (So just before the classic before-copyright hang where OF_peer(0) fails = fairly frequently.) >=20 > (That is the same context as for the prior 10.1-BETA2 activity. = 10.1-BETA2 did not have this problem for this context.) >=20 >=20 >=20 >=20 > I tried reverting to using sc in GENERIC64 using the same 5 lines or = so for sc that are in GENERIC. But it got build failure: ps3fb_remap was = missing because ps3_syscons.c was not compiled. >=20 > That in turn was because sys/conf/files.powerpc listed = "powerpc/ps3/ps3_syscons.c optional ps3 vt" (indicating it was not = needed for syscons builds?). I changed that to = "powerpc/ps3/ps3_syscons.c optional ps3 vt | ps3 sc" and tried again. >=20 > More such sys/conf/files.powerpc and/or sys/conf/files issues showed = up preventing building for sc. >=20 > I gave up on being able to build powerpc64/GENERIC64 for sc directly = and rebuilt again with vt (despite the boot results for the Radeon = context). >=20 > (I have a 10.1-BETA2 /boot/kernel.good/kernel to use in a manual = unload then load /boot/kernel.good/kernel then boot sequence from from = not letting the G5 time out and autoboot. 10.1-BETA3's world seems to = tolerate 10.1-BETA2's kernel. Otherwise this would have been a lot = messier to deal with.) >=20 >=20 >=20 > A contrasting context that worked okay... GeForce 7800 GT based = powerpc64/GENERIC64 PowerMac G5. >=20 > In this case the initial variant tried was: no use of = WITH_DEBUG_FILES=3D WITHOUT_CLANG=3D WITH_DEBUG=3D or of source code = hacks for early-boot-crash information. But still adding options DDB and = GDB. So... >=20 > FreeBSD FBSDG5M0 10.1-BETA3 FreeBSD 10.1-BETA3 #2 r272167M: Mon Sep 29 = 01:24:54 PDT 2014 root@FBSDG5M0:/usr/obj/usr/src/sys/GENERIC64 = powerpc >=20 > Index: /usr/src/sys/powerpc/conf/GENERIC64 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/powerpc/conf/GENERIC64 (revision 272167) > +++ /usr/src/sys/powerpc/conf/GENERIC64 (working copy) > @@ -76,6 +76,8 @@ > # Debugging support. Always need this: > options KDB # Enable kernel debugger = support. > options KDB_TRACE # Print a stack trace for a = panic. > +options DDB > +options GDB > # Make an SMP-capable kernel by default > options SMP # Symmetric MultiProcessor = Kernel >=20 >=20 >=20 > But simply moving the earlier SSD (once rebuilt) from the Radeon = PowerMac G5 (where it failed to display right or boot) to the GeForce = based G5 resulted in normal text and a completed boot. >=20 > It looks like the problem here is tied to Radeons, or possibly to the = model of Radeon (X1950). I may put back the other NVIDIA GeForce 7800 GT = and not try to involve a PowerMac G5 Radeon in my activities for now. >=20 > [The before-Copyright crash still happens randomly. None of this is = directly about that issue.] >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >=20 From owner-freebsd-ppc@FreeBSD.ORG Tue Sep 30 23:21:46 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E10EAAE for ; Tue, 30 Sep 2014 23:21:46 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C43935D for ; Tue, 30 Sep 2014 23:21:45 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8UNLY4F008579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 30 Sep 2014 16:21:35 -0700 Message-ID: <542B3AFC.6040106@freebsd.org> Date: Tue, 30 Sep 2014 16:21:32 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Mark Millard Subject: Re: 10.1-BETA3 and powerpc64/GENERIC64 PowerMac G5 with ATI Radeon X1950 support: broken at boot time now... References: <542ACB24.5070003@freebsd.org> <550AC539-0B97-4F4C-9B30-E435F67366E6@dsl-only.net> In-Reply-To: <550AC539-0B97-4F4C-9B30-E435F67366E6@dsl-only.net> X-Sonic-CAuth: UmFuZG9tSVbsZxrCKCMdDS/KNOukTVr2xdiy75oO52WorkE+iG0TLc7uVuPbbvlmdgu4qH/F3NlYWoXmDNZKwjDQ5CW/y00ltjurc1dixQU= X-Sonic-ID: C;Lj/mhPhI5BGk+3yTE+W37Q== M;3tMehfhI5BGk+3yTE+W37Q== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 23:21:46 -0000 OK, we can bump the max screen size. As an aside, if you use vt(4) instead of syscons, you can use X even on unsupported cards with the xf86-video-scfb driver. It will be unaccelerated, but it will work. -Nathan On 09/30/14 14:36, Mark Millard wrote: > I tried the 1920x1200 display instead of the 2560x1440 one and it then > worked. I should have thought of that test. > > 10.1-BETA2 used the whole screen for 2560x1440, although for a while > the far right hand side would show the start of the next line as well > (buffer width wrap). I prefer 10.1-BETA2's behavior for the size issue > to what happens now under 10.1-BETA3 (useless display). > > But (new experiment) the 2560x1440 display works when the card is a > GeForce 7800 GT instead of the Radeon X1950 (same boot SSD, same type > of PowerMac G5: Quad core). For the 7800 GT it just uses a small area > in the middle as the console instead of trying to use the whole > display. (Too bad it is as small as it is but it does work. I'd not be > able to see all the text from my early-crash DDB dumps in the little > area used. For now having lots of lines during boot is important for > my context.) > > (Xorg does not seem to handle the X1950, leaving console mode as the > only option with that card. I can revert to another 7800 GT if I > decide it is appropriate.) > > > === > Mark Millard > markmi@dsl-only.net > > On Sep 30, 2014, at 8:24 AM, Nathan Whitehorn > wrote: > > What is your screen resolution? I suspect you are overflowing vt's > early-boot framebuffer area. syscons is not supported on PS3, but you > can remove PS3 from your kernel configuration to use it on powermacs. > -Nathan > > On 09/29/14 03:21, Mark Millard wrote: >> 10.1-BETA3 powerpc64/GENERIC64 on PowerMac G5 with a 'Chipset: "ATI >> Radeon X1950" (ChipID = 0x7240)' card with vt: boot text is only a >> couple of pixels high/wide. Unreadable. Repeat the visual pattern >> across the screen (across, not down). [Note: This is not an >> Xorg/xfce4 issue in any way.] >> >> And it appeared to be stopping very early every time so I've no clue >> what it was reporting. >> >> >> Context (uname -a taken from a working boot context for the same SSD, >> see later): >> >> FreeBSD FBSDG5M1 10.1-BETA3 FreeBSD 10.1-BETA3 #28 r272167M: Mon Sep >> 29 02:34:31 PDT 2014 root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64 >> powerpc >> >> Options DDB and GDB added to GENERIC64. WITH_DEBUG_FILES= >> WITHOUT_CLANG= WITH_DEBUG= in /etc/make.conf . DDB default script >> hack for dumping early-boot crash information. Added db_trace_self() >> call executed during first openfirmware_core call with MMU >> programmed. (So just before the classic before-copyright hang where >> OF_peer(0) fails fairly frequently.) >> >> (That is the same context as for the prior 10.1-BETA2 activity. >> 10.1-BETA2 did not have this problem for this context.) >> >> >> >> >> I tried reverting to using sc in GENERIC64 using the same 5 lines or >> so for sc that are in GENERIC. But it got build failure: ps3fb_remap >> was missing because ps3_syscons.c was not compiled. >> >> That in turn was because sys/conf/files.powerpc listed >> "powerpc/ps3/ps3_syscons.c optional ps3 vt" (indicating it was not >> needed for syscons builds?). I changed that to >> "powerpc/ps3/ps3_syscons.c optional ps3 vt | ps3 sc" and tried again. >> >> More such sys/conf/files.powerpc and/or sys/conf/files issues showed >> up preventing building for sc. >> >> I gave up on being able to build powerpc64/GENERIC64 for sc directly >> and rebuilt again with vt (despite the boot results for the Radeon >> context). >> >> (I have a 10.1-BETA2 /boot/kernel.good/kernel to use in a manual >> unload then load /boot/kernel.good/kernel then boot sequence from >> from not letting the G5 time out and autoboot. 10.1-BETA3's world >> seems to tolerate 10.1-BETA2's kernel. Otherwise this would have been >> a lot messier to deal with.) >> >> >> >> A contrasting context that worked okay... GeForce 7800 GT based >> powerpc64/GENERIC64 PowerMac G5. >> >> In this case the initial variant tried was: no use of >> WITH_DEBUG_FILES= WITHOUT_CLANG= WITH_DEBUG= or of source code hacks >> for early-boot-crash information. But still adding options DDB and >> GDB. So... >> >> FreeBSD FBSDG5M0 10.1-BETA3 FreeBSD 10.1-BETA3 #2 r272167M: Mon Sep >> 29 01:24:54 PDT 2014 root@FBSDG5M0:/usr/obj/usr/src/sys/GENERIC64 >> powerpc >> >> Index: /usr/src/sys/powerpc/conf/GENERIC64 >> =================================================================== >> --- /usr/src/sys/powerpc/conf/GENERIC64(revision 272167) >> +++ /usr/src/sys/powerpc/conf/GENERIC64(working copy) >> @@ -76,6 +76,8 @@ >> # Debugging support. Always need this: >> options KDB# Enable kernel debugger support. >> options KDB_TRACE# Print a stack trace for a panic. >> +options DDB >> +options GDB >> # Make an SMP-capable kernel by default >> options SMP# Symmetric MultiProcessor Kernel >> >> >> >> But simply moving the earlier SSD (once rebuilt) from the Radeon >> PowerMac G5 (where it failed to display right or boot) to the GeForce >> based G5 resulted in normal text and a completed boot. >> >> It looks like the problem here is tied to Radeons, or possibly to the >> model of Radeon (X1950). I may put back the other NVIDIA GeForce 7800 >> GT and not try to involve a PowerMac G5 Radeon in my activities for now. >> >> [The before-Copyright crash still happens randomly. None of this is >> directly about that issue.] >> >> >> >> === >> Mark Millard >> markmi at dsl-only.net >> >> _______________________________________________ >> freebsd-ppc@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc >> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >> > > From owner-freebsd-ppc@FreeBSD.ORG Wed Oct 1 04:50:12 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11EA9E97 for ; Wed, 1 Oct 2014 04:50:12 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 762BA90D for ; Wed, 1 Oct 2014 04:50:10 +0000 (UTC) Received: (qmail 15658 invoked from network); 1 Oct 2014 04:50:09 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 1 Oct 2014 04:50:09 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.30.7) with SMTP; Wed, 01 Oct 2014 00:50:09 -0400 (EDT) Received: (qmail 21981 invoked from network); 1 Oct 2014 04:50:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Oct 2014 04:50:08 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-98-246-178-138.hsd1.or.comcast.net [98.246.178.138]) by iron2.pdx.net (Postfix) with ESMTPSA id 371BF1C4053; Tue, 30 Sep 2014 21:50:01 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: 10.1-BETA3 and powerpc64/GENERIC64 PowerMac G5 with ATI Radeon X1950 support: broken at boot time now... From: Mark Millard In-Reply-To: <542B3AFC.6040106@freebsd.org> Date: Tue, 30 Sep 2014 21:50:03 -0700 Message-Id: <8CE0EF30-AFB4-4A8C-BC3E-618F2F55E31C@dsl-only.net> References: <542ACB24.5070003@freebsd.org> <550AC539-0B97-4F4C-9B30-E435F67366E6@dsl-only.net> <542B3AFC.6040106@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 04:50:12 -0000 Multiple thanks (size handling improvement, scfb hint, earlier notes on = experimenting with the code, and what should be true of what I asked = about)! I portmaster'd xf86-video-scfb. Unfortunately it does not work for my = most-of-interest context for it: Radeon X1950. scfb ends up unloaded = instead. I initially tried it for the GeForce 7800 GT based PowerMac G5 Quad = core. Xorg.0.log which reported needing 8 bit depth. With that fixed in = xorg.conf the result was a display with odd colors, mostly lots of red = as I remember, but it was doing something. So I tried the same SSD in the Radeon X1950 G5 Quad core PowerMac. = Xorg.0.log reported needing 32 bit depth. But fixing that in xorg.conf = that was not enough to make it work: it then complained about "(EE) = scfb(0): Weight given (000) is inconsistent with the depth (32)" and = then unloaded scfb. =46rom Xorg.0.log: ... [ 321.133] (II) LoadModule: "scfb" [ 321.134] (II) Loading = /usr/local/lib/xorg/modules/drivers/scfb_drv.so [ 321.134] (II) Module scfb: vendor=3D"X.Org Foundation" [ 321.134] compiled for 1.12.4, module version =3D 0.0.4 [ 321.134] ABI class: X.Org Video Driver, version 12.1 [ 321.134] (II) scfb: driver for wsdisplay framebuffer: scfb [ 321.154] (--) Using syscons driver with X support (version = 8595229351.252) [ 321.154] (--) using VT number 9 [ 321.154] (WW) Falling back to old probe method for scfb [ 321.154] scfb trace: probe start [ 321.154] (II) scfb(0): using default device [ 321.154] scfb trace: probe done [ 321.154] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card = support [ 321.154] scfb: PreInit 0 [ 321.154] (II) scfb(0): Using: depth (32), width (1920), height = (1200) [ 321.154] (**) scfb(0): Depth 32, (--) framebuffer bpp 32 [ 321.154] (EE) scfb(0): Weight given (000) is inconsistent with the = depth (32) [ 321.154] (II) UnloadModule: "scfb" [ 321.154] (EE) Screen(s) found, but none have a usable configuration. [ 321.154]=20 Fatal server error: [ 321.154] no screens found (Side note: It is too bad that Xorg says "Using syscons driver ..." for = vt contexts. That mislead me originally.) =3D=3D=3D Mark Millard markmi at dsl-only.net On Sep 30, 2014, at 4:21 PM, Nathan Whitehorn wrote: OK, we can bump the max screen size. As an aside, if you use vt(4) = instead of syscons, you can use X even on unsupported cards with the = xf86-video-scfb driver. It will be unaccelerated, but it will work. -Nathan On 09/30/14 14:36, Mark Millard wrote: > I tried the 1920x1200 display instead of the 2560x1440 one and it then = worked. I should have thought of that test. >=20 > 10.1-BETA2 used the whole screen for 2560x1440, although for a while = the far right hand side would show the start of the next line as well = (buffer width wrap). I prefer 10.1-BETA2's behavior for the size issue = to what happens now under 10.1-BETA3 (useless display). >=20 > But (new experiment) the 2560x1440 display works when the card is a = GeForce 7800 GT instead of the Radeon X1950 (same boot SSD, same type of = PowerMac G5: Quad core). For the 7800 GT it just uses a small area in = the middle as the console instead of trying to use the whole display. = (Too bad it is as small as it is but it does work. I'd not be able to = see all the text from my early-crash DDB dumps in the little area used. = For now having lots of lines during boot is important for my context.) >=20 > (Xorg does not seem to handle the X1950, leaving console mode as the = only option with that card. I can revert to another 7800 GT if I decide = it is appropriate.) >=20 >=20 > =3D=3D=3D > Mark Millard > markmi@dsl-only.net >=20 > On Sep 30, 2014, at 8:24 AM, Nathan Whitehorn = wrote: >=20 > What is your screen resolution? I suspect you are overflowing vt's = early-boot framebuffer area. syscons is not supported on PS3, but you = can remove PS3 from your kernel configuration to use it on powermacs. > -Nathan >=20 > On 09/29/14 03:21, Mark Millard wrote: >> 10.1-BETA3 powerpc64/GENERIC64 on PowerMac G5 with a 'Chipset: "ATI = Radeon X1950" (ChipID =3D 0x7240)' card with vt: boot text is only a = couple of pixels high/wide. Unreadable. Repeat the visual pattern across = the screen (across, not down). [Note: This is not an Xorg/xfce4 issue in = any way.] >>=20 >> And it appeared to be stopping very early every time so I've no clue = what it was reporting. >>=20 >>=20 >> Context (uname -a taken from a working boot context for the same SSD, = see later): >>=20 >> FreeBSD FBSDG5M1 10.1-BETA3 FreeBSD 10.1-BETA3 #28 r272167M: Mon Sep = 29 02:34:31 PDT 2014 root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64 = powerpc >>=20 >> Options DDB and GDB added to GENERIC64. WITH_DEBUG_FILES=3D = WITHOUT_CLANG=3D WITH_DEBUG=3D in /etc/make.conf . DDB default script = hack for dumping early-boot crash information. Added db_trace_self() = call executed during first openfirmware_core call with MMU programmed. = (So just before the classic before-copyright hang where OF_peer(0) fails = fairly frequently.) >>=20 >> (That is the same context as for the prior 10.1-BETA2 activity. = 10.1-BETA2 did not have this problem for this context.) >>=20 >>=20 >>=20 >>=20 >> I tried reverting to using sc in GENERIC64 using the same 5 lines or = so for sc that are in GENERIC. But it got build failure: ps3fb_remap was = missing because ps3_syscons.c was not compiled. >>=20 >> That in turn was because sys/conf/files.powerpc listed = "powerpc/ps3/ps3_syscons.c optional ps3 vt" (indicating it was not = needed for syscons builds?). I changed that to = "powerpc/ps3/ps3_syscons.c optional ps3 vt | ps3 sc" and tried again. >>=20 >> More such sys/conf/files.powerpc and/or sys/conf/files issues showed = up preventing building for sc. >>=20 >> I gave up on being able to build powerpc64/GENERIC64 for sc directly = and rebuilt again with vt (despite the boot results for the Radeon = context). >>=20 >> (I have a 10.1-BETA2 /boot/kernel.good/kernel to use in a manual = unload then load /boot/kernel.good/kernel then boot sequence from from = not letting the G5 time out and autoboot. 10.1-BETA3's world seems to = tolerate 10.1-BETA2's kernel. Otherwise this would have been a lot = messier to deal with.) >>=20 >>=20 >>=20 >> A contrasting context that worked okay... GeForce 7800 GT based = powerpc64/GENERIC64 PowerMac G5. >>=20 >> In this case the initial variant tried was: no use of = WITH_DEBUG_FILES=3D WITHOUT_CLANG=3D WITH_DEBUG=3D or of source code = hacks for early-boot-crash information. But still adding options DDB and = GDB. So... >>=20 >> FreeBSD FBSDG5M0 10.1-BETA3 FreeBSD 10.1-BETA3 #2 r272167M: Mon Sep = 29 01:24:54 PDT 2014 root@FBSDG5M0:/usr/obj/usr/src/sys/GENERIC64 = powerpc >>=20 >> Index: /usr/src/sys/powerpc/conf/GENERIC64 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/powerpc/conf/GENERIC64 (revision 272167) >> +++ /usr/src/sys/powerpc/conf/GENERIC64 (working copy) >> @@ -76,6 +76,8 @@ >> # Debugging support. Always need this: >> options KDB # Enable kernel debugger support. >> options KDB_TRACE # Print a stack trace for a panic. >> +options DDB >> +options GDB >> # Make an SMP-capable kernel by default >> options SMP # Symmetric MultiProcessor Kernel >>=20 >>=20 >>=20 >> But simply moving the earlier SSD (once rebuilt) from the Radeon = PowerMac G5 (where it failed to display right or boot) to the GeForce = based G5 resulted in normal text and a completed boot. >>=20 >> It looks like the problem here is tied to Radeons, or possibly to the = model of Radeon (X1950). I may put back the other NVIDIA GeForce 7800 GT = and not try to involve a PowerMac G5 Radeon in my activities for now. >>=20 >> [The before-Copyright crash still happens randomly. None of this is = directly about that issue.] >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-ppc@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc >> To unsubscribe, send any mail to = "freebsd-ppc-unsubscribe@freebsd.org" >>=20 >=20 >=20 From owner-freebsd-ppc@FreeBSD.ORG Wed Oct 1 08:00:37 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6C3A2F6 for ; Wed, 1 Oct 2014 08:00:37 +0000 (UTC) Received: from mail-s93.mailgun.info (mail-s93.mailgun.info [184.173.153.221]) by mx1.freebsd.org (Postfix) with ESMTP id 6A0A38F9 for ; Wed, 1 Oct 2014 08:00:37 +0000 (UTC) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=soundestdirect.com; q=dns/txt; s=pic; t=1412150436; h=Date: Message-Id: List-Unsubscribe: From: To: Subject: Content-Type: Mime-Version: Sender; bh=7ysK8rC3LLOwmLvx/eix+jTwHg+Q0HmAL0F0zziikYg=; b=NAPKLT9OL64GEpacmgVrbJHSUXvM4/je1nfia3d3rOFoe6Q9okTmFnDolYC6tzbThiAqGcCy h02X7wJwRJNUUwQb1zXjw+Nq9ZIo+3p8FE0OnvgCPDwYpeMhHnm0u1KlV1mVkihUvzrS+5S8 tyBo3Xdn5NyEx+gI1S9a15DxMk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=soundestdirect.com; s=pic; q=dns; h=Date: Message-Id: List-Unsubscribe: From: To: Subject: Content-Type: Mime-Version: Sender; b=jZv5+WzXW/db9kfr3PWshVk/GnWhQwrlILt55ZV7jxWvMbV1fXVJcSoKQOM6bhFdmY0rDs vvAgexcCxU4AfgXGn9VJoQyIFbv4bFliHdpvKvu5PjIXcuhn2vYesMMSnc1lAaRfJm9/PoJa zQM1EIt9dsGiGiZ3MIdJSmJiSOW4g= Received: from [127.0.0.1] (app-1.radar.soundest.net [192.96.207.97]) by mxa.mailgun.org with ESMTP id 542bb4a4.57f3ba0-in1; Wed, 01 Oct 2014 08:00:36 -0000 (UTC) Date: Wed, 01 Oct 2014 08:00:34 GMT Message-Id: <42b4c5ecf99c8ca2e24007be8d3c1f@app-1> From: "Johan Watson" To: freebsd-ppc@freebsd.org Subject: October Specials from Furnways Mime-Version: 1.0 X-Mailgun-Sid: WyJiMTIyOSIsICJmcmVlYnNkLXBwY0BmcmVlYnNkLm9yZyIsICI1ODNjNSJd Sender: sales=furnways.co.za@soundestdirect.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 08:00:37 -0000 Hospitality Furniture [Web version](http://furnways-uoonf0.soundestdirect.= com/view/542ba73858026ef77f21399c/54264699fe7da963021cb809) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f2139= 95/542ba73858026ef77f21399c/54264699fe7da963021cb809) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f2139= 94/542ba73858026ef77f21399c/54264699fe7da963021cb809) Furnways - Corporate Turnkey Solutions [**Furnways is a leading office furniture supplier**](http://furnways-uoonf= 0.soundestdirect.com/link/542ba6f558026ef77f213993/542ba73858026ef77f21399c= /54264699fe7da963021cb809) in South Africa. WE offer the widest range of = products, from executive desks [to school furniture](http://furnways-uoonf0= .soundestdirect.com/link/542ba6f558026ef77f213992/542ba73858026ef77f21399c/= 54264699fe7da963021cb809). We are the biggest online furniture store in = Africa, delivering high quality products at affordable prices, = understanding our customers' need to acquire top of the line furniture for = their business with reasonable investments. If you are looking for stylish = furniture for your office, hotel or restaurant, then this is the perfect = place for you, as we specialize in creating innovative and chic designs for= your furniture. [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213991= /542ba73858026ef77f21399c/54264699fe7da963021cb809) [ Wimpey Side Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213991/542ba73858026ef77f21399c/54264699fe7da963= 021cb809) Available in over 20 Colours 5 Year Warranty. R240.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213991/542ba73858026ef77f21399c/54264699fe7da963021cb809) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213990= /542ba73858026ef77f21399c/54264699fe7da963021cb809) [ Wimpey Arm Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213990/542ba73858026ef77f21399c/54264699fe7da963= 021cb809) Available in over 20 Colours 5 Year Warranty. R260.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213990/542ba73858026ef77f21399c/54264699fe7da963021cb809) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398f= /542ba73858026ef77f21399c/54264699fe7da963021cb809) [ Wimpey Ultra Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398f/542ba73858026ef77f21399c/54264699fe7da963= 021cb809) Available in over 20 Colours 5 Year Warranty. R280.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398f/542ba73858026ef77f21399c/54264699fe7da963021cb809) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398e= /542ba73858026ef77f21399c/54264699fe7da963021cb809) [ Chloe Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398e/542ba73858026ef77f21399c/54264699fe7da963= 021cb809) Available in over 20 Colours 5 Year Warranty. R480.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398e/542ba73858026ef77f21399c/54264699fe7da963021cb809) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398d= /542ba73858026ef77f21399c/54264699fe7da963021cb809) [ Alpine Chairs ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398d/542ba73858026ef77f21399c/54264699fe7da963= 021cb809) Available in over 20 Colours 5 Year Warranty. R132.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398d/542ba73858026ef77f21399c/54264699fe7da963021cb809) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398c= /542ba73858026ef77f21399c/54264699fe7da963021cb809) [ Avatar Caf=C3=A9 Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398c/542ba73858026ef77f21399c/54264699fe7da963= 021cb809) Available in over 20 Colours 5 Year Warranty. R260.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398c/542ba73858026ef77f21399c/54264699fe7da963021cb809) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398b= /542ba73858026ef77f21399c/54264699fe7da963021cb809) [ Double Pedestal Desk ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398b/542ba73858026ef77f21399c/54264699fe7da963= 021cb809) 32mm Melamine Top 1800mm*900mm Single Pedestal: R2865 Available in a variety of colours 5 Year Warranty R3540.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398b/542ba73858026ef77f21399c/54264699fe7da963021cb809) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398a= /542ba73858026ef77f21399c/54264699fe7da963021cb809) [ Rectangular Tables ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398a/542ba73858026ef77f21399c/54264699fe7da963= 021cb809) 16mm Melamine Tops Available in Oak, Mahogany or Supawood 1800 * 900 From R1093 1400 * 700 From R663 1200 * 600 From R504=C2=A0 5 Year Warranty R504.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398a/542ba73858026ef77f21399c/54264699fe7da963021cb809) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213989= /542ba73858026ef77f21399c/54264699fe7da963021cb809) [ Perforated Metal Set ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213989/542ba73858026ef77f21399c/54264699fe7da963= 021cb809) Contains: 2 tier letter tray Paper bin Pencil cup Paper cube 5 Year Warranty **Available in Siver for R1428** Black/White: R1165.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213989/542ba73858026ef77f21399c/54264699fe7da963021cb809) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213988= /542ba73858026ef77f21399c/54264699fe7da963021cb809) [ Big & Tall Heavy Duty Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213988/542ba73858026ef77f21399c/54264699fe7da963= 021cb809) Supports Up to 150kg Leather Seat Chrome base Chrome arms with polyurethane pads 5 Year Warranty R3496.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213988/542ba73858026ef77f21399c/54264699fe7da963021cb809) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213987= /542ba73858026ef77f21399c/54264699fe7da963021cb809) [ Spine Ergonomic High Back Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213987/542ba73858026ef77f21399c/54264699fe7da963= 021cb809) 2 Part shell Permanent contact mechanism Adjustable arms Available in leather Loads of extras and materials available 5 Year Warranty R1750.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213987/542ba73858026ef77f21399c/54264699fe7da963021cb809) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213986= /542ba73858026ef77f21399c/54264699fe7da963021cb809) [ Lucea 1500 Ergonomic Typist Chair ](http://furnways-uoonf0.soundestdirect= .com/link/542ba6f558026ef77f213986/542ba73858026ef77f21399c/54264699fe7da96= 3021cb809) Ergonomic shaped back with rake and height adjustment Standard with black nylon base Available in leather Loads of extras and materials available 5 Year Warranty R811.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213986/542ba73858026ef77f21399c/54264699fe7da963021cb809) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f2139= 85/542ba73858026ef77f21399c/54264699fe7da963021cb809) =C2=A0[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f= 213984/542ba73858026ef77f21399c/54264699fe7da963021cb809)=C2=A0 =C2=A0[ = ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213983/5= 42ba73858026ef77f21399c/54264699fe7da963021cb809)=C2=A0 =C2=A0[ = ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213982/5= 42ba73858026ef77f21399c/54264699fe7da963021cb809)=C2=A0 [sales@furnways.co.za](mailto:sales@furnways.co.za) Furnways Lonehill Boulevard , 22 , Sandton , 2062 , South Africa All prices are in ZAR and excludes VAT and delivery =C2=A9 2014 Furnways [Unsubscribe](http://furnways-uoonf0.soundestdirect.= com/unsubscribe/542ba73858026ef77f21399c/54264699fe7da963021cb809) Proudly delivered by [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213981= /542ba73858026ef77f21399c/54264699fe7da963021cb809)