Re: X hang after Mesa update
On Fri, Aug 13, 2021 at 11:02:20PM -0700, Anindya Mukherjee wrote: > On Wed, Aug 11, 2021 at 03:09:09PM -0700, Anindya Mukherjee wrote: > > Hi, > > > > Since the recent Mesa update to 21.1.5 I have been experiencing a partial > > hang > > in X. It is triggered mostly while browsing in qutebrowser (which is the > > most > > graphically intensive program on my desktop). When this happens, the display > > freezes but the cursor can be moved and it even changes shape depending on > > what > > is actually on the screen. The system remains responsive and I can tell the > > GUI > > is responding to clicks and keyboard shortcuts, but the display does not > > update. > > I can start or quit programs blind, and also switch to text mode and back. > > > > In order to recover, even quitting my WM (FVWM2) does not work, although I > > can > > see by moving the cursor and observing its shape changing that the xenodm > > login > > screen is being displayed. Login will work blindly. All this time the > > display is > > frozen, displaying the screen contents from the time the problem was > > triggered. > > If I restart xenodm, which fully restarts X, then everything starts working > > again. > > > > My system is using the /usr/X11R6/lib/modules/dri/iris_dri.so library. I > > read > > some material on the web which seem to suggest that Mesa using this (new) > > library can cause issues on Linux, and in some cases switching to the older > > i965_dri.so can work around some of these bugs. So as a test I am using the > > line: > > export MESA_LOADER_DRIVER_OVERRIDE=i965 > > in my .xsession. The directive works and programs are now using the i965 > > library. I can't be 100% sure, but so far after intensive testing I have not > > been able to reproduce the issue. > > > > Further information about my system: > > > > kern.version=OpenBSD 6.9-current (GENERIC.MP) #164: Wed Aug 4 11:25:07 MDT > > 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > dmesg: > > > > OpenBSD 6.9-current (GENERIC.MP) #164: Wed Aug 4 11:25:07 MDT 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 34201006080 (32616MB) > > avail mem = 33148534784 (31612MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xe (94 entries) > > bios0: vendor Dell Inc. version "1.5.6" date 12/07/2016 > > bios0: Dell Inc. OptiPlex 7040 > > acpi0 at bios0: ACPI 5.0 > > acpi0: sleep states S0 S3 S4 S5 > > acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT SSDT UEFI LPIT SSDT > > SSDT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC DMAR TPM2 ASF! BGRT > > acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) > > PS2K(S3) PS2M(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) > > RP12(S4) PXSX(S4) [...] > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3393.07 MHz, 06-5e-03 > > cpu0: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > > cpu0: 256KB 64b/line 8-way L2 cache > > cpu0: smt 0, core 0, package 0 > > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > > cpu0: apic clock running at 24MHz > > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE > > cpu1 at mainbus0: apid 2 (application processor) > > cpu1: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.10 MHz, 06-5e-03 > > cpu1: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,
Re: X hang after Mesa update
On Wed, Aug 11, 2021 at 03:09:09PM -0700, Anindya Mukherjee wrote: > Hi, > > Since the recent Mesa update to 21.1.5 I have been experiencing a partial hang > in X. It is triggered mostly while browsing in qutebrowser (which is the most > graphically intensive program on my desktop). When this happens, the display > freezes but the cursor can be moved and it even changes shape depending on > what > is actually on the screen. The system remains responsive and I can tell the > GUI > is responding to clicks and keyboard shortcuts, but the display does not > update. > I can start or quit programs blind, and also switch to text mode and back. > > In order to recover, even quitting my WM (FVWM2) does not work, although I can > see by moving the cursor and observing its shape changing that the xenodm > login > screen is being displayed. Login will work blindly. All this time the display > is > frozen, displaying the screen contents from the time the problem was > triggered. > If I restart xenodm, which fully restarts X, then everything starts working > again. > > My system is using the /usr/X11R6/lib/modules/dri/iris_dri.so library. I read > some material on the web which seem to suggest that Mesa using this (new) > library can cause issues on Linux, and in some cases switching to the older > i965_dri.so can work around some of these bugs. So as a test I am using the > line: > export MESA_LOADER_DRIVER_OVERRIDE=i965 > in my .xsession. The directive works and programs are now using the i965 > library. I can't be 100% sure, but so far after intensive testing I have not > been able to reproduce the issue. > > Further information about my system: > > kern.version=OpenBSD 6.9-current (GENERIC.MP) #164: Wed Aug 4 11:25:07 MDT > 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > dmesg: > > OpenBSD 6.9-current (GENERIC.MP) #164: Wed Aug 4 11:25:07 MDT 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 34201006080 (32616MB) > avail mem = 33148534784 (31612MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xe (94 entries) > bios0: vendor Dell Inc. version "1.5.6" date 12/07/2016 > bios0: Dell Inc. OptiPlex 7040 > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT SSDT UEFI LPIT SSDT > SSDT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC DMAR TPM2 ASF! BGRT > acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) > PS2K(S3) PS2M(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) > RP12(S4) PXSX(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3393.07 MHz, 06-5e-03 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 24MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.10 MHz, 06-5e-03 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.10 MHz, 06-5e-03 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDC
X hang after Mesa update
Hi, Since the recent Mesa update to 21.1.5 I have been experiencing a partial hang in X. It is triggered mostly while browsing in qutebrowser (which is the most graphically intensive program on my desktop). When this happens, the display freezes but the cursor can be moved and it even changes shape depending on what is actually on the screen. The system remains responsive and I can tell the GUI is responding to clicks and keyboard shortcuts, but the display does not update. I can start or quit programs blind, and also switch to text mode and back. In order to recover, even quitting my WM (FVWM2) does not work, although I can see by moving the cursor and observing its shape changing that the xenodm login screen is being displayed. Login will work blindly. All this time the display is frozen, displaying the screen contents from the time the problem was triggered. If I restart xenodm, which fully restarts X, then everything starts working again. My system is using the /usr/X11R6/lib/modules/dri/iris_dri.so library. I read some material on the web which seem to suggest that Mesa using this (new) library can cause issues on Linux, and in some cases switching to the older i965_dri.so can work around some of these bugs. So as a test I am using the line: export MESA_LOADER_DRIVER_OVERRIDE=i965 in my .xsession. The directive works and programs are now using the i965 library. I can't be 100% sure, but so far after intensive testing I have not been able to reproduce the issue. Further information about my system: kern.version=OpenBSD 6.9-current (GENERIC.MP) #164: Wed Aug 4 11:25:07 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP dmesg: OpenBSD 6.9-current (GENERIC.MP) #164: Wed Aug 4 11:25:07 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34201006080 (32616MB) avail mem = 33148534784 (31612MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xe (94 entries) bios0: vendor Dell Inc. version "1.5.6" date 12/07/2016 bios0: Dell Inc. OptiPlex 7040 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT SSDT UEFI LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC DMAR TPM2 ASF! BGRT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) PS2K(S3) PS2M(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3393.07 MHz, 06-5e-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.10 MHz, 06-5e-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.10 MHz, 06-5e-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-6700 CPU @
Re: Crash when unplugging a UPS USB connection
I apologise for not following up. I relocated my UPS and a Pi is acting as the NUT server now, running several devices. As a result I am unable to easily connect my main OpenBSD desktop to test. However I am setting up another machine and will have a chance to test the fix soon. I am still running upsmon on my desktop which is working fine but this is just the net client. Thanks to everyone for the rapid fix, and in particular sthen@ for his prompt and helpful responses. Regards, Anindya
Re: gdb issue
>On 2021-02-04, Anindya Mukherjee wrote: >> I'm trying to debug the systat utility for learning purposes. I >> enabled >> -g -O0 in the Makefile, and built it in /usr/src/usr.bin/systat. It >> builds and runs fine. However, gdb cannot insert any breakspoints. I'm >> on a very recent snapshot and everything is fully patched. > >> [Switching to thread 588561] >> 0x0b5f3d6c5c8a in ?? () >> (gdb) b engine.c:1156 >> Breakpoint 1 at 0x13aca: file engine.c, line 1156. >> (gdb) info b >> Num Type Disp Enb AddressWhat >> 1 breakpoint keep y 0x00013aca in message_set at >> engine.c:1156 > >OpenBSD binaries are PIE by default. The low address is before >relocation, you will see a similar address if you use "gdb systat" and >set a breakpoint before running, but in that case it is updated when >the process starts. Thanks for reminding me about PIE! That explains everything. > >I'm not sure how to workaround this when attaching to a running process. It's not a big issue. I can start the program from within gdb. That works perfectly. > >(It doesn't directly help with this but generally you will have better >luck with gdb from ports, the old one in base doesn't cope well with >recent compilers. pkg_add gdb and use the egdb binary). I am using egdb. I switched to the base version in my listing just to see if it made any difference. Good to know it is recommended by the developers, thanks. I was playing with systat, and trying to understand how it works. I added a feature which makes the help text persistent in interactive mode. I often have it running in a tmux pane and it's useful to have the help display stay up while switching views. I'll post it in a separate thread for comments. Anyway, in the course of this I have found a couple of memory leaks. I can easily make it leak 100s of KBs of memory by updating the display in a certain way. I'll start a new thread with a fix. Regards, Anindya
Re: gdb issue
I notice now that the code from systat is mapped to very low memory addresses unlike my own programs. I think that's why I am getting errors. Curious how this is happening. >From: Anindya Mukherjee >Sent: February 4, 2021 3:59 PM >To: misc@openbsd.org >Subject: gdb issue > >Hi, > >I'm trying to debug the systat utility for learning purposes. I enabled >-g -O0 in the Makefile, and built it in /usr/src/usr.bin/systat. It >builds and runs fine. However, gdb cannot insert any breakspoints. I'm >on a very recent snapshot and everything is fully patched. > >I set kern.global_ptrace=1 and gdb can attach. Trying to insert a >breakpoint causes the following error: > >$ gdb >GNU gdb 6.3 >Copyright 2004 Free Software Foundation, Inc. >GDB is free software, covered by the GNU General Public License, and you are >welcome to change it and/or distribute copies of it under certain conditions. >Type "show copying" to see the conditions. >There is absolutely no warranty for GDB. Type "show warranty" for details. >This GDB was configured as "amd64-unknown-openbsd6.8" > >(gdb) file systat >Reading symbols from /usr/src/usr.bin/systat/systat...done. >(gdb) attach 51616 >Attaching to program: /usr/src/usr.bin/systat/systat, process 51616 >[Switching to thread 588561] >0x0b5f3d6c5c8a in ?? () >(gdb) b engine.c:1156 >Breakpoint 1 at 0x13aca: file engine.c, line 1156. >(gdb) info b >Num Type Disp Enb Address What >1 breakpoint keep y 0x00013aca in message_set at engine.c:1156 >(gdb) c >Continuing. >Warning: >Cannot insert breakpoint 1. >Error accessing memory address 0x13aca: Input/output error. > >If I build a simple C program debugging works fine. I can even debug >tmux built from git fine with either gdb or egdb. Any ideas? How >would one proceed if one was investigating a bug? > >Thanks, >Anindya
gdb issue
Hi, I'm trying to debug the systat utility for learning purposes. I enabled -g -O0 in the Makefile, and built it in /usr/src/usr.bin/systat. It builds and runs fine. However, gdb cannot insert any breakspoints. I'm on a very recent snapshot and everything is fully patched. I set kern.global_ptrace=1 and gdb can attach. Trying to insert a breakpoint causes the following error: $ gdb GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-unknown-openbsd6.8" (gdb) file systat Reading symbols from /usr/src/usr.bin/systat/systat...done. (gdb) attach 51616 Attaching to program: /usr/src/usr.bin/systat/systat, process 51616 [Switching to thread 588561] 0x0b5f3d6c5c8a in ?? () (gdb) b engine.c:1156 Breakpoint 1 at 0x13aca: file engine.c, line 1156. (gdb) info b Num Type Disp Enb AddressWhat 1 breakpoint keep y 0x00013aca in message_set at engine.c:1156 (gdb) c Continuing. Warning: Cannot insert breakpoint 1. Error accessing memory address 0x13aca: Input/output error. If I build a simple C program debugging works fine. I can even debug tmux built from git fine with either gdb or egdb. Any ideas? How would one proceed if one was investigating a bug? Thanks, Anindya
Re: Cannot mount a LAN samba share with usmb
>On 2021-02-03, tilikoom wrote: >> >> Hello - sorry if this is the wrong support channel for this - I am >> quite new to \ this stuff. I cannot mount a samba share in a LAN with >> usmb. The binary \ successfully parses my .usmb.conf but then drops >> me into some sort of assembly \ prompt that shows: Opcode: init >> >> Command: '$ usmb -c /home/myuser/.usmb.conf -d local_mount' >> Permissions: 'chmod 600 /home/myuser/.usmb.conf' Owner: 'chown >> root:wheel /home/myuser/.usmb.conf' I have it working on my machine (fairly recent snapshot). Here is my usmb.conf, in case it's useful: = rommie anindya rommie rommie /home/anindya/Downloads/mnt allow_other = Mounts with: doas usmb -c ~/Downloads/usmb.conf -u rommie Luckily the "allow_other" option works so I can set permissions as root and have read/write access as my normal user. > >FUSE on OpenBSD doesn't currently work as a normal user, only as root. Yes, unfortunately one has to be root. > >There may be other problems too, but that's the first.. Some of the options (like umask) don't work. Also the performance is not great but for quick transfers it's usable. FUSE won't have good performance anyway. Anindya
Re: Understanding memory statistics
Hi, Thank you very much for taking the time to answer these. I think I now have a better understanding and also got rid of a couple of misconceptions. I'm switching gears slightly to work on porting a couple of my favourite packages; once done I'll resume my research. Regards, Anindya From: Otto Moerbeek Sent: January 23, 2021 12:17 AM To: Anindya Mukherjee Cc: misc@openbsd.org Subject: Re: Understanding memory statistics On Sat, Jan 23, 2021 at 04:40:06AM +, Anindya Mukherjee wrote: > Thanks for the explanation! I noticed during my earlier investigation > that the source of the data size is struct vmspace::vm_dused. This is > updated mostly in uvm_mapanon and uvm_map. The second function seems to > be a more general case. I think during my file mapping the second > function is called and the part where vm_dused is updated is skipped. > I'm setting up a VM on my machine with a debug kernel (this should be an > interesting exercise) to do some exploratory kernel debugging, just to > understand the process. So far this seems to make sense. I never doubted > the system is doing the "right" thing :) > > I also had some questions about the page and the buffer caches. So far I > gathered the following facts (please correct me if I am wrong): > > OpenBSD has separate page and buffer caches, i.e., no UBC. > Q: Is this done for security reasons or due to some complication? Just > curious. page cache is a misnomer, it does not exist. UBC is the concept that file i/o via mmapped files and the read/write systemc calls use the same mechanism for caching the files in memory. One of the consequences is that if a file is both mmapped and being written to via write(2), that change is also visible in the mmapped view immediately. Vice-versa the same. We do not have that unification, a long time ago an attempt was done (you can still find that in cvs) but that was reverted since it caused all kinds of probems the author wasn't able to solve in reasonable time. So My guess it would be we do not have it because of complexity/nobody did and finished the work. So the machanism we have is a buffer cache (which in the end uses pages) used by the read and write system calls. Plus we have the mmapping mechanism used for both file mapping and anonymous mappings (mappings not corresponding to any file, like program data). > > The Inactive pages seem to back the page cache. I ran my file mapping > code a few times mapping/releasing a large file (about 300 MB) with > systat running in the uvm view, and saw the page counts for Active and > Inactive swing back and forth, keeping the total fixed. > > Then I ran md5 on another 100 MB file, and this time the Cache number in > top grew by about 100 MB, with some brief disk activity (I'm on SSD so > things are zippy). I next ran my file mapping program on it. This time > the Active pages grew by about 100 MB, raising the total by the same > amount. When the program ended, those pages moved to Inactive, keeping > the total fixed. There was no disk activity during this and Cache > remained unchanged. > > This seems to indicate that the data for the new file was copied from > the buffer cache to the page cache during the mapping, and both copies > were maintained. Mmapped file activity would indeed show in Active or Inactive pages (which one depends on how much access is done to the pages) while I/O via read or write shows up in Cache indeed. But I would not know from the top of my head if pages in the Buffer Cache from a file are explicitly copied to new pages when the same files is mmapped or just cause some changes on the page admin level so that the mapping refers to pages that are already in mem via the Buffer Cache. Thinking about it it would involve some form of unification, so likely some mem to mem copying is going on. It shows my experience is mostly userland memory management.... -Otto > > Regards, > Anindya > > From: Otto Moerbeek > Sent: January 22, 2021 12:01 AM > To: Anindya Mukherjee > Cc: misc@openbsd.org > Subject: Re: Understanding memory statistics > > On Thu, Jan 21, 2021 at 10:38:59PM +, Anindya Mukherjee wrote: > > > Hi, > > > > Just to follow up, I was playing with allocating memory from a test > > program in various ways in order to produce a situation when SIZE is > > less than RES. The following program causes this to happen. If I mmap a > > large file, the SIZE remains tiny, indicating that the mapped region is > > not counted as part of text + data + stack. Then when I go ahead and > > touch all the memory, SIZE remains tiny but RES grows to the size of the > > file. Very interesting. > > So SIZE does not include mappings backed by a file system object, but > RES does. RES only grows once the pages are touch
Problem in gstreamer1-plugins-good-1.18.3
Hi, it seems that gstreamer1-plugins-good-1.18.3 has an issue in file: /usr/local/lib/gstreamer-1.0/libgstossaudio.so. Attemting to load it causes the following error: gst-plugin-scanner:/usr/local/lib/gstreamer-1.0/libgstossaudio.so: undefined symbol '_oss_ioctl' Running the most current snapshot with updated packages. kern.version=OpenBSD 6.8-current (GENERIC.MP) #291: Sat Jan 23 12:54:25 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Thanks, Anindya
Re: Understanding memory statistics
Thanks for the explanation! I noticed during my earlier investigation
that the source of the data size is struct vmspace::vm_dused. This is
updated mostly in uvm_mapanon and uvm_map. The second function seems to
be a more general case. I think during my file mapping the second
function is called and the part where vm_dused is updated is skipped.
I'm setting up a VM on my machine with a debug kernel (this should be an
interesting exercise) to do some exploratory kernel debugging, just to
understand the process. So far this seems to make sense. I never doubted
the system is doing the "right" thing :)
I also had some questions about the page and the buffer caches. So far I
gathered the following facts (please correct me if I am wrong):
OpenBSD has separate page and buffer caches, i.e., no UBC.
Q: Is this done for security reasons or due to some complication? Just
curious.
The Inactive pages seem to back the page cache. I ran my file mapping
code a few times mapping/releasing a large file (about 300 MB) with
systat running in the uvm view, and saw the page counts for Active and
Inactive swing back and forth, keeping the total fixed.
Then I ran md5 on another 100 MB file, and this time the Cache number in
top grew by about 100 MB, with some brief disk activity (I'm on SSD so
things are zippy). I next ran my file mapping program on it. This time
the Active pages grew by about 100 MB, raising the total by the same
amount. When the program ended, those pages moved to Inactive, keeping
the total fixed. There was no disk activity during this and Cache
remained unchanged.
This seems to indicate that the data for the new file was copied from
the buffer cache to the page cache during the mapping, and both copies
were maintained.
Regards,
Anindya
From: Otto Moerbeek
Sent: January 22, 2021 12:01 AM
To: Anindya Mukherjee
Cc: misc@openbsd.org
Subject: Re: Understanding memory statistics
On Thu, Jan 21, 2021 at 10:38:59PM +0000, Anindya Mukherjee wrote:
> Hi,
>
> Just to follow up, I was playing with allocating memory from a test
> program in various ways in order to produce a situation when SIZE is
> less than RES. The following program causes this to happen. If I mmap a
> large file, the SIZE remains tiny, indicating that the mapped region is
> not counted as part of text + data + stack. Then when I go ahead and
> touch all the memory, SIZE remains tiny but RES grows to the size of the
> file. Very interesting.
So SIZE does not include mappings backed by a file system object, but
RES does. RES only grows once the pages are touched, this is demand
paging in action (anon pages act the same way).
Nice. I already suspected would be something like that, but never took
the time to find out by experimenting or code study.
Now the next quesion is if SIZE *should* include non-anonymous
pages. getrlimit(2) explicitly says RLIMIT_DATA (which is limiting
SIZE) only includes anonymous data. So that hints SIZE indeed should not
include those anon pages.
To back this up:
ps(1) lists several size related stats:
Desc Keyw Function Value
Data dsiz dsize p_vm_dsize
Resident 1 rss p_rssize p_vm_rssize
Resident 2 rsz rssize p_vm_rssize
Stack ssiz ssize p_vm_ssize
Text (code) tsiz tsize p_vm_tsize
Virtual vsiz vsize p_vm_dsize + p_vm_ssize + _vm_tsize
top(1) uses the equivalent of vsiz for SIZE and rss for RES. So this
is consistent with your observations.
I note that the rss vs rsz distinciton ps(1) mentions does not
actually seems to be implemented in ps(1).
BTW: the proper way to get the size is by opening the file and use fstat(2).
-Otto
>
> Quick and very dirty code below:
>
> /* This demonstrates why the SIZE column in OpenBSD top can be less than
> * the RES column. This is because mmapped areas of virtual memory are
> * not counted as text, data, or size, but counted as part of the
> * resident pages, when touched. The program maps a (preferably large)
> * file and then waits for the user to examine the process memory
> * statistics.
> */
>
> #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char **argv)
> {
> char ch;
> char *pch;
> void *result;
> FILE *fp;
> int fd;
> int i;
> size_t mapSize;
> int current = 0;
> const int increment = 10;
> double percent;
> double mapRatio;
>
> if (argc < 2)
> {
> printf("No file name supplied.\n");
> exit(1);
> }
>
> printf("About to mmap. Press Enter... ");
> getchar();
> fp = fopen(argv[1], "r");
> if (fp == NULL)
> {
>
Re: Understanding memory statistics
Hi,
Just to follow up, I was playing with allocating memory from a test
program in various ways in order to produce a situation when SIZE is
less than RES. The following program causes this to happen. If I mmap a
large file, the SIZE remains tiny, indicating that the mapped region is
not counted as part of text + data + stack. Then when I go ahead and
touch all the memory, SIZE remains tiny but RES grows to the size of the
file. Very interesting.
Quick and very dirty code below:
/* This demonstrates why the SIZE column in OpenBSD top can be less than
* the RES column. This is because mmapped areas of virtual memory are
* not counted as text, data, or size, but counted as part of the
* resident pages, when touched. The program maps a (preferably large)
* file and then waits for the user to examine the process memory
* statistics.
*/
#include
#include
#include
#include
#include
int main(int argc, char **argv)
{
char ch;
char *pch;
void *result;
FILE *fp;
int fd;
int i;
size_t mapSize;
int current = 0;
const int increment = 10;
double percent;
double mapRatio;
if (argc < 2)
{
printf("No file name supplied.\n");
exit(1);
}
printf("About to mmap. Press Enter... ");
getchar();
fp = fopen(argv[1], "r");
if (fp == NULL)
{
perror(NULL);
exit(1);
}
fd = fileno(fp);
if (fseek(fp, 0, SEEK_END) == -1)
{
perror(NULL);
exit(1);
}
mapSize = ftell(fp);
if (mapSize == -1)
{
perror(NULL);
exit(1);
}
if (fseek(fp, 0, SEEK_SET) == -1)
{
perror(NULL);
exit(1);
}
result = mmap(NULL, mapSize, PROT_READ, MAP_PRIVATE, fd, 0);
if(close(fd) == -1)
{
perror(NULL);
exit(1);
}
if (result == MAP_FAILED)
{
perror(NULL);
exit(1);
}
printf("%zu bytes mmapped at %p. Press Enter... ", mapSize, result);
getchar();
pch = (char *)result;
printf("Touching mapped memory... ");
mapRatio = 100.0 / mapSize;
for (i = 0; i < mapSize; i++)
{
ch = pch[i];
percent = (i + 1) * mapRatio;
if (current < percent)
{
while (current < percent)
current+= increment;
if (current > percent)
current -=increment;
if (current < 100)
{
printf("%d%%... ", current);
fflush(stdout);
current+= increment;
}
}
}
printf("100%%\nRead done. Press Enter... ");
getchar();
if(munmap(result, mapSize) == -1)
{
perror(NULL);
exit(1);
}
return 0;
}
Anindya
From: Anindya Mukherjee
Sent: January 17, 2021 6:35 PM
To: Otto Moerbeek
Cc: misc@openbsd.org
Subject: Re: Understanding memory statistics
Hi,
I had a look at the code for top and some of the VM code. I think I have
a few more answers.
The easiest one is the calculation for the tot number in top:
https://github.com/openbsd/src/blob/d098acee57f5a5eacb13200c49034ecb8cbd8c29/usr.bin/top/machine.c#L293
Here we see that it is calculated as the total page count - free page
count.
If we calculate delta = tot - active - inactive - cache - wired, we see
that it is still not zero. Typically it is a few hundred MB on my
system. This might be some "dynamic" memory being allocated by the
kernel? I don't know what that means :)
I am not totally sure, but from looking at the code, I suspect that the
SIZE which ultimately comes from struct vmspace does not take into
account shared memory mappings, or at least not all of them. The text,
data, and stack sizes are added up here:
https://github.com/openbsd/src/blob/d098acee57f5a5eacb13200c49034ecb8cbd8c29/usr.bin/top/machine.c#L70
However, I think the RES parameter also takes into account shared memory
mappings. This can explain why it is often higher than SIZE,
particularly for large programs.
Anindya
From: Anindya Mukherjee
Sent: January 12, 2021 3:22 PM
To: Otto Moerbeek
Cc: misc@openbsd.org
Subject: Re: Understanding memory statistics
Hi Otto,
Thank you for your kind reply and explanations. They helped me
understand a few more things. I have some basic familiarity with the
concepts but not so much with OpenBSD internals, although I have
Re: Understanding memory statistics
Hi, I had a look at the code for top and some of the VM code. I think I have a few more answers. The easiest one is the calculation for the tot number in top: https://github.com/openbsd/src/blob/d098acee57f5a5eacb13200c49034ecb8cbd8c29/usr.bin/top/machine.c#L293 Here we see that it is calculated as the total page count - free page count. If we calculate delta = tot - active - inactive - cache - wired, we see that it is still not zero. Typically it is a few hundred MB on my system. This might be some "dynamic" memory being allocated by the kernel? I don't know what that means :) I am not totally sure, but from looking at the code, I suspect that the SIZE which ultimately comes from struct vmspace does not take into account shared memory mappings, or at least not all of them. The text, data, and stack sizes are added up here: https://github.com/openbsd/src/blob/d098acee57f5a5eacb13200c49034ecb8cbd8c29/usr.bin/top/machine.c#L70 However, I think the RES parameter also takes into account shared memory mappings. This can explain why it is often higher than SIZE, particularly for large programs. Anindya From: Anindya Mukherjee Sent: January 12, 2021 3:22 PM To: Otto Moerbeek Cc: misc@openbsd.org Subject: Re: Understanding memory statistics Hi Otto, Thank you for your kind reply and explanations. They helped me understand a few more things. I have some basic familiarity with the concepts but not so much with OpenBSD internals, although I have been using it. I need to research a bit more, but in my next reply I'll try to answer my questions, with some examples. I love OpenBSD and can program in C, so I think given time I'll be able to make some contributions to it. I have been working on tmux and it's been a lot of fun. I got a lot of help and encouragement from Nicholas Mariott. Best, Anindya From: Otto Moerbeek Sent: January 10, 2021 11:42 PM To: Anindya Mukherjee Cc: misc@openbsd.org Subject: Re: Understanding memory statistics On Sun, Jan 10, 2021 at 09:34:49PM +0000, Anindya Mukherjee wrote: > Hi, I'm trying to understand the various numbers reported for memory > usage from top, vmstat, and systat. I'm running OpenBSD 6.8 on a Dell > Optiplex 7040 with an i7 6700, 3.4 Ghz and 32 GB RAM. The GPU is an > Intel HD Graphics 530, integrated. Everything is running smoothly. For > my own edification, I have a few questions. I searched the mailing lists > for similar questions in the past, and found some, but they did not > fully satisfy my curiosity. > > dmesg reports: > real mem = 34201006080 (32616MB) > avail mem = 33149427712 (31613MB) > I think the difference is due to the GPU reserving some memory. That might be, I think it at least includes mem used by the kernel for its code and static data. > Q: Is there a way to view the total amount of video memory, the amount > currently being used, and the GPU usage? AFAIK not. Some bioses have settings for the video mem used (if you have it shared with main mem). > > When I run top, it reports the following memory usage: > Memory: Real: 1497M/4672M act/tot Free: 26G Cache: 2236M Swap: 0K/11G > If I sum up the RES numbers for all the processes, it is close to the > act number = 1497 M (this is mostly due to Firefox). I read that the > cache number is included in tot, but even if I subtract cache and act > from tot there is 939 MB left. > Q: What is this 939 MB being used for, assuming the above makes sense? inactive pages? > Q: What is the cache number indicating exactly? memoy used for file systemn caching. > > If I sum up tot + free * 1024 I get 31296 MB, which less than the 31613 > MB of available memory reported by dmesg. I initially assumed that the > difference might be kernel wired memory. However the uvm view of systat > shows 7514 wired pages = approx 30 MB which is very small. > Q: What is the remaining memory being used for? I think you are looking at dynamic allocations done by the kernel. > Q: What is in kernel wired memory? In particular, is the file system > cache in kernel wired memory or in the cache number? Kernel wired means data pages allocated by the kernel that will not be paged out. The file system mem will also not be paged out (when evecting those they are discarded if not dirty or written to the file if dirty) but the file system cache pages are not in the wired count. > In the man page for systat(1) the active memory is described as being > used by processes active in the last 20 seconds (recently), while the > total is for all processes. These are the same two numbers as act and > tot in top, and act = avm as reported by vmstat. This confused me > because adding up the RES sizes of all the processes I get nowhere near > to tot (even after subtracting cache). Accounting of shared pages is hard and ambiguous. To illustrate: if you switch on S in top, you'll see a bunch of kenel
Re: firefox crashed, no web access after attempted fix
Hi, When you start Firefox with a new profile, and before restoring any files, can you browse the web normally? If that works then it might be better to just copy the places.sqlite file to the new profile folder, and install add-ons and such manually in the new profile. Anindya
Re: Understanding memory statistics
Hi Otto, Thank you for your kind reply and explanations. They helped me understand a few more things. I have some basic familiarity with the concepts but not so much with OpenBSD internals, although I have been using it. I need to research a bit more, but in my next reply I'll try to answer my questions, with some examples. I love OpenBSD and can program in C, so I think given time I'll be able to make some contributions to it. I have been working on tmux and it's been a lot of fun. I got a lot of help and encouragement from Nicholas Mariott. Best, Anindya From: Otto Moerbeek Sent: January 10, 2021 11:42 PM To: Anindya Mukherjee Cc: misc@openbsd.org Subject: Re: Understanding memory statistics On Sun, Jan 10, 2021 at 09:34:49PM +, Anindya Mukherjee wrote: > Hi, I'm trying to understand the various numbers reported for memory > usage from top, vmstat, and systat. I'm running OpenBSD 6.8 on a Dell > Optiplex 7040 with an i7 6700, 3.4 Ghz and 32 GB RAM. The GPU is an > Intel HD Graphics 530, integrated. Everything is running smoothly. For > my own edification, I have a few questions. I searched the mailing lists > for similar questions in the past, and found some, but they did not > fully satisfy my curiosity. > > dmesg reports: > real mem = 34201006080 (32616MB) > avail mem = 33149427712 (31613MB) > I think the difference is due to the GPU reserving some memory. That might be, I think it at least includes mem used by the kernel for its code and static data. > Q: Is there a way to view the total amount of video memory, the amount > currently being used, and the GPU usage? AFAIK not. Some bioses have settings for the video mem used (if you have it shared with main mem). > > When I run top, it reports the following memory usage: > Memory: Real: 1497M/4672M act/tot Free: 26G Cache: 2236M Swap: 0K/11G > If I sum up the RES numbers for all the processes, it is close to the > act number = 1497 M (this is mostly due to Firefox). I read that the > cache number is included in tot, but even if I subtract cache and act > from tot there is 939 MB left. > Q: What is this 939 MB being used for, assuming the above makes sense? inactive pages? > Q: What is the cache number indicating exactly? memoy used for file systemn caching. > > If I sum up tot + free * 1024 I get 31296 MB, which less than the 31613 > MB of available memory reported by dmesg. I initially assumed that the > difference might be kernel wired memory. However the uvm view of systat > shows 7514 wired pages = approx 30 MB which is very small. > Q: What is the remaining memory being used for? I think you are looking at dynamic allocations done by the kernel. > Q: What is in kernel wired memory? In particular, is the file system > cache in kernel wired memory or in the cache number? Kernel wired means data pages allocated by the kernel that will not be paged out. The file system mem will also not be paged out (when evecting those they are discarded if not dirty or written to the file if dirty) but the file system cache pages are not in the wired count. > In the man page for systat(1) the active memory is described as being > used by processes active in the last 20 seconds (recently), while the > total is for all processes. These are the same two numbers as act and > tot in top, and act = avm as reported by vmstat. This confused me > because adding up the RES sizes of all the processes I get nowhere near > to tot (even after subtracting cache). Accounting of shared pages is hard and ambiguous. To illustrate: if you switch on S in top, you'll see a bunch of kenel space processes al at SIZE 0 and the same RES size. They do share the same (kernel) memory. > > There is another thing that confused me in the top output. At first I > assumed that SIZE is the total virtual memory size of the process > (allocated), while RES is the resident size. For example, this is so on > Linux and hence in that case by definition SIZE should always be greater > than RES. However here in many cases SIZE < RES. I am unsure how that is caused. It is possibly a shared pages thing. > > I read in the man page for top that SIZE is actually text + data + stack > for the process. However this did not clear up my confusion or > misunderstanding. Perhaps something to do with shared memory not being > counted? > Q: How can SIZE be less that RES? An example showing how this could > happen would be really helpful. I guess doing some experimenting and code analysis and share your findings. > > Q: Finally, where can I find documentation about the classification for > memory pages (active, inactive, wired, etc.)? I suspect some digging > around in the source in order, but could use some pointers. The start would be man uvm_init. But the rest is code. > > I hope these make sense and are not too pedantic. Looking forward to > comments from the experts, thanks! > > Anindya Mukherjee > -Otto
Understanding memory statistics
Hi, I'm trying to understand the various numbers reported for memory usage from top, vmstat, and systat. I'm running OpenBSD 6.8 on a Dell Optiplex 7040 with an i7 6700, 3.4 Ghz and 32 GB RAM. The GPU is an Intel HD Graphics 530, integrated. Everything is running smoothly. For my own edification, I have a few questions. I searched the mailing lists for similar questions in the past, and found some, but they did not fully satisfy my curiosity. dmesg reports: real mem = 34201006080 (32616MB) avail mem = 33149427712 (31613MB) I think the difference is due to the GPU reserving some memory. Q: Is there a way to view the total amount of video memory, the amount currently being used, and the GPU usage? When I run top, it reports the following memory usage: Memory: Real: 1497M/4672M act/tot Free: 26G Cache: 2236M Swap: 0K/11G If I sum up the RES numbers for all the processes, it is close to the act number = 1497 M (this is mostly due to Firefox). I read that the cache number is included in tot, but even if I subtract cache and act from tot there is 939 MB left. Q: What is this 939 MB being used for, assuming the above makes sense? Q: What is the cache number indicating exactly? If I sum up tot + free * 1024 I get 31296 MB, which less than the 31613 MB of available memory reported by dmesg. I initially assumed that the difference might be kernel wired memory. However the uvm view of systat shows 7514 wired pages = approx 30 MB which is very small. Q: What is the remaining memory being used for? Q: What is in kernel wired memory? In particular, is the file system cache in kernel wired memory or in the cache number? In the man page for systat(1) the active memory is described as being used by processes active in the last 20 seconds (recently), while the total is for all processes. These are the same two numbers as act and tot in top, and act = avm as reported by vmstat. This confused me because adding up the RES sizes of all the processes I get nowhere near to tot (even after subtracting cache). There is another thing that confused me in the top output. At first I assumed that SIZE is the total virtual memory size of the process (allocated), while RES is the resident size. For example, this is so on Linux and hence in that case by definition SIZE should always be greater than RES. However here in many cases SIZE < RES. I read in the man page for top that SIZE is actually text + data + stack for the process. However this did not clear up my confusion or misunderstanding. Perhaps something to do with shared memory not being counted? Q: How can SIZE be less that RES? An example showing how this could happen would be really helpful. Q: Finally, where can I find documentation about the classification for memory pages (active, inactive, wired, etc.)? I suspect some digging around in the source in order, but could use some pointers. I hope these make sense and are not too pedantic. Looking forward to comments from the experts, thanks! Anindya Mukherjee
