Hi,
We've got an ich6m system (a Toshiba Portege S100). ata_piix attempts to
drive the chipset, but fails - however, it doesn't bail out. As a result
it remains bound to the device and ahci isn't loaded.
I've attached the lspci output for the chipset. A few things to note
are:
1) The AHCI BAR is set
2) The SCC register identifies it as an AHCI controller
3) Bits 2 and 0 of the PCS are set, which the spec claims indicates that
the port is to be controlled as an ahci device.
So, my question is effectively: why does ata_piix attempt to disable
ahci rather than simply letting the ahci driver bind? Points (1) and (2)
seem to be checked by the code, but I'm guessing that in the case of (3)
it should just return ENODEV and let ahci be run instead. If so, should
I code up a patch?
Dmesg output:
[4294674.890000] ata_piix 0000:00:1f.2: version 1.05
[4294674.890000] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level,
low) -> IRQ 233
[4294674.890000] PCI: Setting latency timer of device 0000:00:1f.2 to 64
[4294674.890000] ata1: SATA max UDMA/133 cmd 0xBF28 ctl 0xBF26 bmdma
0xBF00 irq 233
[4294674.890000] ata2: SATA max UDMA/133 cmd 0xBF18 ctl 0xBF16 bmdma
0xBF08 irq 233
[4294674.900000] hda: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache,
UDMA(33)
[4294674.900000] Uniform CD-ROM driver Revision: 3.20
[4294674.983000] Probing IDE interface ide1...
[4294675.056000] ATA: abnormal status 0xFF on port 0xBF2F
[4294675.056000] ata1: disabling port
[4294675.057000] scsi0 : ata_piix
[4294675.223000] ATA: abnormal status 0xFF on port 0xBF1F
[4294675.223000] ata2: disabling port
[4294675.224000] scsi1 : ata_piix
lspci output:
0000:00:1f.2 0106: Intel Corporation 82801FBM (ICH6M) SATA Controller
(rev 03) (prog-if 01)
Subsystem: Toshiba America Info Systems: Unknown device 0f00
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 233
I/O ports at bf28 [size=8]
I/O ports at bf24 [size=4]
I/O ports at bf18 [size=8]
I/O ports at bf14 [size=4]
I/O ports at bf00 [size=16]
Memory at cddffc00 (32-bit, non-prefetchable) [size=1K]
Capabilities: [70] Power Management version 2
00: 86 80 53 26 07 00 b0 02 03 01 06 01 00 00 00 00
10: 29 bf 00 00 25 bf 00 00 19 bf 00 00 15 bf 00 00
20: 01 bf 00 00 00 fc df cd 00 00 00 00 79 11 00 0f
30: 00 00 00 00 70 00 00 00 00 00 00 00 0b 02 00 00
40: 07 23 00 00 00 00 00 00 01 00 01 00 00 00 00 00
50: 00 00 00 00 10 10 04 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 01 00 02 40 00 00 00 00 00 00 00 00 00 00 00 00
80: 05 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 80 00 15 00 82 01 c0 0a 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 80 0f 04 00 00 00 00 00
--
Matthew Garrett | [email protected]
Matthew Garrett wrote:
> Hi,
>
> We've got an ich6m system (a Toshiba Portege S100). ata_piix attempts to
> drive the chipset, but fails - however, it doesn't bail out. As a result
> it remains bound to the device and ahci isn't loaded.
>
> I've attached the lspci output for the chipset. A few things to note
> are:
>
> 1) The AHCI BAR is set
> 2) The SCC register identifies it as an AHCI controller
> 3) Bits 2 and 0 of the PCS are set, which the spec claims indicates that
> the port is to be controlled as an ahci device.
>
> So, my question is effectively: why does ata_piix attempt to disable
> ahci rather than simply letting the ahci driver bind? Points (1) and (2)
> seem to be checked by the code, but I'm guessing that in the case of (3)
> it should just return ENODEV and let ahci be run instead. If so, should
> I code up a patch?
>
I'm not very sure but it might be historical. ahci got implemented
after ata_piix and in the meantime ata_piix must have handled all it
could. Can you verify whether modifying the code to return -ENODEV work
for your machine? If so, that could be the correct solution but I'm a
bit worried because it could change probing order or fail to enable
devices it used to. Maybe we need a hack to return -ENODEV iff ahci is
there to handle the device.
--
tejun
On Thu, May 11, 2006 at 11:16:08AM +0900, Tejun Heo wrote:
> I'm not very sure but it might be historical. ahci got implemented
> after ata_piix and in the meantime ata_piix must have handled all it
> could. Can you verify whether modifying the code to return -ENODEV work
> for your machine? If so, that could be the correct solution but I'm a
> bit worried because it could change probing order or fail to enable
> devices it used to. Maybe we need a hack to return -ENODEV iff ahci is
> there to handle the device.
I can verify that just loading ahci before ata_piix is successful, and
udev will load both of them since the PCI IDs match. So just having
ata_piix refuse to bind would solve the problem. Unfortunately I can't
see a way of doing this only if ahci is present if they're modular...
--
Matthew Garrett | [email protected]
On Thu, 11 May 2006 09:11:40 +0100 Matthew Garrett wrote:
> On Thu, May 11, 2006 at 11:16:08AM +0900, Tejun Heo wrote:
>
> > I'm not very sure but it might be historical. ahci got implemented
> > after ata_piix and in the meantime ata_piix must have handled all it
> > could. Can you verify whether modifying the code to return -ENODEV work
> > for your machine? If so, that could be the correct solution but I'm a
> > bit worried because it could change probing order or fail to enable
> > devices it used to. Maybe we need a hack to return -ENODEV iff ahci is
> > there to handle the device.
>
> I can verify that just loading ahci before ata_piix is successful, and
> udev will load both of them since the PCI IDs match. So just having
> ata_piix refuse to bind would solve the problem. Unfortunately I can't
> see a way of doing this only if ahci is present if they're modular...
Does the 'combined_mode' kernel parameter help any?
---
~Randy
On Thu, May 11, 2006 at 08:45:41AM -0700, Randy.Dunlap wrote:
> Does the 'combined_mode' kernel parameter help any?
Hmm. Slightly awkward to check - it's a modular system with libata in
initramfs, so getting parameters in may be a pain. However, there's
nothing on the legacy IDE controller - should combined mode actually
make a difference in that case? As I said, ahci works fine - the problem
only occurs with ata_piix. The MAP register indicates that combined mode
isn't in use.
--
Matthew Garrett | [email protected]
Tejun Heo wrote:
> Matthew Garrett wrote:
>> Hi,
>>
>> We've got an ich6m system (a Toshiba Portege S100). ata_piix attempts
>> to drive the chipset, but fails - however, it doesn't bail out. As a
>> result it remains bound to the device and ahci isn't loaded.
>>
>> I've attached the lspci output for the chipset. A few things to note are:
>>
>> 1) The AHCI BAR is set
>> 2) The SCC register identifies it as an AHCI controller
>> 3) Bits 2 and 0 of the PCS are set, which the spec claims indicates
>> that the port is to be controlled as an ahci device.
>>
>> So, my question is effectively: why does ata_piix attempt to disable
>> ahci rather than simply letting the ahci driver bind? Points (1) and
>> (2) seem to be checked by the code, but I'm guessing that in the case
>> of (3) it should just return ENODEV and let ahci be run instead. If
>> so, should I code up a patch?
>>
>
> I'm not very sure but it might be historical. ahci got implemented
> after ata_piix and in the meantime ata_piix must have handled all it
> could. Can you verify whether modifying the code to return -ENODEV work
> for your machine? If so, that could be the correct solution but I'm a
> bit worried because it could change probing order or fail to enable
> devices it used to. Maybe we need a hack to return -ENODEV iff ahci is
> there to handle the device.
It's definitely historical. I'm pretty frazzled now so I don't
remember. It may be that on ICH6, AHCI mode does not cause the PCI IDs
to change, so driver load order winds up dictating what gets used.
Jeff