Enumerating a machine's buses

Guys,

I want to write a diagnostic program that enumerates all the
devices and buses in a machine and to show them in a Tree
Control. I don’t want to use the Registry or the device manager
for that, I want to see what the hardware tells me, because,
again, this is a diagnostics program, and to a diagnostics
program not even the OS is to be trusted. I know how to do it at
hardware level, no big deal, but I want to give the OS a chance.
Can it be done using only legit OS APIs ?

Alberto.

Device manager (DEVCON, SetupDiXxx) is the best approach.

You cannot gather this information from the hardware in your own code,
doing so will disturb the Windows hardware enumerators.

Windows already have the hardware enumeration, and you have no reliable
ways except relying on them.

If you cannot trust the OS - write the bare-metal app, based on DOS
extender or on customized Linux (well, are you sure you can trust Linux more
then Windows?)

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Alberto Moreira”
To: “Windows System Software Devs Interest List”
Sent: Saturday, January 07, 2006 6:03 PM
Subject: [ntdev] Enumerating a machine’s buses

> Guys,
>
> I want to write a diagnostic program that enumerates all the
> devices and buses in a machine and to show them in a Tree
> Control. I don’t want to use the Registry or the device manager
> for that, I want to see what the hardware tells me, because,
> again, this is a diagnostics program, and to a diagnostics
> program not even the OS is to be trusted. I know how to do it at
> hardware level, no big deal, but I want to give the OS a chance.
> Can it be done using only legit OS APIs ?
>
>
> Alberto.
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Hi, Max,

This is supposed to be a diagnostics program. It’s intended to
diagnose the hardware, not the OS view of the hardware! So, it
matters not which OS I’m running under, I need to access the
hardware.

In a few weeks I’m going to be bringing up a frighteningly
complex new piece of hardware, and I need good diagnostics and
testing software running under the OS’s I’ll be dealing with, in
this case, Solaris, Linux and Windows. It will also be the case
that when a board barfs at a user site, or at the hardware lab,
I’d like to see the hardware’s view of what is in there, and how
many layers of bridges sit between my chips and the processor.
Sometimes, “in-extremis”, I may even ask hardware engineers to
reset the bridges by hand! SoftICE can do that relatively
efficiently, but I do not have it installed at every site and
every machine. It’s not a feasible proposition to ask the user
or the engineer to analyze the Registry and what not, specially
when there’s multiple OS’s involved, but it’s not difficult to
ask site personnel to run an Alberto-supplied applet that dumps
the relevant portions of the machine config into a file that is
then emailed back to Alberto.

What I need is something like the BoundsChecker Monitor, which
we also called “BoundsChecker for Dummies” among ourselves.
Something that a QA or support individual, or a hardware chip or
board engineer, could do in a jiffy! Dump stuff into a file,
email it back to the dev team together with the driver’s log
file.

Alberto.

----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”

Sent: Saturday, January 07, 2006 11:27 AM
Subject: Re: [ntdev] Enumerating a machine’s buses

> Device manager (DEVCON, SetupDiXxx) is the best approach.
>
> You cannot gather this information from the hardware in
> your own code,
> doing so will disturb the Windows hardware enumerators.
>
> Windows already have the hardware enumeration, and you have
> no reliable
> ways except relying on them.
>
> If you cannot trust the OS - write the bare-metal app,
> based on DOS
> extender or on customized Linux (well, are you sure you can
> trust Linux more
> then Windows?)
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Alberto Moreira”
> To: “Windows System Software Devs Interest List”
>
> Sent: Saturday, January 07, 2006 6:03 PM
> Subject: [ntdev] Enumerating a machine’s buses
>
>
>> Guys,
>>
>> I want to write a diagnostic program that enumerates all the
>> devices and buses in a machine and to show them in a Tree
>> Control. I don’t want to use the Registry or the device
>> manager
>> for that, I want to see what the hardware tells me, because,
>> again, this is a diagnostics program, and to a diagnostics
>> program not even the OS is to be trusted. I know how to do it
>> at
>> hardware level, no big deal, but I want to give the OS a
>> chance.
>> Can it be done using only legit OS APIs ?
>>
>>
>> Alberto.
>>
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as:
>> xxxxx@storagecraft.com
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

