Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-03 Thread Kyle Evans 
On Fri, Aug 3, 2018 at 10:10 PM, Eitan Adler  wrote:
> Hi all,
>
> After installing the latest current kernel I get the following panic:
>
> panic: mutex pmap not owned at ... efirt_machdep.c:255
> cpuid =3
> time = 1
> ...
> mtx_assert()
> efi_arch_enter()
> efirt_modevents()
> module_register_init()
> mi_startup()
> btext()
>

This seems odd- pmap lock is acquired at [1], then asserted shortly
later at [2]... I avoid some of this stuff as well as I can, but is it
actually possible for PCPU_GET(...) acquired curpmap to not match
curthread->td_proc->p_vmspace->vm_pmap in this context?

[1] https://svnweb.freebsd.org/base/head/sys/dev/efidev/efirt.c?view=markup#l260
[2] 
https://svnweb.freebsd.org/base/head/sys/amd64/amd64/efirt_machdep.c?view=markup#l254
___
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"

panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-03 Thread Eitan Adler 
Hi all,

After installing the latest current kernel I get the following panic:

panic: mutex pmap not owned at ... efirt_machdep.c:255
cpuid =3
time = 1
...
mtx_assert()
efi_arch_enter()
efirt_modevents()
module_register_init()
mi_startup()
btext()

Unfortunately this appears to be early enough that the keyboard is not usable.

I'll try to bisect this over the next few days unless someone has an
idea is to the exact cause.

-- 
Eitan Adler
___
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: GELI with UEFI supporting Boot Environments goes to HEAD when?

2018-08-03 Thread Ian Lepore 
On Fri, 2018-08-03 at 22:20 +0100, Warner Losh wrote:
> On Fri, Aug 3, 2018, 10:17 PM Tommi Pernila 
> wrote:
> 
> > 
> > 
> > 
> > On Fri, 3 Aug 2018 at 20.17, Warner Losh  wrote:
> > 
> > > 
[...]
> > Thank you all for your work on this!
> > 
> > *starts updating CURRENT install*
> > 
> Let us know of there is a problem...

And don't forget to do the often-skipped "mergemaster -p" step of the
updating before doing the installworld, to add the new ntpd user. :)

-- Ian
___
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: GELI with UEFI supporting Boot Environments goes to HEAD when?

2018-08-03 Thread Warner Losh 
On Fri, Aug 3, 2018, 10:17 PM Tommi Pernila  wrote:

>
>
> On Fri, 3 Aug 2018 at 20.17, Warner Losh  wrote:
>
>> On Fri, Aug 3, 2018, 5:58 PM Ian Lepore  wrote:
>>
>> > On Fri, 2018-08-03 at 19:54 +0300, Tommi Pernila wrote:
>> > > On Tue, 10 Jul 2018 at 1.05, Warner Losh  wrote:
>> > >
>> > > >
>> > > > I have this in my tree already...
>> > > >
>> > > > Warner
>> > > >
>> > > > On Mon, Jul 9, 2018, 10:28 AM Allan Jude 
>> > > > wrote:
>> > > >
>> > > > >
>> > > > > I will look at updating the rootgen.sh script this evening, to
>> > > > > support
>> > > > > creating more flexible ESP partitions, so we can drop the
>> > > > > loader.efi
>> > > > > into an msdosfs directly.
>> > > > >
>> > > > > On 07/08/2018 15:31, Ian Lepore wrote:
>> > > > > >
>> > > > > > On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote:
>> > > > > > >
>> > > > > > > Hi!
>> > > > > > >
>> > > > > > > Have you or Warner any update on this code?
>> > > > > > >
>> > > > > > > On Thursday, April 12, 2018, Eric McCorkle > > > > > > > net>
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > Are you aware of https://reviews.freebsd.org/D15743 ?
>> > > > > >
>> > > > > > That's my changes to add geli support to loader(8) in an
>> > > > > > architecture-
>> > > > > > agnostic way, so that "it just works" for all platforms and
>> > > > > > flavors of
>> > > > > > loader. It has been succesfully tested on armv6/7 (ubldr) and
>> > > > > > on x86
>> > > > > > using qemu.  The x86 tests cover ufs and zfs, legacy bios and
>> > > > > > uefi. The
>> > > > > > only variations that aren't tested yet are the uefi flavors,
>> > > > > > because
>> > > > > > the current rootgen.sh script for assembling test images is
>> > > > > > still using
>> > > > > > boot1.efi and I don't know enough about efi myself to update
>> > > > > > the script
>> > > > > > to make it assemble images the new way Warner envisions.
>> > > > > >
>> > > > > > -- Ian
>> > > > > >
>> > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > I'm in the middle of moving to a new apartment right
>> > > > > > > > now.  It's
>> > > > > > > > going to
>> > > > > > > > be a bit before I can get to this.
>> > > > > > > >
>> > > > > > > > On 04/11/2018 20:31, Warner Losh wrote:
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > OK. I've pushed in the main part of it. The additional
>> > > > > > > > > work I
>> > > > > > > > > have
>> > > > > > > > > shouldn't affect any of this stuff.  I was going to look
>> > > > > > > > > at what
>> > > > > > > > > part(s)
>> > > > > > > > > of your open reviewed needed to be redone tomorrow and
>> > > > > > > > > send you
>> > > > > > > > > feedback, but if you wanted to get a start before then,
>> > > > > > > > > I'm happy
>> > > > > > > > > to
>> > > > > > > > > answer questions. All the rest of my work is going to be
>> > > > > > > > > selecting the
>> > > > > > > > > root partition when we're told to us a specific
>> > > > > > > > > partition, so
>> > > > > > > > > will be
>> > > > > > > > > very constrained.
>> > > > > > > > >
>> > > > > > > > > Warner
>> > > > > > > > >
>> > > > > > > > > On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle > > > > > > > > > icspace.
>> > > > > > > > > net
>> > > > > > > > > > wrote:
>> > > > > > > > >
>> > > > > > > > >  I think the thing to do at this point is to wait for
>> > > > > > > > > the
>> > > > > > > > > current
>> > > > > > > > work on
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >  loader.efi to land, then adapt my patches to apply
>> > > > > > > > > against
>> > > > > > > > > that work.
>> > > > > > > > >
>> > > > > > > > >  On 04/11/2018 15:06, Warner Losh wrote:
>> > > > > > > > >  > Still reviewing the code. I'm worried it's too
>> > > > > > > > > i386
>> > > > > > > > > specific and it
>> > > > > > > > >  > conflicts with some work I'm doing. I'll have a
>> > > > > > > > > list of
>> > > > > > > > > actionable
>> > > > > > > > >  > critiques this week.
>> > > > > > > > >  >
>> > > > > > > > >  > Warner
>> > > > > > > > >  >
>> > > > > > > > >  > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter
>> > > > > > > > >  > > > > > > > > > >  
>> > > > > > > > >  > > > > > > > > >  >>
>> > > > > > > > >  > wrote:
>> > > > > > > > >  >
>> > > > > > > > >  > Hi!
>> > > > > > > > >  >
>> > > > > > > > >  > Is there any update regarding the rebase or
>> > > > > > > > > the
>> > > > > > > > > inclusion to
>> > > > > > > > base
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >  > system?
>> > > > > > > > >  > On 3/28/18, Eric McCorkle > > > > > > > > > t
>> > > > > > > > > > > > > > > > > e...@metricspace.net>
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >  > > > > > > > > > > icspace.n
>>

Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

2018-08-03 Thread Tommi Pernila 
On Fri, 3 Aug 2018 at 20.17, Warner Losh  wrote:

> On Fri, Aug 3, 2018, 5:58 PM Ian Lepore  wrote:
>
> > On Fri, 2018-08-03 at 19:54 +0300, Tommi Pernila wrote:
> > > On Tue, 10 Jul 2018 at 1.05, Warner Losh  wrote:
> > >
> > > >
> > > > I have this in my tree already...
> > > >
> > > > Warner
> > > >
> > > > On Mon, Jul 9, 2018, 10:28 AM Allan Jude 
> > > > wrote:
> > > >
> > > > >
> > > > > I will look at updating the rootgen.sh script this evening, to
> > > > > support
> > > > > creating more flexible ESP partitions, so we can drop the
> > > > > loader.efi
> > > > > into an msdosfs directly.
> > > > >
> > > > > On 07/08/2018 15:31, Ian Lepore wrote:
> > > > > >
> > > > > > On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote:
> > > > > > >
> > > > > > > Hi!
> > > > > > >
> > > > > > > Have you or Warner any update on this code?
> > > > > > >
> > > > > > > On Thursday, April 12, 2018, Eric McCorkle  > > > > > > net>
> > > > > > > wrote:
> > > > > > >
> > > > > > Are you aware of https://reviews.freebsd.org/D15743 ?
> > > > > >
> > > > > > That's my changes to add geli support to loader(8) in an
> > > > > > architecture-
> > > > > > agnostic way, so that "it just works" for all platforms and
> > > > > > flavors of
> > > > > > loader. It has been succesfully tested on armv6/7 (ubldr) and
> > > > > > on x86
> > > > > > using qemu.  The x86 tests cover ufs and zfs, legacy bios and
> > > > > > uefi. The
> > > > > > only variations that aren't tested yet are the uefi flavors,
> > > > > > because
> > > > > > the current rootgen.sh script for assembling test images is
> > > > > > still using
> > > > > > boot1.efi and I don't know enough about efi myself to update
> > > > > > the script
> > > > > > to make it assemble images the new way Warner envisions.
> > > > > >
> > > > > > -- Ian
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > I'm in the middle of moving to a new apartment right
> > > > > > > > now.  It's
> > > > > > > > going to
> > > > > > > > be a bit before I can get to this.
> > > > > > > >
> > > > > > > > On 04/11/2018 20:31, Warner Losh wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > OK. I've pushed in the main part of it. The additional
> > > > > > > > > work I
> > > > > > > > > have
> > > > > > > > > shouldn't affect any of this stuff.  I was going to look
> > > > > > > > > at what
> > > > > > > > > part(s)
> > > > > > > > > of your open reviewed needed to be redone tomorrow and
> > > > > > > > > send you
> > > > > > > > > feedback, but if you wanted to get a start before then,
> > > > > > > > > I'm happy
> > > > > > > > > to
> > > > > > > > > answer questions. All the rest of my work is going to be
> > > > > > > > > selecting the
> > > > > > > > > root partition when we're told to us a specific
> > > > > > > > > partition, so
> > > > > > > > > will be
> > > > > > > > > very constrained.
> > > > > > > > >
> > > > > > > > > Warner
> > > > > > > > >
> > > > > > > > > On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle  > > > > > > > > icspace.
> > > > > > > > > net
> > > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >  I think the thing to do at this point is to wait for
> > > > > > > > > the
> > > > > > > > > current
> > > > > > > > work on
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >  loader.efi to land, then adapt my patches to apply
> > > > > > > > > against
> > > > > > > > > that work.
> > > > > > > > >
> > > > > > > > >  On 04/11/2018 15:06, Warner Losh wrote:
> > > > > > > > >  > Still reviewing the code. I'm worried it's too
> > > > > > > > > i386
> > > > > > > > > specific and it
> > > > > > > > >  > conflicts with some work I'm doing. I'll have a
> > > > > > > > > list of
> > > > > > > > > actionable
> > > > > > > > >  > critiques this week.
> > > > > > > > >  >
> > > > > > > > >  > Warner
> > > > > > > > >  >
> > > > > > > > >  > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter
> > > > > > > > >  >  > > > > > > > >  
> > > > > > > > >   > > > > > > > >  >>
> > > > > > > > >  > wrote:
> > > > > > > > >  >
> > > > > > > > >  > Hi!
> > > > > > > > >  >
> > > > > > > > >  > Is there any update regarding the rebase or
> > > > > > > > > the
> > > > > > > > > inclusion to
> > > > > > > > base
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >  > system?
> > > > > > > > >  > On 3/28/18, Eric McCorkle  > > > > > > > > t
> > > > > > > > >  > > > > > > > e...@metricspace.net>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >  >  > > > > > > > > icspace.n
> > > > > > > > > et>>>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >  > > I'll do another rebase from head just to be
> > > > > > > > > sure
> > > > > > > >

Re: Linux process causes kernel panic

2018-08-03 Thread Johannes Lundberg 
On Fri, Aug 3, 2018 at 9:43 PM Konstantin Belousov 
wrote:

> On Fri, Aug 03, 2018 at 09:26:08PM +0100, Johannes Lundberg wrote:
> > Hi
> >
> > After install new kernel+world built from today's checkout I keep getting
> > the same crash over and over. Never had this problem before. The previous
> > kernel was from 3 weeks ago.
> >
> > Looks familiar to anyone?
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address= 0xfffe665c
> > fault code= supervisor write data, protection violation
> > instruction pointer= 0x20:0x82282db3
> > stack pointer= 0x0:0xfe004c74c8c8
> > frame pointer= 0x0:0xfe004c74c980
> > 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= 1579 (wcgrid_zika_vina_7.)
> > trap number= 12
> > panic: page fault
> > cpuid = 0
> > time = 1533327428
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfe004c74c580
> > vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0
> > panic() at panic+0x43/frame 0xfe004c74c640
> > trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690
> > trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0
> > trap() at trap+0x2ba/frame 0xfe004c74c7f0
> > calltrap() at calltrap+0x8/frame 0xfe004c74c7f0
> > --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp =
> > 0xfe004c74c980 ---
> > futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980
> > ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0
> > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
> > Uptime: 7m29s
> > Dumping 411 out of 8056
> MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94%
> > Dump complete
>
> Post first 40 lines from the verbose dmesg boot of your machine.
>


Table 'FACP' at 0xd970da80
Table 'APIC' at 0xd970db90
APIC: Found table at 0xd970db90
APIC: Using the MADT enumerator.
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #86 d2391fd58c4(master)-dirty: Fri Aug  3 10:57:46 BST
2018
root@jd:/usr/obj/usr/src/amd64.amd64/sys/JD amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM
6.0.1)
WARNING: WITNESS option enabled, expect reduced performance.
Table 'FACP' at 0xd970da80
Table 'APIC' at 0xd970db90
Table 'FPDT' at 0xd970dc18
Table 'FIDT' at 0xd970dc60
Table 'MCFG' at 0xd970dd00
Table 'HPET' at 0xd970dd40
Table 'SSDT' at 0xd970dd78
Table 'UEFI' at 0xd970e230
Table 'SSDT' at 0xd970e278
Table 'ASF!' at 0xd970eef8
Table 'SSDT' at 0xd970ef98
Table 'SSDT' at 0xd970f4b8
Table 'SSDT' at 0xd9710030
Table 'SSDT' at 0xd97101f8
Table 'PCCT' at 0xd97105a0
Table 'SSDT' at 0xd9710610
Table 'SSDT' at 0xd97110d8
Table 'SSDT' at 0xd9715288
Table 'SLIC' at 0xd9719790
Table 'MSDM' at 0xd9719908
Table 'DMAR' at 0xd9719960
Table 'BGRT' at 0xd9719a10
ACPI: No SRAT table found
PPIM 0: PA=0xe000, VA=0x81a1, size=0x7e9000, mode=0x1
VT(efifb): resolution 1920x1080
Preloaded elf kernel "/boot/kernel.JD/kernel" at 0x8186c000.
Preloaded boot_entropy_cache "/boot/entropy" at 0x81875e58.
Preloaded elf obj module "/boot/kernel.JD/snd_hda.ko" at 0x81875eb0.
Preloaded elf obj module "/boot/kernel.JD/ums.ko" at 0x81876560.
Table 'FACP' at 0xd970da80
FACP: Found table at 0xd970da80
Calibrating TSC clock ... TSC clock: 2194965386 Hz
CPU: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz (2194.97-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306d4  Family=0x6  Model=0x3d  Stepping=4

Features=0xbfebfbff

Features2=0x7ffafbbf
  AMD Features=0x2c100800
  AMD Features2=0x121
  Structured Extended
Features=0x21c27ab
  XSAVE Features=0x1
  VT-x: Basic Features=0xda0400
Pin-Based Controls=0x7f
Primary Processor
Controls=0xfff9fffe
Secondary Processor
Controls=0x53cff
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 /2 MByte pages, 6-way associative, 1536
entries. Also 1GBbyte pages, 4-way, 16 entries
L2 cache: 256 kbytes, 8-way associative, 64 bytes/line
real memory  = 8589934592 (8192 MB)
Physical memory chunk(s):
0x0001 - 0x00057fff,

Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of

2018-08-03 Thread John Baldwin 
I decided that it was better to fix our stdatomic.h, so I have a review
to do that at https://reviews.freebsd.org/D16585

-- 
John Baldwin
___
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: Linux process causes kernel panic

2018-08-03 Thread Konstantin Belousov 
On Fri, Aug 03, 2018 at 09:26:08PM +0100, Johannes Lundberg wrote:
> Hi
> 
> After install new kernel+world built from today's checkout I keep getting
> the same crash over and over. Never had this problem before. The previous
> kernel was from 3 weeks ago.
> 
> Looks familiar to anyone?
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address= 0xfffe665c
> fault code= supervisor write data, protection violation
> instruction pointer= 0x20:0x82282db3
> stack pointer= 0x0:0xfe004c74c8c8
> frame pointer= 0x0:0xfe004c74c980
> 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= 1579 (wcgrid_zika_vina_7.)
> trap number= 12
> panic: page fault
> cpuid = 0
> time = 1533327428
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe004c74c580
> vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0
> panic() at panic+0x43/frame 0xfe004c74c640
> trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690
> trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0
> trap() at trap+0x2ba/frame 0xfe004c74c7f0
> calltrap() at calltrap+0x8/frame 0xfe004c74c7f0
> --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp =
> 0xfe004c74c980 ---
> futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980
> ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0
> int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
> Uptime: 7m29s
> Dumping 411 out of 8056 MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94%
> Dump complete

Post first 40 lines from the verbose dmesg boot of your machine.

I have a guess what is going on, I need the dmesg to confirm.
If my guess is correct, you can use a workaround by setting the
"hw.cpu_stdext_disable=0x0010" tunable at the loader prompt for now.
___
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: Linux process causes kernel panic

2018-08-03 Thread Oliver Pinter 
On 8/3/18, Johannes Lundberg  wrote:
> On Fri, Aug 3, 2018 at 9:34 PM Oliver Pinter
> 
> wrote:
>
>> Hi!
>>
>> On 8/3/18, Johannes Lundberg  wrote:
>> > Hi
>> >
>> > After install new kernel+world built from today's checkout I keep
>> > getting
>> > the same crash over and over. Never had this problem before. The
>> > previous
>> > kernel was from 3 weeks ago.
>> >
>> > Looks familiar to anyone?
>>
>> Have you an Intel Broadwell or newer Intel CPU or an AMD CPU with SMAP
>> support?
>>
>
> This is Intel Broadwell, Core i5.

The smapification of amd64/linux/linux_support.s is missing from the SMAP patch.
CC kib@.

>
>
>> >
>> > Fatal trap 12: page fault while in kernel mode
>> > cpuid = 0; apic id = 00
>> > fault virtual address= 0xfffe665c
>> > fault code= supervisor write data, protection violation
>> > instruction pointer= 0x20:0x82282db3
>> > stack pointer= 0x0:0xfe004c74c8c8
>> > frame pointer= 0x0:0xfe004c74c980
>> > 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= 1579 (wcgrid_zika_vina_7.)
>> > trap number= 12
>> > panic: page fault
>> > cpuid = 0
>> > time = 1533327428
>> > KDB: stack backtrace:
>> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> > 0xfe004c74c580
>> > vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0
>> > panic() at panic+0x43/frame 0xfe004c74c640
>> > trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690
>> > trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0
>> > trap() at trap+0x2ba/frame 0xfe004c74c7f0
>> > calltrap() at calltrap+0x8/frame 0xfe004c74c7f0
>> > --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp =
>> > 0xfe004c74c980 ---
>> > futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980
>> > ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0
>> > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
>> > Uptime: 7m29s
>> > Dumping 411 out of 8056
>> > MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94%
>> > Dump complete
>> > ___
>> > 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"
>> >
>>
>
___
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: Linux process causes kernel panic

2018-08-03 Thread Johannes Lundberg 
On Fri, Aug 3, 2018 at 9:34 PM Oliver Pinter 
wrote:

> Hi!
>
> On 8/3/18, Johannes Lundberg  wrote:
> > Hi
> >
> > After install new kernel+world built from today's checkout I keep getting
> > the same crash over and over. Never had this problem before. The previous
> > kernel was from 3 weeks ago.
> >
> > Looks familiar to anyone?
>
> Have you an Intel Broadwell or newer Intel CPU or an AMD CPU with SMAP
> support?
>

This is Intel Broadwell, Core i5.


> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address= 0xfffe665c
> > fault code= supervisor write data, protection violation
> > instruction pointer= 0x20:0x82282db3
> > stack pointer= 0x0:0xfe004c74c8c8
> > frame pointer= 0x0:0xfe004c74c980
> > 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= 1579 (wcgrid_zika_vina_7.)
> > trap number= 12
> > panic: page fault
> > cpuid = 0
> > time = 1533327428
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfe004c74c580
> > vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0
> > panic() at panic+0x43/frame 0xfe004c74c640
> > trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690
> > trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0
> > trap() at trap+0x2ba/frame 0xfe004c74c7f0
> > calltrap() at calltrap+0x8/frame 0xfe004c74c7f0
> > --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp =
> > 0xfe004c74c980 ---
> > futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980
> > ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0
> > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
> > Uptime: 7m29s
> > Dumping 411 out of 8056
> > MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94%
> > Dump complete
> > ___
> > 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"
> >
>
___
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: Linux process causes kernel panic

2018-08-03 Thread Oliver Pinter 
Hi!

On 8/3/18, Johannes Lundberg  wrote:
> Hi
>
> After install new kernel+world built from today's checkout I keep getting
> the same crash over and over. Never had this problem before. The previous
> kernel was from 3 weeks ago.
>
> Looks familiar to anyone?

Have you an Intel Broadwell or newer Intel CPU or an AMD CPU with SMAP support?

>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address= 0xfffe665c
> fault code= supervisor write data, protection violation
> instruction pointer= 0x20:0x82282db3
> stack pointer= 0x0:0xfe004c74c8c8
> frame pointer= 0x0:0xfe004c74c980
> 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= 1579 (wcgrid_zika_vina_7.)
> trap number= 12
> panic: page fault
> cpuid = 0
> time = 1533327428
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe004c74c580
> vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0
> panic() at panic+0x43/frame 0xfe004c74c640
> trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690
> trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0
> trap() at trap+0x2ba/frame 0xfe004c74c7f0
> calltrap() at calltrap+0x8/frame 0xfe004c74c7f0
> --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp =
> 0xfe004c74c980 ---
> futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980
> ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0
> int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
> Uptime: 7m29s
> Dumping 411 out of 8056
> MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94%
> Dump complete
> ___
> 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"
>
___
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"

Linux process causes kernel panic

2018-08-03 Thread Johannes Lundberg 
Hi

After install new kernel+world built from today's checkout I keep getting
the same crash over and over. Never had this problem before. The previous
kernel was from 3 weeks ago.

Looks familiar to anyone?

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address= 0xfffe665c
fault code= supervisor write data, protection violation
instruction pointer= 0x20:0x82282db3
stack pointer= 0x0:0xfe004c74c8c8
frame pointer= 0x0:0xfe004c74c980
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= 1579 (wcgrid_zika_vina_7.)
trap number= 12
panic: page fault
cpuid = 0
time = 1533327428
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe004c74c580
vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0
panic() at panic+0x43/frame 0xfe004c74c640
trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690
trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0
trap() at trap+0x2ba/frame 0xfe004c74c7f0
calltrap() at calltrap+0x8/frame 0xfe004c74c7f0
--- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp =
0xfe004c74c980 ---
futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980
ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0
int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
Uptime: 7m29s
Dumping 411 out of 8056 MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94%
Dump complete
___
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: ntpd as ntpd user question

2018-08-03 Thread Pete Wright 



On 8/2/18 10:43 PM, Chris H wrote:
On Mon, 23 Jul 2018 12:57:28 +0200 "Niclas Zeising" 
 said



On 07/21/18 19:56, RW wrote:
> On Sat, 21 Jul 2018 11:14:45 -0600
> Ian Lepore wrote:
> > >> There's a "pre-world" stage of mergemaster (-Fp option I 
think) which

