Re: FreeBSD has a politics problem

2018-03-18 Thread Erich Dollansky
Hi,

On Sun, 18 Mar 2018 06:43:47 +0100
"Meixner, Johannes"  wrote:

> You must have never been to Southern Germany or Austria.

and Alaska.

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


network performance over 1GBps links degraded

2018-03-18 Thread Gary Jennejohn

I have two computers, both with 1Gbps interfaces plugged into a
1Gb switch.  One computer is running FreeBSD HEAD and the other
some version of Linux.  Under FreeBSD I have re0 and under Linux
I don't know what the hardware is.

Both interfaces are using a MTU of 4088 because that's the
maximum my re0 supports.

I tend to copy files from one to the other using ftp fairly
frequently.

I noticed that the transfer speed has dropped to only about
12MBps.  I'm used to seeing about 27MBps during the ftp
transfers.

I also observed the drop in transfer speed between FreeBSD and
a Windows 10 computer.  Formerly, I was seeing about 30MBps.
Windows 10 also has MTU 4088 set.

I tested with a FreeBSD kernel from March 7 and one from March
17, but both show the miserable performance.  Unfortunately, I
don't have any older kernels backed up.

I can't say exactly when the performance degraded, but possibly
there was some change to the kernel on or before March 7 which
caused it.

Has anyone else seen this?

There were several changes to the networking stack lately.

I wonder whether anyone has an idea what could be the cause of the
performance degredation, and what sysctls I could set to get the
old performance back.

-- 
Gary Jennejohn
___
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: network performance over 1GBps links degraded

2018-03-18 Thread Alex Dupre
Gary Jennejohn wrote:
> I have two computers, both with 1Gbps interfaces plugged into a
> 1Gb switch.  One computer is running FreeBSD HEAD and the other
> some version of Linux.  Under FreeBSD I have re0 and under Linux
> I don't know what the hardware is.
> 
> I noticed that the transfer speed has dropped to only about
> 12MBps.  I'm used to seeing about 27MBps during the ftp
> transfers.

Do you see "re0: watchdog timeout" errors?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

-- 
Alex Dupre
___
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: network performance over 1GBps links degraded

2018-03-18 Thread Gary Jennejohn
On Sun, 18 Mar 2018 11:48:32 +0100
Alex Dupre  wrote:

> Gary Jennejohn wrote:
> > I have two computers, both with 1Gbps interfaces plugged into a
> > 1Gb switch.  One computer is running FreeBSD HEAD and the other
> > some version of Linux.  Under FreeBSD I have re0 and under Linux
> > I don't know what the hardware is.
> > 
> > I noticed that the transfer speed has dropped to only about
> > 12MBps.  I'm used to seeing about 27MBps during the ftp
> > transfers.  
> 
> Do you see "re0: watchdog timeout" errors?
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724
> 

Thanks, but I just copied some 30GB between the FreeBSD and Windows
10 computer and didn't see a single error message.

I tried r330300, but the behavior didn't change.  Maybe I should go even
further back in time.

One possibilty is the new BIOS I installed on my Ryzen (FreeBSD) box.
I checked that the settings are all optimized, but who knows what Asus
changed?

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


[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT

2018-03-18 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700

Charlie Li  changed:

   What|Removed |Added

 CC||freebsd-current@FreeBSD.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: network performance over 1GBps links degraded

2018-03-18 Thread Gary Jennejohn
On Sun, 18 Mar 2018 12:21:54 +0100
Gary Jennejohn  wrote:

> On Sun, 18 Mar 2018 11:48:32 +0100
> Alex Dupre  wrote:
> 
> > Gary Jennejohn wrote:  
> > > I have two computers, both with 1Gbps interfaces plugged into a
> > > 1Gb switch.  One computer is running FreeBSD HEAD and the other
> > > some version of Linux.  Under FreeBSD I have re0 and under Linux
> > > I don't know what the hardware is.
> > > 
> > > I noticed that the transfer speed has dropped to only about
> > > 12MBps.  I'm used to seeing about 27MBps during the ftp
> > > transfers.
> > 
> > Do you see "re0: watchdog timeout" errors?
> > 
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724
> >   
> 
> Thanks, but I just copied some 30GB between the FreeBSD and Windows
> 10 computer and didn't see a single error message.
> 
> I tried r330300, but the behavior didn't change.  Maybe I should go even
> further back in time.
> 
> One possibilty is the new BIOS I installed on my Ryzen (FreeBSD) box.
> I checked that the settings are all optimized, but who knows what Asus
> changed?
> 

So, Stefan Esser (se@) hit me with a clue bat and asked what
ifconfig shows for the speed.

Well, it's 100baseTX.  Not too surprising that it maxes out at
12MBps.

Up until recently the speed was always automatically set to
1000baseTX.  AFAIK nothing has changed in regards to the hardware
(contollers, switches, etc.).

Anyway, I'll try setting mediaopts in rc.conf and see what happens.

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


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main

2018-03-18 Thread AN

Fyi, I started seeing this error today during buildworld compile.

FreeBSD BSD_12 12.0-CURRENT FreeBSD 12.0-CURRENT #15 r331021: Thu Mar 15 
16:30:40 EDT 2018 
root@BSD_12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL  amd64 1200060


# svnlite info
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 331135
Node Kind: directory
Schedule: normal
Last Changed Author: markj
Last Changed Rev: 331135
Last Changed Date: 2018-03-18 13:03:26 -0400 (Sun, 18 Mar 2018)
-

--- all_subdir_lib/libcasper ---
--- all_subdir_lib/libcasper/services/cap_sysctl ---
/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main

referenced by crt1.c:74 (/usr/src/lib/csu/amd64/crt1.c:74)
  /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_create
referenced by cap_sysctl.c:64 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:64)

  /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_add_string
referenced by cap_sysctl.c:65 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:65)

  /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_add_string
referenced by cap_sysctl.c:66 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:66)

  /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_add_number
referenced by cap_sysctl.c:67 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:67)

  /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_add_null
referenced by cap_sysctl.c:69 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:69)

  /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_add_number
referenced by cap_sysctl.c:71 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:71)

  /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_add_binary
referenced by cap_sysctl.c:73 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:73)

  /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
cap_xfer_nvlist
referenced by cap_sysctl.c:74 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:74)

  /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_get_number
referenced by cap_sysctl.c:77 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:77)

  /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_get_number
referenced by cap_sysctl.c:78 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:78)

  /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_destroy
referenced by cap_sysctl.c:79 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:79)

  /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_get_number
referenced by cap_sysctl.c:84 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:84)

  /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_get_binary
referenced by cap_sysctl.c:86 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:86)

  /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_destroy
referenced by cap_sysctl.c:91 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:91)

  /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
service_register
referenced by cap_sysctl.c:295 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:295)

  /tmp/cap_sysctl-cfa2f8.o:(init_casper_service)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_next
referenced by cap_sysctl.c:209 

(/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:209)

  /tmp/cap_sysctl-cfa2f8.o:(sysctl_limit)


/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
nvlist_get_number
referenced by cap_sysctl.c:212 

(/usr/src/lib

Re: /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main

2018-03-18 Thread O. Hartmann
Am Sun, 18 Mar 2018 13:19:08 -0400 (EDT)
AN  schrieb:

> Fyi, I started seeing this error today during buildworld compile.
> 
> FreeBSD BSD_12 12.0-CURRENT FreeBSD 12.0-CURRENT #15 r331021: Thu Mar 15 
> 16:30:40 EDT 2018 
> root@BSD_12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL  amd64 1200060
> 
> # svnlite info
> Path: .
> Working Copy Root Path: /usr/src
> URL: svn://svn.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 331135
> Node Kind: directory
> Schedule: normal
> Last Changed Author: markj
> Last Changed Rev: 331135
> Last Changed Date: 2018-03-18 13:03:26 -0400 (Sun, 18 Mar 2018)
> -
> 
> --- all_subdir_lib/libcasper ---
> --- all_subdir_lib/libcasper/services/cap_sysctl ---
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main
> >>> referenced by crt1.c:74 (/usr/src/lib/csu/amd64/crt1.c:74)
> >>>   /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start)  
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> nvlist_create
> >>> referenced by cap_sysctl.c:64   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:64)
> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)  
> 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> nvlist_add_string
> >>> referenced by cap_sysctl.c:65   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:65)
> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)  
> 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> nvlist_add_string
> >>> referenced by cap_sysctl.c:66   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:66)
> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)  
> 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> nvlist_add_number
> >>> referenced by cap_sysctl.c:67   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:67)
> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)  
> 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> nvlist_add_null
> >>> referenced by cap_sysctl.c:69   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:69)
> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)  
> 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> nvlist_add_number
> >>> referenced by cap_sysctl.c:71   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:71)
> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)  
> 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> nvlist_add_binary
> >>> referenced by cap_sysctl.c:73   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:73)
> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)  
> 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> cap_xfer_nvlist
> >>> referenced by cap_sysctl.c:74   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:74)
> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)  
> 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> nvlist_get_number
> >>> referenced by cap_sysctl.c:77   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:77)
> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)  
> 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> nvlist_get_number
> >>> referenced by cap_sysctl.c:78   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:78)
> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)  
> 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> nvlist_destroy
> >>> referenced by cap_sysctl.c:79   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:79)
> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)  
> 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> nvlist_get_number
> >>> referenced by cap_sysctl.c:84   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:84)
> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)  
> 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> nvlist_get_binary
> >>> referenced by cap_sysctl.c:86   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:86)
> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)  
> 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> nvlist_destroy
> >>> referenced by cap_sysctl.c:91   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:91)
> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)  
> 
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: 
> service_register
> >>> referenced by cap_sysctl.c:295   
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:295)
> >>>

Re: /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main

2018-03-18 Thread Mariusz Zaborski
Thank you for reporting - I'm checking it.
Do you use option MK_CASPER=no ?

On 18 March 2018 at 18:19, AN  wrote:
> Fyi, I started seeing this error today during buildworld compile.
>
> FreeBSD BSD_12 12.0-CURRENT FreeBSD 12.0-CURRENT #15 r331021: Thu Mar 15
> 16:30:40 EDT 2018 root@BSD_12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL
> amd64 1200060
>
> # svnlite info
> Path: .
> Working Copy Root Path: /usr/src
> URL: svn://svn.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 331135
> Node Kind: directory
> Schedule: normal
> Last Changed Author: markj
> Last Changed Rev: 331135
> Last Changed Date: 2018-03-18 13:03:26 -0400 (Sun, 18 Mar 2018)
> -
>
> --- all_subdir_lib/libcasper ---
> --- all_subdir_lib/libcasper/services/cap_sysctl ---
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main

 referenced by crt1.c:74 (/usr/src/lib/csu/amd64/crt1.c:74)
   /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_create

 referenced by cap_sysctl.c:64
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:64)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_add_string

 referenced by cap_sysctl.c:65
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:65)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_add_string

 referenced by cap_sysctl.c:66
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:66)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_add_number

 referenced by cap_sysctl.c:67
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:67)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_add_null

 referenced by cap_sysctl.c:69
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:69)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_add_number

 referenced by cap_sysctl.c:71
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:71)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_add_binary

 referenced by cap_sysctl.c:73
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:73)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> cap_xfer_nvlist

 referenced by cap_sysctl.c:74
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:74)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_get_number

 referenced by cap_sysctl.c:77
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:77)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_get_number

 referenced by cap_sysctl.c:78
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:78)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_destroy

 referenced by cap_sysctl.c:79
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:79)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_get_number

 referenced by cap_sysctl.c:84
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:84)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_get_binary

 referenced by cap_sysctl.c:86
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:86)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> nvlist_destroy

 referenced by cap_sysctl.c:91
>
> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:91)

   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>
>
> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
> service_

