x86_64 VIA chipset IOAPIC fix

PATCH In review Tony Lindgren 4 participants 13 messages Mar 25, 2004 – Mar 30, 2004

Subsystems (2)

ACPI PCI

lore

Share & tools

lore

Tony Lindgren

author

2004-03-25 03:35 UTC #0 lore raw

PATCH 1/1 x86_64 VIA chipset IOAPIC fix

Hi Andi & Len,

Sorry for cross posting all over the place, I tried to CC some people who have been bugged by this bug.

I finally got the IOAPIC working on my eMachines m6805 amd64 laptop with the following patch. I have not tried it on any other machines, so can you guys please check the sanity and make the necessary changes if needed?

This fixes at least ACPI bug 2090:

http://bugme.osdl.org/show_bug.cgi?id=2090

Might fix some other x86 VIA bugs too?

To turn it on, apic still needs to be specified in the kernel cmdline:

root=/dev/hda3 ro psmouse.proto=imps apic console=tty0

Now cat /proc/interrupts shows:

 0:      70843    IO-APIC-edge  timer
 1:          9    IO-APIC-edge  i8042
 2:          0          XT-PIC  cascade
 8:          0    IO-APIC-edge  rtc
10:          0   IO-APIC-level  acpi
12:         44    IO-APIC-edge  i8042
14:       2734    IO-APIC-edge  ide0
15:         19    IO-APIC-edge  ide1
17:          0   IO-APIC-level  yenta
18:          0   IO-APIC-level  eth0
21:        565   IO-APIC-level  ehci_hcd, uhci_hcd, uhci_hcd, uhci_hcd
22:          0   IO-APIC-level  VIA8233
23:          6   IO-APIC-level  eth1
NMI:         12 
LOC:      70752 
ERR:          0
MIS:          0

And things are just working :)

Regards,

Tony

And here's the patch, it's against 2.6.5-rc2:

drivers/acpi/pci_link.c +5 -9

diff -Nru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
@@ -402,10 +402,8 @@
 		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Unable to read status\n"));
 		return_VALUE(result);
 	}
-	if (!link->device->status.enabled) {
-		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Link disabled\n"));
-		return_VALUE(-ENODEV);
-	}
+	if (!link->device->status.enabled)
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Link disabled: VIA chipset? Trying to continue\n"));
 
 	/* Make sure the active IRQ is the one we requested. */
 	result = acpi_pci_link_try_get_current(link, irq);

@@ -415,11 +413,9 @@
    
 	if (link->irq.active != irq) {
 		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, 
-			"Attempt to enable at IRQ %d resulted in IRQ %d\n", 
-			irq, link->irq.active));
-		link->irq.active = 0;
-		acpi_ut_evaluate_object (link->handle, "_DIS", 0, NULL);	   
-		return_VALUE(-ENODEV);
+			"Attempt to enable at IRQ %d resulted in IRQ %d: VIA chipset? Using irq %d\n", 
+			irq, link->irq.active, irq));
+		link->irq.active = irq;
 	}
 
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Set IRQ %d\n", link->irq.active));

Len Brown

2004-03-26 00:32 UTC #1 lore raw

Tony,
At one point we nearly deleted disabled links on parsing them
http://bugme.osdl.org/show_bug.cgi?id=1581
But testing that "fix" suggested that some systems we'd considered "broken" before required the opposite -- pretending that the the links are not disabled at all.

Looks like that is what your VIA box needs.

I think we need to tread carefully in this area. Ignoring the result of _CRS means that we really don't know if the IRQ is programmed or not. We could attach a device to the wrong IRQ and not know it. Unclear if that risk is a better policy than pretending we confirmed that the IRQ was successfully programmed when it may not have been.

perhaps you can attach this patch to 1581 and we can work there to come up with a "disabled links patch" that makes sense for all systems. We might find that we need only a small VIA-specific tweak to an otherwise robust policy.

If your dmesg and acpidmp are different from 2090, it would be good to attach them also.

thanks,
-Len

Quoted 81 lines · Tony Lindgren

Hi Andi & Len,
Sorry for cross posting all over the place, I tried to CC some people who have been bugged by this bug.
I finally got the IOAPIC working on my eMachines m6805 amd64 laptop with the following patch. I have not tried it on any other machines, so can you guys please check the sanity and make the necessary changes if needed?
This fixes at least ACPI bug 2090:
http://bugme.osdl.org/show_bug.cgi?id=2090
Might fix some other x86 VIA bugs too?
To turn it on, apic still needs to be specified in the kernel cmdline:
root=/dev/hda3 ro psmouse.proto=imps apic console=tty0
Now cat /proc/interrupts shows:
 0:      70843    IO-APIC-edge  timer
 1:          9    IO-APIC-edge  i8042
 2:          0          XT-PIC  cascade
 8:          0    IO-APIC-edge  rtc
10:          0   IO-APIC-level  acpi
12:         44    IO-APIC-edge  i8042
14:       2734    IO-APIC-edge  ide0
15:         19    IO-APIC-edge  ide1
17:          0   IO-APIC-level  yenta
18:          0   IO-APIC-level  eth0
21:        565   IO-APIC-level  ehci_hcd, uhci_hcd, uhci_hcd, uhci_hcd
22:          0   IO-APIC-level  VIA8233
23:          6   IO-APIC-level  eth1
NMI:         12 
LOC:      70752 
ERR:          0
MIS:          0
And things are just working :)
Regards,
Tony
And here's the patch, it's against 2.6.5-rc2:
______________________________________________________________________
diff -Nru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
drivers/acpi/pci_link.c +5 -9
@@ -402,10 +402,8 @@
 		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Unable to read status\n"));
 		return_VALUE(result);
 	}
-	if (!link->device->status.enabled) {
-		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Link disabled\n"));
-		return_VALUE(-ENODEV);
-	}
+	if (!link->device->status.enabled)
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Link disabled: VIA chipset? Trying to continue\n"));
 
 	/* Make sure the active IRQ is the one we requested. */
 	result = acpi_pci_link_try_get_current(link, irq);
@@ -415,11 +413,9 @@
 
 	if (link->irq.active != irq) {
 		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, 
-			"Attempt to enable at IRQ %d resulted in IRQ %d\n", 
-			irq, link->irq.active));
-		link->irq.active = 0;
-		acpi_ut_evaluate_object (link->handle, "_DIS", 0, NULL);	   
-		return_VALUE(-ENODEV);
+			"Attempt to enable at IRQ %d resulted in IRQ %d: VIA chipset? Using irq %d\n", 
+			irq, link->irq.active, irq));
+		link->irq.active = irq;
 	}
 
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Set IRQ %d\n", link->irq.active));

Tony Lindgren

author

2004-03-26 00:50 UTC #2 lore raw

Quoted 8 lines · Len Brown

I think we need to tread carefully in this area. Ignoring the result of _CRS means that we really don't know if the IRQ is programmed or not. We could attach a device to the wrong IRQ and not know it. Unclear if that risk is a better policy than pretending we confirmed that the IRQ was successfully programmed when it may not have been.

Yeah, that's what I thought too.

Quoted 4 lines

perhaps you can attach this patch to 1581 and we can work there to come up with a "disabled links patch" that makes sense for all systems. We might find that we need only a small VIA-specific tweak to an otherwise robust policy.

OK, I've attached it there. While waiting for the generic fix, I've also posted the patch to my amd64 page for m6805 and m6807 owners who might the patch handy:

http://www.muru.com/linux/amd64/

Quoted 2 lines

If your dmesg and acpidmp are different from 2090, it would be good to attach them also.

No, looks the same.

Regards,

Tony

Chris Cheney

2004-03-26 03:06 UTC #3 lore raw

In reply to Tony Lindgren

Quoted 9 lines · Tony Lindgren

