public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
To: Alexey Starikovskiy <astarikovskiy@suse.de>
Cc: linux acpi <linux-acpi@vger.kernel.org>
Subject: Re: ACPI: EC: Fix logspam in "GPE storm avoidance" code
Date: Tue, 28 Oct 2008 20:18:07 +0000	[thread overview]
Message-ID: <4907737F.6060507@tuffmail.co.uk> (raw)
In-Reply-To: <4907590E.4070104@suse.de>

Alexey Starikovskiy wrote:
> Alan Jenkins wrote:
>> <http://bugzilla.kernel.org/show_bug.cgi?id=11841>
>> "plenty of line "ACPI: EC: non-query interrupt received,
>>  switching to interrupt mode" in dmesg"
> Probably, it is better to make pr_debug().

Yes, it seems useful to have when all the DEBUG output is enabled.

In that case, the initial message about starting in poll mode should 
also be switched to pr_debug().  Otherwise, the change will give the 
impression that the EC never switches to interrupt mode.

That just leaves the message "missing confirmations, switching to 
polling mode".  That should only happen once per boot, or after a 
suspend/resume cycle, right?  Because it sets NO_GPE, which inhibits 
GPE_MODE and is only reset on resume.  So that can be preserved, and 
it's probably a useful message to have.

I'll leave it to you to submit a more appropriate patch.

>>
>> GPE storm avoidance involves disabling the EC GPE during transactions.
>> Unfortunately we forget to re-enable EC_FLAGS_GPE_MODE afterwards.
> "We" don't forget it, "we" just use same mechanism as driver init. 
> Thus if
> for some reason interrupts do not start to arrive after we issue 
> enable_gpe(),
> we will not fall to timeouts.

Interesting.  I agree that sort of caution is meritted for the EC 
driver!  If that's by design, then great.

I will have a look at the code again for my own peace of mind; I thought 
I understood the GPE storm avoidance but now I'm a bit fuzzy on the 
details.  We apologize for the overuse of the third person.  After 
staring at the code for so long I have to identify with it to some 
extent, despite not having actually written any of it.

>>
>> This happens to work because we re-enable it anyway when we detect
>> the first confirmation interrupt of the next transaction.  However,
>> this causes lots of bogus "switching to interrupt mode" messages.
> they are not "bogus", it is really switching the mode...

Bad words.  It seems bogus because the message changes meaning - for me 
as _user_.  It used to be a gentle reassurance that my computer was 
booting or resuming it's way towards normal working state.  Now it has 
changed to a weaker meaning, because it can also mean that a new 
transaction started in GPE_STORM mode.

In the technical and literal sense the meaning is unchanged.  If the 
message is hidden under DEBUG, that is the only meaning that will matter :).

Thanks
Alan

  reply	other threads:[~2008-10-28 20:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-28 14:05 ACPI: EC: Fix logspam in "GPE storm avoidance" code Alan Jenkins
2008-10-28 18:25 ` Alexey Starikovskiy
2008-10-28 20:18   ` Alan Jenkins [this message]
2008-10-29  0:12   ` Henrique de Moraes Holschuh
2008-10-29  9:51     ` Alan Jenkins
2008-10-29 15:08       ` Henrique de Moraes Holschuh
2008-10-29 16:35         ` Alan Jenkins
2008-10-29 19:00           ` Alexey Starikovskiy
2008-11-01 11:03             ` Alan Jenkins
2008-10-30  1:47           ` Zhao Yakui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4907737F.6060507@tuffmail.co.uk \
    --to=alan-jenkins@tuffmail.co.uk \
    --cc=astarikovskiy@suse.de \
    --cc=linux-acpi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox