Re: netstart: improve DESCRIPTION

2022-10-24 Thread Jason McIntyre
On Mon, Oct 24, 2022 at 06:35:17PM +, Klemens Nanni wrote:
> On Fri, Oct 21, 2022 at 06:58:52PM +, Klemens Nanni wrote:
> > On Fri, Oct 21, 2022 at 06:39:59PM +0100, Jason McIntyre wrote:
> > > i was going to incliude this in my answer, but eventually thought it
> > > looks like a seperate diff:
> > > 
> > > the text currently reads as though only a singular interface is
> > > specified, and -n is kind of hidden. so i reworked the text. i went with
> > > an example which basically mirrors synopsis, because it works with the
> > > -n text, and i wanted to avoid marking up interface, but not doing so
> > > added other ambiguities.
> > > 
> > > so is this better? it's as unobtrusive as i could make it.
> > 
> > I agree with the singular -> plural change to make clear that multiple
> > interfaces work.
> > 
> > However, I don't see much value in an example invocation at the first
> > place:  the synopsis is trivial, echo(1) doesn't have examples, either.
> 
> How about this?
> 
> - use plural to clarify how more than interface may be passed
> - drop the distinction between interface and bridge
> - drop uesless example:  netstart is as trivial as echo(1)
> - mention options the usual way, this also adds tags which makes ":tn"
>   work as expected
> 
> Feedback? Objection? OK?
> 
> 
> Index: netstart.8
> ===
> RCS file: /cvs/src/share/man/man8/netstart.8,v
> retrieving revision 1.29
> diff -u -p -r1.29 netstart.8
> --- netstart.824 Oct 2022 17:58:43 -  1.29
> +++ netstart.824 Oct 2022 18:35:07 -
> @@ -44,7 +44,7 @@ it performs network initialization.
>  .Pp
>  The
>  .Nm
> -script can also be used to start newly created interfaces or bridges.
> +script can also be used to start newly created interfaces.
>  The behaviour of this script is (or can be) controlled to some
>  extent by variables defined in
>  .Xr rc.conf 8 ,
> @@ -88,19 +88,17 @@ and
>  .Xr wg 4 .
>  .El
>  .Pp
> -After the system is completely initialized, it is possible to start a
> -newly created interface or bridges or apply the configuration from a
> +After the system is completely initialized, it is possible to start
> +newly created interfaces or apply configuration from
>  .Xr hostname.if 5
> -file to an existing interface, by invoking the following, where
> -.Ar foo0
> -is the interface or bridge name:
> +files to an existing interfaces.
>  .Pp
> -.D1 # sh /etc/netstart foo0
> -.Pp
> -Using the
> -.Fl n
> -option reports the steps that would be taken,
> -without actually configuring the interface.
> +The options are as follows:
> +.Bl -tag -width Ds
> +.It Fl n
> +Reports the steps that would be taken,
> +without actually configuring anything.
> +.El
>  .Sh SEE ALSO
>  .Xr multicast 4 ,
>  .Xr defaultdomain 5 ,
> 

i think that's fine. ok.
jmc



Re: netstart: do not wait for autoconf in dry-run

2022-10-24 Thread Theo Buehler
On Mon, Oct 24, 2022 at 08:29:22PM +, Klemens Nanni wrote:
> If there is no default route but some interface has AUTOCONF, printing
> what would be done still waits for... nothing to happen.

ok tb



Re: ifconfig, wireguard output less verbose, unless -A or

2022-10-24 Thread Hrvoje Popovski
On 14.10.2022. 23:57, Mikolaj Kucharski wrote:
> Kind reminder. Below there is a comment with an OK from sthen@
> 
> Diff at the end of this email.
> 
> 

Hi all,

can this diff be committed? Less verbose output of ifconfig wg interface
is quite nice when handling wg vpn server

Thank you



> On Wed, Sep 07, 2022 at 05:29:38PM +0100, Stuart Henderson wrote:
>> On 2022/09/07 15:25, Mikolaj Kucharski wrote:
>>> Hi.
>>>
>>> I didn't get a lof of feedback on this on the code level, however
>>> got some intput on manual page changes. At the end of the email is
>>> ifconfig.8 change from jmc@ and ifconfig.c from me.
>>>
>>>
>>> On Sat, Sep 03, 2022 at 04:51:03PM +0100, Jason McIntyre wrote:
 On Sat, Sep 03, 2022 at 08:55:51AM +, Mikolaj Kucharski wrote:
> Hi,
>
> I tried to address what jmc@ mentioned below. I don't really know
> mdoc(7) and English is not my native language, so I imagine there is
> place for improvement in the wg(4) diff.
>

 hi.

 after looking again, i think maybe ifconfig.8 is the better place, but
 just not where it was originally proposed. by way of a peace offering,
 how about the diff below?

 jmc

