Regression post 1.20220331: blk_update_request: I/O error, dev sr0 #1765
Comments
|
Lucky |
|
It seem unlikely that start.elf firmware could cause an issue like this in the kernel driver (but it's conceivable that some prior setup has had an effect). Best way to confirm this for sure is to manually bisect the firmware. If you look here you can see ~25 firmwares between these two points. Bisecting them should take about 5 steps. For each commit you'll want to download start.elf and fixup.dat and replace the ones on your sdcard. This url is for the March 24 firmware (which should work), but replace the hash (ea4c803/) with each of the bisect points. |
|
Thanks for feedback. I have indeed started bisecting and it failed in the first few changes following 1.20220331. |
|
I can confirm things start to fail after 22/04/13 commit afc7631 ( Note: kernel (and related dtbs, overlays & al) remain 5.15.79 in this test, just rolling back .elf/.dat). |
|
That commit seems surprising. Are you sure that is the first firmware update that has the issue? |
|
Looking at commit messages it's the first with commit message referring to firmware change, following 1.20220331 which is "known-good". |
Yes I double-checked: issue does come-up with afc7631 |
|
It looks as if DTBs are not selected the same way after that afc7631 change. Indeed by defaults How can I check which DTB file is selected on a running system? For records, defauls Alpine |
should include the dtb files loaded. |
|
hum, unfortunately it does not seem to be built on Alpine, while |
|
You can use the vclog utility instead: https://github.com/raspberrypi/utils/tree/master/vclog |
|
Do you have an |
Not available either. Package is built with
No, none are set, as shown in copied config.txt (DTBs are in root of SD aside firmware files and |
|
Just clone the git repo and follow build instructions in README. It only takes a minute to build and has minimal dependencies. |
|
Thanks @popcornmix will try to do so.
Can't we conclude afc7631 change somehow broke default downstream DTBs selection in root FAT filesystem, with no further tests? Let me know if/which further info is needed to help for a fix. |
Based on the evidence you've provided that sounds likely. The commit mentioned ("Support longer file paths") doesn't look blatantly wrong, but it perhaps has caused some unintended change in behaviour. I'm sure once we've reproduced this, the fix will be straightforward. But most of us supporting here are away with family for the holiday period, so we can ask questions to narrow down the issue, but actually stepping through the code with a debugger is unlikely to happen before the office opens next week. It's possible the output of vclog will make it clear how it's failing. |
|
Of course, no hurry: enjoy a great & refreshing family break ! |
|
For records, few pending issues compiling |
|
vclog output in the failing condition is below. |
|
Tried again (twice) after a cold reboot (poweroff + unplugging for 15mn+) with "working" firmware (1.20220331): Does |
|
vclog requires a recent APT (or rpi update stable) release of the firmware in order to discover the location of the log buffer via device tree |
|
uart_2ndstage=1 in config.txt will also emit all of the dt loading message up till the kernel is started via the uart |
|
You may be able to use a static build of vcdbg. See raspberrypi/Raspberry-Pi-OS-64bit#67 (comment) |
|
Thanks. Tests to isolate failing conditions are quite tricky and do not seem as clear-cut as the other day... A bit lost ATM... |
|
The two vcdbg logs are identical (ignoring the timestamps).
Are you sure the preceding commit is 100% working? I could produce some additional firmware builds in between the two versions released just to be sure it is the (internal tree) commit we are assuming, but that only works if you can reliably say whether a build has the issue or not. |
|
It seems system do not always properly recover from eventual: This often occur after CD totally spins down, and If those apps are called with CD already spinning (and no previous lockup), then they operate fine... Could root cause be some power limitation (though Any known command that would just spin-up CD (without reading) I could call prior testing access with |
|
Further refined testing pattern trying to be more immune to transient effects.
With that, apparently no more So, I'd pretend some transient power instabilities may affect CD interface board, and/or USB communication with Pi device under some circumstances, while Pi device itself does not seem affected ( I'll keep monitoring this and eventually close it if all shame is to be put on PSU (though was happy with the original 2.4A so far...).
Thanks for the kind offer, but I'm reluctant to consume more of your time on this, unless you think some of the firmware changes may adversely affect USB communication. |
|
interface details for records (bulk) |
|
is PiZeroW QC3.0 compatible on its OTG port (when host)? |
Uh oh!
There was an error while loading. Please reload this page.
Reading Audio CD seems to fail with recent kernel and post 1.20220331 firmware (on PiZeroW)
(Note: by firmware here I just mean bootcode.bin, *.dat, *.elf files)
All this started with failing cdda2wav on a new system install (Alpine 3.17-based):
https://pastebin.com/EF9rsQ24
Note last line:
Driver and/or firmware bug detected! Drive cannot play the very last sector (248604)!On the very same hardware (same PiZeroW, CD-ROM drive, AudioCD, SD card, Power Supply,....), I installed several base Alpine system (no bells & whistles) and looked at
dmesgWorking combo: Alpine 3.16 (kernel 5.15.78, firmware 1.20220331):
https://pastebin.com/JDUHDJTy
Failing combo: Alpine 3.17 (kernel 5.15.79, firmware 6cbf003):
https://pastebin.com/B8HqN0Pv
I then copied Alpine 3.17 firmware onto initially working 3.16 and got it failing too:
https://pastebin.com/U606fAqx
Finally the opposite test (Alpine 3.17 with firmware 1.20220331), which seems OK:
https://pastebin.com/srsYgPEX
With that, it very much seems like some recent firmware changes (bootcode.bin, *.dat, *.elf) post 1.20220331 are colliding with CD driver.
Thoughts?
The text was updated successfully, but these errors were encountered: