linuxptp-users Mailing List for linuxptp (Page 142)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users — Open discussion on using the linuxptp software.
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
(10) |
Mar
(47) |
Apr
|
May
(26) |
Jun
(10) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(20) |
Nov
(14) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(6) |
Feb
(18) |
Mar
(27) |
Apr
(57) |
May
(32) |
Jun
(21) |
Jul
(79) |
Aug
(108) |
Sep
(13) |
Oct
(73) |
Nov
(51) |
Dec
(24) |
| 2014 |
Jan
(24) |
Feb
(41) |
Mar
(39) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(7) |
| 2015 |
Jan
(27) |
Feb
(18) |
Mar
(37) |
Apr
(8) |
May
(13) |
Jun
(44) |
Jul
(4) |
Aug
(50) |
Sep
(35) |
Oct
(6) |
Nov
(24) |
Dec
(19) |
| 2016 |
Jan
(30) |
Feb
(30) |
Mar
(23) |
Apr
(4) |
May
(12) |
Jun
(19) |
Jul
(26) |
Aug
(13) |
Sep
|
Oct
(23) |
Nov
(37) |
Dec
(15) |
| 2017 |
Jan
(33) |
Feb
(19) |
Mar
(20) |
Apr
(43) |
May
(39) |
Jun
(23) |
Jul
(20) |
Aug
(27) |
Sep
(10) |
Oct
(15) |
Nov
|
Dec
(24) |
| 2018 |
Jan
(3) |
Feb
(10) |
Mar
(34) |
Apr
(34) |
May
(28) |
Jun
(50) |
Jul
(27) |
Aug
(75) |
Sep
(21) |
Oct
(42) |
Nov
(25) |
Dec
(31) |
| 2019 |
Jan
(39) |
Feb
(28) |
Mar
(19) |
Apr
(7) |
May
(30) |
Jun
(22) |
Jul
(54) |
Aug
(36) |
Sep
(19) |
Oct
(33) |
Nov
(36) |
Dec
(32) |
| 2020 |
Jan
(29) |
Feb
(38) |
Mar
(29) |
Apr
(30) |
May
(39) |
Jun
(45) |
Jul
(31) |
Aug
(52) |
Sep
(40) |
Oct
(8) |
Nov
(48) |
Dec
(30) |
| 2021 |
Jan
(35) |
Feb
(32) |
Mar
(23) |
Apr
(55) |
May
(43) |
Jun
(63) |
Jul
(17) |
Aug
(24) |
Sep
(9) |
Oct
(31) |
Nov
(67) |
Dec
(55) |
| 2022 |
Jan
(31) |
Feb
(48) |
Mar
(76) |
Apr
(18) |
May
(13) |
Jun
(46) |
Jul
(75) |
Aug
(54) |
Sep
(59) |
Oct
(65) |
Nov
(44) |
Dec
(7) |
| 2023 |
Jan
(38) |
Feb
(32) |
Mar
(35) |
Apr
(23) |
May
(46) |
Jun
(53) |
Jul
(18) |
Aug
(10) |
Sep
(24) |
Oct
(15) |
Nov
(40) |
Dec
(6) |
|
From: Jean-Baptiste M. <jea...@pa...> - 2013-10-25 14:27:04
|
Hi,
I know this "poll tx timestamp timeout" have been discussed around here[1] and on
e1000-devel previously, without clear conclusion (to me), and no sure to which list
this should go, but here is my case:
I'm using ptp4l git head with hardware time stamping, on
- Intel i210 with igb driver,
- Intel i210 with igb_avb driver from Open-AVB project[2],
- stmmac.
Intel igb_avb is fine, yet both vanilla igb and stmmac fail with a
"poll tx timestamp timeout" 100% reproducible.
Increasing the tx_timestamp_timeout does not help.
Here is a typical trace with the igb driver on a i210 NIC:
$ sudo ./ptp4l -i eth2-igb -m -l 7
ptp4l[457162.487]: selected /dev/ptp0 as PTP clock
ptp4l[457162.487]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
ptp4l[457162.488]: driver changed our HWTSTAMP options
ptp4l[457162.489]: tx_type 1 not 1
ptp4l[457162.489]: rx_filter 1 not 12
ptp4l[457162.489]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[457162.489]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[457168.489]: port 1: announce timeout
ptp4l[457168.489]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[457168.489]: selected best master clock a0369f.fffe.1c38a8
ptp4l[457168.489]: assuming the grand master role
ptp4l[457168.490]: port 1: master tx announce timeout
ptp4l[457168.490]: port 1: setting asCapable
ptp4l[457169.489]: port 1: master sync timeout
ptp4l[457169.490]: poll tx timestamp timeout
ptp4l[457169.490]: port 1: send sync failed
ptp4l[457169.490]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[457169.491]: waiting 2^{4} seconds to clear fault on port 1
...
My first trial with going back to v1.1 was succesful, but just by luck: 9 times out of 10
I have a "recvmsg tx timestamp failed: Resource temporarily unavailable".
The same goes going back to 2ec3829, just before 76e10e9 "ptp4l: Use poll() instead of a try-again loop".
Increasing the tx_timestamp_retries does not help.
On the kernel side, for driver/ptp/ I'm on 0d8c3e7 "ptp_pch: fix error handling in pch_probe()" for stmmac,
Debian 3.10.7-1 for i210.
To this point, I think this is a hardware driver issue (not really ptp4l nor ptp driver, and hoping this is not
a combination of the 3) but any suggestion would be welcome.
[1] https://sourceforge.net/mailarchive/forum.php?thread_name=20130815062826.GB4679%40netboy&forum_name=linuxptp-devel
[2] https://github.com/intel-ethernet/Open-AVB
--
JB
|
|
From: Ledda W. E. <Wil...@it...> - 2013-10-24 07:26:25
|
Currently I'm working with RH 6.4 kernel 2.6.32-358.2.1. It has full support for PTP and PHC, and it works fine with igb driver 4.0.1-k Reagrd William -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: 23 October 2013 20:45 To: Fabrizio Giordano Cc: Vick, Matthew; Ledda William EXT; lin...@li... Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 On Mon, Oct 21, 2013 at 06:07:21PM +0000, Fabrizio Giordano wrote: > It's basically the standard scientific linux 6.4 kernel. > > uname -a > Linux dorothy8.lab.nbttech.com 2.6.32-358.18.1.el6.x86_64 #1 SMP > PREEMPT Wed Sep 4 16:09:45 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux So it seems that Scientific Linux 6.4 is a rebranded RedHat Enterprise 6.4, and RedHat has back ported the PHC subsystem to 2.6.32. I couldn't find a git tree for RedHat's kernel, so it is hard to say anything about this port. Remember that 3.0 is like 2.6.40, so the port was probably not too easy, and there could very well be bugs. Thanks, Richard |
|
From: Fabrizio G. <Fab...@ri...> - 2013-10-24 05:38:22
|
Just a heads-up: it was the kernel. I tried the version 2.6.32-422 available in RHEL v.6 beta and everything works as expected. They backported all the necessary code to support 82574L in the e1000e driver. Thanks everyone Fabrizio -----Original Message----- From: Keller, Jacob E [mailto:jac...@in...] Sent: Monday, October 21, 2013 16:44 To: Fabrizio Giordano; Richard Cochran Cc: lin...@li... Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 When the LinuxPTP project was started, ptpd did not support hardware timestamping. Richard Cochran made an interface in the kernel to enable generic access to hardware timestamping features, but ptpd did not want to implement this feature. I believe ptpd may have at some point added some support for the kernel module, but I don't know for sure. As far as I know when I last checked, ptpd only does software timestamping. I am unsure why software timestamping fails to work for you in linuxptp. Richard may be able to answer in more detail about the differences between ptpd and ptp4l. Regards, Jake > -----Original Message----- > From: Fabrizio Giordano [mailto:Fab...@ri...] > Sent: Monday, October 21, 2013 4:12 PM > To: Keller, Jacob E; Richard Cochran > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > So I seem to understand there's currently nothing to do with Intel > 82574 and with the kernel I have (both with SW and HW timestamping). > I have a final questions (I hope this is the right place for this question): > what are the pros and cons of using ptpd instead? How is linuxptp > better than ptpd? > I tried to quickly install it on the box with the 82574 and it worked > right away! Is ptpd hardware assisted or is it just SW timestamping? > > Thank you very much to all! > > Fabrizio > > -----Original Message----- > From: Keller, Jacob E [mailto:jac...@in...] > Sent: Monday, October 21, 2013 15:23 > To: Fabrizio Giordano; Richard Cochran > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > The only guess I have for this is that your Scientific Linux kernel > did not properly backport PTP support, which is why force enabling it > causes a panic. > > Regards, > Jake > > > -----Original Message----- > > From: Fabrizio Giordano [mailto:Fab...@ri...] > > Sent: Monday, October 21, 2013 2:49 PM > > To: Keller, Jacob E; Richard Cochran > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > > Hello Jake, > > > > I had already tried that earlier but I figured that that check > > (kernel > > >= 3) was necessary since when I rebooted the machine with the > e1000e > > driver I got a kernel panic (I didn't spend too much time debugging it). > > Here's the output I got: > > > > > > e1000e: Intel(R) PRO/1000 Network Driver - 2.5.4-NAPI > > e1000e: Copyright(c) 1999 - 2013 Intel Corporation. > > e1000e 0000:03:00.0: Disabling ASPM L0s L1 e1000e 0000:03:00.0: > PCI > > INT A -> GSI 16 (level, low) -> IRQ 16 e1000e 0000:03:00.0: > > Interrupt Throttling Rate (ints/sec) set to dynamic conservative > > mode > > bio: create slab <bio-1> at 1 > > md/raid0:md0: md_size is 62499647488 sectors. > > md: RAID0 configuration for md0 - 1 zone > > BUG: unable to handle kernel NULL pointer dereference at > > 00000000000002ce > > IP: [<ffffffff812788bc>] kref_get+0xc/0x30 PGD 339612067 PUD > 339f03067 > > PMD 0 > > Oops: 0000 [#1] PREEMPT SMP > > last sysfs file: /sys/module/raid0/initstate CPU 8 Modules linked in: > > e1000e(+)(U) ptp pps_core ioatdma dca i7core_edac edac_core sg > ext4 > > jbd2 mbcache raid0 sr_mod cdrom sd_mod crc_t10dif ahci 3w_9xxx > dm_mod > > [last unloaded: scsi_wait_scan] > > > > Pid: 1016, comm: modprobe Not tainted 2.6.32- > > 358.18.1.el6.rvbd.1.x86_64 #1 Supermicro X8DT6/X8DT6 > > RIP: 0010:[<ffffffff812788bc>] [<ffffffff812788bc>] > > kref_get+0xc/0x30 > > RSP: 0018:ffff88063893d9d8 EFLAGS: 00010296 > > RAX: 0000000000000000 RBX: 00000000000002ce RCX: > > 0000000000000030 > > RDX: 0000000000000000 RSI: ffff88033828d9e0 RDI: > > 00000000000002ce > > RBP: ffff88063893d9e8 R08: 0000000000000000 R09: > 00000000fffffffe > > R10: 0000000000000000 R11: 0000000000000000 R12: > > 000000000f600000 > > R13: 0000000000000286 R14: 00000000ffffffea R15: > ffff88033af60c00 > > FS: 00007f94ea831700(0000) GS:ffff880028280000(0000) > > knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > > CR2: 00000000000002ce CR3: 0000000339617000 CR4: > > 00000000000007e0 > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: > > 0000000000000000 > > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: > > 0000000000000400 > > Process modprobe (pid: 1016, threadinfo ffff88063893c000, task > > ffff88063799e040) > > Stack: > > 0000000000000003 0000000000000296 ffff88063893da08 > ffffffff8127754a > > <d> 0000000200000010 ffff88033af60c00 ffff88063893da18 > > ffffffff8134f6b9 > > <d> ffff88063893da98 ffffffff81350c6b ffff88033828d9e0 > > 0000000000000005 > > Call Trace: > > [<ffffffff8127754a>] kobject_get+0x1a/0x30 [<ffffffff8134f6b9>] > > get_device+0x19/0x20 [<ffffffff81350c6b>] device_add+0x8b/0x650 > > [<ffffffff81359fbb>] ? pm_runtime_init+0xcb/0xe0 > [<ffffffff8135124e>] > > device_register+0x1e/0x30 [<ffffffff81351348>] > > device_create_vargs+0xe8/0x110 [<ffffffff813513a1>] > > device_create+0x31/0x40 [<ffffffffa0043614>] > > ptp_clock_register+0x224/0x360 [ptp] [<ffffffff81076b68>] ? > > add_timer+0x18/0x30 [<ffffffff81085569>] ? > > queue_delayed_work_on+0xb9/0x120 [<ffffffffa016acff>] > > e1000e_ptp_init+0x10f/0x210 [e1000e] [<ffffffffa016bf3e>] > > e1000_probe+0xbe6/0xf66 [e1000e] [<ffffffff811965d0>] ? > > iput+0x30/0x70 [<ffffffff811f6570>] ? sysfs_addrm_finish+0x50/0x280 > > [<ffffffff811f6e2e>] ? __sysfs_add_one+0x7e/0xc0 > [<ffffffff81297977>] > > local_pci_probe+0x17/0x20 [<ffffffff81298b71>] > > pci_device_probe+0x101/0x120 [<ffffffff81353c82>] ? > > driver_sysfs_add+0x62/0x90 [<ffffffff81353e20>] > > driver_probe_device+0xa0/0x2a0 [<ffffffff813540cb>] > > __driver_attach+0xab/0xb0 [<ffffffff81354020>] ? > > __driver_attach+0x0/0xb0 [<ffffffff813533d4>] > > bus_for_each_dev+0x64/0x90 [<ffffffff81353bbe>] > > driver_attach+0x1e/0x20 [<ffffffff81352c08>] > > bus_add_driver+0x1e8/0x2b0 [<ffffffff81354416>] > > driver_register+0x76/0x140 [<ffffffff81506b2a>] ? printk+0x41/0x47 > > [<ffffffff81298dd6>] __pci_register_driver+0x56/0xd0 > > [<ffffffffa00e8000>] ? e1000_init_module+0x0/0x43 [e1000e] > > [<ffffffffa00e8041>] e1000_init_module+0x41/0x43 [e1000e] > > [<ffffffff810001ec>] do_one_initcall+0x3c/0x1d0 > > [<ffffffff810ac051>] > > sys_init_module+0xe1/0x250 [<ffffffff810030b2>] > > system_call_fastpath+0x16/0x1b > > Code: 7c 81 e8 88 9f de ff eb cb be 40 00 00 00 48 c7 c7 3f 2b 7c 81 > > e8 > > 75 9f de ff eb b8 0f 1f 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 <8b> > > 07 > > 85 c0 74 0a f0 ff 03 48 83 c4 08 5b c9 c3 be 2b 00 00 00 RIP > > [<ffffffff812788bc>] kref_get+0xc/0x30 RSP <ffff88063893d9d8> > > CR2: 00000000000002ce > > ---[ end trace 4ad683c7806b9327 ]--- Kernel panic - not syncing: > > Fatal exception > > Pid: 1016, comm: modprobe Tainted: G D --------------- 2.6.32- > > 358.18.1.el6.rvbd.1.x86_64 #1 > > Call Trace: > > [<ffffffff81506a21>] ? panic+0xa7/0x16f [<ffffffff8150b254>] ? > > oops_end+0xe4/0x100 [<ffffffff8103a98b>] ? no_context+0xfb/0x260 > > [<ffffffff8103ac15>] ? __bad_area_nosemaphore+0x125/0x1e0 > > [<ffffffff8103ad3e>] ? bad_area+0x4e/0x60 [<ffffffff8103b1ae>] ? > > __do_page_fault+0x26e/0x500 [<ffffffff8150cace>] ? > > do_page_fault+0x3e/0xd0 [<ffffffff8150a535>] ? > page_fault+0x25/0x30 > > [<ffffffff812788bc>] ? kref_get+0xc/0x30 [<ffffffff8127754a>] ? > > kobject_get+0x1a/0x30 [<ffffffff8134f6b9>] ? get_device+0x19/0x20 > > [<ffffffff81350c6b>] ? device_add+0x8b/0x650 [<ffffffff81359fbb>] ? > > pm_runtime_init+0xcb/0xe0 [<ffffffff8135124e>] ? > > device_register+0x1e/0x30 [<ffffffff81351348>] ? > > device_create_vargs+0xe8/0x110 [<ffffffff813513a1>] ? > > device_create+0x31/0x40 [<ffffffffa0043614>] ? > > ptp_clock_register+0x224/0x360 [ptp] [<ffffffff81076b68>] ? > > add_timer+0x18/0x30 [<ffffffff81085569>] ? > > queue_delayed_work_on+0xb9/0x120 [<ffffffffa016acff>] ? > > e1000e_ptp_init+0x10f/0x210 [e1000e] [<ffffffffa016bf3e>] ? > > e1000_probe+0xbe6/0xf66 [e1000e] [<ffffffff811965d0>] ? > > iput+0x30/0x70 [<ffffffff811f6570>] ? sysfs_addrm_finish+0x50/0x280 > > [<ffffffff811f6e2e>] ? __sysfs_add_one+0x7e/0xc0 > [<ffffffff81297977>] > > ? local_pci_probe+0x17/0x20 [<ffffffff81298b71>] ? > > pci_device_probe+0x101/0x120 [<ffffffff81353c82>] ? > > driver_sysfs_add+0x62/0x90 [<ffffffff81353e20>] ? > > driver_probe_device+0xa0/0x2a0 [<ffffffff813540cb>] ? > > __driver_attach+0xab/0xb0 [<ffffffff81354020>] ? > > __driver_attach+0x0/0xb0 [<ffffffff813533d4>] ? > > bus_for_each_dev+0x64/0x90 [<ffffffff81353bbe>] ? > > driver_attach+0x1e/0x20 [<ffffffff81352c08>] ? > > bus_add_driver+0x1e8/0x2b0 [<ffffffff81354416>] ? > > driver_register+0x76/0x140 [<ffffffff81506b2a>] ? printk+0x41/0x47 > > [<ffffffff81298dd6>] ? __pci_register_driver+0x56/0xd0 > > [<ffffffffa00e8000>] ? e1000_init_module+0x0/0x43 [e1000e] > > [<ffffffffa00e8041>] ? e1000_init_module+0x41/0x43 [e1000e] > > [<ffffffff810001ec>] ? do_one_initcall+0x3c/0x1d0 > > [<ffffffff810ac051>] ? sys_init_module+0xe1/0x250 > > [<ffffffff810030b2>] ? system_call_fastpath+0x16/0x1b > > > > > > -----Original Message----- > > From: Keller, Jacob E [mailto:jac...@in...] > > Sent: Monday, October 21, 2013 14:13 > > To: Fabrizio Giordano; Richard Cochran > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > > Hi Fabrizio, > > > > The sourceforge driver for e1000e has a hard check for kernel version. > > Since you have a specialized kernel version that has backported PTP > > support, you might try modifying the kcompat.h of the sourceforge > > driver, and removing the kernel check. > > > > Basically, the kernel compat layer is blocking proper enablement of > > the PTP core because it assumes your kernel can't have support. You > > won't be able to get correct support without the flag properly enabling. > > > > Regards, > > Jake > > > > > -----Original Message----- > > > From: Fabrizio Giordano [mailto:Fab...@ri...] > > > Sent: Monday, October 21, 2013 11:07 AM > > > To: Richard Cochran > > > Cc: lin...@li... > > > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > > > > It's basically the standard scientific linux 6.4 kernel. > > > > > > uname -a > > > Linux dorothy8.lab.nbttech.com 2.6.32-358.18.1.el6.x86_64 #1 SMP > > > PREEMPT Wed Sep 4 16:09:45 EDT 2013 x86_64 x86_64 x86_64 > > GNU/Linux > > > > > > -----Original Message----- > > > From: Richard Cochran [mailto:ric...@gm...] > > > Sent: Monday, October 21, 2013 10:49 > > > To: Fabrizio Giordano > > > Cc: Vick, Matthew; Ledda William EXT; linuxptp- > > > us...@li... > > > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > > > > On Mon, Oct 21, 2013 at 05:32:54PM +0000, Fabrizio Giordano > wrote: > > > > No that's what I find odd... > > > > On another machine I have the exact same kernel but I installed > > > > an Intel > > > 82576. > > > > Here's what ethtool -T returns: > > > > > > > > ethtool -T eth0 > > > > Time stamping parameters for eth0: > > > > Capabilities: > > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > > > PTP Hardware Clock: 0 > > > > > > Okay, so what do you get from `uname -a`? > > > > > > > And it actually works with HW timestamps. If it works with > > > > another NIC > > > and the same kernel I expect that with the proper driver it should > > > work also with a 82574. > > > > Or am I wrong? > > > > > > Tell us more about your kernel. Where did you get it from? > > > Is the source available somewhere to look at? > > > > > > Thanks, > > > Richard > > > > > > ------------------------------------------------------------------ > > > -- > > > -- > > > -------- October Webinars: Code for Performance Free Intel > > > webinars can help you accelerate application performance. > > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get > > > the most from the latest Intel processors and coprocessors. See > > > abstracts and register > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ost > > > g.clktrk > > > _______________________________________________ > > > Linuxptp-users mailing list > > > Lin...@li... > > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Richard C. <ric...@gm...> - 2013-10-23 18:44:48
|
On Mon, Oct 21, 2013 at 06:07:21PM +0000, Fabrizio Giordano wrote: > It's basically the standard scientific linux 6.4 kernel. > > uname -a > Linux dorothy8.lab.nbttech.com 2.6.32-358.18.1.el6.x86_64 #1 SMP PREEMPT Wed Sep 4 16:09:45 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux So it seems that Scientific Linux 6.4 is a rebranded RedHat Enterprise 6.4, and RedHat has back ported the PHC subsystem to 2.6.32. I couldn't find a git tree for RedHat's kernel, so it is hard to say anything about this port. Remember that 3.0 is like 2.6.40, so the port was probably not too easy, and there could very well be bugs. Thanks, Richard |
|
From: Keller, J. E <jac...@in...> - 2013-10-21 23:44:12
|
When the LinuxPTP project was started, ptpd did not support hardware timestamping. Richard Cochran made an interface in the kernel to enable generic access to hardware timestamping features, but ptpd did not want to implement this feature. I believe ptpd may have at some point added some support for the kernel module, but I don't know for sure. As far as I know when I last checked, ptpd only does software timestamping. I am unsure why software timestamping fails to work for you in linuxptp. Richard may be able to answer in more detail about the differences between ptpd and ptp4l. Regards, Jake > -----Original Message----- > From: Fabrizio Giordano [mailto:Fab...@ri...] > Sent: Monday, October 21, 2013 4:12 PM > To: Keller, Jacob E; Richard Cochran > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > So I seem to understand there's currently nothing to do with Intel 82574 > and with the kernel I have (both with SW and HW timestamping). > I have a final questions (I hope this is the right place for this question): > what are the pros and cons of using ptpd instead? How is linuxptp better > than ptpd? > I tried to quickly install it on the box with the 82574 and it worked right > away! Is ptpd hardware assisted or is it just SW timestamping? > > Thank you very much to all! > > Fabrizio > > -----Original Message----- > From: Keller, Jacob E [mailto:jac...@in...] > Sent: Monday, October 21, 2013 15:23 > To: Fabrizio Giordano; Richard Cochran > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > The only guess I have for this is that your Scientific Linux kernel did not > properly backport PTP support, which is why force enabling it causes a > panic. > > Regards, > Jake > > > -----Original Message----- > > From: Fabrizio Giordano [mailto:Fab...@ri...] > > Sent: Monday, October 21, 2013 2:49 PM > > To: Keller, Jacob E; Richard Cochran > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > > Hello Jake, > > > > I had already tried that earlier but I figured that that check (kernel > > >= 3) was necessary since when I rebooted the machine with the > e1000e > > driver I got a kernel panic (I didn't spend too much time debugging it). > > Here's the output I got: > > > > > > e1000e: Intel(R) PRO/1000 Network Driver - 2.5.4-NAPI > > e1000e: Copyright(c) 1999 - 2013 Intel Corporation. > > e1000e 0000:03:00.0: Disabling ASPM L0s L1 e1000e 0000:03:00.0: > PCI > > INT A -> GSI 16 (level, low) -> IRQ 16 e1000e 0000:03:00.0: Interrupt > > Throttling Rate (ints/sec) set to dynamic conservative mode > > bio: create slab <bio-1> at 1 > > md/raid0:md0: md_size is 62499647488 sectors. > > md: RAID0 configuration for md0 - 1 zone > > BUG: unable to handle kernel NULL pointer dereference at > > 00000000000002ce > > IP: [<ffffffff812788bc>] kref_get+0xc/0x30 PGD 339612067 PUD > 339f03067 > > PMD 0 > > Oops: 0000 [#1] PREEMPT SMP > > last sysfs file: /sys/module/raid0/initstate CPU 8 Modules linked in: > > e1000e(+)(U) ptp pps_core ioatdma dca i7core_edac edac_core sg > ext4 > > jbd2 mbcache raid0 sr_mod cdrom sd_mod crc_t10dif ahci 3w_9xxx > dm_mod > > [last unloaded: scsi_wait_scan] > > > > Pid: 1016, comm: modprobe Not tainted 2.6.32- > > 358.18.1.el6.rvbd.1.x86_64 #1 Supermicro X8DT6/X8DT6 > > RIP: 0010:[<ffffffff812788bc>] [<ffffffff812788bc>] kref_get+0xc/0x30 > > RSP: 0018:ffff88063893d9d8 EFLAGS: 00010296 > > RAX: 0000000000000000 RBX: 00000000000002ce RCX: > > 0000000000000030 > > RDX: 0000000000000000 RSI: ffff88033828d9e0 RDI: > > 00000000000002ce > > RBP: ffff88063893d9e8 R08: 0000000000000000 R09: > 00000000fffffffe > > R10: 0000000000000000 R11: 0000000000000000 R12: > > 000000000f600000 > > R13: 0000000000000286 R14: 00000000ffffffea R15: > ffff88033af60c00 > > FS: 00007f94ea831700(0000) GS:ffff880028280000(0000) > > knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > > CR2: 00000000000002ce CR3: 0000000339617000 CR4: > > 00000000000007e0 > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: > > 0000000000000000 > > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: > > 0000000000000400 > > Process modprobe (pid: 1016, threadinfo ffff88063893c000, task > > ffff88063799e040) > > Stack: > > 0000000000000003 0000000000000296 ffff88063893da08 > ffffffff8127754a > > <d> 0000000200000010 ffff88033af60c00 ffff88063893da18 > > ffffffff8134f6b9 > > <d> ffff88063893da98 ffffffff81350c6b ffff88033828d9e0 > > 0000000000000005 > > Call Trace: > > [<ffffffff8127754a>] kobject_get+0x1a/0x30 [<ffffffff8134f6b9>] > > get_device+0x19/0x20 [<ffffffff81350c6b>] device_add+0x8b/0x650 > > [<ffffffff81359fbb>] ? pm_runtime_init+0xcb/0xe0 > [<ffffffff8135124e>] > > device_register+0x1e/0x30 [<ffffffff81351348>] > > device_create_vargs+0xe8/0x110 [<ffffffff813513a1>] > > device_create+0x31/0x40 [<ffffffffa0043614>] > > ptp_clock_register+0x224/0x360 [ptp] [<ffffffff81076b68>] ? > > add_timer+0x18/0x30 [<ffffffff81085569>] ? > > queue_delayed_work_on+0xb9/0x120 [<ffffffffa016acff>] > > e1000e_ptp_init+0x10f/0x210 [e1000e] [<ffffffffa016bf3e>] > > e1000_probe+0xbe6/0xf66 [e1000e] [<ffffffff811965d0>] ? > > iput+0x30/0x70 [<ffffffff811f6570>] ? sysfs_addrm_finish+0x50/0x280 > > [<ffffffff811f6e2e>] ? __sysfs_add_one+0x7e/0xc0 > [<ffffffff81297977>] > > local_pci_probe+0x17/0x20 [<ffffffff81298b71>] > > pci_device_probe+0x101/0x120 [<ffffffff81353c82>] ? > > driver_sysfs_add+0x62/0x90 [<ffffffff81353e20>] > > driver_probe_device+0xa0/0x2a0 [<ffffffff813540cb>] > > __driver_attach+0xab/0xb0 [<ffffffff81354020>] ? > > __driver_attach+0x0/0xb0 [<ffffffff813533d4>] > > bus_for_each_dev+0x64/0x90 [<ffffffff81353bbe>] > > driver_attach+0x1e/0x20 [<ffffffff81352c08>] > > bus_add_driver+0x1e8/0x2b0 [<ffffffff81354416>] > > driver_register+0x76/0x140 [<ffffffff81506b2a>] ? printk+0x41/0x47 > > [<ffffffff81298dd6>] __pci_register_driver+0x56/0xd0 > > [<ffffffffa00e8000>] ? e1000_init_module+0x0/0x43 [e1000e] > > [<ffffffffa00e8041>] e1000_init_module+0x41/0x43 [e1000e] > > [<ffffffff810001ec>] do_one_initcall+0x3c/0x1d0 [<ffffffff810ac051>] > > sys_init_module+0xe1/0x250 [<ffffffff810030b2>] > > system_call_fastpath+0x16/0x1b > > Code: 7c 81 e8 88 9f de ff eb cb be 40 00 00 00 48 c7 c7 3f 2b 7c 81 > > e8 > > 75 9f de ff eb b8 0f 1f 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 <8b> 07 > > 85 c0 74 0a f0 ff 03 48 83 c4 08 5b c9 c3 be 2b 00 00 00 RIP > > [<ffffffff812788bc>] kref_get+0xc/0x30 RSP <ffff88063893d9d8> > > CR2: 00000000000002ce > > ---[ end trace 4ad683c7806b9327 ]--- > > Kernel panic - not syncing: Fatal exception > > Pid: 1016, comm: modprobe Tainted: G D --------------- 2.6.32- > > 358.18.1.el6.rvbd.1.x86_64 #1 > > Call Trace: > > [<ffffffff81506a21>] ? panic+0xa7/0x16f [<ffffffff8150b254>] ? > > oops_end+0xe4/0x100 [<ffffffff8103a98b>] ? no_context+0xfb/0x260 > > [<ffffffff8103ac15>] ? __bad_area_nosemaphore+0x125/0x1e0 > > [<ffffffff8103ad3e>] ? bad_area+0x4e/0x60 [<ffffffff8103b1ae>] ? > > __do_page_fault+0x26e/0x500 [<ffffffff8150cace>] ? > > do_page_fault+0x3e/0xd0 [<ffffffff8150a535>] ? > page_fault+0x25/0x30 > > [<ffffffff812788bc>] ? kref_get+0xc/0x30 [<ffffffff8127754a>] ? > > kobject_get+0x1a/0x30 [<ffffffff8134f6b9>] ? get_device+0x19/0x20 > > [<ffffffff81350c6b>] ? device_add+0x8b/0x650 [<ffffffff81359fbb>] ? > > pm_runtime_init+0xcb/0xe0 [<ffffffff8135124e>] ? > > device_register+0x1e/0x30 [<ffffffff81351348>] ? > > device_create_vargs+0xe8/0x110 [<ffffffff813513a1>] ? > > device_create+0x31/0x40 [<ffffffffa0043614>] ? > > ptp_clock_register+0x224/0x360 [ptp] [<ffffffff81076b68>] ? > > add_timer+0x18/0x30 [<ffffffff81085569>] ? > > queue_delayed_work_on+0xb9/0x120 [<ffffffffa016acff>] ? > > e1000e_ptp_init+0x10f/0x210 [e1000e] [<ffffffffa016bf3e>] ? > > e1000_probe+0xbe6/0xf66 [e1000e] [<ffffffff811965d0>] ? > > iput+0x30/0x70 [<ffffffff811f6570>] ? sysfs_addrm_finish+0x50/0x280 > > [<ffffffff811f6e2e>] ? __sysfs_add_one+0x7e/0xc0 > [<ffffffff81297977>] > > ? local_pci_probe+0x17/0x20 [<ffffffff81298b71>] ? > > pci_device_probe+0x101/0x120 [<ffffffff81353c82>] ? > > driver_sysfs_add+0x62/0x90 [<ffffffff81353e20>] ? > > driver_probe_device+0xa0/0x2a0 [<ffffffff813540cb>] ? > > __driver_attach+0xab/0xb0 [<ffffffff81354020>] ? > > __driver_attach+0x0/0xb0 [<ffffffff813533d4>] ? > > bus_for_each_dev+0x64/0x90 [<ffffffff81353bbe>] ? > > driver_attach+0x1e/0x20 [<ffffffff81352c08>] ? > > bus_add_driver+0x1e8/0x2b0 [<ffffffff81354416>] ? > > driver_register+0x76/0x140 [<ffffffff81506b2a>] ? printk+0x41/0x47 > > [<ffffffff81298dd6>] ? __pci_register_driver+0x56/0xd0 > > [<ffffffffa00e8000>] ? e1000_init_module+0x0/0x43 [e1000e] > > [<ffffffffa00e8041>] ? e1000_init_module+0x41/0x43 [e1000e] > > [<ffffffff810001ec>] ? do_one_initcall+0x3c/0x1d0 > > [<ffffffff810ac051>] ? sys_init_module+0xe1/0x250 > > [<ffffffff810030b2>] ? system_call_fastpath+0x16/0x1b > > > > > > -----Original Message----- > > From: Keller, Jacob E [mailto:jac...@in...] > > Sent: Monday, October 21, 2013 14:13 > > To: Fabrizio Giordano; Richard Cochran > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > > Hi Fabrizio, > > > > The sourceforge driver for e1000e has a hard check for kernel version. > > Since you have a specialized kernel version that has backported PTP > > support, you might try modifying the kcompat.h of the sourceforge > > driver, and removing the kernel check. > > > > Basically, the kernel compat layer is blocking proper enablement of > > the PTP core because it assumes your kernel can't have support. You > > won't be able to get correct support without the flag properly enabling. > > > > Regards, > > Jake > > > > > -----Original Message----- > > > From: Fabrizio Giordano [mailto:Fab...@ri...] > > > Sent: Monday, October 21, 2013 11:07 AM > > > To: Richard Cochran > > > Cc: lin...@li... > > > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > > > > It's basically the standard scientific linux 6.4 kernel. > > > > > > uname -a > > > Linux dorothy8.lab.nbttech.com 2.6.32-358.18.1.el6.x86_64 #1 SMP > > > PREEMPT Wed Sep 4 16:09:45 EDT 2013 x86_64 x86_64 x86_64 > > GNU/Linux > > > > > > -----Original Message----- > > > From: Richard Cochran [mailto:ric...@gm...] > > > Sent: Monday, October 21, 2013 10:49 > > > To: Fabrizio Giordano > > > Cc: Vick, Matthew; Ledda William EXT; linuxptp- > > > us...@li... > > > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > > > > On Mon, Oct 21, 2013 at 05:32:54PM +0000, Fabrizio Giordano > wrote: > > > > No that's what I find odd... > > > > On another machine I have the exact same kernel but I installed an > > > > Intel > > > 82576. > > > > Here's what ethtool -T returns: > > > > > > > > ethtool -T eth0 > > > > Time stamping parameters for eth0: > > > > Capabilities: > > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > > > PTP Hardware Clock: 0 > > > > > > Okay, so what do you get from `uname -a`? > > > > > > > And it actually works with HW timestamps. If it works with another > > > > NIC > > > and the same kernel I expect that with the proper driver it should > > > work also with a 82574. > > > > Or am I wrong? > > > > > > Tell us more about your kernel. Where did you get it from? > > > Is the source available somewhere to look at? > > > > > > Thanks, > > > Richard > > > > > > -------------------------------------------------------------------- > > > -- > > > -------- October Webinars: Code for Performance Free Intel webinars > > > can help you accelerate application performance. > > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > > > most from the latest Intel processors and coprocessors. See > > > abstracts and register > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ost > > > g.clktrk > > > _______________________________________________ > > > Linuxptp-users mailing list > > > Lin...@li... > > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Fabrizio G. <Fab...@ri...> - 2013-10-21 23:11:46
|
So I seem to understand there's currently nothing to do with Intel 82574 and with the kernel I have (both with SW and HW timestamping). I have a final questions (I hope this is the right place for this question): what are the pros and cons of using ptpd instead? How is linuxptp better than ptpd? I tried to quickly install it on the box with the 82574 and it worked right away! Is ptpd hardware assisted or is it just SW timestamping? Thank you very much to all! Fabrizio -----Original Message----- From: Keller, Jacob E [mailto:jac...@in...] Sent: Monday, October 21, 2013 15:23 To: Fabrizio Giordano; Richard Cochran Cc: lin...@li... Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 The only guess I have for this is that your Scientific Linux kernel did not properly backport PTP support, which is why force enabling it causes a panic. Regards, Jake > -----Original Message----- > From: Fabrizio Giordano [mailto:Fab...@ri...] > Sent: Monday, October 21, 2013 2:49 PM > To: Keller, Jacob E; Richard Cochran > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > Hello Jake, > > I had already tried that earlier but I figured that that check (kernel > >= 3) was necessary since when I rebooted the machine with the e1000e > driver I got a kernel panic (I didn't spend too much time debugging it). > Here's the output I got: > > > e1000e: Intel(R) PRO/1000 Network Driver - 2.5.4-NAPI > e1000e: Copyright(c) 1999 - 2013 Intel Corporation. > e1000e 0000:03:00.0: Disabling ASPM L0s L1 e1000e 0000:03:00.0: PCI > INT A -> GSI 16 (level, low) -> IRQ 16 e1000e 0000:03:00.0: Interrupt > Throttling Rate (ints/sec) set to dynamic conservative mode > bio: create slab <bio-1> at 1 > md/raid0:md0: md_size is 62499647488 sectors. > md: RAID0 configuration for md0 - 1 zone > BUG: unable to handle kernel NULL pointer dereference at > 00000000000002ce > IP: [<ffffffff812788bc>] kref_get+0xc/0x30 PGD 339612067 PUD 339f03067 > PMD 0 > Oops: 0000 [#1] PREEMPT SMP > last sysfs file: /sys/module/raid0/initstate CPU 8 Modules linked in: > e1000e(+)(U) ptp pps_core ioatdma dca i7core_edac edac_core sg ext4 > jbd2 mbcache raid0 sr_mod cdrom sd_mod crc_t10dif ahci 3w_9xxx dm_mod > [last unloaded: scsi_wait_scan] > > Pid: 1016, comm: modprobe Not tainted 2.6.32- > 358.18.1.el6.rvbd.1.x86_64 #1 Supermicro X8DT6/X8DT6 > RIP: 0010:[<ffffffff812788bc>] [<ffffffff812788bc>] kref_get+0xc/0x30 > RSP: 0018:ffff88063893d9d8 EFLAGS: 00010296 > RAX: 0000000000000000 RBX: 00000000000002ce RCX: > 0000000000000030 > RDX: 0000000000000000 RSI: ffff88033828d9e0 RDI: > 00000000000002ce > RBP: ffff88063893d9e8 R08: 0000000000000000 R09: 00000000fffffffe > R10: 0000000000000000 R11: 0000000000000000 R12: > 000000000f600000 > R13: 0000000000000286 R14: 00000000ffffffea R15: ffff88033af60c00 > FS: 00007f94ea831700(0000) GS:ffff880028280000(0000) > knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 00000000000002ce CR3: 0000000339617000 CR4: > 00000000000007e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: > 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: > 0000000000000400 > Process modprobe (pid: 1016, threadinfo ffff88063893c000, task > ffff88063799e040) > Stack: > 0000000000000003 0000000000000296 ffff88063893da08 ffffffff8127754a > <d> 0000000200000010 ffff88033af60c00 ffff88063893da18 > ffffffff8134f6b9 > <d> ffff88063893da98 ffffffff81350c6b ffff88033828d9e0 > 0000000000000005 > Call Trace: > [<ffffffff8127754a>] kobject_get+0x1a/0x30 [<ffffffff8134f6b9>] > get_device+0x19/0x20 [<ffffffff81350c6b>] device_add+0x8b/0x650 > [<ffffffff81359fbb>] ? pm_runtime_init+0xcb/0xe0 [<ffffffff8135124e>] > device_register+0x1e/0x30 [<ffffffff81351348>] > device_create_vargs+0xe8/0x110 [<ffffffff813513a1>] > device_create+0x31/0x40 [<ffffffffa0043614>] > ptp_clock_register+0x224/0x360 [ptp] [<ffffffff81076b68>] ? > add_timer+0x18/0x30 [<ffffffff81085569>] ? > queue_delayed_work_on+0xb9/0x120 [<ffffffffa016acff>] > e1000e_ptp_init+0x10f/0x210 [e1000e] [<ffffffffa016bf3e>] > e1000_probe+0xbe6/0xf66 [e1000e] [<ffffffff811965d0>] ? > iput+0x30/0x70 [<ffffffff811f6570>] ? sysfs_addrm_finish+0x50/0x280 > [<ffffffff811f6e2e>] ? __sysfs_add_one+0x7e/0xc0 [<ffffffff81297977>] > local_pci_probe+0x17/0x20 [<ffffffff81298b71>] > pci_device_probe+0x101/0x120 [<ffffffff81353c82>] ? > driver_sysfs_add+0x62/0x90 [<ffffffff81353e20>] > driver_probe_device+0xa0/0x2a0 [<ffffffff813540cb>] > __driver_attach+0xab/0xb0 [<ffffffff81354020>] ? > __driver_attach+0x0/0xb0 [<ffffffff813533d4>] > bus_for_each_dev+0x64/0x90 [<ffffffff81353bbe>] > driver_attach+0x1e/0x20 [<ffffffff81352c08>] > bus_add_driver+0x1e8/0x2b0 [<ffffffff81354416>] > driver_register+0x76/0x140 [<ffffffff81506b2a>] ? printk+0x41/0x47 > [<ffffffff81298dd6>] __pci_register_driver+0x56/0xd0 > [<ffffffffa00e8000>] ? e1000_init_module+0x0/0x43 [e1000e] > [<ffffffffa00e8041>] e1000_init_module+0x41/0x43 [e1000e] > [<ffffffff810001ec>] do_one_initcall+0x3c/0x1d0 [<ffffffff810ac051>] > sys_init_module+0xe1/0x250 [<ffffffff810030b2>] > system_call_fastpath+0x16/0x1b > Code: 7c 81 e8 88 9f de ff eb cb be 40 00 00 00 48 c7 c7 3f 2b 7c 81 > e8 > 75 9f de ff eb b8 0f 1f 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 <8b> 07 > 85 c0 74 0a f0 ff 03 48 83 c4 08 5b c9 c3 be 2b 00 00 00 RIP > [<ffffffff812788bc>] kref_get+0xc/0x30 RSP <ffff88063893d9d8> > CR2: 00000000000002ce > ---[ end trace 4ad683c7806b9327 ]--- > Kernel panic - not syncing: Fatal exception > Pid: 1016, comm: modprobe Tainted: G D --------------- 2.6.32- > 358.18.1.el6.rvbd.1.x86_64 #1 > Call Trace: > [<ffffffff81506a21>] ? panic+0xa7/0x16f [<ffffffff8150b254>] ? > oops_end+0xe4/0x100 [<ffffffff8103a98b>] ? no_context+0xfb/0x260 > [<ffffffff8103ac15>] ? __bad_area_nosemaphore+0x125/0x1e0 > [<ffffffff8103ad3e>] ? bad_area+0x4e/0x60 [<ffffffff8103b1ae>] ? > __do_page_fault+0x26e/0x500 [<ffffffff8150cace>] ? > do_page_fault+0x3e/0xd0 [<ffffffff8150a535>] ? page_fault+0x25/0x30 > [<ffffffff812788bc>] ? kref_get+0xc/0x30 [<ffffffff8127754a>] ? > kobject_get+0x1a/0x30 [<ffffffff8134f6b9>] ? get_device+0x19/0x20 > [<ffffffff81350c6b>] ? device_add+0x8b/0x650 [<ffffffff81359fbb>] ? > pm_runtime_init+0xcb/0xe0 [<ffffffff8135124e>] ? > device_register+0x1e/0x30 [<ffffffff81351348>] ? > device_create_vargs+0xe8/0x110 [<ffffffff813513a1>] ? > device_create+0x31/0x40 [<ffffffffa0043614>] ? > ptp_clock_register+0x224/0x360 [ptp] [<ffffffff81076b68>] ? > add_timer+0x18/0x30 [<ffffffff81085569>] ? > queue_delayed_work_on+0xb9/0x120 [<ffffffffa016acff>] ? > e1000e_ptp_init+0x10f/0x210 [e1000e] [<ffffffffa016bf3e>] ? > e1000_probe+0xbe6/0xf66 [e1000e] [<ffffffff811965d0>] ? > iput+0x30/0x70 [<ffffffff811f6570>] ? sysfs_addrm_finish+0x50/0x280 > [<ffffffff811f6e2e>] ? __sysfs_add_one+0x7e/0xc0 [<ffffffff81297977>] > ? local_pci_probe+0x17/0x20 [<ffffffff81298b71>] ? > pci_device_probe+0x101/0x120 [<ffffffff81353c82>] ? > driver_sysfs_add+0x62/0x90 [<ffffffff81353e20>] ? > driver_probe_device+0xa0/0x2a0 [<ffffffff813540cb>] ? > __driver_attach+0xab/0xb0 [<ffffffff81354020>] ? > __driver_attach+0x0/0xb0 [<ffffffff813533d4>] ? > bus_for_each_dev+0x64/0x90 [<ffffffff81353bbe>] ? > driver_attach+0x1e/0x20 [<ffffffff81352c08>] ? > bus_add_driver+0x1e8/0x2b0 [<ffffffff81354416>] ? > driver_register+0x76/0x140 [<ffffffff81506b2a>] ? printk+0x41/0x47 > [<ffffffff81298dd6>] ? __pci_register_driver+0x56/0xd0 > [<ffffffffa00e8000>] ? e1000_init_module+0x0/0x43 [e1000e] > [<ffffffffa00e8041>] ? e1000_init_module+0x41/0x43 [e1000e] > [<ffffffff810001ec>] ? do_one_initcall+0x3c/0x1d0 > [<ffffffff810ac051>] ? sys_init_module+0xe1/0x250 > [<ffffffff810030b2>] ? system_call_fastpath+0x16/0x1b > > > -----Original Message----- > From: Keller, Jacob E [mailto:jac...@in...] > Sent: Monday, October 21, 2013 14:13 > To: Fabrizio Giordano; Richard Cochran > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > Hi Fabrizio, > > The sourceforge driver for e1000e has a hard check for kernel version. > Since you have a specialized kernel version that has backported PTP > support, you might try modifying the kcompat.h of the sourceforge > driver, and removing the kernel check. > > Basically, the kernel compat layer is blocking proper enablement of > the PTP core because it assumes your kernel can't have support. You > won't be able to get correct support without the flag properly enabling. > > Regards, > Jake > > > -----Original Message----- > > From: Fabrizio Giordano [mailto:Fab...@ri...] > > Sent: Monday, October 21, 2013 11:07 AM > > To: Richard Cochran > > Cc: lin...@li... > > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > > It's basically the standard scientific linux 6.4 kernel. > > > > uname -a > > Linux dorothy8.lab.nbttech.com 2.6.32-358.18.1.el6.x86_64 #1 SMP > > PREEMPT Wed Sep 4 16:09:45 EDT 2013 x86_64 x86_64 x86_64 > GNU/Linux > > > > -----Original Message----- > > From: Richard Cochran [mailto:ric...@gm...] > > Sent: Monday, October 21, 2013 10:49 > > To: Fabrizio Giordano > > Cc: Vick, Matthew; Ledda William EXT; linuxptp- > > us...@li... > > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > > On Mon, Oct 21, 2013 at 05:32:54PM +0000, Fabrizio Giordano wrote: > > > No that's what I find odd... > > > On another machine I have the exact same kernel but I installed an > > > Intel > > 82576. > > > Here's what ethtool -T returns: > > > > > > ethtool -T eth0 > > > Time stamping parameters for eth0: > > > Capabilities: > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > > PTP Hardware Clock: 0 > > > > Okay, so what do you get from `uname -a`? > > > > > And it actually works with HW timestamps. If it works with another > > > NIC > > and the same kernel I expect that with the proper driver it should > > work also with a 82574. > > > Or am I wrong? > > > > Tell us more about your kernel. Where did you get it from? > > Is the source available somewhere to look at? > > > > Thanks, > > Richard > > > > -------------------------------------------------------------------- > > -- > > -------- October Webinars: Code for Performance Free Intel webinars > > can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > > most from the latest Intel processors and coprocessors. See > > abstracts and register > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ost > > g.clktrk > > _______________________________________________ > > Linuxptp-users mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Keller, J. E <jac...@in...> - 2013-10-21 22:23:53
|
The only guess I have for this is that your Scientific Linux kernel did not properly backport PTP support, which is why force enabling it causes a panic. Regards, Jake > -----Original Message----- > From: Fabrizio Giordano [mailto:Fab...@ri...] > Sent: Monday, October 21, 2013 2:49 PM > To: Keller, Jacob E; Richard Cochran > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > Hello Jake, > > I had already tried that earlier but I figured that that check (kernel >= 3) > was necessary since when I rebooted the machine with the e1000e > driver I got a kernel panic (I didn't spend too much time debugging it). > Here's the output I got: > > > e1000e: Intel(R) PRO/1000 Network Driver - 2.5.4-NAPI > e1000e: Copyright(c) 1999 - 2013 Intel Corporation. > e1000e 0000:03:00.0: Disabling ASPM L0s L1 > e1000e 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic > conservative mode > bio: create slab <bio-1> at 1 > md/raid0:md0: md_size is 62499647488 sectors. > md: RAID0 configuration for md0 - 1 zone > BUG: unable to handle kernel NULL pointer dereference at > 00000000000002ce > IP: [<ffffffff812788bc>] kref_get+0xc/0x30 > PGD 339612067 PUD 339f03067 PMD 0 > Oops: 0000 [#1] PREEMPT SMP > last sysfs file: /sys/module/raid0/initstate > CPU 8 > Modules linked in: e1000e(+)(U) ptp pps_core ioatdma dca i7core_edac > edac_core sg ext4 jbd2 mbcache raid0 sr_mod cdrom sd_mod crc_t10dif > ahci 3w_9xxx dm_mod [last unloaded: scsi_wait_scan] > > Pid: 1016, comm: modprobe Not tainted 2.6.32- > 358.18.1.el6.rvbd.1.x86_64 #1 Supermicro X8DT6/X8DT6 > RIP: 0010:[<ffffffff812788bc>] [<ffffffff812788bc>] kref_get+0xc/0x30 > RSP: 0018:ffff88063893d9d8 EFLAGS: 00010296 > RAX: 0000000000000000 RBX: 00000000000002ce RCX: > 0000000000000030 > RDX: 0000000000000000 RSI: ffff88033828d9e0 RDI: > 00000000000002ce > RBP: ffff88063893d9e8 R08: 0000000000000000 R09: 00000000fffffffe > R10: 0000000000000000 R11: 0000000000000000 R12: > 000000000f600000 > R13: 0000000000000286 R14: 00000000ffffffea R15: ffff88033af60c00 > FS: 00007f94ea831700(0000) GS:ffff880028280000(0000) > knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 00000000000002ce CR3: 0000000339617000 CR4: > 00000000000007e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: > 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: > 0000000000000400 > Process modprobe (pid: 1016, threadinfo ffff88063893c000, task > ffff88063799e040) > Stack: > 0000000000000003 0000000000000296 ffff88063893da08 > ffffffff8127754a > <d> 0000000200000010 ffff88033af60c00 ffff88063893da18 > ffffffff8134f6b9 > <d> ffff88063893da98 ffffffff81350c6b ffff88033828d9e0 > 0000000000000005 > Call Trace: > [<ffffffff8127754a>] kobject_get+0x1a/0x30 > [<ffffffff8134f6b9>] get_device+0x19/0x20 > [<ffffffff81350c6b>] device_add+0x8b/0x650 > [<ffffffff81359fbb>] ? pm_runtime_init+0xcb/0xe0 > [<ffffffff8135124e>] device_register+0x1e/0x30 > [<ffffffff81351348>] device_create_vargs+0xe8/0x110 > [<ffffffff813513a1>] device_create+0x31/0x40 > [<ffffffffa0043614>] ptp_clock_register+0x224/0x360 [ptp] > [<ffffffff81076b68>] ? add_timer+0x18/0x30 > [<ffffffff81085569>] ? queue_delayed_work_on+0xb9/0x120 > [<ffffffffa016acff>] e1000e_ptp_init+0x10f/0x210 [e1000e] > [<ffffffffa016bf3e>] e1000_probe+0xbe6/0xf66 [e1000e] > [<ffffffff811965d0>] ? iput+0x30/0x70 > [<ffffffff811f6570>] ? sysfs_addrm_finish+0x50/0x280 > [<ffffffff811f6e2e>] ? __sysfs_add_one+0x7e/0xc0 > [<ffffffff81297977>] local_pci_probe+0x17/0x20 > [<ffffffff81298b71>] pci_device_probe+0x101/0x120 > [<ffffffff81353c82>] ? driver_sysfs_add+0x62/0x90 > [<ffffffff81353e20>] driver_probe_device+0xa0/0x2a0 > [<ffffffff813540cb>] __driver_attach+0xab/0xb0 > [<ffffffff81354020>] ? __driver_attach+0x0/0xb0 > [<ffffffff813533d4>] bus_for_each_dev+0x64/0x90 > [<ffffffff81353bbe>] driver_attach+0x1e/0x20 > [<ffffffff81352c08>] bus_add_driver+0x1e8/0x2b0 > [<ffffffff81354416>] driver_register+0x76/0x140 > [<ffffffff81506b2a>] ? printk+0x41/0x47 > [<ffffffff81298dd6>] __pci_register_driver+0x56/0xd0 > [<ffffffffa00e8000>] ? e1000_init_module+0x0/0x43 [e1000e] > [<ffffffffa00e8041>] e1000_init_module+0x41/0x43 [e1000e] > [<ffffffff810001ec>] do_one_initcall+0x3c/0x1d0 > [<ffffffff810ac051>] sys_init_module+0xe1/0x250 > [<ffffffff810030b2>] system_call_fastpath+0x16/0x1b > Code: 7c 81 e8 88 9f de ff eb cb be 40 00 00 00 48 c7 c7 3f 2b 7c 81 e8 > 75 9f de ff eb b8 0f 1f 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 <8b> 07 > 85 c0 74 0a f0 ff 03 48 83 c4 08 5b c9 c3 be 2b 00 00 00 > RIP [<ffffffff812788bc>] kref_get+0xc/0x30 > RSP <ffff88063893d9d8> > CR2: 00000000000002ce > ---[ end trace 4ad683c7806b9327 ]--- > Kernel panic - not syncing: Fatal exception > Pid: 1016, comm: modprobe Tainted: G D --------------- 2.6.32- > 358.18.1.el6.rvbd.1.x86_64 #1 > Call Trace: > [<ffffffff81506a21>] ? panic+0xa7/0x16f > [<ffffffff8150b254>] ? oops_end+0xe4/0x100 > [<ffffffff8103a98b>] ? no_context+0xfb/0x260 > [<ffffffff8103ac15>] ? __bad_area_nosemaphore+0x125/0x1e0 > [<ffffffff8103ad3e>] ? bad_area+0x4e/0x60 > [<ffffffff8103b1ae>] ? __do_page_fault+0x26e/0x500 > [<ffffffff8150cace>] ? do_page_fault+0x3e/0xd0 > [<ffffffff8150a535>] ? page_fault+0x25/0x30 > [<ffffffff812788bc>] ? kref_get+0xc/0x30 > [<ffffffff8127754a>] ? kobject_get+0x1a/0x30 > [<ffffffff8134f6b9>] ? get_device+0x19/0x20 > [<ffffffff81350c6b>] ? device_add+0x8b/0x650 > [<ffffffff81359fbb>] ? pm_runtime_init+0xcb/0xe0 > [<ffffffff8135124e>] ? device_register+0x1e/0x30 > [<ffffffff81351348>] ? device_create_vargs+0xe8/0x110 > [<ffffffff813513a1>] ? device_create+0x31/0x40 > [<ffffffffa0043614>] ? ptp_clock_register+0x224/0x360 [ptp] > [<ffffffff81076b68>] ? add_timer+0x18/0x30 > [<ffffffff81085569>] ? queue_delayed_work_on+0xb9/0x120 > [<ffffffffa016acff>] ? e1000e_ptp_init+0x10f/0x210 [e1000e] > [<ffffffffa016bf3e>] ? e1000_probe+0xbe6/0xf66 [e1000e] > [<ffffffff811965d0>] ? iput+0x30/0x70 > [<ffffffff811f6570>] ? sysfs_addrm_finish+0x50/0x280 > [<ffffffff811f6e2e>] ? __sysfs_add_one+0x7e/0xc0 > [<ffffffff81297977>] ? local_pci_probe+0x17/0x20 > [<ffffffff81298b71>] ? pci_device_probe+0x101/0x120 > [<ffffffff81353c82>] ? driver_sysfs_add+0x62/0x90 > [<ffffffff81353e20>] ? driver_probe_device+0xa0/0x2a0 > [<ffffffff813540cb>] ? __driver_attach+0xab/0xb0 > [<ffffffff81354020>] ? __driver_attach+0x0/0xb0 > [<ffffffff813533d4>] ? bus_for_each_dev+0x64/0x90 > [<ffffffff81353bbe>] ? driver_attach+0x1e/0x20 > [<ffffffff81352c08>] ? bus_add_driver+0x1e8/0x2b0 > [<ffffffff81354416>] ? driver_register+0x76/0x140 > [<ffffffff81506b2a>] ? printk+0x41/0x47 > [<ffffffff81298dd6>] ? __pci_register_driver+0x56/0xd0 > [<ffffffffa00e8000>] ? e1000_init_module+0x0/0x43 [e1000e] > [<ffffffffa00e8041>] ? e1000_init_module+0x41/0x43 [e1000e] > [<ffffffff810001ec>] ? do_one_initcall+0x3c/0x1d0 > [<ffffffff810ac051>] ? sys_init_module+0xe1/0x250 > [<ffffffff810030b2>] ? system_call_fastpath+0x16/0x1b > > > -----Original Message----- > From: Keller, Jacob E [mailto:jac...@in...] > Sent: Monday, October 21, 2013 14:13 > To: Fabrizio Giordano; Richard Cochran > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > Hi Fabrizio, > > The sourceforge driver for e1000e has a hard check for kernel version. > Since you have a specialized kernel version that has backported PTP > support, you might try modifying the kcompat.h of the sourceforge driver, > and removing the kernel check. > > Basically, the kernel compat layer is blocking proper enablement of the > PTP core because it assumes your kernel can't have support. You won't > be able to get correct support without the flag properly enabling. > > Regards, > Jake > > > -----Original Message----- > > From: Fabrizio Giordano [mailto:Fab...@ri...] > > Sent: Monday, October 21, 2013 11:07 AM > > To: Richard Cochran > > Cc: lin...@li... > > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > > It's basically the standard scientific linux 6.4 kernel. > > > > uname -a > > Linux dorothy8.lab.nbttech.com 2.6.32-358.18.1.el6.x86_64 #1 SMP > > PREEMPT Wed Sep 4 16:09:45 EDT 2013 x86_64 x86_64 x86_64 > GNU/Linux > > > > -----Original Message----- > > From: Richard Cochran [mailto:ric...@gm...] > > Sent: Monday, October 21, 2013 10:49 > > To: Fabrizio Giordano > > Cc: Vick, Matthew; Ledda William EXT; linuxptp- > > us...@li... > > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > > On Mon, Oct 21, 2013 at 05:32:54PM +0000, Fabrizio Giordano wrote: > > > No that's what I find odd... > > > On another machine I have the exact same kernel but I installed an > > > Intel > > 82576. > > > Here's what ethtool -T returns: > > > > > > ethtool -T eth0 > > > Time stamping parameters for eth0: > > > Capabilities: > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > > PTP Hardware Clock: 0 > > > > Okay, so what do you get from `uname -a`? > > > > > And it actually works with HW timestamps. If it works with another > > > NIC > > and the same kernel I expect that with the proper driver it should > > work also with a 82574. > > > Or am I wrong? > > > > Tell us more about your kernel. Where did you get it from? > > Is the source available somewhere to look at? > > > > Thanks, > > Richard > > > > ---------------------------------------------------------------------- > > -------- October Webinars: Code for Performance Free Intel webinars > > can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > > most from the latest Intel processors and coprocessors. See abstracts > > and register > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ost > > g.clktrk > > _______________________________________________ > > Linuxptp-users mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Fabrizio G. <Fab...@ri...> - 2013-10-21 21:49:13
|
Hello Jake, I had already tried that earlier but I figured that that check (kernel >= 3) was necessary since when I rebooted the machine with the e1000e driver I got a kernel panic (I didn't spend too much time debugging it). Here's the output I got: e1000e: Intel(R) PRO/1000 Network Driver - 2.5.4-NAPI e1000e: Copyright(c) 1999 - 2013 Intel Corporation. e1000e 0000:03:00.0: Disabling ASPM L0s L1 e1000e 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode bio: create slab <bio-1> at 1 md/raid0:md0: md_size is 62499647488 sectors. md: RAID0 configuration for md0 - 1 zone BUG: unable to handle kernel NULL pointer dereference at 00000000000002ce IP: [<ffffffff812788bc>] kref_get+0xc/0x30 PGD 339612067 PUD 339f03067 PMD 0 Oops: 0000 [#1] PREEMPT SMP last sysfs file: /sys/module/raid0/initstate CPU 8 Modules linked in: e1000e(+)(U) ptp pps_core ioatdma dca i7core_edac edac_core sg ext4 jbd2 mbcache raid0 sr_mod cdrom sd_mod crc_t10dif ahci 3w_9xxx dm_mod [last unloaded: scsi_wait_scan] Pid: 1016, comm: modprobe Not tainted 2.6.32-358.18.1.el6.rvbd.1.x86_64 #1 Supermicro X8DT6/X8DT6 RIP: 0010:[<ffffffff812788bc>] [<ffffffff812788bc>] kref_get+0xc/0x30 RSP: 0018:ffff88063893d9d8 EFLAGS: 00010296 RAX: 0000000000000000 RBX: 00000000000002ce RCX: 0000000000000030 RDX: 0000000000000000 RSI: ffff88033828d9e0 RDI: 00000000000002ce RBP: ffff88063893d9e8 R08: 0000000000000000 R09: 00000000fffffffe R10: 0000000000000000 R11: 0000000000000000 R12: 000000000f600000 R13: 0000000000000286 R14: 00000000ffffffea R15: ffff88033af60c00 FS: 00007f94ea831700(0000) GS:ffff880028280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000000000002ce CR3: 0000000339617000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process modprobe (pid: 1016, threadinfo ffff88063893c000, task ffff88063799e040) Stack: 0000000000000003 0000000000000296 ffff88063893da08 ffffffff8127754a <d> 0000000200000010 ffff88033af60c00 ffff88063893da18 ffffffff8134f6b9 <d> ffff88063893da98 ffffffff81350c6b ffff88033828d9e0 0000000000000005 Call Trace: [<ffffffff8127754a>] kobject_get+0x1a/0x30 [<ffffffff8134f6b9>] get_device+0x19/0x20 [<ffffffff81350c6b>] device_add+0x8b/0x650 [<ffffffff81359fbb>] ? pm_runtime_init+0xcb/0xe0 [<ffffffff8135124e>] device_register+0x1e/0x30 [<ffffffff81351348>] device_create_vargs+0xe8/0x110 [<ffffffff813513a1>] device_create+0x31/0x40 [<ffffffffa0043614>] ptp_clock_register+0x224/0x360 [ptp] [<ffffffff81076b68>] ? add_timer+0x18/0x30 [<ffffffff81085569>] ? queue_delayed_work_on+0xb9/0x120 [<ffffffffa016acff>] e1000e_ptp_init+0x10f/0x210 [e1000e] [<ffffffffa016bf3e>] e1000_probe+0xbe6/0xf66 [e1000e] [<ffffffff811965d0>] ? iput+0x30/0x70 [<ffffffff811f6570>] ? sysfs_addrm_finish+0x50/0x280 [<ffffffff811f6e2e>] ? __sysfs_add_one+0x7e/0xc0 [<ffffffff81297977>] local_pci_probe+0x17/0x20 [<ffffffff81298b71>] pci_device_probe+0x101/0x120 [<ffffffff81353c82>] ? driver_sysfs_add+0x62/0x90 [<ffffffff81353e20>] driver_probe_device+0xa0/0x2a0 [<ffffffff813540cb>] __driver_attach+0xab/0xb0 [<ffffffff81354020>] ? __driver_attach+0x0/0xb0 [<ffffffff813533d4>] bus_for_each_dev+0x64/0x90 [<ffffffff81353bbe>] driver_attach+0x1e/0x20 [<ffffffff81352c08>] bus_add_driver+0x1e8/0x2b0 [<ffffffff81354416>] driver_register+0x76/0x140 [<ffffffff81506b2a>] ? printk+0x41/0x47 [<ffffffff81298dd6>] __pci_register_driver+0x56/0xd0 [<ffffffffa00e8000>] ? e1000_init_module+0x0/0x43 [e1000e] [<ffffffffa00e8041>] e1000_init_module+0x41/0x43 [e1000e] [<ffffffff810001ec>] do_one_initcall+0x3c/0x1d0 [<ffffffff810ac051>] sys_init_module+0xe1/0x250 [<ffffffff810030b2>] system_call_fastpath+0x16/0x1b Code: 7c 81 e8 88 9f de ff eb cb be 40 00 00 00 48 c7 c7 3f 2b 7c 81 e8 75 9f de ff eb b8 0f 1f 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 <8b> 07 85 c0 74 0a f0 ff 03 48 83 c4 08 5b c9 c3 be 2b 00 00 00 RIP [<ffffffff812788bc>] kref_get+0xc/0x30 RSP <ffff88063893d9d8> CR2: 00000000000002ce ---[ end trace 4ad683c7806b9327 ]--- Kernel panic - not syncing: Fatal exception Pid: 1016, comm: modprobe Tainted: G D --------------- 2.6.32-358.18.1.el6.rvbd.1.x86_64 #1 Call Trace: [<ffffffff81506a21>] ? panic+0xa7/0x16f [<ffffffff8150b254>] ? oops_end+0xe4/0x100 [<ffffffff8103a98b>] ? no_context+0xfb/0x260 [<ffffffff8103ac15>] ? __bad_area_nosemaphore+0x125/0x1e0 [<ffffffff8103ad3e>] ? bad_area+0x4e/0x60 [<ffffffff8103b1ae>] ? __do_page_fault+0x26e/0x500 [<ffffffff8150cace>] ? do_page_fault+0x3e/0xd0 [<ffffffff8150a535>] ? page_fault+0x25/0x30 [<ffffffff812788bc>] ? kref_get+0xc/0x30 [<ffffffff8127754a>] ? kobject_get+0x1a/0x30 [<ffffffff8134f6b9>] ? get_device+0x19/0x20 [<ffffffff81350c6b>] ? device_add+0x8b/0x650 [<ffffffff81359fbb>] ? pm_runtime_init+0xcb/0xe0 [<ffffffff8135124e>] ? device_register+0x1e/0x30 [<ffffffff81351348>] ? device_create_vargs+0xe8/0x110 [<ffffffff813513a1>] ? device_create+0x31/0x40 [<ffffffffa0043614>] ? ptp_clock_register+0x224/0x360 [ptp] [<ffffffff81076b68>] ? add_timer+0x18/0x30 [<ffffffff81085569>] ? queue_delayed_work_on+0xb9/0x120 [<ffffffffa016acff>] ? e1000e_ptp_init+0x10f/0x210 [e1000e] [<ffffffffa016bf3e>] ? e1000_probe+0xbe6/0xf66 [e1000e] [<ffffffff811965d0>] ? iput+0x30/0x70 [<ffffffff811f6570>] ? sysfs_addrm_finish+0x50/0x280 [<ffffffff811f6e2e>] ? __sysfs_add_one+0x7e/0xc0 [<ffffffff81297977>] ? local_pci_probe+0x17/0x20 [<ffffffff81298b71>] ? pci_device_probe+0x101/0x120 [<ffffffff81353c82>] ? driver_sysfs_add+0x62/0x90 [<ffffffff81353e20>] ? driver_probe_device+0xa0/0x2a0 [<ffffffff813540cb>] ? __driver_attach+0xab/0xb0 [<ffffffff81354020>] ? __driver_attach+0x0/0xb0 [<ffffffff813533d4>] ? bus_for_each_dev+0x64/0x90 [<ffffffff81353bbe>] ? driver_attach+0x1e/0x20 [<ffffffff81352c08>] ? bus_add_driver+0x1e8/0x2b0 [<ffffffff81354416>] ? driver_register+0x76/0x140 [<ffffffff81506b2a>] ? printk+0x41/0x47 [<ffffffff81298dd6>] ? __pci_register_driver+0x56/0xd0 [<ffffffffa00e8000>] ? e1000_init_module+0x0/0x43 [e1000e] [<ffffffffa00e8041>] ? e1000_init_module+0x41/0x43 [e1000e] [<ffffffff810001ec>] ? do_one_initcall+0x3c/0x1d0 [<ffffffff810ac051>] ? sys_init_module+0xe1/0x250 [<ffffffff810030b2>] ? system_call_fastpath+0x16/0x1b -----Original Message----- From: Keller, Jacob E [mailto:jac...@in...] Sent: Monday, October 21, 2013 14:13 To: Fabrizio Giordano; Richard Cochran Cc: lin...@li... Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 Hi Fabrizio, The sourceforge driver for e1000e has a hard check for kernel version. Since you have a specialized kernel version that has backported PTP support, you might try modifying the kcompat.h of the sourceforge driver, and removing the kernel check. Basically, the kernel compat layer is blocking proper enablement of the PTP core because it assumes your kernel can't have support. You won't be able to get correct support without the flag properly enabling. Regards, Jake > -----Original Message----- > From: Fabrizio Giordano [mailto:Fab...@ri...] > Sent: Monday, October 21, 2013 11:07 AM > To: Richard Cochran > Cc: lin...@li... > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > It's basically the standard scientific linux 6.4 kernel. > > uname -a > Linux dorothy8.lab.nbttech.com 2.6.32-358.18.1.el6.x86_64 #1 SMP > PREEMPT Wed Sep 4 16:09:45 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux > > -----Original Message----- > From: Richard Cochran [mailto:ric...@gm...] > Sent: Monday, October 21, 2013 10:49 > To: Fabrizio Giordano > Cc: Vick, Matthew; Ledda William EXT; linuxptp- > us...@li... > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > On Mon, Oct 21, 2013 at 05:32:54PM +0000, Fabrizio Giordano wrote: > > No that's what I find odd... > > On another machine I have the exact same kernel but I installed an > > Intel > 82576. > > Here's what ethtool -T returns: > > > > ethtool -T eth0 > > Time stamping parameters for eth0: > > Capabilities: > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > PTP Hardware Clock: 0 > > Okay, so what do you get from `uname -a`? > > > And it actually works with HW timestamps. If it works with another > > NIC > and the same kernel I expect that with the proper driver it should > work also with a 82574. > > Or am I wrong? > > Tell us more about your kernel. Where did you get it from? > Is the source available somewhere to look at? > > Thanks, > Richard > > ---------------------------------------------------------------------- > -------- October Webinars: Code for Performance Free Intel webinars > can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from the latest Intel processors and coprocessors. See abstracts > and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ost > g.clktrk > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Keller, J. E <jac...@in...> - 2013-10-21 21:13:08
|
Hi Fabrizio, The sourceforge driver for e1000e has a hard check for kernel version. Since you have a specialized kernel version that has backported PTP support, you might try modifying the kcompat.h of the sourceforge driver, and removing the kernel check. Basically, the kernel compat layer is blocking proper enablement of the PTP core because it assumes your kernel can't have support. You won't be able to get correct support without the flag properly enabling. Regards, Jake > -----Original Message----- > From: Fabrizio Giordano [mailto:Fab...@ri...] > Sent: Monday, October 21, 2013 11:07 AM > To: Richard Cochran > Cc: lin...@li... > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > It's basically the standard scientific linux 6.4 kernel. > > uname -a > Linux dorothy8.lab.nbttech.com 2.6.32-358.18.1.el6.x86_64 #1 SMP > PREEMPT Wed Sep 4 16:09:45 EDT 2013 x86_64 x86_64 x86_64 > GNU/Linux > > -----Original Message----- > From: Richard Cochran [mailto:ric...@gm...] > Sent: Monday, October 21, 2013 10:49 > To: Fabrizio Giordano > Cc: Vick, Matthew; Ledda William EXT; linuxptp- > us...@li... > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > On Mon, Oct 21, 2013 at 05:32:54PM +0000, Fabrizio Giordano wrote: > > No that's what I find odd... > > On another machine I have the exact same kernel but I installed an Intel > 82576. > > Here's what ethtool -T returns: > > > > ethtool -T eth0 > > Time stamping parameters for eth0: > > Capabilities: > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > PTP Hardware Clock: 0 > > Okay, so what do you get from `uname -a`? > > > And it actually works with HW timestamps. If it works with another NIC > and the same kernel I expect that with the proper driver it should work > also with a 82574. > > Or am I wrong? > > Tell us more about your kernel. Where did you get it from? > Is the source available somewhere to look at? > > Thanks, > Richard > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ost > g.clktrk > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Fabrizio G. <Fab...@ri...> - 2013-10-21 18:07:29
|
It's basically the standard scientific linux 6.4 kernel. uname -a Linux dorothy8.lab.nbttech.com 2.6.32-358.18.1.el6.x86_64 #1 SMP PREEMPT Wed Sep 4 16:09:45 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: Monday, October 21, 2013 10:49 To: Fabrizio Giordano Cc: Vick, Matthew; Ledda William EXT; lin...@li... Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 On Mon, Oct 21, 2013 at 05:32:54PM +0000, Fabrizio Giordano wrote: > No that's what I find odd... > On another machine I have the exact same kernel but I installed an Intel 82576. > Here's what ethtool -T returns: > > ethtool -T eth0 > Time stamping parameters for eth0: > Capabilities: > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > PTP Hardware Clock: 0 Okay, so what do you get from `uname -a`? > And it actually works with HW timestamps. If it works with another NIC and the same kernel I expect that with the proper driver it should work also with a 82574. > Or am I wrong? Tell us more about your kernel. Where did you get it from? Is the source available somewhere to look at? Thanks, Richard |
|
From: Vick, M. <mat...@in...> - 2013-10-21 17:53:05
|
Actually, the more recent out-of-tree versions of igb dropped support for the older timesync API. Older versions should have the support for the older API. On 10/21/13 10:25 AM, "Allan, Bruce W" <bru...@in...> wrote: >IIRC, the out-of-tree igb driver (the driver supporting 82576) also >supports the older timesync API in addition to the newer PTP Hardware >Clock subsystem; the out-of-tree e1000e driver does not support the older >API, just the newer one. > >> -----Original Message----- >> From: Fabrizio Giordano [mailto:Fab...@ri...] >> Sent: Monday, October 21, 2013 10:13 AM >> To: Richard Cochran >> Cc: lin...@li... >> Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 >> >> Then why it works just fine with an Intel 82576 (and the *same* kernel)? >> >> Fabrizio >> >> -----Original Message----- >> From: Richard Cochran [mailto:ric...@gm...] >> Sent: Monday, October 21, 2013 10:11 >> To: Fabrizio Giordano >> Cc: Vick, Matthew; Ledda William EXT; >>lin...@li... >> Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 >> >> On Mon, Oct 21, 2013 at 04:51:58PM +0000, Fabrizio Giordano wrote: >> > >> > The kernel we use is a custom recompiled version of >>2.6.32-358.18.1.el6. >> >> That explains it. The PTP Hardware Clock subsystem first appeared in >> v3.0 of the Linux kernel. >> >> Sorry, >> Richard >> >> >>------------------------------------------------------------------------- >>----- >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and >>register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.cl >> ktrk >> _______________________________________________ >> Linuxptp-users mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users > >-------------------------------------------------------------------------- >---- >October Webinars: Code for Performance >Free Intel webinars can help you accelerate application performance. >Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >from >the latest Intel processors and coprocessors. See abstracts and register > >http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktr >k >_______________________________________________ >Linuxptp-users mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Richard C. <ric...@gm...> - 2013-10-21 17:49:03
|
On Mon, Oct 21, 2013 at 05:32:54PM +0000, Fabrizio Giordano wrote: > No that's what I find odd... > On another machine I have the exact same kernel but I installed an Intel 82576. > Here's what ethtool -T returns: > > ethtool -T eth0 > Time stamping parameters for eth0: > Capabilities: > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > PTP Hardware Clock: 0 Okay, so what do you get from `uname -a`? > And it actually works with HW timestamps. If it works with another NIC and the same kernel I expect that with the proper driver it should work also with a 82574. > Or am I wrong? Tell us more about your kernel. Where did you get it from? Is the source available somewhere to look at? Thanks, Richard |
|
From: Fabrizio G. <Fab...@ri...> - 2013-10-21 17:33:01
|
No that's what I find odd...
On another machine I have the exact same kernel but I installed an Intel 82576.
Here's what ethtool -T returns:
ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)
And it actually works with HW timestamps. If it works with another NIC and the same kernel I expect that with the proper driver it should work also with a 82574.
Or am I wrong?
Fabrizio
-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...]
Sent: Monday, October 21, 2013 10:30
To: Fabrizio Giordano
Cc: Vick, Matthew; Ledda William EXT; lin...@li...
Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574
On Mon, Oct 21, 2013 at 05:12:49PM +0000, Fabrizio Giordano wrote:
> Then why it works just fine with an Intel 82576 (and the *same* kernel)?
I assume you mean SW time stamping works?
Thanks,
Richard
|
|
From: Richard C. <ric...@gm...> - 2013-10-21 17:29:58
|
On Mon, Oct 21, 2013 at 05:12:49PM +0000, Fabrizio Giordano wrote: > Then why it works just fine with an Intel 82576 (and the *same* kernel)? I assume you mean SW time stamping works? Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-10-21 17:27:59
|
On Sat, Oct 19, 2013 at 12:28:16AM +0000, Fabrizio Giordano wrote: > Hello everyone, > > I've been trying to use linux with my Intel 82574 with no much luck. > First I've tried to use it with software timestamping since the version of e1000e I was using didn't support HW timestamping. > This is what I get: > > [root@199-dorothy13 ~]# ptp4l -i eth0 -v -S > ptp4l[25333.043]: port 1: INITIALIZING to LISTENING on INITIALIZE > ptp4l[25333.043]: port 0: INITIALIZING to LISTENING on INITIALIZE > ptp4l[25334.561]: port 1: new foreign master 003048.fffe.9ea9d6-1 > ptp4l[25338.561]: selected best master clock 003048.fffe.9ea9d6 > ptp4l[25338.561]: port 1: LISTENING to GRAND_MASTER on RS_GRAND_MASTER > ptp4l[25339.567]: recvmsg tx timestamp failed: Resource temporarily unavailable > ptp4l[25339.567]: port 1: send sync failed > ptp4l[25339.567]: port 1: GRAND_MASTER to FAULTY on FAULT_DETECTED > ptp4l[25354.574]: port 1: FAULTY to LISTENING on FAULT_CLEARED > > What is that supposed to mean? Resource temporarily unavailable? It means that no transmit time stamp was returned by the networking stack before the timeout expired. Looking at the e1000e driver, both the HW and the SW time stamping first appeared with with kernel 3.9, and so you will not see any transmit SW time stamps with your 2.6.32 kernel. However, if the SF driver includes a call to skb_tx_timestamp (and that code is not conditionally #ifdef'd out), then SW time stamping should work using that driver on your 2.6.32 kernel. HTH, Richard |
|
From: Allan, B. W <bru...@in...> - 2013-10-21 17:26:04
|
IIRC, the out-of-tree igb driver (the driver supporting 82576) also supports the older timesync API in addition to the newer PTP Hardware Clock subsystem; the out-of-tree e1000e driver does not support the older API, just the newer one. > -----Original Message----- > From: Fabrizio Giordano [mailto:Fab...@ri...] > Sent: Monday, October 21, 2013 10:13 AM > To: Richard Cochran > Cc: lin...@li... > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > Then why it works just fine with an Intel 82576 (and the *same* kernel)? > > Fabrizio > > -----Original Message----- > From: Richard Cochran [mailto:ric...@gm...] > Sent: Monday, October 21, 2013 10:11 > To: Fabrizio Giordano > Cc: Vick, Matthew; Ledda William EXT; lin...@li... > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > On Mon, Oct 21, 2013 at 04:51:58PM +0000, Fabrizio Giordano wrote: > > > > The kernel we use is a custom recompiled version of 2.6.32-358.18.1.el6. > > That explains it. The PTP Hardware Clock subsystem first appeared in > v3.0 of the Linux kernel. > > Sorry, > Richard > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.cl > ktrk > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Richard C. <ric...@gm...> - 2013-10-21 17:14:45
|
On Mon, Oct 21, 2013 at 05:11:13PM +0000, Fabrizio Giordano wrote: > I figured... but it's odd because the error message says: > > Cannot enable PTP Hardware Clock support due to a pre-3.0 kernel version or CONFIG_PTP_1588_CLOCK not enabled in the kernel > > I actually have CONFIG_PTP_1588_CLOCK enabled in my kernel. But unless you back-ported the PHC code, the option will have no effect. [ If you back-ported the code, then you may have a bug in your port. ] Thanks, Richard |
|
From: Fabrizio G. <Fab...@ri...> - 2013-10-21 17:12:57
|
Then why it works just fine with an Intel 82576 (and the *same* kernel)? Fabrizio -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: Monday, October 21, 2013 10:11 To: Fabrizio Giordano Cc: Vick, Matthew; Ledda William EXT; lin...@li... Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 On Mon, Oct 21, 2013 at 04:51:58PM +0000, Fabrizio Giordano wrote: > > The kernel we use is a custom recompiled version of 2.6.32-358.18.1.el6. That explains it. The PTP Hardware Clock subsystem first appeared in v3.0 of the Linux kernel. Sorry, Richard |
|
From: Richard C. <ric...@gm...> - 2013-10-21 17:11:25
|
On Mon, Oct 21, 2013 at 04:51:58PM +0000, Fabrizio Giordano wrote: > > The kernel we use is a custom recompiled version of 2.6.32-358.18.1.el6. That explains it. The PTP Hardware Clock subsystem first appeared in v3.0 of the Linux kernel. Sorry, Richard |
|
From: Fabrizio G. <Fab...@ri...> - 2013-10-21 17:11:25
|
I figured... but it's odd because the error message says: Cannot enable PTP Hardware Clock support due to a pre-3.0 kernel version or CONFIG_PTP_1588_CLOCK not enabled in the kernel I actually have CONFIG_PTP_1588_CLOCK enabled in my kernel. -----Original Message----- From: Allan, Bruce W [mailto:bru...@in...] Sent: Monday, October 21, 2013 10:08 To: Vick, Matthew; Fabrizio Giordano; Ledda William EXT; lin...@li... Subject: RE: [Linuxptp-users] Issues with linuxptp and Intel 82574 PTP is not supported in e1000e on kernels older than 3.0 > -----Original Message----- > From: Vick, Matthew [mailto:mat...@in...] > Sent: Monday, October 21, 2013 9:55 AM > To: Fabrizio Giordano; Ledda William EXT; linuxptp- > us...@li... > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > Fabrizio, > > Based on your ethtool -T eth0 output, it sounds like you need the > E1000E_PTP compile flag. You should see the ethtool -T eth0 output > change after using that flag. The hardware timestamping is technically > a different functionality than the PTP functionality and e1000e > version on SourceForge exposes the hardware timestamping by default, > but not the PTP support. > > Cheers, > Matthew > > On 10/21/13 9:51 AM, "Fabrizio Giordano" > <Fab...@ri...> > wrote: > > >Hello Matthew and thanks for your answer, > > > >The version of e1000e is 2.5.4: > > > >ethtool -i eth0 > >driver: e1000e > >version: 2.5.4-NAPI > >firmware-version: 1.9-0 > >bus-info: 0000:03:00.0 > >supports-statistics: yes > >supports-test: yes > >supports-eeprom-access: yes > >supports-register-dump: yes > >supports-priv-flags: no > > > >The kernel we use is a custom recompiled version of 2.6.32-358.18.1.el6. > >I'll try recompiling the driver with the E1000E_PTP option and see if > >it works. > >Thanks for your help > > > >Fabrizio > > > > > >-----Original Message----- > >From: Vick, Matthew [mailto:mat...@in...] > >Sent: Monday, October 21, 2013 9:42 > >To: Ledda William EXT; Fabrizio Giordano; > >lin...@li... > >Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > >Fabrizio, > > > >I would be curious about the ethtool -T eth0 output as well. If you > >are grabbing the latest version of the driver from SourceForge and > >are seeing that issue, you likely did not compile in the PTP support > >with the additional flag (CFLAGS_EXTRA=-DE1000E_PTP make). You can > >confirm this with the README. > > > >Thinking out loud, I also would have expected the SW timestamping to > >work. What version of the kernel and driver are you running? > >$ uname -a > >$ ethtool -i eth0 > > > >The recvmsg tx timestamp failed message means that ptp4l did not ever > >receive the Tx timestamp back. > > > >Cheers, > >Matthew > > > >Matthew Vick > >Linux Development > >Networking Division > >Intel Corporation > > > >From: Ledda William EXT > ><Wil...@it...<mailto:Wil...@it...>> > >Date: Monday, October 21, 2013 12:10 AM > >To: Fabrizio Giordano > ><Fab...@ri...<mailto:Fab...@ri... > m>>, > >"lin...@li...<mailto:linuxptp- > us...@li...urcefo > >rge.net>" > ><lin...@li...<mailto:linuxptp- > us...@li...urcefo > >rge.net>> > >Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > >Ciao Frabrizio, > >Have you tried to discover the timestamp capabilities with ethtool -T > >eth0? > > > >William > > > >From: Fabrizio Giordano [mailto:Fab...@ri...] > >Sent: 19 October 2013 02:28 > >To: > >lin...@li...<mailto:linuxptp- > us...@li...urcefor > >ge.net> > >Subject: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > >Hello everyone, > > > >I've been trying to use linux with my Intel 82574 with no much luck. > >First I've tried to use it with software timestamping since the > >version of e1000e I was using didn't support HW timestamping. > >This is what I get: > > > >[root@199-dorothy13 ~]# ptp4l -i eth0 -v -S > >ptp4l[25333.043]: port 1: INITIALIZING to LISTENING on INITIALIZE > >ptp4l[25333.043]: port 0: INITIALIZING to LISTENING on INITIALIZE > >ptp4l[25334.561]: port 1: new foreign master 003048.fffe.9ea9d6-1 > >ptp4l[25338.561]: selected best master clock 003048.fffe.9ea9d6 > >ptp4l[25338.561]: port 1: LISTENING to GRAND_MASTER on > RS_GRAND_MASTER > >ptp4l[25339.567]: recvmsg tx timestamp failed: Resource temporarily > >unavailable > >ptp4l[25339.567]: port 1: send sync failed > >ptp4l[25339.567]: port 1: GRAND_MASTER to FAULTY on FAULT_DETECTED > >ptp4l[25354.574]: port 1: FAULTY to LISTENING on FAULT_CLEARED > > > >What is that supposed to mean? Resource temporarily unavailable? > > > >So I decided to update my e1000e driver to the latest version > >available > >(2.5.4) and use HW timestamping. > >After rebooting my machine I try to run it with HW support (no option > >-S) and this is what I get: > > > >ptp4l[25432.718]: driver rejected most general HWTSTAMP filter > >ptp4l[25432.718]: ioctl SIOCSHWTSTAMP failed: Numerical result out of > >range > >ptp4l[25432.722]: port 1: INITIALIZING to FAULTY on INITIALIZE > >ptp4l[25432.722]: port 0: INITIALIZING to LISTENING on INITIALIZE > > > >Does anyone know what's going on? > >Thank you very much! > > > >Fabrizio > > > > > > > ---------------------------------------------------------------------- > -------- October Webinars: Code for Performance Free Intel webinars > can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from the latest Intel processors and coprocessors. See abstracts > and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.c > l > ktrk > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Allan, B. W <bru...@in...> - 2013-10-21 17:08:55
|
PTP is not supported in e1000e on kernels older than 3.0 > -----Original Message----- > From: Vick, Matthew [mailto:mat...@in...] > Sent: Monday, October 21, 2013 9:55 AM > To: Fabrizio Giordano; Ledda William EXT; linuxptp- > us...@li... > Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > Fabrizio, > > Based on your ethtool -T eth0 output, it sounds like you need the > E1000E_PTP compile flag. You should see the ethtool -T eth0 output change > after using that flag. The hardware timestamping is technically a > different functionality than the PTP functionality and e1000e version on > SourceForge exposes the hardware timestamping by default, but not the > PTP > support. > > Cheers, > Matthew > > On 10/21/13 9:51 AM, "Fabrizio Giordano" > <Fab...@ri...> > wrote: > > >Hello Matthew and thanks for your answer, > > > >The version of e1000e is 2.5.4: > > > >ethtool -i eth0 > >driver: e1000e > >version: 2.5.4-NAPI > >firmware-version: 1.9-0 > >bus-info: 0000:03:00.0 > >supports-statistics: yes > >supports-test: yes > >supports-eeprom-access: yes > >supports-register-dump: yes > >supports-priv-flags: no > > > >The kernel we use is a custom recompiled version of 2.6.32-358.18.1.el6. > >I'll try recompiling the driver with the E1000E_PTP option and see if it > >works. > >Thanks for your help > > > >Fabrizio > > > > > >-----Original Message----- > >From: Vick, Matthew [mailto:mat...@in...] > >Sent: Monday, October 21, 2013 9:42 > >To: Ledda William EXT; Fabrizio Giordano; > >lin...@li... > >Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > >Fabrizio, > > > >I would be curious about the ethtool -T eth0 output as well. If you are > >grabbing the latest version of the driver from SourceForge and are seeing > >that issue, you likely did not compile in the PTP support with the > >additional flag (CFLAGS_EXTRA=-DE1000E_PTP make). You can confirm this > >with the README. > > > >Thinking out loud, I also would have expected the SW timestamping to > >work. What version of the kernel and driver are you running? > >$ uname -a > >$ ethtool -i eth0 > > > >The recvmsg tx timestamp failed message means that ptp4l did not ever > >receive the Tx timestamp back. > > > >Cheers, > >Matthew > > > >Matthew Vick > >Linux Development > >Networking Division > >Intel Corporation > > > >From: Ledda William EXT > ><Wil...@it...<mailto:Wil...@it...>> > >Date: Monday, October 21, 2013 12:10 AM > >To: Fabrizio Giordano > ><Fab...@ri...<mailto:Fab...@ri... > m>>, > >"lin...@li...<mailto:linuxptp- > us...@li...urcefo > >rge.net>" > ><lin...@li...<mailto:linuxptp- > us...@li...urcefo > >rge.net>> > >Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > >Ciao Frabrizio, > >Have you tried to discover the timestamp capabilities with ethtool -T > >eth0? > > > >William > > > >From: Fabrizio Giordano [mailto:Fab...@ri...] > >Sent: 19 October 2013 02:28 > >To: > >lin...@li...<mailto:linuxptp- > us...@li...urcefor > >ge.net> > >Subject: [Linuxptp-users] Issues with linuxptp and Intel 82574 > > > >Hello everyone, > > > >I've been trying to use linux with my Intel 82574 with no much luck. > >First I've tried to use it with software timestamping since the version > >of e1000e I was using didn't support HW timestamping. > >This is what I get: > > > >[root@199-dorothy13 ~]# ptp4l -i eth0 -v -S > >ptp4l[25333.043]: port 1: INITIALIZING to LISTENING on INITIALIZE > >ptp4l[25333.043]: port 0: INITIALIZING to LISTENING on INITIALIZE > >ptp4l[25334.561]: port 1: new foreign master 003048.fffe.9ea9d6-1 > >ptp4l[25338.561]: selected best master clock 003048.fffe.9ea9d6 > >ptp4l[25338.561]: port 1: LISTENING to GRAND_MASTER on > RS_GRAND_MASTER > >ptp4l[25339.567]: recvmsg tx timestamp failed: Resource temporarily > >unavailable > >ptp4l[25339.567]: port 1: send sync failed > >ptp4l[25339.567]: port 1: GRAND_MASTER to FAULTY on FAULT_DETECTED > >ptp4l[25354.574]: port 1: FAULTY to LISTENING on FAULT_CLEARED > > > >What is that supposed to mean? Resource temporarily unavailable? > > > >So I decided to update my e1000e driver to the latest version available > >(2.5.4) and use HW timestamping. > >After rebooting my machine I try to run it with HW support (no option -S) > >and this is what I get: > > > >ptp4l[25432.718]: driver rejected most general HWTSTAMP filter > >ptp4l[25432.718]: ioctl SIOCSHWTSTAMP failed: Numerical result out of > >range > >ptp4l[25432.722]: port 1: INITIALIZING to FAULTY on INITIALIZE > >ptp4l[25432.722]: port 0: INITIALIZING to LISTENING on INITIALIZE > > > >Does anyone know what's going on? > >Thank you very much! > > > >Fabrizio > > > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.cl > ktrk > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Vick, M. <mat...@in...> - 2013-10-21 16:55:25
|
Fabrizio, Based on your ethtool -T eth0 output, it sounds like you need the E1000E_PTP compile flag. You should see the ethtool -T eth0 output change after using that flag. The hardware timestamping is technically a different functionality than the PTP functionality and e1000e version on SourceForge exposes the hardware timestamping by default, but not the PTP support. Cheers, Matthew On 10/21/13 9:51 AM, "Fabrizio Giordano" <Fab...@ri...> wrote: >Hello Matthew and thanks for your answer, > >The version of e1000e is 2.5.4: > >ethtool -i eth0 >driver: e1000e >version: 2.5.4-NAPI >firmware-version: 1.9-0 >bus-info: 0000:03:00.0 >supports-statistics: yes >supports-test: yes >supports-eeprom-access: yes >supports-register-dump: yes >supports-priv-flags: no > >The kernel we use is a custom recompiled version of 2.6.32-358.18.1.el6. >I'll try recompiling the driver with the E1000E_PTP option and see if it >works. >Thanks for your help > >Fabrizio > > >-----Original Message----- >From: Vick, Matthew [mailto:mat...@in...] >Sent: Monday, October 21, 2013 9:42 >To: Ledda William EXT; Fabrizio Giordano; >lin...@li... >Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > >Fabrizio, > >I would be curious about the ethtool -T eth0 output as well. If you are >grabbing the latest version of the driver from SourceForge and are seeing >that issue, you likely did not compile in the PTP support with the >additional flag (CFLAGS_EXTRA=-DE1000E_PTP make). You can confirm this >with the README. > >Thinking out loud, I also would have expected the SW timestamping to >work. What version of the kernel and driver are you running? >$ uname -a >$ ethtool -i eth0 > >The recvmsg tx timestamp failed message means that ptp4l did not ever >receive the Tx timestamp back. > >Cheers, >Matthew > >Matthew Vick >Linux Development >Networking Division >Intel Corporation > >From: Ledda William EXT ><Wil...@it...<mailto:Wil...@it...>> >Date: Monday, October 21, 2013 12:10 AM >To: Fabrizio Giordano ><Fab...@ri...<mailto:Fab...@ri...>>, >"lin...@li...<mailto:lin...@li...urcefo >rge.net>" ><lin...@li...<mailto:lin...@li...urcefo >rge.net>> >Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 > >Ciao Frabrizio, >Have you tried to discover the timestamp capabilities with ethtool -T >eth0? > >William > >From: Fabrizio Giordano [mailto:Fab...@ri...] >Sent: 19 October 2013 02:28 >To: >lin...@li...<mailto:lin...@li...urcefor >ge.net> >Subject: [Linuxptp-users] Issues with linuxptp and Intel 82574 > >Hello everyone, > >I've been trying to use linux with my Intel 82574 with no much luck. >First I've tried to use it with software timestamping since the version >of e1000e I was using didn't support HW timestamping. >This is what I get: > >[root@199-dorothy13 ~]# ptp4l -i eth0 -v -S >ptp4l[25333.043]: port 1: INITIALIZING to LISTENING on INITIALIZE >ptp4l[25333.043]: port 0: INITIALIZING to LISTENING on INITIALIZE >ptp4l[25334.561]: port 1: new foreign master 003048.fffe.9ea9d6-1 >ptp4l[25338.561]: selected best master clock 003048.fffe.9ea9d6 >ptp4l[25338.561]: port 1: LISTENING to GRAND_MASTER on RS_GRAND_MASTER >ptp4l[25339.567]: recvmsg tx timestamp failed: Resource temporarily >unavailable >ptp4l[25339.567]: port 1: send sync failed >ptp4l[25339.567]: port 1: GRAND_MASTER to FAULTY on FAULT_DETECTED >ptp4l[25354.574]: port 1: FAULTY to LISTENING on FAULT_CLEARED > >What is that supposed to mean? Resource temporarily unavailable? > >So I decided to update my e1000e driver to the latest version available >(2.5.4) and use HW timestamping. >After rebooting my machine I try to run it with HW support (no option -S) >and this is what I get: > >ptp4l[25432.718]: driver rejected most general HWTSTAMP filter >ptp4l[25432.718]: ioctl SIOCSHWTSTAMP failed: Numerical result out of >range >ptp4l[25432.722]: port 1: INITIALIZING to FAULTY on INITIALIZE >ptp4l[25432.722]: port 0: INITIALIZING to LISTENING on INITIALIZE > >Does anyone know what's going on? >Thank you very much! > >Fabrizio > > |
|
From: Fabrizio G. <Fab...@ri...> - 2013-10-21 16:52:17
|
Hello Matthew and thanks for your answer, The version of e1000e is 2.5.4: ethtool -i eth0 driver: e1000e version: 2.5.4-NAPI firmware-version: 1.9-0 bus-info: 0000:03:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no The kernel we use is a custom recompiled version of 2.6.32-358.18.1.el6. I'll try recompiling the driver with the E1000E_PTP option and see if it works. Thanks for your help Fabrizio -----Original Message----- From: Vick, Matthew [mailto:mat...@in...] Sent: Monday, October 21, 2013 9:42 To: Ledda William EXT; Fabrizio Giordano; lin...@li... Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 Fabrizio, I would be curious about the ethtool -T eth0 output as well. If you are grabbing the latest version of the driver from SourceForge and are seeing that issue, you likely did not compile in the PTP support with the additional flag (CFLAGS_EXTRA=-DE1000E_PTP make). You can confirm this with the README. Thinking out loud, I also would have expected the SW timestamping to work. What version of the kernel and driver are you running? $ uname -a $ ethtool -i eth0 The recvmsg tx timestamp failed message means that ptp4l did not ever receive the Tx timestamp back. Cheers, Matthew Matthew Vick Linux Development Networking Division Intel Corporation From: Ledda William EXT <Wil...@it...<mailto:Wil...@it...>> Date: Monday, October 21, 2013 12:10 AM To: Fabrizio Giordano <Fab...@ri...<mailto:Fab...@ri...>>, "lin...@li...<mailto:lin...@li...>" <lin...@li...<mailto:lin...@li...>> Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 Ciao Frabrizio, Have you tried to discover the timestamp capabilities with ethtool -T eth0? William From: Fabrizio Giordano [mailto:Fab...@ri...] Sent: 19 October 2013 02:28 To: lin...@li...<mailto:lin...@li...> Subject: [Linuxptp-users] Issues with linuxptp and Intel 82574 Hello everyone, I've been trying to use linux with my Intel 82574 with no much luck. First I've tried to use it with software timestamping since the version of e1000e I was using didn't support HW timestamping. This is what I get: [root@199-dorothy13 ~]# ptp4l -i eth0 -v -S ptp4l[25333.043]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[25333.043]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[25334.561]: port 1: new foreign master 003048.fffe.9ea9d6-1 ptp4l[25338.561]: selected best master clock 003048.fffe.9ea9d6 ptp4l[25338.561]: port 1: LISTENING to GRAND_MASTER on RS_GRAND_MASTER ptp4l[25339.567]: recvmsg tx timestamp failed: Resource temporarily unavailable ptp4l[25339.567]: port 1: send sync failed ptp4l[25339.567]: port 1: GRAND_MASTER to FAULTY on FAULT_DETECTED ptp4l[25354.574]: port 1: FAULTY to LISTENING on FAULT_CLEARED What is that supposed to mean? Resource temporarily unavailable? So I decided to update my e1000e driver to the latest version available (2.5.4) and use HW timestamping. After rebooting my machine I try to run it with HW support (no option -S) and this is what I get: ptp4l[25432.718]: driver rejected most general HWTSTAMP filter ptp4l[25432.718]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range ptp4l[25432.722]: port 1: INITIALIZING to FAULTY on INITIALIZE ptp4l[25432.722]: port 0: INITIALIZING to LISTENING on INITIALIZE Does anyone know what's going on? Thank you very much! Fabrizio |
|
From: Vick, M. <mat...@in...> - 2013-10-21 16:41:40
|
Fabrizio, I would be curious about the ethtool -T eth0 output as well. If you are grabbing the latest version of the driver from SourceForge and are seeing that issue, you likely did not compile in the PTP support with the additional flag (CFLAGS_EXTRA=-DE1000E_PTP make). You can confirm this with the README. Thinking out loud, I also would have expected the SW timestamping to work. What version of the kernel and driver are you running? $ uname -a $ ethtool -i eth0 The recvmsg tx timestamp failed message means that ptp4l did not ever receive the Tx timestamp back. Cheers, Matthew Matthew Vick Linux Development Networking Division Intel Corporation From: Ledda William EXT <Wil...@it...<mailto:Wil...@it...>> Date: Monday, October 21, 2013 12:10 AM To: Fabrizio Giordano <Fab...@ri...<mailto:Fab...@ri...>>, "lin...@li...<mailto:lin...@li...>" <lin...@li...<mailto:lin...@li...>> Subject: Re: [Linuxptp-users] Issues with linuxptp and Intel 82574 Ciao Frabrizio, Have you tried to discover the timestamp capabilities with ethtool –T eth0? William From: Fabrizio Giordano [mailto:Fab...@ri...] Sent: 19 October 2013 02:28 To: lin...@li...<mailto:lin...@li...> Subject: [Linuxptp-users] Issues with linuxptp and Intel 82574 Hello everyone, I’ve been trying to use linux with my Intel 82574 with no much luck. First I’ve tried to use it with software timestamping since the version of e1000e I was using didn’t support HW timestamping. This is what I get: [root@199-dorothy13 ~]# ptp4l -i eth0 -v -S ptp4l[25333.043]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[25333.043]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[25334.561]: port 1: new foreign master 003048.fffe.9ea9d6-1 ptp4l[25338.561]: selected best master clock 003048.fffe.9ea9d6 ptp4l[25338.561]: port 1: LISTENING to GRAND_MASTER on RS_GRAND_MASTER ptp4l[25339.567]: recvmsg tx timestamp failed: Resource temporarily unavailable ptp4l[25339.567]: port 1: send sync failed ptp4l[25339.567]: port 1: GRAND_MASTER to FAULTY on FAULT_DETECTED ptp4l[25354.574]: port 1: FAULTY to LISTENING on FAULT_CLEARED What is that supposed to mean? Resource temporarily unavailable? So I decided to update my e1000e driver to the latest version available (2.5.4) and use HW timestamping. After rebooting my machine I try to run it with HW support (no option –S) and this is what I get: ptp4l[25432.718]: driver rejected most general HWTSTAMP filter ptp4l[25432.718]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range ptp4l[25432.722]: port 1: INITIALIZING to FAULTY on INITIALIZE ptp4l[25432.722]: port 0: INITIALIZING to LISTENING on INITIALIZE Does anyone know what’s going on? Thank you very much! Fabrizio |
|
From: Fabrizio G. <Fab...@ri...> - 2013-10-21 16:40:57
|
Grazie William,
This is what ethtool -T eth0 returns:
# ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
It clearly says there is no PTP hardware clock, but then why it lists hardware rx/tx capabilities?
In any case, shouldn't it at least work with software timestamping?
Thanks,
Fabrizio
From: Ledda William EXT [mailto:Wil...@it...]
Sent: Monday, October 21, 2013 0:11
To: Fabrizio Giordano; lin...@li...
Subject: RE: Issues with linuxptp and Intel 82574
Ciao Frabrizio,
Have you tried to discover the timestamp capabilities with ethtool -T eth0?
William
From: Fabrizio Giordano [mailto:Fab...@ri...]
Sent: 19 October 2013 02:28
To: lin...@li...
Subject: [Linuxptp-users] Issues with linuxptp and Intel 82574
Hello everyone,
I've been trying to use linux with my Intel 82574 with no much luck.
First I've tried to use it with software timestamping since the version of e1000e I was using didn't support HW timestamping.
This is what I get:
[root@199-dorothy13 ~]# ptp4l -i eth0 -v -S
ptp4l[25333.043]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[25333.043]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[25334.561]: port 1: new foreign master 003048.fffe.9ea9d6-1
ptp4l[25338.561]: selected best master clock 003048.fffe.9ea9d6
ptp4l[25338.561]: port 1: LISTENING to GRAND_MASTER on RS_GRAND_MASTER
ptp4l[25339.567]: recvmsg tx timestamp failed: Resource temporarily unavailable
ptp4l[25339.567]: port 1: send sync failed
ptp4l[25339.567]: port 1: GRAND_MASTER to FAULTY on FAULT_DETECTED
ptp4l[25354.574]: port 1: FAULTY to LISTENING on FAULT_CLEARED
What is that supposed to mean? Resource temporarily unavailable?
So I decided to update my e1000e driver to the latest version available (2.5.4) and use HW timestamping.
After rebooting my machine I try to run it with HW support (no option -S) and this is what I get:
ptp4l[25432.718]: driver rejected most general HWTSTAMP filter
ptp4l[25432.718]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range
ptp4l[25432.722]: port 1: INITIALIZING to FAULTY on INITIALIZE
ptp4l[25432.722]: port 0: INITIALIZING to LISTENING on INITIALIZE
Does anyone know what's going on?
Thank you very much!
Fabrizio
|
27 messages has been excluded from this view by a project administrator.
