Re: svn commit: r316977 - head/sys/dev/syscons

Am Sat, 15 Apr 2017 18:00:18 -0700 Conrad Meyer schrieb: > On Sat, Apr 15, 2017 at 1:21 PM, O. Hartmann wrote: > > Am Sat, 15 Apr 2017 20:03:50 + (UTC) > > Bruce Evans schrieb: > > > >> Author: bde > >> Date: Sat Apr 15 20:03:50

Re: svn commit: r316977 - head/sys/dev/syscons

On Sat, Apr 15, 2017 at 1:21 PM, O. Hartmann wrote: > Am Sat, 15 Apr 2017 20:03:50 + (UTC) > Bruce Evans schrieb: > >> Author: bde >> Date: Sat Apr 15 20:03:50 2017 >> New Revision: 316977 >> URL: https://svnweb.freebsd.org/changeset/base/316977 > >

Re: r316958: booting a server takes >10 minutes!

On Sat, Apr 15, 2017 at 02:24:05PM -0500, Larry Rosenman wrote: > Current SVN seems to have fixed it (via sobomax@ syslogd commit). > Confirmed: I had experienced the issue running: FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #315 r316956M/316956:1200028: Sat Apr 15

Re: svn commit: r316977 - head/sys/dev/syscons

Am Sat, 15 Apr 2017 20:03:50 + (UTC) Bruce Evans schrieb: > Author: bde > Date: Sat Apr 15 20:03:50 2017 > New Revision: 316977 > URL: https://svnweb.freebsd.org/changeset/base/316977 > > Log: > Add a 10x16 mouse cursor and use it in all graphics (strictly, pixel) >

Re: r316958: booting a server takes >10 minutes!

Current SVN seems to have fixed it (via sobomax@ syslogd commit). borg.lerctr.org /usr/src $ svn info;uname -aKU Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID:

Re: r316958: booting a server takes >10 minutes!

Hi! Larry wrote: > It was with PostgreSQL starting and I also noted Exim, SSHD, and > others spinning. Lots of NO BUFFERSPACE in a truss. Interesting. I had my build host being dead in the network (no ping, also with bufferspace problems), but I was able to login via console. And: It failed to

Re: r316958: booting a server takes >10 minutes!

Am Sat, 15 Apr 2017 12:19:02 -0400 Allan Jude schrieb: > On 2017-04-15 07:53, O. Hartmann wrote: > > Recent CURRENT running on a server makes the system booting in multiuser > > mode booting > > incredibly slow! On a machine, before I interrupted the booting process > >

Re: r316958: booting a server takes >10 minutes!

On 4/15/17, 1:43 PM, "David Wolfskill" wrote: On Sat, Apr 15, 2017 at 04:41:28PM +, Poul-Henning Kamp wrote: > > ... > >And I understand that the Cloudflare/f-root server issue isn't quite >

Re: r316958: booting a server takes >10 minutes!

On Sat, Apr 15, 2017 at 04:41:28PM +, Poul-Henning Kamp wrote: > > ... > >And I understand that the Cloudflare/f-root server issue isn't quite > >that recent: "The new f-root servers appeared around two weeks ago" > > And isn't the zone cache expiry time around two weeks as well

Re: r316958: booting a server takes >10 minutes!

On 04/15/17 12:41, Poul-Henning Kamp wrote: > > In message <20170415160916.gy1...@albert.catwhisker.org>, David Wolfskill > write > s: > >> And I understand that the Cloudflare/f-root server issue isn't quite >> that recent: "The new f-root servers appeared around two weeks ago" >

Re: r316958: booting a server takes >10 minutes!

In message <20170415160916.gy1...@albert.catwhisker.org>, David Wolfskill write s: >And I understand that the Cloudflare/f-root server issue isn't quite >that recent: "The new f-root servers appeared around two weeks ago" And isn't the zone cache expiry time around two weeks as well

Re: r316958: booting a server takes >10 minutes!

On 2017-04-15 07:53, O. Hartmann wrote: > Recent CURRENT running on a server makes the system booting in multiuser mode > booting > incredibly slow! On a machine, before I interrupted the booting process > hanging in > starting postgresql 9.6.2 server, it took > 10 minutes. > > Due to a serious

