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

[Eric McCorkle]

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

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

[Warner Losh]

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

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

[Eric McCorkle]

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

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

[Warner Losh]

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 <
oliver.pin...@hardenedbsd.org> wrote:

> Hi!
>
> Is there any update regarding the rebase or the inclusion to base system?
> On 3/28/18, 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-unsubscribe@
>  

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

[Oliver Pinter]

Hi!

Is there any update regarding the rebase or the inclusion to base system?
On 3/28/18, 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-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"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 

Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

[Pedro Giffuni]

On 11/04/2018 11:53, Lucas Holt wrote:

Machines don’t need to be old to have issues. I have a two year old asus am3+ 
board that cant boot from gpt without secure boot enabled and is hard coded for 
Microsoft keys

Lucas Holt


Interesting. Not sure Clover would help there though, secure boot is a  
different issue:


https://wiki.freebsd.org/SecureBoot

Cheers,

Pedro.


On Apr 11, 2018, at 12:04 PM, Ryan Stone  wrote:


On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni  wrote:
Hi;

FWIW, I use a very old PC of the type where the processor will not be fixed
by Intel and that still needs support for the traditional BIOS. I also
bought a 3TB HD (they were easier to find that 2T).

If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and
will happily use ZFS for everything, however I want to dual boot so after
lots of testing I ended up ignoring 1 TB of HD :(.

It does happen that there is a really nice boot loader that could have saved
the day but it is very difficult to install standalone:

https://sourceforge.net/projects/cloverefiboot

Just in case someone has the time and inclination to play with it :)

Pedro.

Is the issue due to using MBR partitioning?  FreeBSD supports booting
from a GPT partition from a traditional BIOS; you don't need EFI.  Is
this machine so old that its BIOS doesn't support booting from GPT?
___
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: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716

[K. Macy]

Chalk another review fail up to shuffling patches between git and phab.
Sorry for the inconvenience.
-M

