[948] in linux-scsi channel archive
Re: 2.0.0/2.0.25 oopses with buslogic 956C and two 4G seagates ...
daemon@ATHENA.MIT.EDU (Leonard N. Zubkoff)
Sat Nov 16 17:41:13 1996
Date: Sat, 16 Nov 1996 14:23:26 -0800
From: "Leonard N. Zubkoff" <lnz@dandelion.com>
To: ptb@dit.upm.es
CC: ptb@dit.upm.es, linux-scsi@vger.rutgers.edu, linux-kernel@vger.rutgers.edu,
ptb@oboe.it.uc3m.es
In-reply-to: <199611162038.UAA08341@oboe.it.uc3m.es> (ptb@oboe.it.uc3m.es)
From: "Peter T. Breuer" <ptb@oboe.it.uc3m.es>
Date: Sat, 16 Nov 1996 20:38:37 +0000 (WET)
Hi Leonard. Thank you very much for taking the time to respond. I really
appreciate it!
No problem.
Uh huh. As we all suspect by now, and as I wrote to Alan, the PCI bus is
probably broken on the machine. That would explain the data. I am just
compiling a non-PCI kernel with the buslogic driver in.
Indeed it would.
(Will that work as a combo? Are there no module/boot options to disable
PCI? I don't know, so I am doing some speculative branching in the
meantime in the other window)
The BusLogic driver will definitely compile with CONFIG_PCI set to NO. Until
now, I've never provided a mechanism to disable the PCI probing via command
line arguments. I've always just told people to not define CONFIG_PCI, since
if the PCI BIOS is broken, it doesn't affect just the BusLogic board. I'll
think about whether such an option would be worthwhile.
Yes. Can I disable PCI support in your supplied buslogic driver somehow?
There are some tricks I have to do to make a slackware bootdisk that I would
rather not learn.
PCI Support is automatically disabled when CONFIG_PCI is not defined. There's
not currently a mechanism to disable it from the command line as there is for
ISA probing.
I have just checked - yes, booting a kernel with no PCI support and the
buslogic driver works!! Thanks! Can we say that PCI is pretty definitely
broken on the machine? I think so.
Excellent!
I think so too. The hardware looks shoddy now that I have taken it apart. I
have managed to resusicate it, but the adapter has shifted itself to 0x334 now
(from 0x330) and the FreeBSD kernel won't pick it up again after the kernel
gets going. So I am stuck. I will pick up with the linux kernel
tomorrow and go from there.
Strange.
OK - I understand the situation better now than I did earlier. Indeed both
seagates are jumpered for termination enabled but they are in a line
with the controller at one end, so that was wrong.
Ouch. It's surprising it worked reliably at all. You were very lucky.
Both were jumpered with the correct IDs, however.
That was pretty much a given, from what FreeBSD reported.
Well - I have now removed termination on the middle drive (id 0), on the
principle that termination should occur at terminals. Was that OK?
Does it mean that I now have to disable "high" or "low" termination in
the bios? And then enable the adapter termination too.
Yes, removing termination from the middle drive was the right thing to do.
Leave the host adapter as it is, with both high and low bytes terminated. You
would only need to do one without the other if you connected one chain of wide
devices and another of narrow. In that case, the host adapter would need the
low byte disabled but the high byte enabled.
I see. I'll check how to turn off tagged queueing as an expedient - or would I
just have to set the queue to 1 or 0 as max? The latter, I suppose.
You can turn it off with "BusLogic=TQ:Disable" on the command line. Chances
are you won't need to do so, with the termination set correctly. You can also
control how aggressive the tagged queuing is by booting with "BusLogic=0,N"
where N is the number of simultaneous commands to allow. I'd try 15 or 7, but
only if you have trouble with the default (28).
Leonard
