[HWiNFO32 Thread] - Questions, Reports, Suggestions, Discussions

i may have to say that again. previous version works with 5870s new dell vbios and catalyst 10.10 .

something added on this version conflicts with something probably ULPS. thats the end

 

Seems that only HD5xxx and later support ULPS, olders had removed the ULPS functionality in recent Catalysts.. That explains the difference between you guys...

 

You don't need to repeat yourself, I heard you the first time..
My point is still valid as Mumak stated that the new version raises the probability of a crash.

 

Nice program, i used an old version with no problem so far...
Yesterday i downloaded the last version (portable), i run it on my notebook and i immediatly had a BSOD.

Notebook: Dell Studio 1555
GPU: Ati mobility radeon hd 4570
Driver: AMD ati catalyst 10.10

Hope this will help for future developement

 

Is that a Dual-GPU machine?

 

well, looks like i am not the only unlucky guy here and not only related to 5870s

 

No, it's a single gpu laptop.

 

In case it's a single GPU machine, I'll need a HWiNFO32 Debug File in order to check what's the problem..

 

I'm sure there are more
No response from ATI yet, I guess I'll have to include an option to disable scanning/monitoring of secondary GPU for those which have such issues..

 

why? previous version doesnt do this?

 

Nope.
I already tried to explain the situation:
1. When a secondary GPU is inactive and put into the lowest power mode (ULPS support), it's sensitive to ANY access (register read - like read clock speed or temperature). So any access can crash it, however this doesn't happen in 100% of cases, but the more you access it the higher the probability.
2. ULPS is available from Cat 10.2 for Win7 and HD 4xxx and later, however some later Cat (.9 or .10) removed ULPS support for HD 4xxx, so only HD 5xxx are affected.
3. Previous HWiNFO32 versions featured a limited communication with secondary GPU, but I added much more access to it in the latest version in order to improve support.
4. I had rare report of crashes because of ULPS, but this was quite random so far. Because the latest version adds more access, the crash probability seems to be much higher now.
5. There is no known workaround available how to avoid this, since you can't even determine that a GPU is in such state when you can't even read its registers to check the state. I believe this is an issue ATI should fix, since for customers it's not possible. I haven't got any feedback from ATI on this issue yet. Previously they were suggesting to switch to their ADL, however this interface is EXTREMELY slow, so I don't accept such a solution.
=> Currently there's probably no other way than to let user disable access to secondary GPU if it crashes the system..

 

If you tell me exactly what should i send you i'll be happy to help.
Sorry but i'm quite noob about this kind of problems.

 

then i guess i prefer to use previous version with limited access to secondary gpu than disabling ULPS and have permanent higher temps on both gpus. Till the issue is fixed

 

Launch HWiNFO32 but don't start the scan, press "Configure" and enable "Debug Mode", then continue. After the machine crashes, reboot and then please send me the HWiNFO32.DBG file that was created.

 

Man...i just tried to do what you told me...
the result is...no crash
Don't know why, but it seems stable now.
If it will crash however i'll send you the file you need.

 

Try to disable Debug Mode back to see if it works then too.

 

I'm working on a patch.. should be ready soon

 

Here's the patch (currently experimental):
www.hwinfo.com/beta/hw32_361_1009.zip
Please let me know how it works and if it helped.
Also a HWiNFO32.DBG file would be useful for me in any case, so I can verify internally how it works..

 

I tried that, after i launched in Debug mode (with no crash) i reconfigured it unchecking the Debug mode, and it still works.
No crush until now.
Strange behaviour but ... it works

 

There is an autostart option but the UAC prompt pops up after reboot.
Can this popup be avoided?
It would be nice if Hwinfo32 could remember the setting of the fancontrol feature. I have a HP 8530w and use this feature to reduce the noise of the fan.
There should be an option to specify this.

 

well it does work!

 

HWiNFO32 v3.61-1011 Beta available.
Changes:

• Added patch for BSOD on multi-GPU machines in case ULPS powers down a GPU.

 

Hi Mumak,

Any ideas why when i have sensors monitoring with HWiNFO32 version 3.61-992 which i use with your sidebar gadget i see the Intel boost monitor in the side bar fluctuating .If i disable the sensor monitoring i no longer see the fluctuating in the Intel boost monitor on the sidebar.I changed power plan's & it makes no differance.I was seeing this with both cpu's i have i7 620M & i7 920XM .In previous version's of HWiNFO32 i never seen this before .

 

i have another question about the hwinfo sidebar

when i load the hwino with minimized sensors the sensors dont appear on the sidebar. I have to run sensors through the hwinfo taskbar icon, wait for them to appear on sidebar and then minimize them again.

 

Try to disable the readings (or whole sensors) one by one and check when the Intel monitor stops fluctuating. It's possible that some of the sensor methods raises the CPU load. When you determine which one causes it, I can check what I can do about it...
You might also want to use the latest HWiNFO32 Beta available.

 

I have tried to reproduce this issue, but for me it works.
Please attach some screenshots - the HWiNFO32 Configuration you use, the Sensor configuration used and more behaviour.

 

