Summary: | [umass] [patch] bogus "slice starts beyond end of the disk:..." on USB floppy access | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Gilbert Healton <ghealton> | ||||||||
Component: | usb | Assignee: | Warner Losh <imp> | ||||||||
Status: | Closed FIXED | ||||||||||
Severity: | Affects Only Me | CC: | imp | ||||||||
Priority: | Normal | ||||||||||
Version: | 4.11-RELEASE | ||||||||||
Hardware: | Any | ||||||||||
OS: | Any | ||||||||||
Attachments: |
|
Description
Gilbert Healton
2005-09-30 23:20:23 UTC
Responsible Changed From-To: freebsd-bugs->freebsd-usb I'm going to make a guess that this is usb-specific. On Fri, 30 Sep 2005, Gilbert Healton wrote: >> Description: > > When using USB based floppy disks under FreeBSD4.11 the kernel produces > diagnostics that were not generated by FreeBSD4.9. These errors print on the console as well as being logged to /var/log/messages. > > Diagnostics on USB floppy mount: > > # mount -t msdos /dev/da0 /mnt > da0s1: slice starts beyond end of the disk: rejecting it > da0s2: slice starts beyond end of the disk: rejecting it > da0s3: slice starts beyond end of the disk: rejecting it I can't see why this problem is new. The messages about the slice haven't changed significantly since FreeBSD_2 (except in -current where similar errors are mostly silently ignored if they are detected at all). > Diagnostics on USB floppy umount: > > # umount /mnt > umass0: Unsupported UFI command 0x35 > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 > > The mount appears successful, but not sure of that. It is very noisy and confusing. Will cause many complaints from our customer base. Floppies normally don't have slice (partition) tables, but disks under CAM are all treated the same and hard disks are supposed to have slice tables. The kernel actually only looks for a slice table if the last 2 bytes of the first 512 byte block are 0x55 and 0xAA (bug: this is bogus even if it works if the sector size is not 512). It has checks that the table seems to make sense, but the results of these checks are always silently ignored, except in the bootverbose case they are unsilently ignored. So changing the 0x55, 0xAA bytes is the only way to kill the slice table on "da" disks. It is not always possible to write a valid slice table, since there may be non-slice data in the slice table area. There is more chance that the bytes at the end of the 512-block are free. But some BIOSes needs these bytes to be 0x55, 0xAA for the disk to be bootabke. I have slice support in my version of the fd driver and found the messages about slices to be annoying at times. They didn't normally happen for me for floppies with file systems on them, but did for floppies with more random data, e.g., for a gzip file dd'ed to the disk, but for this case the problem has usually been hidden under bootverbose except, since the signature bytes 0x55, 0xAA only have 1 1/65536 chance of matching for random data. -current has slice support for fd floppies in a different way. Perhaps this is one reason why it is more silent about errors. > ... > * Related to fact that the "MSDOS partition table" area of > preformatted non-system floppies have error text in the > first three entires of the slice table (s1 to s3). If format > floppy under Windows XP, which fills all four slices, get > messages about s1 to s4. If use FreeBSD's new_msdos to > format floppy, which leaves slice table zeros, mount > shows no errors though umount still does. See attachment. DOS-6.22 does the same. So this problem is not new -- almost any bootable floppy not formatted under FreeBSD will have a non-slice table that gets complained about iff the disk is used in a USB or SCSI drive so that it becomes a "da" disk. I think we're just seeing the problme more now that USB is common. (But USB floppies and floppies general aren't common?) > DD ERRORS > --------- > > Has also been observed when using "dd" access of raw, unmounted, drive. > This generates all of the errors in one command. But I've run "dd" at > times where I did not notice there errors either. > > dd if=/dev/da0 of=./floppy.0 bs=512 count=1 > > This seems to favor the same messages as umount, though sometimes I've > seen them all. The slice table is checked on open of any device on the disk iff no other device on the disk is already open, so opening any device on the disk normally causes the error. > FDFORMAT ERRORS > --------------- > > fdformat program fails with these errors in addition to: > > fdformat: not a floppy disk: /dev/da0 Formatting of floppies is not implemented for "da" devices. > FDISK ERRORS > ------------ > Fdisk gives up on floppies. This (fdisk(8) but perhaps not fdisk in sysinstall)should just work. It just works for "fd" devices. fdisk works even on regular files provided the file size is >= 512. For "fd" devices, the device size is correctly detected and a dummy initial label (not quite a slice table is constructed), and fdisk gets the size from this label. For "da" devices, the device size is not always correctly detected and this may cause problems, but it the slice size is corrctly detected then a dummy initial slice table is constructed and a dummy label is contructed from the slice table and then fdisk uses this label and works. > NEWFS_MSDOS ERRORS > ------------------ > > newfs_msdos appears to format correctly though it shows errors > in the way DD does. It creates an all-zero slice table. This shouldn't cause any errors. It just gives all-empty normal slices, and the file system is still accessible via the whole-disk slice. > * Floppies formatted with FreeBSD's newfs_msdos command, which > leaves s1-s4 zero, no mount errors occur though umount errors > still occur. Which unmount errors? They are unlikely to be related. The most common unmount error for floppies is trying to unmount a write protected floppy that has been written too. The system never gives up trying to write and does bad things if the floppy is forcibly unmounted or removed. > Ideas: > -------------------------------------------------------------------- > > My first guess is that these are caused by the fact that non-system floppy disks have error message text at offset 0x1BE rather than a MSDOS partition table. Such a floppy dump follows. > > My second guess involves someone adding SCSI/UFI code that cycles through MS-DOS partitions without first checking if the partition table exsists. It is generic code that happens not to be used by the fd driver. See kern/subr_diskmbr.c. This has some sanity checks which were intended to be used to check individual partitions but which were only used to print messages, only in the bootverbose case. This could be used to check partition tables as a who but is too strict for this. Any garbage is accepted for the partition table, but there are 2 layers of checks later which usually prevent garbage being used to create bogus devices, but later is too late to suppress error messages since there might be real errors, so the result is alarming error messages about non-problems. > More Notes: > -------------------------------------------------------------------- > > Errors produced by code present in both FreeBSD4.9 and FreeBSD4.11: > > /usr/src/sys/kern/subr_diskmbr.c > > da0s2: slice starts beyond end of the disk: rejecting it So this problem is actually old for you too. > /usr/src/sys/dev/usb/umass.c > umass0: Unsupported UFI command 0x35 > > /usr/src/cam/scsi/scsi_da.c > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 I don't understand the SCSI aspects. > mbr_setslice() > printf( "%s: slice starts beyond end of the disk: rejecting it\n", > > > +++likely called from: > > dsinit() > Reads DOS partition table. suspect should not be called if floppy. The device is not known to be a floppy at this point. Anyway, any disk device, including a floppy, should support any disk metadata that fits. Slices and labels just aren't useful for small media. > +++likely called from: > > kern/subr_diskslice.c > > dsopen(dev, mode, flags, sspp, lp) > called on inactive unit to make it active > DSO_ONESLICE in flags must NOT be set to call dsopen(). > > cam/scsi/scsi_cd.c cdregister() seems to be only place that > sets DSO_ONESLICE. DSO_ONESLICE is useful mainly for avoiding the problems in this PR. It also suppresses the probe for the slice table. Attempting to read the slice table would generaate another set of errors for unformatted media, especially for the old fd driver in non-current and for all versions the cd driver, but DSO_ONESLICE prevents these errors for the cd driver. However, always using DSO_ONESLICE in the cd driver is incorrect. DVD+RW and DVD-RAM drives can easily support partitioning and are almost big and normal enough for parititioning to be useful. Other cd drives can not so easily support partitioning. Bruce >Fix: There are actually two bugs in two different sections of the kernel. Individual fixes for each problem are attched. 86767-beyond.patch fixes main "slice starts beyond end of the disk:..." problem. Floppy disks are not expected to contain partition tables. See additional documentation within the patch. 86767-unsupportedUFI.patch fixes "umass0: contained Unsupported UFI command 0x35" problem also reported in 86767. Originally I thought it was another symptom of the same problem. USB floppy drives now return "success" on SYNCHRONIZE_CACHE requests These patches have been running for some months without causing any problems. -------------------------------------------------------------- ghealton@exit109.com http://www.exit109.com/~ghealton/ -------------------------------------------------------------- Computers are like air conditioners: they don't work well when Windows are left open >Fix: There are actually two bugs in two different sections of the kernel. Individual fixes for each problem follow: 86767-beyond.patch fixes main "slice starts beyond end of the disk:..." problem. Floppy disks are not expected to contain partition tables. See additional documentation within the patch. 86767-unsupportedUFI.patch fixes "umass0: contained Unsupported UFI command 0x35" problem also reported in 86767. Originally I thought it was another symptom of the same problem. USB floppy drives now return "success" on SYNCHRONIZE_CACHE requests These patches have been running for some months without causing any problems. 86767-beyond.patch -------------------------------------------------------------- [] FreeBSD bug: kern/86767 bogus "slice starts beyond end of the disk:..." mount. [] Most accesses to USB floppy drives, especially mounts, tend to result in bogus "slice starts beyond end of the disk:..." errors. [] if the boot parameter block claims the device is a floppy media then it is NOW assumed there is no partition table to check. [] Much thanks to Bruce Evans <bde@zeta.org.au> for hints on where to drop this patch. --- sys/msdosfs/bootsect.h Fri Aug 27 20:48:06 1999 +++ sys/msdosfs/bootsect.h Mon Oct 3 18:04:27 2005 @@ -94,6 +94,34 @@ struct bootsector710 bs710; }; + + /* selected media description bytes within bsPBP. used to detect + * media that only has one slice on it. for now this is expected + * to be floppy media. + ghealton@exit109.com & ... @lumeta.com */ + /* (as of 2005-09 floppy media description bytes were available at + http://support.microsoft.com/default.aspx?scid=kb;en-us;140418 + http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html) + /* size DOS Capicty sides tks spt */ +#define MSDOS_MEDIA_ONESLICE0 0xF9 /* 5.25 3.0 1200KB 2 80 15 */ +#define MSDOS_MEDIA_ONESLICE1 0xFF /* 5.25 1.1 320KB 2 40 8 */ + +#define MSDOS_MEDIA_ONESLICE2 0xF0 /* 3.5 ?.? 2880KB 2 80 36 */ + +#define MSDOS_MEDIA_oneslice(c) ( \ + ( md >= MSDOS_MEDIA_ONESLICE0 && md <= MSDOS_MEDIA_ONESLICE1 ) \ + || ( md == MSDOS_MEDIA_ONESLICE2 ) \ + ) + /* if floppies with slice tables are ever used I suspose + that a check for s1-s4 could be made to verify the + first byte of each slice table is 0x00 or 0x80 AND + at most one byte has the 0x80 value in it AND the + remaining bytes of each slice table are not all zeros. If + this test is met you might be able to assume a slice + table exists. But I would make such a compile-option for + those expressly asking for it. */ + + #if 0 /* * Shorthand for fields in the bpb. --- sys/kern/subr_diskmbr.c Fri Jan 28 05:22:07 2000 +++ sys/kern/subr_diskmbr.c Mon Oct 3 18:16:19 2005 @@ -42,6 +42,7 @@ #include <sys/systm.h> #include <sys/buf.h> #include <sys/conf.h> +#include <msdosfs/bootsect.h> /* BOOTSIG0, BOOTSIG1, MSDOS_MEDIA_oneslice */ #ifdef PC98 #define PC98_ATCOMPAT #define dsinit atcompat_dsinit @@ -200,13 +201,26 @@ /* Weakly verify it. */ cp = bp->b_data; sname = dsname(dev, dkunit(dev), WHOLE_DISK_SLICE, RAW_PART, partname); - if (cp[0x1FE] != 0x55 || cp[0x1FF] != 0xAA) { + if (cp[0x1FE] != BOOTSIG0 || cp[0x1FF] != BOOTSIG1) { if (bootverbose) printf("%s: invalid primary partition table: no magic\n", sname); error = EINVAL; goto done; } + + { /* ghealton@exit109.com also ....@lumeta.com */ + /* check if media description byte within range of known floppy medias */ + + u_char md = cp[0x15]; /* set local easy access variable */ + + if ( MSDOS_MEDIA_oneslice(md) ) { + /* this media only uses a single slice (e.g., floppies) */ + + error = 0; + goto done; /* no partition table to process */ + } + } /* Make a copy of the partition table to avoid alignment problems. */ memcpy(&dpcopy[0], cp + DOSPARTOFF, sizeof(dpcopy)); 86767-unsupportedUFI.patch -------------------------------------------------------------- [] FreeBSD bug: kern/86767 bogus "slice starts beyond end of the disk:..." mount. (also umass0: contained Unsupported UFI command 0x35, which this patch addresses) [] The unmount "unsupported UFI command" and "cache sync" errors are caused by UFI operations not supporting SYNCHRONIZE_CACHE. They now no-operation on SYNCHRONIZE_CACHE requests. Not an ideal solution, but it does get rid of the message. --- sys/dev/usb/umass.c Mon Sep 20 01:30:42 2004 +++ sys/dev/usb/umass.c Thu Oct 13 20:11:34 2005 @@ -2880,6 +2880,13 @@ } switch (cmd[0]) { + /* { ghealton@exit109.com.com */ + /* Commands which we ignore (for floppy drives) */ + /* (a better way should occur, but that's all for now folks) */ + case SYNCHRONIZE_CACHE: + return 1; /* return success */ + /* } */ + /* Commands of which the format has been verified. They should work. */ case TEST_UNIT_READY: case REZERO_UNIT: -------------------------------------------------------------- ghealton@exit109.com http://www.exit109.com/~ghealton/ -------------------------------------------------------------- Computers should be fun playthings or useful tools... not obstacles to overcome. >Fix: There are actually two bugs in two different sections of the kernel. Individual fixes for each problem follow: 86767-beyond.patch fixes main "slice starts beyond end of the disk:..." problem. Floppy disks are not expected to contain partition tables. See additional documentation within the patch. 86767-unsupportedUFI.patch fixes "umass0: contained Unsupported UFI command 0x35" problem also reported in 86767. Originally I thought it was another symptom of the same problem. USB floppy drives now return "success" on SYNCHRONIZE_CACHE requests These patches have been running for some months without causing any problems. 86767-beyond.patch -------------------------------------------------------------- [] FreeBSD bug: kern/86767 bogus "slice starts beyond end of the disk:..." mount. [] Most accesses to USB floppy drives, especially mounts, tend to result in bogus "slice starts beyond end of the disk:..." errors. [] if the boot parameter block claims the device is a floppy media then it is NOW assumed there is no partition table to check. [] Much thanks to Bruce Evans <bde@zeta.org.au> for hints on where to drop this patch. --- sys/msdosfs/bootsect.h Fri Aug 27 20:48:06 1999 +++ sys/msdosfs/bootsect.h Mon Oct 3 18:04:27 2005 @@ -94,6 +94,34 @@ struct bootsector710 bs710; }; + + /* selected media description bytes within bsPBP. used to detect + * media that only has one slice on it. for now this is expected + * to be floppy media. + ghealton@exit109.com & ... @lumeta.com */ + /* (as of 2005-09 floppy media description bytes were available at + http://support.microsoft.com/default.aspx?scid=kb;en-us;140418 + http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html) + /* size DOS Capicty sides tks spt */ +#define MSDOS_MEDIA_ONESLICE0 0xF9 /* 5.25 3.0 1200KB 2 80 15 */ +#define MSDOS_MEDIA_ONESLICE1 0xFF /* 5.25 1.1 320KB 2 40 8 */ + +#define MSDOS_MEDIA_ONESLICE2 0xF0 /* 3.5 ?.? 2880KB 2 80 36 */ + +#define MSDOS_MEDIA_oneslice(c) ( \ + ( md >= MSDOS_MEDIA_ONESLICE0 && md <= MSDOS_MEDIA_ONESLICE1 ) \ + || ( md == MSDOS_MEDIA_ONESLICE2 ) \ + ) + /* if floppies with slice tables are ever used I suspose + that a check for s1-s4 could be made to verify the + first byte of each slice table is 0x00 or 0x80 AND + at most one byte has the 0x80 value in it AND the + remaining bytes of each slice table are not all zeros. If + this test is met you might be able to assume a slice + table exists. But I would make such a compile-option for + those expressly asking for it. */ + + #if 0 /* * Shorthand for fields in the bpb. --- sys/kern/subr_diskmbr.c Fri Jan 28 05:22:07 2000 +++ sys/kern/subr_diskmbr.c Mon Oct 3 18:16:19 2005 @@ -42,6 +42,7 @@ #include <sys/systm.h> #include <sys/buf.h> #include <sys/conf.h> +#include <msdosfs/bootsect.h> /* BOOTSIG0, BOOTSIG1, MSDOS_MEDIA_oneslice */ #ifdef PC98 #define PC98_ATCOMPAT #define dsinit atcompat_dsinit @@ -200,13 +201,26 @@ /* Weakly verify it. */ cp = bp->b_data; sname = dsname(dev, dkunit(dev), WHOLE_DISK_SLICE, RAW_PART, partname); - if (cp[0x1FE] != 0x55 || cp[0x1FF] != 0xAA) { + if (cp[0x1FE] != BOOTSIG0 || cp[0x1FF] != BOOTSIG1) { if (bootverbose) printf("%s: invalid primary partition table: no magic\n", sname); error = EINVAL; goto done; } + + { /* ghealton@exit109.com also ....@lumeta.com */ + /* check if media description byte within range of known floppy medias */ + + u_char md = cp[0x15]; /* set local easy access variable */ + + if ( MSDOS_MEDIA_oneslice(md) ) { + /* this media only uses a single slice (e.g., floppies) */ + + error = 0; + goto done; /* no partition table to process */ + } + } /* Make a copy of the partition table to avoid alignment problems. */ memcpy(&dpcopy[0], cp + DOSPARTOFF, sizeof(dpcopy)); 86767-unsupportedUFI.patch -------------------------------------------------------------- [] FreeBSD bug: kern/86767 bogus "slice starts beyond end of the disk:..." mount. (also umass0: contained Unsupported UFI command 0x35, which this patch addresses) [] The unmount "unsupported UFI command" and "cache sync" errors are caused by UFI operations not supporting SYNCHRONIZE_CACHE. They now no-operation on SYNCHRONIZE_CACHE requests. Not an ideal solution, but it does get rid of the message. --- sys/dev/usb/umass.c Mon Sep 20 01:30:42 2004 +++ sys/dev/usb/umass.c Thu Oct 13 20:11:34 2005 @@ -2880,6 +2880,13 @@ } switch (cmd[0]) { + /* { ghealton@exit109.com.com */ + /* Commands which we ignore (for floppy drives) */ + /* (a better way should occur, but that's all for now folks) */ + case SYNCHRONIZE_CACHE: + return 1; /* return success */ + /* } */ + /* Commands of which the format has been verified. They should work. */ case TEST_UNIT_READY: case REZERO_UNIT: -------------------------------------------------------------- ghealton@exit109.com http://www.exit109.com/~ghealton/ -------------------------------------------------------------- Computers should be fun playthings or useful tools... not obstacles to overcome. Fix: There are actually two bugs in two different sections of the kernel. Individual fixes for each problem follow: 86767-beyond.patch fixes main "slice starts beyond end of the disk:..." problem. Floppy disks are no longer expected to contain partition tables. See additional documentation within the patch. 86767-unsupportedUFI.patch fixes "umass0: contained Unsupported UFI command 0x35" problem also reported in 86767. Originally I thought it was another symptom of the same problem. USB drives now return "success" on SYNCHRONIZE_CACHE requests These patches have been running for some months without causing any problems. 86767-beyond.patch -------------------------------------------------------------- [] FreeBSD bug: kern/86767 bogus "slice starts beyond end of the disk:..." mount. [] Most accesses to USB floppy drives, especially mounts, tend to result in bogus "slice starts beyond end of the disk:..." errors. [] if the boot parameter block claims the device is a floppy media then it is NOW assumed there is no partition table to check. [] Much thanks to Bruce Evans <bde@zeta.org.au> for hints on where to drop this patch. --- sys/msdosfs/bootsect.h Fri Aug 27 20:48:06 1999 +++ sys/msdosfs/bootsect.h Mon Oct 3 18:04:27 2005 @@ -94,6 +94,34 @@ struct bootsector710 bs710; }; + + /* selected media description bytes within bsPBP. used to detect + * media that only has one slice on it. for now this is expected + * to be floppy media. + ghealton@exit109.com & ... @lumeta.com */ + /* (as of 2005-09 floppy media description bytes were available at + http://support.microsoft.com/default.aspx?scid=kb;en-us;140418 + http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html) + /* size DOS Capicty sides tks spt */ +#define MSDOS_MEDIA_ONESLICE0 0xF9 /* 5.25 3.0 1200KB 2 80 15 */ +#define MSDOS_MEDIA_ONESLICE1 0xFF /* 5.25 1.1 320KB 2 40 8 */ + +#define MSDOS_MEDIA_ONESLICE2 0xF0 /* 3.5 ?.? 2880KB 2 80 36 */ + +#define MSDOS_MEDIA_oneslice(c) ( \ + ( md >= MSDOS_MEDIA_ONESLICE0 && md <= MSDOS_MEDIA_ONESLICE1 ) \ + || ( md == MSDOS_MEDIA_ONESLICE2 ) \ + ) + /* if floppies with slice tables are ever used I suspose + that a check for s1-s4 could be made to verify the + first byte of each slice table is 0x00 or 0x80 AND + at most one byte has the 0x80 value in it AND the + remaining bytes of each slice table are not all zeros. If + this test is met you might be able to assume a slice + table exists. But I would make such a compile-option for + those expressly asking for it. */ + + #if 0 /* * Shorthand for fields in the bpb. --- sys/kern/subr_diskmbr.c Fri Jan 28 05:22:07 2000 +++ sys/kern/subr_diskmbr.c Mon Oct 3 18:16:19 2005 @@ -42,6 +42,7 @@ #include <sys/systm.h> #include <sys/buf.h> #include <sys/conf.h> +#include <msdosfs/bootsect.h> /* BOOTSIG0, BOOTSIG1, MSDOS_MEDIA_oneslice */ #ifdef PC98 #define PC98_ATCOMPAT #define dsinit atcompat_dsinit @@ -200,13 +201,26 @@ /* Weakly verify it. */ cp = bp->b_data; sname = dsname(dev, dkunit(dev), WHOLE_DISK_SLICE, RAW_PART, partname); - if (cp[0x1FE] != 0x55 || cp[0x1FF] != 0xAA) { + if (cp[0x1FE] != BOOTSIG0 || cp[0x1FF] != BOOTSIG1) { if (bootverbose) printf("%s: invalid primary partition table: no magic\n", sname); error = EINVAL; goto done; } + + { /* ghealton@exit109.com also ....@lumeta.com */ + /* check if media description byte within range of known floppy medias */ + + u_char md = cp[0x15]; /* set local easy access variable */ + + if ( MSDOS_MEDIA_oneslice(md) ) { + /* this media only uses a single slice (e.g., floppies) */ + + error = 0; + goto done; /* no partition table to process */ + } + } /* Make a copy of the partition table to avoid alignment problems. */ memcpy(&dpcopy[0], cp + DOSPARTOFF, sizeof(dpcopy)); 86767-unsupportedUFI.patch -------------------------------------------------------------- [] FreeBSD bug: kern/86767 bogus "slice starts beyond end of the disk:..." mount. (also umass0: contained Unsupported UFI command 0x35, which this patch addresses) [] The unmount "unsupported UFI command" and "cache sync" errors are caused by UFI operations not supporting SYNCHRONIZE_CACHE. They now no-operation on SYNCHRONIZE_CACHE requests. Not an ideal solution, but it does get rid of the message. --- sys/dev/usb/umass.c Mon Sep 20 01:30:42 2004 +++ sys/dev/usb/umass.c Thu Oct 13 20:11:34 2005 @@ -2880,6 +2880,13 @@ } switch (cmd[0]) { + /* { ghealton@exit109.com.com */ + /* Commands which we ignore (for floppy drives) */ + /* (a better way should occur, but that's all for now folks) */ + case SYNCHRONIZE_CACHE: + return 1; /* return success */ + /* } */ + /* Commands of which the format has been verified. They should work. */ case TEST_UNIT_READY: case REZERO_UNIT: -------------------------------------------------------------- ghealton@exit109.com http://www.exit109.com/~ghealton/ -------------------------------------------------------------- Computers should be fun playthings or useful tools... not obstacles to overcome. The syn cache portion of this bug is no longer necessary. I've corrected the syncache issues in current. For floppies, we always report that the operation succeeded. The rest of the patch looks interesting. Warner For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped These issues were fixed at least in FreeBSD 8, where I used USB floppies successfully w/o this error. |