On 4/08/2006 1:31 PM, User Freebsd wrote:
'k, looking at the above, and comparing it to what I'm getting from pciconf -l, I'm missing something ... namely:

[EMAIL PROTECTED]:10:0: class=0x020000 card=0x0027a0a0 chip=0x813910ec rev=0x10 hdr=0x00

Translates to:

[EMAIL PROTECTED]:10:0: class=0x020000 card=0x0027a0a0 chip=0x813910ec rev=0x10 hdr=0x00
    vendor   = 'Realtek Semiconductor'
    device   = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter'
    class    = network
    subclass = ethernet

But, the last 4 hex of card/chip aren't teh same ... oh, wait, re-reading what you stated, is it safe to assume that chip= can be ignored ... nope, that doesn't follow either ... but I think I see it ...

Looking through src/usr.sbin/pciconf/pciconf.c, it looks as though pciconf only translates the chip= for what it displays. The DOS-based PCI identification code that I've worked with in the past typically referred "chip" as "device", and "card" as "sub-device"... Internally, pciconf uses the same references (snipped from the printf statement):

    (p->pc_subdevice << 16) | p->pc_subvendor,
    (p->pc_device << 16) | p->pc_vendor,

The aforementioned DOS utilities used to display lookups for both (where appropriate); I vaguely recall coming to the conclusion that the sub-device bit was not mandatory, but someone with more knowledge of the ins and outs of the PCI specs may be able to state that more definitively...

In short, the "chip" field from pciconf looks like the most important one.. the rev/hdr fields are less important for our needs - as far as I'm aware they're generally used to denominate hardware revisions, so as vendors revise their PCB layouts and components, they can be easily differentiate between them -- this is most important when you're a driver, trying to figure out what how you should treat a specific device... The card one may fall into a "nice-to-know" but not necessary..

For the above, vendor *should* be Aopen Inc, not Realtek Semiconductor ...

'k, so, for the above:

    - Aopen Inc (A0A0)

    - Realtek Semiconductor (10EC)
    - 8139    RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter (8139)

And the 0027 is actually meaningless in this case ...

So in your case, it's a Realtek 8139 adapter, most likely as part of an AOpen motherboard or add-in card...

So, what I'm looking for is vendor->device, but in some card= cases, there won't be a 'Device' listed ...

As to class= ... what table am I supposed to be seeing at that URL?

The class= line is a combination of two fields (the same as chip and card are a combination of vendor and device fields) -- the class, and subclass, of the device.

The URL http://fxr.watson.org/fxr/source/dev/pci/pci.c#L1340 shows the C source for this table that's used to match them up... for instance:

     CLASS                  SUBCLASS                DESCRIPTION
    {PCIC_NETWORK,          -1,                     "network"},
    {PCIC_NETWORK,          PCIS_NETWORK_ETHERNET,  "ethernet"},
    {PCIC_NETWORK,          PCIS_NETWORK_TOKENRING, "token ring"},
    {PCIC_NETWORK,          PCIS_NETWORK_FDDI,      "fddi"},
    {PCIC_NETWORK,          PCIS_NETWORK_ATM,       "ATM"},
    {PCIC_NETWORK,          PCIS_NETWORK_ISDN,      "ISDN"},

The first line of the above defines the "network" device class; then it defines several of the sub-classes of class "network"... ethernet, token ring, etc. These are defined here:


So this line:

    {PCIC_NETWORK,          PCIS_NETWORK_ETHERNET,  "ethernet"},

actually reads:

    {0x02,                  0x00,                   "ethernet"},

So our class line:


Is made up of 2 hex digits for the device class, and 4 hex digits for the device sub-class...

Savvy? ;-)

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to