Regression on VIA C3 motherboard, commit: 66f2173e2

I have a via motherboard with C3 processor and some real-tek NICs.  I noticed
when using the top-of-tree that performance on it sucked (30Mbps v/s 54Mbps
network throughput in one pertinent test).

After several hours of bisecting, I see this as the culprit:

7b37b5fd9ba32c0c5afc3537eed7e7466f2173e2 is first bad commit
commit 7b37b5fd9ba32c0c5afc3537eed7e7466f2173e2
Author: Len Brown [off-list ref]
Date:   Tue Dec 23 01:47:42 2008 -0500

   ACPI: disable MPS when NO APIC-table found
  
   When ACPI is asked to find an MADT (APIC table)
   and fails, then ACPI expects to run in PIC mode.
  
   However, if an MP Table is was found, IRQs will be
   registered as if an IOAPIC is being used, even
   though ACPI is configuring interrupt links links for PIC mode.
  
   In this scenario, disable MPS so that IRQs
   are registered in PIC mode, consistent with ACPI.
  
   http://bugzilla.kernel.org/show_bug.cgi?id=12257
  
   Signed-off-by: Len Brown [off-list ref]

:040000 040000 86ce74daee3a9fe6ff21ef7f8fb364af23ec0c1e 364933dfec0df34e63b1aeff6aff4092d421886b M      arch


In addition, I see this warning in my logs, which is likely the symptom:

ACPI Exception (tbxface-0627): AE_NO_ACPI_TABLES, While loading namespace from ACPI tables ]
ACPI: Unable to load the System Description Tables
------------[ cut here ]------------
WARNING: at /home/greearb/git/linux-2.6.linus/kernel/time/clockevents.c:46 clockevent_delta)
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.28-rc9c3 #17
Call Trace:
[<c0124d9f>] warn_on_slowpath+0x5f/0x90

32 more lines

Ben Greear wrote:

I have a via motherboard with C3 processor and some real-tek NICs.  I noticed
when using the top-of-tree that performance on it sucked (30Mbps v/s 54Mbps
network throughput in one pertinent test).

After several hours of bisecting, I see this as the culprit:

7b37b5fd9ba32c0c5afc3537eed7e7466f2173e2 is first bad commit
commit 7b37b5fd9ba32c0c5afc3537eed7e7466f2173e2
Author: Len Brown [off-list ref]
Date:   Tue Dec 23 01:47:42 2008 -0500

   ACPI: disable MPS when NO APIC-table found
     When ACPI is asked to find an MADT (APIC table)
   and fails, then ACPI expects to run in PIC mode.
     However, if an MP Table is was found, IRQs will be
   registered as if an IOAPIC is being used, even
   though ACPI is configuring interrupt links links for PIC mode.
     In this scenario, disable MPS so that IRQs
   are registered in PIC mode, consistent with ACPI.
     http://bugzilla.kernel.org/show_bug.cgi?id=12257
     Signed-off-by: Len Brown [off-list ref]

:040000 040000 86ce74daee3a9fe6ff21ef7f8fb364af23ec0c1e 364933dfec0df34e63b1aeff6aff4092d421886b M      arch


In addition, I see this warning in my logs, which is likely the symptom:

ACPI Exception (tbxface-0627): AE_NO_ACPI_TABLES, While loading namespace from ACPI tables ]
ACPI: Unable to load the System Description Tables

You're getting this on boot:

ACPI Error (tbxfroot-0218): A valid RSDP was not found [20080926]

That essentially means ACPI isn't working at all, I think. Did previous kernels produce this error? Do you have ACPI disabled in the BIOS or something?

Robert Hancock wrote:

Ben Greear wrote:

quoted

I have a via motherboard with C3 processor and some real-tek NICs.  I noticed
when using the top-of-tree that performance on it sucked (30Mbps v/s 54Mbps
network throughput in one pertinent test).

After several hours of bisecting, I see this as the culprit:

7b37b5fd9ba32c0c5afc3537eed7e7466f2173e2 is first bad commit
commit 7b37b5fd9ba32c0c5afc3537eed7e7466f2173e2
Author: Len Brown [off-list ref]
Date:   Tue Dec 23 01:47:42 2008 -0500

   ACPI: disable MPS when NO APIC-table found
     When ACPI is asked to find an MADT (APIC table)
   and fails, then ACPI expects to run in PIC mode.
     However, if an MP Table is was found, IRQs will be
   registered as if an IOAPIC is being used, even
   though ACPI is configuring interrupt links links for PIC mode.
     In this scenario, disable MPS so that IRQs
   are registered in PIC mode, consistent with ACPI.
     http://bugzilla.kernel.org/show_bug.cgi?id=12257
     Signed-off-by: Len Brown [off-list ref]

:040000 040000 86ce74daee3a9fe6ff21ef7f8fb364af23ec0c1e 364933dfec0df34e63b1aeff6aff4092d421886b M      arch


In addition, I see this warning in my logs, which is likely the symptom:

ACPI Exception (tbxface-0627): AE_NO_ACPI_TABLES, While loading namespace from ACPI tables ]
ACPI: Unable to load the System Description Tables

You're getting this on boot:

ACPI Error (tbxfroot-0218): A valid RSDP was not found [20080926]

That essentially means ACPI isn't working at all, I think. Did previous kernels produce this error? Do you have ACPI disabled in the BIOS or something?

