linux-kernel - Re: No NCQ support on X61s Ultrabay? (Intel ICH8 SATA controller question)

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]

Date:	Sun, 03 May 2009 14:50:23 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	Tejun Heo <tj@...nel.org>
CC:	Matthew Garrett <mjg59@...f.ucam.org>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Alex Buell <alex.buell@...ted.org.uk>,
	Jeff Garzik <jeff@...zik.org>, Theodore Ts'o <tytso@....edu>,
	linux-kernel@...r.kernel.org,
	Linux IDE mailing list <linux-ide@...r.kernel.org>
Subject: Re: No NCQ support on X61s Ultrabay?  (Intel ICH8 SATA controller
 question)

Tejun Heo wrote:
> Robert Hancock wrote:
>> Matthew Garrett wrote:
>>> On Thu, Apr 30, 2009 at 08:35:08AM -0700, Matthew Wilcox wrote:
>>>> On Thu, Apr 30, 2009 at 02:47:02PM +0100, Alan Cox wrote:
>>>>>> So, at the point of driver load, there just isn't much we can do about
>>>>>> the missing ABAR.  It's sad.  Dunno why some laptop manufacturers
>>>>>> still program the thing into piix mode.  :-(
>>>>> Forcing out of PIIX mode would need to go into the PCI quirks and be a
>>>>> boot option not a module one - at that point its doable as a header
>>>>> quirk.
>>>> I think Matthew Garrett already has code to do this.
>>> Yeah, but some testers reported that it broke after using it for a
>>> while. The most recent version I have is this:
>> We should likely have something like this in the kernel, but it should
>> default to off. For one thing, some machines seem to have BIOS code that
>> tries to poke the controller for some reason during suspend/shutdown
>> events, etc. which would likely go nuts if the controller was
>> unexpectedly in AHCI mode..
> 
> Maybe, I don't know.  Matthew's patch seems clean enough for upstream
> inclusion but I'm always a bit put off about including some feature
> which should default to off.  It never gets used and tested a lot thus
> ending up broken on many configurations further fueling the vicious
> cycle.  After the initial interested users passed, it just becomes
> dead weight none uses which often is quite annoying when trying to
> change code around it because nobody at that point knows on which
> configurations it worked and even whether it not working is a
> regression or expected behavior.

Well, it's a potential concern, but it's simple enough I doubt it would 
really result in much of a burden. Having the force-AHCI option in place 
would allow those interested to try it more easily and see just how 
widely this can be done without breaking things.. It all really depends 
on the BIOS implementation.

> 
> Given the wide variety of ich motherboards out in the wild and all
> their different BIOS revisions and the fact that NCQ or not doesn't
> make whole lot of difference for most desktop workload, I think why
> bother.  A few years back some vendors seemed to use it for product
> differentiation but nowadays it's just silly to disable ahci for that
> purpose.

--
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/