[PATCH] x86_64 VIA chipset IOAPIC fix

[PATCH] x86_64 VIA chipset IOAPIC fix

[Tony Lindgren]

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

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:


[-- Attachment #2: patch-amd64-via-ioapic --]
[-- Type: text/plain, Size: 1170 bytes --]

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));

Re: [PATCH] x86_64 VIA chipset IOAPIC fix

[Len Brown]

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));

Re: [PATCH] x86_64 VIA chipset IOAPIC fix

[Tony Lindgren]

* Len Brown <len.brown@intel.com> [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

Re: [PATCH] x86_64 VIA chipset IOAPIC fix

[Chris Cheney]

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

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

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

Re: [PATCH] x86_64 VIA chipset IOAPIC fix

[Tony Lindgren]

* Chris Cheney <ccheney@cheney.cx> [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

Re: [PATCH] x86_64 VIA chipset IOAPIC fix

[Len Brown]

On Thu, 2004-03-25 at 22:11, Tony Lindgren wrote:
> * Chris Cheney <ccheney@cheney.cx> [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

Re: [PATCH] x86_64 VIA chipset IOAPIC fix

[Chris Cheney]

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

On Thu, Mar 25, 2004 at 07:11:45PM -0800, Tony Lindgren wrote:
> * Chris Cheney <ccheney@cheney.cx> [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

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

Re: [PATCH] x86_64 VIA chipset IOAPIC fix

[Tony Lindgren]

* Chris Cheney <ccheney@cheney.cx> [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

Re: [PATCH] x86_64 VIA chipset IOAPIC fix

[Len Brown]

On Thu, 2004-03-25 at 22:35, Tony Lindgren wrote:
> * Chris Cheney <ccheney@cheney.cx> [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
> 
> 

Re: [PATCH] x86_64 VIA chipset IOAPIC fix

[Chris Cheney]

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

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 <ccheney@cheney.cx> [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

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

Re: [PATCH] x86_64 VIA chipset IOAPIC fix

[Tony Lindgren]

* Chris Cheney <ccheney@cheney.cx> [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

Re: [PATCH] x86_64 VIA chipset IOAPIC fix

[Randy.Dunlap]

On Thu, 25 Mar 2004 22:34:47 -0600 Chris Cheney <ccheney@cheney.cx> 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 <ccheney@cheney.cx> [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

Re: [PATCH] x86_64 VIA chipset IOAPIC fix

[Tony Lindgren]

* Len Brown <len.brown@intel.com> [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

RE: [PATCH] x86_64 VIA chipset IOAPIC fix

[HurryLin]

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

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:tony@atomide.com]
Sent: Thursday, March 25, 2004 11:35 AM
To: linux-kernel@vger.kernel.org
Cc: acpi-devel-request@lists.sourceforge.net; patches@x86-64.org;
ak@suse.de; len.brown@intel.com; pavel@ucw.cz; ccheney@debian.org
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:


[-- Attachment #2: bootlog --]
[-- Type: application/octet-stream, Size: 15390 bytes --]

C physical APIC ID to 2 ... ok.
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-5, 2-11, 2-17, 2-18, 2-19 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 23.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.... register #01: 00178003
.......     : max redirection entries: 0017
.......     : PRQ implemented: 1
.......     : IO APIC version: 0003
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 001 01  0    0    0   0   0    1    1    39
 02 001 01  0    0    0   0   0    1    1    31
 03 001 01  0    0    0   0   0    1    1    41
 04 001 01  0    0    0   0   0    1    1    49
 05 000 00  1    0    0   0   0    0    0    00
 06 001 01  0    0    0   0   0    1    1    51
 07 001 01  0    0    0   0   0    1    1    59
 08 001 01  0    0    0   0   0    1    1    61
 09 001 01  0    0    0   0   0    1    1    69
 0a 001 01  0    0    0   0   0    1    1    71
 0b 000 00  1    0    0   0   0    0    0    00
 0c 001 01  0    0    0   0   0    1    1    79
 0d 001 01  0    0    0   0   0    1    1    81
 0e 001 01  0    0    0   0   0    1    1    89
 0f 001 01  0    0    0   0   0    1    1    91
 10 001 01  1    1    0   1   0    1    1    99
 11 000 00  1    0    0   0   0    0    0    00
 12 000 00  1    0    0   0   0    0    0    00
 13 000 00  1    0    0   0   0    0    0    00
 14 001 01  1    1    0   1   0    1    1    A1
 15 001 01  1    1    0   1   0    1    1    A9
 16 001 01  1    1    0   1   0    1    1    B1
 17 001 01  1    1    0   1   0    1    1    B9
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ20 -> 0:20
IRQ21 -> 0:21
IRQ22 -> 0:22
IRQ23 -> 0:23
.................................... done.
Using local APIC timer interrupts.
Detected 12.529 MHz APIC timer.
NET: Registered protocol family 16
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040116
 tbxface-0117 [03] acpi_load_tables      : ACPI Tables successfully acquired
Parsing all Control Methods:..................................................................................................................................................................................
Table [DSDT](id F004) - 635 Objects with 60 Devices 178 Methods 30 Regions
ACPI Namespace successfully loaded at root ffffffff805dbea0
ACPI: IRQ9 SCI: Level Trigger.
evxfevnt-0093 [04] acpi_enable           : Transition to ACPI mode successful
evgpeblk-0747 [06] ev_create_gpe_block   : GPE 00 to 15 [_GPE] 2 regs at 0000000000004020 on int 9
Completing Region/Field/Buffer/Package initialization:............................................................................................
Initialized 30/30 Regions 19/19 Fields 21/21 Buffers 22/22 Packages (643 nodes)
Executing all Device _STA and_INI methods:........................................................
56 Devices found containing: 56 _STA, 1 _INI methods
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 10 11 12)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 6 7 10 *11 12)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 *11 12)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 11 12)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 7 10 11 12)
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 6 7 10 11 12)
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 6 7 10 11 12)
ACPI: PCI Interrupt Link [ALKA] (IRQs 20)
ACPI: PCI Interrupt Link [ALKB] (IRQs 23)
ACPI: PCI Interrupt Link [ALKC] (IRQs 22)
ACPI: PCI Interrupt Link [ALKD] (IRQs 21)
SCSI subsystem initialized
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 5
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=398.00 Mhz, System=297.00 MHz
radeonfb: Monitor 1 type CRT found
radeonfb: Monitor 2 type no found
radeonfb: ATI Radeon AP  SDR SGRAM 128 MB
IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
ikconfig 0.7 with /proc/config*
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.6 [Flags: R/W DEBUG].
SGI XFS with realtime, large block/inode numbers, no debug enabled
ACPI: Power Button (FF) [PWRF]
ACPI: Processor [CPU0] (supports C1)
pty: 256 Unix98 ptys configured
Real Time Clock Driver v1.12
Hangcheck: starting hangcheck timer 0.5.0 (tick is 180 seconds, margin is 60 seconds).
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Using anticipatory io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
via-rhine.c:v1.10-LK1.1.19-2.5  July-12-2003  Written by Donald Becker
  http://www.scyld.com/network/via-rhine.html
eth0: VIA VT6102 Rhine-II at 0xe400, 00:08:25:6e:00:74, IRQ 5.
eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1.
eth0: MII PHY found at address 2, status 0xc000 advertising 0000 Link c000.
eth0: MII PHY found at address 3, status 0xc000 advertising 0000 Link c000.
eth0: MII PHY found at address 4, status 0xc000 advertising 0000 Link c000.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:0f.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
    ide0: BM-DMA at 0xc800-0xc807, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xc808-0xc80f, BIOS settings: hdc:pio, hdd:DMA
hda: QUANTUM FIREBALLP AS40.0, ATA DISK drive
hdb: Maxtor 6E030L0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdd: ATAPI DVD-ROM 16XMax, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 78177792 sectors (40027 MB) w/1902KiB Cache, CHS=65535/16/63, UDMA(100)
 hda: hda1 hda2
hdb: max request size: 128KiB
hdb: 60058656 sectors (30750 MB) w/2048KiB Cache, CHS=59582/16/63, UDMA(133)
 hdb: hdb1 hdb2
hdd: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
Fusion MPT base driver 3.00.02
Copyright (c) 1999-2003 LSI Logic Corporation
Fusion MPT SCSI Host driver 3.00.02
mice: PS/2 mouse device common for all mice
serio: i8042 AUX port at 0x60,0x64 irq 12
input: ImExPS/2 Generic Explorer Mouse on isa0060/serio1
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard on isa0060/serio0
Intel 810 + AC97 Audio, version 0.24, 12:23:45 Apr 13 2004
oprofile: using NMI interrupt.
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 32768)
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
ACPI: (supports S0 S3 S4 S5)
RAMDISK: Compressed image found at block 0
RAMDISK: incomplete write (-28 != 17408) 4194304
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 192k freed
EXT3 FS on hda1, internal journal
Adding 2048276k swap on /dev/hda2.  Priority:42 extents:1
EXT3 FS on hda1, internal journal
eth0: no IPv6 routers present
ehci_hcd: block sizes: qh 160 qtd 96 itd 192 sitd 96
ehci_hcd 0000:00:10.4: EHCI Host Controller
ehci_hcd 0000:00:10.4: reset hcs_params 0x4208 dbg=0 cc=4 pcc=2 ordered !ppc ports=8
ehci_hcd 0000:00:10.4: reset hcc_params 6872 thresh 7 uframes 256/512/1024
ehci_hcd 0000:00:10.4: capability 0001 at 68
ehci_hcd 0000:00:10.4: irq 11, pci mem ffffff000117b000
ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:10.4: reset command 080002 (park)=0 ithresh=8 period=1024 Reset HALT
ehci_hcd 0000:00:10.4: init command 010009 (park)=0 ithresh=1 period=256 RUN
ehci_hcd 0000:00:10.4: USB 2.0 enabled, EHCI 1.00, driver 2003-Dec-29
ehci_hcd 0000:00:10.4: root hub device address 1
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
drivers/usb/core/message.c: USB device number 1 default language ID 0x409
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.3 ehci_hcd
usb usb1: SerialNumber: 0000:00:10.4
usb usb1: registering 1-0:1.0 (config #1, interface 0)
hub 1-0:1.0: usb_probe_interface
hub 1-0:1.0: usb_probe_interface - got id
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
hub 1-0:1.0: standalone hub
hub 1-0:1.0: ganged power switching
hub 1-0:1.0: individual port over-current protection
hub 1-0:1.0: Single TT
hub 1-0:1.0: TT requires at most 8 FS bit times
hub 1-0:1.0: Port indicators are not supported
hub 1-0:1.0: power on to power good time: 20ms
hub 1-0:1.0: hub controller current requirement: 0mA
hub 1-0:1.0: local power source is good
hub 1-0:1.0: no over-current condition exists
hub 1-0:1.0: enabling power on all ports
drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.1
uhci_hcd 0000:00:10.0: UHCI Host Controller
uhci_hcd 0000:00:10.0: irq 5, io base 000000000000cc00
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 2
drivers/usb/host/uhci-hcd.c: detected 2 ports
uhci_hcd 0000:00:10.0: root hub device address 1
usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
drivers/usb/core/message.c: USB device number 1 default language ID 0x409
usb usb2: Product: UHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.3 uhci_hcd
usb usb2: SerialNumber: 0000:00:10.0
usb usb2: registering 2-0:1.0 (config #1, interface 0)
hub 2-0:1.0: usb_probe_interface
hub 2-0:1.0: usb_probe_interface - got id
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
hub 2-0:1.0: standalone hub
hub 2-0:1.0: ganged power switching
hub 2-0:1.0: global over-current protection
hub 2-0:1.0: Port indicators are not supported
hub 2-0:1.0: power on to power good time: 2ms
hub 2-0:1.0: hub controller current requirement: 0mA
hub 2-0:1.0: local power source is good
hub 2-0:1.0: no over-current condition exists
hub 2-0:1.0: enabling power on all ports
uhci_hcd 0000:00:10.1: UHCI Host Controller
uhci_hcd 0000:00:10.1: irq 5, io base 000000000000d000
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 3
drivers/usb/host/uhci-hcd.c: detected 2 ports
uhci_hcd 0000:00:10.1: root hub device address 1
usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1
drivers/usb/core/message.c: USB device number 1 default language ID 0x409
usb usb3: Product: UHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.3 uhci_hcd
usb usb3: SerialNumber: 0000:00:10.1
usb usb3: registering 3-0:1.0 (config #1, interface 0)
hub 3-0:1.0: usb_probe_interface
hub 3-0:1.0: usb_probe_interface - got id
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
hub 3-0:1.0: standalone hub
hub 3-0:1.0: ganged power switching
hub 3-0:1.0: global over-current protection
hub 3-0:1.0: Port indicators are not supported
hub 3-0:1.0: power on to power good time: 2ms
hub 3-0:1.0: hub controller current requirement: 0mA
hub 3-0:1.0: local power source is good
hub 3-0:1.0: no over-current condition exists
hub 3-0:1.0: enabling power on all ports
uhci_hcd 0000:00:10.2: UHCI Host Controller
uhci_hcd 0000:00:10.2: irq 11, io base 000000000000d400
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 4
drivers/usb/host/uhci-hcd.c: detected 2 ports
uhci_hcd 0000:00:10.2: root hub device address 1
usb usb4: new device strings: Mfr=3, Product=2, SerialNumber=1
drivers/usb/core/message.c: USB device number 1 default language ID 0x409
usb usb4: Product: UHCI Host Controller
usb usb4: Manufacturer: Linux 2.6.3 uhci_hcd
usb usb4: SerialNumber: 0000:00:10.2
usb usb4: registering 4-0:1.0 (config #1, interface 0)
hub 4-0:1.0: usb_probe_interface
hub 4-0:1.0: usb_probe_interface - got id
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
hub 4-0:1.0: standalone hub
hub 4-0:1.0: ganged power switching
hub 4-0:1.0: global over-current protection
hub 4-0:1.0: Port indicators are not supported
hub 4-0:1.0: power on to power good time: 2ms
hub 4-0:1.0: hub controller current requirement: 0mA
hub 4-0:1.0: local power source is good
hub 4-0:1.0: no over-current condition exists
hub 4-0:1.0: enabling power on all ports
uhci_hcd 0000:00:10.3: UHCI Host Controller
uhci_hcd 0000:00:10.3: irq 11, io base 000000000000d800
uhci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 5
drivers/usb/host/uhci-hcd.c: detected 2 ports
uhci_hcd 0000:00:10.3: root hub device address 1
usb usb5: new device strings: Mfr=3, Product=2, SerialNumber=1
drivers/usb/core/message.c: USB device number 1 default language ID 0x409
usb usb5: Product: UHCI Host Controller
usb usb5: Manufacturer: Linux 2.6.3 uhci_hcd
usb usb5: SerialNumber: 0000:00:10.3
usb usb5: registering 5-0:1.0 (config #1, interface 0)
hub 5-0:1.0: usb_probe_interface
hub 5-0:1.0: usb_probe_interface - got id
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
hub 5-0:1.0: standalone hub
hub 5-0:1.0: ganged power switching
hub 5-0:1.0: global over-current protection
hub 5-0:1.0: Port indicators are not supported
hub 5-0:1.0: power on to power good time: 2ms
hub 5-0:1.0: hub controller current requirement: 0mA
hub 5-0:1.0: local power source is good
hub 5-0:1.0: no over-current condition exists
hub 5-0:1.0: enabling power on all ports
hub 2-0:1.0: port 1, status 100, change 3, 12 Mb/s
hub 2-0:1.0: port 2, status 100, change 3, 12 Mb/s
hub 3-0:1.0: port 1, status 100, change 3, 12 Mb/s
hub 3-0:1.0: port 2, status 300, change 3, 1.5 Mb/s
hub 4-0:1.0: port 1, status 100, change 3, 12 Mb/s
hub 4-0:1.0: port 2, status 300, change 3, 1.5 Mb/s
hub 5-0:1.0: port 1, status 300, change 3, 1.5 Mb/s
hub 5-0:1.0: port 2, status 100, change 3, 12 Mb/s
hub 2-0:1.0: port 1 enable change, status 100
hub 2-0:1.0: port 2 enable change, status 100
hub 3-0:1.0: port 1 enable change, status 100
hub 3-0:1.0: port 2 enable change, status 300
hub 4-0:1.0: port 1 enable change, status 100
hub 4-0:1.0: port 2 enable change, status 300
hub 5-0:1.0: port 1 enable change, status 300
hub 5-0:1.0: port 2 enable change, status 100
drivers/usb/host/uhci-hcd.c: cc00: suspend_hc
drivers/usb/host/uhci-hcd.c: d000: suspend_hc
drivers/usb/host/uhci-hcd.c: d400: suspend_hc
drivers/usb/host/uhci-hcd.c: d800: suspend_hc
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timed out, status 0003, PHY status 786d, resetting...

[-- Attachment #3: interrupts --]
[-- Type: application/octet-stream, Size: 518 bytes --]

           CPU0       
  0:  158937133    IO-APIC-edge  timer
  1:        504    IO-APIC-edge  i8042
  2:          0          XT-PIC  cascade
  5:          0          XT-PIC  eth0, uhci_hcd, uhci_hcd
  8:          0    IO-APIC-edge  rtc
  9:          0    IO-APIC-edge  acpi
 11:          0          XT-PIC  ehci_hcd, uhci_hcd, uhci_hcd
 12:       8639    IO-APIC-edge  i8042
 14:      99363    IO-APIC-edge  ide0
 15:       1283    IO-APIC-edge  ide1
NMI:       2455 
LOC:  158917111 
ERR:          0
MIS:          0