15 Nov
2007
15 Nov
'07
6:19 p.m.
On Thursday 15 November 2007 10:32, Jules Richardson wrote:
Yikes.
And I'm due to start a new job shortly, which also involves a couple of hours
a day drive time, which is only going to make it worse.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
Roy J. Tellason wrote:
I saw some mention in there someplace of support in the kernel, but they
weren't very explicit about support for what, exactly.
On Thursday 15 November 2007 00:36, Doc Shipley
wrote:
Hehe. Did that and the first two hits say "not recommended" and "not
supported" in the text that google is showing me there...
I've got a feeling there's not even the code there for it Linux - it just
doesn't know how to handle commands sent to the HBA at all. Few years ago
when I looked though; maybe it's different now... > Both
USB and SCSI have the device-to-device capability written into
> some specs, but it's rarely implemented. ("USB on the go").
Which reminds me of a comment I saw somewhere about the possibility of
having a SCSI bus with more than one host adapter on it. Is that even
possible?
Possible, and has been done fairly often in storage arrays.
Google "multi-initiator scsi" and rock on. :) It's certainly technically possible - I used to
look after a pair of SGI
O200 machines which have a bunch of disk storage shared between them on the
same SCSI bus.
Yeah, but you're talking protocol, of which there currently isn't any at the
BBII end.
Another thought, though, is that might make for
some interesting
possibilities with that Bigboard II, which has that SASI port that seems
(as far as I can tell from just looking at signal names) to be fairly
compatible with SCSI, maybe hooking _that_ into a SCSI bus might have
some serious uses.
Hmm. I think SASI's sufficiently different that you'd be hacking your own
SCSI drivers to do it - from memory there were some extra phases in the
SCSI protocol which weren't in SASI. That's assuming whatever HBA you use doesn't
try and do the work for you and
then barf because the device isn't SCSI.
Thankfully I seem to have a number of different choices available to me here.
Plus I don't think SASI had any concept of parity,
so you'd probably have to
hack a bit of hardware there to generate the parity bit (assuming you
couldn't disable it via software).
I'm not sure what the deal is with that offhand.
Note that Linux chokes on devices that don't
respond to the identify
command - which is every SASI device and some early SCSI ones too. I'm not
sure how deeply set that is into the 'core' SCSI layer, but I don't think
it's down to driver behaviour (i.e. you can't get around it by hacking your
own HBA driver). No idea what other OSes are like...
I'm sure it's in the source tree somewhere, but I haven't dug into that at
all lately and have no idea where it might be located, if it's even in
there.
I'm sure it *could* be done though, but it's a
reasonable amount of work.
It'd be simpler to build your own SASI interface and drive it from a
suitable I/O board (a PC parallel port doesn't quite have enough lines
unfortunately) from user-land. After all, the sort of data transfer rates
for SASI stuff isn't exactly blinding, so some sort of polled-I/O
bit-twiddling should be good enough.
I'm not sure I'm up to building hardware to sit on the peecee side of things,
though.
Sure beats
trying to transfer any nontrivial amount of data over a
serial link, and has the potential for going one heck of a lot faster!
Been there done that with a few ST-412 drives (via Adaptec SCSI bridge
boards). Think it was about 8 hours per 20MB or thereabouts. So many things
to look at, and never enough time...
Yep... I got a PC SASI interface all designed and then halfway wired up
ages ago, then just haven't had the time to do anything more with it for 6
months or so :-(