boot hang at r339386

2018-10-18 Thread Mike Tancsa 

On r339386 I am seeing a 100% hang at boot up time.  Boot ends at

Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-ALPHA10 r339415 GENERIC amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on
LLVM 6.0.1)
WARNING: WITNESS option enabled, expect reduced performance.
VT(vga): resolution 640x480
CPU: AMD Ryzen 5 1600X Six-Core Processor    (3593.34-MHz
K8-class CPU)
  Origin="AuthenticAMD"  Id=0x800f11  Family=0x17  Model=0x1  Stepping=1
 
Features=0x178bfbff
 
Features2=0x7ed8320b
  AMD Features=0x2e500800
  AMD
Features2=0x35c233ff
  Structured Extended
Features=0x209c01a9
  XSAVE Features=0xf
  AMD Extended Feature Extensions ID EBX=0x1007
  SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
  TSC: P-state invariant, performance statistics
real memory  = 34359738368 (32768 MB)
avail memory = 33255837696 (31715 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs
FreeBSD/SMP: 1 package(s) x 2 cache groups x 3 core(s) x 2 hardware threads
random: unblocking device.
Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid
Length but zero Address: 0x/0x1 (20181003/tbfadt-796)
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-55 on motherboard
Launching APs: 10 1 2 3 9 11 8 5 7 6 4
Timecounter "TSC-low" frequency 1796668938 Hz quality 1000
random: entropy device external interface
module_register_init: MOD_LOAD (vesa, 0x810e6a80, 0) error 19
kbd1 at kbdmux0
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
netmap: loaded module
[ath_hal] loaded
nexus0
vtvga0:  on motherboard
aesni0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard

Adding boot verbose, shows the lines below before the hang.


ACPI: 7 ACPI AML tables successfully acquired and loaded
PCIe: Memory Mapped configuration base @ 0xf800

The box is hard locked up and I cannot break to debugger either.

Going back to r339385 works. But going to the next commit hangs the box

https://lists.freebsd.org/pipermail/svn-src-head/2018-October/118853.html


    ---Mike




-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot hang at r339386

2018-10-18 Thread Konstantin Belousov 
On Thu, Oct 18, 2018 at 11:12:11AM -0400, Mike Tancsa wrote:
> 
> On r339386 I am seeing a 100% hang at boot up time.  Boot ends at
> 
> Copyright (c) 1992-2018 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>     The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-ALPHA10 r339415 GENERIC amd64
> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on
> LLVM 6.0.1)
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(vga): resolution 640x480
> CPU: AMD Ryzen 5 1600X Six-Core Processor    (3593.34-MHz
> K8-class CPU)
>   Origin="AuthenticAMD"  Id=0x800f11  Family=0x17  Model=0x1  Stepping=1
>  
> Features=0x178bfbff
>  
> Features2=0x7ed8320b
>   AMD Features=0x2e500800
>   AMD
> Features2=0x35c233ff
>   Structured Extended
> Features=0x209c01a9
>   XSAVE Features=0xf
>   AMD Extended Feature Extensions ID EBX=0x1007
>   SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
>   TSC: P-state invariant, performance statistics
> real memory  = 34359738368 (32768 MB)
> avail memory = 33255837696 (31715 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs
> FreeBSD/SMP: 1 package(s) x 2 cache groups x 3 core(s) x 2 hardware threads
> random: unblocking device.
> Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid
> Length but zero Address: 0x/0x1 (20181003/tbfadt-796)
> ioapic0  irqs 0-23 on motherboard
> ioapic1  irqs 24-55 on motherboard
> Launching APs: 10 1 2 3 9 11 8 5 7 6 4
> Timecounter "TSC-low" frequency 1796668938 Hz quality 1000
> random: entropy device external interface
> module_register_init: MOD_LOAD (vesa, 0x810e6a80, 0) error 19
> kbd1 at kbdmux0
> random: registering fast source Intel Secure Key RNG
> random: fast provider: "Intel Secure Key RNG"
> netmap: loaded module
> [ath_hal] loaded
> nexus0
> vtvga0:  on motherboard
> aesni0:  on motherboard
> cryptosoft0:  on motherboard
> acpi0:  on motherboard
> 
> Adding boot verbose, shows the lines below before the hang.
> 
> 
> ACPI: 7 ACPI AML tables successfully acquired and loaded
> PCIe: Memory Mapped configuration base @ 0xf800
> 
> The box is hard locked up and I cannot break to debugger either.
> 
> Going back to r339385 works. But going to the next commit hangs the box
> 
> https://lists.freebsd.org/pipermail/svn-src-head/2018-October/118853.html

Try the patch at https://reviews.freebsd.org/D17612
___
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"

vnet & firewalls in 12.0

2018-10-18 Thread Ernie Luzar 
Wanting to get a head start on using 12.0 and vnet jails with in jail 
firewall.


1. Will Vimage be compiled as a module in the 12.0 kernel and be 
included in the base system release?


1.a. Has the boot time console log message about vimage being "highly 
experimental" been removed?


2. Has the pf firewall been fixed so it can now run in a vnet jail or 
multiple vnet jails with out concern for which firewall is running on 
the host?


2.a. Is each vnet/pf log only viewable from it's vnet jail console?

2.b. Will pf/kernel module auto load on first call from a vnet jail?

2.c. Does vnet/pf NAT work?

3. Does the ipfw firewall still have the 11.x release mandatory 
requirements that the host must also be running ipfw for the vnet jailed 
ipfw to work?


3.a. Are all vnet/ipfw log messages still intermixed with the host's 
ipfw log messages?


3.b. Does vnet/ipfw NAT work?

4. Has any work been done to ipf (ipfilter) so it will function when 
used in a vnet jail?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot hang at r339386 (solved)

2018-10-18 Thread Mike Tancsa 
On 10/18/2018 2:26 PM, Konstantin Belousov wrote:
> On Thu, Oct 18, 2018 at 11:12:11AM -0400, Mike Tancsa wrote:
>> On r339386 I am seeing a 100% hang at boot up time.  Boot ends at
>>
>> Going back to r339385 works. But going to the next commit hangs the box
>>
>> https://lists.freebsd.org/pipermail/svn-src-head/2018-October/118853.html
> Try the patch at https://reviews.freebsd.org/D17612
>
>
Looks good both on my Ryzen and EPYC based boards!  Thanks


Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/amd64/amd64/pmap.c
|===
|--- sys/amd64/amd64/pmap.c
|+++ sys/amd64/amd64/pmap.c
--
Patching file sys/amd64/amd64/pmap.c using Plan A...
Hunk #1 succeeded at 637.
Hunk #2 succeeded at 7099.
Hunk #3 succeeded at 7143.
Hunk #4 succeeded at 7156.
Hunk #5 succeeded at 7325.
Hunk #6 succeeded at 7448.
Hunk #7 succeeded at 7478.
Hunk #8 succeeded at 7506.
Hunk #9 succeeded at 7521.
Hunk #10 succeeded at 7530.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/amd64/include/pmap.h
|===
|--- sys/amd64/include/pmap.h
|+++ sys/amd64/include/pmap.h
--
Patching file sys/amd64/include/pmap.h using Plan A...
Hunk #1 succeeded at 430.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--
|Index: sys/amd64/pci/pci_cfgreg.c
|===
|--- sys/amd64/pci/pci_cfgreg.c
|+++ sys/amd64/pci/pci_cfgreg.c
--
Patching file sys/amd64/pci/pci_cfgreg.c using Plan A...
Hunk #1 succeeded at 271.
done


    ---Mike

-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot hang at r339386 (solved)

2018-10-18 Thread Mike Tancsa 
On 10/18/2018 2:50 PM, Mike Tancsa wrote:
> On 10/18/2018 2:26 PM, Konstantin Belousov wrote:
>> On Thu, Oct 18, 2018 at 11:12:11AM -0400, Mike Tancsa wrote:
>>> On r339386 I am seeing a 100% hang at boot up time.  Boot ends at
>>>
>>> Going back to r339385 works. But going to the next commit hangs the box
>>>
>>> https://lists.freebsd.org/pipermail/svn-src-head/2018-October/118853.html
>> Try the patch at https://reviews.freebsd.org/D17612
>>
>>
> Looks good both on my Ryzen and EPYC based boards!  Thanks
>


Also tested on a PCEngines APU and looks good.

---<>---
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-ALPHA10 #4 r339418M: Thu Oct 18 14:37:48 EDT 2018
   
mdtan...@nanobsd2.sentex.ca:/pxe/12/obj/pxe/12/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on
LLVM 6.0.1)
VT(vga): resolution 640x480
CPU: AMD GX-412TC SOC    (998.15-MHz
K8-class CPU)
  Origin="AuthenticAMD"  Id=0x730f01  Family=0x16  Model=0x30  Stepping=1
 
Features=0x178bfbff
 
Features2=0x3ed8220b
  AMD Features=0x2e500800
  AMD
Features2=0x1d4037ff
  Structured Extended Features=0x8
  XSAVE Features=0x1
  SVM: NP,NRIP,AFlush,DAssist,NAsids=8
  TSC: P-state invariant, performance statistics
real memory  = 2012930048 (1919 MB)
avail memory = 1909755904 (1821 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
random: unblocking device.
ioapic1: Changing APIC ID to 5
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-55 on motherboard
Launching APs: 1 2 3
Timecounter "TSC" frequency 998147285 Hz quality 1000
random: entropy device external interface
netmap: loaded module
[ath_hal] loaded
module_register_init: MOD_LOAD (vesa, 0x8112ec50, 0) error 19
kbd0 at kbdmux0
nexus0
vtvga0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)

-- 
---
Mike Tancsa, tel +1 519 651 3400 x203
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   

___
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: vnet & firewalls in 12.0

2018-10-18 Thread Michael Zhilin 
Hi Ernie,

On Thu, Oct 18, 2018 at 9:36 PM Ernie Luzar  wrote:

> Wanting to get a head start on using 12.0 and vnet jails with in jail
> firewall.
>
> 1. Will Vimage be compiled as a module in the 12.0 kernel and be
> included in the base system release?
>

I suppose it's part of GENERIC kernel configuration


> 1.a. Has the boot time console log message about vimage being "highly
> experimental" been removed?
>

I don't see in dmesg such notification. 12-ALPHA3


> 2. Has the pf firewall been fixed so it can now run in a vnet jail or
> multiple vnet jails with out concern for which firewall is running on
> the host?
>
> 2.a. Is each vnet/pf log only viewable from it's vnet jail console?
>
> 2.b. Will pf/kernel module auto load on first call from a vnet jail?
>
> 2.c. Does vnet/pf NAT work?
>
> 3. Does the ipfw firewall still have the 11.x release mandatory
> requirements that the host must also be running ipfw for the vnet jailed
> ipfw to work?
>
> 3.a. Are all vnet/ipfw log messages still intermixed with the host's
> ipfw log messages?
>
> 3.b. Does vnet/ipfw NAT work?
>

I use NAT via netgraph+ipfw. it works fine (why not?). I'm patching "jng"
to add "nat" feature.


> 4. Has any work been done to ipf (ipfilter) so it will function when
> used in a vnet jail?
> ___
> 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"

Expected?: "failed: Miscompare for aalgo=hmac/sha1 ealgo=camellia-cb" 12.0-ALPHA10 kernel with pre-openssl update -r339076 head?

2018-10-18 Thread Mark Millard 
As part of helping to track down a powerpc64 system
crash when "kyua test -k /usr/tests/Kyuafile" is run
I substituted into a -r339076 context official kernel
materials from:

https://download.freebsd.org/ftp/snapshots/powerpc/powerpc64/12.0-ALPHA10/kernel*.txz

This does lead to kyua reporting:

sys/geom/class/eli/init_test:init_a  ->  failed: Miscompare for aalgo=hmac/sha1 
ealgo=camellia-cbc keylen=192 sec=8192  [275.805s]

that had been passing with just my buildworld buildkernel
materials for -r339076 . (So far in the run it is the only
such report.)

Is this difference in this odd context expected/reasonable?
Should I ignore it?

(I have no reason to normally run such a odd mix of vintages
of world vs. kernel materials. I'm just checking if the
crashing is somehow specific to my builds or not.)


===
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: vnet & firewalls in 12.0

2018-10-18 Thread Julian Elischer 

I will only discuss ipfw.. I dont' use pf.


On 18/10/18 11:33 am, Ernie Luzar wrote:
Wanting to get a head start on using 12.0 and vnet jails with in 
jail firewall.


1. Will Vimage be compiled as a module in the 12.0 kernel and be 
included in the base system release?

it's in base.. not  a module


1.a. Has the boot time console log message about vimage being 
"highly experimental" been removed?


2. Has the pf firewall been fixed so it can now run in a vnet jail 
or multiple vnet jails with out concern for which firewall is 
running on the host?


2.a. Is each vnet/pf log only viewable from it's vnet jail console?

2.b. Will pf/kernel module auto load on first call from a vnet jail?

2.c. Does vnet/pf NAT work?



3. Does the ipfw firewall still have the 11.x release mandatory 
requirements that the host must also be running ipfw for the vnet 
jailed ipfw to work?

never heard about that..
effectively each network stack can have its own firewall. The ipfw 
module must be loaded so it will be 'hooked into' each stack.

whether you use it or not is up to you.


3.a. Are all vnet/ipfw log messages still intermixed with the host's 
ipfw log messages?
that is probably the case.  there is no per-jail kernel logging 
facility. (Sounds like a good idea!  send patches!)


3.b. Does vnet/ipfw NAT work?

last I checked it did.



4. Has any work been done to ipf (ipfilter) so it will function when 
used in a vnet jail?

I don't know how many people are using that... not a lot.


___
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: vnet & firewalls in 12.0

2018-10-18 Thread Kristof Provost 

On 18 Oct 2018, at 11:33, Ernie Luzar wrote:
Wanting to get a head start on using 12.0 and vnet jails with in jail 
firewall.


1. Will Vimage be compiled as a module in the 12.0 kernel and be 
included in the base system release?


vimage is a kernel option, not a module. It affects the entire kernel, 
and cannot be loaded as a module. It’s either enabled or not (and 
it’s enabled in 12.0).


1.a. Has the boot time console log message about vimage being "highly 
experimental" been removed?



Yes. It was removed around the time it was enabled by default.

2. Has the pf firewall been fixed so it can now run in a vnet jail or 
multiple vnet jails with out concern for which firewall is running on 
the host?



Yes. The automated pf tests rely on vimage.


2.a. Is each vnet/pf log only viewable from it's vnet jail console?

Yes, assuming you mean pflog output. Log files can of course be read 
from the host.



2.b. Will pf/kernel module auto load on first call from a vnet jail?

No. The decision to load the pf module is made by the host. If the 
module is not loaded no jail will be able to use it. Jails may not load 
kernel modules, for obvious reasons.



2.c. Does vnet/pf NAT work?


Yes.

Best regards,
Kristof
___
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 "installworld" fails if not upgrading (e.g. building via Crochet)

2018-10-18 Thread Karl Denninger 
svn updated this morning

Attempting to build 12 via Crochet fails with an error about the "ntpd"
user being missing during install.

Setting "-DDB_FROM_SRC" allows the install to complete.

I'm not sure where it's getting the base check from since this is a new
build into "empty" media (not an upgrade) -- should the "DB_FROM_SRC" be
detected on its own or is this just a Crochet screwball thing?

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: fuser does not list id of processes that have a file

2018-10-18 Thread Mateusz Guzik 
On 10/17/18, Ali Abdallah  wrote:
>> diff --git a/usr.bin/fstat/fuser.c b/usr.bin/fstat/fuser.c
>> index b4225328fc1f..17d06f1c5b13 100644
>> --- a/usr.bin/fstat/fuser.c
>>  +++ b/usr.bin/fstat/fuser.c
>>  @@ -92,7 +92,7 @@ struct consumer {
>>STAILQ_ENTRY(consumer)  next;
>> };
>> struct reqfile {
>> -   uint32_tfsid;
>>  +   uint64_tfsid;
>>uint64_tfileid;
>>const char  *name;
>>STAILQ_HEAD(, consumer) consumers;
>
> The above patch does not resolve the problem for me.
>

Are you sure you recompiled and reinstalled the tool with the patch applied?
You can recompile and install like this:
# make -j 3 clean all install

If this indeed still does not work, can you show output of:
uname -m
mount

I tested on zfs, perhaps there is something extra going on on other filesystems.

-- 
Mateusz Guzik 
___
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: Expected?: "failed: Miscompare for aalgo=hmac/sha1 ealgo=camellia-cb" 12.0-ALPHA10 kernel with pre-openssl update -r339076 head?

2018-10-18 Thread Mark Millard 



On 2018-Oct-18, at 12:12 PM, Mark Millard  wrote:

> As part of helping to track down a powerpc64 system
> crash when "kyua test -k /usr/tests/Kyuafile" is run
> I substituted into a -r339076 context official kernel
> materials from:
> 
> https://download.freebsd.org/ftp/snapshots/powerpc/powerpc64/12.0-ALPHA10/kernel*.txz
> 
> This does lead to kyua reporting:
> 
> sys/geom/class/eli/init_test:init_a  ->  failed: Miscompare for 
> aalgo=hmac/sha1 ealgo=camellia-cbc keylen=192 sec=8192  [275.805s]
> 
> that had been passing with just my buildworld buildkernel
> materials for -r339076 . (So far in the run it is the only
> such report.)
> 
> Is this difference in this odd context expected/reasonable?
> Should I ignore it?
> 
> (I have no reason to normally run such a odd mix of vintages
> of world vs. kernel materials. I'm just checking if the
> crashing is somehow specific to my builds or not.)

For reference:

My normal kernel build is via devel/powerpc64-xtoolchain-gcc
but I've built a -r339076 based kernel from my sources via
gcc 4.2.1 and the system binutils ( world still at -r339076
via devel/powerpc-xtoolchain-gcc ). Under that kernel kyua
reported:

sys/geom/class/eli/init_test:init_a  ->  failed: Miscompare for 
aalgo=hmac/ripemd160 ealgo=camellia-cbc keylen=128 sec=1024  [465.515s]

(A different, far later step for the failure?)

So apparently compiler/toolchains matter even when the
sources are the same.


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