Subject: Re: Bugs with floppy drives
Date: Tue, 8 Mar 94 9:11:54 CST
The transfer speed was only set in the retry after error, not when
switching drives.
a binary link-kit. Make all non-optional options (pagers, procfs) standard,
and update LINT to reflect new symtab requirements.
NB: -Wtraditional will henceforth be forgotten. This editing pass was
primarily intended to detect any constructions where the old code might
have been relying on traditional C semantics or syntax. These were all
fixed, and the result of fixing some of them means that -Wall is now a
realistic possibility within a few weeks.
Entries for 800 and 820 fixed.
From vak@kiae.su:
incorporate Joerg Wunsch formatting code
correct handle timeouted operations
fixed entry for 720 media
GAP values changed suitable for possible format code addition.
Read/write GAP always 2 now.
Interleave parameter added for possible format code addition.
Many logical formats added.
720K physical drive added.
Problems: still can't read 720..820 media in 1.44 drive.
800K in HD 5.25in (maximum for DD diskettes)
1.44M in HD 5.25in (for easy distributions)
1.46M in HD 5.25in (maximum for 5.25)
Some cosmetique changes.
Now minor looks like UU DDDDDD, UU - unit, DDDDDD - density.
If density == 0, CMOS-detect format assumed.
Fix attach code for correct work with unknown CMOS
floppy types.
Trick diskerr to handle new minor.
1.722M floppy in 1.44M drive popular format added.
possible end-user errors.
Now:
1) on physical 1.2 can open logical 1.2, 720, 360H
2) on physical 1.44 can open logical 1.44, 720
3) on physical 360 can open logical 360
All other variants refused.
C-style improved in this check, multiply if's changed to switch.
More work to add 720K floppy support.
Restore good old dependance of device and floppy type.
Now:
fd?a == 1.44
fd?b == 1.2
fd?c == 720
fd?d == 360 in HD
fd?e == 360
Add more strict size check in Fdopen, not it refuse:
1) Attempt to open any type expect fd?e, if you have only 360K drive.
2) Attempt to open fd?a if you have only 1.2 drive.
From: <dec@lazarus.nrtc.northrop.com>
Changes between EPSILON and RELEASE of FreeBSD have again caused
the kernel to not see my floppy disk drives. I don't know what happened,
'cause I don't see any changes to fd.c, but here is an old fix that
I have applied to the probe routine which will solve the problem (at
least for me). Since this is a rather brute-force solution - I understand
if you want to ignore it...
[Upgrading to pre-Beta FreeBSD caused this on my system. -AM]
Date: Thu, 16 Sep 93 01:35:10 +1000
Julian writes:
>In fact DEVIDLE and FINDWORK ended up being basically equivalent.
>the bit I wonder about, is the returning of 0.. What (other than
>another request from somewhere else in the kernel) is going to start
>work on the next item on the queue?
I think removing FINDWORK would make things clearer.
Nothing much is going to start work on the next item. However, it is
pointless to continue processing the queue for the same unready drive.
Aborting all reads and trying harder to perform all writes would be
better.
Julian writes.
> no, actually it should be:
> fdt = fd_data[FDUNIT(minor(dev))].ft;
Fixed.
From: bde@kralizec.zeta.org.au (Bruce Evans)
Date: Thu, 16 Sep 93 22:56:01 +1000
The fd driver reported the wrong cylinder/head/sector numbers after an
error (ST3 is only valid after a sense-drive command), and didn't report
fs block numbers (diskerr was not used).
There was an old problem with writes to block fd devices. Try this:
1. write protect floppy in fd0.
2. tar cf /dev/fd0a /dev/null. Repeat a few times. Later writes tend to
terminate earlier.
3. un-write protect floppy.
4. repeat step 2. The writes tend to return 0, 2048, 4096, ... and then
succeed.
This was caused by a bug in vfs__bios.c. (The bug is fixed in NetBSD's
vfs_bio.c.) fd.c sets bp->b_resid to nonzero after an error. vfs__bios.c
was not initializing bp->b_resid. This causes some writes to terminate
early (e.g., writes to block devices; see spec_write()).
Related funnies:
1. Nothing tries to write the residual bytes.
2. The wd driver sets bp->b_resid to 0 after an error, so there's no
way anything else could write the residual bytes.
3. I use the block fd device for tar because the raw device seemed to
have more bugs long ago, and because it ought to be able to handle
buffering more transparently (I don't want to have to know the
device size). But spec_write() always uses the size BLKDEV_IOSIZE
== 2048 which is too small. For disks it should use the size of
one track (rounded down to meet the next track boundary or the i/o
size). Here it would help if the DIOCGPART ioctl worked. But
DIOCGPART is not implemented for floppies, and the disk size is
ignored except for partitions of type FS_BSDFFS.
Bruce
message for Bruces changes:
>From: bde@kralizec.zeta.org.au (Bruce Evans)
>Subject: fixes for fd driver
I think I've fixed some bugs in the 0.2.4 fd driver.
1. The main cause of hangs was that there was no timeout for seeks. So
attempting i/o with no floppy in the drive hung iff a seek was required.
2. Opens of unattached drives were allowed. The kernel usually paniced
soon after due to a bad pointer.
3. Some timeout functions ran at splclock() instead of splbio(). This
may not have mattered.
4. The state machine was left in a funny state after a timeout.
5. Some function headers were new-style.
6. I picked up some code posted the other day to implement label ioctls.
Now `disklabel fd0' works. See a comment for how to modify conf.c.
reinitialized between while loops. Added comments about what was going
on in the out_fdc routine.
out_fdc now returns if the direction bit is not set in time instead of
trying to wait for MRQ to get cleared.
way of doing things. There still remain several drivers that need to
be updated. Also added a compile-time option to pccons to switch the
control and caps-lock keys (REVERSE_CAPS_CTRL) - added for my personal
sanity.
