Re: head -r365932 on PowerMac G5 (2 dual-core sockets): Crashes before login prompt if powerd is enabled in /etc/rc.conf

On 2020-Sep-22, at 08:58, Brandon Bergren <[email protected]> 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 <read_scom> addis   r2,r12,132
0000000000ad7f28 <read_scom+0x4> addi    r2,r2,220
0000000000ad7f2c <read_scom+0x8> mflr    r0
0000000000ad7f30 <read_scom+0xc> std     r31,-8(r1)
0000000000ad7f34 <read_scom+0x10> std     r0,16(r1)
0000000000ad7f38 <read_scom+0x14> stdu    r1,-64(r1)
0000000000ad7f3c <read_scom+0x18> mr      r31,r1
0000000000ad7f40 <read_scom+0x1c> std     r29,40(r31)
0000000000ad7f44 <read_scom+0x20> std     r30,48(r31)
0000000000ad7f48 <read_scom+0x24> bl      0000000000ad7e58 <mfmsr>
0000000000ad7f4c <read_scom+0x28> mr      r30,r3
0000000000ad7f50 <read_scom+0x2c> rldicl  r3,r3,48,1
0000000000ad7f54 <read_scom+0x30> rotldi  r3,r3,16
0000000000ad7f58 <read_scom+0x34> bl      0000000000ad7e6c <mtmsr>
0000000000ad7f5c <read_scom+0x38> bl      0000000000ad7e84 <isync>
0000000000ad7f60 <read_scom+0x3c> lis     r3,16512
0000000000ad7f64 <read_scom+0x40> ori     r3,r3,33024
0000000000ad7f68 <read_scom+0x44> mtspr   276,r3
0000000000ad7f6c <read_scom+0x48> bl      0000000000ad7e84 <isync>
0000000000ad7f70 <read_scom+0x4c> mfspr   r29,277
0000000000ad7f74 <read_scom+0x50> mr      r30,r29
0000000000ad7f78 <read_scom+0x54> rldicl  r29,r29,32,32
0000000000ad7f7c <read_scom+0x58> mfspr   r3,276
0000000000ad7f80 <read_scom+0x5c> mr      r3,r30
0000000000ad7f84 <read_scom+0x60> bl      0000000000ad7e6c <mtmsr>
0000000000ad7f88 <read_scom+0x64> bl      0000000000ad7e84 <isync>
0000000000ad7f8c <read_scom+0x68> mr      r3,r29
0000000000ad7f90 <read_scom+0x6c> ld      r30,48(r31)
0000000000ad7f94 <read_scom+0x70> ld      r29,40(r31)
0000000000ad7f98 <read_scom+0x74> addi    r1,r1,64
0000000000ad7f9c <read_scom+0x78> ld      r0,16(r1)
0000000000ad7fa0 <read_scom+0x7c> mtlr    r0
0000000000ad7fa4 <read_scom+0x80> ld      r31,-8(r1)
0000000000ad7fa8 <read_scom+0x84> 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 <marklmi at yahoo.com> 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 <pcr_get> addis   r2,r12,132
>> 0000000000ad7ad8 <pcr_get+0x4> addi    r2,r2,1324
>> 0000000000ad7adc <pcr_get+0x8> cmpldi  r4,0
>> 0000000000ad7ae0 <pcr_get+0xc> beq     0000000000ad7b48 <pcr_get+0x74>
>> 0000000000ad7ae4 <pcr_get+0x10> mflr    r0
>> 0000000000ad7ae8 <pcr_get+0x14> std     r31,-8(r1)
>> 0000000000ad7aec <pcr_get+0x18> std     r0,16(r1)
>> 0000000000ad7af0 <pcr_get+0x1c> stdu    r1,-64(r1)
>> 0000000000ad7af4 <pcr_get+0x20> mr      r31,r1
>> 0000000000ad7af8 <pcr_get+0x24> std     r29,40(r31)
>> 0000000000ad7afc <pcr_get+0x28> mr      r29,r3
>> 0000000000ad7b00 <pcr_get+0x2c> li      r3,-1
>> 0000000000ad7b04 <pcr_get+0x30> std     r30,48(r31)
>> 0000000000ad7b08 <pcr_get+0x34> mr      r30,r4
>> 0000000000ad7b0c <pcr_get+0x38> std     r3,32(r4)
>> 0000000000ad7b10 <pcr_get+0x3c> std     r3,24(r4)
>> 0000000000ad7b14 <pcr_get+0x40> std     r3,16(r4)
>> 0000000000ad7b18 <pcr_get+0x44> std     r3,8(r4)
>> 0000000000ad7b1c <pcr_get+0x48> std     r3,0(r4)
>> 0000000000ad7b20 <pcr_get+0x4c> bl      0000000000ad7f2c <read_scom+0x8>
>> 0000000000ad7b24 <pcr_get+0x50> rldicl  r3,r3,8,62
>> 0000000000ad7b28 <pcr_get+0x54> li      r4,10000
>> 0000000000ad7b2c <pcr_get+0x58> stw     r4,0(r30)
>> 0000000000ad7b30 <pcr_get+0x5c> cmpldi  r3,1
>> 0000000000ad7b34 <pcr_get+0x60> beq     0000000000ad7b50 <pcr_get+0x7c>
>> 0000000000ad7b38 <pcr_get+0x64> cmpldi  r3,2
>> 0000000000ad7b3c <pcr_get+0x68> bne     0000000000ad7b58 <pcr_get+0x84>
>> 0000000000ad7b40 <pcr_get+0x6c> li      r3,2500
>> 0000000000ad7b44 <pcr_get+0x70> b       0000000000ad7b54 <pcr_get+0x80>
>> 0000000000ad7b48 <pcr_get+0x74> li      r3,22
>> 0000000000ad7b4c <pcr_get+0x78> blr
>> 0000000000ad7b50 <pcr_get+0x7c> li      r3,5000
>> 0000000000ad7b54 <pcr_get+0x80> stw     r3,0(r30)
>> 0000000000ad7b58 <pcr_get+0x84> std     r29,16(r30)
>> 0000000000ad7b5c <pcr_get+0x88> ld      r30,48(r31)
>> 0000000000ad7b60 <pcr_get+0x8c> ld      r29,40(r31)
>> 0000000000ad7b64 <pcr_get+0x90> addi    r1,r1,64
>> 0000000000ad7b68 <pcr_get+0x94> ld      r0,16(r1)
>> 0000000000ad7b6c <pcr_get+0x98> li      r3,0
>> 0000000000ad7b70 <pcr_get+0x9c> mtlr    r0
>> 0000000000ad7b74 <pcr_get+0xa0> ld      r31,-8(r1)
>> 0000000000ad7b78 <pcr_get+0xa4> blr
>> 
> 
> 

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"