kern/86767: bogus "slice starts beyond end of the disk:..." on USB floppy access

[Bruce Evans]

The following reply was made to PR usb/86767; it has been noted by GNATS.

From: Bruce Evans <bde at zeta.org.au>
To: Gilbert Healton <ghealton at exit109.com>
Cc: FreeBSD-gnats-submit at freebsd.org, freebsd-bugs at freebsd.org
Subject: Re: kern/86767: bogus "slice starts beyond end of the disk:..." on
 USB floppy access
Date: Sun, 2 Oct 2005 02:04:05 +1000 (EST)

 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