Re: LibPATA code issues / 2.6.15.4

Re: LibPATA code issues / 2.6.15.4

[Nicolas Mailhot]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]


> those drives should support all FUA opcodes properly, both queued and unqueued
> 
> On 2/28/06, Jeff Garzik <jgarzik@pobox.com> wrote:
> > Mark Lord wrote:
> > > David Greaves wrote:
> > >
> > >>
> > >> scsi1 : sata_sil
> > >>   Vendor: ATA       Model: Maxtor 6B200M0    Rev: BANC
> > >>   Type:   Direct-Access                      ANSI SCSI revision: 05
> > >>   Vendor: ATA       Model: Maxtor 6B200M0    Rev: BANC
> > >>   Type:   Direct-Access                      ANSI SCSI revision: 05

How about the drives that got blacklisted following :
http://bugzilla.kernel.org/show_bug.cgi?id=5914 ?
and
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177951 ?

Device Model:     Maxtor 6L300S0
Firmware Version: BANC1G10

on

Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)

Regards,

-- 
Nicolas Mailhot

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 199 bytes --]

Re: LibPATA code issues / 2.6.15.4

[Mark Lord]

Nicolas Mailhot wrote:
>>
> How about the drives that got blacklisted following :
> http://bugzilla.kernel.org/show_bug.cgi?id=5914 ?
> and
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177951 ?
> 
> Device Model:     Maxtor 6L300S0
> Firmware Version: BANC1G10
> 
> on Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)

Mmm.. somebody with one of those controllers should check
to see if *any* drives work with FUA, and blacklist the controller
instead of the drives if everything is failing.

Cheers

Re: LibPATA code issues / 2.6.15.4

[Nicolas Mailhot]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

Le mercredi 01 mars 2006 à 14:22 -0500, Mark Lord a écrit :
> Nicolas Mailhot wrote:
> >>
> > How about the drives that got blacklisted following :
> > http://bugzilla.kernel.org/show_bug.cgi?id=5914 ?
> > and
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177951 ?
> > 
> > Device Model:     Maxtor 6L300S0
> > Firmware Version: BANC1G10
> > 
> > on Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)
> 
> Mmm.. somebody with one of those controllers should check
> to see if *any* drives work with FUA, and blacklist the controller
> instead of the drives if everything is failing.

I'm a someone with such a controller (that's my boog here)
But I only have these drives.
So I can only confirm the combo it deadly.
(I could possibly try to plug one on the nforce4 controller, not sure if
extracting the box from the tangle of cables and hardware he's part of
is worth it. sata_nv is rev-eng, while the siI docs are public, right?)

I do suspect Eric D. Mudama knows if the problem is on the hard-drive
side though

Regards,

-- 
Nicolas Mailhot

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 199 bytes --]

Re: LibPATA code issues / 2.6.15.4

[Jeff Garzik]

Nicolas Mailhot wrote:
> is worth it. sata_nv is rev-eng, while the siI docs are public, right?)

sata_nv was written by NVIDIA.

	Jeff

Re: LibPATA code issues / 2.6.15.4

[Eric D. Mudama]

On 3/1/06, Nicolas Mailhot <nicolas.mailhot@gmail.com> wrote:
> Le mercredi 01 mars 2006 à 14:22 -0500, Mark Lord a écrit :
> > Nicolas Mailhot wrote:
> > >>
> > > How about the drives that got blacklisted following :
> > > http://bugzilla.kernel.org/show_bug.cgi?id=5914 ?
> > > and
> > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177951 ?
> > >
> > > Device Model:     Maxtor 6L300S0
> > > Firmware Version: BANC1G10
> > >
> > > on Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)
> >
> > Mmm.. somebody with one of those controllers should check
> > to see if *any* drives work with FUA, and blacklist the controller
> > instead of the drives if everything is failing.
>
> I'm a someone with such a controller (that's my boog here)
> But I only have these drives.
> So I can only confirm the combo it deadly.
> (I could possibly try to plug one on the nforce4 controller, not sure if
> extracting the box from the tangle of cables and hardware he's part of
> is worth it. sata_nv is rev-eng, while the siI docs are public, right?)
>
> I do suspect Eric D. Mudama knows if the problem is on the hard-drive
> side though
>
> Regards,
>
> --
> Nicolas Mailhot
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.1 (GNU/Linux)
>
> iEYEABECAAYFAkQGKmoACgkQI2bVKDsp8g0veQCggJkweq1nQn7YNSEIobOHitk0
> QXsAn0TnHI/6LBG9nezBnS0MTskLml0W
> =s1TM
> -----END PGP SIGNATURE-----
>


I didn't know offhand so we plugged in a bus analzyer and took a look
here in the lab... We didn't have a 3114 lying around, but issuing the
Write DMA FUA (0x3D) opcode on a 3112 resulted in a D0h soft hang.  I
think they're related (4-port vs 2-port).

Looking at the bus trace, the command is issued on the SATA bus, the
drive generates a DMA Activate FIS which is accepted by the 3112, and
then the 3112 generates a Data Payload FIS (46h) with no contents.

The first DWORD of the payload is a HOLD primitive, to which the
device promptly responds with HOLDA, and the two are in a soft bus
lock and will sit forever.  No data is ever generated by the host
(stopped capture after 4 seconds).

I believe this core should not be part of the FUA whitelist.  If I
remember correctly, there are other implementations out there with
similar limitations to opcodes this "new" to ATA.

--eric

Re: LibPATA code issues / 2.6.15.4

[Eric D. Mudama]

On 3/1/06, Eric D. Mudama <edmudama@gmail.com> wrote:
> I believe this core should not be part of the FUA whitelist.  If I
> remember correctly, there are other implementations out there with
> similar limitations to opcodes this "new" to ATA.

That being said, I see from

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177951

that a blacklisting of some Maxtor drives for this issue has
supposedly occurred or been pushed and accepted "upstream" in git ....
 For the obvious (selfish) reasons, I'd like to minimize the number of
Maxtor drives that are blacklisted, as I don't believe this is a drive
issue at all.

If there's a drive model out there reporting support for FUA but
screwing it up, I'm all ears as that's something I need to know about.
 If basic adapter functional testing is required for some of these
low-level commands, then that might be something I can help with too
(on a very limited scale), since we have access to ~100 different
chipsets.

--eric

FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Jeff Garzik]

Eric D. Mudama wrote:
> I didn't know offhand so we plugged in a bus analzyer and took a look
> here in the lab... We didn't have a 3114 lying around, but issuing the
> Write DMA FUA (0x3D) opcode on a 3112 resulted in a D0h soft hang.  I
> think they're related (4-port vs 2-port).

Looking at the public docs posted at 
http://gkernel.sourceforge.net/specs/sii/ ...  FUA is not in the list of 
supported opcodes (Table 10-1).

The 311x does have a facility that allows the driver to specify the 
command protocol associated with an unknown-to-the-chip opcode.  Someone 
sufficiently interested could investigate using the VS Unlock and VS Set 
Command Protocol commands to patch in support (section 10.4.*).

For libata, I think an ATA_FLAG_NO_FUA would be appropriate for 
situations like this...  assume FUA is supported in the controller, and 
set a flag where it is not.  Most chips will support FUA, either by 
design or by sheer luck.  The ones that do not support FUA are the 
controllers that snoop the ATA command opcode, and internally choose the 
protocol based on that opcode.  For such hardware, unknown opcodes will 
inevitably cause problems.

	Jeff

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Jeff Garzik]

Jeff Garzik wrote:
> For libata, I think an ATA_FLAG_NO_FUA would be appropriate for 
> situations like this...  assume FUA is supported in the controller, and 
> set a flag where it is not.  Most chips will support FUA, either by 
> design or by sheer luck.  The ones that do not support FUA are the 
> controllers that snoop the ATA command opcode, and internally choose the 
> protocol based on that opcode.  For such hardware, unknown opcodes will 
> inevitably cause problems.

This also begs the question... what controller was being used, when the 
single Maxtor device listed in the blacklist was added?  Perhaps it was 
a problem with the controller, not the device.

	Jeff

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Eric D. Mudama]

On 3/1/06, Jeff Garzik <jgarzik@pobox.com> wrote:
> This also begs the question... what controller was being used, when the
> single Maxtor device listed in the blacklist was added?  Perhaps it was
> a problem with the controller, not the device.
>
>         Jeff

As reported here:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177951

the controller was a 3114, and the bug was "fixed" by blacklisting his
Maxtor drive's FUA support.  I'd like Maxtor drives to be
un-blacklisted if possible.

--eric

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Jeff Garzik]

Eric D. Mudama wrote:
> On 3/1/06, Jeff Garzik <jgarzik@pobox.com> wrote:
> 
>>This also begs the question... what controller was being used, when the
>>single Maxtor device listed in the blacklist was added?  Perhaps it was
>>a problem with the controller, not the device.
>>
>>        Jeff
> 
> 
> As reported here:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177951
> 
> the controller was a 3114, and the bug was "fixed" by blacklisting his
> Maxtor drive's FUA support.  I'd like Maxtor drives to be
> un-blacklisted if possible.