>> isn't needed often, but one of the times it is needed is apparently
>> when new user ids are added.
> > I wish mergemaster had an option to just add new users and groups,
> rather than merging the files.

etcupdate is usually pretty good at automatically merge updates to 
files without user interaction, even when the files are locally 
edited as well.  For instance, I had no problem merging 
/etc/master.passwd and /etc/group for the ntp change.

Regards
--
Niclas

FWIW I found mergemaster intimidating when I was first starting out. Not
because I didn't understand patch(1)/diff(1). I was well familiar there.
But I found it unintuitive. Despite the messages regarding it's usage.
Anyway. I finally developed a strategy that worked for me.
I start out with the standard

mergemaster -p

then the installworld
But I implement the following mergemster, thusly

mergemaster -vF

It dispenses with asking about all the files that only have revision
changes, and date differences, and just updates them, the -v portion,
just keeps "enlightened" as to wtf is actually happening during the
process.
Then all that's left are just some 5-9 files I need to deal with,
with mergemaster informing me that by default, it'll leave them
for me, to look at later. To which I reply Y. Done.
Knowing diff/patch, makes the resulting unmerged files a trivial
task, requiring perhaps 5-10 minutes while still at the console.
Then I reboot into the new system.



this certainly sums up my experience and workflow now.  if i were 
someone with more free time on my hands i'd look at adding an option to 
mergemaster to read in an env-var or the ~/.mergemasterrc file to use a 
diff program of choice.


i remember when i used to admin IRIX systems we would use xdiff 
frequently when updates of software required updates to configs, being a 
junior admin at the time and having a decent gui to manage diffs 
certainly made me feel more confident about the changes i was making.


but honestly this is such an edge case i haven't put any effort into 
hacking on this :)


-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: GELI with UEFI supporting Boot Environments goes to HEAD when?

2018-08-03 Thread Ian Lepore 
On Fri, 2018-08-03 at 19:54 +0300, Tommi Pernila wrote:
> On Tue, 10 Jul 2018 at 1.05, Warner Losh  wrote:
> 
> > 
> > I have this in my tree already...
> > 
> > Warner
> > 
> > On Mon, Jul 9, 2018, 10:28 AM Allan Jude 
> > wrote:
> > 
> > > 
> > > I will look at updating the rootgen.sh script this evening, to
> > > support
> > > creating more flexible ESP partitions, so we can drop the
> > > loader.efi
> > > into an msdosfs directly.
> > > 
> > > On 07/08/2018 15:31, Ian Lepore wrote:
> > > > 
> > > > On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote:
> > > > > 
> > > > > Hi!
> > > > > 
> > > > > Have you or Warner any update on this code?
> > > > > 
> > > > > On Thursday, April 12, 2018, Eric McCorkle  > > > > net>
> > > > > wrote:
> > > > > 
> > > > Are you aware of https://reviews.freebsd.org/D15743 ?
> > > > 
> > > > That's my changes to add geli support to loader(8) in an
> > > > architecture-
> > > > agnostic way, so that "it just works" for all platforms and
> > > > flavors of
> > > > loader. It has been succesfully tested on armv6/7 (ubldr) and
> > > > on x86
> > > > using qemu.  The x86 tests cover ufs and zfs, legacy bios and
> > > > uefi. The
> > > > only variations that aren't tested yet are the uefi flavors,
> > > > because
> > > > the current rootgen.sh script for assembling test images is
> > > > still using
> > > > boot1.efi and I don't know enough about efi myself to update
> > > > the script
> > > > to make it assemble images the new way Warner envisions.
> > > > 
> > > > -- Ian
> > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > I'm in the middle of moving to a new apartment right
> > > > > > now.  It's
> > > > > > going to
> > > > > > be a bit before I can get to this.
> > > > > > 
> > > > > > On 04/11/2018 20:31, Warner Losh wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > OK. I've pushed in the main part of it. The additional
> > > > > > > work I
> > > > > > > have
> > > > > > > shouldn't affect any of this stuff.  I was going to look
> > > > > > > at what
> > > > > > > part(s)
> > > > > > > of your open reviewed needed to be redone tomorrow and
> > > > > > > send you
> > > > > > > feedback, but if you wanted to get a start before then,
> > > > > > > I'm happy
> > > > > > > to
> > > > > > > answer questions. All the rest of my work is going to be
> > > > > > > selecting the
> > > > > > > root partition when we're told to us a specific
> > > > > > > partition, so
> > > > > > > will be
> > > > > > > very constrained.
> > > > > > > 
> > > > > > > Warner
> > > > > > > 
> > > > > > > On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle  > > > > > > icspace.
> > > > > > > net
> > > > > > > > wrote:
> > > > > > > 
> > > > > > >  I think the thing to do at this point is to wait for
> > > > > > > the
> > > > > > > current
> > > > > > work on
> > > > > > > 
> > > > > > > 
> > > > > > >  loader.efi to land, then adapt my patches to apply
> > > > > > > against
> > > > > > > that work.
> > > > > > > 
> > > > > > >  On 04/11/2018 15:06, Warner Losh wrote:
> > > > > > >  > Still reviewing the code. I'm worried it's too
> > > > > > > i386
> > > > > > > specific and it
> > > > > > >  > conflicts with some work I'm doing. I'll have a
> > > > > > > list of
> > > > > > > actionable
> > > > > > >  > critiques this week.
> > > > > > >  >
> > > > > > >  > Warner
> > > > > > >  >
> > > > > > >  > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter
> > > > > > >  >  > > > > > >  
> > > > > > >   > > > > > >  >>
> > > > > > >  > wrote:
> > > > > > >  >
> > > > > > >  > Hi!
> > > > > > >  >
> > > > > > >  > Is there any update regarding the rebase or
> > > > > > > the
> > > > > > > inclusion to
> > > > > > base
> > > > > > > 
> > > > > > > 
> > > > > > >  > system?
> > > > > > >  > On 3/28/18, Eric McCorkle  > > > > > > t
> > > > > > >  > > > > > e...@metricspace.net>
> > > > > > > 
> > > > > > > 
> > > > > > >  >  > > > > > > icspace.n
> > > > > > > et>>>
> > > > > > wrote:
> > > > > > > 
> > > > > > > 
> > > > > > >  > > I'll do another rebase from head just to be
> > > > > > > sure
> > > > > > >  > >
> > > > > > >  > > On March 28, 2018 3:23:23 PM EDT, Warner
> > > > > > > Losh <
> > > > > > i...@bsdimp.com 
> > > > > > > 
> > > > > > > 
> > > > > > >  > 
> > > > > > > >> wrote:
> > > > > > >  > >>It's on my list for nexr, finally. I have an
> > > > > > > alternate patch
> > > > > > for
> > > > > > > 
> > > > > > > 
> > > > > > >  > >>loader.efi
> > > > > > >  > >>from ESP, but i don't think it will affect
> > > > > > > the GELI
> > > > > > > stuff. I
> > > > > > have some
> > > > > >

Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