Hi Mumak,

I tried what you suggested disabling sensors one at a time but could not pin it down to one individual sensor.Only when i disable sensors does the fluctuating stop on Intel boost monitor,I installed beta but same thing as nobody with a M17x R2 has previously reported this i am guessing its something @ my side maybe.Will try a few things will post if i find it.Thanks.

 

HWiNFO32 v3.61-1014 Beta available.
Changes:

• Fixed rare hang during CPU scan caused by HPET timers.

+ various other improvements..

 

Mumak do you have any idea why i get this X on my cpu 3 temprerature sensor?



here is the debug file

 

Can't you just right-click and select Enable Monitoring on it?

 

you are the man. it was so easy. I cant think how it changed setting by its own..

 

I actually have everything disabled (by choice) except for GPU Thermal Diode for both cards and CPU core temps. Everything else is gone.

 

why did you do that? it uses less ram or loads faster?

 

I haven't tested either one of those outcomes. Maybe. But I do it because I usually disable things I don't need in general, not just with this app.

So, unless, of course, Mumak says that they have to be enabled or my readings will be incorrect or something like that (which is very unlikely) I will leave them off.

OCDs maybe, ha!

 

You can disable any readings you wish, they don't depend on each other. Reading from some types of sensors might cause a small performance impact, so if you really don't need some values you can disable them - there's no disadvantage by doing that.

 

this cpu3 temperature monitor gets disabled eveytme i restart my machine. I have to enable every time. any clue?

 

Try to go to Configure and click "Clear Preferences"

 

worked again!

 

HWiNFO32 v3.62 available.
Changes:

• Added monitoring of fan speed on certain Toshiba notebooks (with TVALZ driver).
• Various minor fixes and updates.
• Fixed Multi-GPU support in case of different brand/model GPUs.
• Added nVidia GeForce GT 440, GeForce GT 555M, GeForce GTX 580, GF110/D13U.
• Enhanced support of Cedarview.
• Added patch for BSOD on multi-GPU machines in case ULPS powers down a GPU.
• Fixed rare hang during CPU scan caused by HPET timers.
• Enhanced sensor monitoring on Biostar TPower I45, MSI Big Bang-XPower (MS-7666).
• Enhanced support of some PMBus capable sensors.
• Added reporting of maximum supported PCIe and USB version on system.

 

Martin, while dynamic FSB is in operation, ie halved, HWinfo32 also shows the RAM clock halving. Are you sure this is correct?

 

Well, I'm not absolutely sure about this.
In fact during DFSB (BusGV) mode there are Duty Cycles inserted into the external clock which causes the operating frequency to halve. The measured CPU clock and multipliers are really as reported (reflected by the Duty Cycles), but I don't know what effect this has on Memory Clock. Maybe the true clock speed is not modified, but the real performance is halved.

 

Duty cycles, would you explain a little further? My own thoughts were that it was controlled by the internal PLL's and the special handshake, but with it being AFAIK undocumented publicly other than to say it is effectively halved internally, it's hard to know and just sheer speculation on my part.

I had always hoped the memory clocked halved since this would have possibly allowed exploitation of being able to use up to double the HFM multiplier to gain up to twice the rated CPU frequency, CPU permitting, by being able to use up to twice the external BCLK. Unfortunately everything I had tried seems to suggest that the memory clock is not changing.

Running a MaxxMem bench with one SODIMM / single channel, would show a 40% read gain over maximum theoretical bandwidth if the memory clock was halved but then I can not be certain if MaxxMem is giving the correct result or not.

 

anyone knows if hwinfo reads the Transcend TS512MSK64V3N temps?

 

I guess it's similar to TM2, where the clock frequency generated remains the same, but there are penalty cycles inserted in order to reduce the final clock. I saw a nice picture about this somewhere, but can't find it anymore

 

That module doesn't seem to feature a DIMM Thermal Sensor, so it's not possible.

 

I think you mean TM1. IIRC TM2 drops the VID/FID and TM1 actually throttles the clock. Also I think I did some testing that showed DFSB didn't work like TM1, I'll have to have a dig around and see if I can find it.

EDIT: Okay, here's some bits and pieces.

A discussion I had with Franck some time ago.
Mobile Core2 SuperLFM
Basically if it were a duty cycle then I can not see how SLFM would work with the lower VID.

From Intels C2D Mobile datasheet,

There's a nice timing table too.

Due you know if it's possibly to change the memory clock on the fly while OS is up? It might make testing easier.

 

maybe i shouldnt ask you but is there any 4GB sodimm ddr3 1333mhz ram module with thermal sensor? What about this KVR1333D3S9/4G ?

 

I had a similar discussion longer ago with Franck (of CPU-Z) and it was him who pursued the idea of duty cycles. I have to say, that I never made a deeper research in this topic, so I believed him

 

I dunno. You need to check respective datasheets (which are commonly available) if the module supports DIMM Thermal Sensor (it might be referred as JC-42.4 or TSE2002 as well).

 

Ahh, okay, I thought you had some ummm, special info .