From owner-freebsd-scsi@FreeBSD.ORG Sun Sep 23 14:08:20 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 261C71065670 for ; Sun, 23 Sep 2012 14:08:20 +0000 (UTC) (envelope-from Paul.Maulberger@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id 8C3DA8FC0C for ; Sun, 23 Sep 2012 14:08:19 +0000 (UTC) Received: (qmail 25909 invoked by uid 0); 23 Sep 2012 14:08:18 -0000 Received: from 31.17.21.234 by www008.gmx.net with HTTP; Sun, 23 Sep 2012 16:08:16 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Sun, 23 Sep 2012 16:08:16 +0200 From: "Paul Maulberger" Message-ID: <20120923140816.144270@gmx.net> MIME-Version: 1.0 To: freebsd-scsi@freebsd.org X-Authenticated: #143783428 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX19MPONJ771M8MYKV7dOrRyauP6B2WsNfO38tpuDPW 3iVN21BiOWUFwrQETBmm4Lo6Q2KkMaMFxlVQ== Content-Transfer-Encoding: 8bit X-GMX-UID: h3ItcD9ZeSEqUGWV+nwhCpB+IGRvb4AW Subject: Intel C600 SAS Controller + locate LED (SGPIO) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 14:08:20 -0000 Hi Folks, I like to manipulate the eight locate LED's of my internal enclosure. The following hardware is used: Mainboard: Supermicro X9DRi-F http://www.supermicro.com/products/motherboard/xeon/c600/x9dri-f.cfm Chassis: SC825TQ-R740LPB http://www.supermicro.com/products/chassis/2U/825/SC825TQ-R740LP.cfm Cable from Intel C602 SAS controller to backplane: SFF-8087 to 4xSATA cable with 8-pin SGPIO connector The backplane of the chassis has the MagaRAC MG9072 chip from AMI and is configured for SGPIO. I'm using FreeBSD 9.1 RC1. FreeBSD has a led driver to manipulate LED's: http://www.freebsd.org/cgi/man.cgi?query=led # ls -al /dev/led total 1 dr-xr-xr-x 2 root wheel 512 Sep 23 09:42 . dr-xr-xr-x 10 root wheel 512 Sep 23 09:42 .. crw------- 1 root wheel 0, 40 Sep 23 09:42 ahcich0.fault crw------- 1 root wheel 0, 39 Sep 23 09:42 ahcich0.locate crw------- 1 root wheel 0, 42 Sep 23 09:42 ahcich1.fault crw------- 1 root wheel 0, 41 Sep 23 09:42 ahcich1.locate crw------- 1 root wheel 0, 44 Sep 23 09:42 ahcich2.fault crw------- 1 root wheel 0, 43 Sep 23 09:42 ahcich2.locate crw------- 1 root wheel 0, 46 Sep 23 09:42 ahcich3.fault crw------- 1 root wheel 0, 45 Sep 23 09:42 ahcich3.locate crw------- 1 root wheel 0, 48 Sep 23 09:42 ahcich4.fault crw------- 1 root wheel 0, 47 Sep 23 09:42 ahcich4.locate crw------- 1 root wheel 0, 50 Sep 23 09:42 ahcich5.fault crw------- 1 root wheel 0, 49 Sep 23 09:42 ahcich5.locate crw------- 1 root wheel 0, 37 Sep 23 09:42 igb0 crw------- 1 root wheel 0, 38 Sep 23 09:42 igb1 Unfortunately there are no "C600" led devices. I found the functions 'scic_sgpio_*' in the file 'sys/dev/isci/scil/scic_sgpio.h'. The function 'scic_sgpio_hardware_initialize' is called in the file 'sys/dev/isci/scil/scic_sds_controller.c'. Although there is no call to 'scic_sgpio_set_led_state' or 'scic_sgpio_update_led_state' in the whole sources (/usr/src). Can somebody give me a hint how to manipulate the LED's? Regards Paul From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 24 08:49:42 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74021106566C for ; Mon, 24 Sep 2012 08:49:42 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by mx1.freebsd.org (Postfix) with ESMTP id DD5988FC1C for ; Mon, 24 Sep 2012 08:49:41 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKUGAen+v9o8APfdlMTK/hzpJSQe6vrQ8M@postini.com; Mon, 24 Sep 2012 01:49:41 PDT Received: from PALCAS01.lsi.com (128.94.213.117) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 24 Sep 2012 04:47:31 -0400 Received: from PALEXCH11.lsi.com (128.94.223.42) by PALCAS01.lsi.com (128.94.213.117) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 24 Sep 2012 04:48:24 -0400 Received: from inbexch02.lsi.com (135.36.98.40) by PALEXCH11.lsi.com (128.94.223.42) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 24 Sep 2012 04:48:23 -0400 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Mon, 24 Sep 2012 14:18:20 +0530 From: "Desai, Kashyap" To: Jason Keltz , "freebsd-scsi@freebsd.org" Date: Mon, 24 Sep 2012 14:18:18 +0530 Thread-Topic: mps target difference between FreeBSD 9 and 9.1 RC Thread-Index: Ac2Won9yT5g+ZBCeTTWqCLnSZ+TREgDjmNbw Message-ID: References: <505A2614.2000709@cse.yorku.ca> In-Reply-To: <505A2614.2000709@cse.yorku.ca> 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: Subject: RE: mps target difference between FreeBSD 9 and 9.1 RC X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 08:49:42 -0000 Jason: FreeBSD9.0 is very old driver where we don't have "mps_mapping.c". With mps= _mapping.c we are supporting different Target ID mapping which is main reas= on why you are seeing two different target ID behaviors in this case. We have major two mapping method. 1. enclosure slot mapping and 2. Device mapping. Depends upon what you have configured in FW Driver will behave accordingly. I would suggest to flash your Card completely and start from fresh with onl= y FreeBSD-9.1. do not compare FreeBSD-9.0 ` Kashyap > -----Original Message----- > From: owner-freebsd-scsi@freebsd.org [mailto:owner-freebsd- > scsi@freebsd.org] On Behalf Of Jason Keltz > Sent: Thursday, September 20, 2012 1:38 AM > To: freebsd-scsi@freebsd.org > Subject: mps target difference between FreeBSD 9 and 9.1 RC >=20 > I have a Dell R720 and a 24 x 2.5" Dell MD1220 JBOD. I have added dual > LSI 9205-8e, each connected to the same MD1220 array. Under FreeBSD > 9.0, if I do a "camcontrol devlist" (with every other disk removed), I > see: >=20 > at scbus0 target 0 lun 0 (pass0,da0) > at scbus0 target 2 lun 0 (pass1,da1) > at scbus0 target 4 lun 0 (pass2,da2) > at scbus0 target 6 lun 0 (pass3,da3) > at scbus0 target 8 lun 0 (pass4,da4) > at scbus0 target 10 lun 0 (pass5,da5) > at scbus0 target 36 lun 0 > (pass6,ses0) > at scbus1 target 12 lun 0 (pass7,da6) > at scbus1 target 14 lun 0 (pass8,da7) > at scbus1 target 16 lun 0 (pass9,da8) > at scbus1 target 18 lun 0 > (pass10,da9) > at scbus1 target 21 lun 0 > (pass11,da10) > at scbus1 target 22 lun 0 > (pass12,da11) > at scbus1 target 36 lun 0 > (pass13,ses1) > at scbus6 target 0 lun 0 (pass14,cd0) >=20 > ... which is what I would expect. If I do the same thing with any > pre-release/RC version of 9.1, I see: >=20 > at scbus0 target 34 lun 0 (pass0,da0) > at scbus0 target 36 lun 0 (pass1,da1) > at scbus0 target 38 lun 0 (pass2,da2) > at scbus0 target 39 lun 0 (pass3,da3) > at scbus0 target 41 lun 0 (pass4,da4) > at scbus0 target 43 lun 0 (pass5,da5) > at scbus0 target 45 lun 0 > (ses0,pass6) > at scbus1 target 21 lun 0 (pass7,da6) > at scbus1 target 23 lun 0 (pass8,da7) > at scbus1 target 24 lun 0 (pass9,da8) > at scbus1 target 26 lun 0 > (pass10,da9) > at scbus1 target 29 lun 0 > (pass11,da10) > at scbus1 target 31 lun 0 > (pass12,da11) > at scbus1 target 32 lun 0 > (ses1,pass13) > at scbus6 target 0 lun 0 (pass14,cd0) >=20 > In particular, note how the targets are starting at 34. I wonder if > someone might explain why? >=20 > I was considering using /boot/device.hints to hard-code the daX mapping > to avoid the use of "labels" for my volumes, but I wouldn't expect the > targets to change between the two releases. >=20 > Thanks for any information that you can provide.. >=20 > Jason. >=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 Mon Sep 24 11:07:32 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B7861065670 for ; Mon, 24 Sep 2012 11:07:31 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A6B6F8FC17 for ; Mon, 24 Sep 2012 11:07:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8OB7VQM086069 for ; Mon, 24 Sep 2012 11:07:31 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8OB7Vkc086067 for freebsd-scsi@FreeBSD.org; Mon, 24 Sep 2012 11:07:31 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Sep 2012 11:07:31 GMT Message-Id: <201209241107.q8OB7Vkc086067@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 Cc: Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 11:07:32 -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/169976 scsi [cam] [patch] make scsi_da use sysctl values where app o kern/169974 scsi [cam] [patch] add Quirks for SSD that are 4k optimised o kern/169835 scsi [patch] remove some unused variables from scsi_da prob o kern/169801 scsi [cam] [patc] make changes to delete_method in scsi_da 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/159412 scsi [ciss] 7.3 RELEASE: ciss0 ADAPTER HEARTBEAT FAILED err 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 kern/153361 scsi [ciss] Smart Array 5300 boot/detect drive problem o kern/152250 scsi [ciss] [patch] Kernel panic when hw.ciss.expose_hidden o kern/151564 scsi [ciss] ciss(4) should increase CISS_MAX_LOGICAL to 10 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/146287 scsi [ciss] ciss(4) cannot see more than one SmartArray con 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/144301 scsi [ciss] [hang] HP proliant server locks when using ciss 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/132250 scsi [ciss] ciss driver does not support more then 15 drive 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 55 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 24 14:38:52 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 006C0106566B for ; Mon, 24 Sep 2012 14:38:51 +0000 (UTC) (envelope-from jas@cse.yorku.ca) Received: from bronze.cs.yorku.ca (bronze.cs.yorku.ca [130.63.95.34]) by mx1.freebsd.org (Postfix) with ESMTP id B884B8FC08 for ; Mon, 24 Sep 2012 14:38:51 +0000 (UTC) Received: from [130.63.97.125] (ident=jas) by bronze.cs.yorku.ca with esmtp (Exim 4.76) (envelope-from ) id 1TG9o4-0004aH-Ke; Mon, 24 Sep 2012 10:38:44 -0400 Message-ID: <50607074.5010502@cse.yorku.ca> Date: Mon, 24 Sep 2012 10:38:44 -0400 From: Jason Keltz User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.7) Gecko/20120824 Thunderbird/10.0.7 MIME-Version: 1.0 To: "Desai, Kashyap" References: <505A2614.2000709@cse.yorku.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 X-Spam-Level: - X-Spam-Report: Content preview: Hi Kashyap, Thanks for your reply. I had seen mention of this different between "enclosure slot mapping" and "device mapping" before, but I can't find any "enclosure slot mapping" or "device mapping" option on the LSI 9205-8e card BIOS screen. Maybe you or someone else can tell me where to look for this option in the BIOS? I'm running the latest IT/non-RAID firmware released by LSI for this card. [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Cc: "freebsd-scsi@freebsd.org" Subject: Re: mps target difference between FreeBSD 9 and 9.1 RC X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 14:38:52 -0000 Hi Kashyap, Thanks for your reply. I had seen mention of this different between "enclosure slot mapping" and "device mapping" before, but I can't find any "enclosure slot mapping" or "device mapping" option on the LSI 9205-8e card BIOS screen. Maybe you or someone else can tell me where to look for this option in the BIOS? I'm running the latest IT/non-RAID firmware released by LSI for this card. I did go into the BIOS and write down all the details for the disks and match this up with FreeBSD 9.1 daX/target mapping. At least now, the results that I'm getting don't seem so "random". Here are the details: Slot,PhyNum,Scan_Order,daX,target [9205-8e card 1] 5,12,10,da0,33 0,13,11,da1,34 1,14,12,da2,35 2,15,13,da3,36 3,16,14,da4,37 4,17,15,da5,38 6,18,16,da6,39 7,19,17,da7,40 8,20,18,da8,41 11,21,19,da9,42 10,22,20,da10,43 9,23,21,da11,44 [9205-8e card 2] 17,24,10,da12,20 16,25,11,da13,21 15,26,12,da14,22 14,27,13,da15,23 22,28,14,da16,24 23,29,15,da17,25 18,30,16,da18,26 19,31,17,da19,27 13,32,18,da20,28 12,33,19,da21,29 20,34,20,da22,30 21,35,21,da23,31 It appears that the daX devices are enumerated by the new driver in either the phy order or scan order. It's still not clear to me why the first 9205-8e card would always see, say, slot 5 first, then 0, 1, 2,...,11,10,9 instead of 0,1,2,3,... but I guess it must be a complex timing issue. If I had different disks in the unit that took different time to spin up, I guess the results might be different? It's also not really clear to me why targets start at 20. In the end, it doesn't really matter what the targets are, but I'd like to understand why they are the way they are. I was able to hard-code the targets in /boot/device.hints to make it so that da0 was slot 0, da1 was slot 1, etc. Booting with every other disk removed, the mappings remained the same, but this is rather dangerous because it relies on the Phy order, and this might change if the disks changed, so it's not ultimately a solution. Ultimately, I need to understand how to enable the slot mapping functionality if it's available on the 9205-8e card. This would force the daX devices to be enumerated by slot number. I have a different system using an internal LSI 9211-8i card, also with the latest IT firmware, but it is connected to a Chenbro CK12803 expander which has 16 internal SATA disks attached. On that system, in the LSI BIOS, I can't see the disks at all - just the Chenbro expander, so I can't print all the details of the mappings like I did above, but the LSI status screen that displays the disks before going into the BIOS prints all the disks, but reports "ENC SLOT 0" for all of them. Here, there's probably some incompatibility with the Chenbro card (even though it's listed on the hardware compatibility list of the card). Without the 9211-8i seeing the proper slot mapping on this system, I'm guessing that enabling slot mapping in the BIOS probably wouldn't help here. Thanks for any help/feedback, Jason. On 09/24/2012 04:48 AM, Desai, Kashyap wrote: > Jason: > > FreeBSD9.0 is very old driver where we don't have "mps_mapping.c". With mps_mapping.c we are supporting different Target ID mapping which is main reason why you are seeing two different target ID behaviors in this case. > > We have major two mapping method. > 1. enclosure slot mapping and > 2. Device mapping. > > Depends upon what you have configured in FW Driver will behave accordingly. > > I would suggest to flash your Card completely and start from fresh with only FreeBSD-9.1. do not compare FreeBSD-9.0 > > > ` Kashyap > >> -----Original Message----- >> From: owner-freebsd-scsi@freebsd.org [mailto:owner-freebsd- >> scsi@freebsd.org] On Behalf Of Jason Keltz >> Sent: Thursday, September 20, 2012 1:38 AM >> To: freebsd-scsi@freebsd.org >> Subject: mps target difference between FreeBSD 9 and 9.1 RC >> >> I have a Dell R720 and a 24 x 2.5" Dell MD1220 JBOD. I have added dual >> LSI 9205-8e, each connected to the same MD1220 array. Under FreeBSD >> 9.0, if I do a "camcontrol devlist" (with every other disk removed), I >> see: >> >> at scbus0 target 0 lun 0 (pass0,da0) >> at scbus0 target 2 lun 0 (pass1,da1) >> at scbus0 target 4 lun 0 (pass2,da2) >> at scbus0 target 6 lun 0 (pass3,da3) >> at scbus0 target 8 lun 0 (pass4,da4) >> at scbus0 target 10 lun 0 (pass5,da5) >> at scbus0 target 36 lun 0 >> (pass6,ses0) >> at scbus1 target 12 lun 0 (pass7,da6) >> at scbus1 target 14 lun 0 (pass8,da7) >> at scbus1 target 16 lun 0 (pass9,da8) >> at scbus1 target 18 lun 0 >> (pass10,da9) >> at scbus1 target 21 lun 0 >> (pass11,da10) >> at scbus1 target 22 lun 0 >> (pass12,da11) >> at scbus1 target 36 lun 0 >> (pass13,ses1) >> at scbus6 target 0 lun 0 (pass14,cd0) >> >> ... which is what I would expect. If I do the same thing with any >> pre-release/RC version of 9.1, I see: >> >> at scbus0 target 34 lun 0 (pass0,da0) >> at scbus0 target 36 lun 0 (pass1,da1) >> at scbus0 target 38 lun 0 (pass2,da2) >> at scbus0 target 39 lun 0 (pass3,da3) >> at scbus0 target 41 lun 0 (pass4,da4) >> at scbus0 target 43 lun 0 (pass5,da5) >> at scbus0 target 45 lun 0 >> (ses0,pass6) >> at scbus1 target 21 lun 0 (pass7,da6) >> at scbus1 target 23 lun 0 (pass8,da7) >> at scbus1 target 24 lun 0 (pass9,da8) >> at scbus1 target 26 lun 0 >> (pass10,da9) >> at scbus1 target 29 lun 0 >> (pass11,da10) >> at scbus1 target 31 lun 0 >> (pass12,da11) >> at scbus1 target 32 lun 0 >> (ses1,pass13) >> at scbus6 target 0 lun 0 (pass14,cd0) >> >> In particular, note how the targets are starting at 34. I wonder if >> someone might explain why? >> >> I was considering using /boot/device.hints to hard-code the daX mapping >> to avoid the use of "labels" for my volumes, but I wouldn't expect the >> targets to change between the two releases. >> >> Thanks for any information that you can provide.. >> >> Jason. >> >> _______________________________________________ >> 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 Mon Sep 24 14:52:52 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A801106566B for ; Mon, 24 Sep 2012 14:52:52 +0000 (UTC) (envelope-from jas@cse.yorku.ca) Received: from bronze.cs.yorku.ca (bronze.cs.yorku.ca [130.63.95.34]) by mx1.freebsd.org (Postfix) with ESMTP id F24528FC08 for ; Mon, 24 Sep 2012 14:52:51 +0000 (UTC) Received: from [130.63.97.125] (ident=jas) by bronze.cs.yorku.ca with esmtp (Exim 4.76) (envelope-from ) id 1TGA1j-0005DM-7g for freebsd-scsi@freebsd.org; Mon, 24 Sep 2012 10:52:51 -0400 Message-ID: <506073C3.7020401@cse.yorku.ca> Date: Mon, 24 Sep 2012 10:52:51 -0400 From: Jason Keltz User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.7) Gecko/20120824 Thunderbird/10.0.7 MIME-Version: 1.0 To: "freebsd-scsi@freebsd.org" References: <5050E7C7.5030607@cse.yorku.ca> In-Reply-To: <5050E7C7.5030607@cse.yorku.ca> X-Forwarded-Message-Id: <5050E7C7.5030607@cse.yorku.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 X-Spam-Level: - X-Spam-Report: Content preview: (somewhat) Related to my previous message.... I have a system which has an Intel S3000AH server board with an LSI 9211-8i card with SAS2008 chipset, running IT firmware. It is connected to an older Chenbro CK12803 expander card which is connected to the 16 disk ports in an AIC RMC3E2-XPSS 3U chassis. At this time, I have only 12 SATA disks in the system ( 1 x 1 TB, 11 x 2 TB). The disks are all recognized, although interestingly enough, all of them report ENC SLOT 0 on the 9211-8i bios display of disks. [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Subject: 9.1-rc1 mps timeout error X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 14:52:52 -0000 (somewhat) Related to my previous message.... I have a system which has an Intel S3000AH server board with an LSI 9211-8i card with SAS2008 chipset, running IT firmware. It is connected to an older Chenbro CK12803 expander card which is connected to the 16 disk ports in an AIC RMC3E2-XPSS 3U chassis. At this time, I have only 12 SATA disks in the system ( 1 x 1 TB, 11 x 2 TB). The disks are all recognized, although interestingly enough, all of them report ENC SLOT 0 on the 9211-8i bios display of disks. At the end of the 9.1 boot sequence, I see: mps0: mpssas_scsiio_timeout checking sc 0xffffff8000759000 cm 0xffffff8000784380 (probe19:mps0:0:19:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 length 0 SMID 240 command timeout cm 0xffffff8000784380 ccb 0xfffffe0006918000 mps0: mpssas_alloc_tm freezing simq mps0: timedout cm 0xffffff8000784380 allocated tm 0xffffff8000771148 (probe19:mps0:0:19:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 length 0 SMID 240 completed timedout cm 0xffffff8000784380 ccb 0xfffffe0006918000 during recovery ioc 8048 scsi 0 state c xfer 0 (noperiph:mps0:0:19:0): SMID 1 abort TaskMID 240 status 0x0 code 0x0 count 1 (noperiph:mps0:0:19:0): SMID 1 finished recovery after aborting TaskMID 240 mps0: mpssas_free_tm releasing simq I'm wondering if this is something to be concerned about? Output of "camcontrol devlist" is: at scbus0 target 19 lun 0 (ses0,pass0) at scbus0 target 25 lun 0 (pass1,da0) at scbus0 target 26 lun 0 (pass2,da1) at scbus0 target 27 lun 0 (pass3,da2) at scbus0 target 28 lun 0 (pass4,da3) at scbus0 target 29 lun 0 (pass5,da4) at scbus0 target 30 lun 0 (pass6,da5) at scbus0 target 31 lun 0 (pass7,da6) at scbus0 target 32 lun 0 (pass8,da7) at scbus0 target 33 lun 0 (pass9,da8) at scbus0 target 34 lun 0 (pass10,da9) at scbus0 target 35 lun 0 (pass11,da10) at scbus0 target 36 lun 0 (pass12,da11) at scbus1 target 0 lun 0 (pass13,cd0) ... I'm guessing the above error is talking to the Chenbro expander card. (mps0:0:19?) At this point, I've been ignoring the error, but if I can add a bit somewhere to make it go away, it would be even better. Thanks for any assistance.. Jason. From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 24 17:26:48 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 821) id 41C281065672; Mon, 24 Sep 2012 17:26:48 +0000 (UTC) Date: Mon, 24 Sep 2012 17:26:48 +0000 From: John To: FreeBSD iSCSI Message-ID: <20120924172648.GA96855@FreeBSD.org> References: <20120915022437.GA90210@FreeBSD.org> <20120915023329.GA55292@nargothrond.kdm.org> <20120915031305.GA97685@FreeBSD.org> <20120915032826.GA63349@nargothrond.kdm.org> <20120915040907.GA5458@FreeBSD.org> <20120915043938.GA71754@nargothrond.kdm.org> <20120916221550.GA63055@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120916221550.GA63055@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: "Kenneth D. Merry" Subject: Re: How to force a reset of a device (disk) in an enclosre slot (PATCH) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 17:26:48 -0000 Hi Ken, The following patch fixes the problem: Index: mps_sas.c =================================================================== --- mps_sas.c (revision 240879) +++ mps_sas.c (working copy) @@ -918,7 +918,7 @@ cpi->hba_eng_cnt = 0; cpi->max_target = sassc->sc->facts->MaxTargets - 1; cpi->max_lun = 255; - cpi->initiator_id = 255; + cpi->initiator_id = sassc->sc->facts->MaxTargets; strncpy(cpi->sim_vid, "FreeBSD", SIM_IDLEN); strncpy(cpi->hba_vid, "LSILogic", HBA_IDLEN); strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN); I simply set the id to the value after the last possible target for the card. Does that seem reasonable to you? If you don't mind, I'll commit this if there are no objections. Thanks to you and others for pointing me in the right direction :-) Thanks, John ----- John's Original Message ----- > ----- Kenneth D. Merry's Original Message ----- > > On Sat, Sep 15, 2012 at 04:09:07 +0000, John wrote: > > > ----- Kenneth D. Merry's Original Message ----- > > > > On Sat, Sep 15, 2012 at 03:13:05 +0000, John wrote: > > > > > ----- Kenneth D. Merry's Original Message ----- > > > > > > On Sat, Sep 15, 2012 at 02:24:37 +0000, John wrote: > > > > > > > Hi Folks, > > > > > > > > > > > > > > I've been poking around and can't seem to find a way to reset and > > > > > > > hopefully acquire access to a disk device in an enclosure. For instance: > > > > > > > > > > > > > > FreeBSD 9.1-PRERELEASE > > > > > > > > > > > > > > # camcontrol smpphylist ses4 > > > > > > > 37 PHYs: > > > > > > > PHY Attached SAS Address > > > > > > > 0 0x5000039368233602 (pass105,da98) > > > > > > > 1 0x5000039368238e3e (pass106,da99) > > > > > > > 2 0x500003936823bca2 (pass107,da100) > > > > > > > 3 0x500003936819507e (pass108,da101) > > > > > > > 4 0x5000039368197d5a (pass109,da102) > > > > > > > 5 0x5000039368197c6e (pass110,da103) > > > > > > > 6 0x500003936818770e (pass111,da104) > > > > > > > 7 0x5000039368238eba (pass112,da105) > > > > > > > 8 0x5000039368232f42 (pass113,da106) > > > > > > > 9 0x0000000000000000 > > > > > > > 10 0x500003936813c31e > > > > > > > 11 0x5000039368233892 (pass114,da107) > > > > > > > 12 0x500003936813c2ca (pass115,da108) > > > > > > > ... > > > > > > > > > > > > > > Note, bay/slot 10 has a listed device address. If I were to pull the > > > > > > > drive and re-insert it, it would show up (as da390 in this case). > > > > > > > The above is after a fresh reboot. Note da106 to da107 skipping > > > > > > > slot 10 (slot 9 is empty). > > > > > > > > > > > > > > The smp utils provide a similar view: > > > > > > > > > > > > > > # smp_discover /dev/ses4 > > > > > > > phy 0:D:attached:[5000039368233602:00 t(SSP)] 6 Gbps > > > > > > > phy 1:D:attached:[5000039368238e3e:00 t(SSP)] 6 Gbps > > > > > > > phy 2:D:attached:[500003936823bca2:00 t(SSP)] 6 Gbps > > > > > > > phy 3:D:attached:[500003936819507e:00 t(SSP)] 6 Gbps > > > > > > > phy 4:D:attached:[5000039368197d5a:00 t(SSP)] 6 Gbps > > > > > > > phy 5:D:attached:[5000039368197c6e:00 t(SSP)] 6 Gbps > > > > > > > phy 6:D:attached:[500003936818770e:00 t(SSP)] 6 Gbps > > > > > > > phy 7:D:attached:[5000039368238eba:00 t(SSP)] 6 Gbps > > > > > > > phy 8:D:attached:[5000039368232f42:00 t(SSP)] 6 Gbps > > > > > > > phy 10:D:attached:[500003936813c31e:00 t(SSP)] 6 Gbps > > > > > > > phy 11:D:attached:[5000039368233892:00 t(SSP)] 6 Gbps > > > > > > > phy 12:D:attached:[500003936813c2ca:00 t(SSP)] 6 Gbps > > > > > > > ... > > > > > > > > > > > > > > The address of slot 10 matches. There is a disk in the slot - just > > > > > > > isn't recognized and attached. > > > > > > > > > > > > > > Back to the basic question. How can I issue a command to the enclosure > > > > > > > to force a re-initialization of the device to recover it without > > > > > > > having to physically pull & insert it. Even if the device numbers > > > > > > > are not sequential, I need access to the drive... > > > > > > > > > > > > You can try sending a link reset: > > > > > > > > > > > > camcontrol smppc ses4 -p 10 -o linkreset > > > > > > > > > > > > It may or may not work. You can also try disabling the PHY (-o disable) > > > > > > and then sending a link reset to re-enable the link. You can also try a > > > > > > hard reset (-o hardreset) > > > > > > > > > > Hi Ken, > > > > > > > > > > Well, I hadn't tried to actually disable the device. That did bring some > > > > > reaction: > > > > > > > > > > # camcontrol smppc ses4 -p 10 -o disable > > > > > # camcontrol smpphylist ses4 > > > > > 37 PHYs: > > > > > PHY Attached SAS Address > > > > > 0 0x5000039368233602 (pass105,da98) > > > > > .... > > > > > 8 0x5000039368232f42 (pass113,da106) > > > > > 9 0x0000000000000000 > > > > > 10 0x0000000000000000 > > > > > 11 0x5000039368233892 (pass114,da107) > > > > > ... > > > > > > > > > > The device is gone. > > > > > > > > > > # camcontrol smppc ses4 -p 10 -o hardreset > > > > > root@vprzfs01p:/root # camcontrol smpphylist ses4 > > > > > 37 PHYs: > > > > > PHY Attached SAS Address > > > > > 0 0x5000039368233602 (pass105,da98) > > > > > .... > > > > > 8 0x5000039368232f42 (pass113,da106) > > > > > 9 0x0000000000000000 > > > > > 10 0x500003936813c31e > > > > > 11 0x5000039368233892 (pass114,da107) > > > > > ... > > > > > > > > > > The device is back, but not attached - This msg: > > > > > > > > > > kernel: mps1: mpssas_alloc_tm freezing simq > > > > > kernel: mps1: mpssas_remove_complete on handle 0x0069, IOCStatus= 0x0 > > > > > kernel: mps1: mpssas_free_tm releasing simq > > > > > kernel: _mapping_add_new_device: failed to add the device with handle 0x0069 to persistent table because there is no free space available - entry 0 > > > > > > > > That message is harmless, it won't prevent the drive from attaching. > > > > > > > > > >From a debug statement in the driver: MaxPersistentEntries == 128, but I > > > > > have more than 128 devices per LSI card and they normally all show up - > > > > > though I do get a bunch of the above messages in dmesg.. > > > > > > > > You might try turning on some of the debugging in the mps(4) driver and > > > > disabling and resetting the link again. > > > > > > > > Try: > > > > > > > > sysctl -w dev.mps.0.debug_level=0xf > > > > > > > > You might get a lot of output, so be prepared to reset it back to 4: > > > > > > > > sysctl -w dev.mps.0.debug_level=4 > > > > > > Hi Ken, > > > > > > I don't see anything obvious. Hopefully you're more familair with the > > > code and have better eyes than I do... Here's everything from messages > > > after the -o disable. There are some "unknown/unhandled"s showing up. > > > > Here is where the drive shows up: > > > > > kernel: mps_intr_locked sc 0xffffff8001353000 writing postindex 243 > > > kernel: mps_enqueue_request SMID 653 cm 0xffffff80013ca4a8 ccb 0 > > > kernel: mps_intr_locked sc 0xffffff8001353000 starting with replypostindex 243 > > > kernel: mps_intr_locked sc 0xffffff8001353000 writing postindex 244 > > > kernel: SAS Address from SAS device page0 = 500003936811feae > > > kernel: Found device <401,End Device> <6.0Gbps> <0x0078> <4/36> > > > kernel: mpssas_rescan_target targetid 255 > > > kernel: mpssas_rescan > > > kernel: > > > kernel: Target id 0xff added > > > > It finds the device, with target ID 255 (which is a little suspicious) and > > queues a rescan, but nothing happens after that. > > > > You might try doing a manual rescan of that device to see what happens: > > > > camcontrol rescan X:255:0 > > > > Where X is the scbus number from camcontrol devlist. > > > > If that doesn't work, then we need to figure out what the maximum number of > > targets supported by the adapter is. To do that, set this in > > /boot/loader.conf and reboot: > > > > hw.mps.debug_level=1 > > > > That should result in the IOCFacts page getting printed on boot. > > > > How many drives and other devices are currently attached to that > > controller? What controller model is it, and do you have IT or IR > > firmware on it? > > > > > Hi Ken, > > First to some of your questions. There are 3 LSI cards installed > in the box. LSI 2116 - One 16i (not in use) and a pair of 16e. There > are 8 d2700 shelves attached to the 16e cards - dual channel. Eight > shelves, 25 devices each: 200 disks, dual attached, da0 - da399 for > fully populated shelves.. The IOCFacts are included at the end of this > email. I think you've seen this diagram before: > > http://people.freebsd.org/~jwd/zfsnfsserver.jpg > > I think there is something to your comment about device id 255 > being suspicious. > > After a fresh reboot, it appears that device 255 on both busses > is missing. Issuing just the commands: > > camcontrol rescan 7:255:0 > camcontrol rescan 8:255:0 > > and the drives show up: > > mps1: handle(0x0062), ioc_status(scsi data underrun)(0x0045), > mps1: scsi_status(good)(0x00), scsi_state( )(0x00) > mps1: handle(0x0062), ioc_status(scsi data underrun)(0x0045), > mps1: scsi_status(good)(0x00), scsi_state( )(0x00) > mps1: handle(0x0062), ioc_status(scsi data underrun)(0x0045), > mps1: scsi_status(good)(0x00), scsi_state( )(0x00) > da390 at mps1 bus 0 scbus7 target 255 lun 0 > da390: Fixed Direct Access SCSI-5 device > da390: 600.000MB/s transfers > da390: Command Queueing enabled > da390: 572325MB (1172123568 512 byte sectors: 255H 63S/T 72961C) > GEOM_MULTIPATH: da390 added to Z78 > mps2: handle(0x0069), ioc_status(scsi data underrun)(0x0045), > mps2: scsi_status(good)(0x00), scsi_state( )(0x00) > mps2: handle(0x0069), ioc_status(scsi data underrun)(0x0045), > mps2: scsi_status(good)(0x00), scsi_state( )(0x00) > mps2: handle(0x0069), ioc_status(scsi data underrun)(0x0045), > mps2: scsi_status(good)(0x00), scsi_state( )(0x00) > da391 at mps2 bus 0 scbus8 target 255 lun 0 > da391: Fixed Direct Access SCSI-5 device > da391: 600.000MB/s transfers > da391: Command Queueing enabled > da391: 572325MB (1172123568 512 byte sectors: 255H 63S/T 72961C) > GEOM_MULTIPATH: da391 added to Z75 > > I don't know if the 'scsi data underrun' is important here. > A camcontrol smpphylist of the two related shelves. Note, there > is no device is bay 9. > > # camcontrol smpphylist ses4 > 37 PHYs: > PHY Attached SAS Address > 0 0x500003936812dd36 (pass105,da98) > .... > 8 0x500003936810b756 (pass113,da106) > 9 0x0000000000000000 > 10 0x500003936811feae (da390,pass409) > ... > 24 0x500003936819898a (pass127,da120) > > # camcontrol smpphylist ses12 > 37 PHYs: > PHY Attached SAS Address > 0 0x5000c5003c4f5986 (pass308,da293) > .... > 8 0x5000c5003c4f5ebe (pass316,da301) > 9 0x0000000000000000 > 10 0x5000c5003c375b86 (da391,pass410) > ... > 24 0x5000c5003c00cb7a (pass330,da315) > > > On a related note, the pass & da devices are reversed for the two > devices found via the rescan. > > I've been scanning the driver code but don't see an obvious place > where device id 255 would be dropped. Please let me know if there is > something you'd like me to check. > > > This has been a learning experience. Thanks Ken. > > Thanks, > John > > > 16i card: (Not currenlty in use) > > mps0: port 0x5000-0x50ff mem 0xfbdf0000-0xfbdf3fff,0xfbd80000-0xfbdbffff irq 52 at device 0.0 on pci24 > mps0: Doorbell= 0x12000000 > mps0: IOCFacts : > MsgVersion: 0x200 > HeaderVersion: 0x1900 > IOCNumber: 0 > IOCExceptions: 0x0 > MaxChainDepth: 128 > WhoInit: ROM BIOS > NumberOfPorts: 1 > RequestCredit: 7632 > ProductID: 0x2213 > IOCCapabilities: 1285c > FWVersion= 14-0-0-0 > IOCRequestFrameSize: 32 > MaxInitiators: 30 > MaxTargets: 756 > MaxSasExpanders: 224 > MaxEnclosures: 224 > ProtocolFlags: 3 > HighPriorityCredit: 120 > MaxReplyDescriptorPostQueueDepth: 65504 > ReplyFrameSize: 32 > MaxVolumes: 0 > MaxDevHandle: 1026 > MaxPersistentEntries: 128 > mps0: Firmware: 14.00.00.00, Driver: 14.00.00.01-fbsd > mps0: IOCCapabilities: 1285c > > > > 1st 16e card: > > > mps1: port 0x7000-0x70ff mem 0xfbff0000-0xfbff3fff,0xfbf80000-0xfbfbffff irq 48 at device 0.0 on pci33 > mps1: Doorbell= 0x12000000 > mps1: IOCFacts : > MsgVersion: 0x200 > HeaderVersion: 0x1900 > IOCNumber: 0 > IOCExceptions: 0x0 > MaxChainDepth: 128 > WhoInit: ROM BIOS > NumberOfPorts: 1 > RequestCredit: 32455 > ProductID: 0x2213 > IOCCapabilities: 1285c > FWVersion= 14-0-0-0 > IOCRequestFrameSize: 32 > MaxInitiators: 32 > MaxTargets: 1024 > MaxSasExpanders: 128 > MaxEnclosures: 129 > ProtocolFlags: 3 > HighPriorityCredit: 127 > MaxReplyDescriptorPostQueueDepth: 65504 > ReplyFrameSize: 32 > MaxVolumes: 0 > MaxDevHandle: 1200 > MaxPersistentEntries: 128 > mps1: Firmware: 14.00.00.00, Driver: 14.00.00.01-fbsd > mps1: IOCCapabilities: 1285c > > 2nd 16e card: > > mps2: port 0x6000-0x60ff mem 0xfbef0000-0xfbef3fff,0xfbe80000-0xfbebffff irq 56 at device 0.0 on pci27 > mps2: Doorbell= 0x12000000 > mps2: IOCFacts : > MsgVersion: 0x200 > HeaderVersion: 0x1900 > IOCNumber: 0 > IOCExceptions: 0x0 > MaxChainDepth: 128 > WhoInit: ROM BIOS > NumberOfPorts: 1 > RequestCredit: 32455 > ProductID: 0x2213 > IOCCapabilities: 1285c > FWVersion= 14-0-0-0 > IOCRequestFrameSize: 32 > MaxInitiators: 32 > MaxTargets: 1024 > MaxSasExpanders: 128 > MaxEnclosures: 129 > ProtocolFlags: 3 > HighPriorityCredit: 127 > MaxReplyDescriptorPostQueueDepth: 65504 > ReplyFrameSize: 32 > MaxVolumes: 0 > MaxDevHandle: 1200 > MaxPersistentEntries: 128 > mps2: Firmware: 14.00.00.00, Driver: 14.00.00.01-fbsd > mps2: IOCCapabilities: 1285c > > > And here is the entire device listing after running the pair > of camcontrol rescan commands. Note, the OS lives on the revodrive. > All shelf drives are for data. > > > at scbus0 target 0 lun 0 (ada0,pass0) > at scbus1 target 0 lun 0 (ada1,pass1) > at scbus5 target 0 lun 0 (pass2,cd0) > at scbus7 target 144 lun 0 (pass3,da0) > at scbus7 target 145 lun 0 (pass4,da1) > at scbus7 target 146 lun 0 (pass5,da2) > at scbus7 target 147 lun 0 (pass6,da3) > at scbus7 target 148 lun 0 (pass7,da4) > at scbus7 target 149 lun 0 (pass8,da5) > at scbus7 target 150 lun 0 (pass9,da6) > at scbus7 target 151 lun 0 (pass10,da7) > at scbus7 target 152 lun 0 (pass11,da8) > at scbus7 target 153 lun 0 (pass12,da9) > at scbus7 target 154 lun 0 (pass13,da10) > at scbus7 target 155 lun 0 (pass14,da11) > at scbus7 target 156 lun 0 (pass15,da12) > at scbus7 target 157 lun 0 (pass16,da13) > at scbus7 target 158 lun 0 (pass17,da14) > at scbus7 target 159 lun 0 (pass18,da15) > at scbus7 target 160 lun 0 (pass19,da16) > at scbus7 target 161 lun 0 (pass20,da17) > at scbus7 target 162 lun 0 (pass21,da18) > at scbus7 target 163 lun 0 (pass22,da19) > at scbus7 target 164 lun 0 (pass23,da20) > at scbus7 target 165 lun 0 (pass24,da21) > at scbus7 target 166 lun 0 (pass25,da22) > at scbus7 target 167 lun 0 (pass26,da23) > at scbus7 target 168 lun 0 (ses0,pass27) > at scbus7 target 169 lun 0 (pass28,da24) > at scbus7 target 170 lun 0 (pass29,da25) > at scbus7 target 171 lun 0 (pass30,da26) > at scbus7 target 172 lun 0 (pass31,da27) > at scbus7 target 173 lun 0 (pass32,da28) > at scbus7 target 174 lun 0 (pass33,da29) > at scbus7 target 175 lun 0 (pass34,da30) > at scbus7 target 176 lun 0 (pass35,da31) > at scbus7 target 177 lun 0 (pass36,da32) > at scbus7 target 178 lun 0 (pass37,da33) > at scbus7 target 179 lun 0 (pass38,da34) > at scbus7 target 180 lun 0 (pass39,da35) > at scbus7 target 181 lun 0 (pass40,da36) > at scbus7 target 182 lun 0 (pass41,da37) > at scbus7 target 183 lun 0 (pass42,da38) > at scbus7 target 184 lun 0 (pass43,da39) > at scbus7 target 185 lun 0 (pass44,da40) > at scbus7 target 186 lun 0 (pass45,da41) > at scbus7 target 187 lun 0 (pass46,da42) > at scbus7 target 188 lun 0 (pass47,da43) > at scbus7 target 189 lun 0 (pass48,da44) > at scbus7 target 190 lun 0 (pass49,da45) > at scbus7 target 191 lun 0 (pass50,da46) > at scbus7 target 192 lun 0 (pass51,da47) > at scbus7 target 193 lun 0 (pass52,da48) > at scbus7 target 194 lun 0 (ses1,pass53) > at scbus7 target 195 lun 0 (pass54,da49) > at scbus7 target 196 lun 0 (pass55,da50) > at scbus7 target 197 lun 0 (pass56,da51) > at scbus7 target 198 lun 0 (pass57,da52) > at scbus7 target 199 lun 0 (pass58,da53) > at scbus7 target 200 lun 0 (pass59,da54) > at scbus7 target 201 lun 0 (pass60,da55) > at scbus7 target 202 lun 0 (pass61,da56) > at scbus7 target 203 lun 0 (pass62,da57) > at scbus7 target 204 lun 0 (pass63,da58) > at scbus7 target 205 lun 0 (pass64,da59) > at scbus7 target 206 lun 0 (pass65,da60) > at scbus7 target 207 lun 0 (pass66,da61) > at scbus7 target 208 lun 0 (pass67,da62) > at scbus7 target 209 lun 0 (pass68,da63) > at scbus7 target 210 lun 0 (pass69,da64) > at scbus7 target 211 lun 0 (pass70,da65) > at scbus7 target 212 lun 0 (pass71,da66) > at scbus7 target 213 lun 0 (pass72,da67) > at scbus7 target 214 lun 0 (pass73,da68) > at scbus7 target 215 lun 0 (pass74,da69) > at scbus7 target 216 lun 0 (pass75,da70) > at scbus7 target 217 lun 0 (pass76,da71) > at scbus7 target 218 lun 0 (pass77,da72) > at scbus7 target 219 lun 0 (ses2,pass78) > at scbus7 target 220 lun 0 (pass79,da73) > at scbus7 target 221 lun 0 (pass80,da74) > at scbus7 target 222 lun 0 (pass81,da75) > at scbus7 target 223 lun 0 (pass82,da76) > at scbus7 target 224 lun 0 (pass83,da77) > at scbus7 target 225 lun 0 (pass84,da78) > at scbus7 target 226 lun 0 (pass85,da79) > at scbus7 target 227 lun 0 (pass86,da80) > at scbus7 target 228 lun 0 (pass87,da81) > at scbus7 target 229 lun 0 (pass88,da82) > at scbus7 target 230 lun 0 (pass89,da83) > at scbus7 target 231 lun 0 (pass90,da84) > at scbus7 target 232 lun 0 (pass91,da85) > at scbus7 target 233 lun 0 (pass92,da86) > at scbus7 target 234 lun 0 (pass93,da87) > at scbus7 target 235 lun 0 (pass94,da88) > at scbus7 target 236 lun 0 (pass95,da89) > at scbus7 target 237 lun 0 (pass96,da90) > at scbus7 target 238 lun 0 (pass97,da91) > at scbus7 target 239 lun 0 (pass98,da92) > at scbus7 target 240 lun 0 (pass99,da93) > at scbus7 target 241 lun 0 (pass100,da94) > at scbus7 target 242 lun 0 (pass101,da95) > at scbus7 target 243 lun 0 (pass102,da96) > at scbus7 target 244 lun 0 (pass103,da97) > at scbus7 target 245 lun 0 (ses3,pass104) > at scbus7 target 246 lun 0 (pass105,da98) > at scbus7 target 247 lun 0 (pass106,da99) > at scbus7 target 248 lun 0 (pass107,da100) > at scbus7 target 249 lun 0 (pass108,da101) > at scbus7 target 250 lun 0 (pass109,da102) > at scbus7 target 251 lun 0 (pass110,da103) > at scbus7 target 252 lun 0 (pass111,da104) > at scbus7 target 253 lun 0 (pass112,da105) > at scbus7 target 254 lun 0 (pass113,da106) > at scbus7 target 255 lun 0 (da390,pass409) > at scbus7 target 256 lun 0 (pass114,da107) > at scbus7 target 257 lun 0 (pass115,da108) > at scbus7 target 258 lun 0 (pass116,da109) > at scbus7 target 259 lun 0 (pass117,da110) > at scbus7 target 260 lun 0 (pass118,da111) > at scbus7 target 261 lun 0 (pass119,da112) > at scbus7 target 262 lun 0 (pass120,da113) > at scbus7 target 263 lun 0 (pass121,da114) > at scbus7 target 264 lun 0 (pass122,da115) > at scbus7 target 265 lun 0 (pass123,da116) > at scbus7 target 266 lun 0 (pass124,da117) > at scbus7 target 267 lun 0 (pass125,da118) > at scbus7 target 268 lun 0 (pass126,da119) > at scbus7 target 269 lun 0 (pass127,da120) > at scbus7 target 270 lun 0 (ses4,pass128) > at scbus7 target 271 lun 0 (pass129,da121) > at scbus7 target 272 lun 0 (pass130,da122) > at scbus7 target 273 lun 0 (pass131,da123) > at scbus7 target 274 lun 0 (pass132,da124) > at scbus7 target 275 lun 0 (pass133,da125) > at scbus7 target 276 lun 0 (pass134,da126) > at scbus7 target 277 lun 0 (pass135,da127) > at scbus7 target 278 lun 0 (pass136,da128) > at scbus7 target 279 lun 0 (pass137,da129) > at scbus7 target 280 lun 0 (pass138,da130) > at scbus7 target 281 lun 0 (pass139,da131) > at scbus7 target 282 lun 0 (pass140,da132) > at scbus7 target 283 lun 0 (pass141,da133) > at scbus7 target 284 lun 0 (pass142,da134) > at scbus7 target 285 lun 0 (pass143,da135) > at scbus7 target 286 lun 0 (pass144,da136) > at scbus7 target 287 lun 0 (pass145,da137) > at scbus7 target 288 lun 0 (pass146,da138) > at scbus7 target 289 lun 0 (pass147,da139) > at scbus7 target 290 lun 0 (pass148,da140) > at scbus7 target 291 lun 0 (pass149,da141) > at scbus7 target 292 lun 0 (pass150,da142) > at scbus7 target 293 lun 0 (pass151,da143) > at scbus7 target 294 lun 0 (pass152,da144) > at scbus7 target 295 lun 0 (pass153,da145) > at scbus7 target 296 lun 0 (ses5,pass154) > at scbus7 target 297 lun 0 (pass155,da146) > at scbus7 target 298 lun 0 (pass156,da147) > at scbus7 target 299 lun 0 (pass157,da148) > at scbus7 target 300 lun 0 (pass158,da149) > at scbus7 target 301 lun 0 (pass159,da150) > at scbus7 target 302 lun 0 (pass160,da151) > at scbus7 target 303 lun 0 (pass161,da152) > at scbus7 target 304 lun 0 (pass162,da153) > at scbus7 target 305 lun 0 (pass163,da154) > at scbus7 target 306 lun 0 (pass164,da155) > at scbus7 target 307 lun 0 (pass165,da156) > at scbus7 target 308 lun 0 (pass166,da157) > at scbus7 target 309 lun 0 (pass167,da158) > at scbus7 target 310 lun 0 (pass168,da159) > at scbus7 target 311 lun 0 (pass169,da160) > at scbus7 target 312 lun 0 (pass170,da161) > at scbus7 target 313 lun 0 (pass171,da162) > at scbus7 target 314 lun 0 (pass172,da163) > at scbus7 target 315 lun 0 (pass173,da164) > at scbus7 target 316 lun 0 (pass174,da165) > at scbus7 target 317 lun 0 (pass175,da166) > at scbus7 target 318 lun 0 (pass176,da167) > at scbus7 target 319 lun 0 (pass177,da168) > at scbus7 target 320 lun 0 (pass178,da169) > at scbus7 target 321 lun 0 (ses6,pass179) > at scbus7 target 322 lun 0 (pass180,da170) > at scbus7 target 323 lun 0 (pass181,da171) > at scbus7 target 324 lun 0 (pass182,da172) > at scbus7 target 325 lun 0 (pass183,da173) > at scbus7 target 326 lun 0 (pass184,da174) > at scbus7 target 327 lun 0 (pass185,da175) > at scbus7 target 328 lun 0 (pass186,da176) > at scbus7 target 329 lun 0 (pass187,da177) > at scbus7 target 330 lun 0 (pass188,da178) > at scbus7 target 331 lun 0 (pass189,da179) > at scbus7 target 332 lun 0 (pass190,da180) > at scbus7 target 333 lun 0 (pass191,da181) > at scbus7 target 334 lun 0 (pass192,da182) > at scbus7 target 335 lun 0 (pass193,da183) > at scbus7 target 336 lun 0 (pass194,da184) > at scbus7 target 337 lun 0 (pass195,da185) > at scbus7 target 338 lun 0 (pass196,da186) > at scbus7 target 339 lun 0 (pass197,da187) > at scbus7 target 340 lun 0 (pass198,da188) > at scbus7 target 341 lun 0 (pass199,da189) > at scbus7 target 342 lun 0 (pass200,da190) > at scbus7 target 343 lun 0 (pass201,da191) > at scbus7 target 344 lun 0 (pass202,da192) > at scbus7 target 345 lun 0 (pass203,da193) > at scbus7 target 346 lun 0 (pass204,da194) > at scbus7 target 347 lun 0 (ses7,pass205) > at scbus8 target 144 lun 0 (pass206,da195) > at scbus8 target 145 lun 0 (pass207,da196) > at scbus8 target 146 lun 0 (pass208,da197) > at scbus8 target 147 lun 0 (pass209,da198) > at scbus8 target 148 lun 0 (pass210,da199) > at scbus8 target 149 lun 0 (pass211,da200) > at scbus8 target 150 lun 0 (pass212,da201) > at scbus8 target 151 lun 0 (pass213,da202) > at scbus8 target 152 lun 0 (pass214,da203) > at scbus8 target 153 lun 0 (pass215,da204) > at scbus8 target 154 lun 0 (pass216,da205) > at scbus8 target 155 lun 0 (pass217,da206) > at scbus8 target 156 lun 0 (pass218,da207) > at scbus8 target 157 lun 0 (pass219,da208) > at scbus8 target 158 lun 0 (pass220,da209) > at scbus8 target 159 lun 0 (pass221,da210) > at scbus8 target 160 lun 0 (pass222,da211) > at scbus8 target 161 lun 0 (pass223,da212) > at scbus8 target 162 lun 0 (pass224,da213) > at scbus8 target 163 lun 0 (pass225,da214) > at scbus8 target 164 lun 0 (pass226,da215) > at scbus8 target 165 lun 0 (pass227,da216) > at scbus8 target 166 lun 0 (pass228,da217) > at scbus8 target 167 lun 0 (pass229,da218) > at scbus8 target 168 lun 0 (ses8,pass230) > at scbus8 target 169 lun 0 (pass231,da219) > at scbus8 target 170 lun 0 (pass232,da220) > at scbus8 target 171 lun 0 (pass233,da221) > at scbus8 target 172 lun 0 (pass234,da222) > at scbus8 target 173 lun 0 (pass235,da223) > at scbus8 target 174 lun 0 (pass236,da224) > at scbus8 target 175 lun 0 (pass237,da225) > at scbus8 target 176 lun 0 (pass238,da226) > at scbus8 target 177 lun 0 (pass239,da227) > at scbus8 target 178 lun 0 (pass240,da228) > at scbus8 target 179 lun 0 (pass241,da229) > at scbus8 target 180 lun 0 (pass242,da230) > at scbus8 target 181 lun 0 (pass243,da231) > at scbus8 target 182 lun 0 (pass244,da232) > at scbus8 target 183 lun 0 (pass245,da233) > at scbus8 target 184 lun 0 (pass246,da234) > at scbus8 target 185 lun 0 (pass247,da235) > at scbus8 target 186 lun 0 (pass248,da236) > at scbus8 target 187 lun 0 (pass249,da237) > at scbus8 target 188 lun 0 (pass250,da238) > at scbus8 target 189 lun 0 (pass251,da239) > at scbus8 target 190 lun 0 (pass252,da240) > at scbus8 target 191 lun 0 (pass253,da241) > at scbus8 target 192 lun 0 (pass254,da242) > at scbus8 target 193 lun 0 (pass255,da243) > at scbus8 target 194 lun 0 (ses9,pass256) > at scbus8 target 195 lun 0 (pass257,da244) > at scbus8 target 196 lun 0 (pass258,da245) > at scbus8 target 197 lun 0 (pass259,da246) > at scbus8 target 198 lun 0 (pass260,da247) > at scbus8 target 199 lun 0 (pass261,da248) > at scbus8 target 200 lun 0 (pass262,da249) > at scbus8 target 201 lun 0 (pass263,da250) > at scbus8 target 202 lun 0 (pass264,da251) > at scbus8 target 203 lun 0 (pass265,da252) > at scbus8 target 204 lun 0 (pass266,da253) > at scbus8 target 205 lun 0 (pass267,da254) > at scbus8 target 206 lun 0 (pass268,da255) > at scbus8 target 207 lun 0 (pass269,da256) > at scbus8 target 208 lun 0 (pass270,da257) > at scbus8 target 209 lun 0 (pass271,da258) > at scbus8 target 210 lun 0 (pass272,da259) > at scbus8 target 211 lun 0 (pass273,da260) > at scbus8 target 212 lun 0 (pass274,da261) > at scbus8 target 213 lun 0 (pass275,da262) > at scbus8 target 214 lun 0 (pass276,da263) > at scbus8 target 215 lun 0 (pass277,da264) > at scbus8 target 216 lun 0 (pass278,da265) > at scbus8 target 217 lun 0 (pass279,da266) > at scbus8 target 218 lun 0 (pass280,da267) > at scbus8 target 219 lun 0 (ses10,pass281) > at scbus8 target 220 lun 0 (pass282,da268) > at scbus8 target 221 lun 0 (pass283,da269) > at scbus8 target 222 lun 0 (pass284,da270) > at scbus8 target 223 lun 0 (pass285,da271) > at scbus8 target 224 lun 0 (pass286,da272) > at scbus8 target 225 lun 0 (pass287,da273) > at scbus8 target 226 lun 0 (pass288,da274) > at scbus8 target 227 lun 0 (pass289,da275) > at scbus8 target 228 lun 0 (pass290,da276) > at scbus8 target 229 lun 0 (pass291,da277) > at scbus8 target 230 lun 0 (pass292,da278) > at scbus8 target 231 lun 0 (pass293,da279) > at scbus8 target 232 lun 0 (pass294,da280) > at scbus8 target 233 lun 0 (pass295,da281) > at scbus8 target 234 lun 0 (pass296,da282) > at scbus8 target 235 lun 0 (pass297,da283) > at scbus8 target 236 lun 0 (pass298,da284) > at scbus8 target 237 lun 0 (pass299,da285) > at scbus8 target 238 lun 0 (pass300,da286) > at scbus8 target 239 lun 0 (pass301,da287) > at scbus8 target 240 lun 0 (pass302,da288) > at scbus8 target 241 lun 0 (pass303,da289) > at scbus8 target 242 lun 0 (pass304,da290) > at scbus8 target 243 lun 0 (pass305,da291) > at scbus8 target 244 lun 0 (pass306,da292) > at scbus8 target 245 lun 0 (ses11,pass307) > at scbus8 target 246 lun 0 (pass308,da293) > at scbus8 target 247 lun 0 (pass309,da294) > at scbus8 target 248 lun 0 (pass310,da295) > at scbus8 target 249 lun 0 (pass311,da296) > at scbus8 target 250 lun 0 (pass312,da297) > at scbus8 target 251 lun 0 (pass313,da298) > at scbus8 target 252 lun 0 (pass314,da299) > at scbus8 target 253 lun 0 (pass315,da300) > at scbus8 target 254 lun 0 (pass316,da301) > at scbus8 target 255 lun 0 (da391,pass410) > at scbus8 target 256 lun 0 (pass317,da302) > at scbus8 target 257 lun 0 (pass318,da303) > at scbus8 target 258 lun 0 (pass319,da304) > at scbus8 target 259 lun 0 (pass320,da305) > at scbus8 target 260 lun 0 (pass321,da306) > at scbus8 target 261 lun 0 (pass322,da307) > at scbus8 target 262 lun 0 (pass323,da308) > at scbus8 target 263 lun 0 (pass324,da309) > at scbus8 target 264 lun 0 (pass325,da310) > at scbus8 target 265 lun 0 (pass326,da311) > at scbus8 target 266 lun 0 (pass327,da312) > at scbus8 target 267 lun 0 (pass328,da313) > at scbus8 target 268 lun 0 (pass329,da314) > at scbus8 target 269 lun 0 (pass330,da315) > at scbus8 target 270 lun 0 (ses12,pass331) > at scbus8 target 271 lun 0 (pass332,da316) > at scbus8 target 272 lun 0 (pass333,da317) > at scbus8 target 273 lun 0 (pass334,da318) > at scbus8 target 274 lun 0 (pass335,da319) > at scbus8 target 275 lun 0 (pass336,da320) > at scbus8 target 276 lun 0 (pass337,da321) > at scbus8 target 277 lun 0 (pass338,da322) > at scbus8 target 278 lun 0 (pass339,da323) > at scbus8 target 279 lun 0 (pass340,da324) > at scbus8 target 280 lun 0 (pass341,da325) > at scbus8 target 281 lun 0 (pass342,da326) > at scbus8 target 282 lun 0 (pass343,da327) > at scbus8 target 283 lun 0 (pass344,da328) > at scbus8 target 284 lun 0 (pass345,da329) > at scbus8 target 285 lun 0 (pass346,da330) > at scbus8 target 286 lun 0 (pass347,da331) > at scbus8 target 287 lun 0 (pass348,da332) > at scbus8 target 288 lun 0 (pass349,da333) > at scbus8 target 289 lun 0 (pass350,da334) > at scbus8 target 290 lun 0 (pass351,da335) > at scbus8 target 291 lun 0 (pass352,da336) > at scbus8 target 292 lun 0 (pass353,da337) > at scbus8 target 293 lun 0 (pass354,da338) > at scbus8 target 294 lun 0 (pass355,da339) > at scbus8 target 295 lun 0 (pass356,da340) > at scbus8 target 296 lun 0 (ses13,pass357) > at scbus8 target 297 lun 0 (pass358,da341) > at scbus8 target 298 lun 0 (pass359,da342) > at scbus8 target 299 lun 0 (pass360,da343) > at scbus8 target 300 lun 0 (pass361,da344) > at scbus8 target 301 lun 0 (pass362,da345) > at scbus8 target 302 lun 0 (pass363,da346) > at scbus8 target 303 lun 0 (pass364,da347) > at scbus8 target 304 lun 0 (pass365,da348) > at scbus8 target 305 lun 0 (pass366,da349) > at scbus8 target 306 lun 0 (pass367,da350) > at scbus8 target 307 lun 0 (pass368,da351) > at scbus8 target 308 lun 0 (pass369,da352) > at scbus8 target 309 lun 0 (pass370,da353) > at scbus8 target 310 lun 0 (pass371,da354) > at scbus8 target 311 lun 0 (pass372,da355) > at scbus8 target 312 lun 0 (pass373,da356) > at scbus8 target 313 lun 0 (pass374,da357) > at scbus8 target 314 lun 0 (pass375,da358) > at scbus8 target 315 lun 0 (pass376,da359) > at scbus8 target 316 lun 0 (pass377,da360) > at scbus8 target 317 lun 0 (pass378,da361) > at scbus8 target 318 lun 0 (pass379,da362) > at scbus8 target 319 lun 0 (pass380,da363) > at scbus8 target 320 lun 0 (pass381,da364) > at scbus8 target 321 lun 0 (ses14,pass382) > at scbus8 target 322 lun 0 (pass383,da365) > at scbus8 target 323 lun 0 (pass384,da366) > at scbus8 target 324 lun 0 (pass385,da367) > at scbus8 target 325 lun 0 (pass386,da368) > at scbus8 target 326 lun 0 (pass387,da369) > at scbus8 target 327 lun 0 (pass388,da370) > at scbus8 target 328 lun 0 (pass389,da371) > at scbus8 target 329 lun 0 (pass390,da372) > at scbus8 target 330 lun 0 (pass391,da373) > at scbus8 target 331 lun 0 (pass392,da374) > at scbus8 target 332 lun 0 (pass393,da375) > at scbus8 target 333 lun 0 (pass394,da376) > at scbus8 target 334 lun 0 (pass395,da377) > at scbus8 target 335 lun 0 (pass396,da378) > at scbus8 target 336 lun 0 (pass397,da379) > at scbus8 target 337 lun 0 (pass398,da380) > at scbus8 target 338 lun 0 (pass399,da381) > at scbus8 target 339 lun 0 (pass400,da382) > at scbus8 target 340 lun 0 (pass401,da383) > at scbus8 target 341 lun 0 (pass402,da384) > at scbus8 target 342 lun 0 (pass403,da385) > at scbus8 target 343 lun 0 (pass404,da386) > at scbus8 target 344 lun 0 (pass405,da387) > at scbus8 target 345 lun 0 (pass406,da388) > at scbus8 target 346 lun 0 (pass407,da389) > at scbus8 target 347 lun 0 (ses15,pass408) > > From owner-freebsd-scsi@FreeBSD.ORG Tue Sep 25 01:01:35 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E197106564A for ; Tue, 25 Sep 2012 01:01:35 +0000 (UTC) (envelope-from jim.harris@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1303D8FC12 for ; Tue, 25 Sep 2012 01:01:34 +0000 (UTC) Received: by vcbfw7 with SMTP id fw7so9005024vcb.13 for ; Mon, 24 Sep 2012 18:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=X64qbpR1XJMPg+aoUN0nqZuNx7qjrtkOtPg5oRpD/Vw=; b=I6mCnzfONZuCu20g7BBH8HwxYBDyh2YWrbc5fAA4N/E9ctqebnhQHSWvNa10yvdNBw Zx0I37JzKVHCwweKBM/1MBjBNCvPb/r6IxMbRIXDM1eBrSFmXJ51oeIezoQrsUbrDTpm tW5ASLkMmm8ZvWzg4tUrCy7XRCbjw+SpfqZrJCounbDcLuzrLOKdvFyWHec0g0XNJIdc JG/IqrG4rDhUzMdiAvYsooaI1b/+Wp9Qm/PwkKv5OLhoKvZqzvB9RA7xHQq9pc8WMw3t BX7GM7KXfu+0nT/oIm0xk71ikS1ALlk59uyPILx28AQj3ZR6ucWMYm0a7eoxl3/zvSQp PXMQ== MIME-Version: 1.0 Received: by 10.220.154.2 with SMTP id m2mr8430511vcw.18.1348534894143; Mon, 24 Sep 2012 18:01:34 -0700 (PDT) Sender: jim.harris@gmail.com Received: by 10.59.10.98 with HTTP; Mon, 24 Sep 2012 18:01:34 -0700 (PDT) In-Reply-To: <20120923140816.144270@gmx.net> References: <20120923140816.144270@gmx.net> Date: Mon, 24 Sep 2012 18:01:34 -0700 X-Google-Sender-Auth: _JUey3_iAnvV7jjwPYe9lP6qPB4 Message-ID: From: Jim Harris To: Paul Maulberger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi@freebsd.org Subject: Re: Intel C600 SAS Controller + locate LED (SGPIO) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 01:01:35 -0000 On Sun, Sep 23, 2012 at 7:08 AM, Paul Maulberger w= rote: > Hi Folks, > > I like to manipulate the eight locate LED's of my internal enclosure. The= following hardware is used: > > Mainboard: Supermicro X9DRi-F > http://www.supermicro.com/products/motherboard/xeon/c600/x9dri-f.cfm > > Chassis: SC825TQ-R740LPB > http://www.supermicro.com/products/chassis/2U/825/SC825TQ-R740LP.cfm > > Cable from Intel C602 SAS controller to backplane: > SFF-8087 to 4xSATA cable with 8-pin SGPIO connector > > The backplane of the chassis has the MagaRAC MG9072 chip from AMI and is = configured for SGPIO. > > I'm using FreeBSD 9.1 RC1. > > FreeBSD has a led driver to manipulate LED's: > http://www.freebsd.org/cgi/man.cgi?query=3Dled > > # ls -al /dev/led > total 1 > dr-xr-xr-x 2 root wheel 512 Sep 23 09:42 . > dr-xr-xr-x 10 root wheel 512 Sep 23 09:42 .. > crw------- 1 root wheel 0, 40 Sep 23 09:42 ahcich0.fault > crw------- 1 root wheel 0, 39 Sep 23 09:42 ahcich0.locate > crw------- 1 root wheel 0, 42 Sep 23 09:42 ahcich1.fault > crw------- 1 root wheel 0, 41 Sep 23 09:42 ahcich1.locate > crw------- 1 root wheel 0, 44 Sep 23 09:42 ahcich2.fault > crw------- 1 root wheel 0, 43 Sep 23 09:42 ahcich2.locate > crw------- 1 root wheel 0, 46 Sep 23 09:42 ahcich3.fault > crw------- 1 root wheel 0, 45 Sep 23 09:42 ahcich3.locate > crw------- 1 root wheel 0, 48 Sep 23 09:42 ahcich4.fault > crw------- 1 root wheel 0, 47 Sep 23 09:42 ahcich4.locate > crw------- 1 root wheel 0, 50 Sep 23 09:42 ahcich5.fault > crw------- 1 root wheel 0, 49 Sep 23 09:42 ahcich5.locate > crw------- 1 root wheel 0, 37 Sep 23 09:42 igb0 > crw------- 1 root wheel 0, 38 Sep 23 09:42 igb1 > > Unfortunately there are no "C600" led devices. > > I found the functions 'scic_sgpio_*' in the file 'sys/dev/isci/scil/scic_= sgpio.h'. The function 'scic_sgpio_hardware_initialize' is called in the fi= le 'sys/dev/isci/scil/scic_sds_controller.c'. Although there is no call to = 'scic_sgpio_set_led_state' or 'scic_sgpio_update_led_state' in the whole so= urces (/usr/src). > > Can somebody give me a hint how to manipulate the LED's? There's no way to manipulate the LEDs on the system as you have it. LED support is not in the current isci driver. But can you try this patch? http://people.freebsd.org/~jimharris/isci_led.patch The LEDs will show up as /dev/led/isci.busX.portY. On C60x SKUs with 8 isci ports (which I think yours has), the isci driver will create 2 buses of 4 ports each (to match the underlying silicon implementation), hence the need to use bus and port numbers in the name, rather than just port. Regards, -Jim > Regards > Paul > _______________________________________________ > 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 Tue Sep 25 03:09:53 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 821) id 2A1F61065674; Tue, 25 Sep 2012 03:09:53 +0000 (UTC) Date: Tue, 25 Sep 2012 03:09:53 +0000 From: John To: FreeBSD iSCSI Message-ID: <20120925030953.GA84605@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Performance question - istgt with dual 10g data links to linux client X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 03:09:53 -0000 Hi Folks, I have a bsd 9.1 zfs server running the latest istgt connected to a RHEL 6.1 system. Regardless of how I configure the systems, I cannot seem to exceed 1GB throughput. If I create a 25G /dev/md0 and export it via istgt (no mpio here), format it with default xfs values, place a 20G file on it, I get the following: dd if=/usr2/20g of=/dev/null bs=512K 40960+0 records in 40960+0 records out 21474836480 bytes (21 GB) copied, 21.4256 s, 1.0 GB/s Running the above /dev/md0 with mpio, dual paths on 10G cards, with rr_minio set anywhere from 1 to 100 on the linux side: [PortalGroup2] Comment "Two networks - one port" Portal DA1 10.59.6.14:5020 # 10G mtu 9000 Portal DA2 10.60.6.14:5020 # 10G mtu 9000 Comment "END: PortalGroup2" mpatha (33000000051ed39a4) dm-0 FreeBSD,USE136EXHF_iSCSI size=25G features='0' hwhandler='0' wp=rw `-+- policy='round-robin 0' prio=1 status=active |- 11:0:0:0 sdd 8:48 active ready running `- 12:0:0:0 sde 8:64 active ready running dd if=/usr2/20g of=/dev/null bs=1M 20480+0 records in 20480+0 records out 21474836480 bytes (21 GB) copied, 20.0076 s, 1.1 GB/s I can see the traffic evenly across both interfaces. I simply can't seem to get the parallelization factor up. Higher levels of mpio have no effect. I realize I haven't included the entire configuration. I'm hoping someone can give some high-level thoughts. I do need to maximize single process large file i/o.. Thanks, John ps: My next thought is to setup a non-unix box and see if I get the same results - and point at either client or server side issues. From owner-freebsd-scsi@FreeBSD.ORG Tue Sep 25 11:57:45 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7617D1065679; Tue, 25 Sep 2012 11:57:45 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3A7C58FC0C; Tue, 25 Sep 2012 11:57:45 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TGTlh-000K0W-9I; Tue, 25 Sep 2012 07:57:37 -0400 Date: Tue, 25 Sep 2012 07:57:37 -0400 From: Gary Palmer To: John Message-ID: <20120925115737.GE77784@in-addr.com> References: <20120925030953.GA84605@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120925030953.GA84605@FreeBSD.org> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: FreeBSD iSCSI Subject: Re: Performance question - istgt with dual 10g data links to linux client X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 11:57:45 -0000 On Tue, Sep 25, 2012 at 03:09:53AM +0000, John wrote: > Hi Folks, > > I have a bsd 9.1 zfs server running the latest istgt connected to a > RHEL 6.1 system. Regardless of how I configure the systems, I cannot seem > to exceed 1GB throughput. If I create a 25G /dev/md0 and export it via > istgt (no mpio here), format it with default xfs values, place a > 20G file on it, I get the following: > > dd if=/usr2/20g of=/dev/null bs=512K > 40960+0 records in > 40960+0 records out > 21474836480 bytes (21 GB) copied, 21.4256 s, 1.0 GB/s > > Running the above /dev/md0 with mpio, dual paths on 10G cards, with > rr_minio set anywhere from 1 to 100 on the linux side: > > [PortalGroup2] > Comment "Two networks - one port" > Portal DA1 10.59.6.14:5020 # 10G mtu 9000 > Portal DA2 10.60.6.14:5020 # 10G mtu 9000 > Comment "END: PortalGroup2" > > mpatha (33000000051ed39a4) dm-0 FreeBSD,USE136EXHF_iSCSI > size=25G features='0' hwhandler='0' wp=rw > `-+- policy='round-robin 0' prio=1 status=active > |- 11:0:0:0 sdd 8:48 active ready running > `- 12:0:0:0 sde 8:64 active ready running > > > dd if=/usr2/20g of=/dev/null bs=1M > 20480+0 records in > 20480+0 records out > 21474836480 bytes (21 GB) copied, 20.0076 s, 1.1 GB/s > > I can see the traffic evenly across both interfaces. I simply > can't seem to get the parallelization factor up. Higher levels > of mpio have no effect. > > I realize I haven't included the entire configuration. I'm hoping > someone can give some high-level thoughts. I do need to maximize > single process large file i/o.. Have you tried doing two dd's at the same time when you have mpio running? I'd be curious to know if you get double the throughput or if each dd gets 0.5GB/s Gary From owner-freebsd-scsi@FreeBSD.ORG Tue Sep 25 15:02:50 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DDC68106566C; Tue, 25 Sep 2012 15:02:50 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id A36DE8FC0A; Tue, 25 Sep 2012 15:02:50 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q8PEsZ1C054388; Tue, 25 Sep 2012 08:54:35 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q8PEsZFx054387; Tue, 25 Sep 2012 08:54:35 -0600 (MDT) (envelope-from ken) Date: Tue, 25 Sep 2012 08:54:35 -0600 From: "Kenneth D. Merry" To: John Message-ID: <20120925145435.GA52990@nargothrond.kdm.org> References: <20120915022437.GA90210@FreeBSD.org> <20120915023329.GA55292@nargothrond.kdm.org> <20120915031305.GA97685@FreeBSD.org> <20120915032826.GA63349@nargothrond.kdm.org> <20120915040907.GA5458@FreeBSD.org> <20120915043938.GA71754@nargothrond.kdm.org> <20120916221550.GA63055@FreeBSD.org> <20120924172648.GA96855@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120924172648.GA96855@FreeBSD.org> User-Agent: Mutt/1.4.2i Cc: FreeBSD iSCSI Subject: Re: How to force a reset of a device (disk) in an enclosre slot (PATCH) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 15:02:51 -0000 On Mon, Sep 24, 2012 at 17:26:48 +0000, John wrote: > Hi Ken, > > The following patch fixes the problem: > > Index: mps_sas.c > =================================================================== > --- mps_sas.c (revision 240879) > +++ mps_sas.c (working copy) > @@ -918,7 +918,7 @@ > cpi->hba_eng_cnt = 0; > cpi->max_target = sassc->sc->facts->MaxTargets - 1; > cpi->max_lun = 255; > - cpi->initiator_id = 255; > + cpi->initiator_id = sassc->sc->facts->MaxTargets; > strncpy(cpi->sim_vid, "FreeBSD", SIM_IDLEN); > strncpy(cpi->hba_vid, "LSILogic", HBA_IDLEN); > strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN); > > > I simply set the id to the value after the last possible target > for the card. Does that seem reasonable to you? Ahh, good catch! > > If you don't mind, I'll commit this if there are no objections. Sure, go ahead and commit it. > Thanks to you and others for pointing me in the right direction :-) No problem, sorry for dropping the ball on looking into this one. But, I'm glad you found it! Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Tue Sep 25 19:33:09 2012 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 821) id 48E8D1065672; Tue, 25 Sep 2012 19:33:09 +0000 (UTC) Date: Tue, 25 Sep 2012 19:33:09 +0000 From: John To: FreeBSD iSCSI Message-ID: <20120925193309.GA60590@FreeBSD.org> References: <20120925030953.GA84605@FreeBSD.org> <20120925115737.GE77784@in-addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120925115737.GE77784@in-addr.com> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Performance question - istgt with dual 10g data links to linux client X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 19:33:09 -0000 ----- Gary Palmer's Original Message ----- > On Tue, Sep 25, 2012 at 03:09:53AM +0000, John wrote: > > Hi Folks, > > > > I have a bsd 9.1 zfs server running the latest istgt connected to a > > RHEL 6.1 system. Regardless of how I configure the systems, I cannot seem > > to exceed 1GB throughput. If I create a 25G /dev/md0 and export it via > > istgt (no mpio here), format it with default xfs values, place a > > 20G file on it, I get the following: > > > > dd if=/usr2/20g of=/dev/null bs=512K > > 40960+0 records in > > 40960+0 records out > > 21474836480 bytes (21 GB) copied, 21.4256 s, 1.0 GB/s > > > > Running the above /dev/md0 with mpio, dual paths on 10G cards, with > > rr_minio set anywhere from 1 to 100 on the linux side: > > > > [PortalGroup2] > > Comment "Two networks - one port" > > Portal DA1 10.59.6.14:5020 # 10G mtu 9000 > > Portal DA2 10.60.6.14:5020 # 10G mtu 9000 > > Comment "END: PortalGroup2" > > > > mpatha (33000000051ed39a4) dm-0 FreeBSD,USE136EXHF_iSCSI > > size=25G features='0' hwhandler='0' wp=rw > > `-+- policy='round-robin 0' prio=1 status=active > > |- 11:0:0:0 sdd 8:48 active ready running > > `- 12:0:0:0 sde 8:64 active ready running > > > > > > dd if=/usr2/20g of=/dev/null bs=1M > > 20480+0 records in > > 20480+0 records out > > 21474836480 bytes (21 GB) copied, 20.0076 s, 1.1 GB/s > > > > I can see the traffic evenly across both interfaces. I simply > > can't seem to get the parallelization factor up. Higher levels > > of mpio have no effect. > > > > I realize I haven't included the entire configuration. I'm hoping > > someone can give some high-level thoughts. I do need to maximize > > single process large file i/o.. > > Have you tried doing two dd's at the same time when you have mpio running? > I'd be curious to know if you get double the throughput or if each dd > gets 0.5GB/s > Hi Gary, Not what I expected... 1/2 the bandwith to each. Had to increase the md0 size to place two different 10g files on the server otherwise the local system cache handled the request for the trailing dd. Below are three test runs. First linear, 2nd two in paralell. /tmp/dd.log.p1.1 40960+0 records in 40960+0 records out 21474836480 bytes (21 GB) copied, 20.4676 s, 1.0 GB/s p1p1 Link encap:Ethernet HWaddr 00:07:43:09:16:AE inet addr:10.60.25.1 Bcast:10.255.255.255 Mask:255.255.0.0 inet6 addr: fe80::207:43ff:fe09:16ae/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:1527823 errors:0 dropped:0 overruns:0 frame:0 TX packets:771887 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:2000 RX bytes:10847808152 (10.1 GiB) TX bytes:57137678 (54.4 MiB) Interrupt:38 Memory:df1fe000-df1fefff p2p1 Link encap:Ethernet HWaddr 00:07:43:08:10:66 inet addr:10.59.25.1 Bcast:10.255.255.255 Mask:255.255.0.0 inet6 addr: fe80::207:43ff:fe08:1066/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:1531304 errors:0 dropped:0 overruns:0 frame:0 TX packets:773255 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:2000 RX bytes:10848499338 (10.1 GiB) TX bytes:57238014 (54.5 MiB) Interrupt:40 Memory:df2fe000-df2fefff Note, the two 10 (Chelsio) cards show equal traffic. Now the two runs in parallel: /tmp/dd.log.p2.1 40960+0 records in 40960+0 records out 21474836480 bytes (21 GB) copied, 38.0411 s, 565 MB/s /tmp/dd.log.p2.2 40960+0 records in 40960+0 records out 21474836480 bytes (21 GB) copied, 37.9768 s, 565 MB/s p1p1 Link encap:Ethernet HWaddr 00:07:43:09:16:AE inet addr:10.60.25.1 Bcast:10.255.255.255 Mask:255.255.0.0 inet6 addr: fe80::207:43ff:fe09:16ae/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:4592000 errors:0 dropped:0 overruns:0 frame:0 TX packets:2319975 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:2000 RX bytes:32541584154 (30.3 GiB) TX bytes:168531554 (160.7 MiB) Interrupt:38 Memory:df1fe000-df1fefff p2p1 Link encap:Ethernet HWaddr 00:07:43:08:10:66 inet addr:10.59.25.1 Bcast:10.255.255.255 Mask:255.255.0.0 inet6 addr: fe80::207:43ff:fe08:1066/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:4596909 errors:0 dropped:0 overruns:0 frame:0 TX packets:2320666 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:2000 RX bytes:32542835932 (30.3 GiB) TX bytes:168585152 (160.7 MiB) Interrupt:40 Memory:df2fe000-df2fefff Ok. Now create 2 md devices, md0 & md1. Place a 20G file on each device and export them via iscsi. # mdconfig -l -v md0 malloc 23G md1 malloc 23G They show up on the linux system as two separate multipath devices: mpathb (3300000008aa9becd) dm-1 FreeBSD,USE136EXHF_iSCSI size=23G features='0' hwhandler='0' wp=rw `-+- policy='round-robin 0' prio=-1 status=active |- 17:0:0:0 sde 8:64 active undef running `- 18:0:0:0 sdg 8:96 active undef running mpatha (33000000051ed39a4) dm-0 FreeBSD,USE136EXHF_iSCSI size=23G features='0' hwhandler='0' wp=rw `-+- policy='round-robin 0' prio=-1 status=active |- 15:0:0:0 sdd 8:48 active undef running `- 16:0:0:0 sdf 8:80 active undef running Filesystem Size Used Avail Use% Mounted on /dev/mapper/mpatha 23G 21G 3.0G 88% /usr2 /dev/mapper/mpathb 23G 21G 3.0G 88% /usr3 Run a dd to each target reading out the 20G file. dd if=/usr2/20g of=/dev/null bs=512K 40960+0 records in 40960+0 records out 21474836480 bytes (21 GB) copied, 25.0937 s, 856 MB/s dd if=/usr3/20g of=/dev/null bs=512K 40960+0 records in 40960+0 records out 21474836480 bytes (21 GB) copied, 24.8599 s, 864 MB/s More along the lines of what I expected. About 1.7GB per second total coming from the server. Which leaves me with the question: Is istgt or multipath the bottleneck? Thoughts? Thanks! John From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 26 00:57:10 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1D2A1065672; Wed, 26 Sep 2012 00:57:10 +0000 (UTC) (envelope-from jim.harris@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1F4FD8FC0A; Wed, 26 Sep 2012 00:57:09 +0000 (UTC) Received: by vcbfw7 with SMTP id fw7so55917vcb.13 for ; Tue, 25 Sep 2012 17:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=CmGcjDOuYKijj+IWiAhKwFKw4TqbT8udksKtn/Iogzo=; b=iBndZ8IsoHbsoUG7KoXXkytZwOtHJ/ZzR57fnFNA5gptw1KBoXM1xz59s2RK1p9ToV VS6lcizb4/9m0+YEjrvTKpXz13DBQ/nhIdTlE30B3YfUoG/USkaV7t7T5+pPOgkk+v1q +EiT4CQfw2cpwEVr/zMbze/lyhNH2EziyWOAZ7iex5XdWqQF/sQDzQbSsIA5GT1/NS/i f+FEL0W+XkAstqVgEx76T1hkYQlScKAKPWDRLB4h+xKfCTsVIvjGYqUuZRtuvzAj6UNN BP+PmPlAtTYytdUT8n9M/7ZnLT4g1h1X1N+eTU6g+NC1ZK3NgNZc/u2BQ//p5xLeP2TZ i6Bg== MIME-Version: 1.0 Received: by 10.52.75.70 with SMTP id a6mr8332425vdw.5.1348621028995; Tue, 25 Sep 2012 17:57:08 -0700 (PDT) Sender: jim.harris@gmail.com Received: by 10.59.10.98 with HTTP; Tue, 25 Sep 2012 17:57:08 -0700 (PDT) In-Reply-To: <20120924172648.GA96855@FreeBSD.org> References: <20120915022437.GA90210@FreeBSD.org> <20120915023329.GA55292@nargothrond.kdm.org> <20120915031305.GA97685@FreeBSD.org> <20120915032826.GA63349@nargothrond.kdm.org> <20120915040907.GA5458@FreeBSD.org> <20120915043938.GA71754@nargothrond.kdm.org> <20120916221550.GA63055@FreeBSD.org> <20120924172648.GA96855@FreeBSD.org> Date: Tue, 25 Sep 2012 17:57:08 -0700 X-Google-Sender-Auth: g5s-b-xOlkeitC3Bsy2H13-FQ9w Message-ID: From: Jim Harris To: John Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD iSCSI , "Kenneth D. Merry" Subject: Re: How to force a reset of a device (disk) in an enclosre slot (PATCH) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 00:57:10 -0000 On Mon, Sep 24, 2012 at 10:26 AM, John wrote: > Hi Ken, > > The following patch fixes the problem: > > Index: mps_sas.c > =================================================================== > --- mps_sas.c (revision 240879) > +++ mps_sas.c (working copy) > @@ -918,7 +918,7 @@ > cpi->hba_eng_cnt = 0; > cpi->max_target = sassc->sc->facts->MaxTargets - 1; > cpi->max_lun = 255; > - cpi->initiator_id = 255; > + cpi->initiator_id = sassc->sc->facts->MaxTargets; > strncpy(cpi->sim_vid, "FreeBSD", SIM_IDLEN); > strncpy(cpi->hba_vid, "LSILogic", HBA_IDLEN); > strncpy(cpi->dev_name, cam_sim_name(sim), DEV_IDLEN); > > > I simply set the id to the value after the last possible target > for the card. Does that seem reasonable to you? > > If you don't mind, I'll commit this if there are no objections. I think the patch is fine, but I'm wondering if the scsi_xpt.c code should instead (or also) ignore the initiator_id if cpi->transport == XPORT_SAS? initiator_id isn't really valid for SAS transport. > Thanks to you and others for pointing me in the right direction :-) > > Thanks, > John > > ----- John's Original Message ----- >> ----- Kenneth D. Merry's Original Message ----- >> > On Sat, Sep 15, 2012 at 04:09:07 +0000, John wrote: >> > > ----- Kenneth D. Merry's Original Message ----- >> > > > On Sat, Sep 15, 2012 at 03:13:05 +0000, John wrote: >> > > > > ----- Kenneth D. Merry's Original Message ----- >> > > > > > On Sat, Sep 15, 2012 at 02:24:37 +0000, John wrote: >> > > > > > > Hi Folks, >> > > > > > > >> > > > > > > I've been poking around and can't seem to find a way to reset and >> > > > > > > hopefully acquire access to a disk device in an enclosure. For instance: >> > > > > > > >> > > > > > > FreeBSD 9.1-PRERELEASE >> > > > > > > >> > > > > > > # camcontrol smpphylist ses4 >> > > > > > > 37 PHYs: >> > > > > > > PHY Attached SAS Address >> > > > > > > 0 0x5000039368233602 (pass105,da98) >> > > > > > > 1 0x5000039368238e3e (pass106,da99) >> > > > > > > 2 0x500003936823bca2 (pass107,da100) >> > > > > > > 3 0x500003936819507e (pass108,da101) >> > > > > > > 4 0x5000039368197d5a (pass109,da102) >> > > > > > > 5 0x5000039368197c6e (pass110,da103) >> > > > > > > 6 0x500003936818770e (pass111,da104) >> > > > > > > 7 0x5000039368238eba (pass112,da105) >> > > > > > > 8 0x5000039368232f42 (pass113,da106) >> > > > > > > 9 0x0000000000000000 >> > > > > > > 10 0x500003936813c31e >> > > > > > > 11 0x5000039368233892 (pass114,da107) >> > > > > > > 12 0x500003936813c2ca (pass115,da108) >> > > > > > > ... >> > > > > > > >> > > > > > > Note, bay/slot 10 has a listed device address. If I were to pull the >> > > > > > > drive and re-insert it, it would show up (as da390 in this case). >> > > > > > > The above is after a fresh reboot. Note da106 to da107 skipping >> > > > > > > slot 10 (slot 9 is empty). >> > > > > > > >> > > > > > > The smp utils provide a similar view: >> > > > > > > >> > > > > > > # smp_discover /dev/ses4 >> > > > > > > phy 0:D:attached:[5000039368233602:00 t(SSP)] 6 Gbps >> > > > > > > phy 1:D:attached:[5000039368238e3e:00 t(SSP)] 6 Gbps >> > > > > > > phy 2:D:attached:[500003936823bca2:00 t(SSP)] 6 Gbps >> > > > > > > phy 3:D:attached:[500003936819507e:00 t(SSP)] 6 Gbps >> > > > > > > phy 4:D:attached:[5000039368197d5a:00 t(SSP)] 6 Gbps >> > > > > > > phy 5:D:attached:[5000039368197c6e:00 t(SSP)] 6 Gbps >> > > > > > > phy 6:D:attached:[500003936818770e:00 t(SSP)] 6 Gbps >> > > > > > > phy 7:D:attached:[5000039368238eba:00 t(SSP)] 6 Gbps >> > > > > > > phy 8:D:attached:[5000039368232f42:00 t(SSP)] 6 Gbps >> > > > > > > phy 10:D:attached:[500003936813c31e:00 t(SSP)] 6 Gbps >> > > > > > > phy 11:D:attached:[5000039368233892:00 t(SSP)] 6 Gbps >> > > > > > > phy 12:D:attached:[500003936813c2ca:00 t(SSP)] 6 Gbps >> > > > > > > ... >> > > > > > > >> > > > > > > The address of slot 10 matches. There is a disk in the slot - just >> > > > > > > isn't recognized and attached. >> > > > > > > >> > > > > > > Back to the basic question. How can I issue a command to the enclosure >> > > > > > > to force a re-initialization of the device to recover it without >> > > > > > > having to physically pull & insert it. Even if the device numbers >> > > > > > > are not sequential, I need access to the drive... >> > > > > > >> > > > > > You can try sending a link reset: >> > > > > > >> > > > > > camcontrol smppc ses4 -p 10 -o linkreset >> > > > > > >> > > > > > It may or may not work. You can also try disabling the PHY (-o disable) >> > > > > > and then sending a link reset to re-enable the link. You can also try a >> > > > > > hard reset (-o hardreset) >> > > > > >> > > > > Hi Ken, >> > > > > >> > > > > Well, I hadn't tried to actually disable the device. That did bring some >> > > > > reaction: >> > > > > >> > > > > # camcontrol smppc ses4 -p 10 -o disable >> > > > > # camcontrol smpphylist ses4 >> > > > > 37 PHYs: >> > > > > PHY Attached SAS Address >> > > > > 0 0x5000039368233602 (pass105,da98) >> > > > > .... >> > > > > 8 0x5000039368232f42 (pass113,da106) >> > > > > 9 0x0000000000000000 >> > > > > 10 0x0000000000000000 >> > > > > 11 0x5000039368233892 (pass114,da107) >> > > > > ... >> > > > > >> > > > > The device is gone. >> > > > > >> > > > > # camcontrol smppc ses4 -p 10 -o hardreset >> > > > > root@vprzfs01p:/root # camcontrol smpphylist ses4 >> > > > > 37 PHYs: >> > > > > PHY Attached SAS Address >> > > > > 0 0x5000039368233602 (pass105,da98) >> > > > > .... >> > > > > 8 0x5000039368232f42 (pass113,da106) >> > > > > 9 0x0000000000000000 >> > > > > 10 0x500003936813c31e >> > > > > 11 0x5000039368233892 (pass114,da107) >> > > > > ... >> > > > > >> > > > > The device is back, but not attached - This msg: >> > > > > >> > > > > kernel: mps1: mpssas_alloc_tm freezing simq >> > > > > kernel: mps1: mpssas_remove_complete on handle 0x0069, IOCStatus= 0x0 >> > > > > kernel: mps1: mpssas_free_tm releasing simq >> > > > > kernel: _mapping_add_new_device: failed to add the device with handle 0x0069 to persistent table because there is no free space available - entry 0 >> > > > >> > > > That message is harmless, it won't prevent the drive from attaching. >> > > > >> > > > > >From a debug statement in the driver: MaxPersistentEntries == 128, but I >> > > > > have more than 128 devices per LSI card and they normally all show up - >> > > > > though I do get a bunch of the above messages in dmesg.. >> > > > >> > > > You might try turning on some of the debugging in the mps(4) driver and >> > > > disabling and resetting the link again. >> > > > >> > > > Try: >> > > > >> > > > sysctl -w dev.mps.0.debug_level=0xf >> > > > >> > > > You might get a lot of output, so be prepared to reset it back to 4: >> > > > >> > > > sysctl -w dev.mps.0.debug_level=4 >> > > >> > > Hi Ken, >> > > >> > > I don't see anything obvious. Hopefully you're more familair with the >> > > code and have better eyes than I do... Here's everything from messages >> > > after the -o disable. There are some "unknown/unhandled"s showing up. >> > >> > Here is where the drive shows up: >> > >> > > kernel: mps_intr_locked sc 0xffffff8001353000 writing postindex 243 >> > > kernel: mps_enqueue_request SMID 653 cm 0xffffff80013ca4a8 ccb 0 >> > > kernel: mps_intr_locked sc 0xffffff8001353000 starting with replypostindex 243 >> > > kernel: mps_intr_locked sc 0xffffff8001353000 writing postindex 244 >> > > kernel: SAS Address from SAS device page0 = 500003936811feae >> > > kernel: Found device <401,End Device> <6.0Gbps> <0x0078> <4/36> >> > > kernel: mpssas_rescan_target targetid 255 >> > > kernel: mpssas_rescan >> > > kernel: >> > > kernel: Target id 0xff added >> > >> > It finds the device, with target ID 255 (which is a little suspicious) and >> > queues a rescan, but nothing happens after that. >> > >> > You might try doing a manual rescan of that device to see what happens: >> > >> > camcontrol rescan X:255:0 >> > >> > Where X is the scbus number from camcontrol devlist. >> > >> > If that doesn't work, then we need to figure out what the maximum number of >> > targets supported by the adapter is. To do that, set this in >> > /boot/loader.conf and reboot: >> > >> > hw.mps.debug_level=1 >> > >> > That should result in the IOCFacts page getting printed on boot. >> > >> > How many drives and other devices are currently attached to that >> > controller? What controller model is it, and do you have IT or IR >> > firmware on it? >> >> >> >> >> Hi Ken, >> >> First to some of your questions. There are 3 LSI cards installed >> in the box. LSI 2116 - One 16i (not in use) and a pair of 16e. There >> are 8 d2700 shelves attached to the 16e cards - dual channel. Eight >> shelves, 25 devices each: 200 disks, dual attached, da0 - da399 for >> fully populated shelves.. The IOCFacts are included at the end of this >> email. I think you've seen this diagram before: >> >> http://people.freebsd.org/~jwd/zfsnfsserver.jpg >> >> I think there is something to your comment about device id 255 >> being suspicious. >> >> After a fresh reboot, it appears that device 255 on both busses >> is missing. Issuing just the commands: >> >> camcontrol rescan 7:255:0 >> camcontrol rescan 8:255:0 >> >> and the drives show up: >> >> mps1: handle(0x0062), ioc_status(scsi data underrun)(0x0045), >> mps1: scsi_status(good)(0x00), scsi_state( )(0x00) >> mps1: handle(0x0062), ioc_status(scsi data underrun)(0x0045), >> mps1: scsi_status(good)(0x00), scsi_state( )(0x00) >> mps1: handle(0x0062), ioc_status(scsi data underrun)(0x0045), >> mps1: scsi_status(good)(0x00), scsi_state( )(0x00) >> da390 at mps1 bus 0 scbus7 target 255 lun 0 >> da390: Fixed Direct Access SCSI-5 device >> da390: 600.000MB/s transfers >> da390: Command Queueing enabled >> da390: 572325MB (1172123568 512 byte sectors: 255H 63S/T 72961C) >> GEOM_MULTIPATH: da390 added to Z78 >> mps2: handle(0x0069), ioc_status(scsi data underrun)(0x0045), >> mps2: scsi_status(good)(0x00), scsi_state( )(0x00) >> mps2: handle(0x0069), ioc_status(scsi data underrun)(0x0045), >> mps2: scsi_status(good)(0x00), scsi_state( )(0x00) >> mps2: handle(0x0069), ioc_status(scsi data underrun)(0x0045), >> mps2: scsi_status(good)(0x00), scsi_state( )(0x00) >> da391 at mps2 bus 0 scbus8 target 255 lun 0 >> da391: Fixed Direct Access SCSI-5 device >> da391: 600.000MB/s transfers >> da391: Command Queueing enabled >> da391: 572325MB (1172123568 512 byte sectors: 255H 63S/T 72961C) >> GEOM_MULTIPATH: da391 added to Z75 >> >> I don't know if the 'scsi data underrun' is important here. >> A camcontrol smpphylist of the two related shelves. Note, there >> is no device is bay 9. >> >> # camcontrol smpphylist ses4 >> 37 PHYs: >> PHY Attached SAS Address >> 0 0x500003936812dd36 (pass105,da98) >> .... >> 8 0x500003936810b756 (pass113,da106) >> 9 0x0000000000000000 >> 10 0x500003936811feae (da390,pass409) >> ... >> 24 0x500003936819898a (pass127,da120) >> >> # camcontrol smpphylist ses12 >> 37 PHYs: >> PHY Attached SAS Address >> 0 0x5000c5003c4f5986 (pass308,da293) >> .... >> 8 0x5000c5003c4f5ebe (pass316,da301) >> 9 0x0000000000000000 >> 10 0x5000c5003c375b86 (da391,pass410) >> ... >> 24 0x5000c5003c00cb7a (pass330,da315) >> >> >> On a related note, the pass & da devices are reversed for the two >> devices found via the rescan. >> >> I've been scanning the driver code but don't see an obvious place >> where device id 255 would be dropped. Please let me know if there is >> something you'd like me to check. >> >> >> This has been a learning experience. Thanks Ken. >> >> Thanks, >> John >> >> >> 16i card: (Not currenlty in use) >> >> mps0: port 0x5000-0x50ff mem 0xfbdf0000-0xfbdf3fff,0xfbd80000-0xfbdbffff irq 52 at device 0.0 on pci24 >> mps0: Doorbell= 0x12000000 >> mps0: IOCFacts : >> MsgVersion: 0x200 >> HeaderVersion: 0x1900 >> IOCNumber: 0 >> IOCExceptions: 0x0 >> MaxChainDepth: 128 >> WhoInit: ROM BIOS >> NumberOfPorts: 1 >> RequestCredit: 7632 >> ProductID: 0x2213 >> IOCCapabilities: 1285c >> FWVersion= 14-0-0-0 >> IOCRequestFrameSize: 32 >> MaxInitiators: 30 >> MaxTargets: 756 >> MaxSasExpanders: 224 >> MaxEnclosures: 224 >> ProtocolFlags: 3 >> HighPriorityCredit: 120 >> MaxReplyDescriptorPostQueueDepth: 65504 >> ReplyFrameSize: 32 >> MaxVolumes: 0 >> MaxDevHandle: 1026 >> MaxPersistentEntries: 128 >> mps0: Firmware: 14.00.00.00, Driver: 14.00.00.01-fbsd >> mps0: IOCCapabilities: 1285c >> >> >> >> 1st 16e card: >> >> >> mps1: port 0x7000-0x70ff mem 0xfbff0000-0xfbff3fff,0xfbf80000-0xfbfbffff irq 48 at device 0.0 on pci33 >> mps1: Doorbell= 0x12000000 >> mps1: IOCFacts : >> MsgVersion: 0x200 >> HeaderVersion: 0x1900 >> IOCNumber: 0 >> IOCExceptions: 0x0 >> MaxChainDepth: 128 >> WhoInit: ROM BIOS >> NumberOfPorts: 1 >> RequestCredit: 32455 >> ProductID: 0x2213 >> IOCCapabilities: 1285c >> FWVersion= 14-0-0-0 >> IOCRequestFrameSize: 32 >> MaxInitiators: 32 >> MaxTargets: 1024 >> MaxSasExpanders: 128 >> MaxEnclosures: 129 >> ProtocolFlags: 3 >> HighPriorityCredit: 127 >> MaxReplyDescriptorPostQueueDepth: 65504 >> ReplyFrameSize: 32 >> MaxVolumes: 0 >> MaxDevHandle: 1200 >> MaxPersistentEntries: 128 >> mps1: Firmware: 14.00.00.00, Driver: 14.00.00.01-fbsd >> mps1: IOCCapabilities: 1285c >> >> 2nd 16e card: >> >> mps2: port 0x6000-0x60ff mem 0xfbef0000-0xfbef3fff,0xfbe80000-0xfbebffff irq 56 at device 0.0 on pci27 >> mps2: Doorbell= 0x12000000 >> mps2: IOCFacts : >> MsgVersion: 0x200 >> HeaderVersion: 0x1900 >> IOCNumber: 0 >> IOCExceptions: 0x0 >> MaxChainDepth: 128 >> WhoInit: ROM BIOS >> NumberOfPorts: 1 >> RequestCredit: 32455 >> ProductID: 0x2213 >> IOCCapabilities: 1285c >> FWVersion= 14-0-0-0 >> IOCRequestFrameSize: 32 >> MaxInitiators: 32 >> MaxTargets: 1024 >> MaxSasExpanders: 128 >> MaxEnclosures: 129 >> ProtocolFlags: 3 >> HighPriorityCredit: 127 >> MaxReplyDescriptorPostQueueDepth: 65504 >> ReplyFrameSize: 32 >> MaxVolumes: 0 >> MaxDevHandle: 1200 >> MaxPersistentEntries: 128 >> mps2: Firmware: 14.00.00.00, Driver: 14.00.00.01-fbsd >> mps2: IOCCapabilities: 1285c >> >> >> And here is the entire device listing after running the pair >> of camcontrol rescan commands. Note, the OS lives on the revodrive. >> All shelf drives are for data. >> >> >> at scbus0 target 0 lun 0 (ada0,pass0) >> at scbus1 target 0 lun 0 (ada1,pass1) >> at scbus5 target 0 lun 0 (pass2,cd0) >> at scbus7 target 144 lun 0 (pass3,da0) >> at scbus7 target 145 lun 0 (pass4,da1) >> at scbus7 target 146 lun 0 (pass5,da2) >> at scbus7 target 147 lun 0 (pass6,da3) >> at scbus7 target 148 lun 0 (pass7,da4) >> at scbus7 target 149 lun 0 (pass8,da5) >> at scbus7 target 150 lun 0 (pass9,da6) >> at scbus7 target 151 lun 0 (pass10,da7) >> at scbus7 target 152 lun 0 (pass11,da8) >> at scbus7 target 153 lun 0 (pass12,da9) >> at scbus7 target 154 lun 0 (pass13,da10) >> at scbus7 target 155 lun 0 (pass14,da11) >> at scbus7 target 156 lun 0 (pass15,da12) >> at scbus7 target 157 lun 0 (pass16,da13) >> at scbus7 target 158 lun 0 (pass17,da14) >> at scbus7 target 159 lun 0 (pass18,da15) >> at scbus7 target 160 lun 0 (pass19,da16) >> at scbus7 target 161 lun 0 (pass20,da17) >> at scbus7 target 162 lun 0 (pass21,da18) >> at scbus7 target 163 lun 0 (pass22,da19) >> at scbus7 target 164 lun 0 (pass23,da20) >> at scbus7 target 165 lun 0 (pass24,da21) >> at scbus7 target 166 lun 0 (pass25,da22) >> at scbus7 target 167 lun 0 (pass26,da23) >> at scbus7 target 168 lun 0 (ses0,pass27) >> at scbus7 target 169 lun 0 (pass28,da24) >> at scbus7 target 170 lun 0 (pass29,da25) >> at scbus7 target 171 lun 0 (pass30,da26) >> at scbus7 target 172 lun 0 (pass31,da27) >> at scbus7 target 173 lun 0 (pass32,da28) >> at scbus7 target 174 lun 0 (pass33,da29) >> at scbus7 target 175 lun 0 (pass34,da30) >> at scbus7 target 176 lun 0 (pass35,da31) >> at scbus7 target 177 lun 0 (pass36,da32) >> at scbus7 target 178 lun 0 (pass37,da33) >> at scbus7 target 179 lun 0 (pass38,da34) >> at scbus7 target 180 lun 0 (pass39,da35) >> at scbus7 target 181 lun 0 (pass40,da36) >> at scbus7 target 182 lun 0 (pass41,da37) >> at scbus7 target 183 lun 0 (pass42,da38) >> at scbus7 target 184 lun 0 (pass43,da39) >> at scbus7 target 185 lun 0 (pass44,da40) >> at scbus7 target 186 lun 0 (pass45,da41) >> at scbus7 target 187 lun 0 (pass46,da42) >> at scbus7 target 188 lun 0 (pass47,da43) >> at scbus7 target 189 lun 0 (pass48,da44) >> at scbus7 target 190 lun 0 (pass49,da45) >> at scbus7 target 191 lun 0 (pass50,da46) >> at scbus7 target 192 lun 0 (pass51,da47) >> at scbus7 target 193 lun 0 (pass52,da48) >> at scbus7 target 194 lun 0 (ses1,pass53) >> at scbus7 target 195 lun 0 (pass54,da49) >> at scbus7 target 196 lun 0 (pass55,da50) >> at scbus7 target 197 lun 0 (pass56,da51) >> at scbus7 target 198 lun 0 (pass57,da52) >> at scbus7 target 199 lun 0 (pass58,da53) >> at scbus7 target 200 lun 0 (pass59,da54) >> at scbus7 target 201 lun 0 (pass60,da55) >> at scbus7 target 202 lun 0 (pass61,da56) >> at scbus7 target 203 lun 0 (pass62,da57) >> at scbus7 target 204 lun 0 (pass63,da58) >> at scbus7 target 205 lun 0 (pass64,da59) >> at scbus7 target 206 lun 0 (pass65,da60) >> at scbus7 target 207 lun 0 (pass66,da61) >> at scbus7 target 208 lun 0 (pass67,da62) >> at scbus7 target 209 lun 0 (pass68,da63) >> at scbus7 target 210 lun 0 (pass69,da64) >> at scbus7 target 211 lun 0 (pass70,da65) >> at scbus7 target 212 lun 0 (pass71,da66) >> at scbus7 target 213 lun 0 (pass72,da67) >> at scbus7 target 214 lun 0 (pass73,da68) >> at scbus7 target 215 lun 0 (pass74,da69) >> at scbus7 target 216 lun 0 (pass75,da70) >> at scbus7 target 217 lun 0 (pass76,da71) >> at scbus7 target 218 lun 0 (pass77,da72) >> at scbus7 target 219 lun 0 (ses2,pass78) >> at scbus7 target 220 lun 0 (pass79,da73) >> at scbus7 target 221 lun 0 (pass80,da74) >> at scbus7 target 222 lun 0 (pass81,da75) >> at scbus7 target 223 lun 0 (pass82,da76) >> at scbus7 target 224 lun 0 (pass83,da77) >> at scbus7 target 225 lun 0 (pass84,da78) >> at scbus7 target 226 lun 0 (pass85,da79) >> at scbus7 target 227 lun 0 (pass86,da80) >> at scbus7 target 228 lun 0 (pass87,da81) >> at scbus7 target 229 lun 0 (pass88,da82) >> at scbus7 target 230 lun 0 (pass89,da83) >> at scbus7 target 231 lun 0 (pass90,da84) >> at scbus7 target 232 lun 0 (pass91,da85) >> at scbus7 target 233 lun 0 (pass92,da86) >> at scbus7 target 234 lun 0 (pass93,da87) >> at scbus7 target 235 lun 0 (pass94,da88) >> at scbus7 target 236 lun 0 (pass95,da89) >> at scbus7 target 237 lun 0 (pass96,da90) >> at scbus7 target 238 lun 0 (pass97,da91) >> at scbus7 target 239 lun 0 (pass98,da92) >> at scbus7 target 240 lun 0 (pass99,da93) >> at scbus7 target 241 lun 0 (pass100,da94) >> at scbus7 target 242 lun 0 (pass101,da95) >> at scbus7 target 243 lun 0 (pass102,da96) >> at scbus7 target 244 lun 0 (pass103,da97) >> at scbus7 target 245 lun 0 (ses3,pass104) >> at scbus7 target 246 lun 0 (pass105,da98) >> at scbus7 target 247 lun 0 (pass106,da99) >> at scbus7 target 248 lun 0 (pass107,da100) >> at scbus7 target 249 lun 0 (pass108,da101) >> at scbus7 target 250 lun 0 (pass109,da102) >> at scbus7 target 251 lun 0 (pass110,da103) >> at scbus7 target 252 lun 0 (pass111,da104) >> at scbus7 target 253 lun 0 (pass112,da105) >> at scbus7 target 254 lun 0 (pass113,da106) >> at scbus7 target 255 lun 0 (da390,pass409) >> at scbus7 target 256 lun 0 (pass114,da107) >> at scbus7 target 257 lun 0 (pass115,da108) >> at scbus7 target 258 lun 0 (pass116,da109) >> at scbus7 target 259 lun 0 (pass117,da110) >> at scbus7 target 260 lun 0 (pass118,da111) >> at scbus7 target 261 lun 0 (pass119,da112) >> at scbus7 target 262 lun 0 (pass120,da113) >> at scbus7 target 263 lun 0 (pass121,da114) >> at scbus7 target 264 lun 0 (pass122,da115) >> at scbus7 target 265 lun 0 (pass123,da116) >> at scbus7 target 266 lun 0 (pass124,da117) >> at scbus7 target 267 lun 0 (pass125,da118) >> at scbus7 target 268 lun 0 (pass126,da119) >> at scbus7 target 269 lun 0 (pass127,da120) >> at scbus7 target 270 lun 0 (ses4,pass128) >> at scbus7 target 271 lun 0 (pass129,da121) >> at scbus7 target 272 lun 0 (pass130,da122) >> at scbus7 target 273 lun 0 (pass131,da123) >> at scbus7 target 274 lun 0 (pass132,da124) >> at scbus7 target 275 lun 0 (pass133,da125) >> at scbus7 target 276 lun 0 (pass134,da126) >> at scbus7 target 277 lun 0 (pass135,da127) >> at scbus7 target 278 lun 0 (pass136,da128) >> at scbus7 target 279 lun 0 (pass137,da129) >> at scbus7 target 280 lun 0 (pass138,da130) >> at scbus7 target 281 lun 0 (pass139,da131) >> at scbus7 target 282 lun 0 (pass140,da132) >> at scbus7 target 283 lun 0 (pass141,da133) >> at scbus7 target 284 lun 0 (pass142,da134) >> at scbus7 target 285 lun 0 (pass143,da135) >> at scbus7 target 286 lun 0 (pass144,da136) >> at scbus7 target 287 lun 0 (pass145,da137) >> at scbus7 target 288 lun 0 (pass146,da138) >> at scbus7 target 289 lun 0 (pass147,da139) >> at scbus7 target 290 lun 0 (pass148,da140) >> at scbus7 target 291 lun 0 (pass149,da141) >> at scbus7 target 292 lun 0 (pass150,da142) >> at scbus7 target 293 lun 0 (pass151,da143) >> at scbus7 target 294 lun 0 (pass152,da144) >> at scbus7 target 295 lun 0 (pass153,da145) >> at scbus7 target 296 lun 0 (ses5,pass154) >> at scbus7 target 297 lun 0 (pass155,da146) >> at scbus7 target 298 lun 0 (pass156,da147) >> at scbus7 target 299 lun 0 (pass157,da148) >> at scbus7 target 300 lun 0 (pass158,da149) >> at scbus7 target 301 lun 0 (pass159,da150) >> at scbus7 target 302 lun 0 (pass160,da151) >> at scbus7 target 303 lun 0 (pass161,da152) >> at scbus7 target 304 lun 0 (pass162,da153) >> at scbus7 target 305 lun 0 (pass163,da154) >> at scbus7 target 306 lun 0 (pass164,da155) >> at scbus7 target 307 lun 0 (pass165,da156) >> at scbus7 target 308 lun 0 (pass166,da157) >> at scbus7 target 309 lun 0 (pass167,da158) >> at scbus7 target 310 lun 0 (pass168,da159) >> at scbus7 target 311 lun 0 (pass169,da160) >> at scbus7 target 312 lun 0 (pass170,da161) >> at scbus7 target 313 lun 0 (pass171,da162) >> at scbus7 target 314 lun 0 (pass172,da163) >> at scbus7 target 315 lun 0 (pass173,da164) >> at scbus7 target 316 lun 0 (pass174,da165) >> at scbus7 target 317 lun 0 (pass175,da166) >> at scbus7 target 318 lun 0 (pass176,da167) >> at scbus7 target 319 lun 0 (pass177,da168) >> at scbus7 target 320 lun 0 (pass178,da169) >> at scbus7 target 321 lun 0 (ses6,pass179) >> at scbus7 target 322 lun 0 (pass180,da170) >> at scbus7 target 323 lun 0 (pass181,da171) >> at scbus7 target 324 lun 0 (pass182,da172) >> at scbus7 target 325 lun 0 (pass183,da173) >> at scbus7 target 326 lun 0 (pass184,da174) >> at scbus7 target 327 lun 0 (pass185,da175) >> at scbus7 target 328 lun 0 (pass186,da176) >> at scbus7 target 329 lun 0 (pass187,da177) >> at scbus7 target 330 lun 0 (pass188,da178) >> at scbus7 target 331 lun 0 (pass189,da179) >> at scbus7 target 332 lun 0 (pass190,da180) >> at scbus7 target 333 lun 0 (pass191,da181) >> at scbus7 target 334 lun 0 (pass192,da182) >> at scbus7 target 335 lun 0 (pass193,da183) >> at scbus7 target 336 lun 0 (pass194,da184) >> at scbus7 target 337 lun 0 (pass195,da185) >> at scbus7 target 338 lun 0 (pass196,da186) >> at scbus7 target 339 lun 0 (pass197,da187) >> at scbus7 target 340 lun 0 (pass198,da188) >> at scbus7 target 341 lun 0 (pass199,da189) >> at scbus7 target 342 lun 0 (pass200,da190) >> at scbus7 target 343 lun 0 (pass201,da191) >> at scbus7 target 344 lun 0 (pass202,da192) >> at scbus7 target 345 lun 0 (pass203,da193) >> at scbus7 target 346 lun 0 (pass204,da194) >> at scbus7 target 347 lun 0 (ses7,pass205) >> at scbus8 target 144 lun 0 (pass206,da195) >> at scbus8 target 145 lun 0 (pass207,da196) >> at scbus8 target 146 lun 0 (pass208,da197) >> at scbus8 target 147 lun 0 (pass209,da198) >> at scbus8 target 148 lun 0 (pass210,da199) >> at scbus8 target 149 lun 0 (pass211,da200) >> at scbus8 target 150 lun 0 (pass212,da201) >> at scbus8 target 151 lun 0 (pass213,da202) >> at scbus8 target 152 lun 0 (pass214,da203) >> at scbus8 target 153 lun 0 (pass215,da204) >> at scbus8 target 154 lun 0 (pass216,da205) >> at scbus8 target 155 lun 0 (pass217,da206) >> at scbus8 target 156 lun 0 (pass218,da207) >> at scbus8 target 157 lun 0 (pass219,da208) >> at scbus8 target 158 lun 0 (pass220,da209) >> at scbus8 target 159 lun 0 (pass221,da210) >> at scbus8 target 160 lun 0 (pass222,da211) >> at scbus8 target 161 lun 0 (pass223,da212) >> at scbus8 target 162 lun 0 (pass224,da213) >> at scbus8 target 163 lun 0 (pass225,da214) >> at scbus8 target 164 lun 0 (pass226,da215) >> at scbus8 target 165 lun 0 (pass227,da216) >> at scbus8 target 166 lun 0 (pass228,da217) >> at scbus8 target 167 lun 0 (pass229,da218) >> at scbus8 target 168 lun 0 (ses8,pass230) >> at scbus8 target 169 lun 0 (pass231,da219) >> at scbus8 target 170 lun 0 (pass232,da220) >> at scbus8 target 171 lun 0 (pass233,da221) >> at scbus8 target 172 lun 0 (pass234,da222) >> at scbus8 target 173 lun 0 (pass235,da223) >> at scbus8 target 174 lun 0 (pass236,da224) >> at scbus8 target 175 lun 0 (pass237,da225) >> at scbus8 target 176 lun 0 (pass238,da226) >> at scbus8 target 177 lun 0 (pass239,da227) >> at scbus8 target 178 lun 0 (pass240,da228) >> at scbus8 target 179 lun 0 (pass241,da229) >> at scbus8 target 180 lun 0 (pass242,da230) >> at scbus8 target 181 lun 0 (pass243,da231) >> at scbus8 target 182 lun 0 (pass244,da232) >> at scbus8 target 183 lun 0 (pass245,da233) >> at scbus8 target 184 lun 0 (pass246,da234) >> at scbus8 target 185 lun 0 (pass247,da235) >> at scbus8 target 186 lun 0 (pass248,da236) >> at scbus8 target 187 lun 0 (pass249,da237) >> at scbus8 target 188 lun 0 (pass250,da238) >> at scbus8 target 189 lun 0 (pass251,da239) >> at scbus8 target 190 lun 0 (pass252,da240) >> at scbus8 target 191 lun 0 (pass253,da241) >> at scbus8 target 192 lun 0 (pass254,da242) >> at scbus8 target 193 lun 0 (pass255,da243) >> at scbus8 target 194 lun 0 (ses9,pass256) >> at scbus8 target 195 lun 0 (pass257,da244) >> at scbus8 target 196 lun 0 (pass258,da245) >> at scbus8 target 197 lun 0 (pass259,da246) >> at scbus8 target 198 lun 0 (pass260,da247) >> at scbus8 target 199 lun 0 (pass261,da248) >> at scbus8 target 200 lun 0 (pass262,da249) >> at scbus8 target 201 lun 0 (pass263,da250) >> at scbus8 target 202 lun 0 (pass264,da251) >> at scbus8 target 203 lun 0 (pass265,da252) >> at scbus8 target 204 lun 0 (pass266,da253) >> at scbus8 target 205 lun 0 (pass267,da254) >> at scbus8 target 206 lun 0 (pass268,da255) >> at scbus8 target 207 lun 0 (pass269,da256) >> at scbus8 target 208 lun 0 (pass270,da257) >> at scbus8 target 209 lun 0 (pass271,da258) >> at scbus8 target 210 lun 0 (pass272,da259) >> at scbus8 target 211 lun 0 (pass273,da260) >> at scbus8 target 212 lun 0 (pass274,da261) >> at scbus8 target 213 lun 0 (pass275,da262) >> at scbus8 target 214 lun 0 (pass276,da263) >> at scbus8 target 215 lun 0 (pass277,da264) >> at scbus8 target 216 lun 0 (pass278,da265) >> at scbus8 target 217 lun 0 (pass279,da266) >> at scbus8 target 218 lun 0 (pass280,da267) >> at scbus8 target 219 lun 0 (ses10,pass281) >> at scbus8 target 220 lun 0 (pass282,da268) >> at scbus8 target 221 lun 0 (pass283,da269) >> at scbus8 target 222 lun 0 (pass284,da270) >> at scbus8 target 223 lun 0 (pass285,da271) >> at scbus8 target 224 lun 0 (pass286,da272) >> at scbus8 target 225 lun 0 (pass287,da273) >> at scbus8 target 226 lun 0 (pass288,da274) >> at scbus8 target 227 lun 0 (pass289,da275) >> at scbus8 target 228 lun 0 (pass290,da276) >> at scbus8 target 229 lun 0 (pass291,da277) >> at scbus8 target 230 lun 0 (pass292,da278) >> at scbus8 target 231 lun 0 (pass293,da279) >> at scbus8 target 232 lun 0 (pass294,da280) >> at scbus8 target 233 lun 0 (pass295,da281) >> at scbus8 target 234 lun 0 (pass296,da282) >> at scbus8 target 235 lun 0 (pass297,da283) >> at scbus8 target 236 lun 0 (pass298,da284) >> at scbus8 target 237 lun 0 (pass299,da285) >> at scbus8 target 238 lun 0 (pass300,da286) >> at scbus8 target 239 lun 0 (pass301,da287) >> at scbus8 target 240 lun 0 (pass302,da288) >> at scbus8 target 241 lun 0 (pass303,da289) >> at scbus8 target 242 lun 0 (pass304,da290) >> at scbus8 target 243 lun 0 (pass305,da291) >> at scbus8 target 244 lun 0 (pass306,da292) >> at scbus8 target 245 lun 0 (ses11,pass307) >> at scbus8 target 246 lun 0 (pass308,da293) >> at scbus8 target 247 lun 0 (pass309,da294) >> at scbus8 target 248 lun 0 (pass310,da295) >> at scbus8 target 249 lun 0 (pass311,da296) >> at scbus8 target 250 lun 0 (pass312,da297) >> at scbus8 target 251 lun 0 (pass313,da298) >> at scbus8 target 252 lun 0 (pass314,da299) >> at scbus8 target 253 lun 0 (pass315,da300) >> at scbus8 target 254 lun 0 (pass316,da301) >> at scbus8 target 255 lun 0 (da391,pass410) >> at scbus8 target 256 lun 0 (pass317,da302) >> at scbus8 target 257 lun 0 (pass318,da303) >> at scbus8 target 258 lun 0 (pass319,da304) >> at scbus8 target 259 lun 0 (pass320,da305) >> at scbus8 target 260 lun 0 (pass321,da306) >> at scbus8 target 261 lun 0 (pass322,da307) >> at scbus8 target 262 lun 0 (pass323,da308) >> at scbus8 target 263 lun 0 (pass324,da309) >> at scbus8 target 264 lun 0 (pass325,da310) >> at scbus8 target 265 lun 0 (pass326,da311) >> at scbus8 target 266 lun 0 (pass327,da312) >> at scbus8 target 267 lun 0 (pass328,da313) >> at scbus8 target 268 lun 0 (pass329,da314) >> at scbus8 target 269 lun 0 (pass330,da315) >> at scbus8 target 270 lun 0 (ses12,pass331) >> at scbus8 target 271 lun 0 (pass332,da316) >> at scbus8 target 272 lun 0 (pass333,da317) >> at scbus8 target 273 lun 0 (pass334,da318) >> at scbus8 target 274 lun 0 (pass335,da319) >> at scbus8 target 275 lun 0 (pass336,da320) >> at scbus8 target 276 lun 0 (pass337,da321) >> at scbus8 target 277 lun 0 (pass338,da322) >> at scbus8 target 278 lun 0 (pass339,da323) >> at scbus8 target 279 lun 0 (pass340,da324) >> at scbus8 target 280 lun 0 (pass341,da325) >> at scbus8 target 281 lun 0 (pass342,da326) >> at scbus8 target 282 lun 0 (pass343,da327) >> at scbus8 target 283 lun 0 (pass344,da328) >> at scbus8 target 284 lun 0 (pass345,da329) >> at scbus8 target 285 lun 0 (pass346,da330) >> at scbus8 target 286 lun 0 (pass347,da331) >> at scbus8 target 287 lun 0 (pass348,da332) >> at scbus8 target 288 lun 0 (pass349,da333) >> at scbus8 target 289 lun 0 (pass350,da334) >> at scbus8 target 290 lun 0 (pass351,da335) >> at scbus8 target 291 lun 0 (pass352,da336) >> at scbus8 target 292 lun 0 (pass353,da337) >> at scbus8 target 293 lun 0 (pass354,da338) >> at scbus8 target 294 lun 0 (pass355,da339) >> at scbus8 target 295 lun 0 (pass356,da340) >> at scbus8 target 296 lun 0 (ses13,pass357) >> at scbus8 target 297 lun 0 (pass358,da341) >> at scbus8 target 298 lun 0 (pass359,da342) >> at scbus8 target 299 lun 0 (pass360,da343) >> at scbus8 target 300 lun 0 (pass361,da344) >> at scbus8 target 301 lun 0 (pass362,da345) >> at scbus8 target 302 lun 0 (pass363,da346) >> at scbus8 target 303 lun 0 (pass364,da347) >> at scbus8 target 304 lun 0 (pass365,da348) >> at scbus8 target 305 lun 0 (pass366,da349) >> at scbus8 target 306 lun 0 (pass367,da350) >> at scbus8 target 307 lun 0 (pass368,da351) >> at scbus8 target 308 lun 0 (pass369,da352) >> at scbus8 target 309 lun 0 (pass370,da353) >> at scbus8 target 310 lun 0 (pass371,da354) >> at scbus8 target 311 lun 0 (pass372,da355) >> at scbus8 target 312 lun 0 (pass373,da356) >> at scbus8 target 313 lun 0 (pass374,da357) >> at scbus8 target 314 lun 0 (pass375,da358) >> at scbus8 target 315 lun 0 (pass376,da359) >> at scbus8 target 316 lun 0 (pass377,da360) >> at scbus8 target 317 lun 0 (pass378,da361) >> at scbus8 target 318 lun 0 (pass379,da362) >> at scbus8 target 319 lun 0 (pass380,da363) >> at scbus8 target 320 lun 0 (pass381,da364) >> at scbus8 target 321 lun 0 (ses14,pass382) >> at scbus8 target 322 lun 0 (pass383,da365) >> at scbus8 target 323 lun 0 (pass384,da366) >> at scbus8 target 324 lun 0 (pass385,da367) >> at scbus8 target 325 lun 0 (pass386,da368) >> at scbus8 target 326 lun 0 (pass387,da369) >> at scbus8 target 327 lun 0 (pass388,da370) >> at scbus8 target 328 lun 0 (pass389,da371) >> at scbus8 target 329 lun 0 (pass390,da372) >> at scbus8 target 330 lun 0 (pass391,da373) >> at scbus8 target 331 lun 0 (pass392,da374) >> at scbus8 target 332 lun 0 (pass393,da375) >> at scbus8 target 333 lun 0 (pass394,da376) >> at scbus8 target 334 lun 0 (pass395,da377) >> at scbus8 target 335 lun 0 (pass396,da378) >> at scbus8 target 336 lun 0 (pass397,da379) >> at scbus8 target 337 lun 0 (pass398,da380) >> at scbus8 target 338 lun 0 (pass399,da381) >> at scbus8 target 339 lun 0 (pass400,da382) >> at scbus8 target 340 lun 0 (pass401,da383) >> at scbus8 target 341 lun 0 (pass402,da384) >> at scbus8 target 342 lun 0 (pass403,da385) >> at scbus8 target 343 lun 0 (pass404,da386) >> at scbus8 target 344 lun 0 (pass405,da387) >> at scbus8 target 345 lun 0 (pass406,da388) >> at scbus8 target 346 lun 0 (pass407,da389) >> at scbus8 target 347 lun 0 (ses15,pass408) >> >> > _______________________________________________ > 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 Sep 26 09:38:03 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CED511065670 for ; Wed, 26 Sep 2012 09:38:03 +0000 (UTC) (envelope-from Paul.Maulberger@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id 264418FC14 for ; Wed, 26 Sep 2012 09:38:02 +0000 (UTC) Received: (qmail 10180 invoked by uid 0); 26 Sep 2012 09:38:01 -0000 Received: from 31.17.115.153 by www031.gmx.net with HTTP; Wed, 26 Sep 2012 11:37:59 +0200 (CEST) Content-Type: multipart/mixed; boundary="========GMX299751348652279484510" Date: Wed, 26 Sep 2012 11:37:59 +0200 From: "Paul Maulberger" In-Reply-To: Message-ID: <20120926093759.299750@gmx.net> MIME-Version: 1.0 References: <20120923140816.144270@gmx.net> To: Jim Harris X-Authenticated: #143783428 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1//8+cognb/n95Qb1tDXShf+TwIs1y7GKrMYOt14v CeOCbYOUMGEnftoCavE1XtgsYpZeRxRRpBJQ== X-GMX-UID: oKkQcHMUeSEqZ2WV+nwhHdR+IGRvb4Ds Cc: freebsd-scsi@freebsd.org Subject: Re: Intel C600 SAS Controller + locate LED (SGPIO) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 09:38:03 -0000 --========GMX299751348652279484510 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Jim, your patch is working very well. Thanks a lot! To support the locate and the fault led I extended your patch a little bit. Like the ahci driver every port has now a locate and a fault led device. # ls -al /dev/led total 1 dr-xr-xr-x 2 root wheel 512 Sep 26 08:39 . dr-xr-xr-x 11 root wheel 512 Sep 26 10:39 .. crw------- 1 root wheel 0, 47 Sep 26 08:43 ahcich0.fault crw------- 1 root wheel 0, 46 Sep 26 08:44 ahcich0.locate crw------- 1 root wheel 0, 49 Sep 26 08:39 ahcich1.fault crw------- 1 root wheel 0, 48 Sep 26 08:39 ahcich1.locate crw------- 1 root wheel 0, 51 Sep 26 08:39 ahcich2.fault crw------- 1 root wheel 0, 50 Sep 26 08:39 ahcich2.locate crw------- 1 root wheel 0, 53 Sep 26 08:39 ahcich3.fault crw------- 1 root wheel 0, 52 Sep 26 08:39 ahcich3.locate crw------- 1 root wheel 0, 55 Sep 26 08:39 ahcich4.fault crw------- 1 root wheel 0, 54 Sep 26 08:39 ahcich4.locate crw------- 1 root wheel 0, 57 Sep 26 08:44 ahcich5.fault crw------- 1 root wheel 0, 56 Sep 26 08:44 ahcich5.locate crw------- 1 root wheel 0, 36 Sep 26 08:39 igb0 crw------- 1 root wheel 0, 37 Sep 26 08:39 igb1 crw------- 1 root wheel 0, 38 Sep 26 08:39 isci.bus0.port0.fault crw------- 1 root wheel 0, 39 Sep 26 08:39 isci.bus0.port0.locate crw------- 1 root wheel 0, 40 Sep 26 08:42 isci.bus0.port1.fault crw------- 1 root wheel 0, 41 Sep 26 08:42 isci.bus0.port1.locate crw------- 1 root wheel 0, 42 Sep 26 08:39 isci.bus0.port2.fault crw------- 1 root wheel 0, 43 Sep 26 08:39 isci.bus0.port2.locate crw------- 1 root wheel 0, 44 Sep 26 08:39 isci.bus0.port3.fault crw------- 1 root wheel 0, 45 Sep 26 08:39 isci.bus0.port3.locate By the way the main board X9DRi-F has only one bus. The X9DR3-F has 2 buses. The patch (compared to 9.1 RC1) is attached. Is it possible to commit this patch into 9.1 or is it too late? Regards Paul Hint: If anybody is using a SC825TQ chassis and no led is blinking check ALL jumper settings of your backplane (Appendix C of http://www.supermicro.com/manuals/chassis/2U/SC825.pdf). Our backplane was wrongly configured by factory (mixture of sgpio and i2c settings). -------- Original-Nachricht -------- > Datum: Mon, 24 Sep 2012 18:01:34 -0700 > Von: Jim Harris > An: Paul Maulberger > CC: freebsd-scsi@freebsd.org > Betreff: Re: Intel C600 SAS Controller + locate LED (SGPIO) > On Sun, Sep 23, 2012 at 7:08 AM, Paul Maulberger > wrote: > > Hi Folks, > > > > I like to manipulate the eight locate LED's of my internal enclosure. > The following hardware is used: > > > > Mainboard: Supermicro X9DRi-F > > http://www.supermicro.com/products/motherboard/xeon/c600/x9dri-f.cfm > > > > Chassis: SC825TQ-R740LPB > > http://www.supermicro.com/products/chassis/2U/825/SC825TQ-R740LP.cfm > > > > Cable from Intel C602 SAS controller to backplane: > > SFF-8087 to 4xSATA cable with 8-pin SGPIO connector > > > > The backplane of the chassis has the MagaRAC MG9072 chip from AMI and is > configured for SGPIO. > > > > I'm using FreeBSD 9.1 RC1. > > > > FreeBSD has a led driver to manipulate LED's: > > http://www.freebsd.org/cgi/man.cgi?query=led > > > > # ls -al /dev/led > > total 1 > > dr-xr-xr-x 2 root wheel 512 Sep 23 09:42 . > > dr-xr-xr-x 10 root wheel 512 Sep 23 09:42 .. > > crw------- 1 root wheel 0, 40 Sep 23 09:42 ahcich0.fault > > crw------- 1 root wheel 0, 39 Sep 23 09:42 ahcich0.locate > > crw------- 1 root wheel 0, 42 Sep 23 09:42 ahcich1.fault > > crw------- 1 root wheel 0, 41 Sep 23 09:42 ahcich1.locate > > crw------- 1 root wheel 0, 44 Sep 23 09:42 ahcich2.fault > > crw------- 1 root wheel 0, 43 Sep 23 09:42 ahcich2.locate > > crw------- 1 root wheel 0, 46 Sep 23 09:42 ahcich3.fault > > crw------- 1 root wheel 0, 45 Sep 23 09:42 ahcich3.locate > > crw------- 1 root wheel 0, 48 Sep 23 09:42 ahcich4.fault > > crw------- 1 root wheel 0, 47 Sep 23 09:42 ahcich4.locate > > crw------- 1 root wheel 0, 50 Sep 23 09:42 ahcich5.fault > > crw------- 1 root wheel 0, 49 Sep 23 09:42 ahcich5.locate > > crw------- 1 root wheel 0, 37 Sep 23 09:42 igb0 > > crw------- 1 root wheel 0, 38 Sep 23 09:42 igb1 > > > > Unfortunately there are no "C600" led devices. > > > > I found the functions 'scic_sgpio_*' in the file > 'sys/dev/isci/scil/scic_sgpio.h'. The function 'scic_sgpio_hardware_initialize' is called in the > file 'sys/dev/isci/scil/scic_sds_controller.c'. Although there is no call to > 'scic_sgpio_set_led_state' or 'scic_sgpio_update_led_state' in the whole > sources (/usr/src). > > > > Can somebody give me a hint how to manipulate the LED's? > > There's no way to manipulate the LEDs on the system as you have it. > LED support is not in the current isci driver. But can you try this > patch? > > http://people.freebsd.org/~jimharris/isci_led.patch > > The LEDs will show up as /dev/led/isci.busX.portY. On C60x SKUs with > 8 isci ports (which I think yours has), the isci driver will create 2 > buses of 4 ports each (to match the underlying silicon > implementation), hence the need to use bus and port numbers in the > name, rather than just port. > > Regards, > > -Jim > > > > Regards > > Paul > > _______________________________________________ > > 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" --========GMX299751348652279484510 Content-Type: application/octet-stream; name="isci_led2.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="isci_led2.patch" LS0tIC91c3Ivc3JjL3N5cy9kZXYvaXNjaS9pc2NpLmguOTFyYzEJMjAxMi0wOS0yNSAwNjo1MToy Mi4wMDAwMDAwMDAgKzAyMDAKKysrIC91c3Ivc3JjL3N5cy9kZXYvaXNjaS9pc2NpLmgJMjAxMi0w OS0yNiAwOTowMjoxMC4wMDAwMDAwMDAgKzAyMDAKQEAgLTE0Myw2ICsxNDMsMTMgQEAKIAogfTsK IAorc3RydWN0IElTQ0lfTEVECit7CisJc3RydWN0IGNkZXYJCSpjZGV2OworCVNDSV9DT05UUk9M TEVSX0hBTkRMRV9UCWhhbmRsZTsKKwlpbnQJCQlpbmRleDsKK307CisKIHN0cnVjdCBJU0NJX0NP TlRST0xMRVIKIHsKIAlzdHJ1Y3QgaXNjaV9zb2Z0YyAJKmlzY2k7CkBAIC0xNjksNiArMTc2LDgg QEAKIAl1aW50MzJfdAkJcXVldWVfZGVwdGg7CiAJdWludDMyX3QJCXNpbV9xdWV1ZV9kZXB0aDsK IAlTQ0lfRkFTVF9MSVNUX1QJCXBlbmRpbmdfZGV2aWNlX3Jlc2V0X2xpc3Q7CisJc3RydWN0IElT Q0lfTEVECQlsZWRfZmF1bHRbU0NJX01BWF9QSFlTXTsKKwlzdHJ1Y3QgSVNDSV9MRUQJCWxlZF9s b2NhdGVbU0NJX01BWF9QSFlTXTsKIAogCVNDSV9NRU1PUllfREVTQ1JJUFRPUl9MSVNUX0hBTkRM RV9UIG1kbDsKIAotLS0gL3Vzci9zcmMvc3lzL2Rldi9pc2NpL2lzY2kuYy45MXJjMQkyMDEyLTA5 LTI2IDEwOjU3OjQ3LjAwMDAwMDAwMCArMDIwMAorKysgL3Vzci9zcmMvc3lzL2Rldi9pc2NpL2lz Y2kuYwkyMDEyLTA5LTI2IDA5OjA0OjMyLjAwMDAwMDAwMCArMDIwMApAQCAtMzcsMTIgKzM3LDE0 IEBACiAjaW5jbHVkZSA8c3lzL21hbGxvYy5oPgogCiAjaW5jbHVkZSA8Y2FtL2NhbV9wZXJpcGgu aD4KKyNpbmNsdWRlIDxkZXYvbGVkL2xlZC5oPgogCiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2lyZWcu aD4KICNpbmNsdWRlIDxkZXYvcGNpL3BjaXZhci5oPgogCiAjaW5jbHVkZSA8ZGV2L2lzY2kvc2Np bC9zY2ljX2xvZ2dlci5oPgogI2luY2x1ZGUgPGRldi9pc2NpL3NjaWwvc2NpY19saWJyYXJ5Lmg+ CisjaW5jbHVkZSA8ZGV2L2lzY2kvc2NpbC9zY2ljX3NncGlvLmg+CiAjaW5jbHVkZSA8ZGV2L2lz Y2kvc2NpbC9zY2ljX3VzZXJfY2FsbGJhY2suaD4KIAogI2luY2x1ZGUgPGRldi9pc2NpL3NjaWwv c2NpZl9jb250cm9sbGVyLmg+CkBAIC0xODAsNyArMTgyLDcgQEAKIGlzY2lfZGV0YWNoKGRldmlj ZV90IGRldmljZSkKIHsKIAlzdHJ1Y3QgaXNjaV9zb2Z0YyAqaXNjaSA9IERFVklDRTJTT0ZUQyhk ZXZpY2UpOwotCWludCBpOworCWludCBpLCBwaHk7CiAKIAlmb3IgKGkgPSAwOyBpIDwgaXNjaS0+ Y29udHJvbGxlcl9jb3VudDsgaSsrKSB7CiAJCXN0cnVjdCBJU0NJX0NPTlRST0xMRVIgKmNvbnRy b2xsZXIgPSAmaXNjaS0+Y29udHJvbGxlcnNbaV07CkBAIC0yMTgsNiArMjIwLDE2IEBACiAKIAkJ aWYgKGNvbnRyb2xsZXItPnJlbW90ZV9kZXZpY2VfbWVtb3J5ICE9IE5VTEwpCiAJCQlmcmVlKGNv bnRyb2xsZXItPnJlbW90ZV9kZXZpY2VfbWVtb3J5LCBNX0lTQ0kpOworCQkJCisJCS8qIGRlc3Ry b3kgbGVkIGRldmljZXMgKi8KKwkJZm9yIChwaHkgPSAwOyBwaHkgPCBTQ0lfTUFYX1BIWVM7IHBo eSsrKQorCQl7CisJCQlpZiAoY29udHJvbGxlci0+bGVkX2ZhdWx0W3BoeV0uY2RldikKKwkJCQls ZWRfZGVzdHJveShjb250cm9sbGVyLT5sZWRfZmF1bHRbcGh5XS5jZGV2KTsKKwkJCQkKKwkJCWlm IChjb250cm9sbGVyLT5sZWRfbG9jYXRlW3BoeV0uY2RldikKKwkJCQlsZWRfZGVzdHJveShjb250 cm9sbGVyLT5sZWRfbG9jYXRlW3BoeV0uY2Rldik7CisJCX0KIAl9CiAKIAkvKiBUaGUgU0NJRiBj b250cm9sbGVycyBoYXZlIGJlZW4gc3RvcHBlZCwgc28gd2UgY2FuIG5vdwotLS0gL3Vzci9zcmMv c3lzL2Rldi9pc2NpL2lzY2lfY29udHJvbGxlci5jLjkxcmMxCTIwMTItMDktMjUgMDY6NTI6MDgu MDAwMDAwMDAwICswMjAwCisrKyAvdXNyL3NyYy9zeXMvZGV2L2lzY2kvaXNjaV9jb250cm9sbGVy LmMJMjAxMi0wOS0yNiAxMDo1NDowNS4wMDAwMDAwMDAgKzAyMDAKQEAgLTQ5LDYgKzQ5LDkgQEAK ICNpbmNsdWRlIDxkZXYvaXNjaS9zY2lsL3NjaWZfcmVtb3RlX2RldmljZS5oPgogI2luY2x1ZGUg PGRldi9pc2NpL3NjaWwvc2NpZl9kb21haW4uaD4KICNpbmNsdWRlIDxkZXYvaXNjaS9zY2lsL3Nj aWZfdXNlcl9jYWxsYmFjay5oPgorI2luY2x1ZGUgPGRldi9pc2NpL3NjaWwvc2NpY19zZ3Bpby5o PgorCisjaW5jbHVkZSA8ZGV2L2xlZC9sZWQuaD4KIAogdm9pZCBpc2NpX2FjdGlvbihzdHJ1Y3Qg Y2FtX3NpbSAqc2ltLCB1bmlvbiBjY2IgKmNjYik7CiB2b2lkIGlzY2lfcG9sbChzdHJ1Y3QgY2Ft X3NpbSAqc2ltKTsKQEAgLTIzMCwxMCArMjMzLDI3IEBACiAJfQogfQogCitzdGF0aWMgdm9pZCBp c2NpX2xlZF9mYXVsdF9mdW5jKHZvaWQgKnByaXYsIGludCBvbm9mZikKK3sKKwlzdHJ1Y3QgSVND SV9MRUQgKmxlZCA9IHByaXY7CisKKwkvKiBtYXAgb25vZmYgdG8gdGhlIGZhdWx0IExFRCAqLwor CXNjaWNfc2dwaW9fdXBkYXRlX2xlZF9zdGF0ZShsZWQtPmhhbmRsZSwgMSA8PCBsZWQtPmluZGV4 LCBvbm9mZiwgMCwgMCk7Cit9CisKK3N0YXRpYyB2b2lkIGlzY2lfbGVkX2xvY2F0ZV9mdW5jKHZv aWQgKnByaXYsIGludCBvbm9mZikKK3sKKwlzdHJ1Y3QgSVNDSV9MRUQgKmxlZCA9IHByaXY7CisK KwkvKiBtYXAgb25vZmYgdG8gdGhlIGxvY2F0ZSBMRUQgKi8KKwlzY2ljX3NncGlvX3VwZGF0ZV9s ZWRfc3RhdGUobGVkLT5oYW5kbGUsIDEgPDwgbGVkLT5pbmRleCwgMCwgb25vZmYsIDApOworfQor CiBTQ0lfU1RBVFVTIGlzY2lfY29udHJvbGxlcl9pbml0aWFsaXplKHN0cnVjdCBJU0NJX0NPTlRS T0xMRVIgKmNvbnRyb2xsZXIpCiB7CiAJU0NJQ19VU0VSX1BBUkFNRVRFUlNfVCBzY2ljX3VzZXJf cGFyYW1ldGVyczsKIAlTQ0lfQ09OVFJPTExFUl9IQU5ETEVfVCBzY2ljX2NvbnRyb2xsZXJfaGFu ZGxlOworCWNoYXIgbGVkX25hbWVbNjRdOwogCXVuc2lnbmVkIGxvbmcgdHVuYWJsZTsKIAlpbnQg aTsKIApAQCAtMzEzLDYgKzMzMywyNCBAQAogCWlzY2lfY29udHJvbGxlcl9hdHRhY2hfdG9fY2Ft KGNvbnRyb2xsZXIpOwogCXhwdF9mcmVlemVfc2ltcShjb250cm9sbGVyLT5zaW0sIDEpOwogCW10 eF91bmxvY2soJmNvbnRyb2xsZXItPmxvY2spOworCQorCS8qIGNyZWF0ZSBsZWQgZGV2aWNlcyAq LworCWZvciAoaSA9IDA7IGkgPCBTQ0lfTUFYX1BIWVM7IGkrKykKKwl7CisJCS8qIGZhdWx0ICov CisJCWNvbnRyb2xsZXItPmxlZF9mYXVsdFtpXS5oYW5kbGUgPSBzY2ljX2NvbnRyb2xsZXJfaGFu ZGxlOworCQljb250cm9sbGVyLT5sZWRfZmF1bHRbaV0uaW5kZXggPSBpOworCQlzcHJpbnRmKGxl ZF9uYW1lLCAiaXNjaS5idXMlZC5wb3J0JWQuZmF1bHQiLCBjb250cm9sbGVyLT5pbmRleCwgaSk7 CisJCWNvbnRyb2xsZXItPmxlZF9mYXVsdFtpXS5jZGV2ID0gbGVkX2NyZWF0ZShpc2NpX2xlZF9m YXVsdF9mdW5jLAorCQkgICAgJmNvbnRyb2xsZXItPmxlZF9mYXVsdFtpXSwgbGVkX25hbWUpOwor CQkJCisJCS8qIGxvY2F0ZSAqLworCQljb250cm9sbGVyLT5sZWRfbG9jYXRlW2ldLmhhbmRsZSA9 IHNjaWNfY29udHJvbGxlcl9oYW5kbGU7CisJCWNvbnRyb2xsZXItPmxlZF9sb2NhdGVbaV0uaW5k ZXggPSBpOworCQlzcHJpbnRmKGxlZF9uYW1lLCAiaXNjaS5idXMlZC5wb3J0JWQubG9jYXRlIiwg Y29udHJvbGxlci0+aW5kZXgsIGkpOworCQljb250cm9sbGVyLT5sZWRfbG9jYXRlW2ldLmNkZXYg PSBsZWRfY3JlYXRlKGlzY2lfbGVkX2xvY2F0ZV9mdW5jLAorCQkgICAgJmNvbnRyb2xsZXItPmxl ZF9sb2NhdGVbaV0sIGxlZF9uYW1lKTsKKwl9CQogCiAJcmV0dXJuIChzY2lmX2NvbnRyb2xsZXJf aW5pdGlhbGl6ZShjb250cm9sbGVyLT5zY2lmX2NvbnRyb2xsZXJfaGFuZGxlKSk7CiB9Cg== --========GMX299751348652279484510-- From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 26 15:57:14 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8F7C106566C for ; Wed, 26 Sep 2012 15:57:14 +0000 (UTC) (envelope-from jim.harris@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 695FC8FC0A for ; Wed, 26 Sep 2012 15:57:14 +0000 (UTC) Received: by vbmv11 with SMTP id v11so1058958vbm.13 for ; Wed, 26 Sep 2012 08:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=C+BZgUn6gccCGIuJxHefYqyDhuOrydjPYJfcopKH8DI=; b=PkCX6ypgpwKTjjXKkrGo4eqFmkbtFx4hXhzsjFsZnYupWpRskIQzP/XKNRApxL42D2 6ataolyhuN3QGTQdS8+eD9+P9JDa4EsTE2nWis33MTaxZTNFJufPJ7q4kAP31rdBORy3 e3kNyJkNEw+fZkCKpnLxP6NyF2RU+o/35teyU7f24zHiOVkMjj1pRxtlr/tXqIkv7eOB ZwYvxX6EpOoGv2OVKmhx2P3Hq3hktLTGJz2TLu+xq7qYq6UHDBINnhqxUk+pMlDe10oF nO0aH5h2M3dUF/y/NSU7m5Wou1iW3rLwAM0UWjTpem+0laW8Yevw3ckuphuWHHinHN8u IHKw== MIME-Version: 1.0 Received: by 10.52.69.47 with SMTP id b15mr397286vdu.116.1348675033565; Wed, 26 Sep 2012 08:57:13 -0700 (PDT) Sender: jim.harris@gmail.com Received: by 10.59.10.98 with HTTP; Wed, 26 Sep 2012 08:57:13 -0700 (PDT) In-Reply-To: <20120926093759.299750@gmx.net> References: <20120923140816.144270@gmx.net> <20120926093759.299750@gmx.net> Date: Wed, 26 Sep 2012 08:57:13 -0700 X-Google-Sender-Auth: Y0fkAYjRZrp0YwE5us6ZZ9qO5fY Message-ID: From: Jim Harris To: Paul Maulberger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi@freebsd.org Subject: Re: Intel C600 SAS Controller + locate LED (SGPIO) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 15:57:14 -0000 On Wed, Sep 26, 2012 at 2:37 AM, Paul Maulberger w= rote: > Hi Jim, > > your patch is working very well. Thanks a lot! > > To support the locate and the fault led I extended your patch a little bi= t. Like the ahci driver every port has now a locate and a fault led device. Hi Paul, I am reluctant to add LEDs for error, even though I know AHCI driver does this today. I don't see the need for userspace to manipulate both locate and error LEDs - it seems locate is sufficient. I'd prefer to keep error LED reserved for future use in the driver. But I will add "locate" to the LED name, just to make it more clear. > # ls -al /dev/led > total 1 > dr-xr-xr-x 2 root wheel 512 Sep 26 08:39 . > dr-xr-xr-x 11 root wheel 512 Sep 26 10:39 .. > crw------- 1 root wheel 0, 47 Sep 26 08:43 ahcich0.fault > crw------- 1 root wheel 0, 46 Sep 26 08:44 ahcich0.locate > crw------- 1 root wheel 0, 49 Sep 26 08:39 ahcich1.fault > crw------- 1 root wheel 0, 48 Sep 26 08:39 ahcich1.locate > crw------- 1 root wheel 0, 51 Sep 26 08:39 ahcich2.fault > crw------- 1 root wheel 0, 50 Sep 26 08:39 ahcich2.locate > crw------- 1 root wheel 0, 53 Sep 26 08:39 ahcich3.fault > crw------- 1 root wheel 0, 52 Sep 26 08:39 ahcich3.locate > crw------- 1 root wheel 0, 55 Sep 26 08:39 ahcich4.fault > crw------- 1 root wheel 0, 54 Sep 26 08:39 ahcich4.locate > crw------- 1 root wheel 0, 57 Sep 26 08:44 ahcich5.fault > crw------- 1 root wheel 0, 56 Sep 26 08:44 ahcich5.locate > crw------- 1 root wheel 0, 36 Sep 26 08:39 igb0 > crw------- 1 root wheel 0, 37 Sep 26 08:39 igb1 > crw------- 1 root wheel 0, 38 Sep 26 08:39 isci.bus0.port0.fault > crw------- 1 root wheel 0, 39 Sep 26 08:39 isci.bus0.port0.locate > crw------- 1 root wheel 0, 40 Sep 26 08:42 isci.bus0.port1.fault > crw------- 1 root wheel 0, 41 Sep 26 08:42 isci.bus0.port1.locate > crw------- 1 root wheel 0, 42 Sep 26 08:39 isci.bus0.port2.fault > crw------- 1 root wheel 0, 43 Sep 26 08:39 isci.bus0.port2.locate > crw------- 1 root wheel 0, 44 Sep 26 08:39 isci.bus0.port3.fault > crw------- 1 root wheel 0, 45 Sep 26 08:39 isci.bus0.port3.locate > > By the way the main board X9DRi-F has only one bus. The X9DR3-F has 2 bus= es. > > The patch (compared to 9.1 RC1) is attached. > > Is it possible to commit this patch into 9.1 or is it too late? I think it is too late. The changes here are very low risk, but it is a new feature and not a bug fix so not really appropriate for 9.1 at this point. Thank you for testing the patch! Regards, -Jim > Regards > Paul > > Hint: If anybody is using a SC825TQ chassis and no led is blinking check = ALL jumper settings of your backplane (Appendix C of http://www.supermicro.= com/manuals/chassis/2U/SC825.pdf). Our backplane was wrongly configured by = factory (mixture of sgpio and i2c settings). > > From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 26 18:17:31 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71EAB1065670 for ; Wed, 26 Sep 2012 18:17:31 +0000 (UTC) (envelope-from Paul.Maulberger@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id D09618FC08 for ; Wed, 26 Sep 2012 18:17:30 +0000 (UTC) Received: (qmail 8653 invoked by uid 0); 26 Sep 2012 18:17:24 -0000 Received: from 31.17.21.234 by www021.gmx.net with HTTP; Wed, 26 Sep 2012 20:17:23 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Wed, 26 Sep 2012 20:17:23 +0200 From: "Paul Maulberger" In-Reply-To: Message-ID: <20120926181723.327430@gmx.net> MIME-Version: 1.0 References: <20120923140816.144270@gmx.net> <20120926093759.299750@gmx.net> To: Jim Harris X-Authenticated: #143783428 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+HhhE0bpiHaiNXgYnh0XxRUpVvAEqPd5u+XJfZdN j5ktg2cW2SFY3HBlkqfw/as+8uAY7SpSy+PA== Content-Transfer-Encoding: 8bit X-GMX-UID: 5CMRcIMeeSEqQ2WV+nwhMkZ+IGRvb0Ag Cc: freebsd-scsi@freebsd.org Subject: Re: Intel C600 SAS Controller + locate LED (SGPIO) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 18:17:31 -0000 Hi Folks, I do not share Jim's opinion. I think the fault led should be access-able by the userspace. I have a special system monitor daemon which although checks the S.M.A.R.T. information of the hard drive. If information X is above value Y the system monitor daemon informs the admin and sets the fault led. In this case the driver could not set the fault led because it does not know "my" value Y. As the fault led is rarely set the userspace and the driver should have shared access to the led. Also a conflict could be easily solved: solution a: The last one wins. solution b: If the driver sets the fault led the userspace could not clear it. What do you think? Regards Paul -------- Original-Nachricht -------- > Datum: Wed, 26 Sep 2012 08:57:13 -0700 > Von: Jim Harris > An: Paul Maulberger > CC: freebsd-scsi@freebsd.org > Betreff: Re: Intel C600 SAS Controller + locate LED (SGPIO) > On Wed, Sep 26, 2012 at 2:37 AM, Paul Maulberger > wrote: > > Hi Jim, > > > > your patch is working very well. Thanks a lot! > > > > To support the locate and the fault led I extended your patch a little > bit. Like the ahci driver every port has now a locate and a fault led > device. > > Hi Paul, > > I am reluctant to add LEDs for error, even though I know AHCI driver > does this today. I don't see the need for userspace to manipulate > both locate and error LEDs - it seems locate is sufficient. I'd > prefer to keep error LED reserved for future use in the driver. > > But I will add "locate" to the LED name, just to make it more clear. > > > # ls -al /dev/led > > total 1 > > dr-xr-xr-x 2 root wheel 512 Sep 26 08:39 . > > dr-xr-xr-x 11 root wheel 512 Sep 26 10:39 .. > > crw------- 1 root wheel 0, 47 Sep 26 08:43 ahcich0.fault > > crw------- 1 root wheel 0, 46 Sep 26 08:44 ahcich0.locate > > crw------- 1 root wheel 0, 49 Sep 26 08:39 ahcich1.fault > > crw------- 1 root wheel 0, 48 Sep 26 08:39 ahcich1.locate > > crw------- 1 root wheel 0, 51 Sep 26 08:39 ahcich2.fault > > crw------- 1 root wheel 0, 50 Sep 26 08:39 ahcich2.locate > > crw------- 1 root wheel 0, 53 Sep 26 08:39 ahcich3.fault > > crw------- 1 root wheel 0, 52 Sep 26 08:39 ahcich3.locate > > crw------- 1 root wheel 0, 55 Sep 26 08:39 ahcich4.fault > > crw------- 1 root wheel 0, 54 Sep 26 08:39 ahcich4.locate > > crw------- 1 root wheel 0, 57 Sep 26 08:44 ahcich5.fault > > crw------- 1 root wheel 0, 56 Sep 26 08:44 ahcich5.locate > > crw------- 1 root wheel 0, 36 Sep 26 08:39 igb0 > > crw------- 1 root wheel 0, 37 Sep 26 08:39 igb1 > > crw------- 1 root wheel 0, 38 Sep 26 08:39 isci.bus0.port0.fault > > crw------- 1 root wheel 0, 39 Sep 26 08:39 isci.bus0.port0.locate > > crw------- 1 root wheel 0, 40 Sep 26 08:42 isci.bus0.port1.fault > > crw------- 1 root wheel 0, 41 Sep 26 08:42 isci.bus0.port1.locate > > crw------- 1 root wheel 0, 42 Sep 26 08:39 isci.bus0.port2.fault > > crw------- 1 root wheel 0, 43 Sep 26 08:39 isci.bus0.port2.locate > > crw------- 1 root wheel 0, 44 Sep 26 08:39 isci.bus0.port3.fault > > crw------- 1 root wheel 0, 45 Sep 26 08:39 isci.bus0.port3.locate > > > > By the way the main board X9DRi-F has only one bus. The X9DR3-F has 2 > buses. > > > > The patch (compared to 9.1 RC1) is attached. > > > > Is it possible to commit this patch into 9.1 or is it too late? > > I think it is too late. The changes here are very low risk, but it is > a new feature and not a bug fix so not really appropriate for 9.1 at > this point. > > Thank you for testing the patch! > > Regards, > > -Jim > > > > Regards > > Paul > > > > Hint: If anybody is using a SC825TQ chassis and no led is blinking check > ALL jumper settings of your backplane (Appendix C of > http://www.supermicro.com/manuals/chassis/2U/SC825.pdf). Our backplane was wrongly configured by > factory (mixture of sgpio and i2c settings). > > > > From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 26 18:42:50 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 124BA1065674 for ; Wed, 26 Sep 2012 18:42:50 +0000 (UTC) (envelope-from jim.harris@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B66C28FC12 for ; Wed, 26 Sep 2012 18:42:49 +0000 (UTC) Received: by vbmv11 with SMTP id v11so1326859vbm.13 for ; Wed, 26 Sep 2012 11:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nPA4TMgPMh/jKMF5lQkUcebLBH5qwcRq/eZVdvTEeMI=; b=XzmbpNuOPCdogRbVNNzl/B5V2gB0y5auPSWUNKzWQcm5wtx3etkASbAFy/MaUrlUvk /8rrefww9+l9XCF/VcRh46Jk1TyuFqP/hHPFXb2HPMl1k5g4w8cBBxE7g9BX0AmrXbiZ JVlx1KApYhHyj/R7B5a3pTcusqdndr7fLGLlSV90X0/Ljvs5Wt2VVlFSD0QoFTw3Fi+G EoUK8n9Z99QURp7i5shSFF4VTJ/IdT9wdyRFDSwGz2cPRnCLFxI7DAlR1oo5yhTsBncV V2nutzo17XPBncIg9Rc6HgRqUKu3UPXCKqpcCLQllYY/uZgLRd52fL8D4sdGkMcbPDKZ W9Xg== MIME-Version: 1.0 Received: by 10.220.154.2 with SMTP id m2mr774451vcw.18.1348684968621; Wed, 26 Sep 2012 11:42:48 -0700 (PDT) Sender: jim.harris@gmail.com Received: by 10.59.10.98 with HTTP; Wed, 26 Sep 2012 11:42:48 -0700 (PDT) In-Reply-To: <20120926181723.327430@gmx.net> References: <20120923140816.144270@gmx.net> <20120926093759.299750@gmx.net> <20120926181723.327430@gmx.net> Date: Wed, 26 Sep 2012 11:42:48 -0700 X-Google-Sender-Auth: uyxYHWEnZ-_hWe8eU8iIabJoQA0 Message-ID: From: Jim Harris To: Paul Maulberger Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-scsi@freebsd.org Subject: Re: Intel C600 SAS Controller + locate LED (SGPIO) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 18:42:50 -0000 On Wed, Sep 26, 2012 at 11:17 AM, Paul Maulberger wrote: > Hi Folks, > > I do not share Jim's opinion. I think the fault led should be access-able by the userspace. > > I have a special system monitor daemon which although checks the S.M.A.R.T. information of the hard drive. If information X is above value Y the system monitor daemon informs the admin and sets the fault led. > > In this case the driver could not set the fault led because it does not know "my" value Y. > > As the fault led is rarely set the userspace and the driver should have shared access to the led. Also a conflict could be easily solved: > > solution a: The last one wins. > > solution b: If the driver sets the fault led the userspace could not clear it. > > What do you think? I'm OK with giving error LED userspace access based on your scenario. You only mentioned wanting to use the locate LEDs in your original post, so I assumed you were trying to get isci to match ahci behavior rather than having a specific need for accessing the error LEDs. But I'd like the patch to be modified to store current value of both error and locate onoff in the ISCI_LED object. This ensures that current error LED value is maintained when the locate callback is invoked, and vice versa. If you could also test simultaneous writes to error and locate LEDs on same port, I would appreciate it. The system I have here does not have separate LEDs for locate and error. Thanks, -Jim > Regards > Paul > > -------- Original-Nachricht -------- >> Datum: Wed, 26 Sep 2012 08:57:13 -0700 >> Von: Jim Harris >> An: Paul Maulberger >> CC: freebsd-scsi@freebsd.org >> Betreff: Re: Intel C600 SAS Controller + locate LED (SGPIO) > >> On Wed, Sep 26, 2012 at 2:37 AM, Paul Maulberger >> wrote: >> > Hi Jim, >> > >> > your patch is working very well. Thanks a lot! >> > >> > To support the locate and the fault led I extended your patch a little >> bit. Like the ahci driver every port has now a locate and a fault led >> device. >> >> Hi Paul, >> >> I am reluctant to add LEDs for error, even though I know AHCI driver >> does this today. I don't see the need for userspace to manipulate >> both locate and error LEDs - it seems locate is sufficient. I'd >> prefer to keep error LED reserved for future use in the driver. >> >> But I will add "locate" to the LED name, just to make it more clear. >> >> > # ls -al /dev/led >> > total 1 >> > dr-xr-xr-x 2 root wheel 512 Sep 26 08:39 . >> > dr-xr-xr-x 11 root wheel 512 Sep 26 10:39 .. >> > crw------- 1 root wheel 0, 47 Sep 26 08:43 ahcich0.fault >> > crw------- 1 root wheel 0, 46 Sep 26 08:44 ahcich0.locate >> > crw------- 1 root wheel 0, 49 Sep 26 08:39 ahcich1.fault >> > crw------- 1 root wheel 0, 48 Sep 26 08:39 ahcich1.locate >> > crw------- 1 root wheel 0, 51 Sep 26 08:39 ahcich2.fault >> > crw------- 1 root wheel 0, 50 Sep 26 08:39 ahcich2.locate >> > crw------- 1 root wheel 0, 53 Sep 26 08:39 ahcich3.fault >> > crw------- 1 root wheel 0, 52 Sep 26 08:39 ahcich3.locate >> > crw------- 1 root wheel 0, 55 Sep 26 08:39 ahcich4.fault >> > crw------- 1 root wheel 0, 54 Sep 26 08:39 ahcich4.locate >> > crw------- 1 root wheel 0, 57 Sep 26 08:44 ahcich5.fault >> > crw------- 1 root wheel 0, 56 Sep 26 08:44 ahcich5.locate >> > crw------- 1 root wheel 0, 36 Sep 26 08:39 igb0 >> > crw------- 1 root wheel 0, 37 Sep 26 08:39 igb1 >> > crw------- 1 root wheel 0, 38 Sep 26 08:39 isci.bus0.port0.fault >> > crw------- 1 root wheel 0, 39 Sep 26 08:39 isci.bus0.port0.locate >> > crw------- 1 root wheel 0, 40 Sep 26 08:42 isci.bus0.port1.fault >> > crw------- 1 root wheel 0, 41 Sep 26 08:42 isci.bus0.port1.locate >> > crw------- 1 root wheel 0, 42 Sep 26 08:39 isci.bus0.port2.fault >> > crw------- 1 root wheel 0, 43 Sep 26 08:39 isci.bus0.port2.locate >> > crw------- 1 root wheel 0, 44 Sep 26 08:39 isci.bus0.port3.fault >> > crw------- 1 root wheel 0, 45 Sep 26 08:39 isci.bus0.port3.locate >> > >> > By the way the main board X9DRi-F has only one bus. The X9DR3-F has 2 >> buses. >> > >> > The patch (compared to 9.1 RC1) is attached. >> > >> > Is it possible to commit this patch into 9.1 or is it too late? >> >> I think it is too late. The changes here are very low risk, but it is >> a new feature and not a bug fix so not really appropriate for 9.1 at >> this point. >> >> Thank you for testing the patch! >> >> Regards, >> >> -Jim >> >> >> > Regards >> > Paul >> > >> > Hint: If anybody is using a SC825TQ chassis and no led is blinking check >> ALL jumper settings of your backplane (Appendix C of >> http://www.supermicro.com/manuals/chassis/2U/SC825.pdf). Our backplane was wrongly configured by >> factory (mixture of sgpio and i2c settings). >> > >> >