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

[Tommi Pernila]

excellent, thanks again for all your work.

On Wed, 28 Mar 2018 at 22.25, Eric McCorkle  wrote:

> I'll do another rebase from head just to be sure
>
> On March 28, 2018 3:23:23 PM EDT, Warner Losh  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"  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  wrote:
>>>
 FYI, I just IFC'ed everything, and the current patches are still fine.

 Also, the full GELI + standalone loader has been deployed on one of my
 laptops for some time now.

 On 02/21/2018 18:15, Eric McCorkle wrote:
 > The GELI work could be merged at this point, though it won't be usable
 > without an additional patch to enable loader-only operation.  The
 > patches are currently up for review:
 >
 > This is the order in which they'd need to be merged:
 >
 >
 > https://reviews.freebsd.org/D12732
 >
 > This one changes the efipart device.  Toomas Soome identified some
 > problems, which I have addressed.  He has not re-reviewed it, however.
 >
 >
 > https://reviews.freebsd.org/D12692
 >
 > This adds some crypto code needed for GELI.  It simply adds new code,
 > and doesn't conflict with anything.
 >
 >
 > https://reviews.freebsd.org/D12698
 >
 > This adds the EFI KMS interface code, and has the EFI loader pass keys
 > into the keybuf interface.
 >
 >
 > I can't post the main GELI driver until those get merged, as it
 depends
 > on them.  It can be found on the geli branch on my github freebsd
 > repository, however.
 >
 >
 > Additionally, you need this patch, which allows loader.efi to function
 > when installed directly to the ESP:
 >
 > https://reviews.freebsd.org/D13497
 >
 > On 02/20/2018 22:56, Tommi Pernila wrote:
 >> Hi Eric,
 >>
 >> could you provide a brief update how the work is going?
 >>
 >>
 >> Br,
 >>
 >> Tommi
 >>
 >>
 >> On Nov 16, 2017 04:29, "Eric McCorkle" > > wrote:
 >>
 >> Right, so basically, the remaining GELI patches are against
 loader, and
 >> most of them can go in independently of the work on removing
 boot1.
 >> There's a unanimous consensus on getting rid of boot1 which
 includes its
 >> original author, so that's going to happen.
 >>
 >>
 >> For GELI, we have the following (not necessarily in order):
 >>
 >> a) Adding the KMS interfaces, pseudo-device, and kernel keybuf
 >> interactions
 >> b) Modifications to the efipart driver
 >> c) boot crypto
 >> d) GELI partition types (not strictly necessary)
 >>
 >> Then there's the GELI driver itself.  (a) and (c) are good to
 land, (b)
 >> needs some more work after Toomas Soome pointed out a legitimate
 >> problem, and (d) actually needs a good bit more code (but again,
 it's
 >> more cosmetic).  Additionally, the GELI driver will need further
 mods to
 >> efipart to be written (nothing too big).  But we could go ahead
 with (a)
 >> and (c), as they've already been proven to work.
 >>
 >> I'd wanted to have this stuff shaped up sooner, but I'm
 preoccupied with
 >> the 7th RISC-V workshop at the end of the month.
 >>
 >> Once this stuff is all in, loader should handle any GELI volumes
 it
 >> finds, and it should Just Work once boot1 is gone.
 >>
 >>
 > ___
 > 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"
 >

>>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
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: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message)

[Sean Fertile]

___
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: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message)

[Mark Millard]

Sean Fertile's messages are showing up empty on the list.
So I'm just forwarding the two that I've gotten to the lists
(and not the individuals). I think they stand fairly well on
their own, so no other message history is included.

On 2018-Mar-28, at 3:08 PM, Sean Fertile  wrote:

> This is specifically the V1 abi support in the 64-bit PowerPC target in lld.  
> I'm definitely guilty of conflating big-endian with V1-abi and little-endian 
> with V2-abi. I wasn't aware of people using the V2 abi on big-endian 
> machines. We can make sure to test big-endian in lit tests as we deliver 
> support for the V2 abi, but its unlikely I'll be able to run big-endian 
> programs on actual hardware . I agree that we should keep it simple to add 
> back the V1 abi support.
>  
> Sean

On 03/28/18 11:22, Sean Fertile wrote:
> Hi Mark,
>  
> Just so we are clear this is about V1 abi support in lld, not in llvm. The 
> compiler will still be able to produce valid code for big-endian ppc64.
>  
> Regards
> Sean


 
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message)

[Sean Fertile]

___
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: Boot failure: panic: No heap setup

[Stefan Esser]

Am 28.03.18 um 22:28 schrieb Warner Losh:
> > Hmmm, the code references point into the boot loader code - I had
> > expected that there is a problem in the kernel, not the boot loader.
> >
> >> [1]
> >> https://svnweb.freebsd.org/base/head/stand/libsa/sbrk.c?view=markup#l56
> 
> >
> >
> > Seems that setbase has either not been called or has been called with
> > base=0.
> 
> Right, which is odd...
> 
> >> [2]
> >> 
> https://svnweb.freebsd.org/base/head/stand/i386/zfsboot/zfsboot.c?view=markup#l688
> 
> 
> >
> >
> > I had thought, that the zfs boot code has been initialized before the
> > menu is displayed?
> 
> Right, all of this should be done long before we get to the
> interpreter. Can you break into the loader prompt and try the `heap`
> command, see what that outputs? CC'ing imp@ because he actually knows
> things.
> 
> Totally weird. I'd add a printf to the sethead() function to display its args
> and see if you get this panic before/after that printf...

I'm currently using a Forth-enabled boot loader again, since this is a
"production" machine (my home server, which also receives and keeps all
my work email, for example).

I'll build a clean world with the LUA loader and test it on one of the
next days. Tests will include the "heap" loader command and I'll add the
printf (though, if sbrk() has really not been called, I guess that will
not go too well ...).

Is it possible, that the setheap function is called a second time, just
before jumping into the kernel? (In that case adding the printf might
crash the loader in the first setheap call ...)

Since the loader menu (and escaping from the menu) works, there must be
a valid heap, at that time.

Regards, STefan
___
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: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message)

[Justin Hibbits]

On Wed, Mar 28, 2018 at 3:17 PM, A. Wilcox  wrote:
> On 03/28/18 13:38, Nathan Whitehorn wrote:
>> Is this big-endian support or V1 support being removed? We support
>> the V2 ABI fully on FreeBSD, but not (yet) little-endian. Like on
>> Linux, the default ABI on big-endian will likely remain V1 for the
>> indefinite future,
>
> This is an important distinction to make (big-endian != ELFv1, and ELFv1
> != big-endian).
>
> But do note that on Linux, the musl libc (in use by distros like Alpine,
> Adélie, postmarketOS) only supports ELFv2, even in big-endian mode.  And
> as the maintainer of Adélie using it as a daily-driver on an iMac G5,
> it's definitely something you can use (the only breakage I've seen so
> far on Linux is the PCRE JIT ignoring __CALL_ELF and inserting function
> descriptors anyway).
>
> So I wouldn't discount moving to ELFv2 ABI on BE if that is necessary to
> keep LLVM happy.  It'd be some effort but it should work.
>
> If this is really something FreeBSD is interested in, you might even
> manage to convince me to put on my ports hat again, to help get the JIT
> patches in that are needed for upstreams that went comatose.
>
>
> Best,
> --arw
>
>
>> however, and it would be good if it were at least simple to re-add
>> support at some later date. -Nathan
>>
>
> --
> A. Wilcox (awilfox)
> Open-source programmer (C, C++, Python)
> https://code.foxkit.us/u/awilfox/
>

Moving to ELFv2 is predicated on having a complete toolchain
supporting it.  Right now, base gcc+binutils only supports ELFv1, and
we cannot upgrade to newer toolchain yet.

- Justin
___
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: Boot failure: panic: No heap setup

[Warner Losh]

On Wed, Mar 28, 2018 at 1:10 PM, Kyle Evans  wrote:

