Re: btxld not found

[Marek Zarychta]

W dniu 28.01.2020 o 23:22, Kyle Evans pisze:
> On Tue, Jan 28, 2020 at 3:28 PM Kyle Evans  wrote:
>>
>> On Tue, Jan 28, 2020 at 2:15 PM Mark Millard  wrote:
>>>
>>> Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on
>>> Tue Jan 28 19:33:45 UTC 2020 :
>>>
 W dniu 28.01.2020 o 19:11, Dimitry Andric pisze:
> On 28 Jan 2020, at 12:36, Nick Hibma  wrote:
>>
>> Could anyone explain to me what I am doing wrong? make installworld 
>> fails each time with the following error
>>
>> ===> stand/i386/libi386 (install)
>> ===> stand/i386/loader_4th (install)
>> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
>> btxld -v -f aout -e 0x20 -o loader_4th -l 
>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
>> make[6]: exec(btxld) failed (No such file or directory)
>> *** Error code 1
>>
>> This is with source of last week. I had this problem before (from old 
>> sources) and fixed it by specifying the full path to btxld in the 
>> stand/i386/*/Makefile.
>
> Yes, this is most likely your clock(s) being off.  At installworld time,
> it should *not* start rebuilding your loader.
>
> Usually this happens if you build on one machine, and install on
> another, while the install machine's time is behind the build machine's
> time.  But it can also happens on one machine, for instance if you
> start in single user mode, and the clock is not yet synchronized.
>
> -Dimitry
>

 I build and install on the same machine, WITH_META_MODE=yes
>>> . . .
>>>
>>> Same here on a ThreadRipper 1950X: a self hosted build and
>>> install gets the issue at install time. WITH_META_MODE in use.
>>>
>>> Never started in single user mode. Also happens for targeting a
>>> local directory tree in the install, instead of updating the
>>> live system. (A directory tree used later with poudriere.)
>>>
>>> https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005130.html
>>>
>>> has some timestamps that I observed. btxld.full was about 27
>>> seconds later in the file system than btxld.meta, btxld.debug,
>>> and such (until I rebuilt).
>>>
>>> Looks to me more like multiple parallel builds that stomp on
>>> each other.
>>>
>>
>> I suspect y'all want something like the following:
>>
> 
> Sorry, that patch is clearly wrong- here's take two. A lot of these
> have dependencies on btxldr that aren't formally described in the
> targets, so I missed... a lot. New version just builds btx first gated
> behind a .WAIT then parallel the rest.
> 
> diff --git a/stand/i386/Makefile b/stand/i386/Makefile
> index a9d402acf60..24255eefabf 100644
> --- a/stand/i386/Makefile
> +++ b/stand/i386/Makefile
> @@ -4,7 +4,10 @@ NO_OBJ=t
> 
>  .include 
> 
> -SUBDIR.yes=mbr pmbr boot0 boot0sio btx boot2 cdboot gptboot \
> +# Almost everything else here relies on btxldr, so we must make sure it's 
> built
> +# before everything else proceeds so we don't end up building against a stale
> +# btxldr and ending up with a build-during-install scenario.
> +SUBDIR.yes=btx .WAIT mbr pmbr boot0 boot0sio boot2 cdboot gptboot \
> isoboot libi386
> 
>  SUBDIR.${MK_LOADER_FIREWIRE}+= libfirewire
> ___
> 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"
> 

I have not correctly applied the patch. I am sorry for the confusion.
The world builds fine with this second patch. I am not able to reproduce
the original error anymore (buildworld and installworld after that, both
go fine even with unpatched stand/i386/Makefile b/stand/i386/Makefile).

-- 
Marek Zarychta



signature.asc
Description: OpenPGP digital signature

Re: btxld not found

[Kyle Evans]

(Resend because I suck at e-mail; sorry Marek)

On Tue, Jan 28, 2020 at 5:42 PM Marek Zarychta
 wrote:
>
> W dniu 28.01.2020 o 22:28, Kyle Evans pisze:
> > On Tue, Jan 28, 2020 at 2:15 PM Mark Millard  wrote:
> >>
> >> Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on
> >> Tue Jan 28 19:33:45 UTC 2020 :
> >>
> >>> W dniu 28.01.2020 o 19:11, Dimitry Andric pisze:
>  On 28 Jan 2020, at 12:36, Nick Hibma  wrote:
> >
> > Could anyone explain to me what I am doing wrong? make installworld 
> > fails each time with the following error
> >
> > ===> stand/i386/libi386 (install)
> > ===> stand/i386/loader_4th (install)
> > strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
> > btxld -v -f aout -e 0x20 -o loader_4th -l 
> > /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
> > /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
> > make[6]: exec(btxld) failed (No such file or directory)
> > *** Error code 1
> >
> > This is with source of last week. I had this problem before (from old 
> > sources) and fixed it by specifying the full path to btxld in the 
> > stand/i386/*/Makefile.
> 
>  Yes, this is most likely your clock(s) being off.  At installworld time,
>  it should *not* start rebuilding your loader.
> 
>  Usually this happens if you build on one machine, and install on
>  another, while the install machine's time is behind the build machine's
>  time.  But it can also happens on one machine, for instance if you
>  start in single user mode, and the clock is not yet synchronized.
> 
>  -Dimitry
> 
> >>>
> >>> I build and install on the same machine, WITH_META_MODE=yes
> >> . . .
> >>
> >> Same here on a ThreadRipper 1950X: a self hosted build and
> >> install gets the issue at install time. WITH_META_MODE in use.
> >>
> >> Never started in single user mode. Also happens for targeting a
> >> local directory tree in the install, instead of updating the
> >> live system. (A directory tree used later with poudriere.)
> >>
> >> https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005130.html
> >>
> >> has some timestamps that I observed. btxld.full was about 27
> >> seconds later in the file system than btxld.meta, btxld.debug,
> >> and such (until I rebuilt).
> >>
> >> Looks to me more like multiple parallel builds that stomp on
> >> each other.
> >>
> >
> > I suspect y'all want something like the following:
> >
> > diff --git a/stand/i386/Makefile b/stand/i386/Makefile
> > index a9d402acf60..5b4e34ce587 100644
> > --- a/stand/i386/Makefile
> > +++ b/stand/i386/Makefile
> > @@ -18,4 +18,9 @@ SUBDIR.yes+=  pxeldr
> >
> >  SUBDIR.${MK_LOADER_ZFS}+=  zfsboot gptzfsboot
> >
> > +SUBDIR_DEPEND_pxeldr=  btx
> > +SUBDIR_DEPEND_loader_4th=  btx
> > +SUBDIR_DEPEND_loader_lua=  btx
> > +SUBDIR_DEPEND_loader_simp= btx
> > +
> >  .include 
>
> Thank you for taking care of this. The patch above worked and I confirm
> it solves the issue for me.
>

That's good to hear! I was starting to doubt because we don't use
SUBDIR_PARALLEL in the stand build, but on second glance we inherit it
during buildworld I reckon.

> I was not able to build the world with the patch you have posted later,
> here is the link to build log --> https://bsd.to/jTpd
>

This looks like the patch may have misapplied and btx ended up in
SUBDIR.yes twice -- the second instance should be removed, and only
the first on the left-hand-side of .WAIT should remain.
___
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: btxld not found

[Marek Zarychta]

W dniu 28.01.2020 o 22:28, Kyle Evans pisze:
> On Tue, Jan 28, 2020 at 2:15 PM Mark Millard  wrote:
>>
>> Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on
>> Tue Jan 28 19:33:45 UTC 2020 :
>>
>>> W dniu 28.01.2020 o 19:11, Dimitry Andric pisze:
 On 28 Jan 2020, at 12:36, Nick Hibma  wrote:
>
> Could anyone explain to me what I am doing wrong? make installworld fails 
> each time with the following error
>
> ===> stand/i386/libi386 (install)
> ===> stand/i386/loader_4th (install)
> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
> btxld -v -f aout -e 0x20 -o loader_4th -l 
> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
> make[6]: exec(btxld) failed (No such file or directory)
> *** Error code 1
>
> This is with source of last week. I had this problem before (from old 
> sources) and fixed it by specifying the full path to btxld in the 
> stand/i386/*/Makefile.

 Yes, this is most likely your clock(s) being off.  At installworld time,
 it should *not* start rebuilding your loader.

 Usually this happens if you build on one machine, and install on
 another, while the install machine's time is behind the build machine's
 time.  But it can also happens on one machine, for instance if you
 start in single user mode, and the clock is not yet synchronized.

 -Dimitry

>>>
>>> I build and install on the same machine, WITH_META_MODE=yes
>> . . .
>>
>> Same here on a ThreadRipper 1950X: a self hosted build and
>> install gets the issue at install time. WITH_META_MODE in use.
>>
>> Never started in single user mode. Also happens for targeting a
>> local directory tree in the install, instead of updating the
>> live system. (A directory tree used later with poudriere.)
>>
>> https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005130.html
>>
>> has some timestamps that I observed. btxld.full was about 27
>> seconds later in the file system than btxld.meta, btxld.debug,
>> and such (until I rebuilt).
>>
>> Looks to me more like multiple parallel builds that stomp on
>> each other.
>>
> 
> I suspect y'all want something like the following:
> 
> diff --git a/stand/i386/Makefile b/stand/i386/Makefile
> index a9d402acf60..5b4e34ce587 100644
> --- a/stand/i386/Makefile
> +++ b/stand/i386/Makefile
> @@ -18,4 +18,9 @@ SUBDIR.yes+=  pxeldr
> 
>  SUBDIR.${MK_LOADER_ZFS}+=  zfsboot gptzfsboot
> 
> +SUBDIR_DEPEND_pxeldr=  btx
> +SUBDIR_DEPEND_loader_4th=  btx
> +SUBDIR_DEPEND_loader_lua=  btx
> +SUBDIR_DEPEND_loader_simp= btx
> +
>  .include 

Thank you for taking care of this. The patch above worked and I confirm
it solves the issue for me.

I was not able to build the world with the patch you have posted later,
here is the link to build log --> https://bsd.to/jTpd

-- 
Marek Zarychta



signature.asc
Description: OpenPGP digital signature

Re: After update to r357104 build of poudriere jail fails with 'out of swap space'

[Cy Schubert]

On January 28, 2020 2:43:51 PM PST, Mark Millard  wrote:
>FYI: kib has a patch out for review to fix the
> head -r357026 change to OOM behavior in
> the vm_pageout_oom(VM_OOM_MEM_PF) context:
>
>https://reviews.freebsd.org/D23409
>
>===
>Mark Millard
>marklmi at yahoo.com
>( dsl-only.net went
>away in early 2018-Mar)

Works here at $JOB.


-- 
Pardon the typos and autocorrect, small keyboard in use. 
Cy Schubert 
FreeBSD UNIX:  Web: https://www.FreeBSD.org

The need of the many outweighs the greed of the few.

Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
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: how to use the ktls

[Rick Macklem]

John Baldwin wrote:
[stuff snipped]
>I don't know yet. :-/  With the TOE-based TLS I had been testing with, this 
>doesn't
>happen because the NIC blocks the data until it gets the key and then it's 
>always
>available via KTLS.  With software-based KTLS for RX (which I'm going to start
>working on soon), this won't be the case and you will potentially have some 
>data
>already ready by OpenSSL that needs to be drained from OpenSSL before you can
>depend on KTLS.  It's probably only the first few messsages, but I will need 
>to figure
>out a way that you can tell how much pending data in userland you need to read 
>via
>SSL_read() and then pass back into the kernel before relying on KTLS (it would 
>just
>be a single chunk of data after SSL_connect you would have to do this for).
I think SSL_read() ends up calling ssl3_read_bytes(..APPLICATION..) and then it 
throws
away non-application data records. (Not sure, ssl3_read_bytes() gets pretty 
convoluted at
a glance.;-)

I've found another issue that should keep me amused for a while (this is 
becoming an
interesting little project;-).
The KERN_TLS needs unmapped pages on the mbuf chain, but that isn't what NFS
generates.
I think I'll have to implement some sort of copy function that creates mbufs 
with unmapped
pages and then maps them into kernel space for long enough that the data can be 
copied,
called just before sosend(). Most NFS RPC messages will easily fit in one page.

Someday, the biggies like server read reply may be able to do what sendfile 
does and
put the read data in unmapped page mbufs, avoiding the long list of mbuf 
clusters
that VOP_READ() currently copies the data into.
--> But that's longer term than getting this to work.;-)

Thanks for all your help John, rick

> I'm currently testing with a kernel that doesn't have options KERN_TLS and
> (so long as I get rid of the 478 bytes), it then just does unencrypted RPCs.
>
> So, I guess the big question is can I get access to your WIP code for KTLS
> receive? (I have no idea if I can make progress on it, but I can't do a lot 
> more
> before I have that.)

The WIP only works right now if you have a Chelsio T6 NIC as it uses the T6's 
TCP
offload engine to do TLS.  If you don't have that gear, ping me off-list.  It
would also let you not worry about the SSL_read case for now for initial 
testing.

--
John Baldwin
___
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: After update to r357104 build of poudriere jail fails with 'out of swap space'

[Mark Millard]

FYI: kib has a patch out for review to fix the
 head -r357026 change to OOM behavior in
 the vm_pageout_oom(VM_OOM_MEM_PF) context:

https://reviews.freebsd.org/D23409

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: btxld not found

[Kyle Evans]

On Tue, Jan 28, 2020 at 3:28 PM Kyle Evans  wrote:
>
> On Tue, Jan 28, 2020 at 2:15 PM Mark Millard  wrote:
> >
> > Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on
> > Tue Jan 28 19:33:45 UTC 2020 :
> >
> > > W dniu 28.01.2020 o 19:11, Dimitry Andric pisze:
> > > > On 28 Jan 2020, at 12:36, Nick Hibma  wrote:
> > > >>
> > > >> Could anyone explain to me what I am doing wrong? make installworld 
> > > >> fails each time with the following error
> > > >>
> > > >> ===> stand/i386/libi386 (install)
> > > >> ===> stand/i386/loader_4th (install)
> > > >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
> > > >> btxld -v -f aout -e 0x20 -o loader_4th -l 
> > > >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
> > > >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
> > > >> make[6]: exec(btxld) failed (No such file or directory)
> > > >> *** Error code 1
> > > >>
> > > >> This is with source of last week. I had this problem before (from old 
> > > >> sources) and fixed it by specifying the full path to btxld in the 
> > > >> stand/i386/*/Makefile.
> > > >
> > > > Yes, this is most likely your clock(s) being off.  At installworld time,
> > > > it should *not* start rebuilding your loader.
> > > >
> > > > Usually this happens if you build on one machine, and install on
> > > > another, while the install machine's time is behind the build machine's
> > > > time.  But it can also happens on one machine, for instance if you
> > > > start in single user mode, and the clock is not yet synchronized.
> > > >
> > > > -Dimitry
> > > >
> > >
> > > I build and install on the same machine, WITH_META_MODE=yes
> > . . .
> >
> > Same here on a ThreadRipper 1950X: a self hosted build and
> > install gets the issue at install time. WITH_META_MODE in use.
> >
> > Never started in single user mode. Also happens for targeting a
> > local directory tree in the install, instead of updating the
> > live system. (A directory tree used later with poudriere.)
> >
> > https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005130.html
> >
> > has some timestamps that I observed. btxld.full was about 27
> > seconds later in the file system than btxld.meta, btxld.debug,
> > and such (until I rebuilt).
> >
> > Looks to me more like multiple parallel builds that stomp on
> > each other.
> >
>
> I suspect y'all want something like the following:
>

Sorry, that patch is clearly wrong- here's take two. A lot of these
have dependencies on btxldr that aren't formally described in the
targets, so I missed... a lot. New version just builds btx first gated
behind a .WAIT then parallel the rest.

diff --git a/stand/i386/Makefile b/stand/i386/Makefile
index a9d402acf60..24255eefabf 100644
--- a/stand/i386/Makefile
+++ b/stand/i386/Makefile
@@ -4,7 +4,10 @@ NO_OBJ=t

 .include 

-SUBDIR.yes=mbr pmbr boot0 boot0sio btx boot2 cdboot gptboot \
+# Almost everything else here relies on btxldr, so we must make sure it's built
+# before everything else proceeds so we don't end up building against a stale
+# btxldr and ending up with a build-during-install scenario.
+SUBDIR.yes=btx .WAIT mbr pmbr boot0 boot0sio boot2 cdboot gptboot \
isoboot libi386

 SUBDIR.${MK_LOADER_FIREWIRE}+= libfirewire
___
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: OOMA kill with vm.pfault_oom_attempts="-1" on RPi3 at r357147 (a vm_pfault_oom_attempts < 0 handling bug as of head -r357026)

[Mark Millard]

[I recommend not sending kib our other exchanges: that he has been
notified is enough. I also sent the material to 2 folks that I forgot at
the time and replied to one more related message with the information.
For most of these folks our general exchange is likely viewed as noise
after then basic, important point for them. Note: kib was the reviewer,
not the creator or submitter of -r357026 .]

On 2020-Jan-28, at 12:11, bob prohaska  wrote:

> On Tue, Jan 28, 2020 at 11:28:14AM -0800, Mark Millard wrote:
>> 
>> 
>> On 2020-Jan-28, at 11:02, bob prohaska  wrote:
>> 
>>> On Tue, Jan 28, 2020 at 09:42:17AM -0800, Mark Millard wrote:
 
 
 
>>> The (partly)modified kernel compiled and booted without
>>> obvious trouble. It's trying to finish buildworld now.
>>> 
> Stopped already, with 
> Jan 28 11:41:59 www kernel: pid 29909 (cc), jid 0, uid 0, was killed: fault's 
> page allocation failed
> 

Yea, what I did in vm_pageout_oom for its messages does
indictae when the vm_pageout_oom(VM_OOM_MEM_PF)
happens of itself. So the printf before that call is
not essential.

With the bug that we have identified, this is the
expected notification until things are fixed.

> 
 If you are testing with vm.pfault_oom_attempts="-1" then
 the vm_fault printf message should never happen anyway.
 
>>> Would it not be interesting if the message appeared in that
>>> case? 
>> 
>> Thanks for the question: looking at the new code found a bug
>> causing oom where it used to be avoided in head -r357025 and
>> before.
> 
> 
> Glad to be of service, even if inadvertently 8-)
> 
> 
>> After vm_waitpfault(dset, vm_pfault_oom_wait * hz)
>> the -r357026 code does a vm_pageout_oom(VM_OOM_MEM_PF) no
>> matter what, even when vm_pfault_oom_attempts < 0 ||
>> fs->oom < vm_pfault_oom_attempts :
>> 
>> New code in head -r357026
>> ( nothing to avoid the vm_pageout_oom(VM_OOM_MEM_PF)
>> for vm_pfault_oom_attempts < 0 ||
>> fs->oom < vm_pfault_oom_attempts ):
>> 
>>  if (fs->m == NULL) {
>>  unlock_and_deallocate(fs);
>>  if (vm_pfault_oom_attempts < 0 ||
>>  fs->oom < vm_pfault_oom_attempts) {
>>  fs->oom++;
>>  vm_waitpfault(dset, vm_pfault_oom_wait * hz);
>>  }
>>  if (bootverbose)
>>  printf(
>> "proc %d (%s) failed to alloc page on fault, starting OOM\n",
>>  curproc->p_pid, curproc->p_comm);
>>  vm_pageout_oom(VM_OOM_MEM_PF);
>>  return (KERN_RESOURCE_SHORTAGE);
>>  }
>> 
>> Old code in head -r357025
>> ( has the goto RetryFault_oom after vm_waitpfault(. . .),
>> thereby avoiding the vm_pageout_oom(VM_OOM_MEM_PF) for
>> vm_pfault_oom_attempts < 0 || fs->oom < vm_pfault_oom_attempts ) :
>> 
>>  if (fs.m == NULL) {
>>  unlock_and_deallocate();
>>  if (vm_pfault_oom_attempts < 0 ||
>>  oom < vm_pfault_oom_attempts) {
>>  oom++;
>>  vm_waitpfault(dset,
>>  vm_pfault_oom_wait * hz);
>>  goto RetryFault_oom;
>>  }
>>  if (bootverbose)
>>  printf(
>>  "proc %d (%s) failed to alloc page on fault, starting OOM\n",
>>  curproc->p_pid, curproc->p_comm);
>>  vm_pageout_oom(VM_OOM_MEM_PF);
>>  goto RetryFault;
>>  }
>> 
>> I expect this is the source of the behavioral
>> difference folks have been seeing for OOM kills.
>> 
>> 
>> As for "gather evidence" messages . . .
>> 
 You may be able to just look and manually delete or
 comment out the bootverbose line in the more modern
 source that currently looks like:
 
if (bootverbose)
printf(
 "proc %d (%s) failed to alloc page on fault, starting OOM\n",
curproc->p_pid, curproc->p_comm);
vm_pageout_oom(VM_OOM_MEM_PF);
return (KERN_RESOURCE_SHORTAGE);
 
>>> 
>>> I can find those lines in /usr/src/sys/vm/vm_fault.c, but
>>> unclear on the motivation to comment the lines out. Perhaps 
>>> to eliminate the return(...) ?  Anyway, is it sufficient 
>>> to insert /* before and */ after? 
>> 
>> The only line to delete or comment out in that
>> code block is:
>> 
>>  if (bootverbose)
>> 
>> Disabling that line makes the following printf
>> always happen, even when a verbose boot was not
>> done.
> Oops, it's commented out now and the kernel is rebuilding.

Not a big deal, given the "was killed: fault's page
allocation failed" message that is separately generated.

>> 
>> Based on the above reported code change, having
>> a 

Re: btxld not found

[Kyle Evans]

On Tue, Jan 28, 2020 at 2:15 PM Mark Millard  wrote:
>
> Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on
> Tue Jan 28 19:33:45 UTC 2020 :
>
> > W dniu 28.01.2020 o 19:11, Dimitry Andric pisze:
> > > On 28 Jan 2020, at 12:36, Nick Hibma  wrote:
> > >>
> > >> Could anyone explain to me what I am doing wrong? make installworld 
> > >> fails each time with the following error
> > >>
> > >> ===> stand/i386/libi386 (install)
> > >> ===> stand/i386/loader_4th (install)
> > >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
> > >> btxld -v -f aout -e 0x20 -o loader_4th -l 
> > >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
> > >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
> > >> make[6]: exec(btxld) failed (No such file or directory)
> > >> *** Error code 1
> > >>
> > >> This is with source of last week. I had this problem before (from old 
> > >> sources) and fixed it by specifying the full path to btxld in the 
> > >> stand/i386/*/Makefile.
> > >
> > > Yes, this is most likely your clock(s) being off.  At installworld time,
> > > it should *not* start rebuilding your loader.
> > >
> > > Usually this happens if you build on one machine, and install on
> > > another, while the install machine's time is behind the build machine's
> > > time.  But it can also happens on one machine, for instance if you
> > > start in single user mode, and the clock is not yet synchronized.
> > >
> > > -Dimitry
> > >
> >
> > I build and install on the same machine, WITH_META_MODE=yes
> . . .
>
> Same here on a ThreadRipper 1950X: a self hosted build and
> install gets the issue at install time. WITH_META_MODE in use.
>
> Never started in single user mode. Also happens for targeting a
> local directory tree in the install, instead of updating the
> live system. (A directory tree used later with poudriere.)
>
> https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005130.html
>
> has some timestamps that I observed. btxld.full was about 27
> seconds later in the file system than btxld.meta, btxld.debug,
> and such (until I rebuilt).
>
> Looks to me more like multiple parallel builds that stomp on
> each other.
>

I suspect y'all want something like the following:

diff --git a/stand/i386/Makefile b/stand/i386/Makefile
index a9d402acf60..5b4e34ce587 100644
--- a/stand/i386/Makefile
+++ b/stand/i386/Makefile
@@ -18,4 +18,9 @@ SUBDIR.yes+=  pxeldr

 SUBDIR.${MK_LOADER_ZFS}+=  zfsboot gptzfsboot

+SUBDIR_DEPEND_pxeldr=  btx
+SUBDIR_DEPEND_loader_4th=  btx
+SUBDIR_DEPEND_loader_lua=  btx
+SUBDIR_DEPEND_loader_simp= btx
+
 .include 
___
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: btxld not found

[Mark Millard]

Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on
Tue Jan 28 19:33:45 UTC 2020 :

> W dniu 28.01.2020 o 19:11, Dimitry Andric pisze:
> > On 28 Jan 2020, at 12:36, Nick Hibma  wrote:
> >>
> >> Could anyone explain to me what I am doing wrong? make installworld fails 
> >> each time with the following error
> >>
> >> ===> stand/i386/libi386 (install)
> >> ===> stand/i386/loader_4th (install)
> >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
> >> btxld -v -f aout -e 0x20 -o loader_4th -l 
> >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
> >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
> >> make[6]: exec(btxld) failed (No such file or directory)
> >> *** Error code 1
> >>
> >> This is with source of last week. I had this problem before (from old 
> >> sources) and fixed it by specifying the full path to btxld in the 
> >> stand/i386/*/Makefile.
> > 
> > Yes, this is most likely your clock(s) being off.  At installworld time,
> > it should *not* start rebuilding your loader.
> > 
> > Usually this happens if you build on one machine, and install on
> > another, while the install machine's time is behind the build machine's
> > time.  But it can also happens on one machine, for instance if you
> > start in single user mode, and the clock is not yet synchronized.
> > 
> > -Dimitry
> > 
> 
> I build and install on the same machine, WITH_META_MODE=yes
. . .

Same here on a ThreadRipper 1950X: a self hosted build and
install gets the issue at install time. WITH_META_MODE in use.

Never started in single user mode. Also happens for targeting a
local directory tree in the install, instead of updating the
live system. (A directory tree used later with poudriere.)

https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005130.html

has some timestamps that I observed. btxld.full was about 27
seconds later in the file system than btxld.meta, btxld.debug,
and such (until I rebuilt).

Looks to me more like multiple parallel builds that stomp on
each other.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: OOMA kill with vm.pfault_oom_attempts="-1" on RPi3 at r357147 (a vm_pfault_oom_attempts < 0 handling bug as of head -r357026)

[bob prohaska]

On Tue, Jan 28, 2020 at 11:28:14AM -0800, Mark Millard wrote:
> 
> 
> On 2020-Jan-28, at 11:02, bob prohaska  wrote:
> 
> > On Tue, Jan 28, 2020 at 09:42:17AM -0800, Mark Millard wrote:
> >> 
> >> 
> >> 
> > The (partly)modified kernel compiled and booted without
> > obvious trouble. It's trying to finish buildworld now.
> > 
Stopped already, with 
Jan 28 11:41:59 www kernel: pid 29909 (cc), jid 0, uid 0, was killed: fault's 
page allocation failed



> >> If you are testing with vm.pfault_oom_attempts="-1" then
> >> the vm_fault printf message should never happen anyway.
> >> 
> > Would it not be interesting if the message appeared in that
> > case? 
> 
> Thanks for the question: looking at the new code found a bug
> causing oom where it used to be avoided in head -r357025 and
> before.


Glad to be of service, even if inadvertently 8-)

 
> After vm_waitpfault(dset, vm_pfault_oom_wait * hz)
> the -r357026 code does a vm_pageout_oom(VM_OOM_MEM_PF) no
> matter what, even when vm_pfault_oom_attempts < 0 ||
> fs->oom < vm_pfault_oom_attempts :
> 
> New code in head -r357026
> ( nothing to avoid the vm_pageout_oom(VM_OOM_MEM_PF)
> for vm_pfault_oom_attempts < 0 ||
> fs->oom < vm_pfault_oom_attempts ):
> 
>   if (fs->m == NULL) {
>   unlock_and_deallocate(fs);
>   if (vm_pfault_oom_attempts < 0 ||
>   fs->oom < vm_pfault_oom_attempts) {
>   fs->oom++;
>   vm_waitpfault(dset, vm_pfault_oom_wait * hz);
>   }
>   if (bootverbose)
>   printf(
> "proc %d (%s) failed to alloc page on fault, starting OOM\n",
>   curproc->p_pid, curproc->p_comm);
>   vm_pageout_oom(VM_OOM_MEM_PF);
>   return (KERN_RESOURCE_SHORTAGE);
>   }
> 
> Old code in head -r357025
> ( has the goto RetryFault_oom after vm_waitpfault(. . .),
> thereby avoiding the vm_pageout_oom(VM_OOM_MEM_PF) for
> vm_pfault_oom_attempts < 0 || fs->oom < vm_pfault_oom_attempts ) :
> 
>   if (fs.m == NULL) {
>   unlock_and_deallocate();
>   if (vm_pfault_oom_attempts < 0 ||
>   oom < vm_pfault_oom_attempts) {
>   oom++;
>   vm_waitpfault(dset,
>   vm_pfault_oom_wait * hz);
>   goto RetryFault_oom;
>   }
>   if (bootverbose)
>   printf(
>   "proc %d (%s) failed to alloc page on fault, starting OOM\n",
>   curproc->p_pid, curproc->p_comm);
>   vm_pageout_oom(VM_OOM_MEM_PF);
>   goto RetryFault;
>   }
> 
> I expect this is the source of the behavioral
> difference folks have been seeing for OOM kills.
> 
> 
> As for "gather evidence" messages . . .
> 
> >> You may be able to just look and manually delete or
> >> comment out the bootverbose line in the more modern
> >> source that currently looks like:
> >> 
> >>if (bootverbose)
> >>printf(
> >> "proc %d (%s) failed to alloc page on fault, starting OOM\n",
> >>curproc->p_pid, curproc->p_comm);
> >>vm_pageout_oom(VM_OOM_MEM_PF);
> >>return (KERN_RESOURCE_SHORTAGE);
> >> 
> > 
> > I can find those lines in /usr/src/sys/vm/vm_fault.c, but
> > unclear on the motivation to comment the lines out. Perhaps 
> > to eliminate the return(...) ?  Anyway, is it sufficient 
> > to insert /* before and */ after? 
> 
> The only line to delete or comment out in that
> code block is:
> 
>   if (bootverbose)
> 
> Disabling that line makes the following printf
> always happen, even when a verbose boot was not
> done.
Oops, it's commented out now and the kernel is rebuilding.

> 
> Based on the above reported code change, having
> a message before vm_pageout_oom(VM_OOM_MEM_PF) is
> important to getting a report of the kill being
> via that code.
>

Thank you!

bob prohaska
 
___
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: After update to r357104 build of poudriere jail fails with 'out of swap space'

[Mark Millard]

On 2020-Jan-28, at 11:33, Cy Schubert  wrote:

> On January 27, 2020 2:25:59 PM PST, Mark Millard  wrote:
>> . . .
>> 
>> It would be nice to find out what category of issue in the kernel
>> is driving the OOM kills for your 5GB context with MAKE_JOBS_NUMBER=4.
>> Too bad the first kill does not report a backtrace spanning the
>> code choosing to do the kill (or otherwise report the type of issue
>> leading the the kill).
>> 
>> Your is consistent with the small arm board folks reporting that
>> recently
>> contexts that were doing buildworld and the like fine under somewhat
>> older kernels have started getting OOM kills, despite the two settings.
>> 
>> At the moment I'm not sure how to find the category(s) of issue(s) that
>> is(are) driving these OOM kills.
>> 
>> Thanks for reporting what settings you were using.
>> 
>> . . .
> 
> I've been able to reproduce the problem at $JOB in a Virtualbox VM with 1 
> vCPU, 1.5 GB vRAM, and 2 GB swap building graphics/graphviz: cc killed out of 
> swap space. The killed cc had an address space of ~ 500 MB, using only 43 MB 
> of the 2 GB swap. Free space is exhausted but swap used never exceeds tens of 
> MB. Doubling the swap to 4 GB had no effect. The VM doesn't use ZFS.
> 
> This appears recent.
> 

head -r357026 turned some code that previously avoided
vm_pageout_oom(VM_OOM_MEM_PF) into code that always
does it for the conditions that should avoid the call.

In part, this disabled what we were doing
vm.pfault_oom_attempts="-1" for: that case now
always kills.

Head -r357025 is the last version to avoid the call
(until this is fixed).


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: After update to r357104 build of poudriere jail fails with 'out of swap space'

[Cy Schubert]

On January 27, 2020 2:25:59 PM PST, Mark Millard  wrote:
>
>
>On 2020-Jan-27, at 12:48, Cy Schubert 
>wrote:
>
>> In message , Mark
>Millard 
>> write
>> s:
>>> 
>>> 
>>> 
>>> On 2020-Jan-27, at 10:20, Cy Schubert 
>wrote:
>>> 
 On January 27, 2020 5:09:06 AM PST, Cy Schubert
>
>>> wrote:
>> . . . 
> 
> Setting a lower arc_max at boot is unlikely to help. Rust was
>building
> on 
> the 8 GB and 5 GB 4 core machines last night. It completed
>successfully
> on 
> the 8 GB machine, while using 12 MB of swap. ARC was at 1307 MB.
> 
> On the 5 GB 4 core machine the rust build died of OOM. 328 KB swap
>was 
> used. ARC was reported at 941 MB. arc_min on this machine is 489.2
>MB.
 
 MAKE_JOBS_NUMBER=3 worked building rust on the 5  GB 4 core
>machine. ARC is
>>> at 534 MB with 12 MB swap used.
>>> 
>>> If you increase vm.pageout_oom_seq to, say, 10 times what you now
>use,
>>> does MAKE_JOBS_NUMBER=4 complete --or at least go notably longer
>before
>>> getting OOM behavior from the system? (The default is 12 last I
>checked.
>>> So that might be what you are now using.)
>> 
>> It's already 4096 (default is 12).
>
>Wow. Then the count of tries to get free RAM above the threshold
>does not seem likely to be the source of the OOM kills.
>
>>> 
>>> Have you tried also having: vm.pfault_oom_attempts="-1" (Presuming
>>> you are not worried about actually running out of swap/page space,
>>> or can tolerate a deadlock if it does run out.) This setting
>presumes
>>> head, not release or stable. (Last I checked anyway.)
>> 
>> Already there.
>
>Then page-out delay does not seem likely to be the source of the OOM
>kills.
>
>> The box is a sandbox with remote serial console access so deadlocks
>are ok.
>> 
>>> 
>>> It would be interesting to know what difference those two settings
>>> together might make for your context: it seems to be a good context
>>> for testing in this area. (But you might already have set them.
>>> If so, it would be good to report the figures in use.)
>>> 
>>> Of course, my experiment ideas need not be your actions.
>> 
>> It's a sandbox machine. We already know 8 GB works with 4 threads on
>as 
>> many cores. And, 5 GB works with 3 threads on 4 cores.
>
>It would be nice to find out what category of issue in the kernel
>is driving the OOM kills for your 5GB context with MAKE_JOBS_NUMBER=4.
>Too bad the first kill does not report a backtrace spanning the
>code choosing to do the kill (or otherwise report the type of issue
>leading the the kill).
>
>Your is consistent with the small arm board folks reporting that
>recently
>contexts that were doing buildworld and the like fine under somewhat
>older kernels have started getting OOM kills, despite the two settings.
>
>At the moment I'm not sure how to find the category(s) of issue(s) that
>is(are) driving these OOM kills.
>
>Thanks for reporting what settings you were using.
>
>===
>Mark Millard
>marklmi at yahoo.com
>( dsl-only.net went
>away in early 2018-Mar)

I've been able to reproduce the problem at $JOB in a Virtualbox VM with 1 vCPU, 
1.5 GB vRAM, and 2 GB swap building graphics/graphviz: cc killed out of swap 
space. The killed cc had an address space of ~ 500 MB, using only 43 MB of the 
2 GB swap. Free space is exhausted but swap used never exceeds tens of MB. 
Doubling the swap to 4 GB had no effect. The VM doesn't use ZFS.

This appears recent.


-- 
Pardon the typos and autocorrect, small keyboard in use. 
Cy Schubert 
FreeBSD UNIX:  Web: https://www.FreeBSD.org

The need of the many outweighs the greed of the few.

Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
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: btxld not found

[Marek Zarychta]

W dniu 28.01.2020 o 19:11, Dimitry Andric pisze:
> On 28 Jan 2020, at 12:36, Nick Hibma  wrote:
>>
>> Could anyone explain to me what I am doing wrong? make installworld fails 
>> each time with the following error
>>
>> ===> stand/i386/libi386 (install)
>> ===> stand/i386/loader_4th (install)
>> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
>> btxld -v -f aout -e 0x20 -o loader_4th -l 
>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
>> make[6]: exec(btxld) failed (No such file or directory)
>> *** Error code 1
>>
>> This is with source of last week. I had this problem before (from old 
>> sources) and fixed it by specifying the full path to btxld in the 
>> stand/i386/*/Makefile.
> 
> Yes, this is most likely your clock(s) being off.  At installworld time,
> it should *not* start rebuilding your loader.
> 
> Usually this happens if you build on one machine, and install on
> another, while the install machine's time is behind the build machine's
> time.  But it can also happens on one machine, for instance if you
> start in single user mode, and the clock is not yet synchronized.
> 
> -Dimitry
> 

I build and install on the same machine, WITH_META_MODE=yes the CPU is
Origin="AuthenticAMD"  Id=0x100f43  Family=0x10  Model=0x4  Stepping=3,
underlining filesystem is ZFS, OBJDIR is /usr/obj though it's really
/usr/amdfam10obj.head mounted with nullfs. For build/install I am using
still these old way commands:
make -sj4 buildworld && make installworld
On the same machine I am building/installing 12-STABLE world as well,
but this error is only present for CURRENT. It has appeared for the
first time in early October last year and remains unresolved to me. I
just ignore errors on installworld since then.

===> stand/i386/btx (install)
===> stand/i386/btx/btx (install)
===> stand/i386/btx/btxldr (install)
===> stand/i386/btx/lib (install)
===> stand/i386/boot2 (install)
btxld -v -E 0x2000 -f bin -b
/usr/obj/usr/src/amd64.amd64/stand/i386/btx/btx/btx -l boot2.ldr  -o
boot2.ld -P 1 boot2.bin
make[6]: exec(btxld) failed (No such file or directory)
*** Error code 1


-- 
Marek Zarychta



signature.asc
Description: OpenPGP digital signature

Re: OOMA kill with vm.pfault_oom_attempts="-1" on RPi3 at r357147 (a vm_pfault_oom_attempts < 0 handling bug as of head -r357026)

[Mark Millard]

On 2020-Jan-28, at 11:02, bob prohaska  wrote:

> On Tue, Jan 28, 2020 at 09:42:17AM -0800, Mark Millard wrote:
>> 
>> 
>> 
> The (partly)modified kernel compiled and booted without
> obvious trouble. It's trying to finish buildworld now.
> 
>> If you are testing with vm.pfault_oom_attempts="-1" then
>> the vm_fault printf message should never happen anyway.
>> 
> Would it not be interesting if the message appeared in that
> case? 

Thanks for the question: looking at the new code found a bug
causing oom where it used to be avoided in head -r357025 and
before.

After vm_waitpfault(dset, vm_pfault_oom_wait * hz)
the -r357026 code does a vm_pageout_oom(VM_OOM_MEM_PF) no
matter what, even when vm_pfault_oom_attempts < 0 ||
fs->oom < vm_pfault_oom_attempts :

New code in head -r357026
( nothing to avoid the vm_pageout_oom(VM_OOM_MEM_PF)
for vm_pfault_oom_attempts < 0 ||
fs->oom < vm_pfault_oom_attempts ):

if (fs->m == NULL) {
unlock_and_deallocate(fs);
if (vm_pfault_oom_attempts < 0 ||
fs->oom < vm_pfault_oom_attempts) {
fs->oom++;
vm_waitpfault(dset, vm_pfault_oom_wait * hz);
}
if (bootverbose)
printf(
"proc %d (%s) failed to alloc page on fault, starting OOM\n",
curproc->p_pid, curproc->p_comm);
vm_pageout_oom(VM_OOM_MEM_PF);
return (KERN_RESOURCE_SHORTAGE);
}

Old code in head -r357025
( has the goto RetryFault_oom after vm_waitpfault(. . .),
thereby avoiding the vm_pageout_oom(VM_OOM_MEM_PF) for
vm_pfault_oom_attempts < 0 || fs->oom < vm_pfault_oom_attempts ) :

if (fs.m == NULL) {
unlock_and_deallocate();
if (vm_pfault_oom_attempts < 0 ||
oom < vm_pfault_oom_attempts) {
oom++;
vm_waitpfault(dset,
vm_pfault_oom_wait * hz);
goto RetryFault_oom;
}
if (bootverbose)
printf(
"proc %d (%s) failed to alloc page on fault, starting OOM\n",
curproc->p_pid, curproc->p_comm);
vm_pageout_oom(VM_OOM_MEM_PF);
goto RetryFault;
}

I expect this is the source of the behavioral
difference folks have been seeing for OOM kills.


As for "gather evidence" messages . . .

>> You may be able to just look and manually delete or
>> comment out the bootverbose line in the more modern
>> source that currently looks like:
>> 
>>  if (bootverbose)
>>  printf(
>> "proc %d (%s) failed to alloc page on fault, starting OOM\n",
>>  curproc->p_pid, curproc->p_comm);
>>  vm_pageout_oom(VM_OOM_MEM_PF);
>>  return (KERN_RESOURCE_SHORTAGE);
>> 
> 
> I can find those lines in /usr/src/sys/vm/vm_fault.c, but
> unclear on the motivation to comment the lines out. Perhaps 
> to eliminate the return(...) ?  Anyway, is it sufficient 
> to insert /* before and */ after? 

The only line to delete or comment out in that
code block is:

if (bootverbose)

Disabling that line makes the following printf
always happen, even when a verbose boot was not
done.

Based on the above reported code change, having
a message before vm_pageout_oom(VM_OOM_MEM_PF) is
important to getting a report of the kill being
via that code.

