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

2017-12-24 Thread Warner Losh
On Sun, Dec 24, 2017 at 7:16 AM, Dimitry Andric  wrote:

> On 24 Dec 2017, at 14:27, David Wolfskill  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:0x81066968
> > stack pointer   = 0x28:0x82286a90
> > frame pointer   = 0x28:0x82286ad0
> > code segment= base 0x0, limit 0xf, 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 10 ]
> > Stopped at  orm_identify+0x308: movq(%r14),%rax
> > db> bt
> > Tracing pid 0 tid 10 td 0x81e94340
> > orm_identify() at orm_identify+0x308/frame 0x82286ad0
> > bus_generic_probe() at bus_generic_probe+0x74/frame 0x82286b00
> > isa_probe_children() at isa_probe_children+0x19/frame 0x82286b50
> > mi_startup() at mi_startup+0x9c/frame 0x82286b70
> > 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=327119=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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


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

2017-12-24 Thread Warner Losh
On Sun, Dec 24, 2017 at 6:27 AM, David Wolfskill 
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):


That may be my fault somehow. I changed orm yesterday, but it worked for me
:(.  Since time is short, I'm commenting out the line I added at the end of
orm_identify. r327162 has the change. After the holidays I'll be in touch
to sort out why you're seeing this and I'm not.

I can afford to leave this machine as-is for a while, and can poke
> at it, given suitable clues as to where to poke & how hard. :-)


Nah, go ahead and reboot. This will be easy to recreate.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


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

2017-12-24 Thread David Wolfskill
On Sun, Dec 24, 2017 at 03:16:59PM +0100, Dimitry Andric wrote:
> ...
> > Fatal trap 9: general protection fault while in kernel mode
> > cpuid = 2; apic id = 02
> > instruction pointer = 0x20:0x81066968
> > stack pointer   = 0x28:0x82286a90
> > frame pointer   = 0x28:0x82286ad0
> > code segment= base 0x0, limit 0xf, 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 10 ]
> > Stopped at  orm_identify+0x308: movq(%r14),%rax
> > db> bt
> > Tracing pid 0 tid 10 td 0x81e94340
> > orm_identify() at orm_identify+0x308/frame 0x82286ad0
> > bus_generic_probe() at bus_generic_probe+0x74/frame 0x82286b00
> > isa_probe_children() at isa_probe_children+0x19/frame 0x82286b50
> > mi_startup() at mi_startup+0x9c/frame 0x82286b70
> > 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=327119=327120
> 
> -Dimitry
> 


And, indeed that seems to be the case:  After 'svn merge -c -r327120 .'

--- Reverse-merging r327120 into '.':
Usys/isa/isa_common.c
Usys/isa/pnp.c
Usys/isa/vga_isa.c
Usys/x86/isa/orm.c
--- Recording mergeinfo for reverse merge of r327120 into '.':
 U   .

and a kernel rebuild/re-install, the machine boots OK:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #52  
r327140M/327142:1200054: Sun Dec 24 06:36:43 PST 2017 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
If Trump is "taking names" re: the UN Jerusalem vote, he can add mine.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature


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

2017-12-24 Thread David Wolfskill
On Sun, Dec 24, 2017 at 03:03:33PM +0100, O. Hartmann wrote:
> ...
> So, it is dangerous to update beyond r327121? I'm running on most of our 
> machines now
> r327121 and it does not show nay anomalies so far ...
> 
> Regards,
> Oliver
> .

Hmm...  Well, reviewing the output from "svn log", I see that the next
commit to head after r327121 is r327140 -- a change to head/sbin/ipfw.
I have a hard time imagining how that could possibly affect anything
during the kernel device probes prior to the transition from single- to
multi-user mode.

So at this stage, I have no indication that what I observed in both of
my machines that track head will necessarily be seen by others.

I could try r327121, perhaps...

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
If Trump is "taking names" re: the UN Jerusalem vote, he can add mine.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature


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

2017-12-24 Thread Dimitry Andric
On 24 Dec 2017, at 14:27, David Wolfskill  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:0x81066968
> stack pointer   = 0x28:0x82286a90
> frame pointer   = 0x28:0x82286ad0
> code segment= base 0x0, limit 0xf, 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 10 ]
> Stopped at  orm_identify+0x308: movq(%r14),%rax
> db> bt
> Tracing pid 0 tid 10 td 0x81e94340
> orm_identify() at orm_identify+0x308/frame 0x82286ad0
> bus_generic_probe() at bus_generic_probe+0x74/frame 0x82286b00
> isa_probe_children() at isa_probe_children+0x19/frame 0x82286b50
> mi_startup() at mi_startup+0x9c/frame 0x82286b70
> 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=327119=327120

-Dimitry



signature.asc
Description: Message signed with OpenPGP


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

2017-12-24 Thread O. Hartmann
Am Sun, 24 Dec 2017 05:27:10 -0800
David Wolfskill  schrieb:

> 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):
> 
> ...
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-CURRENT #51  r327140M/327142:1200054: Sun Dec 24 05:11:03 PST 
> 2017
> 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC 
> amd64
> FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on LLVM 
> 5.0.1)
> WARNING: WITNESS option enabled, expect reduced performance.
> Table 'FACP' at 0xde3c1b98
> Table 'APIC' at 0xde3c1ca8
> Table 'FPDT' at 0xde3c1d40
> Table 'ASF!' at 0xde3c1d88
> Table 'SLIC' at 0xde3c1e30
> Table 'SSDT' at 0xde3c1fa8
> Table 'SSDT' at 0xde3c24e8
> Table 'MCFG' at 0xde3c2fc0
> Table 'HPET' at 0xde3c3000
> Table 'SSDT' at 0xde3c3038
> Table 'SSDT' at 0xde3c33a8
> Table 'MSDM' at 0xde3c6688
> Table 'DMAR' at 0xde3c66e0
> ACPI: No SRAT table found
> PPIM 0: PA=0xa, VA=0x8241, size=0x1, mode=0
> ...
> VT(vga): resolution 640x480
> Preloaded elf kernel "/boot/kernel/kernel" at 0x82278000.
> Preloaded boot_entropy_cache "/boot/entropy" at 0x822810d8.
> Preloaded elf obj module "/boot/kernel/filemon.ko" at 0x82281130.
> Calibrating TSC clock ... TSC clock: 3591758700 Hz
> CPU: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (3591.76-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x306c3  Family=0x6  Model=0x3c  Stepping=3
>   
> Features=0xbfebfbff
>   
> Features2=0x7ffafbff
>   AMD Features=0x2c100800
>   AMD Features2=0x21
>   Structured Extended
> Features=0x2fbb
>  XSAVE
> Features=0x1 VT-x: Basic Features=0xda0400
> Pin-Based Controls=0x7f
> Primary Processor
> Controls=0xfff9fffe
> Secondary Processor
> Controls=0x7cff
> Exit Controls=0xda0400 Entry Controls=0xda0400 EPT
> Features=0x6334141 VPID
> Features=0xf01 TSC: P-state 
> invariant,
> performance statistics Data TLB: 2 MByte or 4 MByte pages, 4-way set 
> associative, 32
> entries and a separate array with 1 GByte pages, 4-way set associative, 4 
> entries Data
> TLB: 4 KB pages, 4-way set associative, 64 entries Instruction TLB: 2M/4M 
> pages, fully
> associative, 8 entries Instruction TLB: 4KByte pages, 8-way set associative, 
> 64 entries
> 64-Byte prefetching
> Shared 2nd-Level TLB: 4 KByte/2MByte pages, 8-way associative, 1024 entries
> L2 cache: 256 kbytes, 8-way associative, 64 bytes/line
> real memory  = 34359738368 (32768 MB)
> Physical memory chunk(s):
> 0x0001 - 0x00099fff, 565248 bytes (138 pages)
> 0x0010 - 0x001f, 1048576 bytes (256 pages)
> 0x022c4000 - 0xcd1d3fff, 3404791808 bytes (831248 pages)
> 0xcd1db000 - 0xcda2cfff, 8724480 bytes (2130 pages)
> 0xcdcaa000 - 0xde036fff, 272158720 bytes (66445 pages)
> 0xde0c1000 - 0xde2a4fff, 1982464 bytes (484 pages)
> 0xdefff000 - 0xdeff, 4096 bytes (1 pages)
> 0x0001 - 0x0007eb4e2fff, 29717573632 bytes (7255267 pages)
> avail memory = 33300434944 (31757 MB)
> ...
> ACPI: Enabled 5 GPEs in block 00 to 3F
> random: harvesting attach, 8 bytes (4 bits) from acpi0
> random: harvesting attach, 8 bytes (4 bits) from apic0
> acpi0: wakeup code va 0xfe009b189000 pa 0x99000
> random: harvesting attach, 8 bytes (4 bits) from nexus0
> ahc_isa_identify 0: ioport 0xc00 alloc failed
> ahc_isa_identify 1: ioport 0x1c00 alloc failed
> ahc_isa_identify 2: ioport 0x2c00 alloc failed
> ahc_isa_identify 3: ioport 0x3c00 alloc failed
> ahc_isa_identify 4: ioport 0x4c00 alloc failed
> ahc_isa_identify 5: ioport 0x5c00 alloc failed
> ahc_isa_identify 6: ioport 0x6c00 alloc failed
> ahc_isa_identify 7: ioport 0x7c00 alloc failed
> ahc_isa_identify 8: ioport 0x8c00 alloc failed
> ahc_isa_identify 9: ioport 0x9c00 alloc failed
> ahc_isa_identify 10: ioport 0xac00 alloc failed
> ahc_isa_identify 11: ioport 0xbc00 alloc failed
> ahc_isa_identify 12: ioport 0xcc00 alloc failed
> ahc_isa_identify 13: ioport 0xdc00 alloc failed
> ahc_isa_identify 14: ioport 0xec00 alloc failed