From nobody Wed Jan 22 00:31:17 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 4Yd4kY4qMmz5lpWM for ; Wed, 22 Jan 2025 00:31:17 +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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yd4kY3NGDz3Rq7 for ; Wed, 22 Jan 2025 00:31:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1737505877; 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=vPlHl9Hgi50l8wSADPlmc201oBa8MZfkfL3WTmjJBsw=; b=OwfT+FtJuUNG/p7PnxFFqNpZ/w38l0Cpb+xDWZWKKIqUbeR0y9KQvHWLlzes2bWtMLwEon zf3oT9AM+7AMZmjW8tWrhqgZks+lB+exwOOxsnzqa/lTLYQYWAypEdFKs1kvrpE5bRpaMQ mB6kHjoHHJanpTyk3T2ltUHOaHjqh+tTCso1xztmcWOUawMq6x5u7yzh1eSmMsQJXhwc+X Rom+U4s+82ZjpJmCUU4cvlAkw7WioAAZsoX6flzNNYgIrmlbx9uhLSIPWiKTVIbyz6YeQQ ihsru64xu7QjIDN543f3we1chJ/XxgSKCk2vhTm+P8jQI0UslWs1IWKEk6R2mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1737505877; 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=vPlHl9Hgi50l8wSADPlmc201oBa8MZfkfL3WTmjJBsw=; b=kjuFPqIS4iWGJH05kLwhuy6h+0cDduHz1l6kZNfzzLqCSEFsROb5nwDc6B36dn4DLEGQNI r7OUiUWq3FShDjEw//hSlYOfZfr4dFIRgludGtN/vIC3eD6f1DIlX5eT8uFyXmHOO+imIX mITWztS6n3J1ZBUW+wzc2sFmyMXBnaBPL496mAYxLTquS11iRU4C0sgYxTU3FcxSkuVfxp 581k7PoiAHUGtEMEgxUWU8katJIrXHD7JV6I0CFegYvTGaqeUvFj+LevQztjxGtUDVkqWd eO8V7iXd0tM2M5ThkQK9pOr9yO8y02zWTJbeSPvysCKOwIU0h8ry9sf+L5WTBg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1737505877; a=rsa-sha256; cv=none; b=Bna44V6dhIjF8nG/G0Ty957zjWwTeUJmyjfa53sLCkeywod43SXuwq/BPtq294XpFDD7Zz JwRqX/r2JJ63p9VmK4xB4VL1pOX9fHm+hTXxvcCUyRh4LpnpwpbZnW90I+EjPsiEfB5zZ7 WcTtuhJlWglMM8OVaxJtz0lv5YT0gQ858pnH+KTjxg4xderp6/oVt8q+2ZfiHPw9OPJHNc /RrsqUWxxfzgq4Xcv2LyhVhrsipaB/uKg7+i1db6VP6UMdeGxHqcALWueyKfYHklg9+YDj TjFWyZZ2RMBgIzwHmR6SIf2gG1oBlsnuYem3InH4rL0svh7MkARhlbszmsCsJg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4Yd4kY2VzKzVBM for ; Wed, 22 Jan 2025 00:31:17 +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 50M0VHnD042019 for ; Wed, 22 Jan 2025 00:31:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 50M0VHSB042018 for bugs@FreeBSD.org; Wed, 22 Jan 2025 00:31:17 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 284050] mrsasutil(8) "show volumes" command triggers multiple kernel messages Date: Wed, 22 Jan 2025 00:31:17 +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: 14.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: terry-freebsd@glaver.org 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-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=3D284050 --- Comment #11 from Terry Kennedy --- (In reply to Doug Ambrisko from comment #10) True. The kernel definitely knows the mapping (from dmesg.boot): da0 at mrsas0 bus 0 scbus0 target 0 lun 0 da1 at mrsas0 bus 0 scbus0 target 1 lun 0 da2 at mrsas0 bus 0 scbus0 target 2 lun 0 da3 at mrsas0 bus 0 scbus0 target 3 lun 0 da4 at mrsas0 bus 0 scbus0 target 4 lun 0 Obviously, we can't blithely assume that mrsas volume 0 is /dev/da0, becaus= e it depends on what else is in the device tree and the order of probing those devices. Is this info held somewhere that either the mrsas driver or mrsasutil utili= ty can fetch it from? Ideally it would be in the mrsas driver, so that any oth= er utility / application that wants to get the device name of a mrsas volume c= an do so, using the same methods that work for mfi. That would also cause the least changes in mrsasutil, since it seems to be built from the same source code as mfiutil. I did some reading in the architecture handbook but couldn't figure out if mrsas gets the actual /dev/daX names back when it registers the volumes thr= ough CAM, or even if that's mrsas's job - maybe once it provides a controller to CAM, CAM handles probing the controller for devices? If this is all too complex, maybe mfiutil could check if it was invoked as mrsasutil and just print the volume numbers as reported by the controller, without trying to find out the actual device name? That might prevent the current situation of asking the driver for data that doesn't exist and triggering these kernel messages. --- As an unrelated issue (let me know if you want me to PR it separately), when mrsas enumerates disks to CAM, it apparently passes a constant speed of 150MB/s. I don't think that information is easily obtainable from the controller, so it just makes up a plausible (for that era) speed and a seri= al number from somewhere (where the first 6 bytes are unique and the last 10 b= ytes are constant, at least for any given controller): da0 at mrsas0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-3 SCSI device da0: Serial Number 009f16ab082653142f00fdd86ba06d86 da0: 150.000MB/s transfers da0: 762496MB (1561591808 512 byte sectors) The speed is coming from mrsas_cam.c: ccb->cpi.base_transfer_speed =3D 150000; I don't see offhand where the serial number is coming from. This causes a number of mailing list / forum posts about "My disks are fast= er than that - why is it showing a slower speed?" Is there a speed we can set this to (perhaps 0 or -1) that will cause the kernel to omit the "daX: xMB/s transfers" line? --=20 You are receiving this mail because: You are the assignee for the bug.=