May 2024 - Linux-stable-mirror

[tip: x86/urgent] x86/cpu: Provide default cache line size if not enumerated

by tip-bot2 for Dave Hansen

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 2a38e4ca302280fdcce370ba2bee79bac16c4587 Gitweb: https://git.kernel.org/tip/2a38e4ca302280fdcce370ba2bee79bac16c4587 Author: Dave Hansen <dave.hansen(a)linux.intel.com> AuthorDate: Fri, 17 May 2024 13:05:34 -07:00 Committer: Dave Hansen <dave.hansen(a)linux.intel.com> CommitterDate: Thu, 30 May 2024 08:29:45 -07:00 x86/cpu: Provide default cache line size if not enumerated tl;dr: CPUs with CPUID.80000008H but without CPUID.01H:EDX[CLFSH] will end up reporting cache_line_size()==0 and bad things happen. Fill in a default on those to avoid the problem. Long Story: The kernel dies a horrible death if c->x86_cache_alignment (aka. cache_line_size() is 0. Normally, this value is populated from c->x86_clflush_size. Right now the code is set up to get c->x86_clflush_size from two places. First, modern CPUs get it from CPUID. Old CPUs that don't have leaf 0x80000008 (or CPUID at all) just get some sane defaults from the kernel in get_cpu_address_sizes(). The vast majority of CPUs that have leaf 0x80000008 also get ->x86_clflush_size from CPUID. But there are oddballs. Intel Quark CPUs[1] and others[2] have leaf 0x80000008 but don't set CPUID.01H:EDX[CLFSH], so they skip over filling in ->x86_clflush_size: cpuid(0x00000001, &tfms, &misc, &junk, &cap0); if (cap0 & (1<<19)) c->x86_clflush_size = ((misc >> 8) & 0xff) * 8; So they: land in get_cpu_address_sizes() and see that CPUID has level 0x80000008 and jump into the side of the if() that does not fill in c->x86_clflush_size. That assigns a 0 to c->x86_cache_alignment, and hilarity ensues in code like: buffer = kzalloc(ALIGN(sizeof(*buffer), cache_line_size()), GFP_KERNEL); To fix this, always provide a sane value for ->x86_clflush_size. Big thanks to Andy Shevchenko for finding and reporting this and also providing a first pass at a fix. But his fix was only partial and only worked on the Quark CPUs. It would not, for instance, have worked on the QEMU config. 1. https://raw.githubusercontent.com/InstLatx64/InstLatx64/master/GenuineIntel… 2. You can also get this behavior if you use "-cpu 486,+clzero" in QEMU. [ dhansen: remove 'vp_bits_from_cpuid' reference in changelog because bpetkov brutally murdered it recently. ] Fixes: fbf6449f84bf ("x86/sev-es: Set x86_virt_bits to the correct value straight away, instead of a two-phase approach") Reported-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Tested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Tested-by: Jörn Heusipp <osmanx(a)heusipp.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20240516173928.3960193-1-andriy.shevchenko@linu… Link: https://lore.kernel.org/lkml/5e31cad3-ad4d-493e-ab07-724cfbfaba44@heusipp.d… Link: https://lore.kernel.org/all/20240517200534.8EC5F33E%40davehans-spike.ostc.i… --- arch/x86/kernel/cpu/common.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 2b170da..e31293c 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1075,6 +1075,10 @@ void get_cpu_address_sizes(struct cpuinfo_x86 *c) c->x86_virt_bits = (eax >> 8) & 0xff; c->x86_phys_bits = eax & 0xff; + + /* Provide a sane default if not enumerated: */ + if (!c->x86_clflush_size) + c->x86_clflush_size = 32; } c->x86_cache_bits = c->x86_phys_bits;

1 year, 1 month

1
0
0 0

[tip: x86/urgent] x86/cpu: Provide default cache line size if not enumerated

