On Fri, 24 Mar 2000 11:46:30 +0000, Iain Sandoe [off-list ref] wrote:
quoted
I second the question. And what does "safe" mean? Could these
aggressive settings damage your data, your hardware, or both? If it's
just data, then that's okay for me to try. I'll turn it off when I
find corrupted data.
Thanks!
"Safe" is a bit tricky in this case - it is likely to be
temperature-dependent and subject to fairly random behaviour when you get
close to the limit.
Most likely the data is at highest risk - with the possibility of trashing
the entire disk (rather than just Linux partitions).
It is very hard to see a way in which the H/W could be damaged because most
aspects of the scsi transfer are negotiated. You would have to work fairly
hard a finding a series of catastrophic failures resulting in overheating...
aspects of the scsi transfer are negotiated. You would have to work fairly
hard a finding a series of catastrophic failures resulting in overheating...
apropos the number of pins:
There are two reasons for more pins on scsi
1/ to use a differential bus - which was also an option on scsi-1
This allows longer interconnect and/or greater noise immunity.
2/ to have access to the UW/scsi-2/3 features
(e.g. more data or address bits).
AKAIK the Macs have never had any external (or 'standard' internal) busses
that were differential (although maybe the IIfx did). There are some cards
like that that were installed as standard - e.g. on my G3/Minitower - but
it's usually link-selectable anyway.
apropos chaining different devices:
A number of scsi drivers (e.g. IIRC the ones one the suns) used to probe at
different rates (for sync operation) and back off to the lowest rate that
worked in the chain.
I don't know if this principle is used by the Linux drivers (but I'm sure
some guru will comment).
AFAIK this is necessary at some stages of the bus negotiation - although
once the transaction is agreed there may be the option of going faster (hmmm
seems a bit dodgy electrically).
Anyway this was/still is a good reason for separating high performance
devices from low.
Personally, the pain of dealing with an unreliable and unpredictable system
doesn't seem worth push one's luck ;-)
By far the best solution is to check the specs on the devices you have
(usually obtainable on the www), and take a peek at the ANSIs for SCSI
(although you might have to buy these or get them through a library).
Thanks a lot, hardware damage was also my main concern. This and Michel's
poting pretty much cleared anything I wanted to know. I haven't seen any
messages about scsi negotiation errors so far, so I guess I'll push my
luck a little farther ;^).
I had a lot of scsi troubles with an external hd and a Tandberg tape under
mklinux, mostly due to a bad quality cable and bad termination, but then
the Mach Kernel spew tons of error messages at me.
The Orb is capable of Ultra scsi, so I suppose fast scsi should pose no
problems on this side. I haven't tried to hook the tape drive to that chain,
maybe I'll test it, too, but I'd have to get another adapter cable first
(and a good one, this time!), now having to connect 25-pin sub-D, 50-pin HD
and a Centronix connector |-(.
Cheers,
Derek
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/