Page MenuHomeFreeBSD

[mips] revert r366664 - flip mips back from -O2 to -O
ClosedPublic

Authored by adrian on Tue, Jan 12, 9:16 PM.

Details

Summary

Now that I have -head fitting in 8MB of flash again, I can test
out freebsd-head on my home AP test setup. Unfortunately,
the introduction of -O2 in r366664 causes the following infinite
loop shortly after boot:


MAP: No valid partition found at map/rootfs.uzip
Warning: no time-of-day clock registered, system time will not be set accurately
start_init: trying /sbin/init
BAD_PAGE_FAULT: pid 1 tid 100001 (init), uid 0: pc 0x4042c320 got a read fault (type 0x2) at 0x2e3a0
Trapframe Register Dump:

zero: 0 at: 0   v0: 0   v1: 0
a0: 0x1af34     a1: 0   a2: 0   a3: 0x7fffeff0
t0: 0   t1: 0   t2: 0   t3: 0
t4: 0   t5: 0   t6: 0   t7: 0
t8: 0   t9: 0x152e8     s0: 0x7fffee84  s1: 0
s2: 0   s3: 0   s4: 0   s5: 0
s6: 0   s7: 0   k0: 0   k1: 0
gp: 0x362c0     sp: 0x7fffedf0  s8: 0   ra: 0x40417df0
sr: 0xf413      mullo: 0        mulhi: 0        badvaddr: 0x2e3a0
cause: 0xffffffff80000008       pc: 0x4042c31c

Page table info for pc address 0x4042c320: pde = 0x80712000, pte = 0xa002065a
Dumping 4 words starting at pc address 0x4042c320:
8f9980e0 80820000 10400067 00809825
Page table info for bad address 0x2e3a0: pde = 0, pte = 0


I'm not yet sure why, but until I figure it out with the mips64/cheri
folk this should be reverted.

Test Plan
  • QCA934x (mips74k) - WDR-3600/WDR-4300 APs

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

Please only do this for GCC if only GCC is broken.

And also a comment explaining why

  • Update to only do this with GCC
  • Add comment
This revision is now accepted and ready to land.Wed, Jan 13, 2:24 AM

Seems fine to me, but I do wonder if this means that we have some UB that clang could also exploit in the future and generate crashing code. Any idea which function the first crash is inside?

Seems fine to me, but I do wonder if this means that we have some UB that clang could also exploit in the future and generate crashing code. Any idea which function the first crash is inside?

I'll go try and reproduce this on QEMU and see if it fails. If it does then great. If not then it could be something QEMU on MIPS doesn't fully emulate - TLB/cache stuff.