Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Jul 2003 10:58:48 -0700
From:      "Kevin Oberman" <oberman@es.net>
To:        Nate Lawson <nate@root.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 
Message-ID:  <20030728175848.8F2CA5D07@ptavv.es.net>
In-Reply-To: Message from Nate Lawson <nate@root.org>  of "Sun, 27 Jul 2003 23:23:33 PDT." <20030727231701.N51710@root.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Sun, 27 Jul 2003 23:23:33 -0700 (PDT)
> From: Nate Lawson <nate@root.org>
> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030728175848.8F2CA5D07>