headers
Robert Hancock | 1 Oct 2010 02:24
Picon

Re: Marvel PMP SATA controller

On 09/30/2010 08:03 AM, Richard wrote:
> On 30/09/10 14:39, Mark Lord wrote:
>> On 10-09-29 04:32 PM, Richard wrote:
>>> On 29/09/10 20:56, Mark Lord wrote:
>>
>>>> What are you trying to do?
>>> Hi Mark,
>>>
>>> Its an embedded device whereby the one HDD I have does not work with
>>> the Marvel PMP. I have the command to send to the PMP controller but
>>> I am not an officianado with linux SATA(the code I have is from
>>> VxWorks) The drive is confirmed working, but the PMP chip does not
>>> default to SATA Generation 1, and this HDD is a bit dumb to figure it
>>> out :) - so I have to force the PMP controller to Gen1 mode.
>>> (I have tons of drives that work just fine, its just this ONE Maxtor
>>> drive that is being a pain)
>>>
>>> The short - I need to write a command to the SATA controller before
>>> this HDD can be recognised.
>> ..
>>
>> Does the existing libata parameter take care of it for you?
>>
>> linux/Documentation/kernel-parameters.txt:
>> eg. libata.force=[ID:]1.5" ## replace [ID:] with port[.device] for the
>> PMP and/or HD
>>
> Unfortunately not.. which is why I asked how to write commands directly
> on to the SATA bus from kernel space.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard | 1 Oct 2010 08:33
Picon

Re: Marvel PMP SATA controller

On 01/10/10 01:24, Robert Hancock wrote:
> On 09/30/2010 08:03 AM, Richard wrote:
>> On 30/09/10 14:39, Mark Lord wrote:
>>> On 10-09-29 04:32 PM, Richard wrote:
>>>> On 29/09/10 20:56, Mark Lord wrote:
>>>
>>>>> What are you trying to do?
>>>> Hi Mark,
>>>>
>>>> Its an embedded device whereby the one HDD I have does not work with
>>>> the Marvel PMP. I have the command to send to the PMP controller but
>>>> I am not an officianado with linux SATA(the code I have is from
>>>> VxWorks) The drive is confirmed working, but the PMP chip does not
>>>> default to SATA Generation 1, and this HDD is a bit dumb to figure it
>>>> out :) - so I have to force the PMP controller to Gen1 mode.
>>>> (I have tons of drives that work just fine, its just this ONE Maxtor
>>>> drive that is being a pain)
>>>>
>>>> The short - I need to write a command to the SATA controller before
>>>> this HDD can be recognised.
>>> ..
>>>
>>> Does the existing libata parameter take care of it for you?
>>>
>>> linux/Documentation/kernel-parameters.txt:
>>> eg. libata.force=[ID:]1.5" ## replace [ID:] with port[.device] for the
>>> PMP and/or HD
>>>
>> Unfortunately not.. which is why I asked how to write commands directly
>> on to the SATA bus from kernel space.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Lord | 1 Oct 2010 15:46

Re: Marvel PMP SATA controller

On 10-09-30 10:03 AM, Richard wrote:
> On 30/09/10 14:39, Mark Lord wrote:
..
>> Does the existing libata parameter take care of it for you?
>>
>> linux/Documentation/kernel-parameters.txt:
>> eg. libata.force=[ID:]1.5" ## replace [ID:] with port[.device] for the PMP and/or HD
>>
> Unfortunately not.. which is why I asked how to write commands directly on to the SATA bus from kernel space.

Right.  Well, just keep plunking away at it in that ancient kernel, then.
The two modern routines to study/backport are sata_pmp_read() and sata_pmp_write(),
which are used by most controllers to perform PMP register accesses.

However, the host controller may require additional tweaks,
especially if it is a Marvell host controller (sata_mv),
or something that doesn't normally "do" PMP, like ata_piix.

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Ben Hutchings | 4 Oct 2010 05:50
Picon

piix vs ata_piix device ID tables

When I converted the Debian kernel configurations over from IDE to
libata-based drivers, I compared the device ID tables for all the PCI
drivers.  I found that ata_piix handles most of the same devices as piix
while pata_oldpiix and pata_mpiix each handle one more.  However, 2
device IDs in piix are not in the device ID tables of any libata-based
driver:

PCI_DEVICE_ID_INTEL_82371FB_0 == 0x122e (PIIX function 0)

piix seems to treat this the same as PCI_DEVICE_ID_INTEL_82371FB_1 ==
0x1230, which is handled by pata_oldpiix.  (This is weird; function 0 is
supposed to be the ISA bridge!)

PCI_DEVICE_ID_INTEL_82801DB_1 == 0x24c1 (ICH4 device 31 function 1)

piix seems to treat this the same as most other ICH PATA interfaces,
which are handled by ata_piix.

Does anyone know why these aren't handled by the libata-based drivers?

Ben.

--

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
Permalink | Reply | 2 comments |
headers
Tejun Heo | 4 Oct 2010 11:18
Picon

Re: [BUG] libahci returns stale result tf much of the time.

Hello,

On 09/25/2010 01:26 AM, Robert Hancock wrote:
>> And here's an example of the bug, which should work (as a demo)
>> for most folks out there with the same controller ahci / JMB360:
>>
>> Here, I'll use hdparm to do a "set acoustic" command
>> on a drive which does NOT have the "Acoustic Management" feature set.
>> Just look for the fd fd fd strings in the returned data,
>> and notice how the final IDENTIFY at the end works, but returns
>> bad ATA status 0x51 from the stale result_tf:
> 
> The d2h_fis area is supposed to be updated by the controller with
> the last FIS received from the device. Maybe this controller just
> isn't doing that for some reason?

Hmm... one possibility is that the controller takes some time to
update the area and the driver is reading it off too early.  Maybe
adding a delay would resolve the issue?  Mark, do you know whether
this problem is isolated to JMB360?

Thanks.

--

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 17 comments |
headers
Alan Cox | 4 Oct 2010 11:21
Picon

Re: piix vs ata_piix device ID tables

On Mon, 04 Oct 2010 04:50:52 +0100
Ben Hutchings <ben <at> decadent.org.uk> wrote:

> When I converted the Debian kernel configurations over from IDE to
> libata-based drivers, I compared the device ID tables for all the PCI
> drivers.  I found that ata_piix handles most of the same devices as
> piix while pata_oldpiix and pata_mpiix each handle one more.
> However, 2 device IDs in piix are not in the device ID tables of any
> libata-based driver:
> 
> PCI_DEVICE_ID_INTEL_82371FB_0 == 0x122e (PIIX function 0)
> 
> piix seems to treat this the same as PCI_DEVICE_ID_INTEL_82371FB_1 ==
> 0x1230, which is handled by pata_oldpiix.  (This is weird; function 0
> is supposed to be the ISA bridge!)

