Slot Number Question

Slot Number Question

[Jack Hammer]

My adapter configuration utility needs to instruct the user which physical
adapter needs attention ( when there may be multiple adapters in the system
).    My question is :  How do I determine the ( machine ) slot number of a
PCI adapter ?

In BIOS and other OS's this may be doneby examining the system's  PCI
Routing Tables.    I don't think I can get to those from Linux.

PCI Devices are defined by  BUS,  DEVICE, and FUNCTION.    In Linux there
is a function ( defined in pci.h near the end of the file ) called   "
PCI_SLOT( devfn ) "   but from what I can see this returns what PCI calls
the device.   PCI device is not the machine's slot number.   This function
even uses the encoded byte which is named  devfn  ( I assume from PCI
device and PCI function ) ,   but this function treats it as slot and
function.

Any help is appreciated.  Thanks in advance.

Jack L. Hammer
RAID Client/Server Development
IBM Personal Systems Group
(919)-254-8665

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Slot Number Question

[Richard B. Johnson]

On Mon, 15 Jan 2001, Jack Hammer wrote:

> My adapter configuration utility needs to instruct the user which physical
> adapter needs attention ( when there may be multiple adapters in the system
> ).    My question is :  How do I determine the ( machine ) slot number of a
> PCI adapter ?
> 
> In BIOS and other OS's this may be doneby examining the system's  PCI
> Routing Tables.    I don't think I can get to those from Linux.
> 
> PCI Devices are defined by  BUS,  DEVICE, and FUNCTION.    In Linux there
> is a function ( defined in pci.h near the end of the file ) called   "
> PCI_SLOT( devfn ) "   but from what I can see this returns what PCI calls
> the device.   PCI device is not the machine's slot number.   This function
> even uses the encoded byte which is named  devfn  ( I assume from PCI
> device and PCI function ) ,   but this function treats it as slot and
> function.
> 
> Any help is appreciated.  Thanks in advance.

According to the PCI Specifications, there is no such item as the 'slot'
if what you refer to is the physical socket on a bus. The hardware
vendor is free to put any 'device number' in any such slot as long
as it is unique.

This is done by asserting the target's IDSEL line when the target <15:11>
bits are qualified. Both the PC BIOS and Linux may 'remember' these
bits and Linux used to display these bits as:

PCI devices found:
  Bus  0, device   0, function  0:
    Class 0600: PCI device 8086:7190 (rev 2).
      Master Capable.  Latency=64.  
      Prefetchable 32 bit memory at 0xe6000000 [0xe7ffffff].
  Bus  0, device   1, function  0:
    Class 0604: PCI device 8086:7191 (rev 2).
      Master Capable.  Latency=64.  Min Gnt=128.
  Bus  0, device   4, function  0:

... the 'device' shown in /proc/pci.  However, there are new problems
relating to changes made in 2.4.0, which now provides incorrect
information in /proc/pci:


    Class 0601: PCI device 8086:7110 (rev 2).
  Bus  0, device   4, function  1:
    Class 0101: PCI device 8086:7111 (rev 1).
      Master Capable.  Latency=32.  
      I/O at 0xd800 [0xd80f].
  Bus  0, device   4, function  2:
    Class 0c03: PCI device 8086:7112 (rev 1).
      IRQ 12.
      Master Capable.  Latency=32.  
      I/O at 0xd400 [0xd41f].
  Bus  0, device   4, function  3:

Note I have 3 device #4 showing in my /proc/pci file, which of course
is impossible. The meaning of 'device' seems to have been changed so one
now has to include the function number as well???!! All of the device 4
listed above refer to the exact same device. It's the PIIX4 PCI/ISA
bridge.

In my case, the correct PCI devices are shown as:

Device      Vendor                    Type
   0   Intel Corporation              440BX/ZX - 82443BX/ZX Host bridge  
       I/O memory : 0xe6000000->0xe7fffff7
   1   Intel Corporation              440BX/ZX - 82443BX/ZX AGP bridge   
       I/O memory : 0x40010100->0x470101ff
       I/O memory : 0x22a0d0e0->0x1fffdfef
       I/O memory : 0xe5e0e5f0->0xe5efe5ff
       I/O memory : 0xe5f0e600->0xe5ffe60f
   4   Intel Corporation              82371AB PIIX4 ISA                  
   9   S3 Inc.                        86c968 [Vision 968 VRAM] rev 0     
       IRQ 12 Pin 1
       I/O memory : 0x14000000->0x15ffffff
  11   3Com Corporation               3c905B 100BaseTX [Cyclone]         
       IRQ 10 Pin 1
       I/O  ports : 0xd000->0xd07e
       I/O memory : 0xe1800000->0xe180007f
  12   BusLogic                       BT-946C (BA80C30), [MultiMaster 10]
       IRQ 11 Pin 1
       I/O  ports : 0xb800->0xb802
       I/O memory : 0xe1000000->0xe1000fff

