[PATCH] Add SATA device to VIA IRQ quirk fixup list

[PATCH] Add SATA device to VIA IRQ quirk fixup list

[Daniel Drake]

Gentoo users at http://bugs.gentoo.org/138036 reported a 2.6.16.17 regression:
new kernels will not boot their system from their VIA SATA hardware.

The solution is just to add the SATA device to the fixup list.
This should also fix the same problem reported by Scott J. Harmon on LKML.

Signed-off-by: Daniel Drake <dsd@gentoo.org>

Index: linux/drivers/pci/quirks.c
===================================================================
--- linux.orig/drivers/pci/quirks.c
+++ linux/drivers/pci/quirks.c
@@ -668,6 +668,7 @@ DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_V
 DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
 DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
 DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237_SATA, quirk_via_irq);
 
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Jeff Garzik]

Daniel Drake wrote:
> Gentoo users at http://bugs.gentoo.org/138036 reported a 2.6.16.17 regression:
> new kernels will not boot their system from their VIA SATA hardware.
> 
> The solution is just to add the SATA device to the fixup list.
> This should also fix the same problem reported by Scott J. Harmon on LKML.
> 
> Signed-off-by: Daniel Drake <dsd@gentoo.org>

Same NAK comment as before...

	Jeff

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Daniel Drake]

Jeff Garzik wrote:
> Daniel Drake wrote:
>> Gentoo users at http://bugs.gentoo.org/138036 reported a 2.6.16.17 
>> regression:
>> new kernels will not boot their system from their VIA SATA hardware.
>>
>> The solution is just to add the SATA device to the fixup list.
>> This should also fix the same problem reported by Scott J. Harmon on 
>> LKML.
>>
>> Signed-off-by: Daniel Drake <dsd@gentoo.org>
> 
> Same NAK comment as before...

I didn't see this patch posted anywhere before, but I just did some more 
searching and found something similar. Are you referring to 
http://lkml.org/lkml/2006/6/24/184 ?

Daniel

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Jeff Garzik]

Daniel Drake wrote:
> Jeff Garzik wrote:
>> Daniel Drake wrote:
>>> Gentoo users at http://bugs.gentoo.org/138036 reported a 2.6.16.17 
>>> regression:
>>> new kernels will not boot their system from their VIA SATA hardware.
>>>
>>> The solution is just to add the SATA device to the fixup list.
>>> This should also fix the same problem reported by Scott J. Harmon on 
>>> LKML.
>>>
>>> Signed-off-by: Daniel Drake <dsd@gentoo.org>
>>
>> Same NAK comment as before...
> 
> I didn't see this patch posted anywhere before, but I just did some more 
> searching and found something similar. Are you referring to 
> http://lkml.org/lkml/2006/6/24/184 ?

Same rationale, but the VIA SATA PCI ID had been submitted before, as 
well...

	Jeff

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Daniel Drake]

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

Jeff Garzik wrote:
> Same rationale, but the VIA SATA PCI ID had been submitted before, as 
> well...

OK. So what's the realistic solution?

The best I can think of is something like this (see attachment).

It's not perfect, because if someone inserts a VIA PCI card into a 
VIA-based motherboard, the quirk will also run on that VIA PCI card.
Is there a way we can realistically say "this is an on-board device" vs 
"this is a PCI card"?

This is untested but I'll happily test and work on it further if it 
doesn't get shot down :)
I have only added the southbridges for my own hardware and the one 
listed on the Gentoo bug. I guess there will be more. I also wonder if 
listing the southbridges is the most sensible approach or if other 
devices (e.g. the host bridge at 00:00.0) would be more appropriate?

Daniel

