Mumak

In both cases when they launched sensor monitoring in HWiNFO it happened. This can hardly be a coincidence. Though it still can be a design flaw when that 'component' acts this way as a response to I2C read request...

I don't have any other reports from M6500 machines, but I'm nearly sure that nVidia ones are not affected.

Apparently the user has taken the CMOS battery out and it didn't help.

I don't think it's related to EC or ME. Those are different entities and neither of them has access to GPU I2C.

Guys, I run into a difficult situation and need your help.

I got 2 reports from different people with Dell Precision M6500 with ATI FirePro M7820 GPU.

When they run HWiNFO and opened sensors it caused the LCD to loose signal. I believe this has something to do with the GPU I2C device scan HWiNFO performs. HWiNFO performs just READ commands and doesn't alter anything, so such thing should never happen. But is seems that machine with that GPU only has some weird device residing there which goes crazy and disables the LCD after such scan ! Plugging an external monitor seems to work, just the integrated LCD doesn't.

The biggest problem is that the machine won't recover from this state anymore !! Even a total shutdown and removing all power doesn't help. I don't think there's a physical damage to some component, it just seems the BIOS/VBIOS probably don't reinitialize that weird device again and it's stuck in a wrong state. Though I'm not exactly sure what happened there and why, in my opinion this is a design flaw. I have intercepted this in HWiNFO (v4.19-1935 Beta) and I'm disabling the GPU I2C on those machines. I believe other tools like GPU-Z, TRiXX or AIDA64 might be affected as well...

Unfortunately, for a few people it was too late. One of the guys probably ended up with an RMA, but the other unlucky guy bought the new expensive machine without a warranty.

Do you have any idea how this might be fixed ? Please come up with any suggestions...

HWiNFO might not report GPU voltage/clocks on 2nd GPU because of ULPS. When ULPS is active and the 2nd GPU is not utilized, the system shuts down the card completely and you must not touch it on low-level (otherwise you risk a system crash). Maybe that causes problems with flashing too..

So try to put some load on the 2nd GPU or use Sapphire TRiXX to disable ULPS (at least temporary).

Build 1620 (and later) adds preliminary support for fan speed monitoring of those models.

I'm currently adding CPU and GPU real fan speed monitoring on ASUS G74Sx and G75VW models into HWiNFO (should work similar to G73).

Does anyone have such a model, so I could test it there?

GPU fan speed under the GPU section in HWiNFO (and also in GPU-Z) is not a valid value on most notebooks. It's because this value is read from the GPU, but notebooks use a different thermal/fan control design which is usually controlled by a dedicated microcontroller (EC). So the GPU doesn't know about this fan, and that's why HWiNFO has special features to offer real fan speed monitoring on some notebooks (including Alienware).

You know what's the difference between communism and democracy ? In communism you don't dare to talk about many things, in democracy you can talk as much as you want, but in the end nothing changes..

Of course neither communism nor democracy is in real world what it was supposed to be...

I remember communism (we had here) and know 'democracy'... actually I'm not sure what's the worser one...

Thanks guys. So not even the subsystem ID can be trusted to distinguish 6970 from 6990 (Michael and Jimbo have the same ID on different cards)

Thanks. What version of HWiNFO do you have (you posted a GPU-Z screenshot)? Later ones should properly recognize your card as FirePro.

I think it might be possible to properly distinguish the models using Subsystem IDs, I just need more reports from different cards.

Guys, I want to improve the recognition of 6970M / 6990M and AMD doesn't make this easy (uses the same IDs)..

So I need your feedback - if you have such a card, please post here which one (6970 or 6990) and the corresponding Hardware ID reported by HWiNFO32/64 under GPU (like: PCI\VEN_1002&DEV_6720&SUBSYS_04A41028&REV_00).

I don't know why that happens. It might be a BIOS limitation or internal CPU Operating Point Protection. Probably the only way to determine this would be to measure it using a multimeter directly...

I'm not sure if I'm allowed to disclose this feature in detail and don't know if it's fully public.

But the Overclocking Extra Voltage is a feature that allows to add an offset to the VID for each operating point. That means, this offset is applied to all VR requests.

Uh, I voted for the wronge range, how can I fix it? Actually I'm in the 35+, don't remember the exact number all the time, but need to calculate it every time

Thanks. I can confirm that it's the ULPS feature - I can't touch the GPU2 registers when it's off (due to ULPS), otherwise it could cause a BSOD.

Yep, enable Debug Mode, start try to switch to GPU2 and if you see that issue close HWiNFO32 and send the HWiNFO32.DBG file.

ok sign me up, how do I make a Debug file for you? Just open hwinfo32 in debug mode and then send you file generated?

Debug File from the machine where you have the issue with not seeing GPU2 properly. Just to confirm if my assumption about ULPS is correct. (this feature has already caused many headaches to developers of such tools..)

Do you need the debug file form my laptop or from AMD? if you need from me let me know and I will be happy to search for it and send it to you.

I believe this is because of the ULPS feature.

If GPU2 is off because of this feature then if you access its registers it will cause a BSOD. AMD is aware of this long ago but has not fixed that yet.. so the only thing I can do to avoid a BSOD is not to touch the GPU2 if it's off.. That might explain why you see GPU2 only if it is used (not switched off by ULPS).

It might also help me to confirm if it's really this issue if I would get the HWiNFO32 Debug File.

Thanks! Brian already did a test and it seems to work. However still needs more testing if all fans are reported correctly.

If it works properly, it might help to test the issue with GPU2 temperatures (GPU and GPU2 fan speeds)..

I have posted a new build (1257) in the HWiNFO32 section.

I am getting mine starting tomorrow, if you haven't found anyone by that time just hit me, I be more than glad to assist.

Guys, is there an M18x owner that wants to contribute to HWiNFO32 ?

I want to try to read the GPU2 fan speed too and need someone who will run a test build of HWiNFO32 and report back.

How do you know that GPU2 fan speed is much slower, do you judge based on the GPU-Z reported fan speed (or HWiNFO32 fan speed under the GPU)? If yes, then forget this reading - it's invalid, because the GPU doesn't control the fan here. Just like on other Alienware models I had to implement the model-specific fan speed reading via EC, so use only those values for fan speeds. Unfortunately for M18x I don't know how to read both fan speeds yet. I can read 2 fans only now: CPU and GPU (probably GPU1). I'm not sure if Compal offers the GPU2 fan speed read, I could try something - make a special build to test if I can get the GPU2 fan speed too. Let me know if you want to give it a try.

Hm, both ~99% loaded and same clocks.. IMO a cooling issue - heatsink, thermal dissipation or a GPU chip with bad thermal characteristics..

Are both GPUs 100% loaded during the test?

What does HWiNFO32 say? Post a screenshot (also with fan speeds), use latest build with M18x support.

You can also open graphs for both GPUs to see how the load/temperatures behaves during the test.

If both are symmetricaly loaded, but temps are different it's most probably a heatsink issue.

2 instances of GPU-Z? Why not a single instance of HWiNFO32? :-P

You can also launch the graph for GPU usage and watch which one is more utilized.