Problems with Linux SATA driver and ARC-770 IDE Bridge chip

Problems with Linux SATA driver and ARC-770 IDE Bridge chip

[sjackerman]

Hello-

We manufacture a SATA to CF adaptor that uses an Acard Technology ARC-770 SATA to IDE bridge chip:

http://www.acscontrol.com/Index_ACS.asp?Page=/Pages/Products/CompactFlash/SATA_To_CF_Adapter.htm

The adaptor works correctly and can be 'seen' in the BIOS, in DOS, in Windows XP, XP MCE and Vista. However the adaptor doesn't work correctly or can't be 'seen' in Linux. A similiar adaptor based upon a Marvell bridge chip works correctly in Linux.

We have now verified that this doesn't work on an in-house Intel 865 chipset motherboard running RIP Linux v2.6.20. A customer has verified that this also doesn't work on Intel 875 or Via chipset motherboards under Linux.

Here are the Linux Kernel error messages that are produced by this kernel running on a Intel D865GLC motherboard trying to talk to our ARC-770 based adaptor on SATA-0 :

ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE002 bmdma 0xDC08 irq 10
scsi2 : ata_piix
ata1.00: CFA, max PIO4, 8005536 sectors: LBA
ata1.00: ata1: dev 0 multi count 0
ata1.00: qc timeout (cmd 0xef)
ata1.00: failed to set xfermode (err_mask=0x4)
ata1.00: limiting speed to PIO3
ata1: failed to recover some devices, retrying in 5 secs
ata1.00: qc timeout (cmd 0xef)
ata1.00: failed to set xfermode (err_mask=0x4)
ata1.00: limiting speed to PIO0
ata1: failed to recover some devices, retrying in 5 secs
ata1.00: qc timeout (cmd 0xef)
ata1.00: failed to set xfermode (err_mask=0x4)
ata1.00: disabled
scsi3 : ata_piix
ATA: abnormal status 0x7F on port 0xE407

You can see that that our ARC-770 based adaptor with 4GB Sandisk CF
card failed to respond to the ATA Identify command. However the BIOS, DOS and Windows can identify and use this same CF card and adaptor. The same CF card
placed into a no-name adaptor that uses a Marvell 88SA8040 bridge chip works
with no problems.

Here is the customer's error attempting the same thing but on an Intel
875 based chipset:

ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
scsi0 :
ata_piix
ATA: abnormal status 0x7F on port 0xC007
scsi1 : ata_piix
ata2: port is slow to respond, please be patient (Status 0xd0)
ata2: port failed to respond (30 secs, Status 0xd0)
ATA: abnormal status 0xD0 on port 0xC807
ATA: abnormal status 0xD0 on port 0xC807
ATA: abnormal status 0xD0 on port 0xC807
ATA: abnormal status 0xD0 on port 0xC807
ATA: abnormal status 0xD0 on port 0xC807
ata2.00: qc timeout (cmd 0xec)
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: port is slow to respond, please be patient (Status 0xd0)
ata2: port failed to respond (30 secs, Status 0xd0)
ATA: abnormal status 0xD0 on port 0xC807
ATA: abnormal status 0xD0 on port 0xC807
ATA: abnormal status 0xD0 on port 0xC807
ATA: abnormal status 0xD0 on port 0xC807
ATA: abnormal status 0xD0 on port 0xC807
ata2.00: qc timeout (cmd 0xec)
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: port is slow to respond, please be patient (Status 0xd0)
ata2: port failed to respond (30 secs, Status 0xd0)

According to the Acard technology support engineer who evaluated the problem:

"Intel chipset assigns an "nIEN (interrupt)" value 1 (disable), which is not compliant with SATA spec, and causes device failure.  Marvell chip has been revised for several versions, and it does something to ignore this assignment since a certain revision, prior to the directives of SATA authority.  That's why Marvel chip works regardless of MB chipset.  However, In ACARD, we follow the directives and spec from SATA authority, unless we receive the notification, we won't do anything against the rules."