[-- Attachment #2: via-irq-fixup-sata.patch --]
[-- Type: text/x-patch, Size: 2409 bytes --]

[PATCH] Add SATA device to VIA IRQ quirk fixup list

Gentoo users at http://bugs.gentoo.org/138036 reported a 2.6.16.17 regression:
new kernels will not boot their system from their VIA SATA hardware.

The solution is just to add the SATA device to the fixup list.
This should also fix the same problem reported by Scott J. Harmon on LKML.

Signed-off-by: Daniel Drake <dsd@gentoo.org>

Index: linux/drivers/pci/quirks.c
===================================================================
--- linux.orig/drivers/pci/quirks.c
+++ linux/drivers/pci/quirks.c
@@ -648,10 +648,31 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V
  * Some of the on-chip devices are actually '586 devices' so they are
  * listed here.
  */
+
+static int via_irq_fixup_needed = -1;
+
+/*
+ * As some VIA hardware is available in PCI-card form, we need to restrict
+ * this quirk to VIA PCI hardware built onto VIA-based motherboards only.
+ * This table lists southbridges on motherboards where this quirk needs to
+ * be run.
+ */
+static const struct pci_device_id via_irq_fixup_tbl[] = {
+	{ PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233A) },
+	{ PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237) },
+	{ 0, },
+};
+
 static void quirk_via_irq(struct pci_dev *dev)
 {
 	u8 irq, new_irq;
 
+	if (via_irq_fixup_needed == -1)
+		via_irq_fixup_needed = pci_dev_present(via_irq_fixup_tbl);
+
+	if (!via_irq_fixup_needed)
+		return;
+
 	new_irq = dev->irq & 0xf;
 	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
 	if (new_irq != irq) {
@@ -661,13 +682,7 @@ static void quirk_via_irq(struct pci_dev
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
 
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Sergey Vlasov]

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

On Fri, 14 Jul 2006 13:15:54 +0100 Daniel Drake wrote:

> Jeff Garzik wrote:
> > Same rationale, but the VIA SATA PCI ID had been submitted before, as 
> > well...
> 
> OK. So what's the realistic solution?
> 
> The best I can think of is something like this (see attachment).
> 
> It's not perfect, because if someone inserts a VIA PCI card into a 
> VIA-based motherboard, the quirk will also run on that VIA PCI card.

I still do not understand what will break in this case - won't the
external device just ignore the value which the quirk will write into
its PCI_INTERRUPT_LINE register?

Can someone point me at examples of breakage caused by the original
quirk matching non-builtin devices?  The examples of breakage caused by
missing devices are everywhere now :(

> Is there a way we can realistically say "this is an on-board device" vs 
> "this is a PCI card"?

I thought about limiting to some range of PCI device numbers on the same
bus as the VIA southbridge, but this range does not seem to be
well-defined even for V-Link devices, and old PCI chips like 82C686 had
an external IDSEL# input and could end up on any device number (they had
only a single multifunction PCI device, however).

> This is untested but I'll happily test and work on it further if it 
> doesn't get shot down :)
> I have only added the southbridges for my own hardware and the one 
> listed on the Gentoo bug. I guess there will be more. I also wonder if 
> listing the southbridges is the most sensible approach or if other 
> devices (e.g. the host bridge at 00:00.0) would be more appropriate?

Using the host bridge as a trigger definitely does not look correct
(e.g., 82C686 looks like a normal PCI device and could be used in
systems with non-VIA host bridges).

> Daniel

> [PATCH] Add SATA device to VIA IRQ quirk fixup list
> 
> Gentoo users at http://bugs.gentoo.org/138036 reported a 2.6.16.17 regression:
> new kernels will not boot their system from their VIA SATA hardware.
> 
> The solution is just to add the SATA device to the fixup list.
> This should also fix the same problem reported by Scott J. Harmon on LKML.

Now this changelog is obviously wrong...

> Signed-off-by: Daniel Drake <dsd@gentoo.org>
> 
> Index: linux/drivers/pci/quirks.c
> ===================================================================
> --- linux.orig/drivers/pci/quirks.c
> +++ linux/drivers/pci/quirks.c
> @@ -648,10 +648,31 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V
>   * Some of the on-chip devices are actually '586 devices' so they are
>   * listed here.
>   */
> +
> +static int via_irq_fixup_needed = -1;
> +
> +/*
> + * As some VIA hardware is available in PCI-card form, we need to restrict
> + * this quirk to VIA PCI hardware built onto VIA-based motherboards only.
> + * This table lists southbridges on motherboards where this quirk needs to
> + * be run.
> + */
> +static const struct pci_device_id via_irq_fixup_tbl[] = {
> +	{ PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233A) },
> +	{ PCI_DEVICE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237) },

This table is even more incomplete than the original.  I found these ISA
bridge IDs from VIA in my copy of pci.ids:

        0586  VT82C586/A/B PCI-to-ISA [Apollo VP]
        0596  VT82C596 ISA [Mobile South]
        0686  VT82C686 [Apollo Super South]
        3074  VT8233 PCI to ISA Bridge
        3109  VT8233C PCI to ISA Bridge
        3147  VT8233A ISA Bridge
        3177  VT8235 ISA Bridge
        3227  VT8237 ISA bridge [KT600/K8T800/K8T890 South]
        3287  VT8251 PCI to ISA Bridge
        3337  VT8237A PCI to ISA Bridge
        8231  VT8231 [PCI-to-ISA Bridge]

The major problem with this approach is that this PCI ID list will
inevitably get stale, and there will be no easy way to boot the kernel
on a newer system.  And there is no sign that VIA turns away from their
habit of using PCI_INTERRUPT_LINE for IRQ routing...

However, what about triggering the quirk on any ISA bridge from VIA:

	{
		.vendor 	= PCI_VENDOR_ID_VIA,
		.device		= PCI_ANY_ID,
		.subvendor	= PCI_ANY_ID,
		.subdevice	= PCI_ANY_ID,
		.class		= PCI_CLASS_BRIDGE_ISA << 8,
		.class_mask	= 0xffff00,
	}

> +	{ 0, },
> +};
> +
>  static void quirk_via_irq(struct pci_dev *dev)
>  {
>  	u8 irq, new_irq;
>  
> +	if (via_irq_fixup_needed == -1)
> +		via_irq_fixup_needed = pci_dev_present(via_irq_fixup_tbl);
> +
> +	if (!via_irq_fixup_needed)
> +		return;
> +
>  	new_irq = dev->irq & 0xf;
>  	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
>  	if (new_irq != irq) {
> @@ -661,13 +682,7 @@ static void quirk_via_irq(struct pci_dev
>  		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
>  	}
>  }
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
>  
>  /*
>   * VIA VT82C598 has its device ID settable and many BIOSes
> 

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

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Daniel Drake]

Sergey Vlasov wrote:
> I still do not understand what will break in this case - won't the
> external device just ignore the value which the quirk will write into
> its PCI_INTERRUPT_LINE register?
> 
> Can someone point me at examples of breakage caused by the original
> quirk matching non-builtin devices?  The examples of breakage caused by
> missing devices are everywhere now :(

I know relatively little about PCI, so I'll leave this for someone else 
to answer. I'm just looking to find an acceptable solution which will 
allow these VIA SATA users to be able to boot again...

> Now this changelog is obviously wrong...

Yep, forgot to update/remove it after the original patch.

> This table is even more incomplete than the original.  I found these ISA
> bridge IDs from VIA in my copy of pci.ids:
> 
>         0586  VT82C586/A/B PCI-to-ISA [Apollo VP]
>         0596  VT82C596 ISA [Mobile South]
>         0686  VT82C686 [Apollo Super South]
>         3074  VT8233 PCI to ISA Bridge
>         3109  VT8233C PCI to ISA Bridge
>         3147  VT8233A ISA Bridge
>         3177  VT8235 ISA Bridge
>         3227  VT8237 ISA bridge [KT600/K8T800/K8T890 South]
>         3287  VT8251 PCI to ISA Bridge
>         3337  VT8237A PCI to ISA Bridge
>         8231  VT8231 [PCI-to-ISA Bridge]
> 
> The major problem with this approach is that this PCI ID list will
> inevitably get stale, and there will be no easy way to boot the kernel
> on a newer system.  And there is no sign that VIA turns away from their
> habit of using PCI_INTERRUPT_LINE for IRQ routing...
> 
> However, what about triggering the quirk on any ISA bridge from VIA:
> 
> 	{
> 		.vendor 	= PCI_VENDOR_ID_VIA,
> 		.device		= PCI_ANY_ID,
> 		.subvendor	= PCI_ANY_ID,
> 		.subdevice	= PCI_ANY_ID,
> 		.class		= PCI_CLASS_BRIDGE_ISA << 8,
> 		.class_mask	= 0xffff00,
> 	}

Sounds sensible, but has the disadvantage that we'd be running on all 
future VIA hardware, even if they fixed it. The original quirk code also 
has this issue, but it could be argued that the current ID list does not.

That said, I'm happy to write and test a new patch with your 
suggestions, if it would be acceptable to Greg/Jeff.

Daniel

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Andrew Morton]

On Fri, 14 Jul 2006 07:51:20 -0400
Jeff Garzik <jeff@garzik.org> wrote:

> Daniel Drake wrote:
> > Jeff Garzik wrote:
> >> Daniel Drake wrote:
> >>> Gentoo users at http://bugs.gentoo.org/138036 reported a 2.6.16.17 
> >>> regression:
> >>> new kernels will not boot their system from their VIA SATA hardware.
> >>>
> >>> The solution is just to add the SATA device to the fixup list.
> >>> This should also fix the same problem reported by Scott J. Harmon on 
> >>> LKML.
> >>>
> >>> Signed-off-by: Daniel Drake <dsd@gentoo.org>
> >>
> >> Same NAK comment as before...
> > 
> > I didn't see this patch posted anywhere before, but I just did some more 
> > searching and found something similar. Are you referring to 
> > http://lkml.org/lkml/2006/6/24/184 ?
> 
> Same rationale, but the VIA SATA PCI ID had been submitted before, as 
> well...
> 

argh.  Is someone able to confirm that 2.6.18-rc1-mm2 works OK?  In that
kernel I did a desperation reversion of the offending patches
(revert-VIA-quirk-fixup-additional-PCI-IDs.patch and
revert-PCI-quirk-VIA-IRQ-fixup-should-only-run-for-VIA-southbridges.patch).

Guys, this is a really serious failure but afaict nobody is working on it
and generally nothing at all is happening.

How do we fix all this?  (Who owns it?)

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Chris Wedgwood]

On Fri, Jul 14, 2006 at 07:43:05AM -0700, Andrew Morton wrote:

> How do we fix all this?  (Who owns it?)

If someone who has this problem with ACPI is enabled can verify that
Windows works that would be helpful, then we might be able to figure
out why CONFIG_ACPI=y doesn't suffice for *some* people.  I've been
told that VIA got their ACPI wrong in some cases so that might be why
it doesn't work --- but if Windows deals with it we might be able to
do whatever windows does in this case.

Doing the quick blindly as we did before (and current -mm does) breaks
for some people and trying to list all the IDs breaks for others
(apparently a larger or certainly louder group).

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Sergio Monteiro Basto]

On Fri, 2006-07-14 at 07:43 -0700, Andrew Morton wrote:
> On Fri, 14 Jul 2006 07:51:20 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
> 
> > Daniel Drake wrote:
> > > Jeff Garzik wrote:
> > >> Daniel Drake wrote:
> > >>> Gentoo users at http://bugs.gentoo.org/138036 reported a 2.6.16.17 
> > >>> regression:
> > >>> new kernels will not boot their system from their VIA SATA hardware.
> > >>>
> > >>> The solution is just to add the SATA device to the fixup list.
> > >>> This should also fix the same problem reported by Scott J. Harmon on 
> > >>> LKML.
> > >>>
> > >>> Signed-off-by: Daniel Drake <dsd@gentoo.org>
> > >>
> > >> Same NAK comment as before...
> > > 
> > > I didn't see this patch posted anywhere before, but I just did some more 
> > > searching and found something similar. Are you referring to 
> > > http://lkml.org/lkml/2006/6/24/184 ?
> > 
> > Same rationale, but the VIA SATA PCI ID had been submitted before, as 
> > well...
> > 
> 
> argh.  Is someone able to confirm that 2.6.18-rc1-mm2 works OK?  In that
> kernel I did a desperation reversion of the offending patches
> (revert-VIA-quirk-fixup-additional-PCI-IDs.patch and
> revert-PCI-quirk-VIA-IRQ-fixup-should-only-run-for-VIA-southbridges.patch).
> 
> Guys, this is a really serious failure but afaict nobody is working on it
> and generally nothing at all is happening.
> 
> How do we fix all this?  (Who owns it?)

Andrew, 
please listen to me ,
I think 
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq)
is wright if interrupts are in XT-PIC mode, If we disable APIC or/and
Local APIC, yes we have to quirk the VIA PCI interrupts, ok ?

if not, if we have IO-APIC enabled (with ACPI I guess, ACPI knows make
IRQ routings ), we don't need neither should quirks the VIA PCIs.
This is my opinion base on some emails from Alan Cox , Bjorn Helgas
etc.. and for now is the best shot we have.


Thanks,
---
Sérgio M. B.

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Scott J. Harmon]

Chris Wedgwood wrote:
> On Fri, Jul 14, 2006 at 07:43:05AM -0700, Andrew Morton wrote:
> 
>> How do we fix all this?  (Who owns it?)
> 
> If someone who has this problem with ACPI is enabled can verify that
> Windows works that would be helpful, then we might be able to figure
> out why CONFIG_ACPI=y doesn't suffice for *some* people.  I've been
> told that VIA got their ACPI wrong in some cases so that might be why
> it doesn't work --- but if Windows deals with it we might be able to
> do whatever windows does in this case.

Windows worked when I had it installed.

> 
> Doing the quick blindly as we did before (and current -mm does) breaks
> for some people and trying to list all the IDs breaks for others
> (apparently a larger or certainly louder group).

Thanks,

Scott.

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Chris Wedgwood]

On Fri, Jul 14, 2006 at 04:46:20PM +0100, Sergio Monteiro Basto wrote:

> I think DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
> quirk_via_irq) is wright if interrupts are in XT-PIC mode, If we
> disable APIC or/and Local APIC, yes we have to quirk the VIA PCI
> interrupts, ok ?

i have a patch (that takes a command line argument to override this)
that more-or-less does that, by default it will frob all VIA devices
if no IO-APIC or is present or you can pass an argument to always do
everything or do nothing

i was hoping we could figure out something smarter than just looking
to see if an IO-APIC was found though, maybe someting like checking if
ACPI actually did something sane, but i know zilch about the ACPI side
of things

i can refresh that against, -git and -mm if people want it

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Chris Wedgwood]

On Fri, Jul 14, 2006 at 05:17:03PM +0100, Daniel Drake wrote:

> This suggests that the quirk is only needed for ACPI users, at least
> on that system.
>
> http://bugs.gentoo.org/show_bug.cgi?id=138036

Actually, the opposite is what I've seen and also had other people
claim.

VIA apparently when asked about this quirk (this wasn't by me, I have
no current contacts there and they've been very quiet here) responded
"use ACPI".

FWIW, I have very similar hardware to what's in the bug report and it
works w/ ACPI just fine.

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Daniel Drake]

Chris Wedgwood wrote:
> If someone who has this problem with ACPI is enabled can verify that
> Windows works that would be helpful, then we might be able to figure
> out why CONFIG_ACPI=y doesn't suffice for *some* people.  I've been
> told that VIA got their ACPI wrong in some cases so that might be why
> it doesn't work --- but if Windows deals with it we might be able to
> do whatever windows does in this case.

It is worth noting that on the Gentoo bug report, the user could not 
boot from VIA SATA while that ID was not in the list. However, if the 
ACPI was *disabled* then the system booted fine (even without the SATA 
ID in the list, i.e. no quirk applied).

This suggests that the quirk is only needed for ACPI users, at least on 
that system.

http://bugs.gentoo.org/show_bug.cgi?id=138036

Daniel

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Daniel Drake]

Daniel Drake wrote:
> It is worth noting that on the Gentoo bug report, the user could not 
> boot from VIA SATA while that ID was not in the list. However, if the 
> ACPI was *disabled* then the system booted fine (even without the SATA 
> ID in the list, i.e. no quirk applied).
> 
> This suggests that the quirk is only needed for ACPI users, at least on 
> that system.

I just confirmed this on my own system, at least partially. I removed 
the quirk and the system booted fine.

This is with ACPI enabled, but APIC not enabled (hence the interrupts 
are XT-PIC). I cannot enable APIC on this system due to buggy BIOS.

Daniel

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Chris Wedgwood]

On Fri, Jul 14, 2006 at 05:24:01PM +0100, Daniel Drake wrote:

> are XT-PIC). I cannot enable APIC on this system due to buggy BIOS.
                               ^^^^

IO-APIC you mean?

what system have you got there?

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Sergio Monteiro Basto]

On Fri, 2006-07-14 at 17:24 +0100, Daniel Drake wrote:
> Daniel Drake wrote:
> > It is worth noting that on the Gentoo bug report, the user could not 
> > boot from VIA SATA while that ID was not in the list. However, if the 
> > ACPI was *disabled* then the system booted fine (even without the SATA 
> > ID in the list, i.e. no quirk applied).
> > 
> > This suggests that the quirk is only needed for ACPI users, at least on 
> > that system.
> 
> I just confirmed this on my own system, at least partially. I removed 
> the quirk and the system booted fine.
> 
> This is with ACPI enabled, but APIC not enabled (hence the interrupts 
> are XT-PIC). I cannot enable APIC on this system due to buggy BIOS.
> 
> Daniel

Daniel, VIA_SATA is not in the list , so when you write remove , you
remove what ? or you want say the opposite ?  
Please rephrase your sentence .

Do you need quirk SATA with acpi=off  ?

Do you need quirk with ACPI enabled ? 

Sérgio M. B. 

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Daniel Drake]

Chris Wedgwood wrote:
> On Fri, Jul 14, 2006 at 05:24:01PM +0100, Daniel Drake wrote:
> 
>> are XT-PIC). I cannot enable APIC on this system due to buggy BIOS.
>                                ^^^^
> 
> IO-APIC you mean?

Yes.

> what system have you got there?

Abit KX7-333 (VIA Apollo KT266/A/333).

I also tried disabling ACPI completely, and the system booted without 
the quirk applied. I was of the suspicion that if I could get IO-APIC 
enabled, then the system would be unable to boot, but this is only 
guesswork based on the info in the Gentoo bug report.

Perhaps we can discount my system, but Aiko Barz's case from the Gentoo 
bug should definitely be considered: Without ACPI, the quirk is not 
needed. With ACPI, the quirk is needed.

Daniel

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Daniel Drake]

Sergio Monteiro Basto wrote:
>> I just confirmed this on my own system, at least partially. I removed 
>> the quirk and the system booted fine.
>>
>> This is with ACPI enabled, but APIC not enabled (hence the interrupts 
>> are XT-PIC). I cannot enable APIC on this system due to buggy BIOS.
>>
>> Daniel
> 
> Daniel, VIA_SATA is not in the list , so when you write remove , you
> remove what ? or you want say the opposite ?  
> Please rephrase your sentence .

Sorry, I should have been clearer. I do not own any VIA SATA hardware 
(that info was relayed from a Gentoo bug report). My own hardware is 
older, [Apollo KT266/A/333]. The quirk gets applied to my IDE controller 
only (both before and after Chris's changes), and I boot from a disk 
connected to this IDE controller.

00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333]
00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo 
KT266/A/333 AGP]
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8233A ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 23)
00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 23)
01:00.0 VGA compatible controller: nVidia Corporation NV15 [GeForce2 
GTS/Pro] (rev a3)

When I said I removed the quirk, I meant I removed the whole quirk, 
which prevented it from running on my hardware.

> Do you need quirk SATA with acpi=off  ?

Assuming you mean "quirk IDE", no.

> Do you need quirk with ACPI enabled ? 

No. But, my interrupts are always XT-PIC, I cannot enable IO-APIC (not 
sure how much relevance that has, possibly worth noting though).



Just for clarity, I'll respond to those 2 questions again with Aiko 
Barz's system in mind (the user on the Gentoo bug report) -- this is the 
one with the VIA SATA hardware.

 > Do you need quirk SATA with acpi=off  ?

No.

 > Do you need quirk with ACPI enabled ?

Yes.


Daniel

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Sergey Vlasov]

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

On Fri, 14 Jul 2006 18:06:08 +0100 Daniel Drake wrote:

> Sergio Monteiro Basto wrote:
> >> I just confirmed this on my own system, at least partially. I removed 
> >> the quirk and the system booted fine.
> >>
> >> This is with ACPI enabled, but APIC not enabled (hence the interrupts 
> >> are XT-PIC). I cannot enable APIC on this system due to buggy BIOS.
> >>
> >> Daniel
> > 
> > Daniel, VIA_SATA is not in the list , so when you write remove , you
> > remove what ? or you want say the opposite ?  
> > Please rephrase your sentence .
> 
> Sorry, I should have been clearer. I do not own any VIA SATA hardware 
> (that info was relayed from a Gentoo bug report). My own hardware is 
> older, [Apollo KT266/A/333]. The quirk gets applied to my IDE controller 
> only (both before and after Chris's changes), and I boot from a disk 
> connected to this IDE controller.

Then the quirk effectively does nothing - the IDE controller is most
likely in legacy mode, and therefore does not use its PCI interrupt (it
uses legacy IRQs 15 and 14 instead).

> 00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333]
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo 
> KT266/A/333 AGP]
> 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
> RTL-8139/8139C/8139C+ (rev 10)
> 00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
> RTL-8139/8139C/8139C+ (rev 10)
> 00:11.0 ISA bridge: VIA Technologies, Inc. VT8233A ISA Bridge
> 00:11.1 IDE interface: VIA Technologies, Inc. 
> VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
> 00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
> Controller (rev 23)
> 00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
> Controller (rev 23)

On this system the quirk would matter only for these USB controllers.

> 01:00.0 VGA compatible controller: nVidia Corporation NV15 [GeForce2 
> GTS/Pro] (rev a3)
> 
> When I said I removed the quirk, I meant I removed the whole quirk, 
> which prevented it from running on my hardware.
> 
> > Do you need quirk SATA with acpi=off  ?
> 
> Assuming you mean "quirk IDE", no.
> 
> > Do you need quirk with ACPI enabled ? 
> 
> No. But, my interrupts are always XT-PIC, I cannot enable IO-APIC (not 
> sure how much relevance that has, possibly worth noting though).

When IO-APIC is used, the "& 0x0f" part of the quirk becomes relevant -
in this mode 0 in the register means IO-APIC IRQ 16, 1 means IRQ 17,
etc...  However, not all chips work like this - e.g., the builtin audio
device of VT8237 has fixed IRQ routing in IO-APIC mode and ignores the
value of PCI_INTERRUPT_LINE completely.

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

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Chris Wedgwood]

On Fri, Jul 14, 2006 at 07:08:10AM -0400, Jeff Garzik wrote:

> Same NAK comment as before...

BTW, what's in -mm it even more aggressive.

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Sergio Monteiro Basto]

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

On Fri, 2006-07-14 at 09:13 -0700, Chris Wedgwood wrote:
> i have a patch (that takes a command line argument to override this)
> that more-or-less does that, by default it will frob all VIA devices
> if no IO-APIC or is present or you can pass an argument to always do
> everything or do nothing
> 
> i was hoping we could figure out something smarter than just looking
> to see if an IO-APIC was found though, maybe someting like checking if
> ACPI actually did something sane, but i know zilch about the ACPI side
> of things
> 
> i can refresh that against, -git and -mm if people want it 

Of course, I like to see and test the patch, refresh or not.

Thanks,
-- 
Sérgio M.B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Daniel Drake]

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

Andrew,

Andrew Morton wrote:
> Guys, this is a really serious failure but afaict nobody is working on it
> and generally nothing at all is happening.
> 
> How do we fix all this?  (Who owns it?)

I'd like to push the attached patch for inclusion. I have tested it on 
my VIA Apollo system, and I hope it is an acceptable compromise while 
nobody has a complete understanding of the issues around this quirk.

I think this belongs to Greg as its a PCI thing, but we should probably 
look for a yay or nay from Jeff as well.

Daniel

[-- Attachment #2: via-irq-fixup-sata.patch --]
[-- Type: text/x-patch, Size: 3308 bytes --]

[PATCH] PCI quirk_via_irq behaviour change

The most recent VIA IRQ quirk changes have broken various VIA devices for
some users. We are not able to add these devices to the blacklist as they
are also available in PCI-card form, and running the quirk on these devices
brings us back to square one (running the VIA quirk on non-VIA boards where
the quirk is not needed).

This patch, based on suggestions from Sergey Vlasov, implements a scheme
similar to but more restrictive than the scheme we had in 2.6.16 and earlier.
It runs the quirk on all VIA hardware, but only if a VIA southbridge was
detected on the system.

There is still a downside to this patch: if the user inserts a VIA PCI card
into a VIA-based motherboard, the quirk will also run on the VIA PCI card.
This corner case is hard to avoid.

However, I think this patch should be applied because:
 - The quirk won't run on Chris's non-VIA system, which was the cause of
   change in the first place.
 - Affected sata_via users will be able to boot again
 - Nobody really has a full understanding of the problem and the issues,
   so I think this "compromise solution" should be acceptable for now.

Signed-off-by: Daniel Drake <dsd@gentoo.org>

Index: linux/drivers/pci/quirks.c
===================================================================
--- linux.orig/drivers/pci/quirks.c
+++ linux/drivers/pci/quirks.c
@@ -648,10 +648,37 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V
  * Some of the on-chip devices are actually '586 devices' so they are
  * listed here.
  */
+
+static int via_irq_fixup_needed = -1;
+
+/*
+ * As some VIA hardware is available in PCI-card form, we need to restrict
+ * this quirk to VIA PCI hardware built onto VIA-based motherboards only.
+ * We try to locate a VIA southbridge before deciding whether the quirk
+ * should be applied.
+ */
+static const struct pci_device_id via_irq_fixup_tbl[] = {
+	{
+		.vendor 	= PCI_VENDOR_ID_VIA,
+		.device		= PCI_ANY_ID,
+		.subvendor	= PCI_ANY_ID,
+		.subdevice	= PCI_ANY_ID,
+		.class		= PCI_CLASS_BRIDGE_ISA << 8,
+		.class_mask	= 0xffff00,
+	},
+	{ 0, },
+};
+
 static void quirk_via_irq(struct pci_dev *dev)
 {
 	u8 irq, new_irq;
 
+	if (via_irq_fixup_needed == -1)
+		via_irq_fixup_needed = pci_dev_present(via_irq_fixup_tbl);
+
+	if (!via_irq_fixup_needed)
+		return;
+
 	new_irq = dev->irq & 0xf;
 	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
 	if (new_irq != irq) {
@@ -661,13 +688,7 @@ static void quirk_via_irq(struct pci_dev
 		pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
 	}
 }
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
 
 /*
  * VIA VT82C598 has its device ID settable and many BIOSes

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Greg KH]

On Sun, Jul 16, 2006 at 03:09:36PM +0100, Daniel Drake wrote:
> Andrew,
> 
> Andrew Morton wrote:
> >Guys, this is a really serious failure but afaict nobody is working on it
> >and generally nothing at all is happening.
> >
> >How do we fix all this?  (Who owns it?)
> 
> I'd like to push the attached patch for inclusion. I have tested it on 
> my VIA Apollo system, and I hope it is an acceptable compromise while 
> nobody has a complete understanding of the issues around this quirk.
> 
> I think this belongs to Greg as its a PCI thing, but we should probably 
> look for a yay or nay from Jeff as well.

Looks ok to me, but I'll defer to Jeff for this one.

thanks,

greg k-h

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Chris Wedgwood]

On Sun, Jul 16, 2006 at 11:31:26AM -0700, Greg KH wrote:

> Looks ok to me, but I'll defer to Jeff for this one.

Could we make sure this doesn't cause any regressions with KT800
chipsets (I think that's it, the VIA thing used on some Athlon64
mainboards).

IIRC some require the quirk and some seem to work without it, the
later class can use the IOAPIC and if we do this might be be breaking
that?

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Andrew Morton]

On Sun, 16 Jul 2006 17:34:18 -0700
Chris Wedgwood <cw@f00f.org> wrote:

> On Sun, Jul 16, 2006 at 11:31:26AM -0700, Greg KH wrote:
> 
> > Looks ok to me, but I'll defer to Jeff for this one.
> 
> Could we make sure this doesn't cause any regressions with KT800
> chipsets (I think that's it, the VIA thing used on some Athlon64
> mainboards).
> 
> IIRC some require the quirk and some seem to work without it, the
> later class can use the IOAPIC and if we do this might be be breaking
> that?

Do you recall which of the several reporters had such a system?

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Alan Cox]

A few comments

"The legacy IDE is using IRQ 14 or 15 not PCI"

This is half correct - V-Link is not involved in this case, however the
legacy IRQs are configurable and steerable via func 0 reg 0x4C for some
chips. If this has been set by a weirdass bios (bits 3-0 not 0x0100 for
the 8233C  varies for others) then we've never supported it.


I have full IRQ routing info for some of the VIA chips and it varies by
chip how this all works.

The 8233/8233C routes via register 0x4C/0x4D of function 0 for internal
devices and via 0x55->0x57 (polarities on 0x54) for PCI interrupts. The
devices use the IRQ number not line. Also to add fun the 8233C has a
3com nic part that does this...

There are then a seperate set of register mappings for SCI and for ISA
IRQ mapping.

There is an errata with the internal devices of the 8235 and earlier
which can be used to detect them fairly well. Only the low four bits of
0ffset 0x3C are writable not the full IRQ value.


Some later chips use bits to indicate PIC v APIC routing.

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Sergio Monteiro Basto]

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

Hi, Alan 

But can we know if dev->irq is XT-PIC ?  or not ? 
or could we know if IO_APIC or LOCAL_APIC is enabled or
not ?

on linux-2.6.17/drivers/pci/quirks.c    

  * we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
  * interrupts delivered properly.
  */

 static void quirk_via_irq(struct pci_dev *dev)
 {
        u8 irq, new_irq;

I want put here something like:  if ( dev->irq != XT-PIC) return and
don't quirk this dev.
        else 

        new_irq = dev->irq & 0xf;
        pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);



On Wed, 2006-07-26 at 01:42 +0100, Alan Cox wrote:
> A few comments
> 
> "The legacy IDE is using IRQ 14 or 15 not PCI"
> 
> This is half correct - V-Link is not involved in this case, however the
> legacy IRQs are configurable and steerable via func 0 reg 0x4C for some
> chips. If this has been set by a weirdass bios (bits 3-0 not 0x0100 for
> the 8233C  varies for others) then we've never supported it.
> 
> 
> I have full IRQ routing info for some of the VIA chips and it varies by
> chip how this all works.
> 
> The 8233/8233C routes via register 0x4C/0x4D of function 0 for internal
> devices and via 0x55->0x57 (polarities on 0x54) for PCI interrupts. The
> devices use the IRQ number not line. Also to add fun the 8233C has a
> 3com nic part that does this...
> 
> There are then a seperate set of register mappings for SCI and for ISA
> IRQ mapping.
> 
> There is an errata with the internal devices of the 8235 and earlier
> which can be used to detect them fairly well. Only the low four bits of
> 0ffset 0x3C are writable not the full IRQ value.
> 
> 
> Some later chips use bits to indicate PIC v APIC routing.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Sérgio M.B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Daniel Drake]

Sergio Monteiro Basto wrote:
> I want put here something like:  if ( dev->irq != XT-PIC) return and
> don't quirk this dev.

I can't explain why, but this is not sufficient. Gentoo now have 2 
completely separate bug reports where the quirk is *only* needed when 
ACPI/APIC are enabled.

http://bugs.gentoo.org/138036
http://bugs.gentoo.org/141082

I'm not disputing that there are other systems where the opposite is 
true, but at least with our current level of understanding we cannot 
apply the quirk on an irq-type basis.

Daniel

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Sergio Monteiro Basto]