> This is supposed to be a diagnostics program. It’s intended to

diagnose the hardware, not the OS view of the hardware! So, it
matters not which OS I’m running under, I need to access the
hardware.

Write the bare-metal app.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

‘low level diagnostics’ and ‘diagnostic for dummies’ are two different
things. One is for hardware bringup - for either new hardware or new
platforms or both, and is best implemented as a combination of low level
tools and hardware analyzers. Diagnostics for dummies is something you ship
with your product that uses the available platform apis to send back enough
information for your support staff to diagnose what went wrong - it assumes
that the low level new-platform new-hardware debugging has already been
done. For the latter case you can certainly use the windows apis to dump out
what the windows view of attached pci devices and their relationship to each
other is.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alberto Moreira
Sent: Saturday, January 07, 2006 11:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Enumerating a machine’s buses

Hi, Max,

This is supposed to be a diagnostics program. It’s intended
to diagnose the hardware, not the OS view of the hardware!
So, it matters not which OS I’m running under, I need to
access the hardware.

In a few weeks I’m going to be bringing up a frighteningly
complex new piece of hardware, and I need good diagnostics
and testing software running under the OS’s I’ll be dealing
with, in this case, Solaris, Linux and Windows. It will also
be the case that when a board barfs at a user site, or at the
hardware lab, I’d like to see the hardware’s view of what is
in there, and how many layers of bridges sit between my chips
and the processor.
Sometimes, “in-extremis”, I may even ask hardware engineers
to reset the bridges by hand! SoftICE can do that relatively
efficiently, but I do not have it installed at every site and
every machine. It’s not a feasible proposition to ask the
user or the engineer to analyze the Registry and what not,
specially when there’s multiple OS’s involved, but it’s not
difficult to ask site personnel to run an Alberto-supplied
applet that dumps the relevant portions of the machine config
into a file that is then emailed back to Alberto.

What I need is something like the BoundsChecker Monitor,
which we also called “BoundsChecker for Dummies” among ourselves.
Something that a QA or support individual, or a hardware chip
or board engineer, could do in a jiffy! Dump stuff into a
file, email it back to the dev team together with the
driver’s log file.

Alberto.

----- Original Message -----
From: “Maxim S. Shatskih”
> To: “Windows System Software Devs Interest List”
>
> Sent: Saturday, January 07, 2006 11:27 AM
> Subject: Re: [ntdev] Enumerating a machine’s buses
>
>
> > Device manager (DEVCON, SetupDiXxx) is the best approach.
> >
> > You cannot gather this information from the hardware in
> > your own code,
> > doing so will disturb the Windows hardware enumerators.
> >
> > Windows already have the hardware enumeration, and you have
> > no reliable
> > ways except relying on them.
> >
> > If you cannot trust the OS - write the bare-metal app,
> > based on DOS
> > extender or on customized Linux (well, are you sure you can
> > trust Linux more
> > then Windows?)
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> > ----- Original Message -----
> > From: “Alberto Moreira”
> > To: “Windows System Software Devs Interest List”
> >
> > Sent: Saturday, January 07, 2006 6:03 PM
> > Subject: [ntdev] Enumerating a machine’s buses
> >
> >
> >> Guys,
> >>
> >> I want to write a diagnostic program that enumerates all the
> >> devices and buses in a machine and to show them in a Tree
> >> Control. I don’t want to use the Registry or the device
> >> manager
> >> for that, I want to see what the hardware tells me, because,
> >> again, this is a diagnostics program, and to a diagnostics
> >> program not even the OS is to be trusted. I know how to do it
> >> at
> >> hardware level, no big deal, but I want to give the OS a
> >> chance.
> >> Can it be done using only legit OS APIs ?
> >>
> >>
> >> Alberto.
> >>
> >>
> >>
> >>
> >> —
> >> Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >>
> >> You are currently subscribed to ntdev as:
> >> xxxxx@storagecraft.com
> >> To unsubscribe send a blank email to
> >> xxxxx@lists.osr.com
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@ieee.org
> > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Mark, I hear you! But this is my original question, how do I get
Windows to tell me about bridges and bus slots that don’t belong
to my hardware ?

