Bug 84930

Comment 1 Mark Linimon 2005-08-14 21:01:59 UTC

Responsible Changed
From-To: freebsd-bugs->freebsd-amd64

Sounds amd64-specific (or at least 64-bit specific).

MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200508142314.38088.andy@athame.co.uk>

At least here on 6.0-BETA2/amd64 it is working fine

umass0: USB Mass storage, rev 2.00/2.00, addr 2
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <BUFFALO ClipDrive 2.00> Removable Direct Access SCSI-2 device
da0: 40.000MB/s transfers
da0: 250MB (512000 512 byte sectors: 64H 32S/T 250C)

[tap@ping Done]$ sudo mount -t msdosfs /dev/da0s1 /cdrom
[tap@ping Done]$ ls -l /cdrom/
total 43820
<remove valid list of files because some are confidential>
[tap@ping Done]$ sudo touch /cdrom/test
[tap@ping Done]$ ls -l /cdrom/
total 43820
<remove same valid list of files because some are confidential>
-rwxr-xr-x  1 root  wheel         0 Aug 14 23:08 test

No problem here with msdosfs on amd64.

My system:

FreeBSD slackbox.xs4all.nl 5.4-STABLE FreeBSD 5.4-STABLE #0: 
Wed Aug 10 20:25:45 CEST 2005 
rsmith@slackbox.xs4all.nl:/usr/obj/usr/src/sys/RFS  amd64


I tried a USB keydrive first:

umass0: vendor 0x1005 USB Flash Drive, rev 2.00/1.00, addr 2
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <USB Flash Drive 1.12> Removable Direct Access SCSI-0 device 
da0: 1.000MB/s transfers
da0: 61MB (126973 512 byte sectors: 64H 32S/T 61C)

Mounted OK. Deleting and adding files OK. Files checked with md5.

Next I tried a compactflash card, in a SanDisk SDDR-31 reader:

umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 2
umass0: Get Max Lun not supported (STALLED)
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <SanDisk ImageMate II 1.30> Removable Direct Access SCSI-2 device 
da0: 1.000MB/s transfers
da0: 61MB (125441 512 byte sectors: 64H 32S/T 61C)

I got some errors here:

(da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 1 ea 0 0 0 1 0 
(da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI Status: Check Condition
(da0:umass-sim0:0:0:0): MEDIUM ERROR asc:0,0
(da0:umass-sim0:0:0:0): No additional sense information

This error was repeated a couple of times. But I could still mount the
drive. Deleting and adding files OK. Files also checked with md5.

Contact me if you need more info.

Roland
-- 
R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text.
public key: http://www.xs4all.nl/~rsmith/pubkey.txt

Maybe, something is "wrong" about this particular filesystem?

It was created by IRiver -- I never reformatted it. It is 40Gb,
but I can extract some headers or whatever would be useful to
debug this...

Or, maybe, it is related to its size? Two people have responded so far
with their _working_ examples, but theirs are 61Mb and 250Mb.

	-mi

On Sun, Aug 14, 2005 at 04:59:08PM -0400, Mikhail Teterin wrote:
> Maybe, something is "wrong" about this particular filesystem?
> 
> It was created by IRiver -- I never reformatted it. It is 40Gb,
> but I can extract some headers or whatever would be useful to
> debug this...


Did you get any unusual messages in the system logfiles?

> Or, maybe, it is related to its size? Two people have responded so far
> with their _working_ examples, but theirs are 61Mb and 250Mb.


Could be, but I don't think so. IIRC, you have to have the "options
MSDOSFS_LARGE" in your kernel for drives >128GB.

Roland
-- 
R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text.
public key: http://www.xs4all.nl/~rsmith/pubkey.txt

> Did you get any unusual messages in the system logfiles?

No, I checked.
 
> > Or, maybe, it is related to its size? Two people have responded so far
> > with their _working_ examples, but theirs are 61Mb and 250Mb.
> 
> Could be, but I don't think so. IIRC, you have to have the "options
> MSDOSFS_LARGE" in your kernel for drives >128GB.

The disk is 40Gb... It is above 2Gb (and 4Gb), which may explain why the
behavior is different from the working examples. But it is well below
the size requiring special treatment -- and, indeed, works fine with my
i386 systems.

	-mi

Comment 7 Giorgos Keramidas 2005-08-16 00:43:15 UTC

On 2005-08-14 15:14, "Mikhail T." <mi@aldan.algebra.com> wrote:
> I just tried to move some songs over to the IRiver MP3-player.
> USB code recognized the device:
>
> 	da1 at umass-sim0 bus 0 target 0 lun 0
> 	da1: <TOSHIBA MK4004GAH JC00> Fixed Direct Access SCSI-0 device
> 	da1: 1.000MB/s transfers
> 	da1: 38147MB (78126048 512 byte sectors: 255H 63S/T 4863C)
>
> and I was able to mount it:
>
> % mount -t msdosfs /dev/da1s1 /iriver
>
> The drive on it is just over half-full and df confirms it:
>
> /dev/da1s1         39052512 19902080 19150432    51%	/iriver
>
> Yet, when I tried to list the contents of the drive, I saw nothing:
>
> 	% ls -l /iriver
> 	total 0
>
> Another system -- i386 running 5.4-stable from April 23 -- had no
> problems and is busy copying the files as I type this.
>
> >How-To-Repeat:
>
> Try to write to an msdosfs on amd64.

This may be unrelated, but I'm successfully using a JetFlash USB stick
to move small amounts of data between my i386 7.0-CURRENT workstation
and my amd64 laptop.  So far things seem to work fine, so it may be a
bug that is not related to msdosfs.

Another thought is that I had similar problems with msdosfs and cd9660
filesystems when I tried to read their contents from a root shell (which
doesn't have any LC_XXX or LANG environment vars), especially when the
filesystem contained Greek filenames.  Setting up the correct locale
fixed everything.

I'm not saying that nothing is wrong with msdosfs on amd64.  Just adding
what I've seen so far, in case it helps track down the cause of your
problems.

Regards,
Giorgos

Comment 8 Craig Rodrigues 2007-01-29 02:30:47 UTC

State Changed
From-To: open->closed

Closing, since this looks related to the amd64 problems with vn_stat() on 
msdosfs:  
http://www.freebsd.org/cgi/query-pr.cgi?pr=106703