From owner-freebsd-scsi@FreeBSD.ORG Mon Jan 29 11:08:46 2007 Return-Path: X-Original-To: freebsd-scsi@FreeBSD.org Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4A6516A614 for ; Mon, 29 Jan 2007 11:08:46 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id C1B9313C441 for ; Mon, 29 Jan 2007 11:08:46 +0000 (UTC) (envelope-from owner-bugmaster@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 l0TB8kth042186 for ; Mon, 29 Jan 2007 11:08:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l0TB8jNQ042182 for freebsd-scsi@FreeBSD.org; Mon, 29 Jan 2007 11:08:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Jan 2007 11:08:45 GMT Message-Id: <200701291108.l0TB8jNQ042182@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon 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, 29 Jan 2007 11:08:46 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27059 scsi [sym] SCSI subsystem hangs under heavy load on (Server o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/40895 scsi wierd kernel / device driver bug o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/60598 scsi wire down of scsi devices conflicts with config o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 o kern/81887 scsi [aac] Adaptec SCSI 2130S aac0: GetDeviceProbeInfo comm o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/93128 scsi [sym] FreeBSD 6.1 BETA 1 has problems with Symbios/LSI o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/99954 scsi [ahc] reading from DVD failes on 6.x (regression) 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/23314 scsi aic driver fails to detect Adaptec 1520B unless PnP is o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce o kern/38828 scsi [feature request] DPT PM2012B/90 doesn't work o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/96133 scsi [scsi] [patch] add scsi quirk for joyfly 128mb flash u o kern/103702 scsi [cam] [patch] ChipsBnk: Unsupported USB memory stick 7 problems total. From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 30 12:08:44 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BE5416A492 for ; Tue, 30 Jan 2007 12:08:44 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail.classis.ru (classis.ru [213.248.60.120]) by mx1.freebsd.org (Postfix) with ESMTP id A100213C491 for ; Tue, 30 Jan 2007 12:08:41 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from citrin (unknown [81.19.65.95]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin.citrin.ru) by mail.classis.ru (Postfix) with ESMTP id 8450912279BA for ; Tue, 30 Jan 2007 14:57:27 +0300 (MSK) Date: Tue, 30 Jan 2007 14:56:49 +0300 From: Anton Yuzhaninov X-Mailer: The Bat! (v3.62.14) Professional Organization: Rambler X-Priority: 3 (Normal) Message-ID: <1579877114.20070130145649@citrin.ru> To: freebsd-scsi@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----------1171831462C568BFD" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem with AIC-7902B Ultra320 SCSI Controller 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, 30 Jan 2007 12:08:44 -0000 This is a cryptographically signed message in MIME format. ------------1171831462C568BFD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hello, freebsd-scsi. At boot time kernel write to logs: Jan 30 10:35:15 cf2 kernel: Waiting 5 seconds for SCSI devices to settle Jan 30 10:35:15 cf2 kernel: ahd1: SCSI Cell parity error SSTAT3 =3D=3D 0x2 Jan 30 10:35:15 cf2 kernel: ahd1: Missing case in ahd_handle_scsiint. statu= s =3D 0 Jan 30 10:35:15 cf2 kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<= <<<<<<<<<<<< Jan 30 10:35:15 cf2 kernel: ahd1: Dumping Card State at program address 0x3= 2 Mode 0x33 Jan 30 10:35:15 cf2 kernel: Card was paused ... [skipped] ... Jan 30 10:35:15 cf2 kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>= >>>>>>>>>> Jan 30 10:35:15 cf2 kernel: ahd0: SCSI Cell parity error SSTAT3 =3D=3D 0x2 Jan 30 10:35:15 cf2 kernel: ahd0: Missing case in ahd_handle_scsiint. statu= s =3D 0 Jan 30 10:35:15 cf2 kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<= <<<<<<<<<<<< Jan 30 10:35:15 cf2 kernel: ahd0: Dumping Card State at program address 0x2= Mode 0x33 Jan 30 10:35:15 cf2 kernel: Card was paused ... [skipped] ... Jan 30 10:35:15 cf2 kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>= >>>>>>>>>> Jan 30 10:35:15 cf2 kernel: ses0 at ahd0 bus 0 target 6 lun 0 Jan 30 10:35:15 cf2 kernel: ses0: Fixed Processor SCSI-2 d= evice Jan 30 10:35:15 cf2 kernel: ses0: 3.300MB/s transfers Jan 30 10:35:15 cf2 kernel: ses0: SAF-TE Compliant Device Jan 30 10:35:15 cf2 kernel: da0 at ahd0 bus 0 target 0 lun 0 Jan 30 10:35:15 cf2 kernel: da0: Fixed Direct Acce= ss SCSI-3 device Jan 30 10:35:15 cf2 kernel: da0: 320.000MB/s transfers (160.000MHz, offset = 127, 16bit), Tagged Queueing Enabled Jan 30 10:35:15 cf2 kernel: da0: 70136MB (143638992 512 byte sectors: 255H = 63S/T 8941C) Jan 30 10:35:15 cf2 kernel: da1 at ahd0 bus 0 target 2 lun 0 Jan 30 10:35:15 cf2 kernel: da1: Fixed Direct Acce= ss SCSI-3 device Jan 30 10:35:15 cf2 kernel: da1: 320.000MB/s transfers (160.000MHz, offset = 127, 16bit), Tagged Queueing Enabled Jan 30 10:35:15 cf2 kernel: da1: 70136MB (143638992 512 byte sectors: 255H = 63S/T 8941C) ahd0@pci2:3:0: class=3D0x010000 card=3D0x081115d9 chip=3D0x801d9005 rev=3D= 0x10 hdr=3D0x00 vendor =3D 'Adaptec Inc' device =3D 'AIC-7902B Ultra320 SCSI Controller' class =3D mass storage subclass =3D SCSI 6.2-RELEASE i386 Full log at http://pastebin.com/871132 Is there any problem with controller or driver? --=20 WBR, Anton Yuzhaninov ------------1171831462C568BFD-- From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 1 23:33:20 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBD8B16A400 for ; Thu, 1 Feb 2007 23:33:20 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id A983413C47E for ; Thu, 1 Feb 2007 23:33:16 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.8/8.13.8) with ESMTP id l11N1jEH077615; Thu, 1 Feb 2007 15:01:53 -0800 (PST) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.8/8.13.8/Submit) with ESMTP id l11N1gpB077612; Thu, 1 Feb 2007 15:01:44 -0800 (PST) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Thu, 1 Feb 2007 15:01:42 -0800 (PST) From: mjacob@freebsd.org To: Scott Long In-Reply-To: <45B67401.9070102@samsco.org> Message-ID: <20070201150111.B77236@ns1.feral.com> References: <20070123173026.E692416A4CD@hub.freebsd.org> <45B65710.4060607@root.org> <20070123105009.G41619@ns1.feral.com> <45B67401.9070102@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Nate Lawson , scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2007 23:33:21 -0000 > > umass should probably just disable the SYNC_CACHE commands from CAM, > as well as whatever other commands are always quirked. The firewire SIM > should probably do the same. > Err, probably should be XPORT based? From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 2 00:14:53 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67BAA16A401 for ; Fri, 2 Feb 2007 00:14:53 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB1C13C481 for ; Fri, 2 Feb 2007 00:14:52 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id l11NaJCT096807; Thu, 1 Feb 2007 16:36:24 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45C27965.1010803@samsco.org> Date: Thu, 01 Feb 2007 16:36:05 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: mjacob@freebsd.org References: <20070123173026.E692416A4CD@hub.freebsd.org> <45B65710.4060607@root.org> <20070123105009.G41619@ns1.feral.com> <45B67401.9070102@samsco.org> <20070201150111.B77236@ns1.feral.com> In-Reply-To: <20070201150111.B77236@ns1.feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Thu, 01 Feb 2007 16:36:24 -0700 (MST) X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Nate Lawson , scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c 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, 02 Feb 2007 00:14:53 -0000 mjacob@freebsd.org wrote: >> >> umass should probably just disable the SYNC_CACHE commands from CAM, >> as well as whatever other commands are always quirked. The firewire SIM >> should probably do the same. >> > > Err, probably should be XPORT based? Ah, very true. Taking that a step further, there should probably be a broader concept of RBC and/or MMC as opposed to the assumption that everything is SBC. Scott From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 2 07:54:14 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C4BB16A410 for ; Fri, 2 Feb 2007 07:54:13 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id D8CEE13C48D for ; Fri, 2 Feb 2007 07:54:12 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 44435 invoked from network); 2 Feb 2007 07:27:33 -0000 Received: from ppp-71-139-39-138.dsl.snfc21.pacbell.net (HELO ?10.0.5.59?) (nate-mail@71.139.39.138) by root.org with ESMTPA; 2 Feb 2007 07:27:33 -0000 Message-ID: <45C2E7DB.30204@root.org> Date: Thu, 01 Feb 2007 23:27:23 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Scott Long References: <20070123173026.E692416A4CD@hub.freebsd.org> <45B65710.4060607@root.org> <20070123105009.G41619@ns1.feral.com> <45B67401.9070102@samsco.org> <20070201150111.B77236@ns1.feral.com> <45C27965.1010803@samsco.org> In-Reply-To: <45C27965.1010803@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mjacob@freebsd.org, scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c 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, 02 Feb 2007 07:54:14 -0000 Scott Long wrote: > mjacob@freebsd.org wrote: >>> >>> umass should probably just disable the SYNC_CACHE commands from CAM, >>> as well as whatever other commands are always quirked. The firewire SIM >>> should probably do the same. >>> >> >> Err, probably should be XPORT based? > > Ah, very true. Taking that a step further, there should probably be a > broader concept of RBC and/or MMC as opposed to the assumption that > everything is SBC. > > Scott I have some experience with that (see the NO_6_BYTE sim option I added for usb and firewire). Of course, that was a hack and should be a XPORT setting as you point out. However, I don't think the umass situation is the same. That's why I haven't acted on it yet. The issue is that SYNC_CACHE is a perfectly valid RBC command. Some devices support it and it works (50% of flash drives my guess), some reject it but continue processing commands (25% maybe), and some hang after receiving it (10-25%). Obviously, the type of device determines whether it's more likely to support this or not (usb hard drive, almost certainly; mp3 player, probably not). For the devices that hang, I have a strong suspicion that their firmware state machine looks like this: case SYNC_CACHE: OptionallyWriteData(); while (1); // wait for detach Florent Thoumie (flz@) started some work based on some evidence that Linux checks a "write cache present" bit in the INQUIRY data and decides whether or not to run SYNC_CACHE based on that. It's unknown yet how closely this bit correlates with the hanging behavior though. I think Windows actually never runs SYNC_CACHE unless you select "detach device". So if we added the capability for a device_eject() newbus method and the default implementation ran device_shutdown(), then scsi_da(4) could run SYNC_CACHE only from its shutdown method and thus it wouldn't matter if the device hung from it. Right now, we run SYNC_CACHE from daclose() and so umounting the drive is enough to cause a hang, and the hangs on boot are from GEOM tasting the drive (daopen/daclose). With this change, a device could be plugged in and mounted/umounted multiple times. Only when the user said "about to eject" would it run SYNC_CACHE. The only limitation is that after running "eject", the device would have to be unplugged and replugged before it could be mounted again. But that's expected behavior. Combine this with the write cache bit detection and you have a robust solution. Comments? -- Nate From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 2 15:18:16 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C485F16A401; Fri, 2 Feb 2007 15:18:16 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 7968C13C4A6; Fri, 2 Feb 2007 15:18:16 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id l12FI91x003091; Fri, 2 Feb 2007 08:18:14 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45C35622.5090504@samsco.org> Date: Fri, 02 Feb 2007 08:17:54 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Nate Lawson References: <20070123173026.E692416A4CD@hub.freebsd.org> <45B65710.4060607@root.org> <20070123105009.G41619@ns1.feral.com> <45B67401.9070102@samsco.org> <20070201150111.B77236@ns1.feral.com> <45C27965.1010803@samsco.org> <45C2E7DB.30204@root.org> In-Reply-To: <45C2E7DB.30204@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 02 Feb 2007 08:18:15 -0700 (MST) X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: mjacob@freebsd.org, scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c 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, 02 Feb 2007 15:18:16 -0000 Nate Lawson wrote: > Scott Long wrote: >> mjacob@freebsd.org wrote: >>>> >>>> umass should probably just disable the SYNC_CACHE commands from CAM, >>>> as well as whatever other commands are always quirked. The firewire >>>> SIM >>>> should probably do the same. >>>> >>> >>> Err, probably should be XPORT based? >> >> Ah, very true. Taking that a step further, there should probably be a >> broader concept of RBC and/or MMC as opposed to the assumption that >> everything is SBC. >> >> Scott > > I have some experience with that (see the NO_6_BYTE sim option I added > for usb and firewire). Of course, that was a hack and should be a XPORT > setting as you point out. > > However, I don't think the umass situation is the same. That's why I > haven't acted on it yet. The issue is that SYNC_CACHE is a perfectly > valid RBC command. Some devices support it and it works (50% of flash > drives my guess), some reject it but continue processing commands (25% > maybe), and some hang after receiving it (10-25%). Obviously, the type > of device determines whether it's more likely to support this or not > (usb hard drive, almost certainly; mp3 player, probably not). > > For the devices that hang, I have a strong suspicion that their firmware > state machine looks like this: > case SYNC_CACHE: > OptionallyWriteData(); > while (1); // wait for detach > > Florent Thoumie (flz@) started some work based on some evidence that > Linux checks a "write cache present" bit in the INQUIRY data and decides > whether or not to run SYNC_CACHE based on that. It's unknown yet how > closely this bit correlates with the hanging behavior though. > > I think Windows actually never runs SYNC_CACHE unless you select "detach > device". So if we added the capability for a device_eject() newbus > method and the default implementation ran device_shutdown(), then > scsi_da(4) could run SYNC_CACHE only from its shutdown method and thus > it wouldn't matter if the device hung from it. Right now, we run > SYNC_CACHE from daclose() and so umounting the drive is enough to cause > a hang, and the hangs on boot are from GEOM tasting the drive > (daopen/daclose). With this change, a device could be plugged in and > mounted/umounted multiple times. Only when the user said "about to > eject" would it run SYNC_CACHE. The only limitation is that after > running "eject", the device would have to be unplugged and replugged > before it could be mounted again. But that's expected behavior. > > Combine this with the write cache bit detection and you have a robust > solution. Comments? > What you describe is exactly my intention. I didn't mean to imply that a new XPORT becomes the dumping ground for the quirk table. Btw, for the record, your assumption about SYNC_CACHE also applies to RAID controllers, which is why Pawel's BIO_FLUSH hack is so dangerous and wrong. Scott From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 2 15:57:47 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B98216A403 for ; Fri, 2 Feb 2007 15:57:47 +0000 (UTC) (envelope-from gogaxxx@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.freebsd.org (Postfix) with ESMTP id C35A913C442 for ; Fri, 2 Feb 2007 15:57:44 +0000 (UTC) (envelope-from gogaxxx@gmail.com) Received: by wr-out-0506.google.com with SMTP id 69so770746wra for ; Fri, 02 Feb 2007 07:57:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:organization:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=sBeR0gRsnBZyVK7SrpDupSf9WVxbjiwwPWlOqfyf4P5HKaWRPakw6dggV3+Ees/TIiEYlDNScGjlrlKLdPDQ3SYuWP3a8L3W7FrCysAjULmXW5bjkeQAb9Bu4STd79OwTkeDmTB9BBq1wG9aXjt460icw3EuQJv73h/J8Pb4V1A= Received: by 10.48.217.11 with SMTP id p11mr542963nfg.1170430211885; Fri, 02 Feb 2007 07:30:11 -0800 (PST) Received: from bormann.domain ( [80.240.99.39]) by mx.google.com with ESMTP id m15sm3900541nfc.2007.02.02.07.30.10; Fri, 02 Feb 2007 07:30:10 -0800 (PST) From: George Potapov Organization: softsearch To: freebsd-scsi@freebsd.org Date: Fri, 2 Feb 2007 18:30:36 +0300 User-Agent: KMail/1.9.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702021830.36522.nephrite@inbox.ru> Sender: George Potapov Subject: Need MFC support in RELENG_6 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, 02 Feb 2007 15:57:47 -0000 Are you planning to implement MFC for mpt(4) and if so when are you planning to merge it into the RELENG_6? Because I'm tired with those slow legacy IDEs and need a good SAS. -- George 'Nephrite' Potapov From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 2 16:13:59 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 185DC16A400 for ; Fri, 2 Feb 2007 16:13:59 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id E6F7E13C478 for ; Fri, 2 Feb 2007 16:13:56 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.8/8.13.8) with ESMTP id l12GDmCR019362; Fri, 2 Feb 2007 08:13:56 -0800 (PST) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.8/8.13.8/Submit) with ESMTP id l12GDmkV019359; Fri, 2 Feb 2007 08:13:48 -0800 (PST) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Fri, 2 Feb 2007 08:13:48 -0800 (PST) From: mjacob@freebsd.org To: Nate Lawson In-Reply-To: <45C2E7DB.30204@root.org> Message-ID: <20070202080329.L17850@ns1.feral.com> References: <20070123173026.E692416A4CD@hub.freebsd.org> <45B65710.4060607@root.org> <20070123105009.G41619@ns1.feral.com> <45B67401.9070102@samsco.org> <20070201150111.B77236@ns1.feral.com> <45C27965.1010803@samsco.org> <45C2E7DB.30204@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2007 16:13:59 -0000 > I think Windows actually never runs SYNC_CACHE unless you select "detach > device". Maybe for pluggable devices, but otherwise Windows uses SYNC_CACHE and FUA quite freely (and correctly). I'm uncomfortable with the notion that there is uncommitted data present in a device after a close that can be lost due to power lossage (or unpluggage). From a user application or filesystem point of view, this is an axiom violation that no OS should ever allow. >From a silly semantic point of view to get around this, we should still support and require SYNC_CACHE on close except where devices don't support it (and any device that hangs on a SYNC_CACHE doesn't support it- period). On detach, devices that still need to have data commited via an opcode that looks remarkably like SYNC_CACHE can and should have that happen- with all the infrastructure changes that go along with allowing devices to be detached (w/o complaint) with a live command. Or have I missed something it what you're suggesting? -matt From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 2 18:43:15 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8EC1C16A401 for ; Fri, 2 Feb 2007 18:43:15 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7347A13C47E for ; Fri, 2 Feb 2007 18:43:15 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 44471 invoked from network); 2 Feb 2007 18:42:28 -0000 Received: from ppp-71-139-39-138.dsl.snfc21.pacbell.net (HELO ?10.0.5.59?) (nate-mail@71.139.39.138) by root.org with ESMTPA; 2 Feb 2007 18:42:28 -0000 Message-ID: <45C3860C.3000206@root.org> Date: Fri, 02 Feb 2007 10:42:20 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mjacob@freebsd.org References: <20070123173026.E692416A4CD@hub.freebsd.org> <45B65710.4060607@root.org> <20070123105009.G41619@ns1.feral.com> <45B67401.9070102@samsco.org> <20070201150111.B77236@ns1.feral.com> <45C27965.1010803@samsco.org> <45C2E7DB.30204@root.org> <20070202080329.L17850@ns1.feral.com> In-Reply-To: <20070202080329.L17850@ns1.feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c 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, 02 Feb 2007 18:43:15 -0000 mjacob@freebsd.org wrote: > >> I think Windows actually never runs SYNC_CACHE unless you select >> "detach device". > > Maybe for pluggable devices, but otherwise Windows uses SYNC_CACHE and > FUA quite freely (and correctly). > > I'm uncomfortable with the notion that there is uncommitted data present > in a device after a close that can be lost due to power lossage (or > unpluggage). From a user application or filesystem point of view, this > is an axiom violation that no OS should ever allow. As long as it's specific to a known external device (USB), and the user knows that running some command (device_eject umass0) will make sure it's safe, I'm ok. >> From a silly semantic point of view to get around this, we should still > support and require SYNC_CACHE on close except where devices don't > support it (and any device that hangs on a SYNC_CACHE doesn't support > it- period). On detach, devices that still need to have data commited > via an opcode that looks remarkably like SYNC_CACHE can and should have > that happen- with all the infrastructure changes that go along with > allowing devices to be detached (w/o complaint) with a live command. > > Or have I missed something it what you're suggesting? Actually, that's a different idea I had where you set a timeout() before running SYNC_CACHE, then cancel the command if it hangs. Not sure how to implement the idea of a cancellable device call but maybe by creating a temporary thread? -- Nate From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 2 18:58:06 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E153516A406; Fri, 2 Feb 2007 18:58:06 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 869A813C467; Fri, 2 Feb 2007 18:58:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id l12Ivwk7004541; Fri, 2 Feb 2007 11:58:03 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45C389A6.1080606@samsco.org> Date: Fri, 02 Feb 2007 11:57:42 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: mjacob@freebsd.org References: <20070123173026.E692416A4CD@hub.freebsd.org> <45B65710.4060607@root.org> <20070123105009.G41619@ns1.feral.com> <45B67401.9070102@samsco.org> <20070201150111.B77236@ns1.feral.com> <45C27965.1010803@samsco.org> <45C2E7DB.30204@root.org> <20070202080329.L17850@ns1.feral.com> In-Reply-To: <20070202080329.L17850@ns1.feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 02 Feb 2007 11:58:03 -0700 (MST) X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: scsi@freebsd.org, Nate Lawson Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c 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, 02 Feb 2007 18:58:07 -0000 mjacob@freebsd.org wrote: > >> I think Windows actually never runs SYNC_CACHE unless you select >> "detach device". > > Maybe for pluggable devices, but otherwise Windows uses SYNC_CACHE and > FUA quite freely (and correctly). > > I'm uncomfortable with the notion that there is uncommitted data present > in a device after a close that can be lost due to power lossage (or > unpluggage). From a user application or filesystem point of view, this > is an axiom violation that no OS should ever allow. > > From a silly semantic point of view to get around this, we should still > support and require SYNC_CACHE on close except where devices don't > support it (and any device that hangs on a SYNC_CACHE doesn't support > it- period). The problem is that we don't know if the device will misbehave until it does, and then we don't know if we can reliably recover it. > On detach, devices that still need to have data commited > via an opcode that looks remarkably like SYNC_CACHE can and should have > that happen- with all the infrastructure changes that go along with > allowing devices to be detached (w/o complaint) with a live command. What instigates this problem is that the GEOM layer will open the device, read a few sectors, close it, then do that again a few more times, long before the user tries to mount/unmount it. It's the whole GEOM-taste thing where it tries to essentially auto-probe the storage. When we unconditionally send a SYNC_CACHE in daclose(), the misbehaving device is dead long before the user has a chance to do anything. One hack might be to track if any write command were done while the device was open, and only issue the SYNC_CACHE if so. Since the GEOM tasting will only read, it'll pass this test and avoid the problem. Scott From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 2 19:20:20 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8628916A405 for ; Fri, 2 Feb 2007 19:20:20 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 64BF213C4A5 for ; Fri, 2 Feb 2007 19:20:20 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 51757 invoked from network); 2 Feb 2007 19:20:09 -0000 Received: from adsl-67-119-74-222.dsl.sntc01.pacbell.net (HELO ?10.0.0.44?) (nate-mail@67.119.74.222) by root.org with ESMTPA; 2 Feb 2007 19:20:09 -0000 Message-ID: <45C38EDD.8010303@root.org> Date: Fri, 02 Feb 2007 11:19:57 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Scott Long References: <20070123173026.E692416A4CD@hub.freebsd.org> <45B65710.4060607@root.org> <20070123105009.G41619@ns1.feral.com> <45B67401.9070102@samsco.org> <20070201150111.B77236@ns1.feral.com> <45C27965.1010803@samsco.org> <45C2E7DB.30204@root.org> <20070202080329.L17850@ns1.feral.com> <45C389A6.1080606@samsco.org> In-Reply-To: <45C389A6.1080606@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mjacob@freebsd.org, scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c 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, 02 Feb 2007 19:20:20 -0000 Scott Long wrote: > mjacob@freebsd.org wrote: >> >>> I think Windows actually never runs SYNC_CACHE unless you select >>> "detach device". >> >> Maybe for pluggable devices, but otherwise Windows uses SYNC_CACHE and >> FUA quite freely (and correctly). >> >> I'm uncomfortable with the notion that there is uncommitted data >> present in a device after a close that can be lost due to power >> lossage (or unpluggage). From a user application or filesystem point >> of view, this is an axiom violation that no OS should ever allow. >> >> From a silly semantic point of view to get around this, we should >> still support and require SYNC_CACHE on close except where devices >> don't support it (and any device that hangs on a SYNC_CACHE doesn't >> support it- period). > > The problem is that we don't know if the device will misbehave until it > does, and then we don't know if we can reliably recover it. Right. And at the moment, basically the command response polls forever. Sometimes, if you unplug the device, the USB intr wakes things up and you can recover. >> On detach, devices that still need to have data commited via an opcode >> that looks remarkably like SYNC_CACHE can and should have that happen- >> with all the infrastructure changes that go along with allowing >> devices to be detached (w/o complaint) with a live command. > > What instigates this problem is that the GEOM layer will open the > device, read a few sectors, close it, then do that again a few more > times, long before the user tries to mount/unmount it. It's the whole > GEOM-taste thing where it tries to essentially auto-probe the storage. > When we unconditionally send a SYNC_CACHE in daclose(), the misbehaving > device is dead long before the user has a chance to do anything. One > hack might be to track if any write command were done while the device > was open, and only issue the SYNC_CACHE if so. Since the GEOM tasting > will only read, it'll pass this test and avoid the problem. Right. Shouldn't it be opening it read-only anyway? -- Nate From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 2 20:38:34 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CF4E16A401 for ; Fri, 2 Feb 2007 20:38:34 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 584DF13C441 for ; Fri, 2 Feb 2007 20:38:34 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.8/8.13.8) with ESMTP id l12KcQBW036763; Fri, 2 Feb 2007 12:38:34 -0800 (PST) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.8/8.13.8/Submit) with ESMTP id l12KcPI6036760; Fri, 2 Feb 2007 12:38:25 -0800 (PST) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Fri, 2 Feb 2007 12:38:25 -0800 (PST) From: mjacob@freebsd.org To: Nate Lawson In-Reply-To: <45C3860C.3000206@root.org> Message-ID: <20070202123728.C36488@ns1.feral.com> References: <20070123173026.E692416A4CD@hub.freebsd.org> <45B65710.4060607@root.org> <20070123105009.G41619@ns1.feral.com> <45B67401.9070102@samsco.org> <20070201150111.B77236@ns1.feral.com> <45C27965.1010803@samsco.org> <45C2E7DB.30204@root.org> <20070202080329.L17850@ns1.feral.com> <45C3860C.3000206@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2007 20:38:34 -0000 > As long as it's specific to a known external device (USB), and the user knows > that running some command (device_eject umass0) will make sure it's safe, I'm > ok. Mmm. >>> From a silly semantic point of view to get around this, we should still >> support and require SYNC_CACHE on close except where devices don't support >> it (and any device that hangs on a SYNC_CACHE doesn't support it- period). >> On detach, devices that still need to have data commited via an opcode that >> looks remarkably like SYNC_CACHE can and should have that happen- with all >> the infrastructure changes that go along with allowing devices to be >> detached (w/o complaint) with a live command. >> >> Or have I missed something it what you're suggesting? > > Actually, that's a different idea I had where you set a timeout() before > running SYNC_CACHE, then cancel the command if it hangs. Not sure how to > implement the idea of a cancellable device call but maybe by creating a > temporary thread? Why not just quiet SYNC_CACHE timeouts? -matt From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 2 20:43:09 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C0FB16A405 for ; Fri, 2 Feb 2007 20:43:09 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5AC9313C46B for ; Fri, 2 Feb 2007 20:43:09 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.8/8.13.8) with ESMTP id l12Kh112037063; Fri, 2 Feb 2007 12:43:09 -0800 (PST) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.8/8.13.8/Submit) with ESMTP id l12Kh1Nk037060; Fri, 2 Feb 2007 12:43:01 -0800 (PST) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Fri, 2 Feb 2007 12:43:01 -0800 (PST) From: mjacob@freebsd.org To: Scott Long In-Reply-To: <45C389A6.1080606@samsco.org> Message-ID: <20070202123844.U36488@ns1.feral.com> References: <20070123173026.E692416A4CD@hub.freebsd.org> <45B65710.4060607@root.org> <20070123105009.G41619@ns1.feral.com> <45B67401.9070102@samsco.org> <20070201150111.B77236@ns1.feral.com> <45C27965.1010803@samsco.org> <45C2E7DB.30204@root.org> <20070202080329.L17850@ns1.feral.com> <45C389A6.1080606@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: scsi@freebsd.org, mjacob@freebsd.org, Nate Lawson Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2007 20:43:09 -0000 >> >> From a silly semantic point of view to get around this, we should still >> support and require SYNC_CACHE on close except where devices don't support >> it (and any device that hangs on a SYNC_CACHE doesn't support it- period). > > The problem is that we don't know if the device will misbehave until it > does, and then we don't know if we can reliably recover it. This is back to what I referred to earlier by a week or so- booting installation (or as a fallback) with a pessimization flag that avoids all questionable commands until the system is up enough to load (via firmware(9) or sysctl or rc scripts) better information. > >> On detach, devices that still need to have data commited via an opcode that >> looks remarkably like SYNC_CACHE can and should have that happen- with all >> the infrastructure changes that go along with allowing devices to be >> detached (w/o complaint) with a live command. > > What instigates this problem is that the GEOM layer will open the > device, read a few sectors, close it, then do that again a few more > times, long before the user tries to mount/unmount it. It's the whole > GEOM-taste thing where it tries to essentially auto-probe the storage. > When we unconditionally send a SYNC_CACHE in daclose(), the > misbehaving device is dead long before the user has a chance to do > anything. One hack might be to track if any write command were done > while the device was open, and only issue the SYNC_CACHE if so. > Since the GEOM tasting will only read, it'll pass this test and avoid > the problem. It's not a hack to keep track of a write commands- after all, I did exactly this for SunOS 4.1 (or was it 4.0?) to know whether you'd dirtied the device or not- and of course *I* would be believe it to still be perfect, eh? :-) This would be an excellent and cheap idea to implement and I think I'll do so. I bet you that this will take care of nearly all of the boot time issues. From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 2 21:30:35 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C8D216A403 for ; Fri, 2 Feb 2007 21:30:35 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8BD13C48D for ; Fri, 2 Feb 2007 21:30:35 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 74487 invoked from network); 2 Feb 2007 21:30:36 -0000 Received: from adsl-67-119-74-222.dsl.sntc01.pacbell.net (HELO ?10.0.0.44?) (nate-mail@67.119.74.222) by root.org with ESMTPA; 2 Feb 2007 21:30:36 -0000 Message-ID: <45C3AD72.7020007@root.org> Date: Fri, 02 Feb 2007 13:30:26 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mjacob@freebsd.org References: <20070123173026.E692416A4CD@hub.freebsd.org> <45B65710.4060607@root.org> <20070123105009.G41619@ns1.feral.com> <45B67401.9070102@samsco.org> <20070201150111.B77236@ns1.feral.com> <45C27965.1010803@samsco.org> <45C2E7DB.30204@root.org> <20070202080329.L17850@ns1.feral.com> <45C389A6.1080606@samsco.org> <20070202123844.U36488@ns1.feral.com> In-Reply-To: <20070202123844.U36488@ns1.feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c 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, 02 Feb 2007 21:30:35 -0000 mjacob@freebsd.org wrote: >>> >>> From a silly semantic point of view to get around this, we should >>> still support and require SYNC_CACHE on close except where devices >>> don't support it (and any device that hangs on a SYNC_CACHE doesn't >>> support it- period). >> >> The problem is that we don't know if the device will misbehave until it >> does, and then we don't know if we can reliably recover it. > > This is back to what I referred to earlier by a week or so- booting > installation (or as a fallback) with a pessimization flag that avoids > all questionable commands until the system is up enough to load (via > firmware(9) or sysctl or rc scripts) better information. That wouldn't work in this case since you would need to tell GEOM not to look at certain devices (just another quirk list). >>> On detach, devices that still need to have data commited via an >>> opcode that looks remarkably like SYNC_CACHE can and should have that >>> happen- with all the infrastructure changes that go along with >>> allowing devices to be detached (w/o complaint) with a live command. >> >> What instigates this problem is that the GEOM layer will open the >> device, read a few sectors, close it, then do that again a few more >> times, long before the user tries to mount/unmount it. It's the whole >> GEOM-taste thing where it tries to essentially auto-probe the storage. >> When we unconditionally send a SYNC_CACHE in daclose(), the >> misbehaving device is dead long before the user has a chance to do >> anything. One hack might be to track if any write command were done >> while the device was open, and only issue the SYNC_CACHE if so. Since >> the GEOM tasting will only read, it'll pass this test and avoid the >> problem. > > It's not a hack to keep track of a write commands- after all, I did > exactly this for SunOS 4.1 (or was it 4.0?) to know whether you'd > dirtied the device or not- and of course *I* would be believe it to > still be perfect, eh? :-) > > This would be an excellent and cheap idea to implement and I think I'll > do so. I bet you that this will take care of nearly all of the boot time > issues. That's fine, but you'd also have to track things like MODE SELECT or COPY or FORMAT or other commands that might actually dirty the media without being a WRITE. I don't see why GEOM can't open the device read-only to do its probe. Doesn't it use a device vnode? -- Nate From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 2 21:32:23 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30E6D16A408 for ; Fri, 2 Feb 2007 21:32:23 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id F137F13C441 for ; Fri, 2 Feb 2007 21:32:22 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 74773 invoked from network); 2 Feb 2007 21:32:23 -0000 Received: from adsl-67-119-74-222.dsl.sntc01.pacbell.net (HELO ?10.0.0.44?) (nate-mail@67.119.74.222) by root.org with ESMTPA; 2 Feb 2007 21:32:23 -0000 Message-ID: <45C3ADDE.6040407@root.org> Date: Fri, 02 Feb 2007 13:32:14 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mjacob@freebsd.org References: <20070123173026.E692416A4CD@hub.freebsd.org> <45B65710.4060607@root.org> <20070123105009.G41619@ns1.feral.com> <45B67401.9070102@samsco.org> <20070201150111.B77236@ns1.feral.com> <45C27965.1010803@samsco.org> <45C2E7DB.30204@root.org> <20070202080329.L17850@ns1.feral.com> <45C3860C.3000206@root.org> <20070202123728.C36488@ns1.feral.com> In-Reply-To: <20070202123728.C36488@ns1.feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c 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, 02 Feb 2007 21:32:23 -0000 mjacob@freebsd.org wrote: >> As long as it's specific to a known external device (USB), and the >> user knows that running some command (device_eject umass0) will make >> sure it's safe, I'm ok. > > Mmm. > >>>> From a silly semantic point of view to get around this, we should still >>> support and require SYNC_CACHE on close except where devices don't >>> support it (and any device that hangs on a SYNC_CACHE doesn't support >>> it- period). On detach, devices that still need to have data commited >>> via an opcode that looks remarkably like SYNC_CACHE can and should >>> have that happen- with all the infrastructure changes that go along >>> with allowing devices to be detached (w/o complaint) with a live >>> command. >>> >>> Or have I missed something it what you're suggesting? >> >> Actually, that's a different idea I had where you set a timeout() >> before running SYNC_CACHE, then cancel the command if it hangs. Not >> sure how to implement the idea of a cancellable device call but maybe >> by creating a temporary thread? > > Why not just quiet SYNC_CACHE timeouts? That's for a device that still works after a timeout. Something about either GEOM, CAM, or USB hangs (or loops infinitely) and refuses to continue the boot if the device times out. -- Nate From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 3 01:39:31 2007 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 068A616A400; Sat, 3 Feb 2007 01:39:31 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id CFB8D13C4AC; Sat, 3 Feb 2007 01:39:30 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.8/8.13.8) with ESMTP id l131dMKo055968; Fri, 2 Feb 2007 17:39:30 -0800 (PST) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.8/8.13.8/Submit) with ESMTP id l131dL0G055965; Fri, 2 Feb 2007 17:39:22 -0800 (PST) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Fri, 2 Feb 2007 17:39:21 -0800 (PST) From: mjacob@freebsd.org To: Nate Lawson In-Reply-To: <45C3AD72.7020007@root.org> Message-ID: <20070202173751.R55867@ns1.feral.com> References: <20070123173026.E692416A4CD@hub.freebsd.org> <45B65710.4060607@root.org> <20070123105009.G41619@ns1.feral.com> <45B67401.9070102@samsco.org> <20070201150111.B77236@ns1.feral.com> <45C27965.1010803@samsco.org> <45C2E7DB.30204@root.org> <20070202080329.L17850@ns1.feral.com> <45C389A6.1080606@samsco.org> <20070202123844.U36488@ns1.feral.com> <45C3AD72.7020007@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mjacob@freebsd.org, scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2007 01:39:31 -0000 > > That's fine, but you'd also have to track things like MODE SELECT or COPY or > FORMAT or other commands that might actually dirty the media without being a > WRITE. No, no, no. Things like MODE SELECT or COPY or FORMAT are out of scope of SYNCHRONIZE CACHE- I don't have time at the moment to chase this, but I'll bet you this is laid out in sbc2 somewhere. > I don't see why GEOM can't open the device read-only to do its probe. Doesn't > it use a device vnode? Sure- but daclose still needs to be made cognizant of that anyway.