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

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

2017-12-24 Thread David Wolfskill 
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
pcib0: allocated type 3 (0xb-0xb07ff) for rid 0 of orm0
pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0
...
pcib0: allocated type 3 (0xe7000-0xe77ff) for rid 0 of orm0
pcib0: allocated type 3 (0xe7800-0xe7fff) for rid 0 of

Re: UEFI booting survey

2017-12-24 Thread Arno de Vries 
On Sun, Dec 17, 2017 at 8:52 PM, Warner Losh  wrote:

> Greetings
>
> If you are booting off UEFI and have a bit of an unusual setup, I'd like
> you to drop me a line.
>
> The setup that I'm looking for is any case where you load boot1.efi off one
> drive (cd, ssd, hdd, nvme, etc), but don't have a FreeBSD system on that
> drive, but on a different drive on the system.
>
> An example of this may be loading boot1.efi off what FreeBSD would call
> /dev/ada0p1, but having root come from /dev/ada1p1.
>
> It's my belief that due to the fragility of this setup, few, if any, people
> have this setup. If you do, please take a minute to reply to this message.
> In the coming months, we're looking at dropping boot1.efi and instead
> installing /boot/loader.efi onto the ESP (most likely as
> \efi\freebsd\loader.efi). As part of the move to fully support the UEFI
> Boot Manager, we're dropping the 'search every device in the system' part
> of the current boot1 algorithm. It will be possible to configure the system
> to continue booting (either via the new efibootmgr which will allow any
> imaginable combination, or possibly via a fallback mechanism needed for the
> embedded EFIs that have poor UEFI Variable support at the moment), but as
> part of an upgrade to a future FreeBSD 12, some intervention will be
> necessary.
>
> Please let me know if you have an unusual setup like this.
>
> Warner
>

I use something similar in FreeBSD 11.1 .
I boot from an USB drive with an EFI partition and an UFS partition
containing only a modified loader.efi, loader.help,loader.conf and loader.rc
The reason is I came from a BIOS system with a root raidz pool on raw
disks.
and my new motherboard no longer supported legacy boot.

I had to modify loader.efi because it only probes partitions for zfs pools,
not disks (also see bug report 220105).
For those interested: comment out the 'continue' on
line 123 in /sys/boot/efi/libefi/efipart.c (r 313355)

I used info form
https://lists.freebsd.org/pipermail/freebsd-hackers/2015-August/048141.html
to get it booting.

Arno


Virusvrij.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
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"