>>> [...]
>>
>> It's all in ifndef SMALL so there are no ramdisk space concerns.
>> Works as expected, I think it's a good idea. It's OK with me.
>>
>>
>>>
>>> Index: ifconfig.c
>>> ===
>>> RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
>>> retrieving revision 1.456
>>> diff -u -p -u -r1.456 ifconfig.c
>>> --- ifconfig.c  8 Jul 2022 07:04:54 -   1.456
>>> +++ ifconfig.c  7 Sep 2022 15:18:50 -
>>> @@ -363,7 +363,7 @@ voidunsetwgpeer(const char *, int);
>>>  void   unsetwgpeerpsk(const char *, int);
>>>  void   unsetwgpeerall(const char *, int);
>>>  
>>> -void   wg_status();
>>> +void   wg_status(int);
>>>  #else
>>>  void   setignore(const char *, int);
>>>  #endif
>>> @@ -679,7 +679,7 @@ voidprintgroupattribs(char *);
>>>  void   printif(char *, int);
>>>  void   printb_status(unsigned short, unsigned char *);
>>>  const char *get_linkstate(int, int);
>>> -void   status(int, struct sockaddr_dl *, int);
>>> +void   status(int, struct sockaddr_dl *, int, int);
>>>  __dead voidusage(void);
>>>  const char *get_string(const char *, const char *, u_int8_t *, int *);
>>>  intlen_string(const u_int8_t *, int);
>>> @@ -1195,7 +1195,7 @@ printif(char *name, int ifaliases)
>>> continue;
>>> ifdata = ifa->ifa_data;
>>> status(1, (struct sockaddr_dl *)ifa->ifa_addr,
>>> -   ifdata->ifi_link_state);
>>> +   ifdata->ifi_link_state, ifaliases);
>>> count++;
>>> noinet = 1;
>>> continue;
>>> @@ -3316,7 +3316,7 @@ get_linkstate(int mt, int link_state)
>>>   * specified, show it and it only; otherwise, show them all.
>>>   */
>>>  void
>>> -status(int link, struct sockaddr_dl *sdl, int ls)
>>> +status(int link, struct sockaddr_dl *sdl, int ls, int ifaliases)
>>>  {
>>> const struct afswtch *p = afp;
>>> struct ifmediareq ifmr;
>>> @@ -3391,7 +3391,7 @@ status(int link, struct sockaddr_dl *sdl
>>> mpls_status();
>>> pflow_status();
>>> umb_status();
>>> -   wg_status();
>>> +   wg_status(ifaliases);
>>>  #endif
>>> trunk_status();
>>> getifgroups();
>>> @@ -5907,7 +5907,7 @@ process_wg_commands(void)
>>>  }
>>>  
>>>  void
>>> -wg_status(void)
>>> +wg_status(int ifaliases)
>>>  {
>>> size_t   i, j, last_size;
>>> struct timespec  now;
>>> @@ -5942,45 +5942,47 @@ wg_status(void)
>>> printf("\twgpubkey %s\n", key);
>>> }
>>>  
>>> -   wg_peer = _interface->i_peers[0];
>>> -   for (i = 0; i < wg_interface->i_peers_count; i++) {
>>> -   b64_ntop(wg_peer->p_public, WG_KEY_LEN,
>>> -   key, sizeof(key));
>>> -   printf("\twgpeer %s\n", key);
>>> -
>>> -   if (wg_peer->p_flags & WG_PEER_HAS_PSK)
>>> -   printf("\t\twgpsk (present)\n");
>>> -
>>> -   if (wg_peer->p_flags & WG_PEER_HAS_PKA && wg_peer->p_pka)
>>> -   printf("\t\twgpka %u (sec)\n", wg_peer->p_pka);
>>> -
>>> -   if (wg_peer->p_flags & WG_PEER_HAS_ENDPOINT) {
>>> -   if (getnameinfo(_peer->p_sa, wg_peer->p_sa.sa_len,
>>> -   hbuf, sizeof(hbuf), sbuf, sizeof(sbuf),
>>> -   NI_NUMERICHOST | NI_NUMERICSERV) == 0)
>>> -   printf("\t\twgendpoint %s %s\n", hbuf, sbuf);
>>> -   else
>>> -   printf("\t\twgendpoint unable to print\n");
>>> -   }
>>> +   if (ifaliases) {
>>> +   wg_peer = _interface->i_peers[0];
>>> +   for (i = 0; i < wg_interface->i_peers_count; i++) {
>>> +   

netstart: do not wait for autoconf in dry-run

2022-10-24 Thread Klemens Nanni
If there is no default route but some interface has AUTOCONF, printing
what would be done still waits for... nothing to happen.

OK?

Index: netstart
===
RCS file: /cvs/src/etc/netstart,v
retrieving revision 1.220
diff -u -p -r1.220 netstart
--- netstart21 Oct 2022 12:04:51 -  1.220
+++ netstart24 Oct 2022 20:25:06 -
@@ -391,7 +396,7 @@ else
 fi
 
 # If interface autoconf exists, pause a little for at least one default route
-wait_autoconf_default
+$PRINT_ONLY || wait_autoconf_default
 
 # Configure interfaces that rely on routing
 ifmstart "tun tap gif etherip gre egre nvgre eoip vxlan pflow wg"



Re: pijuice(4) testing

2022-10-24 Thread Mark Kettenis
> Date: Mon, 24 Oct 2022 16:19:44 +0200
> From: Marcus Glocker 
> 
> Currently the PiJuice HAT EEPROM doesn't ship with the Device Tree node
> for the I2C MCU which delivers us the battery information.  The reason
> for that is most likely that Linux is offering a /dev/i2c device node
> for userland programs, and the PiJuice team has developed an utility
> which utilizes that.  Therefore, the requirement to expose the device
> to the kernel on Linux doesn't exist.
> 
> To make the device attach on OpenBSD, we require to load a Device Tree
> Overlay for now.  If you have a PiJuice HAT, and would like to test it
> with the new pijuice(4) device driver on current, you can install a DTO
> based on those instructions:
> 
>   https://nazgul.ch/pijuice.html
> 
> We'll reach out to the PiJuice team, and hopefully can convince them
> to flash the DTO to their EEPROM in the future, which would make this
> workaround obsolete over time.

So what we probably need to do is subbmit a device tree binding for
this to the Linux folks.  These days that means a .yaml file that
allows automatic checking of .dts file.  See the stuff under
Documentation/devictree/bindings in the Linux source tree.



netstart: SOII: fix comment, print step with -n

2022-10-24 Thread Klemens Nanni
IPv6LL no longer uses SOII (ifconfig(8) `soii' description got fixed).

Don't ignore this step in dry-runs.  In analogy to how we print
{ ifconfig trunk0 || ifconfig trunk0 create; }

the file check could be deferred and printed as well, i.e.
[[ -f /etc/soii.key ]] && sysctl ...

Better print the check?
Feedback? Objection? OK?

Index: netstart
===
RCS file: /cvs/src/etc/netstart,v
retrieving revision 1.220
diff -u -p -r1.220 netstart
--- netstart21 Oct 2022 12:04:51 -  1.220
+++ netstart24 Oct 2022 18:55:40 -
@@ -323,9 +323,14 @@ done
 shift $((OPTIND-1))
 
 # Load key material for the generation of IPv6 Semantically Opaque Interface
-# Identifiers (SOII) used for link local and SLAAC addresses.
-$PRINT_ONLY || [[ ! -f /etc/soii.key ]] ||
-   sysctl -q "net.inet6.ip6.soiikey=$(

netstart: improve DESCRIPTION

2022-10-24 Thread Klemens Nanni
On Fri, Oct 21, 2022 at 06:58:52PM +, Klemens Nanni wrote:
> On Fri, Oct 21, 2022 at 06:39:59PM +0100, Jason McIntyre wrote:
> > i was going to incliude this in my answer, but eventually thought it
> > looks like a seperate diff:
> > 
> > the text currently reads as though only a singular interface is
> > specified, and -n is kind of hidden. so i reworked the text. i went with
> > an example which basically mirrors synopsis, because it works with the
> > -n text, and i wanted to avoid marking up interface, but not doing so
> > added other ambiguities.
> > 
> > so is this better? it's as unobtrusive as i could make it.
> 
> I agree with the singular -> plural change to make clear that multiple
> interfaces work.
> 
> However, I don't see much value in an example invocation at the first
> place:  the synopsis is trivial, echo(1) doesn't have examples, either.

How about this?

- use plural to clarify how more than interface may be passed
- drop the distinction between interface and bridge
- drop uesless example:  netstart is as trivial as echo(1)
- mention options the usual way, this also adds tags which makes ":tn"
  work as expected

Feedback? Objection? OK?


Index: netstart.8
===
RCS file: /cvs/src/share/man/man8/netstart.8,v
retrieving revision 1.29
diff -u -p -r1.29 netstart.8
--- netstart.8  24 Oct 2022 17:58:43 -  1.29
+++ netstart.8  24 Oct 2022 18:35:07 -
@@ -44,7 +44,7 @@ it performs network initialization.
 .Pp
 The
 .Nm
-script can also be used to start newly created interfaces or bridges.
+script can also be used to start newly created interfaces.
 The behaviour of this script is (or can be) controlled to some
 extent by variables defined in
 .Xr rc.conf 8 ,
@@ -88,19 +88,17 @@ and
 .Xr wg 4 .
 .El
 .Pp
-After the system is completely initialized, it is possible to start a
-newly created interface or bridges or apply the configuration from a
+After the system is completely initialized, it is possible to start
+newly created interfaces or apply configuration from
 .Xr hostname.if 5
-file to an existing interface, by invoking the following, where
-.Ar foo0
-is the interface or bridge name:
+files to an existing interfaces.
 .Pp
-.D1 # sh /etc/netstart foo0
-.Pp
-Using the
-.Fl n
-option reports the steps that would be taken,
-without actually configuring the interface.
+The options are as follows:
+.Bl -tag -width Ds
+.It Fl n
+Reports the steps that would be taken,
+without actually configuring anything.
+.El
 .Sh SEE ALSO
 .Xr multicast 4 ,
 .Xr defaultdomain 5 ,



if_parse_packet(): refactor packet parsing on driver level

2022-10-24 Thread Jan Klemkow
Hi,

We have a lot of redundant code on the network device driver layer, that
parses the content of mbufs for ethernet, ip and tcp header.  This diff
introduces a new function if_parse_packet() to centralize this feature.
It just refactors ix(4) and ixl(4) code because, I could test this cards
and won't blowup this diff.  But, igc(3), ale(4) and oce(4) could also
be improved with this.  Beside of refactoring, we'll need this kind of
code in ix(4) and other drivers for better checksum and TSO support.

I'm not sure about the correct naming or place for this helper function.
Thus, nitpicking and bike shading is welcome. :)

bye,
Jan

Index: dev/pci/if_ix.c
===
RCS file: /mount/openbsd/cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.189
diff -u -p -r1.189 if_ix.c
--- dev/pci/if_ix.c 2 Sep 2022 14:08:09 -   1.189
+++ dev/pci/if_ix.c 24 Oct 2022 13:51:22 -
@@ -2477,25 +2477,18 @@ static inline int
 ixgbe_csum_offload(struct mbuf *mp, uint32_t *vlan_macip_lens,
 uint32_t *type_tucmd_mlhl, uint32_t *olinfo_status)
 {
-   struct ether_header *eh = mtod(mp, struct ether_header *);
-   struct mbuf *m;
-   int hoff;
int offload = 0;
-   uint32_t iphlen;
uint8_t ipproto;
 
-   *vlan_macip_lens |= (sizeof(*eh) << IXGBE_ADVTXD_MACLEN_SHIFT);
+   struct if_hdr hdr;
 
-   switch (ntohs(eh->ether_type)) {
-   case ETHERTYPE_IP: {
-   struct ip *ip;
+   if_parse_packet(mp, );
 
-   m = m_getptr(mp, sizeof(*eh), );
-   KASSERT(m != NULL && m->m_len - hoff >= sizeof(*ip));
-   ip = (struct ip *)(mtod(m, caddr_t) + hoff);
+   *vlan_macip_lens |= (hdr.l2len << IXGBE_ADVTXD_MACLEN_SHIFT);
 
-   iphlen = ip->ip_hl << 2;
-   ipproto = ip->ip_p;
+   switch (ntohs(hdr.eth->ether_type)) {
+   case ETHERTYPE_IP: {
+   ipproto = hdr.ip4->ip_p;
 
if (ISSET(mp->m_pkthdr.csum_flags, M_IPV4_CSUM_OUT)) {
*olinfo_status |= IXGBE_TXD_POPTS_IXSM << 8;
@@ -2508,15 +2501,7 @@ ixgbe_csum_offload(struct mbuf *mp, uint
 
 #ifdef INET6
case ETHERTYPE_IPV6: {
-   struct ip6_hdr *ip6;
-
-   m = m_getptr(mp, sizeof(*eh), );
-   KASSERT(m != NULL && m->m_len - hoff >= sizeof(*ip6));
-   ip6 = (struct ip6_hdr *)(mtod(m, caddr_t) + hoff);
-
-   iphlen = sizeof(*ip6);
-   ipproto = ip6->ip6_nxt;
-
+   ipproto = hdr.ip6->ip6_nxt;
*type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_IPV6;
break;
}
@@ -2526,7 +2511,7 @@ ixgbe_csum_offload(struct mbuf *mp, uint
return offload;
}
 
-   *vlan_macip_lens |= iphlen;
+   *vlan_macip_lens |= hdr.l3len;
 
switch (ipproto) {
case IPPROTO_TCP:
Index: dev/pci/if_ixgb.h
===
RCS file: /mount/openbsd/cvs/src/sys/dev/pci/if_ixgb.h,v
retrieving revision 1.19
diff -u -p -r1.19 if_ixgb.h
--- dev/pci/if_ixgb.h   24 Nov 2015 17:11:39 -  1.19
+++ dev/pci/if_ixgb.h   24 Oct 2022 13:27:43 -
@@ -54,6 +54,7 @@ POSSIBILITY OF SUCH DAMAGE.
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
Index: dev/pci/if_ixl.c
===
RCS file: /mount/openbsd/cvs/src/sys/dev/pci/if_ixl.c,v
retrieving revision 1.84
diff -u -p -r1.84 if_ixl.c
--- dev/pci/if_ixl.c5 Aug 2022 13:57:16 -   1.84
+++ dev/pci/if_ixl.c24 Oct 2022 16:34:29 -
@@ -2784,11 +2784,12 @@ ixl_load_mbuf(bus_dma_tag_t dmat, bus_dm
 static uint64_t
 ixl_tx_setup_offload(struct mbuf *m0)
 {
-   struct mbuf *m;
-   int hoff;
-   uint64_t hlen;
uint8_t ipproto;
uint64_t offload = 0;
+   struct if_hdr hdr;
+
+   memset(, 0, sizeof(hdr));
+   if_parse_packet(m0, );
 
if (ISSET(m0->m_flags, M_VLANTAG)) {
uint64_t vtag = m0->m_pkthdr.ether_vtag;
@@ -2800,35 +2801,20 @@ ixl_tx_setup_offload(struct mbuf *m0)
M_IPV4_CSUM_OUT|M_TCP_CSUM_OUT|M_UDP_CSUM_OUT))
return (offload);
 
-   switch (ntohs(mtod(m0, struct ether_header *)->ether_type)) {
+   switch (ntohs(hdr.eth->ether_type)) {
case ETHERTYPE_IP: {
-   struct ip *ip;
-
-   m = m_getptr(m0, ETHER_HDR_LEN, );
-   KASSERT(m != NULL && m->m_len - hoff >= sizeof(*ip));
-   ip = (struct ip *)(mtod(m, caddr_t) + hoff);
-
offload |= ISSET(m0->m_pkthdr.csum_flags, M_IPV4_CSUM_OUT) ?
IXL_TX_DESC_CMD_IIPT_IPV4_CSUM :
IXL_TX_DESC_CMD_IIPT_IPV4;
  
-   hlen = ip->ip_hl << 2;
-   ipproto = ip->ip_p;
+   ipproto = hdr.ip4->ip_p;
break;
}
 
 #ifdef INET6
case ETHERTYPE_IPV6: 

OpenBSD Errata: October 24, 2022 (libcrypto)

2022-10-24 Thread Alexander Bluhm
Errata patches for libcrypto have been released for OpenBSD 7.2.

Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility.  Source code patches can be found on the
respective errata page:

  https://www.openbsd.org/errata72.html



Re: M1 Macmini lost hw.cpuspeed

2022-10-24 Thread Otto Moerbeek
On Mon, Oct 24, 2022 at 04:15:40PM +0200, Mark Kettenis wrote:

> > Date: Mon, 24 Oct 2022 14:52:00 +0200
> > From: Robert Nagy 
> > 
> > On 24/10/22 14:49 +0200, Theo Buehler wrote:
> > > On Mon, Oct 24, 2022 at 09:24:14AM +0200, Otto Moerbeek wrote:
> > > > Hello,
> > > > 
> > > > after updating my M1 macmini after my vacatiuon to the latest snap it
> > > > seems to have lost a few sysctl nodes, making apm(8) fail:
> > > > 
> > > > [otto@macmini:4]$ ktrace apm
> > > > Battery state: unknown, 0% remaining, unknown life estimate
> > > > AC adapter state: not known
> > > > Performance adjustment mode: invalid (0 MHz)
> > > > 
> > > > ...
> > > > 88255 apm  CALL  
> > > > sysctl(6.12,0x7f10d4,0x7f10c8,0,0)
> > > > 88255 apm  RET   sysctl -1 errno 45 Operation not supported
> > > > ...
> > > > 
> > > > 
> > > > Beforre I spend time on this, does anybody have a clue?
> > > > 
> > > > -Otto
> > > > 
> > > 
> > > I'm seeing the same on my m1 mini. Reverting the commit below fixes it
> > > for me.
> > 
> > Maybe you need a new u-boot that has the new tree?
> 
> Yes there has been some churn in this area in the device tree and I
> removed backwards compatibility for the old old way this was done.
> 
> Now the question is when did you install OpenBSD?  If you have a
> directory called M1N1 on your msdos partition with the file BOOT.BIN
> in it, this will be fairly easy to fix.  Download
> 
>   https://cdn.asahilinux.org/os/uefi-only-20220717-1.zip
> 
> unzip it and copy esp/m1n1/boot.bin to your msdos partition.  Maybe
> make a copy of the old file first (and leave it in that directory)
> just in case.
> 
> If not, fixing this will be a little bit more involved, and I need to
> figure out instructions.  I'm pretty sure this is the case for tb@.
> 
> Cheers,
> 
> Mark

Hi,

the instructions worked for me, thanks!

-Otto



pijuice(4) testing

2022-10-24 Thread Marcus Glocker
Currently the PiJuice HAT EEPROM doesn't ship with the Device Tree node
for the I2C MCU which delivers us the battery information.  The reason
for that is most likely that Linux is offering a /dev/i2c device node
for userland programs, and the PiJuice team has developed an utility
which utilizes that.  Therefore, the requirement to expose the device
to the kernel on Linux doesn't exist.

To make the device attach on OpenBSD, we require to load a Device Tree
Overlay for now.  If you have a PiJuice HAT, and would like to test it
with the new pijuice(4) device driver on current, you can install a DTO
based on those instructions:

https://nazgul.ch/pijuice.html

We'll reach out to the PiJuice team, and hopefully can convince them
to flash the DTO to their EEPROM in the future, which would make this
workaround obsolete over time.

Cheers,
Marcus



Re: M1 Macmini lost hw.cpuspeed

2022-10-24 Thread Mark Kettenis
> Date: Mon, 24 Oct 2022 14:52:00 +0200
> From: Robert Nagy 
> 
> On 24/10/22 14:49 +0200, Theo Buehler wrote:
> > On Mon, Oct 24, 2022 at 09:24:14AM +0200, Otto Moerbeek wrote:
> > > Hello,
> > > 
> > > after updating my M1 macmini after my vacatiuon to the latest snap it
> > > seems to have lost a few sysctl nodes, making apm(8) fail:
> > > 
> > > [otto@macmini:4]$ ktrace apm
> > > Battery state: unknown, 0% remaining, unknown life estimate
> > > AC adapter state: not known
> > > Performance adjustment mode: invalid (0 MHz)
> > > 
> > > ...
> > > 88255 apm  CALL  
> > > sysctl(6.12,0x7f10d4,0x7f10c8,0,0)
> > > 88255 apm  RET   sysctl -1 errno 45 Operation not supported
> > > ...
> > > 
> > > 
> > > Beforre I spend time on this, does anybody have a clue?
> > > 
> > >   -Otto
> > > 
> > 
> > I'm seeing the same on my m1 mini. Reverting the commit below fixes it
> > for me.
> 
> Maybe you need a new u-boot that has the new tree?

Yes there has been some churn in this area in the device tree and I
removed backwards compatibility for the old old way this was done.

Now the question is when did you install OpenBSD?  If you have a
directory called M1N1 on your msdos partition with the file BOOT.BIN
in it, this will be fairly easy to fix.  Download

  https://cdn.asahilinux.org/os/uefi-only-20220717-1.zip

unzip it and copy esp/m1n1/boot.bin to your msdos partition.  Maybe
make a copy of the old file first (and leave it in that directory)
just in case.

If not, fixing this will be a little bit more involved, and I need to
figure out instructions.  I'm pretty sure this is the case for tb@.

Cheers,

Mark



Re: M1 Macmini lost hw.cpuspeed

2022-10-24 Thread Theo Buehler
On Mon, Oct 24, 2022 at 02:52:00PM +0200, Robert Nagy wrote:
> On 24/10/22 14:49 +0200, Theo Buehler wrote:
> > On Mon, Oct 24, 2022 at 09:24:14AM +0200, Otto Moerbeek wrote:
> > > Hello,
> > > 
> > > after updating my M1 macmini after my vacatiuon to the latest snap it
> > > seems to have lost a few sysctl nodes, making apm(8) fail:
> > > 
> > > [otto@macmini:4]$ ktrace apm
> > > Battery state: unknown, 0% remaining, unknown life estimate
> > > AC adapter state: not known
> > > Performance adjustment mode: invalid (0 MHz)
> > > 
> > > ...
> > > 88255 apm  CALL  
> > > sysctl(6.12,0x7f10d4,0x7f10c8,0,0)
> > > 88255 apm  RET   sysctl -1 errno 45 Operation not supported
> > > ...
> > > 
> > > 
> > > Beforre I spend time on this, does anybody have a clue?
> > > 
> > >   -Otto
> > > 
> > 
> > I'm seeing the same on my m1 mini. Reverting the commit below fixes it
> > for me.
> 
> Maybe you need a new u-boot that has the new tree?

Maybe. How can I tell and where do I get it?



Re: M1 Macmini lost hw.cpuspeed

2022-10-24 Thread Robert Nagy
On 24/10/22 14:49 +0200, Theo Buehler wrote:
> On Mon, Oct 24, 2022 at 09:24:14AM +0200, Otto Moerbeek wrote:
> > Hello,
> > 
> > after updating my M1 macmini after my vacatiuon to the latest snap it
> > seems to have lost a few sysctl nodes, making apm(8) fail:
> > 
> > [otto@macmini:4]$ ktrace apm
> > Battery state: unknown, 0% remaining, unknown life estimate
> > AC adapter state: not known
> > Performance adjustment mode: invalid (0 MHz)
> > 
> > ...
> > 88255 apm  CALL  sysctl(6.12,0x7f10d4,0x7f10c8,0,0)
> > 88255 apm  RET   sysctl -1 errno 45 Operation not supported
> > ...
> > 
> > 
> > Beforre I spend time on this, does anybody have a clue?
> > 
> > -Otto
> > 
> 
> I'm seeing the same on my m1 mini. Reverting the commit below fixes it
> for me.

Maybe you need a new u-boot that has the new tree?



Re: M1 Macmini lost hw.cpuspeed

2022-10-24 Thread Theo Buehler
On Mon, Oct 24, 2022 at 09:24:14AM +0200, Otto Moerbeek wrote:
> Hello,
> 
> after updating my M1 macmini after my vacatiuon to the latest snap it
> seems to have lost a few sysctl nodes, making apm(8) fail:
> 
> [otto@macmini:4]$ ktrace apm
> Battery state: unknown, 0% remaining, unknown life estimate
> AC adapter state: not known
> Performance adjustment mode: invalid (0 MHz)
> 
> ...
> 88255 apm  CALL  sysctl(6.12,0x7f10d4,0x7f10c8,0,0)
> 88255 apm  RET   sysctl -1 errno 45 Operation not supported
> ...
> 
> 
> Beforre I spend time on this, does anybody have a clue?
> 
>   -Otto
> 

I'm seeing the same on my m1 mini. Reverting the commit below fixes it
for me.

>From 7486b163f559b1a80fe0fb55e4e58a6eabb5d2c1 Mon Sep 17 00:00:00 2001
From: kettenis 
Date: Tue, 18 Oct 2022 15:12:13 +
Subject: [PATCH] No longer match on "apple,cluster-cpufreq" compatible string.

ok miod@, kn@
---
 sys/arch/arm64/dev/aplcpu.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sys/arch/arm64/dev/aplcpu.c b/sys/arch/arm64/dev/aplcpu.c
index f6ce7cd3fba..22d672629b9 100644
--- a/sys/arch/arm64/dev/aplcpu.c
+++ b/sys/arch/arm64/dev/aplcpu.c
@@ -1,4 +1,4 @@
-/* $OpenBSD: aplcpu.c,v 1.3 2022/08/25 19:16:29 kettenis Exp $ */
+/* $OpenBSD: aplcpu.c,v 1.4 2022/10/18 15:12:13 kettenis Exp $ */
 /*
  * Copyright (c) 2022 Mark Kettenis 
  *
@@ -105,9 +105,7 @@ aplcpu_match(struct device *parent, void *match, void *aux)
 {
struct fdt_attach_args *faa = aux;
 
-   /* XXX Remove "apple,cluster-cpufreq" after OpenBSD 7.2 release. */
-   return OF_is_compatible(faa->fa_node, "apple,soc-cpufreq") ||
-   OF_is_compatible(faa->fa_node, "apple,cluster-cpufreq");
+   return OF_is_compatible(faa->fa_node, "apple,soc-cpufreq");
 }
 
 void
-- 
2.38.1



Re: rpki-client: make x509_init_oid() table-based?

2022-10-24 Thread Claudio Jeker
On Mon, Oct 24, 2022 at 11:58:50AM +0200, Theo Buehler wrote:
> The amount of copy-paste and repetition in x509_init_oid() is becoming a
> bit much. The function is an eyesore due to the repetition and made
> worse by the inconsistent wrapping. It's long past the point where my
> brain is still able to process the code.
> 
> How about letting code deal with the repetition and fill the info into a
> table when we need to add an oid?

OK claudio@
 
> Index: x509.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/x509.c,v
> retrieving revision 1.50
> diff -u -p -r1.50 x509.c
> --- x509.c3 Sep 2022 14:40:09 -   1.50
> +++ x509.c24 Oct 2022 09:56:55 -
> @@ -46,45 +46,78 @@ ASN1_OBJECT   *bin_sign_time_oid; /* pkcs-
>  ASN1_OBJECT  *rsc_oid;   /* id-ct-signedChecklist */
>  ASN1_OBJECT  *aspa_oid;  /* id-ct-ASPA */
>  
> +static const struct {
> + const char   *oid;
> + ASN1_OBJECT **ptr;
> +} oid_table[] = {
> + {
> + .oid = "1.3.6.1.5.5.7.14.2",
> + .ptr = _oid,
> + },
> + {
> + .oid = "1.3.6.1.5.5.7.48.5",
> + .ptr = _oid,
> + },
> + {
> + .oid = "1.3.6.1.5.5.7.48.10",
> + .ptr = _oid,
> + },
> + {
> + .oid = "1.3.6.1.5.5.7.48.13",
> + .ptr = _oid,
> + },
> + {
> + .oid = "1.2.840.113549.1.9.16.1.24",
> + .ptr = _oid,
> + },
> + {
> + .oid = "1.2.840.113549.1.9.16.1.26",
> + .ptr = _oid,
> + },
> + {
> + .oid = "1.2.840.113549.1.9.16.1.35",
> + .ptr = _oid,
> + },
> + {
> + .oid = "1.3.6.1.5.5.7.3.30",
> + .ptr = _oid,
> + },
> + {
> + .oid = "1.2.840.113549.1.9.3",
> + .ptr = _type_oid,
> + },
> + {
> + .oid = "1.2.840.113549.1.9.4",
> + .ptr = _dgst_oid,
> + },
> + {
> + .oid = "1.2.840.113549.1.9.5",
> + .ptr = _time_oid,
> + },
> + {
> + .oid = "1.2.840.113549.1.9.16.2.46",
> + .ptr = _sign_time_oid,
> + },
> + {
> + .oid = "1.2.840.113549.1.9.16.1.48",
> + .ptr = _oid,
> + },
> + {
> + .oid = "1.2.840.113549.1.9.16.1.49",
> + .ptr = _oid,
> + },
> +};
> +
>  void
>  x509_init_oid(void)
>  {
> + size_t  i;
>  
> - if ((certpol_oid = OBJ_txt2obj("1.3.6.1.5.5.7.14.2", 1)) == NULL)
> - errx(1, "OBJ_txt2obj for %s failed", "1.3.6.1.5.5.7.14.2");
> - if ((carepo_oid = OBJ_txt2obj("1.3.6.1.5.5.7.48.5", 1)) == NULL)
> - errx(1, "OBJ_txt2obj for %s failed", "1.3.6.1.5.5.7.48.5");
> - if ((manifest_oid = OBJ_txt2obj("1.3.6.1.5.5.7.48.10", 1)) == NULL)
> - errx(1, "OBJ_txt2obj for %s failed", "1.3.6.1.5.5.7.48.10");
> - if ((notify_oid = OBJ_txt2obj("1.3.6.1.5.5.7.48.13", 1)) == NULL)
> - errx(1, "OBJ_txt2obj for %s failed", "1.3.6.1.5.5.7.48.13");
> - if ((roa_oid = OBJ_txt2obj("1.2.840.113549.1.9.16.1.24", 1)) == NULL)
> - errx(1, "OBJ_txt2obj for %s failed",
> - "1.2.840.113549.1.9.16.1.24");
> - if ((mft_oid = OBJ_txt2obj("1.2.840.113549.1.9.16.1.26", 1)) == NULL)
> - errx(1, "OBJ_txt2obj for %s failed",
> - "1.2.840.113549.1.9.16.1.26");
> - if ((gbr_oid = OBJ_txt2obj("1.2.840.113549.1.9.16.1.35", 1)) == NULL)
> - errx(1, "OBJ_txt2obj for %s failed",
> - "1.2.840.113549.1.9.16.1.35");
> - if ((bgpsec_oid = OBJ_txt2obj("1.3.6.1.5.5.7.3.30", 1)) == NULL)
> - errx(1, "OBJ_txt2obj for %s failed", "1.3.6.1.5.5.7.3.30");
> - if ((cnt_type_oid = OBJ_txt2obj("1.2.840.113549.1.9.3", 1)) == NULL)
> - errx(1, "OBJ_txt2obj for %s failed", "1.2.840.113549.1.9.3");
> - if ((msg_dgst_oid = OBJ_txt2obj("1.2.840.113549.1.9.4", 1)) == NULL)
> - errx(1, "OBJ_txt2obj for %s failed", "1.2.840.113549.1.9.4");
> - if ((sign_time_oid = OBJ_txt2obj("1.2.840.113549.1.9.5", 1)) == NULL)
> - errx(1, "OBJ_txt2obj for %s failed", "1.2.840.113549.1.9.5");
> - if ((bin_sign_time_oid =
> - OBJ_txt2obj("1.2.840.113549.1.9.16.2.46", 1)) == NULL)
> - errx(1, "OBJ_txt2obj for %s failed",
> - "1.2.840.113549.1.9.16.2.46");
> - if ((rsc_oid = OBJ_txt2obj("1.2.840.113549.1.9.16.1.48", 1)) == NULL)
> - errx(1, "OBJ_txt2obj for %s failed",
> - "1.2.840.113549.1.9.16.1.48");
> - if ((aspa_oid = OBJ_txt2obj("1.2.840.113549.1.9.16.1.49", 1)) == NULL)
> - errx(1, "OBJ_txt2obj for %s failed",
> - "1.2.840.113549.1.9.16.1.49");
> + for (i = 0; i < sizeof(oid_table) / sizeof(oid_table[0]); i++) {
> + *oid_table[i].ptr = OBJ_txt2obj(oid_table[i].oid, 1);
> +

Re: rpki-client: make x509_init_oid() table-based?

2022-10-24 Thread Job Snijders
On Mon, Oct 24, 2022 at 11:58:50AM +0200, Theo Buehler wrote:
> The amount of copy-paste and repetition in x509_init_oid() is becoming
> a bit much. The function is an eyesore due to the repetition and made
> worse by the inconsistent wrapping. It's long past the point where my
> brain is still able to process the code.
> 
> How about letting code deal with the repetition and fill the info into
> a table when we need to add an oid?

OK job@



rpki-client: make x509_init_oid() table-based?

2022-10-24 Thread Theo Buehler
The amount of copy-paste and repetition in x509_init_oid() is becoming a
bit much. The function is an eyesore due to the repetition and made
worse by the inconsistent wrapping. It's long past the point where my
brain is still able to process the code.

How about letting code deal with the repetition and fill the info into a
table when we need to add an oid?

Index: x509.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/x509.c,v
retrieving revision 1.50
diff -u -p -r1.50 x509.c
--- x509.c  3 Sep 2022 14:40:09 -   1.50
+++ x509.c  24 Oct 2022 09:56:55 -
@@ -46,45 +46,78 @@ ASN1_OBJECT *bin_sign_time_oid; /* pkcs-
 ASN1_OBJECT*rsc_oid;   /* id-ct-signedChecklist */
 ASN1_OBJECT*aspa_oid;  /* id-ct-ASPA */
 
+static const struct {
+   const char   *oid;
+   ASN1_OBJECT **ptr;
+} oid_table[] = {
+   {
+   .oid = "1.3.6.1.5.5.7.14.2",
+   .ptr = _oid,
+   },
+   {
+   .oid = "1.3.6.1.5.5.7.48.5",
+   .ptr = _oid,
+   },
+   {
+   .oid = "1.3.6.1.5.5.7.48.10",
+   .ptr = _oid,
+   },
+   {
+   .oid = "1.3.6.1.5.5.7.48.13",
+   .ptr = _oid,
+   },
+   {
+   .oid = "1.2.840.113549.1.9.16.1.24",
+   .ptr = _oid,
+   },
+   {
+   .oid = "1.2.840.113549.1.9.16.1.26",
+   .ptr = _oid,
+   },
+   {
+   .oid = "1.2.840.113549.1.9.16.1.35",
+   .ptr = _oid,
+   },
+   {
+   .oid = "1.3.6.1.5.5.7.3.30",
+   .ptr = _oid,
+   },
+   {
+   .oid = "1.2.840.113549.1.9.3",
+   .ptr = _type_oid,
+   },
+   {
+   .oid = "1.2.840.113549.1.9.4",
+   .ptr = _dgst_oid,
+   },
+   {
+   .oid = "1.2.840.113549.1.9.5",
+   .ptr = _time_oid,
+   },
+   {
+   .oid = "1.2.840.113549.1.9.16.2.46",
+   .ptr = _sign_time_oid,
+   },
+   {
+   .oid = "1.2.840.113549.1.9.16.1.48",
+   .ptr = _oid,
+   },
+   {
+   .oid = "1.2.840.113549.1.9.16.1.49",
+   .ptr = _oid,
+   },
+};
+
 void
 x509_init_oid(void)
 {
+   size_t  i;
 
-   if ((certpol_oid = OBJ_txt2obj("1.3.6.1.5.5.7.14.2", 1)) == NULL)
-   errx(1, "OBJ_txt2obj for %s failed", "1.3.6.1.5.5.7.14.2");
-   if ((carepo_oid = OBJ_txt2obj("1.3.6.1.5.5.7.48.5", 1)) == NULL)
-   errx(1, "OBJ_txt2obj for %s failed", "1.3.6.1.5.5.7.48.5");
-   if ((manifest_oid = OBJ_txt2obj("1.3.6.1.5.5.7.48.10", 1)) == NULL)
-   errx(1, "OBJ_txt2obj for %s failed", "1.3.6.1.5.5.7.48.10");
-   if ((notify_oid = OBJ_txt2obj("1.3.6.1.5.5.7.48.13", 1)) == NULL)
-   errx(1, "OBJ_txt2obj for %s failed", "1.3.6.1.5.5.7.48.13");
-   if ((roa_oid = OBJ_txt2obj("1.2.840.113549.1.9.16.1.24", 1)) == NULL)
-   errx(1, "OBJ_txt2obj for %s failed",
-   "1.2.840.113549.1.9.16.1.24");
-   if ((mft_oid = OBJ_txt2obj("1.2.840.113549.1.9.16.1.26", 1)) == NULL)
-   errx(1, "OBJ_txt2obj for %s failed",
-   "1.2.840.113549.1.9.16.1.26");
-   if ((gbr_oid = OBJ_txt2obj("1.2.840.113549.1.9.16.1.35", 1)) == NULL)
-   errx(1, "OBJ_txt2obj for %s failed",
-   "1.2.840.113549.1.9.16.1.35");
-   if ((bgpsec_oid = OBJ_txt2obj("1.3.6.1.5.5.7.3.30", 1)) == NULL)
-   errx(1, "OBJ_txt2obj for %s failed", "1.3.6.1.5.5.7.3.30");
-   if ((cnt_type_oid = OBJ_txt2obj("1.2.840.113549.1.9.3", 1)) == NULL)
-   errx(1, "OBJ_txt2obj for %s failed", "1.2.840.113549.1.9.3");
-   if ((msg_dgst_oid = OBJ_txt2obj("1.2.840.113549.1.9.4", 1)) == NULL)
-   errx(1, "OBJ_txt2obj for %s failed", "1.2.840.113549.1.9.4");
-   if ((sign_time_oid = OBJ_txt2obj("1.2.840.113549.1.9.5", 1)) == NULL)
-   errx(1, "OBJ_txt2obj for %s failed", "1.2.840.113549.1.9.5");
-   if ((bin_sign_time_oid =
-   OBJ_txt2obj("1.2.840.113549.1.9.16.2.46", 1)) == NULL)
-   errx(1, "OBJ_txt2obj for %s failed",
-   "1.2.840.113549.1.9.16.2.46");
-   if ((rsc_oid = OBJ_txt2obj("1.2.840.113549.1.9.16.1.48", 1)) == NULL)
-   errx(1, "OBJ_txt2obj for %s failed",
-   "1.2.840.113549.1.9.16.1.48");
-   if ((aspa_oid = OBJ_txt2obj("1.2.840.113549.1.9.16.1.49", 1)) == NULL)
-   errx(1, "OBJ_txt2obj for %s failed",
-   "1.2.840.113549.1.9.16.1.49");
+   for (i = 0; i < sizeof(oid_table) / sizeof(oid_table[0]); i++) {
+   *oid_table[i].ptr = OBJ_txt2obj(oid_table[i].oid, 1);
+   if (*oid_table[i].ptr == NULL)
+   errx(1, "OBJ_txt2obj for %s failed", oid_table[i].oid);
+   }

Re: sparc64: bootblk: let bsd.prog.mk do the work

2022-10-24 Thread Klemens Nanni
On Wed, Oct 12, 2022 at 05:55:10PM +, Klemens Nanni wrote:
>  sets up CLEANFILES, build/install targets and more, so no
> need to roll them ourselves if we just set PROG and SRCS.
> 
> STRIPFLAG is defined but not used and in  INSTALL_STRIP is
> the magic word, so fix that.
> 
> Don't replace "bootblk" wth "${PROG}" to avoid churn.
> 
> 
> No object change, `make' does exactly the same, `make install' got more
> explicit:
>   -install -c -o root -g bin -m 644  bootblk /usr/mdec
>   +install -c   -o root -g bin  -m 644 bootblk /usr/mdec/bootblk
> 
> Feedback? OK?

Ping.

Index: sys/arch/sparc64/stand/bootblk/Makefile
===
RCS file: /cvs/src/sys/arch/sparc64/stand/bootblk/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- sys/arch/sparc64/stand/bootblk/Makefile 2 Apr 2020 06:06:22 -   
1.15
+++ sys/arch/sparc64/stand/bootblk/Makefile 24 Oct 2022 07:53:27 -
@@ -9,10 +9,12 @@ S=${CURDIR}/../../../..
 #
 
 CLEANFILES=machine ffs.fth.h \
-   bootblk bootblk.text bootblk.text.tmp -.d
+   bootblk.text bootblk.text.tmp -.d
 
+PROG=  bootblk
+SRCS=
 NOMAN=
-STRIPFLAG=
+INSTALL_STRIP=
 BINMODE=644
 
 INCLUDES=  -I. -I$S/arch -I$S -nostdinc
@@ -24,7 +26,7 @@ CPPFLAGS= ${INCLUDES} ${IDENT} ${PARAM}
@([ -h machine ] || ln -s ${.CURDIR}/../../include machine)
 .endif
 
-all: bootblk.text bootblk
+all: bootblk.text
 
 ffs.fth.h: ${.CURDIR}/genassym.sh genfth.cf
sh ${.CURDIR}/genassym.sh -f ${CC} ${CFLAGS} ${CPPFLAGS} ${PROF} \
@@ -38,10 +40,6 @@ bootblk.text: bootblk.fth ffs.fth.h
 
 bootblk: bootblk.fth ffs.fth.h
fgen -o bootblk ${.CURDIR}/bootblk.fth
-
-beforeinstall:
-   ${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
-   bootblk ${DESTDIR}/usr/mdec
 
 #
 # The following are if you grab the fakeboot program from the Sun website



M1 Macmini lost hw.cpuspeed

2022-10-24 Thread Otto Moerbeek
Hello,

after updating my M1 macmini after my vacatiuon to the latest snap it
seems to have lost a few sysctl nodes, making apm(8) fail:

[otto@macmini:4]$ ktrace apm
Battery state: unknown, 0% remaining, unknown life estimate
AC adapter state: not known
Performance adjustment mode: invalid (0 MHz)

...
88255 apm  CALL  sysctl(6.12,0x7f10d4,0x7f10c8,0,0)
88255 apm  RET   sysctl -1 errno 45 Operation not supported
...


Beforre I spend time on this, does anybody have a clue?

-Otto