Jordan and I are going to take this up with theo during the hackathon.
I am not sure I like having a gaping hole in the kernel but maybe we can
do something before securelevel. I like it from a hacking perspective
though.
On Tue, May 11, 2010 at 06:27:20PM +0200, Stefan Unterweger wrote:
> * Stefan Unterweger on Tue, May 04, 2010 at 12:43:22AM +0200:
> > As far as I understood from some ancient [FreeBSD] mailinglist
> > threads, in theory it should be possible to somehow do
> > something such that the kernel loads patched ACPI tables which
> > have those particular bugs corrected.
>
> Finally I've found that particular post again, and have been able
> to fix the broken DSDT to some extent. With some dirty patchwork
> acpi_load_dsdt now loads my custom table, and `shutdown -p -h`
> succeeds in turning off the machine, without any more warnings.
>
> A few questions'd remain, though:
>
> - I don't suppose that there would be some "official" point in
> the ACPI driver where such workarounds would "belong"? The code
> looks clear enough to me, but I "speak" neither enough C nor
> ACPI to be sure...
>
> - The patch seems almost too easy to me, but I'm not yet made
> that much progress in learning C. With all that memcpy going
> around, I have the uneasy feeling that I might be introducing
> some nasty memory holes...
>
> The patch is against 4.6-release, since that's the version I was
> planning to put on the machine.
>
>
> Regards,
> s//un
>
>
>
> --- acpi.c.orig Tue May 11 18:07:10 2010
> +++ acpi.c Tue May 11 17:59:56 2010
> @@ -48,6 +48,8 @@
> #define APMDEV_NORMAL 0
> #define APMDEV_CTL 8
>
> +#include "custom_dsdt.h"
> +
> #ifdef ACPI_DEBUG
> int acpi_debug = 16;
> #endif
> @@ -889,6 +891,11 @@
> }
> memcpy((*dsdt)->q_data, handle.va, len);
> (*dsdt)->q_table = (*dsdt)->q_data;
> +
> + /* 5AEb+sk: Override the Tyan Tiger S2466's corrupt DSDT */
> + printf("Trying to override broken DSDT table...\n");
> + (*dsdt)->q_table = (struct acpi_table_header *)AmlCode;
> +
> acpi_unmap(&handle);
> }
> }