Hi,
after upgrading 2.4.23->2.4.26 I am seeing/heariing two problems on
my "HP Omnibookk 6100"":
a) I am getting a lot of double hits when typing (juust see this mmail.
I am not correecting the errors on purpose :-) While I have some
sttupid mistyping habits, double hits all over thhe place did not
belong to them up to now.
b)) Before the upgrade the notebook fan was rarely running at full
speed. AAnd if, only forr short ttimes. Now it kicks in frequeently and
for up to 15 minutes.
Any ideas? I am running SuSE 9.0 with KDE 3.2.0 and XFree 4.3.0.
lspci/lsmod and config included.
mknoblau@mkn5833l1:~> /sbin/lsmod
Module Size Used by Tainted: PF
thermal 6340 0 (unused)
processor 8504 0 [thermal]
vmnet 20432 8
vmmon 34517 5
usbserial 18972 0 (autoclean) (unused)
parport_pc 26184 1 (autoclean)
lp 6336 0 (autoclean)
fan 1504 0 (unused)
button 2476 0 (unused)
battery 5632 0 (unused)
ac 1696 0 (unused)
avma1_cs 2820 0 (unused)
hisax 452700 2 [avma1_cs]
isdn 122432 4 [hisax]
slhc 4816 0 [isdn]
ds 6836 2 [avma1_cs]
yenta_socket 10208 2
pcmcia_core 39680 0 [avma1_cs ds yenta_socket]
printer 7424 0
st 28440 0 (autoclean) (unused)
sg 31292 0 (autoclean)
mousedev 4052 0 (unused)
joydev 5952 0 (unused)
evdev 3904 0 (unused)
input 3136 0 [mousedev joydev evdev]
usb-uhci 22128 0 (unused)
usbcore 58828 1 [usbserial printer usb-uhci]
af_packet 12520 0 (autoclean)
e100 47688 1
ide-scsi 9648 1 (autoclean)
mknoblau@mkn5833l1:~> /sbin/lspci
00:00.0 Host bridge: Intel Corp. 82830 830 Chipset Host Bridge (rev 02)
00:01.0 PCI bridge: Intel Corp. 82830 830 Chipset AGP Bridge (rev 02)
00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 01)
00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 41)
00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 01)
00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 01)
00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility
M6 LY
02:03.0 Multimedia audio controller: ESS Technology ES1988 Allegro-1
(rev 12)
02:04.0 Communication controller: Lucent Microelectronics LT WinModem
(rev 02)
02:05.0 CardBus bridge: Texas Instruments PCI1420
02:05.1 CardBus bridge: Texas Instruments PCI1420
02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100 VM
(KM) Ethernet Controller (rev 41)
Cheers
Martin
=====
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
>Hi,
>
>
>after upgrading 2.4.23->2.4.26 I am seeing/heariing two problems on
>my "HP Omnibookk 6100"":
>
>a) I am getting a lot of double hits when typing (juust see this
mmail.
>I am not correecting the errors on purpose :-) While I have some
>sttupid mistyping habits, double hits all over thhe place did not
>belong to them up to now.
>
Short update. Problem a) seems to be acpi-related. When booting with
"acpi=off", the keyboard behaves OK.
Not only the keyboard is affected, but also the mouse. I just did not
see it immediatelly, but with acpi enabled I am loosing pointer events.
>b)) Before the upgrade the notebook fan was rarely running at full
>speed. AAnd if, only forr short ttimes. Now it kicks in frequeently
and
>for up to 15 minutes.
>
Cheers
Martin
=====
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
On Tue, 2004-04-20 at 07:09, Martin Knoblauch wrote:
> >Hi,
> >
> >
> >after upgrading 2.4.23->2.4.26 I am seeing/heariing two problems on
> >my "HP Omnibookk 6100"":
> >
> >a) I am getting a lot of double hits when typing (juust see this
> mmail.
> >I am not correecting the errors on purpose :-) While I have some
> >sttupid mistyping habits, double hits all over thhe place did not
> >belong to them up to now.
> >
>
> Short update. Problem a) seems to be acpi-related. When booting with
> "acpi=off", the keyboard behaves OK.
>
> Not only the keyboard is affected, but also the mouse. I just did not
> see it immediatelly, but with acpi enabled I am loosing pointer
> events.
>
> >b)) Before the upgrade the notebook fan was rarely running at full
> >speed. AAnd if, only forr short ttimes. Now it kicks in frequeently
> and
> >for up to 15 minutes.
> >
Does /proc/interrupts show any acpi events?
Did it in 2.4.23?
>> >b)) Before the upgrade the notebook fan was rarely running at full
>> >speed. AAnd if, only forr short ttimes. Now it kicks in frequeently
>> and
>> >for up to 15 minutes.
>> >
>
>Does /proc/interrupts show any acpi events?
>Did it in 2.4.23?
>
Len,
when booting without "acpi=off" it shows indeed 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
NMI: 0
ERR: 0
When booting with "acpi=off", as well as with 2.4.23 it shown no acpi
interrupts (not really surprising).
Martin
=====
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
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.
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.
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]
cheers,
-Len
--- Len Brown <[email protected]> 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