Rob Browning (rlb@cs.utexas.edu)
18 Sep 1999 18:21:37 -0500
Looking in the archives, I saw that Mark posted that for recalcitrant
IBM drives, you could use
linux ncr53c8xx=disc:n
to disable disconnects and get them to work. For me this option
didn't help. However, I've had problems with these drives in the past
on x86 machines. During the process of debugging that I spoke with
the people on the Adaptec driver list and they mentioned that some of
these drives advertise that they support tagged command queueing in
their "drive info page", but they really don't, so when the driver
tries to use tagged command queueing, things go haywire.
The permanent solution was to use scsiinfo (or whichever command it is
that lets you edit the drive's parameter page -- it's a Tk app as I
recall), to tell the drive to quit advertising that option. Another
possibility (but not good for long term since you may move the drive)
is to tell the driver not to use tagged command queueing on that
drive. That can be accomplished with this boot command option:
linux ncr53c8xx=tags:8/t3q0
This will (I think) tell the driver to use 8 as the default number of
commands (which is the normal default), and to use 0 on drive id 3 on
the first controller. (See ./Documentation/Configure.help in the
kernel tree for more info.)
I haven't tested this particular command, though. In my case, I just
sledgehammered it until I can get the drive fixed with
linux ncr53c8xx=tags:0
which disables tagged command queueing globally.
(For those who saw my earlier post, the machine works fine with all
the RAM once it's installed. It was just initrd that was failing when
the machine had too much ram.)
-- Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
This archive was generated by hypermail 2.0b3 on Sat Sep 18 1999 - 23:23:36 GMT