[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CE63C05.6060101@grandegger.com>
Date: Fri, 19 Nov 2010 09:57:41 +0100
From: Wolfgang Grandegger <wg@...ndegger.com>
To: Tomoya MORINAGA <tomoya-linux@....okisemi.com>
CC: "David S. Miller" <davem@...emloft.net>,
Wolfram Sang <w.sang@...gutronix.de>,
Christian Pellegrin <chripell@...e.org>,
Barry Song <21cnbao@...il.com>,
Samuel Ortiz <sameo@...ux.intel.com>,
socketcan-core@...ts.berlios.de, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, andrew.chih.howe.khor@...el.com,
qi.wang@...el.com, margie.foster@...el.com, yong.y.wang@...el.com,
Masayuki Ohtake <masa-korg@....okisemi.com>,
kok.howg.ewe@...el.com, joel.clark@...el.com
Subject: Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Add Flow
control,
Hi Tomoya,
On 11/19/2010 08:36 AM, Tomoya MORINAGA wrote:
> On Tuesday, November 16, 2010 7:16 PM, Wolfgang Grandegger wrote :
>
>>> ......It seems the same line continues forever.
>>
>> Yes, it will continue until you connect the cable, that's normal
>> behavior. But that's not the full sequence. Could you please repeat the
>> test as shown below:
>>
>> First start the following command in a *separate* session.
>> # candump any,0:0,#FFFFFFFF"
>>
>> Then setup and start the CAN controller:
>> # ip link set can0 up type can bitrate 125000
>> # cansend can0 123#deadbeef
>>
>
> I show the result of the above command below,
>
> [root@...alhost can-utils]# candump any,0:0,#FFFFFFFF
> can0 20000020 [8] 00 00 00 00 00 00 08 00 ERRORFRAME
> can0 20000020 [8] 00 00 00 00 00 00 10 00 ERRORFRAME
> can0 20000020 [8] 00 00 00 00 00 00 18 00 ERRORFRAME
> can0 20000020 [8] 00 00 00 00 00 00 20 00 ERRORFRAME
> can0 20000020 [8] 00 00 00 00 00 00 28 00 ERRORFRAME
> can0 20000020 [8] 00 00 00 00 00 00 30 00 ERRORFRAME
> can0 20000020 [8] 00 00 00 00 00 00 38 00 ERRORFRAME
> can0 20000020 [8] 00 00 00 00 00 00 40 00 ERRORFRAME
> can0 20000020 [8] 00 00 00 00 00 00 48 00 ERRORFRAME
> can0 20000020 [8] 00 00 00 00 00 00 50 00 ERRORFRAME
> can0 20000020 [8] 00 00 00 00 00 00 58 00 ERRORFRAME
The above lines describe bus errors. Therefore it should be
can0 20000088 [8] 00 00 80 19 00 00 58 00 ERRORFRAME
> can0 20000024 [8] 00 00 00 00 00 00 60 00 ERRORFRAME
The TX error counter has reached 96 signaling a can error state change
to "error warning".
> can0 20000024 [8] 00 08 00 00 00 00 68 00 ERRORFRAME
CAN_ERR_CRTL in the id and CAN_ERR_CRTL_TX_WARNING in data[1], but ...
> can0 20000024 [8] 00 08 00 00 00 00 70 00 ERRORFRAME
the state change should be signaled only *once*.
> can0 20000024 [8] 00 08 00 00 00 00 78 00 ERRORFRAME
> can0 20000024 [8] 00 28 00 00 00 00 80 00 ERRORFRAME
"Error passive" state is reached and CAN_ERR_CRTL_TX_PASSIVE sould be
set in data[1], but CAN_ERR_CRTL_TX_WARNING should be removed.
> can0 20000024 [8] 00 28 00 00 00 00 80 00 ERRORFRAME
> can0 20000024 [8] 00 28 00 00 00 00 80 00 ERRORFRAME
> can0 20000024 [8] 00 28 00 00 00 00 80 00 ERRORFRAME
Sounds magic, well, I'm going to prepare a patch as soon as your pending
patch series is applied.
Could you please do the same testing while triggering a bus-off? After
the test, the output of "ip -d -s link" would be interesting as well.
Thanks,
Wolfgang.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists