[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Resource Allocation Problem
- To: Mailing List Recipients <pci-sig-request@znyx.com>
- Subject: Resource Allocation Problem
- From: Timothy Hellman/PicTel <Timothy_Hellman@smtpnotes.pictel.com>
- Date: 9 Dec 96 10:11:26 EDT
- Resent-Date: 9 Dec 96 10:11:26 EDT
- Resent-From: pci-sig-request@znyx.com
- Resent-Message-Id: <"3yJWP2.0.xu5.7w2ho"@dart>
- Resent-Sender: pci-sig-request@znyx.com
> We are nearing production release of a PCI adapter card product. As
> with any product, we are wary of the potential flood of support calls
> we will get from customers during the installation of the board into
> their system. We want to be prepared to help them even if the
> installation problems are not related to our board specifically, but
> perhaps some other aspect of their system.
Does your product use interrupts? If so, here's what you can expect:
(I'm speaking about Windows 95 installations now - Windows 3.1
will be worse).
95% or so of your installations will be flawless (customer plugs it
in and it works). The other 5% will be a total disaster. The reason
will almost inevitably be an interrupt conflict with a non-plug & play
board. Windows 95 doesn't fix this (it can't, since the method for
performing IRQ assignment is motherboard specific),
so you'll be stuck telling the customer to swap PCI slots,
reconfigure other ISA boards and to look for obscure BIOS
solutions.
Also, if you use bus mastering you'll find a few manufacturers
who decided to totally ignore the PCI spec and implement
'slave-only' PCI slots. Fortunately these are becoming
less common.
> There could be many scenarios, but the specific problem I'm imagining
> are resource allocation problems resulting from NON-plug-and-play ISA
> cards or other legacy devices. Resource allocation goes smoothly
> until our board is installed, then the camel's back gets broken. Even
> though we intend to fully follow the PCI spec and be plug-and-play
> compliant, if the system BIOS and/or OS are unaware of the legacy
> device's resource usage, problems may occur. Since everything worked
> fine until our board was installed, guess who's going to get the call!
Yep - you can look forward to this. Wait 'till you have to explain to the
customer why they have to change the IRQ settings on their sound
card in order to get your device to work! Expect plenty of cursing.
> I have seen some system BIOS's that have setup screens which allow
> certain resources to be reserved for ISA, and I have heard of
> something called ISA Configuration Utility (I don't know if this
> exists anymore-if so, from whom?) which somehow does the same thing.
> Windows 95's Device Manager allows you to modify the resource
> assingments, but what if our customer is not using a plug-and-play OS?
You'll almost never see a problem with I/O and memory assignments.
It's IRQs that are the problem. Some BIOS's do have ways to change
the IRQ assignment, though the trend seems to be toward 'smart'
BIOS's that don't give you any manual overrides. In any case every
BIOS vendor handles this differently.
> Is there a standard way to handle this problem? It really seems to be
> a system vendor problem, but is there anything an adapter card vendor
> can do? Any suggestions would be appreciated.
No standard solution, other than to document the problem as best you
can, and to train your service people in how to identify and rectify these
sorts of problems.
These issues will be with us until we move beyond a 1970's vintage
interrupt controller subsystem on PCs.
|