-
Notifications
You must be signed in to change notification settings - Fork 379
Add additional waitforidle into archiveloop #968
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main-dev
Are you sure you want to change the base?
Conversation
Prevent disconnecting USB drive while write is in progress. Add waitforidle before archive_clips snapshot.
@@ -907,6 +908,7 @@ do | |||
# take a snapshot before archive_clips starts deleting files | |||
if has_cam_disk | |||
then | |||
/root/bin/waitforidle || true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems unrelated to the USB error you mentioned in issue #966, since taking a snapshot doesn't make the drive unavailable to the car. The "consistency of snapshot" you mention in that issue doesn't really matter because a subsequent snapshot will see the full file(s).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doesn't really matter because a subsequent snapshot will see the full file(s)
So what is purpose of waitforidle
in periodic snapshots?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doesn't really matter because a subsequent snapshot will see the full file(s)
So what is purpose of
waitforidle
in periodic snapshots?
I mainly added the waitforidle
script to see if it would have any effect on the "USB too slow" messages that people were reporting way back in 2019. It didn't have any clear effects, but it seemed like it would be a good idea in theory, so I left it in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, so decision is on your side. Just tell me if I should remove this from my pull request.
I like "clean logic", in this case use waitforidle
before every snapshot or remove all occurrences - but this is just my "clean logic".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can leave this in
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Never mind clean logic or what not. You're saying this in fact does clear the silent USB errors every time?
@marcone during the snapshot, cp camdisk.bin
could foreseeably interfere with the recording and writing operation of camdisk.bin
for a fraction of time, unless it was locked down. No?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Never mind clean logic or what not. You're saying this in fact does clear the silent USB errors every time?
This particular waitforidle is meant to avoid snapshotting the drive image while files are partially written.
The waitforidle that was added in the disconnect_usb_drives_from_host
function is meant to avoid the USB error that Tessie is apparently reporting.
@marcone during the snapshot,
cp camdisk.bin
could foreseeably interfere with the recording and writing operation ofcamdisk.bin
for a fraction of time, unless it was locked down. No?
No. Taking a snapshot doesn't make a full copy of the drive image, it just updates some filesystem metadata and as such is very fast. Moreover, the writes that the car does to the emulated USB drive are decoupled from the writes that the Pi does to the underlying file, so the car can continue to write even if writes to the Pi's filesystem were to be briefly stalled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After latest update (2025.20.3), UI_a112_badUSBDevice is back every time, so my "fix" is no more working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well there's that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So from last 2-3 days, every return home and connection to archive leads to UI_a112_badUSBDevice
, even there is no clip to sync, so "disk outage" is minimal.
@marcone does it make sense to implement this now? Firmware error is there, but this can help to not disconnect disk from car during write.
@@ -304,6 +304,7 @@ function fix_errors_in_images () { | |||
|
|||
function disconnect_usb_drives_from_host () { | |||
log "Disconnecting usb from host..." | |||
/root/bin/waitforidle || true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current "waitforidle" script can introduce significant delays, so I'm hesitant to just use it as a matter of course. Does the "UI_a112_badUSBDevice" error you're seeing actually cause problems, or is it just a message in the notifications list in the car? I have never seen this message (but I'm on an older firmware version), so if anything I would prefer these additional calls to be optional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ref: #966
waitforidle
before archive_clips snapshot (after "Archive is reachable")