allmodconfig gcc-13.2.0
arc allnoconfig gcc-13.2.0
arc allyesconfig gcc-13.2.0
arc defconfig gcc-13.2.0
arc randconfig-001-20240807 gcc-13.2.0
arc
Enable ethtool reset support. Ethtool reset flags are mapped to the
E810 reset type:
PF reset:
$ ethtool --reset irq dma filter offload
CORE reset:
$ ethtool --reset irq-shared dma-shared filter-shared \
offload-shared ram-shared
GLOBAL reset:
$ ethtool --reset irq-shared dma-shared fi
On 06.08.2024 16:55, Simon Horman wrote:
> On Mon, Aug 05, 2024 at 02:46:51PM +0200, Wojciech Drewek wrote:
>> Enable ethtool reset support. Ethtool reset flags are mapped to the
>> E810 reset type:
>> PF reset:
>> $ ethtool --reset irq dma filter offload
>> CORE reset:
>> $ ethtool --reset
Architectures that have PAGE_SIZE >= 8192 such as arm64 should act the
same as x86 currently, meaning reuse of a page should only take place
when no one else is busy with it.
Do two things independently of underlying PAGE_SIZE:
- store the page count under ice_rx_buf::pgcnt
- then act upon its val
Hi,
These three small fixes addres the following panic reported by Luiz
(https://lore.kernel.org/netdev/8f9e2a5c-fd30-4206-9311-946a06d03...@redhat.com/):
[ 225.715759] Unable to handle kernel paging request at virtual address
0075e625f68aa42c
[ 225.723669] Mem abort info:
[ 225.726487] ESR
For bigger PAGE_SIZE archs, ice driver works on 3k Rx buffers.
Therefore, ICE_LAST_OFFSET should take into account ICE_RXBUF_3072, not
ICE_RXBUF_2048.
Fixes: 7237f5b0dba4 ("ice: introduce legacy Rx flag")
Suggested-by: Luiz Capitulino
Signed-off-by: Maciej Fijalkowski
---
drivers/net/ethernet/i
When working on multi-buffer packet on arch that has PAGE_SIZE >= 8192,
truesize is calculated and stored in xdp_buff::frame_sz per each
processed Rx buffer. This means that frame_sz will contain the truesize
based on last received buffer, but commit 1dc1a7e7f410 ("ice:
Centrallize Rx buffer recycl
From: Manoj Vishwanathan
Date: Mon, 5 Aug 2024 18:21:59 +
> The transaction salt was being accessed before acquiring the
> idpf_vc_xn_lock when idpf has to forward the virtchnl reply.
You need to explain in details here what issue you have faced due to
that, how to reproduce it and how this
nsim_700_defconfig gcc-13.2.0
arc randconfig-001-20240807 gcc-13.2.0
arc randconfig-002-20240807 gcc-13.2.0
arm allmodconfig gcc-13.2.0
arm allnoconfig clang-20
arm
From: Kolacinski, Karol
Date: Mon, 5 Aug 2024 18:21:39 +0200
> From: Aleksander Lobakin
> Date: Fri, 26 Jul 2024 15:37 +0200
>>> +/**
>>> + * ice_ptp_set_funcs_e830 - Set specialized functions for E830 support
>>> + * @pf: Board private structure
>>> + *
>>> + * Assign functions to the PTP capab
Thanks Przemek & Olek for your quick feedback and responses.
Hi Olek,
I can add more details about the issue we faced in the commit message.
The bug we had here was a virtchnl delay leading to the xn->salt
mismatch. This could be due to several factors including default CPU
bounded kworker workqueu
From: Manoj Vishwanathan
Date: Wed, 7 Aug 2024 06:58:59 -0700
> Thanks Przemek & Olek for your quick feedback and responses.
> Hi Olek,
> I can add more details about the issue we faced in the commit message.
> The bug we had here was a virtchnl delay leading to the xn->salt
> mismatch. This coul
-13.2.0
arc allyesconfig gcc-13.2.0
arc randconfig-001-20240807 gcc-13.2.0
arc randconfig-002-20240807 gcc-13.2.0
arm allmodconfig gcc-14.1.0
arm allnoconfig clang-20
arm
From: Aleksander Lobakin
Date: Wed, 07 Aug 2024 15:54 +0200
+static void ice_ptp_set_funcs_e830(struct ice_pf *pf)
+{
+#ifdef CONFIG_ICE_HWTS
+ if (pcie_ptm_enabled(pf->pdev) &&
+ boot_cpu_has(X86_FEATURE_ART) &&
+ boot_cpu_has(X86_FEATURE_TSC_KNOW
On 2024-08-07 06:53, Maciej Fijalkowski wrote:
Hi,
These three small fixes addres the following panic reported by Luiz
(https://lore.kernel.org/netdev/8f9e2a5c-fd30-4206-9311-946a06d03...@redhat.com/):
Thank you one more time for getting this fixed!
I had to return the testbed so I won't be a
haps_hs_defconfig gcc-13.2.0
arcnsim_700_defconfig gcc-13.2.0
arc randconfig-001-20240807 gcc-13.2.0
arc randconfig-002-20240807 gcc-13.2.0
arm allmodconfig gcc-13.2.0
arm allmodconfig
Hi Christopher,
On Aug 6 17:30, christopher.s.h...@intel.com wrote:
> From: Christopher S M Hall
>
> Writing to clear the PTM status 'valid' bit while the PTM cycle is
> triggered results in unreliable PTM operation. To fix this, clear the
> PTM 'trigger' and status after each PTM transaction.
allnoconfig gcc-13.2.0
arc allyesconfig gcc-13.2.0
arc randconfig-001-20240807 gcc-13.2.0
arc randconfig-002-20240807 gcc-13.2.0
arm allmodconfig gcc-14.1.0
arm
On Wed, Aug 07, 2024 at 06:58:59AM -0700, Manoj Vishwanathan wrote:
> Thanks Przemek & Olek for your quick feedback and responses.
> Hi Olek,
> I can add more details about the issue we faced in the commit message.
> The bug we had here was a virtchnl delay leading to the xn->salt
> mismatch. This
On 8/1/2024 8:56 AM, Alexander Lobakin wrote:
> From: Paul Greenwalt
> Date: Wed, 31 Jul 2024 21:58:29 -0400
>
>> E830 adds hardware support to prevent the VF from overflowing the PF
>> mailbox with VIRTCHNL messages. E830 will use the hardware feature
>> (ICE_F_MBX_LIMIT) instead of the softw
arcnsim_700_defconfig gcc-13.2.0
arc randconfig-001-20240807 gcc-13.2.0
arc randconfig-002-20240807 gcc-13.2.0
arm allmodconfig gcc-13.2.0
arm allmodconfig gcc-14.1.0
arm
Hi Corrina,
> > PHC2SYS exits with:
> >
> > "ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM
> transaction
> > fails
>
> It would be great to add the problems encountered with kdump to the
> commit message as well, as discussed with Vinicius, wouldn't it?
>
> If you need a descrip
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Zaremba, Larysa
>Sent: Wednesday, July 24, 2024 10:19 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Drewek, Wojciech ; Fijalkowski, Maciej
>; Jesper Dangaard Brouer ;
>Daniel Borkmann ; Zaremba, Larysa
>; net...@vger.kernel.org; J
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Zaremba, Larysa
>Sent: Wednesday, July 24, 2024 10:19 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Drewek, Wojciech ; Fijalkowski, Maciej
>; Jesper Dangaard Brouer ;
>Daniel Borkmann ; Zaremba, Larysa
>; net...@vger.kernel.org; J
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Zaremba, Larysa
>Sent: Wednesday, July 24, 2024 10:19 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Drewek, Wojciech ; Fijalkowski, Maciej
>; Jesper Dangaard Brouer ;
>Daniel Borkmann ; Zaremba, Larysa
>; net...@vger.kernel.org; J
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Zaremba, Larysa
>Sent: Wednesday, July 24, 2024 10:19 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Drewek, Wojciech ; Fijalkowski, Maciej
>; Jesper Dangaard Brouer ;
>Daniel Borkmann ; Zaremba, Larysa
>; net...@vger.kernel.org; J
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Zaremba, Larysa
>Sent: Wednesday, July 24, 2024 10:19 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Drewek, Wojciech ; Fijalkowski, Maciej
>; Jesper Dangaard Brouer ;
>Daniel Borkmann ; Zaremba, Larysa
>; net...@vger.kernel.org; J
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Zaremba, Larysa
>Sent: Wednesday, July 24, 2024 10:19 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Drewek, Wojciech ; Fijalkowski, Maciej
>; Jesper Dangaard Brouer ;
>Daniel Borkmann ; Zaremba, Larysa
>; net...@vger.kernel.org; J
28 matches
Mail list logo
