Fwd: CF card I/O errors on Linux

Larry Baker <baker@xxxxxxxx> · Wed, 12 May 2010 14:19:12 -0700

Jeff,

I have been trouble-shooting a misbehaving CF card on Fedora 10 (their  
kernel 2.6.27.41-170.2.117).  It fails in the ATA driver with an  
ABORT.  I have concluded that the card does not properly implement the  
(PIO) READ/WRITE MULTIPLE commands.  As a result of my work in your  
libata-core.c code, I have a few suggestions:

1.  I needed to see more of the IDENTIFY DEVICE response, so I  
modified the probe printout to include words 47, 49, 59, and 80-88,  
like this:

-			       "%s: cfg 49:%04x 82:%04x 83:%04x 84:%04x "
-			       "85:%04x 86:%04x 87:%04x 88:%04x\n",
+			       "%s: cfg 47:%04x 49:%04x 59:%04x "
+ 			       "80-88:%04x %04x %04x %04x %04x %04x %04x %04x %04x\n",
 			       __func__,
-			       id[49], id[82], id[83], id[84],
-			       id[85], id[86], id[87], id[88]);
+			       id[47], id[49], id[59], id[80], id[81], id[82],
+ 			       id[83], id[84], id[85], id[86], id[87], id[88]);

2.  The device I was having trouble with claims to support multi- 
sector transfers, with a maximum Sector Count of 1.  There's not much  
point then, is there?  I suggest adding a test for max >= 2 in the  
conditional where dev->multi_count is assigned:

		/* get current R/W Multiple count setting */
		if ((dev->id[47] >> 8) == 0x80 && (dev->id[59] & 0x100)) {
			unsigned int max = dev->id[47] & 0xff;
			unsigned int cnt = dev->id[59] & 0xff;
+			/* no point unless max >= 2 */
+			if (max >= 2)
			/* only recognize/allow powers of two here */
			if (is_power_of_2(max) && is_power_of_2(cnt))
				if (cnt <= max)
					dev->multi_count = cnt;
		}

3.  In the error recovery code (in libata-eh.c?), I suggest a way to  
recover for devices like the one I've got that improperly implement  
READ/WRITE MULTI commands:

If the failed command is one of the READ/WRITE MULTI commands (entries  
0-4 in ata_rw_cmds[]), and the device response is ABORT, use your  
HORKAGE mechanism to set a flag like ATA_HORKAGE_BROKEN_MULTI to skip  
setting dev->multi_count in libata-core.c (the code in 2., above),  
i.e., disable multi-sector transfers, then reconfigure the device to  
disable multi-sector transfers (call ata_dev_configure(), I guess, so  
the new configuration gets printed out in dmesg) and retry the  
transfer.  Any future calls to ata_dev_configure() for that device  
will not attempt to enable multi-sector transfers because the  
ATA_HORKAGE_BROKEN_MULTI is set:

+		/* don't try to enable R/W multi if it is broken */
+		if (!(dev->horkage & ATA_HORKAGE_BROKEN_MULTI))
		/* get current R/W Multiple count setting */
		if ((dev->id[47] >> 8) == 0x80 && (dev->id[59] & 0x100)) {
			unsigned int max = dev->id[47] & 0xff;
			unsigned int cnt = dev->id[59] & 0xff;
+			/* no point unless max >= 2 */
+			if (max >= 2)
			/* only recognize/allow powers of two here */
			if (is_power_of_2(max) && is_power_of_2(cnt))
				if (cnt <= max)
					dev->multi_count = cnt;
		}

Larry Baker
US Geological Survey
650-329-5608
baker@xxxxxxxx

Begin forwarded message:

From: Larry Baker <baker@xxxxxxxx>
Date: May 11, 2010 10:09:07 PM PDT
To: Raydon Gordon <rgordon@xxxxxxxxxxxx>
Cc: Russ Sell <rwsell@xxxxxxxx>, Joe Fletcher <jfletcher@xxxxxxxx>,  
Tim MacDonald <tmacdonald@xxxxxxxx>, Ian Billings <i.billings@xxxxxxxxxx 
>
Subject: Re: CF card I/O errors on Linux

Ron,

I have analyzed the behavior of Fedora 10 Linux with the M2+ CF 9.0  
Rev: K116 CF card and I have concluded that the I/O errors are not  
due to a bug in Linux, but that the CF card does not properly  
implement the ATA (PIO) READ (WRITE) MULTIPLE command.  It also  
returns a malformed value for word 47 (READ/WRITE MULTIPLE support)  
from the IDENTIFY DEVICE command.

I reported to you before that the ATA standard says an ABORT error  
status means that the READ MULTIPLE command is illegal.  I deduced  
that meant the CF card does not support multi-sector transfers.  (I  
asked you if that was true, and when you did not contradict me, I  
assumed you implicitly confirmed my deduction.)  I speculated that  
the Linux driver was not correctly initializing the device  
multi_count parameter, which I thought could lead to the illegal use  
of the READ MULTIPLE command instead of the READ SECTORS command.

I modified the Fedora 10 Linux ATA device driver to initialize the  
device multi_count parameter to zero.  That didn't help.  I found  
that the CF card was in fact returning device information to the ATA  
driver that multi-sector transfers were supported.  I also verified  
that the ATA driver was correctly reading the multi-sector count  
from the CF card.  However, the only way I could ever get the CF  
card to work was by forcing the ATA driver to use a READ SECTORS  
command instead of a READ MULTIPLE command.

I modified the Fedora 10 Linux ATA device driver to print out the  
ATA IDENTIFY DEVICE data words 47, 49, 59, and 80-88 (in hexadecimal):

   ata5.00: ata_dev_configure: cfg 47:0001 49:2b00 59:0101  
80-88:0078 0000 740a 4004 4000 7429 0004 4003 001f

Word 47 (0001h), bits 0:7 (01h) is the maximum number of sectors for  
READ/WRITE MULTIPLE commands.  The value is 1 (which means there is  
no benefit to READ/WRITE MULTIPLE).

Word 59 (0101h), bit 8 (1) is the "multi-sector transfers enabled"  
state.  If multi-sector transfers are enabled (=1), the multi-sector  
count in bits 0:7 (01h) is the current Sector Count for READ/WRITE  
MULTIPLE commands.  The Sector Count is 1, which, since it is also  
the maximum allowed, is the only legal value.  If the host does not  
alter the Sector Count (to 1, 2, 4, 8, 16, 32, 64, or 128, with a  
SET MULTIPLE MODE), the device can use a preferred Sector Count  
(which can be 0=disabled) after power-up/reset for subsequent READ/ 
WRITE MULTIPLE commands.  That is, the host is not required to issue  
a SET MULTIPLE MODE command if the device enables multi-sector  
transfers by default.  The device information returned by the CF  
card says multi-sector transfers should work.  (In fact, they are  
required to work; see below.)

Recall, the code in the Fedora 10 (Linux kernel version 2.6.27.41)  
ATA device driver (function ata_dev_configure() in drivers/ata/ 
libata-core.c) that sets the device multi_count parameter is:

		if (dev->id[59] & 0x100)
			dev->multi_count = dev->id[59] & 0xff;

I speculated the assignment statement was not being executed for the  
CF card.  That was wrong; it is being executed, and the value 1 is  
being assigned to the device multi_count parameter.

I looked at the code in the latest version of the Linux kernel.  It  
is different:

		/* get current R/W Multiple count setting */
		if ((dev->id[47] >> 8) == 0x80 && (dev->id[59] & 0x100)) {
			unsigned int max = dev->id[47] & 0xff;
			unsigned int cnt = dev->id[59] & 0xff;
			/* only recognize/allow powers of two here */
			if (is_power_of_2(max) && is_power_of_2(cnt))
				if (cnt <= max)
					dev->multi_count = cnt;
		}

It leaves the device multi_count parameter zero (disabling multi- 
sector transfers) if either:

   Word 47, bits 8:15 are not 80h (sanity check of a fixed field  
value)
   Word 59, bit 8 is not set (=1) (the device is currently  
configured to disable multi-sector transfers)
   Word 47, bits 0:7 (max) is not a power of 2 (sanity check)
   Word 59, bits 0:7 (cnt) is not a power of 2 (sanity check)
   Word 59, bits 0:7 (cnt) (current sector count) is greater than  
word 47, bits 0:7 (max) (maximum value allowed for sector count)

Otherwise, it sets the device multi_count parameter to word 59, bits  
0:7 (cnt).

I modified the Fedora 10 Linux ATA driver to use the newer code.   
After that, the device multi_count parameter is zero, which disables  
the use of the READ MULTIPLE command, and the CF card works fine.

I think that is accidental, because:

Word 80 (0078h) sets bits for the ATA version(s) supported.  Bits  
3-6 are set (1).  That means the CF card supports ATA versions 3  
through 6.  All ATA standards since September 1995 (version 3 and  
up) have made READ, WRITE, and SET MULTIPLE commands mandatory.   
Examining the values for words 47 and 59 from the IDENTIFY DEVICE  
command, we can see the reason the device multi_count parameter was  
left set to zero is because bits 8:15 of word 47 are 00h, not 80h.   
The ATA standard versions 3 through 6 (see the portions below)  
specify that bits 8:15 of word 47 must (F=fixed value) be 80h.  The  
CF card violates this requirement of the ATA standard.  The sanity  
check in the Linux ATA driver fails.  This has the inadvertent side  
effect of disabling READ MULTIPLE in the Linux ATA driver.  Thus,  
the flaw in the value for word 47, bits 8:15 in the device  
information coincidentally causes the Linux ATA driver to conceal  
the flaw in the support for multi-sector transfers, and the CF card  
operates correctly in PIO mode on Linux systems that use kernel  
versions later than 2.6.30.

I do not know why the card is not being used in DMA mode on Linux.  
Perhaps there is some setup in the Linux PCMCIA Card and Socket  
Services that I do not know about.  I also do not know how Windows  
XP uses the CF card (READ SECTORS, READ MULTIPLE, or READ DMA).  I  
had no trouble reading the CF card on the same hardware when I  
booted Windows XP (it is setup to boot either 32-bit Windows XP, 64- 
bit Windows XP, or 64-bit Linux).

I was also wrong when I told you earlier that the Linux ATA driver  
had nothing to do with reading the CF card with a USB card reader.   
When I got the CF card to work using the CF card-to-PC card adapter,  
it appeared as a SCSI (/dev/sd) disk.  I thought it would be seen as  
an IDE (/dev/hd) disk.  The Linux SCSI driver is using the ATA  
driver to access the CF card "disk".  This same ATA driver code  
might be used when the CF card is plugged into a USB reader.  I  
don't know yet.  I will not have a chance to work on this again  
until after I return from vacation in a month.

Larry Baker
US Geological Survey
650-329-5608
baker@xxxxxxxx

I downloaded the last drafts of each version of the ATA  
specifications from the Technical Committee T13, AT Attachment, web  
site, http://www.t13.org.  (You have to pay ANSI for copies of the  
final ATA standards.)

ATA version 7 (d1532v1r4b ATA-ATAPI-7.pdf)

6.17.22 Word 47: READ/WRITE MULTIPLE support.
Bits (7:0) of this word define the maximum number of sectors per  
block that the device supports for READ/WRITE MULTIPLE commands. If  
the serial interface is implemented, this field shall be set to 16  
or less.

6.17.28 Word 59: Multiple sector setting
If bit 8 is set to one, bits (7:0) reflect the number of sectors  
currently set to transfer on a READ/WRITE MULTIPLE command. This  
field may default to the preferred value for the device (See 6.52).

6.17.40 Word 80: Major version number
If not 0000h or FFFFh, the device claims compliance with the major  
version(s) as indicated by bits (6:3) being set to one. Values other  
than 0000h and FFFFh are bit significant. Since ATA standards  
maintain downward compatibility, a device may set more than one bit.

6.17.41 Word 81: Minor version number
If an implementor claims that the revision of the standard they used  
to guide their implementation does not need to be reported or if the  
implementation was based upon a standard prior to the ATA-3  
standard, word 81 shall be 0000h or FFFFh.

ATA version 6 (d1410r3b-ATA-ATAPI-6.pdf)

47 M F 15-8 80h
   F 7-0 00h = Reserved
   F 01h-FFh = Maximum number of sectors that shall be transferred  
per interrupt on READ/WRITE MULTIPLE commands

59 M F 15-9 Reserved
   V 8 1 = Multiple sector setting is valid
   V 7-0 xxh = Current setting for number of sectors that shall be  
transferred per interrupt on R/W Multiple command

80 M Major version number
   0000h or FFFFh = device does not report version
   F 15 Reserved
   F 14 Reserved for ATA/ATAPI-14
   F 13 Reserved for ATA/ATAPI-13
   F 12 Reserved for ATA/ATAPI-12
   F 11 Reserved for ATA/ATAPI-11
   F 10 Reserved for ATA/ATAPI-10
   F 9 Reserved for ATA/ATAPI-9
   F 8 Reserved for ATA/ATAPI-8
   F 7 Reserved for ATA/ATAPI-7
   F 6 1 = supports ATA/ATAPI-6
   F 5 1 = supports ATA/ATAPI-5
   F 4 1 = supports ATA/ATAPI-4
   F 3 1 = supports ATA-3
   X 2 Obsolete
   X 1 Obsolete
   F 0 Reserved

81 M F Minor version number
0000h or FFFFh = device does not report version
0001h-FFFEh = see 8.15.41

ATA version 5 (d1321r3-ATA-ATAPI-5.pdf)

47 X 15-8 80h
   R 7-0 00h = Reserved
   F 01h-FFh = Maximum number of sectors that shall be transferred  
per interrupt on READ/WRITE MULTIPLE commands

ATA version 4 (d1153r18-ATA-ATAPI-4.pdf)

47 X 15-8 80h
   R 7-0 00h =Reserved
   F 01h-FFh = Maximum number of sectors that shall be transferred  
per interrupt on READ/WRITE MULTIPLE commands

ATA version 3 (d2008r7b-ATA-3.pdf)

47 X 15-8 Vendor specific
   R 7-0 00h =Reserved
   F 01h-FFh = Maximum number of sectors that can be transferred per  
interrupt on READ/WRITE MULTIPLE commands

Key:
F = the content of the word is fixed and does not change. For  
removable media devices, these values may change when media is  
removed or changed.
V = the contents of the word is variable and may change depending on  
the state of the device or the commands executed by the device.
X = the content of the word is vendor specific and may be fixed or  
variable.
R = the content of the word is reserved and shall be zero.

On May 9, 2010, at 11:47 AM, Raydon Gordon wrote:

Hi Larry,

Thank you for the explanation of your findings with respect to the  
Linux driver. I agree that not initializing the value of “device  
multi_count” could potential spell disaster. I appreciate your  
willingness to apprise me of what you find after patching the driver.

I regard to the USB to CF card issue, I have engaged our  
engineering team, as previously mentioned. They should be looking  
into this issue during the coming week. I will keep you posted.