I have asked for additional clarification from Acard, but it has not been forthcoming.

In attempting to resolve this for our Linux customers, I sent an e-mail to Greg K-H in response to his Free Linux Driver Announcement: 

http://www.kroah.com/log/linux/free_drivers.html

Greg responded and suggested that I post a request for assistance on this mailing list, so here it is.

I would be willing to supply one of our adaptors and a CF card to someone who can revise the driver to work with the Acard ARC-770 and have the corrected driver included in future Linux releases.

Thank you,

Steven J. Ackerman
ACS, Sarasota, FL
http://www.acscontrol.com
steve@acscontrol.com
(941)377-5775




--
This message was sent on behalf of sjackerman@comcast.net at openSubscriber.com
http://www.opensubscriber.com/messages/linux-ide@vger.kernel.org/topic.html

Re: Problems with Linux SATA driver and ARC-770 IDE Bridge chip

[Tejun Heo]

sjackerman@comcast.net wrote:
> Hello-
> 
> We manufacture a SATA to CF adaptor that uses an Acard Technology
> ARC-770 SATA to IDE bridge chip:
> 
> http://www.acscontrol.com/Index_ACS.asp?Page=/Pages/Products/CompactFlash/SATA_To_CF_Adapter.htm
> 
> 
> The adaptor works correctly and can be 'seen' in the BIOS, in DOS, in
> Windows XP, XP MCE and Vista. However the adaptor doesn't work
> correctly or can't be 'seen' in Linux. A similiar adaptor based upon
> a Marvell bridge chip works correctly in Linux.
> 
> We have now verified that this doesn't work on an in-house Intel 865
> chipset motherboard running RIP Linux v2.6.20. A customer has
> verified that this also doesn't work on Intel 875 or Via chipset
> motherboards under Linux.
> 
> Here are the Linux Kernel error messages that are produced by this
> kernel running on a Intel D865GLC motherboard trying to talk to our
> ARC-770 based adaptor on SATA-0 :
> 
> ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE002 bmdma 0xDC08 irq 10 
> scsi2 : ata_piix ata1.00: CFA, max PIO4, 8005536 sectors: LBA 
> ata1.00: ata1: dev 0 multi count 0 ata1.00: qc timeout (cmd 0xef) 
> ata1.00: failed to set xfermode (err_mask=0x4)

Can you give a shot at 2.6.21-rc7.  The problem should have been fixed
there.

-- 
tejun

Re: Re: Problems with Linux SATA driver and ARC-770 IDE Bridge chip

[sjackerman]

Thanks for your quick reply. As I'm new to Linux I'm going to have a customer who brought this problem to my attention try this tonight. 

--
This message was sent on behalf of sjackerman@comcast.net at openSubscriber.com
http://www.opensubscriber.com/message/linux-ide@vger.kernel.org/6567951.html

Re: Problems with Linux SATA driver and ARC-770 IDE Bridge chip

[Tejun Heo]

[cc'ing ATA gurus]
Hello, again.

Okay, there are two different problems here, so I was confused a bit,
but now I see what's going on.

sjackerman@comcast.net wrote:
> ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE002 bmdma 0xDC08 irq 10
> scsi2 : ata_piix
> ata1.00: CFA, max PIO4, 8005536 sectors: LBA
> ata1.00: ata1: dev 0 multi count 0
> ata1.00: qc timeout (cmd 0xef)
> ata1.00: failed to set xfermode (err_mask=0x4)
> ata1.00: limiting speed to PIO3
> ata1: failed to recover some devices, retrying in 5 secs
> ata1.00: qc timeout (cmd 0xef)
> ata1.00: failed to set xfermode (err_mask=0x4)
> ata1.00: limiting speed to PIO0
> ata1: failed to recover some devices, retrying in 5 secs
> ata1.00: qc timeout (cmd 0xef)
> ata1.00: failed to set xfermode (err_mask=0x4)
> ata1.00: disabled
> scsi3 : ata_piix
> ATA: abnormal status 0x7F on port 0xE407
>
> You can see that that our ARC-770 based adaptor with 4GB Sandisk CF
> card failed to respond to the ATA Identify command. However the
> BIOS, DOS and Windows can identify and use this same CF card and
> adaptor. The same CF card placed into a no-name adaptor that uses a
> Marvell 88SA8040 bridge chip works with no problems.

Command 0xef is not IDENTIFY, it's SETFEATURES. libata is trying to
configure transfer mode but the device isn't responding.  In the above
case, the device has successfully executed IDENTIFY but timed out on
SETXFERMODE.  It's okay for CFA devices to not implement SETXFERMODE
but it's supposed to abort the command not timeout on it.  Can you
please ask Acard about this too?

> Here is the customer's error attempting the same thing but on an Intel
> 875 based chipset:
>
> ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> scsi0 :
> ata_piix
> ATA: abnormal status 0x7F on port 0xC007
> scsi1 : ata_piix
> ata2: port is slow to respond, please be patient (Status 0xd0)
> ata2: port failed to respond (30 secs, Status 0xd0)
> ATA: abnormal status 0xD0 on port 0xC807
> ATA: abnormal status 0xD0 on port 0xC807
> ATA: abnormal status 0xD0 on port 0xC807
> ATA: abnormal status 0xD0 on port 0xC807
> ATA: abnormal status 0xD0 on port 0xC807
> ata2.00: qc timeout (cmd 0xec)
> ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> ata2: port is slow to respond, please be patient (Status 0xd0)
> ata2: port failed to respond (30 secs, Status 0xd0)
> ATA: abnormal status 0xD0 on port 0xC807
> ATA: abnormal status 0xD0 on port 0xC807
> ATA: abnormal status 0xD0 on port 0xC807
> ATA: abnormal status 0xD0 on port 0xC807
> ATA: abnormal status 0xD0 on port 0xC807
> ata2.00: qc timeout (cmd 0xec)
> ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> ata2: port is slow to respond, please be patient (Status 0xd0)
> ata2: port failed to respond (30 secs, Status 0xd0)
>
> According to the Acard technology support engineer who evaluated the
problem:
>
>  "Intel chipset assigns an "nIEN (interrupt)" value 1 (disable),
> which is not compliant with SATA spec, and causes device failure.
> Marvell chip has been revised for several versions, and it does
> something to ignore this assignment since a certain revision, prior
> to the directives of SATA authority.  That's why Marvel chip works
> regardless of MB chipset.  However, In ACARD, we follow the
> directives and spec from SATA authority, unless we receive the
> notification, we won't do anything against the rules."

Where does the SATA spec says it's okay to timeout when nIEN is set?
>From ATA8-AST section 7.5.1,

  N Variable. In ATA/ATAPI-7 parallel emulation, this bit corresponds to
        the nIEN bit. The bit is not used in the serial transport, and
        may be transmitted with a zero or a one value. It is
        recommended that it be cleared to zero.

It specifically says "_may_ be transmitted with a zero or a one value"
and not recommending setting this bit is very new thing.  In SATA,
raising an interrupt is the ATA controller's responsibility whears in
PATA it was the device's.  That's why it's meaningless at the SATA
_TRANSPORT_ level because an ATA device doens't and can't care whether
the controller raises interrupt for command completion or not.

But the bit still matters between the ATA controller and the host.
It's the only IRQ mask bit in the interface.  Actually, ATA8-AST talks
exactly about this in annex E.4 and how this transfer of IRQ masking
responsibility should be handled and what problems may arise from it.
The device can ignore nIEN and just set IRQ bit and the controller is
recommended to clear nIEN when transmitting command FIS but earlier
chips do transmit the bit as is.  Note that the implementation detail
is between the controller and the device.  That's why it's described
in AST not in ACS.  ie. The whole thing must be transparent to the
device driver.  After all, the whole idea is to emulate SFF PATA.

IN NO CASE, the device is allowed to timeout on a command because nIEN
is set.  I'm sorry but that's simply a broken device.

With all due respect, anyone who has the flimsiest idea about how SFF
interface works and how SATA command layer protocol descended from it
would know how broken it is to timeout on commands because it has nIEN
set.  I usually try not to rant but it's really frustrating because
this brokenness is whole new and means that we can't have any IRQ
masking on some controllers if we're gonna support this device, on top
of missing reliable IRQ pending bit.

> I have asked for additional clarification from Acard, but it has not
>  been forthcoming.
>
> In attempting to resolve this for our Linux customers, I sent an
> e-mail to Greg K-H in response to his Free Linux Driver
> Announcement:
>
> http://www.kroah.com/log/linux/free_drivers.html
>
> Greg responded and suggested that I post a request for assistance
> on this mailing list, so here it is.

Yeap, you've contacted the right place.

> I would be willing to supply one of our adaptors and a CF card to
> someone who can revise the driver to work with the Acard ARC-770 and
> have the corrected driver included in future Linux releases.

Yes, please.  The CF reader now looks far more interesting after
knowing how weirdly broken it is.  :-)

