CPU load inhibits CAN interrupts

CPU load inhibits CAN interrupts

[Krzysztof Witkowski]

I have an Ubuntu box with 3.2 kernel, CPU with 2 cores and PEAK-PCI card 
(SJA1000 controller attached via PCI bus)

I'm testing receive capabilities of the card on 1Mbit network using 
peak_pci module. 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 high CPU load on the system.

However, if I generate artificial CPU load with stress command:

    chrt --idle 0 stress -c 2

the Receive Interrupts from SJA1000 are no longer raised at all and 
therefore no messages are received. At the same time network card (e100) 
on the same IRQ is working properly.

Why CPU load inhibits hardware interrupts and what can be done about it? 
Or should I suspect hardware malfunction?

Re: CPU load inhibits CAN interrupts

[Wolfgang Grandegger]

On 04/10/2012 04:40 PM, Krzysztof Witkowski wrote:
> I have an Ubuntu box with 3.2 kernel, CPU with 2 cores and PEAK-PCI card
> (SJA1000 controller attached via PCI bus)
> 
> I'm testing receive capabilities of the card on 1Mbit network using
> peak_pci module. 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 high CPU load on the system.
> 
> However, if I generate artificial CPU load with stress command:
> 
>    chrt --idle 0 stress -c 2

What does "-c 2" do? My "chrt" command does not have that option.

> the Receive Interrupts from SJA1000 are no longer raised at all and
> therefore no messages are received. At the same time network card (e100)
> on the same IRQ is working properly.

That's wired. Interrupt processing of the SJA1000 is done in the
interrupt context.

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

Hm, what does "ip -d -s can0" report while you are producing CPU load
with the stress command above.

> Or should I suspect hardware malfunction?

More likely it's a bug.

Wolfgang.

Re: CPU load inhibits CAN interrupts

[Krzysztof Witkowski]

W dniu 4/10/2012 7:48 PM, Wolfgang Grandegger pisze:
>> However, if I generate artificial CPU load with stress command:
>>
>>     chrt --idle 0 stress -c 2
>
> What does "-c 2" do? My "chrt" command does not have that option.

It is an option for stress command:
-c, --cpu N
               spawn N workers spinning on sqrt()

>> Why CPU load inhibits hardware interrupts and what can be done about it?
>
> Hm, what does "ip -d -s can0" report while you are producing CPU load
> with the stress command above.

# ip -s -d link show can0

4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN 
mode DEFAULT qlen 10
     link/can
     can state ERROR-PASSIVE (berr-counter tx 0 rx 128) restart-ms 100
     bitrate 1000000 sample-point 0.750
     tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 2
     sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
     clock 8000000
     re-started bus-errors arbit-lost error-warn error-pass bus-off
     0          0          0          1          1          0
     RX: bytes  packets  errors  dropped overrun mcast
     728        91       0       0       0       0
     TX: bytes  packets  errors  dropped carrier collsns
     0          0        0       0       0       0


It can occasionally deliver packets, but the rate is no more than ~2 
packets/second.

Re: CPU load inhibits CAN interrupts

[Wolfgang Grandegger]

On 04/11/2012 11:40 AM, Krzysztof Witkowski wrote:
> W dniu 4/10/2012 7:48 PM, Wolfgang Grandegger pisze:
>>> However, if I generate artificial CPU load with stress command:
>>>
>>>     chrt --idle 0 stress -c 2
>>
>> What does "-c 2" do? My "chrt" command does not have that option.
> 
> It is an option for stress command:
> -c, --cpu N
>               spawn N workers spinning on sqrt()
> 
>>> Why CPU load inhibits hardware interrupts and what can be done about it?
>>
>> Hm, what does "ip -d -s can0" report while you are producing CPU load
>> with the stress command above.
> 
> # ip -s -d link show can0
> 
> 4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
> mode DEFAULT qlen 10
>     link/can
>     can state ERROR-PASSIVE (berr-counter tx 0 rx 128) restart-ms 100
>     bitrate 1000000 sample-point 0.750
>     tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 2

Why did you set sja to 2? To avoid bus errors? If yes, maybe 4 is better.

>     sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
>     clock 8000000
>     re-started bus-errors arbit-lost error-warn error-pass bus-off
>     0          0          0          1          1          0
>     RX: bytes  packets  errors  dropped overrun mcast
>     728        91       0       0       0       0
>     TX: bytes  packets  errors  dropped carrier collsns
>     0          0        0       0       0       0
> 
> 
> It can occasionally deliver packets, but the rate is no more than ~2
> packets/second.

Strange, anyway, the statistics above reports electrical problems on the
CAN bus. What do you get with the "ip" option "berr-reporting on?
Is there an app reading the CAN messages at the same time?

BTW: what SJA1000 driver and kernel version do you use?

Wolfgang.