Ticket #464 (Fixed)Fri Apr 12 20:20:17 UTC 2019
SCSIFS 1.35 incompatible with !Systemdisc 1.04 and Fat32Format 1.05
Reported by: | jan de boer (472) | Severity: | Normal |
Part: | RISC OS: Module | Release: | |
Milestone: | Status | Fixed |
Details by jan de boer (472):
SCSIFS was changed 8 months ago (Aug ‘18). !Systemdisc stiffs after selecting SCSI and choosing the drive number. Fat32Format fails to read the sizes of USB-sticks and SD-cards over cardreader. When SCSIFS 1.35 is *rmkilled and SCSIFS 1.33 is *rmloaded in Predesk, everything runs OK again.
Bug is found on RPI 1,RPI 3B+ and BeagleBoard XM. No storage media with partitions.
The extra problem with Beagleboard is that it’s difficult to return to earlier versions than 1.35, as the older SCSIFS version has to be *rmloaded over SCSI (if !Boot structure is on an USB-stick).
Using !Systemdisc on Riscos after Aug.’18 with SDFS is problemless.
Changelog:
Modified by Sprow (202) Sat, April 13 2019 - 08:42:08 GMT
- Attachment added: scsifs_test.zip
What does SCSIFS 1.34 do? Good or bad? See attached binaries to try.
Modified by Sprow (202) Sat, April 13 2019 - 08:42:16 GMT
- Part changed from Unspecified to RISC OS: Module
Modified by Chris Mahoney (1684) Mon, April 29 2019 - 08:51:02 GMT
I’ve just tried this myself and 1.33 worked but 1.34 froze the system as described above.
Modified by Sprow (202) Sat, February 29 2020 - 07:53:57 GMT
Extra data point: this also appears to affect SDCreate.
When coming to write out the blank image (the loop just after “Decompressing blank image…” you get the error “Bad input to Squash module”. The loop does execute at least once, as there’s a single progress dot, and Squash returns stat%=2.
Does that suggest either a register corruption, or memory corruption?
Modified by Sprow (202) Sat, March 21 2020 - 19:25:51 GMT
> Extra data point: this also appears to affect SDCreate.
Some hasty back peddling on that. When I got the “Bad input to Squash module” I just reverted to RISC OS 5.24 and assumed that SCSIFS was the important change, without being thorough enough to try just changing SCSIFS.
Now I have, I find that it’s actually Squash causing the problem – a copy built in the Disc environment works, so this particular error seems more likely to be a library or compiler triggered bug.
Modified by Sprow (202) Sun, August 09 2020 - 13:11:33 GMT
For Fat32Formatter, the reason it doesn’t work on SCSIFS 1.34 or later is because the SWI SCSI_Partitions subreason 1 has been retroactively defined to tie significance to R2, when previously there was none. So whatever random value is in R2 gets used when the formatter scans for drives but fails to match so none are returned.
For HForm, this doesn’t trip up because it’s written in BASIC so the unused registers are set to zero, hence R2=0 (always) matches the 0th partition when SCSIFS_Partitions is used.
It seems like a new subreason should have been used rather than tieing new meaning to previously unused registers.
Modified by Sprow (202) Thu, August 20 2020 - 06:17:03 GMT
- Status changed from Open to Fixed
Fixed in SCSIFS-1_36.