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)
--
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)
On Fri, Nov 09, 2007 at 09:02:35AM +0700, Riki Oktarianto wrote:
> 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
Jeff Garzik wrote:
> On Fri, Nov 09, 2007 at 09:02:35AM +0700, Riki Oktarianto wrote:
>> 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...
On Thu, Nov 08, 2007 at 10:29:37PM -0500, Mark Lord wrote:
> 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
Jeff Garzik wrote:
> On Thu, Nov 08, 2007 at 10:29:37PM -0500, Mark Lord wrote:
>> 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?
On Thu, Nov 08, 2007 at 11:44:22PM -0500, Mark Lord wrote:
> Jeff Garzik wrote:
> >On Thu, Nov 08, 2007 at 10:29:37PM -0500, Mark Lord wrote:
> >>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?
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
On Thu, 8 Nov 2007 22:46:22 -0500
Jeff Garzik <[email protected]> wrote:
> On Thu, Nov 08, 2007 at 10:29:37PM -0500, Mark Lord wrote:
> > 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
On Thu, Nov 08, 2007 at 09:31:30PM -0500, Jeff Garzik wrote:
> On Fri, Nov 09, 2007 at 09:02:35AM +0700, Riki Oktarianto wrote:
> > 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 :)
--
Riki Oktarianto
Alan Cox wrote:
> On Thu, 8 Nov 2007 22:46:22 -0500
> Jeff Garzik <[email protected]> wrote:
>
>
>> On Thu, Nov 08, 2007 at 10:29:37PM -0500, Mark Lord wrote:
>>
>>> 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
>
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
On Thu, 8 Nov 2007 23:57:48 -0500
Jeff Garzik <[email protected]> wrote:
> On Thu, Nov 08, 2007 at 11:44:22PM -0500, Mark Lord wrote:
> > Jeff Garzik wrote:
> > >On Thu, Nov 08, 2007 at 10:29:37PM -0500, Mark Lord wrote:
> > >>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?
>
> 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).
--
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
On Fri, Nov 09, 2007 at 04:49:16PM +0200, T?r?k Edwin wrote:
> 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
>
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...
--
Riki Oktarianto
On 09.11.2007 12:04, Alan Cox wrote:
> On Thu, 8 Nov 2007 22:46:22 -0500
> Jeff Garzik <[email protected]> wrote:
>
> > On Thu, Nov 08, 2007 at 10:29:37PM -0500, Mark Lord wrote:
> > > 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
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
--
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.
Alan Cox wrote:
> On Thu, 8 Nov 2007 22:46:22 -0500
> Jeff Garzik <[email protected]> wrote:
>
>> On Thu, Nov 08, 2007 at 10:29:37PM -0500, Mark Lord wrote:
>>> 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
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
Matthias Schniedermeyer wrote:
> 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
On Fri, Nov 09, 2007 at 10:05:05PM -0500, Jeff Garzik wrote:
> 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
Theodore Tso wrote:
> On Fri, Nov 09, 2007 at 10:05:05PM -0500, Jeff Garzik wrote:
>> 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....
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
On 09.11.2007 22:08, Jeff Garzik wrote:
> Matthias Schniedermeyer wrote:
>> 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
--
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.
On 09.11.2007 22:08, Jeff Garzik wrote:
> Matthias Schniedermeyer wrote:
>> 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
--
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.
Matthias Schniedermeyer wrote:
>..
> 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 (?).
On 10.11.2007 13:01, Mark Lord wrote:
> Matthias Schniedermeyer wrote:
>> ..
>> 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
--
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.
> Alan Cox wrote:
> > On Thu, 8 Nov 2007 22:46:22 -0500
> > Jeff Garzik <[email protected]> wrote:
> >
> >> On Thu, Nov 08, 2007 at 10:29:37PM -0500, Mark Lord wrote:
> >>> 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
>
> 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.
>
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.
-----------------------------------------------------------------------------------
Allen Martin wrote:
> 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.
> 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
On 10.11.2007 00:32, Matthias Schniedermeyer wrote:
> [...]
> 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
--
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 */
On 11.11.2007 15:05, Thorsten Leemhuis wrote:
> On 10.11.2007 00:32, Matthias Schniedermeyer wrote:
> > [...]
> > 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.
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
--
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.
> Allen Martin wrote:
> > 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.
What I'm worred about is SMI traps implemented in the SBIOS for AHCI
workarounds that may be disabled when in IDE mode.
> 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.
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.
-----------------------------------------------------------------------------------
> 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.
> 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
I am glad Nvidia accept this point. It would be nice to see it fixed.
> 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
> > 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.
> > 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
>
> I 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:
..
> 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.
On Wed, Nov 14, 2007 at 01:46:09PM -0500, Mark Lord wrote:
> Allen Martin wrote:
> ..
>> 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