CPU Overload

stoa · May 25, 2014

Greetings:

I have a fairly new install (approx. three weeks) which I upgraded to STABLE last week. I have recently noticed high CPU usage (in the range of 30%) on a core2-Duo @ 3.0GHz. I don't know if this state existed before the upgrade. This is in an otherwise resting state with X and i3 running. top reports a resting 0 - 1% before X starts. All other machines I operate with this identical setup rest at 2 - 3% (both OpenBSD and various Linux) with X and i3 running.

I have reviewed the very similar post at https://forums.freebsd.org/viewtopic.php?&t=26319, but there was no actual solution. I disabled my xorg.conf but it made no difference. I have also checked procstat but nothing jumped out. The top(1)() page is very generic, so no help in deciphering some of the other stats provided by top.

My uname -pr is: 10.0-STABLE amd64.

Any hints to determine the problem are appreciated.

stoa · May 26, 2014

I've done a little more checking on the load problem. It seems my (virtually) entire load at idle (and again, this is when X is running through xdm only; no problem in the console) is caused by interrupts. Top reports CPU usage as : 0.0% user, 0.0% nice, 0.0% system, 27.5% interrupt, and 72.5% idle.

The command systat -vmstat shows 325k interrupts, and 324k of them are caused by UHCI. I don't know if this is unusual or not.

If anyone using the UHCI could let me know what their interrupts for this category are using systat -vmstat, that would help. Thanks.

worldi · May 27, 2014

stoa said:
The command systat -vmstat shows 325k interrupts, and 324k of them are caused by UHCI. I don't know if this is unusual or not.

Here's your problem. vmstat -i reports insane rates (like 1k+) for UHCI, right?

There's probably something wrong with the USB stack. I've had similar problems under 9.2-RELEASE about a year ago: I noticed that connecting (and then using) a USB keyboard while the system was running raised the CPU temperature by 5-10°C. This was because of extremely high interrupt rates for EHCI.

kpa · May 27, 2014

That's a sign of a badly designed USB device that needs some special handling from the USB stack. Either it needs what is knows as a "quirk" that is handled by the usb_quirk(4) module or it needs to be fixed in source code. Ask on the freebsd-usb for more advice.

stoa · May 28, 2014

Thanks for the replies.

I reviewed usb_quirk() but there does not appear to be any applicable quirk modules to address either of my two USB connections (mouse and keyboard.) It may be instructive that disconnecting the keyboard and mouse has no effect upon the number of interrupts. Changing the keyboard from a stock Dell to a Razer also makes no difference.

I was able to glean a little more diagnostic information, though. It appears that if I suspend to RAM with the command acpiconf -s 3, upon waking the interrupts are virtually gone and all other load values are normal. I'm unclear at this point how power management relates to USB interrupts, but there is a connection; I've repeated the suspending/waking three times with identical results.

Does anyone have any suggestions given this new information?

Terri_Kennedy · May 28, 2014

stoa said:
Does anyone have any suggestions given this new information?

Unfortunately, one of the remaining design defects of the IBM PC architecture is the limited number of interrupts, mapped to a pair of emulated 8259's. This means that a number of devices end up sharing an interrupt. It is sometimes the case that a peripheral device that FreeBSD doesn't need to know about shares an interrupt with something FreeBSD does know about. So, whenever an interrupt comes in from the unknown hardware, FreeBSD hands it to the driver for the device that it thinks is the only possible source of that interrupt. That driver's interrupt service routine then goes out and checks the devices it controls to find the source of the interrupt. Finding none, it dismisses the interrupt. In the case of the USB driver, it is checking all of the possible USB devices and running up CPU time.

Do a grep irq /var/run/dmesg.boot and see if any other devices are sharing an IRQ with your uhci(4) device. If you don't see anything there, go into the BIOS setup routine and see if it allows you to change interrupt mappings, either via explicit selection for each device or via a global "swizzling" option (don't blame me, I didn't pick the name). This is more commonly available on server motherboards, though, so you may not have that option. If all else fails, try disabling any devices you don't use in the BIOS.

For the gory details, see PCI Interrupts for x86 Machines under FreeBSD.

stoa · May 28, 2014

Terry - thanks for the info (although I'll admit most of it is well beyond my incipient knowledge of computer internals.) I also didn't see anything extremely helpful on the dmesg output, but again, that could be my lack of knowledge.

More to the point, though, is that I don't think this is an OS/hardware problem (i.e., needing correction at the BIOS level, etc.), but is a software problem, specifically, an X.org problem (see above, where the interrupts only occur while X is running).

Any suggestions as to why X (probably xf86-input-keyboard and/or xf86-input-mouse, as they are the only two USB devices I have connected) would be causing interrupts? (This may be totally unconnected, but when I upgraded from RELEASE to STABLE everything worked fine, except the keyboard and mouse did not work at all while X was running. However, the removal and re-installation of those two packages referred to above immediately solved the problem. Maybe there is some lingering issue causing the interrupts?)

Thanks again for your help.

Terri_Kennedy · May 28, 2014

stoa said:
More to the point, though, is that I don't think this is an OS/hardware problem (i.e., needing correction at the BIOS level, etc.), but is a software problem, specifically, an X.org problem (see above, where the interrupts only occur while X is running).

The rate of interrupts seems improbably high, so unless it is sending some commands to the hardware that is causing it to do that, I'd bet on broken / misconfigured hardware. It could well be using a different command to achieve the same purpose in the newer version, which is triggering the interrupt storm as a side effect.

Any suggestions as to why X (probably xf86-input-keyboard and/or xf86-input-mouse, as they are the only two USB devices I have connected) would be causing interrupts? (This may be totally unconnected, but when I upgraded from RELEASE to STABLE everything worked fine, except the keyboard and mouse did not work at all while X was running. However, the removal and re-installation of those two packages referred to above immediately solved the problem. Maybe there is some lingering issue causing the interrupts?)

Sorry, I don't use X on my FreeBSD boxes - they're all headless servers. As a general comment, the keyboard is also one of the legacy areas that can cause problems. This is because even the latest fancy USB stuff still needs to emulate the original IBM AT keyboard controller, at least until a system boots far enough to not need legacy emulation. For example, I have a recent "big name" system (Dell PowerEdge R310) that complains thusly on every boot:

Code:

May 24 18:57:04 test kernel: atkbd: unable to set the command byte.
May 24 18:57:04 test kernel: psm0: unable to set the command byte.

In my case, it is harmless.

Perhaps someone with X experience can provide you with a better answer.