Re: virtualbox 5.2.20 triggers panic with FreeBSD 12.0-ALPHA10 r339432

2018-10-19 Thread Matthew D. Fuller
On Fri, Oct 19, 2018 at 03:47:40PM -0700 I heard the voice of
Don Lewis, and lo! it spake thus:
>
> The first is that when I attempt to start a Virtualbox VM, the
> system panics.

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


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
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: virtualbox 5.2.20 triggers panic with FreeBSD 12.0-ALPHA10 r339432

2018-10-19 Thread Don Lewis
On 19 Oct, Don Lewis wrote:
> On 20 Oct, Graham Perrin wrote:
>> On 19/10/2018 23:47, Don Lewis wrote:
>> 
>>> … when I attempt to start a Virtualbox VM, the system panics. … (guest) 
>>> Windows 7 with
>> networking configured as > NAT and the underlying adapter being Intel 
>> PRO/1000
>> MT Desktop (82540EM). …
>> 
>> No panic here. 32-bit Windows 7 guest with the same virtual adapter.
>> 
>> $ date ; uname -v
>> Sat 20 Oct 2018 00:15:49 BST
>> FreeBSD 12.0-BETA1 r339438 GENERIC
>> $ pkg query '%o %v %R' virtualbox-ose virtualbox-ose-kmod
>> emulators/virtualbox-ose 5.2.20 poudriere
>> emulators/virtualbox-ose-kmod 5.2.20 poudriere
>> $
>> 
>> If you have not already done so, try building and installing from ports.
> 
> I'm using locally built packages and the poudriere jail is the exactly
> same source revision.

My camera isn't working at the moment, so here is a partial,
hand-transcribed DDB backtrace:

... looks like something nearby ng_ether_ifnet_arrival_cookie()
ng_ether_ifnet_arrival_cookie()
... looks like something nearby ng_ether_ifnet_arrival_cookie()
supdrvIOCtlInnerUnrestricted()
VBOXDrvFreeBSDIOCtl()
devfs_ioctl()

___
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: virtualbox 5.2.20 triggers panic with FreeBSD 12.0-ALPHA10 r339432

2018-10-19 Thread Don Lewis
On 20 Oct, Graham Perrin wrote:
> On 19/10/2018 23:47, Don Lewis wrote:
> 
>> … when I attempt to start a Virtualbox VM, the system panics. … (guest) 
>> Windows 7 with
> networking configured as > NAT and the underlying adapter being Intel PRO/1000
> MT Desktop (82540EM). …
> 
> No panic here. 32-bit Windows 7 guest with the same virtual adapter.
> 
> $ date ; uname -v
> Sat 20 Oct 2018 00:15:49 BST
> FreeBSD 12.0-BETA1 r339438 GENERIC
> $ pkg query '%o %v %R' virtualbox-ose virtualbox-ose-kmod
> emulators/virtualbox-ose 5.2.20 poudriere
> emulators/virtualbox-ose-kmod 5.2.20 poudriere
> $
> 
> If you have not already done so, try building and installing from ports.

I'm using locally built packages and the poudriere jail is the exactly
same source revision.

___
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: virtualbox 5.2.20 triggers panic with FreeBSD 12.0-ALPHA10 r339432

2018-10-19 Thread Graham Perrin
On 19/10/2018 23:47, Don Lewis wrote:

> … when I attempt to start a Virtualbox VM, the system panics. … (guest) 
> Windows 7 with
networking configured as > NAT and the underlying adapter being Intel PRO/1000
MT Desktop (82540EM). …

No panic here. 32-bit Windows 7 guest with the same virtual adapter.

$ date ; uname -v
Sat 20 Oct 2018 00:15:49 BST
FreeBSD 12.0-BETA1 r339438 GENERIC
$ pkg query '%o %v %R' virtualbox-ose virtualbox-ose-kmod
emulators/virtualbox-ose 5.2.20 poudriere
emulators/virtualbox-ose-kmod 5.2.20 poudriere
$

If you have not already done so, try building and installing from ports.



Side note: if you can get beyond the panic, then you might encounter this bug:

232408 – emulators/virtualbox-ose VirtualBoxVM guest crash when attempting to 
download guest additions

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


DRM: radeonkms no longer usable (and can not be unloaded (kernel panic)) following a switch to stable, FreeBSD 12.0-BETA1 r339438

2018-10-19 Thread Graham Perrin
$ uname -v
FreeBSD 12.0-BETA1 r339438 GENERIC
$ which xauth
/usr/local/bin/xauth
$

Radeon HD 7570M, HP EliteBook 8570p.

Following the switch to STABLE I could no longer use a desktop environment. For 
example:

service sddm onestart

– results in endless repetition of two lines, comparable to those shown at 
 and 

 except FreeBSD has the different path to xauth so IIRC what's seen is:

…
/usr/local/bin/xauth: (stdin):1:  bad "remove" command line
/usr/local/bin/xauth: (stdin):2:  bad "add" command line
/usr/local/bin/xauth: (stdin):1:  bad "remove" command line
/usr/local/bin/xauth: (stdin):2:  bad "add" command line
…

kldunload radeonkms

– results in a kernel panic.

So I edited my rc.conf,

$ less /etc/rc.conf
# kld_list="/boot/modules/radeonkms.ko"
# sddm_enable="YES"
…

– changed the startup routine to include CSM (not UEFI alone) and created a 
driver-vesa.conf as shown at 
.

Now I can at least use VESA.
___
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"


virtualbox 5.2.20 triggers panic with FreeBSD 12.0-ALPHA10 r339432

2018-10-19 Thread Don Lewis
It looks like there are a couple of problems here.  The first is that
when I attempt to start a Virtualbox VM, the system panics.  The DDB
backtrace seems to indicate that the panic is occuring inside the
ng_ether module, which was being called due to a virtualbox doing an
ioctl call.  The VM guest is M$ Windows 7 with networking configured as
NAT and the underlying adapter being Intel PRO/1000 MT Desktop
(82540EM).

I got a crash dump, but the second problem is that the stack backtrace
doesn't unwind the stack leading to the panic, but rather just the ddb
stack to the doadump call.  The panic is likely to be easily
reproduceable, so I can take a screen photo of the DDB output and upload
it if necessary.

Fri Oct 19 15:27:58 PDT 2018

FreeBSD zipper.catspoiler.org 12.0-ALPHA10 FreeBSD 12.0-ALPHA10 r339432 GENERIC
 amd64

panic:

GNU gdb (GDB) 8.2 [GDB v8.2 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//
boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 6; apic id = 06
fault virtual address   = 0x80a40ac00
fault code  = supervisor read data, protection violation
instruction pointer = 0x20:0x82ece023
stack pointer   = 0x28:0xfe02978ef3c0
frame pointer   = 0x28:0xfe02978ef3d0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 92279 (VirtualBox)

__curthread () at ./machine/pcpu.h:230
230 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) #0  __curthread () at ./machine/pcpu.h:230
#1  doadump (textdump=-2118704256) at /usr/src/sys/kern/kern_shutdown.c:366
#2  0x8043df6c in db_fncall_generic (addr=,
rv=, nargs=, args=)
at /usr/src/sys/ddb/db_command.c:609
#3  db_fncall (dummy1=, dummy2=,
dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:657
#4  0x8043daa9 in db_command (last_cmdp=,
cmd_table=, dopager=)
at /usr/src/sys/ddb/db_command.c:481
#5  0x8043d824 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:534
#6  0x80440a3f in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:252
#7  0x80bd52a3 in kdb_trap (type=12, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:693
#8  0x81062fc1 in trap_fatal (frame=0xfe02978ef300,
eva=34531748864) at /usr/src/sys/amd64/amd64/trap.c:921
#9  0x810630e2 in trap_pfault (frame=0xfe02978ef300,
usermode=) at /usr/src/sys/amd64/amd64/trap.c:765
#10 0x8106270a in trap (frame=0xfe02978ef300)
at /usr/src/sys/amd64/amd64/trap.c:441
#11 
#12 0x82ece023 in ?? ()
#13 0x in ?? ()

___
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: OpenSSL 1.1.1 Update report (ongoing)

2018-10-19 Thread David Marec

On 14/10/2018 19:31, Eric McCorkle wrote:

More:

* ImageMagick (unrelated to OpenSSL 1.1.1): This fails with the OpenMP
option ticked, due to trying to link with the base ld.  Can be fixed by
setting CC, CXX, LD to a port-installed clang, clang++, lld.  The port
should probably do this automatically.



Same issue while running 11.2-STABLE.


--
David Marec
https://lapinbilly.eu/
___
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"


boot message: sendmsg on igb0: No buffer space available

2018-10-19 Thread Mike Tancsa
Since starting to test HEAD, I noticed at bootup time I get the message
in dmesg

sendmsg on igb0: No buffer space available

It seems innocuous enough in that I dont see any obvious issues.  Is it
a symptom of some misconfiguration ? This originally was a releng11 box
that I upgraded via source so /etc/ still has all the old bootup stuff.
Speaking of which, what is the best way to update all the bootup
scripts. It seems to have all changed since 11.



Setting up harvesting:
PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Feeding entropy: .
lo0: link state changed to UP
sendmsg on igb0: No buffer space available
igb0: link state changed to UP
cxl1: link state changed to UP
Starting Network: lo0 igb0 cxl0 cxl1.


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


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"


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


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"


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


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


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

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"


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: head -r339076 based powerpc64 context: fatal kernel trap [ during /usr/tests/Kyuafile's sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 ]

2018-10-17 Thread Mark Millard
[Booting a debug kernel reported a lock order
reversal that might be relevant. The problem
repeated again: seems to always fail in my
context. The backtrace is like the prior
one, but for the debug kernel build being used
this time.]

On 2018-Oct-17, at 6:29 PM, Mark Millard  wrote:

> [I got another data storage interrupt failure, again
> during kyaua showing:
> 
> sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4  ->
> 
> but the backtrace looks different. See below.]
> 
> On 2018-Oct-17, at 4:58 PM, Mark Millard  wrote:
> 
>> On a powerpc64 with builworld buildkernel built via
>> devel/powerpc64-xtoolchain-gcc for head -r339076
>> (some source adjustments), and a system-cc-is-clang
>> I attempted a:
>> 
>> # kyua test -k /usr/tests/Kyuafile
>> 
>> It got to:
>> 
>> sys/netinet/reuseport_lb:basic_ipv4  ->  failed: 
>> /usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address 
>> already in use  [0.014s]
>> sys/netinet/reuseport_lb:basic_ipv6  ->  failed: 
>> /usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address 
>> already in use  [0.014s]
>> sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4  ->  
>> 
>> and then the system crashed. I am re-running to
>> see what happens.
>> 
>> The context has a non-debug kernel (but with
>> symbols).
>> 
>> Hand transcribed from a picture . . .
>> 
>> fatal kernel trap:
>> 
>> exception   = 0x300 (data storage interrupt)
>> virtual address = 0xbfba8530
>> dsisr   = 0x4200
>> srr0= 0x72b054
>> srr1= 0x90009032
>> current msr = 0x90009032
>> lr  = 0x69948c
>> curthread   = 0xc00036f7f000
>> pid = 12798, comm = ifconfig
>> 
>> [ thread pid 12798 tid 100312 ]
>> Stopped at lock_init+0x78 stw r9,0x8(r3)
>> db:0:kdb.enter.default> bt
>> Tracing pid 12798 tid 100312 td 0xc00036f7f000
>> 0xe0004646e330: at 0xe0004646e36c
>> 0xe0004646e360: at epair_modevent+0xf0
>> 0xe0004646e410: at module_register_init+0xe8
>> 0xe0004646e4a0: at linker_laod_module+0x6f8
> 
> Should have been: linker_load_module
> 
>> 0xe0004646e580: at kern_kldload+0x150
>> 0xe0004646e5e0: at sys_kldload+0xb80
>> 0xe0004646e630: at trap+0xef4
>> 0xe0004646e790: at powerpc_interrupt+0x12c
>> 0xe0004646e820: user sc trap by 0x81017fcf8
>> srr1 = 0x9000f032
>> r1   = 0x3fffcfe0
>> cr   = 0x28022482
>> xer  = 0x2000
>> ctr  = 0x81017fcf0
>> r2   = 0x810336300
>> 
>> 
>> # uname -apKU
>> FreeBSD FBSDG5L 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #4 r339076M: Mon Oct 15 
>> 13:19:35 PDT 2018 
>> markmi@FBSDG5L:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG
>>   powerpc powerpc64 1200084 1200084
>> 
>> ports was at -r480180.
>> 
> 
> Again failed during:
> 
> sys/netinet/reuseport_lb:basic_ipv4  ->  failed: 
> /usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address already 
> in use  [0.013s]
> sys/netinet/reuseport_lb:basic_ipv6  ->  failed: 
> /usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address already 
> in use  [0.013s]
> sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4  ->  
> 
> 
> The backtrace this time shows (hand transcribed):
> 
> fatal kernel trap:
> 
> exception   = 0x300 (data storage interrupt)
> virtual address = 0xc0008cab6530
> dsisr   = 0x4200
> srr0= 0xe00046e5b228
> srr1= 0x90009032
> current msr = 0x90009032
> lr  = 0xe00046e5b220
> curthread   = 0xcd48e000
> pid = 9666, comm = jail
> 
> [ thread pid 9666 tid 100185 ]
> Stopped at vnet_epair_init+0x78: stdx r3,r29,r30
> db:0:kdb.enter.default> bt
> Tracing pid 9666 tid 100185 td 0xcd48e000
> 0xe000470a1240: at vnet_sysinit+0x64
> 0xe000470a1270: at vnet_alloc+0xfc
> 0xe000470a12d0: at kern_jail_set+0x1e30
> 0xe000470a15e0: at sys_jail_set+08c
> 0xe000470a1630: at trap+0xef4
> 0xe000470a1790: at powerpc_interrupt+0x12c
> 0xe000470a1820: user sc trap by 0x81016a888
> srr1 = 0x9000f032
> r1   = 0x3fffd090
> cr   = 0x28002482
> xer  = 0x2000
> ctr  = 0x81016a880
> r2   = 0x810322300
> 
> I got a core.txt.0 this time. it reported:
> 
> . . .
> epair3a: Ethernet address: 02:60:27:70:4b:0a
> epair3b: Ethernet address: 02:60:27:70:4b:0b
> epair3a: link state changed to UP
> epair3b: link state changed to UP
> 
> fatal kernel trap:
> 
>   exception   = 0x300 (data storage interrupt)
>   virtual address = 0xc0008cab6530
>   dsisr   = 0x4200
>   srr0= 0xe00046e5b228 (0xe00046e5b228)
>   srr1= 0x90009032
>   current msr = 0x90009032
>   lr  = 0xe00046e5b220 (0xe00046e5b220)
>   curthread   = 0xcd48e000
>  pid = 9666, comm = jail
> 
> 

epair3a: Ethernet address: 02:60:27:70:4b:0a
epair3b: Ethernet address: 02:60:27:70:4b:0b
epair3a: link state 

Re: head -r339076 based powerpc64 context: fatal kernel trap [ during /usr/tests/Kyuafile's sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 ]

2018-10-17 Thread Mark Millard
[I got another data storage interrupt failure, again
during kyaua showing:

sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4  ->

but the backtrace looks different. See below.]

On 2018-Oct-17, at 4:58 PM, Mark Millard  wrote:

> On a powerpc64 with builworld buildkernel built via
> devel/powerpc64-xtoolchain-gcc for head -r339076
> (some source adjustments), and a system-cc-is-clang
> I attempted a:
> 
> # kyua test -k /usr/tests/Kyuafile
> 
> It got to:
> 
> sys/netinet/reuseport_lb:basic_ipv4  ->  failed: 
> /usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address already 
> in use  [0.014s]
> sys/netinet/reuseport_lb:basic_ipv6  ->  failed: 
> /usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address already 
> in use  [0.014s]
> sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4  ->  
> 
> and then the system crashed. I am re-running to
> see what happens.
> 
> The context has a non-debug kernel (but with
> symbols).
> 
> Hand transcribed from a picture . . .
> 
> fatal kernel trap:
> 
> exception   = 0x300 (data storage interrupt)
> virtual address = 0xbfba8530
> dsisr   = 0x4200
> srr0= 0x72b054
> srr1= 0x90009032
> current msr = 0x90009032
> lr  = 0x69948c
> curthread   = 0xc00036f7f000
> pid = 12798, comm = ifconfig
> 
> [ thread pid 12798 tid 100312 ]
> Stopped at lock_init+0x78 stw r9,0x8(r3)
> db:0:kdb.enter.default> bt
> Tracing pid 12798 tid 100312 td 0xc00036f7f000
> 0xe0004646e330: at 0xe0004646e36c
> 0xe0004646e360: at epair_modevent+0xf0
> 0xe0004646e410: at module_register_init+0xe8
> 0xe0004646e4a0: at linker_laod_module+0x6f8

Should have been: linker_load_module

> 0xe0004646e580: at kern_kldload+0x150
> 0xe0004646e5e0: at sys_kldload+0xb80
> 0xe0004646e630: at trap+0xef4
> 0xe0004646e790: at powerpc_interrupt+0x12c
> 0xe0004646e820: user sc trap by 0x81017fcf8
> srr1 = 0x9000f032
> r1   = 0x3fffcfe0
> cr   = 0x28022482
> xer  = 0x2000
> ctr  = 0x81017fcf0
> r2   = 0x810336300
> 
> 
> # uname -apKU
> FreeBSD FBSDG5L 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #4 r339076M: Mon Oct 15 
> 13:19:35 PDT 2018 
> markmi@FBSDG5L:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG
>   powerpc powerpc64 1200084 1200084
> 
> ports was at -r480180.
> 

Again failed during:

sys/netinet/reuseport_lb:basic_ipv4  ->  failed: 
/usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address already 
in use  [0.013s]
sys/netinet/reuseport_lb:basic_ipv6  ->  failed: 
/usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address already 
in use  [0.013s]
sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4  ->  


The backtrace this time shows (hand transcribed):

fatal kernel trap:

exception   = 0x300 (data storage interrupt)
virtual address = 0xc0008cab6530
dsisr   = 0x4200
srr0= 0xe00046e5b228
srr1= 0x90009032
current msr = 0x90009032
lr  = 0xe00046e5b220
curthread   = 0xcd48e000
pid = 9666, comm = jail

[ thread pid 9666 tid 100185 ]
Stopped at vnet_epair_init+0x78: stdx r3,r29,r30
db:0:kdb.enter.default> bt
Tracing pid 9666 tid 100185 td 0xcd48e000
0xe000470a1240: at vnet_sysinit+0x64
0xe000470a1270: at vnet_alloc+0xfc
0xe000470a12d0: at kern_jail_set+0x1e30
0xe000470a15e0: at sys_jail_set+08c
0xe000470a1630: at trap+0xef4
0xe000470a1790: at powerpc_interrupt+0x12c
0xe000470a1820: user sc trap by 0x81016a888
srr1 = 0x9000f032
r1   = 0x3fffd090
cr   = 0x28002482
xer  = 0x2000
ctr  = 0x81016a880
r2   = 0x810322300

I got a core.txt.0 this time. it reported:

. . .
epair3a: Ethernet address: 02:60:27:70:4b:0a
epair3b: Ethernet address: 02:60:27:70:4b:0b
epair3a: link state changed to UP
epair3b: link state changed to UP

fatal kernel trap:

   exception   = 0x300 (data storage interrupt)
   virtual address = 0xc0008cab6530
   dsisr   = 0x4200
   srr0= 0xe00046e5b228 (0xe00046e5b228)
   srr1= 0x90009032
   current msr = 0x90009032
   lr  = 0xe00046e5b220 (0xe00046e5b220)
   curthread   = 0xcd48e000
  pid = 9666, comm = jail



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


head -r339076 based powerpc64 context: fatal kernel trap Stopped at lock_init+0x78 stw r9,0x8(r3)

2018-10-17 Thread Mark Millard
On a powerpc64 with builworld buildkernel built via
devel/powerpc64-xtoolchain-gcc for head -r339076
(some source adjustments), and a system-cc-is-clang
I attempted a:

# kyua test -k /usr/tests/Kyuafile

It got to:

sys/netinet/reuseport_lb:basic_ipv4  ->  failed: 
/usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address already 
in use  [0.014s]
sys/netinet/reuseport_lb:basic_ipv6  ->  failed: 
/usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address already 
in use  [0.014s]
sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4  ->  

and then the system crashed. I am re-running to
see what happens.

The context has a non-debug kernel (but with
symbols).

Hand transcribed from a picture . . .

fatal kernel trap:

exception   = 0x300 (data storage interrupt)
virtual address = 0xbfba8530
dsisr   = 0x4200
srr0= 0x72b054
srr1= 0x90009032
current msr = 0x90009032
lr  = 0x69948c
curthread   = 0xc00036f7f000
pid = 12798, comm = ifconfig

[ thread pid 12798 tid 100312 ]
Stopped at lock_init+0x78 stw r9,0x8(r3)
db:0:kdb.enter.default> bt
Tracing pid 12798 tid 100312 td 0xc00036f7f000
0xe0004646e330: at 0xe0004646e36c
0xe0004646e360: at epair_modevent+0xf0
0xe0004646e410: at module_register_init+0xe8
0xe0004646e4a0: at linker_laod_module+0x6f8
0xe0004646e580: at kern_kldload+0x150
0xe0004646e5e0: at sys_kldload+0xb80
0xe0004646e630: at trap+0xef4
0xe0004646e790: at powerpc_interrupt+0x12c
0xe0004646e820: user sc trap by 0x81017fcf8
srr1 = 0x9000f032
r1   = 0x3fffcfe0
cr   = 0x28022482
xer  = 0x2000
ctr  = 0x81017fcf0
r2   = 0x810336300


# uname -apKU
FreeBSD FBSDG5L 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #4 r339076M: Mon Oct 15 
13:19:35 PDT 2018 
markmi@FBSDG5L:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG
  powerpc powerpc64 1200084 1200084

ports was at -r480180.



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


contigmalloc uses up all free memory.

2018-10-17 Thread Bennett, Ciunas
Hello,

I have encountered an issue with a kernel application that I have written,
the application allocates  and deallocates contiguous memory using 
contigmalloc() and contigfree().
The application will fail after a period of time because there is not enough 
free contiguous memory left.
There could be an issue with the freeing of memory when using the contigfree() 
function.

I have attached a simplified version of the application.
The resulting kernel module just allocates contiguous memory and then frees the 
memory using contigfree();
This allocation is done in a loop and the attached  src code triggers the issue.

After a period of time when running the application multiple times, the kernel 
reports
that there is no available memory and fails with allocation.

I can see that the amount of free memory is decreasing in correlation to how 
many

times I run the application by using DDB and printing out freepages using "show 
freepages"


I run the application in a loop using a shell script where I kldload then 
kldunload multiple times (script runs up to 100)

The application can take 20 to over 60 minutes to trigger the issue and run out 
of memory but can take longer also.

I am running the application on ->
FreeBSD 12.0-ALPHA9 also tested on 11.2
VM with 2 Gb of ram.
Allocating one cpu core.
Running on an Intel(R) Xeon(R) CPU E5-2658 v2 @ 2.40GH using Ubuntu 16.04 host.

I have attached the test kernel application and a Makefile.

Thanks,
Ciunas.
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
#include 
#include 
#include 
#include 
#include 
#include 

#define DEV_MEM "test_mem"

MALLOC_DECLARE(TEST_MEM);
MALLOC_DEFINE(TEST_MEM, "test_mem", "test_mem driver");

/* Test application to allocate contiguous memory then free it */
static int test_application()
{
int i = 0;
int array[10] = {2097152, 1024, 2101248, 1024, 2097152, 2101248,
 2101248, 2097152, 2101248, 1024};
int array1[10] = {1024, 2101248, 2097152, 2101248, 2101248, 2097152,
  1024, 2101248, 1024, 2097152};
void *mem_blocks[10];

for (i = 0; i < 10; i++)
{
mem_blocks[i] = contigmalloc(array[i], TEST_MEM, 0, 0, ~0, PAGE_SIZE, 
0);
if (!mem_blocks[i])
{
printf("%s:%d Unable to allocate contiguous memory slab \n", 
__func__,
   __LINE__);
return -1;
}
}

for (i = 0; i < 10; i++)
contigfree(mem_blocks[i], array[i], TEST_MEM);

for (i = 0; i < 10; i++)
{
mem_blocks[i] = contigmalloc(array1[i], TEST_MEM, 0, 0, ~0, PAGE_SIZE, 
0);
if (!mem_blocks[i])
{
printf("%s:%d Unable to allocate contiguous memory slab \n", 
__func__,
   __LINE__);
return -1;
}
}

for (i = 0; i < 10; i++)
contigfree(mem_blocks[i], array1[i], TEST_MEM);

return 0;
}

static int mem_modevent(module_t mod __unused,
int type,
void *data __unused)
{

switch (type)
{
case MOD_LOAD:
test_application();
return (0);
case MOD_UNLOAD:
return (0);
default:
return (EOPNOTSUPP);
}
}

DEV_MODULE(test_mem, mem_modevent, NULL);
MODULE_VERSION(test_mem, 1);


Makefile
Description: Makefile
___
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: Git segfaulting in libcrypto.so when trying to clone.

2018-10-17 Thread Brennan Vincent
Compiling ftp/curl from source and installing it has fixed the issue. Thank you 
both for the help/suggestions!

___
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: Git segfaulting in libcrypto.so when trying to clone.

2018-10-17 Thread Brian Scott
I think this just depends on when packages were built in relation to the
upgrade of openssl on current. I have just got over this problem by
rebuilding and installing the ftp/curl port (different problem here,
curl was failing but referred to older version of libssl and libcrypto -
which I didn't have a snapshot build).

I also rebuilt 'pkg' to get over the same problem.

Hopefully package building will catch up with this fairly quickly. My
problem was on arm64 so probably a lower priority for getting ports back
on track than amd64.

Cheers,

Brian


On 17/10/18 7:15 pm, Brennan Vincent wrote:
> Hi Kubilay (or do you prefer "koobs"?). Thanks for the response.
>
> To answer your questions:
> * I am using latest packages
> * My /etc/make.conf was empty when I built the system, and now just has 
> `WITH_DEBUG=yes`.
>
> # uname -a
> FreeBSD freebsd 12.0-ALPHA9 FreeBSD 12.0-ALPHA9 #3 r339359: Tue Oct 16 
> 03:28:51 UTC 2018 root@freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  
> amd64
> # ldd /usr/local/bin/curl
> /usr/local/bin/curl:
> libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x800268000)
> libz.so.6 => /lib/libz.so.6 (0x8002e7000)
> libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x800301000)
> libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800382000)
> libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x80038f000)
> libthr.so.3 => /lib/libthr.so.3 (0x8003b1000)
> libc.so.7 => /lib/libc.so.7 (0x8003dc000)
> libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x8007e7000)
> libssl.so.8 => /usr/lib/libssl.so.8 (0x800812000)
> libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x800888000)
> libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800891000)
> libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8008e2000)
> libcrypto.so.8 => /lib/libcrypto.so.8 (0x8008e7000)
> libasn1.so.11 => /usr/lib/libasn1.so.11 (0x800b59000)
> libwind.so.11 => /usr/lib/libwind.so.11 (0x800bfd000)
> libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x800c27000)
> libroken.so.11 => /usr/lib/libroken.so.11 (0x800c2e000)
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x800c43000)
> libcrypto.so.9 => /lib/libcrypto.so.9 (0x800c65000)
> libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 
> (0x800f52000)
> # ldd /usr/local/lib/libcurl.so.4
> /usr/local/lib/libcurl.so.4:
> libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x800707000)
> libssl.so.8 => /usr/lib/libssl.so.8 (0x800732000)
> libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x8007a8000)
> libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800e0)
> libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8007b1000)
> libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e51000)
> libasn1.so.11 => /usr/lib/libasn1.so.11 (0x8010c3000)
> libwind.so.11 => /usr/lib/libwind.so.11 (0x8007b6000)
> libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x8007e)
> libroken.so.11 => /usr/lib/libroken.so.11 (0x8007e7000)
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x801167000)
> libz.so.6 => /lib/libz.so.6 (0x801189000)
> libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x8011a3000)
> libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x801224000)
> libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x801231000)
> libthr.so.3 => /lib/libthr.so.3 (0x801253000)
> libc.so.7 => /lib/libc.so.7 (0x800248000)
> libcrypto.so.9 => /lib/libcrypto.so.9 (0x80127e000)
> libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 
> (0x80156b000)
>
> (aha - libcurl depends on .8 , and the curl binary depends on .9)
>
> From a cursory glance at the source tree, it seems libcrypto is part of 
> openssl, is this right? It seems the openssl version is in flux right now, 
> that might explain things...
>
> Cheers,
> ___
> 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: Git segfaulting in libcrypto.so when trying to clone.

