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