Messages in this thread | | | Date | Sat, 16 Nov 1996 14:23:26 -0800 | From | "Leonard N. Zubkoff" <> | Subject | Re: 2.0.0/2.0.25 oopses with buslogic 956C and two 4G seagates ... |
| |
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
| |