Re: SIP ALG and VoIP
Atticus [grobe...@gmail.com] wrote: > It isn't just SIP. You will need to set up NAT traversal and make sure RTP > traffic can pass as well. Setting up a STUN server and configuring the > clients to use it should aid in the NAT portion. The RTP traffic should be > fine as long as pf is being stateful. If the phones register over SIP fine, > but have no audio, then the RTP traffic isn't getting where it should. IMO, > it makes more sense to use an on-site PBX so you only have to deal with > traffic to/from the one host, but that doesn't sound like an option for you. > Using Asterisk as a SIP server and media gateway, on a public IP with phones behind NAT, you can get NAT traversal via RFC 3581+symmetric RTP (sip.conf nat=yes) without STUN and without a firewall SIP ALG. Freeswitch and also Kamailio + rtpproxy can do similar. These gateways are all capable of symmetric RTP, and have been since forever. If you are connecting phones inside of your NAT to an outside SIP provider, or PBX device, make sure the PBX has a public IP (not behind another NAT itself) and has symmetric RTP enabled.
Re: Documentation error in pci_mapreg_probe(9)
On 2022-01-10 3:53 a.m., Jonathan Gray wrote: > On Mon, Jan 10, 2022 at 09:17:25PM +1100, Jonathan Gray wrote: >> On Mon, Jan 10, 2022 at 02:24:05AM -0700, Ted Bullock wrote: >>> >>> On 2022-01-10 2:18 a.m., Jonathan Gray wrote: On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote: > The manpage incorrectly describes the behaviour and usage of > pci_mapreg_probe(9). This function does not return 0 for success and !0 > for failure as described in the manual, see the diff below for a > possible re-wording and corrected description. I agree the return value is wrong but your description introduces an error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example. Which is something that the pci_mapreg_type text also gets wrong. How about this to start with? >>> >>> It certainly corrects the mechanical issue with the returns, it doesn't help >>> though with understanding how to use the function correctly though. Under >>> what circumstances will the type bits get set as you indicate? I wasn't at >>> all clear about that from peering through the call tree. >> >> as the define would suggest, when it is a 64-bit mem bar > > expanding on this some more Here is what I have written so far. I added what I found to be necessary to actually use the API not having used it in OpenBSD before. More experienced devs might just *know* this but as someone who had to try and understand what it was doing using just the manual and the source code this is what was missing for me. Index: share/man/man9/pci_mapreg_map.9 === RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v retrieving revision 1.1 diff -u -p -r1.1 pci_mapreg_map.9 --- share/man/man9/pci_mapreg_map.9 23 Feb 2019 04:54:25 - 1.1 +++ share/man/man9/pci_mapreg_map.9 11 Jan 2022 04:12:32 - @@ -1,6 +1,7 @@ .\"$OpenBSD: pci_mapreg_map.9,v 1.1 2019/02/23 04:54:25 dlg Exp $ .\" .\" Copyright (c) 2019 David Gwynne +.\" Copyright (c) 2022 Ted Bullock .\" All rights reserved. .\" .\" Permission to use, copy, modify, and distribute this software for any @@ -15,7 +16,7 @@ .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. .\" -.Dd $Mdocdate: February 23 2019 $ +.Dd $Mdocdate: January 10 2022 $ .Dt PCI_MAPREG_MAP 9 .Os .Sh NAME @@ -50,19 +51,21 @@ .Fa "bus_size_t *sizep" .Fa "int *flagsp" .Fc -.Ft int -.Fo pci_mapreg_probe +.Ft pcireg_t +.Fo pci_mapreg_type .Fa "pci_chipset_tag_t pc" .Fa "pcitag_t tag" .Fa "int reg" -.Fa "pcireg_t *typep" .Fc -.Ft pcireg_t -.Fo pci_mapreg_type +.Ft int +.Fo pci_mapreg_probe .Fa "pci_chipset_tag_t pc" .Fa "pcitag_t tag" .Fa "int reg" +.Fa "pcireg_t *typep" .Fc +.Fd #define PCI_MAPREG_TYPE(type) +.Fd #define PCI_MAPREG_MEM_TYPE(type) .\" .Ft int .\" .Fo pci_mem_find .\" .Fa "pci_chipset_tag_t pc" @@ -85,7 +88,43 @@ These functions provide wrappers and helpers around .Xr bus_space 9 mappings for device registers described by the Base Address Registers -(BARs) in a PCI devices configuration space. +(BARs) in a PCI devices configuration space. There are 6 BARs located in the +pci address space at 0x10, 0x14, 0x18, 0x1C, 0x20 and 0x24. The addresses +stored in the PCI BARS are used to map IO and Memory Mapped device registers. +.Pp +BARS have a complex bitmap described a follows: +.TS +center,allbox; +cb s s +cb cb cb +cb s s +c r l +c r l +cb s s +c r l +^ r l +^ r l +c r l +^ r l +c r l +cb s s +c r l. +PCI BAR Bitmap +Bits Description Values +All PCI BARs +0 Type0 Memory +\^ \^ 1 I/O +Memory BARs +1-2Location00 Any 32-bit +\^ \^ 10 < 1MB +\^ \^ 11 Any 64-bit +3 Prefetchable0 No +\^ \^ 1 Yes +4-31 Base Address16-byte aligned +I/O BARs +1 Reserved\_ +2-31 Base Address4-byte aligned +.TE .Pp .Nm pci_mapreg_map wraps a call to @@ -124,29 +163,70 @@ and .Fa flagsp pointers. .Pp +.Nm pci_mapreg_type +returns the type of register access for the registers at the BAR +referenced by +.Fa reg . +.Pp .Nm pci_mapreg_probe attempts to determine if the BAR referenced by .Fa reg -describes a valid register mapping. +describes a valid register mapping. If it does, the register type will be +updated via the pointer +.Fa typep +matching those described for the return value of +.Nm pci_mapreg_type . +If the mapping is invalid the register type should not be used. +.Fa typep +can be +.Dv NULL +if determining the register type is not desired. .Pp +.Nm PCI_MAPREG_TYPE(type) +is a helper macro useful for logical operations on types returned by .Nm pci_mapreg_type -returns the type of register access for the registers at the BAR -referenced by -.Fa reg . -.Sh RETURN VALUES -.Nm pci_mapreg_map , -.Nm pci_mapreg_info , and -.Nm pci_mapreg_probe -return 0 on success, or an +.Nm
Re: Install latest package without prompts on OpenBSD 7.0
On Tue, Jan 11, 2022 at 01:13:27AM -, Stuart Henderson wrote: > On 2022-01-10, Ian Darwin wrote: > > On Mon, Jan 10, 2022 at 06:28:38PM -0300, Crystal Kolipe wrote: > >> On Mon, Jan 10, 2022 at 07:15:25PM +0100, Andreas Kusalananda Khri wrote: > >> > Which one is the "latest" here? > >> > > >> > $ doas pkg_add bogofilter > >> > doas (kk@box) password: > >> > quirks-4.92 signed on 2022-01-07T13:45:06Z > >> > Ambiguous: choose package for bogofilter > >> > a 0: > >> > 1: bogofilter-1.2.5 > >> > 2: bogofilter-1.2.5-db4 > >> > 3: bogofilter-1.2.5-lmdb > >> > 4: bogofilter-1.2.5-qdbm > >> > 5: bogofilter-1.2.5-sqlite3 > >> > Your choice: > >> > >> None of them is the 'latest', those are just different 'flavors' of the > >> port. > > > > Agreed. > > > > The discussion was about different numbered versions, but has been hijacked > > to > > be about flavors. > > > > If a "simple automated scripted" pkg_add were desired, it would take choice > > #1 in this > > case or any where there are flavors AND where no flavor was specified. > > For flavours you can choose that with "pkg_add somepkg--". > ..and it would give you DB 3.x which is probably the worst option. Perhaps we need an option to choose a random flavor.
Re: Install latest package without prompts on OpenBSD 7.0
On 2022-01-10, Ian Darwin wrote: > On Mon, Jan 10, 2022 at 06:28:38PM -0300, Crystal Kolipe wrote: >> On Mon, Jan 10, 2022 at 07:15:25PM +0100, Andreas Kusalananda Khri wrote: >> > Which one is the "latest" here? >> > >> >$ doas pkg_add bogofilter >> >doas (kk@box) password: >> >quirks-4.92 signed on 2022-01-07T13:45:06Z >> >Ambiguous: choose package for bogofilter >> >a 0: >> >1: bogofilter-1.2.5 >> >2: bogofilter-1.2.5-db4 >> >3: bogofilter-1.2.5-lmdb >> >4: bogofilter-1.2.5-qdbm >> >5: bogofilter-1.2.5-sqlite3 >> >Your choice: >> >> None of them is the 'latest', those are just different 'flavors' of the port. > > Agreed. > > The discussion was about different numbered versions, but has been hijacked to > be about flavors. > > If a "simple automated scripted" pkg_add were desired, it would take choice > #1 in this > case or any where there are flavors AND where no flavor was specified. For flavours you can choose that with "pkg_add somepkg--". ..and it would give you DB 3.x which is probably the worst option.
Re: Install latest package without prompts on OpenBSD 7.0
On 2022-01-10, Andreas Kusalananda Kähäri wrote: > Which one is the "latest" here? > > $ doas pkg_add bogofilter > doas (kk@box) password: > quirks-4.92 signed on 2022-01-07T13:45:06Z > Ambiguous: choose package for bogofilter > a 0: > 1: bogofilter-1.2.5 > 2: bogofilter-1.2.5-db4 > 3: bogofilter-1.2.5-lmdb > 4: bogofilter-1.2.5-qdbm > 5: bogofilter-1.2.5-sqlite3 bogofilter--lmdb is the latest :)
Nagios check_by_ssh
nagios install creates user _nagios with login = /sbin/nologin I have some OpenBSD systems not configured to send email to external addresses; there is one system (host0) that is configured to send email outside. I wish to use nagios on host0 to monitor the other systems and send notifications to an offsite email address. I was thinking that some sort of restricted shell (only access to /usr/local/libexec/nagios/) would be appropriate. Anyone able to provide a clue how this can be accomplished? Is there a best practices document for using check_by_ssh in OpenBSD? Frank
Re: Install latest package without prompts on OpenBSD 7.0
On Mon, Jan 10, 2022 at 10:54:22AM -0500, Ian Darwin wrote: > > > > I am working on OpenBSD 7.0, x86_64. I'm trying to script an install > > > > of developer tools I use, like GCC and Git. When I attempt to install > > > > GCC I am prompted: > > > > > > > > $ sudo pkg_add gcc g++ > > > > quirks-4.54 signed on 2022-01-09T19:08:35Z > > > > Ambiguous: choose package for gcc > > > > a0: > > > > 1: gcc-8.4.0p9 > > > > 2: gcc-11.2.0p0 > > > > > > > > I've looked over the man page at https://man.openbsd.org/pkg_add, but > > > > I don't see an option to tell pkg_add to install the latest version of > > > > the package. > > > > > > Sure there is. > > > > > > Quoting the manpage: > > > There is also an ambiguity related to ports with multiple branches. > > > For > > > instance ‘pkg_add python’ is ambiguous, as there are several versions > > > of > > > python in the ports tree. So is ‘pkg_add postfix’. The special form > > > ‘pkgname%branch’ can be used to restrict matches to a branch matching > > > the > > > pkgpath(7). > > > > > > pkg_add gcc%11 g++%11 > > > will do the trick > In the context of the original post, I think he meant a way to invoke > "pkg_add" and have > it just install whatever the latest is, without having to know a priori that > there is a version 11. > "Just install gcc, dammit". There are many ports that have version choices > and in the context > of installing the latest of everything in a "scripted install", having to > either stop mid-install > and answer such a prompt, or sort out in advance what ports exist in multiple > versions, > is not what's wanted. It may be unwise, but it's what some people that do > scripted installs want. > I have wished for this too, but it never bothered me enough to send a query. > :-) For production (and thus automated installs) you do not want the latest. We have branches and they should be used for that. Granted, the gcc port naming is probably not the best ever. But... what's your arch ? do you *really* want a gcc 11 that might not work at all on your arch. Sorry. There is a lot more going on. We could have further annotations to let scripts decide between "most stable", "best esr", "most likely to win a beauty contest"
Re: Install latest package without prompts on OpenBSD 7.0
On Mon, Jan 10, 2022 at 06:28:38PM -0300, Crystal Kolipe wrote: > On Mon, Jan 10, 2022 at 07:15:25PM +0100, Andreas Kusalananda Khri wrote: > > Which one is the "latest" here? > > > > $ doas pkg_add bogofilter > > doas (kk@box) password: > > quirks-4.92 signed on 2022-01-07T13:45:06Z > > Ambiguous: choose package for bogofilter > > a 0: > > 1: bogofilter-1.2.5 > > 2: bogofilter-1.2.5-db4 > > 3: bogofilter-1.2.5-lmdb > > 4: bogofilter-1.2.5-qdbm > > 5: bogofilter-1.2.5-sqlite3 > > Your choice: > > None of them is the 'latest', those are just different 'flavors' of the port. Agreed. The discussion was about different numbered versions, but has been hijacked to be about flavors. If a "simple automated scripted" pkg_add were desired, it would take choice #1 in this case or any where there are flavors AND where no flavor was specified.
Re: Install latest package without prompts on OpenBSD 7.0
On Mon, Jan 10, 2022 at 07:15:25PM +0100, Andreas Kusalananda Khri wrote: > Which one is the "latest" here? > > $ doas pkg_add bogofilter > doas (kk@box) password: > quirks-4.92 signed on 2022-01-07T13:45:06Z > Ambiguous: choose package for bogofilter > a 0: > 1: bogofilter-1.2.5 > 2: bogofilter-1.2.5-db4 > 3: bogofilter-1.2.5-lmdb > 4: bogofilter-1.2.5-qdbm > 5: bogofilter-1.2.5-sqlite3 > Your choice: None of them is the 'latest', those are just different 'flavors' of the port.
SIP ALG and VoIP
It isn't just SIP. You will need to set up NAT traversal and make sure RTP traffic can pass as well. Setting up a STUN server and configuring the clients to use it should aid in the NAT portion. The RTP traffic should be fine as long as pf is being stateful. If the phones register over SIP fine, but have no audio, then the RTP traffic isn't getting where it should. IMO, it makes more sense to use an on-site PBX so you only have to deal with traffic to/from the one host, but that doesn't sound like an option for you. -- Byron Grobe
Re: Documentation error in pci_mapreg_probe(9)
On 2022-01-10 3:53 a.m., Jonathan Gray wrote: > On Mon, Jan 10, 2022 at 09:17:25PM +1100, Jonathan Gray wrote: >> On Mon, Jan 10, 2022 at 02:24:05AM -0700, Ted Bullock wrote: >>> >>> On 2022-01-10 2:18 a.m., Jonathan Gray wrote: On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote: > The manpage incorrectly describes the behaviour and usage of > pci_mapreg_probe(9). This function does not return 0 for success and !0 > for failure as described in the manual, see the diff below for a > possible re-wording and corrected description. I agree the return value is wrong but your description introduces an error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example. Which is something that the pci_mapreg_type text also gets wrong. How about this to start with? >>> >>> It certainly corrects the mechanical issue with the returns, it doesn't help >>> though with understanding how to use the function correctly though. Under >>> what circumstances will the type bits get set as you indicate? I wasn't at >>> all clear about that from peering through the call tree. >> >> as the define would suggest, when it is a 64-bit mem bar Ok, then still missing from the document is the semantic distinctions between the return types and the correct usage for those types with pci_mapreg_info and pci_mapreg_map. There is also the undocumented PCI_MAPREG_TYPE and PCI_MAPREG_MEM_TYPE macros too: This usage should be incorrect? if (type == PCI_MAPREG_TYPE_MEM) I think correct form should be then if (PCI_MAPREG_TYPE(type) == PCI_MAPREG_TYPE_MEM) switch (PCI_MAPREG_MEM_TYPE(type)) PCI_MAPREG_MEM_TYPE_32BIT_1M: PCI_MAPREG_MEM_TYPE_32BIT: pci_mapreg_map for 32 bit bar PCI_MAPREG_MEM_TYPE_64BIT: pci_mapreg_map for 64 bit bar This pci stack doesn't also seem to handle pci devices with a 16 bit bar, but I also don't know if such devices actually exist so maybe this doesn't matter > expanding on this some more > > Index: pci_mapreg_map.9 > === > RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v > retrieving revision 1.1 > diff -u -p -r1.1 pci_mapreg_map.9 > --- pci_mapreg_map.9 23 Feb 2019 04:54:25 - 1.1 > +++ pci_mapreg_map.9 10 Jan 2022 10:51:36 - > @@ -128,6 +128,11 @@ pointers. > attempts to determine if the BAR referenced by > .Fa reg > describes a valid register mapping. > +If it does > +.Fa typep > +will point to a value with flags matching those described for the return > value > +of > +.Nm pci_mapreg_type . > .Pp > .Nm pci_mapreg_type > returns the type of register access for the registers at the BAR > @@ -135,18 +140,22 @@ referenced by > .Fa reg . > .Sh RETURN VALUES > .Nm pci_mapreg_map , > -.Nm pci_mapreg_info , > and > -.Nm pci_mapreg_probe > +.Nm pci_mapreg_info > return 0 on success, or an > .Xr errno 2 > style value on failure. > .Pp > +.Nm pci_mapreg_probe > +returns 1 if if the BAR describes a valid mapping, 0 if not. > +.Pp > .Nm pci_mapreg_type > -returns either > -.Dv PCI_MAPREG_TYPE_IO > -or > -.Dv PCI_MAPREG_TYPE_MEM . > +returns a value with flags for type information. > +.Dv PCI_MAPREG_TYPE_IO , > +.Dv PCI_MAPREG_TYPE_MEM , > +.Dv PCI_MAPREG_MEM_TYPE_32BIT , > +.Dv PCI_MAPREG_MEM_TYPE_32BIT_1M and > +.Dv PCI_MAPREG_MEM_TYPE_64BIT . > .Sh SEE ALSO > .Xr pci 4 , > .Xr bus_space 9 , -- Ted Bullock
Re: SIP ALG and VoIP
Happy New Year to everyone! I currently run openBSD FW v7.0 with vpn setups at a few client sites. Fantastic...no issues. One client recently changed office location (this week exactly) and had Bell install a voip system using softphones. The phones worked last week. However, now that the rest of server-room equipment has been brought over and installed on the weekend including the BSD FW, the phones stopped working. A Bell tech spent most of the day on site today switching the Bell modem from bridge mode to pass-through mode but still no luck. We've decided to install a dry-loop to remedy the issue. I prefer not to open any ports obviously, but should I have added a pf rule that explicitly opens port 5060/udp for the sip server? Is anyone using pf with voip phones that could point me in the right direction? I have another client doing a similar implementation in the next 2 weeks albeit different ISP & VoIP provider. So I'm kind of interested in what's the best option or config going forward. Thanks in advance for your response.
Re: dd and mbr
I see, thanks! :) Rod. On Mon, 10 Jan 2022, Otto Moerbeek wrote: On Mon, Jan 10, 2022 at 07:35:51PM +, Roderick wrote: I thought dd if=/dev/zero of=/dev/rwd1 bs=1m would delete the mbr. But I still see the partition table with fdisk. Any explanation? Rod. You just created a file in /dev named rwd1. There is no device called rwd1. -Otto
Re: dd and mbr
On Mon, Jan 10, 2022 at 07:35:51PM +, Roderick wrote: > > I thought > > dd if=/dev/zero of=/dev/rwd1 bs=1m > > would delete the mbr. But I still see the partition table > with fdisk. > > Any explanation? > > Rod. > You just created a file in /dev named rwd1. There is no device called rwd1. -Otto
dd and mbr
I thought dd if=/dev/zero of=/dev/rwd1 bs=1m would delete the mbr. But I still see the partition table with fdisk. Any explanation? Rod.
Re: Install latest package without prompts on OpenBSD 7.0
On Mon, Jan 10, 2022 at 10:54:22AM -0500, Ian Darwin wrote: > > > > I am working on OpenBSD 7.0, x86_64. I'm trying to script an install > > > > of developer tools I use, like GCC and Git. When I attempt to install > > > > GCC I am prompted: > > > > > > > > $ sudo pkg_add gcc g++ > > > > quirks-4.54 signed on 2022-01-09T19:08:35Z > > > > Ambiguous: choose package for gcc > > > > a0: > > > > 1: gcc-8.4.0p9 > > > > 2: gcc-11.2.0p0 > > > > > > > > I've looked over the man page at https://man.openbsd.org/pkg_add, but > > > > I don't see an option to tell pkg_add to install the latest version of > > > > the package. > > > > > > Sure there is. > > > > > > Quoting the manpage: > > > There is also an ambiguity related to ports with multiple branches. > > > For > > > instance ‘pkg_add python’ is ambiguous, as there are several versions > > > of > > > python in the ports tree. So is ‘pkg_add postfix’. The special form > > > ‘pkgname%branch’ can be used to restrict matches to a branch matching > > > the > > > pkgpath(7). > > > > > > pkg_add gcc%11 g++%11 > > > will do the trick > > In the context of the original post, I think he meant a way to invoke > "pkg_add" and have > it just install whatever the latest is, without having to know a priori that > there is a version 11. > "Just install gcc, dammit". There are many ports that have version choices > and in the context > of installing the latest of everything in a "scripted install", having to > either stop mid-install > and answer such a prompt, or sort out in advance what ports exist in multiple > versions, > is not what's wanted. It may be unwise, but it's what some people that do > scripted installs want. > I have wished for this too, but it never bothered me enough to send a query. > :-) Which one is the "latest" here? $ doas pkg_add bogofilter doas (kk@box) password: quirks-4.92 signed on 2022-01-07T13:45:06Z Ambiguous: choose package for bogofilter a 0: 1: bogofilter-1.2.5 2: bogofilter-1.2.5-db4 3: bogofilter-1.2.5-lmdb 4: bogofilter-1.2.5-qdbm 5: bogofilter-1.2.5-sqlite3 Your choice: -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: HP Probook audio only playing on left speaker
On 1/9/22 8:51 PM, Jordan Geoghegan wrote: Hello, I have an HP Probook (dmesg below) that is only playing audio from the left headphone speaker. No matter how I try I cannot get any audio to play over the right side speaker. I have very little experience debugging audio issues on OpenBSD as everything has largely "just worked" for me over the years in that regard. Any insight or advice would be greatly appreciated! Here is the output from mixerctl: ...[snipped for size]... My first thought is "HW problem". IF it is the internal speaker not working, have you tried an external speaker set? If external, do both internals work? Have you verified both channels work with some other OS? Nick.
Re: Install latest package without prompts on OpenBSD 7.0
> > > I am working on OpenBSD 7.0, x86_64. I'm trying to script an install > > > of developer tools I use, like GCC and Git. When I attempt to install > > > GCC I am prompted: > > > > > > $ sudo pkg_add gcc g++ > > > quirks-4.54 signed on 2022-01-09T19:08:35Z > > > Ambiguous: choose package for gcc > > > a0: > > > 1: gcc-8.4.0p9 > > > 2: gcc-11.2.0p0 > > > > > > I've looked over the man page at https://man.openbsd.org/pkg_add, but > > > I don't see an option to tell pkg_add to install the latest version of > > > the package. > > > > Sure there is. > > > > Quoting the manpage: > > There is also an ambiguity related to ports with multiple branches. For > > instance ‘pkg_add python’ is ambiguous, as there are several versions of > > python in the ports tree. So is ‘pkg_add postfix’. The special form > > ‘pkgname%branch’ can be used to restrict matches to a branch matching > > the > > pkgpath(7). > > > > pkg_add gcc%11 g++%11 > > will do the trick In the context of the original post, I think he meant a way to invoke "pkg_add" and have it just install whatever the latest is, without having to know a priori that there is a version 11. "Just install gcc, dammit". There are many ports that have version choices and in the context of installing the latest of everything in a "scripted install", having to either stop mid-install and answer such a prompt, or sort out in advance what ports exist in multiple versions, is not what's wanted. It may be unwise, but it's what some people that do scripted installs want. I have wished for this too, but it never bothered me enough to send a query. :-)
Re: Interrupts hover above 40% when idle on Dell Latitude E7450
On 2022-01-09, Ryan Kavanagh wrote:
> Hi Stuart,
>
> On Sun, Jan 09, 2022 at 03:12:06PM -, Stuart Henderson wrote:
>> That's shown after the dmesg, though "vmstat -i" would probably be
>> better as it has the totals as well.
>
> vmstat -i under GENERIC before rebooting into GENERIC.MP:
>
> interrupt total rate
> irq0/clock 885333 99
> irq96/acpi0 17890
> irq144/inteldrm0 117024 13
> irq114/em0 124141
> irq176/azalia1 16680
> irq115/iwm0416586 47
> irq102/ehci0 2210
> irq103/ahci0 124340 14
> irq104/ichiic0 17700
> irq145/pckbc0 177101
> irq146/pckbc0 445885
> Total 1623443 183
>
>> Ryan, any difference if you use GENERIC.MP rather than GENERIC?
>
> Yes. Looking at top, I see that CPU0 is spending roughly the same amount
> of time processing interrupts, while CPU1 is free to do other stuff.
> Representative capture:
>
> CPU0 states: 18.6% user, 0.0% nice, 3.0% sys, 0.2% spin, 44.3% intr, 33.9%
> idle
> CPU1 states: 50.3% user, 0.0% nice, 5.0% sys, 1.6% spin, 0.0% intr, 43.1%
> idle
>
> `systat vm` shows an Int% hovering around 20% (I imagine it's the mean
> of the two interrupt rates shown by top), with lows in the low 10% and
> highs in the low 30%.
>
> My laptop does not seem to get as hot as quickly under GENERIC.MP. I
> don't have hard data (I suppose one could plot the output of `sysctl
> hw.sensors` across time to compare), but at least now my laptop fan
> isn't spinning most of the time and my laptop doesn't quickly get too
> hot to handle comfortably.
>
> vmstat -i under GENERIC.MP after being up ~35 minutes with light load:
>
> interrupt total rate
> irq0/clock 860124 399
> irq0/ipi 714019 331
> irq96/acpi0 4360
> irq144/inteldrm033945 15
> irq114/em0 79653
> irq176/azalia1 10
> irq115/iwm0 73471 34
> irq102/ehci0 730
> irq103/ahci044676 20
> irq104/ichiic04310
> irq145/pckbc064412
> irq146/pckbc031781
> Total 1744760 810
>
> Switching to GENERIC.MP solves the practical issue for me: my laptop no
> longer quickly overheats. That said, I don't know what is a normal rate
> of interrupts under GENERIC.MP, and I'm happy to debug further if you
> think it would be helpful.
The interrupt rates look pretty normal to me, but the cpu time spent
processing them is much higher than I'd expect.
If you're interested to dig deeper then I think the simplest way to find
out which part of the kernel is involved in this is probably going to
be via dt(4) / btrace(8). This is a system tracing facility which can
be used for many things but one common and simple use is to see which
functions the kernel spends its time in which will be helpful here.
In recent OpenBSD this is included in the default kernel builds but must
be enabled by setting "kern.allowdt=1" in /etc/sysctl.conf and rebooting
(it can't be changed in normal runtime, once the system securelevel has
been raised).
When that's done you can run the following as root
btrace -e 'profile:hz:100 { @[kstack] = count(); }' > /tmp/btrace.out
Run it for a while and press ^C (in many use cases you might want to be
carrying out certain activity to investigate what the kernel is doing
while that's occurring, but here I would think it's better to do with
the machine mostly idle, and probably running it for 5-10 seconds
would be enough).
That produces a bpftrace-compatible file which you can process by piping
through the following two perl scripts in order (IIRC they are self-
contained and don't require installing any non-base Perl modules,
but ask if you have any problems getting it to work) :-
https://github.com/brendangregg/FlameGraph/raw/master/stackcollapse-bpftrace.pl
https://github.com/brendangregg/FlameGraph/raw/master/flamegraph.pl
The output from the second is an HTML file with SVG display showing what
the kernel was doing during that time that you can load into a browser and
click around to expand things.
If you do this then I'd suggest following up on bugs@ - make it into a
self-contained mail so anyone looking into doesn't need to jump around
other list posts to gather details. Preferably generated with sendbug(1)
to include dmesg/pcidump/etc. It's often easier to use "sendbug -P" and
move that to a standard email client. Describe the problem again i.e.
high cpu % in interrupt, include the information you've already posted
Re: Documentation error in pci_mapreg_probe(9)
On Mon, Jan 10, 2022 at 09:17:25PM +1100, Jonathan Gray wrote: > On Mon, Jan 10, 2022 at 02:24:05AM -0700, Ted Bullock wrote: > > > > On 2022-01-10 2:18 a.m., Jonathan Gray wrote: > > > On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote: > > > > The manpage incorrectly describes the behaviour and usage of > > > > pci_mapreg_probe(9). This function does not return 0 for success and !0 > > > > for failure as described in the manual, see the diff below for a > > > > possible re-wording and corrected description. > > > > > > I agree the return value is wrong but your description introduces an > > > error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example. > > > Which is something that the pci_mapreg_type text also gets wrong. > > > > > > How about this to start with? > > > > It certainly corrects the mechanical issue with the returns, it doesn't help > > though with understanding how to use the function correctly though. Under > > what circumstances will the type bits get set as you indicate? I wasn't at > > all clear about that from peering through the call tree. > > as the define would suggest, when it is a 64-bit mem bar expanding on this some more Index: pci_mapreg_map.9 === RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v retrieving revision 1.1 diff -u -p -r1.1 pci_mapreg_map.9 --- pci_mapreg_map.923 Feb 2019 04:54:25 - 1.1 +++ pci_mapreg_map.910 Jan 2022 10:51:36 - @@ -128,6 +128,11 @@ pointers. attempts to determine if the BAR referenced by .Fa reg describes a valid register mapping. +If it does +.Fa typep +will point to a value with flags matching those described for the return value +of +.Nm pci_mapreg_type . .Pp .Nm pci_mapreg_type returns the type of register access for the registers at the BAR @@ -135,18 +140,22 @@ referenced by .Fa reg . .Sh RETURN VALUES .Nm pci_mapreg_map , -.Nm pci_mapreg_info , and -.Nm pci_mapreg_probe +.Nm pci_mapreg_info return 0 on success, or an .Xr errno 2 style value on failure. .Pp +.Nm pci_mapreg_probe +returns 1 if if the BAR describes a valid mapping, 0 if not. +.Pp .Nm pci_mapreg_type -returns either -.Dv PCI_MAPREG_TYPE_IO -or -.Dv PCI_MAPREG_TYPE_MEM . +returns a value with flags for type information. +.Dv PCI_MAPREG_TYPE_IO , +.Dv PCI_MAPREG_TYPE_MEM , +.Dv PCI_MAPREG_MEM_TYPE_32BIT , +.Dv PCI_MAPREG_MEM_TYPE_32BIT_1M and +.Dv PCI_MAPREG_MEM_TYPE_64BIT . .Sh SEE ALSO .Xr pci 4 , .Xr bus_space 9 ,
Re: Install latest package without prompts on OpenBSD 7.0
[forgot to Cc the list] On Mon, Jan 10, 2022 at 11:36:04AM +0100, Marc Espie wrote: > On Sun, Jan 09, 2022 at 10:03:01PM -0500, Jeffrey Walton wrote: > > Hi Everyone, > > > > I am working on OpenBSD 7.0, x86_64. I'm trying to script an install > > of developer tools I use, like GCC and Git. When I attempt to install > > GCC I am prompted: > > > > $ sudo pkg_add gcc g++ > > quirks-4.54 signed on 2022-01-09T19:08:35Z > > Ambiguous: choose package for gcc > > a0: > > 1: gcc-8.4.0p9 > > 2: gcc-11.2.0p0 > > > > I've looked over the man page at https://man.openbsd.org/pkg_add, but > > I don't see an option to tell pkg_add to install the latest version of > > the package. > > Sure there is. > > Quoting the manpage: > There is also an ambiguity related to ports with multiple branches. For > instance ‘pkg_add python’ is ambiguous, as there are several versions of > python in the ports tree. So is ‘pkg_add postfix’. The special form > ‘pkgname%branch’ can be used to restrict matches to a branch matching the > pkgpath(7). > > pkg_add gcc%11 g++%11 > will do the trick >
Re: Documentation error in pci_mapreg_probe(9)
On Mon, Jan 10, 2022 at 02:24:05AM -0700, Ted Bullock wrote:
>
> On 2022-01-10 2:18 a.m., Jonathan Gray wrote:
> > On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote:
> > > The manpage incorrectly describes the behaviour and usage of
> > > pci_mapreg_probe(9). This function does not return 0 for success and !0
> > > for failure as described in the manual, see the diff below for a
> > > possible re-wording and corrected description.
> >
> > I agree the return value is wrong but your description introduces an
> > error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example.
> > Which is something that the pci_mapreg_type text also gets wrong.
> >
> > How about this to start with?
>
> It certainly corrects the mechanical issue with the returns, it doesn't help
> though with understanding how to use the function correctly though. Under
> what circumstances will the type bits get set as you indicate? I wasn't at
> all clear about that from peering through the call tree.
as the define would suggest, when it is a 64-bit mem bar
for example
0x0010: BAR mem 64bit addr: 0xf122/0x0001
xhci0 at pci0 dev 20 function 0 "Intel 9 Series xHCI" rev 0x03: bar 0x10 type
0x4 : msi, xHCI 1.0
Index: xhci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/xhci_pci.c,v
retrieving revision 1.10
diff -u -p -r1.10 xhci_pci.c
--- xhci_pci.c 18 Nov 2018 08:46:57 - 1.10
+++ xhci_pci.c 10 Jan 2022 09:54:09 -
@@ -134,6 +134,7 @@ xhci_pci_attach(struct device *parent, s
pci_intr_handle_t ih;
pcireg_t reg;
int error;
+ pcireg_t type;
reg = pci_mapreg_type(pa->pa_pc, pa->pa_tag, PCI_CBMEM);
if (pci_mapreg_map(pa, PCI_CBMEM, reg, 0, >sc.iot, >sc.ioh,
@@ -141,6 +142,9 @@ xhci_pci_attach(struct device *parent, s
printf(": can't map mem space\n");
return;
}
+
+ if (pci_mapreg_probe(pa->pa_pc, pa->pa_tag, 0x10, ))
+ printf(": bar 0x10 type 0x%x ", type);
psc->sc_pc = pa->pa_pc;
psc->sc_tag = pa->pa_tag;
from pcireg.h:
#define PCI_MAPREG_TYPE(mr) \
((mr) & PCI_MAPREG_TYPE_MASK)
#define PCI_MAPREG_TYPE_MASK0x0001
#define PCI_MAPREG_TYPE_MEM 0x
#define PCI_MAPREG_TYPE_IO 0x0001
#define PCI_MAPREG_MEM_TYPE(mr) \
((mr) & PCI_MAPREG_MEM_TYPE_MASK)
#define PCI_MAPREG_MEM_TYPE_MASK0x0006
#define PCI_MAPREG_MEM_TYPE_32BIT 0x
#define PCI_MAPREG_MEM_TYPE_32BIT_1M0x0002
#define PCI_MAPREG_MEM_TYPE_64BIT 0x0004
#define _PCI_MAPREG_TYPEBITS(reg) \
(PCI_MAPREG_TYPE(reg) == PCI_MAPREG_TYPE_IO ? \
reg & PCI_MAPREG_TYPE_MASK : \
reg & (PCI_MAPREG_TYPE_MASK|PCI_MAPREG_MEM_TYPE_MASK))
>
> Anyway it's certainly a weakness of the document. This at least stops the
> error from the return values.
>
> >
> > Index: pci_mapreg_map.9
> > ===
> > RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v
> > retrieving revision 1.1
> > diff -u -p -r1.1 pci_mapreg_map.9
> > --- pci_mapreg_map.923 Feb 2019 04:54:25 - 1.1
> > +++ pci_mapreg_map.910 Jan 2022 09:13:30 -
> > @@ -135,12 +135,14 @@ referenced by
> > .Fa reg .
> > .Sh RETURN VALUES
> > .Nm pci_mapreg_map ,
> > -.Nm pci_mapreg_info ,
> > and
> > -.Nm pci_mapreg_probe
> > +.Nm pci_mapreg_info
> > return 0 on success, or an
> > .Xr errno 2
> > style value on failure.
> > +.Pp
> > +.Nm pci_mapreg_probe
> > +returns 1 if if the BAR is implemented, 0 if not.
> > .Pp
> > .Nm pci_mapreg_type
> > returns either
>
> --
> Ted Bullock
>
>
Re: Documentation error in pci_mapreg_probe(9)
On 2022-01-10 2:18 a.m., Jonathan Gray wrote: On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote: The manpage incorrectly describes the behaviour and usage of pci_mapreg_probe(9). This function does not return 0 for success and !0 for failure as described in the manual, see the diff below for a possible re-wording and corrected description. I agree the return value is wrong but your description introduces an error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example. Which is something that the pci_mapreg_type text also gets wrong. How about this to start with? It certainly corrects the mechanical issue with the returns, it doesn't help though with understanding how to use the function correctly though. Under what circumstances will the type bits get set as you indicate? I wasn't at all clear about that from peering through the call tree. Anyway it's certainly a weakness of the document. This at least stops the error from the return values. Index: pci_mapreg_map.9 === RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v retrieving revision 1.1 diff -u -p -r1.1 pci_mapreg_map.9 --- pci_mapreg_map.923 Feb 2019 04:54:25 - 1.1 +++ pci_mapreg_map.910 Jan 2022 09:13:30 - @@ -135,12 +135,14 @@ referenced by .Fa reg . .Sh RETURN VALUES .Nm pci_mapreg_map , -.Nm pci_mapreg_info , and -.Nm pci_mapreg_probe +.Nm pci_mapreg_info return 0 on success, or an .Xr errno 2 style value on failure. +.Pp +.Nm pci_mapreg_probe +returns 1 if if the BAR is implemented, 0 if not. .Pp .Nm pci_mapreg_type returns either -- Ted Bullock
Re: Documentation error in pci_mapreg_probe(9)
On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote: > The manpage incorrectly describes the behaviour and usage of > pci_mapreg_probe(9). This function does not return 0 for success and !0 > for failure as described in the manual, see the diff below for a > possible re-wording and corrected description. I agree the return value is wrong but your description introduces an error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example. Which is something that the pci_mapreg_type text also gets wrong. How about this to start with? Index: pci_mapreg_map.9 === RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v retrieving revision 1.1 diff -u -p -r1.1 pci_mapreg_map.9 --- pci_mapreg_map.923 Feb 2019 04:54:25 - 1.1 +++ pci_mapreg_map.910 Jan 2022 09:13:30 - @@ -135,12 +135,14 @@ referenced by .Fa reg . .Sh RETURN VALUES .Nm pci_mapreg_map , -.Nm pci_mapreg_info , and -.Nm pci_mapreg_probe +.Nm pci_mapreg_info return 0 on success, or an .Xr errno 2 style value on failure. +.Pp +.Nm pci_mapreg_probe +returns 1 if if the BAR is implemented, 0 if not. .Pp .Nm pci_mapreg_type returns either
Re: Install latest package without prompts on OpenBSD 7.0
El lun, 10 ene 2022 a las 4:10, Jeffrey Walton () escribió: > Hi Everyone, > > I am working on OpenBSD 7.0, x86_64. I'm trying to script an install > of developer tools I use, like GCC and Git. When I attempt to install > GCC I am prompted: > > $ sudo pkg_add gcc g++ > quirks-4.54 signed on 2022-01-09T19:08:35Z > Ambiguous: choose package for gcc > a0: > 1: gcc-8.4.0p9 > 2: gcc-11.2.0p0 > > I've looked over the man page at https://man.openbsd.org/pkg_add, but > I don't see an option to tell pkg_add to install the latest version of > the package. > > How do I tell pkg_add to install the latest version without prompting me? > By the way, talking about packages, it should be noted that stating 'latest version' here is an abuse of notation, as those are two different ports, and each one already represents its latest package version. Regards! > Thanks in advance. > >
Re: Install latest package without prompts on OpenBSD 7.0
El lun, 10 ene 2022 a las 4:10, Jeffrey Walton () escribió: > > Hi Everyone, > > I am working on OpenBSD 7.0, x86_64. I'm trying to script an install > of developer tools I use, like GCC and Git. When I attempt to install > GCC I am prompted: > > $ sudo pkg_add gcc g++ > quirks-4.54 signed on 2022-01-09T19:08:35Z > Ambiguous: choose package for gcc > a0: > 1: gcc-8.4.0p9 > 2: gcc-11.2.0p0 > > I've looked over the man page at https://man.openbsd.org/pkg_add, but > I don't see an option to tell pkg_add to install the latest version of > the package. > > How do I tell pkg_add to install the latest version without prompting me? > Not being ambiguous, i.e. with 'sudo pkg_add gcc-12.2.0p0'. If you're looking forward to finding a one-liner able to install the latest version on packages, I'm not aware of any standard way. Taking output from 'pkg_info', filtering and feeding into 'pkg_add' should do the trick. Regards! > Thanks in advance. >
