- Linux-stable-mirror - lists.linaro.org

[PATCH] ARM: dts: microchip: sama5d2: fix spi flexcom fifo size to 32

by nicolas.ferre＠microchip.com

From: Nicolas Ferre <nicolas.ferre(a)microchip.com> Unlike standalone spi peripherals, on sama5d2, the flexcom spi have fifo size of 32 data. Fix flexcom/spi nodes where this property is wrong. Fixes: 6b9a3584c7ed ("ARM: dts: at91: sama5d2: Add missing flexcom definitions") Cc: <stable(a)vger.kernel.org> # 5.8+ Signed-off-by: Nicolas Ferre <nicolas.ferre(a)microchip.com> --- arch/arm/boot/dts/microchip/sama5d2.dtsi | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/boot/dts/microchip/sama5d2.dtsi b/arch/arm/boot/dts/microchip/sama5d2.dtsi index 17430d7f2055..fde890f18d20 100644 --- a/arch/arm/boot/dts/microchip/sama5d2.dtsi +++ b/arch/arm/boot/dts/microchip/sama5d2.dtsi @@ -571,7 +571,7 @@ AT91_XDMAC_DT_PERID(11))>, AT91_XDMAC_DT_PER_IF(1) | AT91_XDMAC_DT_PERID(12))>; dma-names = "tx", "rx"; - atmel,fifo-size = <16>; + atmel,fifo-size = <32>; status = "disabled"; }; @@ -642,7 +642,7 @@ AT91_XDMAC_DT_PERID(13))>, AT91_XDMAC_DT_PER_IF(1) | AT91_XDMAC_DT_PERID(14))>; dma-names = "tx", "rx"; - atmel,fifo-size = <16>; + atmel,fifo-size = <32>; status = "disabled"; }; @@ -854,7 +854,7 @@ AT91_XDMAC_DT_PERID(15))>, AT91_XDMAC_DT_PER_IF(1) | AT91_XDMAC_DT_PERID(16))>; dma-names = "tx", "rx"; - atmel,fifo-size = <16>; + atmel,fifo-size = <32>; status = "disabled"; }; @@ -925,7 +925,7 @@ AT91_XDMAC_DT_PERID(17))>, AT91_XDMAC_DT_PER_IF(1) | AT91_XDMAC_DT_PERID(18))>; dma-names = "tx", "rx"; - atmel,fifo-size = <16>; + atmel,fifo-size = <32>; status = "disabled"; }; @@ -997,7 +997,7 @@ AT91_XDMAC_DT_PERID(19))>, AT91_XDMAC_DT_PER_IF(1) | AT91_XDMAC_DT_PERID(20))>; dma-names = "tx", "rx"; - atmel,fifo-size = <16>; + atmel,fifo-size = <32>; status = "disabled"; }; -- 2.43.0

4 days, 1 hour

2
1
0 0

Re: Request to backport data corruption fix to stable

by Steve French

Sasha, Also wanted to make sure stable gets this patch from David Howells that fixes a regression that was mentioned in some of the same email threads. It fixes an important stable regression in cifs_readv when cache=none. Bharath has also reviewed and tested it with 6.6 stable. See attached. On Fri, Nov 14, 2025 at 9:00 AM Sasha Levin <sashal(a)kernel.org> wrote: > > On Fri, Nov 14, 2025 at 04:42:57PM +0530, Shyam Prasad N wrote: > >Hi Greg/Sasha, > > > >Over the last few months, a few users have reported a data corruption > >with Linux SMB kernel client filesystem. This is one such report: > >https://lore.kernel.org/linux-cifs/36fb31bf2c854cdc930a3415f5551dcd@izw-ber… > > > >The issue is now well understood. Attached is a fix for this issue. > >I've made sure that the fix is stopping the data corruption and also > >not regressing other write patterns. > > > >The regression seems to have been introduced during a refactoring of > >this code path during the v6.3 and continued to exist till v6.9, > >before the code was refactored again with netfs helper library > >integration in v6.10. > > > >I request you to include this change in all stable trees for > >v6.3..v6.9. I've done my testing on stable-6.6. Please let me know if > >you want this tested on any other kernels. > > I'll queue it up for 6.6, thanks! > > -- > Thanks, > Sasha -- Thanks, Steve

4 days, 1 hour

2
1
0 0

[PATCH] Bluetooth: btusb: Add one more ID 0x13d3:0x3612 for Realtek 8852CE

by Levi Zim via B4 Relay