Best Regards,

Raydon Gordon
rgordon@xxxxxxxxxxxx

STEC, Inc - Field Application Engineer
2107 N First Street, Suite 415
San Jose, CA 95131
(800) 367-7330 x8919 (Office)
(408) 416-6514 (Cell)
(408) 452-7936 (Fax)

From: Larry Baker [mailto:baker@xxxxxxxx]
Sent: Friday, May 07, 2010 3:49 PM
To: Raydon Gordon
Cc: Russ Sell; Joe Fletcher; Tim MacDonald; Ian Billings
Subject: Fwd: CF card I/O errors on Linux

Ray,

I have found the reason for the failure to read your CF card (using  
a CF card-to-PCMCIA card adapter) on our Fedora 9 and 10 Linux  
laptops: the ATA device driver in Fedora 9 and 10 is broken.

As I mentioned before, the device multi_count setting controls  
whether Linux uses the ATA (PIO) READ MULTIPLE command when it  
reads from the CF card.  The device multi_count setting is a device  
configuration setting initialized by the Linux kernel ATA device  
driver (function ata_dev_configure() in drivers/ata/libata-core.c):

                if (dev->id[59] & 0x100)
                        dev->multi_count = dev->id[59] & 0xff;

However, this code alters the device multi_count setting only if  
bit 8 in the IDENTIFY DEVICE word 59 is set (Multiple sector  
setting is valid).  If a device does not support multi-sector  
transfers, bit 8 will be clear, and the device multi_count setting  
will retain its previous value.  The question is, what is that  
value?  Unless it has been initialized somewhere else, it will have  
whatever garbage was in the memory location for the device  
multi_count setting when the device configuration data structure  
was allocated.  That would be a bug, and the symptoms would be:  
even though a device responds that it does not support multi-sector  
transfers, Linux will use them anyway, and the transfer will fail  
with an ABORT error.  That is exactly what is happening to us.

Prior to the code above, the device configuration parameters are  
initialized:

        /* initialize to-be-configured parameters */
        dev->flags &= ~ATA_DFLAG_CFG_MASK;
        dev->max_sectors = 0;
        dev->cdb_len = 0;
        dev->n_sectors = 0;
        dev->cylinders = 0;
        dev->heads = 0;
        dev->sectors = 0;

The device multi_count setting does not appear, leading me to  
suspect it has not been initialized to zero anywhere.  Inspection  
of the same section of code in the latest stable release of the  
Linux kernel (2.6.33.3) shows that a line has been added that  
initializes the device muilti_count setting:

        /* initialize to-be-configured parameters */
        dev->flags &= ~ATA_DFLAG_CFG_MASK;
        dev->max_sectors = 0;
        dev->cdb_len = 0;
        dev->n_sectors = 0;
        dev->cylinders = 0;
        dev->heads = 0;
        dev->sectors = 0;
        dev->multi_count = 0;

Fedora 10 Linux uses kernel release 2.6.27.41-170.  The first Linux  
release that contains the missing line is 2.6.30.  Thus, any ATA  
device that requires PIO transfers and does not support multi- 
sector transfers will probably fail for Linux kernels older than  
release 2.6.30.  I will try to patch the Linux ATA device drivers  
on our Fedora 9 and Fedora 10 laptops and verify that this explains  
the errors we have been getting.

CF cards inserted in CF card-to-PCMCIA card adapters into a PCMCIA  
card slot appear to Linux as ATA devices (/dev/hd devices).  CF  
cards inserted in USB CF card readers appear to Linux as SCSI  
devices (/dev/sd devices).  That is not the code I have been  
looking at.  The problems we have encountered reading CF cards  
using USB CF card readers uses different device drivers.  I'll work  
on that next when I can find a test setup that works and one that  
fails.

Larry Baker
US Geological Survey
650-329-5608
baker@xxxxxxxx

Begin forwarded message:

From: Larry Baker <baker@xxxxxxxx>
Date: May 6, 2010 8:07:22 PM PDT
To: Raydon Gordon <rgordon@xxxxxxxxxxxx>
Cc: Russ Sell <rwsell@xxxxxxxx>, Joe Fletcher <jfletcher@xxxxxxxx>,  
Tim MacDonald <tmacdonald@xxxxxxxx>
Subject: Re: CF card I/O errors on Linux

Ray,

I have decoded the commands being sent to the CF card.  The Linux  
message log file sequence repeats:

... ata10.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
... ata10.00: cmd c4/00:20:00:00:00/00:00:00:00:00/e0 tag 0 pio  
16384 in
...         res 51/04:20:00:00:00/00:00:00:00:00/e0 Emask 0x1  
(device error)
... ata10.00: status: { DRDY ERR }
... ata10.00: error: { ABRT }
... ata10.00: configured for PIO0
... ata10: EH complete

The cmd=C4h command being executed is (PIO) READ MULTIPLE.  The  
arguments are Count=20h (32), LBA=0, Device=E0h (OBSOLETE_BIT_15 +  
LBA_BIT + OBSOLETE_BIT13).

The res=51h response is DRDY (Device Ready) + DRQ (Data Request) +  
ERR (Error).  The error bits=04h are ABRT (Abort).

The ATA spec (http://www.t13.org/Documents/UploadedDocuments/docs2006/D1699r3f-ATA8-ACS.pdf 
) for READ MULTIPLE (page 155) says:

7.30 READ MULTIPLE - C4h, PIO data-in

7.30.2 Description

If the READ MULTIPLE command is received when read multiple  
commands are disabled, the READ MULTIPLE
operation shall be rejected with command aborted.

The ATA spec for the Abort error bit (page 53) says:

6.2 Error Bits

6.2.1 Abort (ABRT)

Error bit 2. Abort shall be set to one if the command is not  
supported. Abort may be set to one if the device is not
able to complete the action requested by the command. Abort shall  
also be set to one if an address outside of
the range of user-accessible addresses is requested if IDNF is not  
set to one.

From this, I conclude that the "M2+ CF 9.0 Rev: K116" CF card does  
not support the ATA (PIO) READ MULTIPLE command.  Is that true?

I found the Linux kernel device driver code (function  
ata_rwcmd_protocol() in drivers/ata/libata-core.c) that selects PIO  
MULTI vs. PIO transfers.  It tests the ATA device configuration  
field "multi_count" to decide whether to use (PIO) multi-sector  
transfers.  multi_count is set by the Linux kernel ATA device  
driver (function ata_dev_configure(), also in drivers/ata/libata- 
core.c):

                if (dev->id[59] & 0x100)
                        dev->multi_count = dev->id[59] & 0xff;

This code tests whether bit 8 (Multiple sector setting is valid;  
see page 92 in the ATA spec) is set in id[59] (word 59 of the  
response to the IDENTIFY DEVICE command), and, if so, sets the  
value of multi_count to the (presumably non-zero) value in the  
lower 8 bits in id[59] (Current setting for number of logical  
sectors that shall be transferred per DRQ data block on READ/WRITE  
Multiple commands).

From this, I conclude that the "M2+ CF 9.0 Rev: K116" CF card is  
responding to the DEVICE INQUIRY command that it does support the  
ATA (PIO) READ MULTIPLE command.  Is that true?

If both these conclusions are true, they are inconsistent.  Do you  
agree with my conclusions?  Do you have any way to test this  
hypothesis?

Larry Baker
US Geological Survey
650-329-5608
baker@xxxxxxxx

On May 6, 2010, at 4:38 PM, Raydon Gordon wrote:

Larry,

I will have to check.

Would it be possible for you to send me a photo of the backside of  
the card, which contains version and part number information?

Also, which brand and model notebook computer are you using?

Thanks!

Best Regards,

Raydon Gordon
rgordon@xxxxxxxxxxxx

STEC, Inc - Field Application Engineer
2107 N First Street, Suite 415
San Jose, CA 95131
(800) 367-7330 x8919 (Office)
(408) 416-6514 (Cell)
(408) 452-7936 (Fax)

-----Original Message-----
From: Larry Baker [mailto:baker@xxxxxxxx]
Sent: Thursday, May 06, 2010 4:32 PM
To: Raydon Gordon
Subject: Re: CF card I/O errors on Linux

Ray,

Do you have any laptop Linux systems in house with PCMCIA card slots?
I can send you a CF card-to-PCMCIA card adapter that I have tried (I
tried 3 or 4 of them).

Also, which distributions/versions of Linux do you use?  I believe  
the
two systems we have (both laptops) run Fedora: one runs Fedora 9, the
other runs Fedora 10.

Larry Baker
US Geological Survey
650-329-5608
baker@xxxxxxxx

On May 6, 2010, at 4:26 PM, Raydon Gordon wrote:

