On Wed, Jul 2, 2008 at 5:25 AM, Eduard - Gabriel Munteanu <eduard.munteanu@xxxxxxxxxxx> wrote: > On Tue, 1 Jul 2008 16:18:45 +0000 > "Justin Mattock" <justinmattock@xxxxxxxxx> wrote: > >> Cool; thanks. >> I'll check that out and see where and how I can locate the dsdt >> manufacture number, then see if I can fix the broken dsdt error and >> apply this to the kernel and see what happens. >> regards; > > Just one note here: DSDTs have nothing to do with the kernel. This is > just broken firmware. The most one can do _in-kernel_ is blacklist some > functionality or create a workaround, but this only happens for widely > used stuff. Broken DSDTs aren't widely used stuff, they are written by > the machine's vendor (the laptop's manufacturer for example, but this > could be different for desktops) and differ a lot from one machine to > another. > > > Eduard > Cool, thanks for the info, As of right now I'm mainly trying to clean up as much acpi errors that I can find in my system, in hopes leading me to more info on fixing a bug(or someone else).: http://bugzilla.kernel.org/show_bug.cgi?id=10724 For right now I have cleaned up all of the errors and warning from the dsdt.dsl and have plugged in the new dsdt.hex into the kernel.(everything seems O.K)., except for two messages I received from running iasl i.g. I've google but found not very many results for this No back ptr to Op: type 8 No back ptr to Op: type 8 After contemplating I decided to go ahead with the modified dsdt irregardless of the: No back ptr to Op: type 8 message, but to my dismay I'm still receiving the BUG. "gripes" on a positive not creating a custom dsdt and loading it into the kernel is "cake", figuring out how to fix the dsdt is a "bi*^h"; anyways If you or anybody knows what this means, please send a message. regards; -- Justin P. Mattock -- 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
