Phc2sys on mgbe0 causes kernel null pointer dereference

The desired setup: Orin as PTP grandmaster serving time to device attached to an ethernet port. System time set by chrony using either NMEA/PPS or NTP. System clock synced to ethernet port with phc2sys.

However, when I run the command:

/usr/sbin/phc2sys -s CLOCK_REALTIME -c mgbe0 -O 37 -m

I immediately get a kernel panic:

[   953.458138] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[   953.458424] Mem abort info:
[   953.458523]   ESR = 0x96000044
[   953.458626]   EC = 0x25: DABT (current EL), IL = 32 bits
[   953.458787]   SET = 0, FnV = 0
[   953.458884]   EA = 0, S1PTW = 0
[   953.458976] Data abort info:
[   953.459059]   ISV = 0, ISS = 0x00000044
[   953.459177]   CM = 0, WnR = 1
[   953.459267] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000194ac7000
[   953.459452] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
[   953.459681] Internal error: Oops: 96000044 [#1] PREEMPT SMP

We successfully used this setup on an AGX Xavier. Any reason why this doesn’t work on the Orin?

Sorry that I have no experience with phc2sys. What is mgbe0 parameter doing there?

phc2sys is taking the time from the system clock and placing it on the mgbe0 ethernet interface, to allow PTP to work accurately.

It requires that the NIC is hardware timestamping capable but as far as I can see it is:

$ ethtool -T mgbe0
Time stamping parameters for mgbe0:
	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)

Are you reproducing this issue on a NV devkit?

We’re using a Connect Tech Rogue Carrier for the ethernet connectors


Are you sure this is the correct usage? I checked some internal usage and didn’t see anyone is directly using -c mgbe0. We use phc2sys on /dev/ptpX instead of mgbe0…

Thanks Wayne. I tried /dev/ptp0 and /dev/ptp1 also and they both give the same immediate kernel error.

Do you have any suggestions on how we might debug the kernel crash? That might give us a pointer to the underlying issue.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.