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]
Message-ID: <dd18b0c30807131353l3608ab5l248ae799994cc58d@mail.gmail.com>
Date:	Sun, 13 Jul 2008 20:53:49 +0000
From:	"Justin Mattock" <justinmattock@...il.com>
To:	"Hugh Dickins" <hugh@...itas.com>
Cc:	"Vegard Nossum" <vegard.nossum@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Kernel Testers List" <kernel-testers@...r.kernel.org>,
	"Alexey Starikovskiy" <astarikovskiy@...e.de>
Subject: Re: [Bug #10724] ACPI: EC: GPE storm detected, disabling EC GPE

On Sun, Jul 13, 2008 at 8:27 PM, Hugh Dickins <hugh@...itas.com> wrote:
> On Sun, 13 Jul 2008, Vegard Nossum wrote:
>> On Sun, Jul 13, 2008 at 9:34 PM, Justin Mattock <justinmattock@...il.com> wrote:
>> > On Sun, Jul 13, 2008 at 6:00 PM, Rafael J. Wysocki <rjw@...k.pl> wrote:
>> >> This message has been generated automatically as a part of a report
>> >> of recent regressions.
>> >>
>> >> The following bug entry is on the current list of known regressions
>> >> from 2.6.25.  Please verify if it still should be listed.
>> >>
>> >>
>> >> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=10724
>> >> Subject         : ACPI: EC: GPE storm detected, disabling EC GPE
>> >> Submitter       : Justin Mattock <justinmattock@...il.com>
>> >> Date            : 2008-05-16 6:17 (59 days old)
>> >> References      : http://marc.info/?l=linux-kernel&m=121091875711824&w=4
>> >>                  http://lkml.org/lkml/2008/5/18/168
>> >>                  http://lkml.org/lkml/2008/5/25/195
>> >> Patch           : http://bugzilla.kernel.org/attachment.cgi?id=16364&action=view
>> >>                  http://bugzilla.kernel.org/attachment.cgi?id=16365&action=view
>>
>> I didn't follow the discussion, but I may contribute the following information:
>>
>> This message first appears in my logs on May 16. That was with kernel
>> version 2.6.24.5-85.fc8. The kernel I used before that was
>> 2.6.24.4-64.fc8 (May 3). My logs go back to November 8
>> (2.6.23.1-42.fc8). So we can hardly consider this a regression since
>> 2.6.25, but rather one since 2.6.24?
>>
>> (I'll also note that this message appears quite infrequently here.
>> Only 42 times in 219 boot-ups. So it would be hard to bisect, but I'm
>> guessing the error was introduced somewhere between 2.6.24.4 and
>> 2.6.24.5.)
>
> You're comparing against Fedora kernels, which often contain
> patches which haven't got into mainline yet.  As in this case.
> Unless it used to be assembled from separate pieces, there was
> no "GPE storm detected" message in 2.6.24.N or 2.6.25.N: it was
> added in 2.6.26-rc1.
>
> I sometimes see it too, on a Fujitsu-Siemens laptop.
>
> Hugh
>

Hello;
What I've been using is acpi_osi=Darwin so I don't have to take the
gpe storm detector mechanism out of ec.c
The two areas of interest are when not setting a boot option this
message is triggered by too many
interrupts with BAT0 i.g. /sys/firmware/acpi/interrupts "gpe17 on a
macbook2,2",
Now when using the Darwin option, the interrupts are very little, but
at the cost of loosing any battery info
but I am receiving a reaction with pommed i.g. unplugging the A/C
adapter does dim the screen.
Also I'm not sure if the smart battery was designed for the macbook,
but when using Darwin option, my system will
freeze upon booting(as a note alexy gave me some patches to test on
monday, but still was unable to load the module)
overall from my perspective; trying to tweak the BAT0 mechanism with
it's interrupts could fix this, and/or
port the sbs module to be used with the Darwin option with interrupts
under control, could also be another option,
or have all two working this way the user can decide what they prefferer.
 Personally tweaking the interrupts with BAT0 seems to be more of an
easier solution,
but then again could cause other problems elsewhere.

-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