[Linuxptp-devel] kernel crashed when run linux ptp

[Arnold kang]

Dear Richard,
thanks for your reply. as i asked , my linux kernel is 3.0, and
my phy is DP83640, and my mac is stmmac, and my cpu is arm A9,
when i run it and use hardware timestamp (./ptp4l - H -i eth0 -p
/dev/ptp0) on my system, the kernel crashed. (crash log is appended in
below)
and can i ask a question, " In order for this to work, your MAC
driver must also
implement the skb_tx_timestamp() function." (drivers/ptp/Kconfig),
what's this mean? should i modify the mac driver.


here is kernel crash log:
<INFO: rcu_sched_state detected stall on CPU 0 (t=6000 jiffies)
Backtrace for cpu 0 (current):
Backtrace:
[<c0041edc>] (dump_backtrace+0x0/0x110) from [<c0520be8>]
(dump_stack+0x18/0x1c)
r6:00000000 r5:00000000 r4:c0667784 r3:c3b7c000
[<c0520bd0>] (dump_stack+0x0/0x1c) from [<c00436b4>]
(smp_send_all_cpu_backtrace+0x74/0x104)
[<c0043640>] (smp_send_all_cpu_backtrace+0x0/0x104) from [<c003f518>]
(arch_trigger_all_cpu_backtrace+0x10/0x14)
r7:c0648180 r6:c0642080 r5:c0648180 r4:c0747440
[<c003f508>] (arch_trigger_all_cpu_backtrace+0x0/0x14) from [<c0096018>]
(__rcu_pending+0x158/0x398)
[<c0095ec0>] (__rcu_pending+0x0/0x398) from [<c00962d0>]
(rcu_check_callbacks+0x78/0x168)
[<c0096258>] (rcu_check_callbacks+0x0/0x168) from [<c00661c4>]
(update_process_times+0x40/0x54)
r5:00000000 r4:c38c3840
[<c0066184>] (update_process_times+0x0/0x54) from [<c0083508>]
(tick_periodic+0x5c/0xcc)
r6:91717f80 r5:00000000 r4:c06420c4 r3:00000000
[<c00834ac>] (tick_periodic+0x0/0xcc) from [<c00835a4>]
(tick_handle_periodic+0x2c/0xa8)
r9:c3806280 r8:00000023 r7:00000000 r6:c0747040 r4:c06aa098
r3:c0747040
[<c0083578>] (tick_handle_periodic+0x0/0xa8) from [<c0083944>]
(tick_do_periodic_broadcast+0xf4/0xfc)
[<c0083850>] (tick_do_periodic_broadcast+0x0/0xfc) from [<c0083964>]
(tick_handle_periodic_broadcast+0x18/0x78)
r6:c06461c0 r5:c38062cc r4:c0646220 r3:c008394c
[<c008394c>] (tick_handle_periodic_broadcast+0x0/0x78) from
[<c0049fb4>] (godnet_timer_interrupt+0x38/0x40)
[<c0049f7c>] (godnet_timer_interrupt+0x0/0x40) from [<c009014c>]
(handle_irq_event_percpu+0x58/0x188)
[<c00900f4>] (handle_irq_event_percpu+0x0/0x188) from [<c00902c4>]
(handle_irq_event+0x48/0x68)
[<c009027c>] (handle_irq_event+0x0/0x68) from [<c0092ae4>]
(handle_fasteoi_irq+0xa4/0x118)
r6:00000023 r5:c38062cc r4:c3806280 r3:c0035110
[<c0092a40>] (handle_fasteoi_irq+0x0/0x118) from [<c00900d8>]
(generic_handle_irq+0x30/0x38)
r5:c0035b0c r4:00000023
[<c00900a8>] (generic_handle_irq+0x0/0x38) from [<c0037060>]
(asm_do_IRQ+0x60/0xc0)
r4:c0642480 r3:00000080
[<c0037000>] (asm_do_IRQ+0x0/0xc0) from [<c003d778>]
(__irq_svc+0x38/0xa0)
Exception stack(0xc3b7dcd0 to 0xc3b7dd18)
dcc0: c384c588 00000003
00000001 00000001
dce0: c384c588 c384c000 c384c3a0 c065b71c 000000e5 c3b7c000
000000e5 c3b7dd24
dd00: c3b7dd28 c3b7dd18 bf000748 c05235e4 20000013 ffffffff
r7:c065b71c r6:00000023 r5:fe300100 r4:ffffffff
[<c05235c8>] (_raw_spin_lock+0x0/0x30) from [<bf000748>]
(stmmac_multicast_list+0x20/0x4c [stmmac])
[<bf000728>] (stmmac_multicast_list+0x0/0x4c [stmmac]) from
[<c041ba54>] (__dev_set_rx_mode+0x6c/0xa0)
r6:00000000 r5:bf00dfe0 r4:c384c000 r3:bf000728
[<c041b9e8>] (__dev_set_rx_mode+0x0/0xa0) from [<c04262d8>]
(__dev_mc_add+0x50/0x64)
r6:00000000 r5:c384c12c r4:c384c000 r3:00000004
[<c0426288>] (__dev_mc_add+0x0/0x64) from [<c0426318>]
(dev_mc_add+0x14/0x18)
r7:c3b7ddcc r6:c381d000 r5:00000001 r4:c3b90600
[<c0426304>] (dev_mc_add+0x0/0x18) from [<c0384470>]
(enable_status_frames+0x8c/0xc8)
[<c03843e4>] (enable_status_frames+0x0/0xc8) from [<c03848cc>]
(dp83640_hwtstamp+0x170/0x290)
r5:c3b7de88 r4:c3b90600
[<c038475c>] (dp83640_hwtstamp+0x0/0x290) from [<c0382090>]
(phy_mii_ioctl+0x94/0x1ac)
[<c0381ffc>] (phy_mii_ioctl+0x0/0x1ac) from [<bf000710>]
(stmmac_ioctl+0x60/0x78 [stmmac])
r6:c3b7de88 r5:c384c588 r4:c384c000 r3:00000001
[<bf0006b0>] (stmmac_ioctl+0x0/0x78 [stmmac]) from
[<c0420fcc>] (dev_ifsioc+0x288/0x3d0)
r5:000089b0 r4:c384c000
[<c0420d44>] (dev_ifsioc+0x0/0x3d0) from [<c042166c>]
(dev_ioctl+0x558/0x930)
r6:c3b7de88 r5:c06bd9a0 r4:000089b0 r3:c38c3840
[<c0421114>] (dev_ioctl+0x0/0x930) from [<c040a36c>]
(sock_ioctl+0x9c/0x270)
[<c040a2d0>] (sock_ioctl+0x0/0x270) from [<c00dc9ac>]
(do_vfs_ioctl+0x8c/0x5d8)
r6:0000fdfd r5:c3abb140 r4:bec5ba94 r3:c040a2d0
[<c00dc920>] (do_vfs_ioctl+0x0/0x5d8) from [<c00dcf38>]
(sys_ioctl+0x40/0x68)
[<c00dcef8>] (sys_ioctl+0x0/0x68) from [<c003db80>]
(ret_fast_syscall+0x0/0x30)
r7:00000036 r6:0000000b r5:000089b0 r4:bec5ba94

sending IPI to all other CPUs:
thanks

[Richard Cochran]

Post by Arnold kang
Dear Richard,
thanks for your reply. as i asked , my linux kernel is 3.0, and
my phy is DP83640, and my mac is stmmac, and my cpu is arm A9,

Where did you get your kernel?

I guess you have out of tree patches, right?

Post by Arnold kang
when i run it and use hardware timestamp (./ptp4l - H -i eth0 -p
/dev/ptp0) on my system, the kernel crashed. (crash log is appended in
below)

There is likely a bug in the stmmac driver, see below.

Post by Arnold kang
and can i ask a question, " In order for this to work, your MAC
driver must also
implement the skb_tx_timestamp() function." (drivers/ptp/Kconfig),
what's this mean? should i modify the mac driver.

Yes, you will need to add this one line into the driver.
This trace is badly word wrapped by your email client, making it much
harder to read.

Post by Arnold kang
<INFO: rcu_sched_state detected stall on CPU 0 (t=6000 jiffies)
[<c0041edc>] (dump_backtrace+0x0/0x110) from [<c0520be8>]
(dump_stack+0x18/0x1c)
r6:00000000 r5:00000000 r4:c0667784 r3:c3b7c000
[<c0520bd0>] (dump_stack+0x0/0x1c) from [<c00436b4>]
(smp_send_all_cpu_backtrace+0x74/0x104)
[<c0043640>] (smp_send_all_cpu_backtrace+0x0/0x104) from [<c003f518>]
(arch_trigger_all_cpu_backtrace+0x10/0x14)
r7:c0648180 r6:c0642080 r5:c0648180 r4:c0747440
[<c003f508>] (arch_trigger_all_cpu_backtrace+0x0/0x14) from [<c0096018>]
(__rcu_pending+0x158/0x398)
[<c0095ec0>] (__rcu_pending+0x0/0x398) from [<c00962d0>]
(rcu_check_callbacks+0x78/0x168)
[<c0096258>] (rcu_check_callbacks+0x0/0x168) from [<c00661c4>]
(update_process_times+0x40/0x54)
r5:00000000 r4:c38c3840
[<c0066184>] (update_process_times+0x0/0x54) from [<c0083508>]
(tick_periodic+0x5c/0xcc)
r6:91717f80 r5:00000000 r4:c06420c4 r3:00000000
[<c00834ac>] (tick_periodic+0x0/0xcc) from [<c00835a4>]
(tick_handle_periodic+0x2c/0xa8)
r9:c3806280 r8:00000023 r7:00000000 r6:c0747040 r4:c06aa098
r3:c0747040
[<c0083578>] (tick_handle_periodic+0x0/0xa8) from [<c0083944>]
(tick_do_periodic_broadcast+0xf4/0xfc)
[<c0083850>] (tick_do_periodic_broadcast+0x0/0xfc) from [<c0083964>]
(tick_handle_periodic_broadcast+0x18/0x78)
r6:c06461c0 r5:c38062cc r4:c0646220 r3:c008394c
[<c008394c>] (tick_handle_periodic_broadcast+0x0/0x78) from
[<c0049fb4>] (godnet_timer_interrupt+0x38/0x40)
[<c0049f7c>] (godnet_timer_interrupt+0x0/0x40) from [<c009014c>]
(handle_irq_event_percpu+0x58/0x188)
[<c00900f4>] (handle_irq_event_percpu+0x0/0x188) from [<c00902c4>]
(handle_irq_event+0x48/0x68)
[<c009027c>] (handle_irq_event+0x0/0x68) from [<c0092ae4>]
(handle_fasteoi_irq+0xa4/0x118)
r6:00000023 r5:c38062cc r4:c3806280 r3:c0035110
[<c0092a40>] (handle_fasteoi_irq+0x0/0x118) from [<c00900d8>]
(generic_handle_irq+0x30/0x38)
r5:c0035b0c r4:00000023
[<c00900a8>] (generic_handle_irq+0x0/0x38) from [<c0037060>]
(asm_do_IRQ+0x60/0xc0)
r4:c0642480 r3:00000080
[<c0037000>] (asm_do_IRQ+0x0/0xc0) from [<c003d778>]
(__irq_svc+0x38/0xa0)
Exception stack(0xc3b7dcd0 to 0xc3b7dd18)
dcc0: c384c588 00000003
00000001 00000001
dce0: c384c588 c384c000 c384c3a0 c065b71c 000000e5 c3b7c000
000000e5 c3b7dd24
dd00: c3b7dd28 c3b7dd18 bf000748 c05235e4 20000013 ffffffff
r7:c065b71c r6:00000023 r5:fe300100 r4:ffffffff
[<c05235c8>] (_raw_spin_lock+0x0/0x30) from [<bf000748>]
(stmmac_multicast_list+0x20/0x4c [stmmac])
[<bf000728>] (stmmac_multicast_list+0x0/0x4c [stmmac]) from
[<c041ba54>] (__dev_set_rx_mode+0x6c/0xa0)

The dp83640 driver needs to add a multicast MAC address in order to
receive PHY status frames. It looks like the stmmac driver then
triggers the lock up.

HTH,
Richard

Post by Arnold kang
r6:00000000 r5:bf00dfe0 r4:c384c000 r3:bf000728
[<c041b9e8>] (__dev_set_rx_mode+0x0/0xa0) from [<c04262d8>]
(__dev_mc_add+0x50/0x64)
r6:00000000 r5:c384c12c r4:c384c000 r3:00000004
[<c0426288>] (__dev_mc_add+0x0/0x64) from [<c0426318>]
(dev_mc_add+0x14/0x18)
r7:c3b7ddcc r6:c381d000 r5:00000001 r4:c3b90600
[<c0426304>] (dev_mc_add+0x0/0x18) from [<c0384470>]
(enable_status_frames+0x8c/0xc8)
[<c03843e4>] (enable_status_frames+0x0/0xc8) from [<c03848cc>]
(dp83640_hwtstamp+0x170/0x290)
r5:c3b7de88 r4:c3b90600
[<c038475c>] (dp83640_hwtstamp+0x0/0x290) from [<c0382090>]
(phy_mii_ioctl+0x94/0x1ac)
[<c0381ffc>] (phy_mii_ioctl+0x0/0x1ac) from [<bf000710>]
(stmmac_ioctl+0x60/0x78 [stmmac])
r6:c3b7de88 r5:c384c588 r4:c384c000 r3:00000001
[<bf0006b0>] (stmmac_ioctl+0x0/0x78 [stmmac]) from
[<c0420fcc>] (dev_ifsioc+0x288/0x3d0)
r5:000089b0 r4:c384c000
[<c0420d44>] (dev_ifsioc+0x0/0x3d0) from [<c042166c>]
(dev_ioctl+0x558/0x930)
r6:c3b7de88 r5:c06bd9a0 r4:000089b0 r3:c38c3840
[<c0421114>] (dev_ioctl+0x0/0x930) from [<c040a36c>]
(sock_ioctl+0x9c/0x270)
[<c040a2d0>] (sock_ioctl+0x0/0x270) from [<c00dc9ac>]
(do_vfs_ioctl+0x8c/0x5d8)
r6:0000fdfd r5:c3abb140 r4:bec5ba94 r3:c040a2d0
[<c00dc920>] (do_vfs_ioctl+0x0/0x5d8) from [<c00dcf38>]
(sys_ioctl+0x40/0x68)
[<c00dcef8>] (sys_ioctl+0x0/0x68) from [<c003db80>]
(ret_fast_syscall+0x0/0x30)
r7:00000036 r6:0000000b r5:000089b0 r4:bec5ba94
thanks
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Linuxptp-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Arnold kang]