2018-10-17 Thread Brennan Vincent
No, I've never run `delete-old` and `delete-old-lib` while upgrading.

I can try upgrading again tomorrow and running those. But if my installation of 
curl is for whatever reason
depending on libcrypto.so.8 and that command deletes it, won't that just cause 
curl to stop working? (I tried manually moving libcrypto.so.8 to 
libcrypto.so.8.bak
and as expected, now `git clone` failed because the .so couldn't be found.)

___
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: Git segfaulting in libcrypto.so when trying to clone.

2018-10-17 Thread Brennan Vincent
oh, actually I should point out that /usr/local/lib/libcurl.so.4 depends on 
*both* /lib/libcrypto.so.8 and /lib/libcrypto.so.9 , from the output I showed 
in my last email.

I'm not sure how to get the PORTVERSION and PORTREVISION...
___
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: Git segfaulting in libcrypto.so when trying to clone.

2018-10-17 Thread Kubilay Kocak

On 17/10/2018 7:14 pm, Brennan Vincent wrote:

Hi Kubilay (or do you prefer "koobs"?). Thanks for the response.

To answer your questions:
* I am using latest packages
* My /etc/make.conf was empty when I built the system, and now just has 
`WITH_DEBUG=yes`.

# uname -a
FreeBSD freebsd 12.0-ALPHA9 FreeBSD 12.0-ALPHA9 #3 r339359: Tue Oct 16 03:28:51 
UTC 2018 root@freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
# ldd /usr/local/bin/curl
/usr/local/bin/curl:
 libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x800268000)
 libz.so.6 => /lib/libz.so.6 (0x8002e7000)
 libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x800301000)
 libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800382000)
 libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x80038f000)
 libthr.so.3 => /lib/libthr.so.3 (0x8003b1000)
 libc.so.7 => /lib/libc.so.7 (0x8003dc000)
 libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x8007e7000)
 libssl.so.8 => /usr/lib/libssl.so.8 (0x800812000)
 libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x800888000)
 libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800891000)
 libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8008e2000)
 libcrypto.so.8 => /lib/libcrypto.so.8 (0x8008e7000)
 libasn1.so.11 => /usr/lib/libasn1.so.11 (0x800b59000)
 libwind.so.11 => /usr/lib/libwind.so.11 (0x800bfd000)
 libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x800c27000)
 libroken.so.11 => /usr/lib/libroken.so.11 (0x800c2e000)
 libcrypt.so.5 => /lib/libcrypt.so.5 (0x800c43000)
 libcrypto.so.9 => /lib/libcrypto.so.9 (0x800c65000)
 libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 
(0x800f52000)
# ldd /usr/local/lib/libcurl.so.4
/usr/local/lib/libcurl.so.4:
 libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x800707000)
 libssl.so.8 => /usr/lib/libssl.so.8 (0x800732000)
 libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x8007a8000)
 libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800e0)
 libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8007b1000)
 libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e51000)
 libasn1.so.11 => /usr/lib/libasn1.so.11 (0x8010c3000)
 libwind.so.11 => /usr/lib/libwind.so.11 (0x8007b6000)
 libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x8007e)
 libroken.so.11 => /usr/lib/libroken.so.11 (0x8007e7000)
 libcrypt.so.5 => /lib/libcrypt.so.5 (0x801167000)
 libz.so.6 => /lib/libz.so.6 (0x801189000)
 libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x8011a3000)
 libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x801224000)
 libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x801231000)
 libthr.so.3 => /lib/libthr.so.3 (0x801253000)
 libc.so.7 => /lib/libc.so.7 (0x800248000)
 libcrypto.so.9 => /lib/libcrypto.so.9 (0x80127e000)
 libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 
(0x80156b000)

(aha - libcurl depends on .8 , and the curl binary depends on .9)

 From a cursory glance at the source tree, it seems libcrypto is part of 
openssl, is this right? It seems the openssl version is in flux right now, that 
might explain things...


OpenSSL 1.1.1 import happened 7 days ago [1], which may partially 
explain the cause.


Having two versions of the shared libraries in base is unexpected 
though, unless its intentional for some reason, or I'm 
missing/forgetting something.


Do you run the delete-old / delete-old-lib targets during your
upgrades?

[1] https://svnweb.freebsd.org/changeset/base/339270
___
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: Git segfaulting in libcrypto.so when trying to clone.

2018-10-17 Thread Brennan Vincent
Hi Kubilay (or do you prefer "koobs"?). Thanks for the response.

To answer your questions:
* I am using latest packages
* My /etc/make.conf was empty when I built the system, and now just has 
`WITH_DEBUG=yes`.

# uname -a
FreeBSD freebsd 12.0-ALPHA9 FreeBSD 12.0-ALPHA9 #3 r339359: Tue Oct 16 03:28:51 
UTC 2018 root@freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
# ldd /usr/local/bin/curl
/usr/local/bin/curl:
libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x800268000)
libz.so.6 => /lib/libz.so.6 (0x8002e7000)
libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x800301000)
libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800382000)
libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x80038f000)
libthr.so.3 => /lib/libthr.so.3 (0x8003b1000)
libc.so.7 => /lib/libc.so.7 (0x8003dc000)
libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x8007e7000)
libssl.so.8 => /usr/lib/libssl.so.8 (0x800812000)
libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x800888000)
libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800891000)
libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8008e2000)
libcrypto.so.8 => /lib/libcrypto.so.8 (0x8008e7000)
libasn1.so.11 => /usr/lib/libasn1.so.11 (0x800b59000)
libwind.so.11 => /usr/lib/libwind.so.11 (0x800bfd000)
libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x800c27000)
libroken.so.11 => /usr/lib/libroken.so.11 (0x800c2e000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x800c43000)
libcrypto.so.9 => /lib/libcrypto.so.9 (0x800c65000)
libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 
(0x800f52000)
# ldd /usr/local/lib/libcurl.so.4
/usr/local/lib/libcurl.so.4:
libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x800707000)
libssl.so.8 => /usr/lib/libssl.so.8 (0x800732000)
libheimntlm.so.11 => /usr/lib/libheimntlm.so.11 (0x8007a8000)
libhx509.so.11 => /usr/lib/libhx509.so.11 (0x800e0)
libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x8007b1000)
libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e51000)
libasn1.so.11 => /usr/lib/libasn1.so.11 (0x8010c3000)
libwind.so.11 => /usr/lib/libwind.so.11 (0x8007b6000)
libheimbase.so.11 => /usr/lib/libheimbase.so.11 (0x8007e)
libroken.so.11 => /usr/lib/libroken.so.11 (0x8007e7000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x801167000)
libz.so.6 => /lib/libz.so.6 (0x801189000)
libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x8011a3000)
libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x801224000)
libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x801231000)
libthr.so.3 => /lib/libthr.so.3 (0x801253000)
libc.so.7 => /lib/libc.so.7 (0x800248000)
libcrypto.so.9 => /lib/libcrypto.so.9 (0x80127e000)
libprivateheimipcc.so.11 => /usr/lib/libprivateheimipcc.so.11 
(0x80156b000)

(aha - libcurl depends on .8 , and the curl binary depends on .9)

>From a cursory glance at the source tree, it seems libcrypto is part of 
>openssl, is this right? It seems the openssl version is in flux right now, 
>that might explain things...

Cheers,
___
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: Git segfaulting in libcrypto.so when trying to clone.

2018-10-17 Thread Kubilay Kocak

On 17/10/2018 6:34 pm, Brennan Vincent wrote:

This also happens in the stock `git` installed from `pkg`, but I have installed 
it also from `/usr/ports` so I could enable debug symbols and get a proper 
stacktrace.

When cloning any https repo (or at least the ones from github that I tried), 
git segfaults in `git-remote-https`, and the core dump shows the following 
stack trace:

   * frame #0: 0x00080081f36c libc.so.7`strcmp at strcmp.S:46
 frame #1: 0x000800d04f1d libcrypto.so.8`lh_insert [inlined] 
getrn(lh=, data=0x0008013aba20) at lhash.c:434
 frame #2: 0x000800d04ebb 
libcrypto.so.8`lh_insert(lh=0x000801359480, data=0x0008013aba20) at 
lhash.c:207
 frame #3: 0x000800d0f05e libcrypto.so.8`OBJ_NAME_add(name=0x, 
type=, data="m\x04") at o_names.c:202
 frame #4: 0x00080120ab8d libcrypto.so.9`openssl_add_all_ciphers_int at 
c_allc.c:83
 frame #5: 0x00080120a4b9 
libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ [inlined] 
ossl_init_add_all_ciphers at init.c:216
 frame #6: 0x00080120a4b4 
libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ at init.c:205
 frame #7: 0x00080064de28 
libthr.so.3`_pthread_once(once_control=0x00080128a3b0, 
init_routine=(libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ at init.c:205)) at 
thr_once.c:97
 frame #8: 0x000801209b69 
libcrypto.so.9`CRYPTO_THREAD_run_once(once=, init=) 
at threads_pthread.c:113
 frame #9: 0x000801209f67 
libcrypto.so.9`OPENSSL_init_crypto(opts=2097228, settings=0x) 
at init.c:611
 frame #10: 0x00080052982d libssl.so.9`OPENSSL_init_ssl(opts=2097152, 
settings=) at ssl_init.c:197
 frame #11: 0x000800525cb4 
libssl.so.9`SSL_CTX_new(meth=0x000800b0d1d0) at ssl_lib.c:2883
 frame #12: 0x0008004a4a92 
libcurl.so.4`___lldb_unnamed_symbol655$$libcurl.so.4 + 2722
 frame #13: 0x0008004a935f 
libcurl.so.4`___lldb_unnamed_symbol671$$libcurl.so.4 + 271
 frame #14: 0x00080045b455 
libcurl.so.4`___lldb_unnamed_symbol59$$libcurl.so.4 + 405
 frame #15: 0x0008004661ca 
libcurl.so.4`___lldb_unnamed_symbol136$$libcurl.so.4 + 154
 frame #16: 0x00080047c436 
libcurl.so.4`___lldb_unnamed_symbol259$$libcurl.so.4 + 934
 frame #17: 0x00080047bf0e libcurl.so.4`curl_multi_perform + 222
 frame #18: 0x0026a519 git-remote-https`step_active_slots at 
http.c:1293
 frame #19: 0x0026a596 
git-remote-https`run_active_slot(slot=0x0008012fa4c0) at http.c:1314
 frame #20: 0x0026a9f8 
git-remote-https`run_one_slot(slot=0x0008012fa4c0, 
results=0x7fffe0f8) at http.c:1509
 frame #21: 0x0026dc6a 
git-remote-https`http_request(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;,
 result=0x7fffe298, target=0, options=0x7fffe1f0) at http.c:1793
 frame #22: 0x0026ac5b 
git-remote-https`http_request_reauth(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;,
 result=0x7fffe298, target=0, options=0x7fffe1f0) at http.c:1869
 frame #23: 0x0026ac1c 
git-remote-https`http_get_strbuf(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;,
 result=0x7fffe298, options=0x7fffe1f0) at http.c:1910
 frame #24: 0x00264fbd git-remote-https`discover_refs(service="", 
for_push=0) at remote-curl.c:385
 frame #25: 0x00263ca2 git-remote-https`get_refs(for_push=0) at 
remote-curl.c:465
 frame #26: 0x0026361a git-remote-https`cmd_main(argc=3, 
argv=0x7fffe470) at remote-curl.c:1369
 frame #27: 0x002707d7 git-remote-https`main(argc=3, 
argv=0x7fffe470) at common-main.c:45
 frame #28: 0x0026311b git-remote-https`_start(ap=, 
cleanup=) at crt1.c:76


Hi Brennan,

git gets its HTTP/HTTPS/etc support via curl, so it's likely an issue there.


Note in particular that we jump from `libcrypto.so.9` to `libcrypto.so.8`... 
that seems wrong to me, but I'm not an expert.


There have been many instances in the past where software (from 
ports/packages) ends up linked against *both* OpenSSL from base and 
OpenSSL from ports, due to various issues. This is probably a similar issue.


The same problem can occur for anything that base provides, that can 
also be provided by ports, gssapi, ncurses, readline, among others come 
to mind.





`/lib/libcrypto.so.8` and `/lib/libcrypto.so.9` both exist for me.


If both exist in base, that's interesting (and probably a problem). I 
only have libcrypto.so.8 on a recent (month old) CURRENT build.


The openssl port (which curl can use) provides libcrypto.so.9 (in 
/usr/local/lib)



I can't reproduce this on a pristine install of 12.0-ALPHA10.



Some more system information might prove useful:

- FreeBSD version issue is reproducible on (uname -a)
- Output of ldd /usr/local/bin/curl
- Using quarterly or latest packages?
- What 

Git segfaulting in libcrypto.so when trying to clone.

2018-10-17 Thread Brennan Vincent
This also happens in the stock `git` installed from `pkg`, but I have installed 
it also from `/usr/ports` so I could enable debug symbols and get a proper 
stacktrace.

