Matthew Dharm wrote: > > --8<-- me blindly trying a few sg commands .. > > I don't quite understand why it needs to be limited to Windows only, > > but it seems that Linux does *something* different enough that it > > doesn't quite work for me. > > My guess is that if you tried the equivalent commands under Windows via a > special utility, it would fail there too. Yes, I am clear about that. The sg_* commands that I threw at the device was only to maybe possibly stumble on some information that would help you. > This isn't really a Linux vs. Windows issue as much as it is a > "device doesn't support all the commands" issue. That's not the issue. I couldn't care less about the SCSI commands that fail. My issue on a high level is that when I mount the device, remove the old firmware.bin file, write a new file, and unmount the device - the thing works in Windows but not in Linux. After doing the process in Linux, when reading back the file it has 1024 bytes of 0 prepended to it. After doing the process in Windows, when reading back the file it has no bytes prepended to it. I don't believe this is connected to any SCSI commands that fails or returns strange bytes. > > sdb mounts fine as vfat. .. > It would seem very improbable that this was caused by a USB storage > issue. I'm starting at the bottom of the driver stack. :) Maybe you can help me debug it in any case? Since this is a very small amount of data, might it be informative to add a debug print e.g. for every sector write? > I would check a few things: > > 1) Try fat instead of vfat I just retried the process with explicit mount -t msdos, and got the same result; it doesn't work. > 2) Are you mounting the whole device or a partition of the device? sdb, the whole device. No partitions detected in the dmesg output that I sent. //Peter
Attachment:
pgpuybiLhPXjJ.pgp
Description: PGP signature
