Mbufs leak since r321253
Hello, While running some port builds over an NFS-mounted /usr/ports on my aarch64 VM after r321253, I've noticed that sooner or later I'm getting an error saying "kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached". I've tried increasing the sysctl, but after some time I always got the error. I've checked the mbuf counter with ``netstat -m'' periodically during the build, and noticed that the mbufs in use and mbuf clusters in use are continuously increasing, I've never seen a decrease: 279943/392/280335 mbufs in use (current/cache/total) 130819/253/131072/131072 mbuf clusters in use (current/cache/total/max) According to https://svnweb.freebsd.org/base/head/?view=log=321253, the previous commit to HEAD was r321248. I've checked it on that build as well, and I couldn't reproduce the issue, mbuf counters were stable. After getting the kernel error message, the builds got stuck, some processes become unresponsive, and the only way to I was aware to clear the mbufs was to reboot the VM. So far what I know, is building over NFS triggers the leak. However, I haven't tested it with other network activities, might also do the trick. Could you please take a look into it? If any more information is needed, please let me know, I still have my test VMs at hand, I can do a few tests. Best regards, Gergely ___ 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"
strip: elf_strptr failed: Invalid argument
Hello, I'm trying to build packages on an rpi3, on a freshly build image (with crochet), and when it's trying to build pkg from ports, I'm getting the following error message: libtool: link: cc -D_BSD_SOURCE -I../libpkg -I../libpkg -I../compat -I../external/libucl/klib -I../external/uthash -I../external/expat/lib -DGITHASH=\"\" -O2 -pipe -Wno-error -fno-strict-aliasing -Wall -Wno-unused-function -D_BSD_SOURCE -DINET6=1 -Wl,--enable-new-dtags -o .libs/pkg pkg-add.o pkg-alias.o pkg-annotate.o pkg-audit.o pkg-autoremove.o pkg-backup.o pkg-check.o pkg-clean.o pkg-config.o pkg-convert.o pkg-create.o pkg-delete.o pkg-event.o pkg-fetch.o pkg-globals.o pkg-info.o pkg-install.o pkg-lock.o pkg-main.o pkg-plugins.o pkg-query.o pkg-register.o pkg-repo.o pkg-rquery.o pkg-search.o pkg-set.o pkg-shell.o pkg-shlib.o pkg-ssh.o pkg-stats.o pkg-update.o pkg-updating.o pkg-upgrade.o pkg-utils.o pkg-version.o pkg-which.o ../libpkg/.libs/libpkg.so ../compat/.libs/libbsd_compat.a -lutil -lssl -lcrypto -lm -lelf -ljail -larchive -lz -lbz2 -llzma -Wl,-rpath -Wl,/usr/local/lib /bin/mkdir -p '/usr/ports/ports-mgmt/pkg/work/stage/usr/local/etc' install -m 0644 pkg.conf.sample '/usr/ports/ports-mgmt/pkg/work/stage/usr/local/etc' /bin/mkdir -p '/usr/ports/ports-mgmt/pkg/work/stage/usr/local/sbin' STRIPPROG='strip' /bin/sh ../libtool --mode=install /bin/sh /usr/ports/ports-mgmt/pkg/work/pkg-1.10.1/install-sh -c -s pkg-static pkg '/usr/ports/ports-mgmt/pkg/work/stage/usr/local/sbin' libtool: install: /bin/sh /usr/ports/ports-mgmt/pkg/work/pkg-1.10.1/install-sh -c -s pkg-static /usr/ports/ports-mgmt/pkg/work/stage/usr/local/sbin/pkg-static strip: elf_strptr failed: Invalid argument *** Error code 1 Stop. make[5]: stopped in /usr/ports/ports-mgmt/pkg/work/pkg-1.10.1/src *** Error code 1 Strange part, it says it's stripped already: root@build:/usr/ports/ports-mgmt/pkg # file -s ./work/pkg-1.10.1/src/pkg-static ./work/pkg-1.10.1/src/pkg-static: ELF 64-bit LSB executable, ARM aarch64, version 1 (FreeBSD), statically linked, stripped However, trying to strip(1) manually reproduces the error: # strip ~/pkg-static.1 strip: elf_strptr failed: Invalid argument ktrace didn't reveal anything about the failing elf_strptr(3) call. The system is: FreeBSD build.aegir 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320657: Tue Jul 4 22:28:33 CEST 2017 ae...@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64.aarch64/tank/rpi3/src/sys/AEGIR arm64 Could someone please help me with this? I don't really know how to solve this, or where to start looking. Usually building pkg works out of box. Best regards, Gergely ___ 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"
RPi3 booting issues: vm_fault pager read error pid 1
Hello, I would like to ask for some help. I'm trying to build a freebsd image using crochet, however recent builds, since roughly march, are failing to boot on an RPi3. Currently once the kernel boots up and hands it over to init, the error message "vm_fault pager read error pid 1 (init)" is flooding the screen. Sadly, I don't really know how to debug and fix the cause of this, and I would like to ask some help on fixing this. The image I'm trying to boot (if boots, u/p aegir:aegir): http://czg.harmless.hu/aegir/FreeBSD-aarch64-12.0-AEGIR-317411.img.gz The kernel config: http://czg.harmless.hu/aegir/AEGIR And the crochet config I'm using: http://czg.harmless.hu/aegir/aegir.sh I would like to have a refreshed build, because the one I'm using currently does not have working i2c support, which should be the next thing on my project I'm using this for. Would be nice if someone could take a look into this. Best regards, Gergely ___ 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: process killed: text file modification
On 2017. 03. 21. 3:40, Rick Macklem wrote: Gergely Czuczy wrote: [stuff snipped] Actually I want to test it, but you guys are so vehemently discussing it, I thought it would be better to do so, once you guys settled your analysis on the code. Also, me not having the problem occurring, I don't think would mean it's solved, since that would only mean, the codepath for my specific usecase works. There might be other things there as well, what I don't hit. I hope by vehemently, you didn't find my comments as nasty. If they did come out that way, it was not what I intended and I apologize. Let me know which patch should I test, and I will see to it in the next couple of days, when I get the time to do it. I've attached it here again and, yes, I would agree that the results you get from testing are just another data point and not definitive. (I'd say this statement is true of all testing of nontrivial code.) Thanks in advance for any testing you can do, rick So, I've copied the patched kernel over, and apparently it's working properly. I'm not getting the error anymore. So far I've only did a quick test, should I do something more extensive, like build a couple of ports or something over NFS? ___ 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: process killed: text file modification
On 2017. 03. 21. 3:40, Rick Macklem wrote: Gergely Czuczy wrote: [stuff snipped] Actually I want to test it, but you guys are so vehemently discussing it, I thought it would be better to do so, once you guys settled your analysis on the code. Also, me not having the problem occurring, I don't think would mean it's solved, since that would only mean, the codepath for my specific usecase works. There might be other things there as well, what I don't hit. I hope by vehemently, you didn't find my comments as nasty. If they did come out that way, it was not what I intended and I apologize. Let me know which patch should I test, and I will see to it in the next couple of days, when I get the time to do it. I've attached it here again and, yes, I would agree that the results you get from testing are just another data point and not definitive. (I'd say this statement is true of all testing of nontrivial code.) Thanks in advance for any testing you can do, rick I finally had the time to give it a go, but unfortunately there was something wrong with the built image, it was unable to find the root device during boot. I will try to just copy the kernel over a bit later, and see how it goes. I hope there are no ABI changes between the two revisions (the previously built world, and the patched kernel). ___ 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: process killed: text file modification
On 2017. 03. 21. 3:40, Rick Macklem wrote: Gergely Czuczy wrote: [stuff snipped] Actually I want to test it, but you guys are so vehemently discussing it, I thought it would be better to do so, once you guys settled your analysis on the code. Also, me not having the problem occurring, I don't think would mean it's solved, since that would only mean, the codepath for my specific usecase works. There might be other things there as well, what I don't hit. I hope by vehemently, you didn't find my comments as nasty. If they did come out that way, it was not what I intended and I apologize. Oh, totally not. I barely meant that you guys are right in the middle of the technical discussion, and it doesn't seemed settled. Let me know which patch should I test, and I will see to it in the next couple of days, when I get the time to do it. I've attached it here again and, yes, I would agree that the results you get from testing are just another data point and not definitive. (I'd say this statement is true of all testing of nontrivial code.) Thanks in advance for any testing you can do, rick Updated the tree and the patch has applied: # patch < /home/phoemix/textmod.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- fs/nfsclient/nfs_clvnops.c.text2017-03-16 21:55:16.263393000 -0400 |+++ fs/nfsclient/nfs_clvnops.c 2017-03-17 09:31:23.632814000 -0400 -- Patching file fs/nfsclient/nfs_clvnops.c using Plan A... Hunk #1 succeeded at 140. Hunk #2 succeeded at 177. Hunk #3 succeeded at 3375. done When I'm back home from work, I will check the build out, and see how it goes. And thank you very much guys for working on fixing this one. -czg ___ 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: process killed: text file modification
On 2017. 03. 19. 21:52, Rick Macklem wrote:
Kostik wrote:
[stuff snipped]
Dirty pages are flushed by writes, so if we have a set of dirty pages and
async vm_object_page_clean() is called on the vnode' vm_object, we get
a bunch of delayed-write AKA dirty buffers. This is possible even after
VOP_CLOSE() was done, e.g. by syncer performing regular run involving
vfs_msync().
When I was talking about ncl_flush() above, I was referring to buffer cache
buffers written by a write(2) syscall, not the case of mmap'd pages.
But dirty buffers can appear on the vnode queue due to dirty pages msyncing
by syncer, for instance.
Ok, just to clarify this, in case I don't understand it...
- You aren't saying that anything will be added to v_bufobj.bo_dirty.bv_hd by
vfs_msync() or similar, after VOP_CLOSE(), right?
--> ncl_flush() { was called nfs_flush() in the old NFS client } only deals with
"struct buf's" hanging off v_bufobj.bo_dirty.bv_hd, so I don't see a use
for
it in the patch.
As for pages added to v_bufobj.bo_object...the patch assumes that the process
that was writing the executable file mmap'd is done { normally exited } before
the exec() syscall occurs. If it is still dirtying pages when the exec()
occurs, then
failing with "Text file modified" seems correct to me. As you mentioned, another
client can do this to the file anyhow.
My understanding is that vm_object_page_clean() will get all the dirty pages
written
back to the server at that point and if that is done in VOP_SET_TEXT() as this
patch
does, what more can the NFS client do?
[more stuff snipped]
Syncer does not open the vnode inside the vfs_msync() operations.
Ok, but this doesn't put "struct buf's" on v_bufobj.bo_dirty.bv_hd. Am I right?
(When I said "buffers". I meant "struct buf's" under bo_dirty, not stuff under
v_bufobj.bo_object.)
We do track writeability to the file, and do not allow execution if there is
an active writer, be it a file descriptor opened for write, or a writeable
mapping. And in reverse, if the file is executed (VV_TEXT is set), then
we disallow opening the file for write.
Yes, and that was why I figured doing this in VOP_SET_TEXT(), just before
setting VV_TEXT, was the right place to do it.
[more stuff snipped]
Thanks for testing the patch. Now, if others can test it...rick
Again, hopefully others (especially the original reporter) will be able to
test the patch, rick
Actually I want to test it, but you guys are so vehemently discussing
it, I thought it would be better to do so, once you guys settled your
analysis on the code. Also, me not having the problem occurring, I don't
think would mean it's solved, since that would only mean, the codepath
for my specific usecase works. There might be other things there as
well, what I don't hit.
Let me know which patch should I test, and I will see to it in the next
couple of days, when I get the time to do it.
Regards,
-czg
___
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: process killed: text file modification
On 2017. 03. 09. 20:47, Gergely Czuczy wrote:
On 2017. 03. 09. 19:44, John Baldwin wrote:
On Thursday, March 09, 2017 03:31:56 PM Gergely Czuczy wrote:
[+freebsd-fs]
On 2017. 03. 09. 14:20, Gergely Czuczy wrote:
On 2017. 03. 09. 11:27, Gergely Czuczy wrote:
Hello,
I'm trying to build a few things from ports on an rpi3, the ports
collection is mounted over NFS from another machine. When it's trying
to build pkg i'm getting the error message in syslog:
rpi3 kernel: pid 4451 (sh), uid 0, was killed: text file modification
The report to pkg@:
https://lists.freebsd.org/pipermail/freebsd-pkg/2017-March/002048.html
In ports-mgmt/pkg's config.log It fails at the following entry:
configure:3726: checking whether we are cross compiling
configure:3734: cc -o conftest -O2 -pipe -Wno-error
-fno-strict-aliasing conftest.c >&5
configure:3738: $? = 0
configure:3745: ./conftest
configure:3749: $? = 137
configure:3756: error: in
`/usr/ports/ports-mgmt/pkg/work/pkg-1.10.0':
configure:3760: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
# uname -a
FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314949: Thu Mar 9
08:58:46 CET 2017
ae...@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64.aarch64/tank/rpi3/src/sys/AEGIR
arm64
So far, a few additions:
Time is synced between the NFS server and the client.
it's an open() call which is getting the kill, and it's not the file
what's being opened, but the process executing it.
Here's a simple code that reproduces it:
#include
int main() {
FILE *f = fopen ("/bar", "w");
fclose(f);
return 0;
}
Conditions to reproduce it:
- The resulting binary must be executed from the nfs mount
- The binary must be built after mounting the NFS share.
I haven't tried building it on a different host, I don't have access
to multiple RPis. Also, if I build the binary, umount/remount the NFS
mount point, which has the binary, execute it, then it works.
I've also tried this with the raspbsd.org's image, I could reproduce
it as well.
Another interesting thing is, when I first booted the RPi up, the NFS
server was a 10.2-STABLE, and later got updated to 11-STABLE. While it
was 10.2 I've tried to build some port, and I don't remember having
this issue.
So, could someone please help me figure this out and fix it? This
stuff should work pretty much.
So, this error message comes from here:
https://svnweb.freebsd.org/base/head/sys/fs/nfsclient/nfs_clbio.c?revision=314436=markup#l1674
It's the NFS_TIMESPEC_COMPARE(>n_mtime, >n_vattr.na_mtime)
comparision that fails, np should be the NFS node structure, from the
vnode's v_data, and n_vattr is the attribute cache. As I've seen these
two are being updated together, so I don't really see by the code why
they might differ. Could someone please take a look at it, with more
experience in the NFS code? -czg
Can you print out the two mtimes? I wonder if what's happening is that
your server uses different granularity (for example just seconds) than
your client, so on the client we generate a timestamp with a non-zero
nanoseconds but when the server receives that timestamp it "truncates"
it. During open() we forcefully re-fetch the timestamp (for CTO
consistency) and then notice it doesn't match. For now I would start
with comparing the timestamps and maybe the vfs.timestamp_precision
sysctls on client and server (if server is a FreeBSD box).
Here are the time values:
Mar 9 19:46:01 rpi3 kernel: np->n_mtime: -3298114786344 +
-3298114786336 >n_vattr.na_mtime: -3298114786616 + -3298114786608
Mar 9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed: text
file modification
Mar 9 19:46:01 rpi3 kernel: np->n_mtime: -3298114786344 +
-3298114786336 >n_vattr.na_mtime: -3298114786616 + -3298114786608
Mar 9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed: text
file modification
Printed this way:
printf("np->n_mtime: %ji + %ji
>n_vattr.na_mtime: %ji + %ji",
(intmax_t)(>n_mtime.tv_sec),
(intmax_t)(>n_mtime.tv_nsec),
(intmax_t)(>n_vattr.na_mtime.tv_sec),
(intmax_t)(>n_vattr.na_mtime.tv_nsec));
Sorry, I made a typo there. Here's it now:
Mar 9 20:05:35 rpi3 kernel: np->n_mtime: 1489089935 + 219323000
>n_vattr.na_mtime: 1489089935 + 221438000
Mar 9 20:05:35 rpi3 kernel: pid 847 (csh), uid 0, was killed: text file
modification
Mar 9 20:05:35 rpi3 kernel: np->n_mtime: 1489089935 + 219323000
>n_vattr.na_mtime: 1489089935 + 221438000
Mar 9 20:05:35 rpi3 kernel: pid 847 (csh), uid 0, was killed: text file
modification
That's a difference of 2115 micro seconds.
___
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: process killed: text file modification
On 2017. 03. 09. 19:44, John Baldwin wrote:
On Thursday, March 09, 2017 03:31:56 PM Gergely Czuczy wrote:
[+freebsd-fs]
On 2017. 03. 09. 14:20, Gergely Czuczy wrote:
On 2017. 03. 09. 11:27, Gergely Czuczy wrote:
Hello,
I'm trying to build a few things from ports on an rpi3, the ports
collection is mounted over NFS from another machine. When it's trying
to build pkg i'm getting the error message in syslog:
rpi3 kernel: pid 4451 (sh), uid 0, was killed: text file modification
The report to pkg@:
https://lists.freebsd.org/pipermail/freebsd-pkg/2017-March/002048.html
In ports-mgmt/pkg's config.log It fails at the following entry:
configure:3726: checking whether we are cross compiling
configure:3734: cc -o conftest -O2 -pipe -Wno-error
-fno-strict-aliasing conftest.c >&5
configure:3738: $? = 0
configure:3745: ./conftest
configure:3749: $? = 137
configure:3756: error: in `/usr/ports/ports-mgmt/pkg/work/pkg-1.10.0':
configure:3760: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
# uname -a
FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314949: Thu Mar 9
08:58:46 CET 2017
ae...@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64.aarch64/tank/rpi3/src/sys/AEGIR
arm64
So far, a few additions:
Time is synced between the NFS server and the client.
it's an open() call which is getting the kill, and it's not the file
what's being opened, but the process executing it.
Here's a simple code that reproduces it:
#include
int main() {
FILE *f = fopen ("/bar", "w");
fclose(f);
return 0;
}
Conditions to reproduce it:
- The resulting binary must be executed from the nfs mount
- The binary must be built after mounting the NFS share.
I haven't tried building it on a different host, I don't have access
to multiple RPis. Also, if I build the binary, umount/remount the NFS
mount point, which has the binary, execute it, then it works.
I've also tried this with the raspbsd.org's image, I could reproduce
it as well.
Another interesting thing is, when I first booted the RPi up, the NFS
server was a 10.2-STABLE, and later got updated to 11-STABLE. While it
was 10.2 I've tried to build some port, and I don't remember having
this issue.
So, could someone please help me figure this out and fix it? This
stuff should work pretty much.
So, this error message comes from here:
https://svnweb.freebsd.org/base/head/sys/fs/nfsclient/nfs_clbio.c?revision=314436=markup#l1674
It's the NFS_TIMESPEC_COMPARE(>n_mtime, >n_vattr.na_mtime)
comparision that fails, np should be the NFS node structure, from the
vnode's v_data, and n_vattr is the attribute cache. As I've seen these
two are being updated together, so I don't really see by the code why
they might differ. Could someone please take a look at it, with more
experience in the NFS code? -czg
Can you print out the two mtimes? I wonder if what's happening is that
your server uses different granularity (for example just seconds) than
your client, so on the client we generate a timestamp with a non-zero
nanoseconds but when the server receives that timestamp it "truncates"
it. During open() we forcefully re-fetch the timestamp (for CTO
consistency) and then notice it doesn't match. For now I would start
with comparing the timestamps and maybe the vfs.timestamp_precision
sysctls on client and server (if server is a FreeBSD box).
Here are the time values:
Mar 9 19:46:01 rpi3 kernel: np->n_mtime: -3298114786344 +
-3298114786336 >n_vattr.na_mtime: -3298114786616 + -3298114786608
Mar 9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed: text file
modification
Mar 9 19:46:01 rpi3 kernel: np->n_mtime: -3298114786344 +
-3298114786336 >n_vattr.na_mtime: -3298114786616 + -3298114786608
Mar 9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed: text file
modification
Printed this way:
printf("np->n_mtime: %ji + %ji
>n_vattr.na_mtime: %ji + %ji",
(intmax_t)(>n_mtime.tv_sec),
(intmax_t)(>n_mtime.tv_nsec),
(intmax_t)(>n_vattr.na_mtime.tv_sec),
(intmax_t)(>n_vattr.na_mtime.tv_nsec));
___
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: process killed: text file modification
[+freebsd-fs]
On 2017. 03. 09. 14:20, Gergely Czuczy wrote:
On 2017. 03. 09. 11:27, Gergely Czuczy wrote:
Hello,
I'm trying to build a few things from ports on an rpi3, the ports
collection is mounted over NFS from another machine. When it's trying
to build pkg i'm getting the error message in syslog:
rpi3 kernel: pid 4451 (sh), uid 0, was killed: text file modification
The report to pkg@:
https://lists.freebsd.org/pipermail/freebsd-pkg/2017-March/002048.html
In ports-mgmt/pkg's config.log It fails at the following entry:
configure:3726: checking whether we are cross compiling
configure:3734: cc -o conftest -O2 -pipe -Wno-error
-fno-strict-aliasing conftest.c >&5
configure:3738: $? = 0
configure:3745: ./conftest
configure:3749: $? = 137
configure:3756: error: in `/usr/ports/ports-mgmt/pkg/work/pkg-1.10.0':
configure:3760: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
# uname -a
FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314949: Thu Mar 9
08:58:46 CET 2017
ae...@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64.aarch64/tank/rpi3/src/sys/AEGIR
arm64
So far, a few additions:
Time is synced between the NFS server and the client.
it's an open() call which is getting the kill, and it's not the file
what's being opened, but the process executing it.
Here's a simple code that reproduces it:
#include
int main() {
FILE *f = fopen ("/bar", "w");
fclose(f);
return 0;
}
Conditions to reproduce it:
- The resulting binary must be executed from the nfs mount
- The binary must be built after mounting the NFS share.
I haven't tried building it on a different host, I don't have access
to multiple RPis. Also, if I build the binary, umount/remount the NFS
mount point, which has the binary, execute it, then it works.
I've also tried this with the raspbsd.org's image, I could reproduce
it as well.
Another interesting thing is, when I first booted the RPi up, the NFS
server was a 10.2-STABLE, and later got updated to 11-STABLE. While it
was 10.2 I've tried to build some port, and I don't remember having
this issue.
So, could someone please help me figure this out and fix it? This
stuff should work pretty much.
So, this error message comes from here:
https://svnweb.freebsd.org/base/head/sys/fs/nfsclient/nfs_clbio.c?revision=314436=markup#l1674
It's the NFS_TIMESPEC_COMPARE(>n_mtime, >n_vattr.na_mtime)
comparision that fails, np should be the NFS node structure, from the
vnode's v_data, and n_vattr is the attribute cache. As I've seen these
two are being updated together, so I don't really see by the code why
they might differ. Could someone please take a look at it, with more
experience in the NFS code? -czg
___
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: process killed: text file modification
On 2017. 03. 09. 11:27, Gergely Czuczy wrote:
Hello,
I'm trying to build a few things from ports on an rpi3, the ports
collection is mounted over NFS from another machine. When it's trying
to build pkg i'm getting the error message in syslog:
rpi3 kernel: pid 4451 (sh), uid 0, was killed: text file modification
The report to pkg@:
https://lists.freebsd.org/pipermail/freebsd-pkg/2017-March/002048.html
In ports-mgmt/pkg's config.log It fails at the following entry:
configure:3726: checking whether we are cross compiling
configure:3734: cc -o conftest -O2 -pipe -Wno-error
-fno-strict-aliasing conftest.c >&5
configure:3738: $? = 0
configure:3745: ./conftest
configure:3749: $? = 137
configure:3756: error: in `/usr/ports/ports-mgmt/pkg/work/pkg-1.10.0':
configure:3760: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
# uname -a
FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314949: Thu Mar 9
08:58:46 CET 2017
ae...@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64.aarch64/tank/rpi3/src/sys/AEGIR
arm64
So far, a few additions:
Time is synced between the NFS server and the client.
it's an open() call which is getting the kill, and it's not the file
what's being opened, but the process executing it.
Here's a simple code that reproduces it:
#include
int main() {
FILE *f = fopen ("/bar", "w");
fclose(f);
return 0;
}
Conditions to reproduce it:
- The resulting binary must be executed from the nfs mount
- The binary must be built after mounting the NFS share.
I haven't tried building it on a different host, I don't have access to
multiple RPis. Also, if I build the binary, umount/remount the NFS mount
point, which has the binary, execute it, then it works.
I've also tried this with the raspbsd.org's image, I could reproduce it
as well.
Another interesting thing is, when I first booted the RPi up, the NFS
server was a 10.2-STABLE, and later got updated to 11-STABLE. While it
was 10.2 I've tried to build some port, and I don't remember having this
issue.
So, could someone please help me figure this out and fix it? This stuff
should work pretty much.
I have no idea what's causing it, it should pretty much work out of
the box. Could someone please explain me what's going on here, what's
causing it and how can I fix it?
Best regards,
-czg
___
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"
process killed: text file modification
Hello, I'm trying to build a few things from ports on an rpi3, the ports collection is mounted over NFS from another machine. When it's trying to build pkg i'm getting the error message in syslog: rpi3 kernel: pid 4451 (sh), uid 0, was killed: text file modification The report to pkg@: https://lists.freebsd.org/pipermail/freebsd-pkg/2017-March/002048.html In ports-mgmt/pkg's config.log It fails at the following entry: configure:3726: checking whether we are cross compiling configure:3734: cc -o conftest -O2 -pipe -Wno-error -fno-strict-aliasing conftest.c >&5 configure:3738: $? = 0 configure:3745: ./conftest configure:3749: $? = 137 configure:3756: error: in `/usr/ports/ports-mgmt/pkg/work/pkg-1.10.0': configure:3760: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details # uname -a FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314949: Thu Mar 9 08:58:46 CET 2017 ae...@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64.aarch64/tank/rpi3/src/sys/AEGIR arm64 I have no idea what's causing it, it should pretty much work out of the box. Could someone please explain me what's going on here, what's causing it and how can I fix it? Best regards, -czg ___ 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: LOR on RPi3 r314894
On 2017. 03. 09. 6:59, Benjamin Kaduk wrote: On Wed, Mar 08, 2017 at 02:06:33PM +0100, Gergely Czuczy wrote: On 2017. 03. 08. 13:06, Hans Petter Selasky wrote: You might check the links on this page to see if your LOR is already listed: https://wiki.freebsd.org/LOR Thank you, I wasn't aware of this page. It turns out it's already listed: http://sources.zabbadoz.net/freebsd/lor/238.html However, the last reported stamp shouldn't anymore be 2008-09-30 :) The page is no longer actively maintained, unfortunately. I couldn't find it among the PRs, should I open one? Or since it was on this page, is it already known? I have no idea whether it's a false positive, but I'm surely not getting a panic. -czg -Ben ___ 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: LOR on RPi3 r314894
On 2017. 03. 08. 13:06, Hans Petter Selasky wrote: On 03/08/17 12:23, Gergely Czuczy wrote: Hello, I've built an image for RPi3 from -CURRENT checkout at r314894, and while booting, I've noticed a LOR message: http://czg.harmless.hu/aegir/LOR_1_1280.jpg I don't know whether this one is any concern, if so, I'm just letting you know. Hi, You might check the links on this page to see if your LOR is already listed: https://wiki.freebsd.org/LOR Thank you, I wasn't aware of this page. It turns out it's already listed: http://sources.zabbadoz.net/freebsd/lor/238.html However, the last reported stamp shouldn't anymore be 2008-09-30 :) --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"
LOR on RPi3 r314894
Hello, I've built an image for RPi3 from -CURRENT checkout at r314894, and while booting, I've noticed a LOR message: http://czg.harmless.hu/aegir/LOR_1_1280.jpg I don't know whether this one is any concern, if so, I'm just letting you know. Best regards, Gergely ___ 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: Packaging the FreeBSD base system with pkg(8)
On 2016-01-27 23:33, Glen Barber wrote: As many know, work has been in progress for quite some time to provide the ability to package and upgrade the FreeBSD base system using pkg(8). The majority of the initial implementation has provided much of the core functionality to make this possible, however much work still needs to be done. Over the past few weeks, there have been several inquiries on if this work is still targeted for the 11.0-RELEASE, as well as the status of the project branch (base/projects/release-pkg). The answer to the first question is: Yes. This is still targeted for 11.0-RELEASE, which was one of the requirements during discussion of the new support model announced early last year [1]. The status of the in progress work is a bit more complex to answer in a short email, but work on packaging the FreeBSD base system is indeed ongoing, and has been my primary focus over the past several weeks. I am finishing an initial list of outstanding items that need to be resolved before the project branch can feasibly merged back to head, which I will send to the new freebsd-pkgbase@ mailing list. People interested in discussion surrounding this topic are urged to subscribe: https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase Finally, I want to personally thank Baptiste Daroussin for all of his tireless efforts to get us to the point we are at now. Without his ideas and insights, as well as ensuring pkg(8) contained the necessary functionality, we would not be anywhere close to completing this work for the 11.0-RELEASE. May I ask how are you going to handle the tricky merging part, like /etc/master.passwd? Usually that file has entries from 3 sources: - From the Base system, which might change between releases - From installed ports - Manually created entries. Also, quite often entries from the base system are changed manually, think of root's/toor's password. Are such cases going to be dealt with properly between upgrades, including self-built-and-packaged base systems? Currently it can be a PITA with mergemaster to handle things like master.passwd properly between upgrades, automation so far wasn't famous on doing it properly. Another thing is, there are a couple of parts of the base system where we add or remove features using knobs, and those take effect at multiple places. Like if I want to have wireless support, there's a bunch of userland utilities being built, and (the important part) some utilities are going to be built differently, like ifconfig. Is handling such features implemented properly by packaging base? We still have to be able to switch between different builds using the new tools. Another thing is, sometimes when upgrading systems, to make things easier, I deploy the new major version of base, leave old libs/stuff in there till I rebuild and upgrade the packages installed, and after that remove the old libs (rm-old-libs target IIRC). The reason for this, for smaller systems there's usually a build jail which produces packages, and it needs to be upgraded to the new release to make the packages for it, so it's a bit of catch-22, and running rm-old-libs late just solved the issue. Is such a functionality still supported during upgrades? That is, upgrading base systems first in a way that old packages are still functional? It's a very big projects, with lots of corner cases and difficult issues to tackle, I really appreciate your effort on this. Best regards, Gergely [1] https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html Thanks. Glen ___ 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"
