*BSD News Article 60837


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.bhp.com.au!mel.dit.csiro.au!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!Germany.EU.net!Dortmund.Germany.EU.net!nntp.gmd.de!news.rwth-aachen.de!news.rhrz.uni-bonn.de!RRZ.Uni-Koeln.DE!zpr.uni-koeln.de!se
From: se@ZPR.Uni-Koeln.DE (Stefan Esser)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Two 946Cs sharing IRQ 11 revisited
Date: 30 Jan 1996 21:04:10 GMT
Organization: Institute for Mathematics, University of Cologne, Germany
Lines: 106
Sender: se@Sysiphos (Stefan Esser)
Message-ID: <4em14a$bji@news.rrz.uni-koeln.de>
References: <DLzF99.Fr6@wlbr.iipo.gtegsc.com>
NNTP-Posting-Host: sysiphos.mi.uni-koeln.de
To: sms@wlv.iipo.gtegsc.com (Steven M. Schultz)

In article <DLzF99.Fr6@wlbr.iipo.gtegsc.com>, sms@wlv.iipo.gtegsc.com (Steven M. Schultz) writes:
|> > From: se@ZPR.Uni-Koeln.DE (Stefan Esser)

|> > The 946C was only detected as an ISA device 
|> > in 2.0.5. In 2.1R it has become a Plug'n'Play
|> > PCI device (i.e. you won't have to specify an
|> > IRQ in the kernel config file, the IRQ assigned
|> > to the PCI slot will automatically be used.).
|> > 
|> > 
|> > Just try 2.1R, it ought to have got it right :)

Well, I was overly optimistic ...

Should have said: Try 2.1-STABLE ...
But see below.

|> 	Alas, I have to report that apparently that is not the case.  It's
|> 	quite possible I've messed up and overlooked the magic config file 
|> 	phraseology but there didn't appear to be anything special needed.
|> 
|> 	Over this last weekend I bought the Walnut Creek FreeBSD 2.1 CD and
|> 	installed it tonight.
|> 
|> 	The Buslogic 946C is apparently not being detected as a PCI
|> 	device.  The PCI probing logic does report two entries with
|> 	"Buslogic" but both have "[no driver assigned]".

Yes, this is right as of 2.1R. I've checked this,
and it seems that only in FreeBSD-current, there 
is actually PCI support for that card.

This doesn't mean that the PCI version won't work,
it is just taken for an ISA card ...

Well, just looked into the CVS repository, and it 
seems that the bt controller is supported as a PCI
device in both FreeBSD-stable (i.e. 2.1R with a few
more patches) and FreeBSD-current, but was not in
2.1R ... 

Sorry for the misinformation!

I knew it was in stable, and had assumed it had 
already been in 2.1R without really checking ...

|> 	I did try leaving off all other information in the kernel config
|> 	file lines:
|> 
|> 		controller bt0
|> 		controller bt1
|> 
|> 	but that caused the kernel to skip completely the two 946C cards.

That ought to work in FreeBSD-stable ...

You most probably can easily merge in the new
bt driver code from -stable. Ask again, if you
need instructions.

|> 	Entries of the form:
|> 
|> controller      bt0     at isa? port "IO_BT0" bio irq ? vector btintr
|> controller      bt1     at isa? port "0x334" bio irq ? vector btintr
|> 
|> 	produce a "conflict" on IRQ11 and the second one is not probed at
|> 	all.  But at least the devices on the first SCSI chain are useable.

Yes, in 2.1R they are treated as ISA devices,
and don't support shared interruts, then.

|> 	Entries of the form:
|> 
|> controller      bt0     at isa? port "IO_BT0" bio irq ? vector btintr
|> controller      bt1     at isa? port "0x334" bio conflicts irq ? vector btintr
|> 
|> 	cause a successful probe of both SCSI chains (finding all devices), 
|> 	but the system hangs when accessing the devices later because ISA 
|> 	devices can't share IRQs.

True. The first driver registers its handler,
the second driver overwrites the jump vector
with its own handler's address, and the first
handler will never be called :(

|> 	Is there a limitation on which devices are probed for in the PCI
|> 	space?  "ncr0", "de0" and so on are the only ones listed in the
|> 	"LINT" (sample) configure file - perhaps the 'bt' driver isn't
|> 	PCI aware?  Would seem likely judging from what I'm seeing.

Yes. In 2.1R, it wasn't PCI aware ...

I'm really not surem whether the BT946C card
supports level triggered interrupts, which are 
a requirement for shared PCI interrupts.

But it should not be too much work to port the 
driver from 2.1-STABLE back to 2.1-RELEASE.


Regards, STefan
-- 
 Stefan Esser, Zentrum fuer Paralleles Rechnen		Tel:	+49 221 4706021
 Universitaet zu Koeln, Weyertal 80, 50931 Koeln	FAX:	+49 221 4705160
 ==============================================================================
 http://www.zpr.uni-koeln.de/~se			  <se@ZPR.Uni-Koeln.DE>