On Wed, 2006-07-26 at 14:59 +0100, Daniel Drake wrote:
> Sergio Monteiro Basto wrote:
> > I want put here something like:  if ( dev->irq != XT-PIC) return and
> > don't quirk this dev.
> 
> I can't explain why, but this is not sufficient. Gentoo now have 2 
> completely separate bug reports where the quirk is *only* needed when 
> ACPI/APIC are enabled.
> 

No, Quirks are only need when interrupts are in XT-PIC. (is my bet).
When APIC and ACPI is enabled (and working) we don't need quirks.

Someone said on XT-PIC VIA system, don't need, to boot, quirks when ACPI
is disabled, but this statement don't prove that the quirk aren't need
it . 

--
Sérgio M. B. 


> http://bugs.gentoo.org/138036
> http://bugs.gentoo.org/141082
> 
> I'm not disputing that there are other systems where the opposite is 
> true, but at least with our current level of understanding we cannot 
> apply the quirk on an irq-type basis.
> 
> Daniel
> 

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Daniel Drake]

Sergio Monteiro Basto wrote:
> No, Quirks are only need when interrupts are in XT-PIC. (is my bet).
> When APIC and ACPI is enabled (and working) we don't need quirks.
> 
> Someone said on XT-PIC VIA system, don't need, to boot, quirks when ACPI
> is disabled, but this statement don't prove that the quirk aren't need
> it . 

No, please read again:

In the kernels referenced in the bug reports, the quirks were not being 
applied.

When the systems booted up a usual APIC/ACPI config, the hardware in 
question did not work. The quirk was not applied here.

When the system booted up a kernel with acpi=off, the hardware in 
question worked fine. The quirk was not applied here.

When the kernel is modified to apply the quirk again, the system works 
fine in both cases.

IOW, on these systems at least, the quirk is *definitely* needed when 
ACPI/APIC are enabled, whereas in your last mail, you were suggesting we 
should only do the quirk in non-APIC mode:

> I want put here something like:  if ( dev->irq != XT-PIC) return and
> don't quirk this dev.

Such a change would stop the hardware in question from working when 
ACPI/APIC are enabled on these systems.

Daniel

>> http://bugs.gentoo.org/138036
>> http://bugs.gentoo.org/141082

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Sergio Monteiro Basto]

On Wed, 2006-07-26 at 15:31 +0100, Daniel Drake wrote:
> When the systems booted up a usual APIC/ACPI config, the hardware in 
> question did not work. The quirk was not applied here. 

I think you are missing that APIC is disable by bios or/and by kernel,
and the systems run on XT-PIC.
I don't have time to read the reports sorry .

--
Sérgio M. B. 

Re: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Sergio Monteiro Basto]

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

On Wed, 2006-07-26 at 15:31 +0100, Daniel Drake wrote:
> >> http://bugs.gentoo.org/138036
> >> http://bugs.gentoo.org/141082
> 

http://files.haeckser.net/bugs.gentoo.org/dmesg/dmesg-2.6.16-gentoo-r6.txt
you got "No local APIC present or hardware disabled" and no more
messages about lapic or IO-APIC.
http://files.haeckser.net/bugs.gentoo.org/dmesg/dmesg-acpi-off.txt
you got "No local APIC present or hardware disabled"

so you got yours system is in XT-PIC mode, and therefore you need quirk
VIA PCI s , my rule still correct. 
-- 
Sérgio M. B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2166 bytes --]

RE: [PATCH] Add SATA device to VIA IRQ quirk fixup list

[Brown, Len]

I've been trying very hard to stay away from VIA quirks,
but there are some things to be aware of.

1. quirks are independent of ACPI on/off

Note that ACPI PCI Interrupt Link Devices
are just a wrapper around the same legacy PIRQ router
seen in legacy mode.

The added twist is that it is possible for VIA
to do quirks in ACPI automatically if they want to --
since all it takes is a few lines of AML where we set the link
to a new state.  (we should go see if they're doing this now --
in the past I don not think they did, and so quirks are probably
still needed in ACPI mode on at least old machines)

2. quirks are independent of PIC/IOAPIC

In both ACPI on and ACPI off modes, we tend to touch PIC
interrupts as _little_ as possible.  So it may be that
our system boots up just fine in PIC mode w/o quirks --
but the reason may be because we didn't try to invoke any irq mappings
--
we found we could live with what the BIOS left us and we
used it untouched.

As the IOAPIC is disabled in the default BIOS mode,
we always have to set that up, and a good part of the time
we have to choose our own mappings, so quirks are more likely
to be noticed to be ncessary in IOAPIC mode.

hope this helps,
-Len