"A month of sundays ago Leonard N. Zubkoff wrote:"
>
> reason is that when the driver determines the PCI I/O Port from the PCI BIOS,
> it then commands the card to disable the ISA Compatible I/O Port, partly to
> avoid recognizing the same card twice, and partly to avoid unnecessary
> conflicts with other devices. If PCI BIOS support is not available, then the
> driver will only recognize the ISA Compatible I/O Port and you'd see 0x330 in
> the driver's startup messages.
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.
(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)
> FDC 0 is a post-1991 82077
> scsi0: Configuring Buslogic Model BT956C PCI Wide SCSI Host Adapter
> Firmware Version: 4.28A, I/O Address: 0x6000, IRQ Channel: 11/Level
>
> Note the I/O Address is listed as 0x6000 here, not 0x330.
:-) Simply a misunderstanding on our joint parts!
> scsi0: CCB #0 to Target 0 Impossible State
>
> Here's the real problem. This message indicates that the Completion Code field
> of the CCB (Command Control Block) has a value that is impossible based on the
> control flow of the driver. This pretty much indicates that something trashed
> the CCB data structure, which also explains the OOPS that follows. No doubt
> CCB->Command is invalid, and so the access to Command->scsi_done faults. Why
> this should be occurring I have no idea. It may well be hardware.
Agreed. I walked in this morning to find the machine keeled over and wailing.
During the night FreeBSD had crashed. Probably I twiddled enough bits in the
CMOS to let it notice somethingf is up. I spent the day looking it over ...
> Nope it's not there. Sorry - I can't do any better than this. I hope you can
> match the assembler some other way.
>
> Excellent point. I hadn't thought of that. I've now made the corresponding
> System.map file available and placed a link on the web page. The fault occurs
> near the end of BusLogic_ProcessCompletedCCBs as I expected.
Thanks!
> I notice a couple of things from the FreeBSD messages. First, you seem to have
> a UMC chipset. I don't know much about this particular UMC chipset in detail,
> but my general experiences with UMC have not been good. You could try a Linux
> kernel without PCI BIOS support and see if that helps; it would more closely
> model the behavior of the FreeBSD driver, since it seems to know nothing of
> PCI.
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.
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.
> Well, if the machine is now dead to FreeBSD, then I suspect that you have a
> hardware failure which just happened to manifest itself first on Linux.
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.
> Since it was dead, I opened up the box and took it apart. It looks to
> me as if the seagates (ST15230W) have no jumpers of any sort on, which
> according to the "manual", means that they are both terminated? But who
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.
Both were jumpered with the correct IDs, however.
> My driver reported that SCSI termination was enabled for both the high and low
> bytes. Termination should also be enabled for drive 1, according to your
> description. The host adapter is not auto-terminated. The BT-956C termination
> is enabled/disabled using the AutoSCSI utility; the newer BT-958 does have
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.
> automatic smart termination. There must be jumpers somewhere on those drives
> to set the target IDs; they cannot tell by position. The Seagate Web Site
OK. I found them. They are OK. No jumper means ID 0. Jumper in posiion one
means ID 1. I have that.
> If termination is not set correctly, it might well be possible that FreeBSD
> would function and Linux would not. FreeBSD has no support for tagged queuing,
> so it will never have more than one command outstanding to the drive at a time.
> The Linux driver supports tagged queuing which allows for much higher
> performance, but that also makes an incorrectly implemented or marginal SCSI
> bus more problematic.
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.
> Try the usual experiments to determine why your hardware is dead, swapping
> components out, etc. The beeps at startup may tell you which component is ill;
> consult the motherboard manual for more information on that.
Manual :-) Oh yeah, all the 25 different boxes here probably have a
manual ... sitting on the vendors shelves. 25 copies of MSDOS I can
sell you, yet, unopened :-. Those, we have.
Thank you again.
Peter T. Breuer
,---------------------------------------------------------------------------
|Departamento de Ingenieria de Sistemas Telematicos, Universidad Politecnica
|de Madrid, Escuela Tecnica Superior de Ingenieros de Telecomunicacion,
|Ciudad Universitaria, E--28040 Madrid, SPAIN.
|Tel. Office : +34 (1)336 6831
| Fax : +34 (1)543 2077 or 336 7333
|Internet : <ptb@eng.cam.ac.uk, ptb@comlab.ox.ac.uk, ptb@dit.upm.es>
| URL : http://www.dit.upm.es:80/~ptb/
`---------------------------------------------------------------------------