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] [day] [month] [year] [list]

Date:	Fri, 4 Jul 2008 21:45:29 +0000
From:	"Justin Mattock" <justinmattock@...il.com>
To:	"Alexey Starikovskiy" <aystarik@...il.com>
Cc:	"Matthew Garrett" <mjg59@...f.ucam.org>,
	"Eduard - Gabriel Munteanu" <eduard.munteanu@...ux360.ro>,
	"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 Fri, Jul 4, 2008 at 4:23 PM, Justin Mattock <justinmattock@...il.com> wrote:
> On Fri, Jul 4, 2008 at 11:32 AM, Alexey Starikovskiy <aystarik@...il.com> wrote:
>> Justin Mattock wrote:
>>>
>>> On Wed, Jul 2, 2008 at 4:35 PM, Matthew Garrett <mjg59@...f.ucam.org>
>>> wrote:
>>>
>>>>
>>>> On Wed, Jul 02, 2008 at 04:30:11PM +0000, Justin Mattock wrote:
>>>>
>>>>
>>>>>
>>>>> Hello; what info is supplied with EFI i.g. I'm using a macbook pro.
>>>>> After looking at:
>>>>> http://acpi.sourceforge.net/dsdt/view.php I was unable to locate
>>>>> anything with apple, or at least
>>>>> couldn't find the manufacture number.
>>>>> If somebody has already done this, I was wondering if it would be O.K.
>>>>> if I can attached my dsdt.dsl with the errors,
>>>>> and my explanation of what I changed, just so If I did something
>>>>> completely wrong
>>>>>
>>>>
>>>> iasl will complain about code that the Linux interpreter will happily
>>>> accept. If the only reason you've made changes is that iasl complains,
>>>> then it's unlikely that there's any functional difference as a result.
>>>> Otherwise, work out which changes fix which Linux bugs and file a bug
>>>> at bugzilla.kernel.org against acpi.
>>>>
>>>> --
>>>> Matthew Garrett | mjg59@...f.ucam.org
>>>>
>>>>
>>>
>>> Hello; I modified dsdt because iasl was complaining, As a result like
>>> what you said
>>> "then it's unlikely that there's any functional difference as a
>>> result" is probably
>>> what I'm seeing. As for a bug report I already have one filed. As to
>>> why I'm messing with
>>> the dsdt, just trying to isolate the problem with the bug I have
>>> already filed., or at least
>>> get a better idea of what is happening. Anyways thanks for the info.
>>> regards;
>>>
>>>
>>
>> For difference, you should look for "Darwin", this is how MacOS X identifies
>> itself to hardware.
>>
>>
>> Regards,
>> Alex.
>>
>
> Hello;
> So adding acpi_osi=Darwin will work for boot parameter. Also I wanted
> to apologize If I pissed you off,
> I didn't quite understand what was really happening, and now after
> looking into the scenario, I think I need to find out
> what is going on with my GPE's, this way you're detector(ec.c) won't
> be going off so frequently.
> regards;
>
> --
> Justin P. Mattock
>

Hmm I like this option(never new it existed), the only problem I'm seeing right
now is no battery info in /proc/acpi, "but there is no gpe storm which
makes me happy".
After searching I'm looking at the same as this:
http://lists.opensuse.org/opensuse-bugs/2007-08/msg09525.html
Overall the outcome of using sbs is bad with the Darwin option, system
sticks after loading
the module during boot. even under different proceedures
i.g. with
sbs=only (no a/c and battery modules)
sbs+ac(module)
sbs+ac+battery(modules)

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/