All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Daiwei Li <daiweili@gmail.com>,
	Richard Cochran <richardcochran@gmail.com>
Cc: sasha.neftin@intel.com,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	kurt@linutronix.de, linux-kernel@vger.kernel.org,
	Jakub Kicinski <kuba@kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	anthony.l.nguyen@intel.com, netdev@vger.kernel.org,
	intel-wired-lan@lists.osuosl.org, Paolo Abeni <pabeni@redhat.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [Intel-wired-lan] [PATCH iwl-net v1] igb: Fix not clearing TimeSync interrupts for 82580
Date: Mon, 12 Aug 2024 10:59:08 -0700	[thread overview]
Message-ID: <87sev9wrkj.fsf@intel.com> (raw)
In-Reply-To: <CAN0jFd1CpPtid7TGJcgzajRXQ5oxYN1LjLjLwK7HjQ1piuZ_XQ@mail.gmail.com>

Hi,

Daiwei Li <daiweili@gmail.com> writes:

>> @Daiwei Li, I don't have a 82580 handy, please confirm that the patch
> fixes the issue you are having.
>
> Thank you for the patch! I can confirm it fixes my issue. Below I offer a
> patch that also works in response to Paul's feedback.
>

Your patch looks better than mine. I would suggest for you to go ahead
and propose yours for inclusion.

>> Please also add a description of the test case
>
> I am running ptp4l to serve PTP to a client device attached to the NIC.
> To test, I am rebuilding igb.ko and reloading it.
> Without this patch, I see repeatedly in the output of ptp4l:
>
>> timed out while polling for tx timestamp increasing tx_timestamp_timeout or
>> increasing kworker priority may correct this issue, but a driver bug likely
>> causes it
>
> as well as my client device failing to sync time.
>
>> and maybe the PCI vendor and device code of your network device.
>
> % lspci -nn | grep Network
> 17:00.0 Ethernet controller [0200]: Intel Corporation 82580 Gigabit
> Network Connection [8086:150e] (rev 01)
> 17:00.1 Ethernet controller [0200]: Intel Corporation 82580 Gigabit
> Network Connection [8086:150e] (rev 01)
> 17:00.2 Ethernet controller [0200]: Intel Corporation 82580 Gigabit
> Network Connection [8086:150e] (rev 01)
> 17:00.3 Ethernet controller [0200]: Intel Corporation 82580 Gigabit
> Network Connection [8086:150e] (rev 01)
>
>> Bug, or was it a feature?
>
> According to https://lore.kernel.org/all/CDCB8BE0.1EC2C%25matthew.vick@intel.com/
> it was a bug. It looks like the datasheet was not updated to
> acknowledge this bug:
> https://www.intel.com/content/www/us/en/content-details/333167/intel-82580-eb-82580-db-gbe-controller-datasheet.html
> (section 8.17.28.1).
>
>> Is there a nicer way to write this, so `ack` is only assigned in case
>> for the 82580?
>
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> b/drivers/net/ethernet/intel/igb/igb_main.c
> index ada42ba63549..87ec1258e22a 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -6986,6 +6986,10 @@ static void igb_tsync_interrupt(struct
> igb_adapter *adapter)
>         struct e1000_hw *hw = &adapter->hw;
>         u32 tsicr = rd32(E1000_TSICR);
>         struct ptp_clock_event event;
> +       const u32 mask = (TSINTR_SYS_WRAP | E1000_TSICR_TXTS |
> +                          TSINTR_TT0 | TSINTR_TT1 |
> +                          TSINTR_AUTT0 | TSINTR_AUTT1);
> +
>
>         if (tsicr & TSINTR_SYS_WRAP) {
>                 event.type = PTP_CLOCK_PPS;
> @@ -7009,6 +7013,13 @@ static void igb_tsync_interrupt(struct
> igb_adapter *adapter)
>
>         if (tsicr & TSINTR_AUTT1)
>                 igb_extts(adapter, 1);
> +
> +       if (hw->mac.type == e1000_82580) {
> +               /* 82580 has a hardware bug that requires a explicit
> +                * write to clear the TimeSync interrupt cause.
> +                */
> +               wr32(E1000_TSICR, tsicr & mask);

Yeah, I should have thought about that, that writing '1' into an
interrupr that is cleared should be fine.

> +       }
>  }
> On Fri, Aug 9, 2024 at 10:04 PM Richard Cochran
> <richardcochran@gmail.com> wrote:
>>
>> On Fri, Aug 09, 2024 at 05:23:02PM -0700, Vinicius Costa Gomes wrote:
>> > It was reported that 82580 NICs have a hardware bug that makes it
>> > necessary to write into the TSICR (TimeSync Interrupt Cause) register
>> > to clear it.
>>
>> Bug, or was it a feature?
>>
>> Or IOW, maybe i210 changed the semantics of the TSICR?
>>
>> And what about the 82576?
>>
>> Thanks,
>> Richard

-- 
Vinicius

WARNING: multiple messages have this Message-ID (diff)
From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Daiwei Li <daiweili@gmail.com>,
	Richard Cochran <richardcochran@gmail.com>
Cc: intel-wired-lan@lists.osuosl.org, sasha.neftin@intel.com,
	kurt@linutronix.de, anthony.l.nguyen@intel.com,
	netdev@vger.kernel.org,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH iwl-net v1] igb: Fix not clearing TimeSync interrupts for 82580
Date: Mon, 12 Aug 2024 10:59:08 -0700	[thread overview]
Message-ID: <87sev9wrkj.fsf@intel.com> (raw)
In-Reply-To: <CAN0jFd1CpPtid7TGJcgzajRXQ5oxYN1LjLjLwK7HjQ1piuZ_XQ@mail.gmail.com>

Hi,

Daiwei Li <daiweili@gmail.com> writes:

>> @Daiwei Li, I don't have a 82580 handy, please confirm that the patch
> fixes the issue you are having.
>
> Thank you for the patch! I can confirm it fixes my issue. Below I offer a
> patch that also works in response to Paul's feedback.
>

Your patch looks better than mine. I would suggest for you to go ahead
and propose yours for inclusion.

>> Please also add a description of the test case
>
> I am running ptp4l to serve PTP to a client device attached to the NIC.
> To test, I am rebuilding igb.ko and reloading it.
> Without this patch, I see repeatedly in the output of ptp4l:
>
>> timed out while polling for tx timestamp increasing tx_timestamp_timeout or
>> increasing kworker priority may correct this issue, but a driver bug likely
>> causes it
>
> as well as my client device failing to sync time.
>
>> and maybe the PCI vendor and device code of your network device.
>
> % lspci -nn | grep Network
> 17:00.0 Ethernet controller [0200]: Intel Corporation 82580 Gigabit
> Network Connection [8086:150e] (rev 01)
> 17:00.1 Ethernet controller [0200]: Intel Corporation 82580 Gigabit
> Network Connection [8086:150e] (rev 01)
> 17:00.2 Ethernet controller [0200]: Intel Corporation 82580 Gigabit
> Network Connection [8086:150e] (rev 01)
> 17:00.3 Ethernet controller [0200]: Intel Corporation 82580 Gigabit
> Network Connection [8086:150e] (rev 01)
>
>> Bug, or was it a feature?
>
> According to https://lore.kernel.org/all/CDCB8BE0.1EC2C%25matthew.vick@intel.com/
> it was a bug. It looks like the datasheet was not updated to
> acknowledge this bug:
> https://www.intel.com/content/www/us/en/content-details/333167/intel-82580-eb-82580-db-gbe-controller-datasheet.html
> (section 8.17.28.1).
>
>> Is there a nicer way to write this, so `ack` is only assigned in case
>> for the 82580?
>
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> b/drivers/net/ethernet/intel/igb/igb_main.c
> index ada42ba63549..87ec1258e22a 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -6986,6 +6986,10 @@ static void igb_tsync_interrupt(struct
> igb_adapter *adapter)
>         struct e1000_hw *hw = &adapter->hw;
>         u32 tsicr = rd32(E1000_TSICR);
>         struct ptp_clock_event event;
> +       const u32 mask = (TSINTR_SYS_WRAP | E1000_TSICR_TXTS |
> +                          TSINTR_TT0 | TSINTR_TT1 |
> +                          TSINTR_AUTT0 | TSINTR_AUTT1);
> +
>
>         if (tsicr & TSINTR_SYS_WRAP) {
>                 event.type = PTP_CLOCK_PPS;
> @@ -7009,6 +7013,13 @@ static void igb_tsync_interrupt(struct
> igb_adapter *adapter)
>
>         if (tsicr & TSINTR_AUTT1)
>                 igb_extts(adapter, 1);
> +
> +       if (hw->mac.type == e1000_82580) {
> +               /* 82580 has a hardware bug that requires a explicit
> +                * write to clear the TimeSync interrupt cause.
> +                */
> +               wr32(E1000_TSICR, tsicr & mask);

Yeah, I should have thought about that, that writing '1' into an
interrupr that is cleared should be fine.

> +       }
>  }
> On Fri, Aug 9, 2024 at 10:04 PM Richard Cochran
> <richardcochran@gmail.com> wrote:
>>
>> On Fri, Aug 09, 2024 at 05:23:02PM -0700, Vinicius Costa Gomes wrote:
>> > It was reported that 82580 NICs have a hardware bug that makes it
>> > necessary to write into the TSICR (TimeSync Interrupt Cause) register
>> > to clear it.
>>
>> Bug, or was it a feature?
>>
>> Or IOW, maybe i210 changed the semantics of the TSICR?
>>
>> And what about the 82576?
>>
>> Thanks,
>> Richard

-- 
Vinicius

  reply	other threads:[~2024-08-12 17:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-10  0:23 [Intel-wired-lan] [PATCH iwl-net v1] igb: Fix not clearing TimeSync interrupts for 82580 Vinicius Costa Gomes
2024-08-10  0:23 ` Vinicius Costa Gomes
2024-08-10  4:21 ` [Intel-wired-lan] " Paul Menzel
2024-08-10  4:21   ` Paul Menzel
2024-08-10  5:04 ` Richard Cochran
2024-08-10  5:04   ` Richard Cochran
2024-08-10 15:55   ` [Intel-wired-lan] " Daiwei Li
2024-08-10 15:55     ` Daiwei Li
2024-08-12 17:59     ` Vinicius Costa Gomes [this message]
2024-08-12 17:59       ` Vinicius Costa Gomes
2024-08-13  3:35       ` [Intel-wired-lan] [PATCH iwl-net v2] " Daiwei Li
2024-08-13  3:35         ` Daiwei Li
2024-08-13 22:26         ` [Intel-wired-lan] " Vinicius Costa Gomes
2024-08-13 22:26           ` Vinicius Costa Gomes
2024-08-14  4:58           ` [Intel-wired-lan] " Daiwei Li
2024-08-14  4:58             ` Daiwei Li
2024-08-13  4:12 ` [Intel-wired-lan] [PATCH iwl-net v1] " Ratheesh Kannoth
2024-08-13  4:12   ` Ratheesh Kannoth
2024-08-13 15:02   ` [Intel-wired-lan] " Jakub Kicinski
2024-08-13 15:02     ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sev9wrkj.fsf@intel.com \
    --to=vinicius.gomes@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=daiweili@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kuba@kernel.org \
    --cc=kurt@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=richardcochran@gmail.com \
    --cc=sasha.neftin@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.