On Wed, Apr 11, 2018 at 10:26 AM, K. Macy  wrote:
> Actually ctx lock is still a mutex. Just add the STATE_LOCK_INIT line.
> -M
>
> On Wed, Apr 11, 2018 at 10:24 AM, K. Macy  wrote:
>> Sorry about that. It looks like my review must have been missing a line.
>>
>> @@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx)
>>
>> _iflib_assert(sctx);
>>
>> -   CTX_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
>> -
>> +   CTX_LOCK_INIT(ctx);
>> +   STATE_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
>> ifp = ctx->ifc_ifp = if_gethandle(IFT_ETHER);
>> if (ifp == NULL) {
>> device_printf(dev, "can not allocate ifnet structure\n");
>> @@ -5430,8 +5435,8 @@ iflib_io_tqg_attach(struct grouptask *gt, void
>> *uniq, int cpu, char *name)
>>  }
>>
>>  void
>>
>> On Wed, Apr 11, 2018 at 4:39 AM, David Wolfskill  
>> wrote:
>>> This was running:
>>>
>>> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156  
>>> r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 
>>> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
>>> amd64
>>>
>>> during boot, after updating from:
>>>
>>> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155  
>>> r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018 
>>> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
>>> amd64
>>>
>>> (My build machine, which uses an re((4) NIC, did not encounter the issue.)
>>>
>>> It appears that r332389 is implicated.
>>>
>>> ...
>>> Unread portion of the kernel message buffer:
>>>
>>> __curthread () at ./machine/pcpu.h:230
>>> 230 __asm("movq %%gs:%1,%0" : "=r" (td)
>>> (kgdb) #0  __curthread () at ./machine/pcpu.h:230
>>> #1  doadump (textdump=3) at /usr/src/sys/kern/kern_shutdown.c:361
>>> #2  0x80433f4c in db_fncall_generic (addr=,
>>> rv=, nargs=, args=)
>>> at /usr/src/sys/ddb/db_command.c:609
>>> #3  db_fncall (dummy1=, dummy2=,
>>> dummy3=, dummy4=)
>>> at /usr/src/sys/ddb/db_command.c:657
>>> #4  0x80433a99 in db_command (last_cmdp=,
>>> cmd_table=, dopager=)
>>> at /usr/src/sys/ddb/db_command.c:481
>>> #5  0x80433814 in db_command_loop ()
>>> at /usr/src/sys/ddb/db_command.c:534
>>> #6  0x80436a3f in db_trap (type=, code=>> out>)
>>> at /usr/src/sys/ddb/db_main.c:250
>>> #7  0x80b753e3 in kdb_trap (type=3, code=-61456, tf=)
>>> at /usr/src/sys/kern/subr_kdb.c:697
>>> #8  0x80f7eaa8 in trap (frame=0xfe4377a0)
>>> at /usr/src/sys/amd64/amd64/trap.c:548
>>> #9  
>>> #10 kdb_enter (why=0x811df9d4 "panic", msg=)
>>> at /usr/src/sys/kern/subr_kdb.c:479
>>> #11 0x80b2feda in vpanic (fmt=, 
>>> ap=0xfe437910)
>>> at /usr/src/sys/kern/kern_shutdown.c:826
>>> #12 0x80b2fca0 in kassert_panic (
>>> fmt=0x811dadca "mtx_lock() of spin mutex %s @ %s:%d")
>>> at /usr/src/sys/kern/kern_shutdown.c:723
>>> #13 0x80b0ec93 in __mtx_lock_flags (c=0xf80008c85d88, opts=0,
>>> file=0x81113c90 "/usr/src/sys/net/iflib.c", line=>> out>)
>>> at /usr/src/sys/kern/kern_mutex.c:246
>>> #14 0x80c466e1 in _task_fn_admin (context=0xf80008c85c00)
>>> at /usr/src/sys/net/iflib.c:3716
>>> #15 0x80b73849 in gtaskqueue_run_locked (queue=0xf80008489500)
>>> at /usr/src/sys/kern/subr_gtaskqueue.c:331
>>> #16 0x80b735c8 in gtaskqueue_thread_loop (arg=)
>>> at /usr/src/sys/kern/subr_gtaskqueue.c:506
>>> #17 0x80af0064 in fork_exit (
>>> callout=0x80b73540 ,
>>> arg=0xfe0844223008, frame=0xfe437ac0)
>>> at /usr/src/sys/kern/kern_fork.c:1039
>>> #18 
>>> (kgdb)
>>>
>>> If the dump would be useful, I can put it up for access.
>>>
>>> Peace,
>>> david
>>> --
>>> David H. Wolfskill  da...@catwhisker.org
>>> Well, what did you EXPECT from Trump?  He has a history of breaking 
>>> promises.
>>>
>>> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716

[K. Macy]

Actually ctx lock is still a mutex. Just add the STATE_LOCK_INIT line.
-M