Er, yes...I have ACPI disabled in the BIOS.  I seem to recall now that it worked around
some instability, but it's been a few years since we set that up.   Still, it was working
fine before, and fine again when I comment out the change in this commit (and another
change to force the 'tsc' to be considered stable).

The same error message happens as far back as 2.6.25 at least.

Thanks,
Ben

-- 
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Ben Greear [off-list ref] Candela Technologies Inc  http://www.candelatech.com

Ben Greear wrote:

Robert Hancock wrote:

quoted

Ben Greear wrote:

quoted

I have a via motherboard with C3 processor and some real-tek NICs.  I noticed
when using the top-of-tree that performance on it sucked (30Mbps v/s 54Mbps
network throughput in one pertinent test).

After several hours of bisecting, I see this as the culprit:

7b37b5fd9ba32c0c5afc3537eed7e7466f2173e2 is first bad commit
commit 7b37b5fd9ba32c0c5afc3537eed7e7466f2173e2
Author: Len Brown [off-list ref]
Date:   Tue Dec 23 01:47:42 2008 -0500

   ACPI: disable MPS when NO APIC-table found
     When ACPI is asked to find an MADT (APIC table)
   and fails, then ACPI expects to run in PIC mode.
     However, if an MP Table is was found, IRQs will be
   registered as if an IOAPIC is being used, even
   though ACPI is configuring interrupt links links for PIC mode.
     In this scenario, disable MPS so that IRQs
   are registered in PIC mode, consistent with ACPI.
     http://bugzilla.kernel.org/show_bug.cgi?id=12257
     Signed-off-by: Len Brown [off-list ref]

:040000 040000 86ce74daee3a9fe6ff21ef7f8fb364af23ec0c1e 364933dfec0df34e63b1aeff6aff4092d421886b M      arch


In addition, I see this warning in my logs, which is likely the symptom:

ACPI Exception (tbxface-0627): AE_NO_ACPI_TABLES, While loading namespace from ACPI tables ]
ACPI: Unable to load the System Description Tables

You're getting this on boot:

ACPI Error (tbxfroot-0218): A valid RSDP was not found [20080926]

That essentially means ACPI isn't working at all, I think. Did previous kernels produce this error? Do you have ACPI disabled in the BIOS or something?

Er, yes...I have ACPI disabled in the BIOS.  I seem to recall now that it worked around
some instability, but it's been a few years since we set that up.   Still, it was working

4 more quoted lines

It seems like this is a slightly different case than the patch is trying to address. It's talking about just the MADT not being found, when in your case we have no ACPI at all.

However, I should point out that in general, disabling ACPI tends to be a bad idea, since it tends to bring out untested code paths both in the kernel and in the BIOS/hardware. (For one thing it means you can't use the PM timer, which is likely why your system is falling back to jiffies timing.)

Thanks for the bisect, Ben.

Please test the patch below.

I assume even without the patch, booting with "acpi=off" on your
BIOS-ACPI-disabled box works?  (if no, this patch will not solve
all your problems, for you have additional trouble elsewhere)

I am curious why you're running a CONFIG_ACPI=y kernel
for a box with ACPI disabled. (though yes, it is supposed to work)

I'm even more curious what bad things happen when
you enable ACPI in the BIOS -- can you let me know
and we can try to fix them so the machine can run as shipped?

thanks,
-Len Brown
Intel Open Source Technology Center

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 775c97a..a885295 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c

@@ -293,7 +293,12 @@ static void __init check_multiple_madt(void)
 
 int __init acpi_table_init(void)
 {
-	acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, 0);
+	acpi_status status;
+
+	status = acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, 0);
+	if (ACPI_FAILURE(status))
+		return 1;
+
 	check_multiple_madt();
 	return 0;
 }

Len Brown wrote:

Thanks for the bisect, Ben.

Please test the patch below.

I assume even without the patch, booting with "acpi=off" on your
BIOS-ACPI-disabled box works?  (if no, this patch will not solve
all your problems, for you have additional trouble elsewhere)

I am curious why you're running a CONFIG_ACPI=y kernel
for a box with ACPI disabled. (though yes, it is supposed to work)

I'm even more curious what bad things happen when
you enable ACPI in the BIOS -- can you let me know
and we can try to fix them so the machine can run as shipped?

At one time, these boxes would actually burn out their power
supply if you did an 'init 0' with the BIOS configured to
shut down the system.  It would just suck more and more power
(we measured) until the brick smoked, and the motherboard components
got very hot as well.  I think we were just lucky that the PS died
before the MB did.

This was a while back, but I believe part of the fix was to disable
ACPI so the system couldn't possibly try to power itself down
in this manner.

I will try your patch, but I'm about to go off for a ~2week vacation,
so I probably won't have time to test enabling ACPI and/or compiling
a kernel w/out it to see what shakes out.

I re-worked my previous patch per Ingo's suggestion and am
about to send it off..but please feel free to NAK it if you
think it's wrong.  I don't really know enough about this area
to argue one way or another.

Thanks,
Ben

-- 
Ben Greear [off-list ref]
Candela Technologies Inc  http://www.candelatech.com

Len Brown wrote:

Thanks for the bisect, Ben.

Please test the patch below.

With this patch, performance is fine, and I do not see
my smp hack being exercised.  I still have ACPI off
in the BIOS, and on in the kernel (ie, no change
from the original test case).

So, this very well could be the fix.

Thanks,
Ben

-- 
Ben Greear [off-list ref]
Candela Technologies Inc  http://www.candelatech.com