6

I have an Ubuntu box with 3.2 kernel, CPU with 2 cores and CAN (Controller Area Network) card based on SJA1000 controller attached via PCI bus.

I'm testing receive capabilities of the card. It can handle about ~4000 packets per second, the corresponding interrupt is also raised ~4000 times per second (as /proc/interrupts shows) and it does not cause any CPU load on the system. However, if I generate artificial CPU load with stress command:

chrt --idle 0 stress -c 2

the interrupts are no longer raised and therefore no messages are received.

Why CPU load inhibits hardware interrupts and what can be done about it?

Improve this question
1
  • Do you have any sort of out-of-band management interface available through which you would be able to access the Server/System Event Log(SEL), for example ipmi? If there is some sort of low level hardware issue there is a possibility it would leave something in the SEL.
    – Matt
    Jul 9, 2015 at 23:14

2 Answers 2

Reset to default
1

I suspect what's going on is that the CPU load is blocking from the interrupts being serviced by the CPU.

Use itop to see what's really going on. An output of this would help to understand your problem further.

Improve this answer
1

There may be some BIOS settings that are adjustable, but more information would be necessary to be certain exactly which settings would have the most significant impact.

The interrupts being required to exit the HLT state referenced in this answer seems interesting and possibly related? Based on the nature of the stress workload and if hyper threading is enabled on the system some of the 'virtual' CPUs that are added with hyper threading could conceivably be put into an HLT state until stress levels are lowered and it is possible that the hardware could chose to ignore interrupts to processes running on those CPUs.

Low level hardware configurations in BIOS and the OS kernel can have huge impacts on many different aspects of performance. Verifying that your system is configured to properly handle add-in cards(graphics, communications, etc) of any sort can be a major challenge. More details about the physical hardware and kernel settings, as well as any additional logs like Server/System Event Log(SEL) or Sensor Data Record(SDR) would be beneficial to further diagnose a low level hardware issue like this.

The SEL and SDR are available on most modern servers and can be accessed using ipmitool or a variety of other open source and proprietary/vendor provided tools for in-band and out-of-band server management.

Improve this answer

You must log in to answer this question.