Yes, it looks like it was only sent to me. Sorry, I'm a bit bad about making
sure I reply back to the list on all these messages. seems like the mailing
lists I'm on behave differently - others I can just reply (instead of to
all) and it goes to the list.
===== Original Message from Chiaki Ishikawa
<[EMAIL PROTECTED]> at 4/21/99 10:29 am
X-PMC-CI-e-mail-id: 10384
Hello Charles Galpin,
Well, let us hope that someone who knows the
latest driver source of adaptec 2940U2W inside out
would figure out a subtle problem or bug in the 2.2.x version
and fix it soon.
I am using old-fashioned SCSI-II disks (50 pins) at home. I have 6 of
them on my two computers and they work fine albeit slowly.
I use BusLogic, Tekram DC390, and Symbios chip (NCR 8xx chip) card.
[I also still have AHA1542CF and an old VL-bus BusLogic scsi card.]
There are two SCSI CD drives, one CD changer box, and one CD/PD combo.
So far, only Tekram DC390 driver caused me grief when I tried to
connect Nakamichi multi-LUN CD changer to it. The driver for DC390 underwent
major
revision due to bug reports from other people and myself and
has become more robust.
It seems that older (slower hence) systems had fewer problems than the
current crop of SCSI cards and disks.
Before closing, Just a hunch. Have you set up the BIOS to send out
spin-up command to the disk(s)?
Also, the length of the cable? I know NT is known to be picky, and NT
(and for that matter any multi-tasking OSs including OS/2, Solaris,
etc.) is likely to find fault with poor quaility hardware component,
But some linux drivers may be MORE PICKY than NT drivers.
(I know that NCR8xxx and BusLogic drivers tune the performance so
well, they offer options to slow things down a little bit if the user
experience problems.)
Oh, just one more thing. Have you tried to blacklist the disk so
that the non-zero LUN probe is not performed on the disk? Among my
disk, the Quantum Empire 1GB disk caused a problem when the non-0 LUN
probe is done against the unit. It would lock the bus. So I
blacklisted it in my copy of the linux source and now don't see the
problem any more. I am writing this on a Sun box, but the file in
question is scsi.c if I recall correctly.
I might have done something similar for a Samsung
SCSI disk, too. (This becomes relevant if you enable multi-LUN
support, which may be ON by default in the recent kernel.) It just
might cure the problem.
In any case, I hope your woe would be over in the not so distant future.
Regards,
Chiaki
>>>>> "Charles" == Charles Galpin <[EMAIL PROTECTED]> writes:
>> My guess is that there must be a cable (use quality cable and
>> don't go over maximum spec length) and terminator (use active)
problem of
>> some sort.
Charles> I bought and tried another cable, with no improvement. At $32 a
pop, I'm not
Charles> inclined to try another. I have an active terminator on the
cable. I have
Charles> not idea if this can be tested independantly. Again, it works
under NT,
Charles> which is supposedly very picky about such things.
>> Or it could be that the disk in question can't go run faster as the
>> poster suggested. Have you checked the spec of the disk at the
>> vendor's site? That SCSI-II LVD can go as fast as the max speed of
>> the standard doesn't necessarily mean that all the disks that are
>> hooked up can go at that speed.
>> However, if the SCSI card has a tough time
>> negotiating the transfer speed initially, it certainly is a problem,
>> but such problems are not unheard of.
Charles> Yup, this bad boy is claimed to be able to do 80mb/s (burst I
guess)
Charles> http://www.storage.ibm.com/hardsoft/diskdrdl/ultra/9esdata.htm
Charles> charles
--
Ishikawa, Chiaki [EMAIL PROTECTED] or
(family name, given name) [EMAIL PROTECTED]
Personal Media Corp. ** Remove .NoSpam at the end before use **
Shinagawa, Tokyo, Japan 142-0051
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