Alberto.

----- Original Message -----
From: “Mark Roddy”
To: “Windows System Software Devs Interest List”

Sent: Saturday, January 07, 2006 12:37 PM
Subject: RE: [ntdev] Enumerating a machine’s buses

> ‘low level diagnostics’ and ‘diagnostic for dummies’ are two
> different
> things. One is for hardware bringup - for either new hardware
> or new
> platforms or both, and is best implemented as a combination of
> low level
> tools and hardware analyzers. Diagnostics for dummies is
> something you ship
> with your product that uses the available platform apis to
> send back enough
> information for your support staff to diagnose what went
> wrong - it assumes
> that the low level new-platform new-hardware debugging has
> already been
> done. For the latter case you can certainly use the windows
> apis to dump out
> what the windows view of attached pci devices and their
> relationship to each
> other is.
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>> Alberto Moreira
>> Sent: Saturday, January 07, 2006 11:52 AM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] Enumerating a machine’s buses
>>
>> Hi, Max,
>>
>> This is supposed to be a diagnostics program. It’s intended
>> to diagnose the hardware, not the OS view of the hardware!
>> So, it matters not which OS I’m running under, I need to
>> access the hardware.
>>
>> In a few weeks I’m going to be bringing up a frighteningly
>> complex new piece of hardware, and I need good diagnostics
>> and testing software running under the OS’s I’ll be dealing
>> with, in this case, Solaris, Linux and Windows. It will also
>> be the case that when a board barfs at a user site, or at the
>> hardware lab, I’d like to see the hardware’s view of what is
>> in there, and how many layers of bridges sit between my chips
>> and the processor.
>> Sometimes, “in-extremis”, I may even ask hardware engineers
>> to reset the bridges by hand! SoftICE can do that relatively
>> efficiently, but I do not have it installed at every site and
>> every machine. It’s not a feasible proposition to ask the
>> user or the engineer to analyze the Registry and what not,
>> specially when there’s multiple OS’s involved, but it’s not
>> difficult to ask site personnel to run an Alberto-supplied
>> applet that dumps the relevant portions of the machine config
>> into a file that is then emailed back to Alberto.
>>
>> What I need is something like the BoundsChecker Monitor,
>> which we also called “BoundsChecker for Dummies” among
>> ourselves.
>> Something that a QA or support individual, or a hardware chip
>> or board engineer, could do in a jiffy! Dump stuff into a
>> file, email it back to the dev team together with the
>> driver’s log file.
>>
>> Alberto.
>>
>>
>> ----- Original Message -----
>> From: “Maxim S. Shatskih”
>> To: “Windows System Software Devs Interest List”
>>
>> Sent: Saturday, January 07, 2006 11:27 AM
>> Subject: Re: [ntdev] Enumerating a machine’s buses
>>
>>
>> > Device manager (DEVCON, SetupDiXxx) is the best
>> > approach.
>> >
>> > You cannot gather this information from the hardware in
>> > your own code,
>> > doing so will disturb the Windows hardware enumerators.
>> >
>> > Windows already have the hardware enumeration, and you
>> > have
>> > no reliable
>> > ways except relying on them.
>> >
>> > If you cannot trust the OS - write the bare-metal app,
>> > based on DOS
>> > extender or on customized Linux (well, are you sure you can
>> > trust Linux more
>> > then Windows?)
>> >
>> > Maxim Shatskih, Windows DDK MVP
>> > StorageCraft Corporation
>> > xxxxx@storagecraft.com
>> > http://www.storagecraft.com
>> >
>> > ----- Original Message -----
>> > From: “Alberto Moreira”
>> > To: “Windows System Software Devs Interest List”
>> >
>> > Sent: Saturday, January 07, 2006 6:03 PM
>> > Subject: [ntdev] Enumerating a machine’s buses
>> >
>> >
>> >> Guys,
>> >>
>> >> I want to write a diagnostic program that enumerates all
>> >> the
>> >> devices and buses in a machine and to show them in a Tree
>> >> Control. I don’t want to use the Registry or the device
>> >> manager
>> >> for that, I want to see what the hardware tells me,
>> >> because,
>> >> again, this is a diagnostics program, and to a diagnostics
>> >> program not even the OS is to be trusted. I know how to do
>> >> it
>> >> at
>> >> hardware level, no big deal, but I want to give the OS a
>> >> chance.
>> >> Can it be done using only legit OS APIs ?
>> >>
>> >>
>> >> Alberto.
>> >>
>> >>
>> >>
>> >>
>> >> —
>> >> Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >>
>> >> You are currently subscribed to ntdev as:
>> >> xxxxx@storagecraft.com
>> >> To unsubscribe send a blank email to
>> >> xxxxx@lists.osr.com
>> >
>> >
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > You are currently subscribed to ntdev as: xxxxx@ieee.org
>> > To unsubscribe send a blank email to
>> > xxxxx@lists.osr.com
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as:
>> xxxxx@hollistech.com
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