Re: r316958: booting a server takes >10 minutes!

On Sat, Apr 15, 2017 at 04:00:25PM +, Poul-Henning Kamp wrote: > > > >Recent CURRENT running on a server makes the system booting in multiuser > >mode booting > >incredibly slow! On a machine, before I interrupted the booting process > >hanging in > >starting postgresql 9.6.2

Re: r316958: booting a server takes >10 minutes!

>Recent CURRENT running on a server makes the system booting in multiuser mode >booting >incredibly slow! On a machine, before I interrupted the booting process >hanging in >starting postgresql 9.6.2 server, it took > 10 minutes. Maybe this ticket ?

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

Sorry Matthew, forgot to reply to this one. On Wed, Apr 05, 2017 at 07:01:35PM +0200, Matthew Rezny wrote: > On Wednesday 05 April 2017 16:15:41 Alexey Dokuchaev wrote: > > ... > > Hmm, I don't quite get it: shouldn't static linking actually increase > > the binaries (and thus the package) size?

Re: r316958: booting a server takes >10 minutes!

15.04.2017 14:53, O. Hartmann пишет: Recent CURRENT running on a server makes the system booting in multiuser mode booting incredibly slow! On a machine, before I interrupted the booting process hanging in starting postgresql 9.6.2 server, it took > 10 minutes. Same here. BTW, the command

Re: r316958: booting a server takes >10 minutes!

Am Sat, 15 Apr 2017 07:02:16 -0500 Larry Rosenman schrieb: > On 4/15/17, 6:53 AM, "O. Hartmann" behalf of > ohartm...@walstatt.org> wrote: > > Recent CURRENT running on a server makes the system booting in multiuser > mode > booting

Re: r316958: booting a server takes >10 minutes!

On 4/15/17, 6:53 AM, "O. Hartmann" wrote: Recent CURRENT running on a server makes the system booting in multiuser mode booting incredibly slow! On a machine, before I interrupted the booting process hanging in

r316958: booting a server takes >10 minutes!

Recent CURRENT running on a server makes the system booting in multiuser mode booting incredibly slow! On a machine, before I interrupted the booting process hanging in starting postgresql 9.6.2 server, it took > 10 minutes. Due to a serious bug in CURRENT, I had to disable BPF_JITTER via

Re: CURRENT (r316844): Fatal trap 12: page fault while in kernel mode (syslogd)

Am Fri, 14 Apr 2017 20:18:57 +0300 Konstantin Belousov schrieb: > On Fri, Apr 14, 2017 at 06:58:27PM +0200, O. Hartmann wrote: > > Fatal trap 12: page fault while in kernel mode > > cpuid = 2; apic id = 02 > > fault virtual address = 0xf8001282fb00 > > fault code

Re: CURRENT (r316844): Fatal trap 12: page fault while in kernel mode (syslogd)

Am Sat, 15 Apr 2017 12:33:34 +0300 Konstantin Belousov schrieb: > On Sat, Apr 15, 2017 at 11:18:41AM +0200, O. Hartmann wrote: > > Am Fri, 14 Apr 2017 20:18:57 +0300 > > Konstantin Belousov schrieb: > > > > > On Fri, Apr 14, 2017 at 06:58:27PM +0200,

Re: CURRENT (r316844): Fatal trap 12: page fault while in kernel mode (syslogd)

On Sat, Apr 15, 2017 at 11:18:41AM +0200, O. Hartmann wrote: > Am Fri, 14 Apr 2017 20:18:57 +0300 > Konstantin Belousov schrieb: > > > On Fri, Apr 14, 2017 at 06:58:27PM +0200, O. Hartmann wrote: > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 2; apic id =

Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

On Fri, Apr 14, 2017 at 08:27:29PM -0700, Mark Millard wrote: > I've seen material quoted from a exp-run that reported > that about 54(?) ports were then blocked by lang/gcc6-aux > not building. Although the first is an older run (the last complete run IIUC), there were 50 and 51 respectively as