boot message: sendmsg on igb0: No buffer space available

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

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

virtualbox 5.2.20 triggers panic with FreeBSD 12.0-ALPHA10 r339432

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

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

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

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

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

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

[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

[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

[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

[Don Lewis]

On 19 Oct, Matthew D. Fuller wrote:
> 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

Thanks, that appears to be it.  I'm kind of wondering why I didn't run
into this before my last upgrade.  I was worried about this before my
previous upgrade, but didn't encounter any problems.  Since I hadn't
seen any discussion of this in a while, I thought the problem had been
resolved already ...

___
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 … can not be unloaded (kernel panic)) …

[Graham Perrin]

On 20/10/2018 00:01, Graham Perrin wrote:

> kldunload radeonkms
>
> – results in a kernel panic.

Found, at 
 
under 'drm-devel-kmod g20180822 screen freeze':

>> … normally you never unload the graphics driver so we haven't spent time on 
>> proper cleanup. Also, the drm module will cause panic if you try load load 
>> it again after unload.



Is the principle for -next- the same as for -devel-, should I simply _never_ 
attempt to unload the module?

$ date ; uname -v
Sat 20 Oct 2018 02:06:21 BST
FreeBSD 12.0-BETA1 r339438 GENERIC
$ pkg query '%o %v %R' drm-kmod drm-next-kmod gpu-firmware-kmod
graphics/drm-next-kmod 4.11.g20180822 poudriere
graphics/gpu-firmware-kmod g20180825 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: which way to update export_args structure?

[Rick Macklem]

Brooks Davis wrote:
> Yes, I think that's the right way foward.  Thanks for following up.
>Rick Macklem wrote:
>> Just in case you missed it in the email thread, in your general question 
>> below...
>> Did you mean/suggest that the fields of "struct export_args" be passed in as
>> separate options to nmount(2)?
>>
>> This sounds like a reasonable idea to me and I can ping Josh Paetzel w.r.t. 
>> the
>> changes to mountd.c to do it. (We are still in the testing stage for the 
>> updated
>> struct, so we might as well get that working first.)
>>
Well, Josh and I now have the code working via. passing the export_args
structure into the kernel using the "export"  nmount(2) option.

I have coded a partial patch (not complete nor tested) to pass the fields in as
separate nmount(2) arguments. Since the patch has gotten fairly large
already, I wanted to see if people do think this is the correct approach.
(I'll admit I don't understand why having the arguments would matter, given
 that only mountd does it. Would anyone run a 32bit mountd on a 64bit kernel?)

Anyhow, here's the partial patch showing the main changes when going from
passing in "struct export_args" to passing in separate fields:

--- kern/vfs_mount.c.nofsid22018-10-16 23:45:33.540348000 -0400
+++ kern/vfs_mount.c2018-10-19 20:01:14.92737 -0400
@@ -277,6 +277,7 @@ vfs_buildopts(struct uio *auio, struct v
size_t memused, namelen, optlen;
unsigned int i, iovcnt;
int error;
+   char *cp;
 
opts = malloc(sizeof(struct vfsoptlist), M_MOUNT, M_WAITOK);
TAILQ_INIT(opts);
@@ -325,7 +326,7 @@ vfs_buildopts(struct uio *auio, struct v
}
if (optlen != 0) {
opt->len = optlen;
-   opt->value = malloc(optlen, M_MOUNT, M_WAITOK);
+   opt->value = malloc(optlen + 1, M_MOUNT, M_WAITOK);
if (auio->uio_segflg == UIO_SYSSPACE) {
bcopy(auio->uio_iov[i + 1].iov_base, opt->value,
optlen);
@@ -335,6 +336,8 @@ vfs_buildopts(struct uio *auio, struct v
if (error)
goto bad;
}
+   cp = (char *)opt->value;
+   cp[optlen] = '\0';
}
}
vfs_sanitizeopts(opts);
@@ -961,6 +964,8 @@ vfs_domount_update(
int error, export_error, i, len;
uint64_t flag;
struct o2export_args o2export;
+   char *endptr;
+   int gotexp;
 
ASSERT_VOP_ELOCKED(vp, __func__);
KASSERT((fsflags & MNT_UPDATE) != 0, ("MNT_UPDATE should be here"));
@@ -1033,36 +1038,117 @@ vfs_domount_update(
 
export_error = 0;
/* Process the export option. */
-   if (error == 0 && vfs_getopt(mp->mnt_optnew, "export", &bufp,
-   &len) == 0) {
-   /* Assume that there is only 1 ABI for each length. */
-   switch (len) {
-   case (sizeof(struct oexport_args)):
-   case (sizeof(struct o2export_args)):
-   memset(&export, 0, sizeof(export));
-   memset(&o2export, 0, sizeof(o2export));
-   memcpy(&o2export, bufp, len);
-   export.ex_flags = (u_int)o2export.ex_flags;
-   export.ex_root = o2export.ex_root;
-   export.ex_anon = o2export.ex_anon;
-   export.ex_addr = o2export.ex_addr;
-   export.ex_addrlen = o2export.ex_addrlen;
-   export.ex_mask = o2export.ex_mask;
-   export.ex_masklen = o2export.ex_masklen;
-   export.ex_indexfile = o2export.ex_indexfile;
-   export.ex_numsecflavors = o2export.ex_numsecflavors;
-   for (i = 0; i < MAXSECFLAVORS; i++)
-   export.ex_secflavors[i] =
-   o2export.ex_secflavors[i];
-   export_error = vfs_export(mp, &export);
-   break;
-   case (sizeof(export)):
-   bcopy(bufp, &export, len);
-   export_error = vfs_export(mp, &export);
-   break;
-   default:
-   export_error = EINVAL;
-   break;
+   if (error == 0) {
+   gotexp = 0;
+   memset(&export, 0, sizeof(export));
+   if (vfs_getopt(mp->mnt_optnew, "export.exflags", &bufp,
+   &len) == 0) {
+   gotexp = 1;
+   export.ex_flags = strtouq(bufp, &endptr, 0);
+   if (endptr == bufp)
+   export_error = EINVAL;
+   }
+   if (vfs_getopt(mp->mnt_optnew, "export.root", &bufp,
+   &l