Dear Richard,
i get my kernel from my chip vendor yes, the mac driver is modified by
them. maybe this is why the kernel crashed. but i really don't understand
what* skb_tx_timestamp() *mean. i search in google, there is no answer
and there is no prototype in kernel or other use in kernel code. can you
tell me how to add it? thanks...

Post by Richard Cochran

Post by Arnold kang
Dear Richard,
thanks for your reply. as i asked , my linux kernel is 3.0, and
my phy is DP83640, and my mac is stmmac, and my cpu is arm A9,

Where did you get your kernel?
I guess you have out of tree patches, right?

Post by Arnold kang
when i run it and use hardware timestamp (./ptp4l - H -i eth0 -p
/dev/ptp0) on my system, the kernel crashed. (crash log is appended in
below)

There is likely a bug in the stmmac driver, see below.

Post by Arnold kang
and can i ask a question, " In order for this to work, your MAC
driver must also
implement the skb_tx_timestamp() function." (drivers/ptp/Kconfig),
what's this mean? should i modify the mac driver.

Yes, you will need to add this one line into the driver.
This trace is badly word wrapped by your email client, making it much
harder to read.

Post by Arnold kang
<INFO: rcu_sched_state detected stall on CPU 0 (t=6000 jiffies)
[<c0041edc>] (dump_backtrace+0x0/0x110) from [<c0520be8>]
(dump_stack+0x18/0x1c)
r6:00000000 r5:00000000 r4:c0667784 r3:c3b7c000
[<c0520bd0>] (dump_stack+0x0/0x1c) from [<c00436b4>]
(smp_send_all_cpu_backtrace+0x74/0x104)
[<c0043640>] (smp_send_all_cpu_backtrace+0x0/0x104) from [<c003f518>]
(arch_trigger_all_cpu_backtrace+0x10/0x14)
r7:c0648180 r6:c0642080 r5:c0648180 r4:c0747440
[<c003f508>] (arch_trigger_all_cpu_backtrace+0x0/0x14) from

[<c0096018>]

Post by Arnold kang
(__rcu_pending+0x158/0x398)
[<c0095ec0>] (__rcu_pending+0x0/0x398) from [<c00962d0>]
(rcu_check_callbacks+0x78/0x168)
[<c0096258>] (rcu_check_callbacks+0x0/0x168) from [<c00661c4>]
(update_process_times+0x40/0x54)
r5:00000000 r4:c38c3840
[<c0066184>] (update_process_times+0x0/0x54) from [<c0083508>]
(tick_periodic+0x5c/0xcc)
r6:91717f80 r5:00000000 r4:c06420c4 r3:00000000
[<c00834ac>] (tick_periodic+0x0/0xcc) from [<c00835a4>]
(tick_handle_periodic+0x2c/0xa8)
r9:c3806280 r8:00000023 r7:00000000 r6:c0747040 r4:c06aa098
r3:c0747040
[<c0083578>] (tick_handle_periodic+0x0/0xa8) from [<c0083944>]
(tick_do_periodic_broadcast+0xf4/0xfc)
[<c0083850>] (tick_do_periodic_broadcast+0x0/0xfc) from [<c0083964>]
(tick_handle_periodic_broadcast+0x18/0x78)
r6:c06461c0 r5:c38062cc r4:c0646220 r3:c008394c
[<c008394c>] (tick_handle_periodic_broadcast+0x0/0x78) from
[<c0049fb4>] (godnet_timer_interrupt+0x38/0x40)
[<c0049f7c>] (godnet_timer_interrupt+0x0/0x40) from [<c009014c>]
(handle_irq_event_percpu+0x58/0x188)
[<c00900f4>] (handle_irq_event_percpu+0x0/0x188) from [<c00902c4>]
(handle_irq_event+0x48/0x68)
[<c009027c>] (handle_irq_event+0x0/0x68) from [<c0092ae4>]
(handle_fasteoi_irq+0xa4/0x118)
r6:00000023 r5:c38062cc r4:c3806280 r3:c0035110
[<c0092a40>] (handle_fasteoi_irq+0x0/0x118) from [<c00900d8>]
(generic_handle_irq+0x30/0x38)
r5:c0035b0c r4:00000023
[<c00900a8>] (generic_handle_irq+0x0/0x38) from [<c0037060>]
(asm_do_IRQ+0x60/0xc0)
r4:c0642480 r3:00000080
[<c0037000>] (asm_do_IRQ+0x0/0xc0) from [<c003d778>]
(__irq_svc+0x38/0xa0)
Exception stack(0xc3b7dcd0 to 0xc3b7dd18)
dcc0: c384c588 00000003
00000001 00000001
dce0: c384c588 c384c000 c384c3a0 c065b71c 000000e5 c3b7c000
000000e5 c3b7dd24
dd00: c3b7dd28 c3b7dd18 bf000748 c05235e4 20000013 ffffffff
r7:c065b71c r6:00000023 r5:fe300100 r4:ffffffff
[<c05235c8>] (_raw_spin_lock+0x0/0x30) from [<bf000748>]
(stmmac_multicast_list+0x20/0x4c [stmmac])
[<bf000728>] (stmmac_multicast_list+0x0/0x4c [stmmac]) from
[<c041ba54>] (__dev_set_rx_mode+0x6c/0xa0)

The dp83640 driver needs to add a multicast MAC address in order to
receive PHY status frames. It looks like the stmmac driver then
triggers the lock up.
HTH,
Richard

Post by Arnold kang
r6:00000000 r5:bf00dfe0 r4:c384c000 r3:bf000728
[<c041b9e8>] (__dev_set_rx_mode+0x0/0xa0) from [<c04262d8>]
(__dev_mc_add+0x50/0x64)
r6:00000000 r5:c384c12c r4:c384c000 r3:00000004
[<c0426288>] (__dev_mc_add+0x0/0x64) from [<c0426318>]
(dev_mc_add+0x14/0x18)
r7:c3b7ddcc r6:c381d000 r5:00000001 r4:c3b90600
[<c0426304>] (dev_mc_add+0x0/0x18) from [<c0384470>]
(enable_status_frames+0x8c/0xc8)
[<c03843e4>] (enable_status_frames+0x0/0xc8) from

[<c03848cc>]

Post by Arnold kang
(dp83640_hwtstamp+0x170/0x290)
r5:c3b7de88 r4:c3b90600
[<c038475c>] (dp83640_hwtstamp+0x0/0x290) from [<c0382090>]
(phy_mii_ioctl+0x94/0x1ac)
[<c0381ffc>] (phy_mii_ioctl+0x0/0x1ac) from [<bf000710>]
(stmmac_ioctl+0x60/0x78 [stmmac])
r6:c3b7de88 r5:c384c588 r4:c384c000 r3:00000001
[<bf0006b0>] (stmmac_ioctl+0x0/0x78 [stmmac]) from
[<c0420fcc>] (dev_ifsioc+0x288/0x3d0)
r5:000089b0 r4:c384c000
[<c0420d44>] (dev_ifsioc+0x0/0x3d0) from [<c042166c>]
(dev_ioctl+0x558/0x930)
r6:c3b7de88 r5:c06bd9a0 r4:000089b0 r3:c38c3840
[<c0421114>] (dev_ioctl+0x0/0x930) from [<c040a36c>]
(sock_ioctl+0x9c/0x270)
[<c040a2d0>] (sock_ioctl+0x0/0x270) from [<c00dc9ac>]
(do_vfs_ioctl+0x8c/0x5d8)
r6:0000fdfd r5:c3abb140 r4:bec5ba94 r3:c040a2d0
[<c00dc920>] (do_vfs_ioctl+0x0/0x5d8) from [<c00dcf38>]
(sys_ioctl+0x40/0x68)
[<c00dcef8>] (sys_ioctl+0x0/0x68) from [<c003db80>]
(ret_fast_syscall+0x0/0x30)
r7:00000036 r6:0000000b r5:000089b0 r4:bec5ba94
thanks

------------------------------------------------------------------------------

Post by Arnold kang
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Linuxptp-devel mailing list
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Richard Cochran]

Post by Arnold kang
Dear Richard,
i get my kernel from my chip vendor， yes, the mac driver is modified by
them. maybe this is why the kernel crashed. but i really don't understand
what* skb_tx_timestamp() *mean. i search in google, there is no answer，
and there is no prototype in kernel or other use in kernel code. can you
tell me how to add it? thanks...

