diff -Nru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c Wed Feb 25 21:11:46 2004
+++ b/drivers/acpi/pci_link.c Wed Mar 24 18:47:48 2004
@@ -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,
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
On Wed, 2004-03-24 at 22:34, Tony Lindgren wrote:
> 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
> --- a/drivers/acpi/pci_link.c Wed Feb 25 21:11:46 2004
> +++ b/drivers/acpi/pci_link.c Wed Mar 24 18:47:48 2004
> @@ -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 <[email protected]> [040325 16:15]:
>
> 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.
> 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/
> If your dmesg and acpidmp are different from 2090, it would
> be good to attach them also.
No, looks the same.
Regards,
Tony
On Wed, Mar 24, 2004 at 07:34:34PM -0800, Tony Lindgren wrote:
> 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?
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
* Chris Cheney <[email protected]> [040325 19:06]:
> 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.
> 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
On Thu, 2004-03-25 at 22:11, Tony Lindgren wrote:
> * Chris Cheney <[email protected]> [040325 19:06]:
> > 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
On Thu, Mar 25, 2004 at 07:11:45PM -0800, Tony Lindgren wrote:
> * Chris Cheney <[email protected]> [040325 19:06]:
> > 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
* 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. 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
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?
> The power button still turns off the machine immedieately too with
> ACPI on.
Then ACPI is not on. what does dmesg show?
> 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
>
>
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?
> > 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
* Len Brown <[email protected]> [040325 20:22]:
>
> 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
* Chris Cheney <[email protected]> [040325 20:35]:
> On Thu, Mar 25, 2004 at 11:21:51PM -0500, Len Brown wrote:
> > > 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
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
Dear Tony:
We have done some tests as follows:
1. For original issue (bug 1530)
According to your patch for bug 2090, We rebuild SuSe 9.0 final with kernel 2.6.3 and your patch. Then, we enter "APIC" in the command line to enable APIC mode but the system still hang with bios using dynamic IRQ routing method in ASL code. So your patch can fix this issue. The original issue is detailed in bug 1530.
2. IRQ routing in SuSe OS
a. According to your patch for bug 2090, We rebuild SuSe 9.0 final with kernel 2.6.3 and your patch. Then, we enter "APIC" in the command line to enable APIC mode but the system can work with bios using static IRQ routing method in ASL code but abnormal. We get some information for your reference (bootlog and interrupts). In other words, we find the IRQ of USB is XT-PIC and IRQ5,11 but it should originally be IO-APIC and IRQ 21.
b. If we install SuSe 9.0 final with bios using static IRQ routing method in ASL code, then the system can normally work. The IRQ of USB contoller is IO-APIC and 21.
For the above, we have some questions:
1. Why is the system's IRQ routing abnormal for USB controller when rebuild SuSe 9.0 with kernel 2.6.3?
2. Is the dynamic IRQ routing method of ASL code in bios incorrect? Or does the OS's APCI praser have some problem?
If you need more information or any problem, please feel free to contact with me.
Hurry
-----Original Message-----
From: Tony Lindgren [mailto:[email protected]]
Sent: Thursday, March 25, 2004 11:35 AM
To: [email protected]
Cc: [email protected]; [email protected];
[email protected]; [email protected]; [email protected]; [email protected]
Subject: [PATCH] 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: