Re: 2.6.18-rc7-git1: AHCI not seeing devices on ICH8 mobo (DG965RY)

Re: 2.6.18-rc7-git1: AHCI not seeing devices on ICH8 mobo (DG965RY)

[Jeff Garzik]

Tejun Heo wrote:
> Jeff, we've been ignoring PI in ahci_host_init()...
> 
>     for (i = 0; i < probe_ent->n_ports; i++) {
> #if 0 /* BIOSen initialize this incorrectly */
>         if (!(hpriv->port_map & (1 << i)))
>             continue;
> #endif
> 
> The comment suggests that some BIOSen initialize PI incorrectly which 
> will probably result in undetected ports.  Is this true?  Would it be 
> dangerous to honor PI on some controllers?  If so, PI should be used 
> only for controllers which does non-linear port mapping.


The core problem is that this register is write-once after reset, i.e. 
BIOS-initialized.  And my experience with pre-production machines has 
been that after reset _by the driver_, the register was useless until 
initialized to a value... _by the driver_.  Which defeats the purpose of 
the register.

So the info contained in the register is quite useful -- when info is 
contained in the register.  :)

Now, granted, I have only seen this on pre-production machines, hence 
the #if 0.  But also, since the code has been disabled in production, we 
don't know how effective it is across all platforms, and we _do_ know 
that it is ineffective if used directly after a reset.  The write-once 
behavior is documented, and normal.

We can't really know which controllers have a non-linear port mapping, 
because that is dependent on both the silicon and whether or not the 
chip is connected to port X[0-31].  The BIOS knows this, of course :)

We can try to enable the code, but I worry that it will fail in 
situations such as kexec.

	Jeff

Re: 2.6.18-rc7-git1: AHCI not seeing devices on ICH8 mobo (DG965RY)

[Robin H. Johnson]

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

On Mon, Sep 18, 2006 at 11:53:39PM -0400, Jeff Garzik wrote:
> We can't really know which controllers have a non-linear port mapping, 
> because that is dependent on both the silicon and whether or not the 
> chip is connected to port X[0-31].  The BIOS knows this, of course :)
I noticed that in my case, when the wrong ioports were probed (base +
port_idx*offset) for port_idx being 2/3 - all of the return values were
zero, instead of the expected values.

You could probably use this to detect cases where PI claims a port is
not present, but it really is.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]