Re: Errata: OpenBSD 7.5: high temperature spotted different times
Correction: CPU: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 06-45-01, patch 0026 (year 2014) Dan wrote: > Hello, > > In my OpenBSD 7.5 stable temperature incrises timtotime remaining on > 64-65°C; an old quad cores I5 cpu. > > Thanks, > > -dan
OpenBSD 7.5: xfce-4.18.1: missing Special Characters utility
Hello, In my OpenBSD 7.5, xfce-4.18.1 is missing the Characters Map / Special Characters utility both graphically, in the menu, and on the disk. Thanks! -dan
OpenBSD 7.5: high temperature spotted different times
Hello, In my OpenBSD 7.5 stable temperature incrises timtotime remaining on 64-65°C; an old quad cores I5 cpu. Thanks, -dan
subscribe
subscribe please
Re: pax and ext2fs
On Wed May 15 13:04:53 2024 Walter Alejandro Iglesias wrote: > After more testing I realized that I was wrong my modification doesn't > solve the problem. > Yeah, I also realized that what I did was stupid. :-)
Re: pax and ext2fs
On Wed May 15 10:24:32 2024 Walter Alejandro Iglesias wrote: > I get it working but I don't know if what I did is fine. > > As I'd told you the problem was ctime (when using -Y), so I added one > conditional to your diff where it checks only mtime and it works: > > > Index: ar_subs.c > === > RCS file: /cvs/src/bin/pax/ar_subs.c,v > diff -u -p -r1.51 ar_subs.c > [...] After more testing I realized that I was wrong my modification doesn't solve the problem.
Re: pax and ext2fs
On Wed May 15 10:20:04 2024 Philip Guenther wrote:
> I think you've managed to hit a spot where the POSIX standard doesn't
> provide a way for a program to find the information it needs to do its job
> correctly. I've filed a ticket there
>https://austingroupbugs.net/view.php?id=1831
>
> We'll see if my understanding of pathconf() is incorrect or if someone has
> a great idea for how to get around this...
>
>
> Philip Guenther
>
Hi Philip,
I get it working but I don't know if what I did is fine.
As I'd told you the problem was ctime (when using -Y), so I added one
conditional to your diff where it checks only mtime and it works:
Index: ar_subs.c
===
RCS file: /cvs/src/bin/pax/ar_subs.c,v
diff -u -p -r1.51 ar_subs.c
--- ar_subs.c 10 Jul 2023 16:28:33 - 1.51
+++ ar_subs.c 15 May 2024 08:19:08 -
@@ -146,23 +146,61 @@ list(void)
}
static int
-cmp_file_times(int mtime_flag, int ctime_flag, ARCHD *arcn, struct stat *sbp)
+cmp_file_times(int mtime_flag, int ctime_flag, ARCHD *arcn, const char *path)
{
struct stat sb;
+ long res;
- if (sbp == NULL) {
- if (lstat(arcn->name, &sb) != 0)
- return (0);
- sbp = &sb;
+ if (path == NULL)
+ path = arcn->name;
+ if (lstat(path, &sb) != 0)
+ return (0);
+
+ /*
+* The target (sb) mtime might be rounded down due to the limitations
+* of the FS it's on. If it's strictly greater or we don't care about
+* mtime, then precision doesn't matter, so check those cases first.
+*/
+ if (ctime_flag && mtime_flag) {
+ if (timespeccmp(&arcn->sb.st_mtim, &sb.st_mtim, <=))
+ return timespeccmp(&arcn->sb.st_ctim, &sb.st_ctim, <=);
+ if (!timespeccmp(&arcn->sb.st_ctim, &sb.st_ctim, <=))
+ return 0;
+ /* <= ctim, but >= mtim */
+ } else if (mtime_flag) {
+ return timespeccmp(&arcn->sb.st_mtim, &sb.st_mtim, <=);
+ } else if (ctime_flag)
+ return timespeccmp(&arcn->sb.st_ctim, &sb.st_ctim, <=);
+ else if (timespeccmp(&arcn->sb.st_mtim, &sb.st_mtim, <=))
+ return 1;
+
+ /*
+* If we got here then the target arcn > sb for mtime *and* that's
+* the deciding factor. Check whether they're equal after rounding
+* down the arcn mtime to the precision of the target path.
+*/
+ res = pathconf(path, _PC_TIMESTAMP_RESOLUTION);
+ if (res == -1)
+ return 0;
+
+ /* nanosecond resolution? previous comparisons were accurate */
+ if (res == 1)
+ return 0;
+
+ /* common case: second accuracy */
+ if (res == 10)
+ return arcn->sb.st_mtime <= sb.st_mtime;
+
+ if (res < 10) {
+ struct timespec ts = arcn->sb.st_mtim;
+ ts.tv_nsec = (ts.tv_nsec / res) * res;
+ return timespeccmp(&ts, &sb.st_mtim, <=);
+ } else {
+ /* not a POSIX compliant FS */
+ res /= 10;
+ return ((arcn->sb.st_mtime / res) * res) <= sb.st_mtime;
+ return arcn->sb.st_mtime <= ((sb.st_mtime / res) * res);
}
-
- if (ctime_flag && mtime_flag)
- return (timespeccmp(&arcn->sb.st_mtim, &sbp->st_mtim, <=) &&
- timespeccmp(&arcn->sb.st_ctim, &sbp->st_ctim, <=));
- else if (ctime_flag)
- return (timespeccmp(&arcn->sb.st_ctim, &sbp->st_ctim, <=));
- else
- return (timespeccmp(&arcn->sb.st_mtim, &sbp->st_mtim, <=));
}
/*
@@ -842,14 +880,12 @@ copy(void)
/*
* if existing file is same age or newer skip
*/
- res = lstat(dirbuf, &sb);
- *dest_pt = '\0';
-
- if (res == 0) {
+ if (cmp_file_times(uflag, Dflag, arcn, dirbuf)) {
+ *dest_pt = '\0';
ftree_skipped_newer(arcn);
- if (cmp_file_times(uflag, Dflag, arcn, &sb))
- continue;
+ continue;
}
+ *dest_pt = '\0';
}
/*
Re: pax and ext2fs
On Tue, May 14, 2024 at 11:59 AM Walter Alejandro Iglesias wrote: > Hi Philip, > > On Tue May 14 19:40:04 2024 Philip Guenther wrote: > > If you like, you could try the following patch to pax to more gracefully > > handle filesystems with time resolution more granular than nanoseconds. > > After applying your patch, as I'd done before reporting the issue, I > sycronized my home directory to an external ext2fs drive with the > command showed by the man page: > > $ pax -rw -v -Z -Y source target > > This time only one file stays updating again an again, a soft link I > have in my ~/bin folder of /usr/local/bin/prename. I think you've managed to hit a spot where the POSIX standard doesn't provide a way for a program to find the information it needs to do its job correctly. I've filed a ticket there https://austingroupbugs.net/view.php?id=1831 We'll see if my understanding of pathconf() is incorrect or if someone has a great idea for how to get around this... Philip Guenther
Re: viomb0 unable to allocate256 physmem pages, error 12
viomb is a driver that tries to support OpenBSD, as a VM guest, responding to a request from the VM host to stop using so much physical memory. That log message indicates that the kernel couldn't easily free up that much physical memory, sorry! The VM host is, of course, free to decide to just page out whatever memory it wants instead, possibly resulting in thrashing: running a VM setup oversubscribed for memory is a great way to be frustrated and hate computers. How can you make that message go away? Provision your VM setup with enough memory that it's not over subscribed, or at least so that the OpenBSD guest(s) isn't the one being asked to slim itself (possibly by giving it *less* but _reserved_ memory, so that the VM host never tries to shrink its usage). Philip Guenther On Tue, May 14, 2024 at 4:16 PM F Bax wrote: > I'm not a coder; but I found source for viomb; which > calls uvm_pglistalloc; which calls uvm_pmr_getpages which mentions ENOMEM: > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/uvm/uvm_pmemrange.c?rev=1.66&content-type=text/plain > There I found this comment: > * fail if any of these conditions is true: > * [1] there really are no free pages, or > * [2] only kernel "reserved" pages remain and > *the UVM_PLA_USERESERVE flag wasn't used. > * [3] only pagedaemon "reserved" pages remain and > *the requestor isn't the pagedaemon nor the syncer. > > Unsure how I might use this information to get rid of the previously > mentioned error message.. > > On Tue, May 14, 2024 at 2:28 PM Peter J. Philipp > wrote: > >> On Tue, May 14, 2024 at 01:58:18PM -0400, F Bax wrote: >> > Recently installed 7.5 amd64 in qemu VM (8G RAM) under proxmox. See this >> > message many times on console and dmesg. >> > >> > viomb0 unable to allocate 256 physmem pages, error 12 >> > >> > What does this mean? How to resolve this issue? >> >> Hi, >> >> When you see "error " it's good to look up the manpage on errno. >> Under number 12 it says: ENOMEM "Cannot Allocate Memory". But look for >> yourself for a deeper explanation. Also if you want to hunt for this >> errno >> in the code you would most likely grep for ENOMEM. >> >> Best Regards, >> -pjp >> >> -- >> ** all info about me: lynx https://callpeter.tel, dig loc >> delphinusdns.org ** >> >>