On Wed, Apr 11, 2018 at 10:24 AM, K. Macy  wrote:
> Sorry about that. It looks like my review must have been missing a line.
>
> @@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx)
>
> _iflib_assert(sctx);
>
> -   CTX_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
> -
> +   CTX_LOCK_INIT(ctx);
> +   STATE_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
> ifp = ctx->ifc_ifp = if_gethandle(IFT_ETHER);
> if (ifp == NULL) {
> device_printf(dev, "can not allocate ifnet structure\n");
> @@ -5430,8 +5435,8 @@ iflib_io_tqg_attach(struct grouptask *gt, void
> *uniq, int cpu, char *name)
>  }
>
>  void
>
> On Wed, Apr 11, 2018 at 4:39 AM, David Wolfskill  wrote:
>> This was running:
>>
>> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156  
>> r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 
>> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
>> amd64
>>
>> during boot, after updating from:
>>
>> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155  
>> r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018 
>> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
>> amd64
>>
>> (My build machine, which uses an re((4) NIC, did not encounter the issue.)
>>
>> It appears that r332389 is implicated.
>>
>> ...
>> Unread portion of the kernel message buffer:
>>
>> __curthread () at ./machine/pcpu.h:230
>> 230 __asm("movq %%gs:%1,%0" : "=r" (td)
>> (kgdb) #0  __curthread () at ./machine/pcpu.h:230
>> #1  doadump (textdump=3) at /usr/src/sys/kern/kern_shutdown.c:361
>> #2  0x80433f4c in db_fncall_generic (addr=,
>> rv=, nargs=, args=)
>> at /usr/src/sys/ddb/db_command.c:609
>> #3  db_fncall (dummy1=, dummy2=,
>> dummy3=, dummy4=)
>> at /usr/src/sys/ddb/db_command.c:657
>> #4  0x80433a99 in db_command (last_cmdp=,
>> cmd_table=, dopager=)
>> at /usr/src/sys/ddb/db_command.c:481
>> #5  0x80433814 in db_command_loop ()
>> at /usr/src/sys/ddb/db_command.c:534
>> #6  0x80436a3f in db_trap (type=, code=> out>)
>> at /usr/src/sys/ddb/db_main.c:250
>> #7  0x80b753e3 in kdb_trap (type=3, code=-61456, tf=)
>> at /usr/src/sys/kern/subr_kdb.c:697
>> #8  0x80f7eaa8 in trap (frame=0xfe4377a0)
>> at /usr/src/sys/amd64/amd64/trap.c:548
>> #9  
>> #10 kdb_enter (why=0x811df9d4 "panic", msg=)
>> at /usr/src/sys/kern/subr_kdb.c:479
>> #11 0x80b2feda in vpanic (fmt=, ap=0xfe437910)
>> at /usr/src/sys/kern/kern_shutdown.c:826
>> #12 0x80b2fca0 in kassert_panic (
>> fmt=0x811dadca "mtx_lock() of spin mutex %s @ %s:%d")
>> at /usr/src/sys/kern/kern_shutdown.c:723
>> #13 0x80b0ec93 in __mtx_lock_flags (c=0xf80008c85d88, opts=0,
>> file=0x81113c90 "/usr/src/sys/net/iflib.c", line=)
>> at /usr/src/sys/kern/kern_mutex.c:246
>> #14 0x80c466e1 in _task_fn_admin (context=0xf80008c85c00)
>> at /usr/src/sys/net/iflib.c:3716
>> #15 0x80b73849 in gtaskqueue_run_locked (queue=0xf80008489500)
>> at /usr/src/sys/kern/subr_gtaskqueue.c:331
>> #16 0x80b735c8 in gtaskqueue_thread_loop (arg=)
>> at /usr/src/sys/kern/subr_gtaskqueue.c:506
>> #17 0x80af0064 in fork_exit (
>> callout=0x80b73540 ,
>> arg=0xfe0844223008, frame=0xfe437ac0)
>> at /usr/src/sys/kern/kern_fork.c:1039
>> #18 
>> (kgdb)
>>
>> If the dump would be useful, I can put it up for access.
>>
>> Peace,
>> david
>> --
>> David H. Wolfskill  da...@catwhisker.org
>> Well, what did you EXPECT from Trump?  He has a history of breaking promises.
>>
>> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716

[K. Macy]

Sorry about that. It looks like my review must have been missing a line.

@@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx)

_iflib_assert(sctx);

-   CTX_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
-
+   CTX_LOCK_INIT(ctx);
+   STATE_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
ifp = ctx->ifc_ifp = if_gethandle(IFT_ETHER);
if (ifp == NULL) {
device_printf(dev, "can not allocate ifnet structure\n");
@@ -5430,8 +5435,8 @@ iflib_io_tqg_attach(struct grouptask *gt, void
*uniq, int cpu, char *name)
 }

 void