> On Tue, Mar 27, 2018 at 6:39 PM, Stefan Esser  wrote:
> > Am 27.03.18 um 21:31 schrieb Kyle Evans:
> >>
> >> On Tue, Mar 27, 2018 at 11:06 AM, Stefan Esser  wrote:
> >>>
> >>> A few weeks ago I tried the LUA boot and found, that my kernel did not
> >>> start
> >>> (i.e. did not print the initial FreeBSD version line), but instead
> >>> stopped
> >>> with:
> >>
> >>
> >> Oy =/
> >>
> >>> panic: No heap setup
> >>>
> >>> I recovered by booting from an alternate boot device and kept my system
> >>> running until today, where I decided to give the LUA boot another try.
> >>>
> >>> The boot failure happened again, with identical message:
> >>>
> >>>  panic: No heap setup
> >>
> >>
> >> Hmm... that's an sbrk panic [1], indicating that setheap hadn't been
> >> called. zfsgptboot is zfsboot with gpt bits included, so the relevant
> >> setheap call is [2] I believe. It's not immediately clear to me how
> >> switching interpreters could actually be breaking it in this way.
> >>
> >> At what point are you hitting this panic? After menu, before kernel
> >> transition?
> >
> >
> > The menu is displayed and I can unload the kernel and load the kernel
> > and modules from an alternate path. The lua code seems to work just fine,
> > but as soon as I enter the "boot" command, the panic happens.
> >
> > This happens when the loader transfers control to the kernel but before
> > any other output is generated. I tried booting a GENERIC kernel just to
> > be sure this is not caused by an out-dated kernel config file.
> >
> >>> I tried booting a GENERIC kernel, but only rebuilding the boot loader
> >>> (gptzfsloader in my case) without LUA support fixed the issue for me
> ...
> >>>
> >>> The system is -CURRENT (built today) on amd64 (not converted to UEFI,
> >>> yet).
> >
> >
> > Hmmm, the code references point into the boot loader code - I had
> > expected that there is a problem in the kernel, not the boot loader.
> >
> >> [1]
> >> https://svnweb.freebsd.org/base/head/stand/libsa/sbrk.c?view=markup#l56
> >
> >
> > Seems that setbase has either not been called or has been called with
> > base=0.
>
> Right, which is odd...
>
> >> [2]
> >> https://svnweb.freebsd.org/base/head/stand/i386/zfsboot/
> zfsboot.c?view=markup#l688
> >
> >
> > I had thought, that the zfs boot code has been initialized before the
> > menu is displayed?
>
> Right, all of this should be done long before we get to the
> interpreter. Can you break into the loader prompt and try the `heap`
> command, see what that outputs? CC'ing imp@ because he actually knows
> things.


Totally weird. I'd add a printf to the sethead() function to display its
args and see if you get this panic before/after that printf...

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: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message)

[A. Wilcox]

On 03/28/18 13:38, Nathan Whitehorn wrote:
> Is this big-endian support or V1 support being removed? We support 
> the V2 ABI fully on FreeBSD, but not (yet) little-endian. Like on 
> Linux, the default ABI on big-endian will likely remain V1 for the 
> indefinite future,

This is an important distinction to make (big-endian != ELFv1, and ELFv1
!= big-endian).

But do note that on Linux, the musl libc (in use by distros like Alpine,
Adélie, postmarketOS) only supports ELFv2, even in big-endian mode.  And
as the maintainer of Adélie using it as a daily-driver on an iMac G5,
it's definitely something you can use (the only breakage I've seen so
far on Linux is the PCRE JIT ignoring __CALL_ELF and inserting function
descriptors anyway).

So I wouldn't discount moving to ELFv2 ABI on BE if that is necessary to
keep LLVM happy.  It'd be some effort but it should work.

If this is really something FreeBSD is interested in, you might even
manage to convince me to put on my ports hat again, to help get the JIT
patches in that are needed for upstreams that went comatose.


Best,
--arw


> however, and it would be good if it were at least simple to re-add 
> support at some later date. -Nathan
> 

-- 
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/



signature.asc
Description: OpenPGP digital signature

Re: Boot failure: panic: No heap setup

[Kyle Evans]

