Date: Sun, 27 Jul 2003 23:23:33 -0700 (PDT) From: Nate Lawson <nate@root.org> To: 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 Message-ID: <20030727231701.N51710@root.org> In-Reply-To: <20030728061606.046BC37B401@hub.freebsd.org> References: <20030728061606.046BC37B401@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030727231701.N51710>