panic: mtx_lock() by idle thread ... mutex igb0 @ ../../../net/iflib.c:2084

Feeding entropy: . lo0: link state changed to UP panic: mtx_lock() by idle thread 0xf800036ac000 on sleep mutex igb0 @ ../../../net/iflib.c:2084 cpuid = 4 time = 1540286062 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe007876e610 vpanic() at vpanic+0

[Bug 218849] Remove rc.conf jail configuration via jail_* variables

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Nicolas Hainaux changed: What|Removed |Added CC||nh.te...@gmail.com --- Comment #

loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated)

On 22.10.2018 12:27, Toomas Soome wrote: > It would help to get output from loader lsdev -v command. current loader crashes on "lsdev" for me: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232483 (it is not threadripper-related, my hardware is Intel Atom). -- // Lev Serebryakov signature

Panic during network initialization after r339583 -> r339639

Gory details in . I snapped some screenshots, but can't associate using laptop's iwn(4) (in stable/11, stable/12, or head/13) at the place I'm currently staying. (I may be able to at least get the screenshots uploaded to the Web server later

Re: loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated)

> On 23 Oct 2018, at 13:53, Lev Serebryakov wrote: > > On 22.10.2018 12:27, Toomas Soome wrote: > >> It would help to get output from loader lsdev -v command. > current loader crashes on "lsdev" for me: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232483 (it is not > threadripper-related

Re: careless commits disrupt

Am 22.10.18 um 23:09 schrieb Julian H. Stacey: > Hi, Reference: >> From:Stefan Esser >> Date:Fri, 12 Oct 2018 11:44:59 +0200 > > Stefan Esser wrote: >> I might have mentioned, that I always preserve old shared libraries in >> /usr/lib/compat before running "make de

Facing kernel panic during early boot from 12.0 ALPHA9

Hi, I have a amd64 based board, where I could able to install upto FreeBSD 12.0 ALPHA8 without issues. But starting ALPHA9, I start to see the below panic during early boot. Looks like some sleep at unwanted place. I am using the memstick image from dowload page. Please let me know if you need

RE: Panic during network initialization after r339583 -> r339639

This is caused by https://svnweb.freebsd.org/changeset/base/339634. --- 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 Messa

Re: Facing kernel panic during early boot from 12.0 ALPHA9

On Tue, Oct 23, 2018 at 05:43:15PM +0530, Rajesh Kumar wrote: > Hi, > > I have a amd64 based board, where I could able to install upto FreeBSD 12.0 > ALPHA8 without issues. But starting ALPHA9, I start to see the below panic > during early boot. Looks like some sleep at unwanted place. I am usin

Re: Facing kernel panic during early boot from 12.0 ALPHA9

Hi Mark, > From the db> prompt, could you please run "show page" and "show pageq", > and post the output? The system gets hung when it runs to db prompt. I only have the option to force shutdown at that point. Is there any other way, I can collect what you need? On Tue, Oct 23, 2018 at 7:05 PM

Re: Facing kernel panic during early boot from 12.0 ALPHA9

On Tue, Oct 23, 2018 at 07:10:02PM +0530, Rajesh Kumar wrote: > Hi Mark, > > > From the db> prompt, could you please run "show page" and "show pageq", > > and post the output? > > The system gets hung when it runs to db prompt. I only have the option to > force shutdown at that point. Is there a

Re: Facing kernel panic during early boot from 12.0 ALPHA9

Hi Mark, Please find attached the "sysctl vm" output with ALPHA8. On Tue, Oct 23, 2018 at 7:21 PM Mark Johnston wrote: > On Tue, Oct 23, 2018 at 07:10:02PM +0530, Rajesh Kumar wrote: > > Hi Mark, > > > > > From the db> prompt, could you please run "show page" and "show pageq", > > > and post th

current kernel built without TCO (-fno-optimize-sibling-calls) is almost unusable

I've built 13/current kernel with "-fno-optimize-sibling-calls" option to have full and true stacks. And my test stand (which is lousy Atom D2500, I need to admit) becomes unusable with such kernel. Here are NO any errors or message on console, but system drops ssh connection after several se

current kernel built without TCO (-fno-optimize-sibling-calls) is almost unusable

On 23.10.2018 17:21, Lev Serebryakov wrote: > Here are NO any errors or message on console, but system drops ssh > connection after several seconds (soemtimes before logon, sometimes > right after showing shell), timeouts connections to it, etc. > > When I able to run "top -SH" (for several sec

Solved (Was: current kernel built without TCO (-fno-optimize-sibling-calls) is almost unusable)

On 23.10.2018 17:25, Lev Serebryakov wrote: >> Here are NO any errors or message on console, but system drops ssh >> connection after several seconds (soemtimes before logon, sometimes >> right after showing shell), timeouts connections to it, etc. >> >> When I able to run "top -SH" (for several

Re: loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated)

On Tue, Oct 23, 2018 at 5:54 AM Toomas Soome wrote: > > > On 23 Oct 2018, at 13:53, Lev Serebryakov wrote: > > > > On 22.10.2018 12:27, Toomas Soome wrote: > > > >> It would help to get output from loader lsdev -v command. > > current loader crashes on "lsdev" for me: > > https://bugs.freebsd.or

[CFT] patch for suspend on systems with shared interrupts

I am working on a patch to improve stability of suspend (and resume) on systems where an interrupt line (legacy PCI) is shared by multiple devices. If you have such a system and you experience hangs during suspend or resume, could you please test the patch? It's easy to check if you have shared

Re: loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated)

On Tue, Oct 23, 2018 at 08:54:24AM -0600, Warner Losh wrote: > On Tue, Oct 23, 2018 at 5:54 AM Toomas Soome wrote: > > > > > > On 23 Oct 2018, at 13:53, Lev Serebryakov wrote: > > > > > > On 22.10.2018 12:27, Toomas Soome wrote: > > > > > >> It would help to get output from loader lsdev -v comma

Re: which way to update export_args structure?

> On Oct 22, 2018, at 09:49, Josh Paetzel wrote: > > > >> On Mon, Oct 22, 2018, at 11:05 AM, Brooks Davis wrote: >> >> >> This is the direction I'd been thinking. FWIW, the usecase is more that >> once you've moved away from the struct it's easy to make incremental >> changes then to use a

Re: ctm(1) deprecation in the FreeBSD base system?

I have no problem turning ctm into a port. But I would appreciate advice on whether there is a standard or easy process for converting software from the FreeBSD base to a port. If not, I can muddle my way through it. But give me some time (a few months) to get it done, because the rest of my lif

Re: careless commits disrupt

> Am 22.10.18 um 23:09 schrieb Julian H. Stacey: > > Hi, Reference: > >> From: Stefan Esser > >> Date: Fri, 12 Oct 2018 11:44:59 +0200 > > > > Stefan Esser wrote: > >> I might have mentioned, that I always preserve old shared libraries in > >> /usr/lib/compat before runn

Re: ctm(1) deprecation in the FreeBSD base system?

Am 23.10.18 um 17:27 schrieb Montgomery-Smith, Stephen: > I have no problem turning ctm into a port. But I would appreciate > advice on whether there is a standard or easy process for converting > software from the FreeBSD base to a port. If not, I can muddle my way > through it. But give me som

Re: which way to update export_args structure?

Brooks Davis wrote this message on Mon, Oct 22, 2018 at 16:05 +: > > + switch (len) { > > + case (sizeof(struct oexport_args)): > > + case (sizeof(struct o2export_args)): > > + memset(&export, 0, sizeof(export)); >

Re: ctm(1) deprecation in the FreeBSD base system?

On Tue, Oct 23, 2018 at 10:44 AM Stefan Esser wrote: > Am 23.10.18 um 17:27 schrieb Montgomery-Smith, Stephen: > > I have no problem turning ctm into a port. But I would appreciate > > advice on whether there is a standard or easy process for converting > > software from the FreeBSD base to a po

savecore: BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276

Hello, I have a freshly built 12.0-ALPHA10 (r339406) and the kernel panicked at some point (another mail coming on that). I have a full dump partition enabled, but during savecore quite lot BFD assertion messages appear: Tue Oct 23 18:45:53 CEST 2018 FreeBSD radziecki 12.0-ALPHA10 FreeBSD 12.0-A

Re: ctm(1) deprecation in the FreeBSD base system?

> Am 23.10.18 um 17:27 schrieb Montgomery-Smith, Stephen: > > I have no problem turning ctm into a port. But I would appreciate > > advice on whether there is a standard or easy process for converting > > software from the FreeBSD base to a port. If not, I can muddle my way > > through it. But g

Re: ctm(1) deprecation in the FreeBSD base system?

Am 23.10.18 um 19:06 schrieb Warner Losh: > > > On Tue, Oct 23, 2018 at 10:44 AM Stefan Esser > wrote: > > Am 23.10.18 um 17:27 schrieb Montgomery-Smith, Stephen: > > I have no problem turning ctm into a port.  But I would appreciate > > advice on whether th

Re: ctm(1) deprecation in the FreeBSD base system?

On 10/23/18 11:44 AM, Stefan Esser wrote: > Am 23.10.18 um 17:27 schrieb Montgomery-Smith, Stephen: >> I have no problem turning ctm into a port. But I would appreciate >> advice on whether there is a standard or easy process for converting >> software from the FreeBSD base to a port. If not, I c

Re: ctm(1) deprecation in the FreeBSD base system?

On Tue, Oct 23, 2018, 12:18 PM Stefan Esser wrote: > Am 23.10.18 um 19:06 schrieb Warner Losh: > > > > > > On Tue, Oct 23, 2018 at 10:44 AM Stefan Esser > > wrote: > > > > Am 23.10.18 um 17:27 schrieb Montgomery-Smith, Stephen: > > > I have no problem turning ctm

UEFI boot hangs after loader

Just upgraded my Asus UX303L (amd64) from 11-STABLE to 12.0-BETA1 r339529 by source. Have a problem with booting which hangs after: >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 5 block devices ... done ZFS found the following pools: zroot UFS

Re: ctm(1) deprecation in the FreeBSD base system?

A cost(=time)/benefit look on moving ctm from src/ to ports/ : - No tangible architecture benefit (its not like purging an old driver to makes kernel support simpler, or avoiding clashing libs etc) - FreeBSD would shrink 0.028 % of the size of src/ cd /pub/FreeBSD/branches/-current/src

Re: UEFI boot hangs after loader

Do you get boot menu? if so, press esc to get to ok prompt, then type start - if its bootfort based loader, it will load the kernel and modules. lsmod will then list the loaded files. If the loader prompt is still usable, then next command would be: boot rgds, toomas > On 23 Oct 2018, at 20:45

Re: UEFI boot hangs after loader

If boot menu is the screen where you get the options for various kernels and the picture of the daemon head, no. It stops at the point in my email — though not as I said just before the kernel is loaded but in point of fact before the menu. I've also rebuilt the kernel and still can't use efiboot

Re: UEFI boot hangs after loader

hm. in that case, whats the content of /boot/loader.rc ? rgds, toomas > On 23 Oct 2018, at 23:01, Harry Newton wrote: > > If boot menu is the screen where you get the options for various kernels and > the picture of the daemon head, no. It stops at the point in my email — > though not as I s

Re: UEFI boot hangs after loader

So it's got FORTH in it, but my loader is lua based, and also doesn't appear to read loader.rc. /H On 23 October 2018 at 21:03, Toomas Soome wrote: > hm. in that case, whats the content of /boot/loader.rc ? > > rgds, > toomas > > > On 23 Oct 2018, at 23:01, Harry Newton wrote: > > If boot menu

Re: ctm(1) deprecation in the FreeBSD base system?

> A cost(=time)/benefit look on moving ctm from src/ to ports/ : > - No tangible architecture benefit (its not like purging an old driver > to makes kernel support simpler, or avoiding clashing libs etc) > - FreeBSD would shrink 0.028 % of the size of src/ > cd /pub/FreeBSD/branches/-curren

Re: UEFI boot hangs after loader

ok, in that case I’d suggest to test out if forth based one is still working - at least you can get the bootable system. And then there is a chance to debug the lua version too (note it should be possible to chain /boot/loader_lua.efi). rgds, toomas > On 23 Oct 2018, at 23:08, Harry Newton wro

Re: ctm(1) deprecation in the FreeBSD base system?

On Tue, Oct 23, 2018 at 2:13 PM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > A cost(=time)/benefit look on moving ctm from src/ to ports/ : > > - No tangible architecture benefit (its not like purging an old driver > > to makes kernel support simpler, or avoiding clashing li

Re: UEFI boot hangs after loader

Yes ... so as everything is built, can I just alter LOADER_DEFAULT_INTERP in /etc/make.conf and then reinstall just the loader and boot parts onto the UEFI partition ? If so, how ? On 23 October 2018 at 21:17, Toomas Soome wrote: > ok, in that case I’d suggest to test out if forth based one is

Re: UEFI boot hangs after loader

you should have the binaries in boot - just ln (or copy) one to loader.efi rgds, toomas > On 23 Oct 2018, at 23:22, Harry Newton wrote: > > Yes ... so as everything is built, can I just alter LOADER_DEFAULT_INTERP in > /etc/make.conf and then reinstall just the loader and boot parts onto the

Re: UEFI boot hangs after loader

Right ... I've the binaries in /boot, freshly made. This might be a silly question ... do I not need to copy them (or dd the boot1.efifat image) to the EFI partition ? /H On 23 October 2018 at 21:30, Toomas Soome wrote: > you should have the binaries in boot - just ln (or copy) one to loader.e

RE: ctm(1) deprecation in the FreeBSD base system?

And more importantly a great thanks for ctm from all of us who depended on it for ages ;-) -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Poul-Henning Kamp Sent: 22 October 2018 21:59 To: Warner Losh Cc: Rodney W. Grimes

Re: UEFI boot hangs after loader

I set LOADER_DEFAULT_INTERP=4th and went in /usr/src/stand and re-made the binaries in /boot but this doesn't solve the problem. It did copy /boot/loader_4th.efi to /boot/loader.efi which is (according to uefi(8) which is what is called from /boot/boot1.efi and which contains the strings I see on

FIXED - Head won't build tool-chain at r339586

On 10/22/18 10:49 AM, Thomas Laus wrote: > I have been building HEAD for the past several years about every 2 > weeks. I updated my base source today from r339234 to r339586 and the > buildworld stops because a missing libarchive.so.7 dependency. It is > looking for libcrypto.so.9 which has not b

Re: UEFI boot hangs after loader

Hi, I suspect 4th vs. lua has no impact here, given the output shown -- can you throw one of the installer images [0] on some removable media and give that a shot for booting? If that works, we can explore UEFI variables from there. efibootmgr will only work on a successful UEFI boot, unfortunate

Re: panic: mtx_lock() by idle thread ... mutex igb0 @ ../../../net/iflib.c:2084

Will fix. On Tue, Oct 23, 2018 at 2:21 AM Peter Holm wrote: > > Feeding entropy: . > lo0: link state changed to UP > panic: mtx_lock() by idle thread 0xf800036ac000 on sleep mutex igb0 @ > ../../../net/iflib.c:2084 > cpuid = 4 > time = 1540286062 > KDB: stack backtrace: > db_trace_self_wrappe

build is broken

as of rev: 339671 build fails https://dpaste.de/NCeV/raw - Miwi -- +-oOO--(_)--OOo-+ With best Regards, Martin Wilke (miwi_(at)_FreeBSD.org) Mess with the Best, Die like the Rest ___ freebsd-current@fre

Re: build is broken

Konstantin fixed it a few minutes ago. Warner On Tue, Oct 23, 2018, 6:09 PM Martin Wilke wrote: > as of rev: 339671 > > build fails > > https://dpaste.de/NCeV/raw > > - Miwi > -- > +-oOO--(_)--OOo-+ > With best Regards, > Martin Wilke (miwi_(at)_F

Re: build is broken

Thanks. On Wed, Oct 24, 2018 at 8:11 AM Warner Losh wrote: > Konstantin fixed it a few minutes ago. > > Warner > > On Tue, Oct 23, 2018, 6:09 PM Martin Wilke wrote: > >> as of rev: 339671 >> >> build fails >> >> https://dpaste.de/NCeV/raw >> >> - Miwi >> -- >> +-oOO--(_)--OOo---