PCI card unrecognized
Vikram Ragukumar
I have a PMC module that sits on a PCI-PMC adapter (adapter has some bus
switches). I find that when the PCI card is plugged into one slot (slot 4)
on the Motherboard the card is recognized by the "lspci" command under
linux, however if the PCI card is plugged into another slot (slot 6, using
same adapter as before) "lspci" does not recognize the PCI card.
I have also found that if i transfer the PMC module to an adapter from an
alternate vendor, the PCI card is now recognized in slot 6 also.
What are the "primary" factors that could be causing this behavior ? Are
there any key signals that have to be checked for signal integrity ? I have
probed the board for IDSEL and it seems to be alright...
Any help will be appreciated.
Thanks in advance...
MM
sometimes things don't work, especially at clock rates higher than 33 MHz.
Also, if there are PCI-to-PCI bridges between the slots or on the adapter
itself, there might be issues with resources not being properly assigned to
the card by either BIOS or OS. Finally, PMC connectors are just not very
good connectors, and I've seen more than a few cases where cleaning them
with some contact cleaner resolved a problem.
/Mikhail
"Vikram Ragukumar" <vragu...@signalogic.com> wrote in message
news:Hu6dnauQqd1lVpfW...@giganews.com...
Vikram Ragukumar
To clarify, we have found that this adpater("bad adapter") works well in
several other servers. We are facing issues with a single slot on a single
server.
On examining further, we found that when the card is plugged into slot 6,
there is no clock signal. However, while using a different adapter, clock
signal is visible on the scope. PCI Slot 4 works perfectly with the "bad
adapter".
What does the PCI enumeration process look for so that it can quickly
(within very few cycles) decide if a device is present or not in a PCI slot
? Is there a register that we can access to force clock to be enabled to a
particular PCI slot ?
Thanks,
Vikram.
---------------------------------------
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com
Vikram Ragukumar
To clarify, we have found that this adpater("bad adapter") works well in
several other servers. We are facing issues with a single slot on a single
server.
On examining further, we found that when the card is plugged into slot 6,
there is no clock signal. However, while using a different adapter, clock
signal is visible on the scope. PCI Slot 4 works perfectly with the "bad
adapter".
What does the PCI enumeration process look for so that it can quickly
(within very few cycles) decide if a device is present or not in a PCI slot
? Is there a register that we can access to force clock to be enabled to a
particular PCI slot ?
Thanks,
Vikram.
>This kind of adapters violates PCI spec in several ways, resulting in that
Peter Van Epp
>Hello,
>Thanks in advance...
On an FPGA web site recently I found a link to an open source PCI
enumerating program and thought I had marked where to get it. Of course I
can't now find the reference :-). With luck someone else here will know of
the program and provide a reference (or I may yet find where I noted it ...)
Peter Van Epp
Vikram Ragukumar
vacant ? Is there something bad that is happening to one of these important
signals that causes the BIOS to think that the PCI card is non-existant ?
Thanks...
John Adair
there are 2 presence lines that can indicate a card is there and give
some other information about the card. Not all formats of PCI have
this capability and some Bios's don't use them either even if there.
The other way is straightforward try the slot approach where a cycle
is attempted to see if there is a response.
IDSEL lines are usually derived off one of the upper address lines.
The config commands are used in conjuction with a given IDSEL to
select up a card for configuration.
Some of PCI timings are very tight even at 33MHz and adding either
track length or capacitence can mean you don't meet timing.
John Adair
Enterpoint Ltd.
On 23 Nov, 21:53, "Vikram Ragukumar" <vraguku...@signalogic.com>
wrote:
> Thank you Mikhail.
>
> To clarify, we have found that this adpater("bad adapter") works well in
> several other servers. We are facing issues with a single slot on a single
> server.
>
> On examining further, we found that when the card is plugged into slot 6,
> there is no clock signal. However, while using a different adapter, clock
> signal is visible on the scope. PCI Slot 4 works perfectly with the "bad
> adapter".
>
> What does the PCI enumeration process look for so that it can quickly
> (within very few cycles) decide if a device is present or not in a PCI slot
> ? Is there a register that we can access to force clock to be enabled to a
> particular PCI slot ?
>
> Thanks,
> Vikram.
>
>
>
>
>
> >This kind of adapters violates PCI spec in several ways, resulting in that
> >sometimes things don't work, especially at clock rates higher than 33 MHz.
> >Also, if there are PCI-to-PCI bridges between the slots or on the adapter
> >itself, there might be issues with resources not being properly assigned
> to
> >the card by either BIOS or OS. Finally, PMC connectors are just not very
> >good connectors, and I've seen more than a few cases where cleaning them
> >with some contact cleaner resolved a problem.
>
> >/Mikhail
>
> >"Vikram Ragukumar" <vraguku...@signalogic.com> wrote in message
MM
>
> What does the PCI enumeration process look for so that it can quickly
> (within very few cycles) decide if a device is present or not in a PCI
> slot
> ? Is there a register that we can access to force clock to be enabled to a
> particular PCI slot ?
>
The system is supposed read the device's configuration space using special
configuration read cycles. I am not sure why different adapters would behave
differently, but if your PCI interface is implemented in an FPGA (I am
guessing since you are posting in comp.arch.fpga), it might be simply not
ready by the time the system is trying to read it... This is a well-known
problem with FPGA PCI implementation. I believe the fix is to somehow delay
the PCI bus polling at the boot time.
Another possible reason for not enabling the slot is if the system cannot
allocate enough resources (usually memory or IO space is the problem) to the
card. The card might be requesting too much or a PCI-to-PCI bridge if
present might have too small a window...
You could also check the CMOS settings for the system to see if there is
something PCI related that you can disable... I believe choosing Plug&Play
OS forces OS to assign PCI resources instead of BIOS. Sometimes disabling
this feature helps...
Sorry, it's been a while since I was actively involved in PCI development,
so my memory is a little rusty...
/Mikhail
Peter Van Epp
<snip>
> On an FPGA web site recently I found a link to an open source PCI
>enumerating program and thought I had marked where to get it. Of course I
>can't now find the reference :-). With luck someone else here will know of
>the program and provide a reference (or I may yet find where I noted it ...)
Found the site:
http://members.datafast.net.au/dft0802/
while I haven't gotten far enough yet to need to use it it may help you. As
well in the documentation that came with my Dragon board there is some advise
on PCI problems:
http://www.knjn.com/docs/KNJN%20PCI%20Dragon%20board.pdf
section 6.4 which describes the clock signal being disabled by BIOS when
there is no PCI configuration space implemented. The no clock signal sounds
like what you have. Hope one of these helps :-)
Peter Van Epp
Peter Van Epp