Hi Florian,
Yes, it's common, as far as I understand the floppy driver, it
auto-detects the disk geometry by reading the first block ("bootblock")
in floppy_revalidate and __floppy_read_block_0 [1].
The auto-detection is also noted in admin-guide/devices.txt [2]:
2 block Floppy disks
0 = /dev/fd0 Controller 0, drive 0, autodetect
https://github.com/sparclinux/issues/issues/18#issuecomment-3446644226
Without any further research, this seems to make sense to me. The error message indicates
that something tried to read 16 sectors (8 kilobyte), but the medium size is assumed to
be just 8 sectors (4 kilobyte). As the define is now 4 (kilobyte) and the SPARC page size
is 8 kilobytes, the bigger page size might be the reason that an 8KB read happens at that
moment. The name of the original patch ("hotfix-floppy-not-4k-pages.patch")
also supports the assumption that something in the floppy driver relies on the page size.
It took me a while, but I think I'm starting to understand the problem now.
1. A new floppy disk is inserted. The driver doesn't know the real disk size
yet, so it's set to MAX_DISK_SIZE (8 sectors, 4KiB).
2. Someone accesses the disk. The kernel reads the bootblock first (2 sectors,
1KiB) to detect the real disk size.
3. In reality, it reads a whole memory page, which can be larger than the
predefined MAX_DISK_SIZE. Specifically, on UltraSPARC CPUs, it's 8KiB (16
sectors). This causes the access to fail, before even reading from the disk.
If the detection routine only needs 2 sectors, then it should read just that -
*before* bailing out when the requested data size (1 memory page in this case)
is larger than the hardcoded minimum disk size (4KiB). Otherwise the detection
code will never run, and the disk size is never corrected.
Turning this around, it would also be a problem when swapping different floppy
disk sizes.
Insert a 1.44MB disk first, and the driver adjusts the size to 1.44MB. Then
insert a 720KB disk, and try to access the 1MB..1.44MB. This wouldn't be
short-circuited, because the floppy subsystem still thinks a 1.44MB floppy is
inserted.
But it would (should!) still fail, because the physical disk is now smaller
than 1.44MB.
So why prevent the access in the first place? The cached disk size may always
be a mismatch, in one way or another.
I'm not sure how to solve this problem properly, but the way it's solved right
now seems wrong...