When cloning any https repo (or at least the ones from github that I tried), 
git segfaults in `git-remote-https`, and the core dump shows the following 
stack trace:

  * frame #0: 0x00080081f36c libc.so.7`strcmp at strcmp.S:46
frame #1: 0x000800d04f1d libcrypto.so.8`lh_insert [inlined] 
getrn(lh=, data=0x0008013aba20) at lhash.c:434
frame #2: 0x000800d04ebb 
libcrypto.so.8`lh_insert(lh=0x000801359480, data=0x0008013aba20) at 
lhash.c:207
frame #3: 0x000800d0f05e 
libcrypto.so.8`OBJ_NAME_add(name=0x, type=, 
data="m\x04") at o_names.c:202
frame #4: 0x00080120ab8d libcrypto.so.9`openssl_add_all_ciphers_int at 
c_allc.c:83
frame #5: 0x00080120a4b9 libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ 
[inlined] ossl_init_add_all_ciphers at init.c:216
frame #6: 0x00080120a4b4 libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ 
at init.c:205
frame #7: 0x00080064de28 
libthr.so.3`_pthread_once(once_control=0x00080128a3b0, 
init_routine=(libcrypto.so.9`ossl_init_add_all_ciphers_ossl_ at init.c:205)) at 
thr_once.c:97
frame #8: 0x000801209b69 
libcrypto.so.9`CRYPTO_THREAD_run_once(once=, init=) 
at threads_pthread.c:113
frame #9: 0x000801209f67 
libcrypto.so.9`OPENSSL_init_crypto(opts=2097228, settings=0x) 
at init.c:611
frame #10: 0x00080052982d libssl.so.9`OPENSSL_init_ssl(opts=2097152, 
settings=) at ssl_init.c:197
frame #11: 0x000800525cb4 
libssl.so.9`SSL_CTX_new(meth=0x000800b0d1d0) at ssl_lib.c:2883
frame #12: 0x0008004a4a92 
libcurl.so.4`___lldb_unnamed_symbol655$$libcurl.so.4 + 2722
frame #13: 0x0008004a935f 
libcurl.so.4`___lldb_unnamed_symbol671$$libcurl.so.4 + 271
frame #14: 0x00080045b455 
libcurl.so.4`___lldb_unnamed_symbol59$$libcurl.so.4 + 405
frame #15: 0x0008004661ca 
libcurl.so.4`___lldb_unnamed_symbol136$$libcurl.so.4 + 154
frame #16: 0x00080047c436 
libcurl.so.4`___lldb_unnamed_symbol259$$libcurl.so.4 + 934
frame #17: 0x00080047bf0e libcurl.so.4`curl_multi_perform + 222
frame #18: 0x0026a519 git-remote-https`step_active_slots at 
http.c:1293
frame #19: 0x0026a596 
git-remote-https`run_active_slot(slot=0x0008012fa4c0) at http.c:1314
frame #20: 0x0026a9f8 
git-remote-https`run_one_slot(slot=0x0008012fa4c0, 
results=0x7fffe0f8) at http.c:1509
frame #21: 0x0026dc6a 
git-remote-https`http_request(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;,
 result=0x7fffe298, target=0, options=0x7fffe1f0) at http.c:1793
frame #22: 0x0026ac5b 
git-remote-https`http_request_reauth(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;,
 result=0x7fffe298, target=0, options=0x7fffe1f0) at http.c:1869
frame #23: 0x0026ac1c 
git-remote-https`http_get_strbuf(url="https://github.com/emacs-lsp/lsp-mode/info/refs?service=git-upload-pack;,
 result=0x7fffe298, options=0x7fffe1f0) at http.c:1910
frame #24: 0x00264fbd git-remote-https`discover_refs(service="", 
for_push=0) at remote-curl.c:385
frame #25: 0x00263ca2 git-remote-https`get_refs(for_push=0) at 
remote-curl.c:465
frame #26: 0x0026361a git-remote-https`cmd_main(argc=3, 
argv=0x7fffe470) at remote-curl.c:1369
frame #27: 0x002707d7 git-remote-https`main(argc=3, 
argv=0x7fffe470) at common-main.c:45
frame #28: 0x0026311b git-remote-https`_start(ap=, 
cleanup=) at crt1.c:76

Note in particular that we jump from `libcrypto.so.9` to `libcrypto.so.8`... 
that seems wrong to me, but I'm not an expert.

`/lib/libcrypto.so.8` and `/lib/libcrypto.so.9` both exist for me.

I can't reproduce this on a pristine install of 12.0-ALPHA10.

Does anyone have any ideas?

___
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: fuser does not list id of processes that have a file

2018-10-17 Thread Ali Abdallah
> 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.

Regards.


On Tue, Oct 16, 2018 at 5:17 PM Ed Schouten  wrote:

> Hi there,
>
> Op di 16 okt. 2018 om 15:05 schreef Mateusz Guzik :
> >  struct reqfile {
> > -   uint32_tfsid;
> > +   uint64_tfsid;
> > uint64_tfileid;
>
> Considering that these are based on sb.st_{ino,dev}, maybe better to
> use the occasion to switch these fields to dev_t and ino_t?
>
> --
> Ed Schouten 
>
___
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: poudriere extract failures with TAR=/usr/local/bin/gtar with gtar from ports

2018-10-16 Thread Graham Perrin
The tail of a log from a failed run:

===
===>  License BSD3CLAUSE accepted by the user
===> Fetching all distfiles required by gflags-2.2.1 for building
===>  Extracting for gflags-2.2.1
=> SHA256 Checksum OK for gflags-gflags-v2.2.1_GH0.tar.gz.
/bin/sh: /usr/local/bin/gtar: not found
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/gflags
=>> Cleaning up wrkdir
===>  Cleaning for gflags-2.2.1
build of devel/gflags | gflags-2.2.1 ended at Wed Oct 17 02:32:54 BST 2018
build time: 00:00:02
!!! build failure encountered !!!






Why not found? gtar _is_ present:

$ /usr/local/bin/gtar --version
tar (GNU tar) 1.30
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
$
___
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: poudriere extract failures with TAR=/usr/local/bin/gtar with gtarfrom ports

2018-10-16 Thread Cy Schubert
It's failed to ensure gtar is installed as a prereq. The only thing I can 
suggest at the moment is kludgy.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
 or 
The need of the many outweighs the greed of the few.
---

-Original Message-
From: Graham Perrin
Sent: 15/10/2018 22:19
To: freebsd-current@freebsd.org
Subject: poudriere extract failures with TAR=/usr/local/bin/gtar with gtarfrom 
ports

For example:

> [00:01:10] [02] [00:00:19] Finished www/qt5-webkit | 
> qt5-webkit-5.212.0.a2_13: Failed: extract

In full:



root@momh167-gjp4-hpelitebook8570p-freebsd:~ # date ; uname -v ; pkg upgrade -f 
-r poudriere archivers/gtar
Tue 16 Oct 2018 06:03:24 BST
FreeBSD 12.0-ALPHA9 r339356 GENERIC-NODEBUG
Updating poudriere repository catalogue...
poudriere repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
    gtar-1.30 [poudriere]

Number of packages to be reinstalled: 1

Proceed with this action? [y/N]: y
[1/1] Reinstalling gtar-1.30...
[1/1] Extracting gtar-1.30: 100%
root@momh167-gjp4-hpelitebook8570p-freebsd:~ # nano 
/usr/local/etc/poudriere.d/make.conf




  GNU nano 3.1 
/usr/local/etc/poudriere.d/make.conf
   

ICA_CERTS=/usr/ports/distfiles/QuoVadisRootCA2.crt
DEFAULT_VERSIONS+= samba=4.8
# 
TAR=/usr/local/bin/gtar




root@momh167-gjp4-hpelitebook8570p-freebsd:~ # date ; poudriere ports -u ; 
poudriere bulk -j current www/otter-browser
Tue 16 Oct 2018 06:04:04 BST
[00:00:00] Updating portstree "default" with portsnap...Looking up 
portsnap.FreeBSD.org mirrors... 6 mirrors found.
Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done.
Ports tree hasn't changed since last snapshot.
No updates needed.
Ports tree is already up to date.
 done
[00:00:00] Creating the reference jail... done
[00:00:01] Mounting system devices for current-default
[00:00:01] Mounting ports/packages/distfiles
[00:00:01] Stashing existing package repository
[00:00:01] Mounting ccache from: /var/cache/ccache
[00:00:01] Mounting packages from: 
/usr/local/poudriere/data/packages/current-default
[00:00:01] Copying /var/db/ports from: 
/usr/local/etc/poudriere.d/current-options
[00:00:01] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
/etc/resolv.conf -> 
/usr/local/poudriere/data/.m/current-default/ref/etc/resolv.conf
[00:00:01] Starting jail current-default
[00:00:04] Logs: 
/usr/local/poudriere/data/logs/bulk/current-default/2018-10-16_06h04m05s
[00:00:05] Loading MOVED for 
/usr/local/poudriere/data/.m/current-default/ref/usr/ports
[00:00:06] Ports supports: FLAVORS SELECTED_OPTIONS
[00:00:06] Gathering ports metadata
[00:00:14] Calculating ports order and dependencies
[00:00:16] Sanity checking the repository
[00:00:16] Checking packages for incremental rebuild needs
[00:00:43] Deleting stale symlinks... done
[00:00:43] Deleting empty directories... done
[00:00:43] Cleaning the build queue
[00:00:43] Sanity checking build queue
[00:00:43] Processing PRIORITY_BOOST
[00:00:43] Balancing pool
[00:00:43] Recording filesystem state for prepkg... done
[00:00:49] Building 3 packages using 2 builders
[00:00:49] Starting/Cloning builders
[00:00:51] Hit CTRL+t at any time to see build progress and stats
[00:00:51] [01] [00:00:00] Building www/qt5-webengine | qt5-webengine-5.9.5_8
[00:00:51] [02] [00:00:00] Building www/qt5-webkit | qt5-webkit-5.212.0.a2_13
[00:01:10] [02] [00:00:19] Finished www/qt5-webkit | qt5-webkit-5.212.0.a2_13: 
Failed: extract
[00:01:10] [02] [00:00:19] Skipping www/otter-browser | otter-browser-0.9.99.3: 
Dependent port www/qt5-webkit | qt5-webkit-5.212.0.a2_13 failed
[00:01:29] [01] [00:00:38] Finished www/qt5-webengine | qt5-webengine-5.9.5_8: 
Failed: extract
[00:01:30] Stopping 2 builders
[00:01:36] No package built, no need to update the repository
[00:01:36] Committing packages to repository
[00:01:37] Removing old packages
[00:01:37] Failed ports: www/qt5-webkit:extract www/qt5-webengine:extract
[00:01:37] Skipped ports: www/otter-browser
[current-default] [2018-10-16_06h04m05s] [committing:] Queued: 3  Built: 0  
Failed: 2  Skipped: 1  Ignored: 0  Tobuild: 0   Time: 00:01:33
[00:01:37] Logs: 
/usr/local/poudriere/data/logs/bulk/current-default/2018-10-16_06h04m05s
[00:01:37] Cleaning up
[00:01:37] Unmounting file systems
root@momh167-gjp4-hpelitebook8570p-freebsd:~ #
___
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: Sound issues with Dell Latitude 7490 (kabylake)

2018-10-16 Thread Oliver Pinter
On 10/16/18, Oliver Pinter  wrote:
> On 10/6/18, David Wolfskill  wrote:
>> On Wed, Oct 03, 2018 at 03:28:45PM +0200, Jakob Alvermark wrote:
>>> ...
>>> This is probably not a proper fix, but it helps to understand the
>>> problem.
>>>
>>> Could you post the output of 'sysctl dev.hdaa' with and without the
>>> patch so we can see what's different?
>>> .
>>
>> I have run:
>>
>>  uname -a && sysctl dev.pcm dev.hdaa
>>
>> for each of stable/11 and head, both unpatched and patched.  (The
>> "unpatched" versions were a bit older -- almost a week, for stable/11;
>> from back in August, for head -- but that does not appear to be
>> significant in the present case.)
>>
>> The files are accessible from
>> .
>>
>> The sysctl output is the same for stable/11 & head:
>>
>> g1-215(11.2-S)[9] foreach f ( sound_info_* )
>> foreach? echo -n "${f}: " && tail +2 $f | md5
>> foreach? end
>> sound_info_11_patched: 90c26fbae2031174656207f66e1a39ec
>> sound_info_11_unpatched: cb9239fb33901086f56527c22576097f
>> sound_info_12_patched: 90c26fbae2031174656207f66e1a39ec
>> sound_info_12_unpatched: cb9239fb33901086f56527c22576097f
>> g1-215(11.2-S)[12]
>>
>> A unidiff for the "head" versions:
>>
>> g1-215(11.2-S)[12] diff -u sound_info_12_{un,}patched
>> --- sound_info_12_unpatched 2018-10-06 04:04:36.041741000 -0700
>> +++ sound_info_12_patched   2018-10-06 04:00:26.68135 -0700
>> @@ -1,4 +1,4 @@
>> -FreeBSD g1-215.catwhisker.org 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #276
>> r338043M/338043:1200078: Sun Aug 19 04:32:07 PDT 2018
>> r...@g1-215.catwhisker.org:/common/S3/obj/usr/src/amd64.amd64/sys/CANARY
>> amd64
>> +FreeBSD g1-215.catwhisker.org 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #131
>> r339212M/339212: Sat Oct  6 03:52:20 PDT 2018
>> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
>> amd64
>>  dev.pcm.3.bitperfect: 0
>>  dev.pcm.3.buffersize: 65536
>>  dev.pcm.3.rec.vchanformat: s16le:2.0
>> @@ -111,7 +111,7 @@
>>   Widget cap: 0x00400781 PWR DIGITAL UNSOL STEREO
>>  Pin cap: 0x0014 PDC OUT
>>   Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None
>> ctype=1/8
>> loc=Rear color=Black misc=1
>> -Pin control: 0x
>> +Pin control: 0x0040 OUT
>>  Connections: 1
>>+ <- nid=6 [audio output] [DISABLED]
>>
>> @@ -134,7 +134,7 @@
>>   Widget cap: 0x0040058f PWR UNSOL STEREO
>>  Pin cap: 0x3734 PDC OUT IN VREF[ 50 80 100 GROUND HIZ ]
>>   Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None
>> ctype=1/8
>> loc=Rear color=Black misc=1
>> -Pin control: 0x
>> +Pin control: 0x0020 IN
>>   Output amp: 0x8000 mute=1 step=0 size=0 offset=0 (0/0dB)
>>Input amp: 0x00270300 mute=0 step=3 size=39 offset=0 (0/30dB)
>>  Connections: 2
>> @@ -147,7 +147,7 @@
>>   Widget cap: 0x0040048b PWR UNSOL STEREO
>>  Pin cap: 0x3724 PDC IN VREF[ 50 80 100 GROUND HIZ ]
>>   Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None
>> ctype=1/8
>> loc=Rear color=Black misc=1
>> -Pin control: 0x
>> +Pin control: 0x0020 IN
>>Input amp: 0x00270300 mute=0 step=3 size=39 offset=0 (0/30dB)
>>
>>  dev.hdaa.1.nid25_original: 0x01a1903e as=3 seq=14 device=Mic conn=Jack
>> ctype=1/8 loc=Rear color=Pink misc=0
>> g1-215(11.2-S)[13]
>>
>> Peace,
>> david
>
> Is there any chance to get these workarounds / fixes for dell machines
> in the main tree?

With Jakob's workaround - to comment out the cleaning of hda pin
states - my laptop's sound started to work.
It's a Dell E5440. So thanks Jakob! :)

>
>
>> --
>> David H. Wolfskill   da...@catwhisker.org
>> Women (and decent men): vote against supporters of Trump's misogyny!
>>
>> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Sound issues with Dell Latitude 7490 (kabylake)

2018-10-16 Thread Oliver Pinter
On 10/6/18, David Wolfskill  wrote:
> On Wed, Oct 03, 2018 at 03:28:45PM +0200, Jakob Alvermark wrote:
>> ...
>> This is probably not a proper fix, but it helps to understand the
>> problem.
>>
>> Could you post the output of 'sysctl dev.hdaa' with and without the
>> patch so we can see what's different?
>> .
>
> I have run:
>
>   uname -a && sysctl dev.pcm dev.hdaa
>
> for each of stable/11 and head, both unpatched and patched.  (The
> "unpatched" versions were a bit older -- almost a week, for stable/11;
> from back in August, for head -- but that does not appear to be
> significant in the present case.)
>
> The files are accessible from
> .
>
> The sysctl output is the same for stable/11 & head:
>
> g1-215(11.2-S)[9] foreach f ( sound_info_* )
> foreach? echo -n "${f}: " && tail +2 $f | md5
> foreach? end
> sound_info_11_patched: 90c26fbae2031174656207f66e1a39ec
> sound_info_11_unpatched: cb9239fb33901086f56527c22576097f
> sound_info_12_patched: 90c26fbae2031174656207f66e1a39ec
> sound_info_12_unpatched: cb9239fb33901086f56527c22576097f
> g1-215(11.2-S)[12]
>
> A unidiff for the "head" versions:
>
> g1-215(11.2-S)[12] diff -u sound_info_12_{un,}patched
> --- sound_info_12_unpatched 2018-10-06 04:04:36.041741000 -0700
> +++ sound_info_12_patched   2018-10-06 04:00:26.68135 -0700
> @@ -1,4 +1,4 @@
> -FreeBSD g1-215.catwhisker.org 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #276
> r338043M/338043:1200078: Sun Aug 19 04:32:07 PDT 2018
> r...@g1-215.catwhisker.org:/common/S3/obj/usr/src/amd64.amd64/sys/CANARY
> amd64
> +FreeBSD g1-215.catwhisker.org 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #131
> r339212M/339212: Sat Oct  6 03:52:20 PDT 2018
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> amd64
>  dev.pcm.3.bitperfect: 0
>  dev.pcm.3.buffersize: 65536
>  dev.pcm.3.rec.vchanformat: s16le:2.0
> @@ -111,7 +111,7 @@
>   Widget cap: 0x00400781 PWR DIGITAL UNSOL STEREO
>  Pin cap: 0x0014 PDC OUT
>   Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None ctype=1/8
> loc=Rear color=Black misc=1
> -Pin control: 0x
> +Pin control: 0x0040 OUT
>  Connections: 1
>+ <- nid=6 [audio output] [DISABLED]
>
> @@ -134,7 +134,7 @@
>   Widget cap: 0x0040058f PWR UNSOL STEREO
>  Pin cap: 0x3734 PDC OUT IN VREF[ 50 80 100 GROUND HIZ ]
>   Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None ctype=1/8
> loc=Rear color=Black misc=1
> -Pin control: 0x
> +Pin control: 0x0020 IN
>   Output amp: 0x8000 mute=1 step=0 size=0 offset=0 (0/0dB)
>Input amp: 0x00270300 mute=0 step=3 size=39 offset=0 (0/30dB)
>  Connections: 2
> @@ -147,7 +147,7 @@
>   Widget cap: 0x0040048b PWR UNSOL STEREO
>  Pin cap: 0x3724 PDC IN VREF[ 50 80 100 GROUND HIZ ]
>   Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None ctype=1/8
> loc=Rear color=Black misc=1
> -Pin control: 0x
> +Pin control: 0x0020 IN
>Input amp: 0x00270300 mute=0 step=3 size=39 offset=0 (0/30dB)
>
>  dev.hdaa.1.nid25_original: 0x01a1903e as=3 seq=14 device=Mic conn=Jack
> ctype=1/8 loc=Rear color=Pink misc=0
> g1-215(11.2-S)[13]
>
> Peace,
> david

Is there any chance to get these workarounds / fixes for dell machines
in the main tree?


> --
> David H. Wolfskillda...@catwhisker.org
> Women (and decent men): vote against supporters of Trump's misogyny!
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: is 4k desktop possible on freebsd-12?

2018-10-16 Thread tech lists
On 10/10/2018 11:17, tech-lists wrote:
> I'm trying to get xorg to display 4k. The context is:
> 
> FreeBSD 12.0-ALPHA8 r339084 amd64
> ports r481640
> AMD RX580 GPU
> Asus X99 Extreme3 mobo
> cpu: intel e5-2699v4
> 48GB RAM
> Samsung UE48JU6410U monitor connected via HDMI
> 
> drm-next-kmod-4.11.g20180822

Hi, just to follow up to this,

I'd run out of time to work on this so installed latest ubuntu desktop,
then ran xrandr and it showed 4k as the top resolution. I didn't have to
make any modifications:

[snip]
DisplayPort-2 disconnected (normal left inverted right x axis y axis)
HDMI-A-0 connected primary 1920x1080+0+0 (normal left inverted right x
axis y axis) 1872mm x 1053mm
   3840x2160 30.00 +  25.0024.0029.9723.98
   4096x2160 30.0025.0024.0029.9723.98
[/snip]

and then, additionally, installed boinc-client-opencl and boinc was able
to see the GPUand use it for crunching.

On FreeBSD I couldn't see a way of making the boinc client OpenCL-aware.

On the plus side, FreeBSD was much more stable on this hardware than
Ubuntu. Had to disable hyperthreading in the BIOS to stop it crashing
every few hrs on Ubuntu.

It would be interesting to know, if possible, what Ubuntu is doing that
FreeBSD isn't on this hardware.

thanks to all who replied/tried to help,
-- 
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: fuser does not list id of processes that have a file

2018-10-16 Thread Ed Schouten
Hi there,

Op di 16 okt. 2018 om 15:05 schreef Mateusz Guzik :
>  struct reqfile {
> -   uint32_tfsid;
> +   uint64_tfsid;
> uint64_tfileid;

Considering that these are based on sb.st_{ino,dev}, maybe better to
use the occasion to switch these fields to dev_t and ino_t?

-- 
Ed Schouten 
___
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: fuser does not list id of processes that have a file

2018-10-16 Thread Mateusz Guzik
On 10/16/18, Ali Abdallah  wrote:
> Hello,
>
> On FreeBSD 12 ALPHA9
>
>> less .vimrc
>> fuser .vimrc
> .vimrc:
>
> gives no pid, on FreeBSD 11.2 the above works as expected.
>

try this:
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;


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


fuser does not list id of processes that have a file

2018-10-16 Thread Ali Abdallah
Hello,

On FreeBSD 12 ALPHA9

> less .vimrc
> fuser .vimrc
.vimrc:

gives no pid, on FreeBSD 11.2 the above works as expected.

Regards,
Ali
___
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"


poudriere extract failures with TAR=/usr/local/bin/gtar with gtar from ports

2018-10-15 Thread Graham Perrin
For example:

> [00:01:10] [02] [00:00:19] Finished www/qt5-webkit | 
> qt5-webkit-5.212.0.a2_13: Failed: extract

In full:



root@momh167-gjp4-hpelitebook8570p-freebsd:~ # date ; uname -v ; pkg upgrade -f 
-r poudriere archivers/gtar
Tue 16 Oct 2018 06:03:24 BST
FreeBSD 12.0-ALPHA9 r339356 GENERIC-NODEBUG
Updating poudriere repository catalogue...
poudriere repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
    gtar-1.30 [poudriere]

Number of packages to be reinstalled: 1

Proceed with this action? [y/N]: y
[1/1] Reinstalling gtar-1.30...
[1/1] Extracting gtar-1.30: 100%
root@momh167-gjp4-hpelitebook8570p-freebsd:~ # nano 
/usr/local/etc/poudriere.d/make.conf




  GNU nano 3.1 
/usr/local/etc/poudriere.d/make.conf
   

ICA_CERTS=/usr/ports/distfiles/QuoVadisRootCA2.crt
DEFAULT_VERSIONS+= samba=4.8
# 
TAR=/usr/local/bin/gtar




root@momh167-gjp4-hpelitebook8570p-freebsd:~ # date ; poudriere ports -u ; 
poudriere bulk -j current www/otter-browser
Tue 16 Oct 2018 06:04:04 BST
[00:00:00] Updating portstree "default" with portsnap...Looking up 
portsnap.FreeBSD.org mirrors... 6 mirrors found.
Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done.
Ports tree hasn't changed since last snapshot.
No updates needed.
Ports tree is already up to date.
 done
[00:00:00] Creating the reference jail... done
[00:00:01] Mounting system devices for current-default
[00:00:01] Mounting ports/packages/distfiles
[00:00:01] Stashing existing package repository
[00:00:01] Mounting ccache from: /var/cache/ccache
[00:00:01] Mounting packages from: 
/usr/local/poudriere/data/packages/current-default
[00:00:01] Copying /var/db/ports from: 
/usr/local/etc/poudriere.d/current-options
[00:00:01] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
/etc/resolv.conf -> 
/usr/local/poudriere/data/.m/current-default/ref/etc/resolv.conf
[00:00:01] Starting jail current-default
[00:00:04] Logs: 
/usr/local/poudriere/data/logs/bulk/current-default/2018-10-16_06h04m05s
[00:00:05] Loading MOVED for 
/usr/local/poudriere/data/.m/current-default/ref/usr/ports
[00:00:06] Ports supports: FLAVORS SELECTED_OPTIONS
[00:00:06] Gathering ports metadata
[00:00:14] Calculating ports order and dependencies
[00:00:16] Sanity checking the repository
[00:00:16] Checking packages for incremental rebuild needs
[00:00:43] Deleting stale symlinks... done
[00:00:43] Deleting empty directories... done
[00:00:43] Cleaning the build queue
[00:00:43] Sanity checking build queue
[00:00:43] Processing PRIORITY_BOOST
[00:00:43] Balancing pool
[00:00:43] Recording filesystem state for prepkg... done
[00:00:49] Building 3 packages using 2 builders
[00:00:49] Starting/Cloning builders
[00:00:51] Hit CTRL+t at any time to see build progress and stats
[00:00:51] [01] [00:00:00] Building www/qt5-webengine | qt5-webengine-5.9.5_8
[00:00:51] [02] [00:00:00] Building www/qt5-webkit | qt5-webkit-5.212.0.a2_13
[00:01:10] [02] [00:00:19] Finished www/qt5-webkit | qt5-webkit-5.212.0.a2_13: 
Failed: extract
[00:01:10] [02] [00:00:19] Skipping www/otter-browser | otter-browser-0.9.99.3: 
Dependent port www/qt5-webkit | qt5-webkit-5.212.0.a2_13 failed
[00:01:29] [01] [00:00:38] Finished www/qt5-webengine | qt5-webengine-5.9.5_8: 
Failed: extract
[00:01:30] Stopping 2 builders
[00:01:36] No package built, no need to update the repository
[00:01:36] Committing packages to repository
[00:01:37] Removing old packages
[00:01:37] Failed ports: www/qt5-webkit:extract www/qt5-webengine:extract
[00:01:37] Skipped ports: www/otter-browser
[current-default] [2018-10-16_06h04m05s] [committing:] Queued: 3  Built: 0  
Failed: 2  Skipped: 1  Ignored: 0  Tobuild: 0   Time: 00:01:33
[00:01:37] Logs: 
/usr/local/poudriere/data/logs/bulk/current-default/2018-10-16_06h04m05s
[00:01:37] Cleaning up
[00:01:37] Unmounting file systems
root@momh167-gjp4-hpelitebook8570p-freebsd:~ #
___
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: Problem compiling rust: observations on swap: GNU tar

2018-10-15 Thread Cy Schubert
In message <97680f3e-fb00-abc7-81d5-c61c9cae7...@gmail.com>, Graham 
Perrin writ
es:
> On 14/10/2018 22:34, Cy Schubert wrote:
>
> > Set TAR in make.conf to gnu tar from ports. Some tarballs will cause bsdtar
>  to exhaust memory and swap. There was discussion a while ago suggesting this
>  is a bug in vmm.
>
> Thanks!
>
> My make.conf for poudriere:
>
> root@momh167-gjp4-hpelitebook8570p-freebsd:~ # cat /usr/local/etc/poudriere.d
> /make.conf
> ICA_CERTS=/usr/ports/distfiles/QuoVadisRootCA2.crt
> DEFAULT_VERSIONS+= samba=4.8
> GNUTAR=on
> root@momh167-gjp4-hpelitebook8570p-freebsd:~ #
>
> – like so (the third line of the file), yes?

No, like this.

TAR=/usr/local/bin/gtar


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


Problem compiling rust: observations on swap: GNU tar

2018-10-15 Thread Graham Perrin
On 14/10/2018 22:34, Cy Schubert wrote:

> Set TAR in make.conf to gnu tar from ports. Some tarballs will cause bsdtar 
> to exhaust memory and swap. There was discussion a while ago suggesting this 
> is a bug in vmm.

Thanks!

My make.conf for poudriere:

root@momh167-gjp4-hpelitebook8570p-freebsd:~ # cat 
/usr/local/etc/poudriere.d/make.conf
ICA_CERTS=/usr/ports/distfiles/QuoVadisRootCA2.crt
DEFAULT_VERSIONS+= samba=4.8
GNUTAR=on
root@momh167-gjp4-hpelitebook8570p-freebsd:~ #

– like so (the third line of the file), yes?
___
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: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

2018-10-15 Thread Enji Cooper (yaneurabeya)

> On Oct 15, 2018, at 6:10 AM, Gleb Smirnoff  wrote:
> 
>  Enji,
> 
> can you please check that with this patch all your tests pass?

Hi Gleb!
It almost compiled. I just needed to dereference the `so` pointer:

$ git diff /usr/src/sys/kern/kern_sendfile.c
diff --git a/sys/kern/kern_sendfile.c b/sys/kern/kern_sendfile.c
index 438069aa721..50404ce5745 100644
--- a/sys/kern/kern_sendfile.c
+++ b/sys/kern/kern_sendfile.c
@@ -526,6 +526,8 @@ sendfile_getsock(struct thread *td, int s, struct file 
**sock_fp,
*so = (*sock_fp)->f_data;
if ((*so)->so_type != SOCK_STREAM)
return (EINVAL);
+   if (SOLISTENING(*so))
+   return (ENOTCONN);
return (0);
 }


After I applied that and rebuilt the kernel, it doesn’t panic anymore 
(and it fails with the correct errno).
Thank you so very much :)!
-Enji


signature.asc
Description: Message signed with OpenPGP


Re: OpenSSL 1.1.1 Update report (ongoing)

2018-10-15 Thread Eric McCorkle
* gnome-vfs: C compile errors related to openssl, no viable mitigation

Almost done now, though ptlib and gnome-vfs may cause runtime trouble

On 10/14/18 7:13 PM, Eric McCorkle wrote:
> * ptlib; Fails to build, due to C compiler errors arising from
> source-level incompatibilities.  This gets dragged in by opal, which
> ends up being a dependency of ekiga, which is a dependency of gnome3.
> Resolved by adding it to the exclude list, which actually does not seem
> to be breaking the build of opal.
> 
> * ffmpeg: autoconf fails to detect openssl.  Probably easily fixable,
> but the trivial workaround is to tick the GNUTLS option (emacs ends
> up dragging in GNUTLS anyway, so it doesn't add more packages)
> 
> On 10/14/18 1:31 PM, Eric McCorkle wrote:
>> More:
>>
>> * ImageMagick (unrelated to OpenSSL 1.1.1): This fails with the OpenMP
>> option ticked, due to trying to link with the base ld.  Can be fixed by
>> setting CC, CXX, LD to a port-installed clang, clang++, lld.  The port
>> should probably do this automatically.
>>
>> * compat-linux-c7-base had a signal 11 when creating a package, which
>> could be ignored without any apparent problem.  Might be related.
>>
>> * evolution-data-server: build process apparently ends up linking
>> against installed evolution libs.  This led to a build failure, due to
>> missing libssl.so.8.  Trying to deinstall then reinstall.
>>
>> Currently a little over halfway through.
>>
>> On 10/14/18 9:18 AM, Eric McCorkle wrote:
>>> I'm currently in the process of updating my laptop, rebuilding world,
>>> then rebuilding *all* ports.  I have a large number of ports installed
>>> (around 1200), and I tend to select a lot of build options.
>>>
>>> This report is intended to help shake out issues relating to OpenSSL
>>> 1.1.1.  I'll be adding to this report as things progress.
>>>
>>> So far:
>>>
>>> * I'd seen issues with some C++ files not including string.h.  I can't
>>> seem to reproduce this on my other laptop, so I'm going to assume it's
>>> fixed.
>>>
>>> * Base libpmc jevents issue: buildworld fails for me when building
>>> libpmc.  It appears to be missing a dependency link to build the jevents
>>> executable in the pmu-events subdirectory.  I was able to work around
>>> this by manually running make in that directory, then copying the result
>>> to the object directory for LIB32 builds
>>>
>>> * librtmp: C compile errors directly attributable to OpenSSL 1.1.1
>>> (missing defs, etc)
>>>
>>> * graphics/graphviz circular deps (unrelated to OpenSSL 1.1.1): graphviz
>>> with gnomeui and/or librsvg options ticked ends up depending on vala,
>>> which depends on graphviz.  Unrelated to OpenSSL 1.1.1, but warrants
>>> reporting.
>>>
>>>
>>> That's all so far.  Will send more info as it comes.
>>>
>>
> 



signature.asc
Description: OpenPGP digital signature


Re: vm_fault on boot with NVMe/nda

2018-10-15 Thread Warner Losh
At Netflix we have our OCA firmware based on FreeBSD -current (we take a
snapshot every 5 weeks or so). We've been booting thousands of machines off
nda for over a year... It absolutely works and is one of the things that
lets us deliver the content we do...

I have some patches in my queue waiting for the freeze to lift that do much
better trim shaping to the drives. You might also want to turn on
vfs.ffs.dotrimcons=1 which is a new feature that eliminates many of the
BIO_DELETE requests that come down from UFS that are turned into trims. nvd
has no queueing policy at all: it shot-guns all requests to the drive w/o
collapsing or any moderation at all... This isn't so good for most drives
out there today...

Warner

On Mon, Oct 15, 2018 at 8:38 AM Yuri Pankov  wrote:

> Daniel Nebdal wrote:
> > Hi. I have a 12-ALPHA9 / r339331 amd64 system (a HPE ProLiant ML30 G9),
> > with a Kingston NVMe SSD ("KINGSTON SKC1000480G") on a PCIe card.
> >
> > By default, it shows up as /dev/nvd0, and this is how I installed the
> > system. It has a single large UFS2 (with SJ and TRIM support) partition
> > mounted as /. (There's also a few other partitions on it that should be
> > irrelevant for this.) This works, but it does sometimes slow down for
> > minutes at the time with disturbing queue lengths in gstat; on the order
> of
> > tens of thousands. As I understand it, this is due to how TRIM operations
> > take precedence over everything else when using nvd ?
> >
> > Looking around, I noticed the nda driver for NVMe-through-CAM. To test
> it,
> > I added hw.nvme.use_nvd=0 to loader.conf. On one level, this works: The
> > drive shows up as /dev/nda0 . On the other hand, trying to mount nda0p2
> as
> > / floods the console with "vm_fault: pager read error, pid 1 (init)", and
> > never finishes booting.
> >
> > What is more interesting is that if I boot from the drive, but mount an
> > alpha9 usb stick as /, I can then mount the nda device just fine, and the
> > very minimal testing I did (using bin/cat and COPYRIGHT on the NVMe
> drive)
> > seems to work.
> >
> > So - is nda meant to be bootable, or am I a bit over-eager in trying to
> do
> > so?
> > If not, is there anything smart I can do to get better performance out of
> > nvd?
> > (Or have I just overlooked something obvious?)
> >
> > Dmesg from a normal nvd boot here:
> > https://openbenchmarking.org/system/1810159-RA-SSD30089593/SSD/dmesg
>
> FWIW, I set hw.nvme.use_nvd=0 in the installer, got 12-ALPHA8 installed
> on nda0, and it's happily booting from it (using ZFS, though), so it's
> certainly meant to be bootable.
>
>
___
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: vm_fault on boot with NVMe/nda

2018-10-15 Thread Yuri Pankov
Daniel Nebdal wrote:
> Hi. I have a 12-ALPHA9 / r339331 amd64 system (a HPE ProLiant ML30 G9),
> with a Kingston NVMe SSD ("KINGSTON SKC1000480G") on a PCIe card.
> 
> By default, it shows up as /dev/nvd0, and this is how I installed the
> system. It has a single large UFS2 (with SJ and TRIM support) partition
> mounted as /. (There's also a few other partitions on it that should be
> irrelevant for this.) This works, but it does sometimes slow down for
> minutes at the time with disturbing queue lengths in gstat; on the order of
> tens of thousands. As I understand it, this is due to how TRIM operations
> take precedence over everything else when using nvd ?
> 
> Looking around, I noticed the nda driver for NVMe-through-CAM. To test it,
> I added hw.nvme.use_nvd=0 to loader.conf. On one level, this works: The
> drive shows up as /dev/nda0 . On the other hand, trying to mount nda0p2 as
> / floods the console with "vm_fault: pager read error, pid 1 (init)", and
> never finishes booting.
> 
> What is more interesting is that if I boot from the drive, but mount an
> alpha9 usb stick as /, I can then mount the nda device just fine, and the
> very minimal testing I did (using bin/cat and COPYRIGHT on the NVMe drive)
> seems to work.
> 
> So - is nda meant to be bootable, or am I a bit over-eager in trying to do
> so?
> If not, is there anything smart I can do to get better performance out of
> nvd?
> (Or have I just overlooked something obvious?)
> 
> Dmesg from a normal nvd boot here:
> https://openbenchmarking.org/system/1810159-RA-SSD30089593/SSD/dmesg

FWIW, I set hw.nvme.use_nvd=0 in the installer, got 12-ALPHA8 installed
on nda0, and it's happily booting from it (using ZFS, though), so it's
certainly meant to be bootable.



signature.asc
Description: OpenPGP digital signature


vm_fault on boot with NVMe/nda

2018-10-15 Thread Daniel Nebdal
Hi. I have a 12-ALPHA9 / r339331 amd64 system (a HPE ProLiant ML30 G9),
with a Kingston NVMe SSD ("KINGSTON SKC1000480G") on a PCIe card.

By default, it shows up as /dev/nvd0, and this is how I installed the
system. It has a single large UFS2 (with SJ and TRIM support) partition
mounted as /. (There's also a few other partitions on it that should be
irrelevant for this.) This works, but it does sometimes slow down for
minutes at the time with disturbing queue lengths in gstat; on the order of
tens of thousands. As I understand it, this is due to how TRIM operations
take precedence over everything else when using nvd ?

Looking around, I noticed the nda driver for NVMe-through-CAM. To test it,
I added hw.nvme.use_nvd=0 to loader.conf. On one level, this works: The
drive shows up as /dev/nda0 . On the other hand, trying to mount nda0p2 as
/ floods the console with "vm_fault: pager read error, pid 1 (init)", and
never finishes booting.

What is more interesting is that if I boot from the drive, but mount an
alpha9 usb stick as /, I can then mount the nda device just fine, and the
very minimal testing I did (using bin/cat and COPYRIGHT on the NVMe drive)
seems to work.

So - is nda meant to be bootable, or am I a bit over-eager in trying to do
so?
If not, is there anything smart I can do to get better performance out of
nvd?
(Or have I just overlooked something obvious?)

Dmesg from a normal nvd boot here:
https://openbenchmarking.org/system/1810159-RA-SSD30089593/SSD/dmesg

-- 
Daniel Nebdal
___
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: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

2018-10-15 Thread Gleb Smirnoff
  Enji,

can you please check that with this patch all your tests pass?

-- 
Gleb Smirnoff
Index: sys/kern/kern_sendfile.c
===
--- sys/kern/kern_sendfile.c	(revision 339098)
+++ sys/kern/kern_sendfile.c	(working copy)
@@ -526,6 +526,8 @@ sendfile_getsock(struct thread *td, int s, struct
 	*so = (*sock_fp)->f_data;
 	if ((*so)->so_type != SOCK_STREAM)
 		return (EINVAL);
+	if (SOLISTENING(so))
+		return (ENOTCONN);
 	return (0);
 }
 
___
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: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

2018-10-15 Thread Gleb Smirnoff
On Sun, Oct 14, 2018 at 10:17:28PM -0700, Enji Cooper (yaneurabeya) wrote:
E> Oh yipes. I guess passing in a server socket (a bound and listening socket) 
instead of a client socket (connect’ed to a server socket) for `s` will result 
in a crash?

Oh, thanks enough info. Thanks! Isn't related to sendfile but definitely
is related to my other changes. Will fix.

-- 
Gleb Smirnoff
___
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 panic at boot with vmm in loader.conf vs manually loading it

2018-10-15 Thread Mike Tancsa
On 10/14/2018 2:19 PM, Mateusz Guzik wrote:
> On 10/14/18, Mike Tancsa  wrote:
>> On 10/13/2018 12:48 PM, Allan Jude wrote:
>>> Strange that your crash is in ZFS here...
>>>
>>> Can you take a crash dump?
>>>
>>> It looks like something is trying to write to uninitialized memory here.
>> I will need to pop in another drive or can I do a netdump at this point ?
>>
> This should be fixed with https://svnweb.freebsd.org/changeset/base/339355
> i.e. just update.
>
Thanks, just tried and all is good!


    ---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: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

2018-10-14 Thread Enji Cooper (yaneurabeya)

> On Oct 14, 2018, at 10:17 PM, Enji Cooper (yaneurabeya) 
>  wrote:

...

> Oh yipes. I guess passing in a server socket (a bound and listening socket) 
> instead of a client socket (connect’ed to a server socket) for `s` will 
> result in a crash?
> 
> From 
> https://github.com/ngie-eign/freebsd/blob/95b96470a3a0270c36c4e7fb5eedc150fe124fac/lib/libc/tests/sys/sendfile_test.c#L479
>  
> :
> ATF_TC_BODY(s_negative_not_connected_socket, tc)
> {
>   int client_sock, error, fd, port;
> 
>   port = XXX_TEST_PORT_BASE + __LINE__;
>   client_sock = setup_tcp_server(XXX_TEST_DOMAIN, port);
> 
>   fd = open(SOURCE_FILE, O_CREAT|O_RDWR);
>   ATF_REQUIRE_MSG(fd != -1, "open failed: %s", strerror(errno));
> 
>   error = sendfile(fd, client_sock, 0, 0, NULL, NULL, SF_FLAGS(0, 0));
>   ATF_REQUIRE_ERRNO(ENOTCONN, error == -1);
> 
>   (void)close(fd);
>   (void)close(client_sock);
> }
> Let me see if I can track this down..

Can’t repro this on 11.2-RELEASE. Trying 11.2-STABLE.
Thanks!
-Enji



signature.asc
Description: Message signed with OpenPGP


Re: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

2018-10-14 Thread Enji Cooper (yaneurabeya)

> On Oct 14, 2018, at 10:12 PM, Enji Cooper (yaneurabeya) 
>  wrote:
> 
>> On Oct 14, 2018, at 9:45 PM, Enji Cooper (yaneurabeya) 
>> mailto:yaneurab...@gmail.com>> wrote:
>> 
>> 
>> 
>>> On Oct 14, 2018, at 7:25 PM, Gleb Smirnoff >> > wrote:
>>> 
>>>  Hi Enji,
>>> 
>>> On Sun, Oct 14, 2018 at 06:51:42PM -0700, Enji Cooper (yaneurabeya) wrote:
>>> E> Hi,
>>> E>  I’m seeing a semi-deterministic panic on 12.0-ALPHA9 related to 
>>> sendfile(2) when running sendfile_test on the host: 
>>> https://pastebin.com/raw/6Y7xg0ki ; it 
>>> looks like it’s crashing in the sxlock code when calling sblock on a 
>>> sockbuf. Are there any commands in gdb you would like me to run to display 
>>> lock state?
>>> E>  Repro:
>>> E>
>>> E> mkdir /path/to/git/checkout
>>> E> cd /path/to/git/checkout
>>> E> git clone https://github.com/ngie-eign/freebsd/tree/sendfile_tests 
>>>  .
>>> E> git checkout sendfile_tests
>>> E> (cd lib/libc/tests/sys/; make obj; make; sudo make install)
>>> E> kyua test -k /usr/tests/lib/libc/sys/Kyuafile sendfile_test
>>> 
>>> I'd like to reproduce it myself, but looks like URL is
>>> wrong:
>>> 
>>> glebius@erla:/usr/src:|>git clone 
>>> https://github.com/ngie-eign/freebsd/tree/sendfile_tests 
>>> 
>>> Клонирование в «sendfile_tests»…
>>> fatal: repository 
>>> 'https://github.com/ngie-eign/freebsd/tree/sendfile_tests/ 
>>> ' not found
>> 
>> Mea culpa. It should be:
>> 
>> $ git clone https://github.com/ngie-eign/freebsd.git 
>>  .
>> 
>> Another note is that I’m running GENERIC-NODEBUG, not GENERIC-DEBUG.
>> 
>> I suspect that it’s crashing on :hdtr_negative_bad_pointers or : 
>> s_negative_not_descriptor, because the other items don’t seem terribly 
>> plausible.
>> 
>> The test case (source) can be found here: 
>> https://github.com/ngie-eign/freebsd/blob/95b96470a3a0270c36c4e7fb5eedc150fe124fac/lib/libc/tests/sys/sendfile_test.c
>>  
>> 
> Aha! It was actually :s_negative_not_connected_socket.
> 
> Updated repro: use `kyua test -k /usr/tests/lib/libc/sys/Kyuafile 
> sendfile_test:s_negative_not_connected_socket` instead of the other kyua call 
> I provided.

Oh yipes. I guess passing in a server socket (a bound and listening socket) 
instead of a client socket (connect’ed to a server socket) for `s` will result 
in a crash?

From 
https://github.com/ngie-eign/freebsd/blob/95b96470a3a0270c36c4e7fb5eedc150fe124fac/lib/libc/tests/sys/sendfile_test.c#L479
 
:
ATF_TC_BODY(s_negative_not_connected_socket, tc)
{
int client_sock, error, fd, port;

port = XXX_TEST_PORT_BASE + __LINE__;
client_sock = setup_tcp_server(XXX_TEST_DOMAIN, port);

fd = open(SOURCE_FILE, O_CREAT|O_RDWR);
ATF_REQUIRE_MSG(fd != -1, "open failed: %s", strerror(errno));

error = sendfile(fd, client_sock, 0, 0, NULL, NULL, SF_FLAGS(0, 0));
ATF_REQUIRE_ERRNO(ENOTCONN, error == -1);

(void)close(fd);
(void)close(client_sock);
}
Let me see if I can track this down..

Thanks!
-Enji


signature.asc
Description: Message signed with OpenPGP


Re: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

2018-10-14 Thread Enji Cooper (yaneurabeya)


> On Oct 14, 2018, at 9:45 PM, Enji Cooper (yaneurabeya) 
>  wrote:
> 
> 
> 
>> On Oct 14, 2018, at 7:25 PM, Gleb Smirnoff > > wrote:
>> 
>>  Hi Enji,
>> 
>> On Sun, Oct 14, 2018 at 06:51:42PM -0700, Enji Cooper (yaneurabeya) wrote:
>> E> Hi,
>> E>   I’m seeing a semi-deterministic panic on 12.0-ALPHA9 related to 
>> sendfile(2) when running sendfile_test on the host: 
>> https://pastebin.com/raw/6Y7xg0ki ; it 
>> looks like it’s crashing in the sxlock code when calling sblock on a 
>> sockbuf. Are there any commands in gdb you would like me to run to display 
>> lock state?
>> E>   Repro:
>> E>
>> E> mkdir /path/to/git/checkout
>> E> cd /path/to/git/checkout
>> E> git clone https://github.com/ngie-eign/freebsd/tree/sendfile_tests 
>>  .
>> E> git checkout sendfile_tests
>> E> (cd lib/libc/tests/sys/; make obj; make; sudo make install)
>> E> kyua test -k /usr/tests/lib/libc/sys/Kyuafile sendfile_test
>> 
>> I'd like to reproduce it myself, but looks like URL is
>> wrong:
>> 
>> glebius@erla:/usr/src:|>git clone 
>> https://github.com/ngie-eign/freebsd/tree/sendfile_tests 
>> 
>> Клонирование в «sendfile_tests»…
>> fatal: repository 'https://github.com/ngie-eign/freebsd/tree/sendfile_tests/ 
>> ' not found
> 
> Mea culpa. It should be:
> 
> $ git clone https://github.com/ngie-eign/freebsd.git 
>  .
> 
> Another note is that I’m running GENERIC-NODEBUG, not GENERIC-DEBUG.
> 
> I suspect that it’s crashing on :hdtr_negative_bad_pointers or : 
> s_negative_not_descriptor, because the other items don’t seem terribly 
> plausible.
> 
> The test case (source) can be found here: 
> https://github.com/ngie-eign/freebsd/blob/95b96470a3a0270c36c4e7fb5eedc150fe124fac/lib/libc/tests/sys/sendfile_test.c
>  
> 
Aha! It was actually :s_negative_not_connected_socket.

Updated repro: use `kyua test -k /usr/tests/lib/libc/sys/Kyuafile 
sendfile_test:s_negative_not_connected_socket` instead of the other kyua call I 
provided.

Thanks!
-Enji


signature.asc
Description: Message signed with OpenPGP


Re: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

2018-10-14 Thread Enji Cooper (yaneurabeya)


> On Oct 14, 2018, at 7:25 PM, Gleb Smirnoff  wrote:
> 
>  Hi Enji,
> 
> On Sun, Oct 14, 2018 at 06:51:42PM -0700, Enji Cooper (yaneurabeya) wrote:
> E> Hi,
> E>I’m seeing a semi-deterministic panic on 12.0-ALPHA9 related to 
> sendfile(2) when running sendfile_test on the host: 
> https://pastebin.com/raw/6Y7xg0ki; it looks like it’s crashing in the sxlock 
> code when calling sblock on a sockbuf. Are there any commands in gdb you 
> would like me to run to display lock state?
> E>Repro:
> E>
> E> mkdir /path/to/git/checkout
> E> cd /path/to/git/checkout
> E> git clone https://github.com/ngie-eign/freebsd/tree/sendfile_tests .
> E> git checkout sendfile_tests
> E> (cd lib/libc/tests/sys/; make obj; make; sudo make install)
> E> kyua test -k /usr/tests/lib/libc/sys/Kyuafile sendfile_test
> 
> I'd like to reproduce it myself, but looks like URL is
> wrong:
> 
> glebius@erla:/usr/src:|>git clone 
> https://github.com/ngie-eign/freebsd/tree/sendfile_tests
> Клонирование в «sendfile_tests»…
> fatal: repository 'https://github.com/ngie-eign/freebsd/tree/sendfile_tests/' 
> not found

Mea culpa. It should be:

$ git clone https://github.com/ngie-eign/freebsd.git 
 .

Another note is that I’m running GENERIC-NODEBUG, not GENERIC-DEBUG.

I suspect that it’s crashing on :hdtr_negative_bad_pointers or : 
s_negative_not_descriptor, because the other items don’t seem terribly 
plausible.

The test case (source) can be found here: 
https://github.com/ngie-eign/freebsd/blob/95b96470a3a0270c36c4e7fb5eedc150fe124fac/lib/libc/tests/sys/sendfile_test.c

Thanks!
-Enji


signature.asc
Description: Message signed with OpenPGP


Re: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

2018-10-14 Thread Gleb Smirnoff
  Hi Enji,

On Sun, Oct 14, 2018 at 06:51:42PM -0700, Enji Cooper (yaneurabeya) wrote:
E> Hi,
E>  I’m seeing a semi-deterministic panic on 12.0-ALPHA9 related to 
sendfile(2) when running sendfile_test on the host: 
https://pastebin.com/raw/6Y7xg0ki; it looks like it’s crashing in the sxlock 
code when calling sblock on a sockbuf. Are there any commands in gdb you would 
like me to run to display lock state?
E>  Repro:
E> 
E> mkdir /path/to/git/checkout
E> cd /path/to/git/checkout
E> git clone https://github.com/ngie-eign/freebsd/tree/sendfile_tests .
E> git checkout sendfile_tests
E> (cd lib/libc/tests/sys/; make obj; make; sudo make install)
E> kyua test -k /usr/tests/lib/libc/sys/Kyuafile sendfile_test

I'd like to reproduce it myself, but looks like URL is
wrong:

glebius@erla:/usr/src:|>git clone 
https://github.com/ngie-eign/freebsd/tree/sendfile_tests 
Клонирование в «sendfile_tests»…
fatal: repository 'https://github.com/ngie-eign/freebsd/tree/sendfile_tests/' 
not found


-- 
Gleb Smirnoff
___
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: 12.0-ALPHA5 - ZFS default ARC max apparently forcing system to run out of memory

2018-10-14 Thread Rebecca Cran
On 9/27/18 9:00 PM, Allan Jude wrote:

>
> It doesn't appear like ZFS is dominating memory usage there. Using less
> than the 8GB you indicated that setting the max to solved the problem...


You're right, the problem appeared again despite having limited ZFS:


FreeBSD tau.bluestop.org 12.0-ALPHA8 FreeBSD 12.0-ALPHA8
dc3b1a4cf0e(master) MYKERNEL  amd64

vfs.zfs.arc_max: 8589934592


Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(15): failed
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(14): failed
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(15): failed
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(8): failed
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(15): failed
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(8): failed
Oct  9 22:17:50 tau syslogd: last message repeated 1 times
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(4): failed
Oct  9 22:17:50 tau syslogd: last message repeated 2 times
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(5): failed
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(4): failed
Oct  9 22:17:50 tau syslogd: last message repeated 1 times
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(3): failed
Oct  9 22:17:50 tau syslogd: last message repeated 1 times
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(15): failed
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(3): failed
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(15): failed
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(3): failed
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(5): failed
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(3): failed
Oct  9 22:17:50 tau syslogd: last message repeated 1 times
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(15): failed
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(3): failed
Oct  9 22:17:50 tau kernel: swap_pager_getswapspace(15): failed
Oct  9 22:21:51 tau kernel: swap_pager_getswapspace(1): failed
Oct  9 22:36:03 tau kernel: pid 9236 (cc1plus), uid 0, was killed: out
of swap space
Oct  9 22:40:55 tau kernel: pid 29131 (cc1plus), uid 0, was killed: out
of swap space
Oct  9 22:40:56 tau kernel: pid 82673 (firefox), uid 1001, was killed:
out of swap space
Oct  9 22:40:57 tau kernel: pid 30363 (firefox), uid 1001: exited on
signal 11 (core dumped)
Oct  9 22:40:59 tau kernel: pid 46714 (firefox), uid 1001: exited on
signal 11 (core dumped)
Oct  9 22:41:00 tau kernel: pid 62612 (firefox), uid 1001: exited on
signal 11 (core dumped)


-- 
Rebecca Cran

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


Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

2018-10-14 Thread Enji Cooper (yaneurabeya)
Hi,
I’m seeing a semi-deterministic panic on 12.0-ALPHA9 related to 
sendfile(2) when running sendfile_test on the host: 
https://pastebin.com/raw/6Y7xg0ki; it looks like it’s crashing in the sxlock 
code when calling sblock on a sockbuf. Are there any commands in gdb you would 
like me to run to display lock state?
Repro:

mkdir /path/to/git/checkout
cd /path/to/git/checkout
git clone https://github.com/ngie-eign/freebsd/tree/sendfile_tests .
git checkout sendfile_tests
(cd lib/libc/tests/sys/; make obj; make; sudo make install)
kyua test -k /usr/tests/lib/libc/sys/Kyuafile sendfile_test

Thank you!
-Enji


signature.asc
Description: Message signed with OpenPGP


RE: Problem compiling rust: observations on swap

2018-10-14 Thread Cy Schubert
Set TAR in make.conf to gnu tar from ports. Some tarballs will cause bsdtar to 
exhaust memory and swap. There was discussion a while ago suggesting this is a 
bug in vmm.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
 or 
The need of the many outweighs the greed of the few.
---

-Original Message-
From: Graham Perrin
Sent: 14/10/2018 15:19
To: freebsd-current@freebsd.org
Subject: Problem compiling rust: observations on swap

On 06/10/2018 23:41, Rebecca Cran wrote:

> On 10/6/18 6:40 AM, Greg V wrote:
>
>> BTW, this error message doesn't say much, but if cargo fails, you
>> might be out of memory.
>
> I was going to suggest being out of memory too. I've seen the rust build
> cause my system to run out of all 32GB RAM and 2GB swap.

Yeah, by coincidence I mentioned this yesterday in IRC:



– whilst poudriere built both llvm and rust. Around 6 of 8 GB swap used on a 
system with 16 GB real memory.

(I allowed a larger than usual partition for swap when I first installed the 
system.)
___
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: OpenSSL 1.1.1 Update report (ongoing)

2018-10-14 Thread Eric McCorkle
* ptlib; Fails to build, due to C compiler errors arising from
source-level incompatibilities.  This gets dragged in by opal, which
ends up being a dependency of ekiga, which is a dependency of gnome3.
Resolved by adding it to the exclude list, which actually does not seem
to be breaking the build of opal.

* ffmpeg: autoconf fails to detect openssl.  Probably easily fixable,
but the trivial workaround is to tick the GNUTLS option (emacs ends
up dragging in GNUTLS anyway, so it doesn't add more packages)

On 10/14/18 1:31 PM, Eric McCorkle wrote:
> More:
> 
> * ImageMagick (unrelated to OpenSSL 1.1.1): This fails with the OpenMP
> option ticked, due to trying to link with the base ld.  Can be fixed by
> setting CC, CXX, LD to a port-installed clang, clang++, lld.  The port
> should probably do this automatically.
> 
> * compat-linux-c7-base had a signal 11 when creating a package, which
> could be ignored without any apparent problem.  Might be related.
> 
> * evolution-data-server: build process apparently ends up linking
> against installed evolution libs.  This led to a build failure, due to
> missing libssl.so.8.  Trying to deinstall then reinstall.
> 
> Currently a little over halfway through.
> 
> On 10/14/18 9:18 AM, Eric McCorkle wrote:
>> I'm currently in the process of updating my laptop, rebuilding world,
>> then rebuilding *all* ports.  I have a large number of ports installed
>> (around 1200), and I tend to select a lot of build options.
>>
>> This report is intended to help shake out issues relating to OpenSSL
>> 1.1.1.  I'll be adding to this report as things progress.
>>
>> So far:
>>
>> * I'd seen issues with some C++ files not including string.h.  I can't
>> seem to reproduce this on my other laptop, so I'm going to assume it's
>> fixed.
>>
>> * Base libpmc jevents issue: buildworld fails for me when building
>> libpmc.  It appears to be missing a dependency link to build the jevents
>> executable in the pmu-events subdirectory.  I was able to work around
>> this by manually running make in that directory, then copying the result
>> to the object directory for LIB32 builds
>>
>> * librtmp: C compile errors directly attributable to OpenSSL 1.1.1
>> (missing defs, etc)
>>
>> * graphics/graphviz circular deps (unrelated to OpenSSL 1.1.1): graphviz
>> with gnomeui and/or librsvg options ticked ends up depending on vala,
>> which depends on graphviz.  Unrelated to OpenSSL 1.1.1, but warrants
>> reporting.
>>
>>
>> That's all so far.  Will send more info as it comes.
>>
> 



signature.asc
Description: OpenPGP digital signature


Re: OpenSSL 1.1.1 libssl.so version number

2018-10-14 Thread Konstantin Belousov
On Sun, Oct 14, 2018 at 05:45:30PM +0200, Dirk Meyer wrote:
> Don Lewis schrieb:,
> 
> > It looks to me like the base libssl.so version needs to get moved to a
> > value that doesn't collide with ports, perhaps 12.  These are the
> > library version numbers currently used by the various ssl ports:
> > 
> > boringssl   1
> > openssl 9
> > openssl-devel   10
> > openssl111  11
> > libressl43
> > libressl-devel  44
> 
> The linker will always pick the highest so version of a lib (e.g. libssl.so).
> I the past the base version must be smaller then the port version,

This is simply not true, both static and dynamic ELF linkers do not care
about version numbers at all.

Static linker ld(1) only looks for libXXX.so file and records DT_SONAME from
the shared library into the linked binary.  Dynamic linker ld-elf.so.1
looks for exact match of the library filename and DT_SONAME.

So for instance we have
libc.so -> libc.so.7
symlink and libc.so.7 has DT_SONAME libc.so.7.  Then -lc causes recording
the dependency libc.so.7 and dynamic linker loads it when activating the
image. 
___
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: OpenSSL 1.1.1 libssl.so version number

2018-10-14 Thread Cy Schubert
Not necessarily 12. ports/openssl111 should have the same ABI as HEAD so they 
should share the same version number. The fact that openssl111 in HEAD and 
openssl 1.0.2 in ports share the same version number but do not share the same 
ABI is the problem.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
 or 
The need of the many outweighs the greed of the few.
---

-Original Message-
From: Don Lewis
Sent: 14/10/2018 09:06
To: FreeBSD current
Cc: r...@freebsd.org
Subject: Re: OpenSSL 1.1.1 libssl.so version number

On 12 Oct, Don Lewis wrote:
> Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
> /usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
> ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
> (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, the
> base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
> with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
> is ambiguous because there are now two different versions of libssl.so
> (1.0.2p and 1.1.1) with the same shared library version number.
> 
> I stumbled across this when debugging a virtualbox-ose configure
> failure.  The test executable was linked to the ports version of
> libssl.so but rtld chose the base libssl.so at run time.

It looks to me like the base libssl.so version needs to get moved to a
value that doesn't collide with ports, perhaps 12.  These are the
library version numbers currently used by the various ssl ports:

boringssl   1
openssl 9
openssl-devel   10
openssl111  11
libressl43
libressl-devel  44

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


Problem compiling rust: observations on swap

2018-10-14 Thread Graham Perrin
On 06/10/2018 23:41, Rebecca Cran wrote:

> On 10/6/18 6:40 AM, Greg V wrote:
>
>> BTW, this error message doesn't say much, but if cargo fails, you
>> might be out of memory.
>
> I was going to suggest being out of memory too. I've seen the rust build
> cause my system to run out of all 32GB RAM and 2GB swap.

Yeah, by coincidence I mentioned this yesterday in IRC:



– whilst poudriere built both llvm and rust. Around 6 of 8 GB swap used on a 
system with 16 GB real memory.

(I allowed a larger than usual partition for swap when I first installed the 
system.)
___
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: OpenSSL 1.1.1 libssl.so version number

2018-10-14 Thread Daniel Eischen


> On Oct 14, 2018, at 2:00 AM, Don Lewis  wrote:
> 
>> On 12 Oct, Don Lewis wrote:
>> Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
>> /usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
>> ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
>> (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, the
>> base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
>> with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
>> is ambiguous because there are now two different versions of libssl.so
>> (1.0.2p and 1.1.1) with the same shared library version number.
>> 
>> I stumbled across this when debugging a virtualbox-ose configure
>> failure.  The test executable was linked to the ports version of
>> libssl.so but rtld chose the base libssl.so at run time.
> 
> It looks to me like the base libssl.so version needs to get moved to a
> value that doesn't collide with ports, perhaps 12.  These are the
> library version numbers currently used by the various ssl ports:

Even if base OpenSSL used 12, don't you potentially have the same problem if 
the port bumps their version sometime later?

And do you have a problem if a port library is built against a port OpenSSL, 
and another port library is built against base OpenSSL, then an app links to 
both libraries, getting both base and port OpenSSL's linked in the same image?  
It seems like you have to ensure that when you specify WITH_OPENSSL, that all 
your ports are [re]built this way, no?  I guess base OpenSSL is really no 
different, all ports need to be built using the same library, whether it's base 
or some other port version.

--
DE
___
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 panic at boot with vmm in loader.conf vs manually loading it

2018-10-14 Thread Mateusz Guzik
On 10/14/18, Mike Tancsa  wrote:
> On 10/13/2018 12:48 PM, Allan Jude wrote:
>>
>> Strange that your crash is in ZFS here...
>>
>> Can you take a crash dump?
>>
>> It looks like something is trying to write to uninitialized memory here.
>
> I will need to pop in another drive or can I do a netdump at this point ?
>

This should be fixed with https://svnweb.freebsd.org/changeset/base/339355
i.e. just update.

-- 
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: OpenSSL 1.1.1 libssl.so version number

2018-10-14 Thread Cy Schubert
In message <0f7eb379-8c52-478a-aa5a-ac4257e5b...@freebsd.org>, Daniel 
Eischen w
rites:
> 
>
> > On Oct 12, 2018, at 10:58 PM, Cy Schubert  wrote
> :
> > 
> > In message , Don Lewis writes:
> >> Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
> >> /usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
> >> ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
> >> (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, the
> >> base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
> >> with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
> >> is ambiguous because there are now two different versions of libssl.so
> >> (1.0.2p and 1.1.1) with the same shared library version number.
> >> 
> >> I stumbled across this when debugging a virtualbox-ose configure
> >> failure.  The test executable was linked to the ports version of
> >> libssl.so but rtld chose the base libssl.so at run time.
> > 
> > This is also the issue with ports-mgmt/pkg on a system that still 
> > requires OpenSSL 1.0.2 from ports in order to support an old client.
> > 
> > cwfw# pkg info
> > ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0 
> > required by /usr/local/lib/libpkg.so.4 not defined
> > cwfw# 
> > 
> > If I remove security/openssl, the above issue is resolved however the 
> > old client, which should be replaced next year, fails to communicate 
> > with the server. The classic rock & a hard place scenario.
>
> Not saying this is a real solution for the general problem, but can you use a
>  libmap.conf entry to work around this?

I tried using the path1 path2 form. No joy there.


-- 
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: OpenSSL 1.1.1 Update report (ongoing)

2018-10-14 Thread Eric McCorkle
More:

* ImageMagick (unrelated to OpenSSL 1.1.1): This fails with the OpenMP
option ticked, due to trying to link with the base ld.  Can be fixed by
setting CC, CXX, LD to a port-installed clang, clang++, lld.  The port
should probably do this automatically.

* compat-linux-c7-base had a signal 11 when creating a package, which
could be ignored without any apparent problem.  Might be related.

* evolution-data-server: build process apparently ends up linking
against installed evolution libs.  This led to a build failure, due to
missing libssl.so.8.  Trying to deinstall then reinstall.

Currently a little over halfway through.

On 10/14/18 9:18 AM, Eric McCorkle wrote:
> I'm currently in the process of updating my laptop, rebuilding world,
> then rebuilding *all* ports.  I have a large number of ports installed
> (around 1200), and I tend to select a lot of build options.
> 
> This report is intended to help shake out issues relating to OpenSSL
> 1.1.1.  I'll be adding to this report as things progress.
> 
> So far:
> 
> * I'd seen issues with some C++ files not including string.h.  I can't
> seem to reproduce this on my other laptop, so I'm going to assume it's
> fixed.
> 
> * Base libpmc jevents issue: buildworld fails for me when building
> libpmc.  It appears to be missing a dependency link to build the jevents
> executable in the pmu-events subdirectory.  I was able to work around
> this by manually running make in that directory, then copying the result
> to the object directory for LIB32 builds
> 
> * librtmp: C compile errors directly attributable to OpenSSL 1.1.1
> (missing defs, etc)
> 
> * graphics/graphviz circular deps (unrelated to OpenSSL 1.1.1): graphviz
> with gnomeui and/or librsvg options ticked ends up depending on vala,
> which depends on graphviz.  Unrelated to OpenSSL 1.1.1, but warrants
> reporting.
> 
> 
> That's all so far.  Will send more info as it comes.
> 



signature.asc
Description: OpenPGP digital signature


Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-14 Thread Mike Tancsa
On 10/13/2018 12:48 PM, Allan Jude wrote:
>
> Strange that your crash is in ZFS here...
>
> Can you take a crash dump?
>
> It looks like something is trying to write to uninitialized memory here. 

I will need to pop in another drive or can I do a netdump at this point ?

    ---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: nginx introduces extra delay when talking to slow backend (probably FreeBSD kevent specific)

2018-10-14 Thread Maxim Dounin
Hello!

On Fri, Oct 12, 2018 at 11:31:26PM +0300, Dmitry Marakasov wrote:

> * Dmitry Marakasov (amd...@amdmi3.ru) wrote:
> 
> I've gathered ktrace dumps for both cases, and it really looks that
> the problem is related to kevent. After nginx sends response back
> to client, it calls kevent(2) on client fd (which is 5).
> 
> When there is a bug (FreeBSD 11.2), the following happens:
> 
>  49365 nginx3.099362 CALL  
> kevent(0x7,0x8022a2000,0,0x8023005c0,0x200,0x7fffe598)
>  49365 nginx3.099419 STRU  struct kevent[] = {  }
>  49365 nginx3.194695 STRU  struct kevent[] = { { ident=5, 
> filter=EVFILT_WRITE, flags=0x20, fflags=0, data=0xbf88, 
> udata=0x8023633d1 } }
>  49365 nginx3.194733 RET   kevent 1
> ...
>  49365 nginx3.194858 CALL  
> kevent(0x7,0x8022a2000,0,0x8023005c0,0x200,0x7fffe598)
>  49365 nginx3.194875 STRU  struct kevent[] = {  }
>  49365 nginx3.835259 STRU  struct kevent[] = { { ident=5, 
> filter=EVFILT_READ, flags=0x8020, fflags=0, data=0, 
> udata=0x802346111 } }
>  49365 nginx3.835299 RET   kevent 1
> 
> E.g. read and write events come separately, both with huge delays.
> 
> On FreeBSD-CURRENT which doesn't experience the problem, kdump looks this way:
> 
>   8049 nginx3.081367 CALL  
> kevent(0x7,0x8012d1b40,0,0x8012da040,0x200,0x7fffe598)
>   8049 nginx3.081371 STRU  struct kevent[] = {  }
>   8049 nginx3.081492 STRU  struct kevent[] = { { ident=5, 
> filter=EVFILT_WRITE, flags=0x20, fflags=0, data=0xbf88, 
> udata=0x801341f11 }
>  { ident=5, filter=EVFILT_READ, flags=0x8020, 
> fflags=0, data=0, udata=0x801324e51 } }
>   8049 nginx3.081498 RET   kevent 2
> 
> E.g. both events come immediately and at the same time.
> 
> Not sure if that's problem of kevent or something it relies on or the
> way nginx uses it.

Have you tried looking into what happens in the client?  These 
events are client-related, and seems to match what client does as 
per tcpdump of traffic between nginx and the client.

Also, at least on my box (FreeBSD 10.4) this issue can be 
reproduced with curl, but not with fetch or wget.  Seems to be 
something curl-specific.  I'm not familiar with curl source code, 
but it seems to be sitting in a poll() call without any file 
descriptors for some reason:

  8862 curl 0.013972 GIO   fd 3 wrote 78 bytes
   "GET / HTTP/1.1\r
Host: localhost:8080\r
User-Agent: curl/7.61.0\r
Accept: */*\r
\r
   "
  8862 curl 0.013977 RET   sendto 78/0x4e
  8862 curl 0.013984 CALL  poll(0xbfbfe610,0x1,0)
  8862 curl 0.013987 RET   poll 0
  8862 curl 0.013992 CALL  poll(0xbfbfe768,0x1,0x1)
  8862 curl 0.016042 RET   poll 0
  8862 curl 0.016118 CALL  poll(0xbfbfe610,0x1,0)
  8862 curl 0.016137 RET   poll 0
  8862 curl 0.016197 CALL  poll(0xbfbfe768,0x1,0xc5)
  8862 curl 0.228557 RET   poll 0
  8862 curl 0.228605 CALL  poll(0xbfbfe610,0x1,0)
  8862 curl 0.228617 RET   poll 0
  8862 curl 0.228631 CALL  poll(0xbfbfe768,0x1,0x3e8)
  8862 curl 1.246374 RET   poll 0
  8862 curl 1.246420 CALL  poll(0,0,0x3e8)
  8862 curl 2.298297 RET   poll 0
  8862 curl 2.298410 CALL  poll(0xbfbfe610,0x1,0)
  8862 curl 2.298452 RET   poll 1
  8862 curl 2.298517 CALL  recvfrom(0x3,0x28ca,0x19000,0,0,0)
  8862 curl 2.298584 GIO   fd 3 read 171 bytes
   "HTTP/1.1 200 OK\r
Server: nginx/1.15.5\r

Note these lines:

  8862 curl 1.246420 CALL  poll(0,0,0x3e8)
  8862 curl 2.298297 RET   poll 0

This is a call without any file descriptors and with 1000 
millisecond timeout, so it will result in an unconditional 1 
second delay.

Not sure why you are seeing the problem with some FreeBSD version 
but not others, but different curl versions or curl compilation 
flags may explain things.  In my case curl version is as follows:

$ curl --version
curl 7.61.0 (i386-portbld-freebsd10.4) libcurl/7.61.0 OpenSSL/1.0.1u 
zlib/1.2.11 nghttp2/1.32.0
Release-Date: 2018-07-11
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp 
smtps telnet tftp 
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL 
libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy 

Upgrading curl to 7.61.1 doesn't fix things.

-- 
Maxim Dounin
http://mdounin.ru/
___
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"


OpenSSL 1.1.1 Update report (ongoing)

2018-10-14 Thread Eric McCorkle
I'm currently in the process of updating my laptop, rebuilding world,
then rebuilding *all* ports.  I have a large number of ports installed
(around 1200), and I tend to select a lot of build options.

This report is intended to help shake out issues relating to OpenSSL
1.1.1.  I'll be adding to this report as things progress.

So far:

* I'd seen issues with some C++ files not including string.h.  I can't
seem to reproduce this on my other laptop, so I'm going to assume it's
fixed.

* Base libpmc jevents issue: buildworld fails for me when building
libpmc.  It appears to be missing a dependency link to build the jevents
executable in the pmu-events subdirectory.  I was able to work around
this by manually running make in that directory, then copying the result
to the object directory for LIB32 builds

* librtmp: C compile errors directly attributable to OpenSSL 1.1.1
(missing defs, etc)

* graphics/graphviz circular deps (unrelated to OpenSSL 1.1.1): graphviz
with gnomeui and/or librsvg options ticked ends up depending on vala,
which depends on graphviz.  Unrelated to OpenSSL 1.1.1, but warrants
reporting.


That's all so far.  Will send more info as it comes.



signature.asc
Description: OpenPGP digital signature


Re: OpenSSL 1.1.1 libssl.so version number

2018-10-14 Thread Don Lewis
On 12 Oct, Don Lewis wrote:
> Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
> /usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
> ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
> (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, the
> base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
> with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
> is ambiguous because there are now two different versions of libssl.so
> (1.0.2p and 1.1.1) with the same shared library version number.
> 
> I stumbled across this when debugging a virtualbox-ose configure
> failure.  The test executable was linked to the ports version of
> libssl.so but rtld chose the base libssl.so at run time.

It looks to me like the base libssl.so version needs to get moved to a
value that doesn't collide with ports, perhaps 12.  These are the
library version numbers currently used by the various ssl ports:

boringssl   1
openssl 9
openssl-devel   10
openssl111  11
libressl43
libressl-devel  44

___
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 panic at boot with vmm in loader.conf vs manually loading it

2018-10-13 Thread Cy Schubert
In message <8f033c7c-af8f-1ebc-d787-548634f10...@freebsd.org>, Allan 
Jude write
s:
> On 10/12/2018 11:52, Mike Tancsa wrote:
> > I am guessing this does not have anything to do with vmm being loaded,
> > but hardware being initialized in a particular order? If I load vmm in
> > loader.conf, the box panics at boot up.  However, manually loading it
> > all seems to work.  Hardware is PRIME X370-PRO, AMD Ryzen 5 1600X 32G
> > RAM.  FreeBSD 12.0-ALPHA9 r339328 GENERIC-NODEBUG
> > 
> > 
> > Leading up to the crash, I see
> > 
> > 
> > ugen0.1: <0x1022 XHCI root HUB> at usbus0
> > ugen1.1: <0x1b21 XHCI root HUB> at usbus1
> > Trying to mount root from zfs:zroot/ROOT/default []...
> > uhub0: ugen2.1: <0x1022 XHCI root HUB> at usbus2
> > Root mount waiting for: usbus2<0x1022 XHCI root HUB, class 9/0, rev
> > 3.00/1.00, addr 1> on usbus0
> >   usbus1 usbus0
> > uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
> > uhub2: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
> > uhub2: 4 ports with 4 removable, self powered
> > uhub1: 8 ports with 8 removable, self powered
> > uhub0: 22 ports with 22 removable, self powered
> > 
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address   = 0x398
> > fault code              = supervisor write data, page not pres
> ent
> > instruction pointer     = 0x20:0x8273d776
> > stack pointer           = 0x28:0xfe0075d55230
> > frame pointer           = 0x28:0xfe0075d55270
> > code segment            = base 0x0, limit 0xf, type 0x1b
> >                          = DPL 0, pres 1, long 1, de
> f32 0, gran 1
> > processor eflags        = interrupt enabled, resume, IOPL = 0
> > current process         = 1 (kernel)
> > [ thread pid 1 tid 12 ]
> > Stopped at      rrw_enter_read_impl+0x36:       lock cmpxchgq
> > %r14,0x18(%rbx)
> > db> bt
> > Tracing pid 1 tid 12 td 0xf8000567d580
> > rrw_enter_read_impl() at rrw_enter_read_impl+0x36/frame 0xfe0075d55270
> > zfs_mount() at zfs_mount+0x7b2/frame 0xfe0075d55400
> > vfs_domount() at vfs_domount+0x5b2/frame 0xfe0075d55630
> > vfs_donmount() at vfs_donmount+0x930/frame 0xfe0075d556d0
> > kernel_mount() at kernel_mount+0x3d/frame 0xfe0075d55720
> > parse_mount() at parse_mount+0x451/frame 0xfe0075d55860
> > vfs_mountroot() at vfs_mountroot+0x7a0/frame 0xfe0075d559f0
> > start_init() at start_init+0x27/frame 0xfe0075d55a70
> > fork_exit() at fork_exit+0x83/frame 0xfe0075d55ab0
> > fork_trampoline() at fork_trampoline+0xe/frame 0xfe0075d55ab0
> > --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > db>
>
> Strange that your crash is in ZFS here...
>
> Can you take a crash dump?
>
> It looks like something is trying to write to uninitialized memory here.
>

I was digging into this before I left on vacation. You can recreate 
this by,

mount -t zfs tank/nonexistent /mnt

A nonexistent dataset or zpool triggers the panic. I discovered it by 
chance through a typo in fstab. The panic occurs with INVARIANTS. 
Without INVARIANTS results in a hard hang.

I got as far as discovering that f_mntfromname pointed to a null string 
but ran out of time before I left.


-- 
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: Dell latitude 7490 touchpad support?

2018-10-13 Thread Mark Johnston
On Sat, Sep 29, 2018 at 08:48:57PM +0100, Johannes Lundberg wrote:
> Hi
> 
> I just got a new work laptop and the touchpad does not work. Some
> information points to that this machine has a Microsoft precision touchpad.
> I can't see any USB device so I'm wondering if this is an I2C device?
> 
> Do we have any driver for this?

I tried installing FreeBSD on a Latitude 7480 and hit the same problem.
Some digging turned up this diff, and with it applied I get a working
trackpad: https://reviews.freebsd.org/D16698
___
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: OpenSSL 1.1.1 libssl.so version number

2018-10-13 Thread Daniel Eischen


> On Oct 12, 2018, at 10:58 PM, Cy Schubert  wrote:
> 
> In message , Don Lewis writes:
>> Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
>> /usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
>> ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
>> (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, the
>> base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
>> with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
>> is ambiguous because there are now two different versions of libssl.so
>> (1.0.2p and 1.1.1) with the same shared library version number.
>> 
>> I stumbled across this when debugging a virtualbox-ose configure
>> failure.  The test executable was linked to the ports version of
>> libssl.so but rtld chose the base libssl.so at run time.
> 
> This is also the issue with ports-mgmt/pkg on a system that still 
> requires OpenSSL 1.0.2 from ports in order to support an old client.
> 
> cwfw# pkg info
> ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0 
> required by /usr/local/lib/libpkg.so.4 not defined
> cwfw# 
> 
> If I remove security/openssl, the above issue is resolved however the 
> old client, which should be replaced next year, fails to communicate 
> with the server. The classic rock & a hard place scenario.

Not saying this is a real solution for the general problem, but can you use a 
libmap.conf entry to work around this?

--
DE
___
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 panic at boot with vmm in loader.conf vs manually loading it

2018-10-13 Thread Allan Jude

On 10/12/2018 11:52, Mike Tancsa wrote:

I am guessing this does not have anything to do with vmm being loaded,
but hardware being initialized in a particular order? If I load vmm in
loader.conf, the box panics at boot up.  However, manually loading it
all seems to work.  Hardware is PRIME X370-PRO, AMD Ryzen 5 1600X 32G
RAM.  FreeBSD 12.0-ALPHA9 r339328 GENERIC-NODEBUG


Leading up to the crash, I see


ugen0.1: <0x1022 XHCI root HUB> at usbus0
ugen1.1: <0x1b21 XHCI root HUB> at usbus1
Trying to mount root from zfs:zroot/ROOT/default []...
uhub0: ugen2.1: <0x1022 XHCI root HUB> at usbus2
Root mount waiting for: usbus2<0x1022 XHCI root HUB, class 9/0, rev
3.00/1.00, addr 1> on usbus0
  usbus1 usbus0
uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
uhub2: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
uhub2: 4 ports with 4 removable, self powered
uhub1: 8 ports with 8 removable, self powered
uhub0: 22 ports with 22 removable, self powered

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x398
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x8273d776
stack pointer   = 0x28:0xfe0075d55230
frame pointer   = 0x28:0xfe0075d55270
code segment    = base 0x0, limit 0xf, type 0x1b
     = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process = 1 (kernel)
[ thread pid 1 tid 12 ]
Stopped at  rrw_enter_read_impl+0x36:   lock cmpxchgq
%r14,0x18(%rbx)
db> bt
Tracing pid 1 tid 12 td 0xf8000567d580
rrw_enter_read_impl() at rrw_enter_read_impl+0x36/frame 0xfe0075d55270
zfs_mount() at zfs_mount+0x7b2/frame 0xfe0075d55400
vfs_domount() at vfs_domount+0x5b2/frame 0xfe0075d55630
vfs_donmount() at vfs_donmount+0x930/frame 0xfe0075d556d0
kernel_mount() at kernel_mount+0x3d/frame 0xfe0075d55720
parse_mount() at parse_mount+0x451/frame 0xfe0075d55860
vfs_mountroot() at vfs_mountroot+0x7a0/frame 0xfe0075d559f0
start_init() at start_init+0x27/frame 0xfe0075d55a70
fork_exit() at fork_exit+0x83/frame 0xfe0075d55ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0075d55ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
db>


Strange that your crash is in ZFS here...

Can you take a crash dump?

It looks like something is trying to write to uninitialized memory here.



On a normal boot, the next line would be atrtc0

uhub0: Root mount waiting for: usbus2ugen2.1: <0x1022 XHCI root HUB> at usbus2
<0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
  usbus1 usbus0uhub1: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> 
on usbus1

uhub2: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
uhub1: 4 ports with 4 removable, self powered
uhub2: 8 ports with 8 removable, self powered
uhub0: 22 ports with 22 removable, self powered
atrtc0: providing initial system time
start_init: trying /sbin/init
Setting hostuuid: c3297ba0-3f01-11e7-8725-6045cba08a84.
Setting hostid: 0x094fa67e.
Starting file system checks:
Mounting local filesystems:.


snip




---Mike






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


net/samba48

2018-10-13 Thread Graham Perrin


How about 4.8 as the default for ports for 12?

Is it too late to throw the suggestion into the mix?

(Does the suggestion even make sense? Excuse the clumsy wording.)

As far as I can tell:

- 4.8 is vastly preferable for compatibility with services from modern versions 
of Windows

… and (personally) nearly all servers that I'm _required_ to use could not be 
used with Dolphin (and so on) with samba47.

TIA



For now I have this in my
/usr/local/etc/poudriere.d/make.conf

DEFAULT_VERSIONS+= samba=4.8

– which is effective, but (of course) some of the associated builds can be 
terribly time-consuming. Particularly when poudriere must 'start from scratch' 
after an update to the 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"


Also affects "pkg" (was: Re: OpenSSL 1.1.1 libssl.so version number)

2018-10-13 Thread Stefan Esser
Am 13.10.18 um 01:56 schrieb Don Lewis:
> Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
> /usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
> ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
> (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, the
> base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
> with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
> is ambiguous because there are now two different versions of libssl.so
> (1.0.2p and 1.1.1) with the same shared library version number.
> 
> I stumbled across this when debugging a virtualbox-ose configure
> failure.  The test executable was linked to the ports version of
> libssl.so but rtld chose the base libssl.so at run time.

I'm seeing something possibly related in pkg:

$ ldd /usr/local/lib/libpkg. | grep ssl
libpkg.a libpkg.solibpkg.so.4  libpkg.so.4.0.0

$ldd /usr/local/lib/libpkg.so.4 | grep ssl
libssl.so.9 => /usr/lib/libssl.so.9 (0x800679000)

This results in:

$ pkg -v
ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0 required by
/usr/local/lib/libpkg.so.4 not defined

My work-around was to copy pkg-static over pkg (I have not checked
whether the static version is linked against the system or ports
version of the library, but I assume the latter).

I have "DEFAULT_VERSIONS+= ssl=openssl" in make.conf but the same
problem exists if pkg is built without that setting.

My local version of portmaster has been changed to use pkg-static
in favor of pkg and I plan to commit that change to the portmaster
port, to make it resilient against this problem.

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


Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-13 Thread Ronald Klop

On Sat, 13 Oct 2018 02:00:16 +0200, Don Lewis  wrote:


On 11 Oct, Don Lewis wrote:

On 11 Oct, Don Lewis wrote:

On 11 Oct, freebsd.curr...@clogic.com.ua wrote:

On 2018-10-10 06:14, Michael Butler wrote:

On 10/9/18 5:34 PM, Glen Barber wrote:

OpenSSL has been updated to version 1.1.1 as of r339270.

It is important to rebuild third-party packages before running:

 # make -C /usr/src delete-old && make -C /usr/src delete-old-libs

Thank you for your patience while this work was in progress, and  
thank

you to all involved for their hard work in getting things ready for
this
update.


So far, I've found two ports that will no longer build. They are:

net-mgmt/net-snmp
security/opencryptoki

I simply chose those that were linked to /usr/lib/libssl.so.8 where  
the

openssl update creates libssl.so.9. There may be more I haven't found
yet,

imb


You always can add DEFAULT_VERSIONS+=ssl=openssl to /etc/make.conf to
use openssl from ports.
Anyway, I think apps from ports need to use openssl from ports.


I've been doing this for a long time, but I still see a fair amount of
breakage with the new base OpenSSL.  I suspect that some ports are
incorrectly stumbling across the new bits in base even though they
shouldn't be looking there.


security/p5-Net-SSLeay is hardwired to use base OpenSSL, so changing the
default version can't be done to unbreak p5-IO-Socket-SSL.

devel/libsoup appears to allow the OpenSSL version to be set, but  
doesn't

have an option for GSSAPI, so it attempts to use base GSSAPI with ports
OpenSSL which is not a valid combo.

emulators/virtualbox-ose is hardwired to use base OpenSSL.


I now think the problem with virtualbox-ose is not the port.  Rather it
is the fact that that the base libssl.so and the libssl.so installed by
the security/openssl have the same shared library version number even
though they are radically different OpenSSL versions.



I added this to libmap.conf:
cat /etc/libmap.conf
# $FreeBSD: head/libexec/rtld-elf/libmap.conf 338741 2018-09-18 00:25:00Z  
brd $

includedir /usr/local/etc/libmap.d
libssl.so.8 libssl.so.9
libcrypto.so.8  libcrypto.so.9

This made pkg run again. And now I'm waiting for the next pkg build to run  
pkg upgrade -f and upgrade everything.

I guess that will solve all issues.

Ronald.
___
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: OpenSSL 1.1.1 libssl.so version number

2018-10-13 Thread freebsd . current

On 2018-10-13 02:56, Don Lewis wrote:

Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
/usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
(1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, 
the

base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
is ambiguous because there are now two different versions of libssl.so
(1.0.2p and 1.1.1) with the same shared library version number.

I stumbled across this when debugging a virtualbox-ose configure
failure.  The test executable was linked to the ports version of
libssl.so but rtld chose the base libssl.so at run time.


I see the same issue with ports-mgmt/pkg when security/openssl 
installed. Have DEFAULT_VERSIONS+=ssl=openssl in /etc/make.conf


After rebuild pkg on 12-ALPHA9 system:

# pkg
ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0 
required by /usr/local/lib/libpkg.so.4 not defined

___
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: OpenSSL 1.1.1 libssl.so version number

2018-10-13 Thread Cy Schubert
In message , Don Lewis writes:
> Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
> /usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
> ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
> (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, the
> base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
> with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
> is ambiguous because there are now two different versions of libssl.so
> (1.0.2p and 1.1.1) with the same shared library version number.
>
> I stumbled across this when debugging a virtualbox-ose configure
> failure.  The test executable was linked to the ports version of
> libssl.so but rtld chose the base libssl.so at run time.

This is also the issue with ports-mgmt/pkg on a system that still 
requires OpenSSL 1.0.2 from ports in order to support an old client.

cwfw# pkg info
ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0 
required by /usr/local/lib/libpkg.so.4 not defined
cwfw# 

If I remove security/openssl, the above issue is resolved however the 
old client, which should be replaced next year, fails to communicate 
with the server. The classic rock & a hard place scenario.


-- 
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: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-12 Thread Don Lewis
On 11 Oct, Don Lewis wrote:
> On 11 Oct, Don Lewis wrote:
>> On 11 Oct, freebsd.curr...@clogic.com.ua wrote:
>>> On 2018-10-10 06:14, Michael Butler wrote:
 On 10/9/18 5:34 PM, Glen Barber wrote:
> OpenSSL has been updated to version 1.1.1 as of r339270.
> 
> It is important to rebuild third-party packages before running:
> 
>  # make -C /usr/src delete-old && make -C /usr/src delete-old-libs
> 
> Thank you for your patience while this work was in progress, and thank
> you to all involved for their hard work in getting things ready for 
> this
> update.
 
 So far, I've found two ports that will no longer build. They are:
 
 net-mgmt/net-snmp
 security/opencryptoki
 
 I simply chose those that were linked to /usr/lib/libssl.so.8 where the
 openssl update creates libssl.so.9. There may be more I haven't found 
 yet,
 
imb
>>> 
>>> You always can add DEFAULT_VERSIONS+=ssl=openssl to /etc/make.conf to 
>>> use openssl from ports.
>>> Anyway, I think apps from ports need to use openssl from ports.
>> 
>> I've been doing this for a long time, but I still see a fair amount of
>> breakage with the new base OpenSSL.  I suspect that some ports are
>> incorrectly stumbling across the new bits in base even though they
>> shouldn't be looking there.
> 
> security/p5-Net-SSLeay is hardwired to use base OpenSSL, so changing the
> default version can't be done to unbreak p5-IO-Socket-SSL.
> 
> devel/libsoup appears to allow the OpenSSL version to be set, but doesn't
> have an option for GSSAPI, so it attempts to use base GSSAPI with ports
> OpenSSL which is not a valid combo.
> 
> emulators/virtualbox-ose is hardwired to use base OpenSSL.

I now think the problem with virtualbox-ose is not the port.  Rather it
is the fact that that the base libssl.so and the libssl.so installed by
the security/openssl have the same shared library version number even
though they are radically different OpenSSL versions.

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


OpenSSL 1.1.1 libssl.so version number

2018-10-12 Thread Don Lewis
Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
/usr/lib/libssl.so.8.  The security/openssl port (1.0.2p) installed
${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
(1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11.  After the import, the
base OpenSSL library is /usr/lib/libssl.so.9.  Now if you build ports
with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
is ambiguous because there are now two different versions of libssl.so
(1.0.2p and 1.1.1) with the same shared library version number.

I stumbled across this when debugging a virtualbox-ose configure
failure.  The test executable was linked to the ports version of
libssl.so but rtld chose the base libssl.so at run time.

___
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: nginx introduces extra delay when talking to slow backend (probably FreeBSD kevent specific)

2018-10-12 Thread Dmitry Marakasov
* Dmitry Marakasov (amd...@amdmi3.ru) wrote:

I've gathered ktrace dumps for both cases, and it really looks that
the problem is related to kevent. After nginx sends response back
to client, it calls kevent(2) on client fd (which is 5).

When there is a bug (FreeBSD 11.2), the following happens:

 49365 nginx3.099362 CALL  
kevent(0x7,0x8022a2000,0,0x8023005c0,0x200,0x7fffe598)
 49365 nginx3.099419 STRU  struct kevent[] = {  }
 49365 nginx3.194695 STRU  struct kevent[] = { { ident=5, 
filter=EVFILT_WRITE, flags=0x20, fflags=0, data=0xbf88, 
udata=0x8023633d1 } }
 49365 nginx3.194733 RET   kevent 1
...
 49365 nginx3.194858 CALL  
kevent(0x7,0x8022a2000,0,0x8023005c0,0x200,0x7fffe598)
 49365 nginx3.194875 STRU  struct kevent[] = {  }
 49365 nginx3.835259 STRU  struct kevent[] = { { ident=5, 
filter=EVFILT_READ, flags=0x8020, fflags=0, data=0, 
udata=0x802346111 } }
 49365 nginx3.835299 RET   kevent 1

E.g. read and write events come separately, both with huge delays.

On FreeBSD-CURRENT which doesn't experience the problem, kdump looks this way:

  8049 nginx3.081367 CALL  
kevent(0x7,0x8012d1b40,0,0x8012da040,0x200,0x7fffe598)
  8049 nginx3.081371 STRU  struct kevent[] = {  }
  8049 nginx3.081492 STRU  struct kevent[] = { { ident=5, 
filter=EVFILT_WRITE, flags=0x20, fflags=0, data=0xbf88, 
udata=0x801341f11 }
 { ident=5, filter=EVFILT_READ, flags=0x8020, 
fflags=0, data=0, udata=0x801324e51 } }
  8049 nginx3.081498 RET   kevent 2

E.g. both events come immediately and at the same time.

Not sure if that's problem of kevent or something it relies on or the
way nginx uses it.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru  ..:  https://github.com/AMDmi3

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


nginx introduces extra delay when talking to slow backend (probably FreeBSD kevent specific)

2018-10-12 Thread Dmitry Marakasov
Hi!

I've noticed strange behavior of nginx with slow uwsgi backend (turned
out to not be uwsgi specific, and acually reproduces with any backend)
on FreeBSD 11.2

If backend replies in less than a second, nginx doesn't introduce any
additional latency and replies in the same time. However if backend
replies no more than around 1.2 seconds, nginx introduces an extra delay
and replies in around 2.2 seconds.

I've gathered some details here, including the graph of nginx reply time
vs. backend reply time:

https://github.com/AMDmi3/nginx-bug-demo

It reproduces on FreeBSD 11.2 and around year old -CURRENT, but not the
recent -CURRENT, so I suspect this may be FreeBSD specific (probably
kevent-related) and already fixed.

Still, I'm posting to both related nginx and FreeBSD lists for this
problem to be known.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru  ..:  https://github.com/AMDmi3

___
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: Good motherboard for Ryzen (first-gen)

2018-10-12 Thread Greg V




On Thu, Oct 11, 2018 at 11:40 PM, Eric van Gyzen  
wrote:

On 9/21/18 9:53 PM, Eric van Gyzen wrote:
I would like to build a Ryzen desktop.  Can anyone recommend a good 
motherboard?


I'm planning on a first-gen, because the second-gen has similar 
stability problems as the first-gen had, and AMD hasn't released 
errata for the second-gen yet (as far as I know...I would love to 
be wrong).


I would like to be a cool kid with a Threadripper, but I can't 
justify the cost, so I'm thinking maybe a Ryzen 7 with /only/ 8 
cores.  :)


Ideally, I want an Intel NIC, ECC memory support, and a 3-year 
warranty.


Thanks for all the responses.  They were very helpful.  Here is what 
I ended up building:


Mobo:  ASUS Prime X470-Pro
CPU:   Ryzen 7 2700X 3.7GHz 8-Core
RAM:   Corsair Vengeance LPX 2 x 16GB DDR4-2666 PC4-21300 C16
Video: ASUS GeForce GTX 1060 6GB
Disk:  Samsung 970 EVO 500GB TLC NAND M.2 2280 PCIe NVMe 3.0 x4
PSU:   EVGA SuperNOVA G3 750 Watt 80 Plus Gold ATX
Fan:   Cooler Master Hyper 212 EVO Universal CPU Cooler

It's running FreeBSD head.  BIOS version is 4018 (2018-07-12).  So 
far, it has been perfectly stable.  No crashes, no lockups.  It has 
been my work-from-home desktop for just over a week now.  I'm 
overclocking the memory a little, but nothing else.  The NIC works.  
The sound works, though I've only tested the rear analog output.  The 
video card works with the nvidia-driver, currently 390.87.  It's 
driving two 2560x1440 monitors over HDMI.


The only problem so far:  I can't get NUMA enabled.  I've set Memory 
Interleave to "off", but the BIOS still doesn't generate an ACPI SRAT 
table.  I'm still working on this.


You won't ever get NUMA enabled.

Because Ryzen 7 2700X is not a NUMA processor! :)

Only Threadripper and EPYC are.

Desktop Ryzen has a "slightly NUMA-like" thing going on, it's 
recognized as 'cache groups' in the line:
FreeBSD/SMP: 1 package(s) x 2 cache groups x 4 core(s) x 2 hardware 
threads


But it's not actual NUMA.

___
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: 10G performance regression / difference cxl and ix RELENG11 vs HEAD

2018-10-12 Thread Mike Tancsa
On 10/12/2018 12:52 PM, Navdeep Parhar wrote:
>
> The number of retries (the "Retr" column) should have been 0 in a
> controlled test like this.  Is this the default stack with all default
> parameters or have you tuned TCP and/or sockets in any way?

No tuning at all.  After a reboot and one test, I am seeing a bunch of
overflows. I am going to netboot back to RELENG_11 to confirm

 sysctl -a dev.cxl.1.stats
dev.cxl.1.stats.rx_tls_octets: 0
dev.cxl.1.stats.rx_tls_records: 0
dev.cxl.1.stats.tx_tls_octets: 0
dev.cxl.1.stats.tx_tls_records: 0
dev.cxl.1.stats.rx_trunc3: 0
dev.cxl.1.stats.rx_trunc2: 12
dev.cxl.1.stats.rx_trunc1: 0
dev.cxl.1.stats.rx_trunc0: 0
dev.cxl.1.stats.rx_ovflow3: 0
dev.cxl.1.stats.rx_ovflow2: 58
dev.cxl.1.stats.rx_ovflow1: 0
dev.cxl.1.stats.rx_ovflow0: 0
dev.cxl.1.stats.rx_ppp7: 0
dev.cxl.1.stats.rx_ppp6: 0
dev.cxl.1.stats.rx_ppp5: 0
dev.cxl.1.stats.rx_ppp4: 0
dev.cxl.1.stats.rx_ppp3: 0
dev.cxl.1.stats.rx_ppp2: 0
dev.cxl.1.stats.rx_ppp1: 0
dev.cxl.1.stats.rx_ppp0: 0
dev.cxl.1.stats.rx_pause: 0
dev.cxl.1.stats.rx_frames_1519_max: 0
dev.cxl.1.stats.rx_frames_1024_1518: 6169625
dev.cxl.1.stats.rx_frames_512_1023: 473
dev.cxl.1.stats.rx_frames_256_511: 133
dev.cxl.1.stats.rx_frames_128_255: 150
dev.cxl.1.stats.rx_frames_65_127: 1015832
dev.cxl.1.stats.rx_frames_64: 4
dev.cxl.1.stats.rx_runt: 0
dev.cxl.1.stats.rx_symbol_err: 0
dev.cxl.1.stats.rx_len_err: 0
dev.cxl.1.stats.rx_fcs_err: 0
dev.cxl.1.stats.rx_jabber: 0
dev.cxl.1.stats.rx_too_long: 0
dev.cxl.1.stats.rx_ucast_frames: 7186215
dev.cxl.1.stats.rx_mcast_frames: 0
dev.cxl.1.stats.rx_bcast_frames: 2
dev.cxl.1.stats.rx_frames: 7186217
dev.cxl.1.stats.rx_octets: 9437149499
dev.cxl.1.stats.tx_ppp7: 0
dev.cxl.1.stats.tx_ppp6: 0
dev.cxl.1.stats.tx_ppp5: 0
dev.cxl.1.stats.tx_ppp4: 0
dev.cxl.1.stats.tx_ppp3: 0
dev.cxl.1.stats.tx_ppp2: 0
dev.cxl.1.stats.tx_ppp1: 0
dev.cxl.1.stats.tx_ppp0: 0
dev.cxl.1.stats.tx_pause: 222
dev.cxl.1.stats.tx_drop: 0
dev.cxl.1.stats.tx_frames_1519_max: 0
dev.cxl.1.stats.tx_frames_1024_1518: 5409152
dev.cxl.1.stats.tx_frames_512_1023: 11968
dev.cxl.1.stats.tx_frames_256_511: 162
dev.cxl.1.stats.tx_frames_128_255: 26
dev.cxl.1.stats.tx_frames_65_127: 3095205
dev.cxl.1.stats.tx_frames_64: 210
dev.cxl.1.stats.tx_error_frames: 0
dev.cxl.1.stats.tx_ucast_frames: 8516714
dev.cxl.1.stats.tx_mcast_frames: 0
dev.cxl.1.stats.tx_bcast_frames: 9
dev.cxl.1.stats.tx_frames: 8516945
dev.cxl.1.stats.tx_octets: 8434330861
dev.cxl.1.stats.tx_parse_error: 0

> Regards,
> Navdeep
>
>
>

-- 
---
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: 10G performance regression / difference cxl and ix RELENG11 vs HEAD

2018-10-12 Thread Navdeep Parhar
On 10/12/18 9:52 AM, Navdeep Parhar wrote:
> The number of retries (the "Retr" column) should have been 0 in a

retransmits, not retries.
___
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: 10G performance regression / difference cxl and ix RELENG11 vs HEAD

2018-10-12 Thread Navdeep Parhar
On 10/12/18 8:37 AM, Mike Tancsa wrote:
> I was doing a quick iperf test with  r339328 GENERIC-NODEBUG  amd64, and
> noticed  I can no longer saturate a 10G nic with iperf3.  I tried first
> with the ix adapter, but was not sure if it was the driver or not. I
> tried as well with a Chelsio and got similar numbers.
> 
> # iperf3 -c 192.168.242.3
> Connecting to host 192.168.242.3, port 5201
> [  5] local 192.168.242.2 port 50474 connected to 192.168.242.3 port 5201
> [ ID] Interval   Transfer Bitrate Retr  Cwnd
> [  5]   0.00-1.00   sec   997 MBytes  8.36 Gbits/sec  717    175
> KBytes  
> [  5]   1.00-2.00   sec   975 MBytes  8.18 Gbits/sec  668   41.1
> KBytes  
> [  5]   2.00-3.00   sec   880 MBytes  7.38 Gbits/sec  846   25.6
> KBytes  
> [  5]   3.00-4.00   sec   523 MBytes  4.39 Gbits/sec  802   59.8
> KBytes  
> [  5]   4.00-5.00   sec   520 MBytes  4.36 Gbits/sec  882   48.4
> KBytes  
> [  5]   5.00-6.00   sec   543 MBytes  4.55 Gbits/sec  838   56.9
> KBytes  
> [  5]   6.00-7.00   sec   556 MBytes  4.66 Gbits/sec  850   11.4
> KBytes  
> [  5]   7.00-8.00   sec   538 MBytes  4.51 Gbits/sec  795   39.9
> KBytes  
> [  5]   8.00-9.00   sec   540 MBytes  4.53 Gbits/sec  853   57.0
> KBytes  
> [  5]   9.00-10.00  sec   503 MBytes  4.22 Gbits/sec  814   59.8
> KBytes  
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bitrate Retr
> [  5]   0.00-10.00  sec  6.42 GBytes  5.52 Gbits/sec  8065
> sender
> [  5]   0.00-10.00  sec  6.42 GBytes  5.52 Gbits/sec 
> receiver

The number of retries (the "Retr" column) should have been 0 in a
controlled test like this.  Is this the default stack with all default
parameters or have you tuned TCP and/or sockets in any way?

Regards,
Navdeep

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


Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-12 Thread Mike Tancsa
I am guessing this does not have anything to do with vmm being loaded,
but hardware being initialized in a particular order? If I load vmm in
loader.conf, the box panics at boot up.  However, manually loading it
all seems to work.  Hardware is PRIME X370-PRO, AMD Ryzen 5 1600X 32G
RAM.  FreeBSD 12.0-ALPHA9 r339328 GENERIC-NODEBUG


Leading up to the crash, I see


ugen0.1: <0x1022 XHCI root HUB> at usbus0
ugen1.1: <0x1b21 XHCI root HUB> at usbus1
Trying to mount root from zfs:zroot/ROOT/default []...
uhub0: ugen2.1: <0x1022 XHCI root HUB> at usbus2
Root mount waiting for: usbus2<0x1022 XHCI root HUB, class 9/0, rev
3.00/1.00, addr 1> on usbus0
 usbus1 usbus0
uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
uhub2: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
uhub2: 4 ports with 4 removable, self powered
uhub1: 8 ports with 8 removable, self powered
uhub0: 22 ports with 22 removable, self powered

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x398
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x8273d776
stack pointer   = 0x28:0xfe0075d55230
frame pointer   = 0x28:0xfe0075d55270
code segment    = base 0x0, limit 0xf, type 0x1b
    = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process = 1 (kernel)
[ thread pid 1 tid 12 ]
Stopped at  rrw_enter_read_impl+0x36:   lock cmpxchgq  
%r14,0x18(%rbx)
db> bt
Tracing pid 1 tid 12 td 0xf8000567d580
rrw_enter_read_impl() at rrw_enter_read_impl+0x36/frame 0xfe0075d55270
zfs_mount() at zfs_mount+0x7b2/frame 0xfe0075d55400
vfs_domount() at vfs_domount+0x5b2/frame 0xfe0075d55630
vfs_donmount() at vfs_donmount+0x930/frame 0xfe0075d556d0
kernel_mount() at kernel_mount+0x3d/frame 0xfe0075d55720
parse_mount() at parse_mount+0x451/frame 0xfe0075d55860
vfs_mountroot() at vfs_mountroot+0x7a0/frame 0xfe0075d559f0
start_init() at start_init+0x27/frame 0xfe0075d55a70
fork_exit() at fork_exit+0x83/frame 0xfe0075d55ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0075d55ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
db>

On a normal boot, the next line would be atrtc0

uhub0: Root mount waiting for: usbus2ugen2.1: <0x1022 XHCI root HUB> at usbus2
<0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
 usbus1 usbus0uhub1: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> 
on usbus1

uhub2: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
uhub1: 4 ports with 4 removable, self powered
uhub2: 8 ports with 8 removable, self powered
uhub0: 22 ports with 22 removable, self powered
atrtc0: providing initial system time
start_init: trying /sbin/init
Setting hostuuid: c3297ba0-3f01-11e7-8725-6045cba08a84.
Setting hostid: 0x094fa67e.
Starting file system checks:
Mounting local filesystems:.
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib 
/usr/local/lib/perl5/5.26/mach/CORE
32-bit compatibility ldconfig path: /usr/lib32
Setting hostname: ryzenbsd12.sentex.ca.

Manually loading it, dmesg shows

AMD-Vi: IVRS Info VAsize = 64 PAsize = 48 GVAsize = 2 flags:0
driver bug: Unable to set devclass (class: ppc devname: (unknown))
ivhd0:  on acpi0
ivhd0: Flag:b0
ivhd0: Features(type:0x11) MsiNumPPR = 0 PNBanks= 2 PNCounters= 0
ivhd0: Extended features[31:0]:22294ada HATS = 0x2 
GATS = 0x0 GLXSup = 0x1 SmiFSup = 0x1 SmiFRC = 0x2 GAMSup = 0x1 DualPortLogSup 
= 0x2 DualEventLogSup = 0x2
ivhd0: Extended features[62:32]:f77ef Max PASID: 0x2f DevTblSegSup = 0x3 
MarcSup = 0x1
ivhd0: supported paging level:7, will use only: 4
ivhd0: device range: 0x0 - 0x
ivhd0: PCI cap 0x190b640f@0x40 feature:19

and loading it manually with boot.verbose set

pci0: driver added
found-> vendor=0x1022, dev=0x1451, revid=0x00
domain=0, bus=0, slot=0, func=2
class=08-06-00, hdrtype=0x00, mfdev=1
cmdreg=0x0004, statreg=0x0010, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
MSI supports 4 messages, 64 bit
pci0:0:0:2: reprobing on driver added
found-> vendor=0x1022, dev=0x790b, revid=0x59
domain=0, bus=0, slot=20, func=0
class=0c-05-00, hdrtype=0x00, mfdev=1
cmdreg=0x0403, statreg=0x0220, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
pci0:0:20:0: reprobing on driver added
pci1: driver added
pci2: driver added
pci3: driver added
pci4: driver added
pci5: driver added
pci6: driver added
pci7: driver added
pci8: driver added
pci9: driver added
found-> vendor=0x1425, dev=0x5501, revid=0x00
domain=0, bus=9, slot=0, func=5
class=01-00-00, hdrtype=0x00, mfdev=1
cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
 

10G performance regression / difference cxl and ix RELENG11 vs HEAD

2018-10-12 Thread Mike Tancsa
I was doing a quick iperf test with  r339328 GENERIC-NODEBUG  amd64, and
noticed  I can no longer saturate a 10G nic with iperf3.  I tried first
with the ix adapter, but was not sure if it was the driver or not. I
tried as well with a Chelsio and got similar numbers.

# iperf3 -c 192.168.242.3
Connecting to host 192.168.242.3, port 5201
[  5] local 192.168.242.2 port 50474 connected to 192.168.242.3 port 5201
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.00   sec   997 MBytes  8.36 Gbits/sec  717    175
KBytes  
[  5]   1.00-2.00   sec   975 MBytes  8.18 Gbits/sec  668   41.1
KBytes  
[  5]   2.00-3.00   sec   880 MBytes  7.38 Gbits/sec  846   25.6
KBytes  
[  5]   3.00-4.00   sec   523 MBytes  4.39 Gbits/sec  802   59.8
KBytes  
[  5]   4.00-5.00   sec   520 MBytes  4.36 Gbits/sec  882   48.4
KBytes  
[  5]   5.00-6.00   sec   543 MBytes  4.55 Gbits/sec  838   56.9
KBytes  
[  5]   6.00-7.00   sec   556 MBytes  4.66 Gbits/sec  850   11.4
KBytes  
[  5]   7.00-8.00   sec   538 MBytes  4.51 Gbits/sec  795   39.9
KBytes  
[  5]   8.00-9.00   sec   540 MBytes  4.53 Gbits/sec  853   57.0
KBytes  
[  5]   9.00-10.00  sec   503 MBytes  4.22 Gbits/sec  814   59.8
KBytes  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.00  sec  6.42 GBytes  5.52 Gbits/sec  8065
sender
[  5]   0.00-10.00  sec  6.42 GBytes  5.52 Gbits/sec 
receiver


If I do a parallel transfer I get closer to the max.  However, on
RELENG11 I could do pretty close to a full 10G no problem with just a
single stream. This is with a GENERIC-NODEBUG kernel using a couple of
T520s back to back


t5iov1@pci0:9:0:1:  class=0x02 card=0x1425 chip=0x50011425
rev=0x00 hdr=0x00
    vendor = 'Chelsio Communications Inc'
    device = 'T520-CR Unified Wire Ethernet Controller'
    class  = network
    subclass   = ethernet
    bar   [10] = type Memory, range 64, base 0xf668, size 524288,
enabled
    bar   [18] = type Memory, range 64, base 0xf660, size 524288,
enabled
    bar   [20] = type Memory, range 64, base 0xf688a000, size 8192, enabled
    cap 01[40] = powerspec 3  supports D0 D3  current D0
    cap 05[50] = MSI supports 8 messages, 64 bit, vector masks
    cap 10[70] = PCI-Express 2 endpoint max data 512(2048) FLR RO NS
 link x8(x8) speed 8.0(8.0)



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


iflib_timer hits hung label; never recovers

2018-10-12 Thread Eric van Gyzen
My firewall is running head at r338402 (30 Aug).  It has three I211 NICs 
(PCI dev 0x1539).  About 24 hours ago, it said:


Oct 11 22:29:03 asbestos kernel: igb1: TX(1) desc avail = 42, pidx = 524
Oct 11 22:29:03 asbestos kernel: Link state changed to down
Oct 11 22:29:03 asbestos kernel: core: link state changed to DOWN

It keeps saying this periodically:

Oct 12 09:46:05 asbestos kernel: igb1: TX(1) desc avail = 1024, pidx = 0

$ dmesg | uniq -c
2455 igb1: TX(1) desc avail = 1024, pidx = 0

I can panic the box and get a vmcore, but what other information should 
I get before then?  I tried to attach kgdb to the running kernel, but it 
failed.  :(


I grabbed sysctl dev.igb.1 and dropped it here:

http://vangyzen.net/FreeBSD/igb.hang/

I haven't tried manually recovering with ifconfig because I want to 
diagnose why the driver couldn't do it automatically.  I imagine it's 
hard to test this code path.  :)


Eric
___
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: PKGBase installs openssl with pkg install -g 'FreeBSD-*'

2018-10-12 Thread Guido Falsi
On 12/10/18 15:45, Johan Hendriks wrote:
> I am testing pkg base on a 12 current system, and all went fine, but
> after the update to ALPHA9 the system keeps installing openssl-1.0.2p_1,1
> 
> I do a make buildworld && make buildkernel Then make packages.
> Then i upgrade the package tree so to say with pkg update -r FreeBSD-base
> 
> And then i do a pkg install -g 'FreeBSD-*'
> 
> root@builder:/usr/src # pkg install -g 'FreeBSD-*'
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> Updating FreeBSD-base repository catalogue...
> FreeBSD-base repository is up to date.
> All repositories are up to date.
> Checking integrity... done (0 conflicting)
> The following 333 package(s) will be affected (of 0 checked):
> 
> New packages to be INSTALLED:
>     openssl: 1.0.2p_1,1 [FreeBSD]
> 
> Installed packages to be UPGRADED:
>     FreeBSD-acct: 12.0.s20181011130928 -> 12.0.s20181012122202
> [FreeBSD-base]
>     FreeBSD-acct-debug: 12.0.s20181011130928 -> 12.0.s20181012122202
> [FreeBSD-base]
>     FreeBSD-acpi: 12.0.s20181011130928 -> 12.0.s20181012122202
> [FreeBSD-base]
> 
> ... SNIP .
> 
>     FreeBSD-vi-debug: 12.0.s20181011130928 -> 12.0.s20181012122202
> [FreeBSD-base]
>     FreeBSD-zfs: 12.0.s20181011130928 -> 12.0.s20181012122202 [FreeBSD-base]
> 
> Installed packages to be REINSTALLED:
>     pkg-1.10.5_3 [FreeBSD] (options changed)
> 
> Number of packages to be installed: 1
> Number of packages to be upgraded: 331
> Number of packages to be reinstalled: 1
> 
> The process will require 11 MiB more space.
> 
> Then the system is installing openssl and reinstalls pkg but after a
> reboot pkg is not working anymore.
> And gives me the following error.
> root@builder:/usr/src # pkg
> ld-elf.so.1: Shared object "libssl.so.8" not found, required by "pkg"
> 
> What can i do to get out of this cycle.
> 

Use pkg-static until you have a new pkg package linked to the new libssl
to upgrade pkg to.

Another option is preserving a copy of libssl.so.8 (and the related
libcrypto too most probably) before pkg upgrade

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


PKGBase installs openssl with pkg install -g 'FreeBSD-*'

2018-10-12 Thread Johan Hendriks
I am testing pkg base on a 12 current system, and all went fine, but
after the update to ALPHA9 the system keeps installing openssl-1.0.2p_1,1

I do a make buildworld && make buildkernel Then make packages.
Then i upgrade the package tree so to say with pkg update -r FreeBSD-base

And then i do a pkg install -g 'FreeBSD-*'

root@builder:/usr/src # pkg install -g 'FreeBSD-*'
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 333 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
    openssl: 1.0.2p_1,1 [FreeBSD]

Installed packages to be UPGRADED:
    FreeBSD-acct: 12.0.s20181011130928 -> 12.0.s20181012122202
[FreeBSD-base]
    FreeBSD-acct-debug: 12.0.s20181011130928 -> 12.0.s20181012122202
[FreeBSD-base]
    FreeBSD-acpi: 12.0.s20181011130928 -> 12.0.s20181012122202
[FreeBSD-base]

... SNIP .

    FreeBSD-vi-debug: 12.0.s20181011130928 -> 12.0.s20181012122202
[FreeBSD-base]
    FreeBSD-zfs: 12.0.s20181011130928 -> 12.0.s20181012122202 [FreeBSD-base]

Installed packages to be REINSTALLED:
    pkg-1.10.5_3 [FreeBSD] (options changed)

Number of packages to be installed: 1
Number of packages to be upgraded: 331
Number of packages to be reinstalled: 1

The process will require 11 MiB more space.

Then the system is installing openssl and reinstalls pkg but after a
reboot pkg is not working anymore.
And gives me the following error.
root@builder:/usr/src # pkg
ld-elf.so.1: Shared object "libssl.so.8" not found, required by "pkg"

What can i do to get out of this cycle.

regards


___
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: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto

2018-10-12 Thread Jung-uk Kim
On 18. 10. 12., Harry Schmalzbauer wrote:
> Am 12.10.2018 um 07:41 schrieb Dag-Erling Smørgrav:
>> Jung-uk Kim  writes:
>>> I forgot to patch one more file, i.e., Makefile.inc1.  Please try the
>>> attached patch instead.
>> Thanks, I missed that too.
>>
>> DES
> 
> Even with 339326 (adjusting Makefile.inc1) I get the foollowing build
> error (compiling 339326-amd64 on stable/11-amd64):
> building shared library libprivateldns.so.5
> cc -target x86_64-unknown-freebsd12.0
> --sysroot=/usr/local/share/deploy-tools/obj/HEAD-S12RP/usr/local/share/deploy-tools/HEAD/src
> 
> /amd64.amd64/tmp
> -B/usr/local/share/deploy-tools/obj/HEAD-S12RP/usr/local/share/deploy-tools/HEAD/src/amd64.amd64/tmp/usr/bin
> -f
> stack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings
> -Wl,--warn-shared-textrel  -o libprivateldns.so.5.full -Wl,-soname,libp
> rivateldns.so.5  `NM='nm' NMFLAGS='' lorder buffer.pico dane.pico
> dname.pico dnssec.pico dnssec_sign.pico dnssec_verify.pico dnsse
> c_zone.pico duration.pico error.pico higher.pico host2str.pico
> host2wire.pico keys.pico net.pico packet.pico parse.pico radix.pico
>  rbtree.pico rdata.pico resolver.pico rr.pico rr_functions.pico
> sha1.pico sha2.pico str2host.pico tsig.pico update.pico util.pico
> wire2host.pico zone.pico b64_ntop.pico b64_pton.pico |  tsort -q` -lssl 
> -lcrypto
> /usr/local/share/deploy-tools/obj/HEAD-S12RP/usr/local/share/deploy-tools/HEAD/src/amd64.amd64/tmp/usr/bin/ld:
> error: unable to fi
> nd library -lssl
> cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** [libprivateldns.so.5.full] Error code 1

https://docs.freebsd.org/cgi/mid.cgi?d218a9de-bfac-3a66-6197-4b58d5a78a94

The remaining patch is attached.

Jung-uk Kim
Index: Makefile.inc1
===
--- Makefile.inc1	(revision 339326)
+++ Makefile.inc1	(working copy)
@@ -2631,9 +2631,10 @@ lib/librtld_db__L: lib/libprocstat__L
 _secure_lib_libcrypto= secure/lib/libcrypto
 _secure_lib_libssl= secure/lib/libssl
 lib/libradius__L secure/lib/libssl__L: secure/lib/libcrypto__L
+secure/lib/libcrypto__L: lib/libthr__L
 .if ${MK_LDNS} != "no"
 _lib_libldns= lib/libldns
-lib/libldns__L: secure/lib/libcrypto__L
+lib/libldns__L: secure/lib/libssl__L
 .endif
 .if ${MK_OPENSSH} != "no"
 _secure_lib_libssh= secure/lib/libssh


signature.asc
Description: OpenPGP digital signature


Re: careless commits disrupt

2018-10-12 Thread Julian H. Stacey
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote:
> Julian H. Stacey  writes:
> > Stefan Esser  writes:
> > > You should also delete old files:
> > > 
> > > cd /usr/src
> > > make delete-old
> > > make delete-old-libs
> > I just ran that. It deleted lots of stuff. & I'd only run it 2 days ago.
> > I should have run it just before buildworld though.
> > It's not suggested in the top of 
> >   https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html
> > just at base of page.
> 
> That's because you should *never* run delete-old or delete-old-libs from
> a source tree that is newer than your installed system.  It may delete
> files which have been obsoleted by changes you haven't yet built and
> installed, to the point where you may be unable to build and install
> those changes.  

Arg ! So obviously true - in retrospect !  Yet I did it.
Could we add a comment to the Makefile please ? It could save others.
Maybe incorporate something from Stefan's (arrived while I was writing)

> In this particular case, it will, at the very least,
> break ssh and svn / svnlite.

(Fortunately I'm running local inside a wall, & always keep
both rlogin & ssh going to insure against foot shooting )

Thanks Dag-Erling !

Cheers,
Julian
-- 
Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich
 Brexit: 3,700,000 stolen votes in 1st referendum inc. 700,000 from Brits in EU
 Campaign lies & criminal funding, economy & pound down: New referendum needed.
http://exitbrexit.ukhttps://www.peoples-vote.uk/petition
___
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: careless commits disrupt

2018-10-12 Thread Stefan Esser
Am 12.10.18 um 07:39 schrieb Dag-Erling Sm�rgrav:
> Julian H. Stacey  writes:
>> Stefan Esser  writes:
>>> You should also delete old files:
>>>
>>> cd /usr/src
>>> make delete-old
>>> make delete-old-libs
>> I just ran that. It deleted lots of stuff. & I'd only run it 2 days ago.
>> I should have run it just before buildworld though.
>> It's not suggested in the top of 
>>   https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html
>> just at base of page.
> 
> That's because you should *never* run delete-old or delete-old-libs from
> a source tree that is newer than your installed system.  It may delete
> files which have been obsoleted by changes you haven't yet built and
> installed, to the point where you may be unable to build and install
> those changes.  In this particular case, it will, at the very least,
> break ssh and svn / svnlite.

Yes, sorry, running make delete-old-libs before buildworld is no good
idea, unless the old libraries have been copied to /usr/lib/compat before.


The advice to run "make delete-old-libs" came from the following message
from Glen Barber:

https://lists.freebsd.org/pipermail/freebsd-current/2018-October/071581.html

But the advice was not to delete old files before make buildworld, but only
before starting the required port upgrades ...


I might have mentioned, that I always preserve old shared libraries in
/usr/lib/compat before running "make delete-old-libs". This allows to run
old binaries, but prevents linking of new binaries against these libraries
(should not matter for make buildworld, but for building ports, which I do
at in the same script that invokes buildworld for critical kernel modules
that are to be built from ports).

No binary or library should reference a library whose path contains
/compat/ after all upgrades have been performed, obviously ...

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


Re: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto

2018-10-12 Thread Trond Endrestøl
On Fri, 12 Oct 2018 09:59+0200, Raúl wrote:

> (also deleted obj)

I do that whenever sys/sys/param.h changes. My builder wipes obj 
unconditionally every Monday in addition to the above.

-- 
Trond.
___
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: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto

2018-10-12 Thread Raúl
El 12/10/18 a las 7:30, Dag-Erling Smørgrav escribió:

> Alex, Julian and others are seeing linker failures in libcrypto, long
> before libldns.  I have the exact same issue on i386 but not amd64; I

  Same here on amd64, to follow head I was building on other box and
tarballing src and obj. Then I saw Glen's Heads-up and I tried (also
deleted obj). It built fine and that's why I suggested following Glen's
heads-up. This same box built this night from r339293 to r339318 without
patches nor glitches.

Raúl.
___
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: Dell latitude 7490 touchpad support?

2018-10-12 Thread Anton Shterenlikht
On Thu, Oct 11, 2018 at 08:20:13PM -0400, Hyun Hwang wrote:
> On Saturday, September 29, 2018, 8:48 PM (UTC+0100), Johannes Lundberg 
>  wrote:
> > Hi
> > 
> > I just got a new work laptop and the touchpad does not work. Some
> > information points to that this machine has a Microsoft precision touchpad.
> > I can't see any USB device so I'm wondering if this is an I2C device?

I think I have the same problem with Dell Precision 3520
under 12-current:

https://lists.freebsd.org/pipermail/freebsd-questions/2018-April/281490.html

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


  1   2   3   4   5   6   7   8   9   10   >