Re: earmv7hf test status, specifically utimensat
> We really should have a proper (and non-optional) devfs and then the problem > is moot. >- thorpej Strongly agree! Preconfigured device nodes and MAKEDEV are a downside to NetBSD and OpenBSD, and decidedly awkward with GTP-partitioned hard drives with many partitions. Tom
Re: earmv7hf test status, specifically utimensat
> On Aug 30, 2018, at 11:27 AM, Martin Husemann wrote: > > I dimly remember part of my issues were with /dev on the noatime file > system - so maybe we should just update atime in the vnode cache, but > just don't write it back if mounted noatime. And maybe lock dev vnodes > and never reclaim them - there can't be *that* much of them (if you > have ptyfs mounted). We really should have a proper (and non-optional) devfs and then the problem is moot. -- thorpej
Re: earmv7hf test status, specifically utimensat
> On Aug 30, 2018, at 11:05 AM, Martin Husemann wrote: > > I forgot the details, but it breaks real world software every now and > then, at least it did when I last tried. At the very least, an atime update should never drive an I/O. Atime updates should update in-memory and *shrug*. If you want to update the atime on stable storage when updating some other attribute, so be it... and I suppose it wouldn't be too terrible to push out a dirty atime when the vnode is reclaimed, but it's still unnecessary write I/O for what might otherwise a read-only workload. -- thorpej
Re: earmv7hf test status, specifically utimensat
On Thu, Aug 30, 2018 at 11:22:03AM -0700, Jason Thorpe wrote: > At the very least, an atime update should never drive an I/O. Indeed. > Atime updates should update in-memory and *shrug*. If you want to > update the atime on stable storage when updating some other attribute, > so be it... and I suppose it wouldn't be too terrible to push out a > dirty atime when the vnode is reclaimed, but it's still unnecessary > write I/O for what might otherwise a read-only workload. I dimly remember part of my issues were with /dev on the noatime file system - so maybe we should just update atime in the vnode cache, but just don't write it back if mounted noatime. And maybe lock dev vnodes and never reclaim them - there can't be *that* much of them (if you have ptyfs mounted). Martin
Re: earmv7hf test status, specifically utimensat
Hello. atime is something I use for diagnostic purposes on a regular basis. I wish Windows had it and when it's not available, I miss it often. -thanks -Brian On Aug 30, 11:01am, Jason Thorpe wrote: } Subject: Re: earmv7hf test status, specifically utimensat } } } > On Aug 30, 2018, at 10:21 AM, Greg Troxel wrote: } > } > It turns out the system I found this on was mounted noatime, just } > like the install image does by default. I had not set up tmpfs, even } > though I usually do. } > } > Adding a tmpfs makes the test pass. } > } > Also, when I said lockup, what really happened was that the system was } > running but the usb wifi interface wedged: } > } > Aug 30 11:00:20 rpi3 /netbsd: urtwn0: timeout waiting for firmware readiness } } I see this all the bloody time on my RPI, and it drives me batty. } } > obviously noatime is about not breaking uSD cards, but I wonder if } > that's still necessary with modern cards? } } Yes. } } > the rpi3 image seems to default to noatime, and I wonder if that } > should continue to be, given the balance of saving wear and oddness } } Honestly, atime is one of the dumbest file attributes there is. Personally, I think we should be defaulting to noatime unless running some sort of conformance test. } } -- thorpej } } >-- End of excerpt from Jason Thorpe
Re: earmv7hf test status, specifically utimensat
On Thu, Aug 30, 2018 at 11:01:21AM -0700, Jason Thorpe wrote: > Honestly, atime is one of the dumbest file attributes there is. > Personally, I think we should be defaulting to noatime unless running > some sort of conformance test. I forgot the details, but it breaks real world software every now and then, at least it did when I last tried. Martin
Re: earmv7hf test status, specifically utimensat
> On Aug 30, 2018, at 10:21 AM, Greg Troxel wrote: > > It turns out the system I found this on was mounted noatime, just > like the install image does by default. I had not set up tmpfs, even > though I usually do. > > Adding a tmpfs makes the test pass. > > Also, when I said lockup, what really happened was that the system was > running but the usb wifi interface wedged: > > Aug 30 11:00:20 rpi3 /netbsd: urtwn0: timeout waiting for firmware readiness I see this all the bloody time on my RPI, and it drives me batty. > obviously noatime is about not breaking uSD cards, but I wonder if > that's still necessary with modern cards? Yes. > the rpi3 image seems to default to noatime, and I wonder if that > should continue to be, given the balance of saving wear and oddness Honestly, atime is one of the dumbest file attributes there is. Personally, I think we should be defaulting to noatime unless running some sort of conformance test. -- thorpej
Re: earmv7hf test status, specifically utimensat
Martin Husemann writes: > On Thu, Aug 30, 2018 at 10:25:54AM -0400, Greg Troxel wrote: >> 2) On the same RPI3 that failed bup tests, our atf tests fail >> >> usr/tests/lib/libc/c063 > atf-run ./t_utimensat | atf-report >> Tests root: /usr/tests/lib/libc/c063 >> >> ./t_utimensat (1/1): 7 test cases >> utimensat_fd: [0.007541s] Failed: >> /home/n0/gdt/NetBSD-8/src/tests/lib/libc/c063/t_utimensat.c:78: >> st.st_atimespec.tv_sec == tptr[0].tv_sec not met >> utimensat_fdcwd: [0.006916s] Failed: >> /home/n0/gdt/NetBSD-8/src/tests/lib/libc/c063/t_utimensat.c:103: >> st.st_atimespec.tv_sec == tptr[0].tv_sec not met >> utimensat_fdcwderr: [0.006623s] Passed. >> utimensat_fderr1: [0.006826s] Passed. >> utimensat_fderr2: [0.007021s] Passed. >> utimensat_fderr3: [0.006694s] Passed. >> utimensat_fdlink: [0.007133s] Failed: >> /home/n0/gdt/NetBSD-8/src/tests/lib/libc/c063/t_utimensat.c:195: >> st.st_atimespec.tv_sec == tptr[0].tv_sec not met >> [0.055688s] > > Those all work for me, with FFS on SATA disk. What file system are you using? Thanks - that turned out to be almos the right question, which I now know to be "is your fs mounted noatime?". It turns out the system I found this on was mounted noatime, just like the install image does by default. I had not set up tmpfs, even though I usually do. Adding a tmpfs makes the test pass. Also, when I said lockup, what really happened was that the system was running but the usb wifi interface wedged: Aug 30 11:00:20 rpi3 /netbsd: urtwn0: timeout waiting for firmware readiness (Thanks to gson@ for explaining why the tests fail; that's unfortunate.) So, I guess this leaves two questions: obviously noatime is about not breaking uSD cards, but I wonder if that's still necessary with modern cards? the rpi3 image seems to default to noatime, and I wonder if that should continue to be, given the balance of saving wear and oddness I wonder if calling utimensat (and similar) on a file that's on a noatime fs should results in EROFS, or if noatime is supposed to be a silent discarding signature.asc Description: PGP signature
Re: earmv7hf test status, specifically utimensat
On Thu, Aug 30, 2018 at 11:16:03AM -0400, Greg Troxel wrote: > The system is FFS on uSD, plus /tmp is tmpfs.A typical RPI3 install > with no extra stuff. So atf should use tmpfs (same here). I am running at least one full test run every week, but on a cubietruck. Recently I saw occasional crashes, but never repeatable enough to track it down. Maybe those manifest as lock ups for you. Still no idea about the utimesat() lossage though. Martin
Re: earmv7hf test status, specifically utimensat
Martin Husemann writes: >> 2) On the same RPI3 that failed bup tests, our atf tests fail >> >> usr/tests/lib/libc/c063 > atf-run ./t_utimensat | atf-report >> Tests root: /usr/tests/lib/libc/c063 >> >> ./t_utimensat (1/1): 7 test cases >> utimensat_fd: [0.007541s] Failed: >> /home/n0/gdt/NetBSD-8/src/tests/lib/libc/c063/t_utimensat.c:78: >> st.st_atimespec.tv_sec == tptr[0].tv_sec not met >> utimensat_fdcwd: [0.006916s] Failed: >> /home/n0/gdt/NetBSD-8/src/tests/lib/libc/c063/t_utimensat.c:103: >> st.st_atimespec.tv_sec == tptr[0].tv_sec not met >> utimensat_fdcwderr: [0.006623s] Passed. >> utimensat_fderr1: [0.006826s] Passed. >> utimensat_fderr2: [0.007021s] Passed. >> utimensat_fderr3: [0.006694s] Passed. >> utimensat_fdlink: [0.007133s] Failed: >> /home/n0/gdt/NetBSD-8/src/tests/lib/libc/c063/t_utimensat.c:195: >> st.st_atimespec.tv_sec == tptr[0].tv_sec not met >> [0.055688s] > > Those all work for me, with FFS on SATA disk. What file system are you using? The system is FFS on uSD, plus /tmp is tmpfs.A typical RPI3 install with no extra stuff. And, running the entire atf tests resulted in a lockup. signature.asc Description: PGP signature
Re: earmv7hf test status, specifically utimensat
Greg Troxel wrote: > 1) The releng tests for -current/earmv7hf seem not to have completed since > May 4 > > http://releng.netbsd.org/b5reports/evbarm-earmv7hf/ > http://releng.netbsd.org/b5reports/evbarm-earmv7hf/commits-2018.05.html > > Does anybody know why the tests don't complete? Just a too-low > timeout/too-long test? Joerg's gtmr changes broke them. Every gtmr read is now repeated 200 times, getting a different value every time because qemu is so slow, and that slows down the tests even more, to the point that they time out. This is PR 53308. -- Andreas Gustafsson, g...@gson.org
Re: earmv7hf test status, specifically utimensat
On Thu, Aug 30, 2018 at 10:25:54AM -0400, Greg Troxel wrote: > > While running tests for pkgsrc/sysutils/bup on earmv7hf-el (RPI3) on > netbsd-8 from July 3, I saw test failures for utimensat. It seems this > is a NetBSD bug instead of a bup test issue. > > 1) The releng tests for -current/earmv7hf seem not to have completed since > May 4 > > http://releng.netbsd.org/b5reports/evbarm-earmv7hf/ > http://releng.netbsd.org/b5reports/evbarm-earmv7hf/commits-2018.05.html > > Does anybody know why the tests don't complete? Just a too-low > timeout/too-long test? No idea, but the real hardware tests work for me: http://www.netbsd.org/~martin/evbearmv7hf-atf/ > 2) On the same RPI3 that failed bup tests, our atf tests fail > > usr/tests/lib/libc/c063 > atf-run ./t_utimensat | atf-report > Tests root: /usr/tests/lib/libc/c063 > > ./t_utimensat (1/1): 7 test cases > utimensat_fd: [0.007541s] Failed: > /home/n0/gdt/NetBSD-8/src/tests/lib/libc/c063/t_utimensat.c:78: > st.st_atimespec.tv_sec == tptr[0].tv_sec not met > utimensat_fdcwd: [0.006916s] Failed: > /home/n0/gdt/NetBSD-8/src/tests/lib/libc/c063/t_utimensat.c:103: > st.st_atimespec.tv_sec == tptr[0].tv_sec not met > utimensat_fdcwderr: [0.006623s] Passed. > utimensat_fderr1: [0.006826s] Passed. > utimensat_fderr2: [0.007021s] Passed. > utimensat_fderr3: [0.006694s] Passed. > utimensat_fdlink: [0.007133s] Failed: > /home/n0/gdt/NetBSD-8/src/tests/lib/libc/c063/t_utimensat.c:195: > st.st_atimespec.tv_sec == tptr[0].tv_sec not met > [0.055688s] Those all work for me, with FFS on SATA disk. What file system are you using? Martin
earmv7hf test status, specifically utimensat
While running tests for pkgsrc/sysutils/bup on earmv7hf-el (RPI3) on netbsd-8 from July 3, I saw test failures for utimensat. It seems this is a NetBSD bug instead of a bup test issue. 1) The releng tests for -current/earmv7hf seem not to have completed since May 4 http://releng.netbsd.org/b5reports/evbarm-earmv7hf/ http://releng.netbsd.org/b5reports/evbarm-earmv7hf/commits-2018.05.html Does anybody know why the tests don't complete? Just a too-low timeout/too-long test? 2) On the same RPI3 that failed bup tests, our atf tests fail usr/tests/lib/libc/c063 > atf-run ./t_utimensat | atf-report Tests root: /usr/tests/lib/libc/c063 ./t_utimensat (1/1): 7 test cases utimensat_fd: [0.007541s] Failed: /home/n0/gdt/NetBSD-8/src/tests/lib/libc/c063/t_utimensat.c:78: st.st_atimespec.tv_sec == tptr[0].tv_sec not met utimensat_fdcwd: [0.006916s] Failed: /home/n0/gdt/NetBSD-8/src/tests/lib/libc/c063/t_utimensat.c:103: st.st_atimespec.tv_sec == tptr[0].tv_sec not met utimensat_fdcwderr: [0.006623s] Passed. utimensat_fderr1: [0.006826s] Passed. utimensat_fderr2: [0.007021s] Passed. utimensat_fderr3: [0.006694s] Passed. utimensat_fdlink: [0.007133s] Failed: /home/n0/gdt/NetBSD-8/src/tests/lib/libc/c063/t_utimensat.c:195: st.st_atimespec.tv_sec == tptr[0].tv_sec not met [0.055688s] Failed test cases: ./t_utimensat:utimensat_fd, ./t_utimensat:utimensat_fdcwd, ./t_utimensat:utimensat_fdlink Summary for 1 test programs: 4 passed test cases. 3 failed test cases. 0 expected failed test cases. 0 skipped test cases. and this is consistent with my hacky test program. The errors smell like type size mismatch. signature.asc Description: PGP signature