by tip-bot2 for Dave Hansen

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: b9210e56d71d9deb1ad692e405f6b2394f7baa4d Gitweb: https://git.kernel.org/tip/b9210e56d71d9deb1ad692e405f6b2394f7baa4d Author: Dave Hansen <dave.hansen(a)linux.intel.com> AuthorDate: Fri, 17 May 2024 13:05:34 -07:00 Committer: Dave Hansen <dave.hansen(a)linux.intel.com> CommitterDate: Thu, 30 May 2024 07:14:27 -07:00 x86/cpu: Provide default cache line size if not enumerated tl;dr: CPUs with CPUID.80000008H but without CPUID.01H:EDX[CLFSH] will end up reporting cache_line_size()==0 and bad things happen. Fill in a default on those to avoid the problem. Long Story: The kernel dies a horrible death if c->x86_cache_alignment (aka. cache_line_size() is 0. Normally, this value is populated from c->x86_clflush_size. Right now the code is set up to get c->x86_clflush_size from two places. First, modern CPUs get it from CPUID. Old CPUs that don't have leaf 0x80000008 (or CPUID at all) just get some sane defaults from the kernel in get_cpu_address_sizes(). The vast majority of CPUs that have leaf 0x80000008 also get ->x86_clflush_size from CPUID. But there are oddballs. Intel Quark CPUs[1] and others[2] have leaf 0x80000008 but don't set CPUID.01H:EDX[CLFSH], so they skip over filling in ->x86_clflush_size: cpuid(0x00000001, &tfms, &misc, &junk, &cap0); if (cap0 & (1<<19)) c->x86_clflush_size = ((misc >> 8) & 0xff) * 8; So they: land in get_cpu_address_sizes() and see that CPUID has level 0x80000008 and jump into the side of the if() that does not fill in c->x86_clflush_size. That assigns a 0 to c->x86_cache_alignment, and hilarity ensues in code like: buffer = kzalloc(ALIGN(sizeof(*buffer), cache_line_size()), GFP_KERNEL); To fix this, always provide a sane value for ->x86_clflush_size. Big thanks to Andy Shevchenko for finding and reporting this and also providing a first pass at a fix. But his fix was only partial and only worked on the Quark CPUs. It would not, for instance, have worked on the QEMU config. 1. https://raw.githubusercontent.com/InstLatx64/InstLatx64/master/GenuineIntel… 2. You can also get this behavior if you use "-cpu 486,+clzero" in QEMU. [ dhansen: remove 'vp_bits_from_cpuid' reference in changelog because bpetkov brutally murdered it recently. ] Fixes: fbf6449f84bf ("x86/sev-es: Set x86_virt_bits to the correct value straight away, instead of a two-phase approach") Reported-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Tested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Tested-by: Jörn Heusipp <osmanx(a)heusipp.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20240516173928.3960193-1-andriy.shevchenko@linu… Link: https://lore.kernel.org/lkml/5e31cad3-ad4d-493e-ab07-724cfbfaba44@heusipp.d… Link: https://lore.kernel.org/all/20240517200534.8EC5F33E%40davehans-spike.ostc.i… --- arch/x86/kernel/cpu/common.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 2b170da..373b16b 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1070,6 +1070,10 @@ void get_cpu_address_sizes(struct cpuinfo_x86 *c) cpu_has(c, X86_FEATURE_PSE36)) c->x86_phys_bits = 36; } + + /* Provide a sane default if not enumerated: */ + if (!c->x86_clflush_size) + c->x86_clflush_size = 32; } else { cpuid(0x80000008, &eax, &ebx, &ecx, &edx);

1 year, 1 month

3
2
0 0

[PATCH] x86/cpu: Provide default cache line size if not enumerated

by Dave Hansen

From: Dave Hansen <dave.hansen(a)linux.intel.com> tl;dr: CPUs with CPUID.80000008H but without CPUID.01H:EDX[CLFSH] will end up reporting cache_line_size()==0 and bad things happen. Fill in a default on those to avoid the problem. Long Story: The kernel dies a horrible death if c->x86_cache_alignment (aka. cache_line_size() is 0. Normally, this value is populated from c->x86_clflush_size. Right now the code is set up to get c->x86_clflush_size from two places. First, modern CPUs get it from CPUID. Old CPUs that don't have leaf 0x80000008 (or CPUID at all) just get some sane defaults from the kernel in get_cpu_address_sizes(). The vast majority of CPUs that have leaf 0x80000008 also get ->x86_clflush_size from CPUID. But there are oddballs. Intel Quark CPUs[1] and others[2] have leaf 0x80000008 but don't set CPUID.01H:EDX[CLFSH], so they skip over filling in ->x86_clflush_size: cpuid(0x00000001, &tfms, &misc, &junk, &cap0); if (cap0 & (1<<19)) c->x86_clflush_size = ((misc >> 8) & 0xff) * 8; So they: land in get_cpu_address_sizes(), set vp_bits_from_cpuid=0 and never fill in c->x86_clflush_size, assign c->x86_cache_alignment, and hilarity ensues in code like: buffer = kzalloc(ALIGN(sizeof(*buffer), cache_line_size()), GFP_KERNEL); To fix this, always provide a sane value for ->x86_clflush_size. Big thanks to Andy Shevchenko for finding and reporting this and also providing a first pass at a fix. But his fix was only partial and only worked on the Quark CPUs. It would not, for instance, have worked on the QEMU config. 1. https://raw.githubusercontent.com/InstLatx64/InstLatx64/master/GenuineIntel… 2. You can also get this behavior if you use "-cpu 486,+clzero" in QEMU. Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Reported-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Fixes: fbf6449f84bf ("x86/sev-es: Set x86_virt_bits to the correct value straight away, instead of a two-phase approach") Link: https://lore.kernel.org/all/20240516173928.3960193-1-andriy.shevchenko@linu… Cc: stable(a)vger.kernel.org --- b/arch/x86/kernel/cpu/common.c | 4 ++++ 1 file changed, 4 insertions(+) diff -puN arch/x86/kernel/cpu/common.c~default-x86_clflush_size arch/x86/kernel/cpu/common.c --- a/arch/x86/kernel/cpu/common.c~default-x86_clflush_size 2024-05-17 12:51:25.886169008 -0700 +++ b/arch/x86/kernel/cpu/common.c 2024-05-17 13:03:09.761999885 -0700 @@ -1064,6 +1064,10 @@ void get_cpu_address_sizes(struct cpuinf c->x86_virt_bits = (eax >> 8) & 0xff; c->x86_phys_bits = eax & 0xff; + + /* Provide a sane default if not enumerated: */ + if (!c->x86_clflush_size) + c->x86_clflush_size = 32; } else { if (IS_ENABLED(CONFIG_X86_64)) { c->x86_clflush_size = 64; _

1 year, 1 month

4
5
0 0

[PATCH] drm/radeon: Remove __counted_by from StateArray.states[]

by Nathan Chancellor

From: Bill Wendling <morbo(a)google.com> Work for __counted_by on generic pointers in structures (not just flexible array members) has started landing in Clang 19 (current tip of tree). During the development of this feature, a restriction was added to __counted_by to prevent the flexible array member's element type from including a flexible array member itself such as: struct foo { int count; char buf[]; }; struct bar { int count; struct foo data[] __counted_by(count); }; because the size of data cannot be calculated with the standard array size formula: sizeof(struct foo) * count This restriction was downgraded to a warning but due to CONFIG_WERROR, it can still break the build. The application of __counted_by on the states member of 'struct _StateArray' triggers this restriction, resulting in: drivers/gpu/drm/radeon/pptable.h:442:5: error: 'counted_by' should not be applied to an array with element of unknown size because 'ATOM_PPLIB_STATE_V2' (aka 'struct _ATOM_PPLIB_STATE_V2') is a struct type with a flexible array member. This will be an error in a future compiler version [-Werror,-Wbounds-safety-counted-by-elt-type-unknown-size] 442 | ATOM_PPLIB_STATE_V2 states[] __counted_by(ucNumEntries); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. Remove this use of __counted_by to fix the warning/error. However, rather than remove it altogether, leave it commented, as it may be possible to support this in future compiler releases. Cc: stable(a)vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/2028 Fixes: efade6fe50e7 ("drm/radeon: silence UBSAN warning (v3)") Signed-off-by: Bill Wendling <morbo(a)google.com> Co-developed-by: Nathan Chancellor <nathan(a)kernel.org> Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- drivers/gpu/drm/radeon/pptable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/pptable.h b/drivers/gpu/drm/radeon/pptable.h index b7f22597ee95..969a8fb0ee9e 100644 --- a/drivers/gpu/drm/radeon/pptable.h +++ b/drivers/gpu/drm/radeon/pptable.h @@ -439,7 +439,7 @@ typedef struct _StateArray{ //how many states we have UCHAR ucNumEntries; - ATOM_PPLIB_STATE_V2 states[] __counted_by(ucNumEntries); + ATOM_PPLIB_STATE_V2 states[] /* __counted_by(ucNumEntries) */; }StateArray; --- base-commit: e64e8f7c178e5228e0b2dbb504b9dc75953a319f change-id: 20240529-drop-counted-by-radeon-states-state-array-01936ded4c18 Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

1 year, 1 month

2
1
0 0

[PATCH v3 0/4] LoongArch: Bootloader interface fixes

by Jiaxun Yang

Hi all, This series fixed some issues on bootloader - kernel interface. The first two fixed booting with devicetree, the last two enhanced kernel's tolerance on different bootloader implementation. Please review. Thanks Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> --- Changes in v3: - Polish all individual patches with comments received offline. - Link to v2: https://lore.kernel.org/r/20240522-loongarch-booting-fixes-v2-0-727edb96e54… Changes in v2: - Enhance PATCH 3-4 based on off list discussions with Huacai & co. - Link to v1: https://lore.kernel.org/r/20240521-loongarch-booting-fixes-v1-0-659c201c037… --- Jiaxun Yang (4): LoongArch: Fix built-in DTB detection LoongArch: smp: Add all CPUs enabled by fdt to NUMA node 0 LoongArch: Fix entry point in image header LoongArch: Override higher address bits in JUMP_VIRT_ADDR arch/loongarch/include/asm/stackframe.h | 2 +- arch/loongarch/kernel/head.S | 2 +- arch/loongarch/kernel/setup.c | 6 ++++-- arch/loongarch/kernel/smp.c | 5 ++++- arch/loongarch/kernel/vmlinux.lds.S | 2 ++ drivers/firmware/efi/libstub/loongarch.c | 2 +- 6 files changed, 13 insertions(+), 6 deletions(-) --- base-commit: 124cfbcd6d185d4f50be02d5f5afe61578916773 change-id: 20240521-loongarch-booting-fixes-366e13e7ca55 Best regards, -- Jiaxun Yang <jiaxun.yang(a)flygoat.com>

1 year, 1 month

5
10
0 0

[PATCH] kheaders: explicitly define file modes for archived headers

by Matthias Männich

From: Matthias Maennich <maennich(a)google.com> Build environments might be running with different umask settings resulting in indeterministic file modes for the files contained in kheaders.tar.xz. The file itself is served with 444, i.e. world readable. Archive the files explicitly with 744,a+X to improve reproducibility across build environments. --mode=0444 is not suitable as directories need to be executable. Also, 444 makes it hard to delete all the readonly files after extraction. Cc: stable(a)vger.kernel.org Cc: linux-kbuild(a)vger.kernel.org Cc: Masahiro Yamada <masahiroy(a)kernel.org> Cc: Joel Fernandes <joel(a)joelfernandes.org> Signed-off-by: Matthias Maennich <maennich(a)google.com> --- kernel/gen_kheaders.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/gen_kheaders.sh b/kernel/gen_kheaders.sh index 6d443ea22bb7..8b6e0c2bc0df 100755 --- a/kernel/gen_kheaders.sh +++ b/kernel/gen_kheaders.sh @@ -84,7 +84,7 @@ find $cpio_dir -type f -print0 | # Create archive and try to normalize metadata for reproducibility. tar "${KBUILD_BUILD_TIMESTAMP:+--mtime=$KBUILD_BUILD_TIMESTAMP}" \ - --owner=0 --group=0 --sort=name --numeric-owner \ + --owner=0 --group=0 --sort=name --numeric-owner --mode=u=rw,go=r,a+X \ -I $XZ -cf $tarfile -C $cpio_dir/ . > /dev/null echo $headers_md5 > kernel/kheaders.md5 -- 2.45.1.288.g0e0cd299f1-goog

1 year, 1 month

2
1
0 0

[PATCH v3] ata: ahci: Do not apply Intel PCS quirk on Intel Alder Lake

by Jason Nader

Commit b8b8b4e0c052 ("ata: ahci: Add Intel Alder Lake-P AHCI controller to low power chipsets list") added Intel Alder Lake to the ahci_pci_tbl. Because of the way that the Intel PCS quirk was implemented, having an explicit entry in the ahci_pci_tbl caused the Intel PCS quirk to be applied. (The quirk was not being applied if there was no explict entry.) Thus, entries that were added to the ahci_pci_tbl also got the Intel PCS quirk applied. The quirk was cleaned up in commit 7edbb6059274 ("ahci: clean up intel_pcs_quirk"), such that it is clear which entries that actually applies the Intel PCS quirk. Newer Intel AHCI controllers do not need the Intel PCS quirk, and applying it when not needed actually breaks some platforms. Do not apply the Intel PCS quirk for Intel Alder Lake. This is in line with how things worked before commit b8b8b4e0c052 ("ata: ahci: Add Intel Alder Lake-P AHCI controller to low power chipsets list"), such that certain platforms using Intel Alder Lake will work once again. Cc: stable(a)vger.kernel.org # 6.7 Fixes: b8b8b4e0c052 ("ata: ahci: Add Intel Alder Lake-P AHCI controller to low power chipsets list") Signed-off-by: Jason Nader <dev(a)kayoway.com> --- drivers/ata/ahci.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 6548f10e61d9..07d66d2c5f0d 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -429,7 +429,6 @@ static const struct pci_device_id ahci_pci_tbl[] = { { PCI_VDEVICE(INTEL, 0x02d7), board_ahci_pcs_quirk }, /* Comet Lake PCH RAID */ /* Elkhart Lake IDs 0x4b60 & 0x4b62 https://sata-io.org/product/8803 not tested yet */ { PCI_VDEVICE(INTEL, 0x4b63), board_ahci_pcs_quirk }, /* Elkhart Lake AHCI */ - { PCI_VDEVICE(INTEL, 0x7ae2), board_ahci_pcs_quirk }, /* Alder Lake-P AHCI */ /* JMicron 360/1/3/5/6, match class to avoid IDE function */ { PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, -- 2.45.1

1 year, 1 month

3
2
0 0

[REGRESSION][BISECTED] Scheduling errors with the AMD FX 8300 CPU

by Christian Heusel

Hello Thomas, Tim reports a regression on his AMD FX 8300 CPU that causes him scheduling errors (see dmesg below), initially on the latest stable kernel from Arch Linux. The issue reproduces by simply booting the kernel on his hardware. He also reported some ATA related errors (also attached below the dmesg), of which I dont know whether they are relevant or not. We have debugged the issue together in the ticket in our bugtracker[0] and collectively bisected it down to the following commit: c749ce393b8f ("x86/cpu: Use common topology code for AMD") Tim (in CC) offered to be available for further debugging in this thread. Reported-by: Tim Teichmann <teichmanntim(a)outlook.de> Bisected-by: Christian Heusel <christian(a)heusel.eu> Cheers, Chris [0]: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/56 --- #regzbot link: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/56 #regzbot introduced: c749ce393b8f #regzbot title: Scheduling errors with the AMD FX 8300 CPU --- dmesg output: May 23 23:36:49 archlinux kernel: smp: Bringing up secondary CPUs ... May 23 23:36:49 archlinux kernel: smpboot: x86: Booting SMP configuration: May 23 23:36:49 archlinux kernel: .... node #0, CPUs: #2 #4 #6 May 23 23:36:49 archlinux kernel: __common_interrupt: 2.55 No irq handler for vector May 23 23:36:49 archlinux kernel: __common_interrupt: 4.55 No irq handler for vector May 23 23:36:49 archlinux kernel: __common_interrupt: 6.55 No irq handler for vector May 23 23:36:49 archlinux kernel: #1 #3 #5 #7 May 23 23:36:49 archlinux kernel: ------------[ cut here ]------------ May 23 23:36:49 archlinux kernel: WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6482 sched_cpu_starting+0x183/0x250 May 23 23:36:49 archlinux kernel: Modules linked in: May 23 23:36:49 archlinux kernel: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.9.1-arch1-2 #1 06928436e5a6b4805e171d14d8efa397d7db9ad0 May 23 23:36:49 archlinux kernel: Hardware name: Gigabyte Technology Co., Ltd. GA-78LMT-USB3 R2/GA-78LMT-USB3 R2, BIOS F1 11/08/2017 May 23 23:36:49 archlinux kernel: RIP: 0010:sched_cpu_starting+0x183/0x250 May 23 23:36:49 archlinux kernel: Code: 00 8b 0d b0 e0 10 02 39 c8 0f 83 71 ff ff ff 48 63 d0 48 8b 3c d5 20 53 71 a6 4c 01 e7 39 c3 75 c7 4c 89 bf 48 0d 00 00 eb c7 <0f> 0b eb c3 be 04 00> May 23 23:36:49 archlinux kernel: RSP: 0000:ffffa6a3c00cfe38 EFLAGS: 00010087 May 23 23:36:49 archlinux kernel: RAX: 0000000000000002 RBX: 0000000000000001 RCX: 0000000000000008 May 23 23:36:49 archlinux kernel: RDX: 0000000000000002 RSI: fffffffffffffffc RDI: ffff9367aeb36540 May 23 23:36:49 archlinux kernel: RBP: ffff9367aea99b00 R08: ffff9367aea99b00 R09: 0000000000000003 May 23 23:36:49 archlinux kernel: R10: ffff9367aea99b00 R11: 0000000000000006 R12: 0000000000036540 May 23 23:36:49 archlinux kernel: R13: 0000000000036540 R14: 0000000000000001 R15: ffff9367aea36540 May 23 23:36:49 archlinux kernel: FS: 0000000000000000(0000) GS:ffff9367aea80000(0000) knlGS:0000000000000000 May 23 23:36:49 archlinux kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 May 23 23:36:49 archlinux kernel: CR2: 0000000000000000 CR3: 000000036dc20000 CR4: 00000000000406f0 May 23 23:36:49 archlinux kernel: Call Trace: May 23 23:36:49 archlinux kernel: <TASK> May 23 23:36:49 archlinux kernel: ? sched_cpu_starting+0x183/0x250 May 23 23:36:49 archlinux kernel: ? __warn.cold+0x8e/0xe8 May 23 23:36:49 archlinux kernel: ? sched_cpu_starting+0x183/0x250 May 23 23:36:49 archlinux kernel: ? report_bug+0xff/0x140 May 23 23:36:49 archlinux kernel: ? handle_bug+0x3c/0x80 May 23 23:36:49 archlinux kernel: ? exc_invalid_op+0x17/0x70 May 23 23:36:49 archlinux kernel: ? asm_exc_invalid_op+0x1a/0x20 May 23 23:36:49 archlinux kernel: ? sched_cpu_starting+0x183/0x250 May 23 23:36:49 archlinux kernel: ? sched_cpu_starting+0x15a/0x250 May 23 23:36:49 archlinux kernel: ? __pfx_sched_cpu_starting+0x10/0x10 May 23 23:36:49 archlinux kernel: cpuhp_invoke_callback+0x122/0x410 May 23 23:36:49 archlinux kernel: __cpuhp_invoke_callback_range+0x64/0xc0 May 23 23:36:49 archlinux kernel: start_secondary+0x9c/0x140 May 23 23:36:49 archlinux kernel: common_startup_64+0x13e/0x141 May 23 23:36:49 archlinux kernel: </TASK> May 23 23:36:49 archlinux kernel: ---[ end trace 0000000000000000 ]--- May 23 23:36:49 archlinux kernel: __common_interrupt: 1.55 No irq handler for vector May 23 23:36:49 archlinux kernel: __common_interrupt: 3.55 No irq handler for vector May 23 23:36:49 archlinux kernel: __common_interrupt: 5.55 No irq handler for vector May 23 23:36:49 archlinux kernel: __common_interrupt: 7.55 No irq handler for vector May 23 23:36:49 archlinux kernel: smp: Brought up 1 node, 8 CPUs May 23 23:36:49 archlinux kernel: smpboot: Total of 8 processors activated (53173.28 BogoMIPS) May 23 23:36:49 archlinux kernel: ------------[ cut here ]------------ May 23 23:36:49 archlinux kernel: WARNING: CPU: 0 PID: 1 at kernel/sched/topology.c:2408 build_sched_domains+0x76b/0x12b0 May 23 23:36:49 archlinux kernel: Modules linked in: May 23 23:36:49 archlinux kernel: CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.9.1-arch1-2 #1 06928436e5a6b4805e171d14d8efa397d7db9ad0 May 23 23:36:49 archlinux kernel: Hardware name: Gigabyte Technology Co., Ltd. GA-78LMT-USB3 R2/GA-78LMT-USB3 R2, BIOS F1 11/08/2017 May 23 23:36:49 archlinux kernel: RIP: 0010:build_sched_domains+0x76b/0x12b0 May 23 23:36:49 archlinux kernel: Code: 63 4d 14 39 34 8a 0f 8e 73 fe ff ff 25 e9 ef ff ff 80 cc 04 41 89 46 3c e9 62 fe ff ff 41 c7 46 30 01 00 00 00 e9 55 fe ff ff <0f> 0b bb f4 ff ff ff> May 23 23:36:49 archlinux kernel: RSP: 0018:ffffa6a3c001fe10 EFLAGS: 00010202 May 23 23:36:49 archlinux kernel: RAX: 00000000ffffff01 RBX: 0000000000000000 RCX: 00000000ffffff01 May 23 23:36:49 archlinux kernel: RDX: 00000000fffffff8 RSI: 0000000000000003 RDI: ffff9367aea19b00 May 23 23:36:49 archlinux kernel: RBP: ffff936480367a00 R08: ffff9367aea19b00 R09: 0000000000000000 May 23 23:36:49 archlinux kernel: R10: ffffa6a3c001fdd8 R11: 0000000000000000 R12: 0000000000000001 May 23 23:36:49 archlinux kernel: R13: ffff9367aea99b00 R14: 0000000000000001 R15: ffff936480942e80 May 23 23:36:49 archlinux kernel: FS: 0000000000000000(0000) GS:ffff9367aea00000(0000) knlGS:0000000000000000 May 23 23:36:49 archlinux kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 May 23 23:36:49 archlinux kernel: CR2: ffff9366eea01000 CR3: 000000036dc20000 CR4: 00000000000406f0 May 23 23:36:49 archlinux kernel: Call Trace: May 23 23:36:49 archlinux kernel: <TASK> May 23 23:36:49 archlinux kernel: ? build_sched_domains+0x76b/0x12b0 May 23 23:36:49 archlinux kernel: ? __warn.cold+0x8e/0xe8 May 23 23:36:49 archlinux kernel: ? build_sched_domains+0x76b/0x12b0 May 23 23:36:49 archlinux kernel: ? report_bug+0xff/0x140 May 23 23:36:49 archlinux kernel: ? handle_bug+0x3c/0x80 May 23 23:36:49 archlinux kernel: ? exc_invalid_op+0x17/0x70 May 23 23:36:49 archlinux kernel: ? asm_exc_invalid_op+0x1a/0x20 May 23 23:36:49 archlinux kernel: ? build_sched_domains+0x76b/0x12b0 May 23 23:36:49 archlinux kernel: ? kmalloc_trace+0x13a/0x320 May 23 23:36:49 archlinux kernel: sched_init_smp+0x3e/0xc0 May 23 23:36:49 archlinux kernel: ? stop_machine+0x30/0x40 May 23 23:36:49 archlinux kernel: kernel_init_freeable+0x109/0x250 May 23 23:36:49 archlinux kernel: ? __pfx_kernel_init+0x10/0x10 May 23 23:36:49 archlinux kernel: kernel_init+0x1a/0x140 May 23 23:36:49 archlinux kernel: ret_from_fork+0x34/0x50 May 23 23:36:49 archlinux kernel: ? __pfx_kernel_init+0x10/0x10 May 23 23:36:49 archlinux kernel: ret_from_fork_asm+0x1a/0x30 May 23 23:36:49 archlinux kernel: </TASK> May 23 23:36:49 archlinux kernel: ---[ end trace 0000000000000000 ]--- --- ATA stuff: May 23 23:36:59 archlinux kernel: ata2.00: exception Emask 0x10 SAct 0x1fffe000 SErr 0x40d0002 action 0xe frozen May 23 23:36:59 archlinux kernel: ata2.00: irq_stat 0x00000040, connection status changed May 23 23:36:59 archlinux kernel: ata2: SError: { RecovComm PHYRdyChg CommWake 10B8B DevExch } May 23 23:36:59 archlinux kernel: ata2.00: failed command: WRITE FPDMA QUEUED May 23 23:36:59 archlinux kernel: ata2.00: cmd 61/10:68:10:f8:07/00:00:00:00:00/40 tag 13 ncq dma 8192 out res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) May 23 23:36:59 archlinux kernel: ata2.00: status: { DRDY } May 23 23:36:59 archlinux kernel: ata2.00: failed command: WRITE FPDMA QUEUED May 23 23:36:59 archlinux kernel: ata2.00: cmd 61/08:70:28:f8:07/00:00:00:00:00/40 tag 14 ncq dma 4096 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) May 23 23:36:59 archlinux kernel: ata2.00: status: { DRDY } May 23 23:36:59 archlinux kernel: ata2.00: failed command: WRITE FPDMA QUEUED May 23 23:36:59 archlinux kernel: ata2.00: cmd 61/18:78:50:f8:07/00:00:00:00:00/40 tag 15 ncq dma 12288 out res 40/00:68:00:00:00/00:00:00:00:00/40 Emask 0x10 (ATA

1 year, 1 month

6
18
0 0

[PATCH 2/2] arm64: dts: qcom: sc7280: Disable SS instances in park mode

by Krishna Kurapati

On SC7280, in host mode, it is observed that stressing out controller in host mode results in HC died error and only restarting the host mode fixes it. Disable SS instances in park mode for these targets to avoid host controller being dead. Reported-by: Doug Anderson <dianders(a)google.com> Cc: <stable(a)vger.kernel.org> Fixes: bb9efa59c665 ("arm64: dts: qcom: sc7280: Add USB related nodes") Signed-off-by: Krishna Kurapati <quic_kriskura(a)quicinc.com> --- arch/arm64/boot/dts/qcom/sc7280.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi index 41f51d326111..e0d3eeb6f639 100644 --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi @@ -4131,6 +4131,7 @@ usb_1_dwc3: usb@a600000 { iommus = <&apps_smmu 0xe0 0x0>; snps,dis_u2_susphy_quirk; snps,dis_enblslpm_quirk; + snps,parkmode-disable-ss-quirk; phys = <&usb_1_hsphy>, <&usb_1_qmpphy QMP_USB43DP_USB3_PHY>; phy-names = "usb2-phy", "usb3-phy"; maximum-speed = "super-speed"; -- 2.34.1

1 year, 1 month

2
1
0 0

[PATCH 1/2] gpio: amd8111: Convert PCIBIOS_* return codes to errnos

by Ilpo Järvinen

amd_gpio_init() uses pci_read_config_dword() that returns PCIBIOS_* codes. The return code is then returned as is but amd_gpio_init() is a module init function that should return normal errnos. Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal errno before returning it from amd_gpio_init(). Fixes: f942a7de047d ("gpio: add a driver for GPIO pins found on AMD-8111 south bridge chips") Cc: stable(a)vger.kernel.org Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> --- drivers/gpio/gpio-amd8111.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-amd8111.c b/drivers/gpio/gpio-amd8111.c index 6f3ded619c8b..3377667a28de 100644 --- a/drivers/gpio/gpio-amd8111.c +++ b/drivers/gpio/gpio-amd8111.c @@ -195,8 +195,10 @@ static int __init amd_gpio_init(void) found: err = pci_read_config_dword(pdev, 0x58, &gp.pmbase); - if (err) + if (err) { + err = pcibios_err_to_errno(err); goto out; + } err = -EIO; gp.pmbase &= 0x0000FF00; if (gp.pmbase == 0) -- 2.39.2

1 year, 1 month

4
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2024