From: Levi Zim <rsworktech(a)outlook.com> Devices with ID 13d3:3612 are found in ASUS TUF Gaming A16 (2025) and ASUS TX Gaming FA608FM. The corresponding device info from /sys/kernel/debug/usb/devices is T: Bus=03 Lev=02 Prnt=03 Port=02 Cnt=02 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3612 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Levi Zim <rsworktech(a)outlook.com> --- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 8085fabadde8ff01171783b59226589757bbbbbc..d1e62b3158166a33153a6dfaade03fd3fb7d8231 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -552,6 +552,8 @@ static const struct usb_device_id quirks_table[] = { BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x13d3, 0x3592), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x13d3, 0x3612), .driver_info = BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x0489, 0xe122), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, --- base-commit: 302a1f674c00dd5581ab8e493ef44767c5101aab change-id: 20250927-ble-13d3-3612-53a2246e4862 Best regards, -- Levi Zim <rsworktech(a)outlook.com>

4 days, 1 hour

4
3
0 0

Re: Compile Error fs/nfsd/nfs4state.o - clamp() low limit slotsize greater than high limit total_avail/scale_factor

by Mike-SPC via Bugspray Bot

Mike-SPC writes via Kernel.org Bugzilla: Hi there, at first: Thanks for patching and investigation. I've tested the patch mentioned in https://lkml.org/lkml/2025/11/10/12 and it works (for me). Thanks again and regards, Michael View: https://bugzilla.kernel.org/show_bug.cgi?id=220745#c17 You can reply to this message to join the discussion. -- Deet-doot-dot, I am a bot. Kernel.org Bugzilla (bugspray 0.1-dev)

4 days, 4 hours

1
0
0 0

Get the Fruit Attraction 2025 Attendee List!

by Karlee Howell

Hi, We’re offering exclusive access to the Fruit Attraction 2025 Visitor Contact List — your direct connection to verified buyers, importers, exporters, and industry leaders from the global fresh produce, logistics, and agri-innovation market. We have 97,137 verified visitor contacts in our database. You’ll receive full contact data: Individual Email Address, Phone Number, Contact Name, Job Title, Company Name, Website, Physical Address, LinkedIn Profile, and more. All data is fully 100% GDPR-compliant and ethically sourced 20% Off—Respond Before Nov 20. Let me know if you are Interested to see the pricing? Reply “Send me Pricing.” Best regards, Karlee Howell Sr. Marketing Manager Prefer not to receive these emails? Just reply “NOT INTERESTED”.

4 days, 4 hours

1
0
0 0

[REGRESSION 6.12.y] hyper-v: BUG: kernel NULL pointer dereference, address: 00000000000000a0: RIP: 0010:hv_uio_channel_cb+0xd/0x20 [uio_hv_generic]

by Salvatore Bonaccorso