> Mark, I hear you! But this is my original question, how do I get

Windows to tell me about bridges and bus slots that don’t belong
to my hardware ?

Do you want to know about busses that aren’t in the path to your device, or
do you want to somehow diagnose the existance of mysterious busses somewhere
in hyperspace that the OS was somehow unable to find? Your earlier posts
seem to indicate the later.

If you want to know what busses are there and are willing to believe the OS
has found them all, just walk the hardware tree.

If you don’t believe the OS has found them all, why do you care about the
others? If the OS doesn’t know it is there it isn’t very likely to be using
it.

Loren

Loren,

I want to draw the bus tree as seen by the machine’s hardware.
And no, I do not want to trust the OS for that. Also, the core
logic of this diag program will have to work on multiple
platforms and multiple operating systems, such as Linux,
Solaris, Windows, maybe MacOS, and so on. I may have 2 or 4
boards in the system, I may have multiple chips per board, and I
want to know where the hardware thinks my boards are connected,
what’s the path from the processor down to the board in terms of
buses and chips, what else the hardware thinks is connected to
each bus in the path, and so on - because at the hardware level,
anything is possible and the hardware level interactions and
barfing possibilities are endless. Believe me, I’ve seen video
boards misbehave because of electrical problems in network or
audio cards: remove the network card, and everything’s fine.

You see, I’m working at pretty low level! I want to make sure my
hardware behaves enough to allow the OS’s to do their jobs. This
is not device driver work! This is diagnostics work. Two notches
lower level. Upstream from the OS.

Reminds me of a story when I was doing DriverStudio. A salesman
came to me, “Do we still ship SoftICE for DOS ?” I was very
surprised, who in the world still wanted it ? The answer was,
the requestor was the diagnostics and testing organization for a
well known disk drive manufacturer; they wanted to install
SoftICE in a few machines at the shop floor so that they could
quickly run some hardware-level tests by peeking and poking at
hardware level memory and i/o locations. And, as luck would have
it, we still shipped it inside the DriverStudio CD.

Believe me, there’s life outside the OS!

Alberto.

----- Original Message -----
From: “Loren Wilton”
To: “Windows System Software Devs Interest List”

Sent: Saturday, January 07, 2006 2:05 PM
Subject: Re: [ntdev] Enumerating a machine’s buses

>> Mark, I hear you! But this is my original question, how do I
>> get
>> Windows to tell me about bridges and bus slots that don’t
>> belong
>> to my hardware ?
>
> Do you want to know about busses that aren’t in the path to
> your device, or
> do you want to somehow diagnose the existance of mysterious
> busses somewhere
> in hyperspace that the OS was somehow unable to find? Your
> earlier posts
> seem to indicate the later.
>
> If you want to know what busses are there and are willing to
> believe the OS
> has found them all, just walk the hardware tree.
>
> If you don’t believe the OS has found them all, why do you
> care about the
> others? If the OS doesn’t know it is there it isn’t very
> likely to be using
> it.
>
> Loren
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

> Believe me, there’s life outside the OS!