On Tue, Mar 27, 2018 at 6:39 PM, Stefan Esser  wrote:
> Am 27.03.18 um 21:31 schrieb Kyle Evans:
>>
>> On Tue, Mar 27, 2018 at 11:06 AM, Stefan Esser  wrote:
>>>
>>> A few weeks ago I tried the LUA boot and found, that my kernel did not
>>> start
>>> (i.e. did not print the initial FreeBSD version line), but instead
>>> stopped
>>> with:
>>
>>
>> Oy =/
>>
>>> panic: No heap setup
>>>
>>> I recovered by booting from an alternate boot device and kept my system
>>> running until today, where I decided to give the LUA boot another try.
>>>
>>> The boot failure happened again, with identical message:
>>>
>>>  panic: No heap setup
>>
>>
>> Hmm... that's an sbrk panic [1], indicating that setheap hadn't been
>> called. zfsgptboot is zfsboot with gpt bits included, so the relevant
>> setheap call is [2] I believe. It's not immediately clear to me how
>> switching interpreters could actually be breaking it in this way.
>>
>> At what point are you hitting this panic? After menu, before kernel
>> transition?
>
>
> The menu is displayed and I can unload the kernel and load the kernel
> and modules from an alternate path. The lua code seems to work just fine,
> but as soon as I enter the "boot" command, the panic happens.
>
> This happens when the loader transfers control to the kernel but before
> any other output is generated. I tried booting a GENERIC kernel just to
> be sure this is not caused by an out-dated kernel config file.
>
>>> I tried booting a GENERIC kernel, but only rebuilding the boot loader
>>> (gptzfsloader in my case) without LUA support fixed the issue for me ...
>>>
>>> The system is -CURRENT (built today) on amd64 (not converted to UEFI,
>>> yet).
>
>
> Hmmm, the code references point into the boot loader code - I had
> expected that there is a problem in the kernel, not the boot loader.
>
>> [1]
>> https://svnweb.freebsd.org/base/head/stand/libsa/sbrk.c?view=markup#l56
>
>
> Seems that setbase has either not been called or has been called with
> base=0.

Right, which is odd...

>> [2]
>> https://svnweb.freebsd.org/base/head/stand/i386/zfsboot/zfsboot.c?view=markup#l688
>
>
> I had thought, that the zfs boot code has been initialized before the
> menu is displayed?

Right, all of this should be done long before we get to the
interpreter. Can you break into the loader prompt and try the `heap`
command, see what that outputs? CC'ing imp@ because he actually knows
things.

> Or do I misunderstand this phase of the boot process???
>
> Regards, STefan
___
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?

[Eric McCorkle]

I'll do another rebase from head just to be sure 

On March 28, 2018 3:23:23 PM EDT, Warner Losh  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"  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 
>wrote:
>>
>>> FYI, I just IFC'ed everything, and the current patches are still
>fine.
>>>
>>> Also, the full GELI + standalone loader has been deployed on one of
>my
>>> laptops for some time now.
>>>
>>> On 02/21/2018 18:15, Eric McCorkle wrote:
>>> > The GELI work could be merged at this point, though it won't be
>usable
>>> > without an additional patch to enable loader-only operation.  The
>>> > patches are currently up for review:
>>> >
>>> > This is the order in which they'd need to be merged:
>>> >
>>> >
>>> > https://reviews.freebsd.org/D12732
>>> >
>>> > This one changes the efipart device.  Toomas Soome identified some
>>> > problems, which I have addressed.  He has not re-reviewed it,
>however.
>>> >
>>> >
>>> > https://reviews.freebsd.org/D12692
>>> >
>>> > This adds some crypto code needed for GELI.  It simply adds new
>code,
>>> > and doesn't conflict with anything.
>>> >
>>> >
>>> > https://reviews.freebsd.org/D12698
>>> >
>>> > This adds the EFI KMS interface code, and has the EFI loader pass
>keys
>>> > into the keybuf interface.
>>> >
>>> >
>>> > I can't post the main GELI driver until those get merged, as it
>depends
>>> > on them.  It can be found on the geli branch on my github freebsd
>>> > repository, however.
>>> >
>>> >
>>> > Additionally, you need this patch, which allows loader.efi to
>function
>>> > when installed directly to the ESP:
>>> >
>>> > https://reviews.freebsd.org/D13497
>>> >
>>> > On 02/20/2018 22:56, Tommi Pernila wrote:
>>> >> Hi Eric,
>>> >>
>>> >> could you provide a brief update how the work is going?
>>> >>
>>> >>
>>> >> Br,
>>> >>
>>> >> Tommi
>>> >>
>>> >>
>>> >> On Nov 16, 2017 04:29, "Eric McCorkle" >> >> > wrote:
>>> >>
>>> >> Right, so basically, the remaining GELI patches are against
>>> loader, and
>>> >> most of them can go in independently of the work on removing
>boot1.
>>> >> There's a unanimous consensus on getting rid of boot1 which
>>> includes its
>>> >> original author, so that's going to happen.
>>> >>
>>> >>
>>> >> For GELI, we have the following (not necessarily in order):
>>> >>
>>> >> a) Adding the KMS interfaces, pseudo-device, and kernel
>keybuf
>>> >> interactions
>>> >> b) Modifications to the efipart driver
>>> >> c) boot crypto
>>> >> d) GELI partition types (not strictly necessary)
>>> >>
>>> >> Then there's the GELI driver itself.  (a) and (c) are good to
>>> land, (b)
>>> >> needs some more work after Toomas Soome pointed out a
>legitimate
>>> >> problem, and (d) actually needs a good bit more code (but
>again,
>>> it's
>>> >> more cosmetic).  Additionally, the GELI driver will need
>further
>>> mods to
>>> >> efipart to be written (nothing too big).  But we could go
>ahead
>>> with (a)
>>> >> and (c), as they've already been proven to work.
>>> >>
>>> >> I'd wanted to have this stuff shaped up sooner, but I'm
>>> preoccupied with
>>> >> the 7th RISC-V workshop at the end of the month.
>>> >>
>>> >> Once this stuff is all in, loader should handle any GELI
>volumes it
>>> >> finds, and it should Just Work once boot1 is gone.
>>> >>
>>> >>
>>> > ___
>>> > freebsd-current@freebsd.org mailing list
>>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
>>> freebsd.org"
>>> >
>>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
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?

