Re: Only 1TB RAM out of 1.5TB on amd64
On Wed, Mar 27, 2024 at 05:55:20PM +0200, Konstantin Belousov wrote: > On Wed, Mar 27, 2024 at 03:01:11AM +0100, Bernd Walter wrote: > > Same Problem with current: > > reeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964: Thu Mar 14 02:58:39 UTC > > 2024 > > > > real memory = 1649265344512 (1572862 MB) > > avail memory = 1057118396416 (1008146 MB) > Real memory is really the max physical address of the valid byte. > If you have holes in the phys map, real memory should reflect these > holes. Avail memory is the total memory as reported by EFI map. Damn - thank you very much. That was the answer. I was under the impression that the machine has 1.5T installed, but in fact it has only 1T installed. I was expecting holes because of NUMA, but my assumption was more that the holes would led to memory being outside of the direct map space. > > Verify all that by looking at sysctl machdep.efi_map output. > > > > On Fri, Mar 22, 2024 at 07:54:06PM +0100, Bernd Walter wrote: > > > .. > > > real memory = 1649265344512 (1572862 MB) > > > avail memory = 105713704 (1008166 MB) > > > .. > > > > > > I suspect address space issues, but don't know for sure. > > > Changing NUMA nodes per socket in the BIOS had an influence to make it > > > worse, but not better. > > > > > > > > > Copyright (c) 1992-2021 The FreeBSD Project. > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > The Regents of the University of California. All rights reserved. > > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > > FreeBSD 13.3-RELEASE releng/13.3-n257428-80d2b634ddf0 GENERIC amd64 > > > FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git > > > llvmorg-17.0.6-0-g6009708b4367) > > > VT(efifb): resolution 1024x768 > > > CPU: AMD EPYC 7352 24-Core Processor (2300.07-MHz > > > K8-class CPU) > > > Origin="AuthenticAMD" Id=0x830f10 Family=0x17 Model=0x31 Stepping=0 > > > > > > Features=0x178bfbff > > > > > > Features2=0x7ed8320b > > > AMD Features=0x2e500800 > > > AMD > > > Features2=0x75c237ff > > > Structured Extended > > > Features=0x219c91a9 > > > Structured Extended Features2=0x44 > > > XSAVE Features=0xf > > > AMD Extended Feature Extensions ID > > > EBX=0x18cf757 > > > SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 > > > TSC: P-state invariant, performance statistics > > > real memory = 1649265344512 (1572862 MB) > > > avail memory = 105713704 (1008166 MB) > > > Event timer "LAPIC" quality 600 > > > ACPI APIC Table: > > > FreeBSD/SMP: Multiprocessor System Detected: 96 CPUs > > > FreeBSD/SMP: 2 package(s) x 8 cache groups x 3 core(s) x 2 hardware > > > threads > > > random: registering fast source Intel Secure Key RNG > > > random: fast provider: "Intel Secure Key RNG" > > > random: unblocking device. > > > ioapic0 irqs 0-23 > > > ioapic1 irqs 24-55 > > > ioapic2 irqs 56-87 > > > ioapic3 irqs 88-119 > > > ioapic4 irqs 120-151 > > > ioapic5 irqs 152-183 > > > ioapic6 irqs 184-215 > > > ioapic7 irqs 216-247 > > > ioapic8 irqs 248-279 > > > Launching APs: 32 30 34 13 14 16 23 21 19 24 28 9 86 10 87 7 26 37 39 41 > > > 45 46 43 66 71 69 54 57 59 80 82 78 49 53 51 60 65 62 84 88 91 95 74 73 > > > 76 92 33 40 11 2 27 22 20 5 44 18 15 36 6 8 25 89 79 85 93 56 48 70 31 81 > > > 12 50 38 77 55 63 75 58 1 90 29 94 52 72 67 83 35 42 61 64 68 47 4 17 3 > > > random: entropy device external interface > > > kbd1 at kbdmux0 > > > .. > > > > > > kern.maxphys: 1048576 > > > hw.physmem: 109930544 > > > hw.usermem: 1091323355136 > > > hw.realmem: 1649265344512 > > > vm.phys_locality: > > > 0: 10 32 > > > 1: 32 10 > > > > > > vm.phys_segs: > > > SEGMENT 0: > > > > > > start: 0x1 > > > end: 0xa > > > domain:0 > > > free list: 0x81ec7ea0 > > > > > > SEGMENT 1: > > > > > > start: 0x10 > > > end: 0x100 > > > domain:0 > > > free list: 0x81ec7ea0 > > > > > > SEGMENT 2: > > > > > > start: 0x100 > > > end: 0x7400 > > > domain:0 > > > free list: 0x81ec7c30 > > > > > > SEGMENT 3: > > > > > > start: 0x74043000 > > > end: 0x75db > > > domain:0 > > > free list: 0x81ec7c30 > > > > > > SEGMENT 4: > > > > > > start: 0x7600 > > > end: 0x963b8000 > > > domain:0 > > > free list: 0x81ec7c30 > > > > > > SEGMENT 5: > > > > > > start: 0x963c2000 > > > end: 0x963f9000 > > > domain:0 > > > free list: 0x81ec7c30 > > > > > > SEGMENT 6: > > > > > > start: 0x9650 > > > end: 0xa57f7000 > > > domain:0 > > > free list: 0x81ec7c30 > > > > > > SEGMENT 7: > > > > > > start: 0xa8e96000 > > > end: 0xac00 > > > domain:0 > > > free list: 0x81ec7c30 > > > > > > SEGMENT 8: > > > > > > start: 0x1e000 > > > end: 0x7d0780 > > > domain:0 > > > free list: 0x81ec79c0 > > > > > >
Re: Only 1TB RAM out of 1.5TB on amd64
On Wed, Mar 27, 2024 at 03:01:11AM +0100, Bernd Walter wrote: > Same Problem with current: > reeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964: Thu Mar 14 02:58:39 UTC 2024 > > real memory = 1649265344512 (1572862 MB) > avail memory = 1057118396416 (1008146 MB) Real memory is really the max physical address of the valid byte. If you have holes in the phys map, real memory should reflect these holes. Avail memory is the total memory as reported by EFI map. Verify all that by looking at sysctl machdep.efi_map output. > > On Fri, Mar 22, 2024 at 07:54:06PM +0100, Bernd Walter wrote: > > .. > > real memory = 1649265344512 (1572862 MB) > > avail memory = 105713704 (1008166 MB) > > .. > > > > I suspect address space issues, but don't know for sure. > > Changing NUMA nodes per socket in the BIOS had an influence to make it > > worse, but not better. > > > > > > Copyright (c) 1992-2021 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 13.3-RELEASE releng/13.3-n257428-80d2b634ddf0 GENERIC amd64 > > FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git > > llvmorg-17.0.6-0-g6009708b4367) > > VT(efifb): resolution 1024x768 > > CPU: AMD EPYC 7352 24-Core Processor (2300.07-MHz K8-class > > CPU) > > Origin="AuthenticAMD" Id=0x830f10 Family=0x17 Model=0x31 Stepping=0 > > > > Features=0x178bfbff > > > > Features2=0x7ed8320b > > AMD Features=0x2e500800 > > AMD > > Features2=0x75c237ff > > Structured Extended > > Features=0x219c91a9 > > Structured Extended Features2=0x44 > > XSAVE Features=0xf > > AMD Extended Feature Extensions ID > > EBX=0x18cf757 > > SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 > > TSC: P-state invariant, performance statistics > > real memory = 1649265344512 (1572862 MB) > > avail memory = 105713704 (1008166 MB) > > Event timer "LAPIC" quality 600 > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 96 CPUs > > FreeBSD/SMP: 2 package(s) x 8 cache groups x 3 core(s) x 2 hardware threads > > random: registering fast source Intel Secure Key RNG > > random: fast provider: "Intel Secure Key RNG" > > random: unblocking device. > > ioapic0 irqs 0-23 > > ioapic1 irqs 24-55 > > ioapic2 irqs 56-87 > > ioapic3 irqs 88-119 > > ioapic4 irqs 120-151 > > ioapic5 irqs 152-183 > > ioapic6 irqs 184-215 > > ioapic7 irqs 216-247 > > ioapic8 irqs 248-279 > > Launching APs: 32 30 34 13 14 16 23 21 19 24 28 9 86 10 87 7 26 37 39 41 45 > > 46 43 66 71 69 54 57 59 80 82 78 49 53 51 60 65 62 84 88 91 95 74 73 76 92 > > 33 40 11 2 27 22 20 5 44 18 15 36 6 8 25 89 79 85 93 56 48 70 31 81 12 50 > > 38 77 55 63 75 58 1 90 29 94 52 72 67 83 35 42 61 64 68 47 4 17 3 > > random: entropy device external interface > > kbd1 at kbdmux0 > > .. > > > > kern.maxphys: 1048576 > > hw.physmem: 109930544 > > hw.usermem: 1091323355136 > > hw.realmem: 1649265344512 > > vm.phys_locality: > > 0: 10 32 > > 1: 32 10 > > > > vm.phys_segs: > > SEGMENT 0: > > > > start: 0x1 > > end: 0xa > > domain:0 > > free list: 0x81ec7ea0 > > > > SEGMENT 1: > > > > start: 0x10 > > end: 0x100 > > domain:0 > > free list: 0x81ec7ea0 > > > > SEGMENT 2: > > > > start: 0x100 > > end: 0x7400 > > domain:0 > > free list: 0x81ec7c30 > > > > SEGMENT 3: > > > > start: 0x74043000 > > end: 0x75db > > domain:0 > > free list: 0x81ec7c30 > > > > SEGMENT 4: > > > > start: 0x7600 > > end: 0x963b8000 > > domain:0 > > free list: 0x81ec7c30 > > > > SEGMENT 5: > > > > start: 0x963c2000 > > end: 0x963f9000 > > domain:0 > > free list: 0x81ec7c30 > > > > SEGMENT 6: > > > > start: 0x9650 > > end: 0xa57f7000 > > domain:0 > > free list: 0x81ec7c30 > > > > SEGMENT 7: > > > > start: 0xa8e96000 > > end: 0xac00 > > domain:0 > > free list: 0x81ec7c30 > > > > SEGMENT 8: > > > > start: 0x1e000 > > end: 0x7d0780 > > domain:0 > > free list: 0x81ec79c0 > > > > SEGMENT 9: > > > > start: 0x1019000 > > end: 0x1797de0 > > domain:1 > > free list: 0x81ec8110 > > > > SEGMENT 10: > > > > start: 0x17ffdc0 > > end: 0x17ffdde7000 > > domain:1 > > free list: 0x81ec8110 > > > > > > > > -- > > B.Walter https://www.bwct.de > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > > > > -- > B.Walter https://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Re: CURRENT on laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230
El día miércoles, marzo 27, 2024 a las 10:37:48a. m. +0100, Matthias Apitz escribió: > > Hello, > > I bought the laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 and managed to > boot FreeBSD with boot verbose messages from an USB key and I'm able to > login. The /var/log/messages are here > http://www.unixarea.de/ASUS-VivoBook-Pro-14-messages.txt A 'gpart list nda0' is here http://www.unixarea.de/nda0.txt Actual the (Windows) partitions are: # egrep 'Name:|Mediasize:' nda0.txt 1. Name: nda0p1 Mediasize: 272629760 (260M) 2. Name: nda0p2 Mediasize: 16777216 (16M) 3. Name: nda0p3 Mediasize: 510507949568 (475G) 4. Name: nda0p4 Mediasize: 1101004800 (1.0G) 5. Name: nda0p5 Mediasize: 209715200 (200M) 1. Name: nda0 Mediasize: 512110190592 (477G) A 'pciconf -lv' is here: http://www.unixarea.de/pciconf.txt The WLAN card seems to be: none2@pci0:1:0:0: class=0x028000 rev=0x00 hdr=0x00 vendor=0x14c3 device=0x7961 subvendor=0x1a3b subdevice=0x4680 vendor = 'MEDIATEK Corp.' device = 'MT7921 802.11ax PCI Express Wireless Network Adapter' class = network Perhaps not supported until today: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264300 An attached USB mouse is detected and works. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
Re: truss -f timeout 2 sleep 10 causes breakage
On Wed, Mar 27, 2024 at 01:00:07PM +0100, Mateusz Guzik wrote: > Top of main, but I reproduced it on stable/14-e64d827d3 as well. > > Mere "timeout 2 sleep 10" correctly times out. > > Running "truss -f timeout 2 sleep 10" prevents timeout from killing > sleep and the entire thing refuses to exit, truss has to be killed off > with SIGKILL. The issue is because debugger can stop the debuggee, which makes the single threading never succeed. Supposed fix is in https://reviews.freebsd.org/D44523 the cost is that in principle, the debuggee now can try to break out of the reaper kill hammer, with the help of debugger. But this setup is arguably too convoluted: you either control the process with reaper, or with debugger. > > Here is the best part: after doing the above, going back to mere > "timeout 2 sleep 10" (without truss!) no longer works -- timeout gets > stuck in the kernel: mi_switch sleepq_catch_signals sleepq_wait_sig > _sx_xlock_hard stop_all_proc_block kern_procctl sys_procctl > amd64_syscall fast_syscall_common This is because the threaded workqueue thread is stuck waiting for single-threading of the victim. > > It does react to -9 though. Not the workqueue, which is the problem.
Re: truss -f timeout 2 sleep 10 causes breakage
Mateusz Guzik writes: > Top of main, but I reproduced it on stable/14-e64d827d3 as well. Confirmed on 14.0-RELEASE-p5. > Mere "timeout 2 sleep 10" correctly times out. > > Running "truss -f timeout 2 sleep 10" prevents timeout from killing > sleep This is sort of expected as truss(1) uses ptrace(2) which breaks the parent-child relationship, so you should never use `truss -f` with a command that expects to control its children. > and the entire thing refuses to exit, truss has to be killed off > with SIGKILL. This, however, is not expected. > Here is the best part: after doing the above, going back to mere > "timeout 2 sleep 10" (without truss!) no longer works Neither is this. DES -- Dag-Erling Smørgrav - d...@freebsd.org
truss -f timeout 2 sleep 10 causes breakage
Top of main, but I reproduced it on stable/14-e64d827d3 as well. Mere "timeout 2 sleep 10" correctly times out. Running "truss -f timeout 2 sleep 10" prevents timeout from killing sleep and the entire thing refuses to exit, truss has to be killed off with SIGKILL. Here is the best part: after doing the above, going back to mere "timeout 2 sleep 10" (without truss!) no longer works -- timeout gets stuck in the kernel: mi_switch sleepq_catch_signals sleepq_wait_sig _sx_xlock_hard stop_all_proc_block kern_procctl sys_procctl amd64_syscall fast_syscall_common It does react to -9 though. -- Mateusz Guzik
Re: CURRENT on laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230
On Wed, Mar 27, 2024 at 12:38 PM Matthias Apitz wrote: > > > Hello, > > I bought the laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 and managed to > boot FreeBSD with boot verbose messages from an USB key and I'm able to > login. The /var/log/messages are here > http://www.unixarea.de/ASUS-VivoBook-Pro-14-messages.txt `pciconf -lv` would be useful too.
CURRENT on laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230
Hello, I bought the laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 and managed to boot FreeBSD with boot verbose messages from an USB key and I'm able to login. The /var/log/messages are here http://www.unixarea.de/ASUS-VivoBook-Pro-14-messages.txt I can identify the harddisk as nda0 (correct), but don't see any mouse and WLAN card. I will also boot an Ubuntu 22.04.4 from USB, maybe this gives more hints about hardware details. Thanks for any comments. I have 30 days to return the laptop to the store. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub
