Thread: [Linuxptp-users] Problems with hardware time stamping with PHY DP83640 on MCP5200 powerpc platform
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
From: Mario M. <Mar...@we...> - 2012-05-22 17:35:02
|
Hallo linuxptp members, I have some problems to use our PTP device (PHY DP83640 on MCP5200 powerpc platform). The software time stamping seems for the first look ok but the hardware time stamping have some problems. 1.) software time stamping: ==================== ptp4l[180]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[180]: port 1: new foreign master 0050c2.fffe.c2dfc3-1 ptp4l[180]: selected best master clock 0050c2.fffe.c2dfc3 ptp4l[180]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[180]: port 1: minimum delay request interval 2^3 ptp4l[180]: master offset 536296 s0 adj +0 path delay 116376 ptp4l[180]: master offset 546610 s0 adj +0 path delay 116376 ptp4l[180]: master offset 552398 s0 adj +0 path delay 116376 ptp4l[180]: master offset 597686 s1 adj +0 path delay 116376 ptp4l[180]: master offset 30287 s2 adj +3059 path delay 116376 ptp4l[180]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[180]: master offset 41825 s2 adj +4255 path delay 116376 ptp4l[180]: master offset 104402 s2 adj +10617 path delay 116376 ptp4l[180]: master offset 108479 s2 adj +11133 path delay 116376 ptp4l[180]: master offset 190504 s2 adj +19526 path delay 95604 ptp4l[180]: master offset 180213 s2 adj +18677 path delay 95604 ptp4l[180]: master offset 212836 s2 adj +22152 path delay 87573 ptp4l[180]: master offset 202140 s2 adj +21285 path delay 87573 ptp4l[180]: master offset 245722 s2 adj +25889 path delay 87573 ptp4l[180]: master offset 212369 s2 adj +22766 path delay 95802 ptp4l[180]: master offset 241451 s2 adj +25915 path delay 95802 ptp4l[180]: master offset 302218 s2 adj +32294 path delay 95802 ptp4l[180]: master offset 164231 s2 adj +18660 path delay 95802 ptp4l[180]: master offset 150769 s2 adj +17464 path delay 95724 It adjust only the system clock not PHY clock. 2.) hardware time stamping =================== ptp4l[183]: selected /dev/ptp0 as PTP clock ptp4l[183]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[183]: received SYNC without timestamp ptp4l[183]: port 1: bad message ptp4l[183]: port 1: new foreign master 0050c2.fffe.c2dfc3-1 ptp4l[183]: received SYNC without timestamp ptp4l[183]: port 1: bad message ptp4l[183]: received SYNC without timestamp ptp4l[183]: port 1: bad message ptp4l[183]: selected best master clock 0050c2.fffe.c2dfc3 ptp4l[183]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[183]: recvmsg tx timestamp failed: Resource temporarily unavailable ptp4l[183]: port 1: send delay request failed ptp4l[183]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED ptp4l[183]: port 1: FAULTY to LISTENING on FAULT_CLEARED ptp4l[183]: received SYNC without timestamp ptp4l[183]: port 1: bad message ptp4l[183]: port 1: new foreign master 0050c2.fffe.c2dfc3-1 ptp4l[183]: received SYNC without timestamp ptp4l[183]: port 1: bad message ptp4l[183]: received SYNC without timestamp ptp4l[183]: port 1: bad message ptp4l[183]: selected best master clock 0050c2.fffe.c2dfc3 ptp4l[183]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[183]: recvmsg tx timestamp failed: Resource temporarily unavailable ptp4l[183]: port 1: send delay request failed ptp4l[183]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED ptp4l[183]: port 1: FAULTY to LISTENING on FAULT_CLEARED ptp4l[183]: received SYNC without timestamp ptp4l[183]: port 1: bad message ptp4l[183]: port 1: new foreign master 0050c2.fffe.c2dfc3-1 ptp4l[183]: received SYNC without timestamp ptp4l[183]: port 1: bad message ptp4l[183]: received SYNC without timestamp ptp4l[183]: port 1: bad message ptp4l[183]: selected best master clock 0050c2.fffe.c2dfc3 ptp4l[183]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[183]: recvmsg tx timestamp failed: Resource temporarily unavailable ptp4l[183]: port 1: send delay request failed ptp4l[183]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED ptp4l[183]: port 1: FAULTY to LISTENING on FAULT_CLEARED ptp4l[183]: received SYNC without timestamp ptp4l[183]: port 1: bad message ptp4l[183]: port 1: new foreign master 0050c2.fffe.c2dfc3-1 ptp4l[183]: received SYNC without timestamp ptp4l[183]: port 1: bad message ptp4l[183]: received SYNC without timestamp ptp4l[183]: port 1: bad message ptp4l[183]: selected best master clock 0050c2.fffe.c2dfc3 ptp4l[183]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[183]: recvmsg tx timestamp failed: Resource temporarily unavailable ptp4l[183]: port 1: send delay request failed ptp4l[183]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED I used following linux version without any source changes for test of PTP: Linux version 3.4.0-rc7-next-20120514 with following options - CONFIG_EXPERIMENTAL - CONFIG_PPS - CONFIG_NETWORK_PHY_TIMESTAMPING - PTP_1588_CLOCKPTP I have at the moment no any idea what is wrong and I need help to figure out where the problem is. The other point is, I am not sure that the ptp4l support the DP83640 PHY. Please let me know how I can debug this problem e.g. with some printks in the kernel driver or adapt the ptp4l application. Best regards and many thanks for the help in advance, Mario Molitor |
|
From: Richard C. <ric...@gm...> - 2012-05-22 18:18:17
|
On Tue, May 22, 2012 at 07:34:55PM +0200, Mario Molitor wrote:
> Hallo linuxptp members,
>
> I have some problems to use our PTP device (PHY DP83640 on MCP5200 powerpc
^^^
(I think you mean MPC)
> platform).
I have never seen the combination MPC5200/DP83640. Is this a
commercial board or a custom design?
> 2.) hardware time stamping
> ===================
> ptp4l[183]: selected /dev/ptp0 as PTP clock
>
> ptp4l[183]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[183]: received SYNC without timestamp
> ptp4l[183]: port 1: bad message
> ptp4l[183]: port 1: new foreign master 0050c2.fffe.c2dfc3-1
> ptp4l[183]: received SYNC without timestamp
> ptp4l[183]: port 1: bad message
> ptp4l[183]: received SYNC without timestamp
> ptp4l[183]: port 1: bad message
Looks like no packets are being time stamped at all.
> I used following linux version without any source changes for test of PTP:
>
> Linux version 3.4.0-rc7-next-20120514
> with following options
> - CONFIG_EXPERIMENTAL
> - CONFIG_PPS
> - CONFIG_NETWORK_PHY_TIMESTAMPING
> - PTP_1588_CLOCKPTP
^^^
(I think you mean PTP_1588_CLOCK)
Did you enable CONFIG_DP83640_PHY too?
> I have at the moment no any idea what is wrong and I need help to figure out
> where the problem is.
Don't worry, we will figure this out...
> The other point is, I am not sure that the ptp4l support the DP83640 PHY.
The ptp4l should work with every PHC Linux driver.
> Please let me know how I can debug this problem e.g. with some printks in
> the kernel driver or adapt the ptp4l application.
This might be a driver issue with the MPC5200, since I never tested it
in combination with the DP83640. But first, make sure you have the PHY
driver compiled in your kernel.
Thanks,
Richard
|
|
From: Mario M. <Mar...@we...> - 2012-05-23 14:41:34
|
Hello Richard,
many thanks for your quick answer.
>(I think you mean MPC)
Yes, it was typo
>I have never seen the combination MPC5200/DP83640. Is this a
> commercial board or a custom design?
It is custom design. We design a module for our data acquisition systems.
>Looks like no packets are being time stamped at all.
Why the software time stamping work and only the hardware time stamping has
this problem? This point has me irritated.
The other point we don't have connected the PTP server directly with our PTP
slave module and it is some Ethernet switches involved in Ethernet
connection. Could this make a problem?
>(I think you mean PTP_1588_CLOCK)
Yes, it was typo
>Did you enable CONFIG_DP83640_PHY too?
Yes we have also used this option.
>Don't worry, we will figure this out...
Thanks. I appreciate your help. :)
>The ptp4l should work with every PHC Linux driver.
Ok. Fine and I am happy to hear that.
>This might be a driver issue with the MPC5200, since I never tested it
>in combination with the DP83640. But first, make sure you have the PHY
>driver compiled in your kernel.
I have adapt the code of PHY driver (net/phy/dp83640.c) with printk and I
have seen the probe function is executed. I can say the kernel driver is
compiled and loaded.
I have a question to phy driver dp83640.c only for interest. I have seen in
probe function that recalibrate(clock) function not always executed directly
after registration. What is the reason for this?
I men following code sequence:
==========================================
if (choose_this_phy(clock, phydev)) { clock->chosen =
dp83640; clock->ptp_clock = ptp_clock_register(&clock->caps);
if (IS_ERR(clock->ptp_clock)) { err =
PTR_ERR(clock->ptp_clock); goto
} } else list_add_tail(&dp83640->list,
&clock->phylist); if (clock->chosen &&
!list_empty(&clock->phylist)) recalibrate(clock);
========================================
Kind regards and thanks again for your help,
Mario
----- Original Message -----
From: "Richard Cochran" <ric...@gm...>
To: "Mario Molitor" <Mar...@we...>
Cc: <lin...@li...>
Sent: Tuesday, May 22, 2012 8:17 PM
Subject: Re: [Linuxptp-users] Problems with hardware time stamping with PHY
DP83640 on MCP5200 powerpc platform
> On Tue, May 22, 2012 at 07:34:55PM +0200, Mario Molitor wrote:
>> Hallo linuxptp members,
>>
>> I have some problems to use our PTP device (PHY DP83640 on MCP5200
>> powerpc
> ^^^
> (I think you mean MPC)
>
>> platform).
>
> I have never seen the combination MPC5200/DP83640. Is this a
> commercial board or a custom design?
>
>> 2.) hardware time stamping
>> ===================
>> ptp4l[183]: selected /dev/ptp0 as PTP clock
>>
>> ptp4l[183]: port 1: INITIALIZING to LISTENING on INITIALIZE
>> ptp4l[183]: received SYNC without timestamp
>> ptp4l[183]: port 1: bad message
>> ptp4l[183]: port 1: new foreign master 0050c2.fffe.c2dfc3-1
>> ptp4l[183]: received SYNC without timestamp
>> ptp4l[183]: port 1: bad message
>> ptp4l[183]: received SYNC without timestamp
>> ptp4l[183]: port 1: bad message
>
> Looks like no packets are being time stamped at all.
>
>> I used following linux version without any source changes for test of
>> PTP:
>>
>> Linux version 3.4.0-rc7-next-20120514
>> with following options
>> - CONFIG_EXPERIMENTAL
>> - CONFIG_PPS
>> - CONFIG_NETWORK_PHY_TIMESTAMPING
>> - PTP_1588_CLOCKPTP
> ^^^
> (I think you mean PTP_1588_CLOCK)
>
> Did you enable CONFIG_DP83640_PHY too?
>
>> I have at the moment no any idea what is wrong and I need help to figure
>> out
>> where the problem is.
>
> Don't worry, we will figure this out...
>
>> The other point is, I am not sure that the ptp4l support the DP83640
>> PHY.
>
> The ptp4l should work with every PHC Linux driver.
>
>> Please let me know how I can debug this problem e.g. with some printks in
>> the kernel driver or adapt the ptp4l application.
>
> This might be a driver issue with the MPC5200, since I never tested it
> in combination with the DP83640. But first, make sure you have the PHY
> driver compiled in your kernel.
>
> Thanks,
> Richard
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
|
|
From: Mario M. <Mar...@we...> - 2012-05-23 14:54:52
|
Hello Richard,
many thanks for your quick answer.
>(I think you mean MPC)
Yes, it was typo
> I have never seen the combination MPC5200/DP83640. Is this a
> commercial board or a custom design?
It is custom design. We design a module for our data acquisition systems.
>Looks like no packets are being time stamped at all.
Why the software time stamping work and only the hardware time stamping has
this problem? This point has me irritated.
The other point we don't have connected the PTP server directly with our PTP
slave module and it is some Ethernet switches involved in Ethernet
connection. Could this make a problem?
>(I think you mean PTP_1588_CLOCK)
Yes, it was typo
>Did you enable CONFIG_DP83640_PHY too?
Yes we have also used this option.
>Don't worry, we will figure this out...
Thanks. I appreciate your help. :)
>The ptp4l should work with every PHC Linux driver.
Ok. Fine and I am happy to hear that.
>This might be a driver issue with the MPC5200, since I never tested it
>in combination with the DP83640. But first, make sure you have the PHY
>driver compiled in your kernel.
I have adapt the code of PHY driver (net/phy/dp83640.c) with printk and I
have seen the probe function is executed. I can say the kernel driver is
compiled and loaded.
I have a question to phy driver dp83640.c only for interest. I have seen in
probe function that recalibrate(clock) function not always executed directly
after registration. What is the reason for this?
I men following code sequence:
=========================================
if (choose_this_phy(clock, phydev)) {
clock->chosen = dp83640;
clock->ptp_clock = ptp_clock_register(&clock->caps);
if (IS_ERR(clock->ptp_clock)) {
err = PTR_ERR(clock->ptp_clock);
goto no_register;
}
} else
list_add_tail(&dp83640->list, &clock->phylist);
if (clock->chosen && !list_empty(&clock->phylist))
recalibrate(clock);
========================================
Kind regards and thanks again for your help,
Mario
----- Original Message -----
From: "Richard Cochran" <ric...@gm...>
To: "Mario Molitor" <Mar...@we...>
Cc: <lin...@li...>
Sent: Tuesday, May 22, 2012 8:17 PM
Subject: Re: [Linuxptp-users] Problems with hardware time stamping with PHY
DP83640 on MCP5200 powerpc platform
> On Tue, May 22, 2012 at 07:34:55PM +0200, Mario Molitor wrote:
>> Hallo linuxptp members,
>>
>> I have some problems to use our PTP device (PHY DP83640 on MCP5200
>> powerpc
> ^^^
> (I think you mean MPC)
>
>> platform).
>
> I have never seen the combination MPC5200/DP83640. Is this a
> commercial board or a custom design?
>
>> 2.) hardware time stamping
>> ===================
>> ptp4l[183]: selected /dev/ptp0 as PTP clock
>>
>> ptp4l[183]: port 1: INITIALIZING to LISTENING on INITIALIZE
>> ptp4l[183]: received SYNC without timestamp
>> ptp4l[183]: port 1: bad message
>> ptp4l[183]: port 1: new foreign master 0050c2.fffe.c2dfc3-1
>> ptp4l[183]: received SYNC without timestamp
>> ptp4l[183]: port 1: bad message
>> ptp4l[183]: received SYNC without timestamp
>> ptp4l[183]: port 1: bad message
>
> Looks like no packets are being time stamped at all.
>
>> I used following linux version without any source changes for test of
>> PTP:
>>
>> Linux version 3.4.0-rc7-next-20120514
>> with following options
>> - CONFIG_EXPERIMENTAL
>> - CONFIG_PPS
>> - CONFIG_NETWORK_PHY_TIMESTAMPING
>> - PTP_1588_CLOCKPTP
> ^^^
> (I think you mean PTP_1588_CLOCK)
>
> Did you enable CONFIG_DP83640_PHY too?
>
>> I have at the moment no any idea what is wrong and I need help to figure
>> out
>> where the problem is.
>
> Don't worry, we will figure this out...
>
>> The other point is, I am not sure that the ptp4l support the DP83640
>> PHY.
>
> The ptp4l should work with every PHC Linux driver.
>
>> Please let me know how I can debug this problem e.g. with some printks in
>> the kernel driver or adapt the ptp4l application.
>
> This might be a driver issue with the MPC5200, since I never tested it
> in combination with the DP83640. But first, make sure you have the PHY
> driver compiled in your kernel.
>
> Thanks,
> Richard
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
|
|
From: Richard C. <ric...@gm...> - 2012-05-23 15:15:19
|
On Wed, May 23, 2012 at 04:54:42PM +0200, Mario Molitor wrote: > I have a question to phy driver dp83640.c only for interest. I have seen in > probe function that recalibrate(clock) function not always executed directly > after registration. What is the reason for this? The driver supports using multiple PHYs together as one PHC clock. Calibration is needed to synchronize multiple PHYs, but only when you have two or more PHYs on the same MDIO bus. Do you have more than one PHY in your design? If so, their GPIOs need to be wired together correctly in order to make this work. If not, then the recalibrate() function should never be called. HTH, Richard |
|
From: Mario M. <Mar...@we...> - 2012-05-28 11:25:24
|
Hi Richard, >> I have a question to phy driver dp83640.c only for interest. I have seen >> in >> probe function that recalibrate(clock) function not always executed >> directly >> after registration. What is the reason for this? > > The driver supports using multiple PHYs together as one PHC > clock. Calibration is needed to synchronize multiple PHYs, but only > when you have two or more PHYs on the same MDIO bus. > > Do you have more than one PHY in your design? No, we used only one PHY in our design. > > If so, their GPIOs need to be wired together correctly in order to > make this work. > > If not, then the recalibrate() function should never be called. Ok this is also my observation. Thanks for the info, Mario |
|
From: Richard C. <ric...@gm...> - 2012-05-23 15:29:58
|
On Wed, May 23, 2012 at 04:54:42PM +0200, Mario Molitor wrote: > > Why the software time stamping work and only the hardware time stamping has > this problem? This point has me irritated. SW and HW time stamping are completely different code paths and are not really connected to each other. > The other point we don't have connected the PTP server directly with our PTP > slave module and it is some Ethernet switches involved in Ethernet > connection. Could this make a problem? I doubt it. > >Did you enable CONFIG_DP83640_PHY too? > > Yes we have also used this option. Good. Can you post your dmesg? > I have adapt the code of PHY driver (net/phy/dp83640.c) with printk and I > have seen the probe function is executed. I can say the kernel driver is > compiled and loaded. If you want to trace what is happening, you can add printks along the following path. *** drivers/net/ethernet/freescale/fec_mpc52xx.c: mpc52xx_fec_rx_interrupt() if (!skb_defer_rx_timestamp(skb)) netif_rx(rskb); *** net/core/timestamping.c: skb_defer_rx_timestamp[104] type = classify(skb); (check the conditions within classify() and the returned type) ... phydev = skb->dev->phydev; if (likely(phydev->drv->rxtstamp)) return phydev->drv->rxtstamp(phydev, skb, type); *** drivers/net/phy/dp83640.c: dp83640_rxtstamp[1172] (If you can trace a sync message this far, then that will already help narrow down the problem.) Thanks, Richard |
|
From: Mario M. <Mar...@we...> - 2012-05-28 11:26:33
Attachments:
dmesg.log
|
Hi Richard, >> Why the software time stamping work and only the hardware time stamping >> has >> this problem? This point has me irritated. > > SW and HW time stamping are completely different code paths and are > not really connected to each other. Ok. >> The other point we don't have connected the PTP server directly with our >> PTP >> slave module and it is some Ethernet switches involved in Ethernet >> connection. Could this make a problem? > > I doubt it. Ok fine. >> >Did you enable CONFIG_DP83640_PHY too? >> >> Yes we have also used this option. > > Good. Can you post your dmesg? Yes I have attached the DMESG log on this email. >> I have adapt the code of PHY driver (net/phy/dp83640.c) with printk and I >> have seen the probe function is executed. I can say the kernel driver is >> compiled and loaded. > > If you want to trace what is happening, you can add printks along the > following path. > > *** drivers/net/ethernet/freescale/fec_mpc52xx.c: > mpc52xx_fec_rx_interrupt() > > if (!skb_defer_rx_timestamp(skb)) > netif_rx(rskb); > > *** net/core/timestamping.c: skb_defer_rx_timestamp[104] > > type = classify(skb); > > (check the conditions within classify() and the returned type) It seems that classify (better the function sk_run_filter) don't detected any PTP event message. Tomorrow I will deeper TRACE this. > ... > phydev = skb->dev->phydev; > if (likely(phydev->drv->rxtstamp)) > return phydev->drv->rxtstamp(phydev, skb, type); > > *** drivers/net/phy/dp83640.c: dp83640_rxtstamp[1172] Best regards, Mario |
|
From: Richard C. <ric...@gm...> - 2012-05-28 13:57:58
|
On Mon, May 28, 2012 at 01:26:12PM +0200, Mario Molitor wrote: > >(check the conditions within classify() and the returned type) > > It seems that classify (better the function sk_run_filter) don't detected > any PTP event message. Tomorrow I will deeper TRACE this. It would help to see a hex dump of skb->data from a PTP message packet when sk_run_filter fails to detect it. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2012-05-23 15:45:43
|
On Wed, May 23, 2012 at 04:54:42PM +0200, Mario Molitor wrote:
> >I have never seen the combination MPC5200/DP83640. Is this a
> >commercial board or a custom design?
>
> It is custom design. We design a module for our data acquisition systems.
Here are two ideas to think about.
1. Perhaps the PHY device driver instance is not properly associated with
the FEC driver instance. Have you checked your DTS?
2. The PHY sends the time stamps to the MAC using special "status"
frames. Perhaps your MAC is dropping these frames? They are sent
with a DST MAC address like this:
static u8 status_frame_dst[6] = { 0x01, 0x1B, 0x19, 0x00, 0x00, 0x00 };
HTH,
Richard
|
|
From: Mario M. <Mar...@we...> - 2012-05-28 11:34:00
|
Hi Richard,
>> >I have never seen the combination MPC5200/DP83640. Is this a
>> >commercial board or a custom design?
>>
>> It is custom design. We design a module for our data acquisition systems.
>
> Here are two ideas to think about.
>
> 1. Perhaps the PHY device driver instance is not properly associated with
> the FEC driver instance. Have you checked your DTS?
We have checked this and it looks ok, but we can't shutout any problem. We
will very this tomorrow again.
> 2. The PHY sends the time stamps to the MAC using special "status"
> frames. Perhaps your MAC is dropping these frames? They are sent
> with a DST MAC address like this:
>
> static u8 status_frame_dst[6] = { 0x01, 0x1B, 0x19, 0x00, 0x00, 0x00 };
I could verify this with tcpdump (on the module) and with our probe
(http://www.beckhoff.de/default.asp?ethercat/et2000.htm) over Wireshark.
What do you think about this?
I have another question to use always layer 2 for status frame.
Is this always necessary?
Because I think UDP/IPv4 status frames should also possible.
I could change this for our tests. What do you think about this?
Thanks,
Mario
|
|
From: Richard C. <ric...@gm...> - 2012-05-28 14:01:17
|
On Mon, May 28, 2012 at 01:33:54PM +0200, Mario Molitor wrote: > > I have another question to use always layer 2 for status frame. > Is this always necessary? > Because I think UDP/IPv4 status frames should also possible. > > I could change this for our tests. What do you think about this? I am not sure what you mean. The PHY status frames are L2, but this has nothing to do with the actual PTP messages, which can be L2 or L4 in any case. HTH, Richard |
|
From: Mario M. <Mar...@we...> - 2012-05-29 18:54:42
Attachments:
messages.zip
|
Hi Richard, >> >(check the conditions within classify() and the returned type) >> >> It seems that classify (better the function sk_run_filter) don't detected >> any PTP event message. Tomorrow I will deeper TRACE this. > It would help to see a hex dump of skb->data from a PTP message packet > when sk_run_filter fails to detect it. I have modified my instrumentation which you can find as attached message (messages.zip) log (syslog). In case of type (in the function "skb_defer_rx_timestamp()") with a value 0 it makes printk hex output of skb->data. I hope this help you. Please let me let me know if you need more information. Thanks, Mario |
|
From: Richard C. <ric...@gm...> - 2012-05-30 05:00:22
|
On Tue, May 29, 2012 at 08:54:36PM +0200, Mario Molitor wrote: > > I have modified my instrumentation which you can find as attached > message (messages.zip) > log (syslog). > In case of type (in the function "skb_defer_rx_timestamp()") with a value > 0 it makes printk hex output of skb->data. > I hope this help you. Please let me let me know if you need more > information. Wow, that looks really wrong. I don't see a MAC address anywhere. It is essential that the function, classify(), in skb_defer_rx_timestamp is passed a skb with skb->data pointing to the DST MAC address. Can you show the patch you are using? Thanks, Richard |
|
From: Stephan G. <st...@ga...> - 2012-05-30 16:35:47
Attachments:
smime.p7s
|
Hello Richard, I'm a colleague of Mario and we found the reason for the strange data int the skb. > Wow, that looks really wrong. I don't see a MAC address anywhere. > The problem lies in the file linux/drivers/net/ethernet/freescale/fec_mpc52xx.c In the receive interrupt function mpc52xx_fec_rx_interrupt the call to skb_defer_rx_timestamp is done using a freshly allocated skb (called skb) and not with the received skb (called rskb). Calling skb_defer_rx_timestamp with the correct parameter engages the whole engine. We would be happy to make a patch for this fix. Do you think the powerpc mailing list is more suitable than the linux-netdev? Regards, Stephan |
|
From: Richard C. <ric...@gm...> - 2012-05-30 19:32:40
|
On Wed, May 30, 2012 at 06:20:32PM +0200, Stephan Gatzka wrote: > Hello Richard, > > I'm a colleague of Mario and we found the reason for the strange > data int the skb. > > >Wow, that looks really wrong. I don't see a MAC address anywhere. > > > > The problem lies in the file > linux/drivers/net/ethernet/freescale/fec_mpc52xx.c > > In the receive interrupt function mpc52xx_fec_rx_interrupt > the call to skb_defer_rx_timestamp is done using a freshly > allocated skb (called skb) and not with the received skb (called > rskb). Calling skb_defer_rx_timestamp with the correct parameter > engages the whole engine. Oops. I added that code. My bad. > We would be happy to make a patch for this fix. Do you think the > powerpc mailing list is more suitable than the linux-netdev? Please post the fix to netdev, and add the tag for stable like this: Cc: <st...@vg...> [affects 3.1 and newer] Thanks, Richard |
|
From: Stephan G. <st...@ga...> - 2012-05-30 19:52:55
Attachments:
smime.p7s
|
Hi! > Oops. I added that code. My bad. Don't worry. :) We are more than happy that you built the whole ptp infrastructure into the kernel. > Please post the fix to netdev, and add the tag for stable like this: > > Cc:<st...@vg...> [affects 3.1 and newer] We will do that. Regards, Stephan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X