On Wed, Apr 11, 2018 at 4:39 AM, David Wolfskill  wrote:
> This was running:
>
> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156  
> r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64
>
> during boot, after updating from:
>
> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155  
> r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018 
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64
>
> (My build machine, which uses an re((4) NIC, did not encounter the issue.)
>
> It appears that r332389 is implicated.
>
> ...
> Unread portion of the kernel message buffer:
>
> __curthread () at ./machine/pcpu.h:230
> 230 __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) #0  __curthread () at ./machine/pcpu.h:230
> #1  doadump (textdump=3) at /usr/src/sys/kern/kern_shutdown.c:361
> #2  0x80433f4c in db_fncall_generic (addr=,
> rv=, nargs=, args=)
> at /usr/src/sys/ddb/db_command.c:609
> #3  db_fncall (dummy1=, dummy2=,
> dummy3=, dummy4=)
> at /usr/src/sys/ddb/db_command.c:657
> #4  0x80433a99 in db_command (last_cmdp=,
> cmd_table=, dopager=)
> at /usr/src/sys/ddb/db_command.c:481
> #5  0x80433814 in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:534
> #6  0x80436a3f in db_trap (type=, code=)
> at /usr/src/sys/ddb/db_main.c:250
> #7  0x80b753e3 in kdb_trap (type=3, code=-61456, tf=)
> at /usr/src/sys/kern/subr_kdb.c:697
> #8  0x80f7eaa8 in trap (frame=0xfe4377a0)
> at /usr/src/sys/amd64/amd64/trap.c:548
> #9  
> #10 kdb_enter (why=0x811df9d4 "panic", msg=)
> at /usr/src/sys/kern/subr_kdb.c:479
> #11 0x80b2feda in vpanic (fmt=, ap=0xfe437910)
> at /usr/src/sys/kern/kern_shutdown.c:826
> #12 0x80b2fca0 in kassert_panic (
> fmt=0x811dadca "mtx_lock() of spin mutex %s @ %s:%d")
> at /usr/src/sys/kern/kern_shutdown.c:723
> #13 0x80b0ec93 in __mtx_lock_flags (c=0xf80008c85d88, opts=0,
> file=0x81113c90 "/usr/src/sys/net/iflib.c", line=)
> at /usr/src/sys/kern/kern_mutex.c:246
> #14 0x80c466e1 in _task_fn_admin (context=0xf80008c85c00)
> at /usr/src/sys/net/iflib.c:3716
> #15 0x80b73849 in gtaskqueue_run_locked (queue=0xf80008489500)
> at /usr/src/sys/kern/subr_gtaskqueue.c:331
> #16 0x80b735c8 in gtaskqueue_thread_loop (arg=)
> at /usr/src/sys/kern/subr_gtaskqueue.c:506
> #17 0x80af0064 in fork_exit (
> callout=0x80b73540 ,
> arg=0xfe0844223008, frame=0xfe437ac0)
> at /usr/src/sys/kern/kern_fork.c:1039
> #18 
> (kgdb)
>
> If the dump would be useful, I can put it up for access.
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> Well, what did you EXPECT from Trump?  He has a history of breaking promises.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716

[Andrey V. Elsukov]

On 11.04.2018 20:02, Mark Johnston wrote:
>> It appears that r332389 is implicated.
> 
> I'm seeing this too, under bhyve with e1000 emulation. Reverting r332389
> fixes the problem.

I have this problem too. And reverting r332389 fixes it.

em0@pci0:0:25:0:class=0x02 card=0x20088086 chip=0x15028086 rev=0x04
hdr=0x00

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

[Lucas Holt]

Machines don’t need to be old to have issues. I have a two year old asus am3+ 
board that cant boot from gpt without secure boot enabled and is hard coded for 
Microsoft keys 

Lucas Holt

> On Apr 11, 2018, at 12:04 PM, Ryan Stone  wrote:
> 
>> On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni  wrote:
>> Hi;
>> 
>> FWIW, I use a very old PC of the type where the processor will not be fixed
>> by Intel and that still needs support for the traditional BIOS. I also
>> bought a 3TB HD (they were easier to find that 2T).
>> 
>> If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and
>> will happily use ZFS for everything, however I want to dual boot so after
>> lots of testing I ended up ignoring 1 TB of HD :(.
>> 
>> It does happen that there is a really nice boot loader that could have saved
>> the day but it is very difficult to install standalone:
>> 
>> https://sourceforge.net/projects/cloverefiboot
>> 
>> Just in case someone has the time and inclination to play with it :)
>> 
>> Pedro.
> 
> Is the issue due to using MBR partitioning?  FreeBSD supports booting
> from a GPT partition from a traditional BIOS; you don't need EFI.  Is
> this machine so old that its BIOS doesn't support booting from GPT?
> ___
> 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: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716

[Mark Johnston]

