In-Use Glasgows can be interrupted by firmware reload #241
Comments
We can, by claiming an interface. But... there's a chicken-and-egg problem here: the only way we can introduce this interface is by increasing the API level, which means that claiming an interface would require reloading the firmware, which means this very interruption. |
|
Per IRC discussion, it's an edge case that we probably can't do much with. |
|
I actually think we can introduce this feature without significant disruption. But it would need to be carefully considered how. |
|
Can't we just make sure we don't reload firmware on Glasgows already exposing this interface? Sure, ones running old firmware would be reloaded... but that sounds like a problem nobody will ever actually care about. Once your Glasgows are initialized with current firmware it no longer matters. |
That's what API levels are already for! And we still have the problem, because people keep running old firmware and not reflashing it, because the firmware is transparently reloaded to SRAM on every invocation. Essentially, the cause of this issue is the same assumption you made: I also thought this would be "a problem nobody will ever actually care about", but that turned out to not be the case. |
|
But once you're running an applet with up to date software, like OP, it'll already be running the latest firmware, right? If this happened to them it's because their existing run wasn't using an interface, otherwise we would just try to claim it, fail, and not touch that device any more. |
The firmware is reloaded before any interfaces are claimed. |
Then it sounds like an easy fix to claim the interface first, if present, as a mutex, before doing that. |
|
Well... yes, that's what I suggested above? Except we don't have an interface that can be used for this purpose yet. |
|
Sure... I was just confused as to how this was an unfixable problem. Like, just doing that means going from "any concurrent glasgow invocations fail" to "glasgow invocations concurrent with out of date ones fail" which sounds like an obvious 99% fix. |
|
Yep, I was also confused when I closed this issue, which is why I reopened it! |
|
Ok, we're in violent agreement then :) |
|
Actually, I think I came up with a way that is somewhat simpler and works with every firmware version we have: just try to claim every interface that is already exposed before reflashing, then release. (AIUI, on Windows libusb requires exclusive access in first place, so this is never an issue, and on Linux at least one of these claims must fail if the device is in use.) |
On Linux multiple userspace applications can send control requests to a device without being aware of each other. Claim every interface to ensure mutual exclusion with any other application. On other OSes device access is already exclusive. Fixes GlasgowEmbedded#241.
On Linux multiple userspace applications can send control requests to a device without being aware of each other. Claim every interface to ensure mutual exclusion with any other application. On other OSes device access is already exclusive. Fixes GlasgowEmbedded#241.
On Linux multiple userspace applications can send control requests to a device without being aware of each other. Claim every interface to ensure mutual exclusion with any other application. On other OSes device access is already exclusive. Fixes GlasgowEmbedded#241.
On Linux multiple userspace applications can send control requests to a device without being aware of each other. Claim every interface to ensure mutual exclusion with any other application. On other OSes device access is already exclusive. Fixes GlasgowEmbedded#241.
On Linux multiple userspace applications can send control requests to a device without being aware of each other. Claim every interface to ensure mutual exclusion with any other application. On other OSes device access is already exclusive. Fixes GlasgowEmbedded#241.
On Linux multiple userspace applications can send control requests to a device without being aware of each other. Claim every interface to ensure mutual exclusion with any other application. On other OSes device access is already exclusive. Fixes GlasgowEmbedded#241.
On Linux multiple userspace applications can send control requests to a device without being aware of each other. Claim every interface to ensure mutual exclusion with any other application. On other OSes device access is already exclusive. Fixes GlasgowEmbedded#241.
On Linux multiple userspace applications can send control requests to a device without being aware of each other. Claim every interface to ensure mutual exclusion with any other application. On other OSes device access is already exclusive. Fixes #241.
I had previously started a Glasgow collecting data using the SCD30 applet.
I've just connected a second Glasgow to my system and ran
glasgow list(to get the serial for use with--serial), and noticed that the SCD30 Glasgow was interrupted. I also think I saw the following line twice (once for each board, I've lost the output unfortunately).It seems that running
glasgow listreloaded the firmware on the currently busy board, interrupting the applet, and showing the errors below (the last a number of times).I don't know if we can "lock" a device, or determine if it is already use, but this may be worth investigating.
The API level message was introduced in ab21295, and may or may not be related.
I'll look into this further when I have time.
The text was updated successfully, but these errors were encountered: