> I have a similar problem concerning an Asus SC200 NcR53C810-based SCSI-card.
> The kernel version (2.0.34/35/37pre4) doesnt matter -- I tracked it down to
> the device driver. Using the old driver NCR53c7,8xx works, the dedicated
> NCR58c8xx-driver runs into problems (and yes, I tried to fiddle around with
> tagged commands etc).
>
> Now here's what happening: I have an old 2 GB SCSI DAT-streamer from Maynard
> attached to my SCSI bus. Writing to it will work fine for a while but then
> the bus will hang, eventually resetting (sometimes not). Running xcdroast
> (which seems to scan the SCSI-bus) will report my CD-ROM-drive (the last
Probably xcdroast send INQUIRY commands to all SCSI devices. In real SCSI,
devices report their capabilities in the INQUIRY response. The ncr53c8xx
driver trusts the INQUIRY response from each device and only uses features
the device claims to support. If it happens that a device does not really
support a feature reported in its INQUIRY response or just sent shitty
data instead, then problems may occur.
> before my streamer -- last entry in the log), then will freeze the entire
> system. At one instant I could see the system recover with an SCSI-bus
> reset. As I mentioned above, using the old driver solves all the problems,
> while reducing I/O throughput quite a bit.
>
> If it would be useful for you, I could run another test with my streamer
> writing down the exact error messages.
I am interested in the INQUIRY response sent by devices that fail with the
ncr53c8xx driver. If you want to use scsiinfo for getting such data from a
scanner, this will not work due to the sg driver only accepting O_RDWR
open(). Hacking the sg_open() routine in sg.c so that it will also accept
O_RDONLY open() works around this problem.
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/