Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #93158 > unrolled thread

Bug#1141185: linux-image-6.12.94+deb13-amd64: Occasional read problems in RAID/LVM/ext4 stack when under stress.

Started byCharles Curley <charlescurley@charlescurley.com>
First post2026-06-30 22:50 +0200
Last post2026-07-26 14:30 +0200
Articles 7 — 4 participants

Back to article view | Back to linux.debian.kernel


Contents

  Bug#1141185: linux-image-6.12.94+deb13-amd64: Occasional read problems in RAID/LVM/ext4 stack when under stress. Charles Curley <charlescurley@charlescurley.com> - 2026-06-30 22:50 +0200
    Bug#1141185: linux-image-6.12.94+deb13-amd64: Occasional read problems in RAID/LVM/ext4 stack when under stress. Tj <tj.iam.tj@proton.me> - 2026-07-01 13:30 +0200
    Bug#1141185: linux-image-6.12.94+deb13-amd64: Occasional read problems in RAID/LVM/ext4 stack when under stress. Uwe Kleine-König <ukleinek@debian.org> - 2026-07-06 17:50 +0200
      Bug#1141185: linux-image-6.12.94+deb13-amd64: Occasional read problems in RAID/LVM/ext4 stack when under stress. Charles Curley <charlescurley@charlescurley.com> - 2026-07-07 00:00 +0200
        Bug#1141185: linux-image-6.12.94+deb13-amd64: Occasional read  problems in RAID/LVM/ext4 stack when under stress. Charles Curley <charlescurley@charlescurley.com> - 2026-07-09 22:00 +0200
    Bug#1141185: Status, probable solution. Charles Curley <charlescurley@charlescurley.com> - 2026-07-23 01:30 +0200
    Bug#1141185: marked as done (linux-image-6.12.94+deb13-amd64:  Occasional read problems in RAID/LVM/ext4 stack when under stress.) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-07-26 14:30 +0200

#93158 — Bug#1141185: linux-image-6.12.94+deb13-amd64: Occasional read problems in RAID/LVM/ext4 stack when under stress.

FromCharles Curley <charlescurley@charlescurley.com>
Date2026-06-30 22:50 +0200
SubjectBug#1141185: linux-image-6.12.94+deb13-amd64: Occasional read problems in RAID/LVM/ext4 stack when under stress.
Message-ID<NbNz3-1Xeo-5@gated-at.bofh.it>
Package: src:linux
Version: 6.12.94-1
Severity: normal
X-Debbugs-Cc: charlescurley@charlescurley.com

Dear Maintainer,
I have four four terabyte hard drives. Each has one partition on it. The four partitions comprise a RAID 5 array using mdadm. On top of that, LUKS encryption, then LVM with ext4 logical volumes.

On one LVM partition I have a number of backup files, tarred, bzipped, and sha256 and sha512 summed. I have a script which will find checksum files, and execute the appropriate program to test the archives. It puts each program into the background, parallising any number of checksum tests.

Starting early in May, the script found an error in one or more files out of several. Results are inconsistent: one pass may find an error in a given file, the next pass not find any errors in it. Running checksums manually, one at a time, does not turn up an error. Running "tar tvf" finds no error in a suspect tarball. Running "bunzip2 -t" also turns up no error. Only running the script turns up any errors.

I create two checksum files when I create the backups, for sha256 and sha512. After this problem surfaced, I then made two new checksum files of a suspect file. The two checksum file pairs (e.g. both sha512sum files) show the same checksums. The script now tests using both the old and new checksum files. Sometime only one pair of checksum files fail the suspect file.

In addition to all of that, I also get the occasional "bad message" error. I have no idea what that means, but an fsck seems to deal with it.

To be thorough, I have run extended SMART tests on the hard drives, kicked mdadm into testing the RAID array, and fscked the LVM partitions on the RAID array. Only fsck turned up issues, and that has not stopped. SMART showed problems with one hard drive. I replaced the drive. That did not solve this problem. However, while the drive was "failed" and before the replacement installed, the error count went down noticeably.

I also back some of this up to offsite USB drives. I ran the script on one of those, using this computer, and a different computer. No errors reported.

I believe a successful work-around is to install the backports kernel, linux-image-7.0.10+deb13-amd64 et seq. This problem went away, although another similar problem has occurred with that kernel.

There is extensive discussion of this problem on the Debian user list, under the subject "Schrödinger's hash", starting at https://lists.debian.org/debian-user/2026/05/msg00377.html


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: ASUS
product_name: All Series
product_version: System Version
chassis_vendor: To Be Filled By O.E.M.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: 2404
board_vendor: ASUSTeK COMPUTER INC.
board_name: H97M-E
board_version: Rev X.0x

** Configuration for modprobe:
blacklist arkfb
blacklist aty128fb
blacklist atyfb
blacklist radeonfb
blacklist cirrusfb
blacklist cyber2000fb
blacklist kyrofb
blacklist matroxfb_base
blacklist mb862xxfb
blacklist neofb
blacklist pm2fb
blacklist pm3fb
blacklist s3fb
blacklist savagefb
blacklist sisfb
blacklist tdfxfb
blacklist tridentfb
blacklist vt8623fb
blacklist microcode
options snd_pcsp index=-2
options cx88_alsa index=-2
options snd_atiixp_modem index=-2
options snd_intel8x0m index=-2
options snd_via82xx_modem index=-2
options md_mod start_ro=1
options bonding max_bonds=0
options dummy numdummies=0
options ifb numifbs=0

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00] (rev 06)
	Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: <access denied>
	Kernel driver in use: hsw_uncore

00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06) (prog-if 00 [Normal decode])
	Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 24
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: [disabled] [16-bit]
	Memory behind bridge: [disabled] [32-bit]
	Prefetchable memory behind bridge: [disabled] [64-bit]
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport
	Kernel modules: shpchp

00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) (prog-if 00 [VGA controller])
	DeviceName:  Onboard IGD
	Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 32
	Region 0: Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
	Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at f000 [size=64]
	Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: i915
	Kernel modules: i915

00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06) (prog-if 00 [HDA compatible])
	Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 34
	Region 0: Memory at f7e14000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

00:14.0 USB controller [0c03]: Intel Corporation 9 Series Chipset Family USB xHCI Controller [8086:8cb1] (prog-if 30 [XHCI])
	Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 30
	Region 0: Memory at f7e00000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

00:16.0 Communication controller [0780]: Intel Corporation 9 Series Chipset Family ME Interface #1 [8086:8cba]
	Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 33
	Region 0: Memory at f7e1d000 (64-bit, non-prefetchable) [size=16]
	Capabilities: <access denied>
	Kernel driver in use: mei_me
	Kernel modules: mei_me

00:1a.0 USB controller [0c03]: Intel Corporation 9 Series Chipset Family USB EHCI Controller #2 [8086:8cad] (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 20
	Region 0: Memory at f7e1b000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <access denied>
	Kernel driver in use: ehci-pci
	Kernel modules: ehci_pci

00:1b.0 Audio device [0403]: Intel Corporation 9 Series Chipset Family HD Audio Controller [8086:8ca0] (prog-if 00 [HDA compatible])
	Subsystem: ASUSTeK Computer Inc. Device [1043:8616]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 35
	Region 0: Memory at f7e10000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation 9 Series Chipset Family PCI Express Root Port 1 [8086:8c90] (rev d0) (prog-if 00 [Normal decode])
	Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 25
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 2000-2fff [size=4K] [16-bit]
	Memory behind bridge: df200000-df3fffff [size=2M] [32-bit]
	Prefetchable memory behind bridge: df400000-df5fffff [size=2M] [32-bit]
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport
	Kernel modules: shpchp

00:1c.2 PCI bridge [0604]: Intel Corporation 9 Series Chipset Family PCI Express Root Port 3 [8086:8c94] (rev d0) (prog-if 00 [Normal decode])
	Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin C routed to IRQ 26
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: e000-efff [size=4K] [16-bit]
	Memory behind bridge: f7d00000-f7dfffff [size=1M] [32-bit]
	Prefetchable memory behind bridge: f0000000-f00fffff [size=1M] [32-bit]
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport
	Kernel modules: shpchp

00:1c.7 PCI bridge [0604]: Intel Corporation 9 Series Chipset Family PCI Express Root Port 8 [8086:8c9e] (rev d0) (prog-if 00 [Normal decode])
	Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin D routed to IRQ 27
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
	I/O behind bridge: d000-dfff [size=4K] [16-bit]
	Memory behind bridge: f7c00000-f7cfffff [size=1M] [32-bit]
	Prefetchable memory behind bridge: [disabled] [64-bit]
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport
	Kernel modules: shpchp

00:1d.0 USB controller [0c03]: Intel Corporation 9 Series Chipset Family USB EHCI Controller #1 [8086:8ca6] (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at f7e1a000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <access denied>
	Kernel driver in use: ehci-pci
	Kernel modules: ehci_pci

00:1f.0 ISA bridge [0601]: Intel Corporation H97 Chipset LPC Controller [8086:8cc6]
	Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: <access denied>
	Kernel driver in use: lpc_ich
	Kernel modules: lpc_ich

00:1f.2 SATA controller [0106]: Intel Corporation 9 Series Chipset Family SATA Controller [AHCI Mode] [8086:8c82] (prog-if 01 [AHCI 1.0])
	Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 29
	Region 0: I/O ports at f0b0 [size=8]
	Region 1: I/O ports at f0a0 [size=4]
	Region 2: I/O ports at f090 [size=8]
	Region 3: I/O ports at f080 [size=4]
	Region 4: I/O ports at f060 [size=32]
	Region 5: Memory at f7e19000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: <access denied>
	Kernel driver in use: ahci
	Kernel modules: ahci

00:1f.3 SMBus [0c05]: Intel Corporation 9 Series Chipset Family SMBus Controller [8086:8ca2]
	Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin C routed to IRQ 18
	Region 0: Memory at f7e18000 (64-bit, non-prefetchable) [size=256]
	Region 4: I/O ports at f040 [size=32]
	Kernel driver in use: i801_smbus
	Kernel modules: i2c_i801

03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 11)
	Subsystem: ASUSTeK Computer Inc. AM1I-A Motherboard [1043:859e]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: I/O ports at e000 [size=256]
	Region 2: Memory at f7d00000 (64-bit, non-prefetchable) [size=4K]
	Region 4: Memory at f0000000 (64-bit, prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: r8169
	Kernel modules: r8169

04:00.0 SATA controller [0106]: JMicron Technology Corp. JMB58x AHCI SATA controller [197b:0585] (prog-if 01 [AHCI 1.0])
	Subsystem: JMicron Technology Corp. Device [197b:0000]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 31
	Region 0: I/O ports at d200 [size=128]
	Region 1: I/O ports at d180 [size=128]
	Region 2: I/O ports at d100 [size=128]
	Region 3: I/O ports at d080 [size=128]
	Region 4: I/O ports at d000 [size=128]
	Region 5: Memory at f7c10000 (32-bit, non-prefetchable) [size=8K]
	Expansion ROM at f7c00000 [disabled] [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: ahci
	Kernel modules: ahci


** USB devices:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8009 Intel Corp. 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 8087:8001 Intel Corp. Integrated Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
Bus 003 Device 003: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
Bus 003 Device 004: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 003 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 003 Device 006: ID 03f0:0972 HP, Inc HP LaserJet MFP M232-M237
Bus 003 Device 007: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 002: ID 0bc2:ab28 Seagate RSS LLC Seagate Backup Plus Portable 5TB SRD00F1


-- System Information:
Debian Release: 13.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 7.0.12+deb13-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-6.12.94+deb13-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.148.4
ii  kmod                                    34.2-2
ii  linux-base                              4.12.1

Versions of packages linux-image-6.12.94+deb13-amd64 recommends:
ii  apparmor  4.1.0-1

Versions of packages linux-image-6.12.94+deb13-amd64 suggests:
pn  debian-kernel-handbook  <none>
pn  firmware-linux-free     <none>
ii  grub-efi-amd64          2.12-9+deb13u2
pn  linux-doc-6.12          <none>

Versions of packages linux-image-6.12.94+deb13-amd64 is related to:
pn  firmware-amd-graphics      <none>
pn  firmware-atheros           <none>
pn  firmware-bnx2              <none>
pn  firmware-bnx2x             <none>
pn  firmware-brcm80211         <none>
pn  firmware-cavium            <none>
pn  firmware-cirrus            <none>
ii  firmware-intel-graphics    20250410-2
pn  firmware-intel-misc        <none>
pn  firmware-intel-sound       <none>
pn  firmware-ipw2x00           <none>
pn  firmware-ivtv              <none>
pn  firmware-iwlwifi           <none>
pn  firmware-libertas          <none>
pn  firmware-marvell-prestera  <none>
pn  firmware-mediatek          <none>
pn  firmware-misc-nonfree      <none>
pn  firmware-myricom           <none>
pn  firmware-netronome         <none>
pn  firmware-netxen            <none>
pn  firmware-nvidia-graphics   <none>
pn  firmware-qcom-soc          <none>
pn  firmware-qlogic            <none>
ii  firmware-realtek           20250410-2
pn  firmware-samsung           <none>
pn  firmware-siano             <none>
pn  firmware-ti-connectivity   <none>
pn  xen-hypervisor             <none>

-- no debconf information

[toc] | [next] | [standalone]


#93164

FromTj <tj.iam.tj@proton.me>
Date2026-07-01 13:30 +0200
Message-ID<Nc1iF-25bb-1@gated-at.bofh.it>
In reply to#93158
Followup-For: Bug #1141185
X-Debbugs-Cc: tj.iam.tj@proton.me

"It puts each program into the background, parallising any number of
checksum tests"

+

"Running checksums manually, one at a time, does not turn up an error"

This is possibly a classic system of a RAM module with sticky bits. In
addition it suggests the module with the problem is at the higher
physical addresses since the impact is only noticed when the host memory
usage is high (due to parallel tasks).

A long memtest86+ is strongly recommended.

[toc] | [prev] | [next] | [standalone]


#93251

FromUwe Kleine-König <ukleinek@debian.org>
Date2026-07-06 17:50 +0200
Message-ID<NdTK2-3830-3@gated-at.bofh.it>
In reply to#93158

[Multipart message — attachments visible in raw view] — view raw

Hello Charles,

On Tue, Jun 30, 2026 at 02:47:26PM -0600, Charles Curley wrote:
> I have four four terabyte hard drives. Each has one partition on it. The four partitions comprise a RAID 5 array using mdadm. On top of that, LUKS encryption, then LVM with ext4 logical volumes.
> 
> On one LVM partition I have a number of backup files, tarred, bzipped, and sha256 and sha512 summed. I have a script which will find checksum files, and execute the appropriate program to test the archives. It puts each program into the background, parallising any number of checksum tests.
> 
> Starting early in May, the script found an error in one or more files out of several. Results are inconsistent: one pass may find an error in a given file, the next pass not find any errors in it. Running checksums manually, one at a time, does not turn up an error. Running "tar tvf" finds no error in a suspect tarball. Running "bunzip2 -t" also turns up no error. Only running the script turns up any errors.
> 
> I create two checksum files when I create the backups, for sha256 and sha512. After this problem surfaced, I then made two new checksum files of a suspect file. The two checksum file pairs (e.g. both sha512sum files) show the same checksums. The script now tests using both the old and new checksum files. Sometime only one pair of checksum files fail the suspect file.
> 
> In addition to all of that, I also get the occasional "bad message" error. I have no idea what that means, but an fsck seems to deal with it.
> 
> To be thorough, I have run extended SMART tests on the hard drives, kicked mdadm into testing the RAID array, and fscked the LVM partitions on the RAID array. Only fsck turned up issues, and that has not stopped. SMART showed problems with one hard drive. I replaced the drive. That did not solve this problem. However, while the drive was "failed" and before the replacement installed, the error count went down noticeably.
> 
> I also back some of this up to offsite USB drives. I ran the script on one of those, using this computer, and a different computer. No errors reported.
> 
> I believe a successful work-around is to install the backports kernel, linux-image-7.0.10+deb13-amd64 et seq. This problem went away, although another similar problem has occurred with that kernel.
> 
> There is extensive discussion of this problem on the Debian user list, under the subject "Schrödinger's hash", starting at https://lists.debian.org/debian-user/2026/05/msg00377.html

You got a reply to your report, but you might not have noticed it unless
you subscribed to the bug. So in case you missed it: Tj suggested to run
memtest86+ on your system to rule out (or confirm) RAM issues.

You don't happen to have overclocked your system?

Best regards
Uwe

[toc] | [prev] | [next] | [standalone]


#93258

FromCharles Curley <charlescurley@charlescurley.com>
Date2026-07-07 00:00 +0200
Message-ID<NdZw5-3bcd-1@gated-at.bofh.it>
In reply to#93251
On Mon, 6 Jul 2026 17:46:36 +0200
Uwe Kleine-König <ukleinek@debian.org> wrote:

> You got a reply to your report, but you might not have noticed it
> unless you subscribed to the bug.

I don't seem to have it, so thank you for the followup.

> So in case you missed it: Tj
> suggested to run memtest86+ on your system to rule out (or confirm)
> RAM issues.

Already done; no issues found. I also substituted a single stick of RAM
(8 gig) for the two I usually run. That resulted in fewer errors.

Tj said,

> A long memtest86+ is strongly recommended.

Tj, please define long? I seem to recall letting it run for about 6
hours and seeing no errors.

> 
> You don't happen to have overclocked your system?

Nope. Stock, bog-standard except for the addition of one SATA card.

root@hawk:~# lspci -vs 4:0
04:00.0 SATA controller: JMicron Technology Corp. JMB58x AHCI SATA controller (prog-if 01 [AHCI 1.0])
	Subsystem: JMicron Technology Corp. Device 0000
	Flags: bus master, fast devsel, latency 0, IRQ 31
	I/O ports at d200 [size=128]
	I/O ports at d180 [size=128]
	I/O ports at d100 [size=128]
	I/O ports at d080 [size=128]
	I/O ports at d000 [size=128]
	Memory at f7c10000 (32-bit, non-prefetchable) [size=8K]
	Expansion ROM at f7c00000 [disabled] [size=64K]
	Capabilities: [80] Power Management version 3
	Capabilities: [90] MSI: Enable+ Count=1/8 Maskable- 64bit+
	Capabilities: [c0] Express Legacy Endpoint, IntMsgNum 0
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [150] Device Serial Number 00-00-00-00-00-00-00-00
	Capabilities: [160] Power Budgeting <?>
	Capabilities: [1b8] Latency Tolerance Reporting
	Capabilities: [300] Secondary PCI Express
	Capabilities: [900] L1 PM Substates
	Kernel driver in use: ahci
	Kernel modules: ahci

root@hawk:~# 

That suggests a test to try when I get a chance: power down the DVD
drive, move the boot SSD to that card and the one HD currently on that
card to the motherboard. It may be several days before I get to it,
though.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]


#93298 — Bug#1141185: linux-image-6.12.94+deb13-amd64: Occasional read problems in RAID/LVM/ext4 stack when under stress.

FromCharles Curley <charlescurley@charlescurley.com>
Date2026-07-09 22:00 +0200
SubjectBug#1141185: linux-image-6.12.94+deb13-amd64: Occasional read problems in RAID/LVM/ext4 stack when under stress.
Message-ID<Nf34B-3L7r-1@gated-at.bofh.it>
In reply to#93258
On Mon, 6 Jul 2026 15:46:29 -0600 Charles Curley
<charlescurley@charlescurley.com> wrote:


> 
> Nope. Stock, bog-standard except for the addition of one SATA card.
> 
> root@hawk:~# lspci -vs 4:0
> 04:00.0 SATA controller: JMicron Technology Corp. JMB58x AHCI SATA
> controller (prog-if 01 [AHCI 1.0]) Subsystem: JMicron Technology
> Corp. Device 0000 Flags: bus master, fast devsel, latency 0, IRQ 31
> 	I/O ports at d200 [size=128]
> 	I/O ports at d180 [size=128]
> 	I/O ports at d100 [size=128]
> 	I/O ports at d080 [size=128]
> 	I/O ports at d000 [size=128]
> 	Memory at f7c10000 (32-bit, non-prefetchable) [size=8K]
> 	Expansion ROM at f7c00000 [disabled] [size=64K]
> 	Capabilities: [80] Power Management version 3
> 	Capabilities: [90] MSI: Enable+ Count=1/8 Maskable- 64bit+
> 	Capabilities: [c0] Express Legacy Endpoint, IntMsgNum 0
> 	Capabilities: [100] Advanced Error Reporting
> 	Capabilities: [150] Device Serial Number
> 00-00-00-00-00-00-00-00 Capabilities: [160] Power Budgeting <?>
> 	Capabilities: [1b8] Latency Tolerance Reporting
> 	Capabilities: [300] Secondary PCI Express
> 	Capabilities: [900] L1 PM Substates
> 	Kernel driver in use: ahci
> 	Kernel modules: ahci
> 
> root@hawk:~# 
> 
> That suggests a test to try when I get a chance: power down the DVD
> drive, move the boot SSD to that card and the one HD currently on that
> card to the motherboard. It may be several days before I get to it,
> though.

Well, I may have a diagnosis. In any case, I have other problems which
will delay further work on this.

I made the above changes, except I left the DVD drive powered and on
the above SATA card. On booting, I added "fsck.mode=force" to the linux
line. fack failed the root partition. That is on the SSD, now on the
SATA card. manually fscking that several times produced two to four
errors of the form "directory has no checksum" and "directory
corrupted". On each pass the errors showed up in different inode
numbers.

Also, for the halibut, I fscked the home partition, which should have
been completely untouched by the boot process. Similar errors obtained.

I then powered down, removed power from the DVD drive, and moved the
SSD to the other SATA port on the card. This time both home and root had
similar issues.

I then shut the system down, and hooked the SSD up to another computer
via a USB-SATA adapter (Bus 001 Device 008: ID 152d:2338 JMicron
Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to
SATA & PATA Combo Bridge). I may have cooked the SSD in the process. I
couldn't read the device on the other computer. Also, the power
connector was warm when I took it off the SSD.

I then set the computer under discussion back up as it had been
originally. It refused even to power on. I unhooked the SSD from data
and power. The computer now boots. I have booted finnix (a rescue
Linux), and will fsck the hard drive while I contemplate my next move.
But I suspect a replacement SSD and SATA card are in order.

It will take me a few days to get replacements, during which time I can
run memory tests.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]


#93438 — Bug#1141185: Status, probable solution.

FromCharles Curley <charlescurley@charlescurley.com>
Date2026-07-23 01:30 +0200
SubjectBug#1141185: Status, probable solution.
Message-ID<NjOxX-6nEH-1@gated-at.bofh.it>
In reply to#93158
On July 6, my main drive (an SSD) died on me. I have been rebuilding
the system since. While waiting for the replacement drive, I ran
memtest86. Four days of that showed no problems.

Current status:

The old dead SSD was a SATA interface. The replacement is an m.2 SATA
SSD. This allowed me to remove all hard drives from the added PCI SATA
card. That now has only the DVD drive. The four RAID hard drives are now
attached directly to the motherboard. I have installed trixie, kernel
6.12.96+deb13-amd64. This is not exactly the kernel I was using when the
problems first appeared (6.12.94-1), but close.

Testing as above shows no errors. Fscking the RAID logical volumes
shows no errors. No-one else has chimed in observing the same thing. I
will continue testing but I am inclined to think that the problem was my
hardware, not the kernel.

Unless I hear otherwise in a few days I will close this bug per
https://www.debian.org/Bugs/Developer#closing.

Thank you for your responses.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]


#93464 — Bug#1141185: marked as done (linux-image-6.12.94+deb13-amd64: Occasional read problems in RAID/LVM/ext4 stack when under stress.)

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2026-07-26 14:30 +0200
SubjectBug#1141185: marked as done (linux-image-6.12.94+deb13-amd64: Occasional read problems in RAID/LVM/ext4 stack when under stress.)
Message-ID<Nl69r-74xR-9@gated-at.bofh.it>
In reply to#93158

[Multipart message — attachments visible in raw view] — view raw

Your message dated Sun, 26 Jul 2026 14:27:34 +0200
with message-id <eceb5be2a4db1eb77c617eb895af32277223e281.camel@decadent.org.uk>
and subject line Re: Status, probable solution.
has caused the Debian Bug report #1141185,
regarding linux-image-6.12.94+deb13-amd64: Occasional read problems in RAID/LVM/ext4 stack when under stress.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1141185: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141185
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.kernel


csiph-web