Re: CAN State Information

Re: CAN State Information

[Wolfgang Grandegger]

Hello,

On 12/06/2011 02:56 PM, kime-Z4QKGCRq86k@public.gmane.org wrote:
> Hello,
> 
> I am using socketcan with a combination of 3 passive plx cards (1 dual channel and 2 single channel) on kernel 3.0.0-13.  I have the libsocketcan-0.0.8 installed as well. I can use all 4 CAN channels but for some reason I can only use can_get_state() with the two single cards and the dual card returns -1 for both channels.  I have attempted another setup this time with just the two single cards and when I use the can_get_state() I am able to only return the state on 1 of them. Then I attempted putting in the dual card alone and the same result, one channel works the other does not. 

Hm, if "ip -d -s link" lists the state correctly, then it's most likely
a problem with libsocketcan. Anyway, for what purpose would you like to
use can_get_state()? It's not forseen for frequent polling of the CAN
error state. Please use error messages instead.

> I would appreciate any advice, this seems like a strange problem to me. 

What Socket-CAN driver are you using for the IXXAT cards? There is still
no support in mainline Linux, IIRC. Maybe there is some mismatch with
the header files.

Hope it helps.

Wolfgang.

PS: I added our new mailing list linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org to the CC.
    BerliOS will be closed end of the year.


> Mit freundlichen Grüssen / Yours sincerely,
> 
> James Kime
> Entwicklung / Development
> --------------------------------------------
> IXXAT Automation GmbH
> Leibnizstr. 15, 88250 Weingarten, Germany
> Phone +49-751-56146-181
> Fax   +49-751-56146-29
> mailto:kime-Z4QKGCRq86k@public.gmane.org
> http://www.ixxat.de
> --------------------------------------------
> PRIVILEGED AND CONFIDENTIAL.
> Any unauthorized use or disclosure
> is strictly prohibited.

Please drop these lines when you send to a public mailing list.

Re: CAN State Information

[Wolfram Sang]

[-- Attachment #1.1: Type: text/plain, Size: 381 bytes --]

> PS: I added our new mailing list linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org to the CC.
>     BerliOS will be closed end of the year.

FYI, maybe not: http://developer.berlios.de/forum/forum.php?forum_id=37533

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 188 bytes --]

_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core

RE: CAN State Information

[kime-Z4QKGCRq86k]

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

Hello,
Thanks for the response.  I am using can_get_state() as part of my start_CAN routine.  After, I call can_do_start(), I read the state to see if I need to do bus-off recovery.  So it is not a frequent call.  I was able to see the states correctly on all four CAN channels with "ip -d -s link".  

I updated the code in plx_pci.c to include support for the IXXAT card.  I wanted to ask you how to submit the changes since I have not done it before.  I attached a patch file.


Mit freundlichen Grüssen / Yours sincerely,

James Kime
Entwicklung / Development
--------------------------------------------
IXXAT Automation GmbH
Leibnizstr. 15, 88250 Weingarten, Germany
Phone +49-751-56146-181
Fax   +49-751-56146-29
mailto:kime-Z4QKGCRq86k@public.gmane.org
http://www.ixxat.de
--------------------------------------------
PRIVILEGED AND CONFIDENTIAL.
Any unauthorized use or disclosure
is strictly prohibited.
--------------------------------------------
Sitz der Gesellschaft: Weingarten
Handelsregister Ulm HRB 551905
Geschäftsführer:
Dipl.-Ing. Christian Schlegel
--------------------------------------------

-----Original Message-----
From: Wolfgang Grandegger [mailto:wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org] 
Sent: Tuesday, December 06, 2011 4:27 PM
To: Kime, James
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org; linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: CAN State Information

Hello,

On 12/06/2011 02:56 PM, kime-Z4QKGCRq86k@public.gmane.org wrote:
> Hello,
> 
> I am using socketcan with a combination of 3 passive plx cards (1 dual channel and 2 single channel) on kernel 3.0.0-13.  I have the libsocketcan-0.0.8 installed as well. I can use all 4 CAN channels but for some reason I can only use can_get_state() with the two single cards and the dual card returns -1 for both channels.  I have attempted another setup this time with just the two single cards and when I use the can_get_state() I am able to only return the state on 1 of them. Then I attempted putting in the dual card alone and the same result, one channel works the other does not. 

Hm, if "ip -d -s link" lists the state correctly, then it's most likely
a problem with libsocketcan. Anyway, for what purpose would you like to
use can_get_state()? It's not forseen for frequent polling of the CAN
error state. Please use error messages instead.

> I would appreciate any advice, this seems like a strange problem to me. 

