Bug 86767

Summary: [umass] [patch] bogus "slice starts beyond end of the disk:..." on USB floppy access
Product: Base System Reporter: Gilbert Healton <ghealton>
Component: usbAssignee: Warner Losh <imp>
Status: Closed FIXED    
Severity: Affects Only Me CC: imp
Priority: Normal    
Version: 4.11-RELEASE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
floppy-bug.txt
none
86767-unsupportedUFI.patch
none
86767-beyond.patch none

Description Gilbert Healton 2005-09-30 23:20:23 UTC
	
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

  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.


More details:

 * src/UPDATING read. Closest is 20030806 DA_OLD_QUIRKS note, 
   but that claims it was removed in 4.9 and 4.9 worked 
   without these errors.

 * Attachment has some duplicate details, logs, as well as much 
   additional material.

 * Failures observed on two different Dell D600 systems and 
   a Dell D610.

 * Failures do not occur on straight "fd0" floppies.

 * Notice many people asking about this error in various 
   news groups when searching for error text using Google.

 * 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.

Fix: None found yet. still looking, but slowly as not used to FreeBSD 
I/O drivers and I have a software delivery coming well too soon.
Never done BSD drivers nor these devices before so lots to learn.
	

How-To-Repeat: Mount non-system MSDOS 3 1/2 formatted floppy in USB connected drive then 

  mount -t msdos /dev/da0 /mnt
  umount /mnt
	

Used multiple fresh-out-of-the-box preformatted floppies with nothing
written to them as well as floppies formatted other ways. The key is
having a non-system floppy that prints that classic error message where
message text is stored where MSDOS partition table normally resides.

100% reproduction rate.

Used Dell branded floppy (PN/71761-A01) though it lists as NEC in dmesg 
(see attachment).  Other numbers on drive: FDDM-101    243-560390-101-0 
UL E151483 M     IC Class B ICES-003
Bar Code PH-02R152-17601-42B-E239 Rev A00.



WORKAROUND - PARTIAL
--------------------

Format floppy with FreeBSD's "newfs_msdos" program before mounting
the floppy for use:

	newfs_msdos [-L label] /dev/da0

This stops mount errors, though the umount errors continue.

(This happens to leave the partition table area zeros.)


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.


FDFORMAT ERRORS
---------------

fdformat program fails with these errors in addition to:

  fdformat: not a floppy disk: /dev/da0


FDISK ERRORS
------------
Fdisk gives up on floppies.


NEWFS_MSDOS ERRORS
------------------

newfs_msdos appears to format correctly though it shows errors 
in the way DD does.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2005-10-01 05:38:26 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-usb

I'm going to make a guess that this is usb-specific.
Comment 2 Bruce Evans 2005-10-01 17:04:05 UTC
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
Comment 3 ghealton 2006-02-06 16:42:12 UTC
>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
Comment 4 ghealton 2006-02-06 17:08:01 UTC
>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.
Comment 5 ghealton 2006-02-06 17:08:44 UTC
>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.
Comment 6 ghealton 2006-02-06 17:20:36 UTC
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.
Comment 7 M. Warner Losh 2007-09-11 17:53:36 UTC
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
Comment 8 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:07 UTC
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
Comment 9 Warner Losh freebsd_committer freebsd_triage 2021-07-04 01:43:45 UTC
These issues were fixed at least in FreeBSD 8, where I used USB floppies successfully w/o this error.