> Ok, Larry. Since we have not seen this failure in-house on the  
Linux
> systems we run, I think it is best to look at the CF card reader.  
At
> least this way, we should be able to replicate the problem and  
track
> down the root cause.
>
> It is no more difficult for us to diagnose this failure on a  
"cheap"
> card reader than it would be on a full-fledged system. We use an
> interposer card and a bus analyzer, so there should not be a  
problem.
>
> Best Regards,
>
> Raydon Gordon
> rgordon@xxxxxxxxxxxx
>
> STEC, Inc - Field Application Engineer
> 2107 N First Street, Suite 415
> San Jose, CA 95131
> (800) 367-7330 x8919 (Office)
> (408) 416-6514 (Cell)
> (408) 452-7936 (Fax)
>
> -----Original Message-----
> From: Larry Baker [mailto:baker@xxxxxxxx]
> Sent: Thursday, May 06, 2010 11:24 AM
> To: Raydon Gordon
> Subject: Re: CF card I/O errors on Linux
>
> Ray,
>
> No problem.  I'll try to spend some time to decode the error  
messages
> I included for you.  Note: the errors I sent were not using an CF  
card
> reader, but a CF card-to-PCMCIA card adapter, which, I believe,  
is not
> an active device.  That is, it passes the pins on the CF card to  
the
> proper pins in a PCMCIA card slot.  Presumably, that setup should  
have
> worked, and should be simpler to diagnose than a (likely, cheap) CF
> card reader.
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> baker@xxxxxxxx
>
> On May 5, 2010, at 8:19 PM, Raydon Gordon wrote:
>
>> Larry,
>>
>> Sorry for the delay in responding. We are currently in the process
>> of investigating the alleged CF card reader compatibility issue.
>>
>> At this time, the root cause has not been identified as we have  
not
>> been able to witness the problem first hand. I'm not saying that  
it
>> doesn't exist, just that until now we have not seen a problem with
>> any CF card readers. I have purchased a card reader suspected of
>> exhibiting this issue and we will begin examining its interaction
>> with the new STEC CF cards shortly.
>>
>> We will be able to provide more insight once our investigation is
>> complete. At this time I do not have an ETA, however, I can assure
>> you that this reported problem is being investigated.
>>
>> Best Regards,
>>
>> Raydon Gordon
>> rgordon@xxxxxxxxxxxx
>>
>> STEC, Inc - Field Application Engineer
>> 2107 N First Street, Suite 415
>> San Jose, CA 95131
>> (800) 367-7330 x8919 (Office)
>> (408) 416-6514 (Cell)
>> (408) 452-7936 (Fax)
>>
>> -----Original Message-----
>> From: Jesse Molina
>> Sent: Monday, April 19, 2010 3:45 PM
>> To: Larry Baker; Mark Swiney
>> Cc: Raydon Gordon
>> Subject: RE: CF card I/O errors on Linux
>>
>> Hi Larry,
>>
>> I am cc'ing Raydon Gordon who is our local FAE. Raydon can take a
>> look at things and provide some insight. Thanks.
>>
>> Best Regards,
>> Jesse
>>
>> Jesse Molina
>> Field Sales Engineer
>> STEC, Inc.
>> Tel: 800-367-7330 x 8916
>> Cell: 408-605-5583
>> Website: www.stec-inc.com
>>
>>
>> -----Original Message-----
>> From: Larry Baker [mailto:baker@xxxxxxxx]
>> Sent: Monday, April 19, 2010 12:04 PM
>> To: Mark Swiney; Jesse Molina
>> Subject: CF card I/O errors on Linux
>>
>> We have several M2+ CF 9.0 Rev: K116 cards.  They were supplied  
to us
>> by an instrument manufacturer (Refraction Technology) to record
>> seismic data.  We use either USB CF card readers or CF-to-PCCARD
>> adapters to connect the CF cards to Linux laptops for playback.   
They
>> seem to be very temperamental.  They work with some USB CF card
>> readers, but not with others.  Sometimes they take an  
excruciatingly
>> long time to play back.  I have uniformly bad luck using them with
>> any
>> of the many (5V and low-voltage keyed) CF-to-PCCARD adapters.   
(The
>> Linux kernel messages are below.  I have not tried to decode the
>> SCSI/
>> ATA responses.)  The problems do not seem to appear when we use
>> Windows XP -- only Linux -- I don't know why.  However, our data
>> management systems are all Linux; we do not use Windows.  The  
Linux
>> systems I have tried are Fedora 9 and 10.  We do not have this
>> problem
>> with other brands of CF cards (e.g., Kingston).  However, our
>> instrument supplier uses your cards.  Do your engineers have any
>> comments or suggestions?
>>
>> Larry Baker
>> US Geological Survey
>> 650-329-5608
>> baker@xxxxxxxx
>>
>> Portions of the Fedora Linux 10 /var/log/messages file with error
>> messages and drive status information following insertion of CF- 
to-
>> PCCARD adapter:
>>
>> Apr 19 04:45:42 necv50 kernel: ata10.00: exception Emask 0x0  
SAct 0x0
>> SErr 0x0 action 0x0
>> Apr 19 04:45:42 necv50 kernel: ata10.00: cmd
>> c4/00:20:00:00:00/00:00:00:00:00/e0 tag 0 pio 16384 in
>> Apr 19 04:45:42 necv50 kernel:         res
>> 51/04:20:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
>> Apr 19 04:45:42 necv50 kernel: ata10.00: status: { DRDY ERR }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: error: { ABRT }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: configured for PIO0
>> Apr 19 04:45:42 necv50 kernel: ata10: EH complete
>> Apr 19 04:45:42 necv50 kernel: ata10.00: exception Emask 0x0  
SAct 0x0
>> SErr 0x0 action 0x0
>> Apr 19 04:45:42 necv50 kernel: ata10.00: cmd
>> c4/00:20:00:00:00/00:00:00:00:00/e0 tag 0 pio 16384 in
>> Apr 19 04:45:42 necv50 kernel:         res
>> 51/04:20:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
>> Apr 19 04:45:42 necv50 kernel: ata10.00: status: { DRDY ERR }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: error: { ABRT }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: configured for PIO0
>> Apr 19 04:45:42 necv50 kernel: ata10: EH complete
>> Apr 19 04:45:42 necv50 kernel: ata10.00: exception Emask 0x0  
SAct 0x0
>> SErr 0x0 action 0x0
>> Apr 19 04:45:42 necv50 kernel: ata10.00: cmd
>> c4/00:20:00:00:00/00:00:00:00:00/e0 tag 0 pio 16384 in
>> Apr 19 04:45:42 necv50 kernel:         res
>> 51/04:20:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
>> Apr 19 04:45:42 necv50 kernel: ata10.00: status: { DRDY ERR }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: error: { ABRT }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: configured for PIO0
>> Apr 19 04:45:42 necv50 kernel: ata10: EH complete
>> Apr 19 04:45:42 necv50 kernel: ata10.00: exception Emask 0x0  
SAct 0x0
>> SErr 0x0 action 0x0
>> Apr 19 04:45:42 necv50 kernel: ata10.00: cmd
>> c4/00:20:00:00:00/00:00:00:00:00/e0 tag 0 pio 16384 in
>> Apr 19 04:45:42 necv50 kernel:         res
>> 51/04:20:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
>> Apr 19 04:45:42 necv50 kernel: ata10.00: status: { DRDY ERR }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: error: { ABRT }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: configured for PIO0
>> Apr 19 04:45:42 necv50 kernel: ata10: EH complete
>> Apr 19 04:45:42 necv50 kernel: ata10.00: exception Emask 0x0  
SAct 0x0
>> SErr 0x0 action 0x0
>> Apr 19 04:45:42 necv50 kernel: ata10.00: cmd
>> c4/00:20:00:00:00/00:00:00:00:00/e0 tag 0 pio 16384 in
>> Apr 19 04:45:42 necv50 kernel:         res
>> 51/04:20:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
>> Apr 19 04:45:42 necv50 kernel: ata10.00: status: { DRDY ERR }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: error: { ABRT }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: configured for PIO0
>> Apr 19 04:45:42 necv50 kernel: ata10: EH complete
>> Apr 19 04:45:42 necv50 kernel: ata10.00: exception Emask 0x0  
SAct 0x0
>> SErr 0x0 action 0x0
>> Apr 19 04:45:42 necv50 kernel: ata10.00: cmd
>> c4/00:20:00:00:00/00:00:00:00:00/e0 tag 0 pio 16384 in
>> Apr 19 04:45:42 necv50 kernel:         res
>> 51/04:20:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
>> Apr 19 04:45:42 necv50 kernel: ata10.00: status: { DRDY ERR }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: error: { ABRT }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: configured for PIO0
>> Apr 19 04:45:42 necv50 kernel: sd 9:0:0:0: [sdb] Result:
>> hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
>> Apr 19 04:45:42 necv50 kernel: sd 9:0:0:0: [sdb] Sense Key :  
Aborted
>> Command [current] [descriptor]
>> Apr 19 04:45:42 necv50 kernel: Descriptor sense data with sense
>> descriptors (in hex):
>> Apr 19 04:45:42 necv50 kernel:        72 0b 00 00 00 00 00 0c 00  
0a
>> 80
>> 00 00 00 00 00
>> Apr 19 04:45:42 necv50 kernel:        00 00 00 00
>> Apr 19 04:45:42 necv50 kernel: sd 9:0:0:0: [sdb] Add. Sense: No
>> additional sense information
>> Apr 19 04:45:42 necv50 kernel: end_request: I/O error, dev sdb,
>> sector 0
>> Apr 19 04:45:42 necv50 kernel: ata10: EH complete
>> Apr 19 04:45:42 necv50 kernel: ata10.00: exception Emask 0x0  
SAct 0x0
>> SErr 0x0 action 0x0
>> Apr 19 04:45:42 necv50 kernel: ata10.00: cmd
>> c4/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
>> Apr 19 04:45:42 necv50 kernel:         res
>> 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
>> Apr 19 04:45:42 necv50 kernel: ata10.00: status: { DRDY ERR }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: error: { ABRT }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: configured for PIO0
>> Apr 19 04:45:42 necv50 kernel: ata10: EH complete
>> Apr 19 04:45:42 necv50 kernel: ata10.00: exception Emask 0x0  
SAct 0x0
>> SErr 0x0 action 0x0
>> Apr 19 04:45:42 necv50 kernel: ata10.00: cmd
>> c4/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
>> Apr 19 04:45:42 necv50 kernel:         res
>> 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
>> Apr 19 04:45:42 necv50 kernel: ata10.00: status: { DRDY ERR }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: error: { ABRT }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: configured for PIO0
>> Apr 19 04:45:42 necv50 kernel: ata10: EH complete
>> Apr 19 04:45:42 necv50 kernel: ata10.00: exception Emask 0x0  
SAct 0x0
>> SErr 0x0 action 0x0
>> Apr 19 04:45:42 necv50 kernel: ata10.00: cmd
>> c4/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
>> Apr 19 04:45:42 necv50 kernel:         res
>> 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
>> Apr 19 04:45:42 necv50 kernel: ata10.00: status: { DRDY ERR }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: error: { ABRT }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: configured for PIO0
>> Apr 19 04:45:42 necv50 kernel: ata10: EH complete
>> Apr 19 04:45:42 necv50 kernel: ata10.00: exception Emask 0x0  
SAct 0x0
>> SErr 0x0 action 0x0
>> Apr 19 04:45:42 necv50 kernel: ata10.00: cmd
>> c4/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
>> Apr 19 04:45:42 necv50 kernel:         res
>> 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
>> Apr 19 04:45:42 necv50 kernel: ata10.00: status: { DRDY ERR }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: error: { ABRT }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: configured for PIO0
>> Apr 19 04:45:42 necv50 kernel: ata10: EH complete
>> Apr 19 04:45:42 necv50 kernel: ata10.00: exception Emask 0x0  
SAct 0x0
>> SErr 0x0 action 0x0
>> Apr 19 04:45:42 necv50 kernel: ata10.00: cmd
>> c4/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
>> Apr 19 04:45:42 necv50 kernel:         res
>> 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
>> Apr 19 04:45:42 necv50 kernel: ata10.00: status: { DRDY ERR }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: error: { ABRT }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: configured for PIO0
>> Apr 19 04:45:42 necv50 kernel: ata10: EH complete
>> Apr 19 04:45:42 necv50 kernel: ata10.00: exception Emask 0x0  
SAct 0x0
>> SErr 0x0 action 0x0
>> Apr 19 04:45:42 necv50 kernel: ata10.00: cmd
>> c4/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 4096 in
>> Apr 19 04:45:42 necv50 kernel:         res
>> 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
>> Apr 19 04:45:42 necv50 kernel: ata10.00: status: { DRDY ERR }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: error: { ABRT }
>> Apr 19 04:45:42 necv50 kernel: ata10.00: configured for PIO0
>> Apr 19 04:45:42 necv50 kernel: sd 9:0:0:0: [sdb] Result:
>> hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
>> Apr 19 04:45:42 necv50 kernel: sd 9:0:0:0: [sdb] Sense Key :  
Aborted
>> Command [current] [descriptor]
>> Apr 19 04:45:42 necv50 kernel: Descriptor sense data with sense
>> descriptors (in hex):
>> Apr 19 04:45:42 necv50 kernel:        72 0b 00 00 00 00 00 0c 00  
0a
>> 80
>> 00 00 00 00 00
>> Apr 19 04:45:42 necv50 kernel:        00 00 00 00
>> Apr 19 04:45:42 necv50 kernel: sd 9:0:0:0: [sdb] Add. Sense: No
>> additional sense information
>> Apr 19 04:45:42 necv50 kernel: end_request: I/O error, dev sdb,
>> sector 0
>> Apr 19 04:45:42 necv50 kernel: ata10: EH complete
>> Apr 19 04:45:42 necv50 kernel: sd 9:0:0:0: [sdb] 3844512 512-byte
>> hardware sectors (1968 MB)
>> Apr 19 04:45:42 necv50 kernel: sd 9:0:0:0: [sdb] Write Protect  
is off
>> Apr 19 04:45:42 necv50 kernel: sd 9:0:0:0: [sdb] Write cache:
>> enabled,
>> read cache: enabled, doesn't support DPO or FUA
>> Apr 19 04:45:42 necv50 kernel: sd 9:0:0:0: [sdb] 3844512 512-byte
>> hardware sectors (1968 MB)
>> Apr 19 04:45:42 necv50 kernel: sd 9:0:0:0: [sdb] Write Protect  
is off
>> Apr 19 04:45:42 necv50 kernel: sd 9:0:0:0: [sdb] Write cache:
>> enabled,
>> read cache: enabled, doesn't support DPO or FUA
>>
>>
>> PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED
>>
>> This electronic transmission, and any documents attached hereto,  
may
>> contain confidential, proprietary and/or legally privileged
>> information. The information is intended only for use by the
>> recipient named above. If you received this electronic message in
>> error, please notify the sender and delete the electronic message.
>> Any disclosure, copying, distribution, or use of the contents of
>> information received in error is strictly prohibited, and  
violators
>> will be pursued legally.
>
>
> PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED
>
> This electronic transmission, and any documents attached hereto,  
may
> contain confidential, proprietary and/or legally privileged
> information. The information is intended only for use by the
> recipient named above. If you received this electronic message in
> error, please notify the sender and delete the electronic message.
> Any disclosure, copying, distribution, or use of the contents of
> information received in error is strictly prohibited, and violators
> will be pursued legally.

PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED

This electronic transmission, and any documents attached hereto,  
may contain confidential, proprietary and/or legally privileged  
information. The information is intended only for use by the  
recipient named above. If you received this electronic message in  
error, please notify the sender and delete the electronic message.  
Any disclosure, copying, distribution, or use of the contents of  
information received in error is strictly prohibited, and violators  
will be pursued legally.

PROPRIETARY-CONFIDENTIAL INFORMATION INCLUDED

This electronic transmission, and any documents attached hereto,  
may contain confidential, proprietary and/or legally privileged  
information. The information is intended only for use by the  
recipient named above. If you received this electronic message in  
error, please notify the sender and delete the electronic message.  
Any disclosure, copying, distribution, or use of the contents of  
information received in error is strictly prohibited, and violators  
will be pursued legally.

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html