On Sat, Jan 27, 2007 at 10:47:49PM +0000, Josef Karthauser wrote: > > The error messages from mpt are attached in the file called 'messages'. > The kernel probe boot time log is attached as dmesg.log. >
> Jan 27 18:42:03 littoralis kernel: mpt0: QUEUE FULL EVENT: Bus 0x00 Target > 0x01 Depth 121 > Jan 27 18:44:01 littoralis kernel: mpt0: QUEUE FULL EVENT: Bus 0x00 Target > 0x00 Depth 121 > Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca756328:48785 timed out > for ccb 0xca8f0c00 (req->ccb 0xca8f0c00) > Jan 27 18:51:06 littoralis kernel: mpt0: attempting to abort req > 0xca756328:48785 function 0 > Jan 27 18:51:06 littoralis kernel: mpt0: request 0xca755c28:48786 timed out > for ccb 0xcc213800 (req->ccb 0xcc213800) An update for anyone who's following this thread. At Matthew Jacob's suggestion I tweaked the 'camcontrol tags' settings for the drives, and with a particular choice of settings the problems goes away. So, at boot time both drives (da0|1) report that they have 255 tag openings. However you can see above in the logs that the mpt files when the depth gets to 121. If I manually set the tags for the drives to anything 120 or above the drive controller complains under load, and one of the disks goes away. If I get it to 119 the server runs all day without missing a beat. Matt suggested quirking the drives to fix this. I'm wondering though where it is that the mpt controller get the queue size of 121 from, and why the drives report 255 at boot time. Is this because the control isn't mediating this information properly, or is there a bug in the controller firmware or driver? Joe
pgpZ1IMzT4dJf.pgp
Description: PGP signature