Re: CVS commit: syssrc

[Matthew Jacob <mjacob%feral.com@localhost>]

On Thu, 6 Jul 2000, Erik E. Fair wrote:

> Two things:
> 
> 1. The Qlogic controller in question does exist; I have one, and I 
> bet that WierdStuff is still selling them for $40/ea (they still had 
> about a dozen when I was there a month ago). It has an ISP 1020 on 
> it, Qlogic board assy PC2010404-01 rev D, copyright 1994. There are 
> nothing but 50-pin SCSI connectors on it: one external, Sun-style, 
> one internal IDC header. It probes on a 1.4ZD kernel as follows:
> 
> isp0 at pci0 dev 5 function 0
> Qlogic ISP Driver, NetBSD (pci) Platform Version 0.997 Core Version 1.14
> isp0: interrupting at eb164 irq 2
> isp0: Board Revision 1020, loaded F/W Revision 4.65.0
> isp0: Last F/W revision was 5.57.1
> isp0: 243 max I/O commands supported
> isp0: driver initiated bus reset of bus 0
> scsibus0 at isp0: 16 targets, 8 luns per target

It's still a wide SCSI bus. The implementation has the upper lines tied, I
hope. What is interesting about all of this is that this implementation has
valid NVRAM. The chatty message came about from stuff set in NVRAM which said
to not touch such an area.

> 
> I'm using one in my Alpha PC164 to talk to three HP C3725S 2GB 
> Fast/Narrow SCSI disks arranged in a ccd. Aside from making any 
> single-port TULIP Ethernet board cough up blood (I've got a four-port 
> 21143/21152 board in there now; the second on-card PCI bus seems to 
> make everything happy), the Qlogic controller works pretty well.
> 
> 2. I made the change to isp.c during the period when you had "left 
> the project"

I'm always around, but I understand. The change you made was after an update
I'd had Havard do- which showed I was still maintaining.

> and I didn't expect that such a minimally invasive 
> change was going to cause any problems. I preserved the functionality 
> for anyone desiring to debug the controller interactions; I just made 
> it not spew about SCSI ID's it was "skipping" (which means all IDs 
> above 7 on this controller; it can't support ID's up there) for 
> kernels not compiled with DEBUG or SCSIDEBUG, which is a problem for 
> the controller I have. I'm slightly paranoid ("Can you prove that 
> they're _not_ out to get me?") - I always use DIAGNOSTIC kernels.

The printing/logging will change next month to something more sane.

> 
> I'm sorry if this change offended. Thank you for putting some of it back.

Thanks for being gracious. I should apologize for being tetchy. No sleep,
sorry.

-matt