2018-08-03 Thread Warner Losh 
On Fri, Aug 3, 2018, 5:58 PM Ian Lepore  wrote:

> On Fri, 2018-08-03 at 19:54 +0300, Tommi Pernila wrote:
> > On Tue, 10 Jul 2018 at 1.05, Warner Losh  wrote:
> >
> > >
> > > I have this in my tree already...
> > >
> > > Warner
> > >
> > > On Mon, Jul 9, 2018, 10:28 AM Allan Jude 
> > > wrote:
> > >
> > > >
> > > > I will look at updating the rootgen.sh script this evening, to
> > > > support
> > > > creating more flexible ESP partitions, so we can drop the
> > > > loader.efi
> > > > into an msdosfs directly.
> > > >
> > > > On 07/08/2018 15:31, Ian Lepore wrote:
> > > > >
> > > > > On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote:
> > > > > >
> > > > > > Hi!
> > > > > >
> > > > > > Have you or Warner any update on this code?
> > > > > >
> > > > > > On Thursday, April 12, 2018, Eric McCorkle  > > > > > net>
> > > > > > wrote:
> > > > > >
> > > > > Are you aware of https://reviews.freebsd.org/D15743 ?
> > > > >
> > > > > That's my changes to add geli support to loader(8) in an
> > > > > architecture-
> > > > > agnostic way, so that "it just works" for all platforms and
> > > > > flavors of
> > > > > loader. It has been succesfully tested on armv6/7 (ubldr) and
> > > > > on x86
> > > > > using qemu.  The x86 tests cover ufs and zfs, legacy bios and
> > > > > uefi. The
> > > > > only variations that aren't tested yet are the uefi flavors,
> > > > > because
> > > > > the current rootgen.sh script for assembling test images is
> > > > > still using
> > > > > boot1.efi and I don't know enough about efi myself to update
> > > > > the script
> > > > > to make it assemble images the new way Warner envisions.
> > > > >
> > > > > -- Ian
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I'm in the middle of moving to a new apartment right
> > > > > > > now.  It's
> > > > > > > going to
> > > > > > > be a bit before I can get to this.
> > > > > > >
> > > > > > > On 04/11/2018 20:31, Warner Losh wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > OK. I've pushed in the main part of it. The additional
> > > > > > > > work I
> > > > > > > > have
> > > > > > > > shouldn't affect any of this stuff.  I was going to look
> > > > > > > > at what
> > > > > > > > part(s)
> > > > > > > > of your open reviewed needed to be redone tomorrow and
> > > > > > > > send you
> > > > > > > > feedback, but if you wanted to get a start before then,
> > > > > > > > I'm happy
> > > > > > > > to
> > > > > > > > answer questions. All the rest of my work is going to be
> > > > > > > > selecting the
> > > > > > > > root partition when we're told to us a specific
> > > > > > > > partition, so
> > > > > > > > will be
> > > > > > > > very constrained.
> > > > > > > >
> > > > > > > > Warner
> > > > > > > >
> > > > > > > > On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle  > > > > > > > icspace.
> > > > > > > > net
> > > > > > > > > wrote:
> > > > > > > >
> > > > > > > >  I think the thing to do at this point is to wait for
> > > > > > > > the
> > > > > > > > current
> > > > > > > work on
> > > > > > > >
> > > > > > > >
> > > > > > > >  loader.efi to land, then adapt my patches to apply
> > > > > > > > against
> > > > > > > > that work.
> > > > > > > >
> > > > > > > >  On 04/11/2018 15:06, Warner Losh wrote:
> > > > > > > >  > Still reviewing the code. I'm worried it's too
> > > > > > > > i386
> > > > > > > > specific and it
> > > > > > > >  > conflicts with some work I'm doing. I'll have a
> > > > > > > > list of
> > > > > > > > actionable
> > > > > > > >  > critiques this week.
> > > > > > > >  >
> > > > > > > >  > Warner
> > > > > > > >  >
> > > > > > > >  > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter
> > > > > > > >  >  > > > > > > >  
> > > > > > > >   > > > > > > >  >>
> > > > > > > >  > wrote:
> > > > > > > >  >
> > > > > > > >  > Hi!
> > > > > > > >  >
> > > > > > > >  > Is there any update regarding the rebase or
> > > > > > > > the
> > > > > > > > inclusion to
> > > > > > > base
> > > > > > > >
> > > > > > > >
> > > > > > > >  > system?
> > > > > > > >  > On 3/28/18, Eric McCorkle  > > > > > > > t
> > > > > > > >  > > > > > > e...@metricspace.net>
> > > > > > > >
> > > > > > > >
> > > > > > > >  >  > > > > > > > icspace.n
> > > > > > > > et>>>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >  > > I'll do another rebase from head just to be
> > > > > > > > sure
> > > > > > > >  > >
> > > > > > > >  > > On March 28, 2018 3:23:23 PM EDT, Warner
> > > > > > > > Losh <
> > > > > > > i...@bsdimp.com 
> > > > > > > >
> > > > > > > >
> > > > > > > >  > 
> > > > > > > > >> wrote:
> > > > > > > >  >

Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

2018-08-03 Thread Tommi Pernila 
On Tue, 10 Jul 2018 at 1.05, Warner Losh  wrote:

> I have this in my tree already...
>
> Warner
>
> On Mon, Jul 9, 2018, 10:28 AM Allan Jude  wrote:
>
>> I will look at updating the rootgen.sh script this evening, to support
>> creating more flexible ESP partitions, so we can drop the loader.efi
>> into an msdosfs directly.
>>
>> On 07/08/2018 15:31, Ian Lepore wrote:
>> > On Sun, 2018-07-08 at 21:08 +0200, Oliver Pinter wrote:
>> >> Hi!
>> >>
>> >> Have you or Warner any update on this code?
>> >>
>> >> On Thursday, April 12, 2018, Eric McCorkle 
>> >> wrote:
>> >>
>> >
>> > Are you aware of https://reviews.freebsd.org/D15743 ?
>> >
>> > That's my changes to add geli support to loader(8) in an architecture-
>> > agnostic way, so that "it just works" for all platforms and flavors of
>> > loader. It has been succesfully tested on armv6/7 (ubldr) and on x86
>> > using qemu.  The x86 tests cover ufs and zfs, legacy bios and uefi. The
>> > only variations that aren't tested yet are the uefi flavors, because
>> > the current rootgen.sh script for assembling test images is still using
>> > boot1.efi and I don't know enough about efi myself to update the script
>> > to make it assemble images the new way Warner envisions.
>> >
>> > -- Ian
>> >
>> >>>
>> >>> I'm in the middle of moving to a new apartment right now.  It's
>> >>> going to
>> >>> be a bit before I can get to this.
>> >>>
>> >>> On 04/11/2018 20:31, Warner Losh wrote:
>> 
>>  OK. I've pushed in the main part of it. The additional work I
>>  have
>>  shouldn't affect any of this stuff.  I was going to look at what
>>  part(s)
>>  of your open reviewed needed to be redone tomorrow and send you
>>  feedback, but if you wanted to get a start before then, I'm happy
>>  to
>>  answer questions. All the rest of my work is going to be
>>  selecting the
>>  root partition when we're told to us a specific partition, so
>>  will be
>>  very constrained.
>> 
>>  Warner
>> 
>>  On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle >  net
>>  > wrote:
>> 
>>   I think the thing to do at this point is to wait for the
>>  current
>> >>> work on
>> 
>>   loader.efi to land, then adapt my patches to apply against
>>  that work.
>> 
>>   On 04/11/2018 15:06, Warner Losh wrote:
>>   > Still reviewing the code. I'm worried it's too i386
>>  specific and it
>>   > conflicts with some work I'm doing. I'll have a list of
>>  actionable
>>   > critiques this week.
>>   >
>>   > Warner
>>   >
>>   > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter
>>   > >   
>>   >   >>
>>   > wrote:
>>   >
>>   > Hi!
>>   >
>>   > Is there any update regarding the rebase or the
>>  inclusion to
>> >>> base
>> 
>>   > system?
>>   > On 3/28/18, Eric McCorkle >  > >>> e...@metricspace.net>
>> 
>>   > >  et>>>
>> >>> wrote:
>> 
>>   > > I'll do another rebase from head just to be sure
>>   > >
>>   > > On March 28, 2018 3:23:23 PM EDT, Warner Losh <
>> >>> i...@bsdimp.com 
>> 
>>   > >> wrote:
>>   > >>It's on my list for nexr, finally. I have an
>>  alternate patch
>> >>> for
>> 
>>   > >>loader.efi
>>   > >>from ESP, but i don't think it will affect the GELI
>>  stuff. I
>> >>> have some
>> 
>>   > >>time
>>   > >>slotted for integration issues though.
>>   > >>
>>   > >>I am quite mindful of the freeze dates I  have
>>  some uefi
>> >>> boot
>> 
>>   > >>loader
>>   > >>protocol changes that I need to get in.
>>   > >>
>>   > >>Warner
>>   > >>
>>   > >>On Feb 21, 2018 11:18 PM, "Tommi Pernila" <
>> >>> tommi.pern...@iki.fi 
>> 
>>   > >  fi>>>
>> >>> wrote:
>> 
>>   > >>
>>   > >>> Awesome, thanks for the update and the work that
>>  you have
>> >>> done!
>> 
>>   > >>>
>>   > >>> Now we just need some more reviewers eyes on the
>>  code :)
>>   > >>>
>>   > >>> Br,
>>   > >>>
>>   > >>> Tommi
>>   > >>>
>>   > >>> On Thu, 22 Feb 2018 at 2.03, Eric McCorkle <
>> >>> e...@metricspace.net 
>> 
>>   >

Re: ntpd user/group issue

2018-08-03 Thread Ian Lepore 
On Fri, 2018-08-03 at 10:31 +0300, Daniel Braniss wrote:
> Hi,
> I am cross compiling, which means i’m using for example an 11.1 to
> compile current, for
> another host - an image which is different from the one i'm using to
> compile.
> 
> make install checks for ntpd in /etc, instead, should it look
> elsewhere? DESTDIR perhaps?
> 
> cheers,
>   danny
> 

Add -DDB_FROM_SRC to the make command when you're installing, to work
around this. Fixing the build system to automatically do so isn't as
easy as you might think, but I've been working on it in slow motion.

-- Ian
___
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: Unable to UEFI boot 11.2 via pxeboot

2018-08-03 Thread Timo Völker 
> On 3. Aug 2018, at 10:17, Toomas Soome  wrote:
> 
> 
> 
>> On 3 Aug 2018, at 10:28, Timo Völker  wrote:
>> 
>> Hi Toomas,
>> 
>> it seems your fix works here. Some of the error messages remain, but I was 
>> able to (pxe)boot without a USB stick plugged in.
>> 
>> https://ibb.co/g8Bkfe
>> 
>> Right after the moment from the screenshot, the FreeBSD boot manager showed 
>> up.
>> 
>> Thanks,
>> 
>> Timo
> 
> Ok, so far so good. As seen from the screen dump, some cleanup is required, I 
> do not think we should print about efipart_inithandles() in case of errno 2 - 
> thats perfectly normal case if there are no block devices. Update commited:)
> 
> rgds,
> toomas

It still works and it looks better with less error messages :-)

https://ibb.co/bVv9Oz

Thanks,

Timo

> 
>> 
>>> On 2. Aug 2018, at 14:45, Toomas Soome  wrote:
>>> 
>>> Could you check the current with 
>>> https://svnweb.freebsd.org/changeset/base/337131
>>> 
>>> thanks,
>>> toomas
>>> 
 On 2 Aug 2018, at 15:32, Toomas Soome  wrote:
 
 
 
> On 2 Aug 2018, at 15:08, Timo Völker  wrote:
> 
> It seems this issue is related to current as well. I did a quick test and 
> got this output, while I tried to (pxe)boot FreeBSD current (without a 
> USB stick plugged in)
> 
> https://ibb.co/no8Fve
> 
> Best regards
> 
> Timo
 
 the hint is about efipart_inithandles() returning 2, thats errno code for 
 ENOENT. congratz, you have hit the corner case:D
 
 Since efinet_dev is part of devsw, we can not skip the devswitch init with 
 such error, we still need to walk the list. Let me see if I can provide 
 quick fix.
 
 rgds,
 toomas
 
 
> 
>> On 31. Jul 2018, at 14:16, Timo Völker  
>> wrote:
>> 
>> Hi,
>> 
>> I'm unable to boot up the amd64 11.2 via pxeboot using UEFI on a Dell 
>> PowerEdge R430. I get this output
>> 
>> https://ibb.co/h5ntuT
>> 
>> If I press a key to interrupt reboot, I get to the OK prompt. If I enter 
>> lsdev -v, it prints nothing more than "net devices:". The variable 
>> currdev is not set (show currdev prints variable 'currdev' not found). I 
>> configured pxeboot to be the one and only boot medium in BIOS setup. 
>> 
>> However, I found a workaround that works for me. If I put an (empty) USB 
>> stick in a USB port of the PowerEdge, it successfully boots via pxeboot 
>> (which is still the one and only configured boot medium). I then get 
>> this output
>> 
>> https://ibb.co/mU8SM8
>> 
>> With FreeBSD 11.1 pxeboot worked on the Dell PowerEdge R430, even 
>> without a USB stick plugged in. I couldn't test this with FreeBSD 
>> 12-current. Hope this helps anyway to find an open issue.
>> 
>> I found this thread which seems to be related.
>> 
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-July/070082.html
>> 
>> Thanks,
>> 
>> Timo
> 
 
>>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Status of OpenSSL 1.1.1

2018-08-03 Thread Eric McCorkle 
On 08/03/2018 04:44, Warner Losh wrote:
> 
> 
> On Thu, Aug 2, 2018 at 5:45 PM, Benjamin Kaduk  > wrote:
> 
> On Wed, Aug 01, 2018 at 10:05:28AM -0400, Eric McCorkle wrote:
> > On 08/01/2018 09:02, Warner Losh wrote:
> > >
> > >
> > > On Wed, Aug 1, 2018, 12:31 PM Eric McCorkle
> mailto:e...@metricspace.net>
> > > >> wrote:
> > >
> > >     Hi folks,
> > >
> > >     I'm wondering what's the status of OpenSSL 1.1.1 integration
> into base?
> > >     More specifically, is there a repo or a branch that's
> started the
> > >     integration?  I'm aware of the wiki page and the list of
> port build
> > >     issues, but that seems to be based on replacing the base
> OpenSSL with a
> > >     port build (similar to the way one replaces it with LibreSSL).
> > >
> > >     I have some work I'd like to do that's gating on sorting out the
> > >     kernel/loader crypto situation, and I'd very much like to
> see OpenSSL
> > >     1.1.1 get merged, so I can start to look into doing that.
> > >
> > >
> > > There are patches to use bear SSL for the loader. OpenSSL is
> simply too
> > > large to use due to limits the loader operates under.
> >
> > I was going to look into the feasibility of doing something like what
> > LibreSSL does with portable, where they extract a subset of the full
> > library designed to be embedded in the kernel, loader, etc.
> >
> > I think it ought to be possible to do something like that, but it
> really
> > ought to be done in a tree with 1.1.1 integrated.
> >
> 
> It wouldn't be terribly easy or effective, IMO.  OpenSSL wasn't designed
> with such modularity in mind.
> 
> 
> Others that have tried have found OpenSSL to be way too large for the
> boot loader and a completely impossible to subset enough to get things
> small enough due to the intertwingled nature of things.

To what extent, if any, does this change in 1.1.1, though?



signature.asc
Description: OpenPGP digital signature

Re: Status of OpenSSL 1.1.1

2018-08-03 Thread Warner Losh 
On Thu, Aug 2, 2018 at 5:45 PM, Benjamin Kaduk  wrote:

> On Wed, Aug 01, 2018 at 10:05:28AM -0400, Eric McCorkle wrote:
> > On 08/01/2018 09:02, Warner Losh wrote:
> > >
> > >
> > > On Wed, Aug 1, 2018, 12:31 PM Eric McCorkle  > > > wrote:
> > >
> > > Hi folks,
> > >
> > > I'm wondering what's the status of OpenSSL 1.1.1 integration into
> base?
> > > More specifically, is there a repo or a branch that's started the
> > > integration?  I'm aware of the wiki page and the list of port build
> > > issues, but that seems to be based on replacing the base OpenSSL
> with a
> > > port build (similar to the way one replaces it with LibreSSL).
> > >
> > > I have some work I'd like to do that's gating on sorting out the
> > > kernel/loader crypto situation, and I'd very much like to see
> OpenSSL
> > > 1.1.1 get merged, so I can start to look into doing that.
> > >
> > >
> > > There are patches to use bear SSL for the loader. OpenSSL is simply too
> > > large to use due to limits the loader operates under.
> >
> > I was going to look into the feasibility of doing something like what
> > LibreSSL does with portable, where they extract a subset of the full
> > library designed to be embedded in the kernel, loader, etc.
> >
> > I think it ought to be possible to do something like that, but it really
> > ought to be done in a tree with 1.1.1 integrated.
> >
>
> It wouldn't be terribly easy or effective, IMO.  OpenSSL wasn't designed
> with such modularity in mind.
>

Others that have tried have found OpenSSL to be way too large for the boot
loader and a completely impossible to subset enough to get things small
enough due to the intertwingled nature of things.

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: EFI issues

2018-08-03 Thread Warner Losh 
On Sun, Jul 29, 2018 at 6:35 AM, O. Hartmann  wrote:

> > > > 'efibootmgr -v' output:
> > > >
> > > > BootCurrent: 0004
> > > > Timeout: 1 seconds
> > > > BootOrder  : 0001, 0002, 0003, 0004
> > > >  Boot0001* Hard Drive  BBS(HD,,0x0)
> > > >  Boot0002* Network Card  BBS(Network,,0x0)
> > > >  Boot0003* UEFI OS
> > > > HD(1,GPT,78459ec0-9303-11e8-97e6-98ded0009b1c,0x28,
> 0x64000)/File(\EFI\BOOT\BOOTX64.EFI)
> > > > ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
> > > > Path(0,0,ae84b11df581724e85442bab0c2cac5c0202) +Boot0004*
> UEFI: SanDisk
> > > > PciRoot(0x0)/Pci(0x1d,0x0)/USB(0x1,0x0)/USB(0x4,0x0)/HD(
> 1,MBR,0x90909090,0x1,0x640)
> > > > VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,
> 530061006e004400690073006b00)
>
...