Yes, there is. But the case you’ve picked is particularly grusome to try to
solve. Even quite ignoring that probably most OSes would get upset with the
kind of poing around you would have to do, or would prevent you from doing
some of it, there is the problem that the hardware itself might get upset,
and you will end up creating a mess that didn’t exist before you started
poking.

Your first big problem is going to be finding the busses. About the only
way you can do this reliably is to get your hands on the ACPI tables, run an
ACPI interpreter, walk the tree, and find the host bridge addresses.

Now you have the problem of dealing with the host bridges. You *do* know
how to deal with a UNO035 host bridge, don’t you? And you know the rather
major and critical differences between it and a UNO030? Oh wait, I forgot.
We don’t publish the specs on those bridges since only my HALs and the BIOS
and ASL code really need to deal with them, plus some of our proprietary
drivers.

Well, once you get the host bridges set up right and the IO and bus memory
mapped, you can start walking down the PCI busses outside them to see what
is there. It is important that you do this in the right order though,
otherwise you might not end up with IO space mapped for the compatability
board, and none of the standard peripherals will work any more.

If you look in the bridge spec (that we don’t publish) you will see some
flags you need to look at to do this right. Oh, the algorithms aren’t in
the spec. And it doesn’t really mention there which flags you need to look
at to do this right. That was all figured out by the BIOS group after the
hardware group wrote the spec, and the hardware group doesn’t figure those
sort of details belong in their spec.

Now, that’s just to deal with the host bridges on a couple of Unisys
machines I happen to know about off the top of my head. I’d be willing to
bet that there are a bunch of equally interesting things out there that I
don’t know about, but other iron vendors do.

And all of that is completely ignoring systems that don’t map bus memory
space 1:1 into host memory space, or that use indirection registers to get
to the PCI config space for the busses in other clusters and the like.

Loren

> I want to draw the bus tree as seen by the machine’s hardware.

The node in the tree (owner of the children) is a controller, which requires
particular driver.

For instance, you have sym_u3 or adpu160m SCSI card. How will you draw the tree
of disks and tapes hanging off it? Sorry, your code will need the driver for
sym_u3 and for adpu160m.

And so on. Your system will need the drivers for all hardware which is capable
of having connected “children”. OK, 2 USB stacks - one for UHCD and another for
UHCI, and so on. OK, the 1394 stack - for TI OHCI and Adaptec controller.

You’re rewriting the OS.

Yes, this is a choice (and can be done, for instance, by customizing Linux),
but sorry, how this relates to Windows?

IN WINDOWS, YOU CANNOT DO HARDWARE PROBES. Period. Only the “owner” driver can
touch its hardware, nobody else. Sorry. Move to another OS or write your own.

And no, I do not want to trust the OS for that.

Then write your own OS. No other chances.

Believe me, there’s life outside the OS!

Yes. So should your diag app. You can base it on SI/DOS codebase in fact.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Alberto,
Why not do this is DOS?
calvin

— Alberto Moreira wrote:

> Loren,
>
> I want to draw the bus tree as seen by the machine’s
> hardware.
> And no, I do not want to trust the OS for that.
> Also, the core
> logic of this diag program will have to work on
> multiple
> platforms and multiple operating systems, such as
> Linux,
> Solaris, Windows, maybe MacOS, and so on. I may have
> 2 or 4
> boards in the system, I may have multiple chips per
> board, and I
> want to know where the hardware thinks my boards are
> connected,
> what’s the path from the processor down to the board
> in terms of
> buses and chips, what else the hardware thinks is
> connected to
> each bus in the path, and so on - because at the
> hardware level,
> anything is possible and the hardware level
> interactions and
> barfing possibilities are endless. Believe me, I’ve
> seen video
> boards misbehave because of electrical problems in
> network or
> audio cards: remove the network card, and
> everything’s fine.
>
> You see, I’m working at pretty low level! I want to
> make sure my
> hardware behaves enough to allow the OS’s to do
> their jobs. This
> is not device driver work! This is diagnostics work.
> Two notches
> lower level. Upstream from the OS.
>
> Reminds me of a story when I was doing DriverStudio.
> A salesman
> came to me, “Do we still ship SoftICE for DOS ?” I
> was very
> surprised, who in the world still wanted it ? The
> answer was,
> the requestor was the diagnostics and testing
> organization for a
> well known disk drive manufacturer; they wanted to
> install
> SoftICE in a few machines at the shop floor so that
> they could
> quickly run some hardware-level tests by peeking and
> poking at
> hardware level memory and i/o locations. And, as
> luck would have
> it, we still shipped it inside the DriverStudio CD.
>
> Believe me, there’s life outside the OS!
>
> Alberto.
>
>
>
> ----- Original Message -----
> From: “Loren Wilton”
> To: “Windows System Software Devs Interest List”
>
> Sent: Saturday, January 07, 2006 2:05 PM
> Subject: Re: [ntdev] Enumerating a machine’s buses
>
>
> >> Mark, I hear you! But this is my original
> question, how do I
> >> get
> >> Windows to tell me about bridges and bus slots
> that don’t
> >> belong
> >> to my hardware ?
> >
> > Do you want to know about busses that aren’t in
> the path to
> > your device, or
> > do you want to somehow diagnose the existance of
> mysterious
> > busses somewhere
> > in hyperspace that the OS was somehow unable to
> find? Your
> > earlier posts
> > seem to indicate the later.
> >
> > If you want to know what busses are there and are
> willing to
> > believe the OS
> > has found them all, just walk the hardware tree.
> >
> > If you don’t believe the OS has found them all,
> why do you
> > care about the
> > others? If the OS doesn’t know it is there it
> isn’t very
> > likely to be using
> > it.
> >
> > Loren
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> xxxxx@ieee.org
> > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@yahoo.ca
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

__________________________________________________________
Find your next car at http://autos.yahoo.ca

No.

Bill M.

“Alberto Moreira” wrote in message news:xxxxx@ntdev…
> Guys,
>
> I want to write a diagnostic program that enumerates all the devices and
> buses in a machine and to show them in a Tree Control. I don’t want to use
> the Registry or the device manager for that, I want to see what the
> hardware tells me, because, again, this is a diagnostics program, and to a
> diagnostics program not even the OS is to be trusted. I know how to do it
> at hardware level, no big deal, but I want to give the OS a chance. Can it
> be done using only legit OS APIs ?
>
>
> Alberto.
>
>
>
>

Alberto wrote:

>>

This is supposed to be a diagnostics program. It’s intended to diagnose the hardware, not the OS view of the hardware! So, it matters not which OS I’m running under, I need to access the hardware.

>>

If this isn’t a question of “How do I do this under Windows” than the question is OT. If the question is “How do I do this under Windows” it’s been answered: You use the provided APIs.

We all know your disdain for having to deal with the OS, Alberto. Some of us have perhaps not heard it quite enough to recognize it for the trolling that it is. So, spare us the lectures about “I can do anything I want to the hardware and that should be no concern of Windows” which is where this thread is headed if it’s not there already – Use Windows or write to the “bare metal” as Max suggested and have a blast.

Hardware diags are useful and fun to write… under the appropriate own run time environment. Going behind the back of the OS to write them, and expecting the OS to stay running, is not good engineeering practice.

Peter
OSR

Let me rephrase my request, Peter, once again: someone, please,
tell me how I can write a multiprocessor-safe program under
Windows XP or 2K3 that recursively enumerates all devices on a
PCI bus. Do you know how to do it ? Please tell me. Do you not ?
No problem, but spare the pontification.

Now, if I believe and understand what Bill McKenzie wrote, it
cannot be done.

Simple, eh ?

Alberto.

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”

Sent: Monday, January 09, 2006 12:07 PM
Subject: RE:[ntdev] Enumerating a machine’s buses

