Re: AWS M5 ena issues [IGNORE]

2018-07-06 Thread Pete Wright 
sorry - this was sent to incorrect list - please ignore.  sorry for the 
noise!


-pete

On 07/06/2018 16:22, Pete Wright wrote:

hi there - this is in relation to this ticket:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225791

"ena driver causing kernel panics on AWS EC2"

reading through the thread, and Colin's blog post on the new M5 
instance types, it looks like the issues people are running into are 
related to NVMe devices fronting EBS block stores. My question is is 
this a discreet issue from other anomalies people have seen with ena 
network devices.  For example, on some currently lightly loaded 
m5.large instances I have been seeing this in the logs pretty regularly:


ena0: device is going DOWN
ena0: device is going UP
ena0: queue 0 - cpu 0
ena0: queue 1 - cpu 1

These systems were previously running 11.1-RELEASE, which I upgraded 
to 11.2-RELEASE via "freebsd-update".  These messages only started 
showing up after I had completed the upgrade.2



from reading the bug report above though it's not clear as to the 
state of the ena drivers themselves.  Are they considered unstable on 
11.2-RELEASE?


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"

AWS M5 ena issues

2018-07-06 Thread Pete Wright 

hi there - this is in relation to this ticket:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225791

"ena driver causing kernel panics on AWS EC2"

reading through the thread, and Colin's blog post on the new M5 instance 
types, it looks like the issues people are running into are related to 
NVMe devices fronting EBS block stores. My question is is this a 
discreet issue from other anomalies people have seen with ena network 
devices.  For example, on some currently lightly loaded m5.large 
instances I have been seeing this in the logs pretty regularly:


ena0: device is going DOWN
ena0: device is going UP
ena0: queue 0 - cpu 0
ena0: queue 1 - cpu 1

These systems were previously running 11.1-RELEASE, which I upgraded to 
11.2-RELEASE via "freebsd-update".  These messages only started showing 
up after I had completed the upgrade.2



from reading the bug report above though it's not clear as to the state 
of the ena drivers themselves.  Are they considered unstable on 
11.2-RELEASE?


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: bhyve and freebsd memstick installer

2018-07-06 Thread tech-lists 

On 06/07/2018 18:32, Rodney W. Grimes wrote:

Untested, but since memstick is actually a "disk" image and not
a "cdrom" image you should be able to do something like
vmrun.sh -c 2 -m 4096M -t tap0 -d memstick.img -d guest.img guestname

Your memstick should show up as ada0,
and your guest.img should be ada1.


Thanks for that, I'll try it next time I can.

I got round it temporarily by mounting the memstick as /dev/md1p3 and 
pointing mkisofs at that.


the -i -I thing of bhyve threw me. I thought I'd need it to point to 
bootable media.


--
J.
___
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: bhyve and freebsd memstick installer

2018-07-06 Thread Rodney W. Grimes 
> Hello,
> 
> context: freebsd-12-current server, amd64
> 
> I usually install a freebsd guest like this:
> 
> sh /usr/share/examples/bhyve/vmrun.sh -c 2 -m 4096M -t tap0 -d guest.img 
> -i -I FreeBSD-installation-dvd1.iso guestname
> 
> I only have memstick.img - how do I either:
> 
> 1. convert the memstick to dvd1.iso
> 2. make bhyve use the memstick installation iso (I don't think it can do 
> this as the option to do so isn't in vmrun.sh)

Untested, but since memstick is actually a "disk" image and not
a "cdrom" image you should be able to do something like
vmrun.sh -c 2 -m 4096M -t tap0 -d memstick.img -d guest.img guestname

Your memstick should show up as ada0,
and your guest.img should be ada1.


-- 
Rod Grimes rgri...@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"

bhyve and freebsd memstick installer

2018-07-06 Thread tech-lists 

Hello,

context: freebsd-12-current server, amd64

I usually install a freebsd guest like this:

sh /usr/share/examples/bhyve/vmrun.sh -c 2 -m 4096M -t tap0 -d guest.img 
-i -I FreeBSD-installation-dvd1.iso guestname


I only have memstick.img - how do I either:

1. convert the memstick to dvd1.iso
2. make bhyve use the memstick installation iso (I don't think it can do 
this as the option to do so isn't in vmrun.sh)


thanks,
--
J.
___
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: em0 link fail

2018-07-06 Thread tech-lists 

On 03/07/2018 18:47, Michael Butler wrote:

On June 1st, I was able to do my monthly laptop ZFS snap-shot/back-up
(using "zfs snapshot -r zroot@backup; zfs send -R >nfs-filesys"). Now I
can't without the em0 interface stalling :-(

On a guess, I tried reverting SVN r335303 but that didn't help.

em0:  port 0xf080-0xf09f mem
0xf7e0-0xf7e1,0xf7e39000-0xf7e39fff irq 20 at device 25.0 on pci0
em0: attach_pre capping queues at 1
em0: using 1024 tx descriptors and 1024 rx descriptors
em0: msix_init qsets capped at 1
em0: PCIY_MSIX capability not found; or rid 0 == 0.
em0: Using an MSI interrupt
em0: allocated for 1 tx_queues
em0: allocated for 1 rx_queues
em0: Ethernet address: f0:1f:af:66:95:7e
em0: netmap queues/slots: TX 1/1024, RX 1/1024
em0: link state changed to UP

  [ initiate "zfs send" ]

em0: TX(0) desc avail = 41, pidx = 172
em0: link state changed to DOWN
em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0

  .. ad nauseum ..

"ifconfig em0 down; ifconfig em0 up" doesn't help.

Any hints?


Hi,

I'm not seeing any problems using em0/saturating upstream
using 12.0-CURRENT #0 r335979
--
J.
___
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: atomic changes break drm-next-kmod?

2018-07-06 Thread Hans Petter Selasky 

On 07/06/18 11:14, Johannes Lundberg wrote:

On Fri, Jul 6, 2018 at 9:49 AM Konstantin Belousov 
wrote:


On Fri, Jul 06, 2018 at 09:52:24AM +0200, Niclas Zeising wrote:

On 07/06/18 00:02, Warner Losh wrote:



On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin mailto:j...@freebsd.org>> wrote:

 On 7/5/18 12:36 PM, Konstantin Belousov wrote:
  > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky

wrote:

  >> On 07/05/18 20:59, Hans Petter Selasky wrote:
  >>> On 07/05/18 19:48, Pete Wright wrote:
  
  
   On 07/05/2018 10:10, John Baldwin wrote:
  > On 7/3/18 5:10 PM, Pete Wright wrote:
  >>
  >> On 07/03/2018 15:56, John Baldwin wrote:
  >>> On 7/3/18 3:34 PM, Pete Wright wrote:
   On 07/03/2018 15:29, John Baldwin wrote:
  > That seems like kgdb is looking at the wrong CPU.  Can
 you use
  > 'info threads' and look for threads not stopped in
 'sched_switch'
  > and get their backtraces?  You could also just do

'thread

 apply
  > all bt' and put that file at a URL if that is easiest.
  >
   sure thing John - here's a gist of "thread apply all bt"
  
  
 https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
 >> That doesn't look right at all.  Are you sure the kernel
 matches the
  >>> vmcore?  Also, which kgdb version are you using?
  >>>
  >> yea i agree that doesn't look right at all.  here is my

setup:

  >>
  >> $ which kgdb
  >> /usr/bin/kgdb
  >> $ kgdb
  >> GNU gdb 6.1.1 [FreeBSD]
  >> $ ls -lh /var/crash/vmcore.1
  >> -rw---  1 root  wheel   1.6G Jul  3 15:03
 /var/crash/vmcore.1
  >> $ ls -l /usr/lib/debug/boot/kernel/kernel.debug
  >> -r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54
  >> /usr/lib/debug/boot/kernel/kernel.debug
  >>
  >> and i invoke kgdb like so:
  >> $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug
 /var/crash/vmcore.1
  >>
  >> here's a gist of my full gdb session:
  >> http://termbin.com/krsn
  >>
  >> dunno - maybe i have a bad core dump?  regardless, more

than

 happy to
  >> help so let me know if i should try anything else or

patches

 etc..
  > Can you try installing gdb from ports and using
 /usr/local/bin/kgdb?
  >
  
   that seems to have done the trick, at least the output looks

more

   encouraging.
  
     --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
   KDB: enter: panic
  
   __curthread () at ./machine/pcpu.h:231
   231__asm("movq %%gs:%1,%0" : "=r" (td)
  
  
   here's my full kgdb session:
   http://termbin.com/qa4f
  
   i don't see any threads not in "sched_switch" though :(
  >>>
  >>> Hi,
  >>>
  >>> The problem may be that the patch to enable atomic inlining

of all

  >>> macros forgot to set the SMP keyword which means SMP is not
 defined at
  >>> all for KLD's so all non-kernel atomic usage is with MPLOCKED
 empty!
  > Problem is that out-of-tree modules build does not have opt*.h

files

  > from the kernel.  UP config is a valid one, flipping some

option's

  > default value does not solve the problem.

 Yes, but using the lock prefix in a generic module is ok (it will

still

 work, just not quite as fast) whereas the lack of lock is fatal on
 SMP.  I would amend Hans' patch slightly to honor the opt_* setting
 for KLD_TIED (but that is only true if KLD_TIED means "built as

part of

 a kernel build, so has valid opt_foo.h headers" and not
 'a standalone module where someone put MODULES_TIED=1 on the

command

 line
 to make').


I agree with this default. It's sensible to default to (a) the most
popular thing and (b) thing that always works, especially when (a) and
(b) are identical.

Don't make me start the "Do we really need an SMP option, why not make
it always on" thread :) The number of relevant uniprocessor x86 boxes
that benefit from omitting SMP is so small as to be irrelevant, IMHO.

A

MP kernel runs just fine on them...

Warner


Where are we on this?
It is important to get it fixed, it's already been 4 days, which means 4
days of all modern FreeBSD desktop systems being broken, and possibly
other systems with kernel modules from ports as well.


Another question, how hard would it be to expose how the kernel was
built to modules built from ports, so that they can figure out stuff
like SMP and others, that might affect the module build?

Point the KERNBUILDDIR variable to the directory of the kernel build.
This is the

Re: atomic changes break drm-next-kmod?

2018-07-06 Thread Johannes Lundberg 
On Fri, Jul 6, 2018 at 9:49 AM Konstantin Belousov 
wrote:

> On Fri, Jul 06, 2018 at 09:52:24AM +0200, Niclas Zeising wrote:
> > On 07/06/18 00:02, Warner Losh wrote:
> > >
> > >
> > > On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin  > > > wrote:
> > >
> > > On 7/5/18 12:36 PM, Konstantin Belousov wrote:
> > >  > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky
> wrote:
> > >  >> On 07/05/18 20:59, Hans Petter Selasky wrote:
> > >  >>> On 07/05/18 19:48, Pete Wright wrote:
> > >  
> > >  
> > >   On 07/05/2018 10:10, John Baldwin wrote:
> > >  > On 7/3/18 5:10 PM, Pete Wright wrote:
> > >  >>
> > >  >> On 07/03/2018 15:56, John Baldwin wrote:
> > >  >>> On 7/3/18 3:34 PM, Pete Wright wrote:
> > >   On 07/03/2018 15:29, John Baldwin wrote:
> > >  > That seems like kgdb is looking at the wrong CPU.  Can
> > > you use
> > >  > 'info threads' and look for threads not stopped in
> > > 'sched_switch'
> > >  > and get their backtraces?  You could also just do
> 'thread
> > > apply
> > >  > all bt' and put that file at a URL if that is easiest.
> > >  >
> > >   sure thing John - here's a gist of "thread apply all bt"
> > >  
> > >  
> > > https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
> > >  >
> > >  >>> That doesn't look right at all.  Are you sure the kernel
> > > matches the
> > >  >>> vmcore?  Also, which kgdb version are you using?
> > >  >>>
> > >  >> yea i agree that doesn't look right at all.  here is my
> setup:
> > >  >>
> > >  >> $ which kgdb
> > >  >> /usr/bin/kgdb
> > >  >> $ kgdb
> > >  >> GNU gdb 6.1.1 [FreeBSD]
> > >  >> $ ls -lh /var/crash/vmcore.1
> > >  >> -rw---  1 root  wheel   1.6G Jul  3 15:03
> > > /var/crash/vmcore.1
> > >  >> $ ls -l /usr/lib/debug/boot/kernel/kernel.debug
> > >  >> -r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54
> > >  >> /usr/lib/debug/boot/kernel/kernel.debug
> > >  >>
> > >  >> and i invoke kgdb like so:
> > >  >> $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug
> > > /var/crash/vmcore.1
> > >  >>
> > >  >> here's a gist of my full gdb session:
> > >  >> http://termbin.com/krsn
> > >  >>
> > >  >> dunno - maybe i have a bad core dump?  regardless, more
> than
> > > happy to
> > >  >> help so let me know if i should try anything else or
> patches
> > > etc..
> > >  > Can you try installing gdb from ports and using
> > > /usr/local/bin/kgdb?
> > >  >
> > >  
> > >   that seems to have done the trick, at least the output looks
> more
> > >   encouraging.
> > >  
> > >     --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > >   KDB: enter: panic
> > >  
> > >   __curthread () at ./machine/pcpu.h:231
> > >   231__asm("movq %%gs:%1,%0" : "=r" (td)
> > >  
> > >  
> > >   here's my full kgdb session:
> > >   http://termbin.com/qa4f
> > >  
> > >   i don't see any threads not in "sched_switch" though :(
> > >  >>>
> > >  >>> Hi,
> > >  >>>
> > >  >>> The problem may be that the patch to enable atomic inlining
> of all
> > >  >>> macros forgot to set the SMP keyword which means SMP is not
> > > defined at
> > >  >>> all for KLD's so all non-kernel atomic usage is with MPLOCKED
> > > empty!
> > >  > Problem is that out-of-tree modules build does not have opt*.h
> files
> > >  > from the kernel.  UP config is a valid one, flipping some
> option's
> > >  > default value does not solve the problem.
> > >
> > > Yes, but using the lock prefix in a generic module is ok (it will
> still
> > > work, just not quite as fast) whereas the lack of lock is fatal on
> > > SMP.  I would amend Hans' patch slightly to honor the opt_* setting
> > > for KLD_TIED (but that is only true if KLD_TIED means "built as
> part of
> > > a kernel build, so has valid opt_foo.h headers" and not
> > > 'a standalone module where someone put MODULES_TIED=1 on the
> command
> > > line
> > > to make').
> > >
> > >
> > > I agree with this default. It's sensible to default to (a) the most
> > > popular thing and (b) thing that always works, especially when (a) and
> > > (b) are identical.
> > >
> > > Don't make me start the "Do we really need an SMP option, why not make
> > > it always on" thread :) The number of relevant uniprocessor x86 boxes
> > > that benefit from omitting SMP is so small as to be irrelevant, IMHO.
> A
> > > MP kernel runs just fine on them...
> > >
> > >

Re: atomic changes break drm-next-kmod?

2018-07-06 Thread Konstantin Belousov 
On Fri, Jul 06, 2018 at 09:52:24AM +0200, Niclas Zeising wrote:
> On 07/06/18 00:02, Warner Losh wrote:
> > 
> > 
> > On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin  > > wrote:
> > 
> > On 7/5/18 12:36 PM, Konstantin Belousov wrote:
> >  > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky wrote:
> >  >> On 07/05/18 20:59, Hans Petter Selasky wrote:
> >  >>> On 07/05/18 19:48, Pete Wright wrote:
> >  
> >  
> >   On 07/05/2018 10:10, John Baldwin wrote:
> >  > On 7/3/18 5:10 PM, Pete Wright wrote:
> >  >>
> >  >> On 07/03/2018 15:56, John Baldwin wrote:
> >  >>> On 7/3/18 3:34 PM, Pete Wright wrote:
> >   On 07/03/2018 15:29, John Baldwin wrote:
> >  > That seems like kgdb is looking at the wrong CPU.  Can
> > you use
> >  > 'info threads' and look for threads not stopped in
> > 'sched_switch'
> >  > and get their backtraces?  You could also just do 'thread
> > apply
> >  > all bt' and put that file at a URL if that is easiest.
> >  >
> >   sure thing John - here's a gist of "thread apply all bt"
> >  
> >  
> > https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
> > 
> >  >>> That doesn't look right at all.  Are you sure the kernel
> > matches the
> >  >>> vmcore?  Also, which kgdb version are you using?
> >  >>>
> >  >> yea i agree that doesn't look right at all.  here is my setup:
> >  >>
> >  >> $ which kgdb
> >  >> /usr/bin/kgdb
> >  >> $ kgdb
> >  >> GNU gdb 6.1.1 [FreeBSD]
> >  >> $ ls -lh /var/crash/vmcore.1
> >  >> -rw---  1 root  wheel   1.6G Jul  3 15:03
> > /var/crash/vmcore.1
> >  >> $ ls -l /usr/lib/debug/boot/kernel/kernel.debug
> >  >> -r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54
> >  >> /usr/lib/debug/boot/kernel/kernel.debug
> >  >>
> >  >> and i invoke kgdb like so:
> >  >> $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug
> > /var/crash/vmcore.1
> >  >>
> >  >> here's a gist of my full gdb session:
> >  >> http://termbin.com/krsn
> >  >>
> >  >> dunno - maybe i have a bad core dump?  regardless, more than
> > happy to
> >  >> help so let me know if i should try anything else or patches
> > etc..
> >  > Can you try installing gdb from ports and using
> > /usr/local/bin/kgdb?
> >  >
> >  
> >   that seems to have done the trick, at least the output looks more
> >   encouraging.
> >  
> >     --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> >   KDB: enter: panic
> >  
> >   __curthread () at ./machine/pcpu.h:231
> >   231        __asm("movq %%gs:%1,%0" : "=r" (td)
> >  
> >  
> >   here's my full kgdb session:
> >   http://termbin.com/qa4f
> >  
> >   i don't see any threads not in "sched_switch" though :(
> >  >>>
> >  >>> Hi,
> >  >>>
> >  >>> The problem may be that the patch to enable atomic inlining of all
> >  >>> macros forgot to set the SMP keyword which means SMP is not
> > defined at
> >  >>> all for KLD's so all non-kernel atomic usage is with MPLOCKED
> > empty!
> >  > Problem is that out-of-tree modules build does not have opt*.h files
> >  > from the kernel.  UP config is a valid one, flipping some option's
> >  > default value does not solve the problem.
> > 
> > Yes, but using the lock prefix in a generic module is ok (it will still
> > work, just not quite as fast) whereas the lack of lock is fatal on
> > SMP.  I would amend Hans' patch slightly to honor the opt_* setting
> > for KLD_TIED (but that is only true if KLD_TIED means "built as part of
> > a kernel build, so has valid opt_foo.h headers" and not
> > 'a standalone module where someone put MODULES_TIED=1 on the command
> > line
> > to make').
> > 
> > 
> > I agree with this default. It's sensible to default to (a) the most 
> > popular thing and (b) thing that always works, especially when (a) and 
> > (b) are identical.
> > 
> > Don't make me start the "Do we really need an SMP option, why not make 
> > it always on" thread :) The number of relevant uniprocessor x86 boxes 
> > that benefit from omitting SMP is so small as to be irrelevant, IMHO. A 
> > MP kernel runs just fine on them...
> > 
> > Warner
> 
> Where are we on this?
> It is important to get it fixed, it's already been 4 days, which means 4 
> days of all modern FreeBSD desktop systems being broken, and possibly 
> other systems with kernel modules from ports as well.
> 
> 
> Another question, how hard would it be to expose

Re: EFI booting from external USB pen drive

2018-07-06 Thread Rodney W. Grimes 
> On 2018-07-06 04:17, Warner Losh wrote:
> > On Thu, Jul 5, 2018 at 7:11 PM, Rodney W. Grimes <
> > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > 
> >> > On 5 Jul 2018, at 18:18, Rodney W. Grimes wrote:
> >> >
> >> > > [ Charset UTF-8 unsupported, converting... ]
> >> > >> On 5 Jul 2018, at 17:19, Warner Losh wrote:
> >> > >>
> >> > >>> FAT12 isn't good for UEFI. Use FAT16 or FAT32.
> >> > >>
> >> > >> We use it for the default image we built and the wiki suggests it as
> >> > >> well at https://wiki.freebsd.org/UEFI#CD.2FDVD_Boot_under_UEFI
> >> > >
> >> > > IIRC FreeBSD recently cnahged to FAT16 or 32 on these
> >> > > as the size got pushed up to be larger than what FAT12
> >> > > can access.
> >> >
> >> > https://svnweb.freebsd.org/base/head/stand/efi/boot1/
> >> generate-fat.sh?annotate=332561#l45
> >> >
> >> > nope.
> >> 
> >> That is not the code we build release images with,
> >> that is Warners tests for the boot loader.
> >> 
> > 
> > No, that's the actual code that generates boot1.efiffat.
> > 
> > Warner
> 
>   Yup, and EFI have no problem at all with this.
>   FAT12 can work with all EFI implementation, the problem is the size of 
> the FAT12 part that sometimes causes problems.
>   Rod, you are refering to the arm images which do not uses makefs or 
> generate-fat.sh but using md device and newfs_msdos.

Yes, your right Emmanuel, thanks.  I thought that was the last
place fat12 was in use, but I see there is this ugly bit of evil
still around.

-- 
Rod Grimes rgri...@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"

CURRENT: building PkgBase for 11.2-RELENG on CURRENT fails

2018-07-06 Thread O. Hartmann 
I fail to buildworld/buildkernel and package FreeBSD 11.2-RELENG on a CURRENT
host (FreeBSD 12.0-CURRENT #165 r336013: Thu Jul  5 21:00:36 CEST 2018 amd64)
with the error shown below.

My aim is to have CURRENT building 11.1 and 11.2 packages for "base" and for
the poudriere jails. This seems to start failing recently and I can not fathom
why. Any ideas?

As the env variables show, the sources are stored
at /pool/sources/11.2-RELENG/src and for the build environment, I point to that
source and obj base.


Kind regards,
Oliver

[...]
+ cd /pool/sources/11.2-RELENG/src
+ env 'MAKEOBJDIRPREFIX=/pool/sources/11.2-RELENG/obj' 'WITH_META_MODE=YES'
  '__MAKE_CONF=/usr/local/etc/config/amd64/11.2-RELENG-make.conf'
  'SRCCONF=/usr/local/etc/config/amd64/11.2-RELENG-src.conf'
  'SRC_ENV_CONF=/usr/local/etc/config/amd64/11.2-RELENG-src-env.conf' make -j9
  'TARGET=amd64'
  'KERNCONFDIR=/usr/local/etc/config/amd64/11.2-RELENG/kernel_conf/' 'KERNCONF=
  GENERIC-NODEBUG ' 'NO_INSTALLEXTRAKERNELS=NO' 'NO_INSTALLKERNEL=NO'
  buildworld buildkernel --- buildworld --- make[1]:
  "/pool/sources/11.2-RELENG/src/Makefile.inc1" line 1517: Unassociated shell
  command "@cd ${KSTAGEDIR}/${DISTDIR} ;  awk -f
  ${SRCDIR}/release/scripts/mtree-to-plist.awk  -v kernel=yes -v
  _kernconf=${INSTALLKERNEL}  ${KSTAGEDIR}/kernel.meta ;  cap_arg=`cd
  ${SRCDIR}/etc ; ${MAKE} -VCAP_MKDB_ENDIAN` ;  pwd_arg=`cd ${SRCDIR}/etc ;
  ${MAKE} -VPWD_MKDB_ENDIAN` ;  sed -e "s/%VERSION%/${PKG_VERSION}/"  -e
  "s/%PKGNAME%/kernel-${INSTALLKERNEL:tl}${:U""}/"  -e "s/%KERNELDIR%/kernel/"
  -e "s/%COMMENT%/FreeBSD ${INSTALLKERNEL} kernel ${:U""}/"  -e
  "s/%DESC%/FreeBSD ${INSTALLKERNEL} kernel ${:U""}/"  -e
  "s/%CAP_MKDB_ENDIAN%/$${cap_arg}/g"  -e "s/%PWD_MKDB_ENDIAN%/$${pwd_arg}/g"
  ${SRCDIR}/release/packages/kernel.ucl  >
  ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U""}.ucl ;  awk -F\"
  '  /name/ { printf("===> Creating %s-", $$2); next }  /version/ {print $$2;
  next } '  ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U""}.ucl ;
  ${PKG_CMD} -o ABI_FILE=${WSTAGEDIR}/bin/sh -o ALLOW_BASE_SHLIBS=yes  create
  -M ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U""}.ucl  -p
  ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U""}.plist  -r
  ${KSTAGEDIR}/${DISTDIR}  -o ${REPODIR}/$$(${PKG_CMD} -o
  ABI_FILE=${WSTAGEDIR}/bin/sh config ABI)/${PKG_VERSION}" 

make[1]: "/pool/sources/11.2-RELENG/src/Makefile.inc1" line 1517: Unassociated
shell command "@cd ${KSTAGEDIR}/${DISTDIR} ;  awk -f
  ${SRCDIR}/release/scripts/mtree-to-plist.awk  -v kernel=yes -v
  _kernconf=${INSTALLKERNEL}  ${KSTAGEDIR}/kernel.meta ;  cap_arg=`cd
  ${SRCDIR}/etc ; ${MAKE} -VCAP_MKDB_ENDIAN` ;  pwd_arg=`cd ${SRCDIR}/etc ;
  ${MAKE} -VPWD_MKDB_ENDIAN` ;  sed -e "s/%VERSION%/${PKG_VERSION}/"  -e
  "s/%PKGNAME%/kernel-${INSTALLKERNEL:tl}${:U-debug}/"  -e
  "s/%KERNELDIR%/kernel/"  -e "s/%COMMENT%/FreeBSD ${INSTALLKERNEL} kernel
  ${:U-debug}/"  -e "s/%DESC%/FreeBSD ${INSTALLKERNEL} kernel ${:U-debug}/"  -e
  "s/%CAP_MKDB_ENDIAN%/$${cap_arg}/g"  -e "s/%PWD_MKDB_ENDIAN%/$${pwd_arg}/g"
  ${SRCDIR}/release/packages/kernel.ucl  >
  ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U-debug}.ucl ;  awk -F\"
  '  /name/ { printf("===> Creating %s-", $$2); next }  /version/ {print $$2;
  next } '  ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U-debug}.ucl ;
  ${PKG_CMD} -o ABI_FILE=${WSTAGEDIR}/bin/sh -o ALLOW_BASE_SHLIBS=yes  create
  -M ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U-debug}.ucl  -p
  ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U-debug}.plist  -r
  ${KSTAGEDIR}/${DISTDIR}  -o ${REPODIR}/$$(${PKG_CMD} -o
  ABI_FILE=${WSTAGEDIR}/bin/sh config ABI)/${PKG_VERSION}" 

make[1]: Fatal errors encountered -- cannot continue 
make[1]: stopped in /pool/sources/11.2-RELENG/src
___
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 booting from external USB pen drive

2018-07-06 Thread Emmanuel Vadot 

On 2018-07-06 09:34, Bjoern A. Zeeb wrote:

On 6 Jul 2018, at 6:34, Emmanuel Vadot wrote:

 FAT12 can work with all EFI implementation, the problem is the size 
of the FAT12 part that sometimes causes problems.


Ok, now that we are all on the same page, changing it to newfs_msdos
-F 32  did not make a change to my problem of the boot menu changing
to the blank screen and immediately returning to itself.

/bz


 What boot menu and what blank screen ?

--
Emmanuel Vadot  
___
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: atomic changes break drm-next-kmod?

2018-07-06 Thread Niclas Zeising 

On 07/06/18 00:02, Warner Losh wrote:



On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin > wrote:


On 7/5/18 12:36 PM, Konstantin Belousov wrote:
 > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky wrote:
 >> On 07/05/18 20:59, Hans Petter Selasky wrote:
 >>> On 07/05/18 19:48, Pete Wright wrote:
 
 
  On 07/05/2018 10:10, John Baldwin wrote:
 > On 7/3/18 5:10 PM, Pete Wright wrote:
 >>
 >> On 07/03/2018 15:56, John Baldwin wrote:
 >>> On 7/3/18 3:34 PM, Pete Wright wrote:
  On 07/03/2018 15:29, John Baldwin wrote:
 > That seems like kgdb is looking at the wrong CPU.  Can
you use
 > 'info threads' and look for threads not stopped in
'sched_switch'
 > and get their backtraces?  You could also just do 'thread
apply
 > all bt' and put that file at a URL if that is easiest.
 >
  sure thing John - here's a gist of "thread apply all bt"
 
 
https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed

 >>> That doesn't look right at all.  Are you sure the kernel
matches the
 >>> vmcore?  Also, which kgdb version are you using?
 >>>
 >> yea i agree that doesn't look right at all.  here is my setup:
 >>
 >> $ which kgdb
 >> /usr/bin/kgdb
 >> $ kgdb
 >> GNU gdb 6.1.1 [FreeBSD]
 >> $ ls -lh /var/crash/vmcore.1
 >> -rw---  1 root  wheel   1.6G Jul  3 15:03
/var/crash/vmcore.1
 >> $ ls -l /usr/lib/debug/boot/kernel/kernel.debug
 >> -r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54
 >> /usr/lib/debug/boot/kernel/kernel.debug
 >>
 >> and i invoke kgdb like so:
 >> $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug
/var/crash/vmcore.1
 >>
 >> here's a gist of my full gdb session:
 >> http://termbin.com/krsn
 >>
 >> dunno - maybe i have a bad core dump?  regardless, more than
happy to
 >> help so let me know if i should try anything else or patches
etc..
 > Can you try installing gdb from ports and using
/usr/local/bin/kgdb?
 >
 
  that seems to have done the trick, at least the output looks more
  encouraging.
 
    --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
  KDB: enter: panic
 
  __curthread () at ./machine/pcpu.h:231
  231        __asm("movq %%gs:%1,%0" : "=r" (td)
 
 
  here's my full kgdb session:
  http://termbin.com/qa4f
 
  i don't see any threads not in "sched_switch" though :(
 >>>
 >>> Hi,
 >>>
 >>> The problem may be that the patch to enable atomic inlining of all
 >>> macros forgot to set the SMP keyword which means SMP is not
defined at
 >>> all for KLD's so all non-kernel atomic usage is with MPLOCKED
empty!
 > Problem is that out-of-tree modules build does not have opt*.h files
 > from the kernel.  UP config is a valid one, flipping some option's
 > default value does not solve the problem.

Yes, but using the lock prefix in a generic module is ok (it will still
work, just not quite as fast) whereas the lack of lock is fatal on
SMP.  I would amend Hans' patch slightly to honor the opt_* setting
for KLD_TIED (but that is only true if KLD_TIED means "built as part of
a kernel build, so has valid opt_foo.h headers" and not
'a standalone module where someone put MODULES_TIED=1 on the command
line
to make').


I agree with this default. It's sensible to default to (a) the most 
popular thing and (b) thing that always works, especially when (a) and 
(b) are identical.


Don't make me start the "Do we really need an SMP option, why not make 
it always on" thread :) The number of relevant uniprocessor x86 boxes 
that benefit from omitting SMP is so small as to be irrelevant, IMHO. A 
MP kernel runs just fine on them...


Warner


Where are we on this?
It is important to get it fixed, it's already been 4 days, which means 4 
days of all modern FreeBSD desktop systems being broken, and possibly 
other systems with kernel modules from ports as well.



Another question, how hard would it be to expose how the kernel was 
built to modules built from ports, so that they can figure out stuff 
like SMP and others, that might affect the module build?


Regards
--
Niclas
___
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 booting from external USB pen drive

2018-07-06 Thread Bjoern A. Zeeb 

On 6 Jul 2018, at 6:34, Emmanuel Vadot wrote:

 FAT12 can work with all EFI implementation, the problem is the size 
of the FAT12 part that sometimes causes problems.


Ok, now that we are all on the same page, changing it to newfs_msdos -F 
32  did not make a change to my problem of the boot menu changing to the 
blank screen and immediately returning to itself.


/bz
___
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 booting from external USB pen drive

2018-07-06 Thread Emmanuel Vadot 

On 2018-07-06 04:17, Warner Losh wrote:

On Thu, Jul 5, 2018 at 7:11 PM, Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:


> On 5 Jul 2018, at 18:18, Rodney W. Grimes wrote:
>
> > [ Charset UTF-8 unsupported, converting... ]
> >> On 5 Jul 2018, at 17:19, Warner Losh wrote:
> >>
> >>> FAT12 isn't good for UEFI. Use FAT16 or FAT32.
> >>
> >> We use it for the default image we built and the wiki suggests it as
> >> well at https://wiki.freebsd.org/UEFI#CD.2FDVD_Boot_under_UEFI
> >
> > IIRC FreeBSD recently cnahged to FAT16 or 32 on these
> > as the size got pushed up to be larger than what FAT12
> > can access.
>
> https://svnweb.freebsd.org/base/head/stand/efi/boot1/
generate-fat.sh?annotate=332561#l45
>
> nope.

That is not the code we build release images with,
that is Warners tests for the boot loader.



No, that's the actual code that generates boot1.efiffat.

Warner


 Yup, and EFI have no problem at all with this.
 FAT12 can work with all EFI implementation, the problem is the size of 
the FAT12 part that sometimes causes problems.
 Rod, you are refering to the arm images which do not uses makefs or 
generate-fat.sh but using md device and newfs_msdos.


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