From nobody Mon Nov 11 11:45:12 2024 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 4Xn75N2TZlz5dBPd for ; Mon, 11 Nov 2024 11:45:12 +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 4Xn75N0SY6z4kVn for ; Mon, 11 Nov 2024 11:45:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731325512; 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=Y/b8u4Hm6NwNRXdVsuPmF0/U1ngR6pAoNXKU3McQ9VE=; b=gIiCH9IUR3QZF06ubU7T+THa2yjB5yxF3GipJ89tc4ht0p0yGIYHuVSUZYfnGCX3CtAhRi 35dr6mXzlXMDQ/oL+xOX+ctj9JyVKI6YJmA5YdxHfmFVWqQ5X4wjH5yerQFuAGO7XhLEii IqwI7fYABdULbVAZik7C5qPGV5nlwHG+aZ9y/08eOnnR7GasjRsWG9akLZvRFEnGKTTgC2 9FdPaHlnvm3qSi7QnlFgGJVgnNvCgLo3TM4ZYVsUF7JelvgMFRlJA8GtMy7ljz8oRfDQkY K1UO2z/SwELT/8swFd5dD4hVo+Bszm/7xUBkd15EruD4M1JS5R4zGSaCpa4wFQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731325512; a=rsa-sha256; cv=none; b=I3k1Fai257vWIuVfEfD6mD7Zso06ZnrriF7JtdBeEgTxCjGJGaacT0dfNZ+wewL0POuZ6m LQaICKPO1WD1ZuQ9zjpCOVGPUOA1v+5i7kwo393VNE9Y0fxnEJIm1IZrr/Q7aekq59qmQ7 Jf2oviN4ot1HqVkkgQjkmbHVEEdjqGhXhmaA4SCeMX9dPZJTNoXHfq/B+B0H2MVsqzFdFf qNFWTYgh+KGUUPlKUWny86TQ8eJdLzWTHFF+x3dwxZFaibX4jtKqksZiPGHins38TC66di BHWYqBy+AWbviH8t4WrjOVa1YX0zr0e1Hs3UdtUGw0QbxFlHLGTulJ1dI3MIOw== 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 4Xn75M745VzPF2 for ; Mon, 11 Nov 2024 11:45:11 +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 4ABBjBRM041901 for ; Mon, 11 Nov 2024 11:45:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4ABBjBai041900 for bugs@FreeBSD.org; Mon, 11 Nov 2024 11:45:11 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 281177] 13.2 works, 13.3 and 14.x installers panic on older qlogic isp card Date: Mon, 11 Nov 2024 11:45:12 +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: 13.3-RELEASE X-Bugzilla-Keywords: crash, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: Joerg.Pulz@frm2.tum.de X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=3D281177 --- Comment #27 from Joerg Pulz --- Some background on isp(4) default firmware handling: Every card has firmware in flash and we have firmware for every supported isp(4) card generation in ispfw(4). The driver reads the FLT (flash layout table) to get the flash address of t= he firmware stored on the card. The firmware header is loaded from flash at this address to get the firmware version. ispfw(4) is loaded and the firmware header is parsed to get the ispfw(4) firmware version. After comparison of the available versions the newer one is loaded into the= RAM of the card and the card is instructed to execute the loaded firmware. There are some hints (hint.isp.N.fwload_disable and hint.isp.N.fwload_force= ) to change the above behavior. On a running system three sysctl(8) values provide firmware version information: dev.isp.N.fw_version_flash The readonly flash firmware version value in the active region of the controller. dev.isp.N.fw_version_ispfw The readonly firmware version value provided by ispfw(4). dev.isp.N.fw_version_run The readonly firmware version value currently executed on the controller. As the behavior hasn't changed between 14.1 and 14.2, I wonder what happens here. It may be that there are some old cards with broken flash and reading the F= LT fails or gives bad data. If that's the case than probably reflashing the card may be of help. But if that's the case it should happen on 14.1 systems too. About disabling isp(4) in GENERIC: Actually we are talking about two/three people with the 24xx 4Gbit/s) and 2= 5xx (8Gbit/s) cards that seem to be problematic. The latest firmware for the 25= xx cards is dated 2019. We seem to have no issues with the 26xx (16Gbit/s), 27xx (32Gbit/s) and 28xx (32 and 64Gbit/s) cards. Is that enough to justify disabling isp(4) in GENERIC at all? It is no requirement to enable ispfw(4) in loader.conf(5). isp(4) is loading and usi= ng it if available automatically if not instructed by a hint to do otherwise. = So disabling isp(4) in GENERIC will most probably hit all people that have no explicit isp_enable=3D"YES" in loader.conf(5). We could think about changing the code to skip FLT reading for those old ca= rd generations at all and change the load and exec behavior back to the state before all my changes. That's probably not going to happen in time for 14.2. Binary firmware loading instead of .ko is possible. I already have some code for this. But it would be a complete change away from ispw(4). Anyway, I doubt that this would solve the problem we see here. Again, probably not going to happen for 14.2. For further tasks to solve this I would need some detailed data where it br= eaks on 14.2. Unfortunately my test system is currently running without the 25xx card. I = have physical access to this system tomorrow to plug in a 25xx card and run some tests by myself. In the meantime: @Vladimir Can you please boot your panicing 14.2 memstick using hint.isp.0.debug=3D"0x3f" That should reveal all details about reading and parsing the FLT and firmwa= re header and about firmware loading and execution. I need all the console output until it panics. --=20 You are receiving this mail because: You are the assignee for the bug.=