[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT

2018-03-18 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700

Conrad Meyer  changed:

   What|Removed |Added

 CC|freebsd-current@FreeBSD.org |c...@freebsd.org

--- Comment #3 from Conrad Meyer  ---
Please do not CC huge mailing lists on bugs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"


[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT

2018-03-18 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700

Charlie Li  changed:

   What|Removed |Added

 CC||freebsd-current@FreeBSD.org

--- Comment #5 from Charlie Li  ---
In that case I do have WITH_ZONEINFO_LEAPSECONDS_SUPPORT set in src.conf. This
setting also breaks databases/postgresql-server but it's a known quantity
there.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"


[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT

2018-03-18 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700

w.schwarzenf...@utanet.at changed:

   What|Removed |Added

 CC|freebsd-current@FreeBSD.org |w.schwarzenf...@utanet.at

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"


[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT

2018-03-18 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700

--- Comment #6 from Charlie Li  ---
Also could someone remove current@ again? I accidentally used a cached page to
comment and didn't pay attention to the CC list.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main

2018-03-18 Thread Mariusz Zaborski
I think r331137 fix the problem.

Thanks,
Mariusz

On 18 March 2018 at 18:29, O. Hartmann  wrote:
> Am Sun, 18 Mar 2018 13:19:08 -0400 (EDT)
> AN  schrieb:
>
>> Fyi, I started seeing this error today during buildworld compile.
>>
>> FreeBSD BSD_12 12.0-CURRENT FreeBSD 12.0-CURRENT #15 r331021: Thu Mar 15
>> 16:30:40 EDT 2018
>> root@BSD_12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL  amd64 1200060
>>
>> # svnlite info
>> Path: .
>> Working Copy Root Path: /usr/src
>> URL: svn://svn.freebsd.org/base/head
>> Relative URL: ^/head
>> Repository Root: svn://svn.freebsd.org/base
>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> Revision: 331135
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: markj
>> Last Changed Rev: 331135
>> Last Changed Date: 2018-03-18 13:03:26 -0400 (Sun, 18 Mar 2018)
>> -
>>
>> --- all_subdir_lib/libcasper ---
>> --- all_subdir_lib/libcasper/services/cap_sysctl ---
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main
>> >>> referenced by crt1.c:74 (/usr/src/lib/csu/amd64/crt1.c:74)
>> >>>   /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start)
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_create
>> >>> referenced by cap_sysctl.c:64
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:64)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_add_string
>> >>> referenced by cap_sysctl.c:65
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:65)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_add_string
>> >>> referenced by cap_sysctl.c:66
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:66)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_add_number
>> >>> referenced by cap_sysctl.c:67
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:67)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_add_null
>> >>> referenced by cap_sysctl.c:69
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:69)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_add_number
>> >>> referenced by cap_sysctl.c:71
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:71)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_add_binary
>> >>> referenced by cap_sysctl.c:73
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:73)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> cap_xfer_nvlist
>> >>> referenced by cap_sysctl.c:74
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:74)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_get_number
>> >>> referenced by cap_sysctl.c:77
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:77)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_get_number
>> >>> referenced by cap_sysctl.c:78
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:78)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_destroy
>> >>> referenced by cap_sysctl.c:79
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:79)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_get_number
>> >>> referenced by cap_sysctl.c:84
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:84)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_get_binary
>> >>> referenced by cap_sysctl.c:86
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:86)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> nvlist_destroy
>> >>> referenced by cap_sysctl.c:91
>> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:91)
>> >>>   /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname)
>>
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol:
>> service_register
>> >>> r

Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

2018-03-18 Thread bob prohaska
On Sun, Mar 11, 2018 at 10:43:58AM -1000, Jeff Roberson wrote:

> Also, if you could try going back to r328953 or r326346 and let me know if 
> the problem exists in either.  That would be very helpful.  If anyone is 

Not sure this is relevant, but r326343 is able to run a j4 buildworld
to completion on an RPi3 with 3 gigs of microSD-based swap. There are
periods of seeming distress at times (lots of swread, pfault state
in top along with high %idle) in top, but the compilation completes.

In contrast, r328953 could not complete buildworld using -j4. Buildworld
would stop, usually reporting c++ killed, apparently for want of swap,
even though swap usage never exceeded about 30% accoring to top.

The machine employs UFS filesystems, the kernel config can be seen at

http://www.zefox.net/~fbsd/rpi3/kernel_config/ZEFOX

Thanks for reading, I hope it's useful.

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


pcm1:virtual:dsp1.vp0: play interrupt timeout, channel dead

2018-03-18 Thread AN
FreeBSD BSD_12 12.0-CURRENT FreeBSD 12.0-CURRENT #12 r331138: Sun Mar 18 
15:09:37 EDT 2018 
root@BSD_12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL  amd64


I recently started to see strange behavior on 2 different machines and was 
wondering if anyone else has run into it.  Within the last few days, I 
have been experiencing a reproduceable problem with sound.  It happens in 
VLC and also in Virtualbox watching video in a browser.


I get the following log entry:

Mar 18 18:10:26 BSD_12 kernel: pcm1: chn_write(): pcm1:virtual:dsp1.vp0: 
play interrupt timeout, channel dead


and then sound is dead in all applications.  Any ideas what to do?

