On Wed, 3 Jan 2007, Vaclav Barta wrote:

> On Tuesday 02 January 2007 23:21, Alan Stern wrote:
> > Comparing the logs again, I see that Windows uses a 512-byte read to load
> > the partition sector whereas Linux uses a 4096-byte read.  It's reasonable
> > to assume the device likes one and doesn't like the other.
> >
> > Unfortunately there's no way to make Linux use a 512-byte read.  However
> > it is possible to verify the assumption.  You can use the PLscsi program,
> > available from
> >
> >     http://members.aol.com/plscsi/linux/
> >
> > Here's what you should do.  First, rename the sd_mod.ko kernel module, or
> I actually had SCSI disk support directly in the kernel, but changed to 
> module 
> (and renamed it).
> 
> > move it from its standard location, so that it won't get loaded
> > automatically.  Then plug in the device and do "modprobe sg".  Then issue
> > the following command (as root):
> >
> >     plscsi -v -x '28 0 0 0 0 0 0 0 1 0' -i 512 /dev/sg0
> >
> > Make sure you copy the command string correctly!  You will probably have
> > to run it twice; the first time through the device will report that it was
> > just reset but the second time it should work.
> On first try, it actually reported the following:
> quanxi plscsi # ./plscsi -v -x '28 0 0 0 0 0 0 0 1 0' -i 512 /dev/sg0
> x 00000000 28 00 00:00:00:00 00 00:01 00 .. .. .. .. .. .. "(@@@@@@@A@"
> x 00000000 50:7E:26:08 00:00:00:00 00:00:00:00 FF:FF:FF:FF "P~&H@@@@@@@@????"
...
> x 000001F0 FF:FF:FF:FF FF:FF:FF:FF 28:00:00:00 00:00:00:00 "????????(@@@@@@@"
> x 00000000 70:00:06:00 00:00:00:0A 00:00:00:00 28:00 .. .. "[EMAIL 
> PROTECTED]@@@@J@@@@(@"
> // x 6 28 sense // x200 (512) residue
> // -x0102 = -258 = plscsi.main exit int
> 
> (The ellipses and comments are actually part of the output - I didn't edit 
> anything).

I did.  The values were meaningless, just random garbage sitting in
memory.  They were not data sent by the device.

In fact the command failed, as you can see from the final sense data,
residue, and status.  In this case 0x6 0x28 means "Not ready to ready
transition" -- in other words, the device is telling you that it was just
reset.

> But it's true that the output subsequently changed:
> x 00000000 28 00 00:00:00:00 00 00:01 00 .. .. .. .. .. .. "(@@@@@@@A@"
> x 00000000 79:7A:7A:FF 79:7A:7A:FF 79:7A:7A:FF 79:7A:7A:FF "yzz?yzz?yzz?yzz?"
...
> x 000001F0 77:78:78:FF 77:78:78:FF 77:78:78:FF 77:78:78:FF "wxx?wxx?wxx?wxx?"
> x 00000000 70:00:03:00 00:00:00:0A 00:00:00:00 11:00 .. .. "[EMAIL 
> PROTECTED]@@@@J@@@@Q@"
> // x 3 11 sense // x200 (512) residue
> // -x0102 = -258 = plscsi.main exit int
> 
> Does that help?

No.  It's no better than before.  The sense codes are the same as you
have been getting all along: 0x3 0x11, meaning "Medium error,
unrecovered read error".


All right.  Here's a list of plscsi commands that are exactly equivalent 
to what Windows sent in your SnoopyPro log (except for the fact that Linux 
automatically sends an INQUIRY command to each LUN; there's no way to 
avoid it).  You can add a -v flag to the commands if you want.  Note the 
difference between /dev/sg0 and /dev/sg1.

        plscsi -x '12 0 0 0 24 0' -i 36 /dev/sg0
        plscsi -x '23 0 0 0 0 0 0 0 fc 0' -i 252 /dev/sg0
        plscsi -x '23 0 0 0 0 0 0 0 fc 0' -i 252 /dev/sg0

        plscsi -x '12 0 0 0 24 0' -i 36 /dev/sg1
        plscsi -x '23 0 0 0 0 0 0 0 fc 0' -i 252 /dev/sg1
        plscsi -x '23 0 0 0 0 0 0 0 fc 0' -i 252 /dev/sg1

        plscsi -x '25 0 0 0 0 0 0 0 0 0' -i 8 /dev/sg0
        plscsi -x '28 0 0 0 0 0 0 0 1 0' -i 512 /dev/sg0

(That last command is what failed before.)

        plscsi -x '1a 0 1c 0 c0 0' -i 192 /dev/sg0
        plscsi -x '1a 0 3f 0 c0 0' -i 192 /dev/sg0
        plscsi -x '25 0 0 0 0 0 0 0 0 0' -i 8 /dev/sg0
        plscsi -x '25 0 0 0 0 0 0 0 0 0' -i 8 /dev/sg0
        plscsi -x '28 0 0 0 0 0 0 0 1 0' -i 512 /dev/sg0
        plscsi -x '28 0 0 0 0 0 0 0 1 0' -i 512 /dev/sg0
        plscsi -x '25 0 0 0 0 0 0 0 0 0' -i 8 /dev/sg0
        plscsi -x '25 0 0 0 0 0 0 0 0 0' -i 8 /dev/sg0
        plscsi -x '28 0 0 0 0 0 0 0 1 0' -i 512 /dev/sg0

        plscsi -x '25 0 0 0 0 0 0 0 0 0' -i 8 /dev/sg1
        plscsi -x '28 0 0 0 0 0 0 0 1 0' -i 512 /dev/sg1
        plscsi -x '1a 0 1c 0 c0 0' -i 192 /dev/sg1
        plscsi -x '1a 0 3f 0 c0 0' -i 192 /dev/sg1
        plscsi -x '25 0 0 0 0 0 0 0 0 0' -i 8 /dev/sg1
        plscsi -x '25 0 0 0 0 0 0 0 0 0' -i 8 /dev/sg1
        plscsi -x '28 0 0 0 0 0 0 0 1 0' -i 512 /dev/sg1
        plscsi -x '28 0 0 0 0 0 0 0 1 0' -i 512 /dev/sg1
        plscsi -x '25 0 0 0 0 0 0 0 0 0' -i 8 /dev/sg1
        plscsi -x '25 0 0 0 0 0 0 0 0 0' -i 8 /dev/sg1
        plscsi -x '28 0 0 0 0 0 0 0 1 0' -i 512 /dev/sg0

Etc.  You may have noticed that Windows repeats itself a lot.  I have no 
idea why it does.

By the way, I was wrong about the write-protect settings.  Looking through 
the SnoopyPro log again, it shows that both LUNs are write-enabled.  If 
you use -v on the two plscsi lines that contain '1a 0 3f 0 c0 0', you'll 
see whether the result is the same here.

However there is one significant difference between Linux and Windows 
which may go some way toward explaining the write-protect values.  To make 
Linux work like Windows in this regard, apply the patch below.  You should 
run both a normal test (with sd_mod loaded) and the tests above with this 
patch.

Alan Stern


Index: usb-2.6/drivers/usb/storage/scsiglue.c
===================================================================
--- usb-2.6.orig/drivers/usb/storage/scsiglue.c
+++ usb-2.6/drivers/usb/storage/scsiglue.c
@@ -110,23 +110,6 @@ static int slave_configure(struct scsi_d
         * the end, scatter-gather buffers follow page boundaries. */
        blk_queue_dma_alignment(sdev->request_queue, (512 - 1));
 
-       /* Set the SCSI level to at least 2.  We'll leave it at 3 if that's
-        * what is originally reported.  We need this to avoid confusing
-        * the SCSI layer with devices that report 0 or 1, but need 10-byte
-        * commands (ala ATAPI devices behind certain bridges, or devices
-        * which simply have broken INQUIRY data).
-        *
-        * NOTE: This means /dev/sg programs (ala cdrecord) will get the
-        * actual information.  This seems to be the preference for
-        * programs like that.
-        *
-        * NOTE: This also means that /proc/scsi/scsi and sysfs may report
-        * the actual value or the modified one, depending on where the
-        * data comes from.
-        */
-       if (sdev->scsi_level < SCSI_2)
-               sdev->scsi_level = sdev->sdev_target->scsi_level = SCSI_2;
-
        /* Many devices have trouble transfering more than 32KB at a time,
         * while others have trouble with more than 64K. At this time we
         * are limiting both to 32K (64 sectores).
@@ -176,7 +159,9 @@ static int slave_configure(struct scsi_d
                 * a Get-Max-LUN request, we won't lose much by setting the
                 * revision level down to 2.  The only devices that would be
                 * affected are those with sparse LUNs. */
-               sdev->scsi_level = sdev->sdev_target->scsi_level = SCSI_2;
+               if (sdev->scsi_level > SCSI_2)
+                       sdev->scsi_level = sdev->sdev_target->scsi_level =
+                                       SCSI_2;
 
                /* USB-IDE bridges tend to report SK = 0x04 (Non-recoverable
                 * Hardware Error) when any low-level error occurs,


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Reply via email to