| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAFZh4h-w6u9gSGK2M2v_CDX+KBkZKdqTWz4E2BuPjkHFKbKzRw@mail.gmail.com>
Date: Wed, 23 Aug 2023 14:12:47 -0400
From: Brian Hutchinson <b.hutchman@...il.com>
To: netdev@...r.kernel.org
Subject: Re: Microchip net DSA with ptp4l getting tx_timeout failed msg using
6.3.12 kernel and KSZ9567 switch
Hi Christian,
On Wed, Aug 23, 2023 at 4:22 AM Christian Eggers <ceggers@...i.de> wrote:
>
> Hi Brian,
>
> I just return from my holidays...
Hope you had a good one ... I need one too!
>
> Am Dienstag, 22. August 2023, 23:49:33 CEST schrieben Sie:
> > Getting this tx_timestamp_timeout error over and over when I try to run ptp4l:
> >
> > ptp4l[1366.143]: selected best master clock 001747.fffe.70151b
> > ptp4l[1366.143]: updating UTC offset to 37
> > ptp4l[1366.143]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
> > ptp4l[1366.860]: port 1: delay timeout
> > ptp4l[1376.871]: timed out while polling for tx timestamp
> > ptp4l[1376.871]: increasing tx_timestamp_timeout may correct this
> > issue, but it is likely caused by a driver bug
> > ptp4l[1376.871]: port 1: send delay request failed
> >
> > I was using 5.10.69 with Christians patches before they were mainlined
> > and had everything working with the help of Christian, Vladimir and
> > others.
> >
> > Now I need to update kernel so tried 6.3.12 which contains Christians
> > upstream patches and I also back ported v8 of the upstreamed patches
> > to 6.1.38 and I'm getting the same results with that kernel too.
> >
>
> I am also in the process of upgrading to 6.1.38 (but not really tested).
> I cherry-picked all necessary patches from the latest master (see attached
> archive). Maybe you would like to compare this with your patch series.
Excellent, I will check it out! Yeah, we needed to be on a LTS kernel
so that's why I'm focusing on 6.1.38 as it's the latest in the
yocto/oe universe.
>
> > [...]
> >
> > I tried increasing tx_timestamp and it doesn't appear to matter. I
> > feel like I had this problem before when first starting to work with
> > 5.10.69 but can't remember if another patch resolved it. With 5.10.69
> > I've got quite a few more patches than just the 13 that were mainlined
> > in 6.3. Looking through old emails I want to say it might have been
> > resolved with net-dsa-ksz9477-avoid-PTP-races-with-the-data-path-l.patch
> > that Vladimir gave me but looking at the code it doesn't appear
> > mainline has that one.
>
> How is the IRQ line of you switch attached? I remember there was a problem
> with the IRQ type (edge vs. level), but I think this has already been
> applied to 6.1.38 (via -stable).
So that's one of the first things I thought of which is why I provided
cat of /proc/interrupts.
I also do have a /dev/ptp1 (/dev/ptp0 is imx8mm)
My device tree node is the same as before:
i2c_ksz9567: ksz9567@5f {
compatible = "microchip,ksz9567";
reg = <0x5f>;
phy-mode = "rgmii-id";
status = "okay";
interrupt-parent = <&gpio1>;
interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan1";
};
port@1 {
reg = <1>;
label = "lan2";
};
port@6 {
reg = <6>;
label = "cpu";
ethernet = <&fec1>;
phy-mode = "rgmii-id";
fixed-link {
speed = <100>;
full-duplex;
};
};
};
};
And I have same pinmux setup as before. I double checked all of that.
I noticed new kernel /proc/interrupts now has a bunch of ksz lines in
addition to "gpio-mxc 10 Level" which is IRQ from the ksz switch.
Here is what the old 5.10.69 /proc/interrupts looked like:
cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
11: 46141 127 127 124 GICv3 30 Level
arch_timer
14: 5260 0 0 0 GICv3 79 Level
timer@...a0000
15: 0 0 0 0 GICv3 23 Level arm-pmu
20: 0 0 0 0 GICv3 127 Level sai
21: 0 0 0 0 GICv3 82 Level sai
32: 0 0 0 0 GICv3 110 Level
30280000.watchdog
33: 0 0 0 0 GICv3 135 Level sdma
34: 0 0 0 0 GICv3 66 Level sdma
35: 0 0 0 0 GICv3 52 Level
caam-snvs
36: 0 0 0 0 GICv3 51 Level
rtc alarm
37: 0 0 0 0 GICv3 36 Level
30370000.snvs:snvs-powerkey
39: 0 0 0 0 GICv3 64 Level
30830000.spi
40: 1412 0 0 0 GICv3 59 Level
30890000.serial
42: 55291 0 0 0 GICv3 67 Level
30a20000.i2c
43: 0 0 0 0 GICv3 68 Level
30a30000.i2c
44: 0 0 0 0 GICv3 69 Level
30a40000.i2c
45: 0 0 0 0 GICv3 70 Level
30a50000.i2c
47: 0 0 0 0 GICv3 55 Level mmc1
48: 3003 0 0 0 GICv3 56 Level mmc2
49: 2565 0 0 0 GICv3 139 Level
30bb0000.spi
50: 0 0 0 0 GICv3 34 Level sdma
51: 0 0 0 0 GICv3 150 Level
30be0000.ethernet
52: 0 0 0 0 GICv3 151 Level
30be0000.ethernet
53: 1417 0 0 0 GICv3 152 Level
30be0000.ethernet
54: 0 0 0 0 GICv3 153 Level
30be0000.ethernet
56: 0 0 0 0 GICv3 130 Level
imx8_ddr_perf_pmu
60: 0 0 0 0 gpio-mxc 3 Level
bd718xx-irq
67: 23 0 0 0 gpio-mxc 10 Level 0-005f
72: 0 0 0 0 gpio-mxc 15 Edge
30b50000.mmc cd
217: 0 0 0 0 bd718xx-irq 5 Edge
gpio_keys
IPI0: 29 14 13 13 Rescheduling interrupts
IPI1: 0 41 41 41 Function call interrupts
IPI2: 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 CPU stop (for
crash dump) interrupts
IPI4: 0 0 0 0 Timer broadcast
interrupts
IPI5: 7959 0 0 0 IRQ work interrupts
IPI6: 0 0 0 0 CPU wake-up interrupts
Err: 0
I'll check out your 6.1.38 changes compared to what I did.
Thanks,
Brian
>
> Get all the latest information from www.arri.com, Facebook, Twitter, Instagram, LinkedIn and YouTube.
>
> Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
> Sitz: München ‑ Registergericht: Amtsgericht München ‑ Handelsregisternummer: HRA 57918
> Persönlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
> Sitz: München ‑ Registergericht: Amtsgericht München ‑ Handelsregisternummer: HRB 54477
> Geschäftsführer: Dr. Matthias Erb (Chairman); Lars Weyer; Stephan Schenk; Walter Trauninger
>
>
Powered by blists - more mailing lists