Tkil,
It seems very unlikely indeed that the problem is in redirection
of the packet commands to incorrect drives in ide-scsi. As soon
as a command gets to idescsi_queue(), the driver is using the id
as an index to get a pointer to the ide_drive_t drive structure,
and all further processing is done using this per-drive pointer.
To verify that the above isn't indeed the case, I'd recommend
mounting several cd's simultaneously and reading from all of them
through ide-scsi, rather than writing a CD-R. This will move
the real-time issues from the picture and will allow us to see
whether the commands are redirected to incorrect drives.
Much More likely is that there is some serialization going on
somewhere (either in software or in hardware), which doesn't allow
the multiple channels to run simultaneously, so that access to one
drive is not being performed in the limits allowed by its buffer.
This will cause data underrun and a sense error.
If I understand the setup correctly, we have:
- hda as the source which contains the image to be burned.
- hdb, hdc and hdd as the cd-r writers.
As IDE drives connected to the same interface are noramlly serialized
by the IDE hardware (except for special conditions such as ATAPI
tape drives, seeks in cdrom drives, and new devices which support
overlap under a driver which supports it), we definitely have
serialization between:
- hda and hdb
- hdc and hdd
And perhaps additional serializations, in the IDE chipset or
somewhere else in the software.
Performance when writing from hda to hdc will be best. When hdb
is involved, we will start to depend on the IDE driver scheduling
decisions of how to share the bus bandwidth between hda and hdb.
hda will likely be busy as cdrecord will prefetch data from
it to two (or three) streams simultaneously to fill its user-space
fifo as much as possible. Sequential drive performance is pretty
good, but when we have two sequential streams with an offset from
each other, we are likely to experience drive seeks which are
more costly than sequential reads.
I'd recommend changing choose_drive() in drivers/block/ide.c
as follows -- replacing the "drive = hwgroup->drive;" line with
"drive = hwgroup->drive->next;" line, and commenting out the
part later which tests the best->nice1 flag (the second part
of the patch can alternatively be done by using "echo nice1:0 >
/proc/ide/hdx/settings for each IDE drive).
This will select round-robin scheduling between the drives. This
is usually not the best for throughput, but might be more appropriate
when real-time constrains are involved.
Another test to try is to generally increase performance by
switching all capable drives to DMA operation:
hdparm -d1 /dev/hdx for all IDE drives, including the CD-R's.
Cheers,
Gadi
--- ide.c~ Sat Aug 14 04:32:10 1999
+++ ide.c Tue Jan 25 20:42:24 2000
@@ -1044,7 +1044,7 @@
repeat:
best = NULL;
- drive = hwgroup->drive;
+ drive = hwgroup->drive->next;
do {
if (drive->queue && (!drive->sleep || 0 <= (signed long)(jiffies - drive->sleep))) {
if (!best
@@ -1057,6 +1057,7 @@
}
}
} while ((drive = drive->next) != hwgroup->drive);
+#if 0
if (best && best->nice1 && !best->sleep && best != hwgroup->drive && best->service_time > WAIT_MIN_SLEEP) {
long t = (signed long)(WAKEUP(best) - jiffies);
if (t >= WAIT_MIN_SLEEP) {
@@ -1076,6 +1077,7 @@
} while ((drive = drive->next) != best);
}
}
+#endif
return best;
}
On Mon, 24 Jan 2000, Tkil wrote:
>
> Hello again.
>
> The plot sickens. In our first installment, we seemed to be able to
> do successful writes (these were "-dummy" writes, however) to two
> CD-Rs if they were on different channels, while a third CD-R (on the
> same channel as the second) apparently never saw commands destined for
> it if that channel master was writing.
>
> Well, we have another intersting data point. We were merrily burning
> a CD-R to "dev=0,1,0", that is, /dev/hdc. When we tried to start a
> burn to /dev/hdb (on a *different* IDE channel!) the same faulty
> behavior was seen: /dev/hdb started grabbing all the commands
> intended for /dev/hdc, and the cdrecord process talking to /dev/hdc
> bailed out with a sense error.
>
> So this seems to tell me that there is something weird in how ide-scsi
> redirects commands, and that it's sensitive to "active" devices
> vs. "inactive" devices (since I can burn just fine to hdd if both hdb
> and hdc are inactive!)
>
> And again, starting the burn to /dev/hdb first, then intiating the
> burn to hdc, seems to work just fine.
>
> Given that we are contemplating making ide-scsi the norm, I would
> appreciate any ideas people can offer. Mark Hahn has sent me a few
> questions, which hopefully are answered in this reply. If anyone
> would like me to run a particular test, I'd be glad to do so.
>
> Thanks for your attention,
> t.
>
>
> -
> 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/
>
>
-
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/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:15 EST