Regarding skb_tx_timestamp(), the prototype is found in
include/linux/skbuff.h, and it has been there since v2.6.36.

* skb_tx_timestamp() - Driver hook for transmit timestamping
*
* Ethernet MAC Drivers should call this function in their hard_xmit()
* function immediately before giving the sk_buff to the MAC hardware.

Once you fix your kernel crash, then you will need to add this into
the MAC driver as well.

The kernel crash has nothing to do with skb_tx_timestamp().
Unfortunately, I cannot help you with your vendor kernel.

Good luck,
Richard

[Arnold kang]

Dear Richard,
thanks your help

Post by Richard Cochran

Post by Arnold kang
Dear Richard,
i get my kernel from my chip vendor yes, the mac driver is modified

by

Post by Arnold kang
them. maybe this is why the kernel crashed. but i really don't understand
what* skb_tx_timestamp() *mean. i search in google, there is no answer
and there is no prototype in kernel or other use in kernel code. can you
tell me how to add it? thanks...

Regarding skb_tx_timestamp(), the prototype is found in
include/linux/skbuff.h, and it has been there since v2.6.36.
* skb_tx_timestamp() - Driver hook for transmit timestamping
*
* Ethernet MAC Drivers should call this function in their hard_xmit()
* function immediately before giving the sk_buff to the MAC hardware.
Once you fix your kernel crash, then you will need to add this into
the MAC driver as well.
The kernel crash has nothing to do with skb_tx_timestamp().
Unfortunately, I cannot help you with your vendor kernel.
Good luck,
Richard

[Arnold kang]

Dear Richard,
i'm sorry for i need your help again, i just resolve the kernel crash,
this was caused by call spin_lock twice in stmmac mac driver, but another
problem come out.
when i run "./ptp4l -i eth0 -H -p /dev/ptp0 -m", an error display
"*increasing
tx_timestamp_timeout may correct this issue, but it is likely caused by a
driver bug*", i'm not sure this was caused by mac driver or phy driver.
and i run ptp4l in SOFTWARE mode, all goes correctlly.

Post by Arnold kang
Dear Richard,
thanks your help

Post by Arnold kang

Post by Arnold kang
Dear Richard,
i get my kernel from my chip vendor yes, the mac driver is modified

by

Post by Arnold kang
them. maybe this is why the kernel crashed. but i really don't

understand

Post by Arnold kang
what* skb_tx_timestamp() *mean. i search in google, there is no

answer

Post by Arnold kang
and there is no prototype in kernel or other use in kernel code. can you
tell me how to add it? thanks...

Regarding skb_tx_timestamp(), the prototype is found in
include/linux/skbuff.h, and it has been there since v2.6.36.
* skb_tx_timestamp() - Driver hook for transmit timestamping
*
* Ethernet MAC Drivers should call this function in their hard_xmit()
* function immediately before giving the sk_buff to the MAC hardware.
Once you fix your kernel crash, then you will need to add this into
the MAC driver as well.
The kernel crash has nothing to do with skb_tx_timestamp().
Unfortunately, I cannot help you with your vendor kernel.
Good luck,
Richard

[Richard Cochran]

Post by Arnold kang
Dear Richard,
i'm sorry for i need your help again, i just resolve the kernel crash,
this was caused by call spin_lock twice in stmmac mac driver, but another
problem come out.
when i run "./ptp4l -i eth0 -H -p /dev/ptp0 -m", an error display
"*increasing
tx_timestamp_timeout may correct this issue, but it is likely caused by a
driver bug*", i'm not sure this was caused by mac driver or phy driver.
and i run ptp4l in SOFTWARE mode, all goes correctlly.

Did you try increasing tx_timestamp_timeout?

Thanks,
Richard

[Arnold kang]

yes, i just set never timeout, but it doesn't work.

Post by Richard Cochran

Post by Arnold kang
Dear Richard,
i'm sorry for i need your help again, i just resolve the kernel

