linux-kernel - Re: dsdt buggy acpi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 2 Jul 2008 06:16:15 +0000
From:	"Justin Mattock" <justinmattock@...il.com>
To:	"Eduard - Gabriel Munteanu" <eduard.munteanu@...ux360.ro>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"ACPI Devel Maling List" <linux-acpi@...r.kernel.org>
Subject: Re: dsdt buggy acpi

On Wed, Jul 2, 2008 at 5:25 AM, Eduard - Gabriel Munteanu
<eduard.munteanu@...ux360.ro> wrote:
> On Tue, 1 Jul 2008 16:18:45 +0000
> "Justin Mattock" <justinmattock@...il.com> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/