| Message ID | 20210312063259.1721939-1-jsnow@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | fdc: fix floppy boot for Red Hat Linux 5.2 | expand |
On 12/03/2021 07.32, John Snow wrote: > The image size indicates it's an 81 track floppy disk image, which we > don't have a listing for in the geometry table. When you force the drive > type to 1.44MB, it guesses the reasonably close 18/80. When the drive > type is allowed to auto-detect or set to 2.88, it guesses a very > incorrect geometry. > > auto, 144 and 288 drive types get the right geometry with the new entry > in the table. > > Reported-by: Michael Tokarev <mjt@tls.msk.ru> > Signed-off-by: John Snow <jsnow@redhat.com> > --- > hw/block/fdc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/hw/block/fdc.c b/hw/block/fdc.c > index 198940e737..b2f26ba587 100644 > --- a/hw/block/fdc.c > +++ b/hw/block/fdc.c > @@ -122,6 +122,7 @@ static const FDFormat fd_formats[] = { > /* First entry is default format */ > /* 1.44 MB 3"1/2 floppy disks */ > { FLOPPY_DRIVE_TYPE_144, 18, 80, 1, FDRIVE_RATE_500K, }, /* 3.5" 2880 */ > + { FLOPPY_DRIVE_TYPE_144, 18, 81, 1, FDRIVE_RATE_500K, }, > { FLOPPY_DRIVE_TYPE_144, 20, 80, 1, FDRIVE_RATE_500K, }, /* 3.5" 3200 */ > { FLOPPY_DRIVE_TYPE_144, 21, 80, 1, FDRIVE_RATE_500K, }, > { FLOPPY_DRIVE_TYPE_144, 21, 82, 1, FDRIVE_RATE_500K, }, That whole table-based approach seems quite unreliable to me - I've seen floppy disks with 80, 81, 82 or sometimes even 83 tracks in the past, so I think we would do better with a more flexible way of guessing ... but for the time being, this is certainly a quick and easy fix that also should not have any negative impact, thus: Reviewed-by: Thomas Huth <thuth@redhat.com>
On 3/12/21 3:01 AM, Thomas Huth wrote: > > That whole table-based approach seems quite unreliable to me - I've seen > floppy disks with 80, 81, 82 or sometimes even 83 tracks in the past, so > I think we would do better with a more flexible way of guessing ... but > for the time being, this is certainly a quick and easy fix that also > should not have any negative impact, thus: > > Reviewed-by: Thomas Huth <thuth@redhat.com> Yes, that's my thought. I can't personally justify tackling this hokey system -- I simply don't know enough about the history of the device to design a suitable replacement. So, it's a band-aid, but one that fits with the way the floppy has worked for quite a long time, and seems the least likely to bother anything further. --js
diff --git a/hw/block/fdc.c b/hw/block/fdc.c index 198940e737..b2f26ba587 100644 --- a/hw/block/fdc.c +++ b/hw/block/fdc.c @@ -122,6 +122,7 @@ static const FDFormat fd_formats[] = { /* First entry is default format */ /* 1.44 MB 3"1/2 floppy disks */ { FLOPPY_DRIVE_TYPE_144, 18, 80, 1, FDRIVE_RATE_500K, }, /* 3.5" 2880 */ + { FLOPPY_DRIVE_TYPE_144, 18, 81, 1, FDRIVE_RATE_500K, }, { FLOPPY_DRIVE_TYPE_144, 20, 80, 1, FDRIVE_RATE_500K, }, /* 3.5" 3200 */ { FLOPPY_DRIVE_TYPE_144, 21, 80, 1, FDRIVE_RATE_500K, }, { FLOPPY_DRIVE_TYPE_144, 21, 82, 1, FDRIVE_RATE_500K, },
The image size indicates it's an 81 track floppy disk image, which we don't have a listing for in the geometry table. When you force the drive type to 1.44MB, it guesses the reasonably close 18/80. When the drive type is allowed to auto-detect or set to 2.88, it guesses a very incorrect geometry. auto, 144 and 288 drive types get the right geometry with the new entry in the table. Reported-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: John Snow <jsnow@redhat.com> --- hw/block/fdc.c | 1 + 1 file changed, 1 insertion(+)