BIOS track read retry errors when floppy sectors/track differ

[ghaerr]

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.

[Mellvik]

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.

[ghaerr]

(@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.
——————————————

Direct console, scan kbd 80x25 emulating ANSI (3 virtual consoles)
ttyS0 at 0x3f8, irq 4 is a 16450
ttyS1 at 0x2f8, irq 3 is a 16550A
ttyS2 at 0x3e8, irq 5 is a 16550A
xms: A20 was off now on, using int 15, 256 xms buffers
eth: NE2K at 0x300, irq 12, MAC 00:80:29:ef:d9:51
bioshd: hda BIOS CHS 610,16,63
bioshd: hda  IDE CHS 993,16,63
/dev/hda: 993 cylinders, 16 heads, 63 sectors = 488.7 Mb
/dev/fd0: 80 cylinders, 2 heads, 18 sectors = 1440.0 kb
/dev/fd1: 80 cylinders, 2 heads, 15 sectors = 1200.0 kb
Partitions: hda:(0,1000944)  hda1:(63,997857)
device_setup: BIOS drive 0x0, root device 0x380
PC/AT class machine, Unknown x86 CPU, 640K base RAM.
ELKS kernel 0.4.0 (52416 text, 12704 ftext, 8016 data, 41856 bss, 15662 heap)
Kernel text at 2d0:0000, ftext f9c:0000, data 12b6:0000, top a000:0, 501K free
fd: /dev/fd0 found ELKS parm block, has 80 cylinders, 2 heads, and 18 sectors
VFS: Mounted root 0x0380 (minix filesystem).
Running /etc/rc.d/rc.sys script
fsck -r /dev/fd0: /dev/fd0 is clean, no check.
fd: probing disc in /dev/fd1
fd: /dev/fd1 probably has 80 cylinders, 2 heads, and 15 sectors
FAT: me=f9,csz=1,#f=2,floc=1,fsz=7,rloc=15,#d=224,dloc=29,#s=2400,ts=0
FAT: 1200k, fat12 format
FAT: me=f8,csz=16,#f=2,floc=1,fsz=244,rloc=489,#d=512,dloc=521,#s=997857,ts=9978
57
FAT: 498M, fat16 format
Starting networking on eth
ktcp -b 10.0.2.15 10.0.2.2 255.255.255.0
ktcp: ip 10.0.2.15, gateway 10.0.2.2, netmask 255.255.255.0
ktcp: ethernet 00.80.29.ef.d9.51 mtu 1500
Starting daemons 'telnetd' 'ftpd -d -d'
ELKS built from commit 5d36b17
Mon Jan 31 19:02:37 2022


ELKS 0.4.0

login: root
# ls /mnt1
command.com  dos          ibmbio.com   ibmdos.com
#

[ghaerr]

ELKS does mount a 360k floppy fine, while displaying the 'wrong' data, see clip below.

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!