> Date: Wed, 3 Feb 2021 12:51:02 +0100 > From: Marcus Glocker <mar...@nazgul.ch> > > On Wed, 3 Feb 2021 11:41:17 +0000 > Edd Barrett <e...@theunixzoo.co.uk> wrote: > > > On Wed, Feb 03, 2021 at 11:17:01AM +0000, Stuart Henderson wrote: > > > btw the problem was seen with umb, it's not just ugen. > > > > From mglocker@'s explanation, I understood that it is the ugen driver > > trying to attach to some part of the device that in turn hoses umb for > > the same device? > > > > Maybe I misunderstood. > > That's right. ugen(4) tries to attach to another umb(4) interface, > then fails, and labels the whole umb(4) device dying. I don't know if > all umb(4) devices show this behaviour (I don't have such a device). > But the other thing I was thinking about is whether we should make > umb(4) attach to this other interface as well to prevent ugen(4) to > take control.
Probably not. The umb0 in my x1 for example shows up as: umb0 at uhub0 port 4 configuration 1 interface 0 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" rev 2.00/17.29 addr 2 umodem0 at uhub0 port 4 configuration 1 interface 2 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" rev 2.00/17.29 addr 2 umodem0: data interface 3, has no CM over data, has break umodem0: status change notification available ucom0 at umodem0 And that ucom0 is useful to interact with the modem using AT commands. That is how you interact with the GNSS module for example. So probably ugen(4) should be changed such that it doesn't label the whole device as unusable if somehow attaching to a specific interface fails.
