From: Wolfgang Grandegger <wg@grandegger.com>
To: "j.p.lammertink" <j.p.lammertink@kubicas.com>
Cc: linux-can@vger.kernel.org
Subject: Re: Losing CAN messages with socket-CAN
Date: Sun, 07 Apr 2013 15:13:27 +0200 [thread overview]
Message-ID: <516170F7.5040400@grandegger.com> (raw)
In-Reply-To: <20130405133140.17A179B5161E0@bmail04.one.com>
Hi Jeroen,
On 04/05/2013 03:31 PM, j.p.lammertink wrote:
> Hi Wolfgang,
>
> Thanks for your response. Still working just before midnight ...
> Unfortunatelly it doesn't work yet.
> I've collected test results and pasted them below.
>
> Best Regards,
>
> Jeroen Lammertink
>
> --------------------------------------------------------------------------
...
> <>Can you tell me which sources I should look for? (Probably I've downloaded them
> <>already, but I wish to replace only the files that make the difference)
>
> < I think that patch 1/7 of the series may already fix your TX problems:
>
> < http://marc.info/?l=linux-can&m=135526076021515&w=2
> < ´
> < If you apply the remaining patches, you can select the "c_can_pci"
> < driver. If you get trouble with these patches I need to adapt them to a
> < more recent kernel version.
>
> My colleage has applied the patch you mentioned above. The patching was
> straightforward without any problems. Also building went fine (->pch_can.ko).
> I've installed the module with:
> sudo rmmod pch_can
> sudo insmod pch_can.ko
What kernel version did you finally use? Could you show your pch_can.c?
> Unfortunatelly, running the test application resulted in an assert. To obtain
> additional information I addapted the function CCanPort::Write() (See below).
> Running gave the following result:
>
> write returned -1
> errno = 64
> CCanPort.cpp[116]: ASSERT(ret == sizeof(*pFrame)) FAILED
>
> The errno 64 is not mentioned in man write
> #define ENONET 64 /* Machine is not on the network */
Hm, I'm also puzzled where this errno comes from? If you send a lot of
messages without delay I would expect an errno ENOBUFS. Could you please
handle the error code properly. In case of an ENOBUF errno just sleep
for a shot time (e.g. usleep(10000)) and then retry.
> At the end of this E-mail I've also included messages of dmesg.
>
> Do you recognize these errors?
See above.
> Should we continue with the pch_can driver and also apply remaining patches,
> or should we switch to c_can?
Probably yes. I do not really want to care about the pch_can driver.
> <><>--------------------------------------------------------------------------
>
> <><>size_t CCanPort::Write(can_frame *pFrame)
> <><>{
> <><> ssize_t ret = write(m_Sock, pFrame, sizeof(*pFrame));
> <><> ASSERT(ret == sizeof(*pFrame));
> <><> return ret;
> <><>}
>
> <><>CCanPort::CCanPort()
> <><>{
> <><> int rcvbuf_size = BUFFER_SIZE;
>
> <><> m_Sock = socket( PF_CAN, SOCK_RAW, CAN_RAW );
>
> <><> struct ifreq ifr;
> <><> strcpy(ifr.ifr_name, "can0");
> <><> ioctl(m_Sock, SIOCGIFINDEX, &ifr);
>
> <><> struct sockaddr_can addr;
> <><> addr.can_family = AF_CAN;
> <><> addr.can_ifindex = ifr.ifr_ifindex;
>
> <><> // Set receive buffer size
> <><> setsockopt(m_Sock, SOL_SOCKET, SO_RCVBUF, &rcvbuf_size, sizeof(rcvbuf_size));
>
> <><> // Bind
> <><> bind( m_Sock, (struct sockaddr*)&addr, sizeof(addr) );
> <><>}
>
> --------------------------------------------------------------------------
>
> size_t CCanPort::Write(can_frame *pFrame)
> {
> ssize_t ret = write(m_Sock, pFrame, sizeof(*pFrame));
>
> switch(ret)
> {
> case 0:
> std::cout << "write return 0" << std::endl;
> break;
> case -1:
> std::cout << "write returned -1" << std::endl;
> switch(errno)
> {
> case EAGAIN:
> std::cout << "errno = EAGAIN (=EWOULDBLOCK)" << std::endl;
> break;
> case EBADF:
> std::cout << "errno = EBADF" << std::endl;
> break;
> case EDESTADDRREQ:
> std::cout << "errno = EDESTADDRREQ" << std::endl;
> break;
> case EFAULT:
> std::cout << "errno = EFAULT" << std::endl;
> break;
> case EFBIG:
> std::cout << "errno = EFBIG" << std::endl;
> break;
> case EINTR:
> std::cout << "errno = EINTR" << std::endl;
> break;
> case EINVAL:
> std::cout << "errno = EINVAL" << std::endl;
> break;
> case EIO:
> std::cout << "errno = EIO" << std::endl;
> break;
> case ENOSPC:
> std::cout << "errno = ENOSPC" << std::endl;
> break;
> case EPIPE:
> std::cout << "errno = EPIPE" << std::endl;
> break;
> default:
> std::cout << "errno = " << errno << std::endl;
> break;
> }
> break;
> default:
> std::cout << "write returned " << ret << std::endl;
> };
>
> ASSERT(ret == sizeof(*pFrame));
> return ret;
> }
>
> --------------------------------------------------------------------------
>
> bmterra@q7buntu:~/user/jla$ dmesg | grep can
> [ 0.181560] [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
> [ 1.316862] isapnp: Scanning for PnP cards...
> [ 2.885786] rtc_cmos 00:08: RTC can wake from S4
> [ 11.119391] pch_can 0000:02:0c.3: irq 47 for MSI/MSI-X
> [ 11.119435] pch_can 0000:02:0c.3: (unregistered net_device): PCH CAN opened with MSI
> [ 11.119537] pch_can 0000:02:0c.3: setting latency timer to 64
> [ 635.622115] can: controller area network core (rev 20090105 abi 8)
> [ 635.628256] can: raw protocol (rev 20090105)
> [ 660.069395] pch_can 0000:02:0c.3: can0: can_put_echo_skb: BUG! echo_skb is occupied!
> [ 660.069561] pch_can 0000:02:0c.3: can0: can_put_echo_skb: BUG! echo_skb is occupied!
> [ 660.069583] pch_can 0000:02:0c.3: can0: can_put_echo_skb: BUG! echo_skb is occupied!
> [ 660.069602] pch_can 0000:02:0c.3: can0: can_put_echo_skb: BUG! echo_skb is occupied!
> [ 660.069622] pch_can 0000:02:0c.3: can0: can_put_echo_skb: BUG! echo_skb is occupied!
> [ 660.069641] pch_can 0000:02:0c.3: can0: can_put_echo_skb: BUG! echo_skb is occupied!
These are real problems. Did you see them without the patch as well?
Wolfgang.
next prev parent reply other threads:[~2013-04-07 13:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-05 13:31 Losing CAN messages with socket-CAN j.p.lammertink
2013-04-07 13:13 ` Wolfgang Grandegger [this message]
2013-04-07 21:05 ` Kurt Van Dijck
-- strict thread matches above, loose matches on Subject: below --
2013-04-24 9:11 j.p.lammertink
2013-04-24 10:59 ` Wolfgang Grandegger
2013-04-18 10:34 j.p.lammertink
2013-04-08 14:43 j.p.lammertink
2013-04-04 16:16 j.p.lammertink
2013-04-04 21:12 ` Wolfgang Grandegger
2013-04-04 14:44 j.p.lammertink
2013-04-04 15:11 ` Wolfgang Grandegger
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=516170F7.5040400@grandegger.com \
--to=wg@grandegger.com \
--cc=j.p.lammertink@kubicas.com \
--cc=linux-can@vger.kernel.org \
/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.