Re: rpi2 hangup during poudriere build: lots of pfault wmseg status

[Mark Millard]

> On 2017-Dec-6, at 5:47 PM, Laurent Cimon  wrote:
> 
>> On Dec 6, 2017, at 20:01, Mark Millard  wrote:
>> 
>> On 2017-Dec-6, at 1:54 PM, Laurent Cimon  wrote:
>> 
 On Dec 6, 2017, at 00:57, Mark Millard  wrote:
 
 I tried to build some ports on a rpi2
 (via poudriere) but it hung up:
 Ethernet and normal console use. (Note:
 the root file system is on a USB SSD
 and the swap partition is also on that
 USB SSD.)
 
 But ~^b worked for getting to the db>
 prompt on the console.
 
 From there a ps suggests that it got hung
 up in pfault activity. (Possibly insufficient
 RAM+swap-partition space?) But it is not
 clear to me that it should end up hung up
 vs. killing processes or other such.
>>> 
>>> Hi,
>>> 
>>> From what I know the raspberry pis use the same controller for ethernet and
>>> the USB hub on which you’re hosting an SSD. It seems like you make very 
>>> heavy
>>> use of the USB ports, and all of the resources used by poudriere except for 
>>> the
>>> CPU and the (very limited) memory that’s not in swap is attached to them. 
>>> If you
>>> really didn’t have enough memory and swap, the linkers would’ve been 
>>> stopped.
>>> 
>>> I think it might just be a swap death. Poudriere compiles and fetches in 
>>> parallel
>>> a lot, ethernet and disk I/O is slow because it’s very limited, so linking 
>>> takes
>>> longer. You end up linking a few very big binaries at the same time, and 
>>> they
>>> all fight for the memory, to get out of swap through page faults, but there
>>> are too many page faults, all too big, requesting for more CPU time that’s
>>> allowed to them.
>>> 
>>> This would explain why you have 3 linkers waiting on a page fault out of 
>>> the 4
>>> CPUs poudriere allows builds on, on top of the awk processes. It would also
>>> explain why you had easy access to the debugger: it was in memory already 
>>> with
>>> the kernel.
>>> 
>>> I’d advise you to disable parallel builds and see if it happens again,
>>> but it would make building much slower. Using makejobs would help if you
>>> can afford watching the build. Otherwise be patient, it should resolve 
>>> itself
>>> eventually, but it will take a while and it will happen again.
>> 
>> My post was more about how FreeBSD handled the
>> heavy-use context and less about getting the
>> builds to finish: it managed to to get to a
>> state of no-progress for processes and a loss
>> of normal control as far as I could tell.
>> 
>> I did a "c" to ddb and left it until just before
>> this note then did ~ ^B again. Things looked the
>> same. [I've finally rebooted the rpi2.]
>> 
>> PARALLEL_JOBS=1 was already in use but
>> ALLOW_MAKE_JOBS=yes was also in use.
>> USE_TMPFS=no was already in use.
>> 
>> While an ssh session was monitoring the
>> build, Ethernet was not in heavy use.
>> (No nfs mounts to its disks, for example.)
>> 
>> I may try without ALLOW_MAKE_JOBS=yes and
>> with ALLOW_MAKE_JOBS_PACKAGES empty/undefined
>> to see if it can complete for such a context
>> without having the same sort of problem.
>> 
>> Ultimately I can cross-build and install from
>> those materials when I really want updates. I
>> have the context for such. This was more about
>> seeing how well the rpi2 did for self-hosted.
>> Classically I've used a BPI-M3 with 2 GiBytes
>> of RAM and a proportionally bigger swap partition
>> instead (approximately).
>> 
>> 
>> FYI (rpi2 after rebooting):
>> 
>> # swapinfo
>> Device  1K-blocks UsedAvail Capacity
>> /dev/label/RPI2swap   15728600  1572860 0%
>> 
>> # df -m
>> Filesystem   1M-blocks  Used  Avail Capacity  Mounted on
>> /dev/ufs/RPI2rootfs 195378 30791 14895717%/
>> devfs0 0  0   100%/dev
>> /dev/label/RPI2Aboot4912 3725%/boot/msdos
>> 
>> 
>> An rpi3 (aarch64) with the same amount of RAM,
>> same type of USB SSD, etc., but well more swap
>> completed building basically the same set of
>> ports for the same poudriere settings just
>> fine.
>> 
>> Interestingly for the default kern.maxswzone:
>> (Just to show the reported recommended maximum
>> figures for swap.)
>> 
>> rpi2: . . . exceeds maximum recommended amount (411488 pages).
>> rpi3: . . . exceeds maximum recommended amount (925680 pages).
>> 
>> (I was running with somewhat under those maximums for
>> the tests.)
>> 
>> # swapinfo
>> Device  1K-blocks UsedAvail Capacity
>> /dev/gpt/RPI3swap   37027840  3702784 0%
>> 
>> # df -m
>> Filesystem   1M-blocks  Used  Avail Capacity  Mounted on
>> /dev/ufs/RPI3rootfs 195378 14937 164811 8%/
>> devfs0 0  0   100%/dev
>> /dev/label/RPI3Aboot49 7 4215%/boot/efi
>> 
>> If I restricted the rpi3 to somewhat under what the
>> rpi2 allows for swap, I do not know if it would also
>> hang up vs. not.
>> 
>> If having more swap makes the 

Re: GPTZFSBOOT in Current r326622 has problems

[Thomas Laus]

> Warner Losh [i...@bsdimp.com] wrote:
> > > > You can just build the boot blocks at each step if you'd like to save
> > > > some time on the binary search.
> > > >
> > > > cd stand
> > > > make cleandir obj depend
> > > > make -j XX
> > > > sudo -E make install
> > > >
> > 
> > OK. Still a fair number of changes, including changes to geli to fix
> > warnings...
> > 
> > 326585-326594 is a flurry of changes. Then another in the 326609-326610
> > range. There's one other trivial one. I'd wager that if '500 works, the
> > breakage will be somewhere in the first range, which suggests 326590 might
> > be a good, next pivot. There's also a few just after '500 that might break
> > things as well if I messed something up. '504 and '507 both touch this
> > stuff directly...
> >
> Warren:
> 
> Building just 'stand' had an error in /usr/src/stand/geli concerning
> geli hmac conflicting type for 'ngets'.
> 
> I am doing a full buildworld for r326590.  It should be complete
> before 9:30 PM EST.  I'll post the results and look for replies tomorrow
> morning and proceed with the disscetion.
>
Warren:

The r326590 buildworld failed due to a problem in the 'geli' code.
The specific error:

/usr/src/sys/geom/eli/g-eli_hmac.c line 46.  It complained about a
missing type specifier.

I'll try this again tomorrow morning from an xterm so I can capture
and post the exact message.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
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: rpi2 hangup during poudriere build: lots of pfault wmseg status

[Laurent Cimon]

> On Dec 6, 2017, at 20:01, Mark Millard  wrote:
> 
> On 2017-Dec-6, at 1:54 PM, Laurent Cimon  wrote:
> 
>>> On Dec 6, 2017, at 00:57, Mark Millard  wrote:
>>> 
>>> I tried to build some ports on a rpi2
>>> (via poudriere) but it hung up:
>>> Ethernet and normal console use. (Note:
>>> the root file system is on a USB SSD
>>> and the swap partition is also on that
>>> USB SSD.)
>>> 
>>> But ~^b worked for getting to the db>
>>> prompt on the console.
>>> 
>>> From there a ps suggests that it got hung
>>> up in pfault activity. (Possibly insufficient
>>> RAM+swap-partition space?) But it is not
>>> clear to me that it should end up hung up
>>> vs. killing processes or other such.
>> 
>> Hi,
>> 
>> From what I know the raspberry pis use the same controller for ethernet and
>> the USB hub on which you’re hosting an SSD. It seems like you make very heavy
>> use of the USB ports, and all of the resources used by poudriere except for 
>> the
>> CPU and the (very limited) memory that’s not in swap is attached to them. If 
>> you
>> really didn’t have enough memory and swap, the linkers would’ve been stopped.
>> 
>> I think it might just be a swap death. Poudriere compiles and fetches in 
>> parallel
>> a lot, ethernet and disk I/O is slow because it’s very limited, so linking 
>> takes
>> longer. You end up linking a few very big binaries at the same time, and they
>> all fight for the memory, to get out of swap through page faults, but there
>> are too many page faults, all too big, requesting for more CPU time that’s
>> allowed to them.
>> 
>> This would explain why you have 3 linkers waiting on a page fault out of the 
>> 4
>> CPUs poudriere allows builds on, on top of the awk processes. It would also
>> explain why you had easy access to the debugger: it was in memory already 
>> with
>> the kernel.
>> 
>> I’d advise you to disable parallel builds and see if it happens again,
>> but it would make building much slower. Using makejobs would help if you
>> can afford watching the build. Otherwise be patient, it should resolve itself
>> eventually, but it will take a while and it will happen again.
> 
> My post was more about how FreeBSD handled the
> heavy-use context and less about getting the
> builds to finish: it managed to to get to a
> state of no-progress for processes and a loss
> of normal control as far as I could tell.
> 
> I did a "c" to ddb and left it until just before
> this note then did ~ ^B again. Things looked the
> same. [I've finally rebooted the rpi2.]
> 
> PARALLEL_JOBS=1 was already in use but
> ALLOW_MAKE_JOBS=yes was also in use.
> USE_TMPFS=no was already in use.
> 
> While an ssh session was monitoring the
> build, Ethernet was not in heavy use.
> (No nfs mounts to its disks, for example.)
> 
> I may try without ALLOW_MAKE_JOBS=yes and
> with ALLOW_MAKE_JOBS_PACKAGES empty/undefined
> to see if it can complete for such a context
> without having the same sort of problem.
> 
> Ultimately I can cross-build and install from
> those materials when I really want updates. I
> have the context for such. This was more about
> seeing how well the rpi2 did for self-hosted.
> Classically I've used a BPI-M3 with 2 GiBytes
> of RAM and a proportionally bigger swap partition
> instead (approximately).
> 
> 
> FYI (rpi2 after rebooting):
> 
> # swapinfo
> Device  1K-blocks UsedAvail Capacity
> /dev/label/RPI2swap   15728600  1572860 0%
> 
> # df -m
> Filesystem   1M-blocks  Used  Avail Capacity  Mounted on
> /dev/ufs/RPI2rootfs 195378 30791 14895717%/
> devfs0 0  0   100%/dev
> /dev/label/RPI2Aboot4912 3725%/boot/msdos
> 
> 
> An rpi3 (aarch64) with the same amount of RAM,
> same type of USB SSD, etc., but well more swap
> completed building basically the same set of
> ports for the same poudriere settings just
> fine.
> 
> Interestingly for the default kern.maxswzone:
> (Just to show the reported recommended maximum
> figures for swap.)
> 
> rpi2: . . . exceeds maximum recommended amount (411488 pages).
> rpi3: . . . exceeds maximum recommended amount (925680 pages).
> 
> (I was running with somewhat under those maximums for
> the tests.)
> 
> # swapinfo
> Device  1K-blocks UsedAvail Capacity
> /dev/gpt/RPI3swap   37027840  3702784 0%
> 
> # df -m
> Filesystem   1M-blocks  Used  Avail Capacity  Mounted on
> /dev/ufs/RPI3rootfs 195378 14937 164811 8%/
> devfs0 0  0   100%/dev
> /dev/label/RPI3Aboot49 7 4215%/boot/efi
> 
> If I restricted the rpi3 to somewhat under what the
> rpi2 allows for swap, I do not know if it would also
> hang up vs. not.
> 
> If having more swap makes the difference, then it
> would not seem to be being I/O-bound that would
> explain the hangup.
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net

There are a few factors that could have 

Re: GPTZFSBOOT in Current r326622 has problems

[Thomas Laus]

Warner Losh [i...@bsdimp.com] wrote:
> > > You can just build the boot blocks at each step if you'd like to save
> > > some time on the binary search.
> > >
> > > cd stand
> > > make cleandir obj depend
> > > make -j XX
> > > sudo -E make install
> > >
> 
> OK. Still a fair number of changes, including changes to geli to fix
> warnings...
> 
> 326585-326594 is a flurry of changes. Then another in the 326609-326610
> range. There's one other trivial one. I'd wager that if '500 works, the
> breakage will be somewhere in the first range, which suggests 326590 might
> be a good, next pivot. There's also a few just after '500 that might break
> things as well if I messed something up. '504 and '507 both touch this
> stuff directly...
>
Warren:

Building just 'stand' had an error in /usr/src/stand/geli concerning
geli hmac conflicting type for 'ngets'.

I am doing a full buildworld for r326590.  It should be complete
before 9:30 PM EST.  I'll post the results and look for replies tomorrow
morning and proceed with the disscetion.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
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: rpi2 hangup during poudriere build: lots of pfault wmseg status

[Mark Millard]

On 2017-Dec-6, at 1:54 PM, Laurent Cimon  wrote:

>> On Dec 6, 2017, at 00:57, Mark Millard  wrote:
>> 
>> I tried to build some ports on a rpi2
>> (via poudriere) but it hung up:
>> Ethernet and normal console use. (Note:
>> the root file system is on a USB SSD
>> and the swap partition is also on that
>> USB SSD.)
>> 
>> But ~^b worked for getting to the db>
>> prompt on the console.
>> 
>> From there a ps suggests that it got hung
>> up in pfault activity. (Possibly insufficient
>> RAM+swap-partition space?) But it is not
>> clear to me that it should end up hung up
>> vs. killing processes or other such.
> 
> Hi,
> 
> From what I know the raspberry pis use the same controller for ethernet and
> the USB hub on which you’re hosting an SSD. It seems like you make very heavy
> use of the USB ports, and all of the resources used by poudriere except for 
> the
> CPU and the (very limited) memory that’s not in swap is attached to them. If 
> you
> really didn’t have enough memory and swap, the linkers would’ve been stopped.
> 
> I think it might just be a swap death. Poudriere compiles and fetches in 
> parallel
> a lot, ethernet and disk I/O is slow because it’s very limited, so linking 
> takes
> longer. You end up linking a few very big binaries at the same time, and they
> all fight for the memory, to get out of swap through page faults, but there
> are too many page faults, all too big, requesting for more CPU time that’s
> allowed to them.
> 
> This would explain why you have 3 linkers waiting on a page fault out of the 4
> CPUs poudriere allows builds on, on top of the awk processes. It would also
> explain why you had easy access to the debugger: it was in memory already with
> the kernel.
> 
> I’d advise you to disable parallel builds and see if it happens again,
> but it would make building much slower. Using makejobs would help if you
> can afford watching the build. Otherwise be patient, it should resolve itself
> eventually, but it will take a while and it will happen again.

My post was more about how FreeBSD handled the
heavy-use context and less about getting the
builds to finish: it managed to to get to a
state of no-progress for processes and a loss
of normal control as far as I could tell.

I did a "c" to ddb and left it until just before
this note then did ~ ^B again. Things looked the
same. [I've finally rebooted the rpi2.]

PARALLEL_JOBS=1 was already in use but
ALLOW_MAKE_JOBS=yes was also in use.
USE_TMPFS=no was already in use.

While an ssh session was monitoring the
build, Ethernet was not in heavy use.
(No nfs mounts to its disks, for example.)

I may try without ALLOW_MAKE_JOBS=yes and
with ALLOW_MAKE_JOBS_PACKAGES empty/undefined
to see if it can complete for such a context
without having the same sort of problem.

Ultimately I can cross-build and install from
those materials when I really want updates. I
have the context for such. This was more about
seeing how well the rpi2 did for self-hosted.
Classically I've used a BPI-M3 with 2 GiBytes
of RAM and a proportionally bigger swap partition
instead (approximately).


FYI (rpi2 after rebooting):

# swapinfo
Device  1K-blocks UsedAvail Capacity
/dev/label/RPI2swap   15728600  1572860 0%

# df -m
Filesystem   1M-blocks  Used  Avail Capacity  Mounted on
/dev/ufs/RPI2rootfs 195378 30791 14895717%/
devfs0 0  0   100%/dev
/dev/label/RPI2Aboot4912 3725%/boot/msdos


An rpi3 (aarch64) with the same amount of RAM,
same type of USB SSD, etc., but well more swap
completed building basically the same set of
ports for the same poudriere settings just
fine.

Interestingly for the default kern.maxswzone:
(Just to show the reported recommended maximum
figures for swap.)

rpi2: . . . exceeds maximum recommended amount (411488 pages).
rpi3: . . . exceeds maximum recommended amount (925680 pages).

(I was running with somewhat under those maximums for
the tests.)

# swapinfo
Device  1K-blocks UsedAvail Capacity
/dev/gpt/RPI3swap   37027840  3702784 0%

# df -m
Filesystem   1M-blocks  Used  Avail Capacity  Mounted on
/dev/ufs/RPI3rootfs 195378 14937 164811 8%/
devfs0 0  0   100%/dev
/dev/label/RPI3Aboot49 7 4215%/boot/efi

If I restricted the rpi3 to somewhat under what the
rpi2 allows for swap, I do not know if it would also
hang up vs. not.

If having more swap makes the difference, then it
would not seem to be being I/O-bound that would
explain the hangup.


===
Mark Millard
markmi at dsl-only.net

___
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: GPTZFSBOOT in Current r326622 has problems

[Warner Losh]

On Wed, Dec 6, 2017 at 5:17 PM, Thomas Laus  wrote:

> Warner Losh [i...@bsdimp.com] wrote:
> > You can just build the boot blocks at each step if you'd like to save
> some
> > time on the binary search.
> >
> > cd stand
> > make cleandir obj depend
> > make -j XX
> > sudo -E make install
> >
> Warren:
>
> I built and loaded r326500 successfully.  It looks like the problem is
> after r326500 and before r326662.


OK. Still a fair number of changes, including changes to geli to fix
warnings...

326585-326594 is a flurry of changes. Then another in the 326609-326610
range. There's one other trivial one. I'd wager that if '500 works, the
breakage will be somewhere in the first range, which suggests 326590 might
be a good, next pivot. There's also a few just after '500 that might break
things as well if I messed something up. '504 and '507 both touch this
stuff directly...

Good luck!

Warner
___
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: GPTZFSBOOT in Current r326622 has problems

[Thomas Laus]

Warner Losh [i...@bsdimp.com] wrote:
> You can just build the boot blocks at each step if you'd like to save some
> time on the binary search.
> 
> cd stand
> make cleandir obj depend
> make -j XX
> sudo -E make install
>
Warren:

I built and loaded r326500 successfully.  It looks like the problem is
after r326500 and before r326662.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
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: GPTZFSBOOT in Current r326622 has problems

[Thomas Laus]

Warner Losh [i...@bsdimp.com] wrote:
> 
> You can just build the boot blocks at each step if you'd like to save some
> time on the binary search.
> 
> cd stand
> make cleandir obj depend
> make -j XX
> sudo -E make install
> 
> should suffice. There's no compiler dependency that I'm aware of.
>
I have started another buildworld.  I should probably let it run to
completion and then test whether it boots.  Thanks for the suggestion
on further builds.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
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: Strange behavior about pattern matching on manual pages [FIXED]

[Alan Somers]

On Wed, Dec 6, 2017 at 3:35 PM, Jamie Landeg-Jones 
wrote:

> Alan Somers  wrote:
>
> > How about just setting MANPAGER=less in your environment?
>
> Because some of us prefer "more"?
>
> And as I said, it's related to searching using the more(1) command
> generally.
>
> I was under the impression that fixing bugs in existing commands was a
> better
> solution than telling someone to simply use something else.
>

Yes, it certainly is.  Are you sure this is actually a bug in less, or is
it just weird-but-intended behavior when less is emulating some old version
of more?  It would be worth comparing our less sources to upstream's to see
what differences have crept in, and svn blaming them to see why.

-Alan
___
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: Strange behavior about pattern matching on manual pages [FIXED]

[Jamie Landeg-Jones]

Alan Somers  wrote:

> How about just setting MANPAGER=less in your environment?

Because some of us prefer "more"?

And as I said, it's related to searching using the more(1) command generally.

I was under the impression that fixing bugs in existing commands was a better
solution than telling someone to simply use something else.
___
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: GPTZFSBOOT in Current r326622 has problems

[Warner Losh]

On Wed, Dec 6, 2017 at 3:21 PM, Thomas Laus  wrote:

> Warner Losh [i...@bsdimp.com] wrote:
> > I've been *VERY* busy between then and now cleaning up the boot loader
> > "accumulated technical debt". Alas, sounds like I've broken something.
> So I
> > think it's a binary search: I'd start with 326370 as the pivot and
> 326500 /
> > 326250 as the next steps if it succeeds / fails.
> >
> Warren:
>
> I reverted my system to r326370 and it booted normally.  It looks like
> something broke after that revision.  I'll cue up another buildworld
> after updating the system to r326500.
>
> I received a couple of suggestions to take a picture and post my
> console screen of the BTX fault.  My camera battery has died and is on
> the charger for a while.  I'll build r326500 and post a picture if it
> shows the same BTX issue.


You can just build the boot blocks at each step if you'd like to save some
time on the binary search.

cd stand
make cleandir obj depend
make -j XX
sudo -E make install

should suffice. There's no compiler dependency that I'm aware of.

Warner
___
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: Strange behavior about pattern matching on manual pages [FIXED]

[Alan Somers]

On Wed, Dec 6, 2017 at 3:04 PM, Jamie Landeg-Jones 
wrote:

> by  wrote:
>
> > Hi,
> >
> > I encounter a problem when viewing manuals via man(1) command.
> >
> > The case is simple, when I try to search something, I press ‘/’, and
> then input the pattern, If it got something in the page, it will direct me
> into the specified place, and then, I continue with ’n’, and it goes well.
> > But the problem is, after a sequence of ’n’, the screen go to the end of
> the manual pages, and keeping press ’n’, I got annoying “...skipping...”,
> the page is full of skipping and parts of the end of the manual page.
>
> Yes. This has been annoying me too - your email prompted me to finally work
> on a fix for it!
>
> Firstly, it isn't man(1) itself - man(1) uses more(1) as the pager.
> more(1) is in itself actually the program less(1), running in "more
> emulation mode".
>
> And less(1) isn't FreeBSD native code - it's imported into the project
> from http://www.greenwoodsoftware.com/less/
>
> I noticed the very latest version of less(1) has been checked into
> freebsd-current, and the issue still occurs there.
>
> Anyway, the fix is two small patches to less(1), please let me know
> if they work for you, and if you see any bad side-effects in man(1) /
> more(1) and less(1) and I'll then try and get them applied upstream.
>
> The patches have been tested against FreeBSD 11.1-STABLE and 12-CURRENT
>
> cheers! Jamie
>
> --- contrib/less/forwback.c.orig2017-11-20 08:52:33.978356000 +
> +++ contrib/less/forwback.c 2017-12-05 15:53:50.51755 +
> @@ -255,7 +255,7 @@
>  * start the display after the beginning of the file,
>  * and it is not appropriate to squish in that case.
>  */
> -   if ((first_time || less_is_more) &&
> +   if ((first_time) &&
> pos == NULL_POSITION && !top_scroll &&
>  #if TAGS
> tagoption == NULL &&
> --- contrib/less/main.c.orig2017-11-20 08:52:33.978356000 +
> +++ contrib/less/main.c 2017-12-05 15:53:57.291394000 +
> @@ -168,7 +168,10 @@
> }
>
> if (less_is_more)
> +   {
> no_init = TRUE;
> +   scan_option("--tilde");
> +   }
>
>  #if EDITOR
> editor = lgetenv("VISUAL");
>
>
How about just setting MANPAGER=less in your environment?
___
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: GPTZFSBOOT in Current r326622 has problems

[Thomas Laus]

Warner Losh [i...@bsdimp.com] wrote:
> I've been *VERY* busy between then and now cleaning up the boot loader
> "accumulated technical debt". Alas, sounds like I've broken something. So I
> think it's a binary search: I'd start with 326370 as the pivot and 326500 /
> 326250 as the next steps if it succeeds / fails.
>
Warren:

I reverted my system to r326370 and it booted normally.  It looks like
something broke after that revision.  I'll cue up another buildworld
after updating the system to r326500.

I received a couple of suggestions to take a picture and post my
console screen of the BTX fault.  My camera battery has died and is on
the charger for a while.  I'll build r326500 and post a picture if it
shows the same BTX issue.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
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: rpi2 hangup during poudriere build: lots of pfault wmseg status

[Laurent Cimon]

> On Dec 6, 2017, at 00:57, Mark Millard  wrote:
> 
> I tried to build some ports on a rpi2
> (via poudriere) but it hung up:
> Ethernet and normal console use. (Note:
> the root file system is on a USB SSD
> and the swap partition is also on that
> USB SSD.)
> 
> But ~^b worked for getting to the db>
> prompt on the console.
> 
> From there a ps suggests that it got hung
> up in pfault activity. (Possibly insufficient
> RAM+swap-partition space?) But it is not
> clear to me that it should end up hung up
> vs. killing processes or other such.

Hi,

From what I know the raspberry pis use the same controller for ethernet and
the USB hub on which you’re hosting an SSD. It seems like you make very heavy
use of the USB ports, and all of the resources used by poudriere except for the
CPU and the (very limited) memory that’s not in swap is attached to them. If you
really didn’t have enough memory and swap, the linkers would’ve been stopped.

I think it might just be a swap death. Poudriere compiles and fetches in 
parallel
a lot, ethernet and disk I/O is slow because it’s very limited, so linking takes
longer. You end up linking a few very big binaries at the same time, and they
all fight for the memory, to get out of swap through page faults, but there
are too many page faults, all too big, requesting for more CPU time that’s
allowed to them.

This would explain why you have 3 linkers waiting on a page fault out of the 4
CPUs poudriere allows builds on, on top of the awk processes. It would also
explain why you had easy access to the debugger: it was in memory already with
the kernel.

I’d advise you to disable parallel builds and see if it happens again,
but it would make building much slower. Using makejobs would help if you
can afford watching the build. Otherwise be patient, it should resolve itself
eventually, but it will take a while and it will happen again.

Good luck,

Laurent
___
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: Strange behavior about pattern matching on manual pages [FIXED]

[Jamie Landeg-Jones]

by  wrote:

> Hi,
>
> I encounter a problem when viewing manuals via man(1) command.
>
> The case is simple, when I try to search something, I press ‘/’, and then 
> input the pattern, If it got something in the page, it will direct me into 
> the specified place, and then, I continue with ’n’, and it goes well.
> But the problem is, after a sequence of ’n’, the screen go to the end of the 
> manual pages, and keeping press ’n’, I got annoying “...skipping...”, the 
> page is full of skipping and parts of the end of the manual page.

Yes. This has been annoying me too - your email prompted me to finally work
on a fix for it!

Firstly, it isn't man(1) itself - man(1) uses more(1) as the pager.
more(1) is in itself actually the program less(1), running in "more
emulation mode".

And less(1) isn't FreeBSD native code - it's imported into the project
from http://www.greenwoodsoftware.com/less/

I noticed the very latest version of less(1) has been checked into
freebsd-current, and the issue still occurs there.

Anyway, the fix is two small patches to less(1), please let me know
if they work for you, and if you see any bad side-effects in man(1) /
more(1) and less(1) and I'll then try and get them applied upstream.

The patches have been tested against FreeBSD 11.1-STABLE and 12-CURRENT

cheers! Jamie

--- contrib/less/forwback.c.orig2017-11-20 08:52:33.978356000 +
+++ contrib/less/forwback.c 2017-12-05 15:53:50.51755 +
@@ -255,7 +255,7 @@
 * start the display after the beginning of the file,
 * and it is not appropriate to squish in that case.
 */
-   if ((first_time || less_is_more) &&
+   if ((first_time) &&
pos == NULL_POSITION && !top_scroll && 
 #if TAGS
tagoption == NULL &&
--- contrib/less/main.c.orig2017-11-20 08:52:33.978356000 +
+++ contrib/less/main.c 2017-12-05 15:53:57.291394000 +
@@ -168,7 +168,10 @@
}
 
if (less_is_more)
+   {
no_init = TRUE;
+   scan_option("--tilde");
+   }
 
 #if EDITOR
editor = lgetenv("VISUAL");
___
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: logger(1) exited on signal 11 after r326525 -> r326622

[David Wolfskill]

On Wed, Dec 06, 2017 at 08:54:52PM +0300, Maxim Konovalov wrote:
> Hi David,
> 
> On Wed, 6 Dec 2017, 05:12-0800, David Wolfskill wrote:
> 
> > I noticed among the messages on the console during the final stages of
> > the transition from single- to multi-user mode:
> >
> [...]
> 
> https://lists.freebsd.org/pipermail/svn-src-all/2017-December/154807.html
> 
> -- 
> Maxim Konovalov

Thanks for the pointer; that resolved the issue for me. :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump is an incompetent, lying bully who is unfit for any public office.

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


signature.asc
Description: PGP signature

Re: GPTZFSBOOT in Current r326622 has problems

[Thomas Laus]

Warner Losh [i...@bsdimp.com] wrote:
> I've been *VERY* busy between then and now cleaning up the boot loader
> "accumulated technical debt". Alas, sounds like I've broken something. So I
> think it's a binary search: I'd start with 326370 as the pivot and 326500 /
> 326250 as the next steps if it succeeds / fails.
> 
> So you are seeing a BTX error? Before we even get to running /boot/loader,
> correct? Any chance you can get me that error?
>
I get a screen full of register and hex numbers followed by BTX
halted.  I can do my best to transcribe all of the numbers, but that
may be very error prone to do by hand.  At this point in the boot
process, it is a little hard to fire up a serial console and capture
the output to a file.  I run Geli encrypted disks and the BTX halt
comes even before the prompt for a password.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
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: GPTZFSBOOT in Current r326622 has problems

[Warner Losh]

On Wed, Dec 6, 2017 at 9:48 AM, Thomas Laus  wrote:

> Warner Losh [i...@bsdimp.com] wrote:
> >
> > Any chance you can bisect when this happened? I think I'll need more
> > details to see what happened. What was your old loader that world based
> on?
> >
> My last good gptzfsboot was r326070.  I had not built anything since
> then until this morning when I built world and kernel at r326622.
> I'll look at the svn history and see where I should start.


I've been *VERY* busy between then and now cleaning up the boot loader
"accumulated technical debt". Alas, sounds like I've broken something. So I
think it's a binary search: I'd start with 326370 as the pivot and 326500 /
326250 as the next steps if it succeeds / fails.

So you are seeing a BTX error? Before we even get to running /boot/loader,
correct? Any chance you can get me that error?

> > I also see the problem with the loader logs dumping core that others
> > > have reported recently.
> > >
> >
> > I've not seen these reports, nor do I see if on my loader testing. More
> > details please? Last I had heard, everything was working...
> >
> That was a typo.  I had loader on my mind and the core dumps are
> dealing with logger.  I have seen recent messages to this group about
> logger dumping core and someone is bisecting the issue.  I was just
> reporting that it was still occurring at r326622.


Good! One less problem for me to track...

Warner
___
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: GPTZFSBOOT in Current r326622 has problems

[Thomas Laus]

Warner Losh [i...@bsdimp.com] wrote:
> 
> Any chance you can bisect when this happened? I think I'll need more
> details to see what happened. What was your old loader that world based on?
> 
My last good gptzfsboot was r326070.  I had not built anything since
then until this morning when I built world and kernel at r326622.
I'll look at the svn history and see where I should start.

> > I also see the problem with the loader logs dumping core that others
> > have reported recently.
> >
> 
> I've not seen these reports, nor do I see if on my loader testing. More
> details please? Last I had heard, everything was working...
>
That was a typo.  I had loader on my mind and the core dumps are
dealing with logger.  I have seen recent messages to this group about
logger dumping core and someone is bisecting the issue.  I was just
reporting that it was still occurring at r326622.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
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: GPTZFSBOOT in Current r326622 has problems

[Warner Losh]

On Wed, Dec 6, 2017 at 8:35 AM, Thomas Laus  wrote:

> Group:
>
> I updated my amd64 computer today to r326622 and copied the
> /boot/gptzfsboot file to each of my ZFS hard drives p1 partition.  The
> BTX loader stopped and could not load.  This rendered my system
> 'un-bootable'.  I copied this file from an earlier live filesystem CD,
> which restored my computer and enabled me to boot.
>

Any chance you can bisect when this happened? I think I'll need more
details to see what happened. What was your old loader that world based on?


> I also see the problem with the loader logs dumping core that others
> have reported recently.
>

I've not seen these reports, nor do I see if on my loader testing. More
details please? Last I had heard, everything was working...

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

GPTZFSBOOT in Current r326622 has problems

[Thomas Laus]

Group:

I updated my amd64 computer today to r326622 and copied the
/boot/gptzfsboot file to each of my ZFS hard drives p1 partition.  The
BTX loader stopped and could not load.  This rendered my system
'un-bootable'.  I copied this file from an earlier live filesystem CD,
which restored my computer and enabled me to boot.

I also see the problem with the loader logs dumping core that others
have reported recently.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
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"

logger(1) exited on signal 11 after r326525 -> r326622

[David Wolfskill]

I noticed among the messages on the console during the final stages of
the transition from single- to multi-user mode:

...
Dec  6 12:53:13 g1-252 kernel: ugen2.3:  at usbus2
Dec  6 12:53:13 g1-252 kernel: ugen1.3:  at usbus1
Dec  6 12:53:13 g1-252 kernel: pid 334 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: iwn0: iwn_read_firmware: ucode rev=0x08530501
Dec  6 12:53:13 g1-252 kernel: wlan0: link state changed to UP
Dec  6 12:53:13 g1-252 kernel: pid 398 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 400 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 403 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 407 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 409 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 410 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 413 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 414 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 417 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 418 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 419 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 420 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 475 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 477 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 544 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 545 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 547 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: pid 554 (logger), uid 0: exited on signal 11 
(core dumped)
Dec  6 12:53:13 g1-252 kernel: Linux x86-64 ELF exec handler installed
Dec  6 12:53:13 g1-252 dbus[170]: [system] Activating service 
name='org.freedesktop.ConsoleKit' (using servicehelper)



I don't see any similar issues on my (headless) build machine; I
just checked further, and verified that booting head @r326622 is the
only time I see them.  (The laptop spends most of its time running
stable/11.)  And the laptop didn't whine when booting head @r326525.

I'm trying to extract useful information from /logger.core, but not
doing so well on the "useful" part of that -- e.g.:

g1-252(12.0-C)[10] sudo lldb -c logger.core 
Password:
(lldb) target create --core "logger.core"
Core file '/logger.core' (x86_64) was loaded.
(lldb) bt
* thread #1, name = 'logger', stop reason = signal SIGSEGV
  * frame #0: 0x00402152
frame #1: 0x000800603618
(lldb) 


Actually writing to the log (obviously!) works

As far as I can tell, the laptop is otherwise functioning normally.
Strange

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump is an incompetent, lying bully who is unfit for any public office.

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


signature.asc
Description: PGP signature

rpi2 hangup during poudriere build: lots of pfault wmseg status

[Mark Millard]

I tried to build some ports on a rpi2
(via poudriere) but it hung up:
Ethernet and normal console use. (Note:
the root file system is on a USB SSD
and the swap partition is also on that
USB SSD.)

But ~^b worked for getting to the db>
prompt on the console.

>From there a ps suggests that it got hung
up in pfault activity. (Possibly insufficient
RAM+swap-partition space?) But it is not
clear to me that it should end up hung up
vs. killing processes or other such.

db> ps
  pid  ppid  pgrp   uid  state   wmesg   wchan   cmd
36369 36770 36588 0  D+  pfault  0xc0832880  sh
36368 36770 36588 0  D+  pfault  0xc0832880  awk
36367 36770 36588 0  D+  pfault  0xc0832880  awk
36353 88873 36588 0  D+J pfault  0xc0832880  gmake
35115 35107 36588 0  D+J pfault  0xc0832880  ld
35107 76552 36588 0  SW+Jwait0xc4a52398  c++
35071 35066 36588 0  D+J pfault  0xc0832880  ld
35066 76552 36588 0  SW+Jwait0xc64d6730  c++
35047 35036 36588 0  D+J pfault  0xc0832880  ld
35036 76552 36588 0  SW+Jwait0xc5efc000  c++
88873 88868 36588 0  S+J select  0xc5ea0b24  gmake
88868 88867 36588 0  SW+Jwait0xc3da1ac8  sh
88867 88674 36588 0  SW+Jwait0xc5904398  gmake
88674 28839 36588 0  SW+Jwait0xc66e4730  gmake
76552 76450 36588 0  SW+Jwait0xc5eb5ac8  gmake
76450 76438 36588 0  SW+Jwait0xc3aa2730  sh
76438 76380 36588 0  SW+Jwait0xc64d6000  gmake
76380 28839 36588 0  SW+Jwait0xc66e4ac8  gmake
28839 28828 36588 0  SW+Jwait0xc5f78ac8  gmake
28828 28826 36588 0  SW+Jwait0xc4a52000  sh
28826 28825 36588 0  SW+Jwait0xc5eb5398  gmake
28825 28793 36588 0  SW+Jwait0xc5c5d730  sh
28793 28792 36588 0  SW+Jwait0xc4262ac8  make
28792 23997 36588 0  SW+ wait0xc56fb000  sh
23997 36588 36588 0  D+  pfault  0xc0832880  sh
40786 36588 36588 0  S+  piperd  0xc422c5b8  sh
36770 36588 36588 0  S+  wait0xc5f78000  sh
36588   748 36588 0  D+  pfault  0xc0832880  sh
36387   748 36387 0  TW+ vi
  748   747   748 0  SW+ wait0xc4205000  sh
  747   741   747  1001  SW+ wait0xc4261398  su
  741   740   741  1001  SWs+wait0xc3da  sh
  740   737   737  1001  S   select  0xc4227524  sshd
  737   670   737 0  Ss  select  0xc42275a4  sshd
  723   722   723 0  D+  pfault  0xc0832880  sh
  722 1   722 0  SWs+wait0xc4260398  login
  721 1   721 0  Ss+ ttyin   0xc39d9474  getty
  674 1   674 0  ?Ws cron
  670 1   670 0  Ds  pfault  0xc0832880  sshd
  639 1   639 0  Ss  select  0xc4227724  powerd
  636 1   636 0  Ss  (threaded)  ntpd
100106   S   select  0xc4227764  ntpd
  588   587   587 0  S   (threaded)  nfsd
100098   S   rpcsvc  0xc42ecc50  nfsd: master
100110   S   rpcsvc  0xc3995250  nfsd: service
100111   S   rpcsvc  0xc41721d0  nfsd: service
100112   S   rpcsvc  0xc4171d50  nfsd: service
100113   S   rpcsvc  0xc39952d0  nfsd: service
100114   S   rpcsvc  0xc41725d0  nfsd: service
100115   S   rpcsvc  0xc4171dd0  nfsd: service
100116   S   rpcsvc  0xc39956d0  nfsd: service
100117   S   rpcsvc  0xc3995350  nfsd: service
100118   S   rpcsvc  0xc4172550  nfsd: service
100119   S   rpcsvc  0xc3995750  nfsd: service
100120   S   rpcsvc  0xc41726d0  nfsd: service
100121   S   rpcsvc  0xc39953d0  nfsd: service
100122   S   rpcsvc  0xc4172650  nfsd: service
100123   S   rpcsvc  0xc41723d0  nfsd: service
100124   S   rpcsvc  0xc4172450  nfsd: service
100125   S   rpcsvc  0xc3995450  nfsd: service
100126   S   rpcsvc  0xc4171cd0  nfsd: service
100127   S   rpcsvc  0xc4172350  nfsd: service
100128   S   rpcsvc  0xc41724d0  nfsd: service
100129   S   rpcsvc  0xc39954d0  nfsd: service
100130   S   rpcsvc  0xc4172250  nfsd: service
100131   S   rpcsvc  0xc41720d0  nfsd: service
100132   S   rpcsvc  0xc41722d0  nfsd: service
100133   S   rpcsvc  0xc3995550  nfsd: service
100134   S   rpcsvc  0xc4172050  nfsd: service
100135   S   rpcsvc  0xc4171e50  nfsd: service
100136   S   rpcsvc  0xc4172150  nfsd: service
100137   S   rpcsvc  0xc39955d0  nfsd: service
100138   S   rpcsvc  0xc4171f50