Jeff, Alan, Mark and Albert, do you have ideas how we should support
this one?  This thing locks up if nIEN is set in command FIS.  For
ahci and sata_sil24, we can and probably should stop setting nIEN when
polling, but what are we gonna do with all the SFF controllers?  I can
think of some dirty hacks along the line of polling with IRQ enabled
but I would love to be enlightened with something cleaner.

Thanks.

-- 
tejun

Re: Problems with Linux SATA driver and ARC-770 IDE Bridge chip

[Alan Cox]

> Jeff, Alan, Mark and Albert, do you have ideas how we should support
> this one?  This thing locks up if nIEN is set in command FIS.  For

I believe they make a round receptacle for putting them in, along with
other rubbish.

> ahci and sata_sil24, we can and probably should stop setting nIEN when
> polling, but what are we gonna do with all the SFF controllers?  I can
> think of some dirty hacks along the line of polling with IRQ enabled
> but I would love to be enlightened with something cleaner.

The SFF controllers need nIEN, I don't believe this "product" is
supportable if the diagnosis and claims of the cause of the problem are
true - I've no idea if they are the half-clued ramblings of front line
support or someone technical and reflect the real reason the device fails.

We can certainly handle the "should be zero" for pure SATA controllers
where we decide what goes in that bit in the FIS, but for SFF based and
emulation controllers there's nothing we can sanely do.

Alan

Re: Problems with Linux SATA driver and ARC-770 IDE Bridge chip

[Mark Lord]

