From owner-freebsd-scsi@FreeBSD.ORG Sun Jan 29 01:12:01 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27F6316A420; Sun, 29 Jan 2006 01:12:01 +0000 (GMT) (envelope-from nate@root.org) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5767E43D53; Sun, 29 Jan 2006 01:12:00 +0000 (GMT) (envelope-from nate@root.org) Received: from ylpvm01.prodigy.net (ylpvm01-int.prodigy.net [207.115.5.207]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id k0T1BreY009374; Sat, 28 Jan 2006 20:11:56 -0500 X-ORBL: [71.139.114.10] Received: from [10.0.0.115] (ppp-71-139-114-10.dsl.snfc21.pacbell.net [71.139.114.10]) by ylpvm01.prodigy.net (8.13.4 dk-milter linux/8.13.4) with ESMTP id k0T1BsUi000542; Sat, 28 Jan 2006 20:11:55 -0500 Message-ID: <43DC1669.2000900@root.org> Date: Sat, 28 Jan 2006 17:12:09 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050723) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: CAM target and quirk docs 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, 29 Jan 2006 01:12:01 -0000 I recently updated my web page (here): http://root.org/~nate/freebsd/ I added a doc that describes the target mode interface to CAM and the path ATIO/CTIO take through the system. I also added a link to the quirks guide (how to test and report quirks). Hope this helps, -- Nate From owner-freebsd-scsi@FreeBSD.ORG Sun Jan 29 14:10:33 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A881A16A420 for ; Sun, 29 Jan 2006 14:10:33 +0000 (GMT) (envelope-from marco@beishuizen.info) Received: from smtp14.wxs.nl (smtp14.wxs.nl [195.121.247.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C2EE43D45 for ; Sun, 29 Jan 2006 14:10:32 +0000 (GMT) (envelope-from marco@beishuizen.info) Received: from yokozuna.lan (ipd50a233c.speed.planet.nl [213.10.35.60]) by smtp14.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ITU009LOY1GRO@smtp14.wxs.nl> for freebsd-scsi@freebsd.org; Sun, 29 Jan 2006 15:10:28 +0100 (CET) Received: from yokozuna.lan (yokozuna.lan [127.0.0.1]) by yokozuna.lan (8.13.4/8.13.1) with ESMTP id k0TEASpR013862 for ; Sun, 29 Jan 2006 15:10:28 +0100 (CET envelope-from marco@beishuizen.info) Date: Sun, 29 Jan 2006 15:10:28 +0100 (CET) From: Marco Beishuizen Sender: marco@yokozuna.lan To: FreeBSD SCSI mailing list Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT FreeBSD: Homepage: Subject: RAID level migration and FreeBSD slice/partitions X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marco Beishuizen List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 14:10:33 -0000 Hello, I would like to add 2 SCSI disks to my RAID controller (an Intel SRCU42X, the new disks are Seagate Cheetahs 36GB) and migrate to RAID 5. At the moment the controller has 2 disks attached to it (also 2x Seagate Cheetah 36GB) in RAID 0. According to the documentation of the controller this should be possible, but my question is what happens with the size of the slice and partitions of FreeBSD? Do they grow or do I have a lot of empty space after the migration? Hope someone knows the answer. Thanks, Marco -- Croll's Query: If tin whistles are made of tin, what are foghorns made of? From owner-freebsd-scsi@FreeBSD.ORG Mon Jan 30 11:02:47 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7B6D16A420 for ; Mon, 30 Jan 2006 11:02:47 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2231143D5A for ; Mon, 30 Jan 2006 11:02:47 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0UB2lHv019968 for ; Mon, 30 Jan 2006 11:02:47 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0UB2jQX019962 for freebsd-scsi@freebsd.org; Mon, 30 Jan 2006 11:02:45 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 30 Jan 2006 11:02:45 GMT Message-Id: <200601301102.k0UB2jQX019962@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 30 Jan 2006 11:02:48 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/05/03] kern/27059 scsi [sym] SCSI subsystem hangs under heavy lo o [2001/06/29] kern/28508 scsi problems with backup to Tandberg SLR40 st o [2002/06/17] kern/39388 scsi ncr/sym drivers fail with 53c810 and more o [2002/07/22] kern/40895 scsi wierd kernel / device driver bug o [2003/05/24] kern/52638 scsi [panic] SCSI U320 on SMP server won't run s [2003/09/30] kern/57398 scsi [mly] Current fails to install on mly(4) o [2003/12/26] kern/60598 scsi wire down of scsi devices conflicts with o [2003/12/27] kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C81 s [2004/01/10] kern/61165 scsi [panic] kernel page fault after calling c o [2004/12/02] kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5 o [2005/06/04] kern/81887 scsi [aac] Adaptec SCSI 2130S aac0: GetDeviceP o [2005/12/12] kern/90282 scsi [sym] SCSI bus resets cause loss of ch de 12 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/12/06] kern/23314 scsi aic driver fails to detect Adaptec 1520B o [2002/02/23] kern/35234 scsi World access to /dev/pass? (for scanner) o [2002/06/02] kern/38828 scsi [feature request] DPT PM2012B/90 doesn't o [2002/10/29] kern/44587 scsi dev/dpt/dpt.h is missing defines required o [2005/01/12] kern/76178 scsi [ahd] Problem with ahd and large SCSI Rai 5 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Jan 30 16:27:05 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AB7A16A420 for ; Mon, 30 Jan 2006 16:27:05 +0000 (GMT) (envelope-from se@freebsd.org) Received: from mail.atsec.com (mail.atsec.com [195.30.252.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6181343D48 for ; Mon, 30 Jan 2006 16:27:04 +0000 (GMT) (envelope-from se@freebsd.org) Received: (qmail 30211 invoked by uid 10125); 30 Jan 2006 16:27:03 -0000 X-SpaceNet-Virusscan: Sophos Version: 4.00; Last IDE Update: 2006-01-30 15:40 no information about results Received: from p508780cc.dip0.t-ipconnect.de (HELO ?192.168.0.12?) (80.135.128.204) by mail.atsec.com with SMTP; 30 Jan 2006 16:27:02 -0000 X-SpaceNet-Authentification: SMTP AUTH verified Message-ID: <43DE3E38.2080902@FreeBSD.org> Date: Mon, 30 Jan 2006 17:26:32 +0100 From: Stefan Esser User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: olli@lurza.secnetix.de References: <200601251000.k0PA02CY070581@lurza.secnetix.de> In-Reply-To: <200601251000.k0PA02CY070581@lurza.secnetix.de> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.ORG, matthias.andree@gmx.de Subject: Re: SCSI scanner, sym/ncr driver, pt(4) 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, 30 Jan 2006 16:27:05 -0000 Oliver Fromme schrieb: > Matthias Andree wrote: > > Oliver Fromme writes: > > There was a time when sym(4) didn't support the more efficient > > LOAD/STORE uncapable 810, 815, 825 chips (the A variants, where they > > exist, support LOAD/STORE). sym(4) has learned to use MEMMOVE on these, > > however. > > > > ncr(4) has never used LOAD/STORE, and lacks support for the 897 chip and > > the 1010 family. I think I can clarify the situation. The NCR driver supports all chips except for the 1010 (I think it should work with the 895/897, though I never owned one and haven't checked the sources). Because of the many problems with the Linux ncr53c8xx driver (which did not even support SCSI Disconnect), Gerard Roudier ported the BSD NCR driver to Linux where it was known as the BSD NCR driver at that time. After he had managed to complete the interface shims, he split the driver into an OS dependent part (different for BSD and Linux) and the low level driver code. While I did not want to give up support for the first generation of NCR chips (which had to use self modifying code in a lot of places for lack of better addressing modes in the early NCR SCRIPTS engine), Gerard simplified the micro code by use of the LOAD/STORE. Since at that time the NCR chip company had been bought by Hyundai (IIRC) and named Symbios, Gerard renamed the driver to "sym" (since it still supported the chips sold by Symbios, but not some of the earlier chips developed by NCR). At that time Gerard became a FreeBSD comitter and actively maintained the "sym" driver on FreeBSD (and also to some degree the "ncr" driver, which still has much in common with "sym"). A job change meant that could not keep up maintaining the NCR driver and I was glad to see that Gerard took over, but it appears, that he has not been active in the project for several years. I have considered declaring myself maintainer of both ncr and sym drivers, since I guess that I know there development and internal structure best, but I'm still extremely short of spare time (and while I still own some of the hardware used to develop the NCT driver, none of it is currently installed in any of my systems). I had started writing an improved NCR driver (which could take advantage of all possible combinations of features in the different chips), but when I found that I did not even have time to maintain the existing driver, I gave up on finishing it. Besides with the sym driver being maintained and made to support newer chips, the ncr driver was only relevant for the old chips left behind by sym. > I've read about that LOAD/STORE and MEMMOVE stuff in the > manpage, but I'm not a SCSI expert, so that's really only > gibberish to me, I'm afraid. Hell, I do not even know if > my "810" card is an "early NCR 810" which sym(4) keeps > talking about. The 810 is early, the 810A is a second generation chip. The 860 is a faster version of the 810A (or rather the 860 was the sequel to the 810 and offered the enhanced instruction set, the 810A is a slower variant offering only the original 5MB/s instead of the 860s 10MB/s). > If you're just a user, the manpages fail to tell whether > the sym(4) or ncr(4) driver is preferred for an 810 host > adapter. If you include both drivers in a kernel, "sym" will be used for all chips it supports. I might have a look at the man pages, though ... > > > But I wonder if the ncr(4) driver offered any advantages. > > > > It doesn't. There used to be a time when it worked with the old 810 and > > sym(4) didn't, but this no longer holds. Hmmm, this is news to me. That would require the sym driver to contain both sets of SCRIPTS code, the one from the NCR driver and the one from the sym driver. > OK, so the ncr(4) should be regarded obsolete, right? In > that case, the manpage should say so, at least. I don't think so ... Except if you consider the 53c810 obsolete, though it is still quite useful for slower SCSI peripherals. Regards, STefan From owner-freebsd-scsi@FreeBSD.ORG Mon Jan 30 16:38:31 2006 Return-Path: X-Original-To: freebsd-scsi@FreeBSD.ORG Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEE7116A422 for ; Mon, 30 Jan 2006 16:38:31 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 9D23B43D48 for ; Mon, 30 Jan 2006 16:38:26 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: (qmail invoked by alias); 30 Jan 2006 16:38:25 -0000 Received: from p509137A1.dip0.t-ipconnect.de (EHLO m2a2.dyndns.org) [80.145.55.161] by mail.gmx.net (mp010) with SMTP; 30 Jan 2006 17:38:25 +0100 X-Authenticated: #428038 Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 41B08200BC7; Mon, 30 Jan 2006 17:38:24 +0100 (CET) Received: from m2a2.dyndns.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19378-20; Mon, 30 Jan 2006 17:38:22 +0100 (CET) Received: by merlin.emma.line.org (Postfix, from userid 500) id E906F200BC9; Mon, 30 Jan 2006 17:38:21 +0100 (CET) Date: Mon, 30 Jan 2006 17:38:21 +0100 From: Matthias Andree To: Stefan Esser Message-ID: <20060130163821.GC19173@merlin.emma.line.org> Mail-Followup-To: Stefan Esser , olli@lurza.secnetix.de, freebsd-scsi@FreeBSD.ORG References: <200601251000.k0PA02CY070581@lurza.secnetix.de> <43DE3E38.2080902@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43DE3E38.2080902@FreeBSD.org> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at emma.line.org X-Y-GMX-Trusted: 0 Cc: freebsd-scsi@FreeBSD.ORG, matthias.andree@gmx.de, olli@lurza.secnetix.de Subject: Re: SCSI scanner, sym/ncr driver, pt(4) 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, 30 Jan 2006 16:38:32 -0000 On Mon, 30 Jan 2006, Stefan Esser wrote: > > > > But I wonder if the ncr(4) driver offered any advantages. > > > > > > It doesn't. There used to be a time when it worked with the old 810 and > > > sym(4) didn't, but this no longer holds. > > Hmmm, this is news to me. That would require the sym driver to contain > both sets of SCRIPTS code, the one from the NCR driver and the one from > the sym driver. The man page sym(4) reads (as of 6-STABLE): "sym also uses LOAD/STORE SCRIPTS instructions for chips that support it. Only the early 810, 815 and 825 NCR chips do not support LOAD/STORE. Use of LOAD/STORE instead of MEMORY MOVE allows SCRIPTS to access IO registers internal to the chip (no external PCI cycles). As a result, the driver guarantees that no PCI self-mastering will occur for chips that support LOAD/STORE." -- Matthias Andree From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 31 01:51:36 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D4F816A420; Tue, 31 Jan 2006 01:51:36 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from smtp.xbsd.org (xbsd.org [82.233.2.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6619443D4C; Tue, 31 Jan 2006 01:51:35 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 208A5114BF; Tue, 31 Jan 2006 02:51:34 +0100 (CET) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40065-04; Tue, 31 Jan 2006 02:51:23 +0100 (CET) Received: from cream.xbsd.org (cream.xbsd.org [192.168.42.6]) by smtp.xbsd.org (Postfix) with ESMTP id 6D61211498; Tue, 31 Jan 2006 02:51:22 +0100 (CET) From: Florent Thoumie To: Nate Lawson Date: Tue, 31 Jan 2006 02:51:08 +0100 User-Agent: KMail/1.8.2 References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <200601310133.34152.flz@xbsd.org> <43DEB6C5.8090504@root.org> In-Reply-To: <43DEB6C5.8090504@root.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1193124.iTfgH26Rz4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601310251.16946.flz@xbsd.org> X-Virus-Scanned: amavisd-new at xbsd.org Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs 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, 31 Jan 2006 01:51:36 -0000 --nextPart1193124.iTfgH26Rz4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 31 January 2006 02:00, Nate Lawson wrote: > Florent Thoumie wrote: > > On Tuesday 31 January 2006 01:24, Nate Lawson wrote: > >>I'm not concerned about the revision. I'm concerned about the vendor > >>(Generic*) and device name (STORAGE DEVICE*). Why are the *'s needed? > > > > Seemed common practice reading the other entries. > > No, that's definitely not it. In fact, the most recent entries should > be audited to see if they really need the *'s. This wildcard might > overly match the wrong devices. > > >>(Again, a PR would help track this kind of conversation as shown in > >>previous PRs about quirks. Submitters often match way too much.) > >> > >>>Do you want me to create a PR just for tracking purposes? > >>>[1] http://docs.freebsd.org/cgi/mid.cgi?20060116193024.GA95183 > >> > >>That would be nice, especially since some of the requested info is > >>missing (dmesg, usbdevs -v). However, if you cited a email in the > >>commit msg (maybe SMTP Message-ID) such that we could find it in the > >>future, that would probably be enough. I'm not trying to create a > >>bureaucracy, just make sure we don't lose information like we used to on > >>why a quirk was added in the first place. > > > > I only mentioned the freebsd-usb mailing list. I'll contact Anders to g= et > > additional details and I (or he) will fill a PR so that we can add it to > > the comment. > > Thanks. > > > It seems a lot of devices are concerned by the sync cache problem, would > > it be harmful to just remove this part of the code or could there be a > > way to detect if the device supports it or not? > > Well, it's important to run SYNC_CACHE in shutdown or possibly when > unmounting a filesystem. Otherwise, data could be lost on boot. > However, I support adding a USB-specific mechanism that says SYNC_CACHE > should only be run on shutdown or device_eject, that way devices that > hang after this command is run would still work at runtime. And SCSI > devices that support multiple calls to SYNC_CACHE (i.e. most non-USB > devs) would still work too. > > However, the first step is to investigate what windows and Linux do. Linux only sends the SYNCHRONIZE_CACHE command if the WCE (Write Cache Enab= le)=20 bit of the disk is set. I can't seem to find something equivalent to this i= n=20 our CAM framework. I have no particular SCSI knowledge but I guess I can ha= ve=20 a look at this tomorrow. I'm forwarding this to freebsd-scsi@ (keep me CC'ed, as I'm not subscribed = to=20 this list, yet). =2D-=20 =46lorent Thoumie flz@FreeBSD.org =46reeBSD Committer --nextPart1193124.iTfgH26Rz4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD3sKUMxEkbVFH3PQRAitXAJ40IV4gpLF//h2PDVva6C3TCKN2hACcD9QQ muyn35Z7+j57eoC+YUMUu6E= =8LJ2 -----END PGP SIGNATURE----- --nextPart1193124.iTfgH26Rz4-- From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 31 05:23:00 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C1AA16A420; Tue, 31 Jan 2006 05:23:00 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7C9B43D45; Tue, 31 Jan 2006 05:22:59 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.53] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k0V5MvEr002952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jan 2006 21:22:58 -0800 Message-ID: <43DEF43A.6090804@root.org> Date: Mon, 30 Jan 2006 21:23:06 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Thoumie References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <200601310133.34152.flz@xbsd.org> <43DEB6C5.8090504@root.org> <200601310251.16946.flz@xbsd.org> In-Reply-To: <200601310251.16946.flz@xbsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs 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, 31 Jan 2006 05:23:00 -0000 Florent Thoumie wrote: > On Tuesday 31 January 2006 02:00, Nate Lawson wrote: > >>Florent Thoumie wrote: >>>It seems a lot of devices are concerned by the sync cache problem, would >>>it be harmful to just remove this part of the code or could there be a >>>way to detect if the device supports it or not? >> >>Well, it's important to run SYNC_CACHE in shutdown or possibly when >>unmounting a filesystem. Otherwise, data could be lost on boot. >>However, I support adding a USB-specific mechanism that says SYNC_CACHE >>should only be run on shutdown or device_eject, that way devices that >>hang after this command is run would still work at runtime. And SCSI >>devices that support multiple calls to SYNC_CACHE (i.e. most non-USB >>devs) would still work too. >> >>However, the first step is to investigate what windows and Linux do. > > > Linux only sends the SYNCHRONIZE_CACHE command if the WCE (Write Cache Enable) > bit of the disk is set. I can't seem to find something equivalent to this in > our CAM framework. I have no particular SCSI knowledge but I guess I can have > a look at this tomorrow. > > I'm forwarding this to freebsd-scsi@ (keep me CC'ed, as I'm not subscribed to > this list, yet). Hmm, is WCE part of the inquiry response? [moving to scsi@ list] -- Nate From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 31 05:33:51 2006 Return-Path: X-Original-To: freebsd-scsi@FreeBSD.org Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0414416A420 for ; Tue, 31 Jan 2006 05:33:51 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A43CD43D45 for ; Tue, 31 Jan 2006 05:33:50 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.4/8.13.4) with ESMTP id k0V5XoxA079198; Mon, 30 Jan 2006 21:33:50 -0800 (PST) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.4/8.13.4/Submit) with ESMTP id k0V5XoqN079195; Mon, 30 Jan 2006 21:33:50 -0800 (PST) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Mon, 30 Jan 2006 21:33:50 -0800 (PST) From: Matthew Jacob X-X-Sender: mjacob@ns1.feral.com To: Nate Lawson In-Reply-To: <43DEF43A.6090804@root.org> Message-ID: <20060130213338.H79194@ns1.feral.com> References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <200601310133.34152.flz@xbsd.org> <43DEB6C5.8090504@root.org> <200601310251.16946.flz@xbsd.org> <43DEF43A.6090804@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-scsi@FreeBSD.org, Florent Thoumie Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthew Jacob List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2006 05:33:51 -0000 >> Linux only sends the SYNCHRONIZE_CACHE command if the WCE (Write Cache >> Enable) bit of the disk is set. I can't seem to find something equivalent >> to this in our CAM framework. I have no particular SCSI knowledge but I >> guess I can have a look at this tomorrow. >> >> I'm forwarding this to freebsd-scsi@ (keep me CC'ed, as I'm not subscribed >> to this list, yet). > > Hmm, is WCE part of the inquiry response? [moving to scsi@ list] Yes. From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 31 11:39:34 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4A8A16A420 for ; Tue, 31 Jan 2006 11:39:34 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from smtp.xbsd.org (xbsd.org [82.233.2.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40A7E43D46 for ; Tue, 31 Jan 2006 11:39:34 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id 654821172F; Tue, 31 Jan 2006 12:39:26 +0100 (CET) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57592-01; Tue, 31 Jan 2006 12:39:16 +0100 (CET) Received: from cream.xbsd.org (cream.xbsd.org [192.168.42.6]) by smtp.xbsd.org (Postfix) with ESMTP id 33058114B1; Tue, 31 Jan 2006 12:39:15 +0100 (CET) From: Florent Thoumie To: Matthew Jacob Date: Tue, 31 Jan 2006 12:38:59 +0100 User-Agent: KMail/1.8.2 References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> In-Reply-To: <20060130213338.H79194@ns1.feral.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3005303.P7i632OuBW"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200601311239.10248.flz@xbsd.org> X-Virus-Scanned: amavisd-new at xbsd.org Cc: freebsd-scsi@freebsd.org, Nate Lawson Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs 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, 31 Jan 2006 11:39:34 -0000 --nextPart3005303.P7i632OuBW Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 31 January 2006 06:33, Matthew Jacob wrote: > >> Linux only sends the SYNCHRONIZE_CACHE command if the WCE (Write Cache > >> Enable) bit of the disk is set. I can't seem to find something > >> equivalent to this in our CAM framework. I have no particular SCSI > >> knowledge but I guess I can have a look at this tomorrow. > >> > >> I'm forwarding this to freebsd-scsi@ (keep me CC'ed, as I'm not > >> subscribed to this list, yet). > > > > Hmm, is WCE part of the inquiry response? [moving to scsi@ list] > > Yes. Hum, reading Linux source and SCSI standard [1], I'm not so sure, but I mig= ht=20 be wrong. We need to request the caching page in scsi_mode_sense_{6,10}. I'll try to write something today, but I guess someone having already worke= d=20 on scsi will only need 10 minutes to DTRT. [1] http://www.danbbs.dk/~dino/SCSI/SCSI2-09.html (table 156) =2D-=20 =46lorent Thoumie flz@FreeBSD.org =46reeBSD Committer --nextPart3005303.P7i632OuBW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD30xeMxEkbVFH3PQRAh5hAJ41awguZx4xg/Mec2huUjS0BNQxjQCfYPHY zo1mPzWax9DpJISLF9IwFU0= =asgn -----END PGP SIGNATURE----- --nextPart3005303.P7i632OuBW-- From owner-freebsd-scsi@FreeBSD.ORG Wed Feb 1 08:02:05 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE1A016A420 for ; Wed, 1 Feb 2006 08:02:05 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8509643D45 for ; Wed, 1 Feb 2006 08:02:05 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (ppp-71-139-114-10.dsl.snfc21.pacbell.net [71.139.114.10]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k11820Er027801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Feb 2006 00:02:01 -0800 Message-ID: <43E06B06.80405@root.org> Date: Wed, 01 Feb 2006 00:02:14 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florent Thoumie References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> In-Reply-To: <200601311239.10248.flz@xbsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, Matthew Jacob Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs 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, 01 Feb 2006 08:02:06 -0000 Florent Thoumie wrote: > On Tuesday 31 January 2006 06:33, Matthew Jacob wrote: > >>>>Linux only sends the SYNCHRONIZE_CACHE command if the WCE (Write Cache >>>>Enable) bit of the disk is set. I can't seem to find something >>>>equivalent to this in our CAM framework. I have no particular SCSI >>>>knowledge but I guess I can have a look at this tomorrow. >>>> >>>>I'm forwarding this to freebsd-scsi@ (keep me CC'ed, as I'm not >>>>subscribed to this list, yet). >>> >>>Hmm, is WCE part of the inquiry response? [moving to scsi@ list] >> >>Yes. > > > Hum, reading Linux source and SCSI standard [1], I'm not so sure, but I might > be wrong. We need to request the caching page in scsi_mode_sense_{6,10}. > > I'll try to write something today, but I guess someone having already worked > on scsi will only need 10 minutes to DTRT. > > [1] http://www.danbbs.dk/~dino/SCSI/SCSI2-09.html (table 156) > You might also want to check if we or Linux set the Immediate bit as part of the SYNCHRONIZE CACHE command. It's possible that USB devices don't properly parse that bit. I think the tape driver (sa) does MODE SENSE as part of normal operation but da does not. (Working frm memory here). -- Nate From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 14:35:09 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AAA716A420 for ; Thu, 2 Feb 2006 14:35:09 +0000 (GMT) (envelope-from age.robekk@ventelo.no) Received: from kirov.kq.no (kirov.kq.no [195.139.204.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 177BF43D45 for ; Thu, 2 Feb 2006 14:35:08 +0000 (GMT) (envelope-from age.robekk@ventelo.no) Received: from aage.i.eunet.no (aage.i.eunet.no [193.71.2.25]) by kirov.kq.no (Postfix) with ESMTP id A522F28C4B for ; Thu, 2 Feb 2006 15:35:07 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by aage.i.eunet.no (Postfix) with ESMTP id 9929F51095 for ; Thu, 2 Feb 2006 15:35:07 +0100 (CET) Message-ID: <43E2189B.1090207@ventelo.no> Date: Thu, 02 Feb 2006 15:35:07 +0100 From: =?ISO-8859-1?Q?=C5ge_R=F8bekk?= User-Agent: Thunderbird 1.5 (X11/20060117) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Problems with Dell PV132T tape changer 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: Thu, 02 Feb 2006 14:35:09 -0000 This changer has two separate changer devices, /dev/ch0 and /dev/ch1. When moving a tape from e.g. slot 0 to drive 0 on /dev/ch0, everything works as it is supposed to. However, trying the same operation on /dev/ch1 fails as follows: # chio -f /dev/ch0 move slot 0 drive 0 chio: /dev/ch0: CHIOMOVE: Input/output error dmesg: [...] (ch1:ahc0:0:5:1): MOVE MEDIUM. CDB: a5 20 0 1 20 6 2 0 0 0 0 0 (ch1:ahc0:0:5:1): CAM Status: SCSI Status Error (ch1:ahc0:0:5:1): SCSI Status: Check Condition (ch1:ahc0:0:5:1): ILLEGAL REQUEST asc:3b,a0 (ch1:ahc0:0:5:1): Vendor Specific ASCQ (ch1:ahc0:0:5:1): Unretryable error # chio -f /dev/ch1 status picker 0: slot 0: slot 1: slot 2: slot 3: slot 4: slot 5: slot 6: slot 7: slot 8: slot 9: slot 10: slot 11: slot 12: slot 13: portal 0: drive 0: # camcontrol devlist -v scbus0 on ahc0 bus 0: at scbus0 target 2 lun 0 (pass0,cd0) at scbus0 target 3 lun 0 (sa0,pass1) at scbus0 target 3 lun 1 (pass2,ch0) at scbus0 target 4 lun 0 (sa1,pass3) at scbus0 target 5 lun 0 (sa2,pass4) at scbus0 target 5 lun 1 (pass5,ch1) at scbus0 target 6 lun 0 (pass6,cd1) < > at scbus0 target -1 lun -1 () scbus1 on ahc1 bus 0: at scbus1 target 1 lun 0 (sa3,pass7) at scbus1 target 1 lun 1 (pass8,ch2) at scbus1 target 2 lun 0 (sa4,pass9) at scbus1 target 3 lun 0 (sa5,pass10) < > at scbus1 target -1 lun -1 () scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) The third changer device (ch2) is an IBM 3575L32 tape library which has been in use for several months, never had any problems. The server is running FreeBSD 5.4-STABLE on i386. -- Åge Røbekk, Ventelo Comnet AS From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 16:21:35 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2165A16A422 for ; Thu, 2 Feb 2006 16:21:35 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 700BB43D45 for ; Thu, 2 Feb 2006 16:21:34 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.13.4/8.12.11) with ESMTP id k12GLX17091031; Thu, 2 Feb 2006 09:21:33 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.13.4/8.12.5/Submit) id k12GLX8s091030; Thu, 2 Feb 2006 09:21:33 -0700 (MST) (envelope-from ken) Date: Thu, 2 Feb 2006 09:21:33 -0700 From: "Kenneth D. Merry" To: ?ge R?bekk Message-ID: <20060202162133.GA90898@nargothrond.kdm.org> References: <43E2189B.1090207@ventelo.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43E2189B.1090207@ventelo.no> User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.87.1/1270/Thu Feb 2 05:47:37 2006 on nargothrond.kdm.org X-Virus-Status: Clean Cc: freebsd-scsi@freebsd.org Subject: Re: Problems with Dell PV132T tape changer 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: Thu, 02 Feb 2006 16:21:35 -0000 On Thu, Feb 02, 2006 at 15:35:07 +0100, ?ge R?bekk wrote: > This changer has two separate changer devices, /dev/ch0 and /dev/ch1. > When moving a tape from e.g. slot 0 to drive 0 on /dev/ch0, everything > works as it is supposed to. However, trying the same operation on > /dev/ch1 fails as follows: > > # chio -f /dev/ch0 move slot 0 drive 0 > chio: /dev/ch0: CHIOMOVE: Input/output error This doesn't quite make sense. You're trying the above command on ch0, but you said the problem is with ch1...and it looks like the command failed on ch0 as well. > dmesg: > > [...] > (ch1:ahc0:0:5:1): MOVE MEDIUM. CDB: a5 20 0 1 20 6 2 0 0 0 0 0 > (ch1:ahc0:0:5:1): CAM Status: SCSI Status Error > (ch1:ahc0:0:5:1): SCSI Status: Check Condition > (ch1:ahc0:0:5:1): ILLEGAL REQUEST asc:3b,a0 > (ch1:ahc0:0:5:1): Vendor Specific ASCQ > (ch1:ahc0:0:5:1): Unretryable error In this case, ch1 didn't like the move medium for some reason, but they've given us a vendor specific error. The other errors in that general vicinity in the spec deal with not being able to do movements requested from a changer. > > # chio -f /dev/ch1 status > picker 0: > slot 0: > slot 1: > slot 2: > slot 3: > slot 4: > slot 5: > slot 6: > slot 7: > slot 8: > slot 9: > slot 10: > slot 11: > slot 12: > slot 13: > portal 0: > drive 0: >From the specs, it looks like this changer is supposed to have up to 24 slots when used with LTO drives. How many slots does your unit have? How many slots are there on ch0? Are all slots available from both changer devices? > # camcontrol devlist -v > scbus0 on ahc0 bus 0: > at scbus0 target 2 lun 0 (pass0,cd0) > at scbus0 target 3 lun 0 (sa0,pass1) > at scbus0 target 3 lun 1 (pass2,ch0) > at scbus0 target 4 lun 0 (sa1,pass3) > at scbus0 target 5 lun 0 (sa2,pass4) > at scbus0 target 5 lun 1 (pass5,ch1) > at scbus0 target 6 lun 0 (pass6,cd1) > < > at scbus0 target -1 lun -1 () > scbus1 on ahc1 bus 0: > at scbus1 target 1 lun 0 (sa3,pass7) > at scbus1 target 1 lun 1 (pass8,ch2) > at scbus1 target 2 lun 0 (sa4,pass9) > at scbus1 target 3 lun 0 (sa5,pass10) > < > at scbus1 target -1 lun -1 () > scbus-1 on xpt0 bus 0: > < > at scbus-1 target -1 lun -1 (xpt0) > > The third changer device (ch2) is an IBM 3575L32 tape library which has > been in use for several months, never had any problems. > > The server is running FreeBSD 5.4-STABLE on i386. Ken -- Kenneth Merry ken@FreeBSD.org From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 17:50:47 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC73916A420 for ; Thu, 2 Feb 2006 17:50:47 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08FCE43D49 for ; Thu, 2 Feb 2006 17:50:46 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.13.4/8.12.11) with ESMTP id k12HogeM092343; Thu, 2 Feb 2006 10:50:42 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.13.4/8.12.5/Submit) id k12HofeC092342; Thu, 2 Feb 2006 10:50:41 -0700 (MST) (envelope-from ken) Date: Thu, 2 Feb 2006 10:50:41 -0700 From: "Kenneth D. Merry" To: Nate Lawson Message-ID: <20060202175041.GA92109@nargothrond.kdm.org> References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> <43E06B06.80405@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43E06B06.80405@root.org> User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.87.1/1270/Thu Feb 2 05:47:37 2006 on nargothrond.kdm.org X-Virus-Status: Clean Cc: freebsd-scsi@freebsd.org, Matthew Jacob , Florent Thoumie Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs 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: Thu, 02 Feb 2006 17:50:48 -0000 On Wed, Feb 01, 2006 at 00:02:14 -0800, Nate Lawson wrote: > Florent Thoumie wrote: > >On Tuesday 31 January 2006 06:33, Matthew Jacob wrote: > > > >>>>Linux only sends the SYNCHRONIZE_CACHE command if the WCE (Write Cache > >>>>Enable) bit of the disk is set. I can't seem to find something > >>>>equivalent to this in our CAM framework. I have no particular SCSI > >>>>knowledge but I guess I can have a look at this tomorrow. > >>>> > >>>>I'm forwarding this to freebsd-scsi@ (keep me CC'ed, as I'm not > >>>>subscribed to this list, yet). > >>> > >>>Hmm, is WCE part of the inquiry response? [moving to scsi@ list] > >> > >>Yes. > > > > > >Hum, reading Linux source and SCSI standard [1], I'm not so sure, but I > >might be wrong. We need to request the caching page in > >scsi_mode_sense_{6,10}. > > > >I'll try to write something today, but I guess someone having already > >worked on scsi will only need 10 minutes to DTRT. > > > >[1] http://www.danbbs.dk/~dino/SCSI/SCSI2-09.html (table 156) > > > > You might also want to check if we or Linux set the Immediate bit as > part of the SYNCHRONIZE CACHE command. It's possible that USB devices > don't properly parse that bit. > > I think the tape driver (sa) does MODE SENSE as part of normal operation > but da does not. (Working frm memory here). It seems like a reasonable idea to check the WCE bit before sending a sync cache command. In theory it shouldn't cause any more breakage than sync cache itself. The generic CAM probe code already sends a mode sense (for the control mode page) to detect whether the DQue bit is set. The way to implement it in the da(4) driver would be as another probe state in addition to the two read capacity states. One difference is that things shouldn't blow up if the mode sense fails. (In that case, we should probably disable sync cache.) One case this won't cover, though, is when the user changes the WCE bit after we probe. That's obviously not a very common case, but the only way to mostly cover it would be to do a mode sense just prior to every sync cache command. (We could set a bit, though, if that mode page isn't supported so that we don't constantly ask for a mode page that isn't supported.) We're also assuming that the device firmware is telling the truth about whether the write cache is enabled or disabled. (Hopefully so, but you never know.) Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 18:02:23 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F41BE16A420; Thu, 2 Feb 2006 18:02:22 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7641E43D46; Thu, 2 Feb 2006 18:02:22 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.4/8.13.4) with ESMTP id k12I2MPK097797; Thu, 2 Feb 2006 10:02:22 -0800 (PST) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.4/8.13.4/Submit) with ESMTP id k12I2MB8097794; Thu, 2 Feb 2006 10:02:22 -0800 (PST) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Thu, 2 Feb 2006 10:02:22 -0800 (PST) From: Matthew Jacob X-X-Sender: mjacob@ns1.feral.com To: "Kenneth D. Merry" In-Reply-To: <20060202175041.GA92109@nargothrond.kdm.org> Message-ID: <20060202095828.D97756@ns1.feral.com> References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> <43E06B06.80405@root.org> <20060202175041.GA92109@nargothrond.kdm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-scsi@freebsd.org, Florent Thoumie , Matthew Jacob , Nate Lawson Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthew Jacob List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 18:02:23 -0000 >> I think the tape driver (sa) does MODE SENSE as part of normal operation >> but da does not. (Working frm memory here). > > It seems like a reasonable idea to check the WCE bit before sending a sync > cache command. In theory it shouldn't cause any more breakage than sync > cache itself. The generic CAM probe code already sends a mode sense (for > the control mode page) to detect whether the DQue bit is set. > > The way to implement it in the da(4) driver would be as another probe state > in addition to the two read capacity states. One difference is that things > shouldn't blow up if the mode sense fails. (In that case, we should > probably disable sync cache.) > > One case this won't cover, though, is when the user changes the WCE bit > after we probe. That's obviously not a very common case, but the only way > to mostly cover it would be to do a mode sense just prior to every sync > cache command. (We could set a bit, though, if that mode page isn't > supported so that we don't constantly ask for a mode page that isn't > supported.) > > We're also assuming that the device firmware is telling the truth about > whether the write cache is enabled or disabled. (Hopefully so, but you > never know.) Changing the WCE bit is actually pretty common. I do it all the time myself. Furthermore, a common scenario is the Windows enables WCE and then uses FUA for synchronization. I've missed something here- other than broken devices that die spectacularly when the get one, why don't you just infer from a failed SYNCHRONIZE CACHE (e.g., "Illegal Request") that the device doesn't support it and stop doing it? For example, the EMC/Clariion AX100 reports Illegal Request on this command. You can't use quirks to identify this device because all Clariions have essentially the same Vendor/Product ID ("DGC", "RAID5"). From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 18:43:46 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D163616A420; Thu, 2 Feb 2006 18:43:46 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76FAC43D48; Thu, 2 Feb 2006 18:43:46 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (ppp-71-139-114-10.dsl.snfc21.pacbell.net [71.139.114.10]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k12IhhEr006516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Feb 2006 10:43:44 -0800 Message-ID: <43E252EC.1050803@root.org> Date: Thu, 02 Feb 2006 10:43:56 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Jacob References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> <43E06B06.80405@root.org> <20060202175041.GA92109@nargothrond.kdm.org> <20060202095828.D97756@ns1.feral.com> In-Reply-To: <20060202095828.D97756@ns1.feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, "Kenneth D. Merry" , Florent Thoumie Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs 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: Thu, 02 Feb 2006 18:43:46 -0000 Matthew Jacob wrote: >> One case this won't cover, though, is when the user changes the WCE bit >> after we probe. That's obviously not a very common case, but the only >> way >> to mostly cover it would be to do a mode sense just prior to every sync >> cache command. (We could set a bit, though, if that mode page isn't >> supported so that we don't constantly ask for a mode page that isn't >> supported.) >> >> We're also assuming that the device firmware is telling the truth about >> whether the write cache is enabled or disabled. (Hopefully so, but you >> never know.) > > Changing the WCE bit is actually pretty common. I do it all the time > myself. Furthermore, a common scenario is the Windows enables WCE and > then uses FUA for synchronization. > > I've missed something here- other than broken devices that die > spectacularly when the get one, why don't you just infer from a failed > SYNCHRONIZE CACHE (e.g., "Illegal Request") that the device doesn't > support it and stop doing it? > > For example, the EMC/Clariion AX100 reports Illegal Request on this > command. You can't use quirks to identify this device because all > Clariions have essentially the same Vendor/Product ID ("DGC", "RAID5"). There are 3 kinds of devices: * SYNC CACHE works * SYNC CACHE reports an error, but continues working * SYNC CACHE just hangs, no error * SYNC CACHE reports and error correctly, but then all subsequent commands time out We're talking about the 4th case and some versions with the 3rd case, if it was possible to detect them without hanging (i.e. mode sense works and WCE properly reported). The problem is that we have a significant SYNC CACHE quirk proliferation problem. A few years ago, we had a 6-byte command quirk proliferation problem, until I modified USB and Firewire SIMs to report "not 6-byte capable". I then was able to remove dozens of quirks and we seem to have solved that problem. I'm recommending we do the same thing with SYNC CACHE now. -- Nate From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 18:51:14 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB29016A420; Thu, 2 Feb 2006 18:51:14 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAF3943D4C; Thu, 2 Feb 2006 18:51:13 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.4/8.13.4) with ESMTP id k12IpDgB098533; Thu, 2 Feb 2006 10:51:13 -0800 (PST) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.4/8.13.4/Submit) with ESMTP id k12IpDXt098530; Thu, 2 Feb 2006 10:51:13 -0800 (PST) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Thu, 2 Feb 2006 10:51:13 -0800 (PST) From: Matthew Jacob X-X-Sender: mjacob@ns1.feral.com To: Nate Lawson In-Reply-To: <43E252EC.1050803@root.org> Message-ID: <20060202104606.W98511@ns1.feral.com> References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> <43E06B06.80405@root.org> <20060202175041.GA92109@nargothrond.kdm.org> <20060202095828.D97756@ns1.feral.com> <43E252EC.1050803@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Kenneth D. Merry" , freebsd-scsi@freebsd.org, Matthew Jacob , Florent Thoumie Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthew Jacob List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 18:51:14 -0000 > > There are 3 kinds of devices: > > * SYNC CACHE works > * SYNC CACHE reports an error, but continues working > * SYNC CACHE just hangs, no error > * SYNC CACHE reports and error correctly, but then all subsequent commands > time out > > We're talking about the 4th case and some versions with the 3rd case, if it > was possible to detect them without hanging (i.e. mode sense works and WCE > properly reported). The problem is that we have a significant SYNC CACHE > quirk proliferation problem. > > A few years ago, we had a 6-byte command quirk proliferation problem, until I > modified USB and Firewire SIMs to report "not 6-byte capable". I then was > able to remove dozens of quirks and we seem to have solved that problem. I'm > recommending we do the same thing with SYNC CACHE now. > Ah- I'm all for that as a reasonable solution as long as the default doesn't cause WCE off in a regular disk drive to be interpreted as "does not support". From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 19:24:08 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2947E16A420; Thu, 2 Feb 2006 19:24:08 +0000 (GMT) (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 02ED743D4C; Thu, 2 Feb 2006 19:24:02 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k12JNvMM042005; Thu, 2 Feb 2006 12:23:57 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43E25C4D.9020804@samsco.org> Date: Thu, 02 Feb 2006 12:23:57 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> <43E06B06.80405@root.org> <20060202175041.GA92109@nargothrond.kdm.org> <20060202095828.D97756@ns1.feral.com> <43E252EC.1050803@root.org> In-Reply-To: <43E252EC.1050803@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org, "Kenneth D. Merry" , Matthew Jacob , Florent Thoumie Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs 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: Thu, 02 Feb 2006 19:24:08 -0000 Nate Lawson wrote: > Matthew Jacob wrote: > >>> One case this won't cover, though, is when the user changes the WCE bit >>> after we probe. That's obviously not a very common case, but the >>> only way >>> to mostly cover it would be to do a mode sense just prior to every sync >>> cache command. (We could set a bit, though, if that mode page isn't >>> supported so that we don't constantly ask for a mode page that isn't >>> supported.) >>> >>> We're also assuming that the device firmware is telling the truth about >>> whether the write cache is enabled or disabled. (Hopefully so, but you >>> never know.) >> >> >> Changing the WCE bit is actually pretty common. I do it all the time >> myself. Furthermore, a common scenario is the Windows enables WCE and >> then uses FUA for synchronization. >> >> I've missed something here- other than broken devices that die >> spectacularly when the get one, why don't you just infer from a failed >> SYNCHRONIZE CACHE (e.g., "Illegal Request") that the device doesn't >> support it and stop doing it? >> >> For example, the EMC/Clariion AX100 reports Illegal Request on this >> command. You can't use quirks to identify this device because all >> Clariions have essentially the same Vendor/Product ID ("DGC", "RAID5"). > > > There are 3 kinds of devices: > > * SYNC CACHE works > * SYNC CACHE reports an error, but continues working > * SYNC CACHE just hangs, no error > * SYNC CACHE reports and error correctly, but then all subsequent > commands time out > > We're talking about the 4th case and some versions with the 3rd case, if > it was possible to detect them without hanging (i.e. mode sense works > and WCE properly reported). The problem is that we have a significant > SYNC CACHE quirk proliferation problem. > > A few years ago, we had a 6-byte command quirk proliferation problem, > until I modified USB and Firewire SIMs to report "not 6-byte capable". I > then was able to remove dozens of quirks and we seem to have solved that > problem. I'm recommending we do the same thing with SYNC CACHE now. > You're suggesting that the umass and firewire SIMs universally instruct CAM to not send a SYNC CACHE for all targets? Easy, but I think it's too big of a hammer. I'd like to see the da driver get modified to check the WCE state as has been suggested. Scott From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 20:01:12 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F20C16A420; Thu, 2 Feb 2006 20:01:12 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id E51C843D48; Thu, 2 Feb 2006 20:01:09 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (ppp-71-139-114-10.dsl.snfc21.pacbell.net [71.139.114.10]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k12K14Er007719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Feb 2006 12:01:07 -0800 Message-ID: <43E2650D.1060109@root.org> Date: Thu, 02 Feb 2006 12:01:17 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> <43E06B06.80405@root.org> <20060202175041.GA92109@nargothrond.kdm.org> <20060202095828.D97756@ns1.feral.com> <43E252EC.1050803@root.org> <43E25C4D.9020804@samsco.org> In-Reply-To: <43E25C4D.9020804@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, "Kenneth D. Merry" , Matthew Jacob , Florent Thoumie Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs 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: Thu, 02 Feb 2006 20:01:12 -0000 Scott Long wrote: > Nate Lawson wrote: > >> Matthew Jacob wrote: >> >>>> One case this won't cover, though, is when the user changes the WCE bit >>>> after we probe. That's obviously not a very common case, but the >>>> only way >>>> to mostly cover it would be to do a mode sense just prior to every sync >>>> cache command. (We could set a bit, though, if that mode page isn't >>>> supported so that we don't constantly ask for a mode page that isn't >>>> supported.) >>>> >>>> We're also assuming that the device firmware is telling the truth about >>>> whether the write cache is enabled or disabled. (Hopefully so, but you >>>> never know.) >>> >>> >>> >>> Changing the WCE bit is actually pretty common. I do it all the time >>> myself. Furthermore, a common scenario is the Windows enables WCE and >>> then uses FUA for synchronization. >>> >>> I've missed something here- other than broken devices that die >>> spectacularly when the get one, why don't you just infer from a >>> failed SYNCHRONIZE CACHE (e.g., "Illegal Request") that the device >>> doesn't support it and stop doing it? >>> >>> For example, the EMC/Clariion AX100 reports Illegal Request on this >>> command. You can't use quirks to identify this device because all >>> Clariions have essentially the same Vendor/Product ID ("DGC", "RAID5"). >> >> >> >> There are 3 kinds of devices: >> >> * SYNC CACHE works >> * SYNC CACHE reports an error, but continues working >> * SYNC CACHE just hangs, no error >> * SYNC CACHE reports and error correctly, but then all subsequent >> commands time out >> >> We're talking about the 4th case and some versions with the 3rd case, >> if it was possible to detect them without hanging (i.e. mode sense >> works and WCE properly reported). The problem is that we have a >> significant SYNC CACHE quirk proliferation problem. >> >> A few years ago, we had a 6-byte command quirk proliferation problem, >> until I modified USB and Firewire SIMs to report "not 6-byte capable". >> I then was able to remove dozens of quirks and we seem to have solved >> that problem. I'm recommending we do the same thing with SYNC CACHE now. >> > > You're suggesting that the umass and firewire SIMs universally instruct > CAM to not send a SYNC CACHE for all targets? Easy, but I think it's > too big of a hammer. I'd like to see the da driver get modified to > check the WCE state as has been suggested. I agree, I wasn't clear. I meant that we should use the mode sense approach instead of adding quirks all the time for something that's endemic to a particular architecture. But if that doesn't work, perhaps something specific to USB and Firewire may be appropriate. -- Nate From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 21:06:49 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB4D716A420; Thu, 2 Feb 2006 21:06:49 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 774DF43D46; Thu, 2 Feb 2006 21:06:49 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.4/8.13.4) with ESMTP id k12L6neK099190; Thu, 2 Feb 2006 13:06:49 -0800 (PST) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.4/8.13.4/Submit) with ESMTP id k12L6kh9099187; Thu, 2 Feb 2006 13:06:46 -0800 (PST) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Thu, 2 Feb 2006 13:06:46 -0800 (PST) From: Matthew Jacob X-X-Sender: mjacob@ns1.feral.com To: Nate Lawson In-Reply-To: <43E2650D.1060109@root.org> Message-ID: <20060202130620.A99168@ns1.feral.com> References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> <43E06B06.80405@root.org> <20060202175041.GA92109@nargothrond.kdm.org> <20060202095828.D97756@ns1.feral.com> <43E252EC.1050803@root.org> <43E25C4D.9020804@samsco.org> <43E2650D.1060109@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-scsi@freebsd.org, Matthew Jacob , "Kenneth D. Merry" , Florent Thoumie Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthew Jacob List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 21:06:50 -0000 >> >> You're suggesting that the umass and firewire SIMs universally instruct >> CAM to not send a SYNC CACHE for all targets? Easy, but I think it's >> too big of a hammer. I'd like to see the da driver get modified to >> check the WCE state as has been suggested. > > I agree, I wasn't clear. I meant that we should use the mode sense approach > instead of adding quirks all the time for something that's endemic to a > particular architecture. But if that doesn't work, perhaps something > specific to USB and Firewire may be appropriate. And how will you distinguish between "not currently enabled" and "not supported"? From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 21:10:42 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD2BB16A420; Thu, 2 Feb 2006 21:10:42 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from smtp.xbsd.org (xbsd.org [82.233.2.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id E50AF43D48; Thu, 2 Feb 2006 21:10:41 +0000 (GMT) (envelope-from flz@xbsd.org) Received: from localhost (localhost.xbsd.org [127.0.0.1]) by smtp.xbsd.org (Postfix) with ESMTP id D83BE11729; Thu, 2 Feb 2006 22:10:36 +0100 (CET) Received: from smtp.xbsd.org ([127.0.0.1]) by localhost (srv1.xbsd.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15850-08; Thu, 2 Feb 2006 22:10:19 +0100 (CET) Received: from cream.xbsd.org (cream.xbsd.org [192.168.42.6]) by smtp.xbsd.org (Postfix) with ESMTP id 10C4111438; Thu, 2 Feb 2006 22:10:17 +0100 (CET) From: Florent Thoumie To: Matthew Jacob Date: Thu, 2 Feb 2006 22:10:02 +0100 User-Agent: KMail/1.8.2 References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43E2650D.1060109@root.org> <20060202130620.A99168@ns1.feral.com> In-Reply-To: <20060202130620.A99168@ns1.feral.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1366658.a6l1fpj1ns"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200602022210.10198.flz@xbsd.org> X-Virus-Scanned: amavisd-new at xbsd.org Cc: freebsd-scsi@freebsd.org, "Kenneth D. Merry" , Nate Lawson Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs 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: Thu, 02 Feb 2006 21:10:42 -0000 --nextPart1366658.a6l1fpj1ns Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 02 February 2006 22:06, Matthew Jacob wrote: > >> You're suggesting that the umass and firewire SIMs universally instruct > >> CAM to not send a SYNC CACHE for all targets? Easy, but I think it's > >> too big of a hammer. I'd like to see the da driver get modified to > >> check the WCE state as has been suggested. > > > > I agree, I wasn't clear. I meant that we should use the mode sense > > approach instead of adding quirks all the time for something that's > > endemic to a particular architecture. But if that doesn't work, perhaps > > something specific to USB and Firewire may be appropriate. > > And how will you distinguish between "not currently enabled" and "not > supported"? What about a note saying "Don't set it to 1 unless you know what you're doi= ng=20 and willing to suffer the spanish inquisition" ? =2D-=20 =46lorent Thoumie flz@FreeBSD.org =46reeBSD Committer --nextPart1366658.a6l1fpj1ns Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBD4nUyMxEkbVFH3PQRAiQBAKCQR7vu47pWB4+7EcthZ3DbaEX3oACghiUa 2rg8rYdRUjNXeZsqWC8C6CY= =3UA6 -----END PGP SIGNATURE----- --nextPart1366658.a6l1fpj1ns-- From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 21:18:15 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B97B16A420; Thu, 2 Feb 2006 21:18:15 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94AF343D45; Thu, 2 Feb 2006 21:18:14 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.4/8.13.4) with ESMTP id k12LIEhu099256; Thu, 2 Feb 2006 13:18:14 -0800 (PST) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.4/8.13.4/Submit) with ESMTP id k12LIEmS099253; Thu, 2 Feb 2006 13:18:14 -0800 (PST) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Thu, 2 Feb 2006 13:18:14 -0800 (PST) From: Matthew Jacob X-X-Sender: mjacob@ns1.feral.com To: Florent Thoumie In-Reply-To: <200602022210.10198.flz@xbsd.org> Message-ID: <20060202131802.R99168@ns1.feral.com> References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43E2650D.1060109@root.org> <20060202130620.A99168@ns1.feral.com> <200602022210.10198.flz@xbsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-scsi@freebsd.org, Matthew Jacob , "Kenneth D. Merry" , Nate Lawson Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthew Jacob List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 21:18:15 -0000 > > What about a note saying "Don't set it to 1 unless you know what you're doing > and willing to suffer the spanish inquisition" ? > Tempting, but suboptimal. From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 21:49:09 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C9B316A420; Thu, 2 Feb 2006 21:49:09 +0000 (GMT) (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 2847E43D48; Thu, 2 Feb 2006 21:49:04 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k12Ln1Yk042770; Thu, 2 Feb 2006 14:49:02 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43E27E58.4020606@samsco.org> Date: Thu, 02 Feb 2006 14:49:12 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Jacob References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> <43E06B06.80405@root.org> <20060202175041.GA92109@nargothrond.kdm.org> <20060202095828.D97756@ns1.feral.com> <43E252EC.1050803@root.org> <43E25C4D.9020804@samsco.org> <43E2650D.1060109@root.org> <20060202130620.A99168@ns1.feral.com> In-Reply-To: <20060202130620.A99168@ns1.feral.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org, Florent Thoumie , "Kenneth D. Merry" , Nate Lawson Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs 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: Thu, 02 Feb 2006 21:49:09 -0000 Matthew Jacob wrote: >>> >>> You're suggesting that the umass and firewire SIMs universally instruct >>> CAM to not send a SYNC CACHE for all targets? Easy, but I think it's >>> too big of a hammer. I'd like to see the da driver get modified to >>> check the WCE state as has been suggested. >> >> >> I agree, I wasn't clear. I meant that we should use the mode sense >> approach instead of adding quirks all the time for something that's >> endemic to a particular architecture. But if that doesn't work, >> perhaps something specific to USB and Firewire may be appropriate. > > > And how will you distinguish between "not currently enabled" and "not > supported"? > If WCE is not supported, will the device lie and report the WCE bit as set? Scott From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 21:51:50 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C327316A423; Thu, 2 Feb 2006 21:51:50 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1C1543D49; Thu, 2 Feb 2006 21:51:49 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.4/8.13.4) with ESMTP id k12LpnE5099427; Thu, 2 Feb 2006 13:51:49 -0800 (PST) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.4/8.13.4/Submit) with ESMTP id k12LpnEC099424; Thu, 2 Feb 2006 13:51:49 -0800 (PST) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Thu, 2 Feb 2006 13:51:49 -0800 (PST) From: Matthew Jacob X-X-Sender: mjacob@ns1.feral.com To: Scott Long In-Reply-To: <43E27E58.4020606@samsco.org> Message-ID: <20060202135123.K99168@ns1.feral.com> References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> <43E06B06.80405@root.org> <20060202175041.GA92109@nargothrond.kdm.org> <20060202095828.D97756@ns1.feral.com> <43E252EC.1050803@root.org> <43E25C4D.9020804@samsco.org> <43E2650D.1060109@root.org> <20060202130620.A99168@ns1.feral.com> <43E27E58.4020606@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-scsi@freebsd.org, "Kenneth D. Merry" , Florent Thoumie , Matthew Jacob , Nate Lawson Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthew Jacob List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 21:51:51 -0000 >> >> >> And how will you distinguish between "not currently enabled" and "not >> supported"? >> > > If WCE is not supported, will the device lie and report the WCE bit as > set? > No. But a device could have it turned off and you wouldn't then infer that you *could*. From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 22:06:35 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B97A16A420; Thu, 2 Feb 2006 22:06:35 +0000 (GMT) (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 A7A0F43D45; Thu, 2 Feb 2006 22:06:34 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k12M6VHN042931; Thu, 2 Feb 2006 15:06:32 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43E28272.30704@samsco.org> Date: Thu, 02 Feb 2006 15:06:42 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Jacob References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> <43E06B06.80405@root.org> <20060202175041.GA92109@nargothrond.kdm.org> <20060202095828.D97756@ns1.feral.com> <43E252EC.1050803@root.org> <43E25C4D.9020804@samsco.org> <43E2650D.1060109@root.org> <20060202130620.A99168@ns1.feral.com> <43E27E58.4020606@samsco.org> <20060202135123.K99168@ns1.feral.com> In-Reply-To: <20060202135123.K99168@ns1.feral.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org, Florent Thoumie , "Kenneth D. Merry" , Nate Lawson Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs 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: Thu, 02 Feb 2006 22:06:35 -0000 Matthew Jacob wrote: >>> >>> >>> And how will you distinguish between "not currently enabled" and "not >>> supported"? >>> >> >> If WCE is not supported, will the device lie and report the WCE bit as >> set? >> > > No. But a device could have it turned off and you wouldn't then infer > that you *could*. I guess I don't follow. There was a suggestion to read page 8 during the da device probe, cache the WCE value, and act on it accordingly later on. There was also a suggestion to read the page on demand as part of the immediate decision to do the SYNC CACHE. As much of a hassle as it could be, the latter is likely the better approach as it eliminates the messy state tracking that you'd have to do on the user. Who wants to hack up the pass driver to trap mode page writes and then try to correlate which da device to pass that info on to? And yeah, if the device is able to change the state on its own, there is no way the first approach can work. Scott From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 2 22:13:07 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6FAB16A420; Thu, 2 Feb 2006 22:13:07 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D54043D48; Thu, 2 Feb 2006 22:13:05 +0000 (GMT) (envelope-from mj@feral.com) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.4/8.13.4) with ESMTP id k12MD4DG099572; Thu, 2 Feb 2006 14:13:04 -0800 (PST) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.4/8.13.4/Submit) with ESMTP id k12MD20Z099569; Thu, 2 Feb 2006 14:13:04 -0800 (PST) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Thu, 2 Feb 2006 14:13:02 -0800 (PST) From: Matthew Jacob X-X-Sender: mjacob@ns1.feral.com To: Scott Long In-Reply-To: <43E28272.30704@samsco.org> Message-ID: <20060202140733.J99168@ns1.feral.com> References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> <43E06B06.80405@root.org> <20060202175041.GA92109@nargothrond.kdm.org> <20060202095828.D97756@ns1.feral.com> <43E252EC.1050803@root.org> <43E25C4D.9020804@samsco.org> <43E2650D.1060109@root.org> <20060202130620.A99168@ns1.feral.com> <43E27E58.4020606@samsco.org> <20060202135123.K99168@ns1.feral.com> <43E28272.30704@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-scsi@freebsd.org, "Kenneth D. Merry" , Florent Thoumie , Matthew Jacob , Nate Lawson Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthew Jacob List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 22:13:07 -0000 >> >> No. But a device could have it turned off and you wouldn't then infer that >> you *could*. > > I guess I don't follow. There was a suggestion to read page 8 during > the da device probe, cache the WCE value, and act on it accordingly > later on. There was also a suggestion to read the page on demand as > part of the immediate decision to do the SYNC CACHE. As much of a > hassle as it could be, the latter is likely the better approach as it > eliminates the messy state tracking that you'd have to do on the user. > Who wants to hack up the pass driver to trap mode page writes and then > try to correlate which da device to pass that info on to? And yeah, > if the device is able to change the state on its own, there is no way > the first approach can work. > Okay- I was a bit fatigued (up until 2AM last night worrying over core emails) The WCE bit from page 8 is either the current state, the persistent state, or whether you can change that bit (the PCF fields). All you can infer from this bit is whether WCE is currently enabled, or whether the default is for it to be enabled or not. You cannot infer whether the device correctly supports it or not. You could infer from the CHANGEABLE version as to whether you can change the state. I guess what is being suggested by inference here is that if the WCE bit is off at attach time, we don't issue a SYNC CACHE. If you want your drive to be cacheable, you run camcontrol on it (saving the page) and reboot. I suppose this isn't so bad, because you could then also begin to think about using FUA as well. -matt From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 3 02:20:11 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45DF016A420; Fri, 3 Feb 2006 02:20:11 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C98C43D4C; Fri, 3 Feb 2006 02:20:10 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.53] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id k132K4Er013529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Feb 2006 18:20:04 -0800 Message-ID: <43E2BDE0.1070709@root.org> Date: Thu, 02 Feb 2006 18:20:16 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> <43E06B06.80405@root.org> <20060202175041.GA92109@nargothrond.kdm.org> <20060202095828.D97756@ns1.feral.com> <43E252EC.1050803@root.org> <43E25C4D.9020804@samsco.org> <43E2650D.1060109@root.org> <20060202130620.A99168@ns1.feral.com> <43E27E58.4020606@samsco.org> <20060202135123.K99168@ns1.feral.com> <43E28272.30704@samsco.org> In-Reply-To: <43E28272.30704@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, "Kenneth D. Merry" , Matthew Jacob , Florent Thoumie Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs 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: Fri, 03 Feb 2006 02:20:11 -0000 Scott Long wrote: > Matthew Jacob wrote: >>>> >>>> And how will you distinguish between "not currently enabled" and >>>> "not supported"? >>>> >>> >>> If WCE is not supported, will the device lie and report the WCE bit as >>> set? >>> >> >> No. But a device could have it turned off and you wouldn't then infer >> that you *could*. > > > I guess I don't follow. There was a suggestion to read page 8 during > the da device probe, cache the WCE value, and act on it accordingly > later on. There was also a suggestion to read the page on demand as > part of the immediate decision to do the SYNC CACHE. As much of a > hassle as it could be, the latter is likely the better approach as it > eliminates the messy state tracking that you'd have to do on the user. > Who wants to hack up the pass driver to trap mode page writes and then > try to correlate which da device to pass that info on to? And yeah, > if the device is able to change the state on its own, there is no > way the first approach can work. I agree -- we should just do the MODE SENSE inline with the SYNC CACHE each time for starters. If it causes problems, then re-evaluate this approach. Can someone with a bad USB device run the appropriate camcontrol command to see if WCE is set or not? It would help to know if they lie because if so, this approach is not likely to succeed. -- Nate From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 3 11:27:02 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5189E16A423; Fri, 3 Feb 2006 11:27:02 +0000 (GMT) (envelope-from age.robekk@ventelo.no) Received: from kirov.kq.no (kirov.kq.no [195.139.204.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBBAA43D48; Fri, 3 Feb 2006 11:27:01 +0000 (GMT) (envelope-from age.robekk@ventelo.no) Received: from aage.i.eunet.no (aage.i.eunet.no [193.71.2.25]) by kirov.kq.no (Postfix) with ESMTP id A513728D8E; Fri, 3 Feb 2006 12:27:00 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by aage.i.eunet.no (Postfix) with ESMTP id 968CE510B6; Fri, 3 Feb 2006 12:27:00 +0100 (CET) Message-ID: <43E33E04.1080007@ventelo.no> Date: Fri, 03 Feb 2006 12:27:00 +0100 From: =?ISO-8859-1?Q?=C5ge_R=F8bekk?= User-Agent: Thunderbird 1.5 (X11/20060117) MIME-Version: 1.0 To: "Kenneth D. Merry" References: <43E2189B.1090207@ventelo.no> <20060202162133.GA90898@nargothrond.kdm.org> In-Reply-To: <20060202162133.GA90898@nargothrond.kdm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-scsi@freebsd.org Subject: Re: Problems with Dell PV132T tape changer 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: Fri, 03 Feb 2006 11:27:02 -0000 Kenneth D. Merry wrote: > On Thu, Feb 02, 2006 at 15:35:07 +0100, ?ge R?bekk wrote: >> This changer has two separate changer devices, /dev/ch0 and /dev/ch1. >> When moving a tape from e.g. slot 0 to drive 0 on /dev/ch0, everything >> works as it is supposed to. However, trying the same operation on >> /dev/ch1 fails as follows: >> >> # chio -f /dev/ch0 move slot 0 drive 0 >> chio: /dev/ch0: CHIOMOVE: Input/output error > > This doesn't quite make sense. You're trying the above command on ch0, but > you said the problem is with ch1...and it looks like the command failed on > ch0 as well. Oops, a slight mixup. /dev/ch1 is the erroneous device, /dev/ch0 apparently has no problems. The cutted & pasted error above was due to moving from a slot to an already occupied drive on the wrong device. >> dmesg: >> >> [...] >> (ch1:ahc0:0:5:1): MOVE MEDIUM. CDB: a5 20 0 1 20 6 2 0 0 0 0 0 >> (ch1:ahc0:0:5:1): CAM Status: SCSI Status Error >> (ch1:ahc0:0:5:1): SCSI Status: Check Condition >> (ch1:ahc0:0:5:1): ILLEGAL REQUEST asc:3b,a0 >> (ch1:ahc0:0:5:1): Vendor Specific ASCQ >> (ch1:ahc0:0:5:1): Unretryable error > > In this case, ch1 didn't like the move medium for some reason, but they've > given us a vendor specific error. The other errors in that general > vicinity in the spec deal with not being able to do movements requested > from a changer. Is there any easy way to obtain the documentation that states what these ASCQ codes are? This might be as easy as a stuck picker or perhaps faulty firmware. >> # chio -f /dev/ch1 status >> picker 0: >> slot 0: >> slot 1: >> slot 2: >> slot 3: >> slot 4: >> slot 5: >> slot 6: >> slot 7: >> slot 8: >> slot 9: >> slot 10: >> slot 11: >> slot 12: >> slot 13: >> portal 0: >> drive 0: > > From the specs, it looks like this changer is supposed to have up to 24 slots > when used with LTO drives. How many slots does your unit have? How many > slots are there on ch0? ch0 has 8 slots: # chio -f /dev/ch0 status picker 0: slot 0: slot 1: slot 2: slot 3: slot 4: slot 5: slot 6: slot 7: portal 0: drive 0: > Are all slots available from both changer devices? No, for some reason they chose to separate the device into two different pickers and drives. 8 of the cartridges are in the back of the unit (ch0), the rest is mounted in front (ch1). > Ken -- Åge Røbekk, Ventelo Comnet AS From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 3 15:53:12 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C61816A420 for ; Fri, 3 Feb 2006 15:53:12 +0000 (GMT) (envelope-from tom@dyndns.com) Received: from manganese.bos.dyndns.org (manganese.bos.dyndns.org [63.208.196.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 553F743D5D for ; Fri, 3 Feb 2006 15:53:11 +0000 (GMT) (envelope-from tom@dyndns.com) Received: from manganese.bos.dyndns.org (localhost [127.0.0.1]) by manganese.bos.dyndns.org (8.12.9p2/8.12.9) with ESMTP id k13Fr97N068025 for ; Fri, 3 Feb 2006 10:53:09 -0500 (EST) (envelope-from tom@dyndns.com) Received: from localhost (tom@localhost) by manganese.bos.dyndns.org (8.12.9p2/8.12.9/Submit) with ESMTP id k13Fr93M068019 for ; Fri, 3 Feb 2006 10:53:09 -0500 (EST) (envelope-from tom@dyndns.com) X-Authentication-Warning: manganese.bos.dyndns.org: tom owned process doing -bs Date: Fri, 3 Feb 2006 10:53:09 -0500 (EST) From: Tom Daly X-X-Sender: tom@manganese.bos.dyndns.org To: freebsd-scsi@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: -2.405 () ALL_TRUSTED,BAYES_20 X-Scanned-By: MIMEDefang 2.54 on 63.208.196.3 Subject: Suggested RAID cards for FreeBSD 5-RELEASE and 6-RELEASE 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: Fri, 03 Feb 2006 15:53:12 -0000 Hi, This seems to be an often posted topic on this list, however, its seems everyone's milage tends to vary. My inquiry: We are trying to validate a hardware platform for our server farms. Our goal is to locate a server/RAID controller pair that satisfy's the following requirements: Provides RAID levels 0, 1, and 10. Provides for management via BIOS over Serial Console Redirect Provides for management via OS CLI or GUI (but no X-Windows, should be able to run through a standard shell) Provides logging ability for events to syslog, e-mail, or logfile Our last successful deployment was using the Intel SE7501WV2 Motherboard, with the Intel SRCZCR RAID controller. However, Intel has discontinued both of these projects. In our testing, we've tried the following, and come up with these results: Dell PowerEdge 2850 with Dell PERC4e/Di: Provides required RAID levels Management via BIOS over serial mostly works Management via OS (MegaRC) seems broken Logging (MegaMon) works Both of the programs MegaRC and MegaMon http://people.freebsd.org/~emoore/MegaRAID_SCSI/ Dell PowerEdge 2850 with Adaptec 2130SLP Provides required RAID levels Management via BIOS over serial works Management via aaccli works Logging could be accomplished with aaccli and script files, but I see nothing to directly accomplish this. Intel SR7520JR2 with Intel SRCS16 (SATA) Provides required RAID levels Management via BIOS over serial is not possible No OS Tools found for logging or management Any of the Intel software stack 2 cards would appear to have this problem. We're considering a trial of the 3ware cards. Thier software support appears to be pretty good, however, I'm concerned about this recent post to this list: http://lists.freebsd.org/pipermail/freebsd-scsi/2006-January/002203.html The Dell 2850 seems to have a slew of other problems, namely with memory and such, but it still seems like a viable candidate. Does anyone have any stellar FreeBSD + Hardware RAID success stories, somewhat akin to my Intel WV2 + SRCZCR experience? In the Fourth Quarter 2005 FreeBSD Status Report, a section titled "LSI MegaRAID improvements" was included. Does anyone know if this includes the rebranded OEM/Dell controllers? Furthermore, has anyone gotten the LSI-provided management apps to run, as stated in the article? Are they native apps, or must they be run under linux compat mode? Thanks for your input, Tom Daly -- Thomas J. Daly tom@dyndns.com Dynamic Network Services, Inc. http://www.dyndns.com/ From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 3 17:11:42 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C04716A420 for ; Fri, 3 Feb 2006 17:11:42 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AEF543D53 for ; Fri, 3 Feb 2006 17:11:40 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.13.4/8.12.11) with ESMTP id k13HBeg2001934; Fri, 3 Feb 2006 10:11:40 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.13.4/8.12.5/Submit) id k13HBdlQ001933; Fri, 3 Feb 2006 10:11:39 -0700 (MST) (envelope-from ken) Date: Fri, 3 Feb 2006 10:11:39 -0700 From: "Kenneth D. Merry" To: ?ge R?bekk Message-ID: <20060203171139.GA1616@nargothrond.kdm.org> References: <43E2189B.1090207@ventelo.no> <20060202162133.GA90898@nargothrond.kdm.org> <43E33E04.1080007@ventelo.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43E33E04.1080007@ventelo.no> User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.87.1/1274/Fri Feb 3 07:43:35 2006 on nargothrond.kdm.org X-Virus-Status: Clean Cc: freebsd-scsi@freebsd.org Subject: Re: Problems with Dell PV132T tape changer 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: Fri, 03 Feb 2006 17:11:42 -0000 On Fri, Feb 03, 2006 at 12:27:00 +0100, ?ge R?bekk wrote: > Kenneth D. Merry wrote: > >On Thu, Feb 02, 2006 at 15:35:07 +0100, ?ge R?bekk wrote: > >>This changer has two separate changer devices, /dev/ch0 and /dev/ch1. > >>When moving a tape from e.g. slot 0 to drive 0 on /dev/ch0, everything > >>works as it is supposed to. However, trying the same operation on > >>/dev/ch1 fails as follows: > >> > >># chio -f /dev/ch0 move slot 0 drive 0 > >>chio: /dev/ch0: CHIOMOVE: Input/output error > > > >This doesn't quite make sense. You're trying the above command on ch0, but > >you said the problem is with ch1...and it looks like the command failed on > >ch0 as well. > > Oops, a slight mixup. /dev/ch1 is the erroneous device, /dev/ch0 > apparently has no problems. The cutted & pasted error above was due to > moving from a slot to an already occupied drive on the wrong device. Ahh. > >>dmesg: > >> > >>[...] > >>(ch1:ahc0:0:5:1): MOVE MEDIUM. CDB: a5 20 0 1 20 6 2 0 0 0 0 0 > >>(ch1:ahc0:0:5:1): CAM Status: SCSI Status Error > >>(ch1:ahc0:0:5:1): SCSI Status: Check Condition > >>(ch1:ahc0:0:5:1): ILLEGAL REQUEST asc:3b,a0 > >>(ch1:ahc0:0:5:1): Vendor Specific ASCQ > >>(ch1:ahc0:0:5:1): Unretryable error > > > >In this case, ch1 didn't like the move medium for some reason, but they've > >given us a vendor specific error. The other errors in that general > >vicinity in the spec deal with not being able to do movements requested > >from a changer. > > Is there any easy way to obtain the documentation that states what these > ASCQ codes are? This might be as easy as a stuck picker or perhaps > faulty firmware. Well, you'll have to either get the documentation from Dell or whoever they OEMed the changer from. Another thing you might try is 'chio ielem'. Some changers need that to know what their inventory is. Some changers scan their inventory on boot, but may go back and look at it again in response to an initialize element status command. (i.e. 'chio ielem') Anyway, you may be able to get the picker to move around a bit that way. Another thing to try would be to try the same move via the front panel on the changer, if you have one. Some changers have a front panel that lets you move tapes around. > >># chio -f /dev/ch1 status > >>picker 0: > >>slot 0: > >>slot 1: > >>slot 2: > >>slot 3: > >>slot 4: > >>slot 5: > >>slot 6: > >>slot 7: > >>slot 8: > >>slot 9: > >>slot 10: > >>slot 11: > >>slot 12: > >>slot 13: > >>portal 0: > >>drive 0: > > > >From the specs, it looks like this changer is supposed to have up to 24 > >slots > >when used with LTO drives. How many slots does your unit have? How many > >slots are there on ch0? > > ch0 has 8 slots: > > # chio -f /dev/ch0 status > picker 0: > slot 0: > slot 1: > slot 2: > slot 3: > slot 4: > slot 5: > slot 6: > slot 7: > portal 0: > drive 0: > > > >Are all slots available from both changer devices? > > No, for some reason they chose to separate the device into two different > pickers and drives. 8 of the cartridges are in the back of the unit > (ch0), the rest is mounted in front (ch1). Interesting. I take it you can move tapes back and forth between the two parts via the portals? Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 3 22:36:43 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB70916A420 for ; Fri, 3 Feb 2006 22:36:42 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AC5643D53 for ; Fri, 3 Feb 2006 22:36:41 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 03 Feb 2006 14:36:41 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id k13MafDT065886; Fri, 3 Feb 2006 14:36:41 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id k13Maf1r065885; Fri, 3 Feb 2006 14:36:41 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200602032236.k13Maf1r065885@ambrisko.com> In-Reply-To: To: Tom Daly Date: Fri, 3 Feb 2006 14:36:41 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-scsi@freebsd.org Subject: Re: Suggested RAID cards for FreeBSD 5-RELEASE and 6-RELEASE 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: Fri, 03 Feb 2006 22:36:43 -0000 Tom Daly writes: | This seems to be an often posted topic on this list, however, its seems | everyone's milage tends to vary. My inquiry: | | We are trying to validate a hardware platform for our server farms. Our | goal is to locate a server/RAID controller pair that satisfy's the | following requirements: | | Provides RAID levels 0, 1, and 10. | Provides for management via BIOS over Serial Console Redirect | Provides for management via OS CLI or GUI (but no X-Windows, should be | able to run through a standard shell) | Provides logging ability for events to syslog, e-mail, or logfile | | Our last successful deployment was using the Intel SE7501WV2 Motherboard, | with the Intel SRCZCR RAID controller. However, Intel has discontinued | both of these projects. | | In our testing, we've tried the following, and come up with these results: | | Dell PowerEdge 2850 with Dell PERC4e/Di: | Provides required RAID levels | Management via BIOS over serial mostly works | Management via OS (MegaRC) seems broken MegaRC from LSI for FreeBSD seems to work okay. | Logging (MegaMon) works I doubt this if it comes from emoore's stuff. It will blow up other programs on the system. | | Both of the programs MegaRC and MegaMon | http://people.freebsd.org/~emoore/MegaRAID_SCSI/ I'd be carefull since they are really old and have some bugs in them. | Dell PowerEdge 2850 with Adaptec 2130SLP | Provides required RAID levels | Management via BIOS over serial works | Management via aaccli works | Logging could be accomplished with aaccli and script files, but I | see nothing to directly accomplish this. Logging mostly happens via the driver direct and doesn't require an app. like LSI. You might have to start using the Linux version to get updates. | http://lists.freebsd.org/pipermail/freebsd-scsi/2006-January/002203.html | | The Dell 2850 seems to have a slew of other problems, namely with memory | and such, but it still seems like a viable candidate. Does anyone have any | stellar FreeBSD + Hardware RAID success stories, somewhat akin to my Intel | WV2 + SRCZCR experience? There are BIOS/RAID firmware issues with systems >4G. The latest stuff helps. I'd stay away from MegaMon under FreeBSD. The Linux version was slightly better. | In the Fourth Quarter 2005 FreeBSD Status Report, a section titled "LSI | MegaRAID improvements" was included. Does anyone know if this includes the | rebranded OEM/Dell controllers? Furthermore, has anyone gotten the | LSI-provided management apps to run, as stated in the article? Are they | native apps, or must they be run under linux compat mode? The Linux IOCTL emulation requires Linux app's to be run in Linux compat mode. It was infact developed and tested on Dell PE2850s so yes I have got it to run on it since I did the initial work! To make the Linux versus of MegaMon reliable I had to hack FreeBSD's shared memory to re-use the same memory for Linux app's. Otherwise it quickly leaked and ran out of memory. It leaks on Linux but takes longer to run out of memory. Hopefully LSI releases a fixed version if they haven't already. Doug A. From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 4 23:19:30 2006 Return-Path: X-Original-To: freebsd-scsi@hub.freebsd.org Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D474E16A420; Sat, 4 Feb 2006 23:19:30 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E15243D45; Sat, 4 Feb 2006 23:19:30 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k14NJUL0056298; Sat, 4 Feb 2006 23:19:30 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k14NJUtx056294; Sat, 4 Feb 2006 23:19:30 GMT (envelope-from linimon) Date: Sat, 4 Feb 2006 23:19:30 GMT From: Mark Linimon Message-Id: <200602042319.k14NJUtx056294@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-scsi@FreeBSD.org Cc: Subject: Re: kern/92798: [ahc] SCSI problem with timeouts 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: Sat, 04 Feb 2006 23:19:31 -0000 Old Synopsis: SCSI problem New Synopsis: [ahc] SCSI problem with timeouts Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi Responsible-Changed-By: linimon Responsible-Changed-When: Sat Feb 4 23:18:28 UTC 2006 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=92798