On Wed, Apr 11, 2018 at 04:39:58AM -0700, David Wolfskill wrote:
> This was running:
> 
> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156  
> r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64
> 
> during boot, after updating from:
> 
> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155  
> r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018 
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64
> 
> (My build machine, which uses an re((4) NIC, did not encounter the issue.)
> 
> It appears that r332389 is implicated.

I'm seeing this too, under bhyve with e1000 emulation. Reverting r332389
fixes the problem.
___
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: CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

[Pedro Giffuni]

On 11/04/2018 11:04, Ryan Stone wrote:

On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni  wrote:

Hi;

FWIW, I use a very old PC of the type where the processor will not be fixed
by Intel and that still needs support for the traditional BIOS. I also
bought a 3TB HD (they were easier to find that 2T).

If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and
will happily use ZFS for everything, however I want to dual boot so after
lots of testing I ended up ignoring 1 TB of HD :(.

It does happen that there is a really nice boot loader that could have saved
the day but it is very difficult to install standalone:

https://sourceforge.net/projects/cloverefiboot

Just in case someone has the time and inclination to play with it :)

Pedro.

Is the issue due to using MBR partitioning?  FreeBSD supports booting
from a GPT partition from a traditional BIOS; you don't need EFI.  Is
this machine so old that its BIOS doesn't support booting from GPT?


It's a Dell Optiplex 760 (refurbished). I don't remember the details but 
FreeBSD supports booting just fine if I dedicate all the HD to 
FreeBSD/GPT, but the Windows bootloader wont so I needed a bootloader 
with it's own EFI implementation that would. Clover comes from the 
Apple/Darwin world and does this but I never managed to install it in a 
HD; ideally you have to figure out how to install it before installing 
the OS so I had to install it later in a thumbdrive.


FWIW, the only documentation I could find on the gory details for dual 
booting (with linux) is here:


https://www.rodsbooks.com/gdisk/bios.html

Cheers,

Pedro.
___
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: CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

[Ryan Stone]

On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni  wrote:
> Hi;
>
> FWIW, I use a very old PC of the type where the processor will not be fixed
> by Intel and that still needs support for the traditional BIOS. I also
> bought a 3TB HD (they were easier to find that 2T).
>
> If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and
> will happily use ZFS for everything, however I want to dual boot so after
> lots of testing I ended up ignoring 1 TB of HD :(.
>
> It does happen that there is a really nice boot loader that could have saved
> the day but it is very difficult to install standalone:
>
> https://sourceforge.net/projects/cloverefiboot
>
> Just in case someone has the time and inclination to play with it :)
>
> Pedro.

Is the issue due to using MBR partitioning?  FreeBSD supports booting
from a GPT partition from a traditional BIOS; you don't need EFI.  Is
this machine so old that its BIOS doesn't support booting from GPT?
___
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"

CloverEFIBoot (was Re: Call for Testing: UEFI Changes)

[Pedro Giffuni]

Hi;

FWIW, I use a very old PC of the type where the processor will not be 
fixed by Intel and that still needs support for the traditional BIOS. I 
also bought a 3TB HD (they were easier to find that 2T).


If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB 
and will happily use ZFS for everything, however I want to dual boot so 
after lots of testing I ended up ignoring 1 TB of HD :(.


It does happen that there is a really nice boot loader that could have 
saved the day but it is very difficult to install standalone:


https://sourceforge.net/projects/cloverefiboot

Just in case someone has the time and inclination to play with it :)

Pedro.


___
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: Call for Testing: UEFI Changes

[Kyle Evans]

On Thu, Apr 5, 2018 at 7:23 PM, Zaphod Beeblebrox  wrote:
> As I said I would, I put the contents of /boot onto the FAT-formated EFI
> partition.  This is suboptimal.  The default is to use "kernel.old" ... etc
> ... which cannot be done on a FAT partition... at least not with our
> filesystem driver ...
>
> ... but with all of /boot on the EFI partition, simply starting loader.efi
> works.
>

Hi,

Can you try a standard setup with the patch at [1] applied to your
boot1.efi? Standard setup being /boot/loader.efi in place and
boot1.efi copied over to your ESP.

I *think* this might help your situation, but I've no real idea. If I
know what I'm doing (which I don't), then this patch should (maybe?)
force your screen down into a lower resolution prior to drawing the
menu then reset it once more before it prints resolution information
and executes the kernel.