crash,

Post by Arnold kang
this was caused by call spin_lock twice in stmmac mac driver, but another
problem come out.
when i run "./ptp4l -i eth0 -H -p /dev/ptp0 -m", an error display
"*increasing
tx_timestamp_timeout may correct this issue, but it is likely caused by a
driver bug*", i'm not sure this was caused by mac driver or phy driver.
and i run ptp4l in SOFTWARE mode, all goes correctlly.

Did you try increasing tx_timestamp_timeout?
Thanks,
Richard

[Richard Cochran]

Post by Arnold kang
yes, i just set never timeout, but it doesn't work.

But there is no such setting.

???
Richard

[Arnold kang]

yes, this was happed in the fun "sk_receive" <sk.c line 212> , i just set
the poll's third param to a negative value witch means an infinite timeout,
it doesn't work,
and i set the tx_timestamp_timeout to 100, it still doesn't work, i
appreciate
your help.

Post by Richard Cochran

Post by Arnold kang
yes, i just set never timeout, but it doesn't work.

But there is no such setting.
???
Richard

[Richard Cochran]

Post by Arnold kang
yes, this was happed in the fun "sk_receive" <sk.c line 212> , i just set
the poll's third param to a negative value witch means an infinite timeout,
it doesn't work,
and i set the tx_timestamp_timeout to 100, it still doesn't work, i
appreciate
your help.

Okay, then I would instrument the dp83640 driver with kprint in order
to confirm that the packets are being accepted via the function
skb_clone_tx_timestamp() and then later delivered.

The problem is likely to be in your modified MAC driver or in your
modified kernel.

HTH,
Richard

[Arnold kang]

this soc have a TOE (TCP Offload Engine) with mac, i not sure caused by
this module, and i'm sure the DP83640 can accept packet.

Post by Arnold kang

Post by Arnold kang
yes, this was happed in the fun "sk_receive" <sk.c line 212> , i just set
the poll's third param to a negative value witch means an infinite

timeout,

Post by Arnold kang
it doesn't work,
and i set the tx_timestamp_timeout to 100, it still doesn't work, i
appreciate
your help.

Okay, then I would instrument the dp83640 driver with kprint in order
to confirm that the packets are being accepted via the function
skb_clone_tx_timestamp() and then later delivered.
The problem is likely to be in your modified MAC driver or in your
modified kernel.
HTH,
Richard

[Arnold kang]

this link is about TOE,
http://www.emutex.com/case-studies/tcp-offload-engine. thanks you ,
Richard. you give me so much help.

Post by Arnold kang
this soc have a TOE (TCP Offload Engine) with mac, i not sure caused by
this module, and i'm sure the DP83640 can accept packet.

Post by Arnold kang

Post by Arnold kang
yes, this was happed in the fun "sk_receive" <sk.c line 212> , i just

set

Post by Arnold kang
the poll's third param to a negative value witch means an infinite

timeout,

Post by Arnold kang
it doesn't work,
and i set the tx_timestamp_timeout to 100, it still doesn't work, i
appreciate
your help.

Okay, then I would instrument the dp83640 driver with kprint in order
to confirm that the packets are being accepted via the function
skb_clone_tx_timestamp() and then later delivered.
The problem is likely to be in your modified MAC driver or in your
modified kernel.
HTH,
Richard

[Richard Cochran]

Post by Arnold kang
this soc have a TOE (TCP Offload Engine) with mac, i not sure caused by
this module, and i'm sure the DP83640 can accept packet.

Um, you are aware that we are talking about UDP packets?

Thanks,
Richard

[Arnold kang]

sorry, i just afraid TOE will affect it. there is nothing special in mac
driver without TOE


Thanks

Post by Richard Cochran

Post by Arnold kang
this soc have a TOE (TCP Offload Engine) with mac, i not sure caused by
this module, and i'm sure the DP83640 can accept packet.

Um, you are aware that we are talking about UDP packets?
Thanks,
Richard