From owner-freebsd-scsi@FreeBSD.ORG Mon Feb 11 11:06:51 2013 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 79B182CE for ; Mon, 11 Feb 2013 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 6BADF1BDA for ; Mon, 11 Feb 2013 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1BB6pTT081405 for ; Mon, 11 Feb 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1BB6pRH081403 for freebsd-scsi@FreeBSD.org; Mon, 11 Feb 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Feb 2013 11:06:51 GMT Message-Id: <201302111106.r1BB6pRH081403@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/171650 scsi [da] da(4) driver does not recognize end of cciss (Sma o kern/169403 scsi [cam] [patch] CAM layer, I/O starvation, no fairness o kern/165982 scsi [mpt] mpt instability, drive resets, and losses on Fre o kern/165740 scsi [cam] SCSI code must drain callbacks before free o kern/163713 scsi [aic7xxx] [patch] Add Adaptec29329LPE to aic79xx_pci.c o kern/162256 scsi [mpt] QUEUE FULL EVENT and 'mpt_cam_event: 0x0' o kern/161809 scsi [cam] [patch] set kern.cam.boot_delay via build option o kern/157770 scsi [iscsi] [panic] iscsi_initiator panic o kern/154432 scsi [xpt] run_interrupt_driven_hooks: still waiting after o kern/153514 scsi [cam] [panic] CAM related panic o docs/151336 scsi Missing documentation of scsi_ and ata_ functions in c s kern/149927 scsi [cam] hard drive not stopped before removing power dur o kern/148083 scsi [aac] Strange device reporting o kern/147704 scsi [mpt] sys/dev/mpt: new chip revision, partially unsupp o kern/145768 scsi [mpt] can't perform I/O on SAS based SAN disk in freeb o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/127717 scsi [ata] [patch] [request] - support write cache toggling o kern/123674 scsi [ahc] ahc driver dumping o kern/123520 scsi [ahd] unable to boot from net while using ahd o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 45 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Feb 11 16:12:20 2013 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7BD17286; Mon, 11 Feb 2013 16:12:20 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog127.obsmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by mx1.freebsd.org (Postfix) with ESMTP id B61A0BF1; Mon, 11 Feb 2013 16:12:19 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKURkYYgRp8GqAW0NesCfc6pJa8DW0Ipkw@postini.com; Mon, 11 Feb 2013 08:12:20 PST Received: from PALHUB01.lsi.com (128.94.213.114) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 11 Feb 2013 11:12:29 -0500 Received: from inbexch02.lsi.com (135.36.98.40) by PALHUB01.lsi.com (128.94.213.114) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 11 Feb 2013 11:12:17 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Mon, 11 Feb 2013 21:42:14 +0530 From: "Desai, Kashyap" To: "Kenneth D. Merry" Date: Mon, 11 Feb 2013 21:42:11 +0530 Subject: RE: Max Queue depth of HBA limited to 256 ? Thread-Topic: Max Queue depth of HBA limited to 256 ? Thread-Index: Ac4D5iOPnb8e42+1TjmX//UNm9rDLAEjBB1Q Message-ID: References: <20130121170529.GA64188@nargothrond.kdm.org> <20130205211642.GA75343@nargothrond.kdm.org> In-Reply-To: <20130205211642.GA75343@nargothrond.kdm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-scsi@freebsd.org" , "McConnell, Stephen" , "jhb@freebsd.org" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 16:12:20 -0000 Ken: I am still not able to pump more than 256 command. (This time I simulated s= imilar to your setup. I tried driver) For example: dev.mps.0.%desc: LSI SAS2008 dev.mps.0.%driver: mps dev.mps.0.%location: slot=3D0 function=3D0 dev.mps.0.%pnpinfo: vendor=3D0x1000 device=3D0x0072 subvendor=3D0x1000 subd= evice=3D0x0072 class=3D0x010700 dev.mps.0.%parent: pci2 dev.mps.0.debug_level: 0 dev.mps.0.disable_msix: 0 dev.mps.0.disable_msi: 0 dev.mps.0.firmware_version: 14.00.00.00 dev.mps.0.driver_version: 14.00.00.01-fbsd dev.mps.0.io_cmds_active: 256 dev.mps.0.io_cmds_highwater: 256 dev.mps.0.chain_free: 2048 dev.mps.0.chain_free_lowwater: 2047 dev.mps.0.max_chains: 2048 dev.mps.0.chain_alloc_fail: 0 io_cmds_highwater =3D 256 Here is the system information: at scbus0 target 10 lun 0 (pass3,da1) at scbus0 target 11 lun 0 (pass4,da2) at scbus0 target 12 lun 0 (pass5,da3) at scbus0 target 13 lun 0 (pass2,da0) at scbus0 target 14 lun 0 (pass6,= ses0) -- Expander Running 128 dd on each target using small shell scripts: --------------------------------------------------------- #!/bin/sh max=3D128 for i in `seq 1 $max` do dd if=3D/dev/da0 of=3D/dev/null bs=3D1m & dd if=3D/dev/da1 of=3D/dev/null bs=3D1m & dd if=3D/dev/da2 of=3D/dev/null bs=3D1m & dd if=3D/dev/da3 of=3D/dev/null bs=3D1m & echo "$i" done ---------------------------------------------------------------------------= ------------------ The individual drives logs:=20 dhcp-135-24-192-146# camcontrol tags da3 -v (pass5:mps0:0:12:0): dev_openings 248 (pass5:mps0:0:12:0): dev_active 7 (pass5:mps0:0:12:0): devq_openings 248 (pass5:mps0:0:12:0): devq_queued 0 (pass5:mps0:0:12:0): held 0 (pass5:mps0:0:12:0): mintags 2 (pass5:mps0:0:12:0): maxtags 255 dhcp-135-24-192-146# camcontrol tags da2 -v (pass4:mps0:0:11:0): dev_openings 155 (pass4:mps0:0:11:0): dev_active 100 (pass4:mps0:0:11:0): devq_openings 155 (pass4:mps0:0:11:0): devq_queued 0 (pass4:mps0:0:11:0): held 0 (pass4:mps0:0:11:0): mintags 2 (pass4:mps0:0:11:0): maxtags 255 dhcp-135-24-192-146# camcontrol tags da1 -v (pass3:mps0:0:10:0): dev_openings 145 (pass3:mps0:0:10:0): dev_active 110 (pass3:mps0:0:10:0): devq_openings 145 (pass3:mps0:0:10:0): devq_queued 0 (pass3:mps0:0:10:0): held 0 (pass3:mps0:0:10:0): mintags 2 (pass3:mps0:0:10:0): maxtags 255 dhcp-135-24-192-146# camcontrol tags da0 -v (pass2:mps0:0:13:0): dev_openings 233 (pass2:mps0:0:13:0): dev_active 22 (pass2:mps0:0:13:0): devq_openings 233 (pass2:mps0:0:13:0): devq_queued 0 (pass2:mps0:0:13:0): held 0 (pass2:mps0:0:13:0): mintags 2 (pass2:mps0:0:13:0): maxtags 255 Is there any change in latest Upstream kernel ? Mine is not very much lates= t FreeBSD OS..! I will try with latest upstream freebsd OS.=20 ` Kashyap > -----Original Message----- > From: Kenneth D. Merry [mailto:ken@freebsd.org] > Sent: Wednesday, February 06, 2013 2:47 AM > To: Desai, Kashyap > Cc: freebsd-scsi@freebsd.org; jhb@freebsd.org; McConnell, Stephen > Subject: Re: Max Queue depth of HBA limited to 256 ? >=20 >=20 > I'm able to get more than 255 commands outstanding to the controller in > my configuration. >=20 > For example: >=20 > dev.mps.0.%desc: LSI SAS2116 > dev.mps.0.%driver: mps > dev.mps.0.%location: slot=3D6 function=3D0 handle=3D\_SB_.PCI0.S30_ > dev.mps.0.%pnpinfo: vendor=3D0x1000 device=3D0x0064 subvendor=3D0x1000 > subdevice=3D0x30c0 class=3D0x010700 > dev.mps.0.%parent: pci0 > dev.mps.0.debug_level: 4 > dev.mps.0.disable_msix: 0 > dev.mps.0.disable_msi: 0 > dev.mps.0.firmware_version: 13.00.01.00 > dev.mps.0.driver_version: 14.00.00.01-fbsd > dev.mps.0.io_cmds_active: 442 > dev.mps.0.io_cmds_highwater: 464 > dev.mps.0.chain_free: 354 > dev.mps.0.chain_free_lowwater: 181 > dev.mps.0.max_chains: 2048 > dev.mps.0.chain_alloc_fail: 0 >=20 > io_cmds_highwater is 464. Can you get more than 255 commands > outstanding if you use more than 1 target? >=20 > This is with 272 'dd' processes doing 1MB reads to 16 2TB and 3TB SAS > drives behind 2 3Gb Maxim expanders: >=20 > at scbus2 target 144 lun 0 > (pass4,sg4,da0) > at scbus2 target 145 lun 0 > (pass5,sg5,da1) > at scbus2 target 146 lun 0 > (pass6,sg6,da2) > at scbus2 target 147 lun 0 > (pass7,sg7,da3) > at scbus2 target 148 lun 0 > (pass8,sg8,da4) > at scbus2 target 149 lun 0 > (pass9,sg9,da5) > at scbus2 target 150 lun 0 > (pass10,sg10,da6) > at scbus2 target 151 lun 0 > (pass11,sg11,da7) > at scbus2 target 152 lun 0 > (pass12,sg12,da8) > at scbus2 target 153 lun 0 > (pass13,sg13,da9) > at scbus2 target 154 lun 0 > (pass14,sg14,da10) > at scbus2 target 155 lun 0 > (pass15,sg15,da11) > at scbus2 target 156 lun 0 > (pass16,sg16,da12) > at scbus2 target 157 lun 0 > (pass17,sg17,da13) > at scbus2 target 158 lun 0 > (pass18,sg18,da14) > at scbus2 target 159 lun 0 > (pass19,sg19,da15) >=20 > i.e. 17 iterations of this: >=20 > ((i=3D0)); while [ $i -le 15 ]; do dd if=3D/dev/da$i of=3D/dev/null bs=3D= 1m & > ((i++)); done >=20 > The individual drives see varying numbers of tags, but nowhere near the > maximum: >=20 > [root@storage-domain ~]# camcontrol tags da15 -v > (pass19:mps0:0:159:0): dev_openings 230 > (pass19:mps0:0:159:0): dev_active 25 > (pass19:mps0:0:159:0): devq_openings 230 > (pass19:mps0:0:159:0): devq_queued 0 > (pass19:mps0:0:159:0): held 0 > (pass19:mps0:0:159:0): mintags 2 > (pass19:mps0:0:159:0): maxtags 255 >=20 > What kind of drive is the target? >=20 > Ken >=20 > On Wed, Jan 23, 2013 at 00:44:31 +0530, Desai, Kashyap wrote: > > LSI h/w needs more outstanding command in FW to get better Perf counts > compare to other OS. > > > > Please suggest if whatever I have been observed is limitation from > FreeBSD or we can tune it in Driver ? > > My goals is to pump ~1000 outstanding IOs to the HBA. I see that it > never goes beyond 255. > > > > Thanks, > > Kashyap > > > > > -----Original Message----- > > > From: owner-freebsd-scsi@freebsd.org [mailto:owner-freebsd- > > > scsi@freebsd.org] On Behalf Of Desai, Kashyap > > > Sent: Monday, January 21, 2013 11:18 PM > > > To: Kenneth D. Merry > > > Cc: freebsd-scsi@freebsd.org; jhb@freebsd.org; McConnell, Stephen > > > Subject: RE: Max Queue depth of HBA limited to 256 ? > > > > > > > > > > > > > -----Original Message----- > > > > From: Kenneth D. Merry [mailto:ken@freebsd.org] > > > > Sent: Monday, January 21, 2013 10:35 PM > > > > To: Desai, Kashyap > > > > Cc: freebsd-scsi@freebsd.org; McConnell, Stephen; Saxena, Sumit; > > > > jhb@freebsd.org > > > > Subject: Re: Max Queue depth of HBA limited to 256 ? > > > > > > > > On Mon, Jan 21, 2013 at 20:15:47 +0530, Desai, Kashyap wrote: > > > > > Hi, > > > > > > > > > > I was trying to check few things on LSI controller, where we > > > > > have more > > > > than 256 queue depth support. > > > > > I added default maxtags in scsi/scsi_xpt.c as below. (Because I > > > > > don't > > > > want mattags to restrict any outstanding commands the LSI HBA. > > > > > > > > > > { > > > > > /* Default tagged queuing parameters for all devices */ > > > > > { > > > > > T_ANY, SIP_MEDIA_REMOVABLE|SIP_MEDIA_FIXED, > > > > > /*vendor*/"*", /*product*/"*", /*revision*/"*" > > > > > }, > > > > > /*quirks*/0, /*mintags*/2, /*maxtags*/1024 <--- > Default > > > > maxtags were 256. I increase it to 10234 > > > > > }, > > > > > > > > > > > > > > > LSI's SAS-HBA and MR-HBA can support more than 256 outstanding > > > > commands in Firmware. But due to some reason, I am not able to > > > > pump more than 256 outstanding commands to the HBA. > > > > > > > > > > I used "rawio -p 256 /dev/da1" and more /dev/dax in loop. I have > > > > sysctl parameter in Driver to display outstanding "FW commands". > > > > Max value for FW outstanding only goes up to 256. > > > > > > > > > > Also from some other mail thread Subject "mfi driver > > > > > performance", I > > > > found that folks talk about tuning queue depth _but_ nobody > > > > discussed to increase it beyond 256. Is there any limitation in > FreeBSD ? > > > > > > > > > > > > > As Jim pointed out, one thing to check is the values passed into > > > > cam_sim_alloc(). In the case of the mps(4) driver, the > > > > calculation is in mps_attach(): > > > > > > > > sc->num_reqs =3D MIN(MPS_REQ_FRAMES, sc->facts->RequestCredit); > > > > > > > > What is reported for the RequestCredit on this particular adapter? > > > > > > > > The other question is, what does 'camcontrol tags daX -v' show > > > > when you are running the test? > > > > > > Below is output of camcontrol tags da1 -v. > > > > > > dhcp-135-24-192-127# camcontrol tags da13 -v > > > (pass13:mrsas0:0:13:0): dev_openings 1024 > > > (pass13:mrsas0:0:13:0): dev_active 0 > > > (pass13:mrsas0:0:13:0): devq_openings 1024 > > > (pass13:mrsas0:0:13:0): devq_queued 0 > > > (pass13:mrsas0:0:13:0): held 0 > > > (pass13:mrsas0:0:13:0): mintags 2 > > > (pass13:mrsas0:0:13:0): maxtags 1024 > > > dhcp-135-24-192-127# camcontrol tags da1 -v > > > (pass1:mrsas0:0:1:0): dev_openings 1024 > > > (pass1:mrsas0:0:1:0): dev_active 0 > > > (pass1:mrsas0:0:1:0): devq_openings 1024 > > > (pass1:mrsas0:0:1:0): devq_queued 0 > > > (pass1:mrsas0:0:1:0): held 0 > > > (pass1:mrsas0:0:1:0): mintags 2 > > > (pass1:mrsas0:0:1:0): maxtags 1024 > > > > > > Value 1024 is hard coded for my testing. In MegaRaid controller and > > > SAS- HBA Driver read max commands value from FW. > > > Similar to "RequestCredit".. Different FW has different value, but > > > they are every time above 255. > > > > > > > > > When I run IOs dev_active stays in range of 0-255 only. See below > > > output when I run IOs on /dev/da1 and /dev/da13. I expect total > > > dev_openings should go beyond 255, which is not happening. > > > > > > > > > dhcp-135-24-192-127# camcontrol tags da1 -v > > > (pass1:mrsas0:0:1:0): dev_openings 832 > > > (pass1:mrsas0:0:1:0): dev_active 192 > > > (pass1:mrsas0:0:1:0): devq_openings 832 > > > (pass1:mrsas0:0:1:0): devq_queued 0 > > > (pass1:mrsas0:0:1:0): held 0 > > > (pass1:mrsas0:0:1:0): mintags 2 > > > (pass1:mrsas0:0:1:0): maxtags 1024 > > > dhcp-135-24-192-127# camcontrol tags da13 -v > > > (pass13:mrsas0:0:13:0): dev_openings 881 > > > (pass13:mrsas0:0:13:0): dev_active 143 > > > (pass13:mrsas0:0:13:0): devq_openings 881 > > > (pass13:mrsas0:0:13:0): devq_queued 0 > > > (pass13:mrsas0:0:13:0): held 0 > > > (pass13:mrsas0:0:13:0): mintags 2 > > > (pass13:mrsas0:0:13:0): maxtags 1024 > > > > > > > > > > > > > > > Jim: > > > Below is my API call. I have hard code value "queue_depth" =3D 1024 > > > > > > sc->sim_0 =3D cam_sim_alloc(mrsas_action, mrsas_poll, "mrsas", sc= , > > > device_get_unit(sc->mrsas_dev), &sc->sim_lock, queue_depth, > > > queue_depth, devq); > > > > > > ~ Kashyap > > > > > > > > > > > Ken > > > > -- > > > > Kenneth Merry > > > > ken@FreeBSD.ORG > > > _______________________________________________ > > > freebsd-scsi@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > > > To unsubscribe, send any mail to "freebsd-scsi- > unsubscribe@freebsd.org" >=20 > -- > Kenneth Merry > ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Wed Feb 13 14:11:22 2013 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A6713456; Wed, 13 Feb 2013 14:11:22 +0000 (UTC) (envelope-from xenophon@irtnog.org) Received: from mx1.irtnog.org (rrcs-24-123-13-61.central.biz.rr.com [24.123.13.61]) by mx1.freebsd.org (Postfix) with ESMTP id 4B19168F; Wed, 13 Feb 2013 14:11:22 +0000 (UTC) Received: from cinep001bsdgw.irtnog.net (localhost [127.0.0.1]) by mx1.irtnog.org (Postfix) with ESMTP id E12191C76F; Wed, 13 Feb 2013 09:11:20 -0500 (EST) X-Virus-Scanned: amavisd-new at irtnog.org Received: from mx1.irtnog.org ([127.0.0.1]) by cinep001bsdgw.irtnog.net (mx1.irtnog.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxQwCU_Nlg1k; Wed, 13 Feb 2013 09:11:11 -0500 (EST) Received: from cinip100ntsbs.irtnog.net (cinip100ntsbs.irtnog.net [10.63.1.100]) by mx1.irtnog.org (Postfix) with ESMTP; Wed, 13 Feb 2013 09:11:11 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: kern/151564: [ciss] ciss(4) should increase CISS_MAX_LOGICAL to 107 Date: Wed, 13 Feb 2013 09:11:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <201301120120.r0C1K1Hp024632@freefall.freebsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: kern/151564: [ciss] ciss(4) should increase CISS_MAX_LOGICAL to 107 Thread-Index: Ac3wYw5p+f6y/3KZTPqjLGzp0heCnQZjuKEA References: <201301120120.r0C1K1Hp024632@freefall.freebsd.org> From: "Matthew X. Economou" To: Cc: peter@FreeBSD.org, leon.kos@lecad.fs.uni-lj.si, bug-followup@FreeBSD.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:11:22 -0000 Sean, After I applied your patch to FreeBSD 9.1, the server locks up during boot. I'm working on attaching a serial console in order to capture the boot log. Best wishes, Matthew --=20 I FIGHT FOR THE USERS > -----Original Message----- > From: owner-freebsd-scsi@freebsd.org [mailto:owner-freebsd- > scsi@freebsd.org] On Behalf Of Sean Bruno > Sent: Friday, January 11, 2013 8:20 PM > To: freebsd-scsi@FreeBSD.org > Subject: Re: kern/151564: [ciss] ciss(4) should increase > CISS_MAX_LOGICAL to 107 >=20 > The following reply was made to PR kern/151564; it has been noted by > GNATS. >=20 > From: Sean Bruno > To: bug-followup@FreeBSD.org, leon.kos@lecad.fs.uni-lj.si > Cc: peter > Subject: Re: kern/151564: [ciss] ciss(4) should increase > CISS_MAX_LOGICAL > to 107 > Date: Fri, 11 Jan 2013 17:17:51 -0800 >=20 > --=3D-VU6ICzSz8eqrj1bn7pu+ > Content-Type: text/plain; charset=3D"UTF-8" > Content-Transfer-Encoding: 7bit >=20 > ok, fixed on the 6i and older with the attached patch. Try this one > instead, basically I had a typo in a variable name and I was making core > logic decisions in boot_verbose code. :-) >=20 > this also means, I'm probably going to revert svn r242089 as it might > not be the right thing to do, but impossible to hit on older > controllers. >=20 > ciss0: port 0x4000-0x40ff mem > 0xfdff0000-0xfdff1fff,0xfdf80000-0xfdfbffff irq 51 at device 3.0 on pci4 > ciss0: PERFORMANT Transport > ciss0: got 0 MSI messages] > ioapic2: routing intpin 3 (PCI IRQ 51) to lapic 0 vector 52 > ciss0: using 1024 of 1024 available commands > ciss0: 1 logical drive configured > ciss0: firmware 2.26 > ciss0: 2 SCSI channels > ciss0: signature 'CISS' > ciss0: valence 1 > ciss0: supported I/O methods 0x80000006 > ciss0: active I/O method 0x5 > ciss0: 4G page base 0x00000000 > ciss0: interrupt coalesce delay 0us > ciss0: interrupt coalesce count 16 > ciss0: max outstanding commands 1024 > ciss0: bus types 0x2 > ciss0: server name '' > ciss0: heartbeat 0x1000008d > ciss0: max logical logical volumes: 63 > ciss0: max physical disks supported: 1024 > ciss0: max physical disks per logical volume: 0 > ciss0: 7 physical devices > ciss0: 1 logical drive > ciss0: logical drive (b0t0): RAID 1(1+0), 103936MB online >=20 >=20 > --=3D-VU6ICzSz8eqrj1bn7pu+ > Content-Disposition: attachment; > filename=3D"ciss_probe_logical_physical.diff" > Content-Type: text/x-patch; = name=3D"ciss_probe_logical_physical.diff"; > charset=3D"UTF-8" > Content-Transfer-Encoding: 7bit >=20 > --- //depot/yahoo/ybsd_9/src/sys/dev/ciss/ciss.c 2012-03-17 > 00:14:40.000000000 0000 > +++ /home/seanbru/ybsd_9/sys/dev/ciss/ciss.c 2012-03-17 > 00:14:40.000000000 0000 > @@ -1202,13 +1202,21 @@ > /* XXX only really required for old 5300 adapters? */ > sc->ciss_flags |=3D CISS_FLAG_BMIC_ABORT; >=20 > + /* > + * Earlier controller specs do not contain these config > + * entries, so assume that a 0 means its old and assign > + * these values to the defaults that were established > + * when this driver was developed for them > + */ > + if (sc->ciss_cfg->max_logical_supported =3D=3D 0) > + sc->ciss_cfg->max_logical_supported =3D CISS_MAX_LOGICAL; > + if (sc->ciss_cfg->max_physical_supported =3D=3D 0) > + sc->ciss_cfg->max_physical_supported =3D > CISS_MAX_PHYSICAL; > /* print information */ > if (bootverbose) { > -#if 0 /* XXX proxy volumes??? */ > ciss_printf(sc, " %d logical drive%s configured\n", > sc->ciss_id->configured_logical_drives, > (sc->ciss_id->configured_logical_drives =3D=3D 1) ? "" : > "s"); > -#endif > ciss_printf(sc, " firmware %4.4s\n", sc->ciss_id- > >running_firmware_revision); > ciss_printf(sc, " %d SCSI channels\n", sc->ciss_id- > >scsi_bus_count); >=20 > @@ -1231,6 +1239,9 @@ > "\20\1ultra2\2ultra3\10fibre1\11fibre2\n"); > ciss_printf(sc, " server name '%.16s'\n", sc->ciss_cfg- > >server_name); > ciss_printf(sc, " heartbeat 0x%x\n", sc->ciss_cfg->heartbeat); > + ciss_printf(sc, " max logical logical volumes: %d\n", sc- > >ciss_cfg->max_logical_supported); > + ciss_printf(sc, " max physical disks supported: %d\n", sc- > >ciss_cfg->max_physical_supported); > + ciss_printf(sc, " max physical disks per logical volume: %d\n", > sc->ciss_cfg->max_physical_per_logical); > } >=20 > out: > @@ -1318,7 +1329,7 @@ > break; > case CISS_CMD_STATUS_DATA_OVERRUN: > ciss_printf(sc, "WARNING: more units than driver limit > (%d)\n", > - CISS_MAX_LOGICAL); > + sc->ciss_cfg->max_logical_supported); > break; > default: > ciss_printf(sc, "error detecting logical drive configuration > (%s)\n", > @@ -1352,7 +1363,7 @@ > debug_called(1); >=20 > cll =3D ciss_report_luns(sc, CISS_OPCODE_REPORT_LOGICAL_LUNS, > - CISS_MAX_LOGICAL); > + sc->ciss_cfg->max_logical_supported); > if (cll =3D=3D NULL) { > error =3D ENXIO; > goto out; > @@ -1360,9 +1371,9 @@ >=20 > /* sanity-check reply */ > ndrives =3D (ntohl(cll->list_size) / sizeof(union ciss_device_address)); > - if ((ndrives < 0) || (ndrives > CISS_MAX_LOGICAL)) { > + if ((ndrives < 0) || (ndrives > sc->ciss_cfg- > >max_logical_supported)) { > ciss_printf(sc, "adapter claims to report absurd number of > logical drives (%d > %d)\n", > - ndrives, CISS_MAX_LOGICAL); > + ndrives, sc->ciss_cfg->max_logical_supported); > error =3D ENXIO; > goto out; > } > @@ -1385,19 +1396,20 @@ >=20 > for (i =3D 0; i <=3D sc->ciss_max_logical_bus; i++) { > sc->ciss_logical[i] =3D > - malloc(CISS_MAX_LOGICAL * sizeof(struct ciss_ldrive), > + malloc(sc->ciss_cfg->max_logical_supported * > + sizeof(struct ciss_ldrive), > CISS_MALLOC_CLASS, M_NOWAIT | M_ZERO); > if (sc->ciss_logical[i] =3D=3D NULL) { > error =3D ENXIO; > goto out; > } >=20 > - for (j =3D 0; j < CISS_MAX_LOGICAL; j++) > + for (j =3D 0; j < sc->ciss_cfg->max_logical_supported; j++) > sc->ciss_logical[i][j].cl_status =3D CISS_LD_NONEXISTENT; > } >=20 >=20 > - for (i =3D 0; i < CISS_MAX_LOGICAL; i++) { > + for (i =3D 0; i < sc->ciss_cfg->max_logical_supported; i++) { > if (i < ndrives) { > struct ciss_ldrive *ld; > int bus, target; > @@ -1439,7 +1451,7 @@ > target =3D 0; >=20 > cll =3D ciss_report_luns(sc, CISS_OPCODE_REPORT_PHYSICAL_LUNS, > - CISS_MAX_PHYSICAL); > + sc->ciss_cfg->max_physical_supported); > if (cll =3D=3D NULL) { > error =3D ENXIO; > goto out; > @@ -1982,7 +1994,7 @@ > bus_dma_tag_destroy(sc->ciss_parent_dmat); > if (sc->ciss_logical) { > for (i =3D 0; i <=3D sc->ciss_max_logical_bus; i++) { > - for (j =3D 0; j < CISS_MAX_LOGICAL; j++) { > + for (j =3D 0; j < sc->ciss_cfg->max_logical_supported; j++) { > if (sc->ciss_logical[i][j].cl_ldrive) > free(sc->ciss_logical[i][j].cl_ldrive, > CISS_MALLOC_CLASS); > if (sc->ciss_logical[i][j].cl_lstatus) > @@ -2965,9 +2977,9 @@ > cpi->hba_inquiry =3D PI_TAG_ABLE; /* XXX is this correct? > */ > cpi->target_sprt =3D 0; > cpi->hba_misc =3D 0; > - cpi->max_target =3D CISS_MAX_LOGICAL; > + cpi->max_target =3D sc->ciss_cfg->max_logical_supported; > cpi->max_lun =3D 0; /* 'logical drive' channel only */ > - cpi->initiator_id =3D CISS_MAX_LOGICAL; > + cpi->initiator_id =3D sc->ciss_cfg->max_logical_supported; > strncpy(cpi->sim_vid, "FreeBSD", SIM_IDLEN); > strncpy(cpi->hba_vid, "msmith@freebsd.org", HBA_IDLEN); > strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN); > @@ -3878,7 +3890,7 @@ > * drive address. > */ > cll =3D ciss_report_luns(sc, CISS_OPCODE_REPORT_LOGICAL_LUNS, > - CISS_MAX_LOGICAL); > + sc->ciss_cfg->max_logical_supported); > if (cll =3D=3D NULL) > return; >=20 > @@ -3889,7 +3901,7 @@ > * firmware. > */ > for (i =3D 0; i < sc->ciss_max_logical_bus; i++) { > - for (j =3D 0; j < CISS_MAX_LOGICAL; j++) { > + for (j =3D 0; j < sc->ciss_cfg->max_logical_supported; j++) { > ld =3D &sc->ciss_logical[i][j]; >=20 > if (ld->cl_update =3D=3D 0) > @@ -4058,7 +4070,7 @@ > * Rescan the physical lun list for new items > */ > cll =3D ciss_report_luns(sc, > CISS_OPCODE_REPORT_PHYSICAL_LUNS, > - CISS_MAX_PHYSICAL); > + sc->ciss_cfg- > >max_physical_supported); > if (cll =3D=3D NULL) { > ciss_printf(sc, "Warning, cannot get physical lun > list\n"); > break; > @@ -4306,7 +4318,7 @@ >=20 > "\20\1notify_ok\2control_open\3aborting\4running\21fake_s > ynch\22bmic_abort\n"); >=20 > for (i =3D 0; i < sc->ciss_max_logical_bus; i++) { > - for (j =3D 0; j < CISS_MAX_LOGICAL; j++) { > + for (j =3D 0; j < sc->ciss_cfg->max_logical_supported; j++) { > ciss_printf(sc, "LOGICAL DRIVE %d: ", i); > ciss_print_ldrive(sc, &sc->ciss_logical[i][j]); > } > --- //depot/yahoo/ybsd_9/src/sys/dev/ciss/cissreg.h 2011-11-02 > 23:46:55.000000000 0000 > +++ /home/seanbru/ybsd_9/sys/dev/ciss/cissreg.h 2011-11-02 > 23:46:55.000000000 0000 > @@ -425,6 +425,15 @@ > #define CISS_DRIVER_DAUGHTER_ATTACHED (1<<8) > #define CISS_DRIVER_SCSI_PREFETCH (1<<9) > u_int32_t max_sg_length; /* 31 in older firmware > */ > +/* > + * these fields appear in OpenCISS Spec 1.06 > + * http://cciss.sourceforge.net/#docs > + */ > + u_int32_t max_logical_supported; > + u_int32_t max_physical_supported; > + u_int32_t max_physical_per_logical; > + u_int32_t max_perfomant_mode_cmds; > + u_int32_t max_block_fetch_count; > } __packed; >=20 > /* >=20 > --=3D-VU6ICzSz8eqrj1bn7pu+-- >=20 > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi- > unsubscribe@freebsd.org" From owner-freebsd-scsi@FreeBSD.ORG Wed Feb 13 17:54:55 2013 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6AB0D87E; Wed, 13 Feb 2013 17:54:55 +0000 (UTC) (envelope-from xenophon+freebsd@irtnog.org) Received: from mx1.irtnog.org (rrcs-24-123-13-61.central.biz.rr.com [24.123.13.61]) by mx1.freebsd.org (Postfix) with ESMTP id ECAE23E5; Wed, 13 Feb 2013 17:54:54 +0000 (UTC) Received: from cinep001bsdgw.irtnog.net (localhost [127.0.0.1]) by mx1.irtnog.org (Postfix) with ESMTP id 2F4C61C981; Wed, 13 Feb 2013 12:54:54 -0500 (EST) X-Virus-Scanned: amavisd-new at irtnog.org Received: from mx1.irtnog.org ([127.0.0.1]) by cinep001bsdgw.irtnog.net (mx1.irtnog.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXeZr7qNg7IG; Wed, 13 Feb 2013 12:54:49 -0500 (EST) Received: from cinip100ntsbs.irtnog.net (cinip100ntsbs.irtnog.net [10.63.1.100]) by mx1.irtnog.org (Postfix) with ESMTP; Wed, 13 Feb 2013 12:54:49 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: kern/151564: [ciss] ciss(4) should increase CISS_MAX_LOGICAL to 107 Date: Wed, 13 Feb 2013 12:54:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: kern/151564: [ciss] ciss(4) should increase CISS_MAX_LOGICAL to 107 Thread-Index: Ac3wYw5p+f6y/3KZTPqjLGzp0heCnQZjuKEAAAhJK3A= References: <201301120120.r0C1K1Hp024632@freefall.freebsd.org> From: "xenophon\\+freebsd" To: Cc: leon.kos@lecad.fs.uni-lj.si, peter@FreeBSD.org, bug-followup@FreeBSD.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:54:55 -0000 OK, I captured the boot log: https://web.irtnog.org/~xenophon/pastebin/freebsd-kernel-boot-log-201302 1300 --=20 I FIGHT FOR THE USERS > -----Original Message----- > From: owner-freebsd-scsi@freebsd.org [mailto:owner-freebsd- > scsi@freebsd.org] On Behalf Of Matthew X. Economou > Sent: Wednesday, February 13, 2013 9:11 AM > To: freebsd-scsi@FreeBSD.org > Cc: peter@FreeBSD.org; leon.kos@lecad.fs.uni-lj.si; bug- > followup@FreeBSD.org > Subject: RE: kern/151564: [ciss] ciss(4) should increase > CISS_MAX_LOGICAL to 107 >=20 > Sean, >=20 > After I applied your patch to FreeBSD 9.1, the server locks up during > boot. I'm working on attaching a serial console in order to capture the > boot log. >=20 > Best wishes, > Matthew >=20 > -- > I FIGHT FOR THE USERS >=20 >=20 > > -----Original Message----- > > From: owner-freebsd-scsi@freebsd.org [mailto:owner-freebsd- > > scsi@freebsd.org] On Behalf Of Sean Bruno > > Sent: Friday, January 11, 2013 8:20 PM > > To: freebsd-scsi@FreeBSD.org > > Subject: Re: kern/151564: [ciss] ciss(4) should increase > > CISS_MAX_LOGICAL to 107 > > > > The following reply was made to PR kern/151564; it has been noted > by > > GNATS. > > > > From: Sean Bruno > > To: bug-followup@FreeBSD.org, leon.kos@lecad.fs.uni-lj.si > > Cc: peter > > Subject: Re: kern/151564: [ciss] ciss(4) should increase > > CISS_MAX_LOGICAL > > to 107 > > Date: Fri, 11 Jan 2013 17:17:51 -0800 > > > > --=3D-VU6ICzSz8eqrj1bn7pu+ > > Content-Type: text/plain; charset=3D"UTF-8" > > Content-Transfer-Encoding: 7bit > > > > ok, fixed on the 6i and older with the attached patch. Try this one > > instead, basically I had a typo in a variable name and I was making > core > > logic decisions in boot_verbose code. :-) > > > > this also means, I'm probably going to revert svn r242089 as it might > > not be the right thing to do, but impossible to hit on older > > controllers. > > > > ciss0: port 0x4000-0x40ff mem > > 0xfdff0000-0xfdff1fff,0xfdf80000-0xfdfbffff irq 51 at device 3.0 on > pci4 > > ciss0: PERFORMANT Transport > > ciss0: got 0 MSI messages] > > ioapic2: routing intpin 3 (PCI IRQ 51) to lapic 0 vector 52 > > ciss0: using 1024 of 1024 available commands > > ciss0: 1 logical drive configured > > ciss0: firmware 2.26 > > ciss0: 2 SCSI channels > > ciss0: signature 'CISS' > > ciss0: valence 1 > > ciss0: supported I/O methods 0x80000006 > > ciss0: active I/O method 0x5 > > ciss0: 4G page base 0x00000000 > > ciss0: interrupt coalesce delay 0us > > ciss0: interrupt coalesce count 16 > > ciss0: max outstanding commands 1024 > > ciss0: bus types 0x2 > > ciss0: server name '' > > ciss0: heartbeat 0x1000008d > > ciss0: max logical logical volumes: 63 > > ciss0: max physical disks supported: 1024 > > ciss0: max physical disks per logical volume: 0 > > ciss0: 7 physical devices > > ciss0: 1 logical drive > > ciss0: logical drive (b0t0): RAID 1(1+0), 103936MB online > > > > > > --=3D-VU6ICzSz8eqrj1bn7pu+ > > Content-Disposition: attachment; > > filename=3D"ciss_probe_logical_physical.diff" > > Content-Type: text/x-patch; > name=3D"ciss_probe_logical_physical.diff"; > > charset=3D"UTF-8" > > Content-Transfer-Encoding: 7bit > > > > --- //depot/yahoo/ybsd_9/src/sys/dev/ciss/ciss.c 2012-03-17 > > 00:14:40.000000000 0000 > > +++ /home/seanbru/ybsd_9/sys/dev/ciss/ciss.c 2012-03-17 > > 00:14:40.000000000 0000 > > @@ -1202,13 +1202,21 @@ > > /* XXX only really required for old 5300 adapters? */ > > sc->ciss_flags |=3D CISS_FLAG_BMIC_ABORT; > > > > + /* > > + * Earlier controller specs do not contain these config > > + * entries, so assume that a 0 means its old and assign > > + * these values to the defaults that were established > > + * when this driver was developed for them > > + */ > > + if (sc->ciss_cfg->max_logical_supported =3D=3D 0) > > + sc->ciss_cfg->max_logical_supported =3D CISS_MAX_LOGICAL; > > + if (sc->ciss_cfg->max_physical_supported =3D=3D 0) > > + sc->ciss_cfg->max_physical_supported =3D > > CISS_MAX_PHYSICAL; > > /* print information */ > > if (bootverbose) { > > -#if 0 /* XXX proxy volumes??? */ > > ciss_printf(sc, " %d logical drive%s configured\n", > > sc->ciss_id->configured_logical_drives, > > (sc->ciss_id->configured_logical_drives =3D=3D 1) ? "" : > > "s"); > > -#endif > > ciss_printf(sc, " firmware %4.4s\n", sc->ciss_id- > > >running_firmware_revision); > > ciss_printf(sc, " %d SCSI channels\n", sc->ciss_id- > > >scsi_bus_count); > > > > @@ -1231,6 +1239,9 @@ > > "\20\1ultra2\2ultra3\10fibre1\11fibre2\n"); > > ciss_printf(sc, " server name '%.16s'\n", sc->ciss_cfg- > > >server_name); > > ciss_printf(sc, " heartbeat 0x%x\n", sc->ciss_cfg->heartbeat); > > + ciss_printf(sc, " max logical logical volumes: %d\n", > sc- > > >ciss_cfg->max_logical_supported); > > + ciss_printf(sc, " max physical disks supported: %d\n", > sc- > > >ciss_cfg->max_physical_supported); > > + ciss_printf(sc, " max physical disks per logical > volume: %d\n", > > sc->ciss_cfg->max_physical_per_logical); > > } > > > > out: > > @@ -1318,7 +1329,7 @@ > > break; > > case CISS_CMD_STATUS_DATA_OVERRUN: > > ciss_printf(sc, "WARNING: more units than driver limit > > (%d)\n", > > - CISS_MAX_LOGICAL); > > + sc->ciss_cfg->max_logical_supported); > > break; > > default: > > ciss_printf(sc, "error detecting logical drive configuration > > (%s)\n", > > @@ -1352,7 +1363,7 @@ > > debug_called(1); > > > > cll =3D ciss_report_luns(sc, CISS_OPCODE_REPORT_LOGICAL_LUNS, > > - CISS_MAX_LOGICAL); > > + sc->ciss_cfg->max_logical_supported); > > if (cll =3D=3D NULL) { > > error =3D ENXIO; > > goto out; > > @@ -1360,9 +1371,9 @@ > > > > /* sanity-check reply */ > > ndrives =3D (ntohl(cll->list_size) / sizeof(union > ciss_device_address)); > > - if ((ndrives < 0) || (ndrives > CISS_MAX_LOGICAL)) { > > + if ((ndrives < 0) || (ndrives > sc->ciss_cfg- > > >max_logical_supported)) { > > ciss_printf(sc, "adapter claims to report absurd number of > > logical drives (%d > %d)\n", > > - ndrives, CISS_MAX_LOGICAL); > > + ndrives, sc->ciss_cfg->max_logical_supported); > > error =3D ENXIO; > > goto out; > > } > > @@ -1385,19 +1396,20 @@ > > > > for (i =3D 0; i <=3D sc->ciss_max_logical_bus; i++) { > > sc->ciss_logical[i] =3D > > - malloc(CISS_MAX_LOGICAL * sizeof(struct ciss_ldrive), > > + malloc(sc->ciss_cfg->max_logical_supported * > > + sizeof(struct ciss_ldrive), > > CISS_MALLOC_CLASS, M_NOWAIT | M_ZERO); > > if (sc->ciss_logical[i] =3D=3D NULL) { > > error =3D ENXIO; > > goto out; > > } > > > > - for (j =3D 0; j < CISS_MAX_LOGICAL; j++) > > + for (j =3D 0; j < sc->ciss_cfg->max_logical_supported; j++) > > sc->ciss_logical[i][j].cl_status =3D CISS_LD_NONEXISTENT; > > } > > > > > > - for (i =3D 0; i < CISS_MAX_LOGICAL; i++) { > > + for (i =3D 0; i < sc->ciss_cfg->max_logical_supported; i++) { > > if (i < ndrives) { > > struct ciss_ldrive *ld; > > int bus, target; > > @@ -1439,7 +1451,7 @@ > > target =3D 0; > > > > cll =3D ciss_report_luns(sc, > CISS_OPCODE_REPORT_PHYSICAL_LUNS, > > - CISS_MAX_PHYSICAL); > > + sc->ciss_cfg->max_physical_supported); > > if (cll =3D=3D NULL) { > > error =3D ENXIO; > > goto out; > > @@ -1982,7 +1994,7 @@ > > bus_dma_tag_destroy(sc->ciss_parent_dmat); > > if (sc->ciss_logical) { > > for (i =3D 0; i <=3D sc->ciss_max_logical_bus; i++) { > > - for (j =3D 0; j < CISS_MAX_LOGICAL; j++) { > > + for (j =3D 0; j < sc->ciss_cfg->max_logical_supported; j++) { > > if (sc->ciss_logical[i][j].cl_ldrive) > > free(sc->ciss_logical[i][j].cl_ldrive, > > CISS_MALLOC_CLASS); > > if (sc->ciss_logical[i][j].cl_lstatus) > > @@ -2965,9 +2977,9 @@ > > cpi->hba_inquiry =3D PI_TAG_ABLE; /* XXX is this correct? > > */ > > cpi->target_sprt =3D 0; > > cpi->hba_misc =3D 0; > > - cpi->max_target =3D CISS_MAX_LOGICAL; > > + cpi->max_target =3D sc->ciss_cfg->max_logical_supported; > > cpi->max_lun =3D 0; /* 'logical drive' channel only > */ > > - cpi->initiator_id =3D CISS_MAX_LOGICAL; > > + cpi->initiator_id =3D sc->ciss_cfg->max_logical_supported; > > strncpy(cpi->sim_vid, "FreeBSD", SIM_IDLEN); > > strncpy(cpi->hba_vid, "msmith@freebsd.org", HBA_IDLEN); > > strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN); > > @@ -3878,7 +3890,7 @@ > > * drive address. > > */ > > cll =3D ciss_report_luns(sc, CISS_OPCODE_REPORT_LOGICAL_LUNS, > > - CISS_MAX_LOGICAL); > > + sc->ciss_cfg->max_logical_supported); > > if (cll =3D=3D NULL) > > return; > > > > @@ -3889,7 +3901,7 @@ > > * firmware. > > */ > > for (i =3D 0; i < sc->ciss_max_logical_bus; i++) { > > - for (j =3D 0; j < CISS_MAX_LOGICAL; j++) { > > + for (j =3D 0; j < sc->ciss_cfg->max_logical_supported; j++) { > > ld =3D &sc->ciss_logical[i][j]; > > > > if (ld->cl_update =3D=3D 0) > > @@ -4058,7 +4070,7 @@ > > * Rescan the physical lun list for new items > > */ > > cll =3D ciss_report_luns(sc, > > CISS_OPCODE_REPORT_PHYSICAL_LUNS, > > - CISS_MAX_PHYSICAL); > > + sc->ciss_cfg- > > >max_physical_supported); > > if (cll =3D=3D NULL) { > > ciss_printf(sc, "Warning, cannot get physical lun > > list\n"); > > break; > > @@ -4306,7 +4318,7 @@ > > > > "\20\1notify_ok\2control_open\3aborting\4running\21fake_s > > ynch\22bmic_abort\n"); > > > > for (i =3D 0; i < sc->ciss_max_logical_bus; i++) { > > - for (j =3D 0; j < CISS_MAX_LOGICAL; j++) { > > + for (j =3D 0; j < sc->ciss_cfg->max_logical_supported; j++) { > > ciss_printf(sc, "LOGICAL DRIVE %d: ", i); > > ciss_print_ldrive(sc, &sc->ciss_logical[i][j]); > > } > > --- //depot/yahoo/ybsd_9/src/sys/dev/ciss/cissreg.h 2011- > 11-02 > > 23:46:55.000000000 0000 > > +++ /home/seanbru/ybsd_9/sys/dev/ciss/cissreg.h 2011-11-02 > > 23:46:55.000000000 0000 > > @@ -425,6 +425,15 @@ > > #define CISS_DRIVER_DAUGHTER_ATTACHED (1<<8) > > #define CISS_DRIVER_SCSI_PREFETCH (1<<9) > > u_int32_t max_sg_length; /* 31 in older firmware > > */ > > +/* > > + * these fields appear in OpenCISS Spec 1.06 > > + * http://cciss.sourceforge.net/#docs > > + */ > > + u_int32_t max_logical_supported; > > + u_int32_t max_physical_supported; > > + u_int32_t max_physical_per_logical; > > + u_int32_t max_perfomant_mode_cmds; > > + u_int32_t max_block_fetch_count; > > } __packed; > > > > /* > > > > --=3D-VU6ICzSz8eqrj1bn7pu+-- > > > > _______________________________________________ > > freebsd-scsi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > > To unsubscribe, send any mail to "freebsd-scsi- > > unsubscribe@freebsd.org" > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi- > unsubscribe@freebsd.org" From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 14 13:25:58 2013 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3323CE11 for ; Thu, 14 Feb 2013 13:25:58 +0000 (UTC) (envelope-from sven@crashme.org) Received: from celaeno.tauri.mw.lg.virgo.supercluster.net (celaeno.tauri.mw.lg.virgo.supercluster.net [213.252.140.33]) by mx1.freebsd.org (Postfix) with ESMTP id DBF261FE for ; Thu, 14 Feb 2013 13:25:57 +0000 (UTC) Received: from miram.persei.mw.lg.virgo.supercluster.net ([213.252.140.37] helo=[192.168.20.6]) by celaeno.tauri.mw.lg.virgo.supercluster.net with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1U5yQP-0003F0-7d for freebsd-scsi@freebsd.org; Thu, 14 Feb 2013 13:00:29 +0000 Message-ID: <511CDFEE.10307@crashme.org> Date: Thu, 14 Feb 2013 14:00:30 +0100 From: Sven Brandenburg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: Re: Increase mps sequential read performance with ZFS/zvol References: <510E987C.4090509@oxit.fi> <510E9FD1.5070907@freebsd.org> <20130205023609.GA99100@FreeBSD.org> In-Reply-To: <20130205023609.GA99100@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 13:25:58 -0000 On 02/05/2013 03:36 AM, John wrote: [..] > Gmultipath is used to bind the disks such that each disk can be > addressed by either controller and the I/O balanced. > > The zfs pool consists of 24 mirrors, each pair one from each shelf. > The multipaths are rotated such that I/O is balanced between shelves > and controllers. [..] Not sure if this applicable to your problem but in a similar setup like yours, I found gmultipath in round-robin mode to be terrible for performance. Afaik the D2700 have their own caching controllers and may shield you from this, but if HBAs are directly connected to the disk, concurrent IO requests from two 'sides' via gmultipath seem to terrorize them, cutting effective read performance down by at least 75%. Try to switch gmultipath to active/passive. I bet its faster :) regards, Sven From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 15 09:02:54 2013 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 797A826F for ; Fri, 15 Feb 2013 09:02:54 +0000 (UTC) (envelope-from jackson4015@gmail.com) Received: from mail-ie0-x243.google.com (ie-in-x0243.1e100.net [IPv6:2607:f8b0:4001:c03::243]) by mx1.freebsd.org (Postfix) with ESMTP id 54EDDB25 for ; Fri, 15 Feb 2013 09:02:54 +0000 (UTC) Received: by mail-ie0-f195.google.com with SMTP id c11so2220507ieb.2 for ; Fri, 15 Feb 2013 01:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=WpwqYyn6KmfwmAzeRJgV70EJp5ZgQuHb3kBJs0OM+os=; b=NlDcAeJwO1QNTkBx6iOUO1BzYBHNuHx0Vd5WQAbq2LF0uDOEsSsnFYBNmmvWxfKNXL 6sgFQ6XDo8hYa1EGZ3f9A5FDyWyD7SYZkHnWNbEaDHXuRzuwlUgM/MJTD6bEVnDS3V/R FdMkY5pWJR4vixb7xewmcJ3jHzrPHZ18HWXaxoaDXw8SKkOLrblrw6BZ/efGyh4MRJJY 0hOHc34yguV8JX5u+oxniluwCjER7CIjdBJLX5QBF2EgD9wof0sEdPBY/wHDnIn+s2WE 7+eCx4LZkY03Ue1OfgFguLyS6uAixUMehF8T+C9KJSJi4ytQUhVjxMp9hnriNCNGYzS9 cyBw== MIME-Version: 1.0 X-Received: by 10.50.217.226 with SMTP id pb2mr1238949igc.31.1360918972976; Fri, 15 Feb 2013 01:02:52 -0800 (PST) Received: by 10.64.93.137 with HTTP; Fri, 15 Feb 2013 01:02:52 -0800 (PST) Date: Fri, 15 Feb 2013 17:02:52 +0800 Message-ID: Subject: Link rate problem of SAS HDD From: jackson wang To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 09:02:54 -0000 Hello,All. I have a SAS HDD,have some demands as following: 1.Use SCSI command to get the supported link rates,ex:1.5? 3.0? or 6.0 Gb/s; 2.Get current working link rate with SCSI CMD; 3.Need to downgrade 6.0gb/s to 3.0gb/s with SCSI CMD because some RAID card had bugs, so speed negotiation sometimes failed; I know many RAID cards have management tool:CLI,which could make it, but not all system install that tool, so using SCSI command is the only option. PLS help to give some advices. Thx! From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 15 16:08:18 2013 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 783D6B41 for ; Fri, 15 Feb 2013 16:08:18 +0000 (UTC) (envelope-from dgilbert@interlog.com) Received: from smtp.infotech.no (smtp.infotech.no [82.134.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id 3A9206DC for ; Fri, 15 Feb 2013 16:08:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id 308932041B8; Fri, 15 Feb 2013 16:59:07 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVIVLbk62y3n; Fri, 15 Feb 2013 16:59:01 +0100 (CET) Received: from [192.168.48.66] (unknown [98.143.98.44]) by smtp.infotech.no (Postfix) with ESMTPA id DFDE52041B0; Fri, 15 Feb 2013 16:59:00 +0100 (CET) Message-ID: <511E5B3C.8040400@interlog.com> Date: Fri, 15 Feb 2013 10:58:52 -0500 From: Douglas Gilbert User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: jackson wang Subject: Re: Link rate problem of SAS HDD References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dgilbert@interlog.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:08:18 -0000 On 13-02-15 04:02 AM, jackson wang wrote: > Hello,All. > > I have a SAS HDD,have some demands as following: > > 1.Use SCSI command to get the supported link rates,ex:1.5? 3.0? or 6.0 Gb/s; > 2.Get current working link rate with SCSI CMD; > 3.Need to downgrade 6.0gb/s to 3.0gb/s with SCSI CMD because some RAID > card had bugs, > so speed negotiation sometimes failed; > > I know many RAID cards have management tool:CLI,which could make it, > but not all system install that > tool, so using SCSI command is the only option. May I immodestly propose sdparm which is written for Linux but ported to FreeBSD (Solaris and Windoze). You will need to familiarize yourself with SAS "phy control and discover" mode page. Then see: http://sg.danny.cz/sg/sdparm.html There is an example in the Examples section. The items of interest are: Programmed minimum link rate and Programmed maximum link rate. By changing them and resetting the disk you constrain the following speed negotiation. You may also be interested in my sg3_utils (for general SCSI commands) and smp_utils (for SAS expanders) packages. They are also ported to FreeBSD. Doug Gilbert