Tejun Heo wrote:
> [cc'ing ATA gurus]
> Hello, again.
> 
> Okay, there are two different problems here, so I was confused a bit,
> but now I see what's going on.
> 
> sjackerman@comcast.net wrote:
>> ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE002 bmdma 0xDC08 irq 10
>> scsi2 : ata_piix
>> ata1.00: CFA, max PIO4, 8005536 sectors: LBA
>> ata1.00: ata1: dev 0 multi count 0
>> ata1.00: qc timeout (cmd 0xef)
>> ata1.00: failed to set xfermode (err_mask=0x4)
..
> Jeff, Alan, Mark and Albert, do you have ideas how we should support
> this one?  This thing locks up if nIEN is set in command FIS.

It would be useful to see the full tf on those errors.
My experience with PATA drives and CF cards, it that they
default to PIO4 (assuming they report supporting PIO4).
So we don't actually need to do a set xfer mode on them.

Is the full IDENTIFY data available (hex, please)?
Perhaps we can recognize this beast and just handle it
differently when detected.

Is it the CF card, or the CF adaptor, that's the problem?

Many questions, not many answers (yet).

Re: Problems with Linux SATA driver and ARC-770 IDE Bridge chip

[Craig Metz]

In message <4637379F.7070805@rtr.ca>, you write:
>It would be useful to see the full tf on those errors.
>My experience with PATA drives and CF cards, it that they
>default to PIO4 (assuming they report supporting PIO4).
>So we don't actually need to do a set xfer mode on them.
>
>Is the full IDENTIFY data available (hex, please)?
>Perhaps we can recognize this beast and just handle it
>differently when detected.
>
>Is it the CF card, or the CF adaptor, that's the problem?
>
>Many questions, not many answers (yet).

  The CF card I'm using is a modern SanDisk, which supports up to MDMA2. I'd
like to be able to use their new Extreme IV, which supports up to UDMA6. The
flash parts themselves are now getting fast enough that DMA really makes a
difference vs. PIO.

  The same card in a CF<->PATA adapter chained to a PATA<->SATA adapter based
on a different bridge chip works fine. So I don't think it's the card, or the
CF technology inherently. My personal estimation is that the ACard bridge
chip is buggy and in need of a work-around.

  What do I need to run in order to extract the full IDENTIFY data for you?
Keep in mind that I can't get a kernel booted that will fully see this device.
(i.e., no SCSI disk is ever allocated)

  Thanks,

									-Craig

Re: Problems with Linux SATA driver and ARC-770 IDE Bridge chip

[Mark Lord]

Craig Metz wrote:
>
>   What do I need to run in order to extract the full IDENTIFY data for you?
> Keep in mind that I can't get a kernel booted that will fully see this device.
> (i.e., no SCSI disk is ever allocated)

That's tough, then.  Does it behave the same regardless of CF card?
Can I get hold of one of those adaptors here?

Cheers

Re: Problems with Linux SATA driver and ARC-770 IDE Bridge chip

[Craig Metz]

In message <46377C4A.3080602@rtr.ca>, you write:
>Craig Metz wrote:
>>
>>   What do I need to run in order to extract the full IDENTIFY data for you?
>> Keep in mind that I can't get a kernel booted that will fully see this devic
>> (i.e., no SCSI disk is ever allocated)
>
>That's tough, then.  Does it behave the same regardless of CF card?

  Yes. I've tried three different models of SanDisk card and a Lexar.

>Can I get hold of one of those adaptors here?

  I believe that Steve from ACS was willing to help with hardware.

									-Craig

RE: Problems with Linux SATA driver and ARC-770 IDE Bridge chip

[Steven J. Ackerman]

All-

Sorry, I've been out of town for a sudden illness and subsequent family
death.

Please provide me with a shipping address and/or other requisite
information.

Thank you,

Steven J. Ackerman, Consultant
ACS, Sarasota, FL
Work: http://www.acscontrol.com
           steve@acscontrol.com
Blog: http://spaces.msn.com/sjackerman
         sjackerman@comcast.net
 
> -----Original Message-----
> From: Craig Metz [mailto:cmetz@inner.net]
> Sent: Tuesday, May 01, 2007 2:06 PM
> To: Mark Lord
> Cc: Tejun Heo; sjackerman@comcast.net; linux-ide@vger.kernel.org; Jeff
> Garzik; Alan Cox; albertcc@tw.ibm.com
> Subject: Re: Problems with Linux SATA driver and ARC-770 IDE Bridge chip
> 
> In message <46377C4A.3080602@rtr.ca>, you write:
> >Craig Metz wrote:
> >>
> >>   What do I need to run in order to extract the full IDENTIFY data for
> you?
> >> Keep in mind that I can't get a kernel booted that will fully see this
> devic
> >> (i.e., no SCSI disk is ever allocated)
> >
> >That's tough, then.  Does it behave the same regardless of CF card?
> 
>   Yes. I've tried three different models of SanDisk card and a Lexar.
> 
> >Can I get hold of one of those adaptors here?
> 
>   I believe that Steve from ACS was willing to help with hardware.
> 
>
-Craig