If its 3114 I agree un-blacklisting is the way to go... but its not 
clear to me whether the problematic configuration included sata_sil or 
sata_nv.  Since I'm apparently blind :) which part of the bug points 
conclusively to sata_sil?

	Jeff

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Eric D. Mudama]

On 3/1/06, Jeff Garzik <jgarzik@pobox.com> wrote:
> Eric D. Mudama wrote:
> > On 3/1/06, Jeff Garzik <jgarzik@pobox.com> wrote:
> >
> >>This also begs the question... what controller was being used, when the
> >>single Maxtor device listed in the blacklist was added?  Perhaps it was
> >>a problem with the controller, not the device.
> >>
> >>        Jeff
> >
> >
> > As reported here:
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177951
> >
> > the controller was a 3114, and the bug was "fixed" by blacklisting his
> > Maxtor drive's FUA support.  I'd like Maxtor drives to be
> > un-blacklisted if possible.
>
> If its 3114 I agree un-blacklisting is the way to go... but its not
> clear to me whether the problematic configuration included sata_sil or
> sata_nv.  Since I'm apparently blind :) which part of the bug points
> conclusively to sata_sil?
>
>         Jeff

The "failing dmesg" has the plextor connected to sata_nv, and the two
Maxtor drives connected to sata_sil, if I read it correctly.  They're
ata5/ata6 ports, mapped as sda/sdb.

Nicolas' comment in the thread "Re: LibPATA code issues / 2.6.15.4"
seemed to say it was the same adapter:

http://marc.theaimsgroup.com/?l=linux-kernel&m=114123989405668&w=2

--eric

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Jeff Garzik]

Eric D. Mudama wrote:
> The "failing dmesg" has the plextor connected to sata_nv, and the two
> Maxtor drives connected to sata_sil, if I read it correctly.  They're
> ata5/ata6 ports, mapped as sda/sdb.
> 
> Nicolas' comment in the thread "Re: LibPATA code issues / 2.6.15.4"
> seemed to say it was the same adapter:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114123989405668&w=2

Sounds like un-blacklisting the drive, and adding ATA_FLAG_NO_FUA is the 
way to go...

	Jeff

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Tejun Heo]

Jeff Garzik wrote:
> Eric D. Mudama wrote:
> 
>> The "failing dmesg" has the plextor connected to sata_nv, and the two
>> Maxtor drives connected to sata_sil, if I read it correctly.  They're
>> ata5/ata6 ports, mapped as sda/sdb.
>>
>> Nicolas' comment in the thread "Re: LibPATA code issues / 2.6.15.4"
>> seemed to say it was the same adapter:
>>
>> http://marc.theaimsgroup.com/?l=linux-kernel&m=114123989405668&w=2
> 
> 
> Sounds like un-blacklisting the drive, and adding ATA_FLAG_NO_FUA is the 
> way to go...
> 

Agreed. I'm currently implementing VDMA on sata_sil and will get to FUA 
via explicit protocol soon.

-- 
tejun

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Mark Lord]

Jeff Garzik wrote:
..
> Sounds like un-blacklisting the drive, and adding ATA_FLAG_NO_FUA is the 
> way to go...

Might as well add sata_mv to that blacklist as well.

And while I'm at it, the pdc_adma and sata_qstor controllers/drivers are fine with FUA.

-ml

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Jeff Garzik]

Mark Lord wrote:
> Jeff Garzik wrote:
> ..
> 
>> Sounds like un-blacklisting the drive, and adding ATA_FLAG_NO_FUA is 
>> the way to go...
> 
> 
> Might as well add sata_mv to that blacklist as well.

Have you confirmed that it doesn't work with FUA?

We recently patched sata_mv to add ATA_CMD_WRITE_FUA_EXT, in response to 
a nasty bug report, and ISTR the complainer went away.


> And while I'm at it, the pdc_adma and sata_qstor controllers/drivers are 
> fine with FUA.

Verified or just guessing?

	Jeff

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Eric D. Mudama]

On 3/1/06, Jeff Garzik <jgarzik@pobox.com> wrote:
> Mark Lord wrote:
> > Jeff Garzik wrote:
> > ..
> >
> >> Sounds like un-blacklisting the drive, and adding ATA_FLAG_NO_FUA is
> >> the way to go...
> >
> >
> > Might as well add sata_mv to that blacklist as well.
>
> Have you confirmed that it doesn't work with FUA?

I'll see if I can find one of these around the lab tomorrow and test
the raw command support.  If that's fine at a basic level, it might be
a bug in the driver?

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Jens Axboe]

