On Sat, Sep 02, 2017 at 12:53:51AM -0500, Andrew Daugherity wrote: > On Fri, Sep 1, 2017 at 1:57 AM, Mike Larkin <mlar...@azathoth.net> wrote: > > > On Fri, Sep 01, 2017 at 01:04:40AM -0500, Andrew Daugherity wrote: > > > ==== > > > boot> hd0a:/bsd.61 > > > cannot open hd0a:/etc/random.seed: No such file or directory > > > booting hd0a:/bsd.61: 7678420+2057220+174556+0+1097728 > > > [72+501520+501951]=0xb761b4 > > > entry point at 0x2000d4 > > > > > > [ using 1003956 bytes of bsd ELF symbol table ] > > > Copyright (c) 1982, 1986, 1989, 1991, 1993 > > > The Regents of the University of California. All rights > > reserved. > > > Copyright (c) 1995-2017 OpenBSD. All rights reserved. > > https://www.OpenBSD.org > > > > > > OpenBSD 6.1 (GENERIC) #291: Sat Apr 1 13:49:08 MDT 2017 > > > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC > > > kernel: privileged instruction fault trap, code=0 > > > Stopped at cpuid+0x12: cpuid > > > ddb> trace > > > cpuid(80000000,d0d78ef0,d0d78ed8,0,7d) at cpuid+0x12 > > > identifycpu(d0c7d8a0,d09fbb83,10,0,ffffffff) at identifycpu+0x80d > > > cpu_startup(d09cefed,d09d1680,16c,8,0) at cpu_startup+0xb9 > > > main(d02004c6,d02004ce,0,0,0) at main+0x6a > > > ddb> ps > > > PID TID PPID UID S FLAGS WAIT COMMAND > > > ddb> > > > ==== > > > > > > Looks like it's trying to run the CPUID instruction, which this > > > processor probably doesn't support. Maybe this was an accidental > > > breakage, rather than intentionally dropping 486es? Time to examine > > > the CVS logs, I guess. (A -current snapshot also fails in the same > > > manner, so something happened between 6.0 & 6.1.) > > > > > > > Looks like I broke this about a year ago: > > > > 1.592 (mlarkin 14-Oct-16): > > 1.592 (mlarkin 14-Oct-16): cpuid(0x80000000, regs); > > 1.592 (mlarkin 14-Oct-16): if (regs[0] >= 0x80000006) > > 1.592 (mlarkin 14-Oct-16): cpuid(0x80000006, > > ci->ci_extcacheinfo); > > > > I did test this on 486, but apparently qemu's emulated 486 isn't really a > > proper 486. I'll see what I can do to solve it for you. > > > > Thanks for reporting it. > > > > -ml > > > > I was looking at that commit last night, and thinking it might be the one > at issue here. My next step was going to be adding a '&& class == > CPUCLASS_686' to that block [if (vendor == CPUVENDOR_INTEL)] to match the > AMD block above it -- not sure if 686 is the correct restriction there, or > 586, or something else like 'cpuid_level >= N' -- but any of those would > probably resolve my issue. > > qemu isn't necessarily wrong if it was emulating a later 486 like the DX4 > -- apparently those (and the Am5x86, and maybe even the DX2?) did support > CPUID, just not the older 486DX/SX. > > And yes, I know 16MB RAM will be an issue. I just built a stripped-down > 4.1 kernel (on a faster box, of course) which gained me about 6MB > additional RAM and the ability to actually start X plus a couple xterms (on > GENERIC it was still swapping madly an hour after startx and took about 45 > seconds to recover after Ctrl+Alt+Backspace). I doubt that will be > possible on 6.1, even with a small kernel -- besides, I'd have to build > XF86_AGX myself if I wanted anything better than VGA. It's only for > nostalgia reasons and the somewhat unique hardware (and its small size, > meaning it's easily packed into a box o'stuff) that I've hung onto it > anyway. > > Thanks for the forthcoming fix! > > > -Andrew
I committed a fix for this, please wait for the next snap and give it a try and let me know if it is still broken. -ml
