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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <450F69C3.8060603@garzik.org>
Date:	Mon, 18 Sep 2006 23:53:39 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Tejun Heo <htejun@...il.com>
CC:	"Robin H. Johnson" <robbat2@...too.org>,
	linux-kernel@...r.kernel.org,
	"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>
Subject: Re: 2.6.18-rc7-git1: AHCI not seeing devices on ICH8 mobo (DG965RY)

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

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