This is obtained from a program that simply scans the PCI bus in the
manner shown on page 345 of the PCI System Architecture, fourth edition,
MindShare, Inc., ISBN 0-201-30974-2.

In any case, there is no way to correlate the device number with a
PC connector slot just as there is no way to find out which of the
4 INT lines go to these connectors. The BIOS vendor only knows for
sure, and since BIOSes are not updated as often as boards, even the
BIOS is often incorrect.

I suggest you put a flashing LED on the board that needs attention.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Slot Number Question

[Dominik Kubla]

On Mon, Jan 15, 2001 at 03:22:58PM -0500, Richard B. Johnson wrote:
> 
> In any case, there is no way to correlate the device number with a
> PC connector slot just as there is no way to find out which of the
> 4 INT lines go to these connectors. The BIOS vendor only knows for
> sure, and since BIOSes are not updated as often as boards, even the
> BIOS is often incorrect.

Well actually there seems to be a way to do this. Quoting "System Management
BIOS Reference Specification" v2.3.1 (p.51):

   3.3.10 System Slots (Type 9)

   The information in this structure defines the attributes of a system
   slot. One structure is provided for each slot in the system.

And later in table 3.3.10.5 (p.53):

   Identifies the value present in the Slot Number field of the PCI Interrupt
   Routing Table entry that is associated with this slot, in offset 09h [...]

   Software can determine the PCI bus number and device associated with the
   slot by matching the "Slot ID" to an entry in the routing table... and
   ultimately determine what device is present in that slot.

Right now Linux' SMBIOS implementation use only the first 3 tables to determine
the manufacturer of system and BIOS to blacklist known buggy APM/ACPI
implementations.  Since i have the SMBIOS specs at hand i will have a lot.
Is there a PCI spec available on the net? www.pcisig.org asks for a password
when you try to download the specs... (don't you just love "secret" standards?)

Yours,
  Dominik Kubla
-- 
  Sign me!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Slot Number Question

[Richard B. Johnson]

On Tue, 16 Jan 2001, Dominik Kubla wrote:

> On Mon, Jan 15, 2001 at 03:22:58PM -0500, Richard B. Johnson wrote:
> > 
> > In any case, there is no way to correlate the device number with a
> > PC connector slot just as there is no way to find out which of the
> > 4 INT lines go to these connectors. The BIOS vendor only knows for
> > sure, and since BIOSes are not updated as often as boards, even the
> > BIOS is often incorrect.
> 
> Well actually there seems to be a way to do this. Quoting "System Management
> BIOS Reference Specification" v2.3.1 (p.51):
> 
>    3.3.10 System Slots (Type 9)
> 
>    The information in this structure defines the attributes of a system
>    slot. One structure is provided for each slot in the system.
> 
> And later in table 3.3.10.5 (p.53):
> 
>    Identifies the value present in the Slot Number field of the PCI Interrupt
>    Routing Table entry that is associated with this slot, in offset 09h [...]
> 
>    Software can determine the PCI bus number and device associated with the
>    slot by matching the "Slot ID" to an entry in the routing table... and
>    ultimately determine what device is present in that slot.
> 
> Right now Linux' SMBIOS implementation use only the first 3 tables to determine
> the manufacturer of system and BIOS to blacklist known buggy APM/ACPI
> implementations.  Since i have the SMBIOS specs at hand i will have a lot.
> Is there a PCI spec available on the net? www.pcisig.org asks for a password
> when you try to download the specs... (don't you just love "secret" standards?)
> 
> Yours,
>   Dominik Kubla
> -- 
>   Sign me!
> 

Well yes and no. The problem is that the 'slot' is not the connector!
It's easy to determine the slot to which they refer simply from the
bits at <11:15>. However, applications are not supposed to do the
port I/O to get this info, though. Instead, they are supposed to use
BIOS32 or other provisions.

All of the information necessary to observe/configure the bridge(s)
is/are available from the two ports specified in the standard.
Machines that don't have 'ports' emulate them (also in the standard)
so that minimum changes are necessary.

When a vendor puts a PCI Ethernet controller or a SCSI controller
on the board (or both). Any notion of a slot referencing a card-
connector goes out the window.

Linux now provides a 'local' PCI database. However, if hot-swapping
of PCI devices becomes a reality, this extra code may have limited
utility. Nevertheless it is a good idea for fixed configurations
that use modules because one doesn't run the risk of corrupting
a running PCI bus to get the resource information necessary to
install a new module.

The invisibility of a physical connector may actually be good. This
allows any PCI board to work in any PCI card-connector. Software that
requires a particular card-connector is probably broken by design.  If
software needs someone to 'adjust' something on a particular board,
hardware should provide an indication on the board (like a LED). 

--- Adjust the Contrabulator(tm) on the board with the flashing LED
to obtain a pale blue flame... Press any key to test.....
		**** RELEASE to DETONATE ***


I have heard that there is a spec available on the Net . However, I just
buy the latest books because the company has "plenty" of money and
I like hard copies. Sombody else will probably tell you where. There
is even a complete BIOS (several) on the Net.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/