Date: Wed, 24 Jan 2007 15:46:08 +0100 From: Bernd Walter <ticso@cicely12.cicely.de> To: Hans Petter Selasky <hselasky@c2i.net> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, freebsd-stable@freebsd.org, Ed Schouten <ed@fxq.nl>, Pietro Cerutti <pietro.cerutti@gmail.com> Subject: Re: atacontrol kernel crash (atausb?) Message-ID: <20070124144607.GD39608@cicely12.cicely.de> In-Reply-To: <200701241254.51900.hselasky@c2i.net> References: <e572718c0701150322o38d463a0qc8ccca55a508e871@mail.gmail.com> <e572718c0701150824o24d14ff8t4f42dbe1cd0314c6@mail.gmail.com> <20070124113858.GG64263@hoeg.nl> <200701241254.51900.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 24, 2007 at 12:54:51PM +0100, Hans Petter Selasky wrote: > On Wednesday 24 January 2007 12:38, Ed Schouten wrote: > > Hello, > > > > * Pietro Cerutti <pietro.cerutti@gmail.com> wrote: > > > On 1/15/07, Hans Petter Selasky <hselasky@c2i.net> wrote: > > > >No. What happens when you use/load "umass" and unload "atausb" ? > > > > > > Everything works nice with umass. It creates the da0 device node. > > > It just shows up these errors, as it always did... > > > GEOM: new disk da0 > > > da0 at umass-sim0 bus 0 target 0 lun 0 > > > da0: < USB2.0 FlashDisk 1.1b> Removable Direct Access SCSI-0 device > > > da0: Serial Number > > > da0: 40.000MB/s transfers > > > da0: 248MB (507904 512 byte sectors: 64H 32S/T 248C) > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > > I had these messages with two other devices before, an MP3 player and a > > USB floppy drive. I fixed these errors by adding a quirk to > > /sys/cam/scsi/scsi_da.c. > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=97174 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=107101 > > Instead of having all these quirks, isn't it possible that the SCSI layer can > auto-probe this? No - it is intended to fail on devices not supporting the commands. And the user should know if a drive has not been synced befor unplugging it from power. The SCSI Layer could ask if the device has a cache at least, but I this would likely just relocate the problem. Issuing unsupported commands should be harmless for any sane device, but often bad implemented devices just hang on unknown commands. IIRC umass specification has a way to distinguish reduced command set flash type from generic SCSI devices, by interpreting the subclass. That way umass could safely catch such commands. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070124144607.GD39608>