[1306] in linux-scsi channel archive
Re: Problems with MO-Drive
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Fri Jan 24 17:13:20 1997
Date: Fri, 24 Jan 1997 21:34:38 +0000 (GMT)
From: Gerard Roudier <groudier@club-internet.fr>
To: Michael Ulbrich <mul@lab1033.berlin.ptb.de>
cc: linux-scsi@vger.rutgers.edu, mul@lab1033.berlin.ptb.de
In-Reply-To: <9701241002.AA22783@hamilton.lab1033.berlin.ptb.de>
On Fri, 24 Jan 1997, Michael Ulbrich wrote:
> On Mon Jan 20 23:07:35 1997 Jeffrey Templon wrote:
>
> >I saw you mentioned the NCR chip. 2.0.0 kernel has a very buggy NCR
> >driver. I managed to completely trash my disk subsystem by running
> >it. I'd recommend kernel version 2.0.18 or higher.
2.0.0 had only Drew's NCR driver. The only file that is different in
2.0.28 is 53c7,8xx.c. Here are the differences:
--- 53c7,8xx.c Wed Jun 5 00:22:08 1996
+++ /devel/src/linux/drivers/scsi/53c7,8xx.c Sat Jul 20 18:35:40 1996
@@ -3546,6 +3546,7 @@
case MODE_SELECT:
case WRITE_6:
case WRITE_10:
+ case START_STOP: /* also SCAN, which may do DATA OUT */
#if 0
printk("scsi%d : command is ", host->host_no);
print_command(cmd->cmnd);
@@ -3564,7 +3565,6 @@
* These commands do no data transfer, we should force an
* interrupt if a data phase is attempted on them.
*/
- case START_STOP:
case TEST_UNIT_READY:
datain = dataout = 0;
break;
This change just allow data out for START_STOP opcode that is the same
as SCAN for scanner devices.
That's indeed very buggy and the 53C8XX driver has been fixed too for that.
In my opinion, the real explanation of the MO drive problem is known and
a fix has been suggested by Leonard Zubkoff.
> Yeah, thanks Jeffrey, I upgraded to 2.0.28 and the NCR-SCSI bus hangs
> are gone. The developers seem to have achieved a major improvement in
> stability here, well done!
>
> OTOH, there are still some strange things happening, which of course
> are related to my unusual application, but here it goes (for those
> who are interested):
>
> Let me first describe my problem again: I'm reading (and only reading)
> magneto-optical disks which are written in a non contiguous manner, i.e
> valid (readable) sectors are randomly mixed with unreadable (maybe blank,
> maybe containing some kind of filemark) sectors. I'm accessing the disk
> on the raw level, there is no recognisable filesystem on the disk.
There is no disk raw devices under Linux, only block devices and file
systems. The sr driver allows by default 120 sectors read ahead when the
scsi controller supports scatter/gather and 4 if not.
Even if you set read ahead to 0, the kernel will read at least 1 block
from the device.
> The program I wrote to access the disk tries to read single sectors
> (512 bytes) and returns valid or invalid buffer data depending on the
> return status of the fread() call.
fread is a buffered interface. So it will read 1 STDIO BUFFER at a time
from the kernel.
Gerard.
