From: Martin Knoblauch <knobi@knobisoft.de>
To: Len Brown <len.brown@intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Two problems after upgrade tto 2.4.26
Date: Mon, 26 Apr 2004 03:04:56 -0700 (PDT) [thread overview]
Message-ID: <20040426100456.82710.qmail@web13909.mail.yahoo.com> (raw)
In-Reply-To: <1082861443.3160.18.camel@dhcppc4>
--- Len Brown <len.brown@intel.com> wrote:
> On Fri, 2004-04-23 at 04:22, Martin Knoblauch wrote:
>
> Re: keyboard/mouse instability with ACPI enabled starting in 2.4.26
>
> > >Does /proc/interrupts show any acpi events?
> > >Did it in 2.4.23?
> > >
> > Len,
> >
> > some ACPI Interrupts:
> >
> > cat /proc/interrupts
> > CPU0
> > 0: 31464 XT-PIC timer
> > 1: 570 XT-PIC keyboard
> > 2: 0 XT-PIC cascade
> > 3: 5 XT-PIC HiSax
> > 8: 2 XT-PIC rtc
> > 9: 1197 XT-PIC acpi
> > 10: 1695 XT-PIC eth0, usb-uhci, Texas Instruments
> > PCI1420, Texas Instruments PCI1420 (#2)
> > 12: 5460 XT-PIC PS/2 Mouse
> > 14: 18052 XT-PIC ide0
> > 15: 11 XT-PIC ide1
>
> kill acpid and
> # cat /proc/acpi/event
> to see what the events are.
> We we are working on a GPE issue related to spurious
> ACPI interrupts right now, but I'd actually expect
> 2.4.26 to get _fewer_ acpi interrupts than 2.4.25, not more.
>
Hi Len,
just to make things clear: I never talked about 2.4.25 :-) I went
directly from 2.4.23 to 2.4.26. And ACPI was not set in my 2.4.23
config. Not sure how it got set in 2.4.26? Interesting ...
Anyway, I killed acpid and did a cat on the event stream. All I see
is:
# cat /proc/acpi/event
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
thermal_zone THRM 00000081 00000000
^C
#
During this snapshot, the number of ACPI interrupts went up by about
270. So, it seems not every ACPI interrupt ends in /proc/acpi/event.
In general, the whole thing is pretty hard to reproduce. It seems to
be also depenant on the system load. The keyboard double-hit is much
more likely to happen when running a kernel compile instead of an
otherwise idle system.
> Re: fan running more
> it would be interesting if you notice a temperature difference
> between the releases in /proc/acpi/thermal...
>
> eg.
> cat /proc/acpi/thermal_zone/THRM/temperature
> temperature: 37 C
>
>
> FAN isn't always controlled by ACPI. If it is, you'll see it
> in the dmesg like this:
> ACPI: Power Resource [PFAN] (off)
> In either case, it may be that we're running hotter (say idle
> isn't working right), or we're running the fan more often by mistake.
>
Nope, no such messages in dmesg.
> For idle, you can compare the /proc/acpi/processor/CPU0/power
> file in the two releases to see if one release is getting into
> a deeper power-saving state than the other.
>
> Eg, this centrino box isn't getting into C3 because USB is active.
>
> cat /proc/acpi/processor/CPU0/power
> active state: C2
> default state: C1
> bus master activity: ffffffff
> states:
> C1: promotion[C2] demotion[--] latency[000]
> usage[00000010]
> *C2: promotion[C3] demotion[C1] latency[001]
> usage[00370077]
> C3: promotion[--] demotion[C2] latency[085]
> usage[00000000]
>
>
On my system it looks like this:
# cat /proc/acpi/processor/CPU0/power
active state: C2
default state: C1
bus master activity: 00000000
states:
C1: promotion[C2] demotion[--] latency[000]
usage[00012170]
*C2: promotion[--] demotion[C1] latency[010]
usage[00888388]
C3: <not supported>
> cheers,
> -Len
>
Thanks
Martin
=====
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
next prev parent reply other threads:[~2004-04-26 10:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <A6974D8E5F98D511BB910002A50A6647615F981B@hdsmsx403.hd.intel.com>
2004-04-25 2:50 ` Len Brown
2004-04-26 10:04 ` Martin Knoblauch [this message]
2004-04-23 8:22 Martin Knoblauch
[not found] <A6974D8E5F98D511BB910002A50A6647615F936B@hdsmsx403.hd.intel.com>
2004-04-22 3:08 ` Len Brown
-- strict thread matches above, loose matches on Subject: below --
2004-04-20 11:09 Martin Knoblauch
2004-04-16 11:18 Martin Knoblauch
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=20040426100456.82710.qmail@web13909.mail.yahoo.com \
--to=knobi@knobisoft.de \
--cc=len.brown@intel.com \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®