Re: VNET branch destiny

[Ari Suutari]

Hi,

There is also this one:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673

It's about memory leak with pf tables + vnet, but the problem results
in panic, which is quite easily reproduced.

 Ari S.


On 10.4.2017 17:39, Ernie Luzar wrote:

To the VNET (VIMAGE) update project team members

Release 11.0 has some out standing VNET (VIMAGE) PR's that need 
addressing.


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

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

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

I believe 212000 and 212013 would require an rewrite replacing the 
kernel method they use to the user land method as used by ipfw. At the 
very lease it should be documented somewhere that pf & ipfilter do not 
work in an vnet/vimage jail.


PR 212031 looks like a vimage/vnet problem to me.


To the members of current, This bug report is not a jail(8) problem 
but a kernel problem that needs to be addressed. Could someone please 
look into fixing it. I effects all jail(8) users.

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

There is also the matter of removing the depreciated rc.conf jail 
definition method from the rc.d scripts making the jail.conf method 
the default. This is long over due and maybe something over looked in 
the 11.0 release.



Thank you for your attention.




___
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: r316677:EFI boot failure: Can't load kernel

[Hartmann, O.]

On Mon, 10 Apr 2017 21:04:04 +0200
"O. Hartmann"  wrote:

> Am Mon, 10 Apr 2017 21:59:00 +0300
> Toomas Soome  schrieb:
> 
> > > On 10. apr 2017, at 21:04, O. Hartmann 
> > > wrote:
> > > 
> > > Am Mon, 10 Apr 2017 16:14:21 +0300
> > > Toomas Soome  schrieb:
> > > 
> > >>> On 10. apr 2017, at 15:58, Hartmann, O.
> > >>>  wrote:
> > >>> 
> > >>> After today's update to r316677, some UEFI boxes (Fujitsu
> > >>> Celsius M740 XEON) reject to boot properly. They die
> > >>> immediately after loading /boot/loader.efi and jump into loader
> > >>> prompt:
> > >>> 
> > >>> [...]
> > >>> \
> > >>> can't load 'kernel'
> > >>> 
> > >>> 
> > >>> I had to investigate with an USB flashdrive the filesystem, but
> > >>> everything seems to be properly in place and installed.
> > >>> 
> > >>> I need advice how to revive the system after this.
> > >>> 
> > >> 
> > >> 
> > >> hm, this implies that r316676 was ok? If so, the only logical
> > >> conclusion is that it hast to do about the kernel size and if
> > >> there is enough space in UEFI memory to place the kernel.
> > >> 
> > >> You can fetch the current memory map from loader OK prompt with
> > >> memmap command, I hope this will help to identify the issue.
> > >> 
> > >> rgds,
> > >> toomas
> > > 
> > > 
> > > And?
> > > 
> > > Regrads,
> > > 
> > > oh
> > > 
> > 
> > Well, the memory needed is starting from the:
> > 
> > #define KERNEL_PHYSICAL_BASE (2*1024*1024)
> > 
> > and it should be large enough for kernel. But it feels a bit like
> > barking under the random tree; the problem is that the error is not
> > telling us anything why it did happen:(
> > 
> > This message you get is coming from sys/boot/common/boot.c, as part
> > of the autoload sequence; did you try to load kernel manually with
> > load command? also if you have old kernel around, does old kernel
> > get loaded?
> > 
> > rgds,
> > toomas
> > 
> > 
> > 
> >   
> 
> I haven't done anything yet, since the accident happened when I left
> my bureau and I desperately tried to examine on the fly what happened.
> 
> I'll be at the box tomorrow morning and I will check whether I can
> load the old kernel manually.
> 
> I'll report in what happened.
> 
> Kind regards,
> 
> oh
> 

I did the following:

replaced /boot/loader with /boot/loader.old (which was from end of
March)

copied /boot/loader.efi from the r315864 snapshot USB image
into /boot/loader.efi of the broken systems.

Aprt from the fact that I don't know which one is broken, the boxes are
booting again.

Conclusion: UEFI loader is broken!
___
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 branch destiny

[Bjoern A. Zeeb]

On 10 Apr 2017, at 20:59, peter.b...@bsd4all.org wrote:

No problem. Although pf is not used the vnet_destroy seems to be the 
issue. Some parts are not virtualized and the 
vnet_destroy->vnet_pf_uninit teardown happens on the host vnet so to 
speak.


The base system VNET is not shutdown;  it never was.   Module unload 
however could be a possible scenario.


___
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 branch destiny

[peter . blok]

No problem. Although pf is not used the vnet_destroy seems to be the issue. 
Some parts are not virtualized and the vnet_destroy->vnet_pf_uninit teardown 
happens on the host vnet so to speak.


> On 10 Apr 2017, at 22:11, Ernie Luzar  wrote:
> 
> peter.b...@bsd4all.org wrote:
>> Well, in my case it panic’ed on 11-stable. I’m only using pf on the host, 
>> not in the jail. I’m using Devin Teske’s jng to create a netgraph bridge. It 
>> is my intention to use the netgrpah bridge with bhyve as well.
> 
> 
> I also tested using Devin Teske’s jng to create a netgraph bridge on
> RELEASE 10.0 and it worked. But when I tried the same configuration on
> RELEASE 11.0 it no longer worked.
> 
> Sorry for the noise. I missed this sentence. "I’m only using pf on the
> host, not in the jail.". Thats what happens when I answer email after a long 
> day at work.
> 
> 

___
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 branch destiny

[Ernie Luzar]

peter.b...@bsd4all.org wrote:
Well, in my case it panic’ed on 11-stable. I’m only using pf on the 
host, not in the jail. I’m using Devin Teske’s jng to create a netgraph 
bridge. It is my intention to use the netgrpah bridge with bhyve as well.





I also tested using Devin Teske’s jng to create a netgraph bridge on
RELEASE 10.0 and it worked. But when I tried the same configuration on
RELEASE 11.0 it no longer worked.

Sorry for the noise. I missed this sentence. "I’m only using pf on the
host, not in the jail.". Thats what happens when I answer email after a 
long day at work.



___
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: r316677:EFI boot failure: Can't load kernel

[O. Hartmann]

Am Mon, 10 Apr 2017 21:59:00 +0300
Toomas Soome  schrieb:

> > On 10. apr 2017, at 21:04, O. Hartmann  wrote:
> > 
> > Am Mon, 10 Apr 2017 16:14:21 +0300
> > Toomas Soome  schrieb:
> >   
> >>> On 10. apr 2017, at 15:58, Hartmann, O.  wrote:
> >>> 
> >>> After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740
> >>> XEON) reject to boot properly. They die immediately after
> >>> loading /boot/loader.efi and jump into loader prompt:
> >>> 
> >>> [...]
> >>> \
> >>> can't load 'kernel'
> >>> 
> >>> 
> >>> I had to investigate with an USB flashdrive the filesystem, but
> >>> everything seems to be properly in place and installed.
> >>> 
> >>> I need advice how to revive the system after this.
> >>>   
> >> 
> >> 
> >> hm, this implies that r316676 was ok? If so, the only logical conclusion 
> >> is that it
> >> hast to do about the kernel size and if there is enough space in UEFI 
> >> memory to place
> >> the kernel.
> >> 
> >> You can fetch the current memory map from loader OK prompt with memmap 
> >> command, I
> >> hope this will help to identify the issue.
> >> 
> >> rgds,
> >> toomas  
> > 
> > 
> > And?
> > 
> > Regrads,
> > 
> > oh
> >   
> 
> Well, the memory needed is starting from the:
> 
> #define KERNEL_PHYSICAL_BASE (2*1024*1024)
> 
> and it should be large enough for kernel. But it feels a bit like barking 
> under the
> random tree; the problem is that the error is not telling us anything why it 
> did
> happen:(
> 
> This message you get is coming from sys/boot/common/boot.c, as part of the 
> autoload
> sequence; did you try to load kernel manually with load command? also if you 
> have old
> kernel around, does old kernel get loaded?
> 
> rgds,
> toomas
> 
> 
> 
> 

I haven't done anything yet, since the accident happened when I left my bureau 
and I
desperately tried to examine on the fly what happened.

I'll be at the box tomorrow morning and I will check whether I can load the old 
kernel
manually.

I'll report in what happened.

Kind regards,

oh

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpHFWyMu1dZM.pgp
Description: OpenPGP digital signature

Re: r316677:EFI boot failure: Can't load kernel

[Toomas Soome]

> On 10. apr 2017, at 21:04, O. Hartmann  wrote:
> 
> Am Mon, 10 Apr 2017 16:14:21 +0300
> Toomas Soome  schrieb:
> 
>>> On 10. apr 2017, at 15:58, Hartmann, O.  wrote:
>>> 
>>> After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740
>>> XEON) reject to boot properly. They die immediately after
>>> loading /boot/loader.efi and jump into loader prompt:
>>> 
>>> [...]
>>> \
>>> can't load 'kernel'
>>> 
>>> 
>>> I had to investigate with an USB flashdrive the filesystem, but
>>> everything seems to be properly in place and installed.
>>> 
>>> I need advice how to revive the system after this.
>>> 
>> 
>> 
>> hm, this implies that r316676 was ok? If so, the only logical conclusion is 
>> that it
>> hast to do about the kernel size and if there is enough space in UEFI memory 
>> to place
>> the kernel.
>> 
>> You can fetch the current memory map from loader OK prompt with memmap 
>> command, I hope
>> this will help to identify the issue.
>> 
>> rgds,
>> toomas
> 
> 
> And?
> 
> Regrads,
> 
> oh
> 

Well, the memory needed is starting from the:

#define KERNEL_PHYSICAL_BASE (2*1024*1024)

and it should be large enough for kernel. But it feels a bit like barking under 
the random tree; the problem is that the error is not telling us anything why 
it did happen:(

This message you get is coming from sys/boot/common/boot.c, as part of the 
autoload sequence; did you try to load kernel manually with load command? also 
if you have old kernel around, does old kernel get loaded?

rgds,
toomas




___
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: CURRENT: Compile time of ports has increased significantly since LLVM 4.0

[Ronald Klop]

There is a similar thread with subject: 'how to mark llvm* forbidden?'  
going on right now on this list.


Regards,
Ronald.


On Mon, 10 Apr 2017 14:10:03 +0200, O. Hartmann   
wrote:



We build pretty often world and ports.

With poudriere as port building backend, The daily/weekly builds have  
now grown
in compile time significantly since approx. the introduction of LLVM 4.0  
into

FreeBSD.

The build box is a LGA1150 IvyBridge XEON system with 3,4 GHz and 16 GB  
RAM.
The configuration of poudriere (most recent ports tree version, as well  
as most
recent CURRENT host and most recent CURRENT jail:  FreeBSD 12.0-CURRENT  
#4

r316067: Tue Mar 28 06:26:18 CEST 2017 amd64).

Within the past 4 - 6 months, wekbkit-gtk2 and webkit-gtk3 took ~ 1h 90  
min,
or, when started together, ~ 2h 40 min. Now they take each(!, even  
separately
started and indivuidually conmpiled without concurrent jobs) more than 3  
hours.


The same with /editors/libreoffice. On this bos it took 2h 40 min to  
compile

libreoffice 5.2.X up to 5.2.6, now it graces or is beyond 4 hours!

This observation is taken from a time span of 5 - 6 months and even with  
worst

case scenarios like parallel start of webkit[2]-gtk[23] in parallel.

So, does someone also diagnose this compile time stretching? I also see  
this

while regularily building ports via "make" in /usr/ports.


Thanks in advance,

Oliver
___
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: r316677:EFI boot failure: Can't load kernel

[O. Hartmann]

Am Mon, 10 Apr 2017 16:14:21 +0300
Toomas Soome  schrieb:

> > On 10. apr 2017, at 15:58, Hartmann, O.  wrote:
> > 
> > After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740
> > XEON) reject to boot properly. They die immediately after
> > loading /boot/loader.efi and jump into loader prompt:
> > 
> > [...]
> > \
> > can't load 'kernel'
> > 
> > 
> > I had to investigate with an USB flashdrive the filesystem, but
> > everything seems to be properly in place and installed.
> > 
> > I need advice how to revive the system after this.
> >   
> 
> 
> hm, this implies that r316676 was ok? If so, the only logical conclusion is 
> that it
> hast to do about the kernel size and if there is enough space in UEFI memory 
> to place
> the kernel.
> 
> You can fetch the current memory map from loader OK prompt with memmap 
> command, I hope
> this will help to identify the issue.
> 
> rgds,
> toomas


And?

Regrads,

oh

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpkSoVAEEdcs.pgp
Description: OpenPGP digital signature

Re: buildkernel broken for META_MODE

[Bryan Drewery]

On 4/7/2017 12:13 PM, Ngie Cooper (yaneurabeya) wrote:
> Hi,
>   I ran into this error when trying to run a meta mode build (for the 
> first time). It might be related to the recent assym* ordering changes.
> Thanks!
> -Ngie
> 
> $ cat /etc/src-env.conf
> WITH_AUTO_OBJ=  yes
> WITH_META_MODE= yes
> UPDATE_DEPENDFILE=  yes
> $ pwd
> /usr/src
> $ svnversion
> 316603M
> $ svn st | grep -v \?
> M   usr.bin/grep/tests/Makefile
> $ env SRCCONF=/dev/null NO_FILEMON=1 script ~/bk.ts make buildkernel -j3
> Script started on Fri Apr  7 11:52:38 2017
> Command: time make buildkernel -j3
> --- buildkernel ---
> make[1]: "/usr/src/Makefile.inc1" line 146: SYSTEM_COMPILER: Determined that 
> CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
> --- buildkernel ---
> --
 Kernel build for GENERIC started on Fri Apr  7 11:52:39 PDT 2017
> --
> ===> GENERIC
> mkdir -p /usr/obj/usr/src/sys
> --
 stage 1: configuring the kernel
> --
> ...
> Building /usr/obj/usr/obj/usr/src/sys/GENERIC/acpi_quirks.h
> Building /usr/obj/usr/obj/usr/src/sys/GENERIC/feeder_eq_gen.h
> Building /usr/obj/usr/obj/usr/src/sys/GENERIC/feeder_rate_gen.h
> Building /usr/obj/usr/obj/usr/src/sys/GENERIC/snd_fxdiv_gen.h
> Building /usr/obj/usr/obj/usr/src/sys/GENERIC/miidevs.h
> Building /usr/obj/usr/obj/usr/src/sys/GENERIC/pccarddevs.h
> Building /usr/obj/usr/obj/usr/src/sys/GENERIC/teken_state.h
> Building /usr/obj/usr/obj/usr/src/sys/GENERIC/usbdevs.h
> Building /usr/obj/usr/obj/usr/src/sys/GENERIC/vnode_if.h
> Building /usr/obj/usr/obj/usr/src/sys/GENERIC/ia32_genassym.o
> --- ia32_genassym.o ---
> :1:10: fatal error: 'opt_global.h' file not found
> #include "opt_global.h"
>  ^~
> 1 error generated.
> *** [ia32_genassym.o] Error code 1
> 
> make[2]: stopped in /usr/obj/usr/src/sys/GENERIC
> .ERROR_TARGET='ia32_genassym.o'
> .ERROR_META_FILE='/usr/obj/usr/obj/usr/src/sys/GENERIC/ia32_genassym.o.meta'
> 

It was previously reported here too
https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061946.html.
 It's a race.  I had forgotten about it but will look at it again.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: VNET branch destiny

[Ernie Luzar]

peter.b...@bsd4all.org wrote:
Well, in my case it panic’ed on 11-stable. I’m only using pf on the 
host, not in the jail. I’m using Devin Teske’s jng to create a netgraph 
bridge. It is my intention to use the netgrpah bridge with bhyve as well.


The panic (one-time) happened in pfioctl when I refreshed the rules. I 
suspect the problem is related to the following message when I stop the 
jail.


kernel: Freed UMA keg (pf table entries) was not empty (32 items).  Lost 
-57 pages of memory.


Current does not display the UMA message. I’m still narrowing down what 
happens with the pf table entries. My suspicion is that the netgraph 
bridge which creates a ng_ether device which is handed over to the 
jail vnet, is causing this.



The panic happened on LIST_REMOVE in keg_fetch_slab

