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.