What Socket-CAN driver are you using for the IXXAT cards? There is still
no support in mainline Linux, IIRC. Maybe there is some mismatch with
the header files.

Hope it helps.

Wolfgang.

PS: I added our new mailing list linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org to the CC.
    BerliOS will be closed end of the year.


> Mit freundlichen Grüssen / Yours sincerely,
> 
> James Kime
> Entwicklung / Development
> --------------------------------------------
> IXXAT Automation GmbH
> Leibnizstr. 15, 88250 Weingarten, Germany
> Phone +49-751-56146-181
> Fax   +49-751-56146-29
> mailto:kime-Z4QKGCRq86k@public.gmane.org
> http://www.ixxat.de
> --------------------------------------------
> PRIVILEGED AND CONFIDENTIAL.
> Any unauthorized use or disclosure
> is strictly prohibited.

Please drop these lines when you send to a public mailing list.

[-- Attachment #2: plx_pci_patch --]
[-- Type: application/octet-stream, Size: 1528 bytes --]

diff -Naur old/plx_pci.c new/plx_pci.c
--- old/plx_pci.c	2011-07-22 04:17:23.000000000 +0200
+++ new/plx_pci.c	2011-12-08 09:32:39.696774502 +0100
@@ -43,7 +43,8 @@
 			"TEWS TECHNOLOGIES TPMC810, "
 			"esd CAN-PCI/CPCI/PCI104/200, "
 			"esd CAN-PCI/PMC/266, "
-			"esd CAN-PCIe/2000")
+			"esd CAN-PCIe/2000, "
+			"IXXAT PC-I 04/PCI")
 MODULE_LICENSE("GPL v2");
 
 #define PLX_PCI_MAX_CHAN 2
@@ -121,6 +122,10 @@
 #define ESD_PCI_SUB_SYS_ID_PCIE2000	0x0200
 #define ESD_PCI_SUB_SYS_ID_PCI104200	0x0501
 
+#define IXXAT_PCI_VENDOR_ID		0x10b5
+#define IXXAT_PCI_DEVICE_ID		0x9050
+#define IXXAT_PCI_SUB_SYS_ID		0x2540
+
 #define MARATHON_PCI_DEVICE_ID		0x2715
 
 #define TEWS_PCI_VENDOR_ID		0x1498
@@ -193,6 +198,14 @@
 	/* based on PEX8311 */
 };
 
+static struct plx_pci_card_info plx_pci_card_info_ixxat __devinitdata = {
+	"IXXAT PC-I 04/PCI", 2,
+	PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
+	{0, 0x00, 0x00}, { {2, 0x00, 0x80}, {2, 0x200, 0x80} },
+	&plx_pci_reset_common
+	/* based on PLX9050 */
+};
+
 static struct plx_pci_card_info plx_pci_card_info_marathon __devinitdata = {
 	"Marathon CAN-bus-PCI", 2,
 	PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
@@ -267,6 +280,13 @@
 		(kernel_ulong_t)&plx_pci_card_info_esd2000
 	},
 	{
+		/* IXXAT PC-I 04/PCI card */
+		IXXAT_PCI_VENDOR_ID, IXXAT_PCI_DEVICE_ID,
+		PCI_ANY_ID, IXXAT_PCI_SUB_SYS_ID,
+		0, 0,
+		(kernel_ulong_t)&plx_pci_card_info_ixxat
+	},
+	{
 		/* Marathon CAN-bus-PCI card */
 		PCI_VENDOR_ID_PLX, MARATHON_PCI_DEVICE_ID,
 		PCI_ANY_ID, PCI_ANY_ID,


[-- Attachment #3: Type: text/plain, Size: 188 bytes --]

_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core

Re: CAN State Information

[Wolfgang Grandegger]

Hello James,

On 12/08/2011 09:43 AM, kime-Z4QKGCRq86k@public.gmane.org wrote:
> Hello,
> Thanks for the response.  I am using can_get_state() as part of my start_CAN routine.  After, I call can_do_start(), I read the state to see if I need to do bus-off recovery.  So it is not a frequent call.  I was able to see the states correctly on all four CAN channels with "ip -d -s link".  

OK, just to be sure. Does the "canconfig canX state" from the
Pengutronix canutils list the state correctly for any device?
I just tried here and it works fine.

> I updated the code in plx_pci.c to include support for the IXXAT card.  I wanted to ask you how to submit the changes since I have not done it before.  I attached a patch file.

Nice! A patch should be submitted as *inline* mail to the linux-can
*and* netdev mailing list with a proper subject, patch description and
signed-off-by line. The subject line should be something like:

"[PATCH net-next] can: plx_pci: add support for IXXAT PCI cards"

It's best to use git to create and send the patch but for simple patches
it doesn't really matter.

Wolfgang.

RE: CAN State Information

[kime]

I plan to spend some time today tracking down the problem.  I am most curious to discover if there is a problem in the msg returned from send_dump_request(). 

$ sudo ./canconfig can0 state
can0 state: STOPPED
$ sudo ./canconfig can1 state
can1 state: STOPPED
$ sudo ./canconfig can2 state
can2: failed to get state 
$ sudo ./canconfig can3 state
can3: failed to get state 
$ ip -d -s link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    RX: bytes  packets  errors  dropped overrun mcast   
    500        8        0       0       0       0      
    TX: bytes  packets  errors  dropped carrier collsns 
    500        8        0       0       0       0      
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:11:2f:72:cc:4d brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast   
    997317     7091     0       0       0       2      
    TX: bytes  packets  errors  dropped carrier collsns 
    285592     3799     0       0       0       0      
3: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN qlen 10
    link/can 
    can state STOPPED (berr-counter tx 0 rx 0) restart-ms 0 
    bitrate 0 sample-point 0.000 
    tq 0 prop-seg 0 phase-seg1 0 phase-seg2 0 sjw 0
    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          0          0          0         
    RX: bytes  packets  errors  dropped overrun mcast   
    0          0        0       0       0       0      
    TX: bytes  packets  errors  dropped carrier collsns 
    0          0        0       0       0       0      
4: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN qlen 10
    link/can 
    can state STOPPED (berr-counter tx 0 rx 0) restart-ms 0 
    bitrate 0 sample-point 0.000 
    tq 0 prop-seg 0 phase-seg1 0 phase-seg2 0 sjw 0
    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          0          0          0         
    RX: bytes  packets  errors  dropped overrun mcast   
    0          0        0       0       0       0      
    TX: bytes  packets  errors  dropped carrier collsns 
    0          0        0       0       0       0      
5: can2: <NOARP,ECHO> mtu 16 qdisc noop state DOWN qlen 10
    link/can 
    can state STOPPED (berr-counter tx 0 rx 0) restart-ms 0 
    bitrate 0 sample-point 0.000 
    tq 0 prop-seg 0 phase-seg1 0 phase-seg2 0 sjw 0
    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          0          0          0         
    RX: bytes  packets  errors  dropped overrun mcast   
    0          0        0       0       0       0      
    TX: bytes  packets  errors  dropped carrier collsns 
    0          0        0       0       0       0      
6: can3: <NOARP,ECHO> mtu 16 qdisc noop state DOWN qlen 10
    link/can 
    can state STOPPED (berr-counter tx 0 rx 0) restart-ms 0 
    bitrate 0 sample-point 0.000 
    tq 0 prop-seg 0 phase-seg1 0 phase-seg2 0 sjw 0
    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          0          0          0         
    RX: bytes  packets  errors  dropped overrun mcast   
    0          0        0       0       0       0      
    TX: bytes  packets  errors  dropped carrier collsns 
    0          0        0       0       0       0      

Mit freundlichen Grüssen / Yours sincerely,

James Kime
Entwicklung / Development
--------------------------------------------
IXXAT Automation GmbH
Leibnizstr. 15, 88250 Weingarten, Germany
Phone +49-751-56146-181
Fax   +49-751-56146-29
mailto:kime@ixxat.de
http://www.ixxat.de
--------------------------------------------
PRIVILEGED AND CONFIDENTIAL.
Any unauthorized use or disclosure
is strictly prohibited.
--------------------------------------------
Sitz der Gesellschaft: Weingarten
Handelsregister Ulm HRB 551905
Geschäftsführer:
Dipl.-Ing. Christian Schlegel
--------------------------------------------

-----Original Message-----
From: Wolfgang Grandegger [mailto:wg@grandegger.com] 
Sent: Thursday, December 08, 2011 8:15 PM
To: Kime, James
Cc: socketcan-core@lists.berlios.de; linux-can@vger.kernel.org
Subject: Re: CAN State Information

Hello James,

On 12/08/2011 09:43 AM, kime@ixxat.de wrote:
> Hello,
> Thanks for the response.  I am using can_get_state() as part of my start_CAN routine.  After, I call can_do_start(), I read the state to see if I need to do bus-off recovery.  So it is not a frequent call.  I was able to see the states correctly on all four CAN channels with "ip -d -s link".  

OK, just to be sure. Does the "canconfig canX state" from the
Pengutronix canutils list the state correctly for any device?
I just tried here and it works fine.

> I updated the code in plx_pci.c to include support for the IXXAT card.  I wanted to ask you how to submit the changes since I have not done it before.  I attached a patch file.

Nice! A patch should be submitted as *inline* mail to the linux-can
*and* netdev mailing list with a proper subject, patch description and
signed-off-by line. The subject line should be something like:

"[PATCH net-next] can: plx_pci: add support for IXXAT PCI cards"

It's best to use git to create and send the patch but for simple patches
it doesn't really matter.

Wolfgang.

Re: CAN State Information

[Wolfgang Grandegger]

On 12/09/2011 09:03 AM, kime-Z4QKGCRq86k@public.gmane.org wrote:
> I plan to spend some time today tracking down the problem.  I am most curious to discover if there is a problem in the msg returned from send_dump_request(). 
> 
> $ sudo ./canconfig can0 state
> can0 state: STOPPED
> $ sudo ./canconfig can1 state
> can1 state: STOPPED
> $ "
> can2: failed to get state 
> $ sudo ./canconfig can3 state
> can3: failed to get state 

OK, what does strace tell you. Is there a system call failing with "-1"?
Also ftrace could give some hint (assuming that ftrace and function
tracing is enabled in you kernel):

  # mount -tdebugfs none /sys/kernel/debug/
  # cd /sys/kernel/debug/tracing/
  # echo function > current_tracer
  # echo "can_*" >  set_ftrace_filter
  # cat set_ftrace_filter
  # echo 0 > trace

What does /sys/kernel/debug/tracing/trace list after calling "sudo
./canconfig can2 state"?

Wolfgang.

Re: CAN State Information

[Wolfgang Grandegger]

On 12/09/2011 09:15 AM, Wolfgang Grandegger wrote:
> On 12/09/2011 09:03 AM, kime-Z4QKGCRq86k@public.gmane.org wrote:
>> I plan to spend some time today tracking down the problem.  I am most curious to discover if there is a problem in the msg returned from send_dump_request(). 
>>
>> $ sudo ./canconfig can0 state
>> can0 state: STOPPED
>> $ sudo ./canconfig can1 state
>> can1 state: STOPPED
>> $ "
>> can2: failed to get state 
>> $ sudo ./canconfig can3 state
>> can3: failed to get state 
> 
> OK, what does strace tell you. Is there a system call failing with "-1"?
> Also ftrace could give some hint (assuming that ftrace and function
> tracing is enabled in you kernel):
> 
>   # mount -tdebugfs none /sys/kernel/debug/
>   # cd /sys/kernel/debug/tracing/
>   # echo function > current_tracer
>   # echo "can_*" >  set_ftrace_filter
>   # cat set_ftrace_filter
>   # echo 0 > trace

    # echo 1 > tracing_on

might also be necessary (usually it on by default).

Wolfgang.

RE: CAN State Information

[kime-Z4QKGCRq86k]

I am new to using trace, but I think this is the output you are looking for: 

       canconfig-3288  [000]  3756.129866: can_vma_merge_before <-vma_merge
       canconfig-3288  [000]  3756.130035: can_vma_merge_before <-vma_merge
       canconfig-3288  [000]  3756.130116: can_vma_merge_before <-vma_merge
       canconfig-3288  [000]  3756.130234: can_vma_merge_before <-vma_merge
       canconfig-3288  [000]  3756.130366: can_vma_merge_before <-vma_merge
       canconfig-3288  [000]  3756.148522: can_vma_merge_before <-vma_merge
       canconfig-3288  [000]  3756.162588: can_vma_merge_before <-vma_merge
       canconfig-3288  [000]  3756.162641: can_vma_merge_before <-vma_merge
       canconfig-3288  [000]  3756.162653: can_vma_merge_before <-vma_merge
       canconfig-3288  [000]  3756.163033: can_fill_xstats <-rtnl_link_fill
       canconfig-3288  [000]  3756.163034: can_fill_info <-rtnl_link_fill
       canconfig-3288  [000]  3756.163041: can_fill_xstats <-rtnl_link_fill
       canconfig-3288  [000]  3756.163042: can_fill_info <-rtnl_link_fill
       canconfig-3288  [000]  3756.163047: can_fill_xstats <-rtnl_link_fill
       canconfig-3288  [000]  3756.163048: can_fill_info <-rtnl_link_fill
       canconfig-3288  [000]  3756.163066: can_fill_xstats <-rtnl_link_fill
       canconfig-3288  [000]  3756.163067: can_fill_info <-rtnl_link_fill
       canconfig-3288  [000]  3756.163073: can_fill_xstats <-rtnl_link_fill
       canconfig-3288  [000]  3756.163073: can_fill_info <-rtnl_link_fill

Mit freundlichen Grüssen / Yours sincerely,

James Kime
Entwicklung / Development
--------------------------------------------
IXXAT Automation GmbH
Leibnizstr. 15, 88250 Weingarten, Germany
Phone +49-751-56146-181
Fax   +49-751-56146-29
mailto:kime-Z4QKGCRq86k@public.gmane.org
http://www.ixxat.de
--------------------------------------------
PRIVILEGED AND CONFIDENTIAL.
Any unauthorized use or disclosure
is strictly prohibited.
--------------------------------------------
Sitz der Gesellschaft: Weingarten
Handelsregister Ulm HRB 551905
Geschäftsführer:
Dipl.-Ing. Christian Schlegel
--------------------------------------------


-----Original Message-----
From: Wolfgang Grandegger [mailto:wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org] 
Sent: Friday, December 09, 2011 9:19 AM
To: Kime, James
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org; linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: CAN State Information

On 12/09/2011 09:15 AM, Wolfgang Grandegger wrote:
> On 12/09/2011 09:03 AM, kime-Z4QKGCRq86k@public.gmane.org wrote:
>> I plan to spend some time today tracking down the problem.  I am most curious to discover if there is a problem in the msg returned from send_dump_request(). 
>>
>> $ sudo ./canconfig can0 state
>> can0 state: STOPPED
>> $ sudo ./canconfig can1 state
>> can1 state: STOPPED
>> $ "
>> can2: failed to get state 
>> $ sudo ./canconfig can3 state
>> can3: failed to get state 
> 
> OK, what does strace tell you. Is there a system call failing with "-1"?
> Also ftrace could give some hint (assuming that ftrace and function
> tracing is enabled in you kernel):
> 
>   # mount -tdebugfs none /sys/kernel/debug/
>   # cd /sys/kernel/debug/tracing/
>   # echo function > current_tracer
>   # echo "can_*" >  set_ftrace_filter
>   # cat set_ftrace_filter
>   # echo 0 > trace

    # echo 1 > tracing_on

might also be necessary (usually it on by default).

Wolfgang.

Re: CAN State Information

[Wolfgang Grandegger]

On 12/09/2011 09:45 AM, kime-Z4QKGCRq86k@public.gmane.org wrote:
> I am new to using trace, but I think this is the output you are looking for: 
> 
...
>        canconfig-3288  [000]  3756.163033: can_fill_xstats <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163034: can_fill_info <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163041: can_fill_xstats <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163042: can_fill_info <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163047: can_fill_xstats <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163048: can_fill_info <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163066: can_fill_xstats <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163067: can_fill_info <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163073: can_fill_xstats <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163073: can_fill_info <-rtnl_link_fill

Yep, I wanted to check if can_fill_info() is called at all. Actually,
can_fill_info() does not return an error code so what I can think off is
a mismatch in the data structure. What kernel CAN header files did you
use when building libsocketcan?

Next step would be to use "gdb" to find out where the error happend in
the code. Most errors while print an error message, though.

Wolfgang.

RE: CAN State Information

[kime]

I noticed that when libsocketcan calls send_dump_request() it returns a message for me that has a length of 3424 with recvmsg().  This is not the full message, if I add a loop into the routine to again receive, I receive a second message this time with a length of 1424.  I added some prints into the routine to output strings and sizes:

First read:
nl_msg:-1073753668  u_msglen:3424
lo
nl_msg:-1073752676  u_msglen:2432
eth0
nl_msg:-1073751668  u_msglen:1424
can0
nl_msg:-1073750956  u_msglen:712
can1

Second read:
nl_msg:-1073753668  u_msglen:1424
can2
nl_msg:-1073752956  u_msglen:712
can3

With this loop, it seems to work.  Does this make sense?

Mit freundlichen Grüssen / Yours sincerely,

James Kime
Entwicklung / Development
--------------------------------------------
IXXAT Automation GmbH
Leibnizstr. 15, 88250 Weingarten, Germany
Phone +49-751-56146-181
Fax   +49-751-56146-29
mailto:kime@ixxat.de
http://www.ixxat.de
--------------------------------------------
PRIVILEGED AND CONFIDENTIAL.
Any unauthorized use or disclosure
is strictly prohibited.
--------------------------------------------
Sitz der Gesellschaft: Weingarten
Handelsregister Ulm HRB 551905
Geschäftsführer:
Dipl.-Ing. Christian Schlegel
--------------------------------------------


-----Original Message-----
From: Wolfgang Grandegger [mailto:wg@grandegger.com] 
Sent: Friday, December 09, 2011 10:00 AM
To: Kime, James
Cc: socketcan-core@lists.berlios.de; linux-can@vger.kernel.org
Subject: Re: CAN State Information

On 12/09/2011 09:45 AM, kime@ixxat.de wrote:
> I am new to using trace, but I think this is the output you are looking for: 
> 
...
>        canconfig-3288  [000]  3756.163033: can_fill_xstats <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163034: can_fill_info <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163041: can_fill_xstats <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163042: can_fill_info <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163047: can_fill_xstats <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163048: can_fill_info <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163066: can_fill_xstats <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163067: can_fill_info <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163073: can_fill_xstats <-rtnl_link_fill
>        canconfig-3288  [000]  3756.163073: can_fill_info <-rtnl_link_fill

Yep, I wanted to check if can_fill_info() is called at all. Actually,
can_fill_info() does not return an error code so what I can think off is
a mismatch in the data structure. What kernel CAN header files did you
use when building libsocketcan?

Next step would be to use "gdb" to find out where the error happend in
the code. Most errors while print an error message, though.

Wolfgang.

Re: CAN State Information

[Wolfgang Grandegger]

On 12/09/2011 02:41 PM, kime@ixxat.de wrote:
> I noticed that when libsocketcan calls send_dump_request() it returns a message for me that has a length of 3424 with recvmsg().  This is not the full message, if I add a loop into the routine to again receive, I receive a second message this time with a length of 1424.  I added some prints into the routine to output strings and sizes:
> 
> First read:
> nl_msg:-1073753668  u_msglen:3424
> lo
> nl_msg:-1073752676  u_msglen:2432
> eth0
> nl_msg:-1073751668  u_msglen:1424
> can0
> nl_msg:-1073750956  u_msglen:712
> can1
> 
> Second read:
> nl_msg:-1073753668  u_msglen:1424
> can2
> nl_msg:-1073752956  u_msglen:712
> can3
> 
> With this loop, it seems to work.  Does this make sense?

Yes, could you send a patch (showing your modifications)?

Wolfgang.

RE: CAN State Information

[kime-Z4QKGCRq86k]

Here is the patch.  It polls for messages at the end of the loop and repeats if needed.

diff -Naur b/libsocketcan.c a/libsocketcan.c
--- b/libsocketcan.c	2010-02-14 20:22:15.000000000 +0100
+++ a/libsocketcan.c	2011-12-12 11:10:40.000000000 +0100
@@ -32,6 +32,7 @@
 
 #include <linux/rtnetlink.h>
 #include <linux/netlink.h>
+#include <poll.h>
 
 #include <libsocketcan.h>
 
@@ -322,6 +323,13 @@
 	char nlbuf[1024 * 8];
 
 	int ret = -1;
+	int repeat = 0;
+
+	struct pollfd poll_msg = {
+		.fd = fd,
+		.events = 0x0001,
+		.revents = 0,
+	};
 
 	struct iovec iov = {
 		.iov_base = (void *)nlbuf,
@@ -352,126 +360,142 @@
 		perror("Receive error");
 		return ret;
 	}
-	size_t u_msglen = (size_t) msglen;
-	/* Check to see if the buffers in msg get truncated */
-	if (msg.msg_namelen != sizeof(peer) ||
-	    (msg.msg_flags & (MSG_TRUNC | MSG_CTRUNC))) {
-		fprintf(stderr, "Uhoh... truncated message.\n");
-		return ret;
-	}
-
-	for (nl_msg = (struct nlmsghdr *)nlbuf;
-	     NLMSG_OK(nl_msg, u_msglen);
-	     nl_msg = NLMSG_NEXT(nl_msg, u_msglen)) {
-		int type = nl_msg->nlmsg_type;
-		int len;
-		if (type != RTM_NEWLINK)
-			continue;
-
-		struct ifinfomsg *ifi = NLMSG_DATA(nl_msg);
-		struct rtattr *tb[IFLA_MAX + 1];
-
-		len =
-		    nl_msg->nlmsg_len - NLMSG_LENGTH(sizeof(struct ifaddrmsg));
-		parse_rtattr(tb, IFLA_MAX, IFLA_RTA(ifi), len);
-
-		if (strncmp
-		    ((char *)RTA_DATA(tb[IFLA_IFNAME]), name,
-		     sizeof(name)) != 0)
-			continue;
-
-		if (tb[IFLA_LINKINFO])
-			parse_rtattr_nested(linkinfo,
-					    IFLA_INFO_MAX, tb[IFLA_LINKINFO]);
-		else
-			continue;
 
-		if (!linkinfo[IFLA_INFO_DATA]) {
-			fprintf(stderr, "no link data found\n");
+    while(repeat == 0){
+		size_t u_msglen = (size_t) msglen;
+		/* Check to see if the buffers in msg get truncated */
+		if (msg.msg_namelen != sizeof(peer) ||
+			(msg.msg_flags & (MSG_TRUNC | MSG_CTRUNC))) {
+			fprintf(stderr, "Uhoh... truncated message.\n");
 			return ret;
 		}
 
-		parse_rtattr_nested(can_attr, IFLA_CAN_MAX,
-				    linkinfo[IFLA_INFO_DATA]);
-
-		switch (acquire) {
-		case GET_STATE:
-			if (can_attr[IFLA_CAN_STATE]) {
-				*((int *)res) = *((__u32 *)
-						  RTA_DATA(can_attr
-							   [IFLA_CAN_STATE]));
-				ret = 0;
-			} else {
-				fprintf(stderr, "no state data found\n");
+		for (nl_msg = (struct nlmsghdr *)nlbuf;
+			NLMSG_OK(nl_msg, u_msglen);
+			nl_msg = NLMSG_NEXT(nl_msg, u_msglen)) {
+
+			int type = nl_msg->nlmsg_type;
+			int len;
+			if (type != RTM_NEWLINK)
+				continue;
+
+
+			struct ifinfomsg *ifi = NLMSG_DATA(nl_msg);
+			struct rtattr *tb[IFLA_MAX + 1];
+
+			len =
+				nl_msg->nlmsg_len - NLMSG_LENGTH(sizeof(struct ifaddrmsg));
+			parse_rtattr(tb, IFLA_MAX, IFLA_RTA(ifi), len);
+
+			if (strncmp
+				((char *)RTA_DATA(tb[IFLA_IFNAME]), name,
+				 sizeof(name)) != 0) {
+				continue;
+			}
+			if (tb[IFLA_LINKINFO])
+				parse_rtattr_nested(linkinfo,
+							IFLA_INFO_MAX, tb[IFLA_LINKINFO]);
+			else
+				continue;
+
+			if (!linkinfo[IFLA_INFO_DATA]) {
+				fprintf(stderr, "no link data found\n");
+				return ret;
 			}
 
-			break;
-		case GET_RESTART_MS:
-			if (can_attr[IFLA_CAN_RESTART_MS]) {
-				*((__u32 *) res) = *((__u32 *)
-						     RTA_DATA(can_attr
-							      [IFLA_CAN_RESTART_MS]));
-				ret = 0;
-			} else
-				fprintf(stderr, "no restart_ms data found\n");
-
-			break;
-		case GET_BITTIMING:
-			if (can_attr[IFLA_CAN_BITTIMING]) {
-				memcpy(res,
-				       RTA_DATA(can_attr[IFLA_CAN_BITTIMING]),
-				       sizeof(struct can_bittiming));
-				ret = 0;
-			} else
-				fprintf(stderr, "no bittiming data found\n");
-
-			break;
-		case GET_CTRLMODE:
-			if (can_attr[IFLA_CAN_CTRLMODE]) {
-				memcpy(res,
-				       RTA_DATA(can_attr[IFLA_CAN_CTRLMODE]),
-				       sizeof(struct can_ctrlmode));
-				ret = 0;
-			} else
-				fprintf(stderr, "no ctrlmode data found\n");
-
-			break;
-		case GET_CLOCK:
-			if (can_attr[IFLA_CAN_CLOCK]) {
-				memcpy(res,
-				       RTA_DATA(can_attr[IFLA_CAN_CLOCK]),
-				       sizeof(struct can_clock));
-				ret = 0;
-			} else
-				fprintf(stderr,
-					"no clock parameter data found\n");
+			parse_rtattr_nested(can_attr, IFLA_CAN_MAX,
+						linkinfo[IFLA_INFO_DATA]);
+
+			switch (acquire) {
+			case GET_STATE:
+				if (can_attr[IFLA_CAN_STATE]) {
+					*((int *)res) = *((__u32 *)
+							  RTA_DATA(can_attr
+								   [IFLA_CAN_STATE]));
+					ret = 0;
+				} else {
+					fprintf(stderr, "no state data found\n");
+				}
 
-			break;
-		case GET_BITTIMING_CONST:
-			if (can_attr[IFLA_CAN_BITTIMING_CONST]) {
-				memcpy(res,
-				       RTA_DATA(can_attr[IFLA_CAN_BITTIMING_CONST]),
-				       sizeof(struct can_bittiming_const));
-				ret = 0;
-			} else
-				fprintf(stderr, "no bittiming_const data found\n");
-
-			break;
-		case GET_BERR_COUNTER:
-			if (can_attr[IFLA_CAN_BERR_COUNTER]) {
-				memcpy(res,
-				       RTA_DATA(can_attr[IFLA_CAN_BERR_COUNTER]),
-				       sizeof(struct can_berr_counter));
-				ret = 0;
-			} else
-				fprintf(stderr, "no berr_counter data found\n");
+				break;
+			case GET_RESTART_MS:
+				if (can_attr[IFLA_CAN_RESTART_MS]) {
+					*((__u32 *) res) = *((__u32 *)
+								 RTA_DATA(can_attr
+									  [IFLA_CAN_RESTART_MS]));
+					ret = 0;
+				} else
+					fprintf(stderr, "no restart_ms data found\n");
+
+				break;
+			case GET_BITTIMING:
+				if (can_attr[IFLA_CAN_BITTIMING]) {
+					memcpy(res,
+						   RTA_DATA(can_attr[IFLA_CAN_BITTIMING]),
+						   sizeof(struct can_bittiming));
+					ret = 0;
+				} else
+					fprintf(stderr, "no bittiming data found\n");
+
+				break;
+			case GET_CTRLMODE:
+				if (can_attr[IFLA_CAN_CTRLMODE]) {
+					memcpy(res,
+						   RTA_DATA(can_attr[IFLA_CAN_CTRLMODE]),
+						   sizeof(struct can_ctrlmode));
+					ret = 0;
+				} else
+					fprintf(stderr, "no ctrlmode data found\n");
+
+				break;
+			case GET_CLOCK:
+				if (can_attr[IFLA_CAN_CLOCK]) {
+					memcpy(res,
+						   RTA_DATA(can_attr[IFLA_CAN_CLOCK]),
+						   sizeof(struct can_clock));
+					ret = 0;
+				} else
+					fprintf(stderr,
+						"no clock parameter data found\n");
+
+				break;
+			case GET_BITTIMING_CONST:
+				if (can_attr[IFLA_CAN_BITTIMING_CONST]) {
+					memcpy(res,
+						   RTA_DATA(can_attr[IFLA_CAN_BITTIMING_CONST]),
+						   sizeof(struct can_bittiming_const));
+					ret = 0;
+				} else
+					fprintf(stderr, "no bittiming_const data found\n");
+
+				break;
+			case GET_BERR_COUNTER:
+				if (can_attr[IFLA_CAN_BERR_COUNTER]) {
+					memcpy(res,
+						   RTA_DATA(can_attr[IFLA_CAN_BERR_COUNTER]),
+						   sizeof(struct can_berr_counter));
+					ret = 0;
+				} else
+					fprintf(stderr, "no berr_counter data found\n");
 
-			break;
+				break;
 
-		default:
-			fprintf(stderr, "unknown acquire mode\n");
+			default:
+				fprintf(stderr, "unknown acquire mode\n");
+			}
 		}
-	}
+
+		if((poll(&poll_msg,1,1))>0) {
+			msglen = recvmsg(fd, &msg, 0);
+			if (msglen <= 0) {
+				perror("Receive error");
+				return -1;
+			}
+		}
+		else {
+			repeat = 1;
+		}
+	}  //while(repeat == 0)
 	return ret;
 }

Mit freundlichen Grüssen / Yours sincerely,

James Kime
Entwicklung / Development
--------------------------------------------
IXXAT Automation GmbH
Leibnizstr. 15, 88250 Weingarten, Germany
Phone +49-751-56146-181
Fax   +49-751-56146-29
mailto:kime-Z4QKGCRq86k@public.gmane.org
http://www.ixxat.de
--------------------------------------------
PRIVILEGED AND CONFIDENTIAL.
Any unauthorized use or disclosure
is strictly prohibited.
--------------------------------------------
Sitz der Gesellschaft: Weingarten
Handelsregister Ulm HRB 551905
Geschäftsführer:
Dipl.-Ing. Christian Schlegel
--------------------------------------------


-----Original Message-----
From: Wolfgang Grandegger [mailto:wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org] 
Sent: Friday, December 09, 2011 3:50 PM
To: Kime, James
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org; linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: CAN State Information

On 12/09/2011 02:41 PM, kime-Z4QKGCRq86k@public.gmane.org wrote:
> I noticed that when libsocketcan calls send_dump_request() it returns a message for me that has a length of 3424 with recvmsg().  This is not the full message, if I add a loop into the routine to again receive, I receive a second message this time with a length of 1424.  I added some prints into the routine to output strings and sizes:
> 
> First read:
> nl_msg:-1073753668  u_msglen:3424
> lo
> nl_msg:-1073752676  u_msglen:2432
> eth0
> nl_msg:-1073751668  u_msglen:1424
> can0
> nl_msg:-1073750956  u_msglen:712
> can1
> 
> Second read:
> nl_msg:-1073753668  u_msglen:1424
> can2
> nl_msg:-1073752956  u_msglen:712
> can3
> 
> With this loop, it seems to work.  Does this make sense?

Yes, could you send a patch (showing your modifications)?

Wolfgang.