Re: umass(4) broken on netbsd-7/amd64?

[Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost>]

Michael van Elst <mlelstv%serpens.de@localhost> writes:

> This could be a different issue. msdosfs got some additional
> sanity checks to prevent it from using an invalid bios parameter
> block that could make it panic.

That's it.  I compiled a kernel with DEBUG_MSDOSFS, and here's what I
see now, for two USB memory sticks I've been using for years.  One is
small, and contains a FREEDOS boot image for BIOS patching (downloaded
from the net and written to the stick), the other is much larger, and is
used for ferrying files among systems running Windows, Linux, NetBSD,
and whatever my TV runs.  IIRC, it was initialized under Windows XP.

umass0 at uhub7 port 3 configuration 1 interface 0
umass0: SMI Corporation (0x90c) USB DISK (0x1000), rev 2.00/11.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <S31B1103, USB DISK, 1100> disk removable
sd0: 3864 MB, 7872 cyl, 16 head, 63 sec, 512 bytes/sect x 7913472 sectors

5 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 d:   7913472         0     unused      0     0        # (Cyl.    0 -   7850*)
 e:     58593         1      MSDOS                     # (Cyl.    0*-     58*)

: dejah# ;mount /dev/sd0e /m/stick
msdosfs_mountfs(): FATsecs 60 != real 58

umass0 at uhub7 port 1 configuration 1 interface 0
umass0: SanDisk (0x781) Cruzer Glide (0x5575), rev 2.00/2.01, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <SanDisk, Cruzer Glide, 2.01> disk fixed
sd0: 30532 MB, 62034 cyl, 16 head, 63 sec, 512 bytes/sect x 62530624 sectors

5 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 d:  62530624         0     unused      0     0        # (Cyl.    0 -  62034*)
 e:  62527488      2048      MSDOS                     # (Cyl.    2*-  62033*)

: dejah# ;mount /dev/sd0e /m/stick
msdosfs_mountfs(): FATsecs 15264 != real 15259

So if I read this right, the MSDOS file system seems to have allocated
slightly more space for the FAT table than msdosfs thinks it should,
right?  Could this just be a difference in rounding choice?

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay