On Thu, Jan 24, 2019 at 03:35:01AM +0100, Krystian Lewandowski wrote: > > > Wiadomość napisana przez Mike Larkin <mlar...@azathoth.net> w dniu > > 24.01.2019, o godz. 00:15: > > > > On Tue, Jan 22, 2019 at 11:31:08AM +0100, Krystian Lewandowski wrote: > >> > >>> Wiadomość napisana przez Mike Larkin <mlar...@azathoth.net> w dniu > >>> 22.01.2019, o godz. 04:35: > >>> > >>> On Mon, Jan 21, 2019 at 07:29:40PM -0800, Mike Larkin wrote: > >>>> On Tue, Jan 22, 2019 at 03:14:13AM +0100, Krystian Lewandowski wrote: > >>>>> Hello misc@, > >>>>> > >>>>> I’m trying to boot OpenBSD (current) on iMac Pro (iMacPro1,1). > >>>>> It’s Apple’s Xeon-W based PC with ECC memory. > >>>>> > >>>>> This machine is very picky when it comes to OS support. Obviously macOS > >>>>> is well > >>>>> supported and I don’t have problems with it, MS Windows on an > >>>>> external USB drive is stable as well. > >>>>> I tried whole BSD family, multiple Linux based distros and Illumos. The > >>>>> only > >>>>> Linux distribution I was able to boot and install was Clear Linux* - > >>>>> ended up with kernel > >>>>> panicking randomly, and regarding BSDs - I was able to install and boot > >>>>> FreeBSD > >>>>> but it randomly fails with a Machine Check Exceptions. > >>>>> > >>>>> The other interesting thing is infamous T2 chip in which iMac Pro is > >>>>> equipped - > >>>>> almost every crash ends up with BridgeOS crash report. > >>>>> > >>>>> I would consider OpenBSD assertion failures and FreeBSD MCA errors > >>>>> "UNCORR PCC GCACHE L2 ERR error" as valid if it wasn’t for rock stable > >>>>> macOS and > >>>>> MS Windows (and on both it’s pushed hard at times, for a few hours > >>>>> straight, incl. VMs). > >>>>> And my understanding is that this iMac Pro is no exception - other > >>>>> iMacs present > >>>>> similar behaviour (ending up with similar T2 chip Bridge OS crash > >>>>> reports). > >>>>> > >>>>> I tried to do my homework and installed OpenBSD on an external USB > >>>>> drive via > >>>>> VMWare Fusion and built kernel with DEBUG flag. > >>>>> External USB drive is the only option because of T2 chip. > >>>>> > >>>>> Tried to boot .SP kernel, tried to disable some devices - though > >>>>> probably > >>>>> doesn’t matter because I assume it’s crashing before autoconf is even > >>>>> involved. > >>>>> I also, tried to update microcode at boot on FreeBSD - someone > >>>>> suggested that > >>>>> via Twitter - didn’t help for at runtime MCA faults (CPU had most > >>>>> recent microcode). > >>>>> > >>>>> OpenBSD snapshot fails with: > >>>>> "fatal machine check in supervisor mode" > >>>>> "panic: trap type 18, code=0, pc=…" > >>>>> https://www.dropbox.com/s/birtxskxayjvxht/OpenBSD%20default%20kernel.jpeg?dl=0 > >>>>> > >>>> > >>>> This may be related to a set of recent changes I made. Can you try > >>>> 6.4-RELEASE > >>>> and see if that still panics? > >>>> > >>>> -ml > >>>> > >>> > >>> Sorry, didn't see the other captures. The most recent crash may still be > >>> due to > >>> the recent changes though. The MCEs, well, that's another thing. > >>> > >>> Can you send me the output of "machine memory" from the boot> prompt > >>> please? > >>> > >>> -ml > >>> > >> > >> Sure, > >> please find machine memory output here: > >> https://www.dropbox.com/s/sbgq7av9m0sre14/machine_memory.jpeg?dl=0 > >> > >> Krystian > >> > > > > Does shrinking the amount of memory get any further? > > > > boot> mach mem =16G > > > > ... something like that? > > > > -ml > > > > I think, I could say yes, a bit (compared to my most recent attempts). Now I > can > see mpath0 and scsibus0 being logged before the crash. Tried a few times on > default > kernel and DEBUG kernel, very similar in all tries. > > https://www.dropbox.com/s/z9xnheqhy274z8z/mem%2016G.jpeg?dl=0 > https://www.dropbox.com/s/ozqlhsch0yz4ibr/16G%20default%20kernel.jpeg?dl=0 > https://www.dropbox.com/s/hbzbf1aa2u0a9h4/16G%20debug%20kernel.jpeg?dl=0 > > And after that, macOS welcomed me with "x86 CPU CATERR detected report. > > Krystian
You selected mach mem =16G and yet the kernel thought all 64GB was available? Odd. Either your machine is totally hosed or there is some other problem. In any case, "show registers" at ddb> after the panic might show more. But I'm at a bit of a loss to explain what is going on here. -ml
