[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Slot number in Desk-top - huh?
Bus#, Device#, Func# has never been an issue.
However the "Slot #", e.g. the slot label is not
readable through any standard hardware mechanism.
e.g. the slot label is just the silk screen information
that labels a slot as "SLOT 1" or "Ref U32" or "SLOT A",
or "SLOT A1", etc, etc.
The slot label information can only be obtained from BIOS
tables, because on the BIOS is custom to the motherboard and
hence can contain the silk screen info.
Windows 9x happened to define their IRQ table table (which
also has to define information only by BIOS, e.g. IRQ routing)
in this same table. [I had thought they used a string value,
but they did not, they allowed only an integer value....]
So they assume that a platform will label its slots as
1,2,3,4,5. The value 0 is reserved for slotless onboard
devices, so that value can't be used for a PCI slot. Actually,
you could use any integers you want: So
for instance if you had two peer busses you might want to
do something like: 11,12,13,14,15 and 21,22,23,24,25 to
represent slots 1-5 on physical connector busses 1 & 2.
These slot labelings have NOTHING to do with the actual
PCI bus number and PCI DEVICE number of the slot.
For instance Slot ID 11 (Phys Bus 1, Slot 1 in my example)
might actually have Bus 4 and Device ID 7 depending on how
the board is layed out.
Software often reports that Bus X and Device Y has an error,
but rarely actually gives useful information such as what physical
slot label that device is in. Since the logical addressable Bus X,
and DEVICE Y have no predefined spec based relationship to what SLOT
connector that Bus X and Device Y is actually in.
To give a practical example: On large machine (or even small ones)
folks can put in 3 Adaptec SCSI adapters, or 3 Intel LAN NIC's. Then
for some reason an error is reported. Its Bus X & Dev Y on an "Intel LAN".
The end user sees that and says to himself, "well which one is it...."
which of the three is having the error. Having the Bus#Device# isn't
very useful. What s/he wants to know is what connector has the problem
The Windows 9x IRQ table provides this information. Some OEM's use
proprietary information storage in the SMBIOS structures as well to solve
this same information. ACPI provides a "string value" that can be
associated with a connector description.
At this time the Win9x table is the most prevelently read by boot loaders
and supplied to OS. (Because most single CPU OS kernals use this for IRQ
mapping, so they get the info on slots as well.) However it appears that
few or zero OS actually make the slot information available to drivers, which
is a shame. [A shame, but understandable, since the Win9x table is not part
of the PCI spec, its just a spec that MS wrote.]
From: Henry Gong [mailto:email@example.com]
Sent: Wednesday, January 08, 2003 3:04 PM
To: Mike Dini
Subject: Re: Slot number in Desk-top - huh?
I do not quite understand this issue. If what you said is true, why so many
software can find all PCI boards and corresponding bus number, slot number and
function number, for instance PCIVIEW and Unix command lspci? I do not know
how they do it. But they really can.
However, physically, PCI slots can be numbered in either direction. The slot 1
could be any of two side slots.
Mike Dini wrote:
> I'm confused as to how the original question deviated into the IRQ's,
> unless I misunderstood the original question. I thought Dinesh asked the
> following question (paraphrasing):
> I have a board plug into PCI/PCIX/ et al.
> How does the driver determine the physical
> location of that board?
> My private answer to him went as follows:
> You can't. This is a fundamental problem with PCI and it is a problem we
> have all the time. On a PCI bus, you can figure what board is plugged in,
> but it is impossible to determine which physical slot the board is plugged
> into. This is all PCI, not just Sun. This can be quite troublesome if you
> put two of the same boards into a system and, for example, they get cabled
> differently to something external.
> The only way to solve this is to put a DIP switch on the PWB or add some
> sort of an ID to the circuit. Upon installation, the user (or other) must
> tell the driver which of these ID's in connected to which function.
> Now I state again in clearer prose: Across platforms, it is impossible in
> PCI to correctly determine the physical location of a PCI resource without
> some external intervention.
> >| Hi Experts,
> >| I have a basic qry.
> >| In a desk-top environment, is there a mechanism to find out which
> >| PCI card/resource is plugged in to which slot ? In other words, is
> >| it possible in OS level to read slot number of a particular PCI
> >| card plugged in to a desk-top ? Assume the machine is running in
> >| Solaris/Linux.
> >| Any one experienced similar problems ?
> >| Thanks in advance
> >| Dinesh