determine the card number

Hello

I’m developping a WDM driver for a PCI-Device. For handling interrupts I
would like to use named kernel events to notify applications if an
interrupt occured. Now I have the problem that more than one card might be
plugged in the same PC. That means the kernel events must have different
event names for every card to determine in the application which card
actually initiated an interrupt.
I thought about putting the card number behind the name of the event i.e.
GIGS_EVENT_RX_OVFLW_0,_1,_2, etc. (where 0,1,2 is just an incrementing
number, each representing one card). I simply don’t know from where the
hell I get this number! I would like to create the events in the pnp start
device routine but how can I determine how many times I already run
through this routine, because this count would give me the number I need!
Does anybody has an idea how I can get to this number?

Thanks very much
Daniel

I would not use the number of times through start device, your device can be
stopped then restarted do you really want to have a different event number
in this case? You could use the AddDevice routine, but you can have a
similar problem.

You might use the DevicePropertyUINumber from IoGetDeviceProperety though
these may not be sequential. Or you could create a registry entry for the
device (see IoOpenDeviceRegistryKey) that has the number, and if the key is
not present increment if from a global value under the driver registry key.

Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting

----- Original Message -----
From: “Daniel Luethi”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 22, 2003 7:16 AM
Subject: [ntdev] determine the card number

> Hello
>
> I’m developping a WDM driver for a PCI-Device. For handling interrupts I
> would like to use named kernel events to notify applications if an
> interrupt occured. Now I have the problem that more than one card might be
> plugged in the same PC. That means the kernel events must have different
> event names for every card to determine in the application which card
> actually initiated an interrupt.
> I thought about putting the card number behind the name of the event i.e.
> GIGS_EVENT_RX_OVFLW_0,_1,_2, etc. (where 0,1,2 is just an incrementing
> number, each representing one card). I simply don’t know from where the
> hell I get this number! I would like to create the events in the pnp start
> device routine but how can I determine how many times I already run
> through this routine, because this count would give me the number I need!
> Does anybody has an idea how I can get to this number?
>
> Thanks very much
> Daniel
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@acm.org
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Don Burn wrote:

I would not use the number of times through start device, your device can be
stopped then restarted do you really want to have a different event number
in this case? You could use the AddDevice routine, but you can have a
similar problem.

I haven’t seen any similar problem using AddDevice to assign such an
attribute, but my device is a PCI card that can’t be removed during
operation. I would just assign event names during device installation
and store them in the device registry key, and use a value in the driver
registry key to keep track. That way, if some strange circumstance
should init the devices in a different order, the assignments will
remain associated.

Thanks Don, the IoGetDeviceProperty(…DevicePropertyUINumber…) is a very
useful for me! I tried it out and the returned value actually corresponds
to the PCI slot number. That means as long as the PC has power, this
number will not change for the same card and is a warranty that created
named events will not suddenly belong to another card due to some strange
install and deinstalling process!
That the numbers are not sequentiell is not so beautiful, but doesn’t
matter in the end.
A last question: Does somebody know how I can access these numbers
(returned with DevicePropertyUINumber) in the application?

Thx
Daniel

>A last question: Does somebody know how I can access these numbers

(returned with DevicePropertyUINumber) in the application?

SetupDiGetDeviceRegistryProperty (specified SPDRP_UI_NUMBER) will do.

Calvin Guan, Software Developer xxxxx@nospam.ati.com
SW2D-Radeon NT Core Drivers
ATI Technologies Inc.
1 Commerce Valley Drive East
Markham, Ontario, Canada L3T 7X6
Tel: (905) 882-2600 Ext. 8654
Find a driver: http://www.ati.com/support/driver.html


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@ati.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

>> A last question: Does somebody know how I can access these numbers

> (returned with DevicePropertyUINumber) in the application?

SetupDiGetDeviceRegistryProperty (specified SPDRP_UI_NUMBER) will do.

Another approach, if you want to keep the source used to provide the
id number flexible, would be to simply add an IOCTL on the device to
return it’s id number.

> Thanks Don, the IoGetDeviceProperty(…DevicePropertyUINumber…) is a very

useful for me! I tried it out and the returned value actually corresponds
to the PCI slot number. That means as long as the PC has power, this
number will not change for the same card and is a warranty that created

This number comes from the ACPI BIOS, and should never change for a slot on
a given machine (except possibly wiht a BIOS upgrade). It isn’t dependent
on which board is in the slot, it is simply a property of the slot.

Loren

If only the number returned actually matched the number silk screened on the
motherboard…

I have test system where those numbers are off by 1 (or maybe they are off
by 2, I don’t remember anymore) from the numbers printed on the motherboard.

I presume this is a BIOS bug on this particular system, but if my test
system can have such a bug, so could the BIOS on any system out there.
Thus, it makes me question the usefulness of telling a client that putting a
board into the slot labelled ‘3’ on the motherboard will mean that Windows
will report it as being in slot number 3.

  • Jay

Jay Talbott
Principal Consulting Engineer
SysPro Consulting, LLC
3519 E. South Fork Drive
Suite 201
Phoenix, AZ 85044
(480) 704-8045
xxxxx@sysproconsulting.com
http://www.sysproconsulting.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
Sent: Thursday, October 23, 2003 4:44 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: determine the card number

> Thanks Don, the
IoGetDeviceProperty(…DevicePropertyUINumber…) is a very
> useful for me! I tried it out and the returned value
actually corresponds
> to the PCI slot number. That means as long as the PC has power, this
> number will not change for the same card and is a warranty
that created

This number comes from the ACPI BIOS, and should never change
for a slot on
a given machine (except possibly wiht a BIOS upgrade). It
isn’t dependent
on which board is in the slot, it is simply a property of the slot.

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@sysproconsulting.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

I don’t think it is a bios bug so much as the pci chipset/motherboard have
embedded devices occupying a couple of ‘slots’ while the engineer designing
the motherboard layout just labels the physical slots starting from 0 or 1.

=====================
Mark Roddy

-----Original Message-----
From: Jay Talbott [mailto:xxxxx@sysproconsulting.com]
Sent: Friday, October 24, 2003 11:34 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: determine the card number

If only the number returned actually matched the number silk
screened on the motherboard…

I have test system where those numbers are off by 1 (or maybe
they are off by 2, I don’t remember anymore) from the numbers
printed on the motherboard.

I presume this is a BIOS bug on this particular system, but
if my test system can have such a bug, so could the BIOS on
any system out there. Thus, it makes me question the
usefulness of telling a client that putting a board into the
slot labelled ‘3’ on the motherboard will mean that Windows
will report it as being in slot number 3.

  • Jay

Jay Talbott
Principal Consulting Engineer
SysPro Consulting, LLC
3519 E. South Fork Drive
Suite 201
Phoenix, AZ 85044
(480) 704-8045
xxxxx@sysproconsulting.com
http://www.sysproconsulting.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
> Sent: Thursday, October 23, 2003 4:44 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: determine the card number
>
>
> > Thanks Don, the
> IoGetDeviceProperty(…DevicePropertyUINumber…) is a very
> > useful for me! I tried it out and the returned value
> actually corresponds
> > to the PCI slot number. That means as long as the PC has
power, this
> > number will not change for the same card and is a warranty
> that created
>
> This number comes from the ACPI BIOS, and should never change
> for a slot on
> a given machine (except possibly wiht a BIOS upgrade). It
> isn’t dependent
> on which board is in the slot, it is simply a property of the slot.
>
> 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@sysproconsulting.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@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Try SetupDiGetDeviceRegistryProperty

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

----- Original Message -----
From: “Daniel Luethi”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, October 22, 2003 9:06 PM
Subject: [ntdev] Re: determine the card number

> Thanks Don, the IoGetDeviceProperty(…DevicePropertyUINumber…) is a very
> useful for me! I tried it out and the returned value actually corresponds
> to the PCI slot number. That means as long as the PC has power, this
> number will not change for the same card and is a warranty that created
> named events will not suddenly belong to another card due to some strange
> install and deinstalling process!
> That the numbers are not sequentiell is not so beautiful, but doesn’t
> matter in the end.
> A last question: Does somebody know how I can access these numbers
> (returned with DevicePropertyUINumber) in the application?
>
> Thx
> Daniel
>
> —
> 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

I’m not talking about the PCI device number, but the slot number, returned
when you call IoGetDeviceProperty() with DevicePropertyUINumber. From the
DDK docs:

“This number is typically a user-perceived slot number,
such as a number printed next to the slot on the board,
or some other number that makes locating the physical
device easier for the user.”

So, one would like to believe that the number returned actually matches the
number printed next to the slot in the system.

Note that calling IoGetDeviceProperty() with DevicePropertyAddress will give
you the PCI bus/device/function number data (interestly, the docs only say
that the encoding of the data in the returned ULONG is bus specific, but
provides no pointers of where to find out how it’s encoded for a specific
bus, such as PCI).

These slot number assignments are provided to the OS by the BIOS and is
totally independent of the PCI device number. For instance, in the test
system I mentioned, I have a network card located in the first slot in the
motherboard, labelled on the board as slot #1. If I go into device manager
(Win2k3 Server) and look at the properties on the device, it shows it’s
location as:

PCI Slot 3 (PCI bus 2, device 0, function 0)

Notice that the PCI Slot number is not the same as the PCI device number.

Note that in this system, all of the on-board devices are located on PCI bus
0, the video adapter is on the AGP bus (PCI bus 1), and all of the physical
PCI slots are on PCI bus 2.

As I mentioned before, the slot number is off by 2 (3 vs. 1) from the actual
slot numbers printed on the motherboard. This must be a bug in the BIOS
code that reports the slot assignments for this particular motherboard. I
know that when I’ve had other boards in the system, they also reported a
slot number that was off by 2.

Most annoying to have such a feature, only to have the data be WRONG.

  • Jay

Jay Talbott
Principal Consulting Engineer
SysPro Consulting, LLC
3519 E. South Fork Drive
Suite 201
Phoenix, AZ 85044
(480) 704-8045
xxxxx@sysproconsulting.com
http://www.sysproconsulting.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Friday, October 24, 2003 9:23 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: determine the card number

I don’t think it is a bios bug so much as the pci
chipset/motherboard have
embedded devices occupying a couple of ‘slots’ while the
engineer designing
the motherboard layout just labels the physical slots
starting from 0 or 1.

=====================
Mark Roddy

> -----Original Message-----
> From: Jay Talbott [mailto:xxxxx@sysproconsulting.com]
> Sent: Friday, October 24, 2003 11:34 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: determine the card number
>
>
> If only the number returned actually matched the number silk
> screened on the motherboard…
>
> I have test system where those numbers are off by 1 (or maybe
> they are off by 2, I don’t remember anymore) from the numbers
> printed on the motherboard.
>
> I presume this is a BIOS bug on this particular system, but
> if my test system can have such a bug, so could the BIOS on
> any system out there. Thus, it makes me question the
> usefulness of telling a client that putting a board into the
> slot labelled ‘3’ on the motherboard will mean that Windows
> will report it as being in slot number 3.
>
> - Jay
>
> Jay Talbott
> Principal Consulting Engineer
> SysPro Consulting, LLC
> 3519 E. South Fork Drive
> Suite 201
> Phoenix, AZ 85044
> (480) 704-8045
> xxxxx@sysproconsulting.com
> http://www.sysproconsulting.com
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
> > Sent: Thursday, October 23, 2003 4:44 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Re: determine the card number
> >
> >
> > > Thanks Don, the
> > IoGetDeviceProperty(…DevicePropertyUINumber…) is a very
> > > useful for me! I tried it out and the returned value
> > actually corresponds
> > > to the PCI slot number. That means as long as the PC has
> power, this
> > > number will not change for the same card and is a warranty
> > that created
> >
> > This number comes from the ACPI BIOS, and should never change
> > for a slot on
> > a given machine (except possibly wiht a BIOS upgrade). It
> > isn’t dependent
> > on which board is in the slot, it is simply a property of
the slot.
> >
> > 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@sysproconsulting.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@stratus.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@sysproconsulting.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

My comment was that the number wouldn’t change (save with a BIOS revision),
not that it was accurate. For the OP’s use it will be fine no matter what
value it has, as long as each slot is unique and constant.

That said, the ACPI spec specifically states that this value must match the
value screened by the slot, if any. Of course, since this is an 8 bit
value, it can be quite hard to get it to match a slot number of 4/1/5 for
instance, since the OEM has no control over how Windows will display this
number. (And no, my example number isn’t fanciful. It matches the slot
coordinates on our larger systems, which have *many* slots.)

Loren

----- Original Message -----
From: “Jay Talbott”
To: “Windows System Software Devs Interest List”
Sent: Friday, October 24, 2003 8:34 AM
Subject: [ntdev] Re: determine the card number

If only the number returned actually matched the number silk screened on the
motherboard…

I have test system where those numbers are off by 1 (or maybe they are off
by 2, I don’t remember anymore) from the numbers printed on the motherboard.

I presume this is a BIOS bug on this particular system, but if my test
system can have such a bug, so could the BIOS on any system out there.
Thus, it makes me question the usefulness of telling a client that putting a
board into the slot labelled ‘3’ on the motherboard will mean that Windows
will report it as being in slot number 3.

- Jay

Jay Talbott
Principal Consulting Engineer
SysPro Consulting, LLC
3519 E. South Fork Drive
Suite 201
Phoenix, AZ 85044
(480) 704-8045
xxxxx@sysproconsulting.com
http://www.sysproconsulting.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
> Sent: Thursday, October 23, 2003 4:44 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: determine the card number
>
>
> > Thanks Don, the
> IoGetDeviceProperty(…DevicePropertyUINumber…) is a very
> > useful for me! I tried it out and the returned value
> actually corresponds
> > to the PCI slot number. That means as long as the PC has power, this
> > number will not change for the same card and is a warranty
> that created
>
> This number comes from the ACPI BIOS, and should never change
> for a slot on
> a given machine (except possibly wiht a BIOS upgrade). It
> isn’t dependent
> on which board is in the slot, it is simply a property of the slot.
>
> 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@sysproconsulting.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@earthlink.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

> These slot number assignments are provided to the OS by the BIOS and is

totally independent of the PCI device number. For instance, in the test

IIRC the Slot/Chassis number is a field in PCI config space, filled by the BIOS
who knows the particular mobo’s layout.

I expect PCI.SYS to generate DevicePropertyUINumber from this config space
field.

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

To the best of my memory, the UI number comes from acpi.sys as it filters
the node requests, and the field comes from the ACPI BIOS. It might work
differently of course for a non-ACPI machine. I know on our machines this
number is coming from the ACPI BIOS.

Loren

----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”
Sent: Sunday, October 26, 2003 9:27 AM
Subject: [ntdev] Re: determine the card number

> > These slot number assignments are provided to the OS by the BIOS and is
> > totally independent of the PCI device number. For instance, in the test
>
> IIRC the Slot/Chassis number is a field in PCI config space, filled by the
BIOS
> who knows the particular mobo’s layout.
>
> I expect PCI.SYS to generate DevicePropertyUINumber from this config space
> field.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.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@earthlink.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

You think that you’re annoyed. You’ve only got one system with a busted
BIOS. I deal with literally hundreds.

The truth is that absolutely nothing that comes from the BIOS will be
reliable more than about 80% of the time on white-box machines. The
business model that supports them just isn’t rich enough. They just copy
the BIOS from one machine to the next, updating the parts that occur to
them. If they change the motherboard, but forget to update the slot
numbers, they won’t actually see a machine crash, so they won’t actually
have any feedback that they got it wrong.


Jake Oshins
Windows Base Kernel Team

This posting is provided “AS IS” with no warranties, and confers no rights.
OR if you wish to include a script sample in your post please add “Use of
included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

“Jay Talbott” wrote in message
news:xxxxx@ntdev…

I’m not talking about the PCI device number, but the slot number, returned
when you call IoGetDeviceProperty() with DevicePropertyUINumber. From the
DDK docs:

“This number is typically a user-perceived slot number,
such as a number printed next to the slot on the board,
or some other number that makes locating the physical
device easier for the user.”

So, one would like to believe that the number returned actually matches the
number printed next to the slot in the system.

Note that calling IoGetDeviceProperty() with DevicePropertyAddress will give
you the PCI bus/device/function number data (interestly, the docs only say
that the encoding of the data in the returned ULONG is bus specific, but
provides no pointers of where to find out how it’s encoded for a specific
bus, such as PCI).

These slot number assignments are provided to the OS by the BIOS and is
totally independent of the PCI device number. For instance, in the test
system I mentioned, I have a network card located in the first slot in the
motherboard, labelled on the board as slot #1. If I go into device manager
(Win2k3 Server) and look at the properties on the device, it shows it’s
location as:

PCI Slot 3 (PCI bus 2, device 0, function 0)

Notice that the PCI Slot number is not the same as the PCI device number.

Note that in this system, all of the on-board devices are located on PCI bus
0, the video adapter is on the AGP bus (PCI bus 1), and all of the physical
PCI slots are on PCI bus 2.

As I mentioned before, the slot number is off by 2 (3 vs. 1) from the actual
slot numbers printed on the motherboard. This must be a bug in the BIOS
code that reports the slot assignments for this particular motherboard. I
know that when I’ve had other boards in the system, they also reported a
slot number that was off by 2.

Most annoying to have such a feature, only to have the data be WRONG.

- Jay

Jay Talbott
Principal Consulting Engineer
SysPro Consulting, LLC
3519 E. South Fork Drive
Suite 201
Phoenix, AZ 85044
(480) 704-8045
xxxxx@sysproconsulting.com
http://www.sysproconsulting.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
> Sent: Friday, October 24, 2003 9:23 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: determine the card number
>
>
> I don’t think it is a bios bug so much as the pci
> chipset/motherboard have
> embedded devices occupying a couple of ‘slots’ while the
> engineer designing
> the motherboard layout just labels the physical slots
> starting from 0 or 1.
>
>
> =====================
> Mark Roddy
>
>
> > -----Original Message-----
> > From: Jay Talbott [mailto:xxxxx@sysproconsulting.com]
> > Sent: Friday, October 24, 2003 11:34 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Re: determine the card number
> >
> >
> > If only the number returned actually matched the number silk
> > screened on the motherboard…
> >
> > I have test system where those numbers are off by 1 (or maybe
> > they are off by 2, I don’t remember anymore) from the numbers
> > printed on the motherboard.
> >
> > I presume this is a BIOS bug on this particular system, but
> > if my test system can have such a bug, so could the BIOS on
> > any system out there. Thus, it makes me question the
> > usefulness of telling a client that putting a board into the
> > slot labelled ‘3’ on the motherboard will mean that Windows
> > will report it as being in slot number 3.
> >
> > - Jay
> >
> > Jay Talbott
> > Principal Consulting Engineer
> > SysPro Consulting, LLC
> > 3519 E. South Fork Drive
> > Suite 201
> > Phoenix, AZ 85044
> > (480) 704-8045
> > xxxxx@sysproconsulting.com
> > http://www.sysproconsulting.com
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
> > > Sent: Thursday, October 23, 2003 4:44 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: [ntdev] Re: determine the card number
> > >
> > >
> > > > Thanks Don, the
> > > IoGetDeviceProperty(…DevicePropertyUINumber…) is a very
> > > > useful for me! I tried it out and the returned value
> > > actually corresponds
> > > > to the PCI slot number. That means as long as the PC has
> > power, this
> > > > number will not change for the same card and is a warranty
> > > that created
> > >
> > > This number comes from the ACPI BIOS, and should never change
> > > for a slot on
> > > a given machine (except possibly wiht a BIOS upgrade). It
> > > isn’t dependent
> > > on which board is in the slot, it is simply a property of
> the slot.
> > >
> > > 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@sysproconsulting.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@stratus.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@sysproconsulting.com
To unsubscribe send a blank email to xxxxx@lists.osr.com