On Wed, Mar 01 2006, Jeff Garzik wrote:
> Jeff Garzik wrote:
> >For libata, I think an ATA_FLAG_NO_FUA would be appropriate for 
> >situations like this...  assume FUA is supported in the controller, and 
> >set a flag where it is not.  Most chips will support FUA, either by 
> >design or by sheer luck.  The ones that do not support FUA are the 
> >controllers that snoop the ATA command opcode, and internally choose the 
> >protocol based on that opcode.  For such hardware, unknown opcodes will 
> >inevitably cause problems.
> 
> This also begs the question... what controller was being used, when the 
> single Maxtor device listed in the blacklist was added?  Perhaps it was 
> a problem with the controller, not the device.

Yeah which explains it a lot better as well... The FUA drive problem
never made much sense to me.

-- 
Jens Axboe

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Sander]

Jeff Garzik wrote (ao):
> Mark Lord wrote:
> >Jeff Garzik wrote:
> >..
> >
> >>Sounds like un-blacklisting the drive, and adding ATA_FLAG_NO_FUA is 
> >>the way to go...
> >
> >
> >Might as well add sata_mv to that blacklist as well.
> 
> Have you confirmed that it doesn't work with FUA?
> 
> We recently patched sata_mv to add ATA_CMD_WRITE_FUA_EXT, in response to 
> a nasty bug report, and ISTR the complainer went away.

That is correct. I was that complainer and reported that the patch works
for me: http://lkml.org/lkml/2006/2/15/175

Also, the patch went into the next -rc kernel that time.

	Sander

PS, can I get you guys interested in the sata_mv driver? I would really
love to use Marvell controller:
http://www.ussg.iu.edu/hypermail/linux/kernel/0602.2/0914.html

I'd be very happy to test any patches and will report how they do.

-- 
Humilis IT Services and Solutions
http://www.humilis.net

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Sander]

Eric D. Mudama wrote (ao):
> On 3/1/06, Jeff Garzik <jgarzik@pobox.com> wrote:
> > Mark Lord wrote:
> > > Jeff Garzik wrote:
> > > ..
> > >
> > >> Sounds like un-blacklisting the drive, and adding ATA_FLAG_NO_FUA is
> > >> the way to go...
> > >
> > >
> > > Might as well add sata_mv to that blacklist as well.
> >
> > Have you confirmed that it doesn't work with FUA?
> 
> I'll see if I can find one of these around the lab tomorrow and test
> the raw command support. If that's fine at a basic level, it might be
> a bug in the driver?

If you tell me what to do (what to type in etc) I can save you from
looking for one. I have a:

Marvell Technology Group Ltd. MV88SX6081 8-port SATA II PCI-X Controller
(rev 09)

I can connect a Maxtor MaXLine Pro 500, a Maxtor DiamondMax11 and a WD
Raptor 74GB to test if necessary.

	Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Jeff Garzik]

Eric D. Mudama wrote:
> On 3/1/06, Jeff Garzik <jgarzik@pobox.com> wrote:
> 
>>Mark Lord wrote:
>>
>>>Jeff Garzik wrote:
>>>..
>>>
>>>
>>>>Sounds like un-blacklisting the drive, and adding ATA_FLAG_NO_FUA is
>>>>the way to go...
>>>
>>>
>>>Might as well add sata_mv to that blacklist as well.
>>
>>Have you confirmed that it doesn't work with FUA?
> 
> 
> I'll see if I can find one of these around the lab tomorrow and test
> the raw command support.  If that's fine at a basic level, it might be
> a bug in the driver?

Quite possibly.  Anything goes with sata_mv at the moment...  I've done 
my best to cover most of the errata and get it working, but there are 
still some key errata workarounds missing.  It's still marked "HIGHLY 
EXPERIMENTAL" in the Kconfig ;-)

	Jeff

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Nicolas Mailhot]

Le Jeu 2 mars 2006 02:58, Jeff Garzik a écrit :
> Jeff Garzik wrote:
>> For libata, I think an ATA_FLAG_NO_FUA would be appropriate for
>> situations like this...  assume FUA is supported in the controller, and
>> set a flag where it is not.  Most chips will support FUA, either by
>> design or by sheer luck.  The ones that do not support FUA are the
>> controllers that snoop the ATA command opcode, and internally choose the
>> protocol based on that opcode.  For such hardware, unknown opcodes will
>> inevitably cause problems.
>
> This also begs the question... what controller was being used, when the
> single Maxtor device listed in the blacklist was added?  Perhaps it was
> a problem with the controller, not the device.