Given that pre PIIX3 devices (MPIIX and PIIX original) never worked in
the old IDE code (well sometimes semi-worked by accident because the
BIOS values were right and they didn't break anything) I wouldn't draw
any conclusions.

> PCI_DEVICE_ID_INTEL_82801DB_1 == 0x24c1 (ICH4 device 31 function 1)
> 
> piix seems to treat this the same as most other ICH PATA interfaces,
> which are handled by ata_piix.
> 
> Does anyone know why these aren't handled by the libata-based drivers?

I don't know about 0x24C1 however it isn't listed in the Intel ICH
programming manual so given we've also had no reports about it I
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tejun Heo | 4 Oct 2010 18:46
Picon

Re: Bug#598518: linux-image-2.6-686: ata_piix module loaded before ahci module deactivate hotplug support (regression from lenny)

Hello,

On 09/30/2010 12:27 AM, Ben Hutchings wrote:
> On Wed, 2010-09-29 at 18:50 +0200, thomas.debesse+debian <at> gmail.com
> wrote:
> [...]
>> ICH6 sata controller could be managed by both ata_piix and ahci module but only
>> ahci module handle hotplug.
>> At boot time, when ata_piix is loaded before ahci module, it takes control of
>> the ICH6 controller and the ahci module does'nt manage nothing. Because
>> ata_piix also manage ICH6 sata controller, hard drives are managed, but because
>> ata_piix module is used in place of ahci module, because ahci module is'nt
>> used, hotplug (and other ahci functionnalities indeed) does'nt works.
> [...]
>> The solution is to load ahci module before ata_piix module, then we can have
>> SATA drives managed by ahci module and IDE drives managed by ata_piix module.
> [...]
> 
> You can force ahci to be loaded first:
> 1. Add the line 'ahci' to /etc/initramfs-tools/modules.
> 2. Run 'update-initramfs -u' to regenerate the initramfs.
> 3. Reboot.
> 
> But it seems like it would be better if ahci was automatically
> preferred.

With modules.order in place, modprobe will always prefer ahci over
ata_piix (the preference follows the link order).  Maybe debian initrd
doesn't handle modules.order properly?
(Continue reading)

Permalink | Reply | 21 comments |
headers
Mark Lord | 4 Oct 2010 19:01

Re: [BUG] libahci returns stale result tf much of the time.

On 10-10-04 05:18 AM, Tejun Heo wrote:
> Hello,
>
> On 09/25/2010 01:26 AM, Robert Hancock wrote:
>>> And here's an example of the bug, which should work (as a demo)
>>> for most folks out there with the same controller ahci / JMB360:
>>>
>>> Here, I'll use hdparm to do a "set acoustic" command
>>> on a drive which does NOT have the "Acoustic Management" feature set.
>>> Just look for the fd fd fd strings in the returned data,
>>> and notice how the final IDENTIFY at the end works, but returns
>>> bad ATA status 0x51 from the stale result_tf:
>>
>> The d2h_fis area is supposed to be updated by the controller with
>> the last FIS received from the device. Maybe this controller just
>> isn't doing that for some reason?
>
> Hmm... one possibility is that the controller takes some time to
> update the area and the driver is reading it off too early.  Maybe
> adding a delay would resolve the issue?  Mark, do you know whether
> this problem is isolated to JMB360?
..

That's my theory, too (slow updating of the area).
I haven't pursued it further yet, but I will.

This is really disruptive for me here, as my primary eSATA
adaptor in my notebook is JMB360, and it gets used a LOT.

Cheers
(Continue reading)

Permalink | Reply | 16 comments |
headers
Mark Lord | 4 Oct 2010 19:06

Re: [BUG] libahci returns stale result tf much of the time.

On 10-10-04 01:01 PM, Mark Lord wrote:
> On 10-10-04 05:18 AM, Tejun Heo wrote:
>> Hello,
>>
>> On 09/25/2010 01:26 AM, Robert Hancock wrote:
>>>> And here's an example of the bug, which should work (as a demo)
>>>> for most folks out there with the same controller ahci / JMB360:
>>>>
>>>> Here, I'll use hdparm to do a "set acoustic" command
>>>> on a drive which does NOT have the "Acoustic Management" feature set.
>>>> Just look for the fd fd fd strings in the returned data,
>>>> and notice how the final IDENTIFY at the end works, but returns
>>>> bad ATA status 0x51 from the stale result_tf:
>>>
>>> The d2h_fis area is supposed to be updated by the controller with
>>> the last FIS received from the device. Maybe this controller just
>>> isn't doing that for some reason?
>>
>> Hmm... one possibility is that the controller takes some time to
>> update the area and the driver is reading it off too early. Maybe
>> adding a delay would resolve the issue? Mark, do you know whether
>> this problem is isolated to JMB360?
> ..
>
> That's my theory, too (slow updating of the area).
> I haven't pursued it further yet, but I will.
>
> This is really disruptive for me here, as my primary eSATA
> adaptor in my notebook is JMB360, and it gets used a LOT.
(Continue reading)

Permalink | Reply | 15 comments |
headers
Mark Lord | 4 Oct 2010 19:31

Re: [BUG] libahci returns stale result tf much of the time.

On 10-10-04 01:06 PM, Mark Lord wrote:
..
>> That's my theory, too (slow updating of the area).
>> I haven't pursued it further yet, but I will.
>>
>> This is really disruptive for me here, as my primary eSATA
>> adaptor in my notebook is JMB360, and it gets used a LOT.
>
> Okay, I just now ran a quick test on another machine with AHCI: Same bug:
>
> 00:1f.2 SATA controller: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH) 6 port SATA AHCI Controller
(rev 02)
>
> So it's probably universal. Try it with this simple test:
>
> hdparm -I /dev/sdX ## this works
> hdparm -Z /dev/sdX ## this will fail --> obsolete vendor-specific command
> hdparm -I /dev/sdX ## this fails when following the above
>
> hdparm -z /dev/sdX ## force some regular I/O, to clear the bad state from the driver
> hdparm -I /dev/sdX ## this now works again

The issue also seems to be present in 2.6.32.8 on that same Intel AHCI platform,
so it probably has nothing to do with the libahci split.

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 14 comments |

Gmane