Re: [RFC v2 0/7] pch_can/c_can: fix races and add PCH support to c_can

[Marc Kleine-Budde <mkl@pengutronix.de>]

[-- Attachment #1: Type: text/plain, Size: 3057 bytes --]

On 12/06/2012 02:38 PM, Alexander Stein wrote:
>>> On the second line you can see that the register isn't written at all (or the 
>>> read failed for some reason).
>>
>> I assume the latter. Could you please retry reading the register until
>> the correct value shows up. With some timeout, of course.
> 
> I notices having all error events printed on serial console using
> pch_uart driver has negative effect (I guess one problem causes
> another one), so I setup 'dmesg -n1' to reduce serial load before the
> test. Running the test with just one heartbeat triggered LED set
> using I2C the test runs without errors. I only see Lots of 'c_can_pci
> 0000:02:0c.3: can0: write 0x0 to offset 0x2c failed. got: 0x2000' at
> the beginning. It seems this (reserved?) bit is always 1 no matter
> what we write. But things start to break when running the test while
> running 'watch sensors' (sensors queries several temperature sensors
> via I2C) in a seconds ssh session. First off the driver error
> messages (omitting the messages as written above):

Hmmm, maybe there is a hardware problem, that would not be the first one
we've seen in CAN hardware.

> [  384.466217] c_can_pci 0000:02:0c.3: can0: write 0x73 to offset 0x24 failed. got: 0xbc
[...]
> [  700.647000] c_can_pci 0000:02:0c.3: can0: write 0x0 to offset 0x0 failed. got: 0x88

Your spin lock patches look good. I think it's time to get in contact
with your Intel support and try to get through to the hardware people
that can look into the VHDL code.

> As you can see, sometimes it needs several write retries to succeed.
> Nevertheless my test application detects also some problems:

>> Error on MSG ID 0x252. Got counter 96480 and expected 96466
>> Error on MSG ID 0x251. Got counter 96480 and expected 96466
>> Error on MSG ID 0x252. Got counter 101706 and expected 101696
>> Error on MSG ID 0x251. Got counter 101706 and expected 101696
> Here were messages missed/dropped for both CAN-IDs.

Drops can happen at the hardware level, rx-overflow, or in the socket
queueing in linux. Look in the driver if it reports rx-overflows
properly and look at the stats. There also is a flag that indicates
frame drop at the linux socket level, but I don't remember it.

>> Error on MSG ID 0x251. Got counter 108673 and expected 108672
>> Error on MSG ID 0x251. Got counter 108672 and expected 108674
>> Error on MSG ID 0x251. Got counter 108674 and expected 108673
>                                      ^^^^^^
> Here you can see the CAN frame with counter 108673 is read before 108672.

This is a typical out-of-sequence reception with a
RX-goes-into-first-free-mailbox hardware. I've implemented the algorithm
used in the at91 and fixed the one for the ti_hecc.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]