lkml.org 
[lkml]   [2006]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFT] major libata update
Jeff Garzik wrote:
> Tejun Heo wrote:
>> On Thu, May 18, 2006 at 04:07:58PM -0700, Andrew Morton wrote:
>>> Yes it does. I dropped it and got
>>>
>>> SCSI subsystem initialized
>>> ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
>>> ACPI (acpi_bus-0191): Device is not power manageable [20060310]
>>> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19
>>> ata1: SATA max UDMA/133 cmd 0x2148 ctl 0x217E bmdma 0x2110 irq 19
>>> ata2: SATA max UDMA/133 cmd 0x2140 ctl 0x217A bmdma 0x2118 irq 19
>>> ata1: SATA port has no device.
>>>
>>> Then I undropped it and got
>>>
>>> SCSI subsystem initialized
>>> ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
>>> ACPI (acpi_bus-0191): Device is not power manageable [20060310]
>>> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19
>>> ata1: SATA max UDMA/133 cmd 0x2148 ctl 0x217E bmdma 0x2110 irq 19
>>> ata2: SATA max UDMA/133 cmd 0x2140 ctl 0x217A bmdma 0x2118 irq 19
>>> ata1.00: ATA-7, max UDMA/133, 321672960 sectors: LBA48 NCQ (depth 0/32)
>>> ata1.00: configured for UDMA/133
>>> scsi0 : ata_piix
>>>
>>> and a computer which boots.
>>>
>>> Look closer, please ;)
>>
>> Hello, Andrew.
>>
>> I see. It seems that you're reporting two separate problems - your
>> PCS register doesn't report presence properly && the TF registers
>> report ghost device if the first device is ATAPI. I can reproduce the
>> second here, but AFAIK the only controller which had problem with PCS
>> persence bits was ESB6300 until now.
>>
>> Can you post the result of 'lspci -n' and ata_piix boot probing
>> messages with the following patch applied? It would be helpful if you
>> tell us how devices are actually connected. Also, where did the patch
>> come from? With what comment?
>
> At this point it may be relevant to note that Intel tells me that PCS
> has changed on -every- chip. So, ICH8 PCS register behaves differently
> from ICH7 and prior.

Yeah, the PCS bit is sad to look at. From ICH6, the docs say that the
AHCI SStatus should be used for presence detection but that cannot be
done without AHCI BAR mapped.

ICH7 (or 6 was it?) added a window register into AHCI area, which
weirdly cannot be used without actually enabling AHCI BAR - what's the
point? My suspicion is that they designed it to work without AHCI BAR
enabled but maybe some revisions screwed up and ICH7 still had PCS
presence bits working, so the weird result.

I don't have ICH8 docs but, again, my guess is that they've got the
window register correct this time and determined to screw PCS presence
bits. All these suspicions and guesses need verification, but if my
guesses are right, the solution would be...

* leave anything order than ICH6 as it is now
* trust PCS presence bits for ICH6/7
* use AHCI window register to access SStatus on ICH8

--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-05-19 04:19    [W:0.072 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site