Re: Install of 13.0-RELEASE i386 with ZFS root hangs up
On Sat, May 08, 2021 at 06:33:02PM +0700, Eugene Grosbein wrote: > 08.05.2021 2:52, Konstantin Belousov wrote: > > > i386 kernel uses memory up to 24G since 13.0. > > > > PAE only means that devices that can access full 64bit address are allowed > > to avoid dma bouncing. > > Maybe you could tell something on similar topic? > > There is FreeBSD 12.2-STABLE r369567 Base12 amd64 running > with Intel Atom CPU capable of long mode and addressing 8GB RAM, > ASRock A330ION motherboard and two memory modules installed: 4G+2GB. > Why so small "avail memory"? > > FreeBSD clang version 10.0.1 (g...@github.com:llvm/llvm-project.git > llvmorg-10.0.1-0-gef32c611aa2) > CPU: Intel(R) Atom(TM) CPU 330 @ 1.60GHz (1600.03-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x106c2 Family=0x6 Model=0x1c Stepping=2 > > Features=0xbfe9fbff > Features2=0x40e31d > AMD Features=0x2800 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > real memory = 6442450944 (6144 MB) > Physical memory chunk(s): > 0x0001 - 0x0009dfff, 581632 bytes (142 pages) > 0x00103000 - 0x001f, 1036288 bytes (253 pages) > 0x02b0 - 0xd8709fff, 3586170880 bytes (875530 pages) > avail memory = 3571384320 (3405 MB) > > Also http://www.grosbein.net/freebsd/dmidecode.txt Some necromancy revealed that this CPU did not have memory controller on-chip, it was a design from the 2008 where MCH handled memory. It is up to the chipset and BIOS to configure and report the memory above 4G to OS. As you clearly see from the SMAP printed above, BIOS does not report anything above 4G. Might be, look at bios settings. No other ideas. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 13 console stops working under VMware
On 08/05/2021 15:20, Dimitry Andric wrote: On 8 May 2021, at 16:02, Roger Leigh wrote: This might sound like a bit of an odd one, but I’ll try to describe it. When I run a FreeBSD 13-RELEASE virtual machine under VMware, it appears to work correctly, but randomly stops working. If I focus the VMware window, and press Ctrl-G to grab input focus (or click in the window), I can log into the system using the console. However, if I press Ctrl-Alt to ungrab the input focus, or click outside the window, the block cursor on the console vanishes, and it’s no longer possible to type any input. However… if I grab focus again, I can use Alt-Fn to switch to a different virtual console, log in again and everything is fine… up until I switch focus to something else and the block cursor vanishes in that virtual console. Repeat until you run out of virtual consoles! I can’t reproduce this with FreeBSD 12. It seems to only happen with FreeBSD 13. I’ve had it happen reproducibly when losing focus, but then again sometimes I’ve had a few minutes where it doesn’t happen, until it starts occurring again. While it seems that losing focus is the trigger, there might be something else going on. Has anyone else noticed this or have any suggested workarounds? Press the Scroll Lock key to 'fix' it, if that is possible for you. This is some weird interaction between VMware's input focus grabbing method and our console, which sometimes turns on Scroll Lock accidentally. I have not been able to put my finger on when it happens exactly, but it does happen often. For me, it usually occurs when I use Microsoft Remote Desktop to access a Windows machine running VMware, and switch back and forth between Remote desktop and another application. Something about losing the focus is making the VMware GUI inject a Scroll Lock event. It's pretty tricky to generate Scroll Lock via Remote Desktop though, especially from a Mac, which doesn't have that key at all. :) -Dimitry PS: Note that Scroll Lock is normally used in FreeBSD's console to scroll back in the virtual consoles, as opposed to Linux's shift-PageUp and shift-PageDown. But it is a toggle, not a one-off key. Thanks Dimitry, that certainly makes some sort of sense! I am indeed connecting from a Mac to a beefier Windows 10 PC running VMware workstation using Remote Desktop. Going back to one of the "broken" consoles, I can indeed use PgUp/PgDn to scroll up and down, so it certainly appears as though a Scroll Lock keypress was sent or triggered somehow. While I do have a regular PC keyboard hooked up, I don't find myself able to send that key event through the Remote Desktop session. However, if I physically log into the Windows PC, I can unstick each console with the physical Scroll Lock key, so it seems clear that (somehow) Scroll Lock was triggered in the first place to cause the problem. I have tried to trigger various combinations of grab/ungrab/switch to window inside or outside of the Remote Desktop session, but I've not been able to pinpoint the specific trigger. Kind regards, Roger ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 13 console stops working under VMware
On 8 May 2021, at 16:02, Roger Leigh wrote: > > This might sound like a bit of an odd one, but I’ll try to describe it. When > I run a FreeBSD 13-RELEASE virtual machine under VMware, it appears to work > correctly, but randomly stops working. > > If I focus the VMware window, and press Ctrl-G to grab input focus (or click > in the window), I can log into the system using the console. However, if I > press Ctrl-Alt to ungrab the input focus, or click outside the window, the > block cursor on the console vanishes, and it’s no longer possible to type any > input. > > However… if I grab focus again, I can use Alt-Fn to switch to a different > virtual console, log in again and everything is fine… up until I switch focus > to something else and the block cursor vanishes in that virtual console. > Repeat until you run out of virtual consoles! > > I can’t reproduce this with FreeBSD 12. It seems to only happen with FreeBSD > 13. I’ve had it happen reproducibly when losing focus, but then again > sometimes I’ve had a few minutes where it doesn’t happen, until it starts > occurring again. While it seems that losing focus is the trigger, there > might be something else going on. > > Has anyone else noticed this or have any suggested workarounds? Press the Scroll Lock key to 'fix' it, if that is possible for you. This is some weird interaction between VMware's input focus grabbing method and our console, which sometimes turns on Scroll Lock accidentally. I have not been able to put my finger on when it happens exactly, but it does happen often. For me, it usually occurs when I use Microsoft Remote Desktop to access a Windows machine running VMware, and switch back and forth between Remote desktop and another application. Something about losing the focus is making the VMware GUI inject a Scroll Lock event. It's pretty tricky to generate Scroll Lock via Remote Desktop though, especially from a Mac, which doesn't have that key at all. :) -Dimitry PS: Note that Scroll Lock is normally used in FreeBSD's console to scroll back in the virtual consoles, as opposed to Linux's shift-PageUp and shift-PageDown. But it is a toggle, not a one-off key. signature.asc Description: Message signed with OpenPGP
FreeBSD 13 console stops working under VMware
Hi, This might sound like a bit of an odd one, but I’ll try to describe it. When I run a FreeBSD 13-RELEASE virtual machine under VMware, it appears to work correctly, but randomly stops working. If I focus the VMware window, and press Ctrl-G to grab input focus (or click in the window), I can log into the system using the console. However, if I press Ctrl-Alt to ungrab the input focus, or click outside the window, the block cursor on the console vanishes, and it’s no longer possible to type any input. However… if I grab focus again, I can use Alt-Fn to switch to a different virtual console, log in again and everything is fine… up until I switch focus to something else and the block cursor vanishes in that virtual console. Repeat until you run out of virtual consoles! I can’t reproduce this with FreeBSD 12. It seems to only happen with FreeBSD 13. I’ve had it happen reproducibly when losing focus, but then again sometimes I’ve had a few minutes where it doesn’t happen, until it starts occurring again. While it seems that losing focus is the trigger, there might be something else going on. Has anyone else noticed this or have any suggested workarounds? Kind regards, Roger ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Loading zfs module results in hangup on i386
From: Yasuhiro Kimura Subject: Re: Loading zfs module results in hangup on i386 Date: Sat, 08 May 2021 07:44:15 +0900 (JST) >> Now I think I know what is the source of problem. After all, on >> 13.0-RELEASE i386 system simply loading zfs module results in system >> hang up. >> >> The steps to reproduce it are, >> >> 1. Boot with install media of 13.0-RELEASE i386 >> 2. At the first menu of FreeBSD installer, select 'Shell'. >> 3. At the shell prompt, type `kldload zfs` and return key. >> >> I confirmed hangup happens with VirtualBox, VMware Player and my bare >> metal PC environement. So the problem doesn't depend on hardware. >> >> And hangup also happens with 13-STABLE and 14-CURRENT. > > This problem is already reported to Bugzilla. > > Bug 254177 When ZFS is recognized, An i386 machine with a lot of memory hangs. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254177 Referencing the bug report, I applied attached patch to d474440ab33 of main (14-CURRENT). built install image and tried install of ZFS root i386 system with it. Then it completed successfully with 8GB memory. Additionally GENERIC kernel recognizes 8GB of memory. And ZFS root system works fine without any tuning. -- diff --git a/sys/contrib/openzfs/module/zfs/dbuf.c b/sys/contrib/openzfs/module/zfs/dbuf.c index d48dc7943a2..c85500453fb 100644 --- a/sys/contrib/openzfs/module/zfs/dbuf.c +++ b/sys/contrib/openzfs/module/zfs/dbuf.c @@ -796,7 +796,7 @@ dbuf_init(void) * By default, the table will take up * totalmem * sizeof(void*) / 8K (1MB per GB with 8-byte pointers). */ - while (hsize * zfs_arc_average_blocksize < physmem * PAGESIZE) + while (hsize * zfs_arc_average_blocksize < (uint64_t)physmem * PAGESIZE) hsize <<= 1; retry: -- --- Yasuhiro Kimura ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Install of 13.0-RELEASE i386 with ZFS root hangs up
08.05.2021 2:52, Konstantin Belousov wrote: > i386 kernel uses memory up to 24G since 13.0. > > PAE only means that devices that can access full 64bit address are allowed > to avoid dma bouncing. Maybe you could tell something on similar topic? There is FreeBSD 12.2-STABLE r369567 Base12 amd64 running with Intel Atom CPU capable of long mode and addressing 8GB RAM, ASRock A330ION motherboard and two memory modules installed: 4G+2GB. Why so small "avail memory"? FreeBSD clang version 10.0.1 (g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2) CPU: Intel(R) Atom(TM) CPU 330 @ 1.60GHz (1600.03-MHz K8-class CPU) Origin="GenuineIntel" Id=0x106c2 Family=0x6 Model=0x1c Stepping=2 Features=0xbfe9fbff Features2=0x40e31d AMD Features=0x2800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 6442450944 (6144 MB) Physical memory chunk(s): 0x0001 - 0x0009dfff, 581632 bytes (142 pages) 0x00103000 - 0x001f, 1036288 bytes (253 pages) 0x02b0 - 0xd8709fff, 3586170880 bytes (875530 pages) avail memory = 3571384320 (3405 MB) Also http://www.grosbein.net/freebsd/dmidecode.txt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
