Re: Gotta start somewhere ... how many of us are really out there?

On Fri, 4 Aug 2006, Antony Mawer wrote:

All of the expanded 'vendor', 'device', 'class' and 'subclass' information is present in the non -v version of the command output. The numbers shown earlier can be used to derive the text information:

class=0x010400
determines the class/subclass lines, using the table from here:
http://fxr.watson.org/fxr/source/dev/pci/pci.c#L1340

card=0xc0351044 chip=0xa5111044
these make up the vendor and device lines, using the list in
/usr/share/misc/pci_vendors (which is derived from the PCIDEVS.TXT
listing).

The last 4 hex digits of the card and chip lines are the vendor ID
while the first 4 are the device ID. The card is often given by
the vendor, while the chip identifies the actual part it uses to
implement functionality. For instance, a Netcomm ethernet NIC may
use a Realtek 8139 chip... so chip gives us the fact it's
essentially a generic Realtek chipset, while the card tells us the
vendor who manufactured the card & perhaps their name for it.

In short, there's no reason to have to transmit all the text names back to any server -- this can all be resolved at the server end,

'k, looking at the above, and comparing it to what I'm getting from pciconf -l, I'm missing something ... namely:

none8@pci2:10:0: class=0x020000 card=0x0027a0a0 chip=0x813910ec rev=0x10 hdr=0x00

Translates to:

none8@pci2: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 ...

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

'k, so, for the above:

card=0x0027a0a0
- Aopen Inc (A0A0)

chip=0x813910ec
- 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, 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?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@xxxxxxx MSN . scrappy@xxxxxxx
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Gotta start somewhere ... how many of us are really out there?
    ... # pciconf -l -v ... vendor = 'Adaptec )' ... The last 4 hex digits of the card and chip lines are the vendor ID ...
    (freebsd-questions)
  • Re: Sun - Too visionary?
    ... > I go even further to protect the proprietary rights of the vendor. ... every periphery card may require such a chip. ... then encrypted by the private key and sent to the vendor, ... encrypts the result with his private key and ships it ...
    (comp.lang.java.advocacy)
  • Touch screen ET&T on Clevo tn120r
    ... vendor = 'Intel Corporation' ... CardVendor 0x1558 card 0x0122 ... STATUS 0x2090 COMMAND 0x0106 ...
    (freebsd-questions)
  • Fwd: Evil trouble (Am1772/PQP-WP288P)
    ... The card itself is labelled,,NetVision 802.11b''. ... vendor = 'Intel Corporation' ... device = '82443MX USB Universal Host Controller' ...
    (freebsd-current)
  • Evil trouble (Am1772/PQP-WP288P)
    ... The card itself is labelled,,NetVision 802.11b''. ... vendor = 'Intel Corporation' ... device = '82443MX USB Universal Host Controller' ...
    (freebsd-current)
Quantcast