Hi Andi & Len,
Sorry for cross posting all over the place, I tried to CC some people who have been bugged by this bug.
I finally got the IOAPIC working on my eMachines m6805 amd64 laptop with the following patch. I have not tried it on any other machines, so can you guys please check the sanity and make the necessary changes if needed?

Quoted 5 lines

This fixes at least ACPI bug 2090:
http://bugme.osdl.org/show_bug.cgi?id=2090
Might fix some other x86 VIA bugs too?

Is this actually a "VIA" fix or a just workaround for the broken Arima bios? I noticed that the Arima bios seems to be pretty buggy in some other aspects as well.

BTW - Does this also solve the problem with needing USB to be compiled directly into the kernel in 64bit mode?

Chris

Tony Lindgren

author

2004-03-26 03:12 UTC #4 lore raw

Quoted 5 lines · Chris Cheney

On Wed, Mar 24, 2004 at 07:34:34PM -0800, Tony Lindgren wrote:
Is this actually a "VIA" fix or a just workaround for the broken Arima bios? I noticed that the Arima bios seems to be pretty buggy in some other aspects as well.

VIA fix, not a BIOS thing.

Quoted 2 lines

BTW - Does this also solve the problem with needing USB to be compiled directly into the kernel in 64bit mode?

Hmmm, let me try, I'm recompiling right now anyways, just a sec.

Tony

Len Brown

2004-03-26 03:14 UTC #5 lore raw

Quoted 8 lines · Tony Lindgren

Quoted 5 lines · Chris Cheney
On Wed, Mar 24, 2004 at 07:34:34PM -0800, Tony Lindgren wrote:
Is this actually a "VIA" fix or a just workaround for the broken Arima bios? I noticed that the Arima bios seems to be pretty buggy in some other aspects as well.
VIA fix, not a BIOS thing.

Actually it is VIA as presented by the BIOS, so technically these disabled interrupt link devices are a BIOS bug.

-Len

Chris Cheney

2004-03-26 03:21 UTC #6 lore raw

In reply to Tony Lindgren

Quoted 8 lines · Tony Lindgren

Quoted 5 lines · Chris Cheney
On Wed, Mar 24, 2004 at 07:34:34PM -0800, Tony Lindgren wrote:
Is this actually a "VIA" fix or a just workaround for the broken Arima bios? I noticed that the Arima bios seems to be pretty buggy in some other aspects as well.
VIA fix, not a BIOS thing.

I guess I am just surprised that no one else had noticed this bug back when K8T800 first came out (April 2003) and fixed it already. :)

Thanks,
Chris

Tony Lindgren

author

2004-03-26 03:35 UTC #7 lore raw

In reply to Chris Cheney

Quoted 4 lines · Chris Cheney

On Wed, Mar 24, 2004 at 07:34:34PM -0800, Tony Lindgren wrote:
BTW - Does this also solve the problem with needing USB to be compiled directly into the kernel in 64bit mode?

OK, tried it and it does not help there. Also loding ACPI processor and thermal zone compiled in hangs the machine, but loading them as modules work. The power button still turns off the machine immedieately too with ACPI on.

So you still need to have both uchi and echi compiled. Ehci is needed for the hotplug to work properly at least on gentoo.

Regards,

Tony

Len Brown

2004-03-26 04:22 UTC #8 lore raw

Quoted 9 lines · Tony Lindgren

Quoted 4 lines · Chris Cheney
On Wed, Mar 24, 2004 at 07:34:34PM -0800, Tony Lindgren wrote:
BTW - Does this also solve the problem with needing USB to be compiled directly into the kernel in 64bit mode?
OK, tried it and it does not help there. Also loding ACPI processor and thermal zone compiled in hangs the machine, but loading them as modules work.

where does it hang when processor and thermal are compiled-in?

Quoted 2 lines

The power button still turns off the machine immedieately too with
ACPI on.

Then ACPI is not on. what does dmesg show?

Quoted 8 lines

So you still need to have both uchi and echi compiled. Ehci is needed for the hotplug to work properly at least on gentoo.
Regards,
Tony

Chris Cheney

2004-03-26 04:35 UTC #9 lore raw

Quoted 4 lines · Len Brown

Quoted 3 lines · Tony Lindgren
Quoted 2 lines · Chris Cheney
On Wed, Mar 24, 2004 at 07:34:34PM -0800, Tony Lindgren wrote:

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
BTW - Does this also solve the problem with needing USB to be compiled directly into the kernel in 64bit mode?
OK, tried it and it does not help there. Also loding ACPI processor and thermal zone compiled in hangs the machine, but loading them as modules work.
where does it hang when processor and thermal are compiled-in?

You had mentioned before there is a way to decompile SSDT with 3rd party (non iasl.exe) asl tools, do you happen to know where to get them? Also does the usual dsdt override patch (acpi.sf.net) allow you to override the ssdt or does it only work for the dsdt?

Quoted 4 lines

Quoted 2 lines
The power button still turns off the machine immedieately too with
ACPI on.
Then ACPI is not on. what does dmesg show?

This seems similiar to what I saw with my machine and mentioned in #2090, when I hit the power button just right, for lack of a better description, it would dump acpi_ev_dispatch errors, otherwise it would immediately shut off. It certainly didn't take the usual ~ 4s hold down time to shut off.

Chris

Tony Lindgren

author

2004-03-26 05:10 UTC #10 lore raw

Quoted 11 lines · Chris Cheney

Quoted 4 lines · Len Brown
Quoted 2 lines
The power button still turns off the machine immedieately too with
ACPI on.
Then ACPI is not on. what does dmesg show?
This seems similiar to what I saw with my machine and mentioned in #2090, when I hit the power button just right, for lack of a better description, it would dump acpi_ev_dispatch errors, otherwise it would immediately shut off. It certainly didn't take the usual ~ 4s hold down time to shut off.

Yeah, same here. ACPI works for the battery thogh. I've uploaded my dmesg to ACPI bug 2090 at:

http://bugme.osdl.org/show_bug.cgi?id=2090

Tony

Randy.Dunlap

2004-03-30 03:17 UTC #11 lore raw

In reply to Chris Cheney

On Thu, 25 Mar 2004 22:34:47 -0600 Chris Cheney <[email protected]> wrote:

| On Thu, Mar 25, 2004 at 11:21:51PM -0500, Len Brown wrote:
| > On Thu, 2004-03-25 at 22:35, Tony Lindgren wrote:
| > > * Chris Cheney <[email protected]> [040325 19:06]:
| > > > On Wed, Mar 24, 2004 at 07:34:34PM -0800, Tony Lindgren wrote:
| > > > 
| > > > BTW - Does this also solve the problem with needing USB to be compiled
| > > > directly into the kernel in 64bit mode?
| > > 
| > > OK, tried it and it does not help there. Also loding ACPI processor and
| > > thermal zone compiled in hangs the machine, but loading them as modules
| > > work.
| > 
| > where does it hang when processor and thermal are compiled-in?
| 
| You had mentioned before there is a way to decompile SSDT with 3rd party
| (non iasl.exe) asl tools, do you happen to know where to get them? Also
| does the usual dsdt override patch (acpi.sf.net) allow you to override
| the ssdt or does it only work for the dsdt?

There are some non-Intel ACPI (dumping) tools in CVS (acpidump and pmtools/acpi*) at this SF.net project:
https://sourceforge.net/projects/acpi/
I expect that I need to make those available as tarballs.

And Len has pmtools (and dmidecode) available here:
http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/

However, I'm not aware of any of these decompiling the SSDT...

--
~Randy

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Tony Lindgren

author

2004-03-26 05:02 UTC #12 lore raw

In reply to Len Brown

Quoted 2 lines · Len Brown

where does it hang when processor and thermal are compiled-in?

It hangs early after saying the processor supports c1 and c2 states + few more lines.

It does not hang if loading processor and thermal as modules.

Tony