Maybe it'll fix it?

Thanks,

Kyle Evans

[1] https://people.freebsd.org/~kevans/loader.diff
___
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: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716

[David Wolfskill]

This was running:

FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156  
r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 
r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64

during boot, after updating from:

FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155  
r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018 
r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64

(My build machine, which uses an re((4) NIC, did not encounter the issue.)

It appears that r332389 is implicated.

...
Unread portion of the kernel message buffer:

__curthread () at ./machine/pcpu.h:230
230 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) #0  __curthread () at ./machine/pcpu.h:230
#1  doadump (textdump=3) at /usr/src/sys/kern/kern_shutdown.c:361
#2  0x80433f4c in db_fncall_generic (addr=, 
rv=, nargs=, args=)
at /usr/src/sys/ddb/db_command.c:609
#3  db_fncall (dummy1=, dummy2=, 
dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:657
#4  0x80433a99 in db_command (last_cmdp=, 
cmd_table=, dopager=)
at /usr/src/sys/ddb/db_command.c:481
#5  0x80433814 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:534
#6  0x80436a3f in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:250
#7  0x80b753e3 in kdb_trap (type=3, code=-61456, tf=)
at /usr/src/sys/kern/subr_kdb.c:697
#8  0x80f7eaa8 in trap (frame=0xfe4377a0)
at /usr/src/sys/amd64/amd64/trap.c:548
#9  
#10 kdb_enter (why=0x811df9d4 "panic", msg=)
at /usr/src/sys/kern/subr_kdb.c:479
#11 0x80b2feda in vpanic (fmt=, ap=0xfe437910)
at /usr/src/sys/kern/kern_shutdown.c:826
#12 0x80b2fca0 in kassert_panic (
fmt=0x811dadca "mtx_lock() of spin mutex %s @ %s:%d")
at /usr/src/sys/kern/kern_shutdown.c:723
#13 0x80b0ec93 in __mtx_lock_flags (c=0xf80008c85d88, opts=0, 
file=0x81113c90 "/usr/src/sys/net/iflib.c", line=)
at /usr/src/sys/kern/kern_mutex.c:246
#14 0x80c466e1 in _task_fn_admin (context=0xf80008c85c00)
at /usr/src/sys/net/iflib.c:3716
#15 0x80b73849 in gtaskqueue_run_locked (queue=0xf80008489500)
at /usr/src/sys/kern/subr_gtaskqueue.c:331
#16 0x80b735c8 in gtaskqueue_thread_loop (arg=)
at /usr/src/sys/kern/subr_gtaskqueue.c:506
#17 0x80af0064 in fork_exit (
callout=0x80b73540 , 
arg=0xfe0844223008, frame=0xfe437ac0)
at /usr/src/sys/kern/kern_fork.c:1039
#18 
(kgdb) 

If the dump would be useful, I can put it up for access.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Well, what did you EXPECT from Trump?  He has a history of breaking promises.

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


signature.asc
Description: PGP signature

Re: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found

[Vladimir Zakharov]

On Tue, Apr 10, 2018, Kristof Provost wrote:
> On 9 Apr 2018, at 13:10, Vladimir Zakharov wrote:
> > On Mon, Apr 09, 2018, Kristof Provost wrote:
> > > On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote:
> > > 
> > > For several days buildworld fails for me with the following
> > > error. Cleaning
> > > and
> > > rebuilding didn't help.
> > > 
> > > ===> tests/sys/netpfil/pf/ioctl (all)
> > > --- validation ---
> > > (cd /usr/src/tests/sys/netpfil/pf/ioctl &&
> > > DEPENDFILE=.depend.validation
> > > NO_SUBDIR=1 make -f /usr/src/tests/sys/netpfil/pf/ioctl/Makefile
> > > _RECURSING_PROGS=t PROG=validation )
> > > Building
> > > /home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/
> > > validation.o
> > > --- validation.o ---
> > > In file included from
> > > /usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35:
> > > /home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10:
> > > fatal
> > > error: 'netpfil/pf/pf.h' file not found
> > > #include 
> > > ^
> 
> It should be fully fixed as of r332358.
> Thanks for the report.

Works for me. Thanks.

-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
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"