Strange Behavior.

[DreamSeason]

Hi, TW. I'm here to ask something quite strange in my Insprion N4010. I've read the whole source in this project. I tried with the rw-everything to manually set the rpm to a fixed value. But it seems it would restore to bios control after around second after I changed it. I already write 0x60 to be 00 so I can take over the fan control. Any ideas? Thanks. BTW, hwmonitor in osx is capable of settng a fixed rpm fan. :(

[Dolnor]

Hi,
You have to have the fan ON, then make it drop speed gradually by setting level 0x63 to 0 once it runs at level 1 (you can't do it at level 2 as it will force itself back to 2 as soon as you write 0) and wait out until you get to a sensible (for your anyway) rpm figure, then lock the fan at that speed by writing 0 to 0x60. If it's revoking the fan control back to automatic after that, then EC behaves differently on your 14R and you'd have to figure out the exact behavior (of perhaps register to lock the fan).

[DreamSeason]

Thanks for your reply. Just to make sure I make everything you said loud and clear. So you suggestion is that I lock the fan speed manually by setting 0x60 to 0 when it's decreasing itself to 0 RPM. Am I correct on this? Another question is that if there is any guidance related to our EC? I strongly doubt we share the same chip because your registers seem identical to mine. I mean the place for fanH, fanL, CPU, GPU etc.

[Dolnor]

In that scenario it shouldn't be revoking itself back to auto, yes.
Despite the fact that registers are the same, behavior coded in the firmware may be somewhat different and thus resulting in different results.

[DreamSeason]

If so, anything I could turn to for help? I seem to read that you said this is closed sheet. So there is not related documentation out there?

[Dolnor]

Nope, there are no docs what so ever for ITE8518E, nor the DELL specific firmware on it, as such this is solely based on me deciphering the behavior on my particular laptop having Secure Core Tiano base firmware.

[DreamSeason]

Got it. Correct me if I were wrong. If I change 0x60 to 0, which means I take control, 0x63 would be FF. Is it the same result on your end?

[Dolnor]

Yes, the fan level transitions to 0xFF once you override and ideally should stay at that.

[DreamSeason]

:( When 0x63 is 01, which means the fan is on level 1, I try to set it to 0 to decrease the fan speed. However, after I set it to 0, it would reset to 1 after around 1 second. :( any ideas to bypass that?

[Dolnor]

nope, sadly I have no idea how to bypass that .. it seems to be controlled differently on your unti .. which makes me wonder how come the same control approach works through HWMonitor in OSX then .. ?

[DreamSeason]

Yeah. I am amazed by this too. To use that app in OS X, I have to use an additional ssdt. Don't know if thats related.

[Dolnor]

The thing is .. this SSDT that I had coded had exactly the same control logic as what you are doing in RWE. so unless it's a Dell driver that messes this up I fail to see the fragmented behavior across both OSes.

[DreamSeason]

Thanks for explanation. Anyway, is the method you described working in your PC?

[DreamSeason]

Hi, TW. Back again. Even though it's nearly 2017 now. I want to ask have you experienced the value of 0x63 being 3, 4 or 5? I recently found my dell would stay in 5 for quite a long time. Maybe there is malfunction with my fan. Just here to ask if you can shed some light on this problem. BTW, happy new year. :D