Re: acpicpu(4) and ACPI0007

2020-07-27 Thread Jonathan Matthew
On Mon, Jul 27, 2020 at 05:16:47PM +0200, Mark Kettenis wrote:
> > Date: Mon, 27 Jul 2020 17:02:41 +0200 (CEST)
> > From: Mark Kettenis 
> > 
> > Recent ACPI versions have deprecated "Processor()" nodes in favout of
> > "Device()" nodes with a _HID() method that returns "ACPI0007".  This
> > diff tries to support machines with firmware that implements this.  If
> > you see something like:
> > 
> >   "ACPI0007" at acpi0 not configured
> > 
> > please try the following diff and report back with an updated dmesg.
> > 
> > Cheers,
> > 
> > Mark
> 
> And now with the right diff...

On a dell r6415, it looks like this:

acpicpu0 at acpi0copyvalue: 6: C1(@1 halt!)
all the way up to
acpicpu127 at acpi0copyvalue: 6: no cpu matching ACPI ID 127

which I guess means aml_copyvalue() needs to learn how to copy 
AML_OBJTYPE_DEVICE.

> 
> 
> Index: dev/acpi/acpicpu.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpicpu.c,v
> retrieving revision 1.85
> diff -u -p -r1.85 acpicpu.c
> --- dev/acpi/acpicpu.c27 May 2020 05:02:21 -  1.85
> +++ dev/acpi/acpicpu.c27 Jul 2020 14:58:38 -
> @@ -186,6 +186,11 @@ struct cfdriver acpicpu_cd = {
>   NULL, "acpicpu", DV_DULL
>  };
>  
> +const char *acpicpu_hids[] = {
> + "ACPI0007",
> + NULL
> +};
> +
>  extern int setperf_prio;
>  
>  struct acpicpu_softc *acpicpu_sc[MAXCPUS];
> @@ -650,6 +655,9 @@ acpicpu_match(struct device *parent, voi
>   struct acpi_attach_args *aa = aux;
>   struct cfdata   *cf = match;
>  
> + if (acpi_matchhids(aa, acpicpu_hids, cf->cf_driver->cd_name))
> + return (1);
> +
>   /* sanity */
>   if (aa->aaa_name == NULL ||
>   strcmp(aa->aaa_name, cf->cf_driver->cd_name) != 0 ||
> @@ -665,6 +673,7 @@ acpicpu_attach(struct device *parent, st
>   struct acpicpu_softc*sc = (struct acpicpu_softc *)self;
>   struct acpi_attach_args *aa = aux;
>   struct aml_valueres;
> + int64_t uid;
>   int i;
>   uint32_tstatus = 0;
>   CPU_INFO_ITERATOR   cii;
> @@ -675,6 +684,10 @@ acpicpu_attach(struct device *parent, st
>   acpicpu_sc[sc->sc_dev.dv_unit] = sc;
>  
>   SLIST_INIT(>sc_cstates);
> +
> + if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode,
> + "_UID", 0, NULL, ) == 0)
> + sc->sc_cpu = uid;
>  
>   if (aml_evalnode(sc->sc_acpi, sc->sc_devnode, 0, NULL, ) == 0) {
>   if (res.type == AML_OBJTYPE_PROCESSOR) {
> 



sbus.4: remove iommu mention

2020-07-27 Thread Klemens Nanni
There since import from NetBSD, but we have no iommu(4).

OK?

Index: share/man/man4/sbus.4
===
RCS file: /cvs/src/share/man/man4/sbus.4,v
retrieving revision 1.53
diff -u -p -r1.53 sbus.4
--- share/man/man4/sbus.4   18 Jun 2018 06:06:52 -  1.53
+++ share/man/man4/sbus.4   28 Jul 2020 03:01:46 -
@@ -36,7 +36,6 @@
 .Nd introduction to SBus bus support
 .Sh SYNOPSIS
 .Cd "sbus* at mainbus?"
-.Cd "sbus* at iommu?"
 .Cd "sbus* at xbox?"
 .Sh DESCRIPTION
 These



Re: Improve ure(4) performance

2020-07-27 Thread Jonathon Fletcher
On Mon, Jul 27, 2020 at 07:13:33PM +, Mikolaj Kucharski wrote:
> On Mon, Jul 27, 2020 at 11:58:02AM -0700, Jonathon Fletcher wrote:
> > 
> > Are you ok using patch's -l option for this patch?
> 
> Sure, can do. New kernel compiled, will switch my machine tonight. Will
> let you know how things go. For meetings I would need couple of days, as
> I don't have Google Meet calls that often.

Mikolaj,

Great, thank you. I have attached the patch below with the whitespace intact.

Thanks,
Jonathon

Index: sys/dev/usb/if_urereg.h
===
RCS file: /cvs/src/sys/dev/usb/if_urereg.h,v
retrieving revision 1.8
diff -u -p -u -r1.8 if_urereg.h
--- sys/dev/usb/if_urereg.h 7 Dec 2019 08:45:28 -   1.8
+++ sys/dev/usb/if_urereg.h 27 Jul 2020 17:10:09 -
@@ -494,28 +494,32 @@ struct ure_txpkt {
 #define URE_ENDPT_TX   1
 #define URE_ENDPT_MAX  2
 
-#defineURE_TX_LIST_CNT 8
+#defineURE_TX_LIST_CNT 1
 #defineURE_RX_LIST_CNT 1
-#defineURE_RX_BUF_ALIGNsizeof(uint64_t)
+#defineURE_TX_BUF_ALIGN4
+#defineURE_RX_BUF_ALIGN8
 
-#defineURE_TXBUFSZ 16384
-#defineURE_8152_RXBUFSZ16384
-#defineURE_8153_RXBUFSZ32768
+#defineURE_8152_TX_BUFSZ   16384
+#defineURE_8152_RX_BUFSZ   16384
+
+#defineURE_8153_TX_BUFSZ   16384
+#defineURE_8153_RX_BUFSZ   32768
 
 struct ure_chain {
struct ure_softc*uc_sc;
struct usbd_xfer*uc_xfer;
char*uc_buf;
-   struct mbuf *uc_mbuf;
-   int uc_accum;
-   int uc_idx;
+   uint32_tuc_buflen;
+   uint32_tuc_bufmax;
+   struct mbuf_listuc_mbuf_list;
+   SLIST_ENTRY(ure_chain)  ure_list;
+   uint8_t uc_idx;
 };
 
 struct ure_cdata {
-   struct ure_chaintx_chain[URE_TX_LIST_CNT];
-   struct ure_chainrx_chain[URE_RX_LIST_CNT];
-   int tx_prod;
-   int tx_cnt;
+   struct ure_chainure_rx_chain[URE_RX_LIST_CNT];
+   struct ure_chainure_tx_chain[URE_TX_LIST_CNT];
+   SLIST_HEAD(ure_list_head, ure_chain)ure_tx_free;
 };
 
 struct ure_softc {
@@ -541,7 +545,7 @@ struct ure_softc {
 
struct timeval  ure_rx_notice;
int ure_rxbufsz;
-   int ure_tx_list_cnt;
+   int ure_txbufsz;
 
int ure_phyno;
 
Index: sys/dev/usb/if_ure.c
===
RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
retrieving revision 1.16
diff -u -p -u -r1.16 if_ure.c
--- sys/dev/usb/if_ure.c10 Jul 2020 13:26:41 -  1.16
+++ sys/dev/usb/if_ure.c27 Jul 2020 17:10:39 -
@@ -117,11 +117,13 @@ void  ure_miibus_writereg(struct device 
 void   ure_lock_mii(struct ure_softc *);
 void   ure_unlock_mii(struct ure_softc *);
 
-inture_encap(struct ure_softc *, struct mbuf *);
+inture_encap_txpkt(struct mbuf *, char *, uint32_t);
+inture_encap_xfer(struct ifnet *, struct ure_softc *, struct 
ure_chain *);
 void   ure_rxeof(struct usbd_xfer *, void *, usbd_status);
 void   ure_txeof(struct usbd_xfer *, void *, usbd_status);
-inture_rx_list_init(struct ure_softc *);
-inture_tx_list_init(struct ure_softc *);
+inture_xfer_list_init(struct ure_softc *, struct ure_chain *,
+   uint32_t, int);
+void   ure_xfer_list_free(struct ure_softc *, struct ure_chain *, int);
 
 void   ure_tick_task(void *);
 void   ure_tick(void *);
@@ -625,12 +627,36 @@ void
 ure_watchdog(struct ifnet *ifp)
 {
struct ure_softc*sc = ifp->if_softc;
+   struct ure_chain*c;
+   usbd_status err;
+   int i, s;
+
+   ifp->if_timer = 0;
 
if (usbd_is_dying(sc->ure_udev))
return;
 
+   if ((ifp->if_flags & (IFF_RUNNING|IFF_UP)) != (IFF_RUNNING|IFF_UP))
+   return;
+
+   sc = ifp->if_softc;
+   s = splnet();
+
ifp->if_oerrors++;
-   printf("%s: watchdog timeout\n", sc->ure_dev.dv_xname);
+   DPRINTF(("watchdog timeout\n"));
+
+   for (i = 0; i < URE_TX_LIST_CNT; i++) {
+   c = >ure_cdata.ure_tx_chain[i];
+   if (ml_len(>uc_mbuf_list) > 0) {
+   usbd_get_xfer_status(c->uc_xfer, NULL, NULL, NULL,
+   );
+   ure_txeof(c->uc_xfer, c, err);
+   }
+   }
+
+   if (ifq_is_oactive(>if_snd))
+   

Re: ssh(1), getrrsetbyname(3), SSHFP and DNSSEC

2020-07-27 Thread Jesper Wallin
On Mon, Jul 27, 2020 at 03:30:52AM +0200, Jeremie Courreges-Anglas wrote:
> On Sun, Jul 26 2020, Jesper Wallin  wrote:
> > On Sat, Jul 25, 2020 at 02:01:06PM +0200, Jeremie Courreges-Anglas wrote:
> >> 
> >> For those two reasons I think the feature should be opt-in.
> >
> > Yeah, I agree with you.  My first approach was to have it check what
> > kind of DNS record that was requested, and add the AD-flag only if type
> > was SSHFP, but that felt even uglier.  I also wasn't so sure my approach
> > was the right one after reading the RFCs Peter J. Philipp mentioned.
> 
> The quote from RFC6840 seems clear to me, care to share why you had some
> doubts if they still exist?

Sorry for being unclear, I was referring to the previous RFCs, but no,
no doubts.  RFC6840 is indeed clear on the matter.

> > Perhaps another approach would be to make use of the currently unused
> > flags argument in getrrsetbyname(3)?  This way, only getrrsetbyname(3)
> > and certain requests are affected by it.
> 
> I thought about that too, but getrrsetbyname(3) isn't the only function
> of interest.  There's also res_query(3) and friends, which are in more
> widely use in the larger ecosystem.  I guess we could restrict AD flag
> tweaking to APIs where the caller can actually access the AD flag in the
> response, but the "default vs opt-in" question is still present.
>

Yeah, true.  I'd say that opt-in is the proper way to go, no matter what
approcah is taken.  For what it's worth, my vote is to go with your 
trust-ad approach.  It's a lot more elegant than mine.  It would need
some manuals changes though, to cover the cases benno@ mentioned.

I still think the RES_USE_AD option might be a useful though, for when
you want to decide on an application-level whether to trust AD or not?


Yours,
Jesper Wallin



Re: Improve ure(4) performance

2020-07-27 Thread Mikolaj Kucharski
On Mon, Jul 27, 2020 at 11:58:02AM -0700, Jonathon Fletcher wrote:
> 
> Are you ok using patch's -l option for this patch?
> 

Sure, can do. New kernel compiled, will switch my machine tonight. Will
let you know how things go. For meetings I would need couple of days, as
I don't have Google Meet calls that often.

-- 
Regards,
 Mikolaj



Re: Improve ure(4) performance

2020-07-27 Thread Jonathon Fletcher


> On Jul 27, 2020, at 11:47 AM, Mikolaj Kucharski  
> wrote:
> 
> On Mon, Jul 27, 2020 at 11:24:55AM -0700, Jonathon Fletcher wrote:
>> 
>> I have attached an updated patch - which includes Kevin's changes from
>> his earlier email - that also corrects the tx buffer sizes for RTL8153
>> / RTL8153B devices.
>> 
> 
> Unfortunately below diff fails to apply.
> 
> 2 out of 2 hunks failed
> 15 out of 15 hunks failed
> 
> I've tried on fresh cvs version of if_urereg.h and if_ure.c
> 
> I usually, for convenience take the diffs from marc.info :
> 
> https://marc.info/?l=openbsd-tech=159587449018248=mbox 
> 

I appear to have a mangled whitespace problem with my email.

It applies successfully when I copy / paste the patch out of the url above and 
apply it from /usr/src with patch -p0 -l .

Are you ok using patch's -l option for this patch?

Thanks,
Jonathon



Re: Improve ure(4) performance

2020-07-27 Thread Mikolaj Kucharski
On Mon, Jul 27, 2020 at 11:24:55AM -0700, Jonathon Fletcher wrote:
> 
> I have attached an updated patch - which includes Kevin's changes from
> his earlier email - that also corrects the tx buffer sizes for RTL8153
> / RTL8153B devices.
> 

Unfortunately below diff fails to apply.

2 out of 2 hunks failed
15 out of 15 hunks failed

I've tried on fresh cvs version of if_urereg.h and if_ure.c

I usually, for convenience take the diffs from marc.info:

https://marc.info/?l=openbsd-tech=159587449018248=mbox

> 
> Index: sys/dev/usb/if_urereg.h
> ===
> RCS file: /cvs/src/sys/dev/usb/if_urereg.h,v
> retrieving revision 1.8
> diff -u -p -u -r1.8 if_urereg.h
> --- sys/dev/usb/if_urereg.h 7 Dec 2019 08:45:28 - 1.8
> +++ sys/dev/usb/if_urereg.h 27 Jul 2020 17:10:09 -
> @@ -494,28 +494,32 @@ struct ure_txpkt {
>  #define URE_ENDPT_TX 1
>  #define URE_ENDPT_MAX 2
> 
> -#define URE_TX_LIST_CNT 8
> +#define URE_TX_LIST_CNT 1
>  #define URE_RX_LIST_CNT 1
> -#define URE_RX_BUF_ALIGN sizeof(uint64_t)
> +#define URE_TX_BUF_ALIGN 4
> +#define URE_RX_BUF_ALIGN 8
> 
> -#define URE_TXBUFSZ 16384
> -#define URE_8152_RXBUFSZ 16384
> -#define URE_8153_RXBUFSZ 32768
> +#define URE_8152_TX_BUFSZ 16384
> +#define URE_8152_RX_BUFSZ 16384
> +
> +#define URE_8153_TX_BUFSZ 16384
> +#define URE_8153_RX_BUFSZ 32768
> 
>  struct ure_chain {
>   struct ure_softc *uc_sc;
>   struct usbd_xfer *uc_xfer;
>   char *uc_buf;
> - struct mbuf *uc_mbuf;
> - int uc_accum;
> - int uc_idx;
> + uint32_t uc_buflen;
> + uint32_t uc_bufmax;
> + struct mbuf_list uc_mbuf_list;
> + SLIST_ENTRY(ure_chain)  ure_list;
> + uint8_t uc_idx;
>  };
> 
>  struct ure_cdata {
> - struct ure_chain tx_chain[URE_TX_LIST_CNT];
> - struct ure_chain rx_chain[URE_RX_LIST_CNT];
> - int tx_prod;
> - int tx_cnt;
> + struct ure_chain ure_rx_chain[URE_RX_LIST_CNT];
> + struct ure_chain ure_tx_chain[URE_TX_LIST_CNT];
> + SLIST_HEAD(ure_list_head, ure_chain)ure_tx_free;
>  };
> 
>  struct ure_softc {
> @@ -541,7 +545,7 @@ struct ure_softc {
> 
>   struct timeval ure_rx_notice;
>   int ure_rxbufsz;
> - int ure_tx_list_cnt;
> + int ure_txbufsz;
> 
>   int ure_phyno;
> 
> Index: sys/dev/usb/if_ure.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
> retrieving revision 1.16
> diff -u -p -u -r1.16 if_ure.c
> --- sys/dev/usb/if_ure.c 10 Jul 2020 13:26:41 - 1.16
> +++ sys/dev/usb/if_ure.c 27 Jul 2020 17:10:39 -
> @@ -117,11 +117,13 @@ void ure_miibus_writereg(struct device
>  void ure_lock_mii(struct ure_softc *);
>  void ure_unlock_mii(struct ure_softc *);
> 
> -int ure_encap(struct ure_softc *, struct mbuf *);
> +int ure_encap_txpkt(struct mbuf *, char *, uint32_t);
> +int ure_encap_xfer(struct ifnet *, struct ure_softc *, struct ure_chain *);
>  void ure_rxeof(struct usbd_xfer *, void *, usbd_status);
>  void ure_txeof(struct usbd_xfer *, void *, usbd_status);
> -int ure_rx_list_init(struct ure_softc *);
> -int ure_tx_list_init(struct ure_softc *);
> +int ure_xfer_list_init(struct ure_softc *, struct ure_chain *,
> +uint32_t, int);
> +void ure_xfer_list_free(struct ure_softc *, struct ure_chain *, int);
> 
>  void ure_tick_task(void *);
>  void ure_tick(void *);
> @@ -625,12 +627,36 @@ void
>  ure_watchdog(struct ifnet *ifp)
>  {
>   struct ure_softc *sc = ifp->if_softc;
> + struct ure_chain *c;
> + usbd_status err;
> + int i, s;
> +
> + ifp->if_timer = 0;
> 
>   if (usbd_is_dying(sc->ure_udev))
>   return;
> 
> + if ((ifp->if_flags & (IFF_RUNNING|IFF_UP)) != (IFF_RUNNING|IFF_UP))
> + return;
> +
> + sc = ifp->if_softc;
> + s = splnet();
> +
>   ifp->if_oerrors++;
> - printf("%s: watchdog timeout\n", sc->ure_dev.dv_xname);
> + DPRINTF(("watchdog timeout\n"));
> +
> + for (i = 0; i < URE_TX_LIST_CNT; i++) {
> + c = >ure_cdata.ure_tx_chain[i];
> + if (ml_len(>uc_mbuf_list) > 0) {
> + usbd_get_xfer_status(c->uc_xfer, NULL, NULL, NULL,
> +);
> + ure_txeof(c->uc_xfer, c, err);
> + }
> + }
> +
> + if (ifq_is_oactive(>if_snd))
> + ifq_restart(>if_snd);
> + splx(s);
>  }
> 
>  void
> @@ -653,18 +679,26 @@ ure_init(void *xsc)
>   else
>   ure_rtl8153_nic_reset(sc);
> 
> - if (ure_rx_list_init(sc) == ENOBUFS) {
> + if (ure_xfer_list_init(sc, sc->ure_cdata.ure_rx_chain,
> + sc->ure_rxbufsz, URE_RX_LIST_CNT) == ENOBUFS) {
>   printf("%s: rx list init failed\n", sc->ure_dev.dv_xname);
>   splx(s);
>   return;
>   }
> 
> - if (ure_tx_list_init(sc) == ENOBUFS) {
> + if (ure_xfer_list_init(sc, sc->ure_cdata.ure_tx_chain,
> + sc->ure_txbufsz, URE_TX_LIST_CNT) == ENOBUFS) {
>   printf("%s: tx list init failed\n", sc->ure_dev.dv_xname);
>   splx(s);
>   return;
>   }
> 
> + /* Initialize the SLIST we are using for the multiple tx buffers */
> + SLIST_INIT(>ure_cdata.ure_tx_free);
> + for (i = 0; i < URE_TX_LIST_CNT; i++)
> + SLIST_INSERT_HEAD(>ure_cdata.ure_tx_free,
> + >ure_cdata.ure_tx_chain[i], ure_list);
> +
>   /* Set MAC address. */
>   

Re: Improve ure(4) performance

2020-07-27 Thread Jonathon Fletcher
On Sun, Jul 26, 2020 at 10:12 PM Mikolaj Kucharski
 wrote:
>
> On Sun, Jul 26, 2020 at 06:47:32PM -0700, Jonathon Fletcher wrote:
> > Mikolaj,
> >
> > Thank you for testing my patch.
> >
> > I am very interested to know what xhci (or ehci) hardware you have.
> >
> > I have the following:
> >
> > xhci0 at pci0 dev 20 function 0 "Intel 9 Series xHCI" rev 0x03: msi, xHCI 
> > 1.0
> > usb0 at xhci0: USB revision 3.0
> > uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 
> > 3.00/1.00 addr 1
> > ure0 at uhub0 port 14 configuration 1 interface 0 "Realtek USB 
> > 10/100/1G/2.5G LAN" rev 3.20/30.00 addr 3
> > ure0: RTL8156 (0x7030), address 00:e0:4c:ab:64:5a
> >
> > My ure0 is https://www.amazon.com/gp/product/B07Z8S6PN4 
> > 
> >
> > I do not get any watchdog errors with this.
> >
> > Kevin has been testing my patch and giving me good feedback. He has seen 
> > some watchdog errors with an RTL8153B also.
> >
> > I am starting to suspect that I have the tx xfer size wrong (too big) for 
> > the 8153 / 8153B devices. I am also trying to eliminate the XHCI hardware 
> > as a cause.
> >
> > Please could you post your dmesg? At a minimum it would help me a lot to 
> > see your usb hardware.
> >
>
> Sure, no problem. I'm testing your patch with:
>
> https://www.amazon.co.uk/gp/product/B081YGDBG7/
>

[snip]

> xhci0 at pci0 dev 20 function 0 "Intel 100 Series xHCI" rev 0x21: msi, xHCI 
> 1.0
> usb0 at xhci0: USB revision 3.0
> uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 
> addr 1
> uhub1 at uhub0 port 3 configuration 1 interface 0 "VIA Labs, Inc. USB2.0 Hub" 
> rev 2.10/3.d3 addr 2
> uhub2 at uhub1 port 3 configuration 1 interface 0 "Terminus Technology USB 
> 2.0 Hub" rev 2.00/1.00 addr 3
> ure0 at uhub2 port 2 configuration 1 interface 0 "Realtek USB 10/100/1000 
> LAN" rev 2.10/30.00 addr 4
> ure0: RTL8153 (0x5c30), address 00:e0:4c:04:09:7d
> rgephy0 at ure0 phy 0: RTL8251 PHY, rev. 0

Thanks Mikolaj,

I believe that the intermittent watchdog messages on RTL8153 variants
are now resolved. The previous code defined 32kb buffer sizes for both
tx and rx for RTL8153. The rx buffer size does vary by device type but
the tx buffer size should be 16kb for all types.

The patch improves tx performance primarily by packing multiple
packets into the outgoing xfer buffer if / when this is possible. This
makes it possible to use the entire xfer buffer in a single tx xfer.
If there are enough packets in the outbound queue and the xfer buffer
is defined as larger than the device buffer then the device could be
sent a tx xfer too large for it - eventually resulting in the watchdog
routine getting called.

I have attached an updated patch - which includes Kevin's changes from
his earlier email - that also corrects the tx buffer sizes for RTL8153
/ RTL8153B devices.

Jonathon

Index: sys/dev/usb/if_urereg.h
===
RCS file: /cvs/src/sys/dev/usb/if_urereg.h,v
retrieving revision 1.8
diff -u -p -u -r1.8 if_urereg.h
--- sys/dev/usb/if_urereg.h 7 Dec 2019 08:45:28 - 1.8
+++ sys/dev/usb/if_urereg.h 27 Jul 2020 17:10:09 -
@@ -494,28 +494,32 @@ struct ure_txpkt {
 #define URE_ENDPT_TX 1
 #define URE_ENDPT_MAX 2

-#define URE_TX_LIST_CNT 8
+#define URE_TX_LIST_CNT 1
 #define URE_RX_LIST_CNT 1
-#define URE_RX_BUF_ALIGN sizeof(uint64_t)
+#define URE_TX_BUF_ALIGN 4
+#define URE_RX_BUF_ALIGN 8

-#define URE_TXBUFSZ 16384
-#define URE_8152_RXBUFSZ 16384
-#define URE_8153_RXBUFSZ 32768
+#define URE_8152_TX_BUFSZ 16384
+#define URE_8152_RX_BUFSZ 16384
+
+#define URE_8153_TX_BUFSZ 16384
+#define URE_8153_RX_BUFSZ 32768

 struct ure_chain {
  struct ure_softc *uc_sc;
  struct usbd_xfer *uc_xfer;
  char *uc_buf;
- struct mbuf *uc_mbuf;
- int uc_accum;
- int uc_idx;
+ uint32_t uc_buflen;
+ uint32_t uc_bufmax;
+ struct mbuf_list uc_mbuf_list;
+ SLIST_ENTRY(ure_chain)  ure_list;
+ uint8_t uc_idx;
 };

 struct ure_cdata {
- struct ure_chain tx_chain[URE_TX_LIST_CNT];
- struct ure_chain rx_chain[URE_RX_LIST_CNT];
- int tx_prod;
- int tx_cnt;
+ struct ure_chain ure_rx_chain[URE_RX_LIST_CNT];
+ struct ure_chain ure_tx_chain[URE_TX_LIST_CNT];
+ SLIST_HEAD(ure_list_head, ure_chain)ure_tx_free;
 };

 struct ure_softc {
@@ -541,7 +545,7 @@ struct ure_softc {

  struct timeval ure_rx_notice;
  int ure_rxbufsz;
- int ure_tx_list_cnt;
+ int ure_txbufsz;

  int ure_phyno;

Index: sys/dev/usb/if_ure.c
===
RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
retrieving revision 1.16
diff -u -p -u -r1.16 if_ure.c
--- sys/dev/usb/if_ure.c 10 Jul 2020 13:26:41 - 1.16
+++ sys/dev/usb/if_ure.c 27 Jul 2020 17:10:39 -
@@ -117,11 +117,13 @@ void ure_miibus_writereg(struct device
 void ure_lock_mii(struct ure_softc *);
 void ure_unlock_mii(struct ure_softc *);

-int ure_encap(struct ure_softc *, struct mbuf *);
+int ure_encap_txpkt(struct mbuf *, 

Re: acpicpu(4) and ACPI0007

2020-07-27 Thread Jason McIntyre
On Mon, Jul 27, 2020 at 05:16:47PM +0200, Mark Kettenis wrote:
> > Date: Mon, 27 Jul 2020 17:02:41 +0200 (CEST)
> > From: Mark Kettenis 
> > 
> > Recent ACPI versions have deprecated "Processor()" nodes in favout of
> > "Device()" nodes with a _HID() method that returns "ACPI0007".  This
> > diff tries to support machines with firmware that implements this.  If
> > you see something like:
> > 
> >   "ACPI0007" at acpi0 not configured
> > 
> > please try the following diff and report back with an updated dmesg.
> > 
> > Cheers,
> > 
> > Mark
> 
> And now with the right diff...
> 
> 

hi. i'm not sure if the output is correct, but it does look like the cpu
is adjustable with this:

cpu0: 1996 MHz: speeds: 2000 1700 1400 MHz

this part looks weird:

acpicpu0 at acpi0copyvalue: 6: C3(0@350 io@0x415), C2(0@400 io@0x414), C1(0@1 
mwait), PSS
acpicpu1 at acpi0copyvalue: 6: C3(0@350 io@0x415), C2(0@400 io@0x414), C1(0@1 
mwait), PSS
acpicpu2 at acpi0copyvalue: 6: C3(0@350 io@0x415), C2(0@400 io@0x414), C1(0@1 
mwait), PSS
acpicpu3 at acpi0copyvalue: 6: C3(0@350 io@0x415), C2(0@400 io@0x414), C1(0@1 
mwait), PSS
acpicpu4 at acpi0copyvalue: 6: C3(0@350 io@0x415), C2(0@400 io@0x414), C1(0@1 
mwait), PSS
acpicpu5 at acpi0copyvalue: 6: C3(0@350 io@0x415), C2(0@400 io@0x414), C1(0@1 
mwait), PSS
acpicpu6 at acpi0copyvalue: 6: C3(0@350 io@0x415), C2(0@400 io@0x414), C1(0@1 
mwait), PSS
acpicpu7 at acpi0copyvalue: 6: C3(0@350 io@0x415), C2(0@400 io@0x414), C1(0@1 
mwait), PSS
acpicpu8 at acpi0copyvalue: 6: no cpu matching ACPI ID 8
acpicpu9 at acpi0copyvalue: 6: no cpu matching ACPI ID 9
acpicpu10 at acpi0copyvalue: 6: no cpu matching ACPI ID 10
acpicpu11 at acpi0copyvalue: 6: no cpu matching ACPI ID 11
acpicpu12 at acpi0copyvalue: 6: no cpu matching ACPI ID 12
acpicpu13 at acpi0copyvalue: 6: no cpu matching ACPI ID 13
acpicpu14 at acpi0copyvalue: 6: no cpu matching ACPI ID 14
acpicpu15 at acpi0copyvalue: 6: no cpu matching ACPI ID 15

full dmesg below.
jmc

OpenBSD 6.7-current (GENERIC.MP) #2: Mon Jul 27 16:18:30 BST 2020
jmc@kansas:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 7895654400 (7529MB)
avail mem = 7641284608 (7287MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xca707000 (77 entries)
bios0: vendor Dell Inc. version "1.1.0" date 05/27/2020
bios0: Dell Inc. Inspiron 5505
acpi0 at bios0: ACPI 5.0Undefined scope: \\_SB_.PCI0.LPC0.EC0_

acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP UEFI SSDT IVRS SSDT TPM2 MSDM ASF! BOOT HPET APIC MCFG 
SLIC SSDT WSMT VFCT SSDT SSDT CRAT CDIT SSDT SSDT SSDT SSDT FPDT SSDT SSDT SSDT 
SSDT SSDT SSDT SSDT BGRT
acpi0: wakeup devices GP17(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 7 4700U with Radeon Graphics, 1996.53 MHz, 17-60-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache, 8MB 64b/line disabled L3 cache
cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Ryzen 7 4700U with Radeon Graphics, 1996.25 MHz, 17-60-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache, 8MB 64b/line disabled L3 cache
cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Ryzen 7 4700U with Radeon Graphics, 1996.25 MHz, 17-60-01
cpu2: 

Re: timekeep: fixing large skews on amd64 with RDTSCP

2020-07-27 Thread Mark Kettenis
> Date: Mon, 27 Jul 2020 17:14:21 +0200
> From: Christian Weisgerber 
> 
> Scott Cheloha:
> 
> > --- lib/libc/arch/amd64/gen/usertc.c8 Jul 2020 09:17:48 -   
> > 1.2
> > +++ lib/libc/arch/amd64/gen/usertc.c25 Jul 2020 17:50:38 -
> > @@ -21,9 +21,12 @@
> >  static inline u_int
> >  rdtsc(void)
> >  {
> > -   uint32_t hi, lo;
> > -   asm volatile("rdtsc" : "=a"(lo), "=d"(hi));
> > -   return ((uint64_t)lo)|(((uint64_t)hi)<<32);
> > +   uint32_t lo;
> > +
> > +   asm volatile("lfence");
> > +   asm volatile("rdtsc" : "=a"(lo) : : "rdx");
> 
> Is there a guarantee that two separate asm()s will not be reordered?

I believe that is true for "volatile" asm statements.  But this is all
not very well documented and I believe that the compiler may hoist
bits of C code in between, which is probably not what you want.

Note that since "asm" is non-standard C, we favour spelling it as
"__asm" since that makes the compiler shut up about it even if you
request stricter C standard compliance.

And given the kernel bit nelow...

> > +
> > +   return lo;
> >  }
> >  
> >  static int
> > --- sys/arch/amd64/amd64/tsc.c  6 Jul 2020 13:33:06 -   1.19
> > +++ sys/arch/amd64/amd64/tsc.c  25 Jul 2020 17:50:38 -
> > @@ -211,7 +211,12 @@ cpu_recalibrate_tsc(struct timecounter *
> >  u_int
> >  tsc_get_timecount(struct timecounter *tc)
> >  {
> > -   return rdtsc() + curcpu()->ci_tsc_skew;
> > +   uint32_t lo;
> > +
> > +   asm volatile("lfence");
> > +   asm volatile("rdtsc" : "=a"(lo) : : "rdx");
> > +
> > +   return lo + curcpu()->ci_tsc_skew;
> >  }
> >  
> >  void
> > 
> 
> I'd just do s/rdtsc/rdtsc_lfence/, which would agree well with the
> rest of the file.

Agreed.  And I would really prefer that the libc code stays as close
to the kernel code as possible.



Re: acpicpu(4) and ACPI0007

2020-07-27 Thread Mark Kettenis
> Date: Mon, 27 Jul 2020 11:10:42 -0400
> From: Bryan Steele 
> 
> On Mon, Jul 27, 2020 at 05:02:41PM +0200, Mark Kettenis wrote:
> > Recent ACPI versions have deprecated "Processor()" nodes in favout of
> > "Device()" nodes with a _HID() method that returns "ACPI0007".  This
> > diff tries to support machines with firmware that implements this.  If
> > you see something like:
> > 
> >   "ACPI0007" at acpi0 not configured
> > 
> > please try the following diff and report back with an updated dmesg.
> > 
> > Cheers,
> > 
> > Mark
> > 
> 
> Wrong diff?

Yes, too many diffs that start with acpi...

Thanks,

Mark

> > Index: dev/acpi/acpi.c
> > ===
> > RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> > retrieving revision 1.384
> > diff -u -p -r1.384 acpi.c
> > --- dev/acpi/acpi.c 11 May 2020 17:57:17 -  1.384
> > +++ dev/acpi/acpi.c 13 May 2020 18:44:32 -
> > @@ -72,6 +72,7 @@ int   acpi_debug = 16;
> >  
> >  intacpi_poll_enabled;
> >  intacpi_hasprocfvs;
> > +intacpi_haspci;
> >  
> >  #define ACPIEN_RETRIES 15
> >  
> > Index: dev/acpi/acpivar.h
> > ===
> > RCS file: /cvs/src/sys/dev/acpi/acpivar.h,v
> > retrieving revision 1.108
> > diff -u -p -r1.108 acpivar.h
> > --- dev/acpi/acpivar.h  8 May 2020 11:18:01 -   1.108
> > +++ dev/acpi/acpivar.h  13 May 2020 18:44:32 -
> > @@ -43,6 +43,7 @@ extern int acpi_debug;
> >  #endif
> >  
> >  extern int acpi_hasprocfvs;
> > +extern int acpi_haspci;
> >  
> >  struct klist;
> >  struct acpiec_softc;
> > Index: arch/amd64/amd64/mainbus.c
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/amd64/mainbus.c,v
> > retrieving revision 1.49
> > diff -u -p -r1.49 mainbus.c
> > --- arch/amd64/amd64/mainbus.c  7 Sep 2019 13:46:19 -   1.49
> > +++ arch/amd64/amd64/mainbus.c  13 May 2020 18:44:32 -
> > @@ -231,6 +231,13 @@ mainbus_attach(struct device *parent, st
> >  #endif
> >  
> >  #if NPCI > 0
> > +#if NACPI > 0
> > +   if (acpi_haspci) {
> > +   extern void acpipci_attach_busses(struct device *);
> > +
> > +   acpipci_attach_busses(self);
> > +   } else
> > +#endif
> > {
> > pci_init_extents();
> >  
> > @@ -245,9 +252,6 @@ mainbus_attach(struct device *parent, st
> > mba.mba_pba.pba_domain = pci_ndomains++;
> > mba.mba_pba.pba_bus = 0;
> > config_found(self, _pba, mainbus_print);
> > -#if NACPI > 0
> > -   acpi_pciroots_attach(self, _pba, mainbus_print);
> > -#endif
> > }
> >  #endif
> >  
> > Index: arch/amd64/conf/RAMDISK
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK,v
> > retrieving revision 1.77
> > diff -u -p -r1.77 RAMDISK
> > --- arch/amd64/conf/RAMDISK 5 Mar 2020 16:36:30 -   1.77
> > +++ arch/amd64/conf/RAMDISK 13 May 2020 18:44:32 -
> > @@ -30,6 +30,7 @@ acpi0 at bios?
> >  #acpicpu*  at acpi?
> >  acpicmos*  at acpi?
> >  acpiec*at acpi?
> > +acpipci*   at acpi?
> >  acpiprt*   at acpi?
> >  acpimadt0  at acpi?
> >  #acpitz*   at acpi?
> > Index: arch/amd64/conf/RAMDISK_CD
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK_CD,v
> > retrieving revision 1.188
> > diff -u -p -r1.188 RAMDISK_CD
> > --- arch/amd64/conf/RAMDISK_CD  15 Feb 2020 08:49:11 -  1.188
> > +++ arch/amd64/conf/RAMDISK_CD  13 May 2020 18:44:32 -
> > @@ -37,6 +37,7 @@ acpi0 at bios?
> >  #acpicpu*  at acpi?
> >  acpicmos*  at acpi?
> >  acpiec*at acpi?
> > +acpipci*   at acpi?
> >  acpiprt*   at acpi?
> >  acpimadt0  at acpi?
> >  #acpitz*   at acpi?
> > Index: arch/amd64/pci/acpipci.c
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/pci/acpipci.c,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 acpipci.c
> > --- arch/amd64/pci/acpipci.c7 Sep 2019 13:46:19 -   1.3
> > +++ arch/amd64/pci/acpipci.c13 May 2020 18:44:32 -
> > @@ -53,6 +53,19 @@ struct acpipci_softc {
> > struct device   sc_dev;
> > struct acpi_softc *sc_acpi;
> > struct aml_node *sc_node;
> > +
> > +   bus_space_tag_t sc_iot;
> > +   bus_space_tag_t sc_memt;
> > +   bus_dma_tag_t   sc_dmat;
> > +
> > +   struct extent   *sc_busex;
> > +   struct extent   *sc_memex;
> > +   struct extent   *sc_ioex;
> > +   charsc_busex_name[32];
> > +   charsc_ioex_name[32];
> > +   charsc_memex_name[32];
> > +   int sc_bus;
> > +   uint32_tsc_seg;
> >  };
> >  
> >  intacpipci_match(struct device *, void *, void *);
> > @@ -72,6 +85,11 @@ const char *acpipci_hids[] = {
> > NULL
> >  };
> >  
> > +void   

Re: acpicpu(4) and ACPI0007

2020-07-27 Thread Mark Kettenis
> Date: Mon, 27 Jul 2020 17:02:41 +0200 (CEST)
> From: Mark Kettenis 
> 
> Recent ACPI versions have deprecated "Processor()" nodes in favout of
> "Device()" nodes with a _HID() method that returns "ACPI0007".  This
> diff tries to support machines with firmware that implements this.  If
> you see something like:
> 
>   "ACPI0007" at acpi0 not configured
> 
> please try the following diff and report back with an updated dmesg.
> 
> Cheers,
> 
> Mark

And now with the right diff...


Index: dev/acpi/acpicpu.c
===
RCS file: /cvs/src/sys/dev/acpi/acpicpu.c,v
retrieving revision 1.85
diff -u -p -r1.85 acpicpu.c
--- dev/acpi/acpicpu.c  27 May 2020 05:02:21 -  1.85
+++ dev/acpi/acpicpu.c  27 Jul 2020 14:58:38 -
@@ -186,6 +186,11 @@ struct cfdriver acpicpu_cd = {
NULL, "acpicpu", DV_DULL
 };
 
+const char *acpicpu_hids[] = {
+   "ACPI0007",
+   NULL
+};
+
 extern int setperf_prio;
 
 struct acpicpu_softc *acpicpu_sc[MAXCPUS];
@@ -650,6 +655,9 @@ acpicpu_match(struct device *parent, voi
struct acpi_attach_args *aa = aux;
struct cfdata   *cf = match;
 
+   if (acpi_matchhids(aa, acpicpu_hids, cf->cf_driver->cd_name))
+   return (1);
+
/* sanity */
if (aa->aaa_name == NULL ||
strcmp(aa->aaa_name, cf->cf_driver->cd_name) != 0 ||
@@ -665,6 +673,7 @@ acpicpu_attach(struct device *parent, st
struct acpicpu_softc*sc = (struct acpicpu_softc *)self;
struct acpi_attach_args *aa = aux;
struct aml_valueres;
+   int64_t uid;
int i;
uint32_tstatus = 0;
CPU_INFO_ITERATOR   cii;
@@ -675,6 +684,10 @@ acpicpu_attach(struct device *parent, st
acpicpu_sc[sc->sc_dev.dv_unit] = sc;
 
SLIST_INIT(>sc_cstates);
+
+   if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode,
+   "_UID", 0, NULL, ) == 0)
+   sc->sc_cpu = uid;
 
if (aml_evalnode(sc->sc_acpi, sc->sc_devnode, 0, NULL, ) == 0) {
if (res.type == AML_OBJTYPE_PROCESSOR) {



Re: timekeep: fixing large skews on amd64 with RDTSCP

2020-07-27 Thread Christian Weisgerber
Scott Cheloha:

> --- lib/libc/arch/amd64/gen/usertc.c  8 Jul 2020 09:17:48 -   1.2
> +++ lib/libc/arch/amd64/gen/usertc.c  25 Jul 2020 17:50:38 -
> @@ -21,9 +21,12 @@
>  static inline u_int
>  rdtsc(void)
>  {
> - uint32_t hi, lo;
> - asm volatile("rdtsc" : "=a"(lo), "=d"(hi));
> - return ((uint64_t)lo)|(((uint64_t)hi)<<32);
> + uint32_t lo;
> +
> + asm volatile("lfence");
> + asm volatile("rdtsc" : "=a"(lo) : : "rdx");

Is there a guarantee that two separate asm()s will not be reordered?

> +
> + return lo;
>  }
>  
>  static int
> --- sys/arch/amd64/amd64/tsc.c6 Jul 2020 13:33:06 -   1.19
> +++ sys/arch/amd64/amd64/tsc.c25 Jul 2020 17:50:38 -
> @@ -211,7 +211,12 @@ cpu_recalibrate_tsc(struct timecounter *
>  u_int
>  tsc_get_timecount(struct timecounter *tc)
>  {
> - return rdtsc() + curcpu()->ci_tsc_skew;
> + uint32_t lo;
> +
> + asm volatile("lfence");
> + asm volatile("rdtsc" : "=a"(lo) : : "rdx");
> +
> + return lo + curcpu()->ci_tsc_skew;
>  }
>  
>  void
> 

I'd just do s/rdtsc/rdtsc_lfence/, which would agree well with the
rest of the file.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de



Re: acpicpu(4) and ACPI0007

2020-07-27 Thread Bryan Steele
On Mon, Jul 27, 2020 at 05:02:41PM +0200, Mark Kettenis wrote:
> Recent ACPI versions have deprecated "Processor()" nodes in favout of
> "Device()" nodes with a _HID() method that returns "ACPI0007".  This
> diff tries to support machines with firmware that implements this.  If
> you see something like:
> 
>   "ACPI0007" at acpi0 not configured
> 
> please try the following diff and report back with an updated dmesg.
> 
> Cheers,
> 
> Mark
> 

Wrong diff?

> 
> Index: dev/acpi/acpi.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> retrieving revision 1.384
> diff -u -p -r1.384 acpi.c
> --- dev/acpi/acpi.c   11 May 2020 17:57:17 -  1.384
> +++ dev/acpi/acpi.c   13 May 2020 18:44:32 -
> @@ -72,6 +72,7 @@ int acpi_debug = 16;
>  
>  int  acpi_poll_enabled;
>  int  acpi_hasprocfvs;
> +int  acpi_haspci;
>  
>  #define ACPIEN_RETRIES 15
>  
> Index: dev/acpi/acpivar.h
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpivar.h,v
> retrieving revision 1.108
> diff -u -p -r1.108 acpivar.h
> --- dev/acpi/acpivar.h8 May 2020 11:18:01 -   1.108
> +++ dev/acpi/acpivar.h13 May 2020 18:44:32 -
> @@ -43,6 +43,7 @@ extern int acpi_debug;
>  #endif
>  
>  extern int acpi_hasprocfvs;
> +extern int acpi_haspci;
>  
>  struct klist;
>  struct acpiec_softc;
> Index: arch/amd64/amd64/mainbus.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/mainbus.c,v
> retrieving revision 1.49
> diff -u -p -r1.49 mainbus.c
> --- arch/amd64/amd64/mainbus.c7 Sep 2019 13:46:19 -   1.49
> +++ arch/amd64/amd64/mainbus.c13 May 2020 18:44:32 -
> @@ -231,6 +231,13 @@ mainbus_attach(struct device *parent, st
>  #endif
>  
>  #if NPCI > 0
> +#if NACPI > 0
> + if (acpi_haspci) {
> + extern void acpipci_attach_busses(struct device *);
> +
> + acpipci_attach_busses(self);
> + } else
> +#endif
>   {
>   pci_init_extents();
>  
> @@ -245,9 +252,6 @@ mainbus_attach(struct device *parent, st
>   mba.mba_pba.pba_domain = pci_ndomains++;
>   mba.mba_pba.pba_bus = 0;
>   config_found(self, _pba, mainbus_print);
> -#if NACPI > 0
> - acpi_pciroots_attach(self, _pba, mainbus_print);
> -#endif
>   }
>  #endif
>  
> Index: arch/amd64/conf/RAMDISK
> ===
> RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK,v
> retrieving revision 1.77
> diff -u -p -r1.77 RAMDISK
> --- arch/amd64/conf/RAMDISK   5 Mar 2020 16:36:30 -   1.77
> +++ arch/amd64/conf/RAMDISK   13 May 2020 18:44:32 -
> @@ -30,6 +30,7 @@ acpi0   at bios?
>  #acpicpu*at acpi?
>  acpicmos*at acpi?
>  acpiec*  at acpi?
> +acpipci* at acpi?
>  acpiprt* at acpi?
>  acpimadt0at acpi?
>  #acpitz* at acpi?
> Index: arch/amd64/conf/RAMDISK_CD
> ===
> RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK_CD,v
> retrieving revision 1.188
> diff -u -p -r1.188 RAMDISK_CD
> --- arch/amd64/conf/RAMDISK_CD15 Feb 2020 08:49:11 -  1.188
> +++ arch/amd64/conf/RAMDISK_CD13 May 2020 18:44:32 -
> @@ -37,6 +37,7 @@ acpi0   at bios?
>  #acpicpu*at acpi?
>  acpicmos*at acpi?
>  acpiec*  at acpi?
> +acpipci* at acpi?
>  acpiprt* at acpi?
>  acpimadt0at acpi?
>  #acpitz* at acpi?
> Index: arch/amd64/pci/acpipci.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/pci/acpipci.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 acpipci.c
> --- arch/amd64/pci/acpipci.c  7 Sep 2019 13:46:19 -   1.3
> +++ arch/amd64/pci/acpipci.c  13 May 2020 18:44:32 -
> @@ -53,6 +53,19 @@ struct acpipci_softc {
>   struct device   sc_dev;
>   struct acpi_softc *sc_acpi;
>   struct aml_node *sc_node;
> +
> + bus_space_tag_t sc_iot;
> + bus_space_tag_t sc_memt;
> + bus_dma_tag_t   sc_dmat;
> +
> + struct extent   *sc_busex;
> + struct extent   *sc_memex;
> + struct extent   *sc_ioex;
> + charsc_busex_name[32];
> + charsc_ioex_name[32];
> + charsc_memex_name[32];
> + int sc_bus;
> + uint32_tsc_seg;
>  };
>  
>  int  acpipci_match(struct device *, void *, void *);
> @@ -72,6 +85,11 @@ const char *acpipci_hids[] = {
>   NULL
>  };
>  
> +void acpipci_attach_deferred(struct device *);
> +int  acpipci_print(void *, const char *);
> +int  acpipci_parse_resources(int, union acpi_resource *, void *);
> +void acpipci_osc(struct acpipci_softc *);
> +
>  int
>  acpipci_match(struct device *parent, void *match, void *aux)
>  {
> @@ -86,15 +104,225 @@ acpipci_attach(struct device *parent, st
>  {
>   

acpicpu(4) and ACPI0007

2020-07-27 Thread Mark Kettenis
Recent ACPI versions have deprecated "Processor()" nodes in favout of
"Device()" nodes with a _HID() method that returns "ACPI0007".  This
diff tries to support machines with firmware that implements this.  If
you see something like:

  "ACPI0007" at acpi0 not configured

please try the following diff and report back with an updated dmesg.

Cheers,

Mark



Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.384
diff -u -p -r1.384 acpi.c
--- dev/acpi/acpi.c 11 May 2020 17:57:17 -  1.384
+++ dev/acpi/acpi.c 13 May 2020 18:44:32 -
@@ -72,6 +72,7 @@ int   acpi_debug = 16;
 
 intacpi_poll_enabled;
 intacpi_hasprocfvs;
+intacpi_haspci;
 
 #define ACPIEN_RETRIES 15
 
Index: dev/acpi/acpivar.h
===
RCS file: /cvs/src/sys/dev/acpi/acpivar.h,v
retrieving revision 1.108
diff -u -p -r1.108 acpivar.h
--- dev/acpi/acpivar.h  8 May 2020 11:18:01 -   1.108
+++ dev/acpi/acpivar.h  13 May 2020 18:44:32 -
@@ -43,6 +43,7 @@ extern int acpi_debug;
 #endif
 
 extern int acpi_hasprocfvs;
+extern int acpi_haspci;
 
 struct klist;
 struct acpiec_softc;
Index: arch/amd64/amd64/mainbus.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/mainbus.c,v
retrieving revision 1.49
diff -u -p -r1.49 mainbus.c
--- arch/amd64/amd64/mainbus.c  7 Sep 2019 13:46:19 -   1.49
+++ arch/amd64/amd64/mainbus.c  13 May 2020 18:44:32 -
@@ -231,6 +231,13 @@ mainbus_attach(struct device *parent, st
 #endif
 
 #if NPCI > 0
+#if NACPI > 0
+   if (acpi_haspci) {
+   extern void acpipci_attach_busses(struct device *);
+
+   acpipci_attach_busses(self);
+   } else
+#endif
{
pci_init_extents();
 
@@ -245,9 +252,6 @@ mainbus_attach(struct device *parent, st
mba.mba_pba.pba_domain = pci_ndomains++;
mba.mba_pba.pba_bus = 0;
config_found(self, _pba, mainbus_print);
-#if NACPI > 0
-   acpi_pciroots_attach(self, _pba, mainbus_print);
-#endif
}
 #endif
 
Index: arch/amd64/conf/RAMDISK
===
RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK,v
retrieving revision 1.77
diff -u -p -r1.77 RAMDISK
--- arch/amd64/conf/RAMDISK 5 Mar 2020 16:36:30 -   1.77
+++ arch/amd64/conf/RAMDISK 13 May 2020 18:44:32 -
@@ -30,6 +30,7 @@ acpi0 at bios?
 #acpicpu*  at acpi?
 acpicmos*  at acpi?
 acpiec*at acpi?
+acpipci*   at acpi?
 acpiprt*   at acpi?
 acpimadt0  at acpi?
 #acpitz*   at acpi?
Index: arch/amd64/conf/RAMDISK_CD
===
RCS file: /cvs/src/sys/arch/amd64/conf/RAMDISK_CD,v
retrieving revision 1.188
diff -u -p -r1.188 RAMDISK_CD
--- arch/amd64/conf/RAMDISK_CD  15 Feb 2020 08:49:11 -  1.188
+++ arch/amd64/conf/RAMDISK_CD  13 May 2020 18:44:32 -
@@ -37,6 +37,7 @@ acpi0 at bios?
 #acpicpu*  at acpi?
 acpicmos*  at acpi?
 acpiec*at acpi?
+acpipci*   at acpi?
 acpiprt*   at acpi?
 acpimadt0  at acpi?
 #acpitz*   at acpi?
Index: arch/amd64/pci/acpipci.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/acpipci.c,v
retrieving revision 1.3
diff -u -p -r1.3 acpipci.c
--- arch/amd64/pci/acpipci.c7 Sep 2019 13:46:19 -   1.3
+++ arch/amd64/pci/acpipci.c13 May 2020 18:44:32 -
@@ -53,6 +53,19 @@ struct acpipci_softc {
struct device   sc_dev;
struct acpi_softc *sc_acpi;
struct aml_node *sc_node;
+
+   bus_space_tag_t sc_iot;
+   bus_space_tag_t sc_memt;
+   bus_dma_tag_t   sc_dmat;
+
+   struct extent   *sc_busex;
+   struct extent   *sc_memex;
+   struct extent   *sc_ioex;
+   charsc_busex_name[32];
+   charsc_ioex_name[32];
+   charsc_memex_name[32];
+   int sc_bus;
+   uint32_tsc_seg;
 };
 
 intacpipci_match(struct device *, void *, void *);
@@ -72,6 +85,11 @@ const char *acpipci_hids[] = {
NULL
 };
 
+void   acpipci_attach_deferred(struct device *);
+intacpipci_print(void *, const char *);
+intacpipci_parse_resources(int, union acpi_resource *, void *);
+void   acpipci_osc(struct acpipci_softc *);
+
 int
 acpipci_match(struct device *parent, void *match, void *aux)
 {
@@ -86,15 +104,225 @@ acpipci_attach(struct device *parent, st
 {
struct acpi_attach_args *aaa = aux;
struct acpipci_softc *sc = (struct acpipci_softc *)self;
-   struct aml_value args[4];
struct aml_value res;
-   static uint8_t uuid[16] = ACPI_PCI_UUID;
-   uint32_t buf[3];
+   uint64_t bbn = 0;
+   uint64_t seg = 0;
+
+