Re: head -r365932 on PowerMac G5 (2 dual-core sockets): Crashe s before login prompt if powerd is enabled in /etc/rc.conf
"Brandon Bergren" <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.ppc |
|---|---|
| Message-ID | <[email protected]> |
OK, stuff using -O instead of -O2 is known to break G4 in early boot at the very least, and the function calls in that context are pretty problematic in general. Here's how it's supposed to look: (gdb) disassemble read_scom Dump of assembler code for function read_scom: 0x0000000000b067f8 <+0>: mfmsr r4 0x0000000000b067fc <+4>: rldicl r3,r4,48,1 0x0000000000b06800 <+8>: lis r5,16512 0x0000000000b06804 <+12>: rotldi r3,r3,16 0x0000000000b06808 <+16>: mtmsr r3 0x0000000000b0680c <+20>: isync 0x0000000000b06810 <+24>: isync 0x0000000000b06814 <+28>: ori r3,r5,33024 0x0000000000b06818 <+32>: mtspr 276,r3 0x0000000000b0681c <+36>: isync 0x0000000000b06820 <+40>: mfspr r3,277 0x0000000000b06824 <+44>: mr r4,r3 0x0000000000b06828 <+48>: rldicl r3,r3,32,32 0x0000000000b0682c <+52>: mfspr r5,276 0x0000000000b06830 <+56>: mtmsr r4 0x0000000000b06834 <+60>: isync 0x0000000000b06838 <+64>: isync 0x0000000000b0683c <+68>: blr 0x0000000000b06840 <+72>: .long 0x0 0x0000000000b06844 <+76>: .long 0x0 0x0000000000b06848 <+80>: .long 0x0 Do you have any flags set in your make.conf / src.conf / the kernel config file etc? On Tue, Sep 22, 2020, at 2:15 PM, Mark Millard wrote: > > > On 2020-Sep-22, at 12:00, Brandon Bergren <bdragon at FreeBSD.org> wrote: > > > 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? > > # svnlite diff /usr/src/sys/conf/kern.pre.mk > # svnlite info /usr/src > Path: . > Working Copy Root Path: /usr/src > URL: https://svn.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 365932 > Node Kind: directory > Schedule: normal > Last Changed Author: jrtc27 > Last Changed Rev: 365932 > Last Changed Date: 2020-09-20 16:20:18 -0700 (Sun, 20 Sep 2020) > > But it used -O instead of -O2 . . . > > # Meta data file > /usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG/pcr.o.meta > CMD cc -target powerpc64-unknown-freebsd13.0 > --sysroot=/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp -B/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -msoft-float -fPIC -fno-omit-frame-pointer -fdebug-prefix-map=./machine=/usr/src/sys/powerpc/include -mno-altivec -msoft-float -mabi=elfv2 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-erro r-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -Wno-for mat-zero-length -std=iso9899:1999 /usr/src/sys/powerpc/cpufreq/pcr.c > CMD ctfconvert -L VERSION -g pcr.o > CWD > /usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG > TARGET pcr.o > OODATE offset.inc assym.inc > > > > On Tue, Sep 22, 2020, at 1:55 PM, Mark Millard wrote: > >> > >> > >> 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 > > > > -- > Brandon Bergren > [email protected] > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > -- Brandon Bergren [email protected] _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to "[email protected]"