🚀 go-pugleaf

In article <Dn92LB.Cn@daneb.ping.de> mueller@daneb.ping.de (Andreas Mueller) writes:

  I'm considering to buy the BT946C SCSI card for an ASUS TP4XE board. The
  Linux SCSI Howto mentions a good driver stability because of its mailbox
  communication principle. However, a reliable german computer magazine tested
  this card and experienced several PCI incompatibilities (C't 1/95). It was
  not possible to correctly set up this card in a Plato board.
  Has the situation changed?  Maybe someone is using a BT946C with an ASUS
  board. Suggestions for other SCSI cards are also welcome.

1/95 was a long time ago and those problems should be long passed now.  The
present revision BT-946C should have no problems in a Plug & Play compliant
motherboard.  At one time I tested four of them together in a TP4XE board
and it seemed to work fine.

		Leonard

In article <Dn92LB.Cn@daneb.ping.de>, mueller@daneb.ping.de (Andreas Mueller) writes:
> I'm considering to buy the BT946C SCSI card for an ASUS TP4XE board. The
> Linux SCSI Howto mentions a good driver stability because of its mailbox
> communication principle. However, a reliable german computer magazine tested
> this card and experienced several PCI incompatibilities (C't 1/95). It was
> not possible to correctly set up this card in a Plato board.
> Has the situation changed?  Maybe someone is using a BT946C with an ASUS
> board. Suggestions for other SCSI cards are also welcome.

  I've been using BT946C's in Plato boards since Rev. A of the BT946C and
BIOS 8 on the Plato. I've never had any trouble (in fact, I've run 2 BT946C's
in a Plato). Early BT946C's (Rev A) didn't get along with the Plato's PCI
autoconfigure. There was a lot of fingerpointing, with both sides claiming
the other violated the PCI spec. The easy solution was to set a BIOS address
on the BusLogic card (there are 2 jumpers there for the purpose) instead of
using PCI autoconfig. Somewhere along the line BusLogic updated their card
(it's now at Rev. F) and they now work fine in the Plato even with PCI auto-
config enabled. (BTW, later BT946C revs like E05 and F don't have a "classic"
BIOS on them - they only present the BIOS using PCI autoconfig).

	Terry Kennedy		  Operations Manager, Academic Computing
	terry@spcvxa.spc.edu	  St. Peter's College, Jersey City, NJ USA
        +1 201 915 9381 (voice)   +1 201 435-3662 (FAX)

Leonard N. Zubkoff (lnz@dandelion.com) wrote:
: In article <Dn92LB.Cn@daneb.ping.de> mueller@daneb.ping.de (Andreas Mueller) writes:

:   I'm considering to buy the BT946C SCSI card for an ASUS TP4XE board. The
:   Linux SCSI Howto mentions a good driver stability because of its mailbox
:   communication principle. However, a reliable german computer magazine tested
:   this card and experienced several PCI incompatibilities (C't 1/95). It was
:   not possible to correctly set up this card in a Plato board.
                                             ^^^^^^^^^^^^^^^^^^
:   Has the situation changed?  Maybe someone is using a BT946C with an ASUS
:   board. Suggestions for other SCSI cards are also welcome.

: 1/95 was a long time ago and those problems should be long passed now.  The
: present revision BT-946C should have no problems in a Plug & Play compliant
: motherboard.  At one time I tested four of them together in a TP4XE board
: and it seemed to work fine.

: 		Leonard

I just wanted to say that I used my BT946C in an Intel Plato motherboard with no
problems (I'm now using the card in an Endeavour). I can thoroughly recommend the
BT946C - mine has proved totally reliable, and Leonard's BusLogic device driver is
very robust and fast (thanks Leonard ;-). I currently have two discs, a CDROM, and
a HP DAT drive connected to the card...

In addition, I'm also very pleased with the technical support at BusLogic. When I
bought the card early last year it had an older BIOS version that was causing a
problem with tagged queueing. Both Leonard and techsup@buslogic.com were very
helpful, and BusLogic sent me the upgrade ROM chips free of charge.

Regards,
--
Julian Thompson (jrt@miel.demon.co.uk)

Andreas Mueller (mueller@daneb.ping.de) wrote:
: I'm considering to buy the BT946C SCSI card for an ASUS TP4XE board. The

I have _exactly_ this config and it works nicely.

fyi,


-- 
Bryan Levin
<a href="http://www.hal.com/services/juggle/home/blevin@netcom.com"> BL </a>

Leonard N. Zubkoff (lnz@dandelion.com) wrote:
: In article <Dn92LB.Cn@daneb.ping.de> mueller@daneb.ping.de (Andreas Mueller) writes:
: 
:   I'm considering to buy the BT946C SCSI card for an ASUS TP4XE board. The
:   Linux SCSI Howto mentions a good driver stability because of its mailbox
:   communication principle. However, a reliable german computer magazine tested
:   this card and experienced several PCI incompatibilities (C't 1/95). It was
:   not possible to correctly set up this card in a Plato board.
:   Has the situation changed?  Maybe someone is using a BT946C with an ASUS
:   board. Suggestions for other SCSI cards are also welcome.
: 
: 1/95 was a long time ago and those problems should be long passed now.  The
: present revision BT-946C should have no problems in a Plug & Play compliant
: motherboard.  At one time I tested four of them together in a TP4XE board
: and it seemed to work fine.


I have found that some boards are still not fully compatible with the 
BT-946C.  I was running on a PCI 486 board when I first purchased my 
BT-946C, and found that there were some incompatibilities between the 
board and the controller.  The board claimed that it was PCI 2.0, and 
Buslogic Tech Support said that it should work with my Firmware revision, 
but still a no-go.  I upgraded to a Pentium TRITON based motherboard, 
with PCI 2.10, and had no problems installing it.  (Just ensure that you 
set the IRQ for the slot in BIOS, and I think you have to put it in slot 
1, or your BusMaster slot for it to work correctly-- The BT-946C touches 
on BIOS problems with using UNIX.  You can make LILO load all the way up 
to the point where it attempts to first mount your root partition, and 
then it fails because it tries to take the controller out of BIOS's control.)

I am currently using this drive to power a USENET news server with a 5GB 
RAID-0 array using the MD Software RAID drivers.  Works REALLY REALLY well.

=-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-=
     Justin H. Scott - Network Administrator - DFW Internet Services, Inc
    Any opinions stated in the above message are mine, and not those of my
                 employers.  They wouldn't want them anyhow...
                      "Now, where did I put that LART?"
=-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-==-=

In <Dn92LB.Cn@daneb.ping.de>, mueller@daneb.ping.de (Andreas Mueller) writes:
>I'm considering to buy the BT946C SCSI card for an ASUS TP4XE board. The
>Linux SCSI Howto mentions a good driver stability because of its mailbox
>communication principle. However, a reliable german computer magazine tested
>this card and experienced several PCI incompatibilities (C't 1/95). It was
>not possible to correctly set up this card in a Plato board.
>Has the situation changed?  Maybe someone is using a BT946C with an ASUS
>board. Suggestions for other SCSI cards are also welcome.
>
>Thanks for your help.

The same card was tested again in c't 8/95 and there were no more PCI
incompatibilities. Performance results were the same as in c't 1/95.

Christian

christian.thill@ci.educ.lu wrote:
> 
> In <Dn92LB.Cn@daneb.ping.de>, mueller@daneb.ping.de (Andreas Mueller) writes:
> >I'm considering to buy the BT946C SCSI card for an ASUS TP4XE board. The
> >Linux SCSI Howto mentions a good driver stability because of its mailbox
> >communication principle. However, a reliable german computer magazine tested
> >this card and experienced several PCI incompatibilities (C't 1/95). It was
> >not possible to correctly set up this card in a Plato board.
> >Has the situation changed?  Maybe someone is using a BT946C with an ASUS
> >board. Suggestions for other SCSI cards are also welcome.
> >
> >Thanks for your help.
> 
> The same card was tested again in c't 8/95 and there were no more PCI
> incompatibilities. Performance results were the same as in c't 1/95.
> 
> Christian


Odd, we bought a Buslogic 946C in 1/95 and used it with a Plato motherboard for 12 months with no problems.  The
same board is currently in use with an ASUS TP4XE, again with no,problems.  Anyone know which firmware rev was
considered "fixed"?  I'd hate to think we've just been lucky for the last year...

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    Lee Burnside --SysAdmin-- TTU Dept. of Physics
	    tljlb@tomserver.phys.ttu.edu
      Physics Homepage: http://www.phys.ttu.edu/
       University Hoempage: http://www.ttu.edu/
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   So long as men can breathe, or eyes can see, 
   So long lives this, and this gives life to thee. 
		--The Bard
   Inna Gadda Da Vida, Baby.
		--Iron Butterfly

I know that on some DOS-based PCI Pentiums, rev C of the BT946C has
problems; revs D, E & F are supposedly o.k.


-- 
   __________sss k k  y  y  w   w  eee    a       sss eee  l __________
   _________ss   kk    yy    www   ee    aaa     ss   ee   l  _________
   _______sss    k k   y     w w   eee  a   a  sss    eee  llll________
             duncan@skypoint.com||||||skyweasel@skypoint.com

In article <4hslfi$90m@mirage.skypoint.com> duncan@skypoint.com (Earl Baker) writes:

  I know that on some DOS-based PCI Pentiums, rev C of the BT946C has
  problems; revs D, E & F are supposedly o.k.

Actually, I believe revs C - F are all identical in their PCI compatibility
assuming they have the latest firmware.  The Rev C card had SCSI problems
with a few devices.

		Leonard

Leonard N. Zubkoff wrote:
> 
>   I know that on some DOS-based PCI Pentiums, rev C of the BT946C has
>   problems; revs D, E & F are supposedly o.k.
> 
> Actually, I believe revs C - F are all identical in their PCI compatibility
> assuming they have the latest firmware.  The Rev C card had SCSI problems
> with a few devices.

I wasn't even aware that there was an F revision of the BT946C. Any idea what was 
changed on that from the E to the F revision?
-- 
--==Steve==--

shoke@baldcom.net
steven_hoke@msn.com

In article <31421F46.3AFC@baldcom.net> Steven Hoke <shoke@baldcom.net> writes:

>Leonard N. Zubkoff wrote:
>> 
>>   I know that on some DOS-based PCI Pentiums, rev C of the BT946C has
>>   problems; revs D, E & F are supposedly o.k.
>> 
>> Actually, I believe revs C - F are all identical in their PCI compatibility
>> assuming they have the latest firmware.  The Rev C card had SCSI problems
>> with a few devices.
>
> I wasn't even aware that there was an F revision of the BT946C. Any idea
> what was changed on that from the E to the F revision?

They removed the third (bios) socket, which was functionally unused in Revs
C-E, and was actually left empty in D and E, when they redid the circuit
board layout.  Ever since Rev C, the bios and firmware were contained
within the odd/even firmware pair, so there wasn't any need to keep the
third socket.

Rhia

In article <31421F46.3AFC@baldcom.net> Steven Hoke <shoke@baldcom.net> writes:

  Leonard N. Zubkoff wrote:
  > 
  >   I know that on some DOS-based PCI Pentiums, rev C of the BT946C has
  >   problems; revs D, E & F are supposedly o.k.
  > 
  > Actually, I believe revs C - F are all identical in their PCI compatibility
  > assuming they have the latest firmware.  The Rev C card had SCSI problems
  > with a few devices.

  I wasn't even aware that there was an F revision of the BT946C. Any idea
  what was changed on that from the E to the F revision?

My understanding is that the only difference between the Revision E and F
cards is that one of the three firmware/BIOS sockets is no longer present
on the revision F.  It seems this chip/socket was never actually used for
anything, so it was finally removed in the latest revision.  It was left
empty on the Revision E boards I have which I think led some customers to
worry that something was missing from the board.

		Leonard

In article <4hslfi$90m@mirage.skypoint.com>,
Earl Baker <duncan@skypoint.com> wrote:
>I know that on some DOS-based PCI Pentiums, rev C of the BT946C has
>problems; revs D, E & F are supposedly o.k.

   And it's possible that the unit you have is bad; I've been
debugging a problem with a 946 where it would lock up like a
drum if I ever did DMA(*) across the bridge to the ISA bus. After
checking every possible other approach (disks?  cabling? system
board?) it became apparent that it was the 946 that was having
trouble (I have two of them side-by-side, and the DMA lockup
was following one of the cards; after I bought a third card and
swapped out the offending one, the DMA problem seems to have
stopped.)


   (* or, for that matter, anything that pumped a lot of bytes
across the ISA bridge; I was getting the lockups when I fired up X
or displayed graphic images on the console, and these lockups
ceased when I bought a PCI graphics adaptor and moved video onto
the PCI bus.)


                 ____
   david parsons \bi/ orc@pell.chi.il.us
                  \/

Leonard N. Zubkoff wrote:
 
>   I wasn't even aware that there was an F revision of the BT946C. Any idea
>   what was changed on that from the E to the F revision? 
> My understanding is that the only difference between the Revision E and F
> cards is that one of the three firmware/BIOS sockets is no longer present
> on the revision F.  It seems this chip/socket was never actually used for
> anything, so it was finally removed in the latest revision.  It was left
> empty on the Revision E boards I have which I think led some customers to
> worry that something was missing from the board.

That can't be right. I have a Rev E board, and it has all three sockets populated, 
and it arrived directly from BusLogic. I've since updated the BIOS, and they sent 
all 3 chips. There's never been an empty socket on the board. Maybe its something 
else.

-- 
--==Steve==--

shoke@baldcom.net
steven_hoke@msn.com

In article <3145A85F.59B8@baldcom.net> Steven Hoke <shoke@baldcom.net> writes:

> Leonard N. Zubkoff wrote:

>>>   I wasn't even aware that there was an F revision of the BT946C. Any idea
>>>   what was changed on that from the E to the F revision? 
>> My understanding is that the only difference between the Revision E and F
>> cards is that one of the three firmware/BIOS sockets is no longer present
>> on the revision F.  It seems this chip/socket was never actually used for
>> anything, so it was finally removed in the latest revision.  It was left
>> empty on the Revision E boards I have which I think led some customers to
>> worry that something was missing from the board.

> That can't be right. I have a Rev E board, and it has all three sockets
> populated, and it arrived directly from BusLogic. I've since updated the
> BIOS, and they sent all 3 chips. There's never been an empty socket on
> the board. Maybe its something else.

Some Rev E boards were done with a dummy bios chip early on, before they
made the decision not to provide that; also, about 6 months ago, they were
sending out the 3-chip upgrades (with the dummy bios chip).  They have
since stopped doing that except in the case where someone is upset about
not having a chip in the unused socket.

Rhia

Does anyone knows how to receive the updated ROMS for my BT946 ?

Thanks in advance !

-- 
---------------- Fuck The Monopoly ! ----------------
    ______                           ____            
   /_  __/                          / __/            
    / /__     __  __  __           / /_              
   / //_  /  /_  /   / / /\/\     /_  / /  / \/ \/   
  / //__ /_ /__ /__ /_/ /   /    __/ / /__/  /\ /\   
 /_/ Italia                     /___/                
                                                     
  655 days left to the end of telecom's monopoly     
      when this e-mail was posted.                   
                                                     
-----------------------------------------------------
 Daniele Orlandi                                     
 Via Tagliamento, 13                                 
 20030 Seveso (MI)                                   
 Italy                         FAX: ++39(2)29510943  
-----------------------------------------------------

In article <314B4F7A.381C@uli.it> Daniele Orlandi <dorlandi@uli.it> writes:

> Does anyone knows how to receive the updated ROMS for my BT946 ?

Contact BusLogic Technical Support and give them the pertinent information:
what hardware revision of the card and/or your current bios and firmware
(from the Summary of Configuration in the AutoSCSI).  They can ship the
upgrade chips to you.

Technical Support is 408-654-0760 or "techsup@buslogic.com".

Rhia

In article <4igap9$mp@kelewan.dandelion.com> "Rhia" <rhiannon@dandelion.com> writes:
>From: "Rhia" <rhiannon@dandelion.com>
>Subject: Re: PCI compatibility of BusLogic's BT946C SCSI Adapter
>Date: 16 Mar 1996 22:17:13 -0800

>In article <314B4F7A.381C@uli.it> Daniele Orlandi <dorlandi@uli.it> writes:

>> Does anyone knows how to receive the updated ROMS for my BT946 ?

>Contact BusLogic Technical Support and give them the pertinent information:
>what hardware revision of the card and/or your current bios and firmware
>(from the Summary of Configuration in the AutoSCSI).  They can ship the
>upgrade chips to you.

>Technical Support is 408-654-0760 or "techsup@buslogic.com".

>Rhia

Be aware that due to some "errors" in the chipsets on rev A-C(D?) you can't 
get these adapters PCI 2.0 compliant. Not by doing BIOS-upgrades only.
To resolve this BusLogic offered a free trade on these adapters in spring -95 
to a rev E that had upgraded chipsets. I don't know if BusLogic has still 
got this offer. 
The rev E is to my experience fully 2.0 compliant with full Plug & Prey support

Bjoernar

In article <bjornarb.267.3152CBA6@sofus.hiof.no> bjornarb@sofus.hiof.no (Bjornar Bjornerud) writes:

> Be aware that due to some "errors" in the chipsets on rev A-C(D?) you
> can't get these adapters PCI 2.0 compliant. Not by doing BIOS-upgrades
> only.  To resolve this BusLogic offered a free trade on these adapters in
> spring -95 to a rev E that had upgraded chipsets. I don't know if
> BusLogic has still got this offer.  The rev E is to my experience fully
> 2.0 compliant with full Plug & Prey support

I was informed that the Rev C is compliant, but still suffered from a
specific timing problem that was corrected in Rev D.

BusLogic's upgrade to Rev E expired at the end of 1995, as had been
announced about six months prior to that.  If you need an upgrade, you can
still talk to them about it but there will be a fee for the new card.

Rhia

bjornarb@sofus.hiof.no (Bjornar Bjornerud) wrote:
>Be aware that due to some "errors" in the chipsets on rev A-C(D?) you can't 
>get these adapters PCI 2.0 compliant. Not by doing BIOS-upgrades only.
>To resolve this BusLogic offered a free trade on these adapters in spring -95 
>to a rev E that had upgraded chipsets. I don't know if BusLogic has still 
>got this offer. 
>The rev E is to my experience fully 2.0 compliant with full Plug & Prey support

"Plug & Prey"?  - that's probably a type but...

Sometimes I feel like Prey when dealing with PnP bios & pci adapters.

"Plug & Pray"? - also appropriate...

Whenever I install a new PCI board, I never know what IRQ will get
assigned to it.  The PCI board may get an IRQ assigned to an ISA board
and then the trouble begins.  I have several Micron systems with
Phoenix BIOS and Buslogic BT946C controllers.  Three different MB
bioses - three different IRQ's assigned to the Buslogic board!
HI54M-02PM -> IRQ 11
HI54M-09PM -> IRQ 15
HI54M-10PM -> IRQ 10
Needless to say this plays havoc with system configurations with
systems like SCO unix which won't boot if there is an irq conflict.
There is no method that I have found to assign an IRQ to a specific
PCI board with Phoenix and/or Buslogic's bioses.

The reason this is a problem may not be obvious to some readers...

We had a system with a defective motherboard that failed after about 6
months.  No problem - just swap motherboards with the same
configuration - right?  Wrong!  The new motherboard had a newer bios
which chose a different IRQ for the buslogic than the earlier one
which conflicted with the network adapter and SCO paniced on boot (as
it should).  Only solution was to flash the bios back to the earlier
level to get the IRQ assigned where we had SCO configured for it.

So, the questions are:

Are there any bioses out there that let you determine resource
assignment for PCI adapters?
Is there a Buslogic bios that allows you to force the IRQ to a
specific one and is it possible with PCI?
Where is a good source of info about PCI in regard to actually
explaining how all this works and how to live with it.

Toby

PS I never had these problems with ISA boards...
Toby L. Kraft, Kraft Enterprises, Inc., Evansville. IN USA

In <4k0tnp$o66@info.evansville.net> tkraft@evansville.net (Toby L. Kraft) writes:

>Whenever I install a new PCI board, I never know what IRQ will get
>assigned to it.  The PCI board may get an IRQ assigned to an ISA board
>and then the trouble begins.  I have several Micron systems with
>Phoenix BIOS and Buslogic BT946C controllers.  Three different MB
>bioses - three different IRQ's assigned to the Buslogic board!

Every motherboard I've used has had an Award bios and they have all had
some way of assigning the IDE irq used to a specific PCI slot. Some
older boards have both bios settings and jumpers on the motherboard for
this purpose. Usually you assign an ISA interupt to one of the 4 PCI
interupts, then assign that interupt to a specific PCI slot, or at least
that's the way it appears to work.

It still usually takes me 3 or 4 times as long to set up right as it
ever did when I just jumpered the boards by hand though.

-- 
John Henders

In article <4k0tnp$o66@info.evansville.net> tkraft@evansville.net (Toby L. Kraft) writes:

> Whenever I install a new PCI board, I never know what IRQ will get
> assigned to it.  The PCI board may get an IRQ assigned to an ISA board
> and then the trouble begins.  I have several Micron systems with Phoenix
> BIOS and Buslogic BT946C controllers.  Three different MB bioses - three
> different IRQ's assigned to the Buslogic board!
> HI54M-02PM -> IRQ 11
> HI54M-09PM -> IRQ 15
> HI54M-10PM -> IRQ 10
> Needless to say this plays havoc with system configurations with systems
> like SCO unix which won't boot if there is an irq conflict.  There is no
> method that I have found to assign an IRQ to a specific PCI board with
> Phoenix and/or Buslogic's bioses.
>
> We had a system with a defective motherboard that failed after about 6
> months.  No problem - just swap motherboards with the same configuration
> - right?  Wrong!  The new motherboard had a newer bios which chose a
> different IRQ for the buslogic than the earlier one which conflicted with
> the network adapter and SCO paniced on boot (as it should).  Only
> solution was to flash the bios back to the earlier level to get the IRQ
> assigned where we had SCO configured for it.

It doesn't sound like you're using the latest SCO driver from BusLogic,
then, because it's PCI compliant and doesn't care whether the IRQ moves or
not - it'll go out and find the adapter anyway.  Versions of the driver
prior to 2.06 were not completely compliant and forced you to use 0x334h
and IRQ=11 in order to have the card recognized as a BusLogic.  You can get
the latest driver at ftp://ftp.buslogic.com/pub/current/SCO.EXE

> Are there any bioses out there that let you determine resource assignment
> for PCI adapters?

Probably, but most of the major ones do it for you, assuming you're going
to be using properly PCI compliant drivers.

> Is there a Buslogic bios that allows you to force the IRQ to a specific
> one and is it possible with PCI?

Not and still be PCI 2.0 compliant.

> Where is a good source of info about PCI in regard to actually explaining
> how all this works and how to live with it.

I'd like to know too.  :-)

> PS I never had these problems with ISA boards...

Well, they haven't made ISA "Plug & Play/Pray" yet.  Fortunately.

Rhia

In article <4k1a9l$rov@vanbc.wimsey.com> jhenders@wimsey.com (John Henders) writes:

> In <4k0tnp$o66@info.evansville.net> tkraft@evansville.net (Toby L. Kraft)
> writes:
>
>>Whenever I install a new PCI board, I never know what IRQ will get
>>assigned to it.  The PCI board may get an IRQ assigned to an ISA board
>>and then the trouble begins.  I have several Micron systems with
>>Phoenix BIOS and Buslogic BT946C controllers.  Three different MB
>>bioses - three different IRQ's assigned to the Buslogic board!
>
> Every motherboard I've used has had an Award bios and they have all had
> some way of assigning the IDE irq used to a specific PCI slot. Some older
> boards have both bios settings and jumpers on the motherboard for this
> purpose. Usually you assign an ISA interupt to one of the 4 PCI
> interupts, then assign that interupt to a specific PCI slot, or at least
> that's the way it appears to work.

IDE isn't Plug & Play.  Yet.  BusLogic's newest cards don't even use the
legacy ports unless you set a particular option - PCI compliance is moving
away from this, and configuration is becoming more and more
invisible... along with its attendant complications.

Rhia

In message <4k0tnp$o66@info.evansville.net>, tkraft@evansville.net said:

  > Are there any bioses out there that let you determine resource
  > assignment for PCI adapters? 

My AWARD Modular BIOS 4.50PG allows me to keep track of what is assigned
to what AFAICT. At least when I fitted a 2940 it assigned exactly the IRQ
I expect it to.

I've also seen BIOSs (not sure which make) which let you reserve some IRQs
for ISA cards so PCI ones won't get them automatically assigned.

:-)

Roland.

@CiX

"Rhia" <rhiannon@dandelion.com> wrote:
>In article <4k0tnp$o66@info.evansville.net> tkraft@evansville.net (Toby L. Kraft) writes:

>> Whenever I install a new PCI board, I never know what IRQ will get
>> assigned to it.  The PCI board may get an IRQ assigned to an ISA board
>> and then the trouble begins.

>It doesn't sound like you're using the latest SCO driver from BusLogic,
>then, because it's PCI compliant and doesn't care whether the IRQ moves or
>not - it'll go out and find the adapter anyway.  Versions of the driver
>prior to 2.06 were not completely compliant and forced you to use 0x334h
>and IRQ=11 in order to have the card recognized as a BusLogic.  You can get
>the latest driver at ftp://ftp.buslogic.com/pub/current/SCO.EXE

There's no problem with the BusLogic just that the reassigned IRQ
conflicts with a previously assigned IRQ on another ISA board.

>> Where is a good source of info about PCI in regard to actually explaining
>> how all this works and how to live with it.

>I'd like to know too.  :-)

Contact I have at Phoenix suggests:

PCI Special Interest Group
PO Box 14070
Portland, OR 97214
phone:	(800) 433-5177
phone:	(503) 797-4207
fax:	(503) 234-6762

but still looking for a book or downloadable FAQ &/! Spec on PCI.

>> PS I never had these problems with ISA boards...

>Well, they haven't made ISA "Plug & Play/Pray" yet.  Fortunately.

Oh yes they have - there is a ISA PnP Spec (version 1.0a dated May 5,
1994) put out by Intel and Microsoft that describes how to make ISA
boards Plug'n'Play compatible.

Toby L. Kraft, Kraft Enterprises, Inc., Evansville. IN USA