From: Wolfgang Grandegger <wg@grandegger.com>
To: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Wolfram Sang <w.sang@pengutronix.de>,
Christian Pellegrin <chripell@fsfe.org>,
Barry Song <21cnbao@gmail.com>,
Samuel Ortiz <sameo@linux.intel.com>,
socketcan-core@lists.berlios.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, andrew.chih.howe.khor@intel.com,
qi.wang@intel.com, margie.foster@intel.com,
yong.y.wang@intel.com,
Masayuki Ohtake <masa-korg@dsn.okisemi.com>,
kok.howg.ewe@intel.com, joel.clark@intel.com
Subject: Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Add Flow control,
Date: Fri, 19 Nov 2010 09:57:41 +0100 [thread overview]
Message-ID: <4CE63C05.6060101@grandegger.com> (raw)
In-Reply-To: <00bf01cb87bc$8ed6e300$66f8800a@maildom.okisemi.com>
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@localhost 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.
WARNING: multiple messages have this Message-ID (diff)
From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
To: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Masayuki Ohtake
<masa-korg-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>,
Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
margie.foster-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
joel.clark-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
"David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
Christian Pellegrin <chripell-VaTbYqLCNhc@public.gmane.org>,
qi.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
Subject: Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Add Flow control,
Date: Fri, 19 Nov 2010 09:57:41 +0100 [thread overview]
Message-ID: <4CE63C05.6060101@grandegger.com> (raw)
In-Reply-To: <00bf01cb87bc$8ed6e300$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org>
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@localhost 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.
next prev parent reply other threads:[~2010-11-19 8:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-15 8:30 [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Add Flow control, Tomoya MORINAGA
2010-11-15 8:30 ` Tomoya MORINAGA
2010-11-15 9:11 ` Marc Kleine-Budde
2010-11-15 9:11 ` Marc Kleine-Budde
2010-11-16 5:18 ` Tomoya MORINAGA
2010-11-16 5:18 ` Tomoya MORINAGA
2010-11-16 8:14 ` Marc Kleine-Budde
2010-11-16 8:14 ` Marc Kleine-Budde
2010-11-16 9:33 ` Tomoya MORINAGA
2010-11-16 9:33 ` Tomoya MORINAGA
2010-11-16 17:11 ` David Miller
2010-11-16 17:11 ` David Miller
2010-11-15 9:37 ` Marc Kleine-Budde
2010-11-15 9:37 ` Marc Kleine-Budde
2010-11-16 5:30 ` Tomoya MORINAGA
2010-11-16 5:30 ` Tomoya MORINAGA
2010-11-15 14:21 ` Wolfgang Grandegger
2010-11-15 14:21 ` Wolfgang Grandegger
2010-11-16 8:25 ` Tomoya MORINAGA
2010-11-16 8:25 ` Tomoya MORINAGA
2010-11-16 10:16 ` Wolfgang Grandegger
2010-11-16 10:16 ` Wolfgang Grandegger
2010-11-19 7:36 ` Tomoya MORINAGA
2010-11-19 7:36 ` Tomoya MORINAGA
2010-11-19 8:57 ` Wolfgang Grandegger [this message]
2010-11-19 8:57 ` Wolfgang Grandegger
2010-11-22 5:20 ` Tomoya MORINAGA
2010-11-22 5:20 ` Tomoya MORINAGA
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CE63C05.6060101@grandegger.com \
--to=wg@grandegger.com \
--cc=21cnbao@gmail.com \
--cc=andrew.chih.howe.khor@intel.com \
--cc=chripell@fsfe.org \
--cc=davem@davemloft.net \
--cc=joel.clark@intel.com \
--cc=kok.howg.ewe@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=margie.foster@intel.com \
--cc=masa-korg@dsn.okisemi.com \
--cc=netdev@vger.kernel.org \
--cc=qi.wang@intel.com \
--cc=sameo@linux.intel.com \
--cc=socketcan-core@lists.berlios.de \
--cc=tomoya-linux@dsn.okisemi.com \
--cc=w.sang@pengutronix.de \
--cc=yong.y.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.