Re: CVS commit: src/tests/lib/libarchive
On Tue, 16 Jun 2020, Martin Husemann wrote: On Tue, Jun 16, 2020 at 09:12:40AM -0700, Paul Goyette wrote: It might be better to run the test in a rump-kernel rather than in a "live" environment The test this is about is a plain userland test: it extracts/compresses/decompresses various archive formats and compares results. Only thing "special" is that it is in big parts cpu bound, and multi-threaded. If NetBSD can not gracefully deal with that, something is very wrong (which since about a month it is). This PR is on the "must be fixed before branching netbsd-10" list, and I hope it will be fixed quickly. Ah, my bad. I thought it was the watch-dog that was being tested. I certainly agree that it needs to fixed ASAP. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/tests/lib/libarchive
On Tue, Jun 16, 2020 at 09:12:40AM -0700, Paul Goyette wrote: > It might be better to run the test in a rump-kernel rather than in a > "live" environment The test this is about is a plain userland test: it extracts/compresses/decompresses various archive formats and compares results. Only thing "special" is that it is in big parts cpu bound, and multi-threaded. If NetBSD can not gracefully deal with that, something is very wrong (which since about a month it is). This PR is on the "must be fixed before branching netbsd-10" list, and I hope it will be fixed quickly. Martin
Re: CVS commit: src/tests/lib/libarchive
On Tue, 16 Jun 2020, Greg Troxel wrote: Jason Thorpe writes: On Jun 16, 2020, at 8:43 AM, Martin Husemann wrote: No, that is definitively not OK, which is what the PR is about. It is not OK for a regular atf run to cause a reboot of the test machine though, so this is a temporary hack around the issue (and admitedly a very ugly hack). At the very least, the user-land watchdog tickler should wire itself down. My impression of the point is that it be normal, so that the system reboots if normal processes cannot be run.It seems like once whatever bug exists is fixed, wiring is probably not necessary anyway. It might be better to run the test in a rump-kernel rather than in a "live" environment ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: CVS commit: src/tests/lib/libarchive
Jason Thorpe writes: >> On Jun 16, 2020, at 8:43 AM, Martin Husemann wrote: >> >> No, that is definitively not OK, which is what the PR is about. >> >> It is not OK for a regular atf run to cause a reboot of the test machine >> though, so this is a temporary hack around the issue (and admitedly a very >> ugly hack). > > At the very least, the user-land watchdog tickler should wire itself down. My impression of the point is that it be normal, so that the system reboots if normal processes cannot be run.It seems like once whatever bug exists is fixed, wiring is probably not necessary anyway.
Re: CVS commit: src/tests/lib/libarchive
> On Jun 16, 2020, at 8:43 AM, Martin Husemann wrote: > > No, that is definitively not OK, which is what the PR is about. > > It is not OK for a regular atf run to cause a reboot of the test machine > though, so this is a temporary hack around the issue (and admitedly a very > ugly hack). At the very least, the user-land watchdog tickler should wire itself down. -- thorpej
Re: CVS commit: src/tests/lib/libarchive
On Tue, Jun 16, 2020 at 03:38:26PM -, Christos Zoulas wrote: > So we are saying that it is ok for process running with regular priority, > to be able to starve another process at the same priority from getting > any runtime for 21 seconds in a uniprocessor kernel, and this does not > indicate any problem with the scheduler implementation? This would mean > that for a HZ=100 kernel in 2100 rescheduling opportunities, the watchdog > thread was never selected to run? No, that is definitively not OK, which is what the PR is about. It is not OK for a regular atf run to cause a reboot of the test machine though, so this is a temporary hack around the issue (and admitedly a very ugly hack). Martin
Re: CVS commit: src/tests/lib/libarchive
In article <20200616075907.ecafcf...@cvs.netbsd.org>, Martin Husemann wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: martin >Date: Tue Jun 16 07:59:07 UTC 2020 > >Modified Files: > src/tests/lib/libarchive: t_libarchive.sh > >Log Message: >PR kern/55272: skip this test on uniprocessor machines, it is too dangerous >and can kill the host kernel if a userland watchdog is running So we are saying that it is ok for process running with regular priority, to be able to starve another process at the same priority from getting any runtime for 21 seconds in a uniprocessor kernel, and this does not indicate any problem with the scheduler implementation? This would mean that for a HZ=100 kernel in 2100 rescheduling opportunities, the watchdog thread was never selected to run? christos
re: CVS commit: src/tests/lib/libarchive
"Martin Husemann" writes: > Module Name: src > Committed By: martin > Date: Tue Jan 28 18:18:32 UTC 2020 > > Modified Files: > src/tests/lib/libarchive: t_libarchive.sh > > Log Message: > Bump timeout to 3600 - the libarchive tests take quite a while to > complete (on a nearly 1 GHz dual armv7 machine it takes more than 700s) this seems awfully excessive. can we tone down the libarchive tests to something reasonable for netbsd? .mrg.
