Re: Sierra Wireless MC7750 attaches as ugen(4) on OpenBSD 7.3 #1125 2023-March-25
On Thu, 2023-04-06 at 11:59 +, Gerhard Roth wrote: > On Thu, 2023-04-06 at 11:51 +, Mikolaj Kucharski wrote: > > On Thu, Apr 06, 2023 at 11:40:06AM +, Gerhard Roth wrote: > > > On Thu, 2023-04-06 at 11:15 +, Mikolaj Kucharski wrote: > > > > > > > > So, I am not sure do I understand the output right, but is this modem > > > > already in correct mode? > > > > > > Well "correct" depends on what you want ;) > > > > > > Mode 6 offers AT mode (meaning you have a modem to control with AT- > > > commands) and QMI. Sadly, none of the supported modes includes > > > an MBIM (umb) interface. So mode 6 is probably the best one you can pick. > > > > Ah, sorry. I got confused by all those abbreviations. The device umb(4) > > is MBIM and not QMI. Yeah, I see what you mean. > > > > Basically there is nothing more to do here? Then my option to have an > > internet via that modem is pppd(8) on /dev/cueU2 ? > > I don't know what kind of mode is supplied by "Win8 Std Net". But from > the others listed, I'm afraid that is correct. pppd(8)/chat(8) is what > you need. But I might stand corrected after googling a little bit: https://techship.com/faq/how-to-change-usb-interface-using-atusbcomp-on-sierra-wireless-modules/ says that MC7750 uses "AT!USBCOMP" instead of "AT!UDUSBCOMP" to switch modes. Maybe that'll help. > > > > > > > > > > > > > > > > AT!ENTERCND="A710" > > > > OK > > > > AT!UDUSBCOMP=? > > > > 0 - HIP DM NMEA AT MDM1 MDM2 MDM3 MS NOT SUPPORTED > > > > 1 - HIP DM NMEA AT MDM1 MS NOT SUPPORTED > > > > 2 - HIP DM NMEA AT NIC1 MS NOT SUPPORTED > > > > 3 - HIP DM NMEA AT MDM1 NIC1 MS NOT SUPPORTED > > > > 4 - HIP DM NMEA AT NIC1 NIC2 NIC3 MS NOT SUPPORTED > > > > 5 - HIP DM NMEA AT ECM1 MS NOT SUPPORTED > > > > 6 - DM NMEA AT QMI SUPPORTED > > > > 7 - DM NMEA AT RMNET1 RMNET2 RMNET3 SUPPORTED > > > > 8 - Win8 Std Net SUPPORTED > > > > > > > > > > > > OK > > > > AT!UDUSBCOMP? > > > > !UDUSBCOMP: 6 > > > > > > > > OK > > > > > > > smime.p7s Description: S/MIME cryptographic signature
Re: Sierra Wireless MC7750 attaches as ugen(4) on OpenBSD 7.3 #1125 2023-March-25
On Thu, 2023-04-06 at 11:51 +, Mikolaj Kucharski wrote: > On Thu, Apr 06, 2023 at 11:40:06AM +0000, Gerhard Roth wrote: > > On Thu, 2023-04-06 at 11:15 +, Mikolaj Kucharski wrote: > > > > > > So, I am not sure do I understand the output right, but is this modem > > > already in correct mode? > > > > Well "correct" depends on what you want ;) > > > > Mode 6 offers AT mode (meaning you have a modem to control with AT- > > commands) and QMI. Sadly, none of the supported modes includes > > an MBIM (umb) interface. So mode 6 is probably the best one you can pick. > > Ah, sorry. I got confused by all those abbreviations. The device umb(4) > is MBIM and not QMI. Yeah, I see what you mean. > > Basically there is nothing more to do here? Then my option to have an > internet via that modem is pppd(8) on /dev/cueU2 ? I don't know what kind of mode is supplied by "Win8 Std Net". But from the others listed, I'm afraid that is correct. pppd(8)/chat(8) is what you need. > > > > > > > > > > AT!ENTERCND="A710" > > > OK > > > AT!UDUSBCOMP=? > > > 0 - HIP DM NMEA AT MDM1 MDM2 MDM3 MS NOT SUPPORTED > > > 1 - HIP DM NMEA AT MDM1 MS NOT SUPPORTED > > > 2 - HIP DM NMEA AT NIC1 MS NOT SUPPORTED > > > 3 - HIP DM NMEA AT MDM1 NIC1 MS NOT SUPPORTED > > > 4 - HIP DM NMEA AT NIC1 NIC2 NIC3 MS NOT SUPPORTED > > > 5 - HIP DM NMEA AT ECM1 MS NOT SUPPORTED > > > 6 - DM NMEA AT QMI SUPPORTED > > > 7 - DM NMEA AT RMNET1 RMNET2 RMNET3 SUPPORTED > > > 8 - Win8 Std Net SUPPORTED > > > > > > > > > OK > > > AT!UDUSBCOMP? > > > !UDUSBCOMP: 6 > > > > > > OK > > > > smime.p7s Description: S/MIME cryptographic signature
Re: Sierra Wireless MC7750 attaches as ugen(4) on OpenBSD 7.3 #1125 2023-March-25
On Thu, 2023-04-06 at 11:15 +, Mikolaj Kucharski wrote:
> On Thu, Apr 06, 2023 at 09:13:27AM +0000, Gerhard Roth wrote:
> >
> > The Sierra Wireless documentation is available. Alas, switching the
> > mode seems far too complex and error prone to perform this inside
> > a driver.
> >
> > When the AT (modem) interface is available, you would have to:
> >
> > 1) enter password protected command mode with "AT!ENTERCND=passwd"
> >
> > 2) query the list of modes with "AT!UDUSBCOMP=?". Example result:
> >
> > 0 - reserved NOT SUPPORTED
> > 1 - DM AT SUPPORTED
> > 2 - reserved NOT SUPPORTED
> > 3 - reserved NOT SUPPORTED
> > 4 - reserved NOT SUPPORTED
> > 5 - reserved NOT SUPPORTED
> > 6 - DM NMEA AT QMI SUPPORTED
> > 7 - DM NMEA AT RMNET1 RMNET2 RMNET3 SUPPORTED
> > 8 - DM NMEA AT MBIM SUPPORTED
> > 9 - MBIM SUPPORTED
> > 10 - NMEA MBIM SUPPORTED
> > 11 - DM MBIM SUPPORTED
> > 12 - DM NMEA MBIM SUPPORTED
> > 13 - Config1: comp6 Config2: comp8 NOT SUPPORTED
> > 14 - Config1: comp6 Config2: comp9 SUPPORTED
> > 15 - Config1: comp6 Config2: comp10 NOT SUPPORTED
> > 16 - Config1: comp6 Config2: comp11 NOT SUPPORTED
> > 17 - Config1: comp6 Config2: comp12 NOT SUPPORTED
> > 18 - Config1: comp7 Config2: comp8 NOT SUPPORTED
> > 19 - Config1: comp7 Config2: comp9 SUPPORTED
> > 20 - Config1: comp7 Config2: comp10 NOT SUPPORTED
> > 21 - Config1: comp7 Config2: comp11 NOT SUPPORTED
> > 22 - Config1: comp7 Config2: comp12 NOT SUPPORTED
> >
> > There is no guarantee that the table doesn't change. And every
> > device has a differnt set of supported modes.
> >
> > 3) select the desired mode with "AT!UDUSBCOMP=X"
> > 4) wait for the device to reset itself
>
> So, I am not sure do I understand the output right, but is this modem
> already in correct mode?
Well "correct" depends on what you want ;)
Mode 6 offers AT mode (meaning you have a modem to control with AT-
commands) and QMI. Sadly, none of the supported modes includes
an MBIM (umb) interface. So mode 6 is probably the best one you can pick.
>
>
> AT!ENTERCND="A710"
> OK
> AT!UDUSBCOMP=?
> 0 - HIP DM NMEA AT MDM1 MDM2 MDM3 MS NOT SUPPORTED
> 1 - HIP DM NMEA AT MDM1 MS NOT SUPPORTED
> 2 - HIP DM NMEA AT NIC1 MS NOT SUPPORTED
> 3 - HIP DM NMEA AT MDM1 NIC1 MS NOT SUPPORTED
> 4 - HIP DM NMEA AT NIC1 NIC2 NIC3 MS NOT SUPPORTED
> 5 - HIP DM NMEA AT ECM1 MS NOT SUPPORTED
> 6 - DM NMEA AT QMI SUPPORTED
> 7 - DM NMEA AT RMNET1 RMNET2 RMNET3 SUPPORTED
> 8 - Win8 Std Net SUPPORTED
>
>
> OK
> AT!UDUSBCOMP?
> !UDUSBCOMP: 6
>
> OK
>
>
> That is on kernel with the below diff applied - on line change to umsm.c
>
> # dmesg
> ...
> umsm0 at uhub4 port 3 configuration 1 interface 0 "Sierra Wireless,
> Incorporated MC7750" rev 2.00/0.06 addr 3
> ucom0 at umsm0
> umsm1 at uhub4 port 3 configuration 1 interface 2 "Sierra Wireless,
> Incorporated MC7750" rev 2.00/0.06 addr 3
> ucom1 at umsm1
> umsm2 at uhub4 port 3 configuration 1 interface 3 "Sierra Wireless,
> Incorporated MC7750" rev 2.00/0.06 addr 3
> ucom2 at umsm2
> umsm3 at uhub4 port 3 configuration 1 interface 8 "Sierra Wireless,
> Incorporated MC7750" rev 2.00/0.06 addr 3
> ucom3 at umsm3
>
>
> > >
> > > Index: umsm.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/usb/umsm.c,v
> > > retrieving revision 1.125
> > > diff -u -p -r1.125 umsm.c
> > > --- umsm.c 2 Apr 2023 23:57:57 - 1.125
> > > +++ umsm.c 6 Apr 2023 08:40:30 -
> > > @@ -271,6 +271,7 @@ static const struct umsm_type umsm_devs[
> > > {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_AIRCARD_340U}, 0},
> > > {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_AIRCARD_770S}, 0},
> > > {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC7455}, 0},
> > > + {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC7700}, 0},
> > >
> > > {{ USB_VENDOR_SIMCOM, USB_PRODUCT_SIMCOM_SIM5320}, 0},
> > > {{ USB_VENDOR_SIMCOM, USB_PRODUCT_SIMCOM_SIM7600E}, 0},
> > >
> >
>
smime.p7s
Description: S/MIME cryptographic signature
Re: Sierra Wireless MC7750 attaches as ugen(4) on OpenBSD 7.3 #1125 2023-March-25
On Thu, 2023-04-06 at 18:49 +1000, David Gwynne wrote: > On Wed, Apr 05, 2023 at 11:22:34PM +, Mikolaj Kucharski wrote: > > On Wed, Apr 05, 2023 at 11:16:55PM +, miko...@kucharski.name wrote: > > > > Synopsis: Sierra Wireless MC7750 attaches as ugen(4) > > > > Category: kernel > > > > Environment: > > > System : OpenBSD 7.3 > > > Details : OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 > > > MDT 2023 > > > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > Architecture: OpenBSD.amd64 > > > Machine : amd64 > > > > Description: > > > Sierra Wireless MC7750 attaches as ugen(4) on PC Engines APU3, > > > running OpenBSD. Modem is mini-PCIe device. > > > > How-To-Repeat: > > > No specific steps. Plug in the device, boot up OpenBSD. > > > > Fix: > > > Unknown. > > > > > > > Forgot to also add lsusb output. > > > > # lsusb -vvv -d 1199:68a2 > > > > Bus 002 Device 003: ID 1199:68a2 Sierra Wireless, Inc. > > Device Descriptor: > > bLength 18 > > bDescriptorType 1 > > bcdUSB 2.00 > > bDeviceClass 0 (Defined at Interface level) > > bDeviceSubClass 0 > > bDeviceProtocol 0 > > bMaxPacketSize0 64 > > idVendor 0x1199 Sierra Wireless, Inc. > > idProduct 0x68a2 > > bcdDevice 0.06 > > iManufacturer 3 Sierra Wireless, Incorporated > > iProduct 2 MC7750 > > iSerial 4 00102700999 > > bNumConfigurations 1 > > Configuration Descriptor: > > bLength 9 > > bDescriptorType 2 > > wTotalLength 115 > > bNumInterfaces 4 > > bConfigurationValue 1 > > iConfiguration 1 Sierra Configuration > > bmAttributes 0xe0 > > Self Powered > > Remote Wakeup > > MaxPower 0mA > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 0 > > bAlternateSetting 0 > > bNumEndpoints 2 > > bInterfaceClass 255 Vendor Specific Class > > bInterfaceSubClass 255 Vendor Specific Subclass > > bInterfaceProtocol 255 Vendor Specific Protocol > > iInterface 0 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x81 EP 1 IN > > bmAttributes 2 > > Transfer Type Bulk > > Synch Type None > > Usage Type Data > > wMaxPacketSize 0x0200 1x 512 bytes > > bInterval 32 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x01 EP 1 OUT > > bmAttributes 2 > > Transfer Type Bulk > > Synch Type None > > Usage Type Data > > wMaxPacketSize 0x0200 1x 512 bytes > > bInterval 32 > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 2 > > bAlternateSetting 0 > > bNumEndpoints 2 > > bInterfaceClass 255 Vendor Specific Class > > bInterfaceSubClass 255 Vendor Specific Subclass > > bInterfaceProtocol 255 Vendor Specific Protocol > > iInterface 0 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x82 EP 2 IN > > bmAttributes 2 > > Transfer Type Bulk > > Synch Type None > > Usage Type Data > > wMaxPacketSize 0x0200 1x 512 bytes > > bInterval 32 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x02 EP 2 OUT > > bmAttributes 2 > > Transfer Type Bulk > > Synch Type None > > Usage Type Data > > wMaxPacketSize 0x0200 1x 512 bytes > > bInterval 32 > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 3 > > bAlternateSetting 0 > > bNumEndpoints 3 > > bInterfaceClass 255 Vendor Specific Class > > bInterfaceSubClass 255 Vendor Specific Subclass > > bInterfaceProtocol 255 Vendor Specific Protocol > > iInterface 0 > > Endpoint Descriptor: > >
Re: axen0: invalid buffer(pkt#1)
On Mon, 28 Mar 2022 09:25:32 +0200 Gerhard Roth wrote:
> Hi Stephan,
>
> although the newer AX88179A chip set (note the "A" at the end) uses the
> same product ID as the older AX88179, it is quite different.
>
> I will work on support for AX88179A, but that'll take some time.
>
> Regards,
>
> Gerhard
>
>
> On 3/26/22 22:05, Stephan Mending wrote:
> > Hi *,
> > I am currently in the unlucky position having to use two
> > usb-to-ethernet-adapters on a router.
> >
> > Therefore, I bought a model from "ISY" called "USB-A to Gigabit LAN Adapter
> > IAD-1010-A". You probably don't care about
> > the name of it.
> >
> > axen0 at uhub0 port 12 configuration 1 interface 0 "ASIX AX88179A" rev
> > 2.10/2.00 addr 9
> > axen0: AX88179, address f8:e4:3b:08:10:e2
> > ukphy0 at axen0 phy 3: Generic IEEE 802.3u media interface, rev. 1:
> > OUI 0x000700, model 0x0006
> >
> > The adapters are configured to act as interfaces for a local network.
> >
> > As soon as packets are received following messages are printed to
> > /var/log/messages:
> >
> > axen0: invalid buffer(pkt#1), continue
> >
> > These messages are issued with each and every packet that is received on
> > the interface.
> >
> > Taking a look at tcpdump:
> >
> > truncated-ip - 4 bytes missing!
> >
> > This message prefixes every packet that I sent towards the axen usb-adapter
> > (not just dhcp).
> > Same behavior for both of the adapters.
> >
> > Do you guys have any idea, what might be the issue?
> >
> > Best regards,
> > Stephan
> >
I got a sample driver from ASIX for the AX88179A chipset and they allow me
to use it to write a driver but they won't allow me to publish it :(
ASIX recomended to use the CDC/NCM interface of the chipset, but OpenBSD
has no driver for CDC/NCM. Looking at the USB descriptor it turns out,
that it also has a configuration for CDC/ECM.
If you try the patch below, the AX88179A should attach via cdce(4). Don't
know if this is the way to go, but at least you should be able to use
your adapters.
Good luck,
Gerhard
Index: sys/dev/usb/if_cdce.c
===
RCS file: /cvs/src/sys/dev/usb/if_cdce.c,v
retrieving revision 1.80
diff -u -p -u -p -r1.80 if_cdce.c
--- sys/dev/usb/if_cdce.c 29 Jan 2021 17:12:19 - 1.80
+++ sys/dev/usb/if_cdce.c 21 Apr 2022 11:55:15 -
@@ -59,8 +59,11 @@
#include
#include
+#include
+
#include
#include
+#include
#include
#include
#include
@@ -90,18 +93,19 @@ void cdce_stop(struct cdce_softc *);
voidcdce_intr(struct usbd_xfer *, void *, usbd_status);
const struct cdce_type cdce_devs[] = {
-{{ USB_VENDOR_ACERLABS, USB_PRODUCT_ACERLABS_M5632 }, 0 },
-{{ USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2501 }, 0 },
-{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SL5500 }, CDCE_CRC32 },
-{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_A300 }, CDCE_CRC32 },
-{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SL5600 }, CDCE_CRC32 },
-{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_C700 }, CDCE_CRC32 },
-{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_C750 }, CDCE_CRC32 },
-{{ USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_USBLAN }, CDCE_CRC32 },
-{{ USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_USBLAN2 }, CDCE_CRC32 },
-{{ USB_VENDOR_GMATE, USB_PRODUCT_GMATE_YP3X00 }, 0 },
-{{ USB_VENDOR_COMPAQ, USB_PRODUCT_COMPAQ_IPAQLINUX }, 0 },
-{{ USB_VENDOR_AMBIT, USB_PRODUCT_AMBIT_NTL_250 }, CDCE_SWAPUNION },
+{{ USB_VENDOR_ACERLABS, USB_PRODUCT_ACERLABS_M5632 }, 0, 0, -1 },
+{{ USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2501 }, 0, 0, -1 },
+{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SL5500 }, 0, CDCE_CRC32, -1 },
+{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_A300 }, 0, CDCE_CRC32, -1 },
+{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SL5600 }, 0, CDCE_CRC32, -1 },
+{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_C700 }, 0, CDCE_CRC32, -1 },
+{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_C750 }, 0, CDCE_CRC32, -1 },
+{{ USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_USBLAN }, 0, CDCE_CRC32, -1
},
+{{ USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_USBLAN2 }, 0, CDCE_CRC32,
-1 },
+{{ USB_VENDOR_GMATE, USB_PRODUCT_GMATE_YP3X00 }, 0, 0, -1 },
+{{ USB_VENDOR_COMPAQ, USB_PRODUCT_COMPAQ_IPAQLINUX }, 0, 0, -1 },
+{{ USB_VENDOR_AMBIT, USB_PRODUCT_AMBIT_NTL_250 }, 0, CDCE_SWAPUNION, -1 },
+{{ USB_VENDOR_ASIX, USB_PRODUCT_ASIX_AX88179 }, 0x0200, CDCE_MATCHREV, 3 },
};
#define cdce_lookup(v, p) \
((const struct cdce_type *)usb_lookup(cdce_devs, v, p))
@@ -123,6 +127,15 @@ cdce_match(struct device *parent, void *
{
struct usb_attach_arg *uaa = aux;
Re: axen0: invalid buffer(pkt#1)
Hi Stephan, although the newer AX88179A chip set (note the "A" at the end) uses the same product ID as the older AX88179, it is quite different. I will work on support for AX88179A, but that'll take some time. Regards, Gerhard On 3/26/22 22:05, Stephan Mending wrote: Hi *, I am currently in the unlucky position having to use two usb-to-ethernet-adapters on a router. Therefore, I bought a model from "ISY" called "USB-A to Gigabit LAN Adapter IAD-1010-A". You probably don't care about the name of it. axen0 at uhub0 port 12 configuration 1 interface 0 "ASIX AX88179A" rev 2.10/2.00 addr 9 axen0: AX88179, address f8:e4:3b:08:10:e2 ukphy0 at axen0 phy 3: Generic IEEE 802.3u media interface, rev. 1: OUI 0x000700, model 0x0006 The adapters are configured to act as interfaces for a local network. As soon as packets are received following messages are printed to /var/log/messages: axen0: invalid buffer(pkt#1), continue These messages are issued with each and every packet that is received on the interface. Taking a look at tcpdump: truncated-ip - 4 bytes missing! This message prefixes every packet that I sent towards the axen usb-adapter (not just dhcp). Same behavior for both of the adapters. Do you guys have any idea, what might be the issue? Best regards, Stephan smime.p7s Description: S/MIME cryptographic signature
Re: run(4) panic: null node
On Thu, 28 Oct 2021 10:10:23 + Klemens Nanni wrote:
> On Tue, Sep 14, 2021 at 05:52:08PM -0400, James Hastings wrote:
> > >Synopsis: run(4): connecting to WEP network. panic: null node
> > >Category: kernel
> > >Environment:
> > System : OpenBSD 7.0
> > Details : OpenBSD 7.0-beta (GENERIC.MP) #206: Thu Sep 9 09:24:02
> > MDT 2021
> >
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > I was testing various networks with a Ralink RT5370 USB run(4) device.
> > Connecting to a WEP-enabled SSID reliably produces the following kernel
> > panic:
>
> I looked at this out of curiosity and the code seems obviously wrong.
>
> > panic: null node
> > Stopped at db_enter+0x10: popq%rbp
> > TID PIDUID PRFLAGS PFLAGS CPU COMMAND
> > *515938 8927 0 0x14000 0x2003K usbtask
> > db_enter() at db_enter+0x10
> > panic(81e29b27) at panic+0xbf
> > ieee80211_send_mgmt(80e7d048,0,c0,3,0) at ieee80211_send_mgmt+0x3aa
> > run_set_key_cb(80e7d000,80e7fe00) at run_set_key_cb+0x76
> > run_task(80e7d000) at run_task+0xa9
> > usb_task_thread(800022d72550) at usb_task_thread+0x135
> > end trace frame: 0x0, count: 9
>
> run_init() does this
>
> if (ic->ic_flags & IEEE80211_F_WEPON) {
> /* install WEP keys */
> for (i = 0; i < IEEE80211_WEP_NKID; i++)
> (void)run_set_key(ic, NULL, >ic_nw_keys[i]);
> }
>
> run_set_key() passes that NULL argument unaltered to run_set_key_cb()
> which eventually calls ieee80211_send_mgmt() with a NULL `ni' argument
> which hits the panic.
>
> I don't see how this can work; maybe an oversight whenever run(4) or
> 802.11 was touched last?
Yes, apparently before
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/if_run.c.diff?r1=1.131=1.132=h
run_set_key_cb() wouldn't even look at 'cmd->ni'.
>
> > >How-To-Repeat:
> > $ doas ifconfig run0 nwid MYWEPSSID nwkey 0xXX
> > $ doas ifconfig run0 up
> >
> > >Fix:
> > Unknown at this time.
>
smime.p7s
Description: S/MIME cryptographic signature
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: umb(4) /bsd: usb_insert_transfer: xfer=0xfffffd843de527c0 not free
On 2020-08-18 00:03, Christoph R. Winter wrote: Hello, thanks for your fast answer. Am 17.08.2020 11:29, schrieb Gerhard Roth: The "not on queue" error sounds more like a bug in xhci(4). Could you please try to disable USB3 in the BIOS an see if the problem resolves then. I disabled USB3 in the BIOS but the connection died again randomly. The difference is, without USB3 there are no errors in XConsole nor in /var/log/messages. I also tried the HDD with OpenBSD in a ThinkPad W541 with another LTE card (other card but same model) with exact the same results. To verify that it is no hardware thing, I tried a recent live version of a Linux Mint on booth machines. The download and to run it for some time worked without any connection lose. Regards, Christoph Hi Christoph, MBIM has a method to reset devices. However, this is not implemented in umb(4). So it the device detaches itself from the USB this is almost certainly a firmware bug. Just because you didn't see it with Linux doesn't mean that this has to be a problem with umb(4). On freedesktop.org (the home of libmbim), there have been reports of detaching EM7345, too. And all of them suggest a firmware update. See https://lists.freedesktop.org/archives/libqmi-devel/2018-August/002947.html Could you please check, if there is a newer firmware available an if so, update your device. Gerhard
Re: umb(4) /bsd: usb_insert_transfer: xfer=0xfffffd843de527c0 not free
On 2020-08-15 14:47, Christoph R. Winter wrote: Update : During a CVS checkout I got disconnected because of a loop something (sorry, did not kept the message) and saw a new message in /var/log/messages. This time the device disaapeared in ifconfig. Aug 15 07:21:35 t440p /bsd: usb_insert_transfer: xfer=0xfd843de52000 not free Aug 15 08:02:43 t440p /bsd: usb_transfer_complete: xfer=0xfd843de52000 not on queue The "not on queue" error sounds more like a bug in xhci(4). Could you please try to disable USB3 in the BIOS an see if the problem resolves then. And in XConsole : umb0 detached ucom0 detached umodem0 detached uhub0: port 10, set config 0 at addr 5 failed uhub0: device problem, disabling port 10 A detaching module is bad. Either it had a brownout or the firmware crashed. Gerhard
Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
On 2020-06-13 01:24, Łukasz Lejtkowski wrote:
Good news - no more kernel panics on USB 3.0(xHCI), it’s fixed.
Bad news - after 2-3h LTE modem lost local network connection via USB
3.0(cdce0). I have to remove modem and put it back to usb port - then
local network connection between OpenBSD and modem back for 2-3h,
sometimes 30-40 min. It looks like the same problem as kernel panic, but
this time there is lost network connection via usb 3.0(xhci).
root@master[~]ping 192.168.8.1
PING 192.168.8.1 (192.168.8.1): 56 data bytes
ping: sendmsg: Network is down
ping: wrote 192.168.8.1 64 chars, ret=-1
ping: sendmsg: Network is down
ping: wrote 192.168.8.1 64 chars, ret=-1
192.168.8.1 is default static IP on lte modem.
Your changes in if_cdce.c 1.77 not completely fix the problem.
Hi,
yes, my patch just targeted to fix the panic as a reaction to USB
problems; not the USB problems themself.
Does it recover after doing
# ifconfig cdcef0 down
# ifconfig cdcef0 up
Gerhard
On 11 Jun 2020, at 11:13, Łukasz Lejtkowski <mailto:emig...@gmail.com>> wrote:
Hi Gerhard,
Today I added Your patches to 6.7-stable and moved back LTE modem to
USB 3.0. So, just waiting for… nothing or kernel panic. I’ll let you
know.
On 8 Jun 2020, at 19:13, Patrick Wildt <mailto:patr...@blueri.se>> wrote:
On Mon, Jun 08, 2020 at 05:31:44PM +0200, Gerhard Roth wrote:
On 2020-05-25 13:19, Martin Pieuchot wrote:
On 25/05/20(Mon) 12:56, Gerhard Roth wrote:
On 5/22/20 9:05 PM, Mark Kettenis wrote:
From: Łukasz Lejtkowski <mailto:emig...@gmail.com>>
Date: Fri, 22 May 2020 20:51:57 +0200
Probably power supply 12 V is broken. Showing 16,87 V(Fluke 179) -
too high. Should be 12,25-12,50 V. I replaced to the new one.
That might be why the device stops responding. The fact that
cleaning
up from a failed USB transaction leads to this panic is a bug though.
And somebody just posted a very similar panic with ure(4). Something
in the network stack is holding a mutex when it shouldn't.
I think that holding the mutex is ok. The bug is calling the stop
routine in case of errors.
This is what common foo_start() does:
m_head = ifq_deq_begin(>if_snd);
if (foo_encap(sc, m_head, 0)) {
ifq_deq_rollback(>if_snd, m_head);
...
return;
}
ifq_deq_commit(>if_snd, m_head);
Here, ifq_deq_begin() grabs a mutex and it is held while
calling foo_encap().
For USB network interfaces foo_encap() mostly does this:
err = usbd_transfer(sc->sc_xfer);
if (err != USBD_IN_PROGRESS) {
foo_stop(sc);
return EIO;
}
And foo_stop() calls usbd_abort_pipe() -> xhci_command_submit(),
which might sleep.
How to fix? We could do the foo_encap() after the ifq_deq_commit(),
possibly dropping the current mbuf if encap fails (who cares
for the packets after foo_stop() anyway).
That's the approach taken by drivers using ifq_dequeue(9) instead of
ifq_deq_begin/commit().
Or change all the drivers to follow the path that if_aue.c takes:
err = usbd_transfer(c->aue_xfer);
if (err != USBD_IN_PROGRESS) {
...
/* Stop the interface from process context. */
usb_add_task(sc->aue_udev, >aue_stop_task);
return (EIO);
}
That's just trading the current problem for another one with higher
complexity.
Any ideas, what's better? Or alternative proposals?
Using ifq_dequeue(9) would have the advantage of unifying the code
base.
It introduces a behavior change. A simpler fix would be to call
foo_stop() in the error path after ifq_deq_rollback().
Hi,
two weeks passed any nobody objected Martin's proposal. So I thought,
we could try to move on this way.
Gerhard
From what I remember from various discussions, the goal should be to
check if there's a buffer free in the ring, then dequeue and send, and
it it can't be sent out, then drop it. With USB apparently those
drivers "always" have an open buffer, so we can just dequeue and send,
like you do in this diff. And if it gets dropped, that's fine.
That said, I think IFQ_DEQUEUE() is old compat code, and we actually
nowadays prefer:
m_head = ifq_dequeue(>if_snd);
If you look at the define for IFQ_DEQUEUE() you'll see it's marked
as compat code. If you look at a new driver, like ixl(4), you'll
see that it also uses ifq_dequeue().
Sorry to to give you some work, but with that fixed: ok patrick@
Patrick
Index: sys/dev/usb/if_axe.c
===
RCS file: /cvs/src/sys/dev/usb/if_axe.c,v
retrieving revision 1.139
diff -u -p -u -p -r1.139 if_axe.c
--- sys/dev/usb/if_axe.c7 Jul 2019 06:40:10 -1.139
+++ sys/dev/usb/if_axe.c8 Jun 2020 15:13:25 -
@@ -1223,6 +1223,7 @@ axe_encap(struct axe_softc *sc, struct m
/* Transmit */
err = usbd_transfer(c->axe_xfer);
if (err != USBD_IN_PROGRESS) {
+c->axe_mbuf = NULL;
axe_stop(sc);
return(EIO);
}
@@ -1246,16 +1247,15 @@ axe_start(struct ifnet *ifp)
if (ifq_is_oactive(>if_snd))
return;
-m_head = ifq_deq_begin(>if_snd);
Re: 6.7-stable server crashes after ~1-2 days uptime: USB3 panic
Hi Matthias,
I just committed if_cdcef.c, rev 1.77. That should fix the panic.
However, the cdce(4) interface will still stop sending. But that
may be due to some problem with the USB network adapter.
Gerhard
On 2020-06-07 14:57, Matthias wrote:
Synopsis: 6.7-stable USB3 panic: assertwaitok: non-zero mutex count: 1
Category: kernel
Environment:
System : OpenBSD 6.7
Details : OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun 4 09:55:08 MDT 2020
r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architecture: OpenBSD.amd64
Machine : amd64
Description:
After ~1-2 days the server crashes. The USB3 network adapters (cdce)
appear to be involved as this does not happen on a USB2-only backup server
running 6.7-stable. This also did not happen with 6.6-stable. I saw similar
crash reports on bugs@ recently. Just sending this as it may contain additional
information.
ddb{0}> show panic
assertwaitok: non-zero mutex count: 1
ddb{0}> trace
db_enter() at db_enter+0x10
panic(81c8c2a4) at panic+0x128
assertwaitok() at assertwaitok+0xc7
mi_switch() at mi_switch+0x40
sleep_finish(800020230cd8,1) at sleep_finish+0x84
sleep_finish_all(800020230cd8,1) at sleep_finish_all+0x21
tsleep(80130750,16,81c98204,33) at tsleep+0xd6
xhci_command_submit(8011b000,800020230dc8,1dcd6500) at xhci_command
_submit+0x13f
xhci_abort_xfer(fd817f89c3c0,6) at xhci_abort_xfer+0x13a
usbd_abort_pipe(80a5e000) at usbd_abort_pipe+0x3d
cdce_stop(803cb000) at cdce_stop+0x46
cdce_encap(803cb000,fd801d501a00,0) at cdce_encap+0xf7
cdce_start(803cb048) at cdce_start+0x84
if_qstart_compat(803cb2c0) at if_qstart_compat+0x2e
ifq_serialize(803cb2c0,803cb390) at ifq_serialize+0x103
taskq_thread(8003a0c0) at taskq_thread+0x4d
end trace frame: 0x0, count: -16
ddb{0}> ps
PID TID PPIDUID S FLAGS WAIT COMMAND
12486 298693 1 0 30x100083 ttyin getty
99434 183909 1 0 30x100083 ttyin getty
60013 239089 1 0 30x100083 ttyin getty
81607 450582 1 0 30x100083 ttyin getty
57630 349299 1 0 30x100083 ttyin getty
40564 404576 1 0 30x100083 ttyin getty
40014 41691 1 0 30x100098 poll cron
50279 381075 1 99 30x100090 poll sndiod
91619 288003 1110 30x100090 poll sndiod
53415 129112 1109 30x90 kqreadftp-proxy
14622 25396 58826 95 30x100092 kqreadsmtpd
39273 386691 58826103 30x100092 kqreadsmtpd
48966 71880 58826 95 30x100092 kqreadsmtpd
28228 40707 58826 95 30x100092 kqreadsmtpd
826484150 58826 95 30x100092 kqreadsmtpd
10338 135224 58826 95 30x100092 kqreadsmtpd
58826 247890 1 0 30x100080 kqreadsmtpd
12615 212381 1 77 30x100090 poll dhcpd
85979 509198 1 0 30x80 selectsshd
48139 519425 1 0 30x100080 poll ntpd
59931 362850 1640 83 30x100092 poll ntpd
1640 206706 1 83 30x100092 poll ntpd
38615 84215 1 53 30x90 kqreadunbound
130 438640 43856 74 30x100092 bpf pflogd
43856 416242 1 0 30x80 netio pflogd
5225 84596 8634 73 30x100090 kqreadsyslogd
8634 40345 1 0 30x100082 netio syslogd
17797 33595 87133115 30x100092 kqreadslaacd
97226 141252 87133115 30x100092 kqreadslaacd
87133 292818 1 0 30x100080 kqreadslaacd
40953 507895 0 0 3 0x14280 schto i915/signal:6
35819 13695 0 0 3 0x14280 schto i915/signal:2
57548 409063 0 0 3 0x14280 schto i915/signal:1
13585 303805 0 0 3 0x14280 schto i915/signal:0
90572 387925 0 0 3 0x14200 bored i915-userptr-acq
7972 404423 0 0 3 0x14200 bored i915_modeset
64027 472769 0 0 3 0x14200 bored i915-dp
63546 416859 0 0 3 0x14200 bored i915
65809 163493 0 0 3 0x14200 bored smr
18923 16924 0 0 3 0x14200 pgzerozerothread
49603 391724 0 0 3 0x14200 aiodoned aiodoned
5278 258120 0 0 3 0x14200 syncerupdate
85919 506000 0 0 3 0x14200 cleaner cleaner
18761 448463 0 0 3
Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
On 2020-05-25 13:19, Martin Pieuchot wrote:
On 25/05/20(Mon) 12:56, Gerhard Roth wrote:
On 5/22/20 9:05 PM, Mark Kettenis wrote:
From: Łukasz Lejtkowski
Date: Fri, 22 May 2020 20:51:57 +0200
Probably power supply 12 V is broken. Showing 16,87 V(Fluke 179) -
too high. Should be 12,25-12,50 V. I replaced to the new one.
That might be why the device stops responding. The fact that cleaning
up from a failed USB transaction leads to this panic is a bug though.
And somebody just posted a very similar panic with ure(4). Something
in the network stack is holding a mutex when it shouldn't.
I think that holding the mutex is ok. The bug is calling the stop
routine in case of errors.
This is what common foo_start() does:
m_head = ifq_deq_begin(>if_snd);
if (foo_encap(sc, m_head, 0)) {
ifq_deq_rollback(>if_snd, m_head);
...
return;
}
ifq_deq_commit(>if_snd, m_head);
Here, ifq_deq_begin() grabs a mutex and it is held while
calling foo_encap().
For USB network interfaces foo_encap() mostly does this:
err = usbd_transfer(sc->sc_xfer);
if (err != USBD_IN_PROGRESS) {
foo_stop(sc);
return EIO;
}
And foo_stop() calls usbd_abort_pipe() -> xhci_command_submit(),
which might sleep.
How to fix? We could do the foo_encap() after the ifq_deq_commit(),
possibly dropping the current mbuf if encap fails (who cares
for the packets after foo_stop() anyway).
That's the approach taken by drivers using ifq_dequeue(9) instead of
ifq_deq_begin/commit().
Or change all the drivers to follow the path that if_aue.c takes:
err = usbd_transfer(c->aue_xfer);
if (err != USBD_IN_PROGRESS) {
...
/* Stop the interface from process context. */
usb_add_task(sc->aue_udev, >aue_stop_task);
return (EIO);
}
That's just trading the current problem for another one with higher
complexity.
Any ideas, what's better? Or alternative proposals?
Using ifq_dequeue(9) would have the advantage of unifying the code base.
It introduces a behavior change. A simpler fix would be to call
foo_stop() in the error path after ifq_deq_rollback().
Hi,
two weeks passed any nobody objected Martin's proposal. So I thought,
we could try to move on this way.
Gerhard
Index: sys/dev/usb/if_axe.c
===
RCS file: /cvs/src/sys/dev/usb/if_axe.c,v
retrieving revision 1.139
diff -u -p -u -p -r1.139 if_axe.c
--- sys/dev/usb/if_axe.c7 Jul 2019 06:40:10 - 1.139
+++ sys/dev/usb/if_axe.c8 Jun 2020 15:13:25 -
@@ -1223,6 +1223,7 @@ axe_encap(struct axe_softc *sc, struct m
/* Transmit */
err = usbd_transfer(c->axe_xfer);
if (err != USBD_IN_PROGRESS) {
+ c->axe_mbuf = NULL;
axe_stop(sc);
return(EIO);
}
@@ -1246,16 +1247,15 @@ axe_start(struct ifnet *ifp)
if (ifq_is_oactive(>if_snd))
return;
- m_head = ifq_deq_begin(>if_snd);
+ IFQ_DEQUEUE(>if_snd, m_head);
if (m_head == NULL)
return;
if (axe_encap(sc, m_head, 0)) {
- ifq_deq_rollback(>if_snd, m_head);
+ m_freem(m_head);
ifq_set_oactive(>if_snd);
return;
}
- ifq_deq_commit(>if_snd, m_head);
/*
* If there's a BPF listener, bounce a copy of this frame
Index: sys/dev/usb/if_axen.c
===
RCS file: /cvs/src/sys/dev/usb/if_axen.c,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 if_axen.c
--- sys/dev/usb/if_axen.c 7 Jul 2019 06:40:10 - 1.27
+++ sys/dev/usb/if_axen.c 8 Jun 2020 14:49:26 -
@@ -1186,6 +1186,7 @@ axen_encap(struct axen_softc *sc, struct
/* Transmit */
err = usbd_transfer(c->axen_xfer);
if (err != USBD_IN_PROGRESS) {
+ c->axen_mbuf = NULL;
axen_stop(sc);
return EIO;
}
@@ -1209,16 +1210,15 @@ axen_start(struct ifnet *ifp)
if (ifq_is_oactive(>if_snd))
return;
- m_head = ifq_deq_begin(>if_snd);
+ IFQ_DEQUEUE(>if_snd, m_head);
if (m_head == NULL)
return;
if (axen_encap(sc, m_head, 0)) {
- ifq_deq_rollback(>if_snd, m_head);
+ m_freem(m_head);
ifq_set_oactive(>if_snd);
return;
}
- ifq_deq_commit(>if_snd, m_head);
/*
* If there's a BPF listener, bounce a copy of this frame
Index: sys/dev/usb/if_cdce.c
===
RCS file: /cvs/src/sys/dev/usb/if_cdce.c,v
retrieving revision 1.76
diff -u -p -u -p -r1.76 if_cdce.c
--- sys/
Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
On 5/22/20 9:05 PM, Mark Kettenis wrote:
From: Łukasz Lejtkowski
Date: Fri, 22 May 2020 20:51:57 +0200
Probably power supply 12 V is broken. Showing 16,87 V(Fluke 179) -
too high. Should be 12,25-12,50 V. I replaced to the new one.
That might be why the device stops responding. The fact that cleaning
up from a failed USB transaction leads to this panic is a bug though.
And somebody just posted a very similar panic with ure(4). Something
in the network stack is holding a mutex when it shouldn't.
I think that holding the mutex is ok. The bug is calling the stop
routine in case of errors.
This is what common foo_start() does:
m_head = ifq_deq_begin(>if_snd);
if (foo_encap(sc, m_head, 0)) {
ifq_deq_rollback(>if_snd, m_head);
...
return;
}
ifq_deq_commit(>if_snd, m_head);
Here, ifq_deq_begin() grabs a mutex and it is held while
calling foo_encap().
For USB network interfaces foo_encap() mostly does this:
err = usbd_transfer(sc->sc_xfer);
if (err != USBD_IN_PROGRESS) {
foo_stop(sc);
return EIO;
}
And foo_stop() calls usbd_abort_pipe() -> xhci_command_submit(),
which might sleep.
How to fix? We could do the foo_encap() after the ifq_deq_commit(),
possibly dropping the current mbuf if encap fails (who cares
for the packets after foo_stop() anyway).
Or change all the drivers to follow the path that if_aue.c takes:
err = usbd_transfer(c->aue_xfer);
if (err != USBD_IN_PROGRESS) {
...
/* Stop the interface from process context. */
usb_add_task(sc->aue_udev, >aue_stop_task);
return (EIO);
}
Any ideas, what's better? Or alternative proposals?
Gerhard
On 22 May 2020, at 20:05, Łukasz Lejtkowski wrote:
30 min ago… :/
OpenBSD/amd64 (master.bsdxxx.xx) (tty00)
login: panic: assertwaitok: non-zero mutex count: 1
Stopped at db_enter+0x10: popq%rbp
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
db_enter() at db_enter+0x10
panic(81c882c4) at panic+0x128
assertwaitok() at assertwaitok+0xc7
mi_switch() at mi_switch+0x40
sleep_finish(8000225b8538,1) at sleep_finish+0x84
sleep_finish_all(8000225b8538,1) at sleep_finish_all+0x21
tsleep(800b1750,16,81c95c7d,33) at tsleep+0xd6
xhci_command_submit(8009c000,8000225b8628,1dcd6500) at xhci_command
_submit+0x13f
xhci_abort_xfer(fd812e90c780,6) at xhci_abort_xfer+0x13a
usbd_abort_pipe(8047b000) at usbd_abort_pipe+0x3d
cdce_stop(8012d000) at cdce_stop+0x46
cdce_encap(8012d000,fd80c0731d00,0) at cdce_encap+0xf7
cdce_start(8012d048) at cdce_start+0x84
if_qstart_compat(8012d2c0) at if_qstart_compat+0x2e
end trace frame: 0x8000225b8840, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{2}>
On 22 May 2020, at 15:58, Łukasz Lejtkowski wrote:
Hi everyone,
After a few hours OpenBSD 6.7 crashes to ddb> . Without a LTE modem OpenBSD 6.7
works stable. Huawei E3372s-153 HiLink on OpenBSD 6.6 works perfectly, stable.
Something wrong with USB, xHCI or cdce on OpenBSD 6.7 imho.
ddb{2}> show panic
assertwaitok: non-zero mutex count: 1
ddb{2}> trace
db_enter() at db_enter+0x10
panic(81c8ec25) at panic+0x128
assertwaitok() at assertwaitok+0xc7
mi_switch() at mi_switch+0x40
sleep_finish(8000225b8f88,1) at sleep_finish+0x84
sleep_finish_all(8000225b8f88,1) at sleep_finish_all+0x21
tsleep(800a5750,16,81c99248,33) at tsleep+0xd6
xhci_command_submit(8009,8000225b9078,1dcd6500) at xhci_command
_submit+0x13f
xhci_abort_xfer(fd811e918690,6) at xhci_abort_xfer+0x13a
usbd_abort_pipe(8045f000) at usbd_abort_pipe+0x3d
cdce_stop(80119000) at cdce_stop+0x46
cdce_encap(80119000,fd80df8b8400,0) at cdce_encap+0xf7
cdce_start(80119048) at cdce_start+0x84
if_qstart_compat(801192c0) at if_qstart_compat+0x2e
ifq_serialize(801192c0,80119390) at ifq_serialize+0x103
taskq_thread(800290c0) at taskq_thread+0x4d
end trace frame: 0x0, count: -16
PC Engines apu2
coreboot build 20202604
BIOS version v4.11.0.6
4080 MB ECC DRAM
SeaBIOS (version rel-1.12.1.3-0-g300e8b70)
root@master[~]usbdevs -v
Controller /dev/usb0:
addr 01: 1022: AMD, xHCI root hub
super speed, self powered, config 1, rev 1.00
driver: uhub0
addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
high speed, self powered, config 1, rev 1.02
driver: cdce0
driver: umass0
Controller /dev/usb1:
addr 01: 1022: AMD, EHCI root hub
high speed, self powered, config 1, rev 1.00
driver: uhub1
addr 02: 0438:7900 Advanced Micro Devices, Hub
high speed, self powered, config 1, rev 0.18
driver: uhub2
Re: umb device no longer detected
Hi Lee, thank you very much for your generous offer. But I don't think this is needed. I think the umsm(4) vs. umb(4) attach problem can be attacked without having this specific device as it happens with other Sierra Wireless devices, too. Theo had a M7700 that would not attach a umb(4) but as I understood, yours it not one of these (since you were aready working on MBIM auth with it). So this problem can't be attacked with the device from your machine. And the behavior of the one from Yahoo is unknown. Gerhard On Thu, 06 Feb 2020 11:04:02 +0900 "Lee B" wrote: > Hello Gerhard, > > Theo asked me if I could get one of these devices to you. I have two choices: > > 1. Pick up the one on Yahoo Auctions (I'm in Tokyo) and send it. > > 2. Remove the one in my machine and send it. > > I'm easy either way (I won't be actively using mine until I can finish off > the > umb authentication patches). The one on Yahoo might need unlocking though - > it > seems to be a bit hit-and-miss as to whether they're locked or not. > > Let me know what you want to do. > > Lee. > > On Wed Feb 5, 2020 at 2:32 PM, Gerhard Roth wrote: > > On Wed, 05 Feb 2020 05:55:41 -0700 "Theo de Raadt" > > wrote: > > > Well, I have been given this particilular MC7700 which works as umsm, > > > but it does *NOT* match as umb, probably because it's firmware is too > > > old? Or it is in the wrong mode, I can't tell. > > > > > > The current mode can be queried with > > > > > > AT!UDUSBCOMP? > > > > > > And > > > > > > AT!UDUSBCOMP=? > > > > > > should give a list of supported interface compositions. > > > > > > My guess is that the device is in a mode that offers multiple > > interfaces. > > And MBIM is on config #2. > > > > > > Since umsm now matches on config #1, usbd_probe_and_attach() stops here > > and never probes config #2 (like it did before). > > > > > > It would be interesting if config #2 offers an AT-interfac (umsm), too. > > In that case umsm and umb could coexist. > > > > > > > > > > Gerhard > > > > > > > > > > > > > > > The alternative is that the device cannot attach at all. > > > > > > How does this get resolved? I can dig it up and show in a few days. > > > > > > Gerhard Roth wrote: > > > > > > > On Wed, 5 Feb 2020 19:54:01 +0900 leeb wrote: > > > > > >Synopsis:umb device no longer detected > > > > > >Category:kernel > > > > > >Environment: > > > > > System : OpenBSD 6.6 > > > > > Details : OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 > > > > > 20:23:40 JST 2020 > > > > > > > > > > lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP > > > > > > > > > > Architecture: OpenBSD.amd64 > > > > > Machine : amd64 > > > > > >Description: > > > > > Before reworking my umb authentication patches I upgraded > > > > > my -current, and found that the LTE modem was no longer > > > > > detected as a umb device. It seems to be picked up later > > > > > in the boot via umsm, but I don't think that should be > > > > > happening. > > > > > > > > That comes from https://marc.info/?l=openbsd-cvs=157878261716342=2 > > > > > > > > It's not that 'umsm picks up the device later', it's just that > > > > umsm_match() [UMATCH_VENDOR_IFACESUBCLASS] now wins over umb_match() > > > > [UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO]. > > > > > > > > Gerhard > > > > > > > > > > > > > > I happened to have an older working -current kernel saved, > > > > > so tried booting from that - the umb device is detected OK. > > > > > > > > > > To eliminate the possibility of a mistake on my part, I > > > > > swapped disks in this machine and installed a fresh current > > > > > snapshot. Same result. I've attached below the sendbug > > > > > outputs from both the working (old) kernel, and the new > > > > > (not working) kernel. > > > > > > > > > > I installed the clean -current from an image at: > >
Re: umb device no longer detected
On Wed, 05 Feb 2020 05:55:41 -0700 "Theo de Raadt" wrote: > Well, I have been given this particilular MC7700 which works as umsm, > but it does *NOT* match as umb, probably because it's firmware is too > old? Or it is in the wrong mode, I can't tell. The current mode can be queried with AT!UDUSBCOMP? And AT!UDUSBCOMP=? should give a list of supported interface compositions. My guess is that the device is in a mode that offers multiple interfaces. And MBIM is on config #2. Since umsm now matches on config #1, usbd_probe_and_attach() stops here and never probes config #2 (like it did before). It would be interesting if config #2 offers an AT-interfac (umsm), too. In that case umsm and umb could coexist. Gerhard > The alternative is that the device cannot attach at all. > > How does this get resolved? I can dig it up and show in a few days. > > Gerhard Roth wrote: > > > On Wed, 5 Feb 2020 19:54:01 +0900 leeb wrote: > > > >Synopsis:umb device no longer detected > > > >Category:kernel > > > >Environment: > > > System : OpenBSD 6.6 > > > Details : OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 20:23:40 > > > JST 2020 > > > > > > lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP > > > > > > Architecture: OpenBSD.amd64 > > > Machine : amd64 > > > >Description: > > > Before reworking my umb authentication patches I upgraded > > > my -current, and found that the LTE modem was no longer > > > detected as a umb device. It seems to be picked up later > > > in the boot via umsm, but I don't think that should be > > > happening. > > > > That comes from https://marc.info/?l=openbsd-cvs=157878261716342=2 > > > > It's not that 'umsm picks up the device later', it's just that > > umsm_match() [UMATCH_VENDOR_IFACESUBCLASS] now wins over umb_match() > > [UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO]. > > > > Gerhard > > > > > > > > I happened to have an older working -current kernel saved, > > > so tried booting from that - the umb device is detected OK. > > > > > > To eliminate the possibility of a mistake on my part, I > > > swapped disks in this machine and installed a fresh current > > > snapshot. Same result. I've attached below the sendbug > > > outputs from both the working (old) kernel, and the new > > > (not working) kernel. > > > > > > I installed the clean -current from an image at: > > > ftp.jaist.ac.jp in /OpenBSD/snapshots/amd64/install66.fs > > > > > > Ran 'sysupgrade -s' on the new install to make sure I was > > > up-to-date. > > > > > > >How-To-Repeat: > > > Install or upgrade to latest snapshot on a machine with a > > > umb device. > > > > > > ** sendbug -P output from OK kernel * > > > > > > dmesg: > > > OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 20:23:40 JST 2020 > > > lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP > > > real mem = 16972566528 (16186MB) > > > avail mem = 16445722624 (15683MB) > > > mpath0 at root > > > scsibus0 at mpath0: 256 targets > > > mainbus0 at root > > > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries) > > > bios0: vendor LENOVO version "G2ET92WW (2.52 )" date 02/22/2013 > > > bios0: LENOVO 23061Q2 > > > acpi0 at bios0: ACPI 5.0 > > > acpi0: sleep states S0 S3 S4 S5 > > > acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT > > > ASF! UEFI UEFI POAT SSDT SSDT UEFI DBG2 BGRT > > > acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) > > > EHC1(S3) EHC2(S3) HDEF(S4) > > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > > acpihpet0 at acpi0: 14318179 Hz > > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > > cpu0 at mainbus0: apid 0 (boot processor) > > > cpu0: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.78 MHz, 06-3a-09 > > > cpu0: > > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > > cpu0: 256KB 64b/line 8-way L2 cache >
Re: umb device no longer detected
On Wed, 5 Feb 2020 19:54:01 +0900 leeb wrote: > >Synopsis:umb device no longer detected > >Category:kernel > >Environment: > System : OpenBSD 6.6 > Details : OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 20:23:40 > JST 2020 > > lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > Before reworking my umb authentication patches I upgraded > my -current, and found that the LTE modem was no longer > detected as a umb device. It seems to be picked up later > in the boot via umsm, but I don't think that should be > happening. That comes from https://marc.info/?l=openbsd-cvs=157878261716342=2 It's not that 'umsm picks up the device later', it's just that umsm_match() [UMATCH_VENDOR_IFACESUBCLASS] now wins over umb_match() [UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO]. Gerhard > > I happened to have an older working -current kernel saved, > so tried booting from that - the umb device is detected OK. > > To eliminate the possibility of a mistake on my part, I > swapped disks in this machine and installed a fresh current > snapshot. Same result. I've attached below the sendbug > outputs from both the working (old) kernel, and the new > (not working) kernel. > > I installed the clean -current from an image at: > ftp.jaist.ac.jp in /OpenBSD/snapshots/amd64/install66.fs > > Ran 'sysupgrade -s' on the new install to make sure I was > up-to-date. > > >How-To-Repeat: > Install or upgrade to latest snapshot on a machine with a > umb device. > > ** sendbug -P output from OK kernel * > > dmesg: > OpenBSD 6.6-current (GENERIC.MP) #8: Tue Jan 14 20:23:40 JST 2020 > lee@x230.tanmatsu.local:/sys/arch/amd64/compile/GENERIC.MP > real mem = 16972566528 (16186MB) > avail mem = 16445722624 (15683MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries) > bios0: vendor LENOVO version "G2ET92WW (2.52 )" date 02/22/2013 > bios0: LENOVO 23061Q2 > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT > ASF! UEFI UEFI POAT SSDT SSDT UEFI DBG2 BGRT > acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) > EHC2(S3) HDEF(S4) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.78 MHz, 06-3a-09 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.36 MHz, 06-3a-09 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 1, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: Intel(R) Core(TM) i3-3120M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09 > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu3: 256KB 64b/line 8-way L2 cache > cpu3:
