From owner-freebsd-scsi@FreeBSD.ORG Mon Jul 28 10:58:52 2003 Return-Path: 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 665AA37B401; Mon, 28 Jul 2003 10:58:52 -0700 (PDT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E8EF43F75; Mon, 28 Jul 2003 10:58:51 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id MUA74016; Mon, 28 Jul 2003 10:58:49 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 8F2CA5D07; Mon, 28 Jul 2003 10:58:48 -0700 (PDT) To: Nate Lawson In-Reply-To: Message from Nate Lawson of "Sun, 27 Jul 2003 23:23:33 PDT." <20030727231701.N51710@root.org> Date: Mon, 28 Jul 2003 10:58:48 -0700 From: "Kevin Oberman" Message-Id: <20030728175848.8F2CA5D07@ptavv.es.net> cc: current@freebsd.org cc: scsi@freebsd.org Subject: Re: cvs commit: src/sys/cam cam_ccb.h src/sys/cam/scsi scsi_cd.c scsi_da.c src/sys/dev/ata atapi-cam.c src/sys/dev/usb umass.c src/sys/dev/firewire sbp.c X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2003 17:58:52 -0000 > Date: Sun, 27 Jul 2003 23:23:33 -0700 (PDT) > From: Nate Lawson > Sender: owner-freebsd-current@freebsd.org > > On Sun, 27 Jul 2003, Nate Lawson wrote: > > Modified files: > > sys/cam cam_ccb.h > > sys/cam/scsi scsi_da.c scsi_cd.c > > sys/dev/ata atapi-cam.c > > sys/dev/usb umass.c > > sys/dev/firewire sbp.c > > Log: > > Add a PATH_INQ flag, PIM_NO_6_BYTE, which indicates the SIM never wishes to > > receive 6 byte commands. Add a check for this flag to da(4) and cd(4) so > > that they honor it. This is a quick workaround for many devices (especially > > USB) that require da(4) quirks to operate. The more complete approach is > > to finish the new transport code which will be aware of the SCSI version a > > transport implements. > > > > MFC after: 1 day > > > > Revision Changes Path > > 1.26 +2 -1 src/sys/cam/cam_ccb.h > > 1.80 +8 -0 src/sys/cam/scsi/scsi_cd.c > > 1.147 +8 -0 src/sys/cam/scsi/scsi_da.c > > 1.18 +1 -1 src/sys/dev/ata/atapi-cam.c > > 1.58 +1 -1 src/sys/dev/firewire/sbp.c > > 1.88 +1 -1 src/sys/dev/usb/umass.c > > This is the first step to removing many of the da(4) quirks that have > accumulated for USB devices. This code should remove the message: > "READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10." It > should also fix USB devices which fail when receiving 6 byte commands but > do not yet have a quirk. > > After this code is in both stable and current, current USB quirks will be > deprecated but can be re-enabled in a pinch with a kernel option. > Unfortunately, I only have contact information for the more recent quirks > that were committed and so the only way to find devices that have other > problems (i.e. NO_SYNC_CACHE) is to disable the quirks and re-enable them > for devices that still fail. I'm doing this as early as possible before > 5.2 to get things sorted out and if your device fails at that point, it > can be returned to ordinary behavior with a kernel option until I remove > it from the deprecated section. This looks great to me. The entire quirks system is a royal pain. It really needs to be driven by an external file so that the kernel does not need a re-compile for every device that requires poking something odd, but eliminating all of the 6 bye/10 byte ones will greatly improve life. I know such things (like pccard.conf) are ugly, but it's better than patching the source and re-building the kernel all of the time. There must be a better way. Almost anything like this that I plug into Windows "just works". That means no driver installation or anything. (The USB devices almost always include software, but I seldom install it.) I just HATE it when Windows works better than FreeBSD, but hardware can be a tough nut to crack. Is there any hope of getting PR53094 to support the Nomad MuVo moved to current. It will still need a quirk as it requires both NO_SYNC_CACHE and NO_PREVENT. The pr has been around for some time but was just assigned to joe@ about 10 days ago, so it may already be on it's way. (I am about 250 messages behind in cvs-all, so it may already have been committed.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634