- User Since
- Jun 6 2018, 11:31 PM (45 w, 3 d)
Sun, Apr 7
Going to work on some issues I noticed with the power_save_sequence.
@luporl Feel free to commandeer this back again. Please do a test of the updated trap code with clang8/lld8. I have sucessfully booted this with my base/gcc 8.2.0.
marking done on addressed comments.
Rewrote trap code to not waste valuable trap space for addresses that are easily calculatable.
Tighten up the reset vector by one instruction.
Commandeering this to post updated trap code.
Sat, Apr 6
Yep, there is indeed an 8-byte alignment restriction on .toc.
Also the section being subsumed into .got might throw off the linker as well.
Well, it's probably from the alignment being off. Ensuring alignment there makes sense to me imo. Checking what the actual requirements are...
Fri, Mar 29
The TOC_REF bits have landed separately as rS345676.
Tue, Mar 26
Note: The LINKS= line breaks installkernel on systems where /boot is a msdos filesystem (currently needed on some petitboot systems on powerpc64 -- Talos II in particular, due to lack of UFS support in the default PNOR builds)
Looks good here. It has the bugs fixed that I had in the original. +1
Mar 17 2019
Some parts of this will land separately. The ldscript chanages are split off to D19574 as more cases have been discovered where kernels were built with multiple PT_LOAD sections, even on ELFv1, and it should probably go in first.
Mar 16 2019
ELFv1 test went fine too on the G5.
Mar 15 2019
This is functionally identical to what I've been running locally since last October for my ELFv2 kernel builds.
Mar 12 2019
Feb 26 2019
Feb 25 2019
Regarding the sys/conf/Makefile.powerpc, sys/conf/kern.pre.mk and
sys/powerpc/include/vparam.h changes that you left out, leaving them out is correct -- they were POWER9BSD and/or local hacks that are unrelated.
Feb 22 2019
Feb 18 2019
Yeah, that's better.
Feb 14 2019
Jan 31 2019
Jan 15 2019
32 bit version works fine on G4.
Jan 10 2019
C question: Would a cast through void* be a better workaround for this specific issue by the way?
Abandoning in favor of the D18808 solution.
OK, I'm fine with this solution.
Jan 7 2019
32-bit version of the code is working OK on my iBook G4.
Jan 3 2019
The patch has been accepted upstream.
Dec 19 2018
Dec 16 2018
On second thought, it looks like there might be cases where we should actually be checking the relocation. I'll fix this properly with the ifunc implementation I'll be submitting this week.
Dec 14 2018
This could plausibly be either that binutils ld.bfd is more picky than lld about undefined references (in code that is ultimately dead, possibly? JSON.o / MicrosoftMangle.o seem like the sort of thing to me that would end up ultimately trimmed out) or that my build went down a path that is untested on amd64.
Always include xxhash.cpp in libllvm, to fix buildworld on powerpc64 with binutils ld.
I think it's possible that ld.bfd on powerpc64 is more picky than lld when it comes to missing references inside archives, because I am encountering a build failure on the main compiler as well.
OPTIONS_UNSET=DOCS NLS WRKDIRPREFIX=/usr/obj
Dec 1 2018
Replaced the comment block with one that jhibbits wrote that's worded a lot better than mine.
Nov 28 2018
Nov 27 2018
Nov 26 2018
Fix ABI violation that was causing crash on thread exit.
Nov 25 2018
Nov 2 2018
Oct 31 2018
Looks good to me too, and I think it's important for anything doing textrelocs on ppc.
Oct 29 2018
Additionally, the setting of lowaddr to an address below the end of phys memory will force bus_dmamem_alloc to always do contig malloc, which causes additional pressure and possibility of failure. sys/powerpc/powerpc/busdma_machdep.c badly needs some updating to handle stuff like multiple segment allocations and multiple exclusion ranges.
On POWER9, the controllers operate in 32 bit and 64 bit mode simultaneously. A full fix will require teaching the dma tag handling to handle multiple exclusion ranges, I imagine. Right now it's hardcoded to only allocate memory between 0x0 and lowaddr, and it ignores highaddr entirely.
Specifically, here's the problem that we're seeing on the Talos II:
The problem is that the change is applying to 64-bit devices too. It really needs to be restricted to PECs that have 32 bit devices attached.
Oct 5 2018
Oct 2 2018
No complaints on this end, it's working just fine here.
Oct 1 2018
oh, THAT's why the cam layer wasn't attaching. Will test this on my equipment now.
Sep 19 2018
Add a check for powernv by running the opal_check().
Sep 17 2018
Oh, right, I forgot to also put in my original symptoms and train of thought, for people who weren't following along with my chasing of this issue:
hmm, actually, phb3 does the same thing for MSI when initting ioda2 as phb4 does for ioda3. Is this bug also happening on P8?
Sep 16 2018
Physical map before:
Aug 3 2018
Two more make -j64 buildworld runs complete. I don't know why it's suddenly decided to stop crashing for me, but I will focus on the hardware side if it comes back.
I figured out the correct SCOM address for interrogating what error happened that is causing my controller freeze, but of course now that I have that figured out, it's not happening.
@kbowling Nah, my fs is fine. I'm saying that this patch is an improvement in that when it crashes, it leaves the fs in a saner state than a crash without the patch.
One definite improvement for me with this patch is that fsck seems to be able to recover the root filesystem after a crash without manual intervention, which I was not seeing before.
I was not on the latest firmware. However, updating the firmware didn't seem to help.
Aug 2 2018
Crashed in intx mode as well.
ok, crashed with the local bits I was wondering about as well.
ok, so unfortunately, I had another crash when testing with only these changes. My original crash where the controller straight up stops working and won't even reset.
yep, working on it now.
I recompiled with just this diff, and I was back to crashing during buildworld. Going to recompile with my local changes again so if it crashes again I have my tools to examine the nvme queues more extensively from the kernel debugger.
I actually made it through a buildworld for once without panicing for once with this patch. My kernel's not clean at the moment, but I will rerun with only this patch in a bit.
Attaches fine on my Talos II. Seems to work fine, as far as I can tell.