“Error WDTF_PNP : Result: Failed to receive IRP_MN_REMOVE_DEVICE after receiving IRP_MN_SURPRISE_REMOVAL. etc”
Note this is with my filter driver NOT installed.
Intelppm.sys causes a Verfier BSOD about memory leaks, details posted in my ‘Window8 Test Signing Fun’ thread a day or so ago.
Not that I care particularly, when I do my submission I will provide the HCT logs and dump files and get a signature anyway, but I just thought someone at Microsoft might like to know and perhaps mention to the companies concerned that their code is failing.
Of course I really expect nothing to be done and for me to be wasting my time here, but hey ho, such is life.
No takers?
OK, I will address this to the WHQL forum.
matt sykes wrote:
No takers?
What do you expect them to do? Drop everything and fix this for tomorrow on Windows Update?
Frankly I doubt anyone at MSFT appreciates you “turning over rocks” in this manner, and you’re probably engendering a lot of ill will with those same folks who you’re going to need help from the next time you make another unsupported spelunking trip in the OS’s innards…
Is that driver even removable?
> What do you expect them to do? Drop everything and fix this for tomorrow on
Windows Update?
What do I expect MSFT to do? How about reply to my post asking for the HCT version I am using and say they will test it.
As for ‘turning over rocks’ I really have little idea what you mean, but I dont see how informing MSFT of problems in the code they ship a bad thing. Heck, I would welcome the feedback from engineers testing and finding faults in my code!
As for ‘spelunking’ (what ever that is) into the OS innards, let me refer you to this chunk f code from Intel: http://software.intel.com/en-us/articles/intel-performance-counter-monitor-a-better-way-to-measure-cpu-utilization “We have implemented a basic set of routines with a high level interface that are callable from user C++ application and provide various CPU performance metrics in real-time.”, code that is packed full of wrmsr calls to the CPU perf ctl.
Look, it is not a religion, the OS is not sacrosanct, it is a tool, a tool to be used. The product I am working on calls for it to be used in a particular way, and is sucessfull in doing so, and is prfectly safe and stable.
So for once can we leave the religious fervour to those more suited to it and behave a bit more like engineers?
> Is that driver even removable?
Thats what I thought, yet the CPU test is doing exactly that. I suspect therefore that the CPU drivers, AMDppm.sys and Intelppm.sys are in fact just power policy managers, as the name suggests, and dont really do much else.
If that’s what you looking for, open a support incident. That’s the recommended path on the WHQL web site.
So? Because Intel does it, it means it’s a good idea? Or it’s OK to WMSR for perf control, so it should be OK to do it for some other reason?
The problem is that you INSIST on using the tool incorrectly and then complaining about it. A wrench is not a hammer.
This argument is often the last refuge of the desperate. “What I’m doing is justified as engineering.” But nothing could be further from the truth. It’s like you’re arguing that it’s OK to cut a hole in the side of a 747 when you need ventilation mid-flight, instead of using the little air duct over your seat. “I’m talking about a SMALL hole. There are already LOTS of holes in the plane. There are even DOORS that can be opened, for goodness sakes!! A plane is just a tool. It’s not sacrosanct.” Uh huh… outstandingly sound technical argument. Just use the little air vent and you’ll be fine. But, no… somebody who doesn’t know better wants to pay you to create a hole and gosh darn it, a hole WILL be created!
Peter
OSR
>The problem is that you INSIST on using the tool incorrectly and then
complaining about it. A wrench is not a hammer.
It isnt me complaining about the tool, it is HCT. Remember IT is saying amdppm.sys is failing when my driver ISNT loaded.
If you want an analogy a better one would be using a drill as a screw driver; wasnt designed for that job, but is very effective none the less. Cutting chunks out of dural is a different matter entirely.
So anyway, like I said, the design actually works very well. The only issues seen in testing have been in the OSPPM drivers that ship with Windows. Concerns over access to MSRs in general are unjustified because clearly given the number of MSRs there are they are already accessed by a number of different components concurently. So what will be the effect of the OSPPM writing to PERF_CTL at the same time as my driver, call it a SOSPPM? Two threads setting up registers and calling an assembly instruction. How would the thread descheduling and rescheduling mechanism cause any problems here?
Of course when a thread is rescheduled the registers and stack are restored and the call to wrmsr is atomic so in fact there are no concurrency issues.
Implementing the same functionality on Linux is interesting. The CPU driver registers a Target function (which does the wrmsr) with the cpufreq driver and it exposes a cpufreq_driver_target call for drivers to use in order to set the CPU speed. Interesting change in implementation, but a broadly similar architecture to windows in many ways.
Are the MSR registers handled in thread context switches? In older
versions of Windows when these first came out they definitely were not
swapped in context switches. I worked with a firm that was wondering
why a tool they bought was failing on a few systems, turned out that
SysIntenals tool that use the MSR’s was also on the systems and they had
a conflict.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:
> Of course when a thread is rescheduled the registers and stack are restored and the call to wrmsr is atomic so in fact there are no concurrency issues.
>
> Implementing the same functionality on Linux is interesting. The CPU driver registers a Target function (which does the wrmsr) with the cpufreq driver and it exposes a cpufreq_driver_target call for drivers to use in order to set the CPU speed. Interesting change in implementation, but a broadly similar architecture to windows in many ways.
If eax edx and ecx werent saved during a context switch then no code would even run after being rescheduled whether it was using MSRs or not, since those registers are used all the time.
Imagine if you had a func that returned a memory address in ecx and it got overwritten after a thread switch and wasnt restored when the original thread rescheduled, you would have an invalid address and BSODs all over the place.
The issue you had then was probably due to the actual effect on the CPU of writing to those MSrs, ie, changing its state to something incompatible with what the other program expected.
Does anyone here still think that:
-
There are concurrency issues doing a wrmsr on PERF_CTL given that Intel provides a library for any application to do so and that register state is preserved on a context switch while Pstate control is acchieved through a single call to the atomic wrmsr.
-
Since the driver checks the CPU support for MSRs and support for Pstates that any CPU can be damaged by writing those values to the MSR.
-
The use of the machine is being compromised in any way given that the driver is a filter driver that does not replace the ppm.sys but only throttles the CPU the application work thread is running on and when that thread is no longer running leaves the CPU speed alone.
-
There are any legal issues involved and that the machine is being misused given that the functionality is advertised.
I know the idea of what this product is doing caused a lot of concern when I originally posted about it but I think those concerns have been shown to be unjustified.
My professional opinion is that your current implementation is unnecessary, unwise, and introduces potential problems with Windows OS components.
Peter
OSR
Thank you for your reply Peter.
I think the potential problems have been answered in my post above, ie, there arent any.
As for unnecessary, unlike a sleep() in user mode, the kernel approach I have taken really does run the CPU slow regardless of the load on that CPU and is far more effective. ie the CPU speed isnt jumping up and down which is what ‘heavy load’ sleep ‘heavy load’ would do.
As for unwise, that depends on #1.
Based on the lack on any concrete evidence to the contrary I will recomend that the kernel solution is adopted.
Thanks for your input everyone.
You just touched the surface of testing and scenarios you need to validate. It works in my machine is insufficient.
Just because Intel has a driver that does it, doesn’t justify you doing it. Did you read the terms of their release? I bet you can’t use it in a production or server or factory floor environment. In other words, it is their for personal use at your own risk.
d
Bent from my phone
From: xxxxx@hotmail.commailto:xxxxx
Sent: ?4/?16/?2013 8:13 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] AMDppm.sys fails HCT
Thank you for your reply Peter.
I think the potential problems have been answered in my post above, ie, there arent any.
As for unnecessary, unlike a sleep() in user mode, the kernel approach I have taken really does run the CPU slow regardless of the load on that CPU and is far more effective. ie the CPU speed isnt jumping up and down which is what ‘heavy load’ sleep ‘heavy load’ would do.
As for unwise, that depends on #1.
Based on the lack on any concrete evidence to the contrary I will recomend that the kernel solution is adopted.
Thanks for your input everyone.
—
NTDEV is sponsored by OSR
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>
I have not been following the thread closely. From what I read, you are
modify the state of some resources that you don’t own without coordination
with it’s owner. Yes, you might be able to solve concurrency access and
thread context problems.
But how do you ensure the change of resource state won’t affect the owner’s
correct operations AT ALL? The owner may have set the state of the affected
resources to A at earlier point of time, and legitimately but
mistakenly assumes it’s still A (because you have changed it to B without
letting it know) when it’s making its decisions based on the assumed
state at later point. I’m not saying that’s the problem but you know the
detail behavior of the owner to eliminate the possibility entirely? Do you
care a service pack may change the behavior of the owner?
On Sun, Apr 14, 2013 at 1:20 AM, wrote:
> Does anyone here still think that:
>
> 1) There are concurrency issues doing a wrmsr on PERF_CTL given that Intel
> provides a library for any application to do so and that register state is
> preserved on a context switch while Pstate control is acchieved through a
> single call to the atomic wrmsr.
>
> 2) Since the driver checks the CPU support for MSRs and support for
> Pstates that any CPU can be damaged by writing those values to the MSR.
>
> 3) The use of the machine is being compromised in any way given that the
> driver is a filter driver that does not replace the ppm.sys but only
> throttles the CPU the application work thread is running on and when that
> thread is no longer running leaves the CPU speed alone.
>
> 4) There are any legal issues involved and that the machine is being
> misused given that the functionality is advertised.
>
>
>
> I know the idea of what this product is doing caused a lot of concern when
> I originally posted about it but I think those concerns have been shown to
> be unjustified.
>
>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Doran, can you tell me that the registers used in wrmsr are not restored during a thread context switch?
If so you have me worried, but seriously, how can they not be? If they werent then no code would run properly after a context switch. Read my response to Don for more on that.
Calvin, “I have not been following the thread closely. From what I read, you are
modify the state of some resources that you don’t own without coordination
with it’s owner.”
Normally this is a concern, but these are not ‘resources’ in the ordinary sense. The values are set in EDX/EAX and wrmsr is a single assembly instruction and so atomic. A thread context switch must restore register state and since wrmsr is atomic access by two threads is not an issue and thus no locking is required.
Tell me if you believe I am wrong, and show me technical reasons why, but I dont see any problems at all with doing this.
xxxxx@hotmail.com wrote:
Doran, can you tell me that the registers used in wrmsr are not restored during a thread context switch?
I can’t tell which question you are asking. If you’re asking about the
CPU registers involved in the wrmsr instruction, that’s irrelevant,
because the wrmsr instruction cannot be interrupted. Some instructions
can, but not that one.
However, the machine-specific registers themselves are NOT part of the
thread state, so they will not be saved and restored.
Calvin, “I have not been following the thread closely. From what I read, you are
modify the state of some resources that you don’t own without coordination
with it’s owner.”
Normally this is a concern, but these are not ‘resources’ in the ordinary sense. The values are set in EDX/EAX and wrmsr is a single assembly instruction and so atomic. A thread context switch must restore register state and since wrmsr is atomic access by two threads is not an issue and thus no locking is required.
That’s not the point. Calvin’s point is that the MSRs themselves are a
resource that you don’t own. Whoever does own them is making
assumptions based on the values that he stored. You are violating those
assumptions.
Tell me if you believe I am wrong, and show me technical reasons why, but I dont see any problems at all with doing this.
Yes, you have made that clear.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim,
Not sure he will get your point I tried to raise it almost two
weeks ago. You can’t depend on the MSR’s.
Don Burn
Land Preservation and Stewardship
Westborough Community Land Trust
“Tim Roberts” wrote in message news:xxxxx@ntdev:
> xxxxx@hotmail.com wrote:
> > Doran, can you tell me that the registers used in wrmsr are not restored during a thread context switch?
>
> I can’t tell which question you are asking. If you’re asking about the
> CPU registers involved in the wrmsr instruction, that’s irrelevant,
> because the wrmsr instruction cannot be interrupted. Some instructions
> can, but not that one.
>
> However, the machine-specific registers themselves are NOT part of the
> thread state, so they will not be saved and restored.
>
>
> > Calvin, “I have not been following the thread closely. From what I read, you are
> > modify the state of some resources that you don’t own without coordination
> > with it’s owner.”
> >
> > Normally this is a concern, but these are not ‘resources’ in the ordinary sense. The values are set in EDX/EAX and wrmsr is a single assembly instruction and so atomic. A thread context switch must restore register state and since wrmsr is atomic access by two threads is not an issue and thus no locking is required.
>
> That’s not the point. Calvin’s point is that the MSRs themselves are a
> resource that you don’t own. Whoever does own them is making
> assumptions based on the values that he stored. You are violating those
> assumptions.
>
>
> > Tell me if you believe I am wrong, and show me technical reasons why, but I dont see any problems at all with doing this.
>
> Yes, you have made that clear.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.