mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
To: Madhavan Srinivasan <maddy@linux.ibm.com>,
	Ritesh Harjani <riteshh@linux.ibm.com>,
	Shrikanth Hegde <sshegde@linux.ibm.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	nandinih@linux.ibm.com
Cc: LKML <linux-kernel@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: [BUG] selftests/powerpc/eeh: eeh-basic breaks the device hosting rootfs, ext4 goes read-only and the test harness crashes
Date: Thu, 12 Nov 2026 11:36:36 +0530	[thread overview]
Message-ID: <9113e399-ddd0-405e-9abb-69a9785c726c@linux.ibm.com> (raw)

Hello!!!

IBM CI has hit a failure that takes down the test harness, While running 
the powerpc EEH selftest on a bare-metal POWER system.

The selftest injects an error into the PCI device that hosts the root 
filesystem. The filesystem goes read-only and the run dies.

[ 1112.079091] EEH: Frozen PHB#3-PE#1fd detected
[ 1112.079905] aacraid 0003:01:00.0: aacraid: PCI error detected 2
[ 1112.140830] I/O error, dev sdb, sector 3906906472 op 0x1:(WRITE) ...
[ 1112.140957] Aborting journal on device sdb2-8.
[ 1112.140977] EXT4-fs error (device sdb2) in ext4_dirty_inode:7656: IO 
failure
[ 1112.176664] EXT4-fs error (device sdb2): ext4_journal_check_start:98: 
... Detected aborted journal
[ 1187.736385] aacraid 0003:01:00.0: aacraid: PCI error - slot reset
[ 1217.244306] EXT4-fs (sdb2): Remounting filesystem read-only
[ 1220.583495] aacraid 0003:01:00.0: aacraid: PCI error - resume

We need to make appropriate changes to selftest, so that it skips the 
adapter, if rootfs is hosted on it.


SetUp:

System: IBM 9006-22C (POWER9), PowerNV, bare metal
Firmware: skiboot-v6.8-45-g8246de863
Kernel: 7.4.0-rc2+, upstream master at 067c5c24cef2 ("Merge tag 
'page_alloc-for-7.4-rc2'", 2026-11-10)


Issue1: Selftest should skip the adapter that host the rootfs

eeh_can_break() already skips ahci, for similar reason, but has no check 
for a device that backs /. A friendly LLM has suggested

below change, which I tested and it works.

0003:01:00.0, Skipped: hosts the root filesystem

Other adapters are tested as before and the run completes

diff --git a/tools/testing/selftests/powerpc/eeh/eeh-functions.sh 
b/tools/testing/selftests/powerpc/eeh/eeh-functions.sh
index 70daa3925dcb..f9db1f9be05a 100644
--- a/tools/testing/selftests/powerpc/eeh/eeh-functions.sh
+++ b/tools/testing/selftests/powerpc/eeh/eeh-functions.sh
@@ -62,6 +62,42 @@ eeh_test_prep() {
      echo 5000 > /sys/kernel/debug/powerpc/eeh_max_freezes
  }

+# Print the resolved sysfs path of a block device followed by the paths of
+# every device stacked underneath it (dm, md, etc).
+eeh_blk_sysfs_paths() {
+    local sys="$1"
+    local s
+
+    realpath "$sys"
+    for s in "$sys"/slaves/* ; do
+        if [ -e "$s" ] ; then
+            eeh_blk_sysfs_paths "$s"
+        fi
+    done
+}
+
+# Succeeds if the root filesystem lives on a disk behind any function 
of the
+# slot containing the given PCI device.
+eeh_hosts_rootfs() {
+    local slot="${1%.*}"
+    local majmin src sys
+
+    # Use the last "/" entry so an initramfs rootfs entry is ignored.
+    majmin="$(awk '$5 == "/" { mm = $3 } END { print mm }' 
/proc/self/mountinfo)"
+    src="$(awk '$5 == "/" { for (i = 6; i < NF; i++) if ($i == "-") s = 
$(i + 2) } END { print s }' /proc/self/mountinfo)"
+
+    if [ -e "/sys/dev/block/$majmin" ] ; then
+        sys="/sys/dev/block/$majmin"
+    elif [ -b "$src" ] ; then
+        # e.g. btrfs reports an anonymous major:minor
+        sys="/sys/class/block/$(basename "$(realpath "$src")")"
+    else
+        return 1
+    fi
+
+    eeh_blk_sysfs_paths "$sys" 2>/dev/null | grep -q "/${slot}\.[0-7]/"
+}
+
  eeh_can_break() {
      # skip bridges since we can't recover them (yet...)
      if [ -e "/sys/bus/pci/devices/$dev/pci_bus" ] ; then
@@ -78,6 +114,14 @@ eeh_can_break() {
          return 1;
      fi

+    # Breaking the device that hosts the root filesystem makes I/O fail
+    # during recovery, which can abort the journal and leave / read-only
+    # (and kill the test harness). Leave it alone.
+    if eeh_hosts_rootfs "$1" ; then
+        log "$1, Skipped: hosts the root filesystem"
+        return 1;
+    fi
+
      # Don't inject errosr into an already-frozen PE. This happens with
      # PEs that contain multiple PCI devices (e.g. multi-function cards)
      # and injecting new errors during the recovery process will probably



Issue2: Some adapters take longer time to recover.


Once the rootfs device was skipped, the run completed, but with the 
default 60 s wait three adapters were reported as Failed to recover!,
and the summary was 3 devices failed to recover (6 tested). Checking the 
PE state afterwards showed them healthy .
I re-ran with EEH_MAX_WAIT=240, and all of them recovered:

Result with the 240 s limit: 0 devices failed to recover (6 tested).

BRCM/Mellonox/Intel Adapters took 78s/77s/75s respectively to recover. 
So I think its better to increase default timeout to 120s.

diff --git a/tools/testing/selftests/powerpc/eeh/eeh-functions.sh 
b/tools/testing/selftests/powerpc/eeh/eeh-functions.sh
index 70daa3925dcb..1f1d1c8d73bc 100644
--- a/tools/testing/selftests/powerpc/eeh/eeh-functions.sh
+++ b/tools/testing/selftests/powerpc/eeh/eeh-functions.sh
@@ -110,13 +110,13 @@ eeh_one_dev() {
      # is a no-op.
      echo $dev >/sys/kernel/debug/powerpc/eeh_dev_check

-    # Default to a 60s timeout when waiting for a device to recover. This
+    # Default to a 120s timeout when waiting for a device to recover. This
      # is an arbitrary default which can be overridden by setting the
      # EEH_MAX_WAIT environmental variable when required.

      # The current record holder for longest recovery time is:
-    #  "Adaptec Series 8 12G SAS/PCIe 3" at 39 seconds
-    max_wait=${EEH_MAX_WAIT:=60}
+    #  "Broadcom / LSI SAS3008" at 78 seconds
+    max_wait=${EEH_MAX_WAIT:=120}

      for i in `seq 0 ${max_wait}` ; do
          if pe_ok $dev ; then


Please let me know, if the fix for the two issues are good enough, I can 
send a formal patch.



Regards,

Venkat.


                 reply	other threads:[~2026-11-12  6:06 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9113e399-ddd0-405e-9abb-69a9785c726c@linux.ibm.com \
    --to=venkat88@linux.ibm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=nandinih@linux.ibm.com \
    --cc=riteshh@linux.ibm.com \
    --cc=sshegde@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®