An additional benefit from the great learning experience of the past 2 weeks is that I managed to get rid of the temperature and power throttling locks. More precise: I have set the power throttling threshold from 6W to 11W and max temperature from 68 to 84 degrees celcius. This tablet is now more valuable than when I bought it 
After some testing and experimentation, I do seem to have a problem with the throttling/power management on mine. I didnât tweak the Setup var yet to increase TDP or max temp, but what seems to happen is after some wake sleep cycles the CPU gets stuck at 600MHz even when it is cold. This makes the tablet really slow. Any experience on that? I have the i5-4300y processor in mine.
Another question, which values did you tweak in the Setup var to increase the TDP? All the information I find online just unlock the TDP setting, and require ThrottleStop or Intel XTU to actually increase it. It would be nice if this change could be done pre-boot in BIOS.
I have the same cpu and changed these vars:
* 0xD0E 0x01 0x00 ; Package power limit lock
* 0x54 0x01 0x00 ; Platform power limit lock
* 0xD04 0x01 0x00 ; CFG lock
* 0xD0D 0x01 0x00 ; VR Current value lock
* 0x39 0x00 0x00 ; Configurable TDP lock
* 0x23 0x20 0x10 ; TCC activation offset
* 0x3A 0x00 0x10 ; Config TDP lock
I then use Intel XTU to increase the power threshold from 6W to 11W and RW_Everything to change memory-mapped IO reg 0xFED159A0 to 0x00000000
I keep XTU and RW_Everything open and switch to standby for a few secs
When the cpu and gpu are under stress the cpu core frequencies consistently show around 2GHz and the gpu something like 600-800MHz iirc
Temerature goes up to around 82 celcius which seems not to be a big deal.
I am not a gamer, but just for fun I installed League of Legends and found frame rates have more than doubled. I also did some large sw builds on xenial running in vmware and this also runs much quicker.
I have just one more issue with my tablet, if I choose standby upon closing the lid and I return from it, then the tablet becomes terribly slow. I probably need to do another clean up of my NVAR and/or DVAR. Can anyone with a Dell keyboard dock confirm? (I already upgraded the keyboard dock fw to v3.7)
This is the exact problem I am describing now, I have the travel keyboard and experience the same. In XTU you can see that it only clocks at 600MHz, and sometimes (not always) it shows constant thermal throttling ON. I also have the desktop dock and undocking/redocking helps to reset it. If no dock is available, I have to reboot to restore it to full speed again.
Unfortunately I think it is an inherent problem with our CPU that throttling sometimes gets stuck. I have found this: https://software.intel.com/en-us/forums/âŚng/topic/594164
It is about an i5-4300u, but that it applies to the i5-4300y too. The errata document describing the problem he refers to is here: https://www.intel.com/content/dam/www/puâŚtion-update.pdf
Search for "Throttling may continue indefinitely".
It says "Workaround: It is possible for the BIOS to contain a workaround for this erratum" so we should poke Dell.
I will check my friendâs tablet and see if he has the same problem. If not, then I will flash his bios dump. What is the model number of your motherboard? I think it is shown in BIOS system info, if not CPU-Z shows it somewhere on the 2nd or 3rd tab.
They mean CPU Microcode most likely. Do you have the latest one for your CPUID? You can use MC Extractor to determine that.
UEFITool says we have revision 0x1C dated from 07.03.2014 embedded in the latest BIOS, so probably not. Canât immediately find an overview online, will keep looking.
I do know linux automatically loads a newer microcode during bootup, so we could test if it happens when running linux.
Attached is the latest 40651 microcode weâve found, maybe that fixes your issue.
I checked with RW everything what microcode the CPU was running while booted, which was 0x1D. Apparently windows does upgrade it at runtime when booting, but only bumps the version by 1.
I have found this driver/utility online: https://labs.vmware.com/flings/vmware-cpâŚe-update-driver
Installing it and downloading the microcode.dat file from intel gives me version 0x20, the same one provided by plutomaniac. If this fixes it, I will consider embedding it in BIOS. FIngers crossed!
I renamed plutomaniacâs file to microcode.dat and ran install.bat but it insists on a second file microcode_amd.bin ?
Ah, I found this remedy
I tried it, but no luck. Eventlog gives me one error âUnexpected data while parsing whitespace in microcode file.â and a warning âAn update for this CPU was not found. No update has been attempted.â. Will try again with a microcode from Intel.
Okay, it installed fine. Trying to find the microcode version in RW Everything⌠Found it: patch ID in CPU MSR table, it says 1D. Hm, not 20?? Yes 20 after reboot 
EDIT: tested it a few times and the problem seems to be solved
EDIT2: tested it another time and waited a bit longer and CPU locked at 0.60 GHz again 
Sorry for the sparse information. I followed the instructions on the vmware page (https://labs.vmware.com/flings/vmware-cpâŚer#instructions). Indeed, you need to download a .dat containing all possible microcode from intel. The file from plutomaniac is probably for embedding in the BIOS. I added the AMD microcode too since it was in the guide, not sure if you can skip that. After running install.bat it applied immediately.
I havenât experienced throttling yet, but it somehow happens very infrequently in my case. Only when I have an uptime >2days with only suspend-wake cycles. If this doesnât solve it we maybe have to complain with Dell, I donât think you can have a cleaner BIOS than what we have.
To answer your previous question about which motherboard rev I have, it says A00. Did you have this issue before your ME corruption? I donât have experience with the tablet before my fault condition either, I basically got it like this. I canât say it has been a very reliable computer up until nowâŚ
The weird thing is that with my tablet I can trigger the problem only when closing the lid and then getting it out of sleep again. I couldnât reproduce it with the ON/OFF button which is also set to sleep. I never noticed any problem like this before I got my keyboard. I will do more testing with my friendâs tablet and keyboard, actually my ME probs started after using the keyboard for the first time. Perhaps I am brave enough to flash the microcode in bios later on, maybe it can make a difference.
PS: my mainboard is a T69G0 Rev A00
It happened again on my tablet too. It seems to recover itself if I dock and undock it from the desktop dock (Dell K10A). Maybe you will get the same effect by connecting and disconnecting the microUSB charger, but I canât test that because the previous user lost that charger - I always charge through that dock.
I will test that later.
With the keyboard connected, I could provoke the error after going to sleep a couple of times by pressing the ON/OFF button (instead of closing the lid). I havenât tested without the keyboard, but I suspect it will work fine. What I recall is there is no problem with a connected charger while the keyboard is connected. I havenât injected the cpu ucode in the bios yet. I want to try that later, but I suspect it wonât help either. Perhaps a newer version of the keyboard firmware might help, I am currently on v3.7. I did not search for any later versions. The keyboard update is the Dell Venue Pro 11 5130/7130/7139/7140 Travel Keyboard TI MSP430 Firmware which I found here
EDIT: On the recommended updates page I found there is a Main stream BIOS and a VPro BIOS:
Venue 11 Pro 7130 A16 Mainstream 7/16/2015
Venue 11 Pro 7130 A16 vPro 7/16/2015
It would be interesting to know whether the Mainstream can make a difference. Probably the only difference is the ME feature set.
I donât have the travel keyboard but the slim keyboard. I always have it connected when I donât use the dekstop docking station, because it is also kind of a case for the tablet. The tablet sleeps when you fold the keyboard over the screen, thatâs how I typically use it.
I havenât tried if the tablet enters the same fault condition when I donât use the keyboard, I can try that.
Iâve tested this, when not using the keyboard the fault does not occur. With keyboard, the fault condition can be provoked by just closing the keyboard over the screen. At least when the power option for the action when the lid is closed is set to sleep, but I believe even when the action do nothing is set, the fault will also happen. Does anybody know what sensor is used for detecting the lid closed state? I guess it is a magnet, and if that is the case I will most likely remove it.
The fault condition is reset when the original Dell power supply is connected. I have not yet found any other way to reset it. I doubt it is the bug which is described in the Intel Errata. The core clock frequency is kept to a low value, most of the time 0.6 GHz, but I also once got it stuck at 0.7 GHz Is there any hw info tool which shows TM1 bit values?
A new observation: the issue does not exist under Linux. After multiple suspend/resume cycles over 2 weeks, the cpufreq did not get stuck at 600MHz even once.
I will try and install all Dellâs tools in Windows, maybe one of them contains a fix? My Windows install right now is a bare bones clean install, I normally avoid installing all the manufacturers utilities and tools.
PS: Initially I didnât install any microcode update packages in Linux, and it did flag a âFirmware Bugâ in dmesg due to old microcode. It preventively disabled TSC_DEADLINE APIC functionality. Version 0x20 and above is required to fix it, but the throttling issue does not appear under Linux with or without the microcode update.
Thanks for your update. Do you have instructions how to read out the cpufreq in linux. And is the default behavior to enter suspend when button is pressed? Looks like the Windows mobile docking keyboard driver suite is buggy. Perhaps requires additional power management settings (âallow this device to wake the computerâ or whatever)
On my tablet it only occurs when my mobile kb is connected and only if it runs on battery. I am running the most recent Insider preview of Windows 10 and the most recent ucode is loaded at boot. I have also installed all Dell tools to update drivers etc, but that doesnât solve anything. When the cpu gets stuck at 600 MHz, connecting the original or any other charger or powerbank unlocks it. At least with non-original chargers or powerbanks it takes a few replug cycles.
EDIT: still testing it, but I think I found the culprit. I disabled a few Human Interface Devices related to the docking keyboard (two HID-compliant vendor-defined devices and one USB Input Device) and then I couldnât provoke the issue anymore
EDIT2: although I couldnât provoke it by pressing the button to suspend/unsuspend, after closing /opening the keyboard the problem still occurs. Is there a relationship with the keyboard lid close sensor driver (ACPI Lid)?
EDIT3: on my tablet the stuck cpu frequency issue can systematically be triggered by closing the keyboard cover and then opening it again, if the tablet was put to sleep at least once before doing that. Even after setting âDo nothingâ when closing the lid in the power options you can just provoke it by slowly closing the keyboard cover until the display backlight goes off and then opening it up again. I suspect there is a fault in the âACPI Lidâ driver, although it is not a real driver as there are no driver files required or loaded for this device and it can also not be disabled. I am trying to find a way to disable it nonetheless. Probably in Linux the driver behaves different or perhaps in Linux there is no driver at all to detect keyboard cover/lid closed.
EDIT4: I changed the ACPI Lid driver to MS Volume Manager and then disabled that device. Unfortunately, it doesnât solve the problem. I wonder whatâs different in Linux and will test with Ubuntu Xenial
EDIT5: I tested suspend followed by multiple times closing and opening the keyboard in Ubuntu Xenial and checked cpufreq with lscpu and can confirm your observation, the cpufreq never gets stuck. My guess is the problem is caused by the display adapter driver (âIntel HD Graphics Familyâ). I replaced it with âMicrosoft Basic Display Adapterâ but unfortunately that driver doesnât support S3 sleep mode
I monitor the cpu frequency like this: watch -n1 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
Other tools seemed to always report 1.6GHz, the frequency the cpu is rated for. Anyway, under Linux it is definitely working.
Have you also installed Dell Command | Configure and Dell Command | Power Manager? I installed those 2 specific tools yesterday. The Power Manager tool creates a startup item and runs in the background, so it could have some effect.
If that doesnât do the job I also think it is probably a driver problem. Very quirky tablet⌠Does your friend (the one you got the dump from) also have these issues?