On Wednesday, January 23, 2013 08:29:02 AM Lv Zheng wrote:
> There is automatic return object repair mechanism implemented in
> ACPICA which can not handle all of the issues exposed by BIOS
> currently. This patch allow a kernel boots up without such
> workarounds enabled. A better choice should refine the repair
> mechanism to allow more robust evaluation result.
>
> Signed-off-by: Lv Zheng <lv.zheng@xxxxxxxxx>
> ---
> drivers/acpi/bus.c | 12 ++++++++++++
drivers/acpi/osl.c would IMO make more sense to add this, there
is no __setup function in bus.c yet, but in osl.c there is:
__setup("acpi_serialize", acpi_serialize_setup);
doing more or less the same.
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 01708a1..e33577f 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -805,6 +805,18 @@ static int __init acpi_bus_init(void)
> struct kobject *acpi_kobj;
> EXPORT_SYMBOL_GPL(acpi_kobj);
>
> +static int __init acpi_disable_repair(char *s)
> +{
> + printk(KERN_NOTICE PREFIX
pr_notice()
No need to change other printk(KERN_NOTICE..., but new patches
should make use of pr_notice.
Are there known error messages that indicate when it makes sense
to try this out?
How would I know I should try this boot param?
If there are hints when to use this, it makes sense to mention them at
least in the changelog (or a bug reference or similar).
kernel parameters are typically described in
Documentation/kernel-parameters.txt
Not sure whether it's worth for this one (if it's intended for low level
ACPI debugging only and people making use of it know the drivers/acpi/*
code and therefore know about this option it may not).
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