static uma_slab_t
keg_fetch_slab(uma_keg_t keg, uma_zone_t zone, int flags)
{
uma_slab_t slab;
int reserve;

mtx_assert(>uk_lock, MA_OWNED);
slab = NULL;
reserve = 0;
if ((flags & M_USE_RESERVE) == 0)
reserve = keg->uk_reserve;

for (;;) {
/*
 * Find a slab with some space.  Prefer slabs that are 
partially
 * used over those that are totally full.  This helps to 
reduce

 * fragmentation.
 */
if (keg->uk_free > reserve) {
if (!LIST_EMPTY(>uk_part_slab)) {
slab = LIST_FIRST(>uk_part_slab);
} else {
slab = LIST_FIRST(>uk_free_slab);
*LIST_REMOVE(slab, us_link);*
LIST_INSERT_HEAD(>uk_part_slab, slab,
us_link);
}
MPASS(slab->us_keg == keg);
return (slab);
}

KDB: stack backtrace:
#0 0x805df0e7 at kdb_backtrace+0x67
#1 0x8059d176 at vpanic+0x186
#2 0x8059cfe3 at panic+0x43
#3 0x808ebaa2 at trap_fatal+0x322
#4 0x808ebaf9 at trap_pfault+0x49
#5 0x808eb336 at trap+0x286
#6 0x808d1441 at calltrap+0x8
#7 0x808a871e at zone_fetch_slab+0x6e
#8 0x808a87cd at zone_import+0x4d
#9 0x808a4fc9 at uma_zalloc_arg+0x529
#10 0x80803214 at pfr_ina_define+0x584
#11 0x807f0734 at pfioctl+0x3364
#12 0x80469288 at devfs_ioctl_f+0x128
#13 0x805fa925 at kern_ioctl+0x255
#14 0x805fa65f at sys_ioctl+0x16f
#15 0x808ec604 at amd64_syscall+0x6c4
#16 0x808d172b at Xfast_syscall+0xfb

The panic is so far not reproducible.


On 10 Apr 2017, at 15:50, Ernie Luzar > wrote:


peter.b...@bsd4all.org  wrote:
There have been issues with pf if I recall correctly. I currently 
have issues with stable, pf and vnet. There is an issue with pf table 
entries when an interface is moved to a different vnet.
Does anyone no if there is a specific fix for this that hasn’t been 
ported to stable? I haven’t had the time to test this on current.

Peter


PF was fixed in 11.0 to not panic when run on a host that has vimage 
compiled into the kernel. On 11.0 you can configure pf to run in a 
vnet jail but it really does not enforce any firewall rules because pf 
needs access to the kernel which jail(8) is blocking by design. As far 
as I know this is a show shopper that can not be fixed without a pf 
rewrite changing the way it works internally.


This PR gives all the details
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013




I also tested using Devin Teske’s jng to create a netgraph bridge on 
RELEASE 10.0 and it worked. But when I tried the same configuration on 
RELEASE 11.0 it no longer worked.


I strongly suggest you verify pf is functional in your vnet jail before 
you go chasing a dump which I suspect is totally misleading.


Setup a simple vnet pf rule set being run in the vnet jail that allows 
everything out except port 43 which the "whois" command uses and then 
issue the whois command from the vent jail console. If the vnet pf port 
43 rule is really blocking port 43 it will cause the whois command to 
not return any results. If the whois command returns results this 
indicates that even thought you have all the correct settings to run pf 
in your vnet jail and have received no error messages about it, pf is 
not really enforcing any rules. (IE; not working)  I am assuming that 
the host has no firewall at all or is at least allowing outbound port 43 
packets out.


___
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 branch destiny

[Ernie Luzar]

To the VNET (VIMAGE) update project team members

Release 11.0 has some out standing VNET (VIMAGE) PR's that need addressing.

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

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

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

I believe 212000 and 212013 would require an rewrite replacing the 
kernel method they use to the user land method as used by ipfw. At the 
very lease it should be documented somewhere that pf & ipfilter do not 
work in an vnet/vimage jail.


PR 212031 looks like a vimage/vnet problem to me.


To the members of current, This bug report is not a jail(8) problem but 
a kernel problem that needs to be addressed. Could someone please look 
into fixing it. I effects all jail(8) users.

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

There is also the matter of removing the depreciated rc.conf jail 
definition method from the rc.d scripts making the jail.conf method the 
default. This is long over due and maybe something over looked in the 
11.0 release.



Thank you for your attention.




___
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 branch destiny

[peter . blok]

Well, in my case it panic’ed on 11-stable. I’m only using pf on the host, not 
in the jail. I’m using Devin Teske’s jng to create a netgraph bridge. It is my 
intention to use the netgrpah bridge with bhyve as well.

The panic (one-time) happened in pfioctl when I refreshed the rules. I suspect 
the problem is related to the following message when I stop the jail.

kernel: Freed UMA keg (pf table entries) was not empty (32 items).  Lost -57 
pages of memory.

Current does not display the UMA message. I’m still narrowing down what happens 
with the pf table entries. My suspicion is that the netgraph bridge which 
creates a ng_ether device which is handed over to the jail vnet, is causing 
this.


The panic happened on LIST_REMOVE in keg_fetch_slab

static uma_slab_t
keg_fetch_slab(uma_keg_t keg, uma_zone_t zone, int flags)
{
uma_slab_t slab;
int reserve;

mtx_assert(>uk_lock, MA_OWNED);
slab = NULL;
reserve = 0;
if ((flags & M_USE_RESERVE) == 0)
reserve = keg->uk_reserve;

for (;;) {
/*
 * Find a slab with some space.  Prefer slabs that are partially
 * used over those that are totally full.  This helps to reduce
 * fragmentation.
 */
if (keg->uk_free > reserve) {
if (!LIST_EMPTY(>uk_part_slab)) {
slab = LIST_FIRST(>uk_part_slab);
} else {
slab = LIST_FIRST(>uk_free_slab);
LIST_REMOVE(slab, us_link);
LIST_INSERT_HEAD(>uk_part_slab, slab,
us_link);
}
MPASS(slab->us_keg == keg);
return (slab);
}

KDB: stack backtrace:
#0 0x805df0e7 at kdb_backtrace+0x67
#1 0x8059d176 at vpanic+0x186
#2 0x8059cfe3 at panic+0x43
#3 0x808ebaa2 at trap_fatal+0x322
#4 0x808ebaf9 at trap_pfault+0x49
#5 0x808eb336 at trap+0x286
#6 0x808d1441 at calltrap+0x8
#7 0x808a871e at zone_fetch_slab+0x6e
#8 0x808a87cd at zone_import+0x4d
#9 0x808a4fc9 at uma_zalloc_arg+0x529
#10 0x80803214 at pfr_ina_define+0x584
#11 0x807f0734 at pfioctl+0x3364
#12 0x80469288 at devfs_ioctl_f+0x128
#13 0x805fa925 at kern_ioctl+0x255
#14 0x805fa65f at sys_ioctl+0x16f
#15 0x808ec604 at amd64_syscall+0x6c4
#16 0x808d172b at Xfast_syscall+0xfb

The panic is so far not reproducible.


> On 10 Apr 2017, at 15:50, Ernie Luzar  wrote:
> 
> peter.b...@bsd4all.org wrote:
>> There have been issues with pf if I recall correctly. I currently have 
>> issues with stable, pf and vnet. There is an issue with pf table entries 
>> when an interface is moved to a different vnet.
>> Does anyone no if there is a specific fix for this that hasn’t been ported 
>> to stable? I haven’t had the time to test this on current.
>> Peter
> 
> PF was fixed in 11.0 to not panic when run on a host that has vimage compiled 
> into the kernel. On 11.0 you can configure pf to run in a vnet jail but it 
> really does not enforce any firewall rules because pf needs access to the 
> kernel which jail(8) is blocking by design. As far as I know this is a show 
> shopper that can not be fixed without a pf rewrite changing the way it works 
> internally.
> 
> This PR gives all the details
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: VNET branch destiny

[Ernie Luzar]

peter.b...@bsd4all.org wrote:

There have been issues with pf if I recall correctly. I currently have issues 
with stable, pf and vnet. There is an issue with pf table entries when an 
interface is moved to a different vnet.

Does anyone no if there is a specific fix for this that hasn’t been ported to 
stable? I haven’t had the time to test this on current.

Peter


PF was fixed in 11.0 to not panic when run on a host that has vimage 
compiled into the kernel. On 11.0 you can configure pf to run in a vnet 
jail but it really does not enforce any firewall rules because pf needs 
access to the kernel which jail(8) is blocking by design. As far as I 
know this is a show shopper that can not be fixed without a pf rewrite 
changing the way it works internally.


This PR gives all the details
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013


___
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: r316677:EFI boot failure: Can't load kernel

[Toomas Soome]

> On 10. apr 2017, at 15:58, Hartmann, O.  wrote:
> 
> After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740
> XEON) reject to boot properly. They die immediately after
> loading /boot/loader.efi and jump into loader prompt:
> 
> [...]
> \
> can't load 'kernel'
> 
> 
> I had to investigate with an USB flashdrive the filesystem, but
> everything seems to be properly in place and installed.
> 
> I need advice how to revive the system after this.
> 


hm, this implies that r316676 was ok? If so, the only logical conclusion is 
that it hast to do about the kernel size and if there is enough space in UEFI 
memory to place the kernel.

You can fetch the current memory map from loader OK prompt with memmap command, 
I hope this will help to identify the issue.

rgds,
toomas

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

r316677:EFI boot failure: Can't load kernel

[Hartmann, O.]

After today's update to r316677, some UEFI boxes (Fujitsu Celsius M740
XEON) reject to boot properly. They die immediately after
loading /boot/loader.efi and jump into loader prompt:

[...]
\
can't load 'kernel'


I had to investigate with an USB flashdrive the filesystem, but
everything seems to be properly in place and installed.

I need advice how to revive the system after this.

Thanks in advance,

Oliver
___
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: Compile time of ports has increased significantly since LLVM 4.0

[O. Hartmann]

We build pretty often world and ports.

With poudriere as port building backend, The daily/weekly builds have now grown
in compile time significantly since approx. the introduction of LLVM 4.0 into
FreeBSD.

The build box is a LGA1150 IvyBridge XEON system with 3,4 GHz and 16 GB RAM.
The configuration of poudriere (most recent ports tree version, as well as most
recent CURRENT host and most recent CURRENT jail:  FreeBSD 12.0-CURRENT #4
r316067: Tue Mar 28 06:26:18 CEST 2017 amd64).

Within the past 4 - 6 months, wekbkit-gtk2 and webkit-gtk3 took ~ 1h 90 min,
or, when started together, ~ 2h 40 min. Now they take each(!, even separately
started and indivuidually conmpiled without concurrent jobs) more than 3 hours.

The same with /editors/libreoffice. On this bos it took 2h 40 min to compile
libreoffice 5.2.X up to 5.2.6, now it graces or is beyond 4 hours!

This observation is taken from a time span of 5 - 6 months and even with worst
case scenarios like parallel start of webkit[2]-gtk[23] in parallel.

So, does someone also diagnose this compile time stretching? I also see this
while regularily building ports via "make" in /usr/ports.


Thanks in advance,

Oliver
___
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 branch destiny

[peter . blok]

There have been issues with pf if I recall correctly. I currently have issues 
with stable, pf and vnet. There is an issue with pf table entries when an 
interface is moved to a different vnet.

Does anyone no if there is a specific fix for this that hasn’t been ported to 
stable? I haven’t had the time to test this on current.

Peter
> On 10 Apr 2017, at 08:50, Pavel Timofeev  wrote:
> 
> 31 марта 2017 г. 17:40 пользователь "Bjoern A. Zeeb" <
> bzeeb-li...@lists.zabbadoz.net> написал:
> 
> On 31 Mar 2017, at 13:57, Pavel Timofeev wrote:
> 
> Hello, dear freebsd-current@!
>> 
>> There was FreeBSD Foundation report back in 2016Q2 where it told us
>> about VNET (VIMAGE) update project sponsored by foundation.
>> What is the current situation? Is it committed into base? If not
>> what's the plan?
>> 
> 
> Changes are in 12 and 11.   12 has seen more slight fixes due to other
> changes that other committers are tracking and I hope they merge to 11.
> 
> /bz
> 
> 
> Sorry, do you know if there is any plan to include VNET into GENERIC?
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: VNET branch destiny

[Pavel Timofeev]

31 марта 2017 г. 17:40 пользователь "Bjoern A. Zeeb" <
bzeeb-li...@lists.zabbadoz.net> написал:

On 31 Mar 2017, at 13:57, Pavel Timofeev wrote:

Hello, dear freebsd-current@!
>
> There was FreeBSD Foundation report back in 2016Q2 where it told us
> about VNET (VIMAGE) update project sponsored by foundation.
> What is the current situation? Is it committed into base? If not
> what's the plan?
>

Changes are in 12 and 11.   12 has seen more slight fixes due to other
changes that other committers are tracking and I hope they merge to 11.

/bz


Sorry, do you know if there is any plan to include VNET into GENERIC?
___
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"