Skip to content

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

Open
wants to merge 1 commit into
base: main-dev
Choose a base branch
from

Conversation

mhaluska
Copy link

Ref: #966

  • prevent disconnecting USB drive from host while write is in progress
  • add waitforidle before archive_clips snapshot (after "Archive is reachable")

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
Copy link
Owner

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).

Copy link
Author

@mhaluska mhaluska Jun 15, 2025

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?

Copy link
Owner

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.

Copy link
Author

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".

Copy link
Owner

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

Copy link

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?

Copy link
Owner

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 of camdisk.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.

Copy link
Author

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well there's that.

Copy link
Author

@mhaluska mhaluska Jun 17, 2025

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
Copy link
Owner

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not visible on display, but in firmware errors in Tessie. I would like to prevent those errors.
Anyway, let me add it as optional with default disabled.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants