From nobody Mon Mar 31 12:05:22 2025 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZR8w303fwz5rwKR for ; Mon, 31 Mar 2025 12:05:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZR8w25MtFz3x1V for ; Mon, 31 Mar 2025 12:05:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1743422722; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=e8bLEuSiNbzXI2sg9Y+XPTc96sbXT4BRXGgYVTXhA8Y=; b=PA1fNG77SzV9LLKghAUjBZCSTzUlkU4Bu1gcScc8qUjww1c+LhX2JtwQlSTibW4OwkZkAz u9OGs74O+9fFwj7LKR46b3DG6XSxlcW+OqfsBbMgfyz+zb78qcjoqH+SO0skmDcVOl6VHO wWCwfzv/5gLPcNCMqT438lcfH7bxZl8ZBGQevWR+ZOvxkam/RjsRdRxX37MfoSN/NXaoLK hAPyVF3OZrkXvmJSWmgL/ViVQGCdv0hqupNoiDe7kEiBqLdwCHBBWE8Oyuxn40YoJB2whY t8Xj0XuTvjbCHqaG9UzK3WUfdgrVvoU+gg9cHxXdfWlTcVd4gT+RYHi4NPm0hw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1743422722; a=rsa-sha256; cv=none; b=dBWWdQzILI5/uN9chT8IW1Nf/v4QdMJwDRksO28nXRwAUe2TFj2mZBXmTXNjqa+K6sPLNe 25NE+XLUCpZR7B1XR8b4yooHqmd472FYU23vAiNE+PfmqKrJfMZQ6SqtPvjlH+gZXLuk+i mT1W6VMPX8CnVM86vyATYYy/1hoI6gNvD/ARTmel74r//wLkHLoucT2AY20ZH0x2cQZz6l B0iF4ZVlBOMn2kSO2TSm/O0YLjTIOQ6PdaoWe0pDoL/CBJhjDtRjVCGHxWEjyhw2pJQeTX GXarb/6Aglyv9C/3WRxFsjFgqC0tIWsnnfC9LjD/NtgPVueCf/od1uXsn6nQpQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1743422722; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=e8bLEuSiNbzXI2sg9Y+XPTc96sbXT4BRXGgYVTXhA8Y=; b=slp/xDeSV1fHh+UOU6Ok0VpCsK36nH9k8GttT8uQ2WGdxtktLb4ZUyh8uOB8qk0ZiBVEaH JaQPHNAIHWc7FmxMtv3YIiPE8sNjeYwq7S7IOyMYbW1cRU75MN1v9qc7E5LGHIXuaz11f7 UtlXzdLnRL86cYbHuqlI1OPDx2YjklD5mak+QRRk/fqaHliawLRn3AWjRT8v9GwPL/K6aQ sLWcTk+pBrBmNqJKC5N2eA1dFO5ETNNoDek0WrjcyxRaMEzCinpKOSlJbJbc13GET/6xH/ Q1uHUFAetG2go9+t4FCaDOnzbTHMNlUJGOYT/NpaA5Pc4hrtd5WHgJ3IwFNqUQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4ZR8w24b6jzlKQ for ; Mon, 31 Mar 2025 12:05:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 52VC5MCf069716 for ; Mon, 31 Mar 2025 12:05:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 52VC5MQT069715 for bugs@FreeBSD.org; Mon, 31 Mar 2025 12:05:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 243225] "mpr0: Out of chain frames" boot hang after clang 9.0.1 import (probably timing, not compiler related) Date: Mon, 31 Mar 2025 12:05:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: lopez.on.the.lists@yellowspace.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D243225 Lorenzo Perone changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lopez.on.the.lists@yellowsp | |ace.net --- Comment #7 from Lorenzo Perone --- Hi there, I have the exact same problem, on a DELL PowerEdge R440 with the DELL PERC HBA330 which is the LSI SAS 3008. I can report the following: With FreeBSD 14.2, the same happens with an unmodified memstick installer o= r a distribution over pxe / netboot. Setting hw.mpr.max_chains=3D2048 in /boot/loader.conf (in my netboot environment) helps booting, at least mo= st of the rounds. After the system is booted, I can see the controller and the= 2 drives attached to it, was able to create a zfs pool and copy data with nor= mal (expectable) speeds on them without problems. BUT: As soon as I add zfs_load=3D"YES"=20 (or for that matter geom_mirror_load=3D"YES". Any GEOM module will probably= do?) it goes back doing the same thing it was doing before, exactly as initially reported by Terry Kennedy (stuck in a reinitialization loop) So it does indeed look like there is a timing problem somehow. If the kernel tries to access the controller/drives in the boot process (such as the zfs = and geom modules do), the mpr driver gets stuck.=20 Note that booting off the EFI partition, as well as the root partition with according loader.conf, on those drives also works until I put in "zfs_load=3DYES". Which means that all the loader logic works, but as soon as the driver kicks in, it doesnt: - Reading loader.efi (as EFI/BOOT/freebsd.efi) from da0p1 or da1p1 (the dri= ves attached to the controller) works - Even reading /boot/loader.conf from the mirror zroot pool (boot pool) wor= ks - Loading the kernel works - But as soon as I put zfs_load or geom_mirror_load in /boot/loader.conf, it will load them, then initialize the rest of the kernel, but it will get stu= ck with the "initialization loop". Note that sometimes even removing the load_xxx lines does not help for some reboots, but will boot eventually after a cold start. So what I see very mu= ch matches the observations of Terry Kennedy about this problem behaving very erraticly. I am available for any tests for a limited time (I'll resort to another controller if I can on this machine...). Best Regards, Lorenzo --=20 You are receiving this mail because: You are the assignee for the bug.=