Re: pf queues
On Wed, Nov 29, 2023 at 12:12:02AM +0300, 4 wrote: > i haven't used queues for a long time, but now there is a need. previously, > queues had not only a hierarchy, but also a priority. now there is no > priority, only the hierarchy exists. i was surprised, but i thought that this > is quite in the way of Theo, and it is possible to simplify the queue > mechanism only to the hierarchy, meaning that if a queue standing higher in > the hierarchy, and he priority is higher. but in order for it to work this > way, it is necessary to allow assigning packets to any queue, and not just to > the last one, because when you assign only to the last queue in the > hierarchy, then in practice it means that you have no hierarchy and no > queues. and although the rule with the assignment to a queue above the last > one is not syntactically incorrect, but in practice the assignment is not > performed, and the packets fall into the default(last) queue. am i missing > something or is it really idiocy that humanity has not seen yet? > How long ago is it that you did anything with queues? the older ALTQ system was replaced by a whole new system back in OpenBSD 5.5 (or actually, altq lived on as oldqeueue through 5.6), and the syntax is both very different and in most things much simpler to deal with. The most extensive treatment available is in The Book of PF, 3rd edition (actually the introduction of the new queues was the reason for doing that revision). If for some reason the book is out of reach, you can likely glean most of the useful information from the relevant slides in the PF tutorial https://home.nuug.no/~peter/pftutorial/ with the traffic shaping part starting at https://home.nuug.no/~peter/pftutorial/#68 -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
pf queues
i haven't used queues for a long time, but now there is a need. previously, queues had not only a hierarchy, but also a priority. now there is no priority, only the hierarchy exists. i was surprised, but i thought that this is quite in the way of Theo, and it is possible to simplify the queue mechanism only to the hierarchy, meaning that if a queue standing higher in the hierarchy, and he priority is higher. but in order for it to work this way, it is necessary to allow assigning packets to any queue, and not just to the last one, because when you assign only to the last queue in the hierarchy, then in practice it means that you have no hierarchy and no queues. and although the rule with the assignment to a queue above the last one is not syntactically incorrect, but in practice the assignment is not performed, and the packets fall into the default(last) queue. am i missing something or is it really idiocy that humanity has not seen yet?
Re: cumbersome mtree
Michael Hekeler wrote: > > mtree -c -f /etc/mtree/4.4BSD.dist -K uid,guid,mode -p /usr/games > > -e > > what is your intention when using these flags? What do you want to do? I wanted to use mtree to script a tool flexible enough for everyone consumption but I think I will wait better times both reading you and Marc feedback. Thank you both for your time. == Nowarez Market
Re : mkdir
Interesting... because I was testing accents on my French keyboard. De : Crystal Kolipe Envoyé : dimanche 26 novembre 2023 22:54 À : Pascal Deveaux Cc : Zé Loff ; misc@openbsd.org Objet : Re: mkdir On Thu, Nov 23, 2023 at 05:14:42PM +, Pascal Deveaux wrote: > all files are present in /bin/ mkdir. Oddly enough after several attempts I > was able to create the directory You probably typed: $ mkdir[some unprintable character] test For example, if you type 'mkdir', then hit ALT-ENTER, then ' test', you will get exactly the error message you first reported: ksh: mkdir: not found Then, I'm guessing that instead of typing it again, you just hit 'cursor up' to get the line back from the shell's command history, which would include the unprintable character. Eventually, when you typed it again without the unprintable character, it worked. Try: $ mkdir[ALT-ENTER] test 2> /dev/stdout | hexdump -C And you will get the following: 6b 73 68 3a 20 6d 6b 64 69 72 8d 3a 20 6e 6f 74 |ksh: mkdir.: not| 0010 20 66 6f 75 6e 64 0a | found.| 0017 Notice the 0x8d byte following 'mkdir'. This is 0x0d, (ENTER), plus 0x80 as a result of seting bit 7 by pressing ALT.
Re: OpenBSD SMP - BGPd - send_rtmsg: action 1, prefix A.B.C.D/24: No buffer space available - panic: malloc: out of space in kmem_map
Le 28/11/2023 à 17:46, Claudio Jeker a écrit : The problem is that the symbol nkmempages moved into .bss and is therefor no longer modifiable by config(8). I think you can still use ukc via boot -c to alter it (but that is not sticky). The alternative is to set "option NKMEMPAGES=131072" in your GENERIC config file (or option NKMEMPAGES_MAX=131072). See also options(4). Long term is the fix this proper. All of this was built when computers had 100MB of memory not 100GB. Got it. Thanks. It means I'll stick with this kernel for now and see if it helps (it seems promising for now). Is there a way you can submit this patch (option NKMEMPAGES=131072) to the current branch ? Thanks
Re: OpenBSD SMP - BGPd - send_rtmsg: action 1, prefix A.B.C.D/24: No buffer space available - panic: malloc: out of space in kmem_map
On Tue, Nov 28, 2023 at 04:50:05PM +0100, Laurent CARON wrote: > Le 28/11/2023 à 12:12, Claudio Jeker a écrit : > > So the problem is that the malloc space is filled by > > a) 26540K of devbuf -- because of the multiqueue support in ixl > > b) 63493K of ACPI -- what the heck ACPI?!? > > and then there is not enough space for rtable. A full table requires > > in your example 50816K of rtable malloc space. > > > > Now on amd64 all of this needs to fit into 128MB which is impossible. > > > > You can use config(8) and bsd.re-config(5) to adjust the nkmempg variable > > to something like 131072 (which is 4 times the default size). > > This can be verified with `sysctl vm.nkmempages` > > > > Now ixl(4) and ACPI should not be such pigs but in the end 128MB of kernel > > malloc space is just stupidly small on a system with 128GB of memory. > > > Hi Claudio, > > Thanks. > > I bumped nkmempg to 131072 > > > > # config -e -o bsd.new /bsd > > ukc> nkmempg 131072 > > quit > > > > Then rebooted with the very same issue. > > It seems the nkmempg variable is not properly takes into account since > 'sysctl vm.nkmempages' still shows 32768 after reboot > > > > # sysctl vm.nkmempages vm.nkmempages=32768 > > > > # config -e -o bsd.new /bsd OpenBSD 7.4 (GENERIC.MP) #0: Sun Oct 22 12:13:42 > MDT 2023 > r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > Enter 'help' for information ukc> nkmempg nkmempages = 262144 > > Modifying /etc/bsd.re-config and rebooting (twice) didn't help either. > > I 'had'to recompile kernel (after modifying: /usr/src/sys/kern/kern_malloc.c > with '#define NKMEMPAGES 262144 '), the issue is not occuring again. > > Do you recomend using this approach to mitigate the issue, or is there a > more 'long term' fix ? The problem is that the symbol nkmempages moved into .bss and is therefor no longer modifiable by config(8). I think you can still use ukc via boot -c to alter it (but that is not sticky). The alternative is to set "option NKMEMPAGES=131072" in your GENERIC config file (or option NKMEMPAGES_MAX=131072). See also options(4). Long term is the fix this proper. All of this was built when computers had 100MB of memory not 100GB. -- :wq Claudio
Re: OpenBSD SMP - BGPd - send_rtmsg: action 1, prefix A.B.C.D/24: No buffer space available - panic: malloc: out of space in kmem_map
Le 28/11/2023 à 12:12, Claudio Jeker a écrit : So the problem is that the malloc space is filled by a) 26540K of devbuf -- because of the multiqueue support in ixl b) 63493K of ACPI -- what the heck ACPI?!? and then there is not enough space for rtable. A full table requires in your example 50816K of rtable malloc space. Now on amd64 all of this needs to fit into 128MB which is impossible. You can use config(8) and bsd.re-config(5) to adjust the nkmempg variable to something like 131072 (which is 4 times the default size). This can be verified with `sysctl vm.nkmempages` Now ixl(4) and ACPI should not be such pigs but in the end 128MB of kernel malloc space is just stupidly small on a system with 128GB of memory. Hi Claudio, Thanks. I bumped nkmempg to 131072 # config -e -o bsd.new /bsd ukc> nkmempg 131072 quit Then rebooted with the very same issue. It seems the nkmempg variable is not properly takes into account since 'sysctl vm.nkmempages' still shows 32768 after reboot # sysctl vm.nkmempages vm.nkmempages=32768 # config -e -o bsd.new /bsd OpenBSD 7.4 (GENERIC.MP) #0: Sun Oct 22 12:13:42 MDT 2023 r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Enter 'help' for information ukc> nkmempg nkmempages = 262144 Modifying /etc/bsd.re-config and rebooting (twice) didn't help either. I 'had'to recompile kernel (after modifying: /usr/src/sys/kern/kern_malloc.c with '#define NKMEMPAGES 262144 '), the issue is not occuring again. Do you recomend using this approach to mitigate the issue, or is there a more 'long term' fix ? Thanks Laurent
Re: OpenBSD SMP - BGPd - send_rtmsg: action 1, prefix A.B.C.D/24: No buffer space available - panic: malloc: out of space in kmem_map
On Mon, Nov 27, 2023 at 05:51:25PM +0100, Laurent CARON wrote:
> Please find attached the relevant info:
>
> vmstat-m_SP_with_bgpd -> vmstat -m SP with bgpd
>
> vmstat-m_SMP_without_bgpd -> vmstat -m SMP without bgpd
>
> vmstat-m_SMP_with_bgpd_0{01..11} -> vmstat -m SMP with bgpd until crash.
>
>
> Thanks
>
> Laurent
>
> Le 27/11/2023 à 17:10, Claudio Jeker a écrit :
> > vmstat -m
So the problem is that the malloc space is filled by
a) 26540K of devbuf -- because of the multiqueue support in ixl
b) 63493K of ACPI -- what the heck ACPI?!?
and then there is not enough space for rtable. A full table requires
in your example 50816K of rtable malloc space.
Now on amd64 all of this needs to fit into 128MB which is impossible.
You can use config(8) and bsd.re-config(5) to adjust the nkmempg variable
to something like 131072 (which is 4 times the default size).
This can be verified with `sysctl vm.nkmempages`
Now ixl(4) and ACPI should not be such pigs but in the end 128MB of kernel
malloc space is just stupidly small on a system with 128GB of memory.
--
:wq Claudio
Re: OpenBSD SMP - BGPd - send_rtmsg: action 1, prefix A.B.C.D/24: No buffer space available - panic: malloc: out of space in kmem_map
Hi Claudio,
Should you need remote access to the server, this is of course possible.
Le 27/11/2023 à 17:51, Laurent CARON a écrit :
Please find attached the relevant info:
vmstat-m_SP_with_bgpd -> vmstat -m SP with bgpd
vmstat-m_SMP_without_bgpd -> vmstat -m SMP without bgpd
vmstat-m_SMP_with_bgpd_0{01..11} -> vmstat -m SMP with bgpd until crash.
Thanks
Laurent
Le 27/11/2023 à 17:10, Claudio Jeker a écrit :
vmstat -m
Re: cumbersome mtree
We used to use mtree for packages at well. At some point, it was simpler to just give up and roll our own format for the same thing. There are many many limitations to mtree
Re: (Tina Turner) Scrumbled sectors playing dvd
Thank you for this one, appreciated. -- Nowarez Market
回复: a couple question about my fde setup
发件人: owner-m...@openbsd.org 代表 Shadrock Uhuru 发送时间: 2023年11月28日 09:23 收件人: openbsd 主题: Re: a couple question about my fde setup >>From: Nick Holland >>To: misc@openbsd.org >>Date: Mon, 20 Nov 2023 07:47:40 -0500 >>Subject: Re: a couple question about my fde setup >>On 11/19/23 18:09, Shadrock Uhuru wrote: >>> hi all >>> a couple question about my fde >>> first, i have fde setup using a keydisk on my laptop, encryption and >>> decryption works fine >>> when i reboot with the key inserted it doesn't find the key, >>> i have to shut the machine down and restart it then the key is detected, >>> is this normally how a reboot works with fde and keydisk ? >> >i've noticed a few things during the booting with and without the keydisk. > >without keydisk with keyfisk > >disk hd0 cd0 sr0* disk hd0 hd1 sr0* >>> openbsd/amd64 BootX64 3.63 >> openbsd/amd64 Bootx64 3.62 >failed (1) will try bsd failed (22) will try bsd > >also i have no idea why i have hd devices showing up at boot time >and i have sd devices in dmesg. > >shadrock I’m no expert, but it looks to me like your computer is booting from your key disk (why: different errors, different EFI versions between booting with and without key disk). Does your key disk have an EFI boot partition for some reason? Can you make sure your computer is set to not boot from USB? Re hd in boot menu, sd in dmesg: as far as I know, this is just due to different naming conventions in the boot loader and the kernel. ‘sr’ in the boot loader is your softraid encrypted disk. Nathan
