# top reports 100% of CPU for "hi"

## KarlisRepsons

Forum attendees,

anyone can explain what could be a reason for top command to report a line like this:

 *Quote:*   

> Cpu(s):  0.3%us,  0.3%sy,  0.0%ni,  0.0%id,  0.0%wa, 99.3%hi,  0.0%si,  0.0%st

 

Note that it's in idle conditions, "hi" is supposedly standing for HardwareInterrupts... If some process starts running, hi drops, but id is always 0... Any guess? Is that something bad?

----------

## Hu

I would expect hardware interrupts should be near zero in a normal system.  A high level of hardware interrupts could indicate a buggy driver is not properly servicing some hardware device.

----------

## KarlisRepsons

I wonder if there is some way to find out which is that driver...

----------

## aderesch

 *KarlisRepsons wrote:*   

> I wonder if there is some way to find out which is that driver...

 

cat /proc/interrupts and look for unusually large numbers. Then look at the listed drivers for that interrupt, lspci output, and the kernel log to find the corresponding device/driver.

ad

----------

## KarlisRepsons

 *aderesch wrote:*   

> cat /proc/interrupts and look for unusually large numbers.

 

I'm seeing this for the output:

 *Quote:*   

> # cat /proc/interrupts
> 
>            CPU0       
> 
>   0:   23026493   IO-APIC-edge      timer
> ...

 

So I guess, something needs to be changed in kernel related to some (perhaps high precision) timer?

----------

## aderesch

 *KarlisRepsons wrote:*   

> So I guess, something needs to be changed in kernel related to some (perhaps high precision) timer?

 

Hhmm, timer is somewhat of a special case. What's the rate of timer interrupts (i.e. how many per second on average)? What's the value of CONFIG_HZ for this kernel? Is CONFIG_NO_HZ set? If not, can you try that? What kind of hardware are we talking about by the way?

ad

----------

## krinn

your video card isn't list, dig that, kernel might try to speak with your video and its not getting answer, hence the high interrupts requests

----------

## KarlisRepsons

 *aderesch wrote:*   

> What's the rate of timer interrupts (i.e. how many per second on average)?
> 
> What's the value of CONFIG_HZ for this kernel? Is CONFIG_NO_HZ set? If not, can you try that?

 

 *zcat /proc/config.gz | grep HZ wrote:*   

> # CONFIG_NO_HZ is not set
> 
> # CONFIG_HZ_100 is not set
> 
> CONFIG_HZ_250=y
> ...

 

 *aderesch wrote:*   

> What kind of hardware are we talking about by the way?

 

VIA C7 on a Jetway mini-itx board!

I'm considering to rebuild kernel a bit differently by using make oldconfig, then make menuconfig, because I saw some warnings about mismatches (don't remember exactly), they involved grsec and some rtc drivers... I just copied the old config and ran make menuconfig, could that be to blame? Or I had to dig in make menuconfig to find how can I get those warnings gone..? (I'll post the exact warnings later if will be necessary)

----------

## KarlisRepsons

 *krinn wrote:*   

> your video card isn't list, dig that, kernel might try to speak with your video and its not getting answer, hence the high interrupts requests

 

If that changes anything, I only use console and integrated video card. 

And by the way, looks like this problem with kernel really needs to be fixed, I just got a system freeze!

----------

## Hu

Does the problem occur on a non-GRsecurity-patched kernel?

----------

## krinn

forget the video on console usage only.

you can check hpet support : 

grep hpet /proc/timer_list 

and enable it with kernel param: clocksource=hpet

on all my box local timer interrupts is always far higher than timer, no doubt a kernel issue there with timer.

----------

## KarlisRepsons

I just compiled gentoo-sources of the same version and no problem with "hi"... However, I really got rid of those warnings, which I had after finishing make menuconfig previously (added eeprom support in one option and no grsec). Now I'll try with grsec configured from scratch. I moved from 2.6.28 to 2.6.38...

If anything, I have this:

 *Quote:*   

> # grep hpet /proc/timer_list 
> 
> # grep HPET /proc/timer_list 
> 
> # zcat /proc/config.gz | grep CONFIG_HPET
> ...

 

Add:

perhaps there is nothing really bad about it, but for hardened-sources warnings like this show up:

 *Quote:*   

> make > /dev/null
> 
> arch/x86/kernel/apic/io_apic.c: In function 'check_timer':
> 
> arch/x86/kernel/apic/io_apic.c:2783: warning: comparison of unsigned expression >= 0 is always true

 

----------

## KarlisRepsons

With grsecurity I'm again having 100% "hi" with unused system! The additional difference is, however, that in one case it's hardened-sources kernel and in the other it's gentoo-sources one. Confused. Should I throw away grsecurity? Or how could I fix the issue? I remember that the original author of grsec lost funding for the project and I don't know what is the quality of the latest made of it. Maybe it's even better to just stay away from it's bugs rather than having it's semi-artificial patch style security? Any pointers to comparison of the actual gentoo-sources vs hardened-sources with grsec and PaX on? I, of course, originally stick with PaX and grsec because it seemed more secure.

----------

## KarlisRepsons

An interesting observation: with very similar configuration the same version of Linux compiled without a single warning as for gentoo-sources, but with lots and lots of them for hardened-sources... Am I just in rush or hardened gentoo is going nowhere?

----------

