minimike said:
# mptutil show events gives you a hex dump instead of useful messages.(0:83) new-gate:/tmp# mptutil show adapter
mpt0 Adapter:
Board Name: SAS6IR
Board Assembly:
Chip Name: C1068E
Chip Revision: UNUSED
RAID Levels: RAID0, RAID1, RAID1E
RAID0 Stripes: 64K
RAID1E Stripes: 64K
RAID0 Drives/Vol: 2-10
RAID1 Drives/Vol: 2
RAID1E Drives/Vol: 3-10
(0:84) new-gate:/tmp# mptutil show volumes
mpt0 Volumes:
Id Size Level Stripe State Write-Cache Name
0 ( 279G) RAID-1 OPTIMAL Enabled
(0:85) new-gate:/tmp# mptutil show drives
mpt0 Physical Drives:
0 ( 279G) ONLINE <WDC WD3000HLFS-0 4V02> SATA bus 0 id 1
1 ( 279G) ONLINE <WDC WD3000HLFS-0 4V02> SATA bus 0 id 9danstoner said:
(0:200) new-gate:~terry# ./lsiutil
LSI Logic MPT Configuration Utility, Version 1.60, July 11, 2008
sh: /sbin/modprobe: No such file or directory
/bin/mknod: `/dev/mptctl': No such file or directory
Couldn't open /dev/mptctl or /dev/mpt2ctl!
0 MPT Ports found mptutil just segmentation fault.# mptutil show drives
Segmentation fault (core dumped)
# mptutil show config
Segmentation fault (core dumped)
# uname -a
FreeBSD StorOS 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64I have an mpt(4) adapter on FreeBSD 10.1 amd64 (r276774 from 10-STABLE) and while I don't have any drives connected to it, mptutil(8) doesn't segfault:
(0:17) test2:/sysprog/terry# mptutil show adapter
mpt0 Adapter:
Board Name: 0
Board Assembly: 0
Chip Name: C1030
Chip Revision: 0
RAID Levels: none
(0:18) test2:/sysprog/terry# mptutil show config
mpt0 Configuration: 0 volumes, 0 drives
(0:19) test2:/sysprog/terry# mptutil show drives
mpt0 Physical Drives: pciconf -lv and dmesg mpt0@pci0:4:0:0: class=0x010000 card=0x31401000 chip=0x00581000 rev=0x08 hdr=0x00
vendor = 'LSI Logic / Symbios Logic'
device = 'SAS1068E PCI-Express Fusion-MPT SAS'
class = mass storage
subclass = SCSI
# dmesg | grep -i MPT
mpt0: <LSILogic SAS/SATA Adapter> port 0xe000-0xe0ff mem 0xfba10000-0xfba13fff,0xfba00000-0xfba0ffff irq 27 at device 0.0 on pci4
mpt0: MPI Version=1.5.19.0
mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 )
mpt0: 0 Active Volumes (2 Max)
mpt0: 0 Hidden Drive Members (14 Max)
da0 at mpt0 bus 0 scbus0 target 40 lun 0
da1 at mpt0 bus 0 scbus0 target 41 lun 0
da2 at mpt0 bus 0 scbus0 target 42 lun 0
cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed
da3 at mpt0 bus 0 scbus0 target 43 lun 0
da6 at mpt0 bus 0 scbus0 target 46 lun 0
da7 at mpt0 bus 0 scbus0 target 47 lun 0
da4 at mpt0 bus 0 scbus0 target 44 lun 0
da5 at mpt0 bus 0 scbus0 target 45 lun 0
pid 914 (mptutil), uid 0: exited on signal 11 (core dumped)
pid 915 (mptutil), uid 0: exited on signal 11 (core dumped)Does it segfault if you invoke it with no arguments? How about as
mptutil version? If those segfault, I'd suspect something is wrong with either the libraries on your system or with the prebuilt mptutil(8) binary.# ktrace mptutil; kdump would be informative - it will let us know how far it gets before it segfaults.The mpt(4) driver encompasses a very large range of controller models. In my case, it is a PCI Express SCSI (traditional Ultra320 parallel SCSI, not SAS) host adapter without RAID features.
mptutil version and mptutil show adapter looks good.ccb->ccb_h.status =1;
CAM_STATUS_MASK = 0x3F
CAM_REQ_CMP = 0x01cam_freeccb(ccb);(gdb) b
Breakpoint 1 at 0x40253a: file mpt_cam.c, line 292.
(gdb) bt
#0 0x0000000800f0c24c in sbrk () from /lib/libc.so.7
#1 0x0000000800f0c7af in sbrk () from /lib/libc.so.7
#2 0x0000000800f17df5 in free () from /lib/libc.so.7
#3 0x000000000040253a in mpt_fetch_disks (fd=<value optimized out>,
ndisks=0x7fffffffe9bc, disksp=0x7fffffffe9c0) at mpt_cam.c:292
#4 0x0000000000405ce9 in show_drives (ac=<value optimized out>,
av=<value optimized out>) at mpt_show.c:500
#5 0x000000000040192c in main (ac=2, av=0x7fffffffea98) at mptutil.c:117
(gdb) frame 3
#3 0x000000000040253a in mpt_fetch_disks (fd=<value optimized out>,
ndisks=0x7fffffffe9bc, disksp=0x7fffffffe9c0) at mpt_cam.c:292
292 cam_freeccb(ccb);
(gdb) l
287 cam_freeccb(ccb);
288 return (error);
289 }
290
291 if ((ccb->ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) {
292 cam_freeccb(ccb);
293 return (EIO);
294 }
295 cam_freeccb(ccb);
296
(gdb) p ccb->ccb_h.status
$3 = 1 kdumpyou asked is attached.Something odd is going on here. mptutil is stripped by default, so you shouldn't have the symbol table. Can you tell me some more about the system you're running on? Your earlier post indicated you were running a release kernel. Was this installed from a FreeBSD distribution or a 3rd-party build? Did you compile anything yourself? If so, do you have anything at all in /etc/make.conf? Messing with compiler flags in there should really carry a "WARNING: No user serviceable parts inside" disclaimer.
Go here. But I'd suggest doing a few more rounds with me first to make sure it isn't something peculiar to your install.
# camcontrol devlist -v? Also, the full contents of /var/run/dmesg.boot might be useful. If you feel you need to censor anything in there, just xxx it out, or PM it to me if you don't want others to see it. [There normally isn't anything sensitive in there, but some people don't want to show their Ethernet addresses or any field test hardware that might be present.] mptutil coredumped, and you showed it is working on your setup. I downloaded source code of mptutil from 10.1-RELEASE, and compile it with -g. gdb to provide more info.# uname -a
FreeBSD StorOS 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 camcontrol devlist -v lists all the 8 disks I plugged in.These are SAS drives (at least the RE4 on da3/pass3 is). I also suspect you have a SAS expander in the chassis, give the improbably high target numbers for direct attachment.
# mptutil still segfaults. This assumes that it is on the installation media - I didn't check. Also, you could try older or newer FreeBSD releases to see if this is specific to 10.1 (or 10.x). mptutil show drives still segfaulted mptutil show drives still segfaultedHow about shutting down the system and removing all drives, then booting from the 10.1-RELEASE stick and see if it still faults with no drives? Then shut down and reinstall your drives. This should be harmless, though I'd suggest backing up first just to be safe.
Ok. Why don't you try the 8.4 and current (11) images and see if both of those fault.
mptutil does not segfault. However, when I reinstall one drives. mptutil will segfault.Yes. It would be interesting to see if this behavior is the same on 8.4 and CURRENT. If it doesn't segfault on CURRENT, then there may be a fix that can be MFC'd to 10.1.
259 if ((ccb->ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) {
260 cam_freeccb(ccb);
261 return (EIO);
262 }
263 cam_freeccb(ccb);
264
265 /*
266 * A last block of 2^32-1 means that the true capacity is over 2TB,
267 * and we need to issue the long READ CAPACITY to get the real
268 * capacity. Otherwise, we're all set.
269 */
270 if (scsi_4btoul(rcap.addr) != 0xffffffff) {
271 disk->maxlba = scsi_4btoul(rcap.addr);
272 return (0);
273 }
274
275 /* Zero the rest of the ccb. */
276 bzero(&(&ccb->ccb_h)[1], sizeof(struct ccb_scsiio) -
277 sizeof(struct ccb_hdr));
278
279 scsi_read_capacity_16(&ccb->csio, 1, NULL, MSG_SIMPLE_Q_TAG, 0, 0, 0,
280 (uint8_t *)&rcaplong, sizeof(rcaplong), SSD_FULL_SIZE, 5000);
281
282 /* Disable freezing the device queue */
283 ccb->ccb_h.flags |= CAM_DEV_QFRZDIS;
284
285 if (cam_send_ccb(dev, ccb) < 0) {
286 error = errno;
287 cam_freeccb(ccb);
288 return (error);
289 }
290
291 if ((ccb->ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) {
292 cam_freeccb(ccb);
293 return (EIO);
294 }
295 cam_freeccb(ccb);What model? What disk configuration? Where is the SAS HBA installed (back or front, or motherboard)? Is there a SAS expander card installed in the front (internal) PCIe slot?
Actually, that's the big tower model. It may very well have no expander at all, because it can only handle 8 big (3.5") disks in hardware, which means the SAS HBA has enough ports to feed all disks. I think you can buy a similar model with disk hardware for 16 small disks; that probably causes an expander to be added somewhere. I'm not very familiar with the tower models though, only seen them from the outside, so I wouldn't know where to look for the expanders.