Kernel uses `struct virtio_net_ctrl_rss` to save command-specific-data
for both the VIRTIO_NET_CTRL_MQ_HASH_CONFIG and
VIRTIO_NET_CTRL_MQ_RSS_CONFIG commands.
According to the VirtIO standard, "Field reserved MUST contain zeroes.
It is defined to make the structure to match the layout of
virtio_net_rss_config structure, defined in 5.1.6.5.7.".
Yet for the VIRTIO_NET_CTRL_MQ_HASH_CONFIG command case, the `max_tx_vq`
field in struct virtio_net_ctrl_rss, which corresponds to the
`reserved` field in struct virtio_net_hash_config, is not zeroed,
thereby violating the VirtIO standard.
This patch solves this problem by zeroing this field in
virtnet_init_default_rss().
Cc: Andrew Melnychenko <andrew(a)daynix.com>
Cc: stable(a)vger.kernel.org
Fixes: c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.")
Signed-off-by: Hawkins Jiawei <yin31149(a)gmail.com>
Acked-by: Jason Wang <jasowang(a)redhat.com>
Acked-by: Eugenio Pérez <eperezma(a)redhat.com>
Acked-by: Michael S. Tsirkin <mst(a)redhat.com>
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 1270c8d23463..8db38634ae82 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2761,7 +2761,7 @@ static void virtnet_init_default_rss(struct virtnet_info *vi)
vi->ctrl->rss.indirection_table[i] = indir_val;
}
- vi->ctrl->rss.max_tx_vq = vi->curr_queue_pairs;
+ vi->ctrl->rss.max_tx_vq = vi->has_rss ? vi->curr_queue_pairs : 0;
vi->ctrl->rss.hash_key_length = vi->rss_key_size;
netdev_rss_key_fill(vi->ctrl->rss.key, vi->rss_key_size);
--
2.34.1
The kernel hangs for a good 12 seconds without any info being printed to
dmesg, very early in the boot process, if this regulator is not enabled.
Force-enable it to work around this issue, until we know more about the
underlying problem.
Signed-off-by: Paul Cercueil <paul(a)crapouillou.net>
Fixes: 8620cc2f99b7 ("ARM: dts: exynos: Add devicetree file for the Galaxy S2")
Cc: <stable(a)vger.kernel.org> # v5.8+
---
arch/arm/boot/dts/exynos4210-i9100.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-i9100.dts b/arch/arm/boot/dts/exynos4210-i9100.dts
index a9ec1f6c1dea..a076a1dfe41f 100644
--- a/arch/arm/boot/dts/exynos4210-i9100.dts
+++ b/arch/arm/boot/dts/exynos4210-i9100.dts
@@ -527,6 +527,14 @@ vtcam_reg: LDO12 {
regulator-name = "VT_CAM_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
+
+ /*
+ * Force-enable this regulator; otherwise the
+ * kernel hangs very early in the boot process
+ * for about 12 seconds, without apparent
+ * reason.
+ */
+ regulator-always-on;
};
vcclcd_reg: LDO13 {
--
2.40.1
Hi All,
Here is v3 of my series to address the regressions wrt PS/2 IRQs
not working on AMD zen models.
Changes in v3:
- Add links to more bug reports caused by a9c4a912b7dc to the commitmsg
- Also do the ZEN check for IRQ 12 (Reported-by August Wikerfors)
- Move the gsi != 1 && gsi != 12 check to inside the #ifdef CONFIG_X86,
these being the i8042 IRQs is X86 specific and the "return true;" is
always done for #ifndef CONFIG_X86 already
- Make acpi_int_src_ovr an array which keep track of the status
of all legacy IRQs and not just IRQ 1
Changes in v2:
- Add 2 patches on top of the revert to avoid the revert causing
other models which are known to need the override to regress.
As discussed in the v1 thread:
https://lore.kernel.org/linux-acpi/20230806151453.10690-1-hdegoede@redhat.c…
This series adds a few fixes on top of the revert to avoid the revert
causing regressions on other AMD Zen systems where dropping the special
Zen behavior was known to fix things.
As also mentioned in the thread this is intended as a short term fix
for 6.4.y >= 6.4.7 and 6.5 to get all the systems which were working
fine before commit a9c4a912b7dc ("ACPI: resource: Remove "Zen"
specific match and quirks") to work again.
The long term plan is to see if we can read back what the BIOS
has actually programmed as IRQ trigger-type / polarity into
the IOAPIC.
Regards,
Hans
Hans de Goede (3):
ACPI: resource: revert "Remove "Zen" specific match and quirks"
ACPI: resource: Always use MADT override IRQ settings for all legacy
non i8042 IRQs
ACPI: resource: Honor MADT INT_SRC_OVR settings for IRQ1 on AMD Zen
arch/x86/include/asm/acpi.h | 2 ++
arch/x86/kernel/acpi/boot.c | 4 +++
drivers/acpi/resource.c | 52 +++++++++++++++++++++++++++++++++++++
3 files changed, 58 insertions(+)
--
2.41.0
Dzień dobry,
jakiś czas temu zgłosiła się do nas firma, której strona internetowa nie pozycjonowała się wysoko w wyszukiwarce Google.
Na podstawie wykonanego przez nas audytu SEO zoptymalizowaliśmy treści na stronie pod kątem wcześniej opracowanych słów kluczowych. Nasz wewnętrzny system codziennie analizuje prawidłowe działanie witryny. Dzięki indywidualnej strategii, firma zdobywa coraz więcej Klientów.
Czy chcieliby Państwo zwiększyć liczbę osób odwiedzających stronę internetową firmy? Mógłbym przedstawić ofertę?
Pozdrawiam serdecznie,
Dominik Perkowski
The dma-buf backend is supposed to provide its own vm_ops, but some
implementation just have nothing special to do and leave vm_ops
untouched, probably expecting this field to be zero initialized (this
is the case with the system_heap implementation for instance).
Let's reset vma->vm_ops to NULL to keep things working with these
implementations.
Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf")
Cc: <stable(a)vger.kernel.org>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Reported-by: Roman Stratiienko <roman.stratiienko(a)globallogic.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)collabora.com>
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 4ea6507a77e5..baaf0e0feb06 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -623,7 +623,13 @@ int drm_gem_shmem_mmap(struct drm_gem_shmem_object *shmem, struct vm_area_struct
int ret;
if (obj->import_attach) {
+ /* Reset both vm_ops and vm_private_data, so we don't end up with
+ * vm_ops pointing to our implementation if the dma-buf backend
+ * doesn't set those fields.
+ */
vma->vm_private_data = NULL;
+ vma->vm_ops = NULL;
+
ret = dma_buf_mmap(obj->dma_buf, vma, 0);
/* Drop the reference drm_gem_mmap_obj() acquired.*/
--
2.41.0
Can we backport this patch into stable? It fixes a build error with
binutils >= 2.41.
On Mon, 2023-07-10 at 13:00 +0800, Huacai Chen wrote:
> Binutils 2.41 enables linker relaxation by default, but the kernel
> module loader doesn't support that, so just disable it. Otherwise we
> get such an error when loading modules:
>
> "Unknown relocation type 102"
>
> As an alternative, we could add linker relaxation support in the kernel
> module loader. But it is relatively large complexity that may or may not
> bring a similar gain, and we don't really want to include this linker
> pass in the kernel.
>
> Reviewed-by: WANG Xuerui <git(a)xen0n.name>
> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn>
> ---
> arch/loongarch/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile
> index 09ba338a64de..7466d3b15db8 100644
> --- a/arch/loongarch/Makefile
> +++ b/arch/loongarch/Makefile
> @@ -68,6 +68,8 @@ LDFLAGS_vmlinux += -static -n -nostdlib
> ifdef CONFIG_AS_HAS_EXPLICIT_RELOCS
> cflags-y += $(call cc-option,-mexplicit-relocs)
> KBUILD_CFLAGS_KERNEL += $(call cc-option,-mdirect-extern-access)
> +KBUILD_AFLAGS_MODULE += $(call cc-option,-mno-relax) $(call cc-option,-Wa$(comma)-mno-relax)
> +KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-relax) $(call cc-option,-Wa$(comma)-mno-relax)
> else
> cflags-y += $(call cc-option,-mno-explicit-relocs)
> KBUILD_AFLAGS_KERNEL += -Wa,-mla-global-with-pcrel
--
Xi Ruoyao <xry111(a)xry111.site>
School of Aerospace Science and Technology, Xidian University