From owner-freebsd-ppc@freebsd.org Tue Dec 22 09:09:21 2020 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 068864B84EB for ; Tue, 22 Dec 2020 09:09:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-19.consmr.mail.gq1.yahoo.com (sonic313-19.consmr.mail.gq1.yahoo.com [98.137.65.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D0Vrw5DlYz3kK6 for ; Tue, 22 Dec 2020 09:09:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1608628158; bh=U2qqUNtjQaZ6tlo/83q/7mKprcg7vxToRcUF32ngzDI=; h=Subject:From:Date:To:From:Subject; b=Rjk8kDcioIz5pG/Se6xEd2B9GBBxWwb2kK3EAI0v80uyQ6mo9A7lwhjHALEiNVVM+6K4vUX9yPf2dJQwCh5nKF7kgKRChxczaYHDVZg0IHVUKd46ErjRgLRaMGDFSdlQqUoLRjGLnU3DOONJO0vfVKFcSr0N74jUyjjkgLtxQi9FZCAVK/jOTu+oFXNl8kipJ0BkhgjkLs4JjdcRGphQvWODN334RFcgXwhdkjlk28VEoA2sCO1QnhCCHLK5HCCpJmejMk2boFFIScCoMyC8TmhpQtT2df5qXOG7LqYIo5DQ2as3jTVQvlBIqir/EbYqfnexvSB+1bVHxl5b8nlkmw== X-YMail-OSG: EwyCb6YVM1ke8ZtqrV3YPqn0E_.YKukx2ghwwbbNAAzOMhwI1N8NXWzTHtP7SM5 KvR_1MrXcwjIFWK.HKeVYSuCux.9ugDcUmvU8ip24badfapfKMMthYeSJ4DByoZXx.yYl4.DzIjV Zl49QK1e8XMVPVAO8wqHgKp1kmti8vzblTtAGdqX6rCT1wwC6UzFIo5qgHAoQ8_nT.U.qSVtsM8d r3EOnJ4zr7A8hJcApQV9AfRhbEIIlhdKcDuKkU1C0KKZ_Y4efF355wR5JWoZCWBTmCpDqy7nCYFp yehKYKw5uUJhdQPNkqLZ6niPfwIRkXOiwrls0HGxr1O0qntEVSihDMMn8E_HDb_YgX1xgraC1cuS x1pS1630IWYdMoRQ7j2oT33j_6nIOjpQJ8AgE.9jBMht0hxVKonqK_JiI8HDhvlG7VR2PpgcMxy5 Uil07y0aR7OgjjtExECRu.FD18q3RVIVoVI65R7lVuO.Xn0TOKNjrzmB.VaLEp2AawGyUiJUaiWv 8tDOBvHBDJPYkACvzVdSPwGAO1XUhJjgRVhoeq0ra0oMaztanULtb9ls_L89BVWRpvotIVt5HaTi Vy7SYDCdv1Mc5Fd4B1dBQjU9HK5JJzN5IxFubPOLSNNpOsR4xKbeutAGrgHPlw97diHBdwbFvcO_ 3xM3QBQdGpnolZ8OiZX585qIotxhCad8xKVbwhIQemkerQUgkoMXoXX0M5PHxPFQzGoS88A7q5Cn rkY6pkgwKu1Os48fBIS04ZN.z0ou_yxW42c2r5pmixhZDudVB.nHHc9DqRcJqDkgS9v1CGpoCSeP Y9ZK34nWV9JInAZHVxFmCKXcrmVRTcp_gNYxcRupTRVGn0tawkN6JPrpRVS3Gw4Fy4nYBVw1SSgM E4Ygq_TsNbZlgH4pb9IcjpeFFtXhgi2mM3Evq.6biOSyPutfDKYc.vD5yNF3E_49R.A8_Czj9WBl V_H0bn3iS8TffUVaCVTIsiXcDs8p_jNdm.t13FmUZZv4hJP2hG5VGQENLIokrYYh.gCACQpqWU_h A2hfPb3LqRpNZt4DJIq8_ZcQt5xTuwqqn2V8C1uA7HcedI1xODzUdCKCjGNuPMqWVIuKxh4pQlFO RywZTUXMSJvdQQCHf_k5ixHRxlAJMUbnCa859TXtsLJzAm6VlmFKm04601zMm2d4ajRKOfG5dkjR jUeWO3iOqif9uXR.XjSy4M9oKBNBwggNtY1H8pr33s0uWJosv51MrQN_hcqcIor4IocI6MioIg0l obB1hKmD9OBKh3_UhHCYPWu8cGKjx.1RSTTBkn7kSmDe94C47y5F9pjeCnMeGPssSMUvqqmt0fo1 87mL6jNB8grqR_WPfVfupUkzgvxdGkNiTrk_jDld4BEI9gZD3HWsQVoCtLeEv.Wkmc5ZXfMXuMDe beS1khgNWb8.B4iZapyRFSugaHE1OnpX_r1gZI84L6slJozh4b9m.YvwFh1ki2D9J4qpoDezWbhU kzrbv0c3strbYwSY.3da9whSIDmeGzXEAnFEzlPqu2ZCulcrwGQKidcEVfkU_0czr4XqoI3Eajeu GBmY0SrZhMoj70cOLJZlBInLUv.4rZA.CcvIhBx7dwuIg5U3lsbHKmhD9suvOOCh3S82Rx1XM1_b NRFd0iuZaYdg9NtF3EkKdl6rb.9jWmtshhcsHJzCyxI1TfkutmiidKYhZ91kEsMXNPlxxTD7q6Vr UGzzE2EWQwx1MyKAH8zOkcIs7upq9flehn6S0oAhq1RDmBqHXKTGNnSax3wrgxCidp6opnpRvUbL KXfGwklnCzNfkOJkh_nw7naDfpxZqO1rxjmuiHzZ.0RyjmoC2H4NvfqObxjqCmwQqu_rn5ieiADw zLFx1IkY5Qbn825UKgqg0zoRgbIBY0_7Ja9tGVID09UhGJ.jzNXT5hCZiW3ecoJIARtJNjxiUMIp OaJlqiACo9Zo9AXv6ZFM2cSSArkJHLlLYWpyfC4FG1Mvs_QMKwaOy53eltzlg3dcim0XKGKSJN5h c7c8LmkOUVYmxKBSIqyaXPL9BfDJqFVKKyxpukOV62gTfoI1bT5cK8_jLVjjF.jMm3O1GVr6t2Ee AJEfDQVa_jV0PbFOIcADLCQqIFq_9uGx.lV3d4CsmFAG0XayBi1sIXptEUsCJ4lxHJdAA3L1B9Gf EU5DP5bQUbrdNGvwJYcOuXZ6Inp4gdTwq9RH2nHN_uq20.lm.esAV02HlFgQpV2OFqxY7sKf9v2q PwsBpFnw9Pb0rIk0mCiaH65k6O_i3YII0aZhA4USTgl5VpPmopZFXlWgTA3pW2PSAnDET9R6g9Bi Rb6lj83Gf3vl0mlLTTVylYkrywlBrZUESNyVlBncKu2HaW0BX8UbMVDAMjsxLX1GRccIJ5ZK9MRZ _Iu2WtESDEa2D8Qqry2ZW5lgyI1op7d6PuqlH_9FtsXu_.8SktyPcgwkLWFP1l_r7.4iqqO3tCrd K13awna3cf54PEEBi6KLxCwqx9k.oPS4EMEe6p4Ikbb86h8uBGsEDWfbh89l.S26HXN54p1j2lDV U4RRIrbNE4SQNoB_S5Ut0fY0e9drsO2KcZkf3F1WGro2tS8SUkGVjz.5YentPKQwVJnU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 22 Dec 2020 09:09:18 +0000 Received: by smtp410.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1bc0106dc8ab1ee56ac76bcf7422dfa8; Tue, 22 Dec 2020 09:09:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Subject: Re: Old PowerMac G5 2-socket/2-cores-each: head -r368820 kernel reports: bus_dmamem_alloc failed to align memory properly From: Mark Millard In-Reply-To: <66ce8494-204b-4b8b-a043-94ba00509f41@www.fastmail.com> Date: Tue, 22 Dec 2020 01:09:11 -0800 Cc: FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <7870C7CB-6104-4A63-AA86-4981913FA48D@yahoo.com> References: <40dead6f-2a69-cf74-0a23-cde56dd90510@blastwave.org> <53f15d43-62c3-e12c-f8db-ede6a30e4e95@blastwave.org> <46726BE0-00FF-4DE7-835B-C7B04F3B0693@yahoo.com> <04727338-1ecb-4a94-c8e9-dcef7abd1513@blastwave.org> <66ce8494-204b-4b8b-a043-94ba00509f41@www.fastmail.com> To: Brandon Bergren X-Mailer: Apple Mail (2.3654.20.0.2.21) X-Rspamd-Queue-Id: 4D0Vrw5DlYz3kK6 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 09:09:21 -0000 On 2020-Dec-21, at 21:11, Brandon Bergren = wrote: > On Mon, Dec 21, 2020, at 10:25 PM, Dennis Clarke via freebsd-ppc = wrote: >> On 12/21/20 11:03 PM, Mark Millard wrote: >>=20 >>> As far as I know, 32-bit powerpc for old PowerMacs still has the = kernel >>> gradually zeroing out user-space pages, even for = single-socket/single-core >>> 32-bit PowerMacs. So I run 32-bit via a chroot on a 64-bit system: = the >>> 64-bit kernel does not have this specific problem. (I seem to = remember >>> that there was a different boot failure last I tried 32-bit, but I = do not >>> remember any detail at this time.) >=20 > This is the bridge mode bug that we haven't figured out yet. It's = specific to the G5 running a 32 bit kernel. The problem doesn't manifest = on actual 32-bit MMUs. I combined more than one thing in that paragraph, making things hard to follow in the reply. I'll provide reminders of context for both things. Neither matches with a G5 being in use. For the "seem to remember" part of my text . . . Wrong problem and wrong machine context, I'm afraid. Back on Sept-22 I reported for the 2-socket G4s (typos preserved): Subject: head -r365932 for 320bit powerpc unable to boot 2-socket = PowerMac G4 QUOTE I attempted to boot an update from head -r365590 to head -r365932 and it dies just after: Kernel entry at 0x100620 via: Invalid memory access at %SRR0: 0000ffff %SRR1: 00ffffff END QUOTE (I did report at the time that the G5 gets much further along than the above when that same media (and content) is used to try to boot the G5. But the report was about the G4 context.) As for the "gradually zeroing out user-space pages" . . . For this I was referencing there being no G3/G4 code analogous to the 64 bit code clearing of PGA_EXECUTABLE (and possibly other issues too), nothing like the: vm_page_aflag_clear(????,PGA_WRITEABLE | PGA_EXECUTABLE) in the 64 bit code. I've demonstrated and reported the problem that results on each of: A) A G3 PowerMac (the only one I have access to) B) A single-socket/single thread G4 PowerMac C) Two 2-Socket G4 PowerMacs (but of the same type, the only such type that I've access to) Justin took a couple of stabs at fixing the problem before the specifics of clearing PGA_EXECUTABLE needing to be part of a working fix was identified. (My statements of the history may be over simplified but I think generally point in the right direction.) The sequence of messages about the kernel bug(s) ended with: https://lists.freebsd.org/pipermail/freebsd-ppc/2020-June/011916.html https://lists.freebsd.org/pipermail/freebsd-ppc/2020-June/011917.html https://lists.freebsd.org/pipermail/freebsd-ppc/2020-June/011969.html https://lists.freebsd.org/pipermail/freebsd-ppc/2020-June/011970.html https://lists.freebsd.org/pipermail/freebsd-ppc/2020-June/011971.html Even booting and leaving such a machine idle eventually has processes die from the zeroed pages (not quickly). It is easier/quicker to see the problem by building with a debug jemalloc (no MALLOC_PRODUCTION=3D in use): the debug code notices problems with jemalloc's own memory being zeroed much earlier generally, still not quickly when idle. I've not noticed anything go by that involved clearing PGA_EXECUTABLE so I expect that things are still broken. Note: There were other notes about potential kernel code issues but I'm not going to relist everything that looked like it might be an issue of some kind. I had traced PGA_EXECUTABLE mis-handling to be a definite problem. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)