FYI: poudriere bulk -a ended up in a "all STOP" status. . . Turns out to be: /usr/bin/nohup in background vs. tty output issue

2017-11-29 Thread Mark Millard
I attempted the experiment of building all ports via poudriere (run via "/usr/bin/nohup . . . &" and watched via tail -f nohup.out ). It got to: [16:06:54] [14] [00:03:00] Finished net-mgmt/icinga-core | icinga-core-1.13.3_1: Success [16:06:57] [14] [00:00:01] Building devel/elixir-crontab | elix

Re: Booting UEFI ZFS is broken on arm64

2017-11-29 Thread Warner Losh
On Wed, Nov 29, 2017 at 5:54 PM, Warner Losh wrote: > > > On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb > wrote: > >> On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: >> > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb > > >> > wrote: >> > >> > > On Wed, Nov 29, 2017 at 05:33:46PM -0700,

Re: panic r326359

2017-11-29 Thread Masachika ISHIZUKA
>>After updating r326359, kernel panic has occure. ( I can boot up >> but panics within a few minutes.) >>It was good working up to r325887. > > Try to set: > kern.smp.disabled=1 > from loader or in /boot/loader.conf Thank you for reply, HPS. It seems good working by 'set kern.smp.di

Re: Booting UEFI ZFS is broken on arm64

2017-11-29 Thread Warner Losh
On Wed, Nov 29, 2017 at 5:43 PM, Shawn Webb wrote: > On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb > > wrote: > > > > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb

Re: Booting UEFI ZFS is broken on arm64

2017-11-29 Thread Shawn Webb
On Wed, Nov 29, 2017 at 05:42:52PM -0700, Warner Losh wrote: > On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb > wrote: > > > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb > > > wrote: > > > > > > > It appears that in the latest FreeBS

Re: Booting UEFI ZFS is broken on arm64

2017-11-29 Thread Warner Losh
On Wed, Nov 29, 2017 at 5:34 PM, Shawn Webb wrote: > On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb > > wrote: > > > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > > > booting UEFI GPT ZFS on my OverDrive 1000

Re: Booting UEFI ZFS is broken on arm64

2017-11-29 Thread Shawn Webb
On Wed, Nov 29, 2017 at 05:33:46PM -0700, Warner Losh wrote: > On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb > wrote: > > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > > this line: > > > > Using DTB provi

Re: Booting UEFI ZFS is broken on arm64

2017-11-29 Thread Warner Losh
On Wed, Nov 29, 2017 at 5:21 PM, Shawn Webb wrote: > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > this line: > > Using DTB provided by EFI at 0x801fe0. Which snapshot is that? Boot1 was broken until

Booting UEFI ZFS is broken on arm64

2017-11-29 Thread Shawn Webb
It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to this line: Using DTB provided by EFI at 0x801fe0. Then all output stops. I'm in the process of building a custom install ISO that has DEBUG turned on in the fdt

Re: CURRENT: kernel crash r326347: Cannot access memory at address 0x65657246

2017-11-29 Thread Subbsd
The same problem started the last week. The problem arises when on the CPU + I/O load - also when I recompile ports. I'm not completely sure but apparently I see a problem on the server ( with the same revision ) with SSDs only: on slow HDD disk still did not hang, while the server with SSD dies w

Re: panic r326359

2017-11-29 Thread Hans Petter Selasky
On 11/29/17 13:37, Masachika ISHIZUKA wrote: After updating r326359, kernel panic has occure. ( I can boot up but panics within a few minutes.) It was good working up to r325887. # cat /var/crash/info.6 Dump header from device: /dev/gpt/fbswap Architecture: amd64 Architecture Version

Re: Switch vfs.nfsd.issue_delegations to TUNABLE ?

2017-11-29 Thread Rick Macklem
Emmanuel Vadot wrote: [stuff snipped] > I haven't test by I can say that it will work, I actually wondered at >first doing that. The problem with this patch is what I tried to >describe in my first and following mails, since you can turn on and off >delegation you can still have delegation (so nfsr

Re: Switch vfs.nfsd.issue_delegations to TUNABLE ?

2017-11-29 Thread Emmanuel Vadot
Hello Rick, On Tue, 28 Nov 2017 23:18:57 + Rick Macklem wrote: > Did my usual and forgot to attach it. Here's the patch, rick > > > From: Rick Macklem > Sent: Tuesday, November 28, 2017 6:17:13 PM > To: Emmanuel Vadot > Cc: Konstantin Belousov; Fre

panic r326359

2017-11-29 Thread Masachika ISHIZUKA
After updating r326359, kernel panic has occure. ( I can boot up but panics within a few minutes.) It was good working up to r325887. # cat /var/crash/info.6 Dump header from device: /dev/gpt/fbswap Architecture: amd64 Architecture Version: 2 Dump Length: 505135104 Blocksize: 512 Com

CURRENT: kernel crash r326347: Cannot access memory at address 0x65657246

2017-11-29 Thread Hartmann, O.
Since yesterday's CURRENT update, I face worse and nasty problems on all of our CURRENT systems! Most recent CURRENT, as with r326363, crashes on booting the kernel, in another case the kernel is stuck and freezing after initialising the USB subsystem (the last thing I see on screen, keyboard full