Panic @ orm_identify+0x308 (kernel probes) after r327103 -> r327140

[Warner Losh]

On Sun, Dec 24, 2017 at 7:16 AM, Dimitry Andric <dimitry at andric.com> wrote:

> On 24 Dec 2017, at 14:27, David Wolfskill <david at catwhisker.org> wrote:
> >
> > Had this on the laptop; fotunately, also got it on the build machine (as
> > it's a lot easier to work with the serial console of the latter for
> > this -- and it runs a GENERIC kernel):
> ...
> > Fatal trap 9: general protection fault while in kernel mode
> > cpuid = 2; apic id = 02
> > instruction pointer     = 0x20:0xffffffff81066968
> > stack pointer           = 0x28:0xffffffff82286a90
> > frame pointer           = 0x28:0xffffffff82286ad0
> > code segment            = base 0x0, limit 0xfffff, type 0x1b
> >                        = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags        = interrupt enabled, resume, IOPL = 0
> > current process         = 0 (swapper)
> > [ thread pid 0 tid 100000 ]
> > Stopped at      orm_identify+0x308:     movq    (%r14),%rax
> > db> bt
> > Tracing pid 0 tid 100000 td 0xffffffff81e94340
> > orm_identify() at orm_identify+0x308/frame 0xffffffff82286ad0
> > bus_generic_probe() at bus_generic_probe+0x74/frame 0xffffffff82286b00
> > isa_probe_children() at isa_probe_children+0x19/frame 0xffffffff82286b50
> > mi_startup() at mi_startup+0x9c/frame 0xffffffff82286b70
> > btext() at btext+0x2c
>
> Since there is "isa" in the backtrace, I would consider r327120 ("Warn
> when nonPNP ISA devices are attached in GENERIC that they are being
> removed from GENERIC in 12") by Warner suspect...
>
> Specifically, this change:
> https://svnweb.freebsd.org/base/head/sys/x86/isa/orm.c?
> r1=327120&r2=327119&pathrev=327120


Yea, I just partially reverted it. It worked when I test booted it, but
there must be something different in David's machine than mine that I
hand't considered.

Warner