Date: Thu, 28 Nov 2024 14:45:24 +0000 From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 271238] mpr (LSI SAS3816) driver not finding all devices in HP D6020 enclosures Message-ID: <bug-271238-1689-FFoOeY4AKc@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-271238-1689@https.bugs.freebsd.org/bugzilla/> References: <bug-271238-1689@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271238 --- Comment #14 from Peter Eriksson <pen@lysator.liu.se> --- (In reply to Rafe from comment #13) Yes, it's that mapping that fails. However I can't use "-1" since from the = man page: "device. This feature is not recommended if the topology includes multiple enclosures/expanders. If multiple enclosures/expanders are present in the topology, Phy numbers are repeated, causing all devices at these Phy numbers except the first device to fail enumeration." In our setup we have multiple expanders (one in each drawer) so the phy num= bers definitely repeat. (The Linux people seems to have dropped all this HBA/driver-specific mapping logic since kernel 2.6 and just identifies drives using their WWN and uses "udev" to create stable mappings in the kernel instead - that is probably a better way of doing it, but that's a major change :-) Btw, I'm not sure it is the D6020 enclosures that's really at fault. When I query the box via sg_ses / camcontrol smpphylist etc it gives valid results= and says 35 slots etc. The wrong (18 instead of 35) number of slots definitely comes from the SAS3= 816 HBA via an MPI message (MPI2_SAS_ENCL_DEVICE_STATUS_CHANGE) though, so it's= not something the mpr driver dreams up atleast :-) --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-271238-1689-FFoOeY4AKc>