> Alberto wrote:
>
>>>>
>
> This is supposed to be a diagnostics program. It’s intended to
> diagnose the hardware, not the OS view of the hardware! So, it
> matters not which OS I’m running under, I need to access the
> hardware.
>
>>>>
>
> If this isn’t a question of “How do I do this under Windows”
> than the question is OT. If the question is “How do I do this
> under Windows” it’s been answered: You use the provided APIs.
>
> We all know your disdain for having to deal with the OS,
> Alberto. Some of us have perhaps not heard it quite enough to
> recognize it for the trolling that it is. So, spare us the
> lectures about “I can do anything I want to the hardware and
> that should be no concern of Windows” which is where this
> thread is headed if it’s not there already – Use Windows or
> write to the “bare metal” as Max suggested and have a blast.
>
> Hardware diags are useful and fun to write… under the
> appropriate own run time environment. Going behind the back
> of the OS to write them, and expecting the OS to stay running,
> is not good engineeering practice.
>
> Peter
> OSR
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

> Let me rephrase my request, Peter, once again: someone, please,

tell me how I can write a multiprocessor-safe program under
Windows XP or 2K3 that recursively enumerates all devices on a
PCI bus. Do you know how to do it ? Please tell me. Do you not ?
No problem, but spare the pontification.

Yes, I know how to do it. Walk the stuff you get back from the OS. DO NOT
try to probe the hardware yourself.

Now, perhaps you want to rephrase your question as “Do I know how to write a
multiprocessor safe program under Windows XP or 2K3 that recursively
enumerates all devices on a PCI bus by banging directly on the bus.”
There are a few of questions burried in that single query:

  1. Do I know how to FIND the PCI busses in the first place?
  2. Do I know how to walk the PCI bus bridges without messing up hardware?
  3. Do I know how to do this without messing up the OS?
  4. Do I know how to do this without potentially trashing users IOs in
    progress?
  5. Do I know how to do this without the specs for the host bridges on the
    machine?
  6. Do I want to do this before or after the BIOS configures the system?
  7. Do I want to find out about busses the BIOS has left out of the
    current configuration?

Is that enough questions that need answers?

Now, maybe I’m looking at this with a jaundiced viewpoint since I spend my
time working on big machines. But I can tell you for a fact that I can
configure a partition such that there will be busses out there the BIOS
doesn’t enable, partially or completely. And if you go poking at them, you
are likely to hang the partition or do something even more evil. Do you
really want to do that?

Loren

Wait, you can see what is enumerated by the Windows PCI driver using a bus
filter driver. This is no simple task. This will not be something that
would be useful for any other platform besides an NT based OS.

You originally said that you wanted to enumerate all devices on all buses,
that is much much more difficult and would require multiple bus filter
drivers.

I made a tool similar to this at Compuware called PnpView which enumerated
all PCI, USB, and 1394 device and read the config space of all PCI devices,
the descriptors for all USB devices and the Config ROMs of all 1394 devices
and displayed everything from tree views based on bus. Enumerating every
type of device is a lot more work, especially if you get into trying to
enumerate HID devices, Bluetooth devices, and others.

Now, from what you stated, I gathered that you wanted to walk these busses
underneath the OS, and not to just filter the OS’s enumeration itself. You
cannot do that using standard APIs, although you can walk the PCI bus in
*most* cases (not all cases) using some deprecated APIs.

Bill M.

“Alberto Moreira” wrote in message news:xxxxx@ntdev…
> Let me rephrase my request, Peter, once again: someone, please, tell me
> how I can write a multiprocessor-safe program under Windows XP or 2K3 that
> recursively enumerates all devices on a PCI bus. Do you know how to do it
> ? Please tell me. Do you not ? No problem, but spare the pontification.
>
> Now, if I believe and understand what Bill McKenzie wrote, it cannot be
> done.
>
> Simple, eh ?
>
>
> Alberto.
>
>
>
>
> ----- Original Message -----
> From:
> To: “Windows System Software Devs Interest List”
> Sent: Monday, January 09, 2006 12:07 PM
> Subject: RE:[ntdev] Enumerating a machine’s buses
>
>
>> Alberto wrote:
>>
>>>>>
>>
>> This is supposed to be a diagnostics program. It’s intended to diagnose
>> the hardware, not the OS view of the hardware! So, it matters not which
>> OS I’m running under, I need to access the hardware.
>>
>>>>>
>>
>> If this isn’t a question of “How do I do this under Windows” than the
>> question is OT. If the question is “How do I do this under Windows” it’s
>> been answered: You use the provided APIs.
>>
>> We all know your disdain for having to deal with the OS, Alberto. Some
>> of us have perhaps not heard it quite enough to recognize it for the
>> trolling that it is. So, spare us the lectures about “I can do anything
>> I want to the hardware and that should be no concern of Windows” which is
>> where this thread is headed if it’s not there already – Use Windows or
>> write to the “bare metal” as Max suggested and have a blast.
>>
>> Hardware diags are useful and fun to write… under the appropriate own
>> run time environment. Going behind the back of the OS to write them, and
>> expecting the OS to stay running, is not good engineeering practice.
>>
>> Peter
>> OSR
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

