Summary: | mpt(4), mptutil(8) reports variable, erroneous drive information | ||
---|---|---|---|
Product: | Base System | Reporter: | Rory Arms <rorya+FreeBSD.org> |
Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
Status: | Open --- | ||
Severity: | Affects Only Me | CC: | emaste |
Priority: | Normal | ||
Version: | 8.2-RELEASE | ||
Hardware: | Any | ||
OS: | Any |
Description
Rory Arms
2011-11-13 04:50:06 UTC
This is a known issue; mptutil(8) isn't endian-clean (actually the IOCTL- interface of mpt(4) is little-endian even on big-endian architectures and actually also should stay that way as otherwise we would need to add code to the driver to convert all possible configuration pages, which doesn't make sense), which requires a non-trivial amount of work to fix. That mptutil(8) is working that much in it's current state actually is really amazing. For now you're probably better off using the software RAID equivalent. Marius Thanks for your usual prompt response, Marius. B) After I submitted this, it crossed my mind that it might be an endian = issue. Well, I really bought that controller just so I could attach new = SATA/SAS drives to my aging sun4u. So I don't need to use the RAID = capabilities on it. You suggest using software RAID, which was what I was thinking of using = anyway. So it's sofe to assume that using mpt(4) in a RAID-less = configuration should not be a problem? I was thinking of using zfs or = vinum to do RAID1 with 2 1 TB drives. I suppose it's possible that at = some point I may hove those drives to amd64, so it would be nice if it = would continue to work there w/o a dump & restore. As a recall zfs does = write data in the endian order of the host that created the volume, but = is smart enough to swap byte order as it reads the data from disk, when = the disk is moved to a PC. But I assume there would be some kind of = performance penalty for this. How about vinum and UFS2, would these = require a restore of the data once moved to a PC? Also at what size drive is OBP 3.10 going to have have a problem = accessing or addressing a large drive? As I recall OBP had a 2 TB limit, = so I assume there will be some kind of problem with drives above 2TB in = size? How about the VTOC8 label, does it have similar limits? Regarding this endian issue with mpt(4)/mptutil(8) ioctl, I don't see a = mention of it in the 8.2 release notes, hardware notes or errata = documents. Wouldn't it make sense to add a note about this in there for = the impending v9 release? I was actually about to upgrade to v9 to check = for this problem, before I sent this. But decided to wait for the = response first. I was just trying to find the corresponding release = documents on the site for v9 but couldn't find them. At least, it used = to be that you could see them on the site a few weeks before a release, = but I can't find them now. For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped A commit references this bug: Author: emaste Date: Mon Jul 22 17:25:36 UTC 2019 New revision: 350215 URL: https://svnweb.freebsd.org/changeset/base/350215 Log: mptutil: emit a warning on big-endian architectures It is known to be broken. PR: 162513 MFC after: 1 week Sponsored by: The FreeBSD Foundation Changes: head/usr.sbin/mptutil/mptutil.c A commit references this bug: Author: emaste Date: Tue Jul 30 14:18:05 UTC 2019 New revision: 350441 URL: https://svnweb.freebsd.org/changeset/base/350441 Log: MFC r350215: mptutil: emit a warning on big-endian architectures It is known to be broken. PR: 162513 Sponsored by: The FreeBSD Foundation Changes: _U stable/12/ stable/12/usr.sbin/mptutil/mptutil.c A commit references this bug: Author: emaste Date: Tue Jul 30 14:19:19 UTC 2019 New revision: 350442 URL: https://svnweb.freebsd.org/changeset/base/350442 Log: MFC r350215: mptutil: emit a warning on big-endian architectures It is known to be broken. PR: 162513 Sponsored by: The FreeBSD Foundation Changes: _U stable/11/ stable/11/usr.sbin/mptutil/mptutil.c Reclassify from spar64 as this is a big endian issue, not a sparc-specific issue |