-
Notifications
You must be signed in to change notification settings - Fork 106
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
BIOS track read retry errors when floppy sectors/track differ #1119
Comments
Very interesting @ghaerr!
I have exactly this setup on physical, will take a look at this tomorrow and try out the new config files at the same time.
The problem with 360k reporting may actually be correct after all. Most 5.25in drives still in use are 1.2M drives. They autodetect the media density, and will report 1200k initially, change it if it's actually 360k.
…-M
19. jan. 2022 kl. 19:20 skrev Gregory Haerr ***@***.***>:
As can be seen from the screenshot below, the floppy BIOSHD driver ends up doing a track read retry whenever switching between floppy disks with different sectors per track (e.g. /dev/fd0 1440K and /dev/fd1 720K). This screenshot is using the mount.cfg auto-mount to mount /dev/fd1 at boot time and gets the track read retry error when switching back to reading the boot floppy:
I'm not sure if this is a new problem with QEMU's BIOS emulation, or happens on real hardware.
Also, BIOSHD is querying the floppy drive type from BIOS and getting the wrong result for 360K floppies. Shown below, it is reporting a 360K /dev/fd1 as 80 cylinders, 2 heads and 15 sectors 1200k. After the ELKS BIOSHD probe, the correct disk size is determined and shown as 40 cylinders, 2 heads and 9 sectors:
Also not sure if this is just QEMU, or happens on real hardware.
Both these errors end up fixing themselves, but the false reporting of disk attributes is bothersome, and the track retry may have to be modified, as ELKS currently doesn't actually retry track reads, but instead falls back to single sector reads. Changing this to 2 retries also fixes the problem, but not sure whether this is a QEMU-only problem or happens on real hardware. A disk reset causes the entire BIOSHD function to fail, for some reason.
It is not clear how long this behavior has been occurring.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
|
(@Mellvik's reply from #1109 (comment)): I just tested this, and cannot replicate the reread problem on real hardware. ELKS does mount a 360k floppy fine, while displaying the 'wrong' data, see clip below. The 2nd pair of FAT messages are (obviously) for the HD.
|
Thanks for testing this. I assume for 'wrong' data, you mean it reports CHS 80/2/15 (1200k) rather than CHS 40/2/9. It seems my originally reported problem is that the retry error is only with QEMU. However, with ELKS thinking the disk is 1200K rather than 360k, a quick top-level directory listing may not try reading sectors outside the 360k sectors/track limit of 9, and thus not show the real problem. Thank you! |
As can be seen from the screenshot below, the floppy BIOSHD driver ends up doing a track read retry whenever switching between floppy disks with different sectors per track (e.g. /dev/fd0 1440K and /dev/fd1 720K). This screenshot is using the mount.cfg auto-mount to mount /dev/fd1 at boot time and gets the track read retry error when switching back to reading the boot floppy:
I'm not sure if this is a new problem with QEMU's BIOS emulation, or happens on real hardware.
Also, BIOSHD is querying the floppy drive type from BIOS and getting the wrong result for 360K floppies. Shown below, it is reporting a 360K /dev/fd1 as 80 cylinders, 2 heads and 15 sectors 1200k. After the ELKS BIOSHD probe, the correct disk size is determined and shown as 40 cylinders, 2 heads and 9 sectors:
Also not sure if this is just QEMU, or happens on real hardware.
Both these errors end up fixing themselves, but the false reporting of disk attributes is bothersome, and the track retry may have to be modified, as ELKS currently doesn't actually retry track reads, but instead falls back to single sector reads. Changing this to 2 retries also fixes the problem, but not sure whether this is a QEMU-only problem or happens on real hardware. A disk reset causes the entire BIOSHD function to fail, for some reason.
It is not clear how long this behavior has been occurring.
The text was updated successfully, but these errors were encountered: