From owner-freebsd-scsi@FreeBSD.ORG Sun Sep 26 00:02:04 2010 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 3AF5C1065670 for ; Sun, 26 Sep 2010 00:02:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D5D1B8FC12 for ; Sun, 26 Sep 2010 00:02:03 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o8PNPopr096282; Sat, 25 Sep 2010 17:25:51 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long In-Reply-To: <86aan67obp.fsf@ds4.des.no> Date: Sat, 25 Sep 2010 17:25:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2EA9CBBC-3F97-4AF2-BFB5-96DF39FDE376@saers.com> <86aan67obp.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org, Niklas Saers Subject: Re: mfi - setting up disks 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, 26 Sep 2010 00:02:04 -0000 On Sep 24, 2010, at 4:45 PM, Dag-Erling Sm=F8rgrav wrote: > Niklas Saers writes: >> In the SuperMicro system where I had problems with the mpt = controller, >> I switched it for a mfi-based controller. I had it set up with 36x >> RAID0 volumes with each their own disk (no way to access the disk >> otherwise I found), and added them to a ZFS system. The numbering >> became a bit weird, so I pulled the disks out one by one and put them >> back to figure out and note down what disk number was in what >> slot. Only test data on my ZFS volume, so I didn't mind that = crashing. >=20 > You can wire down SCSI buses and disks in /boot/device.hints so each > disk always gets the same device number regardless of the order in = which > the disks spin up. The syntax is documented in /sys/conf/NOTES = (search > for "SCSI DEVICE CONFIGURATION"). It's a CAM feature, and mfi uses = CAM, MFI only uses CAM for passthrough access to component drives, not for = normal I/O. Setting CAM wiring hints will not solve the problem at = hand. And the problem at hand isn't really even numbering, it's that = the MFI firmware freaked out and marked the disks inaccessible. I think = that this happened to us at Yahoo once, and we eventually gave up and = replaced the disks. Putting the disks on a non-LSI, non-RAID controller = and writing 0's to the last 10MB worth of sectors (or just writing 0's = to the entire drive) will likely solve the problem, but YMMV. Scott From owner-freebsd-scsi@FreeBSD.ORG Sun Sep 26 18:46:58 2010 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 3A52E1065672 for ; Sun, 26 Sep 2010 18:46:58 +0000 (UTC) (envelope-from niklas@saers.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id C5C4E8FC18 for ; Sun, 26 Sep 2010 18:46:57 +0000 (UTC) Received: by ewy22 with SMTP id 22so1287985ewy.13 for ; Sun, 26 Sep 2010 11:46:56 -0700 (PDT) Received: by 10.213.35.2 with SMTP id n2mr1909583ebd.62.1285526816471; Sun, 26 Sep 2010 11:46:56 -0700 (PDT) Received: from [192.168.0.198] (x1-6-00-24-01-67-20-00.k428.webspeed.dk [83.89.13.33]) by mx.google.com with ESMTPS id a48sm7095644eei.19.2010.09.26.11.46.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 26 Sep 2010 11:46:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Niklas Saers In-Reply-To: Date: Sun, 26 Sep 2010 20:46:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4EF4B99C-8550-4207-BBDB-391CF4F2D940@saers.com> References: <2EA9CBBC-3F97-4AF2-BFB5-96DF39FDE376@saers.com> <86aan67obp.fsf@ds4.des.no> To: Scott Long X-Mailer: Apple Mail (2.1081) Cc: freebsd-scsi@freebsd.org, Jakob Jensen , =?iso-8859-1?Q?michael_Kj=F8gx?= , =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Subject: Re: mfi - setting up disks 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, 26 Sep 2010 18:46:58 -0000 Hi Scott & Dag-Erling, On Sep 26, 2010, at 1:25 AM, Scott Long wrote: > MFI only uses CAM for passthrough access to component drives, not for = normal I/O. Setting CAM wiring hints will not solve the problem at = hand. And the problem at hand isn't really even numbering, it's that = the MFI firmware freaked out and marked the disks inaccessible. I think = that this happened to us at Yahoo once, and we eventually gave up and = replaced the disks. Putting the disks on a non-LSI, non-RAID controller = and writing 0's to the last 10MB worth of sectors (or just writing 0's = to the entire drive) will likely solve the problem, but YMMV. Indeed, "mfiutil locate" gave us all we needed for identifying the disk, = so numbering is no longer an issue. Thanks for the tip on how to get the = disk back up, I'll make sure we try that this week. I tried the let-the-RAID-controller-make-RAIDs-and-join-them-via-ZFS = model on the mpt-based controller, and that made performance drop from = ~250 mb/sec to ~4 mb/sec. With mfi (the system is otherwise unchanged), = the average speed is ~200 mb/sec, down ~50 mb/sec. Cheers Nik= From owner-freebsd-scsi@FreeBSD.ORG Sun Sep 26 21:24:05 2010 Return-Path: Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF36B106566C; Sun, 26 Sep 2010 21:24:05 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 95EC58FC1E; Sun, 26 Sep 2010 21:24:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8QLO5IQ028680; Sun, 26 Sep 2010 21:24:05 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8QLO5xd028676; Sun, 26 Sep 2010 21:24:05 GMT (envelope-from linimon) Date: Sun, 26 Sep 2010 21:24:05 GMT Message-Id: <201009262124.o8QLO5xd028676@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-scsi@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/150936: [ciss] [patch] Write possibility of the RAID1 level 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, 26 Sep 2010 21:24:05 -0000 Old Synopsis: [ciss] Write possibility of the RAID1 level New Synopsis: [ciss] [patch] Write possibility of the RAID1 level Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi Responsible-Changed-By: linimon Responsible-Changed-When: Sun Sep 26 21:23:45 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=150936 From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 27 11:07:02 2010 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 AC8081065679 for ; Mon, 27 Sep 2010 11:07:02 +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 9B1508FC15 for ; Mon, 27 Sep 2010 11:07:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8RB72EH023583 for ; Mon, 27 Sep 2010 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8RB72s6023581 for freebsd-scsi@FreeBSD.org; Mon, 27 Sep 2010 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Sep 2010 11:07:02 GMT Message-Id: <201009271107.o8RB72s6023581@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, 27 Sep 2010 11:07:02 -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/150936 scsi [ciss] [patch] Write possibility of the RAID1 level o kern/149502 scsi [mpt] Latent buglet in debug print code 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/141934 scsi [cam] [patch] add support for SEAGATE DAT Scopion 130 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 p kern/130735 scsi [cam] [patch] pass M_NOWAIT to the malloc() call insid 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/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping 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/119668 scsi [cam] [patch] certain errors are too verbose comparing 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/94838 scsi Kernel panic while mounting SD card with lock switch o 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/40895 scsi wierd kernel / device driver bug 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 42 problems total. From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 29 09:59:19 2010 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 8A7911065670; Wed, 29 Sep 2010 09:59:19 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7B1D38FC13; Wed, 29 Sep 2010 09:59:18 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA22932; Wed, 29 Sep 2010 12:47:17 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P0tFt-0003KE-Ge; Wed, 29 Sep 2010 12:47:17 +0300 Message-ID: <4CA30B24.8040707@freebsd.org> Date: Wed, 29 Sep 2010 12:47:16 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Kenneth D. Merry" , freebsd-scsi@freebsd.org References: <4BCDEBF6.3030609@icyb.net.ua> <20100423184412.GA5016@nargothrond.kdm.org> <4BD1FC74.3090504@freebsd.org> In-Reply-To: <4BD1FC74.3090504@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: cam.3: do not discourage use of cam_open_device 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, 29 Sep 2010 09:59:19 -0000 Reviving this thread. Sorry for top-posting. Here's a patch that removes any "artificial intelligence" from cam_get_device() and thus from cam_open_device() as well: http://people.freebsd.org/~avg/cam_get_device.diff This removes the following features: 1. ignoring 'r' and 'n' at the start of device name 2. ignoring whitespace at end of device name (why put it there in the first place) 3. parsing and ignoring slice and partition names So, only plain device names like /dev/foo0 or foo1 are supported. Perhaps we could also remove sd => da and st => sa mapping at this time too? on 23/04/2010 23:00 Andriy Gapon said the following: > on 23/04/2010 21:44 Kenneth D. Merry said the following: >> On Tue, Apr 20, 2010 at 21:01:26 +0300, Andriy Gapon wrote: >>> This is based on my understanding what Scott Long tried to explain me a while ago. >>> >>> Index: lib/libcam/cam.3 >>> =================================================================== >>> --- lib/libcam/cam.3 (revision 206902) >>> +++ lib/libcam/cam.3 (working copy) >>> @@ -190,12 +190,6 @@ >>> Once the device name and unit number >>> are determined, a lookup is performed to determine the passthrough device >>> that corresponds to the given device. >>> -.Fn cam_open_device >>> -is rather simple to use, but it is not really suitable for general use >>> -because its behavior is not necessarily deterministic. >>> -Programmers writing >>> -new applications should make the extra effort to use one of the other open >>> -routines documented below. >>> .Pp >>> .Fn cam_open_spec_device >>> opens the >>> >>> >>> It seems that this warning about ambiguity came from pre-devfs days when e.g. cd0 >>> nodes in different directories could correspond to different actual SCSI >>> peripherals. It seems that there wasn't an ambiguity if an absolute device path >>> was given. >>> >>> Nowadays, cam_open_device seems to always do a proper job of finding a correct >>> pass device. >> >> The warning had more to do with the ambiguity trying to make sense of >> device names than having different device nodes lying around. >> >> cam_get_device() (which is called by cam_open_device()) tries to do >> some things that will break on devices that start with n (unless it's a >> non-rewound tape device) or r. Right now we don't have any CAM peripheral >> drivers that start with those letters, so it works. It also won't do the >> right thing on devices with gpt partitions. Some of that can be fixed, >> though. >> >> So it's mostly deterministic, but it may not do exactly what you expect. >> >> It may be good to keep some statement in there pointing people to the other >> routines as being preferred because they're a little more deterministic. > > These are very valid concerns. > I was aware that we ditched "r" (raw) devices quite a while ago, but wasn't sure > about "n" kind as I have never dealt with tapes in my life. > Perhaps we can just remove that code now? > > Also, from my point of view, it doesn't make any sense to support > cam_open_device() calls on slices, partitions, etc. I mean, what is a > passthough device for a slice of disk? Can you send SCSI commands to a slice? > > All these comes from my (limited) practical experience with some userland > applications where people were afraid to use cam_open_device() because of the > warning in question. So they went out of the way to "manually" establish > mapping from an original device name to a corresponding passthough device. > > So, I'd like to let people know that it's totally OK to use cam_open_device() > with "normal" device names. I don't care about the extra logic ("r", "n" > prefixes; partition/slice suffixes). > > But that's only my point of view. > > And thank you for the explanation! > -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Sat Oct 2 08:20:04 2010 Return-Path: Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A3441065672 for ; Sat, 2 Oct 2010 08:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1FBC78FC0C for ; Sat, 2 Oct 2010 08:20:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o928K48h020005 for ; Sat, 2 Oct 2010 08:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o928K3Ir020003; Sat, 2 Oct 2010 08:20:03 GMT (envelope-from gnats) Date: Sat, 2 Oct 2010 08:20:03 GMT Message-Id: <201010020820.o928K3Ir020003@freefall.freebsd.org> To: freebsd-scsi@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/150936: commit references a PR X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 08:20:04 -0000 The following reply was made to PR kern/150936; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/150936: commit references a PR Date: Sat, 2 Oct 2010 08:18:25 +0000 (UTC) Author: kib Date: Sat Oct 2 08:18:19 2010 New Revision: 213354 URL: http://svn.freebsd.org/changeset/base/213354 Log: Cosmetic: make it less confusing when displaying RAID 1 level, that might be 1+0 as well. PR: kern/150936 MFC after: 2 weeks Modified: head/sys/dev/ciss/ciss.c Modified: head/sys/dev/ciss/ciss.c ============================================================================== --- head/sys/dev/ciss/ciss.c Sat Oct 2 08:11:38 2010 (r213353) +++ head/sys/dev/ciss/ciss.c Sat Oct 2 08:18:19 2010 (r213354) @@ -4394,7 +4394,7 @@ ciss_name_ldrive_org(int org) case CISS_LDRIVE_RAID0: return("RAID 0"); case CISS_LDRIVE_RAID1: - return("RAID 1"); + return("RAID 1(1+0)"); case CISS_LDRIVE_RAID4: return("RAID 4"); case CISS_LDRIVE_RAID5: _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"