Regression on VIA C3 motherboard, commit: 66f2173e2

Commit Message

Len Brown Feb. 6, 2009, 6:57 p.m. UTC

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

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Ben Greear Feb. 6, 2009, 7:20 p.m. UTC | #1

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 Feb. 6, 2009, 7:52 p.m. UTC | #2

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

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

Patch

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