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

[O. Hartmann]

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 2017
> >> New Revision: 316977
> >> URL: https://svnweb.freebsd.org/changeset/base/316977  
> >
> > There is a lot of development going on theses days for syscons. What's 
> > about vt()?
> > vt() is considered broken for x11/nvidia-driver and vt() is considered a 
> > requirement
> > when UEFI is boot scheme, isn't it?
> >
> > I'm just curious.  
> 
> Hi O.,
> 
> Bruce uses syscons and cares enough to improve it.  He likely does not
> care about UEFI and definitely does not care about vt.  I don't think
> there's anything wrong with that.  We can't force volunteers to work
> on things they are not interested in.
> 
> Best,
> Conrad

Hello Conrad, happy easter.

There is and was never intention to apply "force", it is a question as I'm 
curious about
what's going on with vt() - no personally bound to B. Evans or anybody else - I 
just took
the chance to comment/ask on that subject when I saw postings.

Maybe not the right place to spread some thinkings.

Regards,

Oliver Hartmann

-- 
O. Hartmann

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


pgp6JmhcQ2VBg.pgp
Description: OpenPGP digital signature

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

[Conrad Meyer]

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
>
> There is a lot of development going on theses days for syscons. What's about 
> vt()? vt() is
> considered broken for x11/nvidia-driver and vt() is considered a requirement 
> when UEFI is
> boot scheme, isn't it?
>
> I'm just curious.

Hi O.,

Bruce uses syscons and cares enough to improve it.  He likely does not
care about UEFI and definitely does not care about vt.  I don't think
there's anything wrong with that.  We can't force volunteers to work
on things they are not interested in.

Best,
Conrad
___
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: r316958: booting a server takes >10 minutes!

[David Wolfskill]

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 08:13:46 PDT 2017 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

on my laptop, then cherry-picked r316973 and re-buit; no issue with
processes spinning in CPU.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Who would have thought that a "hotelier" would be so ... unwelcoming?  Sad.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

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

[O. Hartmann]

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)
>   modes if the font size is >= 14.
>   
>   This is the X cursor XC_left_ptr (#68) (glyph #45 in an X cursor font).
>   Also found in vt.  The old 9x13 cursor is the 10x16 one trimmed not very
>   well.
>   
>   8x8 fonts need a smaller cursor instead of a larger one, except when
>   the pixel size is small.  Text mode is still limited to width and height
>   1 more than the font (so the 9x13 is already 4 pixels too high for it).
> 
> Modified:
>   head/sys/dev/syscons/scvgarndr.c
> 
> Modified: head/sys/dev/syscons/scvgarndr.c
> ==
> --- head/sys/dev/syscons/scvgarndr.c  Sat Apr 15 19:47:50 2017
> (r316976)
> +++ head/sys/dev/syscons/scvgarndr.c  Sat Apr 15 20:03:50 2017
> (r316977)
> @@ -173,6 +173,14 @@ static const struct mousedata mouse9x13 
>   0x0c00, 0x0c00, 0x0600, 0x0600, 0x, 0x, 0x, 0x, },
>   9, 13,
>  };
> +
> +static const struct mousedata mouse10x16 = { {
> + 0xc000, 0xa000, 0x9000, 0x8800, 0x8400, 0x8200, 0x8100, 0x8080,
> + 0x8040, 0x83c0, 0x9200, 0xa900, 0xc900, 0x0480, 0x0480, 0x0300, }, {
> + 0x, 0x4000, 0x6000, 0x7000, 0x7800, 0x7c00, 0x7e00, 0x7f00,
> + 0x7f80, 0x7c00, 0x6c00, 0x4600, 0x0600, 0x0300, 0x0300, 0x, },
> + 10, 16,
> +};
>  #endif
>  #endif
>  
> @@ -1042,7 +1050,7 @@ draw_pxlmouse_planar(scr_stat *scp, int 
>   int i, j, k;
>   uint8_t m1;
>  
> - mdp = 
> + mdp = (scp->font_size < 14) ?  : 
>   line_width = scp->sc->adp->va_line_width;
>   xoff = (x - scp->xoff*8)%8;
>   yoff = y - rounddown(y, line_width);
> @@ -1087,7 +1095,7 @@ remove_pxlmouse_planar(scr_stat *scp, in
>   vm_offset_t p;
>   int bx, by, i, line_width, xend, xoff, yend, yoff;
>  
> - mdp = 
> + mdp = (scp->font_size < 14) ?  : 
>  
>   /*
>* It is only necessary to remove the mouse image where it overlaps
> @@ -1132,7 +1140,7 @@ vga_pxlmouse_direct(scr_stat *scp, int x
>   uint8_t  *u8;
>   int bpp;
>  
> - mdp = 
> + mdp = (scp->font_size < 14) ?  : 
>  
>   /*
>* Determine overlap with the border and then if removing, do nothing


There is a lot of development going on theses days for syscons. What's about 
vt()? vt() is
considered broken for x11/nvidia-driver and vt() is considered a requirement 
when UEFI is
boot scheme, isn't it?

I'm just curious.

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).


pgpCqNjvGWnci.pgp
Description: OpenPGP digital signature

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

[Larry Rosenman]

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: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 316973
Node Kind: directory
Schedule: normal
Last Changed Author: sobomax
Last Changed Rev: 316973
Last Changed Date: 2017-04-15 13:20:11 -0500 (Sat, 15 Apr 2017)

FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #22 r316973: Sat Apr 
15 14:06:54 CDT 2017 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  
amd64 1200028 1200028
borg.lerctr.org /usr/src $
[borg][

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
 
 

On 4/15/17, 2:13 PM, "Kurt Jaeger"  wrote:

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 shutdown/reboot properly, with some 200+ unclean
blocks, trying to get them on disk in an seemingly endless loop.
I had to hard-reset the box.

But: It's older, r315141.

-- 
p...@opsec.eu+49 171 3101372 3 years to 
go !



___
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: r316958: booting a server takes >10 minutes!

[Kurt Jaeger]

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 shutdown/reboot properly, with some 200+ unclean
blocks, trying to get them on disk in an seemingly endless loop.
I had to hard-reset the box.

But: It's older, r315141.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
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: r316958: booting a server takes >10 minutes!

[O. Hartmann]

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 
> > 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 sysctl
> > net.bpf_jitter.enable=0
> > 
> > The box also is a syslog "receiving" server for other hosts, syslogd's 
> > option "-s"
> > isn't used (just for the record).
> > 
> > I'm back to r316717 now which boots the box fine.
> > 
> > Booting in single-user mode is also quick as expected.
> > 
> > oh
> >   
> 
> Is it stalled in a specific place?
> 

No. It seems erratic and involves diffrent services which are about to be 
started. slapd,
mountd for instance take longer as expected, postgresql takes a very long time, 
usually I
have to terminate starting via Ctrl-C. But longest seems to be postgresql. 
Ctrl-C kills
starting, but then, something spins forever and Ctrl-T says, that "sh" does 
something -
not sure what or I didn't remember. I switched back to a working revision.

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).


pgpqUs9tQJKkv.pgp
Description: OpenPGP digital signature

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

[Larry Rosenman]

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
> >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 ?
> 

Regardless, I observe that my laptop was (somewhat) affected by this,
but my build machine did not appear to be affected.

The build machine has very few ports install, runs a GENERIC kernel,
and normally runs headless, while the laptop normally runs xdm and
has my (somewhat old-fashioned) set of ports for a user-facing
machine.  But among the ports on which X11 depends is dbus, and
dbus-daemon was one of the processes that was apparently spinning
in CPU without evidence of accomplishing much of anything, so the
X11 environment wasn't usable.  (I was able to login to and use a
vty on the laptop, though.)

Peace,
david


As was my HOME server which does NOT do ANY DNS services (It’s a DNS Client, 
DHCP Client). 

It was with PostgreSQL starting and I also noted Exim, SSHD, and others 
spinning.  Lots of NO BUFFERSPACE in a truss. 

I suspect it’s related to UDP changes in the system. 
 


___
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: r316958: booting a server takes >10 minutes!

[David Wolfskill]

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 ?
> 

Regardless, I observe that my laptop was (somewhat) affected by this,
but my build machine did not appear to be affected.

The build machine has very few ports install, runs a GENERIC kernel,
and normally runs headless, while the laptop normally runs xdm and
has my (somewhat old-fashioned) set of ports for a user-facing
machine.  But among the ports on which X11 depends is dbus, and
dbus-daemon was one of the processes that was apparently spinning
in CPU without evidence of accomplishing much of anything, so the
X11 environment wasn't usable.  (I was able to login to and use a
vty on the laptop, though.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Who would have thought that a "hotelier" would be so ... unwelcoming?  Sad.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

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

[Michael Butler]

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"
> 
> And isn't the zone cache expiry time around two weeks as well ?

Sure, but none of my name-servers were doing root zone-transfers and,
when I restarted this morning, only a few of my jails would come up.
Reverting to a kernel previous to SVN r316874 restored normal start-up,

imb

___
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: r316958: booting a server takes >10 minutes!

[Poul-Henning Kamp]

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 ?


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: r316958: booting a server takes >10 minutes!

[Allan Jude]

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 bug in CURRENT, I had to disable BPF_JITTER via sysctl
> net.bpf_jitter.enable=0
> 
> The box also is a syslog "receiving" server for other hosts, syslogd's option 
> "-s" isn't
> used (just for the record).
> 
> I'm back to r316717 now which boots the box fine.
> 
> Booting in single-user mode is also quick as expected.
> 
> oh
> 

Is it stalled in a specific place?

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

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

[David Wolfskill]

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 server, it took > 10 minutes.
> 
> Maybe this ticket ?
> 
>   https://lists.freebsd.org/pipermail/freebsd-ports/2017-April/108144.html
> ...

I doubt it:  While I encountered the observed symptom, that was not
until today's build of head (r316956, in my case); yesterday's (r316823)
was fine.

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"

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Who would have thought that a "hotelier" would be so ... unwelcoming?  Sad.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

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

[Poul-Henning Kamp]

>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 ?

https://lists.freebsd.org/pipermail/freebsd-ports/2017-April/108144.html


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Alexey Dokuchaev]

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?
> 
> I might have reversed static and shared somewhere in the linking
> explanation, or not properly described the situation. [...]

Understood, makes sense now.

> There was a brief period in which llvm39 was fully switched to dynamic
> linking, which made it considerably smaller but caused runtime problems
> (and was also likely to be slower).

That still sounds like the most sane way to go; provided those problems
are/would be fixed, I hope for that switch to happen again one day.  (I
somewhat doubt that "slower" was noticeable enough to worry about.)

> The best solution to cut rebuild time for LLVM is ccache.

Indeed, ccache helps greatly.  Now that I've managed to cut down package
times as well, situation with LLVM ports no longer looks as bad as I
originally saw it; thank you.

./danfe
___
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: r316958: booting a server takes >10 minutes!

[Boris Samorodov]

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 "service -e" runs forever and eats CPU.

I had to kill sendmail and dbus (which were chewing CPU) and then
"service -e" run fine.

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
"It is not necessary to change. Survival is not mandatory."
___
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: r316958: booting a server takes >10 minutes!

[O. Hartmann]

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 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 sysctl
> net.bpf_jitter.enable=0
> 
> The box also is a syslog "receiving" server for other hosts, syslogd's 
> option "-s"
> isn't used (just for the record).
> 
> I'm back to r316717 now which boots the box fine.
> 
> Booting in single-user mode is also quick as expected.
> 
> 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).
> 
> 
> I’m seeing similar, and HAVE the syslogd patch applied.   
> 
> My system seems to hang with PostgreSQL taking a LONG time to come up, I also 
> saw
> sshd/exim and other processes spinning on a “No Bufferspace availabile” (from 
> a truss,
> no I don’t have the output). 
> 
> Something™ is seriously not right here.
> 

I follow the svc-src-head@ list on the topic:

svn commit: r316874 - head/sys/kern

which might be the reason for this issue ...

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).


pgp4Wj7IBRXkb.pgp
Description: OpenPGP digital signature

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

[Larry Rosenman]

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
starting postgresql 9.6.2 server, it took > 10 minutes.

Due to a serious bug in CURRENT, I had to disable BPF_JITTER via sysctl
net.bpf_jitter.enable=0

The box also is a syslog "receiving" server for other hosts, syslogd's 
option "-s" isn't
used (just for the record).

I'm back to r316717 now which boots the box fine.

Booting in single-user mode is also quick as expected.

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).


I’m seeing similar, and HAVE the syslogd patch applied.   

My system seems to hang with PostgreSQL taking a LONG time to come up, I also 
saw sshd/exim and other processes spinning on a “No Bufferspace availabile” 
(from a truss, no I don’t have the output). 

Something™ is seriously not right here.





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

r316958: booting a server takes >10 minutes!

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

Due to a serious bug in CURRENT, I had to disable BPF_JITTER via sysctl
net.bpf_jitter.enable=0

The box also is a syslog "receiving" server for other hosts, syslogd's option 
"-s" isn't
used (just for the record).

I'm back to r316717 now which boots the box fine.

Booting in single-user mode is also quick as expected.

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).


pgpeZiJGlAIui.pgp
Description: OpenPGP digital signature

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

[O. Hartmann]

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  = supervisor read instruction, protection violation 
> >  
> 
> > ??() at 0xf8001282fb00
> > bpf_mtap() at bpf_mtap+0x1ab/frame 0xfe012d2aefb0
> > iflib_txq_drain() at iflib_txq_drain+0x1383/frame 0xfe012d2af130
> > drain_ring_lockless() at drain_ring_lockless+0xc0/frame 0xfe012d2af190
> > ifmp_ring_enqueue() at ifmp_ring_enqueue+0x32e/frame 0xfe012d2af200
> > iflib_if_transmit() at iflib_if_transmit+0xb0/frame 0xfe012d2af240
> > ether_output() at ether_output+0x730/frame 0xfe012d2af2e0
> > arprequest() at arprequest+0x426/frame 0xfe012d2af3e0
> > arpresolve_full() at arpresolve_full+0x3d1/frame 0xfe012d2af460
> > arpresolve() at arpresolve+0x10c/frame 0xfe012d2af4d0
> > ether_output() at ether_output+0x4e1/frame 0xfe012d2af570
> > ip_output() at ip_output+0x14e6/frame 0xfe012d2af6b0
> > udp_send() at udp_send+0xab1/frame 0xfe012d2af780
> > sosend_dgram() at sosend_dgram+0x3e4/frame 0xfe012d2af7f0
> > kern_sendit() at kern_sendit+0x229/frame 0xfe012d2af890
> > sendit() at sendit+0x1a7/frame 0xfe012d2af8e0
> > sys_sendto() at sys_sendto+0x4d/frame 0xfe012d2af930
> > amd64_syscall() at amd64_syscall+0x4c2/frame 0xfe012d2afab0
> > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe012d2afab0
> > syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x800b8a5fa, rsp = 
> > 0x7fffd6b8,
> > rbp = 0x7fffdcc0 ---  
> 
> You probably have BPF_JITTER option in your kernel config.  Either set
> net.bpf_jitter.enable to 0 for now, or remove the option.
> 
> It is due to r316767. The issue is known and a solution is being discussed.

simply setting "net.bpf_jitter.enable=0" in /boot/loader.conf.local doesn't 
help, the
Trap 12 still occurs.

-- 
O. Hartmann

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


pgppTdkCwNgsL.pgp
Description: OpenPGP digital signature

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

[O. Hartmann]

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, O. Hartmann wrote:  
> > > > Fatal trap 12: page fault while in kernel mode
> > > > cpuid = 2; apic id = 02
> > > > fault virtual address   = 0xf8001282fb00
> > > > fault code  = supervisor read instruction, protection 
> > > > violation
> > >   
> > > > ??() at 0xf8001282fb00
> > > > bpf_mtap() at bpf_mtap+0x1ab/frame 0xfe012d2aefb0
> > > > iflib_txq_drain() at iflib_txq_drain+0x1383/frame 0xfe012d2af130
> > > > drain_ring_lockless() at drain_ring_lockless+0xc0/frame 
> > > > 0xfe012d2af190
> > > > ifmp_ring_enqueue() at ifmp_ring_enqueue+0x32e/frame 0xfe012d2af200
> > > > iflib_if_transmit() at iflib_if_transmit+0xb0/frame 0xfe012d2af240
> > > > ether_output() at ether_output+0x730/frame 0xfe012d2af2e0
> > > > arprequest() at arprequest+0x426/frame 0xfe012d2af3e0
> > > > arpresolve_full() at arpresolve_full+0x3d1/frame 0xfe012d2af460
> > > > arpresolve() at arpresolve+0x10c/frame 0xfe012d2af4d0
> > > > ether_output() at ether_output+0x4e1/frame 0xfe012d2af570
> > > > ip_output() at ip_output+0x14e6/frame 0xfe012d2af6b0
> > > > udp_send() at udp_send+0xab1/frame 0xfe012d2af780
> > > > sosend_dgram() at sosend_dgram+0x3e4/frame 0xfe012d2af7f0
> > > > kern_sendit() at kern_sendit+0x229/frame 0xfe012d2af890
> > > > sendit() at sendit+0x1a7/frame 0xfe012d2af8e0
> > > > sys_sendto() at sys_sendto+0x4d/frame 0xfe012d2af930
> > > > amd64_syscall() at amd64_syscall+0x4c2/frame 0xfe012d2afab0
> > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe012d2afab0
> > > > syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x800b8a5fa, rsp = 
> > > > 0x7fffd6b8,
> > > > rbp = 0x7fffdcc0 ---
> > > 
> > > You probably have BPF_JITTER option in your kernel config.  Either set
> > > net.bpf_jitter.enable to 0 for now, or remove the option.
> > > 
> > > It is due to r316767. The issue is known and a solution is being 
> > > discussed.  
> > 
> > simply setting "net.bpf_jitter.enable=0" in /boot/loader.conf.local doesn't 
> > help, the
> > Trap 12 still occurs.  
> 
> It is sysctl, not tunable.

Correct, I didn't/couldn't think that far. Having a setting in /etc/sysctl.conf
accordingly, booting the kernel doesn't reveal the Trap 12 anymore.

Thanks.
Oliver


-- 
O. Hartmann

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


pgp7Iu4sv0Ahq.pgp
Description: OpenPGP digital signature

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

[Konstantin Belousov]

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 = 02
> > > fault virtual address   = 0xf8001282fb00
> > > fault code  = supervisor read instruction, protection 
> > > violation  
> > 
> > > ??() at 0xf8001282fb00
> > > bpf_mtap() at bpf_mtap+0x1ab/frame 0xfe012d2aefb0
> > > iflib_txq_drain() at iflib_txq_drain+0x1383/frame 0xfe012d2af130
> > > drain_ring_lockless() at drain_ring_lockless+0xc0/frame 0xfe012d2af190
> > > ifmp_ring_enqueue() at ifmp_ring_enqueue+0x32e/frame 0xfe012d2af200
> > > iflib_if_transmit() at iflib_if_transmit+0xb0/frame 0xfe012d2af240
> > > ether_output() at ether_output+0x730/frame 0xfe012d2af2e0
> > > arprequest() at arprequest+0x426/frame 0xfe012d2af3e0
> > > arpresolve_full() at arpresolve_full+0x3d1/frame 0xfe012d2af460
> > > arpresolve() at arpresolve+0x10c/frame 0xfe012d2af4d0
> > > ether_output() at ether_output+0x4e1/frame 0xfe012d2af570
> > > ip_output() at ip_output+0x14e6/frame 0xfe012d2af6b0
> > > udp_send() at udp_send+0xab1/frame 0xfe012d2af780
> > > sosend_dgram() at sosend_dgram+0x3e4/frame 0xfe012d2af7f0
> > > kern_sendit() at kern_sendit+0x229/frame 0xfe012d2af890
> > > sendit() at sendit+0x1a7/frame 0xfe012d2af8e0
> > > sys_sendto() at sys_sendto+0x4d/frame 0xfe012d2af930
> > > amd64_syscall() at amd64_syscall+0x4c2/frame 0xfe012d2afab0
> > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe012d2afab0
> > > syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x800b8a5fa, rsp = 
> > > 0x7fffd6b8,
> > > rbp = 0x7fffdcc0 ---  
> > 
> > You probably have BPF_JITTER option in your kernel config.  Either set
> > net.bpf_jitter.enable to 0 for now, or remove the option.
> > 
> > It is due to r316767. The issue is known and a solution is being discussed.
> 
> simply setting "net.bpf_jitter.enable=0" in /boot/loader.conf.local doesn't 
> help, the
> Trap 12 still occurs.

It is sysctl, not tunable.
___
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: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

[Mark Linimon]

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 of:

http://thunderx1.nyi.freebsd.org/build.html?mastername=110arm64-default=423029
http://beefy8.nyi.freebsd.org/build.html?mastername=head-armv6-default=p437390_s316341

I think you're fairly deep into unexplored territory here.

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