Re: 6.8-current ifconfig umb0 and Device not configured
A question below..
On Wed, Feb 03, 2021 at 11:22:16AM +, Mikolaj Kucharski wrote:
> On Wed, Feb 03, 2021 at 11:10:45AM +, Edd Barrett wrote:
> > Hi,
> >
> > CCing ratchov@ and kettenis@ with some context.
> >
> > In short: my change broke ugen, which expects to scan up the interface
> > range until an interface doesn't exist.
> >
> > On Wed, Feb 03, 2021 at 06:25:48AM +0100, Marcus Glocker wrote:
> > >
> > > Index: dev/usb/usbdi.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
> > > retrieving revision 1.109
> > > diff -u -p -u -p -r1.109 usbdi.c
> > > --- dev/usb/usbdi.c 1 Feb 2021 09:21:51 - 1.109
> > > +++ dev/usb/usbdi.c 2 Feb 2021 06:07:41 -
> > > @@ -642,6 +642,10 @@ usbd_device2interface_handle(struct usbd
> > >
> > > if (dev->cdesc == NULL)
> > > return (USBD_NOT_CONFIGURED);
> > > + if (ifaceno < dev->cdesc->bNumInterfaces) {
> > > + *iface = >ifaces[ifaceno];
> > > + return (USBD_NORMAL_COMPLETION);
> > > + }
> > > /*
> > > * The correct interface should be at dev->ifaces[ifaceno], but
> > > we've
> > > * seen non-compliant devices in the wild which present
> > > non-contiguous
> > >
> > > So OK if I commit this fix Edd, Stuart?
> >
> > I'm OK with it as a quick-fix. At least it will make both of the devices
> > in question work.
> >
> > But in the long run, it's not hard to imagine other non-compliant
> > devices which would still be defeated by this code.
> >
> > Suppose a device presents its contiguous interfaces in reverse order, e.g.:
> > [2, 1, 0]. Now suppose a device driver asks for interface 2. We will
> > find interface 0, as we never check if it's the right interface and we
> > never reach the part of the code that scans the array.
> >
> > In other words, just because an index exists, doesn't mean it's the right
> > interface.
> >
> > I think (and I'm not much of a kernel hacker, so I reserve the right be
> > wrong)
> > the correct solution is to:
> >
> > * always loop over the array looking for the right interface.
> > * change ugen, so that it's scanning resilient to gaps in interface range.
> >
I would probably ask, what is the meaning of ifaceno?
Is that variable an index in the array or is it bInterfaceNumber?
>From my understanding, with -r1.110 of usbdi.c it's both. From this
email thread, in various devices array index and bInterfaceNumber
don't always have the same value. They don't always match.
What users of usbd_device2interface_handle() function assume,
an array index or bInterfaceNumber for ifaceno argument?
> Not sure is your above proposition enough. Here is part of dmesg with
> some debugging statments for 2 devices which trigger
> usbd_device2interface_handle()
>
> See MMM markers.
>
> ...
> ulpt0 at uhub0 port 3 configuration 1 interface 1 "Samsung Electronics Co.,
> Ltd. M2070 Series" rev 2.00/1.00 addr 2
> ulpt0: using bi-directional mode
> ugen0 at uhub0 port 3 configuration 1 "Samsung Electronics Co., Ltd. M2070
> Series" rev 2.00/1.00 addr 2
> MMM: USBD_NORMAL_COMPLETION v1 ifaceno=0 bNumInterfaces=2
> [usbd_device2interface_handle()|usbdi.c|649]
> uhub2 at uhub1 port 1 configuration 1 interface 0 "Advanced Micro Devices
> Hub" rev 2.00/0.18 addr 2
> umb0 at uhub2 port 3 configuration 1 interface 12 "Sierra Wireless,
> Incorporated Sierra Wireless MC7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
> 2.00/0.06 addr 3
> ugen1 at uhub2 port 3 configuration 1 "Sierra Wireless, Incorporated Sierra
> Wireless MC7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev 2.00/0.06 addr 3
> MMM: USBD_NORMAL_COMPLETION v1 ifaceno=0 bNumInterfaces=5
> [usbd_device2interface_handle()|usbdi.c|649]
> MMM: USBD_NORMAL_COMPLETION v1 ifaceno=1 bNumInterfaces=5
> [usbd_device2interface_handle()|usbdi.c|649]
> MMM: USBD_NORMAL_COMPLETION v1 ifaceno=2 bNumInterfaces=5
> [usbd_device2interface_handle()|usbdi.c|649]
> vscsi0 at root
> scsibus2 at vscsi0: 256 targets
> ...
>
> For ugen1 (belongs to physical device, whih also attaches a umb(4)) we
> can see that ifaceno has value of 0, 1, 2, but from lsusb we see that:
>
> (from earliers Marcus Glocker's email)
>
> Index Interface Number
> - ---
> 0 0
> 1 2
> 2 3
> 3 12
> 4 13
>
> for ifaceno 1 and 2 it will not equal to bInterfaceNumber if we iterate
> the for (idx = 0; idx < dev->cdesc->bNumInterfaces; idx++) loop.
>
> I don't have good picture for how all the functions work with each
> other, but it does feel like substantial work is needed here, to piece
> everything together.
>
--
Regards,
Mikolaj
Re: 6.8-current ifconfig umb0 and Device not configured
> Date: Wed, 3 Feb 2021 12:51:02 +0100 > From: Marcus Glocker > > On Wed, 3 Feb 2021 11:41:17 + > Edd Barrett wrote: > > > On Wed, Feb 03, 2021 at 11:17:01AM +, Stuart Henderson wrote: > > > btw the problem was seen with umb, it's not just ugen. > > > > From mglocker@'s explanation, I understood that it is the ugen driver > > trying to attach to some part of the device that in turn hoses umb for > > the same device? > > > > Maybe I misunderstood. > > That's right. ugen(4) tries to attach to another umb(4) interface, > then fails, and labels the whole umb(4) device dying. I don't know if > all umb(4) devices show this behaviour (I don't have such a device). > But the other thing I was thinking about is whether we should make > umb(4) attach to this other interface as well to prevent ugen(4) to > take control. Probably not. The umb0 in my x1 for example shows up as: umb0 at uhub0 port 4 configuration 1 interface 0 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" rev 2.00/17.29 addr 2 umodem0 at uhub0 port 4 configuration 1 interface 2 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" rev 2.00/17.29 addr 2 umodem0: data interface 3, has no CM over data, has break umodem0: status change notification available ucom0 at umodem0 And that ucom0 is useful to interact with the modem using AT commands. That is how you interact with the GNSS module for example. So probably ugen(4) should be changed such that it doesn't label the whole device as unusable if somehow attaching to a specific interface fails.
Re: 6.8-current ifconfig umb0 and Device not configured
Hello Gerhard, On Wed, 3 Feb 2021 13:20:19 +0100 Gerhard Roth wrote: > On 2/3/21 12:51 PM, Marcus Glocker wrote: > > On Wed, 3 Feb 2021 11:41:17 + > > Edd Barrett wrote: > > > >> On Wed, Feb 03, 2021 at 11:17:01AM +, Stuart Henderson wrote: > >>> btw the problem was seen with umb, it's not just ugen. > >> > >> From mglocker@'s explanation, I understood that it is the ugen > >> driver trying to attach to some part of the device that in turn > >> hoses umb for the same device? > >> > >> Maybe I misunderstood. > > > > That's right. ugen(4) tries to attach to another umb(4) interface, > > then fails, and labels the whole umb(4) device dying. I don't know > > if all umb(4) devices show this behaviour (I don't have such a > > device). But the other thing I was thinking about is whether we > > should make umb(4) attach to this other interface as well to > > prevent ugen(4) to take control. > > I don't think that's a good idea. Sierra Wireless devices have an > "USB composite" (USBCOMP) where the user can select between several > modes. And each mode is a different composition of USB devices. > E.g. mode 8 gives you four different interfaces: > > - DM (Device Management) > - NMEA (GPS Services) > - AT (AT Commands) > - MBIM > > While mode 9 is MBIM only. So depending upon the USBCOMP selection, > the devices will offer completely different interfaces. > > If umb would claim all interfaces, the other features become unusable. > And esp. AT commands can be very useful and allow to do things that > are not possible via MBIM. > > > If the additional interfaces are a problem, umb(4) could switch > Sierra Wireless modems into MBIM-only mode with QMI-over-MBIM > commands. But since the USBCOMP setting is persistent, that could > confuse dual-boot systems. OK. That's a quite a helpful update. I'm not so familiar with the umb(4) specifics. Then at least this clarifies that the current behaviour is fine. Since we have now fixed the umb(4) problem with the last usbdi.c commit I think we just keep it as is.
Re: 6.8-current ifconfig umb0 and Device not configured
On 2/3/21 12:51 PM, Marcus Glocker wrote: On Wed, 3 Feb 2021 11:41:17 + Edd Barrett wrote: On Wed, Feb 03, 2021 at 11:17:01AM +, Stuart Henderson wrote: btw the problem was seen with umb, it's not just ugen. From mglocker@'s explanation, I understood that it is the ugen driver trying to attach to some part of the device that in turn hoses umb for the same device? Maybe I misunderstood. That's right. ugen(4) tries to attach to another umb(4) interface, then fails, and labels the whole umb(4) device dying. I don't know if all umb(4) devices show this behaviour (I don't have such a device). But the other thing I was thinking about is whether we should make umb(4) attach to this other interface as well to prevent ugen(4) to take control. I don't think that's a good idea. Sierra Wireless devices have an "USB composite" (USBCOMP) where the user can select between several modes. And each mode is a different composition of USB devices. E.g. mode 8 gives you four different interfaces: - DM (Device Management) - NMEA (GPS Services) - AT (AT Commands) - MBIM While mode 9 is MBIM only. So depending upon the USBCOMP selection, the devices will offer completely different interfaces. If umb would claim all interfaces, the other features become unusable. And esp. AT commands can be very useful and allow to do things that are not possible via MBIM. If the additional interfaces are a problem, umb(4) could switch Sierra Wireless modems into MBIM-only mode with QMI-over-MBIM commands. But since the USBCOMP setting is persistent, that could confuse dual-boot systems. Gerhard At some point you just have to say "this device is broken crap, send it back or ebay it and buy an alternative". This is much easier for some classes of device where there are many alternatives (like audio interfaces) than mobile broadband where it's still very difficult to find something suitable with the correct physical interface. Yes, I'm starting to lean in this direction too. The only other solution would be to have some kind of quirks system, but I don't think that'd be perfect either: I bet some (different) devices share vendor and device IDs... Well. I think there are a lot of USB device with all kind of non-compliant USB configurations. That's why I personally think spending too much efforts here, trying to make the right thing, isn't worth it. You will fix something, and then break something else IMO. I would rather focus on getting as much devices possible supported without breaking others. Just as we did now :-)
Re: 6.8-current ifconfig umb0 and Device not configured
On Wed, 3 Feb 2021 11:41:17 + Edd Barrett wrote: > On Wed, Feb 03, 2021 at 11:17:01AM +, Stuart Henderson wrote: > > btw the problem was seen with umb, it's not just ugen. > > From mglocker@'s explanation, I understood that it is the ugen driver > trying to attach to some part of the device that in turn hoses umb for > the same device? > > Maybe I misunderstood. That's right. ugen(4) tries to attach to another umb(4) interface, then fails, and labels the whole umb(4) device dying. I don't know if all umb(4) devices show this behaviour (I don't have such a device). But the other thing I was thinking about is whether we should make umb(4) attach to this other interface as well to prevent ugen(4) to take control. > > At some point you just have to say "this device is broken crap, send > > it back or ebay it and buy an alternative". This is much easier for > > some classes of device where there are many alternatives (like > > audio interfaces) than mobile broadband where it's still very > > difficult to find something suitable with the correct physical > > interface. > > Yes, I'm starting to lean in this direction too. > > The only other solution would be to have some kind of quirks system, > but I don't think that'd be perfect either: I bet some (different) > devices share vendor and device IDs... Well. I think there are a lot of USB device with all kind of non-compliant USB configurations. That's why I personally think spending too much efforts here, trying to make the right thing, isn't worth it. You will fix something, and then break something else IMO. I would rather focus on getting as much devices possible supported without breaking others. Just as we did now :-)
Re: 6.8-current ifconfig umb0 and Device not configured
On Wed, Feb 03, 2021 at 11:17:01AM +, Stuart Henderson wrote: > btw the problem was seen with umb, it's not just ugen. >From mglocker@'s explanation, I understood that it is the ugen driver trying to attach to some part of the device that in turn hoses umb for the same device? Maybe I misunderstood. > At some point you just have to say "this device is broken crap, send > it back or ebay it and buy an alternative". This is much easier for some > classes of device where there are many alternatives (like audio interfaces) > than mobile broadband where it's still very difficult to find something > suitable with the correct physical interface. Yes, I'm starting to lean in this direction too. The only other solution would be to have some kind of quirks system, but I don't think that'd be perfect either: I bet some (different) devices share vendor and device IDs... -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: 6.8-current ifconfig umb0 and Device not configured
On Wed, Feb 03, 2021 at 11:10:45AM +, Edd Barrett wrote:
> Hi,
>
> CCing ratchov@ and kettenis@ with some context.
>
> In short: my change broke ugen, which expects to scan up the interface
> range until an interface doesn't exist.
>
> On Wed, Feb 03, 2021 at 06:25:48AM +0100, Marcus Glocker wrote:
> >
> > Index: dev/usb/usbdi.c
> > ===
> > RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
> > retrieving revision 1.109
> > diff -u -p -u -p -r1.109 usbdi.c
> > --- dev/usb/usbdi.c 1 Feb 2021 09:21:51 - 1.109
> > +++ dev/usb/usbdi.c 2 Feb 2021 06:07:41 -
> > @@ -642,6 +642,10 @@ usbd_device2interface_handle(struct usbd
> >
> > if (dev->cdesc == NULL)
> > return (USBD_NOT_CONFIGURED);
> > + if (ifaceno < dev->cdesc->bNumInterfaces) {
> > + *iface = >ifaces[ifaceno];
> > + return (USBD_NORMAL_COMPLETION);
> > + }
> > /*
> > * The correct interface should be at dev->ifaces[ifaceno], but
> > we've
> > * seen non-compliant devices in the wild which present
> > non-contiguous
> >
> > So OK if I commit this fix Edd, Stuart?
>
> I'm OK with it as a quick-fix. At least it will make both of the devices
> in question work.
>
> But in the long run, it's not hard to imagine other non-compliant
> devices which would still be defeated by this code.
>
> Suppose a device presents its contiguous interfaces in reverse order, e.g.:
> [2, 1, 0]. Now suppose a device driver asks for interface 2. We will
> find interface 0, as we never check if it's the right interface and we
> never reach the part of the code that scans the array.
>
> In other words, just because an index exists, doesn't mean it's the right
> interface.
>
> I think (and I'm not much of a kernel hacker, so I reserve the right be wrong)
> the correct solution is to:
>
> * always loop over the array looking for the right interface.
> * change ugen, so that it's scanning resilient to gaps in interface range.
>
Not sure is your above proposition enough. Here is part of dmesg with
some debugging statments for 2 devices which trigger
usbd_device2interface_handle()
See MMM markers.
...
ulpt0 at uhub0 port 3 configuration 1 interface 1 "Samsung Electronics Co.,
Ltd. M2070 Series" rev 2.00/1.00 addr 2
ulpt0: using bi-directional mode
ugen0 at uhub0 port 3 configuration 1 "Samsung Electronics Co., Ltd. M2070
Series" rev 2.00/1.00 addr 2
MMM: USBD_NORMAL_COMPLETION v1 ifaceno=0 bNumInterfaces=2
[usbd_device2interface_handle()|usbdi.c|649]
uhub2 at uhub1 port 1 configuration 1 interface 0 "Advanced Micro Devices Hub"
rev 2.00/0.18 addr 2
umb0 at uhub2 port 3 configuration 1 interface 12 "Sierra Wireless,
Incorporated Sierra Wireless MC7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
2.00/0.06 addr 3
ugen1 at uhub2 port 3 configuration 1 "Sierra Wireless, Incorporated Sierra
Wireless MC7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev 2.00/0.06 addr 3
MMM: USBD_NORMAL_COMPLETION v1 ifaceno=0 bNumInterfaces=5
[usbd_device2interface_handle()|usbdi.c|649]
MMM: USBD_NORMAL_COMPLETION v1 ifaceno=1 bNumInterfaces=5
[usbd_device2interface_handle()|usbdi.c|649]
MMM: USBD_NORMAL_COMPLETION v1 ifaceno=2 bNumInterfaces=5
[usbd_device2interface_handle()|usbdi.c|649]
vscsi0 at root
scsibus2 at vscsi0: 256 targets
...
For ugen1 (belongs to physical device, whih also attaches a umb(4)) we
can see that ifaceno has value of 0, 1, 2, but from lsusb we see that:
(from earliers Marcus Glocker's email)
Index Interface Number
- ---
0 0
1 2
2 3
3 12
4 13
for ifaceno 1 and 2 it will not equal to bInterfaceNumber if we iterate
the for (idx = 0; idx < dev->cdesc->bNumInterfaces; idx++) loop.
I don't have good picture for how all the functions work with each
other, but it does feel like substantial work is needed here, to piece
everything together.
--
Regards,
Mikolaj
Re: 6.8-current ifconfig umb0 and Device not configured
On 2021/02/03 11:10, Edd Barrett wrote:
> Hi,
>
> CCing ratchov@ and kettenis@ with some context.
>
> In short: my change broke ugen, which expects to scan up the interface
> range until an interface doesn't exist.
btw the problem was seen with umb, it's not just ugen.
> On Wed, Feb 03, 2021 at 06:25:48AM +0100, Marcus Glocker wrote:
> >
> > Index: dev/usb/usbdi.c
> > ===
> > RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
> > retrieving revision 1.109
> > diff -u -p -u -p -r1.109 usbdi.c
> > --- dev/usb/usbdi.c 1 Feb 2021 09:21:51 - 1.109
> > +++ dev/usb/usbdi.c 2 Feb 2021 06:07:41 -
> > @@ -642,6 +642,10 @@ usbd_device2interface_handle(struct usbd
> >
> > if (dev->cdesc == NULL)
> > return (USBD_NOT_CONFIGURED);
> > + if (ifaceno < dev->cdesc->bNumInterfaces) {
> > + *iface = >ifaces[ifaceno];
> > + return (USBD_NORMAL_COMPLETION);
> > + }
> > /*
> > * The correct interface should be at dev->ifaces[ifaceno], but
> > we've
> > * seen non-compliant devices in the wild which present
> > non-contiguous
> >
> > So OK if I commit this fix Edd, Stuart?
>
> I'm OK with it as a quick-fix. At least it will make both of the devices
> in question work.
>
> But in the long run, it's not hard to imagine other non-compliant
> devices which would still be defeated by this code.
At some point you just have to say "this device is broken crap, send
it back or ebay it and buy an alternative". This is much easier for some
classes of device where there are many alternatives (like audio interfaces)
than mobile broadband where it's still very difficult to find something
suitable with the correct physical interface.
> Suppose a device presents its contiguous interfaces in reverse order, e.g.:
> [2, 1, 0]. Now suppose a device driver asks for interface 2. We will
> find interface 0, as we never check if it's the right interface and we
> never reach the part of the code that scans the array.
>
> In other words, just because an index exists, doesn't mean it's the right
> interface.
>
> I think (and I'm not much of a kernel hacker, so I reserve the right be wrong)
> the correct solution is to:
>
> * always loop over the array looking for the right interface.
> * change ugen, so that it's scanning resilient to gaps in interface range.
>
> --
> Best Regards
> Edd Barrett
>
> http://www.theunixzoo.co.uk
Re: 6.8-current ifconfig umb0 and Device not configured
Hi,
CCing ratchov@ and kettenis@ with some context.
In short: my change broke ugen, which expects to scan up the interface
range until an interface doesn't exist.
On Wed, Feb 03, 2021 at 06:25:48AM +0100, Marcus Glocker wrote:
>
> Index: dev/usb/usbdi.c
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
> retrieving revision 1.109
> diff -u -p -u -p -r1.109 usbdi.c
> --- dev/usb/usbdi.c 1 Feb 2021 09:21:51 - 1.109
> +++ dev/usb/usbdi.c 2 Feb 2021 06:07:41 -
> @@ -642,6 +642,10 @@ usbd_device2interface_handle(struct usbd
>
> if (dev->cdesc == NULL)
> return (USBD_NOT_CONFIGURED);
> + if (ifaceno < dev->cdesc->bNumInterfaces) {
> + *iface = >ifaces[ifaceno];
> + return (USBD_NORMAL_COMPLETION);
> + }
> /*
> * The correct interface should be at dev->ifaces[ifaceno], but we've
> * seen non-compliant devices in the wild which present non-contiguous
>
> So OK if I commit this fix Edd, Stuart?
I'm OK with it as a quick-fix. At least it will make both of the devices
in question work.
But in the long run, it's not hard to imagine other non-compliant
devices which would still be defeated by this code.
Suppose a device presents its contiguous interfaces in reverse order, e.g.:
[2, 1, 0]. Now suppose a device driver asks for interface 2. We will
find interface 0, as we never check if it's the right interface and we
never reach the part of the code that scans the array.
In other words, just because an index exists, doesn't mean it's the right
interface.
I think (and I'm not much of a kernel hacker, so I reserve the right be wrong)
the correct solution is to:
* always loop over the array looking for the right interface.
* change ugen, so that it's scanning resilient to gaps in interface range.
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
Re: 6.8-current ifconfig umb0 and Device not configured
On Wed, Feb 03, 2021 at 05:11:41AM +, Mikolaj Kucharski wrote: > On Tue, Feb 02, 2021 at 10:02:57AM +, Edd Barrett wrote: > > Hi, > > > > Apologies for breaking stuff. > > No worries. > > > On Tue, Feb 02, 2021 at 07:24:34AM +0100, Marcus Glocker wrote: > > > Edd: > > > Can you please also double check if this still works with your > > > uaudio(4) device? > > > > My device works with your diff. > > > > But, I'm not sure I understand why the change broke the device. Maybe we > > should update the comments in the code to better explain? > > > > Edd, could you send lsusb -v for your device? I guess it was some kind > of uaudio(4) device? That's Edds uaudio(4) device: https://gist.github.com/vext01/958756d0fd515cc321f99a3ee1e3351a
Re: 6.8-current ifconfig umb0 and Device not configured
On Tue, Feb 02, 2021 at 10:01:32PM +, Mikolaj Kucharski wrote:
> Hi Marcus,
>
> Below diff makes umb(4) work for me. All good now.
Cool, thanks for testing Mikolaj.
So OK if I commit this fix Edd, Stuart?
Index: dev/usb/usbdi.c
===
RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.109
diff -u -p -u -p -r1.109 usbdi.c
--- dev/usb/usbdi.c 1 Feb 2021 09:21:51 - 1.109
+++ dev/usb/usbdi.c 2 Feb 2021 06:07:41 -
@@ -642,6 +642,10 @@ usbd_device2interface_handle(struct usbd
if (dev->cdesc == NULL)
return (USBD_NOT_CONFIGURED);
+ if (ifaceno < dev->cdesc->bNumInterfaces) {
+ *iface = >ifaces[ifaceno];
+ return (USBD_NORMAL_COMPLETION);
+ }
/*
* The correct interface should be at dev->ifaces[ifaceno], but we've
* seen non-compliant devices in the wild which present non-contiguous
Re: 6.8-current ifconfig umb0 and Device not configured
On Tue, Feb 02, 2021 at 10:02:57AM +, Edd Barrett wrote: > Hi, > > Apologies for breaking stuff. No worries. > On Tue, Feb 02, 2021 at 07:24:34AM +0100, Marcus Glocker wrote: > > Edd: > > Can you please also double check if this still works with your > > uaudio(4) device? > > My device works with your diff. > > But, I'm not sure I understand why the change broke the device. Maybe we > should update the comments in the code to better explain? > Edd, could you send lsusb -v for your device? I guess it was some kind of uaudio(4) device? -- Regards, Mikolaj
Re: 6.8-current ifconfig umb0 and Device not configured
Hi Marcus, Below diff makes umb(4) work for me. All good now. OpenBSD 6.8-current (GENERIC.MP) #166: Tue Feb 2 21:51:12 UTC 2021 r...@pc1.home.local:/home/mkucharski/openbsd/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4259872768 (4062MB) avail mem = 4115435520 (3924MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xcfe8b040 (13 entries) bios0: vendor coreboot version "v4.12.0.4" date 08/27/2020 bios0: PC Engines apu2 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-64 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.25 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 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, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD GX-412TC SOC, 998.13 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 cpu2: 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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD GX-412TC SOC, 998.36 MHz, 16-30-01 cpu3: 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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PBR4) acpiprt2 at acpi0: bus 1 (PBR5) acpiprt3 at acpi0: bus 2 (PBR6) acpiprt4 at acpi0: bus 3 (PBR7) acpiprt5 at acpi0: bus 4 (PBR8) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 amdgpio0 at acpi0 GPIO uid 0 addr 0xfed81500/0x300 irq 7, 184 pins "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "BOOT" at acpi0 not configured acpicpu0 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu2 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu3 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpitz0 at acpi0: critical temperature is 115 degC cpu0: 998 MHz: speeds: 1000 800 600 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD 16h Root
Re: 6.8-current ifconfig umb0 and Device not configured
On Tue, Feb 02, 2021 at 02:28:52PM +0100, Marcus Glocker wrote: > Because of that ugen(4) calls usbd_deactivate(), > and the device is busted ... I see. And it looks like that device is also not compliant: its interfaces are again, non-contiguous. > Now we can argue whether the behavior of ugen(4) is entirely correct, > and so forth, but at this point I really think we should make > usbd_device2interface_handle() backwards compatible again, because > otherwise I think we'll go down a rabbit hole of such situations. Agreed. (Maybe later the right solution is for ugen to first ask how many interfaces there are, and then keep scanning until it has seen them all, regardless of gaps in the interface numbers. Maybe that's not possible, I don't know) -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: 6.8-current ifconfig umb0 and Device not configured
On Tue, Feb 02, 2021 at 10:35:38AM +, Stuart Henderson wrote: > On 2021/02/02 10:02, Edd Barrett wrote: > > Hi, > > > > Apologies for breaking stuff. > > > > On Tue, Feb 02, 2021 at 07:24:34AM +0100, Marcus Glocker wrote: > > > Edd: > > > Can you please also double check if this still works with your > > > uaudio(4) device? > > > > My device works with your diff. > > > > But, I'm not sure I understand why the change broke the device. Maybe we > > should update the comments in the code to better explain? > > Let's see if it fixes the umb first. If my thought processes are correct > the previous code would have returned invalid and skipped the last three > interfaces (numbered 12, 13 and 13).. That's how this umb(4) device interfaces are setup: Index Interface Number - --- 0 0 1 2 2 3 3 12 4 13 Now our new usbd_device2interface_handle() is strictly checking whether the indexed interface number is matching the requested interface number. With this more strict behavior, ugen(4):ugen_set_config() will fail on index 1, where we never match interface number 2. Because of that ugen(4) calls usbd_deactivate(), and the device is busted ... Now we can argue whether the behavior of ugen(4) is entirely correct, and so forth, but at this point I really think we should make usbd_device2interface_handle() backwards compatible again, because otherwise I think we'll go down a rabbit hole of such situations.
Re: 6.8-current ifconfig umb0 and Device not configured
On 2021/02/02 10:02, Edd Barrett wrote: > Hi, > > Apologies for breaking stuff. > > On Tue, Feb 02, 2021 at 07:24:34AM +0100, Marcus Glocker wrote: > > Edd: > > Can you please also double check if this still works with your > > uaudio(4) device? > > My device works with your diff. > > But, I'm not sure I understand why the change broke the device. Maybe we > should update the comments in the code to better explain? Let's see if it fixes the umb first. If my thought processes are correct the previous code would have returned invalid and skipped the last three interfaces (numbered 12, 13 and 13)..
Re: 6.8-current ifconfig umb0 and Device not configured
Hi, Apologies for breaking stuff. On Tue, Feb 02, 2021 at 07:24:34AM +0100, Marcus Glocker wrote: > Edd: > Can you please also double check if this still works with your > uaudio(4) device? My device works with your diff. But, I'm not sure I understand why the change broke the device. Maybe we should update the comments in the code to better explain? -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: 6.8-current ifconfig umb0 and Device not configured
On Mon, Feb 01, 2021 at 10:16:37PM +, Mikolaj Kucharski wrote:
> On Mon, Feb 01, 2021 at 10:57:43PM +0100, Marcus Glocker wrote:
> > Ok. Then it was the usbd_device2interface_handle() change.
> > Fixed one device (uaudio), broke the other device (umb) :-|
> > Now lets see if we can find something common to make both
> > work. Can you please send an lsusb -v of your umb?
>
> Working umb0 (kernel with revert diff), full lsusb -v output:
Sigh. ugen(4) wants to cycle through all interfaces at one point,
and with our more strict check on the interface number fail soon.
Seems like in this case leaving the device back in some broken
status.
Since I don't want to break more things by trying to do the right
thing, I would propose that we re-introduce the loose behavior
of usbd_device2interface_handle(), and only execute the linear search
in case ifaceno >= bNumInterfaces. I hope this keeps both devices
working.
Edd:
Can you please also double check if this still works with your
uaudio(4) device?
Index: dev/usb/usbdi.c
===
RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.109
diff -u -p -u -p -r1.109 usbdi.c
--- dev/usb/usbdi.c 1 Feb 2021 09:21:51 - 1.109
+++ dev/usb/usbdi.c 2 Feb 2021 06:07:41 -
@@ -642,6 +642,10 @@ usbd_device2interface_handle(struct usbd
if (dev->cdesc == NULL)
return (USBD_NOT_CONFIGURED);
+ if (ifaceno < dev->cdesc->bNumInterfaces) {
+ *iface = >ifaces[ifaceno];
+ return (USBD_NORMAL_COMPLETION);
+ }
/*
* The correct interface should be at dev->ifaces[ifaceno], but we've
* seen non-compliant devices in the wild which present non-contiguous
Re: 6.8-current ifconfig umb0 and Device not configured
On Mon, Feb 01, 2021 at 10:16:37PM +, Mikolaj Kucharski wrote: > On Mon, Feb 01, 2021 at 10:57:43PM +0100, Marcus Glocker wrote: > > Ok. Then it was the usbd_device2interface_handle() change. > > Fixed one device (uaudio), broke the other device (umb) :-| > > Now lets see if we can find something common to make both > > work. Can you please send an lsusb -v of your umb? > Here is dmesg with a bit better debug information (MMM markers): OpenBSD 6.8-current (GENERIC.MP) #163: Mon Feb 1 22:22:39 UTC 2021 r...@pc1.home.local:/home/mkucharski/openbsd/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4259872768 (4062MB) avail mem = 4115435520 (3924MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xcfe8b040 (13 entries) bios0: vendor coreboot version "v4.12.0.4" date 08/27/2020 bios0: PC Engines apu2 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-64 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.26 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 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, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD GX-412TC SOC, 998.13 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD GX-412TC SOC, 998.13 MHz, 16-30-01 cpu2: 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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 cpu3: 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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PBR4) acpiprt2 at acpi0: bus 1 (PBR5) acpiprt3 at acpi0: bus 2 (PBR6) acpiprt4 at acpi0: bus 3 (PBR7) acpiprt5 at acpi0: bus 4 (PBR8) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 amdgpio0 at acpi0 GPIO uid 0 addr 0xfed81500/0x300 irq 7, 184 pins "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "BOOT" at acpi0 not configured acpicpu0
Re: 6.8-current ifconfig umb0 and Device not configured
On Mon, Feb 01, 2021 at 10:57:43PM +0100, Marcus Glocker wrote: > Ok. Then it was the usbd_device2interface_handle() change. > Fixed one device (uaudio), broke the other device (umb) :-| > Now lets see if we can find something common to make both > work. Can you please send an lsusb -v of your umb? Working umb0 (kernel with revert diff), full lsusb -v output: 8< Script started on Mon Feb 1 22:06:42 2021 Bus 000 Device 001: ID 1022: Shinko Shoji Co., Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize0 9 idVendor 0x1022 Shinko Shoji Co., Ltd idProduct 0x bcdDevice1.00 iManufacturer 1 AMD iProduct2 xHCI root hub iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 13 bDescriptorType 42 nNbrPorts 4 wHubCharacteristic 0x Ganged power switching Ganged overcurrent protection TT think time 8 FS bits bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable0x00 PortPwrCtrlMask0x00 Hub Port Status: Port 1: .02a0 5Gbps power Rx.Detect Port 2: .02a0 5Gbps power Rx.Detect Port 3: .0503 Unknown Speed Recovery enable connect Port 4: .02a0 5Gbps power Rx.Detect Device Status: 0x0001 Self Powered Bus 000 Device 002: ID 04e8:3469 Samsung Electronics Co., Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x04e8 Samsung Electronics Co., Ltd idProduct 0x3469 bcdDevice1.00 iManufacturer 1 Samsung Electronics Co., Ltd. iProduct2 M2070 Series iSerial 3 ZF46B8KM2D02Z1A bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 55 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 10 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 7 Printer bInterfaceSubClass 1 Printer bInterfaceProtocol 2 Bidirectional iInterface 0 Endpoint
Re: 6.8-current ifconfig umb0 and Device not configured
Ok. Then it was the usbd_device2interface_handle() change. Fixed one device (uaudio), broke the other device (umb) :-| Now lets see if we can find something common to make both work. Can you please send an lsusb -v of your umb? On Mon, Feb 01, 2021 at 09:39:43PM +, Mikolaj Kucharski wrote: > Bingo! > > After applying your revert diff, umb0 works as expected: > > # ifconfig umb0 > umb0: flags=8855 mtu 1500 > index 7 priority 6 llprio 3 > roaming disabled registration home network > state up cell-class LTE rssi -99dBm speed 47.7Mbps up 286Mbps down > SIM initialized PIN valid (3 attempts left) > subscriber-id 000 ICC-id provider PLAY > device MC7455 IMEI 000 firmware SWI9X30C_02.33.03.00 > APN internet > dns 89.108.202.20 185.89.185.1 > groups: egress > status: active > inet 100.109.48.67 --> 100.109.48.68 netmask 0xfff8 > > OpenBSD 6.8-current (GENERIC.MP) #161: Mon Feb 1 21:31:17 UTC 2021 > > r...@pc1.home.local:/home/mkucharski/openbsd/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4259872768 (4062MB) > avail mem = 4115431424 (3924MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xcfe8b040 (13 entries) > bios0: vendor coreboot version "v4.12.0.4" date 08/27/2020 > bios0: PC Engines apu2 > acpi0 at bios0: ACPI 6.0 > acpi0: sleep states S0 S1 S4 S5 > acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET > acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) > UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-64 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD GX-412TC SOC, 998.25 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line > 16-way L2 cache > cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu0: DTLB 40 4KB entries fully associative, 8 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, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD GX-412TC SOC, 998.14 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line > 16-way L2 cache > cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 > cpu2: > 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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line > 16-way L2 cache > cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 > cpu3: > 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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line > 16-way L2 cache > cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative > cpu3: smt 0, core 3, package 0 > ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins > ioapic1 at mainbus0: apid 5 pa 0xfec2,
Re: 6.8-current ifconfig umb0 and Device not configured
Bingo! After applying your revert diff, umb0 works as expected: # ifconfig umb0 umb0: flags=8855 mtu 1500 index 7 priority 6 llprio 3 roaming disabled registration home network state up cell-class LTE rssi -99dBm speed 47.7Mbps up 286Mbps down SIM initialized PIN valid (3 attempts left) subscriber-id 000 ICC-id provider PLAY device MC7455 IMEI 000 firmware SWI9X30C_02.33.03.00 APN internet dns 89.108.202.20 185.89.185.1 groups: egress status: active inet 100.109.48.67 --> 100.109.48.68 netmask 0xfff8 OpenBSD 6.8-current (GENERIC.MP) #161: Mon Feb 1 21:31:17 UTC 2021 r...@pc1.home.local:/home/mkucharski/openbsd/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4259872768 (4062MB) avail mem = 4115431424 (3924MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xcfe8b040 (13 entries) bios0: vendor coreboot version "v4.12.0.4" date 08/27/2020 bios0: PC Engines apu2 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-64 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.25 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 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, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD GX-412TC SOC, 998.14 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 cpu2: 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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 cpu3: 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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PBR4) acpiprt2 at acpi0: bus 1 (PBR5) acpiprt3 at acpi0: bus 2 (PBR6) acpiprt4 at acpi0: bus 3 (PBR7) acpiprt5 at acpi0: bus 4 (PBR8) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 amdgpio0 at acpi0 GPIO uid 0 addr 0xfed81500/0x300 irq 7, 184 pins "PRP0001" at acpi0 not configured "PRP0001" at
Re: 6.8-current ifconfig umb0 and Device not configured
Thanks.
There were some changes going in that area recently.
I think we need to try reverting some of them, and see which fixes it.
Lets start with the most obvious one. Does this change anything?
Index: dev/usb/usbdi.c
===
RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.109
diff -u -p -u -p -r1.109 usbdi.c
--- dev/usb/usbdi.c 1 Feb 2021 09:21:51 - 1.109
+++ dev/usb/usbdi.c 1 Feb 2021 21:11:45 -
@@ -638,23 +638,12 @@ usbd_status
usbd_device2interface_handle(struct usbd_device *dev, u_int8_t ifaceno,
struct usbd_interface **iface)
{
- u_int8_t idx;
-
if (dev->cdesc == NULL)
return (USBD_NOT_CONFIGURED);
- /*
-* The correct interface should be at dev->ifaces[ifaceno], but we've
-* seen non-compliant devices in the wild which present non-contiguous
-* interface numbers and this skews the indices. For this reason we
-* linearly search the interface array.
-*/
- for (idx = 0; idx < dev->cdesc->bNumInterfaces; idx++) {
- if (dev->ifaces[idx].idesc->bInterfaceNumber == ifaceno) {
- *iface = >ifaces[idx];
- return (USBD_NORMAL_COMPLETION);
- }
- }
- return (USBD_INVAL);
+ if (ifaceno >= dev->cdesc->bNumInterfaces)
+ return (USBD_INVAL);
+ *iface = >ifaces[ifaceno];
+ return (USBD_NORMAL_COMPLETION);
}
/* use altno */
Re: 6.8-current ifconfig umb0 and Device not configured
Can you also send a dmesg of the last working kernel please? On Mon, Feb 01, 2021 at 08:03:29PM +, miko...@kucharski.name wrote: > >Synopsis:umb(4) not working, ifconfig: SIOCGWG: Device not configured > >Category:kernel > >Environment: > System : OpenBSD 6.8 > Details : OpenBSD 6.8-current (GENERIC.MP) #302: Sat Jan 30 > 21:51:53 MST 2021 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > After sysupgrade to recent snapshot network over umb0 stopped > working. During inspection it looks umb0 device stopped working: > > # ifconfig umb0 > umb0: flags=8810 mtu 1500 > index 7 priority 6 llprio 3 > ifconfig: SIOCGWG: Device not configured > > >How-To-Repeat: > Upgrade to OpenBSD 6.8-current (GENERIC.MP) #302 amd64 on PC > Engines APU2 with Sierra Wireless MC7455 mini-PCIe card. Device umb(4) > doesn't work as expected. Like shown above ifconfig always fails on > umb0. > > >Fix: > Unknown. Need to bisect when this stopped working, unless > someone has an idea what could be source of the problem. Last working > official kernel was: > > OpenBSD 6.8-current (GENERIC.MP) #264: Thu Jan 7 11:41:04 MST 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Currently not working official kernel is: > > OpenBSD 6.8-current (GENERIC.MP) #302: Sat Jan 30 21:51:53 MST 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > I've also used my own custom kernels on that machine and last > working kernel was: > > OpenBSD 6.8-current (GENERIC.MP) #157: Sat Jan 23 22:27:44 UTC 2021 > > r...@pc1.home.local:/home/mkucharski/openbsd/src/sys/arch/amd64/compile/GENERIC.MP > > Above build timestamp is also approximate time when CVS checkout was > done. > > dmesg: > OpenBSD 6.8-current (GENERIC.MP) #302: Sat Jan 30 21:51:53 MST 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4259872768 (4062MB) > avail mem = 4115435520 (3924MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xcfe8b040 (13 entries) > bios0: vendor coreboot version "v4.12.0.4" date 08/27/2020 > bios0: PC Engines apu2 > acpi0 at bios0: ACPI 6.0 > acpi0: sleep states S0 S1 S4 S5 > acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET > acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) > UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-64 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD GX-412TC SOC, 998.27 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line > 16-way L2 cache > cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu0: DTLB 40 4KB entries fully associative, 8 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, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD GX-412TC SOC, 998.25 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line > 16-way L2 cache > cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 > cpu2: > 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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line > 16-way L2 cache > cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully
Re: 6.8-current ifconfig umb0 and Device not configured
Here dmesg when umb0 works: OpenBSD 6.8-current (GENERIC.MP) #157: Sat Jan 23 22:27:44 UTC 2021 r...@pc1.home.local:/home/mkucharski/openbsd/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4259872768 (4062MB) avail mem = 4115431424 (3924MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xcfe8b040 (13 entries) bios0: vendor coreboot version "v4.12.0.4" date 08/27/2020 bios0: PC Engines apu2 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-64 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.28 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 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, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD GX-412TC SOC, 998.14 MHz, 16-30-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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 cpu2: 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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 cpu3: 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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PBR4) acpiprt2 at acpi0: bus 1 (PBR5) acpiprt3 at acpi0: bus 2 (PBR6) acpiprt4 at acpi0: bus 3 (PBR7) acpiprt5 at acpi0: bus 4 (PBR8) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 amdgpio0 at acpi0 GPIO uid 0 addr 0xfed81500/0x300 irq 7, 184 pins "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "PRP0001" at acpi0 not configured "BOOT" at acpi0 not configured acpicpu0 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu2 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpicpu3 at acpi0: C2(0@400 io@0x1771), C1(@1 halt!), PSS acpitz0 at acpi0: critical temperature is 115 degC cpu0: 998 MHz: speeds: 1000 800 600 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD 16h Root Complex" rev 0x00 vendor "AMD",