Peter Morrow reported in Debian a regression, reported in https://bugs.debian.org/1120602 . The regression was seen after updating, to 6.12.57-1 in Debian, but details on the offending commit follows. His report was as follows: > Dear Maintainer, > > I'm seeing a kernel crash quite soon after boot on a debian trixie based > system running 6.12.57+deb13-amd64, unfortunately the kernel panics before > I can access the system to gather more information. Thus I'll provide details > of the system using a previously known good version. The panic is happening > 100% of the time unfortunately. I have access to the serial console however > so can enable any required verbose logging during boot if necessary. > > Crucially the crash is not seen with kernel version 6.12.41+deb13-amd64 with the > same userspace. We had pinned to that version until very recently to in order > to work around https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109676 > > I'm running a dpdk application here (VPP) on Azure, VM form factor is a > "Standard DS3 v2 (4 vcpus, 14 GiB memory)". > > The only relevant upstream commit in this area (as far as I can see) is: > > https://lore.kernel.org/linux-hyperv/1bb599ee-fe28-409d-b430-2fc086268936@l… > > The comment regarding avoiding races at start adds a bit more weight behind this > hunch, though it's only a hunch as I am most definitely nowhere near an expert > in this area. > > -- Package-specific info: > > [ 19.625535] BUG: kernel NULL pointer dereference, address: 00000000000000a0 > [ 19.628874] #PF: supervisor read access in kernel mode > [ 19.630841] #PF: error_code(0x0000) - not-present page > [ 19.632788] PGD 0 P4D 0 > [ 19.633905] Oops: Oops: 0000 [#1] PREEMPT SMP PTI > [ 19.635586] CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.12.57+deb13-amd64 #1 Debian 6.12.57-1 > [ 19.640216] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 > [ 19.644514] RIP: 0010:hv_uio_channel_cb+0xd/0x20 [uio_hv_generic] > [ 19.646994] Code: 02 00 00 5b 5d e9 53 98 69 e9 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 8b 47 10 <48> 8b b8 a0 00 00 00 f0 83 44 24 fc 00 e9 51 6f fa ff 90 90 90 90 > [ 19.654377] RSP: 0018:ffffb15ac01a4fa8 EFLAGS: 00010046 > [ 19.656385] RAX: 0000000000000000 RBX: 0000000000000015 RCX: 0000000000000015 > [ 19.659240] RDX: 0000000000000001 RSI: ffffffffffffffff RDI: ffff8ff69c759400 > [ 19.662168] RBP: ffff8ff548790200 R08: ffff8ff548790200 R09: 00fca75150b080e9 > [ 19.665239] R10: 0000000000000000 R11: ffffb15ac01a4ff8 R12: ffff8ff871dc1480 > [ 19.668193] R13: ffff8ff69c759400 R14: ffff8ff69c7596a0 R15: ffffffffc106e160 > [ 19.671106] FS: 0000000000000000(0000) GS:ffff8ff871d80000(0000) knlGS:0000000000000000 > [ 19.674281] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 19.676533] CR2: 00000000000000a0 CR3: 0000000100ba6003 CR4: 00000000003706f0 > [ 19.679385] Call Trace: > [ 19.680361] <IRQ> > [ 19.681181] vmbus_isr+0x1a5/0x210 [hv_vmbus] > [ 19.682916] __sysvec_hyperv_callback+0x32/0x60 > [ 19.684991] sysvec_hyperv_callback+0x6c/0x90 > [ 19.686665] </IRQ> > [ 19.687509] <TASK> > [ 19.688366] asm_sysvec_hyperv_callback+0x1a/0x20 > [ 19.690262] RIP: 0010:pv_native_safe_halt+0xf/0x20 > [ 19.692067] Code: 09 e9 c5 08 01 00 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d e5 3b 31 00 fb f4 <c3> cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 > [ 19.699119] RSP: 0018:ffffb15ac0103ed8 EFLAGS: 00000246 > [ 19.701412] RAX: 0000000000000003 RBX: ffff8ff5403b1fc0 RCX: ffff8ff54c64ce30 > [ 19.704328] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 000000000001f894 > [ 19.706910] RBP: 0000000000000003 R08: 000000000bb760d9 R09: 00fca75150b080e9 > [ 19.709762] R10: 0000000000000003 R11: 0000000000000001 R12: 0000000000000000 > [ 19.712510] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > [ 19.715173] default_idle+0x9/0x20 > [ 19.716846] default_idle_call+0x29/0x100 > [ 19.718623] do_idle+0x1fe/0x240 > [ 19.720045] cpu_startup_entry+0x29/0x30 > [ 19.721595] start_secondary+0x11e/0x140 > [ 19.723080] common_startup_64+0x13e/0x141 > [ 19.725222] </TASK> > [ 19.726387] Modules linked in: isofs cdrom uio_hv_generic uio binfmt_misc intel_rapl_msr intel_rapl_common intel_uncore_frequency_common isst_if_mbox_msr isst_if_common rpcrdma skx_edac_common nfit sunrpc libnvdimm crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 sha256_ssse3 rdma_ucm ib_iser sha1_ssse3 rdma_cm aesni_intel iw_cm gf128mul crypto_simd libiscsi cryptd ib_umad ib_ipoib scsi_transport_iscsi ib_cm rapl sg hv_utils hv_balloon evdev pcspkr joydev mpls_router ip_tunnel ramoops configfs pstore_blk efi_pstore pstore_zone nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs ip_tables x_tables autofs4 overlay squashfs dm_verity dm_bufio reed_solomon dm_mod loop ext4 crc16 mbcache jbd2 crc32c_generic mlx5_ib ib_uverbs ib_core mlx5_core mlxfw pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper sd_mod drm_kms_helper hv_storvsc scsi_transport_fc drm scsi_mod hid_generic hid_hyperv hid serio_raw hv_netvsc hyperv_keyboard scsi_common hv_vmbus > [ 19.726466] crc32_pclmul crc32c_intel > [ 19.765771] CR2: 00000000000000a0 > [ 19.767524] ---[ end trace 0000000000000000 ]--- > [ 19.800433] RIP: 0010:hv_uio_channel_cb+0xd/0x20 [uio_hv_generic] > [ 19.803170] Code: 02 00 00 5b 5d e9 53 98 69 e9 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 8b 47 10 <48> 8b b8 a0 00 00 00 f0 83 44 24 fc 00 e9 51 6f fa ff 90 90 90 90 > [ 19.811041] RSP: 0018:ffffb15ac01a4fa8 EFLAGS: 00010046 > [ 19.813466] RAX: 0000000000000000 RBX: 0000000000000015 RCX: 0000000000000015 > [ 19.816504] RDX: 0000000000000001 RSI: ffffffffffffffff RDI: ffff8ff69c759400 > [ 19.819484] RBP: ffff8ff548790200 R08: ffff8ff548790200 R09: 00fca75150b080e9 > [ 19.822625] R10: 0000000000000000 R11: ffffb15ac01a4ff8 R12: ffff8ff871dc1480 > [ 19.825569] R13: ffff8ff69c759400 R14: ffff8ff69c7596a0 R15: ffffffffc106e160 > [ 19.828804] FS: 0000000000000000(0000) GS:ffff8ff871d80000(0000) knlGS:0000000000000000 > [ 19.832214] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 19.834709] CR2: 00000000000000a0 CR3: 0000000100ba6003 CR4: 00000000003706f0 > [ 19.837976] Kernel panic - not syncing: Fatal exception in interrupt > [ 19.841825] Kernel Offset: 0x28a00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) > [ 19.896620] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- > > > lspci output: > > Collected from a system that is not crashing (6.12.41+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.41-1 (2025-08-12) x86_64 GNU/Linux)... > > $ sudo lspci -v > 2f22:00:02.0 Ethernet controller: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] (rev 80) > Subsystem: Mellanox Technologies Device 0190 > Physical Slot: 3 > Flags: bus master, fast devsel, latency 0, NUMA node 0 > Memory at fe0100000 (64-bit, prefetchable) [size=1M] > Capabilities: [60] Express Endpoint, IntMsgNum 0 > Capabilities: [9c] MSI-X: Enable+ Count=8 Masked- > Kernel driver in use: mlx5_core > Kernel modules: mlx5_core > > 52f7:00:02.0 Ethernet controller: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] (rev 80) > Subsystem: Mellanox Technologies Device 0190 > Physical Slot: 2 > Flags: bus master, fast devsel, latency 0, NUMA node 0 > Memory at fe0000000 (64-bit, prefetchable) [size=1M] > Capabilities: [60] Express Endpoint, IntMsgNum 0 > Capabilities: [9c] MSI-X: Enable+ Count=8 Masked- > Kernel driver in use: mlx5_core > Kernel modules: mlx5_core > > 7852:00:02.0 Ethernet controller: Mellanox Technologies MT27710 Family [ConnectX-4 Lx Virtual Function] (rev 80) > Subsystem: Mellanox Technologies Device 0190 > Physical Slot: 4 > Flags: bus master, fast devsel, latency 0, NUMA node 0 > Memory at fe0200000 (64-bit, prefetchable) [size=1M] > Capabilities: [60] Express Endpoint, IntMsgNum 0 > Capabilities: [9c] MSI-X: Enable+ Count=8 Masked- > Kernel driver in use: mlx5_core > Kernel modules: mlx5_core > > dmidecode output: > > $ sudo dmidecode > # dmidecode 3.6 > Getting SMBIOS data from sysfs. > SMBIOS 3.1.0 present. > Table at 0x3FF82000. > > Handle 0x0000, DMI type 0, 26 bytes > BIOS Information > Vendor: Microsoft Corporation > Version: Hyper-V UEFI Release v4.1 > Release Date: 05/13/2024 > ROM Size: 64 kB > Characteristics: > BIOS characteristics not supported > ACPI is supported > Targeted content distribution is supported > UEFI is supported > System is a virtual machine > BIOS Revision: 4.1 > > Handle 0x0001, DMI type 1, 27 bytes > System Information > Manufacturer: Microsoft Corporation > Product Name: Virtual Machine > Version: Hyper-V UEFI Release v4.1 > Serial Number: 0000-0010-5437-9499-5225-4477-46 > UUID: 925315af-4af4-4d42-915a-1516b5a1fe5c > Wake-up Type: Power Switch > SKU Number: None > Family: Virtual Machine > > Handle 0x0002, DMI type 3, 24 bytes > Chassis Information > Manufacturer: Microsoft Corporation > Type: Desktop > Lock: Not Present > Version: Hyper-V UEFI Release v4.1 > Serial Number: 2466-9316-1078-9783-6078-7718-80 > Asset Tag: 7783-7084-3265-9085-8269-3286-77 > Boot-up State: Safe > Power Supply State: Safe > Thermal State: Safe > Security Status: Unknown > OEM Information: 0x00000000 > Height: Unspecified > Number Of Power Cords: Unspecified > Contained Elements: 0 > SKU Number: Virtual Machine > > Handle 0x0003, DMI type 2, 17 bytes > Base Board Information > Manufacturer: Microsoft Corporation > Product Name: Virtual Machine > Version: Hyper-V UEFI Release v4.1 > Serial Number: 0000-0010-4737-0707-0684-2660-76 > Asset Tag: None > Features: > Board is a hosting board > Location In Chassis: Virtual Machine > Chassis Handle: 0x0002 > Type: Motherboard > Contained Object Handles: 0 > > Handle 0x0004, DMI type 4, 48 bytes > Processor Information > Socket Designation: None > Type: Central Processor > Family: Unknown > Manufacturer: None > ID: 00 00 00 00 00 00 00 00 > Version: None > Voltage: Unknown > External Clock: Unknown > Max Speed: Unknown > Current Speed: Unknown > Status: Unpopulated > Upgrade: Other > L1 Cache Handle: Not Provided > L2 Cache Handle: Not Provided > L3 Cache Handle: Not Provided > Serial Number: None > Asset Tag: None > Part Number: None > Core Count: 4 > Core Enabled: 4 > Thread Count: 1 > Characteristics: None > > Handle 0x0005, DMI type 11, 5 bytes > OEM Strings > String 1: [MS_VM_CERT/SHA1/9b80ca0d5dd061ec9da4e494f4c3fd1196270c22] > String 2: None > String 3: To be filled by OEM > > Handle 0x0006, DMI type 16, 23 bytes > Physical Memory Array > Location: System Board Or Motherboard > Use: System Memory > Error Correction Type: None > Maximum Capacity: 0 bytes > Error Information Handle: Not Provided > Number Of Devices: 3 > > Handle 0x0007, DMI type 17, 92 bytes > Memory Device > Array Handle: 0x0006 > Error Information Handle: Not Provided > Total Width: Unknown > Data Width: Unknown > Size: 26 MB > Form Factor: Unknown > Set: None > Locator: M0001 > Bank Locator: None > Type: Unknown > Type Detail: Unknown > Speed: Unknown > Manufacturer: Microsoft Corporation > Serial Number: None > Asset Tag: None > Part Number: None > Rank: Unknown > Configured Memory Speed: Unknown > Minimum Voltage: Unknown > Maximum Voltage: Unknown > Configured Voltage: Unknown > Memory Technology: <OUT OF SPEC> > Memory Operating Mode Capability: None > Firmware Version: Not Specified > Module Manufacturer ID: Unknown > Module Product ID: Unknown > Memory Subsystem Controller Manufacturer ID: Unknown > Memory Subsystem Controller Product ID: Unknown > Non-Volatile Size: None > Volatile Size: None > Cache Size: None > Logical Size: None > > Handle 0x0008, DMI type 19, 31 bytes > Memory Array Mapped Address > Starting Address: 0x00000000000 > Ending Address: 0x00001A003FF > Range Size: 26625 kB > Physical Array Handle: 0x0006 > Partition Width: 0 > > Handle 0x0009, DMI type 20, 35 bytes > Memory Device Mapped Address > Starting Address: 0x00000000000 > Ending Address: 0x00001A003FF > Range Size: 26625 kB > Physical Device Handle: 0x0007 > Memory Array Mapped Address Handle: 0x0008 > Partition Row Position: Unknown > > Handle 0x000A, DMI type 17, 92 bytes > Memory Device > Array Handle: 0x0006 > Error Information Handle: Not Provided > Total Width: Unknown > Data Width: Unknown > Size: 948 MB > Form Factor: Unknown > Set: None > Locator: M0002 > Bank Locator: None > Type: Unknown > Type Detail: Unknown > Speed: Unknown > Manufacturer: Microsoft Corporation > Serial Number: None > Asset Tag: None > Part Number: None > Rank: Unknown > Configured Memory Speed: Unknown > Minimum Voltage: Unknown > Maximum Voltage: Unknown > Configured Voltage: Unknown > Memory Technology: <OUT OF SPEC> > Memory Operating Mode Capability: None > Firmware Version: Not Specified > Module Manufacturer ID: Unknown > Module Product ID: Unknown > Memory Subsystem Controller Manufacturer ID: Unknown > Memory Subsystem Controller Product ID: Unknown > Non-Volatile Size: None > Volatile Size: None > Cache Size: None > Logical Size: None > > Handle 0x000B, DMI type 19, 31 bytes > Memory Array Mapped Address > Starting Address: 0x00004C00000 > Ending Address: 0x000400003FF > Range Size: 970753 kB > Physical Array Handle: 0x0006 > Partition Width: 0 > > Handle 0x000C, DMI type 20, 35 bytes > Memory Device Mapped Address > Starting Address: 0x00004C00000 > Ending Address: 0x000400003FF > Range Size: 970753 kB > Physical Device Handle: 0x000A > Memory Array Mapped Address Handle: 0x000B > Partition Row Position: Unknown > > Handle 0x000D, DMI type 17, 92 bytes > Memory Device > Array Handle: 0x0006 > Error Information Handle: Not Provided > Total Width: Unknown > Data Width: Unknown > Size: 13 GB > Form Factor: Unknown > Set: None > Locator: M0003 > Bank Locator: None > Type: Unknown > Type Detail: Unknown > Speed: Unknown > Manufacturer: Microsoft Corporation > Serial Number: None > Asset Tag: None > Part Number: None > Rank: Unknown > Configured Memory Speed: Unknown > Minimum Voltage: Unknown > Maximum Voltage: Unknown > Configured Voltage: Unknown > Memory Technology: <OUT OF SPEC> > Memory Operating Mode Capability: None > Firmware Version: Not Specified > Module Manufacturer ID: Unknown > Module Product ID: Unknown > Memory Subsystem Controller Manufacturer ID: Unknown > Memory Subsystem Controller Product ID: Unknown > Non-Volatile Size: None > Volatile Size: None > Cache Size: None > Logical Size: None > > Handle 0x000E, DMI type 19, 31 bytes > Memory Array Mapped Address > Starting Address: 0x00100000000 > Ending Address: 0x004400003FF > Range Size: 13 GB > Physical Array Handle: 0x0006 > Partition Width: 0 > > Handle 0x000F, DMI type 20, 35 bytes > Memory Device Mapped Address > Starting Address: 0x00100000000 > Ending Address: 0x004400003FF > Range Size: 13 GB > Physical Device Handle: 0x000D > Memory Array Mapped Address Handle: 0x000E > Partition Row Position: Unknown > > Handle 0x0010, DMI type 32, 11 bytes > System Boot Information > Status: No errors detected > > Handle 0xFEFF, DMI type 127, 4 bytes > End Of Table The offending commit appers to be the backport of b15b7d2a1b09 ("uio_hv_generic: Let userspace take care of interrupt mask") for 6.12.y. Peter confirmed that reverting this commit on top of 6.12.57-1 as packaged in Debian resolves indeed the issue. Interestingly the issue is *not* seen with 6.17.7 based kernel in Debian. #regzbot introduced: 37bd91f22794dc05436130d6983302cb90ecfe7e #regzbot monitor: https://bugs.debian.org/1120602 Thank you already! Regards, Salvatore

4 days, 6 hours

3
5
0 0

[PATCH 6.6 and older] uio_hv_generic: Enable user space to manage interrupt_mask for subchannels

by Naman Jain

From: Long Li <longli(a)microsoft.com> Enable the user space to manage interrupt_mask for subchannels through irqcontrol interface for uio device. Also remove the memory barrier when monitor bit is enabled as it is not necessary. This is a backport of the upstream commit d062463edf17 ("uio_hv_generic: Set event for all channels on the device") with some modifications to resolve merge conflicts and take care of missing support for slow devices on older kernels. Original change was not a fix, but it needs to be backported to fix a NULL pointer crash resulting from missing interrupt mask setting. Commit 37bd91f22794 ("uio_hv_generic: Let userspace take care of interrupt mask") removed the default setting of interrupt_mask for channels (including subchannels) in the uio_hv_generic driver, as it relies on the user space to take care of managing it. This approach works fine when user space can control this setting using the irqcontrol interface provided for uio devices. Support for setting the interrupt mask through this interface for subchannels came only after commit d062463edf17 ("uio_hv_generic: Set event for all channels on the device"). On older kernels, this change is not present. With uio_hv_generic no longer setting the interrupt_mask, and userspace not having the capability to set it, it remains unset, and interrupts can come for the subchannels, which can result in a crash in hv_uio_channel_cb. Backport the change to older kernels, where this change was not present, to allow userspace to set the interrupt mask properly for subchannels. Additionally, this patch also adds certain checks for primary vs subchannels in the hv_uio_channel_cb, which can gracefully handle these two cases and prevent the NULL pointer crashes. Signed-off-by: Long Li <longli(a)microsoft.com> Fixes: 37bd91f22794 ("uio_hv_generic: Let userspace take care of interrupt mask") Closes: https://bugs.debian.org/1120602 Cc: <stable(a)vger.kernel.org> # 6.6.x and older Signed-off-by: Naman Jain <namjain(a)linux.microsoft.com> --- Remove reviewed-by tags since the original code has changed quite a bit while backporting. Backported change for 6.12 kernel is sent separately. --- drivers/uio/uio_hv_generic.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c index 2724656bf634..69e5016ebd46 100644 --- a/drivers/uio/uio_hv_generic.c +++ b/drivers/uio/uio_hv_generic.c @@ -80,9 +80,15 @@ hv_uio_irqcontrol(struct uio_info *info, s32 irq_state) { struct hv_uio_private_data *pdata = info->priv; struct hv_device *dev = pdata->device; + struct vmbus_channel *primary, *sc; - dev->channel->inbound.ring_buffer->interrupt_mask = !irq_state; - virt_mb(); + primary = dev->channel; + primary->inbound.ring_buffer->interrupt_mask = !irq_state; + + mutex_lock(&vmbus_connection.channel_mutex); + list_for_each_entry(sc, &primary->sc_list, sc_list) + sc->inbound.ring_buffer->interrupt_mask = !irq_state; + mutex_unlock(&vmbus_connection.channel_mutex); return 0; } @@ -93,11 +99,18 @@ hv_uio_irqcontrol(struct uio_info *info, s32 irq_state) static void hv_uio_channel_cb(void *context) { struct vmbus_channel *chan = context; - struct hv_device *hv_dev = chan->device_obj; - struct hv_uio_private_data *pdata = hv_get_drvdata(hv_dev); + struct hv_device *hv_dev; + struct hv_uio_private_data *pdata; virt_mb(); + /* + * The callback may come from a subchannel, in which case look + * for the hv device in the primary channel + */ + hv_dev = chan->primary_channel ? + chan->primary_channel->device_obj : chan->device_obj; + pdata = hv_get_drvdata(hv_dev); uio_event_notify(&pdata->info); } -- 2.34.1

4 days, 6 hours

1
0
0 0

[PATCH v1 v6.12.y] nfsd: Replace clamp_t in nfsd4_get_drc_mem()

by Chuck Lever

From: NeilBrown <neil(a)brown.name> A recent change to clamp_t() in 6.1.y caused fs/nfsd/nfs4state.c to fail to compile with gcc-9. The code in nfsd4_get_drc_mem() was written with the assumption that when "max < min", clamp(val, min, max) would return max. This assumption is not documented as an API promise and the change caused a compile failure if it could be statically determined that "max < min". The relevant code was no longer present upstream when commit 1519fbc8832b ("minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()") landed there, so there is no upstream change to nfsd4_get_drc_mem() to backport. There is no clear case that the existing code in nfsd4_get_drc_mem() is functioning incorrectly. The goal of this patch is to permit the clean application of commit 1519fbc8832b ("minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()"), and any commits that depend on it, to LTS kernels without affecting the ability to compile those kernels. This is done by open-coding the __clamp() macro sans the built-in type checking. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220745#c0 Signed-off-by: NeilBrown <neil(a)brown.name> Stable-dep-of: 1519fbc8832b ("minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()") Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> --- fs/nfsd/nfs4state.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) Changes since Neil's post: * Editorial changes to the commit message * Attempt to address David's review comments * Applied to linux-6.12.y, passed NFSD upstream CI suite This patch is intended to be applied to linux-6.12.y, and should apply cleanly to other LTS kernels since nfsd4_get_drc_mem hasn't changed since v5.4. diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index 7b0fabf8c657..41545933dd18 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -1983,8 +1983,10 @@ static u32 nfsd4_get_drc_mem(struct nfsd4_channel_attrs *ca, struct nfsd_net *nn */ scale_factor = max_t(unsigned int, 8, nn->nfsd_serv->sv_nrthreads); - avail = clamp_t(unsigned long, avail, slotsize, - total_avail/scale_factor); + if (avail > total_avail / scale_factor) + avail = total_avail / scale_factor; + else if (avail < slotsize) + avail = slotsize; num = min_t(int, num, avail / slotsize); num = max_t(int, num, 1); nfsd_drc_mem_used += num * slotsize; -- 2.51.0

4 days, 16 hours

2
1
0 0

Sports bags, backpacks, sportswear

by HILL APEX

Hi linux-stable-mirror(a)lists.linaro.org We make sublimated sports bags, backpacks, and sportswear. To get delivery prices, please: 1. Visit hillapex.com and pick an item. 2. Let us know your order quantity. 3. Provide your country name. Best regards, Saad Afzal Founder | Hill Apex 📧 Email: saad(a)hillapex.com 🌐 Website: hillapex.com 📞 Phone/WhatsApp: +92 300 7101027 📍 Address: Chenab Ranger’s Road, 51310 Sialkot, Pakistan

4 days, 18 hours

1
0
0 0

[tip: x86/boot] x86/acpi/boot: Correct acpi_is_processor_usable() check again

by tip-bot2 for Yazen Ghannam

The following commit has been merged into the x86/boot branch of tip: Commit-ID: 1c7ac68c05bc0327d725dd10aa05f5120f868250 Gitweb: https://git.kernel.org/tip/1c7ac68c05bc0327d725dd10aa05f5120f868250 Author: Yazen Ghannam <yazen.ghannam(a)amd.com> AuthorDate: Tue, 11 Nov 2025 14:53:57 Committer: Borislav Petkov (AMD) <bp(a)alien8.de> CommitterDate: Fri, 14 Nov 2025 21:00:26 +01:00 x86/acpi/boot: Correct acpi_is_processor_usable() check again ACPI v6.3 defined a new "Online Capable" MADT LAPIC flag. This bit is used in conjunction with the "Enabled" MADT LAPIC flag to determine if a CPU can be enabled/hotplugged by the OS after boot. Before the new bit was defined, the "Enabled" bit was explicitly described like this (ACPI v6.0 wording provided): "If zero, this processor is unusable, and the operating system support will not attempt to use it" This means that CPU hotplug (based on MADT) is not possible. Many BIOS implementations follow this guidance. They may include LAPIC entries in MADT for unavailable CPUs, but since these entries are marked with "Enabled=0" it is expected that the OS will completely ignore these entries. However, QEMU will do the same (include entries with "Enabled=0") for the purpose of allowing CPU hotplug within the guest. Comment from QEMU function pc_madt_cpu_entry(): /* ACPI spec says that LAPIC entry for non present * CPU may be omitted from MADT or it must be marked * as disabled. However omitting non present CPU from * MADT breaks hotplug on linux. So possible CPUs * should be put in MADT but kept disabled. */ Recent Linux topology changes broke the QEMU use case. A following fix for the QEMU use case broke bare metal topology enumeration. Rework the Linux MADT LAPIC flags check to allow the QEMU use case only for guests and to maintain the ACPI spec behavior for bare metal. Remove an unnecessary check added to fix a bare metal case introduced by the QEMU "fix". [ bp: Change logic as Michal suggested. ] Fixes: fed8d8773b8e ("x86/acpi/boot: Correct acpi_is_processor_usable() check") Fixes: f0551af02130 ("x86/topology: Ignore non-present APIC IDs in a present package") Closes: https://lore.kernel.org/r/20251024204658.3da9bf3f.michal.pecio@gmail.com Reported-by: Michal Pecio <michal.pecio(a)gmail.com> Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Tested-by: Michal Pecio <michal.pecio(a)gmail.com> Tested-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/20251111145357.4031846-1-yazen.ghannam@amd.com --- arch/x86/kernel/acpi/boot.c | 12 ++++++++---- arch/x86/kernel/cpu/topology.c | 15 --------------- 2 files changed, 8 insertions(+), 19 deletions(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 9fa321a..d6138b2 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -35,6 +35,7 @@ #include <asm/smp.h> #include <asm/i8259.h> #include <asm/setup.h> +#include <asm/hypervisor.h> #include "sleep.h" /* To include x86_acpi_suspend_lowlevel */ static int __initdata acpi_force = 0; @@ -164,11 +165,14 @@ static bool __init acpi_is_processor_usable(u32 lapic_flags) if (lapic_flags & ACPI_MADT_ENABLED) return true; - if (!acpi_support_online_capable || - (lapic_flags & ACPI_MADT_ONLINE_CAPABLE)) - return true; + if (acpi_support_online_capable) + return lapic_flags & ACPI_MADT_ONLINE_CAPABLE; - return false; + /* + * QEMU expects legacy "Enabled=0" LAPIC entries to be counted as usable + * in order to support CPU hotplug in guests. + */ + return !hypervisor_is_type(X86_HYPER_NATIVE); } static int __init diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c index 6073a16..425404e 100644 --- a/arch/x86/kernel/cpu/topology.c +++ b/arch/x86/kernel/cpu/topology.c @@ -27,7 +27,6 @@ #include <xen/xen.h> #include <asm/apic.h> -#include <asm/hypervisor.h> #include <asm/io_apic.h> #include <asm/mpspec.h> #include <asm/msr.h> @@ -240,20 +239,6 @@ static __init void topo_register_apic(u32 apic_id, u32 acpi_id, bool present) cpuid_to_apicid[cpu] = apic_id; topo_set_cpuids(cpu, apic_id, acpi_id); } else { - u32 pkgid = topo_apicid(apic_id, TOPO_PKG_DOMAIN); - - /* - * Check for present APICs in the same package when running - * on bare metal. Allow the bogosity in a guest. - */ - if (hypervisor_is_type(X86_HYPER_NATIVE) && - topo_unit_count(pkgid, TOPO_PKG_DOMAIN, phys_cpu_present_map)) { - pr_info_once("Ignoring hot-pluggable APIC ID %x in present package.\n", - apic_id); - topo_info.nr_rejected_cpus++; - return; - } - topo_info.nr_disabled_cpus++; }

4 days, 18 hours

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror