From owner-freebsd-ppc@freebsd.org Tue Sep 22 19:01:16 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 8ADE43F2FBA for ; Tue, 22 Sep 2020 19:01:16 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BwrHw3D7dz4Syt; Tue, 22 Sep 2020 19:01:16 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bdragon/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4D72B1DD5E; Tue, 22 Sep 2020 19:01:16 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id 1ED2D27C0054; Tue, 22 Sep 2020 15:01:16 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute4.internal (MEProxy); Tue, 22 Sep 2020 15:01:16 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeggddufeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdluddtmdenucfjughrpefofgggkfgjfhffhffvufgtsehttdertder reejnecuhfhrohhmpedfuehrrghnughonhcuuegvrhhgrhgvnhdfuceosggurhgrghhonh eshfhrvggvuefuffdrohhrgheqnecuggftrfgrthhtvghrnhepgfeuueejieehvdeffeet tdeigfelueetfeehffduhffhvddvtdeftefgteffhfdvnecuffhomhgrihhnpehfrhgvvg gsshgurdhorhhgpdgushhlqdhonhhlhidrnhgvthenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpegsughrrghgohhnodhmvghsmhhtphgruhhthh hpvghrshhonhgrlhhithihqddutdegvdefheekieegqddukedutdekheduqdgsughrrghg ohhnpeephfhrvggvuefuffdrohhrghesihhmrghprdgttg X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B86D7C200A6; Tue, 22 Sep 2020 15:01:15 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-355-g3ece53b-fm-20200922.004-g3ece53b9 Mime-Version: 1.0 Message-Id: <11fe573a-24c3-47be-95ed-c601ec54f168@www.fastmail.com> In-Reply-To: References: <52783D16-5DCA-45BC-9238-2518326454A1@yahoo.com> <6E99EE39-D2B8-415A-A5BF-823C0F0C22D6@yahoo.com> Date: Tue, 22 Sep 2020 14:00:56 -0500 From: "Brandon Bergren" To: "Mark Millard" Cc: "FreeBSD PowerPC ML" Subject: =?UTF-8?Q?Re:_head_-r365932_on_PowerMac_G5_(2_dual-core_sockets):_Crashe?= =?UTF-8?Q?s_before_login_prompt_if_powerd_is_enabled_in_/etc/rc.conf?= Content-Type: text/plain X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.33 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 Sep 2020 19:01:16 -0000 Weird, that read_scom has the "inlines not being inlined" problem. Are you sure your local tree has my https://svnweb.freebsd.org/base/head/?view=revision&revision=365441 fixes? On Tue, Sep 22, 2020, at 1:55 PM, Mark Millard wrote: > > > On 2020-Sep-22, at 08:58, Brandon Bergren wrote: > > > In theory, this would also crash if you did "sysctl dev.cpu.0.freq". > > Yep, that dies with a backtrace but not taking input to > the db> prompt. > > The call stack looks to have the same sequence. > > Different srr0 and lr values were listed when I tried > that: > > srr0=0x8004'4000'0000'0000 (0xc004'4000'0000'0000) > . . . > lr =0x8004'4000'0000'0000 (0xc004'4000'0000'0000) > > > > You sure the lack of a backtrace isn't just that you are using a nodebug config? > > Back when I was using the FireWire based debugging I > discovered that it continued to report material after > the monitor updates stopped. I learned to not use > the last message on screen to guess where it was > having a problem, other than "sometime after the > last message shown". > > > Could you please disassemble read_scom? > > Sure: > > 0000000000ad7f24 addis r2,r12,132 > 0000000000ad7f28 addi r2,r2,220 > 0000000000ad7f2c mflr r0 > 0000000000ad7f30 std r31,-8(r1) > 0000000000ad7f34 std r0,16(r1) > 0000000000ad7f38 stdu r1,-64(r1) > 0000000000ad7f3c mr r31,r1 > 0000000000ad7f40 std r29,40(r31) > 0000000000ad7f44 std r30,48(r31) > 0000000000ad7f48 bl 0000000000ad7e58 > 0000000000ad7f4c mr r30,r3 > 0000000000ad7f50 rldicl r3,r3,48,1 > 0000000000ad7f54 rotldi r3,r3,16 > 0000000000ad7f58 bl 0000000000ad7e6c > 0000000000ad7f5c bl 0000000000ad7e84 > 0000000000ad7f60 lis r3,16512 > 0000000000ad7f64 ori r3,r3,33024 > 0000000000ad7f68 mtspr 276,r3 > 0000000000ad7f6c bl 0000000000ad7e84 > 0000000000ad7f70 mfspr r29,277 > 0000000000ad7f74 mr r30,r29 > 0000000000ad7f78 rldicl r29,r29,32,32 > 0000000000ad7f7c mfspr r3,276 > 0000000000ad7f80 mr r3,r30 > 0000000000ad7f84 bl 0000000000ad7e6c > 0000000000ad7f88 bl 0000000000ad7e84 > 0000000000ad7f8c mr r3,r29 > 0000000000ad7f90 ld r30,48(r31) > 0000000000ad7f94 ld r29,40(r31) > 0000000000ad7f98 addi r1,r1,64 > 0000000000ad7f9c ld r0,16(r1) > 0000000000ad7fa0 mtlr r0 > 0000000000ad7fa4 ld r31,-8(r1) > 0000000000ad7fa8 blr > > > > On Tue, Sep 22, 2020, at 12:46 AM, Mark Millard via freebsd-ppc wrote: > >> > >> > >> On 2020-Sep-21, at 21:34, Mark Millard wrote: > >> > >>> This was discovered while doing a head -r363590 -> -r365932 > >>> upgrade to FreeBSD. (A non-debug system context.) > >>> > >>> It first showed up only having updated the kernel. It still > >>> shows up after updating world as well. It is now running: > >>> > >>> # uname -apKU > >>> FreeBSD FBSDG5L2 13.0-CURRENT FreeBSD 13.0-CURRENT #16 r365932M: Sun Sep 20 19:57:07 PDT 2020 root@FBSDFHUGE:/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1300115 1300115 > >>> > >>> but with /etc/rc.conf having powerd disabled: > >>> > >>> #powerd_enable="YES" > >>> > >>> The crash now is now silent, not getting to the db> prompt > >>> and not showing any messages or backtrace. > >>> > >>> Prior to world being updated it crashed with a traceback. > >>> A quick summary from a camera picture: > >>> > >>> fatal kernel trap: > >>> . . . > >>> pid = 1126, comm = powerd > >>> . . . > >>> kernel PGM trap by 0: . . . > >>> at pcr_get+0x4c > >>> at CPUFREQ_DRV_GET+0x78 > >>> at cpufreq_get_frequency+0x20 > >>> at cpufreq_get_level+0x2c > >>> at cf_get_method+0x20c > >>> at CPUFREQ_GET+0x78 > >>> at cpufreq_curr_sysctl+0x70 > >>> at sysctl_root_handler_locked+0x10c > >>> at sysctl_root+0x26c > >>> at userland_sysctl+0x14c > >>> at sys___sysctl+0x8c > >>> at syscallenter+0x188 > >>> at syscall+0x60 > >>> at trap+0x498 > >>> at powerpc_interrrupt+0x110 > >>> user SC trap . . . > >>> > >>> After this I tried to make a dump and then proceeded > >>> with disabling powerd in /etc/rc.conf and doing the > >>> world update. > >>> > >>> Unfortunately, while a dump was written, the core.txt > >>> file from the -r365932 world boot that processed the > >>> dump reported "invalid corefile" all over the place. > >>> > >>> With powerpd disabled the G5 seems to be operational. > >>> But turning powerd back on in /etc/rc.conf and rebooting > >>> prevents the boot from completing, no messages, no > >>> db> prompt. So I now leave powerd disabled. > >> > >> Some additional low-level information: > >> > >> For exception 0x700 (program) the screen picture > >> shows (but I've added ' use): > >> > >> srr0=0x0 (0x4000'0000'0000'0000) > >> . . . > >> lr =0x0 (0x4000'0000'0000'0000) > >> > >> The kernel PGM trap notice does report: > >> > >> ctr=0xc000'0000'00ad'7ad4 > >> (the start of pcr_get but with the 0xc > >> prefix) > >> > >> I'll remind of the pcr_get+0x4c report in the summary. > >> > >> objdump for /boot/kernel/kernel reports: > >> > >> 0000000000ad7ad4 addis r2,r12,132 > >> 0000000000ad7ad8 addi r2,r2,1324 > >> 0000000000ad7adc cmpldi r4,0 > >> 0000000000ad7ae0 beq 0000000000ad7b48 > >> 0000000000ad7ae4 mflr r0 > >> 0000000000ad7ae8 std r31,-8(r1) > >> 0000000000ad7aec std r0,16(r1) > >> 0000000000ad7af0 stdu r1,-64(r1) > >> 0000000000ad7af4 mr r31,r1 > >> 0000000000ad7af8 std r29,40(r31) > >> 0000000000ad7afc mr r29,r3 > >> 0000000000ad7b00 li r3,-1 > >> 0000000000ad7b04 std r30,48(r31) > >> 0000000000ad7b08 mr r30,r4 > >> 0000000000ad7b0c std r3,32(r4) > >> 0000000000ad7b10 std r3,24(r4) > >> 0000000000ad7b14 std r3,16(r4) > >> 0000000000ad7b18 std r3,8(r4) > >> 0000000000ad7b1c std r3,0(r4) > >> 0000000000ad7b20 bl 0000000000ad7f2c > >> 0000000000ad7b24 rldicl r3,r3,8,62 > >> 0000000000ad7b28 li r4,10000 > >> 0000000000ad7b2c stw r4,0(r30) > >> 0000000000ad7b30 cmpldi r3,1 > >> 0000000000ad7b34 beq 0000000000ad7b50 > >> 0000000000ad7b38 cmpldi r3,2 > >> 0000000000ad7b3c bne 0000000000ad7b58 > >> 0000000000ad7b40 li r3,2500 > >> 0000000000ad7b44 b 0000000000ad7b54 > >> 0000000000ad7b48 li r3,22 > >> 0000000000ad7b4c blr > >> 0000000000ad7b50 li r3,5000 > >> 0000000000ad7b54 stw r3,0(r30) > >> 0000000000ad7b58 std r29,16(r30) > >> 0000000000ad7b5c ld r30,48(r31) > >> 0000000000ad7b60 ld r29,40(r31) > >> 0000000000ad7b64 addi r1,r1,64 > >> 0000000000ad7b68 ld r0,16(r1) > >> 0000000000ad7b6c li r3,0 > >> 0000000000ad7b70 mtlr r0 > >> 0000000000ad7b74 ld r31,-8(r1) > >> 0000000000ad7b78 blr > >> > > > > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > -- Brandon Bergren bdragon@FreeBSD.org