From: Jamin W. C. <jco...@as...> - 2002-08-27 14:19:28
|
Has anyone else tried using ACPI with the C1VN or similiar laptops? I've recently recompiled my kernel, removing APM and enabling ACPI. Most things seem to work fine (battery status and events). However, when I start esd or asd to mix audio streams my processor utilization immediately jumps to ~50% and stays there. The utilization drops to 15-30% if I set longrun to maximum rather than variable. I've verified the utilization with both "top" and "gkrellm". However, while top shows that my CPU is not completely idle, it does not list what is using the CPU. I've tried sorting by CPU utilization, but there are still large gaps. As shown by the following: CPU states: 0.8% user, 25.7% system, 0.0% nice, 73.5% idle Mem: 110876K total, 107672K used, 3204K free, 9944K buffers Swap: 996020K total, 0K used, 996020K free, 48224K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 700 jcollins 15 0 960 960 748 R 1.1 0.8 0:16 top 591 root 10 -10 39296 30M 2052 S < 0.7 27.8 2:14 XFree86 1 root 8 0 488 488 424 S 0.0 0.4 0:01 init 2 root 9 0 0 0 0 SW 0.0 0.0 0:00 keventd 3 root 19 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0 4 root 9 0 0 0 0 SW 0.0 0.0 0:00 kswapd I'm able to run either ESD or ASD with a non-ACPI kernel without these symptoms and likewise, running the ACPI kernel without ESD or ASD results in normal CPU utilization. I've tried both the vanilla ACPI support provided with the 2.4.18 kernel and the latest patches provided by the ACPI project for the 2.4.18 kernel, both exhibit the same behaviour. Any ideas on how to use both ACPI and either ASD or ESD without this high CPU utilization cropping up? -- Jamin W. Collins |
From: Faye P. <fa...@cl...> - 2002-08-27 14:48:36
|
Jamin W. Collins [jco...@as...] wrote: > Has anyone else tried using ACPI with the C1VN or similiar laptops? I've > recently recompiled my kernel, removing APM and enabling ACPI. Most > things seem to work fine (battery status and events). However, when I > start esd or asd to mix audio streams my processor utilization immediately > jumps to ~50% and stays there. The utilization drops to 15-30% if I set > longrun to maximum rather than variable. I've verified the utilization > with both "top" and "gkrellm". However, while top shows that my CPU is > not completely idle, it does not list what is using the CPU. I've tried > sorting by CPU utilization, but there are still large gaps. As shown by > the following: If you stop acpid (if you run it) and cat /proc/acpi/events, do you get a constant stream of events during this high system load? I get a constant stream of Processor 0x80 events if I pass the Passive cooling point on my laptop (Compaq 2701EA) running 2.4.19-020815. This causes the processor to run hotter and therefore continue to stream these events. I need to find what it is which is causing the problem. I had a look at processor and thermal, and when the passive point is reached it does send an acpi event, but if I comment that out, all it does is stop it going to acpi/events, it doesn't stop whatever is spinning and causing the high system load and noone on the list has been able to give me any tips on where to look. I don't remember the problem occurring when I was using 2.4.18-020709 kernel. Perhaps Passive cooling "handling" is new since then? Faye -- Faye Pearson, Software Development Manager, ClaraNET Ltd. Tel 020 7903 3000 Friends may come and go, but enemies accumulate. -- Thomas Jones |
From: Jamin W. C. <jco...@as...> - 2002-08-27 15:32:36
|
On Tue, 27 Aug 2002 15:48:26 +0100 Faye Pearson <fa...@cl...> wrote: > If you stop acpid (if you run it) and cat /proc/acpi/events, do you get > a constant stream of events during this high system load? Nope a "cat /proc/acpi/event" reports nothing. The laptop doesn't seem to suffer any ill effects from the reported CPU utilization. In fact, I haven't noticed any slow down to speak of. Below is the output of "acpi -V" while asd is running: Battery 1: charging, 100% Thermal 1: ok, 48.0 degrees C AC Adapter 1: on-line After several minutes of more or less idling this looks like: Battery 1: charging, 100% Thermal 1: ok, 42.0 degrees C AC Adapter 1: on-line So, the temperature isn't really fluxating that much. -- Jamin W. Collins |
From: Stephen W. <ste...@ea...> - 2002-08-27 14:58:53
|
---- Original Message ---- > From Jamin W. Collins <jco...@as...> > Date: Tuesday, 27 Aug 2002, 15:18 > > CPU states: 0.8% user, 25.7% system, 0.0% nice, 73.5% idle ^^^^^^^^^^^^ The marked bit means that 25.7% of the CPU time is being spent inside the kernel, this means that it doesn't show up on the process list as it is not a normal process causing the load .. hence you weren't able to spot where it was being used even when sorting by CPU usage. A traditional way to create a high system CPU load would be lots of network traffic over an encrypted interface (e.g. cipe) .. so the kernel itself is spending a lot of time doing cryptography. The fact that ACPI is causing this is a problem. One thing to try is check that you are not getting lots of ACPI events or that you are not getting lots of interrupts occuring. The later can be found with 'cat /proc/interrupts' .. run it a few times and compare the results. I'm not an ACPI expert so I can't suggest much else to look for. -- Stephen White <ste...@ea...> |
From: Jamin W. C. <jco...@as...> - 2002-08-27 15:31:51
|
On Tue, 27 Aug 2002 15:58:43 +0100 Stephen White <ste...@ea...> wrote: > ---- Original Message ---- > > From Jamin W. Collins <jco...@as...> > > Date: Tuesday, 27 Aug 2002, 15:18 > > > > CPU states: 0.8% user, 25.7% system, 0.0% nice, 73.5% idle > ^^^^^^^^^^^^ > The marked bit means that 25.7% of the CPU time is being spent inside > the kernel, this means that it doesn't show up on the process list as > it is not a normal process causing the load .. hence you weren't able > to spot where it was being used even when sorting by CPU usage. Cool, that makes sense. > A traditional way to create a high system CPU load would be lots of > network traffic over an encrypted interface (e.g. cipe) .. so the kernel > itself is spending a lot of time doing cryptography. Well, as this only occurs when ASD or ESD is running in conjunction with ACPI, I doubt it's that. > The fact that ACPI is causing this is a problem. One thing to try is > check that you are not getting lots of ACPI events or that you are not > getting lots of interrupts occuring. The later can be found with 'cat > /proc/interrupts' .. run it a few times and compare the results. I assume I'm supposed to be looking at the CPU0 column for changes? If so, I definitely see a drastic increase in the values for interrupts 0 & 9. The following were grabbed by simply repeatedly running the command in rapid succession: **** ASD running **** jamin-mini:/# cat /proc/interrupts CPU0 0: 1189010 XT-PIC timer 1: 1219 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 5329 XT-PIC orinoco_cs 8: 3 XT-PIC rtc 9: 1924005 XT-PIC acpi, usb-uhci, Ricoh Co Ltd RL5c475, YMFPCI 11: 55 XT-PIC sonypi 12: 9081 XT-PIC PS/2 Mouse 14: 89778 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 jamin-mini:/# cat /proc/interrupts CPU0 0: 1189228 XT-PIC timer 1: 1219 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 5343 XT-PIC orinoco_cs 8: 3 XT-PIC rtc 9: 1924413 XT-PIC acpi, usb-uhci, Ricoh Co Ltd RL5c475, YMFPCI 11: 55 XT-PIC sonypi 12: 9081 XT-PIC PS/2 Mouse 14: 89778 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 jamin-mini:/# cat /proc/interrupts CPU0 0: 1189701 XT-PIC timer 1: 1219 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 5357 XT-PIC orinoco_cs 8: 3 XT-PIC rtc 9: 1925301 XT-PIC acpi, usb-uhci, Ricoh Co Ltd RL5c475, YMFPCI 11: 55 XT-PIC sonypi 12: 9081 XT-PIC PS/2 Mouse 14: 89780 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 jamin-mini:/# cat /proc/interrupts CPU0 0: 1190144 XT-PIC timer 1: 1219 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 5371 XT-PIC orinoco_cs 8: 3 XT-PIC rtc 9: 1926132 XT-PIC acpi, usb-uhci, Ricoh Co Ltd RL5c475, YMFPCI 11: 55 XT-PIC sonypi 12: 9081 XT-PIC PS/2 Mouse 14: 89782 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 **** ASD stopped **** jamin-mini:/# cat /proc/interrupts CPU0 0: 1203690 XT-PIC timer 1: 1219 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 5406 XT-PIC orinoco_cs 8: 3 XT-PIC rtc 9: 1950699 XT-PIC acpi, usb-uhci, Ricoh Co Ltd RL5c475, YMFPCI 11: 55 XT-PIC sonypi 12: 9081 XT-PIC PS/2 Mouse 14: 89806 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 jamin-mini:/# cat /proc/interrupts CPU0 0: 1203843 XT-PIC timer 1: 1219 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 5423 XT-PIC orinoco_cs 8: 3 XT-PIC rtc 9: 1950699 XT-PIC acpi, usb-uhci, Ricoh Co Ltd RL5c475, YMFPCI 11: 55 XT-PIC sonypi 12: 9081 XT-PIC PS/2 Mouse 14: 89806 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 jamin-mini:/# cat /proc/interrupts CPU0 0: 1203985 XT-PIC timer 1: 1219 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 5439 XT-PIC orinoco_cs 8: 3 XT-PIC rtc 9: 1950699 XT-PIC acpi, usb-uhci, Ricoh Co Ltd RL5c475, YMFPCI 11: 55 XT-PIC sonypi 12: 9081 XT-PIC PS/2 Mouse 14: 89808 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 jamin-mini:/# cat /proc/interrupts CPU0 0: 1204728 XT-PIC timer 1: 1219 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 5453 XT-PIC orinoco_cs 8: 3 XT-PIC rtc 9: 1950699 XT-PIC acpi, usb-uhci, Ricoh Co Ltd RL5c475, YMFPCI 11: 55 XT-PIC sonypi 12: 9081 XT-PIC PS/2 Mouse 14: 89814 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 -- Jamin W. Collins |
From: Carlos M. <ch...@ch...> - 2002-08-27 15:53:30
|
On 2002.08.27 15:18:44 +0100 Jamin W. Collins wrote: > I'm able to run either ESD or ASD with a non-ACPI kernel without these > symptoms and likewise, running the ACPI kernel without ESD or ASD results > in normal CPU utilization. > check the irq distribution on an apm and an acpi kernel -- Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey: 0x1FC57F0A http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A Software is like sex; it's better when it's free. - Linus Torvalds |
From: Jamin W. C. <jco...@as...> - 2002-08-27 16:10:07
|
On Tue, 27 Aug 2002 16:53:20 +0100 Carlos Morgado <ch...@ch...> wrote: > check the irq distribution on an apm and an acpi kernel ACPI Kernel - 2.4.18 - with ACPI and SWSUP patches 0: 1204728 XT-PIC timer 1: 1219 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 5453 XT-PIC orinoco_cs 8: 3 XT-PIC rtc 9: 1950699 XT-PIC acpi, usb-uhci, Ricoh Co Ltd RL5c475, YMFPCI 11: 55 XT-PIC sonypi 12: 9081 XT-PIC PS/2 Mouse 14: 89814 XT-PIC ide0 APM Kernel - 2.4.18 - stock Debian 586tsc 0: 34547 XT-PIC timer 1: 5 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 190 XT-PIC orinoco_cs 8: 3 XT-PIC rtc 9: 31 XT-PIC usb-uhci, Ricoh Co Ltd RL5c475, YMFPCI 11: 3 XT-PIC sonypi 12: 15 XT-PIC PS/2 Mouse 14: 68288 XT-PIC ide0 With the exception of acpi not existing in the APM kernel, they look exactly the same. -- Jamin W. Collins |