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&m=157878261716342&w=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:
Re: umb device no longer detected
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 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&m=157878261716342&w=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: Int
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&m=157878261716342&w=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,MELT
Re: umb device no longer detected
Hmmm. I got mine used off an auction site but unfortunately updated the firmware before installing OpenBSD on this machine. No help there, sorry. Though the latest firmware wasn't all that recent IIRC. Not made any other changes to it apart from that though. Happy to help out with any testing etc. if needed. On Wed, Feb 05, 2020 at 05:55:41AM -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 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. >
Re: umb device no longer detected
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&m=157878261716342&w=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,POPCN
Re: umb device no longer detected
I've told Lee to test something for me. I think the priority from match functions are being confused via these (stupid) UMATCH_* variables, which are some weird disguise for what is supposed to be a priority code. In his upgraded case, ubm should win. it returns UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO which is 5. umsm does fewer tests, and returns UMATCH_VENDOR_IFACESUBCLASS which is 6. So with my change umsm wins. I asked Lee to first test if_umb.c returning a higher value such as UMATCH_VENDOR_IFACESUBCLASS_IFACEPROTO which is 7 On my backwards device, if_umb does not match at all, so umsm would win. If I am right, that would satisfy both old and new devices; I think umb_patch is already doing the correct "tests", but simply returning the wrong value. And if that helps, then I think all this should be reconsidered. I *think* the idea behind this UMATCH_* variable naming is that the match return value says "how many fields did I look at and how confident am I", and that's what the naming comes from, but what I don't understand is --- who cares how many fields you looked at, as far as the subr_conf.c code is concerned this is ONLY a priority code not some "what did I do" to decide thing. And the priority value is going to something more magical, it's not some direct mapping between "how much did you look at". However are a mess of relationships here with the many device need "first kick me off umass", so we need to be somewhat careful to pick at this problem from the correct end.
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&m=157878261716342&w=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:
Re: umb device no longer detected
OK, just rebuilt my kernel:
x230$ grep MC7700 umsm.c
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC7700}, 0},
x230$ diff if_umb.c if_umb.c.~1.31.~
276,277c276
< /* return UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; */
< return UMATCH_VENDOR_IFACESUBCLASS_IFACEPROTO;
---
> return UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO;
x230$ ifconfig umb0
umb0: flags=8810 mtu 1500
index 5 priority 6 llprio 3
roaming disabled registration unknown
state open cell-class none
SIM not initialized PIN required
device MC7700 ID xxx firmware SWI9200X_03.05.19.00Aap
status: down
x230$
My source is not quite at a point to allow me to check the actual
operation of the thing, but it looks good so far...
Lee.
On Wed, Feb 05, 2020 at 07:24:00PM -0700, Theo de Raadt wrote:
> I've told Lee to test something for me.
>
> I think the priority from match functions are being confused via
> these (stupid) UMATCH_* variables, which are some weird disguise for
> what is supposed to be a priority code.
>
> In his upgraded case, ubm should win. it returns
> UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO which is 5.
>
> umsm does fewer tests, and returns UMATCH_VENDOR_IFACESUBCLASS which
> is 6.
>
> So with my change umsm wins.
>
> I asked Lee to first test if_umb.c returning a higher value such as
> UMATCH_VENDOR_IFACESUBCLASS_IFACEPROTO which is 7
>
> On my backwards device, if_umb does not match at all, so umsm would
> win.
>
> If I am right, that would satisfy both old and new devices; I think
> umb_patch is already doing the correct "tests", but simply returning
> the wrong value.
>
> And if that helps, then I think all this should be reconsidered.
>
> I *think* the idea behind this UMATCH_* variable naming is that the
> match return value says "how many fields did I look at and how confident
> am I", and that's what the naming comes from, but what I don't
> understand is --- who cares how many fields you looked at, as far as
> the subr_conf.c code is concerned this is ONLY a priority code not some
> "what did I do" to decide thing. And the priority value is going to
> something more magical, it's not some direct mapping between "how much did
> you look at".
>
> However are a mess of relationships here with the many device need
> "first kick me off umass", so we need to be somewhat careful to pick
> at this problem from the correct end.
>
>
Re: umb device no longer detected
Gerhard Roth wrote: > 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. Yes, it looks like the testing request I sent Lee works :) > 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. I am pretty sure he'd be able to supply you an old one.
Re: umb device no longer detected
leeb wrote:
> OK, just rebuilt my kernel:
>
> x230$ grep MC7700 umsm.c
> {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC7700}, 0},
> x230$ diff if_umb.c if_umb.c.~1.31.~
>
> 276,277c276
> < /* return UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; */
> < return UMATCH_VENDOR_IFACESUBCLASS_IFACEPROTO;
> ---
> > return UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO;
> x230$ ifconfig umb0
> umb0: flags=8810 mtu 1500
> index 5 priority 6 llprio 3
> roaming disabled registration unknown
> state open cell-class none
> SIM not initialized PIN required
> device MC7700 ID xxx firmware SWI9200X_03.05.19.00Aap
> status: down
Exactly as I expected.
The UMATCH_* abstraction confuses people.
Re: umb device no longer detected
I installed MC77xx about three years ago into OpenBSD driven machine. It actively uses everyday with msm mode driver. The question was how to detect UMB and MSM devices and attach suitable driver simultaneously (msm + umb) for single device according to USB descriptors for each possible mode of MC77xx card. I haven't track any repository changes since than and use 7304 in MSM modes only to have WWAN access and NMEA GPS ports simultaneously, but years ago I wanted to use it as UMB device + NMEA. The USB descriptors for all modes of MC7304 and MC7455 are attached. Both cards are used actively so I can test any changes if needed. Denis On 2/5/2020 2:40 PM, leeb wrote: > Hmmm. I got mine used off an auction site but unfortunately updated > the firmware before installing OpenBSD on this machine. No help there, > sorry. Though the latest firmware wasn't all that recent IIRC. > > Not made any other changes to it apart from that though. > > Happy to help out with any testing etc. if needed. > > > On Wed, Feb 05, 2020 at 05:55:41AM -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 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. >> > usb-descriptors.tar.gz Description: application/gzip
Re: umb device no longer detected
Denis wrote: > I installed MC77xx about three years ago into OpenBSD driven machine. It > actively uses everyday with msm mode driver. The question was how to > detect UMB and MSM devices and attach suitable driver simultaneously > (msm + umb) for single device according to USB descriptors for each > possible mode of MC77xx card. > > I haven't track any repository changes since than and use 7304 in MSM > modes only to have WWAN access and NMEA GPS ports simultaneously, but > years ago I wanted to use it as UMB device + NMEA. > > The USB descriptors for all modes of MC7304 and MC7455 are attached. > > Both cards are used actively so I can test any changes if needed. The device itself must be configured to export those capabilities. For old devices we don't know how to do change that. For mid-generation to newer devices, if you force the kernel to not match umb, then com ports may show up. There's some docs out there which allow changing the capabilities which are exposed. But umb_attach interferes and doesn't let you have both. People keep talking about "wouldn't it be nice if I could do that", consider that the source code is available...
Re: umb device no longer detected
> From: "Theo de Raadt" > Date: Thu, 13 Feb 2020 11:50:11 -0700 > > Denis wrote: > > > I installed MC77xx about three years ago into OpenBSD driven machine. It > > actively uses everyday with msm mode driver. The question was how to > > detect UMB and MSM devices and attach suitable driver simultaneously > > (msm + umb) for single device according to USB descriptors for each > > possible mode of MC77xx card. > > > > I haven't track any repository changes since than and use 7304 in MSM > > modes only to have WWAN access and NMEA GPS ports simultaneously, but > > years ago I wanted to use it as UMB device + NMEA. > > > > The USB descriptors for all modes of MC7304 and MC7455 are attached. > > > > Both cards are used actively so I can test any changes if needed. > > The device itself must be configured to export those capabilities. > > For old devices we don't know how to do change that. > > For mid-generation to newer devices, if you force the kernel to not match > umb, then com ports may show up. There's some docs out there which allow > changing the capabilities which are exposed. But umb_attach interferes > and doesn't let you have both. Well, my EM7345 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 In this configuration, ucom0 provides an AT command set interface that provides a (somewhat quirky) NMEA GPS interface.
Re: umb device no longer detected
Mark Kettenis wrote: > Well, my EM7345 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 > > In this configuration, ucom0 provides an AT command set interface that > provides a (somewhat quirky) NMEA GPS interface. Different models will export different capabilities, and a set of AT commands can unlock the capabilities. Including a com port that has a nmea gps stream. Of course that depends on having the com port with the AT command available to begin with, if you don't, it is much more complicated and we don't have software in openbsd which can tweak it at a lower level into the right mode.
Re: umb device no longer detected
As I remembered, I set device functionality by port composition using AT commands trough AT port when device was in factory default msm mode. Sierra provides some special AT commands for MC/EM77xx, 73xx, and 7455 series etc. Of course you can send AT command to a special modem port to enable GLO/GPS, but NMEA output will not work in OpenBSD while your device stays in MBIM mode. As Theo said, currently you can use it configured to MBIM mode which supported by UMB driver OR MSM mode and both modes can't be set in one device simultaneously to have support it by OpenBSD simultaneously. Somebody from developers asked for USB descriptors for 7455 7304 to implement both drivers attach simultaneously. Anyway, you can use an "old" mode using MSM OR MBIM, but without MSM. Some commands to change modes are below: Sierra Wireless EM74xx, MC74xx series module: AT!ENTERCND=”A710” AT!USBCOMP=? AT!USBCOMP? AT!USBCOMP=1,1,100D AT!RESET Sierra Wireless EM73xx, MC73xx series module: AT!ENTERCND=”A710” AT!UDUSBCOMP=? AT!UDUSBCOMP? AT!UDUSBCOMP=6 AT!RESET ADB port enable for Sierra EM/MC73xx AT!OPENLOCK? AT!OPENLOCK="" AT!CUSTOM="ADBENABLE",1 or AT!CUSTOM="ADBENABLE",0 to disable ADB port AT!RESET *** to check ADB port state after changes it is recommended to reconnect modem's power Denis On 2/13/2020 8:04 PM, Theo de Raadt wrote: > Mark Kettenis wrote: > >> Well, my EM7345 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 >> >> In this configuration, ucom0 provides an AT command set interface that >> provides a (somewhat quirky) NMEA GPS interface. > > Different models will export different capabilities, and a set of AT > commands can unlock the capabilities. Including a com port that has > a nmea gps stream. Of course that depends on having the com port with > the AT command available to begin with, if you don't, it is much more > complicated and we don't have software in openbsd which can tweak it > at a lower level into the right mode. >
Re: umb device no longer detected
That's great ... you've copied from a blog and what does it have to do with OpenBSD? Nothing. Denis wrote: > As I remembered, I set device functionality by port composition using AT > commands trough AT port when device was in factory default msm mode. > Sierra provides some special AT commands for MC/EM77xx, 73xx, and 7455 > series etc. > > Of course you can send AT command to a special modem port to enable > GLO/GPS, but NMEA output will not work in OpenBSD while your device > stays in MBIM mode. > > As Theo said, currently you can use it configured to MBIM mode which > supported by UMB driver OR MSM mode and both modes can't be set in one > device simultaneously to have support it by OpenBSD simultaneously. > > Somebody from developers asked for USB descriptors for 7455 7304 to > implement both drivers attach simultaneously. > > Anyway, you can use an "old" mode using MSM OR MBIM, but without MSM. > > Some commands to change modes are below: > > Sierra Wireless EM74xx, MC74xx series module: > AT!ENTERCND=”A710” > AT!USBCOMP=? > AT!USBCOMP? > AT!USBCOMP=1,1,100D > AT!RESET > > Sierra Wireless EM73xx, MC73xx series module: > AT!ENTERCND=”A710” > AT!UDUSBCOMP=? > AT!UDUSBCOMP? > AT!UDUSBCOMP=6 > AT!RESET > > ADB port enable for Sierra EM/MC73xx > > AT!OPENLOCK? > AT!OPENLOCK="" > AT!CUSTOM="ADBENABLE",1 > or AT!CUSTOM="ADBENABLE",0 to disable ADB port > AT!RESET > > *** to check ADB port state after changes it is recommended to reconnect > modem's power > > > Denis > > > On 2/13/2020 8:04 PM, Theo de Raadt wrote: > > Mark Kettenis wrote: > > > >> Well, my EM7345 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 > >> > >> In this configuration, ucom0 provides an AT command set interface that > >> provides a (somewhat quirky) NMEA GPS interface. > > > > Different models will export different capabilities, and a set of AT > > commands can unlock the capabilities. Including a com port that has > > a nmea gps stream. Of course that depends on having the com port with > > the AT command available to begin with, if you don't, it is much more > > complicated and we don't have software in openbsd which can tweak it > > at a lower level into the right mode. > > >
Re: umb device no longer detected
It was marked as "not necessary" to implement both driver for one Sierra device. So work was stopped before begin right on descriptors... On 2/13/2020 8:40 PM, Theo de Raadt wrote: > That's great ... you've copied from a blog and what does it have to do > with OpenBSD? > > Nothing. > > Denis wrote: > >> As I remembered, I set device functionality by port composition using AT >> commands trough AT port when device was in factory default msm mode. >> Sierra provides some special AT commands for MC/EM77xx, 73xx, and 7455 >> series etc. >> >> Of course you can send AT command to a special modem port to enable >> GLO/GPS, but NMEA output will not work in OpenBSD while your device >> stays in MBIM mode. >> >> As Theo said, currently you can use it configured to MBIM mode which >> supported by UMB driver OR MSM mode and both modes can't be set in one >> device simultaneously to have support it by OpenBSD simultaneously. >> >> Somebody from developers asked for USB descriptors for 7455 7304 to >> implement both drivers attach simultaneously. >> >> Anyway, you can use an "old" mode using MSM OR MBIM, but without MSM. >> >> Some commands to change modes are below: >> >> Sierra Wireless EM74xx, MC74xx series module: >> AT!ENTERCND=”A710” >> AT!USBCOMP=? >> AT!USBCOMP? >> AT!USBCOMP=1,1,100D >> AT!RESET >> >> Sierra Wireless EM73xx, MC73xx series module: >> AT!ENTERCND=”A710” >> AT!UDUSBCOMP=? >> AT!UDUSBCOMP? >> AT!UDUSBCOMP=6 >> AT!RESET >> >> ADB port enable for Sierra EM/MC73xx >> >> AT!OPENLOCK? >> AT!OPENLOCK="" >> AT!CUSTOM="ADBENABLE",1 >> or AT!CUSTOM="ADBENABLE",0 to disable ADB port >> AT!RESET >> >> *** to check ADB port state after changes it is recommended to reconnect >> modem's power >> >> >> Denis >> >> >> On 2/13/2020 8:04 PM, Theo de Raadt wrote: >>> Mark Kettenis wrote: >>> Well, my EM7345 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 In this configuration, ucom0 provides an AT command set interface that provides a (somewhat quirky) NMEA GPS interface. >>> >>> Different models will export different capabilities, and a set of AT >>> commands can unlock the capabilities. Including a com port that has >>> a nmea gps stream. Of course that depends on having the com port with >>> the AT command available to begin with, if you don't, it is much more >>> complicated and we don't have software in openbsd which can tweak it >>> at a lower level into the right mode. >>> >> >
Re: umb device no longer detected
Denis wrote: > It was marked as "not necessary" to implement both driver for one Sierra > device. So work was stopped before begin right on descriptors... No what is happening is you keep begging for functionality but not writing it. Do the work or adjust your expectations.