[Warner Losh]

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"  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  wrote:
>
>> FYI, I just IFC'ed everything, and the current patches are still fine.
>>
>> Also, the full GELI + standalone loader has been deployed on one of my
>> laptops for some time now.
>>
>> On 02/21/2018 18:15, Eric McCorkle wrote:
>> > The GELI work could be merged at this point, though it won't be usable
>> > without an additional patch to enable loader-only operation.  The
>> > patches are currently up for review:
>> >
>> > This is the order in which they'd need to be merged:
>> >
>> >
>> > https://reviews.freebsd.org/D12732
>> >
>> > This one changes the efipart device.  Toomas Soome identified some
>> > problems, which I have addressed.  He has not re-reviewed it, however.
>> >
>> >
>> > https://reviews.freebsd.org/D12692
>> >
>> > This adds some crypto code needed for GELI.  It simply adds new code,
>> > and doesn't conflict with anything.
>> >
>> >
>> > https://reviews.freebsd.org/D12698
>> >
>> > This adds the EFI KMS interface code, and has the EFI loader pass keys
>> > into the keybuf interface.
>> >
>> >
>> > I can't post the main GELI driver until those get merged, as it depends
>> > on them.  It can be found on the geli branch on my github freebsd
>> > repository, however.
>> >
>> >
>> > Additionally, you need this patch, which allows loader.efi to function
>> > when installed directly to the ESP:
>> >
>> > https://reviews.freebsd.org/D13497
>> >
>> > On 02/20/2018 22:56, Tommi Pernila wrote:
>> >> Hi Eric,
>> >>
>> >> could you provide a brief update how the work is going?
>> >>
>> >>
>> >> Br,
>> >>
>> >> Tommi
>> >>
>> >>
>> >> On Nov 16, 2017 04:29, "Eric McCorkle" > >> > wrote:
>> >>
>> >> Right, so basically, the remaining GELI patches are against
>> loader, and
>> >> most of them can go in independently of the work on removing boot1.
>> >> There's a unanimous consensus on getting rid of boot1 which
>> includes its
>> >> original author, so that's going to happen.
>> >>
>> >>
>> >> For GELI, we have the following (not necessarily in order):
>> >>
>> >> a) Adding the KMS interfaces, pseudo-device, and kernel keybuf
>> >> interactions
>> >> b) Modifications to the efipart driver
>> >> c) boot crypto
>> >> d) GELI partition types (not strictly necessary)
>> >>
>> >> Then there's the GELI driver itself.  (a) and (c) are good to
>> land, (b)
>> >> needs some more work after Toomas Soome pointed out a legitimate
>> >> problem, and (d) actually needs a good bit more code (but again,
>> it's
>> >> more cosmetic).  Additionally, the GELI driver will need further
>> mods to
>> >> efipart to be written (nothing too big).  But we could go ahead
>> with (a)
>> >> and (c), as they've already been proven to work.
>> >>
>> >> I'd wanted to have this stuff shaped up sooner, but I'm
>> preoccupied with
>> >> the 7th RISC-V workshop at the end of the month.
>> >>
>> >> Once this stuff is all in, loader should handle any GELI volumes it
>> >> finds, and it should Just Work once boot1 is gone.
>> >>
>> >>
>> > ___
>> > freebsd-current@freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
>> 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: r331650 breaks amd64 kernel build

[Ian FREISLICH]

On 03/28/2018 11:11 AM, Ian FREISLICH wrote:
> Hi
>
> (As noted by Oliver Hartman in svn-src-all@)
>
> r331650 breaks amd64 kernel build as follows:
>
> --- machdep.o ---
> /usr/src/sys/amd64/amd64/machdep.c:520:20: error: use of undeclared identifier
> 'T_PROTFLT' ksi.ksi_trapno = T_PROTFLT;
>  ^

Appears fixed in r331681

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: New ACPI Errors

[Pete Wright]

On 02/16/2018 13:54, Pete Wright wrote:



On 02/15/2018 13:37, Jung-uk Kim wrote:

On 02/13/2018 17:34, Claude Buisson wrote:

On 02/13/2018 22:49, Pete Wright wrote:

Hello,
I have started seeing a lot of these messages spam my system log:

ACPI Error: No pointer back to namespace node in package
0xf8000f79a080 (20180209/dsargs-472)
ACPI Error: Method parse/execution failed \134_SB.AC.ADJP,
AE_AML_INTERNAL (20180209/psparse-677)
ACPI Error: Method parse/execution failed \134_SB.AC._PSR,
AE_AML_INTERNAL (20180209/psparse-677)

I noticed this starting from a CURRENT build i installed two weeks
ago, and still see it from a world/kernel i built last night.  two
questions:
1) has anyone else noticed this?
2) is this something to worry about?

i can help debug the issue but am not sure where to start poking.

thanks!
-pete


Here I have

ACPI Error: No pointer back to namespace node in package
0xf8000171f700 (20180209/dsargs-472)
ACPI Error: AE_AML_INTERNAL, While resolving operands for [OpcodeName
unavailable] (20180209/dswexec-606)
ACPI Error: Method parse/execution failed
\134_PR.CPU0._CST,AE_AML_INTERNAL (20180209/psparse-677)

with svn 329142 on a Lenovo ThinkCentre M83
ACPI APIC Table: 

Claude Buisson

I believe you can silence the errors with the attached patch. Please
try it and let me know.

hrm still getting errors:

Feb 16 13:49:45 runner kernel: ACPI Error: No pointer back to 
namespace node in package 0xf80003c8c080 (20180209/dsargs-472)
Feb 16 13:49:45 runner kernel: ACPI Error: Method parse/execution 
failed \_SB.AC.ADJP, AE_AML_INTERNAL (20180209/psparse-677)
Feb 16 13:49:45 runner kernel: ACPI Error: Method parse/execution 
failed \_SB.AC._PSR, AE_AML_INTERNAL (20180209/psparse-677)



here's my diff:
diff --git a/sys/contrib/dev/acpica/include/platform/acfreebsd.h 
b/sys/contrib/dev/acpica/include/platform/acfreebsd.h

index 905dffb7a40..df89399a369 100644
--- a/sys/contrib/dev/acpica/include/platform/acfreebsd.h
+++ b/sys/contrib/dev/acpica/include/platform/acfreebsd.h
@@ -166,6 +166,7 @@

 #define ACPI_UINTPTR_T  uintptr_t

+#define ACPI_IGNORE_PACKAGE_RESOLUTION_ERRORS
 #define ACPI_USE_DO_WHILE_0
 #define ACPI_USE_LOCAL_CACHE
 #define ACPI_USE_NATIVE_DIVIDE




hi there - i was wondering if anyone has taken a look at this issue.  I 
am still seeing these ACPI errors on recent CURRENT systems:


ACPI Error: No pointer back to namespace node in package 
0xf803e71fff00 (20180313/dsargs-472)
ACPI Error: Method parse/execution failed \134_SB.AC.ADJP, 
AE_AML_INTERNAL (20180313/psparse-677)
ACPI Error: Method parse/execution failed \134_SB.AC._PSR, 
AE_AML_INTERNAL (20180313/psparse-677)



I have two amd64 (skylake and kabylake) systems that are exhibiting this 
behavior and am more than happy to test patches or other things.


cheers!
-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: From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message)

[Nathan Whitehorn]

Is this big-endian support or V1 support being removed? We support the 
V2 ABI fully on FreeBSD, but not (yet) little-endian. Like on Linux, the 
default ABI on big-endian will likely remain V1 for the indefinite 
future, however, and it would be good if it were at least simple to 
re-add support at some later date.

-Nathan

On 03/28/18 11:22, Sean Fertile wrote:

Hi Mark,
Just so we are clear this is about V1 abi support in lld, not in llvm. 
The compiler will still be able to produce valid code for big-endian 
ppc64.

Regards
Sean

- Original message -
From: Mark Millard 
To: Nathan Whitehorn , Justin Hibbits
, Ed Maste 
Cc: freebsd-...@freebsd.org, FreeBSD Current
, sfert...@ca.ibm.com
Subject: From LLVM: I got a note that LLVM plans to remove PPC64's
V1 abi support; I'm asked about what support there is for the
PPC64 little-endian/V2 abi (see forwarded message)
Date: Wed, Mar 28, 2018 1:23 PM
I'm not one of the better people to be responding to the the likes of
the below. So I've forwarded to some folks better able to comment,
and 2 freebsd lists so others can see the note as well.

sfertile at ca.ibm.com likely does not monitor any FreeBSD lists. So
either direct sends or use of llvm's bug 31716 comments are probably
required for responses.

Begin forwarded message:

> From: bugzilla-dae...@llvm.org
> Subject: [Bug 31716] FreeBSD's 3.9.1 lld: Powerpc64: code in
.plt expects function descriptor layout but .got.plt space it uses
does not have such
> Date: March 28, 2018 at 10:00:01 AM PDT
> To: marklmi26-fbsd at yahoo.com
>
> sfert...@ca.ibm.com changed bug 31716
> What Removed Added
> CC sfertile at ca.ibm.com
>
> Comment # 2 on bug 31716 from sfertile at ca.ibm.com
> Hi Mark,
>
> I'm one of a few people now actively working on adding support
for the PPC64 V2
> abi.Our plan was to explicitly remove support for the V1 abi (at
least until
> someone makes a pointed effort to support it). I'm interested in
hearing what
> support FreeBSD has for ppc64 right now. Is there any support
for the
> little-endian/V2 abi?
>
>
> You are receiving this mail because:
> • You reported the bug.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)




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

[Tommi Pernila]

Hi all,

is there any chance that this would make it to 11.2 RELEASE ?

 stable/11 slush: April 20, 2018
 stable/11 freeze:May 4, 2018

Br,

Tommi


On Thu, Feb 22, 2018 at 8:18 AM, Tommi Pernila  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  wrote:
>
>> FYI, I just IFC'ed everything, and the current patches are still fine.
>>
>> Also, the full GELI + standalone loader has been deployed on one of my
>> laptops for some time now.
>>
>> On 02/21/2018 18:15, Eric McCorkle wrote:
>> > The GELI work could be merged at this point, though it won't be usable
>> > without an additional patch to enable loader-only operation.  The
>> > patches are currently up for review:
>> >
>> > This is the order in which they'd need to be merged:
>> >
>> >
>> > https://reviews.freebsd.org/D12732
>> >
>> > This one changes the efipart device.  Toomas Soome identified some
>> > problems, which I have addressed.  He has not re-reviewed it, however.
>> >
>> >
>> > https://reviews.freebsd.org/D12692
>> >
>> > This adds some crypto code needed for GELI.  It simply adds new code,
>> > and doesn't conflict with anything.
>> >
>> >
>> > https://reviews.freebsd.org/D12698
>> >
>> > This adds the EFI KMS interface code, and has the EFI loader pass keys
>> > into the keybuf interface.
>> >
>> >
>> > I can't post the main GELI driver until those get merged, as it depends
>> > on them.  It can be found on the geli branch on my github freebsd
>> > repository, however.
>> >
>> >
>> > Additionally, you need this patch, which allows loader.efi to function
>> > when installed directly to the ESP:
>> >
>> > https://reviews.freebsd.org/D13497
>> >
>> > On 02/20/2018 22:56, Tommi Pernila wrote:
>> >> Hi Eric,
>> >>
>> >> could you provide a brief update how the work is going?
>> >>
>> >>
>> >> Br,
>> >>
>> >> Tommi
>> >>
>> >>
>> >> On Nov 16, 2017 04:29, "Eric McCorkle" > >> > wrote:
>> >>
>> >> Right, so basically, the remaining GELI patches are against
>> loader, and
>> >> most of them can go in independently of the work on removing boot1.
>> >> There's a unanimous consensus on getting rid of boot1 which
>> includes its
>> >> original author, so that's going to happen.
>> >>
>> >>
>> >> For GELI, we have the following (not necessarily in order):
>> >>
>> >> a) Adding the KMS interfaces, pseudo-device, and kernel keybuf
>> >> interactions
>> >> b) Modifications to the efipart driver
>> >> c) boot crypto
>> >> d) GELI partition types (not strictly necessary)
>> >>
>> >> Then there's the GELI driver itself.  (a) and (c) are good to
>> land, (b)
>> >> needs some more work after Toomas Soome pointed out a legitimate
>> >> problem, and (d) actually needs a good bit more code (but again,
>> it's
>> >> more cosmetic).  Additionally, the GELI driver will need further
>> mods to
>> >> efipart to be written (nothing too big).  But we could go ahead
>> with (a)
>> >> and (c), as they've already been proven to work.
>> >>
>> >> I'd wanted to have this stuff shaped up sooner, but I'm
>> preoccupied with
>> >> the 7th RISC-V workshop at the end of the month.
>> >>
>> >> Once this stuff is all in, loader should handle any GELI volumes it
>> >> finds, and it should Just Work once boot1 is gone.
>> >>
>> >>
>> > ___
>> > freebsd-current@freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
>> 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"

From LLVM: I got a note that LLVM plans to remove PPC64's V1 abi support; I'm asked about what support there is for the PPC64 little-endian/V2 abi (see forwarded message)

[Mark Millard]

I'm not one of the better people to be responding to the the likes of
the below. So I've forwarded to some folks better able to comment,
and 2 freebsd lists so others can see the note as well.

sfertile at ca.ibm.com likely does not monitor any FreeBSD lists. So
either direct sends or use of llvm's bug 31716 comments are probably
required for responses.

Begin forwarded message:

> From: bugzilla-dae...@llvm.org
> Subject: [Bug 31716] FreeBSD's 3.9.1 lld: Powerpc64: code in .plt expects 
> function descriptor layout but .got.plt space it uses does not have such
> Date: March 28, 2018 at 10:00:01 AM PDT
> To: marklmi26-fbsd at yahoo.com
> 
> sfert...@ca.ibm.com changed bug 31716 
> What  Removed Added
> CCsfertile at ca.ibm.com
> 
> Comment # 2 on bug 31716 from sfertile at ca.ibm.com
> Hi Mark, 
> 
> I'm one of a few people now actively working on adding support for the PPC64 
> V2
> abi.Our plan was to explicitly remove support for the V1 abi (at least until
> someone makes a pointed effort to support it). I'm interested in hearing what
> support FreeBSD has for ppc64 right now. Is there any support for the
> little-endian/V2 abi?
> 
> 
> You are receiving this mail because:
>   • You reported the bug.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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

r331650 breaks amd64 kernel build

[Ian FREISLICH]

Hi

(As noted by Oliver Hartman in svn-src-all@)

r331650 breaks amd64 kernel build as follows:

--- machdep.o ---
/usr/src/sys/amd64/amd64/machdep.c:520:20: error: use of undeclared identifier
'T_PROTFLT' ksi.ksi_trapno = T_PROTFLT;
 ^

The fix:

Index: sys/amd64/amd64/machdep.c
===
--- sys/amd64/amd64/machdep.c   (revision 331680)
+++ sys/amd64/amd64/machdep.c   (working copy)
@@ -128,6 +128,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef SMP
 #include 
 #endif


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: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

[Maurizio Vairani]

2018-02-04 14:40 GMT+01:00 Andriy Gapon :

> On 04/02/2018 11:50, Maurizio Vairani wrote:
> > I have added a socket in the ifioctl() call as in the
> > /usr/src/sys/nfs/bootp_subr.c source.
> > Please let me know if you prefer a patch.
>
> A patch here https://reviews.freebsd.org/ would be the best.
>
> --
> Andriy Gapon
>

Hi,
I have uploaded a patch here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226982
--
Maurizio
___
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"