Shared memory segments are note removed after process exit
I'm running a tandem of Xvfb + x11vnc on a headless box. x11vnc runs as _x11 user. This stack works pretty well for me until one of the processes restarts. When Xvfb restarts, it no longer enabled SHM extension. # Xvfb MIT-SHM extension disabled due to lack of kernel support When I check ipcs, I see a lot of shm segments: # ipcs | grep _x11 | grep wc -l 137 Both processes are dead at this stage, so I'm not sure why those shm segments are not collected? When I manually remove them using ipcrm -m , I can restart Xvfb and it will happily enable SHM extension. x11vnc will also work as well. Is that an expected behaviour? How can I ensure shm segments are purged when processes are no longer running? Cheers, Chris signature.asc Description: PGP signature
Re: Shared memory segments are note removed after process exit
On Sat, 06 Feb 2021 01:43:09 +, Chris Narkiewicz wrote: > When I check ipcs, I see a lot of shm segments: > > # ipcs | grep _x11 | grep wc -l > 137 > > Both processes are dead at this stage, so I'm not sure why those shm > segments are not collected? This is expected behavior. Shared memory segments are not garbage collected when a process exits (or when the last reference to them is removed). They need to be explicitly removed, either by one of the processes that is using them or manually using ipcrm(1). - todd
Groups
0 C Pakistan P Islamabad T Islamabad F Irregular O OpenBSD users of Pakistan I Abdullah Khabir M abdullah@abdullah.today U https://abdullah.today N OpenBSD signature.asc Description: PGP signature
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
groups update
0 Canada BC Vancouver Irregular VanBUG Sha'ul ben Avraham van...@riseup.net Subscribe van...@lists.riseup.net https://lists.riseup.net/www/info/vanbug OpenBSD, FreeBSD
groups new
0 Canada BC Vancouver Irregular VanBUG Sha'ul ben Avraham van...@riseup.net https://lists.riseup.net/www/info/vanbug *BSD
Re: AX201 Surface Pro 7
On Fri, Feb 05, 2021 at 11:38:24AM +0100, Fredrik Engberg wrote: > Hey > > I got myself a Surface Pro 7 and thought it had a supported AX201 wifi chip > in it but after some looking around in the source I couldn’t find the device > ID in there so I tried myself to add it to pcidevs and pcidevs.h. > I also added the pci_products to if_iwx.c and pcidevs_data.h. I got it to > show up in dmesg. But I get “iwx0: unsupported AX201 adapter". I think Im in > a bit of deep water here and my knowledge is to low for it. Im wondering if > someone else has gotten this AX1650 card to work? > > Here is pcidump from the machine: > > 0:20:3: Intel unknown > 0x: Vendor ID: 8086, Product ID: 34f0 > 0x0004: Command: 0006, Status: 0010 > 0x0008: Class: 02 Network, Subclass: 80 Miscellaneous, > Interface: 00, Revision: 30 > 0x000c: BIST: 00, Header Type: 80, Latency Timer: 00, > Cache Line Size: 00 > 0x0010: BAR mem 64bit addr: 0x006002134000/0x4000 > 0x0018: BAR empty () > 0x001c: BAR empty () > 0x0020: BAR empty () > 0x0024: BAR empty () > 0x0028: Cardbus CIS: > 0x002c: Subsystem Vendor ID: 8086 Product ID: 0074 > 0x0030: Expansion ROM Base Address: > 0x0038: > 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00 > 0x00c8: Capability 0x01: Power Management > State: D0 > 0x00d0: Capability 0x05: Message Signalled Interrupts (MSI) > Enabled: no > 0x0040: Capability 0x10: PCI Express > Max Payload Size: 128 / 128 bytes > Max Read Request Size: 128 bytes > 0x0100: Enhanced Capability 0x18: Latency Tolerance Reporting > 0x0164: Enhanced Capability 0x0b: Vendor-Specific > 0x0080: Capability 0x11: Extended Message Signalled Interrupts (MSI-X) > Enabled: yes; table size 16 (BAR 0:8192) > > > //Fredrik Engberg > > This device needs firmware "Qu-b0-hr-b0-48" You can find the firmware image here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git The iwx driver will need corresponding changes to detect your device and load this specific firmware image. Then it will hopefully work.
AX201 Surface Pro 7
Hey I got myself a Surface Pro 7 and thought it had a supported AX201 wifi chip in it but after some looking around in the source I couldn’t find the device ID in there so I tried myself to add it to pcidevs and pcidevs.h. I also added the pci_products to if_iwx.c and pcidevs_data.h. I got it to show up in dmesg. But I get “iwx0: unsupported AX201 adapter". I think Im in a bit of deep water here and my knowledge is to low for it. Im wondering if someone else has gotten this AX1650 card to work? Here is pcidump from the machine: 0:20:3: Intel unknown 0x: Vendor ID: 8086, Product ID: 34f0 0x0004: Command: 0006, Status: 0010 0x0008: Class: 02 Network, Subclass: 80 Miscellaneous, Interface: 00, Revision: 30 0x000c: BIST: 00, Header Type: 80, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0x006002134000/0x4000 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 8086 Product ID: 0074 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00 0x00c8: Capability 0x01: Power Management State: D0 0x00d0: Capability 0x05: Message Signalled Interrupts (MSI) Enabled: no 0x0040: Capability 0x10: PCI Express Max Payload Size: 128 / 128 bytes Max Read Request Size: 128 bytes 0x0100: Enhanced Capability 0x18: Latency Tolerance Reporting 0x0164: Enhanced Capability 0x0b: Vendor-Specific 0x0080: Capability 0x11: Extended Message Signalled Interrupts (MSI-X) Enabled: yes; table size 16 (BAR 0:8192) //Fredrik Engberg
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. I'm not sure how to workaround this when attaching to a running process. (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).
