From owner-freebsd-ppc@FreeBSD.ORG Sun Feb 8 09:16:37 2015 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 28F59A9C for ; Sun, 8 Feb 2015 09:16:37 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 D7632FB0 for ; Sun, 8 Feb 2015 09:16:35 +0000 (UTC) Received: (qmail 27375 invoked from network); 8 Feb 2015 09:16:34 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Feb 2015 09:16:34 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 08 Feb 2015 04:16:34 -0500 (EST) Received: (qmail 2952 invoked from network); 8 Feb 2015 09:16:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Feb 2015 09:16:33 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 43DC6B1E001; Sun, 8 Feb 2015 01:16:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: HEADS UP: powerpc64 kernel format change [booted a PowerMac G5 quad-core][__syncicache is running at the time of the crashes] From: Mark Millard In-Reply-To: <449E0C48-B57D-4873-B2E7-BC217D891897@dsl-only.net> Date: Sun, 8 Feb 2015 01:16:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <335C8DCD-33DF-4430-A0FA-77669C513C61@dsl-only.net> <449E0C48-B57D-4873-B2E7-BC217D891897@dsl-only.net> To: Nathan Whitehorn X-Mailer: Apple Mail (2.2070.6) 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: Sun, 08 Feb 2015 09:16:37 -0000 I've narrowed down greatly where the crashes happen, which need not be = where root-cause is: that could be earlier. In the following code [I'm using 10.1-RELEASE-p5 for reference here] $ svnlite diff sys/boot/ofw/libofw/ppc64_elf_freebsd.c=20 Index: sys/boot/ofw/libofw/ppc64_elf_freebsd.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/ofw/libofw/ppc64_elf_freebsd.c (revision 277808) +++ sys/boot/ofw/libofw/ppc64_elf_freebsd.c (working copy) @@ -59,7 +59,11 @@ * be done by the kernel after relocation. */ if (!strcmp((*result)->f_type, "elf kernel")) +{ +printf("ppc64_ofw_elf_loadfile before __syncicache\n"); __syncicache((void *) (*result)->f_addr, = (*result)->f_size); +printf("ppc64_ofw_elf_loadfile after __syncicache\n"); +} return (0); } for a directly-bootable (no crash) kernel-build both printf's are = displayed. (The above code part of /boot/loader .) But for the kernels that I build that fail to directly boot only the = first of the two printf's is displayed when a direct boot is attempted: = Openfirmware's notice with %SRR0 and %SRR1 shows up after that instead = of the text from the second printf. Based on that much it looks like the crash is either in evaluating the = arguments to __syncicache or happens during __syncicache's execution, = not after. Changing the first printf to something like the sequence: printf("ppc64_ofw_elf_loadfile before __syncicache\n"); printf("(void*)result: %p\n",(void*)result); printf("(void*)(*result): %p\n",(void*)(*result)); printf("(void*)(*result)->f_addr: %p\n",(void*)(*result)->f_addr); printf("(*result)->f_size : 0x%lx\n",(*result)->f_size); Shows that all of the stages print before the crash happens, answering = the question about evaluation of the arguments: there is no problem = evaluating them. So the crashes are strictly during __syncicache's activity. Only (*result)->f_size varies between the 3 examples that I've used: 10.1-RELEASE-p5 variant without VERBOSE_SYSINIT (and BOOTVERBOSE, = BOOTHOWTO). (boots fine) 10.1-RELEASE-p5 variant with VERBOSE_SYSINIT (and BOOTVERBOSE, = BOOTHOWTO). (crashes) 10.1-STABLE (-r278028) variant without VERBOSE_SYSINIT (and BOOTVERBOSE, = BOOTHOWTO). (crashes) What the above printf's reported was: (void*)result: 0x1c35b48 (void*)(*result): 0x1ebc0 (*result)->f_addr: 0x100000 10.1-RELEASE-p5 variant without VERBOSE_SYSINIT: (*result)->f_size: = 0x1014b80 10.1-RELEASE-p5 variant with VERBOSE_SYSINIT: (*result)->f_size: = 0x1014bb0 10.1-STABLE (-r278028) variant without VERBOSE_SYSINIT: = (*result)->f_size: 0x10175d0 (Listed in increasing order.) As I remember for the last two the crash report listed %SRR0: 0x1c2785c = for both. The "without VERBOSE_SYSINIT" one above does not crash and for = it the "ppc64_ofw_elf_loadfile after __syncicache" message shows up as = it should. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Feb-7, at 09:43 AM, Mark Millard wrote: Correction to earlier Email: VERBOSE_SYSINIT with DDB (and GDB) all = enabled (indirectly booted via using kernel10.1RE) got 0x1c277ec for the = %SRR0 value, not 0x1c277fc. So slightly different than Kernel10.1S's = 0x1c277fc (for this 10.1-STABLE variant). (I looked at the wrong notes = when composing the original Email.) More comparisons of kernel build options: VERBOSE_SYSINIT enabled with DDB (and GDB) disabled still has the = booting problem for my 10.1-RELEASE-p5 variant. It also still has the = 0x1c277ec for the %SRR0 value. For VERBOSE_SYSINIT disabled (DDB and GDB enabled) directly booted... Preloaded elf kernel "/boot/kernel/kernel" at 0x1106000. ... real memory =3D 17152118784 (16357 MB) available KVA =3D 7222611967 (6888 MB) Physical memory chunk(s): 0x0000000000024000 - 0x00000000000fffff, 901120 bytes (220 pages) 0x0000000001115000 - 0x00000000017fffff, 7254016 bytes (1771 pages) 0x0000000001814000 - 0x0000000001bfffff, 4112384 bytes (1004 pages) 0x0000000001c3d000 - 0x0000000001c3cfff, 0 bytes (0 pages) 0x0000000004cbd000 - 0x000000000fffffff, 187969536 bytes (45891 pages) 0x0000000020000000 - 0x000000007f5effff, 1600061440 bytes (390640 pages) 0x0000000100000000 - 0x0000000466827fff, 14604730368 bytes (3565608 = pages) 0x0000000200000000 - 0x00000001ffffffff, 0 bytes (0 pages) 0x0000000300000000 - 0x00000002ffffffff, 0 bytes (0 pages) 0x0000000400000000 - 0x00000003ffffffff, 0 bytes (0 pages) avail memory =3D 16374190080 (15615 MB) So 0x1c277ec is between the two: 0x0000000001814000 - 0x0000000001bfffff, 4112384 bytes (1004 pages) 0x0000000001c3d000 - 0x0000000001c3cfff, 0 bytes (0 pages) (But I do not know what most of the regions and holes are supposed to = be.) VERBOSE_SYSINIT, DDB, and GDB enabled but indirectly booted via = kernel10.1RE (via /boot/loader.conf's kernel=3D"kernel10.1RE"), = stopping, unloading, then doing "boot kernel": Preloaded elf kernel "/boot/kernel/kernel" at 0x1116000. ... real memory =3D 17152118784 (16357 MB) available KVA =3D 7222611967 (6888 MB) Physical memory chunk(s): 0x0000000000024000 - 0x00000000000fffff, 901120 bytes (220 pages) 0x0000000001105000 - 0x0000000001114fff, 65536 bytes (16 pages) 0x0000000001125000 - 0x00000000017fffff, 7188480 bytes (1755 pages) 0x0000000001814000 - 0x0000000001bfffff, 4112384 bytes (1004 pages) 0x0000000001c3d000 - 0x0000000001c3cfff, 0 bytes (0 pages) 0x0000000004cbd000 - 0x000000000fffffff, 187969536 bytes (45891 pages) 0x0000000020000000 - 0x000000007f5effff, 1600061440 bytes (390640 pages) 0x0000000100000000 - 0x0000000466827fff, 14604730368 bytes (3565608 = pages) 0x0000000200000000 - 0x00000001ffffffff, 0 bytes (0 pages) 0x0000000300000000 - 0x00000002ffffffff, 0 bytes (0 pages) 0x0000000400000000 - 0x00000003ffffffff, 0 bytes (0 pages) avail memory =3D 16374190080 (15615 MB) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Feb-7, at 03:49 AM, Mark Millard wrote: Nathan, you had the below written about my problems with booting my = builds of, say, 10.1-STABLE (kernel=3D"kernel10.1S" in = /boot/loaderl.conf) without involving the kernel from my build of = 10.1-RELEASE-p5 (kernel=3D"kernel10.1RE" or sometimes kernel=3D"kernel" = in /boot/loader.conf), where kernel=3D"kernel10.1RE" in = /boot/loader.conf boots just fine... > So this has to be some kind of icache issue. If you unload and reload=20= > the *same* kernel, does it also help? > -Nathan (Part of the evidence was: Using kernel=3D"kernel10.1RE" in = /boot/loader.conf, stopping at the 10sec prompt, unloading, and doing = "boot kernel 10.1S" lets my 10.1-STABLE builds boot that will not boot = directly.) Well I've got a little more information from a different direction: A = way to create the problem when building my 10.1-RELEASE-p5 kernel is to = enable VERBOSE_SYSINIT. More specifically the comparison/contrast I've = done so far is... I added the following 3 lines to my GENERIC64vtsc for my 10.1-RELEASE-p5 = source tree (no other changes elsewhere at all) options VERBOSE_SYSINIT options BOOTVERBOSE=3D1 options BOOTHOWTO=3DRB_VERBOSE and rebuilt kernel the via KERNCONF=3DGENERIC64vtsc INSTKERNNAME=3Dkernel = the resulting kernel load fails if referenced by /boot/loader.conf via = kernel=3D"kernel" line. The %SRR0 address value listed is the same as = for kernel10.1S: 1c277fc. But booting using kernel=3D"kernel10.1RE" in = /boot/loader.conf, stopping at the 10sec wait, unloading, and typing = "boot kernel" boots fine --just like "boot kernel10.1S". Note: GENERIC64vtsc has option DDB enabled (and GBD too). (This is = associated my with my information gathering for early G5 boot = crashes/hangups.) Note: This is the first time I've ever tried any of those 3 options. My = kernel10.1S build was not based on them. Then I changed the 3 lines by just commenting out the first of the 3 = that I had added #options VERBOSE_SYSINIT options BOOTVERBOSE=3D1 options BOOTHOWTO=3DRB_VERBOSE and rebuilt via KERNCONF=3DGENERIC64vtsc INSTKERNNAME=3Dkernel again. = The resulting /boot/kernel/... boots just fine when kernel=3D"kernel" is = used in /boot/loader.conf : no need for using kernel10.1RE or for = stopping to do anything special. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Mon Feb 9 00:21:08 2015 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 EC3699F9 for ; Mon, 9 Feb 2015 00:21:08 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 A070DFFD for ; Mon, 9 Feb 2015 00:21:07 +0000 (UTC) Received: (qmail 18769 invoked from network); 9 Feb 2015 00:21:01 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 9 Feb 2015 00:21:01 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 08 Feb 2015 19:21:01 -0500 (EST) Received: (qmail 22792 invoked from network); 9 Feb 2015 00:21:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Feb 2015 00:21:00 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 7808C1C43B2; Sun, 8 Feb 2015 16:20:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: HEADS UP: ... [__syncicache exceptions at a dcbst when len is not a cache-line-size multiple] From: Mark Millard In-Reply-To: Date: Sun, 8 Feb 2015 16:20:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <335C8DCD-33DF-4430-A0FA-77669C513C61@dsl-only.net> <449E0C48-B57D-4873-B2E7-BC217D891897@dsl-only.net> To: Nathan Whitehorn X-Mailer: Apple Mail (2.2070.6) 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: Mon, 09 Feb 2015 00:21:09 -0000 [Side note: My prior comment about having additional signed/unsigned = conversion code related to "int len" in __syncicache was wrong. That the = calling argument (*result)->f_size has size_t as a type ends up just = depending on the value not being so big as to cause problems when it is = converted to "int len" for __syncicache's len parameter.] %SRR0 being 0x1c2785c is a loader code address and does not change = unless one switches/updates the loader. objdump shows the following for the unstripped variant of the loader = that is in use = (/usr/obj/usr/home/markmi/src_10_1_releng/sys/boot/powerpc/ofw/loader): 01c27834 <__syncicache> lis r9,452 01c27838 <__syncicache+0x4> lwz r10,-25800(r9) 01c2783c <__syncicache+0x8> addi r11,r10,-1 01c27840 <__syncicache+0xc> and r0,r3,r11 01c27844 <__syncicache+0x10> add r0,r0,r4 01c27848 <__syncicache+0x14> andc r8,r3,r11 01c2784c <__syncicache+0x18> subf r0,r10,r0 01c27850 <__syncicache+0x1c> neg r7,r10 01c27854 <__syncicache+0x20> mr r9,r8 01c27858 <__syncicache+0x24> mr r11,r0 01c2785c <__syncicache+0x28> dcbst r0,r9 01c27860 <__syncicache+0x2c> add r11,r11,r7 01c27864 <__syncicache+0x30> add. r6,r10,r11 01c27868 <__syncicache+0x34> add r9,r9,r10 01c2786c <__syncicache+0x38> bgt+ 01c2785c <__syncicache+0x28> 01c27870 <__syncicache+0x3c> sync =20 01c27874 <__syncicache+0x40> icbi r0,r8 01c27878 <__syncicache+0x44> add r0,r0,r7 01c2787c <__syncicache+0x48> add. r9,r0,r10 01c27880 <__syncicache+0x4c> add r8,r8,r10 01c27884 <__syncicache+0x50> bgt+ 01c27874 <__syncicache+0x40> 01c27888 <__syncicache+0x54> sync =20 01c2788c <__syncicache+0x58> isync 01c27890 <__syncicache+0x5c> blr So the address in %SRR0 that is reported is for: 01c2785c <__syncicache+0x28> dcbst r0,r9 The source shows: void __syncicache(void *from, int len) { register_t l, off; char *p; off =3D (uintptr_t)from & (cacheline_size - 1); l =3D len +=3D off; p =3D (char *)from - off; do { __asm __volatile ("dcbst 0,%0" :: "r"(p)); p +=3D cacheline_size; } while ((l -=3D cacheline_size) > 0); __asm __volatile ("sync"); p =3D (char *)from - off; do { __asm __volatile ("icbi 0,%0" :: "r"(p)); p +=3D cacheline_size; } while ((len -=3D cacheline_size) > 0); __asm __volatile ("sync; isync"); } Comparing the 3 examples of dcbst use for off and initial len values = (using cacheline_size =3D=3D 128 so cacheline_size-1 =3D=3D 0x7F): off =3D=3D 0x1c35b48 & 0x7F (in all 3 cases) off =3D=3D 0x48 len =3D=3D 0x1014b80 is cache-line-multiple sized: This is the case that = works fine. from+len =3D=3D 0x1c35b48 + 0x1014b80 from+len =3D=3D 0x2c4A6C8 from+len-1 =3D=3D 0x2c4A6C7 start at 0x1c35b00 end with 0x2c4A680 (spans through 0x2c4A6FF) len =3D=3D 0x1014bb0 is NOT cache-line-multiple sized: FAILS! from+len =3D=3D 0x1c35b48 + 0x1014b80 from+len =3D=3D 0x2c4A6F8 from+len-1 =3D=3D 0x2c4A6F7 start at 0x1c35b00 end with 0x2c4A680 (spans through 0x2c4A6FF) NOTE: Same start/end range as above but fails by causing an exception! len =3D=3D 0x10175d0 is NOT cache-line-multiple sized: FAILS! from+len =3D=3D 0x1c35b48 + 0x10175d0 from+len =3D=3D 0x2c4D118 from+len-1 =3D=3D 0x2c4D117 start at 0x1c35b00 end with 0x2c4D100 (spans through 0x2c4A67F) The 3 cases have the same number of "extra before from" in the = cache-lines. But the 3 cases have varying numbers of "extra after from+len-1". Only for len being a multiple of the cache-line-size would "extra before = from" + "extra after from+len-1" be the cache-line-size (or zero if from = was cache-line-aligned). My guess is that something is configured based on "extra before from" + = "extra after from+len-1" being the cache-line-size (or zero if from was = cache-line-aligned) when it does not apply. So the processor ends up = rejecting some bytes during a dcbst instruction for len values that are = not multiples of the cache-line size. For __syncicache's use from sys/boot/ofw/libofw/ppc64_elf_freebsd.c I've = not figured out what all is configured related to the the range = [from,from+len) (excludes from+len) --i.e. the range [from,from+len-1] = since 0f_addr len =3D=3D (*result)->f_size Blindly listing things that can cause dcbst to exception (quotes form = PowerISA_203_Final_Public.pdf): > A Data Storage interrupt occurs when no higher priority exception = exists and a data access cannot be per- formed for any of the following = reasons. Data address translation is enabled (MSRDR=3D1) and the virtual = address of any byte of the storage location specified by a Load, Store, = icbi, dcbz, dcbst, dcbf[l], eciwx, or ecowx instruction cannot be = translated to a real address.=20 > A Data Segment interrupt occurs when no higher prior- ity exception = exists and a data access cannot be per- formed because data address = translation is enabled and the effective address of any byte of the = storage location specified by a Load, Store, icbi, dcbz, dcbst, dcbf[l] = eciwx, or ecowx instruction cannot be trans- lated to a virtual address.=20= > dcbf, dcbfep, dcbst, and dcbstep instructions are treated as Loads = with respect to protection. Flushing or storing a line from the cache is = not considered a Store since the store has already been done to update = the cache and the dcbf, dcbfep, dcbst, or dcbstep instruction is only = updating the copy in main storage. As a Load, they can cause Read Access = Control exception type Data Storage interrupts.=20 (A table indicates Yes for Read Protection Violation and No for Write = Protection Violation.) > On implementations on which a Machine Check interrupt can be caused by = referring to an invalid real address, executing a dcbz, dcbzep, or dcba = instruction can cause a delayed Machine Check interrupt by establishing = in the data cache a block that is associated with an invalid real = address. See Section 3.2 of Book II. A Machine Check interrupt can = eventually occur if and when a subsequent attempt is made to write that = block to main storage, for example as the result of executing an = instruc- tion that causes a cache miss for which the block is the target = for replacement or as the result of exe- cuting a dcbst, dcbstep, dcbf, = or dcbfep instruc- tion.=20 The dcbst related details for the code are (picking a failing example's = argument values): from =3D=3D 0x1c35b48 len =3D=3D 0x1014bb0 (example) starting at 0x1c35b00 ending with 0x2c4A680 (but it will span through 0x2c4A6FF) The code's calculations are based on: off =3D=3D (uintptr_t)from & (cacheline_size - 1) off =3D=3D 0x1c35b48 & 0x7F off =3D=3D 0x48 (len as in the argument here, not later updates) len+off =3D=3D 0x1014bb0 + 0x48 len+off =3D=3D 0x1014BF8 l =3D=3D 0x1014BF8 (initially) Note that len+off is not a multiple of the cache size. Repeated = subtractions of the cache size will end up with a non-zero remainder. (p as it is initialized here, not later updates) p =3D=3D from - off p =3D=3D 0x1c35b48 - 0x48 p =3D=3D 0x1c35b00 p+l =3D=3D 0x1c35b00+0x1014BF8 p+l =3D=3D 0x2c4A6F8 Note that 0x2c4A6F8 this is not cache aligned. Note that as the dcbst loop progresses p+l is constant (other than in = the middle of updating the pair). So when... l=3D=3D0xF8: p=3D=3D0x2c4A600 l=3D=3D0x78: p=3D=3D0x2c4A680 l<0: no dcbst for p It appears that the dcbst loop does span the range of cache-lines that = it should. But apparently the processor is rejecting some bytes from that range = when full cache-line sized units are counted. I would guess the = rejection is on the l=3D0x78 side of things that varies from example to = example. =3D=3D=3D Mark Millard markmiatdsl-only.net On 2015-Feb-8, at 01:16 AM, Mark Millard wrote: I've narrowed down greatly where the crashes happen, which need not be = where root-cause is: that could be earlier. In the following code [I'm using 10.1-RELEASE-p5 for reference here] $ svnlite diff sys/boot/ofw/libofw/ppc64_elf_freebsd.c=20 Index: sys/boot/ofw/libofw/ppc64_elf_freebsd.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/ofw/libofw/ppc64_elf_freebsd.c (revision 277808) +++ sys/boot/ofw/libofw/ppc64_elf_freebsd.c (working copy) @@ -59,7 +59,11 @@ * be done by the kernel after relocation. */ if (!strcmp((*result)->f_type, "elf kernel")) +{ +printf("ppc64_ofw_elf_loadfile before __syncicache\n"); __syncicache((void *) (*result)->f_addr, = (*result)->f_size); +printf("ppc64_ofw_elf_loadfile after __syncicache\n"); +} return (0); } for a directly-bootable (no crash) kernel-build both printf's are = displayed. (The above code part of /boot/loader .) But for the kernels that I build that fail to directly boot only the = first of the two printf's is displayed when a direct boot is attempted: = Openfirmware's notice with %SRR0 and %SRR1 shows up after that instead = of the text from the second printf. Based on that much it looks like the crash is either in evaluating the = arguments to __syncicache or happens during __syncicache's execution, = not after. Changing the first printf to something like the sequence: printf("ppc64_ofw_elf_loadfile before __syncicache\n"); printf("(void*)result: %p\n",(void*)result); printf("(void*)(*result): %p\n",(void*)(*result)); printf("(void*)(*result)->f_addr: %p\n",(void*)(*result)->f_addr); printf("(*result)->f_size : 0x%lx\n",(*result)->f_size); Shows that all of the stages print before the crash happens, answering = the question about evaluation of the arguments: there is no problem = evaluating them. So the crashes are strictly during __syncicache's activity. Only (*result)->f_size varies between the 3 examples that I've used: 10.1-RELEASE-p5 variant without VERBOSE_SYSINIT (and BOOTVERBOSE, = BOOTHOWTO). (boots fine) 10.1-RELEASE-p5 variant with VERBOSE_SYSINIT (and BOOTVERBOSE, = BOOTHOWTO). (crashes) 10.1-STABLE (-r278028) variant without VERBOSE_SYSINIT (and BOOTVERBOSE, = BOOTHOWTO). (crashes) What the above printf's reported was: (void*)result: 0x1c35b48 (void*)(*result): 0x1ebc0 (*result)->f_addr: 0x100000 10.1-RELEASE-p5 variant without VERBOSE_SYSINIT: (*result)->f_size: = 0x1014b80 10.1-RELEASE-p5 variant with VERBOSE_SYSINIT: (*result)->f_size: = 0x1014bb0 10.1-STABLE (-r278028) variant without VERBOSE_SYSINIT: = (*result)->f_size: 0x10175d0 (Listed in increasing order.) As I remember for the last two the crash report listed %SRR0: 0x1c2785c = for both. The "without VERBOSE_SYSINIT" one above does not crash and for = it the "ppc64_ofw_elf_loadfile after __syncicache" message shows up as = it should. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Feb-7, at 09:43 AM, Mark Millard wrote: Correction to earlier Email: VERBOSE_SYSINIT with DDB (and GDB) all = enabled (indirectly booted via using kernel10.1RE) got 0x1c277ec for the = %SRR0 value, not 0x1c277fc. So slightly different than Kernel10.1S's = 0x1c277fc (for this 10.1-STABLE variant). (I looked at the wrong notes = when composing the original Email.) More comparisons of kernel build options: VERBOSE_SYSINIT enabled with DDB (and GDB) disabled still has the = booting problem for my 10.1-RELEASE-p5 variant. It also still has the = 0x1c277ec for the %SRR0 value. For VERBOSE_SYSINIT disabled (DDB and GDB enabled) directly booted... Preloaded elf kernel "/boot/kernel/kernel" at 0x1106000. ... real memory =3D 17152118784 (16357 MB) available KVA =3D 7222611967 (6888 MB) Physical memory chunk(s): 0x0000000000024000 - 0x00000000000fffff, 901120 bytes (220 pages) 0x0000000001115000 - 0x00000000017fffff, 7254016 bytes (1771 pages) 0x0000000001814000 - 0x0000000001bfffff, 4112384 bytes (1004 pages) 0x0000000001c3d000 - 0x0000000001c3cfff, 0 bytes (0 pages) 0x0000000004cbd000 - 0x000000000fffffff, 187969536 bytes (45891 pages) 0x0000000020000000 - 0x000000007f5effff, 1600061440 bytes (390640 pages) 0x0000000100000000 - 0x0000000466827fff, 14604730368 bytes (3565608 = pages) 0x0000000200000000 - 0x00000001ffffffff, 0 bytes (0 pages) 0x0000000300000000 - 0x00000002ffffffff, 0 bytes (0 pages) 0x0000000400000000 - 0x00000003ffffffff, 0 bytes (0 pages) avail memory =3D 16374190080 (15615 MB) So 0x1c277ec is between the two: 0x0000000001814000 - 0x0000000001bfffff, 4112384 bytes (1004 pages) 0x0000000001c3d000 - 0x0000000001c3cfff, 0 bytes (0 pages) (But I do not know what most of the regions and holes are supposed to = be.) VERBOSE_SYSINIT, DDB, and GDB enabled but indirectly booted via = kernel10.1RE (via /boot/loader.conf's kernel=3D"kernel10.1RE"), = stopping, unloading, then doing "boot kernel": Preloaded elf kernel "/boot/kernel/kernel" at 0x1116000. ... real memory =3D 17152118784 (16357 MB) available KVA =3D 7222611967 (6888 MB) Physical memory chunk(s): 0x0000000000024000 - 0x00000000000fffff, 901120 bytes (220 pages) 0x0000000001105000 - 0x0000000001114fff, 65536 bytes (16 pages) 0x0000000001125000 - 0x00000000017fffff, 7188480 bytes (1755 pages) 0x0000000001814000 - 0x0000000001bfffff, 4112384 bytes (1004 pages) 0x0000000001c3d000 - 0x0000000001c3cfff, 0 bytes (0 pages) 0x0000000004cbd000 - 0x000000000fffffff, 187969536 bytes (45891 pages) 0x0000000020000000 - 0x000000007f5effff, 1600061440 bytes (390640 pages) 0x0000000100000000 - 0x0000000466827fff, 14604730368 bytes (3565608 = pages) 0x0000000200000000 - 0x00000001ffffffff, 0 bytes (0 pages) 0x0000000300000000 - 0x00000002ffffffff, 0 bytes (0 pages) 0x0000000400000000 - 0x00000003ffffffff, 0 bytes (0 pages) avail memory =3D 16374190080 (15615 MB) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Feb-7, at 03:49 AM, Mark Millard wrote: Nathan, you had the below written about my problems with booting my = builds of, say, 10.1-STABLE (kernel=3D"kernel10.1S" in = /boot/loaderl.conf) without involving the kernel from my build of = 10.1-RELEASE-p5 (kernel=3D"kernel10.1RE" or sometimes kernel=3D"kernel" = in /boot/loader.conf), where kernel=3D"kernel10.1RE" in = /boot/loader.conf boots just fine... > So this has to be some kind of icache issue. If you unload and reload=20= > the *same* kernel, does it also help? > -Nathan (Part of the evidence was: Using kernel=3D"kernel10.1RE" in = /boot/loader.conf, stopping at the 10sec prompt, unloading, and doing = "boot kernel 10.1S" lets my 10.1-STABLE builds boot that will not boot = directly.) Well I've got a little more information from a different direction: A = way to create the problem when building my 10.1-RELEASE-p5 kernel is to = enable VERBOSE_SYSINIT. More specifically the comparison/contrast I've = done so far is... I added the following 3 lines to my GENERIC64vtsc for my 10.1-RELEASE-p5 = source tree (no other changes elsewhere at all) options VERBOSE_SYSINIT options BOOTVERBOSE=3D1 options BOOTHOWTO=3DRB_VERBOSE and rebuilt kernel the via KERNCONF=3DGENERIC64vtsc INSTKERNNAME=3Dkernel = the resulting kernel load fails if referenced by /boot/loader.conf via = kernel=3D"kernel" line. The %SRR0 address value listed is the same as = for kernel10.1S: 1c277fc. But booting using kernel=3D"kernel10.1RE" in = /boot/loader.conf, stopping at the 10sec wait, unloading, and typing = "boot kernel" boots fine --just like "boot kernel10.1S". Note: GENERIC64vtsc has option DDB enabled (and GBD too). (This is = associated my with my information gathering for early G5 boot = crashes/hangups.) Note: This is the first time I've ever tried any of those 3 options. My = kernel10.1S build was not based on them. Then I changed the 3 lines by just commenting out the first of the 3 = that I had added #options VERBOSE_SYSINIT options BOOTVERBOSE=3D1 options BOOTHOWTO=3DRB_VERBOSE and rebuilt via KERNCONF=3DGENERIC64vtsc INSTKERNNAME=3Dkernel again. = The resulting /boot/kernel/... boots just fine when kernel=3D"kernel" is = used in /boot/loader.conf : no need for using kernel10.1RE or for = stopping to do anything special. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Mon Feb 9 03:52:46 2015 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 0AF8BAEB for ; Mon, 9 Feb 2015 03:52:46 +0000 (UTC) Received: from mail.umail10.cn4e.com (umail10.cn4e.com [219.239.95.79]) by mx1.freebsd.org (Postfix) with ESMTP id 334D6D2D for ; Mon, 9 Feb 2015 03:52:45 +0000 (UTC) Received: from smail116.cn4e.com (smail116.cn4e.com [124.202.153.116]) by mail.umail10.cn4e.com (Postfix) with ESMTP id 678BEFE44A7 for ; Mon, 9 Feb 2015 11:52:44 +0800 (CST) X-Bordeaux-Score: 550 X-Spam-Flag: NO Received: from localhost([180.173.154.98]) by smail116.cn4e.com(5.0.0.3a) with ESMTP id 375C040A0006.33.1423453964.552394; Mon, 09 Feb 2015 11:52:44 +0800 (CST) X-BQId: 375C040A0006.33.1423453964.552394.1 X-Bordeaux-Type: AUTHSMTP X-35BMId: 375C040A0006.33.1423453964.552394.1 X-Bordeaux-LOG: SA: TSMF, 3-550-1-83886336,3-550-1-83886336,3-550-1-83886336 eJzt2ctOwkAUBmA2uhHfYZa6YJxSbhJjgFosoTAExsTtMAyXpHRILwmPysI38A1c2UZMTBMJGzp Ez9c0p4uz+Hd/ZnpR+FK827Gf06LDoW0xZDQINuomNqoVfN8ogH/i7YidcM1XnmHUsPArEgu1Rv ZkwEaoo4KZ5PG2ZVZvqpgkj8lvT54YAJC3y/3M9oftuBS5SnDPUWGkLR7Q5OOIHdo/eQwAwBm72 s9sf7RfmINc+twbaosGNHpP3jKuY3Jgpx1HS+lHK8GjlfJRGAshw3Aee3mFBABoVfyemf4YtHsu 6o7poIke1tznCxmQWkv4JRlJsUwvKx61ZQanl54/eNIHmwNnzzIhpJxbIgDAubnez2x/jK0RQ4w m7TEPpJyGs9JmI1rd5LszecIqWEB9/Glpf4ytpv3Kft+hfSS3kQx87qH0V8hUbXPLBwDQ7xOUoF tE X-Bordeaux-Detail: eJxzsrIKjgwOcfW1snIGI0MDYysrE3MrK1MDLidMSRMrKyMDEEaR9YDIGhpaWVkCZY1RZYHIEaz FwAgoZ2WlkVeak6OJZrofyHQgAFLmMCUAqLwmTg== X-Bordeaux-Action-libantispam.so: Action: Relay[NEXT,10000,550:550:550] X-Bordeaux-Action-libspamsa.so: X-Bordeaux-Action-libclamav.so: X-Bordeaux-Action-libsmtpext.so: Message-ID: <1774407398378A2CC0A3C17A8E071F2C3149D8EC75@CN-ETECH.COM> From: "Helen" Reply-To: To: Date: Mon, 9 Feb 2015 11:49:44 +0800 MIME-Version: 1.0 X-Priority: 3 X-Mailer: Joinf MailSystem 8.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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, 09 Feb 2015 03:52:46 -0000 RGVhciBteSBmcmllbmQ7DQpHb29kIGRheS4NClRoaXMgaXMgSGVsZW4gZnJvbSBFemxpZmUgQ28u LCBMdGQsIGVzdGFibGlzaGVkIGluIDIwMDMuDQpJIGtub3cgeW91IGZyb20gdGhlIGludGVybmV0 Lg0KV2UgYXJlIG9uZSBvZiB0aGUgbGVhZGluZyBjb21wYW5pZXMgaW4gcmVzZWFyY2ggJmRldmVs b3BtZW50LCBwcm9kdWN0aW9uIGFuZCBzYWxlcyBvZiBib2R5IHdhcm1lciwgaGFuZCB3YXJtZXIs IGZvb3Qgd2FybWVyLCB0b2Ugd2FybWVyLCBoZWF0aW5nLCBsaWZlIGdpZnQgcHJvZHVjdHMgaW4g Q2hpbmEuIA0KV2UgaGF2ZSAxMDAgd29ya2VycyBhbmQgYW5udWFsIHByb2R1Y3Rpb24gY2FwYWNp dHkgb2YgbGlmZSBwcm9kdWN0cyBoYXMgcmVhY2hlZCAxNTAsIDAwMCwgMDAwIHBpZWNlcy4NCldl IGhhdmUgZGlmZmVyZW50IGFzc2VtYmx5IGxpbmVzIHRoYXQgYXJlIHN1cGVydmlzZWQgYW5kIG1h bmFnZWQgYnkgcHJvZmVzc2lvbmFsIGRlc2lnbmVycyBhbmQgbWFuYWdlcnMuDQpPdXIgYWltIGlz IHRvIG1ha2UgeW91ciBsaWZlIGVhc3kgYW5kIGhhcHB5IHdpdGggaGlnaCB0ZWNobm9sb2d5Lg0K T3VyIHByb2R1Y3RzIGhhcyBiZWVuIGF3YXJkZWQgd2l0aCBDaGluZXNlLCBVU0EsIEdlcm1hbnks IGV0YyAtICBjZXJ0aWZpY2F0aW9ucy4NCldlIHN0aWxsIG1ha2UgZWZmb3J0cyB0byBzdGVhZGls eSBwcm9ncmVzc2lvbiBhbmQgY3JlYXRpb24gb2YgbmV3IHByb2R1Y3RzLg0KV2UgcHJvdmlkZSBo aWdoIHF1YWxpdHkgcHJvZHVjdCB3aXRoIGNvbXBldGl0aXZlIHByaWNlIGFuZCBwcm9mZXNzaW9u YWwgc2VydmljZS4NCkZyZWUgc2FtcGxlIGlzIGZvciB5b3VyIHRlc3RpbmcgLg0KDQoNCkNvdWxk IHlvdSBnaXZlIHVzIGEgY2hhbmNlIHRvIHNlcnZlIHlvdSBpbiBjb2xvciwgY2F0Y2hlciwgc3Bv cnQgdG93ZWwsIGRhaWx5IGxpZmUgcHJvZHVjdHM/DQpMb29raW5nIGZvcndhcmQgIHRvIHlvdXIg a2luZGx5IHJlcGx5Lg0KDQoNCkJlc3QgUmVnYXJkcyENCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkhlbGVuIFpoYW5n IA0KU2hhbmdoYWkgRXpsaWZlIENvLiBMdGQNCkFkZDogTm8uNDc5IENodW5kb25nIHJvYWQsTWlu aGFuZyBkaXN0cmljdCwgU2hhbmdoYWkgMjAxMTA4LCBDaGluYQ0KVGVsOjAwODYgMjE1NDcxMDAx MC04MDY3DQpGYXg6MDA4NiAyMSA2MTI5IDQ3NzkNCk1vYihWaWJlci9XaGF0c2FwcCk6IDAwODYg MTU4MDE3OTUwOTQNClNreXBlIElEOiBzaC5zZmZpbHRlY2gzDQpFbWFpbDogc2FsZXMyQGV6bGlm ZWNuLmNvbQ== From owner-freebsd-ppc@FreeBSD.ORG Mon Feb 9 04:03:10 2015 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 038A5CFC for ; Mon, 9 Feb 2015 04:03:10 +0000 (UTC) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C202DE16 for ; Mon, 9 Feb 2015 04:03:09 +0000 (UTC) Received: by mail-oi0-f48.google.com with SMTP id a3so2262124oib.7 for ; Sun, 08 Feb 2015 20:03:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=KBb5GUsTkJrASC6yxZHMPiiLt85Bn8P1fdjnfmB2XpQ=; b=TSKxt5fRh5BfQGlAO9n/2H8jXlOexuOzFWIgEBm/mWcd7OdC90TWuphBgiyctX8VA2 C6Cl0mcT4jGMUcxa257+GS8TDDj8uKZUunALrqrJiReJOuIqT4/BrrBfN3N1hS52YlOo 0yvryXybExx6s+ZH9bz5dXuKK6zQrXc3MlR4pfLYIFSDE0Hx9j0Q6TWNtuPpXMJ1xRo7 aeRjuUSfnh+ToRxaIsqKg/g18bzBip3zTTPXTkhEfuhyr5WvcC9HXLPxRD+wKMopqUGY SzY6ROSK0moB+FsgMF31iuBQbo6qBRg8DgrFPGbdxFg18vY9s4eQVj/fw11sp7SHT62S 0b2Q== X-Gm-Message-State: ALoCoQkWJK5h+fC+8bQXuplo6FH196BGgeF5GLgoWgcSUxUYBgMAvDkbs2fstK+puIv5UL8Q11D7 MIME-Version: 1.0 X-Received: by 10.202.222.132 with SMTP id v126mr9824730oig.103.1423454583176; Sun, 08 Feb 2015 20:03:03 -0800 (PST) Received: by 10.76.71.33 with HTTP; Sun, 8 Feb 2015 20:03:03 -0800 (PST) X-Originating-IP: [66.177.125.30] Received: by 10.76.71.33 with HTTP; Sun, 8 Feb 2015 20:03:03 -0800 (PST) In-Reply-To: <1774407398378A2CC0A3C17A8E071F2C3149D8EC75@CN-ETECH.COM> References: <1774407398378A2CC0A3C17A8E071F2C3149D8EC75@CN-ETECH.COM> Date: Sun, 8 Feb 2015 23:03:03 -0500 Message-ID: Subject: Re: From: Michael Copeland Cc: FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 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, 09 Feb 2015 04:03:10 -0000 It's ok, they're from the Internet. From owner-freebsd-ppc@FreeBSD.ORG Mon Feb 9 04:06:49 2015 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 0D01ED45 for ; Mon, 9 Feb 2015 04:06:49 +0000 (UTC) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C65BAE2C for ; Mon, 9 Feb 2015 04:06:48 +0000 (UTC) Received: by iecrp18 with SMTP id rp18so9328028iec.10 for ; Sun, 08 Feb 2015 20:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ghAeS5+exN/DUMi7Jp+a0EzaVxAshG6+72RqxDtBTgs=; b=J3/SeaRjg/zSkqtkd30pWKK8n2DhQeWsyx0SF4Y9wLX1m7g+mB+J5CaDrfCT6nY6zU /cWSZjnK5hrNsWcQYZk0RciOFYolh/W1ARdTa+Yu8X/E8PgMpCfdZQp3jVR2zD0Av21q y/Ho9N19Ht6jrgTSYElEoowvKIgcoBQiMKe/8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ghAeS5+exN/DUMi7Jp+a0EzaVxAshG6+72RqxDtBTgs=; b=OyBZCUCFVbbi0JssvR6rBwK5GX17T+7p55xW+6+o9W7WPqwHyY8EkzxbdiYST/yOyi G3dxnJZ88qdgjg26ekfsscHd37D/kMcV4BtW9Pzl+FXehgqSJ+gahpq2iVTlHTgj3iQE Ow34cjmRYOOuRWniBIlQv4CzZ7kD8AwXzybm25H5f2igCP1jLG8iamigGEPjgU41FTtH V1RhNkaeFiWuOQmrRgFmGiqf2fJOWaL44oKTtBlOdqxtOWnBsmTtLsFDZYmPuzNh/44U ZUPJAdNTZQLXghLkDelzHyxBJ+1DvOtMYC7DibszNTd1wFoWzucczjsZXjHj0N4zKLkk Amxw== X-Gm-Message-State: ALoCoQnnq5ND8ZVBi51DLjTA1y8WNhzZBwTp5ve+vo0ljcfmU7sPBaLDIbWKTuGk8GS90gDz2VNR X-Received: by 10.107.7.129 with SMTP id g1mr23444123ioi.52.1423454807751; Sun, 08 Feb 2015 20:06:47 -0800 (PST) Received: from [172.31.32.31] (107-133-113-194.lightspeed.milwwi.sbcglobal.net. [107.133.113.194]) by mx.google.com with ESMTPSA id j129sm5734967ioe.18.2015.02.08.20.06.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Feb 2015 20:06:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: From: Jason Hellenthal X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Sun, 8 Feb 2015 22:06:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8D8045B8-0995-42EE-A51E-7A7DAFBAA94A@dataix.net> References: <1774407398378A2CC0A3C17A8E071F2C3149D8EC75@CN-ETECH.COM> To: Michael Copeland 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: Mon, 09 Feb 2015 04:06:49 -0000 Rofl --=20 Jason Hellenthal Mobile: +1 (616) 953-0176 jhellenthal@DataIX.net JJH48-ARIN On Feb 8, 2015, at 22:03, Michael Copeland wr= ote: It's ok, they're from the Internet. _______________________________________________ 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 Mon Feb 9 16:28:15 2015 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 AF317792 for ; Mon, 9 Feb 2015 16:28:15 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 4C26F962 for ; Mon, 9 Feb 2015 16:28:14 +0000 (UTC) Received: (qmail 14143 invoked from network); 9 Feb 2015 16:28:11 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 Feb 2015 16:28:11 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 09 Feb 2015 11:28:11 -0500 (EST) Received: (qmail 9538 invoked from network); 9 Feb 2015 16:28:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Feb 2015 16:28:08 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 2A9B51C43B3; Mon, 9 Feb 2015 08:28:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: HEADS UP: ... [Better info for __syncicache exceptions at a dcbst: %DAR holding address not covered by PTEG's] From: Mark Millard In-Reply-To: Date: Mon, 9 Feb 2015 08:28:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <335C8DCD-33DF-4430-A0FA-77669C513C61@dsl-only.net> <449E0C48-B57D-4873-B2E7-BC217D891897@dsl-only.net> To: Nathan Whitehorn X-Mailer: Apple Mail (2.2070.6) 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: Mon, 09 Feb 2015 16:28:15 -0000 An early copy/paste error propagated throughout my figures and messes = things up. So I try again... Also it turns out openfirmware has a "word" for dumping the registers = for a crash: .registers So I can coordinate some register values with __syncicache operation and = that is better information than I tried to give before anyway. I used a = failing direct boot attempt for the kernel10.1S that has len =3D = 0x10175d0. 01c27834 <__syncicache> lis r9,452 01c27838 <__syncicache+0x4> lwz r10,-25800(r9) Note: cacheline_size =3D r10 above ends up being 0x20. Yep the code is treating the 970MP processor as having a very small = cache line size: 32. My understanding is that it is really 128. So each = line is dcbst'd 4 times (offsets 0, 32, 64, and 96). 01c2783c <__syncicache+0x8> addi r11,r10,-1 Note: cacheline_size-1 =3D r11 above (0x1F). [So fixing both my initial copy/paste of the from value and the = cacheline_size-1 figures: off =3D=3D from & (cacheline_size-1) off =3D=3D 0x100000 & 0x1F (in all 3 cases) off =3D=3D 0x0 So in essence that old material should be ignored.] 01c27840 <__syncicache+0xc> and r0,r3,r11 01c27844 <__syncicache+0x10> add r0,r0,r4 01c27848 <__syncicache+0x14> andc r8,r3,r11 01c2784c <__syncicache+0x18> subf r0,r10,r0 01c27850 <__syncicache+0x1c> neg r7,r10 01c27854 <__syncicache+0x20> mr r9,r8 01c27858 <__syncicache+0x24> mr r11,r0 01c2785c <__syncicache+0x28> dcbst r0,r9 Note: p =3D r9 above. The register dump shows r9=3D0xbe7000 and shows DAR=3D0xbe7000. It also shows SRR0=3D0x1c2785c and interrupt vector 0x300. DSISR=3D0x40000000 (not found in the primary or secondary PTEG). And: r10=3D0x20, r6=3D0x5305d0, r11=3D5305b0, r7=3D0xffffffffffffffe0 (so = -0x20) (r6,r11 together are related to l in the C source.) 01c27860 <__syncicache+0x2c> add r11,r11,r7 01c27864 <__syncicache+0x30> add. r6,r10,r11 01c27868 <__syncicache+0x34> add r9,r9,r10 01c2786c <__syncicache+0x38> bgt+ 01c2785c <__syncicache+0x28> 01c27870 <__syncicache+0x3c> sync =20 01c27874 <__syncicache+0x40> icbi r0,r8 01c27878 <__syncicache+0x44> add r0,r0,r7 01c2787c <__syncicache+0x48> add. r9,r0,r10 01c27880 <__syncicache+0x4c> add r8,r8,r10 01c27884 <__syncicache+0x50> bgt+ 01c27874 <__syncicache+0x40> 01c27888 <__syncicache+0x54> sync =20 01c2788c <__syncicache+0x58> isync 01c27890 <__syncicache+0x5c> blr So the problem seems to be not at the ends of the range but in the = middle of it: a hole in the address range with no PTEG coverage. =3D=3D=3D Mark Millard markmi@dsl-only.net On 2015-Feb-8, at 04:20 PM, Mark Millard wrote: [Side note: My prior comment about having additional signed/unsigned = conversion code related to "int len" in __syncicache was wrong. That the = calling argument (*result)->f_size has size_t as a type ends up just = depending on the value not being so big as to cause problems when it is = converted to "int len" for __syncicache's len parameter.] %SRR0 being 0x1c2785c is a loader code address and does not change = unless one switches/updates the loader. objdump shows the following for the unstripped variant of the loader = that is in use = (/usr/obj/usr/home/markmi/src_10_1_releng/sys/boot/powerpc/ofw/loader): 01c27834 <__syncicache> lis r9,452 01c27838 <__syncicache+0x4> lwz r10,-25800(r9) 01c2783c <__syncicache+0x8> addi r11,r10,-1 01c27840 <__syncicache+0xc> and r0,r3,r11 01c27844 <__syncicache+0x10> add r0,r0,r4 01c27848 <__syncicache+0x14> andc r8,r3,r11 01c2784c <__syncicache+0x18> subf r0,r10,r0 01c27850 <__syncicache+0x1c> neg r7,r10 01c27854 <__syncicache+0x20> mr r9,r8 01c27858 <__syncicache+0x24> mr r11,r0 01c2785c <__syncicache+0x28> dcbst r0,r9 01c27860 <__syncicache+0x2c> add r11,r11,r7 01c27864 <__syncicache+0x30> add. r6,r10,r11 01c27868 <__syncicache+0x34> add r9,r9,r10 01c2786c <__syncicache+0x38> bgt+ 01c2785c <__syncicache+0x28> 01c27870 <__syncicache+0x3c> sync =20 01c27874 <__syncicache+0x40> icbi r0,r8 01c27878 <__syncicache+0x44> add r0,r0,r7 01c2787c <__syncicache+0x48> add. r9,r0,r10 01c27880 <__syncicache+0x4c> add r8,r8,r10 01c27884 <__syncicache+0x50> bgt+ 01c27874 <__syncicache+0x40> 01c27888 <__syncicache+0x54> sync =20 01c2788c <__syncicache+0x58> isync 01c27890 <__syncicache+0x5c> blr So the address in %SRR0 that is reported is for: 01c2785c <__syncicache+0x28> dcbst r0,r9 The source shows: void __syncicache(void *from, int len) { register_t l, off; char *p; off =3D (uintptr_t)from & (cacheline_size - 1); l =3D len +=3D off; p =3D (char *)from - off; do { __asm __volatile ("dcbst 0,%0" :: "r"(p)); p +=3D cacheline_size; } while ((l -=3D cacheline_size) > 0); __asm __volatile ("sync"); p =3D (char *)from - off; do { __asm __volatile ("icbi 0,%0" :: "r"(p)); p +=3D cacheline_size; } while ((len -=3D cacheline_size) > 0); __asm __volatile ("sync; isync"); } Comparing the 3 examples of dcbst use for off and initial len values = (using cacheline_size =3D=3D 128 so cacheline_size-1 =3D=3D 0x7F): off =3D=3D 0x1c35b48 & 0x7F (in all 3 cases) off =3D=3D 0x48 len =3D=3D 0x1014b80 is cache-line-multiple sized: This is the case that = works fine. from+len =3D=3D 0x1c35b48 + 0x1014b80 from+len =3D=3D 0x2c4A6C8 from+len-1 =3D=3D 0x2c4A6C7 start at 0x1c35b00 end with 0x2c4A680 (spans through 0x2c4A6FF) len =3D=3D 0x1014bb0 is NOT cache-line-multiple sized: FAILS! from+len =3D=3D 0x1c35b48 + 0x1014b80 from+len =3D=3D 0x2c4A6F8 from+len-1 =3D=3D 0x2c4A6F7 start at 0x1c35b00 end with 0x2c4A680 (spans through 0x2c4A6FF) NOTE: Same start/end range as above but fails by causing an exception! len =3D=3D 0x10175d0 is NOT cache-line-multiple sized: FAILS! from+len =3D=3D 0x1c35b48 + 0x10175d0 from+len =3D=3D 0x2c4D118 from+len-1 =3D=3D 0x2c4D117 start at 0x1c35b00 end with 0x2c4D100 (spans through 0x2c4A67F) The 3 cases have the same number of "extra before from" in the = cache-lines. But the 3 cases have varying numbers of "extra after from+len-1". Only for len being a multiple of the cache-line-size would "extra before = from" + "extra after from+len-1" be the cache-line-size (or zero if from = was cache-line-aligned). My guess is that something is configured based on "extra before from" + = "extra after from+len-1" being the cache-line-size (or zero if from was = cache-line-aligned) when it does not apply. So the processor ends up = rejecting some bytes during a dcbst instruction for len values that are = not multiples of the cache-line size. For __syncicache's use from sys/boot/ofw/libofw/ppc64_elf_freebsd.c I've = not figured out what all is configured related to the the range = [from,from+len) (excludes from+len) --i.e. the range [from,from+len-1] = since 0f_addr len =3D=3D (*result)->f_size Blindly listing things that can cause dcbst to exception (quotes form = PowerISA_203_Final_Public.pdf): > A Data Storage interrupt occurs when no higher priority exception = exists and a data access cannot be per- formed for any of the following = reasons. Data address translation is enabled (MSRDR=3D1) and the virtual = address of any byte of the storage location specified by a Load, Store, = icbi, dcbz, dcbst, dcbf[l], eciwx, or ecowx instruction cannot be = translated to a real address.=20 > A Data Segment interrupt occurs when no higher prior- ity exception = exists and a data access cannot be per- formed because data address = translation is enabled and the effective address of any byte of the = storage location specified by a Load, Store, icbi, dcbz, dcbst, dcbf[l] = eciwx, or ecowx instruction cannot be trans- lated to a virtual address.=20= > dcbf, dcbfep, dcbst, and dcbstep instructions are treated as Loads = with respect to protection. Flushing or storing a line from the cache is = not considered a Store since the store has already been done to update = the cache and the dcbf, dcbfep, dcbst, or dcbstep instruction is only = updating the copy in main storage. As a Load, they can cause Read Access = Control exception type Data Storage interrupts.=20 (A table indicates Yes for Read Protection Violation and No for Write = Protection Violation.) > On implementations on which a Machine Check interrupt can be caused by = referring to an invalid real address, executing a dcbz, dcbzep, or dcba = instruction can cause a delayed Machine Check interrupt by establishing = in the data cache a block that is associated with an invalid real = address. See Section 3.2 of Book II. A Machine Check interrupt can = eventually occur if and when a subsequent attempt is made to write that = block to main storage, for example as the result of executing an = instruc- tion that causes a cache miss for which the block is the target = for replacement or as the result of exe- cuting a dcbst, dcbstep, dcbf, = or dcbfep instruc- tion.=20 The dcbst related details for the code are (picking a failing example's = argument values): from =3D=3D 0x1c35b48 len =3D=3D 0x1014bb0 (example) starting at 0x1c35b00 ending with 0x2c4A680 (but it will span through 0x2c4A6FF) The code's calculations are based on: off =3D=3D (uintptr_t)from & (cacheline_size - 1) off =3D=3D 0x1c35b48 & 0x7F off =3D=3D 0x48 (len as in the argument here, not later updates) len+off =3D=3D 0x1014bb0 + 0x48 len+off =3D=3D 0x1014BF8 l =3D=3D 0x1014BF8 (initially) Note that len+off is not a multiple of the cache size. Repeated = subtractions of the cache size will end up with a non-zero remainder. (p as it is initialized here, not later updates) p =3D=3D from - off p =3D=3D 0x1c35b48 - 0x48 p =3D=3D 0x1c35b00 p+l =3D=3D 0x1c35b00+0x1014BF8 p+l =3D=3D 0x2c4A6F8 Note that 0x2c4A6F8 this is not cache aligned. Note that as the dcbst loop progresses p+l is constant (other than in = the middle of updating the pair). So when... l=3D=3D0xF8: p=3D=3D0x2c4A600 l=3D=3D0x78: p=3D=3D0x2c4A680 l<0: no dcbst for p It appears that the dcbst loop does span the range of cache-lines that = it should. But apparently the processor is rejecting some bytes from that range = when full cache-line sized units are counted. I would guess the = rejection is on the l=3D0x78 side of things that varies from example to = example. =3D=3D=3D Mark Millard markmiatdsl-only.net On 2015-Feb-8, at 01:16 AM, Mark Millard wrote: I've narrowed down greatly where the crashes happen, which need not be = where root-cause is: that could be earlier. In the following code [I'm using 10.1-RELEASE-p5 for reference here] $ svnlite diff sys/boot/ofw/libofw/ppc64_elf_freebsd.c=20 Index: sys/boot/ofw/libofw/ppc64_elf_freebsd.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/ofw/libofw/ppc64_elf_freebsd.c (revision 277808) +++ sys/boot/ofw/libofw/ppc64_elf_freebsd.c (working copy) @@ -59,7 +59,11 @@ * be done by the kernel after relocation. */ if (!strcmp((*result)->f_type, "elf kernel")) +{ +printf("ppc64_ofw_elf_loadfile before __syncicache\n"); __syncicache((void *) (*result)->f_addr, = (*result)->f_size); +printf("ppc64_ofw_elf_loadfile after __syncicache\n"); +} return (0); } for a directly-bootable (no crash) kernel-build both printf's are = displayed. (The above code part of /boot/loader .) But for the kernels that I build that fail to directly boot only the = first of the two printf's is displayed when a direct boot is attempted: = Openfirmware's notice with %SRR0 and %SRR1 shows up after that instead = of the text from the second printf. Based on that much it looks like the crash is either in evaluating the = arguments to __syncicache or happens during __syncicache's execution, = not after. Changing the first printf to something like the sequence: printf("ppc64_ofw_elf_loadfile before __syncicache\n"); printf("(void*)result: %p\n",(void*)result); printf("(void*)(*result): %p\n",(void*)(*result)); printf("(void*)(*result)->f_addr: %p\n",(void*)(*result)->f_addr); printf("(*result)->f_size : 0x%lx\n",(*result)->f_size); Shows that all of the stages print before the crash happens, answering = the question about evaluation of the arguments: there is no problem = evaluating them. So the crashes are strictly during __syncicache's activity. Only (*result)->f_size varies between the 3 examples that I've used: 10.1-RELEASE-p5 variant without VERBOSE_SYSINIT (and BOOTVERBOSE, = BOOTHOWTO). (boots fine) 10.1-RELEASE-p5 variant with VERBOSE_SYSINIT (and BOOTVERBOSE, = BOOTHOWTO). (crashes) 10.1-STABLE (-r278028) variant without VERBOSE_SYSINIT (and BOOTVERBOSE, = BOOTHOWTO). (crashes) What the above printf's reported was: (void*)result: 0x1c35b48 (void*)(*result): 0x1ebc0 (*result)->f_addr: 0x100000 10.1-RELEASE-p5 variant without VERBOSE_SYSINIT: (*result)->f_size: = 0x1014b80 10.1-RELEASE-p5 variant with VERBOSE_SYSINIT: (*result)->f_size: = 0x1014bb0 10.1-STABLE (-r278028) variant without VERBOSE_SYSINIT: = (*result)->f_size: 0x10175d0 (Listed in increasing order.) As I remember for the last two the crash report listed %SRR0: 0x1c2785c = for both. The "without VERBOSE_SYSINIT" one above does not crash and for = it the "ppc64_ofw_elf_loadfile after __syncicache" message shows up as = it should. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Feb-7, at 09:43 AM, Mark Millard wrote: Correction to earlier Email: VERBOSE_SYSINIT with DDB (and GDB) all = enabled (indirectly booted via using kernel10.1RE) got 0x1c277ec for the = %SRR0 value, not 0x1c277fc. So slightly different than Kernel10.1S's = 0x1c277fc (for this 10.1-STABLE variant). (I looked at the wrong notes = when composing the original Email.) More comparisons of kernel build options: VERBOSE_SYSINIT enabled with DDB (and GDB) disabled still has the = booting problem for my 10.1-RELEASE-p5 variant. It also still has the = 0x1c277ec for the %SRR0 value. For VERBOSE_SYSINIT disabled (DDB and GDB enabled) directly booted... Preloaded elf kernel "/boot/kernel/kernel" at 0x1106000. ... real memory =3D 17152118784 (16357 MB) available KVA =3D 7222611967 (6888 MB) Physical memory chunk(s): 0x0000000000024000 - 0x00000000000fffff, 901120 bytes (220 pages) 0x0000000001115000 - 0x00000000017fffff, 7254016 bytes (1771 pages) 0x0000000001814000 - 0x0000000001bfffff, 4112384 bytes (1004 pages) 0x0000000001c3d000 - 0x0000000001c3cfff, 0 bytes (0 pages) 0x0000000004cbd000 - 0x000000000fffffff, 187969536 bytes (45891 pages) 0x0000000020000000 - 0x000000007f5effff, 1600061440 bytes (390640 pages) 0x0000000100000000 - 0x0000000466827fff, 14604730368 bytes (3565608 = pages) 0x0000000200000000 - 0x00000001ffffffff, 0 bytes (0 pages) 0x0000000300000000 - 0x00000002ffffffff, 0 bytes (0 pages) 0x0000000400000000 - 0x00000003ffffffff, 0 bytes (0 pages) avail memory =3D 16374190080 (15615 MB) So 0x1c277ec is between the two: 0x0000000001814000 - 0x0000000001bfffff, 4112384 bytes (1004 pages) 0x0000000001c3d000 - 0x0000000001c3cfff, 0 bytes (0 pages) (But I do not know what most of the regions and holes are supposed to = be.) VERBOSE_SYSINIT, DDB, and GDB enabled but indirectly booted via = kernel10.1RE (via /boot/loader.conf's kernel=3D"kernel10.1RE"), = stopping, unloading, then doing "boot kernel": Preloaded elf kernel "/boot/kernel/kernel" at 0x1116000. ... real memory =3D 17152118784 (16357 MB) available KVA =3D 7222611967 (6888 MB) Physical memory chunk(s): 0x0000000000024000 - 0x00000000000fffff, 901120 bytes (220 pages) 0x0000000001105000 - 0x0000000001114fff, 65536 bytes (16 pages) 0x0000000001125000 - 0x00000000017fffff, 7188480 bytes (1755 pages) 0x0000000001814000 - 0x0000000001bfffff, 4112384 bytes (1004 pages) 0x0000000001c3d000 - 0x0000000001c3cfff, 0 bytes (0 pages) 0x0000000004cbd000 - 0x000000000fffffff, 187969536 bytes (45891 pages) 0x0000000020000000 - 0x000000007f5effff, 1600061440 bytes (390640 pages) 0x0000000100000000 - 0x0000000466827fff, 14604730368 bytes (3565608 = pages) 0x0000000200000000 - 0x00000001ffffffff, 0 bytes (0 pages) 0x0000000300000000 - 0x00000002ffffffff, 0 bytes (0 pages) 0x0000000400000000 - 0x00000003ffffffff, 0 bytes (0 pages) avail memory =3D 16374190080 (15615 MB) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Feb-7, at 03:49 AM, Mark Millard wrote: Nathan, you had the below written about my problems with booting my = builds of, say, 10.1-STABLE (kernel=3D"kernel10.1S" in = /boot/loaderl.conf) without involving the kernel from my build of = 10.1-RELEASE-p5 (kernel=3D"kernel10.1RE" or sometimes kernel=3D"kernel" = in /boot/loader.conf), where kernel=3D"kernel10.1RE" in = /boot/loader.conf boots just fine... > So this has to be some kind of icache issue. If you unload and reload=20= > the *same* kernel, does it also help? > -Nathan (Part of the evidence was: Using kernel=3D"kernel10.1RE" in = /boot/loader.conf, stopping at the 10sec prompt, unloading, and doing = "boot kernel 10.1S" lets my 10.1-STABLE builds boot that will not boot = directly.) Well I've got a little more information from a different direction: A = way to create the problem when building my 10.1-RELEASE-p5 kernel is to = enable VERBOSE_SYSINIT. More specifically the comparison/contrast I've = done so far is... I added the following 3 lines to my GENERIC64vtsc for my 10.1-RELEASE-p5 = source tree (no other changes elsewhere at all) options VERBOSE_SYSINIT options BOOTVERBOSE=3D1 options BOOTHOWTO=3DRB_VERBOSE and rebuilt kernel the via KERNCONF=3DGENERIC64vtsc INSTKERNNAME=3Dkernel = the resulting kernel load fails if referenced by /boot/loader.conf via = kernel=3D"kernel" line. The %SRR0 address value listed is the same as = for kernel10.1S: 1c277fc. But booting using kernel=3D"kernel10.1RE" in = /boot/loader.conf, stopping at the 10sec wait, unloading, and typing = "boot kernel" boots fine --just like "boot kernel10.1S". Note: GENERIC64vtsc has option DDB enabled (and GBD too). (This is = associated my with my information gathering for early G5 boot = crashes/hangups.) Note: This is the first time I've ever tried any of those 3 options. My = kernel10.1S build was not based on them. Then I changed the 3 lines by just commenting out the first of the 3 = that I had added #options VERBOSE_SYSINIT options BOOTVERBOSE=3D1 options BOOTHOWTO=3DRB_VERBOSE and rebuilt via KERNCONF=3DGENERIC64vtsc INSTKERNNAME=3Dkernel again. = The resulting /boot/kernel/... boots just fine when kernel=3D"kernel" is = used in /boot/loader.conf : no need for using kernel10.1RE or for = stopping to do anything special. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Mon Feb 9 17:37:23 2015 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 0CE144F7 for ; Mon, 9 Feb 2015 17:37:23 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 B78FB239 for ; Mon, 9 Feb 2015 17:37:22 +0000 (UTC) Received: (qmail 7869 invoked from network); 9 Feb 2015 17:37:20 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 Feb 2015 17:37:20 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 09 Feb 2015 12:37:20 -0500 (EST) Received: (qmail 2447 invoked from network); 9 Feb 2015 17:37:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Feb 2015 17:37:20 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 6A8BC1C405E; Mon, 9 Feb 2015 09:37:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: HEADS UP: ... [Better info for __syncicache exceptions at a dcbst: %DAR holding address not covered by PTEG's] From: Mark Millard In-Reply-To: Date: Mon, 9 Feb 2015 09:37:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <70827670-5645-4445-BCEF-1809F2554F84@dsl-only.net> References: <335C8DCD-33DF-4430-A0FA-77669C513C61@dsl-only.net> <449E0C48-B57D-4873-B2E7-BC217D891897@dsl-only.net> To: Nathan Whitehorn X-Mailer: Apple Mail (2.2070.6) 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: Mon, 09 Feb 2015 17:37:23 -0000 objdump -h /boot/kernel10.1S/kernel shows a hole in the memory map = between 25 (kern_conf) and 26 (.data) below: /boot/kernel10.1S/kernel: file format elf64-powerpc Sections: Idx Name Size VMA LMA File off = Algn 0 .text 007e5f84 0000000000100190 0000000000100190 00000190 = 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .interp 0000000d 00000000008e6114 00000000008e6114 007e6114 = 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .hash 00023598 00000000008e6128 00000000008e6128 007e6128 = 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA ... 25 kern_conf 000008d1 0000000000be6240 0000000000be6240 00ae6240 = 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 26 .data 000635b6 0000000000bf0000 0000000000bf0000 00af0000 = 2**16 CONTENTS, ALLOC, LOAD, DATA Note that 0xbe6240+0x8d1 =3D=3D 0xbe6b11 and 0xbe7000 is on a different = page, and there are several more pages in the hole before 0xbf0000. Also far more than "code" areas are having __syncicache's dcbst = executed. By contrast for the working kernel10.1RE kern_conf and .data are close = together, .data being on the very next page (0xbd600+0x8d1=3D0xbdfed1 = vs. 0xbe0000, a difference of 0x12f): 25 kern_conf 000008d1 0000000000bdf600 0000000000bdf600 00adf600 = 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 26 .data 000635b6 0000000000be0000 0000000000be0000 00ae0000 = 2**16 CONTENTS, ALLOC, LOAD, DATA =3D=3D=3D Mark Millard markmi@dsl-only.net On 2015-Feb-9, at 08:28 AM, Mark Millard wrote: An early copy/paste error propagated throughout my figures and messes = things up. So I try again... Also it turns out openfirmware has a "word" for dumping the registers = for a crash: .registers So I can coordinate some register values with __syncicache operation and = that is better information than I tried to give before anyway. I used a = failing direct boot attempt for the kernel10.1S that has len =3D = 0x10175d0. 01c27834 <__syncicache> lis r9,452 01c27838 <__syncicache+0x4> lwz r10,-25800(r9) Note: cacheline_size =3D r10 above ends up being 0x20. Yep the code is treating the 970MP processor as having a very small = cache line size: 32. My understanding is that it is really 128. So each = line is dcbst'd 4 times (offsets 0, 32, 64, and 96). 01c2783c <__syncicache+0x8> addi r11,r10,-1 Note: cacheline_size-1 =3D r11 above (0x1F). [So fixing both my initial copy/paste of the from value and the = cacheline_size-1 figures: off =3D=3D from & (cacheline_size-1) off =3D=3D 0x100000 & 0x1F (in all 3 cases) off =3D=3D 0x0 So in essence that old material should be ignored.] 01c27840 <__syncicache+0xc> and r0,r3,r11 01c27844 <__syncicache+0x10> add r0,r0,r4 01c27848 <__syncicache+0x14> andc r8,r3,r11 01c2784c <__syncicache+0x18> subf r0,r10,r0 01c27850 <__syncicache+0x1c> neg r7,r10 01c27854 <__syncicache+0x20> mr r9,r8 01c27858 <__syncicache+0x24> mr r11,r0 01c2785c <__syncicache+0x28> dcbst r0,r9 Note: p =3D r9 above. The register dump shows r9=3D0xbe7000 and shows DAR=3D0xbe7000. It also shows SRR0=3D0x1c2785c and interrupt vector 0x300. DSISR=3D0x40000000 (not found in the primary or secondary PTEG). And: r10=3D0x20, r6=3D0x5305d0, r11=3D5305b0, r7=3D0xffffffffffffffe0 (so = -0x20) (r6,r11 together are related to l in the C source.) 01c27860 <__syncicache+0x2c> add r11,r11,r7 01c27864 <__syncicache+0x30> add. r6,r10,r11 01c27868 <__syncicache+0x34> add r9,r9,r10 01c2786c <__syncicache+0x38> bgt+ 01c2785c <__syncicache+0x28> 01c27870 <__syncicache+0x3c> sync =20 01c27874 <__syncicache+0x40> icbi r0,r8 01c27878 <__syncicache+0x44> add r0,r0,r7 01c2787c <__syncicache+0x48> add. r9,r0,r10 01c27880 <__syncicache+0x4c> add r8,r8,r10 01c27884 <__syncicache+0x50> bgt+ 01c27874 <__syncicache+0x40> 01c27888 <__syncicache+0x54> sync =20 01c2788c <__syncicache+0x58> isync 01c27890 <__syncicache+0x5c> blr So the problem seems to be not at the ends of the range but in the = middle of it: a hole in the address range with no PTEG coverage. =3D=3D=3D Mark Millard markmi@dsl-only.net On 2015-Feb-8, at 04:20 PM, Mark Millard wrote: [Side note: My prior comment about having additional signed/unsigned = conversion code related to "int len" in __syncicache was wrong. That the = calling argument (*result)->f_size has size_t as a type ends up just = depending on the value not being so big as to cause problems when it is = converted to "int len" for __syncicache's len parameter.] %SRR0 being 0x1c2785c is a loader code address and does not change = unless one switches/updates the loader. objdump shows the following for the unstripped variant of the loader = that is in use = (/usr/obj/usr/home/markmi/src_10_1_releng/sys/boot/powerpc/ofw/loader): 01c27834 <__syncicache> lis r9,452 01c27838 <__syncicache+0x4> lwz r10,-25800(r9) 01c2783c <__syncicache+0x8> addi r11,r10,-1 01c27840 <__syncicache+0xc> and r0,r3,r11 01c27844 <__syncicache+0x10> add r0,r0,r4 01c27848 <__syncicache+0x14> andc r8,r3,r11 01c2784c <__syncicache+0x18> subf r0,r10,r0 01c27850 <__syncicache+0x1c> neg r7,r10 01c27854 <__syncicache+0x20> mr r9,r8 01c27858 <__syncicache+0x24> mr r11,r0 01c2785c <__syncicache+0x28> dcbst r0,r9 01c27860 <__syncicache+0x2c> add r11,r11,r7 01c27864 <__syncicache+0x30> add. r6,r10,r11 01c27868 <__syncicache+0x34> add r9,r9,r10 01c2786c <__syncicache+0x38> bgt+ 01c2785c <__syncicache+0x28> 01c27870 <__syncicache+0x3c> sync =20 01c27874 <__syncicache+0x40> icbi r0,r8 01c27878 <__syncicache+0x44> add r0,r0,r7 01c2787c <__syncicache+0x48> add. r9,r0,r10 01c27880 <__syncicache+0x4c> add r8,r8,r10 01c27884 <__syncicache+0x50> bgt+ 01c27874 <__syncicache+0x40> 01c27888 <__syncicache+0x54> sync =20 01c2788c <__syncicache+0x58> isync 01c27890 <__syncicache+0x5c> blr So the address in %SRR0 that is reported is for: 01c2785c <__syncicache+0x28> dcbst r0,r9 The source shows: void __syncicache(void *from, int len) { register_t l, off; char *p; off =3D (uintptr_t)from & (cacheline_size - 1); l =3D len +=3D off; p =3D (char *)from - off; do { __asm __volatile ("dcbst 0,%0" :: "r"(p)); p +=3D cacheline_size; } while ((l -=3D cacheline_size) > 0); __asm __volatile ("sync"); p =3D (char *)from - off; do { __asm __volatile ("icbi 0,%0" :: "r"(p)); p +=3D cacheline_size; } while ((len -=3D cacheline_size) > 0); __asm __volatile ("sync; isync"); } Comparing the 3 examples of dcbst use for off and initial len values = (using cacheline_size =3D=3D 128 so cacheline_size-1 =3D=3D 0x7F): off =3D=3D 0x1c35b48 & 0x7F (in all 3 cases) off =3D=3D 0x48 len =3D=3D 0x1014b80 is cache-line-multiple sized: This is the case that = works fine. from+len =3D=3D 0x1c35b48 + 0x1014b80 from+len =3D=3D 0x2c4A6C8 from+len-1 =3D=3D 0x2c4A6C7 start at 0x1c35b00 end with 0x2c4A680 (spans through 0x2c4A6FF) len =3D=3D 0x1014bb0 is NOT cache-line-multiple sized: FAILS! from+len =3D=3D 0x1c35b48 + 0x1014b80 from+len =3D=3D 0x2c4A6F8 from+len-1 =3D=3D 0x2c4A6F7 start at 0x1c35b00 end with 0x2c4A680 (spans through 0x2c4A6FF) NOTE: Same start/end range as above but fails by causing an exception! len =3D=3D 0x10175d0 is NOT cache-line-multiple sized: FAILS! from+len =3D=3D 0x1c35b48 + 0x10175d0 from+len =3D=3D 0x2c4D118 from+len-1 =3D=3D 0x2c4D117 start at 0x1c35b00 end with 0x2c4D100 (spans through 0x2c4A67F) The 3 cases have the same number of "extra before from" in the = cache-lines. But the 3 cases have varying numbers of "extra after from+len-1". Only for len being a multiple of the cache-line-size would "extra before = from" + "extra after from+len-1" be the cache-line-size (or zero if from = was cache-line-aligned). My guess is that something is configured based on "extra before from" + = "extra after from+len-1" being the cache-line-size (or zero if from was = cache-line-aligned) when it does not apply. So the processor ends up = rejecting some bytes during a dcbst instruction for len values that are = not multiples of the cache-line size. For __syncicache's use from sys/boot/ofw/libofw/ppc64_elf_freebsd.c I've = not figured out what all is configured related to the the range = [from,from+len) (excludes from+len) --i.e. the range [from,from+len-1] = since 0f_addr len =3D=3D (*result)->f_size Blindly listing things that can cause dcbst to exception (quotes form = PowerISA_203_Final_Public.pdf): > A Data Storage interrupt occurs when no higher priority exception = exists and a data access cannot be per- formed for any of the following = reasons. Data address translation is enabled (MSRDR=3D1) and the virtual = address of any byte of the storage location specified by a Load, Store, = icbi, dcbz, dcbst, dcbf[l], eciwx, or ecowx instruction cannot be = translated to a real address.=20 > A Data Segment interrupt occurs when no higher prior- ity exception = exists and a data access cannot be per- formed because data address = translation is enabled and the effective address of any byte of the = storage location specified by a Load, Store, icbi, dcbz, dcbst, dcbf[l] = eciwx, or ecowx instruction cannot be trans- lated to a virtual address.=20= > dcbf, dcbfep, dcbst, and dcbstep instructions are treated as Loads = with respect to protection. Flushing or storing a line from the cache is = not considered a Store since the store has already been done to update = the cache and the dcbf, dcbfep, dcbst, or dcbstep instruction is only = updating the copy in main storage. As a Load, they can cause Read Access = Control exception type Data Storage interrupts.=20 (A table indicates Yes for Read Protection Violation and No for Write = Protection Violation.) > On implementations on which a Machine Check interrupt can be caused by = referring to an invalid real address, executing a dcbz, dcbzep, or dcba = instruction can cause a delayed Machine Check interrupt by establishing = in the data cache a block that is associated with an invalid real = address. See Section 3.2 of Book II. A Machine Check interrupt can = eventually occur if and when a subsequent attempt is made to write that = block to main storage, for example as the result of executing an = instruc- tion that causes a cache miss for which the block is the target = for replacement or as the result of exe- cuting a dcbst, dcbstep, dcbf, = or dcbfep instruc- tion.=20 The dcbst related details for the code are (picking a failing example's = argument values): from =3D=3D 0x1c35b48 len =3D=3D 0x1014bb0 (example) starting at 0x1c35b00 ending with 0x2c4A680 (but it will span through 0x2c4A6FF) The code's calculations are based on: off =3D=3D (uintptr_t)from & (cacheline_size - 1) off =3D=3D 0x1c35b48 & 0x7F off =3D=3D 0x48 (len as in the argument here, not later updates) len+off =3D=3D 0x1014bb0 + 0x48 len+off =3D=3D 0x1014BF8 l =3D=3D 0x1014BF8 (initially) Note that len+off is not a multiple of the cache size. Repeated = subtractions of the cache size will end up with a non-zero remainder. (p as it is initialized here, not later updates) p =3D=3D from - off p =3D=3D 0x1c35b48 - 0x48 p =3D=3D 0x1c35b00 p+l =3D=3D 0x1c35b00+0x1014BF8 p+l =3D=3D 0x2c4A6F8 Note that 0x2c4A6F8 this is not cache aligned. Note that as the dcbst loop progresses p+l is constant (other than in = the middle of updating the pair). So when... l=3D=3D0xF8: p=3D=3D0x2c4A600 l=3D=3D0x78: p=3D=3D0x2c4A680 l<0: no dcbst for p It appears that the dcbst loop does span the range of cache-lines that = it should. But apparently the processor is rejecting some bytes from that range = when full cache-line sized units are counted. I would guess the = rejection is on the l=3D0x78 side of things that varies from example to = example. =3D=3D=3D Mark Millard markmiatdsl-only.net On 2015-Feb-8, at 01:16 AM, Mark Millard wrote: I've narrowed down greatly where the crashes happen, which need not be = where root-cause is: that could be earlier. In the following code [I'm using 10.1-RELEASE-p5 for reference here] $ svnlite diff sys/boot/ofw/libofw/ppc64_elf_freebsd.c=20 Index: sys/boot/ofw/libofw/ppc64_elf_freebsd.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/ofw/libofw/ppc64_elf_freebsd.c (revision 277808) +++ sys/boot/ofw/libofw/ppc64_elf_freebsd.c (working copy) @@ -59,7 +59,11 @@ * be done by the kernel after relocation. */ if (!strcmp((*result)->f_type, "elf kernel")) +{ +printf("ppc64_ofw_elf_loadfile before __syncicache\n"); __syncicache((void *) (*result)->f_addr, = (*result)->f_size); +printf("ppc64_ofw_elf_loadfile after __syncicache\n"); +} return (0); } for a directly-bootable (no crash) kernel-build both printf's are = displayed. (The above code part of /boot/loader .) But for the kernels that I build that fail to directly boot only the = first of the two printf's is displayed when a direct boot is attempted: = Openfirmware's notice with %SRR0 and %SRR1 shows up after that instead = of the text from the second printf. Based on that much it looks like the crash is either in evaluating the = arguments to __syncicache or happens during __syncicache's execution, = not after. Changing the first printf to something like the sequence: printf("ppc64_ofw_elf_loadfile before __syncicache\n"); printf("(void*)result: %p\n",(void*)result); printf("(void*)(*result): %p\n",(void*)(*result)); printf("(void*)(*result)->f_addr: %p\n",(void*)(*result)->f_addr); printf("(*result)->f_size : 0x%lx\n",(*result)->f_size); Shows that all of the stages print before the crash happens, answering = the question about evaluation of the arguments: there is no problem = evaluating them. So the crashes are strictly during __syncicache's activity. Only (*result)->f_size varies between the 3 examples that I've used: 10.1-RELEASE-p5 variant without VERBOSE_SYSINIT (and BOOTVERBOSE, = BOOTHOWTO). (boots fine) 10.1-RELEASE-p5 variant with VERBOSE_SYSINIT (and BOOTVERBOSE, = BOOTHOWTO). (crashes) 10.1-STABLE (-r278028) variant without VERBOSE_SYSINIT (and BOOTVERBOSE, = BOOTHOWTO). (crashes) What the above printf's reported was: (void*)result: 0x1c35b48 (void*)(*result): 0x1ebc0 (*result)->f_addr: 0x100000 10.1-RELEASE-p5 variant without VERBOSE_SYSINIT: (*result)->f_size: = 0x1014b80 10.1-RELEASE-p5 variant with VERBOSE_SYSINIT: (*result)->f_size: = 0x1014bb0 10.1-STABLE (-r278028) variant without VERBOSE_SYSINIT: = (*result)->f_size: 0x10175d0 (Listed in increasing order.) As I remember for the last two the crash report listed %SRR0: 0x1c2785c = for both. The "without VERBOSE_SYSINIT" one above does not crash and for = it the "ppc64_ofw_elf_loadfile after __syncicache" message shows up as = it should. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Feb-7, at 09:43 AM, Mark Millard wrote: Correction to earlier Email: VERBOSE_SYSINIT with DDB (and GDB) all = enabled (indirectly booted via using kernel10.1RE) got 0x1c277ec for the = %SRR0 value, not 0x1c277fc. So slightly different than Kernel10.1S's = 0x1c277fc (for this 10.1-STABLE variant). (I looked at the wrong notes = when composing the original Email.) More comparisons of kernel build options: VERBOSE_SYSINIT enabled with DDB (and GDB) disabled still has the = booting problem for my 10.1-RELEASE-p5 variant. It also still has the = 0x1c277ec for the %SRR0 value. For VERBOSE_SYSINIT disabled (DDB and GDB enabled) directly booted... Preloaded elf kernel "/boot/kernel/kernel" at 0x1106000. ... real memory =3D 17152118784 (16357 MB) available KVA =3D 7222611967 (6888 MB) Physical memory chunk(s): 0x0000000000024000 - 0x00000000000fffff, 901120 bytes (220 pages) 0x0000000001115000 - 0x00000000017fffff, 7254016 bytes (1771 pages) 0x0000000001814000 - 0x0000000001bfffff, 4112384 bytes (1004 pages) 0x0000000001c3d000 - 0x0000000001c3cfff, 0 bytes (0 pages) 0x0000000004cbd000 - 0x000000000fffffff, 187969536 bytes (45891 pages) 0x0000000020000000 - 0x000000007f5effff, 1600061440 bytes (390640 pages) 0x0000000100000000 - 0x0000000466827fff, 14604730368 bytes (3565608 = pages) 0x0000000200000000 - 0x00000001ffffffff, 0 bytes (0 pages) 0x0000000300000000 - 0x00000002ffffffff, 0 bytes (0 pages) 0x0000000400000000 - 0x00000003ffffffff, 0 bytes (0 pages) avail memory =3D 16374190080 (15615 MB) So 0x1c277ec is between the two: 0x0000000001814000 - 0x0000000001bfffff, 4112384 bytes (1004 pages) 0x0000000001c3d000 - 0x0000000001c3cfff, 0 bytes (0 pages) (But I do not know what most of the regions and holes are supposed to = be.) VERBOSE_SYSINIT, DDB, and GDB enabled but indirectly booted via = kernel10.1RE (via /boot/loader.conf's kernel=3D"kernel10.1RE"), = stopping, unloading, then doing "boot kernel": Preloaded elf kernel "/boot/kernel/kernel" at 0x1116000. ... real memory =3D 17152118784 (16357 MB) available KVA =3D 7222611967 (6888 MB) Physical memory chunk(s): 0x0000000000024000 - 0x00000000000fffff, 901120 bytes (220 pages) 0x0000000001105000 - 0x0000000001114fff, 65536 bytes (16 pages) 0x0000000001125000 - 0x00000000017fffff, 7188480 bytes (1755 pages) 0x0000000001814000 - 0x0000000001bfffff, 4112384 bytes (1004 pages) 0x0000000001c3d000 - 0x0000000001c3cfff, 0 bytes (0 pages) 0x0000000004cbd000 - 0x000000000fffffff, 187969536 bytes (45891 pages) 0x0000000020000000 - 0x000000007f5effff, 1600061440 bytes (390640 pages) 0x0000000100000000 - 0x0000000466827fff, 14604730368 bytes (3565608 = pages) 0x0000000200000000 - 0x00000001ffffffff, 0 bytes (0 pages) 0x0000000300000000 - 0x00000002ffffffff, 0 bytes (0 pages) 0x0000000400000000 - 0x00000003ffffffff, 0 bytes (0 pages) avail memory =3D 16374190080 (15615 MB) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Feb-7, at 03:49 AM, Mark Millard wrote: Nathan, you had the below written about my problems with booting my = builds of, say, 10.1-STABLE (kernel=3D"kernel10.1S" in = /boot/loaderl.conf) without involving the kernel from my build of = 10.1-RELEASE-p5 (kernel=3D"kernel10.1RE" or sometimes kernel=3D"kernel" = in /boot/loader.conf), where kernel=3D"kernel10.1RE" in = /boot/loader.conf boots just fine... > So this has to be some kind of icache issue. If you unload and reload=20= > the *same* kernel, does it also help? > -Nathan (Part of the evidence was: Using kernel=3D"kernel10.1RE" in = /boot/loader.conf, stopping at the 10sec prompt, unloading, and doing = "boot kernel 10.1S" lets my 10.1-STABLE builds boot that will not boot = directly.) Well I've got a little more information from a different direction: A = way to create the problem when building my 10.1-RELEASE-p5 kernel is to = enable VERBOSE_SYSINIT. More specifically the comparison/contrast I've = done so far is... I added the following 3 lines to my GENERIC64vtsc for my 10.1-RELEASE-p5 = source tree (no other changes elsewhere at all) options VERBOSE_SYSINIT options BOOTVERBOSE=3D1 options BOOTHOWTO=3DRB_VERBOSE and rebuilt kernel the via KERNCONF=3DGENERIC64vtsc INSTKERNNAME=3Dkernel = the resulting kernel load fails if referenced by /boot/loader.conf via = kernel=3D"kernel" line. The %SRR0 address value listed is the same as = for kernel10.1S: 1c277fc. But booting using kernel=3D"kernel10.1RE" in = /boot/loader.conf, stopping at the 10sec wait, unloading, and typing = "boot kernel" boots fine --just like "boot kernel10.1S". Note: GENERIC64vtsc has option DDB enabled (and GBD too). (This is = associated my with my information gathering for early G5 boot = crashes/hangups.) Note: This is the first time I've ever tried any of those 3 options. My = kernel10.1S build was not based on them. Then I changed the 3 lines by just commenting out the first of the 3 = that I had added #options VERBOSE_SYSINIT options BOOTVERBOSE=3D1 options BOOTHOWTO=3DRB_VERBOSE and rebuilt via KERNCONF=3DGENERIC64vtsc INSTKERNNAME=3Dkernel again. = The resulting /boot/kernel/... boots just fine when kernel=3D"kernel" is = used in /boot/loader.conf : no need for using kernel10.1RE or for = stopping to do anything special. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Mon Feb 9 21:57:38 2015 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 625A7375 for ; Mon, 9 Feb 2015 21:57:38 +0000 (UTC) Received: from sasl.smtp.pobox.com (pb-sasl1.int.icgroup.com [208.72.237.25]) by mx1.freebsd.org (Postfix) with ESMTP id 328B66A3 for ; Mon, 9 Feb 2015 21:57:37 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 036D4349E2; Mon, 9 Feb 2015 16:57:30 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from :content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; s=sasl; bh=nzEYQP5RSwNE0Z+9E0W5YW86Qss =; b=AlFZlUDTJlwQltCzmmoC372dS2TX4e0nwUpa15PmScqRJRQx/cfHdHkvX7l hRPw8No5EgitMElcpdwb+LuJtka1n090t8PvQBQ9EN8ZUbEbrLBWLVehwnUkgVl9 WOwnHZdcQ34kQzxnO2SKsMDCKtvDbzL56i0h6cyp4/kSzPgQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from :content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; q=dns; s=sasl; b=NmHPooB3NE3lfE3zqnIrC G2bgdNkxU4M9XkfBVi7SJCPkFrC3AqtvSrUK04mMKlbFCEVS4R18nRDaGKLmw97w hvzZXuXBGsCXhXyWhmaJvvQaKU2q1O9nfZggwQZUCZjwHPbLMLf/xku3E3Mpb9ts GZY1FhUEAiA55QONILFyPU= Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id ED7B9349E0; Mon, 9 Feb 2015 16:57:29 -0500 (EST) Received: from almini.rcthomas.org (unknown [208.53.120.31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id 30CDE349DE; Mon, 9 Feb 2015 16:57:29 -0500 (EST) From: Rick Thomas Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Feb 2015 13:57:25 -0800 Subject: repository of pre-compiled packages for powerpc? To: FreeBSD PowerPC ML Message-Id: <6A193C95-31B9-4C85-A7EE-CA98A3063981@pobox.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Pobox-Relay-ID: A4521534-B0A6-11E4-9643-DC3B3EDD908B-02150157!pb-sasl1.pobox.com 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, 09 Feb 2015 21:57:38 -0000 I=92ve installed FreeBSD 10.1 RELEASE on a PowerMac G4 Quicksilver. It = seems to work reasonably well, but the pkg command seems to have a = problem finding its repositories=85 Am I doing something wrong? > [root@grey ~]# pkg search port > pkg: Repository FreeBSD missing. 'pkg update' required > pkg: http://pkg.FreeBSD.org/FreeBSD:10:powerpc/latest/meta.txz: Not = Found > pkg: http://pkg.FreeBSD.org/FreeBSD:10:powerpc/latest/packagesite.txz: = Not Found > pkg: Repository FreeBSD cannot be opened. 'pkg update' required > [root@grey ~]# env > HOST=3Dgrey.rcthomas.org > SHELL=3D/bin/csh > TERM=3Dxterm-256color > GROUP=3Dwheel > USER=3Droot > HOSTTYPE=3DFreeBSD > PAGER=3Dmore > = PATH=3D/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local= /bin:/root/bin > MAIL=3D/var/mail/root > BLOCKSIZE=3DK > PWD=3D/root > EDITOR=3Dvi > SHLVL=3D2 > HOME=3D/root > OSTYPE=3DFreeBSD > VENDOR=3Dmotorola > LOGNAME=3Droot > MACHTYPE=3Dpowerpc Compiling ports takes *lots* of time on this decade old machine (700MHz, = single core, 1GB RAM) =97 not fun! Thanks! Rick= From owner-freebsd-ppc@FreeBSD.ORG Mon Feb 9 22:17:39 2015 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 A5A2B863 for ; Mon, 9 Feb 2015 22:17:39 +0000 (UTC) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 655658E8 for ; Mon, 9 Feb 2015 22:17:39 +0000 (UTC) Received: by mail-oi0-f51.google.com with SMTP id g201so5493650oib.10 for ; Mon, 09 Feb 2015 14:17:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oYk3JaQaZTiZH95/eIDrD4GQtsO2dCPdcSBIPhDiNUY=; b=SVAHQaRFs2G63OwJbLcQ43gO2nkWryNDALAT7obsttDWpIjy0KwnKcvZcS9V/M1sbu r42oTejUMGHqnGDogTzGqcbqJhc0kMj/fC3NM6sjhxlP9CSQmXEao8H2wPMQu2D6DZU+ mN1dXfRRx7nn/FEVqFYl7AQ+ZsnJvdNRIsFmyaplXwdDQfpvCSTB/UhejEqPevZh10F4 rhA35lfo2eZQv0FYOW6MxCMsBFebtJciYz4qW1OGtq9Tbgq7Dnej1jZFPW036U6gdNsD skJGTGkhmRv0Hlhrhs1DELBBrnsXlYXt7ymZs7USthv7vsiATCPJMUUPcwAJemmc8yRg I7+Q== MIME-Version: 1.0 X-Received: by 10.202.67.132 with SMTP id q126mr12706695oia.15.1423520258791; Mon, 09 Feb 2015 14:17:38 -0800 (PST) Received: by 10.202.176.214 with HTTP; Mon, 9 Feb 2015 14:17:38 -0800 (PST) Received: by 10.202.176.214 with HTTP; Mon, 9 Feb 2015 14:17:38 -0800 (PST) In-Reply-To: <6A193C95-31B9-4C85-A7EE-CA98A3063981@pobox.com> References: <6A193C95-31B9-4C85-A7EE-CA98A3063981@pobox.com> Date: Mon, 9 Feb 2015 16:17:38 -0600 Message-ID: Subject: Re: repository of pre-compiled packages for powerpc? From: Bill Sorenson To: Rick Thomas Content-Type: text/plain; charset=UTF-8 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: Mon, 09 Feb 2015 22:17:39 -0000 As of now I don't think there is an official repository for anything not arm or x86 or x64. I've toyed with the idea of setting up a PPC build machine for an unofficial repo, haven't gotten around to it. -Bill On Feb 9, 2015 3:57 PM, "Rick Thomas" wrote: > > I=E2=80=99ve installed FreeBSD 10.1 RELEASE on a PowerMac G4 Quicksilver.= It > seems to work reasonably well, but the pkg command seems to have a proble= m > finding its repositories=E2=80=A6 Am I doing something wrong? > > > [root@grey ~]# pkg search port > > pkg: Repository FreeBSD missing. 'pkg update' required > > pkg: http://pkg.FreeBSD.org/FreeBSD:10:powerpc/latest/meta.txz: Not > Found > > pkg: http://pkg.FreeBSD.org/FreeBSD:10:powerpc/latest/packagesite.txz: > Not Found > > pkg: Repository FreeBSD cannot be opened. 'pkg update' required > > > [root@grey ~]# env > > HOST=3Dgrey.rcthomas.org > > SHELL=3D/bin/csh > > TERM=3Dxterm-256color > > GROUP=3Dwheel > > USER=3Droot > > HOSTTYPE=3DFreeBSD > > PAGER=3Dmore > > > PATH=3D/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/loca= l/bin:/root/bin > > MAIL=3D/var/mail/root > > BLOCKSIZE=3DK > > PWD=3D/root > > EDITOR=3Dvi > > SHLVL=3D2 > > HOME=3D/root > > OSTYPE=3DFreeBSD > > VENDOR=3Dmotorola > > LOGNAME=3Droot > > MACHTYPE=3Dpowerpc > > > Compiling ports takes *lots* of time on this decade old machine (700MHz, > single core, 1GB RAM) =E2=80=94 not fun! > > Thanks! > Rick > _______________________________________________ > 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 Mon Feb 9 22:29:57 2015 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 E4902AC7 for ; Mon, 9 Feb 2015 22:29:57 +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 C98109EB for ; Mon, 9 Feb 2015 22:29:57 +0000 (UTC) Received: from zeppelin.tachypleus.net (airbears2-136-152-142-67.AirBears2.Berkeley.EDU [136.152.142.67]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.14.9) with ESMTPSA id t19MTtWE024708 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 9 Feb 2015 14:29:55 -0800 Message-ID: <54D934E3.9020407@freebsd.org> Date: Mon, 09 Feb 2015 14:29:55 -0800 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-ppc@freebsd.org Subject: Re: repository of pre-compiled packages for powerpc? References: <6A193C95-31B9-4C85-A7EE-CA98A3063981@pobox.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVahU8vzBIQJkEDk1CDEIWpHENdF/pMA5LJk8sO1s+9SqXHUL52jm1ErwUIQ66QQWgSC3weDublJ4u2nmWQSO/Eb6JPNzzKToa0= X-Sonic-ID: C;dB0ULKuw5BGCa2S47jkJAQ== M;RFdQLKuw5BGCa2S47jkJAQ== 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: Mon, 09 Feb 2015 22:29:58 -0000 There are some older unofficial packages at http://people.freebsd.org/~nwhitehorn/powerpc-10-packages. I'm currently setting up an official build machine using a quad-core POWER8 system, but need to work through some performance issues. -Nathan On 02/09/15 14:17, Bill Sorenson wrote: > As of now I don't think there is an official repository for anything not > arm or x86 or x64. I've toyed with the idea of setting up a PPC build > machine for an unofficial repo, haven't gotten around to it. > > -Bill > On Feb 9, 2015 3:57 PM, "Rick Thomas" wrote: > >> I’ve installed FreeBSD 10.1 RELEASE on a PowerMac G4 Quicksilver. It >> seems to work reasonably well, but the pkg command seems to have a problem >> finding its repositories… Am I doing something wrong? >> >>> [root@grey ~]# pkg search port >>> pkg: Repository FreeBSD missing. 'pkg update' required >>> pkg: http://pkg.FreeBSD.org/FreeBSD:10:powerpc/latest/meta.txz: Not >> Found >>> pkg: http://pkg.FreeBSD.org/FreeBSD:10:powerpc/latest/packagesite.txz: >> Not Found >>> pkg: Repository FreeBSD cannot be opened. 'pkg update' required >>> [root@grey ~]# env >>> HOST=grey.rcthomas.org >>> SHELL=/bin/csh >>> TERM=xterm-256color >>> GROUP=wheel >>> USER=root >>> HOSTTYPE=FreeBSD >>> PAGER=more >>> >> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin >>> MAIL=/var/mail/root >>> BLOCKSIZE=K >>> PWD=/root >>> EDITOR=vi >>> SHLVL=2 >>> HOME=/root >>> OSTYPE=FreeBSD >>> VENDOR=motorola >>> LOGNAME=root >>> MACHTYPE=powerpc >> >> Compiling ports takes *lots* of time on this decade old machine (700MHz, >> single core, 1GB RAM) — not fun! >> >> Thanks! >> Rick >> _______________________________________________ >> 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" >> > _______________________________________________ > 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 Feb 10 11:20:26 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 8DA39216; Tue, 10 Feb 2015 11:20:26 +0000 (UTC) Date: Tue, 10 Feb 2015 11:20:26 +0000 From: Alexey Dokuchaev To: Nathan Whitehorn Subject: Re: repository of pre-compiled packages for powerpc? Message-ID: <20150210112026.GA27961@FreeBSD.org> References: <6A193C95-31B9-4C85-A7EE-CA98A3063981@pobox.com> <54D934E3.9020407@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54D934E3.9020407@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-ppc@freebsd.org 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, 10 Feb 2015 11:20:26 -0000 On Mon, Feb 09, 2015 at 02:29:55PM -0800, Nathan Whitehorn wrote: > There are some older unofficial packages at > http://people.freebsd.org/~nwhitehorn/powerpc-10-packages. I'm currently > setting up an official build machine using a quad-core POWER8 system, > but need to work through some performance issues. > > [ reply-to and several bogus copies of mailman footer trimmed ] Guys, please, do not include mailman footer (and other irrelevant lines) in your replies. Pretty please. :( ./danfe From owner-freebsd-ppc@FreeBSD.ORG Tue Feb 10 18:38:19 2015 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 6954B2BB for ; Tue, 10 Feb 2015 18:38:19 +0000 (UTC) Received: from sasl.smtp.pobox.com (pb-sasl1.int.icgroup.com [208.72.237.25]) by mx1.freebsd.org (Postfix) with ESMTP id 340B9352 for ; Tue, 10 Feb 2015 18:38:18 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 488103710E; Tue, 10 Feb 2015 13:38:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; s=sasl; bh= 4ZBGRgiktxPBKdECUvfoljdCQaw=; b=TfQyXSyMz4PiAayUWI2yvn4ZWHmtdVT7 cQTTOVa4+ITTYJhz5aBH5+7iVHx1zgq4o/dQ+gnTYxNjfPqFAuCbEMZetDT3RFjY 51/kzt0NW1MGoLGrDvsmatppx7mOXaginMQ7V32nm/hPPHAEy0kV7zFj1lFtj14v +e71FYZANcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; q=dns; s= sasl; b=gWDmB0L/XmKGvw7lbXBKbMHHmd+5I4/iFh6Qz7HPkpnORQq0zTZPLUMr oM65q2NLUqwoWYlNVh7cc/+bW9OoFnOiUH0KPlhEnZ/1kSULYAivkF3nQaHAdEMl Q9tGCVVvwmY5qBqLvwRcVth5hO5yNtWIbDb1jBrA+AcHDuWTFX8= Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 404AA3710D; Tue, 10 Feb 2015 13:38:17 -0500 (EST) Received: from almini.rcthomas.org (unknown [208.53.120.31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id 5E0C13710C; Tue, 10 Feb 2015 13:38:16 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: repository of pre-compiled packages for powerpc? From: Rick Thomas In-Reply-To: Date: Tue, 10 Feb 2015 10:38:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0F0B837D-8637-4B1B-84E9-B04D71BA0BA7@pobox.com> References: <6A193C95-31B9-4C85-A7EE-CA98A3063981@pobox.com> To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.1878.6) X-Pobox-Relay-ID: FA4B5218-B153-11E4-9640-DC3B3EDD908B-02150157!pb-sasl1.pobox.com 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, 10 Feb 2015 18:38:19 -0000 Am I doing something wrong? OK, so I wanted to install gnome. I did cd /usr/ports/x11/gnome-desktop make config-recursive I answered a *lot* of questions =97 is there some way to say =93just take the defaults. please=94? Then make install It compiled a whole bunch of stuff =97 it took all night, in fact. =09 But it ended in an error as follows. > byte-compiling = /usr/ports/devel/py-setuptools27/work/stage/usr/local/lib/python3.4/site-p= ackages/_markerlib/__init__.py to __init__.cpython-34.pyc > writing byte-compilation script '/tmp/tmpo0usm3zz.py' > /usr/local/bin/python3.4 -O /tmp/tmpo0usm3zz.py > removing /tmp/tmpo0usm3zz.py > running install_egg_info > running egg_info > writing dependency_links to setuptools.egg-info/dependency_links.txt > writing requirements to setuptools.egg-info/requires.txt > writing top-level names to setuptools.egg-info/top_level.txt > writing setuptools.egg-info/PKG-INFO > writing entry points to setuptools.egg-info/entry_points.txt > reading manifest file 'setuptools.egg-info/SOURCES.txt' > reading manifest template 'MANIFEST.in' > writing manifest file 'setuptools.egg-info/SOURCES.txt' > Copying setuptools.egg-info to = /usr/ports/devel/py-setuptools27/work/stage/usr/local/lib/python3.4/site-p= ackages/setuptools-5.5.1-py3.4.egg-info > running install_scripts > Installing easy_install-3.4 script to = /usr/ports/devel/py-setuptools27/work/stage/usr/local/bin > writing list of installed files to = '/usr/ports/devel/py-setuptools27/work/.PLIST.pymodtmp' > install -o root -g wheel -m 0644 = /usr/ports/devel/py-setuptools27/../py-setuptools/files/easy-install.pth.d= ist = /usr/ports/devel/py-setuptools27/work/stage/usr/local/lib/python3.4/site-p= ackages/ > =3D=3D=3D=3D> Compressing man pages (compress-man) > =3D=3D=3D> Installing for py34-setuptools34-5.5.1_1 > =3D=3D=3D> Checking if py34-setuptools34 already installed > =3D=3D=3D> py34-setuptools34-5.5.1_1 is already installed > You may wish to ``make deinstall'' and install this port again > by ``make reinstall'' to upgrade it properly. > If you really wish to overwrite the old port of = py34-setuptools34 > without deleting it first, set the variable "FORCE_PKG_REGISTER" > in your environment or the "make install" command line. > *** Error code 1 >=20 > Stop. > make[3]: stopped in /usr/ports/devel/py-setuptools27 > *** Error code 1 >=20 > Stop. > make[2]: stopped in /usr/ports/textproc/py-libxml2 > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/ports/textproc/itstool > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/x11/gnome-desktop >=20 I tried taking the advice in the error message by doing > root@grey:/usr/ports/devel/py-setuptools34 # make deinstall > =3D=3D=3D> Deinstalling for py34-setuptools34 > =3D=3D=3D> Deinstalling py34-setuptools34-5.5.1_1 > Updating database digests format: 100% > Checking integrity... done (0 conflicting) > Deinstallation has been requested for the following 1 packages (of 0 = packages in the universe): >=20 > Installed packages to be REMOVED: > py34-setuptools34-5.5.1_1 >=20 > The operation will free 2 MiB. > [1/1] Deinstalling py34-setuptools34-5.5.1_1... > [1/1] Deleting files for py34-setuptools34-5.5.1_1: 100% and > root@grey:/usr/ports/devel/py-setuptools34 # make reinstall > =3D=3D=3D> Installing for py34-setuptools34-5.5.1_1 > =3D=3D=3D> py34-setuptools34-5.5.1_1 depends on file: = /usr/local/bin/python3.4 - found > /usr/local/bin/python3.4 > =3D=3D=3D> Registering installation for py34-setuptools34-5.5.1_1 > Installing py34-setuptools34-5.5.1_1... > ********************************************************************* >=20 > The script /usr/local/bin/easy_install was already installed > on your system, so only the script = /usr/local/bin/easy_install-%%PYVER%% > has been added. >=20 > ********************************************************************* Then I went back to /usr/ports/x11/gnome-desktop make install And got the same errors. > root@grey:/usr/ports/x11/gnome-desktop # make install > . . . > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on package: iso-codes>=3D0 = - found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on package: = gsettings-desktop-schemas>=3D0 - found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on package: = xkeyboard-config>=3D0 - found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on package: libxkbfile>=3D0 = - found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on executable: itstool - = not found > =3D=3D=3D> Verifying install for itstool in = /usr/ports/textproc/itstool > =3D=3D=3D> itstool-2.0.2_1 depends on file: = /usr/local/lib/python2.7/site-packages/libxml2.py - not found > =3D=3D=3D> Verifying install for = /usr/local/lib/python2.7/site-packages/libxml2.py in = /usr/ports/textproc/py-libxml2 > =3D=3D=3D> py27-libxml2-2.9.2 depends on package: = py27-setuptools27>0 - not found > =3D=3D=3D> Verifying install for py27-setuptools27>0 in = /usr/ports/devel/py-setuptools27 > =3D=3D=3D> Installing for py34-setuptools34-5.5.1_1 > =3D=3D=3D> py34-setuptools34-5.5.1_1 depends on file: = /usr/local/bin/python3.4 - found > =3D=3D=3D> Checking if py34-setuptools34 already installed > =3D=3D=3D> py34-setuptools34-5.5.1_1 is already installed > You may wish to ``make deinstall'' and install this port again > by ``make reinstall'' to upgrade it properly. > If you really wish to overwrite the old port of = py34-setuptools34 > without deleting it first, set the variable "FORCE_PKG_REGISTER" > in your environment or the "make install" command line. > *** Error code 1 >=20 > Stop. > make[3]: stopped in /usr/ports/devel/py-setuptools27 > *** Error code 1 >=20 > Stop. > make[2]: stopped in /usr/ports/textproc/py-libxml2 > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/ports/textproc/itstool > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/x11/gnome-desktop What can I do to get past this point? Thanks, Rick On Feb 9, 2015, at 2:17 PM, Bill Sorenson = wrote: > As of now I don't think there is an official repository for anything = not > arm or x86 or x64. I've toyed with the idea of setting up a PPC build > machine for an unofficial repo, haven't gotten around to it. >=20 > -Bill From owner-freebsd-ppc@FreeBSD.ORG Tue Feb 10 22:35:51 2015 Return-Path: Delivered-To: freebsd-powerpc@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 5F059E84 for ; Tue, 10 Feb 2015 22:35:51 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 41CF032E for ; Tue, 10 Feb 2015 22:35:51 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t1AMZpUK007179 for ; Tue, 10 Feb 2015 22:35:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-powerpc@FreeBSD.org Subject: [Bug 194183] [arm] math/R missing libquadmath to compile Date: Tue, 10 Feb 2015 22:35:51 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bf@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 10 Feb 2015 22:35:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194183 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress CC| |freebsd-powerpc@FreeBSD.org --- Comment #8 from Sean Bruno --- Going to run a mips32 and mips64 test just to see if it builds as is suspected. Adding some of the powerpc guys to the list to see if they can test as well. Probably, OPTIONS_DEFAULT_powerpc+= MISSING if there's no libquadmath on these arch's ? Unable to test sparc64, but hopefully someone can test? -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-ppc@FreeBSD.ORG Wed Feb 11 01:16:59 2015 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 F2F9C714 for ; Wed, 11 Feb 2015 01:16:59 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 AEE3B7D2 for ; Wed, 11 Feb 2015 01:16:59 +0000 (UTC) Received: (qmail 25196 invoked from network); 11 Feb 2015 01:16:52 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 11 Feb 2015 01:16:52 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 10 Feb 2015 20:16:52 -0500 (EST) Received: (qmail 12981 invoked from network); 11 Feb 2015 01:16:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Feb 2015 01:16:51 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id D4DA31C405E for ; Tue, 10 Feb 2015 17:16:45 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fixing powerpc64 /boot/loader's kernel page handing: suggestions? Message-Id: Date: Tue, 10 Feb 2015 17:16:49 -0800 To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) 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, 11 Feb 2015 01:17:00 -0000 Context: Unfortunately this takes me a bit to describe... powerpc 64 FreeBSD 10.1-??? variants on a PowerMac G5 Quad-Core, built = on the same machine. I expect the issue applies to some plain powerpc = contexts as well as some other powerpc64 contexts. As example context = where my issue occurs is: > 10.1-RELEASE-p5 > 10.1-RELEASE-p5 > FreeBSD FBSDG5M1 10.1-RELEASE-p5 FreeBSD 10.1-RELEASE-p5 #0 r277808M: = Fri Jan 30 00:58:33 PST 2015 = root@FBSDG5M1:/usr/obj/usr/home/markmi/src_10_1_releng/sys/GENERIC64vtsc = powerpc But I also get is for various vintages of 10.1-STABLE (and = 11.0-CURRENT). I use 10.1-RELEASE-p5 here because I happen to have a = build that avoids the problem and I know what to set for that build to = regenerated --and I know at least one thing to to turn on for builds to = create the problem. > root@FBSDG5M1:/usr/home/markmi/src_10_1_releng # more = sys/powerpc/conf/GENERIC64vtsc=20 > include GENERIC64 > ident GENERIC64vtsc >=20 > nooptions PS3 #Sony Playstation 3 = HACK!!! to allow sc >=20 > options DDB # HACK!!! to dump early crash = info (but 11.0-CURRENT already has it) > options GDB # HACK!!! ... > options VERBOSE_SYSINIT # VERBOSE_SYSINT blocks direct = booting for my 10.1-RELEASE-p5 variants: Crashes when the loader is in = __syncicache doing dcbst's. > options BOOTVERBOSE=3D1 > options BOOTHOWTO=3DRB_VERBOSE > #options KTR > #options KTR_MASK=3DKTR_TRAP > #options KTR_CPUMASK=3D0xF > #options KTR_VERBOSE >=20 > # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting > device sc > #device kbdmux # HACK: already listed by vt > options SC_OFWFB # OFW frame buffer > options SC_DFLT_FONT # compile font in > makeoptions SC_DFLT_FONT=3Dcp437 >=20 >=20 > # Disable extra checking typically used for FreeBSD 11.0-CURRENT: > nooptions DEADLKRES #Enable the deadlock resolver > nooptions INVARIANTS #Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT #Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS #Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN #Don't run witness on = spinlocks for speed > nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones For my temporarily extended ELF_VERBOSE code [and other printf's] that = also reports on non-PT_LOADs (which are otherwise skipped) what it = reports for booting various 10.1-??? kernel builds is the sequence: PT_PHDR PT_INTERP PT_LOAD (for .text) (using archsw.arch_copyin then kern_pread) Address range example: 0x100000-0xbe017b PT_LOAD (for .data) (using kern_pread) Address range for the same example: 0xbf0000-0xea4b7f PT_DYNAMIC PT_GNU_STACK symtab strtab Final address for the same example: 0x1114baf The issue happens when there are such unreferenced pages where I = indicated. It turns out for what I started this investigation with that = if I commented out VERBOSE_SYSINIT in GENERIC64vtsc (listed earlier) = then no unreferenced pages appear but with VERBOSE_SYSINT there are such = pages (holding the rest of the context constant). But this is not the = only way to get such unreferenced pages. For example my 10.1-STABLE = build has unreferenced pages but does not have VERBOSE_SYSINIT (yet). When there are unreferenced pages between the two PT_LOADs those pages = do not get archsw_arch_copyin or kern_pread handling. (kern_pread in = turn uses archsw.arch_readin.) For my PowerMac G5 Quad-Core context those archsw.arch_ routines end = up being ofw_copyin and ofw_readin. Those routines in turn call = ofw_memmap which includes doing: > if (OF_call_method("claim", memory, 3, 1, destp, dlen, 0, = &addr) > =3D=3D -1) { > printf("ofw_mapmem: physical claim failed\n"); > return (ENOMEM); > } > =20 > /* > * We only do virtual memory management when real_mode is = false. > */ > if (real_mode =3D=3D 0) { > if (OF_call_method("claim", mmu, 3, 1, destp, dlen, 0, = &addr) > =3D=3D -1) { > printf("ofw_mapmem: virtual claim failed\n"); > return (ENOMEM); > } >=20 > if (OF_call_method("map", mmu, 4, 0, destp, destp, = dlen, 0) > =3D=3D -1) { > printf("ofw_mapmem: map failed\n"); > return (ENOMEM); > } > } and during load-time this is what programs the PowerPC to have the PTEG = entries (and whatever else) that instructions like dcbst require (since = MSR[DR]=3D1). The crashes are at the first dcbst in __syncicache execution that = reference the missing pages. (It seems unlikely that there is any other = usage of those pages.) The crash reports missing PTEG entries (DSISR for = IV 0x300). (Apple's openfirmware word .registers shows the recorded = register status from the crash. After the crash the PowerMac is in = Apple's context, not FreeBSD's.) The __syncicache use results from the following > int > ppc64_ofw_elf_loadfile(char *filename, u_int64_t dest, > struct preloaded_file **result) > { > int r; >=20 > r =3D __elfN(loadfile)(filename, dest, result); > if (r !=3D 0) > return (r); >=20 > /* > * No need to sync the icache for modules: this will > * be done by the kernel after relocation. > */ > if (!strcmp((*result)->f_type, "elf kernel")) > __syncicache((void *) (*result)->f_addr, = (*result)->f_size); > return (0); > } (powerpc has a similar sequence with __syncicache as I remember.) For = some reason the __syncicache usage is set up to span into or beyond the = .data segment, not just the .text one. I do not know why. __elfN(loadfile)'s interface is not designed to return multiple address = ranges and is returning one range that spans into both the PT_LOAD = ranges (.text and .data) and any unreferenced pages that are between = them. (In fact it spans even more afterwards as I remember.) Questions: Anyone have a clue about why the __syncicache use is set up to span into = .data (and more) and not just span .text --and willing to explain a = little? As far as solution directions go: this looks like a subject area = appropriate to general FreeBSD use base on the available evidence. A = local personal hack does not seem appropriate. So... A) Should the link of the kernel be producing a kernel with unreferenced = pages between the two PT_LOADs (between .text and .data)? Is the proper = fix to prevent those pages from existing in linked kernels? vs. B) Is it okay for those unreferenced pages to be there between the two = PT_LOADs? If yes... B1) Should something like the ofw_memmap activity be forced on those = otherwise unreferenced pages so that the later __syncicache use can stay = as it is? vs. B2) Should the unreferenced pages be skipped by making separate = __synicache calls for each PT_LOAD (.text segment and then .data segment = and beyond(?))? vs. B3) Should only the .text segment be spanned by the __syncicache use? = Some other more specific range that avoids those unreferenced pages? It would appear that all but (A) involve changing the interface provided = by __elfN(loadfile) and/or the interfaces it uses: the fix does not = appear well localized. (A) may have its own such issues but in other = code or files that I've not looked at. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Wed Feb 11 13:00:43 2015 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 5967BE72 for ; Wed, 11 Feb 2015 13:00:43 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 0ED6BD1B for ; Wed, 11 Feb 2015 13:00:41 +0000 (UTC) Received: (qmail 6993 invoked from network); 11 Feb 2015 13:00:40 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 11 Feb 2015 13:00:40 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 11 Feb 2015 08:00:40 -0500 (EST) Received: (qmail 24732 invoked from network); 11 Feb 2015 13:00:39 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Feb 2015 13:00:39 -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-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 01E341C43A7; Wed, 11 Feb 2015 05:00:36 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Fixing powerpc64 /boot/loader's kernel page handing: suggestions? [my screwup!] From: Mark Millard In-Reply-To: Date: Wed, 11 Feb 2015 05:00:37 -0800 Message-Id: <3B68D71E-806B-4826-A603-1141E70A281C@dsl-only.net> References: To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=utf-8 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: Wed, 11 Feb 2015 13:00:43 -0000 The unreferenced pages were *my* screw up and so I have the answer to my = questions: I typed the target value 16 to .align instead of typing the power of 2 = (i.e., 4) --and then repeatedly read-in my intent, not what the source = said/implied. That things prior to .data ended within a page of such a = 2**16 boundary for a notable time in my activities just happened to be = the case: The mistake has been in my environment for a long time despite = my only recently discovering the crash issue with recent builds that = I=E2=80=99d done. So the answer to my questions was option (A): Avoid having the link = produce the unreferenced pages. (By keeping alignments smaller than a = page --by in turn specifying the power of 2 like I should have.) At least I got an exploration of more of the FreeBSD code out of my = mistake... =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Feb-10, at 05:16 PM, Mark Millard = wrote: Context: Unfortunately this takes me a bit to describe... powerpc 64 FreeBSD 10.1-??? variants on a PowerMac G5 Quad-Core, built = on the same machine. I expect the issue applies to some plain powerpc = contexts as well as some other powerpc64 contexts. As example context = where my issue occurs is: > 10.1-RELEASE-p5 > 10.1-RELEASE-p5 > FreeBSD FBSDG5M1 10.1-RELEASE-p5 FreeBSD 10.1-RELEASE-p5 #0 r277808M: = Fri Jan 30 00:58:33 PST 2015 = root@FBSDG5M1:/usr/obj/usr/home/markmi/src_10_1_releng/sys/GENERIC64vtsc = powerpc But I also get is for various vintages of 10.1-STABLE (and = 11.0-CURRENT). I use 10.1-RELEASE-p5 here because I happen to have a = build that avoids the problem and I know what to set for that build to = regenerated --and I know at least one thing to to turn on for builds to = create the problem. > root@FBSDG5M1:/usr/home/markmi/src_10_1_releng # more = sys/powerpc/conf/GENERIC64vtsc=20 > include GENERIC64 > ident GENERIC64vtsc >=20 > nooptions PS3 #Sony Playstation 3 = HACK!!! to allow sc >=20 > options DDB # HACK!!! to dump early crash = info (but 11.0-CURRENT already has it) > options GDB # HACK!!! ... > options VERBOSE_SYSINIT # VERBOSE_SYSINT blocks direct = booting for my 10.1-RELEASE-p5 variants: Crashes when the loader is in = __syncicache doing dcbst's. > options BOOTVERBOSE=3D1 > options BOOTHOWTO=3DRB_VERBOSE > #options KTR > #options KTR_MASK=3DKTR_TRAP > #options KTR_CPUMASK=3D0xF > #options KTR_VERBOSE >=20 > # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting > device sc > #device kbdmux # HACK: already listed by vt > options SC_OFWFB # OFW frame buffer > options SC_DFLT_FONT # compile font in > makeoptions SC_DFLT_FONT=3Dcp437 >=20 >=20 > # Disable extra checking typically used for FreeBSD 11.0-CURRENT: > nooptions DEADLKRES #Enable the deadlock resolver > nooptions INVARIANTS #Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT #Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS #Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN #Don't run witness on = spinlocks for speed > nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones For my temporarily extended ELF_VERBOSE code [and other printf's] that = also reports on non-PT_LOADs (which are otherwise skipped) what it = reports for booting various 10.1-??? kernel builds is the sequence: PT_PHDR PT_INTERP PT_LOAD (for .text) (using archsw.arch_copyin then kern_pread) Address range example: 0x100000-0xbe017b PT_LOAD (for .data) (using kern_pread) Address range for the same example: 0xbf0000-0xea4b7f PT_DYNAMIC PT_GNU_STACK symtab strtab Final address for the same example: 0x1114baf The issue happens when there are such unreferenced pages where I = indicated. It turns out for what I started this investigation with that = if I commented out VERBOSE_SYSINIT in GENERIC64vtsc (listed earlier) = then no unreferenced pages appear but with VERBOSE_SYSINT there are such = pages (holding the rest of the context constant). But this is not the = only way to get such unreferenced pages. For example my 10.1-STABLE = build has unreferenced pages but does not have VERBOSE_SYSINIT (yet). When there are unreferenced pages between the two PT_LOADs those pages = do not get archsw_arch_copyin or kern_pread handling. (kern_pread in = turn uses archsw.arch_readin.) For my PowerMac G5 Quad-Core context those archsw.arch_ routines end = up being ofw_copyin and ofw_readin. Those routines in turn call = ofw_memmap which includes doing: > if (OF_call_method("claim", memory, 3, 1, destp, dlen, 0, = &addr) > =3D=3D -1) { > printf("ofw_mapmem: physical claim failed\n"); > return (ENOMEM); > } >=20 > /* > * We only do virtual memory management when real_mode is = false. > */ > if (real_mode =3D=3D 0) { > if (OF_call_method("claim", mmu, 3, 1, destp, dlen, 0, = &addr) > =3D=3D -1) { > printf("ofw_mapmem: virtual claim failed\n"); > return (ENOMEM); > } >=20 > if (OF_call_method("map", mmu, 4, 0, destp, destp, = dlen, 0) > =3D=3D -1) { > printf("ofw_mapmem: map failed\n"); > return (ENOMEM); > } > } and during load-time this is what programs the PowerPC to have the PTEG = entries (and whatever else) that instructions like dcbst require (since = MSR[DR]=3D1). The crashes are at the first dcbst in __syncicache execution that = reference the missing pages. (It seems unlikely that there is any other = usage of those pages.) The crash reports missing PTEG entries (DSISR for = IV 0x300). (Apple's openfirmware word .registers shows the recorded = register status from the crash. After the crash the PowerMac is in = Apple's context, not FreeBSD's.) The __syncicache use results from the following > int > ppc64_ofw_elf_loadfile(char *filename, u_int64_t dest, > struct preloaded_file **result) > { > int r; >=20 > r =3D __elfN(loadfile)(filename, dest, result); > if (r !=3D 0) > return (r); >=20 > /* > * No need to sync the icache for modules: this will > * be done by the kernel after relocation. > */ > if (!strcmp((*result)->f_type, "elf kernel")) > __syncicache((void *) (*result)->f_addr, = (*result)->f_size); > return (0); > } (powerpc has a similar sequence with __syncicache as I remember.) For = some reason the __syncicache usage is set up to span into or beyond the = .data segment, not just the .text one. I do not know why. __elfN(loadfile)'s interface is not designed to return multiple address = ranges and is returning one range that spans into both the PT_LOAD = ranges (.text and .data) and any unreferenced pages that are between = them. (In fact it spans even more afterwards as I remember.) Questions: Anyone have a clue about why the __syncicache use is set up to span into = .data (and more) and not just span .text --and willing to explain a = little? As far as solution directions go: this looks like a subject area = appropriate to general FreeBSD use base on the available evidence. A = local personal hack does not seem appropriate. So... A) Should the link of the kernel be producing a kernel with unreferenced = pages between the two PT_LOADs (between .text and .data)? Is the proper = fix to prevent those pages from existing in linked kernels? vs. B) Is it okay for those unreferenced pages to be there between the two = PT_LOADs? If yes... B1) Should something like the ofw_memmap activity be forced on those = otherwise unreferenced pages so that the later __syncicache use can stay = as it is? vs. B2) Should the unreferenced pages be skipped by making separate = __synicache calls for each PT_LOAD (.text segment and then .data segment = and beyond(?))? vs. B3) Should only the .text segment be spanned by the __syncicache use? = Some other more specific range that avoids those unreferenced pages? It would appear that all but (A) involve changing the interface provided = by __elfN(loadfile) and/or the interfaces it uses: the fix does not = appear well localized. (A) may have its own such issues but in other = code or files that I've not looked at. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Thu Feb 12 02:47:01 2015 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 09B82D39 for ; Thu, 12 Feb 2015 02:47:01 +0000 (UTC) Received: from sasl.smtp.pobox.com (pb-sasl1.int.icgroup.com [208.72.237.25]) by mx1.freebsd.org (Postfix) with ESMTP id C90C0387 for ; Thu, 12 Feb 2015 02:47:00 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 6B10537ABC; Wed, 11 Feb 2015 21:46:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from :content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; s=sasl; bh=Q6m+r6HVUzA78H4KoJKJ8vAL3bs =; b=gSN8qGiBmhQsIqJWJTSQqESo1OQj7KTC+LRkihcxZXWgQBzTjsq97cwWylT D/LoACHcwE9G36NbtLYD9Mo+TZxPD9Jhf7W4v4aTPpdVkhdoyK8CHB9beQZGVzRC BGzhWRpiCjWo153cmyldY0NWC6tJe7RoTQwc5ZLedWlcboxo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from :content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; q=dns; s=sasl; b=AS41/Arg25djXxWl4jvSQ CIO4/AJDI3fOxtD8CUBRxIOl3H4p61lGXdsJCP1y1JqwEV8qDSWio+1dR1e1Na0z XiJfAcmpOJyOFDKr3gTszUEVO6NwOgIWYBj8Ij0Q5M8TWOybjoKuQCy2PjH+Lgrq n348GTURVp4AZEEpCcMtR0= Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 6052037ABA; Wed, 11 Feb 2015 21:46:53 -0500 (EST) Received: from almini.rcthomas.org (unknown [208.53.120.31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id 621E837AB9; Wed, 11 Feb 2015 21:46:52 -0500 (EST) From: Rick Thomas Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Feb 2015 18:46:49 -0800 Subject: luajit doesn't compile on powerpc (among others) but is required to install gnome-desktop... To: FreeBSD PowerPC ML Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Pobox-Relay-ID: 666CB708-B261-11E4-8EE7-8FDD009B7A5A-02150157!pb-sasl1.pobox.com 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: Thu, 12 Feb 2015 02:47:01 -0000 Continuing to try to install gnome-desktop on my Apple PowerMac G4 = =93Quicksilver=94 with FreeBSD 10.1=85 I get the following: > root@grey:/root # cd /usr/ports/lang/luajit >=20 > root@grey:/usr/ports/lang/luajit # make install > =3D=3D=3D> luajit-2.0.3 is marked as broken: Does not compile on = ia64, powerpc, or sparc64. > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/lang/luajit Any suggestions? The reason I tried this (I never heard of =93lua=94 before now!) is that = it seems to be required for installing the gnome-desktop from ports. As = follows: > root@grey:/usr/ports/x11/gnome-desktop # make install > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on package: iso-codes>=3D0 = - found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on package: = gsettings-desktop-schemas>=3D0 - found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on package: = xkeyboard-config>=3D0 - found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on package: libxkbfile>=3D0 = - found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on executable: itstool - = found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on executable: bison - = found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on executable: msgfmt - = found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on executable: gmake - = found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on executable: pkgconf - = found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on file: = /usr/local/bin/python3.4 - found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on executable: python3 - = found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on file: = /usr/local/libdata/pkgconfig/x11.pc - found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on file: = /usr/local/libdata/pkgconfig/xrandr.pc - found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on file: = /usr/local/libdata/pkgconfig/xext.pc - found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on file: = /usr/local/bin/intltool-extract - found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on executable: = g-ir-scanner - found > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on shared library: = libstartup-notification-1.so - found = (/usr/local/lib/libstartup-notification-1.so.0.0.0) > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on shared library: = libintl.so - found (/usr/local/lib/libintl.so.8.1.3) > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on shared library: = libatk-1.0.so - found (/usr/local/lib/libatk-1.0.so.0.21409.1) > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on shared library: = libglib-2.0.so - found (/usr/local/lib/libglib-2.0.so.0.4200.1) > =3D=3D=3D> gnome-desktop-3.14.2_1 depends on shared library: = libgtk-3.so - not found > =3D=3D=3D> Verifying for libgtk-3.so in = /usr/ports/x11-toolkits/gtk30 > =3D=3D=3D> gtk3-3.14.7 depends on package: at-spi2-atk>=3D0 - found > =3D=3D=3D> gtk3-3.14.7 depends on executable: msgfmt - found > =3D=3D=3D> gtk3-3.14.7 depends on executable: gmake - found > =3D=3D=3D> gtk3-3.14.7 depends on executable: pkgconf - found > =3D=3D=3D> gtk3-3.14.7 depends on file: = /usr/local/libdata/pkgconfig/xext.pc - found > =3D=3D=3D> gtk3-3.14.7 depends on file: = /usr/local/libdata/pkgconfig/xrender.pc - found > =3D=3D=3D> gtk3-3.14.7 depends on file: = /usr/local/libdata/pkgconfig/x11.pc - found > =3D=3D=3D> gtk3-3.14.7 depends on file: = /usr/local/libdata/pkgconfig/xinerama.pc - found > =3D=3D=3D> gtk3-3.14.7 depends on file: = /usr/local/libdata/pkgconfig/xi.pc - found > =3D=3D=3D> gtk3-3.14.7 depends on file: = /usr/local/libdata/pkgconfig/xrandr.pc - found > =3D=3D=3D> gtk3-3.14.7 depends on file: = /usr/local/libdata/pkgconfig/xcursor.pc - found > =3D=3D=3D> gtk3-3.14.7 depends on file: = /usr/local/libdata/pkgconfig/xfixes.pc - found > =3D=3D=3D> gtk3-3.14.7 depends on file: = /usr/local/libdata/pkgconfig/xdamage.pc - found > =3D=3D=3D> gtk3-3.14.7 depends on file: = /usr/local/libdata/pkgconfig/xcomposite.pc - found > =3D=3D=3D> gtk3-3.14.7 depends on executable: gtk-update-icon-cache = - found > =3D=3D=3D> gtk3-3.14.7 depends on executable: g-ir-scanner - found > =3D=3D=3D> gtk3-3.14.7 depends on file: /usr/local/bin/perl5.16.3 - = found > =3D=3D=3D> gtk3-3.14.7 depends on shared library: libcolord.so - not = found > =3D=3D=3D> Verifying for libcolord.so in /usr/ports/graphics/colord > =3D=3D=3D> colord-1.2.4 depends on executable: docbook2html - not = found > =3D=3D=3D> Verifying install for docbook2html in = /usr/ports/textproc/docbook-utils > =3D=3D=3D> docbook-utils-0.6.14_13 depends on package: = docbook-sgml>0 - found > =3D=3D=3D> docbook-utils-0.6.14_13 depends on package: = dsssl-docbook-modular>0 - found > =3D=3D=3D> docbook-utils-0.6.14_13 depends on executable: nsgmls - = found > =3D=3D=3D> docbook-utils-0.6.14_13 depends on executable: jadetex - = not found > =3D=3D=3D> Verifying install for jadetex in = /usr/ports/print/tex-jadetex > =3D=3D=3D> tex-jadetex-3.13_2 depends on file: = /usr/local/share/texmf-dist/README - not found > =3D=3D=3D> Verifying install for /usr/local/share/texmf-dist/README = in /usr/ports/print/texlive-texmf > =3D=3D=3D> texlive-texmf-20140525_4 depends on executable: tlmgr - = not found > =3D=3D=3D> Verifying install for tlmgr in = /usr/ports/print/texlive-base > =3D=3D=3D> Building for texlive-base-20140525_6 > gmake[9]: Entering directory = '/usr/ports/print/texlive-base/work/texlive-20140525-source' > Making all in . > gmake[10]: Entering directory = '/usr/ports/print/texlive-base/work/texlive-20140525-source' > gmake[10]: Leaving directory = '/usr/ports/print/texlive-base/work/texlive-20140525-source' > Making all in doc > gmake[10]: Entering directory = '/usr/ports/print/texlive-base/work/texlive-20140525-source/doc' > gmake[10]: Nothing to be done for 'all'. > gmake[10]: Leaving directory = '/usr/ports/print/texlive-base/work/texlive-20140525-source/doc' > Making all in libs > gmake[10]: Entering directory = '/usr/ports/print/texlive-base/work/texlive-20140525-source/libs' > Making all in . > gmake[11]: Entering directory = '/usr/ports/print/texlive-base/work/texlive-20140525-source/libs' > =3D=3D=3D configuring in luajit = (/usr/ports/print/texlive-base/work/texlive-20140525-source/libs/luajit) > make: running /bin/sh './configure' '--disable-option-checking' = '--prefix=3D/usr/local' '--disable-native-texlive-build' = '--disable-web-progs' '--disable-psutils' '--enable-shared' = '--disable-t1utils' '--disable-dvipdfmx' '--disable-dvipdfm-x' = '--disable-xdvipdfmx' '--enable-build-in-source-tree' = '--datarootdir=3D/usr/local/share' '--with-system-freetype' = '--with-freetype-includes=3D/usr/local/include/freetype1/freetype' = '--with-freetype-libdir=3D/usr/local/lib' '--with-system-freetype2' = '--with-freetype2-includes=3D/usr/local/include/freetype2' = '--with-freetype2-libdir=3D/usr/local/lib' '--with-system-cairo' = '--with-system-gd' '--with-system-graphite' '--with-system-icu' = '--with-icu-include=3D/usr/local/include' = '--with-icu-libdir=3D/usr/local/lib' '--with-system-kpathsea' = '--with-kpathsea-include=3D/usr/local/include/kpathsea' = '--with-kpathsea-libdir=3D/usr/local/lib' '--with-system-libgs' = '--with-libgs-includes=3D/usr/local/include' = '--with-libgs-libdir=3D/usr/local/lib' '--with-system-libpaper' = '--with-libpaper-includes=3D/usr/local/include' = '--with-libpaper-libdir=3D/usr/local/lib' '--with-system-libpng' = '--with-system-pixman' '--with-system-poppler' '--with-system-ptexenc' = '--with-ptexenc-include=3D/usr/local/include/ptexenc' = '--with-ptexenc-libdir=3D/usr/local/lib' '--with-system-t1lib' = '--with-system-teckit' '--with-xpdf-includes=3D/usr/local/include/poppler'= '--with-xpdf-libdir=3D/usr/local/lib' '--with-system-xpdf' = '--with-system-zziplib' '--with-system-zlib' = '--x-libraries=3D/usr/local/lib' '--x-includes=3D/usr/local/include' = '--mandir=3D/usr/local/man' '--infodir=3D/usr/local/info/' = '--build=3Dpowerpc-portbld-freebsd10.1' = 'build_alias=3Dpowerpc-portbld-freebsd10.1' 'CC=3Dcc' 'CFLAGS=3D-O2 = -pipe -I/usr/local/include -I/usr/local/include/kpathsea = -I/usr/local/include/ptexenc -fno-strict-aliasing' 'LDFLAGS=3D' 'LIBS=3D' = 'CPPFLAGS=3D' 'CPP=3Dcpp' 'CXX=3Dc++' 'CXXFLAGS=3D-O2 -pipe = -I/usr/local/include -I/usr/local/include/kpathsea = -I/usr/local/include/ptexenc -fno-strict-aliasing ' '--enable-largefile' = '--disable-silent-rules' '--enable-multiplatform=3Dno' = '--enable-cxx-runtime-hack=3Dno' '--enable-libtool-hack=3Dyes' = '--enable-texlive-build' '--with-x' '--enable-m-tx=3Dyes' = '--enable-pmx=3Dyes' '--enable-ps2eps=3Dyes' '--enable-texdoctk=3Dyes' = '--enable-tpic2pdftex=3Dyes' '--enable-vlna=3Dyes' '--enable-xindy=3Dno' = '--with-clisp-runtime=3Dsystem' '--enable-xpdfopen=3Dyes' = '--enable-afm2pl=3Dyes' '--enable-bibtex-x=3Dyes' '--enable-chktex=3Dyes' = '--enable-cjkutils=3Dyes' '--enable-detex=3Dyes' '--enable-devnag=3Dyes' = '--enable-dtl=3Dyes' '--enable-dvi2tty=3Dyes' '--enable-dvidvi=3Dyes' = '--enable-dviljk=3Dyes' '--enable-dvipng=3Dyes' '--enable-dvipos=3Dyes' = '--enable-dvisvgm=3Dyes' '--enable-gsftopk=3Dyes' '--enable-lacheck=3Dyes'= '--enable-lcdf-typetools=3Dyes' '--enable-makeindexk=3Dyes' = '--enable-makejvf=3Dyes' '--enable-mendexk=3Dyes' '--enable-ps2pkm=3Dyes' = '--enable-seetexk=3Dyes' '--enable-tex4htk=3Dyes' '--enable-ttf2pk2=3Dyes'= '--enable-ttfdump=3Dyes' '--enable-texlive=3Dyes' = '--with-system-harfbuzz=3Dno' '--with-system-graphite2=3Dno' = '--with-system-potrace=3Dno' '--cache-file=3D/dev/null' '--srcdir=3D.' > configure: loading site script /usr/ports/Templates/config.site > checking for a BSD-compatible install... (cached) /usr/bin/install > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p > checking for gawk... (cached) /usr/bin/awk > checking whether make sets $(MAKE)... yes > checking whether make supports nested variables... yes > checking for style of include used by make... GNU > checking for gcc... cc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables...=20 > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether cc accepts -g... yes > checking for cc option to accept ISO C89... none needed > checking whether cc understands -c and -o together... yes > checking dependency style of cc... gcc3 > checking whether to enable maintainer-specific portions of = Makefiles... no > checking whether the compiler accepts prototypes... yes > checking what warning flags to pass to the C compiler... -Wimplicit = -Wreturn-type -Wdeclaration-after-statement -Wno-unknown-pragmas > checking build system type... powerpc-portbld-freebsd10.1 > checking host system type... powerpc-portbld-freebsd10.1 > checking for gcc... (cached) cc > checking whether we are using the GNU C compiler... (cached) yes > checking whether cc accepts -g... (cached) yes > checking for cc option to accept ISO C89... (cached) none needed > checking whether cc understands -c and -o together... (cached) yes > checking dependency style of cc... (cached) gcc3 > checking dependency style of cc... gcc3 > checking for ranlib... ranlib > checking whether ln -s works... yes > checking for library containing sqrt... -lm > checking for library containing dlopen... none required > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > checking for _LARGEFILE_SOURCE value needed for large files... no > checking how to run the C preprocessor... cpp > configure: error: Sorry, can not preprocess > =3D=3D=3D configuring in luajit failed > Makefile:875: recipe for target 'recurse' failed > gmake[11]: *** [recurse] Error 1 > gmake[11]: Leaving directory = '/usr/ports/print/texlive-base/work/texlive-20140525-source/libs' > Makefile:455: recipe for target 'all-recursive' failed > gmake[10]: *** [all-recursive] Error 1 > gmake[10]: Leaving directory = '/usr/ports/print/texlive-base/work/texlive-20140525-source/libs' > Makefile:544: recipe for target 'all-recursive' failed > gmake[9]: *** [all-recursive] Error 1 > gmake[9]: Leaving directory = '/usr/ports/print/texlive-base/work/texlive-20140525-source' > *** Error code 1 >=20 > Stop. > make[8]: stopped in /usr/ports/print/texlive-base > *** Error code 1 >=20 > Stop. > make[7]: stopped in /usr/ports/print/texlive-texmf > *** Error code 1 >=20 > Stop. > make[6]: stopped in /usr/ports/print/tex-jadetex > *** Error code 1 >=20 > Stop. > make[5]: stopped in /usr/ports/textproc/docbook-utils > *** Error code 1 >=20 > Stop. > make[4]: stopped in /usr/ports/graphics/colord > *** Error code 1 >=20 > Stop. > make[3]: stopped in /usr/ports/graphics/colord > *** Error code 1 >=20 > Stop. > make[2]: stopped in /usr/ports/x11-toolkits/gtk30 > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/ports/x11-toolkits/gtk30 > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/x11/gnome-desktop Thanks! Rick= From owner-freebsd-ppc@FreeBSD.ORG Thu Feb 12 05:41:13 2015 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 4FE6C8D4 for ; Thu, 12 Feb 2015 05:41:13 +0000 (UTC) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2290AA15 for ; Thu, 12 Feb 2015 05:41:12 +0000 (UTC) Received: by pdbfp1 with SMTP id fp1so9545046pdb.9 for ; Wed, 11 Feb 2015 21:41:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Ye+3x8VKwfLfQrAt9oCVKsI75o9FrT3Dm5ZazUNIdkI=; b=LoC56G2OiazhN1bORmhz7x+Azl8EcX5Dk58fZo1J8XMsnrVQpf/BbHLHvvAXqPBVdq zWHaUIJA2ae4iduDPA5UMOxnwqyUdrpLSGFGZvSVygc6pqbGGdusZAmh7dtUsVm/BIYz AClj/I4TZ58PoFO0ZIiXQYGcCDKLRUZOtYpV83JCMoRt13mCjmRc3Tt7LrO8ZQuzTFXu jT7BcVPWJ293vhl9wjMAD5CxoBZFRy8XlUwl08tNS1wunxJXuKaYlD9V6LyQpvhKgyqv UpqKIwpZ0zF5JAc2AP+fVx4W5nfDyVwKVFIIZ57laLfYDYFI1cGVeqt7ML2tquJ3MQRp xdBA== X-Received: by 10.70.101.136 with SMTP id fg8mr3535154pdb.65.1423719666516; Wed, 11 Feb 2015 21:41:06 -0800 (PST) Received: from [192.168.1.69] (107-222-186-3.lightspeed.sntcca.sbcglobal.net. [107.222.186.3]) by mx.google.com with ESMTPSA id if10sm2497157pad.38.2015.02.11.21.41.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 21:41:05 -0800 (PST) Message-ID: <54DC3CEF.1070501@gmail.com> Date: Wed, 11 Feb 2015 21:41:03 -0800 From: Justin Hibbits User-Agent: Mozilla/5.0 (X11; FreeBSD powerpc; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-ppc@freebsd.org Subject: Re: luajit doesn't compile on powerpc (among others) but is required to install gnome-desktop... References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Thu, 12 Feb 2015 05:41:13 -0000 Hi Rick On 02/11/15 18:46, Rick Thomas wrote: > Continuing to try to install gnome-desktop on my Apple PowerMac G4 “Quicksilver” with FreeBSD 10.1… > > I get the following: > >> root@grey:/root # cd /usr/ports/lang/luajit >> >> root@grey:/usr/ports/lang/luajit # make install >> ===> luajit-2.0.3 is marked as broken: Does not compile on ia64, powerpc, or sparc64. >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/ports/lang/luajit > Any suggestions? See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193289 . The same fix for powerpc64 could be applied for powerpc. However, luajit has been ported to powerpc (32-bit), the developers have no plans to port to 64-bit. Getting it ported for FreeBSD should be relatively straight forward, if it needs any work at all. - Justin From owner-freebsd-ppc@FreeBSD.ORG Thu Feb 12 15:39:34 2015 Return-Path: Delivered-To: freebsd-powerpc@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 7AC51CBC for ; Thu, 12 Feb 2015 15:39:34 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 6084B187 for ; Thu, 12 Feb 2015 15:39:34 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t1CFdY5J022625 for ; Thu, 12 Feb 2015 15:39:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-powerpc@FreeBSD.org Subject: [Bug 194183] [arm] math/R missing libquadmath to compile Date: Thu, 12 Feb 2015 15:39:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bf@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 12 Feb 2015 15:39:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194183 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed --- Comment #9 from Sean Bruno --- oh, math/R depend tree requires a functional lang/gcc This is not available on mips/mips64 at this time. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-ppc@FreeBSD.ORG Thu Feb 12 22:36:58 2015 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 0D0ADBB6 for ; Thu, 12 Feb 2015 22:36:58 +0000 (UTC) Received: from sasl.smtp.pobox.com (pb-sasl1.int.icgroup.com [208.72.237.25]) by mx1.freebsd.org (Postfix) with ESMTP id CEBBC81D for ; Thu, 12 Feb 2015 22:36:57 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 5E5943733D; Thu, 12 Feb 2015 17:36:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=content-type :mime-version:subject:from:date:cc:content-transfer-encoding :message-id:to; s=sasl; bh=HLSnRd2iuOzc4q5OniJoh3m4gy0=; b=OO79W z2sl4J7BRcaqjzMNZPHwIUrb7iRgPRBGTtgl/tMk/Bt3mcfI3MW+dB8m1mp1i/n0 KIh90ReeZo7rN5KbvfJqyOD0oup0oww61La9LvKC4CyzqhtnWxzxM8/x8hYipnBq sru2IANTu8QgszVWfM8ruFkt2QZYwrW0DyeGwg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=content-type :mime-version:subject:from:date:cc:content-transfer-encoding :message-id:to; q=dns; s=sasl; b=e9P6c62tKcWL+nTHPUAnMPLWbdCBR8t a7ZscbfUYB+DZqzfagzqUsllPTYDlT4MtR2TZPl2Sw3svu6jN8/Mmh0Ohkp1GKsh GvI4cdjfPwzzyVZRZ9cqIzz+sTStzEgsiMe3NhqCt44ghk6BC6+d6H2Od07F/GbB 9iMnN25t0cR4= Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 524E13733B; Thu, 12 Feb 2015 17:36:56 -0500 (EST) Received: from almini.rcthomas.org (unknown [208.53.120.31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id 587C33733A; Thu, 12 Feb 2015 17:36:55 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: System clock falls behind quickly on Mac mini G4 From: Rick Thomas Date: Thu, 12 Feb 2015 14:36:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9BE10E2F-D281-4E4F-9575-1A41F61AA068@pobox.com> To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.1878.6) X-Pobox-Relay-ID: A603BDB6-B307-11E4-8A8A-8FDD009B7A5A-02150157!pb-sasl1.pobox.com Cc: danfe@nsu.ru 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: Thu, 12 Feb 2015 22:36:58 -0000 Hi! Did you ever get a solution for this? I=92m having the same problem on = a PowerMac G4 =93quicksilver=94 machine. Thanks! Rick > On Tue, Apr 08, 2014 at 10:41:44AM -0400, John Baldwin wrote: > > It wouldn=92t be tsc_freq on a powerpc box. You'd need to see what = your > > time counter is and what frequency it is using (kern.timecounter = nodes) > > and see if that is adjustable. >=20 > Yup, sorry; I forgot that our TSC maps to actual x86 Time Stamp = Counter, > not being some aggregated MI relatively high-precision time keeping = thing. >=20 > Does not look I can do much about it though: >=20 > $ sysctl kern.timecounter > kern.timecounter.fast_gettime: 1 > kern.timecounter.tick: 2 > kern.timecounter.choice: timebase(0) dummy(-1000000) > kern.timecounter.hardware: timebase > kern.timecounter.alloweddeviation: 5 > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.timebase.mask: 4294967295 > kern.timecounter.tc.timebase.counter: 3224483187 > kern.timecounter.tc.timebase.frequency: 41620907 > kern.timecounter.tc.timebase.quality: 0 >=20 > ./danfe From owner-freebsd-ppc@FreeBSD.ORG Fri Feb 13 07:06:12 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1033) id D900EB04; Fri, 13 Feb 2015 07:06:12 +0000 (UTC) Date: Fri, 13 Feb 2015 07:06:12 +0000 From: Alexey Dokuchaev To: Rick Thomas Subject: Re: System clock falls behind quickly on Mac mini G4 Message-ID: <20150213070612.GA48146@FreeBSD.org> References: <9BE10E2F-D281-4E4F-9575-1A41F61AA068@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BE10E2F-D281-4E4F-9575-1A41F61AA068@pobox.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: danfe@nsu.ru, 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: Fri, 13 Feb 2015 07:06:12 -0000 On Thu, Feb 12, 2015 at 02:36:52PM -0800, Rick Thomas wrote: > Did you ever get a solution for this? I'm having the same problem on a > PowerMac G4 "quicksilver" machine. Nope, sorry; the clock still runs away, but since ntpd(8) doing a job good enough to keep it sane I never had strong motivation to dig the root cause. ./danfe From owner-freebsd-ppc@FreeBSD.ORG Fri Feb 13 08:08:42 2015 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 9D6DA622; Fri, 13 Feb 2015 08:08:42 +0000 (UTC) Received: from sasl.smtp.pobox.com (pb-sasl1.int.icgroup.com [208.72.237.25]) by mx1.freebsd.org (Postfix) with ESMTP id 68B95A54; Fri, 13 Feb 2015 08:08:41 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 0D81038C24; Fri, 13 Feb 2015 03:08:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=sasl; bh= 02VyBiboBi/JJWs+PvNIewE5we4=; b=FWksYrDAazCVAj0Tf0vGh9WuBsC5DpYY U9VjWK3xyQ/6OaxqhhhWNXx4xzQIX8jnrNt1PkIt8cyCyJs83X+GttMq9A1KyRqk vi+ZSlLfWkDyzBcesf8FSxEaEA4ql7b47ztkY6mjp8rWSLEwHJqFIzQNlgMnS1KY sN6ctY0omXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= sasl; b=JbG4HgEBUOvB7UF1a83bAAzNntgILBj8t2WGfgBu0e9HK3KDhLY7xwXE HclnPQDoTbktB5GREHjeq9Yv8Mdj76ZumTiyJZYuUKtkfVfH0r/ftvPIZ0k0Ii8X 3q7NpPv6m4DZs45BCoihWqBB2z0PcCLZ/FxfwtnrMcVZEcGUuLQ= Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 027EA38C23; Fri, 13 Feb 2015 03:08:35 -0500 (EST) Received: from almini.rcthomas.org (unknown [208.53.120.31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id 8784D38C22; Fri, 13 Feb 2015 03:08:33 -0500 (EST) Subject: Re: System clock falls behind quickly on Mac mini G4 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rick Thomas In-Reply-To: <20150213070612.GA48146@FreeBSD.org> Date: Fri, 13 Feb 2015 00:08:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <06EFEE70-4BB4-41D2-BC30-E5F9F7CA1622@pobox.com> References: <9BE10E2F-D281-4E4F-9575-1A41F61AA068@pobox.com> <20150213070612.GA48146@FreeBSD.org> To: Alexey Dokuchaev X-Mailer: Apple Mail (2.1878.6) X-Pobox-Relay-ID: 816F20E4-B357-11E4-BB68-8FDD009B7A5A-02150157!pb-sasl1.pobox.com Cc: danfe@nsu.ru, 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: Fri, 13 Feb 2015 08:08:42 -0000 On Feb 12, 2015, at 11:06 PM, Alexey Dokuchaev = wrote: > On Thu, Feb 12, 2015 at 02:36:52PM -0800, Rick Thomas wrote: >> Did you ever get a solution for this? I'm having the same problem on = a >> PowerMac G4 "quicksilver" machine. >=20 > Nope, sorry; the clock still runs away, but since ntpd(8) doing a job = good > enough to keep it sane I never had strong motivation to dig the root = cause. >=20 > ./danfe Thanks! It helps to know that it=92s still an unsolved problem. I=92m = determined to track it down. I=92ll report back to the freebsd-ppc list = when I get it solved. I=92m currently working on using sysctl to patch = the assumed frequency of the clock. Rick From owner-freebsd-ppc@FreeBSD.ORG Fri Feb 13 21:38:02 2015 Return-Path: Delivered-To: freebsd-powerpc@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 5994225A for ; Fri, 13 Feb 2015 21:38:02 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 3F359E05 for ; Fri, 13 Feb 2015 21:38:02 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t1DLc2Nb007419 for ; Fri, 13 Feb 2015 21:38:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-powerpc@FreeBSD.org Subject: [Bug 194183] [arm] math/R missing libquadmath to compile Date: Fri, 13 Feb 2015 21:38:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jhibbits@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bf@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 13 Feb 2015 21:38:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194183 Justin Hibbits changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhibbits@FreeBSD.org --- Comment #10 from Justin Hibbits --- (In reply to Sean Bruno from comment #8) This should also be done for powerpc and powerpc64. I can open a new bug if you'd like. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-ppc@FreeBSD.ORG Fri Feb 13 21:42:17 2015 Return-Path: Delivered-To: freebsd-powerpc@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 80FD54EF for ; Fri, 13 Feb 2015 21:42:17 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 66ECDEBD for ; Fri, 13 Feb 2015 21:42:17 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t1DLgHA1014459 for ; Fri, 13 Feb 2015 21:42:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-powerpc@FreeBSD.org Subject: [Bug 194183] [arm] math/R missing libquadmath to compile Date: Fri, 13 Feb 2015 21:42:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bf@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Fri, 13 Feb 2015 21:42:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194183 --- Comment #11 from Sean Bruno --- (In reply to Justin Hibbits from comment #10) powerpc/powerpc64 done in r378945 -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-ppc@FreeBSD.ORG Sat Feb 14 09:53:44 2015 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 1755779D for ; Sat, 14 Feb 2015 09:53:44 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 C675BBB0 for ; Sat, 14 Feb 2015 09:53:43 +0000 (UTC) Received: (qmail 14679 invoked from network); 14 Feb 2015 09:53:36 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 14 Feb 2015 09:53:36 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sat, 14 Feb 2015 04:53:36 -0500 (EST) Received: (qmail 10220 invoked from network); 14 Feb 2015 09:53:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Feb 2015 09:53:36 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id B244B1C43A4 for ; Sat, 14 Feb 2015 01:53:34 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: PowerMac G5 powerpc64: new context where repeatedly booting varies between failing and working Message-Id: <7CA43EE3-8C11-4FBD-9F8A-42DF08B82362@dsl-only.net> Date: Sat, 14 Feb 2015 01:53:33 -0800 To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) 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: Sat, 14 Feb 2015 09:53:44 -0000 FreeBSD context: PowerMac G5 Quad-Core with 16GB RAM. root@FBSDG5M1:/usr/src # freebsd-version -ku ; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG5M1 10.1-STABLE FreeBSD 10.1-STABLE #10 r278443M: Fri Feb = 13 03:26:27 PST 2015 = root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64vtsc powerpc Other configuration/context details for /boot/kernel10.1S/kernel are = given late in this message. But I will here mention the use of: options DDB options GDB options VERBOSE_SYSINIT options BOOTVERBOSE=3D1 options BOOTHOWTO=3DRB_VERBOSE I've got a new context where repeatedly booting via power-off then = power-on varies between failing and working, always failing in the same = way/place when it does. Here are 3 addresses (&...: ...) from a successful boot of kernel10.1S, = where the first one will be different for the failing boots (this is = from dmesg -a): authnone_init(0)... &authnone_private: 0xe313a8, &_null_auth: = 0xe31608, &authnone_ops: 0xc31f80 done. where the extra output is from the added printf in: static void authnone_init(void *dummy) { struct authnone_private *ap =3D &authnone_private; XDR xdrs; ap->no_client.ah_cred =3D ap->no_client.ah_verf =3D _null_auth; ap->no_client.ah_ops =3D &authnone_ops; printf(" &authnone_private: %p, &_null_auth: %p, &authnone_ops: %p ", = ap, &_null_auth, &authnone_ops); xdrmem_create(&xdrs, ap->mclient, MAX_MARSHAL_SIZE, XDR_ENCODE); xdr_opaque_auth(&xdrs, &ap->no_client.ah_cred); xdr_opaque_auth(&xdrs, &ap->no_client.ah_verf); ap->mcnt =3D XDR_GETPOS(&xdrs); XDR_DESTROY(&xdrs); } SYSINIT(authnone_init, SI_SUB_KMEM, SI_ORDER_ANY, authnone_init, NULL); The authnone_init code for through its first store into ap->... is: 00000000007a3ea4 <.authnone_init> mflr r0 00000000007a3ea8 <.authnone_init+0x4> std r29,-24(r1) 00000000007a3eac <.authnone_init+0x8> std r30,-16(r1) 00000000007a3eb0 <.authnone_init+0xc> std r31,-8(r1) 00000000007a3eb4 <.authnone_init+0x10> std r0,16(r1) 00000000007a3eb8 <.authnone_init+0x14> stdu r1,-192(r1) 00000000007a3ebc <.authnone_init+0x18> mr r31,r1 00000000007a3ec0 <.authnone_init+0x1c> ld r29,304(r2) 00000000007a3ec4 <.authnone_init+0x20> ld r9,312(r2) 00000000007a3ec8 <.authnone_init+0x24> ld r0,0(r9) 00000000007a3ecc <.authnone_init+0x28> ld r11,8(r9) 00000000007a3ed0 <.authnone_init+0x2c> ld r9,16(r9) 00000000007a3ed4 <.authnone_init+0x30> std r0,24(r29) When the boots fail they fail on that last std: std r0,24(r29) , doing = so based on r2: 0xd2da20 r29: 0x2400002200e313a8 bad virtual address: 0x2400002200e313c0 (These are from a boot-crash time register display, so hand copied off = screen as it is too soon for interaction with DDB. I've got a default = ddb script in place that does the display.) When it boots okay r29 =3D 0x00e313a8 and the address accessed is = 0x00e313c0 instead: see the first address that I started with above (for = &authnone_private). In other words: The difference is the upper half of r29. I've no = evidence that r2 is corrupt for failing boots for this code. So either 304(r2) accesses different values from one time to the next = for booting or the r29 register is corrupted somehow between 00000000007a3ec0 <.authnone_init+0x1c> ld r29,304(r2) and 00000000007a3ed4 <.authnone_init+0x30> std r0,24(r29) (such as an interrupt not restoring the 64bit-ABI's register value = fully). At this point I've no clue if variability in the TOC contents that = 304(r2) references makes any sense or not. I've yet to figure out how it = is established. More FreeBSD configuration details: 10.1-STABLE's buildworld kernel and installworld were all done from the = PowerMac G5 itself. root@FBSDG5M1:/usr/src # more sys/powerpc/conf/GENERIC64 GENERIC64 GENERIC64vtsc =20 root@FBSDG5M1:/usr/src # more sys/powerpc/conf/GENERIC64vtsc=20 include GENERIC64 ident GENERIC64vtsc nooptions PS3 #Sony Playstation 3 = HACK!!! to allow sc options DDB # HACK!!! to dump early crash = info (but 11.0-CURRENT already has it) options GDB # HACK!!! ... options VERBOSE_SYSINIT options BOOTVERBOSE=3D1 options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP #options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting device sc #device kbdmux # HACK: already listed by vt options SC_OFWFB # OFW frame buffer options SC_DFLT_FONT # compile font in makeoptions SC_DFLT_FONT=3Dcp437 # Disable extra checking typically used for FreeBSD 11.0-CURRENT: nooptions DEADLKRES #Enable the deadlock resolver nooptions INVARIANTS #Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT #Extra sanity checks of internal = structures, required by INVARIANTS nooptions WITNESS #Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN #Don't run witness on spinlocks = for speed nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones root@FBSDG5M1:/usr/src # svnlite status ? .snap M sys/ddb/db_main.c M sys/ddb/db_script.c M sys/powerpc/conf ? sys/powerpc/conf/GENERIC64vtsc M sys/powerpc/ofw/ofw_machdep.c M sys/powerpc/ofw/ofwcall64.S M sys/powerpc/powermac/powermac_thermal.c M sys/rpc/auth_none.c root@FBSDG5M1:/usr/src # more /boot/loader.conf=20 #kernel=3D"kernel" #kernel=3D"kernel10.1RE" kernel=3D"kernel10.1S" #kernel=3D"kernel11C" verbose_loading=3D"YES" kern.vty=3Dvt root@FBSDG5M1:/usr/src # more /etc/make.conf=20 WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D MALLOC_PRODUCTION=3D root@FBSDG5M1:/usr/src # more /etc/src.conf CFLAGS+=3D-DELF_VERBOSE #WITH_DEBUG_FILES=3D #WITHOUT_CLANG=3D Other than powermac_thermal.c (from Justin H.) the source changes are = for investigation of various early-boot problems for PowerMac G5's. The = PowerMac G5 that powermac_thermal.c was put in place to experiment with = is no longer around but I've not yet removed the powermac_thermal.c = update from my environment. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sat Feb 14 22:21:55 2015 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 787966C5 for ; Sat, 14 Feb 2015 22:21:55 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 31744E32 for ; Sat, 14 Feb 2015 22:21:54 +0000 (UTC) Received: (qmail 13261 invoked from network); 14 Feb 2015 22:21:53 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Feb 2015 22:21:53 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sat, 14 Feb 2015 17:21:53 -0500 (EST) Received: (qmail 23581 invoked from network); 14 Feb 2015 22:21:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Feb 2015 22:21:52 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id CAFADB1E002 for ; Sat, 14 Feb 2015 14:21:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: PowerMac G5 powerpc64: new context where repeatedly booting varies between failing and working From: Mark Millard In-Reply-To: <7CA43EE3-8C11-4FBD-9F8A-42DF08B82362@dsl-only.net> Date: Sat, 14 Feb 2015 14:21:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7CA43EE3-8C11-4FBD-9F8A-42DF08B82362@dsl-only.net> To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.2070.6) 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: Sat, 14 Feb 2015 22:21:55 -0000 I've been able to show that the TOC entry that authnone_init accesses is = messed up and it is so from very early on. I took advantage of sys/rpc/auth_none.c exposing the static variable's = address calculation result, in fact the same one that the crash happened = for: AUTH * authnone_create() { struct authnone_private *ap =3D &authnone_private; return (&ap->no_client); } The no_client even happens to be the first field of the struct pointed = to by ap. So I put calls of that routine where it would periodically monitor the = calculation during the early part of booting: root@FBSDG5M1:/usr/src # svnlite diff sys/kern/init_main.c=20 Index: sys/kern/init_main.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/init_main.c (revision 278443) +++ sys/kern/init_main.c (working copy) @@ -91,6 +91,11 @@ #include #include =20 +#if defined(VERBOSE_SYSINIT) +/* HACK! */ +extern void* authnone_create(void); +#endif + void mi_startup(void); /* Should be elsewhere = */ =20 /* Components of the first process -- never freed. */ @@ -282,7 +287,9 @@ =20 #if defined(VERBOSE_SYSINIT) if (verbose) +{printf(" authnone_private address generation check: %p ", = authnone_create()); printf("done.\n"); +} #endif So when it boots successfully it reports messages like: malloc_init(&M_JFREEFRAG)... authnone_private address generation = check: 0xe313a8 done. When the boots fails the very first such message of that form shows the = 0x2400002200e313a8 value, as do all the later ones. When the boot works = it always shows 0xe313a8. [I have since shortened the text with: printf(" &authnone_private: %p ", authnone_create());] It would appear that the TOC entry generation/update is the source of = the variations in value that are observed that can lead to a crash. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Feb-14, at 01:53 AM, Mark Millard = wrote: FreeBSD context: PowerMac G5 Quad-Core with 16GB RAM. root@FBSDG5M1:/usr/src # freebsd-version -ku ; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG5M1 10.1-STABLE FreeBSD 10.1-STABLE #10 r278443M: Fri Feb = 13 03:26:27 PST 2015 = root@FBSDG5M1:/usr/obj/usr/src/sys/GENERIC64vtsc powerpc Other configuration/context details for /boot/kernel10.1S/kernel are = given late in this message. But I will here mention the use of: options DDB options GDB options VERBOSE_SYSINIT options BOOTVERBOSE=3D1 options BOOTHOWTO=3DRB_VERBOSE I've got a new context where repeatedly booting via power-off then = power-on varies between failing and working, always failing in the same = way/place when it does. Here are 3 addresses (&...: ...) from a successful boot of kernel10.1S, = where the first one will be different for the failing boots (this is = from dmesg -a): authnone_init(0)... &authnone_private: 0xe313a8, &_null_auth: = 0xe31608, &authnone_ops: 0xc31f80 done. where the extra output is from the added printf in: static void authnone_init(void *dummy) { struct authnone_private *ap =3D &authnone_private; XDR xdrs; ap->no_client.ah_cred =3D ap->no_client.ah_verf =3D _null_auth; ap->no_client.ah_ops =3D &authnone_ops; printf(" &authnone_private: %p, &_null_auth: %p, &authnone_ops: %p ", = ap, &_null_auth, &authnone_ops); xdrmem_create(&xdrs, ap->mclient, MAX_MARSHAL_SIZE, XDR_ENCODE); xdr_opaque_auth(&xdrs, &ap->no_client.ah_cred); xdr_opaque_auth(&xdrs, &ap->no_client.ah_verf); ap->mcnt =3D XDR_GETPOS(&xdrs); XDR_DESTROY(&xdrs); } SYSINIT(authnone_init, SI_SUB_KMEM, SI_ORDER_ANY, authnone_init, NULL); The authnone_init code for through its first store into ap->... is: 00000000007a3ea4 <.authnone_init> mflr r0 00000000007a3ea8 <.authnone_init+0x4> std r29,-24(r1) 00000000007a3eac <.authnone_init+0x8> std r30,-16(r1) 00000000007a3eb0 <.authnone_init+0xc> std r31,-8(r1) 00000000007a3eb4 <.authnone_init+0x10> std r0,16(r1) 00000000007a3eb8 <.authnone_init+0x14> stdu r1,-192(r1) 00000000007a3ebc <.authnone_init+0x18> mr r31,r1 00000000007a3ec0 <.authnone_init+0x1c> ld r29,304(r2) 00000000007a3ec4 <.authnone_init+0x20> ld r9,312(r2) 00000000007a3ec8 <.authnone_init+0x24> ld r0,0(r9) 00000000007a3ecc <.authnone_init+0x28> ld r11,8(r9) 00000000007a3ed0 <.authnone_init+0x2c> ld r9,16(r9) 00000000007a3ed4 <.authnone_init+0x30> std r0,24(r29) When the boots fail they fail on that last std: std r0,24(r29) , doing = so based on r2: 0xd2da20 r29: 0x2400002200e313a8 bad virtual address: 0x2400002200e313c0 (These are from a boot-crash time register display, so hand copied off = screen as it is too soon for interaction with DDB. I've got a default = ddb script in place that does the display.) When it boots okay r29 =3D 0x00e313a8 and the address accessed is = 0x00e313c0 instead: see the first address that I started with above (for = &authnone_private). In other words: The difference is the upper half of r29. I've no = evidence that r2 is corrupt for failing boots for this code. So either 304(r2) accesses different values from one time to the next = for booting or the r29 register is corrupted somehow between 00000000007a3ec0 <.authnone_init+0x1c> ld r29,304(r2) and 00000000007a3ed4 <.authnone_init+0x30> std r0,24(r29) (such as an interrupt not restoring the 64bit-ABI's register value = fully). At this point I've no clue if variability in the TOC contents that = 304(r2) references makes any sense or not. I've yet to figure out how it = is established. More FreeBSD configuration details: 10.1-STABLE's buildworld kernel and installworld were all done from the = PowerMac G5 itself. root@FBSDG5M1:/usr/src # more sys/powerpc/conf/GENERIC64 GENERIC64 GENERIC64vtsc =20 root@FBSDG5M1:/usr/src # more sys/powerpc/conf/GENERIC64vtsc=20 include GENERIC64 ident GENERIC64vtsc nooptions PS3 #Sony Playstation 3 = HACK!!! to allow sc options DDB # HACK!!! to dump early crash = info (but 11.0-CURRENT already has it) options GDB # HACK!!! ... options VERBOSE_SYSINIT options BOOTVERBOSE=3D1 options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP #options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting device sc #device kbdmux # HACK: already listed by vt options SC_OFWFB # OFW frame buffer options SC_DFLT_FONT # compile font in makeoptions SC_DFLT_FONT=3Dcp437 # Disable extra checking typically used for FreeBSD 11.0-CURRENT: nooptions DEADLKRES #Enable the deadlock resolver nooptions INVARIANTS #Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT #Extra sanity checks of internal = structures, required by INVARIANTS nooptions WITNESS #Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN #Don't run witness on spinlocks = for speed nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones root@FBSDG5M1:/usr/src # svnlite status ? .snap M sys/ddb/db_main.c M sys/ddb/db_script.c M sys/powerpc/conf ? sys/powerpc/conf/GENERIC64vtsc M sys/powerpc/ofw/ofw_machdep.c M sys/powerpc/ofw/ofwcall64.S M sys/powerpc/powermac/powermac_thermal.c M sys/rpc/auth_none.c root@FBSDG5M1:/usr/src # more /boot/loader.conf=20 #kernel=3D"kernel" #kernel=3D"kernel10.1RE" kernel=3D"kernel10.1S" #kernel=3D"kernel11C" verbose_loading=3D"YES" kern.vty=3Dvt root@FBSDG5M1:/usr/src # more /etc/make.conf=20 WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D MALLOC_PRODUCTION=3D root@FBSDG5M1:/usr/src # more /etc/src.conf CFLAGS+=3D-DELF_VERBOSE #WITH_DEBUG_FILES=3D #WITHOUT_CLANG=3D Other than powermac_thermal.c (from Justin H.) the source changes are = for investigation of various early-boot problems for PowerMac G5's. The = PowerMac G5 that powermac_thermal.c was put in place to experiment with = is no longer around but I've not yet removed the powermac_thermal.c = update from my environment. =3D=3D=3D Mark Millard markmi at dsl-only.net