I tried the following:

rebuilt world and kernel several times
rebuilt libvorbis
rebuilt ffmpeg
rebuilt vlc
rebuilt Vbox and kmod

The only thing I can think of as a possible issue is an update to 
libvorbis recently, cc'ing ports just in case.


Is there a way to restart the audio subsystem without rebooting the 
machine?  Is there anymore info I can provide to troubleshoot?


# dmesg | grep pcm
pcm0:  at nid 3 on hdaa0
pcm1:  at nid 20,22,21,23 and 24,26 
on hdaa1

pcm2:  at nid 27 and 25 on hdaa1
pcm1: chn_write(): pcm1:virtual:dsp1.vp0: play interrupt timeout, channel 
dead



# pciconf -lv
hostb0@pci0:0:0:0:	class=0x06 card=0x7a341462 chip=0x14501022 
rev=0x00 hdr=0x00

vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-0fh) Root Complex'
class  = bridge
subclass   = HOST-PCI

hdac0@pci0:34:0:1:	class=0x040300 card=0xaa681545 chip=0xaa681002 
rev=0x00 hdr=0x00

vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]'
device = 'Cedar HDMI Audio [Radeon HD 5400/6300/7300 Series]'
class  = multimedia
subclass   = HDA


hdac1@pci0:36:0:3:	class=0x040300 card=0xda341462 chip=0x14571022 
rev=0x00 hdr=0x00

vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Family 17h (Models 00h-0fh) HD Audio Controller'
class  = multimedia
subclass   = HDA


Thanks in advance for any advice.
___
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: pcm1:virtual:dsp1.vp0: play interrupt timeout, channel dead

2018-03-18 Thread Theron Tarigo

On 03/18/18 18:52, Theron Tarigo wrote:

On 03/18/18 18:35, AN wrote:
Is there a way to restart the audio subsystem without rebooting the 
machine?
Building kernel with sound and snd_* as loadable modules should enable 
this to be accomplished with kldunload/kldload.  In my experience 
though all sound device files must be closed before unloading these 
modules to avoid some lockup issues.


___
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: pcm1:virtual:dsp1.vp0: play interrupt timeout, channel dead

2018-03-18 Thread Theron Tarigo

On 03/18/18 18:35, AN wrote:
Is there a way to restart the audio subsystem without rebooting the 
machine?
Building kernel with sound and snd_* as loadable modules should enable 
this to be accomplished with kldunload/kldload.  In my experience though 
all sound device files must be closed before unloading these modules to 
avoid some lockup issues.

___
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: pcm1:virtual:dsp1.vp0: play interrupt timeout, channel dead

2018-03-18 Thread Cy Schubert
In message <764e2df5-613d-a131-5d7d-6df545995...@gmail.com>, Theron 
Tarigo writ
es:
> On 03/18/18 18:35, AN wrote:
> > Is there a way to restart the audio subsystem without rebooting the 
> > machine?
> Building kernel with sound and snd_* as loadable modules should enable 
> this to be accomplished with kldunload/kldload.  In my experience though 
> all sound device files must be closed before unloading these modules to 
> avoid some lockup issues.

The other thing you might want to check out is if you multiboot your 
laptop that any non-FreeBSD operating system may put hardware into an 
inconsistent state. For example, my Acer laptop loses sound if I boot 
Windows then boot FreeBSD. The workaround is either adjust the HDA 
inputs/outputs through sysctl or simply power cycle the laptop.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
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: Strange ARC/Swap/CPU on yesterday's -CURRENT

2018-03-18 Thread Mark Millard
bob prohaska fbsd at www.zefox.net wrote on
Sun Mar 18 21:09:42 UTC 2018 :

> On Sun, Mar 11, 2018 at 10:43:58AM -1000, Jeff Roberson wrote:
> 
> > Also, if you could try going back to r328953 or r326346 and let me know if 
> > the problem exists in either.  That would be very helpful.  If anyone is 
> 
> Not sure this is relevant, but r326343 is able to run a j4 buildworld
> to completion on an RPi3 with 3 gigs of microSD-based swap. There are
> periods of seeming distress at times (lots of swread, pfault state
> in top along with high %idle) in top, but the compilation completes.
> 
> In contrast, r328953 could not complete buildworld using -j4. Buildworld
> would stop, usually reporting c++ killed, apparently for want of swap,
> even though swap usage never exceeded about 30% accoring to top.
> 
> The machine employs UFS filesystems, . . .


