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

[christos%astron.com@localhost (Christos Zoulas)]

In article <m2tvxfer5d.fsf%thuvia.hamartun.priv.no@localhost>,
Tom Ivar Helbekkmo  <tih%hamartun.priv.no@localhost> wrote:
>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?

We could introduce an msdos specific 'permissive' option that allows
readonly mounts.

christos