Date: Wed, 8 Jan 1997 11:31:51 -0800 From: Virgil Champlin <champlin@virgil.pa.dec.com> To: dgy@rtd.com Cc: dwhite@resnet.uoregon.edu, freebsd-questions@FreeBSD.ORG, champlin@pa.dec.com Subject: Re: Two AHA1542CF scsi controllers on 2.1.5-RELEASE Message-ID: <9701081931.AA18307@virgil.pa.dec.com> In-Reply-To: <199701081834.LAA19663@seagull.rtd.com> (message from Don Yuniskis on Wed, 8 Jan 1997 11:34:27 -0700 (MST))
next in thread | previous in thread | raw e-mail | index | archive | help
>>The "settings" also include IRQ and DRQ -- if these aren't disjoint, >>I suspect you'll see much the same symptoms... Sorry, I wasn't clear. The cards have disjoint settings (ctlr0 = iob330/irq11/drq6 and ctlr1 = iob334/irq10/drq7) and this was verified when the driver probed them. Since the probe for ctlr0 (iob330/irq11/drq6) worked and ctlr1 (iob334/irq10/drq7) didn't, I simply swapped the cards base addresses (iob330 and iob334) to see if there were any possible conflicts with irq10/drq7. Apparently not since the probe reported iob330/irq10/drq7 as successful and iob334/irq11/drq6 now had the timeout symptoms. I could still have a conflict with iob334 but I can't find one (no hidden bustek 742 controller :-)) and the ctrl activity light on the failing "aha" does respond during probe time. Just not as long as the successful one. My conclusion was that I didn't understand the scsi kernel configuration well enough but I guess I should actually swap the iob definitions of "aha0" and "aha1" in the configuration file to completely rule out an iob334 conflict. Thanks much for the response. -virgil
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9701081931.AA18307>