On Fri, Nov 24, 2017 at 11:08:25AM +0000, Stuart Henderson wrote: > > booted under openbsd. The umb driver doesn't support accessing the card > > directly for debugging and diagnostics? > > Correct, you can't get at those from OpenBSD atm.
That's a bummer; guess you wouldn't care too much if things were working :), but when you're trying to sort out why they're not it sure would be nice. Then if you're placing an external antenna the signal strength readings are cool. > I don't have it handy to check now, but IIRC that's similar to what I > see on MC8805 after adding the ID for fcc auth. Interestingly, I tried the card in an external miniPCI to USB adapter, and it worked fine? Without any driver changes or adding the fcc auth ID. But when the card is installed directly in the system it doesn't work :(. But it works fine under Linux, so it's not that the system hardware is broken or incompatible. It's a PC Engines APU 3, maybe the OpenBSD USB drivers for this board aren't working quite right? With the external adapter, the driver sends the MBIM_OPEN_MSG, gets an interrupt, receives a response, parses the response, and moves on. Installed on the board, the driver sends the MBIM_OPEN_MSG, and then nothing happens. No interrupt, no response, nothing. Jul 23 18:00:35 maggie /bsd: uhub1 at usb1 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00 addr 1 Jul 23 18:00:35 maggie /bsd: uhub2 at uhub1 port 1 configuration 1 interface 0 " Advanced Micro Devices product 0x7900" rev 2.00/0.18 addr 2 Jul 23 18:00:35 maggie /bsd: umb0 at uhub2 port 3 configuration 1 interface 12 " Sierra Wireless, Incorporated Sierra Wireless MC7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev 2.10/0.06 addr 3 It looks like the card is on a stacked hub or something when installed in the box? When it's plugged in on the external adapter: Jul 23 18:15:38 maggie /bsd: umb1 at uhub0 port 4 configuration 1 interface 12 " Sierra Wireless, Incorporated Sierra Wireless MC7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev 2.10/0.06 addr 2 It's connected directly to a controller. They seem to init the same: Jul 23 18:00:35 maggie /bsd: umb0: umb_attach Jul 23 18:00:35 maggie /bsd: umb0: ctrl_len=4096, maxpktlen=1422, cap=0x20 Jul 23 18:00:35 maggie /bsd: umb0: ctrl-ifno#12: ep-ctrl=5, data-ifno#13: ep-rx= 4, ep-tx=3 Jul 23 18:00:35 maggie /bsd: umb0: rx/tx size 16384/16384 Jul 23 18:00:35 maggie /bsd: umb0: umb_open Jul 23 18:00:35 maggie /bsd: umb0: umb_ctrl_msg Jul 23 18:00:35 maggie /bsd: umb0: -> snd MBIM_OPEN_MSG (tid 1) Jul 23 18:00:35 maggie /bsd: umb0: sent MBIM_OPEN_MSG (tid 1) Jul 23 18:00:35 maggie /bsd: 0: 01 00 00 00 10 00 00 00 01 00 00 00 00 10 0 0 00 Jul 23 18:21:20 maggie /bsd: umb1: umb_attach Jul 23 18:21:20 maggie /bsd: umb1: ctrl_len=4096, maxpktlen=1422, cap=0x20 Jul 23 18:21:20 maggie /bsd: umb1: ctrl-ifno#12: ep-ctrl=5, data-ifno#13: ep-rx= 4, ep-tx=3 Jul 23 18:21:20 maggie /bsd: umb1: rx/tx size 16384/16384 Jul 23 18:21:20 maggie /bsd: umb1: umb_open Jul 23 18:21:20 maggie /bsd: umb1: umb_ctrl_msg Jul 23 18:21:20 maggie /bsd: umb1: -> snd MBIM_OPEN_MSG (tid 1) Jul 23 18:21:20 maggie /bsd: umb1: sent MBIM_OPEN_MSG (tid 1) Jul 23 18:21:20 maggie /bsd: 0: 01 00 00 00 10 00 00 00 01 00 00 00 00 10 0 0 00 But it's only when connected externally that the card actually generates an interrupt and sends a response: Jul 23 18:15:48 maggie /bsd: umb1: umb_intr Jul 23 18:15:48 maggie /bsd: umb1: umb_intr: response available Jul 23 18:15:48 maggie /bsd: umb1: umb_get_response_task Jul 23 18:15:48 maggie /bsd: umb1: umb_decode_response Jul 23 18:15:48 maggie /bsd: umb1: got response: len 16 Any thoughts on how to diagnose what might be a USB driver issue as opposed to an LTE card issue 8-/? Thanks...