>> and is now in vm_fault_allocate(. . .). (That file has
>> hd a reorganization since where I'm synchronized.)
>> 
>> Having the message indicate vm_fault_allocate is
>> optional but would look like:
>> 
>> "vm_fault_allocate: proc %d (%s) failed to alloc page on fault, starting 
>> OOM\n",
>> 
>> Doing the delete/comment-out would avoid waiting for me.
>> 
>> 
> I'll do it after the next stoppage.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: btxld not found

[Dimitry Andric]

On 28 Jan 2020, at 12:36, Nick Hibma  wrote:
> 
> Could anyone explain to me what I am doing wrong? make installworld fails 
> each time with the following error
> 
> ===> stand/i386/libi386 (install)
> ===> stand/i386/loader_4th (install)
> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
> btxld -v -f aout -e 0x20 -o loader_4th -l 
> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
> make[6]: exec(btxld) failed (No such file or directory)
> *** Error code 1
> 
> This is with source of last week. I had this problem before (from old 
> sources) and fixed it by specifying the full path to btxld in the 
> stand/i386/*/Makefile.

Yes, this is most likely your clock(s) being off.  At installworld time,
it should *not* start rebuilding your loader.

Usually this happens if you build on one machine, and install on
another, while the install machine's time is behind the build machine's
time.  But it can also happens on one machine, for instance if you
start in single user mode, and the clock is not yet synchronized.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: btxld not found

[Mark Millard]

Nick Hibma nick at van-laarhoven.org wrote on
Tue Jan 28 16:08:19 UTC 2020 :

> > On Tue, Jan 28, 2020, 4:57 AM Nick Hibma  > > wrote:
> > > On 28/01 /2020, at 12:39, Toomas Soome mailto:tsoome 
> > > at me.com>> wrote:
> > > 
> > >> On 28. Jan 2020, at 13:36, Nick Hibma  > >> > wrote:
> > >> 
> > >> Folks,
> > >> 
> > >> Could anyone explain to me what I am doing wrong? make installworld 
> > >> fails each time with the following error
> > >> 
> > >> ===> stand/i386/libi386 (install)
> > >> ===> stand/i386/loader_4th (install)
> > >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
> > >> btxld -v -f aout -e 0x20 -o loader_4th -l 
> > >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
> > >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
> > >> make[6]: exec(btxld) failed (No such file or directory)
> > >> *** Error code 1
> > >> 
> > >> This is with source of last week. I had this problem before (from old 
> > >> sources) and fixed it by specifying the full path to btxld in the 
> > >> stand/i386/*/Makefile. 
> > >> 
> > >> Any pointers?
> > >> 
> > > 
> > > it should be /usr/sbin/btxld; are you missing /usr/sbin from the path?
> > 
> > Well, it's an 'installworld' so I would expect it to be providing that 
> > program itself, but no, /usr/sbin/ is in the path of the current shell.
> > 
> > Also, in some of the makefiles the target calling btxldr is depending on 
> > the build of that executable:
> > 
> > Index: stand/i386/pxeldr/Makefile
> > ===
> > --- stand/i386/pxeldr/Makefile  (revision 357042)
> > +++ stand/i386/pxeldr/Makefile  (working copy)
> > @@ -39,7 +39,7 @@
> >  CLEANFILES+= ${LOADER}
> > 
> >  ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN}
> > -   btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l ${BTXLDR} \
> > +   /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l 
> > ${BTXLDR} \
> > -b ${BTXKERN} ${LOADERBIN}
> > 
> > This is definitely wrong. We have either a path that is wrong, or we aren't 
> > reinstalling btxld in the right place.
> > 
> > Warner
> 
> This is not a fix, this is to get me through the installworld. As I've not 
> seen any mention of this the past 6 months it must be something on my system 
> that makes things go bad, but I have no idea what.

I reported this to toolchain back on 2019-Dec-14 and 15, for updating to
head -r355761 then -r355777 at the time:

https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005127.html
https://lists.freebsd.org/pipermail/freebsd-toolchain/2019-December/005130.html

It is not just your context that has the issue.

The 2nd message showed some interesting timestamps from the build.

I've found that re-running buildworld (not from scratch) with -j1
then doing installworld seemed to reliably deal with it. Allowing
-j32 was unreliable for the rerun. (Despite that early report.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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: btxld not found

[Toomas Soome]

> On 28. Jan 2020, at 18:08, Nick Hibma  wrote:
> 
> 
>> On Tue, Jan 28, 2020, 4:57 AM Nick Hibma > > wrote:
>> > On 28/01 /2020, at 12:39, Toomas Soome > > > wrote:
>> > 
>> >> On 28. Jan 2020, at 13:36, Nick Hibma > >> > wrote:
>> >> 
>> >> Folks,
>> >> 
>> >> Could anyone explain to me what I am doing wrong? make installworld fails 
>> >> each time with the following error
>> >> 
>> >> ===> stand/i386/libi386 (install)
>> >> ===> stand/i386/loader_4th (install)
>> >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
>> >> btxld -v -f aout -e 0x20 -o loader_4th -l 
>> >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
>> >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
>> >> make[6]: exec(btxld) failed (No such file or directory)
>> >> *** Error code 1
>> >> 
>> >> This is with source of last week. I had this problem before (from old 
>> >> sources) and fixed it by specifying the full path to btxld in the 
>> >> stand/i386/*/Makefile. 
>> >> 
>> >> Any pointers?
>> >> 
>> > 
>> > it should be /usr/sbin/btxld; are you missing /usr/sbin from the path?
>> 
>> Well, it's an 'installworld' so I would expect it to be providing that 
>> program itself, but no, /usr/sbin/ is in the path of the current shell.
>> 
>> Also, in some of the makefiles the target calling btxldr is depending on the 
>> build of that executable:
>> 
>> Index: stand/i386/pxeldr/Makefile
>> ===
>> --- stand/i386/pxeldr/Makefile  (revision 357042)
>> +++ stand/i386/pxeldr/Makefile  (working copy)
>> @@ -39,7 +39,7 @@
>>  CLEANFILES+= ${LOADER}
>> 
>>  ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN}
>> -   btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l ${BTXLDR} \
>> +   /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l 
>> ${BTXLDR} \
>> -b ${BTXKERN} ${LOADERBIN}
>> 
>> This is definitely wrong. We have either a path that is wrong, or we aren't 
>> reinstalling btxld in the right place.
>> 
>> Warner
> 
> This is not a fix, this is to get me through the installworld. As I've not 
> seen any mention of this the past 6 months it must be something on my system 
> that makes things go bad, but I have no idea what.
> 
> They are being built, and installed:
> 
> {e}nick@fimkjecurrent:/usr/src/stand/i386/btx % find / -name btxld -ls
> 1908308   48 -r-xr-xr-x1 root wheel   
> 22988 Jan 27 23:37 /usr/sbin/btxld
> 13190104 drwxr-xr-x2 nick nick
>   512 Sep 15  2017 /usr/src/usr.sbin/btxld
> 33695644 drwxrwxr-x2 root wheel   
>   512 Jan 27 22:33 
> /usr/obj/usr/src/i386.i386/usr.sbin/btxld
> 3371323   52 -rwxr-xr-x1 root wheel   
> 25816 Jan 27 22:33 
> /usr/obj/usr/src/i386.i386/usr.sbin/btxld/btxld
> 
> I guess the difference in file size is due to it being stripped during 
> install?
> 
> Nick

why it is installed into directory: /usr/obj/usr/src/i386.i386/usr.sbin/btxld ? 

rgds,
toomas

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

Emacs tramp mode doesn't work with CURRENT

[John F Carr]

I use emacs tramp mode, which opens an ssh connection to a remote machine for 
file access.  It works to Linux and FreeBSD 12.1, but not to CURRENT.  There 
has been a change in the way characters are echoed by the shell, with 12.1 
treating a consecutive run of backspace as an atomic unit and CURRENT 
processing them one at a time.  This is not necessarily a bug, but it is a 
nuisance and independently it is suboptimal.

I would like to blame libedit, which changed since 12.1.  I didn't see any 
changes in pty code and the problem happens with at least two different shells. 
 It could also be caused by a change to sshd or something I haven't through of.

Here is a longer explanation.

Emacs tramp mode opens an ssh connection to a remote machine.  It doesn't want 
to see input echoed back so it runs

stty -inlcr -onlcr -echo kill '^U' erase '^H'

This doesn't do anything useful if a shell is running in line editing mode 
(raw) instead of using the tty (cooked).  So tramp falls back to a hack to 
detect echoed input.  It sends "_echo" followed by a string of backspace 
characters.  "_echo" is unlikely to appear in program output.

Here is the next command after the initial stty:

_echo^H^H^H^H^Hstty icanon erase ^H cols 32767_echo^H^H^H^H^H

The groups of 5 ^H represent 5 backspace characters and the lone ^H in the 
middle is a two character sequence for stty.

The terminal output from a 12.1 system is

_echo^H ^H^H ^H^H ^H^H ^H^H ^Hstty icanon erase ^H cols 32767_echo^H ^H^H ^H^H 
^H^H ^H^H ^H
#$ 

where again the middle ^H is a two character sequence and the others are 
backspace characters.  There is a carriage return between the two lines.  "#$ " 
is the shell prompt set by tramp.

The terminal output from a CURRENT system is

_echo
#$ _ech ^H
#$ _ec ^H
#$ _e ^H
#$ _ ^H
#$  ^Hstty icanon erase ^H cols 32767_echo
#$ stty icanon erase ^H cols 32767_ech ^H
#$ stty icanon erase ^H cols 32767_ec ^H
#$ stty icanon erase ^H cols 32767_e ^H
#$ stty icanon erase ^H cols 32767_ ^H
#$ stty icanon erase ^H cols 32767 ^H
#$ 

with carriage returns between lines.  This does not make sense to emacs.

I tried both /bin/sh and /bin/csh as shells and tramp didn't work with either.  
I put set +V and set +E in my .profile thinking that would turn off line 
editing but there was no change.  Probably the shell still takes raw input.

A possible complicating factor is the CURRENT machines are both 64 bit ARM and 
the 12.1 machine is amd64.  One has unsigned characters, the other signed.  
Shouldn't matter, but I haven't tried 12.1 on ARM so I can't swear it works.
___
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: btxld not found

[Ian Lepore]

On Tue, 2020-01-28 at 17:08 +0100, Nick Hibma wrote:
> > On Tue, Jan 28, 2020, 4:57 AM Nick Hibma  > > wrote:
> > > On 28/01 /2020, at 12:39, Toomas Soome  > > tso...@me.com>> wrote:
> > > 
> > > > On 28. Jan 2020, at 13:36, Nick Hibma  > > > > wrote:
> > > > 
> > > > Folks,
> > > > 
> > > > Could anyone explain to me what I am doing wrong? make
> > > > installworld fails each time with the following error
> > > > 
> > > > ===> stand/i386/libi386 (install)
> > > > ===> stand/i386/loader_4th (install)
> > > > strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
> > > > btxld -v -f aout -e 0x20 -o loader_4th -l
> > > > /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b
> > > > /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx
> > > > loader_4th.bin
> > > > make[6]: exec(btxld) failed (No such file or directory)
> > > > *** Error code 1
> > > > 
> > > > This is with source of last week. I had this problem before
> > > > (from old sources) and fixed it by specifying the full path to
> > > > btxld in the stand/i386/*/Makefile. 
> > > > 
> > > > Any pointers?
> > > > 
> > > 
> > > it should be /usr/sbin/btxld; are you missing /usr/sbin from the
> > > path?
> > 
> > Well, it's an 'installworld' so I would expect it to be providing
> > that program itself, but no, /usr/sbin/ is in the path of the
> > current shell.
> > 
> > Also, in some of the makefiles the target calling btxldr is
> > depending on the build of that executable:
> > 
> > Index: stand/i386/pxeldr/Makefile
> > ===
> > --- stand/i386/pxeldr/Makefile  (revision 357042)
> > +++ stand/i386/pxeldr/Makefile  (working copy)
> > @@ -39,7 +39,7 @@
> >  CLEANFILES+= ${LOADER}
> > 
> >  ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN}
> > -   btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l
> > ${BTXLDR} \
> > +   /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o
> > ${.TARGET} -l ${BTXLDR} \
> > -b ${BTXKERN} ${LOADERBIN}
> > 
> > This is definitely wrong. We have either a path that is wrong, or
> > we aren't reinstalling btxld in the right place.
> > 
> > Warner
> 
> This is not a fix, this is to get me through the installworld. As
> I've not seen any mention of this the past 6 months it must be
> something on my system that makes things go bad, but I have no idea
> what.
> 
> They are being built, and installed:
> 
> {e}nick@fimkjecurrent:/usr/src/stand/i386/btx % find / -name btxld
> -ls
> 1908308   48 -r-xr-xr-x1
> root wheel   
> 22988 Jan 27 23:37 /usr/sbin/btxld
> 13190104 drwxr-xr-x2
> nick nick
>   512 Sep 15  2017 /usr/src/usr.sbin/btxld
> 33695644 drwxrwxr-x2
> root wheel   
>   512 Jan 27 22:33 /usr/obj/usr/src/i386.i386/usr.sbin/btxld
> 3371323   52 -rwxr-xr-x1
> root wheel   
> 25816 Jan 27 22:33 /usr/obj/usr/src/i386.i386/usr.sbin/btxld/btxld
> 
> I guess the difference in file size is due to it being stripped
> during install?
> 
> Nick

I would expect the one that gets used during make install to be in the
objdir/.../tmp/usr/sbin directory, like other build and install tools.

But oddly, I don't have btxld in tmp for amd64 builds, only for i386.

-- Ian


___
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: btxld not found

[Nick Hibma]

> On Tue, Jan 28, 2020, 4:57 AM Nick Hibma  > wrote:
> > On 28/01 /2020, at 12:39, Toomas Soome  > > wrote:
> > 
> >> On 28. Jan 2020, at 13:36, Nick Hibma  >> > wrote:
> >> 
> >> Folks,
> >> 
> >> Could anyone explain to me what I am doing wrong? make installworld fails 
> >> each time with the following error
> >> 
> >> ===> stand/i386/libi386 (install)
> >> ===> stand/i386/loader_4th (install)
> >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
> >> btxld -v -f aout -e 0x20 -o loader_4th -l 
> >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
> >> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
> >> make[6]: exec(btxld) failed (No such file or directory)
> >> *** Error code 1
> >> 
> >> This is with source of last week. I had this problem before (from old 
> >> sources) and fixed it by specifying the full path to btxld in the 
> >> stand/i386/*/Makefile. 
> >> 
> >> Any pointers?
> >> 
> > 
> > it should be /usr/sbin/btxld; are you missing /usr/sbin from the path?
> 
> Well, it's an 'installworld' so I would expect it to be providing that 
> program itself, but no, /usr/sbin/ is in the path of the current shell.
> 
> Also, in some of the makefiles the target calling btxldr is depending on the 
> build of that executable:
> 
> Index: stand/i386/pxeldr/Makefile
> ===
> --- stand/i386/pxeldr/Makefile  (revision 357042)
> +++ stand/i386/pxeldr/Makefile  (working copy)
> @@ -39,7 +39,7 @@
>  CLEANFILES+= ${LOADER}
> 
>  ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN}
> -   btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l ${BTXLDR} \
> +   /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l 
> ${BTXLDR} \
> -b ${BTXKERN} ${LOADERBIN}
> 
> This is definitely wrong. We have either a path that is wrong, or we aren't 
> reinstalling btxld in the right place.
> 
> Warner

This is not a fix, this is to get me through the installworld. As I've not seen 
any mention of this the past 6 months it must be something on my system that 
makes things go bad, but I have no idea what.

They are being built, and installed:

{e}nick@fimkjecurrent:/usr/src/stand/i386/btx % find / -name btxld -ls
1908308   48 -r-xr-xr-x1 root wheel 
  22988 Jan 27 23:37 /usr/sbin/btxld
13190104 drwxr-xr-x2 nick nick  
512 Sep 15  2017 /usr/src/usr.sbin/btxld
33695644 drwxrwxr-x2 root wheel 
512 Jan 27 22:33 
/usr/obj/usr/src/i386.i386/usr.sbin/btxld
3371323   52 -rwxr-xr-x1 root wheel 
  25816 Jan 27 22:33 
/usr/obj/usr/src/i386.i386/usr.sbin/btxld/btxld

I guess the difference in file size is due to it being stripped during install?

Nick
___
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: btxld not found

[Warner Losh]

On Tue, Jan 28, 2020, 4:57 AM Nick Hibma  wrote:

> > On 28/01 /2020, at 12:39, Toomas Soome  wrote:
> >
> >> On 28. Jan 2020, at 13:36, Nick Hibma  wrote:
> >>
> >> Folks,
> >>
> >> Could anyone explain to me what I am doing wrong? make installworld
> fails each time with the following error
> >>
> >> ===> stand/i386/libi386 (install)
> >> ===> stand/i386/loader_4th (install)
> >> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
> >> btxld -v -f aout -e 0x20 -o loader_4th -l
> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b
> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
> >> make[6]: exec(btxld) failed (No such file or directory)
> >> *** Error code 1
> >>
> >> This is with source of last week. I had this problem before (from old
> sources) and fixed it by specifying the full path to btxld in the
> stand/i386/*/Makefile.
> >>
> >> Any pointers?
> >>
> >
> > it should be /usr/sbin/btxld; are you missing /usr/sbin from the path?
>
> Well, it's an 'installworld' so I would expect it to be providing that
> program itself, but no, /usr/sbin/ is in the path of the current shell.
>
> Also, in some of the makefiles the target calling btxldr is depending on
> the build of that executable:
>
> Index: stand/i386/pxeldr/Makefile
> ===
> --- stand/i386/pxeldr/Makefile  (revision 357042)
> +++ stand/i386/pxeldr/Makefile  (working copy)
> @@ -39,7 +39,7 @@
>  CLEANFILES+= ${LOADER}
>
>  ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN}
> -   btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l ${BTXLDR} \
> +   /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l
> ${BTXLDR} \
> -b ${BTXKERN} ${LOADERBIN}
>

This is definitely wrong. We have either a path that is wrong, or we aren't
reinstalling btxld in the right place.

Warner


Nick
> ___
> 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"
>
___
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: btxld not found

[Nick Hibma]

> On 28/01 /2020, at 12:39, Toomas Soome  wrote:
> 
>> On 28. Jan 2020, at 13:36, Nick Hibma  wrote:
>> 
>> Folks,
>> 
>> Could anyone explain to me what I am doing wrong? make installworld fails 
>> each time with the following error
>> 
>> ===> stand/i386/libi386 (install)
>> ===> stand/i386/loader_4th (install)
>> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
>> btxld -v -f aout -e 0x20 -o loader_4th -l 
>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
>> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
>> make[6]: exec(btxld) failed (No such file or directory)
>> *** Error code 1
>> 
>> This is with source of last week. I had this problem before (from old 
>> sources) and fixed it by specifying the full path to btxld in the 
>> stand/i386/*/Makefile. 
>> 
>> Any pointers?
>> 
> 
> it should be /usr/sbin/btxld; are you missing /usr/sbin from the path?

Well, it's an 'installworld' so I would expect it to be providing that program 
itself, but no, /usr/sbin/ is in the path of the current shell.

Also, in some of the makefiles the target calling btxldr is depending on the 
build of that executable:

Index: stand/i386/pxeldr/Makefile
===
--- stand/i386/pxeldr/Makefile  (revision 357042)
+++ stand/i386/pxeldr/Makefile  (working copy)
@@ -39,7 +39,7 @@
 CLEANFILES+= ${LOADER}

 ${LOADER}: ${LOADERBIN} ${BTXLDR} ${BTXKERN}
-   btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l ${BTXLDR} \
+   /usr/sbin/btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l 
${BTXLDR} \
-b ${BTXKERN} ${LOADERBIN}


Nick
___
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: btxld not found

[Marek Zarychta]

W dniu 28.01.2020 o 12:36, Nick Hibma pisze:
> Folks,
>
> Could anyone explain to me what I am doing wrong? make installworld fails 
> each time with the following error
>
> ===> stand/i386/libi386 (install)
> ===> stand/i386/loader_4th (install)
> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
> btxld -v -f aout -e 0x20 -o loader_4th -l 
> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
> make[6]: exec(btxld) failed (No such file or directory)
> *** Error code 1
>
> This is with source of last week. I had this problem before (from old 
> sources) and fixed it by specifying the full path to btxld in the 
> stand/i386/*/Makefile. 
>
> Any pointers?
>
> Nick Hibma
> n...@van-laarhoven.org
>
> -- Open Source: We stand on the shoulders of giants.
>  

I am experiencing also the same issue on CURRENT for some time (a few
months). Removing /usr/src and fresh checkout solved the issue for a
while but it returned soon. I am not to complain here but to confirm
that it happens.

Best regards,

-- 
Marek Zarychta




signature.asc
Description: OpenPGP digital signature

Re: btxld not found

[Toomas Soome]

> On 28. Jan 2020, at 13:36, Nick Hibma  wrote:
> 
> Folks,
> 
> Could anyone explain to me what I am doing wrong? make installworld fails 
> each time with the following error
> 
> ===> stand/i386/libi386 (install)
> ===> stand/i386/loader_4th (install)
> strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
> btxld -v -f aout -e 0x20 -o loader_4th -l 
> /usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
> /usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
> make[6]: exec(btxld) failed (No such file or directory)
> *** Error code 1
> 
> This is with source of last week. I had this problem before (from old 
> sources) and fixed it by specifying the full path to btxld in the 
> stand/i386/*/Makefile. 
> 
> Any pointers?
> 

it should be /usr/sbin/btxld; are you missing /usr/sbin from the path?

rgds,
toomas

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

btxld not found

[Nick Hibma]

Folks,

Could anyone explain to me what I am doing wrong? make installworld fails each 
time with the following error

===> stand/i386/libi386 (install)
===> stand/i386/loader_4th (install)
strip -R .comment -R .note -o loader_4th.bin loader_4th.sym
btxld -v -f aout -e 0x20 -o loader_4th -l 
/usr/obj/usr/src/i386.i386/stand/i386/btx/btxldr/btxldr  -b 
/usr/obj/usr/src/i386.i386/stand/i386/btx/btx/btx loader_4th.bin
make[6]: exec(btxld) failed (No such file or directory)
*** Error code 1

This is with source of last week. I had this problem before (from old sources) 
and fixed it by specifying the full path to btxld in the stand/i386/*/Makefile. 

Any pointers?

Nick Hibma
n...@van-laarhoven.org

-- Open Source: We stand on the shoulders of giants.



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

[HEADS UP] EPOCH breakage in [USB/PCI] network drivers after r357004

[Hans Petter Selasky]

Hi,

Currently 8 of 10 USB WLAN drivers are broken and multiple PCI ones too. 
I have some patches, which I would like to have more attention that try 
to address these issues. The patches are currently being worked on.


1) https://reviews.freebsd.org/D23348
2) https://reviews.freebsd.org/D23347

If you have some comments please sign up!

I hope all issues will be addressed by end of week.

--HPS


___
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: OOMA kill with vm.pfault_oom_attempts="-1" on RPi3 at r357147

[Mark Millard]

On 2020-Jan-27, at 21:29, Mark Millard  wrote:

> On 2020-Jan-27, at 19:53, bob prohaska  wrote:
> 
>> On Mon, Jan 27, 2020 at 06:22:20PM -0800, Mark Millard wrote:
>>> 
>>> So far as I know, in the past progress was only made when someone
>>> already knowledgable got involved in isolating what was happening
>>> and how to control it.
>>> 
>> Indeed. One can only hope said knowledgeables are reading
> 
> May be I can suggest something that might kick-start
> evidence gathering a little bit: add 4 unconditional
> printf's to the kernel code, each just before one of
> the vm_pageout_oom(. . .) calls. Have the message
> uniquely identify which of the 4 it is before.
> 
> . . .

Below is a stab at implementing the suggestion. A couple of
the printf's are basically what Mark Johnston supplied
long ago. (Other code from what he supplied back then did
not survive updates made to FreeBSD.) One of his printf's
is not tied to indicating vm_pageout_oom use.

(Sent this way some whitespace might not be preserved.)

# svnlite diff /usr/src/sys/vm/ 
Index: /usr/src/sys/vm/swap_pager.c
===
--- /usr/src/sys/vm/swap_pager.c(revision 356426)
+++ /usr/src/sys/vm/swap_pager.c(working copy)
@@ -2021,6 +2021,7 @@
0, 1))
printf("swap blk zone exhausted, "
"increase kern.maxswzone\n");
+   printf("swp_pager_meta_build: swap blk uma zone 
exhausted\n");
vm_pageout_oom(VM_OOM_SWAPZ);
pause("swzonxb", 10);
} else
@@ -2051,6 +2052,7 @@
0, 1))
printf("swap pctrie zone exhausted, "
"increase kern.maxswzone\n");
+   printf("swp_pager_meta_build: swap pctrie uma 
zone exhausted\n");
vm_pageout_oom(VM_OOM_SWAPZ);
pause("swzonxp", 10);
} else
Index: /usr/src/sys/vm/vm_fault.c
===
--- /usr/src/sys/vm/vm_fault.c  (revision 356426)
+++ /usr/src/sys/vm/vm_fault.c  (working copy)
@@ -943,9 +943,9 @@
vm_pfault_oom_wait * hz);
goto RetryFault_oom;
}
-   if (bootverbose)
+   // HAVE PRINTF BE UNCONDITIONAL FOR TESTING: if 
(bootverbose)
printf(
-   "proc %d (%s) failed to alloc page on fault, starting OOM\n",
+   "vm_fault: proc %d (%s) failed to alloc page on fault, starting OOM\n",
curproc->p_pid, curproc->p_comm);
vm_pageout_oom(VM_OOM_MEM_PF);
goto RetryFault;
Index: /usr/src/sys/vm/vm_page.c
===
--- /usr/src/sys/vm/vm_page.c   (revision 356426)
+++ /usr/src/sys/vm/vm_page.c   (working copy)
@@ -3139,6 +3139,7 @@
 * race-free vm_wait_domain().
 */
if (curproc == pageproc) {
+   printf("thread %d waiting for memory\n", curthread->td_tid);
mtx_lock(_domainset_lock);
vm_pageproc_waiters++;
msleep(_pageproc_waiters, _domainset_lock, PVM | PDROP,
Index: /usr/src/sys/vm/vm_pageout.c
===
--- /usr/src/sys/vm/vm_pageout.c(revision 356426)
+++ /usr/src/sys/vm/vm_pageout.c(working copy)
@@ -1741,6 +1741,8 @@
 * start OOM.  Initiate the selection and signaling of the
 * victim.
 */
+   printf("vm_pageout_mightbe_oom: kill context: v_free_count: %u, 
v_inactive_count: %u\n",
+   vmd->vmd_free_count, vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt);
vm_pageout_oom(VM_OOM_MEM);
 
/*
@@ -1933,10 +1935,24 @@
}
sx_sunlock(_lock);
if (bigproc != NULL) {
+   char *reason_text;
+   switch (shortage) {
+   case VM_OOM_MEM_PF:
+   reason_text= "fault's page allocation failed";
+   break;
+   case VM_OOM_MEM:
+   reason_text= "free RAM stayed below threshold";
+   break;
+   case VM_OOM_SWAPZ:
+   reason_text= "swblk or swpctrie zone exhausted";
+   break;
+   default:
+   reason_text= "Unknown Reason";
+   }
if (vm_panic_on_oom != 0)
-   panic("out of swap space");
+