> > I've updated BIOS (which alone didn't change anything) and executed
> > commands you suggested, and it helped! Thanks!
> >
> > Now 'efibootmgr -v' output looks like this:
> >
> > BootCurrent: 
> > Timeout: 1 seconds
> > BootOrder  : , 0004, 0006, 0003, 0007
> > +Boot* FreeBSD
> > HD(1,GPT,78459ec0-9303-11e8-97e6-98ded0009b1c,0x28,
> 0x64000)/File(\efi\boot\BOOTx64.efi)
> > ada0p1:/efi/boot/BOOTx64.efi (null) Boot0004* Hard Drive  BBS(HD,,0x0)
> >  Boot0006* Network Card  BBS(Network,,0x0)
> >  Boot0003* UEFI OS
> > HD(1,GPT,78459ec0-9303-11e8-97e6-98ded0009b1c,0x28,
> 0x64000)/File(\EFI\BOOT\BOOTX64.EFI)
> > ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
> > Path(0,0,ef47642dc93ba041ac194d51d01b4ce65200650061006c00740065006b00
> 200042006f006f00740020004100670065006e007400)
> > Boot0007* UEFI: SanDisk
> > PciRoot(0x0)/Pci(0x14,0x0)/USB(0x9,0x0)/HD(1,MBR,0x90909090,0x1,0x640)
> > VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,
> 340043003500330031003000300031003500340031003000310035003100
> 30003900300039003500)
> >
> >
> > Unreferenced Variables:
> >
> > This is strange, because the only difference I see is that Boot has
> > lowercase filenames ('/efi/boot/BOOTx64.efi' vs
> > '/EFI/BOOT/BOOTX64.EFI'). I'm wondering if that's the only reason it
> > wasn't working before?
> >
> > > - --
> > > O. Hartmann
> [...]
>
> >
> > Roman Bogorodskiy
>
> I'm glad to be of help. But it was a "wild guess", not experience or
> decend knowledge.
> Maybe there is an issue with recent UEFI/boot/stand implementation since
> this portion of
> FreeBSD is under heavy development or has been under such ...
>
> Ypu shpuld consider contacting Warner Losh or Toomas Soome (on the current@
> list, there
> is a thread entitelt "[UEFI] Boot issues on some UEFI implementations"
> started by myself
> targetting some weird FreeBSD/UEFI issues. Toomas Soome gave me the hint
> with
> efibootmgr(8) and I figured out by learning from the definitions, that on
> specific UEFI
> implementations, the boot path "/efi/boot/bootx64.efi" is considered the
> default for
> changeable media (like USB flash drives) and not necessaryly the default
> for SATA/SAS
> devices.


Case shouldn't matter. If it does, I've done something wrong. Internally,
we convert to lower case and the filesystem is case insensitive in this
case.

The whole default file thing is something I thought I understood really,
really well, but it's becoming clear that there's issues that are clear as
mud. We should be coping with this junk in the installer...

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: Unable to UEFI boot 11.2 via pxeboot

2018-08-03 Thread Toomas Soome 


> On 3 Aug 2018, at 10:28, Timo Völker  wrote:
> 
> Hi Toomas,
> 
> it seems your fix works here. Some of the error messages remain, but I was 
> able to (pxe)boot without a USB stick plugged in.
> 
> https://ibb.co/g8Bkfe
> 
> Right after the moment from the screenshot, the FreeBSD boot manager showed 
> up.
> 
> Thanks,
> 
> Timo

Ok, so far so good. As seen from the screen dump, some cleanup is required, I 
do not think we should print about efipart_inithandles() in case of errno 2 - 
thats perfectly normal case if there are no block devices. Update commited:)

rgds,
toomas


> 
>> On 2. Aug 2018, at 14:45, Toomas Soome  wrote:
>> 
>> Could you check the current with 
>> https://svnweb.freebsd.org/changeset/base/337131
>> 
>> thanks,
>> toomas
>> 
>>> On 2 Aug 2018, at 15:32, Toomas Soome  wrote:
>>> 
>>> 
>>> 
 On 2 Aug 2018, at 15:08, Timo Völker  wrote:
 
 It seems this issue is related to current as well. I did a quick test and 
 got this output, while I tried to (pxe)boot FreeBSD current (without a USB 
 stick plugged in)
 
 https://ibb.co/no8Fve
 
 Best regards
 
 Timo
>>> 
>>> the hint is about efipart_inithandles() returning 2, thats errno code for 
>>> ENOENT. congratz, you have hit the corner case:D
>>> 
>>> Since efinet_dev is part of devsw, we can not skip the devswitch init with 
>>> such error, we still need to walk the list. Let me see if I can provide 
>>> quick fix.
>>> 
>>> rgds,
>>> toomas
>>> 
>>> 
 
> On 31. Jul 2018, at 14:16, Timo Völker  
> wrote:
> 
> Hi,
> 
> I'm unable to boot up the amd64 11.2 via pxeboot using UEFI on a Dell 
> PowerEdge R430. I get this output
> 
> https://ibb.co/h5ntuT
> 
> If I press a key to interrupt reboot, I get to the OK prompt. If I enter 
> lsdev -v, it prints nothing more than "net devices:". The variable 
> currdev is not set (show currdev prints variable 'currdev' not found). I 
> configured pxeboot to be the one and only boot medium in BIOS setup. 
> 
> However, I found a workaround that works for me. If I put an (empty) USB 
> stick in a USB port of the PowerEdge, it successfully boots via pxeboot 
> (which is still the one and only configured boot medium). I then get this 
> output
> 
> https://ibb.co/mU8SM8
> 
> With FreeBSD 11.1 pxeboot worked on the Dell PowerEdge R430, even without 
> a USB stick plugged in. I couldn't test this with FreeBSD 12-current. 
> Hope this helps anyway to find an open issue.
> 
> I found this thread which seems to be related.
> 
> https://lists.freebsd.org/pipermail/freebsd-current/2018-July/070082.html
> 
> Thanks,
> 
> Timo
 
>>> 
>> 
> 

___
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"

ntpd user/group issue

2018-08-03 Thread Daniel Braniss 
Hi,
I am cross compiling, which means i’m using for example an 11.1 to compile 
current, for
another host - an image which is different from the one i'm using to compile.

make install checks for ntpd in /etc, instead, should it look elsewhere? 
DESTDIR perhaps?

cheers,
danny

___
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: Unable to UEFI boot 11.2 via pxeboot

2018-08-03 Thread Timo Völker 
Hi Toomas,

it seems your fix works here. Some of the error messages remain, but I was able 
to (pxe)boot without a USB stick plugged in.

https://ibb.co/g8Bkfe

Right after the moment from the screenshot, the FreeBSD boot manager showed up.

Thanks,

Timo

> On 2. Aug 2018, at 14:45, Toomas Soome  wrote:
> 
> Could you check the current with 
> https://svnweb.freebsd.org/changeset/base/337131
> 
> thanks,
> toomas
> 
>> On 2 Aug 2018, at 15:32, Toomas Soome  wrote:
>> 
>> 
>> 
>>> On 2 Aug 2018, at 15:08, Timo Völker  wrote:
>>> 
>>> It seems this issue is related to current as well. I did a quick test and 
>>> got this output, while I tried to (pxe)boot FreeBSD current (without a USB 
>>> stick plugged in)
>>> 
>>> https://ibb.co/no8Fve
>>> 
>>> Best regards
>>> 
>>> Timo
>> 
>> the hint is about efipart_inithandles() returning 2, thats errno code for 
>> ENOENT. congratz, you have hit the corner case:D
>> 
>> Since efinet_dev is part of devsw, we can not skip the devswitch init with 
>> such error, we still need to walk the list. Let me see if I can provide 
>> quick fix.
>> 
>> rgds,
>> toomas
>> 
>> 
>>> 
 On 31. Jul 2018, at 14:16, Timo Völker  wrote:
 
 Hi,
 
 I'm unable to boot up the amd64 11.2 via pxeboot using UEFI on a Dell 
 PowerEdge R430. I get this output
 
 https://ibb.co/h5ntuT
 
 If I press a key to interrupt reboot, I get to the OK prompt. If I enter 
 lsdev -v, it prints nothing more than "net devices:". The variable currdev 
 is not set (show currdev prints variable 'currdev' not found). I 
 configured pxeboot to be the one and only boot medium in BIOS setup. 
 
 However, I found a workaround that works for me. If I put an (empty) USB 
 stick in a USB port of the PowerEdge, it successfully boots via pxeboot 
 (which is still the one and only configured boot medium). I then get this 
 output
 
 https://ibb.co/mU8SM8
 
 With FreeBSD 11.1 pxeboot worked on the Dell PowerEdge R430, even without 
 a USB stick plugged in. I couldn't test this with FreeBSD 12-current. Hope 
 this helps anyway to find an open issue.
 
 I found this thread which seems to be related.
 
 https://lists.freebsd.org/pipermail/freebsd-current/2018-July/070082.html
 
 Thanks,
 
 Timo
>>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature