Ugly pci problem

I support a driver and pci hardware that goes into an embedded Windows 2K/XP
system. I have recently converted the driver into a fully WDM driver,
removing lots of obsolete Hal* calls.

Our PCI hardware has a problem. The eeprom that contains the information
that is downloaded into the PCI bridge chip on rare (not rare enough)
occasionally “scrambles”. We don’t yet completely understand why it happens.
That eeprom contains our vendor and product ID (among aother stuff), and my
driver loads against those ids. When it scrambles, it usually scrambles in
such a way that the bridge chip recognizes that the product and vendor id
info coming from the eeprom is invalid, and defaults to its own product and
vendor id. I can and do load my driver against those also. I can get away
with this becasue we are an embedded system, and no customer can add or
remove PCI devices that might potentially use those id’s.

If the eeprom scrambles such that the ids are considered valid by the bridge
chip, but they are not the ones I know about, my driver won’t load, and
worst case some other driver might load! I have never seen that happen, but
it is just a matter of time.

So, if I go back to using the Hal* calls, I can probably find the pci
device, and attempt to clean it up. I know the bus number and slots that the
card could be in, so I could find it. But, the Hal* calls are supposed to be
obsolete. Should I use them? When are they REALLY going to be obsolete?
Longhorn? I wish MS woudl give us a drop dead release past which the
obsolete calls are really obsolete! It is hard to tell my boss that I
shouldn’t use those calls to fix this problem, if they are going to exist
into Longhorn.

Niels Jensen

Try reworking the INF file to force your driver being loaded for both
“normal” and “scrambled” IDs.

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

----- Original Message -----
From: “Niels Jensen”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Wednesday, July 27, 2005 6:21 PM
Subject: [ntdev] Ugly pci problem

> I support a driver and pci hardware that goes into an embedded Windows 2K/XP
> system. I have recently converted the driver into a fully WDM driver,
> removing lots of obsolete Hal* calls.
>
> Our PCI hardware has a problem. The eeprom that contains the information
> that is downloaded into the PCI bridge chip on rare (not rare enough)
> occasionally “scrambles”. We don’t yet completely understand why it happens.
> That eeprom contains our vendor and product ID (among aother stuff), and my
> driver loads against those ids. When it scrambles, it usually scrambles in
> such a way that the bridge chip recognizes that the product and vendor id
> info coming from the eeprom is invalid, and defaults to its own product and
> vendor id. I can and do load my driver against those also. I can get away
> with this becasue we are an embedded system, and no customer can add or
> remove PCI devices that might potentially use those id’s.
>
> If the eeprom scrambles such that the ids are considered valid by the bridge
> chip, but they are not the ones I know about, my driver won’t load, and
> worst case some other driver might load! I have never seen that happen, but
> it is just a matter of time.
>
> So, if I go back to using the Hal* calls, I can probably find the pci
> device, and attempt to clean it up. I know the bus number and slots that the
> card could be in, so I could find it. But, the Hal* calls are supposed to be
> obsolete. Should I use them? When are they REALLY going to be obsolete?
> Longhorn? I wish MS woudl give us a drop dead release past which the
> obsolete calls are really obsolete! It is hard to tell my boss that I
> shouldn’t use those calls to fix this problem, if they are going to exist
> into Longhorn.
>
> Niels Jensen
>
>
>
> —
> 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

What do you do in the “attempt to clean it up” portion of the code? Are
you going to try and poke the device to reset it?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Niels Jensen
Sent: Wednesday, July 27, 2005 7:21 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Ugly pci problem

I support a driver and pci hardware that goes into an embedded Windows
2K/XP system. I have recently converted the driver into a fully WDM
driver, removing lots of obsolete Hal* calls.

Our PCI hardware has a problem. The eeprom that contains the information
that is downloaded into the PCI bridge chip on rare (not rare enough)
occasionally “scrambles”. We don’t yet completely understand why it
happens.
That eeprom contains our vendor and product ID (among aother stuff), and
my driver loads against those ids. When it scrambles, it usually
scrambles in such a way that the bridge chip recognizes that the product
and vendor id info coming from the eeprom is invalid, and defaults to
its own product and vendor id. I can and do load my driver against those
also. I can get away with this becasue we are an embedded system, and no
customer can add or remove PCI devices that might potentially use those
id’s.

If the eeprom scrambles such that the ids are considered valid by the
bridge chip, but they are not the ones I know about, my driver won’t
load, and worst case some other driver might load! I have never seen
that happen, but it is just a matter of time.

So, if I go back to using the Hal* calls, I can probably find the pci
device, and attempt to clean it up. I know the bus number and slots that
the card could be in, so I could find it. But, the Hal* calls are
supposed to be obsolete. Should I use them? When are they REALLY going
to be obsolete?
Longhorn? I wish MS woudl give us a drop dead release past which the
obsolete calls are really obsolete! It is hard to tell my boss that I
shouldn’t use those calls to fix this problem, if they are going to
exist into Longhorn.

Niels Jensen


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

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

I don’t understand what you mean.
I don’t know the scrambled ID’s. They could be any 32 bit value. So I cannot
put the ID into the inf file.

Maybe I could do something to force load the driver, but how does the the
PNP manager know to connect the hardware to my driver? How does the PNP
manager know which hardware to load the driver against? What is the FDO?
passed to me in my AddDevice routine?

Niels

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> Try reworking the INF file to force your driver being loaded for both
> “normal” and “scrambled” IDs.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Niels Jensen”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, July 27, 2005 6:21 PM
> Subject: [ntdev] Ugly pci problem
>
>
>> I support a driver and pci hardware that goes into an embedded Windows
>> 2K/XP
>> system. I have recently converted the driver into a fully WDM driver,
>> removing lots of obsolete Hal* calls.
>>
>> Our PCI hardware has a problem. The eeprom that contains the information
>> that is downloaded into the PCI bridge chip on rare (not rare enough)
>> occasionally “scrambles”. We don’t yet completely understand why it
>> happens.
>> That eeprom contains our vendor and product ID (among aother stuff), and
>> my
>> driver loads against those ids. When it scrambles, it usually scrambles
>> in
>> such a way that the bridge chip recognizes that the product and vendor id
>> info coming from the eeprom is invalid, and defaults to its own product
>> and
>> vendor id. I can and do load my driver against those also. I can get away
>> with this becasue we are an embedded system, and no customer can add or
>> remove PCI devices that might potentially use those id’s.
>>
>> If the eeprom scrambles such that the ids are considered valid by the
>> bridge
>> chip, but they are not the ones I know about, my driver won’t load, and
>> worst case some other driver might load! I have never seen that happen,
>> but
>> it is just a matter of time.
>>
>> So, if I go back to using the Hal* calls, I can probably find the pci
>> device, and attempt to clean it up. I know the bus number and slots that
>> the
>> card could be in, so I could find it. But, the Hal* calls are supposed to
>> be
>> obsolete. Should I use them? When are they REALLY going to be obsolete?
>> Longhorn? I wish MS woudl give us a drop dead release past which the
>> obsolete calls are really obsolete! It is hard to tell my boss that I
>> shouldn’t use those calls to fix this problem, if they are going to exist
>> into Longhorn.
>>
>> Niels Jensen
>>
>>
>>
>> —
>> 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
>
>

Worst case, I can rewrite the eeprom, and force a reboot.

Best case, most of the eeprom is correct, but it incorrectly identifies
itself. If only I can load my driver against the incorrect ID, then
everything still works. I could fix up the eeprom in this case also.

Niels

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
What do you do in the “attempt to clean it up” portion of the code? Are
you going to try and poke the device to reset it?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Niels Jensen
Sent: Wednesday, July 27, 2005 7:21 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Ugly pci problem

I support a driver and pci hardware that goes into an embedded Windows
2K/XP system. I have recently converted the driver into a fully WDM
driver, removing lots of obsolete Hal* calls.

Our PCI hardware has a problem. The eeprom that contains the information
that is downloaded into the PCI bridge chip on rare (not rare enough)
occasionally “scrambles”. We don’t yet completely understand why it
happens.
That eeprom contains our vendor and product ID (among aother stuff), and
my driver loads against those ids. When it scrambles, it usually
scrambles in such a way that the bridge chip recognizes that the product
and vendor id info coming from the eeprom is invalid, and defaults to
its own product and vendor id. I can and do load my driver against those
also. I can get away with this becasue we are an embedded system, and no
customer can add or remove PCI devices that might potentially use those
id’s.

If the eeprom scrambles such that the ids are considered valid by the
bridge chip, but they are not the ones I know about, my driver won’t
load, and worst case some other driver might load! I have never seen
that happen, but it is just a matter of time.

So, if I go back to using the Hal* calls, I can probably find the pci
device, and attempt to clean it up. I know the bus number and slots that
the card could be in, so I could find it. But, the Hal* calls are
supposed to be obsolete. Should I use them? When are they REALLY going
to be obsolete?
Longhorn? I wish MS woudl give us a drop dead release past which the
obsolete calls are really obsolete! It is hard to tell my boss that I
shouldn’t use those calls to fix this problem, if they are going to
exist into Longhorn.

Niels Jensen


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

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

You have a hardware problem that cannot be resolved in software. The
config space for the device has to be stabile when the device is
enumerated, thems the rules.

The pnp manager uses the config space did/vid to connect hardware to
driver. How the heck is that going to work if your totally broken
hardware can’t provide anything but random bits?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Niels Jensen
Sent: Thursday, July 28, 2005 6:34 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Ugly pci problem

I don’t understand what you mean.
I don’t know the scrambled ID’s. They could be any 32 bit value. So I
cannot
put the ID into the inf file.

Maybe I could do something to force load the driver, but how does the
the
PNP manager know to connect the hardware to my driver? How does the PNP
manager know which hardware to load the driver against? What is the FDO?

passed to me in my AddDevice routine?

Niels

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> Try reworking the INF file to force your driver being loaded for
both
> “normal” and “scrambled” IDs.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Niels Jensen”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, July 27, 2005 6:21 PM
> Subject: [ntdev] Ugly pci problem
>
>
>> I support a driver and pci hardware that goes into an embedded
Windows
>> 2K/XP
>> system. I have recently converted the driver into a fully WDM driver,
>> removing lots of obsolete Hal* calls.
>>
>> Our PCI hardware has a problem. The eeprom that contains the
information
>> that is downloaded into the PCI bridge chip on rare (not rare enough)
>> occasionally “scrambles”. We don’t yet completely understand why it
>> happens.
>> That eeprom contains our vendor and product ID (among aother stuff),
and
>> my
>> driver loads against those ids. When it scrambles, it usually
scrambles
>> in
>> such a way that the bridge chip recognizes that the product and
vendor id
>> info coming from the eeprom is invalid, and defaults to its own
product
>> and
>> vendor id. I can and do load my driver against those also. I can get
away
>> with this becasue we are an embedded system, and no customer can add
or
>> remove PCI devices that might potentially use those id’s.
>>
>> If the eeprom scrambles such that the ids are considered valid by the

>> bridge
>> chip, but they are not the ones I know about, my driver won’t load,
and
>> worst case some other driver might load! I have never seen that
happen,
>> but
>> it is just a matter of time.
>>
>> So, if I go back to using the Hal* calls, I can probably find the pci
>> device, and attempt to clean it up. I know the bus number and slots
that
>> the
>> card could be in, so I could find it. But, the Hal* calls are
supposed to
>> be
>> obsolete. Should I use them? When are they REALLY going to be
obsolete?
>> Longhorn? I wish MS woudl give us a drop dead release past which the
>> obsolete calls are really obsolete! It is hard to tell my boss that I
>> shouldn’t use those calls to fix this problem, if they are going to
exist
>> into Longhorn.
>>
>> Niels Jensen
>>
>>
>>
>> —
>> 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@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

I agree with you. I can’t see any way to recover, assuming I don’t use the
Hal* calls which are obsolete.

I do know exactly where my board is going to be in our embedded system (pci
bus and slot numbers), so I can use the Hal* calls to get to the board, and
possibly fix it. I don’t want to do it, because they are obsolete! But it
would work.

I guess I am looking for two things…

  1. Confirmation that there is no “legal” way to do it.

  2. When is the illegal way REALLY going to be obsolete? I realize I probably
    won’t get an answer, but I can vent :frowning:

Thanks for the discussion!

Niels

“Roddy, Mark” wrote in message news:xxxxx@ntdev…
You have a hardware problem that cannot be resolved in software. The
config space for the device has to be stabile when the device is
enumerated, thems the rules.

The pnp manager uses the config space did/vid to connect hardware to
driver. How the heck is that going to work if your totally broken
hardware can’t provide anything but random bits?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Niels Jensen
Sent: Thursday, July 28, 2005 6:34 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Ugly pci problem

I don’t understand what you mean.
I don’t know the scrambled ID’s. They could be any 32 bit value. So I
cannot
put the ID into the inf file.

Maybe I could do something to force load the driver, but how does the
the
PNP manager know to connect the hardware to my driver? How does the PNP
manager know which hardware to load the driver against? What is the FDO?

passed to me in my AddDevice routine?

Niels

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> Try reworking the INF file to force your driver being loaded for
both
> “normal” and “scrambled” IDs.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Niels Jensen”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, July 27, 2005 6:21 PM
> Subject: [ntdev] Ugly pci problem
>
>
>> I support a driver and pci hardware that goes into an embedded
Windows
>> 2K/XP
>> system. I have recently converted the driver into a fully WDM driver,
>> removing lots of obsolete Hal* calls.
>>
>> Our PCI hardware has a problem. The eeprom that contains the
information
>> that is downloaded into the PCI bridge chip on rare (not rare enough)
>> occasionally “scrambles”. We don’t yet completely understand why it
>> happens.
>> That eeprom contains our vendor and product ID (among aother stuff),
and
>> my
>> driver loads against those ids. When it scrambles, it usually
scrambles
>> in
>> such a way that the bridge chip recognizes that the product and
vendor id
>> info coming from the eeprom is invalid, and defaults to its own
product
>> and
>> vendor id. I can and do load my driver against those also. I can get
away
>> with this becasue we are an embedded system, and no customer can add
or
>> remove PCI devices that might potentially use those id’s.
>>
>> If the eeprom scrambles such that the ids are considered valid by the

>> bridge
>> chip, but they are not the ones I know about, my driver won’t load,
and
>> worst case some other driver might load! I have never seen that
happen,
>> but
>> it is just a matter of time.
>>
>> So, if I go back to using the Hal* calls, I can probably find the pci
>> device, and attempt to clean it up. I know the bus number and slots
that
>> the
>> card could be in, so I could find it. But, the Hal* calls are
supposed to
>> be
>> obsolete. Should I use them? When are they REALLY going to be
obsolete?
>> Longhorn? I wish MS woudl give us a drop dead release past which the
>> obsolete calls are really obsolete! It is hard to tell my boss that I
>> shouldn’t use those calls to fix this problem, if they are going to
exist
>> into Longhorn.
>>
>> Niels Jensen
>>
>>
>>
>> —
>> 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@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

No that isn’t going to work well either. Suppose the random bits match an
installed device, or any device for which pnp can produce a driver for? Pnp
is going to go off and install that thing. You might be able to get in at
boot time early enough to hide your crapped-out hardware from pnp, but
really you need to get the hardware fixed instead.

If you go the hal route you will not have a pnp driver. You will have a
legacy nt driver for a pci device, and that has issues.

=====================
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 Niels Jensen
Sent: Thursday, July 28, 2005 7:44 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Ugly pci problem

I agree with you. I can’t see any way to recover, assuming I
don’t use the
Hal* calls which are obsolete.

I do know exactly where my board is going to be in our
embedded system (pci bus and slot numbers), so I can use the
Hal* calls to get to the board, and possibly fix it. I don’t
want to do it, because they are obsolete! But it would work.

I guess I am looking for two things…

  1. Confirmation that there is no “legal” way to do it.

  2. When is the illegal way REALLY going to be obsolete? I
    realize I probably won’t get an answer, but I can vent :frowning:

Thanks for the discussion!

Niels

“Roddy, Mark” wrote in message
> news:xxxxx@ntdev…
> You have a hardware problem that cannot be resolved in
> software. The config space for the device has to be stabile
> when the device is enumerated, thems the rules.
>
> The pnp manager uses the config space did/vid to connect
> hardware to driver. How the heck is that going to work if
> your totally broken hardware can’t provide anything but random bits?
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Niels Jensen
> Sent: Thursday, July 28, 2005 6:34 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Ugly pci problem
>
> I don’t understand what you mean.
> I don’t know the scrambled ID’s. They could be any 32 bit
> value. So I cannot put the ID into the inf file.
>
> Maybe I could do something to force load the driver, but how
> does the the PNP manager know to connect the hardware to my
> driver? How does the PNP manager know which hardware to load
> the driver against? What is the FDO?
>
> passed to me in my AddDevice routine?
>
> Niels
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> > Try reworking the INF file to force your driver being loaded for
> both
> > “normal” and “scrambled” IDs.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> > ----- Original Message -----
> > From: “Niels Jensen”
> > Newsgroups: ntdev
> > To: “Windows System Software Devs Interest List”
>
> > Sent: Wednesday, July 27, 2005 6:21 PM
> > Subject: [ntdev] Ugly pci problem
> >
> >
> >> I support a driver and pci hardware that goes into an embedded
> Windows
> >> 2K/XP
> >> system. I have recently converted the driver into a fully
> WDM driver,
> >> removing lots of obsolete Hal* calls.
> >>
> >> Our PCI hardware has a problem. The eeprom that contains the
> information
> >> that is downloaded into the PCI bridge chip on rare (not
> rare enough)
> >> occasionally “scrambles”. We don’t yet completely
> understand why it
> >> happens.
> >> That eeprom contains our vendor and product ID (among
> aother stuff),
> and
> >> my
> >> driver loads against those ids. When it scrambles, it usually
> scrambles
> >> in
> >> such a way that the bridge chip recognizes that the product and
> vendor id
> >> info coming from the eeprom is invalid, and defaults to its own
> product
> >> and
> >> vendor id. I can and do load my driver against those also.
> I can get
> away
> >> with this becasue we are an embedded system, and no
> customer can add
> or
> >> remove PCI devices that might potentially use those id’s.
> >>
> >> If the eeprom scrambles such that the ids are considered
> valid by the
>
> >> bridge
> >> chip, but they are not the ones I know about, my driver won’t load,
> and
> >> worst case some other driver might load! I have never seen that
> happen,
> >> but
> >> it is just a matter of time.
> >>
> >> So, if I go back to using the Hal* calls, I can probably
> find the pci
> >> device, and attempt to clean it up. I know the bus number and slots
> that
> >> the
> >> card could be in, so I could find it. But, the Hal* calls are
> supposed to
> >> be
> >> obsolete. Should I use them? When are they REALLY going to be
> obsolete?
> >> Longhorn? I wish MS woudl give us a drop dead release past
> which the
> >> obsolete calls are really obsolete! It is hard to tell my
> boss that I
> >> shouldn’t use those calls to fix this problem, if they are going to
> exist
> >> into Longhorn.
> >>
> >> Niels Jensen
> >>
> >>
> >>
> >> —
> >> 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@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@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

I had a case once where an eeprom took too long to load, and one
needed to do a soft reboot or else the hardware wouldn’t work.

Alberto.

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

Sent: Wednesday, July 27, 2005 3:17 PM
Subject: RE: [ntdev] Ugly pci problem

What do you do in the “attempt to clean it up” portion of the
code? Are
you going to try and poke the device to reset it?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Niels
Jensen
Sent: Wednesday, July 27, 2005 7:21 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Ugly pci problem

I support a driver and pci hardware that goes into an embedded
Windows
2K/XP system. I have recently converted the driver into a fully
WDM
driver, removing lots of obsolete Hal* calls.

Our PCI hardware has a problem. The eeprom that contains the
information
that is downloaded into the PCI bridge chip on rare (not rare
enough)
occasionally “scrambles”. We don’t yet completely understand why
it
happens.
That eeprom contains our vendor and product ID (among aother
stuff), and
my driver loads against those ids. When it scrambles, it usually
scrambles in such a way that the bridge chip recognizes that the
product
and vendor id info coming from the eeprom is invalid, and
defaults to
its own product and vendor id. I can and do load my driver
against those
also. I can get away with this becasue we are an embedded
system, and no
customer can add or remove PCI devices that might potentially
use those
id’s.

If the eeprom scrambles such that the ids are considered valid
by the
bridge chip, but they are not the ones I know about, my driver
won’t
load, and worst case some other driver might load! I have never
seen
that happen, but it is just a matter of time.

So, if I go back to using the Hal* calls, I can probably find
the pci
device, and attempt to clean it up. I know the bus number and
slots that
the card could be in, so I could find it. But, the Hal* calls
are
supposed to be obsolete. Should I use them? When are they REALLY
going
to be obsolete?
Longhorn? I wish MS woudl give us a drop dead release past which
the
obsolete calls are really obsolete! It is hard to tell my boss
that I
shouldn’t use those calls to fix this problem, if they are going
to
exist into Longhorn.

Niels Jensen


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

You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.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: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com

> I don’t know the scrambled ID’s. They could be any 32 bit value. So I cannot

put the ID into the inf file.

Then sorry, fix your hardware, it is buggy and Windows-incompatible.

Well, the last chance is to have a PCI bus filter which will patch the QUERY_ID
results for the given slot number to be your real ID. You will also need a UI
tool to specify in what particular slot your hardware is installed, and thus to
manage the filter.

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

Software should be written to hardware, not the other way
around. If Windows can’t handle a piece of hardware, it’s as
much a problem of Windows as it is a problem with the hardware.
Unless of course the hardware isn’t PCI compliant - in which
case the issue has nothing to do with Windows but is rather a
hardware level problem.

But as I pointed out in my previous post, loading stuff from
eeproms sometimes can cause ill effects, and that may have
nothing to do with the OS.

You know, guys, not to come on you too hard, but sometimes the
arrogance contained in some of the posts in this mailing list is
appalling. I really believe we should keep it under wraps. No
matter what the technical issue really is, interacting with a
fellow professional deserves a minimum level of respect and
civility.

Alberto.

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

Sent: Friday, July 29, 2005 7:47 AM
Subject: Re: Re:[ntdev] Ugly pci problem

>> I don’t know the scrambled ID’s. They could be any 32 bit
>> value. So I cannot
>> put the ID into the inf file.
>
> Then sorry, fix your hardware, it is buggy and
> Windows-incompatible.
>
> Well, the last chance is to have a PCI bus filter which will
> patch the QUERY_ID
> results for the given slot number to be your real ID. You will
> also need a UI
> tool to specify in what particular slot your hardware is
> installed, and thus to
> manage the filter.
>
> 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@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

Hi All,

I’ve following this thread for a bit now and have to say that I agree
that the hardware is broken. But I wouldn’t say that this is Windows
incompatible, it is PCI incompatible. If a PCI device can’t id itself
with a fixed VID / DID, then it doesn’t meet PCI specs. You will have
problems in any OS, Windows, Linux, VxWorks, etc. The correct way to
address this is to fix the hardware.

Ok, having said that, I also understand that changing the hardware may
not be an option. In that case you are forced to attempt to work around
this glitch, and it seems that the only way is to rely on the Hal*
routines. I’d bring up these issues to management and warn them that
there’s a strong possibility that this kludge won’t work on future
releases of Windows. Then this becomes a business decision, spend time
and $ to fix the hardware, or kludge the software and risk not being
able to move to future versions of Windows.

Just my $0.02.

Best regards,
-Mike

Alberto Moreira wrote:

Software should be written to hardware, not the other way around. If
Windows can’t handle a piece of hardware, it’s as much a problem of
Windows as it is a problem with the hardware. Unless of course the
hardware isn’t PCI compliant - in which case the issue has nothing to
do with Windows but is rather a hardware level problem.

But as I pointed out in my previous post, loading stuff from eeproms
sometimes can cause ill effects, and that may have nothing to do with
the OS.

You know, guys, not to come on you too hard, but sometimes the
arrogance contained in some of the posts in this mailing list is
appalling. I really believe we should keep it under wraps. No matter
what the technical issue really is, interacting with a fellow
professional deserves a minimum level of respect and civility.

Alberto.

----- Original Message ----- From: “Maxim S. Shatskih”

> To: “Windows System Software Devs Interest List”
> Sent: Friday, July 29, 2005 7:47 AM
> Subject: Re: Re:[ntdev] Ugly pci problem
>
>
>>> I don’t know the scrambled ID’s. They could be any 32 bit value. So
>>> I cannot
>>> put the ID into the inf file.
>>
>>
>> Then sorry, fix your hardware, it is buggy and Windows-incompatible.
>>
>> Well, the last chance is to have a PCI bus filter which will patch
>> the QUERY_ID
>> results for the given slot number to be your real ID. You will also
>> need a UI
>> tool to specify in what particular slot your hardware is installed,
>> and thus to
>> manage the filter.
>>
>> 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@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@hologic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

That is pure bovine scatology Alberto. Software can fix hardware some faux
pax, but sometimes the hardware has such
a problem that trying to fix it using software is asinine, and sometimes
the software simply cannot fix crappy hardware.

I have a current issue before me where a new chip added to the firmware is
screwing up how status is being
reported, causing corruption. Since the HBA driver was written by the HBA
vendor, and my filter driver does not
have the resources that are owned by the HBA mini-port, I can’t deal with
the hardware itself to fix the problem.
Plus, this is not a buggable event since the new chip is forcing an event
outside the scope of the spec, there is not one
god damn thing I can do in software to fix the screw-up of this new chip.Oh
sure, I can cobble together a piece of jury-rigged
offal that might get us by till the chip can be remasked, but it literally
is not worth the time or effort, which would probably take
as much time as remasking the chip.

Sometimes you HAVE to fix that which is broken.


The personal opinion of
Gary G. Little

“Alberto Moreira” wrote in message news:xxxxx@ntdev…
> Software should be written to hardware, not the other way around. If
> Windows can’t handle a piece of hardware, it’s as much a problem of
> Windows as it is a problem with the hardware. Unless of course the
> hardware isn’t PCI compliant - in which case the issue has nothing to do
> with Windows but is rather a hardware level problem.
>
> But as I pointed out in my previous post, loading stuff from eeproms
> sometimes can cause ill effects, and that may have nothing to do with the
> OS.
>
> You know, guys, not to come on you too hard, but sometimes the arrogance
> contained in some of the posts in this mailing list is appalling. I really
> believe we should keep it under wraps. No matter what the technical issue
> really is, interacting with a fellow professional deserves a minimum level
> of respect and civility.
>
> Alberto.
>
>
> ----- Original Message -----
> From: “Maxim S. Shatskih”
> To: “Windows System Software Devs Interest List”
> Sent: Friday, July 29, 2005 7:47 AM
> Subject: Re: Re:[ntdev] Ugly pci problem
>
>
>>> I don’t know the scrambled ID’s. They could be any 32 bit value. So I
>>> cannot
>>> put the ID into the inf file.
>>
>> Then sorry, fix your hardware, it is buggy and Windows-incompatible.
>>
>> Well, the last chance is to have a PCI bus filter which will patch the
>> QUERY_ID
>> results for the given slot number to be your real ID. You will also need
>> a UI
>> tool to specify in what particular slot your hardware is installed, and
>> thus to
>> manage the filter.
>>
>> 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@ieee.org
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

The config space requirements for pci device are clearly stated in the pci
specifications. This hardware is broken and needs to be fixed.

=====================
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: Friday, July 29, 2005 8:07 AM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Ugly pci problem

Software should be written to hardware, not the other way
around. If Windows can’t handle a piece of hardware, it’s as
much a problem of Windows as it is a problem with the hardware.
Unless of course the hardware isn’t PCI compliant - in which
case the issue has nothing to do with Windows but is rather a
hardware level problem.

But as I pointed out in my previous post, loading stuff from
eeproms sometimes can cause ill effects, and that may have
nothing to do with the OS.

You know, guys, not to come on you too hard, but sometimes
the arrogance contained in some of the posts in this mailing
list is appalling. I really believe we should keep it under
wraps. No matter what the technical issue really is,
interacting with a fellow professional deserves a minimum
level of respect and civility.

Alberto.

----- Original Message -----
From: “Maxim S. Shatskih”
> To: “Windows System Software Devs Interest List”
>
> Sent: Friday, July 29, 2005 7:47 AM
> Subject: Re: Re:[ntdev] Ugly pci problem
>
>
> >> I don’t know the scrambled ID’s. They could be any 32 bit
> >> value. So I cannot
> >> put the ID into the inf file.
> >
> > Then sorry, fix your hardware, it is buggy and
> > Windows-incompatible.
> >
> > Well, the last chance is to have a PCI bus filter which will
> > patch the QUERY_ID
> > results for the given slot number to be your real ID. You will
> > also need a UI
> > tool to specify in what particular slot your hardware is
> > installed, and thus to
> > manage the filter.
> >
> > 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@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
>

Like I said, it is an ugly problem. I have taken no offense at anything
anyone has written. I am quite happy with blunt answers.

I can’t imagine the nightmare this would be if this were a non-embedded pci
device selling.

Niels Jensen

“Gary G. Little” wrote in message news:xxxxx@ntdev…
> That is pure bovine scatology Alberto. Software can fix hardware some faux
> pax, but sometimes the hardware has such
> a problem that trying to fix it using software is asinine, and sometimes
> the software simply cannot fix crappy hardware.
>
> I have a current issue before me where a new chip added to the firmware is
> screwing up how status is being
> reported, causing corruption. Since the HBA driver was written by the HBA
> vendor, and my filter driver does not
> have the resources that are owned by the HBA mini-port, I can’t deal with
> the hardware itself to fix the problem.
> Plus, this is not a buggable event since the new chip is forcing an event
> outside the scope of the spec, there is not one
> god damn thing I can do in software to fix the screw-up of this new
> chip.Oh sure, I can cobble together a piece of jury-rigged
> offal that might get us by till the chip can be remasked, but it literally
> is not worth the time or effort, which would probably take
> as much time as remasking the chip.
>
> Sometimes you HAVE to fix that which is broken.
>
> –
> The personal opinion of
> Gary G. Little
>
> “Alberto Moreira” wrote in message news:xxxxx@ntdev…
>> Software should be written to hardware, not the other way around. If
>> Windows can’t handle a piece of hardware, it’s as much a problem of
>> Windows as it is a problem with the hardware. Unless of course the
>> hardware isn’t PCI compliant - in which case the issue has nothing to do
>> with Windows but is rather a hardware level problem.
>>
>> But as I pointed out in my previous post, loading stuff from eeproms
>> sometimes can cause ill effects, and that may have nothing to do with the
>> OS.
>>
>> You know, guys, not to come on you too hard, but sometimes the arrogance
>> contained in some of the posts in this mailing list is appalling. I
>> really believe we should keep it under wraps. No matter what the
>> technical issue really is, interacting with a fellow professional
>> deserves a minimum level of respect and civility.
>>
>> Alberto.
>>
>>
>> ----- Original Message -----
>> From: “Maxim S. Shatskih”
>> To: “Windows System Software Devs Interest List”
>> Sent: Friday, July 29, 2005 7:47 AM
>> Subject: Re: Re:[ntdev] Ugly pci problem
>>
>>
>>>> I don’t know the scrambled ID’s. They could be any 32 bit value. So I
>>>> cannot
>>>> put the ID into the inf file.
>>>
>>> Then sorry, fix your hardware, it is buggy and Windows-incompatible.
>>>
>>> Well, the last chance is to have a PCI bus filter which will patch the
>>> QUERY_ID
>>> results for the given slot number to be your real ID. You will also need
>>> a UI
>>> tool to specify in what particular slot your hardware is installed, and
>>> thus to
>>> manage the filter.
>>>
>>> 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@ieee.org
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>

In which case this may not have nothing to do with Windows. I
would try a Linux box to see what happens. And noncompliance
with a hardware standard is very different from not being
appropriate to Windows; a noncompliant hardware is noncompliant
under any OS. But still, that noncompliance must be pegged down,
correctly diagnosed, and then maybe fixed.

Hardware work, eh ? Nothing to do with Windows. Same thing under
Linux.

Alberto.

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

Sent: Friday, July 29, 2005 12:20 PM
Subject: RE: Re:[ntdev] Ugly pci problem

> The config space requirements for pci device are clearly
> stated in the pci
> specifications. This hardware is broken and needs to be fixed.
>
> =====================
> 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: Friday, July 29, 2005 8:07 AM
>> To: Windows System Software Devs Interest List
>> Subject: Re: Re:[ntdev] Ugly pci problem
>>
>> Software should be written to hardware, not the other way
>> around. If Windows can’t handle a piece of hardware, it’s as
>> much a problem of Windows as it is a problem with the
>> hardware.
>> Unless of course the hardware isn’t PCI compliant - in which
>> case the issue has nothing to do with Windows but is rather a
>> hardware level problem.
>>
>> But as I pointed out in my previous post, loading stuff from
>> eeproms sometimes can cause ill effects, and that may have
>> nothing to do with the OS.
>>
>> You know, guys, not to come on you too hard, but sometimes
>> the arrogance contained in some of the posts in this mailing
>> list is appalling. I really believe we should keep it under
>> wraps. No matter what the technical issue really is,
>> interacting with a fellow professional deserves a minimum
>> level of respect and civility.
>>
>> Alberto.
>>
>>
>> ----- Original Message -----
>> From: “Maxim S. Shatskih”
>> To: “Windows System Software Devs Interest List”
>>
>> Sent: Friday, July 29, 2005 7:47 AM
>> Subject: Re: Re:[ntdev] Ugly pci problem
>>
>>
>> >> I don’t know the scrambled ID’s. They could be any 32 bit
>> >> value. So I cannot
>> >> put the ID into the inf file.
>> >
>> > Then sorry, fix your hardware, it is buggy and
>> > Windows-incompatible.
>> >
>> > Well, the last chance is to have a PCI bus filter which
>> > will
>> > patch the QUERY_ID
>> > results for the given slot number to be your real ID. You
>> > will
>> > also need a UI
>> > tool to specify in what particular slot your hardware is
>> > installed, and thus to
>> > manage the filter.
>> >
>> > 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@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