Add quirk to set AHCI mode on ICH boards
PATCH 1/1 Add quirk to set AHCI mode on ICH boards
Some BIOSen map AHCI ABAR but lock the SATA controller to IDE mode. This patch add quirk to set AHCI mode on ICH board with such case.
Tested on Macbook2,1 (ICH7M)
Signature · 43 lines
Riki Oktarianto
--- linux-2.6.24-rc2.orig/drivers/pci/quirks.c
+++ linux-2.6.24-rc2/drivers/pci/quirks.c
@@ -466,6 +466,38 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_I
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_2, quirk_ich6_lpc_acpi );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_3, quirk_ich6_lpc_acpi );
+static void __devinit quirk_ich_sata(struct pci_dev *dev)
+{
+ u32 ahci_bar;
+
+ pci_read_config_dword(dev, 0x24, &ahci_bar);
+ if (!ahci_bar) {
+ return;
+ }
+
+ if ((dev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
+ pci_write_config_byte(dev, PCI_CLASS_PROG, 0x01);
+ pci_write_config_byte(dev, PCI_CLASS_DEVICE, 0x06);
+ }
+ dev->class = PCI_CLASS_STORAGE_SATA_AHCI;
+ printk (KERN_INFO "PCI_CLASS_STORAGE_SATA_AHCI set for %s\n",
+ pci_name(dev));
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2652, quirk_ich_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2653, quirk_ich_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x27c0, quirk_ich_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x27c4, quirk_ich_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2680, quirk_ich_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2820, quirk_ich_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2825, quirk_ich_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2828, quirk_ich_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2920, quirk_ich_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2921, quirk_ich_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2926, quirk_ich_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2928, quirk_ich_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x292d, quirk_ich_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x292e, quirk_ich_sata);
+
/*
* VIA ACPI: One IO region pointed to by longword at
* 0x48 or 0x20 (256 bytes of ACPI registers)Quoted 4 lines · Riki Oktarianto
Some BIOSen map AHCI ABAR but lock the SATA controller to IDE mode. This patch add quirk to set AHCI mode on ICH board with such case.
Tested on Macbook2,1 (ICH7M)
Intel will complain but it's awful tempting...
Jeff
Quoted 7 lines · Jeff Garzik
Quoted 4 lines · Riki Oktarianto
Some BIOSen map AHCI ABAR but lock the SATA controller to IDE mode. This patch add quirk to set AHCI mode on ICH board with such case.
Tested on Macbook2,1 (ICH7M)
Intel will complain but it's awful tempting...
*Very* tempting.
And I might even privately patch my own kernels to map the ACHI BAR in the cases where the BIOS didn't...
Quoted 2 lines · Mark Lord
And I might even privately patch my own kernels to map the ACHI BAR in the cases where the BIOS didn't...
The inability to do this in the general case is the main reason why AHCI was not unconditionally enabled, even in IDE mode, when it was originally added... :/
Jeff, taking a trip down memory lane
Quoted 7 lines · Jeff Garzik
Quoted 2 lines · Mark Lord
And I might even privately patch my own kernels to map the ACHI BAR in the cases where the BIOS didn't...
The inability to do this in the general case is the main reason why AHCI was not unconditionally enabled, even in IDE mode, when it was originally added... :/
..
Yeah, that one's always puzzled me.
It's just software, so why don't we do it? In the PCI layer, that is?
Quoted 5 lines · Mark Lord
Quoted 4 lines · Jeff Garzik
Quoted 2 lines · Mark Lord
And I might even privately patch my own kernels to map the ACHI BAR in the cases where the BIOS didn't...
Quoted 7 lines
Quoted 3 lines
The inability to do this in the general case is the main reason why AHCI was not unconditionally enabled, even in IDE mode, when it was originally added... :/
..
Yeah, that one's always puzzled me.
It's just software, so why don't we do it? In the PCI layer, that is?
Ah, but it's not just software: when trying to find bus address space for the BAR, we don't know if we are stomping on magic hardware resources the BIOS has conveniently failed to tell us about.
So while in all likelihood you will have no problem finding a suitable bus address to use, as a generalized rule it is a far more difficult proposition.
Mind you, I would /love/ to be proven wrong here. In additional to AHCI BAR, modern ata_piix includes SATA PHY registers that we could make use of, but cannot...
Jeff
Quoted 15 lines · On Thu, 8 Nov 2007 23:57:48 -0500 Jeff Garzik <[email protected]> wrote:
Quoted 5 lines · Mark Lord
Quoted 4 lines · Jeff Garzik
Quoted 2 lines · Mark Lord
And I might even privately patch my own kernels to map the ACHI BAR in the cases where the BIOS didn't...
Quoted 8 lines
Quoted 3 lines
The inability to do this in the general case is the main reason why AHCI was not unconditionally enabled, even in IDE mode, when it was originally added... :/
..
Yeah, that one's always puzzled me.
It's just software, so why don't we do it? In the PCI layer, that is?
Quoted 8 lines
Ah, but it's not just software: when trying to find bus address space for the BAR, we don't know if we are stomping on magic hardware resources the BIOS has conveniently failed to tell us about.
So while in all likelihood you will have no problem finding a suitable bus address to use, as a generalized rule it is a far more difficult proposition.
another thing to test before doing this everywhere is suspend/resume. This would use the hardware in a way the bios doesn't expect, and sadly that kind of thing tends to royally b0rk the suspend/resume code often (but of course not always).
Signature · 3 lines
If you want to reach me at my work email, use [email protected] For development, discussion and tips for power savings, visit http://www.lesswatts.org
Quoted 7 lines · On Thu, 8 Nov 2007 22:46:22 -0500 Jeff Garzik <[email protected]> wrote:
Quoted 2 lines · Mark Lord
And I might even privately patch my own kernels to map the ACHI BAR in the cases where the BIOS didn't...
The inability to do this in the general case is the main reason why AHCI was not unconditionally enabled, even in IDE mode, when it was originally added... :/
We've done it all the time for various devices without problems (eg S3 video cards). I'd like to see it go in - although perhaps attached to a force_ahci boot param initially
Quoted 9 lines · Alan Cox
Quoted 5 lines · On Thu, 8 Nov 2007 22:46:22 -0500 Jeff Garzik <[email protected]> wrote:
Quoted 3 lines · Mark Lord
And I might even privately patch my own kernels to map the ACHI BAR in the cases where the BIOS didn't...
Quoted 9 lines
Quoted 4 lines
The inability to do this in the general case is the main reason why AHCI was not unconditionally enabled, even in IDE mode, when it was originally added... :/
We've done it all the time for various devices without problems (eg S3 video cards). I'd like to see it go in - although perhaps attached to a
force_ahciboot param initially
There is one problem with force enabling ahci. You'll loose the CDROM on Dell laptops.
Prior to force-enabling ahci there is one "device" that sees the 2 sata channels, and the 2 ide channels.
When you force-enable ahci, this device becomes the ahci controller (it changes the device id),
and the IDE controller will appear as a separate new device (with another device id), but it is disabled.
There are registers on the ICH7 that allows you to set enabled/disabled status, but according to the documentation you should not enable a device after it has been disabled. In practice I couldn't get the CDROM to get re-enabled:
* either nothing happend
* spurious irqs were sent that nobody handles, unless I used irq=poll; but still no cdrom.
Force-enabling AHCI, and not trying to enable the CDROM works, although I occasionally got NCQ errors.
For a (long) discussion see this thread on the powertop mailing list:
http://www.bughost.org/pipermail/power/2007-June/000533.html
http://www.bughost.org/pipermail/power/2007-June/000573.html
And there is also another slightly different approach:
http://mjg59.livejournal.com/76062.html
Best regards,
--Edwin
Quoted 24 lines · Török Edwin
There is one problem with force enabling ahci. You'll loose the CDROM on Dell laptops.
Prior to force-enabling ahci there is one "device" that sees the 2 sata channels, and the 2 ide channels.
When you force-enable ahci, this device becomes the ahci controller (it changes the device id),
and the IDE controller will appear as a separate new device (with another device id), but it is disabled.There are registers on the ICH7 that allows you to set enabled/disabled status, but according to the documentation you should not enable a device after it has been disabled. In practice I couldn't get the CDROM to get re-enabled:
* either nothing happend
* spurious irqs were sent that nobody handles, unless I used irq=poll; but still no cdrom.Force-enabling AHCI, and not trying to enable the CDROM works, although I occasionally got NCQ errors.
For a (long) discussion see this thread on the powertop mailing list:
http://www.bughost.org/pipermail/power/2007-June/000533.html
http://www.bughost.org/pipermail/power/2007-June/000573.html
Quoted 6 lines
And there is also another slightly different approach:
http://mjg59.livejournal.com/76062.htmlBest regards,
--Edwin
In the MacBook, after enabling ahci the IDE controller also appeared as a separate new device, but it is enabled and handled correctly by piix.
I haven't got any problem, even suspend/resume works fine.
Lucky us who got the ABAR mapped by the BIOS...
Signature · 1 line
Riki Oktarianto
Quoted 7 lines · Alan Cox
Quoted 4 lines · On Thu, 8 Nov 2007 22:46:22 -0500 Jeff Garzik <[email protected]> wrote:
Quoted 2 lines · Mark Lord
And I might even privately patch my own kernels to map the ACHI BAR in the cases where the BIOS didn't...
Quoted 7 lines
Quoted 3 lines
The inability to do this in the general case is the main reason why AHCI was not unconditionally enabled, even in IDE mode, when it was originally added... :/
We've done it all the time for various devices without problems (eg S3 video cards). I'd like to see it go in - although perhaps attached to a
force_ahciboot param initially
I second that.
My computer/mainboard @work has such a "broken" BIOS. Of the 5 SATA-Ports this MB has only 1 (and 1 "missing" that is reported by linux but i can't find on the MB) is configured as AHCI which means that with a HDD & a DVD-ROM connected to 2 of the 4 "piix"-ports, i only have 1 hot-pluggable port instead of the possible 3. And for some temporary work i would really need at least 2 hot-pluggable ports.
So as a work-around i will try a Promise 150 TX4 controller as it is supposed to support hotplug since 2.6.23.
After having hotplug @home from the date the linux-kernel supporting it was released, i don't want to live without it, as i use it daily.
And on the topic of "broken" BIOSes. I have a little empathy for the MB manufactures as non-RAID AHCI royaly screws Windos, so not supporting it reduces their support costs enough to overlook screwing the non-windos faction.
Bis denn
Signature · 4 lines
Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous.
Quoted 1 line · Matthias Schniedermeyer
And on the topic of "broken" BIOSes. I have a little empathy for the MB manufactures as non-RAID AHCI royaly screws Windos, so not supporting it reduces their support costs enough to overlook screwing the non-windos faction.
non-RAID AHCI works just fine on Windows.
Jeff
Quoted 7 lines · Jeff Garzik
Quoted 4 lines · Matthias Schniedermeyer
And on the topic of "broken" BIOSes. I have a little empathy for the MB manufactures as non-RAID AHCI royaly screws Windos, so not supporting it reduces their support costs enough to overlook screwing the non-windos faction.
non-RAID AHCI works just fine on Windows.
Last i know is that Intel doesn't provide an AHCI driver for the non-RAID version. (For whatever political reason). That is even documented in the german "c't", they even had an articel about "patching in the Device-IDs" so the RAID-AHCI driver accepts the non-RAID AHCI chipsets.
And i can second that, when i configure my @home MB (ASUS P5B = non-RAID) to AHCI neither XP nor Vista work.
@work i tried to install Vista on an AHCI-configured machine and aborted that "expriment" after about 2 hours. In IDE-mode it took Vista about 3 Minutes to reach the point where i aborted the AHCI experiment.
So i must say: My milage varies.
Bis denn
Signature · 4 lines
Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous.
Quoted 7 lines · Jeff Garzik
Quoted 4 lines · Matthias Schniedermeyer
And on the topic of "broken" BIOSes. I have a little empathy for the MB manufactures as non-RAID AHCI royaly screws Windos, so not supporting it reduces their support costs enough to overlook screwing the non-windos faction.
non-RAID AHCI works just fine on Windows.
And even if, that doesn't change the fact that there are BIOSes where you can't set AHCI-mode, like my MB @work.
Bis denn
Signature · 4 lines
Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous.
Quoted 2 lines · Matthias Schniedermeyer
..
My computer/mainboard @work has such a "broken" BIOS. Of the 5 SATA-Ports this MB has only 1 (and 1 "missing" that is reported by linux but i can't find on the MB) is configured as AHCI which means that with
..
I have a P5B-VM here (very similar).
The "missing" AHCI port is an eSATA connector on the back panel for this board. Maybe your board just has empty tracks where the connector would otherwise have been populated (?).
Quoted 11 lines · Mark Lord
Quoted 4 lines · Matthias Schniedermeyer
..
My computer/mainboard @work has such a "broken" BIOS. Of the 5 SATA-Ports this MB has only 1 (and 1 "missing" that is reported by linux but i can't find on the MB) is configured as AHCI which means that with..
I have a P5B-VM here (very similar).
The "missing" AHCI port is an eSATA connector on the back panel for this board. Maybe your board just has empty tracks where the connector would otherwise have been populated (?).
Maybe, but that still doesn't "solve" my problem of the SATA-ports that i have to drive by PIIX, instead of the more preferable AHCI.
Bis denn
Signature · 4 lines
Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous.
Quoted 4 lines · Matthias Schniedermeyer
[...]
My computer/mainboard @work has such a "broken" BIOS. Of the 5 SATA-Ports this MB has only 1 (and 1 "missing" that is reported by linux but i can't find on the MB) is configured as AHCI [...]
There is nothing "broken" here. You have a ICH8 (without R) that drives four SATA ports, which are handled by ata_piix.
Then you have a Jmicron JMB363 -- it handles the PATA-Channel and two SATA-Ports -- one internal (near the battery)/next to the PCI-Slot and a external eSATA port. Seems you configured it in AHCI-Mode in the BIOS-Setup. Linux will work just fine if you connect the hard disc to that port. But if you want to install Windows XP you need a driver from Jmicron.
There were BIOSes for the P5B where you could enabled AHCI for the ICH8 as well. It seems Asus removed it in the later BIOS-versions again as Intel doesn't provide a Windows-AHCI driver for the basic ICH8.
HTH and clarifies some of your problems.
Cu
knurd
Signature · 11 lines
Thorsten Leemhuis c't- Magazin für Computertechnik web http://www.heise.de/ct/ Heise Zeitschriften Verlag GmbH&Co.KG phone +49 (0)511 5352 666 Helstorfer Str. 7 icq 140593172 D-30625 Hannover, Germany jabber [email protected] /* Heise Zeitschriften Verlag GmbH & Co. KG, Registergericht: Amtsgericht Hannover HRA 26709; Persönlich haftende Gesellschafterin: Heise Zeitschriften Verlag Geschäftsführung GmbH, Registergericht: Amtsgericht Hannover, HRB 60405 Geschäftsführer: Ansgar Heise, Steven P. Steinkraus, Dr. Alfons Schräder */
Quoted 16 lines · Thorsten Leemhuis
Quoted 4 lines · Matthias Schniedermeyer
[...]
My computer/mainboard @work has such a "broken" BIOS. Of the 5 SATA-Ports this MB has only 1 (and 1 "missing" that is reported by linux but i can't find on the MB) is configured as AHCI [...]There is nothing "broken" here. You have a ICH8 (without R) that drives four SATA ports, which are handled by
ata_piix.Then you have a Jmicron JMB363 -- it handles the PATA-Channel and two SATA-Ports -- one internal (near the battery)/next to the PCI-Slot and a external eSATA port. Seems you configured it in AHCI-Mode in the BIOS-Setup. Linux will work just fine if you connect the hard disc to that port. But if you want to install Windows XP you need a driver from Jmicron.
Quoted 3 lines
There were BIOSes for the P5B where you could enabled AHCI for the ICH8 as well. It seems Asus removed it in the later BIOS-versions again as Intel doesn't provide a Windows-AHCI driver for the basic ICH8.
I don't have an P5B @work, but i guess MSI cooks with water too. :-)
But i have a (1 year old) P5B @home and it is exactly like you said.
My main point is still the same, if Linux could force AHCI mode, i wouldn't have to switch between those modes when booting Wintendo to play some games. (And i could use AHCI @work where i can't switch it in BIOS)
On a side note, with the mainboard i had before the P5B (ASUS, 925X Chipset, ICH 6 or 7) Linux worked in AHCI-mode and Wintendo worked also without problems. (IOW: I did not need to switch modes in BIOS!)
Bis denn
Signature · 4 lines
Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous.
Quoted 6 lines · Alan Cox
Quoted 3 lines · On Thu, 8 Nov 2007 22:46:22 -0500 Jeff Garzik <[email protected]> wrote:
Quoted 2 lines · Mark Lord
And I might even privately patch my own kernels to map the ACHI BAR in the cases where the BIOS didn't...
Quoted 7 lines
Quoted 3 lines
The inability to do this in the general case is the main reason why AHCI was not unconditionally enabled, even in IDE mode, when it was originally added... :/
We've done it all the time for various devices without problems (eg S3 video cards). I'd like to see it go in - although perhaps attached to a
force_ahciboot param initially
By forcing AHCI, your PATA devices will be inaccessible, in a common configuration. It also means shuffling users from one driver to another, which induces breakage.
I was speaking wishfully. Real life intrudes, alas.
Jeff
Quoted 5 lines · Jeff Garzik
By forcing AHCI, your PATA devices will be inaccessible, in a common configuration. It also means shuffling users from one driver to another, which induces breakage.
I was speaking wishfully. Real life intrudes, alas.
Not even as boot-time option? I'm curious whether it might allow me to use AHCI mode on a T60p laptop; right now I can't because in AHCI mode the Ultrabay hard drive device becomes invisible to Linux (although not to Windows, interestingly). I'm currently travelling and I don't carry the T60 around anymore, so I can't do the experiment right this moment, but given that this would allow the T60 to take advantage of ALPM if this works, it would be awfully tempting....
- Ted
Quoted 5 lines · Theodore Tso
Quoted 3 lines · Jeff Garzik
By forcing AHCI, your PATA devices will be inaccessible, in a common configuration. It also means shuffling users from one driver to another, which induces breakage.
I was speaking wishfully. Real life intrudes, alas.
Quoted 7 lines
Not even as boot-time option? I'm curious whether it might allow me to use AHCI mode on a T60p laptop; right now I can't because in AHCI mode the Ultrabay hard drive device becomes invisible to Linux (although not to Windows, interestingly). I'm currently travelling and I don't carry the T60 around anymore, so I can't do the experiment right this moment, but given that this would allow the T60 to take advantage of ALPM if this works, it would be awfully tempting....
Oh sure, a boot-time option would be fine.
I want to spread AHCI far and wide; it is vastly superior to ata_piix in many ways.
I was mainly talking about unconditionally changing behavior from the current default, which presents several problems.
Jeff
Quoted 17 lines
Quoted 5 lines · Alan Cox
Quoted 2 lines · On Thu, 8 Nov 2007 22:46:22 -0500 Jeff Garzik <[email protected]> wrote:
Quoted 1 line · Mark Lord
And I might even privately patch my own kernels to map
the ACHI BAR
Quoted 2 lines
Quoted 2 lines
Quoted 1 line
in the cases where the BIOS didn't...
The inability to do this in the general case is the main
reason why
Quoted 1 line
Quoted 1 line
AHCI was not unconditionally enabled, even in IDE mode,
when it was
Quoted 3 lines
Quoted 1 line
originally added... :/
We've done it all the time for various devices without
problems (eg S3
Quoted 1 line
video cards). I'd like to see it go in - although perhaps
Quoted 9 lines
attached to
Quoted 1 line
a
force_ahciboot param initiallyBy forcing AHCI, your PATA devices will be inaccessible, in a common configuration. It also means shuffling users from one driver to another, which induces breakage.
I was speaking wishfully. Real life intrudes, alas.
At least for NVIDIA controllers, loading the AHCI driver when the BIOS is set to IDE mode is not recommended by NVIDIA. Any AHCI workarounds in the BIOS are likely to be disabled when set to IDE mode. In practice we don't expect to see a lot of users running an AHCI controller in IDE mode unless they have explicitly disabled AHCI from the BIOS or the system builder has some specific reason for shipping IDE mode by default (like support for some legacy DOS or Win9x tools)
-Allen
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Quoted 3 lines · Allen Martin
At least for NVIDIA controllers, loading the AHCI driver when the BIOS is set to IDE mode is not recommended by NVIDIA. Any AHCI workarounds in the BIOS are likely to be disabled when set to IDE mode. In practice
What workarounds, if any, are needed?
We need those in the driver not BIOS anyway, in order to fully support suspend/resume and host controller reset during runtime operation.
Quoted 4 lines
we don't expect to see a lot of users running an AHCI controller in IDE mode unless they have explicitly disabled AHCI from the BIOS or the system builder has some specific reason for shipping IDE mode by default (like support for some legacy DOS or Win9x tools)
That's the situation we run into the most: the system is in IDE mode not because AHCI doesn't work, but for legacy compatibility. We even run into cases (MacBook, Dell servers) where the user is never offered the option to turn on AHCI, even though the silicon supports it.
As such, the user winds up being forced to into the inferior mode for no reason related to their own setup (since they are obviously running Linux).
In Linux at least, we have a bunch of open sata_nv issues, so forcing users' interface into AHCI mode as a default future policy seems like the most stable choice on NVIDIA AHCI platforms.
Jeff
Quoted 5 lines
Quoted 1 line · Allen Martin
At least for NVIDIA controllers, loading the AHCI driver
when the BIOS
Quoted 1 line
is set to IDE mode is not recommended by NVIDIA. Any AHCI
workarounds
Quoted 8 lines
Quoted 1 line
in the BIOS are likely to be disabled when set to IDE mode.
In practice
What workarounds, if any, are needed?
We need those in the driver not BIOS anyway, in order to fully support
suspend/resume and host controller reset during runtime operation.
What I'm worred about is SMI traps implemented in the SBIOS for AHCI workarounds that may be disabled when in IDE mode.
Quoted 3 lines
In Linux at least, we have a bunch of open
sata_nvissues, so forcing users' interface into AHCI mode as a default future policy seems like the most stable choice on NVIDIA AHCI platforms.
I believe most of the issues with sata_nv have been due to lack of documentation of ADMA and swNCQ. The NVIDA AHCI controllers that operate in IDE mode are straight up PATA emulation ANSI/INCITS 370 interface, no hotplug, no NCQ. So I would expect there to not be a lot of issues.
I'm with you that AHCI mode is superior and should be used whenever possible, but it probably comes as no suprise that almost all the hardware/BIOS testing is done with Windows, and operating the hardware in a mode that Windows doesn't (enabling AHCI in classcode 0101) seems like asking for trouble.
-Allen
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Quoted 2 lines
What I'm worred about is SMI traps implemented in the SBIOS for AHCI workarounds that may be disabled when in IDE mode.
For Nvidia devices those would only be present if there were problems with the AHCI hardware right, which would mean you could simply tell us what workarounds to implement.
Quoted 2 lines
I believe most of the issues with
sata_nvhave been due to lack of documentation of ADMA and swNCQ. The NVIDA AHCI controllers that
I am glad Nvidia accept this point. It would be nice to see it fixed.
Quoted 5 lines
I'm with you that AHCI mode is superior and should be used whenever possible, but it probably comes as no suprise that almost all the hardware/BIOS testing is done with Windows, and operating the hardware in a mode that Windows doesn't (enabling AHCI in classcode 0101) seems like asking for trouble.
I agree we must be careful, for example we should put the controller back into its boot mode before suspending so that we can reasonably expect the BIOS to handle suspend/resume. And we certainly need an override option in one direction or the other.
Nevertheless you don't make progress by limiting yourself to avoid breaking the most ancient system. We gave up having a man walking in front of cars with a red flag a long time ago.
Alan
Quoted 7 lines
Quoted 2 lines
What I'm worred about is SMI traps implemented in the SBIOS for AHCI workarounds that may be disabled when in IDE mode.
For Nvidia devices those would only be present if there were problems with the AHCI hardware right, which would mean you could simply tell us
what workarounds to implement.
Errata for which there is an SBIOS workaround are generally only released to BIOS vendors and under NDA. If Linux users were impacted by such a bug we would most likely release a patch, but a much more likely scenario is that it slips through the cracks because it's not a configuration we would test in our QA. So a small minority of users that are running AHCI in class code 0101 would get some very rare but serious errors that would be impossible to debug.
Quoted 4 lines
Quoted 2 lines
I believe most of the issues with
sata_nvhave been due to lack of documentation of ADMA and swNCQ. The NVIDA AHCI controllers thatI am glad Nvidia accept this point. It would be nice to see it fixed.
I don't have any say over that, but it's probably unlikely to be fixed. Going forward we're only using open standards for storage.
-Allen
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Allen Martin wrote:
..
Quoted 3 lines
Errata for which there is an SBIOS workaround are generally only released to BIOS vendors and under NDA. If Linux users were impacted by such a bug we would most likely release a patch, but a much more likely
..
All of that silly secrecy harms your company and your customers. You really should find a way to make the full information available to all O/S providers. In the case of Linux, this costs nothing but a willingness on your part.
Quoted 11 lines · Mark Lord
Allen Martin wrote:
..Quoted 3 lines
Errata for which there is an SBIOS workaround are generally only released to BIOS vendors and under NDA. If Linux users were impacted by such a bug we would most likely release a patch, but a much more likely
..
All of that silly secrecy harms your company and your customers. You really should find a way to make the full information available to all O/S providers. In the case of Linux, this costs nothing but a willingness on your part.
Actually, we (Linux developers) can sign NDAs if that is what the manufacturer needs in order for us to be able to get this information.
If that is what nvidia requires, please let me know and I can set up the proper paperwork so that we can get this needed information.
thanks,
greg k-h
Quoted 11 lines · Jeff Garzik
Quoted 4 lines · Riki Oktarianto
Some BIOSen map AHCI ABAR but lock the SATA controller to IDE mode. This patch add quirk to set AHCI mode on ICH board with such case.
Tested on Macbook2,1 (ICH7M)
Intel will complain but it's awful tempting...
Jeff
Then the tempted users will complain back :)
Signature · 1 line
Riki Oktarianto