Re: NetBSD-8/i386 SMP Panic? (was: Re: Netbsd-7/i386 won't boot on new motherboard/CPU)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 15 Nov 2017 20:48:14 -0700
    From:        Andy Ruhl <acruhl%gmail.com@localhost>
    Message-ID:  <CAJcb3fot6V0bd=5wLSWu7o9diNv9KgPa+kyh8GRe4-6gjhw8iw%mail.gmail.com@localhost>

  | I'm actually using netbsd-8 from the 201711131530Z directory on nyftp.

Yes, I knew you were using -8 ... in my last e-mail, somehow the "8"
I meant to type got skipped...

What I meant was that that explains why ACPI is OK now, and wasn't earlier
when you were attempting to boot the older -7 kernel.

  | I tried booting with and without -2 and I'm not sure if it affects the
  | new problem I'm having.

No, I think you can forget the boot flags (-1 and -2 now) you're past
that point.

  | If I boot with "boot -1 -2" it seems to solve the hangs during fsck,
  | but I'm not 100% sure about that.

I actually doubt it makes any difference.

  | I took photos of the panic at:
  | 
  | http://acruhl.freeshell.org/netbsd-i386-8-panic1.jpg
  | http://acruhl.freeshell.org/netbsd-i386-8-panic2.jpg

Those are UVM (x86 pmap) issues - there have been recent "issues" with
some of that code.  I wasn't aware it had been pulled up to -8, but I
guess it has.

  | I think this is SMP related, but I'm not sure.

That might make the issue more likely to occur, but is probably not
directly related (that is, the busier the system gets, the more likely
the pmap issues are to happen).

  | I got 2 panics that looked pretty similar to this when I did ctrl-c
  | during fsck which seemed to hang.

I think this issue might also explain fsck hangs - it all relates to
kernel mem allocation, and sleeping waiting for mem to become available
is normal.   If it never happens, hang...

Someone else is going to need to suggest what can be done with -8 ... I
don't remember (not that my lack of memory is evidence of anything at all)
any pullups to -8 (since Nov 13) which could be correcting this.

I'd actually suggest fetching a kernel from a build of current, and trying
that (if you use GENERIC, it will have all modules already loaded, so you
don't really need to worry about the modules directory and all its files.)
I know there have been fixes in -current (HEAD) for issues very similar to
the one you are seeing.   Just the kernel should be enough, there have been
no API changes that are likely to matter too much since 8 was branched
(I think perhaps just one relatively minor one) and that way you will be
able to go back to a -8 kernel once there is one which works properly.

I will cc a couple of people who are likely to know much more about this
than I do.

kre