Date: Sat, 20 Feb 2010 00:56:18 +1100 From: Lawrence Stewart <lstewart@freebsd.org> To: Alexander Motin <mav@FreeBSD.org> Cc: svn-src-stable@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Matthew Jacob <mj@feral.com>, svn-src-stable-8@FreeBSD.org Subject: Re: svn commit: r203889 - in stable/8/sys: cam cam/ata cam/scsi dev/ahci dev/asr dev/ata dev/ciss dev/hptiop dev/hptrr dev/mly dev/mpt dev/ppbus dev/siis dev/trm dev/twa dev/usb/storage Message-ID: <4B7E9882.3000703@freebsd.org> In-Reply-To: <4B7E50DC.3070103@FreeBSD.org> References: <201002141938.o1EJcRpx065470@svn.freebsd.org> <4B7D4962.8070706@freebsd.org> <4B7D626A.9040301@feral.com> <4B7E2B94.3090605@freebsd.org> <4B7E50DC.3070103@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/19/10 19:50, Alexander Motin wrote: > Lawrence Stewart wrote: >> On 02/19/10 02:53, Matthew Jacob wrote: >>> Just a total swag here, but reduce the openings via camcontrol to< 32, >>> or even< 16 >> >> Thanks for the suggestion. camcontrol doesn't seem able to futz with the >> mpt controller e.g.: >> >> root@server# camcontrol identify da0 -v >> (pass0:mpt0:0:2:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 >> 00 00 >> (pass0:mpt0:0:2:0): CAM status: CCB request was invalid > > IDENTIFY is an ATA command. It is not working there now, as mpt on some > level translates ATA into SCSI. `camcontrol inquiry da0` and the others > probably should work. root@server# camcontrol inquiry da0 pass0: <LSILOGIC Logical Volume 3000> Fixed Direct Access SCSI-2 device pass0: 300.000MB/s transfers, Command Queueing Enabled > >> However, there does appear to be a relevant sysctl: >> >> root@server# sysctl dev.mpt.0 >> dev.mpt.0.%desc: LSILogic SAS/SATA Adapter >> dev.mpt.0.%driver: mpt >> dev.mpt.0.%location: slot=3 function=0 >> dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0050 subvendor=0x1000 >> subdevice=0x3060 class=0x010000 >> dev.mpt.0.%parent: pci2 >> dev.mpt.0.debug: 3 >> dev.mpt.0.role: 1 >> dev.mpt.0.vol_member_wce: NC >> dev.mpt.0.vol_queue_depth: 128 >> dev.mpt.0.vol_resync_rate: 0 >> dev.mpt.0.nonoptimal_volumes: 0 >> >> Setting dev.mpt.0.vol_queue_depth=32, I can still trigger the >> "mpt0: mpt_cam_event: 0x16" messages by doing an svn up on the src tree. >> Same if I set depth to 16, so unfortunately it doesn't seem to do help >> in this case. > > I am not sure what this sysctl does, but it is mpt driver own sysctl. It > has nothing common with number of tags used by CAM (at least directly). Ah ok, I misunderstood what openings meant in this context... I thought it was the queue depth. So if I restore dev.mpt.0.vol_queue_depth=128 and do the following: root@server# camcontrol tags da0 (pass0:mpt0:0:2:0): device openings: 255 root@server# camcontrol tags da0 -N 64 (pass0:mpt0:0:2:0): tagged openings now 64 (pass0:mpt0:0:2:0): device openings: 64 I can still trigger the "mpt0: mpt_cam_event: 0x16" messages. Same with openings set to 32. If I lower the openings down to 16, I still get fairly large stalls in disk IO, but the mpt_cam_event messages no longer appear. Hmmmm... Cheers, Lawrence
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B7E9882.3000703>