I should clarify, actually just getting enumerated devices is easy using
SetupAPIs. If you want to interact with these devices, such as reading
config space information and such, you need bus filter drivers which is much
more difficult.

Bill M.

“Bill McKenzie” wrote in message
news:xxxxx@ntdev…
> Wait, you can see what is enumerated by the Windows PCI driver using a bus
> filter driver. This is no simple task. This will not be something that
> would be useful for any other platform besides an NT based OS.
>
> You originally said that you wanted to enumerate all devices on all buses,
> that is much much more difficult and would require multiple bus filter
> drivers.
>
> I made a tool similar to this at Compuware called PnpView which enumerated
> all PCI, USB, and 1394 device and read the config space of all PCI
> devices, the descriptors for all USB devices and the Config ROMs of all
> 1394 devices and displayed everything from tree views based on bus.
> Enumerating every type of device is a lot more work, especially if you get
> into trying to enumerate HID devices, Bluetooth devices, and others.
>
> Now, from what you stated, I gathered that you wanted to walk these busses
> underneath the OS, and not to just filter the OS’s enumeration itself.
> You cannot do that using standard APIs, although you can walk the PCI bus
> in most cases (not all cases) using some deprecated APIs.
>
> Bill M.
>
> “Alberto Moreira” wrote in message news:xxxxx@ntdev…
>> Let me rephrase my request, Peter, once again: someone, please, tell me
>> how I can write a multiprocessor-safe program under Windows XP or 2K3
>> that recursively enumerates all devices on a PCI bus. Do you know how to
>> do it ? Please tell me. Do you not ? No problem, but spare the
>> pontification.
>>
>> Now, if I believe and understand what Bill McKenzie wrote, it cannot be
>> done.
>>
>> Simple, eh ?
>>
>>
>> Alberto.
>>
>>
>>
>>
>> ----- Original Message -----
>> From:
>> To: “Windows System Software Devs Interest List”
>> Sent: Monday, January 09, 2006 12:07 PM
>> Subject: RE:[ntdev] Enumerating a machine’s buses
>>
>>
>>> Alberto wrote:
>>>
>>>>>>
>>>
>>> This is supposed to be a diagnostics program. It’s intended to diagnose
>>> the hardware, not the OS view of the hardware! So, it matters not which
>>> OS I’m running under, I need to access the hardware.
>>>
>>>>>>
>>>
>>> If this isn’t a question of “How do I do this under Windows” than the
>>> question is OT. If the question is “How do I do this under Windows”
>>> it’s been answered: You use the provided APIs.
>>>
>>> We all know your disdain for having to deal with the OS, Alberto. Some
>>> of us have perhaps not heard it quite enough to recognize it for the
>>> trolling that it is. So, spare us the lectures about “I can do anything
>>> I want to the hardware and that should be no concern of Windows” which
>>> is where this thread is headed if it’s not there already – Use Windows
>>> or write to the “bare metal” as Max suggested and have a blast.
>>>
>>> Hardware diags are useful and fun to write… under the appropriate own
>>> run time environment. Going behind the back of the OS to write them,
>>> and expecting the OS to stay running, is not good engineeering practice.
>>>
>>> Peter
>>> OSR
>>>
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at
>>> http://www.osronline.com/article.cfm?id=256
>>>
>>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>
>
>