git commit for WITH_DETECT_TZ_CHANGES breaks date, et al
After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to recognize any configured timezone when WITH_DETECT_TZ_CHANGES is not set. For example .. imb@vm01:/home/imb> date Tue Sep 14 01:25:57 2021 Every other daemon also thinks it's running in UTC+0 :-( When libc is recompiled with WITH_DETECT_TZ_CHANGES=yes in /etc/src.conf, the output is (for me) .. imb@vm01:/usr/src/lib/libc> date Mon Sep 13 21:28:29 EDT 2021 imb
Re: recent head having significantly less "avail memory"
On 14/09/21 00:12, Konstantin Belousov wrote: On Mon, Sep 13, 2021 at 10:07:46PM +0200, Guido Falsi wrote: On 13/09/21 19:08, Konstantin Belousov wrote: On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote: Hi, I updated head recently and today I noticed a difference which looks wrong. At boodt the new head shows signifcantly less avail memory than before, around 3 GiB less. I moved from commit 71fbc6faed6 [1] where I got: Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) to commit 7955efd574b [2] where I get: Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) I'm seeing this on multiple machines. Unluckily bisecting and trying an older loader.efi in sseparate tests did not give me any more insight. The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look like a possible trigger to this, but I have been unable to confirm it. Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could be? Is this UEFI or bios boot? Provide verbose dmesg for old and new boots on the same machine. For UEFI boot, show output of 'sysctl machdep.efi_map', again for old and new boots. I shared the data you request here: https://www.madpilot.net/cloud/s/ENW5zF7jfmrmFeG Thanks. If you do on the loader prompt for the new (AKA bad) kernel copy_staging enable and then boot, does the report of avail memory becomes good? Yes, it works as expected, that is reports the amount of memory I expect: Sep 14 00:24:50 marvin kernel: real memory = 17179869184 (16384 MB) Sep 14 00:24:50 marvin kernel: avail memory = 16590356480 (15821 MB) -- Guido Falsi
Re: recent head having significantly less "avail memory"
On Mon, Sep 13, 2021 at 10:07:46PM +0200, Guido Falsi wrote: > On 13/09/21 19:08, Konstantin Belousov wrote: > > On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current > > wrote: > > > Hi, > > > > > > I updated head recently and today I noticed a difference which looks > > > wrong. > > > > > > At boodt the new head shows signifcantly less avail memory than before, > > > around 3 GiB less. > > > > > > I moved from commit 71fbc6faed6 [1] where I got: > > > > > > Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) > > > Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) > > > > > > to commit 7955efd574b [2] where I get: > > > > > > Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) > > > Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) > > > > > > I'm seeing this on multiple machines. > > > > > > Unluckily bisecting and trying an older loader.efi in sseparate tests did > > > not give me any more insight. > > > > > > The recent changes to efi loader, starting with commit 6032b6ba9596 [3] > > > look > > > like a possible trigger to this, but I have been unable to confirm it. > > > > > > Any suggesstions on how to proceed to debug thiss? ANy idea what a fix > > > could > > > be? > > > > Is this UEFI or bios boot? > > Provide verbose dmesg for old and new boots on the same machine. > > For UEFI boot, show output of 'sysctl machdep.efi_map', again for old > > and new boots. > > > > I shared the data you request here: > > https://www.madpilot.net/cloud/s/ENW5zF7jfmrmFeG Thanks. If you do on the loader prompt for the new (AKA bad) kernel copy_staging enable and then boot, does the report of avail memory becomes good?
Re: recent head having significantly less "avail memory"
On 13/09/21 19:08, Konstantin Belousov wrote: On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote: Hi, I updated head recently and today I noticed a difference which looks wrong. At boodt the new head shows signifcantly less avail memory than before, around 3 GiB less. I moved from commit 71fbc6faed6 [1] where I got: Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) to commit 7955efd574b [2] where I get: Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) I'm seeing this on multiple machines. Unluckily bisecting and trying an older loader.efi in sseparate tests did not give me any more insight. The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look like a possible trigger to this, but I have been unable to confirm it. Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could be? Is this UEFI or bios boot? Provide verbose dmesg for old and new boots on the same machine. For UEFI boot, show output of 'sysctl machdep.efi_map', again for old and new boots. I shared the data you request here: https://www.madpilot.net/cloud/s/ENW5zF7jfmrmFeG -- Guido Falsi
Re: recent head having significantly less "avail memory"
On 13/09/21 20:17, Ryan Stone wrote: On Mon, Sep 13, 2021 at 2:13 PM Guido Falsi via freebsd-current wrote: I'm not sure how to get the verbose data for the old boot, since I've been unable to revert the machine to the old state. I'll try anyway though. Do you have physical access to the machine? It might be easiest to grab a snapshot image, stick it on a USB drive and boot from that. I definitely have physical access, it's my desktop, laptop and build machines. First thing I'm doing is disable cron job removing old zfs snapshots, so state is not lost. Since this is involving only UEFI, loader and kernel, I've recovered the old parts and now I have the machine reporting the usual amount of memory, so I should be able to extract the requested data and post it shortly. Thanks for your help anyway! -- Guido Falsi
Re: recent head having significantly less "avail memory"
On Mon, Sep 13, 2021 at 2:13 PM Guido Falsi via freebsd-current wrote: > I'm not sure how to get the verbose data for the old boot, since I've > been unable to revert the machine to the old state. I'll try anyway though. Do you have physical access to the machine? It might be easiest to grab a snapshot image, stick it on a USB drive and boot from that.
Re: recent head having significantly less "avail memory"
On 13/09/21 19:08, Konstantin Belousov wrote: On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote: Hi, I updated head recently and today I noticed a difference which looks wrong. At boodt the new head shows signifcantly less avail memory than before, around 3 GiB less. I moved from commit 71fbc6faed6 [1] where I got: Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) to commit 7955efd574b [2] where I get: Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) I'm seeing this on multiple machines. Unluckily bisecting and trying an older loader.efi in sseparate tests did not give me any more insight. The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look like a possible trigger to this, but I have been unable to confirm it. Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could be? Is this UEFI or bios boot? Machine is UEFI Provide verbose dmesg for old and new boots on the same machine. For UEFI boot, show output of 'sysctl machdep.efi_map', again for old and new boots. I'm not sure how to get the verbose data for the old boot, since I've been unable to revert the machine to the old state. I'll try anyway though. Anyway this is happening on tree different machines. I forgot to mention they are using a custom kernel. I don't think it makes a difference but I'll also test GENERIC, just in case. -- Guido Falsi
Re: recent head having significantly less "avail memory"
On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote: > Hi, > > I updated head recently and today I noticed a difference which looks wrong. > > At boodt the new head shows signifcantly less avail memory than before, > around 3 GiB less. > > I moved from commit 71fbc6faed6 [1] where I got: > > Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) > Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) > > to commit 7955efd574b [2] where I get: > > Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) > Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) > > I'm seeing this on multiple machines. > > Unluckily bisecting and trying an older loader.efi in sseparate tests did > not give me any more insight. > > The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look > like a possible trigger to this, but I have been unable to confirm it. > > Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could > be? Is this UEFI or bios boot? Provide verbose dmesg for old and new boots on the same machine. For UEFI boot, show output of 'sysctl machdep.efi_map', again for old and new boots.
recent head having significantly less "avail memory"
Hi, I updated head recently and today I noticed a difference which looks wrong. At boodt the new head shows signifcantly less avail memory than before, around 3 GiB less. I moved from commit 71fbc6faed6 [1] where I got: Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) to commit 7955efd574b [2] where I get: Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) I'm seeing this on multiple machines. Unluckily bisecting and trying an older loader.efi in sseparate tests did not give me any more insight. The recent changes to efi loader, starting with commit 6032b6ba9596 [3] look like a possible trigger to this, but I have been unable to confirm it. Any suggesstions on how to proceed to debug thiss? ANy idea what a fix could be? [1] https://cgit.freebsd.org/src/commit/?id=71fbc6faed62e8eb5864f7c40839740f5e9f5558 [2] https://cgit.freebsd.org/src/commit/?id=7955efd574b98601a95da45d6d8e7f452631fddd [3] https://cgit.freebsd.org/src/commit/?id=6032b6ba9596927aba15a8004ade521a593a7d58 -- Guido Falsi