Sounds like -r326346 would be an interesting kernel to test (the
next check-in on head after -r326343, one of Jeff's check-ins).

-r328953 was just before Jeff's:

Author: jeff
Date: Tue Feb  6 22:10:07 2018
New Revision: 328954
URL: 
https://svnweb.freebsd.org/changeset/base/328954


Log:
  Use per-domain locks for vm page queue free.  Move paging control from
  global to per-domain state.  Protect reservations with the free lock
  from the domain that they belong to.  Refactor to make vm domains more
  of a first class object.



So, if -r328953 behaves oddly and -r326343 does not, then the
question is if -r326346 makes the difference:

Author: jeff
Date: Tue Nov 28 23:18:35 2017
New Revision: 326346
URL: 
https://svnweb.freebsd.org/changeset/base/326346


Log:
  Move domain iterators into the page layer where domain selection should take
  place.  This makes the majority of the phys layer explicitly domain specific.


(Unfortunately my FreeBSD time is currently greatly limited.)

It is also interesting that your test context is UFS. O. Hartmann
has reported problems for UFS in a more modern version: -r330608 .


===
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: Strange ARC/Swap/CPU on yesterday's -CURRENT

2018-03-18 Thread bob prohaska
On Sun, Mar 18, 2018 at 05:54:30PM -0700, Mark Millard wrote:
> bob prohaska fbsd at www.zefox.net wrote on
> Sun Mar 18 21:09:42 UTC 2018 :
> 
> > On Sun, Mar 11, 2018 at 10:43:58AM -1000, Jeff Roberson wrote:
> > 
> > > Also, if you could try going back to r328953 or r326346 and let me know 
> > > if 
> > > the problem exists in either.  That would be very helpful.  If anyone is 
> > 
> > Not sure this is relevant, but r326343 is able to run a j4 buildworld
> > to completion on an RPi3 with 3 gigs of microSD-based swap. There are
> > periods of seeming distress at times (lots of swread, pfault state
> > in top along with high %idle) in top, but the compilation completes.
> > 
> > In contrast, r328953 could not complete buildworld using -j4. Buildworld
> > would stop, usually reporting c++ killed, apparently for want of swap,
> > even though swap usage never exceeded about 30% accoring to top.
> > 
> > The machine employs UFS filesystems, . . .
> 
> 
> Sounds like -r326346 would be an interesting kernel to test (the
> next check-in on head after -r326343, one of Jeff's check-ins).
> 
> -r328953 was just before Jeff's:
> 

My intent was to try 326346. Somehow 326343 arrived in its place. 
Do architectures affect revision numbers? I thought not, but... 


> Author: jeff
> Date: Tue Feb  6 22:10:07 2018
> New Revision: 328954
> URL: 
> https://svnweb.freebsd.org/changeset/base/328954
> 
> 
> Log:
>   Use per-domain locks for vm page queue free.  Move paging control from
>   global to per-domain state.  Protect reservations with the free lock
>   from the domain that they belong to.  Refactor to make vm domains more
>   of a first class object.
> 
> 
> 
> So, if -r328953 behaves oddly and -r326343 does not, then the
> question is if -r326346 makes the difference:
> 
> Author: jeff
> Date: Tue Nov 28 23:18:35 2017
> New Revision: 326346
> URL: 
> https://svnweb.freebsd.org/changeset/base/326346
> 
> 
> Log:
>   Move domain iterators into the page layer where domain selection should take
>   place.  This makes the majority of the phys layer explicitly domain 
> specific.
> 
> 
> (Unfortunately my FreeBSD time is currently greatly limited.)
> 
> It is also interesting that your test context is UFS. O. Hartmann
> has reported problems for UFS in a more modern version: -r330608 .
> 

When "out of swap" problems appeared I cobbled up a custom kernel,
in the hope that a smaller kernel might help. It has since developed
that the custom kernel can't boot, but GENERIC still boots. The system 
is now running a j4 buildworld on r331153 with a GENERIC kernel
to see if maybe the problem has already been fixed in a way that
was obscured by the customization. The kernel config is at
http://www.zefox.net/~fbsd/rpi3/kernel_config/ZEFOX

Thanks for reading,

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