The controller in the bugzilla entry ie a SiI 3114.
It was a quick fix and I did expect more thorough investigation later
(probably 2.6.17 frame). Though it seems FUA-related problems are so
numerous FUA itself will be blacklisted for 2.6.16, so the limited
blacklist is no longer needed.

The thread leading to the blacklist is referenced in the bugzilla entry

-- 
Nicolas Mailhot

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Nicolas Mailhot]

Le Jeu 2 mars 2006 03:46, Jeff Garzik a écrit :
> Eric D. Mudama wrote:

> If its 3114 I agree un-blacklisting is the way to go... but its not
> clear to me whether the problematic configuration included sata_sil or
> sata_nv.  Since I'm apparently blind :) which part of the bug points
> conclusively to sata_sil?

It's sata-sil
I'm 100% sure it's how I cabled the system
sata-nv only got a plextor drive attached
(pata-nv has two pata drives on too)


-- 
Nicolas Mailhot

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Nicolas Mailhot]

Le Jeu 2 mars 2006 03:20, Eric D. Mudama a écrit :
> On 3/1/06, Jeff Garzik <jgarzik@pobox.com> wrote:
>> This also begs the question... what controller was being used, when the
>> single Maxtor device listed in the blacklist was added?  Perhaps it was
>> a problem with the controller, not the device.
>>
>>         Jeff
>
> As reported here:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177951
>
> the controller was a 3114, and the bug was "fixed" by blacklisting his
> Maxtor drive's FUA support.  I'd like Maxtor drives to be
> un-blacklisted if possible.

BTW Eric you should know :
- these specific drives (and the Maxtor PATA drives they replaced) where
bought because I knew you were hanging on the lists
- I fully intended to ask you if the blacklisting where valif after the
FUA dust had settled a little

Regards,

-- 
Nicolas Mailhot

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Nicolas Mailhot]

Le Jeu 2 mars 2006 04:00, Eric D. Mudama a écrit :

> The "failing dmesg" has the plextor connected to sata_nv, and the two
> Maxtor drives connected to sata_sil, if I read it correctly.  They're
> ata5/ata6 ports, mapped as sda/sdb.
>
> Nicolas' comment in the thread "Re: LibPATA code issues / 2.6.15.4"
> seemed to say it was the same adapter:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114123989405668&w=2

Not only it's the same adapter model, but we're talking about the same
physical system. I opened the original boog, posted on lkml, etc

-- 
Nicolas Mailhot

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Nicolas Mailhot]

Le Jeu 2 mars 2006 04:06, Jeff Garzik a écrit :
> Eric D. Mudama wrote:
>> The "failing dmesg" has the plextor connected to sata_nv, and the two
>> Maxtor drives connected to sata_sil, if I read it correctly.  They're
>> ata5/ata6 ports, mapped as sda/sdb.
>>
>> Nicolas' comment in the thread "Re: LibPATA code issues / 2.6.15.4"
>> seemed to say it was the same adapter:
>>
>> http://marc.theaimsgroup.com/?l=linux-kernel&m=114123989405668&w=2
>
> Sounds like un-blacklisting the drive, and adding ATA_FLAG_NO_FUA is the
> way to go...

Please add the ATA_FLAG_NO_FUA flag and *after* unblacklist the drive as I
distinctly have no wish to do fsck stressing again.

-- 
Nicolas Mailhot

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Jeff Garzik]

Nicolas Mailhot wrote:
> The controller in the bugzilla entry ie a SiI 3114.
> It was a quick fix and I did expect more thorough investigation later
> (probably 2.6.17 frame). Though it seems FUA-related problems are so
> numerous FUA itself will be blacklisted for 2.6.16, so the limited
> blacklist is no longer needed.

Well, we're looking for a long term solution :)

Disabling FUA by default in 2.6.16 is a temporary solution.

	Jeff

Re: FUA and 311x (was Re: LibPATA code issues / 2.6.15.4)

[Mark Lord]

Jeff Garzik wrote:
> Mark Lord wrote:
>> Jeff Garzik wrote:
>> ..
>>
>>> Sounds like un-blacklisting the drive, and adding ATA_FLAG_NO_FUA is 
>>> the way to go...
>>
>>
>> Might as well add sata_mv to that blacklist as well.
> 
> Have you confirmed that it doesn't work with FUA?

Ooops.  Defective memory here.

The Marvell documentation for the 6081/6041 does indeed state
that the FUA DMA commands *are* supported (queued or non-queued).

So it should be okay, at least for those two specific chips.