lv_task_handler can fail to return in high load scenarios, causing watchdog resets
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Ambito
- embedded-iot, operating-systems
Direzione di ricerca
Inizia tracciando lv_task_handler e l’interazione tra DisplayApp/SystemTask descritta nell’issue, quindi riproduci il blocco con un carico di animazione elevato usando una LV_DISPLAY_REFR_PERIOD più breve. Il lavoro è completato quando il gestore delle attività ritorna sotto carico sostenuto e la coda dei messaggi non causa più reset del watchdog.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
The LVGL task handler re-evaluates higher priority tasks after executing lower priority ones
The animation task is higher priority than refresh tasks
If the animation task or refresh task takes a long time, after executing the refresh task the animation task may be ready again
This causes lv_task_handler to infinitely execute animation->refresh->animation->refresh etc without ever returning
If lv_task_handler doesn't return, the DisplayApp message queue becomes full (usually with touchscreen events) and blocks SystemTask, causing watchdog resets
This happens very rarely or even never in standard InfiniTime. But by either decreasing the LV_DISPLAY_REFR_PERIOD and increasing animation load (e.g animation scroll speed for labels in px/s) (I have not tested if both are required to trigger this behaviour, but I know that both are sufficient), it's possible to reproduce this lockup.
I'd suggest that we replace the LVGL task handler with one that provides a hard upper bound on the number of task executions. Perhaps by only executing each task once and exiting early if it's already spent too long doing work (many tasks waiting)? This would allow task priorities to still be usefully enforced. Lower priority refresh tasks might still get starved by animations though.
Possible cause for #2012 (the notification header scrolling animation)
- Lingua principale
- C
- Stelle
- 3.4k
- Fork
- 1.1k
- Merge medio
- 23h 18m
- PR unite (30g)
- 1
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di InfiniTimeOrg/InfiniTime
-
BLE handlers use length fields from the packet without checking how much data arrivedForse già presa @DustinHab l’ha presa 37 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 56/100
InfiniTimeOrg/InfiniTime#2485 ·
-
Unexpected jump back to watch face when button pressedForse già presa @SteveAmor l’ha presa 81 giorni fa. Apertabug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 50/100
InfiniTimeOrg/InfiniTime#2461 · 2 commenti ·
-
Screen doesn't go to sleep after reset countdown appForse già presa @SteveAmor l’ha presa 78 giorni fa. Apertabug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
InfiniTimeOrg/InfiniTime#2419 · 4 commenti ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
InfiniTimeOrg/InfiniTime#2410 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
InfiniTimeOrg/InfiniTime#2407 · 4 commenti ·
Tutte le issue di InfiniTimeOrg/InfiniTime
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
quickjs-ng/quickjs#1836 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
open-quantum-safe/liboqs#2637 ·
I maintainer di solito rispondono entro 1 giorno
-
Go device SDK: Whisper transcriber keeps buffering and transcribing audio appended after Stop()Forse già presa @apoorvdarshan l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
BasedHardware/omi#22770 ·
I maintainer di solito rispondono entro 1 giorno
-
fido_do_ecdh() reports any getKeyAgreement failure as FIDO_ERR_INTERNALForse già presa @brlumen l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
joncampbell123/dosbox-x#6698 ·
I maintainer di solito rispondono entro 1 giorno